From alpt@freaknet.org Sat Jan 1 01:10:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 01:10:27 -0800 (PST) Received: from darkalpt.dyndns.org (host111-78.pool82104.interbusiness.it [82.104.78.111]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0199wZ3013031 for ; Sat, 1 Jan 2005 01:10:19 -0800 Received: (qmail 6179 invoked by uid 1000); 31 Dec 2004 23:31:12 +0100 Date: Fri, 31 Dec 2004 23:31:12 +0100 From: Alpt To: netdev@oss.sgi.com Subject: Ipv6 and the lost broadcast Message-ID: <20041231223112.GA6134@darkalpt> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alpt@freaknet.org Precedence: bulk X-list: netdev --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Once upon a time in the ip protocol there was INADDR_BROADCAST, and all seemed happy. =66rom "man ipv6": " IPv6 supports several address types: unicast to address a single host, multicast to address a group of hosts, anycast to address the nearest member of a group of hosts (not implemented in Linux), IPv4-on-IPv6 to address a IPv4 host, and other reserved address types." =66rom net/ipv6/tcp_ipv6.c +582: =2E.. /* * connect() to INADDR_ANY means loopback (BSD'ism). */ =09 if(ipv6_addr_any(&usin->sin6_addr)) usin->sin6_addr.s6_addr[15] =3D 0x1;=20 =2E.. Why it isn't supported? Is there a particular reason to follow this BSD'ism?=20 Is it possible to achieve the same result of INADDR_BROADCAST with multicast? The propagation has to be restricted only to the neighbour nodes. Best Regards --=20 :wq! "I don't know nothing" The One Who reached the Thinking Matter '.' [ Alpt --- Freaknet Medialab ] [ GPG Key ID 441CF0EE ] [ Key fingerprint =3D 8B02 26E8 831A 7BB9 81A9 5277 BFF8 037E 441C F0EE ] --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB1dMwv/gDfkQc8O4RApdjAJ45hCKiV9673qrR0n/cUZFYAybqHQCgp/MA lqc74S9l3p60u1r3SmHPywE= =qMh9 -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From tgraf@suug.ch Sat Jan 1 04:02:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 04:02:17 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j01C1ltk019233 for ; Sat, 1 Jan 2005 04:02:08 -0800 Received: from postel.suug.ch (unknown [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 0C8EDF; Sat, 1 Jan 2005 13:09:58 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 77D251C0EA; Sat, 1 Jan 2005 13:10:41 +0100 (CET) Date: Sat, 1 Jan 2005 13:10:41 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. Message-ID: <20050101121041.GR32419@postel.suug.ch> References: <20041229150140.GJ32419@postel.suug.ch> <1104335620.1025.22.camel@jzny.localdomain> <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104526311.1047.379.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13314 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 * jamal <1104526311.1047.379.camel@jzny.localdomain> 2004-12-31 15:51 > On Fri, 2004-12-31 at 13:11, Thomas Graf wrote: > > * jamal <1104511494.1048.303.camel@jzny.localdomain> 2004-12-31 11:44 > > > Agreed I just don't get the reason for the PID. tc is usually called as > > a new process instance when dumping. > > Indeed. A new instance of tc should be able to delete or understand > what an old instance with different process ID installed. > The P in pid here stands for "program" not "process". Looking at it from > another angle it is the "owner" of that rule. Ahh, now this makes sense. Sorry, I misunderstood you all the time. > > u16 handle > > u16 matchID > > u16 kind > > u8 flags > > u8 pad > > We need to know who installed the rule so we can intepret what the ID in > the match is. Yes but this should go into the selector header. > You may actually need those Ts enumerated as if they are array > indices. Look at the way i transfer actions using "order" Right, order would be N-2. I don't see any reason for storing it, I didn't had need for it in EGP and I used exactly the same techniques as in the action code. > My view was length is also a common field. Theres also another reason > why you want length viewable in a dumb way: > --> you dont really wanna force people to write dumpers for these > ematchers (goal: keep this interface as simple as it can be); i.e dont > need any pretty formater in the kernel. > If you have a length then you can reconstruct the TCA_EMATCH easily > without caring about the content. This is the path i started taking in > eactions. Refer to my notes i sent earlier on the mythical one page > ematch/eaction. > If someone wants funky stuff - write a classifier. Very simple ematches will only require a struct for configuration so the dumping is not more than 5 lines of code. The length can be calculated via RTA_PAYLOAD(ematch_tlv) - sizeof(ematch_hdr). This of course requires the struct to be aligned to RTA_ALIGN but that's generally not a problem at all. I understand your concern but I also want to allow a little bit more complicated ematches such as KMP or later a very simple regular expression implementation. Here's some code from the simple_cmp key of EGP giving a good idea how a simple ematch will look like: static int sc_match(struct egp_cls *cls, struct egp_key *k) { struct egp_key_sc *sc = k->data; u32 lvalue = cls->ops->read(cls, &sc->left); u32 rvalue = cls->ops->read(cls, &sc->right); switch (sc->op) { #define SC(a, b) case EGP_OP_##a: return b SC(NONE, 0); SC(EQ, lvalue == rvalue); SC(NE, lvalue != rvalue); SC(LT, lvalue < rvalue); SC(LE, lvalue <= rvalue); SC(GT, lvalue > rvalue); SC(GE, lvalue >= rvalue); #undef SC } BUG(); return 0; } static int sc_validate(struct egp_config *conf, struct egp_ops *ops, void *d, size_t len) { int err; struct egp_key_sc *sc = d; if (len != sizeof(*sc) || sc->op > EGP_OP_MAX) return -EINVAL; return 0; } static int sc_replace(struct egp_cls *cls, struct egp_key *k, void *d, size_t len) { k->data = kmalloc(len, GFP_KERNEL); if (NULL == k->data) return -ENOBUFS; memcpy(k->data, d, len); return 0; } static int sc_dump(struct egp_cls *cls, struct sk_buff *skb, struct egp_key *k) { struct egp_key_sc *sc = k->data; RTA_PUT(skb, TCA_EGP_KEY_DATA, sizeof(*sc), sc); return 0; rtattr_failure: return -1; } static void sc_free_data(struct egp_cls *cls, struct egp_key *k) { if (k->data) kfree(k->data); } OTOH, on more complex ematches data might be nested TLVs with optional parameters. etc. > Stats are the other thing that adds complexity to the API. If you can > make it optional then that would be best - I was thinking to not even > have it in. It's probably enough to allow optional generic hits/success stats per match. > I thought we already agreed on the layout: > SEL2- which may nest E/MATCHEs TLVs. Sel2 not being very different from > original selector. May be i didnt follow. You did follow but I made the existing u32 match a ematch as well. Things like the program ID goes into the selector header T=1 and classifier specific selector bits such as the hashing bits goes into T=2. Thinking of it it's probably cleaner to put things like hmark, hoff into its own TLV. So the selector TLV contains the selector header at T=1 and nested ematch TLVs at T=2..T=N. I think we're mostly in sync so I'll start working on it and we can review again. From tgraf@suug.ch Sat Jan 1 04:13:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 04:13:33 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j01CCstU020370 for ; Sat, 1 Jan 2005 04:13:15 -0800 Received: from postel.suug.ch (unknown [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 0E8E5F; Sat, 1 Jan 2005 13:21:07 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 82BD81C0EA; Sat, 1 Jan 2005 13:21:50 +0100 (CET) Date: Sat, 1 Jan 2005 13:21:50 +0100 From: Thomas Graf To: "David S. Miller" Cc: Jamal Hadi Salim , Patrick McHardy , netdev@oss.sgi.com Subject: [FINAL RESEND 2/9] PKT_SCHED: tc filter extension API Message-ID: <20050101122150.GS32419@postel.suug.ch> References: <20041230122652.GM32419@postel.suug.ch> <20041230123023.GO32419@postel.suug.ch> <20041230163359.GA32419@postel.suug.ch> <20041231141249.GK32419@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041231141249.GK32419@postel.suug.ch> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13315 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 The tcf_exts API abstracts extensions such as actions/policers into a generic layer and reduces the knowledge inside classifiers to the minimum required. It isolates the validation code into its own function to allow classifiers to validate all input data before making changes and thus avoids the need to undo changes if a extension configuration request cannot be fullfilled. Adds missing locking when adding a action/police extension to an already existing filter. Acquiring dev->queue_lock makes sure we don't change the action/police in the middle of a classification. Noted by Patrick McHardy. As a nice side effect, using this API removes the existing ifdef clutter. Usage: The classifier holds struct tcf_exts which may be empty if no extensions are compiled in. It then calls tcf_exts_validate when a new change request was received and provides a temporary tcf_exts copy to store the change requests. Given it succeeded the classifier may change its own parameters and at the end call tcf_exts_change to commit the changes and replace the existing extension configuration with the new one. The classifier is responsible to destroy his temporary copy if any of its own validation checks fail. The classifier specific TLV types must be exported to the extensions API via tcf_ext_map. Destroying the extensions is as easy as calling tcf_exts_destroy. The extensions are executed by the classifier by calling tcf_exts_exec which must be done as the last thing after making sure the filter matches. Note: A classifier might take further actions after the execution to tcf_exts_exec such as correcting its own cache to avoid caching results which could have been influenced by the extensions. tcf_exts_exec returns a negative error code if the filter must be considered unmatched, 0 on normal execution or a positive classifier return code (TC_ACT_*) which must be returned to the underlying layer as-is. Signed-off-by: Thomas Graf --- linux-2.6.10-bk2.orig/include/net/pkt_cls.h 2004-12-31 14:10:54.000000000 +0100 +++ linux-2.6.10-bk2/include/net/pkt_cls.h 2004-12-30 17:17:56.000000000 +0100 @@ -62,6 +62,93 @@ tp->q->ops->cl_ops->unbind_tcf(tp->q, cl); } +struct tcf_exts +{ +#ifdef CONFIG_NET_CLS_ACT + struct tc_action *action; +#elif defined CONFIG_NET_CLS_POLICE + struct tcf_police *police; +#endif +}; + +/* Map to export classifier specific extension TLV types to the + * generic extensions API. Unsupported extensions must be set to 0. + */ +struct tcf_ext_map +{ + int action; + int police; +}; + +/** + * tcf_exts_is_predicative - check if a predicative extension is present + * @exts: tc filter extensions handle + * + * Returns 1 if a predicative extension is present, i.e. an extension which + * might cause further actions and thus overrule the regular tcf_result. + */ +static inline int +tcf_exts_is_predicative(struct tcf_exts *exts) +{ +#ifdef CONFIG_NET_CLS_ACT + return !!exts->action; +#elif defined CONFIG_NET_CLS_POLICE + return !!exts->police; +#else + return 0; +#endif +} + +/** + * tcf_exts_is_available - check if at least one extension is present + * @exts: tc filter extensions handle + * + * Returns 1 if at least one extension is present. + */ +static inline int +tcf_exts_is_available(struct tcf_exts *exts) +{ + /* All non-predicative extensions must be added here. */ + return tcf_exts_is_predicative(exts); +} + +/** + * tcf_exts_exec - execute tc filter extensions + * @skb: socket buffer + * @exts: tc filter extensions handle + * @res: desired result + * + * Executes all configured extensions. Returns 0 on a normal execution, + * a negative number if the filter must be considered unmatched or + * a positive action code (TC_ACT_*) which must be returned to the + * underlying layer. + */ +static inline int +tcf_exts_exec(struct sk_buff *skb, struct tcf_exts *exts, + struct tcf_result *res) +{ +#ifdef CONFIG_NET_CLS_ACT + if (exts->action) + return tcf_action_exec(skb, exts->action, res); +#elif defined CONFIG_NET_CLS_POLICE + if (exts->police) + return tcf_police(skb, exts->police); +#endif + + return 0; +} + +extern int tcf_exts_validate(struct tcf_proto *tp, struct rtattr **tb, + struct rtattr *rate_tlv, struct tcf_exts *exts, + struct tcf_ext_map *map); +extern void tcf_exts_destroy(struct tcf_proto *tp, struct tcf_exts *exts); +extern void tcf_exts_change(struct tcf_proto *tp, struct tcf_exts *dst, + struct tcf_exts *src); +extern int tcf_exts_dump(struct sk_buff *skb, struct tcf_exts *exts, + struct tcf_ext_map *map); +extern int tcf_exts_dump_stats(struct sk_buff *skb, struct tcf_exts *exts, + struct tcf_ext_map *map); + #ifdef CONFIG_NET_CLS_ACT static inline int tcf_change_act_police(struct tcf_proto *tp, struct tc_action **action, --- linux-2.6.10-bk2.orig/net/sched/cls_api.c 2004-12-31 19:31:07.000000000 +0100 +++ linux-2.6.10-bk2/net/sched/cls_api.c 2004-12-31 19:26:59.000000000 +0100 @@ -439,6 +439,154 @@ return skb->len; } +void +tcf_exts_destroy(struct tcf_proto *tp, struct tcf_exts *exts) +{ +#ifdef CONFIG_NET_CLS_ACT + if (exts->action) { + tcf_action_destroy(exts->action, TCA_ACT_UNBIND); + exts->action = NULL; + } +#elif defined CONFIG_NET_CLS_POLICE + if (exts->police) { + tcf_police_release(exts->police, TCA_ACT_UNBIND); + exts->police = NULL; + } +#endif +} + + +int +tcf_exts_validate(struct tcf_proto *tp, struct rtattr **tb, + struct rtattr *rate_tlv, struct tcf_exts *exts, + struct tcf_ext_map *map) +{ + memset(exts, 0, sizeof(*exts)); + +#ifdef CONFIG_NET_CLS_ACT + int err; + struct tc_action *act; + + if (map->police && tb[map->police-1] && rate_tlv) { + act = tcf_action_init_1(tb[map->police-1], rate_tlv, "police", + TCA_ACT_NOREPLACE, TCA_ACT_BIND, &err); + if (act == NULL) + return err; + + act->type = TCA_OLD_COMPAT; + exts->action = act; + } else if (map->action && tb[map->action-1] && rate_tlv) { + act = tcf_action_init(tb[map->action-1], rate_tlv, NULL, + TCA_ACT_NOREPLACE, TCA_ACT_BIND, &err); + if (act == NULL) + return err; + + exts->action = act; + } +#elif defined CONFIG_NET_CLS_POLICE + if (map->police && tb[map->police-1] && rate_tlv) { + struct tcf_police *p; + + p = tcf_police_locate(tb[map->police-1], rate_tlv); + if (p == NULL) + return -EINVAL; + + exts->police = p; + } else if (map->action && tb[map->action-1]) + return -EOPNOTSUPP; +#else + if ((map->action && tb[map->action-1]) || + (map->police && tb[map->police-1])) + return -EOPNOTSUPP; +#endif + + return 0; +} + +void +tcf_exts_change(struct tcf_proto *tp, struct tcf_exts *dst, + struct tcf_exts *src) +{ +#ifdef CONFIG_NET_CLS_ACT + if (src->action) { + struct tc_action *act; + tcf_tree_lock(tp); + act = xchg(&dst->action, src->action); + tcf_tree_unlock(tp); + if (act) + tcf_action_destroy(act, TCA_ACT_UNBIND); + } +#elif defined CONFIG_NET_CLS_POLICE + if (src->police) { + struct tcf_police *p; + tcf_tree_lock(tp); + p = xchg(&dst->police, src->police); + tcf_tree_unlock(tp); + if (p) + tcf_police_release(p, TCA_ACT_UNBIND); + } +#endif +} + +int +tcf_exts_dump(struct sk_buff *skb, struct tcf_exts *exts, + struct tcf_ext_map *map) +{ +#ifdef CONFIG_NET_CLS_ACT + if (map->action && exts->action) { + /* + * again for backward compatible mode - we want + * to work with both old and new modes of entering + * tc data even if iproute2 was newer - jhs + */ + struct rtattr * p_rta = (struct rtattr*) skb->tail; + + if (exts->action->type != TCA_OLD_COMPAT) { + RTA_PUT(skb, map->action, 0, NULL); + if (tcf_action_dump(skb, exts->action, 0, 0) < 0) + goto rtattr_failure; + p_rta->rta_len = skb->tail - (u8*)p_rta; + } else if (map->police) { + RTA_PUT(skb, map->police, 0, NULL); + if (tcf_action_dump_old(skb, exts->action, 0, 0) < 0) + goto rtattr_failure; + p_rta->rta_len = skb->tail - (u8*)p_rta; + } + } +#elif defined CONFIG_NET_CLS_POLICE + if (map->police && exts->police) { + struct rtattr * p_rta = (struct rtattr*) skb->tail; + + RTA_PUT(skb, map->police, 0, NULL); + + if (tcf_police_dump(skb, exts->police) < 0) + goto rtattr_failure; + + p_rta->rta_len = skb->tail - (u8*)p_rta; + } +#endif + return 0; +rtattr_failure: __attribute__ ((unused)) + return -1; +} + +int +tcf_exts_dump_stats(struct sk_buff *skb, struct tcf_exts *exts, + struct tcf_ext_map *map) +{ +#ifdef CONFIG_NET_CLS_ACT + if (exts->action) + if (tcf_action_copy_stats(skb, exts->action) < 0) + goto rtattr_failure; +#elif defined CONFIG_NET_CLS_POLICE + if (exts->police) + if (tcf_police_dump_stats(skb, exts->police) < 0) + goto rtattr_failure; +#endif + return 0; +rtattr_failure: __attribute__ ((unused)) + return -1; +} static int __init tc_filter_init(void) { @@ -461,3 +609,8 @@ EXPORT_SYMBOL(register_tcf_proto_ops); EXPORT_SYMBOL(unregister_tcf_proto_ops); +EXPORT_SYMBOL(tcf_exts_validate); +EXPORT_SYMBOL(tcf_exts_destroy); +EXPORT_SYMBOL(tcf_exts_change); +EXPORT_SYMBOL(tcf_exts_dump); +EXPORT_SYMBOL(tcf_exts_dump_stats); From kaber@trash.net Sat Jan 1 08:04:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 08:04:20 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j01G3qNb028448 for ; Sat, 1 Jan 2005 08:04:12 -0800 Received: from eru.coreworks.de ([172.16.0.2] helo=trash.net) by kaber.coreworks.de with esmtp (Exim 4.34) id 1CklrN-0006fw-RW; Sat, 01 Jan 2005 17:12:11 +0100 Message-ID: <41D6CB87.8040205@trash.net> Date: Sat, 01 Jan 2005 17:10:47 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , netdev@oss.sgi.com, Wichert Akkerman Subject: Re: patch: tunnels not setting inputdev References: <1104513392.1048.316.camel@jzny.localdomain> <41D5941C.8060001@trash.net> <1104523892.1047.338.camel@jzny.localdomain> In-Reply-To: <1104523892.1047.338.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev jamal wrote: >>For the remaining changes, why not simply set >>input_dev in netif_receive_skb before the call to ing_filter ? > > You want to be able to filter on indev at ingress - it is safer for > whoever calls netif_rx() to do the setting. The packet could be looped > from egress multiple times as well (redirected). Currently input_dev is set in eth_type_trans, ppp_generic and the mirred action. With your patch we have a couple of drivers more, but this still leaves lots of non-ethernet drivers that don't set input_dev. A centralized solutions seems much better to me than adding this to every single driver. I can't see the problem with redirected packets, just set skb->input_dev = skb->dev in netif_receive_skb, this should have exactly the same effect as setting it in the drivers or the mirred action. Regards Patrick From tgraf@suug.ch Sat Jan 1 10:23:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 10:24:03 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j01INZ7O002637 for ; Sat, 1 Jan 2005 10:23:56 -0800 Received: from postel.suug.ch (unknown [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 B429AF; Sat, 1 Jan 2005 19:31:47 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 32BA31C0EA; Sat, 1 Jan 2005 19:32:30 +0100 (CET) Date: Sat, 1 Jan 2005 19:32:30 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. Message-ID: <20050101183230.GT32419@postel.suug.ch> References: <20041229150140.GJ32419@postel.suug.ch> <1104335620.1025.22.camel@jzny.localdomain> <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104526311.1047.379.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13317 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 * jamal <1104526311.1047.379.camel@jzny.localdomain> 2004-12-31 15:51 > > T=1 generic selector header > > > > T=2 classifier specific selector header (u32 hashsing stuff goes here) > > T=3 ematch 1 > > T=N ematch N > > I thought we already agreed on the layout: > SEL2- which may nest E/MATCHEs TLVs. Sel2 not being very different from > original selector. May be i didnt follow. OK, I changed my mind while implementing it and a selector now looks like this: Selector TLV: +----------------------------+ | TCA_EMATCH_TREE_HDR | +----------------------------+ | TCA_EMATCH_TREE_LIST | | +------------------------+ | | | T=1 Match 1 | | | +------------------------+ | | | T=2 Match 2 | | | +------------------------+ | | | T=N Match N | | | +------------------------+ | +----------------------------+ So we can put more into the selector if needed without breaking compatibility. TCA_EMATCH_TREE_HDR currently contains `nmatches' specifying N and progid holding the PID you talked about. The match TLVs must have a continous numbering because I don't want to define limits as done in the action code. I'll post an RFC patch tomorrow implementing the API and a simple ematch. From ahu@outpost.ds9a.nl Sat Jan 1 12:55:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 12:55:45 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j01KtGxi009506 for ; Sat, 1 Jan 2005 12:55:37 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2322E3FDD; Sat, 1 Jan 2005 22:03:48 +0100 (CET) Date: Sat, 1 Jan 2005 22:03:47 +0100 From: bert hubert To: Shekhar Kshirsagar Cc: Networking Team , jmorris@redhat.com Subject: ipsec null encryption slower than AES / was Re: 2.6 IPSec Throughput puzzle Message-ID: <20050101210347.GA4713@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Shekhar Kshirsagar , Networking Team , jmorris@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev [added James Morris, resident crypto api guru, to the CC list] On Wed, Dec 29, 2004 at 03:50:34PM -0800, Shekhar Kshirsagar wrote: > I played with oprofile for a while, and it seems that in case of null > encryption, scatterwalk related code takes most of the cpu cycles. Odd - the 'scatterlist' is what people were most proud of in the ipsec work in 2.6. I recall that it was implemented as a natural way to represent the encryption needs of ipsec. From your numbers below it is clear all ipsec benchmarks have maxed out your CPU, but aes/sha1 still has some hits in default_idle. Is this an SMP system? scatterwalk_done consists of crypto_kunmap, which in turn calls kunmap_atomic (inline), which is defined as nothing sometimes and as a real function otherwise which is not likely to be inlined, so should show up in the profile if it were a large load. The other part of scatterwalk_done is scatterwalk_page_done, which looks like it could cause further (inlined) work. But, in the end, I can't really help you further. All this scatterlist stuff looks like something is really badly tuned for null-encryption and well-tuned for encryption. > Is there any place where I can find documentation about what exactly > scatterwalk does? http://www.certconf.org/presentations/2004/Tuesday/TS2.pdf - the concept is called 'the scatterlist'. http://lwn.net/Articles/14010/?format=printable is also nice. Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From hadi@cyberus.ca Sat Jan 1 15:21:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 15:21:25 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j01NKvwF012593 for ; Sat, 1 Jan 2005 15:21:18 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Cksgg-0004ZM-BP for netdev@oss.sgi.com; Sat, 01 Jan 2005 18:29:34 -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 1Cksgb-0004Ah-DA; Sat, 01 Jan 2005 18:29:29 -0500 Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050101121041.GR32419@postel.suug.ch> References: <20041229150140.GJ32419@postel.suug.ch> <1104335620.1025.22.camel@jzny.localdomain> <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101121041.GR32419@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104622164.1048.444.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Jan 2005 18:29:25 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13319 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 Sat, 2005-01-01 at 07:10, Thomas Graf wrote: > * jamal <1104526311.1047.379.camel@jzny.localdomain> 2004-12-31 15:51 > > We need to know who installed the rule so we can intepret what the ID in > > the match is. > > Yes but this should go into the selector header. > Agreed - PID needs to go into selector. The other ID is per match. > > You may actually need those Ts enumerated as if they are array > > indices. Look at the way i transfer actions using "order" > > Right, order would be N-2. I don't see any reason for storing it, I > didn't had need for it in EGP and I used exactly the same techniques > as in the action code. > If youve done it on EGP then go ahead and use that scheme since you are comfortable with it. > > My view was length is also a common field. Theres also another reason > > why you want length viewable in a dumb way: > > --> you dont really wanna force people to write dumpers for these > > ematchers (goal: keep this interface as simple as it can be); i.e dont > > need any pretty formater in the kernel. > > If you have a length then you can reconstruct the TCA_EMATCH easily > > without caring about the content. This is the path i started taking in > > eactions. Refer to my notes i sent earlier on the mythical one page > > ematch/eaction. > > If someone wants funky stuff - write a classifier. > > Very simple ematches will only require a struct for configuration > so the dumping is not more than 5 lines of code. The length can be > calculated via RTA_PAYLOAD(ematch_tlv) - sizeof(ematch_hdr). This > of course requires the struct to be aligned to RTA_ALIGN but > that's generally not a problem at all. Does the ematch API include a dump()? I dont think it should - thats the point i was making. Should be simple. > I understand your concern but I also want to allow a little bit > more complicated ematches such as KMP or later a very simple > regular expression implementation. > > Here's some code from the simple_cmp key of EGP giving a good > idea how a simple ematch will look like: > > static int > sc_match(struct egp_cls *cls, struct egp_key *k) > { > struct egp_key_sc *sc = k->data; > u32 lvalue = cls->ops->read(cls, &sc->left); > u32 rvalue = cls->ops->read(cls, &sc->right); > > switch (sc->op) { > #define SC(a, b) case EGP_OP_##a: return b > SC(NONE, 0); > SC(EQ, lvalue == rvalue); > SC(NE, lvalue != rvalue); > SC(LT, lvalue < rvalue); > SC(LE, lvalue <= rvalue); > SC(GT, lvalue > rvalue); > SC(GE, lvalue >= rvalue); > #undef SC > } > > BUG(); > return 0; > } > nice and valid for API. > static int > sc_validate(struct egp_config *conf, struct egp_ops *ops, void *d, size_t len) > { > int err; > struct egp_key_sc *sc = d; > > if (len != sizeof(*sc) || sc->op > EGP_OP_MAX) > return -EINVAL; > return 0; > } > Even this is too much for a simple ematch. Validation should happen in user space or maybe at the mother clasifier. maybe a maxsize,minsize attribute is needed in the ematch struct. > static int > sc_replace(struct egp_cls *cls, struct egp_key *k, void *d, size_t len) > { > k->data = kmalloc(len, GFP_KERNEL); > if (NULL == k->data) > return -ENOBUFS; > memcpy(k->data, d, len); > return 0; > } Equivalent of this should be done by the mother classifier. All it needs to know is the length (and no other details). And the length is known from the L in TLV. > static int > sc_dump(struct egp_cls *cls, struct sk_buff *skb, struct egp_key *k) > { > struct egp_key_sc *sc = k->data; > RTA_PUT(skb, TCA_EGP_KEY_DATA, sizeof(*sc), sc); > return 0; > > rtattr_failure: > return -1; > } > Again if you store length, you dont need this. Mother classifier can do it. > static void > sc_free_data(struct egp_cls *cls, struct egp_key *k) > { > if (k->data) > kfree(k->data); > } Dont need this either; mother classifier can handle it. > OTOH, on more complex ematches data might be nested TLVs with > optional parameters. etc. > > > Stats are the other thing that adds complexity to the API. If you can > > make it optional then that would be best - I was thinking to not even > > have it in. > > It's probably enough to allow optional generic hits/success stats > per match. Even at the moment classifiers dont have stats. If you want stats you could add a simple gact accept action. Note also: think of the 100K rules being added and amount of RAM used; > > I thought we already agreed on the layout: > > SEL2- which may nest E/MATCHEs TLVs. Sel2 not being very different from > > original selector. May be i didnt follow. > > You did follow but I made the existing u32 match a ematch as well. > Things like the program ID goes into the selector header T=1 and > classifier specific selector bits such as the hashing bits goes > into T=2. Thinking of it it's probably cleaner to put things like > hmark, hoff into its own TLV. So the selector TLV contains the > selector header at T=1 and nested ematch TLVs at T=2..T=N. > Note that the ematch is supposed to be a very very simple thing... Something a fireman who has implemented a iptables target can whip in an hour. Keep in mind that design goal. Non trivial coding needed or poor usability is the major problem with tc in general. Avoid that theme. An ematch _needs_ a mother classifier such as u32. u32 has a very nice and very flexible layout - it can be trained to build any sort of tree. Maybe the first step should be to not even have u32 as an ematch .. > I think we're mostly in sync so I'll start working on it and > we can review again. Maybe i will wait for the code. cheers, jamal From hadi@cyberus.ca Sat Jan 1 15:25:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 15:25:32 -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 j01NP40I013117 for ; Sat, 1 Jan 2005 15:25:25 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Ckskc-0001WZ-KJ for netdev@oss.sgi.com; Sat, 01 Jan 2005 18:33:38 -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 1CkskV-0004gd-1u; Sat, 01 Jan 2005 18:33:31 -0500 Subject: Re: patch: tunnels not setting inputdev From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com, Wichert Akkerman In-Reply-To: <41D6CB87.8040205@trash.net> References: <1104513392.1048.316.camel@jzny.localdomain> <41D5941C.8060001@trash.net> <1104523892.1047.338.camel@jzny.localdomain> <41D6CB87.8040205@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104622406.1049.450.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Jan 2005 18:33:27 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13320 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 Sat, 2005-01-01 at 11:10, Patrick McHardy wrote: > jamal wrote: > > >>For the remaining changes, why not simply set > >>input_dev in netif_receive_skb before the call to ing_filter ? > > > > You want to be able to filter on indev at ingress - it is safer for > > whoever calls netif_rx() to do the setting. The packet could be looped > > from egress multiple times as well (redirected). > > Currently input_dev is set in eth_type_trans, ppp_generic and the > mirred action. With your patch we have a couple of drivers more, I want to understand the repurcasssions instead of blindly setting. Let users complain, thats why the printk exists. For example what does input_dev mean for netbios or a 802.3ad interface? You already saw one, xfrm, where there was no need to reset. > but this still leaves lots of non-ethernet drivers that don't set > input_dev. A centralized solutions seems much better to me than > adding this to every single driver. Ethernet like, ppp-like and now tunnel-like. If you note on my email with the patch i said: "A lot of the stuff the tunnels do is very similar, so maybe wiser to have something like tunnel_type_trans()." This includes things like nf_reset(skb) which is done by that family of devices that may need centralizing. If you want to create such a patch go ahead and i will hold mine. > I can't see the problem with > redirected packets, just set skb->input_dev = skb->dev in > netif_receive_skb, this should have exactly the same effect as > setting it in the drivers or the mirred action. > in some cases the pointers are swapped. You cant just blindly set skb->input_dev = skb->dev at the input - that would be violating the intent; think reinjecting packets (and look at mirred as a sample of apps to come that do this). cheers, jamal From hadi@cyberus.ca Sat Jan 1 15:34:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 15:34:13 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j01NXk3l013695 for ; Sat, 1 Jan 2005 15:34:06 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Ckst2-0008Lx-Tk for netdev@oss.sgi.com; Sat, 01 Jan 2005 18:42:20 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Ckst0-000661-Oj; Sat, 01 Jan 2005 18:42:19 -0500 Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050101183230.GT32419@postel.suug.ch> References: <20041229150140.GJ32419@postel.suug.ch> <1104335620.1025.22.camel@jzny.localdomain> <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101183230.GT32419@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104622934.1047.460.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Jan 2005 18:42:14 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13321 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 Sat, 2005-01-01 at 13:32, Thomas Graf wrote: > OK, I changed my mind while implementing it and a selector now looks > like this: > > Selector TLV: > > +----------------------------+ > | TCA_EMATCH_TREE_HDR | > +----------------------------+ > | TCA_EMATCH_TREE_LIST | > | +------------------------+ | > | | T=1 Match 1 | | > | +------------------------+ | > | | T=2 Match 2 | | > | +------------------------+ | > | | T=N Match N | | > | +------------------------+ | > +----------------------------+ > what happened to the good old SEL TLV (which i believe we called SEL2 now); or maybe thats what contains this TLV? > So we can put more into the selector if needed without breaking > compatibility. TCA_EMATCH_TREE_HDR currently contains `nmatches' > specifying N and progid holding the PID you talked about. Ok, so i think you may be saying the old selector stays intact then (sans the matches)? Why do you need to specify "nmatches". You know exactly where each one starts and ends (from the TLVs). What is TCA_EMATCH_TREE_LIST for? Looks like another TLV nesting. Not needed, you just plumb the T=1,..T=N right after the header. > The match TLVs must have a continous numbering because I don't > want to define limits as done in the action code. I think the way you have it is fine - and believe it is the way the action code has it for the list. > I'll post an RFC patch tomorrow implementing the API and a > simple ematch. Nice. I have started implementing the eaction code but too obsessed with this other thing i am working on - hopefully i will get to it before my vacation expires. cheers, jamal From tgraf@suug.ch Sat Jan 1 15:57:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 15:57:47 -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 j01NvIm0014428 for ; Sat, 1 Jan 2005 15:57:39 -0800 Received: from postel.suug.ch (unknown [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 CA041F; Sun, 2 Jan 2005 01:05:30 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 942A91C0EA; Sun, 2 Jan 2005 01:06:12 +0100 (CET) Date: Sun, 2 Jan 2005 01:06:12 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. Message-ID: <20050102000612.GU32419@postel.suug.ch> References: <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101121041.GR32419@postel.suug.ch> <1104622164.1048.444.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104622164.1048.444.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13322 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 * jamal <1104622164.1048.444.camel@jzny.localdomain> 2005-01-01 18:29 > Does the ematch API include a dump()? I dont think it should - thats the > point i was making. Should be simple. Yes, although simple ematches are not required to implement dump. > > [validate] > Even this is too much for a simple ematch. Validation should happen in > user space or maybe at the mother clasifier. maybe a maxsize,minsize > attribute is needed in the ematch struct. > > [replace] > Equivalent of this should be done by the mother classifier. > All it needs to know is the length (and no other details). And the > length is known from the L in TLV. I merged validate/replace into change which takes a unsigned long for storage and a data/len parameter. It's up to the ematch what he does with it, data may contain a u32 directly and the ematch might save it in the unsigned long or a ematch may allocate a structure. Why are you focused on hiding so much? I'd rather try to make it simple but still allow more complex ematches to exist. Have a look at http://people.suug.ch/~tgr/tmp/ematch.diff I broke the API down to: change match destroy (optional, only for complex ematches) dump (optional, only for complex ematches) > Even at the moment classifiers dont have stats. If you want stats > you could add a simple gact accept action. > Note also: think of the 100K rules being added and amount of RAM used; Agreed, I didn't add them so far, it's up to the ematch whether it wants to maintain stats or not. > Note that the ematch is supposed to be a very very simple thing... > Something a fireman who has implemented a iptables target can whip in an > hour. Keep in mind that design goal. Non trivial coding needed or poor > usability is the major problem with tc in general. Avoid that theme. > An ematch _needs_ a mother classifier such as u32. u32 has a very nice > and very flexible layout - it can be trained to build any sort of tree. > Maybe the first step should be to not even have u32 as an ematch .. I understand your point but I want to at least be able to implement some more complex stuff. Hiding too much can be bad too. Having only 2 functions to implement is really easy, the rest can be done the LinuxWay(tm) ;-> Have a look at the code and tell me what you think. Here's an example ematch, I find this quite simple already. static in foo_change(struct tcf_proto *tp, void *data, int len, struct tcf_ematch *m) { if (len != sizeof(u32)) return -EINVAL; m->data = *(u32*)data; return 0; } static int foo_match(struct sk_buff *skb, struct tcf_ematch *m) { return skb->security == m->data; } static struct tcf_ematch_ops foo_ops = { .kind = 111, .change = foo_change, .match = foo_match, .owner = THIS_MODULE, .link = LIST_HEAD_INIT(foo_ops.link) } static int __init foo_init(void) { return tcf_ematch_register(&foo_ops); } static void __exit foo_exit(void) { return tcf_ematch_unregister(&foo_ops); } module_init(init_foo); module_exit(exit_foo); From tgraf@suug.ch Sat Jan 1 16:05:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 16:05:10 -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 j0204gZi015018 for ; Sat, 1 Jan 2005 16:05:03 -0800 Received: from postel.suug.ch (unknown [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 3F70EF; Sun, 2 Jan 2005 01:12:55 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 5AFCF1C0EA; Sun, 2 Jan 2005 01:13:38 +0100 (CET) Date: Sun, 2 Jan 2005 01:13:38 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. Message-ID: <20050102001338.GV32419@postel.suug.ch> References: <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101183230.GT32419@postel.suug.ch> <1104622934.1047.460.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104622934.1047.460.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13323 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 * jamal <1104622934.1047.460.camel@jzny.localdomain> 2005-01-01 18:42 > what happened to the good old SEL TLV (which i believe we called SEL2 > now); or maybe thats what contains this TLV? Please look at the patch I posted in the other post. I think we missudnerstand each other. > > So we can put more into the selector if needed without breaking > > compatibility. TCA_EMATCH_TREE_HDR currently contains `nmatches' > > specifying N and progid holding the PID you talked about. > > Ok, so i think you may be saying the old selector stays intact then > (sans the matches)? Right, old selector TLV statys as-is. Although I have to look u32 closely before I can make final statements. > Why do you need to specify "nmatches". It's mainly a shortcut to validate precedence jumps so I can avoid traversing the RTA chain twice. It could be avoided but is quite handy to speed things up and also acts for validation purposes to check consistency of the match list. > What is TCA_EMATCH_TREE_LIST for? Looks like another TLV nesting. Not > needed, you just plumb the T=1,..T=N right after the header. No, what if we need some more stuff in the selector TLV? We can't modify the header TLV w/o breaking backwards compatibility. Adding this addtional nesting allows to simply add stuff after TREE_LIST TLV. > I think the way you have it is fine - and believe it is the way the > action code has it for the list. You're using a maximum prio aren't you? I use a RTA_OK() loop supporting unlimited number of matches without the need to allocate rtattr pointer array. From kaber@trash.net Sat Jan 1 16:17:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 16:17:42 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j020HBC1015722 for ; Sat, 1 Jan 2005 16:17:35 -0800 Received: from eru.coreworks.de ([172.16.0.2] helo=trash.net) by kaber.coreworks.de with esmtp (Exim 4.34) id 1CktYo-0006yJ-Jr; Sun, 02 Jan 2005 01:25:31 +0100 Message-ID: <41D73F28.3090206@trash.net> Date: Sun, 02 Jan 2005 01:24:08 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , netdev@oss.sgi.com, Wichert Akkerman Subject: Re: patch: tunnels not setting inputdev References: <1104513392.1048.316.camel@jzny.localdomain> <41D5941C.8060001@trash.net> <1104523892.1047.338.camel@jzny.localdomain> <41D6CB87.8040205@trash.net> <1104622406.1049.450.camel@jzny.localdomain> In-Reply-To: <1104622406.1049.450.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev jamal wrote: > I want to understand the repurcasssions instead of blindly setting. Let > users complain, thats why the printk exists. For example what does > input_dev mean for netbios or a 802.3ad interface? You already saw one, > xfrm, where there was no need to reset. What's special about netbios ? For 802.3ad, I would expect input_dev to hold the virtual device through which the packet entered the stack, just what iptables -i would match. For xfrm - there is no need but its also not wrong. >>I can't see the problem with >>redirected packets, just set skb->input_dev = skb->dev in >>netif_receive_skb, this should have exactly the same effect as >>setting it in the drivers or the mirred action. > > in some cases the pointers are swapped. You cant just blindly > set skb->input_dev = skb->dev at the input - that would be violating the > intent; think reinjecting packets (and look at mirred as a sample of > apps to come that do this). I don't know your intent, but I assumed it was to match the incoming interface as the networking stack sees it. Why would the pointers be swapped ? Please give me an example. mirred does: skb2->dev = dev; skb2->input_dev = skb->dev; So on input input_dev is the incoming interface of the original packet, on output it is the outgoing interface of the original packet. Doesn't make much sense to me, the original packet came the same way both times. Regards Patrick From y030729@njupt.edu.cn Sat Jan 1 18:15:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 18:15:45 -0800 (PST) Received: from njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j022FH0I021906 for ; Sat, 1 Jan 2005 18:15:38 -0800 Received: (eyou send program); Sun, 02 Jan 2005 11:17:09 +0800 Message-ID: <304635829.27548@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Sun, 02 Jan 2005 11:17:09 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: netdev@oss.sgi.com Cc: lartc@mailman.ds9a.nl, tgraf@suug.ch Date: Sun, 02 Jan 2005 11:17:09 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: A Question On CBQ Content-Type: text/plain X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: y030729@njupt.edu.cn Precedence: bulk X-list: netdev Hello, As it is well know that CBQ is the class based queue. But i am confused on the word "class" now, especially it is used in Diffserv. IMO, different classes should mean that there are different kinds of traffics, so the class should be difined by the parameters (such as bandwidth, priority..) the traffic wanted. That is, using cbq we can define different kinds of traffics which need different bandwidth at the gateway, am i right?? Then, in diffserv the traffic is identified by the DSCP, right? From Floyd's paper Link-sharing and Resource Management Models for Packet Networks, we can see if there are two classes of traffic such as class A and class B, and each of them has traffics video and ftp, then how the two different FTP are identified in diffserv, by their DSCP? IMO, at first, according to the bandwidth the traffic needed, the traffic is classified into class A or class B, then at each class the traffic is identified by their DSCP. Eagerly waiting for your reply! Happy New Year! From mgalgoci@parcelfarce.linux.theplanet.co.uk Sat Jan 1 22:04:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 22:04:36 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02644De030495 for ; Sat, 1 Jan 2005 22:04:27 -0800 Received: from [127.0.0.1] (helo=localhost) by www.linux.org.uk with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Ckyyk-0003Fo-Uj for netdev@oss.sgi.com; Sun, 02 Jan 2005 06:12:39 +0000 Date: Sun, 2 Jan 2005 06:12:38 +0000 (GMT) From: Matthew J Galgoci To: netdev@oss.sgi.com Subject: 2.6.10-bk4 ip_conntrack oops fix Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mgalgoci@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: netdev I stumbled onto an annoying oops in 2.6.10-bk4. Here is how to cause the oops. load ip_conntrack remove ip_conntrack ls /proc/net/stat boom Here is what I think the fix is: --- linux-2.6.10-bk4/net/ipv4/netfilter/ip_conntrack_standalone.c.orig 2005-01-01 23:44:42.000000000 -0500 +++ linux-2.6.10-bk4/net/ipv4/netfilter/ip_conntrack_standalone.c 2005-01-02 00:57:20.000000000 -0500 @@ -820,7 +820,7 @@ nf_unregister_hook(&ip_conntrack_defrag_ops); cleanup_proc_stat: #ifdef CONFIG_PROC_FS - proc_net_remove("ip_conntrack_stat"); + remove_proc_entry("ip_conntrack", proc_net_stat); cleanup_proc_exp: proc_net_remove("ip_conntrack_expect"); cleanup_proc: From shekhark@juniper.net Sat Jan 1 22:43:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Jan 2005 22:43:12 -0800 (PST) Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j026gj9a031878 for ; Sat, 1 Jan 2005 22:43:05 -0800 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 01 Jan 2005 22:51:15 -0800 X-BrightmailFiltered: true X-Ironport-AV: i="3.88,96,1102320000"; d="scan'208"; a="86393475:sNHT19204476" Received: from gluon.jnpr.net ([172.24.15.23]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 1 Jan 2005 22:51:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ipsec null encryption slower than AES / was Re: 2.6 IPSec Throughput puzzle Date: Sat, 1 Jan 2005 22:51:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipsec null encryption slower than AES / was Re: 2.6 IPSec Throughput puzzle Thread-Index: AcTwRXsiJ+Iw7jziRpSFpNj9LgAvnAATxiJX From: "Shekhar Kshirsagar" To: "bert hubert" Cc: "Networking Team" , X-OriginalArrivalTime: 02 Jan 2005 06:51:14.0798 (UTC) FILETIME=[73DFA0E0:01C4F097] X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j026gj9a031878 X-archive-position: 13327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shekhark@juniper.net Precedence: bulk X-list: netdev > From your numbers below it is clear all ipsec benchmarks have maxed out your > CPU, but aes/sha1 still has some hits in default_idle. Is this an SMP > system? No, it is not running SMP kernel. (The system is SMP). About little time being sent in default_idle, I think,it was because I was little late in performing dump. I redid the test and the CPU was maxed out even in aes/sha1 case. > http://www.certconf.org/presentations/2004/Tuesday/TS2.pdf - the concept is > called 'the scatterlist'. > http://lwn.net/Articles/14010/?format=printable is also nice. Thanks, for the pointers. I will see, if I can isolate the problem. Shekhar From pb@bieringer.de Sun Jan 2 00:53:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 00:53:19 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j028qpUg006071 for ; Sun, 2 Jan 2005 00:53:12 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 07BA7137F1; Sun, 2 Jan 2005 10:01:24 +0100 (CET) X-AV-Checked: Sun Jan 2 10:01:24 2005 smtp2.aerasec.de Received: from [192.168.1.2] (pD9E4EFC7.dip.t-dialin.net [217.228.239.199]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id 63403137EA; Sun, 2 Jan 2005 10:01:22 +0100 (CET) Date: Sun, 02 Jan 2005 10:01:20 +0100 From: Peter Bieringer To: Patrick McHardy Cc: USAGI core , Maillist netdev , Harald Welte , Netfilter development mailing list Subject: Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches Message-ID: <85346B5DA83795C08812E782@worker.muc.bieringer.de> In-Reply-To: <41CD8B4F.6010402@trash.net> References: <019064D0423CE6C823CBF476@t1mobil.muc.aerasec.de> <5F6ACA5CEF52DBFBF11FBF94@t1mobil.muc.aerasec.de> <41CD8B4F.6010402@trash.net> X-Mailer: Mulberry/3.1.6 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Hi, --On Saturday, December 25, 2004 04:46:23 PM +0100 Patrick McHardy wrote: > Peter Bieringer wrote: >> Looks like there is something going wrong in the protocol matching >> algorithm in netfilter6. > > Does this patch fix the problem ? > > Regards > Patrick Yes, this patch fix the problem on the incoming side: I ping6 to a remote host via IPsec in transport mode: IPv6 INPUT chain: 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 128 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 129 1 156 ACCEPT esp * * remote/128 local/128 0 0 ACCEPT all * * remote/128 local/128 So the proper chain matches. But I wonder a little bit because of the result of the OUTPUT chain: 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 129 1 104 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 128 0 0 ACCEPT esp * * local/128 remote/128 0 0 ACCEPT all * * local/128 remote/128 Here, the ICMPv6 rule matches. This means for me that the traffic goes like this: OUTPUT: ping6 -> netfilter -> encryption -> ESP INPUT : ESP -> netfilter -> decryption -> ping6 Is this logical? BTW: how to filter incoming traffic after decryption? Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From pb@bieringer.de Sun Jan 2 01:04:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 01:04:46 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0294JP0006820 for ; Sun, 2 Jan 2005 01:04:40 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 8E460137EA; Sun, 2 Jan 2005 10:12:53 +0100 (CET) X-AV-Checked: Sun Jan 2 10:12:53 2005 smtp2.aerasec.de Received: from [192.168.1.2] (pD9E4EFC7.dip.t-dialin.net [217.228.239.199]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id C6EFE137F1; Sun, 2 Jan 2005 10:12:44 +0100 (CET) Date: Sun, 02 Jan 2005 10:12:42 +0100 From: Peter Bieringer To: "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" , yasuyuki.kozakai@toshiba.co.jp Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org, laforge@gnumonks.org, kaber@trash.net, netfilter-devel@lists.netfilter.org Subject: Re: netfilter6: ICMPv6 type 143 doesn't match (130 also not) Message-ID: <44BA844FEB4A052700F3C77E@worker.muc.bieringer.de> In-Reply-To: <20041227.100205.102356251.yoshfuji@linux-ipv6.org> References: <6050E336B1A0D7D8E70C66F3@t1mobil.muc.aerasec.de> <200412270417.iBR4HZRG021429@toshiba.co.jp> <20041227.100205.102356251.yoshfuji@linux-ipv6.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Hi, --On Monday, December 27, 2004 10:02:05 AM +0100 "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" wrote: > In article <200412270417.iBR4HZRG021429@toshiba.co.jp> (at Mon, 27 Dec > 2004 13:17:34 +0900 (JST)), Yasuyuki Kozakai > says: > >> >> - ptr = IPV6_HDR_LEN; >> + ptr = ((u8*)skb->nh.ipv6h - skb->data) + IPV6_HDR_LEN; >> > > IMHO, skb->nh.ipv6h does not points ipv6 header anymore; > it should be skb->nh.raw in this case. > > --yoshfuji Can someone pls. provide me a patch for kernel version 2.6.9? If so, I would run tests. BTW: at the moment, I have an additional packet where no ICMPv6 rule matches: Jan 2 10:04:15 gate kernel: default-drop-extIN:IN=sit1 OUT= MAC=53:2e:55:**:**:**->00:00:65:**:**:** TUNNEL=212.224. 0.188->217.228.***.*** SRC=fe80:0000:0000:0000:0000:0000:d4e0:00bc DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=76 TC=0 HOPLIMIT=1 FLOWLBL=0 OPT ( ) PROTO=ICMPv6 TYPE=130 CODE=0 10:08:25.540037 fe80::d4e0:bc > ff02::1: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1] 0x0000: 6000 0000 0024 0001 fe80 0000 0000 0000 `....$.......... 0x0010: 0000 0000 d4e0 00bc ff02 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 3a00 0502 0000 0100 ........:....... 0x0030: 8200 a03a 07d0 0000 0000 0000 0000 0000 ...:............ 0x0040: 0000 0000 0000 0000 027d 0000 .........}.. # ip6tables -vnL INPUT --line-num Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT icmpv6 * * ::/0 fe80::/10 ipv6-icmp type 136 HL match HL == 255 2 0 0 ACCEPT icmpv6 * * ::/0 ff02::1:ff00:1/128 ipv6-icmp type 135 HL match HL == 255 3 0 0 ACCEPT icmpv6 * * ::/128 fe80::/10 ipv6-icmp type 135 HL match HL == 255 4 0 0 ACCEPT icmpv6 * * fe80::/10 ::/0 ipv6-icmp type 135 HL match HL == 255 5 4 384 ACCEPT icmpv6 * * fe80::/10 ff02::1/128 ipv6-icmp type 134 HL match HL == 255 6 0 0 ACCEPT icmpv6 * * fe80::/10 fe80::/10 ipv6-icmp type 133 HL match HL == 255 7 0 0 ACCEPT icmpv6 * * fe80::/10 ff02::1/128 ipv6-icmp type 130 HL match HL == 1 8 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 4 9 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 3 10 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 2 11 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 1 Expected: match of rule 7 Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From gandalf@wlug.westbo.se Sun Jan 2 01:57:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 01:57:34 -0800 (PST) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j029v5pm008386 for ; Sun, 2 Jan 2005 01:57:26 -0800 Received: by null.rsn.bth.se (Postfix, from userid 65534) id D53E32C0007; Sun, 2 Jan 2005 11:05:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id 8A7E92C002D; Sun, 2 Jan 2005 11:05:33 +0100 (CET) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id CD5492C0007; Sun, 2 Jan 2005 11:05:32 +0100 (CET) Received: by tux.rsn.bth.se (Postfix, from userid 501) id 062253F79; Sun, 2 Jan 2005 11:05:32 +0100 (CET) Subject: Re: 2.6.10-bk4 ip_conntrack oops fix From: Martin Josefsson To: Matthew J Galgoci Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-t7qNmEHVwCYZzqHnTZvU" Date: Sun, 02 Jan 2005 11:05:32 +0100 Message-Id: <1104660332.3821.40.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by amavisd-new-20030616-p10 on null.rsn.bth.se X-Virus-Status: Clean X-archive-position: 13330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev --=-t7qNmEHVwCYZzqHnTZvU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-01-02 at 06:12 +0000, Matthew J Galgoci wrote: > I stumbled onto an annoying oops in 2.6.10-bk4. >=20 > Here is how to cause the oops. >=20 > load ip_conntrack > remove ip_conntrack > ls /proc/net/stat > boom Thanks for the fix, a patch for this has already been submitted. Hopefully it'll make it's way into the tree soon, The hollidays and vacations is making the process a bit sluggish at the moment. --=20 /Martin --=-t7qNmEHVwCYZzqHnTZvU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB18dsWm2vlfa207ERAp+UAKCjWidLHkboST3L0uLOp6zGHZ0wFgCfW0g3 19ViKWGchnRiP9dwpuLiOrU= =RPkS -----END PGP SIGNATURE----- --=-t7qNmEHVwCYZzqHnTZvU-- From linux_lover2004@yahoo.com Sun Jan 2 03:09:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 03:09:53 -0800 (PST) Received: from web52204.mail.yahoo.com (web52204.mail.yahoo.com [206.190.39.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j02B9PU5012300 for ; Sun, 2 Jan 2005 03:09:45 -0800 Received: (qmail 8758 invoked by uid 60001); 2 Jan 2005 11:17:55 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ocMxXZkMLOIXw+DcQhwF8XlRUmgVKvCPsbkBhKCaFQxd8y4mhW3G4JvLVNQqImBRRcHn9QCigdubNfg5z3h2jOhxWXHBPTSxCiKSgGuNN8fwPNcshy6q9/D15pmt8gSoZ76arFwhduLMP9iRhX45CbOPWVtZ6amg1579VZ7bChA= ; Message-ID: <20050102111755.8756.qmail@web52204.mail.yahoo.com> Received: from [202.56.231.117] by web52204.mail.yahoo.com via HTTP; Sun, 02 Jan 2005 03:17:55 PST Date: Sun, 2 Jan 2005 03:17:55 -0800 (PST) From: linux lover Subject: what is mean by linear socket buffers? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Hello, On Internet i found one document that states following statement "Linux chooses to use linear buffers and save space in advance because linear buffers make many other things much faster." I want to know what is linear buffers? are they different than what we declare in normal C programming syntax unsigned char *str. regards, linux_lover. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From kaber@trash.net Sun Jan 2 03:35:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 03:35:55 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02BZRVR013230 for ; Sun, 2 Jan 2005 03:35:47 -0800 Received: from eru.coreworks.de ([172.16.0.2] helo=trash.net) by kaber.coreworks.de with esmtp (Exim 4.34) id 1Cl49h-0007Qy-FW; Sun, 02 Jan 2005 12:44:17 +0100 Message-ID: <41D7DE3E.2090304@trash.net> Date: Sun, 02 Jan 2005 12:42:54 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Peter Bieringer CC: USAGI core , Maillist netdev , Harald Welte , Netfilter development mailing list Subject: Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches References: <019064D0423CE6C823CBF476@t1mobil.muc.aerasec.de> <5F6ACA5CEF52DBFBF11FBF94@t1mobil.muc.aerasec.de> <41CD8B4F.6010402@trash.net> <85346B5DA83795C08812E782@worker.muc.bieringer.de> In-Reply-To: <85346B5DA83795C08812E782@worker.muc.bieringer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Peter Bieringer wrote: >>Does this patch fix the problem ? >> > Yes, this patch fix the problem on the incoming side: Thanks. > > I ping6 to a remote host via IPsec in transport mode: > > IPv6 INPUT chain: > > 0 0 ACCEPT icmpv6 * * ::/0 ::/0 > ipv6-icmp type 128 > 0 0 ACCEPT icmpv6 * * ::/0 ::/0 > ipv6-icmp type 129 > 1 156 ACCEPT esp * * remote/128 local/128 > 0 0 ACCEPT all * * remote/128 local/128 > > > So the proper chain matches. > > > But I wonder a little bit because of the result of the OUTPUT chain: > > 0 0 ACCEPT icmpv6 * * ::/0 ::/0 > ipv6-icmp type 129 > 1 104 ACCEPT icmpv6 * * ::/0 ::/0 > ipv6-icmp type 128 > 0 0 ACCEPT esp * * local/128 remote/128 > 0 0 ACCEPT all * * local/128 remote/128 > > > Here, the ICMPv6 rule matches. > > This means for me that the traffic goes like this: > > OUTPUT: ping6 -> netfilter -> encryption -> ESP > INPUT : ESP -> netfilter -> decryption -> ping6 More specific, with transport mode it goes: OUTPUT: ping6 -> LOCAL_OUT -> encryption -> POST_ROUTING INPUT: ESP -> PRE_ROUTING -> LOCAL_IN -> decryption -> ping6 Filtering for IPv6 happens on LOCAL_IN/LOCAL_OUT (and FORWARD). > Is this logical? Not very. Patches to improve this for IPv4 will be submitted next week, but IPv6 still needs some work. > > BTW: how to filter incoming traffic after decryption? Use tunnel-mode. The decrypted packets will hit PRE_ROUTING and LOCAL_IN again. Regards Patrick From ahu@outpost.ds9a.nl Sun Jan 2 04:05:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 04:05:44 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02C5FhS014608 for ; Sun, 2 Jan 2005 04:05:35 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7CD1D441A; Sun, 2 Jan 2005 13:13:49 +0100 (CET) Date: Sun, 2 Jan 2005 13:13:49 +0100 From: bert hubert To: jamal Cc: Wichert Akkerman , netdev@oss.sgi.com Subject: Re: unregister_netdev Annoyance WAS(Re: ing_filter debug messages Message-ID: <20050102121349.GA27022@outpost.ds9a.nl> Mail-Followup-To: bert hubert , jamal , Wichert Akkerman , netdev@oss.sgi.com References: <20041230160643.GD24603@wiggy.net> <1104469666.1049.231.camel@jzny.localdomain> <20041231093827.GG24603@wiggy.net> <1104491510.1047.234.camel@jzny.localdomain> <20041231131553.GA7460@wiggy.net> <1104505838.1048.273.camel@jzny.localdomain> <20041231154844.GA11511@wiggy.net> <1104511697.1048.308.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104511697.1048.308.camel@jzny.localdomain> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev > > However, the unregister_netdev problem still persists. > > I am pretty sure its a different problem. Quick scan shows the > register/unregister state machine may be at fault. This is a separate and known problem - see 'Re: Major deadlock: unregister_netdevice: waiting for to become free. Usage count = 1' by Peter Bieringer. For some reason this issue has been widely ignored. I see it as well here and it is the one reason I don't entirely trust 2.6.10 yet in production. Thanks for looking into it Jamal! -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From pb@bieringer.de Sun Jan 2 04:07:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 04:07:47 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02C7FRF014929 for ; Sun, 2 Jan 2005 04:07:35 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id CD4AA137F1; Sun, 2 Jan 2005 13:15:48 +0100 (CET) X-AV-Checked: Sun Jan 2 13:15:48 2005 smtp2.aerasec.de Received: from [192.168.1.2] (pD9E4EFC7.dip.t-dialin.net [217.228.239.199]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id D52BA137EA; Sun, 2 Jan 2005 13:15:45 +0100 (CET) Date: Sun, 02 Jan 2005 13:15:42 +0100 From: Peter Bieringer To: Patrick McHardy Cc: USAGI core , Maillist netdev , Harald Welte , Netfilter development mailing list Subject: Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches Message-ID: In-Reply-To: <41D7DE3E.2090304@trash.net> References: <019064D0423CE6C823CBF476@t1mobil.muc.aerasec.de> <5F6ACA5CEF52DBFBF11FBF94@t1mobil.muc.aerasec.de> <41CD8B4F.6010402@trash.net> <85346B5DA83795C08812E782@worker.muc.bieringer.de> <41D7DE3E.2090304@trash.net> X-Mailer: Mulberry/3.1.6 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev --On Sunday, January 02, 2005 12:42:54 PM +0100 Patrick McHardy wrote: >> But I wonder a little bit because of the result of the OUTPUT chain: >> >> 0 0 ACCEPT icmpv6 * * ::/0 ::/0 >> ipv6-icmp type 129 >> 1 104 ACCEPT icmpv6 * * ::/0 ::/0 >> ipv6-icmp type 128 >> 0 0 ACCEPT esp * * local/128 remote/128 >> 0 0 ACCEPT all * * local/128 remote/128 >> >> >> Here, the ICMPv6 rule matches. >> >> This means for me that the traffic goes like this: >> >> OUTPUT: ping6 -> netfilter -> encryption -> ESP >> INPUT : ESP -> netfilter -> decryption -> ping6 > > More specific, with transport mode it goes: > > OUTPUT: ping6 -> LOCAL_OUT -> encryption -> POST_ROUTING > INPUT: ESP -> PRE_ROUTING -> LOCAL_IN -> decryption -> ping6 > > Filtering for IPv6 happens on LOCAL_IN/LOCAL_OUT (and FORWARD). > >> Is this logical? > > Not very. Patches to improve this for IPv4 will be submitted > next week, but IPv6 still needs some work. > >> >> BTW: how to filter incoming traffic after decryption? > > Use tunnel-mode. The decrypted packets will hit PRE_ROUTING > and LOCAL_IN again. Ok, confirmed working in tunnel mode, ping6 packet was counted twice in different rules (esp and icmpv6) But for outgoing ping6 packets, this won't work, packet is only counted (and accepted) by the icmpv6 rule, esp rule got no match, also not the "all" rule. Looks like at the moment, outgoing packet is passing netfilter only one time, even if encryption is in tunnel mode. By design / bug / missing feature? Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From rich@phekda.gotadsl.co.uk Sun Jan 2 05:42:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 05:42:32 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02DfvPQ026524 for ; Sun, 2 Jan 2005 05:42:17 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (unknown [84.12.62.218]) by smtp.nildram.co.uk (Postfix) with ESMTP id 0A06D251692; Sun, 2 Jan 2005 13:50:26 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 5A3BA355; Sun, 2 Jan 2005 13:51:21 +0000 (GMT) Message-ID: <41D7FC59.2040503@phekda.gotadsl.co.uk> Date: Sun, 02 Jan 2005 13:51:21 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Me Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41A09541.5040405@phekda.gotadsl.co.uk> <41A0F0D5.9050702@phekda.gotadsl.co.uk> <20041121205814.GA22460@electric-eye.fr.zoreil.com> <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> In-Reply-To: <20041229235203.GA5465@electric-eye.fr.zoreil.com> Content-Type: multipart/mixed; boundary="------------090209010003000801020701" X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------090209010003000801020701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. Francois Romieu wrote: > Richard Dawe : > [...] > >>IRQ routing seems to be disabled in 2.6.10. I got a warning about an >>unhandled interrupt for the VIA 8255 (I think that's the right number) >>on shutdown. I'm wondering if there is some bad interaction between the >>VIA chipset and the 8110 chipset. > > > Possible. I hope the networking does not perform better when you are > listening to music. No, it doesn't. I even built a kernel with no sound support, but this had the same problems. In this case /proc/interrupts showed that there was no driver handling the interrupts for the VIA 8233 sound chip. [snip] > Could you send an updated dmesg, lspci -vvx, /proc/interrupts please ? Please see the attached, which are for running with 2.6.10. I included .config, Just In Case. > Did you remove the other OS from the laptop ? I'd be curious to know > if it can teach us something. I removed Windows XP Home. I only have Fedora Core 3 on it. I've spoken with someone else who's had problems with Acer laptops and networking. He has the laptop mentioned on this page: http://www.latzinator.com/acer_aspire_1705SMi.html Apparently it works fine with FreeBSD 5.3, even booting from cold. So this seems like a Linux ACPI-specific problem. Note that the 1705SMi is a Pentium IV-based laptop. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek --------------090209010003000801020701 Content-Type: text/plain; name="2.6.10-dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.10-dmesg.txt" Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00) Linux version 2.6.9-1.678_FC3 (bhcompile@dolly.build.redhat.com) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Mon Nov 15 18:27:45 EST 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000d8000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001ff70000 (usable) BIOS-e820: 000000001ff70000 - 000000001ff7a000 (ACPI data) BIOS-e820: 000000001ff7a000 - 000000001ff80000 (ACPI NVS) BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved) BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved) No mptable found. On node 0 totalpages: 130928 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126832 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 PTLTD ) @ 0x00000000000f6a60 ACPI: RSDT (v001 PTLTD RSDT 0x06040000 LTP 0x00000000) @ 0x000000001ff73fbd ACPI: FADT (v002 AMDK8 PTLTW 0x06040000 PTL_ 0x000f4240) @ 0x000000001ff79e35 ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x000000001ff79eb9 ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @ 0x000000001ff79fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x06040000 MSFT 0x0100000e) @ 0x0000000000000000 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ d0000000 size 256 MB Built 1 zonelists Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=tty0 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 65536 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 2201.330 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Memory: 508340k/523712k available (2403k kernel code, 14612k reserved, 1285k data, 164k init) Calibrating delay loop... 4325.37 BogoMIPS (lpj=2162688) Security Scaffold v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode There is already a security framework initialized, register_security failed. selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3400+ stepping 0a Using local APIC NMI watchdog using perfctr0 Using local APIC timer interrupts. Detected 12.507 MHz APIC timer. checking if image is initramfs... it is NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040816 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10 ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: Embedded Controller [EC] (gpe 11) usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 21 (level, low) -> IRQ 169 ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 17 (level, low) -> IRQ 177 ACPI: PCI interrupt 0000:00:0b.1[B] -> GSI 18 (level, low) -> IRQ 185 ACPI: PCI interrupt 0000:00:0b.2[C] -> GSI 19 (level, low) -> IRQ 193 ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 22 (level, low) -> IRQ 201 ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 169 ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 21 (level, low) -> IRQ 169 ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 21 (level, low) -> IRQ 169 ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 21 (level, low) -> IRQ 169 ACPI: PCI interrupt 0000:00:11.1[A]: no GSI ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 201 ACPI: PCI interrupt 0000:00:11.6[C] -> GSI 22 (level, low) -> IRQ 201 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 209 agpgart: Detected AGP bridge 0 agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 256M @ 0xd0000000 PCI-DMA: Disabling IOMMU. IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $ audit: initializing netlink socket (disabled) audit(1104670420.329:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key A523A41F30C2FAFE - User ID: Red Hat, Inc. (Kernel Module GPG key) PCI: Via IRQ fixup for 0000:00:10.0, from 0 to 9 PCI: Via IRQ fixup for 0000:00:10.1, from 0 to 9 PCI: Via IRQ fixup for 0000:00:10.2, from 0 to 9 PCI: Via IRQ fixup for 0000:00:11.6, from 11 to 9 pci_hotplug: PCI Hot Plug PCI Core version: 0.5 vesafb: probe of vesafb0 failed with error -6 ACPI: Processor [CPU0] (supports C1) ACPI: Thermal Zone [THRS] (18 C) ACPI: Thermal Zone [THRC] (38 C) Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize divert: not allocating divert_blk for non-ethernet device lo Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:11.1 ACPI: PCI interrupt 0000:00:11.1[A]: no GSI VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1 ide0: BM-DMA at 0x1c80-0x1c87, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1c88-0x1c8f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: IC25N060ATMR04-0, ATA DISK drive Using cfq io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: TSSTcorpCD/DVDW TS-L532A, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... ide2: Wait for ready failed before probe ! Probing IDE interface ide3... ide3: Wait for ready failed before probe ! Probing IDE interface ide4... ide4: Wait for ready failed before probe ! Probing IDE interface ide5... ide5: Wait for ready failed before probe ! hda: max request size: 1024KiB hda: 117210240 sectors (60011 MB) w/7884KiB Cache, CHS=16383/255/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 ide-floppy driver 0.99.newide usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 Synaptics Touchpad, model: 1 Firmware: 5.8 180 degree mounted touchpad Sensor: 18 new absolute packet format Touchpad has extended capability bits -> 4 multi-buttons, i.e. besides standard buttons -> multifinger detection -> palm detection input: SynPS/2 Synaptics TouchPad on isa0060/serio4 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 28Kbytes TCP: Hash tables configured (established 32768 bind 4681) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09b) powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x2 (1500 mV) powernow-k8: 1 : fid 0xc (2000 MHz), vid 0x6 (1400 mV) powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xa (1300 mV) powernow-k8: 3 : fid 0x0 (800 MHz), vid 0x12 (1100 mV) powernow-k8: cpu_init done, current fid 0xe, vid 0x0 powernow-k8: ph2 null fid transition 0xe ACPI: (supports S0 S3 S4 S5) ACPI wakeup devices: PCI0 Z007 GLAN LID SLPB Freeing unused kernel memory: 164k freed device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com cdrom: open failed. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. security: 3 users, 4 roles, 316 types, 20 bools security: 53 classes, 7072 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev dm-0, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), not configured for labeling SELinux: initialized (dev hugetlbfs, type hugetlbfs), not configured for labeling SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts inserting floppy driver for 2.6.9-1.678_FC3 floppy0: no floppy controllers found r8169 Gigabit Ethernet driver 1.2 loaded ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 22 (level, low) -> IRQ 201 r8169: NAPI enabled divert: allocating divert_blk for eth0 eth0: Identified chip type is 'RTL8169'. eth0: RTL8169 at 0xffffff0000022400, 00:0a:e4:5f:3e:85, IRQ 201 r8169: media option is deprecated. via82xx: Assuming DXS channels with 48k fixed sample rate. Please try dxs_support=1 or dxs_support=4 option and report if it works on your machine. ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 201 PCI: Setting latency timer of device 0000:00:11.5 to 64 ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 21 (level, low) -> IRQ 169 ehci_hcd 0000:00:10.3: EHCI Host Controller ehci_hcd 0000:00:10.3: irq 169, pci mem ffffff0000024800 SELinux: initialized (dev usbdevfs, type usbdevfs), uses genfs_contexts ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10 hub 1-0:1.0: USB hub found hub 1-0:1.0: 6 ports detected USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 169 uhci_hcd 0000:00:10.0: UHCI Host Controller uhci_hcd 0000:00:10.0: irq 169, io base 0000000000001c20 uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 21 (level, low) -> IRQ 169 uhci_hcd 0000:00:10.1: UHCI Host Controller uhci_hcd 0000:00:10.1: irq 169, io base 0000000000001c40 uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 21 (level, low) -> IRQ 169 uhci_hcd 0000:00:10.2: UHCI Host Controller uhci_hcd 0000:00:10.2: irq 169, io base 0000000000001c60 uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected Linux Kernel Card Services options: [pci] [cardbus] [pm] ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 17 (level, low) -> IRQ 177 Yenta: CardBus bridge found at 0000:00:0b.0 [1025:006e] Yenta: ISA IRQ mask 0x0cf8, PCI irq 177 Socket status: 30000006 PCI: Enabling device 0000:00:0b.1 (0000 -> 0002) ACPI: PCI interrupt 0000:00:0b.1[B] -> GSI 18 (level, low) -> IRQ 185 Yenta: CardBus bridge found at 0000:00:0b.1 [1025:006e] Yenta: ISA IRQ mask 0x0cf8, PCI irq 185 Socket status: 30000006 ohci1394: $Rev: 1223 $ Ben Collins ACPI: PCI interrupt 0000:00:0b.2[C] -> GSI 19 (level, low) -> IRQ 193 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[193] MMIO=[c0005800-c0005fff] Max Packet=[2048] md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. ieee1394: Host added: ID:BUS[0-00:1023] GUID[000ae40444105af8] ACPI: AC Adapter [AC] (off-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Lid Switch [LID] ACPI: Sleep Button (CM) [SLPB] EXT3 FS on dm-0, internal journal cdrom: open failed. kjournald starting. Commit interval 5 seconds EXT3 FS on hda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. SELinux: initialized (dev hda1, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Adding 1015800k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1 SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected ip_tables: (C) 2000-2002 Netfilter core team ip_conntrack version 2.1 (2045 buckets, 16360 max) - 496 bytes per conntrack r8169: eth0: link up SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts i2c /dev entries driver parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected lp0: using parport0 (polling). lp0: console ready NET: Registered protocol family 10 Disabled Privacy Extensions on device ffffffff80450020(lo) IPv6 over IPv4 tunneling driver divert: not allocating divert_blk for non-ethernet device sit0 eth0: no IPv6 routers present --------------090209010003000801020701 Content-Type: text/plain; name="2.6.10-lspci-vvx.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.10-lspci-vvx.txt" 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 Subsystem: Acer Incorporated [ALI]: Unknown device 006e Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] HyperTransport: Slave or Primary Interface !!! Possibly incomplete decoding Command: BaseUnitID=0 UnitCnt=3 MastHost- DefDir- Link Control 0: CFlE- CST- CFE- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 88 b1 07 00 30 02 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 20 22 20: 00 c1 f0 c1 00 e0 f0 ef 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:0a.0 Ethernet controller: Linksys, A Division of Cisco Systems [AirConn] INPROCOMM IPN 2220 Wireless LAN Adapter (rev 01) Subsystem: AMBIT Microsystem Corp.: Unknown device 0305 Control: I/O+ Mem+ BusMaster- SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 8e ac 07 00 10 02 00 00 07 06 20 a8 82 00 10: 00 00 00 20 a0 00 00 02 00 02 05 b0 00 00 40 20 20: 00 f0 7f 20 00 00 80 20 00 f0 bf 20 00 44 00 00 30: fc 44 00 00 00 48 00 00 fc 48 00 00 0a 01 c0 05 40: 25 10 6e 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller Subsystem: Acer Incorporated [ALI]: Unknown device 006e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 8e ac 07 00 10 02 00 00 07 06 20 a8 82 00 10: 00 10 00 20 a0 00 00 02 00 06 09 b0 00 00 c0 20 20: 00 f0 ff 20 00 00 00 21 00 f0 3f 21 00 4c 00 00 30: fc 4c 00 00 00 50 00 00 fc 50 00 00 0b 02 c0 05 40: 25 10 6e 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0b.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller (prog-if 10 [OHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 006e Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 00: de 10 47 03 07 00 b0 02 a1 00 00 03 00 40 00 00 10: 00 00 00 c1 08 00 00 e0 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 6e 00 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 05 01 --------------090209010003000801020701 Content-Type: text/plain; name="2.6.10-proc-interrupts.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.10-proc-interrupts.txt" CPU0 0: 261994 IO-APIC-edge timer 1: 14 IO-APIC-edge i8042 8: 0 IO-APIC-edge rtc 9: 1 IO-APIC-level acpi 12: 100 IO-APIC-edge i8042 14: 4433 IO-APIC-edge ide0 15: 1934 IO-APIC-edge ide1 169: 0 IO-APIC-level ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd 177: 0 IO-APIC-level yenta 185: 0 IO-APIC-level yenta 193: 3 IO-APIC-level ohci1394 201: 652 IO-APIC-level VIA8233, eth0 NMI: 11 LOC: 261884 ERR: 0 MIS: 0 --------------090209010003000801020701 Content-Type: text/plain; name="config-2.6.10" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config-2.6.10" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.10 # Wed Dec 29 00:15:30 2004 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT is not set # CONFIG_NUMA is not set CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_IBM=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_CUSTOM_DSDT=y CONFIG_ACPI_CUSTOM_DSDT_FILE="/home/rich/src/acpi/acer-1524wlmi/dsdt.hex" CONFIG_ACPI_BLACKLIST_YEAR=2001 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_PROC_INTF is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y # CONFIG_CPU_FREQ_24_API is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_TABLE=y # # CPUFreq processor drivers # CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_ACPI_CPUFREQ=m # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y # CONFIG_PCI_NAMES is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set # CONFIG_PCMCIA_OBSOLETE is not set CONFIG_PCMCIA=m CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_PD6729=m CONFIG_I82092=m CONFIG_TCIC=m # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE=y CONFIG_HOTPLUG_PCI_SHPC=m CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE=y # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_UID16=y # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=m CONFIG_MTD_REDBOOT_PARTS=m # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set CONFIG_MTD_CMDLINE_PARTS=y # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_MTD_BLOCK=m CONFIG_MTD_BLOCK_RO=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y CONFIG_INFTL=m # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_AMDSTD_RETRY=3 CONFIG_MTD_CFI_STAA=m CONFIG_MTD_CFI_UTIL=m CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m CONFIG_MTD_ABSENT=m # # Mapping drivers for chip access # CONFIG_MTD_COMPLEX_MAPPINGS=y # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PNC2000 is not set CONFIG_MTD_SC520CDP=m CONFIG_MTD_NETSC520=m CONFIG_MTD_TS5500=m CONFIG_MTD_SBC_GXX=m CONFIG_MTD_ELAN_104NC=m CONFIG_MTD_SCx200_DOCFLASH=m # CONFIG_MTD_AMD76XROM is not set # CONFIG_MTD_ICHXROM is not set CONFIG_MTD_SCB2_FLASH=m # CONFIG_MTD_NETtel is not set # CONFIG_MTD_DILNETPC is not set # CONFIG_MTD_L440GX is not set CONFIG_MTD_PCI=m # # Self-contained MTD device drivers # CONFIG_MTD_PMC551=m # CONFIG_MTD_PMC551_BUGFIX is not set # CONFIG_MTD_PMC551_DEBUG is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set CONFIG_MTD_MTDRAM=m CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 # CONFIG_MTD_BLKMTD is not set # # Disk-On-Chip Device Drivers # CONFIG_MTD_DOC2000=m # CONFIG_MTD_DOC2001 is not set CONFIG_MTD_DOC2001PLUS=m CONFIG_MTD_DOCPROBE=m CONFIG_MTD_DOCECC=m # CONFIG_MTD_DOCPROBE_ADVANCED is not set CONFIG_MTD_DOCPROBE_ADDRESS=0 # # NAND Flash Device Drivers # CONFIG_MTD_NAND=m # CONFIG_MTD_NAND_VERIFY_WRITE is not set CONFIG_MTD_NAND_IDS=m # CONFIG_MTD_NAND_DISKONCHIP is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_PNPACPI is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set CONFIG_BLK_CPQ_DA=m CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_SX8=m # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_LBD=y CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_AEC62XX=y CONFIG_BLK_DEV_ALI15X3=y # CONFIG_WDC_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_ATIIXP=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_TRIFLEX=y CONFIG_BLK_DEV_CY82C693=y CONFIG_BLK_DEV_CS5520=y CONFIG_BLK_DEV_CS5530=y CONFIG_BLK_DEV_HPT34X=y # CONFIG_HPT34X_AUTODMA is not set CONFIG_BLK_DEV_HPT366=y # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set CONFIG_BLK_DEV_PDC202XX_OLD=y # CONFIG_PDC202XX_BURST is not set CONFIG_BLK_DEV_PDC202XX_NEW=y CONFIG_PDC202XX_FORCE=y CONFIG_BLK_DEV_SVWKS=y CONFIG_BLK_DEV_SIIMAGE=y CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=m CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_3W_9XXX=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_ENABLE_RD_STRM is not set # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_SCSI_SATA=y CONFIG_SCSI_SATA_AHCI=m CONFIG_SCSI_SATA_SVW=m CONFIG_SCSI_ATA_PIIX=m CONFIG_SCSI_SATA_NV=m CONFIG_SCSI_SATA_PROMISE=m CONFIG_SCSI_SATA_SX4=m CONFIG_SCSI_SATA_SIL=m CONFIG_SCSI_SATA_SIS=m CONFIG_SCSI_SATA_ULI=m CONFIG_SCSI_SATA_VIA=m CONFIG_SCSI_SATA_VITESSE=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set CONFIG_SCSI_GDTH=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m CONFIG_SCSI_INIA100=m CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set # CONFIG_SCSI_IPR is not set CONFIG_SCSI_QLOGIC_ISP=m # CONFIG_SCSI_QLOGIC_FC is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLOGIC_1280_1040=y CONFIG_SCSI_QLA2XXX=m CONFIG_SCSI_QLA21XX=m CONFIG_SCSI_QLA22XX=m CONFIG_SCSI_QLA2300=m CONFIG_SCSI_QLA2322=m CONFIG_SCSI_QLA6312=m CONFIG_SCSI_QLA6322=m # CONFIG_SCSI_DC395x is not set CONFIG_SCSI_DC390T=m # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # CONFIG_PCMCIA_FDOMAIN=m CONFIG_PCMCIA_QLOGIC=m CONFIG_PCMCIA_SYM53C500=m # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID5=m CONFIG_MD_RAID6=m CONFIG_MD_MULTIPATH=m # CONFIG_MD_FAULTY is not set CONFIG_BLK_DEV_DM=m CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m # # Fusion MPT device support # CONFIG_FUSION=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_OUI_DB=y # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set # CONFIG_IEEE1394_ETH1394 is not set CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m # # I2O device support # CONFIG_I2O=m CONFIG_I2O_CONFIG=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=m CONFIG_IP_TCPDIAG_IPV6=y # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # CONFIG_IP_VS_FTP=m CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m CONFIG_IPV6_TUNNEL=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_MATCH_CONNMARK=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_CONNMARK=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_QUEUE is not set CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_PHYSDEV=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_IP6_NF_RAW=m # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_XFRM=y CONFIG_XFRM_USER=y # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m # CONFIG_ATM_MPOA is not set CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set CONFIG_LLC=y # CONFIG_LLC2 is not set CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=y CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set CONFIG_NET_DIVERT=y # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_NET_CLS_IND=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_RX is not set CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # CONFIG_HAMRADIO is not set CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m # # Old SIR device drivers # CONFIG_IRPORT_SIR=m # # Old Serial dongle support # # CONFIG_DONGLE_OLD is not set # # FIR device drivers # CONFIG_USB_IRDA=m CONFIG_SIGMATEL_FIR=m # CONFIG_VLSI_FIR is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_CMTP=m CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_BCSP_TXCRC=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_ETHERTAP=m CONFIG_NET_SB1000=m # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_TYPHOON=m # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set CONFIG_TULIP_MMIO=y # CONFIG_TULIP_NAPI is not set CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_PCMCIA_XIRCOM=m CONFIG_PCMCIA_XIRTULIP=m # CONFIG_HP100 is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_AMD8111E_NAPI=y CONFIG_ADAPTEC_STARFIRE=m CONFIG_ADAPTEC_STARFIRE_NAPI=y CONFIG_B44=m CONFIG_FORCEDETH=m CONFIG_DGRS=m CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m CONFIG_E100_NAPI=y CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m CONFIG_8139TOO_PIO=y # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_DL2K=m CONFIG_E1000=m CONFIG_E1000_NAPI=y CONFIG_NS83820=m CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_R8169=m CONFIG_R8169_NAPI=y CONFIG_SK98LIN=m CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=m # # Ethernet (10000 Mbit) # CONFIG_IXGB=m CONFIG_IXGB_NAPI=y CONFIG_S2IO=m CONFIG_S2IO_NAPI=y # # Token Ring devices # CONFIG_TR=y CONFIG_IBMOL=m CONFIG_3C359=m CONFIG_TMS380TR=m CONFIG_TMSPCI=m CONFIG_ABYSS=m # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # # Obsolete Wireless cards support (pre-802.11) # # CONFIG_STRIP is not set CONFIG_PCMCIA_WAVELAN=m CONFIG_PCMCIA_NETWAVE=m # # Wireless 802.11 Frequency Hopping cards support # CONFIG_PCMCIA_RAYCS=m # # Wireless 802.11b ISA/PCI cards support # CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_PCI_HERMES=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m # # Wireless 802.11b Pcmcia/Cardbus cards support # CONFIG_PCMCIA_HERMES=m CONFIG_AIRO_CS=m CONFIG_PCMCIA_ATMEL=m CONFIG_PCMCIA_WL3501=m # # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support # CONFIG_PRISM54=m CONFIG_NET_WIRELESS=y # # PCMCIA network device support # CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_PCMCIA_AXNET=m # # Wan interfaces # # CONFIG_WAN is not set # # ATM drivers # CONFIG_ATM_TCP=m CONFIG_ATM_LANAI=m CONFIG_ATM_ENI=m # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set CONFIG_ATM_FIRESTREAM=m # CONFIG_ATM_ZATM is not set CONFIG_ATM_IDT77252=m # CONFIG_ATM_IDT77252_DEBUG is not set # CONFIG_ATM_IDT77252_RCV_ALL is not set CONFIG_ATM_IDT77252_USE_SUNI=y CONFIG_ATM_AMBASSADOR=m # CONFIG_ATM_AMBASSADOR_DEBUG is not set CONFIG_ATM_HORIZON=m # CONFIG_ATM_HORIZON_DEBUG is not set CONFIG_ATM_FORE200E_MAYBE=m # CONFIG_ATM_FORE200E_PCA is not set CONFIG_ATM_HE=m # CONFIG_ATM_HE_USE_SUNI is not set CONFIG_FDDI=y # CONFIG_DEFXX is not set CONFIG_SKFP=m # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m # CONFIG_PPP_BSDCOMP is not set CONFIG_PPPOE=m CONFIG_PPPOATM=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set CONFIG_NET_FC=y # CONFIG_SHAPER is not set CONFIG_NETCONSOLE=m # # ISDN subsystem # CONFIG_ISDN=m # # Old ISDN4Linux # CONFIG_ISDN_I4L=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y # CONFIG_ISDN_PPP_BSDCOMP is not set CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y # # ISDN feature submodules # CONFIG_ISDN_DRV_LOOP=m CONFIG_ISDN_DIVERSION=m # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=m # # D-channel protocol features # CONFIG_HISAX_EURO=y CONFIG_DE_AOC=y CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y CONFIG_HISAX_DIEHLDIVA=y CONFIG_HISAX_SEDLBAUER=y CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y # CONFIG_HISAX_DEBUG is not set # # HiSax PCMCIA card service modules # CONFIG_HISAX_SEDLBAUER_CS=m CONFIG_HISAX_ELSA_CS=m CONFIG_HISAX_AVM_A1_CS=m CONFIG_HISAX_TELES_CS=m # # HiSax sub driver modules # CONFIG_HISAX_ST5481=m CONFIG_HISAX_HFCUSB=m CONFIG_HISAX_FRITZ_PCIPNP=m CONFIG_HISAX_HDLC=y # # Active cards # CONFIG_ISDN_DRV_TPAM=m CONFIG_HYSDN=m CONFIG_HYSDN_CAPI=y # # CAPI subsystem # CONFIG_ISDN_CAPI=m CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=m CONFIG_ISDN_CAPI_CAPIDRV=m # # CAPI hardware drivers # # # Active AVM cards # CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m # # Active Eicon DIVA Server cards # # CONFIG_CAPI_EICON is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_SOUND_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_VORTEX=m CONFIG_GAMEPORT_FM801=m CONFIG_GAMEPORT_CS461x=m CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # CONFIG_SERIO_RAW is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_VSXXXAA=m CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m CONFIG_JOYSTICK_ADI=m CONFIG_JOYSTICK_COBRA=m CONFIG_JOYSTICK_GF2K=m CONFIG_JOYSTICK_GRIP=m CONFIG_JOYSTICK_GRIP_MP=m CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=m CONFIG_JOYSTICK_SIDEWINDER=m CONFIG_JOYSTICK_TMDC=m CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=m CONFIG_JOYSTICK_MAGELLAN=m CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=m CONFIG_JOYSTICK_STINGER=m CONFIG_JOYSTICK_TWIDDLER=m CONFIG_JOYSTICK_DB9=m CONFIG_JOYSTICK_GAMECON=m CONFIG_JOYSTICK_TURBOGRAFX=m CONFIG_JOYSTICK_JOYDUMP=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set CONFIG_ROCKETPORT=m # CONFIG_CYCLADES is not set # CONFIG_DIGIEPCA is not set # CONFIG_DIGI is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_ISI is not set # CONFIG_SYNCLINK is not set # CONFIG_SYNCLINKMP is not set CONFIG_N_HDLC=m # CONFIG_RISCOM8 is not set # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set CONFIG_STALDRV=y # CONFIG_STALLION is not set # CONFIG_ISTALLION is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_CS=m # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_MULTIPORT=y CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_TIPAR=m # # IPMI # CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m CONFIG_ACQUIRE_WDT=m CONFIG_ADVANTECH_WDT=m CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m CONFIG_SC520_WDT=m CONFIG_EUROTECH_WDT=m CONFIG_IB700_WDT=m CONFIG_WAFER_WDT=m CONFIG_I8XX_TCO=m CONFIG_SC1200_WDT=m # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set CONFIG_CPU5_WDT=m CONFIG_W83627HF_WDT=m CONFIG_W83877F_WDT=m CONFIG_MACHZ_WDT=m # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_HW_RANDOM=m # CONFIG_NVRAM is not set CONFIG_RTC=y CONFIG_DTLK=m CONFIG_R3964=m # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL_MCH=y CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_SIS=m # # PCMCIA character devices # CONFIG_SYNCLINK_CS=m CONFIG_MWAVE=m # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set CONFIG_HANGCHECK_TIMER=m # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI1563=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m # CONFIG_SCx200_ACB is not set CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m CONFIG_I2C_STUB=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_I2C_VOODOO3=m CONFIG_I2C_PCA_ISA=m # # Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_FSCHER=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83627HF=m # # Other I2C Chip support # CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_PCF8574=m CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_RTC8564=m # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BWQCAM=m CONFIG_VIDEO_CQCAM=m CONFIG_VIDEO_W9966=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_PP=m CONFIG_VIDEO_CPIA_USB=m CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_TUNER_3036=m CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_DPC=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_OVCAMCHIP=m # # Radio Adapters # CONFIG_RADIO_GEMTEK_PCI=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_MAESTRO=m # # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m # # Supported SAA7146 based PCI Adapters # CONFIG_DVB_AV7110=m # CONFIG_DVB_AV7110_FIRMWARE is not set CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_DVB_DIBUSB=m CONFIG_DVB_DIBUSB_MISDESIGNED_DEVICES=y # CONFIG_DVB_DIBCOM_DEBUG is not set CONFIG_DVB_CINERGYT2=m # CONFIG_DVB_CINERGYT2_TUNING is not set # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_SKYSTAR=m CONFIG_DVB_B2C2_USB=m # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m # # Supported DVB Frontends # # # Customise DVB Frontends # # # DVB-S (satellite) frontends # CONFIG_DVB_STV0299=m CONFIG_DVB_CX24110=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA80XX=m CONFIG_DVB_MT312=m CONFIG_DVB_VES1X93=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m # # DVB-C (cable) frontends # CONFIG_DVB_ATMEL_AT76C651=m CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_STV0297=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_VIDEO_VIDEOBUF=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m # # Graphics support # CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_CIRRUS=m # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FB_HGA=m CONFIG_FB_HGA_ACCEL=y CONFIG_FB_RIVA=m # CONFIG_FB_RIVA_I2C is not set # CONFIG_FB_RIVA_DEBUG is not set CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G450=y CONFIG_FB_MATROX_G100=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y # CONFIG_FB_RADEON_OLD is not set CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y # CONFIG_FB_RADEON_DEBUG is not set CONFIG_FB_ATY128=m CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y # CONFIG_FB_ATY_GENERIC_LCD is not set # CONFIG_FB_ATY_XL_INIT is not set CONFIG_FB_ATY_GX=y CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=m CONFIG_FB_SAVAGE_ACCEL=m # CONFIG_FB_SIS is not set CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=m CONFIG_FB_3DFX_ACCEL=y CONFIG_FB_VOODOO1=m CONFIG_FB_TRIDENT=m CONFIG_FB_TRIDENT_ACCEL=y # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_BIT32_EMUL=m CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # # PCI devices # CONFIG_SND_AC97_CODEC=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS4281=m CONFIG_SND_EMU10K1=m CONFIG_SND_KORG1212=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_HDSP=m CONFIG_SND_TRIDENT=m CONFIG_SND_YMFPCI=m CONFIG_SND_ALS4000=m CONFIG_SND_CMIPCI=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_MAESTRO3=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_SONICVIBES=m CONFIG_SND_VIA82XX=m CONFIG_SND_VX222=m # # USB devices # CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m # # PCMCIA devices # # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m CONFIG_USB_SL811_HCD=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # CONFIG_USB_MIDI=m CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_RW_DETECT=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y CONFIG_THRUSTMASTER_FF=y CONFIG_USB_HIDDEV=y CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m CONFIG_USB_KBTAB=m CONFIG_USB_POWERMATE=m CONFIG_USB_MTOUCH=m CONFIG_USB_EGALAX=m CONFIG_USB_XPAD=m CONFIG_USB_ATI_REMOTE=m # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # # USB Multimedia devices # CONFIG_USB_DABUSB=m CONFIG_USB_VICAM=m CONFIG_USB_DSBR=m CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m CONFIG_USB_SN9C102=m CONFIG_USB_STV680=m CONFIG_USB_W9968CF=m # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_GENESYS=y CONFIG_USB_NET1080=y CONFIG_USB_PL2301=y CONFIG_USB_KC2190=y # # Intelligent USB Devices/Gadgets # CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_ZAURUS=y CONFIG_USB_CDCETHER=y # # USB Network Adapters # CONFIG_USB_AX8817X=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m # CONFIG_USB_SERIAL_IPW is not set CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m # CONFIG_USB_EMI26 is not set CONFIG_USB_TIGL=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_LED=m # CONFIG_USB_CYTHERM is not set CONFIG_USB_PHIDGETKIT=m CONFIG_USB_PHIDGETSERVO=m CONFIG_USB_TEST=m # # USB ATM/DSL drivers # CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set CONFIG_MMC_BLOCK=m CONFIG_MMC_WBSD=m # # Firmware Drivers # # CONFIG_EDD is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y CONFIG_TMPFS_XATTR=y CONFIG_TMPFS_SECURITY=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set CONFIG_AFFS_FS=m CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m CONFIG_EFS_FS=m # CONFIG_JFFS_FS is not set CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_NAND=y # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_ZLIB=y CONFIG_JFFS2_RTIME=y # CONFIG_JFFS2_RUBIN is not set CONFIG_CRAMFS=m CONFIG_VXFS_FS=m # CONFIG_HPFS_FS is not set CONFIG_QNX4FS_FS=m # CONFIG_QNX4FS_RW is not set CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_EXPERIMENTAL is not set CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_EFI_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_INFO=y # CONFIG_CHECKING is not set CONFIG_INIT_DEBUG=y # CONFIG_IOMMU_DEBUG is not set # CONFIG_KPROBES is not set # # Security options # # CONFIG_KEYS is not set CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_ROOTPLUG is not set CONFIG_SECURITY_SECLVL=m CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y # CONFIG_SECURITY_SELINUX_MLS is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m --------------090209010003000801020701-- From rich@phekda.gotadsl.co.uk Sun Jan 2 07:14:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 07:15:08 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02FEYCc028693 for ; Sun, 2 Jan 2005 07:14:55 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (unknown [84.12.65.24]) by smtp.nildram.co.uk (Postfix) with ESMTP id A047F24FE6B; Sun, 2 Jan 2005 15:23:03 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 76901355; Sun, 2 Jan 2005 15:23:58 +0000 (GMT) Message-ID: <41D811F9.7030202@phekda.gotadsl.co.uk> Date: Sun, 02 Jan 2005 15:23:37 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Richard Dawe , netdev@oss.sgi.com Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41A09541.5040405@phekda.gotadsl.co.uk> <41A0F0D5.9050702@phekda.gotadsl.co.uk> <20041121205814.GA22460@electric-eye.fr.zoreil.com> <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41D7FC59.2040503@phekda.gotadsl.co.uk> In-Reply-To: <41D7FC59.2040503@phekda.gotadsl.co.uk> Content-Type: multipart/mixed; boundary="------------050102090004090802060504" X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------050102090004090802060504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. Richard Dawe wrote: > > Francois Romieu wrote: [snip] >> Could you send an updated dmesg, lspci -vvx, /proc/interrupts please ? > > > Please see the attached, which are for running with 2.6.10. I included > .config, Just In Case. [snip] Sorry, I booted into 2.6.9-1.681_FC3 by mistake. Attached are the ones from 2.6.10. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek --------------050102090004090802060504 Content-Type: text/plain; name="2.6.10-dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.10-dmesg.txt" Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00) Linux version 2.6.10 (rich@meelo.int.phekda.gotadsl.co.uk) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Wed Dec 29 00:43:22 GMT 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000d8000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001ff70000 (usable) BIOS-e820: 000000001ff70000 - 000000001ff7a000 (ACPI data) BIOS-e820: 000000001ff7a000 - 000000001ff80000 (ACPI NVS) BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved) BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved) No mptable found. On node 0 totalpages: 130928 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126832 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 PTLTD ) @ 0x00000000000f6a60 ACPI: RSDT (v001 PTLTD RSDT 0x06040000 LTP 0x00000000) @ 0x000000001ff73fbd ACPI: FADT (v002 AMDK8 PTLTW 0x06040000 PTL_ 0x000f4240) @ 0x000000001ff79e35 ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x000000001ff79eb9 ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @ 0x000000001ff79fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x06040000 MSFT 0x0100000e) @ 0x0000000000000000 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ d0000000 size 256 MB Built 1 zonelists Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=tty0 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 65536 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 2201.348 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Memory: 508232k/523712k available (2585k kernel code, 14724k reserved, 1202k data, 184k init) Calibrating delay loop... 4325.37 BogoMIPS (lpj=2162688) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3400+ stepping 0a ACPI-0294: *** Info: Table [DSDT] replaced by host OS Using local APIC NMI watchdog using perfctr0 Using local APIC timer interrupts. Detected 12.507 MHz APIC timer. checking if image is initramfs... it is NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20041105 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10 ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: Embedded Controller [EC] (gpe 11) Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to bjorn.helgaas@hp.com ** so I can fix the driver. agpgart: Detected AGP bridge 0 agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 256M @ 0xd0000000 PCI-DMA: Disabling IOMMU. IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $ audit: initializing netlink socket (disabled) audit(1104678976.354:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API pci_hotplug: PCI Hot Plug PCI Core version: 0.5 vesafb: probe of vesafb0 failed with error -6 ACPI: Thermal Zone [THRS] (42 C) ACPI: Thermal Zone [THRC] (51 C) Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize divert: not allocating divert_blk for non-ethernet device lo Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:11.1 ACPI: PCI interrupt 0000:00:11.1[A]: no GSI - using IRQ 0 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1 ide0: BM-DMA at 0x1c80-0x1c87, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1c88-0x1c8f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: IC25N060ATMR04-0, ATA DISK drive elevator: using anticipatory as default io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: TSSTcorpCD/DVDW TS-L532A, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... ide2: Wait for ready failed before probe ! Probing IDE interface ide3... ide3: Wait for ready failed before probe ! Probing IDE interface ide4... ide4: Wait for ready failed before probe ! Probing IDE interface ide5... ide5: Wait for ready failed before probe ! hda: max request size: 1024KiB hda: 117210240 sectors (60011 MB) w/7884KiB Cache, CHS=16383/255/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 ide-floppy driver 0.99.newide usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 Synaptics Touchpad, model: 1 Firmware: 5.8 180 degree mounted touchpad Sensor: 18 new absolute packet format Touchpad has extended capability bits -> 4 multi-buttons, i.e. besides standard buttons -> multifinger detection -> palm detection input: SynPS/2 Synaptics TouchPad on isa0060/serio4 md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 28Kbytes TCP: Hash tables configured (established 32768 bind 4681) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e) powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x2 (1500 mV) powernow-k8: 1 : fid 0xc (2000 MHz), vid 0x6 (1400 mV) powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xa (1300 mV) powernow-k8: 3 : fid 0x0 (800 MHz), vid 0x12 (1100 mV) cpu_init done, current fid 0xe, vid 0x0 powernow-k8: ph2 null fid transition 0xe ACPI wakeup devices: PCI0 Z007 GLAN LID SLPB ACPI: (supports S0 S3 S4 S5) Freeing unused kernel memory: 184k freed device-mapper: 4.3.0-ioctl (2004-09-30) initialised: dm-devel@redhat.com cdrom: open failed. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. security: 3 users, 4 roles, 316 types, 20 bools security: 53 classes, 7085 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev dm-0, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), not configured for labeling SELinux: initialized (dev hugetlbfs, type hugetlbfs), not configured for labeling SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts inserting floppy driver for 2.6.10 floppy0: no floppy controllers found r8169 Gigabit Ethernet driver 1.2 loaded ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 22 (level, low) -> IRQ 169 r8169: NAPI enabled divert: allocating divert_blk for eth0 eth0: Identified chip type is 'RTL8169'. eth0: RTL8169 at 0xffffff000001a400, 00:0a:e4:5f:3e:85, IRQ 169 r8169: media option is deprecated. via82xx: Assuming DXS channels with 48k fixed sample rate. Please try dxs_support=1 or dxs_support=4 option and report if it works on your machine. ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 169 PCI: Via IRQ fixup for 0000:00:11.5, from 11 to 9 PCI: Setting latency timer of device 0000:00:11.5 to 64 ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 21 (level, low) -> IRQ 177 ehci_hcd 0000:00:10.3: EHCI Host Controller ehci_hcd 0000:00:10.3: irq 177, pci mem 0xc0006800 ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004 hub 1-0:1.0: USB hub found hub 1-0:1.0: 6 ports detected USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 177 PCI: Via IRQ fixup for 0000:00:10.0, from 0 to 1 uhci_hcd 0000:00:10.0: UHCI Host Controller uhci_hcd 0000:00:10.0: irq 177, io base 0x1c20 uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 21 (level, low) -> IRQ 177 PCI: Via IRQ fixup for 0000:00:10.1, from 0 to 1 uhci_hcd 0000:00:10.1: UHCI Host Controller uhci_hcd 0000:00:10.1: irq 177, io base 0x1c40 uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 21 (level, low) -> IRQ 177 PCI: Via IRQ fixup for 0000:00:10.2, from 0 to 1 uhci_hcd 0000:00:10.2: UHCI Host Controller uhci_hcd 0000:00:10.2: irq 177, io base 0x1c60 uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected Linux Kernel Card Services options: [pci] [cardbus] [pm] ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 17 (level, low) -> IRQ 185 Yenta: CardBus bridge found at 0000:00:0b.0 [1025:006e] Yenta: ISA IRQ mask 0x0cf8, PCI irq 185 Socket status: 30000006 PCI: Enabling device 0000:00:0b.1 (0000 -> 0002) ACPI: PCI interrupt 0000:00:0b.1[B] -> GSI 18 (level, low) -> IRQ 193 Yenta: CardBus bridge found at 0000:00:0b.1 [1025:006e] Yenta: ISA IRQ mask 0x0cf8, PCI irq 193 Socket status: 30000006 ohci1394: $Rev: 1223 $ Ben Collins ACPI: PCI interrupt 0000:00:0b.2[C] -> GSI 19 (level, low) -> IRQ 201 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[201] MMIO=[c0005800-c0005fff] Max Packet=[2048] md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. ieee1394: Host added: ID:BUS[0-00:1023] GUID[000ae40444105af8] ACPI: AC Adapter [AC] (on-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Lid Switch [LID] ACPI: Sleep Button (CM) [SLPB] ibm_acpi: ec object not found ACPI: Video Device [VGA] (multi-head: yes rom: no post: no) EXT3 FS on dm-0, internal journal cdrom: open failed. kjournald starting. Commit interval 5 seconds EXT3 FS on hda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. SELinux: initialized (dev hda1, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Adding 1015800k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1 SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts parport_pc: Ignoring new-style parameters in presence of obsolete ones parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected ip_tables: (C) 2000-2002 Netfilter core team ip_conntrack version 2.1 (2045 buckets, 16360 max) - 504 bytes per conntrack r8169: eth0: link up SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts parport_pc: Ignoring new-style parameters in presence of obsolete ones parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected lp0: using parport0 (polling). lp0: console ready NET: Registered protocol family 10 Disabled Privacy Extensions on device ffffffff80470ae0(lo) IPv6 over IPv4 tunneling driver divert: not allocating divert_blk for non-ethernet device sit0 eth0: no IPv6 routers present --------------050102090004090802060504 Content-Type: text/plain; name="2.6.10-lspci-vvx.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.10-lspci-vvx.txt" 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 Subsystem: Acer Incorporated [ALI]: Unknown device 006e Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] HyperTransport: Slave or Primary Interface !!! Possibly incomplete decoding Command: BaseUnitID=0 UnitCnt=3 MastHost- DefDir- Link Control 0: CFlE- CST- CFE- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 88 b1 07 00 30 02 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 20 22 20: 00 c1 f0 c1 00 e0 f0 ef 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:0a.0 Ethernet controller: Linksys, A Division of Cisco Systems [AirConn] INPROCOMM IPN 2220 Wireless LAN Adapter (rev 01) Subsystem: AMBIT Microsystem Corp.: Unknown device 0305 Control: I/O+ Mem+ BusMaster- SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 8e ac 07 00 10 02 00 00 07 06 20 a8 82 00 10: 00 00 00 20 a0 00 00 02 00 02 05 b0 00 00 40 20 20: 00 f0 7f 20 00 00 80 20 00 f0 bf 20 00 44 00 00 30: fc 44 00 00 00 48 00 00 fc 48 00 00 0a 01 c0 05 40: 25 10 6e 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller Subsystem: Acer Incorporated [ALI]: Unknown device 006e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 8e ac 07 00 10 02 00 00 07 06 20 a8 82 00 10: 00 10 00 20 a0 00 00 02 00 06 09 b0 00 00 c0 20 20: 00 f0 ff 20 00 00 00 21 00 f0 3f 21 00 4c 00 00 30: fc 4c 00 00 00 50 00 00 fc 50 00 00 0b 02 c0 05 40: 25 10 6e 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0b.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller (prog-if 10 [OHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 006e Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 00: de 10 47 03 07 00 b0 02 a1 00 00 03 00 40 00 00 10: 00 00 00 c1 08 00 00 e0 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 6e 00 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 05 01 --------------050102090004090802060504 Content-Type: text/plain; name="2.6.10-proc-interrupts.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.10-proc-interrupts.txt" CPU0 0: 132568 IO-APIC-edge timer 1: 14 IO-APIC-edge i8042 8: 0 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 12: 100 IO-APIC-edge i8042 14: 4750 IO-APIC-edge ide0 15: 729 IO-APIC-edge ide1 169: 548 IO-APIC-level VIA8233, eth0 177: 0 IO-APIC-level ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd 185: 0 IO-APIC-level yenta 193: 0 IO-APIC-level yenta 201: 3 IO-APIC-level ohci1394 NMI: 12 LOC: 132480 ERR: 0 MIS: 0 --------------050102090004090802060504 Content-Type: text/plain; name="config-2.6.10" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config-2.6.10" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.10 # Wed Dec 29 00:15:30 2004 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT is not set # CONFIG_NUMA is not set CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_IBM=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_CUSTOM_DSDT=y CONFIG_ACPI_CUSTOM_DSDT_FILE="/home/rich/src/acpi/acer-1524wlmi/dsdt.hex" CONFIG_ACPI_BLACKLIST_YEAR=2001 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_PROC_INTF is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y # CONFIG_CPU_FREQ_24_API is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_TABLE=y # # CPUFreq processor drivers # CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_ACPI_CPUFREQ=m # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y # CONFIG_PCI_NAMES is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set # CONFIG_PCMCIA_OBSOLETE is not set CONFIG_PCMCIA=m CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_PD6729=m CONFIG_I82092=m CONFIG_TCIC=m # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE=y CONFIG_HOTPLUG_PCI_SHPC=m CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE=y # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_UID16=y # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=m CONFIG_MTD_REDBOOT_PARTS=m # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set CONFIG_MTD_CMDLINE_PARTS=y # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_MTD_BLOCK=m CONFIG_MTD_BLOCK_RO=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y CONFIG_INFTL=m # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_AMDSTD_RETRY=3 CONFIG_MTD_CFI_STAA=m CONFIG_MTD_CFI_UTIL=m CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m CONFIG_MTD_ABSENT=m # # Mapping drivers for chip access # CONFIG_MTD_COMPLEX_MAPPINGS=y # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PNC2000 is not set CONFIG_MTD_SC520CDP=m CONFIG_MTD_NETSC520=m CONFIG_MTD_TS5500=m CONFIG_MTD_SBC_GXX=m CONFIG_MTD_ELAN_104NC=m CONFIG_MTD_SCx200_DOCFLASH=m # CONFIG_MTD_AMD76XROM is not set # CONFIG_MTD_ICHXROM is not set CONFIG_MTD_SCB2_FLASH=m # CONFIG_MTD_NETtel is not set # CONFIG_MTD_DILNETPC is not set # CONFIG_MTD_L440GX is not set CONFIG_MTD_PCI=m # # Self-contained MTD device drivers # CONFIG_MTD_PMC551=m # CONFIG_MTD_PMC551_BUGFIX is not set # CONFIG_MTD_PMC551_DEBUG is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set CONFIG_MTD_MTDRAM=m CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 # CONFIG_MTD_BLKMTD is not set # # Disk-On-Chip Device Drivers # CONFIG_MTD_DOC2000=m # CONFIG_MTD_DOC2001 is not set CONFIG_MTD_DOC2001PLUS=m CONFIG_MTD_DOCPROBE=m CONFIG_MTD_DOCECC=m # CONFIG_MTD_DOCPROBE_ADVANCED is not set CONFIG_MTD_DOCPROBE_ADDRESS=0 # # NAND Flash Device Drivers # CONFIG_MTD_NAND=m # CONFIG_MTD_NAND_VERIFY_WRITE is not set CONFIG_MTD_NAND_IDS=m # CONFIG_MTD_NAND_DISKONCHIP is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_PNPACPI is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set CONFIG_BLK_CPQ_DA=m CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_SX8=m # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_LBD=y CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_AEC62XX=y CONFIG_BLK_DEV_ALI15X3=y # CONFIG_WDC_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_ATIIXP=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_TRIFLEX=y CONFIG_BLK_DEV_CY82C693=y CONFIG_BLK_DEV_CS5520=y CONFIG_BLK_DEV_CS5530=y CONFIG_BLK_DEV_HPT34X=y # CONFIG_HPT34X_AUTODMA is not set CONFIG_BLK_DEV_HPT366=y # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set CONFIG_BLK_DEV_PDC202XX_OLD=y # CONFIG_PDC202XX_BURST is not set CONFIG_BLK_DEV_PDC202XX_NEW=y CONFIG_PDC202XX_FORCE=y CONFIG_BLK_DEV_SVWKS=y CONFIG_BLK_DEV_SIIMAGE=y CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=m CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_3W_9XXX=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_ENABLE_RD_STRM is not set # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_SCSI_SATA=y CONFIG_SCSI_SATA_AHCI=m CONFIG_SCSI_SATA_SVW=m CONFIG_SCSI_ATA_PIIX=m CONFIG_SCSI_SATA_NV=m CONFIG_SCSI_SATA_PROMISE=m CONFIG_SCSI_SATA_SX4=m CONFIG_SCSI_SATA_SIL=m CONFIG_SCSI_SATA_SIS=m CONFIG_SCSI_SATA_ULI=m CONFIG_SCSI_SATA_VIA=m CONFIG_SCSI_SATA_VITESSE=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set CONFIG_SCSI_GDTH=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m CONFIG_SCSI_INIA100=m CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set # CONFIG_SCSI_IPR is not set CONFIG_SCSI_QLOGIC_ISP=m # CONFIG_SCSI_QLOGIC_FC is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLOGIC_1280_1040=y CONFIG_SCSI_QLA2XXX=m CONFIG_SCSI_QLA21XX=m CONFIG_SCSI_QLA22XX=m CONFIG_SCSI_QLA2300=m CONFIG_SCSI_QLA2322=m CONFIG_SCSI_QLA6312=m CONFIG_SCSI_QLA6322=m # CONFIG_SCSI_DC395x is not set CONFIG_SCSI_DC390T=m # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # CONFIG_PCMCIA_FDOMAIN=m CONFIG_PCMCIA_QLOGIC=m CONFIG_PCMCIA_SYM53C500=m # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID5=m CONFIG_MD_RAID6=m CONFIG_MD_MULTIPATH=m # CONFIG_MD_FAULTY is not set CONFIG_BLK_DEV_DM=m CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m # # Fusion MPT device support # CONFIG_FUSION=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_OUI_DB=y # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set # CONFIG_IEEE1394_ETH1394 is not set CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m # # I2O device support # CONFIG_I2O=m CONFIG_I2O_CONFIG=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=m CONFIG_IP_TCPDIAG_IPV6=y # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # CONFIG_IP_VS_FTP=m CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m CONFIG_IPV6_TUNNEL=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_MATCH_CONNMARK=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_CONNMARK=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_QUEUE is not set CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_PHYSDEV=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_IP6_NF_RAW=m # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_XFRM=y CONFIG_XFRM_USER=y # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m # CONFIG_ATM_MPOA is not set CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set CONFIG_LLC=y # CONFIG_LLC2 is not set CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=y CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set CONFIG_NET_DIVERT=y # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_NET_CLS_IND=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_RX is not set CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # CONFIG_HAMRADIO is not set CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m # # Old SIR device drivers # CONFIG_IRPORT_SIR=m # # Old Serial dongle support # # CONFIG_DONGLE_OLD is not set # # FIR device drivers # CONFIG_USB_IRDA=m CONFIG_SIGMATEL_FIR=m # CONFIG_VLSI_FIR is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_CMTP=m CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_BCSP_TXCRC=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_ETHERTAP=m CONFIG_NET_SB1000=m # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_TYPHOON=m # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set CONFIG_TULIP_MMIO=y # CONFIG_TULIP_NAPI is not set CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_PCMCIA_XIRCOM=m CONFIG_PCMCIA_XIRTULIP=m # CONFIG_HP100 is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_AMD8111E_NAPI=y CONFIG_ADAPTEC_STARFIRE=m CONFIG_ADAPTEC_STARFIRE_NAPI=y CONFIG_B44=m CONFIG_FORCEDETH=m CONFIG_DGRS=m CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m CONFIG_E100_NAPI=y CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m CONFIG_8139TOO_PIO=y # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_DL2K=m CONFIG_E1000=m CONFIG_E1000_NAPI=y CONFIG_NS83820=m CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_R8169=m CONFIG_R8169_NAPI=y CONFIG_SK98LIN=m CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=m # # Ethernet (10000 Mbit) # CONFIG_IXGB=m CONFIG_IXGB_NAPI=y CONFIG_S2IO=m CONFIG_S2IO_NAPI=y # # Token Ring devices # CONFIG_TR=y CONFIG_IBMOL=m CONFIG_3C359=m CONFIG_TMS380TR=m CONFIG_TMSPCI=m CONFIG_ABYSS=m # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # # Obsolete Wireless cards support (pre-802.11) # # CONFIG_STRIP is not set CONFIG_PCMCIA_WAVELAN=m CONFIG_PCMCIA_NETWAVE=m # # Wireless 802.11 Frequency Hopping cards support # CONFIG_PCMCIA_RAYCS=m # # Wireless 802.11b ISA/PCI cards support # CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_PCI_HERMES=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m # # Wireless 802.11b Pcmcia/Cardbus cards support # CONFIG_PCMCIA_HERMES=m CONFIG_AIRO_CS=m CONFIG_PCMCIA_ATMEL=m CONFIG_PCMCIA_WL3501=m # # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support # CONFIG_PRISM54=m CONFIG_NET_WIRELESS=y # # PCMCIA network device support # CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_PCMCIA_AXNET=m # # Wan interfaces # # CONFIG_WAN is not set # # ATM drivers # CONFIG_ATM_TCP=m CONFIG_ATM_LANAI=m CONFIG_ATM_ENI=m # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set CONFIG_ATM_FIRESTREAM=m # CONFIG_ATM_ZATM is not set CONFIG_ATM_IDT77252=m # CONFIG_ATM_IDT77252_DEBUG is not set # CONFIG_ATM_IDT77252_RCV_ALL is not set CONFIG_ATM_IDT77252_USE_SUNI=y CONFIG_ATM_AMBASSADOR=m # CONFIG_ATM_AMBASSADOR_DEBUG is not set CONFIG_ATM_HORIZON=m # CONFIG_ATM_HORIZON_DEBUG is not set CONFIG_ATM_FORE200E_MAYBE=m # CONFIG_ATM_FORE200E_PCA is not set CONFIG_ATM_HE=m # CONFIG_ATM_HE_USE_SUNI is not set CONFIG_FDDI=y # CONFIG_DEFXX is not set CONFIG_SKFP=m # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m # CONFIG_PPP_BSDCOMP is not set CONFIG_PPPOE=m CONFIG_PPPOATM=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set CONFIG_NET_FC=y # CONFIG_SHAPER is not set CONFIG_NETCONSOLE=m # # ISDN subsystem # CONFIG_ISDN=m # # Old ISDN4Linux # CONFIG_ISDN_I4L=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y # CONFIG_ISDN_PPP_BSDCOMP is not set CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y # # ISDN feature submodules # CONFIG_ISDN_DRV_LOOP=m CONFIG_ISDN_DIVERSION=m # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=m # # D-channel protocol features # CONFIG_HISAX_EURO=y CONFIG_DE_AOC=y CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y CONFIG_HISAX_DIEHLDIVA=y CONFIG_HISAX_SEDLBAUER=y CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y # CONFIG_HISAX_DEBUG is not set # # HiSax PCMCIA card service modules # CONFIG_HISAX_SEDLBAUER_CS=m CONFIG_HISAX_ELSA_CS=m CONFIG_HISAX_AVM_A1_CS=m CONFIG_HISAX_TELES_CS=m # # HiSax sub driver modules # CONFIG_HISAX_ST5481=m CONFIG_HISAX_HFCUSB=m CONFIG_HISAX_FRITZ_PCIPNP=m CONFIG_HISAX_HDLC=y # # Active cards # CONFIG_ISDN_DRV_TPAM=m CONFIG_HYSDN=m CONFIG_HYSDN_CAPI=y # # CAPI subsystem # CONFIG_ISDN_CAPI=m CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=m CONFIG_ISDN_CAPI_CAPIDRV=m # # CAPI hardware drivers # # # Active AVM cards # CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m # # Active Eicon DIVA Server cards # # CONFIG_CAPI_EICON is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_SOUND_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_VORTEX=m CONFIG_GAMEPORT_FM801=m CONFIG_GAMEPORT_CS461x=m CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # CONFIG_SERIO_RAW is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_VSXXXAA=m CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m CONFIG_JOYSTICK_ADI=m CONFIG_JOYSTICK_COBRA=m CONFIG_JOYSTICK_GF2K=m CONFIG_JOYSTICK_GRIP=m CONFIG_JOYSTICK_GRIP_MP=m CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=m CONFIG_JOYSTICK_SIDEWINDER=m CONFIG_JOYSTICK_TMDC=m CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=m CONFIG_JOYSTICK_MAGELLAN=m CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=m CONFIG_JOYSTICK_STINGER=m CONFIG_JOYSTICK_TWIDDLER=m CONFIG_JOYSTICK_DB9=m CONFIG_JOYSTICK_GAMECON=m CONFIG_JOYSTICK_TURBOGRAFX=m CONFIG_JOYSTICK_JOYDUMP=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set CONFIG_ROCKETPORT=m # CONFIG_CYCLADES is not set # CONFIG_DIGIEPCA is not set # CONFIG_DIGI is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_ISI is not set # CONFIG_SYNCLINK is not set # CONFIG_SYNCLINKMP is not set CONFIG_N_HDLC=m # CONFIG_RISCOM8 is not set # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set CONFIG_STALDRV=y # CONFIG_STALLION is not set # CONFIG_ISTALLION is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_CS=m # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_MULTIPORT=y CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_TIPAR=m # # IPMI # CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m CONFIG_ACQUIRE_WDT=m CONFIG_ADVANTECH_WDT=m CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m CONFIG_SC520_WDT=m CONFIG_EUROTECH_WDT=m CONFIG_IB700_WDT=m CONFIG_WAFER_WDT=m CONFIG_I8XX_TCO=m CONFIG_SC1200_WDT=m # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set CONFIG_CPU5_WDT=m CONFIG_W83627HF_WDT=m CONFIG_W83877F_WDT=m CONFIG_MACHZ_WDT=m # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_HW_RANDOM=m # CONFIG_NVRAM is not set CONFIG_RTC=y CONFIG_DTLK=m CONFIG_R3964=m # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL_MCH=y CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_SIS=m # # PCMCIA character devices # CONFIG_SYNCLINK_CS=m CONFIG_MWAVE=m # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set CONFIG_HANGCHECK_TIMER=m # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI1563=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m # CONFIG_SCx200_ACB is not set CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m CONFIG_I2C_STUB=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_I2C_VOODOO3=m CONFIG_I2C_PCA_ISA=m # # Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_FSCHER=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83627HF=m # # Other I2C Chip support # CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_PCF8574=m CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_RTC8564=m # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BWQCAM=m CONFIG_VIDEO_CQCAM=m CONFIG_VIDEO_W9966=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_PP=m CONFIG_VIDEO_CPIA_USB=m CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_TUNER_3036=m CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_DPC=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_OVCAMCHIP=m # # Radio Adapters # CONFIG_RADIO_GEMTEK_PCI=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_MAESTRO=m # # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m # # Supported SAA7146 based PCI Adapters # CONFIG_DVB_AV7110=m # CONFIG_DVB_AV7110_FIRMWARE is not set CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_DVB_DIBUSB=m CONFIG_DVB_DIBUSB_MISDESIGNED_DEVICES=y # CONFIG_DVB_DIBCOM_DEBUG is not set CONFIG_DVB_CINERGYT2=m # CONFIG_DVB_CINERGYT2_TUNING is not set # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_SKYSTAR=m CONFIG_DVB_B2C2_USB=m # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m # # Supported DVB Frontends # # # Customise DVB Frontends # # # DVB-S (satellite) frontends # CONFIG_DVB_STV0299=m CONFIG_DVB_CX24110=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA80XX=m CONFIG_DVB_MT312=m CONFIG_DVB_VES1X93=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m # # DVB-C (cable) frontends # CONFIG_DVB_ATMEL_AT76C651=m CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_STV0297=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_VIDEO_VIDEOBUF=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m # # Graphics support # CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_CIRRUS=m # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FB_HGA=m CONFIG_FB_HGA_ACCEL=y CONFIG_FB_RIVA=m # CONFIG_FB_RIVA_I2C is not set # CONFIG_FB_RIVA_DEBUG is not set CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G450=y CONFIG_FB_MATROX_G100=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y # CONFIG_FB_RADEON_OLD is not set CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y # CONFIG_FB_RADEON_DEBUG is not set CONFIG_FB_ATY128=m CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y # CONFIG_FB_ATY_GENERIC_LCD is not set # CONFIG_FB_ATY_XL_INIT is not set CONFIG_FB_ATY_GX=y CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=m CONFIG_FB_SAVAGE_ACCEL=m # CONFIG_FB_SIS is not set CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=m CONFIG_FB_3DFX_ACCEL=y CONFIG_FB_VOODOO1=m CONFIG_FB_TRIDENT=m CONFIG_FB_TRIDENT_ACCEL=y # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_BIT32_EMUL=m CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # # PCI devices # CONFIG_SND_AC97_CODEC=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS4281=m CONFIG_SND_EMU10K1=m CONFIG_SND_KORG1212=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_HDSP=m CONFIG_SND_TRIDENT=m CONFIG_SND_YMFPCI=m CONFIG_SND_ALS4000=m CONFIG_SND_CMIPCI=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_MAESTRO3=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_SONICVIBES=m CONFIG_SND_VIA82XX=m CONFIG_SND_VX222=m # # USB devices # CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m # # PCMCIA devices # # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m CONFIG_USB_SL811_HCD=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # CONFIG_USB_MIDI=m CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_RW_DETECT=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y CONFIG_THRUSTMASTER_FF=y CONFIG_USB_HIDDEV=y CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m CONFIG_USB_KBTAB=m CONFIG_USB_POWERMATE=m CONFIG_USB_MTOUCH=m CONFIG_USB_EGALAX=m CONFIG_USB_XPAD=m CONFIG_USB_ATI_REMOTE=m # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # # USB Multimedia devices # CONFIG_USB_DABUSB=m CONFIG_USB_VICAM=m CONFIG_USB_DSBR=m CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m CONFIG_USB_SN9C102=m CONFIG_USB_STV680=m CONFIG_USB_W9968CF=m # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_GENESYS=y CONFIG_USB_NET1080=y CONFIG_USB_PL2301=y CONFIG_USB_KC2190=y # # Intelligent USB Devices/Gadgets # CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_ZAURUS=y CONFIG_USB_CDCETHER=y # # USB Network Adapters # CONFIG_USB_AX8817X=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m # CONFIG_USB_SERIAL_IPW is not set CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m # CONFIG_USB_EMI26 is not set CONFIG_USB_TIGL=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_LED=m # CONFIG_USB_CYTHERM is not set CONFIG_USB_PHIDGETKIT=m CONFIG_USB_PHIDGETSERVO=m CONFIG_USB_TEST=m # # USB ATM/DSL drivers # CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set CONFIG_MMC_BLOCK=m CONFIG_MMC_WBSD=m # # Firmware Drivers # # CONFIG_EDD is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y CONFIG_TMPFS_XATTR=y CONFIG_TMPFS_SECURITY=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set CONFIG_AFFS_FS=m CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m CONFIG_EFS_FS=m # CONFIG_JFFS_FS is not set CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_NAND=y # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_ZLIB=y CONFIG_JFFS2_RTIME=y # CONFIG_JFFS2_RUBIN is not set CONFIG_CRAMFS=m CONFIG_VXFS_FS=m # CONFIG_HPFS_FS is not set CONFIG_QNX4FS_FS=m # CONFIG_QNX4FS_RW is not set CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_EXPERIMENTAL is not set CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_EFI_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_INFO=y # CONFIG_CHECKING is not set CONFIG_INIT_DEBUG=y # CONFIG_IOMMU_DEBUG is not set # CONFIG_KPROBES is not set # # Security options # # CONFIG_KEYS is not set CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_ROOTPLUG is not set CONFIG_SECURITY_SECLVL=m CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y # CONFIG_SECURITY_SELINUX_MLS is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m --------------050102090004090802060504 Content-Type: text/plain; name="2.6.10-uname.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.10-uname.txt" Linux meelo.int.phekda.gotadsl.co.uk 2.6.10 #1 Wed Dec 29 00:43:22 GMT 2004 x86_64 x86_64 x86_64 GNU/Linux --------------050102090004090802060504-- From kaber@trash.net Sun Jan 2 13:06:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 13:06:34 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02L667S011222 for ; Sun, 2 Jan 2005 13:06:27 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.34) id 1ClD3w-0008JB-Uu; Sun, 02 Jan 2005 22:14:56 +0100 Message-ID: <41D86450.1070904@trash.net> Date: Sun, 02 Jan 2005 22:14:56 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041008 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: Peter Bieringer CC: USAGI core , Maillist netdev , Harald Welte , Netfilter development mailing list Subject: Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches References: <019064D0423CE6C823CBF476@t1mobil.muc.aerasec.de> <5F6ACA5CEF52DBFBF11FBF94@t1mobil.muc.aerasec.de> <41CD8B4F.6010402@trash.net> <85346B5DA83795C08812E782@worker.muc.bieringer.de> <41D7DE3E.2090304@trash.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Peter Bieringer wrote: >>>BTW: how to filter incoming traffic after decryption? >>> >>Use tunnel-mode. The decrypted packets will hit PRE_ROUTING >>and LOCAL_IN again. >> > >Ok, confirmed working in tunnel mode, ping6 packet was counted twice in >different rules (esp and icmpv6) > >But for outgoing ping6 packets, this won't work, packet is only counted >(and accepted) by the icmpv6 rule, esp rule got no match, also not the >"all" rule. > >Looks like at the moment, outgoing packet is passing netfilter only one >time, even if encryption is in tunnel mode. > That is correct. > >By design / bug / missing feature? > By design and missing feature :) As I said, patches to fix this for IPv4 will be submitted this week .. IPv6 will hopefully follow soon. Regards Patrick From eric.lemoine@gmail.com Sun Jan 2 15:22:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 15:22:29 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j02NM2f1014530 for ; Sun, 2 Jan 2005 15:22:22 -0800 Received: by wproxy.gmail.com with SMTP id 50so4482wri for ; Sun, 02 Jan 2005 15:30:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dfullWpQ+6i8if36k9vS+ZzayY0N6nDz4RWx3AuyeDG7Ss4db1zvvQdzDIxWypItQQVNzO221czDENVa2inahnEZLBsJz7yAIzPN/1+0wuHc03hwBNT6j2Pjbcn/97aQo2nhRmhfxfa5WCANe9tYafsaQ4v44yvm7MPBxHOmfnQ= Received: by 10.54.10.55 with SMTP id 55mr67773wrj; Sun, 02 Jan 2005 15:30:31 -0800 (PST) Received: by 10.54.30.8 with HTTP; Sun, 2 Jan 2005 15:30:31 -0800 (PST) Message-ID: <5cac192f0501021530672a908a@mail.gmail.com> Date: Mon, 3 Jan 2005 00:30:31 +0100 From: Eric Lemoine Reply-To: Eric Lemoine To: hadi@cyberus.ca Subject: Re: LLTX and netif_stop_queue Cc: Patrick McHardy , "David S. Miller" , roland@topspin.com, netdev@oss.sgi.com, openib-general@openib.org In-Reply-To: <1104240717.1100.66.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_709_5375345.1104708631807" References: <52llbwoaej.fsf@topspin.com> <20041217214432.07b7b21e.davem@davemloft.net> <1103484675.1050.158.camel@jzny.localdomain> <5cac192f04122210491d64d4b6@mail.gmail.com> <20041222202919.057b8331.davem@davemloft.net> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev ------=_Part_709_5375345.1104708631807 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On 28 Dec 2004 08:31:57 -0500, jamal wrote: > On Fri, 2004-12-24 at 11:10, Eric Lemoine wrote: > > > Yes but requiring drivers to release a lock that they should not even > > be aware of doesn't sound good. Another way would be to keep > > dev->queue_lock grabbed when entering start_xmit() and let the driver > > drop it (and re-acquire it before it returns) only if it wishes so. > > Although I don't like this too much either, that's the best way I can > > think of up to now... > > I am not a big fan of that patch either, but i cant think of a cleaner > way to do it. > The violation already happens with the LLTX flag. So maybe a big warning > that says "Do this only if you driver is LLTX enabled". The other way to > do it is put a check to see if LLTX is enabled before releasing that > lock - but why the extra cycles? Driver writer should know. Two (untested) patches implementing what I described above. The first pach (sch_generic.patch) keeps queue_lock held in qdisc_restart() when calling hard_start_xmit() of a LLTX driver. The second (sungem.patch) makes sungem release queue_lock after grabbing its private tx lock. Note that the modifications made to qdisc_restart() are not compatible with the current LLTX drivers. All LLTX drivers must be modified along sungem.patch's lines. Take sungem.patch as an example of how things must be done. Patches apply to current davem bk snapshot. -- Eric ------=_Part_709_5375345.1104708631807 Content-Type: application/octet-stream; name="sch_generic.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sch_generic.patch" PT09PT0gbmV0L3NjaGVkL3NjaF9nZW5lcmljLmMgMS4zMiB2cyBlZGl0ZWQgPT09PT0KLS0tIDEu MzIvbmV0L3NjaGVkL3NjaF9nZW5lcmljLmMJMjAwNC0xMi0yOCAwNTo1MToyMCArMDE6MDAKKysr IGVkaXRlZC9uZXQvc2NoZWQvc2NoX2dlbmVyaWMuYwkyMDA1LTAxLTAyIDIzOjU1OjE4ICswMTow MApAQCAtMTA0LDkgKzEwNCwxNyBAQAogCQkgKiBsb2NraW5nIGFnYWluLiBUaGVzZSBjaGVja3Mg YXJlIHdvcnRoIGl0IGJlY2F1c2UKIAkJICogZXZlbiB1bmNvbmdlc3RlZCBsb2NrcyBjYW4gYmUg cXVpdGUgZXhwZW5zaXZlLgogCQkgKiBUaGUgZHJpdmVyIGNhbiBkbyB0cnlsb2NrIGxpa2UgaGVy ZSB0b28sIGluIGNhc2UKLQkJICogb2YgbG9jayBjb25nZXN0aW9uIGl0IHNob3VsZCByZXR1cm4g LTEgYW5kIHRoZSBwYWNrZXQKLQkJICogd2lsbCBiZSByZXF1ZXVlZC4KKwkJICogb2YgbG9jayBj b25nZXN0aW9uIGl0IHNob3VsZCByZXR1cm4gTkVUREVWX1RYX0xPQ0tFRAorCQkgKiBhbmQgdGhl IHBhY2tldCB3aWxsIGJlIHJlcXVldWVkLgorCQkgKiAKKwkJICogTm90ZTogd2hlbiB0aGUgZHJp dmVyIGhhcyBMTFRYIHNldCBxdWV1ZV9sb2NrIGNhbm5vdAorCQkgKiBiZSBkcm9wcGVkIGluIGhl cmUgaWYgd2Ugd2FudCB0byBhdm9pZCBoYXZpbmcgcGFja2V0cworCQkgKiBwYXNzaW5nIGVhY2hv dmVyIGR1cmluZyB0cmFuc21pdC4gcXVldWVfbG9jayBjYW4gb25seQorCQkgKiBiZSBkcm9wcGVk IGluIGhhcmRfc3RhcnRfeG1pdCgpIGFmdGVyIHByaXZhdGUgdHggbG9jayAKKwkJICogaGFzIGJl ZW4gZ3JhYmJlZC4gSWYgaGFyZF9zdGFydF94bWl0KCkgZG9lcyByZWxlYXNlIAorCQkgKiBxdWV1 ZV9sb2NrIGl0IG11c3QgZ3JhYiBpdCBhZ2FpbiBiZWZvcmUgaXQgcmV0dXJucy4KIAkJICovCisK IAkJaWYgKCFub2xvY2spIHsKIAkJCWlmICghc3Bpbl90cnlsb2NrKCZkZXYtPnhtaXRfbG9jaykp IHsKIAkJCWNvbGxpc2lvbjoKQEAgLTEyOCwxMiArMTM2LDEyIEBACiAJCQl9CiAJCQkvKiBSZW1l bWJlciB0aGF0IHRoZSBkcml2ZXIgaXMgZ3JhYmJlZCBieSB1cy4gKi8KIAkJCWRldi0+eG1pdF9s b2NrX293bmVyID0gc21wX3Byb2Nlc3Nvcl9pZCgpOworCisJCQkvKiBBbmQgcmVsZWFzZSBxdWV1 ZSAqLworCQkJc3Bpbl91bmxvY2soJmRldi0+cXVldWVfbG9jayk7CiAJCX0KIAkJCiAJCXsKLQkJ CS8qIEFuZCByZWxlYXNlIHF1ZXVlICovCi0JCQlzcGluX3VubG9jaygmZGV2LT5xdWV1ZV9sb2Nr KTsKLQogCQkJaWYgKCFuZXRpZl9xdWV1ZV9zdG9wcGVkKGRldikpIHsKIAkJCQlpbnQgcmV0Owog CQkJCWlmIChuZXRkZXZfbml0KQpAQCAtMTQ0LDE0ICsxNTIsMTIgQEAKIAkJCQkJaWYgKCFub2xv Y2spIHsKIAkJCQkJCWRldi0+eG1pdF9sb2NrX293bmVyID0gLTE7CiAJCQkJCQlzcGluX3VubG9j aygmZGV2LT54bWl0X2xvY2spOworCQkJCQkJc3Bpbl9sb2NrKCZkZXYtPnF1ZXVlX2xvY2spOwog CQkJCQl9Ci0JCQkJCXNwaW5fbG9jaygmZGV2LT5xdWV1ZV9sb2NrKTsKIAkJCQkJcmV0dXJuIC0x OwogCQkJCX0KLQkJCQlpZiAocmV0ID09IE5FVERFVl9UWF9MT0NLRUQgJiYgbm9sb2NrKSB7Ci0J CQkJCXNwaW5fbG9jaygmZGV2LT5xdWV1ZV9sb2NrKTsKKwkJCQlpZiAocmV0ID09IE5FVERFVl9U WF9MT0NLRUQgJiYgbm9sb2NrKQogCQkJCQlnb3RvIGNvbGxpc2lvbjsgCi0JCQkJfQogCQkJfQog CiAJCQkvKiBORVRERVZfVFhfQlVTWSAtIHdlIG5lZWQgdG8gcmVxdWV1ZSAqLwpAQCAtMTU5LDgg KzE2NSw4IEBACiAJCQlpZiAoIW5vbG9jaykgeyAKIAkJCQlkZXYtPnhtaXRfbG9ja19vd25lciA9 IC0xOwogCQkJCXNwaW5fdW5sb2NrKCZkZXYtPnhtaXRfbG9jayk7CisJCQkJc3Bpbl9sb2NrKCZk ZXYtPnF1ZXVlX2xvY2spOwogCQkJfSAKLQkJCXNwaW5fbG9jaygmZGV2LT5xdWV1ZV9sb2NrKTsK IAkJCXEgPSBkZXYtPnFkaXNjOwogCQl9CiAK ------=_Part_709_5375345.1104708631807 Content-Type: application/octet-stream; name="sungem.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sungem.patch" PT09PT0gZHJpdmVycy9uZXQvc3VuZ2VtLmMgMS43MSB2cyBlZGl0ZWQgPT09PT0KLS0tIDEuNzEv ZHJpdmVycy9uZXQvc3VuZ2VtLmMJMjAwNC0xMS0xNCAxMDo0NTozNiArMDE6MDAKKysrIGVkaXRl ZC9kcml2ZXJzL25ldC9zdW5nZW0uYwkyMDA1LTAxLTAzIDAwOjAwOjIyICswMTowMApAQCAtOTUw LDYgKzk1MCw3IEBACiAJcmV0dXJuIDA7CiB9CiAKKy8qIENhbGxlZCB3aXRoIGRldi0+cXVldWVf bG9jayBoZWxkICovCiBzdGF0aWMgaW50IGdlbV9zdGFydF94bWl0KHN0cnVjdCBza19idWZmICpz a2IsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpCiB7CiAJc3RydWN0IGdlbSAqZ3AgPSBkZXYtPnBy aXY7CkBAIC05NzYsOCArOTc3LDE2IEBACiAJCXJldHVybiBORVRERVZfVFhfTE9DS0VEOwogCX0K IAorCS8qIFdlIGNhbiBub3cgZHJvcCBxdWV1ZV9sb2NrIHNpbmNlIHR4X2xvY2sgcHJvdGVjdHMg dXMuIEJ1dCByZW1lbWJlcgorCSAqIHRoYXQgcXVldWVfbG9jayBtdXN0IGJlIHJlYWNxdWlyZWQg YmVmb3JlIHdlIHJldHVybi4gTW9yZW92ZXIgd2UKKwkgKiBtdXN0IHJlYWNxdWlyZSBpdCBiZWZv cmUgcmVsZWFzaW5nIHR4X2xvY2sgdG8gYXZvaWQgYmVpbmcgY2FsbGVkCisJICogd2l0aCB0aGUg cXVldWUgc3RvcHBlZC4KKwkgKi8KKwlzcGluX3VubG9jaygmZGV2LT5xdWV1ZV9sb2NrKTsKKwog CS8qIFRoaXMgaXMgYSBoYXJkIGVycm9yLCBsb2cgaXQuICovCiAJaWYgKFRYX0JVRkZTX0FWQUlM KGdwKSA8PSAoc2tiX3NoaW5mbyhza2IpLT5ucl9mcmFncyArIDEpKSB7CisJCXNwaW5fbG9jaygm ZGV2LT5xdWV1ZV9sb2NrKTsKIAkJbmV0aWZfc3RvcF9xdWV1ZShkZXYpOwogCQlzcGluX3VubG9j a19pcnFyZXN0b3JlKCZncC0+dHhfbG9jaywgZmxhZ3MpOwogCQlwcmludGsoS0VSTl9FUlIgUEZY ICIlczogQlVHISBUeCBSaW5nIGZ1bGwgd2hlbiBxdWV1ZSBhd2FrZSFcbiIsCkBAIC0xMDY2LDYg KzEwNzUsNyBAQAogCQkgICAgICAgZGV2LT5uYW1lLCBlbnRyeSwgc2tiLT5sZW4pOwogCW1iKCk7 CiAJd3JpdGVsKGdwLT50eF9uZXcsIGdwLT5yZWdzICsgVFhETUFfS0lDSyk7CisJc3Bpbl9sb2Nr KCZkZXYtPnF1ZXVlX2xvY2spOwogCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmdwLT50eF9sb2Nr LCBmbGFncyk7CiAKIAlkZXYtPnRyYW5zX3N0YXJ0ID0gamlmZmllczsK ------=_Part_709_5375345.1104708631807-- From eric.lemoine@gmail.com Sun Jan 2 23:33:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Jan 2005 23:33:38 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j037XB6o000815 for ; Sun, 2 Jan 2005 23:33:31 -0800 Received: by wproxy.gmail.com with SMTP id 50so29809wri for ; Sun, 02 Jan 2005 23:41:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=cc827pRpvybQlkDhw5gYQr9P6ari95lM9KiR9xjV2v29aAdkHTlWk+yuuThdRsOCk8XrPOw5+zEyOBElAT0QEVh7Obx4aw0ZpkGqc3dzMPB765mweEkvzHp6LJnRAl2MUKGg84vrDXeEMfZngPOhE9MsfXyqOyIhGvmiSPkNrS8= Received: by 10.54.22.35 with SMTP id 35mr229070wrv; Sun, 02 Jan 2005 23:41:40 -0800 (PST) Received: by 10.54.30.8 with HTTP; Sun, 2 Jan 2005 23:41:40 -0800 (PST) Message-ID: <5cac192f050102234168b40bc@mail.gmail.com> Date: Mon, 3 Jan 2005 08:41:40 +0100 From: Eric Lemoine Reply-To: Eric Lemoine To: hadi@cyberus.ca Subject: Re: LLTX and netif_stop_queue Cc: Patrick McHardy , "David S. Miller" , roland@topspin.com, netdev@oss.sgi.com, openib-general@openib.org In-Reply-To: <5cac192f0501021530672a908a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <52llbwoaej.fsf@topspin.com> <20041217214432.07b7b21e.davem@davemloft.net> <1103484675.1050.158.camel@jzny.localdomain> <5cac192f04122210491d64d4b6@mail.gmail.com> <20041222202919.057b8331.davem@davemloft.net> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev > Two (untested) patches implementing what I described above. > > The first pach (sch_generic.patch) keeps queue_lock held in > qdisc_restart() when calling hard_start_xmit() of a LLTX driver. The > second (sungem.patch) makes sungem release queue_lock after grabbing > its private tx lock. > > Note that the modifications made to qdisc_restart() are not compatible > with the current LLTX drivers. All LLTX drivers must be modified along > sungem.patch's lines. Take sungem.patch as an example of how things > must be done. Correction: the current LLTX drivers need not be modified to work correctly. However, as an opimisation, they can modified along sungem.patch's line. Thanks, -- Eric From thomas.spatzier@de.ibm.com Mon Jan 3 01:03:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 01:03:47 -0800 (PST) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0393HuU007091 for ; Mon, 3 Jan 2005 01:03:38 -0800 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j039BjvU230926 for ; Mon, 3 Jan 2005 09:11:45 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j039CZ3N095016 for ; Mon, 3 Jan 2005 10:12:35 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j039BiRg004882 for ; Mon, 3 Jan 2005 10:11:45 +0100 Received: from d12ml061.megacenter.de.ibm.com ([9.149.165.51]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j039BiJB004874; Mon, 3 Jan 2005 10:11:44 +0100 In-Reply-To: <1103723307.1092.83.camel@jzny.localdomain> Subject: Re: [patch 4/10] s390: network driver. To: hadi@cyberus.ca Cc: "David S. Miller" , Hasso Tepper , Herbert Xu , Jeff Garzik , netdev@oss.sgi.com, Paul Jakma , Tommy Christensen X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Thomas Spatzier Date: Mon, 3 Jan 2005 10:10:56 +0100 X-MIMETrack: Serialize by Router on D12ML061/12/M/IBM(Release 6.51HF338 | June 21, 2004) at 03/01/2005 10:12:23 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: thomas.spatzier@de.ibm.com Precedence: bulk X-list: netdev jamal wrote on 22.12.2004 14:48:28: > I think this needs to be resolved too. > It is possible to have a centralized action instead of requiring drivers > to make changes if we know the state of the driver is in netcarrier_off. > What that would require is > on cable gone, you just say: > netif_carrier_off(); > and the top layer code will junk the packets before they hit the driver. > This way the socket code can continue sending whatever it wants but if > theres no link, then its fair to drop those packets? > > If this acceptable i can generate a quick patch. Does Jamal's solution sound good for all? Then I would change my driver to do the following: just call netif_carrier_off() (not netif_stop_queue) Then the upper layers will do the propper thing, so I should not get any more packets. If I still get some, I will drop them. Did I get this correctly? BTW: A happy new year to all ;-) Regards, Thomas. From tgraf@suug.ch Mon Jan 3 04:48:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 04:48:14 -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 j03Clf0O026270 for ; Mon, 3 Jan 2005 04:48:02 -0800 Received: from postel.suug.ch (unknown [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 4B0AC84; Mon, 3 Jan 2005 13:55:52 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 67CA01C0EA; Mon, 3 Jan 2005 13:56:35 +0100 (CET) Date: Mon, 3 Jan 2005 13:56:35 +0100 From: Thomas Graf To: Jamal Hadi Salim Cc: netdev@oss.sgi.com Subject: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050103125635.GB26856@postel.suug.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13341 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 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jamal et al, I attached 4 patches of a first ematch implementation. Comments and suggestions very much appreciated. Compiles but untested. Patch 1: ematch API API visible to classifier: tcf_em_tree_validate(tp, tlv, tree) tlv: ematches TLV tree: temporary struct tcf_ematch_tree Validates the data in the TLV and builds the ematch tree upon the temporary variable. tcf_em_tree_change(tp, dst, src) dst: destination ematch tree (from classifier private data) src: source ematch tree (temporary tree from _validate) Replaces the ematch tree in the classifier with the temporary tree. tcf_em_tree_destroy(tp, tree) Destroys an ematch tree tcf_em_tree_dump(skb, tree, tlv_type) tlv_type: T of ematches TLV (classifier specific) Dumps the ematch tree to the skb with given tlv_type. tcf_em_tree_match(skb, tree, res) res: struct tcf_result * Macro returning 1 if no ematches are configured, otherwise the tree is evaulated and 1 is returned if the tree matches. The complete API is also visible if ematch is not configured but will result in empty macros/structures. Those need to be improved though. API visible to ematches: tcf_em_register(ops) tcf_em_unregister(ops) ematches must at least provide the following callbacks: change, match Optional callbacks are: destroy, dump kind must be set to a unique ID, i thought about declaring 1..2^16 to ematches within the mainline tree and have the rest declared as to be used for private use to avoid collisions. Patch 2: u32 ematch Is an ematch based on the existing u32 match but allows to specify the layer and is able to read u32 values if alignment does not allow direct access. Additionally it supports the operands, eq, lt, gt. It is a few ticks slower than the existing match but worth it. However, it does not support the neat nexthdr via hashing as u32 does which is the main problem before u32 can make proper use of it. Patch 3: nbyte ematch Compares n bytes at specified offset. To be used for IPv6 address matches to avoid 4 ANDed u32 matches. Patch 4: Basic Classifier This is the most basic classifier possible doing nothing more than executing extensions and ematches. It follows the architecture of u32 and fw by storing a filter list in tp->root. This eventually makes fw obsolete once meta ematch is available. I didn't copy the u32/fw code but rather made use of the list.h. pskbs are completely unhandled so far as I'm still not sure how to do it properly. Cheers --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="01_ematch.diff" diff -Nru linux-2.6.10-bk4.orig/include/linux/pkt_cls.h linux-2.6.10-bk4/include/linux/pkt_cls.h --- linux-2.6.10-bk4.orig/include/linux/pkt_cls.h 2005-01-02 21:39:16.000000000 +0100 +++ linux-2.6.10-bk4/include/linux/pkt_cls.h 2005-01-02 21:31:48.000000000 +0100 @@ -319,4 +319,47 @@ #define TCA_TCINDEX_MAX (__TCA_TCINDEX_MAX - 1) +struct tcf_ematch_tree_hdr +{ + __u16 nmatches; + __u16 progid; +}; + +enum +{ + TCA_EMATCH_TREE_UNSPEC, + TCA_EMATCH_TREE_HDR, + TCA_EMATCH_TREE_LIST, + __TCA_EMATCH_TREE_MAX +}; +#define TCA_EMATCH_TREE_MAX (__TCA_EMATCH_TREE_MAX - 1) + +struct tcf_ematch_hdr +{ + __u16 handle; + __u16 matchID; + __u16 kind; + __u8 flags; + __u8 pad; /* currently unused */ +}; + +enum +{ + TCF_EM_CONTAINER, + __TCF_EM_MAX +}; + +#define TCF_EM_REL_MASK 3 +#define TCF_EM_REL_VALID(v) \ + (!(((v) & TCF_EM_REL_MASK) == TCF_EM_REL_MASK)) +#define TCF_EM_LAST_KEY(v) (!((v) & TCF_EM_REL_MASK)) + +#define TCF_EM_REL_OBVIOUS(v, r) (TCF_EM_LAST_KEY(v) || \ + (!(r) && ((v) & TCF_EM_REL_AND)) || ((r) && ((v) & TCF_EM_REL_OR))) + +#define TCF_EM_REL_END (1<<0) +#define TCF_EM_REL_AND (1<<1) +#define TCF_EM_REL_OR (1<<2) +#define TCF_EM_INVERT (1<<3) + #endif diff -Nru linux-2.6.10-bk4.orig/include/linux/rtnetlink.h linux-2.6.10-bk4/include/linux/rtnetlink.h --- linux-2.6.10-bk4.orig/include/linux/rtnetlink.h 2005-01-02 21:39:16.000000000 +0100 +++ linux-2.6.10-bk4/include/linux/rtnetlink.h 2005-01-02 21:32:46.000000000 +0100 @@ -779,6 +779,11 @@ goto rtattr_failure; \ __rta_fill(skb, attrtype, attrlen, data); }) +#define RTA_PUT_NOHDR(skb, attrlen, data) \ +({ if (unlikely(skb_tailroom(skb) < (int)(attrlen))) \ + goto rtattr_failure; \ + memcpy(skb_put(skb, RTA_ALIGN(attrlen)), data, attrlen); }) + static inline struct rtattr * __rta_reserve(struct sk_buff *skb, int attrtype, int attrlen) { diff -Nru linux-2.6.10-bk4.orig/include/net/pkt_cls.h linux-2.6.10-bk4/include/net/pkt_cls.h --- linux-2.6.10-bk4.orig/include/net/pkt_cls.h 2005-01-02 21:39:16.000000000 +0100 +++ linux-2.6.10-bk4/include/net/pkt_cls.h 2005-01-02 21:33:21.000000000 +0100 @@ -149,6 +149,75 @@ extern int tcf_exts_dump_stats(struct sk_buff *skb, struct tcf_exts *exts, struct tcf_ext_map *map); +#ifdef CONFIG_NET_EMATCH + +struct tcf_ematch_ops; + +struct tcf_ematch +{ + struct tcf_ematch_hdr hdr; + struct tcf_ematch_ops * ops; + unsigned long data; +}; + +struct tcf_ematch_tree +{ + struct tcf_ematch_tree_hdr hdr; + struct tcf_ematch * matches; + +}; + +#define em_lookup_match(t, i) (&(t)->matches[(i)]) + +struct tcf_ematch_ops +{ + int kind; + + int (*change)(struct tcf_proto *tp, void *data, + int len, struct tcf_ematch *m); + + int (*match)(struct sk_buff *skb, struct tcf_ematch *m); + int (*destroy)(struct tcf_proto *tp, struct tcf_ematch *m); + int (*dump)(struct sk_buff *skb, struct tcf_ematch *m); + + struct module * owner; + struct list_head link; +}; + +extern int tcf_em_register(struct tcf_ematch_ops *); +extern int tcf_em_unregister(struct tcf_ematch_ops *); +extern int tcf_em_tree_validate(struct tcf_proto *, struct rtattr *, + struct tcf_ematch_tree *); +extern void tcf_em_tree_destroy(struct tcf_proto *, struct tcf_ematch_tree *); +extern int tcf_em_tree_dump(struct sk_buff *, struct tcf_ematch_tree *, int); +extern int __tcf_em_tree_match(struct sk_buff *, struct tcf_ematch_tree *); + +static inline void +tcf_em_tree_change(struct tcf_proto *tp, struct tcf_ematch_tree *dst, + struct tcf_ematch_tree *src) +{ + tcf_tree_lock(tp); + memcpy(dst, src, sizeof(*dst)); + tcf_tree_unlock(tp); +} + +#define tcf_em_tree_match(skb, t) \ + ((t)->hdr.nmatches ? __tcf_em_tree_match(skb, t) : 1) + +#else /* CONFIG_NET_EMATCH */ + +struct tcf_ematch_tree +{ +}; + +#define tcf_em_tree_validate(tp, tb, t) do { } while(0) +#define tcf_em_tree_destroy(tp, t) do { } while(0) +#define tcf_em_tree_dump(skb, t, tlv) do { } while(0) +#define tcf_em_tree_change(tp, dst, src) do { } while(0) +#define tcf_em_tree_match(skb, t) do { } while(0) + +#endif /* CONFIG_NET_EMATCH */ + #ifdef CONFIG_NET_CLS_IND static inline int tcf_change_indev(struct tcf_proto *tp, char *indev, struct rtattr *indev_tlv) diff -Nru linux-2.6.10-bk4.orig/net/sched/Kconfig linux-2.6.10-bk4/net/sched/Kconfig --- linux-2.6.10-bk4.orig/net/sched/Kconfig 2005-01-02 21:39:16.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Kconfig 2005-01-02 21:31:44.000000000 +0100 @@ -375,6 +375,12 @@ To compile this code as a module, choose M here: the module will be called cls_rsvp6. +config NET_EMATCH + bool "Extended Matches" + depends on NET_CLS + ---help--- + TODO + config NET_CLS_ACT bool "Packet ACTION" depends on EXPERIMENTAL && NET_CLS && NET_QOS diff -Nru linux-2.6.10-bk4.orig/net/sched/Makefile linux-2.6.10-bk4/net/sched/Makefile --- linux-2.6.10-bk4.orig/net/sched/Makefile 2005-01-02 21:39:16.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Makefile 2005-01-02 21:31:48.000000000 +0100 @@ -33,3 +33,4 @@ obj-$(CONFIG_NET_CLS_RSVP) += cls_rsvp.o obj-$(CONFIG_NET_CLS_TCINDEX) += cls_tcindex.o obj-$(CONFIG_NET_CLS_RSVP6) += cls_rsvp6.o +obj-$(CONFIG_NET_EMATCH) += ematch.o diff -Nru linux-2.6.10-bk4.orig/net/sched/ematch.c linux-2.6.10-bk4/net/sched/ematch.c --- linux-2.6.10-bk4.orig/net/sched/ematch.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/ematch.c 2005-01-01 23:32:13.000000000 +0100 @@ -0,0 +1,300 @@ +/* + * net/sched/ematch.c Extended Match API + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EMATCH_STACK_SIZE 32 + +static LIST_HEAD(ematch_ops); +static rwlock_t ematch_mod_lock = RW_LOCK_UNLOCKED; + +static inline struct tcf_ematch_ops * +tcf_em_lookup(u16 kind) +{ + struct tcf_ematch_ops *e = NULL; + + read_lock(&ematch_mod_lock); + list_for_each_entry(e, &ematch_ops, link) { + if (kind == e->kind) { + if (!try_module_get(e->owner)) + e = NULL; + break; + } + } + read_unlock(&ematch_mod_lock); + + return e; +} + +int tcf_em_register(struct tcf_ematch_ops *ops) +{ + int err = -EEXIST; + struct tcf_ematch_ops *e; + + write_lock(&ematch_mod_lock); + list_for_each_entry(e, &ematch_ops, link) + if (ops->kind == e->kind) + goto errout; + + list_add_tail(&ops->link, &ematch_ops); + err = 0; +errout: + write_unlock(&ematch_mod_lock); + return err; +} + +int tcf_em_unregister(struct tcf_ematch_ops *ops) +{ + int err = 0; + struct tcf_ematch_ops *e; + + write_lock(&ematch_mod_lock); + list_for_each_entry(e, &ematch_ops, link) { + if (e == ops) { + list_del(&e->link); + goto out; + } + } + + err = -ENOENT; +out: + write_unlock(&ematch_mod_lock); + return err; +} + +static int tcf_em_validate(struct tcf_proto *tp, struct tcf_ematch_tree_hdr *th, + struct tcf_ematch *m, struct rtattr *rta) +{ + int err = -EINVAL; + struct tcf_ematch_hdr *mh = RTA_DATA(rta); + int datalen = RTA_PAYLOAD(rta) - sizeof(*mh); + void *data = (void *) data + sizeof(*mh); + + if (!TCF_EM_REL_VALID(mh->flags)) + goto errout; + + memcpy(&m->hdr, mh, sizeof(*mh)); + + if (mh->kind == TCF_EM_CONTAINER) { + u32 ref; + + if (datalen < sizeof(ref)) + goto errout; + ref = *(u32 *) data; + if (ref >= th->nmatches) + goto errout; + m->data = ref; + } else { + struct tcf_ematch_ops *ops = tcf_em_lookup(mh->kind); + + if (ops == NULL) { + err = -ENOENT; + goto errout; + } + + if (ops->change) { + err = ops->change(tp, data, datalen, m); + if (err < 0) + goto errout; + } + } + + err = 0; +errout: + return err; +} + +int tcf_em_tree_validate(struct tcf_proto *tp, struct rtattr *rta, + struct tcf_ematch_tree *tree) +{ + int i, len, mlen, err = -EINVAL; + struct rtattr *m, *tb[TCA_EMATCH_TREE_MAX]; + struct tcf_ematch_tree_hdr *th; + + if (!rta || rtattr_parse_nested(tb, TCA_EMATCH_TREE_MAX, rta) < 0) + goto errout; + + if (RTA_PAYLOAD(tb[TCA_EMATCH_TREE_HDR-1]) < sizeof(*th) || + RTA_PAYLOAD(tb[TCA_EMATCH_TREE_LIST-1]) < sizeof(*m)) + goto errout; + + th = RTA_DATA(tb[TCA_EMATCH_TREE_HDR-1]); + m = RTA_DATA(tb[TCA_EMATCH_TREE_LIST-1]); + len = RTA_PAYLOAD(tb[TCA_EMATCH_TREE_LIST-1]); + mlen = th->nmatches * sizeof(struct tcf_ematch); + + memcpy(&tree->hdr, th, sizeof(*th)); + + tree->matches = kmalloc(mlen, GFP_KERNEL); + if (tree->matches == NULL) + goto errout; + memset(tree->matches, 0, mlen); + + for (i = 0; RTA_OK(m, len); i++) { + if (rta->rta_type != (i+1) || i >= th->nmatches || + RTA_PAYLOAD(rta) < sizeof(struct tcf_ematch_hdr)) { + err = -EINVAL; + goto errout_abort; + } + + err = tcf_em_validate(tp, th, em_lookup_match(tree, i), rta); + if (err < 0) + goto errout_abort; + + m = RTA_NEXT(m, len); + } + + if (i != th->nmatches) { + err = -EINVAL; + goto errout_abort; + } + + + err = 0; +errout: + return err; + +errout_abort: + tcf_em_tree_destroy(tp, tree); + return err; +} + + +void tcf_em_tree_destroy(struct tcf_proto *tp, struct tcf_ematch_tree *t) +{ + int i; + + if (t->matches == NULL) + return; + + for (i = 0; i < t->hdr.nmatches; i++) { + struct tcf_ematch *m = em_lookup_match(t, i); + if (m->ops) { + if (m->ops->destroy) + m->ops->destroy(tp, m); + module_put(m->ops->owner); + } + } + + kfree(t->matches); +} + +int tcf_em_tree_dump(struct sk_buff *skb, struct tcf_ematch_tree *t, int tlv) +{ + int i; + struct rtattr * p_rta = (struct rtattr*) skb->tail; + struct rtattr * pm_rta; + + RTA_PUT(skb, tlv, 0, NULL); + RTA_PUT(skb, TCA_EMATCH_TREE_HDR, sizeof(t->hdr), &t->hdr); + + pm_rta = (struct rtattr *) skb->tail; + RTA_PUT(skb, TCA_EMATCH_TREE_LIST, 0, NULL); + + for (i = 0; i < t->hdr.nmatches; i++) { + struct rtattr * pd_rta = (struct rtattr*) skb->tail; + struct tcf_ematch *m = em_lookup_match(t, i); + + RTA_PUT(skb, i+1, sizeof(m->hdr), &m->hdr); + if (m->ops->dump && m->ops->dump(skb, m) < 0) + goto rtattr_failure; + pd_rta->rta_len = skb->tail - (u8*) pd_rta; + } + + pm_rta->rta_len = skb->tail - (u8*)pm_rta; + p_rta->rta_len = skb->tail - (u8*)p_rta; + return 0; +rtattr_failure: + return -1; +} + +static inline int tcf_em_match(struct sk_buff *skb, struct tcf_ematch *m) +{ + int r = 0; + + if (m->ops->match) + r = m->ops->match(skb, m); + + return m->hdr.flags & TCF_EM_INVERT ? !r : r; +} + +/* Do not use this function directly, use tcf_em_tree_match */ +int __tcf_em_tree_match(struct sk_buff *skb, struct tcf_ematch_tree *t) +{ + int i = 0, n = 0, r = 0; + struct tcf_ematch *m; + int stack[EMATCH_STACK_SIZE]; + + memset(stack, 0, sizeof(stack)); + +proceed: + while (n < t->hdr.nmatches) { + m = em_lookup_match(t, n); + + if (m->hdr.kind == TCF_EM_CONTAINER) { + if (unlikely(i >= EMATCH_STACK_SIZE)) { + if (net_ratelimit()) + printk("Local stack overflow, " \ + "increase EMATCH_STACK_SIZE\n"); + return -1; + } + + if (unlikely(m->data <= n)) { + if (net_ratelimit()) + printk("Detected backward precedence " \ + "jump, fix your filter.\n"); + return -1; + } + + stack[i++] = n; + n = m->data; + continue; + } + + r = tcf_em_match(skb, m); + if (TCF_EM_REL_OBVIOUS(m->hdr.flags, r)) + break; + n++; + } + +pop_stack: + if (i > 0) { + n = stack[--i]; + m = em_lookup_match(t, n); + + if (TCF_EM_REL_OBVIOUS(m->hdr.flags, r)) + goto pop_stack; + else { + n++; + goto proceed; + } + } + + return r; +} + +EXPORT_SYMBOL(tcf_em_register); +EXPORT_SYMBOL(tcf_em_unregister); +EXPORT_SYMBOL(tcf_em_tree_validate); +EXPORT_SYMBOL(tcf_em_tree_destroy); +EXPORT_SYMBOL(tcf_em_tree_dump); +EXPORT_SYMBOL(__tcf_em_tree_match); + --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="02_em_u32.diff" diff -Nru linux-2.6.10-bk4.orig/include/linux/pkt_cls.h linux-2.6.10-bk4/include/linux/pkt_cls.h --- linux-2.6.10-bk4.orig/include/linux/pkt_cls.h 2005-01-02 22:37:46.000000000 +0100 +++ linux-2.6.10-bk4/include/linux/pkt_cls.h 2005-01-02 22:37:39.000000000 +0100 @@ -346,6 +346,7 @@ enum { TCF_EM_CONTAINER, + TCF_EM_U32, __TCF_EM_MAX }; @@ -362,4 +363,28 @@ #define TCF_EM_REL_OR (1<<2) #define TCF_EM_INVERT (1<<3) +struct tcf_em_u32 +{ + __u32 val; + __u32 mask; + __u16 off; + __u8 align; + __u8 layer:4; + __u8 opnd:4; +}; + +enum +{ + TCF_EM_ALIGN_U8 = 1, + TCF_EM_ALIGN_U16 = 2, + TCF_EM_ALIGN_U32 = 4 +}; + +enum +{ + TCF_EM_OPND_EQ, + TCF_EM_OPND_GT, + TCF_EM_OPND_LT +}; + #endif diff -Nru linux-2.6.10-bk4.orig/include/net/pkt_cls.h linux-2.6.10-bk4/include/net/pkt_cls.h --- linux-2.6.10-bk4.orig/include/net/pkt_cls.h 2005-01-02 22:37:46.000000000 +0100 +++ linux-2.6.10-bk4/include/net/pkt_cls.h 2005-01-02 22:23:24.000000000 +0100 @@ -218,6 +218,36 @@ #endif /* CONFIG_NET_EMATCH */ +static inline u32 tcf_read_bucket(u8 *ptr, u8 align) +{ + switch (align) { + case TCF_EM_ALIGN_U8: + return *ptr; + case TCF_EM_ALIGN_U16: + return (*ptr << 8) | *(ptr+1); + case TCF_EM_ALIGN_U32: + return (*ptr << 24) | (*(ptr+1) << 16) | + (*(ptr+2) << 8) | *(ptr+3); + } + return 0; +} + +static inline u8 * tcf_get_base_ptr(struct sk_buff *skb, u8 layer) +{ + switch (layer) { + case 0: + return skb->data; + case 1: + return skb->nh.raw; + case 2: + return skb->h.raw; + } + return NULL; +} + +#define tcf_valid_offset(skb, ptr, off, len) \ + ((ptr + off + len) < skb->tail && (ptr + off) > skb->head) + #ifdef CONFIG_NET_CLS_IND static inline int tcf_change_indev(struct tcf_proto *tp, char *indev, struct rtattr *indev_tlv) diff -Nru linux-2.6.10-bk4.orig/net/sched/Kconfig linux-2.6.10-bk4/net/sched/Kconfig --- linux-2.6.10-bk4.orig/net/sched/Kconfig 2005-01-02 22:37:46.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Kconfig 2005-01-02 22:37:39.000000000 +0100 @@ -381,6 +381,12 @@ ---help--- TODO +config NET_EMATCH_U32 + tristate "U32" + depends on NET_EMATCH + ---help--- + TODO + config NET_CLS_ACT bool "Packet ACTION" depends on EXPERIMENTAL && NET_CLS && NET_QOS diff -Nru linux-2.6.10-bk4.orig/net/sched/Makefile linux-2.6.10-bk4/net/sched/Makefile --- linux-2.6.10-bk4.orig/net/sched/Makefile 2005-01-02 22:37:46.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Makefile 2005-01-02 22:37:39.000000000 +0100 @@ -34,3 +34,4 @@ obj-$(CONFIG_NET_CLS_TCINDEX) += cls_tcindex.o obj-$(CONFIG_NET_CLS_RSVP6) += cls_rsvp6.o obj-$(CONFIG_NET_EMATCH) += ematch.o +obj-$(CONFIG_NET_EMATCH_U32) += em_u32.o diff -Nru linux-2.6.10-bk4.orig/net/sched/em_u32.c linux-2.6.10-bk4/net/sched/em_u32.c --- linux-2.6.10-bk4.orig/net/sched/em_u32.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/em_u32.c 2005-01-02 22:38:27.000000000 +0100 @@ -0,0 +1,98 @@ +/* + * net/sched/em_u32.c U32 ematch + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int em_u32_change(struct tcf_proto *tp, void *data, int len, + struct tcf_ematch *m) +{ + if (len != sizeof(struct tcf_em_u32)) + return -EINVAL; + + m->data = (unsigned long) kmalloc(len, GFP_KERNEL); + if (!m->data) + return -ENOBUFS; + + memcpy((void *) m->data, data, len); + return 0; +} + +static int em_u32_match(struct sk_buff *skb, struct tcf_ematch *m) +{ + struct tcf_em_u32 *u = (struct tcf_em_u32 *) m->data; + u8 *ptr = tcf_get_base_ptr(skb, u->layer); + u32 v; + + if (unlikely(!tcf_valid_offset(skb, ptr, u->off, u->align))) + return 0; + + v = tcf_read_bucket(ptr + u->off, u->align) & u->mask; + + switch (u->opnd) { + case TCF_EM_OPND_EQ: + return v == u->val; + case TCF_EM_OPND_LT: + return v < u->val; + case TCF_EM_OPND_GT: + return v > u->val; + } + + return 0; +} + +static int em_u32_destroy(struct tcf_proto *tp, struct tcf_ematch *m) +{ + kfree((void *) m->data); + return 0; +} + +static int em_u32_dump(struct sk_buff *skb, struct tcf_ematch *m) +{ + RTA_PUT_NOHDR(skb, sizeof(struct tcf_em_u32), (void *) m->data); + return 0; +rtattr_failure: + return -1; +} + +static struct tcf_ematch_ops em_u32_ops = { + .kind = TCF_EM_U32, + .change = em_u32_change, + .match = em_u32_match, + .destroy = em_u32_destroy, + .dump = em_u32_dump, + .owner = THIS_MODULE, + .link = LIST_HEAD_INIT(em_u32_ops.link) +}; + +static int __init init_em_u32(void) +{ + return tcf_em_register(&em_u32_ops); +} + +static void __exit exit_em_u32(void) +{ + tcf_em_unregister(&em_u32_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_em_u32); +module_exit(exit_em_u32); + --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="03_em_nbyte.diff" diff -Nru linux-2.6.10-bk4.orig/include/linux/pkt_cls.h linux-2.6.10-bk4/include/linux/pkt_cls.h --- linux-2.6.10-bk4.orig/include/linux/pkt_cls.h 2005-01-02 22:44:16.000000000 +0100 +++ linux-2.6.10-bk4/include/linux/pkt_cls.h 2005-01-02 22:44:31.000000000 +0100 @@ -347,6 +347,7 @@ { TCF_EM_CONTAINER, TCF_EM_U32, + TCF_EM_NBYTE, __TCF_EM_MAX }; @@ -387,4 +388,11 @@ TCF_EM_OPND_LT }; +struct tcf_em_nbyte +{ + __u16 off; + __u16 len:12; + __u8 layer:4; +}; + #endif diff -Nru linux-2.6.10-bk4.orig/net/sched/Kconfig linux-2.6.10-bk4/net/sched/Kconfig --- linux-2.6.10-bk4.orig/net/sched/Kconfig 2005-01-02 22:44:16.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Kconfig 2005-01-02 22:44:31.000000000 +0100 @@ -387,6 +387,12 @@ ---help--- TODO +config NET_EMATCH_NBYTE + tristate "N-Byte" + depends on NET_EMATCH + ---help--- + TODO + config NET_CLS_ACT bool "Packet ACTION" depends on EXPERIMENTAL && NET_CLS && NET_QOS diff -Nru linux-2.6.10-bk4.orig/net/sched/Makefile linux-2.6.10-bk4/net/sched/Makefile --- linux-2.6.10-bk4.orig/net/sched/Makefile 2005-01-02 22:44:16.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Makefile 2005-01-02 22:44:31.000000000 +0100 @@ -35,3 +35,4 @@ obj-$(CONFIG_NET_CLS_RSVP6) += cls_rsvp6.o obj-$(CONFIG_NET_EMATCH) += ematch.o obj-$(CONFIG_NET_EMATCH_U32) += em_u32.o +obj-$(CONFIG_NET_EMATCH_NBYTE) += em_nbyte.o diff -Nru linux-2.6.10-bk4.orig/net/sched/em_nbyte.c linux-2.6.10-bk4/net/sched/em_nbyte.c --- linux-2.6.10-bk4.orig/net/sched/em_nbyte.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/em_nbyte.c 2005-01-02 22:54:20.000000000 +0100 @@ -0,0 +1,95 @@ +/* + * net/sched/em_nbyte.c N-Byte ematch + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct nbyte_data +{ + struct tcf_em_nbyte hdr; + char pattern[0]; +}; + +static int em_nbyte_validate(struct tcf_proto *tp, void *data, int len, + struct tcf_ematch *m) +{ + struct tcf_em_nbyte *n = data; + + if (len < sizeof(*n) || len < (sizeof(*n) + n->len)) + return -EINVAL; + + m->data = (unsigned long) kmalloc(sizeof(*n) + n->len, GFP_KERNEL); + if (!m->data) + return -ENOBUFS; + + memcpy((void *) m->data, data, sizeof(*n) + n->len); + return 0; +} + +static int em_nbyte_match(struct sk_buff *skb, struct tcf_ematch *m) +{ + struct nbyte_data *d = (struct nbyte_data *) m->data; + u8 *ptr = tcf_get_base_ptr(skb, d->hdr.layer); + + if (unlikely(!tcf_valid_offset(skb, ptr, d->hdr.off, d->hdr.len))) + return 0; + + return !memcmp(ptr + d->hdr.off, d->pattern, d->hdr.len); +} + +static int em_nbyte_destroy(struct tcf_proto *tp, struct tcf_ematch *m) +{ + kfree((void *) m->data); + return 0; +} + +static int em_nbyte_dump(struct sk_buff *skb, struct tcf_ematch *m) +{ + struct nbyte_data *d = (struct nbyte_data *) m->data; + RTA_PUT_NOHDR(skb, sizeof(*d) + d->hdr.len, d); + return 0; +rtattr_failure: + return -1; +} + +static struct tcf_ematch_ops em_nbyte_ops = { + .kind = TCF_EM_NBYTE, + .change = em_nbyte_validate, + .match = em_nbyte_match, + .destroy = em_nbyte_destroy, + .dump = em_nbyte_dump, + .owner = THIS_MODULE, + .link = LIST_HEAD_INIT(em_nbyte_ops.link) +}; + +static int __init init_em_nbyte(void) +{ + return tcf_em_register(&em_nbyte_ops); +} + +static void __exit exit_em_nbyte(void) +{ + tcf_em_unregister(&em_nbyte_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_em_nbyte); +module_exit(exit_em_nbyte); + --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="04_cls_basic.diff" diff -Nru linux-2.6.10-bk4.orig/include/linux/pkt_cls.h linux-2.6.10-bk4/include/linux/pkt_cls.h --- linux-2.6.10-bk4.orig/include/linux/pkt_cls.h 2005-01-02 22:57:36.000000000 +0100 +++ linux-2.6.10-bk4/include/linux/pkt_cls.h 2005-01-03 02:43:05.000000000 +0100 @@ -319,6 +319,20 @@ #define TCA_TCINDEX_MAX (__TCA_TCINDEX_MAX - 1) +/* Basic filter */ + +enum +{ + TCA_BASIC_UNSPEC, + TCA_BASIC_CLASSID, + TCA_BASIC_EMATCHES, + TCA_BASIC_ACT, + TCA_BASIC_POLICE, + __TCA_BASIC_MAX +}; + +#define TCA_BASIC_MAX (__TCA_BASIC_MAX - 1) + struct tcf_ematch_tree_hdr { __u16 nmatches; diff -Nru linux-2.6.10-bk4.orig/net/sched/Kconfig linux-2.6.10-bk4/net/sched/Kconfig --- linux-2.6.10-bk4.orig/net/sched/Kconfig 2005-01-02 22:57:36.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Kconfig 2005-01-03 03:27:54.000000000 +0100 @@ -269,6 +269,12 @@ Documentation and software is at . +config NET_CLS_BASIC + tristate "Basic classifier" + depends on NET_CLS + ---help--- + TODO + config NET_CLS_TCINDEX tristate "TC index classifier" depends on NET_CLS diff -Nru linux-2.6.10-bk4.orig/net/sched/Makefile linux-2.6.10-bk4/net/sched/Makefile --- linux-2.6.10-bk4.orig/net/sched/Makefile 2005-01-02 22:57:36.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/Makefile 2005-01-03 03:27:21.000000000 +0100 @@ -33,6 +33,7 @@ obj-$(CONFIG_NET_CLS_RSVP) += cls_rsvp.o obj-$(CONFIG_NET_CLS_TCINDEX) += cls_tcindex.o obj-$(CONFIG_NET_CLS_RSVP6) += cls_rsvp6.o +obj-$(CONFIG_NET_CLS_BASIC) += cls_basic.o obj-$(CONFIG_NET_EMATCH) += ematch.o obj-$(CONFIG_NET_EMATCH_U32) += em_u32.o obj-$(CONFIG_NET_EMATCH_NBYTE) += em_nbyte.o diff -Nru linux-2.6.10-bk4.orig/net/sched/cls_basic.c linux-2.6.10-bk4/net/sched/cls_basic.c --- linux-2.6.10-bk4.orig/net/sched/cls_basic.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.10-bk4/net/sched/cls_basic.c 2005-01-03 13:32:00.000000000 +0100 @@ -0,0 +1,300 @@ +/* + * net/sched/cls_basic.c Basic Packet Classifier. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct basic_head +{ + u32 hgenerator; + struct list_head flist; +}; + +struct basic_filter +{ + u32 handle; + struct tcf_exts exts; + struct tcf_ematch_tree ematches; + struct tcf_result res; + struct list_head link; +}; + +static struct tcf_ext_map basic_ext_map = { + .action = TCA_BASIC_ACT, + .police = TCA_BASIC_POLICE +}; + +static int basic_classify(struct sk_buff *skb, struct tcf_proto *tp, + struct tcf_result *res) +{ + int r; + struct basic_head *head = (struct basic_head *) tp->root; + struct basic_filter *f; + + list_for_each_entry(f, &head->flist, link) { + if (!tcf_em_tree_match(skb, &f->ematches)) + continue; + *res = f->res; + r = tcf_exts_exec(skb, &f->exts, res); + if (r < 0) + continue; + return r; + } + return -1; +} + +static unsigned long basic_get(struct tcf_proto *tp, u32 handle) +{ + unsigned long l = 0UL; + struct basic_head *head = (struct basic_head *) tp->root; + struct basic_filter *f; + + list_for_each_entry(f, &head->flist, link) + if (f->handle == handle) + l = (unsigned long) f; + + return l; +} + +static void basic_put(struct tcf_proto *tp, unsigned long f) +{ +} + +static int basic_init(struct tcf_proto *tp) +{ + return 0; +} + +static inline void +basic_delete_filter(struct tcf_proto *tp, struct basic_filter *f) +{ + tcf_unbind_filter(tp, &f->res); + tcf_exts_destroy(tp, &f->exts); + tcf_em_tree_destroy(tp, &f->ematches); + kfree(f); +} + +static void basic_destroy(struct tcf_proto *tp) +{ + struct basic_head *head = (struct basic_head *) xchg(&tp->root, NULL); + struct basic_filter *f, *n; + + list_for_each_entry_safe(f, n, &head->flist, link) { + list_del(&f->link); + basic_delete_filter(tp, f); + } +} + +static int basic_delete(struct tcf_proto *tp, unsigned long arg) +{ + struct basic_head *head = (struct basic_head *) tp->root; + struct basic_filter *t, *f = (struct basic_filter *) arg; + + list_for_each_entry(t, &head->flist, link) + if (t == f) { + tcf_tree_lock(tp); + list_del(&t->link); + tcf_tree_unlock(tp); + basic_delete_filter(tp, t); + return 0; + } + + return -ENOENT; +} + +static inline int basic_set_parms(struct tcf_proto *tp, struct basic_filter *f, + unsigned long base, struct rtattr **tb, + struct rtattr *est) +{ + int err; + struct tcf_exts e; + struct tcf_ematch_tree t; + + err = tcf_exts_validate(tp, tb, est, &e, &basic_ext_map); + if (err < 0) + return err; + + err = tcf_em_tree_validate(tp, tb[TCA_BASIC_EMATCHES-1], &t); + if (err < 0) + goto errout; + + if (tb[TCA_BASIC_CLASSID-1]) { + err = -EINVAL; + if (RTA_PAYLOAD(tb[TCA_BASIC_CLASSID-1]) < sizeof(u32)) + goto errout; + + f->res.classid = *(u32*)RTA_DATA(tb[TCA_BASIC_CLASSID-1]); + tcf_bind_filter(tp, &f->res, base); + } + + tcf_exts_change(tp, &f->exts, &e); + tcf_em_tree_change(tp, &f->ematches, &t); + + return 0; +errout: + tcf_exts_destroy(tp, &e); + return err; +} + +static int basic_change(struct tcf_proto *tp, unsigned long base, u32 handle, + struct rtattr **tca, unsigned long *arg) +{ + int err = -EINVAL; + struct basic_head *head = (struct basic_head *) tp->root; + struct rtattr *tb[TCA_BASIC_MAX]; + struct basic_filter *f = (struct basic_filter *) *arg; + + if (!tca[TCA_OPTIONS-1]) + return -EINVAL; + + if (rtattr_parse_nested(tb, TCA_BASIC_MAX, tca[TCA_OPTIONS-1]) < 0) + return -EINVAL; + + if (f != NULL) { + if (handle && f->handle != handle) + return -EINVAL; + return basic_set_parms(tp, f, base, tb, tca[TCA_RATE-1]); + } + + err = -ENOBUFS; + if (!head) { + head = kmalloc(sizeof(*head), GFP_KERNEL); + if (!head) + goto errout; + + memset(head, 0, sizeof(*head)); + INIT_LIST_HEAD(&head->flist); + tp->root = head; + } + + f = kmalloc(sizeof(*f), GFP_KERNEL); + if (!f) + goto errout; + memset(f, 0, sizeof(*f)); + + err = -EINVAL; + if (handle) + f->handle = handle; + else { + int i = 0x80000000; + do { + if (++head->hgenerator == 0x7FFFFFFF) + head->hgenerator = 1; + } while (--i > 0 && basic_get(tp, head->hgenerator)); + + if (i <= 0) { + printk(KERN_ERR "Insufficient number of handles\n"); + goto errout; + } + + f->handle = head->hgenerator; + } + + err = basic_set_parms(tp, f, base, tb, tca[TCA_RATE-1]); + if (err < 0) + goto errout; + + tcf_tree_lock(tp); + list_add(&f->link, &head->flist); + tcf_tree_unlock(tp); + *arg = (unsigned long) f; + + return 0; +errout: + if (*arg == 0UL && f) + kfree(f); + + return err; +} + +static void basic_walk(struct tcf_proto *tp, struct tcf_walker *arg) +{ + struct basic_head *head = (struct basic_head *) tp->root; + struct basic_filter *f; + + list_for_each_entry(f, &head->flist, link) { + if (arg->count < arg->skip) + goto skip; + + if (arg->fn(tp, (unsigned long) f, arg) < 0) { + arg->stop = 1; + break; + } +skip: + arg->count++; + } +} + +static int basic_dump(struct tcf_proto *tp, unsigned long fh, + struct sk_buff *skb, struct tcmsg *t) +{ + struct basic_filter *f = (struct basic_filter *) fh; + unsigned char *b = skb->tail; + struct rtattr *rta; + + if (!f) + return skb->len; + + t->tcm_handle = f->handle; + + rta = (struct rtattr *) b; + RTA_PUT(skb, TCA_OPTIONS, 0, NULL); + + if (tcf_exts_dump(skb, &f->exts, &basic_ext_map) < 0 || + tcf_em_tree_dump(skb, &f->ematches, TCA_BASIC_EMATCHES) < 0) + goto rtattr_failure; + + rta->rta_len = (skb->tail - b); + return skb->len; + +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static struct tcf_proto_ops cls_basic_ops = { + .kind = "basic", + .classify = basic_classify, + .init = basic_init, + .destroy = basic_destroy, + .get = basic_get, + .put = basic_put, + .change = basic_change, + .delete = basic_delete, + .walk = basic_walk, + .dump = basic_dump, + .owner = THIS_MODULE, +}; + +static int __init init_basic(void) +{ + return register_tcf_proto_ops(&cls_basic_ops); +} + +static void __exit exit_basic(void) +{ + unregister_tcf_proto_ops(&cls_basic_ops); +} + +module_init(init_basic) +module_exit(exit_basic) +MODULE_LICENSE("GPL"); + --4Ckj6UjgE2iN1+kY-- From okir@suse.de Mon Jan 3 06:25:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 06:25:11 -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 j03EOecH030329 for ; Mon, 3 Jan 2005 06:25:03 -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 0616412C516C for ; Mon, 3 Jan 2005 15:33:07 +0100 (CET) Date: Mon, 3 Jan 2005 15:33:06 +0100 From: Olaf Kirch To: netdev@oss.sgi.com Subject: [PATCH] Check for SOL_SOCKET in compat_sys_getsockopt Message-ID: <20050103143306.GG25446@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline compat_sys_getsockopt checks for SO_RCVTIMEO/SO_SNDTIMEO without making sure that the level is actually SOL_SOCKET. This can break getsockopt() requests for other protocols. Cheers, and a happy new year to everyone! Olaf -- Olaf Kirch | Things that make Monday morning interesting, #2: okir@suse.de | "We have 8,000 NFS mount points, why do we keep ---------------+ running out of privileged ports?" --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=setsockopt-compat Subject: check for SOL_SOCKET in compat_sys_getsocket compat_sys_getsockopt checks for SO_RCVTIMEO/SO_SNDTIMEO without making sure that the level is actually SOL_SOCKET. This can break getsockopt() requests for other protocols. Signed-off-by: Olaf Kirch Index: linux-2.6.9/net/compat.c =================================================================== --- linux-2.6.9.orig/net/compat.c 2005-01-03 15:25:11.000000000 +0100 +++ linux-2.6.9/net/compat.c 2005-01-03 15:25:29.000000000 +0100 @@ -507,7 +507,8 @@ static int do_get_sock_timeout(int fd, i asmlinkage long compat_sys_getsockopt(int fd, int level, int optname, char __user *optval, int __user *optlen) { - if (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO) + if (level == SOL_SOCKET && + (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO)) return do_get_sock_timeout(fd, level, optname, optval, optlen); return sys_getsockopt(fd, level, optname, optval, optlen); } --IiVenqGWf+H9Y6IX-- From hadi@cyberus.ca Mon Jan 3 06:28:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 06:28:53 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03ESP1U030896 for ; Mon, 3 Jan 2005 06:28:45 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1ClTKL-00030n-8H for netdev@oss.sgi.com; Mon, 03 Jan 2005 09:36:57 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1ClTKJ-0003Wa-HA; Mon, 03 Jan 2005 09:36:55 -0500 Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050102000612.GU32419@postel.suug.ch> References: <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101121041.GR32419@postel.suug.ch> <1104622164.1048.444.camel@jzny.localdomain> <20050102000612.GU32419@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104763012.1047.524.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 09:36:52 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13343 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 Sat, 2005-01-01 at 19:06, Thomas Graf wrote: > * jamal <1104622164.1048.444.camel@jzny.localdomain> 2005-01-01 18:29 > > Does the ematch API include a dump()? I dont think it should - thats the > > point i was making. Should be simple. > > Yes, although simple ematches are not required to implement dump. ok. I realize its optional - but i wouldnt even give the writter of ematch the opportunity to write one. Want something more complex? write a classifier. > > > [validate] > > Even this is too much for a simple ematch. Validation should happen in > > user space or maybe at the mother clasifier. maybe a maxsize,minsize > > attribute is needed in the ematch struct. > > > [replace] > > Equivalent of this should be done by the mother classifier. > > All it needs to know is the length (and no other details). And the > > length is known from the L in TLV. > > I merged validate/replace into change which takes a unsigned long > for storage and a data/len parameter. It's up to the ematch what he > does with it, data may contain a u32 directly and the ematch might > save it in the unsigned long or a ematch may allocate a structure. Again allowing for this may be overkill. Just send the same structure the ematch needs in exactly the same form it needs it and you dont need this. > Why are you focused on hiding so much? I'd rather try to make it > simple but still allow more complex ematches to exist. > > Have a look at http://people.suug.ch/~tgr/tmp/ematch.diff Thanks, give me a few hours then i will look. > I broke the API down to: > > change > match > destroy (optional, only for complex ematches) > dump (optional, only for complex ematches) > Other than match, anything really should be optional for simplicity sake. > > Note that the ematch is supposed to be a very very simple thing... > > Something a fireman who has implemented a iptables target can whip in an > > hour. Keep in mind that design goal. Non trivial coding needed or poor > > usability is the major problem with tc in general. Avoid that theme. > > An ematch _needs_ a mother classifier such as u32. u32 has a very nice > > and very flexible layout - it can be trained to build any sort of tree. > > Maybe the first step should be to not even have u32 as an ematch .. > > I understand your point but I want to at least be able to implement > some more complex stuff. Hiding too much can be bad too. Having only 2 > functions to implement is really easy, the rest can be done the LinuxWay(tm) ;-> > True - but the goals of this ematch is to be simple ;-> > Have a look at the code and tell me what you think. > > Here's an example ematch, I find this quite simple already. > > static in foo_change(struct tcf_proto *tp, void *data, int len, struct > tcf_ematch *m) > { > if (len != sizeof(u32)) > return -EINVAL; > m->data = *(u32*)data; > return 0; > } > I still say not needed ;-> > static int foo_match(struct sk_buff *skb, struct tcf_ematch *m) > { > return skb->security == m->data; > } makes sense. > static struct tcf_ematch_ops foo_ops = { > .kind = 111, > .change = foo_change, > .match = foo_match, > .owner = THIS_MODULE, > .link = LIST_HEAD_INIT(foo_ops.link) > } whats the .link for? > static int __init foo_init(void) > { > return tcf_ematch_register(&foo_ops); > } > > static void __exit foo_exit(void) > { > return tcf_ematch_unregister(&foo_ops); > } > > module_init(init_foo); > module_exit(exit_foo); All looks good. Give me a few hours, first day of working week will slow me down. cheers, jamal From hadi@cyberus.ca Mon Jan 3 06:38:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 06:38:19 -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 j03EbqCH031733 for ; Mon, 3 Jan 2005 06:38:12 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1ClTTU-0006Ip-47 for netdev@oss.sgi.com; Mon, 03 Jan 2005 09:46:24 -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 1ClTTR-00058B-0M; Mon, 03 Jan 2005 09:46:21 -0500 Subject: Re: patch: tunnels not setting inputdev From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com, Wichert Akkerman In-Reply-To: <41D73F28.3090206@trash.net> References: <1104513392.1048.316.camel@jzny.localdomain> <41D5941C.8060001@trash.net> <1104523892.1047.338.camel@jzny.localdomain> <41D6CB87.8040205@trash.net> <1104622406.1049.450.camel@jzny.localdomain> <41D73F28.3090206@trash.net> Content-Type: multipart/mixed; boundary="=-fHTulGJembddNxbTRWt5" Organization: jamalopolous Message-Id: <1104763578.1047.553.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 09:46:18 -0500 X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13344 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 --=-fHTulGJembddNxbTRWt5 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-01-01 at 19:24, Patrick McHardy wrote: > jamal wrote: > > I want to understand the repurcasssions instead of blindly setting. Let > > users complain, thats why the printk exists. For example what does > > input_dev mean for netbios or a 802.3ad interface? You already saw one, > > xfrm, where there was no need to reset. > > What's special about netbios ? For 802.3ad, I would expect input_dev > to hold the virtual device through which the packet entered the stack, > just what iptables -i would match. For xfrm - there is no need but its > also not wrong. This is exactly why i am not just setting things arbitraliy at input. Different _types_ of devices that need different _types_ of treatment (with dependency of where they are in the path as well). Tunnels are not the same as ethernet are not the same as atm devices are not the same as ppp-based devices. Heck some of these things dont even use netdevices. Note, one could claim that if you remove the printk there is already a central place to set things. However, I need to know when people use this path what the circumstances are - at some point we will get rid of the printk. At some point it may be you are right, lets just put it all in one spot - but for now just leave it as is. > > in some cases the pointers are swapped. You cant just blindly > > set skb->input_dev = skb->dev at the input - that would be violating the > > intent; think reinjecting packets (and look at mirred as a sample of > > apps to come that do this). > > I don't know your intent, but I assumed it was to match the incoming > interface as the networking stack sees it. Why would the pointers be > swapped ? Please give me an example. mirred does: > > skb2->dev = dev; > skb2->input_dev = skb->dev; > > So on input input_dev is the incoming interface of the original packet, > on output it is the outgoing interface of the original packet. Doesn't > make much sense to me, the original packet came the same way both times. The current mirred does only egress redirection - it doesnt do ingress redirection, nor socket redirection yet. The TODO list in the file says it will at some point. I have some code - but its not clean enough to include - those for example will matter in this case. I dont want to rule it out to be specific just for those few apps i have. The architecture allows arbitrary loops between arbitrary number of actions and netdevices in a policy topology. The input could appear more than once in such a topology at arbitrary points. I am attaching an old version of the dummy device, which i am hoping to propose as a replacement for IMQ at some point; its has an example of such usage. I havent really added any hooks for contracking action in the path in which dummy is to be found etc, but I hope it helps make my point. At some point i will document all the features. An example policy: on eth0: match filter at ingress/egress then action mirred egress redirect dev dummy0. dummy0 reinjects at ingress/egress. More complex: on dummy0 add more interesting rules to do further redirection. cheers, jamal --=-fHTulGJembddNxbTRWt5 Content-Disposition: attachment; filename=dummy.c Content-Type: text/x-c; name=dummy.c; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit /* dummy.c: a dummy net driver The purpose of this driver is to provide a device to point a route through, but not to actually transmit packets. Why? If you have a machine whose only connection is an occasional PPP/SLIP/PLIP link, you can only connect to your own hostname when the link is up. Otherwise you have to use localhost. This isn't very consistent. One solution is to set up a dummy link using PPP/SLIP/PLIP, but this seems (to me) too much overhead for too little gain. This driver provides a small alternative. Thus you can do [when not running slip] ifconfig dummy slip.addr.ess.here up [to go to slip] ifconfig dummy down dip whatever This was written by looking at Donald Becker's skeleton driver and the loopback driver. I then threw away anything that didn't apply! Thanks to Alan Cox for the key clue on what to do with misguided packets. Nick Holloway, 27th May 1994 [I tweaked this explanation a little but that's all] Alan Cox, 30th May 1994 */ /* * This driver isnt abused enough ;-> * Here to add only a _feeew more_ features, * 10 years after AC added comment above ;-> hehe - JHS */ #include #include #include #include #include #include #include #ifdef CONFIG_NET_CLS_ACT #include #endif #define TX_TIMEOUT (2*HZ) #define TX_Q_LIMIT 32 struct dummy_private { struct net_device_stats stats; #ifdef CONFIG_NET_CLS_ACT struct tasklet_struct dummy_tasklet; int tasklet_pending; /* mostly debug stats leave in for now */ unsigned long stat_r1; unsigned long stat_r2; unsigned long stat_r3; unsigned long stat_r4; unsigned long stat_r5; unsigned long stat_r6; unsigned long stat_r7; unsigned long stat_r8; struct sk_buff_head rq; struct sk_buff_head tq; #endif }; #ifdef CONFIG_NET_CLS_ACT static void ri_tasklet(unsigned long dev); #endif static int numdummies = 1; static int dummy_xmit(struct sk_buff *skb, struct net_device *dev); static struct net_device_stats *dummy_get_stats(struct net_device *dev); static void dummy_timeout(struct net_device *dev); static int dummy_open(struct net_device *dev); static int dummy_close(struct net_device *dev); static void dummy_timeout(struct net_device *dev) { int cpu = smp_processor_id(); dev->trans_start = jiffies; printk("%s: BUG tx timeout on CPU %d\n",dev->name,cpu); if (spin_is_locked((&dev->xmit_lock))) printk("xmit lock grabbed already\n"); if (spin_is_locked((&dev->queue_lock))) printk("queue lock grabbed already\n"); } #ifdef CONFIG_NET_CLS_ACT static void ri_tasklet(unsigned long dev) { struct net_device *dv = (struct net_device *)dev; struct dummy_private *dp = ((struct net_device *)dev)->priv; struct net_device_stats *stats = &dp->stats; struct sk_buff *skb = NULL; dp->stat_r4 +=1; if (NULL == (skb = skb_peek(&dp->tq))) { dp->stat_r5 +=1; if (spin_trylock(&dv->xmit_lock)) { dp->stat_r8 +=1; while (NULL != (skb = skb_dequeue(&dp->rq))) { skb_queue_tail(&dp->tq, skb); } spin_unlock(&dv->xmit_lock); } else { /* reschedule */ dp->stat_r1 +=1; goto resched; } } while (NULL != (skb = skb_dequeue(&dp->tq))) { __u32 from = G_TC_FROM(skb->tc_verd); skb->tc_verd = 0; skb->tc_verd = SET_TC_NCLS(skb->tc_verd); stats->tx_packets++; stats->tx_bytes+=skb->len; if (from & AT_EGRESS) { dp->stat_r6 +=1; dev_queue_xmit(skb); } else if (from & AT_INGRESS) { dp->stat_r7 +=1; netif_rx(skb); } else { /* if netfilt is compiled in and packet is tagged, we could reinject the packet back this would make it do what current IMQ does + more; if someone really really insists then this is the spot .. jhs */ dev_kfree_skb(skb); stats->tx_dropped++; } } if (spin_trylock(&dv->xmit_lock)) { dp->stat_r3 +=1; if (NULL == (skb = skb_peek(&dp->rq))) { dp->tasklet_pending = 0; if (netif_queue_stopped(dv)) netif_start_queue(dv); } else { dp->stat_r2 +=1; spin_unlock(&dv->xmit_lock); goto resched; } spin_unlock(&dv->xmit_lock); } else { resched: dp->tasklet_pending = 1; tasklet_schedule(&dp->dummy_tasklet); } } #endif static int dummy_set_address(struct net_device *dev, void *p) { struct sockaddr *sa = p; if (!is_valid_ether_addr(sa->sa_data)) return -EADDRNOTAVAIL; memcpy(dev->dev_addr, sa->sa_data, ETH_ALEN); return 0; } /* fake multicast ability */ static void set_multicast_list(struct net_device *dev) { } #ifdef CONFIG_NET_FASTROUTE static int dummy_accept_fastpath(struct net_device *dev, struct dst_entry *dst) { return -1; } #endif static void __init dummy_setup(struct net_device *dev) { /* Initialize the device structure. */ dev->get_stats = dummy_get_stats; dev->hard_start_xmit = dummy_xmit; dev->tx_timeout = &dummy_timeout; dev->watchdog_timeo = TX_TIMEOUT; dev->open = &dummy_open; dev->stop = &dummy_close; dev->set_multicast_list = set_multicast_list; dev->set_mac_address = dummy_set_address; #ifdef CONFIG_NET_FASTROUTE dev->accept_fastpath = dummy_accept_fastpath; #endif /* Fill in device structure with ethernet-generic values. */ ether_setup(dev); dev->tx_queue_len = TX_Q_LIMIT; dev->flags |= IFF_NOARP; dev->flags &= ~IFF_MULTICAST; SET_MODULE_OWNER(dev); random_ether_addr(dev->dev_addr); } static int dummy_xmit(struct sk_buff *skb, struct net_device *dev) { struct dummy_private *dp = ((struct net_device *)dev)->priv; struct net_device_stats *stats = &dp->stats; #ifdef CONFIG_NET_CLS_ACT __u32 from = G_TC_FROM(skb->tc_verd); #endif int ret = 0; stats->rx_packets++; stats->rx_bytes+=skb->len; #ifdef CONFIG_NET_CLS_ACT if ( !from || !skb->input_dev ) { dropped: dev_kfree_skb(skb); stats->rx_dropped++; return ret; } else { if (skb->input_dev) skb->dev = skb->input_dev; else printk("warning!!! no idev %s\n",skb->dev->name); skb->input_dev = dev; if (from & AT_INGRESS) { skb_pull(skb, skb->dev->hard_header_len); } else { if (!(from & AT_EGRESS)) { goto dropped; } } } if (skb_queue_len(&dp->rq) >= dev->tx_queue_len) { netif_stop_queue(dev); } dev->trans_start = jiffies; skb_queue_tail(&dp->rq, skb); if (!dp->tasklet_pending) { dp->tasklet_pending = 1; tasklet_schedule(&dp->dummy_tasklet); } #else dev_kfree_skb(skb); #endif return ret; } static struct net_device_stats *dummy_get_stats(struct net_device *dev) { struct dummy_private *dp = ((struct net_device *)dev)->priv; struct net_device_stats *stats = &dp->stats; #ifdef CONFIG_NET_CLS_ACT_DEB printk("tasklets stats %ld:%ld:%ld:%ld:%ld:%ld:%ld:%ld \n", dp->stat_r1,dp->stat_r2,dp->stat_r3,dp->stat_r4, dp->stat_r5,dp->stat_r6,dp->stat_r7,dp->stat_r8); #endif return stats; } static struct net_device **dummies; /* Number of dummy devices to be set up by this module. */ module_param(numdummies, int, 0); MODULE_PARM_DESC(numdummies, "Number of dummy pseudo devices"); static int dummy_close(struct net_device *dev) { #ifdef CONFIG_NET_CLS_ACT struct dummy_private *dp = ((struct net_device *)dev)->priv; tasklet_kill(&dp->dummy_tasklet); skb_queue_purge(&dp->rq); skb_queue_purge(&dp->tq); #endif netif_stop_queue(dev); return 0; } static int dummy_open(struct net_device *dev) { #ifdef CONFIG_NET_CLS_ACT struct dummy_private *dp = ((struct net_device *)dev)->priv; tasklet_init(&dp->dummy_tasklet, ri_tasklet, (unsigned long)dev); skb_queue_head_init(&dp->rq); skb_queue_head_init(&dp->tq); #endif netif_start_queue(dev); return 0; } static int __init dummy_init_one(int index) { struct net_device *dev_dummy; int err; dev_dummy = alloc_netdev(sizeof(struct dummy_private), "dummy%d", dummy_setup); if (!dev_dummy) return -ENOMEM; if ((err = register_netdev(dev_dummy))) { free_netdev(dev_dummy); dev_dummy = NULL; } else { dummies[index] = dev_dummy; } return err; } static void dummy_free_one(int index) { unregister_netdev(dummies[index]); free_netdev(dummies[index]); } static int __init dummy_init_module(void) { int i, err = 0; dummies = kmalloc(numdummies * sizeof(void *), GFP_KERNEL); if (!dummies) return -ENOMEM; for (i = 0; i < numdummies && !err; i++) err = dummy_init_one(i); if (err) { while (--i >= 0) dummy_free_one(i); } return err; } static void __exit dummy_cleanup_module(void) { int i; for (i = 0; i < numdummies; i++) dummy_free_one(i); kfree(dummies); } module_init(dummy_init_module); module_exit(dummy_cleanup_module); MODULE_LICENSE("GPL"); --=-fHTulGJembddNxbTRWt5-- From hadi@cyberus.ca Mon Jan 3 06:42:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 06:42:39 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03EgBIq032344 for ; Mon, 3 Jan 2005 06:42:32 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1ClTXf-0005hg-BY for netdev@oss.sgi.com; Mon, 03 Jan 2005 09:50:43 -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 1ClTXe-0005vF-Hc; Mon, 03 Jan 2005 09:50:42 -0500 Subject: Re: unregister_netdev Annoyance WAS(Re: ing_filter debug messages From: jamal Reply-To: hadi@cyberus.ca To: bert hubert Cc: Wichert Akkerman , netdev@oss.sgi.com In-Reply-To: <20050102121349.GA27022@outpost.ds9a.nl> References: <20041230160643.GD24603@wiggy.net> <1104469666.1049.231.camel@jzny.localdomain> <20041231093827.GG24603@wiggy.net> <1104491510.1047.234.camel@jzny.localdomain> <20041231131553.GA7460@wiggy.net> <1104505838.1048.273.camel@jzny.localdomain> <20041231154844.GA11511@wiggy.net> <1104511697.1048.308.camel@jzny.localdomain> <20050102121349.GA27022@outpost.ds9a.nl> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104763839.1047.563.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 09:50:40 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13345 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 Sun, 2005-01-02 at 07:13, bert hubert wrote: > This is a separate and known problem - see 'Re: Major deadlock: > unregister_netdevice: waiting for to become free. Usage count = 1' > by Peter Bieringer. > > For some reason this issue has been widely ignored. I see it as well here > and it is the one reason I don't entirely trust 2.6.10 yet in production. > > Thanks for looking into it Jamal! This issue was already being looked into by about 3 people {Dave, Yoshfuji-san, Herbert}. They have more knowledge about the circumstances than i do. The holidays are over, so give it a short time and lets see what happens. cheers, jamal From tgraf@suug.ch Mon Jan 3 06:53:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 06:54:04 -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 j03EracX000823 for ; Mon, 3 Jan 2005 06:53:57 -0800 Received: from postel.suug.ch (unknown [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 492B184; Mon, 3 Jan 2005 16:01:48 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 04AD41C0EA; Mon, 3 Jan 2005 16:02:30 +0100 (CET) Date: Mon, 3 Jan 2005 16:02:30 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. Message-ID: <20050103150230.GC26856@postel.suug.ch> References: <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101121041.GR32419@postel.suug.ch> <1104622164.1048.444.camel@jzny.localdomain> <20050102000612.GU32419@postel.suug.ch> <1104763012.1047.524.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104763012.1047.524.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13346 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 * jamal <1104763012.1047.524.camel@jzny.localdomain> 2005-01-03 09:36 > On Sat, 2005-01-01 at 19:06, Thomas Graf wrote: > > * jamal <1104622164.1048.444.camel@jzny.localdomain> 2005-01-01 18:29 > > > Does the ematch API include a dump()? I dont think it should - thats the > > > point i was making. Should be simple. > > > > Yes, although simple ematches are not required to implement dump. > > ok. I realize its optional - but i wouldnt even give the writter of > ematch the opportunity to write one. Want something more complex? write > a classifier. A classifier is at least 300 lines and you lose the ability to use the logic relations. > Again allowing for this may be overkill. Just send the same structure > the ematch needs in exactly the same form it needs it and you dont need > this. Compromise: If change/dump is not provided the api allocates and memcpy's itself resptively dumps m->data. Simple ematches don't have to care and can simple access m->data, more complex ematches can implement their own change/dump. Does that sound beter? > whats the .link for? I use list.h to chain ematch_ops and it's better to have it initialized. From hadi@cyberus.ca Mon Jan 3 06:56:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 06:56:23 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03EtvR2001312 for ; Mon, 3 Jan 2005 06:56:17 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1ClTkw-0000oV-B3 for netdev@oss.sgi.com; Mon, 03 Jan 2005 10:04:26 -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 1ClTku-0007Aw-3i; Mon, 03 Jan 2005 10:04:24 -0500 Subject: Re: LLTX and netif_stop_queue From: jamal Reply-To: hadi@cyberus.ca To: Eric Lemoine , Andi Kleen Cc: Patrick McHardy , "David S. Miller" , roland@topspin.com, netdev@oss.sgi.com, openib-general@openib.org In-Reply-To: <5cac192f0501021530672a908a@mail.gmail.com> References: <52llbwoaej.fsf@topspin.com> <20041217214432.07b7b21e.davem@davemloft.net> <1103484675.1050.158.camel@jzny.localdomain> <5cac192f04122210491d64d4b6@mail.gmail.com> <20041222202919.057b8331.davem@davemloft.net> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104764660.1048.578.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 10:04:21 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13347 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 this piece: ----- + + /* And release queue */ + spin_unlock(&dev->queue_lock); } --------- Isnt there a possibility (higher as you increase number of processors) that you will spin for a long time in _the driver_ waiting for the queue lock? Maybe we need a flag "the queue lock" is already been grabbed passed to the driver. LLTX is a good alias but insufficient (if you run your driver in an old kernels which support LLTX but not the idea of locking the queue for you). Andi or anyone else - has anyone really done perfomance analysis of LLTX (with anything other than loopback) and shown it has any value? Maybe time to just shoot the damn thing. cheers, jamal On Sun, 2005-01-02 at 18:30, Eric Lemoine wrote: > On 28 Dec 2004 08:31:57 -0500, jamal wrote: > > On Fri, 2004-12-24 at 11:10, Eric Lemoine wrote: > > > > > Yes but requiring drivers to release a lock that they should not even > > > be aware of doesn't sound good. Another way would be to keep > > > dev->queue_lock grabbed when entering start_xmit() and let the driver > > > drop it (and re-acquire it before it returns) only if it wishes so. > > > Although I don't like this too much either, that's the best way I can > > > think of up to now... > > > > I am not a big fan of that patch either, but i cant think of a cleaner > > way to do it. > > The violation already happens with the LLTX flag. So maybe a big warning > > that says "Do this only if you driver is LLTX enabled". The other way to > > do it is put a check to see if LLTX is enabled before releasing that > > lock - but why the extra cycles? Driver writer should know. > > Two (untested) patches implementing what I described above. > > The first pach (sch_generic.patch) keeps queue_lock held in > qdisc_restart() when calling hard_start_xmit() of a LLTX driver. The > second (sungem.patch) makes sungem release queue_lock after grabbing > its private tx lock. > > Note that the modifications made to qdisc_restart() are not compatible > with the current LLTX drivers. All LLTX drivers must be modified along > sungem.patch's lines. Take sungem.patch as an example of how things > must be done. > > Patches apply to current davem bk snapshot. From eric.lemoine@gmail.com Mon Jan 3 07:39:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 07:39:58 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03FdU9e003208 for ; Mon, 3 Jan 2005 07:39:50 -0800 Received: by wproxy.gmail.com with SMTP id 71so1331127wra for ; Mon, 03 Jan 2005 07:48:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=bqlWbHnOofEuCNnArW5xjKx8U5HVmqRlvva6gi2Qn6HCXr9CpEDiyA6UYpotEvWgw1TXf58STO33hUvt5mRjRYgRXYYmJSO+Nr2rrR9Kbhq03MAFpllsJyY/HFD6tcSz6tWhDFqmIVJxXSGoeRV0mtcivQuo5hIKuSxj+TMnVoI= Received: by 10.54.51.35 with SMTP id y35mr143948wry; Mon, 03 Jan 2005 07:48:00 -0800 (PST) Received: by 10.54.30.8 with HTTP; Mon, 3 Jan 2005 07:48:00 -0800 (PST) Message-ID: <5cac192f05010307484f23bca5@mail.gmail.com> Date: Mon, 3 Jan 2005 16:48:00 +0100 From: Eric Lemoine Reply-To: Eric Lemoine To: hadi@cyberus.ca Subject: Re: LLTX and netif_stop_queue Cc: Andi Kleen , Patrick McHardy , "David S. Miller" , roland@topspin.com, netdev@oss.sgi.com, openib-general@openib.org In-Reply-To: <1104764660.1048.578.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <52llbwoaej.fsf@topspin.com> <1103484675.1050.158.camel@jzny.localdomain> <5cac192f04122210491d64d4b6@mail.gmail.com> <20041222202919.057b8331.davem@davemloft.net> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> <1104764660.1048.578.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev On 03 Jan 2005 10:04:21 -0500, jamal wrote: > this piece: > ----- > + > + /* And release queue */ > + spin_unlock(&dev->queue_lock); > } > --------- > > Isnt there a possibility (higher as you increase number of processors) > that you will spin for a long time in _the driver_ waiting for the queue > lock? I don't see how LLTX is different from non-LLTX wrt the time spent spinning on queue_lock. What am i missing? > > Maybe we need a flag "the queue lock" is already been grabbed passed > to the driver. LLTX is a good alias but insufficient (if you run your > driver in an old kernels which support LLTX but not the idea of locking > the queue for you). > > Andi or anyone else - has anyone really done perfomance analysis of LLTX > (with anything other than loopback) and shown it has any value? Maybe > time to just shoot the damn thing. I do not like LLTX too much either as I can't see a cleaner way to get rid of that packet reordering race condition. -- Eric From hadi@cyberus.ca Mon Jan 3 07:47:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 07:47:27 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03Fl0kO003949 for ; Mon, 3 Jan 2005 07:47:20 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1ClUYN-0001A3-VE for netdev@oss.sgi.com; Mon, 03 Jan 2005 10:55:31 -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 1ClUYL-0005Cr-5F; Mon, 03 Jan 2005 10:55:29 -0500 Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050103150230.GC26856@postel.suug.ch> References: <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101121041.GR32419@postel.suug.ch> <1104622164.1048.444.camel@jzny.localdomain> <20050102000612.GU32419@postel.suug.ch> <1104763012.1047.524.camel@jzny.localdomain> <20050103150230.GC26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104767726.1049.591.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 10:55:26 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13349 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-03 at 10:02, Thomas Graf wrote: > > ok. I realize its optional - but i wouldnt even give the writter of > > ematch the opportunity to write one. Want something more complex? write > > a classifier. > > A classifier is at least 300 lines and you lose the ability to use the > logic relations. Sure, but simpler-than-classifier is where we started ;-> I think in time we should revamp this a little more, but classifiers we have today already we just cant get rid of them now. Over time, I agree we should revamp. > > Again allowing for this may be overkill. Just send the same structure > > the ematch needs in exactly the same form it needs it and you dont need > > this. > > Compromise: If change/dump is not provided the api allocates and > memcpy's itself resptively dumps m->data. Simple ematches don't have to > care and can simple access m->data, more complex ematches can implement > their own change/dump. Does that sound beter? Yes, indeed. A copy instead of reference is owned by the classifier. To me its a valid compromise. Dont want those matches to be shared in any case. Also dont want user to know shit about TLVs. Neither in the kernel, nor in user space. Simplicty. Sorry, havent looked at the code yet. Is the patch you posted the same as you have on the url earlier? > > whats the .link for? > > I use list.h to chain ematch_ops and it's better to have it initialized. I relaized that - but should the user know anything about this? cheers, jamal From roland@topspin.com Mon Jan 3 07:49:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 07:49:10 -0800 (PST) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03FmeiW004264 for ; Mon, 3 Jan 2005 07:49:01 -0800 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Jan 2005 07:57:15 -0800 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Jan 2005 07:57:14 -0800 Received: from roland by eddore with local (Exim 4.34) id 1ClUa2-0002Wp-8F; Mon, 03 Jan 2005 07:57:14 -0800 To: hadi@cyberus.ca Cc: Eric Lemoine , Andi Kleen , Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com, openib-general@openib.org X-Message-Flag: Warning: May contain useful information References: <52llbwoaej.fsf@topspin.com> <20041217214432.07b7b21e.davem@davemloft.net> <1103484675.1050.158.camel@jzny.localdomain> <5cac192f04122210491d64d4b6@mail.gmail.com> <20041222202919.057b8331.davem@davemloft.net> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> <1104764660.1048.578.camel@jzny.localdomain> From: Roland Dreier Date: Mon, 03 Jan 2005 07:57:14 -0800 In-Reply-To: <1104764660.1048.578.camel@jzny.localdomain> (jamal's message of "03 Jan 2005 10:04:21 -0500") Message-ID: <52brc68q05.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: LLTX and netif_stop_queue Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 03 Jan 2005 15:57:14.0803 (UTC) FILETIME=[E4C57030:01C4F1AC] X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev jamal> Andi or anyone else - has anyone really done perfomance jamal> analysis of LLTX (with anything other than loopback) and jamal> shown it has any value? Maybe time to just shoot the damn jamal> thing. For the IPoIB driver, it seems to be worth a couple percent. It's hard to get really consistent results but on my pair of test systems, TCP throughput with netperf goes up by about 30 Mbps out of roughly 1900 Mbps total. It's probably not worth the complexity in the net core if all drivers only get that level of improvement. - Roland From tgraf@suug.ch Mon Jan 3 08:18:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 08:18:08 -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 j03GHeiC005631 for ; Mon, 3 Jan 2005 08:18:01 -0800 Received: from postel.suug.ch (unknown [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 CBAEC84; Mon, 3 Jan 2005 17:25:52 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 890DE1C0EA; Mon, 3 Jan 2005 17:26:35 +0100 (CET) Date: Mon, 3 Jan 2005 17:26:35 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. Message-ID: <20050103162635.GD26856@postel.suug.ch> References: <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101121041.GR32419@postel.suug.ch> <1104622164.1048.444.camel@jzny.localdomain> <20050102000612.GU32419@postel.suug.ch> <1104763012.1047.524.camel@jzny.localdomain> <20050103150230.GC26856@postel.suug.ch> <1104767726.1049.591.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104767726.1049.591.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13351 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 * jamal <1104767726.1049.591.camel@jzny.localdomain> 2005-01-03 10:55 > Sorry, havent looked at the code yet. Is the patch you posted the same > as you have on the url earlier? Yes, with a few minor fixes and I made it depend on CONFIG_NET_CLS_EMATCH and added nil macros when it's not defined. Those macros need some more work though. TODO: - KConfig doc - make change optional - dump m->data if no dump implementation is provided The question I'm yet unsure is whether to strictly return 1/0 or allow classifier return codes. Given I'm done with the above, a minimal ematch will look like: static int sec_match(struct sk_buff *skb, struct tcf_ematch *m) { return *(u32 *) m->data == skb->security; } static struct tcf_ematch_ops sec_ops = { .kind = 11, .match = sec_match, .owner = THIS_MODULE } ... init/exit calling tcf_em_(un_register ... What do you think about checking RTA_PAYLOAD of the ematch data for < sizeof(unsigned long) and assign it to m->data without allocation? Would save us nonse allocations. The yet unused 8bit in tcf_ematch_hdr would hold a flag to indicate that m->data contains the data directly. > I relaized that - but should the user know anything about this? Actually no but initializing it in tcf_em_register wouldn't serve any purpose so we can either remove it or leave it there. From eric.lemoine@gmail.com Mon Jan 3 08:32:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 08:33:04 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03GWaEq009789 for ; Mon, 3 Jan 2005 08:32:57 -0800 Received: by wproxy.gmail.com with SMTP id 71so1338921wra for ; Mon, 03 Jan 2005 08:41:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BCkYFIPGcx9omY9dyEloq48dp5pOhDfDGlryvzB6X0yHCRdn3PEJkjh/P/dVtyDY+x1kDo2tLJimtRVIa32rKNZp/3n1HoqO39AU1wh/bzcfflHxLiAyXI/hxU4xNruAY+Fer/XUW4yzp2cgGNv6n+4bcdY7CdD8ESy8UX7Cqhg= Received: by 10.54.23.71 with SMTP id 71mr22509wrw; Mon, 03 Jan 2005 08:41:06 -0800 (PST) Received: by 10.54.30.8 with HTTP; Mon, 3 Jan 2005 08:41:05 -0800 (PST) Message-ID: <5cac192f05010308414a25b548@mail.gmail.com> Date: Mon, 3 Jan 2005 17:41:05 +0100 From: Eric Lemoine Reply-To: Eric Lemoine To: Roland Dreier Subject: Re: LLTX and netif_stop_queue Cc: hadi@cyberus.ca, Andi Kleen , Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com, openib-general@openib.org In-Reply-To: <52brc68q05.fsf@topspin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <52llbwoaej.fsf@topspin.com> <5cac192f04122210491d64d4b6@mail.gmail.com> <20041222202919.057b8331.davem@davemloft.net> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> <1104764660.1048.578.camel@jzny.localdomain> <52brc68q05.fsf@topspin.com> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev On Mon, 03 Jan 2005 07:57:14 -0800, Roland Dreier wrote: > jamal> Andi or anyone else - has anyone really done perfomance > jamal> analysis of LLTX (with anything other than loopback) and > jamal> shown it has any value? Maybe time to just shoot the damn > jamal> thing. > > For the IPoIB driver, it seems to be worth a couple percent. It's > hard to get really consistent results but on my pair of test systems, > TCP throughput with netperf goes up by about 30 Mbps out of roughly > 1900 Mbps total. It's probably not worth the complexity in the net > core if all drivers only get that level of improvement. > > - Roland > What are your machines? In particular, how many CPUs do they have? -- Eric From wensong@linux-vs.org Mon Jan 3 08:36:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 08:36:47 -0800 (PST) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03GaGVh010347 for ; Mon, 3 Jan 2005 08:36:38 -0800 Received: from penguin.linux-vs.org ([61.149.155.144]) by lb1.ctrip.com (8.12.10/8.12.10) with ESMTP id j03Gi0Mh005257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Jan 2005 00:44:07 +0800 Received: from penguin.linux-vs.org (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id j03GeT3Y003617; Tue, 4 Jan 2005 00:40:29 +0800 Received: from localhost (wensong@localhost) by penguin.linux-vs.org (8.12.8/8.12.8/Submit) with ESMTP id j03GeQGP003613; Tue, 4 Jan 2005 00:40:28 +0800 X-Authentication-Warning: penguin.linux-vs.org: wensong owned process doing -bs Date: Tue, 4 Jan 2005 00:40:25 +0800 (CST) From: Wensong Zhang To: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] [IPVS] run master/backup sync daemon at a time Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-1463811584-572891765-1097000265=:2451" Content-ID: X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wensong@linux-vs.org Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Hi Dave, Here is the back port patch from kernel 2.6, which is to run master/backup sync daemon at a time with SyncID support. Please check and apply it to kernel 2.4. Thanks, Wensong ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.4-ipvs-sync.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.4-ipvs-sync.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5 bGUgcGF0Y2guDQojDQojIENoYW5nZVNldA0KIyAgIDIwMDUvMDEvMDQgMDA6 MzA6NTgrMDg6MDAgYWNhc3NlbkBsaW51eC12cy5vcmcgDQojICAgW0lQVlNd IGNoYW5nZSB0byBydW4gbWFzdGVyL2JhY2t1cCBzeW5jIGRhZW1vbiBhdCBh IHRpbWUNCiMgICANCiMgICBTaWduZWQtb2ZmLWJ5OiBXZW5zb25nIFpoYW5n IDx3ZW5zb25nQGxpbnV4LXZzLm9yZz4NCiMgDQojIG5ldC9pcHY0L2lwdnMv aXBfdnNfc3luYy5jDQojICAgMjAwNS8wMS8wNCAwMDozMDo0NyswODowMCBh Y2Fzc2VuQGxpbnV4LXZzLm9yZyArOTYgLTM4DQojICAgY2hhbmdlZCB0byBy dW4gbWFzdGVyL2JhY2t1cCBzeW5jIGRhZW1vbiBhdCBhIHRpbWUuDQojIA0K IyBuZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jDQojICAgMjAwNS8wMS8wNCAw MDozMDo0NyswODowMCBhY2Fzc2VuQGxpbnV4LXZzLm9yZyArNyAtMw0KIyAg IGV4dGVuZHMgdGhlIGludGVyZmFjZSBvZiBJUFZTDQojIA0KIyBuZXQvaXB2 NC9pcHZzL2lwX3ZzX2NvcmUuYw0KIyAgIDIwMDUvMDEvMDQgMDA6MzA6NDcr MDg6MDAgYWNhc3NlbkBsaW51eC12cy5vcmcgKzEgLTENCiMgICBzeW5jIGEg Y29ubmVjdGlvbiB3aGVuIHRoZSBmbGFnIG9mIHN5bmMgc3RhdGUgaXMgbWFz dGVyLg0KIyANCiMgaW5jbHVkZS9uZXQvaXBfdnMuaA0KIyAgIDIwMDUvMDEv MDQgMDA6MzA6NDcrMDg6MDAgYWNhc3NlbkBsaW51eC12cy5vcmcgKzggLTUN CiMgICBleHRlbmQgdGhlIHN0cnVjdHMgZm9yIG1hc3Rlci9iYWNrdXAgZGFl bW9uIHJ1bm5pbmcgYXQgYSB0aW1lLg0KIyANCmRpZmYgLU5ydSBhL2luY2x1 ZGUvbmV0L2lwX3ZzLmggYi9pbmNsdWRlL25ldC9pcF92cy5oDQotLS0gYS9p bmNsdWRlL25ldC9pcF92cy5oCTIwMDUtMDEtMDQgMDA6MzM6MDYgKzA4OjAw DQorKysgYi9pbmNsdWRlL25ldC9pcF92cy5oCTIwMDUtMDEtMDQgMDA6MzM6 MDYgKzA4OjAwDQpAQCAtOTcsNiArOTcsNyBAQA0KIAlpbnQgICAgICAgICAg ICAgc3RhdGU7ICAgICAgICAgIC8qIHN5bmMgZGFlbW9uIHN0YXRlICovDQog CWNoYXIgICAgICAgICAgICBtY2FzdF9pZm5bSVBfVlNfSUZOQU1FX01BWExF Tl07DQogCQkJCQkvKiBtdWx0aWNhc3QgaW50ZXJmYWNlIG5hbWUgKi8NCisJ aW50CQlzeW5jaWQ7DQogDQogCS8qIHZpcnR1YWwgc2VydmljZSBvcHRpb25z ICovDQogCXVfaW50MTZfdAlwcm90b2NvbDsNCkBAIC0yMTMsOCArMjE0LDkg QEANCiANCiAvKiBUaGUgYXJndW1lbnQgdG8gSVBfVlNfU09fR0VUX0RBRU1P TiAqLw0KIHN0cnVjdCBpcF92c19kYWVtb25fdXNlciB7DQotCWludAlzdGF0 ZTsJCQkJLyogc3luYyBkYWVtb24gc3RhdGUgKi8NCi0JY2hhcgltY2FzdF9p Zm5bSVBfVlNfSUZOQU1FX01BWExFTl07CS8qIG11bHRpY2FzdCBpbnRlcmZh Y2UgbmFtZSAqLw0KKwlpbnQJc3RhdGU7CQkJCQkvKiBzeW5jIGRhZW1vbiBz dGF0ZSAqLw0KKwljaGFyCW1jYXN0X21hc3Rlcl9pZm5bSVBfVlNfSUZOQU1F X01BWExFTl07CS8qIG1jYXN0IG1hc3RlciBpbnRlcmZhY2UgbmFtZSAqLw0K KwljaGFyCW1jYXN0X2JhY2t1cF9pZm5bSVBfVlNfSUZOQU1FX01BWExFTl07 CS8qIG1jYXN0IGJhY2t1cCBpbnRlcmZhY2UgbmFtZSAqLw0KIH07DQogDQog DQpAQCAtNzI2LDkgKzcyOCwxMCBAQA0KICAqICAgICAgKGZyb20gaXBfdnNf c3luYy5jKQ0KICAqLw0KIGV4dGVybiB2b2xhdGlsZSBpbnQgaXBfdnNfc3lu Y19zdGF0ZTsNCi1leHRlcm4gY2hhciBpcF92c19tY2FzdF9pZm5bSVBfVlNf SUZOQU1FX01BWExFTl07DQotZXh0ZXJuIGludCBzdGFydF9zeW5jX3RocmVh ZChpbnQgc3RhdGUsIGNoYXIgKm1jYXN0X2lmbik7DQotZXh0ZXJuIGludCBz dG9wX3N5bmNfdGhyZWFkKHZvaWQpOw0KK2V4dGVybiBjaGFyIGlwX3ZzX21j YXN0X21hc3Rlcl9pZm5bSVBfVlNfSUZOQU1FX01BWExFTl07DQorZXh0ZXJu IGNoYXIgaXBfdnNfbWNhc3RfYmFja3VwX2lmbltJUF9WU19JRk5BTUVfTUFY TEVOXTsNCitleHRlcm4gaW50IHN0YXJ0X3N5bmNfdGhyZWFkKGludCBzdGF0 ZSwgY2hhciAqbWNhc3RfaWZuLCBfX3U4IHN5bmNpZCk7DQorZXh0ZXJuIGlu dCBzdG9wX3N5bmNfdGhyZWFkKGludCBzdGF0ZSk7DQogZXh0ZXJuIHZvaWQg aXBfdnNfc3luY19jb25uKHN0cnVjdCBpcF92c19jb25uICpjcCk7DQogDQog DQpkaWZmIC1OcnUgYS9uZXQvaXB2NC9pcHZzL2lwX3ZzX2NvcmUuYyBiL25l dC9pcHY0L2lwdnMvaXBfdnNfY29yZS5jDQotLS0gYS9uZXQvaXB2NC9pcHZz L2lwX3ZzX2NvcmUuYwkyMDA1LTAxLTA0IDAwOjMzOjA2ICswODowMA0KKysr IGIvbmV0L2lwdjQvaXB2cy9pcF92c19jb3JlLmMJMjAwNS0wMS0wNCAwMDoz MzowNiArMDg6MDANCkBAIC0xMTMxLDcgKzExMzEsNyBAQA0KIAkvKiBpbmNy ZWFzZSBpdHMgcGFja2V0IGNvdW50ZXIgYW5kIGNoZWNrIGlmIGl0IGlzIG5l ZWRlZA0KIAkgICB0byBiZSBzeW5jaHJvbml6ZWQgKi8NCiAJYXRvbWljX2lu YygmY3AtPmluX3BrdHMpOw0KLQlpZiAoaXBfdnNfc3luY19zdGF0ZSA9PSBJ UF9WU19TVEFURV9NQVNURVIgJiYNCisJaWYgKGlwX3ZzX3N5bmNfc3RhdGUg JiBJUF9WU19TVEFURV9NQVNURVIgJiYNCiAJICAgIChjcC0+cHJvdG9jb2wg IT0gSVBQUk9UT19UQ1AgfHwNCiAJICAgICBjcC0+c3RhdGUgPT0gSVBfVlNf U19FU1RBQkxJU0hFRCkgJiYNCiAJICAgIChhdG9taWNfcmVhZCgmY3AtPmlu X3BrdHMpICUgNTAgPT0gc3lzY3RsX2lwX3ZzX3N5bmNfdGhyZXNob2xkKSkN CmRpZmYgLU5ydSBhL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMgYi9uZXQv aXB2NC9pcHZzL2lwX3ZzX2N0bC5jDQotLS0gYS9uZXQvaXB2NC9pcHZzL2lw X3ZzX2N0bC5jCTIwMDUtMDEtMDQgMDA6MzM6MDYgKzA4OjAwDQorKysgYi9u ZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTIwMDUtMDEtMDQgMDA6MzM6MDYg KzA4OjAwDQpAQCAtMTczMSwxMCArMTczMSwxMSBAQA0KIAkJcmV0ID0gaXBf dnNfc2V0X3RpbWVvdXRzKHVydWxlKTsNCiAJCWdvdG8gb3V0X3VubG9jazsN CiAJfSBlbHNlIGlmIChjbWQgPT0gSVBfVlNfU09fU0VUX1NUQVJUREFFTU9O KSB7DQotCQlyZXQgPSBzdGFydF9zeW5jX3RocmVhZCh1cnVsZS0+c3RhdGUs IHVydWxlLT5tY2FzdF9pZm4pOw0KKwkJcmV0ID0gc3RhcnRfc3luY190aHJl YWQodXJ1bGUtPnN0YXRlLCB1cnVsZS0+bWNhc3RfaWZuLA0KKwkJCQkJdXJ1 bGUtPnN5bmNpZCk7DQogCQlnb3RvIG91dF91bmxvY2s7DQogCX0gZWxzZSBp ZiAoY21kID09IElQX1ZTX1NPX1NFVF9TVE9QREFFTU9OKSB7DQotCQlyZXQg PSBzdG9wX3N5bmNfdGhyZWFkKCk7DQorCQlyZXQgPSBzdG9wX3N5bmNfdGhy ZWFkKHVydWxlLT5zdGF0ZSk7DQogCQlnb3RvIG91dF91bmxvY2s7DQogCX0g ZWxzZSBpZiAoY21kID09IElQX1ZTX1NPX1NFVF9aRVJPKSB7DQogCQkvKiBp ZiBubyBzZXJ2aWNlIGFkZHJlc3MgaXMgc2V0LCB6ZXJvIGNvdW50ZXJzIGlu IGFsbCAqLw0KQEAgLTIwODIsNyArMjA4MywxMCBAQA0KIAkJCWdvdG8gb3V0 Ow0KIAkJfQ0KIAkJdS5zdGF0ZSA9IGlwX3ZzX3N5bmNfc3RhdGU7DQotCQlz dHJjcHkodS5tY2FzdF9pZm4sIGlwX3ZzX21jYXN0X2lmbik7DQorCQlpZiAo aXBfdnNfc3luY19zdGF0ZSAmIElQX1ZTX1NUQVRFX01BU1RFUikNCisJCQlz dHJjcHkodS5tY2FzdF9tYXN0ZXJfaWZuLCBpcF92c19tY2FzdF9tYXN0ZXJf aWZuKTsNCisJCWlmIChpcF92c19zeW5jX3N0YXRlICYgSVBfVlNfU1RBVEVf QkFDS1VQKQ0KKwkJCXN0cmNweSh1Lm1jYXN0X2JhY2t1cF9pZm4sIGlwX3Zz X21jYXN0X2JhY2t1cF9pZm4pOw0KIAkJaWYgKGNvcHlfdG9fdXNlcih1c2Vy LCAmdSwgc2l6ZW9mKHUpKSAhPSAwKQ0KIAkJCXJldCA9IC1FRkFVTFQ7DQog CX0NCmRpZmYgLU5ydSBhL25ldC9pcHY0L2lwdnMvaXBfdnNfc3luYy5jIGIv bmV0L2lwdjQvaXB2cy9pcF92c19zeW5jLmMNCi0tLSBhL25ldC9pcHY0L2lw dnMvaXBfdnNfc3luYy5jCTIwMDUtMDEtMDQgMDA6MzM6MDYgKzA4OjAwDQor KysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX3N5bmMuYwkyMDA1LTAxLTA0IDAw OjMzOjA2ICswODowMA0KQEAgLTEzLDYgKzEzLDkgQEANCiAgKiAgICAgICAg ICAgICAgdGhyb3VnaCBtdWx0aWNhc3QNCiAgKg0KICAqIENoYW5nZXM6DQor ICoJQWxleGFuZHJlIENhc3NlbiAgICAgICAgOiAgICAgICBBZGRlZCBtYXN0 ZXIgJiBiYWNrdXAgc3VwcG9ydCBhdCBhIHRpbWUuDQorICoJQWxleGFuZHJl IENhc3NlbiAgICAgICAgOiAgICAgICBBZGRlZCBTeW5jSUQgc3VwcG9ydCBm b3IgaW5jb21pbmcgc3luYw0KKyAqCQkJCQltZXNzYWdlcyBmaWx0ZXJpbmcu DQogICoJSnVzdGluIE9zc2V2b29ydAk6CUZpeCBlbmRpYW4gcHJvYmxlbSBv biBzeW5jIG1lc3NhZ2Ugc2l6ZS4NCiAgKi8NCiANCkBAIC03NCw3ICs3Nyw3 IEBADQogICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCi0g ICAgICB8ICBDb3VudCBDb25ucyAgfCAgIFJlc2VydmVkICAgIHwgICAgICAg ICAgICBTaXplICAgICAgICAgICAgICAgfA0KKyAgICAgIHwgIENvdW50IENv bm5zICB8ICAgIFN5bmMgSUQgICAgfCAgICAgICAgICAgIFNpemUgICAgICAg ICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAgICAg ICAgICAgIElQVlMgU3luYyBDb25uZWN0aW9uICgxKSAgICAgICAgICAgICAg ICAgICB8DQpAQCAtODYsMTEgKzg5LDE2IEBADQogICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICBJUFZT IFN5bmMgQ29ubmVjdGlvbiAobikgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQorDQorICAgQ291bnQgQ29ubnMg OiBOdW1iZXIgb2YgSVBWUyBzeW5jIENvbm5lY3Rpb24gZW50cmllcy4NCisg ICBTeW5jIElEICAgICA6IElQVlMgc3luYyBncm91cCB3ZSBiZWxvbmcgdG8u DQorICAgU2l6ZSAgICAgICAgOiBTaXplIG9mIHBhY2tldC4NCisNCiAqLw0K ICNkZWZpbmUgU1lOQ19NRVNHX01BWF9TSVpFICAgICAgKDI0KjUwKzQpDQog c3RydWN0IGlwX3ZzX3N5bmNfbWVzZyB7DQogCV9fdTggICAgICAgICAgICAg ICAgICAgIG5yX2Nvbm5zOw0KLQlfX3U4ICAgICAgICAgICAgICAgICAgICBy ZXNlcnZlZDsNCisJX191OCAgICAgICAgICAgICAgICAgICAgc3luY2lkOw0K IAlfX3UxNiAgICAgICAgICAgICAgICAgICBzaXplOw0KIA0KIAkvKiBpcF92 c19zeW5jX2Nvbm4gZW50cmllcyBzdGFydCBoZXJlICovDQpAQCAtMTE2LDYg KzEyNCwxOCBAQA0KIHN0YXRpYyBzdHJ1Y3QgaXBfdnNfc3luY19idWZmICAg KmN1cnJfc2IgPSBOVUxMOw0KIHN0YXRpYyBzcGlubG9ja190IGN1cnJfc2Jf bG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRDsNCiANCisvKiBpcHZzIHN5bmMg ZGFlbW9uIHN0YXRlICovDQordm9sYXRpbGUgaW50IGlwX3ZzX3N5bmNfc3Rh dGUgPSBJUF9WU19TVEFURV9OT05FOw0KK3ZvbGF0aWxlIGludCBpcF92c19t YXN0ZXJfc3luY2lkID0gMDsNCit2b2xhdGlsZSBpbnQgaXBfdnNfYmFja3Vw X3N5bmNpZCA9IDA7DQorDQorLyogbXVsdGljYXN0IGludGVyZmFjZSBuYW1l ICovDQorY2hhciBpcF92c19tY2FzdF9tYXN0ZXJfaWZuW0lQX1ZTX0lGTkFN RV9NQVhMRU5dOw0KK2NoYXIgaXBfdnNfbWNhc3RfYmFja3VwX2lmbltJUF9W U19JRk5BTUVfTUFYTEVOXTsNCisNCisvKiBtdWx0aWNhc3QgYWRkciAqLw0K K3N0YXRpYyBzdHJ1Y3Qgc29ja2FkZHJfaW4gbWNhc3RfYWRkcjsNCisNCiBz dGF0aWMgaW5saW5lIHZvaWQgc2JfcXVldWVfdGFpbChzdHJ1Y3QgaXBfdnNf c3luY19idWZmICpzYikNCiB7DQogCXNwaW5fbG9jaygmaXBfdnNfc3luY19s b2NrKTsNCkBAIC0xNTMsNiArMTczLDcgQEANCiAJCXJldHVybiBOVUxMOw0K IAl9DQogCXNiLT5tZXNnLT5ucl9jb25ucyA9IDA7DQorCXNiLT5tZXNnLT5z eW5jaWQgPSBpcF92c19tYXN0ZXJfc3luY2lkOw0KIAlzYi0+bWVzZy0+c2l6 ZSA9IDQ7DQogCXNiLT5oZWFkID0gKHVuc2lnbmVkIGNoYXIgKilzYi0+bWVz ZyArIDQ7DQogCXNiLT5lbmQgPSAodW5zaWduZWQgY2hhciAqKXNiLT5tZXNn ICsgU1lOQ19NRVNHX01BWF9TSVpFOw0KQEAgLTI2NSw2ICsyODYsMTMgQEAN CiAJCXJldHVybjsNCiAJfQ0KIA0KKwkvKiBTeW5jSUQgc2FuaXR5IGNoZWNr ICovDQorCWlmIChpcF92c19iYWNrdXBfc3luY2lkICE9IDAgJiYgbS0+c3lu Y2lkICE9IGlwX3ZzX2JhY2t1cF9zeW5jaWQpIHsNCisJCUlQX1ZTX0RCRyg3 LCAiSWdub3JpbmcgaW5jb21pbmcgbXNnIHdpdGggc3luY2lkID0gJWRcbiIs DQorCQkJICBtLT5zeW5jaWQpOw0KKwkJcmV0dXJuOw0KKwl9DQorDQogCXAg PSAoY2hhciAqKWJ1ZmZlciArIHNpemVvZihzdHJ1Y3QgaXBfdnNfc3luY19t ZXNnKTsNCiAJZm9yIChpPTA7IGk8bS0+bnJfY29ubnM7IGkrKykgew0KIAkJ cyA9IChzdHJ1Y3QgaXBfdnNfc3luY19jb25uICopcDsNCkBAIC0zMDgsMTYg KzMzNiw2IEBADQogfQ0KIA0KIA0KLS8qIGlwdnMgc3luYyBkYWVtb24gc3Rh dGUgKi8NCi12b2xhdGlsZSBpbnQgaXBfdnNfc3luY19zdGF0ZSA9IElQX1ZT X1NUQVRFX05PTkU7DQotDQotLyogbXVsdGljYXN0IGludGVyZmFjZSBuYW1l ICovDQotY2hhciBpcF92c19tY2FzdF9pZm5bSVBfVlNfSUZOQU1FX01BWExF Tl07DQotDQotLyogbXVsdGljYXN0IGFkZHIgKi8NCi1zdGF0aWMgc3RydWN0 IHNvY2thZGRyX2luIG1jYXN0X2FkZHI7DQotDQotDQogLyoNCiAgKiAgICAg IFNldHVwIGxvb3BiYWNrIG9mIG91dGdvaW5nIG11bHRpY2FzdHMgb24gYSBz ZW5kaW5nIHNvY2tldA0KICAqLw0KQEAgLTQyOSw3ICs0NDcsNyBAQA0KIAkJ cmV0dXJuIE5VTEw7DQogCX0NCiANCi0JaWYgKHNldF9tY2FzdF9pZihzb2Nr LT5zaywgaXBfdnNfbWNhc3RfaWZuKSA8IDApIHsNCisJaWYgKHNldF9tY2Fz dF9pZihzb2NrLT5zaywgaXBfdnNfbWNhc3RfbWFzdGVyX2lmbikgPCAwKSB7 DQogCQlJUF9WU19FUlIoIkVycm9yIHNldHRpbmcgb3V0Ym91bmQgbWNhc3Qg aW50ZXJmYWNlXG4iKTsNCiAJCWdvdG8gZXJyb3I7DQogCX0NCkBAIC00Mzcs NyArNDU1LDcgQEANCiAJc2V0X21jYXN0X2xvb3Aoc29jay0+c2ssIDApOw0K IAlzZXRfbWNhc3RfdHRsKHNvY2stPnNrLCAxKTsNCiANCi0JaWYgKGJpbmRf bWNhc3RpZl9hZGRyKHNvY2ssIGlwX3ZzX21jYXN0X2lmbikgPCAwKSB7DQor CWlmIChiaW5kX21jYXN0aWZfYWRkcihzb2NrLCBpcF92c19tY2FzdF9tYXN0 ZXJfaWZuKSA8IDApIHsNCiAJCUlQX1ZTX0VSUigiRXJyb3IgYmluZGluZyBh ZGRyZXNzIG9mIHRoZSBtY2FzdCBpbnRlcmZhY2VcbiIpOw0KIAkJZ290byBl cnJvcjsNCiAJfQ0KQEAgLTQ4Myw3ICs1MDEsNyBAQA0KIAkvKiBqb2luIHRo ZSBtdWx0aWNhc3QgZ3JvdXAgKi8NCiAJaWYgKGpvaW5fbWNhc3RfZ3JvdXAo c29jay0+c2ssDQogCQkJICAgICAoc3RydWN0IGluX2FkZHIqKSZtY2FzdF9h ZGRyLnNpbl9hZGRyLA0KLQkJCSAgICAgaXBfdnNfbWNhc3RfaWZuKSA8IDAp IHsNCisJCQkgICAgIGlwX3ZzX21jYXN0X2JhY2t1cF9pZm4pIDwgMCkgew0K IAkJSVBfVlNfRVJSKCJFcnJvciBqb2luaW5nIHRvIHRoZSBtdWx0aWNhc3Qg Z3JvdXBcbiIpOw0KIAkJZ290byBlcnJvcjsNCiAJfQ0KQEAgLTU3MSwxMCAr NTg5LDEyIEBADQogDQogDQogc3RhdGljIERFQ0xBUkVfV0FJVF9RVUVVRV9I RUFEKHN5bmNfd2FpdCk7DQotc3RhdGljIHBpZF90IHN5bmNfcGlkID0gMDsN CitzdGF0aWMgcGlkX3Qgc3luY19tYXN0ZXJfcGlkID0gMDsNCitzdGF0aWMg cGlkX3Qgc3luY19iYWNrdXBfcGlkID0gMDsNCiANCiBzdGF0aWMgREVDTEFS RV9XQUlUX1FVRVVFX0hFQUQoc3RvcF9zeW5jX3dhaXQpOw0KLXN0YXRpYyBp bnQgc3RvcF9zeW5jID0gMDsNCitzdGF0aWMgaW50IHN0b3BfbWFzdGVyX3N5 bmMgPSAwOw0KK3N0YXRpYyBpbnQgc3RvcF9iYWNrdXBfc3luYyA9IDA7DQog DQogc3RhdGljIHZvaWQgc3luY19tYXN0ZXJfbG9vcCh2b2lkKQ0KIHsNCkBA IC01ODYsNiArNjA2LDEwIEBADQogCWlmICghc29jaykNCiAJCXJldHVybjsN CiANCisJSVBfVlNfSU5GTygic3luYyB0aHJlYWQgc3RhcnRlZDogc3RhdGUg PSBNQVNURVIsIG1jYXN0X2lmbiA9ICVzLCAiDQorCQkgICAic3luY2lkID0g JWRcbiIsDQorCQkgICBpcF92c19tY2FzdF9tYXN0ZXJfaWZuLCBpcF92c19t YXN0ZXJfc3luY2lkKTsNCisNCiAJZm9yICg7Oykgew0KIAkJd2hpbGUgKChz Yj1zYl9kZXF1ZXVlKCkpKSB7DQogCQkJaXBfdnNfc2VuZF9zeW5jX21zZyhz b2NrLCBzYi0+bWVzZyk7DQpAQCAtNTk4LDcgKzYyMiw3IEBADQogCQkJaXBf dnNfc3luY19idWZmX3JlbGVhc2Uoc2IpOw0KIAkJfQ0KIA0KLQkJaWYgKHN0 b3Bfc3luYykNCisJCWlmIChzdG9wX21hc3Rlcl9zeW5jKQ0KIAkJCWJyZWFr Ow0KIA0KIAkJX19zZXRfY3VycmVudF9zdGF0ZShUQVNLX0lOVEVSUlVQVElC TEUpOw0KQEAgLTYzNyw2ICs2NjEsMTAgQEANCiAJaWYgKCFzb2NrKQ0KIAkJ Z290byBvdXQ7DQogDQorCUlQX1ZTX0lORk8oInN5bmMgdGhyZWFkIHN0YXJ0 ZWQ6IHN0YXRlID0gQkFDS1VQLCBtY2FzdF9pZm4gPSAlcywgIg0KKwkJICAg InN5bmNpZCA9ICVkXG4iLA0KKwkJICAgaXBfdnNfbWNhc3RfYmFja3VwX2lm biwgaXBfdnNfYmFja3VwX3N5bmNpZCk7DQorDQogCWZvciAoOzspIHsNCiAJ CS8qIGRvIHlvdSBoYXZlIGRhdGEgbm93PyAqLw0KIAkJd2hpbGUgKCFza2Jf cXVldWVfZW1wdHkoJihzb2NrLT5zay0+cmVjZWl2ZV9xdWV1ZSkpKSB7DQpA QCAtNjUyLDcgKzY4MCw3IEBADQogCQkJbG9jYWxfYmhfZW5hYmxlKCk7DQog CQl9DQogDQotCQlpZiAoc3RvcF9zeW5jKQ0KKwkJaWYgKHN0b3BfYmFja3Vw X3N5bmMpDQogCQkJYnJlYWs7DQogDQogCQlfX3NldF9jdXJyZW50X3N0YXRl KFRBU0tfSU5URVJSVVBUSUJMRSk7DQpAQCAtNjY3LDEyICs2OTUsMzEgQEAN CiAJa2ZyZWUoYnVmKTsNCiB9DQogDQorc3RhdGljIHZvaWQgc3luY19waWRf c2V0KGludCBzeW5jX3N0YXRlLCBwaWRfdCBzeW5jX3BpZCkNCit7DQorCWlm IChzeW5jX3N0YXRlID09IElQX1ZTX1NUQVRFX01BU1RFUikNCisJCXN5bmNf bWFzdGVyX3BpZCA9IHN5bmNfcGlkOw0KKwllbHNlIGlmIChzeW5jX3N0YXRl ID09IElQX1ZTX1NUQVRFX0JBQ0tVUCkNCisJCXN5bmNfYmFja3VwX3BpZCA9 IHN5bmNfcGlkOw0KK30NCisNCitzdGF0aWMgdm9pZCBzeW5jX3N0b3Bfc2V0 KGludCBzeW5jX3N0YXRlLCBpbnQgc2V0KQ0KK3sNCisJaWYgKHN5bmNfc3Rh dGUgPT0gSVBfVlNfU1RBVEVfTUFTVEVSKQ0KKwkJc3RvcF9tYXN0ZXJfc3lu YyA9IHNldDsNCisJZWxzZSBpZiAoc3luY19zdGF0ZSA9PSBJUF9WU19TVEFU RV9CQUNLVVApDQorCQlzdG9wX2JhY2t1cF9zeW5jID0gc2V0Ow0KKwllbHNl IHsNCisJCXN0b3BfbWFzdGVyX3N5bmMgPSBzZXQ7DQorCQlzdG9wX2JhY2t1 cF9zeW5jID0gc2V0Ow0KKwl9DQorfQ0KIA0KIHN0YXRpYyBpbnQgc3luY190 aHJlYWQodm9pZCAqc3RhcnR1cCkNCiB7DQogCURFQ0xBUkVfV0FJVFFVRVVF KHdhaXQsIGN1cnJlbnQpOw0KIAltbV9zZWdtZW50X3Qgb2xkbW07DQotCWlu dCBzdGF0ZTsNCisJaW50IHN0YXRlID0gSVBfVlNfU1RBVEVfTk9ORTsNCiAN CiAJTU9EX0lOQ19VU0VfQ09VTlQ7DQogCWRhZW1vbml6ZSgpOw0KQEAgLTY4 MCwxMiArNzI3LDE1IEBADQogCW9sZG1tID0gZ2V0X2ZzKCk7DQogCXNldF9m cyhLRVJORUxfRFMpOw0KIA0KLQlpZiAoaXBfdnNfc3luY19zdGF0ZSA9PSBJ UF9WU19TVEFURV9NQVNURVIpDQorCWlmIChpcF92c19zeW5jX3N0YXRlICYg SVBfVlNfU1RBVEVfTUFTVEVSICYmICFzeW5jX21hc3Rlcl9waWQpIHsNCisJ CXN0YXRlID0gSVBfVlNfU1RBVEVfTUFTVEVSOw0KIAkJc3ByaW50ZihjdXJy ZW50LT5jb21tLCAiaXB2c19zeW5jbWFzdGVyIik7DQotCWVsc2UgaWYgKGlw X3ZzX3N5bmNfc3RhdGUgPT0gSVBfVlNfU1RBVEVfQkFDS1VQKQ0KKwl9IGVs c2UgaWYgKGlwX3ZzX3N5bmNfc3RhdGUgJiBJUF9WU19TVEFURV9CQUNLVVAp IHsNCisJCXN0YXRlID0gSVBfVlNfU1RBVEVfQkFDS1VQOw0KIAkJc3ByaW50 ZihjdXJyZW50LT5jb21tLCAiaXB2c19zeW5jYmFja3VwIik7DQotCWVsc2Ug SVBfVlNfQlVHKCk7DQorCX0gZWxzZSBJUF9WU19CVUcoKTsNCiANCisJLyog QmxvY2sgYWxsIHNpZ25hbHMgKi8NCiAJc3Bpbl9sb2NrX2lycSgmY3VycmVu dC0+c2lnbWFza19sb2NrKTsNCiAJc2lnaW5pdHNldGludigmY3VycmVudC0+ YmxvY2tlZCwgMCk7DQogCXJlY2FsY19zaWdwZW5kaW5nKGN1cnJlbnQpOw0K QEAgLTY5OCw5ICs3NDgsNyBAQA0KIA0KIAlhZGRfd2FpdF9xdWV1ZSgmc3lu Y193YWl0LCAmd2FpdCk7DQogDQotCXN0YXRlID0gaXBfdnNfc3luY19zdGF0 ZTsNCi0Jc3luY19waWQgPSBjdXJyZW50LT5waWQ7DQotCUlQX1ZTX0lORk8o InN5bmMgdGhyZWFkIHN0YXJ0ZWQuXG4iKTsNCisJc3luY19waWRfc2V0KHN0 YXRlLCBjdXJyZW50LT5waWQpOw0KIAljb21wbGV0ZSgoc3RydWN0IGNvbXBs ZXRpb24gKilzdGFydHVwKTsNCiANCiAJLyogcHJvY2Vzc2luZyBtYXN0ZXIv YmFja3VwIGxvb3AgaGVyZSAqLw0KQEAgLTcxMywxMyArNzYxLDEzIEBADQog CXJlbW92ZV93YWl0X3F1ZXVlKCZzeW5jX3dhaXQsICZ3YWl0KTsNCiANCiAJ LyogdGhyZWFkIGV4aXRzICovDQotCXN5bmNfcGlkID0gMDsNCisJc3luY19w aWRfc2V0KHN0YXRlLCAwKTsNCiAJSVBfVlNfSU5GTygic3luYyB0aHJlYWQg c3RvcHBlZCFcbiIpOw0KIA0KIAlzZXRfZnMob2xkbW0pOw0KIAlNT0RfREVD X1VTRV9DT1VOVDsNCiANCi0Jc3RvcF9zeW5jID0gMDsNCisJc3luY19zdG9w X3NldChzdGF0ZSwgMCk7DQogCXdha2VfdXAoJnN0b3Bfc3luY193YWl0KTsN CiANCiAJcmV0dXJuIDA7DQpAQCAtNzQ1LDIwICs3OTMsMjcgQEANCiB9DQog DQogDQotaW50IHN0YXJ0X3N5bmNfdGhyZWFkKGludCBzdGF0ZSwgY2hhciAq bWNhc3RfaWZuKQ0KK2ludCBzdGFydF9zeW5jX3RocmVhZChpbnQgc3RhdGUs IGNoYXIgKm1jYXN0X2lmbiwgX191OCBzeW5jaWQpDQogew0KIAlERUNMQVJF X0NPTVBMRVRJT04oc3RhcnR1cCk7DQogCXBpZF90IHBpZDsNCiANCi0JaWYg KHN5bmNfcGlkKQ0KKwlpZiAoKHN0YXRlID09IElQX1ZTX1NUQVRFX01BU1RF UiAmJiBzeW5jX21hc3Rlcl9waWQpIHx8DQorCSAgICAoc3RhdGUgPT0gSVBf VlNfU1RBVEVfQkFDS1VQICYmIHN5bmNfYmFja3VwX3BpZCkpDQogCQlyZXR1 cm4gLUVFWElTVDsNCiANCiAJSVBfVlNfREJHKDcsICIlczogcGlkICVkXG4i LCBfX0ZVTkNUSU9OX18sIGN1cnJlbnQtPnBpZCk7DQogCUlQX1ZTX0RCRyg3 LCAiRWFjaCBpcF92c19zeW5jX2Nvbm4gZW50cnkgbmVlZCAlZCBieXRlc1xu IiwNCiAJCSAgc2l6ZW9mKHN0cnVjdCBpcF92c19zeW5jX2Nvbm4pKTsNCiAN Ci0JaXBfdnNfc3luY19zdGF0ZSA9IHN0YXRlOw0KLQlzdHJjcHkoaXBfdnNf bWNhc3RfaWZuLCBtY2FzdF9pZm4pOw0KKwlpcF92c19zeW5jX3N0YXRlIHw9 IHN0YXRlOw0KKwlpZiAoc3RhdGUgPT0gSVBfVlNfU1RBVEVfTUFTVEVSKSB7 DQorCQlzdHJjcHkoaXBfdnNfbWNhc3RfbWFzdGVyX2lmbiwgbWNhc3RfaWZu KTsNCisJCWlwX3ZzX21hc3Rlcl9zeW5jaWQgPSBzeW5jaWQ7DQorCX0gZWxz ZSB7DQorCQlzdHJjcHkoaXBfdnNfbWNhc3RfYmFja3VwX2lmbiwgbWNhc3Rf aWZuKTsNCisJCWlwX3ZzX2JhY2t1cF9zeW5jaWQgPSBzeW5jaWQ7DQorCX0N CiANCiAgIHJlcGVhdDoNCiAJaWYgKChwaWQgPSBrZXJuZWxfdGhyZWFkKGZv cmtfc3luY190aHJlYWQsICZzdGFydHVwLCAwKSkgPCAwKSB7DQpAQCAtNzc1 LDIwICs4MzAsMjIgQEANCiB9DQogDQogDQotaW50IHN0b3Bfc3luY190aHJl YWQodm9pZCkNCitpbnQgc3RvcF9zeW5jX3RocmVhZChpbnQgc3RhdGUpDQog ew0KIAlERUNMQVJFX1dBSVRRVUVVRSh3YWl0LCBjdXJyZW50KTsNCiANCi0J aWYgKCFzeW5jX3BpZCkNCisJaWYgKChzdGF0ZSA9PSBJUF9WU19TVEFURV9N QVNURVIgJiYgIXN5bmNfbWFzdGVyX3BpZCkgfHwNCisJICAgIChzdGF0ZSA9 PSBJUF9WU19TVEFURV9CQUNLVVAgJiYgIXN5bmNfYmFja3VwX3BpZCkpDQog CQlyZXR1cm4gLUVTUkNIOw0KIA0KIAlJUF9WU19EQkcoNywgIiVzOiBwaWQg JWRcbiIsIF9fRlVOQ1RJT05fXywgY3VycmVudC0+cGlkKTsNCi0JSVBfVlNf SU5GTygic3RvcHBpbmcgc3luYyB0aHJlYWQgJWQgLi4uXG4iLCBzeW5jX3Bp ZCk7DQorCUlQX1ZTX0lORk8oInN0b3BwaW5nIHN5bmMgdGhyZWFkICVkIC4u LlxuIiwNCisJCSAgIChzdGF0ZSA9PSBJUF9WU19TVEFURV9NQVNURVIpID8g c3luY19tYXN0ZXJfcGlkIDogc3luY19iYWNrdXBfcGlkKTsNCiANCiAJX19z ZXRfY3VycmVudF9zdGF0ZShUQVNLX1VOSU5URVJSVVBUSUJMRSk7DQogCWFk ZF93YWl0X3F1ZXVlKCZzdG9wX3N5bmNfd2FpdCwgJndhaXQpOw0KLQlpcF92 c19zeW5jX3N0YXRlID0gSVBfVlNfU1RBVEVfTk9ORTsNCi0Jc3RvcF9zeW5j ID0gMTsNCisJc3luY19zdG9wX3NldChzdGF0ZSwgMSk7DQorCWlwX3ZzX3N5 bmNfc3RhdGUgLT0gc3RhdGU7DQogCXdha2VfdXAoJnN5bmNfd2FpdCk7DQog CXNjaGVkdWxlKCk7DQogCV9fc2V0X2N1cnJlbnRfc3RhdGUoVEFTS19SVU5O SU5HKTsNCkBAIC03OTcsNyArODU0LDggQEANCiAJLyogTm90ZTogbm8gbmVl ZCB0byByZWFwIHRoZSBzeW5jIHRocmVhZCwgYmVjYXVzZSBpdHMgcGFyZW50 DQogCSAgIHByb2Nlc3MgaXMgdGhlIGluaXQgcHJvY2VzcyAqLw0KIA0KLQlp ZiAoc3RvcF9zeW5jKQ0KKwlpZiAoKHN0YXRlID09IElQX1ZTX1NUQVRFX01B U1RFUiAmJiBzdG9wX21hc3Rlcl9zeW5jKSB8fA0KKwkgICAgKHN0YXRlID09 IElQX1ZTX1NUQVRFX0JBQ0tVUCAmJiBzdG9wX2JhY2t1cF9zeW5jKSkNCiAJ CUlQX1ZTX0JVRygpOw0KIA0KIAlyZXR1cm4gMDsNCg== ---1463811584-572891765-1097000265=:2451-- From roland@topspin.com Mon Jan 3 08:46:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 08:46:53 -0800 (PST) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03GkPFl011134 for ; Mon, 3 Jan 2005 08:46:45 -0800 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Jan 2005 08:55:00 -0800 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Jan 2005 08:54:59 -0800 Received: from roland by eddore with local (Exim 4.34) id 1ClVTv-0002Yi-Bc; Mon, 03 Jan 2005 08:54:59 -0800 To: Eric Lemoine Cc: hadi@cyberus.ca, Andi Kleen , Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com, openib-general@openib.org X-Message-Flag: Warning: May contain useful information References: <52llbwoaej.fsf@topspin.com> <5cac192f04122210491d64d4b6@mail.gmail.com> <20041222202919.057b8331.davem@davemloft.net> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> <1104764660.1048.578.camel@jzny.localdomain> <52brc68q05.fsf@topspin.com> <5cac192f05010308414a25b548@mail.gmail.com> From: Roland Dreier Date: Mon, 03 Jan 2005 08:54:59 -0800 In-Reply-To: <5cac192f05010308414a25b548@mail.gmail.com> (Eric Lemoine's message of "Mon, 3 Jan 2005 17:41:05 +0100") Message-ID: <527jmu8nbw.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: LLTX and netif_stop_queue Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 03 Jan 2005 16:55:00.0006 (UTC) FILETIME=[F6317460:01C4F1B4] X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Eric> What are your machines? In particular, how many CPUs do they have? Dual Xeons with HT on, so they look like 4 CPUs. - R. From eric.lemoine@gmail.com Mon Jan 3 08:58:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 08:58:58 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03GwUJI011890 for ; Mon, 3 Jan 2005 08:58:51 -0800 Received: by wproxy.gmail.com with SMTP id 71so1342477wra for ; Mon, 03 Jan 2005 09:07:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=LG2/9QmpfiE0lmO++pln2mMGFeMpQYugpOLjwNyRBNK/OG6YzfxSf9CAwcSP+fM2gOp/Fz0ZZtR/er35QYFol+zXOJxMovDuZlZcoj6cepCRhUxNERWWhzgVzYLJw4iqcnzT22epQQsSHhT0SnHhhMEoKQNqSkchuQW6vwqqPes= Received: by 10.54.16.72 with SMTP id 72mr78682wrp; Mon, 03 Jan 2005 09:07:00 -0800 (PST) Received: by 10.54.30.8 with HTTP; Mon, 3 Jan 2005 09:07:00 -0800 (PST) Message-ID: <5cac192f0501030907c755135@mail.gmail.com> Date: Mon, 3 Jan 2005 18:07:00 +0100 From: Eric Lemoine Reply-To: Eric Lemoine To: Roland Dreier Subject: Re: LLTX and netif_stop_queue Cc: hadi@cyberus.ca, Andi Kleen , Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com, openib-general@openib.org In-Reply-To: <527jmu8nbw.fsf@topspin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <52llbwoaej.fsf@topspin.com> <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> <1104764660.1048.578.camel@jzny.localdomain> <52brc68q05.fsf@topspin.com> <5cac192f05010308414a25b548@mail.gmail.com> <527jmu8nbw.fsf@topspin.com> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev On Mon, 03 Jan 2005 08:54:59 -0800, Roland Dreier wrote: > Eric> What are your machines? In particular, how many CPUs do they have? > > Dual Xeons with HT on, so they look like 4 CPUs. If I understand correctly, LLTX aims at avoiding cache misses on lock variables (because of cacheline bouncing). So the effect of LLTX should increase as the number of CPUs not sharing the same cache increases. And two CPUs might not be enough... -- Eric From grundler@cup.hp.com Mon Jan 3 09:05:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 09:05:20 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03H4bHo012486 for ; Mon, 3 Jan 2005 09:05:13 -0800 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id C1D34E751; Mon, 3 Jan 2005 09:13:05 -0800 (PST) Received: from localhost.localdomain (postfix@debian.cup.hp.com [15.244.57.47]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id JAA19635; Mon, 3 Jan 2005 09:09:57 -0800 (PST) Received: by localhost.localdomain (Postfix, from userid 1000) id 8E5C19009A; Mon, 3 Jan 2005 09:12:27 -0800 (PST) Date: Mon, 3 Jan 2005 09:12:27 -0800 From: Grant Grundler To: Eric Lemoine Cc: Roland Dreier , netdev@oss.sgi.com, hadi@cyberus.ca, Andi Kleen , openib-general@openib.org, Patrick McHardy , "David S. Miller" Subject: Re: [openib-general] Re: LLTX and netif_stop_queue Message-ID: <20050103171227.GD7370@esmail.cup.hp.com> References: <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> <1104764660.1048.578.camel@jzny.localdomain> <52brc68q05.fsf@topspin.com> <5cac192f05010308414a25b548@mail.gmail.com> <527jmu8nbw.fsf@topspin.com> <5cac192f0501030907c755135@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5cac192f0501030907c755135@mail.gmail.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: iod00d@hp.com Precedence: bulk X-list: netdev On Mon, Jan 03, 2005 at 06:07:00PM +0100, Eric Lemoine wrote: > If I understand correctly, LLTX aims at avoiding cache misses on lock > variables (because of cacheline bouncing). So the effect of LLTX > should increase as the number of CPUs not sharing the same cache > increases. And two CPUs might not be enough... Cacheline bouncing usually starts to show up with > 4 CPUs (ie 8 or more). Some workloads that Jamal cares about (routing) only need 2 cpus. grant From pb@bieringer.de Mon Jan 3 12:30:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 12:30:45 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03KUDZj023653 for ; Mon, 3 Jan 2005 12:30:34 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 55152137EE; Mon, 3 Jan 2005 21:38:46 +0100 (CET) X-AV-Checked: Mon Jan 3 21:38:46 2005 smtp2.aerasec.de Received: from [192.168.1.2] (p50805EF3.dip.t-dialin.net [80.128.94.243]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id 8774C137EA; Mon, 3 Jan 2005 21:38:44 +0100 (CET) Date: Mon, 03 Jan 2005 21:38:41 +0100 From: Peter Bieringer To: Maillist USAGI-users , Maillist netdev Subject: Sneak preview: IPv6-IPsec now described in Linux+IPv6-HOWTO Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Hi, I wrote some information about IPv6-IPsec in an intermediate release (0.47.1) of my howto, sneak preview is available at following locations: Perhaps one has some time for review and suggestions until Sunday, when I plan a new major release, which will submitted to TLDP also. BTW: does anyone know the status of the IPsec backport from 2.6 to 2.4? Thank you very much, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From jeremy.guthrie@berbee.com Mon Jan 3 12:47:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 12:47:30 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03Kkx21024507 for ; Mon, 3 Jan 2005 12:47:23 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Jan 2005 14:55:28 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: V2.4 policy router operates faster/better than V2.6 Date: Mon, 3 Jan 2005 14:55:24 -0600 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6658067.kfCW7YP8Jb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501031455.26980.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 03 Jan 2005 20:55:28.0766 (UTC) FILETIME=[8E6781E0:01C4F1D6] X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart6658067.kfCW7YP8Jb Content-Type: multipart/mixed; boundary="Boundary-01=_8Eb2BlUDcnK2yQT" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_8Eb2BlUDcnK2yQT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have a dual processor box running Suse 9.1 Ent. that I changed over to th= e=20 V2.6.10 kernel. The box has two interfaces in it, both E1000s. The box=20 receives anywhere from 200mbit to 500+ mbit that it needs to route out to= =20 other boxes. The policy routing table is running ~ 150-200 rules. ie. da= ta=20 comes in E3(e1000), is policy routed to a destination sent out E2(e1000). Under V2.4 kernels, the system will operate just fine and drop few packets = if=20 any. ie. right now under V2.4, I have dropped all of three packets. Under= =20 2.6, I can watch the RX drop counter increment. See below. [h-pr-msn-1 guthrie 1:48pm]~-> ifconfig eth3 ; sleep 10 ; ifconfig eth3 eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 inet addr:10.253.0.1 Bcast:10.255.255.255 Mask:255.255.255.0 inet6 addr: fe80::202:b3ff:fed5:7e30/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:132919934 errors:311285 dropped:311285 overruns:247225= =20 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2630721320 (2508.8 Mb) TX bytes:484 (484.0 b) Base address:0x22a0 Memory:eff80000-effa0000 eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 inet addr:10.253.0.1 Bcast:10.255.255.255 Mask:255.255.255.0 inet6 addr: fe80::202:b3ff:fed5:7e30/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:133847068 errors:325697 dropped:325697 overruns:258546= =20 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3102796062 (2959.0 Mb) TX bytes:484 (484.0 b) Base address:0x22a0 Memory:eff80000-effa0000 If I turn off the policy routing, I instantly stop getting RX errors or=20 overruns as it appears the CPU can now pay attention to the packets coming = in=20 and drop them(as I turned off IP forwarding as well). V2.4 Kernel mpstat data: command: mpstat -P ALL 60 Linux 2.4.21-251-smp (h-pr-msn-1) 12/15/2004 01:16:24 PM CPU %user %nice %system %idle intr/s 01:17:19 PM all 0.16 0.00 50.12 49.72 42114.18 01:17:19 PM 0 0.12 0.00 55.60 44.28 42114.18 01:17:19 PM 1 0.20 0.00 44.65 55.15 42114.18 01:17:19 PM CPU %user %nice %system %idle intr/s 01:18:19 PM all 0.13 0.00 48.49 51.38 42103.08 01:18:19 PM 0 0.13 0.00 31.88 67.98 42103.08 01:18:19 PM 1 0.13 0.00 65.10 34.77 42103.08 V2.6 kernel mpstat data: command: mpstat -P ALL 60 Linux 2.6.5-7.111.5-smp (h-pr-msn-1) 12/15/04 13:36:25 CPU %user %nice %system %iowait %irq %soft %idle = =20 intr/s 13:37:25 all 0.13 0.00 0.15 0.09 2.03 43.14 54.45 =20 25506.53 13:37:25 0 0.17 0.00 0.08 0.18 0.00 16.81 82.76 = =20 2215.63 13:37:25 1 0.08 0.00 0.20 0.00 4.08 69.49 26.14 =20 23291.34 13:37:25 CPU %user %nice %system %iowait %irq %soft %idle = =20 intr/s 13:38:24 all 0.14 0.00 0.12 0.12 2.02 42.89 54.71 =20 25900.70 13:38:24 0 0.03 0.00 0.05 0.22 0.00 16.67 83.03 = =20 2246.10 13:38:24 1 0.25 0.00 0.20 0.03 4.02 69.12 26.40 =20 23654.55 Any insights as to why there would be such a stark difference in performanc= e=20 between V2.6 and V2.4? Please advise. =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --Boundary-01=_8Eb2BlUDcnK2yQT Content-Type: application/pgp-keys; name="OpenPGP key 0x719905E5" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0x719905E5.asc -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQGiBDtxSucRBACqnISb8M/pvbF1gUb7iCPB7t6XbFa5237KsRZHBaeugLdtKCw3 8ulxSrEAsDHFgRJ3eFNWXEX5LEu52CI/riyhR9qzWYTtomddLNAOfZpyalKBtyxC P9nv0WwYxvmEnsrgnfsJ41mVBaW0Ft5f/IbeyxwZbAxqwHJm2nM4QOVYcwCgng9G Cw79l9J91FaUVNPMcupFLPMD/0u15pANW+jBXeTFBHLjAp60PFROr4Z0ePBdIGqD bKV6dX7vfPv/rMhaImUozr/rCCllmrzEFwC63WGZ6QGEl9zzB49vdcwEkPZfMneY j+QNrAc3OA0cRHm07DugnhRpgawJMzuc9UV9kN3CL0p0zZ7Be94YrNb0tEsSfEJQ kd2zA/4hQoJmYeDf/UgZZnmWsWioay/S6/9s+ENvkd0/QjLYe1SLU6STeBCkmJWe fk3iSBYpRquj9w+5v8spltu91nhv5K8giTFiidk6inQ70yH/Dz8FKflWuMhbEGUL SLLXWtWLJUB2wShvMbEpKVIcVn3ylrBZEF7qGNFdiUwqQkVe/7RBSmVyZW15IE0u IEd1dGhyaWUgKEplcmVteSBNLiBHdXRocmllKSA8amVyZW15Lmd1dGhyaWVAYmVy YmVlLmNvbT6IZAQTEQIAJAUCQEziyQIbAwUJB+pfZwYLCQgHAwIDFQIDAxYCAQIe AQIXgAAKCRCq2NoEcZkF5cWLAJ986CQQIz7zVV2z+TgucV3LOYRXDwCaAiwptN0c quyV1upu4f8GQAtNd9i5Ag0EO3FK8RAIAMi4ZmMfAGAv9n7m3n5HXmAfHARllCv2 2nxzZYMKp9XmAHLl7NbvxOw6rs+hWFufL1QfGxiHaaMTO64gPUi64+kKFWoGwTY5 AfidjLhNFWoP+gNIc1Mi90J6ZQuXwZI+mieRWTQNE4B9R7ZRftBH05Sj63ioqfbr uPszGXiunM2S8V3z1U/L9GIvqIW7+tiFYmgXMzW7H2ElIV11Nl+AFqihVSqljXvG Gi6zkD4OAK6O3fRHtjOTf55eZHHlQ+WjgTn+FtrBQFLRwZ+KDaBOymAjdxoxhe3n +ZDegk+HzWSPzv8929LGTZeTCI1OMTl/S6AXwwwNGiAZjfVXTsa018MAAwUH/2KG szyDYLLMd72TK7Yojsvltf84ctK+2hscYrYf34MjNu4ODqe0a/1gwxvfvG4zaIQ5 fWJgFzA/JuprE/gFp9JnSAtvrTBTno4KYlwJggkq5KVpfZs5GDN4Q9uecdvJZ17y EGasTfyxuTnyxdpHtNkn9ehfs1aVPbd4QzolO0N2QZB2YDBw/GPZ6rgeo/XKkzqg AoIOwlyWVRgGb5Hv93fNOXhbQ+xMpw4uieeBr8p6B/nwlp/o5M6H676aY9JTf9Up hdbcBKQpe2Zs54grERng/Q9KJqCDFh65BKGMc7ceckSRhzaKwGF3Wa1BSVn/dLsz d/0FZ9UX1Cs9LsKnRlCITAQYEQIADAUCPbgP6QUJB+pfeAAKCRCq2NoEcZkF5QvZ AJ0byLfrhE+kbl+PXTRJ9eeU//O/+wCffaUH/md38U3ZkCgxOcRmPqmf3W0= =03qu -----END PGP PUBLIC KEY BLOCK----- --Boundary-01=_8Eb2BlUDcnK2yQT-- --nextPart6658067.kfCW7YP8Jb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB2bE+qtjaBHGZBeURAgEjAJsEepf2zXr5iYSXdm135VDp627O9QCfd/+E r/oNJpgFcPI8IH8Lw1fUICU= =Fh1p -----END PGP SIGNATURE----- --nextPart6658067.kfCW7YP8Jb-- From shemminger@osdl.org Mon Jan 3 14:43:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 14:43:22 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03MgoKr028701 for ; Mon, 3 Jan 2005 14:43:15 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j03MpF604659; Mon, 3 Jan 2005 14:51:16 -0800 Date: Mon, 3 Jan 2005 14:51:15 -0800 From: Stephen Hemminger To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Message-Id: <20050103145115.4bdb2cd6@dxpl.pdx.osdl.net> In-Reply-To: <200501031455.26980.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; x86_64-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 3 Jan 2005 14:55:24 -0600 "Jeremy M. Guthrie" wrote: > I have a dual processor box running Suse 9.1 Ent. that I changed over to the > V2.6.10 kernel. The box has two interfaces in it, both E1000s. The box > receives anywhere from 200mbit to 500+ mbit that it needs to route out to > other boxes. The policy routing table is running ~ 150-200 rules. ie. data > comes in E3(e1000), is policy routed to a destination sent out E2(e1000). > > Under V2.4 kernels, the system will operate just fine and drop few packets if > any. ie. right now under V2.4, I have dropped all of three packets. Under > 2.6, I can watch the RX drop counter increment. See below. > > [h-pr-msn-1 guthrie 1:48pm]~-> ifconfig eth3 ; sleep 10 ; ifconfig eth3 > eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 > inet addr:10.253.0.1 Bcast:10.255.255.255 Mask:255.255.255.0 > inet6 addr: fe80::202:b3ff:fed5:7e30/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:132919934 errors:311285 dropped:311285 overruns:247225 > frame:0 > TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:2630721320 (2508.8 Mb) TX bytes:484 (484.0 b) > Base address:0x22a0 Memory:eff80000-effa0000 > > eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 > inet addr:10.253.0.1 Bcast:10.255.255.255 Mask:255.255.255.0 > inet6 addr: fe80::202:b3ff:fed5:7e30/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:133847068 errors:325697 dropped:325697 overruns:258546 > frame:0 > TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3102796062 (2959.0 Mb) TX bytes:484 (484.0 b) > Base address:0x22a0 Memory:eff80000-effa0000 > > If I turn off the policy routing, I instantly stop getting RX errors or > overruns as it appears the CPU can now pay attention to the packets coming in > and drop them(as I turned off IP forwarding as well). > > V2.4 Kernel mpstat data: > command: mpstat -P ALL 60 > Linux 2.4.21-251-smp (h-pr-msn-1) 12/15/2004 > > 01:16:24 PM CPU %user %nice %system %idle intr/s > 01:17:19 PM all 0.16 0.00 50.12 49.72 42114.18 > 01:17:19 PM 0 0.12 0.00 55.60 44.28 42114.18 > 01:17:19 PM 1 0.20 0.00 44.65 55.15 42114.18 > > 01:17:19 PM CPU %user %nice %system %idle intr/s > 01:18:19 PM all 0.13 0.00 48.49 51.38 42103.08 > 01:18:19 PM 0 0.13 0.00 31.88 67.98 42103.08 > 01:18:19 PM 1 0.13 0.00 65.10 34.77 42103.08 > > V2.6 kernel mpstat data: > command: mpstat -P ALL 60 > Linux 2.6.5-7.111.5-smp (h-pr-msn-1) 12/15/04 > > 13:36:25 CPU %user %nice %system %iowait %irq %soft %idle > intr/s > 13:37:25 all 0.13 0.00 0.15 0.09 2.03 43.14 54.45 > 25506.53 > 13:37:25 0 0.17 0.00 0.08 0.18 0.00 16.81 82.76 > 2215.63 > 13:37:25 1 0.08 0.00 0.20 0.00 4.08 69.49 26.14 > 23291.34 > > 13:37:25 CPU %user %nice %system %iowait %irq %soft %idle > intr/s > 13:38:24 all 0.14 0.00 0.12 0.12 2.02 42.89 54.71 > 25900.70 > 13:38:24 0 0.03 0.00 0.05 0.22 0.00 16.67 83.03 > 2246.10 > 13:38:24 1 0.25 0.00 0.20 0.03 4.02 69.12 26.40 > 23654.55 > > Any insights as to why there would be such a stark difference in performance > between V2.6 and V2.4? How many flows are going through the router? The neighbour cache can get to be a bottleneck. Perhaps Robert "the Router Man" Olssen can give some hints. From jeremy.guthrie@berbee.com Mon Jan 3 14:48:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 14:48:56 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03MmSK6029275 for ; Mon, 3 Jan 2005 14:48:48 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Jan 2005 16:56:57 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Mon, 3 Jan 2005 16:56:53 -0600 User-Agent: KMail/1.7.2 Cc: Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <20050103145115.4bdb2cd6@dxpl.pdx.osdl.net> In-Reply-To: <20050103145115.4bdb2cd6@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2723897.nnnOR6FQuA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501031656.57041.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 03 Jan 2005 22:56:58.0001 (UTC) FILETIME=[87208010:01C4F1E7] X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart2723897.nnnOR6FQuA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline How would I check? It should be in the hundreds of thousands. On Monday 03 January 2005 04:51 pm, Stephen Hemminger wrote: > On Mon, 3 Jan 2005 14:55:24 -0600 > > "Jeremy M. Guthrie" wrote: > > Any insights as to why there would be such a stark difference in > > performance between V2.6 and V2.4? > > How many flows are going through the router? The neighbour cache > can get to be a bottleneck. Perhaps Robert "the Router Man" Olssen can > give some hints. =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart2723897.nnnOR6FQuA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB2c24qtjaBHGZBeURApfPAJ47JnVz3gwRijJDhfR02fR2zCDrkgCgk+K0 lVInjqbgrTXWPVwsKyMdWzA= =cpIW -----END PGP SIGNATURE----- --nextPart2723897.nnnOR6FQuA-- From hadi@cyberus.ca Mon Jan 3 14:52:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 14:52:32 -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 j03Mq1HF029811 for ; Mon, 3 Jan 2005 14:52:25 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1ClbBi-00038X-GF for netdev@oss.sgi.com; Mon, 03 Jan 2005 18:00:34 -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 1ClTMc-0003tQ-Pk; Mon, 03 Jan 2005 09:39:19 -0500 Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050102001338.GV32419@postel.suug.ch> References: <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.camel@jzny.localdomain> <20041231153930.GN32419@postel.suug.ch> <1104511494.1048.303.camel@jzny.localdomain> <20041231181153.GP32419@postel.suug.ch> <1104526311.1047.379.camel@jzny.localdomain> <20050101183230.GT32419@postel.suug.ch> <1104622934.1047.460.camel@jzny.localdomain> <20050102001338.GV32419@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104763156.1048.531.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 09:39:16 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13361 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 Sat, 2005-01-01 at 19:13, Thomas Graf wrote: > * jamal <1104622934.1047.460.camel@jzny.localdomain> 2005-01-01 18:42 > > what happened to the good old SEL TLV (which i believe we called SEL2 > > now); or maybe thats what contains this TLV? > > Please look at the patch I posted in the other post. I think > we missudnerstand each other. Will do. > > Why do you need to specify "nmatches". > > It's mainly a shortcut to validate precedence jumps so I > can avoid traversing the RTA chain twice. It could be > avoided but is quite handy to speed things up and > also acts for validation purposes to check consistency of > the match list. Ok. > > What is TCA_EMATCH_TREE_LIST for? Looks like another TLV nesting. Not > > needed, you just plumb the T=1,..T=N right after the header. > > No, what if we need some more stuff in the selector TLV? We can't > modify the header TLV w/o breaking backwards compatibility. Adding > this addtional nesting allows to simply add stuff after TREE_LIST > TLV. Good point. > > I think the way you have it is fine - and believe it is the way the > > action code has it for the list. > > You're using a maximum prio aren't you? I use a RTA_OK() loop > supporting unlimited number of matches without the need to > allocate rtattr pointer array. Sounds reasonable; Note in my case, you probably want a limit on how many actions you chain in one policy - I would suggest you do the same as well. In other words even if you do it that way, have a limit check/setting somewhere. cheers, jamal From hadi@cyberus.ca Mon Jan 3 15:43:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 15:43:10 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j03NgcQc032070 for ; Mon, 3 Jan 2005 15:43:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1ClTls-0003Z0-Km for netdev@oss.sgi.com; Mon, 03 Jan 2005 10:05:24 -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 1ClTlh-0007IC-EU; Mon, 03 Jan 2005 10:05:13 -0500 Subject: Re: [patch 4/10] s390: network driver. From: jamal Reply-To: hadi@cyberus.ca To: Thomas Spatzier Cc: "David S. Miller" , Hasso Tepper , Herbert Xu , Jeff Garzik , netdev@oss.sgi.com, Paul Jakma , Tommy Christensen In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1104764710.1048.580.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 10:05:10 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13362 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 The change is simple if theres consensus to go this path. cheers, jamal On Mon, 2005-01-03 at 04:10, Thomas Spatzier wrote: > > > jamal wrote on 22.12.2004 14:48:28: > > I think this needs to be resolved too. > > It is possible to have a centralized action instead of requiring drivers > > to make changes if we know the state of the driver is in netcarrier_off. > > What that would require is > > on cable gone, you just say: > > netif_carrier_off(); > > and the top layer code will junk the packets before they hit the driver. > > This way the socket code can continue sending whatever it wants but if > > theres no link, then its fair to drop those packets? > > > > If this acceptable i can generate a quick patch. > > Does Jamal's solution sound good for all? Then I would change my driver > to do the following: > just call netif_carrier_off() (not netif_stop_queue) > > Then the upper layers will do the propper thing, so I should not > get any more packets. If I still get some, I will drop them. > Did I get this correctly? > > BTW: A happy new year to all ;-) > > Regards, > Thomas. > > From bunk@stusta.de Mon Jan 3 15:43:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 15:43:32 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j03Nh02M032080 for ; Mon, 3 Jan 2005 15:43:25 -0800 Received: (qmail 17606 invoked from network); 3 Jan 2005 23:51:29 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 3 Jan 2005 23:51:29 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 2974BBC0A4; Tue, 4 Jan 2005 00:51:28 +0100 (CET) Date: Tue, 4 Jan 2005 00:51:27 +0100 From: Adrian Bunk To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/core/: misc possible cleanups Message-ID: <20050103235127.GQ2980@stusta.de> References: <20041214045758.GA23151@stusta.de> <20041227190249.6afda3df.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041227190249.6afda3df.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Mon, Dec 27, 2004 at 07:02:49PM -0800, David S. Miller wrote: > On Tue, 14 Dec 2004 05:57:58 +0100 > Adrian Bunk wrote: > > > - skbuff.c: skb_insert > > - skbuff.c: skb_iter_first > > - skbuff.c: skb_iter_next > > - skbuff.c: skb_iter_abort > > These are actually planned to be used, let's keep them in for > now. OK, updated patch: <-- snip --> The patch below contains the following cleanups: - make needlessly global code static - remove the following unused global functions: - datagram.c: skb_copy_datagram - iovec.c: memcpy_tokerneliovec - remove the following unneeded EXPORT_SYMBOL's: - datagram.c: skb_copy_datagram - dev.c: ing_filter - iovec.c: memcpy_tokerneliovec - netpoll.c: netpoll_send_skb - rtnetlink.c: rtnetlink_dump_ifinfo - sock.c: sock_alloc_send_pskb diffstat output: include/linux/netdevice.h | 1 - include/linux/netfilter.h | 4 ---- include/linux/netpoll.h | 1 - include/linux/rtnetlink.h | 1 - include/linux/skbuff.h | 5 ----- include/linux/socket.h | 1 - include/net/iw_handler.h | 3 --- include/net/pkt_cls.h | 1 - include/net/sock.h | 7 ------- net/core/datagram.c | 19 +++---------------- net/core/dev.c | 13 ++++--------- net/core/dst.c | 2 +- net/core/iovec.c | 23 ----------------------- net/core/netfilter.c | 2 +- net/core/netpoll.c | 5 ++--- net/core/rtnetlink.c | 3 +-- net/core/sock.c | 17 +++++++++-------- net/core/wireless.c | 3 +-- 18 files changed, 22 insertions(+), 89 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.10-rc3-mm1-full/include/linux/skbuff.h.old 2004-12-14 02:34:03.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/linux/skbuff.h 2004-12-14 02:51:27.000000000 +0100 @@ -1086,14 +1085,9 @@ int noblock, int *err); extern unsigned int datagram_poll(struct file *file, struct socket *sock, struct poll_table_struct *wait); -extern int skb_copy_datagram(const struct sk_buff *from, - int offset, char __user *to, int size); extern int skb_copy_datagram_iovec(const struct sk_buff *from, int offset, struct iovec *to, int size); -extern int skb_copy_and_csum_datagram(const struct sk_buff *skb, - int offset, u8 __user *to, - int len, unsigned int *csump); extern int skb_copy_and_csum_datagram_iovec(const struct sk_buff *skb, int hlen, --- linux-2.6.10-rc3-mm1-full/include/net/pkt_cls.h.old 2004-12-14 02:37:09.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/net/pkt_cls.h 2004-12-14 02:37:15.000000000 +0100 @@ -17,7 +17,6 @@ extern int register_tcf_proto_ops(struct tcf_proto_ops *ops); extern int unregister_tcf_proto_ops(struct tcf_proto_ops *ops); -extern int ing_filter(struct sk_buff *skb); static inline unsigned long __cls_set_class(unsigned long *clp, unsigned long cl) --- linux-2.6.10-rc3-mm1-full/include/linux/netdevice.h.old 2004-12-14 02:38:05.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/linux/netdevice.h 2004-12-14 02:38:11.000000000 +0100 @@ -522,7 +522,6 @@ extern struct net_device *dev_base; /* All devices */ extern rwlock_t dev_base_lock; /* Device list lock */ -extern int netdev_boot_setup_add(char *name, struct ifmap *map); extern int netdev_boot_setup_check(struct net_device *dev); extern unsigned long netdev_boot_base(const char *prefix, int unit); extern struct net_device *dev_getbyhwaddr(unsigned short type, char *hwaddr); --- linux-2.6.10-rc3-mm1-full/include/linux/socket.h.old 2004-12-14 02:39:18.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/linux/socket.h 2004-12-14 02:39:24.000000000 +0100 @@ -286,7 +286,6 @@ extern int verify_iovec(struct msghdr *m, struct iovec *iov, char *address, int mode); extern int memcpy_toiovec(struct iovec *v, unsigned char *kdata, int len); -extern void memcpy_tokerneliovec(struct iovec *iov, unsigned char *kdata, int len); extern int move_addr_to_user(void *kaddr, int klen, void __user *uaddr, int __user *ulen); extern int move_addr_to_kernel(void __user *uaddr, int ulen, void *kaddr); extern int put_cmsg(struct msghdr*, int level, int type, int len, void *data); --- linux-2.6.10-rc3-mm1-full/include/linux/netfilter.h.old 2004-12-14 02:41:28.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/linux/netfilter.h 2004-12-14 02:41:37.000000000 +0100 @@ -175,10 +175,6 @@ extern void (*ip_ct_attach)(struct sk_buff *, struct sk_buff *); extern void nf_ct_attach(struct sk_buff *, struct sk_buff *); -#ifdef CONFIG_NETFILTER_DEBUG -extern void nf_dump_skb(int pf, struct sk_buff *skb); -#endif - /* FIXME: Before cache is ever used, this must be implemented for real. */ extern void nf_invalidate_cache(int pf); --- linux-2.6.10-rc3-mm1-full/net/core/datagram.c.old 2004-12-14 04:22:37.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/datagram.c 2004-12-14 02:35:34.000000000 +0100 @@ -199,19 +199,6 @@ kfree_skb(skb); } -/* - * Copy a datagram to a linear buffer. - */ -int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to, int size) -{ - struct iovec iov = { - .iov_base = to, - .iov_len =size, - }; - - return skb_copy_datagram_iovec(skb, offset, &iov, size); -} - /** * skb_copy_datagram_iovec - Copy a datagram to an iovec. * @skb - buffer to copy @@ -296,8 +283,9 @@ return -EFAULT; } -int skb_copy_and_csum_datagram(const struct sk_buff *skb, int offset, - u8 __user *to, int len, unsigned int *csump) +static int skb_copy_and_csum_datagram(const struct sk_buff *skb, int offset, + u8 __user *to, int len, + unsigned int *csump) { int start = skb_headlen(skb); int pos = 0; @@ -489,7 +477,6 @@ EXPORT_SYMBOL(datagram_poll); EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec); -EXPORT_SYMBOL(skb_copy_datagram); EXPORT_SYMBOL(skb_copy_datagram_iovec); EXPORT_SYMBOL(skb_free_datagram); EXPORT_SYMBOL(skb_recv_datagram); --- linux-2.6.10-rc3-mm1-full/net/core/dev.c.old 2004-12-14 02:36:09.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/dev.c 2004-12-14 02:38:19.000000000 +0100 @@ -183,7 +183,7 @@ * semaphore held. */ struct net_device *dev_base; -struct net_device **dev_tail = &dev_base; +static struct net_device **dev_tail = &dev_base; rwlock_t dev_base_lock = RW_LOCK_UNLOCKED; EXPORT_SYMBOL(dev_base); @@ -361,7 +361,7 @@ * returns 0 on error and 1 on success. This is a generic routine to * all netdevices. */ -int netdev_boot_setup_add(char *name, struct ifmap *map) +static int netdev_boot_setup_add(char *name, struct ifmap *map) { struct netdev_boot_setup *s; int i; @@ -644,7 +644,7 @@ * Network device names need to be valid file names to * to allow sysfs to work */ -int dev_valid_name(const char *name) +static int dev_valid_name(const char *name) { return !(*name == '\0' || !strcmp(name, ".") @@ -1596,7 +1596,7 @@ * the ingress scheduler, you just cant add policies on ingress. * */ -int ing_filter(struct sk_buff *skb) +static int ing_filter(struct sk_buff *skb) { struct Qdisc *q; struct net_device *dev = skb->dev; @@ -3251,9 +3251,4 @@ EXPORT_SYMBOL(dev_load); #endif -#ifdef CONFIG_NET_CLS_ACT -EXPORT_SYMBOL(ing_filter); -#endif - - EXPORT_PER_CPU_SYMBOL(softnet_data); --- linux-2.6.10-rc3-mm1-full/net/core/dst.c.old 2004-12-14 02:38:35.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/dst.c 2004-12-14 02:38:45.000000000 +0100 @@ -264,7 +264,7 @@ return NOTIFY_DONE; } -struct notifier_block dst_dev_notifier = { +static struct notifier_block dst_dev_notifier = { .notifier_call = dst_dev_event, }; --- linux-2.6.10-rc3-mm1-full/net/core/iovec.c.old 2004-12-14 02:39:30.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/iovec.c 2004-12-14 02:39:52.000000000 +0100 @@ -99,28 +99,6 @@ } /* - * In kernel copy to iovec. Returns -EFAULT on error. - * - * Note: this modifies the original iovec. - */ - -void memcpy_tokerneliovec(struct iovec *iov, unsigned char *kdata, int len) -{ - while (len > 0) { - if (iov->iov_len) { - int copy = min_t(unsigned int, iov->iov_len, len); - memcpy(iov->iov_base, kdata, copy); - kdata += copy; - len -= copy; - iov->iov_len -= copy; - iov->iov_base += copy; - } - iov++; - } -} - - -/* * Copy iovec to kernel. Returns -EFAULT on error. * * Note: this modifies the original iovec. @@ -259,4 +237,3 @@ EXPORT_SYMBOL(memcpy_fromiovec); EXPORT_SYMBOL(memcpy_fromiovecend); EXPORT_SYMBOL(memcpy_toiovec); -EXPORT_SYMBOL(memcpy_tokerneliovec); --- linux-2.6.10-rc3-mm1-full/net/core/netfilter.c.old 2004-12-14 02:41:44.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/netfilter.c 2004-12-14 02:41:52.000000000 +0100 @@ -173,7 +173,7 @@ printk("\n"); } -void nf_dump_skb(int pf, struct sk_buff *skb) +static void nf_dump_skb(int pf, struct sk_buff *skb) { printk("skb: pf=%i %s dev=%s len=%u\n", pf, --- linux-2.6.10-rc3-mm1-full/include/linux/netpoll.h.old 2004-12-14 02:43:42.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/linux/netpoll.h 2004-12-14 02:43:47.000000000 +0100 @@ -24,7 +24,6 @@ }; void netpoll_poll(struct netpoll *np); -void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb); void netpoll_send_udp(struct netpoll *np, const char *msg, int len); int netpoll_parse_options(struct netpoll *np, char *opt); int netpoll_setup(struct netpoll *np); --- linux-2.6.10-rc3-mm1-full/net/core/netpoll.c.old 2004-12-14 02:43:06.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/netpoll.c 2004-12-14 02:43:59.000000000 +0100 @@ -39,7 +39,7 @@ static LIST_HEAD(rx_list); static atomic_t trapped; -spinlock_t netpoll_poll_lock = SPIN_LOCK_UNLOCKED; +static spinlock_t netpoll_poll_lock = SPIN_LOCK_UNLOCKED; #define NETPOLL_RX_ENABLED 1 #define NETPOLL_RX_DROP 2 @@ -178,7 +178,7 @@ return skb; } -void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb) +static void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb) { int status; @@ -676,6 +676,5 @@ EXPORT_SYMBOL(netpoll_parse_options); EXPORT_SYMBOL(netpoll_setup); EXPORT_SYMBOL(netpoll_cleanup); -EXPORT_SYMBOL(netpoll_send_skb); EXPORT_SYMBOL(netpoll_send_udp); EXPORT_SYMBOL(netpoll_poll); --- linux-2.6.10-rc3-mm1-full/include/linux/rtnetlink.h.old 2004-12-14 02:44:36.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/linux/rtnetlink.h 2004-12-14 02:44:52.000000000 +0100 @@ -765,7 +765,6 @@ }; extern struct rtnetlink_link * rtnetlink_links[NPROTO]; -extern int rtnetlink_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb); extern int rtnetlink_send(struct sk_buff *skb, u32 pid, u32 group, int echo); extern int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics); --- linux-2.6.10-rc3-mm1-full/net/core/rtnetlink.c.old 2004-12-14 02:45:12.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/rtnetlink.c 2004-12-14 02:45:26.000000000 +0100 @@ -241,7 +241,7 @@ return -1; } -int rtnetlink_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) +static int rtnetlink_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) { int idx; int s_idx = cb->args[0]; @@ -676,7 +676,6 @@ EXPORT_SYMBOL(__rta_fill); EXPORT_SYMBOL(rtattr_parse); -EXPORT_SYMBOL(rtnetlink_dump_ifinfo); EXPORT_SYMBOL(rtnetlink_links); EXPORT_SYMBOL(rtnetlink_put_metrics); EXPORT_SYMBOL(rtnl); --- linux-2.6.10-rc3-mm1-full/include/net/sock.h.old 2004-12-14 02:56:46.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/net/sock.h 2004-12-14 02:53:27.000000000 +0100 @@ -733,11 +733,6 @@ unsigned long size, int noblock, int *errcode); -extern struct sk_buff *sock_alloc_send_pskb(struct sock *sk, - unsigned long header_len, - unsigned long data_len, - int noblock, - int *errcode); extern void *sock_kmalloc(struct sock *sk, int size, int priority); extern void sock_kfree_s(struct sock *sk, void *mem, int size); extern void sk_send_sigurg(struct sock *sk); @@ -795,8 +790,6 @@ * Default socket callbacks and setup code */ -extern void sock_def_destruct(struct sock *); - /* Initialise core socket variables */ extern void sock_init_data(struct socket *sock, struct sock *sk); --- linux-2.6.10-rc3-mm1-full/net/core/sock.c.old 2004-12-14 02:52:27.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/sock.c 2004-12-14 03:12:56.000000000 +0100 @@ -825,8 +825,10 @@ * Generic send/receive buffer handlers */ -struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len, - unsigned long data_len, int noblock, int *errcode) +static struct sk_buff *sock_alloc_send_pskb(struct sock *sk, + unsigned long header_len, + unsigned long data_len, + int noblock, int *errcode) { struct sk_buff *skb; unsigned int gfp_mask; @@ -1084,7 +1086,7 @@ * Default Socket Callbacks */ -void sock_def_wakeup(struct sock *sk) +static void sock_def_wakeup(struct sock *sk) { read_lock(&sk->sk_callback_lock); if (sk->sk_sleep && waitqueue_active(sk->sk_sleep)) @@ -1092,7 +1094,7 @@ read_unlock(&sk->sk_callback_lock); } -void sock_def_error_report(struct sock *sk) +static void sock_def_error_report(struct sock *sk) { read_lock(&sk->sk_callback_lock); if (sk->sk_sleep && waitqueue_active(sk->sk_sleep)) @@ -1101,7 +1103,7 @@ read_unlock(&sk->sk_callback_lock); } -void sock_def_readable(struct sock *sk, int len) +static void sock_def_readable(struct sock *sk, int len) { read_lock(&sk->sk_callback_lock); if (sk->sk_sleep && waitqueue_active(sk->sk_sleep)) @@ -1110,7 +1112,7 @@ read_unlock(&sk->sk_callback_lock); } -void sock_def_write_space(struct sock *sk) +static void sock_def_write_space(struct sock *sk) { read_lock(&sk->sk_callback_lock); @@ -1129,7 +1131,7 @@ read_unlock(&sk->sk_callback_lock); } -void sock_def_destruct(struct sock *sk) +static void sock_def_destruct(struct sock *sk) { if (sk->sk_protinfo) kfree(sk->sk_protinfo); @@ -1368,7 +1370,6 @@ EXPORT_SYMBOL(sk_alloc); EXPORT_SYMBOL(sk_free); EXPORT_SYMBOL(sk_send_sigurg); -EXPORT_SYMBOL(sock_alloc_send_pskb); EXPORT_SYMBOL(sock_alloc_send_skb); EXPORT_SYMBOL(sock_init_data); EXPORT_SYMBOL(sock_kfree_s); --- linux-2.6.10-rc3-mm1-full/include/net/iw_handler.h.old 2004-12-14 02:54:50.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/include/net/iw_handler.h 2004-12-14 02:54:57.000000000 +0100 @@ -418,9 +418,6 @@ * Those may be called only within the kernel. */ -/* Data needed by fs/compat_ioctl.c for 32->64 bit conversion */ -extern const char iw_priv_type_size[]; - /* First : function strictly used inside the kernel */ /* Handle /proc/net/wireless, called in net/code/dev.c */ --- linux-2.6.10-rc3-mm1-full/net/core/wireless.c.old 2004-12-14 02:55:04.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/net/core/wireless.c 2004-12-14 02:55:12.000000000 +0100 @@ -304,7 +304,7 @@ sizeof(struct iw_ioctl_description)); /* Size (in bytes) of the various private data types */ -const char iw_priv_type_size[] = { +static const char iw_priv_type_size[] = { 0, /* IW_PRIV_TYPE_NONE */ 1, /* IW_PRIV_TYPE_BYTE */ 1, /* IW_PRIV_TYPE_CHAR */ From akepner@sgi.com Mon Jan 3 17:36:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 17:36:55 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j041aT1r006947 for ; Mon, 3 Jan 2005 17:36:49 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j041j3xT019715 for ; Mon, 3 Jan 2005 19:45:03 -0600 From: akepner@sgi.com Received: from [192.168.2.3] (mtv-vpn-sw-corp-0-142.corp.sgi.com [134.15.0.142]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j041j1Fx4730500; Mon, 3 Jan 2005 17:45:02 -0800 (PST) Date: Mon, 3 Jan 2005 17:45:01 -0800 (PST) X-X-Sender: To: , cc: Subject: [PATCH bk-2.6.10] tg3:align IP headers from 5701 in PCI-X mode Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev We still have customers using 5701 cards, and their syslogs fill with "kernel unaligned access" messages. They may also see a significant performance degradation due to the expense of unaligned accesses on ia64. Here's a patch to address this (it is almost the same as the patch which was discussed in http://marc.theaimsgroup.com/?l=linux-netdev&m=109770128816605&w=2). In a quick throughput test, I found that this could improve throughput by ~30% on an Altix. diffstats: drivers/net/Kconfig | 13 +++++++++++++ drivers/net/tg3.c | 8 +++++++- 2 files changed, 20 insertions(+), 1 deletion(-) Signed-off-by: Arthur Kepner ===== drivers/net/Kconfig 1.97 vs edited ===== --- 1.97/drivers/net/Kconfig 2004-12-27 01:29:18 -08:00 +++ edited/drivers/net/Kconfig 2005-01-03 17:12:26 -08:00 @@ -2089,6 +2089,19 @@ config TIGON3 To compile this driver as a module, choose M here: the module will be called tg3. This is recommended. +config 5701_PCIX_IP_ALIGN + bool "align IP headers from 5701 cards in the driver (in PCI-X mode)" + depends on TIGON3 + help + IP headers from 5701 cards (in PCI-X mode only) are not aligned as + the TCP/IP stack expects. On some architectures (including ia64) + unaligned accesses are particularly expensive, and the performance + of 5701 cards in PCI-X mode suffers. Configuring 5701_PCIX_IP_ALIGN + causes the driver to copy packets so that the IP headers are + aligned. 5701_PCIX_IP_ALIGN only affects operation of the TIGON3 driver + when used with a 5701 card in PCI-X mode - other cards are unaffected + by this option. + config GIANFAR tristate "Gianfar Ethernet" depends on 85xx ===== drivers/net/tg3.c 1.222 vs edited ===== --- 1.222/drivers/net/tg3.c 2004-11-15 15:53:08 -08:00 +++ edited/drivers/net/tg3.c 2005-01-03 17:25:09 -08:00 @@ -2702,7 +2702,13 @@ static int tg3_rx(struct tg3 *tp, int bu len = ((desc->idx_len & RXD_LEN_MASK) >> RXD_LEN_SHIFT) - 4; /* omit crc */ - if (len > RX_COPY_THRESHOLD) { + if (len > RX_COPY_THRESHOLD +#ifdef CONFIG_5701_PCIX_IP_ALIGN + && tp->rx_offset == 2 + /* rx_offset != 2 iff this is a 5701 card running + * in PCI-X mode [see tg3_get_invariants()] */ +#endif + ) { int skb_size; skb_size = tg3_alloc_rx_skb(tp, opaque_key, -- Arthur From y030729@njupt.edu.cn Mon Jan 3 18:13:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 18:13:46 -0800 (PST) Received: from njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j042DHah008208 for ; Mon, 3 Jan 2005 18:13:38 -0800 Received: (eyou send program); Tue, 04 Jan 2005 11:15:37 +0800 Message-ID: <304808537.11599@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Tue, 04 Jan 2005 11:15:37 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: netdev@oss.sgi.com Cc: lartc@mailman.ds9a.nl Date: Tue, 04 Jan 2005 11:15:37 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: Scheduler Mechnisms! Content-Type: text/plain X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: y030729@njupt.edu.cn Precedence: bulk X-list: netdev Hello, Normally, in addition to such qdisc scheduler mechanisms as FIFO, PQ, WRR, WFQ, are there any more? Then, there is a confusion on scheduler in Linux enviroment: Assume there is a qdisc, such as RED as a leaf qdisc in a router, we know, if there is packet which want to enqueue the packet, the Function red_enqueue is called, but when the packet leave the queue(when the Function red_dequeue is called)? I think it is meaningless when the pack leaves the queue just it enterred it. Is there anything need to be done betweent the packet's enqueue and dequeue? Best, From akpm@osdl.org Mon Jan 3 19:10:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 19:10:45 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j043AFCU010514 for ; Mon, 3 Jan 2005 19:10:35 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j043Ii617056 for ; Mon, 3 Jan 2005 19:18:44 -0800 Date: Mon, 3 Jan 2005 19:18:36 -0800 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: b44 ifconfig fails with ENOMEM Message-Id: <20050103191836.57f918e5.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__3_Jan_2005_19_18_36_-0800_WFmoBQgWAKAe8uBv" X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --Multipart=_Mon__3_Jan_2005_19_18_36_-0800_WFmoBQgWAKAe8uBv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit b44 requires an order-8 allocation? Good luck... Begin forwarded message: Date: Wed, 29 Dec 2004 05:57:28 +0100 From: Stefan Knoblich To: linux-kernel@vger.kernel.org Cc: pp@ee.oulu.fi Subject: b44 ifconfig fails with ENOMEM Hi, ifconfig eth0 192.168.1.2 up returns the following error message: laptop ~ # ifconfig eth0 192.168.1.2 up SIOCSIFFLAGS: Cannot allocate memory SIOCSIFFLAGS: Cannot allocate memory output of dmesg: ifconfig: page allocation failure. order:8, mode:0x21 [] __alloc_pages+0x1d2/0x3a0 [] __get_free_pages+0x1f/0x40 [] dma_alloc_coherent+0xca/0x100 [] b44_alloc_consistent+0xc7/0x1a0 [b44] [] b44_open+0x21/0xd0 [b44] [] schedule+0x2be/0x4e0 [] dev_open+0x85/0xa0 [] dev_change_flags+0x53/0x130 [] devinet_ioctl+0x257/0x5b0 [] inet_ioctl+0x66/0xb0 [] sock_ioctl+0xd9/0x2b0 [] sys_ioctl+0xd5/0x220 [] do_syscall_trace+0x47/0x90 [] syscall_call+0x7/0xb there's plenty of free memory available: laptop ~ # free total used free shared buffers cached Mem: 506320 499728 6592 0 20036 274712 -/+ buffers/cache: 204980 301340 Swap: 987988 3144 984844 unloading and reloading the module didn't help, only a reboot fixed it (after ~36hours uptime) the wlan nic (ipw2100) worked fine (i was abled to ifconfig down and up it again, add an ip alias...) more hardware information: Fujitsu-Siemens Amilo 7400M, Pentium-m 1500MHz, i855GM Chipset 0000:02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) Subsystem: Wistron Corp.: Unknown device 1082 Flags: bus master, fast devsel, latency 64, IRQ 10 Memory at e0200000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 if you need more information, please tell me since it 2.6.9 worked fine, i guess the recent PCI DMA changes in b44.c may cause this problem stefan --Multipart=_Mon__3_Jan_2005_19_18_36_-0800_WFmoBQgWAKAe8uBv Content-Type: text/plain; name="config-2.6.10" Content-Disposition: attachment; filename="config-2.6.10" Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # Linux kernel version: 2.6.10 # Sun Dec 26 20:54:11 2004 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_PROC_INTF=m # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_24_API=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_TABLE=y # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=m # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # # shared options # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_MSI is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set # CONFIG_PCMCIA_OBSOLETE is not set CONFIG_PCMCIA=m CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_PD6729=m CONFIG_I82092=m CONFIG_I82365=m CONFIG_TCIC=m CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set CONFIG_PARPORT_OTHER=y CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set CONFIG_PNPACPI=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set CONFIG_BLK_DEV_UB=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_LBD is not set # CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_NINJA_SCSI is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID5=m CONFIG_MD_RAID6=m CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=y CONFIG_DM_SNAPSHOT=y CONFIG_DM_MIRROR=y CONFIG_DM_ZERO=y # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_OUI_DB=y CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y CONFIG_IEEE1394_CONFIG_ROM_IP1394=y # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y # CONFIG_IP_TCPDIAG_IPV6 is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m CONFIG_IPV6_TUNNEL=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y # CONFIG_IP_NF_CT_ACCT is not set # CONFIG_IP_NF_CONNTRACK_MARK is not set # CONFIG_IP_NF_CT_PROTO_SCTP is not set # CONFIG_IP_NF_FTP is not set # CONFIG_IP_NF_IRC is not set # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_OWNER=y # CONFIG_IP_NF_MATCH_PHYSDEV is not set CONFIG_IP_NF_MATCH_ADDRTYPE=y CONFIG_IP_NF_MATCH_REALM=y # CONFIG_IP_NF_MATCH_SCTP is not set CONFIG_IP_NF_MATCH_COMMENT=y # CONFIG_IP_NF_MATCH_HASHLIMIT is not set CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_TARGET_NETMAP=y CONFIG_IP_NF_TARGET_SAME=y # CONFIG_IP_NF_NAT_LOCAL is not set # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_IP_NF_TARGET_DSCP=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_CLASSIFY=y # CONFIG_IP_NF_RAW is not set CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_QUEUE is not set # CONFIG_IP6_NF_IPTABLES is not set # # Bridge: Netfilter Configuration # # CONFIG_BRIDGE_NF_EBTABLES is not set CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m # CONFIG_CLS_U32_PERF is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m # CONFIG_IRNET is not set CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # # CONFIG_DONGLE is not set # # Old SIR device drivers # CONFIG_IRPORT_SIR=m # # Old Serial dongle support # # CONFIG_DONGLE_OLD is not set # # FIR device drivers # # CONFIG_USB_IRDA is not set CONFIG_SIGMATEL_FIR=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y # CONFIG_BT_HCIUART_BCSP_TXCRC is not set CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBFUSB=m # CONFIG_BT_HCIDTL1 is not set # CONFIG_BT_HCIBT3C is not set # CONFIG_BT_HCIBLUECARD is not set # CONFIG_BT_HCIBTUART is not set CONFIG_BT_HCIVHCI=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set CONFIG_B44=m # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # # Obsolete Wireless cards support (pre-802.11) # # CONFIG_STRIP is not set # CONFIG_ARLAN is not set # CONFIG_WAVELAN is not set # CONFIG_PCMCIA_WAVELAN is not set # CONFIG_PCMCIA_NETWAVE is not set # # Wireless 802.11 Frequency Hopping cards support # # CONFIG_PCMCIA_RAYCS is not set # # Wireless 802.11b ISA/PCI cards support # # CONFIG_AIRO is not set CONFIG_HERMES=m # CONFIG_PLX_HERMES is not set # CONFIG_TMD_HERMES is not set # CONFIG_PCI_HERMES is not set CONFIG_ATMEL=m # CONFIG_PCI_ATMEL is not set # # Wireless 802.11b Pcmcia/Cardbus cards support # # CONFIG_PCMCIA_HERMES is not set # CONFIG_AIRO_CS is not set # CONFIG_PCMCIA_ATMEL is not set # CONFIG_PCMCIA_WL3501 is not set # # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support # CONFIG_PRISM54=m CONFIG_NET_WIRELESS=y # # PCMCIA network device support # # CONFIG_NET_PCMCIA is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set CONFIG_SERIO_PCIPS2=y # CONFIG_SERIO_RAW is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set # CONFIG_SERIAL_8250_CS is not set CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m CONFIG_TIPAR=m # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m CONFIG_AGP_INTEL_MCH=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_ELEKTOR is not set CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_ISA=m # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_FSCHER=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83627HF=m # # Other I2C Chip support # CONFIG_SENSORS_EEPROM=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5246A is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON_OLD is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # ISA devices # # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_DT019X is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VX222 is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_VXP440 is not set # CONFIG_SND_PDAUDIOCF is not set # # Open Sound System # CONFIG_SOUND_PRIME=m # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set CONFIG_SOUND_ICH=m # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_AD1980 is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # # CONFIG_USB_MIDI is not set CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_RW_DETECT=y # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set CONFIG_USB_VICAM=m # CONFIG_USB_DSBR is not set CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m # CONFIG_USB_SN9C102 is not set CONFIG_USB_STV680=m # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_TEST is not set # # USB ATM/DSL drivers # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set CONFIG_MMC_BLOCK=m CONFIG_MMC_WBSD=m # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y CONFIG_MINIX_FS=m # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=852 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-15" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y CONFIG_TMPFS_XATTR=y CONFIG_TMPFS_SECURITY=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_CRAMFS=m # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=y CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set # CONFIG_FRAME_POINTER is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_KEYS is not set CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=m # CONFIG_SECURITY_ROOTPLUG is not set # CONFIG_SECURITY_SECLVL is not set # CONFIG_SECURITY_SELINUX is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_TEST=m # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y --Multipart=_Mon__3_Jan_2005_19_18_36_-0800_WFmoBQgWAKAe8uBv-- From hadi@cyberus.ca Mon Jan 3 20:05:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 20:05:50 -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 j0445NOu012629 for ; Mon, 3 Jan 2005 20:05:43 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Clg4z-0004k7-Fz for netdev@oss.sgi.com; Mon, 03 Jan 2005 23:13:57 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Clg4w-0002nl-2z; Mon, 03 Jan 2005 23:13:54 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050103125635.GB26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104812028.1085.50.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 23:13:48 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13367 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-03 at 07:56, Thomas Graf wrote: > Jamal et al, > > I attached 4 patches of a first ematch implementation. Comments > and suggestions very much appreciated. Compiles but untested. > > Patch 1: ematch API > > API visible to classifier: > > tcf_em_tree_validate(tp, tlv, tree) > tlv: ematches TLV > tree: temporary struct tcf_ematch_tree > > Validates the data in the TLV and builds the ematch tree > upon the temporary variable. struct tcf_ematch_hdr { __u16 handle; __u16 matchID; __u16 kind; __u8 flags; __u8 pad; /* currently unused */ }; you need both matchID and handle? struct tcf_ematch { struct tcf_ematch_hdr hdr; struct tcf_ematch_ops * ops; unsigned long data; }; Both tcf_ematch_ops and tcf_ematch_hdr have kind; Is data length stored somewhere? Noticed indev still hanging there ;-> shouldnt that die by this patch? > tcf_em_tree_change(tp, dst, src) > dst: destination ematch tree (from classifier private data) > src: source ematch tree (temporary tree from _validate) > > Replaces the ematch tree in the classifier with the temporary > tree. Seems to assume some owner of the ematch other than mother classifier. Recall the idea of ownership by classifier we discussed earlier which should be default if the ematch doesnt implement a ->change() BTW, Is the assumption i can have a u32: match ematch match match ematch now gone? I couldnt tell. > tcf_em_tree_destroy(tp, tree) > Destroys an ematch tree > > tcf_em_tree_dump(skb, tree, tlv_type) > tlv_type: T of ematches TLV (classifier specific) > > Dumps the ematch tree to the skb with given tlv_type. Same comments as in ->change(). if ematch doesnt implement a destroy or dump then mother classifier is responsible. > tcf_em_tree_match(skb, tree, res) > res: struct tcf_result * > > Macro returning 1 if no ematches are configured, otherwise > the tree is evaulated and 1 is returned if the tree matches. I think that looks valid for simplicty case. I wasnt so sure about the INVERT thing you had. It doesnt look like a bad idea, just different from what i had in mind (where you let the ematch worry about inversion). > The complete API is also visible if ematch is not configured but > will result in empty macros/structures. Those need to be > improved though. > > API visible to ematches: > > tcf_em_register(ops) > tcf_em_unregister(ops) > > ematches must at least provide the following callbacks: > > change, match > > Optional callbacks are: destroy, dump > > kind must be set to a unique ID, i thought about declaring > 1..2^16 to ematches within the mainline tree and have the > rest declared as to be used for private use to avoid collisions. With std actions also this was an issue - at the moment dont have anything in any headers just to make it free for all - This way you could write a simple module that has zero dependency on an already compiled kernel. There would be standard practise where say 11 would mean something - but i suggest not to enforce it; the register() should probably spit some helpful message of who already has the number. you are trying to grab. > Patch 2: u32 ematch > > Is an ematch based on the existing u32 match but allows to > specify the layer and is able to read u32 values if alignment > does not allow direct access. Additionally it supports > the operands, eq, lt, gt. It is a few ticks slower than the > existing match but worth it. However, it does not support > the neat nexthdr via hashing as u32 does which is the main > problem before u32 can make proper use of it. It does emulate a u32 node but not the classifier - which is a _lot_ more sophisticated (with multilevel trees of hashes etc). Maybe you should change its name to something like 32bit match. > Patch 3: nbyte ematch > > Compares n bytes at specified offset. To be used for IPv6 > address matches to avoid 4 ANDed u32 matches. This looks useful. My recommendation would be to have the metamatch as the first thing so we can kill indev and friends. > Patch 4: Basic Classifier > > This is the most basic classifier possible doing nothing more > than executing extensions and ematches. It follows the > architecture of u32 and fw by storing a filter list in tp->root. > This eventually makes fw obsolete once meta ematch is available. > I didn't copy the u32/fw code but rather made use of the list.h. Very inefficient, but serves the purpose of an example. [Even if you go as basic a hash as fw classifier you will do better] > pskbs are completely unhandled so far as I'm still not sure > how to do it properly. Given where we are doing these things (egress and ingress of stack) we would mostly be fine (unlike netfilter). cheers, jamal From hadi@cyberus.ca Mon Jan 3 20:10:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 20:10:22 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0449nhC013152 for ; Mon, 3 Jan 2005 20:10:09 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Clg9K-0007uH-Sz for netdev@oss.sgi.com; Mon, 03 Jan 2005 23:18:26 -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 1Clg9D-0003FZ-SU; Mon, 03 Jan 2005 23:18:20 -0500 Subject: Re: [openib-general] Re: LLTX and netif_stop_queue From: jamal Reply-To: hadi@cyberus.ca To: Grant Grundler Cc: Eric Lemoine , Roland Dreier , netdev@oss.sgi.com, Andi Kleen , openib-general@openib.org, Patrick McHardy , "David S. Miller" In-Reply-To: <20050103171227.GD7370@esmail.cup.hp.com> References: <5cac192f0412230110628749e3@mail.gmail.com> <41CAF444.3000305@trash.net> <5cac192f04122408102129af43@mail.gmail.com> <1104240717.1100.66.camel@jzny.localdomain> <5cac192f0501021530672a908a@mail.gmail.com> <1104764660.1048.578.camel@jzny.localdomain> <52brc68q05.fsf@topspin.com> <5cac192f05010308414a25b548@mail.gmail.com> <527jmu8nbw.fsf@topspin.com> <5cac192f0501030907c755135@mail.gmail.com> <20050103171227.GD7370@esmail.cup.hp.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104812294.1085.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jan 2005 23:18:14 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13368 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-03 at 12:12, Grant Grundler wrote: > Some workloads that Jamal cares about (routing) only need 2 cpus. What bothers me is more the complexity this has introduced more than the workload. OTOH, 1-2% improvement posted by Roland is good justification. cheers, jamal From imipak@yahoo.com Mon Jan 3 21:30:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 21:31:05 -0800 (PST) Received: from web12304.mail.yahoo.com (web12304.mail.yahoo.com [216.136.173.102]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j045Uc51018795 for ; Mon, 3 Jan 2005 21:30:58 -0800 Received: (qmail 37918 invoked by uid 60001); 4 Jan 2005 05:39:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=HtL24ZE50UKSFlqKo/55xDMow4aBa3IVj+1r4RGj+XMFNouOqmizyIpgCCEIIZOnFBf26w4XWOe/IYa+a3vfz3T+zP+JwI8jlIHcPniHVV1VD/4VW+8AnrUont/JmmJz2Qdc0V5CIl0HHAINY5rPD2JJJSDWqM9VZU9rWJ3luhE= ; Message-ID: <20050104053912.37916.qmail@web12304.mail.yahoo.com> Received: from [65.102.7.124] by web12304.mail.yahoo.com via HTTP; Mon, 03 Jan 2005 21:39:12 PST Date: Mon, 3 Jan 2005 21:39:12 -0800 (PST) From: Jonathan Day Subject: Re: [LARTC] Scheduler Mechnisms! To: Zhenyu Wu , netdev@oss.sgi.com Cc: lartc@mailman.ds9a.nl In-Reply-To: <304808537.11599@njupt.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imipak@yahoo.com Precedence: bulk X-list: netdev It depends on what you mean by "more". More for Linux? Certainly. HTB3 seems to be a popular mechanism, and you can use IMQ to set up an intermediate device to allow shaping of both inbound and outbound traffic, using one (or more!) scheduling mechanisms in series. (In fact, there are several versions of IMQ out there. I've given links to both the projects that seem to be alive, but there may be more.) There's also ESFQ, but there doesn't seem to be much active work on that. There are forward ports to recent Linux kernels, though. QLinux has a version of H-SFQ for Linux, but again it seems to be getting long in the tooth. Unfortunately, I can't find any forward ports of that. http://luxik.cdi.cz/~devik/qos/htb/ http://www.linuximq.net/ http://pupa.da.ru/imq/ http://www.digriz.org.uk/jdg-qos-script/#qos-2.6 http://kem.p.lodz.pl/~peter/qnet/ http://lass.cs.umass.edu/software/qlinux/ There are a great many systems that I can't find a Linux version of. Cisco routers support something called "Class-Based Weighted Fair Queueing" (CBWFQ) which seems to be a hybrid of classful and classless scheduling. Cisco also has two versions of ECN, for forwards and backwards propogation. I've listed below a number of papers detailing various QoS schemes. Some of these have been implemented in other OS' (the BSDs tend to get a lot of this stuff implemented quickly for them as part of ALTQ) and some I've never seen an implementation at all. However, the papers should all give enough information to write a version for Linux. Note: ALTQ can be found at: http://www.csl.sony.co.jp/person/kjc/kjc/software.html Please note that this list is not exhaustive. Rather, I got exhausted after trying to find what was out there and what state it was currently in. QoS is a big field, if the number of papers is anything to go by. Linux only touches the fringes of it. If anyone feels particularly bored, or in need of a good ego boost, it would be cool to see if a reasonable selection of these could be introduced into Linux over the 2.7 cycle. EDF (Earliest Deadline First) http://citeseer.ist.psu.edu/13919.html BLUE (an alternative to RED) http://citeseer.ist.psu.edu/feng99blue.html AF PHB (Assured Forwarding Per-Hop Behaviour) http://citeseer.ist.psu.edu/552302.html SFB (Stochastic Fair Blue) http://citeseer.ist.psu.edu/551253.html GREEN (a pro-active variant on the theme of RED) http://citeseer.ist.psu.edu/feng02green.html SMART (Scalable Multipath Aggregated RouTing) http://citeseer.ist.psu.edu/vutukury00smart.html CSFQ (Core Stateless Fair Queueing) http://citeseer.ist.psu.edu/391.html StFQ (Start-Time Fair Queueing) http://citeseer.ist.psu.edu/goyal96starttime.html RFQ (Rainbow Fair Queueing) http://citeseer.ist.psu.edu/cao00rainbow.html PrFQ (Probabalistic Fair Queueing) http://citeseer.ist.psu.edu/anker00prfq.html ERR (Elastic Round Robin) http://citeseer.ist.psu.edu/kanhere02fair.html GFQ (Greedy Fair Queueing) http://citeseer.ist.psu.edu/690207.html PERR (Prioritized Elastic Round Robin) http://citeseer.ist.psu.edu/681127.html AOQ (Anchored Opportunity Queueing) http://citeseer.ist.psu.edu/701742.html BSFQ (Bin Sort Fair Queueing) http://citeseer.ist.psu.edu/622188.html As for the final question on what happens between enqueue and dequeue, there are various diagrams out there which show different aspects of how packets traverse the system. I've included a few links to those I could find: http://open-source.arkoon.net/kernel/kernel_net.png http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html http://www.docum.org/docum.org/kptd/ The last of these is the infamous Kernel Packet Travelling Diagram. Most links to this that I've been able to find are broken. It should be noted that the diagrams all refer to the Linux 2.4 kernel. Linux 2.6 has quite a few QoS changes to it, but I'm unclear as to whether they significantly alter any of the flows. I hope this is of some use. Or, at the very least, is an effective remedy to insomnia. :) Jonathan --- Zhenyu Wu wrote: > Hello, > > Normally, in addition to such qdisc scheduler > mechanisms as FIFO, PQ, WRR, WFQ, > are there any more? Then, there is a confusion on > scheduler in Linux enviroment: > Assume there is a qdisc, such as RED as a leaf qdisc > in a router, we know, if > there is packet which want to enqueue the packet, > the Function red_enqueue is > called, but when the packet leave the queue(when the > Function red_dequeue is > called)? I think it is meaningless when the pack > leaves the queue just it enterred > it. Is there anything need to be done betweent the > packet's enqueue and dequeue? > > Best, > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: > http://lartc.org/ > __________________________________ Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. http://celebrity.mail.yahoo.com From jgarzik@pobox.com Mon Jan 3 22:32:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Jan 2005 22:32:50 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j046WMfE020786 for ; Mon, 3 Jan 2005 22:32:42 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CliNB-0006yA-Iu; Tue, 04 Jan 2005 06:40:53 +0000 Message-ID: <41DA3A60.8050102@pobox.com> Date: Tue, 04 Jan 2005 01:40:32 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: =?UTF-8?B?WU9TSElGVUpJIEhpZGVha2kgLyDlkInol6Toi7HmmI4=?= , Herbert Xu Subject: IPv6 badness continues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev This problem seems to be appearing much sooner, in 2.6.10 and 2.6.10-bk kernels. Herbert, your patch did not apply to recent kernels, so I did not boot with it. The first 'Badness in dst_release' message (of many) from 2.6.10-bk1, on x86 SMP, is found below. Standard FC2 OS with IPv6 6to4 setup as described on http://linux.yyz.us/ipv6-fc2-howto.html Sorry, this is my main fileserver and router, so I need to reboot it... Jeff Badness in dst_release at include/net/dst.h:149 [] ip6_dst_check+0x67/0x80 [ipv6] [] ip6_dst_lookup+0x1b4/0x1d0 [ipv6] [] udpv6_sendmsg+0x2b4/0x950 [ipv6] [] udp_recvmsg+0x64/0x300 [] inet_sendmsg+0x4d/0x60 [] sock_sendmsg+0xdd/0x100 [] find_busiest_group+0xd4/0x300 [] copy_from_user+0x42/0x70 [] autoremove_wake_function+0x0/0x60 [] sys_sendmsg+0x18f/0x1f0 [] __wake_up_common+0x41/0x70 [] __wake_up+0x3e/0x60 [] wake_futex+0x37/0x70 [] futex_wake+0x7b/0xd0 [] copy_from_user+0x42/0x70 [] sys_socketcall+0x242/0x260 From buytenh@wantstofly.org Tue Jan 4 01:25:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 01:25:30 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j049P1DC031170 for ; Tue, 4 Jan 2005 01:25:22 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 33DD12B0EE; Tue, 4 Jan 2005 10:33:35 +0100 (MET) Date: Tue, 4 Jan 2005 10:33:35 +0100 From: Lennert Buytenhek To: Jeff Garzik Cc: Netdev , YOSHIFUJI Hideaki / ???????????? , Herbert Xu Subject: Re: IPv6 badness continues Message-ID: <20050104093335.GB7823@xi.wantstofly.org> References: <41DA3A60.8050102@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DA3A60.8050102@pobox.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Tue, Jan 04, 2005 at 01:40:32AM -0500, Jeff Garzik wrote: > Standard FC2 OS with IPv6 6to4 setup as described on > http://linux.yyz.us/ipv6-fc2-howto.html I upgraded my problematic machine to FC3, which somehow broke 6to4, and I didn't bother to reenable it again because the local DNS server (dnscache) just drops AAAA queries on the floor anyway, leading to lots of timeouts when trying to resolve host names, etc. Ever since 6to4 was turned off on that box I stopped seeing these messages. --L From tgraf@suug.ch Tue Jan 4 03:55:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 03:55:10 -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 j04Bsetq006588 for ; Tue, 4 Jan 2005 03:55:01 -0800 Received: from postel.suug.ch (unknown [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 337BF82; Tue, 4 Jan 2005 13:02:52 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id A24611C0EA; Tue, 4 Jan 2005 13:03:33 +0100 (CET) Date: Tue, 4 Jan 2005 13:03:33 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050104120333.GF26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104812028.1085.50.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13372 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 * jamal <1104812028.1085.50.camel@jzny.localdomain> 2005-01-03 23:13 > struct tcf_ematch_hdr > { > __u16 handle; > __u16 matchID; > __u16 kind; > __u8 flags; > __u8 pad; /* currently unused */ > }; > > you need both matchID and handle? No, handle is yet unused and I think we can screw it again. > Both tcf_ematch_ops and tcf_ematch_hdr have kind; Correct, I wanted to avoid having to do transformations but it would save us a few bits. > Is data length stored somewhere? Not in this patch as it wasn't needed, I added it to my local tree yesterday though. It is indeed required if we allocate in the ematch api instead of having the ematch doing it. > Noticed indev still hanging there ;-> shouldnt that die by this patch? As soon as I find the time to write the meta ematch. > > tcf_em_tree_change(tp, dst, src) > > dst: destination ematch tree (from classifier private data) > > src: source ematch tree (temporary tree from _validate) > > > > Replaces the ematch tree in the classifier with the temporary > > tree. > > Seems to assume some owner of the ematch other than mother classifier. > Recall the idea of ownership by classifier we discussed earlier > which should be default if the ematch doesnt implement a ->change() The classifier must always be the owner. Splitting the vaildation and changing into 2 separate functions makes it easy for the classifier to stay consistent while changing without doing expensive error recovery. > BTW, Is the assumption i can have a u32: > match > ematch > match > match > ematch > > now gone? I couldnt tell. I can't tell you either but not really. It's still possible but I'm not sure if it makes sense. My idea was to replace match with ematch so it would benefit from logic relations. The problem arises when we get to the nexthdr offset mangling. I have to look into this but I might have to drop my idea and do as you state above. > > tcf_em_tree_destroy(tp, tree) > > Destroys an ematch tree > > > > tcf_em_tree_dump(skb, tree, tlv_type) > > tlv_type: T of ematches TLV (classifier specific) > > > > Dumps the ematch tree to the skb with given tlv_type. > > Same comments as in ->change(). > if ematch doesnt implement a destroy or dump then mother classifier is > responsible. Right, I changed this already. change/dump/destroy are fully optional. Here's the latest API to the classifier: change() (Optional) Called if provided, otherwise ematch api allocates the data, stores it in m->data and sets m->datalen. Special Case: If TCF_EM_SIMPLE is set the ematch data consists of a simple u32 which means no allocation is required and the value is stored in m->data directly. Note: I might add a special field to ematch_ops which can be set to the expected length of the ematch data so we have at least some basic sanity check. Thoughts? match() (Must) ... destroy() (Optional) Called if provided, otheriwse m->data is freed in ematch api unless TCF_EM_SIMPLE is set. dump() (Optional) Called if provided, otherwise m->data is dumped onto the skb with m->datalen as L. Special handling again for TCF_EM_SIMPLE. I think this makes it as simple as it can get while keeping the door open for complex ematches such as meta ematch. > With std actions also this was an issue - at the moment dont have > anything in any headers just to make it free for all - This way you > could write a simple module that has zero dependency on an already > compiled kernel. There would be standard practise where say 11 would > mean something - but i suggest not to enforce it; the register() > should probably spit some helpful message of who already has the number. > you are trying to grab. The warning is a good idea. I don't want to enforce it, a comment is just fine and it's up to you whehter you want to fix your ematch everyime a new ematch makes it into the kernel. I added this comment: /* Ematch type assignments * 1..32767 Reserved for ematches inside kernel tree * 32768..65535 Free to use, not reliable */ > > Patch 2: u32 ematch > > It does emulate a u32 node but not the classifier - which is a _lot_ > more sophisticated (with multilevel trees of hashes etc). Maybe you > should change its name to something like 32bit match. Agreed. Note: With the latest API everything except for match can be screwed. Same for em_nbyte. > > Patch 3: nbyte ematch > > > > Compares n bytes at specified offset. To be used for IPv6 > > address matches to avoid 4 ANDed u32 matches. > > This looks useful. > My recommendation would be to have the metamatch as the first thing > so we can kill indev and friends. Right, but those were easy to write in in interruptive working enviroment and somewhat validated the API. meta ematch will take some time to write but it sure has top priority. > > Patch 4: Basic Classifier > > Very inefficient, but serves the purpose of an example. > [Even if you go as basic a hash as fw classifier you will do better] Fully agreed, nevertheless I think something like this is required to fill the gaps of u32 and fw. From tgraf@suug.ch Tue Jan 4 04:19:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 04:19:11 -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 j04CIh53008256 for ; Tue, 4 Jan 2005 04:19:04 -0800 Received: from postel.suug.ch (unknown [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 BA15C82; Tue, 4 Jan 2005 13:26:55 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id CDA701C0EA; Tue, 4 Jan 2005 13:27:38 +0100 (CET) Date: Tue, 4 Jan 2005 13:27:38 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050104122738.GG26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104812028.1085.50.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13373 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 * jamal <1104812028.1085.50.camel@jzny.localdomain> 2005-01-03 23:13 > On Mon, 2005-01-03 at 07:56, Thomas Graf wrote: > > Patch 4: Basic Classifier > > Very inefficient, but serves the purpose of an example. > [Even if you go as basic a hash as fw classifier you will do better] Might be worth to mention the motivation for this. fw and u32 will definitely perform much better on complex setups but many do not use u32 hashing not to mention even understand it or have large nfmark -> classid fw maps. Many use u32 to match simple stuff as port numbers, dscp values or ip subnet addresses and create a new filter for every port/dscp value and for every address. Some even use temporary classes to emulate logic relations and this gets really slow. I have to get numbers first but a single basic filter with ORed matches is probably faster than a separate u32 filter for every case. Sure, once u32 has ematch support it gets better and the hashing shouldn't have too much influence even if it's unused.. We can see what to do once u32 can handle ematches. From hadi@cyberus.ca Tue Jan 4 05:11:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 05:11:16 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04DAnA1013418 for ; Tue, 4 Jan 2005 05:11:09 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Cloal-00033k-87 for netdev@oss.sgi.com; Tue, 04 Jan 2005 08:19:19 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cloai-0002Ey-VF; Tue, 04 Jan 2005 08:19:17 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050104120333.GF26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104120333.GF26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104844753.1085.99.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Jan 2005 08:19:13 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13374 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-01-04 at 07:03, Thomas Graf wrote: > * jamal <1104812028.1085.50.camel@jzny.localdomain> 2005-01-03 23:13 > Right, I changed this already. change/dump/destroy are fully > optional. Here's the latest API to the classifier: > > change() (Optional) > Called if provided, otherwise ematch api allocates the data, stores > it in m->data and sets m->datalen. Special Case: If TCF_EM_SIMPLE > is set the ematch data consists of a simple u32 which means no > allocation is required and the value is stored in m->data directly. > > Note: I might add a special field to ematch_ops which can be set to > the expected length of the ematch data so we have at least some basic > sanity check. Thoughts? My thinking is: It doesnt have to be simple 32 bit data. If i pass you a struct and tell you what length it is, then you as the classifier dont know need to know anything about it. You just store mystruct as data and datalen from the TLV. you then pass the datastruct to match() - Of course the match() will have to know what that struct means. > match() (Must) > ... > > destroy() (Optional) > Called if provided, otheriwse m->data is freed in ematch api unless > TCF_EM_SIMPLE is set. Again using the above logic, destroy becomes just kfree(mystruct) > dump() (Optional) > Called if provided, otherwise m->data is dumped onto the skb with > m->datalen as L. Special handling again for TCF_EM_SIMPLE. and dump becomes a matter of looking at datalen and encapsulating mystruct in a TLV without thinking about what the content is. > I think this makes it as simple as it can get while keeping the door > open for complex ematches such as meta ematch. Agreed. > > > Patch 4: Basic Classifier > > > > Very inefficient, but serves the purpose of an example. > > [Even if you go as basic a hash as fw classifier you will do better] > > Fully agreed, nevertheless I think something like this is > required to fill the gaps of u32 and fw. agreed. cheers, jamal From hadi@cyberus.ca Tue Jan 4 05:14:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 05:14:14 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04DDljL013816 for ; Tue, 4 Jan 2005 05:14:07 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Clodf-0004hI-R8 for netdev@oss.sgi.com; Tue, 04 Jan 2005 08:22:19 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Clode-0002YX-EY; Tue, 04 Jan 2005 08:22:18 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050104122738.GG26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104122738.GG26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104844935.1085.103.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Jan 2005 08:22:15 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13375 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-01-04 at 07:27, Thomas Graf wrote: > * jamal <1104812028.1085.50.camel@jzny.localdomain> 2005-01-03 23:13 > > Very inefficient, but serves the purpose of an example. > > [Even if you go as basic a hash as fw classifier you will do better] > > Might be worth to mention the motivation for this. fw and u32 > will definitely perform much better on complex setups but > many do not use u32 hashing not to mention even understand it > or have large nfmark -> classid fw maps. agreed. > Many use u32 to match simple stuff as port numbers, dscp values > or ip subnet addresses and create a new filter for every port/dscp > value and for every address. Some even use temporary classes to > emulate logic relations and this gets really slow. I have to get > numbers first but a single basic filter with ORed matches is probably > faster than a separate u32 filter for every case. I am pretty sure someone who knows u32 well can outperform you (in the scenarios where u32 works using AND etc). Start hitting 50K rules then lets talk ;-> > Sure, once u32 > has ematch support it gets better and the hashing shouldn't have > too much influence even if it's unused.. We can see what to do once > u32 can handle ematches. If your intent is to write an ematch holder, then it would be worth to at least go as far as making it some basic hash - as basic as fw does; where collision leads toa linked list. If it is just to show an example, then it is fine. cheers, jamal From tgraf@suug.ch Tue Jan 4 05:32:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 05:33:01 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04DWXmm015060 for ; Tue, 4 Jan 2005 05:32:53 -0800 Received: from postel.suug.ch (unknown [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 EA8C682; Tue, 4 Jan 2005 14:40:43 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 70FB71C0EA; Tue, 4 Jan 2005 14:41:26 +0100 (CET) Date: Tue, 4 Jan 2005 14:41:26 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050104134126.GJ26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104122738.GG26856@postel.suug.ch> <1104844935.1085.103.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104844935.1085.103.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13376 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 * jamal <1104844935.1085.103.camel@jzny.localdomain> 2005-01-04 08:22 > On Tue, 2005-01-04 at 07:27, Thomas Graf wrote: > > Many use u32 to match simple stuff as port numbers, dscp values > > or ip subnet addresses and create a new filter for every port/dscp > > value and for every address. Some even use temporary classes to > > emulate logic relations and this gets really slow. I have to get > > numbers first but a single basic filter with ORed matches is probably > > faster than a separate u32 filter for every case. > > I am pretty sure someone who knows u32 well can outperform you (in the > scenarios where u32 works using AND etc). > Start hitting 50K rules then lets talk ;-> Sure but I'd call a filter with 50K ANDed rules an unlikely scenario ;-> In most cases logic will beat brute force. I used to have a u32 setup with 4K matches and hashing, it was not only error prone but could be replaced with 12 egp filters gaining 90kpps. Why's that? Simply because it was easier to optimize the logic behind it. egp itself is terribly slow compared to u32. > If your intent is to write an ematch holder, then it would be worth to > at least go as far as making it some basic hash - as basic as fw does; > where collision leads toa linked list. If it is just to show an example, > then it is fine. Using what key? We have no knowledge about what the ematches want to see or not. From tgraf@suug.ch Tue Jan 4 05:37:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 05:38:01 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04DbYW0015675 for ; Tue, 4 Jan 2005 05:37:54 -0800 Received: from postel.suug.ch (unknown [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 3ECB582; Tue, 4 Jan 2005 14:45:46 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 62A781C0EA; Tue, 4 Jan 2005 14:46:29 +0100 (CET) Date: Tue, 4 Jan 2005 14:46:29 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050104134629.GK26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104120333.GF26856@postel.suug.ch> <1104844753.1085.99.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104844753.1085.99.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13377 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 * jamal <1104844753.1085.99.camel@jzny.localdomain> 2005-01-04 08:19 > On Tue, 2005-01-04 at 07:03, Thomas Graf wrote: > > change() (Optional) > > My thinking is: > It doesnt have to be simple 32 bit data. > If i pass you a struct and tell you what length it is, then you as the > classifier dont know need to know anything about it. You just store > mystruct as data and datalen from the TLV. you then pass the datastruct > to match() - Of course the match() will have to know what that struct > means. That's exactly how it is, basically the logic is: if (ops->change) { err = ops->change(tp, data, datalen, m); if (err < 0) goto errout; } else if (datalen > 0) { if (mh->flags & TCF_EM_SIMPLE) { if (datalen != sizeof(u32)) goto errout; m->data = *(u32 *) data; } else { void *v = kmalloc(datalen, GFP_KERNEL); if (v == NULL) { err = -ENOBUFS; goto errout; } memcpy(v, data, datalen); m->data = (unsigned long) v; } } m->datalen = datalen; > > destroy() (Optional) > > Called if provided, otheriwse m->data is freed in ematch api unless > > TCF_EM_SIMPLE is set. > > Again using the above logic, destroy becomes just kfree(mystruct) Right, that's exactly how it is if (m->ops->destroy) m->ops->destroy(tp, m); else if (!(m->hdr.flags & TCF_EM_SIMPLE) && m->data) kfree((void *) m->data); > > dump() (Optional) > > Called if provided, otherwise m->data is dumped onto the skb with > > m->datalen as L. Special handling again for TCF_EM_SIMPLE. > > and dump becomes a matter of looking at datalen and encapsulating > mystruct in a TLV without thinking about what the content is. Absolutely true, you know about the code before you read it ;-> if (m->ops->dump) { if (m->ops->dump(skb, m) < 0) goto rtattr_failure; } else if (m->hdr.flags & TCF_EM_SIMPLE) { u32 u = m->data; RTA_PUT_NOHDR(skb, sizeof(u32), &u); } else if (m->datalen > 0) RTA_PUT_NOHDR(skb, m->datalen, (void *) m->data); From jeremy.guthrie@berbee.com Tue Jan 4 06:58:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 06:59:06 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04EwcSa018326 for ; Tue, 4 Jan 2005 06:58:59 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 Jan 2005 09:07:07 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Tue, 4 Jan 2005 09:07:03 -0600 User-Agent: KMail/1.7.2 References: <200501031455.26980.jeremy.guthrie@berbee.com> <20050103145115.4bdb2cd6@dxpl.pdx.osdl.net> In-Reply-To: <20050103145115.4bdb2cd6@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2323836.npItmXt88H"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501040907.07466.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 04 Jan 2005 15:07:07.0955 (UTC) FILETIME=[0EF69830:01C4F26F] X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart2323836.npItmXt88H Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 03 January 2005 04:51 pm, Stephen Hemminger wrote: > How many flows are going through the router? The neighbour cache > can get to be a bottleneck. Perhaps Robert "the Router Man" Olssen can > give some hints. Tue Jan 4 08:59:12 CST 2005 58406 rt_cache Tue Jan 4 08:59:48 CST 2005 60636 rt_cache Tue Jan 4 09:00:34 CST 2005 63891 rt_cache Tue Jan 4 09:01:02 CST 2005 64635 rt_cache Tue Jan 4 09:01:29 CST 2005 65689 rt_cache Tue Jan 4 09:01:58 CST 2005 63426 rt_cache Tue Jan 4 09:02:25 CST 2005 64139 rt_cache Tue Jan 4 09:02:53 CST 2005 63860 rt_cache Tue Jan 4 09:03:20 CST 2005 65719 rt_cache Tue Jan 4 09:03:48 CST 2005 62465 rt_cache Tue Jan 4 09:04:15 CST 2005 39339 rt_cache =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart2323836.npItmXt88H Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB2rEbqtjaBHGZBeURAqWAAJ9KZYqLRuAig+bKL6/MT9R9/hWuigCeOip1 XyXwql9OqQ4OWxV5aRYM06g= =HPlF -----END PGP SIGNATURE----- --nextPart2323836.npItmXt88H-- From okir@suse.de Tue Jan 4 08:51:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 08:51:38 -0800 (PST) Received: from Cantor.suse.de (news.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04GpAZK026523 for ; Tue, 4 Jan 2005 08:51:31 -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 2F24D12CCE28; Tue, 4 Jan 2005 17:59:39 +0100 (CET) Date: Tue, 4 Jan 2005 17:59:34 +0100 From: Olaf Kirch To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] Problem with recent CMSG_COMPAT_OK fix Message-ID: <20050104165934.GJ7761@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The recent fixes for cmsg_len handling seem to break 32bit compatibility at least on x86_64. The new CMSG_COMPAT_OK macro requires that cmsg_len is greater or equal the size of struct cmsghdr, which is the 64bit version of the struct. The code should really check against the size of struct compat_cmsghdr. Signed-off-by: Olaf Kirch --- linux-2.6.10/net/compat.c.orig 2005-01-04 13:51:49.000000000 +0100 +++ linux-2.6.10/net/compat.c 2005-01-04 16:53:38.000000000 +0100 @@ -125,7 +125,7 @@ (struct compat_cmsghdr __user *)NULL) #define CMSG_COMPAT_OK(ucmlen, ucmsg, mhdr) \ - ((ucmlen) >= sizeof(struct cmsghdr) && \ + ((ucmlen) >= sizeof(struct compat_cmsghdr) && \ (ucmlen) <= (unsigned long) \ ((mhdr)->msg_controllen - \ ((char *)(ucmsg) - (char *)(mhdr)->msg_control))) -- Olaf Kirch | Things that make Monday morning interesting, #2: okir@suse.de | "We have 8,000 NFS mount points, why do we keep ---------------+ running out of privileged ports?" --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cmsg-compat-signedness-fix-fix From: Olaf Kirch Subject: Fix cmsg_len checks in 32bit compat mode References: 49517 - LTC13227 The recent fixes for cmsg_len handling seem to break 32bit compatibility at least on x86_64. The new CMSG_COMPAT_OK macro requires that cmsg_len is greater or equal the size of struct cmsghdr, which is the 64bit version of the struct. The code should really check against the size of struct compat_cmsghdr. Signed-off-by: Olaf Kirch --- linux-2.6.10/net/compat.c.orig 2005-01-04 13:51:49.000000000 +0100 +++ linux-2.6.10/net/compat.c 2005-01-04 16:53:38.000000000 +0100 @@ -125,7 +125,7 @@ (struct compat_cmsghdr __user *)NULL) #define CMSG_COMPAT_OK(ucmlen, ucmsg, mhdr) \ - ((ucmlen) >= sizeof(struct cmsghdr) && \ + ((ucmlen) >= sizeof(struct compat_cmsghdr) && \ (ucmlen) <= (unsigned long) \ ((mhdr)->msg_controllen - \ ((char *)(ucmsg) - (char *)(mhdr)->msg_control))) --T4sUOijqQbZv57TR-- From davem@davemloft.net Tue Jan 4 09:39:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 09:40:02 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04HdY4T028383 for ; Tue, 4 Jan 2005 09:39:55 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1ClsjH-0001yZ-00; Tue, 04 Jan 2005 09:44:23 -0800 Date: Tue, 4 Jan 2005 09:44:23 -0800 From: "David S. Miller" To: David Dillow Cc: netdev@oss.sgi.com, dave@thedillows.org Subject: Re: Ethtool offload patch Message-Id: <20050104094423.2d404759.davem@davemloft.net> In-Reply-To: <1104396895.5845.1.camel@ori.thedillows.org> References: <1104396895.5845.1.camel@ori.thedillows.org> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 30 Dec 2004 03:54:55 -0500 David Dillow wrote: > The attached patch allows the ethtool userspace tool to query and > control IPSEC crypto offload. Aren't you going to need something much more sophisticated than a boolean on/off value? How can I tell the driver "offload 3DES ESP, but not AH at all" or something like that? From robert.j.woodruff@intel.com Tue Jan 4 09:55:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 09:55:38 -0800 (PST) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04HtBkE029422 for ; Tue, 4 Jan 2005 09:55:31 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j04I3bvZ025026; Tue, 4 Jan 2005 18:03:37 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 j04I3PM3020680; Tue, 4 Jan 2005 18:03:28 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005010409592228321 ; Tue, 04 Jan 2005 09:59:27 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 09:59:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [openib-general] Re: [PATCH][v5][0/24] Latest IB patch queue Date: Tue, 4 Jan 2005 09:58:59 -0800 Message-ID: <1AC79F16F5C5284499BB9591B33D6F00032CA55B@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [openib-general] Re: [PATCH][v5][0/24] Latest IB patch queue Thread-Index: AcTtRtA8sfH+7rkCRfybU0u6Of9gBQFPznFQ From: "Woodruff, Robert J" To: "Roland Dreier" , "Karen Shaeffer" Cc: , , X-OriginalArrivalTime: 04 Jan 2005 17:59:01.0344 (UTC) FILETIME=[1238DE00:01C4F287] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j04HtBkE029422 X-archive-position: 13381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: robert.j.woodruff@intel.com Precedence: bulk X-list: netdev Karen> I am interested in Infiniband with x86_64 Opterons. Roland>OK, the current code should work well for you -- x86_64 is probably Roland>the most-tested architecture. I have tested on X86_64 EM64T systems. I have a 4 node cluster that I ran some MPI tests on top of IpoIB over the holidays and it ran without any problems. I know that others have also tested on x86_64 Opteron, so it should work fine for that arch. woody From dave@thedillows.org Tue Jan 4 10:56:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:56:33 -0800 (PST) Received: from iasrv1.idleaire.net (NS1.idleaire.net [65.220.16.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04Iu5W9031702 for ; Tue, 4 Jan 2005 10:56:25 -0800 Received: by iasrv1.idleaire.net (Postfix, from userid 300) id 4D7B8236E66; Tue, 4 Jan 2005 14:04:34 -0500 (EST) Received: from corp4.idleaire.com (corp4.idleaire.com [10.1.66.36]) by iasrv1.idleaire.net (Postfix) with ESMTP id 1799A236E4E; Tue, 4 Jan 2005 14:04:34 -0500 (EST) Received: from knox.voodoobox.net ([10.1.66.124]) by corp4.idleaire.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Jan 2005 14:04:33 -0500 Subject: Re: Ethtool offload patch From: Dave Dillow To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20050104094423.2d404759.davem@davemloft.net> References: <1104396895.5845.1.camel@ori.thedillows.org> <20050104094423.2d404759.davem@davemloft.net> Content-Type: text/plain Message-Id: <1104865471.9860.16.camel@dillow.idleaire.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 04 Jan 2005 14:04:31 -0500 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2005 19:04:33.0963 (UTC) FILETIME=[3A3EE7B0:01C4F290] X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev On Tue, 2005-01-04 at 12:44, David S. Miller wrote: > On Thu, 30 Dec 2004 03:54:55 -0500 > David Dillow wrote: > > > The attached patch allows the ethtool userspace tool to query and > > control IPSEC crypto offload. > > Aren't you going to need something much more sophisticated > than a boolean on/off value? How can I tell the driver > "offload 3DES ESP, but not AH at all" or something like > that? Sure, but this was quicker. :) Actually, I thought that would be better suited to the xfrm_user/pf_key interfaces, perhaps using a flag on the SA that says "do not offload me", or perhaps the opposite. I'd probably want to add a flag to indicate which ones were actually offloaded as well so "ip xfrm state" could give an overview of what is currently offloaded. I know you just got back from vacation, so when you get a chance, I'd welcome comments on the patch series -- I did most of it simply, just to see how it would perform. There is (obviously) still work to do -- I need to figure out how to determine if an IPv6 address is local, and it may be nice to have some sort of LRU list to offload the most active SAs when resources get low on the card. The current version I'm testing includes the changes suggested on the board (change afinfo->map_direction() and remove xfrm_bundle_list), as well as a change to call dev->xfrm_state_add() and dev->xfrm_bundle_add() from process context, so I can get rid of the GFP_ATOMIC allocations. I'll have that out as soon as I can test and rediff everything, but in the meantime, is the whole idea fatally flawed? -- Dave Dillow From pekkas@netcore.fi Tue Jan 4 12:51:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 12:51:31 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04Kp2gC006367 for ; Tue, 4 Jan 2005 12:51:23 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j04Kvh331419; Tue, 4 Jan 2005 22:57:43 +0200 Date: Tue, 4 Jan 2005 22:57:43 +0200 (EET) From: Pekka Savola To: Lennert Buytenhek cc: Jeff Garzik , Netdev , YOSHIFUJI Hideaki / ???????????? , Herbert Xu Subject: Re: IPv6 badness continues In-Reply-To: <20050104093335.GB7823@xi.wantstofly.org> Message-ID: References: <41DA3A60.8050102@pobox.com> <20050104093335.GB7823@xi.wantstofly.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev On Tue, 4 Jan 2005, Lennert Buytenhek wrote: > On Tue, Jan 04, 2005 at 01:40:32AM -0500, Jeff Garzik wrote: > >> Standard FC2 OS with IPv6 6to4 setup as described on >> http://linux.yyz.us/ipv6-fc2-howto.html > > I upgraded my problematic machine to FC3, which somehow broke 6to4, and I > didn't bother to reenable it again because the local DNS server (dnscache) > just drops AAAA queries on the floor anyway, leading to lots of timeouts > when trying to resolve host names, etc. Ever since 6to4 was turned off > on that box I stopped seeing these messages. Surely it doesn't just drop AAAA queries on the floor, but sends an error message? If so, maybe then the problem is that glibc resolver cannot properly handle such errors without undue timeouts. Actually I've just sent a message on libc-alpha@ describing a similar timeout issue: http://sources.redhat.com/ml/libc-alpha/2005-01/msg00007.html Maybe you could run a little bit of debug on whether the server sends errors (which kind) and how the resolver reacts. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From davem@davemloft.net Tue Jan 4 14:16:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 14:16:08 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04MFexc009542 for ; Tue, 4 Jan 2005 14:16:01 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Clx2Q-0002vA-00; Tue, 04 Jan 2005 14:20:26 -0800 Date: Tue, 4 Jan 2005 14:20:26 -0800 From: "David S. Miller" To: Andrew Morton Cc: netdev@oss.sgi.com Subject: Re: Fw: b44 ifconfig fails with ENOMEM Message-Id: <20050104142026.000be2e8.davem@davemloft.net> In-Reply-To: <20050103191836.57f918e5.akpm@osdl.org> References: <20050103191836.57f918e5.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 3 Jan 2005 19:18:36 -0800 Andrew Morton wrote: > b44 requires an order-8 allocation? Good luck... Yes, it allocates a full TX ring worth of bounce buffers to work around a DMA addressing limitation. It should do a bunch of smaller consistent allocations instead of one huge one, that's for sure. From tgraf@suug.ch Tue Jan 4 14:27:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 14:27:47 -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 j04MRI31010320 for ; Tue, 4 Jan 2005 14:27:39 -0800 Received: from postel.suug.ch (unknown [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 0F04382; Tue, 4 Jan 2005 23:35:29 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 848AD1C0EA; Tue, 4 Jan 2005 23:36:12 +0100 (CET) Date: Tue, 4 Jan 2005 23:36:12 +0100 From: Thomas Graf To: Jamal Hadi Salim Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050104223612.GN26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050103125635.GB26856@postel.suug.ch> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13385 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 Updated patch with the following changes (still untested) * destroy/dump/change are not optional (only match is required) * ematch can set datalen in ematch_ops to have the ematch api do a data length sanity check. (to at least avoid bogus memory refs) * better nop macros if ematch is not enabled * TCF_EM_SIMPLE flag which marks an ematch config as simple, meaning that the data consists of a u32 value. * API documentation * removed handle from ematch_hdr * userspace visible ematch header is no longer used in ematch tree and the attributes are copied now to avoid duplications such as kind. * suggestion comment to use a kind > 2^15 for private/temporary ematches to avoid collisions on kernel upgrades * some minor cosmetic fixes to make code look more pretty * renamed tcf_em_tree_change to tcf_em_tree_replace, it gives a better impression on what is being done Jamal, I know it's still not simple enough for you but can you live with it? ;-> diff -Nru linux-2.6.10-bk6.orig/include/linux/pkt_cls.h linux-2.6.10-bk6/include/linux/pkt_cls.h --- linux-2.6.10-bk6.orig/include/linux/pkt_cls.h 2005-01-04 18:10:11.000000000 +0100 +++ linux-2.6.10-bk6/include/linux/pkt_cls.h 2005-01-04 18:10:17.000000000 +0100 @@ -319,4 +319,51 @@ #define TCA_TCINDEX_MAX (__TCA_TCINDEX_MAX - 1) +struct tcf_ematch_tree_hdr +{ + __u16 nmatches; + __u16 progid; +}; + +enum +{ + TCA_EMATCH_TREE_UNSPEC, + TCA_EMATCH_TREE_HDR, + TCA_EMATCH_TREE_LIST, + __TCA_EMATCH_TREE_MAX +}; +#define TCA_EMATCH_TREE_MAX (__TCA_EMATCH_TREE_MAX - 1) + +struct tcf_ematch_hdr +{ + __u16 matchID; + __u16 kind; + __u16 flags; + __u16 pad; /* currently unused */ +}; + +/* Ematch type assignments + * 1..32767 Reserved for ematches inside kernel tree + * 32768..65535 Free to use, not reliable + */ +enum +{ + TCF_EM_CONTAINER, + __TCF_EM_MAX +}; + +#define TCF_EM_REL_MASK 3 +#define TCF_EM_REL_VALID(v) \ + (!(((v) & TCF_EM_REL_MASK) == TCF_EM_REL_MASK)) +#define TCF_EM_LAST_KEY(v) (!((v) & TCF_EM_REL_MASK)) + +#define TCF_EM_REL_OBVIOUS(v, r) (TCF_EM_LAST_KEY(v) || \ + (!(r) && ((v) & TCF_EM_REL_AND)) || ((r) && ((v) & TCF_EM_REL_OR))) + +#define TCF_EM_REL_END (1<<0) +#define TCF_EM_REL_AND (1<<1) +#define TCF_EM_REL_OR (1<<2) +#define TCF_EM_INVERT (1<<3) +#define TCF_EM_SIMPLE (1<<4) + #endif diff -Nru linux-2.6.10-bk6.orig/include/linux/rtnetlink.h linux-2.6.10-bk6/include/linux/rtnetlink.h --- linux-2.6.10-bk6.orig/include/linux/rtnetlink.h 2005-01-04 18:10:11.000000000 +0100 +++ linux-2.6.10-bk6/include/linux/rtnetlink.h 2005-01-04 01:33:32.000000000 +0100 @@ -779,6 +779,11 @@ goto rtattr_failure; \ __rta_fill(skb, attrtype, attrlen, data); }) +#define RTA_PUT_NOHDR(skb, attrlen, data) \ +({ if (unlikely(skb_tailroom(skb) < (int)(attrlen))) \ + goto rtattr_failure; \ + memcpy(skb_put(skb, RTA_ALIGN(attrlen)), data, attrlen); }) + static inline struct rtattr * __rta_reserve(struct sk_buff *skb, int attrtype, int attrlen) { diff -Nru linux-2.6.10-bk6.orig/include/net/pkt_cls.h linux-2.6.10-bk6/include/net/pkt_cls.h --- linux-2.6.10-bk6.orig/include/net/pkt_cls.h 2005-01-04 18:10:11.000000000 +0100 +++ linux-2.6.10-bk6/include/net/pkt_cls.h 2005-01-04 19:42:59.000000000 +0100 @@ -149,6 +149,127 @@ extern int tcf_exts_dump_stats(struct sk_buff *skb, struct tcf_exts *exts, struct tcf_ext_map *map); +#ifdef CONFIG_NET_EMATCH + +struct tcf_ematch_ops; + +/** + * struct tcf_ematch - extended match (ematch) + * + * @matchID: identifier to allow userspace to reidentify a match + * @flags: flags specifying attributes and the relation to other matches + * @ops: the operations lookup table of the corresponding ematch module + * @datalen: length of the ematch specific configuration data + * @data: ematch specific data + */ +struct tcf_ematch +{ + u16 matchID; + u16 flags; + struct tcf_ematch_ops * ops; + unsigned int datalen; + unsigned long data; +}; + +/** + * struct tcf_ematch_tree - ematch tree handle + * + * @hdr: ematch tree header supplied by userspace + * @matches: array of ematches + */ +struct tcf_ematch_tree +{ + struct tcf_ematch_tree_hdr hdr; + struct tcf_ematch * matches; + +}; + +#define em_lookup_match(t, i) (&(t)->matches[(i)]) + +/** + * struct tcf_ematch_ops - ematch module operations + * + * @kind: identifier (kind) of this ematch module + * @datalen: length of expected configuration data (optional) + * @change: called during validation (optional) + * @match: called during ematch tree evaluation, must return 1/0 + * @destroy: called during destroyage (optional) + * @dump: called during dumping process (optional) + * @owner: owner, must be set to THIS_MODULE + * @link: link to previous/next ematch module (internal use) + */ +struct tcf_ematch_ops +{ + int kind; + int datalen; + int (*change)(struct tcf_proto *, void *, + int, struct tcf_ematch *); + int (*match)(struct sk_buff *, struct tcf_ematch *); + int (*destroy)(struct tcf_proto *, + struct tcf_ematch *); + int (*dump)(struct sk_buff *, struct tcf_ematch *); + struct module *owner; + struct list_head link; +}; + +extern int tcf_em_register(struct tcf_ematch_ops *); +extern int tcf_em_unregister(struct tcf_ematch_ops *); +extern int tcf_em_tree_validate(struct tcf_proto *, struct rtattr *, + struct tcf_ematch_tree *); +extern void tcf_em_tree_destroy(struct tcf_proto *, struct tcf_ematch_tree *); +extern int tcf_em_tree_dump(struct sk_buff *, struct tcf_ematch_tree *, int); +extern int __tcf_em_tree_match(struct sk_buff *, struct tcf_ematch_tree *); + +/** + * tcf_em_tree_replace - replace ematch tree of a running classifier + * + * @tp: classifier kind handle + * @dst: destination ematch tree variable + * @src: source ematch tree (temporary tree from tcf_em_tree_validate) + * + * This functions replaces the ematch tree in @dst with the ematch + * tree in @src. The classifier in charge of the ematch tree may be + * running. + */ +static inline void +tcf_em_tree_replace(struct tcf_proto *tp, struct tcf_ematch_tree *dst, + struct tcf_ematch_tree *src) +{ + tcf_tree_lock(tp); + memcpy(dst, src, sizeof(*dst)); + tcf_tree_unlock(tp); +} + +/** + * tcf_em_tree_match - evaulate an ematch tree + * + * @skb: socket buffer of the packet in question + * @t: ematch tree to be used for evaluation + * + * This function matches @skb against the ematch tree in @t by going + * through all ematches respecting their logic relations returning + * as soon as the result is obvious. + * + * Returns 1 if the ematch tree as-one matches, no ematches are configured + * or ematch is not enabled in the kernel, otherwise 0 is returned. + */ +#define tcf_em_tree_match(skb, t) \ + ((t)->hdr.nmatches ? __tcf_em_tree_match(skb, t) : 1) + +#else /* CONFIG_NET_EMATCH */ + +struct tcf_ematch_tree +{ +}; + +#define tcf_em_tree_validate(tp, tb, t) (0) +#define tcf_em_tree_destroy(tp, t) do { } while(0) +#define tcf_em_tree_dump(skb, t, tlv) (0) +#define tcf_em_tree_change(tp, dst, src) do { } while(0) +#define tcf_em_tree_match(skb, t) (1) + +#endif /* CONFIG_NET_EMATCH */ + #ifdef CONFIG_NET_CLS_IND static inline int tcf_change_indev(struct tcf_proto *tp, char *indev, struct rtattr *indev_tlv) diff -Nru linux-2.6.10-bk6.orig/net/sched/Kconfig linux-2.6.10-bk6/net/sched/Kconfig --- linux-2.6.10-bk6.orig/net/sched/Kconfig 2005-01-04 18:10:11.000000000 +0100 +++ linux-2.6.10-bk6/net/sched/Kconfig 2005-01-04 18:10:17.000000000 +0100 @@ -375,6 +375,19 @@ To compile this code as a module, choose M here: the module will be called cls_rsvp6. +config NET_EMATCH + bool "Extended Matches" + depends on NET_CLS + ---help--- + Say Y here if you want to use extended matches on top of classifiers + and select the extended matches below. + + Extended matches are small classification helpers not worth writing + a separate classifier. + + You must have a recent version of the iproute2 tools in order to use + extended matches. + config NET_CLS_ACT bool "Packet ACTION" depends on EXPERIMENTAL && NET_CLS && NET_QOS diff -Nru linux-2.6.10-bk6.orig/net/sched/Makefile linux-2.6.10-bk6/net/sched/Makefile --- linux-2.6.10-bk6.orig/net/sched/Makefile 2005-01-04 18:10:11.000000000 +0100 +++ linux-2.6.10-bk6/net/sched/Makefile 2005-01-04 18:10:17.000000000 +0100 @@ -33,3 +33,4 @@ obj-$(CONFIG_NET_CLS_RSVP) += cls_rsvp.o obj-$(CONFIG_NET_CLS_TCINDEX) += cls_tcindex.o obj-$(CONFIG_NET_CLS_RSVP6) += cls_rsvp6.o +obj-$(CONFIG_NET_EMATCH) += ematch.o diff -Nru linux-2.6.10-bk6.orig/net/sched/ematch.c linux-2.6.10-bk6/net/sched/ematch.c --- linux-2.6.10-bk6.orig/net/sched/ematch.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.10-bk6/net/sched/ematch.c 2005-01-04 18:55:40.000000000 +0100 @@ -0,0 +1,396 @@ +/* + * net/sched/ematch.c Extended Match API + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EMATCH_STACK_SIZE 32 + +static LIST_HEAD(ematch_ops); +static rwlock_t ematch_mod_lock = RW_LOCK_UNLOCKED; + +static inline struct tcf_ematch_ops * +tcf_em_lookup(u16 kind) +{ + struct tcf_ematch_ops *e = NULL; + + read_lock(&ematch_mod_lock); + list_for_each_entry(e, &ematch_ops, link) { + if (kind == e->kind) { + if (!try_module_get(e->owner)) + e = NULL; + break; + } + } + read_unlock(&ematch_mod_lock); + + return e; +} + +/** + * tcf_em_register - register an extended match + * + * @ops: ematch operations lookup table + * + * This function must be called by ematches to announce their presence. + * The given @ops must have kind set to a unique identifier and the + * callback match() must be implemented. All other callbacks are optional + * and a fallback implementation is used instead. + * + * Returns -EEXISTS if an ematch of the same kind has already registered. + */ +int tcf_em_register(struct tcf_ematch_ops *ops) +{ + int err = -EEXIST; + struct tcf_ematch_ops *e; + + write_lock(&ematch_mod_lock); + list_for_each_entry(e, &ematch_ops, link) + if (ops->kind == e->kind) + goto errout; + + list_add_tail(&ops->link, &ematch_ops); + err = 0; +errout: + write_unlock(&ematch_mod_lock); + return err; +} + +/** + * tcf_em_unregister - unregster and extended match + * + * @ops: ematch operations lookup table + * + * This function must be called by ematches to announce their disappearance + * for examples when the module gets unloaded. The @ops parameter must be + * the same as the one used for registration. + * + * Returns -ENOENT if no matching ematch was found. + */ +int tcf_em_unregister(struct tcf_ematch_ops *ops) +{ + int err = 0; + struct tcf_ematch_ops *e; + + write_lock(&ematch_mod_lock); + list_for_each_entry(e, &ematch_ops, link) { + if (e == ops) { + list_del(&e->link); + goto out; + } + } + + err = -ENOENT; +out: + write_unlock(&ematch_mod_lock); + return err; +} + +static int tcf_em_validate(struct tcf_proto *tp, struct tcf_ematch_tree_hdr *th, + struct tcf_ematch *m, struct rtattr *rta) +{ + int err = -EINVAL; + struct tcf_ematch_hdr *mh = RTA_DATA(rta); + int datalen = RTA_PAYLOAD(rta) - sizeof(*mh); + void *data = (void *) data + sizeof(*mh); + + if (!TCF_EM_REL_VALID(mh->flags)) + goto errout; + + if (mh->kind == TCF_EM_CONTAINER) { + u32 ref; + + if (datalen < sizeof(ref)) + goto errout; + ref = *(u32 *) data; + if (ref >= th->nmatches) + goto errout; + m->data = ref; + } else { + struct tcf_ematch_ops *ops = tcf_em_lookup(mh->kind); + + if (ops == NULL) { + err = -ENOENT; + goto errout; + } + + if (ops->datalen && datalen < ops->datalen) + goto errout; + + if (ops->change) { + err = ops->change(tp, data, datalen, m); + if (err < 0) + goto errout; + } else if (datalen > 0) { + if (mh->flags & TCF_EM_SIMPLE) { + if (datalen < sizeof(u32)) + goto errout; + m->data = *(u32 *) data; + } else { + void *v = kmalloc(datalen, GFP_KERNEL); + if (v == NULL) { + err = -ENOBUFS; + goto errout; + } + memcpy(v, data, datalen); + m->data = (unsigned long) v; + } + } + } + + m->matchID = mh->matchID; + m->flags = mh->flags; + m->datalen = datalen; + + err = 0; +errout: + return err; +} + +/** + * tcf_em_tree_validate - validate ematch config TLV and build ematch tree + * + * @tp: classifier kind handle + * @rta: ematch tree configuration TLV + * @tree: destination ematch tree variable to store the resulting + * ematch tree. + * + * This function validates the given configuration TLV @rta and builds an + * ematch tree in @tree. The resulting tree must later be copied into + * the private classifier data using tcf_em_tree_change(). You MUST NOT + * provide the ematch tree variable of the private classifier data directly, + * the changes would not be locked properly. + * + * Returns a negative error code if the configuration TLV contains errors. + */ +int tcf_em_tree_validate(struct tcf_proto *tp, struct rtattr *rta, + struct tcf_ematch_tree *tree) +{ + int i, len, mlen, err = -EINVAL; + struct rtattr *m, *tb[TCA_EMATCH_TREE_MAX]; + struct tcf_ematch_tree_hdr *th; + + if (!rta || rtattr_parse_nested(tb, TCA_EMATCH_TREE_MAX, rta) < 0) + goto errout; + + if (RTA_PAYLOAD(tb[TCA_EMATCH_TREE_HDR-1]) < sizeof(*th) || + RTA_PAYLOAD(tb[TCA_EMATCH_TREE_LIST-1]) < sizeof(*m)) + goto errout; + + th = RTA_DATA(tb[TCA_EMATCH_TREE_HDR-1]); + m = RTA_DATA(tb[TCA_EMATCH_TREE_LIST-1]); + len = RTA_PAYLOAD(tb[TCA_EMATCH_TREE_LIST-1]); + mlen = th->nmatches * sizeof(struct tcf_ematch); + + memcpy(&tree->hdr, th, sizeof(*th)); + + tree->matches = kmalloc(mlen, GFP_KERNEL); + if (tree->matches == NULL) + goto errout; + memset(tree->matches, 0, mlen); + + for (i = 0; RTA_OK(m, len); i++) { + if (rta->rta_type != (i+1) || i >= th->nmatches || + RTA_PAYLOAD(rta) < sizeof(struct tcf_ematch_hdr)) { + err = -EINVAL; + goto errout_abort; + } + + err = tcf_em_validate(tp, th, em_lookup_match(tree, i), rta); + if (err < 0) + goto errout_abort; + + m = RTA_NEXT(m, len); + } + + if (i != th->nmatches) { + err = -EINVAL; + goto errout_abort; + } + + + err = 0; +errout: + return err; + +errout_abort: + tcf_em_tree_destroy(tp, tree); + return err; +} + +/** + * tcf_em_tree_destroy - destroy an ematch tree + * + * @tp: classifier kind handle + * @t: ematch tree to be deleted + * + * This functions destroys an ematch tree previously created by + * tcf_em_tree_validate()/tcf_em_tree_change(). You must ensure that + * the ematch tree is not in use before calling this function. + */ +void tcf_em_tree_destroy(struct tcf_proto *tp, struct tcf_ematch_tree *t) +{ + int i; + + if (t->matches == NULL) + return; + + for (i = 0; i < t->hdr.nmatches; i++) { + struct tcf_ematch *m = em_lookup_match(t, i); + if (m->ops) { + if (m->ops->destroy) + m->ops->destroy(tp, m); + else if (!(m->flags & TCF_EM_SIMPLE) && m->data) + kfree((void *) m->data); + module_put(m->ops->owner); + } + } + + t->hdr.nmatches = 0; + kfree(t->matches); +} + +/** + * tcf_em_tree_dump - dump ematch tree into a rtnl message + * + * @skb: skb holding the rtnl message + * @t: ematch tree to be dumped + * @tlv: TLV type to be used to encapsulate the tree + * + * This function dumps a ematch tree into a rtnl message. It is valid to + * call this function while the ematch tree is in use. + * + * Returns -1 if the skb tailroom is insufficient. + */ +int tcf_em_tree_dump(struct sk_buff *skb, struct tcf_ematch_tree *t, int tlv) +{ + int i; + struct rtattr * p_rta = (struct rtattr*) skb->tail; + struct rtattr * pm_rta; + + RTA_PUT(skb, tlv, 0, NULL); + RTA_PUT(skb, TCA_EMATCH_TREE_HDR, sizeof(t->hdr), &t->hdr); + + pm_rta = (struct rtattr *) skb->tail; + RTA_PUT(skb, TCA_EMATCH_TREE_LIST, 0, NULL); + + for (i = 0; i < t->hdr.nmatches; i++) { + struct rtattr * pd_rta = (struct rtattr*) skb->tail; + struct tcf_ematch *m = em_lookup_match(t, i); + struct tcf_ematch_hdr hdr = { + .kind = m->ops->kind, + .matchID = m->matchID, + .flags = m->flags + }; + + RTA_PUT(skb, i+1, sizeof(hdr), &hdr); + if (m->ops->dump) { + if (m->ops->dump(skb, m) < 0) + goto rtattr_failure; + } else if (m->flags & TCF_EM_SIMPLE) { + u32 u = m->data; + RTA_PUT_NOHDR(skb, sizeof(u32), &u); + } else if (m->datalen > 0) + RTA_PUT_NOHDR(skb, m->datalen, (void *) m->data); + + pd_rta->rta_len = skb->tail - (u8*) pd_rta; + } + + pm_rta->rta_len = skb->tail - (u8*) pm_rta; + p_rta->rta_len = skb->tail - (u8*) p_rta; + return 0; +rtattr_failure: + return -1; +} + +static inline int tcf_em_match(struct sk_buff *skb, struct tcf_ematch *m) +{ + int r = 0; + + if (m->ops->match) + r = m->ops->match(skb, m); + + return m->flags & TCF_EM_INVERT ? !r : r; +} + +/* Do not use this function directly, use tcf_em_tree_match instead */ +int __tcf_em_tree_match(struct sk_buff *skb, struct tcf_ematch_tree *t) +{ + int i = 0, n = 0, r = 0; + struct tcf_ematch *m; + int stack[EMATCH_STACK_SIZE]; + + memset(stack, 0, sizeof(stack)); + +proceed: + while (n < t->hdr.nmatches) { + m = em_lookup_match(t, n); + + if (m->ops->kind == TCF_EM_CONTAINER) { + if (unlikely(i >= EMATCH_STACK_SIZE)) + goto stack_overflow; + + if (unlikely(m->data <= n)) + goto backward_jump; + + stack[i++] = n; + n = m->data; + continue; + } + + r = tcf_em_match(skb, m); + if (TCF_EM_REL_OBVIOUS(m->flags, r)) + break; + n++; + } + +pop_stack: + if (i > 0) { + n = stack[--i]; + m = em_lookup_match(t, n); + + if (TCF_EM_REL_OBVIOUS(m->flags, r)) + goto pop_stack; + else { + n++; + goto proceed; + } + } + + return r; + +stack_overflow: + if (net_ratelimit()) + printk("Local stack overflow, increase EMATCH_STACK_SIZE\n"); + return -1; + +backward_jump: + if (net_ratelimit()) + printk("Detected backward precedence jump, fix your filter.\n"); + return -1; +} + +EXPORT_SYMBOL(tcf_em_register); +EXPORT_SYMBOL(tcf_em_unregister); +EXPORT_SYMBOL(tcf_em_tree_validate); +EXPORT_SYMBOL(tcf_em_tree_destroy); +EXPORT_SYMBOL(tcf_em_tree_dump); +EXPORT_SYMBOL(__tcf_em_tree_match); + From jgarzik@pobox.com Tue Jan 4 15:18:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 15:18:39 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04NIAdb012795 for ; Tue, 4 Jan 2005 15:18:30 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cly4Z-0000mR-7l; Tue, 04 Jan 2005 23:26:43 +0000 Message-ID: <41DB2623.7000601@pobox.com> Date: Tue, 04 Jan 2005 18:26:27 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lennert Buytenhek CC: Netdev , YOSHIFUJI Hideaki / ???????????? , Herbert Xu Subject: Re: IPv6 badness continues References: <41DA3A60.8050102@pobox.com> <20050104093335.GB7823@xi.wantstofly.org> In-Reply-To: <20050104093335.GB7823@xi.wantstofly.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Lennert Buytenhek wrote: > On Tue, Jan 04, 2005 at 01:40:32AM -0500, Jeff Garzik wrote: > > >>Standard FC2 OS with IPv6 6to4 setup as described on >>http://linux.yyz.us/ipv6-fc2-howto.html > > > I upgraded my problematic machine to FC3, which somehow broke 6to4, and I > didn't bother to reenable it again because the local DNS server (dnscache) > just drops AAAA queries on the floor anyway, leading to lots of timeouts > when trying to resolve host names, etc. Ever since 6to4 was turned off > on that box I stopped seeing these messages. hmmm, that's annoying. My router is still FC2, but I'll check that out when I upgrade it to FC3. Jeff From jgarzik@pobox.com Tue Jan 4 15:20:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 15:20:53 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04NKOLb013162 for ; Tue, 4 Jan 2005 15:20:44 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cly6f-0000q7-SL; Tue, 04 Jan 2005 23:28:53 +0000 Message-ID: <41DB26A6.2070008@pobox.com> Date: Tue, 04 Jan 2005 18:28:38 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Paul Jakma , Tommy Christensen Subject: Re: [patch 4/10] s390: network driver. References: <1104764710.1048.580.camel@jzny.localdomain> In-Reply-To: <1104764710.1048.580.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev jamal wrote: > The change is simple if theres consensus to go this path. Can you resend your patch? My main objection was that any change should be made in the core, not in individual net drivers. Another objection was that it seemed that some of the proposed solutions for clearing the queue on link down were imposing app-specific policy on the overall kernel. Aren't there cases where people would -not- want the queue to be cleared? Jeff From y030729@njupt.edu.cn Tue Jan 4 16:45:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 16:45:22 -0800 (PST) Received: from njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j050ipgR019227 for ; Tue, 4 Jan 2005 16:45:12 -0800 Received: (eyou send program); Wed, 05 Jan 2005 09:47:27 +0800 Message-ID: <304889647.25037@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Wed, 05 Jan 2005 09:47:27 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: imipak@yahoo.com, netdev@oss.sgi.com Cc: lartc@mailman.ds9a.nl Date: Wed, 05 Jan 2005 09:47:27 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: Re: [LARTC] Scheduler Mechnisms! Content-Type: text/plain X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: y030729@njupt.edu.cn Precedence: bulk X-list: netdev Thank you very much, i will try to find these papers which must be very helpful for me. The "more" means that whether there are other mechanisms not only for Linux. Sorry, i have not make it clear! Sometimes, i wonder whether the qdiscs such as CBQ, RED, GRED ... are belong to the scheduler mechanisms in linux enviroment. For example, In Red, which i can find are enqueue, and dequeue.... so, if i add a RED qidsc to a class, must i add a scheduler mechanism so that i can decide which packet in the queues will be scheduled and put to the link? Good luck, Best, >It depends on what you mean by "more". More for Linux? > Certainly. HTB3 seems to be a popular mechanism, and > you can use IMQ to set up an intermediate device to > allow shaping of both inbound and outbound traffic, > using one (or more!) scheduling mechanisms in series. > > (In fact, there are several versions of IMQ out there. > I've given links to both the projects that seem to be > alive, but there may be more.) > > There's also ESFQ, but there doesn't seem to be much > active work on that. There are forward ports to recent > Linux kernels, though. QLinux has a version of H-SFQ > for Linux, but again it seems to be getting long in > the tooth. Unfortunately, I can't find any forward > ports of that. > > http://luxik.cdi.cz/~devik/qos/htb/ > http://www.linuximq.net/ > http://pupa.da.ru/imq/ > > http://www.digriz.org.uk/jdg-qos-script/#qos-2.6 > http://kem.p.lodz.pl/~peter/qnet/ > http://lass.cs.umass.edu/software/qlinux/ > > There are a great many systems that I can't find a > Linux version of. Cisco routers support something > called "Class-Based Weighted Fair Queueing" (CBWFQ) > which seems to be a hybrid of classful and classless > scheduling. Cisco also has two versions of ECN, for > forwards and backwards propogation. > > I've listed below a number of papers detailing various > QoS schemes. Some of these have been implemented in > other OS' (the BSDs tend to get a lot of this stuff > implemented quickly for them as part of ALTQ) and some > I've never seen an implementation at all. However, the > papers should all give enough information to write a > version for Linux. > > Note: ALTQ can be found at: > http://www.csl.sony.co.jp/person/kjc/kjc/software.html > > Please note that this list is not exhaustive. Rather, > I got exhausted after trying to find what was out > there and what state it was currently in. QoS is a big > field, if the number of papers is anything to go by. > Linux only touches the fringes of it. If anyone feels > particularly bored, or in need of a good ego boost, it > would be cool to see if a reasonable selection of > these could be introduced into Linux over the 2.7 > cycle. > > EDF (Earliest Deadline First) > http://citeseer.ist.psu.edu/13919.html > > BLUE (an alternative to RED) > http://citeseer.ist.psu.edu/feng99blue.html > > AF PHB (Assured Forwarding Per-Hop Behaviour) > http://citeseer.ist.psu.edu/552302.html > > SFB (Stochastic Fair Blue) > http://citeseer.ist.psu.edu/551253.html > > GREEN (a pro-active variant on the theme of RED) > http://citeseer.ist.psu.edu/feng02green.html > > SMART (Scalable Multipath Aggregated RouTing) > http://citeseer.ist.psu.edu/vutukury00smart.html > > CSFQ (Core Stateless Fair Queueing) > http://citeseer.ist.psu.edu/391.html > > StFQ (Start-Time Fair Queueing) > http://citeseer.ist.psu.edu/goyal96starttime.html > > RFQ (Rainbow Fair Queueing) > http://citeseer.ist.psu.edu/cao00rainbow.html > > PrFQ (Probabalistic Fair Queueing) > http://citeseer.ist.psu.edu/anker00prfq.html > > ERR (Elastic Round Robin) > http://citeseer.ist.psu.edu/kanhere02fair.html > > GFQ (Greedy Fair Queueing) > http://citeseer.ist.psu.edu/690207.html > > PERR (Prioritized Elastic Round Robin) > http://citeseer.ist.psu.edu/681127.html > > AOQ (Anchored Opportunity Queueing) > http://citeseer.ist.psu.edu/701742.html > > BSFQ (Bin Sort Fair Queueing) > http://citeseer.ist.psu.edu/622188.html > > > As for the final question on what happens between > enqueue and dequeue, there are various diagrams out > there which show different aspects of how packets > traverse the system. I've included a few links to > those I could find: > > http://open-source.arkoon.net/kernel/kernel_net.png > http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png > http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html > http://www.docum.org/docum.org/kptd/ > > The last of these is the infamous Kernel Packet > Travelling Diagram. Most links to this that I've been > able to find are broken. It should be noted that the > diagrams all refer to the Linux 2.4 kernel. Linux 2.6 > has quite a few QoS changes to it, but I'm unclear as > to whether they significantly alter any of the flows. > > I hope this is of some use. Or, at the very least, is > an effective remedy to insomnia. :) > > Jonathan > > --- Zhenyu Wu wrote: > > > Hello, > > > > Normally, in addition to such qdisc scheduler > > mechanisms as FIFO, PQ, WRR, WFQ, > > are there any more? Then, there is a confusion on > > scheduler in Linux enviroment: > > Assume there is a qdisc, such as RED as a leaf qdisc > > in a router, we know, if > > there is packet which want to enqueue the packet, > > the Function red_enqueue is > > called, but when the packet leave the queue(when the > > Function red_dequeue is > > called)? I think it is meaningless when the pack > > leaves the queue just it enterred > > it. Is there anything need to be done betweent the > > packet's enqueue and dequeue? > > > > Best, > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: > > http://lartc.org/ > > > > > > > __________________________________ > Do you Yahoo!? > Jazz up your holiday email with celebrity designs. Learn more. > http://celebrity.mail.yahoo.com > > From hadi@cyberus.ca Tue Jan 4 06:55:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 06:55:43 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04EtFcD003593 for ; Tue, 4 Jan 2005 06:55:36 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Cm1KF-000358-QG for netdev@oss.sgi.com; Tue, 04 Jan 2005 21:55:07 -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 1Cm1K7-0003Tm-Sr; Tue, 04 Jan 2005 21:55:00 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050104134126.GJ26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104122738.GG26856@postel.suug.ch> <1104844935.1085.103.camel@jzny.localdomain> <20050104134126.GJ26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104893694.1124.37.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Jan 2005 21:54:54 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13389 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-01-04 at 08:41, Thomas Graf wrote: > * jamal <1104844935.1085.103.camel@jzny.localdomain> 2005-01-04 08:22 > > On Tue, 2005-01-04 at 07:27, Thomas Graf wrote: > > I am pretty sure someone who knows u32 well can outperform you (in the > > scenarios where u32 works using AND etc). > > Start hitting 50K rules then lets talk ;-> > > Sure but I'd call a filter with 50K ANDed rules an unlikely scenario ;-> 50K matches is probably senseless - i was talking about rules (which contain matches). > In most cases logic will beat brute force. I used to have a u32 setup > with 4K matches and hashing, it was not only error prone but could be > replaced with 12 egp filters gaining 90kpps. Why's that? Simply because > it was easier to optimize the logic behind it. egp itself is terribly > slow compared to u32. I think this is a debate that can be easily settled ;-> Agreed logic will beat brute force smartness and u32 is not exactly for the faint hearted. And its usability is extremely poor - but lets maintain its power as is. > > If your intent is to write an ematch holder, then it would be worth to > > at least go as far as making it some basic hash - as basic as fw does; > > where collision leads toa linked list. If it is just to show an example, > > then it is fine. > > Using what key? We have no knowledge about what the ematches want to > see or not. Ok, good question ;-> Maybe you should have own some 32 bit key? cheers, jamal From hadi@cyberus.ca Tue Jan 4 07:12:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 07:12:50 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04FCM6Y004421 for ; Tue, 4 Jan 2005 07:12:42 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Cm1as-0005Np-7e for netdev@oss.sgi.com; Tue, 04 Jan 2005 22:12:18 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cm1an-0006sZ-Mh; Tue, 04 Jan 2005 22:12:13 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050104223612.GN26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104894728.1117.56.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Jan 2005 22:12:08 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13390 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-01-04 at 17:36, Thomas Graf wrote: > * TCF_EM_SIMPLE flag which marks an ematch config as simple, meaning > that the data consists of a u32 value. This is 1 of 2 parts i think thats still an issue; otherwise looks very good. Why do i need to signal something as simple? AND why does it have to be 32 bit type - what edge does that give you? I should be able to specify a struct with two 32 bits and encap it in a TLV and the classifier can treat it the same way - it knows the type and length - thats sufficient to create, destroy and dump. The other issue is still on the ematch/match interleaving i.e i should be able to say something along the lines: //simple slammer-worm or code-red ACL detector rule //using u32 classifier and ematches (match ip protocol udp port 1434 AND ematch packetlen minsize 404 maxsize 404) OR (match ip protocol tcp http AND ematch urlscanner "*.ida") action ipt -j ULOG "Virus detected and dropped" action drop Not a very good example - but you can see how powerfull this is when you can quickly use a string scanner such as the one you have as an ematch while maintaining u32 as is. cheers, jamal From hadi@cyberus.ca Tue Jan 4 07:20:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 07:20:20 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04FJolB005008 for ; Tue, 4 Jan 2005 07:20:11 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Cm1i4-00005l-DW for netdev@oss.sgi.com; Tue, 04 Jan 2005 22:19:44 -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 1Cm1hv-0007wP-Ir; Tue, 04 Jan 2005 22:19:35 -0500 Subject: Re: [patch 4/10] s390: network driver. From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Paul Jakma , Tommy Christensen In-Reply-To: <41DB26A6.2070008@pobox.com> References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> Content-Type: multipart/mixed; boundary="=-0846Th3rEGC6QKddUtsg" Organization: jamalopolous Message-Id: <1104895169.1117.63.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Jan 2005 22:19:29 -0500 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13391 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 --=-0846Th3rEGC6QKddUtsg Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-01-04 at 18:28, Jeff Garzik wrote: > jamal wrote: > > The change is simple if theres consensus to go this path. > > Can you resend your patch? I didnt send any patch - but heres one that looks right - havent tried compiling it. > My main objection was that any change should be made in the core, not in > individual net drivers. Attached patch resolves that concern > Another objection was that it seemed that some of the proposed solutions > for clearing the queue on link down were imposing app-specific policy on > the overall kernel. > > Aren't there cases where people would -not- want the queue to be cleared? Thats a good question and your point of imposing policy in the kernel is valid. I know that i would probably want packets to appear they are going out when the wire is pulled from underneath me. Theres possibly people who would want it differently - so for we havent heard from them. Maybe poll far and wide - or push it in and wait for them to whine. cheers, jamal --=-0846Th3rEGC6QKddUtsg Content-Disposition: attachment; filename=nc.p Content-Type: text/plain; name=nc.p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 2610-bk1/net/sched/sch_generic.c 2005/01/05 01:21:04 1.1 +++ 2610-bk1/net/sched/sch_generic.c 2005/01/05 01:36:26 @@ -152,7 +152,7 @@ spin_lock(&dev->queue_lock); goto collision; } - } + } /* NETDEV_TX_BUSY - we need to requeue */ /* Release the driver */ @@ -162,6 +162,11 @@ } spin_lock(&dev->queue_lock); q = dev->qdisc; + if (!netif_carrier_ok(dev)) { + kfree_skb(skb); + q->qstats.drops++; + return -1; + } } /* Device kicked us out :( --=-0846Th3rEGC6QKddUtsg-- From imipak@yahoo.com Tue Jan 4 08:00:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 08:00:19 -0800 (PST) Received: from web12303.mail.yahoo.com (web12303.mail.yahoo.com [216.136.173.101]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j04FxrMC006486 for ; Tue, 4 Jan 2005 08:00:13 -0800 Received: (qmail 38740 invoked by uid 60001); 5 Jan 2005 03:59:46 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=xdOT+6FehLtWodBHcdQK7bJ1yfD/vwQW5NOfBNFMkxfV9O2MV9gZCtggTkp9E4y6fCb5lqEZg7fF/LiGpqoJaYE4bUIQmjLbGb3Pj6tZJM+KieveNoG40vPg6vLikeerP8sep3muEqkepiABWuA1Kqn45llQUNCbCvxd7a/PATg= ; Message-ID: <20050105035946.38738.qmail@web12303.mail.yahoo.com> Received: from [65.102.7.124] by web12303.mail.yahoo.com via HTTP; Tue, 04 Jan 2005 19:59:46 PST Date: Tue, 4 Jan 2005 19:59:46 -0800 (PST) From: Jonathan Day Subject: Re: [LARTC] Scheduler Mechnisms! To: Zhenyu Wu , netdev@oss.sgi.com Cc: lartc@mailman.ds9a.nl In-Reply-To: <304889647.25037@njupt.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imipak@yahoo.com Precedence: bulk X-list: netdev I may be wrong on this, but I believe that RED can be attached to any queueing system, including the basic FIFO queues. In a sense, you're still using a scheduling system, when using the default arrangement, it's just a first-come, first-served one. RED is classless and applies to the whole of a queue. What that queue is attached to, if I understand it correctly, isn't important. It can be a class, but it can just as easily be everything going through that device. Again, someone correct me if I'm wrong, but as I understand it, there are four levels to the whole QoS/diffserv concept. One of these levels is the queueing discipline. This can be something like CBQ, WFQ, FIFO, PRIO, or whatever. This is how the data is organized, it does not describe how the data is sent. In the case of something like CBQ, you have a defined set of queues in parallel, with rules as to what packets fall into what queue. On the other hand, queueing schemes such as FIFO are flat. There's a single queue that everything goes through, though there may be different rules for how things get pushed to it. Another level is the scheduling mechanism. This describes how the data is sent, once organized, but does not describe the organization itself. If you've only one queue, then there's really not much to schedule. If you've multiple queues, then it's fairly normal to use "round robin" or "weighted round robin" to pick which queue to pull a packet from. Linux' CBQ uses "weighted round robin", according to the C file. The next level is the packet dropping mechanism. When queues flood, packets are going to be dropped. There's nowhere to store them. I'm pretty sure the default behaviour is to simply continue accepting packets, but to drop any that expire before being sent or which fall off the end of the queue (if the queue is bounded). RED, GRED, and a whole host of similar mechanisms, try to drop packets in a more controlled manner. However, that is really all they do. Finally, there are mechanisms for damping overly active applications, such as ECN. The idea here is that if you throttle back whatever is generating excess traffic, you don't get the problems assoicated with dealing with it. The "default" behaviour is to do nothing. When setting up QoS - on Linux or anything else - you basically pick one of each of the four categories to assemble a packet delivery system. Even without QoS, you're doing that, you're just using the defaults in all cases. The mechanisms are still going to be there. The Linux configuration menu does NOT match the above terminology, or the terminology in the source code. Thus, the source code identifies CBQ as a queueing discipline, but the configuration menu calls it a scheduler. The QoS help is also not very helpful, as it mostly tells people to look at the source. However, if you look at the source for CBQ or RED, for example, the explanation is relative to the cited papers, so you then have to go and read those before coming back and doing anything. This is one area I hope is going to get resolved in the reasonably near future. If not, I might have to come up with a patch myself. The very thought of that should send shivers down the spines of any kernel developers out there. Jonathan --- Zhenyu Wu wrote: > Thank you very much, i will try to find these papers > which must be very helpful > for me. The "more" means that whether there are > other mechanisms not only for > Linux. Sorry, i have not make it clear! Sometimes, i > wonder whether the qdiscs > such as CBQ, RED, GRED ... are belong to the > scheduler mechanisms in linux > enviroment. For example, In Red, which i can find > are enqueue, and dequeue.... so, > if i add a RED qidsc to a class, must i add a > scheduler mechanism so that i can > decide which packet in the queues will be scheduled > and put to the link? > > Good luck, > Best, __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From akpm@osdl.org Tue Jan 4 09:59:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:03 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04Hxalj016045 for ; Tue, 4 Jan 2005 09:59:56 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j055xL614574; Tue, 4 Jan 2005 21:59:21 -0800 Date: Tue, 4 Jan 2005 21:59:13 -0800 From: Andrew Morton To: Jeff Garzik , "David S. Miller" Cc: netdev@oss.sgi.com Subject: net patches Message-Id: <20050104215913.274e6567.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev I'll unload some accumulated net patches. I can't say that I've looked at them very closely. From akpm@osdl.org Tue Jan 4 10:00:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:31 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04Hxui9016054 for ; Tue, 4 Jan 2005 10:00:16 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xh614717; Tue, 4 Jan 2005 21:59:43 -0800 Message-Id: <200501050559.j055xh614717@mail.osdl.org> Subject: [patch 08/10] r8169: reduce max MTU for large frames To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, romieu@fr.zoreil.com From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:34 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Francois Romieu The device does not support the whole mtu range it claims. Experimenting with the Tx threshold and/or the PCI burst size does not seem to improve the behavior. Signed-off-by: Francois Romieu Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/r8169.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff -puN drivers/net/r8169.c~r8169-reduce-max-mtu-for-large-frames drivers/net/r8169.c --- 25/drivers/net/r8169.c~r8169-reduce-max-mtu-for-large-frames 2005-01-04 21:57:36.322612408 -0800 +++ 25-akpm/drivers/net/r8169.c 2005-01-04 21:57:44.698339104 -0800 @@ -112,7 +112,8 @@ static int multicast_filter_limit = 32; #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ -#define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC */ +#define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC... */ +#define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ #define R8169_REGS_SIZE 256 @@ -1593,7 +1594,7 @@ static int rtl8169_change_mtu(struct net struct rtl8169_private *tp = netdev_priv(dev); int ret = 0; - if (new_mtu < ETH_ZLEN || new_mtu > RxPacketMaxSize) + if (new_mtu < ETH_ZLEN || new_mtu > SafeMtu) return -EINVAL; dev->mtu = new_mtu; _ From akpm@osdl.org Tue Jan 4 10:00:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:16 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04HxnQr016047 for ; Tue, 4 Jan 2005 10:00:09 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xZ614657; Tue, 4 Jan 2005 21:59:35 -0800 Message-Id: <200501050559.j055xZ614657@mail.osdl.org> Subject: [patch 01/10] xircom_tulip_cb.c build fix To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, bero@arklinux.org, bunk@stusta.de From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:26 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Bernhard Rosenkraenzer , Adrian Bunk - Define `debug' before using it. - remove now-unneeded module_parm_array hack. Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/tulip/xircom_tulip_cb.c | 19 +++++++++---------- 1 files changed, 9 insertions(+), 10 deletions(-) diff -puN drivers/net/tulip/xircom_tulip_cb.c~xircom_tulip_cb-build-fix drivers/net/tulip/xircom_tulip_cb.c --- 25/drivers/net/tulip/xircom_tulip_cb.c~xircom_tulip_cb-build-fix 2005-01-04 21:54:38.251683304 -0800 +++ 25-akpm/drivers/net/tulip/xircom_tulip_cb.c 2005-01-04 21:54:41.815141576 -0800 @@ -33,6 +33,13 @@ /* A few user-configurable values. */ +#define xircom_debug debug +#ifdef XIRCOM_DEBUG +static int xircom_debug = XIRCOM_DEBUG; +#else +static int xircom_debug = 1; +#endif + /* Maximum events (Rx packets, etc.) to handle at each interrupt. */ static int max_interrupt_work = 25; @@ -124,19 +131,11 @@ module_param(max_interrupt_work, int, 0) module_param(rx_copybreak, int, 0); module_param(csr0, int, 0); -static int num_units; -module_param_array(options, num_units, int, 0); -module_param_array(full_duplex, num_units, int, 0); +module_param_array(options, int, NULL, 0); +module_param_array(full_duplex, int, NULL, 0); #define RUN_AT(x) (jiffies + (x)) -#define xircom_debug debug -#ifdef XIRCOM_DEBUG -static int xircom_debug = XIRCOM_DEBUG; -#else -static int xircom_debug = 1; -#endif - /* Theory of Operation _ From akpm@osdl.org Tue Jan 4 10:00:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:32 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04Hxvhm016055 for ; Tue, 4 Jan 2005 10:00:18 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xi614722; Tue, 4 Jan 2005 21:59:44 -0800 Message-Id: <200501050559.j055xi614722@mail.osdl.org> Subject: [patch 09/10] r8169: oversized driver field for ethtool To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, romieu@fr.zoreil.com, rich@phekda.gotadsl.co.uk From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:35 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Francois Romieu Reported by Richard Dawe : - RTL8169_DRIVER_NAME contains more than the 32 characters allowed for the driver field; - remove RTL8169_DRIVER_NAME as it is only used once. Signed-off-by: Francois Romieu Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/r8169.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff -puN drivers/net/r8169.c~r8169-oversized-driver-field-for-ethtool drivers/net/r8169.c --- 25/drivers/net/r8169.c~r8169-oversized-driver-field-for-ethtool 2005-01-04 21:57:36.451592800 -0800 +++ 25-akpm/drivers/net/r8169.c 2005-01-04 21:57:36.455592192 -0800 @@ -63,7 +63,6 @@ VERSION 1.6LK <2004/04/14> #define RTL8169_VERSION "1.6LK" #define MODULENAME "r8169" -#define RTL8169_DRIVER_NAME MODULENAME " Gigabit Ethernet driver " RTL8169_VERSION #define PFX MODULENAME ": " #ifdef RTL8169_DEBUG @@ -564,8 +563,8 @@ static void rtl8169_get_drvinfo(struct n { struct rtl8169_private *tp = netdev_priv(dev); - strcpy(info->driver, RTL8169_DRIVER_NAME); - strcpy(info->version, RTL8169_VERSION ); + strcpy(info->driver, MODULENAME); + strcpy(info->version, RTL8169_VERSION); strcpy(info->bus_info, pci_name(tp->pci_dev)); } @@ -1282,7 +1281,8 @@ rtl8169_init_one(struct pci_dev *pdev, c board_idx++; if (!printed_version) { - printk(KERN_INFO RTL8169_DRIVER_NAME " loaded\n"); + printk(KERN_INFO "%s Gigabit Ethernet driver %s loaded\n", + MODULENAME, RTL8169_VERSION); printed_version = 1; } _ From akpm@osdl.org Tue Jan 4 10:00:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:19 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04Hxpck016050 for ; Tue, 4 Jan 2005 10:00:12 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xb614676; Tue, 4 Jan 2005 21:59:37 -0800 Message-Id: <200501050559.j055xb614676@mail.osdl.org> Subject: [patch 03/10] pcnet32: 79c976 with fiber optic fix To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, agx@sigxcpu.org, lars@segv.dk From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:28 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Guido Guenther , Lars Munch Skip PHY selection on Allied Telesyn 2701FX, it looses the link otherwise. Fix up the AT 2701 as well. Signed-Off-By: Guido Guenther Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/pcnet32.c | 47 ++++++++++++++++++++++++---------------- 25-akpm/include/linux/pci_ids.h | 5 ++++ 2 files changed, 34 insertions(+), 18 deletions(-) diff -puN drivers/net/pcnet32.c~pcnet32-79c976-with-fiber-optic drivers/net/pcnet32.c --- 25/drivers/net/pcnet32.c~pcnet32-79c976-with-fiber-optic 2005-01-04 21:57:35.666712120 -0800 +++ 25-akpm/drivers/net/pcnet32.c 2005-01-04 21:57:35.673711056 -0800 @@ -1429,25 +1429,36 @@ pcnet32_open(struct net_device *dev) val |= 0x10; lp->a.write_csr (ioaddr, 124, val); - /* 24 Jun 2004 according AMD, in order to change the PHY, - * DANAS (or DISPM for 79C976) must be set; then select the speed, - * duplex, and/or enable auto negotiation, and clear DANAS */ - if (lp->mii && !(lp->options & PCNET32_PORT_ASEL)) { - lp->a.write_bcr(ioaddr, 32, lp->a.read_bcr(ioaddr, 32) | 0x0080); - /* disable Auto Negotiation, set 10Mpbs, HD */ - val = lp->a.read_bcr(ioaddr, 32) & ~0xb8; - if (lp->options & PCNET32_PORT_FD) - val |= 0x10; - if (lp->options & PCNET32_PORT_100) - val |= 0x08; - lp->a.write_bcr (ioaddr, 32, val); + /* Allied Telesyn AT 2700/2701 FX looses the link, so skip that */ + if (lp->pci_dev->subsystem_vendor == PCI_VENDOR_ID_AT && + (lp->pci_dev->subsystem_device == PCI_SUBDEVICE_ID_AT_2700FX || + lp->pci_dev->subsystem_device == PCI_SUBDEVICE_ID_AT_2701FX)) { + printk(KERN_DEBUG "pcnet32: Skipping PHY selection.\n"); } else { - if (lp->options & PCNET32_PORT_ASEL) { - lp->a.write_bcr(ioaddr, 32, lp->a.read_bcr(ioaddr, 32) | 0x0080); - /* enable auto negotiate, setup, disable fd */ - val = lp->a.read_bcr(ioaddr, 32) & ~0x98; - val |= 0x20; - lp->a.write_bcr(ioaddr, 32, val); + /* + * 24 Jun 2004 according AMD, in order to change the PHY, + * DANAS (or DISPM for 79C976) must be set; then select the speed, + * duplex, and/or enable auto negotiation, and clear DANAS + */ + if (lp->mii && !(lp->options & PCNET32_PORT_ASEL)) { + lp->a.write_bcr(ioaddr, 32, + lp->a.read_bcr(ioaddr, 32) | 0x0080); + /* disable Auto Negotiation, set 10Mpbs, HD */ + val = lp->a.read_bcr(ioaddr, 32) & ~0xb8; + if (lp->options & PCNET32_PORT_FD) + val |= 0x10; + if (lp->options & PCNET32_PORT_100) + val |= 0x08; + lp->a.write_bcr (ioaddr, 32, val); + } else { + if (lp->options & PCNET32_PORT_ASEL) { + lp->a.write_bcr(ioaddr, 32, + lp->a.read_bcr(ioaddr, 32) | 0x0080); + /* enable auto negotiate, setup, disable fd */ + val = lp->a.read_bcr(ioaddr, 32) & ~0x98; + val |= 0x20; + lp->a.write_bcr(ioaddr, 32, val); + } } } diff -puN include/linux/pci_ids.h~pcnet32-79c976-with-fiber-optic include/linux/pci_ids.h --- 25/include/linux/pci_ids.h~pcnet32-79c976-with-fiber-optic 2005-01-04 21:57:35.669711664 -0800 +++ 25-akpm/include/linux/pci_ids.h 2005-01-04 21:57:35.676710600 -0800 @@ -1644,6 +1644,11 @@ #define PCI_DEVICE_ID_OPTIBASE_VPLEXCC 0x2120 #define PCI_DEVICE_ID_OPTIBASE_VQUEST 0x2130 +/* Allied Telesyn */ +#define PCI_VENDOR_ID_AT 0x1259 +#define PCI_SUBDEVICE_ID_AT_2700FX 0x2701 +#define PCI_SUBDEVICE_ID_AT_2701FX 0x2703 + #define PCI_VENDOR_ID_ESS 0x125d #define PCI_DEVICE_ID_ESS_ESS1968 0x1968 #define PCI_DEVICE_ID_ESS_AUDIOPCI 0x1969 _ From akpm@osdl.org Tue Jan 4 10:00:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:17 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04Hxov6016048 for ; Tue, 4 Jan 2005 10:00:10 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xa614669; Tue, 4 Jan 2005 21:59:36 -0800 Message-Id: <200501050559.j055xa614669@mail.osdl.org> Subject: [patch 02/10] net: Netconsole poll support for 3c509 To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, kernel@kolivas.org From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:27 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Con Kolivas This patch provides poll support to allow netconsole to work with 3c509 network cards. Status: Compiled, debugged and tested working by Michael Buesch. Signed-off-by: Con Kolivas Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/3c509.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+) diff -puN drivers/net/3c509.c~net-netconsole-poll-support-for-3c509 drivers/net/3c509.c --- 25/drivers/net/3c509.c~net-netconsole-poll-support-for-3c509 2005-01-04 21:57:35.537731728 -0800 +++ 25-akpm/drivers/net/3c509.c 2005-01-04 21:57:35.542730968 -0800 @@ -209,6 +209,9 @@ static int el3_pm_callback(struct pm_dev #if defined(CONFIG_EISA) || defined(CONFIG_MCA) static int el3_device_remove (struct device *device); #endif +#ifdef CONFIG_NET_POLL_CONTROLLER +static void el3_poll_controller(struct net_device *dev); +#endif #ifdef CONFIG_EISA struct eisa_device_id el3_eisa_ids[] = { @@ -321,6 +324,9 @@ static int __init el3_common_init(struct dev->set_multicast_list = &set_multicast_list; dev->tx_timeout = el3_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller = el3_poll_controller; +#endif SET_ETHTOOL_OPS(dev, ðtool_ops); err = register_netdev(dev); @@ -999,6 +1005,19 @@ el3_interrupt(int irq, void *dev_id, str } +#ifdef CONFIG_NET_POLL_CONTROLLER +/* + * Polling receive - used by netconsole and other diagnostic tools + * to allow network i/o with interrupts disabled. + */ +static void el3_poll_controller(struct net_device *dev) +{ + disable_irq(dev->irq); + el3_interrupt(dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif + static struct net_device_stats * el3_get_stats(struct net_device *dev) { _ From akpm@osdl.org Tue Jan 4 10:00:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:33 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04HxwEP016056 for ; Tue, 4 Jan 2005 10:00:18 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xf614691; Tue, 4 Jan 2005 21:59:41 -0800 Message-Id: <200501050559.j055xf614691@mail.osdl.org> Subject: [patch 06/10] r8169: C 101 To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, romieu@fr.zoreil.com From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:32 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Francois Romieu Back to C101 and code which gives the expected result. Signed-off-by: Francois Romieu Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-c-101 drivers/net/r8169.c --- 25/drivers/net/r8169.c~r8169-c-101 2005-01-04 21:57:36.066651320 -0800 +++ 25-akpm/drivers/net/r8169.c 2005-01-04 21:57:44.966298368 -0800 @@ -1979,7 +1979,7 @@ static void rtl8169_pcierr_interrupt(str PCI_STATUS_REC_TARGET_ABORT | PCI_STATUS_SIG_TARGET_ABORT)); /* The infamous DAC f*ckup only happens at boot time */ - if ((tp->cp_cmd & PCIDAC) && (tp->dirty_rx == tp->cur_rx == 0)) { + if ((tp->cp_cmd & PCIDAC) && !tp->dirty_rx && !tp->cur_rx) { printk(KERN_INFO PFX "%s: disabling PCI DAC.\n", dev->name); tp->cp_cmd &= ~PCIDAC; RTL_W16(CPlusCmd, tp->cp_cmd); _ From akpm@osdl.org Tue Jan 4 10:00:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:33 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04HxtML016052 for ; Tue, 4 Jan 2005 10:00:16 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xg614698; Tue, 4 Jan 2005 21:59:42 -0800 Message-Id: <200501050559.j055xg614698@mail.osdl.org> Subject: [patch 07/10] r8169: Large Send enablement To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, romieu@fr.zoreil.com, jdmason@us.ibm.com From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:33 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Francois Romieu Large Send enablement. Acked-by: Francois Romieu Signed-off-by: Jon Mason Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/r8169.c | 80 ++++++++++++++++++++++++++++++++++++-------- 1 files changed, 67 insertions(+), 13 deletions(-) diff -puN drivers/net/r8169.c~r8169-large-send-enablement drivers/net/r8169.c --- 25/drivers/net/r8169.c~r8169-large-send-enablement 2005-01-04 21:57:36.194631864 -0800 +++ 25-akpm/drivers/net/r8169.c 2005-01-04 21:57:44.830319040 -0800 @@ -112,7 +112,7 @@ static int multicast_filter_limit = 32; #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ -#define RxPacketMaxSize 0x0800 /* Maximum size supported is 16K-1 */ +#define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC */ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ #define R8169_REGS_SIZE 256 @@ -427,6 +427,9 @@ static void rtl8169_tx_timeout(struct ne static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *, void __iomem *); +static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu); +static void rtl8169_down(struct net_device *dev); + #ifdef CONFIG_R8169_NAPI static int rtl8169_poll(struct net_device *dev, int *budget); #endif @@ -1238,8 +1241,6 @@ rtl8169_init_board(struct pci_dev *pdev, } tp->chipset = i; - tp->rx_buf_sz = RX_BUF_SIZE; - *ioaddr_out = ioaddr; *dev_out = dev; out: @@ -1321,6 +1322,7 @@ rtl8169_init_one(struct pci_dev *pdev, c dev->watchdog_timeo = RTL8169_TX_TIMEOUT; dev->irq = pdev->irq; dev->base_addr = (unsigned long) ioaddr; + dev->change_mtu = rtl8169_change_mtu; #ifdef CONFIG_R8169_NAPI dev->poll = rtl8169_poll; @@ -1449,13 +1451,22 @@ static int rtl8169_resume(struct pci_dev #endif /* CONFIG_PM */ -static int -rtl8169_open(struct net_device *dev) +static void rtl8169_set_rxbufsize(struct rtl8169_private *tp, + struct net_device *dev) +{ + unsigned int mtu = dev->mtu; + + tp->rx_buf_sz = (mtu > RX_BUF_SIZE) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE; +} + +static int rtl8169_open(struct net_device *dev) { struct rtl8169_private *tp = netdev_priv(dev); struct pci_dev *pdev = tp->pci_dev; int retval; + rtl8169_set_rxbufsize(tp, dev); + retval = request_irq(dev->irq, rtl8169_interrupt, SA_SHIRQ, dev->name, dev); if (retval < 0) @@ -1535,8 +1546,8 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); RTL_W8(EarlyTxThres, EarlyTxThld); - // For gigabit rtl8169 - RTL_W16(RxMaxSize, RxPacketMaxSize); + // For gigabit rtl8169, MTU + header + CRC + VLAN + RTL_W16(RxMaxSize, tp->rx_buf_sz); // Set Rx Config register i = rtl8169_rx_config | @@ -1577,6 +1588,37 @@ rtl8169_hw_start(struct net_device *dev) netif_start_queue(dev); } +static int rtl8169_change_mtu(struct net_device *dev, int new_mtu) +{ + struct rtl8169_private *tp = netdev_priv(dev); + int ret = 0; + + if (new_mtu < ETH_ZLEN || new_mtu > RxPacketMaxSize) + return -EINVAL; + + dev->mtu = new_mtu; + + if (!netif_running(dev)) + goto out; + + rtl8169_down(dev); + + rtl8169_set_rxbufsize(tp, dev); + + ret = rtl8169_init_ring(dev); + if (ret < 0) + goto out; + + rtl8169_hw_start(dev); + + netif_poll_enable(dev); + + rtl8169_request_timer(dev); + +out: + return ret; +} + static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc) { desc->addr = 0x0badbadbadbadbadull; @@ -2265,19 +2307,17 @@ static int rtl8169_poll(struct net_devic } #endif -static int -rtl8169_close(struct net_device *dev) +static void rtl8169_down(struct net_device *dev) { struct rtl8169_private *tp = netdev_priv(dev); - struct pci_dev *pdev = tp->pci_dev; void __iomem *ioaddr = tp->mmio_addr; + rtl8169_delete_timer(dev); + netif_stop_queue(dev); flush_scheduled_work(); - rtl8169_delete_timer(dev); - spin_lock_irq(&tp->lock); /* Stop the chip's Tx and Rx DMA processes. */ @@ -2292,13 +2332,27 @@ rtl8169_close(struct net_device *dev) spin_unlock_irq(&tp->lock); - free_irq(dev->irq, dev); + synchronize_irq(dev->irq); netif_poll_disable(dev); + /* Give a racing hard_start_xmit a few cycles to complete. */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(1); + rtl8169_tx_clear(tp); rtl8169_rx_clear(tp); +} + +static int rtl8169_close(struct net_device *dev) +{ + struct rtl8169_private *tp = netdev_priv(dev); + struct pci_dev *pdev = tp->pci_dev; + + rtl8169_down(dev); + + free_irq(dev->irq, dev); pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray, tp->RxPhyAddr); _ From akpm@osdl.org Tue Jan 4 10:00:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:37 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04I03t6016065 for ; Tue, 4 Jan 2005 10:00:23 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xe614686; Tue, 4 Jan 2005 21:59:40 -0800 Message-Id: <200501050559.j055xe614686@mail.osdl.org> Subject: [patch 05/10] r8169: missing netif_poll_enable and irq ack To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, romieu@fr.zoreil.com From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:31 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Francois Romieu - (noticed by Jon D. Mason) rtl8169_wait_for_quiescence() needs to disable the NAPI processing but it has no reason to lock any part of the driver which would try to do the same at a later time. Let's reenable NAPI processing as soon as possible. - properly ack any aborted interruption: a reset of the device is not always enough. Signed-off-by: Francois Romieu Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/r8169.c | 9 +++++++++ 1 files changed, 9 insertions(+) diff -puN drivers/net/r8169.c~r8169-missing-netif_poll_enable-and-irq-ack drivers/net/r8169.c --- 25/drivers/net/r8169.c~r8169-missing-netif_poll_enable-and-irq-ack 2005-01-04 21:57:35.938670776 -0800 +++ 25-akpm/drivers/net/r8169.c 2005-01-04 21:57:45.096278608 -0800 @@ -1743,10 +1743,19 @@ static void rtl8169_schedule_work(struct static void rtl8169_wait_for_quiescence(struct net_device *dev) { + struct rtl8169_private *tp = netdev_priv(dev); + void __iomem *ioaddr = tp->mmio_addr; + synchronize_irq(dev->irq); /* Wait for any pending NAPI task to complete */ netif_poll_disable(dev); + + RTL_W16(IntrMask, 0x0000); + + RTL_W16(IntrStatus, 0xffff); + + netif_poll_enable(dev); } static void rtl8169_reinit_task(void *_data) _ From akpm@osdl.org Tue Jan 4 10:00:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:38 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04I02j9016063 for ; Tue, 4 Jan 2005 10:00:22 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xc614681; Tue, 4 Jan 2005 21:59:38 -0800 Message-Id: <200501050559.j055xc614681@mail.osdl.org> Subject: [patch 04/10] Multicast filtering for tun.c To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, sjackman@gmail.com From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:30 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Shaun Jackman This patch adds multicast filtering to the TUN network driver, for packets being sent from the network device to the character device. * drivers/net/tun.c: Add multicast filtering for packets travelling from the network device to the character device. * include/linux/if_tun.h (tun_struct): Add interface flags, a hardware device addres, and a multicast filter. Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/tun.c | 151 +++++++++++++++++++++++++++++++++++++---- 25-akpm/include/linux/if_tun.h | 5 + 2 files changed, 144 insertions(+), 12 deletions(-) diff -puN drivers/net/tun.c~multicast-filtering-for-tunc drivers/net/tun.c --- 25/drivers/net/tun.c~multicast-filtering-for-tunc 2005-01-04 21:57:35.804691144 -0800 +++ 25-akpm/drivers/net/tun.c 2005-01-04 21:57:35.810690232 -0800 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -104,11 +105,42 @@ drop: return 0; } -static void tun_net_mclist(struct net_device *dev) +/** Add the specified Ethernet address to this multicast filter. */ +static void +add_multi(u32* filter, const u8* addr) { - /* Nothing to do for multicast filters. - * We always accept all frames. */ - return; + int bit_nr = ether_crc(ETH_ALEN, addr) >> 26; + filter[bit_nr >> 5] |= 1 << (bit_nr & 31); +} + +/** Remove the specified Ethernet addres from this multicast filter. */ +static void +del_multi(u32* filter, const u8* addr) +{ + int bit_nr = ether_crc(ETH_ALEN, addr) >> 26; + filter[bit_nr >> 5] &= ~(1 << (bit_nr & 31)); +} + +/** Update the list of multicast groups to which the network device belongs. + * This list is used to filter packets being sent from the character device to + * the network device. */ +static void +tun_net_mclist(struct net_device *dev) +{ + struct tun_struct *tun = netdev_priv(dev); + const struct dev_mc_list *mclist; + int i; + DBG(KERN_DEBUG "%s: tun_net_mclist: mc_count %d\n", + dev->name, dev->mc_count); + memset(tun->chr_filter, 0, sizeof tun->chr_filter); + for (i = 0, mclist = dev->mc_list; i < dev->mc_count && mclist != NULL; + i++, mclist = mclist->next) { + add_multi(tun->net_filter, mclist->dmi_addr); + DBG(KERN_DEBUG "%s: tun_net_mclist: %x:%x:%x:%x:%x:%x\n", + dev->name, + mclist->dmi_addr[0], mclist->dmi_addr[1], mclist->dmi_addr[2], + mclist->dmi_addr[3], mclist->dmi_addr[4], mclist->dmi_addr[5]); + } } static struct net_device_stats *tun_net_stats(struct net_device *dev) @@ -301,6 +333,10 @@ static ssize_t tun_chr_readv(struct file add_wait_queue(&tun->read_wait, &wait); while (len) { + const u8 ones[ ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; + u8 addr[ ETH_ALEN]; + int bit_nr; + current->state = TASK_INTERRUPTIBLE; /* Read frames from the queue */ @@ -320,10 +356,37 @@ static ssize_t tun_chr_readv(struct file } netif_start_queue(tun->dev); - ret = tun_put_user(tun, skb, (struct iovec *) iv, len); - - kfree_skb(skb); - break; + /** Decide whether to accept this packet. This code is designed to + * behave identically to an Ethernet interface. Accept the packet if + * - we are promiscuous. + * - the packet is addressed to us. + * - the packet is broadcast. + * - the packet is multicast and + * - we are multicast promiscous. + * - we belong to the multicast group. + */ + memcpy(addr, skb->data, min(sizeof addr, skb->len)); + bit_nr = ether_crc(sizeof addr, addr) >> 26; + if ((tun->if_flags & IFF_PROMISC) || + memcmp(addr, tun->dev_addr, sizeof addr) == 0 || + memcmp(addr, ones, sizeof addr) == 0 || + (((addr[0] == 1 && addr[1] == 0 && addr[2] == 0x5e) || + (addr[0] == 0x33 && addr[1] == 0x33)) && + ((tun->if_flags & IFF_ALLMULTI) || + (tun->chr_filter[bit_nr >> 5] & (1 << (bit_nr & 31)))))) { + DBG(KERN_DEBUG "%s: tun_chr_readv: accepted: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + ret = tun_put_user(tun, skb, (struct iovec *) iv, len); + kfree_skb(skb); + break; + } else { + DBG(KERN_DEBUG "%s: tun_chr_readv: rejected: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + kfree_skb(skb); + continue; + } } current->state = TASK_RUNNING; @@ -417,6 +480,12 @@ static int tun_set_iff(struct file *file tun = netdev_priv(dev); tun->dev = dev; tun->flags = flags; + /* Be promiscuous by default to maintain previous behaviour. */ + tun->if_flags = IFF_PROMISC; + /* Generate random Ethernet address. */ + *(u16 *)tun->dev_addr = htons(0x00FF); + get_random_bytes(tun->dev_addr + sizeof(u16), 4); + memset(tun->chr_filter, 0, sizeof tun->chr_filter); tun_net_init(dev); @@ -457,13 +526,16 @@ static int tun_chr_ioctl(struct inode *i unsigned int cmd, unsigned long arg) { struct tun_struct *tun = file->private_data; + void __user* argp = (void __user*)arg; + struct ifreq ifr; + + if (cmd == TUNSETIFF || _IOC_TYPE(cmd) == 0x89) + if (copy_from_user(&ifr, argp, sizeof ifr)) + return -EFAULT; if (cmd == TUNSETIFF && !tun) { - struct ifreq ifr; int err; - if (copy_from_user(&ifr, (void __user *)arg, sizeof(ifr))) - return -EFAULT; ifr.ifr_name[IFNAMSIZ-1] = '\0'; rtnl_lock(); @@ -473,7 +545,7 @@ static int tun_chr_ioctl(struct inode *i if (err) return err; - if (copy_to_user((void __user *)arg, &ifr, sizeof(ifr))) + if (copy_to_user(argp, &ifr, sizeof(ifr))) return -EFAULT; return 0; } @@ -519,6 +591,61 @@ static int tun_chr_ioctl(struct inode *i break; #endif + case SIOCGIFFLAGS: + ifr.ifr_flags = tun->if_flags; + if (copy_to_user( argp, &ifr, sizeof ifr)) + return -EFAULT; + return 0; + + case SIOCSIFFLAGS: + /** Set the character device's interface flags. Currently only + * IFF_PROMISC and IFF_ALLMULTI are used. */ + tun->if_flags = ifr.ifr_flags; + DBG(KERN_INFO "%s: interface flags 0x%lx\n", + tun->dev->name, tun->if_flags); + return 0; + + case SIOCGIFHWADDR: + memcpy(ifr.ifr_hwaddr.sa_data, tun->dev_addr, + min(sizeof ifr.ifr_hwaddr.sa_data, sizeof tun->dev_addr)); + if (copy_to_user( argp, &ifr, sizeof ifr)) + return -EFAULT; + return 0; + + case SIOCSIFHWADDR: + /** Set the character device's hardware address. This is used when + * filtering packets being sent from the network device to the character + * device. */ + memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data, + min(sizeof ifr.ifr_hwaddr.sa_data, sizeof tun->dev_addr)); + DBG(KERN_DEBUG "%s: set hardware address: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + tun->dev_addr[0], tun->dev_addr[1], tun->dev_addr[2], + tun->dev_addr[3], tun->dev_addr[4], tun->dev_addr[5]); + return 0; + + case SIOCADDMULTI: + /** Add the specified group to the character device's multicast filter + * list. */ + add_multi(tun->chr_filter, ifr.ifr_hwaddr.sa_data); + DBG(KERN_DEBUG "%s: add multi: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); + return 0; + + case SIOCDELMULTI: + /** Remove the specified group from the character device's multicast + * filter list. */ + del_multi(tun->chr_filter, ifr.ifr_hwaddr.sa_data); + DBG(KERN_DEBUG "%s: del multi: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); + return 0; + default: return -EINVAL; }; diff -puN include/linux/if_tun.h~multicast-filtering-for-tunc include/linux/if_tun.h --- 25/include/linux/if_tun.h~multicast-filtering-for-tunc 2005-01-04 21:57:35.805690992 -0800 +++ 25-akpm/include/linux/if_tun.h 2005-01-04 21:57:35.810690232 -0800 @@ -45,6 +45,11 @@ struct tun_struct { struct fasync_struct *fasync; + unsigned long if_flags; + u8 dev_addr[ETH_ALEN]; + u32 chr_filter[2]; + u32 net_filter[2]; + #ifdef TUN_DEBUG int debug; #endif _ From akpm@osdl.org Tue Jan 4 10:00:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:00:41 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04I08ZW016078 for ; Tue, 4 Jan 2005 10:00:28 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j055xj614727; Tue, 4 Jan 2005 21:59:45 -0800 Message-Id: <200501050559.j055xj614727@mail.osdl.org> Subject: [patch 10/10] EMAC: fix ibm_emac autonegotiation result parsing To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, akpm@osdl.org, mporter@kernel.crashing.org, ebs@ebshome.net From: akpm@osdl.org Date: Tue, 04 Jan 2005 21:59:36 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Matt Porter Fix aneg result parsing in ibm_emac driver. Signed-off-by: Eugene Surovegin Signed-off-by: Matt Porter Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/ibm_emac/ibm_emac_phy.c | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff -puN drivers/net/ibm_emac/ibm_emac_phy.c~fix-ibm_emac-autonegotiation-result-parsing drivers/net/ibm_emac/ibm_emac_phy.c --- 25/drivers/net/ibm_emac/ibm_emac_phy.c~fix-ibm_emac-autonegotiation-result-parsing 2005-01-04 21:57:36.578573496 -0800 +++ 25-akpm/drivers/net/ibm_emac/ibm_emac_phy.c 2005-01-04 21:57:36.581573040 -0800 @@ -191,17 +191,18 @@ static int genmii_read_link(struct mii_p u16 lpa; if (phy->autoneg) { - lpa = phy_read(phy, MII_LPA); + lpa = phy_read(phy, MII_LPA) & phy_read(phy, MII_ADVERTISE); - if (lpa & (LPA_10FULL | LPA_100FULL)) - phy->duplex = DUPLEX_FULL; - else - phy->duplex = DUPLEX_HALF; - if (lpa & (LPA_100FULL | LPA_100HALF)) - phy->speed = SPEED_100; - else - phy->speed = SPEED_10; + phy->speed = SPEED_10; + phy->duplex = DUPLEX_HALF; phy->pause = 0; + + if (lpa & (LPA_100FULL | LPA_100HALF)) { + phy->speed = SPEED_100; + if (lpa & LPA_100FULL) + phy->duplex = DUPLEX_FULL; + } else if (lpa & LPA_10FULL) + phy->duplex = DUPLEX_FULL; } /* On non-aneg, we assume what we put in BMCR is the speed, * though magic-aneg shouldn't prevent this case from occurring _ From akpm@osdl.org Tue Jan 4 10:02:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:02:24 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04I1u0o018289 for ; Tue, 4 Jan 2005 10:02:16 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j0561h615068; Tue, 4 Jan 2005 22:01:43 -0800 Message-Id: <200501050601.j0561h615068@mail.osdl.org> Subject: [patch 1/1] ixgb LR card support To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, akpm@osdl.org, aafes@psu.edu From: akpm@osdl.org Date: Tue, 04 Jan 2005 22:01:34 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev From: Phil Sorber This enables the ixgb driver to be used for LR cards as well. Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/ixgb/ixgb_hw.c | 1 + 25-akpm/drivers/net/ixgb/ixgb_ids.h | 1 + 25-akpm/drivers/net/ixgb/ixgb_main.c | 5 ++++- 3 files changed, 6 insertions(+), 1 deletion(-) diff -puN drivers/net/ixgb/ixgb_hw.c~ixgb-lr-card-support drivers/net/ixgb/ixgb_hw.c --- 25/drivers/net/ixgb/ixgb_hw.c~ixgb-lr-card-support 2004-11-22 20:33:33.912389136 -0800 +++ 25-akpm/drivers/net/ixgb/ixgb_hw.c 2004-11-22 20:33:33.920387920 -0800 @@ -198,6 +198,7 @@ static ixgb_phy_type ixgb_identify_phy(s break; case IXGB_DEVICE_ID_82597EX_SR: + case IXGB_DEVICE_ID_82597EX_LR: /* The SR adapters carry two different types of XPAK optics * modules; read the vendor identifier to determine the exact * type of optics. */ diff -puN drivers/net/ixgb/ixgb_ids.h~ixgb-lr-card-support drivers/net/ixgb/ixgb_ids.h --- 25/drivers/net/ixgb/ixgb_ids.h~ixgb-lr-card-support 2004-11-22 20:33:33.914388832 -0800 +++ 25-akpm/drivers/net/ixgb/ixgb_ids.h 2004-11-22 20:33:33.920387920 -0800 @@ -38,6 +38,7 @@ #define IXGB_DEVICE_ID_82597EX 0x1048 #define IXGB_DEVICE_ID_82597EX_SR 0x1A48 +#define IXGB_DEVICE_ID_82597EX_LR 0x1B48 #define IXGB_SUBDEVICE_ID_A11F 0xA11F #define IXGB_SUBDEVICE_ID_A01F 0xA01F diff -puN drivers/net/ixgb/ixgb_main.c~ixgb-lr-card-support drivers/net/ixgb/ixgb_main.c --- 25/drivers/net/ixgb/ixgb_main.c~ixgb-lr-card-support 2004-11-22 20:33:33.916388528 -0800 +++ 25-akpm/drivers/net/ixgb/ixgb_main.c 2004-11-22 20:33:33.922387616 -0800 @@ -46,6 +46,8 @@ static struct pci_device_id ixgb_pci_tbl PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {INTEL_VENDOR_ID, IXGB_DEVICE_ID_82597EX_SR, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {INTEL_VENDOR_ID, IXGB_DEVICE_ID_82597EX_LR, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* required last entry */ {0,} @@ -511,7 +513,8 @@ static int __devinit ixgb_sw_init(struct hw->max_frame_size = netdev->mtu + ENET_HEADER_SIZE + ENET_FCS_LENGTH; if ((hw->device_id == IXGB_DEVICE_ID_82597EX) - || (hw->device_id == IXGB_DEVICE_ID_82597EX_SR)) + || (hw->device_id == IXGB_DEVICE_ID_82597EX_SR) + || (hw->device_id == IXGB_DEVICE_ID_82597EX_LR)) hw->mac_type = ixgb_82597; else { /* should never have loaded on this device */ _ From paul@clubi.ie Tue Jan 4 10:28:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:28:48 -0800 (PST) Received: from hibernia.jakma.org (IDENT:U2FsdGVkX1/mC2+jilYpFQM9ggWyKSc+O21ghiOswKQ@hibernia.jakma.org [212.17.55.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04ISJQe022251 for ; Tue, 4 Jan 2005 10:28:40 -0800 Received: from hibernia.jakma.org (IDENT:U2FsdGVkX19RMg9cCxCWw42Z405+sYLrPghtd9J7QEg@hibernia.jakma.org [192.168.0.3]) by hibernia.jakma.org (8.13.1/8.12.11) with ESMTP id j056QXfN006795; Wed, 5 Jan 2005 06:26:33 GMT Date: Wed, 5 Jan 2005 06:26:32 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@hibernia.jakma.org To: Jeff Garzik cc: hadi@cyberus.ca, Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Tommy Christensen Subject: Re: [patch 4/10] s390: network driver. In-Reply-To: <41DB26A6.2070008@pobox.com> Message-ID: References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> Mail-Followup-To: paul@hibernia.jakma.org X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/634/Sun Dec 19 21:21:52 2004 clamav-milter version 0.80j on hibernia.jakma.org X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 13405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paul@clubi.ie Precedence: bulk X-list: netdev On Tue, 4 Jan 2005, Jeff Garzik wrote: > Aren't there cases where people would -not- want the queue to be > cleared? Why *do* you want the queue to be cleared? (avoiding NIC /dev/null is only reason right?) TCP (AIUI) has its owns means to resend. Most (all?) other transports have *never* had an expectation of such reliability. Applications *know* they have to provide their own reliability. Queueing and later sending (by then) stale packets is *bad* Think: - heartbeat applications - Router or route advertisements (IPv6 RA, IPv4 ICMP IRDP, RIP) - Streaming media (ok, not much damage here, but still there's simply no point queueing while link is down..) Why queue packets on behalf of applications which have no expectation of kernel doing this (any application expecting such is certainlty broken) and which very likely implement their own reliability or packet-loss recovery strategies? Particularly when queueing is quite possibly *detrimental* to what the application is trying to achieve (timely sending of packets). If an application wants reliable sending of packets, it will be using TCP.. > Jeff regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: When the speaker and he to whom he is speaks do not understand, that is metaphysics. -- Voltaire From paul@clubi.ie Tue Jan 4 10:30:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:31:03 -0800 (PST) Received: from hibernia.jakma.org (IDENT:U2FsdGVkX19Fq751r7B2WOQh3YxIFYqXE0mf5v+ScXY@hibernia.jakma.org [212.17.55.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04IUZMB022751 for ; Tue, 4 Jan 2005 10:30:56 -0800 Received: from hibernia.jakma.org (IDENT:U2FsdGVkX1+3svVdQm+osAv9N37oS9iaQoYmLBwtouo@hibernia.jakma.org [192.168.0.3]) by hibernia.jakma.org (8.13.1/8.12.11) with ESMTP id j056UBaG006840; Wed, 5 Jan 2005 06:30:11 GMT Date: Wed, 5 Jan 2005 06:30:11 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@hibernia.jakma.org To: jamal cc: Jeff Garzik , Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Tommy Christensen Subject: Re: [patch 4/10] s390: network driver. In-Reply-To: <1104895169.1117.63.camel@jzny.localdomain> Message-ID: References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> <1104895169.1117.63.camel@jzny.localdomain> Mail-Followup-To: paul@hibernia.jakma.org X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/634/Sun Dec 19 21:21:52 2004 clamav-milter version 0.80j on hibernia.jakma.org X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 13406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paul@clubi.ie Precedence: bulk X-list: netdev On Wed, 4 Jan 2005, jamal wrote: > Theres possibly people who would want it differently - so for we > havent heard from them. Maybe poll far and wide - or push it in and > wait for them to whine. We're whining. This policy in the Linux kernel makes using Linux dangerous for certain routing applications (RIP, routing advertisements). Name a non-TCP application that *does* want this newish kernel policy and tell me how it breaks without this *new* policy. ;) > cheers, > jamal regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: My only love sprung from my only hate! Too early seen unknown, and known too late! -- William Shakespeare, "Romeo and Juliet" From davem@davemloft.net Tue Jan 4 10:35:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:35:39 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04IZAhK023357 for ; Tue, 4 Jan 2005 10:35:33 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cm4hE-0004fR-00; Tue, 04 Jan 2005 22:31:04 -0800 Date: Tue, 4 Jan 2005 22:31:04 -0800 From: "David S. Miller" To: Andrew Morton Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: net patches Message-Id: <20050104223104.2ec87f5b.davem@davemloft.net> In-Reply-To: <20050104215913.274e6567.akpm@osdl.org> References: <20050104215913.274e6567.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 4 Jan 2005 21:59:13 -0800 Andrew Morton wrote: > I'll unload some accumulated net patches. I can't say that I've looked at > them very closely. I'll be quiet for the next few days as I try to discover why sparc64 now explodes after the past week of changes. I'm heavily suspecting the 4-level page table stuff. wli kept saying that he was having trouble getting his sparc boxes working with the -mm tree over the past month and that's about how long the 4-level page table stuff has been in there. What's odd is that Andi's original 4-level page table patch he gave to me worked just fine on sparc64, but it's been changed a lot. From wli@holomorphy.com Tue Jan 4 10:49:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 10:49:39 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04InCv1024099 for ; Tue, 4 Jan 2005 10:49:32 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1Cm4yX-0002Y2-00; Tue, 04 Jan 2005 22:48:57 -0800 Date: Tue, 4 Jan 2005 22:48:57 -0800 From: William Lee Irwin III To: "David S. Miller" Cc: Andrew Morton , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: net patches Message-ID: <20050105064857.GD7961@holomorphy.com> References: <20050104215913.274e6567.akpm@osdl.org> <20050104223104.2ec87f5b.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050104223104.2ec87f5b.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: netdev On Tue, 4 Jan 2005 21:59:13 -0800 Andrew Morton wrote: >> I'll unload some accumulated net patches. I can't say that I've looked at >> them very closely. On Tue, Jan 04, 2005 at 10:31:04PM -0800, David S. Miller wrote: > I'll be quiet for the next few days as I try to discover why > sparc64 now explodes after the past week of changes. I'm > heavily suspecting the 4-level page table stuff. wli kept > saying that he was having trouble getting his sparc boxes > working with the -mm tree over the past month and that's about > how long the 4-level page table stuff has been in there. > What's odd is that Andi's original 4-level page table patch > he gave to me worked just fine on sparc64, but it's been > changed a lot. I eventually narrowed this down to something associated with some unusual core fault handling changes with an unclear relationship to Andi's 4-level code. Something odd was going on with spec-guided definitions of pte_read(), pte_write(), et al. sun4u seemed to do okay with Andi's earlier code in my testing; later problems seemed to stem from elsewhere (e.g. the ioctl bogon). $ uname -a Linux analyticity 2.6.10-rc2-mm2 #8 SMP Sat Dec 18 07:57:42 PST 2004 sparc64 GNU/Linux -- wli From jgarzik@pobox.com Tue Jan 4 11:26:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 11:26:11 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04JPgpa025448 for ; Tue, 4 Jan 2005 11:26:03 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cm5Xy-0005T9-H1; Wed, 05 Jan 2005 07:25:34 +0000 Message-ID: <41DB965F.6070409@pobox.com> Date: Wed, 05 Jan 2005 02:25:19 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: net patches References: <20050104215913.274e6567.akpm@osdl.org> In-Reply-To: <20050104215913.274e6567.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Andrew Morton wrote: > I'll unload some accumulated net patches. I can't say that I've looked at > them very closely. I'll push the drivers/net stuff through tomorrow, after sleep :) Jeff From buytenh@wantstofly.org Tue Jan 4 14:20:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 14:20:31 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04MK3BA001531 for ; Tue, 4 Jan 2005 14:20:23 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id BC4382B0EE; Wed, 5 Jan 2005 11:19:55 +0100 (MET) Date: Wed, 5 Jan 2005 11:19:55 +0100 From: Lennert Buytenhek To: Pekka Savola Cc: Jeff Garzik , Netdev , YOSHIFUJI Hideaki / ???????????? , Herbert Xu Subject: Re: IPv6 badness continues Message-ID: <20050105101955.GE19910@xi.wantstofly.org> References: <41DA3A60.8050102@pobox.com> <20050104093335.GB7823@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Tue, Jan 04, 2005 at 10:57:43PM +0200, Pekka Savola wrote: > >I upgraded my problematic machine to FC3, which somehow broke 6to4, and I > >didn't bother to reenable it again because the local DNS server (dnscache) > >just drops AAAA queries on the floor anyway, leading to lots of timeouts > >when trying to resolve host names, etc. Ever since 6to4 was turned off > >on that box I stopped seeing these messages. > > Surely it doesn't just drop AAAA queries on the floor, but sends an > error message? Sorry, I just tried again and can't reproduce this behavior -- when doing an AAAA query on a random domain name I get a clean 0/0/0 answer indicating no RRs of the desired type having been found, and doing an AAAA query on a domain name that does have RRs of that type, I do get the desired records. I'm trying to recall what specific problem it was that I was seeing.. --L From tgraf@suug.ch Tue Jan 4 15:01:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 15:01:07 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04N0caH002809 for ; Tue, 4 Jan 2005 15:00:59 -0800 Received: from postel.suug.ch (unknown [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 BEE9182; Wed, 5 Jan 2005 12:00:07 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 34CDD1C0EA; Wed, 5 Jan 2005 12:00:48 +0100 (CET) Date: Wed, 5 Jan 2005 12:00:48 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050105110048.GO26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> <1104894728.1117.56.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104894728.1117.56.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13411 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 * jamal <1104894728.1117.56.camel@jzny.localdomain> 2005-01-04 22:12 > On Tue, 2005-01-04 at 17:36, Thomas Graf wrote: > > > * TCF_EM_SIMPLE flag which marks an ematch config as simple, meaning > > that the data consists of a u32 value. > > This is 1 of 2 parts i think thats still an issue; otherwise looks very > good. > Why do i need to signal something as simple? AND why does it have to be > 32 bit type - what edge does that give you? You don't have to, providing a 32bit data chunk without TCF_EM_SIMPLE set will simply result in allocating & copy. It's an optimization, nothing more. > I should be able to specify a struct with two 32 bits and > encap it in a TLV and the classifier can treat it the same way - it > knows the type and length - thats sufficient to create, destroy and > dump. Correct, maybe you're right and I should drop it again. > The other issue is still on the ematch/match interleaving i.e i should > be able to say something along the lines: > > //simple slammer-worm or code-red ACL detector rule > //using u32 classifier and ematches > (match ip protocol udp port 1434 AND > ematch packetlen minsize 404 maxsize 404) OR > (match ip protocol tcp http AND > ematch urlscanner "*.ida") > action ipt -j ULOG "Virus detected and dropped" > action drop > > Not a very good example - but you can see how powerfull this is when you > can quickly use a string scanner such as the one you have as an ematch > while maintaining u32 as is. Basically you could do that already with the basic classifier but I understand your concern and it would be neat to benefit from u32's hashing. There are 2 options: 1) We make u32 hold multiple ematch trees, a u32 key can be of 3 kinds: u32/ematch/container. It's kind of a hack and not very fast due to a lot of stack movement. 2) We make the existing u32 match be an ematch which I already did expect for the nexthdr bits. That is the select will simply be replaced by an ematch tree. I'll take a look into how we could have the classifier take influence on the ematches config data. One possibiliy is to have a struct transfered via map which contains useful data such as offset to next header (u32/rsvp). I have to think about this a little more though. Personally I'm all for 2) because it's just cleaner and easier to maintain. It's probably the best to not to use the u32 ematch I wrote (which I renamed to cmp) but to write a new one behaving exactly the same as the existing u32 match. Attached cmp ematch (formerly u32), it was on diet for a while and is quite smallish now. diff -Nru linux-2.6.10-bk6.orig/include/linux/pkt_cls.h linux-2.6.10-bk6/include/linux/pkt_cls.h --- linux-2.6.10-bk6.orig/include/linux/pkt_cls.h 2005-01-05 01:09:29.000000000 +0100 +++ linux-2.6.10-bk6/include/linux/pkt_cls.h 2005-01-05 01:46:34.000000000 +0100 @@ -349,6 +349,7 @@ enum { TCF_EM_CONTAINER, + TCF_EM_CMP, __TCF_EM_MAX }; @@ -366,4 +367,28 @@ #define TCF_EM_INVERT (1<<3) #define TCF_EM_SIMPLE (1<<4) +struct tcf_em_cmp +{ + __u32 val; + __u32 mask; + __u16 off; + __u8 align; + __u8 layer:4; + __u8 opnd:4; +}; + +enum +{ + TCF_EM_ALIGN_U8 = 1, + TCF_EM_ALIGN_U16 = 2, + TCF_EM_ALIGN_U32 = 4 +}; + +enum +{ + TCF_EM_OPND_EQ, + TCF_EM_OPND_GT, + TCF_EM_OPND_LT +}; + #endif diff -Nru linux-2.6.10-bk6.orig/include/net/pkt_cls.h linux-2.6.10-bk6/include/net/pkt_cls.h --- linux-2.6.10-bk6.orig/include/net/pkt_cls.h 2005-01-05 01:09:29.000000000 +0100 +++ linux-2.6.10-bk6/include/net/pkt_cls.h 2005-01-05 01:26:03.000000000 +0100 @@ -270,6 +270,36 @@ #endif /* CONFIG_NET_EMATCH */ +static inline u32 tcf_read_bucket(u8 *ptr, u8 align) +{ + switch (align) { + case TCF_EM_ALIGN_U8: + return *ptr; + case TCF_EM_ALIGN_U16: + return (*ptr << 8) | *(ptr+1); + case TCF_EM_ALIGN_U32: + return (*ptr << 24) | (*(ptr+1) << 16) | + (*(ptr+2) << 8) | *(ptr+3); + } + return 0; +} + +static inline u8 * tcf_get_base_ptr(struct sk_buff *skb, u8 layer) +{ + switch (layer) { + case 0: + return skb->data; + case 1: + return skb->nh.raw; + case 2: + return skb->h.raw; + } + return NULL; +} + +#define tcf_valid_offset(skb, ptr, off, len) \ + ((ptr + off + len) < skb->tail && (ptr + off) > skb->head) + #ifdef CONFIG_NET_CLS_IND static inline int tcf_change_indev(struct tcf_proto *tp, char *indev, struct rtattr *indev_tlv) diff -Nru linux-2.6.10-bk6.orig/net/sched/Kconfig linux-2.6.10-bk6/net/sched/Kconfig --- linux-2.6.10-bk6.orig/net/sched/Kconfig 2005-01-05 01:09:29.000000000 +0100 +++ linux-2.6.10-bk6/net/sched/Kconfig 2005-01-05 01:34:38.000000000 +0100 @@ -388,6 +388,16 @@ You must have a recent version of the iproute2 tools in order to use extended matches. +config NET_EMATCH_CMP + tristate "Simple packet data comparison" + depends on NET_EMATCH + ---help--- + Say Y here if you want to be able to classify packets based on + simple packet data comparisons for 8, 16, and 32bit values. + + To compile this code as a module, choose M here: the + module will be called em_cmp. + config NET_CLS_ACT bool "Packet ACTION" depends on EXPERIMENTAL && NET_CLS && NET_QOS diff -Nru linux-2.6.10-bk6.orig/net/sched/Makefile linux-2.6.10-bk6/net/sched/Makefile --- linux-2.6.10-bk6.orig/net/sched/Makefile 2005-01-05 01:09:29.000000000 +0100 +++ linux-2.6.10-bk6/net/sched/Makefile 2005-01-05 01:28:03.000000000 +0100 @@ -34,3 +34,4 @@ obj-$(CONFIG_NET_CLS_TCINDEX) += cls_tcindex.o obj-$(CONFIG_NET_CLS_RSVP6) += cls_rsvp6.o obj-$(CONFIG_NET_EMATCH) += ematch.o +obj-$(CONFIG_NET_EMATCH_CMP) += em_cmp.o diff -Nru linux-2.6.10-bk6.orig/net/sched/em_cmp.c linux-2.6.10-bk6/net/sched/em_cmp.c --- linux-2.6.10-bk6.orig/net/sched/em_cmp.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.10-bk6/net/sched/em_cmp.c 2005-01-05 01:47:00.000000000 +0100 @@ -0,0 +1,66 @@ +/* + * net/sched/em_cmp.c Simple packet data comparison ematch + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include + +static int em_cmp_match(struct sk_buff *skb, struct tcf_ematch *m) +{ + struct tcf_em_cmp *u = (struct tcf_em_cmp *) m->data; + u8 *ptr = tcf_get_base_ptr(skb, u->layer); + u32 v; + + if (unlikely(!tcf_valid_offset(skb, ptr, u->off, u->align))) + return 0; + + v = tcf_read_bucket(ptr + u->off, u->align) & u->mask; + + /* FIXME: byte order issues */ + + switch (u->opnd) { + case TCF_EM_OPND_EQ: + return v == u->val; + case TCF_EM_OPND_LT: + return v < u->val; + case TCF_EM_OPND_GT: + return v > u->val; + } + + return 0; +} + +static struct tcf_ematch_ops em_cmp_ops = { + .kind = TCF_EM_CMP, + .datalen = sizeof(struct tcf_em_cmp), + .match = em_cmp_match, + .owner = THIS_MODULE, + .link = LIST_HEAD_INIT(em_cmp_ops.link) +}; + +static int __init init_em_cmp(void) +{ + return tcf_em_register(&em_cmp_ops); +} + +static void __exit exit_em_cmp(void) +{ + tcf_em_unregister(&em_cmp_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_em_cmp); +module_exit(exit_em_cmp); + From tgraf@suug.ch Tue Jan 4 15:09:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 15:09:31 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04N93Xj003493 for ; Tue, 4 Jan 2005 15:09:24 -0800 Received: from postel.suug.ch (unknown [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 6E18B82; Wed, 5 Jan 2005 12:08:34 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 9B15F1C0EA; Wed, 5 Jan 2005 12:09:17 +0100 (CET) Date: Wed, 5 Jan 2005 12:09:17 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050105110917.GP26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104122738.GG26856@postel.suug.ch> <1104844935.1085.103.camel@jzny.localdomain> <20050104134126.GJ26856@postel.suug.ch> <1104893694.1124.37.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104893694.1124.37.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13412 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 * jamal <1104893694.1124.37.camel@jzny.localdomain> 2005-01-04 21:54 > I think this is a debate that can be easily settled ;-> > Agreed logic will beat brute force smartness and u32 is not exactly > for the faint hearted. And its usability is extremely poor - but lets > maintain its power as is. Absolutely. > > Using what key? We have no knowledge about what the ematches want to > > see or not. > > Ok, good question ;-> > Maybe you should have own some 32 bit key? Actually the goal of basic is to be an alternative to u32 if hashing is not required because I think adding hashing will simply result in a duplication of u32. From Robert.Olsson@data.slu.se Tue Jan 4 17:18:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 17:19:03 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j051IY3r017441 for ; Tue, 4 Jan 2005 17:18:55 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j05DIJuA014850; Wed, 5 Jan 2005 14:18:19 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 91AD2EC0BC; Wed, 5 Jan 2005 14:18:19 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16859.59675.522262.418329@robur.slu.se> Date: Wed, 5 Jan 2005 14:18:19 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501031656.57041.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <20050103145115.4bdb2cd6@dxpl.pdx.osdl.net> <200501031656.57041.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > How would I check? It should be in the hundreds of thousands. Good question Stephen,.. Yes it seems like this pretty hefty load. Forwarding rate of 92k kpps and a drop rate of 10 kpps and dst hash mostly at 50-60 kentries if I read the stats correctly. And 2.4 were able handle this but not 2.6.10? Assuming things are uses and setup identically. 2.6 uses RCU for route hash locking. Any dst cache overslow messages seen? A couple of lines of rtstat would be very interesing from this box. Also check that the CPU shares the RX packet load. CPU0 affinty to eth0 and CPU1 to eth1 seems to be best. It gives cache bouncing at "TX" and slab jobs but we have accept that for now. 13:37:25 CPU %user %nice %system %iowait %irq %soft %idle > intr/s > 13:38:24 all 0.14 0.00 0.12 0.12 2.02 42.89 54.71 > 25900.70 > 13:38:24 0 0.03 0.00 0.05 0.22 0.00 16.67 83.03 > 2246.10 > 13:38:24 1 0.25 0.00 0.20 0.03 4.02 69.12 26.40 > 23654.55 This looks weird to me... we cannot have CPU left? Due to the imbalance? Check /proc/net/softnet_stat, Haven't used mpstat. %soft is that *all* softirq's or only softirq's deferred to ksoftird only? --ro From fw@deneb.enyo.de Tue Jan 4 17:33:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 17:33:15 -0800 (PST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j051WlP8018234 for ; Tue, 4 Jan 2005 17:33:07 -0800 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1CmBH4-0004Rx-FJ; Wed, 05 Jan 2005 14:32:30 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1CmBH3-0001nH-MD; Wed, 05 Jan 2005 14:32:29 +0100 From: Florian Weimer To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier References: <20050103125635.GB26856@postel.suug.ch> Date: Wed, 05 Jan 2005 14:32:29 +0100 In-Reply-To: <20050103125635.GB26856@postel.suug.ch> (Thomas Graf's message of "Mon, 3 Jan 2005 13:56:35 +0100") Message-ID: <87pt0kc87m.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: netdev * Thomas Graf: > I attached 4 patches of a first ematch implementation. Comments > and suggestions very much appreciated. Compiles but untested. This might infringe US patent 5,793,954 and the patents that reference it. 8-( From hadi@cyberus.ca Tue Jan 4 17:46:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 17:46:09 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j051jgRi019422 for ; Tue, 4 Jan 2005 17:46:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CmBTf-0007QO-En for netdev@oss.sgi.com; Wed, 05 Jan 2005 08:45:31 -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 1CmBTV-0003GC-EC; Wed, 05 Jan 2005 08:45:21 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Florian Weimer Cc: Thomas Graf , netdev@oss.sgi.com In-Reply-To: <87pt0kc87m.fsf@deneb.enyo.de> References: <20050103125635.GB26856@postel.suug.ch> <87pt0kc87m.fsf@deneb.enyo.de> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104932718.1124.155.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jan 2005 08:45:18 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13415 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 Wed, 2005-01-05 at 08:32, Florian Weimer wrote: > * Thomas Graf: > > > I attached 4 patches of a first ematch implementation. Comments > > and suggestions very much appreciated. Compiles but untested. > > This might infringe US patent 5,793,954 and the patents that reference > it. 8-( hehe. We can sleep better knowing we dont run Linux using C++ ;-> That patents reads like it owns every classifier ever written in C++ that runs on a processor. cheers, jamal From hadi@cyberus.ca Tue Jan 4 17:59:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 17:59:46 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j051xD5r020218 for ; Tue, 4 Jan 2005 17:59:37 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1CmBgm-0003yT-TE for netdev@oss.sgi.com; Wed, 05 Jan 2005 08:59:04 -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 1CmBHm-0001OE-JJ; Wed, 05 Jan 2005 08:33:14 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050105110048.GO26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> <1104894728.1117.56.camel@jzny.localdomain> <20050105110048.GO26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104931991.1117.152.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jan 2005 08:33:11 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13416 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 Wed, 2005-01-05 at 06:00, Thomas Graf wrote: > * jamal <1104894728.1117.56.camel@jzny.localdomain> 2005-01-04 22:12 > > Why do i need to signal something as simple? AND why does it have to be > > 32 bit type - what edge does that give you? > > You don't have to, providing a 32bit data chunk without TCF_EM_SIMPLE > set will simply result in allocating & copy. It's an optimization, > nothing more. Sorry i missed that. Isnt it still unecessary though? You should be able to pass L=4 and not need the speacial treatment, no? > > Not a very good example - but you can see how powerfull this is when you > > can quickly use a string scanner such as the one you have as an ematch > > while maintaining u32 as is. > > Basically you could do that already with the basic classifier but > I understand your concern and it would be neat to benefit from u32's > hashing. There are 2 options: > 1) We make u32 hold multiple ematch trees, a u32 key can be of 3 > kinds: u32/ematch/container. It's kind of a hack and not very > fast due to a lot of stack movement. Indeed this is what i was thinking of. The only added overhead I can think of is when processing a series of u32 keys _within the same selector_ (not across selectors), you check if its u32 native and execute localy (as is done now) or transfer the check to the ematch defined in that key and continue to next key based on the ematchs return code + the logical operation. > 2) We make the existing u32 match be an ematch which I already did > expect for the nexthdr bits. That is the select will simply be > replaced by an ematch tree. I'll take a look into how we could > have the classifier take influence on the ematches config data. > One possibiliy is to have a struct transfered via map which > contains useful data such as offset to next header (u32/rsvp). > I have to think about this a little more though. This could be done in addition to #1. I see #1 as more important for u32 but not so for things like fwmark, tcindex which should fizzle away with meta ematch. I think the danger is in trying to replicate u32 as an ematch; if somehow you can loop back and use the real u32 code, then fine. I feel it being non-trivial to do so. Like i said earlier, theres a lot of power in u32 other than in basic matching. > Personally I'm all for 2) because it's just cleaner and easier to > maintain. Aha, thats why we were not converging then ;-> I think #2 is better for other classifiers which were already doomed anyways. #1 is important for u32 and perhaps other classifiers like rsvp and route. And yes, #1 is more work ;-> > It's probably the best to not to use the u32 ematch I > wrote (which I renamed to cmp) but to write a new one behaving > exactly the same as the existing u32 match. > hang on:-> No dont rewrite u32 please. Your cmp is good for the basic matches that u32 does, but is _nowhere_ close to being able to do what u32 can when used properly. > Attached cmp ematch (formerly u32), it was on diet for a while > and is quite smallish now. Looks very appetizing. Two general comments: > diff -Nru linux-2.6.10-bk6.orig/include/linux/pkt_cls.h linux-2.6.10-bk6/include/linux/pkt_cls.h > --- linux-2.6.10-bk6.orig/include/linux/pkt_cls.h 2005-01-05 01:09:29.000000000 +0100 > +++ linux-2.6.10-bk6/include/linux/pkt_cls.h 2005-01-05 01:46:34.000000000 +0100 > @@ -349,6 +349,7 @@ > enum > { > TCF_EM_CONTAINER, > + TCF_EM_CMP, > __TCF_EM_MAX > }; I Should be able to compile a new ematch as a module in an already running kernel. So, other than generic stuff for ematches, things like TCF_EM_CMP should not be in that enumeration. > @@ -366,4 +367,28 @@ > #define TCF_EM_INVERT (1<<3) > #define TCF_EM_SIMPLE (1<<4) > > +struct tcf_em_cmp > +{ > + __u32 val; > + __u32 mask; > + __u16 off; > + __u8 align; > + __u8 layer:4; > + __u8 opnd:4; > +}; > + > +enum > +{ > + TCF_EM_ALIGN_U8 = 1, > + TCF_EM_ALIGN_U16 = 2, > + TCF_EM_ALIGN_U32 = 4 > +}; > + > +enum > +{ > + TCF_EM_OPND_EQ, > + TCF_EM_OPND_GT, > + TCF_EM_OPND_LT > +}; > + Which means the above should go in its own file; probably create a include/linux/tc_ematch directory with a file of sort tcf_em_cmp.h which holds all the above. > #endif > diff -Nru linux-2.6.10-bk6.orig/include/net/pkt_cls.h linux-2.6.10-bk6/include/net/pkt_cls.h > --- linux-2.6.10-bk6.orig/include/net/pkt_cls.h 2005-01-05 01:09:29.000000000 +0100 > +++ linux-2.6.10-bk6/include/net/pkt_cls.h 2005-01-05 01:26:03.000000000 +0100 > @@ -270,6 +270,36 @@ > > #endif /* CONFIG_NET_EMATCH */ > > +static inline u32 tcf_read_bucket(u8 *ptr, u8 align) > +{ > + switch (align) { > + case TCF_EM_ALIGN_U8: > + return *ptr; > + case TCF_EM_ALIGN_U16: > + return (*ptr << 8) | *(ptr+1); > + case TCF_EM_ALIGN_U32: > + return (*ptr << 24) | (*(ptr+1) << 16) | > + (*(ptr+2) << 8) | *(ptr+3); > + } > + return 0; > +} > + > +static inline u8 * tcf_get_base_ptr(struct sk_buff *skb, u8 layer) > +{ > + switch (layer) { > + case 0: > + return skb->data; > + case 1: > + return skb->nh.raw; > + case 2: > + return skb->h.raw; > + } > + return NULL; > +} > + > +#define tcf_valid_offset(skb, ptr, off, len) \ > + ((ptr + off + len) < skb->tail && (ptr + off) > skb->head) > + And all this also goes in that header file as well. cheers, jamal From hadi@cyberus.ca Tue Jan 4 18:05:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 18:06:00 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0525RXD020913 for ; Tue, 4 Jan 2005 18:05:47 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CmBmk-0003Uw-Rc for netdev@oss.sgi.com; Wed, 05 Jan 2005 09:05:14 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CmB1y-0008Ec-4u; Wed, 05 Jan 2005 08:16:54 -0500 Subject: Re: [patch 4/10] s390: network driver. From: jamal Reply-To: hadi@cyberus.ca To: Paul Jakma Cc: Jeff Garzik , Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Tommy Christensen In-Reply-To: References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> <1104895169.1117.63.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104931011.1118.134.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jan 2005 08:16:51 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13417 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 Wed, 2005-01-05 at 01:30, Paul Jakma wrote: > On Wed, 4 Jan 2005, jamal wrote: > > > Theres possibly people who would want it differently - so for we > > havent heard from them. Maybe poll far and wide - or push it in and > > wait for them to whine. > > We're whining. > > This policy in the Linux kernel makes using Linux dangerous for > certain routing applications (RIP, routing advertisements). > > Name a non-TCP application that *does* want this newish kernel policy > and tell me how it breaks without this *new* policy. ;) Ok, Iam confused - I thought you guys _wanted this_ ;-> The issue is about message obsolency more than it is about reliability. Without this the scenario you played you played for us before was: 1)=>send a few LSAs from user space, pull cable before they go out (this will happen if you are sending sufficiently large amounts of packets i.e network is busy), 2)=>user space gets notified via netlink, device shuts down acces to DMA, packets queued anyways and you have no ability to say "ooops,sorry take that packet back" a)You could do a move to another device at this point. or b) dumb app will continue sending 3)=>plug cable back in 2 minutes later, obsolete LSAs sent followed by any new ones that may follow .... With the patch, packets in #2 will be dropped. As a matter of fact within those two minutes, if stopped, it is probable the device watchdog timer will kick in and flush the DMA but not the scheduler queues above it (which is where upto a 1000 stale packets could be sitting). What is it that you dont like now? cheers, jamal From paul@clubi.ie Tue Jan 4 18:31:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 18:32:02 -0800 (PST) Received: from hibernia.jakma.org (IDENT:U2FsdGVkX18CpjiC5rVNHJTbfCgvwCDjr/yEEJkXPEg@hibernia.jakma.org [212.17.55.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j052VW00022007 for ; Tue, 4 Jan 2005 18:31:55 -0800 Received: from hibernia.jakma.org (IDENT:U2FsdGVkX1+L/mbcoFnU9w/oDtd++/IuZVr8Eu8GWeU@hibernia.jakma.org [192.168.0.3]) by hibernia.jakma.org (8.13.1/8.12.11) with ESMTP id j05ETvjt010773; Wed, 5 Jan 2005 14:29:58 GMT Date: Wed, 5 Jan 2005 14:29:57 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@hibernia.jakma.org To: jamal cc: Jeff Garzik , Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Tommy Christensen Subject: Re: [patch 4/10] s390: network driver. In-Reply-To: <1104931011.1118.134.camel@jzny.localdomain> Message-ID: References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> <1104895169.1117.63.camel@jzny.localdomain> <1104931011.1118.134.camel@jzny.localdomain> Mail-Followup-To: paul@hibernia.jakma.org X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/634/Sun Dec 19 21:21:52 2004 clamav-milter version 0.80j on hibernia.jakma.org X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 13418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paul@clubi.ie Precedence: bulk X-list: netdev On Wed, 5 Jan 2005, jamal wrote: > Ok, Iam confused - I thought you guys _wanted this_ ;-> I'm confused too now. We dont want "queue packets" - that's the 'newish' policy I was referring to. (newish in quotes, as I'm not sure from when this behaviour dates). > The issue is about message obsolency more than it is about reliability. Right, exactly. So we do want what you think we want ;) (i think). > Without this the scenario you played you played for us before was: > > 1)=>send a few LSAs from user space, pull cable before they go out > (this will happen if you are sending sufficiently large amounts of > packets i.e network is busy), > 2)=>user space gets notified via netlink, device shuts down acces to > DMA, packets queued anyways and you have no ability to say "ooops,sorry > take that packet back" Right. Two things: - we noticed this behaviour because of OSPF Users reported ospfd would cease to send packets on all interfaces, (with certain drivers) because /one/ interface was link-down. We can workaround this easily by opening a socket per interface - at present we simply punt OSPF packets down a single raw socket and rely on IP_HDRINCL to have kernel route the packet out correct interface (IP_MULTICAST_IF for multicast destined packets). - The queueing does not affect OSPF terribly, it would affect other protocols though OSPF implements its own 'synchronisation' facilities between neighbours and can easily 'detect' obsolecent packets. So the obsolence issue does not affect it, routing-information in stale packets will not propogate, so they cant do much damage really. (just unneccessary to queue and send such packets). However, other commonly used protocols are not as robust. Mostly those where a protocol is used to distribute routing information to passive listeners, eg: - RIP - IPv4 ICMP based router-discovery (IRDP) - IPv6 Router-advertisements In these cases, the queuing behaviour is potentially dangerous and could disrupt connectivity by propogating no-longer-valid routing information. > a)You could do a move to another device at this point. > or > b) dumb app will continue sending > > 3)=>plug cable back in 2 minutes later, obsolete LSAs sent followed by > any new ones that may follow Right. Except OSPF is robust enough against stale packets. Other protocols are not. > With the patch, packets in #2 will be dropped. Perfect. > As a matter of fact within those two minutes, if stopped, it is > probable the device watchdog timer will kick in and flush the DMA > but not the scheduler queues above it (which is where upto a 1000 > stale packets could be sitting). Right, and our argument it doesnt make sense to send those packets. I've never heard of any UDP and/or raw application that expected a kernel to queue packets if they could not be sent for lack of link or other problem, and any which did are surely broken by definition? ;) > What is it that you dont like now? Sorry, wires crossed re "new behaviour". The "new new" behaviour in the patch as you describe would be perfect. PS: Another issue, could we have kernel space IP fragmentation for IP_HDRINCL sockets please? We currently have to implement fragmentation ourselves, which seems silly given that kernel already has this functionality. > cheers, > jamal regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee From advertiser@localhost.localdomain Tue Jan 4 18:35:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 18:35:37 -0800 (PST) Received: from localhost.localdomain ([82.201.181.227]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j052Z7HW022529 for ; Tue, 4 Jan 2005 18:35:28 -0800 Received: from localhost.localdomain (admin3 [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id j062c1lW001751 for ; Thu, 6 Jan 2005 04:41:31 +0200 Received: (from advertiser@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j05C6fKa006526 for netdev@oss.sgi.com; Wed, 5 Jan 2005 14:06:41 +0200 Date: Wed, 5 Jan 2005 14:06:41 +0200 From: advertiser@advertise.com Message-Id: <200501051206.j05C6fKa006526@localhost.localdomain> To: netdev@oss.sgi.com Subject: Cheap Prices NOT Cheap Hosting X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: advertiser@advertise.com Precedence: bulk X-list: netdev .HellO... ------------------------------------------------------------ ############################################################## $ Visit http://www.mkhoster.com For Very Good Hosting Offer $ $--- Cpanel $ $--- PHP $ $--- CGI-perl $ $--- Mysql $ $--- And MORE ....... $ ############################################################## FOR MORE INFORMATIONS -----< http://mkhoster.com/support.html >----- ************************************************************** From tgraf@suug.ch Tue Jan 4 18:45:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 18:45:29 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j052j1kX023282 for ; Tue, 4 Jan 2005 18:45:22 -0800 Received: from postel.suug.ch (unknown [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 D8E5C82; Wed, 5 Jan 2005 15:44:31 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id F41791C0EA; Wed, 5 Jan 2005 15:45:14 +0100 (CET) Date: Wed, 5 Jan 2005 15:45:14 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050105144514.GQ26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> <1104894728.1117.56.camel@jzny.localdomain> <20050105110048.GO26856@postel.suug.ch> <1104931991.1117.152.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104931991.1117.152.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13420 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 * jamal <1104931991.1117.152.camel@jzny.localdomain> 2005-01-05 08:33 > On Wed, 2005-01-05 at 06:00, Thomas Graf wrote: > > * jamal <1104894728.1117.56.camel@jzny.localdomain> 2005-01-04 22:12 > > > > Why do i need to signal something as simple? AND why does it have to be > > > 32 bit type - what edge does that give you? > > > > You don't have to, providing a 32bit data chunk without TCF_EM_SIMPLE > > set will simply result in allocating & copy. It's an optimization, > > nothing more. > > Sorry i missed that. Isnt it still unecessary though? You should be able > to pass L=4 and not need the speacial treatment, no? Agreed, but the ematch might expect an allocated block. Assuming the data is variable and sometimes is L=4, sometimes L=16 the ematch requires special handling because m->data might hold the value directly or a pointer depending on datalen. > > 1) We make u32 hold multiple ematch trees, a u32 key can be of 3 > > kinds: u32/ematch/container. It's kind of a hack and not very > > fast due to a lot of stack movement. > > Indeed this is what i was thinking of. > The only added overhead I can think of is when processing a series of > u32 keys _within the same selector_ (not across selectors), you check if > its u32 native and execute localy (as is done now) or transfer the check > to the ematch defined in that key and continue to next key based on the > ematchs return code + the logical operation. Exactly, does the performance gap come with any advantage? No. That's why I don't like it. > > 2) We make the existing u32 match be an ematch which I already did > > expect for the nexthdr bits. That is the select will simply be > > replaced by an ematch tree. I'll take a look into how we could > > have the classifier take influence on the ematches config data. > > One possibiliy is to have a struct transfered via map which > > contains useful data such as offset to next header (u32/rsvp). > > I have to think about this a little more though. > > This could be done in addition to #1. I see #1 as more important for u32 > but not so for things like fwmark, tcindex which should fizzle away with > meta ematch. I think the danger is in trying to replicate u32 as an > ematch; if somehow you can loop back and use the real u32 code, then > fine. I feel it being non-trivial to do so. > Like i said earlier, theres a lot of power in u32 other than in basic > matching. Most importantly I don't want to touch any of the hashing code in u32. I really like and it should stay as it is. The existing u32 match can be easly made an ematch so this would safe us the extra work in u32 to implement logic relations again and to fiddle with complicated selector TLVs. The only problem with this is the nexthdr bits because it relies on the hashing code. So we have to make this data available to the ematch which is actually not a bad idea anyway. So I'm thinking about introducing a new structure tcf_em_pkt_info or alike which carries some additional information found out by the classifiers which can be used by ematches. This can be information about the next header, already extracted dscp values, etc. This would give us the chance to add a very small em_u32.c (~40 lines) doing exactly the same as the current u32 match and have the u32 selector replaced with an ematch tree at no additional cost. Backward compatibility is as easy as creating a flat ANDed ematch tree. Note: The u32 ematch I'm talking about is not the cmp ematch, cmp is more advanced but also slightly slower. Thoughts? > I think #2 is better for other classifiers which were already doomed > anyways. #1 is important for u32 and perhaps other classifiers like rsvp > and route. And yes, #1 is more work ;-> Why is it better? What's the advantage? > hang on:-> No dont rewrite u32 please. Your cmp is good for the basic > matches that u32 does, but is _nowhere_ close to being able to do what > u32 can when used properly. Right, that's why I now call it cmp and the existing u32 match becomes the u32 ematch. > I Should be able to compile a new ematch as a module in an already > running kernel. So, other than generic stuff for ematches, things like > TCF_EM_CMP should not be in that enumeration. It's not a requirement to put it there but we need to manage the assigned types for ematches in mainline anyway. > Which means the above should go in its own file; probably create a > include/linux/tc_ematch directory with a file of sort tcf_em_cmp.h > which holds all the above. This one I can agree. > And all this also goes in that header file as well. I put it here because it might be very useful for other ematches or further classifiers, you name it. tcf_get_base_ptr is used by nbyte ematch for example. From webvenza@libero.it Tue Jan 4 18:59:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 18:59:52 -0800 (PST) Received: from gateway.milesteg.arr (venza@adsl-ull-142-137.44-151.net24.it [151.44.137.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j052xPci024778 for ; Tue, 4 Jan 2005 18:59:45 -0800 Date: Wed, 5 Jan 2005 15:59:16 +0100 From: Daniele Venzano To: Brancaleoni Matteo Cc: linux-kernel@vger.kernel.org, NetDev Subject: Re: [PATCH] sis900.c net poll support Message-ID: <20050105145916.GA31207@picchio.gall.it> Mail-Followup-To: Brancaleoni Matteo , linux-kernel@vger.kernel.org, NetDev References: <1104921127.5729.17.camel@athlon64> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104921127.5729.17.camel@athlon64> X-Operating-System: Debian GNU/Linux on kernel Linux 2.4.28-grsec X-Copyright: Forwarding or publishing without permission is prohibited. X-Truth: La vita e' una questione di culo, o ce l'hai o te lo fanno. X-GPG-Fingerprint: 642A A345 1CEF B6E3 925C 23CE DAB9 8764 25B3 57ED X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Thanks, it was on my TODO list and now I can just remove the entry :-) I'll try to integrate your patch in the next sis900 update. Bye. On Wed, Jan 05, 2005 at 11:32:07AM +0100, Brancaleoni Matteo wrote: > Hi. > > I was in need to use netconsole to trace some lock > of my sata disk, but my onboard network card (sis900) > seems doesn't support net poll. > So searching the web I found out an old patch for enabling > in under 2.4, and ported it to 2.6.10 (looking > also into 2.6.x device drivers already working) > > Seems to be ok, netconsole works without issues. > Hope that's ok and can be useful. > > Matteo Brancaleoni. > --- linux-2.6.10/drivers/net/sis900.orig 2005-01-05 09:55:46.000000000 +0100 > +++ linux-2.6.10/drivers/net/sis900.c 2005-01-05 10:09:04.000000000 +0100 -- ----------------------------- Daniele Venzano Web: http://teg.homeunix.org From jeremy.guthrie@berbee.com Tue Jan 4 19:18:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 19:19:07 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j053IZaV026350 for ; Tue, 4 Jan 2005 19:18:57 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Jan 2005 09:18:23 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Wed, 5 Jan 2005 09:18:19 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501031656.57041.jeremy.guthrie@berbee.com> <16859.59675.522262.418329@robur.slu.se> In-Reply-To: <16859.59675.522262.418329@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3761034.eMIVnrcmVK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501050918.22472.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 05 Jan 2005 15:18:23.0136 (UTC) FILETIME=[CBD0CA00:01C4F339] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart3761034.eMIVnrcmVK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 January 2005 07:18 am, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > How would I check? It should be in the hundreds of thousands. > > Good question Stephen,.. > > Yes it seems like this pretty hefty load. Forwarding rate of 92k kpps > and a drop rate of 10 kpps and dst hash mostly at 50-60 kentries if > I read the stats correctly. Yeah, the load will be high. I'm expecting this to be watching ~ 750 mbps = by=20 next December. The app profiles all traffic going in and out of our data=20 centers. > And 2.4 were able handle this but not 2.6.10? Yes. It does handle it. It runs harder ie. 2.6 caps out at ~ 50% utilizat= ion=20 where 2.4 might run 60-75% utilized. > Assuming things are uses and setup identically. 2.6 uses RCU for route > hash locking. Any dst cache overslow messages seen? No. > A couple of lines of rtstat would be very interesing from this box. I'm not showing the /proc/net/rt_cache_stat file. Was there a kernel optio= n I=20 need to recompile with for rt_cache_stat to show up in proc? > Also check that the CPU shares the RX packet load. CPU0 affinty to eth0 > and CPU1 to eth1 seems to be best. It gives cache bouncing at "TX" and > slab jobs but we have accept that for now. How would I go about doing this? > 13:37:25 CPU %user %nice %system %iowait %irq %soft %idle > > > intr/s > > 13:38:24 all 0.14 0.00 0.12 0.12 2.02 42.89 54.71 > > 25900.70 > > 13:38:24 0 0.03 0.00 0.05 0.22 0.00 16.67 83.03 > > 2246.10 > > 13:38:24 1 0.25 0.00 0.20 0.03 4.02 69.12 26.40 > > 23654.55 > > This looks weird to me... we cannot have CPU left? Due to the imbalance? > Check /proc/net/softnet_stat, cat /proc/net/softnet_stat 5592c972 00000000 00001fc8 00000000 00000000 00000000 00000000 00000000=20 00391c3f 000f1991 00000000 00000000 00000000 00000000 00000000 00000000 00000000=20 001292ba > Haven't used mpstat. %soft is that *all* softirq's or only softirq's > deferred to ksoftird only? "%soft" Show the percentage of time spent by the CPU or CPUs to service = =20 softirqs. A softirq (software interrupt) is one of up to 32 = =20 enumerated software interrupts which can run on multiple CPUs at = =20 once. =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart3761034.eMIVnrcmVK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3AU+qtjaBHGZBeURAieyAJ9rfhGwR6xUQ7nG20+7sD80au3vSwCaA3Vm vQkUCdaU2ctd5k52Bjow/X0= =azzl -----END PGP SIGNATURE----- --nextPart3761034.eMIVnrcmVK-- From tommy.christensen@tpack.net Tue Jan 4 19:34:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 19:34:26 -0800 (PST) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j053Xw4M027933 for ; Tue, 4 Jan 2005 19:34:18 -0800 Received: (qmail 29798 invoked from network); 5 Jan 2005 15:33:44 -0000 Received: from dhcp-112.cph.tpack.net (HELO ?172.17.159.11?) (192.168.0.112) by 0 with SMTP; 5 Jan 2005 15:33:44 -0000 Message-ID: <41DC0931.80603@tpack.net> Date: Wed, 05 Jan 2005 16:35:13 +0100 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Jeff Garzik , Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Paul Jakma Subject: Re: [patch 4/10] s390: network driver. References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> <1104895169.1117.63.camel@jzny.localdomain> In-Reply-To: <1104895169.1117.63.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="------------040400030706040102090604" X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040400030706040102090604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit jamal wrote: > On Tue, 2005-01-04 at 18:28, Jeff Garzik wrote: > >>jamal wrote: >> >>>The change is simple if theres consensus to go this path. >> >>Can you resend your patch? > > > I didnt send any patch - but heres one that looks right - havent tried > compiling it. Thank you for diving into this, Jamal. For the patch to have much effect, we need to check the carrier before calling hard_start_xmit(). Like in the modified patch below. >>My main objection was that any change should be made in the core, not in >>individual net drivers. > > > Attached patch resolves that concern Except for the drivers that call netif_stop_queue() on link-down. These calls (and the corresponding netif_wake_queue) would have to be removed. -Tommy --------------040400030706040102090604 Content-Type: text/plain; name="sch_generic.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sch_generic.c.patch" --- linux-2.6.10-bk7/net/sched/sch_generic.c Wed Jan 5 16:27:13 2005 +++ linux-2.6.10-work/net/sched/sch_generic.c Wed Jan 5 16:28:53 2005 @@ -134,7 +134,7 @@ /* And release queue */ spin_unlock(&dev->queue_lock); - if (!netif_queue_stopped(dev)) { + if (!netif_queue_stopped(dev) && netif_carrier_ok(dev)) { int ret; if (netdev_nit) dev_queue_xmit_nit(skb, dev); @@ -162,6 +162,11 @@ } spin_lock(&dev->queue_lock); q = dev->qdisc; + if (!netif_carrier_ok(dev)) { + kfree_skb(skb); + q->qstats.drops++; + return -1; + } } /* Device kicked us out :( --------------040400030706040102090604-- From Robert.Olsson@data.slu.se Tue Jan 4 20:31:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 20:31:19 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j054Un0X000656 for ; Tue, 4 Jan 2005 20:31:11 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j05GUYuA030779; Wed, 5 Jan 2005 17:30:34 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 9DDAFEC0BC; Wed, 5 Jan 2005 17:30:34 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16860.5674.612383.986202@robur.slu.se> Date: Wed, 5 Jan 2005 17:30:34 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson , Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501050918.22472.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501031656.57041.jeremy.guthrie@berbee.com> <16859.59675.522262.418329@robur.slu.se> <200501050918.22472.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > Yeah, the load will be high. I'm expecting this to be watching ~ 750 mbps by > next December. The app profiles all traffic going in and out of our data > centers. BW itself or pps is that not much of challange as handling of concurrent flows. > I'm not showing the /proc/net/rt_cache_stat file. Was there a kernel > option I need to recompile with for rt_cache_stat to show up in proc? No it's there without any options. Would be nice to the output from rtstat > > Also check that the CPU shares the RX packet load. CPU0 affinty to eth0 > > and CPU1 to eth1 seems to be best. It gives cache bouncing at "TX" and > > slab jobs but we have accept that for now. > How would I go about doing this? Assume you route packets between eth0 <-> eth1 Set eth0 irq to CPU0 and eth1 to CPU1 with /proc/irq/XX/smp_affinity Disable irqbalancer etc. > cat /proc/net/softnet_stat total droppped tsquz Throttl FR_hit FR_succe FR_defer FR_def_o cpu_coll > 5592c972 00000000 00001fc8 00000000 00000000 00000000 00000000 00000000 > 00391c3f > 000f1991 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 001292ba See! One line per CPU. So CPU0 is handing almost all packets. > "%soft" > Show the percentage of time spent by the CPU or CPUs to service > softirqs. A softirq (software interrupt) is one of up to 32 > enumerated software interrupts which can run on multiple CPUs Well yes. I had a more specific question. I'll look into mpstat where do find it? Kernel pacthes? Be also aware that packet forwarding with SMP/NUMA is very much research today it is not that easy or not even possible to get aggregated performance from several CPU's. in any setup. Well anyway we are beginning to see some benefits now as we better understand the problems. --ro From tgraf@suug.ch Tue Jan 4 20:48:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 20:48:48 -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 j054mIAZ001568 for ; Tue, 4 Jan 2005 20:48:42 -0800 Received: from postel.suug.ch (unknown [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 02C2D82; Wed, 5 Jan 2005 17:47:48 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 31A3F1C0EA; Wed, 5 Jan 2005 17:48:32 +0100 (CET) Date: Wed, 5 Jan 2005 17:48:32 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050105164832.GB17836@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> <1104894728.1117.56.camel@jzny.localdomain> <20050105110048.GO26856@postel.suug.ch> <1104931991.1117.152.camel@jzny.localdomain> <20050105144514.GQ26856@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050105144514.GQ26856@postel.suug.ch> X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13425 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 > Most importantly I don't want to touch any of the hashing code in u32. > I really like and it should stay as it is. The existing u32 match can > be easly made an ematch so this would safe us the extra work in u32 to > implement logic relations again and to fiddle with complicated selector > TLVs. The only problem with this is the nexthdr bits because it relies > on the hashing code. So we have to make this data available to the > ematch which is actually not a bad idea anyway. So I'm thinking about > introducing a new structure tcf_em_pkt_info or alike which carries > some additional information found out by the classifiers which can be > used by ematches. This can be information about the next header, > already extracted dscp values, etc. Here's what I mean, it moves the u32 match as-is to an ematch so it benefits from logic relations, inversion and can be used from other classifiers as well. All we have to do is set info->ptr and info->nexthdr to ptr respetively off2 before we evaluate the ematch tree. The pkt_info struct is then passed to tcf_em_tree_match and made available to every ematch. Thoughts? diff -Nru linux-2.6.10-bk8.orig/include/linux/pkt_cls.h linux-2.6.10-bk8/include/linux/pkt_cls.h --- linux-2.6.10-bk8.orig/include/linux/pkt_cls.h 2005-01-05 17:40:02.000000000 +0100 +++ linux-2.6.10-bk8/include/linux/pkt_cls.h 2005-01-05 17:38:42.000000000 +0100 @@ -351,6 +351,7 @@ TCF_EM_CONTAINER, TCF_EM_CMP, TCF_EM_NBYTE, + TCF_EM_U32, __TCF_EM_MAX }; diff -Nru linux-2.6.10-bk8.orig/include/net/pkt_cls.h linux-2.6.10-bk8/include/net/pkt_cls.h --- linux-2.6.10-bk8.orig/include/net/pkt_cls.h 2005-01-05 17:40:02.000000000 +0100 +++ linux-2.6.10-bk8/include/net/pkt_cls.h 2005-01-05 17:39:08.000000000 +0100 @@ -274,6 +274,8 @@ struct tcf_pkt_info { + u8 * ptr; + int nexthdr; }; static inline u32 tcf_read_bucket(u8 *ptr, u8 align) diff -Nru linux-2.6.10-bk8.orig/net/sched/Kconfig linux-2.6.10-bk8/net/sched/Kconfig --- linux-2.6.10-bk8.orig/net/sched/Kconfig 2005-01-05 17:38:26.000000000 +0100 +++ linux-2.6.10-bk8/net/sched/Kconfig 2005-01-05 17:41:59.000000000 +0100 @@ -408,6 +408,12 @@ To compile this code as a module, choose M here: the module will be called em_nbyte. +config NET_EMATCH_U32 + tristate "U32 hashing key" + depends on NET_EMATCH + ---help--- + TODO + config NET_CLS_ACT bool "Packet ACTION" depends on EXPERIMENTAL && NET_CLS && NET_QOS diff -Nru linux-2.6.10-bk8.orig/net/sched/Makefile linux-2.6.10-bk8/net/sched/Makefile --- linux-2.6.10-bk8.orig/net/sched/Makefile 2005-01-05 17:38:26.000000000 +0100 +++ linux-2.6.10-bk8/net/sched/Makefile 2005-01-05 17:40:15.000000000 +0100 @@ -36,3 +36,4 @@ obj-$(CONFIG_NET_EMATCH) += ematch.o obj-$(CONFIG_NET_EMATCH_CMP) += em_cmp.o obj-$(CONFIG_NET_EMATCH_NBYTE) += em_nbyte.o +obj-$(CONFIG_NET_EMATCH_U32) += em_u32.o diff -Nru linux-2.6.10-bk8.orig/net/sched/em_u32.c linux-2.6.10-bk8/net/sched/em_u32.c --- linux-2.6.10-bk8.orig/net/sched/em_u32.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.10-bk8/net/sched/em_u32.c 2005-01-05 17:38:42.000000000 +0100 @@ -0,0 +1,53 @@ +/* + * net/sched/em_u32.c U32 Ematch + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + * Alexey Kuznetsov, + * + * Based on net/sched/cls_u32.c + */ + +#include +#include +#include +#include +#include +#include + +static int em_u32_match(struct sk_buff *skb, struct tcf_ematch *m, + struct tcf_pkt_info *info) +{ + struct tc_u32_key *k = (struct tc_u32_key *) m->data; + u8 *ptr = info->ptr + k->off + (info->nexthdr & k->offmask); + + return !((*(u32*) ptr ^ k->val) & k->mask); +} + +static struct tcf_ematch_ops em_u32_ops = { + .kind = TCF_EM_U32, + .datalen = sizeof(struct tc_u32_key), + .match = em_u32_match, + .owner = THIS_MODULE, + .link = LIST_HEAD_INIT(em_u32_ops.link) +}; + +static int __init init_em_u32(void) +{ + return tcf_em_register(&em_u32_ops); +} + +static void __exit exit_em_u32(void) +{ + tcf_em_unregister(&em_u32_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_em_u32); +module_exit(exit_em_u32); + From jeremy.guthrie@berbee.com Tue Jan 4 21:35:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 21:35:44 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j055ZG2d003619 for ; Tue, 4 Jan 2005 21:35:36 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Jan 2005 11:35:04 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Wed, 5 Jan 2005 11:35:00 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501050918.22472.jeremy.guthrie@berbee.com> <16860.5674.612383.986202@robur.slu.se> In-Reply-To: <16860.5674.612383.986202@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2230455.ZoKKAJfLF7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501051135.03493.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 05 Jan 2005 17:35:04.0115 (UTC) FILETIME=[E3FAE030:01C4F34C] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart2230455.ZoKKAJfLF7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 January 2005 10:30 am, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > Yeah, the load will be high. I'm expecting this to be watching ~ 750 > > mbps by next December. The app profiles all traffic going in and out = of > > our data centers. > BW itself or pps is that not much of challange as handling of concurrent > flows. Roger that. > > I'm not showing the /proc/net/rt_cache_stat file. Was there a kernel > > option I need to recompile with for rt_cache_stat to show up in proc? > > No it's there without any options. Would be nice to the output from rtst= at Output from rtstat: rtstat fopen: No such file or directory cd /proc/net/ ls -la total 0 dr-xr-xr-x 5 root root 0 2005-01-04 08:53 . dr-xr-xr-x 72 root root 0 2005-01-04 08:53 .. =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 anycast6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 arp dr-xr-xr-x 2 root root 0 2005-01-05 10:32 atm =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 dev =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 dev_mcast dr-xr-xr-x 2 root root 0 2005-01-05 10:32 dev_snmp6 =2Dr--r--r-- 1 root root 0 2005-01-04 08:53 if_inet6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 igmp =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 igmp6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 ip6_flowlabel =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 ip_mr_cache =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 ip_mr_vif =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 ip_tables_matches =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 ip_tables_names =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 ip_tables_targets =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 ipv6_route =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 mcfilter =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 mcfilter6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 netlink =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 netstat =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 psched =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 raw =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 raw6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 route dr-xr-xr-x 6 root root 0 2005-01-05 10:32 rpc =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 rt6_stats =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 rt_acct =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 rt_cache =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 snmp =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 snmp6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 sockstat =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 sockstat6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 softnet_stat dr-xr-xr-x 2 root root 0 2005-01-05 10:32 stat =2Dr--r--r-- 1 root root 0 2005-01-04 08:53 tcp =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 tcp6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 tr_rif =2Dr--r--r-- 1 root root 0 2005-01-04 08:53 udp =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 udp6 =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 unix =2Dr--r--r-- 1 root root 0 2005-01-05 10:32 wireless > > > Also check that the CPU shares the RX packet load. CPU0 affinty to > > > eth0 and CPU1 to eth1 seems to be best. It gives cache bouncing at > > > "TX" and slab jobs but we have accept that for now. > > > > How would I go about doing this? > > Assume you route packets between eth0 <-> eth1 Yup > Set eth0 irq to CPU0 and eth1 to CPU1 with /proc/irq/XX/smp_affinity Done > Disable irqbalancer etc. Done I'll let you know what I see for stats once I get some collected. > > cat /proc/net/softnet_stat > > total droppped tsquz Throttl FR_hit FR_succe FR_defer FR_def_o > cpu_coll > > > 5592c972 00000000 00001fc8 00000000 00000000 00000000 00000000 00000000 > > 00391c3f > > 000f1991 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > 001292ba > > See! One line per CPU. So CPU0 is handing almost all packets. cat /proc/interrupts CPU0 CPU1 0: 674862 93484967 IO-APIC-edge timer 1: 564 9 IO-APIC-edge i8042 7: 0 0 IO-APIC-level ohci_hcd 8: 1 1 IO-APIC-edge rtc 12: 268 62 IO-APIC-edge i8042 14: 2 0 IO-APIC-edge ide0 18: 2105131410 9140835 IO-APIC-level eth3 20: 1077 248075156 IO-APIC-level eth2 27: 118224 1 IO-APIC-level eth0 28: 36298 49 IO-APIC-level aic7xxx 30: 0 0 IO-APIC-level acpi NMI: 0 0 LOC: 94168097 94168094 ERR: 0 MIS: 0 > > "%soft" > > Show the percentage of time spent by the CPU or CPUs to service > > softirqs. A softirq (software interrupt) is one of up to 32 > > enumerated software interrupts which can run on multiple CPUs > > Well yes. I had a more specific question. I'll look into mpstat where do > find it? Kernel pacthes? Sorry about that. New to the list. I'm not suggesting anything. I=20 appreciate the help! Suse listed mpstat as part of sysstat 5.1.2. I'm running stock 2.6.10. > Be also aware that packet forwarding with SMP/NUMA is very much research > today it is not that easy or not even possible to get aggregated > performance from several CPU's. in any setup. Well anyway we are beginning > to see some benefits now as we better understand the problems. Understood. As long as I know this, I can articulate this to my uppers for= =20 bigger hardware. My current system is a dual P-III 700mhz. May be time fo= r=20 an upgrade. However, I figure this may also offer a good environment to he= lp=20 provide you guys with a taxed system running an load of flows. Nothing lik= e=20 finding fun stuff while a system is ready to fall over. Would a single hyper threaded CPU help this or should I default to a normal= =20 dual-cpu system? =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart2230455.ZoKKAJfLF7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3CVHqtjaBHGZBeURAnY6AJ9bDuvkkdvq4Fz4e7cFE9fAwy69zwCfb5Yi QuzCimWD5bzoT/f5J+D8DTk= =XYHB -----END PGP SIGNATURE----- --nextPart2230455.ZoKKAJfLF7-- From jeremy.guthrie@berbee.com Tue Jan 4 23:26:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 23:26:23 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j057Pt8u007072 for ; Tue, 4 Jan 2005 23:26:16 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Jan 2005 13:25:41 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Wed, 5 Jan 2005 13:25:37 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <16860.5674.612383.986202@robur.slu.se> <200501051135.03493.jeremy.guthrie@berbee.com> In-Reply-To: <200501051135.03493.jeremy.guthrie@berbee.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1848405.zG5ppPKG5L"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501051325.40616.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 05 Jan 2005 19:25:41.0432 (UTC) FILETIME=[58211380:01C4F35C] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart1848405.zG5ppPKG5L Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline After smp_affinity adjustments and turning off IRQ balancing. eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 inet addr:10.253.0.1 Bcast:10.255.255.255 Mask:255.255.255.0 inet6 addr: fe80::202:b3ff:fed5:7e30/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:537271635 errors:2377048 dropped:2377048 overruns:1849= 169=20 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1804727106 (1721.1 Mb) TX bytes:398 (398.0 b) Base address:0x22a0 Memory:eff80000-effa0000 =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart1848405.zG5ppPKG5L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3D80qtjaBHGZBeURAjNkAJ9CabJ3ZnVy6UfHF2bkQ+XyJUP/ugCgmZhw jZ4s0v7Q+e7diEU0AjwVY/8= =Df1l -----END PGP SIGNATURE----- --nextPart1848405.zG5ppPKG5L-- From johannes@erdfelt.com Tue Jan 4 23:34:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 23:34:59 -0800 (PST) Received: from farley.sventech.com (IDENT:daemon@farley.sventech.com [69.36.241.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j057YWxZ007803 for ; Tue, 4 Jan 2005 23:34:52 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 500) by farley.sventech.com with local; Wed, 05 Jan 2005 19:34:25 +0000 Date: Wed, 5 Jan 2005 11:34:25 -0800 From: Johannes Erdfelt To: netdev@oss.sgi.com Subject: [RFC] tulip VLAN support Message-ID: <20050105193425.GY18847@sventech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johannes@erdfelt.com Precedence: bulk X-list: netdev I recently upgraded a system running a 2.4 kernel to a 2.6 based distribution (Fedora Core 2, 2.6.9-1.6_FC2 kernel) and ran into a problem using NFS. After spending some tracking it down, I found out it was an MTU problem and then remembered I had the same problem a couple of years ago with the 2.4 kernels I was running. The problem is that the tulip driver doesn't handle 802.1q tags correctly. Since the VLAN tagging adds 4 bytes to the beginning of the frame, this can cause frame sizes to be too large for the driver (chip?) and the packets get dropped. I've taken the 2.4 patch I found (I forget who developed it, sorry) and ported it to the 2.6 driver. The patch is relative to the 2.6.9-1.6_FC2 kernel for FC2, but I suspect it will apply to other kernels relatively cleanly. Before I rediff the patch against the BK tree and double check all of the tulip variants are updated correctly as well, is there any interest in accepting a patch like this? The 2.4 patch worked for a couple of years for me with no problems and this 2.6 patch has worked for over a week now with no problems. However, I'm worried that there is a reason why a similar patch has not been applied already. JE diff -ur linux-2.6.9.orig/drivers/net/tulip/interrupt.c linux-2.6.9/drivers/net/tulip/interrupt.c --- linux-2.6.9.orig/drivers/net/tulip/interrupt.c 2004-10-18 14:55:36.000000000 -0700 +++ linux-2.6.9/drivers/net/tulip/interrupt.c 2004-12-30 15:23:51.085876693 -0800 @@ -155,9 +155,9 @@ if (--rx_work_limit < 0) goto not_done; - if ((status & 0x38008300) != 0x0300) { - if ((status & 0x38000300) != 0x0300) { - /* Ingore earlier buffers. */ + if ((status & (0x38000000 | RxDescFatalErr | RxWholePkt)) != RxWholePkt) { + if ((status & (0x38000000 | RxWholePkt)) != RxWholePkt) { + /* Ignore earlier buffers. */ if ((status & 0xffff) != 0x7fff) { if (tulip_debug > 1) printk(KERN_WARNING "%s: Oversized Ethernet frame " @@ -182,10 +182,10 @@ struct sk_buff *skb; #ifndef final_version - if (pkt_len > 1518) { + if (pkt_len > 1522) { printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", dev->name, pkt_len, pkt_len); - pkt_len = 1518; + pkt_len = 1522; tp->stats.rx_length_errors++; } #endif @@ -378,9 +378,9 @@ dev->name, entry, status); if (--rx_work_limit < 0) break; - if ((status & 0x38008300) != 0x0300) { - if ((status & 0x38000300) != 0x0300) { - /* Ingore earlier buffers. */ + if ((status & (0x38000000 | RxDescFatalErr | RxWholePkt)) != RxWholePkt) { + if ((status & (0x38000000 | RxWholePkt)) != RxWholePkt) { + /* Ignore earlier buffers. */ if ((status & 0xffff) != 0x7fff) { if (tulip_debug > 1) printk(KERN_WARNING "%s: Oversized Ethernet frame " @@ -405,10 +405,10 @@ struct sk_buff *skb; #ifndef final_version - if (pkt_len > 1518) { + if (pkt_len > 1522) { printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", dev->name, pkt_len, pkt_len); - pkt_len = 1518; + pkt_len = 1522; tp->stats.rx_length_errors++; } #endif diff -ur linux-2.6.9.orig/drivers/net/tulip/tulip.h linux-2.6.9/drivers/net/tulip/tulip.h --- linux-2.6.9.orig/drivers/net/tulip/tulip.h 2004-10-18 14:55:21.000000000 -0700 +++ linux-2.6.9/drivers/net/tulip/tulip.h 2004-12-30 15:20:21.432056171 -0800 @@ -191,7 +191,7 @@ enum desc_status_bits { DescOwned = 0x80000000, - RxDescFatalErr = 0x8000, + RxDescFatalErr = 0x4842, RxWholePkt = 0x0300, }; @@ -259,7 +259,7 @@ #define RX_RING_SIZE 128 #define MEDIA_MASK 31 -#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */ +#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. */ #define TULIP_MIN_CACHE_LINE 8 /* in units of 32-bit words */ diff -ur linux-2.6.9.orig/drivers/net/tulip/tulip_core.c linux-2.6.9/drivers/net/tulip/tulip_core.c --- linux-2.6.9.orig/drivers/net/tulip/tulip_core.c 2004-10-18 14:54:32.000000000 -0700 +++ linux-2.6.9/drivers/net/tulip/tulip_core.c 2004-12-30 15:19:42.424578510 -0800 @@ -70,7 +70,7 @@ #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \ || defined(__sparc_) || defined(__ia64__) \ || defined(__sh__) || defined(__mips__) -static int rx_copybreak = 1518; +static int rx_copybreak = 1522; #else static int rx_copybreak = 100; #endif From mcgrof@studorgs.rutgers.edu Wed Jan 5 00:05:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:06:01 -0800 (PST) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0585XWl009173 for ; Wed, 5 Jan 2005 00:05:54 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 98475F9D4D; Wed, 5 Jan 2005 15:05:26 -0500 (EST) Date: Wed, 5 Jan 2005 15:05:26 -0500 To: prism54-devel@prism54.org, prism54-users@prism54.org Cc: Netdev , linux-kernel@vger.kernel.org, Jeff Garzik , Jean Tourrilhes , mcgrof@studorgs.rutgers.edu Subject: Open hardware wireless cards Message-ID: <20050105200526.GL5159@ruslug.rutgers.edu> Mail-Followup-To: prism54-devel@prism54.org, prism54-users@prism54.org, Netdev , linux-kernel@vger.kernel.org, Jeff Garzik , Jean Tourrilhes Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF" Content-Disposition: inline In-Reply-To: <20050105192447.GJ5159@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev --FN+gV9K+162wdwwF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2005 at 02:24:47PM -0500, Luis R. Rodriguez wrote: <-- snip --> > As far as support for the new chipsets goes -- sorry -- we won't be able > to support it as I don't think even Conexant has a final well tested > linux source base ready for 2.6. And even if we are given a source base > there is nothing we can do to get around the need for the closed-source= =20 > softmac libs that it relies on. As much as I'd like to support it, I > don't want to get a headache to support something I cannot modify so I > won't be willing to support a half-opened driver as the atheros driver. I'd also like to add... For those of you frustrated about our current wireless driver situation in open platforms -- I think we probably will have this trouble with most modern hardware for a = while (graphics cards, wireless driver, etc). A lot of has to do with patent infringement issues, "intellectual property" protection, and other business-oriented excuses. What I think we probably will have to do is just work torwards seeing if we can come up with our own open wireless hardware. I know there was a recent thread on lkml about an open video card -- anyone know where that ended up? If we can't come up with our own project to work on open hardware we can also just see if its feasible to purchase hardware companies on the verge of going backrupt and buy them out and release the specs/etc (a la blender). Can someone do the math here? I'm lazy. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --FN+gV9K+162wdwwF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB3EiGat1JN+IKUl4RAt6mAJ9gbrBRF/ua2WuCBHLQcrpy012SxQCgjAlq HLlowOyG5hYmToywmmfBsNA= =g6/K -----END PGP SIGNATURE----- --FN+gV9K+162wdwwF-- From lsorense@csclub.uwaterloo.ca Wed Jan 5 00:15:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:15:09 -0800 (PST) Received: from perpugilliam.csclub.uwaterloo.ca (postfix@perpugilliam.csclub.uwaterloo.ca [129.97.134.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j058EfmB010282 for ; Wed, 5 Jan 2005 00:15:02 -0800 Received: by perpugilliam.csclub.uwaterloo.ca (Postfix, from userid 3120) id 8C5F5A85E1; Wed, 5 Jan 2005 15:14:34 -0500 (EST) Date: Wed, 5 Jan 2005 15:14:34 -0500 To: prism54-devel@prism54.org, prism54-users@prism54.org, Netdev , linux-kernel@vger.kernel.org, Jeff Garzik , Jean Tourrilhes Subject: Re: Open hardware wireless cards Message-ID: <20050105201434.GB30311@csclub.uwaterloo.ca> References: <20050105192447.GJ5159@ruslug.rutgers.edu> <20050105200526.GL5159@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050105200526.GL5159@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lsorense@csclub.uwaterloo.ca Precedence: bulk X-list: netdev On Wed, Jan 05, 2005 at 03:05:26PM -0500, Luis R. Rodriguez wrote: > I'd also like to add... > > For those of you frustrated about our current wireless driver situation > in open platforms -- > > I think we probably will have this trouble with most modern hardware for a while > (graphics cards, wireless driver, etc). A lot of has to do with patent > infringement issues, "intellectual property" protection, and other > business-oriented excuses. > > What I think we probably will have to do is just work torwards seeing if > we can come up with our own open wireless hardware. I know there was > a recent thread on lkml about an open video card -- anyone know where > that ended up? > > If we can't come up with our own project to work on open hardware we can > also just see if its feasible to purchase hardware companies on the > verge of going backrupt and buy them out and release the specs/etc (a la > blender). Can someone do the math here? I'm lazy. Being open doesn't mean you aren't violating some stupid patent. Software patents really are an incredibly stupid idea. Algorithms are pushing it. After all what does the algorithm do on it's own? Can you show it working and doing something? Len Sorensen From Robert.Olsson@data.slu.se Wed Jan 5 00:23:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:23:40 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j058N8sL014258 for ; Wed, 5 Jan 2005 00:23:29 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j05KMtuA001260; Wed, 5 Jan 2005 21:22:55 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 455B8EC0BC; Wed, 5 Jan 2005 21:22:55 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16860.19615.251360.169722@robur.slu.se> Date: Wed, 5 Jan 2005 21:22:55 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson , Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501051325.40616.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <16860.5674.612383.986202@robur.slu.se> <200501051135.03493.jeremy.guthrie@berbee.com> <200501051325.40616.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > After smp_affinity adjustments and turning off IRQ balancing. > > eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 > RX packets:537271635 errors:2377048 dropped:2377048 overruns:1849169 Worse? Yes. I'll remember Hararld moved rt_cache_stat /proc/net/stats/ and wrote a new utility for it. Should be in iproute2 package. Stephen knows the details. Otherwise change path in rtstat. You need this to relate and verify the load. Check throughtput and how packet load is used with 2.4. /proc/net/softnet_stat and rtstat. Also meditate how the comparison can be fair wrt taffic patterns. Do smame with 2.6. Prepare for a oprofile. I'm lazy and compile the stuff I use into kernel if you can get the same result w. nodules it's ok. --ro From dhollis@davehollis.com Wed Jan 5 00:23:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:23:29 -0800 (PST) Received: from pop-a065d23.pas.sa.earthlink.net (pop-a065d23.pas.sa.earthlink.net [207.217.121.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j058N1xB014251 for ; Wed, 5 Jan 2005 00:23:22 -0800 Received: from user-12hcjeo.cable.mindspring.com ([69.22.77.216] helo=bender.davehollis.com) by pop-a065d23.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CmHgE-0007Pn-00 for netdev@oss.sgi.com; Wed, 05 Jan 2005 12:22:54 -0800 Received: from 10.8.0.6 ([10.8.0.6]) (authenticated bits=0) by bender.davehollis.com (8.13.1/8.12.11) with ESMTP id j05KMl9I020266 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Jan 2005 15:22:50 -0500 Subject: Network driver test suite? From: David Hollis To: Netdev Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iN/CSXxyVrLxrJOpvhY/" Date: Wed, 05 Jan 2005 15:19:46 -0500 Message-Id: <1104956386.3877.58.camel@dhollis-lnx.centricconsulting.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Scanned-By: MIMEDefang 2.49 on 10.8.0.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dhollis@davehollis.com Precedence: bulk X-list: netdev --=-iN/CSXxyVrLxrJOpvhY/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is there any kind of test suite (automated or list of tests) available for testing Linux network drivers? I'm completing the addition of a few new USB ethernet devices and would like to able to test all possible scenarios instead of coming across them piece-meal in the future. I'm not a big fan of the "works on my box" testing that I'm doing now. I'm sure there are all kinds of things that I'm not testing that aren't everyday types of things such as VLANs, multicasting, various ethtool/mii-tool things, large packets, etc. If there isn't anything like this, maybe it would be a useful thing to develop? At a minimum, maybe to set the treshhold for minimum features that drivers support and the like. --=20 David Hollis --=-iN/CSXxyVrLxrJOpvhY/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBB3EvhxasLqOyGHncRAgMDAKCO/pkUIwy3BdKNud9stqyPDF/VZgCfXiWi zIyyHfUy0G/ue6WPaUnMhmI= =QxIc -----END PGP SIGNATURE----- --=-iN/CSXxyVrLxrJOpvhY/-- From steve@nexusuk.org Wed Jan 5 00:28:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:28:58 -0800 (PST) Received: from rivendell.nexusuk.org (rivendell.nexusuk.org [84.92.27.250]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j058STZh015302 for ; Wed, 5 Jan 2005 00:28:50 -0800 Received: from rivendell.nexusuk.org (localhost [127.0.0.1]) by rivendell.nexusuk.org (8.13.1/8.13.1) with ESMTP id j05KMDmb008700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jan 2005 20:22:13 GMT Date: Wed, 5 Jan 2005 20:22:10 +0000 (GMT) From: Steve Hill To: "Luis R. Rodriguez" cc: prism54-devel@prism54.org, prism54-users@prism54.org, Netdev , Jean Tourrilhes , Jeff Garzik , linux-kernel@vger.kernel.org Subject: Re: [Prism54-users] Open hardware wireless cards In-Reply-To: <20050105200526.GL5159@ruslug.rutgers.edu> Message-ID: References: <20050105200526.GL5159@ruslug.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@nexusuk.org Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 5 Jan 2005, Luis R. Rodriguez wrote: > What I think we probably will have to do is just work torwards seeing if > we can come up with our own open wireless hardware. I know there was > a recent thread on lkml about an open video card -- anyone know where > that ended up? This may be a silly point, but there *was* good 802.11g hardware available which worked well with the fully open drivers. I presume the manufacturers are moving to the "softmac" design instead because (for them) it is cheaper. However, the point is that the working designs are already there and it may be that buying the existing design which is being phased out is cheaper for the FOSS community than developing a whole new open device. Maybe it would be possible to convince one of the manufacturers that it's worth their while producing the older design hardware - if there is a single manufacturer who is making more or less the only hardware that is guaranteed to work under Linux there is probably quite a market for them. - Steve Jabber: steve@nexusuk.org Web: http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Public key available at http://www.nexusuk.org/pubkey.txt iD8DBQFB3Ex15zUOsIV3bqERAuInAKCGVS1kzaR4En2nQnKhDPv6TptZ+QCdEzFN y8HbDEpnxvJql8AVpDePcnA= =NfEa -----END PGP SIGNATURE----- From mcgrof@studorgs.rutgers.edu Wed Jan 5 00:37:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:37:20 -0800 (PST) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j058aqd0016599 for ; Wed, 5 Jan 2005 00:37:13 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 953A4F9D6B; Wed, 5 Jan 2005 15:36:45 -0500 (EST) Date: Wed, 5 Jan 2005 15:36:45 -0500 To: Steve Hill Cc: "Luis R. Rodriguez" , prism54-devel@prism54.org, prism54-users@prism54.org, Netdev , Jean Tourrilhes , Jeff Garzik , linux-kernel@vger.kernel.org Subject: Re: [Prism54-users] Open hardware wireless cards Message-ID: <20050105203645.GO5159@ruslug.rutgers.edu> Mail-Followup-To: Steve Hill , "Luis R. Rodriguez" , prism54-devel@prism54.org, prism54-users@prism54.org, Netdev , Jean Tourrilhes , Jeff Garzik , linux-kernel@vger.kernel.org References: <20050105200526.GL5159@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Il7n/DHsA0sMLmDu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev --Il7n/DHsA0sMLmDu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2005 at 08:22:10PM +0000, Steve Hill wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On Wed, 5 Jan 2005, Luis R. Rodriguez wrote: >=20 > >What I think we probably will have to do is just work torwards seeing if > >we can come up with our own open wireless hardware. I know there was > >a recent thread on lkml about an open video card -- anyone know where > >that ended up? >=20 > This may be a silly point, but there *was* good 802.11g hardware availabl= e=20 > which worked well with the fully open drivers.=20 Yes, that would be the Full MAC prism chipsets with the linux prism54 drive= r, which I help maintain. > I presume the=20 > manufacturers are moving to the "softmac" design instead because (for=20 > them) it is cheaper. That is correct. They have already moved to the Softmac design and you're lucky if you can buy FullMAC chipsets in stores now. > However, the point is that the working designs are=20 > already there and it may be that buying the existing design which is bein= g=20 > phased out is cheaper for the FOSS community than developing a whole new= =20 > open device. Definitely, I agree. Anyone have an idea of how much buying a wireless chipset design may cost? > Maybe it would be possible to convince one of the manufacturers that it's= =20 > worth their while producing the older design hardware - if there is a=20 > single manufacturer who is making more or less the only hardware that is= =20 > guaranteed to work under Linux there is probably quite a market for them. I think they made the move because of economics as you mentioned earlier. Under the current circumstances, I find it hard to be able to Convince Conexant, for example, to start selling FullMAC chipsets again. AFAICT the FullMAC chipsets have reached the END OF LIFE period. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --Il7n/DHsA0sMLmDu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB3E/dat1JN+IKUl4RAn+zAJ9Nqm7B2/Z/4ouMrwSdYqjNQlSLRQCfdWtT Zum49MFe0zuSx+3O2yHHpKE= =uXsP -----END PGP SIGNATURE----- --Il7n/DHsA0sMLmDu-- From jeremy.guthrie@berbee.com Wed Jan 5 00:53:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:53:43 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j058rGC8017504 for ; Wed, 5 Jan 2005 00:53:36 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Jan 2005 14:53:03 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Wed, 5 Jan 2005 14:52:57 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501051325.40616.jeremy.guthrie@berbee.com> <16860.19615.251360.169722@robur.slu.se> In-Reply-To: <16860.19615.251360.169722@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2053757.ArktrbUOaq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501051453.03022.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 05 Jan 2005 20:53:03.0854 (UTC) FILETIME=[8CDB30E0:01C4F368] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart2053757.ArktrbUOaq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 January 2005 02:22 pm, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > After smp_affinity adjustments and turning off IRQ balancing. > > > > eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 > > > > RX packets:537271635 errors:2377048 dropped:2377048 > > overruns:1849169 > > Worse? > > Yes. I'll remember Hararld moved rt_cache_stat /proc/net/stats/ and wrote > a new utility for it. Should be in iproute2 package. Stephen knows the > details. Otherwise change path in rtstat. You need this to relate and > verify the load. Hm... ls -la /proc/net/stat/ total 0 dr-xr-xr-x 2 root root 0 Jan 5 14:47 . dr-xr-xr-x 5 root root 0 Jan 5 11:50 .. =2Dr--r--r-- 1 root root 0 Jan 5 14:47 arp_cache =2Dr--r--r-- 1 root root 0 Jan 5 14:47 clip_arp_cache =2Dr--r--r-- 1 root root 0 Jan 5 14:47 ndisc_cache =2Dr--r--r-- 1 root root 0 Jan 5 14:47 rt_cache > Check throughtput and how packet load is used with 2.4. > /proc/net/softnet_stat and rtstat.=20 Will do. > Also meditate how the comparison can be=20 > fair wrt taffic patterns. Do smame with 2.6. Not sure I follow. I can see higher pps/byte through puts on switch port=20 counters when I run with 2.4 vs 2.6. I'll double check though. I am the=20 'dev' state so I can swap between V2.4 and V2.6 as necessary to compare=20 during roughly equivalent times. The only delay is the time between reboot= s. > Prepare for a oprofile. I'm lazy and compile the stuff I use into kernel > if you can get the same result w. nodules it's ok. Okay. > > > --ro =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart2053757.ArktrbUOaq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3FOuqtjaBHGZBeURArx5AJoD1hHvaB93tJpQtWF6wrOGpNfBugCfTtEj L/NGCQWMNHjI4Au8pD6LJNc= =4LXK -----END PGP SIGNATURE----- --nextPart2053757.ArktrbUOaq-- From linux-os@chaos.analogic.com Wed Jan 5 00:56:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 00:56:36 -0800 (PST) Received: from chaos.analogic.com (alog0237.analogic.com [208.224.220.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j058u80r018030 for ; Wed, 5 Jan 2005 00:56:29 -0800 Received: from chaos.analogic.com (localhost.localdomain [127.0.0.1]) by chaos.analogic.com (8.12.11/8.12.11) with ESMTP id j05KmklR012273; Wed, 5 Jan 2005 15:48:46 -0500 Received: (from linux-os@localhost) by chaos.analogic.com (8.12.11/8.12.11/Submit) id j05KmkPP012272; Wed, 5 Jan 2005 15:48:46 -0500 Date: Wed, 5 Jan 2005 15:48:46 -0500 (EST) From: linux-os Reply-To: linux-os@analogic.com To: lsorense@csclub.uwaterloo.ca cc: prism54-devel@prism54.org, prism54-users@prism54.org, Netdev , linux-kernel@vger.kernel.org, Jeff Garzik , Jean Tourrilhes Subject: Re: Open hardware wireless cards In-Reply-To: <20050105201434.GB30311@csclub.uwaterloo.ca> Message-ID: References: <20050105192447.GJ5159@ruslug.rutgers.edu> <20050105200526.GL5159@ruslug.rutgers.edu> <20050105201434.GB30311@csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux-os@chaos.analogic.com Precedence: bulk X-list: netdev On Wed, 5 Jan 2005 lsorense@csclub.uwaterloo.ca wrote: > On Wed, Jan 05, 2005 at 03:05:26PM -0500, Luis R. Rodriguez wrote: >> I'd also like to add... >> >> For those of you frustrated about our current wireless driver situation >> in open platforms -- >> >> I think we probably will have this trouble with most modern hardware for a while >> (graphics cards, wireless driver, etc). A lot of has to do with patent >> infringement issues, "intellectual property" protection, and other >> business-oriented excuses. >> >> What I think we probably will have to do is just work torwards seeing if >> we can come up with our own open wireless hardware. I know there was >> a recent thread on lkml about an open video card -- anyone know where >> that ended up? >> >> If we can't come up with our own project to work on open hardware we can >> also just see if its feasible to purchase hardware companies on the >> verge of going backrupt and buy them out and release the specs/etc (a la >> blender). Can someone do the math here? I'm lazy. > > Being open doesn't mean you aren't violating some stupid patent. > Software patents really are an incredibly stupid idea. Algorithms are > pushing it. After all what does the algorithm do on it's own? Can you > show it working and doing something? > > Len Sorensen Well its mostly about making boards just a bit too cheap. If the vendors would just put in a serial EPROM that loads the proprietary stuff to their PLD upon startup, then there is no "proprietary" code to worry about. You have the generic published interface like a PLX chip, plus the specific published register functions of their PLD chip. How the device actually makes smoke and mirrors is hidden even from the programmer. But, by eliminating the US$0.50 cost of a EPROM, they want to supply a sack of bits that needs to be uploaded to the PLD by software. This sack of bits can be reverse-engineered so companies are not going to supply these (you can extract those bits from a Win-Modem dll so this gets a bit too ridiculous for some devices). In most cases it's not some algorithm that needs to be protected. Instead its the 400-or-so engineering man-hours used to develop the contents of the PLD (notice I did not use the words "Gate-Arrays" until now. There are many kinds of Programmable Logic Devices). Until vendors stop being penny-wise-pound-foolish, we will continue to have these kinds of problems. Vendor education will ultimately be the fix, I predict. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. From akpm@osdl.org Wed Jan 5 01:36:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 01:36:14 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j059Zkc6019701 for ; Wed, 5 Jan 2005 01:36:06 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j05LZYd02938 for ; Wed, 5 Jan 2005 13:35:34 -0800 Date: Wed, 5 Jan 2005 13:35:25 -0800 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 3992] New: Bondig. Not correct work function ARP Monitoring. Broken link. Message-Id: <20050105133525.2bab2e09.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j059Zkc6019701 X-archive-position: 13438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Wed, 5 Jan 2005 07:59:17 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 3992] New: Bondig. Not correct work function ARP Monitoring. Broken link. http://bugme.osdl.org/show_bug.cgi?id=3992 Summary: Bondig. Not correct work function ARP Monitoring. Broken link. Kernel Version: 2.6.10 Status: NEW Severity: normal Owner: jgarzik@pobox.com Submitter: stanislav@muhachev.petro.ru Distribution: Hardware Environment: Vmware GSX machine Software Environment: Gentoo Problem Description: bonding interface going down and down slave link Steps to reproduce: 2 virtual pc identical gentoo linux (copy) 1 nic for both virtual pc up 2 openvpn link trouch nic to another virtual pc (tap0 and tap1)[ethernet bridge] link both vpn1 and vpn2 - ok!(independing link like:192.168.1.1-192.168.1.2 and 192.168.2.1-192.168.2.2) bonding vpn1 & vpn2 òî bond0 (bonding default setup -> nothing failover setings) link îê!(192.168.100.1-192.168.100.2) setting arp monitor in bonding (TUN/TAP driver not support Mii status) link down! arp request go from bond0(machine1)[from tap0 & tap1] to bond0(machine2) - ok. arp answer bond0(machine2) interface - ok! !!! bond0(machine2) -> tap0(tap1)(machine2) - noting!!!(arp answer broken) resultat arp request not complite situation analog both side for monitoring use TCPDUMP ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From lsorense@csclub.uwaterloo.ca Wed Jan 5 01:35:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 01:35:47 -0800 (PST) Received: from perpugilliam.csclub.uwaterloo.ca (postfix@perpugilliam.csclub.uwaterloo.ca [129.97.134.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j059ZLvm019690 for ; Wed, 5 Jan 2005 01:35:41 -0800 Received: by perpugilliam.csclub.uwaterloo.ca (Postfix, from userid 3120) id 4D665A8600; Wed, 5 Jan 2005 16:35:10 -0500 (EST) Date: Wed, 5 Jan 2005 16:35:10 -0500 To: linux-os@analogic.com Cc: prism54-devel@prism54.org, prism54-users@prism54.org, Netdev , linux-kernel@vger.kernel.org, Jeff Garzik , Jean Tourrilhes Subject: Re: Open hardware wireless cards Message-ID: <20050105213510.GP28140@csclub.uwaterloo.ca> References: <20050105192447.GJ5159@ruslug.rutgers.edu> <20050105200526.GL5159@ruslug.rutgers.edu> <20050105201434.GB30311@csclub.uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lsorense@csclub.uwaterloo.ca Precedence: bulk X-list: netdev On Wed, Jan 05, 2005 at 03:48:46PM -0500, linux-os wrote: > Well its mostly about making boards just a bit too cheap. > > If the vendors would just put in a serial EPROM that loads the > proprietary stuff to their PLD upon startup, then there is > no "proprietary" code to worry about. You have the generic > published interface like a PLX chip, plus the specific published > register functions of their PLD chip. How the device actually > makes smoke and mirrors is hidden even from the programmer. > > But, by eliminating the US$0.50 cost of a EPROM, they want to supply > a sack of bits that needs to be uploaded to the PLD by software. This > sack of bits can be reverse-engineered so companies are not going > to supply these (you can extract those bits from a Win-Modem dll so > this gets a bit too ridiculous for some devices). > > In most cases it's not some algorithm that needs to be protected. > Instead its the 400-or-so engineering man-hours used to develop the > contents of the PLD (notice I did not use the words "Gate-Arrays" > until now. There are many kinds of Programmable Logic Devices). > > Until vendors stop being penny-wise-pound-foolish, we will continue > to have these kinds of problems. Vendor education will ultimately > be the fix, I predict. Well unfortunately I think you underestimate the cost of the serial eprom needed to do the load on an fpga or pld or the like. According to our suppliers they are actually rather hard to get for some reason (that I don't understand) and are more than $0.50. The product I am current working on software for would be a whole lot simpler if we could just program an eprom with the fpga code, but instead we have to load it via jtag through the parallel port to save a fair bit of moeny on eprom chips assuming we could even get them in the quantities we would need. The winmodem is just a sound card with the cpu doing the actual algorihtm. That is different and would not be solved with an eprom, only with a real DSP or other chip capable of doing the modulation and demodulation of the signals. I guess calling them modem's is being too generous, more like phone line sampler cards. Len Sorensen From flamingice@sourmilk.net Wed Jan 5 01:54:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 01:54:29 -0800 (PST) Received: from server8.totalchoicehosting.com (server8.totalchoicehosting.com [216.180.241.250]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j059s1sc021459 for ; Wed, 5 Jan 2005 01:54:22 -0800 Received: from host-24-225-148-91.patmedia.net ([24.225.148.91] helo=[192.168.0.100]) by server8.totalchoicehosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1CmJ6L-0005XA-GJ for netdev@oss.sgi.com; Wed, 05 Jan 2005 16:53:57 -0500 From: Michael Wu To: netdev@oss.sgi.com Subject: Re: [Prism54-users] Open hardware wireless cards Date: Wed, 5 Jan 2005 16:53:30 -0500 User-Agent: KMail/1.7.1 References: <20050105200526.GL5159@ruslug.rutgers.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1788797.UstzDMJBSy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501051653.41053.flamingice@sourmilk.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server8.totalchoicehosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - sourmilk.net X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: flamingice@sourmilk.net Precedence: bulk X-list: netdev --nextPart1788797.UstzDMJBSy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 January 2005 3:22 pm, Steve Hill wrote: > On Wed, 5 Jan 2005, Luis R. Rodriguez wrote: > > What I think we probably will have to do is just work torwards seeing if > > we can come up with our own open wireless hardware. I know there was > > a recent thread on lkml about an open video card -- anyone know where > > that ended up? > > This may be a silly point, but there *was* good 802.11g hardware available > which worked well with the fully open drivers. I presume the > manufacturers are moving to the "softmac" design instead because (for > them) it is cheaper. However, the point is that the working designs are > already there and it may be that buying the existing design which is being > phased out is cheaper for the FOSS community than developing a whole new > open device. Softmac doesn't necessary mean evil all the time. The adm8211 has a fully G= PL=20 driver for Linux. There is no firmware to worry about either. ADMtek actual= ly=20 helped me with the driver, by providing the source to their old 2.4 binary= =20 Linux driver and sending me (from Taiwan to New Jersey, fedexed overnight)= =20 two sample cards to test with. Oh yes, and it's quite cheap. (but 802.11b,= =20 which maybe a problem for some people) If ADMtek can do it, why can't other manufacturers? =2DMichael Wu --nextPart1788797.UstzDMJBSy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBB3GHlyWWBbDEe0UIRAv60AJ4r2kU8cLsPl+Hu1OGKu+6GTaAqegCgvKfh ogmmOEs5Gv4d17bomnelBzE= =2oNQ -----END PGP SIGNATURE----- --nextPart1788797.UstzDMJBSy-- From jgarzik@pobox.com Wed Jan 5 02:11:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:11:23 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05AAsMs023442 for ; Wed, 5 Jan 2005 02:11:15 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CmJMc-0000TV-Ts; Wed, 05 Jan 2005 22:10:47 +0000 Message-ID: <41DC65DB.1010907@pobox.com> Date: Wed, 05 Jan 2005 17:10:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Hollis CC: Netdev Subject: Re: Network driver test suite? References: <1104956386.3877.58.camel@dhollis-lnx.centricconsulting.com> In-Reply-To: <1104956386.3877.58.camel@dhollis-lnx.centricconsulting.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David Hollis wrote: > Is there any kind of test suite (automated or list of tests) available > for testing Linux network drivers? I'm completing the addition of a few No, but I would love to someone to write one!!! Jeff (in a rare case of multi-exclamation-point use) From jgarzik@pobox.com Wed Jan 5 02:13:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:13:37 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05AD9sH025003 for ; Wed, 5 Jan 2005 02:13:29 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CmJOm-0000Ww-Qn; Wed, 05 Jan 2005 22:13:00 +0000 Message-ID: <41DC6669.9090407@pobox.com> Date: Wed, 05 Jan 2005 17:12:57 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johannes Erdfelt CC: netdev@oss.sgi.com Subject: Re: [RFC] tulip VLAN support References: <20050105193425.GY18847@sventech.com> In-Reply-To: <20050105193425.GY18847@sventech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Johannes Erdfelt wrote: > @@ -259,7 +259,7 @@ > #define RX_RING_SIZE 128 > #define MEDIA_MASK 31 > > -#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */ > +#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. */ This is the reason why the tulip "vlan" patch is continually rejected. You shouldn't need to increase this constant, but rather follow the other "large MTU" driver conversions. Donald Becker's tulip.c (on which the kernel tulip is based) supports proper MTU changing: ftp://ftp.scyld.com/pub/network/ Jeff From greearb@candelatech.com Wed Jan 5 02:18:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:18:33 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05AI67t025652 for ; Wed, 5 Jan 2005 02:18:26 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j05MXhLH011923; Wed, 5 Jan 2005 14:33:43 -0800 Message-ID: <41DC6795.6060000@candelatech.com> Date: Wed, 05 Jan 2005 14:17:57 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Johannes Erdfelt , netdev@oss.sgi.com Subject: Re: [RFC] tulip VLAN support References: <20050105193425.GY18847@sventech.com> <41DC6669.9090407@pobox.com> In-Reply-To: <41DC6669.9090407@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > Johannes Erdfelt wrote: > >> @@ -259,7 +259,7 @@ >> #define RX_RING_SIZE 128 #define MEDIA_MASK 31 >> >> -#define PKT_BUF_SZ 1536 /* Size of each temporary Rx >> buffer. */ >> +#define PKT_BUF_SZ 1540 /* Size of each temporary Rx >> buffer. */ > > > > This is the reason why the tulip "vlan" patch is continually rejected. > You shouldn't need to increase this constant, but rather follow the > other "large MTU" driver conversions. Has anyone tried just leaving this line as it was (but adding the rest of the patch)? I believe the 1536 already has plenty of space and can hold the extra 4 bytes w/out problem. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From johannes@erdfelt.com Wed Jan 5 02:32:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:32:22 -0800 (PST) Received: from farley.sventech.com (IDENT:daemon@farley.sventech.com [69.36.241.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05AVt5k026582 for ; Wed, 5 Jan 2005 02:32:16 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 500) by farley.sventech.com with local; Wed, 05 Jan 2005 22:31:47 +0000 Date: Wed, 5 Jan 2005 14:31:47 -0800 From: Johannes Erdfelt To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: [RFC] tulip VLAN support Message-ID: <20050105223147.GE18847@sventech.com> References: <20050105193425.GY18847@sventech.com> <41DC6669.9090407@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DC6669.9090407@pobox.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johannes@erdfelt.com Precedence: bulk X-list: netdev On Wed, Jan 05, 2005, Jeff Garzik wrote: > Johannes Erdfelt wrote: > >@@ -259,7 +259,7 @@ > > #define RX_RING_SIZE 128 > > #define MEDIA_MASK 31 > > > >-#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. > >*/ > >+#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. > >*/ > > This is the reason why the tulip "vlan" patch is continually rejected. > You shouldn't need to increase this constant, but rather follow the > other "large MTU" driver conversions. Donald replied to my privately with a number of reasons why similar patches have been rejected and this one of the same points brought up. I just copied the 2.4 patch that worked so well for me, but I was curious about this part of the patch as well. I asked Donald this, but I guess I'll ask on the list here too. If the point of PKT_BUF_SZ is to keep a consistent buffer size between drivers (for performance reasons), why isn't this value defined in a standard header? > Donald Becker's tulip.c (on which the kernel tulip is based) supports > proper MTU changing: ftp://ftp.scyld.com/pub/network/ The problem isn't changing the MTU, it's that a full ethernet sized packet along with the 802.1q tagging causes the size of the packet to grow past the size the driver (and it looks like the chip) will allow. The driver on Donald's site looks to have the same problem as the driver in the kernel. I'm still trying to find some specs on the tulip interface so I can better understand the chip and the changes necessary to fix this problem. Anyone have any pointers? JE From a.korud@vector.com.pl Wed Jan 5 02:34:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:34:44 -0800 (PST) Received: from 3bit.vector.com.pl (3bit.vector.com.pl [81.210.9.37]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05AYFKn027100 for ; Wed, 5 Jan 2005 02:34:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Prism54-devel] Re: [Prism54-users] Open hardware wireless cards MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 5 Jan 2005 23:34:02 +0100 Message-ID: <60E856FD577CC04BA3727AF4122D3F161134B8@3bit.vector.com.pl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Prism54-devel] Re: [Prism54-users] Open hardware wireless cards Thread-Index: AcTzZlCkwLK6ZQ9pT36HT8ksJlpIgwADzxad From: "Andriy Korud" To: "Luis R. Rodriguez" , "Steve Hill" Cc: "Netdev" , "Jean Tourrilhes" , "Luis R. Rodriguez" , "Jeff Garzik" , , , X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j05AYFKn027100 X-archive-position: 13444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.korud@vector.com.pl Precedence: bulk X-list: netdev > AFAICT the FullMAC chipsets have reached the END OF LIFE period. Sorry, as I know (no more details - NDA, sorry) some manufacturers are developing (and planning to continue) FullMAC 802.11g (and further) chipsets and also they are offering Linux drivers (however had no chance to test yet). But from my point of view, SoftMAC cards are better sometimes - you have more control from drivers and can implement some interesting features (for example, madwifi Linux driver with MAC layer ported from xBSD). Any thoughts why we should prefer FullMAC cards over SoftMAC (except CPU usage, of course)? regards, -- Andriy Korud From jgarzik@pobox.com Wed Jan 5 02:46:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:46:29 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05Ajx23029864 for ; Wed, 5 Jan 2005 02:46:19 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CmJuZ-0001MT-HV; Wed, 05 Jan 2005 22:45:51 +0000 Message-ID: <41DC6E08.3080507@pobox.com> Date: Wed, 05 Jan 2005 17:45:28 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johannes Erdfelt CC: netdev@oss.sgi.com Subject: Re: [RFC] tulip VLAN support References: <20050105193425.GY18847@sventech.com> <41DC6669.9090407@pobox.com> <20050105223147.GE18847@sventech.com> In-Reply-To: <20050105223147.GE18847@sventech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Johannes Erdfelt wrote: > On Wed, Jan 05, 2005, Jeff Garzik wrote: > >>Johannes Erdfelt wrote: >> >>>@@ -259,7 +259,7 @@ >>>#define RX_RING_SIZE 128 >>>#define MEDIA_MASK 31 >>> >>>-#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. >>>*/ >>>+#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. >>>*/ >> >>This is the reason why the tulip "vlan" patch is continually rejected. >>You shouldn't need to increase this constant, but rather follow the >>other "large MTU" driver conversions. > > > Donald replied to my privately with a number of reasons why similar > patches have been rejected and this one of the same points brought up. > > I just copied the 2.4 patch that worked so well for me, but I was > curious about this part of the patch as well. > > I asked Donald this, but I guess I'll ask on the list here too. If the > point of PKT_BUF_SZ is to keep a consistent buffer size between drivers > (for performance reasons), why isn't this value defined in a standard > header? > > >>Donald Becker's tulip.c (on which the kernel tulip is based) supports >>proper MTU changing: ftp://ftp.scyld.com/pub/network/ > > > The problem isn't changing the MTU, it's that a full ethernet sized > packet along with the 802.1q tagging causes the size of the packet to > grow past the size the driver (and it looks like the chip) will allow. What size do you need? 1504 bytes, right? > The driver on Donald's site looks to have the same problem as the driver > in the kernel. > > I'm still trying to find some specs on the tulip interface so I can > better understand the chip and the changes necessary to fix this > problem. Anyone have any pointers? They're available for free on the Intel site. I mirror 21143: http://gkernel.sourceforge.net/specs/intel/21143-hrm.pdf.bz2 Jeff From jean-baptiste.note@m4x.org Wed Jan 5 02:50:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:50:11 -0800 (PST) Received: from debian.local.gxaafoot.homelinux.org (postfix@did75-1-82-231-41-149.fbx.proxad.net [82.231.41.149] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05AnhP4030437 for ; Wed, 5 Jan 2005 02:50:04 -0800 Received: by debian.local.gxaafoot.homelinux.org (Postfix, from userid 1000) id C5309C59B; Wed, 5 Jan 2005 23:47:10 +0100 (CET) From: Jean-Baptiste Note To: "Andriy Korud" Cc: "Luis R. Rodriguez" , Netdev , prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [Prism54-users] Open hardware wireless cards References: <60E856FD577CC04BA3727AF4122D3F161134B8@3bit.vector.com.pl> Date: Wed, 05 Jan 2005 23:47:10 +0100 In-Reply-To: <60E856FD577CC04BA3727AF4122D3F161134B8@3bit.vector.com.pl> (Andriy Korud's message of "Wed, 5 Jan 2005 23:34:02 +0100") Message-ID: <87u0pv7att.fsf@gxaafoot.homelinux.org> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jean-baptiste.note@wanadoo.fr Precedence: bulk X-list: netdev Hello, "Andriy Korud" said : >> AFAICT the FullMAC chipsets have reached the END OF LIFE period. > > Sorry, as I know (no more details - NDA, sorry) some manufacturers are developing (and planning to continue) FullMAC 802.11g (and further) chipsets and also they are offering Linux drivers (however had no chance to test yet). I think he meant "prism54 802.11g fullmac chipsets (all the prism54 project is about) are EOL'd". Not "all fullmac chipsets from all manufacturers for all norms to come". In the way of "some manufacturer", are you thinking of ralink ? They've set up a website with their linux driver, and i think they're fullmac chipsets. -- Jean-Baptiste Note +33 (0)6 83 03 42 38 jean-baptiste.note@wanadoo.fr From greearb@candelatech.com Wed Jan 5 02:56:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 02:56:55 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05AuRrl031261 for ; Wed, 5 Jan 2005 02:56:47 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j05NC5LH012417; Wed, 5 Jan 2005 15:12:05 -0800 Message-ID: <41DC7093.2080705@candelatech.com> Date: Wed, 05 Jan 2005 14:56:19 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Johannes Erdfelt , netdev@oss.sgi.com Subject: Re: [RFC] tulip VLAN support References: <20050105193425.GY18847@sventech.com> <41DC6669.9090407@pobox.com> <20050105223147.GE18847@sventech.com> <41DC6E08.3080507@pobox.com> In-Reply-To: <41DC6E08.3080507@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev > What size do you need? 1504 bytes, right? 1500 MTU + 14 for header + 4 for CRC + 4 for VLAN == 1522 Normally, you just have to tell the chip to accept slightly larger frames and/or ignore the over-size frame flag. You do not actually need any ability to set a larger than 1500 MTU. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From shemminger@osdl.org Wed Jan 5 03:19:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 03:19:51 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05BJMSh000686 for ; Wed, 5 Jan 2005 03:19:42 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j05NJ8d23406; Wed, 5 Jan 2005 15:19:08 -0800 Date: Wed, 5 Jan 2005 15:19:10 -0800 From: Stephen Hemminger To: Jeb Cramer , john.ronciak@intel.com, ganesh.venkatesan@intel.com Cc: netdev@oss.sgi.com Subject: [PATCH] e1000: use netdev_priv Message-ID: <20050105151910.1e9a50fe@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert e1000 to use netdev_priv which should generate better code Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c --- a/drivers/net/e1000/e1000_ethtool.c 2005-01-05 13:53:02 -08:00 +++ b/drivers/net/e1000/e1000_ethtool.c 2005-01-05 13:53:02 -08:00 @@ -104,7 +104,7 @@ static int e1000_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; if(hw->media_type == e1000_media_type_copper) { @@ -178,7 +178,7 @@ static int e1000_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; if(ecmd->autoneg == AUTONEG_ENABLE) { @@ -205,7 +205,7 @@ e1000_get_pauseparam(struct net_device *netdev, struct ethtool_pauseparam *pause) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; pause->autoneg = @@ -225,7 +225,7 @@ e1000_set_pauseparam(struct net_device *netdev, struct ethtool_pauseparam *pause) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; adapter->fc_autoneg = pause->autoneg; @@ -258,14 +258,14 @@ static uint32_t e1000_get_rx_csum(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); return adapter->rx_csum; } static int e1000_set_rx_csum(struct net_device *netdev, uint32_t data) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); adapter->rx_csum = data; if(netif_running(netdev)) { @@ -285,7 +285,7 @@ static int e1000_set_tx_csum(struct net_device *netdev, uint32_t data) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); if(adapter->hw.mac_type < e1000_82543) { if (!data) @@ -305,7 +305,7 @@ static int e1000_set_tso(struct net_device *netdev, uint32_t data) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); if ((adapter->hw.mac_type < e1000_82544) || (adapter->hw.mac_type == e1000_82547)) return data ? -EINVAL : 0; @@ -321,14 +321,14 @@ static uint32_t e1000_get_msglevel(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); return adapter->msg_enable; } static void e1000_set_msglevel(struct net_device *netdev, uint32_t data) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); adapter->msg_enable = data; } @@ -343,7 +343,7 @@ e1000_get_regs(struct net_device *netdev, struct ethtool_regs *regs, void *p) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; uint32_t *regs_buff = p; uint16_t phy_data; @@ -431,7 +431,7 @@ static int e1000_get_eeprom_len(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); return adapter->hw.eeprom.word_size * 2; } @@ -439,7 +439,7 @@ e1000_get_eeprom(struct net_device *netdev, struct ethtool_eeprom *eeprom, uint8_t *bytes) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; uint16_t *eeprom_buff; int first_word, last_word; @@ -485,7 +485,7 @@ e1000_set_eeprom(struct net_device *netdev, struct ethtool_eeprom *eeprom, uint8_t *bytes) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; uint16_t *eeprom_buff; void *ptr; @@ -546,7 +546,7 @@ e1000_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *drvinfo) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); strncpy(drvinfo->driver, e1000_driver_name, 32); strncpy(drvinfo->version, e1000_driver_version, 32); @@ -562,7 +562,7 @@ e1000_get_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); e1000_mac_type mac_type = adapter->hw.mac_type; struct e1000_desc_ring *txdr = &adapter->tx_ring; struct e1000_desc_ring *rxdr = &adapter->rx_ring; @@ -583,7 +583,7 @@ e1000_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); e1000_mac_type mac_type = adapter->hw.mac_type; struct e1000_desc_ring *txdr = &adapter->tx_ring; struct e1000_desc_ring *rxdr = &adapter->rx_ring; @@ -765,7 +765,7 @@ struct pt_regs *regs) { struct net_device *netdev = (struct net_device *) data; - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); adapter->test_icr |= E1000_READ_REG(&adapter->hw, ICR); @@ -1376,7 +1376,7 @@ e1000_diag_test(struct net_device *netdev, struct ethtool_test *eth_test, uint64_t *data) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); boolean_t if_running = netif_running(netdev); if(eth_test->flags == ETH_TEST_FL_OFFLINE) { @@ -1436,7 +1436,7 @@ static void e1000_get_wol(struct net_device *netdev, struct ethtool_wolinfo *wol) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; switch(adapter->hw.device_id) { @@ -1481,7 +1481,7 @@ static int e1000_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; switch(adapter->hw.device_id) { @@ -1540,7 +1540,7 @@ static int e1000_phys_id(struct net_device *netdev, uint32_t data) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); if(!data || data > (uint32_t)(MAX_SCHEDULE_TIMEOUT / HZ)) data = (uint32_t)(MAX_SCHEDULE_TIMEOUT / HZ); @@ -1568,7 +1568,7 @@ static int e1000_nway_reset(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); if(netif_running(netdev)) { e1000_down(adapter); e1000_up(adapter); @@ -1586,7 +1586,7 @@ e1000_get_ethtool_stats(struct net_device *netdev, struct ethtool_stats *stats, uint64_t *data) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); int i; e1000_update_stats(adapter); diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2005-01-05 13:53:02 -08:00 +++ b/drivers/net/e1000/e1000_main.c 2005-01-05 13:53:02 -08:00 @@ -411,7 +411,7 @@ SET_NETDEV_DEV(netdev, &pdev->dev); pci_set_drvdata(pdev, netdev); - adapter = netdev->priv; + adapter = netdev_priv(netdev); adapter->netdev = netdev; adapter->pdev = pdev; adapter->hw.back = adapter; @@ -608,7 +608,7 @@ e1000_remove(struct pci_dev *pdev) { struct net_device *netdev = pci_get_drvdata(pdev); - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); uint32_t manc; if(adapter->hw.mac_type >= e1000_82540 && @@ -723,7 +723,7 @@ static int e1000_open(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); int err; /* allocate transmit descriptors */ @@ -766,7 +766,7 @@ static int e1000_close(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); e1000_down(adapter); @@ -1226,7 +1226,7 @@ static int e1000_set_mac(struct net_device *netdev, void *p) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct sockaddr *addr = p; if(!is_valid_ether_addr(addr->sa_data)) @@ -1261,7 +1261,7 @@ static void e1000_set_multi(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; struct dev_mc_list *mc_ptr; uint32_t rctl; @@ -1752,7 +1752,7 @@ static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); unsigned int first, max_per_txd = E1000_MAX_DATA_PER_TXD; unsigned int max_txd_pwr = E1000_MAX_TXD_PWR; unsigned int tx_flags = 0; @@ -1856,7 +1856,7 @@ static void e1000_tx_timeout(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); /* Do the reset outside of interrupt context */ schedule_work(&adapter->tx_timeout_task); @@ -1865,7 +1865,7 @@ static void e1000_tx_timeout_task(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); e1000_down(adapter); e1000_up(adapter); @@ -1882,7 +1882,7 @@ static struct net_device_stats * e1000_get_stats(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); e1000_update_stats(adapter); return &adapter->net_stats; @@ -1899,7 +1899,7 @@ static int e1000_change_mtu(struct net_device *netdev, int new_mtu) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); int old_mtu = adapter->rx_buffer_len; int max_frame = new_mtu + ENET_HEADER_SIZE + ETHERNET_FCS_SIZE; @@ -2112,7 +2112,7 @@ e1000_intr(int irq, void *data, struct pt_regs *regs) { struct net_device *netdev = data; - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; uint32_t icr = E1000_READ_REG(hw, ICR); #ifndef CONFIG_E1000_NAPI @@ -2157,7 +2157,7 @@ static int e1000_clean(struct net_device *netdev, int *budget) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); int work_to_do = min(*budget, netdev->quota); int tx_cleaned; int work_done = 0; @@ -2503,7 +2503,7 @@ static int e1000_mii_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); struct mii_ioctl_data *data = if_mii(ifr); int retval; uint16_t mii_reg; @@ -2670,7 +2670,7 @@ static void e1000_vlan_rx_register(struct net_device *netdev, struct vlan_group *grp) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); uint32_t ctrl, rctl; e1000_irq_disable(adapter); @@ -2705,7 +2705,7 @@ static void e1000_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); uint32_t vfta, index; /* add VID to filter table */ @@ -2718,7 +2718,7 @@ static void e1000_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); uint32_t vfta, index; e1000_irq_disable(adapter); @@ -2802,7 +2802,7 @@ e1000_suspend(struct pci_dev *pdev, uint32_t state) { struct net_device *netdev = pci_get_drvdata(pdev); - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); uint32_t ctrl, ctrl_ext, rctl, manc, status; uint32_t wufc = adapter->wol; @@ -2882,7 +2882,7 @@ e1000_resume(struct pci_dev *pdev) { struct net_device *netdev = pci_get_drvdata(pdev); - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); uint32_t manc, ret; pci_set_power_state(pdev, 0); @@ -2922,7 +2922,7 @@ static void e1000_netpoll (struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; + struct e1000_adapter *adapter = netdev_priv(netdev); disable_irq(adapter->pdev->irq); e1000_intr(adapter->pdev->irq, netdev, NULL); enable_irq(adapter->pdev->irq); From shemminger@osdl.org Wed Jan 5 03:22:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 03:22:53 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05BMPFR001300 for ; Wed, 5 Jan 2005 03:22:45 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j05NMCd24545; Wed, 5 Jan 2005 15:22:12 -0800 Date: Wed, 5 Jan 2005 15:22:13 -0800 From: Stephen Hemminger To: Jeb Cramer , john.ronciak@intel.com, ganesh.venkatesan@intel.com Cc: netdev@oss.sgi.com Subject: [PATCH] e1000: ethtool cleanups Message-ID: <20050105152213.6bb7b5dd@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev E1000 ethtool fixes: * can use ethtool_ops_get_tx_csum * use ADVERTISED_xxx fields when setting advertised fields (works now because fields are the same in ethtool.h) * don't hardcode constant for advertised field Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c --- a/drivers/net/e1000/e1000_ethtool.c 2005-01-05 13:54:27 -08:00 +++ b/drivers/net/e1000/e1000_ethtool.c 2005-01-05 13:54:27 -08:00 @@ -140,9 +140,9 @@ SUPPORTED_FIBRE | SUPPORTED_Autoneg); - ecmd->advertising = (SUPPORTED_1000baseT_Full | - SUPPORTED_FIBRE | - SUPPORTED_Autoneg); + ecmd->advertising = (ADVERTISED_1000baseT_Full | + ADVERTISED_FIBRE | + ADVERTISED_Autoneg); ecmd->port = PORT_FIBRE; @@ -183,8 +183,19 @@ if(ecmd->autoneg == AUTONEG_ENABLE) { hw->autoneg = 1; - hw->autoneg_advertised = 0x002F; - ecmd->advertising = 0x002F; + if (hw->media_type == e1000_media_type_fiber) + hw->autoneg_advertised = ADVERTISED_100baseT_Full | + ADVERTISED_FIBRE | + ADVERTISED_Autoneg; + else + hw->autoneg_advertised = ADVERTISED_10baseT_Half | + ADVERTISED_10baseT_Full | + ADVERTISED_100baseT_Half | + ADVERTISED_100baseT_Full | + ADVERTISED_1000baseT_Full| + ADVERTISED_Autoneg | + ADVERTISED_TP; + ecmd->advertising = hw->autoneg_advertised; } else if(e1000_set_spd_dplx(adapter, ecmd->speed + ecmd->duplex)) return -EINVAL; @@ -276,12 +287,6 @@ return 0; } -static uint32_t -e1000_get_tx_csum(struct net_device *netdev) -{ - return (netdev->features & NETIF_F_HW_CSUM) != 0; -} - static int e1000_set_tx_csum(struct net_device *netdev, uint32_t data) { @@ -293,12 +298,7 @@ return 0; } - if (data) - netdev->features |= NETIF_F_HW_CSUM; - else - netdev->features &= ~NETIF_F_HW_CSUM; - - return 0; + return ethtool_op_set_tx_csum(netdev, data); } #ifdef NETIF_F_TSO @@ -1638,7 +1638,7 @@ .set_pauseparam = e1000_set_pauseparam, .get_rx_csum = e1000_get_rx_csum, .set_rx_csum = e1000_set_rx_csum, - .get_tx_csum = e1000_get_tx_csum, + .get_tx_csum = ethtool_op_get_tx_csum, .set_tx_csum = e1000_set_tx_csum, .get_sg = ethtool_op_get_sg, .set_sg = ethtool_op_set_sg, From cramerj@intel.com Wed Jan 5 04:37:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 04:37:53 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05CbQxh007530 for ; Wed, 5 Jan 2005 04:37:46 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j060b7NA004646; Thu, 6 Jan 2005 00:37:07 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j060anWG002491; Thu, 6 Jan 2005 00:37:05 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005010516365921991 ; Wed, 05 Jan 2005 16:37:01 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jan 2005 16: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: ethtool cleanups Date: Wed, 5 Jan 2005 16:36:31 -0800 Message-ID: <76FA8CF8F1F53240BB5B962A3385A58001EBD04C@orsmsx405> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] e1000: ethtool cleanups Thread-Index: AcTzfWPLRoDcuRJsSPmYxQgM/zEXEgACctaw From: "cramerj" To: "Stephen Hemminger" , "Ronciak, John" , "Venkatesan, Ganesh" Cc: X-OriginalArrivalTime: 06 Jan 2005 00:36:32.0857 (UTC) FILETIME=[C53EAC90:01C4F387] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j05CbQxh007530 X-archive-position: 13450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cramerj@intel.com Precedence: bulk X-list: netdev > + if (hw->media_type == e1000_media_type_fiber) > + hw->autoneg_advertised = ADVERTISED_100baseT_Full | should be ADVERTISED_1000baseT_Full ^ Looks good. Thanks, -Jeb From y030729@njupt.edu.cn Wed Jan 5 05:07:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 05:08:00 -0800 (PST) Received: from njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j05D7VKI009137 for ; Wed, 5 Jan 2005 05:07:52 -0800 Received: (eyou send program); Thu, 06 Jan 2005 10:01:35 +0800 Message-ID: <304976895.08643@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Thu, 06 Jan 2005 10:01:35 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: imipak@yahoo.com, netdev@oss.sgi.com Cc: lartc@mailman.ds9a.nl Date: Thu, 06 Jan 2005 10:01:35 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: Re: [LARTC] Scheduler Mechnisms! Content-Type: text/plain X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: y030729@njupt.edu.cn Precedence: bulk X-list: netdev Jonathan, Yes, I think you are right, RED can be applied to any qdisc. The "RED" you mentioned here is the RED algorithm, right? I know, in linux kernel (sch_red.c), which implements the RED algotithm, just indeed uses a FIFO queue, do you think so? So, if there are serveral RED qdiscs which attach to different classes, a scheduling mechanism is needed, right? If what i have said is right, it seems that there are no scheduler mechanisms for serveral FIFO qdiscs(or RED qdiscs) in linux kernel. Of course, as we can see, CBQ which can be regard as a scheduling queue also has a scheduler mechanisms WRR. But if the FIFO is attached to the CBQ classes, then, when CBQ schedule different queues(FIFOs) using WRR, will the packets in different queues are scheduled in turn? In another condition, if i add a scheduling mechanism such as WRR behind all FIFOs, i can use this mechnism to shedule the packets in different queues, are there are any difference? Thank you very much! Regards, Zhenyu Wu >I may be wrong on this, but I believe that RED can be > attached to any queueing system, including the basic > FIFO queues. In a sense, you're still using a > scheduling system, when using the default arrangement, > it's just a first-come, first-served one. > > RED is classless and applies to the whole of a queue. > What that queue is attached to, if I understand it > correctly, isn't important. It can be a class, but it > can just as easily be everything going through that > device. > > Again, someone correct me if I'm wrong, but as I > understand it, there are four levels to the whole > QoS/diffserv concept. > > One of these levels is the queueing discipline. This > can be something like CBQ, WFQ, FIFO, PRIO, or > whatever. This is how the data is organized, it does > not describe how the data is sent. In the case of > something like CBQ, you have a defined set of queues > in parallel, with rules as to what packets fall into > what queue. On the other hand, queueing schemes such > as FIFO are flat. There's a single queue that > everything goes through, though there may be different > rules for how things get pushed to it. > > Another level is the scheduling mechanism. This > describes how the data is sent, once organized, but > does not describe the organization itself. If you've > only one queue, then there's really not much to > schedule. If you've multiple queues, then it's fairly > normal to use "round robin" or "weighted round robin" > to pick which queue to pull a packet from. Linux' CBQ > uses "weighted round robin", according to the C file. > > The next level is the packet dropping mechanism. When > queues flood, packets are going to be dropped. There's > nowhere to store them. I'm pretty sure the default > behaviour is to simply continue accepting packets, but > to drop any that expire before being sent or which > fall off the end of the queue (if the queue is > bounded). RED, GRED, and a whole host of similar > mechanisms, try to drop packets in a more controlled > manner. However, that is really all they do. > > Finally, there are mechanisms for damping overly > active applications, such as ECN. The idea here is > that if you throttle back whatever is generating > excess traffic, you don't get the problems assoicated > with dealing with it. The "default" behaviour is to do > nothing. > > When setting up QoS - on Linux or anything else - you > basically pick one of each of the four categories to > assemble a packet delivery system. Even without QoS, > you're doing that, you're just using the defaults in > all cases. The mechanisms are still going to be there. > > The Linux configuration menu does NOT match the above > terminology, or the terminology in the source code. > Thus, the source code identifies CBQ as a queueing > discipline, but the configuration menu calls it a > scheduler. The QoS help is also not very helpful, as > it mostly tells people to look at the source. However, > if you look at the source for CBQ or RED, for example, > the explanation is relative to the cited papers, so > you then have to go and read those before coming back > and doing anything. > > This is one area I hope is going to get resolved in > the reasonably near future. If not, I might have to > come up with a patch myself. The very thought of that > should send shivers down the spines of any kernel > developers out there. > > Jonathan > > --- Zhenyu Wu wrote: > > > Thank you very much, i will try to find these papers > > which must be very helpful > > for me. The "more" means that whether there are > > other mechanisms not only for > > Linux. Sorry, i have not make it clear! Sometimes, i > > wonder whether the qdiscs > > such as CBQ, RED, GRED ... are belong to the > > scheduler mechanisms in linux > > enviroment. For example, In Red, which i can find > > are enqueue, and dequeue.... so, > > if i add a RED qidsc to a class, must i add a > > scheduler mechanism so that i can > > decide which packet in the queues will be scheduled > > and put to the link? > > > > Good luck, > > Best, > > > > > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - What will yours do? > http://my.yahoo.com > From akpm@osdl.org Wed Jan 5 08:34:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 08:34:43 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05GYG7h018087 for ; Wed, 5 Jan 2005 08:34:36 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j064Y1d03895; Wed, 5 Jan 2005 20:34:01 -0800 Date: Wed, 5 Jan 2005 20:33:52 -0800 From: Andrew Morton To: Rusty Russell Cc: netdev@oss.sgi.com Subject: net/sched/ipt.c Message-Id: <20050105203352.2bc3b71a.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Am I missing something? *** Warning: "__ipt_mutex_up" [net/sched/ipt.ko] undefined! *** Warning: "__ipt_find_target_lock" [net/sched/ipt.ko] undefined! From rusty@rustcorp.com.au Wed Jan 5 08:47:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 08:47:37 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05GlA1D018697 for ; Wed, 5 Jan 2005 08:47:30 -0800 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 961D12BF0E; Thu, 6 Jan 2005 15:46:55 +1100 (EST) Subject: Re: net/sched/ipt.c From: Rusty Russell To: Andrew Morton Cc: netdev@oss.sgi.com In-Reply-To: <20050105203352.2bc3b71a.akpm@osdl.org> References: <20050105203352.2bc3b71a.akpm@osdl.org> Content-Type: text/plain Date: Thu, 06 Jan 2005 15:46:45 +1100 Message-Id: <1104986805.20582.116.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev On Wed, 2005-01-05 at 20:33 -0800, Andrew Morton wrote: > Am I missing something? > > *** Warning: "__ipt_mutex_up" [net/sched/ipt.ko] undefined! > *** Warning: "__ipt_find_target_lock" [net/sched/ipt.ko] undefined! Patch already sent... Rusty. Name: Restore net/sched/ipt.c After iptables Kmod Cleanup Status: Tested under nfsim Signed-off-by: Rusty Russell Thomas Graf points out that I broke net/sched/ipt.c when I removed __ipt_find_target_lock. In fact, those routines don't need to keep the lock held, so we can simplify them, and expose an interface (ipt_find_target) which does module loading correctly for net/sched/ipt.c. As Thomas points out, this also gets the module refcounts right. Index: linux-2.6.10-bk8-Netfilter/net/ipv4/netfilter/ip_tables.c =================================================================== --- linux-2.6.10-bk8-Netfilter.orig/net/ipv4/netfilter/ip_tables.c 2005-01-06 09:12:01.000000000 +1100 +++ linux-2.6.10-bk8-Netfilter/net/ipv4/netfilter/ip_tables.c 2005-01-06 09:49:10.000000000 +1100 @@ -430,62 +430,63 @@ return NULL; } -/* Find match, grabs mutex & ref. Returns ERR_PTR() on error. */ -static inline struct ipt_match *find_match_lock(const char *name, u8 revision) +/* Find match, grabs ref. Returns ERR_PTR() on error. */ +static inline struct ipt_match *find_match(const char *name, u8 revision) { struct ipt_match *m; - int found = 0; + int err = 0; if (down_interruptible(&ipt_mutex) != 0) return ERR_PTR(-EINTR); list_for_each_entry(m, &ipt_match, list) { if (strcmp(m->name, name) == 0) { - found = 1; if (m->revision == revision) { - if (!try_module_get(m->me)) - found = 0; - else + if (try_module_get(m->me)) { + up(&ipt_mutex); return m; - } + } + } else + err = -EPROTOTYPE; /* Found something. */ } } up(&ipt_mutex); - - /* Not found at all? NULL so try_then_request_module loads module. */ - if (!found) - return NULL; - - return ERR_PTR(-EPROTOTYPE); + return ERR_PTR(err); } -/* Find target, grabs mutex & ref. Returns ERR_PTR() on error. */ -static inline struct ipt_target *find_target_lock(const char *name, u8 revision) +/* Find target, grabs ref. Returns ERR_PTR() on error. */ +static inline struct ipt_target *find_target(const char *name, u8 revision) { struct ipt_target *t; - int found = 0; + int err = 0; if (down_interruptible(&ipt_mutex) != 0) return ERR_PTR(-EINTR); list_for_each_entry(t, &ipt_target, list) { if (strcmp(t->name, name) == 0) { - found = 1; if (t->revision == revision) { - if (!try_module_get(t->me)) - found = 0; - else + if (try_module_get(t->me)) { + up(&ipt_mutex); return t; - } + } + } else + err = -EPROTOTYPE; /* Found something. */ } } up(&ipt_mutex); + return ERR_PTR(err); +} - /* Not found at all? NULL so try_then_request_module loads module. */ - if (!found) - return NULL; +struct ipt_target *ipt_find_target(const char *name, u8 revision) +{ + struct ipt_target *target; - return ERR_PTR(-EPROTOTYPE); + target = try_then_request_module(find_target(name, revision), + "ipt_%s", name); + if (IS_ERR(target) || !target) + return NULL; + return target; } static int match_revfn(const char *name, u8 revision, int *bestp) @@ -708,15 +709,14 @@ { struct ipt_match *match; - match = try_then_request_module(find_match_lock(m->u.user.name, - m->u.user.revision), + match = try_then_request_module(find_match(m->u.user.name, + m->u.user.revision), "ipt_%s", m->u.user.name); if (IS_ERR(match) || !match) { duprintf("check_match: `%s' not found\n", m->u.user.name); return match ? PTR_ERR(match) : -ENOENT; } m->u.kernel.match = match; - up(&ipt_mutex); if (m->u.kernel.match->checkentry && !m->u.kernel.match->checkentry(name, ip, m->data, @@ -754,8 +754,8 @@ goto cleanup_matches; t = ipt_get_target(e); - target = try_then_request_module(find_target_lock(t->u.user.name, - t->u.user.revision), + target = try_then_request_module(find_target(t->u.user.name, + t->u.user.revision), "ipt_%s", t->u.user.name); if (IS_ERR(target) || !target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); @@ -763,7 +763,6 @@ goto cleanup_matches; } t->u.kernel.target = target; - up(&ipt_mutex); if (t->u.kernel.target == &ipt_standard_target) { if (!standard_check(t, size)) { Index: linux-2.6.10-bk8-Netfilter/net/sched/ipt.c =================================================================== --- linux-2.6.10-bk8-Netfilter.orig/net/sched/ipt.c 2004-12-28 12:31:11.000000000 +1100 +++ linux-2.6.10-bk8-Netfilter/net/sched/ipt.c 2005-01-06 09:37:01.000000000 +1100 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -60,32 +61,23 @@ struct ipt_target *target; int ret = 0; struct ipt_entry_target *t = p->t; - target = __ipt_find_target_lock(t->u.user.name, &ret); + target = ipt_find_target(t->u.user.name, t->u.user.revision); if (!target) { printk("init_targ: Failed to find %s\n", t->u.user.name); return -1; } DPRINTK("init_targ: found %s\n", target->name); - /* we really need proper ref counting - seems to be only needed for modules?? Talk to laforge */ -/* if (target->me) - __MOD_INC_USE_COUNT(target->me); -*/ t->u.kernel.target = target; - __ipt_mutex_up(); - if (t->u.kernel.target->checkentry && !t->u.kernel.target->checkentry(p->tname, NULL, t->data, t->u.target_size - sizeof (*t), p->hook)) { -/* if (t->u.kernel.target->me) - __MOD_DEC_USE_COUNT(t->u.kernel.target->me); -*/ DPRINTK("ip_tables: check failed for `%s'.\n", t->u.kernel.target->name); + module_put(t->u.kernel.target->me); ret = -EINVAL; } @@ -235,8 +227,12 @@ { struct tcf_ipt *p; p = PRIV(a,ipt); - if (NULL != p) + if (NULL != p) { + struct ipt_entry_target *t = p->t; + if (t && t->u.kernel.target) + module_put(t->u.kernel.target->me); return tcf_hash_release(p, bind); + } return 0; } Index: linux-2.6.10-bk8-Netfilter/include/linux/netfilter_ipv4/ip_tables.h =================================================================== --- linux-2.6.10-bk8-Netfilter.orig/include/linux/netfilter_ipv4/ip_tables.h 2005-01-06 09:11:56.000000000 +1100 +++ linux-2.6.10-bk8-Netfilter/include/linux/netfilter_ipv4/ip_tables.h 2005-01-06 09:40:03.000000000 +1100 @@ -456,6 +456,9 @@ struct module *me; }; +/* net/sched/ipt.c: Gimme access to your targets! Gets target->me. */ +extern struct ipt_target *ipt_find_target(const char *name, u8 revision); + extern int ipt_register_table(struct ipt_table *table); extern void ipt_unregister_table(struct ipt_table *table); extern unsigned int ipt_do_table(struct sk_buff **pskb, -- A bad analogy is like a leaky screwdriver -- Richard Braakman From akpm@osdl.org Wed Jan 5 10:40:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 10:40:11 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05IdjFp021203 for ; Wed, 5 Jan 2005 10:40:05 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j066dUd19597; Wed, 5 Jan 2005 22:39:30 -0800 Message-Id: <200501060639.j066dUd19597@mail.osdl.org> Subject: [patch 1/1] netfilter: ipt build fix To: rusty@rustcorp.com.au Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Wed, 05 Jan 2005 22:39:21 -0800 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev *** Warning: "ipt_find_target" [net/sched/ipt.ko] undefined! Signed-off-by: Andrew Morton --- 25-akpm/net/ipv4/netfilter/ip_tables.c | 1 + 1 files changed, 1 insertion(+) diff -puN net/ipv4/netfilter/ip_tables.c~netfilter-ipt-build-fix net/ipv4/netfilter/ip_tables.c --- 25/net/ipv4/netfilter/ip_tables.c~netfilter-ipt-build-fix 2005-01-05 22:43:32.000000000 -0800 +++ 25-akpm/net/ipv4/netfilter/ip_tables.c 2005-01-05 22:43:41.000000000 -0800 @@ -488,6 +488,7 @@ struct ipt_target *ipt_find_target(const return NULL; return target; } +EXPORT_SYMBOL(ipt_find_target); static int match_revfn(const char *name, u8 revision, int *bestp) { _ From ebs@ebshome.net Wed Jan 5 11:03:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 11:03:24 -0800 (PST) Received: from gate.ebshome.net (gate.ebshome.net [64.81.67.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05J2v0P021965 for ; Wed, 5 Jan 2005 11:03:18 -0800 Received: (qmail 6759 invoked by uid 1000); 5 Jan 2005 23:02:45 -0800 Date: Wed, 5 Jan 2005 23:02:45 -0800 From: Eugene Surovegin To: Andy Fleming Cc: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model) Message-ID: <20050106070245.GA6539@gate.ebshome.net> Mail-Followup-To: Andy Fleming , Netdev , Embedded PPC Linux list , Kumar Gala References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ICQ-UIN: 1193073 X-Operating-System: Linux i686 X-PGP-Key: http://www.ebshome.net/pubkey.asc User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebs@ebshome.net Precedence: bulk X-list: netdev On Thu, Dec 23, 2004 at 03:00:13PM -0600, Andy Fleming wrote: > > >Adds a Phy Abstraction Layer which allows ethernet controllers to > >manage their PHYs without knowing the details of how the particular > >PHY device operates. This code steals heavily from BenH's sungem > >driver, and got some stuff out of Jason McMullan's patch. Some random notes from quick look at the code: 1) IMO if we can extract some info from the PHY using _standard_ registers we should use them, even if the PHY provides some custom ones. I suspect that _all_ XXX_read_status functions for different PHYs in your patch can be easily handled by generic IEEE 802.3 compliant code (you need to update genphy_read_status to properly handle GigE of course). 2) genphy can be changed to handle GigE speeds as well. 3) I think it's better for the genphy case to _detect_ PHY features instead of hard coding PHY_BASIC_FEATURES. In this case you can easily handle 10/100 and 10/100/1000 PHYs by genphy code. 4) Pause negotiation/advertising is completely missing. 5) PHY interrupt sharing looks broken. Although you request_irq using SA_SHIRQ flag, in the handler itself you don't detect whether this interrupt is for this PHY or not, and return IRQ_HANDLED. This will result in first registered PHY hijacking IRQs from other PHYs (or devices) sharing the same IRQ line. -- Eugene From takata@linux-m32r.org Wed Jan 5 15:55:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 15:55:52 -0800 (PST) Received: from mail01.idc.renesas.com (mail.renesas.com [202.234.163.13]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j05NtOK0031209 for ; Wed, 5 Jan 2005 15:55:45 -0800 Received: (from root@localhost) by guardian02.idc.renesas.com with id j06Bt8J2023578; Thu, 6 Jan 2005 20:55:08 +0900 (JST) Received: from unknown [172.20.8.68] by guardian02.idc.renesas.com with SMTP id WAA23577 ; Thu, 6 Jan 2005 20:55:08 +0900 Received: from mrkaisv.hoku.renesas.com ([10.145.105.245]) by rnsmtp01.hoku_r.renesas.com (8.9.3/3.7W) with ESMTP id UAA20604; Thu, 6 Jan 2005 20:55:06 +0900 (JST) Received: from localhost (pcepx10 [10.145.105.241]) by mrkaisv.hoku.renesas.com (Postfix) with ESMTP id 5A72D7981B7; Thu, 6 Jan 2005 20:55:04 +0900 (JST) Date: Thu, 06 Jan 2005 20:55:03 +0900 (JST) Message-Id: <20050106.205503.719899966.takata.hirokazu@renesas.com> To: Nicolas Pitre Cc: linux-kernel@vger.kernel.org, Jeff Garzik , Andrew Morton , netdev@oss.sgi.com, takata@linux-m32r.org Subject: [PATCH 2.6.10-mm2] net: netconsole support for smc91x From: Hirokazu Takata X-Mailer: Mew version 3.3 on XEmacs 21.4.16 (Corporate Culture) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: takata@linux-m32r.org Precedence: bulk X-list: netdev This patch is for "netconsole" support of smc91x driver. It looks working. Could you please include this? Thank you. Signed-off-by: Hayato Fujiwara Signed-off-by: Hirokazu Takata --- drivers/net/smc91x.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+) diff -ruNp a/drivers/net/smc91x.c b/drivers/net/smc91x.c --- a/drivers/net/smc91x.c 2004-12-25 06:35:40.000000000 +0900 +++ b/drivers/net/smc91x.c 2005-01-06 19:40:56.000000000 +0900 @@ -1333,6 +1333,19 @@ static irqreturn_t smc_interrupt(int irq return IRQ_HANDLED; } +#ifdef CONFIG_NET_POLL_CONTROLLER +/* + * Polling receive - used by netconsole and other diagnostic tools + * to allow network i/o with interrupts disabled. + */ +static void smc_poll_controller(struct net_device *dev) +{ + disable_irq(dev->irq); + smc_interrupt(dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif + /* Our watchdog timed out. Called by the networking layer */ static void smc_timeout(struct net_device *dev) { @@ -1912,6 +1925,9 @@ static int __init smc_probe(struct net_d dev->get_stats = smc_query_statistics; dev->set_multicast_list = smc_set_multicast_list; dev->ethtool_ops = &smc_ethtool_ops; +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller = smc_poll_controller; +#endif tasklet_init(&lp->tx_task, smc_hardware_send_pkt, (unsigned long)dev); INIT_WORK(&lp->phy_configure, smc_phy_configure, dev); --- Usage: - Config: Device Drivers -> Networking support -> Network device support -> Network console logging support (NETCONSOLE) - Kernel parameter: Please set a kernel parameter "netconsole=...". (more info: Documentation/networking/netcosole.txt) - Observation on a remote host: $ netcat -u -l -p -v This is an example output log: $ netcat -u -l -p 6666 -v listening on [any] 6666 ... connect to [192.168.0.1] from mappi001 [192.168.0.101] 6665 Kernel command line: console=tty1 console=ttyS0,115200n8x root=/dev/nfsroot nfsroot=192.168.0.1:/project/m32r-linux/export/rootfs2.6_small,rsize=1024,wsize=1024 nfsaddrs=192.168.0.101:192.168.0.1:192.168.0.1:255.255.255.0:mappi001 mem=32M netconsole=6665@192.168.0.101/eth0,6666@192.168.0.1/ netconsole: local port 6665 netconsole: local IP 192.168.0.101 netconsole: interface eth0 netconsole: remote port 6666 netconsole: remote IP 192.168.0.1 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff PID hash table entries: 256 (order: 8, 4096 bytes) Timer start : latch = 5859 Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 30288k/32772k available (1528k kernel code, 2436k reserved, 281k data, 108k init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) M32R-mp information On-chip CPUs : 2 CPU model : M32R-MP 012U2/CHAOS(Ver.) CPU present map : 3 Booting processor 1/1 Waiting for send to finish... Initializing CPU#1 CPU#1 (phys ID: 1) waiting for CALLOUT +After Startup. Before Callout 1. After Callout 1. OK. Boot done. Brought up 2 CPUs CPU#0 : CPU clock 300.00MHz, Bus clock 75.00MHz, loops_per_jiffy[1196032] CPU#1 : CPU clock 300.00MHz, Bus clock 75.00MHz, loops_per_jiffy[1196032] Before bogomips. Total of 2 processors activated (478.41 BogoMIPS). Before bogocount - setting activated=1. NET: Registered protocol family 16 Linux Kernel Card Services options: none devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 ds1302: Set PLD_RTCBAUR = 37 ds1302: RTC not found. Serial: M32R SIO driver $Revision: 1.9 $ IRQ sharing disabled ttyS0 at I/O 0x4c20000 (irq = 80) is a M32RSIO io scheduler noop registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) elevator: using deadline as default io scheduler nbd: registered device at major 43 smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre eth0: SMC91C11xFD (rev 1) at 0xa0000300 IRQ 129 eth0: Ethernet addr: 08:00:70:25:b0:e1 netconsole: device eth0 not up yet, forcing it eth0: link down eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 netconsole: network logging started Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx hda: HMS360404D5CF00, CFA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 67 hda: max request size: 128KiB hda: 7999488 sectors (4095 MB) w/128KiB Cache, CHS=7936/16/63 /dev/ide/host0/bus0/target0/lun0: p1 NET: Registered protocol family 2 IP: routing cache hash table of 256 buckets, 4Kbytes TCP established hash table entries: 2048 (order: 3, 32768 bytes) TCP bind hash table entries: 2048 (order: 2, 24576 bytes) TCP: Hash tables configured (established 2048 bind 2048) NET: Registered protocol family 1 NET: Registered protocol family 17 IP-Config: Complete: device=eth0, addr=192.168.0.101, mask=255.255.255.0, gw=192.168.0.1, host=mappi001, domain=, nis-domain=(none), bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath= Looking up port of RPC 100003/2 on 192.168.0.1 Looking up port of RPC 100005/1 on 192.168.0.1 VFS: Mounted root (nfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 108k freed -- Hirokazu Takata Linux/M32R Project: http://www.linux-m32r.org/ From hadi@cyberus.ca Wed Jan 5 17:47:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 17:47:27 -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 j061lKiX005958 for ; Wed, 5 Jan 2005 17:47:21 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CmXyo-0005Qu-Hz for netdev@oss.sgi.com; Thu, 06 Jan 2005 08:47:10 -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 1CmXyl-0007gD-Ub; Thu, 06 Jan 2005 08:47:08 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050105144514.GQ26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> <1104894728.1117.56.camel@jzny.localdomain> <20050105110048.GO26856@postel.suug.ch> <1104931991.1117.152.camel@jzny.localdomain> <20050105144514.GQ26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1105019225.2312.7.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jan 2005 08:47:05 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13457 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 Sorry for the latency - vacation over, i am gonna slow down a little .. On Wed, 2005-01-05 at 09:45, Thomas Graf wrote: > * jamal <1104931991.1117.152.camel@jzny.localdomain> 2005-01-05 08:33 [..] > > Sorry i missed that. Isnt it still unecessary though? You should be able > > to pass L=4 and not need the speacial treatment, no? > > Agreed, but the ematch might expect an allocated block. Assuming the > data is variable and sometimes is L=4, sometimes L=16 the ematch > requires special handling because m->data might hold the value directly > or a pointer depending on datalen. So the issue is whether its by ref or copy? Maybe thats what the flag is for then. My view is that _everything_ for ematches should be by copy for simplicty. > > > 1) We make u32 hold multiple ematch trees, a u32 key can be of 3 > > > kinds: u32/ematch/container. It's kind of a hack and not very > > > fast due to a lot of stack movement. > > > > Indeed this is what i was thinking of. > > The only added overhead I can think of is when processing a series of > > u32 keys _within the same selector_ (not across selectors), you check if > > its u32 native and execute localy (as is done now) or transfer the check > > to the ematch defined in that key and continue to next key based on the > > ematchs return code + the logical operation. > > Exactly, does the performance gap come with any advantage? No. Oh, yes;-> the one check in the datapath comes with a _huge_ advantage even all that you had was old style matches because now you have embeded logical operations which are more than just the old AND. But more importantly you can use ematches as well to influence the existing u32 tree path. > That's > why I don't like it. > > > > > 2) We make the existing u32 match be an ematch which I already did > > > expect for the nexthdr bits. That is the select will simply be > > > replaced by an ematch tree. I'll take a look into how we could > > > have the classifier take influence on the ematches config data. > > > One possibiliy is to have a struct transfered via map which > > > contains useful data such as offset to next header (u32/rsvp). > > > I have to think about this a little more though. > > > > This could be done in addition to #1. I see #1 as more important for u32 > > but not so for things like fwmark, tcindex which should fizzle away with > > meta ematch. I think the danger is in trying to replicate u32 as an > > ematch; if somehow you can loop back and use the real u32 code, then > > fine. I feel it being non-trivial to do so. > > Like i said earlier, theres a lot of power in u32 other than in basic > > matching. > > Most importantly I don't want to touch any of the hashing code in u32. What i am reading is you see more work involved. Is this correct? > I really like and it should stay as it is. The existing u32 match can > be easly made an ematch so this would safe us the extra work in u32 to > implement logic relations again and to fiddle with complicated selector > TLVs. The only problem with this is the nexthdr bits because it relies > on the hashing code. So we have to make this data available to the > ematch which is actually not a bad idea anyway. So I'm thinking about > introducing a new structure tcf_em_pkt_info or alike which carries > some additional information found out by the classifiers which can be > used by ematches. This can be information about the next header, > already extracted dscp values, etc. > > This would give us the chance to add a very small em_u32.c (~40 lines) > doing exactly the same as the current u32 match and have the u32 > selector replaced with an ematch tree at no additional cost. Backward > compatibility is as easy as creating a flat ANDed ematch tree. > > Note: The u32 ematch I'm talking about is not the cmp ematch, cmp is > more advanced but also slightly slower. > > Thoughts? I think I understand more after reading the above now. There is one issue which i think is the big source of our lack of sync: You conclude people are gonna want to use the logical tree building scheme you are putting in to put together matches and ematches. U32 _already_ has a tree building scheme which is very very flexible. Now that the sel2 matches will provide u32 logial operators, it presents a very interesting fresh outlook on life in a jiffy of a packet. This is what i dont wanna kill or ignore. fw, tcindex etc donot have this infrastructure so they dont matter. > > I think #2 is better for other classifiers which were already doomed > > anyways. #1 is important for u32 and perhaps other classifiers like rsvp > > and route. And yes, #1 is more work ;-> > > Why is it better? What's the advantage? Refer to what i said above: u32 has built in tree building scheme made more interesting now that there exist more interesting logical operators. > > hang on:-> No dont rewrite u32 please. Your cmp is good for the basic > > matches that u32 does, but is _nowhere_ close to being able to do what > > u32 can when used properly. > > Right, that's why I now call it cmp and the existing u32 match becomes > the u32 ematch. Again, u32 classifier is not just matches; the more interesting thing is the layout of the rules that it can be taught to do. I think the ematch which emulates the std u32 match is of course valuable to have but it _doesnt_ deserve the same name. > > I Should be able to compile a new ematch as a module in an already > > running kernel. So, other than generic stuff for ematches, things like > > TCF_EM_CMP should not be in that enumeration. > > It's not a requirement to put it there but we need to manage the > assigned types for ematches in mainline anyway. Thinking more about it; not sure why you would even bother managing them. Everything runs at the same kernel privilege level. I am not sure you want to have certain things that can only be built when recompiling the kernel > > And all this also goes in that header file as well. > > I put it here because it might be very useful for other ematches > or further classifiers, you name it. tcf_get_base_ptr is used by > nbyte ematch for example. If its generic then it stays in the main header; cheers, jamal From hadi@cyberus.ca Wed Jan 5 17:56:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 17:56:25 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j061uLCC006577 for ; Wed, 5 Jan 2005 17:56:21 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1CmY7W-00076f-U4 for netdev@oss.sgi.com; Thu, 06 Jan 2005 08:56:10 -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 1CmY7M-0000cy-6a; Thu, 06 Jan 2005 08:56:00 -0500 Subject: Re: [patch 4/10] s390: network driver. From: jamal Reply-To: hadi@cyberus.ca To: Paul Jakma Cc: Jeff Garzik , Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Tommy Christensen In-Reply-To: References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> <1104895169.1117.63.camel@jzny.localdomain> <1104931011.1118.134.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1105019757.2314.16.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jan 2005 08:55:58 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13458 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 Wed, 2005-01-05 at 09:29, Paul Jakma wrote: > On Wed, 5 Jan 2005, jamal wrote: [..] > Sorry, wires crossed re "new behaviour". The "new new" behaviour in > the patch as you describe would be perfect. > > PS: Another issue, could we have kernel space IP fragmentation for > IP_HDRINCL sockets please? We currently have to implement > fragmentation ourselves, which seems silly given that kernel already > has this functionality. I will let some other fireman grab this bait ;-> If not i will revisit it after a unknown/random timeout. cheers, jamal From hadi@cyberus.ca Wed Jan 5 17:58:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 17:58:50 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j061wkBA007042 for ; Wed, 5 Jan 2005 17:58:46 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1CmY9t-0000EJ-EQ for netdev@oss.sgi.com; Thu, 06 Jan 2005 08:58:37 -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 1CmY9q-00011e-GT; Thu, 06 Jan 2005 08:58:34 -0500 Subject: Re: [patch 4/10] s390: network driver. From: jamal Reply-To: hadi@cyberus.ca To: Tommy Christensen Cc: Jeff Garzik , Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Paul Jakma In-Reply-To: <41DC0931.80603@tpack.net> References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> <1104895169.1117.63.camel@jzny.localdomain> <41DC0931.80603@tpack.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1105019912.2314.20.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jan 2005 08:58:32 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13459 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 Wed, 2005-01-05 at 10:35, Tommy Christensen wrote: > jamal wrote: > > Except for the drivers that call netif_stop_queue() on link-down. These > calls (and the corresponding netif_wake_queue) would have to be removed. If we assume all drivers do: netif_stop then carrier_off then you dont need that extra check. Thats the working assumption i had - maybe a comment is deserving or we could say we dont think that all drivers are going to follow that sequence. cheers, jamal From hadi@cyberus.ca Wed Jan 5 18:04:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 18:04:16 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0624BBn007576 for ; Wed, 5 Jan 2005 18:04:12 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CmYF7-0000u8-C7 for netdev@oss.sgi.com; Thu, 06 Jan 2005 09:04:01 -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 1CmYF5-0001ps-DH; Thu, 06 Jan 2005 09:03:59 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050105164832.GB17836@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> <1104894728.1117.56.camel@jzny.localdomain> <20050105110048.GO26856@postel.suug.ch> <1104931991.1117.152.camel@jzny.localdomain> <20050105144514.GQ26856@postel.suug.ch> <20050105164832.GB17836@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1105020237.2314.26.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jan 2005 09:03:57 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13460 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 Wed, 2005-01-05 at 11:48, Thomas Graf wrote: > Here's what I mean, it moves the u32 match as-is to an ematch so it > benefits from logic relations, inversion and can be used from other > classifiers as well. All we have to do is set info->ptr and > info->nexthdr to ptr respetively off2 before we evaluate the ematch > tree. The pkt_info struct is then passed to tcf_em_tree_match and > made available to every ematch. > > Thoughts? I think this is fine; getting into complicated-land with off2 etc but fine and does not preclude (and is lower importance in my opinion) than having u32 do its own magic. Note again Thomas: I do realize its more work to do the ematch/match thing ;-> cheers, jamal From dhollis@davehollis.com Wed Jan 5 18:35:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 18:35:30 -0800 (PST) Received: from pop-a065d14.pas.sa.earthlink.net (pop-a065d14.pas.sa.earthlink.net [207.217.121.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j062ZNeR008697 for ; Wed, 5 Jan 2005 18:35:24 -0800 Received: from user-12hcjeo.cable.mindspring.com ([69.22.77.216] helo=bender.davehollis.com) by pop-a065d14.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CmYjM-0002PC-00 for netdev@oss.sgi.com; Thu, 06 Jan 2005 06:35:16 -0800 Received: from 10.8.0.6 ([10.8.0.6]) (authenticated bits=0) by bender.davehollis.com (8.13.1/8.12.11) with ESMTP id j06EYwNJ028884 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 6 Jan 2005 09:35:03 -0500 Subject: Re: Network driver test suite? From: David Hollis To: Netdev In-Reply-To: <41DC65DB.1010907@pobox.com> References: <1104956386.3877.58.camel@dhollis-lnx.centricconsulting.com> <41DC65DB.1010907@pobox.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QyYPyklJnchyC1iCRJ3z" Date: Thu, 06 Jan 2005 08:43:41 -0500 Message-Id: <1105019021.5804.4.camel@dhollis-lnx.centricconsulting.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Scanned-By: MIMEDefang 2.49 on 10.8.0.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dhollis@davehollis.com Precedence: bulk X-list: netdev --=-QyYPyklJnchyC1iCRJ3z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-01-05 at 17:10 -0500, Jeff Garzik wrote: > David Hollis wrote: > > Is there any kind of test suite (automated or list of tests) available > > for testing Linux network drivers? I'm completing the addition of a fe= w >=20 >=20 > No, but I would love to someone to write one!!! >=20 > Jeff (in a rare case of multi-exclamation-point use) >=20 >=20 What kinds of things do you think should be tested? What I can think of in no particular order and certainly not complete: Simple, standard ping remote host pings with various crazy large packet sizes mii-tool ethtool, all of the various options. Not all need to be supported certainly, but there is a set of basic ones that really should be Changing MTU to various sizes Configuring VLANs and being able to send/recv traffic What other types of things should be tested? --=20 David Hollis --=-QyYPyklJnchyC1iCRJ3z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBB3UCNxasLqOyGHncRAu8rAJ4gFIGclJq0vyTZ3e3aSlVK1YF2twCfXX2O Is9ZfiSaVj2z4WfvHjlXWlk= =wvIS -----END PGP SIGNATURE----- --=-QyYPyklJnchyC1iCRJ3z-- From tommy.christensen@tpack.net Wed Jan 5 19:06:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 19:06:36 -0800 (PST) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j0636QJ2009931 for ; Wed, 5 Jan 2005 19:06:31 -0800 Received: (qmail 7237 invoked from network); 6 Jan 2005 15:06:13 -0000 Received: from tsc-6.cph.tpack.net (HELO ?192.168.9.22?) (192.168.9.22) by 0 with SMTP; 6 Jan 2005 15:06:13 -0000 Subject: Re: [patch 4/10] s390: network driver. From: Tommy Christensen To: hadi@cyberus.ca Cc: Jeff Garzik , Thomas Spatzier , "David S. Miller" , Hasso Tepper , Herbert Xu , netdev@oss.sgi.com, Paul Jakma In-Reply-To: <1105019912.2314.20.camel@jzny.localdomain> References: <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> <1104895169.1117.63.camel@jzny.localdomain> <41DC0931.80603@tpack.net> <1105019912.2314.20.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1105023972.3462.48.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 06 Jan 2005 16:06:13 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev On Thu, 2005-01-06 at 14:58, jamal wrote: > On Wed, 2005-01-05 at 10:35, Tommy Christensen wrote: > > jamal wrote: > > > > > Except for the drivers that call netif_stop_queue() on link-down. These > > calls (and the corresponding netif_wake_queue) would have to be removed. > > If we assume all drivers do: > netif_stop then carrier_off then you dont need that extra check. > Thats the working assumption i had - maybe a comment is deserving or > we could say we dont think that all drivers are going to follow that > sequence. But qdisc_restart() isn't called any more after the queue is stopped. So how do we get to drain the packets? Another approach could be to reset the qdisc (kind of what dev_deactivate does) if the driver stays in queue_stopped and carrier_off for some period of time. -Tommy From lsorense@csclub.uwaterloo.ca Wed Jan 5 19:16:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 19:16:29 -0800 (PST) Received: from perpugilliam.csclub.uwaterloo.ca (postfix@perpugilliam.csclub.uwaterloo.ca [129.97.134.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j063GOLM011822 for ; Wed, 5 Jan 2005 19:16:24 -0800 Received: by perpugilliam.csclub.uwaterloo.ca (Postfix, from userid 3120) id BA90EA865B; Thu, 6 Jan 2005 10:16:16 -0500 (EST) Date: Thu, 6 Jan 2005 10:16:16 -0500 To: Andriy Korud Cc: "Luis R. Rodriguez" , Steve Hill , Netdev , Jean Tourrilhes , "Luis R. Rodriguez" , Jeff Garzik , linux-kernel@vger.kernel.org, prism54-users@prism54.org, prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [Prism54-users] Open hardware wireless cards Message-ID: <20050106151616.GC30311@csclub.uwaterloo.ca> References: <60E856FD577CC04BA3727AF4122D3F161134B8@3bit.vector.com.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60E856FD577CC04BA3727AF4122D3F161134B8@3bit.vector.com.pl> User-Agent: Mutt/1.3.28i From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lsorense@csclub.uwaterloo.ca Precedence: bulk X-list: netdev On Wed, Jan 05, 2005 at 11:34:02PM +0100, Andriy Korud wrote: > Sorry, as I know (no more details - NDA, sorry) some manufacturers are developing (and planning to continue) FullMAC 802.11g (and further) chipsets and also they are offering Linux drivers (however had no chance to test yet). > > But from my point of view, SoftMAC cards are better sometimes - you have more control from drivers and can implement some interesting features (for example, madwifi Linux driver with MAC layer ported from xBSD). > > Any thoughts why we should prefer FullMAC cards over SoftMAC (except CPU usage, of course)? Embedded systems with low end cpus (to make less heat and use less power) would prefer anything that uses less cpu and can be done in dedicated (and usually simpler than the cpu) hardware. Of course the windows laptop and desktop market probably far outsells the embedded market, for now at least. Len Sorensen From jeremy.guthrie@berbee.com Wed Jan 5 19:27:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 19:27:14 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j063R8Bk012479 for ; Wed, 5 Jan 2005 19:27:08 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 09:26:55 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Thu, 6 Jan 2005 09:26:50 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501051325.40616.jeremy.guthrie@berbee.com> <16860.19615.251360.169722@robur.slu.se> In-Reply-To: <16860.19615.251360.169722@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1559170.S0gtjA0Rb7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501060926.54588.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 06 Jan 2005 15:26:55.0689 (UTC) FILETIME=[27BBEB90:01C4F404] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart1559170.S0gtjA0Rb7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 January 2005 02:22 pm, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > After smp_affinity adjustments and turning off IRQ balancing. > > > > eth3 Link encap:Ethernet HWaddr 00:02:B3:D5:7E:30 > > > > RX packets:537271635 errors:2377048 dropped:2377048 > > overruns:1849169 > > Worse? > > Yes. I'll remember Hararld moved rt_cache_stat /proc/net/stats/ and wrote > a new utility for it. Should be in iproute2 package. Stephen knows the > details. Otherwise change path in rtstat. You need this to relate and > verify the load. I still don't see the rt_cache_stat file even under 2.4.28 stock. See belo= w. > Check throughtput and how packet load is used with 2.4. > /proc/net/softnet_stat and rtstat. Also meditate how the comparison can be > fair wrt taffic patterns. Do smame with 2.6. wc -l /proc/net/rt_cache Segmentation fault cat /proc/net/rt_cache > /tmp/rt_cache ; wc -l /tmp/rt_cache cat: write error: Bad address 57664 /tmp/rt_cache ls -la /proc/net/ total 0 dr-xr-xr-x 6 root root 0 Jan 6 09:22 . dr-xr-xr-x 55 root root 0 Jan 5 15:23 .. =2Dr--r--r-- 1 root root 0 Jan 6 09:22 arp dr-xr-xr-x 2 root root 0 Jan 6 09:22 atm =2Dr--r--r-- 1 root root 0 Jan 6 09:22 dev =2Dr--r--r-- 1 root root 0 Jan 6 09:22 dev_mcast dr-xr-xr-x 2 root root 0 Jan 6 09:22 drivers =2Dr--r--r-- 1 root root 0 Jan 6 09:22 igmp =2Dr--r--r-- 1 root root 0 Jan 6 09:22 ip_mr_cache =2Dr--r--r-- 1 root root 0 Jan 6 09:22 ip_mr_vif =2Dr--r--r-- 1 root root 0 Jan 6 09:22 ip_queue =2Dr--r--r-- 1 root root 0 Jan 6 09:22 ip_tables_matches =2Dr--r--r-- 1 root root 0 Jan 6 09:22 ip_tables_names =2Dr--r--r-- 1 root root 0 Jan 6 09:22 ip_tables_targets =2Dr--r--r-- 1 root root 0 Jan 6 09:22 mcfilter =2Dr--r--r-- 1 root root 0 Jan 6 09:22 netlink =2Dr--r--r-- 1 root root 0 Jan 6 09:22 netstat =2Dr--r--r-- 1 root root 0 Jan 6 09:22 pnp =2Dr--r--r-- 1 root root 0 Jan 6 09:22 psched =2Dr--r--r-- 1 root root 0 Jan 6 09:22 raw =2Dr--r--r-- 1 root root 0 Jan 6 09:22 route dr-xr-xr-x 2 root root 0 Jan 6 09:22 rpc =2Dr--r--r-- 1 root root 0 Jan 6 09:22 rt_acct =2Dr--r--r-- 1 root root 0 Jan 6 09:22 rt_cache =2Dr--r--r-- 1 root root 0 Jan 6 09:22 snmp =2Dr--r--r-- 1 root root 0 Jan 6 09:22 sockstat =2Dr--r--r-- 1 root root 0 Jan 6 09:22 softnet_stat dr-xr-xr-x 2 root root 0 Jan 6 09:22 stat =2Dr--r--r-- 1 root root 0 Jan 6 09:22 tcp =2Dr--r--r-- 1 root root 0 Jan 6 09:22 udp =2Dr--r--r-- 1 root root 0 Jan 6 09:22 unix =2Dr--r--r-- 1 root root 0 Jan 6 09:22 wireless ls -la /proc/net/stat/ total 0 dr-xr-xr-x 2 root root 0 Jan 6 09:22 . dr-xr-xr-x 6 root root 0 Jan 6 09:22 .. =2Dr--r--r-- 1 root root 0 Jan 6 09:22 arp_cache =2Dr--r--r-- 1 root root 0 Jan 6 09:22 clip_arp_cache =2Dr--r--r-- 1 root root 0 Jan 6 09:22 rt_cache cat /proc/net/softnet_stat 96deb140 0032844e 00012bbb 00000fd8 00000000 00000000 00000000 00000000=20 00000dd4 00013dda 00000000 00000000 00000000 00000000 00000000 00000000 00000000=20 0000041f cat /proc/interrupts CPU0 CPU1 0: 821852 5664906 IO-APIC-edge timer 1: 484 1247 IO-APIC-edge keyboard 8: 0 2 IO-APIC-edge rtc 14: 5 16 IO-APIC-edge ide0 18: 1928608529 1374 IO-APIC-level eth3 20: 1 226113098 IO-APIC-level eth2 27: 7950 34312 IO-APIC-level eth0 28: 2718 8097 IO-APIC-level aic7xxx 30: 0 0 IO-APIC-level acpi NMI: 0 0 LOC: 6487240 6487239 ERR: 0 MIS: 0 =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart1559170.S0gtjA0Rb7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3Vi+qtjaBHGZBeURAt66AJwM0xWjzgxb+u3M/UlpHFEWhMH0VgCfXpXz DJFwD5QWmhr9IfBJzDX98a0= =hXMn -----END PGP SIGNATURE----- --nextPart1559170.S0gtjA0Rb7-- From mitch.a.williams@intel.com Wed Jan 5 21:04:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 21:04:40 -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 j0654Z9E019199 for ; Wed, 5 Jan 2005 21:04:35 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j06H4HXD029818; Thu, 6 Jan 2005 17:04:17 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j06H4EGE016209; Thu, 6 Jan 2005 17:04:17 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 M2005010609041701652 ; Thu, 06 Jan 2005 09:04:17 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jan 2005 09:04:16 -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="iso-8859-1" Subject: RE: [Bugme-new] [Bug 3992] New: Bondig. Not correct work function ARP Monitoring. Broken link. Date: Thu, 6 Jan 2005 09:04:15 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bugme-new] [Bug 3992] New: Bondig. Not correct work function ARP Monitoring. Broken link. thread-index: AcTzbphnoKruf5E+TwG6OHYoOFxO1QAouHjA From: "Williams, Mitch A" To: "Andrew Morton" , X-OriginalArrivalTime: 06 Jan 2005 17:04:16.0775 (UTC) FILETIME=[C14AE970:01C4F411] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j0654Z9E019199 X-archive-position: 13465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch.a.williams@intel.com Precedence: bulk X-list: netdev Our test lab has found a number of issues with ARP monitoring. These bugs were on my to-do list for Q4 but got bumped due to other issues. So now they're on my to-do list for Q1. That being said, if somebody else really wants to fix this before I get to it, I won't complain. -Mitch Williams -----Original Message----- From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Andrew Morton Sent: Wednesday, January 05, 2005 1:35 PM To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 3992] New: Bondig. Not correct work function ARP Monitoring. Broken link. Begin forwarded message: Date: Wed, 5 Jan 2005 07:59:17 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 3992] New: Bondig. Not correct work function ARP Monitoring. Broken link. http://bugme.osdl.org/show_bug.cgi?id=3992 Summary: Bondig. Not correct work function ARP Monitoring. Broken link. Kernel Version: 2.6.10 Status: NEW Severity: normal Owner: jgarzik@pobox.com Submitter: stanislav@muhachev.petro.ru Distribution: Hardware Environment: Vmware GSX machine Software Environment: Gentoo Problem Description: bonding interface going down and down slave link Steps to reproduce: 2 virtual pc identical gentoo linux (copy) 1 nic for both virtual pc up 2 openvpn link trouch nic to another virtual pc (tap0 and tap1)[ethernet bridge] link both vpn1 and vpn2 - ok!(independing link like:192.168.1.1-192.168.1.2 and 192.168.2.1-192.168.2.2) bonding vpn1 & vpn2 òî bond0 (bonding default setup -> nothing failover setings) link îê!(192.168.100.1-192.168.100.2) setting arp monitor in bonding (TUN/TAP driver not support Mii status) link down! arp request go from bond0(machine1)[from tap0 & tap1] to bond0(machine2) - ok. arp answer bond0(machine2) interface - ok! !!! bond0(machine2) -> tap0(tap1)(machine2) - noting!!!(arp answer broken) resultat arp request not complite situation analog both side for monitoring use TCPDUMP ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ebs@ebshome.net Wed Jan 5 21:14:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 21:14:11 -0800 (PST) Received: from gate.ebshome.net (gate.ebshome.net [64.81.67.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j065E78b019931 for ; Wed, 5 Jan 2005 21:14:07 -0800 Received: (qmail 15049 invoked by uid 1000); 6 Jan 2005 09:13:55 -0800 Date: Thu, 6 Jan 2005 09:13:55 -0800 From: Eugene Surovegin To: Andy Fleming Cc: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model) Message-ID: <20050106171355.GB6539@gate.ebshome.net> Mail-Followup-To: Andy Fleming , Netdev , Embedded PPC Linux list , Kumar Gala References: <20050106070245.GA6539@gate.ebshome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050106070245.GA6539@gate.ebshome.net> X-ICQ-UIN: 1193073 X-Operating-System: Linux i686 X-PGP-Key: http://www.ebshome.net/pubkey.asc User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebs@ebshome.net Precedence: bulk X-list: netdev On Wed, Jan 05, 2005 at 11:02:45PM -0800, Eugene Surovegin wrote: > 5) PHY interrupt sharing looks broken. Although you request_irq using > SA_SHIRQ flag, in the handler itself you don't detect whether this > interrupt is for this PHY or not, and return IRQ_HANDLED. This will > result in first registered PHY hijacking IRQs from other PHYs (or > devices) sharing the same IRQ line. Doh, ignore this. I wasn't thinking straight... -- Eugene From chas@cmf.nrl.navy.mil Wed Jan 5 21:18:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 21:18:11 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j065I5MQ020459 for ; Wed, 5 Jan 2005 21:18:06 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j06HHJ5I000508 for ; Thu, 6 Jan 2005 12:17:19 -0500 (EST) Message-Id: <200501061717.j06HHJ5I000508@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Subject: [RFC] locking changes for lec.c Date: Thu, 06 Jan 2005 12:17:20 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 13467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev after looking at things recently its not clear to me that the combination of lec_arp_lock and lec_arp_users was protecting things properly. here is a small rewrite that eliminates lec_arp_users completely and uses lec_arp_lock to protect the lists in lec_prev: lec_arp_tables, lec_arp_empty_ones, et al. and yes, after this patch i will probably submit another patch to fix the tab (or lack of tab) problem. ===== net/atm/lec.c 1.44 vs edited ===== --- 1.44/net/atm/lec.c 2004-07-28 11:59:55 -04:00 +++ edited/net/atm/lec.c 2005-01-06 12:01:46 -05:00 @@ -422,6 +422,7 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb) { + unsigned long flags; struct net_device *dev = (struct net_device*)vcc->proto_data; struct lec_priv *priv = (struct lec_priv*)dev->priv; struct atmlec_msg *mesg; @@ -456,8 +457,10 @@ lec_flush_complete(priv, mesg->content.normal.flag); break; case l_narp_req: /* LANE2: see 7.1.35 in the lane2 spec */ + spin_lock_irqsave(&priv->lec_arp_lock, flags); entry = lec_arp_find(priv, mesg->content.normal.mac_addr); lec_arp_remove(priv, entry); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); if (mesg->content.normal.no_source_le_narp) break; @@ -1222,17 +1225,20 @@ static int lane2_resolve(struct net_device *dev, u8 *dst_mac, int force, u8 **tlvs, u32 *sizeoftlvs) { + unsigned long flags; struct lec_priv *priv = (struct lec_priv *)dev->priv; struct lec_arp_table *table; struct sk_buff *skb; int retval; if (force == 0) { + spin_lock_irqsave(&priv->lec_arp_lock, flags); table = lec_arp_find(priv, dst_mac); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); if(table == NULL) return -1; - *tlvs = kmalloc(table->sizeoftlvs, GFP_KERNEL); + *tlvs = kmalloc(table->sizeoftlvs, GFP_ATOMIC); if (*tlvs == NULL) return -1; @@ -1377,18 +1383,6 @@ #define HASH(ch) (ch & (LEC_ARP_TABLE_SIZE -1)) -static __inline__ void -lec_arp_get(struct lec_priv *priv) -{ - atomic_inc(&priv->lec_arp_users); -} - -static __inline__ void -lec_arp_put(struct lec_priv *priv) -{ - atomic_dec(&priv->lec_arp_users); -} - /* * Initialization of arp-cache */ @@ -1397,12 +1391,12 @@ { unsigned short i; - for (i=0;ilec_arp_tables[i] = NULL; } spin_lock_init(&priv->lec_arp_lock); init_timer(&priv->lec_arp_timer); - priv->lec_arp_timer.expires = jiffies+LEC_ARP_REFRESH_INTERVAL; + priv->lec_arp_timer.expires = jiffies + LEC_ARP_REFRESH_INTERVAL; priv->lec_arp_timer.data = (unsigned long)priv; priv->lec_arp_timer.function = lec_arp_check_expire; add_timer(&priv->lec_arp_timer); @@ -1439,12 +1433,9 @@ static inline void lec_arp_add(struct lec_priv *priv, struct lec_arp_table *to_add) { - unsigned long flags; unsigned short place; struct lec_arp_table *tmp; - spin_lock_irqsave(&priv->lec_arp_lock, flags); - place = HASH(to_add->mac_addr[ETH_ALEN-1]); tmp = priv->lec_arp_tables[place]; to_add->next = NULL; @@ -1457,8 +1448,6 @@ tmp->next = to_add; } - spin_unlock_irqrestore(&priv->lec_arp_lock, flags); - DPRINTK("LEC_ARP: Added entry:%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", 0xff&to_add->mac_addr[0], 0xff&to_add->mac_addr[1], 0xff&to_add->mac_addr[2], 0xff&to_add->mac_addr[3], @@ -1472,15 +1461,11 @@ lec_arp_remove(struct lec_priv *priv, struct lec_arp_table *to_remove) { - unsigned long flags; unsigned short place; struct lec_arp_table *tmp; int remove_vcc=1; - spin_lock_irqsave(&priv->lec_arp_lock, flags); - if (!to_remove) { - spin_unlock_irqrestore(&priv->lec_arp_lock, flags); return -1; } place = HASH(to_remove->mac_addr[ETH_ALEN-1]); @@ -1492,7 +1477,6 @@ tmp = tmp->next; } if (!tmp) {/* Entry was not found */ - spin_unlock_irqrestore(&priv->lec_arp_lock, flags); return -1; } } @@ -1505,7 +1489,7 @@ /* * ESI_FLUSH_PENDING, ESI_FORWARD_DIRECT */ - for(place=0;placelec_arp_tables[place]; tmp != NULL; tmp = tmp->next) { if (memcmp(tmp->atm_addr, to_remove->atm_addr, ATM_ESA_LEN)==0) { @@ -1519,8 +1503,6 @@ } skb_queue_purge(&to_remove->tx_wait); /* FIXME: good place for this? */ - spin_unlock_irqrestore(&priv->lec_arp_lock, flags); - DPRINTK("LEC_ARP: Removed entry:%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", 0xff&to_remove->mac_addr[0], 0xff&to_remove->mac_addr[1], 0xff&to_remove->mac_addr[2], 0xff&to_remove->mac_addr[3], @@ -1704,6 +1686,7 @@ void lec_arp_destroy(struct lec_priv *priv) { + unsigned long flags; struct lec_arp_table *entry, *next; int i; @@ -1712,8 +1695,10 @@ /* * Remove all entries */ - for (i=0;ilec_arp_tables[i];entry != NULL; entry=next) { + + spin_lock_irqsave(&priv->lec_arp_lock, flags); + for (i = 0; i < LEC_ARP_TABLE_SIZE; i++) { + for(entry = priv->lec_arp_tables[i]; entry != NULL; entry=next) { next = entry->next; lec_arp_remove(priv, entry); kfree(entry); @@ -1748,7 +1733,8 @@ priv->mcast_fwds = NULL; priv->mcast_vcc = NULL; memset(priv->lec_arp_tables, 0, - sizeof(struct lec_arp_table*)*LEC_ARP_TABLE_SIZE); + sizeof(struct lec_arp_table *) * LEC_ARP_TABLE_SIZE); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } @@ -1765,18 +1751,15 @@ DPRINTK("LEC_ARP: lec_arp_find :%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", mac_addr[0]&0xff, mac_addr[1]&0xff, mac_addr[2]&0xff, mac_addr[3]&0xff, mac_addr[4]&0xff, mac_addr[5]&0xff); - lec_arp_get(priv); place = HASH(mac_addr[ETH_ALEN-1]); to_return = priv->lec_arp_tables[place]; while(to_return) { if (memcmp(mac_addr, to_return->mac_addr, ETH_ALEN) == 0) { - lec_arp_put(priv); return to_return; } to_return = to_return->next; } - lec_arp_put(priv); return NULL; } @@ -1785,17 +1768,17 @@ { struct lec_arp_table *to_return; - to_return=(struct lec_arp_table *)kmalloc(sizeof(struct lec_arp_table), - GFP_ATOMIC); + to_return = (struct lec_arp_table *) kmalloc(sizeof(struct lec_arp_table), + GFP_ATOMIC); if (!to_return) { printk("LEC: Arp entry kmalloc failed\n"); return NULL; } - memset(to_return,0,sizeof(struct lec_arp_table)); + memset(to_return, 0, sizeof(struct lec_arp_table)); memcpy(to_return->mac_addr, mac_addr, ETH_ALEN); init_timer(&to_return->timer); to_return->timer.function = lec_arp_expire_arp; - to_return->timer.data = (unsigned long)to_return; + to_return->timer.data = (unsigned long) to_return; to_return->last_used = jiffies; to_return->priv = priv; skb_queue_head_init(&to_return->tx_wait); @@ -1835,6 +1818,7 @@ static void lec_arp_expire_vcc(unsigned long data) { + unsigned flags; struct lec_arp_table *to_remove = (struct lec_arp_table*)data; struct lec_priv *priv = (struct lec_priv *)to_remove->priv; struct lec_arp_table *entry = NULL; @@ -1846,6 +1830,8 @@ to_remove->vcc?to_remove->recv_vcc->vpi:0, to_remove->vcc?to_remove->recv_vcc->vci:0); DPRINTK("eo:%p nf:%p\n",priv->lec_arp_empty_ones,priv->lec_no_forward); + + spin_lock_irqsave(&priv->lec_arp_lock, flags); if (to_remove == priv->lec_arp_empty_ones) priv->lec_arp_empty_ones = to_remove->next; else { @@ -1866,6 +1852,8 @@ entry->next = to_remove->next; } } + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + lec_arp_clear_vccs(to_remove); kfree(to_remove); } @@ -1889,69 +1877,67 @@ static void lec_arp_check_expire(unsigned long data) { + unsigned long flags; struct lec_priv *priv = (struct lec_priv *)data; struct lec_arp_table *entry, *next; unsigned long now; unsigned long time_to_check; int i; - DPRINTK("lec_arp_check_expire %p,%d\n",priv, - atomic_read(&priv->lec_arp_users)); + DPRINTK("lec_arp_check_expire %p\n",priv); DPRINTK("expire: eo:%p nf:%p\n",priv->lec_arp_empty_ones, priv->lec_no_forward); - if (!atomic_read(&priv->lec_arp_users)) { - lec_arp_get(priv); - now = jiffies; - for(i=0;ilec_arp_tables[i]; entry != NULL; ) { - if ((entry->flags) & LEC_REMOTE_FLAG && - priv->topology_change) - time_to_check=priv->forward_delay_time; - else - time_to_check = priv->aging_time; - - DPRINTK("About to expire: %lx - %lx > %lx\n", - now,entry->last_used, time_to_check); - if( time_after(now, entry->last_used+ - time_to_check) && - !(entry->flags & LEC_PERMANENT_FLAG) && - !(entry->mac_addr[0] & 0x01) ) { /* LANE2: 7.1.20 */ - /* Remove entry */ - DPRINTK("LEC:Entry timed out\n"); - next = entry->next; - lec_arp_remove(priv, entry); - kfree(entry); - entry = next; - } else { - /* Something else */ - if ((entry->status == ESI_VC_PENDING || - entry->status == ESI_ARP_PENDING) - && time_after_eq(now, - entry->timestamp + - priv->max_unknown_frame_time)) { - entry->timestamp = jiffies; - entry->packets_flooded = 0; - if (entry->status == ESI_VC_PENDING) - send_to_lecd(priv, l_svc_setup, entry->mac_addr, entry->atm_addr, NULL); - } - if (entry->status == ESI_FLUSH_PENDING - && - time_after_eq(now, entry->timestamp+ - priv->path_switching_delay)) { - struct sk_buff *skb; - - while ((skb = skb_dequeue(&entry->tx_wait)) != NULL) - lec_send(entry->vcc, skb, entry->priv); - entry->last_used = jiffies; - entry->status = - ESI_FORWARD_DIRECT; - } - entry = entry->next; - } - } - } - lec_arp_put(priv); - } + now = jiffies; + spin_lock_irqsave(&priv->lec_arp_lock, flags); + for(i = 0; i < LEC_ARP_TABLE_SIZE; i++) { + for(entry = priv->lec_arp_tables[i]; entry != NULL; ) { + if ((entry->flags) & LEC_REMOTE_FLAG && + priv->topology_change) + time_to_check = priv->forward_delay_time; + else + time_to_check = priv->aging_time; + + DPRINTK("About to expire: %lx - %lx > %lx\n", + now,entry->last_used, time_to_check); + if( time_after(now, entry->last_used+ + time_to_check) && + !(entry->flags & LEC_PERMANENT_FLAG) && + !(entry->mac_addr[0] & 0x01) ) { /* LANE2: 7.1.20 */ + /* Remove entry */ + DPRINTK("LEC:Entry timed out\n"); + next = entry->next; + lec_arp_remove(priv, entry); + kfree(entry); + entry = next; + } else { + /* Something else */ + if ((entry->status == ESI_VC_PENDING || + entry->status == ESI_ARP_PENDING) + && time_after_eq(now, + entry->timestamp + + priv->max_unknown_frame_time)) { + entry->timestamp = jiffies; + entry->packets_flooded = 0; + if (entry->status == ESI_VC_PENDING) + send_to_lecd(priv, l_svc_setup, entry->mac_addr, entry->atm_addr, NULL); + } + if (entry->status == ESI_FLUSH_PENDING + && + time_after_eq(now, entry->timestamp+ + priv->path_switching_delay)) { + struct sk_buff *skb; + + while ((skb = skb_dequeue(&entry->tx_wait)) != NULL) + lec_send(entry->vcc, skb, entry->priv); + entry->last_used = jiffies; + entry->status = + ESI_FORWARD_DIRECT; + } + entry = entry->next; + } + } + } + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); mod_timer(&priv->lec_arp_timer, jiffies + LEC_ARP_REFRESH_INTERVAL); } @@ -1963,9 +1949,11 @@ lec_arp_resolve(struct lec_priv *priv, unsigned char *mac_to_find, int is_rdesc, struct lec_arp_table **ret_entry) { + unsigned long flags; struct lec_arp_table *entry; + struct atm_vcc *found; - if (mac_to_find[0]&0x01) { + if (mac_to_find[0] & 0x01) { switch (priv->lane_version) { case 1: return priv->mcast_vcc; @@ -1979,6 +1967,7 @@ } } + spin_lock_irqsave(&priv->lec_arp_lock, flags); entry = lec_arp_find(priv, mac_to_find); if (entry) { @@ -1986,7 +1975,8 @@ /* Connection Ok */ entry->last_used = jiffies; *ret_entry = entry; - return entry->vcc; + found = entry->vcc; + goto out; } /* Data direct VC not yet set up, check to see if the unknown frame count is greater than the limit. If the limit has @@ -1996,7 +1986,8 @@ entry->packets_floodedmaximum_unknown_frame_count) { entry->packets_flooded++; DPRINTK("LEC_ARP: Flooding..\n"); - return priv->mcast_vcc; + found = priv->mcast_vcc; + goto out; } /* We got here because entry->status == ESI_FLUSH_PENDING * or BUS flood limit was reached for an entry which is @@ -2004,13 +1995,14 @@ */ *ret_entry = entry; DPRINTK("lec: entry->status %d entry->vcc %p\n", entry->status, entry->vcc); - return NULL; + found = NULL; } else { /* No matching entry was found */ entry = make_entry(priv, mac_to_find); DPRINTK("LEC_ARP: Making entry\n"); if (!entry) { - return priv->mcast_vcc; + found = priv->mcast_vcc; + goto out; } lec_arp_add(priv, entry); /* We want arp-request(s) to be sent */ @@ -2026,33 +2018,38 @@ entry->timer.expires = jiffies + (1*HZ); entry->timer.function = lec_arp_expire_arp; add_timer(&entry->timer); - return priv->mcast_vcc; + found = priv->mcast_vcc; } + +out: + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + return found; } int lec_addr_delete(struct lec_priv *priv, unsigned char *atm_addr, unsigned long permanent) { + unsigned long flags; struct lec_arp_table *entry, *next; int i; - lec_arp_get(priv); DPRINTK("lec_addr_delete\n"); - for(i=0;ilec_arp_tables[i];entry != NULL; entry=next) { + spin_lock_irqsave(&priv->lec_arp_lock, flags); + for(i = 0; i < LEC_ARP_TABLE_SIZE; i++) { + for(entry = priv->lec_arp_tables[i]; entry != NULL; entry = next) { next = entry->next; if (!memcmp(atm_addr, entry->atm_addr, ATM_ESA_LEN) && (permanent || !(entry->flags & LEC_PERMANENT_FLAG))) { - lec_arp_remove(priv, entry); + lec_arp_remove(priv, entry); kfree(entry); } - lec_arp_put(priv); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); return 0; } } - lec_arp_put(priv); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); return -1; } @@ -2064,6 +2061,7 @@ unsigned char *atm_addr, unsigned long remoteflag, unsigned int targetless_le_arp) { + unsigned long flags; struct lec_arp_table *entry, *tmp; int i; @@ -2072,12 +2070,12 @@ mac_addr[0],mac_addr[1],mac_addr[2],mac_addr[3], mac_addr[4],mac_addr[5]); + spin_lock_irqsave(&priv->lec_arp_lock, flags); entry = lec_arp_find(priv, mac_addr); if (entry == NULL && targetless_le_arp) - return; /* LANE2: ignore targetless LE_ARPs for which - * we have no entry in the cache. 7.1.30 - */ - lec_arp_get(priv); + goto out; /* LANE2: ignore targetless LE_ARPs for which + * we have no entry in the cache. 7.1.30 + */ if (priv->lec_arp_empty_ones) { entry = priv->lec_arp_empty_ones; if (!memcmp(entry->atm_addr, atm_addr, ATM_ESA_LEN)) { @@ -2117,27 +2115,24 @@ entry->flags|=LEC_REMOTE_FLAG; else entry->flags&=~LEC_REMOTE_FLAG; - lec_arp_put(priv); DPRINTK("After update\n"); dump_arp_table(priv); - return; + goto out; } } entry = lec_arp_find(priv, mac_addr); if (!entry) { entry = make_entry(priv, mac_addr); - if (!entry) { - lec_arp_put(priv); - return; - } + if (!entry) + goto out; entry->status = ESI_UNKNOWN; lec_arp_add(priv, entry); /* Temporary, changes before end of function */ } memcpy(entry->atm_addr, atm_addr, ATM_ESA_LEN); del_timer(&entry->timer); - for(i=0;ilec_arp_tables[i];tmp;tmp=tmp->next) { + for(i = 0; i < LEC_ARP_TABLE_SIZE; i++) { + for(tmp = priv->lec_arp_tables[i]; tmp; tmp=tmp->next) { if (entry != tmp && !memcmp(tmp->atm_addr, atm_addr, ATM_ESA_LEN)) { @@ -2166,7 +2161,8 @@ } DPRINTK("After update2\n"); dump_arp_table(priv); - lec_arp_put(priv); +out: + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } /* @@ -2177,10 +2173,11 @@ struct atm_vcc *vcc, void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb)) { + unsigned long flags; struct lec_arp_table *entry; int i, found_entry=0; - lec_arp_get(priv); + spin_lock_irqsave(&priv->lec_arp_lock, flags); if (ioc_data->receive == 2) { /* Vcc for Multicast Forward. No timer, LANEv2 7.1.20 and 2.3.5.3 */ @@ -2189,26 +2186,22 @@ entry = lec_arp_find(priv, bus_mac); if (!entry) { printk("LEC_ARP: Multicast entry not found!\n"); - lec_arp_put(priv); - return; + goto out; } memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN); entry->recv_vcc = vcc; entry->old_recv_push = old_push; #endif entry = make_entry(priv, bus_mac); - if (entry == NULL) { - lec_arp_put(priv); - return; - } + if (entry == NULL) + goto out; del_timer(&entry->timer); memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN); entry->recv_vcc = vcc; entry->old_recv_push = old_push; entry->next = priv->mcast_fwds; priv->mcast_fwds = entry; - lec_arp_put(priv); - return; + goto out; } else if (ioc_data->receive == 1) { /* Vcc which we don't want to make default vcc, attach it anyway. */ @@ -2224,10 +2217,8 @@ ioc_data->atm_addr[16],ioc_data->atm_addr[17], ioc_data->atm_addr[18],ioc_data->atm_addr[19]); entry = make_entry(priv, bus_mac); - if (entry == NULL) { - lec_arp_put(priv); - return; - } + if (entry == NULL) + goto out; memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN); memset(entry->mac_addr, 0, ETH_ALEN); entry->recv_vcc = vcc; @@ -2238,9 +2229,8 @@ add_timer(&entry->timer); entry->next = priv->lec_no_forward; priv->lec_no_forward = entry; - lec_arp_put(priv); dump_arp_table(priv); - return; + goto out; } DPRINTK("LEC_ARP:Attaching data direct, default:%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x%2.2x\n", ioc_data->atm_addr[0],ioc_data->atm_addr[1], @@ -2253,8 +2243,8 @@ ioc_data->atm_addr[14],ioc_data->atm_addr[15], ioc_data->atm_addr[16],ioc_data->atm_addr[17], ioc_data->atm_addr[18],ioc_data->atm_addr[19]); - for (i=0;ilec_arp_tables[i];entry;entry=entry->next) { + for (i = 0; i < LEC_ARP_TABLE_SIZE; i++) { + for (entry = priv->lec_arp_tables[i]; entry; entry=entry->next) { if (memcmp(ioc_data->atm_addr, entry->atm_addr, ATM_ESA_LEN)==0) { DPRINTK("LEC_ARP: Attaching data direct\n"); @@ -2297,18 +2287,15 @@ } } if (found_entry) { - lec_arp_put(priv); DPRINTK("After vcc was added\n"); dump_arp_table(priv); - return; + goto out; } /* Not found, snatch address from first data packet that arrives from this vcc */ entry = make_entry(priv, bus_mac); - if (!entry) { - lec_arp_put(priv); - return; - } + if (!entry) + goto out; entry->vcc = vcc; entry->old_push = old_push; memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN); @@ -2319,20 +2306,23 @@ entry->timer.expires = jiffies + priv->vcc_timeout_period; entry->timer.function = lec_arp_expire_vcc; add_timer(&entry->timer); - lec_arp_put(priv); DPRINTK("After vcc was added\n"); dump_arp_table(priv); +out: + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } void lec_flush_complete(struct lec_priv *priv, unsigned long tran_id) { + unsigned long flags; struct lec_arp_table *entry; int i; DPRINTK("LEC:lec_flush_complete %lx\n",tran_id); - for (i=0;ilec_arp_tables[i];entry;entry=entry->next) { + spin_lock_irqsave(&priv->lec_arp_lock, flags); + for (i = 0; i < LEC_ARP_TABLE_SIZE; i++) { + for (entry = priv->lec_arp_tables[i]; entry; entry=entry->next) { if (entry->flush_tran_id == tran_id && entry->status == ESI_FLUSH_PENDING) { struct sk_buff *skb; @@ -2344,6 +2334,7 @@ } } } + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); dump_arp_table(priv); } @@ -2351,24 +2342,29 @@ lec_set_flush_tran_id(struct lec_priv *priv, unsigned char *atm_addr, unsigned long tran_id) { + unsigned long flags; struct lec_arp_table *entry; int i; - for (i=0;ilec_arp_tables[i];entry;entry=entry->next) + spin_lock_irqsave(&priv->lec_arp_lock, flags); + for (i = 0; i < LEC_ARP_TABLE_SIZE; i++) + for(entry = priv->lec_arp_tables[i]; entry; entry=entry->next) if (!memcmp(atm_addr, entry->atm_addr, ATM_ESA_LEN)) { entry->flush_tran_id = tran_id; DPRINTK("Set flush transaction id to %lx for %p\n",tran_id,entry); } + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc) { + unsigned long flags; unsigned char mac_addr[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; struct lec_arp_table *to_add; struct lec_vcc_priv *vpriv; + int err = 0; if (!(vpriv = kmalloc(sizeof(struct lec_vcc_priv), GFP_KERNEL))) return -ENOMEM; @@ -2376,13 +2372,13 @@ vpriv->old_pop = vcc->pop; vcc->user_back = vpriv; vcc->pop = lec_pop; - lec_arp_get(priv); + spin_lock_irqsave(&priv->lec_arp_lock, flags); to_add = make_entry(priv, mac_addr); if (!to_add) { - lec_arp_put(priv); vcc->pop = vpriv->old_pop; kfree(vpriv); - return -ENOMEM; + err = -ENOMEM; + goto out; } memcpy(to_add->atm_addr, vcc->remote.sas_addr.prv, ATM_ESA_LEN); to_add->status = ESI_FORWARD_DIRECT; @@ -2392,19 +2388,21 @@ vcc->push = lec_push; priv->mcast_vcc = vcc; lec_arp_add(priv, to_add); - lec_arp_put(priv); - return 0; +out: + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + return err; } void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc) { + unsigned long flags; struct lec_arp_table *entry, *next; int i; DPRINTK("LEC_ARP: lec_vcc_close vpi:%d vci:%d\n",vcc->vpi,vcc->vci); dump_arp_table(priv); - lec_arp_get(priv); + spin_lock_irqsave(&priv->lec_arp_lock, flags); for(i=0;ilec_arp_tables[i];entry; entry=next) { next = entry->next; @@ -2466,7 +2464,7 @@ entry = next; } - lec_arp_put(priv); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); dump_arp_table(priv); } @@ -2486,26 +2484,22 @@ #endif src = hdr->h_source; - lec_arp_get(priv); + spin_lock_irqsave(&priv->lec_arp_lock, flags); entry = priv->lec_arp_empty_ones; if (vcc == entry->vcc) { - spin_lock_irqsave(&priv->lec_arp_lock, flags); del_timer(&entry->timer); memcpy(entry->mac_addr, src, ETH_ALEN); entry->status = ESI_FORWARD_DIRECT; entry->last_used = jiffies; priv->lec_arp_empty_ones = entry->next; - spin_unlock_irqrestore(&priv->lec_arp_lock, flags); /* We might have got an entry */ - if ((prev=lec_arp_find(priv,src))) { + if ((prev = lec_arp_find(priv,src))) { lec_arp_remove(priv, prev); kfree(prev); } lec_arp_add(priv, entry); - lec_arp_put(priv); - return; + goto out; } - spin_lock_irqsave(&priv->lec_arp_lock, flags); prev = entry; entry = entry->next; while (entry && entry->vcc != vcc) { @@ -2514,21 +2508,19 @@ } if (!entry) { DPRINTK("LEC_ARP: Arp_check_empties: entry not found!\n"); - lec_arp_put(priv); - spin_unlock_irqrestore(&priv->lec_arp_lock, flags); - return; + goto out; } del_timer(&entry->timer); memcpy(entry->mac_addr, src, ETH_ALEN); entry->status = ESI_FORWARD_DIRECT; entry->last_used = jiffies; prev->next = entry->next; - spin_unlock_irqrestore(&priv->lec_arp_lock, flags); if ((prev = lec_arp_find(priv, src))) { lec_arp_remove(priv, prev); kfree(prev); } lec_arp_add(priv, entry); - lec_arp_put(priv); +out: + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } MODULE_LICENSE("GPL"); ===== net/atm/lec.h 1.12 vs edited ===== --- 1.12/net/atm/lec.h 2004-08-23 04:14:59 -04:00 +++ edited/net/atm/lec.h 2005-01-06 11:11:18 -05:00 @@ -95,7 +95,6 @@ establishes multiple Multicast Forward VCCs to us. This list collects all those VCCs. LANEv1 client has only one item in this list. These entries are not aged out. */ - atomic_t lec_arp_users; spinlock_t lec_arp_lock; struct atm_vcc *mcast_vcc; /* Default Multicast Send VCC */ struct atm_vcc *lecd; From Robert.Olsson@data.slu.se Wed Jan 5 22:16:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 22:16:10 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j066G2xg024072 for ; Wed, 5 Jan 2005 22:16:03 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j06IFmuA026017; Thu, 6 Jan 2005 19:15:48 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 1AEABEC1A0; Thu, 6 Jan 2005 19:15:48 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.32852.11187.131058@robur.slu.se> Date: Thu, 6 Jan 2005 19:15:48 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson , Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501060926.54588.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501051325.40616.jeremy.guthrie@berbee.com> <16860.19615.251360.169722@robur.slu.se> <200501060926.54588.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > I still don't see the rt_cache_stat file even under 2.4.28 stock. See below. > ls -la /proc/net/stat/ > total 0 > -r--r--r-- 1 root root 0 Jan 6 09:22 rt_cache rtstat is replaced by lnstat which is in iproute2 package: http://developer.osdl.org/dev/iproute2/download/ (Old version ftp://robur.slu.se/pub/Linux/net-development/rt_cache_stat/rtstat.c) > cat /proc/net/softnet_stat > 96deb140 0032844e 00012bbb 00000fd8 00000000 00000000 00000000 00000000 > 00000dd4 > 00013dda 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 0000041f You only use CPU0 for packet processing. Also it seems you use the non-NAPI version of e1000. > cat /proc/interrupts > CPU0 CPU1 > 0: 821852 5664906 IO-APIC-edge timer > 1: 484 1247 IO-APIC-edge keyboard > 8: 0 2 IO-APIC-edge rtc > 14: 5 16 IO-APIC-edge ide0 > 18: 1928608529 1374 IO-APIC-level eth3 > 20: 1 226113098 IO-APIC-level eth2 > 27: 7950 34312 IO-APIC-level eth0 Traffic is flowing from eth3->eth2 Why all the interrupts on eth2/CPU1? Is traffic most unidirectional? --ro From shemminger@osdl.org Wed Jan 5 22:57:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 22:57:20 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j066vE9P025341 for ; Wed, 5 Jan 2005 22:57:14 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j06Iv2d29046 for ; Thu, 6 Jan 2005 10:57:02 -0800 Date: Thu, 6 Jan 2005 10:57:03 -0800 From: Stephen Hemminger To: netdev@oss.sgi.com Subject: Fw: [Bug 3998] New: ARP issues after 2.4.28-RC1 Message-ID: <20050106105703.3728eb2f@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev http://bugme.osdl.org/show_bug.cgi?id=3998 Summary: ARP issues after RC1 Kernel Version: 2.4.28 Status: NEW Severity: normal Owner: shemminger@osdl.org Submitter: terryb@d2.com Distribution: Redhat 9.0 Hardware Environment: Intel/IWill MBs. Intel e1000 and Broadcom tg3 network modules. Problem Description: After upgrading to 2.4.28, we having issues where hosts are unreachable and we are getting entries in the ARP tables. After the entry has cleared, the host will become reachable. This is most noticible upon startup, where netfs (nfs mounts), yp, and ntp fail, as they cannot reach their corresponding servers. This is happening on multiple machines, with different MBs and network interfaces, all running RedHat 9.0. 2.4.27, using the same .config had no such issues. After compiling all the pre and rc patches, it seems that the offending change occurred between rc1 and rc2. Steps to reproduce: 1. Install RH9, workstation install. 2. Configure NFS mounts in /etc/fstab, chkconfig netfs on. 3. Configure NTP, chkconfig ntp on. 4. Configure YP, chkconfig ypbind on. 5. Compile 2.4.28 using .config below 6. Reboot using 2.4.28. Upon boot, the services above will fail, as they cannot reach their servers. 7. Once up, log in as root and type arp -a. There will be entries for the unreachable hosts. 8. Compile 2.4.28-rc1, using the same .config. 9. Reboot using 2.4.28-rc1. All the previously failing services will start up with no issues. 10. Compile 2.4.28-rc2, using the same .config. 11. Reboot using 2.4.28-rc2. The services will fail once again. # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_HAS_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_F00F_WORKS_OK=y CONFIG_X86_MCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHIO=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_NR_CPUS=32 # CONFIG_X86_NUMA is not set # CONFIG_X86_TSC_DISABLE is not set CONFIG_X86_TSC=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_ISA=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_TCIC is not set # CONFIG_I82092 is not set # CONFIG_I82365 is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set # CONFIG_HOTPLUG_PCI_SHPC_PHPRM_LEGACY is not set # CONFIG_HOTPLUG_PCI_PCIE is not set # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_OOM_KILLER is not set # CONFIG_PM is not set # CONFIG_APM is not set # # ACPI Support # # CONFIG_ACPI is not set CONFIG_ACPI_BOOT=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_SX8 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_BLK_STATS is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_MD_MULTIPATH=y CONFIG_BLK_DEV_LVM=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y # CONFIG_IP_PNP_BOOTP is not set # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_QUEUE is not set # CONFIG_IP_NF_IPTABLES is not set # CONFIG_IP_NF_ARPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_IPX is not set CONFIG_ATALK=y # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set # CONFIG_BLK_DEV_IDE_SATA is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDECS is not set # CONFIG_BLK_DEV_DELKIN is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_BLK_DEV_GENERIC is not set CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_ADMA100 is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_PDC202XX_OLD=y # CONFIG_PDC202XX_BURST is not set CONFIG_BLK_DEV_PDC202XX_NEW=y # CONFIG_PDC202XX_FORCE is not set CONFIG_BLK_DEV_RZ1000=y # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_PDC202XX=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # CONFIG_BLK_DEV_ATARAID_MEDLEY is not set # CONFIG_BLK_DEV_ATARAID_SII is not set # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_PROBE_EISA_VL is not set # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_MEGARAID2 is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=y # CONFIG_SCSI_SATA_NV is not set # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_SX4 is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIS is not set # CONFIG_SCSI_SATA_ULI is not set # CONFIG_SCSI_SATA_VIA is not set # CONFIG_SCSI_SATA_VITESSE is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_SCSI_PCMCIA is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # CONFIG_IEEE1394=m CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_SBP2_PHYS_DMA=y # CONFIG_IEEE1394_ETH1394 is not set CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_CMP is not set # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_FORCEDETH is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_SUNDANCE_MMIO is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m # CONFIG_E1000_NAPI is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set CONFIG_TIGON3=m # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_PCMCIA_PCNET=y # CONFIG_PCMCIA_AXNET is not set # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_ARCNET_COM20020_CS is not set # CONFIG_PCMCIA_IBMTR is not set # CONFIG_PCMCIA_XIRCOM is not set # CONFIG_PCMCIA_XIRTULIP is not set CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_RAYCS=y # CONFIG_PCMCIA_NETWAVE is not set # CONFIG_PCMCIA_WAVELAN is not set # CONFIG_AIRONET4500_CS is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # CONFIG_INPUT=m CONFIG_INPUT_KEYBDEV=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=m CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set # CONFIG_INPUT_CS461X is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_INPUT_SERIO is not set # CONFIG_INPUT_SERPORT is not set # CONFIG_INPUT_ANALOG is not set # CONFIG_INPUT_A3D is not set # CONFIG_INPUT_ADI is not set # CONFIG_INPUT_COBRA is not set # CONFIG_INPUT_GF2K is not set # CONFIG_INPUT_GRIP is not set # CONFIG_INPUT_INTERACT is not set # CONFIG_INPUT_TMDC is not set # CONFIG_INPUT_SIDEWINDER is not set # CONFIG_INPUT_IFORCE_USB is not set # CONFIG_INPUT_IFORCE_232 is not set # CONFIG_INPUT_WARRIOR is not set # CONFIG_INPUT_MAGELLAN is not set # CONFIG_INPUT_SPACEORB is not set # CONFIG_INPUT_SPACEBALL is not set # CONFIG_INPUT_STINGER is not set # CONFIG_INPUT_DB9 is not set # CONFIG_INPUT_GAMECON is not set # CONFIG_INPUT_TURBOGRAFX is not set # CONFIG_QIC02_TAPE is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMI_PANIC_EVENT is not set # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_KCS is not set # CONFIG_IPMI_WATCHDOG is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_SCx200 is not set # CONFIG_SCx200_GPIO is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_HW_RANDOM is not set # CONFIG_AMD_PM768 is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_AGP_I810=y CONFIG_AGP_VIA=y CONFIG_AGP_AMD=y # CONFIG_AGP_AMD_K8 is not set CONFIG_AGP_SIS=y CONFIG_AGP_ALI=y CONFIG_AGP_SWORKS=y CONFIG_AGP_NVIDIA=y CONFIG_AGP_ATI=y # # Direct Rendering Manager (XFree86 DRI support) # CONFIG_DRM=y # CONFIG_DRM_OLD is not set CONFIG_DRM_NEW=y CONFIG_DRM_TDFX=y # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=y CONFIG_DRM_I810=y CONFIG_DRM_I810_XFREE_41=y # CONFIG_DRM_I830 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # # PCMCIA character devices # # CONFIG_PCMCIA_SERIAL_CS is not set # CONFIG_SYNCLINK_CS is not set # CONFIG_MWAVE is not set # CONFIG_OBMOUSE is not set # # Multimedia devices # CONFIG_VIDEO_DEV=y # # Video For Linux # CONFIG_VIDEO_PROC_FS=y # CONFIG_I2C_PARPORT is not set # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZORAN_BUZ is not set # CONFIG_VIDEO_ZORAN_DC10 is not set # CONFIG_VIDEO_ZORAN_LML33 is not set # CONFIG_VIDEO_ZR36120 is not set # CONFIG_VIDEO_MEYE is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_MIROPCM20 is not set # CONFIG_RADIO_MIROPCM20_RDS is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_QFMT_V2 is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_UMSDOS_FS=y CONFIG_VFAT_FS=y # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set CONFIG_NTFS_FS=y # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set CONFIG_UDF_FS=y # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # CONFIG_XFS_FS is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_RT is not set # CONFIG_XFS_TRACE is not set # CONFIG_XFS_DEBUG is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_DIRECTIO=y CONFIG_ROOT_NFS=y CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_NFSD_TCP=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_SMB_FS=y # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_SMB_UNIX is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # CONFIG_SOUND=m # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_MIDI_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set # CONFIG_SOUND_AD1980 is not set # CONFIG_SOUND_WM97XX is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_EHCI_HCD=m CONFIG_USB_UHCI=m # CONFIG_USB_UHCI_ALT is not set # CONFIG_USB_OHCI is not set # CONFIG_USB_SL811HS_ALT is not set # CONFIG_USB_SL811HS is not set CONFIG_USB_AUDIO=m CONFIG_USB_EMI26=m CONFIG_USB_BLUETOOTH=m CONFIG_USB_MIDI=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=m CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y CONFIG_USB_HIDDEV=y CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m # CONFIG_USB_AIPTEK is not set CONFIG_USB_WACOM=m # CONFIG_USB_KBTAB is not set CONFIG_USB_POWERMATE=m CONFIG_USB_DC2XX=m CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m # CONFIG_USB_HPUSBSCSI is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set CONFIG_USB_PWC=m # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_W9968CF is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set CONFIG_USB_RIO500=m CONFIG_USB_AUERSWALD=m CONFIG_USB_TIGL=m CONFIG_USB_BRLVGER=m CONFIG_USB_LCD=m # # Support for USB gadgets # # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=0 # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # CONFIG_CRC32=y # CONFIG_ZLIB_INFLATE is not set # CONFIG_ZLIB_DEFLATE is not set # CONFIG_FW_LOADER is not set ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jeremy.guthrie@berbee.com Wed Jan 5 23:36:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 23:36:17 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j067a87N026628 for ; Wed, 5 Jan 2005 23:36:08 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 13:35:55 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Thu, 6 Jan 2005 13:35:52 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501060926.54588.jeremy.guthrie@berbee.com> <16861.32852.11187.131058@robur.slu.se> In-Reply-To: <16861.32852.11187.131058@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11278716.QdpK7jeLio"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501061335.55104.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 06 Jan 2005 19:35:55.0690 (UTC) FILETIME=[F0AB28A0:01C4F426] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart11278716.QdpK7jeLio Content-Type: multipart/mixed; boundary="Boundary-01=_YMZ3BgNw2vwGpSi" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_YMZ3BgNw2vwGpSi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 06 January 2005 12:15 pm, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > I still don't see the rt_cache_stat file even under 2.4.28 stock. See > > below. > > > > ls -la /proc/net/stat/ > > total 0 > > -r--r--r-- 1 root root 0 Jan 6 09:22 rt_cache > > rtstat is replaced by lnstat which is in iproute2 package: > http://developer.osdl.org/dev/iproute2/download/ > > (Old version=20 > ftp://robur.slu.se/pub/Linux/net-development/rt_cache_stat/rtstat.c) Please see the attachment. > > cat /proc/net/softnet_stat > > 96deb140 0032844e 00012bbb 00000fd8 00000000 00000000 00000000 00000000 > > 00000dd4 > > 00013dda 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > 0000041f > > You only use CPU0 for packet processing. Also it seems you use the > non-NAPI version of e1000. The E1000 driver is the stock driver in 2.4.28. > > > cat /proc/interrupts > > CPU0 CPU1 > > 0: 821852 5664906 IO-APIC-edge timer > > 1: 484 1247 IO-APIC-edge keyboard > > 8: 0 2 IO-APIC-edge rtc > > 14: 5 16 IO-APIC-edge ide0 > > 18: 1928608529 1374 IO-APIC-level eth3 > > 20: 1 226113098 IO-APIC-level eth2 > > 27: 7950 34312 IO-APIC-level eth0 > > Traffic is flowing from eth3->eth2 Why all the interrupts on eth2/CPU1? > Is traffic most unidirectional? eth2 is TX only. We don't receive anything on it. This system should only= =20 ever RX on eth3 and TX on eth2 as part of its function. Eth0 is the=20 management interface on the host. =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --Boundary-01=_YMZ3BgNw2vwGpSi Content-Type: text/plain; charset="iso-8859-1"; name="results-2.4.28.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="results-2.4.28.txt" arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp| entries| allocs|destroys|hash_gro| lookups| hits|res_fail|rcv_prob|rcv_prob|periodic|forced_g|forced_g| entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| entries| allocs|destroys|hash_gro| lookups| hits|res_fail|rcv_prob|rcv_prob|periodic|forced_g|forced_g| | | | ws| | | ed|es_mcast|es_ucast|_gc_runs| c_runs|c_goal_m| | | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| | | | ws| | | ed|es_mcast|es_ucast|_gc_runs| c_runs|c_goal_m| | | | | | | | | | | | iss| | | | | | | | | | | | | | | | | | | | | | | | | | | | | iss| 22| 9| 425| 1| 17202| 14599| 0| 0| 0| 75743| 0| 0| 61129| 6329| 20428| 0| 0| 1539| 0| 0| 8| 28| 0| 1677| 1675| 0| 0| 143038| 145| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4649| 0| 0| 22| 0| 0| 0| 1| 1| 0| 0| 0| 2| 0| 0| 62833| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 10| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 1| 1| 0| 0| 0| 1| 0| 0| 64306| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 65602| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 59707| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 60684| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 62249| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 62249| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 65000| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 58800| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 58800| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 62135| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 63677| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 63677| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 59013| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 59013| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 62462| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 62462| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 1| 0| 0| 0| 0| 4| 0| 0| 65225| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 1| 0| 0| 0| 0| 4| 0| 0| 65225| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp| entries| allocs|destroys|hash_gro| lookups| hits|res_fail|rcv_prob|rcv_prob|periodic|forced_g|forced_g| entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| entries| allocs|destroys|hash_gro| lookups| hits|res_fail|rcv_prob|rcv_prob|periodic|forced_g|forced_g| | | | ws| | | ed|es_mcast|es_ucast|_gc_runs| c_runs|c_goal_m| | | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| | | | ws| | | ed|es_mcast|es_ucast|_gc_runs| c_runs|c_goal_m| | | | | | | | | | | | iss| | | | | | | | | | | | | | | | | | | | | | | | | | | | | iss| 24| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 60904| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 60904| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 63890| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 63890| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 59738| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 59738| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 63346| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 13| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 63346| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 13| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 0| 0| 0| 0| 4| 0| 0| 58798| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 13| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 0| 0| 0| 0| 4| 0| 0| 58798| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 13| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 62518| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 13| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 62518| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 13| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 2| 2| 0| 0| 0| 3| 0| 0| 65364| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 12| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 2| 2| 0| 0| 0| 3| 0| 0| 65364| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 12| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 2| 2| 0| 0| 0| 4| 0| 0| 61111| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 2| 2| 0| 0| 0| 4| 0| 0| 61111| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 63152| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 6| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 63152| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 6| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 58223| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 4| 0| 0| 58223| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|arp_cach|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp|clip_arp| entries| allocs|destroys|hash_gro| lookups| hits|res_fail|rcv_prob|rcv_prob|periodic|forced_g|forced_g| entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| entries| allocs|destroys|hash_gro| lookups| hits|res_fail|rcv_prob|rcv_prob|periodic|forced_g|forced_g| | | | ws| | | ed|es_mcast|es_ucast|_gc_runs| c_runs|c_goal_m| | | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| | | | ws| | | ed|es_mcast|es_ucast|_gc_runs| c_runs|c_goal_m| | | | | | | | | | | | iss| | | | | | | | | | | | | | | | | | | | | | | | | | | | | iss| 24| 0| 0| 0| 2| 2| 0| 0| 0| 4| 0| 0| 62044| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 15| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 2| 2| 0| 0| 0| 4| 0| 0| 62044| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 15| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 64932| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 64932| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 25| 0| 0| 0| 2| 2| 0| 0| 0| 4| 0| 0| 60712| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 14| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 1| 0| 1| 1| 0| 0| 0| 2| 0| 0| 62304| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 10| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 63758| 1| 1| 0| 0| 1| 0| 0| 0| 0| 0| 1| 1| 0| 0| 8| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0| 0| 64967| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 2| 0| 0| 58931| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 60836| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 6| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 2| 0| 0| 62574| 1| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 64121| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 1| 0| 0| 65615| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 10| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 2| 0| 0| 60057| 1| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23| 0| 0| 0| 1| 1| 0| 0| 0| 1| 0| 0| 62008| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 1| 1| 0| 0| 0| 1| 0| 0| 63651| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 1| 1| 0| 0| 0| 1| 0| 0| 63651| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 0| 1| 1| 0| 0| 0| 1| 0| 0| 63651| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 25| 0| 0| 0| 2| 2| 0| 0| 0| 6| 0| 0| 61300| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 12| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 63087| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| --Boundary-01=_YMZ3BgNw2vwGpSi-- --nextPart11278716.QdpK7jeLio Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3ZMbqtjaBHGZBeURAn36AJ0ZgrFrRrZ0ltYkf+9wcVopJboaBQCZAamg RbifMHm5Th0HwiWo6rysTbk= =TL7p -----END PGP SIGNATURE----- --nextPart11278716.QdpK7jeLio-- From tgraf@suug.ch Wed Jan 5 23:40:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 23:40:57 -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 j067epYJ027199 for ; Wed, 5 Jan 2005 23:40:51 -0800 Received: from postel.suug.ch (unknown [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 5E7B882; Thu, 6 Jan 2005 20:40:20 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 3E8C01C0EA; Thu, 6 Jan 2005 20:41:02 +0100 (CET) Date: Thu, 6 Jan 2005 20:41:02 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050106194102.GW26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <20050104223612.GN26856@postel.suug.ch> <1104894728.1117.56.camel@jzny.localdomain> <20050105110048.GO26856@postel.suug.ch> <1104931991.1117.152.camel@jzny.localdomain> <20050105144514.GQ26856@postel.suug.ch> <1105019225.2312.7.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1105019225.2312.7.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13471 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 * jamal <1105019225.2312.7.camel@jzny.localdomain> 2005-01-06 08:47 > So the issue is whether its by ref or copy? Maybe thats what the flag is > for then. My view is that _everything_ for ematches should be by copy > for simplicty. If we do everything as ref we'll be allocating 4 byte chunks or we introduce a storage u32 which pollutes the structure. I don't like that given that the transfer of a single u32 is probably the most common for all those smallish ematches for a specific thing. For simplicity, you don't even notice if you're not aware of that it can be of help so I don't think we're losing any simplicity here. > Oh, yes;-> the one check in the datapath comes with a _huge_ advantage > even all that you had was old style matches because now you have embeded > logical operations which are more than just the old AND. But more > importantly you can use ematches as well to influence the existing u32 > tree path. Missunderstanding here, I meant is there any advantage in having multiple ematch trees (interleaved) over just making the existing u32 key an ematch and have the selector (with the hashing bits extracted) with one ematch tree. > What i am reading is you see more work involved. Is this correct? Well, given we can agree on moving the u32 key to an ematch and have the selector replaced with an ematch tree the following modifications would be required in u32: 1) extract hashing bits out of selector and move it into a new TLV. 2) Replace the foreach key match loop with an ematch_tree match 3) Fill out a pkt_info struct with ptr and off2 so we don't lose hashing capabilities 4) Add backward compat code. Old selector must be transformed into a flat ematch tree and the hashing bits must be extracted and stored in the new struct. > There is one issue which i think is the big source of our lack of sync: > You conclude people are gonna want to use the logical tree building > scheme you are putting in to put together matches and ematches. U32 > _already_ has a tree building scheme which is very very flexible. I know and I'm not gonna break it but rather replace the ANDed u32 key chains with an ematch tree. I'm fully aware of what u32 can do and I will in no way remove anything. To make it clear, I'm only gonna change about 10 lines in classify: for (i = n->sel.nkeys; i>0; i--, key++) { if ((*(u32*)(ptr+key->off+(off2&key->offmask))^key->val)&key->mask) { n = n->next; goto next_knode; } } will be replaced with: info.nexthdr = off2; info.ptr = ptr; if (!tcf_em_tree_match(..., &info)) { n = n->next; goto next_knode; } That's all, nothing else is changed. I think this is exactly the part were we're out of sync. The most difficult part is to do the Kconfig dependencies in a smart way ;-> > Again, u32 classifier is not just matches; the more interesting thing > is the layout of the rules that it can be taught to do. > I think the ematch which emulates the std u32 match is of course > valuable to have but it _doesnt_ deserve the same name. Stupid terms, em_u32.c is a replacement for the u32 key and it has exactly the same behaviour. I'll be happy to rename it but as you know I really suck at naming things ;-> > Thinking more about it; not sure why you would even bother managing > them. Everything runs at the same kernel privilege level. I am not sure > you want to have certain things that can only be built when recompiling > the kernel Well, we have exactly the same issues as with TLV types. I don't see why one would need to recompile things. The enumeration is for ematches included in the kernel tree. From Robert.Olsson@data.slu.se Thu Jan 6 00:29:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 00:29:33 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j068TRwg031753 for ; Thu, 6 Jan 2005 00:29:28 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j06KTEuA023204; Thu, 6 Jan 2005 21:29:14 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 1E3E4EC1A0; Thu, 6 Jan 2005 21:29:14 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.40858.80960.794144@robur.slu.se> Date: Thu, 6 Jan 2005 21:29:14 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson , Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501061335.55104.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501060926.54588.jeremy.guthrie@berbee.com> <16861.32852.11187.131058@robur.slu.se> <200501061335.55104.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > > You only use CPU0 for packet processing. Also it seems you use the > > non-NAPI version of e1000. > The E1000 driver is the stock driver in 2.4.28. There is a kernel config option. Use Rx Polling (NAPI) > eth2 is TX only. We don't receive anything on it. This system should only > ever RX on eth3 and TX on eth2 as part of its function. Ok! So unidirectional traffic and CPU0 processes all skb's and passes them over to CPU1 which touches and frees them. You could try some other affinity setting later on but there are so many options depending what we want do. If we just want to compare 2.4/2.6 we can start out simple with setting affinity so only one CPU. Which is almost what you got. We reach all the complicated problems immediately... Now we pass skb's between the CPU's which release cache bouncing and makes slab rebalance it's pools. So using just one CPU is probably better... If we had incoming pkts on eth2 eventually we could have had any use for CPU1. Install NAPI-driver, set affinity so eth2/eth3 uses same CPU to start with. The stats info you sent was almost impossible to read. See if you can get only the rtstats. --ro From jeremy.guthrie@berbee.com Thu Jan 6 00:55:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 00:55:15 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j068t7Y8032633 for ; Thu, 6 Jan 2005 00:55:08 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 14:54:55 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Thu, 6 Jan 2005 14:54:51 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061335.55104.jeremy.guthrie@berbee.com> <16861.40858.80960.794144@robur.slu.se> In-Reply-To: <16861.40858.80960.794144@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1802544.rI78qs9h2M"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501061454.54595.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 06 Jan 2005 20:54:55.0490 (UTC) FILETIME=[F9CF3E20:01C4F431] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart1802544.rI78qs9h2M Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 06 January 2005 02:29 pm, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > > You only use CPU0 for packet processing. Also it seems you use the > > > non-NAPI version of e1000. > > > > The E1000 driver is the stock driver in 2.4.28. > There is a kernel config option. Use Rx Polling (NAPI) I'm recompiling the module and will reload the module. > > eth2 is TX only. We don't receive anything on it. This system should > > only ever RX on eth3 and TX on eth2 as part of its function. > > Ok! So unidirectional traffic and CPU0 processes all skb's and passes th= em > over to CPU1 which touches and frees them. You could try some other > affinity setting later on but there are so many options depending what > we want do. If we just want to compare 2.4/2.6 we can start out simple > with setting affinity so only one CPU. Which is almost what you got. > We reach all the complicated problems immediately... Now we pass skb's > between the CPU's which release cache bouncing and makes slab rebalance > it's pools. So using just one CPU is probably better... If we had incoming > pkts on eth2 eventually we could have had any use for CPU1. > > Install NAPI-driver, set affinity so eth2/eth3 uses same CPU to start > with. I installed the NAPI driver and now I drop packets under 2.4.28. I tried=20 setting eth2/3 onto the same CPU. If both eth2/3 are on CPU0, I drop a lot= =20 of packets. If CPU0-eth2 & CPU1-eth3, I still drop packets, just not as=20 fast. I am going to try V2.6 w/o NAPI to see how much that helps. > The stats info you sent was almost impossible to read. See if you can get > only the rtstats. =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart1802544.rI78qs9h2M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3aWeqtjaBHGZBeURAgJLAJ9Ivcgnf/HcOFB4eMC9XGFGC1ck4wCfeYG/ MT8a07gBXWfgSiaudO8YcDs= =bxZV -----END PGP SIGNATURE----- --nextPart1802544.rI78qs9h2M-- From jeremy.guthrie@berbee.com Thu Jan 6 00:56:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 00:56:18 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j068u6M1000431 for ; Thu, 6 Jan 2005 00:56:10 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 14:55:54 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Thu, 6 Jan 2005 14:55:50 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061335.55104.jeremy.guthrie@berbee.com> <16861.40858.80960.794144@robur.slu.se> In-Reply-To: <16861.40858.80960.794144@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1938077.N2rRDRFtMu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501061455.53590.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 06 Jan 2005 20:55:54.0225 (UTC) FILETIME=[1CD17E10:01C4F432] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart1938077.N2rRDRFtMu Content-Type: multipart/mixed; boundary="Boundary-01=_XXa3BZ690xkxonk" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_XXa3BZ690xkxonk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46orgot the attachment. =20 On Thursday 06 January 2005 02:29 pm, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > > You only use CPU0 for packet processing. Also it seems you use the > > > non-NAPI version of e1000. > > > > The E1000 driver is the stock driver in 2.4.28. > > There is a kernel config option. Use Rx Polling (NAPI) > > > eth2 is TX only. We don't receive anything on it. This system should > > only ever RX on eth3 and TX on eth2 as part of its function. > > Ok! So unidirectional traffic and CPU0 processes all skb's and passes th= em > over to CPU1 which touches and frees them. You could try some other > affinity setting later on but there are so many options depending what > we want do. If we just want to compare 2.4/2.6 we can start out simple > with setting affinity so only one CPU. Which is almost what you got. > We reach all the complicated problems immediately... Now we pass skb's > between the CPU's which release cache bouncing and makes slab rebalance > it's pools. So using just one CPU is probably better... If we had incoming > pkts on eth2 eventually we could have had any use for CPU1. > > Install NAPI-driver, set affinity so eth2/eth3 uses same CPU to start > with. > > The stats info you sent was almost impossible to read. See if you can get > only the rtstats. > > --ro =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --Boundary-01=_XXa3BZ690xkxonk Content-Type: text/plain; charset="iso-8859-1"; name="results-2.4.28.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="results-2.4.28.txt" rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| 9092| 21888| 0| 0| 1656| 0| 0| 9| 42| 0| 1836| 1833| 0| 0| 158622| 206| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 1| 1| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 1| 1| 0| 0| 9| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 14| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 14| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 1| 1| 0| 0| 14| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 1| 1| 0| 0| 14| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| 1| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 16| 0| 1| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 16| 0| 1| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 16| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 8| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 8| 0| 2| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 16| 0| 1| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 8| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 6| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 6| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 6| 0| 2| 2| 0| 0| 1| 0| 0| 0| 0| 0| 1| 1| 0| 0| 24| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 2| 0| 0| 1| 0| 0| 0| 0| 0| 1| 1| 0| 0| 16| 0| 0| 2| 0| 0| 1| 0| 0| 0| 0| 0| 1| 1| 0| 0| 16| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| --Boundary-01=_XXa3BZ690xkxonk-- --nextPart1938077.N2rRDRFtMu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3aXZqtjaBHGZBeURAjLjAJkBi385GCSOhiNUVhsZwINncCXMKQCgkGNO KF1TaJcccd9gfXJxV+yZeXs= =A1iR -----END PGP SIGNATURE----- --nextPart1938077.N2rRDRFtMu-- From jeremy.guthrie@berbee.com Thu Jan 6 01:20:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 01:20:26 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j069KFka001612 for ; Thu, 6 Jan 2005 01:20:19 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 15:20:02 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Thu, 6 Jan 2005 15:19:59 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061335.55104.jeremy.guthrie@berbee.com> <16861.40858.80960.794144@robur.slu.se> In-Reply-To: <16861.40858.80960.794144@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1762425.JcF5JoSj3n"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501061520.02362.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 06 Jan 2005 21:20:02.0949 (UTC) FILETIME=[7C533B50:01C4F435] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart1762425.JcF5JoSj3n Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Pulling Rx Polling has kept V2.6 from dropping packets. argh?!?!?! I shou= ld=20 have caught that sooner. 8( Well, I have a window of opportunity here. = If=20 you want I can still provide a broken environment but that seems pointless= =20 while NAPI is not acting right... what is evident is that this will run=20 better till we start to bump up against the top of CPU0. On Thursday 06 January 2005 02:29 pm, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > > You only use CPU0 for packet processing. Also it seems you use the > > > non-NAPI version of e1000. > > > > The E1000 driver is the stock driver in 2.4.28. > > There is a kernel config option. Use Rx Polling (NAPI) > > > eth2 is TX only. We don't receive anything on it. This system should > > only ever RX on eth3 and TX on eth2 as part of its function. > > Ok! So unidirectional traffic and CPU0 processes all skb's and passes th= em > over to CPU1 which touches and frees them. You could try some other > affinity setting later on but there are so many options depending what > we want do. If we just want to compare 2.4/2.6 we can start out simple > with setting affinity so only one CPU. Which is almost what you got. > We reach all the complicated problems immediately... Now we pass skb's > between the CPU's which release cache bouncing and makes slab rebalance > it's pools. So using just one CPU is probably better... If we had incoming > pkts on eth2 eventually we could have had any use for CPU1. > > Install NAPI-driver, set affinity so eth2/eth3 uses same CPU to start > with. > > The stats info you sent was almost impossible to read. See if you can get > only the rtstats. > > --ro =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart1762425.JcF5JoSj3n Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3auCqtjaBHGZBeURAjvkAJ45z7mmyPo5uy7j5n6AUuz9mom0ZwCfabzF 9epO/lWTp3KOLc5IGxztcJU= =c04g -----END PGP SIGNATURE----- --nextPart1762425.JcF5JoSj3n-- From Robert.Olsson@data.slu.se Thu Jan 6 01:36:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 01:36:26 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j069aJ0b002457 for ; Thu, 6 Jan 2005 01:36:19 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j06La6uA016530; Thu, 6 Jan 2005 22:36:06 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 014E9EC1A0; Thu, 6 Jan 2005 22:36:06 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.44870.968343.578778@robur.slu.se> Date: Thu, 6 Jan 2005 22:36:06 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson , Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501061520.02362.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061335.55104.jeremy.guthrie@berbee.com> <16861.40858.80960.794144@robur.slu.se> <200501061520.02362.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > Pulling Rx Polling has kept V2.6 from dropping packets. argh?!?!?! Thats fine... > I should have caught that sooner. 8( Well, I have a window of opportunity > here. If you want I can still provide a broken environment but that seems > pointless while NAPI is not acting right... what is evident is that this > will run better till we start to bump up against the top of CPU0. I don't follow... The stats didn't show any numbers so we don't know your load. --ro From jeremy.guthrie@berbee.com Thu Jan 6 01:46:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 01:46:52 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j069kjVq003202 for ; Thu, 6 Jan 2005 01:46:45 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 15:46:32 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Thu, 6 Jan 2005 15:46:29 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061520.02362.jeremy.guthrie@berbee.com> <16861.44870.968343.578778@robur.slu.se> In-Reply-To: <16861.44870.968343.578778@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6041310.sTJrLWFtUM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501061546.32116.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 06 Jan 2005 21:46:32.0861 (UTC) FILETIME=[2FFC8CD0:01C4F439] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart6041310.sTJrLWFtUM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 06 January 2005 03:36 pm, Robert Olsson wrote: > > I should have caught that sooner. 8( Well, I have a window of > > opportunity here. If you want I can still provide a broken environment > > but that seems pointless while NAPI is not acting right... what is > > evident is that this will run better till we start to bump up against > > the top of CPU0. > > I don't follow... Technically by turning off NAPI, I have 'solved' my short term packet loss= =20 problem. However I can still provide you a window to go through further troubleshoot= ing=20 if it is beneficial. > The stats didn't show any numbers so we don't know your load. Are you referring to the # of entries in the rt_cache table? =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart6041310.sTJrLWFtUM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3bG4qtjaBHGZBeURAlh6AKCGTkaEa8sKvtg4k1Un3T474YTG/ACeLIZb 2eeMHU7sz23LBGz7Gv/NpKA= =cn/n -----END PGP SIGNATURE----- --nextPart6041310.sTJrLWFtUM-- From jketreno@linux.intel.com Thu Jan 6 02:11:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 02:11:12 -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 j06AB3gZ010810 for ; Thu, 6 Jan 2005 02:11:07 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) 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 j06MAnXD003597; Thu, 6 Jan 2005 22:10:49 GMT Received: from [127.0.0.1] (hdlrvguser-533.hd.intel.com [10.127.54.40]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with ESMTP id j06M2KRY031348; Thu, 6 Jan 2005 22:02:24 GMT Message-ID: <41DD630A.1030604@linux.intel.com> Date: Thu, 06 Jan 2005 10:10:50 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Netdev Subject: Re: Steps for netdev-2.6 inclusion? References: <41AE7143.80505@linux.intel.com> <41C88183.3020906@pobox.com> In-Reply-To: <41C88183.3020906@pobox.com> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > James Ketrenos wrote: > >> >> Ok, its been a long time coming, but it appears the ipw* wireless >> drivers are to the point where being more proactive at getting them >> into the kernel is appropriate (at least based on the frequency of >> emails I'm getting of 'why isn't this in mainline?') >> >> So, what would be the set of steps required to get a version in the >> queue for inclusion? > > > Any updates? Where do we stand with this? Sorry -- we had some fires to put out, and then Christmas kicked in :) We're rolling in a couple fixes into the 2200 driver this week for ad-hoc mode and will then send out the patches to this list. Thanks, James > > I would suggest sending a patch for each driver, diff'd against -mm > (which auto-includes my netdev-2.6 and wireless-2.6 queues). > > Jeff > > > From Robert.Olsson@data.slu.se Thu Jan 6 02:11:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 02:11:23 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06ABHkJ010853 for ; Thu, 6 Jan 2005 02:11:18 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j06MB5uA029066; Thu, 6 Jan 2005 23:11:05 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 8B1F8EC1A0; Thu, 6 Jan 2005 23:11:05 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.46969.536236.11355@robur.slu.se> Date: Thu, 6 Jan 2005 23:11:05 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson , Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501061546.32116.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061520.02362.jeremy.guthrie@berbee.com> <16861.44870.968343.578778@robur.slu.se> <200501061546.32116.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > > I don't follow... > Technically by turning off NAPI, I have 'solved' my short term packet loss > problem. You need NAPI of course just wait until your packet load increases just a little bit... I saw drops in your 2.4 /proc/net/softnet_stat which indicates you are close to your system performance. With NAPI you keep up your system system performance regardless of incoming load. The e1000 driver has some bugs in "your setup" as it enables irq's when there is only RX and no TX and should have irq's disabled. I sent patch to intel. --ro From jeremy.guthrie@berbee.com Thu Jan 6 02:18:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 02:18:44 -0800 (PST) Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net [64.73.12.254]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06AIbIo011836 for ; Thu, 6 Jan 2005 02:18:37 -0800 Received: from localhost ([172.30.254.220] RDNS failed) by ctg-msnexc01.staff.berbee.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 16:18:25 -0600 From: "Jeremy M. Guthrie" Reply-To: jeremy.guthrie@berbee.com Organization: Berbee Information Networks To: netdev@oss.sgi.com Subject: Re: V2.4 policy router operates faster/better than V2.6 Date: Thu, 6 Jan 2005 16:18:21 -0600 User-Agent: KMail/1.7.2 Cc: Robert Olsson , Stephen Hemminger References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061546.32116.jeremy.guthrie@berbee.com> <16861.46969.536236.11355@robur.slu.se> In-Reply-To: <16861.46969.536236.11355@robur.slu.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1568023.hnZFYY8YNB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501061618.24465.jeremy.guthrie@berbee.com> X-OriginalArrivalTime: 06 Jan 2005 22:18:25.0053 (UTC) FILETIME=[A3BDE4D0:01C4F43D] X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeremy.guthrie@berbee.com Precedence: bulk X-list: netdev --nextPart1568023.hnZFYY8YNB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 06 January 2005 04:11 pm, Robert Olsson wrote: > Jeremy M. Guthrie writes: > > > I don't follow... > > > > Technically by turning off NAPI, I have 'solved' my short term packet > > loss problem. > > You need NAPI of course just wait until your packet load increases just > a little bit...=20 I agree. Running mpstat now shows that even w/o packet drops, I'm running= =20 2-5% free CPU. > I saw drops in your 2.4 /proc/net/softnet_stat which=20 > indicates you are close to your system performance.=20 Should those drops show up in RX drops in ifconfig? > With NAPI you keep=20 > up your system system performance regardless of incoming load. You mentioned before that " The stats didn't show any numbers so we don't k= now=20 your load." Was there a command you wanted me to re-run? > The e1000 driver has some bugs in "your setup" as it enables irq's when > there is only RX and no TX and should have irq's disabled. I sent patch > to intel. > > --ro =2D-=20 =2D------------------------------------------------- Jeremy M. Guthrie jeremy.guthrie@berbee.com Senior Network Engineer Phone: 608-298-1061 Berbee Fax: 608-288-3007 5520 Research Park Drive NOC: 608-298-1102 Madison, WI 53711 --nextPart1568023.hnZFYY8YNB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB3bkwqtjaBHGZBeURAhwtAJ0dxJdldtO4/T6CJ8GUHnZeyCD8MwCdE0qt FNGzOiQeLVhCPgFf47mSIvM= =JJXF -----END PGP SIGNATURE----- --nextPart1568023.hnZFYY8YNB-- From Robert.Olsson@data.slu.se Thu Jan 6 02:36:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 02:36:26 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06AaGZl012707 for ; Thu, 6 Jan 2005 02:36:21 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id j06MZxuA007354; Thu, 6 Jan 2005 23:35:59 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id C2E30EC1A0; Thu, 6 Jan 2005 23:35:59 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.48463.770166.352726@robur.slu.se> Date: Thu, 6 Jan 2005 23:35:59 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson , Stephen Hemminger Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501061618.24465.jeremy.guthrie@berbee.com> References: <200501031455.26980.jeremy.guthrie@berbee.com> <200501061546.32116.jeremy.guthrie@berbee.com> <16861.46969.536236.11355@robur.slu.se> <200501061618.24465.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > You mentioned before that " The stats didn't show any numbers so we don't > know your load." Was there a command you wanted me to re-run? rtstat should show the routing/packet load. From a systems like yours 2*933 MHz PIII in production for tens of thoundans of users many filter and full BGP routing. Current (late here) use. ifstat2 eth* RX -------------------------- TX ------------------------- eth0 272.8 M bit/s 51 k pps 350.7 M bit/s 51 k pps eth1 371.9 M bit/s 55 k pps 293.6 M bit/s 55 k pps eth2 6.7 M bit/s 1348 pps 3.0 M bit/s 991 pps eth3 472 bit/s 0 pps 600 bit/s 0 pps rtstat size IN: hit tot mc no_rt bcast madst masrc OUT: hit tot mc GC: tot ignored goal_miss ovrf HASH: in_search out_search 21007 114060 748 0 5 0 0 0 11 5 0 0 0 0 0 58280 4 22683 112556 827 0 6 0 0 0 5 5 0 0 0 0 0 60841 7 24230 111083 765 0 4 0 0 0 13 4 0 0 0 0 0 66628 7 Around 110 kpps hitting warm cache entries and ~800 new lookups/sec. I was expecting so see something similar from your system. FYI. cat /proc/net/softnet_stat 9ba490f3 00000000 01281572 00000000 00000000 00000000 00000000 00000000 002562c2 9939268d 00000000 010e42e9 00000000 00000000 00000000 00000000 00000000 0028fe72 Good Night. --ro From jgarzik@pobox.com Thu Jan 6 02:45:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 02:45:38 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06AjQEk015228 for ; Thu, 6 Jan 2005 02:45:31 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CmgNW-0006Ot-Ej; Thu, 06 Jan 2005 22:45:14 +0000 Message-ID: <41DDBF72.4000406@pobox.com> Date: Thu, 06 Jan 2005 17:45:06 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com, agx@sigxcpu.org, lars@segv.dk Subject: Re: [patch 03/10] pcnet32: 79c976 with fiber optic fix References: <200501050559.j055xb614676@mail.osdl.org> In-Reply-To: <200501050559.j055xb614676@mail.osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev akpm@osdl.org wrote: > From: Guido Guenther , > Lars Munch > > Skip PHY selection on Allied Telesyn 2701FX, it looses the link otherwise. > Fix up the AT 2701 as well. > > Signed-Off-By: Guido Guenther > Signed-off-by: Andrew Morton Don, any comments? Jeff From brazilnut@us.ibm.com Thu Jan 6 03:20:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:20:55 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06BKgqA017153 for ; Thu, 6 Jan 2005 03:20:48 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j06NKTCO566962 for ; Thu, 6 Jan 2005 18:20:29 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j06NKS4J307584 for ; Thu, 6 Jan 2005 16:20:28 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j06NKREs014909 for ; Thu, 6 Jan 2005 16:20:28 -0700 Received: from DYN319661.beaverton.ibm.com (DYN319661.beaverton.ibm.com [9.47.22.144]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j06NKRvS014893; Thu, 6 Jan 2005 16:20:27 -0700 Received: by DYN319661.beaverton.ibm.com (Postfix, from userid 1000) id B546B22942E; Thu, 6 Jan 2005 15:19:56 -0800 (PST) Date: Thu, 6 Jan 2005 15:19:56 -0800 From: Don Fry To: Jeff Garzik Cc: akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com, agx@sigxcpu.org, lars@segv.dk Subject: Re: [patch 03/10] pcnet32: 79c976 with fiber optic fix Message-ID: <20050106231956.GA22130@us.ibm.com> References: <200501050559.j055xb614676@mail.osdl.org> <41DDBF72.4000406@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DDBF72.4000406@pobox.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Sorry for the delay, I had a nice vacation and am a little slow getting through the email. Three comments: 1) I recently obtained a 2701FX card but I haven't installed it in a system yet, but I will today. 2) Thomas Bogendorfer was working on a patch to support a board with both a fiber and copper connection on the same board. He is still cooking that change, but it changes code in the same place, but in a different way. 3) I will send another email, later today or tomorrow morning, after I have been able to do a little testing of the patch. On Thu, Jan 06, 2005 at 05:45:06PM -0500, Jeff Garzik wrote: > akpm@osdl.org wrote: > >From: Guido Guenther , > > Lars Munch > > > >Skip PHY selection on Allied Telesyn 2701FX, it looses the link otherwise. > >Fix up the AT 2701 as well. > > > >Signed-Off-By: Guido Guenther > >Signed-off-by: Andrew Morton > > Don, any comments? > > Jeff -- Don Fry brazilnut@us.ibm.com From davem@davemloft.net Thu Jan 6 03:23:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:24:01 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06BNokw017665 for ; Thu, 6 Jan 2005 03:23:55 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CmguM-0002NA-00; Thu, 06 Jan 2005 15:19:10 -0800 Date: Thu, 6 Jan 2005 15:19:10 -0800 From: "David S. Miller" To: Peter Chubb Cc: peterc@gelato.unsw.edu.au, netdev@oss.sgi.com Subject: Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way) Message-Id: <20050106151910.4d51673e.davem@davemloft.net> In-Reply-To: <16839.30796.413939.333935@wombat.chubb.wattle.id.au> References: <16839.27239.264551.415058@berry.gelato.unsw.EDU.AU> <20041220161552.2b88aa3d.davem@davemloft.net> <16839.30796.413939.333935@wombat.chubb.wattle.id.au> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Peter, let me know if this patch solves your PHY link up problem too. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/01/06 14:53:55-08:00 davem@nuts.davemloft.net # [TG3]: Return 0 when PHY read times out, not all-ones. # # Noticed by Peter Chubb. # # Signed-off-by: David S. Miller # # drivers/net/tg3.c # 2005/01/06 14:53:07-08:00 davem@nuts.davemloft.net +1 -1 # [TG3]: Return 0 when PHY read times out, not all-ones. # diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c 2005-01-06 14:54:21 -08:00 +++ b/drivers/net/tg3.c 2005-01-06 14:54:21 -08:00 @@ -485,7 +485,7 @@ udelay(80); } - *val = 0xffffffff; + *val = 0x0; frame_val = ((PHY_ADDR << MI_COM_PHY_ADDR_SHIFT) & MI_COM_PHY_ADDR_MASK); From juhl-lkml@dif.dk Thu Jan 6 03:24:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:24:20 -0800 (PST) Received: from mail.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06BO9Jx017694 for ; Thu, 6 Jan 2005 03:24:10 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.dif.dk (Postfix) with ESMTP id 2E3C5FFC6E for ; Fri, 7 Jan 2005 00:28:11 +0100 (CET) Received: from mail.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27879-05 for ; Fri, 7 Jan 2005 00:28:10 +0100 (CET) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by mail.dif.dk (Postfix) with ESMTP id 1ACACFFC78 for ; Fri, 7 Jan 2005 00:28:10 +0100 (CET) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Fri, 07 Jan 2005 00:23:21 +0100 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CHBN3HT1; Fri, 7 Jan 2005 00:23:54 +0100 Date: Fri, 7 Jan 2005 00:35:24 +0100 (CET) From: Jesper Juhl To: linux-kernel Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, Jorge Cwik , Arnt Gulbrandsen Subject: [patch] net: get rid of redundant access_ok() call in checksum calculation. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 13485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Hi, in include/net/checksum.h::csum_and_copy_to_user it would seem that the access_ok() call before attempting to call copy_to_user() is redundant since copy_to_user() calls access_ok() internally. If that is indeed the case then please consider applying the patch below (if that access_ok() does make sense I'd apreciate to be told why). Signed-off-by: Jesper Juhl diff -up linux-2.6.10-bk9-orig/include/net/checksum.h linux-2.6.10-bk9/include/net/checksum.h --- linux-2.6.10-bk9-orig/include/net/checksum.h 2004-12-24 22:34:26.000000000 +0100 +++ linux-2.6.10-bk9/include/net/checksum.h 2005-01-07 00:27:05.000000000 +0100 @@ -46,10 +46,9 @@ static __inline__ unsigned int csum_and_ { sum = csum_partial(src, len, sum); - if (access_ok(VERIFY_WRITE, dst, len)) { - if (copy_to_user(dst, src, len) == 0) - return sum; - } + if (copy_to_user(dst, src, len) == 0) + return sum; + if (len) *err_ptr = -EFAULT; From nacc@us.ibm.com Thu Jan 6 03:34:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:34:44 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06BYXW0018758 for ; Thu, 6 Jan 2005 03:34:38 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j06NYLvk014683 for ; Thu, 6 Jan 2005 18:34:21 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j06NYL8m263758 for ; Thu, 6 Jan 2005 18:34:21 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j06NYLHd001357 for ; Thu, 6 Jan 2005 18:34:21 -0500 Received: from joust (joust.beaverton.ibm.com [9.47.17.70]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j06NYKqA001338; Thu, 6 Jan 2005 18:34:21 -0500 Received: by joust (Postfix, from userid 1000) id 015094F966; Thu, 6 Jan 2005 15:34:19 -0800 (PST) Date: Thu, 6 Jan 2005 15:34:19 -0800 From: Nishanth Aravamudan To: kernel-janitors@lists.osdl.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH 3/28] net/airo: replace schedule_timeout() with msleep()/ssleep() Message-ID: <20050106233419.GD3055@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Hi, Description: Use msleep()/ssleep() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan --- 2.6.10-v/drivers/net/wireless/airo.c 2004-12-24 13:33:59.000000000 -0800 +++ 2.6.10/drivers/net/wireless/airo.c 2005-01-04 14:57:49.000000000 -0800 @@ -1699,9 +1699,8 @@ static int readBSSListRid(struct airo_in issuecommand(ai, &cmd, &rsp); up(&ai->sem); /* Let the command take effect */ - set_current_state (TASK_INTERRUPTIBLE); ai->task = current; - schedule_timeout (3*HZ); + ssleep(3); ai->task = NULL; } rc = PC4500_readrid(ai, first ? RID_BSSLISTFIRST : RID_BSSLISTNEXT, @@ -2686,11 +2685,9 @@ int reset_card( struct net_device *dev , return -1; waitbusy (ai); OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); waitbusy (ai); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); if (lock) up(&ai->sem); return 0; @@ -5518,12 +5515,12 @@ static int airo_pci_resume(struct pci_de } else { OUT4500(ai, EVACK, EV_AWAKEN); OUT4500(ai, EVACK, EV_AWAKEN); - schedule_timeout(HZ/10); + msleep(100); } set_bit (FLAG_COMMIT, &ai->flags); disable_MAC(ai, 0); - schedule_timeout (HZ/5); + msleep(200); if (ai->SSID) { writeSsidRid(ai, ai->SSID, 0); kfree(ai->SSID); @@ -7472,8 +7469,7 @@ int cmdreset(struct airo_info *ai) { OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* WAS 600 12/7/00 */ + ssleep(1); /* WAS 600 12/7/00 */ if(!waitbusy (ai)){ printk(KERN_INFO "Waitbusy hang AFTER RESET\n"); @@ -7500,8 +7496,7 @@ int setflashmode (struct airo_info *ai) OUT4500(ai, SWS3, FLASH_COMMAND); OUT4500(ai, COMMAND,0); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/2); /* 500ms delay */ + msleep(500); /* 500ms delay */ if(!waitbusy(ai)) { clear_bit (FLAG_FLASHING, &ai->flags); @@ -7611,8 +7606,7 @@ int flashputbuf(struct airo_info *ai){ int flashrestart(struct airo_info *ai,struct net_device *dev){ int i,status; - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + ssleep(1); /* Added 12/7/00 */ clear_bit (FLAG_FLASHING, &ai->flags); if (test_bit(FLAG_MPI, &ai->flags)) { status = mpi_init_descriptors(ai); @@ -7627,8 +7621,7 @@ int flashrestart(struct airo_info *ai,st ( ai, 2312, i >= MAX_FIDS / 2 ); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + ssleep(1); /* Added 12/7/00 */ return status; } #endif /* CISCO_EXT */ From davem@davemloft.net Thu Jan 6 03:35:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:35:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06BZS12019084 for ; Thu, 6 Jan 2005 03:35:29 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1Cmh5f-0002P9-00; Thu, 06 Jan 2005 15:30:51 -0800 Date: Thu, 6 Jan 2005 15:30:51 -0800 From: "David S. Miller" To: hadi@znyx.com Cc: netdev@oss.sgi.com Subject: Re: 2.4.x patchlet Message-Id: <20050106153051.7d0fb873.davem@davemloft.net> In-Reply-To: <1104242685.1090.97.camel@jzny.localdomain> References: <1104242685.1090.97.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On 28 Dec 2004 09:04:45 -0500 Jamal Hadi Salim wrote: > Removes annoying compile of newer tools when done on 2.4.x Applied, thanks Jamal. From jgarzik@pobox.com Thu Jan 6 03:36:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:36:11 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06Ba1O7019491 for ; Thu, 6 Jan 2005 03:36:05 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CmhAX-0007bG-8B; Thu, 06 Jan 2005 23:35:53 +0000 Message-ID: <41DDCB54.2080101@pobox.com> Date: Thu, 06 Jan 2005 18:35:48 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniele Venzano CC: NetDev Subject: Re: [PATCH 1/5] sis900 debugging and revision code References: <20041212121852.GA16325@gateway.milesteg.arr> <20041212123031.GB16325@gateway.milesteg.arr> In-Reply-To: <20041212123031.GB16325@gateway.milesteg.arr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Patches 1, 2, and 5 are OK. For the other two patches, I don't want to deviate from the style that has been standard for years: dev->name prefix, followed by message. It may make greps easier for you, but it becomes a non-standard style and may make existing sysadmin scripts out in the field. Please resend series without the PFX-where-devname-is-known changes. Jeff From nacc@us.ibm.com Thu Jan 6 03:41:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:41:57 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06Bfmbj020208 for ; Thu, 6 Jan 2005 03:41:52 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j06NfZvk028775 for ; Thu, 6 Jan 2005 18:41:35 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j06NfZ8m202858 for ; Thu, 6 Jan 2005 18:41:35 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j06NfZJb014333 for ; Thu, 6 Jan 2005 18:41:35 -0500 Received: from joust (joust.beaverton.ibm.com [9.47.17.70]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j06NfZoO014328; Thu, 6 Jan 2005 18:41:35 -0500 Received: by joust (Postfix, from userid 1000) id 80D794F966; Thu, 6 Jan 2005 15:41:34 -0800 (PST) Date: Thu, 6 Jan 2005 15:41:34 -0800 From: Nishanth Aravamudan To: kernel-janitors@lists.osdl.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH 4/28] net/cosa: replace schedule_timeout() with msleep() Message-ID: <20050106234134.GE3055@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Hi, Description: Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. Also uses the set_current_state() macro instead of direct assignment in a pair of spots. I am still concerned about those sleeps, as TASK_INTERRUPTIBLE() is used without any checking for signals. Hence I used msleep() for the longer delay. Perhaps the 30 jiffy delay has not been updated for the larger HZ values and thus could be changed to msleep(300). Signed-off-by: Nishanth Aravamudan --- 2.6.10-v/drivers/net/wan/cosa.c 2004-12-24 13:33:49.000000000 -0800 +++ 2.6.10/drivers/net/wan/cosa.c 2005-01-04 14:57:49.000000000 -0800 @@ -543,7 +543,7 @@ static int cosa_probe(int base, int irq, * FIXME: When this code is not used as module, we should * probably call udelay() instead of the interruptible sleep. */ - current->state = TASK_INTERRUPTIBLE; + set_current_state(TASK_INTERRUPTIBLE); cosa_putstatus(cosa, SR_TX_INT_ENA); schedule_timeout(30); irq = probe_irq_off(irqs); @@ -1564,8 +1564,7 @@ static int cosa_reset_and_read_id(struct cosa_getdata8(cosa); cosa_putstatus(cosa, SR_RST); #ifdef MODULE - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(HZ/2); + msleep(500); #else udelay(5*100000); #endif @@ -1618,7 +1617,7 @@ static int get_wait_data(struct cosa_dat return r; } /* sleep if not ready to read */ - current->state = TASK_INTERRUPTIBLE; + set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(1); } printk(KERN_INFO "cosa: timeout in get_wait_data (status 0x%x)\n", From davem@davemloft.net Thu Jan 6 03:51:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:51:11 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06Box6c020812 for ; Thu, 6 Jan 2005 03:51:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CmhKc-0002Ra-00; Thu, 06 Jan 2005 15:46:18 -0800 Date: Thu, 6 Jan 2005 15:46:18 -0800 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: Re: [PATCH][TCP] merge tcp_sock with tcp_opt Message-Id: <20050106154618.12d7b7d1.davem@davemloft.net> In-Reply-To: <41D1A876.9050609@conectiva.com.br> References: <41D1A876.9050609@conectiva.com.br> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 28 Dec 2004 16:39:50 -0200 Arnaldo Carvalho de Melo wrote: > Here is the tcp_sock one, please consider pulling from: > > bk://kernel.bkbits.net/acme/connection_sock-2.6 Pulled, thanks Arnaldo. From jgarzik@pobox.com Thu Jan 6 03:52:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 03:52:05 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06Bq0fd021136 for ; Thu, 6 Jan 2005 03:52:00 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CmhQ0-0007y5-4q; Thu, 06 Jan 2005 23:51:52 +0000 Message-ID: <41DDCF00.6070405@pobox.com> Date: Thu, 06 Jan 2005 18:51:28 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" , Netdev Subject: BK-current build breakage Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev net/built-in.o(.text+0x25858): In function `tcf_ipt_init': net/sched/ipt.c:63: undefined reference to `__ipt_find_target_lock' net/built-in.o(.text+0x25873):net/sched/ipt.c:78: undefined reference to `__ipt_mutex_up' make: *** [.tmp_vmlinux1] Error 1 From tgraf@suug.ch Thu Jan 6 04:10:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 04:10:56 -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 j06CAfdG022932 for ; Thu, 6 Jan 2005 04:10:42 -0800 Received: from postel.suug.ch (unknown [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 D234882; Fri, 7 Jan 2005 01:10:11 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 6C4E41C0EA; Fri, 7 Jan 2005 01:10:53 +0100 (CET) Date: Fri, 7 Jan 2005 01:10:53 +0100 From: Thomas Graf To: Jeff Garzik Cc: "David S. Miller" , Netdev Subject: Re: BK-current build breakage Message-ID: <20050107001053.GY26856@postel.suug.ch> References: <41DDCF00.6070405@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DDCF00.6070405@pobox.com> X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13492 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 * Jeff Garzik <41DDCF00.6070405@pobox.com> 2005-01-06 18:51 > net/built-in.o(.text+0x25858): In function `tcf_ipt_init': > net/sched/ipt.c:63: undefined reference to `__ipt_find_target_lock' > net/built-in.o(.text+0x25873):net/sched/ipt.c:78: undefined reference to > `__ipt_mutex_up' > make: *** [.tmp_vmlinux1] Error 1 A fix for this is in the queue: On Wed, 2005-01-05 at 19:12 +0100, Thomas Graf wrote: > * Rusty Russell <1104896029.20582.72.camel@localhost.localdomain> 2005-01-05 14:33 > > Name: Clean up the kmod handling code in iptables.c > > Status: Tested under nfsim > > > > 4) Remove __ipt_mutex_up() and __ipt_find_target_lock() which weren't > > used (even in patch-o-matic AFAICT). > > Those are used by ipt action (net/sched/ipt.c). > > Readds __ipt_find_target_lock() and __ipt_mutex_up() and adapts ipt.c > to correctly use it. module must be given back properly upon cleanup. > removes the comments demanding for proper module refcnt since > find_target_lock() takes care of this now. OK, thanks. You missed a module_put in the check_entry-failed error path though. I looked harder at this, and I prefer this patch: Name: Restore net/sched/ipt.c After iptables Kmod Cleanup Status: Tested under nfsim Signed-off-by: Rusty Russell Thomas Graf points out that I broke net/sched/ipt.c when I removed __ipt_find_target_lock. In fact, those routines don't need to keep the lock held, so we can simplify them, and expose an interface (ipt_find_target) which does module loading correctly for net/sched/ipt.c. As Thomas points out, this also gets the module refcounts right. Index: linux-2.6.10-bk8-Netfilter/net/ipv4/netfilter/ip_tables.c =================================================================== --- linux-2.6.10-bk8-Netfilter.orig/net/ipv4/netfilter/ip_tables.c 2005-01-06 09:12:01.000000000 +1100 +++ linux-2.6.10-bk8-Netfilter/net/ipv4/netfilter/ip_tables.c 2005-01-06 09:49:10.000000000 +1100 @@ -430,62 +430,63 @@ return NULL; } -/* Find match, grabs mutex & ref. Returns ERR_PTR() on error. */ -static inline struct ipt_match *find_match_lock(const char *name, u8 revision) +/* Find match, grabs ref. Returns ERR_PTR() on error. */ +static inline struct ipt_match *find_match(const char *name, u8 revision) { struct ipt_match *m; - int found = 0; + int err = 0; if (down_interruptible(&ipt_mutex) != 0) return ERR_PTR(-EINTR); list_for_each_entry(m, &ipt_match, list) { if (strcmp(m->name, name) == 0) { - found = 1; if (m->revision == revision) { - if (!try_module_get(m->me)) - found = 0; - else + if (try_module_get(m->me)) { + up(&ipt_mutex); return m; - } + } + } else + err = -EPROTOTYPE; /* Found something. */ } } up(&ipt_mutex); - - /* Not found at all? NULL so try_then_request_module loads module. */ - if (!found) - return NULL; - - return ERR_PTR(-EPROTOTYPE); + return ERR_PTR(err); } -/* Find target, grabs mutex & ref. Returns ERR_PTR() on error. */ -static inline struct ipt_target *find_target_lock(const char *name, u8 revision) +/* Find target, grabs ref. Returns ERR_PTR() on error. */ +static inline struct ipt_target *find_target(const char *name, u8 revision) { struct ipt_target *t; - int found = 0; + int err = 0; if (down_interruptible(&ipt_mutex) != 0) return ERR_PTR(-EINTR); list_for_each_entry(t, &ipt_target, list) { if (strcmp(t->name, name) == 0) { - found = 1; if (t->revision == revision) { - if (!try_module_get(t->me)) - found = 0; - else + if (try_module_get(t->me)) { + up(&ipt_mutex); return t; - } + } + } else + err = -EPROTOTYPE; /* Found something. */ } } up(&ipt_mutex); + return ERR_PTR(err); +} - /* Not found at all? NULL so try_then_request_module loads module. */ - if (!found) - return NULL; +struct ipt_target *ipt_find_target(const char *name, u8 revision) +{ + struct ipt_target *target; - return ERR_PTR(-EPROTOTYPE); + target = try_then_request_module(find_target(name, revision), + "ipt_%s", name); + if (IS_ERR(target) || !target) + return NULL; + return target; } static int match_revfn(const char *name, u8 revision, int *bestp) @@ -708,15 +709,14 @@ { struct ipt_match *match; - match = try_then_request_module(find_match_lock(m->u.user.name, - m->u.user.revision), + match = try_then_request_module(find_match(m->u.user.name, + m->u.user.revision), "ipt_%s", m->u.user.name); if (IS_ERR(match) || !match) { duprintf("check_match: `%s' not found\n", m->u.user.name); return match ? PTR_ERR(match) : -ENOENT; } m->u.kernel.match = match; - up(&ipt_mutex); if (m->u.kernel.match->checkentry && !m->u.kernel.match->checkentry(name, ip, m->data, @@ -754,8 +754,8 @@ goto cleanup_matches; t = ipt_get_target(e); - target = try_then_request_module(find_target_lock(t->u.user.name, - t->u.user.revision), + target = try_then_request_module(find_target(t->u.user.name, + t->u.user.revision), "ipt_%s", t->u.user.name); if (IS_ERR(target) || !target) { duprintf("check_entry: `%s' not found\n", t->u.user.name); @@ -763,7 +763,6 @@ goto cleanup_matches; } t->u.kernel.target = target; - up(&ipt_mutex); if (t->u.kernel.target == &ipt_standard_target) { if (!standard_check(t, size)) { Index: linux-2.6.10-bk8-Netfilter/net/sched/ipt.c =================================================================== --- linux-2.6.10-bk8-Netfilter.orig/net/sched/ipt.c 2004-12-28 12:31:11.000000000 +1100 +++ linux-2.6.10-bk8-Netfilter/net/sched/ipt.c 2005-01-06 09:37:01.000000000 +1100 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -60,32 +61,23 @@ struct ipt_target *target; int ret = 0; struct ipt_entry_target *t = p->t; - target = __ipt_find_target_lock(t->u.user.name, &ret); + target = ipt_find_target(t->u.user.name, t->u.user.revision); if (!target) { printk("init_targ: Failed to find %s\n", t->u.user.name); return -1; } DPRINTK("init_targ: found %s\n", target->name); - /* we really need proper ref counting - seems to be only needed for modules?? Talk to laforge */ -/* if (target->me) - __MOD_INC_USE_COUNT(target->me); -*/ t->u.kernel.target = target; - __ipt_mutex_up(); - if (t->u.kernel.target->checkentry && !t->u.kernel.target->checkentry(p->tname, NULL, t->data, t->u.target_size - sizeof (*t), p->hook)) { -/* if (t->u.kernel.target->me) - __MOD_DEC_USE_COUNT(t->u.kernel.target->me); -*/ DPRINTK("ip_tables: check failed for `%s'.\n", t->u.kernel.target->name); + module_put(t->u.kernel.target->me); ret = -EINVAL; } @@ -235,8 +227,12 @@ { struct tcf_ipt *p; p = PRIV(a,ipt); - if (NULL != p) + if (NULL != p) { + struct ipt_entry_target *t = p->t; + if (t && t->u.kernel.target) + module_put(t->u.kernel.target->me); return tcf_hash_release(p, bind); + } return 0; } Index: linux-2.6.10-bk8-Netfilter/include/linux/netfilter_ipv4/ip_tables.h =================================================================== --- linux-2.6.10-bk8-Netfilter.orig/include/linux/netfilter_ipv4/ip_tables.h 2005-01-06 09:11:56.000000000 +1100 +++ linux-2.6.10-bk8-Netfilter/include/linux/netfilter_ipv4/ip_tables.h 2005-01-06 09:40:03.000000000 +1100 @@ -456,6 +456,9 @@ struct module *me; }; +/* net/sched/ipt.c: Gimme access to your targets! Gets target->me. */ +extern struct ipt_target *ipt_find_target(const char *name, u8 revision); + extern int ipt_register_table(struct ipt_table *table); extern void ipt_unregister_table(struct ipt_table *table); extern unsigned int ipt_do_table(struct sk_buff **pskb, -- A bad analogy is like a leaky screwdriver -- Richard Braakman From nacc@us.ibm.com Thu Jan 6 04:15:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Jan 2005 04:15:16 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j06CF7Rn023496 for ; Thu, 6 Jan 2005 04:15:08 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j070EtFJ646946 for ; Thu, 6 Jan 2005 19:14:55 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j070Et4J317306 for ; Thu, 6 Jan 2005 17:14:55 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j070EswC014459 for ; Thu, 6 Jan 2005 17:14:54 -0700 Received: from joust (DYN318000BLD.beaverton.ibm.com [9.47.17.70] (may be forged)) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j070Er4q014446; Thu, 6 Jan 2005 17:14:54 -0700 Received: by joust (Postfix, from userid 1000) id 17B634F966; Thu, 6 Jan 2005 16:14:53 -0800 (PST) Date: Thu, 6 Jan 2005 16:14:53 -0800 From: Nishanth Aravamudan To: kernel-janitors@lists.osdl.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH 5/28] net/cs89x0: replace schedule_timeout() with msleep() Message-ID: <20050107001453.GF3055@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Hi, Description: The existing wait is in TASK_INTERRUPTIBLE, but does not check for signals (especially problemtic for a 30 msec wait!) as being a cause for schedule_timeout()s return. Use msleep() instead, to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan --- 2.6.10-v/drivers/net/cs89x0.c 2004-12-24 13:35:24.000000000 -0800 +++ 2.6.10/drivers/net/cs89x0.c 2005-01-04 14:57:49.000000000 -0800 @@ -136,6 +136,7 @@ #include #include #include +#include #include #include @@ -909,8 +910,7 @@ void __init reset_chip(struct net_devic writereg(dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) | POWER_ON_RESET); /* wait 30 ms */ - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(30*HZ/1000); + msleep(30); #ifndef CONFIG_ARCH_IXDP2X01 if (lp->chip_type != CS8900) { From dsw@cse.unsw.edu.au Thu Jan 6 04:18:0