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 Dev