From akpm@osdl.org Thu Jul 1 00:29:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 00:29:20 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i617THgi028495 for ; Thu, 1 Jul 2004 00:29:17 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i617TBG29915 for ; Thu, 1 Jul 2004 00:29:11 -0700 Date: Thu, 1 Jul 2004 00:28:14 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 2991] New: vlan (8021q) is working bad with some sites and some ports Message-Id: <20040701002814.7f3bc516.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Thu, 1 Jul 2004 00:19:15 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 2991] New: vlan (8021q) is working bad with some sites and some ports http://bugme.osdl.org/show_bug.cgi?id=2991 Summary: vlan (8021q) is working bad with some sites and some ports Kernel Version: 2.6.7 Status: NEW Severity: high Owner: niv@us.ibm.com Submitter: roxwal@libero.it Distribution: Vlan (8021q) lost ipv4 packet Hardware Environment: HP tc3100 + switch 3com 3c16886A Software Environment: Mandrake 10 official + kernel 2.6.7-2mdk Problem Description: While using vlan (eth0.2) for connection to internet mostly sites don't work (ex: www.ziobudda.net bad, punto-informatico.it ok) The connection starts but no packet are recived. tcpdump -i eth0.2 -vv -X host www.ziobudda.net tcpdump: listening on eth0.2, link-type EN10MB (Ethernet), capture size 96 bytes 09:03:48.715078 IP (tos 0x0, ttl 64, id 51924, offset 0, flags [DF], length: 52) 81.112.63.189.32933 > 193.254.241.4.http: F [tcp sum ok] 2920000677:2920000677(0) ack 2170843880 win 5840 0x0000 4500 0034 cad4 4000 4006 2bbf 5170 3fbd E..4..@.@.+.Qp?. 0x0010 c1fe f104 80a5 0050 ae0b aca5 8164 72e8 .......P.....dr. 0x0020 8011 16d0 df2c 0000 0101 080a 001c ed47 .....,.........G 0x0030 102b 6f0c .+o. 09:03:48.723397 IP (tos 0x0, ttl 54, id 7661, offset 0, flags [DF], length: 52) 193.254.241.4.http > 81.112.63.189.32933: . [tcp sum ok] 2897:2897(0) ack 1 win 6432 0x0000 4500 0034 1ded 4000 3606 e2a6 c1fe f104 E..4..@.6....... 0x0010 5170 3fbd 0050 80a5 8164 7e38 ae0b aca6 Qp?..P...d~8.... 0x0020 8010 1920 c39b 0000 0101 080a 102b 7cfd .............+|. 0x0030 001c ed47 ...G 09:03:48.826211 IP (tos 0x0, ttl 64, id 20222, offset 0, flags [DF], length: 60) 81.112.63.189.32934 > 193.254.241.4.http: S [tcp sum ok] 2985141064:2985141064(0) win 5840 0x0000 4500 003c 4efe 4000 4006 a78d 5170 3fbd E.. 81.112.63.189.32934: S [tcp sum ok] 2195619523:2195619523 (0) ack 2985141065 win 5792 0x0000 4500 003c 0000 4000 3606 008c c1fe f104 E..<..@.6....... 0x0010 5170 3fbd 0050 80a6 82de 7ec3 b1ed a349 Qp?..P....~....I 0x0020 a012 16a0 9a50 0000 0204 05b4 0402 080a .....P.......... 0x0030 102b 7d08 001c edb6 0103 0300 .+}......... 09:03:48.834228 IP (tos 0x0, ttl 64, id 20223, offset 0, flags [DF], length: 52) 81.112.63.189.32934 > 193.254.241.4.http: . [tcp sum ok] 1:1(0) ack 1 win 5840 0x0000 4500 0034 4eff 4000 4006 a794 5170 3fbd E..4N.@.@...Qp?. 0x0010 c1fe f104 80a6 0050 b1ed a349 82de 7ec4 .......P...I..~. 0x0020 8010 16d0 c8dd 0000 0101 080a 001c edbe ................ 0x0030 102b 7d08 .+}. 09:03:48.836162 IP (tos 0x0, ttl 64, id 20224, offset 0, flags [DF], length: 451) 81.112.63.189.32934 > 193.254.241.4.http: P 1:400(399) ack 1 win 5840 0x0000 4500 01c3 4f00 4000 4006 a604 5170 3fbd E...O.@.@...Qp?. 0x0010 c1fe f104 80a6 0050 b1ed a349 82de 7ec4 .......P...I..~. 0x0020 8018 16d0 78ce 0000 0101 080a 001c edc0 ....x........... 0x0030 102b 7d08 4745 5420 2f20 4854 5450 2f31 .+}.GET./.HTTP/1 0x0040 2e31 0d0a 436f 6e6e 6563 7469 6f6e 3a20 .1..Connection:. 0x0050 4b65 Ke 09:03:48.846287 IP (tos 0x0, ttl 54, id 973, offset 0, flags [DF], length: 52) 193.254.241.4.http > 81.112.63.189.32934: . [tcp sum ok] 1:1(0) ack 400 win 6432 0x0000 4500 0034 03cd 4000 3606 fcc6 c1fe f104 E..4..@.6....... 0x0010 5170 3fbd 0050 80a6 82de 7ec4 b1ed a4d8 Qp?..P....~..... 0x0020 8010 1920 c4fb 0000 0101 080a 102b 7d09 .............+}. 0x0030 001c edc0 (no more) the ping works and the telnet towards others ports (but 80) work if I use une other net card for direct connettion (eth1) internet connections works perfectly Steps to reproduce: hdsl + router cisco + 3com switch layer 3 + vlan eth0 local lan eth0.2 internet links www.ziobudda.net tks W:-} ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From laforge@netfilter.org Thu Jul 1 02:10:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 02:10:57 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i619Aqgi006577 for ; Thu, 1 Jul 2004 02:10:53 -0700 Received: from dsl-082-083-225-178.arcor-ip.net ([82.83.225.178] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1Bfxak-0006Lt-Go; Thu, 01 Jul 2004 11:10:50 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1Bfxai-0000u5-II; Thu, 01 Jul 2004 11:10:48 +0200 Date: Thu, 1 Jul 2004 11:10:48 +0200 From: Harald Welte To: "David S. Miller" Cc: James Morris , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, arjanv@redhat.com, kuznet@ms2.inr.ac.ru Subject: Re: Remote DoS vulnerability in Linux kernel 2.6.x (fwd) Message-ID: <20040701091048.GR1410@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , "David S. Miller" , James Morris , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, arjanv@redhat.com, kuznet@ms2.inr.ac.ru References: <20040630144230.1d52864b.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWJxWxNlJUNgDlXi" Content-Disposition: inline In-Reply-To: <20040630144230.1d52864b.davem@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 6488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --pWJxWxNlJUNgDlXi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 30, 2004 at 02:42:30PM -0700, David S. Miller wrote: =20 > This bug only came up because up the huge change Rusty and Harald did > to make these modules not access the SKB header data directly, and > instead to use local on-stack copies and skb_copy_bits(). A change we had to make in order not to assume fully linearized packet including the tcp header. I suppose the trivial fix has already been pushed upstream... Very unfortunate that vendors weren't informed in advance :( --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --pWJxWxNlJUNgDlXi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA49UYXaXGVTD0i/8RAq4sAJ9GVk5gzRKJAiGgtIWalh/ydPTYtACeP6gt vNB5hX9KKHHjwltrbeQalVo= =skaj -----END PGP SIGNATURE----- --pWJxWxNlJUNgDlXi-- From herbert@gondor.apana.org.au Thu Jul 1 04:04:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 04:04:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61B4cgi013648 for ; Thu, 1 Jul 2004 04:04:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BfzMi-0002Jv-00; Thu, 01 Jul 2004 21:04:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BfzMY-0002oO-00; Thu, 01 Jul 2004 21:04:18 +1000 Date: Thu, 1 Jul 2004 21:04:18 +1000 To: Jeff Garzik , netdev@oss.sgi.com Subject: Resend: [NETDRV] Fix successive calls to spin_lock_irqsave in sk98lin Message-ID: <20040701110418.GA10797@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff: This patch fixes the few places in sk98lin where it calls spin_lock_saveirq on the same flags variable thus causing interrupts to be disabled upon leaving the driver. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: drivers/net/sk98lin/skge.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/net/sk98lin/skge.c,v retrieving revision 1.1.1.17 diff -u -r1.1.1.17 skge.c --- drivers/net/sk98lin/skge.c 10 May 2004 09:47:55 -0000 1.1.1.17 +++ drivers/net/sk98lin/skge.c 22 Jun 2004 10:45:23 -0000 @@ -3093,8 +3093,7 @@ SkEventDispatcher(pAC, pAC->IoBase); for (i=0; iGIni.GIMacsFound; i++) { - spin_lock_irqsave( - &pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock); netif_stop_queue(pAC->dev[i]); } @@ -4773,12 +4772,10 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); SkGeStopPort(pAC, IoC, FromPort, SK_STOP_ALL, SK_SOFT_RST); SkGeStopPort(pAC, IoC, ToPort, SK_STOP_ALL, SK_SOFT_RST); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4791,8 +4788,7 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); pAC->ActivePort = ToPort; #if 0 SetQueueSizes(pAC); @@ -4807,8 +4803,7 @@ pAC, pAC->ActivePort, DualNet)) { - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4834,8 +4829,7 @@ SkGePollTxD(pAC, IoC, ToPort, SK_TRUE); ClearAndStartRx(pAC, FromPort); ClearAndStartRx(pAC, ToPort); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); --Nq2Wo0NMKNjxTN9z-- From herbert@gondor.apana.org.au Thu Jul 1 04:19:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 04:19:51 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61BJUgi017548 for ; Thu, 1 Jul 2004 04:19:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bfzb7-0002P6-00; Thu, 01 Jul 2004 21:19:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bfzb0-0002td-00; Thu, 01 Jul 2004 21:19:14 +1000 Date: Thu, 1 Jul 2004 21:19:14 +1000 To: Jeff Garzik , netdev@oss.sgi.com Subject: Resend: [NETDRV] Merge register_netdev calls Message-ID: <20040701111914.GA11120@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 11, 2004 at 12:08:55PM +1000, herbert wrote: > > In fact it's really making these ISA/MCA probe() functions more > like the ones we have for PCI. To illustrate this, let's take the first driver touched by 4/x. In 3c503, the function init_module() essentially does for each ioaddr if (do_el2_probe(ioaddr) == 0) return 0 And do_el2_probe() just calls el2_probe1() which is similar to your average PCI probe function except that the first thing it does is to make sure that the device exists at ioaddr. This is not that different from PCI where it would look like for each PCI device matching the vendor/product numbers if (do_el2_probe(device) == 0) return 0 Now before my patch, register_netdev was being called just after do_el2_probe() returns. My patch simply moves it to the end of el2_probe1() which is exactly what would happen if this were a PCI driver. I've rediffed it against your net-drivers-2.6 tree. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/3c503.c 1.20 vs edited ===== --- 1.20/drivers/net/3c503.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/3c503.c 2004-07-01 21:16:27 +10:00 @@ -162,12 +162,7 @@ err = do_el2_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -343,6 +338,10 @@ dev->poll_controller = ei_poll; #endif + retval = register_netdev(dev); + if (retval) + goto out1; + if (dev->mem_start) printk("%s: %s - %dkB RAM, 8kB shared mem window at %#6lx-%#6lx.\n", dev->name, ei_status.name, (wordlength+1)<<3, @@ -702,11 +701,8 @@ dev->base_addr = io[this_dev]; dev->mem_end = xcvr[this_dev]; /* low 4bits = xcvr sel. */ if (do_el2_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_el2[found++] = dev; - continue; - } - cleanup_card(dev); + dev_el2[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "3c503.c: No 3c503 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/3c515.c 1.29 vs edited ===== --- 1.29/drivers/net/3c515.c 2004-03-30 20:17:59 +10:00 +++ edited/drivers/net/3c515.c 2004-07-01 21:16:28 +10:00 @@ -373,7 +373,7 @@ #endif /* __ISAPNP__ */ static struct net_device *corkscrew_scan(int unit); -static void corkscrew_setup(struct net_device *dev, int ioaddr, +static int corkscrew_setup(struct net_device *dev, int ioaddr, struct pnp_dev *idev, int card_number); static int corkscrew_open(struct net_device *dev); static void corkscrew_timer(unsigned long arg); @@ -537,10 +537,9 @@ printk(KERN_INFO "3c515 Resource configuration register %#4.4x, DCR %4.4x.\n", inl(ioaddr + 0x2002), inw(ioaddr + 0x2000)); /* irq = inw(ioaddr + 0x2002) & 15; */ /* Use the irq from isapnp */ - corkscrew_setup(dev, ioaddr, idev, cards_found++); SET_NETDEV_DEV(dev, &idev->dev); pnp_cards++; - err = register_netdev(dev); + err = corkscrew_setup(dev, ioaddr, idev, cards_found++); if (!err) return dev; cleanup_card(dev); @@ -556,8 +555,7 @@ printk(KERN_INFO "3c515 Resource configuration register %#4.4x, DCR %4.4x.\n", inl(ioaddr + 0x2002), inw(ioaddr + 0x2000)); - corkscrew_setup(dev, ioaddr, NULL, cards_found++); - err = register_netdev(dev); + err = corkscrew_setup(dev, ioaddr, NULL, cards_found++); if (!err) return dev; cleanup_card(dev); @@ -566,7 +564,7 @@ return NULL; } -static void corkscrew_setup(struct net_device *dev, int ioaddr, +static int corkscrew_setup(struct net_device *dev, int ioaddr, struct pnp_dev *idev, int card_number) { struct corkscrew_private *vp = (struct corkscrew_private *) dev->priv; @@ -689,6 +687,8 @@ dev->get_stats = &corkscrew_get_stats; dev->set_multicast_list = &set_rx_mode; dev->ethtool_ops = &netdev_ethtool_ops; + + return register_netdev(dev); } ===== drivers/net/3c523.c 1.16 vs edited ===== --- 1.16/drivers/net/3c523.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/3c523.c 2004-07-01 21:16:28 +10:00 @@ -572,6 +572,10 @@ dev->flags&=~IFF_MULTICAST; /* Multicast doesn't work */ #endif + retval = register_netdev(dev); + if (retval) + goto err_out; + return 0; err_out: mca_set_adapter_procfn(slot, NULL, NULL); @@ -600,12 +604,7 @@ err = do_elmc_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -1288,12 +1287,9 @@ dev->irq=irq[this_dev]; dev->base_addr=io[this_dev]; if (do_elmc_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_elmc[this_dev] = dev; - found++; - continue; - } - cleanup_card(dev); + dev_elmc[this_dev] = dev; + found++; + continue; } free_netdev(dev); if (io[this_dev]==0) ===== drivers/net/ac3200.c 1.19 vs edited ===== --- 1.19/drivers/net/ac3200.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ac3200.c 2004-07-01 21:16:29 +10:00 @@ -147,12 +147,7 @@ err = do_ac3200_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -284,7 +279,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + retval = register_netdev(dev); + if (retval) + goto out2; return 0; +out2: + if (ei_status.reg0) + iounmap((void *)dev->mem_start); out1: free_irq(dev->irq, dev); out: @@ -402,11 +404,8 @@ dev->base_addr = io[this_dev]; dev->mem_start = mem[this_dev]; /* Currently ignored by driver */ if (do_ac3200_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ac32[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ac32[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "ac3200.c: No ac3200 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/cs89x0.c 1.24 vs edited ===== --- 1.24/drivers/net/cs89x0.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/cs89x0.c 2004-07-01 21:16:29 +10:00 @@ -307,13 +307,7 @@ } if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - outw(PP_ChipID, dev->base_addr + ADD_PORT); - release_region(dev->base_addr, NETCARD_IO_EXTENT); out: free_netdev(dev); printk(KERN_WARNING "cs89x0: no cs8900 or cs8920 detected. Be sure to disable PnP with SETUP\n"); @@ -718,7 +712,13 @@ printk("\n"); if (net_debug) printk("cs89x0_probe1() successful\n"); + + retval = register_netdev(dev); + if (retval) + goto out3; return 0; +out3: + outw(PP_ChipID, dev->base_addr + ADD_PORT); out2: release_region(ioaddr & ~3, NETCARD_IO_EXTENT); out1: @@ -1806,13 +1806,6 @@ if (ret) goto out; - if (register_netdev(dev) != 0) { - printk(KERN_ERR "cs89x0.c: No card found at 0x%x\n", io); - ret = -ENXIO; - outw(PP_ChipID, dev->base_addr + ADD_PORT); - release_region(dev->base_addr, NETCARD_IO_EXTENT); - goto out; - } dev_cs89x0 = dev; return 0; out: ===== drivers/net/e2100.c 1.18 vs edited ===== --- 1.18/drivers/net/e2100.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/e2100.c 2004-07-01 21:16:29 +10:00 @@ -161,12 +161,7 @@ err = do_e2100_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -278,6 +273,9 @@ #endif NS8390_init(dev, 0); + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, E21_IO_EXTENT); @@ -445,11 +443,8 @@ dev->mem_start = mem[this_dev]; dev->mem_end = xcvr[this_dev]; /* low 4bits = xcvr sel. */ if (do_e2100_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_e21[found++] = dev; - continue; - } - cleanup_card(dev); + dev_e21[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "e2100.c: No E2100 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/eepro.c 1.25 vs edited ===== --- 1.25/drivers/net/eepro.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/eepro.c 2004-07-01 21:16:29 +10:00 @@ -596,12 +596,7 @@ err = do_eepro_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - release_region(dev->base_addr, EEPRO_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -747,6 +742,7 @@ struct eepro_local *lp; enum iftype { AUI=0, BNC=1, TPE=2 }; int ioaddr = dev->base_addr; + int err; /* Grab the region so we can find another board if autoIRQ fails. */ if (!request_region(ioaddr, EEPRO_IO_EXTENT, DRV_NAME)) { @@ -856,10 +852,16 @@ /* reset 82595 */ eepro_reset(ioaddr); + + err = register_netdev(dev); + if (err) + goto err; return 0; exit: + err = -ENODEV; +err: release_region(dev->base_addr, EEPRO_IO_EXTENT); - return -ENODEV; + return err; } /* Open/initialize the board. This is called (in the current kernel) @@ -1756,11 +1758,8 @@ dev->irq = irq[i]; if (do_eepro_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_eepro[n_eepro++] = dev; - continue; - } - release_region(dev->base_addr, EEPRO_IO_EXTENT); + dev_eepro[n_eepro++] = dev; + continue; } free_netdev(dev); break; ===== drivers/net/eexpress.c 1.18 vs edited ===== --- 1.18/drivers/net/eexpress.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/eexpress.c 2004-07-01 21:16:30 +10:00 @@ -436,11 +436,8 @@ netdev_boot_setup_check(dev); err = do_express_probe(dev); - if (!err) { - err = register_netdev(dev); - if (!err) - return dev; - } + if (!err) + return dev; free_netdev(dev); return ERR_PTR(err); } @@ -1205,7 +1202,8 @@ dev->set_multicast_list = &eexp_set_multicast; dev->tx_timeout = eexp_timeout; dev->watchdog_timeo = 2*HZ; - return 0; + + return register_netdev(dev); } /* @@ -1716,7 +1714,7 @@ break; printk(KERN_NOTICE "eexpress.c: Module autoprobe not recommended, give io=xx.\n"); } - if (do_express_probe(dev) == 0 && register_netdev(dev) == 0) { + if (do_express_probe(dev) == 0) { dev_eexp[this_dev] = dev; found++; continue; ===== drivers/net/es3210.c 1.13 vs edited ===== --- 1.13/drivers/net/es3210.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/es3210.c 2004-07-01 21:16:30 +10:00 @@ -176,12 +176,7 @@ err = do_es_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -304,6 +299,10 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + retval = register_netdev(dev); + if (retval) + goto out1; return 0; out1: free_irq(dev->irq, dev); @@ -439,11 +438,8 @@ dev->base_addr = io[this_dev]; dev->mem_start = mem[this_dev]; if (do_es_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_es3210[found++] = dev; - continue; - } - cleanup_card(dev); + dev_es3210[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "es3210.c: No es3210 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/hp.c 1.14 vs edited ===== --- 1.14/drivers/net/hp.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/hp.c 2004-07-01 21:16:30 +10:00 @@ -123,12 +123,7 @@ err = do_hp_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -227,7 +222,12 @@ ei_status.block_output = &hp_block_output; hp_init_card(dev); + retval = register_netdev(dev); + if (retval) + goto out1; return 0; +out1: + free_irq(dev->irq, dev); out: release_region(ioaddr, HP_IO_EXTENT); return retval; @@ -432,11 +432,8 @@ dev->irq = irq[this_dev]; dev->base_addr = io[this_dev]; if (do_hp_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_hp[found++] = dev; - continue; - } - cleanup_card(dev); + dev_hp[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "hp.c: No HP card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/eth16i.c 1.19 vs edited ===== --- 1.19/drivers/net/eth16i.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/eth16i.c 2004-07-01 21:16:30 +10:00 @@ -473,13 +473,7 @@ err = do_eth16i_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - free_irq(dev->irq, dev); - release_region(dev->base_addr, ETH16I_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -569,7 +563,13 @@ dev->tx_timeout = eth16i_timeout; dev->watchdog_timeo = TX_TIMEOUT; spin_lock_init(&lp->lock); + + retval = register_netdev(dev); + if (retval) + goto out1; return 0; +out1: + free_irq(dev->irq, dev); out: release_region(ioaddr, ETH16I_IO_EXTENT); return retval; @@ -1462,12 +1462,8 @@ } if (do_eth16i_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_eth16i[found++] = dev; - continue; - } - free_irq(dev->irq, dev); - release_region(dev->base_addr, ETH16I_IO_EXTENT); + dev_eth16i[found++] = dev; + continue; } printk(KERN_WARNING "eth16i.c No Eth16i card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/hp-plus.c 1.16 vs edited ===== --- 1.16/drivers/net/hp-plus.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/hp-plus.c 2004-07-01 21:16:30 +10:00 @@ -159,12 +159,7 @@ err = do_hpp_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -271,6 +266,9 @@ /* Leave the 8390 and HP chip reset. */ outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION); + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, HP_IO_EXTENT); @@ -463,11 +461,8 @@ dev->irq = irq[this_dev]; dev->base_addr = io[this_dev]; if (do_hpp_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_hpp[found++] = dev; - continue; - } - cleanup_card(dev); + dev_hpp[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "hp-plus.c: No HP-Plus card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/hp100.c 1.28 vs edited ===== --- 1.28/drivers/net/hp100.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/hp100.c 2004-07-01 21:16:31 +10:00 @@ -411,12 +411,7 @@ if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; - out1: - release_region(dev->base_addr, HP100_REGION_SIZE); out: free_netdev(dev); return ERR_PTR(err); @@ -770,11 +765,22 @@ printk("Warning! Link down.\n"); } + err = register_netdev(dev); + if (err) + goto out3; + return 0; +out3: + if (local_mode == 1) + pci_free_consistent(lp->pci_dev, MAX_RINGSIZE + 0x0f, + lp->page_vaddr_algn, + virt_to_whatever(dev, lp->page_vaddr_algn)); + if (mem_ptr_virt) + iounmap(mem_ptr_virt); out2: release_region(ioaddr, HP100_REGION_SIZE); out1: - return -ENODEV; + return err; } /* This procedure puts the card into a stable init state */ @@ -2868,18 +2874,12 @@ if (err) goto out1; - err = register_netdev(dev); - if (err) - goto out2; - #ifdef HP100_DEBUG printk("hp100: %s: EISA adapter found at 0x%x\n", dev->name, dev->base_addr); #endif gendev->driver_data = dev; return 0; - out2: - release_region(dev->base_addr, HP100_REGION_SIZE); out1: free_netdev(dev); return err; @@ -2938,17 +2938,12 @@ err = hp100_probe1(dev, ioaddr, HP100_BUS_PCI, pdev); if (err) goto out1; - err = register_netdev(dev); - if (err) - goto out2; #ifdef HP100_DEBUG printk("hp100: %s: PCI adapter found at 0x%x\n", dev->name, ioaddr); #endif pci_set_drvdata(pdev, dev); return 0; - out2: - release_region(dev->base_addr, HP100_REGION_SIZE); out1: free_netdev(dev); return err; @@ -3016,15 +3011,9 @@ SET_MODULE_OWNER(dev); err = hp100_isa_probe(dev, hp100_port[i]); - if (!err) { - err = register_netdev(dev); - if (!err) - hp100_devlist[cards++] = dev; - else - release_region(dev->base_addr, HP100_REGION_SIZE); - } - - if (err) + if (!err) + hp100_devlist[cards++] = dev; + else free_netdev(dev); } ===== drivers/net/isa-skeleton.c 1.13 vs edited ===== --- 1.13/drivers/net/isa-skeleton.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/isa-skeleton.c 2004-07-01 21:16:31 +10:00 @@ -176,12 +176,7 @@ err = do_netcard_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -316,7 +311,15 @@ dev->tx_timeout = &net_tx_timeout; dev->watchdog_timeo = MY_TX_TIMEOUT; + + err = register_netdev(dev); + if (err) + goto out2; return 0; +out2: +#ifdef jumpered_dma + free_dma(dev->dma); +#endif out1: #ifdef jumpered_interrupts free_irq(dev->irq, dev); @@ -691,11 +694,8 @@ dev->dma = dma; dev->mem_start = mem; if (do_netcard_probe(dev) == 0) { - if (register_netdev(dev) == 0) - this_device = dev; - return 0; - } - cleanup_card(dev); + this_device = dev; + return 0; } free_netdev(dev); return -ENXIO; ===== drivers/net/lance.c 1.22 vs edited ===== --- 1.22/drivers/net/lance.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/lance.c 2004-07-01 21:16:31 +10:00 @@ -355,11 +355,8 @@ dev->base_addr = io[this_dev]; dev->dma = dma[this_dev]; if (do_lance_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_lance[found++] = dev; - continue; - } - cleanup_card(dev); + dev_lance[found++] = dev; + continue; } free_netdev(dev); break; @@ -447,12 +444,7 @@ err = do_lance_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -723,6 +715,9 @@ dev->tx_timeout = lance_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; + err = register_netdev(dev); + if (err) + goto out_dma; return 0; out_dma: if (dev->dma != 4) ===== drivers/net/ne.c 1.22 vs edited ===== --- 1.22/drivers/net/ne.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ne.c 2004-07-01 21:16:32 +10:00 @@ -220,12 +220,7 @@ err = do_ne_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -506,8 +501,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + ret = register_netdev(dev); + if (ret) + goto out_irq; return 0; +out_irq: + free_irq(dev->irq, dev); err_out: release_region(ioaddr, NE_IO_EXTENT); return ret; @@ -798,11 +799,8 @@ dev->mem_end = bad[this_dev]; dev->base_addr = io[this_dev]; if (do_ne_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ne[found++] = dev; + continue; } free_netdev(dev); if (found) ===== drivers/net/lne390.c 1.14 vs edited ===== --- 1.14/drivers/net/lne390.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/lne390.c 2004-07-01 21:16:31 +10:00 @@ -168,12 +168,7 @@ err = do_lne390_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -307,7 +302,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + ret = register_netdev(dev); + if (ret) + goto unmap; return 0; +unmap: + if (ei_status.reg0) + iounmap((void *)dev->mem_start); cleanup: free_irq(dev->irq, dev); return ret; @@ -436,11 +438,8 @@ dev->base_addr = io[this_dev]; dev->mem_start = mem[this_dev]; if (do_lne390_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_lne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_lne[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "lne390.c: No LNE390 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/ne2.c 1.16 vs edited ===== --- 1.16/drivers/net/ne2.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ne2.c 2004-07-01 21:16:32 +10:00 @@ -301,12 +301,7 @@ err = do_ne2_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -517,7 +512,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + retval = register_netdev(dev); + if (retval) + goto out1; return 0; +out1: + mca_set_adapter_procfn( ei_status.priv, NULL, NULL); + free_irq(dev->irq, dev); out: release_region(base_addr, NE_IO_EXTENT); return retval; @@ -800,11 +802,8 @@ dev->mem_end = bad[this_dev]; dev->base_addr = io[this_dev]; if (do_ne2_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ne[found++] = dev; + continue; } free_netdev(dev); break; ===== drivers/net/ne-h8300.c 1.4 vs edited ===== --- 1.4/drivers/net/ne-h8300.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ne-h8300.c 2004-07-01 21:16:32 +10:00 @@ -180,12 +180,7 @@ err = do_ne_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -325,8 +320,13 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); - return 0; + ret = register_netdev(dev); + if (ret) + goto out_irq; + return 0; +out_irq: + free_irq(dev->irq, dev); err_out: release_region(ioaddr, NE_IO_EXTENT); return ret; @@ -633,11 +633,8 @@ err = init_reg_offset(dev, dev->base_addr); if (!err) { if (do_ne_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ne[found++] = dev; + continue; } } free_netdev(dev); ===== drivers/net/smc-ultra.c 1.22 vs edited ===== --- 1.22/drivers/net/smc-ultra.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/smc-ultra.c 2004-07-01 21:16:32 +10:00 @@ -195,12 +195,7 @@ err = do_ultra_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -321,6 +316,9 @@ #endif NS8390_init(dev, 0); + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, ULTRA_IO_EXTENT); @@ -579,11 +577,8 @@ dev->irq = irq[this_dev]; dev->base_addr = io[this_dev]; if (do_ultra_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ultra[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ultra[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "smc-ultra.c: No SMC Ultra card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/wd.c 1.19 vs edited ===== --- 1.19/drivers/net/wd.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/wd.c 2004-07-01 21:16:32 +10:00 @@ -148,12 +148,7 @@ err = do_wd_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -163,6 +158,7 @@ static int __init wd_probe1(struct net_device *dev, int ioaddr) { int i; + int err; int checksum = 0; int ancient = 0; /* An old card without config registers. */ int word16 = 0; /* 0 = 8 bit, 1 = 16 bit */ @@ -349,7 +345,10 @@ outb(inb(ioaddr+4)|0x80, ioaddr+4); #endif - return 0; + err = register_netdev(dev); + if (err) + free_irq(dev->irq, dev); + return err; } static int @@ -519,11 +518,8 @@ dev->mem_start = mem[this_dev]; dev->mem_end = mem_end[this_dev]; if (do_wd_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_wd[found++] = dev; - continue; - } - cleanup_card(dev); + dev_wd[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "wd.c: No wd80x3 card found (i/o = 0x%x).\n", io[this_dev]); --sdtB3X0nJg68CQEu-- From herbert@gondor.apana.org.au Thu Jul 1 05:33:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 05:34:03 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61CXsgi019270 for ; Thu, 1 Jul 2004 05:33:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bg0l9-0002s4-00; Thu, 01 Jul 2004 22:33:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bg0l6-00032C-00; Thu, 01 Jul 2004 22:33:44 +1000 Date: Thu, 1 Jul 2004 22:33:44 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [ESP4] Merge NAT-T code in esp_output Message-ID: <20040701123344.GA11639@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is another step on the way to distilling the tunnel mode encap code between AH/ESP/IPCOMP. This patch removes the needless duplciation of NAT-T code between transport mode and tunnel mode ESP4. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/esp4.c 1.48 vs edited ===== --- 1.48/net/ipv4/esp4.c 2004-07-01 19:11:29 +10:00 +++ edited/net/ipv4/esp4.c 2004-07-01 22:33:16 +10:00 @@ -28,9 +28,6 @@ struct crypto_tfm *tfm; struct esp_data *esp; struct sk_buff *trailer; - struct udphdr *uh = NULL; - u32 *udpdata32; - struct xfrm_encap_tmpl *encap = NULL; int blksize; int clen; int alen; @@ -88,30 +85,10 @@ *(u8*)(trailer->tail + clen-(*pskb)->len - 2) = (clen - (*pskb)->len)-2; pskb_put(*pskb, trailer, clen - (*pskb)->len); - encap = x->encap; - iph = (*pskb)->nh.iph; if (x->props.mode) { top_iph = (struct iphdr*)skb_push(*pskb, x->props.header_len); esph = (struct ip_esp_hdr*)(top_iph+1); - if (encap) { - switch (encap->encap_type) { - default: - case UDP_ENCAP_ESPINUDP: - uh = (struct udphdr*) esph; - esph = (struct ip_esp_hdr*)(uh+1); - top_iph->protocol = IPPROTO_UDP; - break; - case UDP_ENCAP_ESPINUDP_NON_IKE: - uh = (struct udphdr*) esph; - udpdata32 = (u32*)(uh+1); - udpdata32[0] = udpdata32[1] = 0; - esph = (struct ip_esp_hdr*)(udpdata32+2); - top_iph->protocol = IPPROTO_UDP; - break; - } - } else - top_iph->protocol = IPPROTO_ESP; *(u8*)(trailer->tail - 1) = IPPROTO_IPIP; top_iph->ihl = 5; top_iph->version = 4; @@ -131,24 +108,6 @@ esph = (struct ip_esp_hdr*)skb_push(*pskb, x->props.header_len); top_iph = (struct iphdr*)skb_push(*pskb, iph->ihl*4); memcpy(top_iph, &tmp_iph, iph->ihl*4); - if (encap) { - switch (encap->encap_type) { - default: - case UDP_ENCAP_ESPINUDP: - uh = (struct udphdr*) esph; - esph = (struct ip_esp_hdr*)(uh+1); - top_iph->protocol = IPPROTO_UDP; - break; - case UDP_ENCAP_ESPINUDP_NON_IKE: - uh = (struct udphdr*) esph; - udpdata32 = (u32*)(uh+1); - udpdata32[0] = udpdata32[1] = 0; - esph = (struct ip_esp_hdr*)(udpdata32+2); - top_iph->protocol = IPPROTO_UDP; - break; - } - } else - top_iph->protocol = IPPROTO_ESP; iph = &tmp_iph.iph; top_iph->tot_len = htons((*pskb)->len + alen); top_iph->check = 0; @@ -157,12 +116,32 @@ } /* this is non-NULL only with UDP Encapsulation */ - if (encap && uh) { + if (x->encap) { + struct xfrm_encap_tmpl *encap = x->encap; + struct udphdr *uh; + u32 *udpdata32; + + uh = (struct udphdr *)esph; uh->source = encap->encap_sport; uh->dest = encap->encap_dport; uh->len = htons((*pskb)->len + alen - sizeof(struct iphdr)); uh->check = 0; - } + + switch (encap->encap_type) { + default: + case UDP_ENCAP_ESPINUDP: + esph = (struct ip_esp_hdr *)(uh + 1); + break; + case UDP_ENCAP_ESPINUDP_NON_IKE: + udpdata32 = (u32 *)(uh + 1); + udpdata32[0] = udpdata32[1] = 0; + esph = (struct ip_esp_hdr *)(udpdata32 + 2); + break; + } + + top_iph->protocol = IPPROTO_UDP; + } else + top_iph->protocol = IPPROTO_ESP; esph->spi = x->id.spi; esph->seq_no = htonl(++x->replay.oseq); --jI8keyz6grp/JLjh-- From michael.kerrisk@gmx.net Thu Jul 1 05:47:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 05:47:27 -0700 (PDT) Received: from mail.jambit.com (mail.jambit.com [62.245.207.83]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61ClNgi019843 for ; Thu, 1 Jul 2004 05:47:24 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.jambit.com (Postfix) with ESMTP id EF61C4A44F; Thu, 1 Jul 2004 14:47:16 +0200 (CEST) Received: from mail.jambit.com ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04463-03; Thu, 1 Jul 2004 14:47:07 +0200 (CEST) Received: from wakatipu (proxy.jambit.com [62.245.207.82]) by mail.jambit.com (Postfix) with ESMTP id 99B674A42D; Thu, 1 Jul 2004 14:47:07 +0200 (CEST) From: "Michael Kerrisk" To: netdev@oss.sgi.com Date: Thu, 01 Jul 2004 14:47:13 +0200 MIME-Version: 1.0 Subject: TCP_CORK 200ms maximum cork time -- expected behaviour? Cc: michael.kerrisk@gmx.net Message-ID: <40E423F1.31890.6CC4104@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (4.21a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new at jambit.com X-archive-position: 6492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michael.kerrisk@gmx.net Precedence: bulk X-list: netdev Gidday, The TCP_CORK socket option allows us to perform multiple write()s (or send()s or sendfile()s) while delaying the transmission of an outgoing TCP segment until the option is disabled (or a segment MSS is filled or the socket is closed). All is fine and good, but there's one point I'm puzzled about: even when TCP_CORK is set, buffered data will still be transmitted after a 200 millisecond delay (the delay counts from the time that the first corked byte was written), even if TCP_CORK is still set. So, I'm wondering: 1. Is this intended behaviour, or simply an outgrowth of the combined implementations of TCP_CORK and TCP_NAGLE_OFF? 2. If it's intended behaviour, what is the rationale for the ceiling time on corking? Cheers, Michael PS I first observed this behaviour quite some time back, but I've verified that it is still current (2.4.26 and 2.6.7 kernels). (In passing: of course, similar behaviour occurs with MSG_MORE on TCP sockets.) From shemminger@osdl.org Thu Jul 1 11:33:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 11:33:38 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61IXUgi002463 for ; Thu, 1 Jul 2004 11:33:30 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i61IXCG11856; Thu, 1 Jul 2004 11:33:12 -0700 Date: Thu, 1 Jul 2004 11:33:12 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch updates the network emulation packet scheduler. * name changed from delay to netem since it does more than just delay * Catalin's merged code to do packet reordering * uses a socket queue's directly rather than layering on qdisc(fifo) because this is used in performance tests. * adds placeholder in API for future enhancements (rate and duplicate). Signed-off-by: Stephen Hemminger diff -urNp -X dontdiff linux-2.6/include/linux/pkt_sched.h sched-2.6/include/linux/pkt_sched.h --- linux-2.6/include/linux/pkt_sched.h 2004-06-24 08:52:58.000000000 -0700 +++ sched-2.6/include/linux/pkt_sched.h 2004-07-01 03:53:31.185482832 -0700 @@ -439,11 +439,14 @@ enum { #define TCA_ATM_MAX TCA_ATM_STATE -/* Delay section */ -struct tc_dly_qopt +/* Network emulator */ +struct tc_netem_qopt { - __u32 latency; - __u32 limit; - __u32 loss; + __u32 latency; /* added delay (us) */ + __u32 limit; /* fifo limit (packets) */ + __u32 loss; /* random packet loss (0=none ~0=100%) */ + __u32 gap; /* re-ordering gap (0 for delay all) */ + __u32 duplicate; /* random packet dup (0=none ~0=100%) */ + __u32 rate; /* maximum transmit rate (bytes/sec) */ }; #endif diff -urNp -X dontdiff linux-2.6/net/sched/Kconfig sched-2.6/net/sched/Kconfig --- linux-2.6/net/sched/Kconfig 2004-06-25 09:41:00.000000000 -0700 +++ sched-2.6/net/sched/Kconfig 2004-06-28 09:17:19.000000000 -0700 @@ -164,12 +164,12 @@ config NET_SCH_DSMARK To compile this code as a module, choose M here: the module will be called sch_dsmark. -config NET_SCH_DELAY - tristate "Delay simulator" +config NET_SCH_NETEM + tristate "Network emulator" depends on NET_SCHED help - Say Y if you want to delay packets by a fixed amount of - time. This is often useful to simulate network delay when + Say Y if you want to emulate network delay, loss, and packet + re-ordering. This is often useful to simulate networks when testing applications or protocols. To compile this driver as a module, choose M here: the module diff -urNp -X dontdiff linux-2.6/net/sched/Makefile sched-2.6/net/sched/Makefile --- linux-2.6/net/sched/Makefile 2004-06-24 08:52:58.000000000 -0700 +++ sched-2.6/net/sched/Makefile 2004-06-28 09:17:49.000000000 -0700 @@ -24,7 +24,7 @@ obj-$(CONFIG_NET_SCH_TBF) += sch_tbf.o obj-$(CONFIG_NET_SCH_TEQL) += sch_teql.o obj-$(CONFIG_NET_SCH_PRIO) += sch_prio.o obj-$(CONFIG_NET_SCH_ATM) += sch_atm.o -obj-$(CONFIG_NET_SCH_DELAY) += sch_delay.o +obj-$(CONFIG_NET_SCH_NETEM) += sch_netem.o obj-$(CONFIG_NET_CLS_U32) += cls_u32.o obj-$(CONFIG_NET_CLS_ROUTE4) += cls_route.o obj-$(CONFIG_NET_CLS_FW) += cls_fw.o diff -urNp -X dontdiff linux-2.6/net/sched/sch_delay.c sched-2.6/net/sched/sch_delay.c --- linux-2.6/net/sched/sch_delay.c 2004-06-21 09:23:15.000000000 -0700 +++ sched-2.6/net/sched/sch_delay.c 1969-12-31 16:00:00.000000000 -0800 @@ -1,281 +0,0 @@ -/* - * net/sched/sch_delay.c Simple constant delay - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version - * 2 of the License, or (at your option) any later version. - * - * Authors: Stephen Hemminger - */ - -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -/* Network delay simulator - This scheduler adds a fixed delay to all packets. - Similar to NISTnet and BSD Dummynet. - - It uses byte fifo underneath similar to TBF */ -struct dly_sched_data { - u32 latency; - u32 limit; - u32 loss; - struct timer_list timer; - struct Qdisc *qdisc; -}; - -/* Time stamp put into socket buffer control block */ -struct dly_skb_cb { - psched_time_t queuetime; -}; - -/* Enqueue packets with underlying discipline (fifo) - * but mark them with current time first. - */ -static int dly_enqueue(struct sk_buff *skb, struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; - int ret; - - /* Random packet drop 0 => none, ~0 => all */ - if (q->loss >= net_random()) { - sch->stats.drops++; - return 0; /* lie about loss so TCP doesn't know */ - } - - PSCHED_GET_TIME(cb->queuetime); - - /* Queue to underlying scheduler */ - ret = q->qdisc->enqueue(skb, q->qdisc); - if (ret) - sch->stats.drops++; - else { - sch->q.qlen++; - sch->stats.bytes += skb->len; - sch->stats.packets++; - } - return ret; -} - -/* Requeue packets but don't change time stamp */ -static int dly_requeue(struct sk_buff *skb, struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - int ret; - - ret = q->qdisc->ops->requeue(skb, q->qdisc); - if (ret == 0) - sch->q.qlen++; - return ret; -} - -static unsigned int dly_drop(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - unsigned int len; - - len = q->qdisc->ops->drop(q->qdisc); - if (len) { - sch->q.qlen--; - sch->stats.drops++; - } - return len; -} - -/* Dequeue packet. - * If packet needs to be held up, then stop the - * queue and set timer to wakeup later. - */ -static struct sk_buff *dly_dequeue(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct sk_buff *skb; - - retry: - skb = q->qdisc->dequeue(q->qdisc); - if (skb) { - struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; - psched_time_t now; - long diff, delay; - - PSCHED_GET_TIME(now); - diff = q->latency - PSCHED_TDIFF(now, cb->queuetime); - - if (diff <= 0) { - sch->q.qlen--; - sch->flags &= ~TCQ_F_THROTTLED; - return skb; - } - - if (q->qdisc->ops->requeue(skb, q->qdisc) != NET_XMIT_SUCCESS) { - sch->q.qlen--; - sch->stats.drops++; - goto retry; - } - - delay = PSCHED_US2JIFFIE(diff); - if (delay <= 0) - delay = 1; - mod_timer(&q->timer, jiffies+delay); - - sch->flags |= TCQ_F_THROTTLED; - } - return NULL; -} - -static void dly_reset(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - - qdisc_reset(q->qdisc); - sch->q.qlen = 0; - sch->flags &= ~TCQ_F_THROTTLED; - del_timer(&q->timer); -} - -static void dly_timer(unsigned long arg) -{ - struct Qdisc *sch = (struct Qdisc *)arg; - - sch->flags &= ~TCQ_F_THROTTLED; - netif_schedule(sch->dev); -} - -/* Tell Fifo the new limit. */ -static int change_limit(struct Qdisc *q, u32 limit) -{ - struct rtattr *rta; - int ret; - - rta = kmalloc(RTA_LENGTH(sizeof(struct tc_fifo_qopt)), GFP_KERNEL); - if (!rta) - return -ENOMEM; - - rta->rta_type = RTM_NEWQDISC; - rta->rta_len = RTA_LENGTH(sizeof(struct tc_fifo_qopt)); - ((struct tc_fifo_qopt *)RTA_DATA(rta))->limit = limit; - ret = q->ops->change(q, rta); - kfree(rta); - - return ret; -} - -/* Setup underlying FIFO discipline */ -static int dly_change(struct Qdisc *sch, struct rtattr *opt) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct tc_dly_qopt *qopt = RTA_DATA(opt); - int err; - - if (q->qdisc == &noop_qdisc) { - struct Qdisc *child - = qdisc_create_dflt(sch->dev, &bfifo_qdisc_ops); - if (!child) - return -EINVAL; - q->qdisc = child; - } - - err = change_limit(q->qdisc, qopt->limit); - if (err) { - qdisc_destroy(q->qdisc); - q->qdisc = &noop_qdisc; - } else { - q->latency = qopt->latency; - q->limit = qopt->limit; - q->loss = qopt->loss; - } - return err; -} - -static int dly_init(struct Qdisc *sch, struct rtattr *opt) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - - if (!opt) - return -EINVAL; - - init_timer(&q->timer); - q->timer.function = dly_timer; - q->timer.data = (unsigned long) sch; - q->qdisc = &noop_qdisc; - - return dly_change(sch, opt); -} - -static void dly_destroy(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - - del_timer(&q->timer); - qdisc_destroy(q->qdisc); - q->qdisc = &noop_qdisc; -} - -static int dly_dump(struct Qdisc *sch, struct sk_buff *skb) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - unsigned char *b = skb->tail; - struct tc_dly_qopt qopt; - - qopt.latency = q->latency; - qopt.limit = q->limit; - qopt.loss = q->loss; - - RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); - - return skb->len; - -rtattr_failure: - skb_trim(skb, b - skb->data); - return -1; -} - -static struct Qdisc_ops dly_qdisc_ops = { - .id = "delay", - .priv_size = sizeof(struct dly_sched_data), - .enqueue = dly_enqueue, - .dequeue = dly_dequeue, - .requeue = dly_requeue, - .drop = dly_drop, - .init = dly_init, - .reset = dly_reset, - .destroy = dly_destroy, - .change = dly_change, - .dump = dly_dump, - .owner = THIS_MODULE, -}; - - -static int __init dly_module_init(void) -{ - return register_qdisc(&dly_qdisc_ops); -} -static void __exit dly_module_exit(void) -{ - unregister_qdisc(&dly_qdisc_ops); -} -module_init(dly_module_init) -module_exit(dly_module_exit) -MODULE_LICENSE("GPL"); diff -urNp -X dontdiff linux-2.6/net/sched/sch_netem.c sched-2.6/net/sched/sch_netem.c --- linux-2.6/net/sched/sch_netem.c 1969-12-31 16:00:00.000000000 -0800 +++ sched-2.6/net/sched/sch_netem.c 2004-06-30 14:05:13.000000000 -0700 @@ -0,0 +1,255 @@ +/* + * net/sched/sch_netem.c Network emulator + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Stephen Hemminger + * Catalin(ux aka Dino) BOIE + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* Network emulator + * + * This scheduler can alters spacing and order + * Similar to NISTnet and BSD Dummynet. + */ + +struct netem_sched_data { + struct sk_buff_head qnormal; + struct sk_buff_head qdelay; + struct timer_list timer; + + u32 latency; + u32 loss; + u32 counter; + u32 gap; +}; + +/* Time stamp put into socket buffer control block */ +struct netem_skb_cb { + psched_time_t time_to_send; +}; + +/* Enqueue packets with underlying discipline (fifo) + * but mark them with current time first. + */ +static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + + pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + + /* Random packet drop 0 => none, ~0 => all */ + if (q->loss >= net_random()) { + sch->stats.drops++; + return 0; /* lie about loss so TCP doesn't know */ + } + + if (q->qnormal.qlen < sch->dev->tx_queue_len) { + PSCHED_GET_TIME(cb->time_to_send); + PSCHED_TADD(cb->time_to_send, q->latency); + + __skb_queue_tail(&q->qnormal, skb); + sch->q.qlen++; + sch->stats.bytes += skb->len; + sch->stats.packets++; + return 0; + } + + sch->stats.drops++; + kfree_skb(skb); + return NET_XMIT_DROP; +} + +/* Requeue packets but don't change time stamp */ +static int netem_requeue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + __skb_queue_head(&q->qnormal, skb); + sch->q.qlen++; + return 0; +} + +/* + * Check the look aside buffer list, and see if any freshly baked buffers. + * If head of queue is not baked, set timer. + */ +static struct sk_buff *netem_get_delayed(struct netem_sched_data *q) +{ + struct sk_buff *skb; + psched_time_t now; + long delay; + + skb = skb_peek(&q->qdelay); + if (skb) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + + PSCHED_GET_TIME(now); + delay = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_dequeue: delay queue %p@%lu %ld\n", + skb, jiffies, delay); + + /* it's baked enough */ + if (delay <= 0) { + __skb_unlink(skb, &q->qdelay); + del_timer(&q->timer); + return skb; + } + + if (!timer_pending(&q->timer)) { + q->timer.expires = jiffies + delay; + add_timer(&q->timer); + } + } + return NULL; +} + +/* Dequeue packet. + * If packet needs to be held up, then put in the delay + * queue and set timer to wakeup later. + */ +static struct sk_buff *netem_dequeue(struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + struct sk_buff *skb; + + skb = netem_get_delayed(q); + if (!skb && (skb = __skb_dequeue(&q->qnormal))) { + /* are we doing out of order packet skip? */ + if (q->counter < q->gap) { + pr_debug("netem_dequeue: send %p normally\n", skb); + q->counter++; + } else { + /* don't send now hold for later */ + pr_debug("netem_dequeue: hold [%p]@%lu\n", skb, jiffies); + __skb_queue_tail(&q->qdelay, skb); + q->counter = 0; + skb = netem_get_delayed(q); + } + } + + if (skb) + sch->q.qlen--; + return skb; +} + +static void netem_timer(unsigned long arg) +{ + struct Qdisc *sch = (struct Qdisc *)arg; + + pr_debug("netem_timer: fired @%lu\n", jiffies); + netif_schedule(sch->dev); +} + +static void netem_reset(struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + skb_queue_purge(&q->qnormal); + skb_queue_purge(&q->qdelay); + + sch->q.qlen = 0; + del_timer_sync(&q->timer); +} + +static int netem_change(struct Qdisc *sch, struct rtattr *opt) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + struct tc_netem_qopt *qopt = RTA_DATA(opt); + + if (qopt->limit) + sch->dev->tx_queue_len = qopt->limit; + + q->gap = qopt->gap; + q->loss = qopt->loss; + q->latency = qopt->latency; + + return 0; +} + +static int netem_init(struct Qdisc *sch, struct rtattr *opt) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + if (!opt) + return -EINVAL; + + skb_queue_head_init(&q->qnormal); + skb_queue_head_init(&q->qdelay); + init_timer(&q->timer); + q->timer.function = netem_timer; + q->timer.data = (unsigned long) sch; + q->counter = 0; + + return netem_change(sch, opt); +} + +static void netem_destroy(struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + del_timer_sync(&q->timer); +} + +static int netem_dump(struct Qdisc *sch, struct sk_buff *skb) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + unsigned char *b = skb->tail; + struct tc_netem_qopt qopt; + + qopt.latency = q->latency; + qopt.limit = sch->dev->tx_queue_len; + qopt.loss = q->loss; + qopt.gap = q->gap; + + RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); + + return skb->len; + +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static struct Qdisc_ops netem_qdisc_ops = { + .id = "netem", + .priv_size = sizeof(struct netem_sched_data), + .enqueue = netem_enqueue, + .dequeue = netem_dequeue, + .requeue = netem_requeue, + .init = netem_init, + .reset = netem_reset, + .destroy = netem_destroy, + .change = netem_change, + .dump = netem_dump, + .owner = THIS_MODULE, +}; + + +static int __init netem_module_init(void) +{ + return register_qdisc(&netem_qdisc_ops); +} +static void __exit netem_module_exit(void) +{ + unregister_qdisc(&netem_qdisc_ops); +} +module_init(netem_module_init) +module_exit(netem_module_exit) +MODULE_LICENSE("GPL"); From oxymoron@waste.org Thu Jul 1 11:44:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 11:44:09 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61Ii3gi002994 for ; Thu, 1 Jul 2004 11:44:03 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i61IhtDj022121; Thu, 1 Jul 2004 13:43:55 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i61Ihtv6022119; Thu, 1 Jul 2004 13:43:55 -0500 Date: Thu, 1 Jul 2004 13:43:55 -0500 From: Matt Mackall To: John Sage Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Parentage of BPF code in Linux Message-ID: <20040701184354.GJ5414@waste.org> References: <20040701181002.GG6445@sparky.finchhaven.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040701181002.GG6445@sparky.finchhaven.net> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 6494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Thu, Jul 01, 2004 at 11:10:02AM -0700, John Sage wrote: > [Non-subscriber: please cc on replies] > > WRT to the SCO/IBM/Linux imbroglio, there was an interesting assertion > made on the Yahoo! Finance message board for SCOX, and I wondered if > anyone could shed some light. > > The assertion is this: > > "...among other things, the Berkeley Packet Filter code, which was > written by an independent developer for the Missouri School District, > licensed under the BSD license terms that never was part of SysV at > any time..." There's a from-scratch reimplementation of BPF in Linux (called Linux Socket Filter) by Jay Schulist in net/core/filter.c. And he appears to have worked for the _Wisconsin_ school district at the time. A Google search on "schulist filter wisconsin" reveals: Jay Schulist, a senior software engineer with Pleasanton, California's Bivio Networks says he wrote the 500 lines of code in 1997 as part of a volunteer project for the Stevens Point Area Catholic Schools in Wisconsin. "I used it for helping a local school district in my home town to connect their old Apple Macintosh machines to the Internet," he said. -- Mathematics is the supreme nostalgia of our time. From P@draigBrady.com Thu Jul 1 12:51:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 12:51:37 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61JpWgi008400 for ; Thu, 1 Jul 2004 12:51:33 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id i61JpEOC095576; Thu, 1 Jul 2004 20:51:15 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <40E46B32.1080605@draigBrady.com> Date: Thu, 01 Jul 2004 20:51:14 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Leech CC: e1000-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] Re: [E1000-devel] e1000 jumbo problems References: <40D883C2.7010106@draigBrady.com> <40D9BF6B.4050807@draigBrady.com> <41b516cb040623114825a9c555@mail.gmail.com> In-Reply-To: <41b516cb040623114825a9c555@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------000106050202080508060107" X-archive-position: 6495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------000106050202080508060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i61JpEOC095576 This patch is not for applying, just for discussion. comments below... Chris Leech wrote: >>>Another related issue, is that the driver uses 4KiB buffers >>>for MTUs in the 1500 -> 2000 range which seems a bit silly. >>>Any particular reason for that? >=20 >=20 > It is wasteful, but does anyone actually use an MTU in the range of > 1501 - 2030? It seems silly to me to go with a non-standard frame > size, but not go up to something that might give you a performance > benefit (9k). > =20 >=20 >>I changed the driver to use 2KiB buffers for frames in the >>1518 -> 2048 range (BSEX=3D0, LPE=3D1). This breaks however >>as packets are not dropped that are larger than the max specified? >>Instead they're scribbled into memory causing a lockup after a while. >=20 >=20 > That sounds right, if you actually got the RCTL register set > correctly. In e1000_setup_rctl the adapter->rx_buffer_len is used to > set that register, and it's currently written to only set LPE if the > buffer size is bigger than 2k (thus, why 4k buffers are used even when > the MTU is in the 1501 - 2030 range). To use 2k buffers for slightly > large frames, you'd want some new flag in the adapter for LPE (or > check netdev->mtu I guess) and do something like: rctl |=3D > E1000_RCTL_SZ_2048 | E1000_RCTL_LPE >=20 > e1000 devices don't have a programmable MTU for receive filtering, > they drop anything larger than 1518 unless LPE (long packet enable) is > set. If LPE is set they accept anything that fits in the FIFO and has > a valid FCS. More accurately e1000s accept anything (even greater than a FIFO). When a large packet is written into multiple FIFOs, only the last rx descriptor has the EOP (end of packet) flag set. The driver doesn't handle this at all currently and will drop the initial buffers (because they don't have the EOP set) which is fine, but it will accept the last buffer (part of the packet). I've attached a patch that fixes this. Also the patch drops packets that fit within a buffer but are larger than MTU. So in summary the patch will stop packets > MTU being accepted by the driver. Note also this patch changes to using 2KiB buffers (from 4KiB) for MTUs between 1500 and 2030, and also it enables large frame reception (LFE) always, but ingore these as they're just for debugging. The patch makes my system completely stable now for MTUs <=3D 2500, However I can still get the system to freeze repeatedly by sending packets larger than this. cheers, P=E1draig. --------------000106050202080508060107 Content-Type: application/x-texinfo; name="e1000-smallMTU.diff" Content-Disposition: inline; filename="e1000-smallMTU.diff" Content-Transfer-Encoding: 7bit diff -Naru e1000-5.2.52-k3/src/e1000.h e1000-pb/src/e1000.h --- e1000-5.2.52-k3/src/e1000.h 2004-05-17 23:59:53.000000000 +0100 +++ e1000-pb/src/e1000.h 2004-06-28 14:45:04.000000000 +0100 @@ -177,6 +177,8 @@ unsigned int next_to_use; /* next descriptor to check for DD status bit */ unsigned int next_to_clean; + /* whether next buffer is partial packet */ + unsigned int multi_buf_pkt; /* array of buffer information structs */ struct e1000_buffer *buffer_info; }; diff -Naru e1000-5.2.52-k3/src/e1000_hw.h e1000-pb/src/e1000_hw.h --- e1000-5.2.52-k3/src/e1000_hw.h 2004-05-17 23:59:53.000000000 +0100 +++ e1000-pb/src/e1000_hw.h 2004-06-29 14:30:45.000000000 +0100 @@ -922,6 +922,7 @@ uint64_t sec; uint64_t cexterr; uint64_t rlec; + uint64_t multibuf; uint64_t xonrxc; uint64_t xontxc; uint64_t xoffrxc; diff -Naru e1000-5.2.52-k3/src/e1000_main.c e1000-pb/src/e1000_main.c --- e1000-5.2.52-k3/src/e1000_main.c 2004-05-17 23:59:53.000000000 +0100 +++ e1000-pb/src/e1000_main.c 2004-07-01 19:24:41.000000000 +0100 @@ -817,6 +817,8 @@ txdr->next_to_use = 0; txdr->next_to_clean = 0; + txdr->multi_buf_pkt = 0; + return 0; } @@ -935,6 +937,8 @@ rxdr->next_to_clean = 0; rxdr->next_to_use = 0; + rxdr->multi_buf_pkt = 0; + return 0; } @@ -962,11 +966,12 @@ rctl &= ~E1000_RCTL_SBP; rctl &= ~(E1000_RCTL_SZ_4096); + rctl |= E1000_RCTL_LPE; switch (adapter->rx_buffer_len) { case E1000_RXBUFFER_2048: default: rctl |= E1000_RCTL_SZ_2048; - rctl &= ~(E1000_RCTL_BSEX | E1000_RCTL_LPE); + rctl &= ~(E1000_RCTL_BSEX); break; case E1000_RXBUFFER_4096: rctl |= E1000_RCTL_SZ_4096 | E1000_RCTL_BSEX | E1000_RCTL_LPE; @@ -1101,6 +1106,8 @@ tx_ring->next_to_use = 0; tx_ring->next_to_clean = 0; + tx_ring->multi_buf_pkt = 0; + E1000_WRITE_REG(&adapter->hw, TDH, 0); E1000_WRITE_REG(&adapter->hw, TDT, 0); } @@ -1169,6 +1176,8 @@ rx_ring->next_to_clean = 0; rx_ring->next_to_use = 0; + rx_ring->multi_buf_pkt = 0; + E1000_WRITE_REG(&adapter->hw, RDH, 0); E1000_WRITE_REG(&adapter->hw, RDT, 0); } @@ -1904,14 +1913,16 @@ DPRINTK(PROBE, ERR, "Invalid MTU setting\n"); return -EINVAL; } + if(max_frame > MAXIMUM_ETHERNET_FRAME_SIZE) { + if(adapter->hw.mac_type < e1000_82543) { + DPRINTK(PROBE, ERR, "Jumbo Frames not supported on 82542\n"); + return -EINVAL; + } + } - if(max_frame <= MAXIMUM_ETHERNET_FRAME_SIZE) { + if(max_frame <= E1000_RXBUFFER_2048) { adapter->rx_buffer_len = E1000_RXBUFFER_2048; - } else if(adapter->hw.mac_type < e1000_82543) { - DPRINTK(PROBE, ERR, "Jumbo Frames not supported on 82542\n"); - return -EINVAL; - } else if(max_frame <= E1000_RXBUFFER_4096) { adapter->rx_buffer_len = E1000_RXBUFFER_4096; @@ -1961,7 +1972,7 @@ adapter->stats.gorch += E1000_READ_REG(hw, GORCH); adapter->stats.bprc += E1000_READ_REG(hw, BPRC); adapter->stats.mprc += E1000_READ_REG(hw, MPRC); - adapter->stats.roc += E1000_READ_REG(hw, ROC); + adapter->stats.roc += E1000_READ_REG(hw, ROC); adapter->stats.roc += adapter->stats.multibuf; adapter->stats.prc64 += E1000_READ_REG(hw, PRC64); adapter->stats.prc127 += E1000_READ_REG(hw, PRC127); adapter->stats.prc255 += E1000_READ_REG(hw, PRC255); @@ -1979,7 +1990,7 @@ adapter->stats.latecol += E1000_READ_REG(hw, LATECOL); adapter->stats.dc += E1000_READ_REG(hw, DC); adapter->stats.sec += E1000_READ_REG(hw, SEC); - adapter->stats.rlec += E1000_READ_REG(hw, RLEC); + adapter->stats.rlec += E1000_READ_REG(hw, RLEC); adapter->stats.rlec += adapter->stats.multibuf; adapter->stats.xonrxc += E1000_READ_REG(hw, XONRXC); adapter->stats.xontxc += E1000_READ_REG(hw, XONTXC); adapter->stats.xoffrxc += E1000_READ_REG(hw, XOFFRXC); @@ -2069,6 +2080,8 @@ adapter->phy_stats.receive_errors += phy_tmp; } + adapter->stats.multibuf=0; + spin_unlock_irqrestore(&adapter->stats_lock, flags); } @@ -2190,6 +2203,7 @@ if(work_done < work_to_do || !netif_running(netdev)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); + return 0; } return (work_done >= work_to_do); @@ -2312,7 +2326,18 @@ skb = buffer_info->skb; length = le16_to_cpu(rx_desc->length); - if(!(rx_desc->status & E1000_RXD_STAT_EOP)) { + if((!(rx_desc->status & E1000_RXD_STAT_EOP)) || rx_ring->multi_buf_pkt) { + + if(!(rx_desc->status & E1000_RXD_STAT_EOP)) { + rx_ring->multi_buf_pkt=1; /* Next buffer also to be dropped */ + } else { + spin_lock_irqsave(&adapter->stats_lock, flags); + adapter->stats.multibuf++; /* counted as "frame too large" error */ + /* TODO: decrement byte and packet counts */ + spin_unlock_irqrestore(&adapter->stats_lock, flags); + + rx_ring->multi_buf_pkt=0; + } /* All receives must fit into a single buffer */ @@ -2358,6 +2383,27 @@ } } + if(length > adapter->hw.max_frame_size + + (rx_desc->status & E1000_RXD_STAT_VP ? VLAN_TAG_SIZE : 0)) { + + spin_lock_irqsave(&adapter->stats_lock, flags); + adapter->stats.multibuf++; /* counted as "frame too large" error */ + /* TODO: decrement byte and packet counts */ + spin_unlock_irqrestore(&adapter->stats_lock, flags); + + E1000_DBG("%s: Packet length %d too big\n", + netdev->name, length); + + dev_kfree_skb_irq(skb); + rx_desc->status = 0; + buffer_info->skb = NULL; + + if(++i == rx_ring->count) i = 0; + + rx_desc = E1000_RX_DESC(*rx_ring, i); + continue; + } + /* Good Receive */ skb_put(skb, length - ETHERNET_FCS_SIZE); --------------000106050202080508060107-- From vkondra@mail.ru Thu Jul 1 13:01:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 13:01:22 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61K1Kgi008857 for ; Thu, 1 Jul 2004 13:01:21 -0700 Received: from [212.179.236.79] (port=57836 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1Bg7k6-0009MO-00 for netdev@oss.sgi.com; Fri, 02 Jul 2004 00:01:18 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: skb->sb on driver xmit Date: Thu, 1 Jul 2004 22:59:56 +0300 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Message-Id: <200407012300.04290.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i61K1Kgi008857 X-archive-position: 6496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see (kernel 2.4.26) that, sometimes, driver's xmit function gets packet with skb->cb containing something from higher level protocols, and non-NULL skb->destructor. Is it documented? If no, it is worth to do so. Like "In case driver want to do some non-trivial manipulations with skb, that involves skb->cb and destructor, one should call skb_orphan()." Also, "When passing skb from driver to stack, driver should clear skb->cb. Otherwise, stack will get confused." Vladimir. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFA5G1Cqxdj7mhC6o0RAkGnAKCi9xH1qP8Y6lCg2QcTsm2ywWPEoQCYqGml 6SMQsIlyKTBmejQY9yh6HA== =G3x9 -----END PGP SIGNATURE----- From shemminger@osdl.org Thu Jul 1 13:11:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 13:11:25 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61KBJgi009530 for ; Thu, 1 Jul 2004 13:11:19 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i61KB1G29825; Thu, 1 Jul 2004 13:11:01 -0700 Date: Thu, 1 Jul 2004 13:11:01 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [PATCH 2.4] update to network emulation QOS scheduler Message-Id: <20040701131101.184f7840@dell_ss3.pdx.osdl.net> In-Reply-To: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This is the 2.4 version of the conversion of simple network delay scheduler to network emulator. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h --- a/include/linux/pkt_sched.h 2004-07-01 13:06:36 -07:00 +++ b/include/linux/pkt_sched.h 2004-07-01 13:06:36 -07:00 @@ -432,12 +432,15 @@ #define TCA_ATM_MAX TCA_ATM_STATE -/* Delay section */ -struct tc_dly_qopt +/* Network emulator */ +struct tc_netem_qopt { - __u32 latency; - __u32 limit; - __u32 loss; + __u32 latency; /* added delay (us) */ + __u32 limit; /* fifo limit (packets) */ + __u32 loss; /* random packet loss (0=none ~0=100%) */ + __u32 gap; /* re-ordering gap (0 for delay all) */ + __u32 duplicate; /* random packet dup (0=none ~0=100%) */ + __u32 rate; /* maximum transmit rate (bytes/sec) */ }; #endif diff -Nru a/net/sched/Config.in b/net/sched/Config.in --- a/net/sched/Config.in 2004-07-01 13:06:36 -07:00 +++ b/net/sched/Config.in 2004-07-01 13:06:36 -07:00 @@ -15,7 +15,7 @@ tristate ' TEQL queue' CONFIG_NET_SCH_TEQL tristate ' TBF queue' CONFIG_NET_SCH_TBF tristate ' GRED queue' CONFIG_NET_SCH_GRED -tristate ' Network delay simulator' CONFIG_NET_SCH_DELAY +tristate ' Network emulator' CONFIG_NET_SCH_NETEM tristate ' Diffserv field marker' CONFIG_NET_SCH_DSMARK if [ "$CONFIG_NETFILTER" = "y" ]; then tristate ' Ingress Qdisc' CONFIG_NET_SCH_INGRESS diff -Nru a/net/sched/Makefile b/net/sched/Makefile --- a/net/sched/Makefile 2004-07-01 13:06:36 -07:00 +++ b/net/sched/Makefile 2004-07-01 13:06:36 -07:00 @@ -14,7 +14,7 @@ obj-$(CONFIG_NET_SCH_INGRESS) += sch_ingress.o obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o obj-$(CONFIG_NET_SCH_CSZ) += sch_csz.o -obj-$(CONFIG_NET_SCH_DELAY) += sch_delay.o +obj-$(CONFIG_NET_SCH_NETEM) += sch_netem.o obj-$(CONFIG_NET_SCH_HPFQ) += sch_hpfq.o obj-$(CONFIG_NET_SCH_HFSC) += sch_hfsc.o obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o diff -Nru a/net/sched/sch_delay.c b/net/sched/sch_delay.c --- a/net/sched/sch_delay.c 2004-07-01 13:06:36 -07:00 +++ /dev/null Wed Dec 31 16:00:00 196900 @@ -1,289 +0,0 @@ -/* - * net/sched/sch_delay.c Simple constant delay - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version - * 2 of the License, or (at your option) any later version. - * - * Authors: Stephen Hemminger - */ - -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -/* Network delay simulator - This scheduler adds a fixed delay to all packets. - Similar to NISTnet and BSD Dummynet. - - It uses byte fifo underneath similar to TBF */ -struct dly_sched_data { - u32 latency; - u32 limit; - u32 loss; - struct timer_list timer; - struct Qdisc *qdisc; -}; - -/* Time stamp put into socket buffer control block */ -struct dly_skb_cb { - psched_time_t queuetime; -}; - -/* Enqueue packets with underlying discipline (fifo) - * but mark them with current time first. - */ -static int dly_enqueue(struct sk_buff *skb, struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; - int ret; - - /* Random packet drop 0 => none, ~0 => all */ - if (q->loss >= net_random()) { - sch->stats.drops++; - return 0; /* lie about loss so TCP doesn't know */ - } - - PSCHED_GET_TIME(cb->queuetime); - - /* Queue to underlying scheduler */ - ret = q->qdisc->enqueue(skb, q->qdisc); - if (ret) - sch->stats.drops++; - else { - sch->q.qlen++; - sch->stats.bytes += skb->len; - sch->stats.packets++; - } - return ret; -} - -/* Requeue packets but don't change time stamp */ -static int dly_requeue(struct sk_buff *skb, struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - int ret; - - ret = q->qdisc->ops->requeue(skb, q->qdisc); - if (ret == 0) - sch->q.qlen++; - return ret; -} - -static unsigned int dly_drop(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - unsigned int len; - - len = q->qdisc->ops->drop(q->qdisc); - if (len) { - sch->q.qlen--; - sch->stats.drops++; - } - return len; -} - -/* Dequeue packet. - * If packet needs to be held up, then stop the - * queue and set timer to wakeup later. - */ -static struct sk_buff *dly_dequeue(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct sk_buff *skb; - - retry: - skb = q->qdisc->dequeue(q->qdisc); - if (skb) { - struct dly_skb_cb *cb = (struct dly_skb_cb *)skb->cb; - psched_time_t now; - long diff, delay; - - PSCHED_GET_TIME(now); - diff = q->latency - PSCHED_TDIFF(now, cb->queuetime); - - if (diff <= 0) { - sch->q.qlen--; - sch->flags &= ~TCQ_F_THROTTLED; - return skb; - } - - if (q->qdisc->ops->requeue(skb, q->qdisc) != NET_XMIT_SUCCESS) { - sch->q.qlen--; - sch->stats.drops++; - goto retry; - } - - delay = PSCHED_US2JIFFIE(diff); - if (delay <= 0) - delay = 1; - mod_timer(&q->timer, jiffies+delay); - - sch->flags |= TCQ_F_THROTTLED; - } - return NULL; -} - -static void dly_reset(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - - qdisc_reset(q->qdisc); - sch->q.qlen = 0; - sch->flags &= ~TCQ_F_THROTTLED; - del_timer(&q->timer); -} - -static void dly_timer(unsigned long arg) -{ - struct Qdisc *sch = (struct Qdisc *)arg; - - sch->flags &= ~TCQ_F_THROTTLED; - netif_schedule(sch->dev); -} - -/* Tell Fifo the new limit. */ -static int change_limit(struct Qdisc *q, u32 limit) -{ - struct rtattr *rta; - int ret; - - rta = kmalloc(RTA_LENGTH(sizeof(struct tc_fifo_qopt)), GFP_KERNEL); - if (!rta) - return -ENOMEM; - - rta->rta_type = RTM_NEWQDISC; - rta->rta_len = RTA_LENGTH(sizeof(struct tc_fifo_qopt)); - ((struct tc_fifo_qopt *)RTA_DATA(rta))->limit = limit; - ret = q->ops->change(q, rta); - kfree(rta); - - return ret; -} - -/* Setup underlying FIFO discipline */ -static int dly_change(struct Qdisc *sch, struct rtattr *opt) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - struct tc_dly_qopt *qopt = RTA_DATA(opt); - int err; - - if (q->qdisc == &noop_qdisc) { - struct Qdisc *child - = qdisc_create_dflt(sch->dev, &bfifo_qdisc_ops); - if (!child) - return -EINVAL; - q->qdisc = child; - } - - err = change_limit(q->qdisc, qopt->limit); - if (err) { - qdisc_destroy(q->qdisc); - q->qdisc = &noop_qdisc; - } else { - q->latency = qopt->latency; - q->limit = qopt->limit; - q->loss = qopt->loss; - } - return err; -} - -static int dly_init(struct Qdisc *sch, struct rtattr *opt) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - int err; - - if (!opt) - return -EINVAL; - - MOD_INC_USE_COUNT; - - init_timer(&q->timer); - q->timer.function = dly_timer; - q->timer.data = (unsigned long) sch; - q->qdisc = &noop_qdisc; - - err = dly_change(sch, opt); - if (err) - MOD_DEC_USE_COUNT; - - return err; -} - -static void dly_destroy(struct Qdisc *sch) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - - del_timer(&q->timer); - qdisc_destroy(q->qdisc); - q->qdisc = &noop_qdisc; - - MOD_DEC_USE_COUNT; -} - -static int dly_dump(struct Qdisc *sch, struct sk_buff *skb) -{ - struct dly_sched_data *q = (struct dly_sched_data *)sch->data; - unsigned char *b = skb->tail; - struct tc_dly_qopt qopt; - - qopt.latency = q->latency; - qopt.limit = q->limit; - qopt.loss = q->loss; - - RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); - - return skb->len; - -rtattr_failure: - skb_trim(skb, b - skb->data); - return -1; -} - -struct Qdisc_ops dly_qdisc_ops = { - .id = "delay", - .priv_size = sizeof(struct dly_sched_data), - .enqueue = dly_enqueue, - .dequeue = dly_dequeue, - .requeue = dly_requeue, - .drop = dly_drop, - .init = dly_init, - .reset = dly_reset, - .destroy = dly_destroy, - .change = dly_change, - .dump = dly_dump, -}; - -#ifdef MODULE -int init_module(void) -{ - return register_qdisc(&dly_qdisc_ops); -} - -void cleanup_module(void) -{ - unregister_qdisc(&dly_qdisc_ops); -} -#endif -MODULE_LICENSE("GPL"); diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/sched/sch_netem.c 2004-07-01 13:06:36 -07:00 @@ -0,0 +1,255 @@ +/* + * net/sched/sch_netem.c Network emulator + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Stephen Hemminger + * Catalin(ux aka Dino) BOIE + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* Network emulator + * + * This scheduler can alters spacing and order + * Similar to NISTnet and BSD Dummynet. + */ + +struct netem_sched_data { + struct sk_buff_head qnormal; + struct sk_buff_head qdelay; + struct timer_list timer; + + u32 latency; + u32 loss; + u32 counter; + u32 gap; +}; + +/* Time stamp put into socket buffer control block */ +struct netem_skb_cb { + psched_time_t time_to_send; +}; + +/* Enqueue packets with underlying discipline (fifo) + * but mark them with current time first. + */ +static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + + pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + + /* Random packet drop 0 => none, ~0 => all */ + if (q->loss >= net_random()) { + sch->stats.drops++; + return 0; /* lie about loss so TCP doesn't know */ + } + + if (q->qnormal.qlen < sch->dev->tx_queue_len) { + PSCHED_GET_TIME(cb->time_to_send); + PSCHED_TADD(cb->time_to_send, q->latency); + + __skb_queue_tail(&q->qnormal, skb); + sch->q.qlen++; + sch->stats.bytes += skb->len; + sch->stats.packets++; + return 0; + } + + sch->stats.drops++; + kfree_skb(skb); + return NET_XMIT_DROP; +} + +/* Requeue packets but don't change time stamp */ +static int netem_requeue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + __skb_queue_head(&q->qnormal, skb); + sch->q.qlen++; + return 0; +} + +/* + * Check the look aside buffer list, and see if any freshly baked buffers. + * If head of queue is not baked, set timer. + */ +static struct sk_buff *netem_get_delayed(struct netem_sched_data *q) +{ + struct sk_buff *skb; + psched_time_t now; + long delay; + + skb = skb_peek(&q->qdelay); + if (skb) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + + PSCHED_GET_TIME(now); + delay = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_dequeue: delay queue %p@%lu %ld\n", + skb, jiffies, delay); + + /* it's baked enough */ + if (delay <= 0) { + __skb_unlink(skb, &q->qdelay); + del_timer(&q->timer); + return skb; + } + + if (!timer_pending(&q->timer)) { + q->timer.expires = jiffies + delay; + add_timer(&q->timer); + } + } + return NULL; +} + +/* Dequeue packet. + * If packet needs to be held up, then put in the delay + * queue and set timer to wakeup later. + */ +static struct sk_buff *netem_dequeue(struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + struct sk_buff *skb; + + skb = netem_get_delayed(q); + if (!skb && (skb = __skb_dequeue(&q->qnormal))) { + /* are we doing out of order packet skip? */ + if (q->counter < q->gap) { + pr_debug("netem_dequeue: send %p normally\n", skb); + q->counter++; + } else { + /* don't send now hold for later */ + pr_debug("netem_dequeue: hold [%p]@%lu\n", skb, jiffies); + __skb_queue_tail(&q->qdelay, skb); + q->counter = 0; + skb = netem_get_delayed(q); + } + } + + if (skb) + sch->q.qlen--; + return skb; +} + +static void netem_timer(unsigned long arg) +{ + struct Qdisc *sch = (struct Qdisc *)arg; + + pr_debug("netem_timer: fired @%lu\n", jiffies); + netif_schedule(sch->dev); +} + +static void netem_reset(struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + skb_queue_purge(&q->qnormal); + skb_queue_purge(&q->qdelay); + + sch->q.qlen = 0; + del_timer_sync(&q->timer); +} + +static int netem_change(struct Qdisc *sch, struct rtattr *opt) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + struct tc_netem_qopt *qopt = RTA_DATA(opt); + + if (qopt->limit) + sch->dev->tx_queue_len = qopt->limit; + + q->gap = qopt->gap; + q->loss = qopt->loss; + q->latency = qopt->latency; + + return 0; +} + +static int netem_init(struct Qdisc *sch, struct rtattr *opt) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + if (!opt) + return -EINVAL; + + skb_queue_head_init(&q->qnormal); + skb_queue_head_init(&q->qdelay); + init_timer(&q->timer); + q->timer.function = netem_timer; + q->timer.data = (unsigned long) sch; + q->counter = 0; + + return netem_change(sch, opt); +} + +static void netem_destroy(struct Qdisc *sch) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + del_timer_sync(&q->timer); +} + +static int netem_dump(struct Qdisc *sch, struct sk_buff *skb) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + unsigned char *b = skb->tail; + struct tc_netem_qopt qopt; + + qopt.latency = q->latency; + qopt.limit = sch->dev->tx_queue_len; + qopt.loss = q->loss; + qopt.gap = q->gap; + + RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); + + return skb->len; + +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static struct Qdisc_ops netem_qdisc_ops = { + .id = "netem", + .priv_size = sizeof(struct netem_sched_data), + .enqueue = netem_enqueue, + .dequeue = netem_dequeue, + .requeue = netem_requeue, + .init = netem_init, + .reset = netem_reset, + .destroy = netem_destroy, + .change = netem_change, + .dump = netem_dump, +}; + + +static int __init netem_module_init(void) +{ + return register_qdisc(&netem_qdisc_ops); +} +static void __exit netem_module_exit(void) +{ + unregister_qdisc(&netem_qdisc_ops); +} +module_init(netem_module_init) +module_exit(netem_module_exit) +MODULE_LICENSE("GPL"); From shemminger@osdl.org Thu Jul 1 13:37:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 13:38:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61Kbsgi010239 for ; Thu, 1 Jul 2004 13:37:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i61KbcG02617; Thu, 1 Jul 2004 13:37:38 -0700 Date: Thu, 1 Jul 2004 13:37:38 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Arnaldo Carvalho de Melo , netdev@oss.sgi.com Subject: [PATCH] TCP acts like it is always out of memory. Message-Id: <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> In-Reply-To: <20040630153049.3ca25b76.davem@redhat.com> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Current 2.6.7 tree acts as if it is alway under memory pressure because a recent change did a s/tcp_memory_pressure/tcp_prot.memory_pressure/. The problem is tcp_prot.memory_pressure is a pointer, so it is always non-zero! Rather than using *tcp_prot.memory_pressure, just go back to looking at tcp_memory_pressure. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-07-01 13:36:58 -07:00 +++ b/net/ipv4/tcp_input.c 2004-07-01 13:36:58 -07:00 @@ -259,7 +259,7 @@ /* Check #1 */ if (tp->rcv_ssthresh < tp->window_clamp && (int)tp->rcv_ssthresh < tcp_space(sk) && - !tcp_prot.memory_pressure) { + !tcp_memory_pressure) { int incr; /* Check #2. Increase window, if skb with such overhead @@ -349,7 +349,7 @@ if (ofo_win) { if (sk->sk_rcvbuf < sysctl_tcp_rmem[2] && !(sk->sk_userlocks & SOCK_RCVBUF_LOCK) && - !tcp_prot.memory_pressure && + !tcp_memory_pressure && atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) sk->sk_rcvbuf = min(atomic_read(&sk->sk_rmem_alloc), sysctl_tcp_rmem[2]); @@ -3764,7 +3764,7 @@ if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf) tcp_clamp_window(sk, tp); - else if (tcp_prot.memory_pressure) + else if (tcp_memory_pressure) tp->rcv_ssthresh = min(tp->rcv_ssthresh, 4U * tp->advmss); tcp_collapse_ofo_queue(sk); @@ -3844,7 +3844,7 @@ if (tp->packets_out < tp->snd_cwnd && !(sk->sk_userlocks & SOCK_SNDBUF_LOCK) && - !tcp_prot.memory_pressure && + !tcp_memory_pressure && atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) { int sndmem = max_t(u32, tp->mss_clamp, tp->mss_cache) + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff), diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-07-01 13:36:58 -07:00 +++ b/net/ipv4/tcp_output.c 2004-07-01 13:36:58 -07:00 @@ -672,7 +672,7 @@ if (free_space < full_space/2) { tp->ack.quick = 0; - if (tcp_prot.memory_pressure) + if (tcp_memory_pressure) tp->rcv_ssthresh = min(tp->rcv_ssthresh, 4U*tp->advmss); if (free_space < mss) diff -Nru a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c --- a/net/ipv4/tcp_timer.c 2004-07-01 13:36:58 -07:00 +++ b/net/ipv4/tcp_timer.c 2004-07-01 13:36:58 -07:00 @@ -257,7 +257,7 @@ TCP_CHECK_TIMER(sk); out: - if (tcp_prot.memory_pressure) + if (tcp_memory_pressure) sk_stream_mem_reclaim(sk); out_unlock: bh_unlock_sock(sk); From davem@redhat.com Thu Jul 1 14:05:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 14:05:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61L5Fgi011087 for ; Thu, 1 Jul 2004 14:05:16 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i61L57e1018065; Thu, 1 Jul 2004 17:05:07 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i61L57013458; Thu, 1 Jul 2004 17:05:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i61L4fOA004142; Thu, 1 Jul 2004 17:04:41 -0400 Date: Thu, 1 Jul 2004 14:04:06 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] TCP acts like it is always out of memory. Message-Id: <20040701140406.62dfbc2a.davem@redhat.com> In-Reply-To: <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 1 Jul 2004 13:37:38 -0700 Stephen Hemminger wrote: > Current 2.6.7 tree acts as if it is alway under memory pressure because > a recent change did a s/tcp_memory_pressure/tcp_prot.memory_pressure/. > The problem is tcp_prot.memory_pressure is a pointer, so it is always non-zero! > > Rather than using *tcp_prot.memory_pressure, just go back to looking at > tcp_memory_pressure. Hehe, applied thanks Stephen. From romieu@fr.zoreil.com Thu Jul 1 14:50:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 14:51:01 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i61Lougi012324 for ; Thu, 1 Jul 2004 14:50:57 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i61Lloon007357; Thu, 1 Jul 2004 23:47:50 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i61LloHr007356; Thu, 1 Jul 2004 23:47:50 +0200 Date: Thu, 1 Jul 2004 23:47:50 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-mm3 1/1] via-velocity: use common crc16 code for WOL Message-ID: <20040701234750.A7109@electric-eye.fr.zoreil.com> References: <20040630223346.A23520@electric-eye.fr.zoreil.com> <40E384F9.7090108@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40E384F9.7090108@pobox.com>; from jgarzik@pobox.com on Wed, Jun 30, 2004 at 11:28:57PM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 6500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Jeff Garzik : > patch OK but rejected against mainline I assume mainline means bk-linus here. I have checked and the patch applies fine to 2.6.7-mm5 which includes both bk-linus and bk-netdev from yesterday (aka: bk://gkernel.bkbits.net/netdev-2.6 jgarzik@pobox.com|ChangeSet|20040622043820|36094 jgarzik) -- Ueimor From acme@conectiva.com.br Thu Jul 1 18:45:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 18:45:45 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i621jegi020192 for ; Thu, 1 Jul 2004 18:45:41 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 563) id 760864754E; Thu, 1 Jul 2004 22:45:34 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 1F3F747B4A for ; Thu, 1 Jul 2004 22:45:30 -0300 (BRT) Received: (qmail 20664 invoked by uid 0); 2 Jul 2004 02:43:39 -0000 Received: from mapi8.distro.conectiva (HELO oops.kerneljanitors.org) (10.0.16.10) by burns.conectiva with SMTP; 2 Jul 2004 02:43:39 -0000 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id 48BD04C822; Thu, 1 Jul 2004 22:32:25 -0300 (BRT) Date: Thu, 1 Jul 2004 22:32:25 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] TCP acts like it is always out of memory. Message-ID: <20040702013225.GA24707@conectiva.com.br> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040701140406.62dfbc2a.davem@redhat.com> X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.5.1i X-Bogosity: No, tests=bogofilter, spamicity=0.499998, version=0.16.3 X-archive-position: 6501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Thu, Jul 01, 2004 at 02:04:06PM -0700, David S. Miller escreveu: > On Thu, 1 Jul 2004 13:37:38 -0700 > Stephen Hemminger wrote: > > > Current 2.6.7 tree acts as if it is alway under memory pressure because > > a recent change did a s/tcp_memory_pressure/tcp_prot.memory_pressure/. > > The problem is tcp_prot.memory_pressure is a pointer, so it is always non-zero! > > > > Rather than using *tcp_prot.memory_pressure, just go back to looking at > > tcp_memory_pressure. > > Hehe, applied thanks Stephen. :-) Thanks Stephen for the fix, this was a leftover of the conversion of the memory pressure members in struct proto to pointers, to cover the case pointed out by David related to the ipv6_mapped functionality in the 1.1722.122.23 changeset, (i.e. tcp_prot and tcpv6_prot having to share the same accounting variables), I forgot to convert all places where the tcp_prot.memory_pressure memory is used, the fix is exactly what I should have done. Due to family health problems I was unable to promply fix this thinko, so, again, thank you very much. Best Regards, - Arnaldo From jhaller@lucent.com Thu Jul 1 21:40:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jul 2004 21:40:09 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i624e5gi026764 for ; Thu, 1 Jul 2004 21:40:06 -0700 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i624dwJh011365 for ; Thu, 1 Jul 2004 23:39:59 -0500 (CDT) Received: from lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i624dwL16471; Thu, 1 Jul 2004 23:39:58 -0500 (CDT) Message-ID: <40E4E719.6000508@lucent.com> Date: Thu, 01 Jul 2004 23:39:53 -0500 From: John Haller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: SO_REUSEADDR, restarting servers, and security patches Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jhaller@lucent.com Precedence: bulk X-list: netdev In October 2002, Yoshifuji Hideaki introduced a patch that prevents completely any duplication of , even when SO_REUSEADDR is set, preventing port stealing denial-of-service attacks. This also has the side effect of not allowing a server to be immediately restarted after being stopped, because of the sockets that remain in the TCP_TIME_WAIT state. Would security be negatively impacted by relaxing the restrictions introduced by the above patch to allow a bind to a TCP port only if all existing references to that TCP port were in the TCP_TIME_WAIT state, and both the listening port and all of the TCP_TIME_WAIT sockets had the SO_REUSEADDR flag set? This relaxation would only help in the case of servers where the listener and connected sockets are all stopped at the same time, and not loosely connect servers where the connected sockets are handled in a separate process from the listener. I don't want to use SO_REUSEPORT for two reasons. The first is that SO_REUSEPORT allows binding the same address twice for active sockets. The second is that SO_REUSEPORT is not commonly enabled. The top message regarding the patch is located here: http://oss.sgi.com/projects/netdev/archive/2002-10/msg00035.html -- John Haller From akpm@osdl.org Fri Jul 2 00:51:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 00:51:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i627p1gi002305 for ; Fri, 2 Jul 2004 00:51:01 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i627otG14795 for ; Fri, 2 Jul 2004 00:50:55 -0700 Date: Fri, 2 Jul 2004 00:49:56 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database Message-Id: <20040702004956.448c95d9.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Could someone please take a look at the locking in net/ipv4/ipmr.c:ipmr_mfc_seq_next? It seems rather broken. Begin forwarded message: Date: Thu, 1 Jul 2004 18:01:00 -0700 (PDT) From: Yichen Xie To: linux-kernel@vger.kernel.org Subject: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database Hi all, We are a group of researchers at Stanford working on program analysis algorithms. We have been building a precision enhanced program analysis engine at Stanford, and our first application was to derive mutex/lock behavior in the linux kernel. In the process, we found 99 likely synchronization errors in linux kernel version 2.6.5: http://glide.stanford.edu/linux-lock/err1.html (69 errors) http://glide.stanford.edu/linux-lock/err2.html (30 errors) err1.html consists of potential double locks/unlocks. Acquiring a lock twice in a row may result in a system hang, and releasing a lock more than once with certain mutex functions (e.g. up) may cause critical section violations. err2.html consists of reports on inconsistent output lock states on function exit. These errors usually correspond to missed lock operations on error paths. (filenames in this report correspond to where a function is declared, so CTAGS may come in handy to find the actual implementation of the function). In the error reports, functions are hyperlinked to their derived summaries, and those of their callees (since the analysis spans function calls, the error condition of a particular function usually depend on the locking behavior of its callees). For example, in function "radeon_pm_program_v2clk" (first error report in err1.html), the tool flagged an error at line 323 of "drivers/video/aty/radeon_pm.c". Line 323 invokes two macros, OUTPLL, and INPLL. OUTPLL acquires "rinfo->reg_lock", and then evaluates "addr", which is calculated, in this case, by calling _INPLL. By clicking on the link "drivers/video/aty/radeon_pm.c:radeon_pm_program_v2clk", we can see that _INPLL requires "rinfo->reg_lock" be unheld on entry (confirmed by looking at its definition), which is not satisfied in this example. So this is a double lock error and could potentially lead to a deadlock on MP systems. We also have a separate web interface to the summary database at: http://glide.stanford.edu/linux-lock/ For example, typing "fh_put" in the input box gives ========= SUMMARY ========= FUNCTION SUMMARY: 'include/linux/nfsd/nfsfh.h:fh_put' { dcache_lock(global): [unlocked -> unlocked] fhp(param#0)->fh_dentry->d_lock: [unlocked -> unlocked] fhp(param#0)->fh_dentry->d_inode->i_sem: [locked -> unlocked] } Each line in the function summary correspond to the requirements and effects on one particular lock. For example, fh_put requires that the global lock variable dcache_lock be unheld on entry, and it'll remain unheld on exit. It also requires fhp->fh_dentry->d_inode->i_sem be held on entry and it'll release it on exit. (note: please ignore summaries for lock premitives like spin_lock or down_interruptible; models for these functions are built into the checker and the derived summaries are not used). We have found that some modules in the kernel has functions with complicated synchronization behavior (esp. in filesystems), and we hope summaries generated by this tool could be useful not only for bug finding, but also for documentation purposes as well. The analysis is intraprocedurally "path sensitive", so it won't be fooled by cases like if (flag & BLOCKING) spin_lock(&l); ... if (flag & BLOCKING) spin_unlock(&l); or if (!spin_trylock(&l)) return -EAGAIN; ... spin_unlock(&l); The analysis algorithm models values (down to individual bits) and pointers in the program with a boolean satisfiability solver with high precision, and we're actively looking for other properties involving (heavy) data dependencies where naive analysis would fail. Suggestions and insights from the linux kernel community will be more than welcome! As always, feedbacks and confirmations will be greatly appreciated! Best regards, Yichen Xie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From akpm@osdl.org Fri Jul 2 01:12:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 01:13:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i628CSgi003110 for ; Fri, 2 Jul 2004 01:12:28 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i628CFG17588; Fri, 2 Jul 2004 01:12:15 -0700 Message-Id: <200407020812.i628CFG17588@mail.osdl.org> Subject: [patch 1/1] err1-28: rose_route locking fix To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Fri, 02 Jul 2004 01:11:17 -0700 X-archive-position: 6504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Fix deadlock in rose_del_loopback_node(). Found by the Stanford locking checker. Signed-off-by: Andrew Morton --- 25-akpm/net/rose/rose_route.c | 1 - 1 files changed, 1 deletion(-) diff -puN net/rose/rose_route.c~err1-28-rose_route-locking-fix net/rose/rose_route.c --- 25/net/rose/rose_route.c~err1-28-rose_route-locking-fix 2004-07-02 01:09:27.377403248 -0700 +++ 25-akpm/net/rose/rose_route.c 2004-07-02 01:09:33.617454616 -0700 @@ -206,7 +206,6 @@ static void rose_remove_node(struct rose { struct rose_node *s; - spin_lock_bh(&rose_node_list_lock); if ((s = rose_node_list) == rose_node) { rose_node_list = rose_node->next; kfree(rose_node); _ From akpm@osdl.org Fri Jul 2 01:29:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 01:30:46 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i628TZgi003788 for ; Fri, 2 Jul 2004 01:29:37 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i628TNG20391; Fri, 2 Jul 2004 01:29:23 -0700 Message-Id: <200407020829.i628TNG20391@mail.osdl.org> Subject: [patch 1/1] err1-62: ax25_ds_idletimer_expiry() locking fix To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Fri, 02 Jul 2004 01:28:24 -0700 X-archive-position: 6505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Fix deadlock identified by the Stanford locking checker. Signed-off-by: Andrew Morton --- 25-akpm/net/ax25/ax25_ds_timer.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/ax25/ax25_ds_timer.c~err1-62-ax25_ds_idletimer_expiry-locking-fix net/ax25/ax25_ds_timer.c --- 25/net/ax25/ax25_ds_timer.c~err1-62-ax25_ds_idletimer_expiry-locking-fix 2004-07-02 01:27:07.504239472 -0700 +++ 25-akpm/net/ax25/ax25_ds_timer.c 2004-07-02 01:27:11.824582680 -0700 @@ -180,7 +180,7 @@ void ax25_ds_idletimer_expiry(ax25_cb *a ax25->sk->sk_state_change(ax25->sk); sock_set_flag(ax25->sk, SOCK_DEAD); } - bh_lock_sock(ax25->sk); + bh_unlock_sock(ax25->sk); } } _ From akpm@osdl.org Fri Jul 2 01:32:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 01:32:28 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i628Vxgi004053 for ; Fri, 2 Jul 2004 01:32:01 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i628VmG20814; Fri, 2 Jul 2004 01:31:48 -0700 Message-Id: <200407020831.i628VmG20814@mail.osdl.org> Subject: [patch 1/1] err1-67: lapb_unregister() locking fix To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Fri, 02 Jul 2004 01:30:49 -0700 X-archive-position: 6506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Fix deadlock identified by the Stanford locking checker. Signed-off-by: Andrew Morton --- 25-akpm/net/lapb/lapb_iface.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/lapb/lapb_iface.c~err1-67-lapb_unregister-locking-fix net/lapb/lapb_iface.c --- 25/net/lapb/lapb_iface.c~err1-67-lapb_unregister-locking-fix 2004-07-02 01:29:50.645438240 -0700 +++ 25-akpm/net/lapb/lapb_iface.c 2004-07-02 01:29:55.717667144 -0700 @@ -176,7 +176,7 @@ int lapb_unregister(struct net_device *d struct lapb_cb *lapb; int rc = LAPB_BADTOKEN; - write_unlock_bh(&lapb_list_lock); + write_lock_bh(&lapb_list_lock); lapb = __lapb_devtostruct(dev); if (!lapb) goto out; _ From akpm@osdl.org Fri Jul 2 01:47:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 01:47:36 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i628lXgi004814 for ; Fri, 2 Jul 2004 01:47:33 -0700 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i628lLG23044; Fri, 2 Jul 2004 01:47:22 -0700 Message-Id: <200407020847.i628lLG23044@mail.osdl.org> Subject: [patch 1/1] err2-15: ax25_rt_add() locking fix To: davem@redhat.com Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Fri, 02 Jul 2004 01:46:23 -0700 X-archive-position: 6508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev It can return with the lock held. Found by the Stanford locking checker Signed-off-by: Andrew Morton --- 25-akpm/net/ax25/ax25_route.c | 1 + 1 files changed, 1 insertion(+) diff -puN net/ax25/ax25_route.c~err2-15-ax25_rt_add-locking-fix net/ax25/ax25_route.c --- 25/net/ax25/ax25_route.c~err2-15-ax25_rt_add-locking-fix 2004-07-02 01:45:20.234119280 -0700 +++ 25-akpm/net/ax25/ax25_route.c 2004-07-02 01:45:37.960424472 -0700 @@ -122,6 +122,7 @@ static int ax25_rt_add(struct ax25_route ax25_rt->digipeat->calls[i] = route->digi_addr[i]; } } + write_unlock(&ax25_route_lock); return 0; } ax25_rt = ax25_rt->next; _ From yoshfuji@linux-ipv6.org Fri Jul 2 01:46:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 01:47:02 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i628kggi004691 for ; Fri, 2 Jul 2004 01:46:42 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 32CC033CE5; Fri, 2 Jul 2004 17:47:54 +0900 (JST) Date: Fri, 02 Jul 2004 17:47:53 +0900 (JST) Message-Id: <20040702.174753.93406678.yoshfuji@linux-ipv6.org> To: davem@redhat.com, yxie@cs.stanford.edu Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. In article (at Thu, 1 Jul 2004 18:01:00 -0700 (PDT)), Yichen Xie says: > http://glide.stanford.edu/linux-lock/err1.html (69 errors) : > err1.html consists of potential double locks/unlocks. Acquiring a lock > twice in a row may result in a system hang, and releasing a lock more than > once with certain mutex functions (e.g. up) may cause critical section > violations. Well, lapb_iface.c:lapb_unregister() has typo and we failed to get lapb_list_lock. rose_route.c:rose_remove_node()'s caller has rose_node_list_lock; so, this is dead lock. Here's the fix. ===== net/lapb/lapb_iface.c 1.14 vs edited ===== --- 1.14/net/lapb/lapb_iface.c 2004-01-11 08:39:04 +09:00 +++ edited/net/lapb/lapb_iface.c 2004-07-02 17:23:27 +09:00 @@ -176,7 +176,7 @@ struct lapb_cb *lapb; int rc = LAPB_BADTOKEN; - write_unlock_bh(&lapb_list_lock); + write_lock_bh(&lapb_list_lock); lapb = __lapb_devtostruct(dev); if (!lapb) goto out; ===== net/rose/rose_route.c 1.12 vs edited ===== --- 1.12/net/rose/rose_route.c 2004-06-04 09:11:24 +09:00 +++ edited/net/rose/rose_route.c 2004-07-02 17:26:08 +09:00 @@ -206,7 +206,6 @@ { struct rose_node *s; - spin_lock_bh(&rose_node_list_lock); if ((s = rose_node_list) == rose_node) { rose_node_list = rose_node->next; kfree(rose_node); Thanks. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Fri Jul 2 04:05:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 04:05:23 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62B58gi010685 for ; Fri, 2 Jul 2004 04:05:12 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BgLqo-00039p-00; Fri, 02 Jul 2004 21:05:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BgLql-00055X-00; Fri, 02 Jul 2004 21:04:59 +1000 From: Herbert Xu To: akpm@osdl.org (Andrew Morton) Subject: Re: Fw: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20040702004956.448c95d9.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Fri, 02 Jul 2004 21:04:59 +1000 X-archive-position: 6509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Andrew Morton wrote: > > Could someone please take a look at the locking in > net/ipv4/ipmr.c:ipmr_mfc_seq_next? It seems rather broken. Obfuscated yes, broken no. Unfortunately the seq interface tends to produce code like this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Jul 2 06:07:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 06:07:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62D77gi016628 for ; Fri, 2 Jul 2004 06:07:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BgNkm-0003uk-00; Fri, 02 Jul 2004 23:06:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BgNki-0005Ix-00; Fri, 02 Jul 2004 23:06:52 +1000 Date: Fri, 2 Jul 2004 23:06:52 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [AH4] Harmonisation of output function Message-ID: <20040702130652.GA20334@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is another step towards the union of the tunnel mode encapsulation between transforms. As there are significant differences between the tunnel encapsulation of IPv4 and IPv6, I'll be dealing with IPv4 only for now. This particular patch rearranges the code in ah_output to isolate the tunnel mode encapsulation. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/ah4.c 1.33 vs edited ===== --- 1.33/net/ipv4/ah4.c 2004-06-24 11:19:28 +10:00 +++ edited/net/ipv4/ah4.c 2004-07-02 22:53:20 +10:00 @@ -86,29 +86,23 @@ top_iph = (struct iphdr*)skb_push(*pskb, x->props.header_len); top_iph->ihl = 5; top_iph->version = 4; - top_iph->tos = 0; - top_iph->tot_len = htons((*pskb)->len); - top_iph->frag_off = 0; + top_iph->tos = iph->tos; + if (x->props.flags & XFRM_STATE_NOECN) + IP_ECN_clear(top_iph); + top_iph->frag_off = iph->frag_off & ~htons(IP_MF|IP_OFFSET); if (!(iph->frag_off&htons(IP_DF))) __ip_select_ident(top_iph, dst, 0); - top_iph->ttl = 0; - top_iph->protocol = IPPROTO_AH; - top_iph->check = 0; + top_iph->ttl = iph->ttl; top_iph->saddr = x->props.saddr.a4; top_iph->daddr = x->id.daddr.a4; + memcpy(&tmp_iph, top_iph, 20); + memset(&(IPCB(*pskb)->opt), 0, sizeof(struct ip_options)); ah = (struct ip_auth_hdr*)(top_iph+1); ah->nexthdr = IPPROTO_IPIP; } else { memcpy(&tmp_iph, (*pskb)->data, iph->ihl*4); top_iph = (struct iphdr*)skb_push(*pskb, x->props.header_len); memcpy(top_iph, &tmp_iph, iph->ihl*4); - iph = &tmp_iph.iph; - top_iph->tos = 0; - top_iph->tot_len = htons((*pskb)->len); - top_iph->frag_off = 0; - top_iph->ttl = 0; - top_iph->protocol = IPPROTO_AH; - top_iph->check = 0; if (top_iph->ihl != 5) { err = ip_clear_mutable_options(top_iph, &top_iph->daddr); if (err) @@ -117,6 +111,15 @@ ah = (struct ip_auth_hdr*)((char*)top_iph+iph->ihl*4); ah->nexthdr = iph->protocol; } + + iph = &tmp_iph.iph; + top_iph->tos = 0; + top_iph->tot_len = htons((*pskb)->len); + top_iph->frag_off = 0; + top_iph->ttl = 0; + top_iph->protocol = IPPROTO_AH; + top_iph->check = 0; + ahp = x->data; ah->hdrlen = (XFRM_ALIGN8(sizeof(struct ip_auth_hdr) + ahp->icv_trunc_len) >> 2) - 2; @@ -127,13 +130,8 @@ ahp->icv(ahp, *pskb, ah->auth_data); top_iph->tos = iph->tos; top_iph->ttl = iph->ttl; - if (x->props.mode) { - if (x->props.flags & XFRM_STATE_NOECN) - IP_ECN_clear(top_iph); - top_iph->frag_off = iph->frag_off&~htons(IP_MF|IP_OFFSET); - memset(&(IPCB(*pskb)->opt), 0, sizeof(struct ip_options)); - } else { - top_iph->frag_off = iph->frag_off; + top_iph->frag_off = iph->frag_off; + if (!x->props.mode) { top_iph->daddr = iph->daddr; if (iph->ihl != 5) memcpy(top_iph+1, iph+1, iph->ihl*4 - sizeof(struct iphdr)); --opJtzjQTFsWo+cga-- From jgarzik@pobox.com Fri Jul 2 08:51:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 08:52:07 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62Fpfgi023523 for ; Fri, 2 Jul 2004 08:51:42 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BgQKC-0006TM-NJ; Fri, 02 Jul 2004 16:51:40 +0100 Message-ID: <40E5847F.8030808@pobox.com> Date: Fri, 02 Jul 2004 11:51:27 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Gigabit Ethernet support for forcedeth References: <40E25328.8020102@colorfullife.com> <40E25944.8010200@pobox.com> <40E2E618.5020601@colorfullife.com> <40E30CA7.3020209@colorfullife.com> In-Reply-To: <40E30CA7.3020209@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Manfred Spraul wrote: > Attached is an incremental patch that fixes the simple issues you > mentioned. Could you merge both patches together to your tree? They > improve the driver significantly and I want some test input from users. I had already deleted the first patch :/ Can you resend patches with full descriptions, like you did with natsemi? Jeff From garzik@havoc.gtf.org Fri Jul 2 10:54:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 10:54:57 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62HsVgi026364 for ; Fri, 2 Jul 2004 10:54:31 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 162C07674; Fri, 2 Jul 2004 13:14:16 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i62HEFJ2017647; Fri, 2 Jul 2004 13:14:15 -0400 Date: Fri, 2 Jul 2004 13:14:15 -0400 From: Jeff Garzik To: Andrew Morton , Linus Torvalds Cc: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x net driver updates Message-ID: <20040702171415.GA17598@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 6513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/8139too.c | 2 +- drivers/net/arcnet/arcnet.c | 4 ++-- drivers/net/irda/Kconfig | 2 +- drivers/net/irda/donauboe.c | 4 ++++ drivers/net/rrunner.c | 8 ++++---- drivers/net/sk98lin/skge.c | 1 + drivers/net/tokenring/Kconfig | 2 +- drivers/net/tokenring/lanstreamer.c | 5 +++++ drivers/net/wireless/atmel_cs.c | 20 +++++++++++++++----- 9 files changed, 34 insertions(+), 14 deletions(-) through these ChangeSets: (04/07/02 1.1787) [PATCH] [Bug 2948] New: Atmel wireless driver Oopses (04/07/02 1.1786) [PATCH] err2-14: skge locking fix It can return with the lock held. Found by the Stanford locking checker. Signed-off-by: Andrew Morton (04/07/01 1.1778.4.25) [netdrvr] fix warnings found on 64-bit platforms Updated: 8139too, arcnet/arcnet, rrunner (04/07/01 1.1778.4.24) [netdrvr] disable certain drivers that are broken on 64-bit Disable Toshiba FIR IRDA driver (donauboe) and IBM Lanstreamer token ring driver on all 64-bit platforms. Add #error to each driver explaining the problem, causing build of driver to fail when BITS_PER_LONG == 64. diff -Nru a/drivers/net/8139too.c b/drivers/net/8139too.c --- a/drivers/net/8139too.c 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/8139too.c 2004-07-02 13:13:12 -04:00 @@ -777,7 +777,7 @@ u8 tmp8; int rc; unsigned int i; - u32 pio_start, pio_end, pio_flags, pio_len; + unsigned long pio_start, pio_end, pio_flags, pio_len; unsigned long mmio_start, mmio_end, mmio_flags, mmio_len; u32 version; diff -Nru a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c --- a/drivers/net/arcnet/arcnet.c 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/arcnet/arcnet.c 2004-07-02 13:13:12 -04:00 @@ -479,7 +479,7 @@ *(uint16_t *) skb_push(skb, 2) = type; if (skb->nh.raw - skb->mac.raw != 2) BUGMSG(D_NORMAL, "arcnet_header: Yikes! diff (%d) is not 2!\n", - skb->nh.raw - skb->mac.raw); + (int)(skb->nh.raw - skb->mac.raw)); return -2; /* return error -- can't transmit yet! */ } /* otherwise, we can just add the header as usual. */ @@ -514,7 +514,7 @@ if (skb->nh.raw - skb->mac.raw != 2) { BUGMSG(D_NORMAL, "rebuild_header: shouldn't be here! (hdrsize=%d)\n", - skb->nh.raw - skb->mac.raw); + (int)(skb->nh.raw - skb->mac.raw)); return 0; } type = *(uint16_t *) skb_pull(skb, 2); diff -Nru a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig --- a/drivers/net/irda/Kconfig 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/irda/Kconfig 2004-07-02 13:13:12 -04:00 @@ -333,7 +333,7 @@ config TOSHIBA_FIR tristate "Toshiba Type-O IR Port" - depends on IRDA + depends on IRDA && !64BIT help Say Y here if you want to build support for the Toshiba Type-O IR and Donau oboe chipsets. These chipsets are used by the Toshiba diff -Nru a/drivers/net/irda/donauboe.c b/drivers/net/irda/donauboe.c --- a/drivers/net/irda/donauboe.c 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/irda/donauboe.c 2004-07-02 13:13:12 -04:00 @@ -1622,6 +1622,10 @@ goto freeregion; } +#if (BITS_PER_LONG == 64) +#error broken on 64-bit: casts pointer to 32-bit, and then back to pointer. +#endif + /*We need to align the taskfile on a taskfile size boundary */ { unsigned long addr; diff -Nru a/drivers/net/rrunner.c b/drivers/net/rrunner.c --- a/drivers/net/rrunner.c 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/rrunner.c 2004-07-02 13:13:12 -04:00 @@ -1335,10 +1335,10 @@ if (rrpriv->tx_skbuff[cons]){ len = min_t(int, 0x80, rrpriv->tx_skbuff[cons]->len); printk("skbuff for cons %i is valid - dumping data (0x%x bytes - skbuff len 0x%x)\n", cons, len, rrpriv->tx_skbuff[cons]->len); - printk("mode 0x%x, size 0x%x,\n phys %08x, skbuff-addr %08lx, truesize 0x%x\n", + printk("mode 0x%x, size 0x%x,\n phys %08Lx, skbuff-addr %08lx, truesize 0x%x\n", rrpriv->tx_ring[cons].mode, rrpriv->tx_ring[cons].size, - rrpriv->tx_ring[cons].addr.addrlo, + (unsigned long long) rrpriv->tx_ring[cons].addr.addrlo, (unsigned long)rrpriv->tx_skbuff[cons]->data, (unsigned int)rrpriv->tx_skbuff[cons]->truesize); for (i = 0; i < len; i++){ @@ -1351,10 +1351,10 @@ printk("dumping TX ring info:\n"); for (i = 0; i < TX_RING_ENTRIES; i++) - printk("mode 0x%x, size 0x%x, phys-addr %08x\n", + printk("mode 0x%x, size 0x%x, phys-addr %08Lx\n", rrpriv->tx_ring[i].mode, rrpriv->tx_ring[i].size, - rrpriv->tx_ring[i].addr.addrlo); + (unsigned long long) rrpriv->tx_ring[i].addr.addrlo); } diff -Nru a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c --- a/drivers/net/sk98lin/skge.c 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/sk98lin/skge.c 2004-07-02 13:13:12 -04:00 @@ -1927,6 +1927,7 @@ */ if (BytesSend < C_LEN_ETHERNET_MINSIZE) { if ((pMessage = skb_padto(pMessage, C_LEN_ETHERNET_MINSIZE)) == NULL) { + spin_unlock_irqrestore(&pTxPort->TxDesRingLock, Flags); return 0; } pMessage->len = C_LEN_ETHERNET_MINSIZE; diff -Nru a/drivers/net/tokenring/Kconfig b/drivers/net/tokenring/Kconfig --- a/drivers/net/tokenring/Kconfig 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/tokenring/Kconfig 2004-07-02 13:13:12 -04:00 @@ -54,7 +54,7 @@ config IBMLS tristate "IBM Lanstreamer chipset PCI adapter support" - depends on TR && PCI + depends on TR && PCI && !64BIT help This is support for IBM Lanstreamer PCI Token Ring Cards. diff -Nru a/drivers/net/tokenring/lanstreamer.c b/drivers/net/tokenring/lanstreamer.c --- a/drivers/net/tokenring/lanstreamer.c 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/tokenring/lanstreamer.c 2004-07-02 13:13:12 -04:00 @@ -129,6 +129,11 @@ #include "lanstreamer.h" +#if (BITS_PER_LONG == 64) +#error broken on 64-bit: stores pointer to rx_ring->buffer in 32-bit int +#endif + + /* I've got to put some intelligence into the version number so that Peter and I know * which version of the code somebody has got. * Version Number = a.b.c.d where a.b.c is the level of code and d is the latest author. diff -Nru a/drivers/net/wireless/atmel_cs.c b/drivers/net/wireless/atmel_cs.c --- a/drivers/net/wireless/atmel_cs.c 2004-07-02 13:13:12 -04:00 +++ b/drivers/net/wireless/atmel_cs.c 2004-07-02 13:13:12 -04:00 @@ -348,9 +348,19 @@ }; /* This is strictly temporary, until PCMCIA devices get integrated into the device model. */ -static struct device atmel_device = { - .bus_id = "pcmcia", -}; +static struct device *atmel_device(void) +{ + static char *kobj_name = "atmel_cs"; + + static struct device dev = { + .bus_id = "pcmcia", + }; + dev.kobj.k_name = kmalloc(strlen(kobj_name)+1, GFP_KERNEL); + strcpy(dev.kobj.k_name, kobj_name); + kobject_init(&dev.kobj); + + return &dev; +} static void atmel_config(dev_link_t *link) { @@ -537,12 +547,12 @@ "atmel: cannot assign IRQ: check that CONFIG_ISA is set in kernel config."); goto cs_failed; } - + ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, card_index == -1 ? NULL : card_table[card_index].firmware, - &atmel_device, + atmel_device(), card_present, link); if (!((local_info_t*)link->priv)->eth_dev) From niv@us.ibm.com Fri Jul 2 10:54:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 10:54:20 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62Hs7gi026319 for ; Fri, 2 Jul 2004 10:54:16 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i62HrpZK663482; Fri, 2 Jul 2004 13:53:51 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i62HrnQj387122; Fri, 2 Jul 2004 11:53:50 -0600 Message-ID: <40E5A1B3.2020202@us.ibm.com> Date: Fri, 02 Jul 2004 10:56:03 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Morris , akpm@osdl.org CC: netdev , christophe@saout.de Subject: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev James, Andrew, Looks like deflate_comp_init() is not calling __vmalloc in a kosher way. We are not in softirq, so deflate_gfp() is going to return GFP_KERNEL, so this is essentially __vmalloc() with GFP_KERNEL|__GFP_HIGHMEM, PAGE_KERNEL. Should we be using __vmalloc here, or is this a vm issue? thanks, Nivedita -------- Original Message -------- Subject: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP Date: Fri, 2 Jul 2004 10:32:44 -0700 From: bugme-daemon@osdl.org To: niv@us.ibm.com http://bugme.osdl.org/show_bug.cgi?id=3003 Summary: might_sleep warning when setting up IPSec with IPCOMP Kernel Version: 2.6.7 Status: NEW Severity: normal Owner: niv@us.ibm.com Submitter: christophe@saout.de CC: christophe@saout.de Linux 2.6.7 on x86, UP preempt Using OpenSWAN for IPSec tunnel with IP-Compression enabled. Often gives the following warning shortly after a connection has been set up: I'm not exactly sure whether this is cryptoapi or the compression module or IPCOMP's fault. Jul 2 18:39:04 websrv Debug: sleeping function called from invalid context at mm/slab.c:1994 Jul 2 18:39:04 websrv in_atomic():1, irqs_disabled():0 Jul 2 18:39:04 websrv [] dump_stack+0x17/0x20 Jul 2 18:39:04 websrv [] __might_sleep+0xb4/0xe0 Jul 2 18:39:04 websrv [] kmem_cache_alloc+0x5c/0x60 Jul 2 18:39:04 websrv [] __get_vm_area+0x20/0xf0 Jul 2 18:39:04 websrv [] get_vm_area+0x24/0x30 Jul 2 18:39:04 websrv [] __vmalloc+0x3c/0x100 Jul 2 18:39:04 websrv [] deflate_comp_init+0x4a/0xf0 Jul 2 18:39:04 websrv [] deflate_compress+0x24/0x80 Jul 2 18:39:04 websrv [] crypto_compress+0x24/0x30 Jul 2 18:39:04 websrv [] ipcomp_compress+0x6c/0x110 Jul 2 18:39:04 websrv [] ipcomp_output+0xc1/0x370 Jul 2 18:39:04 websrv [] dst_output+0xe/0x30 Jul 2 18:39:04 websrv [] nf_hook_slow+0xfa/0x170 Jul 2 18:39:04 websrv [] ip_queue_xmit+0x452/0x540 Jul 2 18:39:04 websrv [] tcp_transmit_skb+0x3ef/0x660 Jul 2 18:39:04 websrv [] tcp_write_xmit+0x15b/0x2c0 Jul 2 18:39:04 websrv [] tcp_sendmsg+0x4e5/0x1030 Jul 2 18:39:04 websrv [] inet_sendmsg+0x47/0x60 Jul 2 18:39:04 websrv [] sock_aio_write+0xae/0xd0 Jul 2 18:39:04 websrv [] do_sync_write+0x76/0xb0 Jul 2 18:39:04 websrv [] vfs_write+0xcb/0xf0 Jul 2 18:39:04 websrv [] sys_write+0x35/0x60 Jul 2 18:39:04 websrv [] sysenter_past_esp+0x52/0x71 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From christophe@saout.de Fri Jul 2 10:58:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 10:58:44 -0700 (PDT) Received: from websrv.werbeagentur-aufwind.de (websrv.werbeagentur-aufwind.de [213.239.197.241]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62Hwegi026980 for ; Fri, 2 Jul 2004 10:58:40 -0700 Received: (qmail 10804 invoked by uid 1003); 2 Jul 2004 19:58:39 +0200 Received: from christophe@saout.de by websrv.werbeagentur-aufwind.de by uid 201 with qmail-scanner-1.20 (clamuko: 0.73. spamassassin: 2.63. Clear:RC:0(80.131.186.206):SA:0(-0.9/6.0):. Processed in 2.140429 secs); 02 Jul 2004 17:58:39 -0000 Received: from p5083bace.dip.t-dialin.net (HELO mail.cs.pocnet.net) (smtp@werbeagentur-aufwind.de@80.131.186.206) by websrv.werbeagentur-aufwind.de with AES256-SHA encrypted SMTP; 2 Jul 2004 19:58:36 +0200 Received: (qmail 11873 invoked from network); 2 Jul 2004 19:58:33 +0200 Received: from leto.cs.pocnet.net (192.168.80.6) by server.cs.pocnet.net with RC4-MD5 encrypted SMTP; 2 Jul 2004 19:58:33 +0200 Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] From: Christophe Saout To: Nivedita Singhvi Cc: James Morris , akpm@osdl.org, netdev In-Reply-To: <40E5A1B3.2020202@us.ibm.com> References: <40E5A1B3.2020202@us.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UfxZsYW81H+P/zsMcMNm" Date: Fri, 02 Jul 2004 19:58:32 +0200 Message-Id: <1088791112.2085.4.camel@leto.cs.pocnet.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 X-archive-position: 6514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christophe@saout.de Precedence: bulk X-list: netdev --=-UfxZsYW81H+P/zsMcMNm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Fr, den 02.07.2004 um 10:56 Uhr -0700 schrieb Nivedita Singhvi: > Looks like deflate_comp_init() is not calling > __vmalloc in a kosher way. > > [...] > Jul 2 18:39:04 websrv [] kmem_cache_alloc+0x5c/0x60 > Jul 2 18:39:04 websrv [] __get_vm_area+0x20/0xf0 > Jul 2 18:39:04 websrv [] get_vm_area+0x24/0x30 > Jul 2 18:39:04 websrv [] __vmalloc+0x3c/0x100 > [...] __get_vm_area does a area =3D kmalloc(sizeof(*area), GFP_KERNEL); So it will produce a warning no matter what flags are passed to __vmalloc. --=-UfxZsYW81H+P/zsMcMNm Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA5aJIZCYBcts5dM0RAlcfAJ92Fy+O5RmW4kE1PgLJYaQjg+Q/0ACgrXl4 w4jVpG55UVBnTV/wDspsCXE= =L3aE -----END PGP SIGNATURE----- --=-UfxZsYW81H+P/zsMcMNm-- From olh@suse.de Fri Jul 2 11:17:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 11:18:08 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62IHpgi027713 for ; Fri, 2 Jul 2004 11:17:52 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 59D3F8347F1; Fri, 2 Jul 2004 20:17:45 +0200 (CEST) Date: Fri, 2 Jul 2004 20:17:44 +0200 From: Olaf Hering To: cramerj@intel.com, netdev@oss.sgi.com Subject: [PATCH] pass unsgined long to udelay in e1000 Message-ID: <20040702181744.GA18546@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i62IHpgi027713 X-archive-position: 6515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev I get these warnings on ppc32 due to the check in udelay() macro. Is it safe to move the struct member? CC [M] drivers/net/e1000/e1000_hw.o drivers/net/e1000/e1000_hw.c: In function `e1000_raise_ee_clk': drivers/net/e1000/e1000_hw.c:3122: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c: In function `e1000_lower_ee_clk': drivers/net/e1000/e1000_hw.c:3141: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c: In function `e1000_shift_out_ee_bits': drivers/net/e1000/e1000_hw.c:3185: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c: In function `e1000_standby_eeprom': drivers/net/e1000/e1000_hw.c:3314: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c:3320: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c:3326: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c:3332: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c:3338: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c:3342: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c: In function `e1000_release_eeprom': drivers/net/e1000/e1000_hw.c:3366: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c:3379: warning: comparison is always false due to limited range of data type drivers/net/e1000/e1000_hw.c:3385: warning: comparison is always false due to limited range of data type patch is against 2.6.7-bk15 --- ./drivers/net/e1000/e1000_hw.h +++ ./drivers/net/e1000/e1000_hw.h 2004/07/02 18:07:28 @@ -234,8 +234,8 @@ struct e1000_eeprom_info { uint16_t word_size; uint16_t opcode_bits; uint16_t address_bits; - uint16_t delay_usec; uint16_t page_size; + unsigned long delay_usec; }; -- USB is for mice, FireWire is for men! sUse lINUX ag, nÃœRNBERG From dcbw@redhat.com Fri Jul 2 12:11:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 12:11:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62JBggi029513 for ; Fri, 2 Jul 2004 12:11:42 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i62JBfe1008122; Fri, 2 Jul 2004 15:11:41 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i62JBe018954; Fri, 2 Jul 2004 15:11:41 -0400 Received: from [172.16.65.83] (dcbw.boston.redhat.com [172.16.65.83]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i62JBc4F006174; Fri, 2 Jul 2004 15:11:38 -0400 Subject: [PATCH] Update in-kernel orinoco drivers to upstream current CVS From: Dan Williams To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Content-Type: text/plain Date: Fri, 02 Jul 2004 15:11:38 -0400 Message-Id: <1088795498.18039.25.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.2 (1.5.9.2-1) Content-Transfer-Encoding: 7bit X-archive-position: 6516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Hi, This patch is simply the fixed-up diff between the kernel's current 0.13e version and the upstream 0.15rc1+ version from savannah CVS. 0.15rc1 has been out for a couple months now and seems stable. The major benefits that this newer version brings are, of course, many bugfixes, but best of all wireless scanning support for the Orinoco line of cards. http://people.redhat.com/dcbw/linux-2.6.7-orinoco.patch.bz2 Dan Williams Red Hat, Inc. From jgarzik@pobox.com Fri Jul 2 12:15:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 12:15:50 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62JFlgi029874 for ; Fri, 2 Jul 2004 12:15:48 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BgTVi-0002LQ-CG; Fri, 02 Jul 2004 20:15:46 +0100 Message-ID: <40E5B450.9050601@pobox.com> Date: Fri, 02 Jul 2004 15:15:28 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev , Andrew Morton Subject: netdev-2.6 queue refreshed Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev I just refreshed and re-merged the netdev-2.6 queue. Everybody following the BK queue bk://gkernel.bkbits.net/netdev-2.6 (or its mirror bk://kernel.bkbits.net/jgarzik/netdev-2.6), please remove and re-clone your repository. Jeff From manfred@colorfullife.com Fri Jul 2 12:29:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 12:29:54 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62JTggi001143 for ; Fri, 2 Jul 2004 12:29:43 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i62JTZLw018532; Fri, 2 Jul 2004 21:29:36 +0200 Message-ID: <40E5B788.80302@colorfullife.com> Date: Fri, 02 Jul 2004 21:29:12 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Gigabit Ethernet support for forcedeth References: <40E25328.8020102@colorfullife.com> <40E25944.8010200@pobox.com> <40E2E618.5020601@colorfullife.com> <40E30CA7.3020209@colorfullife.com> <40E5847F.8030808@pobox.com> In-Reply-To: <40E5847F.8030808@pobox.com> Content-Type: multipart/mixed; boundary="------------040907050803020100060100" X-archive-position: 6518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040907050803020100060100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeff Garzik wrote: > Can you resend patches with full descriptions, like you did with natsemi? > Changelog: - Lots of updates for the gigabit ethernet nic: New ring entry format, support for RGMII phys, new pci ids. - Silence interrupt source 0x01: it's rx error, no need to ask the end user to report it. - add support for vlan packets: The NvRegOffloadConfig register contains the maximum packet size, it was set to 1518 which caused vlan to fail. - fix bit flags for mii access: the wrong bit was polled and the mii write implementation was just broken. - Do not stop the rx/tx engines around mii accesses. - reset and reinit the phy during probe. -- Manfred --------------040907050803020100060100 Content-Type: text/plain; name="patch-forcedeth-gige-all" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forcedeth-gige-all" // $Header$ // Kernel Version: // VERSION = 2 // PATCHLEVEL = 6 // SUBLEVEL = 7 // EXTRAVERSION = -mm5 --- 2.6/drivers/net/forcedeth.c 2004-07-01 07:23:15.000000000 +0200 +++ build-2.6/drivers/net/forcedeth.c 2004-07-01 07:06:52.000000000 +0200 @@ -10,8 +10,11 @@ * trademarks of NVIDIA Corporation in the United States and other * countries. * - * Copyright (C) 2003 Manfred Spraul + * Copyright (C) 2003,4 Manfred Spraul * Copyright (C) 2004 Andrew de Quincey (wol support) + * Copyright (C) 2004 Carl-Daniel Hailfinger (invalid MAC handling, insane + * IRQ rate fixes, bigendian fixes, cleanups, verification) + * Copyright (c) 2004 NVIDIA Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -60,15 +63,18 @@ * 0.19: 29 Nov 2003: Handle RxNoBuf, detect & handle invalid mac * addresses, really stop rx if already running * in nv_start_rx, clean up a bit. - * (C) Carl-Daniel Hailfinger * 0.20: 07 Dec 2003: alloc fixes * 0.21: 12 Jan 2004: additional alloc fix, nic polling fix. * 0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup - * on close. - * (C) Carl-Daniel Hailfinger, Manfred Spraul + * on close. * 0.23: 26 Jan 2004: various small cleanups * 0.24: 27 Feb 2004: make driver even less anonymous in backtraces * 0.25: 09 Mar 2004: wol support + * 0.26: 03 Jun 2004: netdriver specific annotation, sparse-related fixes + * 0.27: 19 Jun 2004: Gigabit support, new descriptor rings, + * added CK804/MCP04 device IDs, code fixes + * for registers, link status and other minor fixes. + * 0.28: 21 Jun 2004: Big cleanup, making driver mostly endian safe * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -80,7 +86,7 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.25" +#define FORCEDETH_VERSION "0.28" #define DRV_NAME "forcedeth" #include @@ -124,6 +130,7 @@ enum { #define NVREG_IRQSTAT_MIIEVENT 0x040 #define NVREG_IRQSTAT_MASK 0x1ff NvRegIrqMask = 0x004, +#define NVREG_IRQ_RX_ERROR 0x0001 #define NVREG_IRQ_RX 0x0002 #define NVREG_IRQ_RX_NOBUF 0x0004 #define NVREG_IRQ_TX_ERR 0x0008 @@ -133,7 +140,7 @@ enum { #define NVREG_IRQ_TX1 0x0100 #define NVREG_IRQMASK_WANTED_1 0x005f #define NVREG_IRQMASK_WANTED_2 0x0147 -#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) +#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) NvRegUnknownSetupReg6 = 0x008, #define NVREG_UNKSETUP6_VAL 3 @@ -160,7 +167,7 @@ enum { NvRegOffloadConfig = 0x90, #define NVREG_OFFLOAD_HOMEPHY 0x601 -#define NVREG_OFFLOAD_NORMAL 0x5ee +#define NVREG_OFFLOAD_NORMAL RX_NIC_BUFSIZE NvRegReceiverControl = 0x094, #define NVREG_RCVCTL_START 0x01 NvRegReceiverStatus = 0x98, @@ -169,6 +176,8 @@ enum { NvRegRandomSeed = 0x9c, #define NVREG_RNDSEED_MASK 0x00ff #define NVREG_RNDSEED_FORCE 0x7f00 +#define NVREG_RNDSEED_FORCE2 0x2d00 +#define NVREG_RNDSEED_FORCE3 0x7400 NvRegUnknownSetupReg1 = 0xA0, #define NVREG_UNKSETUP1_VAL 0x16070f @@ -182,6 +191,9 @@ enum { NvRegMulticastMaskA = 0xB8, NvRegMulticastMaskB = 0xBC, + NvRegPhyInterface = 0xC0, +#define PHY_RGMII 0x10000000 + NvRegTxRingPhysAddr = 0x100, NvRegRxRingPhysAddr = 0x104, NvRegRingSizes = 0x108, @@ -190,12 +202,12 @@ enum { NvRegUnknownTransmitterReg = 0x10c, NvRegLinkSpeed = 0x110, #define NVREG_LINKSPEED_FORCE 0x10000 -#define NVREG_LINKSPEED_10 10 +#define NVREG_LINKSPEED_10 1000 #define NVREG_LINKSPEED_100 100 -#define NVREG_LINKSPEED_1000 1000 +#define NVREG_LINKSPEED_1000 50 NvRegUnknownSetupReg5 = 0x130, #define NVREG_UNKSETUP5_BIT31 (1<<31) - NvRegUnknownSetupReg3 = 0x134, + NvRegUnknownSetupReg3 = 0x13c, #define NVREG_UNKSETUP3_VAL1 0x200010 NvRegTxRxControl = 0x144, #define NVREG_TXRXCTL_KICK 0x0001 @@ -214,15 +226,15 @@ enum { NvRegAdapterControl = 0x188, #define NVREG_ADAPTCTL_START 0x02 #define NVREG_ADAPTCTL_LINKUP 0x04 -#define NVREG_ADAPTCTL_PHYVALID 0x4000 +#define NVREG_ADAPTCTL_PHYVALID 0x40000 #define NVREG_ADAPTCTL_RUNNING 0x100000 #define NVREG_ADAPTCTL_PHYSHIFT 24 NvRegMIISpeed = 0x18c, #define NVREG_MIISPEED_BIT8 (1<<8) #define NVREG_MIIDELAY 5 NvRegMIIControl = 0x190, -#define NVREG_MIICTL_INUSE 0x10000 -#define NVREG_MIICTL_WRITE 0x08000 +#define NVREG_MIICTL_INUSE 0x08000 +#define NVREG_MIICTL_WRITE 0x00400 #define NVREG_MIICTL_ADDRSHIFT 5 NvRegMIIData = 0x194, NvRegWakeUpFlags = 0x200, @@ -254,34 +266,63 @@ enum { #define NVREG_POWERSTATE_D3 0x0003 }; +/* Big endian: should work, but is untested */ struct ring_desc { u32 PacketBuffer; - u16 Length; - u16 Flags; + u32 FlagLen; }; -#define NV_TX_LASTPACKET (1<<0) -#define NV_TX_RETRYERROR (1<<3) -#define NV_TX_LASTPACKET1 (1<<8) -#define NV_TX_DEFERRED (1<<10) -#define NV_TX_CARRIERLOST (1<<11) -#define NV_TX_LATECOLLISION (1<<12) -#define NV_TX_UNDERFLOW (1<<13) -#define NV_TX_ERROR (1<<14) -#define NV_TX_VALID (1<<15) - -#define NV_RX_DESCRIPTORVALID (1<<0) -#define NV_RX_MISSEDFRAME (1<<1) -#define NV_RX_SUBSTRACT1 (1<<3) -#define NV_RX_ERROR1 (1<<7) -#define NV_RX_ERROR2 (1<<8) -#define NV_RX_ERROR3 (1<<9) -#define NV_RX_ERROR4 (1<<10) -#define NV_RX_CRCERR (1<<11) -#define NV_RX_OVERFLOW (1<<12) -#define NV_RX_FRAMINGERR (1<<13) -#define NV_RX_ERROR (1<<14) -#define NV_RX_AVAIL (1<<15) +#define FLAG_MASK_V1 0xffff0000 +#define FLAG_MASK_V2 0xffffc000 +#define LEN_MASK_V1 (0xffffffff ^ FLAG_MASK_V1) +#define LEN_MASK_V2 (0xffffffff ^ FLAG_MASK_V2) + +#define NV_TX_LASTPACKET (1<<16) +#define NV_TX_RETRYERROR (1<<19) +#define NV_TX_LASTPACKET1 (1<<24) +#define NV_TX_DEFERRED (1<<26) +#define NV_TX_CARRIERLOST (1<<27) +#define NV_TX_LATECOLLISION (1<<28) +#define NV_TX_UNDERFLOW (1<<29) +#define NV_TX_ERROR (1<<30) +#define NV_TX_VALID (1<<31) + +#define NV_TX2_LASTPACKET (1<<29) +#define NV_TX2_RETRYERROR (1<<18) +#define NV_TX2_LASTPACKET1 (1<<23) +#define NV_TX2_DEFERRED (1<<25) +#define NV_TX2_CARRIERLOST (1<<26) +#define NV_TX2_LATECOLLISION (1<<27) +#define NV_TX2_UNDERFLOW (1<<28) +/* error and valid are the same for both */ +#define NV_TX2_ERROR (1<<30) +#define NV_TX2_VALID (1<<31) + +#define NV_RX_DESCRIPTORVALID (1<<16) +#define NV_RX_MISSEDFRAME (1<<17) +#define NV_RX_SUBSTRACT1 (1<<18) +#define NV_RX_ERROR1 (1<<23) +#define NV_RX_ERROR2 (1<<24) +#define NV_RX_ERROR3 (1<<25) +#define NV_RX_ERROR4 (1<<26) +#define NV_RX_CRCERR (1<<27) +#define NV_RX_OVERFLOW (1<<28) +#define NV_RX_FRAMINGERR (1<<29) +#define NV_RX_ERROR (1<<30) +#define NV_RX_AVAIL (1<<31) + +#define NV_RX2_DESCRIPTORVALID (1<<29) +#define NV_RX2_SUBSTRACT1 (1<<25) +#define NV_RX2_ERROR1 (1<<18) +#define NV_RX2_ERROR2 (1<<19) +#define NV_RX2_ERROR3 (1<<20) +#define NV_RX2_ERROR4 (1<<21) +#define NV_RX2_CRCERR (1<<22) +#define NV_RX2_OVERFLOW (1<<23) +#define NV_RX2_FRAMINGERR (1<<24) +/* error and avail are the same for both */ +#define NV_RX2_ERROR (1<<30) +#define NV_RX2_AVAIL (1<<31) /* Miscelaneous hardware related defines: */ #define NV_PCI_REGSZ 0x270 @@ -307,28 +348,66 @@ struct ring_desc { /* General driver defaults */ #define NV_WATCHDOG_TIMEO (5*HZ) -#define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ #define RX_RING 128 -#define TX_RING 16 -/* limited to 1 packet until we understand NV_TX_LASTPACKET */ -#define TX_LIMIT_STOP 10 -#define TX_LIMIT_START 5 +#define TX_RING 64 +/* + * If your nic mysteriously hangs then try to reduce the limits + * to 1/0: It might be required to set NV_TX_LASTPACKET in the + * last valid ring entry. But this would be impossible to + * implement - probably a disassembly error. + */ +#define TX_LIMIT_STOP 63 +#define TX_LIMIT_START 62 /* rx/tx mac addr + type + vlan + align + slack*/ -#define RX_NIC_BUFSIZE (DEFAULT_MTU + 64) +#define RX_NIC_BUFSIZE (ETH_DATA_LEN + 64) /* even more slack */ -#define RX_ALLOC_BUFSIZE (DEFAULT_MTU + 128) +#define RX_ALLOC_BUFSIZE (ETH_DATA_LEN + 128) #define OOM_REFILL (1+HZ/20) #define POLL_WAIT (1+HZ/100) +#define DESC_VER_1 0x0 +#define DESC_VER_2 0x02100 + +/* PHY defines */ +#define PHY_OUI_MARVELL 0x5043 +#define PHY_OUI_CICADA 0x03f1 +#define PHYID1_OUI_MASK 0x03ff +#define PHYID1_OUI_SHFT 6 +#define PHYID2_OUI_MASK 0xfc00 +#define PHYID2_OUI_SHFT 10 +#define PHY_INIT1 0x0f000 +#define PHY_INIT2 0x0e00 +#define PHY_INIT3 0x01000 +#define PHY_INIT4 0x0200 +#define PHY_INIT5 0x0004 +#define PHY_INIT6 0x02000 +#define PHY_GIGABIT 0x0100 + +#define PHY_TIMEOUT 0x1 +#define PHY_ERROR 0x2 + +#define PHY_100 0x1 +#define PHY_1000 0x2 +#define PHY_HALF 0x100 + +/* FIXME: MII defines that should be added to */ +#define MII_1000BT_CR 0x09 +#define MII_1000BT_SR 0x0a +#define ADVERTISE_1000FULL 0x0200 +#define ADVERTISE_1000HALF 0x0100 +#define LPA_1000FULL 0x0800 +#define LPA_1000HALF 0x0400 + + /* * SMP locking: * All hardware access under dev->priv->lock, except the performance * critical parts: * - rx is (pseudo-) lockless: it relies on the single-threading provided - * by the arch code for interrupts. + * by the arch code for interrupts. * - tx setup is lockless: it relies on dev->xmit_lock. Actual submission * needs dev->priv->lock :-( * - set_multicast_list: preparation lockless, relies on dev->xmit_lock. @@ -346,12 +425,15 @@ struct fe_priv { int duplex; int phyaddr; int wolenabled; + unsigned int phy_oui; + u16 gigabit; /* General data: RO fields */ dma_addr_t ring_addr; struct pci_dev *pci_dev; u32 orig_mac[2]; u32 irqmask; + u32 desc_ver; /* rx specific fields. * Locking: Within irq hander or disable_irq+spin_lock(&np->lock); @@ -371,7 +453,7 @@ struct fe_priv { unsigned int next_tx, nic_tx; struct sk_buff *tx_skbuff[TX_RING]; dma_addr_t tx_dma[TX_RING]; - u16 tx_flags; + u32 tx_flags; }; /* @@ -396,6 +478,12 @@ static inline void pci_push(u8 * base) readl(base); } +static inline u32 nv_descr_getlength(struct ring_desc *prd, u32 v) +{ + return le32_to_cpu(prd->FlagLen) + & ((v == DESC_VER_1) ? LEN_MASK_V1 : LEN_MASK_V2); +} + static int reg_delay(struct net_device *dev, int offset, u32 mask, u32 target, int delay, int delaymax, const char *msg) { @@ -422,24 +510,18 @@ static int reg_delay(struct net_device * static int mii_rw(struct net_device *dev, int addr, int miireg, int value) { u8 *base = get_hwbase(dev); - int was_running; u32 reg; int retval; writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); - was_running = 0; - reg = readl(base + NvRegAdapterControl); - if (reg & NVREG_ADAPTCTL_RUNNING) { - was_running = 1; - writel(reg & ~NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); - } + reg = readl(base + NvRegMIIControl); if (reg & NVREG_MIICTL_INUSE) { writel(NVREG_MIICTL_INUSE, base + NvRegMIIControl); udelay(NV_MIIBUSY_DELAY); } - reg = NVREG_MIICTL_INUSE | (addr << NVREG_MIICTL_ADDRSHIFT) | miireg; + reg = (addr << NVREG_MIICTL_ADDRSHIFT) | miireg; if (value != MII_READ) { writel(value, base + NvRegMIIData); reg |= NVREG_MIICTL_WRITE; @@ -461,19 +543,117 @@ static int mii_rw(struct net_device *dev dev->name, miireg, addr); retval = -1; } else { - /* FIXME: why is that required? */ - udelay(50); retval = readl(base + NvRegMIIData); dprintk(KERN_DEBUG "%s: mii_rw read from reg %d at PHY %d: 0x%x.\n", dev->name, miireg, addr, retval); } - if (was_running) { - reg = readl(base + NvRegAdapterControl); - writel(reg | NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); - } + return retval; } +static int phy_reset(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u32 miicontrol; + unsigned int tries = 0; + + miicontrol = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ); + miicontrol |= BMCR_RESET; + if (mii_rw(dev, np->phyaddr, MII_BMCR, miicontrol)) { + return -1; + } + + /* wait for 500ms */ + msleep(500); + + /* must wait till reset is deasserted */ + while (miicontrol & BMCR_RESET) { + msleep(10); + miicontrol = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ); + /* FIXME: 100 tries seem excessive */ + if (tries++ > 100) + return -1; + } + return 0; +} + +static int phy_init(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + u32 phyinterface, phy_reserved, mii_status, mii_control, mii_control_1000,reg; + + /* set advertise register */ + reg = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ); + reg |= (ADVERTISE_10HALF|ADVERTISE_10FULL|ADVERTISE_100HALF|ADVERTISE_100FULL|0x800|0x400); + if (mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg)) { + printk(KERN_INFO "%s: phy write to advertise failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + + /* get phy interface type */ + phyinterface = readl(base + NvRegPhyInterface); + + /* see if gigabit phy */ + mii_status = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + if (mii_status & PHY_GIGABIT) { + np->gigabit = PHY_GIGABIT; + mii_control_1000 = mii_rw(dev, np->phyaddr, MII_1000BT_CR, MII_READ); + mii_control_1000 &= ~ADVERTISE_1000HALF; + if (phyinterface & PHY_RGMII) + mii_control_1000 |= ADVERTISE_1000FULL; + else + mii_control_1000 &= ~ADVERTISE_1000FULL; + + if (mii_rw(dev, np->phyaddr, MII_1000BT_CR, mii_control_1000)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + } + else + np->gigabit = 0; + + /* reset the phy */ + if (phy_reset(dev)) { + printk(KERN_INFO "%s: phy reset failed\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + + /* phy vendor specific configuration */ + if ((np->phy_oui == PHY_OUI_CICADA) && (phyinterface & PHY_RGMII) ) { + phy_reserved = mii_rw(dev, np->phyaddr, MII_RESV1, MII_READ); + phy_reserved &= ~(PHY_INIT1 | PHY_INIT2); + phy_reserved |= (PHY_INIT3 | PHY_INIT4); + if (mii_rw(dev, np->phyaddr, MII_RESV1, phy_reserved)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + phy_reserved = mii_rw(dev, np->phyaddr, MII_NCONFIG, MII_READ); + phy_reserved |= PHY_INIT5; + if (mii_rw(dev, np->phyaddr, MII_NCONFIG, phy_reserved)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + } + if (np->phy_oui == PHY_OUI_CICADA) { + phy_reserved = mii_rw(dev, np->phyaddr, MII_SREVISION, MII_READ); + phy_reserved |= PHY_INIT6; + if (mii_rw(dev, np->phyaddr, MII_SREVISION, phy_reserved)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + } + + /* restart auto negotiation */ + mii_control = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ); + mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE); + if (mii_rw(dev, np->phyaddr, MII_BMCR, mii_control)) { + return PHY_ERROR; + } + + return 0; +} + static void nv_start_rx(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); @@ -488,6 +668,8 @@ static void nv_start_rx(struct net_devic writel(np->linkspeed, base + NvRegLinkSpeed); pci_push(base); writel(NVREG_RCVCTL_START, base + NvRegReceiverControl); + dprintk(KERN_DEBUG "%s: nv_start_rx to duplex %d, speed 0x%08x.\n", + dev->name, np->duplex, np->linkspeed); pci_push(base); } @@ -498,8 +680,8 @@ static void nv_stop_rx(struct net_device dprintk(KERN_DEBUG "%s: nv_stop_rx\n", dev->name); writel(0, base + NvRegReceiverControl); reg_delay(dev, NvRegReceiverStatus, NVREG_RCVSTAT_BUSY, 0, - NV_RXSTOP_DELAY1, NV_RXSTOP_DELAY1MAX, - KERN_INFO "nv_stop_rx: ReceiverStatus remained busy"); + NV_RXSTOP_DELAY1, NV_RXSTOP_DELAY1MAX, + KERN_INFO "nv_stop_rx: ReceiverStatus remained busy"); udelay(NV_RXSTOP_DELAY2); writel(0, base + NvRegLinkSpeed); @@ -521,8 +703,8 @@ static void nv_stop_tx(struct net_device dprintk(KERN_DEBUG "%s: nv_stop_tx\n", dev->name); writel(0, base + NvRegTransmitterControl); reg_delay(dev, NvRegTransmitterStatus, NVREG_XMITSTAT_BUSY, 0, - NV_TXSTOP_DELAY1, NV_TXSTOP_DELAY1MAX, - KERN_INFO "nv_stop_tx: TransmitterStatus remained busy"); + NV_TXSTOP_DELAY1, NV_TXSTOP_DELAY1MAX, + KERN_INFO "nv_stop_tx: TransmitterStatus remained busy"); udelay(NV_TXSTOP_DELAY2); writel(0, base + NvRegUnknownTransmitterReg); @@ -530,13 +712,14 @@ static void nv_stop_tx(struct net_device static void nv_txrx_reset(struct net_device *dev) { + struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); dprintk(KERN_DEBUG "%s: nv_txrx_reset\n", dev->name); - writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET, base + NvRegTxRxControl); + writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET | np->desc_ver, base + NvRegTxRxControl); pci_push(base); udelay(NV_TXRX_RESET_DELAY); - writel(NVREG_TXRXCTL_BIT2, base + NvRegTxRxControl); + writel(NVREG_TXRXCTL_BIT2 | np->desc_ver, base + NvRegTxRxControl); pci_push(base); } @@ -651,11 +834,12 @@ static int nv_alloc_rx(struct net_device { struct fe_priv *np = get_nvpriv(dev); unsigned int refill_rx = np->refill_rx; + int nr; while (np->cur_rx != refill_rx) { - int nr = refill_rx % RX_RING; struct sk_buff *skb; + nr = refill_rx % RX_RING; if (np->rx_skbuff[nr] == NULL) { skb = dev_alloc_skb(RX_ALLOC_BUFSIZE); @@ -670,10 +854,9 @@ static int nv_alloc_rx(struct net_device np->rx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len, PCI_DMA_FROMDEVICE); np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]); - np->rx_ring[nr].Length = cpu_to_le16(RX_NIC_BUFSIZE); wmb(); - np->rx_ring[nr].Flags = cpu_to_le16(NV_RX_AVAIL); - dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n", + np->rx_ring[nr].FlagLen = cpu_to_le32(RX_NIC_BUFSIZE | NV_RX_AVAIL); + dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n", dev->name, refill_rx); refill_rx++; } @@ -704,15 +887,13 @@ static int nv_init_ring(struct net_devic int i; np->next_tx = np->nic_tx = 0; - for (i = 0; i < TX_RING; i++) { - np->tx_ring[i].Flags = 0; - } + for (i = 0; i < TX_RING; i++) + np->tx_ring[i].FlagLen = 0; np->cur_rx = RX_RING; np->refill_rx = 0; - for (i = 0; i < RX_RING; i++) { - np->rx_ring[i].Flags = 0; - } + for (i = 0; i < RX_RING; i++) + np->rx_ring[i].FlagLen = 0; return nv_alloc_rx(dev); } @@ -721,7 +902,7 @@ static void nv_drain_tx(struct net_devic struct fe_priv *np = get_nvpriv(dev); int i; for (i = 0; i < TX_RING; i++) { - np->tx_ring[i].Flags = 0; + np->tx_ring[i].FlagLen = 0; if (np->tx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->tx_dma[i], np->tx_skbuff[i]->len, @@ -738,7 +919,7 @@ static void nv_drain_rx(struct net_devic struct fe_priv *np = get_nvpriv(dev); int i; for (i = 0; i < RX_RING; i++) { - np->rx_ring[i].Flags = 0; + np->rx_ring[i].FlagLen = 0; wmb(); if (np->rx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->rx_dma[i], @@ -770,11 +951,10 @@ static int nv_start_xmit(struct sk_buff PCI_DMA_TODEVICE); np->tx_ring[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]); - np->tx_ring[nr].Length = cpu_to_le16(skb->len-1); spin_lock_irq(&np->lock); wmb(); - np->tx_ring[nr].Flags = np->tx_flags; + np->tx_ring[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags ); dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n", dev->name, np->next_tx); { @@ -793,7 +973,7 @@ static int nv_start_xmit(struct sk_buff if (np->next_tx - np->nic_tx >= TX_LIMIT_STOP) netif_stop_queue(dev); spin_unlock_irq(&np->lock); - writel(NVREG_TXRXCTL_KICK, get_hwbase(dev) + NvRegTxRxControl); + writel(NVREG_TXRXCTL_KICK|np->desc_ver, get_hwbase(dev) + NvRegTxRxControl); pci_push(get_hwbase(dev)); return 0; } @@ -806,27 +986,42 @@ static int nv_start_xmit(struct sk_buff static void nv_tx_done(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); + u32 Flags; + int i; - while (np->nic_tx < np->next_tx) { - struct ring_desc *prd; - int i = np->nic_tx % TX_RING; + while (np->nic_tx != np->next_tx) { + i = np->nic_tx % TX_RING; - prd = &np->tx_ring[i]; + Flags = le32_to_cpu(np->tx_ring[i].FlagLen); dprintk(KERN_DEBUG "%s: nv_tx_done: looking at packet %d, Flags 0x%x.\n", - dev->name, np->nic_tx, prd->Flags); - if (prd->Flags & cpu_to_le16(NV_TX_VALID)) + dev->name, np->nic_tx, Flags); + if (Flags & NV_TX_VALID) break; - if (prd->Flags & cpu_to_le16(NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| - NV_TX_UNDERFLOW|NV_TX_ERROR)) { - if (prd->Flags & cpu_to_le16(NV_TX_UNDERFLOW)) - np->stats.tx_fifo_errors++; - if (prd->Flags & cpu_to_le16(NV_TX_CARRIERLOST)) - np->stats.tx_carrier_errors++; - np->stats.tx_errors++; + if (np->desc_ver == DESC_VER_1) { + if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| + NV_TX_UNDERFLOW|NV_TX_ERROR)) { + if (Flags & NV_TX_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += np->tx_skbuff[i]->len; + } } else { - np->stats.tx_packets++; - np->stats.tx_bytes += np->tx_skbuff[i]->len; + if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION| + NV_TX2_UNDERFLOW|NV_TX2_ERROR)) { + if (Flags & NV_TX2_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX2_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += np->tx_skbuff[i]->len; + } } pci_unmap_single(np->pci_dev, np->tx_dma[i], np->tx_skbuff[i]->len, @@ -876,9 +1071,9 @@ static void nv_tx_timeout(struct net_dev static void nv_rx_process(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); + u32 Flags; for (;;) { - struct ring_desc *prd; struct sk_buff *skb; int len; int i; @@ -886,11 +1081,13 @@ static void nv_rx_process(struct net_dev break; /* we scanned the whole ring - do not continue */ i = np->cur_rx % RX_RING; - prd = &np->rx_ring[i]; + Flags = le32_to_cpu(np->rx_ring[i].FlagLen); + len = nv_descr_getlength(&np->rx_ring[i], np->desc_ver); + dprintk(KERN_DEBUG "%s: nv_rx_process: looking at packet %d, Flags 0x%x.\n", - dev->name, np->cur_rx, prd->Flags); + dev->name, np->cur_rx, Flags); - if (prd->Flags & cpu_to_le16(NV_RX_AVAIL)) + if (Flags & NV_RX_AVAIL) break; /* still owned by hardware, */ /* @@ -904,7 +1101,7 @@ static void nv_rx_process(struct net_dev { int j; - dprintk(KERN_DEBUG "Dumping packet (flags 0x%x).",prd->Flags); + dprintk(KERN_DEBUG "Dumping packet (flags 0x%x).",Flags); for (j=0; j<64; j++) { if ((j%16) == 0) dprintk("\n%03x:", j); @@ -913,41 +1110,69 @@ static void nv_rx_process(struct net_dev dprintk("\n"); } /* look at what we actually got: */ - if (!(prd->Flags & cpu_to_le16(NV_RX_DESCRIPTORVALID))) - goto next_pkt; - - - len = le16_to_cpu(prd->Length); + if (np->desc_ver == DESC_VER_1) { + if (!(Flags & NV_RX_DESCRIPTORVALID)) + goto next_pkt; - if (prd->Flags & cpu_to_le16(NV_RX_MISSEDFRAME)) { - np->stats.rx_missed_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_CRCERR)) { - np->stats.rx_crc_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_OVERFLOW)) { - np->stats.rx_over_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_ERROR)) { - /* framing errors are soft errors, the rest is fatal. */ - if (prd->Flags & cpu_to_le16(NV_RX_FRAMINGERR)) { - if (prd->Flags & cpu_to_le16(NV_RX_SUBSTRACT1)) { - len--; + if (Flags & NV_RX_MISSEDFRAME) { + np->stats.rx_missed_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & (NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_CRCERR) { + np->stats.rx_crc_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_OVERFLOW) { + np->stats.rx_over_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_ERROR) { + /* framing errors are soft errors, the rest is fatal. */ + if (Flags & NV_RX_FRAMINGERR) { + if (Flags & NV_RX_SUBSTRACT1) { + len--; + } + } else { + np->stats.rx_errors++; + goto next_pkt; } - } else { + } + } else { + if (!(Flags & NV_RX2_DESCRIPTORVALID)) + goto next_pkt; + + if (Flags & (NV_RX2_ERROR1|NV_RX2_ERROR2|NV_RX2_ERROR3|NV_RX2_ERROR4)) { np->stats.rx_errors++; goto next_pkt; } + if (Flags & NV_RX2_CRCERR) { + np->stats.rx_crc_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX2_OVERFLOW) { + np->stats.rx_over_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX2_ERROR) { + /* framing errors are soft errors, the rest is fatal. */ + if (Flags & NV_RX2_FRAMINGERR) { + if (Flags & NV_RX2_SUBSTRACT1) { + len--; + } + } else { + np->stats.rx_errors++; + goto next_pkt; + } + } } /* got a valid packet - forward it to the network core */ skb = np->rx_skbuff[i]; @@ -972,7 +1197,7 @@ next_pkt: */ static int nv_change_mtu(struct net_device *dev, int new_mtu) { - if (new_mtu > DEFAULT_MTU) + if (new_mtu > ETH_DATA_LEN) return -EINVAL; dev->mtu = new_mtu; return 0; @@ -1036,6 +1261,8 @@ static void nv_set_multicast(struct net_ writel(mask[0], base + NvRegMulticastMaskA); writel(mask[1], base + NvRegMulticastMaskB); writel(pff, base + NvRegPacketFilterFlags); + dprintk(KERN_INFO "%s: reconfiguration for multicast lists.\n", + dev->name); nv_start_rx(dev); spin_unlock_irq(&np->lock); } @@ -1043,16 +1270,62 @@ static void nv_set_multicast(struct net_ static int nv_update_linkspeed(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); - int adv, lpa, newls, newdup; + u8 *base = get_hwbase(dev); + int adv, lpa; + int newls = np->linkspeed; + int newdup = np->duplex; + int mii_status; + int retval = 0; + u32 control_1000, status_1000, phyreg; + + /* BMSR_LSTATUS is latched, read it twice: + * we want the current value. + */ + mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + mii_status = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + + if (!(mii_status & BMSR_LSTATUS)) { + dprintk(KERN_DEBUG "%s: no link detected by phy - falling back to 10HD.\n", + dev->name); + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + newdup = 0; + retval = 0; + goto set_speed; + } + + /* check auto negotiation is complete */ + if (!(mii_status & BMSR_ANEGCOMPLETE)) { + /* still in autonegotiation - configure nic for 10 MBit HD and wait. */ + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + newdup = 0; + retval = 0; + dprintk(KERN_DEBUG "%s: autoneg not completed - falling back to 10HD.\n", dev->name); + goto set_speed; + } + + retval = 1; + if (np->gigabit == PHY_GIGABIT) { + control_1000 = mii_rw(dev, np->phyaddr, MII_1000BT_CR, MII_READ); + status_1000 = mii_rw(dev, np->phyaddr, MII_1000BT_SR, MII_READ); + + if ((control_1000 & ADVERTISE_1000FULL) && + (status_1000 & LPA_1000FULL)) { + dprintk(KERN_DEBUG "%s: nv_update_linkspeed: GBit ethernet detected.\n", + dev->name); + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_1000; + newdup = 1; + goto set_speed; + } + } adv = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ); lpa = mii_rw(dev, np->phyaddr, MII_LPA, MII_READ); dprintk(KERN_DEBUG "%s: nv_update_linkspeed: PHY advertises 0x%04x, lpa 0x%04x.\n", dev->name, adv, lpa); - /* FIXME: handle parallel detection properly, handle gigabit ethernet */ + /* FIXME: handle parallel detection properly */ lpa = lpa & adv; - if (lpa & LPA_100FULL) { + if (lpa & LPA_100FULL) { newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_100; newdup = 1; } else if (lpa & LPA_100HALF) { @@ -1069,47 +1342,75 @@ static int nv_update_linkspeed(struct ne newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; newdup = 0; } - if (np->duplex != newdup || np->linkspeed != newls) { - np->duplex = newdup; - np->linkspeed = newls; - return 1; - } - return 0; + +set_speed: + if (np->duplex == newdup && np->linkspeed == newls) + return retval; + + dprintk(KERN_INFO "%s: changing link setting from %d/%d to %d/%d.\n", + dev->name, np->linkspeed, np->duplex, newls, newdup); + + np->duplex = newdup; + np->linkspeed = newls; + + if (np->gigabit == PHY_GIGABIT) { + phyreg = readl(base + NvRegRandomSeed); + phyreg &= ~(0x3FF00); + if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_10) + phyreg |= NVREG_RNDSEED_FORCE3; + else if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_100) + phyreg |= NVREG_RNDSEED_FORCE2; + else if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_1000) + phyreg |= NVREG_RNDSEED_FORCE; + writel(phyreg, base + NvRegRandomSeed); + } + + phyreg = readl(base + NvRegPhyInterface); + phyreg &= ~(PHY_HALF|PHY_100|PHY_1000); + if (np->duplex == 0) + phyreg |= PHY_HALF; + if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_100) + phyreg |= PHY_100; + else if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_1000) + phyreg |= PHY_1000; + writel(phyreg, base + NvRegPhyInterface); + + writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), + base + NvRegMisc1); + pci_push(base); + writel(np->linkspeed, base + NvRegLinkSpeed); + pci_push(base); + + return retval; } static void nv_link_irq(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); u32 miistat; - int miival; miistat = readl(base + NvRegMIIStatus); writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); - printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); + dprintk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); - miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); - if (miival & BMSR_ANEGCOMPLETE) { - nv_update_linkspeed(dev); - - if (netif_carrier_ok(dev)) { - nv_stop_rx(dev); + if (miistat & (NVREG_MIISTAT_LINKCHANGE)) { + if (nv_update_linkspeed(dev)) { + if (netif_carrier_ok(dev)) { + nv_stop_rx(dev); + } else { + netif_carrier_on(dev); + printk(KERN_INFO "%s: link up.\n", dev->name); + } + nv_start_rx(dev); } else { - netif_carrier_on(dev); - printk(KERN_INFO "%s: link up.\n", dev->name); - } - writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), - base + NvRegMisc1); - nv_start_rx(dev); - } else { - if (netif_carrier_ok(dev)) { - netif_carrier_off(dev); - printk(KERN_INFO "%s: link down.\n", dev->name); - nv_stop_rx(dev); + if (netif_carrier_ok(dev)) { + netif_carrier_off(dev); + printk(KERN_INFO "%s: link down.\n", dev->name); + nv_stop_rx(dev); + } } - writel(np->linkspeed, base + NvRegLinkSpeed); - pci_push(base); } + dprintk(KERN_DEBUG "%s: link change notification done.\n", dev->name); } static irqreturn_t nv_nic_irq(int foo, void *data, struct pt_regs *regs) @@ -1136,7 +1437,7 @@ static irqreturn_t nv_nic_irq(int foo, v spin_unlock(&np->lock); } - if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { + if (events & (NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { nv_rx_process(dev); if (nv_alloc_rx(dev)) { spin_lock(&np->lock); @@ -1158,7 +1459,7 @@ static irqreturn_t nv_nic_irq(int foo, v if (events & (NVREG_IRQ_UNKNOWN)) { printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n", dev->name, events); - } + } if (i > max_interrupt_work) { spin_lock(&np->lock); /* disable interrupts on the nic */ @@ -1211,21 +1512,27 @@ static int nv_open(struct net_device *de writel(0, base + NvRegMulticastMaskA); writel(0, base + NvRegMulticastMaskB); writel(0, base + NvRegPacketFilterFlags); + + writel(0, base + NvRegTransmitterControl); + writel(0, base + NvRegReceiverControl); + writel(0, base + NvRegAdapterControl); + + /* 2) initialize descriptor rings */ + oom = nv_init_ring(dev); + writel(0, base + NvRegLinkSpeed); writel(0, base + NvRegUnknownTransmitterReg); nv_txrx_reset(dev); writel(0, base + NvRegUnknownSetupReg6); - /* 2) initialize descriptor rings */ np->in_shutdown = 0; - oom = nv_init_ring(dev); /* 3) set mac address */ { u32 mac[2]; - mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) + + mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) + (dev->dev_addr[2] << 16) + (dev->dev_addr[3] << 24); mac[1] = (dev->dev_addr[4] << 0) + (dev->dev_addr[5] << 8); @@ -1233,53 +1540,31 @@ static int nv_open(struct net_device *de writel(mac[1], base + NvRegMacAddrB); } - /* 4) continue setup */ + /* 4) give hw rings */ + writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr); + writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr); + writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT), + base + NvRegRingSizes); + + /* 5) continue setup */ np->linkspeed = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; np->duplex = 0; + + writel(np->linkspeed, base + NvRegLinkSpeed); writel(NVREG_UNKSETUP3_VAL1, base + NvRegUnknownSetupReg3); - writel(0, base + NvRegTxRxControl); + writel(np->desc_ver, base + NvRegTxRxControl); pci_push(base); - writel(NVREG_TXRXCTL_BIT1, base + NvRegTxRxControl); + writel(NVREG_TXRXCTL_BIT1|np->desc_ver, base + NvRegTxRxControl); reg_delay(dev, NvRegUnknownSetupReg5, NVREG_UNKSETUP5_BIT31, NVREG_UNKSETUP5_BIT31, NV_SETUP5_DELAY, NV_SETUP5_DELAYMAX, KERN_INFO "open: SetupReg5, Bit 31 remained off\n"); - writel(0, base + NvRegUnknownSetupReg4); - - /* 5) Find a suitable PHY */ - writel(NVREG_MIISPEED_BIT8|NVREG_MIIDELAY, base + NvRegMIISpeed); - for (i = 1; i < 32; i++) { - int id1, id2; - - spin_lock_irq(&np->lock); - id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ); - spin_unlock_irq(&np->lock); - if (id1 < 0 || id1 == 0xffff) - continue; - spin_lock_irq(&np->lock); - id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ); - spin_unlock_irq(&np->lock); - if (id2 < 0 || id2 == 0xffff) - continue; - dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n", - dev->name, id1, id2, i); - np->phyaddr = i; - spin_lock_irq(&np->lock); - nv_update_linkspeed(dev); - spin_unlock_irq(&np->lock); - - break; - } - if (i == 32) { - printk(KERN_INFO "%s: open: failing due to lack of suitable PHY.\n", - dev->name); - ret = -EINVAL; - goto out_drain; - } + writel(0, base + NvRegUnknownSetupReg4); + writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); + writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus); /* 6) continue setup */ - writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), - base + NvRegMisc1); + writel(NVREG_MISC1_FORCE | NVREG_MISC1_HD, base + NvRegMisc1); writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus); writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags); writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig); @@ -1291,17 +1576,12 @@ static int nv_open(struct net_device *de writel(NVREG_UNKSETUP2_VAL, base + NvRegUnknownSetupReg2); writel(NVREG_POLL_DEFAULT, base + NvRegPollingInterval); writel(NVREG_UNKSETUP6_VAL, base + NvRegUnknownSetupReg6); - writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID, + writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID|NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); + writel(NVREG_MIISPEED_BIT8|NVREG_MIIDELAY, base + NvRegMIISpeed); writel(NVREG_UNKSETUP4_VAL, base + NvRegUnknownSetupReg4); writel(NVREG_WAKEUPFLAGS_VAL, base + NvRegWakeUpFlags); - /* 7) start packet processing */ - writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr); - writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr); - writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT), - base + NvRegRingSizes); - i = readl(base + NvRegPowerState); if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0) writel(NVREG_POWERSTATE_POWEREDUP|i, base + NvRegPowerState); @@ -1309,13 +1589,9 @@ static int nv_open(struct net_device *de pci_push(base); udelay(10); writel(readl(base + NvRegPowerState) | NVREG_POWERSTATE_VALID, base + NvRegPowerState); - writel(NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); - writel(0, base + NvRegIrqMask); pci_push(base); - writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); - pci_push(base); writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus); writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); pci_push(base); @@ -1324,6 +1600,7 @@ static int nv_open(struct net_device *de if (ret) goto out_drain; + /* ask for interrupts */ writel(np->irqmask, base + NvRegIrqMask); spin_lock_irq(&np->lock); @@ -1332,18 +1609,27 @@ static int nv_open(struct net_device *de writel(0, base + NvRegMulticastMaskA); writel(0, base + NvRegMulticastMaskB); writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags); + /* One manual link speed update: Interrupts are enabled, future link + * speed changes cause interrupts and are handled by nv_link_irq(). + */ + { + u32 miistat; + miistat = readl(base + NvRegMIIStatus); + writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); + dprintk(KERN_INFO "startup: got 0x%08x.\n", miistat); + } + ret = nv_update_linkspeed(dev); nv_start_rx(dev); nv_start_tx(dev); netif_start_queue(dev); - if (oom) - mod_timer(&np->oom_kick, jiffies + OOM_REFILL); - if (mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE) { + if (ret) { netif_carrier_on(dev); } else { printk("%s: no link during initialization.\n", dev->name); netif_carrier_off(dev); } - + if (oom) + mod_timer(&np->oom_kick, jiffies + OOM_REFILL); spin_unlock_irq(&np->lock); return 0; @@ -1448,6 +1734,14 @@ static int __devinit nv_probe(struct pci goto out_relreg; } + /* handle different descriptor versions */ + if (pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_1 || + pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 || + pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3) + np->desc_ver = DESC_VER_1; + else + np->desc_ver = DESC_VER_2; + err = -ENOMEM; dev->base_addr = (unsigned long) ioremap(addr, NV_PCI_REGSZ); if (!dev->base_addr) @@ -1507,9 +1801,15 @@ static int __devinit nv_probe(struct pci writel(0, base + NvRegWakeUpFlags); np->wolenabled = 0; - np->tx_flags = cpu_to_le16(NV_TX_LASTPACKET|NV_TX_LASTPACKET1|NV_TX_VALID); - if (id->driver_data & DEV_NEED_LASTPACKET1) - np->tx_flags |= cpu_to_le16(NV_TX_LASTPACKET1); + if (np->desc_ver == DESC_VER_1) { + np->tx_flags = NV_TX_LASTPACKET|NV_TX_VALID; + if (id->driver_data & DEV_NEED_LASTPACKET1) + np->tx_flags |= NV_TX_LASTPACKET1; + } else { + np->tx_flags = NV_TX2_LASTPACKET|NV_TX2_VALID; + if (id->driver_data & DEV_NEED_LASTPACKET1) + np->tx_flags |= NV_TX2_LASTPACKET1; + } if (id->driver_data & DEV_IRQMASK_1) np->irqmask = NVREG_IRQMASK_WANTED_1; if (id->driver_data & DEV_IRQMASK_2) @@ -1517,6 +1817,42 @@ static int __devinit nv_probe(struct pci if (id->driver_data & DEV_NEED_TIMERIRQ) np->irqmask |= NVREG_IRQ_TIMER; + /* find a suitable phy */ + for (i = 1; i < 32; i++) { + int id1, id2; + + spin_lock_irq(&np->lock); + id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ); + spin_unlock_irq(&np->lock); + if (id1 < 0 || id1 == 0xffff) + continue; + spin_lock_irq(&np->lock); + id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ); + spin_unlock_irq(&np->lock); + if (id2 < 0 || id2 == 0xffff) + continue; + + id1 = (id1 & PHYID1_OUI_MASK) << PHYID1_OUI_SHFT; + id2 = (id2 & PHYID2_OUI_MASK) >> PHYID2_OUI_SHFT; + dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n", + pci_name(pci_dev), id1, id2, i); + np->phyaddr = i; + np->phy_oui = id1 | id2; + break; + } + if (i == 32) { + /* PHY in isolate mode? No phy attached and user wants to + * test loopback? Very odd, but can be correct. + */ + printk(KERN_INFO "%s: open: Could not find a valid PHY.\n", + pci_name(pci_dev)); + } + + if (i != 32) { + /* reset it */ + phy_init(dev); + } + err = register_netdev(dev); if (err) { printk(KERN_INFO "forcedeth: unable to register netdev: %d\n", err); @@ -1570,21 +1906,77 @@ static void __devexit nv_remove(struct p static struct pci_device_id pci_tbl[] = { { /* nForce Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, - .device = 0x1C3, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_1, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ, }, { /* nForce2 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, - .device = 0x0066, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_2, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_3, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_4, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_5, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, }, { /* nForce3 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, - .device = 0x00D6, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_6, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_7, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* CK804 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_8, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* CK804 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_9, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* MCP04 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_10, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* MCP04 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_11, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, @@ -1611,9 +2003,9 @@ static void __exit exit_nic(void) pci_unregister_driver(&driver); } -MODULE_PARM(max_interrupt_work, "i"); +module_param(max_interrupt_work, int, 0); MODULE_PARM_DESC(max_interrupt_work, "forcedeth maximum events handled per interrupt"); - + MODULE_AUTHOR("Manfred Spraul "); MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver"); MODULE_LICENSE("GPL"); --- 2.6/include/linux/pci_ids.h 2004-07-01 07:23:15.000000000 +0200 +++ build-2.6/include/linux/pci_ids.h 2004-07-01 07:06:37.000000000 +0200 @@ -1063,21 +1063,33 @@ #define PCI_DEVICE_ID_NVIDIA_UVTNT2 0x002D #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_IDE 0x0035 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_SATA 0x0036 +#define PCI_DEVICE_ID_NVIDIA_NVENET_10 0x0037 +#define PCI_DEVICE_ID_NVIDIA_NVENET_11 0x0038 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_SATA2 0x003e #define PCI_DEVICE_ID_NVIDIA_NFORCE_CK804_IDE 0x0053 #define PCI_DEVICE_ID_NVIDIA_NFORCE_CK804_SATA 0x0054 #define PCI_DEVICE_ID_NVIDIA_NFORCE_CK804_SATA2 0x0055 +#define PCI_DEVICE_ID_NVIDIA_NVENET_8 0x0056 +#define PCI_DEVICE_ID_NVIDIA_NVENET_9 0x0057 #define PCI_DEVICE_ID_NVIDIA_NFORCE2_IDE 0x0065 +#define PCI_DEVICE_ID_NVIDIA_NVENET_2 0x0066 #define PCI_DEVICE_ID_NVIDIA_MCP2_AUDIO 0x006a #define PCI_DEVICE_ID_NVIDIA_NFORCE2S_IDE 0x0085 +#define PCI_DEVICE_ID_NVIDIA_NVENET_4 0x0086 +#define PCI_DEVICE_ID_NVIDIA_NVENET_5 0x008c #define PCI_DEVICE_ID_NVIDIA_NFORCE2S_SATA 0x008e #define PCI_DEVICE_ID_NVIDIA_ITNT2 0x00A0 #define PCI_DEVICE_ID_NVIDIA_NFORCE3 0x00d1 #define PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO 0x00da #define PCI_DEVICE_ID_NVIDIA_NFORCE3S 0x00e1 #define PCI_DEVICE_ID_NVIDIA_NFORCE3_IDE 0x00d5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_3 0x00d6 +#define PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO 0x00da +#define PCI_DEVICE_ID_NVIDIA_NVENET_7 0x00df +#define PCI_DEVICE_ID_NVIDIA_NFORCE3S 0x00e1 #define PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA 0x00e3 #define PCI_DEVICE_ID_NVIDIA_NFORCE3S_IDE 0x00e5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_6 0x00e6 #define PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA2 0x00ee #define PCI_DEVICE_ID_NVIDIA_GEFORCE_SDR 0x0100 #define PCI_DEVICE_ID_NVIDIA_GEFORCE_DDR 0x0101 @@ -1105,6 +1117,7 @@ #define PCI_DEVICE_ID_NVIDIA_NFORCE 0x01a4 #define PCI_DEVICE_ID_NVIDIA_MCP1_AUDIO 0x01b1 #define PCI_DEVICE_ID_NVIDIA_NFORCE_IDE 0x01bc +#define PCI_DEVICE_ID_NVIDIA_NVENET_1 0x01c3 #define PCI_DEVICE_ID_NVIDIA_NFORCE2 0x01e0 #define PCI_DEVICE_ID_NVIDIA_GEFORCE3 0x0200 #define PCI_DEVICE_ID_NVIDIA_GEFORCE3_1 0x0201 --------------040907050803020100060100-- From akpm@osdl.org Fri Jul 2 12:32:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 12:32:59 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62JWqgi001475 for ; Fri, 2 Jul 2004 12:32:56 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i62JVLG08489; Fri, 2 Jul 2004 12:31:21 -0700 Date: Fri, 2 Jul 2004 12:30:22 -0700 From: Andrew Morton To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: Fw: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database Message-Id: <20040702123022.563ee931.akpm@osdl.org> In-Reply-To: References: <20040702004956.448c95d9.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Herbert Xu wrote: > > Andrew Morton wrote: > > > > Could someone please take a look at the locking in > > net/ipv4/ipmr.c:ipmr_mfc_seq_next? It seems rather broken. > > Obfuscated yes, broken no. Really? Even if that goto if (it->cache == &mfc_unres_queue) goto end_of_list; is taken? Bizarre. It sure looks wrong. But then, if the author couldn't be bothered describing the locking, I can't be bothered reverse engineering it, so there. > Unfortunately the seq interface tends to produce code like this. Maybe. It could be that the locking in there is straightforward and sensible. But because it is also secretly designed, we see what happens - it wasted the Stanford guys' time, my time, your time, etc. Sigh. From akpm@osdl.org Fri Jul 2 12:44:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 12:44:34 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62JiSgi002111 for ; Fri, 2 Jul 2004 12:44:28 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i62JiMG10785; Fri, 2 Jul 2004 12:44:22 -0700 Date: Fri, 2 Jul 2004 12:43:23 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: James Morris Subject: Fw: [Bugme-new] [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP Message-Id: <20040702124323.5690be11.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Fri, 2 Jul 2004 10:32:47 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP http://bugme.osdl.org/show_bug.cgi?id=3003 Summary: might_sleep warning when setting up IPSec with IPCOMP Kernel Version: 2.6.7 Status: NEW Severity: normal Owner: niv@us.ibm.com Submitter: christophe@saout.de CC: christophe@saout.de Linux 2.6.7 on x86, UP preempt Using OpenSWAN for IPSec tunnel with IP-Compression enabled. Often gives the following warning shortly after a connection has been set up: I'm not exactly sure whether this is cryptoapi or the compression module or IPCOMP's fault. Jul 2 18:39:04 websrv Debug: sleeping function called from invalid context at mm/slab.c:1994 Jul 2 18:39:04 websrv in_atomic():1, irqs_disabled():0 Jul 2 18:39:04 websrv [] dump_stack+0x17/0x20 Jul 2 18:39:04 websrv [] __might_sleep+0xb4/0xe0 Jul 2 18:39:04 websrv [] kmem_cache_alloc+0x5c/0x60 Jul 2 18:39:04 websrv [] __get_vm_area+0x20/0xf0 Jul 2 18:39:04 websrv [] get_vm_area+0x24/0x30 Jul 2 18:39:04 websrv [] __vmalloc+0x3c/0x100 Jul 2 18:39:04 websrv [] deflate_comp_init+0x4a/0xf0 Jul 2 18:39:04 websrv [] deflate_compress+0x24/0x80 Jul 2 18:39:04 websrv [] crypto_compress+0x24/0x30 Jul 2 18:39:04 websrv [] ipcomp_compress+0x6c/0x110 Jul 2 18:39:04 websrv [] ipcomp_output+0xc1/0x370 Jul 2 18:39:04 websrv [] dst_output+0xe/0x30 Jul 2 18:39:04 websrv [] nf_hook_slow+0xfa/0x170 Jul 2 18:39:04 websrv [] ip_queue_xmit+0x452/0x540 Jul 2 18:39:04 websrv [] tcp_transmit_skb+0x3ef/0x660 Jul 2 18:39:04 websrv [] tcp_write_xmit+0x15b/0x2c0 Jul 2 18:39:04 websrv [] tcp_sendmsg+0x4e5/0x1030 Jul 2 18:39:04 websrv [] inet_sendmsg+0x47/0x60 Jul 2 18:39:04 websrv [] sock_aio_write+0xae/0xd0 Jul 2 18:39:04 websrv [] do_sync_write+0x76/0xb0 Jul 2 18:39:04 websrv [] vfs_write+0xcb/0xf0 Jul 2 18:39:04 websrv [] sys_write+0x35/0x60 Jul 2 18:39:04 websrv [] sysenter_past_esp+0x52/0x71 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From shemminger@osdl.org Fri Jul 2 12:50:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 12:50:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62JoSgi002772 for ; Fri, 2 Jul 2004 12:50:28 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i62Jo8G12337; Fri, 2 Jul 2004 12:50:08 -0700 Date: Fri, 2 Jul 2004 12:50:08 -0700 From: Stephen Hemminger To: Andrew Morton Cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database Message-Id: <20040702125008.25e65252@dell_ss3.pdx.osdl.net> In-Reply-To: <20040702123022.563ee931.akpm@osdl.org> References: <20040702004956.448c95d9.akpm@osdl.org> <20040702123022.563ee931.akpm@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 2 Jul 2004 12:30:22 -0700 Andrew Morton wrote: > Herbert Xu wrote: > > > > Andrew Morton wrote: > > > > > > Could someone please take a look at the locking in > > > net/ipv4/ipmr.c:ipmr_mfc_seq_next? It seems rather broken. > > > > Obfuscated yes, broken no. > > Really? Even if that goto > > if (it->cache == &mfc_unres_queue) > goto end_of_list; > > is taken? The problem is that the seq_file interface is trying to create an iterator over a set of data. The interface expects that the usage will always fit a given pattern. The implied semantic is: if returned handle is NULL, then nothing is locked and it->cache = NULL if returned handle is in the mfc_cache_table then it->cache points to mfc_cache_array and mrt_lock is held if returned handle is in the mfc_unres_queue then it->cache points to mfc_unres_queue and mfc_unres_lock is held the seq_next is only valid to mean give me the next entry after the passed handle therefore if there are no more entries after the handle and the handle was on the unresolved queue, then the end is reached. When seq_stop is called, the it->cache pointer will be NULL so no unlock is done. From shemminger@osdl.org Fri Jul 2 13:44:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 13:44:58 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62Kirgi006934 for ; Fri, 2 Jul 2004 13:44:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i62KibG21702; Fri, 2 Jul 2004 13:44:37 -0700 Date: Fri, 2 Jul 2004 13:44:37 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040702134437.5891e998@dell_ss3.pdx.osdl.net> In-Reply-To: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Here is an enhancement to netem to do allow emulating lower speed networks. The resolution is close, but obviously limited by the granularity of timers and size of packets. Also, fixes a rtnetlink dependency which showed up in some configurations and optimizes for the non-loss case by avoiding net_random call. Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2004-07-02 13:40:11 -07:00 +++ b/net/sched/sch_netem.c 2004-07-02 13:40:11 -07:00 @@ -18,6 +18,7 @@ #include #include #include +#include #include @@ -31,11 +32,13 @@ struct sk_buff_head qnormal; struct sk_buff_head qdelay; struct timer_list timer; + psched_time_t last; u32 latency; u32 loss; u32 counter; u32 gap; + u32 rate; }; /* Time stamp put into socket buffer control block */ @@ -54,13 +57,23 @@ pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); /* Random packet drop 0 => none, ~0 => all */ - if (q->loss >= net_random()) { + if (q->loss && q->loss >= net_random()) { sch->stats.drops++; return 0; /* lie about loss so TCP doesn't know */ } if (q->qnormal.qlen < sch->dev->tx_queue_len) { PSCHED_GET_TIME(cb->time_to_send); + if (q->rate) { + if (!PSCHED_IS_PASTPERFECT(q->last) && + PSCHED_TLESS(cb->time_to_send, q->last)) + cb->time_to_send = q->last; + + PSCHED_TADD(cb->time_to_send, + (USEC_PER_SEC * skb->len) / q->rate); + q->last = cb->time_to_send; + } + PSCHED_TADD(cb->time_to_send, q->latency); __skb_queue_tail(&q->qnormal, skb); @@ -179,6 +192,7 @@ q->gap = qopt->gap; q->loss = qopt->loss; q->latency = qopt->latency; + q->rate = qopt->rate; return 0; } @@ -196,6 +210,7 @@ q->timer.function = netem_timer; q->timer.data = (unsigned long) sch; q->counter = 0; + PSCHED_SET_PASTPERFECT(q->last); return netem_change(sch, opt); } @@ -217,6 +232,7 @@ qopt.limit = sch->dev->tx_queue_len; qopt.loss = q->loss; qopt.gap = q->gap; + qopt.rate = q->rate; RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); From niv@us.ibm.com Fri Jul 2 14:25:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 14:25:27 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62LP8gi007913 for ; Fri, 2 Jul 2004 14:25:24 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i62LOnZK466336; Fri, 2 Jul 2004 17:24:49 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i62LOlrb396946; Fri, 2 Jul 2004 15:24:48 -0600 Message-ID: <40E5D326.5000509@us.ibm.com> Date: Fri, 02 Jul 2004 14:27:02 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi CC: James Morris , akpm@osdl.org, netdev , christophe@saout.de, mjbligh@us.ibm.com Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] References: <40E5A1B3.2020202@us.ibm.com> In-Reply-To: <40E5A1B3.2020202@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Nivedita Singhvi wrote: > James, Andrew, > > Looks like deflate_comp_init() is not calling > __vmalloc in a kosher way. > Jul 2 18:39:04 websrv Debug: sleeping function called from invalid > context at > mm/slab.c:1994 > Jul 2 18:39:04 websrv in_atomic():1, irqs_disabled():0 > Jul 2 18:39:04 websrv [] dump_stack+0x17/0x20 > Jul 2 18:39:04 websrv [] __might_sleep+0xb4/0xe0 > Jul 2 18:39:04 websrv [] kmem_cache_alloc+0x5c/0x60 > Jul 2 18:39:04 websrv [] __get_vm_area+0x20/0xf0 > Jul 2 18:39:04 websrv [] get_vm_area+0x24/0x30 > Jul 2 18:39:04 websrv [] __vmalloc+0x3c/0x100 > Jul 2 18:39:04 websrv [] deflate_comp_init+0x4a/0xf0 > Jul 2 18:39:04 websrv [] deflate_compress+0x24/0x80 > Jul 2 18:39:04 websrv [] crypto_compress+0x24/0x30 > Jul 2 18:39:04 websrv [] ipcomp_compress+0x6c/0x110 > Jul 2 18:39:04 websrv [] ipcomp_output+0xc1/0x370 We are grabbing dst->xfrm lock in ipcomp_output(), and have it held when we call ipcomp_compress(). Is that the issue? I don't have the crypto module code, but in_atomic() will be true. thanks, Nivedita From christophe@saout.de Fri Jul 2 14:36:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 14:36:29 -0700 (PDT) Received: from websrv.werbeagentur-aufwind.de (websrv.werbeagentur-aufwind.de [213.239.197.241]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62La7gi008356 for ; Fri, 2 Jul 2004 14:36:08 -0700 Received: (qmail 31513 invoked by uid 1003); 2 Jul 2004 23:36:07 +0200 Received: from christophe@saout.de by websrv.werbeagentur-aufwind.de by uid 201 with qmail-scanner-1.20 (clamuko: 0.73. spamassassin: 2.63. Clear:RC:0(80.131.186.206):SA:0(-0.8/6.0):. Processed in 3.015413 secs); 02 Jul 2004 21:36:07 -0000 Received: from p5083bace.dip.t-dialin.net (HELO mail.cs.pocnet.net) (smtp@werbeagentur-aufwind.de@80.131.186.206) by websrv.werbeagentur-aufwind.de with AES256-SHA encrypted SMTP; 2 Jul 2004 23:36:04 +0200 Received: (qmail 14293 invoked from network); 2 Jul 2004 23:36:00 +0200 Received: from leto.cs.pocnet.net (192.168.80.6) by server.cs.pocnet.net with RC4-MD5 encrypted SMTP; 2 Jul 2004 23:36:00 +0200 Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] From: Christophe Saout To: Nivedita Singhvi Cc: James Morris , akpm@osdl.org, netdev , mjbligh@us.ibm.com In-Reply-To: <40E5D326.5000509@us.ibm.com> References: <40E5A1B3.2020202@us.ibm.com> <40E5D326.5000509@us.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mH+Ux6i7NwWDf3I2Zdzn" Date: Fri, 02 Jul 2004 23:35:59 +0200 Message-Id: <1088804159.763.5.camel@leto.cs.pocnet.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 X-archive-position: 6524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christophe@saout.de Precedence: bulk X-list: netdev --=-mH+Ux6i7NwWDf3I2Zdzn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Fr, den 02.07.2004 um 14:27 Uhr -0700 schrieb Nivedita Singhvi: > We are grabbing dst->xfrm lock in ipcomp_output(), > and have it held when we call ipcomp_compress(). >=20 > Is that the issue? I don't have the crypto module > code, but in_atomic() will be true. Yes. But the code might also be called from softirq context, when a packed from the NIC gets handled or when a slot in the queue becomes free. (I've also got warnings from those two cases in my logs) The compress/decompress calls should be able to be run from softirq (atomic) context just like encrypt/decrypt. I'm just wondering, why does deflate_compress call deflate_comp_init when it is called the first time, but deflate_init is a noop? Shouldn't the deflate_comp_init call just be moved to deflate_init? --=-mH+Ux6i7NwWDf3I2Zdzn Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA5dU/ZCYBcts5dM0RAvu+AJ9uPlqwuUTSSMKvhKJwdBqCrZGkcACeMPpJ y9HkduGM/pLuGamH56kM7KQ= =7Vct -----END PGP SIGNATURE----- --=-mH+Ux6i7NwWDf3I2Zdzn-- From akpm@osdl.org Fri Jul 2 14:37:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 14:37:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62Laxgi008500 for ; Fri, 2 Jul 2004 14:37:00 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i62LaqG00643; Fri, 2 Jul 2004 14:36:52 -0700 Date: Fri, 2 Jul 2004 14:39:49 -0700 From: Andrew Morton To: Nivedita Singhvi Cc: niv@us.ibm.com, jmorris@intercode.com.au, netdev@oss.sgi.com, christophe@saout.de, mjbligh@us.ibm.com Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] Message-Id: <20040702143949.21a50b74.akpm@osdl.org> In-Reply-To: <40E5D326.5000509@us.ibm.com> References: <40E5A1B3.2020202@us.ibm.com> <40E5D326.5000509@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Nivedita Singhvi wrote: > > Nivedita Singhvi wrote: > > > James, Andrew, > > > > Looks like deflate_comp_init() is not calling > > __vmalloc in a kosher way. > > > Jul 2 18:39:04 websrv Debug: sleeping function called from invalid > > context at > > mm/slab.c:1994 > > Jul 2 18:39:04 websrv in_atomic():1, irqs_disabled():0 > > Jul 2 18:39:04 websrv [] dump_stack+0x17/0x20 > > Jul 2 18:39:04 websrv [] __might_sleep+0xb4/0xe0 > > Jul 2 18:39:04 websrv [] kmem_cache_alloc+0x5c/0x60 > > Jul 2 18:39:04 websrv [] __get_vm_area+0x20/0xf0 > > Jul 2 18:39:04 websrv [] get_vm_area+0x24/0x30 > > Jul 2 18:39:04 websrv [] __vmalloc+0x3c/0x100 > > Jul 2 18:39:04 websrv [] deflate_comp_init+0x4a/0xf0 > > Jul 2 18:39:04 websrv [] deflate_compress+0x24/0x80 > > Jul 2 18:39:04 websrv [] crypto_compress+0x24/0x30 > > Jul 2 18:39:04 websrv [] ipcomp_compress+0x6c/0x110 > > Jul 2 18:39:04 websrv [] ipcomp_output+0xc1/0x370 > > We are grabbing dst->xfrm lock in ipcomp_output(), > and have it held when we call ipcomp_compress(). > > Is that the issue? I don't have the crypto module > code, but in_atomic() will be true. > Yes, that is the issue. From a design point-of-view, it is not idiomatic for deflate_compress() to be doing this magical lazy initialisation. It would be better if the client of the deflate.c code were to explicitly initialise the context before diving in and using it. /* * Lazy initialization to make interface simple without allocating * un-needed workspaces. Thus can be called in softirq context. */ static int deflate_comp_init(struct deflate_ctx *ctx) Well no. Those games with deflate_gfp() really need to go away. in_atomic() works OK if CONFIG_PREEMPT is enabled. But with CONFIG_PREEMPT=n, in_atomic() returns false inside spinlock. And in_atomic()'s return value is unaffected by local_irq_disable(). This all needs to be redesigned, sorry. From skinkie@xs4all.nl Fri Jul 2 14:51:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 14:52:01 -0700 (PDT) Received: from smtp-out6.xs4all.nl (smtp-out6.xs4all.nl [194.109.24.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i62Lpvgi009148 for ; Fri, 2 Jul 2004 14:51:58 -0700 Received: from [10.0.0.83] (kinkrsoftware.xs4all.nl [213.84.249.129]) by smtp-out6.xs4all.nl (8.12.10/8.12.10) with ESMTP id i62Lpuew099168; Fri, 2 Jul 2004 23:51:56 +0200 (CEST) Message-ID: <40E5D934.70000@xs4all.nl> Date: Fri, 02 Jul 2004 23:52:52 +0200 From: Stefan de Konink User-Agent: Mozilla Thunderbird 0.7 (X11/20040619) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com Subject: vlan (8021q) 2.6 patches for 3c59x X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------010408040406050300020604" X-archive-position: 6526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skinkie@xs4all.nl Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------010408040406050300020604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit http://bugzilla.kernel.org/show_bug.cgi?id=2991 message requested by Nivedita Singhvi, niv@us.ibm.com I patched the original VLAN patch for the 3Com 3c59x card to make it match a new prototype in 2.6. I would like to request to get it into the mainline kernels. http://www.bewley.net/linux/vlan/patches/ When not applyed, vlantraffic will break if the senders mtu size is too big. Since this patch is around so long for 2.4, but also never applyed, and this is probably the most used card made by 3Com an out of the box working solution would be nice. I hope you can review the code, since it is not written by me I can only tell this works for 3 months on two firewall routers with multiple vlans and interfaces based on Linux 2.6.5. Greetings, Stefan de Konink --------------010408040406050300020604 Content-Type: text/x-patch; name="3c59x-26.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="3c59x-26.patch" *** 3c59x.c.ORG Fri Apr 9 22:19:58 2004 --- 3c59x.c Fri Apr 9 22:20:59 2004 *************** *** 329,334 **** --- 329,337 ---- code size of a per-interface flag is not worthwhile. */ static char mii_preamble_required; + /* The Ethernet Type used for 802.1q tagged frames */ + #define VLAN_ETHER_TYPE 0x8100 + #define PFX DRV_NAME ": " *************** *** 697,703 **** Wn2_ResetOptions=12, }; enum Window3 { /* Window 3: MAC/config bits. */ ! Wn3_Config=0, Wn3_MAC_Ctrl=6, Wn3_Options=8, }; #define BFEXT(value, offset, bitcount) \ --- 700,706 ---- Wn2_ResetOptions=12, }; enum Window3 { /* Window 3: MAC/config bits. */ ! Wn3_Config=0, Wn3_MaxPktSize=4, Wn3_MAC_Ctrl=6, Wn3_Options=8, }; #define BFEXT(value, offset, bitcount) \ *************** *** 725,731 **** Media_LnkBeat = 0x0800, }; enum Window7 { /* Window 7: Bus Master control. */ ! Wn7_MasterAddr = 0, Wn7_MasterLen = 6, Wn7_MasterStatus = 12, }; /* Boomerang bus master control registers. */ enum MasterCtrl { --- 728,735 ---- Media_LnkBeat = 0x0800, }; enum Window7 { /* Window 7: Bus Master control. */ ! Wn7_MasterAddr = 0, Wn7_VlanEtherType=4, Wn7_MasterLen = 6, ! Wn7_MasterStatus = 12, }; /* Boomerang bus master control registers. */ enum MasterCtrl { *************** *** 821,827 **** pm_state_valid:1, /* power_state[] has sane contents */ open:1, medialock:1, ! must_free_region:1; /* Flag: if zero, Cardbus owns the I/O region */ int drv_flags; u16 status_enable; u16 intr_enable; --- 825,832 ---- pm_state_valid:1, /* power_state[] has sane contents */ open:1, medialock:1, ! must_free_region:1, /* Flag: if zero, Cardbus owns the I/O region */ ! large_frames:1; /* accept large frames */ int drv_flags; u16 status_enable; u16 intr_enable; *************** *** 906,911 **** --- 911,920 ---- static void vortex_tx_timeout(struct net_device *dev); static void acpi_set_WOL(struct net_device *dev); static struct ethtool_ops vortex_ethtool_ops; + #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) + static void set_8021q_mode(struct net_device *dev, int enable); + #endif + /* This driver uses 'options' to pass the media type, full-duplex flag, etc. */ /* Option count limit only -- unlimited interfaces are supported. */ *************** *** 1166,1171 **** --- 1175,1181 ---- dev->base_addr = ioaddr; dev->irq = irq; dev->mtu = mtu; + vp->large_frames = mtu > 1500; vp->drv_flags = vci->drv_flags; vp->has_nway = (vci->drv_flags & HAS_NWAY) ? 1 : 0; vp->io_size = vci->io_size; *************** *** 1618,1624 **** /* Set the full-duplex bit. */ outw( ((vp->info1 & 0x8000) || vp->full_duplex ? 0x20 : 0) | ! (dev->mtu > 1500 ? 0x40 : 0) | ((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ? 0x100 : 0), ioaddr + Wn3_MAC_Ctrl); --- 1628,1634 ---- /* Set the full-duplex bit. */ outw( ((vp->info1 & 0x8000) || vp->full_duplex ? 0x20 : 0) | ! (vp->large_frames ? 0x40 : 0) | ((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ? 0x100 : 0), ioaddr + Wn3_MAC_Ctrl); *************** *** 1702,1707 **** --- 1712,1721 ---- } /* Set receiver mode: presumably accept b-case and phys addr only. */ set_rx_mode(dev); + #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) + /* enable 802.1q tagged frames */ + set_8021q_mode(dev, 1); + #endif outw(StatsEnable, ioaddr + EL3_CMD); /* Turn on statistics. */ // issue_and_wait(dev, SetTxStart|0x07ff); *************** *** 1844,1850 **** /* Set the full-duplex bit. */ EL3WINDOW(3); outw( (vp->full_duplex ? 0x20 : 0) | ! (dev->mtu > 1500 ? 0x40 : 0) | ((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ? 0x100 : 0), ioaddr + Wn3_MAC_Ctrl); if (vortex_debug > 1) --- 1858,1864 ---- /* Set the full-duplex bit. */ EL3WINDOW(3); outw( (vp->full_duplex ? 0x20 : 0) | ! (vp->large_frames ? 0x40 : 0) | ((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ? 0x100 : 0), ioaddr + Wn3_MAC_Ctrl); if (vortex_debug > 1) *************** *** 2069,2074 **** --- 2083,2092 ---- issue_and_wait(dev, RxReset|0x07); /* Set the Rx filter to the current state. */ set_rx_mode(dev); + #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) + /* enable 802.1q VLAN tagged frames */ + set_8021q_mode(dev, 1); + #endif outw(RxEnable, ioaddr + EL3_CMD); /* Re-enable the receiver. */ outw(AckIntr | HostError, ioaddr + EL3_CMD); } *************** *** 2673,2678 **** --- 2691,2701 ---- outw(RxDisable, ioaddr + EL3_CMD); outw(TxDisable, ioaddr + EL3_CMD); + #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) + /* Disable receiving 802.1q tagged frames */ + set_8021q_mode(dev, 0); + #endif + if (dev->if_port == XCVR_10base2) /* Turn off thinnet power. Green! */ outw(StopCoax, ioaddr + EL3_CMD); *************** *** 2924,2929 **** --- 2947,2996 ---- outw(new_mode, ioaddr + EL3_CMD); } + #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) + /* Setup the card so that it can receive frames with an 802.1q VLAN tag. + Note that this must be done after each RxReset due to some backwards + compatibility logic in the Cyclone and Tornado ASICs */ + static void set_8021q_mode(struct net_device *dev, int enable) + { + struct vortex_private *vp = (struct vortex_private *)dev->priv; + long ioaddr = dev->base_addr; + int old_window = inw(ioaddr + EL3_CMD); + int mac_ctrl; + + if (vp->drv_flags&IS_CYCLONE || vp->drv_flags&IS_TORNADO) { + /* cyclone and tornado chipsets can recognize 802.1q + * tagged frames and treat them correctly */ + + int max_pkt_size = dev->mtu+14; /* MTU+Ethernet header */ + if (enable) + max_pkt_size += 4; /* 802.1Q VLAN tag */ + + EL3WINDOW(3); + outw(max_pkt_size, ioaddr+Wn3_MaxPktSize); + + /* set VlanEtherType to let the hardware checksumming + treat tagged frames correctly */ + EL3WINDOW(7); + outw(VLAN_ETHER_TYPE, ioaddr+Wn7_VlanEtherType); + } else { + /* on older cards we have to enable large frames */ + + vp->large_frames = dev->mtu > 1500 || enable; + + EL3WINDOW(3); + mac_ctrl = inw(ioaddr+Wn3_MAC_Ctrl); + if (vp->large_frames) + mac_ctrl |= 0x40; + else + mac_ctrl &= ~0x40; + outw(mac_ctrl, ioaddr+Wn3_MAC_Ctrl); + } + + EL3WINDOW(old_window); + } + #endif + /* MII transceiver control section. Read and write the MII registers using software-generated serial MDIO protocol. See the MII specifications or DP83840A data sheet --------------010408040406050300020604-- From herbert@gondor.apana.org.au Fri Jul 2 17:44:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 17:44:31 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i630iJgi018333 for ; Fri, 2 Jul 2004 17:44:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BgYcy-0000vX-00; Sat, 03 Jul 2004 10:43:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BgYci-0007L5-00; Sat, 03 Jul 2004 10:43:20 +1000 Date: Sat, 3 Jul 2004 10:43:20 +1000 To: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com, dev@lists.openswan.org Subject: Proposal for dealing with ICMP black holes for IPsec Message-ID: <20040703004320.GA28139@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1898 Lines: 42 Hi: This is a proposal of a method of detecting the path MTU that can be applied by IPsec keying managers (e.g., openswan/racoon). The problem is that the Internet today contains various ICMP black holes that break normal PMTU discovery. ISPs tend to work around local ICMP black holes by doing TCP MSS clamping. This works fairly well in practice in terms of making the issue transparent to end users. Unfortunately the IPsec implementations available to Linux today cannot take advantage of these TCP clamps. My idea is to use the information available in TCP MSS clamping to help IPsec gateways. This can be done by having the gateways establish a short-lived TCP connection with each other for the purposes of determining the MTU. Obviously this TCP connection will need to be authenticated. If the connection cannot be established (e.g., if an attacker is preventing the gateways from doing so), then we can fall back to the existing MTU discovery mechanisms. If however this connection succeeds, then we can deduce the path MTU from its MSS settings. We can then apply that MTU to the path taken by the IPsec SAs. This makes any ICMP black holes between the gateways invisible to the end users as long as the information provided by TCP MSS clamping is accurate. The advantage of this over the approach taken by KLIPS (the FreeSWAN kernel implementation for IPsec) is that we do not transmit fragments where possible which is the motivation behind PMTU discovery. The advantage of this over the current implementation is that this will work correctly in environments where there are local ICMP black holes that are known through TCP MSS clamping. Comments? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Jul 2 17:51:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 17:51:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i630pbgi018765 for ; Fri, 2 Jul 2004 17:51:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BgYkH-0000xr-00; Sat, 03 Jul 2004 10:51:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BgYk6-0007M3-00; Sat, 03 Jul 2004 10:50:58 +1000 From: Herbert Xu To: paul@xelerance.com (Paul Wouters) Subject: Re: [Openswan dev] IPComp Cc: hugh@mimosa.com, dev@lists.openswan.org, ml@blas.net (Dominique Blas), jmorris@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.net.openswan.dev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Sat, 03 Jul 2004 10:50:58 +1000 X-archive-position: 6529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 922 Lines: 20 Paul Wouters wrote: > > He mailed me the barfs seperately. the key line is: > > Jul 2 15:57:30 vin pluto[29579]: "BRU" #3: ERROR: netlink response for Add SA comp.661a@hhh.hhh.hhh.158 included errno 12: Cannot allocate memory > Jul 2 15:57:30 vin pluto[29579]: "BRU" #4: ERROR: netlink response for Add SA comp.661a@hhh.hhh.hhh.158 included errno 12: Cannot allocate memory These indicate that a kmalloc in the path of adding IPCOMP SAs failed. Hmm, there is a 64K kmalloc in ipcomp_init_state. That's the most likely culprit. What does cat /proc/slabinfo show? James, is there any way to get rid of this kmalloc? It'd also be nice to know exactly what kernel version he is using. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Jul 2 19:09:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 19:09:38 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6329Vgi020425 for ; Fri, 2 Jul 2004 19:09:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BgZxg-0001GL-00; Sat, 03 Jul 2004 12:09:04 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BgZxU-0007Zo-00; Sat, 03 Jul 2004 12:08:52 +1000 Date: Sat, 3 Jul 2004 12:08:52 +1000 To: Jeff Garzik , netdev@oss.sgi.com Subject: Re: Resend: [NETDRV] Fix successive calls to spin_lock_irqsave in sk98lin Message-ID: <20040703020852.GA29105@gondor.apana.org.au> References: <20040701110418.GA10797@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20040701110418.GA10797@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2858 Lines: 86 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff: On Thu, Jul 01, 2004 at 09:04:18PM +1000, herbert wrote: > > This patch fixes the few places in sk98lin where it calls > spin_lock_saveirq on the same flags variable thus causing > interrupts to be disabled upon leaving the driver. That patch doesn't apply with patch -p1. I've fixed it now. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/sk98lin/skge.c 1.38 vs edited ===== --- 1.38/drivers/net/sk98lin/skge.c 2004-03-30 03:57:20 +10:00 +++ edited/drivers/net/sk98lin/skge.c 2004-07-03 12:07:10 +10:00 @@ -3093,8 +3093,7 @@ SkEventDispatcher(pAC, pAC->IoBase); for (i=0; iGIni.GIMacsFound; i++) { - spin_lock_irqsave( - &pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock); netif_stop_queue(pAC->dev[i]); } @@ -4773,12 +4772,10 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); SkGeStopPort(pAC, IoC, FromPort, SK_STOP_ALL, SK_SOFT_RST); SkGeStopPort(pAC, IoC, ToPort, SK_STOP_ALL, SK_SOFT_RST); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4791,8 +4788,7 @@ spin_lock_irqsave( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); - spin_lock_irqsave( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_lock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); pAC->ActivePort = ToPort; #if 0 SetQueueSizes(pAC); @@ -4807,8 +4803,7 @@ pAC, pAC->ActivePort, DualNet)) { - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); @@ -4834,8 +4829,7 @@ SkGePollTxD(pAC, IoC, ToPort, SK_TRUE); ClearAndStartRx(pAC, FromPort); ClearAndStartRx(pAC, ToPort); - spin_unlock_irqrestore( - &pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock, Flags); + spin_unlock(&pAC->TxPort[ToPort][TX_PRIO_LOW].TxDesRingLock); spin_unlock_irqrestore( &pAC->TxPort[FromPort][TX_PRIO_LOW].TxDesRingLock, Flags); --8t9RHnE3ZwKMSgU+-- From hirofumi@mail.parknet.co.jp Fri Jul 2 22:43:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 22:43:12 -0700 (PDT) Received: from mail.parknet.co.jp (mail.parknet.co.jp [210.171.160.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i635h8gi027637 for ; Fri, 2 Jul 2004 22:43:09 -0700 Received: from ibmpc.myhome.or.jp [210.171.164.65] by mail.parknet.co.jp with ESMTP (SMTPD32-4.10) id A87036CF0144; Sat, 03 Jul 2004 14:43:12 +0900 Received: from devron.myhome.or.jp (root@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i635gr4k021345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Jul 2004 14:42:53 +0900 Received: from devron.myhome.or.jp (hirofumi@localhost [127.0.0.1]) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i635gqW8030444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Jul 2004 14:42:52 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) id i635glHF030441; Sat, 3 Jul 2004 14:42:47 +0900 To: Stephen Hemminger Cc: Andrew Morton , Herbert Xu , netdev@oss.sgi.com Subject: Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database References: <20040702004956.448c95d9.akpm@osdl.org> <20040702123022.563ee931.akpm@osdl.org> <20040702125008.25e65252@dell_ss3.pdx.osdl.net> From: OGAWA Hirofumi Date: Sat, 03 Jul 2004 14:42:47 +0900 In-Reply-To: <20040702125008.25e65252@dell_ss3.pdx.osdl.net> Message-ID: <87wu1l3aug.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hirofumi@mail.parknet.co.jp Precedence: bulk X-list: netdev Content-Length: 3667 Lines: 138 Stephen Hemminger writes: > > > Andrew Morton wrote: > > > > > > > > Could someone please take a look at the locking in > > > > net/ipv4/ipmr.c:ipmr_mfc_seq_next? It seems rather broken. > > > > > > Obfuscated yes, broken no. > > > > Really? Even if that goto > > > > if (it->cache == &mfc_unres_queue) > > goto end_of_list; > > > > is taken? > > The problem is that the seq_file interface is trying to create an iterator > over a set of data. The interface expects that the usage will always fit > a given pattern. > > The implied semantic is: > if returned handle is NULL, then nothing is locked and it->cache = NULL > > if returned handle is in the mfc_cache_table then > it->cache points to mfc_cache_array and mrt_lock is held > if returned handle is in the mfc_unres_queue then > it->cache points to mfc_unres_queue and mfc_unres_lock is held > > the seq_next is only valid to mean give me the next entry after the passed handle > therefore if there are no more entries after the handle and the handle was on > the unresolved queue, then the end is reached. > > When seq_stop is called, the it->cache pointer will be NULL so no unlock is done. How about the following patch? At lease, this seems to need ipmr_mfc_release(). Untested patch, sorry. -- OGAWA Hirofumi net/ipv4/ipmr.c | 50 ++++++++++++++++++++++++++------------------------ 1 files changed, 26 insertions(+), 24 deletions(-) diff -puN net/ipv4/ipmr.c~ipmr-cleanup net/ipv4/ipmr.c --- linux-2.6.7/net/ipv4/ipmr.c~ipmr-cleanup 2004-07-03 14:13:50.000000000 +0900 +++ linux-2.6.7-hirofumi/net/ipv4/ipmr.c 2004-07-03 14:30:54.000000000 +0900 @@ -1710,7 +1710,6 @@ struct ipmr_mfc_iter { int ct; }; - static struct mfc_cache *ipmr_mfc_seq_idx(struct ipmr_mfc_iter *it, loff_t pos) { struct mfc_cache *mfc; @@ -1734,7 +1733,6 @@ static struct mfc_cache *ipmr_mfc_seq_id return NULL; } - static void *ipmr_mfc_seq_start(struct seq_file *seq, loff_t *pos) { return *pos ? ipmr_mfc_seq_idx(seq->private, *pos - 1) @@ -1754,31 +1752,29 @@ static void *ipmr_mfc_seq_next(struct se if (mfc->next) return mfc->next; - if (it->cache == &mfc_unres_queue) - goto end_of_list; + if (it->cache == mfc_cache_array) { + while (++it->ct < MFC_LINES) { + mfc = mfc_cache_array[it->ct]; + if (mfc) + return mfc; + } - BUG_ON(it->cache != mfc_cache_array); + /* + * exhausted cache_array, show unresolved. + * So switch to mfc_unres_queue. + */ + read_unlock(&mrt_lock); - while (++it->ct < MFC_LINES) { - mfc = mfc_cache_array[it->ct]; - if (mfc) - return mfc; + it->cache = &mfc_unres_queue; + it->ct = 0; + spin_lock_bh(&mfc_unres_lock); + if (it->cache == mfc_unres_queue) { + mfc = mfc_unres_queue; + if (mfc) + return mfc; + } } - /* exhausted cache_array, show unresolved */ - read_unlock(&mrt_lock); - it->cache = &mfc_unres_queue; - it->ct = 0; - - spin_lock_bh(&mfc_unres_lock); - mfc = mfc_unres_queue; - if (mfc) - return mfc; - - end_of_list: - spin_unlock_bh(&mfc_unres_lock); - it->cache = NULL; - return NULL; } @@ -1854,7 +1850,13 @@ out: out_kfree: kfree(s); goto out; +} +static int ipmr_mfc_release(struct inode *inode, struct file *file) +{ + struct seq_file *seq = file->private_data; + kfree(seq->private); + return seq_release(inode, file); } static struct file_operations ipmr_mfc_fops = { @@ -1862,7 +1864,7 @@ static struct file_operations ipmr_mfc_f .open = ipmr_mfc_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release, + .release = ipmr_mfc_release, }; #endif _ From herbert@gondor.apana.org.au Fri Jul 2 23:13:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 23:13:40 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i636DXgi028789 for ; Fri, 2 Jul 2004 23:13:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bgdm8-0002B8-00; Sat, 03 Jul 2004 16:13:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bgdm4-0006I3-00; Sat, 03 Jul 2004 16:13:20 +1000 Date: Sat, 3 Jul 2004 16:13:20 +1000 To: OGAWA Hirofumi Cc: Stephen Hemminger , Andrew Morton , netdev@oss.sgi.com Subject: Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database Message-ID: <20040703061320.GA24115@gondor.apana.org.au> References: <20040702004956.448c95d9.akpm@osdl.org> <20040702123022.563ee931.akpm@osdl.org> <20040702125008.25e65252@dell_ss3.pdx.osdl.net> <87wu1l3aug.fsf@devron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wu1l3aug.fsf@devron.myhome.or.jp> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 913 Lines: 34 On Sat, Jul 03, 2004 at 02:42:47PM +0900, OGAWA Hirofumi wrote: > > @@ -1854,7 +1850,13 @@ out: > out_kfree: > kfree(s); > goto out; > +} > > +static int ipmr_mfc_release(struct inode *inode, struct file *file) > +{ > + struct seq_file *seq = file->private_data; > + kfree(seq->private); > + return seq_release(inode, file); > } > > static struct file_operations ipmr_mfc_fops = { > @@ -1862,7 +1864,7 @@ static struct file_operations ipmr_mfc_f > .open = ipmr_mfc_open, > .read = seq_read, > .llseek = seq_lseek, > - .release = seq_release, > + .release = ipmr_mfc_release, > }; > #endif This is a good catch. But you probably need to fix the vif stuff as well. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jgarzik@pobox.com Fri Jul 2 23:17:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 23:17:56 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i636Hsgi029129 for ; Fri, 2 Jul 2004 23:17:54 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BgdqT-0004GL-FK; Sat, 03 Jul 2004 07:17:53 +0100 Message-ID: <40E64F84.40302@pobox.com> Date: Sat, 03 Jul 2004 02:17:40 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Gigabit Ethernet support for forcedeth References: <40E25328.8020102@colorfullife.com> <40E25944.8010200@pobox.com> <40E2E618.5020601@colorfullife.com> <40E30CA7.3020209@colorfullife.com> <40E5847F.8030808@pobox.com> <40E5B788.80302@colorfullife.com> In-Reply-To: <40E5B788.80302@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Fri Jul 2 23:21:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jul 2004 23:21:39 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i636Lbgi029468 for ; Fri, 2 Jul 2004 23:21:38 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bgdu4-0004Mp-Ml; Sat, 03 Jul 2004 07:21:36 +0100 Message-ID: <40E65064.6090009@pobox.com> Date: Sat, 03 Jul 2004 02:21:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, alan@redhat.com, akpm@osdl.org Subject: Re: [PATCH 2.6.7-mm3 1/1] via-velocity: use common crc16 code for WOL References: <20040630223346.A23520@electric-eye.fr.zoreil.com> In-Reply-To: <20040630223346.A23520@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From hirofumi@mail.parknet.co.jp Sat Jul 3 01:03:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 01:03:44 -0700 (PDT) Received: from mail.parknet.co.jp (mail.parknet.co.jp [210.171.160.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6383egi004143 for ; Sat, 3 Jul 2004 01:03:41 -0700 Received: from ibmpc.myhome.or.jp [210.171.164.65] by mail.parknet.co.jp with ESMTP (SMTPD32-4.10) id A963371A0150; Sat, 03 Jul 2004 17:03:47 +0900 Received: from devron.myhome.or.jp (root@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i6383Q7U027402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Jul 2004 17:03:27 +0900 Received: from devron.myhome.or.jp (hirofumi@localhost [127.0.0.1]) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i6383PZu031436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Jul 2004 17:03:25 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) id i6383OD5031433; Sat, 3 Jul 2004 17:03:24 +0900 To: Herbert Xu Cc: Stephen Hemminger , Andrew Morton , netdev@oss.sgi.com Subject: Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database References: <20040702004956.448c95d9.akpm@osdl.org> <20040702123022.563ee931.akpm@osdl.org> <20040702125008.25e65252@dell_ss3.pdx.osdl.net> <87wu1l3aug.fsf@devron.myhome.or.jp> <20040703061320.GA24115@gondor.apana.org.au> From: OGAWA Hirofumi Date: Sat, 03 Jul 2004 17:03:24 +0900 In-Reply-To: <20040703061320.GA24115@gondor.apana.org.au> Message-ID: <874qopbjqr.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hirofumi@mail.parknet.co.jp Precedence: bulk X-list: netdev Content-Length: 3717 Lines: 159 Herbert Xu writes: > > +static int ipmr_mfc_release(struct inode *inode, struct file *file) > > +{ > > + struct seq_file *seq = file->private_data; > > + kfree(seq->private); > > + return seq_release(inode, file); > > } > > > > static struct file_operations ipmr_mfc_fops = { > > @@ -1862,7 +1864,7 @@ static struct file_operations ipmr_mfc_f > > .open = ipmr_mfc_open, > > .read = seq_read, > > .llseek = seq_lseek, > > - .release = seq_release, > > + .release = ipmr_mfc_release, > > }; > > #endif > > This is a good catch. But you probably need to fix the vif stuff as > well. Yes, right. I didn't notice it. Thanks. - use seq_release_private for ipmr_vif/mfc_fops. The anothor bug, it->cache need in *->seq_start* by NULL. Otherwise, it->cache can be pointed the previous state by lseek(). e.g. ->seq_next() it->cache = &mfc_unres_queue ->seq_stop() lseek() ->seq_start() return SEQ_START_TOKEN (it->cache still has &mfc_unres_queue) ->seq_show() ->seq_stop() bang Thanks. -- OGAWA Hirofumi --- net/ipv4/ipmr.c | 45 ++++++++++++++++++++------------------------- 1 files changed, 20 insertions(+), 25 deletions(-) diff -puN net/ipv4/ipmr.c~ipmr-cleanup net/ipv4/ipmr.c --- linux-2.6.7/net/ipv4/ipmr.c~ipmr-cleanup 2004-07-03 14:13:50.000000000 +0900 +++ linux-2.6.7-hirofumi/net/ipv4/ipmr.c 2004-07-03 16:53:05.000000000 +0900 @@ -1702,7 +1702,7 @@ static struct file_operations ipmr_vif_f .open = ipmr_vif_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release, + .release = seq_release_private, }; struct ipmr_mfc_iter { @@ -1710,7 +1710,6 @@ struct ipmr_mfc_iter { int ct; }; - static struct mfc_cache *ipmr_mfc_seq_idx(struct ipmr_mfc_iter *it, loff_t pos) { struct mfc_cache *mfc; @@ -1734,9 +1733,11 @@ static struct mfc_cache *ipmr_mfc_seq_id return NULL; } - static void *ipmr_mfc_seq_start(struct seq_file *seq, loff_t *pos) { + struct ipmr_mfc_iter *it = seq->private; + it->cache = NULL; + it->ct = 0; return *pos ? ipmr_mfc_seq_idx(seq->private, *pos - 1) : SEQ_START_TOKEN; } @@ -1754,31 +1755,27 @@ static void *ipmr_mfc_seq_next(struct se if (mfc->next) return mfc->next; - if (it->cache == &mfc_unres_queue) - goto end_of_list; + if (it->cache == mfc_cache_array) { + while (++it->ct < MFC_LINES) { + mfc = mfc_cache_array[it->ct]; + if (mfc) + return mfc; + } - BUG_ON(it->cache != mfc_cache_array); + /* + * exhausted cache_array, show unresolved. + * So switch to mfc_unres_queue. + */ + read_unlock(&mrt_lock); - while (++it->ct < MFC_LINES) { - mfc = mfc_cache_array[it->ct]; + it->cache = &mfc_unres_queue; + it->ct = 0; + spin_lock_bh(&mfc_unres_lock); + mfc = mfc_unres_queue; if (mfc) return mfc; } - /* exhausted cache_array, show unresolved */ - read_unlock(&mrt_lock); - it->cache = &mfc_unres_queue; - it->ct = 0; - - spin_lock_bh(&mfc_unres_lock); - mfc = mfc_unres_queue; - if (mfc) - return mfc; - - end_of_list: - spin_unlock_bh(&mfc_unres_lock); - it->cache = NULL; - return NULL; } @@ -1846,7 +1843,6 @@ static int ipmr_mfc_open(struct inode *i if (rc) goto out_kfree; - memset(s, 0, sizeof(*s)); seq = file->private_data; seq->private = s; out: @@ -1854,7 +1850,6 @@ out: out_kfree: kfree(s); goto out; - } static struct file_operations ipmr_mfc_fops = { @@ -1862,7 +1857,7 @@ static struct file_operations ipmr_mfc_f .open = ipmr_mfc_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release, + .release = seq_release_private, }; #endif _ From herbert@gondor.apana.org.au Sat Jul 3 02:46:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 02:46:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i639khgi009465 for ; Sat, 3 Jul 2004 02:46:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bgh6S-0002q1-00; Sat, 03 Jul 2004 19:46:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bgh6P-00046h-00; Sat, 03 Jul 2004 19:46:33 +1000 Date: Sat, 3 Jul 2004 19:46:32 +1000 To: Stephen Hemminger , netdev@oss.sgi.com Subject: [PATCH] Add nl_open to libnetlink Message-ID: <20040703094632.GA14235@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2288 Lines: 69 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Stephen: I'm in the process of writing two new modules fo ip(8), ippolicy and ipstate which will be a NETLINK based replacement for setkey. In order to do so, I need to get libnetlink to speak the XFRM protocol. Thus I've added a new nl_open function which allows the protocol to be specified. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: include/libnetlink.h =================================================================== RCS file: /home/gondolin/herbert/src/CVS/iproute/include/libnetlink.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- include/libnetlink.h 2 Jul 2004 17:53:03 -0000 1.1.1.1 +++ include/libnetlink.h 3 Jul 2004 09:34:05 -0000 1.2 @@ -15,6 +15,7 @@ }; extern int rtnl_open(struct rtnl_handle *rth, unsigned subscriptions); +extern int nl_open(struct rtnl_handle *rth, unsigned subscriptions, int proto); extern void rtnl_close(struct rtnl_handle *rth); extern int rtnl_wilddump_request(struct rtnl_handle *rth, int fam, int type); extern int rtnl_dump_request(struct rtnl_handle *rth, int type, void *req, int len); Index: lib/libnetlink.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/iproute/lib/libnetlink.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- lib/libnetlink.c 2 Jul 2004 17:53:03 -0000 1.1.1.1 +++ lib/libnetlink.c 3 Jul 2004 09:34:06 -0000 1.2 @@ -32,11 +32,16 @@ int rtnl_open(struct rtnl_handle *rth, unsigned subscriptions) { + return nl_open(rth, subscriptions, NETLINK_ROUTE); +} + +int nl_open(struct rtnl_handle *rth, unsigned subscriptions, int proto) +{ int addr_len; memset(rth, 0, sizeof(rth)); - rth->fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE); + rth->fd = socket(AF_NETLINK, SOCK_RAW, proto); if (rth->fd < 0) { perror("Cannot open netlink socket"); return -1; --IJpNTDwzlM2Ie8A6-- From herbert@gondor.apana.org.au Sat Jul 3 02:52:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 02:52:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i639qQgi009834 for ; Sat, 3 Jul 2004 02:52:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BghC0-0002rI-00; Sat, 03 Jul 2004 19:52:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BghBw-0004De-00; Sat, 03 Jul 2004 19:52:16 +1000 Date: Sat, 3 Jul 2004 19:52:15 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [XFRM] Convert XFRM_MSG_* macros to an enum Message-ID: <20040703095215.GA16195@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1987 Lines: 74 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I'd like to add two new xfrm_user messages, FLUSHSA and FLUSHPOLICY. I've cleaned up the existing MSG definitions by converting them to an enum. This should make future additions slightly easier in that XFRM_MSG_MAX won't have to be touched again. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/xfrm.h 1.20 vs edited ===== --- 1.20/include/linux/xfrm.h 2004-05-30 05:35:21 +10:00 +++ edited/include/linux/xfrm.h 2004-07-03 19:43:11 +10:00 @@ -103,26 +103,28 @@ }; /* Netlink configuration messages. */ -#define XFRM_MSG_BASE 0x10 +enum { + XFRM_MSG_BASE = 0x10, -#define XFRM_MSG_NEWSA (XFRM_MSG_BASE + 0) -#define XFRM_MSG_DELSA (XFRM_MSG_BASE + 1) -#define XFRM_MSG_GETSA (XFRM_MSG_BASE + 2) + XFRM_MSG_NEWSA = 0x10, + XFRM_MSG_DELSA, + XFRM_MSG_GETSA, -#define XFRM_MSG_NEWPOLICY (XFRM_MSG_BASE + 3) -#define XFRM_MSG_DELPOLICY (XFRM_MSG_BASE + 4) -#define XFRM_MSG_GETPOLICY (XFRM_MSG_BASE + 5) + XFRM_MSG_NEWPOLICY, + XFRM_MSG_DELPOLICY, + XFRM_MSG_GETPOLICY, -#define XFRM_MSG_ALLOCSPI (XFRM_MSG_BASE + 6) -#define XFRM_MSG_ACQUIRE (XFRM_MSG_BASE + 7) -#define XFRM_MSG_EXPIRE (XFRM_MSG_BASE + 8) + XFRM_MSG_ALLOCSPI, + XFRM_MSG_ACQUIRE, + XFRM_MSG_EXPIRE, -#define XFRM_MSG_UPDPOLICY (XFRM_MSG_BASE + 9) -#define XFRM_MSG_UPDSA (XFRM_MSG_BASE + 10) + XFRM_MSG_UPDPOLICY, + XFRM_MSG_UPDSA, -#define XFRM_MSG_POLEXPIRE (XFRM_MSG_BASE + 11) + XFRM_MSG_POLEXPIRE, -#define XFRM_MSG_MAX (XFRM_MSG_POLEXPIRE+1) + XFRM_MSG_MAX +}; struct xfrm_user_tmpl { struct xfrm_id id; --y0ulUmNC+osPPQO6-- From yoshfuji@linux-ipv6.org Sat Jul 3 02:59:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 02:59:39 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i639xZgi010238 for ; Sat, 3 Jul 2004 02:59:36 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4391433CE5; Sat, 3 Jul 2004 19:00:47 +0900 (JST) Date: Sat, 03 Jul 2004 19:00:42 +0900 (JST) Message-Id: <20040703.190042.70899669.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [XFRM] Convert XFRM_MSG_* macros to an enum From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040703095215.GA16195@gondor.apana.org.au> References: <20040703095215.GA16195@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 543 Lines: 16 In article <20040703095215.GA16195@gondor.apana.org.au> (at Sat, 3 Jul 2004 19:52:15 +1000), Herbert Xu says: > I've cleaned up the existing MSG definitions by converting them to > an enum. This should make future additions slightly easier in that > XFRM_MSG_MAX won't have to be touched again. > > Signed-off-by: Herbert Xu Well, I think we'd better to do #define XFRM_MSG_GETSA XFRM_MSG_GETSA etc. because this would break (future) applications which do #ifdef. --yoshfuji From herbert@gondor.apana.org.au Sat Jul 3 03:02:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 03:02:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63A2Lgi010603 for ; Sat, 3 Jul 2004 03:02:22 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BghLW-0002vA-00; Sat, 03 Jul 2004 20:02:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BghLU-0004Ft-00; Sat, 03 Jul 2004 20:02:08 +1000 Date: Sat, 3 Jul 2004 20:02:08 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [XFRM] Convert XFRM_MSG_* macros to an enum Message-ID: <20040703100208.GA16339@gondor.apana.org.au> References: <20040703095215.GA16195@gondor.apana.org.au> <20040703.190042.70899669.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040703.190042.70899669.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 661 Lines: 22 On Sat, Jul 03, 2004 at 07:00:42PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Well, I think we'd better to do > > #define XFRM_MSG_GETSA XFRM_MSG_GETSA > > etc. because this would break (future) applications which do > #ifdef. I think such applications are broken. They should compile with headers that define these symbols and test for their support at run-time. Applications should not detect kernel features at compile-time. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Sat Jul 3 03:03:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 03:03:29 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63A3Qgi010898 for ; Sat, 3 Jul 2004 03:03:26 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4653033CE5; Sat, 3 Jul 2004 19:04:40 +0900 (JST) Date: Sat, 03 Jul 2004 19:04:34 +0900 (JST) Message-Id: <20040703.190434.119517848.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [XFRM] Convert XFRM_MSG_* macros to an enum From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040703.190042.70899669.yoshfuji@linux-ipv6.org> References: <20040703095215.GA16195@gondor.apana.org.au> <20040703.190042.70899669.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 6545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 750 Lines: 21 To clarify: In article <20040703.190042.70899669.yoshfuji@linux-ipv6.org> (at Sat, 03 Jul 2004 19:00:42 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > > I've cleaned up the existing MSG definitions by converting them to > > an enum. This should make future additions slightly easier in that > > XFRM_MSG_MAX won't have to be touched again. : > Well, I think we'd better to do > > #define XFRM_MSG_GETSA XFRM_MSG_GETSA > > etc. because this would break (future) applications which do > #ifdef. I meant, the change (without #define) would break (future) applications which do #ifdef. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Sat Jul 3 03:11:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 03:11:19 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63ABCgi011395 for ; Sat, 3 Jul 2004 03:11:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BghU5-0002zA-00; Sat, 03 Jul 2004 20:11:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BghU2-0004s5-00; Sat, 03 Jul 2004 20:10:58 +1000 Date: Sat, 3 Jul 2004 20:10:58 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [XFRM] Convert XFRM_MSG_* macros to an enum Message-ID: <20040703101058.GA18173@gondor.apana.org.au> References: <20040703095215.GA16195@gondor.apana.org.au> <20040703.190042.70899669.yoshfuji@linux-ipv6.org> <20040703100208.GA16339@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20040703100208.GA16339@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1940 Lines: 71 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jul 03, 2004 at 08:02:08PM +1000, herbert wrote: > > I think such applications are broken. > > They should compile with headers that define these symbols and > test for their support at run-time. > > Applications should not detect kernel features at compile-time. Well, I guess there are always going to be broken applications. I'd move on rather than dwell on this point. So here is an add-on patch to add the macros. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/xfrm.h 1.21 vs edited ===== --- 1.21/include/linux/xfrm.h 2004-07-03 19:53:19 +10:00 +++ edited/include/linux/xfrm.h 2004-07-03 20:07:15 +10:00 @@ -107,21 +107,33 @@ XFRM_MSG_BASE = 0x10, XFRM_MSG_NEWSA = 0x10, +#define XFRM_MSG_NEWSA XFRM_MSG_NEWSA XFRM_MSG_DELSA, +#define XFRM_MSG_DELSA XFRM_MSG_DELSA XFRM_MSG_GETSA, +#define XFRM_MSG_GETSA XFRM_MSG_GETSA XFRM_MSG_NEWPOLICY, +#define XFRM_MSG_NEWPOLICY XFRM_MSG_NEWPOLICY XFRM_MSG_DELPOLICY, +#define XFRM_MSG_DELPOLICY XFRM_MSG_DELPOLICY XFRM_MSG_GETPOLICY, +#define XFRM_MSG_GETPOLICY XFRM_MSG_GETPOLICY XFRM_MSG_ALLOCSPI, +#define XFRM_MSG_ALLOCSPI XFRM_MSG_ALLOCSPI XFRM_MSG_ACQUIRE, +#define XFRM_MSG_ACQUIRE XFRM_MSG_ACQUIRE XFRM_MSG_EXPIRE, +#define XFRM_MSG_EXPIRE XFRM_MSG_EXPIRE XFRM_MSG_UPDPOLICY, +#define XFRM_MSG_UPDPOLICY XFRM_MSG_UPDPOLICY XFRM_MSG_UPDSA, +#define XFRM_MSG_UPDSA XFRM_MSG_UPDSA XFRM_MSG_POLEXPIRE, +#define XFRM_MSG_POLEXPIRE XFRM_MSG_POLEXPIRE XFRM_MSG_MAX }; --GvXjxJ+pjyke8COw-- From paul@xelerance.com Sat Jul 3 04:11:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 04:11:19 -0700 (PDT) Received: from expansionpack.xtdnet.nl ([193.110.157.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63BBAgi013297 for ; Sat, 3 Jul 2004 04:11:12 -0700 Received: from mail.xtdnet.nl (mail.xtdnet.nl [193.110.157.5]) by expansionpack.xtdnet.nl (8.12.8/8.11.6) with ESMTP id i63B2uma028140 (using TLSv1/SSLv3 with cipher EDH-DSS-DES-CBC3-SHA (168 bits) verified NO); Sat, 3 Jul 2004 13:02:57 +0200 Date: Sat, 3 Jul 2004 13:02:56 +0200 (MET DST) From: Paul Wouters X-X-Sender: paul@expansionpack.xtdnet.nl To: Herbert Xu cc: Paul Wouters , "D. Hugh Redelmeier" , , Dominique Blas , , Subject: Re: [Openswan dev] IPComp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-archive-position: 6547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paul@xelerance.com Precedence: bulk X-list: netdev Content-Length: 894 Lines: 27 On Sat, 3 Jul 2004, Herbert Xu wrote: > > He mailed me the barfs seperately. the key line is: > > > > Jul 2 15:57:30 vin pluto[29579]: "BRU" #3: ERROR: netlink response for Add SA comp.661a@hhh.hhh.hhh.158 included errno 12: Cannot allocate memory > > Jul 2 15:57:30 vin pluto[29579]: "BRU" #4: ERROR: netlink response for Add SA comp.661a@hhh.hhh.hhh.158 included errno 12: Cannot allocate memory > > These indicate that a kmalloc in the path of adding IPCOMP SAs failed. > > Hmm, there is a 64K kmalloc in ipcomp_init_state. That's the most likely > culprit. What does cat /proc/slabinfo show? That information is not listed in the barf. > It'd also be nice to know exactly what kernel version he is using. 2.6.5 He seems to have generic memory problems though, so I don't think this is an openswan or kernel ipsec bug. Paul -- IRC is just multiplayer notepad. From christopherc@team.outblaze.com Sat Jul 3 04:29:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 04:29:49 -0700 (PDT) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63BTkgi017105 for ; Sat, 3 Jul 2004 04:29:46 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 48F8637AD8 for ; Sat, 3 Jul 2004 11:29:46 +0000 (GMT) Received: from smtp1.hk1.outblaze.com (smtp1.hk1.outblaze.com [203.86.166.80]) by corpmail.outblaze.com (Postfix) with SMTP id 1BC0816DD96 for ; Sat, 3 Jul 2004 11:29:46 +0000 (GMT) Received: (qmail 30311 invoked from network); 3 Jul 2004 11:29:38 -0000 Received: from unknown (HELO ?192.168.1.17?) (christopherc@team.outblaze.com@202.81.246.192) by smtp1.hk1.outblaze.com with SMTP; 3 Jul 2004 11:29:38 -0000 Message-ID: <40E69930.1080402@outblaze.com> Date: Sat, 03 Jul 2004 19:32:00 +0800 From: Christopher Chan User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: dst cache overflow errors Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.2-5; VAE: 6.26.0.3; VDF: 6.26.0.13; host: corpmail.outblaze.com) X-archive-position: 6548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cchan@outblaze.com Precedence: bulk X-list: netdev Content-Length: 493 Lines: 14 Hello, Recently, the Intel chaps wanted to have NAPI permanently enabled for their e100 driver. However, i still get network connectivity problems if I enable NAPI in e100 for 2.6.7. Severe cases result in the kernel not logging clear messages about its bug traps...due to the messages being obfuscated beyond understanding. I wonder then whether the cause/problem, that makes the kernel log dst cache overflows and its BUG_TRAPs in the logs, has been identified? Thanks, Christopher From herbert@gondor.apana.org.au Sat Jul 3 04:45:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 04:45:18 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63BjAgi017603 for ; Sat, 3 Jul 2004 04:45:12 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bgiq7-0003MK-00; Sat, 03 Jul 2004 21:37:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bgipo-0005km-00; Sat, 03 Jul 2004 21:37:32 +1000 Date: Sat, 3 Jul 2004 21:37:32 +1000 To: Paul Wouters Cc: "D. Hugh Redelmeier" , dev@lists.openswan.org, Dominique Blas , jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: [Openswan dev] IPComp Message-ID: <20040703113732.GA22082@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 901 Lines: 23 On Sat, Jul 03, 2004 at 01:02:56PM +0200, Paul Wouters wrote: > > He seems to have generic memory problems though, so I don't think this is an > openswan or kernel ipsec bug. He's probably having a memory fragmentation problem, but allocating 64K physically contiguous memory is something that should never be done over and over again. As the IPCOMP init function is called regularly, this needs to be fixed. I haven't looked at the IPCOMP code in detail, but I'd guess that we're allocating 64K as the largest IP packet size is 64K. Would it be possible to adjust the size of the buffer according to the packet size and allocate it in ipcomp_input()/ipcomp_output() instead? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ml@blas.net Sat Jul 3 04:45:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 04:45:29 -0700 (PDT) Received: from db.blas.net (free.blas.net [82.224.43.127]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63BjLgi017611 for ; Sat, 3 Jul 2004 04:45:22 -0700 Received: from db.local.blas.net (localhost [127.0.0.1]) by db.blas.net (Postfix) with ESMTP id 7A784BF4BF; Sat, 3 Jul 2004 13:45:14 +0200 (CEST) From: Dominique Blas Organization: DB To: Paul Wouters Subject: Re: [Openswan dev] IPComp Date: Sat, 3 Jul 2004 13:45:10 +0200 User-Agent: KMail/1.6.2 Cc: Herbert Xu , "D. Hugh Redelmeier" , , , References: In-Reply-To: HTML: text/html MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_Gxp5AgcDKWYXuES" Message-Id: <200407031345.10313@db> X-archive-position: 6550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ml@blas.net Precedence: bulk X-list: netdev Content-Length: 26896 Lines: 293 --Boundary-00=_Gxp5AgcDKWYXuES Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le samedi 3 Juillet 2004 13:02, Paul Wouters a =E9crit : (...) > 2.6.5=20 >=20 > He seems to have generic memory problems though, so I don't think this = is an=20 > openswan or kernel ipsec bug. No it doesn't seem to be an openswan or kernel ipsec bug.=20 Did you all read my mail from this night (0254 am) ? i explained there that It seems that openswan suffers under poor memory c= onditions whereas when there is plenty of memory everything works=20 fine. I confirm that under these poor memory conditions, using compress=3Dyes l= imits the return packets ( SFS -> OS2) to 348 bytes whereas with compress= =3Dno there is no such limitation (but faled memory allocations in this case but not always). >=20 > Paul Please find in attachment the slabinfo with compress and the slabinfo wit= hout compress tag in ipsec.conf. Rgds, db --Boundary-00=_Gxp5AgcDKWYXuES Content-Type: text/plain; charset="iso-8859-1"; name="slabinfo.wcompress" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slabinfo.wcompress" slabinfo - version: 2.0 # name : tunables : slabdata ip_fib_hash 32 200 16 200 1 : tunables 120 60 0 : slabdata 1 1 0 clip_arp_cache 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 fib6_nodes 9 112 32 112 1 : tunables 120 60 0 : slabdata 1 1 0 ip6_dst_cache 13 30 256 15 1 : tunables 120 60 0 : slabdata 2 2 0 ndisc_cache 1 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0 raw6_sock 0 0 640 6 1 : tunables 54 27 0 : slabdata 0 0 0 udp6_sock 2 6 640 6 1 : tunables 54 27 0 : slabdata 1 1 0 tcp6_sock 5 7 1152 7 2 : tunables 24 12 0 : slabdata 1 1 0 unix_sock 6 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0 ip_vs_conn 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 ip_conntrack 1206 2060 384 10 1 : tunables 54 27 0 : slabdata 206 206 0 ip_mrt_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 tcp_tw_bucket 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 tcp_bind_bucket 1 200 16 200 1 : tunables 120 60 0 : slabdata 1 1 0 tcp_open_request 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 inet_peer_cache 71 116 64 58 1 : tunables 120 60 0 : slabdata 2 2 0 secpath_cache 16 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0 xfrm_dst_cache 10 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0 ip_dst_cache 4633 4660 384 10 1 : tunables 54 27 0 : slabdata 466 466 0 arp_cache 23 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0 raw4_sock 0 0 512 7 1 : tunables 54 27 0 : slabdata 0 0 0 udp_sock 16 21 512 7 1 : tunables 54 27 0 : slabdata 3 3 0 tcp_sock 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0 flow_cache 534 870 128 30 1 : tunables 120 60 0 : slabdata 29 29 0 hpsb_packet 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 udf_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 romfs_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 smb_request 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 smb_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 isofs_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 fat_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 minix_inode_cache 0 0 512 7 1 : tunables 54 27 0 : slabdata 0 0 0 ext2_inode_cache 0 0 512 7 1 : tunables 54 27 0 : slabdata 0 0 0 ext2_xattr 0 0 44 84 1 : tunables 120 60 0 : slabdata 0 0 0 journal_handle 16 123 28 123 1 : tunables 120 60 0 : slabdata 1 1 0 journal_head 119 462 48 77 1 : tunables 120 60 0 : slabdata 6 6 0 revoke_table 4 250 12 250 1 : tunables 120 60 0 : slabdata 1 1 0 revoke_record 0 0 16 200 1 : tunables 120 60 0 : slabdata 0 0 0 ext3_inode_cache 989 1638 512 7 1 : tunables 54 27 0 : slabdata 234 234 0 ext3_xattr 0 0 44 84 1 : tunables 120 60 0 : slabdata 0 0 0 dquot 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 eventpoll_pwq 0 0 36 99 1 : tunables 120 60 0 : slabdata 0 0 0 eventpoll_epi 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 kioctx 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 kiocb 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 dnotify_cache 0 0 20 166 1 : tunables 120 60 0 : slabdata 0 0 0 file_lock_cache 0 0 92 41 1 : tunables 120 60 0 : slabdata 0 0 0 fasync_cache 0 0 16 200 1 : tunables 120 60 0 : slabdata 0 0 0 shmem_inode_cache 3 7 512 7 1 : tunables 54 27 0 : slabdata 1 1 0 posix_timers_cache 0 0 80 48 1 : tunables 120 60 0 : slabdata 0 0 0 uid_cache 0 0 32 112 1 : tunables 120 60 0 : slabdata 0 0 0 bt_sock 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 sgpool-128 32 32 2048 2 1 : tunables 24 12 0 : slabdata 16 16 0 sgpool-64 32 32 1024 4 1 : tunables 54 27 0 : slabdata 8 8 0 sgpool-32 32 32 512 8 1 : tunables 54 27 0 : slabdata 4 4 0 sgpool-16 32 45 256 15 1 : tunables 120 60 0 : slabdata 3 3 0 sgpool-8 32 60 128 30 1 : tunables 120 60 0 : slabdata 2 2 0 deadline_drq 0 0 48 77 1 : tunables 120 60 0 : slabdata 0 0 0 as_arq 10 61 60 61 1 : tunables 120 60 0 : slabdata 1 1 0 blkdev_requests 13 52 152 26 1 : tunables 120 60 0 : slabdata 2 2 0 biovec-BIO_MAX_PAGES 6 6 3072 2 2 : tunables 24 12 0 : slabdata 3 3 0 biovec-128 12 15 1536 5 2 : tunables 24 12 0 : slabdata 3 3 0 biovec-64 25 25 768 5 1 : tunables 54 27 0 : slabdata 5 5 0 biovec-16 50 60 256 15 1 : tunables 120 60 0 : slabdata 4 4 0 biovec-4 100 116 64 58 1 : tunables 120 60 0 : slabdata 2 2 0 biovec-1 163 200 16 200 1 : tunables 120 60 0 : slabdata 1 1 0 bio 276 348 64 58 1 : tunables 120 60 0 : slabdata 6 6 0 sock_inode_cache 39 50 384 10 1 : tunables 54 27 0 : slabdata 5 5 0 skbuff_head_cache 166 270 256 15 1 : tunables 120 60 0 : slabdata 18 18 0 sock 8 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0 proc_inode_cache 194 210 384 10 1 : tunables 54 27 0 : slabdata 21 21 0 sigqueue 4 26 144 26 1 : tunables 120 60 0 : slabdata 1 1 0 radix_tree_node 314 360 260 15 1 : tunables 54 27 0 : slabdata 24 24 0 bdev_cache 4 7 512 7 1 : tunables 54 27 0 : slabdata 1 1 0 mnt_cache 14 58 64 58 1 : tunables 120 60 0 : slabdata 1 1 0 inode_cache 1303 1310 384 10 1 : tunables 54 27 0 : slabdata 131 131 0 dentry_cache 1919 2130 256 15 1 : tunables 120 60 0 : slabdata 142 142 0 filp 141 165 256 15 1 : tunables 120 60 0 : slabdata 11 11 0 names_cache 2 2 4096 1 1 : tunables 24 12 0 : slabdata 2 2 0 idr_layer_cache 3 28 136 28 1 : tunables 120 60 0 : slabdata 1 1 0 buffer_head 4550 10087 48 77 1 : tunables 120 60 0 : slabdata 131 131 0 mm_struct 28 28 512 7 1 : tunables 54 27 0 : slabdata 4 4 0 vm_area_struct 253 406 64 58 1 : tunables 120 60 0 : slabdata 7 7 0 fs_cache 29 112 32 112 1 : tunables 120 60 0 : slabdata 1 1 0 files_cache 17 21 512 7 1 : tunables 54 27 0 : slabdata 3 3 0 signal_cache 33 58 64 58 1 : tunables 120 60 0 : slabdata 1 1 0 sighand_cache 28 35 1408 5 2 : tunables 24 12 0 : slabdata 7 7 0 task_struct 34 40 1440 5 2 : tunables 24 12 0 : slabdata 8 8 0 pte_chain 629 1020 128 30 1 : tunables 120 60 0 : slabdata 34 34 0 pgd 20 20 4096 1 1 : tunables 24 12 0 : slabdata 20 20 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 15 15 65536 1 16 : tunables 8 4 0 : slabdata 15 15 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 38 42 8192 1 2 : tunables 8 4 0 : slabdata 38 42 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 0 : slabdata 0 0 0 size-4096 18 18 4096 1 1 : tunables 24 12 0 : slabdata 18 18 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 0 : slabdata 0 0 0 size-2048 134 134 2048 2 1 : tunables 24 12 0 : slabdata 67 67 0 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 0 : slabdata 0 0 0 size-1024 48 48 1024 4 1 : tunables 54 27 0 : slabdata 12 12 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 0 : slabdata 0 0 0 size-512 8949 8960 512 8 1 : tunables 54 27 0 : slabdata 1120 1120 0 size-256(DMA) 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 size-256 231 240 256 15 1 : tunables 120 60 0 : slabdata 16 16 0 size-128(DMA) 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 size-128 3028 3060 128 30 1 : tunables 120 60 0 : slabdata 102 102 0 size-64(DMA) 0 0 64 58 1 : tunables 120 60 0 : slabdata 0 0 0 size-64 1137 1160 64 58 1 : tunables 120 60 0 : slabdata 20 20 0 size-32(DMA) 0 0 32 112 1 : tunables 120 60 0 : slabdata 0 0 0 size-32 1344 1344 32 112 1 : tunables 120 60 0 : slabdata 12 12 0 kmem_cache 132 132 116 33 1 : tunables 120 60 0 : slabdata 4 4 0 --Boundary-00=_Gxp5AgcDKWYXuES Content-Type: text/plain; charset="iso-8859-1"; name="slabinfo.wocompress" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slabinfo.wocompress" slabinfo - version: 2.0 # name : tunables : slabdata ip_fib_hash 32 200 16 200 1 : tunables 120 60 0 : slabdata 1 1 0 clip_arp_cache 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 fib6_nodes 9 112 32 112 1 : tunables 120 60 0 : slabdata 1 1 0 ip6_dst_cache 13 30 256 15 1 : tunables 120 60 0 : slabdata 2 2 0 ndisc_cache 1 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0 raw6_sock 0 0 640 6 1 : tunables 54 27 0 : slabdata 0 0 0 udp6_sock 2 6 640 6 1 : tunables 54 27 0 : slabdata 1 1 0 tcp6_sock 5 7 1152 7 2 : tunables 24 12 0 : slabdata 1 1 0 unix_sock 7 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0 ip_vs_conn 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 ip_conntrack 1192 2060 384 10 1 : tunables 54 27 0 : slabdata 206 206 0 ip_mrt_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 tcp_tw_bucket 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 tcp_bind_bucket 1 200 16 200 1 : tunables 120 60 0 : slabdata 1 1 0 tcp_open_request 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 inet_peer_cache 72 116 64 58 1 : tunables 120 60 0 : slabdata 2 2 0 secpath_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 xfrm_dst_cache 3 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0 ip_dst_cache 4644 4660 384 10 1 : tunables 54 27 0 : slabdata 466 466 0 arp_cache 7 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0 raw4_sock 0 0 512 7 1 : tunables 54 27 0 : slabdata 0 0 0 udp_sock 16 21 512 7 1 : tunables 54 27 0 : slabdata 3 3 0 tcp_sock 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0 flow_cache 401 870 128 30 1 : tunables 120 60 0 : slabdata 29 29 0 hpsb_packet 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 udf_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 romfs_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 smb_request 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 smb_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 isofs_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 fat_inode_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 minix_inode_cache 0 0 512 7 1 : tunables 54 27 0 : slabdata 0 0 0 ext2_inode_cache 0 0 512 7 1 : tunables 54 27 0 : slabdata 0 0 0 ext2_xattr 0 0 44 84 1 : tunables 120 60 0 : slabdata 0 0 0 journal_handle 8 123 28 123 1 : tunables 120 60 0 : slabdata 1 1 0 journal_head 82 462 48 77 1 : tunables 120 60 0 : slabdata 6 6 0 revoke_table 4 250 12 250 1 : tunables 120 60 0 : slabdata 1 1 0 revoke_record 0 0 16 200 1 : tunables 120 60 0 : slabdata 0 0 0 ext3_inode_cache 988 1638 512 7 1 : tunables 54 27 0 : slabdata 234 234 0 ext3_xattr 0 0 44 84 1 : tunables 120 60 0 : slabdata 0 0 0 dquot 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 eventpoll_pwq 0 0 36 99 1 : tunables 120 60 0 : slabdata 0 0 0 eventpoll_epi 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 kioctx 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 kiocb 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 dnotify_cache 0 0 20 166 1 : tunables 120 60 0 : slabdata 0 0 0 file_lock_cache 0 0 92 41 1 : tunables 120 60 0 : slabdata 0 0 0 fasync_cache 0 0 16 200 1 : tunables 120 60 0 : slabdata 0 0 0 shmem_inode_cache 3 7 512 7 1 : tunables 54 27 0 : slabdata 1 1 0 posix_timers_cache 0 0 80 48 1 : tunables 120 60 0 : slabdata 0 0 0 uid_cache 0 0 32 112 1 : tunables 120 60 0 : slabdata 0 0 0 bt_sock 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0 sgpool-128 32 32 2048 2 1 : tunables 24 12 0 : slabdata 16 16 0 sgpool-64 32 32 1024 4 1 : tunables 54 27 0 : slabdata 8 8 0 sgpool-32 32 32 512 8 1 : tunables 54 27 0 : slabdata 4 4 0 sgpool-16 32 45 256 15 1 : tunables 120 60 0 : slabdata 3 3 0 sgpool-8 32 60 128 30 1 : tunables 120 60 0 : slabdata 2 2 0 deadline_drq 0 0 48 77 1 : tunables 120 60 0 : slabdata 0 0 0 as_arq 13 61 60 61 1 : tunables 120 60 0 : slabdata 1 1 0 blkdev_requests 18 52 152 26 1 : tunables 120 60 0 : slabdata 2 2 0 biovec-BIO_MAX_PAGES 6 6 3072 2 2 : tunables 24 12 0 : slabdata 3 3 0 biovec-128 12 15 1536 5 2 : tunables 24 12 0 : slabdata 3 3 0 biovec-64 25 25 768 5 1 : tunables 54 27 0 : slabdata 5 5 0 biovec-16 55 60 256 15 1 : tunables 120 60 0 : slabdata 4 4 0 biovec-4 108 116 64 58 1 : tunables 120 60 0 : slabdata 2 2 0 biovec-1 115 200 16 200 1 : tunables 120 60 0 : slabdata 1 1 0 bio 276 348 64 58 1 : tunables 120 60 0 : slabdata 6 6 0 sock_inode_cache 39 40 384 10 1 : tunables 54 27 0 : slabdata 4 4 0 skbuff_head_cache 166 270 256 15 1 : tunables 120 60 0 : slabdata 18 18 0 sock 8 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0 proc_inode_cache 199 210 384 10 1 : tunables 54 27 0 : slabdata 21 21 0 sigqueue 8 26 144 26 1 : tunables 120 60 0 : slabdata 1 1 0 radix_tree_node 304 360 260 15 1 : tunables 54 27 0 : slabdata 24 24 0 bdev_cache 4 7 512 7 1 : tunables 54 27 0 : slabdata 1 1 0 mnt_cache 14 58 64 58 1 : tunables 120 60 0 : slabdata 1 1 0 inode_cache 1305 1310 384 10 1 : tunables 54 27 0 : slabdata 131 131 0 dentry_cache 1918 2145 256 15 1 : tunables 120 60 0 : slabdata 143 143 0 filp 141 165 256 15 1 : tunables 120 60 0 : slabdata 11 11 0 names_cache 1 2 4096 1 1 : tunables 24 12 0 : slabdata 1 2 0 idr_layer_cache 3 28 136 28 1 : tunables 120 60 0 : slabdata 1 1 0 buffer_head 5001 10087 48 77 1 : tunables 120 60 0 : slabdata 131 131 0 mm_struct 28 28 512 7 1 : tunables 54 27 0 : slabdata 4 4 0 vm_area_struct 271 406 64 58 1 : tunables 120 60 0 : slabdata 7 7 0 fs_cache 23 112 32 112 1 : tunables 120 60 0 : slabdata 1 1 0 files_cache 18 21 512 7 1 : tunables 54 27 0 : slabdata 3 3 0 signal_cache 39 58 64 58 1 : tunables 120 60 0 : slabdata 1 1 0 sighand_cache 28 30 1408 5 2 : tunables 24 12 0 : slabdata 6 6 0 task_struct 35 40 1440 5 2 : tunables 24 12 0 : slabdata 7 8 0 pte_chain 592 1020 128 30 1 : tunables 120 60 0 : slabdata 34 34 0 pgd 18 20 4096 1 1 : tunables 24 12 0 : slabdata 18 20 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 13 13 65536 1 16 : tunables 8 4 0 : slabdata 13 13 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 39 41 8192 1 2 : tunables 8 4 0 : slabdata 39 41 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 0 : slabdata 0 0 0 size-4096 18 18 4096 1 1 : tunables 24 12 0 : slabdata 18 18 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 0 : slabdata 0 0 0 size-2048 129 134 2048 2 1 : tunables 24 12 0 : slabdata 67 67 0 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 0 : slabdata 0 0 0 size-1024 44 48 1024 4 1 : tunables 54 27 0 : slabdata 12 12 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 0 : slabdata 0 0 0 size-512 8949 8960 512 8 1 : tunables 54 27 0 : slabdata 1120 1120 0 size-256(DMA) 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 size-256 232 240 256 15 1 : tunables 120 60 0 : slabdata 16 16 0 size-128(DMA) 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0 size-128 3036 3060 128 30 1 : tunables 120 60 0 : slabdata 102 102 0 size-64(DMA) 0 0 64 58 1 : tunables 120 60 0 : slabdata 0 0 0 size-64 1147 1160 64 58 1 : tunables 120 60 0 : slabdata 20 20 0 size-32(DMA) 0 0 32 112 1 : tunables 120 60 0 : slabdata 0 0 0 size-32 1320 1344 32 112 1 : tunables 120 60 0 : slabdata 12 12 0 kmem_cache 132 132 116 33 1 : tunables 120 60 0 : slabdata 4 4 0 --Boundary-00=_Gxp5AgcDKWYXuES-- From lists@wildgooses.com Sat Jul 3 06:32:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 06:32:27 -0700 (PDT) Received: from xunil.mail.wildgooses.com (xunil.mail.wildgooses.com [81.6.236.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63DWOgi020370 for ; Sat, 3 Jul 2004 06:32:25 -0700 Received: from localhost (Xunil [127.0.0.1]) by xunil.mail.wildgooses.com (Postfix) with ESMTP id 19B23170CD9; Sat, 3 Jul 2004 14:32:23 +0100 (BST) Received: from xunil.mail.wildgooses.com ([127.0.0.1]) by localhost (Xunil [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09236-03; Sat, 3 Jul 2004 14:32:22 +0100 (BST) Received: from [127.0.0.1] (unknown [192.168.105.1]) by xunil.mail.wildgooses.com (Postfix) with ESMTP id CDB68170CD8; Sat, 3 Jul 2004 14:32:22 +0100 (BST) Message-ID: <40E6B561.4050200@wildgooses.com> Date: Sat, 03 Jul 2004 14:32:17 +0100 From: Ed Wildgoose User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [LARTC] Re: [PATCH 2.6] update to network emulation QOS scheduler References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> In-Reply-To: <20040702134437.5891e998@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at wildgooses.com X-archive-position: 6552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lists@wildgooses.com Precedence: bulk X-list: netdev Content-Length: 667 Lines: 24 >Here is an enhancement to netem to do allow emulating lower speed >networks. The resolution is close, but obviously limited by the >granularity of timers and size of packets. > > Hi Stephen, This looks extremely useful. I have a need for a simulator for the Iridium Satellite phone network, this is at most 2,400 baud with perhaps 1 sec or more latency. Do you expect this scheduler to be able to do this slow? On a related note, for better accuracy I currently need a bit of stochastic variability on the latency, ie assume a 1 sec min delay, but also to vary that a little through time. Have you considered adding that as a feature? Thanks Ed W From jgarzik@pobox.com Sat Jul 3 07:22:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 07:22:20 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63EMIgi021479 for ; Sat, 3 Jul 2004 07:22:19 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bgdkk-0004DS-Ii; Sat, 03 Jul 2004 07:11:58 +0100 Message-ID: <40E64E22.50401@pobox.com> Date: Sat, 03 Jul 2004 02:11:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: netdev@oss.sgi.com Subject: Re: [PATCH] natsemi 2: support packets > 1518 bytes References: <40DC9105.60901@colorfullife.com> In-Reply-To: <40DC9105.60901@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From davem@redhat.com Sat Jul 3 10:18:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 10:18:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63HIXgi028886 for ; Sat, 3 Jul 2004 10:18:34 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i63HIQe1030262; Sat, 3 Jul 2004 13:18:26 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i63HIQ000607; Sat, 3 Jul 2004 13:18:26 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i63HHw3H017677; Sat, 3 Jul 2004 13:17:59 -0400 Date: Sat, 3 Jul 2004 10:16:46 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: kuznet@ms2.inr.ac.ru, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: bk16 changes to cbq Message-Id: <20040703101646.52ae1e01.davem@redhat.com> In-Reply-To: <1088861810.1039.298.camel@jzny.localdomain> References: <1088861810.1039.298.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 899 Lines: 23 On 03 Jul 2004 09:36:50 -0400 jamal wrote: > - if (q->wd_expires && !netif_queue_stopped(sch->dev)) { > + if (q->wd_expires) { > long delay = PSCHED_US2JIFFIE(q->wd_expires); > if (delay <= 0) > delay = 1; > > What i remember is this (4-5 years back) used to cure a bug - cant > remember the details unfortunately, but Alexey may remember. > I am hoping removal of the above line implies that those conditions dont > exist anymore? The test is racy with drivers, on the very next line the driver could take a TX completion interrupt and unplug the queue invalidating the test entirely. If the test proves wrong, that's OK because we'll try again at the top level of packet queue dispatch. There was a good explaination of Stephen's patch on netdev when he posted it. From mcr@sandelman.ottawa.on.ca Sat Jul 3 12:05:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 12:05:24 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63J4vgi031082 for ; Sat, 3 Jul 2004 12:05:10 -0700 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i63J3a305532 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Sat, 3 Jul 2004 15:04:42 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i63JA4N03306 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Sat, 3 Jul 2004 15:10:11 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i63J3Pmn009839 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 3 Jul 2004 15:03:26 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i63J3Onf009836; Sat, 3 Jul 2004 15:03:24 -0400 To: Herbert Xu cc: netdev@oss.sgi.com, dev@lists.openswan.org Subject: Re: [Openswan dev] Proposal for dealing with ICMP black holes for IPsec In-Reply-To: Message from Herbert Xu of "Sat, 03 Jul 2004 10:43:20 +1000." <20040703004320.GA28139@gondor.apana.org.au> References: <20040703004320.GA28139@gondor.apana.org.au> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 03 Jul 2004 15:03:24 -0400 Message-ID: <9835.1088881404@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 6558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 3948 Lines: 89 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Herbert" == Herbert Xu writes: Herbert> My idea is to use the information available in TCP MSS Herbert> clamping to help IPsec gateways. This can be done by Herbert> having the gateways establish a short-lived TCP connection Herbert> with each other for the purposes of determining the MTU. Herbert> Obviously this TCP connection will need to be Herbert> authenticated. If the connection cannot be established Herbert> (e.g., if an attacker is preventing the gateways from doing Herbert> so), then we can fall back to the existing MTU discovery Herbert> mechanisms. It sounds fine in theory. It can break for a number of reasons: 1) any kind of forced proxies for TCP. 2) Cisco-style load balancing that cause different routes to be taken. 3) causes some surprise for firewall administrators, as these new TCP connections show up. Also, therefore, may not work through many NAT devices -- often people do special things with port 500/4500 to get things plugged through. Still, I think it may be worth doing it as an experiment. When you say that the connection needs to be authenticated, are you thinking IPsec (ESP or AH), some kind of other thing? I.e. does this include the headers? I guess if you intend to use various kinds of MSS clamping as a clue, then the headers must not be authenticated, as the MSS clamping code must be able to do its thing. Herbert> The advantage of this over the approach taken by KLIPS (the Herbert> FreeSWAN kernel implementation for IPsec) is that we do not It would be good if you actually documented what this method is. Specifically KLIPS was set to have an MTU of 16k - minus a bit, so that SMB and NFS would appear to work. Not fast, nor well, but they do not encounter Need-Fragments. The resulting ESP packet is then fragmented. I.e. the DF bit on ESP packets is never set. RFC2401 says to fragment (if DF=0) before encryption, and provides various notions about whether to copy the DF bit. RFC2401bis says to fragment after encryption. Herbert> transmit fragments where possible which is the motivation Herbert> behind PMTU discovery. The advantage of this over the Herbert> current implementation is that this will work correctly in Herbert> environments where there are local ICMP black holes that Herbert> are known through TCP MSS clamping. Herbert> Comments? I think that there are simpler mechanisms. Implementation wise, a new vendor ID can indicate the desire to do this. The IKE daemons can do most of the work themselves. The two ends need a way to decide who initiates the connection. Probably the end that initiated the IKE. We need to decide if they do the work between phase 1 and phase 2, or if we can do this after phase 2. (or: Can the MTU of the tunnel be changed after it is created?) Do we do this periodically? Do we care about PMTU stuff, or just MSS? If we care about looking at the PMTU, then we have to write(2) at least enough data to send out a full size packet, that may get PMTU'ed. How do we get the MSS out of a tcp socket? (there must be a sockopt) What about assymetric MTUs? - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQOcC+oqHRg3pndX9AQGgOwP8CghDHSlzYi9VOIXiSRHwV1ILLX9OBVwg bio47djgh+cnOmcQz+hceMC1GKrv7iM59E2M7tFUy8MEvAjxbEiTBJCbdhCUF0M3 xANS/tMnE6/Vh5NZCHEUBT+Ea2xixMnkmcXHMl78hoYXDoC63RlaeVgM6Cbbn4/3 imtNerCtzBQ= =YvP5 -----END PGP SIGNATURE----- From jgarzik@pobox.com Sat Jul 3 12:23:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 12:23:10 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63JN4gi002400 for ; Sat, 3 Jul 2004 12:23:05 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bgdkf-0004DQ-GK; Sat, 03 Jul 2004 07:11:53 +0100 Message-ID: <40E64E1D.8020208@pobox.com> Date: Sat, 03 Jul 2004 02:11:41 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: netdev@oss.sgi.com Subject: Re: [PATCH] natsemi 1: switch to netdev_priv() References: <40DC8BC3.2000401@colorfullife.com> In-Reply-To: <40DC8BC3.2000401@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From herbert@gondor.apana.org.au Sat Jul 3 13:06:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 13:06:56 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i63K6lgi003531 for ; Sat, 3 Jul 2004 13:06:48 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BgqmV-000677-00; Sun, 04 Jul 2004 06:06:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BgqmR-0006O8-00; Sun, 04 Jul 2004 06:06:35 +1000 Date: Sun, 4 Jul 2004 06:06:35 +1000 To: Michael Richardson Cc: netdev@oss.sgi.com, dev@lists.openswan.org Subject: Re: [Openswan dev] Proposal for dealing with ICMP black holes for IPsec Message-ID: <20040703200635.GA24518@gondor.apana.org.au> References: <20040703004320.GA28139@gondor.apana.org.au> <9835.1088881404@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9835.1088881404@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2630 Lines: 66 On Sat, Jul 03, 2004 at 03:03:24PM -0400, Michael Richardson wrote: > > It can break for a number of reasons: > 1) any kind of forced proxies for TCP. > 2) Cisco-style load balancing that cause different routes to be taken. > 3) causes some surprise for firewall administrators, as these new > TCP connections show up. Also, therefore, may not work through > many NAT devices -- often people do special things with port > 500/4500 to get things plugged through. That's OK. We should ignore the MTU obtained via this method if it is larger than the present MTU. So even if it breaks it should not break an otherwise working IPsec path. > When you say that the connection needs to be authenticated, are you > thinking IPsec (ESP or AH), some kind of other thing? I.e. does this > include the headers? > > I guess if you intend to use various kinds of MSS clamping as a clue, > then the headers must not be authenticated, as the MSS clamping code > must be able to do its thing. Yes. In fact if the attacker can spoof the TCP connection, then the worst they can do is lower our path MTU. But they could do that anyway by sending an ICMP packet. So I no longer consider authentication useful on this connection. > I think that there are simpler mechanisms. Good. I'd certainly like to know of those that can estimate the MTU close enough to the target. All the ones I know either lower the MTU to some fixed level or levels, or send fragmented packets. > initiated the IKE. We need to decide if they do the work between phase 1 > and phase 2, or if we can do this after phase 2. IMHO it should be in phase 1, because this is a property between us and that peer. > (or: Can the MTU of the tunnel be changed after it is created?) > Do we do this periodically? Yes it should be done periodically when the SAs are not idle. > Do we care about PMTU stuff, or just MSS? We should also verify that the MSS is actually needed by sending a packet of the current MTU size and making sure that it does not arrive. > If we care about looking at the PMTU, then we have to write(2) at > least enough data to send out a full size packet, that may get PMTU'ed. > How do we get the MSS out of a tcp socket? (there must be a sockopt) On Linux it's a getsockopt. > What about assymetric MTUs? That's fine, each side will get an independent MSS reading. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sat Jul 3 18:21:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 18:22:03 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i641Lwgi012626 for ; Sat, 3 Jul 2004 18:21:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Bgvhe-0004qL-5B for netdev@oss.sgi.com; Sat, 03 Jul 2004 21:21:58 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bgvhb-0008Lz-RO; Sat, 03 Jul 2004 21:21:56 -0400 Subject: Re: bk16 changes to cbq From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Alexey , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <20040703101646.52ae1e01.davem@redhat.com> References: <1088861810.1039.298.camel@jzny.localdomain> <20040703101646.52ae1e01.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1088904111.1043.731.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jul 2004 21:21:51 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1428 Lines: 37 Ok, I looked at Stephens email; i found it here: http://marc.theaimsgroup.com/?l=linux-netdev&m=108751387802077&w=2 Basically similar to what you said. My suggestion is we back out this change - i think there may be a problem elsewhere, somehow we end up pointing here. It is also possible there was a hidden bug, but if this stuff was problematic we would have had complaints in the last few years related. The other thing is you can leave it in there and wait for people to complain. Lets say there was a race condition: The worst that could happen in such a case (on TX completion) is that the cbq watchdog is started (which later reschedules the device) and the top layer reschedules the device as well(because the device was stopped; stopped devices get descheduled). In such a case there will be two netif_schedules() with one being unnecessary. No biggie, just a few extra lines. Lets say there was no race condition: The cbq watchdog gets scheduled only when the netdevice is not stopped. This is optimization is now gone. To reiterate what i said earlier. The only thing the tx complete can do is open up the device for more packets to tx into the device... i.e !netif_queue_stopped(sch->dev) is true in that specific case. Actually while looking at this i noticed some odd things; it may be time to remind people of the return code rules on dev->hard_start_xmit(). I will make another posting. cheers, jamal From dgibson@ozlabs.org Sat Jul 3 19:17:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 19:18:06 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i642Htgi013867 for ; Sat, 3 Jul 2004 19:17:56 -0700 Received: by ozlabs.org (Postfix, from userid 1007) id 72FF52BD7F; Sun, 4 Jul 2004 12:17:49 +1000 (EST) Date: Sun, 4 Jul 2004 12:01:06 +1000 From: David Gibson To: Jeff Garzik Cc: Dan Williams , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Update in-kernel orinoco drivers to upstream current CVS Message-ID: <20040704020106.GB25992@zax> Mail-Followup-To: David Gibson , Jeff Garzik , Dan Williams , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <1088795498.18039.25.camel@dcbw.boston.redhat.com> <40E5B6AD.6060904@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E5B6AD.6060904@pobox.com> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 6563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1130 Lines: 32 On Fri, Jul 02, 2004 at 03:25:33PM -0400, Jeff Garzik wrote: > Dan Williams wrote: > >Hi, > > > >This patch is simply the fixed-up diff between the kernel's current > >0.13e version and the upstream 0.15rc1+ version from savannah CVS. > >0.15rc1 has been out for a couple months now and seems stable. > > > >The major benefits that this newer version brings are, of course, many > >bugfixes, but best of all wireless scanning support for the Orinoco line > >of cards. > > > >http://people.redhat.com/dcbw/linux-2.6.7-orinoco.patch.bz2 > > > >Dan Williams > >Red Hat, Inc. > > > I'm desperately hoping that someone will split this up into multiple > patches... Urg, yes. I've dropped the ball badly on this. I've done very, very little work on the driver for well over a year now and the changes have built up to a megapatch. I really does need to be broken up, but the chances of me finding the time and motivation to do so are not looking good. -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From hadi@cyberus.ca Sat Jul 3 20:13:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jul 2004 20:13:32 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i643DSgi015495 for ; Sat, 3 Jul 2004 20:13:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BgxRY-0007pp-3E for netdev@oss.sgi.com; Sat, 03 Jul 2004 23:13:28 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BgxRV-0000pk-Q4 for netdev@oss.sgi.com; Sat, 03 Jul 2004 23:13:26 -0400 Subject: reminder to netdriver authors From: jamal Reply-To: hadi@cyberus.ca To: netdev@oss.sgi.com Content-Type: text/plain Organization: jamalopolis Message-Id: <1088910801.1041.818.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jul 2004 23:13:21 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1508 Lines: 47 chasing that cbq issue i noticed things from return codes of dev->hard_start_xmit(). The rules are as follows (unfortunately the documentation is outdated; closest i could find was http://www.firstfloor.org/~andi/softnet/softnet.drivers.HOWTO). Jeff i thought you may have had something new. 0) no point of doing things like: if (netif_queue_stopped(dev) Your code will never be entered to begin with if you are stopped. You are wasting fast path cycles. Also no point in doing a netif_stop_queue(dev) as soon as you enter the driver. The driver will not be reentered (from say another CPU) until you return. 1) When you have no space in your DMA Do NOT stash the packet in your ring a) netif_stop_queue() b) return 1 A _lot_ of drivers dont follow this rule. A good driver to copy from if you are into cutnpaste is the e1000. If you stash the packet in your ring then return 1 you are in deep doodoo friend. 2) return a 0 only when you have succesfully put things on DMA. Returning 0 always is not a BadThing. Most drivers do this. It is a little less efficient at the top layer for each batch of packets sent to the driver and you end up stopping the netif at this point. 3) In case of error probably return a 1 and dont try anything funny with the skb. Dont put on your DMA or try to free it or muck with it in any way. You probably should whine if you have too many errors in sequence. Someone with more time than myself can audit the drivers - I have seen these issues. cheers, jamal From ken@xelerance.com Sun Jul 4 05:35:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 05:35:28 -0700 (PDT) Received: from tla.xelerance.com ([193.110.157.89]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64CZOgi013515 for ; Sun, 4 Jul 2004 05:35:24 -0700 Received: by tla.xelerance.com (Postfix, from userid 501) id 0DAE2138088; Sun, 4 Jul 2004 14:37:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tla.xelerance.com (Postfix) with ESMTP id 0461EC034; Sun, 4 Jul 2004 14:37:36 +0200 (CEST) Date: Sun, 4 Jul 2004 14:37:36 +0200 (CEST) From: Ken Bantoft To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, , , , Subject: Re: [Openswan dev] Proposal for dealing with ICMP black holes for IPsec In-Reply-To: <20040703004320.GA28139@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ken@xelerance.com Precedence: bulk X-list: netdev Content-Length: 2030 Lines: 47 On Sat, 3 Jul 2004, Herbert Xu wrote: > Hi: > > This is a proposal of a method of detecting the path MTU that can be > applied by IPsec keying managers (e.g., openswan/racoon). > > My idea is to use the information available in TCP MSS clamping to > help IPsec gateways. This can be done by having the gateways > establish a short-lived TCP connection with each other for the > purposes of determining the MTU. Obviously this TCP connection will > need to be authenticated. If the connection cannot be established > (e.g., if an attacker is preventing the gateways from doing so), then > we can fall back to the existing MTU discovery mechanisms. > > If however this connection succeeds, then we can deduce the path MTU > from its MSS settings. We can then apply that MTU to the path taken > by the IPsec SAs. This makes any ICMP black holes between the gateways > invisible to the end users as long as the information provided by > TCP MSS clamping is accurate. Interesting idea - tcp/500 connection (or maybe it should be port 4500, to deal with NAT boxes. I assume you want to do this as early as possible, eg: Phase 1, however until we have a PH2 we can't do a secure TCP, only authenticated. > The advantage of this over the approach taken by KLIPS (the FreeSWAN > kernel implementation for IPsec) is that we do not transmit fragments > where possible which is the motivation behind PMTU discovery. The > advantage of this over the current implementation is that this will > work correctly in environments where there are local ICMP black holes > that are known through TCP MSS clamping. > > Comments? I like it it in concept - I'd be interested to see how much of a hack is needed to implement it in reality. Should definatly use a VendorID to state whether or not each side supports it, so we don't open TCP connections and let them timeout/die/be hijacked. -- Ken Bantoft VP Business Development ken@xelerance.com Xelerance Corporation sip://toronto.xelerance.com http://www.xelerance.com From mcgrof@studorgs.rutgers.edu Sun Jul 4 08:13:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 08:13:15 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64FDBgi017293 for ; Sun, 4 Jul 2004 08:13:11 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 7CBE3F9D4D; Sun, 4 Jul 2004 11:13:10 -0400 (EDT) Date: Sun, 4 Jul 2004 11:13:10 -0400 To: Netdev Cc: prism54-devel@prism54.org Subject: Re: [Prism54-devel] 2.6.7 patches Message-ID: <20040704151310.GE14482@ruslug.rutgers.edu> Mail-Followup-To: Netdev , prism54-devel@prism54.org References: <5.1.0.14.2.20040702124232.00b0d1c0@pop.t-online.de> <20040704150616.GD14482@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040704150616.GD14482@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 6574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1373 Lines: 35 Oh and PS, all this should be discussed on netdev, CC prism54-devel. I forgot to include netdev in the thread in my reply. Luis On Sun, Jul 04, 2004 at 11:06:16AM -0400, Luis R. Rodriguez wrote: > On Fri, Jul 02, 2004 at 01:12:46PM +0200, Margit Schubert-While wrote: > > Aurelien scribeth: > > > I've checked the changes in CVS and I disagree with the patch #5 > > (removing the writes to some pci registers). > > > Those changes will have huge consequences on card/driver stability. It > > should have been debated here before. > > > Moreover windows drivers do those writes, and adding them solved a lot > > of stability issues in prism54. > > > > 1) Well, many months ago, it was talked about > > I do not remember these register writes being disabled being discussed > here. This needs further investigation. I believe more people are going > to be affected by removing it than adding it, not sure though. We should > figure out exactly what is meant by "legacy" devices and see if we can > detect this on the code itself. > > Luis > > -- > GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E > _______________________________________________ > Prism54-devel mailing list > Prism54-devel@prism54.org > http://prism54.org/mailman/listinfo/prism54-devel -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From SRS0+b80124eefd9a30778c08+315+infradead.org+hch@pentafluge-162352.srs.infradead.org Sun Jul 4 08:23:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 08:23:57 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64FNrgi021325 for ; Sun, 4 Jul 2004 08:23:54 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1Bh8qO-0001Mw-OD; Sun, 04 Jul 2004 16:23:52 +0100 Date: Sun, 4 Jul 2004 16:23:52 +0100 From: Christoph Hellwig To: Bernd Schubert , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.7: sk98lin unload oops Message-ID: <20040704152352.GA5243@infradead.org> Mail-Followup-To: Christoph Hellwig , Bernd Schubert , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <200407041342.18821.bernd-schubert@web.de> <20040704151509.GA5100@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040704151509.GA5100@infradead.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 1264 Lines: 33 On Sun, Jul 04, 2004 at 04:15:09PM +0100, Christoph Hellwig wrote: > > Fortunality everything still works fine (I'm running the script over the > > network of the syskonnect cards). > > > > This machine has two of those syskonnect cards, on another machine which has > > only one syskonnect card this oops doesn't occur. > > As a colleteral damage the following huge patch should fix it, and I need > testers for it anyway ;-) Actually the problem sits deeper. sk98line tries to register a procfile with the interfacename of the struct net_device. The patch below (ontop of the previous one) makes it work unless you change the interface name manually, but as Linux explicitly allows that the interface is fundamentally broken and probably should just go away. --- drivers/net/sk98lin/skge.c~ 2004-07-04 19:15:43.219326648 +0200 +++ drivers/net/sk98lin/skge.c 2004-07-04 19:18:21.562254864 +0200 @@ -5119,9 +5119,12 @@ if ((pAC->GIni.GIMacsFound == 2) && pAC->RlmtNets == 2) have_second_mac = 1; + remove_proc_entry(dev->name, pSkRootDir); unregister_netdev(dev); - if (have_second_mac) + if (have_second_mac) { + remove_proc_entry(pAC->dev[1]->name, pSkRootDir); unregister_netdev(pAC->dev[1]); + } SkGeYellowLED(pAC, pAC->IoBase, 0); From rmk+netdev=oss.sgi.com@arm.linux.org.uk Sun Jul 4 09:04:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 09:04:23 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64G4Hgi022247 for ; Sun, 4 Jul 2004 09:04:18 -0700 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.33) id 1Bh9TK-0000MH-N2; Sun, 04 Jul 2004 17:04:07 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.33) id 1Bh9SG-0004Jt-0u; Sun, 04 Jul 2004 17:03:00 +0100 Date: Sun, 4 Jul 2004 17:02:59 +0100 From: Russell King To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.6: IPv6 initialisation bug Message-ID: <20040704170259.A16596@flint.arm.linux.org.uk> Mail-Followup-To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040628010200.A15067@flint.arm.linux.org.uk> <20040629.020627.76560474.yoshfuji@linux-ipv6.org> <20040628184758.C9214@flint.arm.linux.org.uk> <20040629.095903.58985982.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040629.095903.58985982.yoshfuji@linux-ipv6.org>; from yoshfuji@linux-ipv6.org on Tue, Jun 29, 2004 at 09:59:03AM +0900 X-archive-position: 6577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk+lkml@arm.linux.org.uk Precedence: bulk X-list: netdev Content-Length: 2304 Lines: 57 On Tue, Jun 29, 2004 at 09:59:03AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > In article <20040628184758.C9214@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 18:47:58 +0100), Russell King says: > > On Tue, Jun 29, 2004 at 02:06:27AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > > > In article <20040628010200.A15067@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 01:02:01 +0100), Russell King says: > > > > > > > Ok, I've just tried 2.6.7 out on my root-NFS'd firewall with IPv6 built > > > > in, and it doesn't work because of the problem I described below. > > > : > > > > What's the solution? > > > > > > Bring lo up before bring others up. > > > What does prevent you from doing this? > > > (Do we need some bits to do this automatically?) > > > > When you use root-NFS, the kernel itself brings up the interfaces, > > and IPv6 immediately comes in and tries to configure itself to them, > > trying to create the routes. > > > > Unfortunately, the kernel doesn't bring up lo first because it > > doesn't know to do that. > > Okay, would you try the following patch, please? This does appear to fix the problem. > D: Bring loopback device up first > > Signed-Off-By: Hideaki YOSHIFUJI > > ===== net/ipv4/ipconfig.c 1.38 vs edited ===== > --- 1.38/net/ipv4/ipconfig.c 2004-06-23 09:06:18 +09:00 > +++ edited/net/ipv4/ipconfig.c 2004-06-29 09:53:36 +09:00 > @@ -183,7 +183,14 @@ > > last = &ic_first_dev; > rtnl_shlock(); > + > + /* bring loopback device up first */ > + if (dev_change_flags(&loopback_dev, loopback_dev.flags | IFF_UP) < 0) > + printk(KERN_ERR "IP-Config: Failed to open %s\n", loopback_dev.name); > + > for (dev = dev_base; dev; dev = dev->next) { > + if (dev == &loopback_dev) > + continue; > if (user_dev_name[0] ? !strcmp(dev->name, user_dev_name) : > (!(dev->flags & IFF_LOOPBACK) && > (dev->flags & (IFF_POINTOPOINT|IFF_BROADCAST)) && > > -- > Hideaki YOSHIFUJI @ USAGI Project > GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core From jgarzik@pobox.com Sun Jul 4 09:19:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 09:19:15 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64GJBgi022922 for ; Sun, 4 Jul 2004 09:19:12 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bh8ZK-00086h-RW; Sun, 04 Jul 2004 16:06:15 +0100 Message-ID: <40E81CB1.5070403@pobox.com> Date: Sun, 04 Jul 2004 11:05:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: netdev@oss.sgi.com Subject: Re: reminder to netdriver authors References: <1088910801.1041.818.camel@jzny.localdomain> In-Reply-To: <1088910801.1041.818.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1396 Lines: 41 jamal wrote: > 1) When you have no space in your DMA > > Do NOT stash the packet in your ring > a) netif_stop_queue() > b) return 1 > > A _lot_ of drivers dont follow this rule. A good driver to copy > from if you are into cutnpaste is the e1000. > If you stash the packet in your ring then return 1 you are in deep > doodoo friend. > > 2) return a 0 only when you have succesfully put things on DMA. > Returning 0 always is not a BadThing. Most drivers do this. > It is a little less efficient at the top layer for each batch of packets > sent to the driver and you end up stopping the netif at this point. > > 3) In case of error probably return a 1 and dont try anything funny > with the skb. Dont put on your DMA or try to free it or muck with it in > any way. You probably should whine if you have too many errors in > sequence. > > Someone with more time than myself can audit the drivers - I have seen > these issues. FWIW some of this is related to my own lack of knowledge, long long ago, and mistakes made long ago get cut-n-pasted into the present. I will edit this email, and add it to Documentation/networking/netdevices.txt. Please (to all) consider netdevices.txt as a general text describing how to (or how not to) write net drivers. Any patches -- or even random comments you would like me to turn into patches -- are accepted. Share the knowledge! Jeff From pavel@ucw.cz Sun Jul 4 11:30:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 11:30:42 -0700 (PDT) Received: from amd.ucw.cz (gprs214-240.eurotel.cz [160.218.214.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64ITBgi026180 for ; Sun, 4 Jul 2004 11:30:12 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id C871E2C6CF; Sun, 4 Jul 2004 20:27:55 +0200 (CEST) Date: Sun, 4 Jul 2004 20:27:55 +0200 From: Pavel Machek To: Manfred Spraul Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Gigabit Ethernet support for forcedeth Message-ID: <20040704182755.GA7540@elf.ucw.cz> References: <40E25328.8020102@colorfullife.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E25328.8020102@colorfullife.com> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 6579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 1397 Lines: 36 Hi! > Attached is an update for the patch that adds support for the gigabit > ethernet nic in the nForce 250 Gb chipset. > > There were two changes from the previous patch: > - clear the PHY_HALF flag if the nic is in half duplex. > - remove the setflags / setlen helper functions: the ring entries are > visible to the hardware, I don't like the read/modify/write cycles. > > It passes my own tests with 100 MBit half duplex, 100 MB full duplex and > 1 GBit full duplex. ... > --- 2.6/drivers/net/forcedeth.c 2004-06-30 07:27:50.330753976 +0200 > +++ build-2.6/drivers/net/forcedeth.c 2004-06-30 07:27:25.579516736 +0200 > @@ -10,8 +10,11 @@ > * trademarks of NVIDIA Corporation in the United States and other > * countries. > * > - * Copyright (C) 2003 Manfred Spraul > + * Copyright (C) 2003,4 Manfred Spraul > * Copyright (C) 2004 Andrew de Quincey (wol support) > + * Copyright (C) 2004 Carl-Daniel Hailfinger (invalid MAC handling, insane > + * IRQ rate fixes, bigendian fixes, cleanups, verification) > + * Copyright (c) 2004 NVIDIA Corporation NVidia has copyright on driver created by reverse engeneering their hardware? Funny ;-). If NVIDIA really cooperates, perhaps its time to make the name more friendly to them? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! From jgarzik@pobox.com Sun Jul 4 11:36:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 11:36:17 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64Ia8gi026668 for ; Sun, 4 Jul 2004 11:36:08 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BhAzG-0001Dr-8c; Sun, 04 Jul 2004 18:41:10 +0100 Message-ID: <40E8412A.4030309@pobox.com> Date: Sun, 04 Jul 2004 13:40:58 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: Resend: [NETDRV] Fix successive calls to spin_lock_irqsave in sk98lin References: <20040701110418.GA10797@gondor.apana.org.au> <20040703020852.GA29105@gondor.apana.org.au> In-Reply-To: <20040703020852.GA29105@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From SRS0+bb8afb756f99ce273ebf+315+infradead.org+hch@pentafluge-194404.srs.infradead.org Sun Jul 4 11:44:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 11:44:14 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64Ii6gi027150 for ; Sun, 4 Jul 2004 11:44:07 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1BhBy8-0001ud-59; Sun, 04 Jul 2004 19:44:04 +0100 Date: Sun, 4 Jul 2004 19:44:04 +0100 From: Christoph Hellwig To: Bernd Schubert Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.7: sk98lin unload oops Message-ID: <20040704184404.GA7262@infradead.org> Mail-Followup-To: Christoph Hellwig , Bernd Schubert , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <200407041342.18821.bernd-schubert@web.de> <20040704151509.GA5100@infradead.org> <200407042028.59047.bernd-schubert@web.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <200407042028.59047.bernd-schubert@web.de> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 76366 Lines: 1072 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Is your patch for vanilla 2.6.7? Sorry, it's for Linus' current BK tree. I've attached three files that you should be able to just copy over your regular 2.6.7 tree: include/linux/pci_ids.h drivers/net/sk98lin/skge.c drivers/net/sk98lin/h/skdrv2nd.h (all gzipped) --tThc/1wpZn/ma/RB Content-Type: application/x-gzip Content-Disposition: attachment; filename="pci_ids.h.gz" Content-Transfer-Encoding: base64 H4sICIJP6EAAA3BjaV9pZHMuaACcnV9z2ziSwJ89n0K3V3W1O7WZ8D+pe6NISuKYFBmSkuW8 sGRJnkltKp6yszOz3/6A7gZFyWyQc6lKuWL91AAajUYDaCAff/xh9uNdGaWz6Ovh7e2fs935 2+nldXb4dprF59+/HM+zNH4TDGBfz4e38+xf5/Nvs7eX1+/n00/i1x9/+OHjjwo+SinnN/j+ 27+f1D8l9N+n8/OXb+eZKKyNsrCu203RtHGyTDdJfHdn/GmIP3qq3a1CBM1reYuwTgivm6IK VwkINAfE0edtHdUpQoOlKiyNSZRW2DIryvIROUsnrVRl2hqqCtOYMEeDFc06qZALDFYfm6R5 KKp74IaqRp+3iZQm/gHccEcQ2RT3yaat0s0K2SHFKHYZx9hiS1t42OREDelFUZcGW5oGx2ld ZuEjcEPS6HOwJWAGG6uofUcNNVNRdkzQUCMVdKm+ral+vs2aNE/iFCx9qP8vRLsT5lkAN9iI Hhlu45TIoYb0yHJdbBIkh1rTI7FBktS1J8mLCnvDHRIHHwuTRwNwh9uB0FL8Y03YYCMQu+jZ 1dRrUaUxuQlvQBZ+3K6LukFmsGJEpXVI0FC1CEou1JBeicojYoZMlxjxC4KGzKOD8ihVBQ5p nrjNdrGtCdMoIgqrWILA+TxXhVHyED4iF/DcpZM8TSdFRZ5vN2kUNmmxkfBQyVdQWydVGmbA DnbZNV2GVZhlSTYDfqj3rnmwfiwCvzLUlTdfKeIkx/oM9ek13A0pX6OV+rFuEhwvQxrGj9sy RVMKhuc3hOI8JGhwekNIjveKsMHZDbGqUQUOTm5UK/GLddGU2XaF7OAMh+zFRgKNNtJNucUx Oh8QBZ+298njohAWDNSgPpArkw1KGlQHMnmxrROihrSBVB2Fmw3Vfj6oEORWYZ6URdUgN6QM 5C66mOvmviK6l/Oy5A5DUxF+3q4SUTdhHxIbnv4IvBR70BRbVkWU1HUBlvs0IK4DWjvwQNzT YLEXzum4oZ64cKLHmnSbIzrUHRc0zMo1TKpPpr7ssnhIqhK082Tp0TwtwSc+2XouKrA1jmZU o+OS2HFoTMDH7TKtkgfxF7DhkY1gGMmiUdzw4EauplnpODy0EdrWC4IGh7aq2oJs5Tg8qqnA XE04RzEv8aO6SbIsFYYKQ+M8ODA6pE0tCG7Ohka/IeANqO55qH4KaJsd1O95WL8d1sVUz8MK 7sBdkUZY7LD+OjAOmxA5h58Tq8cS/N2gFcOn/aDfHF5VISdUl1RNmG5y1LNpDM+BAHe+wDR0 k1O62oheJtMXPkTMk+ageso2LlMYFyazBit7Zb5b4yADAJjT8zMsRHEBiyvQEyxK336azWqx XBUL1//87+x3XOA+f3l9+/5PImbfzn9+/+ndKnWXbGIxdtO4jR9Fm9INrqI8/zqcipOd6N4+ JgJCzynXstoyQmCEitFyX4hpHCY432RkItWGZoONPIyAjfA1mygpFW6NyHUU6OjBOhIGmrWf tmFcFfiNgGuZiGnK8BM07Gxy9UUIV5NqMeneBDTvaFOs/ARoG7Y9IrZKl1myF6xzOwDesSJs l0LljxGhYbR+hED0YDwf9Wydh1VjlZI9j8kVwzXJxBgA2OZ67BpGluu0ay3IXYwZ8CNaE7Il b6conbPzm2rHQDsTG1micGe8KoBLWgQBI1YUpXUNoDdSCwkuJGn6I6YmSRkDON6IjtfbTQxB +7Npj+sA9LsA2jW4AbSJqkHffSGyOm2zYoUx/jvuUrCQ1Lp2FIDBGLfu/T1nEccZYce5yHG9 2JVLHGeosh1Yv7BEkjM6JdGjGnLdQhJNVzX5MCJw7iH3NMZRU7iBr7iAuNMI5xP3rOe6hrBe ROlw7uLuqMl1ngJ9BXK9p3QoymxtG1hrpHRgPVSlxVlZx9rYJHa8SFBSRKOmWM94EYsg64ou qv8ZwIDTvZS4jObGHGd8bYMEZylOV0Pg2izcIKrTvUBNJVI3coC7iOSGTlf6Hjnd0AGRxHEe UqrxUYSsxcMyxW0Z1q9IkZ4pusYaWlffcMpfgD9jHF/YpOTyLBnu5Yfjr54jQ7dhuQJvvSAQ c6t05abLNUlylulGjWXJmjq2y+kdSSMIgmiP5IjMRMl0hcxLlT/OqsMvZ33NxbdXsPJyfIcz LcXFxOnr7a5S4uYjXImcy40lxX0ijutZ4vYZcWPtaIgba0ezQI4zeuLadIccZ/Qd94CcP8Z9 Ri4ctY/VHskR+2gzaMlxrIfbLEZuRDNttkJurCVZityIJbRZjlw8xm2QS8a4CrgxSxA+ATnO UwLnOW3WINcfXbtmZGR5zg4szfX0lia4LXFaSxPcjjhP1kMObrFama0yfUXkUZ7gWtjScS1H V0jHLpHVmXTHrpD1+5XaVRMrdY9f5kKjKzZDlguP+mwNjbUnNbZeIjulsfUKWZ3ld+waWd3o 7Nh7ZKfooc6QnaSHHFkuVLxiN8ie+x25/fr99TCtLxvQozNJj02G7JQ2NBWw2tHcsTWyuhHd sQ2yutHZsVtk3b5ucnuaYrIE3dYUY8yWyF4N8Xwk/lBfzpcz8Ud8/zSpE/Ksw4/94srXl8le pZSBvms4usm5YxfITulI2B0X7JSOLGNkp3RkmSA7pS/KJbLerXKmerdyhQKmeAvYzRPsFG8B OxyC1c2rHfszsrpoomPvkV1MYTNkoylsjqxufu/YDbK6Ob5jC2SXU9gSWG202bGfkJ1k1BWy k7zTX/BkcOwj5E4aAA2ykwbAFtlJA2CH7BRnUj4gO8nW98gGf83JxUmxIWd6GhnAiC7vyBdC Mafzy7dZJdZ1k8r5BE7FHHEqiCaITqjSpyWieo0iukLU79d+J6v/913yj2lteAQRrt5PIPoZ 0UO/NEsWFriGMbG4DGusn9QR3SB6noAWiHI7KX30K6DehAosYElkOda79s7Nye3NsWanqx4C If50pT2g4vXjBtE9okGvvM3uw1SL3piTrWFjDVjDznKleoypLUtPUsVzb8IISs+IThhB6TOi E0ZQ+gui1yPICmQrrKmteGylKubstn8fPSCqnzYQPSHq9Ktmg/lNtpwQVuvSQ72T4U+VsQEZ 5yleDnL2BDqhjzZLRCf0ERzLCXSC+YcJtndCBcIlolee3wbzDSarZo010wdkiKaIzq8MDcvz JndniRuIEwwtrBDtO6/cmzZ9PuJWxgQnkH1GtO8Ecn9aKQ/41Qm9mu0R7Tu1fD6tFHAwxykO JjsjOiVqeEZ0gvFmvyDadzBTKl6Fk2OLajE5tqiiybFFFb+LLdJVOVL32sRN7uPhSWujtdVx 2kBXcq1s3vFpDHSVQG00XAvn1+IptxuwJz89FE6eBKp12IjCwZNA9RWVqKUqYEvlit/P0n05 i3798tvb+btexQJs5X0AuekvnMkVeTmg2GW1OqHgDEgibWBF7hxORfgzzwuIh3DsoecFdBDk hvYF9BHkPE0HOuad9tjzAlIduc2sDrSh1bc3KoZA527gSsUQ6N4NXJd4D4ohhaBW4buwFvOC Ce3W5O+EcUb9zI7+OGst2zAlJn+yx/01CWKPoOs28MWMQtdk2MN5ibme0WaYl2YYXADfkVvI htCcGUvSDlTR7CkwYpZBmEZaHf0JngXz7wdy/ofoOk/vBvL+h1AcoQIdr0OXwOfyeQwd3N21 cFkzu8B7ypV3+XQGycrEt74m2CN+MgBQ7+nd9aeLJTV1gum/Jj9ggWkfbKts5UC0b6/mDJJP SHKt6ZFHJDlP1SNPSHKuCsmkESGagSSbcPaQpE2i0h05m0eoLecob84nw3QkzlbyB5sZmFAG DpuhJAjRxeqGm45qtllajgxx4OhOEj/BdNLaZVg3ekdPEi0SyW0CSqy7zWUY3J7epeQywyFg mLpaWqbpUNGmroaW8NnEsckYJM8dc0KKU/JG6ufaxLFpn8Q5xHGmj5wVuGgxbLRLyWKOtYc8 DLnDzVhflFbVliYPNpkHodZ3nQDE2WziG4JiIsfsnAObzdaBTovxBps92kex+MN48ZhFdGAz LBXoIPg0KjHABj2NSvQwIDuNttzDdp9G2+1hStKJzSJE0POt+d1AJvR7MIDwyTT5pNKuvwG8 vcw5BNoIspmnHWgi6HAGmS5yskZOMYKASwzCyiu8p8Vn6Em2qcg7cJ0socBaWR7l05lc/CnB PApHAhkUZ7vmiBORXPnYrPFemmHpSq2TapfArV5AuQkKm9s+hPcJDlQdmKv7XQa7opSY7QdG GteYW+nrKhmtt/ewcyGmCp3EqIx805AXuWgMsJnQ17SK+juvd/eedgzKOzJM9lQDFLpJy6S7 +jxB8ekc00bNJ50KVkleN/L2q0AXJrvFoNQP4dPzs7x4wLhn4ciTvUUj4jD7+HH22/HLT19O b7O3w3/eZn8Lm/9pZqu0nv19E1X/+JtmPhBi5Np5t1ILRi4Siqk0rlMe4tY3xeIPIiq2owU1 N8C+jpZzYFdAOa10TfagIE/bPFmFsg/AyWh2ansohGesg+uTFqAeny6Yk0LYgSwImUEZQa9b fCZ1x7XrIk+QZXcmBKseGLB4XwNYUiWbENYstnfUkcukXYVN0vqGIec9n98NuKF9pNndvms6 Qpo9OL6mY6TZo+NrOkGaPTy+ppdIs8fHuRwaiypsfQfidP/2FjzDmsjqOq9jbWTZja0+6yDL bhsKdif8ViXZAFl297rPzpFl94T77AJZNkWgz0bI6npasSbqVzMkeyzql10QXbGoXzZ2vWJR v2xkIdmilHGK42B1ZR743ahcAWsETSgM2ytzbCYUZmoK02lMMagwmXgzoTBbU5hO5YpxsTB2 f6uHokHL45jZ4PR+Va9AUy/dkFAMjgiZYDNBCXNNYboxFYgYm3LrfbEwGCNx30mQozLVtpNg 2cQ/YF2zRUPmU0eAs4VMEY/MMF9M4Ox02FSimhu6PspeQSCqdeKHcJe08V4/M97gm71+clT4 3IbLRvLHKBkEQAaccVxI2NeWP8bJEEku9aojXaynO15PF65FyR9jpIMynXGZ6MzmvCvqSA9i XPljjPRdIPnk/o4MkAwmkAGSbECuyABn64CfrS+kheSolmQWjCRdzcURilXZvglFVGk6Nu7O iJ/8ll8GmZmXPyCW3ZzMw6Yq9lQ4NzEj1OarEFYVhsuudxWZZshx7kZxj7gRbXJmfpGnSuZO IfpkG65KpLnEn16L0hzYExs+ELuS2+F5fqe90dhnsRLvbq2/h+WevPgEaswaUx9WzbtsNt4N w2jMBj/kFejCSLJci/NMBO7g5SfHtfldP+W/2e2spvVglxsWi+yiQmKu69DRzondRUMsIExX qOuqzdezvlC1V3pm988Qo7qd2cGYpxU+IWCwx8QSaW3PAP27t2803XBxZBq0c+2fn7llLaG2 Qk+B5nBPnRCwl68F0UYLEZDQSas5+/ijRD5ET/9+my1ev5x098Tkt7MioqdDDMOS385ejoev k76qnl4zDHsGB+L5TMQ8s+jl2/fXl69fz6/6r1dOZ2eGIwXALyaVrJ54MQxXflH8c5Z9+Zcg z69ffvv1/CobMLH98rGTTKnPk9JWr4fffv1ynIXH41k04vD9ZaQh2716lkSslKWE7f7DXyue zvKD/1fxqyos11T8vOv/l9czSJpUix1ZgOmp7++ySV+sG/kKVrkOsQXWUX5f/nKGv9V/GyyX vnn6y5arXpYxbFd9V/xqtn550yRjdMVixoHNHpsLroz2ltonhRJe/ji/6m4IyC9t0iwhD+Wy 18elyqvIdXyvCwNE3+nqgrgv7GXuI37gtnCw6vPAMqNaOASQHghfjkr6ID/4AJ9o24ESNtXC 8JSEU0/CpvogP+HfPVnS5pnNVXMZC88a+coDsMGXSomxuWhF3uB256aad/kZXd4Ttgx1Wsmt yqQ4g87t2E0WAYVRqU40NTXLymjkEAKr76sHSvkzF6w+Tmv8cTpUH08gHHaXT0DOHF2ow27k CsgmB3370OU1ZLrofmw2SEOKIE3NxYclTsqGzUZFcGMf6+WyuWAScghilz+geoLYVQpKou5x tZoQQjpO10yPOogPKLCv6Rq/ziBIEZ5OEZ5tE8SFEQC5BOkqTir1dCr1KCz02M0fgDyCNObn UeTosTs7EqIe9HQ96NGhnMfe/AHIIkjjGzwKLPk7vRLyqDg2Y1xAPvWdr+s7n/rO1/edsjtP a59+x/kjnEuFatroky34OlvwHZMgnSLIYHydwfhkML7OYHwyGF9nMD4ZDL+FARBVXGcwPhkM /zIBQNQ6ncH4HtWJ3YAR0Jy88e0zlNcQmR5/WQEgiyBNxeeeTZDG9FzTgANB+VPrr6HqY+7T hLrLn1rKJkpXL9cMiNJOvD6VyD6iBlRAVKCnLKJ0oYWIVJCaa2Xh7Cx/6sMGonS6d+ekiblO Ex710O1rxbeOBii9mxGfekTpnLttEcVmPcmBYeBc6WvDOt8wLaTYZFSkPKLYDZJ1SdEmt1ex LttdWm/DLP2ctMnqTpvFewUv9x7SXHNvaAdprtNuaAtpbskh6MsTdLDlqOXosUsBcrGtAH+2 3MANSV+cPShuMbLVAtzct0keO6kQZyiO62/BxelOUZrmSqptijoKTWQ1Lb6wqG727rVi8zCp G3j00OQvXwtY/iJbhMCxJzaCq5KirYl71qhIcmkRIadRed+CsMMDbhWqmrQOs2WMaQymxZ4D Kfo+ecS8GKA1lg80PJ+7gFQiQXNOTdCf96bSg6UzUcmRHixLMzbEL/aqAyw2y0qA9V7uL3cy fY2bgBYlu6RKII/WtNh5QcHhdg/gnF0Ml1GTROsR00eorT6bmK6s2RHvo2j+rJsltA7zbRWm Lb6lOSZY0SbQ7PrwhsY3J22Z/cLoIay3dZe2zZ9HI9UalOAnn19lBMbqYVz26hYRB4ffqihK 9cIYG8lKpJ1bkenLY8kj/5QkgPKCiitPJY8ue+PuAgYIjkn0LNkbR/5lOgX6YD3H28fwh0AT wTGJASRiHAM2EaMD4dmzY8CmXnWgB0UHbLR7kShN4OR67GFbktVj04VE2jyNqgKe9NUOLWA/ yYtj3VDhdrhWlIftcB5KEPL2mdorY+M4gZm+53TbUkyBi21ND4BeDiHZ2UnB9N93hGJEVe0m knuQJjtLD32pK2n0S/C/dZRFummoeoF8HpVpTDfk2EsradvsSgdf6rVPbJKV4izi2DSAtHUc XEMG/N0NQZkmrvAPRzYqbeCtSpMoNqkCZCmKTRAQFN2nFBR7iUZSlqI0bRSUKpGbYIEylSzO eCXldPXiwgss0SVK05eijWZIGJcDgxVT1eemcxK2IIw7jYb+Vq1k9zHQKqhIdmoGXShZfGKE pFQfsRsQqFelC3YLQmJeJ0xj/KbbUToTc7vqs4uoutg80qDkekgibbSPbXzgMpDb+9ysGqp5 nutIQbRFk5oGXdH04Tn3hy/fnl6+nWa/Hn4/z77/8aLeb0/jt/+a1eczOKPDaXZ4m/1x/vr1 9jiklxidbhbFJqZkbLbXFNYG82gOmTfGnPV1NzA8HnNgD4w62vPg3q/8wYZGm3SV00TGv3ME UJtHwoJcn67AGj/MZtzcuAzpWWnWNiTS1lk0NxLPg4Bvzj9qfQ1jlhK79XUNWwhz5n4N2wjb bA5A0RRiMlfq8kewtijg9SbTZWeHDs3LSEi8055IXcP0mDTXsmuY7mBz47mDq1A0Q7DO7f/T M8AuwywqCB6txTp8uEeUm7Y6NCr3gWV6SHMTU09wVaXwKrqgn9iVUFXkKf5vOiZ/0kqUCJ4s vE11Yk2yj0rlOpNQuEcmUE4HfakWolz01kfhdDqehAYg1ZuE/l9v59Ycu63c+2flU+gxJ5XK JsHr5OUUh0ONaA2HNMmRR35BaUlatV3lbKds7x3n2wdAN3iZpT9An1SdB3uWl39sgrij0Rdd qanYxO5ILFr6F2gWbJaahYRukZrQARtNN0vURHDYhhqHBj9qFNasrwYd8LzjvgeDte9krQ79 mhIRvCNmSgri4C235UZhRsYuekcFuzRsNQQnVEWof/I0ix5o5kczA4P5LjR30znUWVswT/da pJKMRuRMapHqxwuGDwaEuvdZIoNohiFwF4SZBvWvV6KeDD98EnX9ELiDplzXO24T9BVXWRyv rKD+NkvpYil60blJSBa039SMPBTlLg2kxyhizR48S9AKJocybJm5hE+UNgAbUK5gKjPcaa1g o7TbF3g32tVly1p96JdnGNmNeVom4uqusYkNFBubzasj0kfXnXiRSmEIYM2o7zgf6tH9aiKP pceEhbDHl0PPOW+hj50BL+danuXDD3dOOxVin05z3A/orbCQao1ysCPbAlZb0pJodwU8VS+n oj9SoBLsnXcjmQuCdkxr0TxssMX3ojYsC33q1vVhcehUt8Y5DQr0El63IVnT4RBJN3XC+LdV WJXfFIXyi2Fb1Jtys2h3dded/uNYULQMhz3eTevURLv79ZNYisZaYgtP3Q/HuTToWB/bs3FJ 1SYuYOC/FE3xyOeKDL2aIJmJ2L2bn7kHAlFnsGDsSWAzc/TFMOLLBMbuyd5yCXNwQjxX1yOl ylT1gr6XIKPVNqrl+CODatvvF7mMMjSmCJL10IWk3wvxjLRi6Z4PzjEzK6ifCRyFYcFSJDH9 Aw31X/qal3mcbUoz2tKBGxvazRtO/x0pYt1rjJXqS+dkuUit19WxKF+sEsGLc0QmvO1csByS CQfyWrBTTKbbHOmf0lNQphDHpDhVxWG6ZoIhEJiSuT3uw1bVeSf77rEY6K41g1EaJk43ROqe HFbwHwyjdWsF2zRSjmx855Gy8ZnEjaBODUSR4fSp8ZuE15+hqQlL96Z+oAFx29uNbg6h9qQ2 Yxw3JEftQ5Bsyyjk+DD4osqiIuJ1Fyr4FyhnNINa/hkNc7I7h6r+pVQqK74rs2gaJqHdNoF6 Gi485eaoyylCVnsbEQib9yjsUS2DL01lQrA4Low12tctSXXGp7Hk0WS7DvHEYMEwMsEKQzwt WJI2qyGeETR4pJTY4ssrVFcraqibvVnQE3f1dBTIJndTQ/lY/9gS5/rcodj35gDx6mmUS9PU 5+O+NhFAX91Cx7Ypxvp00u9/dTgglTYExg4GnGoOG6yCiWIrZJy+0VA+u2CiMqbQgk+Uz3yY KE6XBg1/DMWOCurXReVM3WacXVR/Xa8wTEUhGbXpXwemb+AGch24TRG9iCxaD3XLUwA0AyRI fn9gl1jHPLlA82mfAN6979v2aewrPgbv0Aw0cTKncGMRVAAsUeOLrViY3HZms5wcvaJ0QxmM gUaQw93XsgyZUQOoH+zEUvU9nwZgFDOC5DDuPduI4ch33q/Q8+RYaxsl68YCJz/CYp70X/H7 5KkeHylbeuhSd5S8E39FJw9FSBEkVs8Fv5GvvFgampeZknmUGY21o8tOqLD3MjiW6yy2VHtF zSYpNh1Sh8y96gtUVBjI2GKqZ4XmNPUlDLDO6sRbny9QU326yj61AQHxVYXG2uZCzqbqjfCm RIFDpzYUOduMZVBXpkh91PIcuSaBdNhxLMGaPHxXn8+yHltjKxnC0Wy+J6O4ijoOowPbBWR+ sXPXzi5IGIPTDWEpY1CtbrFqIA7FKrLcQMGqUhQBibicXwvXCo0d9fljqPq6OAm7/IOu1RQ6 ZCx1LngXpxnZPPl85YgrwyQZ7F4QvDWatulfUIfRiPrXLvdcmlrO6DhCbJ3GXBTpiUH928cl hkt8nAL0HhA7YUxcMpq0HjvYrxZkTKTnmxXR1DWhqE3m6tmb3eUHUqlZMAhGk25phzeYM6r+ sGfY1z4Bfb9jXC3ImEi/zL20UtHMyGy/Mw218zaUBpVQaZI0qz97KnbCM8LRrLbA90Sig9xS 8MOV2A0fNzz3tshoR3FDc4nRpmFNEwsD+A32lhGGUFWErLq6tApYHHmw4GjoX+CNwknHV4k5 vgoOKkXYjjG3NLLV0r9OLGUM534xWM4vzZ0vZQenEDs4MRYxBnXWBhMsDV+XEMbSoLE+YRFL w0kTCGNp+B7AYDFLw5HJDJayNOhjZrCUvxTbLBPGn5C6PyGNBGPw6shg/Amp+xPSOGYMjW/G MsbgvY/BuFtiR1XCMsag3xq3AlcvvvxQWBSRD5/+dWDa0seoPwQ0QdWY+t87xlxjIRGCMei/ QVhEPm7q14nFXDbnlyY86hP3qM9CdjoLHduoehwu+3p4rGnqwhPlpa/mzQ9WMBlKnivKXPER wbPkuWqbYrryeIOZ1hmT5t8mSIg8q814Ftw7t1efPReK/PneuRMET/3Ij+H4NZ8WMky5kGhI rZ9rqkNdSJGkxfMingbOn4DKqkPy8MNY5VwMbEzwBm9kh04W+443qDigw8zpzI0h9qlcgPqS Xjiskpqi7NuzvTp6xxG+CJPNdafOo3TEhWqmNf2H2Z/rZQKUYSzbc1/w0f0dmoUTJcf2qTr3 tUkXpraK+C6i6lmBheNIKUSdOfWNfFO6DxELlGJ7OS66NPpYd536S86IAJehBTv0bMuAr0Kf a9Vv2TDoHeZbMZQcKfSiK4/KBNrsBHBqIPKyQKHZGaHPCxQFfbVSlyw62jJ7fmh79RdN2QWx 5Ku+AAYd+OyhYTJLgOFwwFNsn+Cpdn6sfMoXJYSpWz97aCohtL1HT1EJ4Tln9ZiYCgdzQzCv akDwVSnxMErRSv4wvSDfVqBh/nJ46cRP1HOPKTy9m4SzXvMdrmHTp0bLT4Vz0Vq4WgOI//DI Z36qmfdNNRMtauZjU0+K5sr/+DOvoA704an9Y0Udbzj0d84r/Bv+YHlPLX1/KQ4c1AfrANey hVppDI+zGn3DU44AeLC6fYCsx/DVyqrwWj59LDyRfSPfJKwPcNbHTx6gT4Bb09snLqeRDPyw HvTmK7qevto3gfErYvXZMub0B/Di67NnYn5m26fQM4Kf8XzL9Ix6iW1FbEh0+4yYn/GMpJtn 1DFJGJ9HqBdf1XUskyC4Hk/0Ks9CfPNJskljepVnVbavIg274lE4gtuiJXPRkNvnt1+jSmYf 8mwBattFadDDZECrOYtZT0uqKT1cTOnhl01TtJk+iUd7x/XiRTCMRLpuN1qN8D7/hpYh89sG R0SuAQHOsbNqKjUtl8xvHeTadTGlLiQ2Tlf0UGwf2jrM9UPCPuQpnu15u2kcCejafvNIlsyP bBxC2eIte2i+1bB5DOwYipB5ThpI/evAxpGdQ3Yh3KgTFx0Iw3Glx+qpLxp2UIS7FqZ0gF+d aU//QIGX88HeV8M9CkGyLHZhGcQcw9SRTsXeDX/gOP2lOpS/qMNgpc9ZucNmV5Nd0RfDWIy1 8VnLA0egfUUPyc5khc2xId/MyceqK4newUoytnScMvEDJqIykAxTYycRYpOPGRQEwvRRBAoK LOAIrj+BIYFwM8VgQhId5k0TSAGRA5wtoK+K02Q5+YEmXaZkHpgUZjk+h05kSGS4gYyIhC5V M5kSmUIf5Gt9qs+sVIH76fHS79uuMKq+2BG8ZOwvFRvkmPg8UEMycXLkUC7GUht2x5pimOAd uUZkJIKOJhRHO2suZc4RGb9UdTjWzxW/V+g8Ve9//8+ff3p7/f3j3++rUv1PtCmxz8qquYTB U2i1MOBVJAu8yMoCr6JnZfUc7iJt1pOrH9g6HFACn1UUIR+7MbJZi31c6jHgtVzmSelsuYA5 GOLByuMqhUEeLMfeB7BKdFx5qhKYRFotpXmWRpI2og4Ts0In+w2IEzjrsuK6a361IFzGNfiU j3kQqLMNw3DmpLfbUkY4lbPhspA56PVouCRgDmcYNpz2ZSDNqfu9ijMxbYIEXjlaLic/+wBH L7SkcZFVnLP9tEQqIVTxLN5M3wxdIy25I4nQgHTiqIQw3uHEZfxmGPNwInNLOntjatsPR+Nl LrGc51toqXdYd05cSpznm9OdLaG7J1qr+kBb1fs46jmpu25EuSMr9B10bpt7mJEY+vviLiHb idDfKXIK9xDhxLMLMjIktEHWZBpR/OwIh/ma+yMLhCeimdxb1Nc8qpQxkZ7Oq8mESPeXq60q c64Z0nCZ4aB6ePHmlEjvmymwFVS+0LCZOHfnjdLMcrt7p8CEBeJtDnGCrafVZsHzIaUV6KzD iExBHObYGrs2Ik2Zc46ZVFz5tdAug1bV6XvhMdF+R0HvhRYGJC9QXSZkkdAynkVmVlWtUFfl XM/TV8Psq/w1sa1tX/+ikRpCA1OzR4jPkTnVRVjJxnuOhF8LE4Hxqp9Zzt0ZMlpdHInt6Xvz yHKu93ZjTnaeEVZy0Pc2sU1p7xnwnKcVuhlTJ9TWWSZwOD4MsDzT+fWvBzMznG4+91hKzHKR b9iEEeffhBnOvwlTGwgit2wgmPRuIAzn2UCofZ/lnN+sZ0zN7TfMmMy5ukIXXwUHZNr7psww sZxzSlIzIXPOqVB3AubcYz3Kr8x5BqcaT1eL7uBxZairpjoP6yxrYYDOoYzLw1CWMeMixAfR oSlJ04YvgzRiItCNFNA1hLYSz20/sptjCO2lCJLHw5iqvZjVs/nZIGBPEtjqM/yH9SKGLbpg rW8w7CUzq1N1OE+/SzaZLEU3lDdzn4JX5c3cJ+FVeTN7Gt5QXmY3NNwf7E8KXfJX5WUWmW6v yptYvdCG8jKLFKDr+u1NoArHwrCqYUtv6Guqji29obepWrb0hv6mxpGlN/Q4NdAtva3P9Z05 N+GL6dtKYXxrrTC+tVoY31ovjG+tGMa31gxdX0P7pNuaYXxrzTC+tWYY31ozjG+tGcbhhUz1 wFM6Gu3Vg06fJx+6Y+Gezxkshrr8bH5evtKAp+Jc1OKz6flz9HFvp1wA1wfWKsNoq4rQ/2SZ CGwaQpdTP0mD+1KNyK4sRBB05pMFHGsLtCKNHo68oG09z0cTPd28HkV7XYCyLjtrHIgjsj/W p7qje8EQbo6ZUqepIgspN3YI3RjWcEow9Mab4V0WUW5eHCy5qkt2Aw6h/b5hTEB6EZDByAfe QSxhImFgzrVYeSF8Syksi0bnkg0JhVFKF6ggFC2yhFIGh8KgsCOu0O+JddeDZfnT4Ay+ojti oWX4j3UxpQcIocqMKakzrspHPcT0n/4JhX4tX8qTTuBAQqHpLVFyODx5poDidKqLc8kCYaRk i5mQjO1oArtEeCpY4jaySxrj2GAWL0YTe0mhqHMt0OhgUBx6cXgZntrzuSpH+jjoGjVxagW4 07eFOLbDjI4m8qMjQeCMHvV8GDuy9Mzoy8WgOMvcjO4OV32eiXH67SXcEOy4PXxu2IshhJHv NaL+ZXpLluQZdMKu2Sc+jNHMrhFZdb7geQbr6+PjOPxQj2a5cJx0DH2tbCJc1IkI6+/cxxtD ldc798GGZX135z572M+1HKphFid3fKiDC7MBDw+ykXXbCEn2qNAqcKYZRCvIjVjaDkEjwJlm EId2vsxzIVSOEySb5/l+HYfwrHvrxxPCoK8EyasaT6GsRk/vYbrfN0l6dB+fVoKbQ2MPRKCw faWjSdqYHyF0r5s49WxPSZ8c+oJbWkc7u2cbFDQlVr1if2j7p+GOFDEwCOcClY/VHXvxwDl0 QZ8mGgbEWNBl3e6jgB7AKUuXD+hJ6LGiB2BcncUDx/K8V4WiB2ButsUD7bCP6RMc0/uyRMM+ sfyWAik+Zb8obBd4WyBKwxOITZ+sSzQ9AOPV3BRpemBLkfgBQU9srVWdElo/gNe3m4/QD3hF bizu9PJtnUb1GG4jnPz25gFhH9hSH6aNhsI8gM8Iw573ZtBaQBHyh+J8PbFrd4T7oCWFJWHX sCQblTqi8o3t8Fjv2SQF2kgzpcP1lu2pdaubbmC6HHdYAN3gwq1CsnhK52N8T2DBsVWSyXIi hQv3DSxNu6beMlt8f/8npGdUFJgiZQlzp0hDuFmzOBuswrP4JPYa7awK11veMkryMCkpUCqM /DKLjll0eBuza7GYqkMY7ySgTYdhZH9KypgyDcTwpn2JpoSikbZAKVhjDN0WlihJheN3ieaE wsuUg8l0Rd8Od6SakYdjlYSBPvnEbw4z4H7kaNwhvN4yjDpvdXkceG4PZjQJLg/u7fXMpoF7 i70ke/fVwQKdomn6yd69d2e0KrPUXMvkjljfC1QY9+Acb2rWsGFxYO4lOxgWh5VesgfDQjuc tVwuMTSyIToPUqqGFParH6t61Gbj1LPQJMgUJbdybnUXZGIPjODVbVMdeTXaIWWSYfStcrAT JmmswME6Hy7f6eACknJshjBgnuUehjDxxEya0WS6uluhw2U/F0An7ewKY50c3oSYU9wslTk5 GOe7JMIxC5pC7UJOFOYlfEWVxJQ8jmmsNtp6JsGKzyUc/hlYmL6UxrA3W7h5VhDDMOjXEo4Z hovEXIxdSsvkDiebv4ELouGJT6fstcc9GC+PIHk6V0riePV07GcOs/YFXulE8nmX2rSE8CZH UVGyhbLJyx230EbWTIGSn3mJwe5elHP34XCoffrKkSeVN7hcjaM8Jem1MetPjGc+xSm5l0E2 7cGEuo3xnuNcWSuDt+j+L/9yr/77/p/F397/j85ThnbuXVXWxYmjP4RvaJxNnKxbvf47fEhm 9GpUsC5N5YT2NQe2DfDcMdPqT9VBOzy+BnjPX1z6YvaZCKHn98zJ52tH+TmC8Cvcihbn4tQe WQCFKX6He41DmOe77+iuR/0J3jU92XEIHcI1IkN9t3rnvGKdONqi4i31MC1B77DV9Qq053OT wHP1j21f2PKjpccw2kPEWECk2J7VgqHRLuof9Non7fVl9cFfURswJcXOVJ3+wcHLm86a1nyF 0YQNJCslVc2Iz0fqL1CBwXh/Yu+rMMYTR89z0FdUiX0Xifo8Pngmxr7LFxQqWd+F6QKD+r4u 1i6PHnW1emVbjoVHXa0oq1yGJ40utgjqIUrKcK4Zyu8cnzdjO4x1NvstMvdSSM4IUuOoIlmF PvJ0Vh9mERTjpO+EFJENoYlckzQVC0s9AOqy6is4ld9l2VlwEr/LqrfgDH6XZUfIYUe46P/s m0jmXduPxJZseud7JJ4fQRVZrkq7CyIrGg38l/JUHCqapwVMfmSuLBv5Ik+/3DntnCbw8Se3 jp7BeBaJs1ZY0srEGSsMmc8y0aCdSSsTBm0n8kcWiVXOE0gSsa65K6MgkP2VNGH43nHiQrfe kLixYnmOxPHMkTyoqZ64hiXCY++CJJn4nFYNQ3Uea45eKaB2bOJk3xaH/nI+zzlY0JGS9n5Y zd0KmWYUQU//uiiKguxIyaepnCYq/eukUqZg5Oro8HDlsqP3aUQ+t+2hbd0r3wIU7tXPkPvi PDxWlXsBXMiM3MvbgkysugbtvnQ23WnGgaGoLCbVITQxJ0VH6oXywnp4EX2Fu9dnuo8UOPbk cyP3dFzCkZI1REHg1SzsggqS9OqB5DOtZx/uN/L5xgmNIQ8uuG881B0feESMM1KP2oyDt+UC Z6VmTFblo/o/OYV8cRx5bniK24K76czXbWdNy3Bym26s9wXnuBUwDpjFtDnckVRGcL6c2Ys9 S2Gbmgl+7nTOSW0Vv5EtS0PDSXamv79UJqaeCB1GawMPLHjrrgj9T7gz2XD1jwM00WOo9hWJ ps5JZEYisYZ8KMah4BQyoUjhRRxj8lyXJlmW2kfAicKyXdmL0NwaJRFUFE30WJ3Un00Ygnud TzyG2ZMfL8dHO13B7HQEqQHWV2U3WZ+iRjoP7bn+nkWi6YgpWY5Jbrxk9Y+HrYYwyjyBKVas 8UNVPzj+gloommrkkzC8QaweHtSfaNIIHKrnvi2ffrDaTZEVUC8w8lDOUY0rQv2Th5nREec4 FtYCpP587zwWaDzPMzPh6l+31CgKjsZpzWS+/ae//Mv9119+/Y+PX3/+7/vu59ff9X/cjx9v f9WaKDhiZXs68NdCW0waYkFob3zxpdFp0m2KV5j00UCyKKtzPUX/BAIvA6WzF/ubNX2lBy+t 4Z0xJDL8W3yLL5UDMy73j/ni9BdufipePCU2P7U8aUZ/ooQxJRD5RhXgfUrGMv5s++T+tPl1 6Z97SgopPlMjuOtkfl3+J79OyNRu+bY+GOQ68Mpz+Jn2wflcvHwOxp7q6lJN7BVPMm/Qdpwx rd1+5mi1ORwGHARrOBrNp3j3RBhTnOzr50KNaTJtyl2DxyQZVH/9UAykQReVQx+8wlmHE7mG zZJnhY7YyoecWm87/8ABheNvHvnki/uCl9b4sOEFijbf++CeJhZ4TniI58uLjm1EZYD5Pwiy ri2e69A17DmNMVwcnovzWBynExlaLU5qOOgA06U6G9XH87HZP2pLQfEVbeNOzUlGUR+ak23+ incl5b4t+gO1Bo5uz5Q8FEOYBkKG6b17+RjqmuJ+RSE69GtEhoMMgz8k+TW6siou4NTC0KZq AecWdmSI03DYrQqCrR5XuC0KNgBc4bYwrnR1CjewAbFNngbFAnQWQKxrGd7rLmH7adBjZwnb D4O6EYZvahnmvl7jU1Ggzd8KnwqDtQwKj9d1Au0rlrAtCAxjsoRtMfCphLupmIrhumZcwKmF fQNATMUQvgHQadiA3j43gb6esfwwb59bfpi3zy0/zNPnupsahpfPa9wWBaY2WeO2MNBbZ54I loXZMM0sC7NhmlkWxj3NxOt68Q6AZUG8A2BZDPcAELd1Ag1J1rgtCowBtsZtYVK4EvbFoR5e eCWEPZApdZ7uRBrSngArZg5twxesEXTgMYw8NNco3IUHz7Hs+8vswBYl6O6NKfn9MOWWgj3N soeZxYnfZ5bNlfG4XpTBsnDoWbYyZaA6gP1xDTce1cOg9lnVM58KogQmd2ZMXigcQ+ZIsTyh Zds0eqOXuVwMlrC+xlR4jOfiteyIpXtxI5xEe0uiWa2xyxxpjR9fuqov247UMRE01J04k4/z k1R2qx36TLcntantj1N2+Q2PGJx4x9F45ptq5FjurhPxzKvjQ8Ne667D8PKLq+uFQtjje4+n 4odiKJ5qrkdo11c+1p18OiVFpldqBX/96rj5sGacEfQZ04g81seiLEy66ziKP6BdHCeqi6A5 tCLk4zDUn+pP1thhiD7Vl6ypWRbqWZoaw0kXgo7n1XisCtJURTjtBlHyWKRkZCOgkfwSFQYV MG9V0XUmwTy/HZoqM6aPpsfqXPV16c4vtXxA7wjr/SDL4uy+OLl9qHvY37sPlU17Jf1uBI2B NSLVLMvpj+H8zVxqjt2OCM7EdWqb9J17L0agCI1AgX0KiIsERwZzhOEtD/yt8IhbHqTYH4wk 8eUdXvgrbK9NmxT2BW/XGUsZg8ZVhGWMucq217Y/hMFk7YTtGIPZ2gkrGENDgbE9Y2jqYqxk DLq/ayzkenMospu67NtjwRcB0RtsecvJy1C6dzgzOpSle4OzRAv3/mZVALNuCKxuin4oOKxH VMK7fM1IdrN1qEKIyybOLW83cXDjW8/m+dEbjNJO9vn7y496NRE4t1mxb6c58QCnOAPp8RZO Acj0f8DhaxLYkVBsqUhZ7somj6Kc0r7g8blk93duo6WJzUxsbEewohVKYkNY76eCo3XHcOBr RC2pJm01f5A2dRZ/3Ic6Ftjt/dLNg3qn3LeSqyJcPvmv9399/fnr/S9f7+P7//zl19+3SeKK Ev8LSW052hLl5ltillPMgvLNgqhAefi/EaTN62RH6d+1pdf0cemWCj7Qx4hF9ab/L9V7oG8R i8r983KGuack9CHhtp5i6oBO1OosNT/prwKdYuJ0qvQ7vzFnv+3Hl+KkeVNj2mFLv2b868f9 6fUfr/eHv7/+fN+9/vr6888fP9//9JvnvZMwyuEdGBeA3//rF83ev3/846e3j9/uf/nb/ev9 2+uv7x5hajYq1AzXKXlaWo6Xp7GeZ6IYrrBMSW0Dbw6TKbSNaK9D1dDxIIZG7gTJUKi/zk3m KPVvtGmzcKr+epeYtOE45ucaPhsYzm43kruO8G0FEQbGtoJF3bf2XBPjPNdEyVi1kfdGZsHe UZwVnRThH68//131jd/+66ff3/768f5/7+9/gwkrJhEJichJxPuvP/3j49ff/vK3j9//8vrT r7+oX01I3dX+DaeMqUd2G4gP0M1aM1LNsTygoB+04dRyQBzc+zBn5cGmJU5YeXCDxJyVB1XA xMVWHtzoE5dbDm70p+/V9Vf46kVMHHQ4t+VjDvqE2/LtiYM+IV1xLuy+J4YOMkyZCd+6OAU4 WJDF9WS3wOGOongonk/FngsBrzWJkl0gcvfxaiaNUkyR8NV7bbk7VcAHqoCxPrbnSCYZ7Upx SvAZDAnELWlBygoEPRxnMCIQZv2YwJhAdN5agIPkt+MlYSrmQ0UostWb0cSAMA/YAuTXwwyq Eyqo3mEM7RmkeoeBgRYvb4jc8D2NLSfMEDSzD4ZMvSRds6VQeTWD9EUwXPpCIn1Rhg6zC5FM er89Cel7Mu/3cHYrmOdjBnMCvaU0mxAF+htImGjM6euGMcTkhkE0EOkfRaKgkfm24fUW9b1/ R/NHBiP6LkDqnBn0h9mXTRxT4vsYK9qZ2gfMoaXecmS/neG0VRXHFkxgBD5FmGDa7FYAQ1Ea TCSEwQg6BovJdET/OjHBGHZbHF7YozLZwXuMFx3rpJOV2VIGGcxPZMBQgSWDDu1mX41sEZm8 Iq2GTo9XndSrycXKFabrx/Y09mxHn0B/b6ZIk0iKROiF1VSnU3FurUiohGVMjsVzq88nyStc NSe26Pd01dMV471WY8PkD+tHjMobr/Idpc4Mkw+0LChCHXti6orqF8c7KPt2ipySfKDhOXGy Kcshd6vG1rBbPXYj+NEqybbQDMMWW8K9x398Dd+xXQeotYeiH+qxWgfuT2FYfMblKLoJd2w3 Jzxe4nDvPuHhZcZTHIt4KswShyeNuTBL3F+YKlzWzAa8XOBYV6cayBoHZBFU1xElq6M2hbpz WkQt2dRsNNWPw7y7bgp+O9zXG0gWpQ3VGOE8oguUnPjggJ7QnY1lBjN5LqVGhEL/ikFQguIw m0MA3N1M9gqRP9RmDk+y2SLjM+xCns9JjhXT9fmhPk/RnXNH9sm2G7qasRQHRuitB+9iLO4E cmNWuKwey3qJG6UzXDab7rE9v5hivIVok2cxGXpDi1N2WyPv3ZMCVx5KsdOt/f4m4N32Y30e b74/imB+Ek3riBN9W9eSwhrmOqozEB4d1MHTjLfoPUKLA0EyCoLh6tYFMZksY7o4yUN1Gjnw PHaUNGRX9aQTdN56M9z4YtfeCP3Upv8b+lg0Db8fVf+t3Oc7t8Nm8WxDUMeOeGHPFPf5dBQ0 h+kfNysoOaf+ga9+Mu0eq909kvU0qJcWh0N9ZvsGx1WPhsvOpvx25OM9lH1FCXnjHXQ868uY 9s87bHN0rsZnmj/iV5hKgiB5ftZOW+YKM3EFiTVWFUkEY9IPkexOxdjK7mouMhJsohfJ55+0 H6QWmGJTy0iOPc3ReY4NDyNty972RRo/d4TCvTsJTOOLJVHV2BKq6cKAcPwrMCejgxx7ySlo JxiC+3YjKabE83kOb50ZYzcxGO9Iv3KWBm0JGGNpMGKPwfgDvjpkUe0+6+GV77Ad2NxRjkQ6 Goya4XA9moZ4dQkl9GgCneWv2LDVko0R+eYX2Vw7Ir3lVGTzTKxjmGg/yPK53ptgRm+vDr/p y7ntjdlIksATF0GyjvzhsQ+l2aOkKQxmqQjZlerUFrtXs4nL7Vr2/+kTjtW5b8uWBEJ/a6bk 40OXR1OmFbgtG8k6Mw9g+EzDyKoa2NQDrnIEipAyiKi3ol0tgToJIAUNdeaS12BMgbJi7Jk6 SaSAoTmq7kki5f2KPV+tQXr1q/vV9Y6Cdu6gAfXM9Q2Rvq9OUlGNd043EIuqzVxZNMS6m0ex YSKNu1gYQvuaJVvsifWWQbHlkQV7vy3ZmSgjIU4UadFgJ4rCOPyGOFL1Gg4JdhciC42fneLc TZslnFpZ6Kt8FDFowYbECh8rZrkwd5Gtrh0X1dddKcxriANuzw2QEeir/jhi0FfGKAsf9rad kBZ3DVM7eXuhghvKVAh9lhaltSgMWmfRmF/vq6ooDx7MGBAxOv3PrzfafgHt5xnU84Q0qd1C 34yh2jQOpMmDFb56+38eJ5b1D+4g5IElsKJ5DYcEb5iOisIo9BXsmwoIjgj2TfAEJwT7Wpjg lGDvyDFwTrB3DlXwnqsOKtHWMFWdvwENTFXnmcAsTFXnmcUsTFUHrx/WMFWdf9IxMFUdzAK9 gPe210GF4hqmqoPeXWuYqi7eUBt72+vg5mwNxwRvqLq97aLwPnwNUz3Dq+41nBHsm7cJpkaB 7k9reEewb5LjRuEmRGqCG5rb0LcuKLrizuGbQ4ml5oZebiuWWhve6K9Yqgt4Ab9i+eOSDRWn YC6FbzklmPocvLFf7f+43uBZfA1TxXm33gRTmb3bb4KpzN4tOME0TqD3yBqmceLdsxNM4yT3 re4Ec2/ONwyUcurN+YYG1zRX9YaRcrCLClSCrGGS/LahEQ92nXjb0IgKpkZ829CIB7uowKgf a5gaEZoZrGFqRGhosIZpzL5tGLMK5hbHNvdrmlocxqy+oYWxqY/ftjU5TwlvW6YE20GgXmsN U7GhdmsNU2+CYVbWMJX5fctkansTtMxbw9SbcHDqFUy96X1Db6psb3rf0JuqqcmhJd8NzfXh bsNq4CZJXt1NokFBoLs5NBgR6G4KA9K7oSJ2JmMS6W4wDSYEepRHAzdUAk2WZjAj0D2KNZgT 6B7AGtwR6G5I0zTcNu5ha0hunA3Nza3jXcIFn/JEAm9Tluylm3Dv6E4m0f5DYTqzGw6bRwtv OMUquD4S7J1i0sQKhikclyzLxaHjLJvNcr277WyW6+46dfmY0rSMTSQWZEiku3YNKYh0f5Uh TSdL4bXTgoyJ3CAzIdKj+NRkSqS7Rg2ZEeke3IbMiXSPbkPuiNzQRrTmp4l7fBNKreRT5xqU msnTqQmldoL3tEuUGgpeVyxRaikYVnSJUlOlG6o1pLZK3VMcodRY0Fx4iVJrpTDB+TRnJV1D YzWK/HqCiGetKIEZyJYs6akV7N0KJMnRFiPxn6wMbSYNRbv7w9CY5L1RsvPpCiPTbdXUvUED O9D+MMMmb2s4NLBX+0ewCYiB3VMWOlhzd5xh/92FvtSYhGTYgmBRBFa5ZTjO7wom1LeIkVxB sG/9IDgi2Lv1DQPZlKaGcazhJVwfGfZftWjJVAy/ktBIZnhDmSu6HVKwd7uuYdPbFexXt0en K7efdyARTLWR+2pDwXsr2TeYGCbJMMPfGqa+Ae2nCY7joKGevNtQE81UXt8uhGAur/euxsBc Xt/BlmDqFzAx3AI+2jK/bqjjoy2z55xjYSqz56yjx5/gO6Ys3TBjCL5jynBO0zUsCN5WjIhg 35CKk5gsOPzalDgJLOrtREl4ZtTb0El8vrKNYO5VYeg0cVyI2db07jO0vnbx1ZCJI/ZH23SX sSUvivwDpzuxnKw7YcK5BwKOzxnuTF7y27y9N2GSbQk+KcBN6NtZ7KdGIJCeTEE20Ry8F1pl PI011Ra8RlWErMZImJhJkcN0rTgU3VgZ+7udI00pUTLLQ4pXAQ9HM2lc1EToJSN1ojSlzOFe ehaaUCD1Da83KSUTfIqzZEL+x4kjc8SioHc6Wxi0oLBkGOdBYVC42ZwLykI3fFKqazT112iW Z7TH20LSLLyFpHBnW0gz8UVbSAqLtoE02aT1j5fMKdXqBpm5/vZ8y7cbr798y7fn+tvzLd+e x2YO3UImZg7dQuqZI0+3kPrwlmdbSD13Kd7b6ckNOf+CU00wKni28bSlkGIXBxcyUcM5gWc4 mmAYdMDCqicZp/EggLv0FUsoOpNOaDQXGKcEnuFEwRxPcUuJaVlIvKVQqCCDc+w7vmSpIuA2 esVSceFF34rtiN1S3h2VF95qrVgqL85numSpvPBOa8VSed9wuiKK8j1Q983gdzEmRUCKlwAn eXxsTyNZte+wIQxBMk2M7Zb+cdi2Ny2VL4MjhiC5Iw92/eMDIwKhxZQFc5KIM+1NYEggtNCZ QHp17n91QmByUzernV51ZS+x9/zGv3+1FTOYjAOjYdM/OGbIseq/q0xYlI/Q5YxvMO0K89mu 8RPSBnt1+GH0ptt8vL/jhO1Pchjrswn1/ho40tUzp0UaEud1f9LRO4JmNJw6uv0Pi6gFb0ZR AQA= --tThc/1wpZn/ma/RB Content-Type: application/x-gzip Content-Disposition: attachment; filename="skge.c.gz" Content-Transfer-Encoding: base64 H4sICKBP6EAAA3NrZ2UuYwDUPGt32kiyn+FX9DCzE+zFGDuZ2cRM5iwv2xzzGoGTyWbn6AjR gC56jVryYzP+77equiUkEA6Ok3vPcpKAuquqq7ueXd3K8eFX/RQZ/mEDw+FnBbFa8KqJz6PA +x9uhmeFi47LhSUqbNTqsgtrYUytkHXCJQ9cHrLGzPBDHiDGOx4Iy3PPCj9o/Main+yk+uon 9gP2to2QnzH5Kfwgn05rtVfHtdPjk1N28urs1clZ7VQCj6LA9wTwM1ly5hiWy2aBdcMDJrwo MKHJm0U2l5x/1c9xsXj8dSlKJgvl1kHL8+8Da7EM2cmbN6+PYPKnbHwvrjzXhYVmF870sroF ilAI+pL1jeCG23ZVEWzLBZl7QdzDPkQrz2Xm0vIFSMZwZxnym5LDdabPmAdISUlSxAO0Ag5C mrGT2tE5nx4Bz28qbGoIaIJRepYb3b1ghsldy6yaFfbS/OnNXdXEYRF7PbJgSoPY2LONAL6l LBGqEYVLLzhjrSW0h56/ZBeeJ1jZXMDXP8W9WEka1Rk/QHilP6xvBSsPeZi5wHnZseWvbQwa ZDYLuBDMgCX6M+IiBM1koXfGbJxDFkehoNqF3FzC3AwbFNCN4AuXGhaPGWqhGEzFuDEs25ja nM0Dz0mt9wuBdG75lPnGgoszdnt7W00NZXoOAlx4ocdK48j3vSAskcwENwJzya5c79bmswVn TVhzGrwkGSmRlkg2gQU/8BaB4SA384BzMJF5eGsEvM7uvYiZhssCPoPVDaxpFHJmkWYcAzkw Imt+j3SgLXJnXE4PpuYI5s3p4WJwzS44LC3MfxRNbcuEVQeZA0cGDI0tYgkaMSU6iHGOPIwV D+zcA8IGrnidcQtVj91IN8FO4zEUwQrzSCfKRoicB8zzEe8A2L1nNqhiglpNSclyYWUcGgF+ Az1cBgvkIVfmxpoBd6XGmHXHJXYLHHhRyIC1wHDD++p/kQdhI08ICzUNVMeHGcYLBOby/YzP LZezu7s7dsyO2vB9cKYWacan0WJhuQtShSln3CV9nd6DpzBc6hlf6e1O8/pCb11e9YftxIZT za3GBNfXMVaclrc848IElYLVRanyg/+qtWwT87R8Z4kyWWTRYRxxZIxZKyn4CvBkynklJtgA p6KCEq6LYPzO5H7IZCCtwPcsuDkRYXWpfp+6s+pSGvoqvPe5qC6RDhqLbwQhjpf2Iqw17PeH AwZiue51xokTGl8dvXkN4jZSXhvm4KFhAqkI3TTCSnYFumwnskPLhykNxy+AGQ/+OBwtBjTA Me7B8XDySREODQ7TCO5J18DoKRDEXr/KRjZHnzTzmOuFLAQ48GIvTGh1WeS/UK7ASeztXUf7 wMClz8AVGQJUFgIJNw1gUhrsrWXbpFronRwv4KS41nxumcAzEl9x7qfkoLIBkJK4d81l4LmW kD4Ah0RApOCl/U0c11jXNe1oJsXFlha4NnC397Ea/EJB4VgKv7r8VTWXlsdrSZawJYZUMvw1 3bbCCGtvNKIHdhcbjTwIXG+jzfIwGGxiQ5TZhHNB8EHkb4L6ppW0GMI5nt6H3AvAvWdbLYi3 ItNkbXICacIMUjmTb3KNC5vbI1bTaD5XjRipQ1LJcIlRYcZ97s5Q3UBQco2SaIAKe5amNLU8 8fJ0a8pWmGE5MkxU1aQNOD42l9xcichZS0+KDxbLC2LpSYGib8y0KGkmLbbzupZ6vHMMU7cs 2ZIkULFykGmniEGyEfFMy4Ivb8PsgJbDs0xZp+YGju86Vqbpxp9tkd1okCuVajIgC9qAEVbw Z6bJpFVLNQS2EyaT/aofcO3fW9IS1ZxUbIfR1j1b1rjZEysEdMwhCIK3HJx3L/SRNmzp5+ME nCW2EXimPid9+R51cb7JxtrGt9qVeL92SFrHJIzh4luFURkNUOGVAd69/hm+7HsG/dAd5xBN rdO4Gg27g0kZUi/hlEvgZkP2w8vSQZ0pUtJxw1/IooQDPnt5y2Kri33zPHJN9MiGbYU0RjzA 9bijQ2Yx+R3Sik7ranzdz9AMIPYAgS8hqe0gKSB+gas8WhgUELJkKGAI0AWMBzDlFFkg+a8O aNJw9CGhB+HZWM+bwiPHrDr2xZts4TSH/VGvM+kgDRQ0OkOx9GwZoE3Y6qFEhIP7k3j2c8jo SRcYbuUgANbwH+PGs2YxRiXuelOrneA3ttMmJ0HOTAWnoU8utc74cthrF36q0ZzcyJliKjlf b2vCJWTgKlk0PXduLSLYQbAby8D5Opi62EgT0hUDdgrZUfoNmHBDa+ujhtboF05+LhbjeUtx YDiQ4ILmb8T57BFE8zgaqKQrCfMi5AampNixzQNHtmm6x8eJHve6gyt9POp02nqj8KkEO02v VGEPO0CaO0Aa15OhPuhcEI0xblN2QjR3QbSvR7AkIyLRhJxkV39zR/95b/heb020nmTi3hkG Gnd2QzUfgdKGvc7O9aDOXSsx0jrn+mioTbB/sxPcrj75MOqwXZR7/YkOKWwH+lto1ZDGrcYh pJUEmShQu/NOvzrXOmjOzTIkEwegKzf6Cje2OjxSUz603tV+y8HQIcY9htUYfMjDgj2nxCIj GYOhwU7XXeGmgKcUftjp6yrkvGv0rjusjJumRmui91CpUMHYX+zfxQJ8cDcFksaOwVDrN3rp HmxF6JNaTR8O1LBdEYBDCKMADMOwI54xtRX0ajx8ZwQFmKIE08Ot/oHn8gIsDYw56Gz1XoIh 2XxGAJeNQRvYKH6zANfzsJhyrrwvFhhDj/KtbxPyBKiXZTJ0mQUsSmhc7tNEGTLxyAzRWw06 E9jivuu2OuwQFOCgHmOBPy+MVxe86RnBrAtJxm6kCiORs0O/0VoTgLbmcNgrEAHYJHpmnzvl PEhikMCQy89DITePQoG2Rr4GEUKCHFaoGb4imJUfBnpYYdrv7cPDzS/oPqzEnKemklI1XBN4 KmNKAGonSdMy6NYMIpJcJD/UA76A0ACjwfejpIYuH8F250spxoIawtbiKYJt2RCInoLwu7NW ArHScZvDDsFFJCzuQwRE0zdMLEg+pk9yBfxNsUp87a4PPmgfziVIAbZEutyr6dgBa0iU8OdT 5t/1zNB+jGvVZYEP/ZMdoiRRpKYz25jHBQ9bKqugLbvS0g0o8A4zIDcOg61+5AilcY6hP9Fx SLQwOh0mjCghbRJGI5vcxQUgLxCKAtjRmsgmjmXb2l3GpLQtyNjiJfB6gEdQiLgmU74uxKlN yBxjJJSWzY2g4c5AiAEoRIIHK5MHOblLEwegnZCfnWSaaAZ0e+USS8MqI++H0WPKg6ri8lvd CaNNRQDnoHF0ek0nyp9pSkX71rSMAR4GQIfnCmvhQu66PecEBwiPWt1HvCmucTu4wUm7kT/B /fpj0J6/D3BGh8cXe2lxvMfFRKLbuNDH1yOETenf9ctTxtjICARvk8UPpsF54Dlj2wvxfK8M 6bwIse4bgBdQjRmm1InQCuaAK6POhFJTkKICmQHpXZhtvhduvAH/RulG5w5Gd//v8o38CoRa oNTCY7qneV6ot61A524Y3H/8g71lJbF68xpyzNKm/y5QzWIWA8NKjleID+j1IpeTVKC4hdU9 n0vHKlB5ZMHD88V6vRUORRmQl+V06EQAw4pE7M4HnM/4LKO5hW28tiV827hfI0J4CsEpiKzK b+GRSa2xcqxkC0VB8yxYvOZ0SpGxw3bk+H2x2AjYYFYogk1/hsBtIzTK1JnnHBGi54G7y0Cs FZgtbG8Kye2NEVi4luLL1eu4mO8m0VmR2PkNaMvgutfbjDys7Y0C4KyLtYi5YSrPC9BYbtGu O3Vi1aY0/CtwSqwSA0liySZ3v2HREzOcj6oa0G+0xn98PEUd//Spdvfz61qFwVet9lCBx3/I x3/A40N9m562gx4Sq929qhHyq9e1h/rX9iPKi6SDBDti+ItKE/gYxDuK/FMleaQUV5sYliot w7b+w7cJ0HlQd6joaLSZE2dscNxQ50zHRXSdOwJW8VOxsDO2wkoBzNGv8PNj7Y96AumbFqaF QCEFNDIt0C8AwtFgTwnbTljYgjVnZYSXR4cqmywj4gH77i2rHTDgoKC2qieADlv6AvQe/epw B7POIMQRgEI8Y9VINECEYEwF7BaQqzqGwLDhyyx0PTiklXh4j/sAdG4KldimMJblBDiHIU+B bmGBZ+xeBFmwJZB/yd86mDbBXXcGEFIHxcLxYbEAEhi6bGotGNq3gYee5hLrVRV2y5OioiqX vQDZWVOLSonenJADbtAhB1Ww1nkmHpiviVYR9LhYQHZl5C4UYGWI4fEK5KABldZ80X7vBbMy BU+Quj681nStc6GfVtiPCI4LR3jsr7cEoEHy0+6MWwmd94EV8kcJxXQeEocWL4PGHcNXVVnY fIFSePG5jfDBwcSTICF0Pbqo8JZJJ3lgeQGi6y74G3PJy1l9ILut1WqJiL9LETnICPFlRogB p8NHpWRK52pAJd17JtVJPWVUBgZMK4OCVE8Z1a4n5GNLePjqxZHYy2QKFOBnFOdpD4E1BDqH pappcu3q845H0ZJH213tN8yLQTDqeRif9mPtS8RKK3WW0YnlY14pFSTZvkUWcFcqV6W6yLlt LOpFlbQXCof+gIf1Irk3fGq0Yg0hBfID60YaOcKhtsXpPpXwJAAqDCCizwEgaGuQPSTDxe4u NX5B+pm1E5SD5KtRCgoxHxT2mv6PVBPq9SAHhAVXpKi4iOVI4pNqHbMNCmkbkEiWR8LK9Gxh +KQAfe4opEw1SaZKhAF/ig8McoCsumH2Ku8X6I3ryeVQK5eyF6x+yb9g9WsJCCtE9DladzTp DgflUura2fjqCISzffssvr8gS/wpQj3Qk8G4Uy5djHqp5lFD65fHPuSleqNCh64nRyWm66p7 PNG6A9pGZQ8gDiCvzqfSfCYVLHMP+IK4eT6V5rOotCO/BZ6WFubZVJrPo3Jue7etMLCRm69A pfkcKpoHLr1RKTyTQvM5FFqwwYFN53NIjAI+xzLI8wSj2Q5tup5ORR59ysCzPuh0kg0cOpD0 SLABESMejLlZYU8yMmuT5/Um8YmUto0e650Vlny+nNKap74hVs9RTzT+sfUfOst9Ok9JCps+ 6UzqDbLEI/3lxy0auH9ao+FO1hb8CbifSnhuV0/dodjkpJlHrfkMTnbg7uBkfW6bpZV47Xxq a7RcTj6DvYOX5Pw3Syx22vm0EqRcRh7H3cFH6hw5S23tsvPppRBzufkc/g5+5Fl0lpT02Plk JHwuB4+hfU5Dmvky3qFva7RHNeRp2prcAMiV8g5aCdJjGvI0PlJ3CHZIeAe9FOLjGvI0fuSF hBxR7yAj4XdryNNGjy81ZAmpeJ5PKUbJZeFRzB08JLcusqTijCCfVoKUy8bjuLskEV/g2FhV lVPsEEeMlC+RR3E3+cgcNKwTjBzkenaYdbh+CiyG9s/DrwP452EpAckF+4aFy+TCADvC29o2 v+E2q1G18WRdkKQZ71VK8APuG4EqE0yROIPJzehVD8wOg8h1sWTAJukyAtLBSgJer8c7a5Ff iWsR9A5NUtlAvrDDTJ8PIwqdKsTX5Pmd4Vgun20WJrC/VmGwK4ZpBvfyYjvQ91bY891b6ANq dAs4XbtAldJ1XAz2JTc+ip+KYgnmVLDqxeS80fZgaKwEiHoRxV84pHUd0xXw1GHPGUu9xkVX 20t13J+H6mWEBXTiu0psNOh3kWdJ7B1HUoW3eLFe5Yl1LBAXYCnqsP8/PozvDZmg0XhpLi6e WsGfSCY+q25Hhk3lliJdT2pe6P3xRRkPF2iO0ADmq7e1d/FjqzHBR70zmGgfKsVCoVySRYkz 9rfaa/v3f7tgtuXMOhykSxdYicC5lq23tTqzfknV9OHx739XpR3EmNyRl7L++Fj7o3p5i0cA cd1GlRr/njluIMB6Ljb+7LozfgcErAREi0F2Udcy1HPwNuk+UOmUDglSlX4nCvmdLLPsMXfh W64OBrEilSz/uD0bur2Ah+89gKLSTi7Omk1tE+GhmI8yhjA9MsKlgqPJxD6DDATvXnrxqzGC 4Ys/NK0MveBPYdzwHJIVaRLIARBue1jVZFpn3JmgYUp3Uq1WkSCWtuLTDlm0TomGlLE76IIq NiaNdOHfx/OvVbl0+Z6cXhma54Zlg68AxVwvVeTGnIIvAwf1GWZVGbh81GlcNLoDtYLjVffU JP4Y+wyHdYTugCmH+8yHoEeuY0ni+0Cjiu4PjZF3f2g6nt2Pb3USQC60R3rzNgNSL8YW1Izm Y7QPAOhMLvXm9bk+7v6roxwRejt9jE5X66KLo+KiHD7lR4m9bWD4K0GllyS2vkDqKeU/2a38 5cv31En3xp9qBHsqeXeYp+JJBIl1/eT/XdeB0b01PYbdR89j2H20PIbdR8dj2H00nGBJJ/Ay cPyONV4nYUK+vbs+CWvJXkz2Qb9rStKyVH8B41QvugjSnbG3sGW47I70blv/cH01HBywv/7C oLoHqN7rTjoHqXiZHTU+hd26baeOA5KzA1woSAEEDnCaIqdGxxhyLYz4GkH/ukf3lBX13ebe Hda/0OwSzhQHfcMU9BpxikPM+WCwVFaTOlRRF0vhR0MfX9KBV3JKnBy5PDDckbBHBzuRg+0x lrrEmhqSzo52jZqy46uONtDfN7QB5HCptLBr23xh2KnXM1DFBGRZM0yxcAnkJ5f5lCEzZchK YDhfmM/BHixocsKQxWGe/rcZ5qPTSNxXswzEa7FrzEL2pA3PqdNnY8qoqJ853PGCe/WOKw5H KUG5zx1qgzzmGJKfA3bGZI5Q/i57vRp1O+slB16a6Po0nk42hfKU8f9Kkev70EG0BF68lfc0 SVHJUdDJfWuMV70mQ707Yn+x1POktdFw3R4hilT+lhjOxUmFpZ5O43sQSQuebqb62S+/sJOf wUWwFAlcv8y1cGXfuIkQ4KZskOXijA34bRy/ks0cvfkEOynLiRwmMBrTC1dVWly1M5AWfd7o jTufcRoZBHnbiM4bM1GuIXBjoBnOxKPUWpSlu6nEXqcBrN1IW1rTVDLNPdXcCoc7h9qMjvnC Tm4+LCy8hqLOw/FSAAX89IWHAb+j6a4vZlE0SV/TmmFbco2gjPKl89fs3hzPX79RESBjH+wo 2WvLjUna3PiWdexVEYgJik2K+CLalr0hfscwlywuB8AuiTaKKR4UAvU4kEhQVcD1CAXxlwZu G16xi+Z9iEUI/A8mYEzLxZfHy+v3yjmDuAwSfHnK8OTZiUSI6PKlNtj7A+VNPi28pgOEPJdL hg/yagxKv6nSgNhq0qYX2TN8Zy6pZyhgsh6Cdr0wXXmI7+1lnZi6+hAXF0x8cVfHa6DxIX8d jdv36CQOawOpVVasGAE3aBwwakQl2j3uLsJlXaa1+FO9TCdfYEwRibGxoFCw6lROsD3PxxnS mNCX2eEXmpHA3AxVnTwPrR3z7UjQUs4z4vzf9t61q40kSRj+LH5F2XPalmyBgfZ4vMa4XyGE rTVIjCRs9/b66AipBLXoNirJwHZ7f/sbt7zVRSoJ6O6ZZzgzbqjKjMzKjIyMe+QlbUB3Og5D 2ke9icxFA4DGlzYqNUgmIDQJw/kQ04wEFxd0KDsjdJU2bTAyCgnNQbUF9BakgOM6XGZAnX7c LWzY34801YH+3AEEM0i+UqHda6XGvA94QICee5GOr4260+y2OM4RUrURc5EujWa2E0rRsyZE nAfczk9cz5DDk5Lhrgxs9iR1/PfyCmUL1v3tTEcj4obaeVwFV+njxYaXm96KvPBGPjR/7WGC AoMgRVEDsgbMH4UYfUpE+fw2cSmUF5qtW0lcc0vLspq2C73yG/X3jUqzScubf9z68kPvRemN WQvgzAZf0Ix7enkbOg+FXcoFMcWY6U0NZC0LhWQl1kSiVhqsQrR3IaH1J7e1PqEWHfGe7zu4 ii/VfsZf3cOiNWDR7nfJIm/jK2iUYJPGkuUzTT81Mq1dI33tIq/ozkf0ZF2ZddDwIlFMgXtX 3z9TIMkwbDaKPA0x6JqUxM4EUm5/Su9k3XpGeQ/3pgPgjXJSxPt2BrxSkbK6RFiCIvqjX4XR ezbHToaug6HDANoegqSEv9Nddwf9tz0r5C0xMOBf6yoCmku+i1lvHy2XmsMavw60qGNfLRzW YE6DQtOH5pBFeILjwEYxYZDX4ohDlIuSegM/Sim06OBIvibtR453nYkQ6Ok8RjYU9pnvcDo7 f4Uzo2RDm7WMMJGRs4pgfiUOMIUBJGsTk0lU5NJRo1wbKEdSkozpjbMCiGnwXbAGOJq67AVS ayGkWUZIdz3EskxyiDfs78Ozlc/jlMZ9OGSHBUCVnYL3wiPVdLt0XH1fK8C52cFTZj0zGm8C deqrS8U5by88eyk37OVwBm6tPnArOnBr0cArMlE60Fy0XUbrlcq5pDT5FG2Sp5j0QoL5C6D1 sNkHv9PL2LQFkn/GpqdwH1LTRMMbNUGiRE3M/b1wLZJ5kKT3n6Lvo5Y8AOB+e1oD/cVpDSLf aRsLYx9pSQOGNCuS+YCkWa8p4HyXspGSOBmhq5mIMncPk/pz2khfbO2WBK1J9CWutjeDJWVd hNbJ9jmrmRFoBBSBRVcFuAuSNAgjmEaMUlsYZLE2xQ0KQITfYbFLMKsi0seOTbotxQuxM0qX QrNAWV1F0+U+2TCwybdgOsPUpucgqcu9onLvRFQJcHBgEs8mE41+NA/pc03GsJmslRdeKl3I 9TSYAcMQg0D4mQyB1nk5BELgVSGQSuPZRCN4cv+/uHu75V2M2Xyv3CZy1bB1U6B7sT/oXLzh vJGop8C7Sq370vtz0Z2X+eokILU5a4UMatpYiVowNSlcw2fMckX1SM6geZWJCpFJ0l0VDADU fSYCwa8YIQNhwdK9cM9Se03gZTAGRHR7mljQT+6gS/A3YRKs/cC9Q3ZcUW/WXq9z3yJ5dK9c vRvxi9a+Zi0z0FocxuKBGwsGxiv+TmJ8/rFR4BC6okkK+H3raY2Q0DJV6RkU1SxJQldKLpZb Dp+BcC/0CZkXjStaLMgZrDNdYM043JBh4Qrp4XCQT3YfRf/sRuyQpFgefZoMl/NCcrAhijLG hh7n5kZpXr5h8x0NBJcnDmPGfOJt3/Tlhz9Cd5iYDtZxshq0upPmnIPlQ+WbREYf5E2Zcn3r jLp8KYJYNpEJ2Ss3iUCND7bGmtqL+nw/imBmfOcbF22xu3pWi3T8sG6iRe/xnoH3VmvzDofH 9TBUacO6Gzz5MEQGMdpoduQBeR4n3QmpZzYXiqR02yMCoH04YziokTNTBFUgoRbInBFaya+T nB3QnIKXK2Ztn6Bm3oeJ+JplQreYOwu0qaySmxPGkmqLueViLV6a2nGPxOCAXPjk3qCvw0W9 vgy6lwhDtoCv9PVFTHdnRcQU4mLdXf1gGjoXF3pvCpt6cHJGZxzGqJ+1fty1o0KLjjOk/sCv vxABr9bbx/XPX597f28fltrHNCO8WX/cbc8KeN7ZylTQzici+KTAcYQwuKkiKugFvYxi9XnG TrZoWPCeQK/tmyP5KYgP2J1W48M/72q8e4daxfRFaCQuwvMlSJC3RULTzZE+rc9MbJjwZfF2 trxboLsyw8Yu+qb0rfyDvklvEN0gLgl4MA2/OCXB7XFJ+R2NjlEFb6ZrMu1UtiB4zDBbJFDy bmcwQCJ+6Y+Eu55dj6dXVh6C3AWViZhRMhMDZMurzii7fGcQjimjLENC2/mIE7SzewWCCC8l uIDuDjWNb34X6aC5QHQG/oS0BI593WQb9NZLXIh2hQWJVVJCBAoMdUlSA5X1ozqaNaddlhLN BqmiAlPliEI32AjT973IbWwsyX4wiSU/0J4tlH6V9BiYGgovHdiKAOBiyQ09vphUyZsvegAP ttvN03a12SgXvSc8e+VRyH+hdOXmhLGzkYqjDVyvWEYir/o8QTez9kmp+REpwf81TyvlaukY XcSaxv0VDSvbeJJUkRPcS687n05haQa35FdAocrECVszAuhNhNVufpYcCUvu8Y2cbqPu8mqt 1caPplf5x7rGCYAVlXHO5FCJj97YaR/d19iV+hGIeTvO0HYiQfJjdTR721+Lnq2v1J7TZYAM EiMMIG7T205+CecLdu/7C3ZX+IKdzF+wo7aCY9ciabgRfSjvOXze7CYphXc6Bn0p3fMmlppe K7qP9ne14jtjvMzd4JDtCKcQDxNJyH1pLXMyGGtIduRdddAkRPpSumdMomXczbiMOwuXced+ lnFnpWVcPuh3Q/sU8mLpky3vH+zcuABnm/eMs82fV8DZxYttoc+H6vsPq6z2NifLVF2z42nq QFau1NQRErG5ec/YTAt879i86gLvrLTAWQaKLnDSCPoC1e4HyBf1xuRzgsmqZoD/XT8Z1emK 1SNZCXIt8pl4qaX22WFvjge5RpbgHBCCxAkz8VyyntxZ8yJpfFyMiSMxRVizGGMmbBhp0tXL fcen5FNnALPB4GkV9KKBuAzdb8qJHblRkufW8cuzzw4wZDwChSscnm6WO9Ne6O2/8364oahU +UjjG2bGdr3cY2cpEhYZ2RLnw+ioYnpt4EtR3IgHFOm1xq/lUCnMo9qZdS/9ePtoHFfKjL5r 9h5OClb4g8PSucAqZiS7hT5mLsT6XFOKsraQFIt9UMduZ4jI63X6KG2Q4KiSGJL6KQ+ieEiS 3Dnq8AadW/HKhD46BhyTrPpTLO81n5EBdHYJQuTFpUCt1grYhbMkTsd+OEA7ATp0n/v+iAIU YDmw1Nic3b7Dy6CPf8/G1Mf84BofTr/R8uULppwYfDva4jCgK9LjYg6T9NGT/JrnsAq7vApj aixNiRh+R9S7R5ThWGWOwRdZENZn0+N0wPgmZCRKVzkiCTlpfiymEAHG8ogMKDUnrEgI1FU8 tDJEIrQW6URI6xsCrg9EC7wsyeI/la7EKXAY4mHHOIrz8TefTysvS8h3mtL+r6dkWa+kw791 LQ+ka8n9W9nyp1e2/FtV8adQVfxzytiZF/ufRcZ+UBHwDxXnHkwiy/3pRbLmv0Wyf4tk9yeS sZj155FglIDxoIIMVjkzIgy7z4z7jp/NKpnhQ/Ytm5EkEwOhnXk4DQPnwlF1Q1QuN5WyzYSx UJA1oRhVJ+3PsSKpXXJVw5W4enShDZW7NPszqRI21PSQKb8pSs4z2Y0ksCuqyvYWYy+p7dG1 W1ZLVQ+FmWF6wsQccpiNKpxTYWnOHOdtp2aO07XnEoWXnEp4n9PiiZJPciKgiISScyOqOXcc exijVArkhgLlOPEFejFjaDYBqXzCRIK5XOXbaWfa4T5AT3w8h6Y+qjcfSabmdeSZtZ2e1PK8 wfO1v33zw+DLm5QcceQQlVLiyqhTDoPOBaZp5EQRKP1Qw1K5Vf0kvrwmkT/WzcYOpdkMS1D0 xO2XejTOapjwRJg2FZK5uVPYA8qEQs8Mi9IHVJkcI497AGcPFmoE4nmXyysRM/DdcypnUCmL 2fS2zWmi2hf+LN/6AEwCZ3UuuKHWOBzLohigwFGYc8q2Q67iJGJNxmEYIF7jcN9NDiJTkNRT GdPssLzNd4AAPcAdFBBvdnZev6IrflGTzrlXKKirWEjhsd87wIEweyugRbTgqZOwx04E5Cb+ 0p60SxNqaQZr5cRYOVnxydxdcUqo2PNlge3VpbF0BpEfwpRcWkVTQIdPBdL52vTr5rsRl0+L 4I+YiXTOrNzSNFh2zqxMrVXWrEyNVdqsTI1V3qxMjXXirAytYxjipor6noJIj0w7OLEaj+zc NsfWdeAgU5ET2jg1dLdWwjAa8mFQbPf3QjH8hhVwzDTPgmSmdRYsM62zoJlpnQnPVPN0RIMW gmmrRDnC1go/qcu+W965kzFhoaAVotQpPAHJN2GmgasVsqqKxrnd4KsIEQjyZ38A0sVxJQno DrGoiVUqJ5wjaXGNvwkX98stqejHsDacu8GwySh0KplU3JqFGasaZuwuTHh6xw+fK9KZiljD X6TW1FkfM6djtK9QlZtazv6TJ0KYTjq0OyFrXRk/mO/awn9+3AUpRYVqqBxZe7E2O9hmc8c6 lCTy8uY2P76vtJE1JWShFNqY3BL4NE6jwaAKcajuyDj7lJG3Mw+Mubvb5Q+l2vtKZGw8REnD E/GCf2oYTJH21dk+ulVqwJ9myGyS+VopB529ff58j1nkzXdnE86keJfIci22gURBJ06Hlydm BaOmDypDUuVrECKxVO0KkiN3SxET4yLUZkSIIuGJ01FvLhSmuDB3VmlKCVPmwci/Pp1NHRFL FRFbVcRCAYt+Iffu3o0jb4m4dVfUoM+1pCMvXTZaVW67X2EK26oyDsLec1z4Ys4I38EK43+e PUN5JujfkoZLtA5SqlSibYzeCZelJ71A+mKNgKo/xAIYxyChiHQu0j0HyUovVrZpKyx+GcHv Aw6HIAxucUNi0DTSWMvrPSvYlTNNZTlaE6sHL7qsA9OSz52w2j+bMFG09Zh26Gek7U68rcX2 bROPKX/Mxl54G878YSTTPXyav7W1pQRTM1LCDjpDfXdk2JEPu9TGyK42WT7yTilO+27jLKkb +oTowno6jSNA50Q1dhP7ltjQ+sOE0tmK61D2VFSXwrYPgGB0YO9nyGIUUfU3DMLuHIOHSR6G NVBJwZgxPelS1wT2SWYlRhRufWrgcQndBf1YQX7aqJ/wbVmr1yruWtk8w04sx3uWPNFk/uAC lbZyiznOxQzVdiqj4NzUd2VQWvVT+6rOqkXPNHnSxYy5DKnWamtu+zBZhFsiCUgy8rUyZOtz tcZG/gEbgVIc6+QTRSeyKFY+tdpfTkrlNiXjX2cn10o1zptLfIhOoJ26pGJkdMRjJG0LjLr2 WGQBgpHIMSW+EjZYlfYEFxMTFdM6fcCKLY1ma/nX3m2i39PJrJJGyWiUmF+VV3AV4XaxySWI +jEQFV0is2oraLSVyaUTs9p/d3Ii6G8krEj+yIXzdtbe/YTFX+B0NO1Tv8VpH/us7/fEHPbQ HUuEBmh/UjmBU5p/YpTcB53u1XxSIHuzZJBQR7sJX14WJazI0dC/fPpzYn/rWZMYcHhGNv+F QCMC1OamK0BhceYF/GGiGMTSxkPmFoJBvgypMBLV3fH6aCgxKh5lsVrg/CcsGDrpiR+eNqwh gwbcFANFnzrJcXIdSIx8debBUrDpjUeW1EGRXGekWqr2jc2X7WtkVINnIy6k9HSGidmfkiVN DHN3K47kSTr4N8JxYmNU2uuRyIBN9t2eXodpB9jqEPP7zoFToWpNOjlkeHX+NCx4jx49SpL5 cCOUf1941UaTtfcMumhfwbhHIIqBC13+2EjW6O4lVEPC8Y5o1dexh4mi6BFMsB3COvbHefi1 sPluNG3DXgIdz1TF4X2lVmlWmwVN1w/Ho6czMi59w2wPIawc8HqbFx3y/ESjpWZ/SK8dzjn7 Vi75wtglz4dGFyavvzevxA72NcpIy7gxfiNSRGHnV4HsigQLgLuXwKIVwPT6ahWGlG6L9I09 rd3PtB5AlR9sRZbAzr4mrE9tCWVCWy76YlBRL6ng/ZO2AMIU3mpzRYocp12/KSE5CFFXSEfI Rs7OIt74euRPAbUn3jncDJKgiSQwgoPLjc4mUyVkqZFhYMu4yZppOkpEVttsgd/3/ifo9wM/ TKP9RJYfkPSb078JEjMQUsqfA2wYGlV5AQJFsPV9kDnTHJH1jjdEX4ULPwFSPH0drt+MrJ+U QsxO3TXw+0TKc3xJERn1JA8rp2kRb210WYYmKALzN2gvC04oQvmBKNWuvkvI3TxAU9mgR684 Yz0yluitQ+lTyHMb5Gs4WsOQ3cqbn6ut8of21tYL1CaxyKAGG0UyvNjV/fSEQh8m20PXBBoe rcvKrUmWX5bMwKG+JdYZ4fUF6BfO+O4rw4dPxwP4TPwMSeJietLyopMUUP5vnUFgSg1gMhUk KR3xDGl90c4hqvKe7I32PEm6VN95jrLzDbv86zxsmNtc5wUUpMBu+6qbOsQeVRGEt2+ElyAM DdGJAyuXTCnNTpF8paB7zmII2MUm722+40RVeEMXsNFbNQYaGudTgMxBBHo/qY+cQWmDa891 E+iEh4XofW1RfLpvvVy2zDvmB+AhsQPkwa5MD4uR3nLvS90bzU/Bf2k2NqdAqRFpXaM5bbHL pjqIzg+n8mlRPkFM3sJqYFrTGxqF6AKSNmlTH/SwWVSHrGo8Ilt99uplLke5zCVbOHIgHjyZ jmfj7niglMledYLJRvypJKlWj7GcRdjEr9z31Bdtvhv4o9V1zHbONi//+IvIDkmiNS+/5ImN y6N/CfqjBG/ZjTSPYYFnebrSXWxG0clFrcAF1g+TetjzR+ScmJRZk7NqMhEYjoec+R+7nXRu z33q8hSbhPDOGyMxGGE+ysHkpw3R8y6ddC7LdNPF/yWLGfHhrtVxSQ/OjpxZMMPByalUlxX9 yaOZ90GaNHceOx0Yr3KjnBfCGaBDqjo13c5Ia9hhwaXlgSqygqQGXiAtmY25kZBlBUB6SDZO AYVb1SMXDbqDrvGwnfvsYW10/hSohG5bIDhOFWX3kYIBYyM+kFNLiR93kFAFfZ49UzLUpEMu opHbnhJvhUOMtpp6J62zzZBrd8LHv9ouUv/ueHLriE54r4/8awUDrw0iGnh9MtE/92fXPlwi am3hOrwIRp0BTIJGx6Ou3CcRkvUYpvNqm6/b7Zvt7S2CoQO4xnRpDL7hZs4Hs1vo2evhpGTR PnxWXTsdngsCED7NkJm3Xrl9XKm1K60PlQaKVyfVGieKV4afvKJDQJJQ2oFxZmP9sJjWv+DW FbnLedHWD/F4cQgjFtxOnIHhcWnhVJ5Eyk2rcrCe+7CPPZsbG5F51lQfoxu4yCDCMRutpI3V CxrCB/nTb9h1Oh5yu/GIc+VhFlKeg6q5xahOF2TPRkmX9Wl92bR4GNo8vKfwalCLZicd26PX 8efcvieJGPkGS6JuqLKxzYVnJ6dARbAK2HByEl5YW24oyeOCVSNALfWRYTYZU4cd1tz3OrOO phHARnwLOo7fMKpI9Ek5PCnpjIMf8bgPvN2tXaQPIaV8bc/GcPWH5GUOotAVNQmhzUtea9jX 3a1XXF4G+RkgVVjEAOYCKHzh5wuyyR0Mt5xMkBfmNVa3N2oD+EovuD0nxntSCu2o+fBrjZ74 vQVpko8VMXGaYQTeaem9OK5IHwfR5dlpudqGpWm36qwIKfBuwvZ+OgQ4x+NrT038x92Cl9df Y2chjXT6EFxcJnfi1GW69eTkYN4n5smwJ9rOpScbTNookPui6aiUPzbPTtofJA5QsUKU6xZH fF1wl+KXcrt+dIT+LtVTqpr3Veau7+a8gYGnX2rvHWJ1PfLTwZWKKV4aGEEqnjyJDZJKcQrx 4q9vHSg5Yx8FB6zu16bP24taWhObw+ys5qiycZlAvW+LFuRDpXRYaVAd6oTekUe0bFgT4CVZ wnhWlFCWCwuyPfn0w2ZZqZI6gykAuEV9Znc+IK0d55O1+jZnnkt00WjE8/KeRxhbeMBoC+ud vmneT6qR/lJ4yiDxt3LTe+PFmsDySxP4rdwsRL/x8zT7PCnCI7ptv/G+1T/XvN/ot2brCH6j icARoCefPXmHAXu/pcSV2T3QQU3aqjAwehfh9pWQYhcLTcSq6OzwN8IyM9P7m2hkks4FC8xV UvZuhVFovxAFEwjZEocxRFaP7jWWreCbbrqXFxZX4JRkoHtMhT7npY+9JE/UkhQsVp0NzK8N R8+V3ove39vlZgMYmGaDHc1ILZazeQaKjpr6A78TKu3EgLgTYkuvzinuKkBSh7l5B7eKr32q vmttridVBHkUDfU2zFxEeWrr1XCnSLfmar0fWLfWfL+Gds2L/OTx5gZIeKHDQX+B9CKmA0ft b+EPVM39WyFkKbz/yVVCjk7I/uMonDl/H9Pf+Pmo4inPp1NYgou4LidN6eOp55Z2CCUstB+1 Z7ln8CF9BpikWUpWQv2BCp68ZQvTS28MYt7znYL3zksiakzPMipmlg7jLRnnn1p1A4SQlTdw hikLMR5zo8hhDSbqupN1N0gpPFtTElGUkHypGPx0IROPgmqjHh27j2xNJkrumvtTzgDqkj0R 4ZBNFLiHXCH2ko5KwVBokHo2w0mn668ppi0V0lYX0RAVcZ7ADRlcpDcJYtrvIaeZZT0cS2L/ D5+1DOxj9BOalbXpGEVgtKLCf/BeZe1T+JNnVEVZxbpk7tTwpPDb50P4PXHJ9mwF8Gd08fvm K6GdtGYTstqTwN6dSFyXZ5V55p5Ws3mPlA+I+ph3ySrxpHmHW7gWuV8eZMMgRO5gd4usl3RC /hUE1d9WlFR/W0FUzSqrihj6bHUhdNC5JyF0I7sImi6BRhvcr/yZWyrpKalOxDlL6OOZpZ0s TddX0ANa5Pv5ftqZNcTmYDq+xsDlbz77JOItJYSc4u9JA+hjzXfW4A8dqu5ZVJ38FhUrxdih /3rrLb76TVPl2SgcFMB5ktyV+v2iun116NC1rzGR6RHVp8IgBI4iRYICHzi91QRjdcVhzpMp wq6gajXxaXvc76NNJfYSLRT6aeKNs96Vs6JucKFyUHn48pre9VbKGdeejPfScrXJZ/uGipjD st1F9k2keq51F9FlNI1cRmLZynqfLL9QVrpRMl0pkYiWDJcKGXKW60wTaR7snb6XLMzCA6sP KvqGaBpkY07ekBcUSPb3lxAVr+BxGrwUdVnKx5LmzNWjuedWF29eAiLWSevimA1frLD8TERg yY0fGUKMbMLSa4ZeywYJ10j6PRK9SNyR7k1/yArBJKXhPasHNxKMbKqGmFYJLDLDaRF9DQF0 gVrw3Zpawe8PpQSMSfNUx2xAyRFsDZqYS9er6CoAwzjEjqtX9FiFd4sgiEZQgCFJxGIvB8xg p+x+RMVHrtSjWRFzWKE0rV0XlNneErUp7ZG8L8KlMdb+bs36UetzqVEhvRfg4oACuc45Lxb5 PMAVg/iPU5rORyOuHkul3jsIRCWjG9yyXwx9Fd4u6I8g7uEASiCOxqT142uGnMVJcZiHj9Wq hELR1iliVOQIYVlLM1apnNQhpA/T39SKualz7KwqC0c+hZy1Dv3jWYNubx97gmeq9hZXDi2q +GYbla2qb0q9qLSLUcUgfM0sGHVYT4z6RdYozjnW7NeNFhUw1a5ikQGJfXH9AmhMLpV6jVUI oyVPn8L5fKq8WlR1VslTK0SLuhgSpj0c3VFEQajVg3ZNW2hMtnQ2cmtv92spixgjVjRRSxVE fu/X8lQ8aaiSLRb7A4TZ8/wbzGcLR0yuaURC5HYEBZlYE5pRZ5iyuqawpbTqjG51mxc6W61E PBmuIHJ/aUnbpfGYdNZy1sJZswuSSiGbdAxlIqSIkvZaHUUhxFwdGvYNiYVXky8c+kBoJGGf +FDxqZKe+mCZM6VuNT0K0hPWu+MWRc/6aHxd2DKcYOKOWRe1+Hxfd6588fnWIcxxJeVX28dG Xf64ogmX5q+ZRl9+R601w+/xadr8n7pbtOsIo7tJQTgfzWCelK94hC8pslztlnECI79qkMup nCVuBtZdnip8kbPKPTWFAS7+UZIQaKRAV54qeG/fGhHxx909u99vtvToSG/EaIE8SfOPS5Ta OMAioeLSUCqzHEhS5MT4jgP7SdIHBsR8PGpUKu3mx4N2qfZz3gLMmcsISdU1yNEoSQhASTVi DOiTfe//FK+aS1FUeIpsKo8tc7rQxw05ZUqMptOk5oU2UVpUehznRx7OAGqS+ij7J9F3KaZN R5zmzb7oFrORielBgGEcos2zEHRUx1GSeN9RxFyxBD6Me8Lri73DqSC0JTGgDPSGKlEImUpJ p3vBvb2Z3JMCFNDVP+gMyACHHJj4dsU/maJapIK6voBpHch3b5MxIYwHCEj+CMeTlCqAGxYP oVBl+CiUaKVweEyyhryWrjarkuM0+BE2xaRzsiPRsjIoDWP/bFgcyoz6WByJXZtWOAflumFK 3sviE+eSlPUkxVbYkIPbSDGCycVstbMpvPUY1+I4oJLx7Euaf8TLYw6hWM7kW4ncnMPFeEWi SbqYtGSKfN7NGXzAMKLoB9n+DlFHB/u0Logo1edcBc2gzwG6Bqv+xtkYu5A/A/Ivo2RMTvJO kFhomGxHQUMuBRhGlkM0TnFbyhBiN+7aftzUyykG8bF9UK8fe7HNXvlECLKvcjBUoWQrfOPX BMeA8OIA0SrKj/NCq5vsXGUCarDJv7EgRgRv7J1XuZyo8zldBxoN9U01YFuEYdZdbn0CfwQg JtlsewfpoKw5s+1q4nBFEnq0w6tzVdUWrmMswF703h+dtkut+km1rD2JTD/bKTuDaTolND3H eQxLjKKGaMtkxUT9CLMaEs+oubtGjLuT9IYqF4htXm/Y5vVYT+ohVmydiEgox9V5WxyyzbcX vV1O0ogbPQBy6FVPVXA2cg8YbHp1bmLVvDF0CdlH22xCbsIV6vV8VPFgJTYlPef2iqNpsOkl gYCSykyMViqPm9rXvdVN3hGLt6yDZfJOsHg7jajSdsTo7c4KyMIuPlVc5VGjfmJbvBvrWLwb q1gfZGEd44M63uptI0H7zz/sJOlpW1r8qdLfuk+1+ls/1YY8pWEzGSfsG+nQkdsf6l5q+JQj hrYJETd+LVFQ7yp30xEFtogMnAzkRkJKWzqKk/Vtks9LqXcHt9Yho+jLAeFgkf5AVQISQ+Ir FTE0/shFDsPgKJjR2AMm0k8PzvSSmLTI4tzrvVTMfi8l3UqJwxviI6ohIgR4NIrq5tC3xiUe mN71eNqLtofzV4g1H8Ch1K1/ve+L7o8klkm0R5YhkcSoJU2lKOsTkzvTEmFpo4f64QRYk1jH qpWmiQR8RSZBNVIGzQFgZSjBPCjXncGVK9NGNctUdsIf9ULM7gdQtVKbVW8eK/VYQo1SgURR zUoe5CSJLOaWuawiF5Bw8CO91IfYVECy3yJ7DMyOXSyEE8D3Amb4gWez3xKp46Azc0zNQU0Z uOfqOhQtMIplyrG0WK+cRKPiIyqG+XI8oBDEvnIwj3Wv+dcMYRHf3ackoZNbB5TUOyDLhaI9 xMvNgGcWkkPpMOjje7GO1YndFVfjBHhLXkVMlQsTlGnNZEqKl4XZwKVHOKgSBMEiQx9Z1Vjt hSXFF3KJ0nguOQmpzF4zvTYx1Q/3DERsXyd3kcjD2nxIJsHI46PxFD+fFoTRMlcND7ru3yfm b8+D150ereWex5OGv81yGzxjf1U4cdaQ5M6eK4fz4U7i093Y09btxFeJfIAuhfMBT5YkKCNC bWxMbzi3yBsqvYcFdxz7hDJPILXuk1lNuxt5abcUmW1RyvC8pAvIe6tuHaKDp/6U1A26Qy92 kxVdWM443LaYPho7NW2INQPI2xGaxzHCmLGr509hAUZ0AsdiDkQ7DTd+P9ZFfyiC2T7o5/5F IBZHjqxHRRt3O2WtOsj6/htjpRoGWNjl3LctFfrkhcy1iHmHwZBphV1ggIUcj3sejD2FeQcU EAqDkN8GDI8z3uJOLfStwU0keHodVPCuGE6lcV2csZxP512gqI0IT4XPdTBvyCA4MlWZ8VCP wrBJoW1ZoFwuYG9D7BBcZyCQ4aPRwWg+1c5LScaVR7a5KgkGLh76CVmwyDZolfSch3OghhI8 ztFKsAi66Wcf3SiezrTrFVvm9LZytlxuHk1Mr/QuMWtRNF6H08zejjBv+7hXHfXHW7VzTKfK lZnoqKAlgBftwp9Z1JupCF71spiSD9Ii3ehS6SzewUFZGQHtZu8iHKEs7cUYifdNmzUUthsR j4gEAVk3nIMyK0S3LO96NqOhhLYv8fmSUcl9TDkudUzJOScfnLIM50gBZKgKcqi0kJrU6ncW 8Y1+HoOWRR8G4RBzeiL4v/R8TB7sfTlptI+a5Lfa/FA9aqmd3Xmtm7xPa/Jqw8q8tTTtGa9O dOse2QK/+TSQ+KMz005qWYIsIrqsRjTKIpd/HF5hpNVR4gLlf5i/+GFe2FI6LQcrFYSs05Zo jThesF/cBucTW3V5orvyL7s8jNJYAKlx4yGYeWhO6iqoh7wO6pfMfJ6o6RyUmSbvbQgPlNLu xG2nmKNIa/qevHQp1X5uVxoNoBPyYPe4/em4VCsYSLbLXtIk32ec5Pulk8wntZcZqlvpN3Ex R41hQmvAlfpHcbgoaOq2LF3RtiiSGy7LDteA4NYPaDlk+emHnsIrG6s8owtW6uNMI9Z0ICa7 Utl+TOEba7AkPgyHwkSNOitGeFH0HjduHhf2ciYTY9QfpQXH6lPpmBbUfkDluMyGFHTNZZqp vdYZkYcAaCdR1uGoyFUlGXIdBrpctP8X3/qrB6vF6IQiExU1iCuSFVXUKhoHqMNjWao3VBG0 cYPf+0aqg1IDeV/09HJwKqtcVM3pcCpF0towhIi6p+i5uiGBJunzfOt+ZsYQawCjMKLEv0sq ijm51QlNpn5v3lUmbbSlzXzhHAUbbPr9Fhe1XD/9ud36AMv2oX58qEN98iIhO/Ydq/PzXce8 Q1tO9hzH0Qmm3LTm2wOGomt0rdpkI5U5MIKQeyk+Ed1lUCAncwgyY/pbuYljXuEJk3FFvcME v/q5NXtukewh00j3kGEHmRQPmYbrIUOnthu0e8NOG+s2tzFwf+C3gfFpdyfzxBAMDDLH9qgU bc8KET8abhC/zOhxotkD3vmzyzauWhuWD6MTzHIgUrJxheE49EyKOKd9ANfKTPuGLJ+R/iUL PuZ+T5liYUUVtBHjdzQOw8kZdKYXviIcyJp/PLAxmBmDIqVPkk7IL2OrXgB0ByvUa7P4TIIv FK7/Lrj4ItUzTZWF0w5dvNEJuxvdSS/ZBJeznLsiZjjOpGtELaDKlruWfWqTjywKKklph+EV 6mdg9Uaz8WWYf5bPE6F8Vnhi8PyXnd2vdl1PDKLAWgVf2ipYR3G5DAvrUL7e1q6CpCzaH/g7 r9CUSWe4YYLsQm09FJ6RtEhO80h7YDh3XhWi3Rz1IGJDMIIjxF+Vd1VSBcUL5aJvqFqM/u7C L6+/yuoLTpNSww/hdqsqWReLFpMHRRGlPxZ6Q6fk5yPVkzk2ekU9fhIzAaA6Hksfs5sp1+ud l15++8YvqM60VfGraNNzvps5iBslK+deqEF5QCzaTWFZ/f5g3Om5s1Rj5HgBrKAsE5OFdVF4 uZ14oRfxb4sMZaDTJwB3hUih9tDn4my08+aZjnZaIQm35nO5BzaFU4NoqUUppYTEQiJX5fC9 P1OGBAogUnmec5jq2ToCL7/q5zT3okfTTfVrUN+qBttXvZsfy03iHs+abZj+UaP0/qRSa1ks +rIuZdyK+sesPcg6tVoXivTiLmbZEjBDv9EYclarVcrASpYaP6tV+C7/JYRZuiR6tsAi1xsr T3ilXlW7EwURr9UR8Xydjp61tnCEPnz2dAQ1M/jqzGSU/5drAAxzX26UeZAtOboWU1/QCJwk wOcihz8jYhjSoTHiu9JqQS8lbSk/AWQO2L9VFkF8gC3NBRNbfk1vlTcQqcJ0bN4SapYzwhYB YQjvDIsvHD4PtFxGze0U848/yRqKcYZrFlFtH96TVr1cP97TcuJiJcb+vv7dCh9UAE8blfZx vf6xhIHpzNlpQlSM8Yo4UtF7wgYm+EUZlXTCA/XAiKJKll2sQdGTPLEnqWeZOkPaW5vQ8tSE 2PJ0cWSYqyymynbCajW1wIkrrM9Xlj37bOXSpZxE8wn7PYuRmqPS2D3aFDqSqF5j3YvVTtOX UlIxA+uiZsSjcGOTqElh/zLFCH7AGX2A8Gg3h5WDs/fUN0nRYeeus332UBFUblVazfZh5bj6 qdKQarW8jI6ok3jvbRhq0OOYygWOg3tW64nJ1YGi1wxu7DYFAOaNeLLQC1FoFselTG+omzxb 7LyIgcbQwaloICTKZXGQQjq6lvvSyh5qiuuEalifQLNRFCrgig+IKcqI7UpfKgex2+KOqiEv /7ih5qkN7sRDHU6/kRupemgQxinOFZNJSNWrIT1ykg2bIcT26vHrvehLze87zgGRRlLmD52E jMUd20idtgn+ezqbkvFF+RJQg6E/7E5u8/kuSE/PCnl7VodWbliU3FUTIz6Yl+63K4RyPETY PeQnm9N33jOFI39ERdVWrVuXW1x/bkPzEHyxlMofK1gZolwBQnCoXltV5dQOE9dCID09yT1r iqtWlIsyGL/zpL9v3Ofh/rs6NN/1bbGYHmH5p1DZG6pHR1SWstose795+Ffp+Pjk7LhVFW2x vlzUTfgk+SIUdnTBJfmvSLXT6alFTJOoJbOC8AQLsYbdDjtXkN/Bl0NtziU/Ff0AxH5/OJnd YhQoJ5EHJgIxviPMwgKLPPu7UMgtNYdpiecdsR26kJqxj1kVMd85FTEl3hYr3pVGPSop37iJ sF3iZa+8ADY0h/9mgxVew7G2Mpgbb7XyFSTiSBW87iUgyszYaIrCw78BWZ/tBA6JVKmJFije NtbU/GXS+y0K0kT0cfV5adq8FHWsG45Zbfw9bzkDRP3h9a2XZMjiGucLfJEcD1wlyhGCKZd2 y0/0AZ3ZI8gIK0Sheapmj7JqqcI9HJ9dlPKRWZ1V2bdUwVSwuDYQQ9JVdyUdAzXAQ45e9WoS FM1sRQ2mOKQnJzmInro1Uhygo5w5p+JVCoKFyjFgO6XmsdxrQerg6DQoFtMFaNi4oUsOsfUX Q0Cfc24UJBQqOwrcL/g7ejiXj9tHKgwvuncPjSatG3ZaFgzhndOpQNDx2EWTlXBDoN04cAQD KLJUjZMRCxJ2n+Z/540vxjZeTy2y89RtGowLPAz8Ng3gDsJKGOPpsDOQT0nHEfRYbyUiyS8I N4IqiejBe/bQmKEDsuV6ohotZNCyktBkitF0M9AgMKpwFgnQtKFScQmJ71StsPSYUtdjeb4J ZRwgd8fEbCnZccgNQM6UhdkKZXEjLC238puoK7sbL5KQEGU+naILtOtSnhiKHAuJVLmOkhxh 9/eT/G7t9EdW/PCK0c2LXIHhNXBZv24o2dPcs5b0iVf3g1oVcwuTQIjMeEeLYZz3dXmMXDKX wYnDIkEyT3SUzJ68TWIv0jmU756JOO/hSicGDRUWRxMlbuad4sttmvJQgTh24eklhGv1GpU2 5dK9F5Mu3WxV2kWhfHjnqvqllq+5qCtJFFEwe0FIhVz1yDjg+HpEmXowMNqpe07uz3Q3U9Yt orHhTFJXUd3s81s9r1gekFXu5nXo6rKkU8BOTCJkNVqTMBNdpRCJYG+VVA/L8p0vqTYVqzHf cgiyVWE+LeeLIgop2Wm/Z8hAv3YyPZv/eNBTzHXGm/7spNMl6r5JnqtO/k9gx1RMZkaOVOqG Wx054YnkOhFETMr+kL0CeKxGt/mIfGpR7iKfmGcTrM6tynN7zxbW1zYnKlJlWwWQwc7hV+ae dfhanaTgeW5lNYPKaJB/HNklEgTRFeN6a2tLmTWDfl6UTZyij6opW/WONysHZ82fqdY9q37p I+Ef8soq0lZtvgs7bXIAo5fkrjXwRwWa/WpKWUuhE6ty3bzCz6jDNk+Dnig+Hcad1xn+qTGb gBwHpqguHR42nhUiE8cdguftT9VG66x0TH9UmpT0Wkyly8dzDVt3GRNXasHJX6AdNrUEdalp a88fUAaRkRo3J5gWeJO8sZQoMIRHqx17uyddiCN94in6Xv6g9E9wwY4Rkydwpwdhl8pDY78i XqPD+QAOOCbLJVCs79CFarC/aSF0xg8p3SQF3ie8ZPLzDVgvvMLp5p9i8YkB+aCim9NlJ7y0 ooQjqZB1WNe9UC6iRc7ap1Mum2DlKFh1tmfnBjD0CHF02G0PgnCGMbHd4wDzvnKQYqB+EbNR lFKZK/mulEpwySFUnpT5XUhuczFCm0xHdpCOGOtX5ACbo281MTQljelYcDhxEjRNMWJ4lv0i U8aatCWDNRMwZ/WzJqG6dlRhunVqDkf5sjO6SCJg8pkqLw5CbMPIlfbxcdnKspv4FdrucsfP UHDu/RsAMDpi7DnJgu8BLnrJWHM86RLLtQACOUHfaY1MeMdJmYJCA5+iOrzHRT4FcHQpiJQX DxlQPsKAwOr9gE50zuFxnb7E3aL3s+opv22+w8BRsYqpb4Z/l6xZ5CbUwHrDQG7D7UzlhCLL clIuqaiMH7Z3b96k/aNjLWID/7L9Ne3NTuqb3dQ3P6a+eZn65q9fVVSRWdGzCXBQCxBRJYJa g0WIZN1wie0Dcwh8vk5mc+EQiMVvnZFoOeI6bVR7Iju34CbhoDy0CigVuMb3NChlk8sHfRBd +8GFN4Q53NxgZNQ3NM5+KWyp8tnYlTJNX1wQsA5l+B314AJHELo4txqiSPeeKl3H3AjFI+FN gil97llI0Wu4SEbBxhiBMJvjrR+99K2/6/g5cU4gUfpQIrhOCuGppBB3ve0NXiSJJVmu+4hg xa4EvALeW+/V6wJFoskDMgn/59nJQb0Nu1hwMstvVqq1T6XjPU6GH/Rj9uRH+9qg3Dirpfe1 Sk1XS+/bzbNT1JNYrMhh0LnAQ8csBzIk1LBUblU/WQXKddsjOM/l2XQgzi6cEI4JsRp/hxLA hTO0rwPjOUeK0fNHt5R9mstzU+Y9xF1ypXFKJ8QH0uMIffpuqmHzauNq7gum4U4odHI2S/sq 7GBeUsNCfdU7KAVPpTOBfbfz1+1t9nxn8G/3zROr6dlkf3/H2UJdETSay01N1HvOSYn5wnO+ 4A54DCBwXVV8pTp+TiGhU8mAj9sBMg6RovmU/XklkzyeBOVNgdtE/c5vRWfIqYJujbE2lAoR bLv6cdc1Xh1st6snzY9yu64qfKtZ18azoH/roWuMJCOCGbDQ1eHimUZPyrMRzzH858dduGJh hSk4132+g88BZzcsxx+JYgCJNTyiNCYo73uy62keootcoLTDT7NVPy16lq9T0iR39tYF57CV 6/Tf0NnnS31Ou600zb4nEA+DcILR6P4Uy8LTfuBFQ3Jl53w8n+nq8kprzbu0+c5zcQ0LPcw6 V743GXS6GIJDKBQbJMp+EFbE1KLRLbMUo3GMQ0LzRLSpyMv8Enz9hQpCVuvt4/rnr1upxSlZ MYUfFs2pHnAckrWCh/7El0wxI5VFOcCc55ovYKYAxXUVXjSzCtgSkMYXbS9QCUXOfZPaz1Rm 0bcKEyj4cAw3pNNDVVefeWch+uWHockhGqqXL/i/q6zqHU+LzmLSUDuwZWUzxlOQlPZnU5wF FWD37QvvJfOw5hTgMDjTINHr29w4abNInIQqk07RoIsmgg1il9t9D7WzbcbiC1J+NSMnYQLF a7L7QWeIwpaTXfbPjBk797zHO/ezVSshhbtRpFIHDvTQhwWbJVM8ISr+CDV+L8R4ZzR6iufH jTKiQLiAPrx4wWP8JxCccUnJCZanLflemroaM85E+uiRBAraO4zLdEahrvuGqz2u1j7uRdHw jsixYNCTs2M1ZGQzF3RqVA6dTkzAcS9oJxgVI9KvYryrddzP5lV1tyuNl7elyy1xk+NtT0fD gAEvb4sCe9a2uK5Z27aCoT/NNF+NobOwC0wkcg1v6O/mRBVyItma2TWNTlQRqN/BcDzMyEfC zQ78GsyEIXjvz8o224AT4fGy7RKKR5m3STfOsk+6cZaN0o2z7JRunGWrdOMse8WN9V6xsx07 QeOa2ymGQ8qbZVUMzUj+rZyfNI8nLikt6hiJPeUDbTtcR1pziF7EKTveZsMqUlMhCmn8KCwL /mRMeLkhZWQQgU7hEXB7CUsWuDNdPonc9z2hHT/7wJ9dH1eSwO7wZh0GQ54oCt+M2dV+jQJM GMNz0go54UHn1jRr+uTaEcpB2NA8aWc6ixX6IekUpwiCbsG4EyTuIQruwTva5M1Ni3Vm1V4+ O8NsJAnmYWVHqkZc5CR4mYRGe6qfOgPMeNcJaYjUjh8+V6QzukLiX5RYnXcnk1RUarRssSij UJIkqpJEJKXLRKi2Yg5YOPC9PGwL2voKLCvZ9RbXvioTJEunbVz6NKJwxnWqtFC30lwm0NpY eA+jRneHrAukpLIVMsL5JU3HNDNzWnfs7+sI3REg3zcyotiaqnYh9p9JtzOj+nviO9abBsjc USkjzPwezrwrVCwPvN2tv3p5+Gfrb9sFKstIIELfH8LppeTJVghsqFIrTqZjOOlDvNV1RmuT AWmDa4iRlpCrO4PI8XT7KWm9odkltP5ffzrmZJ7YTPma6ZSNPIvbcAaD4HkKOZsvsqggyAyD 0RwDo/OPYM5cugfzdo68DkxhMutQJSWAQFDK7OE1uPUCnTeV7kPsKn5z/k2nS8lAQ0yEQ1Wc glB9JUEJQnYGCHCCmJodjQDj6ZWUlcQ+uJRByCms6NttXQABGbHWTowF7HonuahZRRDqElJO 02tKO0YgYC+gydDvwWKOZBNDGHqXyM3u1suiWlypq20tMQGQ5dLpsUmBo7dO5qE83Yez+SbO YIsplXyX1l9qm45RqT+018esM+PqpzQTbR/hbE4eWS8A77vZPL8Eiu7FebkMKY+Ap7CEsRSu plsaq2oRkiaZXSKehmYUXYhryza5iIEFhpPcVHjVw8c+09+92Nvibt5hKvK8CYxQmaPXABJy vE0adE/yWpHGXxXy7I+5RD022zyUnGYGUolSmSooHQ1DQ7JWCMurYL5dDKagpdrSSdJ0UHy9 dmQAorCQBSAwgleikNxyXObRagU/VOHAi//gh+LZg5MwgeEsn9IVMo7f1S+FECDRec7aGthI vhis3Uq1CKnPM0xHimWoVm8p49CTJ7HExDFD1b5rqLIyJ6ouKLpXToCXyFtzxzyStM7jfj4B BfFTVf/VDAp6VLbFRGA3q/9VYUYEpwKiJ88mydHOnusTrgllWZWi81vtzk6z2hnLlwKuzxBt tpkTQIaHwO/suU3xdMSa4kNqKsYqoi9b05s2h92GdnEgpyNquAbIQfi98oyzhB3Jz54Da7YI Vkdm27qpXy0GA1M6p8wn6ROqd2cwij2t2EzSQFjzICA0G2Sg7LNhLI5v97UqLXoK3CmTET19 ztURZfEM45+uwGkGc9Vx8vnUkTZjwGIoxavRuGmNx8dA0aBXwZmgsK6WMZnllFPApa3Ty1uV aQ7P2Ief20TBQWKhlh8+N+AuC/GyfevtkC9tysckPt6Mz5KScYa0Y9ENT90As+NNygtYRv0A TmopGkoqpgWIWBsfzPtLT8UyOK0scIyDaPonNm5OVKtlp6yrVuGOS8Yh8/6M69TpzXvDFd6c 5eRQ8+Ub1bhpzEezpbszhrOfBdhR0B+jM3WffA2WAO1Ou5lgdhNOcgQU6eYzAYOGAR29JQDh Q+79g4cB1hLIAvaEWi7DAHMSIwgAL4C3ns4SB9uOnZluZzoNsmxw66bMTZcew2zr16L1O8Mi INP5EhoBQC9Blpyd+53Zfc70GiS08XXyOilBTHgL6lOwPexYbnhYSaw67s6w9G+1vqnrHpkI tVUKWgXkch8QPCq/Ec6pzrHIzygKqdg1dD2gEiYYuhrOz00dZ8wY4nd6VKX8ehrMlAIOdR2b 8oDkN4CJkhDIvt5J9YCFDCPR5OehjzmcuXbFbfhxPBr5QKBJrBhRxeXxICzcs5cdreUiDzt5 FfSn/j+8Z9N/sM9dd9hLcrhzfOvQZx9/P/GHVOBCIFFWZP8bClOcZoajTqHr+0q7Wi+3jnM0 qUiFI+ArPMp8T955wlvznw5v0SAJdDvSWyeIUgAw9s2f6sdGDiBMfx55cGfHP0bZdZ3+XB9/ 8tajrNQY3tkGtJnmn9AARW/6j813sFUcl2R9hFraQtQJ8Kh0dtwSBWF4Hcy6l3ncW2zUxaQr KFlhR9TEAtK+iT4+bVT0G+LSHnU7E9SC5culU8Km0uFJFaUyPeRppXECnGcE0HsLSuzrIjJm 0aPP3aLsW5zRkP6G7Xwr3xzpUfjJaeW98VLaFSKehnqB2G1ZRDre0ZPgnJh1NR0AXKSTsWd9 xWzM32DPOCY0R74Bh/nJs2dLpW8WTs203vekzmxsDi52KJxJx5KUoVRt7+gG1hQOmLm89fIp Cw1nzD6DakR9IjWMiCtGLnpmlwBWkyYHBTi3KC7khSYBkKshOTrlVT5DzMr/sdKoVRIWoVY/ qZwYeFEsFaAucnru5zEVs9aTE/KQdbp9IR+rHFyYlClFwYhJdYKeQI37xOSfL8DKb6885gKM 1YOoFNMrArfR02zMnRE02/D6T0TQKywWojaLK0mjTn40n9g3KFlvBdEX67PcU4AtViWF/z40 dzg0vaBzocBPrLx1nEgD3+hv/9F7Fr3XSdlKKouidzAPiW87ZIU+YYA2+bNlqzvuacMWmklo z9lJud/pYm0DTBXb8frwbhCMfHJC72JYKAERL2JxsMQE6VtWdbwR+qmwbaRnmFVddllAcC8V uKmadQaY7icIPZ2EPvSxZOXMNBEA4eV4PsA0DxyeubWlXBWeSZKTH3c9DFzi4+FJsaGkl4Az O9hgQuzK+TzcfMeepQs67GKH08409HmVa+fTI8CF5mA8q4HAmmdYIfzZpnLyS2/SteiSjTN/ BGEy45u/1yRNksBXHJwQiBq5flqrt5BWCXcnghu8Ltj2M+ZMH15iA2bJLkL83p/BkyKmUID/ bmKmqlOsRUN/sUAmpS0ymtM6vfAFCltiV9QC1hzrcXiogffypyJ91biICII56YxgDCp4XVXH uKDzlfTIkt3Rch6JhQhVZTiZTMffAjSikn0bXmNPnj6KmFwJPZRq62KNE4u4BEyjSVVCtHGy 6Ac5gTmoQGyaSllX0ZV0LthuU4/NpkNYAq7hLuZ1Wb5QJW3hIu+hpzOpOIRYFwhSKE/zR8s2 9teIkiR9KiMvG61ojrTcXS7vnCRyIuccER6L2fKjOVId2USwnyk9yWuv7Hck6mGILWVrwUBe MebPXkwI2zhRS6JZLcmo5kaR31kkxDORbGKLCX1Yi5gs5YTZSAJWDMoW4Y4WIy7dGelruV0q Lo2xcYp8mh37VJqo4AiNPCAc/uaDjhkd8L5HsyiwerRm4OraWKVpnmAK+Vagi4dCK2HK8iRN 7jl3AKLiA14CURdb8qPo9CLhOsEIqWEnsyKPqD76pWxalCIZHtElpYUbTzhCUFNQ0fipXJDI uiVRusRsnzHvYcvRIZYkKoGoGQ0g0SJE2B93KReDZI0C9tCfTiXISagQ1fQuzWfjpm+KfnuH 8wn9TRqvYHTFftH6h+xkx83TSuWwXTpr1YnGYTsgcj4XpceeCLbmX9hKNYxgYD+DDrwc+ViZ GkQDkDApa6aX39FZKGEOA/+m3JnYvbel9/b++RgEhp19VHQWd/cvO4O+6qijMSMTPjquf+Yc BM2fT9r1RrsB8gQVG8IOov9VQE6aFN7tRYGcNCU9gvrsIRb3m74IBx2VfsXzVN1zWstqCLDR vnhIpXJ7ChJnCDet9Dqrdomt1MdpYImtGuOBNVzaiPiFaa1ePNNJ3q7Hpmh96MmmbrGEo/Zo C5MpI2IiT+CcHfIiUt3Z/0zlXdYVrc9Vnip0PUNBlw6JQYDNd7nfcrjh8B/ccPgPbnjuN2wm E8rBQ/U/fLx51x8EUu/3ARwuTTAY+BcdHPmIJ/BBT+B+RhrxQPg1B/Sl8gcPJ3/c86BNfxT6 Zlz+c+FfG+p8lFEjEYCwGPjhLz9+hf9RlZ5fvV+jNvrNHbppjunYHKEOAH+sZx9Kx+QT5X3n Yve/6jd4yA7qrQ92a3xGUCLPCEoihGal1qxEWqc+++6hZ7wqa31YbuP4uW37CY2+Yz+hsXf1 k1KtXT86sjrhg1pux/4bB8uZLidtdPFEWm07kZ9S9tyvGyYIQiWKU3Eo5CAJF1kwDTmeCk8J O2Y/ssIhCDBST0qHwRVHT0pfMMFIk5+piAgzka1TpEhII8QRx9ly+qSvv8gCURZ/u6siU0RE 06lvpJdDdOPkNmF6+mKKXUlOeCtVZwBBZnqBt5+iRp4QZtKCBDPSkKBnLWlJUKnB3qYgY6GL PMZwc8YNAyDvbwElFApUIJKItVLd3dnytB8vWjWR8tEuyegm3Aikg2uOKiKHP4vooj5mEI7Z e1Yq7En+DbI2MtNBLCcZBzto41YDbJr5BiF74KLTAcq4M/hQSRCYMrbxQW6RjInBIuQyKpEd pIqiRIPkSKnWODb0G+PLLJ/t4e3B17thFNy7G68x/o32mboL+ULC4v5i/Wb/av6g7jQWw0Qy y7/VRzLK7bA+bfhD/su0pF+5+8729tEhPUPCLN2BheGfGl5/9PMW5EBg0Hvv8A/opHt/4N5I yVfvLUOvNrbqLCOvNjR1lv0H7FGb56CU2X6YFQfQi++1sKhMimQock3z8gqSTpUc+XnyRMJ6 xV+L62FpylUuNQ7bmFLlhOs6cksB+ovp8dUMoLIxv1D0oMvlHL1+ZxgMbu0CXI8IgF3ukeeD iZOAze4OJ0lDFR8jnjwuPNrf1sUmFzbnplbRLkXemY02i0wqF11QcwoX8BVW3vuP13BY33hV 5k3EW/6/H/8Q/vdj77EKx849xq1RpO6xfuqdkUILp7xF+TfUm4SpqipDIIbi4P3Ez/Hk8zEc TJe9weVcvAT7+8q+FOOUrXQqKGHWxhr/etJCV/PTmdaWb48eEFFmxevxLvfjmhfkijfkSlek BBJHz17G5SRa+Duu59ERLSjyX6stqC4W+RBLCatwcnDavI/V/PAHrCbyrv+Sq/lv1ITFvKe1 /DdiZl3LXz1pke2Wtq5mfQcn378MddkV+XmK+TQSb8nvcR/9TCBTbl1LuiIzLOe40hyLlg/6 FMsO6FHiFAudArU064wqUL/3k4kjpsftkmLctB8+LcXbGP/HnJZ0Sub8ft1wGJGEtg4jwquS rI8zyd1iZycRbALLYT496UbOCHdnOxNUg7WZ4WYFvAbkzKCjsH9d+VDJFFQe04QZWWdq2VZH E8Ms62EnFGBRI8LQv+F3HoqeA7KgYnzyjLQBotVHrcD7ivdpF+T6aU9lreNy9wniCSZrtOPv ywRSSVii1i2IWJLPm5V/FEVC1Salidod5aCwZEusvdjySPh4XBvPsHYWfzN+HOr+zaf+Nwnj LJxwB148HBjtT+SJswxxvnMseU6Sm3WDHkUgk5YFpHqU+tDtRnKbSphx3wvHsD2X/CTooUKI swmiQkhSrPe2zE7E8SCW+YcDjOz56t9xmp6FKecFrwSUscSGkfEsYHuTo2fXNyV+wk8KiU65 ruFoPPM53yDpl859Sq40G1/Qd5OHDs5caVv2WS9JRN5KhAPLxQbI2EzGI06nJOYiF+dxPQTy qrRbd0un3s6QqraqRXESQcSIeuLEE+hXCrT6KAGevZIrAev3F0KjeIrs4Eg/vwggKpzvRFH1 wIqmJs5EJ5oAxDYGnH2lSd+jp7gHir2y8YcVgquij+qVjj0yZBryJAGI4Y4NYwHqJMNCVWMc XsLiZIaIGsDFEI9UDa6MEFEtuBgicuR3QiE1sMKgpInYCOTeoQhBzHBoYD8XfyrnarQIbeKl pe4/68v2jRUIw/21ManAtZAXNaVmCmbsTi6krxCpYBkwWRyUTp+9v94HFx0sbEX33iNYrA3R 2Ol7kfS/3H9L3Ym56HkTBPguUa+a+sGhkqO7vy+EAZ8xgide6pxFHTj4hIuIr2hPtMbiJUfU SJcksCaRMgegdmYK8huPs78vh6OQyGyoeVXjeCETG/eVkSzFch3nN6zVVYu7eGkXf9Uje2XT AOUY0iML1IINeRPZECVuITLJd2uUCkb8hcooJTPUtzrukvTJ074VnCWJNq+P1JrEbz/hulT+ nZmTPYZ8I8xRVR8KjKv1oXRakrinVIUBT+LrL3phv0Yn0mW+CjUHEuW36cipluiptAurXkGm XyYBNLk5XjlIYxwpNOrvsez+SQOtTFuxISK5y1OU0CsNFLlFFoxwUmk1quXVBjgedwFNexkH Oa6XkcIdrjYGmsMyDqCUTmtfimYOdC1G9UrqJ3mqlhC7BFMiMuyS9oqyxZrpU0rXrSYBimfl PG96rR4lLFaa3KgomuWNpe6WoXM/YmajCFUqSktVJ1KRqCWbxpq8ZKITUTSqP12/AliOzyhv BaH22yaj9amiLxZtweer0hXuk4mmxJtGWVjXLWwZIUmCl6DMEvVqomI1G9ATcqDLAPak1GxV GtkBN9ElLwPc5nHp092OMI+uuNr4XKxTumALYic0ta05nU4To+dJvUr19/MvclXat2U2Ze5B FmXuYs/H3GKXx9xiX8fcYvdFW5N8sI4m+WAFTfLBw2iSDx5Ik3zwQJrkGNx70yTHIf/umuQD V5N88KfRJP+/p0g++H0VybQB9PNgymTF4y3QKceo+c4itfIfrVUmZaNHCXVEl9wbk8e/aAYy aZFXpNu62921yIsJ+qpa5IP71CJHgd1Ri3zwR2mRD6Ja5DhFvaMWeUX0Ub3uqkVejDuraZEP 7l2LfHDvWuSDP0qLfBDRIqci0L/1yPeqR76zGvngT6pGPvh/VY188KdTI9+3FnlnTS2yKT5i dMikT1qqQF7x9jH9VlMgx26b+1MgR1mDB1Mgxwe6ZwXywe+gQD74EyiQ9Y2YPKv1dMUJepg/ hab44E+hKd5ZQ1O8VEm8Iu3gPtmVxMvUVStriZcrqtbQEh88lJY4Sm5+Xy3xgaMlTjuf2bXE K6uJ0y/IZN2wQuAKfg/mvHGUwSbclHGYgJqShh5nfcJJnE79Pj1aCbdVr0zYndTYvhNRIUFB fRw1FJ2r/SPld1VtxcFwtlXzZ6RCpywK/qiLKyX1ozsRoNH2Al4BjSNm8sxLzl1LG0GZt3pj YvaRNbKmj+m/MPwTk4/RlkhrztdiZaXtULVcLAkyn2xRI5p5bA2c5ciyGpRqYvkiqGZZl+Hg d12GSIJ4t5DVjorVW3rqD+TQq0/acsUvTy4x+oLOt04woLJjwBiHlKqcrSyiwg1FNuORs2Dt ymibCW+dRIBL8GUnyzw0wmTEGMqztjb9VSAVBU7CNltvoOfE1crwk+SShmdEKle7pqVXtos6 oXHRc/l7M0Gh2ynEJQUWKUNIz4E2u8WQm1IOrPyhUv6oipCuOtS42xngeq86lPcbH5zIG+DL 15tI079YeQr4s3AayW+blfeR+S2Z4OG8MwB00/PjKOIFlfUKK+1YDKd378LRCCutRi2K1kY0 BDqeKelTC3vpCOxIH0lNbLaEVXrIUgeqZCPpCCRxk8mhYHhsU54y01FMbp58GA9vR1j0cdyr jvrjreoIZ406vKY/8KnIUbldrbWQoYyKfVkGpOwR3bsNi/rGNIE5dWCA3xnedeTDn2ulk5WH ZkH6Hheaud+sUfR4b5i56Utc7vBDqWydhHpb6prJJX+bdQLW+Zj4IVkdipIPqNZCNn+HaEvY oZ/9cOkGSWFYLurgGFBidcyXdUzRUqzUV3242Rms07oiNYh2gaVo3CxdCezFfyoStU+VX7Hq a7vxpV2vHf+87IgkjNy648ittUduTu42cvN03ZEbN/cwduPLWt98151ed+TGzT3s9Fojt27u +s3rj3wP+9xab5/vutrrjoz7fNevBmoCS948XfNo3fXT7zA84tof+PW49PdAytcdHpf+Dx3+ 7kQmYXjSvqFLlDedn58H4aWtMFvzjjQcAKXf54K2wLFhIjf2REX9isl1vi7Fcgy0wf8CvEy8 QnJzWGJ0AVqyvKZvsg5+9X73sFhpwLWieTQLT/1p0+9G12fbLE5Kq7cWf1o9bYJg/bnSaDdK tfcVckokOThlgHeRvmenp7pvYQWOvyccvxlmy8s3sCz0G++HnrcJ/xQiIsCZLfKaSuE/BFZO reRZs3CQ+tFJr63vsl432/i0WSm3D7lKQKpocdK5oV/VdJRQEIOQAdESYCV/ZyZefZWZWVY1 bZTgAu+Ucnl8Db9ZKgAstBZejgc9y0KxePAzBHYcDIMZ5TTNMt3nG0pLs6ThC4+LgGVoe4xf sto0Nu9hGqdT/1srGPqfOmgM/Z+g3w/8kOubBKNgFugDQ1m+KfV3LCn3AyYAP52Oe/Muplw3 JdQ72tk56PmjWdDH2ic4DyDEutzBt0lvhVzgXGOPhvKwgIgDCl8COCqVoKoiTOYgZQbsrAIr NuixSpirkzSpczQTuFd7UYplATffZ+f/zkXyfycUNMAyelTLYDblIiSvtznvt6lpwCXcp1Rg UOXyCUYeDYMgupedae6jf3s9nvZ++QogPp0etmulkwplusYvliWhFVFrDdOQpMD8YWU0HtLI sj1Yt0bvQZvStUdLkHPSesTIFasRmCFxupNeA6AnJOKXjypGNgWp6BNeMCptsEaSfTIImEmY uw6zalC1x+sOlgPiyomqwKNGIVVgIrdqtv5Go96gSyD/uOJAhj0jqHhl0R1kZke5+3PuEvyy jRv99L+3nxJppfNsnTE8yQ9ykOmniTUrDqffylycBskOHmt67M3oL0D2rnbb7MnJxXqi15dB 91JDSvkZBheXXF9l0OkythsYHp+E8/lsGZhLwMORJAbmyjM9uHJwbqPxdTJV4Y5R0vKPOeAU WiY/fN7k7+tzMv+f51fQAMMWOEd6p8s+qbOxhgWXEtV4ub7EEjCUK50g+DeTAFC1SKl4AXeJ lZOiMM0rWN0KTj4fK/iZRH42knYkLwQCEAdRmzbuY7vyCY1b+AfBJ28WuCaoDhatlpTppHI3 PFF6jBglIE4qJ81KK59HuuM9K3hPDKSit63LIpmnBalVb55s4b8/7jIW4xGBswEiQvm4Uqqd gfBdPUFnEBrvij6GPjC1VEfkyxPCcVPGaB9Xau9bHxI7vK+YEwxdqX3R+gasoPGwp2w8STpk 48mSM/YvhtmxVUhCbIUl40lWJBGcTMLnRJyyMBtlTMSGwgOgwIsNLDwkG8TeOliWhF115wM/ 9FYGd6+zexiMzxFelLCqIFkNz+d9wHWqMohyAtzDaBb1hvB8ETc4Hc9nmJefOZjQ6YdRZnhD MzrTYxpG11+h0l2h5w/PfSyix8W0Ol4IjIMPl8i83zeVthTqlpmR4zpY8xHif0LdGPI2oBhc zQni0FsbUs3l5ODsyHsWX4K8XXCqmIGZbFK1IyxqJ83xyEmZ7EgBrdwBfBCcGCwFhC2peJcw m0IWsLwHNdKVaXCiOBs1wb3olCiibgpvN4fO2vKpposlvGojVCwMHV4cINOWDEXql3nnqvgW iD2qB1wahBvt8Oo8bz7EqduMcy1wbcpSq35SLSu2z4Jia4BUcSR6wuZq/Z0eV0FHkEAfNIDN d4gQyIFenbexntj0m2/AF6OTocpeCuTmu0kNt0TVv3be1NHyZdbHfYmFD+3XMgtcRHrFe7ZF 7KnVT2oXm9ViZt/qQvON9bNKZ1OHYy2XTDp0MvJvueJwgbuqddQgrHKDsTP+wATlaOr7Fj3B 8oor0xLsFFKBnPGUi27q7nlTjj0jIWBNHZ17Ehu92DQf4sxbJ5c2JLfygccZ0oG3HyL+8kNA GNWCMJMe5npj1hupdvhKNRP0R8EG6wB+PGpUKu3mx4N2qfZz3m5VD1n6seGbgXPfUaAY+F7e gNb+XabEWRQVHhLt6uF7f4YsAyCcFBgDioYIwQqYLDgn/UKnI19c81FA7ug7Lz78l5dX6oBz yuYwv+HSlVVqgT6KpsbDeTgezDEkGOCR8MS1ahWb7/WCvnj4hYLTUeRt2Z9ASHX26qVnfbDN lwH65LhFTqpu/qeopDbsNcIMzsgLEs/2xG1pVayLgpBtNUv9kBt62g1QPVHuXxx+Hk97qnRd x/tx18M4PQl0R0XJpBuoeHKq4pmNV0HFVRI0UmZpiFZhLoKdVKBuGyYXjLiGsF0yFqudYpm7 K0IPVHZAQ9ZsSHOGTPogL/bJQpM8Q5JKQodU/TVz0StiJbAAUqnXm3Kv03IVPvciCCnBARc4 VaiEhYInnzqDQpTkkTJHqBQsu1ZiAoLB4pBeqs0r1O6hskhqW1P556Ie3yPYGqPy24Y4RPf3 98ElF5V2Xt0nKsWh/RlQKY5JD4JI8PF3RqQ74tHviEYHtzPfoNHr+8SiGLA/AxLh9/4OSPT6 7jh0jjNdH4doYx8Yhz5jvWzrXqP62dGrCL56HSySWtxxYH8oFjlf/DvgEXz8GmhEa5flUluE R+7m/k6YFEEk5yK6KyJFgS1BJK58hyW/YX5s5zybaDwKTSqgSz86J1QDUQ1lCklFsU/KvYcU dsR1G38nTP39bs27Iuod8fQPRNPX94ilr/9fRNLf7Va+K44uuJSz4OiDX8rKOAIrzwZLrwei rzLCpVh2Ip4Q3DGULsy6YYlHZT/oBVO/i7oeQU8eIUGPVQ29LnREo+mohwVUp+OZz2OM+144 GF97k87sEk08V8mIFvRtBBtf4dO3gFcYMUmYhQ8slNK2oZjAmUUH5mkVWDCOqL/wIibI/J6W ZjPoyVuxibJVz7w32UKy679X0H3vxT4srvNG94zcEewg14MX7R5FmdK+kjXdu/ZVnGznunOr +7XGpoq87mbachSp/vxczb/GFeBv0p+OCqL+fEpUSDBKwccQjT3XISQnDiFNKVGfk8g4chHh YdkuTDp3LH2rzKulw9Jp+6hUPX6zulPFp0qtJU4VCKZVaXgIyaMXGITLKkRxJPwhfKNpU78T AH6z0x+RhZ7/7Zftr5vv0FWGemE2vGi8UKhdP+pnrR93846x8WC7XT1pfix626p/92I8li7n QKJQn29/+Wm90dJfrvYaw2ddQ/nendYFB7EWhXM6aV8TNSovFGXE0fOw/F2tBeS0zxnWz/FH jAI4SAaw4wDIvoiNSrPSepMjss1nHkep9m64H8ZOM/kawPXiveSnD7riNKPoknuxFZejR0O/ eonZSNSRxylcnY6GAdNF0pMimcOBT2snVRiy1f5yUirzxxc9AUVg405ZODU2b7duKIhaDfT1 l9aX9mmjWkdn1q9brRu4YxpAtMltaoOS07DnFE3ovY+WduxnzUiBork1W/XTdkkW7APGVDea LePHhLscWW3Yc2SEQu/Jvvd/1aOjduOsVqvW3usPiXt43f1rcjnBroHfmXrTG894C6pcn/AX oKKgXoMfVqf/EJU1B7pGRi9qL2s1BHoSTFs3OAe748JpP9gWqo+2q0d9QKaBLum+8v+TjKij 0J8Ct8DGPQ48hP2vjoJZyv6r2OY0MuKQARtWJnriZjNIBZWFsnBeAkJoZAFPumeTXof5w6L7 Rdgaf2nQAAfDOX+28x6HPx0PBrDuaYeCcvDuKXQojXrk1dS4SYD2gBifRD5rlVb77DQz6fzr w5JOmI13dppENiPDFNQVe9LpgsyDuydX8/IdFWQ+HJ8iDlXxbu+DZFW+xMABN4UVYtfIn6GA hFznSJhgELIodF7n3IOV+KHrIlycyCH6Fb2npafPox9Dc4qcy0+cvbBLs+qhwAeiK3mijk3u 4LNQn0/kydBEajIPnBocsVIPYxd113MfO2EmpbfckZyZztWNLlOUmPKN5Su3oxMzW0FLqVBX ALsa3FUARyEv7zQfXY3G1zr/4feNjWzLjTFK2GweJq13PPEo5x3NpTc60i4rzoQ7bqroN96t H5rJ5nLJnxnrNRrbne44XU6kGhu0x2krMdrjjTjqDvrL5xrr1p8PBna3JbuhUryl7gblj6OJ NyonlD7QS5h9HysSARiNHFN/OKYMW6Ne7CNSR1AJCr3C8gHQC26wInydZTHLAOHtEKS9adBd vgmxviPAH7tbnIZxso/ORQd4iZlnZaaH82SxFWn56+0CGfHEKunkDTpucGqXRDohO7sEZ06a Blui6HLSZJCcu86LsjeEGuOBbxMRb0gJ8XTSXlywxI1UsCl/XTbQIabES4CcoetPP/3kdPwu N9EGpZaRjAwgBw+9fI+TiiQmzyhIh2CEfsGcnhmf6C3OlPEinvekEEVC4IisYeFTxGM4/wO5 bYYvQr9b0Jk8ssRg0bfrjVh5npIlZflE1fLdw0yXj+Uky9zY+EvQ7/l9xK7/qjTq5frpz/a2 2LmrVdOzJjplYUAtJSRqnp3ErsluZwaIsHnRQQ0RDOqPrDH/kjTP2c0mua2H8yEjoTvPvwCZ C/op3xgbLtp3nT40Hn7yyPrmRvo3TzN9gM1beCk/ycynnWol2oOSKDG5jAZSPBIqZrLMufTS 5I/CjHhCUmzNg4rHiEDZS2i38zWZ5wfGmxQVf5/7c2a744EUzc/VVvkDHp1Ko8Z4bystFO2p EhEhxSUw3oMeF7OAG+WKFNHj7niAXm7zyZYV+LxIr/DbvueoFRaIQof1zzVHGGr4nZADJGOy 0N/WigOLSDs4IMs73mOjhFskmywTTnrMq0osc/Li7HxN09QtR0y+KBbATVXmJC264AQqit5Y y64uYpRD5RErtbVgekf9HI/r4biy8AmzataPWivNKoIhrwRBrQ1jXbjIcYmCo1J60Gxj0uLO 15S58qlabQ0Xi/HcOPpu5z60o7L6IufjNEjOh/nRfymxKAbve5IfW+tSeE6yWkn5Jx9UrRoD K4aWOwF9GEVfBqg8+YUwTdjs6rpfPDxa95vSW23nwr5ZNWKrfc+D6dk21lEWe0oVHWpd9HK1 s3xwFjgbd9BEL+6YtOr/THgd4XmsQw18obeNuOszV4OhLiGugMVvRgTeGpUVo6A9bZWn0i7D YBQM50OOvSAeUpgXMZNGkr9o3txm3Xbl/ne62HfyhqulL4Von210hq0xzT+kpcId3MjFvrto QVYs4oIjcpcVzw43M35YCKJv29RlsAwE3EPxJbCIWgbJaCUJ1zGTKM1ZcjNezEICs+fYOTIY YGU67Feyv5/A3ChVyNVJp4tZpCokwyXNWWvaUpvKvJnaoxK+ed2ZJN4UsZaOuj5h4NRWFqRl VpqE9848sttwkttaV9kK1p7EFta8/snuvmQenxIbo8pTS1Yc9zo5Ob8rL984biq5KSVmk5nX Cf7ndDalhich5sPKu645GN7pBGLSQl2dtyfzGYV2Fr1YbKSW174Mg9kRWosTLkirlzDf7nIy NYYBCt5bb7tAWeMTIuOwQdoCU0z6G5lLLM2CPvionm+UWtV6TaLYIwn6KXy/o9y8UP620zJR hH8wnAyw7iSK5NJLKbastpgQYIweiZ0JNu9RyxdMaQ6DISG7yeDGof18r6om8taXx2lqlBSV nZ1JVj4SWxNkeWeGb0p9jCVDfY9rZIxpKn3No3knomvOeRwAxrUPwjz75i3Kn8K9KL/J00iC E9ywQQfEziHeWqHfDa11T0oTopd8YQ0FxXYs5kV3or4PrIde2Gc72ifJJFdxkFJscYyNtvFB HQtVwNR69H1jXQIDo9cOHe2MiXK2/ES17+ZDOohS0qDj8YW36Q3gX3KizOYWCs1Daa88P8Pb cOYPVcwvpsOSF93xKBwPkiKYV/HppAhnM2U7MVaRPAjhTRlQNdR/1ebDIqezejahbkjuNn7l R9QUUx+9RsWE5U8oUByXwkqjUT5u11sfmCJiasfJbV6BwGSO7NGIgzxOpKgMoVyvHVXfJ4Nw k6ctBVWtVVvJgKqcoC3434yQavVGpZnyWRjYi8xpOJ5Pu364HFjzczIkMvCMOgOvOe7PrjGV y1JQH1JAfehMewQBudX51F+84Ccnacs9HM5HKkdcwmQwYwOTi4+VRg3W+6juEce8uelR4i34 hYsb4g9BfuN5P4ScG/KxelFDG8H2zQ83pi2goWqZoqIz8xQ09gwCm/wH+vQiiTDmmMNq6X27 eXaKSrEHdS3HLT0MOhdUlWFTe4rj+F5nNuvAcZJUACkkpTaeBf1bohFXgB3+AClGrd7iSATO v0clvTujW3IIhjPW40gIHARBHPqBQnf22i9D+wRKAxsZ8Qy3Z688xD30Ee8WPEpgtdhJ/Fe6 AFSfsmdSbyCfhVp4TGlgMnJs5OTPvH4PzGGpazYfsO3bHmVj5KwEM3hUKmPPJmUVKp/+nH+S py6oFjzodK/mkwJcf+ZZk7jPAqvpTb4QUhc2QYIow11UapUKBZP2UVaAhXYsJIrYUyq3qp9U KWVqdzCGdT0GUj3w3iGSIflhWDqnK0/5bGLns/3cCav9s4nOzKU0C2Zwt+YevcfFp0rvIBOV B2M4z/TDTMciW4JWdTCCHrKoznvHrAJcsLy3nGwqtMYg8LF8p9EPsFPp6q9GY1nitu7Itqol WYABOwYDEpfTnc5OdD1XXFAp+JRtMVNXc0dWsze294phu46VSXM3AyjPySim7TuYxjTZjqh5 SOp27AM7nEbdev661G3YuY1TN/RlkVJkc1iz81tN3qpZiJsXp27O7FehbhhaZVM5L4X6aEqT RJGWU58cdYoQH89T9AfuAE2CNPgtbF6ie0UVOaTG1cNjy7TNFKvrnlzL5yduPtdTyX5yMpyb 6Ci0Le4J6go9ov2gADtALMzISWcoLiPGPm3nz/xpO/rTQGocgzQg3+Z82u9xnEGCDn1OdVo7 n6L6qTkYz2odyqmjk0djpKDMcDQfnusQtmjew4gcNEHgfJYRQgiQOVWw5bWk0gajSHQNYjRO aooOckDkpK71t26gxvXGzHQHM47nRJBtAjkEMgHUgDP0IJABJumhaoacDpFcHKDr0+3dN9ud re2nRQz5BH42lIzEiGKza1QGdKadLlbE8ngyE8w3NuLExefzUE0F4F76N15e4Ied4WTge53z MU2cyigSAIxJxW7bN9sg2ZPod4mqh5vYcPK5ZplB6L3Z7sSyNxIdJvvyG1oFt49OIOGsOZJA b0Ple1SO56m7n99AwXTmcaJG9TROHvHjzL5i0Xe9vsIIsoyJ2YfgtExPx2EOLnmV/1EBRm4K 5NIj3IRacH4+8HNUhJEfN+mMuM/5C3INP5wPZrkcV2DcyEmKKns8ZEAwe69hxpy3QCSevsGX RJnT+m89VayG9eb5czjF9BCh5txe76AXDvrkCTeJvH4Lr//jqTI6SAiH+Xyc1qYupsmxcZhs X3KEAGl6yivMr52enjPQpvfyNXMqLtuRc5Z1YS/+AEv7lvCpHftTE761D++9rF+78HNe/23P W+N7rG4b8c6MR7qMK7ch/yjzyprVnvNCfnn71nu5Z66rEU8EqMBlcIEaEExsxzsW7fmbZ89d cdBRTEPQRDY0ySBw342KjME9wHVhM38OrwsL27OlTMUu5WfOTRCEnAMNgcCPxDoDFuD9K/Kw L8qyzow4v0IK58jXsRmyp8ZMC8DHO2ZOXCU+4Sj7LvOtlh5Np8LVbKLL09ts4vJAaU8xnPQD 9BnIK4U7X+PnCb3WSnulT2aCKVYSGI/84yqfquWK9wz6IH2D/yi3QRSMGDLp6KTgw5Facs26 5AvIOIce6V4r5TZ6XZbrZ7WWl9/d2n2xu/WyQD0p5yLGrZMBpoBvXxVwhkB48Jrk61jdw30E OqWsudS7I1/FCe9gZzuxzwSwEt6umGmAQp0RMLKrRdn+8XxEefXqH73OAFMN3NK92Rv7nGtP 6e2p87nCut4j7wPVzUVw48lkHGLOCSoNUrM/Gz6UR53etuWLL3z8YgSrJkvp/Fj4QAPBeIqR /DS9LVMo81EEROtDlYqhnx1LWRV9MoG67Vn1BPXewBoVrJT41gbYsPYSIDl6cUsx7qJt4f7z 09u0wKUE1TvSgZ6vKYEwMX8WWvBPRQkUhtUn/iiKYBEsMncg2cei9IMgWOTDPUeafHjcFfNb Ro+UJiLBKJGIcE9NShaQESwS8T+Yd4VJCHe0CElGGrIhldEjlGQJEeFecQoapZkxCsId0+gI 2wrTD71VyOcs9HXvk9YZ+zXhB+n8MgBeVCmtL94/0PEGzs6I0tSgLdKn8j6eRYBIeD2ZzRFH sNzJt813w9l8EbakEh2bDpDC3Xj6o+L9sHJw9v4Bkrc/7vnn8wsiKY9RkubSOuuCu9fZPZC8 fjgfkjfFJhehhuNBMfOZzJLUI1RB9q5hcjC+6IPk88K1SkbJqJQNyNk0kkyPMq2Ih4f3LLw6 L4oMCa8oVS0KdMPwYuCPFK2CRm5+cGWJVlALb+jl5gnnbFFWaMZF61oFQJyheyk4geT5w8ns NhEeTxEoLAGl2dIY8vyd9wrZJtPs1UsyG8hQm5ub3oF/EZAJXaWaoTvth9ArYsEh8rrmJ72C B+03yeIVol2LgRb10GSRwNljBnFdPEF/repQiMwAf7wKkAhrDpvqhz+aTrDCKcLah0NbSn9u 8FYn+F8Fd7kHfhB1X4TDCGMdNKY15iWeFIkDQFKLqKtzZcl1HuyRMf2yQ0mt8N89Np9f+jdt tvT/skMWdHraCbsJTz9UvpQ/lBpUTOrx9s7ujy//+upvr/+jdFA+rBw9xh1FwCKYXtq/m0HI /oLPrCH0M7xV88H+9p4XeG/pW/Y8SxUyEUUFCu/wx9v9p//7lGLrLFg4KoJ7NsFjogK/Eho8 3cIaSTRjkFg3EtuQgG1N/lK9UCuBc3ribd/04RJ69857SeEPlwbmor7SdbufpdNT72mGVjTf Cb8P5D+wcMEPO6+SM/Zo67WBBtihF4J9dayNzDnbSpUAzbk8lOpXD3guj7G6WMK5hDlz5TH2 u/2THVOctTqm3T/BOaWUXHhAcKjBPZzbCRpDESoaQrsLD/JANS3IEV14vAZ4qnZfF/iQrXK6 pOvL9btur91159X6XXfX7rr+Kq2zSIPfj3i9TqRdL28U7coHm68Lz17aRKyQQquiLEfsJ8Jq EL2xhQRL2G63UdrDugvh1QWIRNPxud8ej3zFWGKWSRR8n01QZoEZsJXCfQvSYhsTDmLuO+2K kuMyH8YFJcd1NayyMAJl5M8ESu4ZC9n8XmQZdlNrnzbq5fZRU/eCqXbbvWDahlGntwD6FB4c BajNVSEO1neeox0/bPfZ5ZMWEx+zQmLf26zU6jBNxSDjd3Gwt0wsj59fwGv6YgxkdDyf7W14 FAypHOVAFj4poWJ1GoAg7YccLKGAhfiJw0572AmvCBZs+BwYWkTYyA9x0RjbTCbTbH2dmbUl ZFumjtHxHFTNa8vFhSj1KjzIi2Vc9qhQKCSy8uR0Vmk0vMdntCykeFEVrBQsD13NxJj6WKeI fKS4/dT5EfsvmEFCsfI9Ul5H8PxqSMPljSG/VJYKSDi3CpU1Ig2h7pX9A5QKKeP8sWpOG5CW 9EIsu/hD2KW8HjpSUA3mUkjypcpZ2VrxDQO0HlZ78phUTrxYloser5f9bMc8C+nL++wwVaPE TI+bt+FHDqP2mh83/+P1zc3jgupOmUwofMgxr6ttOJnN4fnOX7e39c6cTeQk0QQxRYOaLPwO j9Xh0kE95apyyMadoteuwIjx9G/YjAosyUQigN54PwREI7nHkr1oVlqi0GnXP9cqDVLIqUmO Jyg7YoVVUbapFyGWHlQvSMup3gAv0muTQqd9Q4WPuQ3GQ6gmF3BCkdaE6iW55au36LC+4DUe 7+F8AIQK21FQ9b7HzfxZA/Nj+E7TTretUgcrcP7spNMtEZvFDXvjdjDuzgb6i6r4l3rLCbfa Q9xR+WClmVJNdIB7LhcJccflBUKB9AL+z5qsJxpFUSJOSMWxIOVGYo4OVa0WdXCkvoZWt1S0 8VK526p0Bc2PpJRTQ2ElLGh/3jm/3dqSgDX+Ir+Dp5lSJcD8q0fto3bzvfeb/qN62i7DjAiL 5ALR2S4munY47I19leANbxR85CyGmM7LgrheSEVWuj0ainOGp5ZLCkFUXLX0IDxOoWl8bsrj +aBHSlbNkDPIrWQSph2pteLTO2WZROhhOPG7WLk6WrSapmhVhZZDbQfyCVdDS89Z4SZOjd/C nj2gk0Eczz6Fq3C1Nis5ieepGPg3P3Q9j6KOMGEWD7ZBuQS85wmR8xSklBZP/5WjlmqkIqeY CN0Uoe/vA9fm/eQ95lRPmIYJqwHP/Mce+nLno613Cis0/tFuTJmwcCopjf9mNW76F0NgfGjB 0ibC7THi1UuYDtdoflzAH3LrBQT+2Ycr8fq4cphQaHSH8uzgVYe+60/UiW+zkMdRL0iD1PJK +SuhTECuit4rizxEuTrNvsEJQ8PFjJjRLnN3eQuPmu1q4+x9HWbXvGqMx7PDYKpuFA1Djon6 EzkKANUfT7D24JPwqq3/3nPbsS5TblD7xfh65ONdZtkLbEqhrkRCJMWt8yP4B57wo41cnHhg hkdJ8j4ijwXOgE2MqiIFC0KXPPICSQqlNjqnFTi/iISSne/L5RJYJotbFucOm1PxrJVG7k// uGygu7TIhJiHsrjuQ3KAp4fMZVkcDD8WLsawMfKcdshiFNwfuZWFa7DYhsRmiodIZiJMO+Ej ooxEFJxiGWIsxcJ22XiLZObCgmnzFxEGIzZRxWnEWI3o+lgsh81z2D+xBDsr8hYLmAtiHd4v ZR1W5h0SmIcll/n6t3nO4icUl5uLyAKWtECzU/bnFCqcW50O09nPucQ4l0SOsxPkBSQ5A1HO 2WQ5l3Jh8awjt9ZO6q2VczXOmfgbq0eEeTmweJfE69kK+xTGrNkR71zNAE9hqDCQxF00+IfP DfVsH4i+c2mAPPnhGl5bmrLto8KzHaD3zzfcrJOmrbSSW6qJLCpX7LgYjM87g9AMTR7xk0N6 i3tD/sx02A8b1U+VRvuoCvJYrXRS2Uvo0fAH6KlwiJeK7tGoHKODPomgIl8/0T3ZuT8iZie6 9qvtj3U1Tzh6YBkkrrhCypjpN0RK0cXIwRM7PV4hCRw2MGhUpFX9Lcc1KhVAs/iZTtCZvOHJ uA9ZR8Xt3+gJkcxM/om2Qp/Ufv6NUvthltdv6Xq/guUbY5R1nijrsOlFZFkKe/HIMzvQyL7f m7ocSkQ7gpIBhoG32WUfbyd1SS9hiognSmCJSH8bBbiDAGUFkkmdS9zmoyRiLixoBLzy6ogC t4h08iAJo1h9lKvKMp6dnEYSw+b2TTQT3K48zaauFlP5RtVSaBpWBRRPKqCw5E2sLDr8hLNg MAC2EKNm6NaMZzDiw9aEiZ52ZpfRZB08nJOncTv+nO4zckVPy8SIWTgo0p3TcbTqp0X5lLRh dh5gGOmFWRg6s+6lCk+zNoaa3bX4Cu49ux4mw0/JgLJ4J5bGvOG0P/sYY4eRsZzGAYM6iqii qTb+Tl5jE7x9RxdFtEd2geCFPrtNL0XFal2rftKxa9mHZ4jbS6bGSfxU0pnecDmvyLm8wnei EjFUN9FgwiYXeDQ7H5CdE779V1R/tj9Vaof1Rrt62P6xXD+BLb/Z+ds2XHb4rlT7GV64v2/z /7zvxXQIr7f98/UgNH9ufqzXapVyC+G8/HHdmUTh7K4J5/C4WvtIILrrTuWk1PhUwTQZK8yD sqXRuR1jZhIpYvYz6iV3yWs29DozSSozpEJnm95wEIx6wKX+f+FteMWq960eI/LCKb26j+96 tZPtu8RctgAWCMx/XW9C5VpFdvulvx4E3GzAHDoE2z/u3gOQVy+zAoFfv29830s8xswK0xmW 3+kAb+F1jvFRj/EVqiW3gl571uFQKvvI4ysyuOb0C2V+xVfMNeA7za21J/kIv1Yo2tNji64x 5+JveWT4lCOgYgcNX4zXGLAd7UNlSYWLpl7Ha60BIrfNFLvNCiAu7yzS52l2Brk65HyGV71g GgdU5LdATI0Jz7BCMX3351IDdQG2QorFVO8FwnkBcF78EErO8fis9za0ky3afE8qrPC3ppsi VmqJUlm1cBPFkZiW+YmFCTETV5q4ncAZWhMRxtAsjzqp3zeW8veGucffDBLQvC3mkiccnX3K fNebLszNXiiNmdBCntMU9WQBq/5/ZFgJSDxSAgA= --tThc/1wpZn/ma/RB Content-Type: application/x-gzip Content-Disposition: attachment; filename="skdrv2nd.h.gz" Content-Transfer-Encoding: base64 H4sICNVP6EAAA3NrZHJ2Mm5kLmgA1Vt7c9s4kv+b/hSoydzF8npsSXE8SXSpLZqibW70GpKy nZvZYtEkJHFNkRqClK2Z3e9+3QD4kijbM5e9qmPlQQK/bgCNRj8A6PTomz4HBP+QkbuknxT2 4CfrbuSfLLBsksT/oF76SbnSI8oCdkwmmkGugrl7H6RETxc0iWhKVN9dpTRBihuasCCOPinf m3Qd8FfSOem0yfdY23dTaON7/h/pttvvTjvd006HdM4/tc8+nb0XqEmWrGIGQIt6ceSTBXV9 mpBZEFIyixPiJ8Eavl2ocsOQxNgNsoz9LKRMDOabPqcHB6fflqPopHKotbR4tUmC+SIlnY8f P/wAIukSa8O+xFEEcidXy/vrkx0oohD6jgzdZE3D8EQytBcBI6sknifuksDrLKGUsHiWProJ 7ZFNnBHPjUhC/YClSXCfpZTAPIIgT2MuwWC2QT5QlkUocpAsgYldMhLP+MfVaEquaEQTN4Rp ug8DjwwCj0aMEheaxhK2oD6553yQ4hL7YMk+kMsYGLspqEWP0IBP3FpoDOnmbUiGxyRO+NDd FHuekHiFdC3o7oaEoEEFaTl8GE4EGrLkLcA78EMxoOIIyawDH3r3nWoRw/qOPEIP4iwl0LXE jdLNyf8j7SF9yrwk4DL5JIv4/MMflCITayeIvDDzqZCBFLBYP8fkcRF4ixzByrWErED9PMqY m2w4KeOrzaezIJJIUKDMS7NEVkFjLAUZMpIxPv/YEjKqLFZs24uXS5gauVqlwIkhe3mJvbwO QL0Sb7GRw1IYavHDnJ54/575eRPMQNtnxHGMkeZYX/rmTXfUd64P3ogB71YAiezxd4tT9vBr RjN6svhuq3hOF4/pbnEaLGmyWxx0vSYWq2gZ7JavV35ze02lQRQ0dMP1/YZezMHMJ7/ulnss W+6WJuGygfOcgg/B4oMD+gTrNCLWF2d4Mb1UlCProZ+s1TCMPRNoh/fZ7BAqVe3oGEHGWDsG 08OCeUT9Vi8nX8eBryicFM3JXkrZzFFJCSXT8zOkHbMrmtogeklVYoIoRcDEC0xwNNps3r+N E79gDtWc8/Rd9zmiZprO+XM0F5uU7tJ8aCS5TYKUPte554j2de45mj2d2yGBSdHXNEq3ZoMY sZZ3jf+v30xUUwVyXG+43KCsb6hXjjWdTMam3cA2goJ+4M6HsS+7Qo5WqtfUhQF117QZ+4ZG 4NgODoTFIswBeK5C5PcDpVTO1Qj49hTlFGKQOMDWSRqDKXxKiTkY2gQpTgiYDIWLAikglHEF Bb4RAMyA6nAdJGkGZnKDhjEN5ictQZfrtmIFv9FdOgalW8ABjebpQkDFO5rxles9QOB1+F+f CXJqlb1611WUSZykhv/UQxqTejRYB9H8NAUfx5ZBmsIHWQGEE5WTgUPkknAmpnGj2jpnWJQq KDMpHLDp4IChF0nKIzIECW5c1oQAqIkj72U+Dw8OjhpkOGY7Ml+i75lTcg+G4gGp/gV6A46U ezlYxGTpekmM0R4fATZmG9oXy5nopmPpGvn8mXTa7cKCQ/1kNDSc6+mob+p9CzGHaUuBv9Dn kNGXkfDkk0LCOJq30hZ0BhppkVPyy4FSPIfbnWm1Ch0UIxjRR1KxSGIUeftluZYlCS6slQor aTUFj94iv/9SCBD9yBrisLQHZX7szGmKRfHMdzeH/5m2sPiIk5HPBLufnqRrh3Ph/cZn0PoL L82w+JQXIt2/CmEHsZeGwvEHGGqwamcVRax1e+BcqJaOQ4evPqx0Md2tBuCVbg+NCyGlkpT8 hbSb0NY+dKcJPTF1SbCD7zb3ZdTA+l0TFC1VA/asdXCQblYUl1BhXzgCSa908d6rGB9egGbH W7gJRBYg+QRiHGFIynXPTRus915V86WKoJXgEbkvQ0BYgQksaoYR7z2YbTFJ5SjsO8c0RmBp jf/WlcMPR51296wySLNW3T2T9bLRi9I08bVO86xP2KC6Quj2tYPrnbPqvD9r12qG6p0ztKdQ 0TkrFJ5XGCNecd6uF08HsJBUy3YuDFtpP7U71WX6t+nwYszJPoLa5t3NrRxE+0EMrmwDkXAI uZSIinmk9okMxrefXbaJvEUSR8fk2ri6/px/1lYjSA50eewAgdLeKUU6pZO37IYwc0tYsDg1 ydNp+lSZoJqYSF+3NNNRB8bVSDk/q02vWGVc0jz0I/a4P65bCPCbsL7AtnB1F+YBvG1LaTdg LH0EC1IfvYwbXNq6VYeBUb6EjoBlIcs04wnkMmOQMfqQekckfozILIs8nm019hBWO84QMPWO MSAI9jW+BTteNwPFCm/CogyPMJMADxIsK7LE2eAMbsAqD3WTrELX4wuskh1m4KRDggzqCQpZ QFhB7mMoAX7g0GEV+AfbQ5WcwfZ3OqTQeFk1HPd1U7WN8ShHdbaptyHOQB9d2dckt9Lcn3by lG63dVjA2kBXR9NJ3kT3JYhsQpEtKLwFaGkZwBihIUZE5ooi6Vf0MqFzN/ExgqiFE7PEBZfN BYjpueeGXgY5Olbx7wX1HjCDqIpOwz44sM51c6hqzrWughQcWBq2o/b7Jjl/AWmZmgC+iIQy ++tEJ4R0n0eS8jkkhy90sAX2/5cD8upnD798GC3ybfjJwbZI66BxsPYUzS0a6JLVWbMEEare IdSx7L6Adt5Xwqo9YG6ZESwMcwN6hIt4uxf7RP6/EnQ53C2JjC8v0ZQYk52px6exI/up4WVi ju2xpP64i7S1HApvmpW30znfhU77ORTeSuh5Y++rzf47JLlnoFvC5GWO0cce77Lp/ChfwMgk dCZCfPNSIz9+bBPwL1ZKIYNkbwFRsw8FVxDZLtdzUnIFwKkxIWC8wD0lkJv4YqeYpm4Q5rYM /DbfhzLvqo75z+0nnTbEfeZTH3j3e9ghDDYSnnrRapiGdDU8BILrGC1lSGWyrJgXGuSMSRxW 8jeah2Gyqpbu3WDaaj75HI/vDS0fh/Ej8R/jxK+TYtg5iB9rTclkVPX95Jg8Q3cdzBf7CRdQ 20B5iZ7CSt20RslLCRZnjOzQYDIEdcsVp+H5H8NPcDvxktwNMdevwr2VlS2ZAIPmwAfpQpKW v3ca0MA+SeskvKhGKEoEOUx0vmOQi35nz+DJb054hzCZOynvIIiyp7eExTyzl6KUme+Oqtmg OnZF1Yqod5+u2c26Ztd0zc65vKRsdlXZGtp+jbZtN/Z6dWumfJW+FaQ1hbvdUTiuE+MZk0oK OdoaTEqpCePZjMEs5TSd81KPGnRoF3ab1GB8z227B3mzHBnFqdhZR5Bd6p69R/fsb6Z7gJwy kZDSJMlWUB+kTITPtCxlQJ0lHlq9ecCQ797t9jwJEiG9Yf5kKYeHhoVvjnULcRD5p9hQwUKz 41y2hJ3/J//u8u8K4s4qIBxxp/LvGqK7hcDvigOzJrpmqINKX65vHd00WzmF0dUg21L7X+tN 63c2FF8VMAitjZEtWyphE9UBP2bedVoCln93Ww0wewtmb8PA3HWqEhmMvjjW15HmDDutOqzb DOu26vLVtuSbf28LWdsSckFXl7S2JWmtKmmc46FqfXl+xi9qPapPL3TwolXVha1eXlSbL1Sj 6PRFq6IkWz2vk3brpN2StFsnLXVlW1lepSqvUpRXqckzSlJqw6vm/lUz/0fn/fpWl3OP8jBN Z2h9aaEHo5F7Dz4JjxWvb0mQ/Coith2v16frEdinvn7jQAJR3VWTNb/nBg+6tUpiz/GDxKHg xDbkCL97BwoYrFoUiXvlo6ShAvg1lg/TrKF0uupx4w2hCMGDBw037ghpdN3YJN+Uw2OPXs1J YxWO4hm3Lnb60LZ7eITnAKsVeHcEmFDFvUEF7ibUJUu6jFEG0sHgidhNI82JwN+DU8QjjBPC TwmrTgccC5JcU1c4HnzBLRb7qdKzOtaGGFy4O3h5ATtJ6Hp7CAz31FZQEcQZC8Uw+MmPpMEz QU7zBpnzSw98zgV/tgoiPEUAQfEhI8UAvjkFeNjAxU2dmsj40TfdEvL1I8YZwnXeL7PCzzEu IyAo+8XPXyKfihOYAN9IlC3vwSni2Q3O8SFPfGCJ7ovwTKkm5q6amNtq0pBoNGmJ+Se0pEpD eKr1kp7IwNjcoydmde7r2B09eQbbpCdzkEGE4czFcNqoL+Yf1BfzT+iLbOgSUtFBAEuXk4X4 xjNSEVvx8AmH9n+pYqf1nbyIUl+myWVot4x9mojbM6+4N1Gx7fr40lHBq91xa3hYicOEp6iG Xdt01tc6nbVNZ+3SoR8BKmc8GnzldNU+tJCuyryJ2KwQ18NMUsQWDWTWJCerBo3NnTPv5KC2 Opz3r9qPPW3lLGqN5b18HQv7NSzs/SyAO9Rak1ewMO9atW0hiHBwc9sZjUeVfT75dBqAlq3a hrYF7DYA+19H6nAbeVZtWxt8cS5N/Sc85dMtQ26jvX/XxR3MNloytoBlQpNPUHjS6b4nw+vf tjagCh5fp1/Go7yZHz808PjxQ41HvcvFUbDT1y/V6cCWA0MmDYPTR+rFQEcaTR/Z6hXK7j1v LpjxPBdW+fv2f+RxU63LhYAMa4dJwQOybMnCD9h+HsbEwpMvPGlSR1diBt+19wCnk0kNeNbm m78NUdwmMpJfh7FvRLOYkL4xBD6X497BHsTvlVNRPHjHoA2MO24D3bjh1pkpkbXWhg1icD3N tZjQIv2eajtO3VDW78SLkly4RTSVTbHjfTKBcBO9ggD2ik1X4Vnr/NCYt80nA5yQlrKXsZ0/ gG3bf4BvBYshwMV4PChAMB1/y1iqc53ze7wMtGlYeox/4NGg0EmfbCg7jWK+FHZDaPeJT27K JjSxqNerVtZ52gvwe4s49HPX9yyj6WpFE+F2OSP+XfG+oGvkVYwGuEAqjPh3A6MDRWpkhRN7 EMorh9ArxgTFNiwGckjnJ+St/WQ+vZUuR4ZcNXn3A7YK3Q1uUbFCQHivBgty8W4/TYzULI2t 4DcZwZWMTMrP9GEoP/AriSSOTuPZrGS0LSQQD4wCh2DxI/WeZCRUQtTKwfmbyF0G3tuWEBK/ ETMsD1mQDTbJ9y+52rB4SYnoxr6IGGcmTZYKN6W2OexV9m8g8RoMxho6JrwnIJ7O3qtm+REt L1Q127jRK8eyong0tvOaduX+zjd8+F13GPB97CZ+eaGWnOYX6vkGLO7mFXV4JVbh1yf5GQde YIZI0k1T11scfqQtfr6BEW1Rh0cgoo5fJEeObhCJO7xvcXX4ECd79C3e+JUXfhfAJKTsmMxC d85wT9Z7YISm3sknfhGhmBFMdsUFuivdGBm2cmVEgQhfwQlgpJnPntRLvFkFsWu0lCj8Jj5e gKvjbiYQ669XvkDBSxPop6k+1RV+91Dg+Ku44pFjrm9tDKsl4BrkzK+hc+XjV/Nwe7vOFhRV s80BHjoIquLy+nNURldTFKPrCRL4guA9pGsXOlTpOs6uJMAjX0Up4320KqqM8sXlgxypWdOh omgsW5bI/EB9C4oX7pTKRT2E4h3dKqyS31gQB0zcdFGkNyO8Ox9i6Efyi3f5tOGSm2q201dt leAMWnxEIisqBgfJF14WQeVCzA/8cmORtPCeoWWUSVH0IAbC0w6kzffUS/SIylOZUZHcRFDE UQfyehYIPr5wmbxPWew/IzOAu3ItFXwvcLkN6JqKZDPENw70UkyiF49Ccw/bP3RbIj9buImi 9Pk6gVH//KH9d06Zc8bfUvA7EPGS62p1H5+v1UtYR5wCFxQKB5evvJoCE873zVl1u37lBQ6s S+Vo4gV9mejOikwTJQUI1MRZMCds5Xr1wwNBZYjEG5FijZOgdiYAaDyG7+s3hqYrR4D5uSsG tipPBiRlRdmFNPDXQj+/k4KQd/wjPFLZ30B5uZbPPOqI4M7IIdfpkLooyFY1j77IZuKqLJ+p /PprUjtw5KLLXYtsG5TEEdwdxh0m/zfXu+yJvEU1gjLyQ/CWV4LSBF4lw5bZtUiv8bYxLAxh qWvZNvdvFWUw1aG8oIdj4saIVbSLZ+aV8f2EgGKEcgeGH/TwtSvHWdo0ue9lPU+Hd9lOSPq0 S6g+T+juUuYbDqDdAfO0OIvEol+JgizOmFi/HlaBBMrmQPmHWZgGgojHCjDrSyzyXJbWyQoq TlJpqNzWABcM041GfqjlQQo+AMp3SKTc+c0uMVtV0OHS3ZB7Cg2jrQI/h/vNnhu1ynFe3+Y/ XOvVXEYiSyuj4zOKcXMv34iTk8xPpOszDQEmIuVN53JInIL7csSz6lTxxAHig2K/7k39zicj 6L7Tp3IjSerU6wiTkrC6SciJh3S5farIfzi0tWGIbfpL15HEBW1/qApyzSDwXuxe4XglXbF3 ycVU+TERhi3NG5lywxxFg6L8Ge/t44VSVbP+jpbrIN8rRRnsICBarF+u1dh4xjoNLrW4vCYn e5eq+wqq3BZzgpfxRdgOFAjhy5QLUXhIWoltWFy2UQur+8laAyMaZSsRXaOIY8mAXyjFKBam vHb7BfjkKXjBp5p/F+tWBDIQ1nB1BcaYBOVTOY7CjVh5lKVb+5T8bKT46sePUf6tLYIVuGlM KfhYiSwgM8gegCHmAEQsX4iVSRuv9ePPDxne2xQQlq1QhUpQB0Ffswe8stkIOd2XFRRzlv+O RKxw6QMYmB/03rzsr0ol0xIElxBMaWkSVuZaRoor8XtWltM0hlMXrveQreTeL3+vhFXcNO/E VNuJ3q3LjNl0VVd7kaIhgzFMvxZCR/CHf2EuV5QZSgEHeJ+xjViAI0Mr60+L9IffRZe/8QCu 27+L49rwPzcdg66ePAAA --tThc/1wpZn/ma/RB-- From herbert@gondor.apana.org.au Sun Jul 4 14:41:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 14:41:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64LfKgi002169 for ; Sun, 4 Jul 2004 14:41:22 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BhEij-00056z-00; Mon, 05 Jul 2004 07:40:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BhEid-0000Ce-00; Mon, 05 Jul 2004 07:40:15 +1000 Date: Mon, 5 Jul 2004 07:40:15 +1000 To: Ken Bantoft Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com, dev@lists.openswan.org Subject: Re: [Openswan dev] Proposal for dealing with ICMP black holes for IPsec Message-ID: <20040704214015.GC671@gondor.apana.org.au> References: <20040703004320.GA28139@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1449 Lines: 34 On Sun, Jul 04, 2004 at 02:37:36PM +0200, Ken Bantoft wrote: > > Interesting idea - tcp/500 connection (or maybe it should be port 4500, to > deal with NAT boxes. I assume you want to do this as early as possible, > eg: Phase 1, however until we have a PH2 we can't do a secure TCP, only > authenticated. Encrypting it is not very useful since the information we're tryint to convey is public anyway. Authenticating it is useful to a certain extent. What we're trying to prevent is for an attacker to lower our MTU unnecessarily. However there are limits to what we can do since the information we're trying to obatin can only be there through modification of the TCP header. So the easiest thing to do would be to verify the MSS obtained in this way by sending a packet of mtu(MSS) + 1 bytes and checking whether it arrives. We'll also be repeating this process periodically (once every ten minutes) as long as the tunnel is not idle, so even if we do get an incorrect MTU it is not fatal. I should also point out that if the attacker can inject packets into the network and our firewalls are configured properly, then it is rather trivial for them to lower the path MTU anyway by sending us a need-to-frag packet. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ahu@outpost.ds9a.nl Sun Jul 4 14:41:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 14:41:34 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64LfUgi002178 for ; Sun, 4 Jul 2004 14:41:31 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 82C394016; Sun, 4 Jul 2004 23:41:27 +0200 (CEST) Date: Sun, 4 Jul 2004 23:41:27 +0200 From: bert hubert To: netdev@oss.sgi.com Subject: [alessandro.suardi@oracle.com: TCP window scaling still bad in 2.6.7-bk17] Message-ID: <20040704214127.GA24721@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 6584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1788 Lines: 59 Probably worth looking at: ----- Forwarded message from Alessandro Suardi ----- Date: Sun, 04 Jul 2004 23:11:19 +0200 From: Alessandro Suardi To: linux-kernel Subject: TCP window scaling still bad in 2.6.7-bk17 X-Mailing-List: linux-kernel@vger.kernel.org I have a tcpdump and a description of what happens here http://xoomer.virgilio.it/incident/tcpdump.out with www.kernel.org, but I'm mostly shut off the entire 'net. The _only_ site I found I can browse without disabling TCP window scaling is http://www.google.it. My system: RedHat 9 base distro 2.6.7-bk17 plus ACX100 out-of-kernel wireless driver (version 0.2.0-pre8_plus_fixes_13) from acx100.sf.net built with binutils 2.15.91.0.1 and GCC 3.4.0 System behaved properly until 2.6.7-bk1, was bad since 2.6.7-bk7 (haven't tried in-between kernels as I was on holiday). I also tried walking up to my router and connecting via eth0 instead of wlan0 (to rule out the wireless driver) - still the connection to www.kernel.org hangs (always -bk17). I'm available for further digging, please CC: me on replies as I only read lkml from the USSG archives. Thanks, --alessandro "Practice is more important than theory. A _lot_ more important." (Linus Torvalds on lkml, 1 June 2004) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ----- End forwarded message ----- -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From vandrove@vc.cvut.cz Sun Jul 4 14:41:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 14:41:58 -0700 (PDT) Received: from vana.vc.cvut.cz (vana.vc.cvut.cz [147.32.240.58]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64Lfsgi002258 for ; Sun, 4 Jul 2004 14:41:55 -0700 Received: from vana.vc.cvut.cz (localhost [127.0.0.1]) by vana.vc.cvut.cz (8.12.11/8.12.11/Debian-5) with ESMTP id i64Lfqk9009599; Sun, 4 Jul 2004 23:41:52 +0200 Received: (from root@localhost) by vana.vc.cvut.cz (8.12.11/8.12.11/Debian-5) id i64Lfqxl009596; Sun, 4 Jul 2004 23:41:52 +0200 Date: Sun, 4 Jul 2004 23:41:52 +0200 From: Petr Vandrovec To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] vlan code accesses released memory Message-ID: <20040704214152.GB7300@vana.vc.cvut.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-archive-position: 6585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vandrove@vc.cvut.cz Precedence: bulk X-list: netdev Content-Length: 1589 Lines: 45 Hi Dave, today I was experimenting with vlans, and I have noticed small problem with shutting down vlan interface with attached multicast addresses: it in its vlan_flush_mc_list() it first issues dev_mc_delete on list entry, and then it prints that entry to log. But dev_mc_delete can release memory which was used for multicast entry, and so in better case bogus MAC address is printed, in worse case kernel oopses (when built with PAGE_ALLOC debugging). Patch below is for 2.6.7, but 2.4.x seems to need it too. Best regards, Petr Vandrovec Before: eth0.22: del 01:00:5e:00:00:01 mcast address from master interface eth0.22: del 6b:6b:6b:6b:6b:6b mcast address from vlan interface After: eth0.22: del 01:00:5e:00:00:01 mcast address from vlan interface eth0.22: del 01:00:5e:00:00:01 mcast address from master interface Signed-off-by: Petr Vandrovec diff -urN linux/net/8021q/vlan_dev.c linux/net/8021q/vlan_dev.c --- linux/net/8021q/vlan_dev.c 2004-07-02 21:11:49.000000000 +0200 +++ linux/net/8021q/vlan_dev.c 2004-07-04 16:42:40.000000000 +0200 @@ -727,7 +727,6 @@ struct dev_mc_list *dmi = dev->mc_list; while (dmi) { - dev_mc_delete(dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); printk(KERN_DEBUG "%s: del %.2x:%.2x:%.2x:%.2x:%.2x:%.2x mcast address from vlan interface\n", dev->name, dmi->dmi_addr[0], @@ -736,6 +735,7 @@ dmi->dmi_addr[3], dmi->dmi_addr[4], dmi->dmi_addr[5]); + dev_mc_delete(dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); dmi = dev->mc_list; } From SRS0+de6832d9ed3192f84f29+315+infradead.org+hch@pentafluge-230446.srs.infradead.org Sun Jul 4 15:04:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 15:04:51 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64M4kgi003553 for ; Sun, 4 Jul 2004 15:04:48 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1BhF6M-0002LR-2f; Sun, 04 Jul 2004 23:04:46 +0100 Date: Sun, 4 Jul 2004 23:04:46 +0100 From: Christoph Hellwig To: Bernd Schubert Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.7: sk98lin unload oops Message-ID: <20040704220446.GA9010@infradead.org> Mail-Followup-To: Christoph Hellwig , Bernd Schubert , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <200407041342.18821.bernd-schubert@web.de> <200407042028.59047.bernd-schubert@web.de> <20040704184404.GA7262@infradead.org> <200407050001.46489.bernd-schubert@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407050001.46489.bernd-schubert@web.de> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 1096 Lines: 24 On Mon, Jul 05, 2004 at 12:01:35AM +0200, Bernd Schubert wrote: > [from your other mail] > > the previous one) makes it work unless you change the interface name > > manually, but as Linux explicitly allows that the interface is > > fundamentally broken and probably should just go away. > > Unfortunality we rename all interfaces using ifrename to make sure that the > interface names won't change with different kernel versions (we have this > problem when we switch between 2.4. and 2.6.). So it is normal that the oops > occurs on unloading the modules? Well, the problem is that someone smoked bad crack when designing the sk98lin procfs interface ;-) We should probably just kill it and find a better way to export the information if nessecary. I'll take a look at that. > Btw, on 22th June I got another skge.c patch from Herbert Xu to fix another > oops: > > http://lkml.org/lkml/2004/6/22/44 > > This patch applies fine on top of your new versions (with 400 lines offset), > maybe this patch should also be included into the current BK tree? Jeff already merged that patch. From bernd-schubert@web.de Sun Jul 4 15:04:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 15:04:58 -0700 (PDT) Received: from mailgate4.cinetic.de (mailgate4.cinetic.de [217.72.192.167]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i64M4tgi003560 for ; Sun, 4 Jul 2004 15:04:55 -0700 Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by mailgate4.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with ESMTP id i64M4nS25853 for ; Mon, 5 Jul 2004 00:04:49 +0200 Received: from [80.140.14.225] (helo=bathl.lan.fli4l) by smtp08.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1BhF3M-0002o0-00; Mon, 05 Jul 2004 00:01:40 +0200 From: Bernd Schubert To: Christoph Hellwig , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.7: sk98lin unload oops Date: Mon, 5 Jul 2004 00:01:35 +0200 User-Agent: KMail/1.6.2 References: <200407041342.18821.bernd-schubert@web.de> <200407042028.59047.bernd-schubert@web.de> <20040704184404.GA7262@infradead.org> In-Reply-To: <20040704184404.GA7262@infradead.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200407050001.46489.bernd-schubert@web.de> X-archive-position: 6587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd-schubert@web.de Precedence: bulk X-list: netdev Content-Length: 945 Lines: 28 > Sorry, it's for Linus' current BK tree. I've attached three files that > you should be able to just copy over your regular 2.6.7 tree: Thanks, this driver compiles fine. [from your other mail] > the previous one) makes it work unless you change the interface name > manually, but as Linux explicitly allows that the interface is > fundamentally broken and probably should just go away. Unfortunality we rename all interfaces using ifrename to make sure that the interface names won't change with different kernel versions (we have this problem when we switch between 2.4. and 2.6.). So it is normal that the oops occurs on unloading the modules? Btw, on 22th June I got another skge.c patch from Herbert Xu to fix another oops: http://lkml.org/lkml/2004/6/22/44 This patch applies fine on top of your new versions (with 400 lines offset), maybe this patch should also be included into the current BK tree? Thanks a lot, Bernd From yoshfuji@linux-ipv6.org Sun Jul 4 20:32:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 20:32:13 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i653W7gi016376 for ; Sun, 4 Jul 2004 20:32:07 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 5013D33CE5; Mon, 5 Jul 2004 12:33:22 +0900 (JST) Date: Mon, 05 Jul 2004 12:33:21 +0900 (JST) Message-Id: <20040705.123321.91002396.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: rmk+lkml@arm.linux.org.uk, netdev@oss.sgi.com Subject: Re: 2.6.6: IPv6 initialisation bug From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040704170259.A16596@flint.arm.linux.org.uk> References: <20040628184758.C9214@flint.arm.linux.org.uk> <20040629.095903.58985982.yoshfuji@linux-ipv6.org> <20040704170259.A16596@flint.arm.linux.org.uk> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2445 Lines: 62 In article <20040704170259.A16596@flint.arm.linux.org.uk> (at Sun, 4 Jul 2004 17:02:59 +0100), Russell King says: > On Tue, Jun 29, 2004 at 09:59:03AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > > In article <20040628184758.C9214@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 18:47:58 +0100), Russell King says: > > > On Tue, Jun 29, 2004 at 02:06:27AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > > > > In article <20040628010200.A15067@flint.arm.linux.org.uk> (at Mon, 28 Jun 2004 01:02:01 +0100), Russell King says: > > > > > > > > > Ok, I've just tried 2.6.7 out on my root-NFS'd firewall with IPv6 built > > > > > in, and it doesn't work because of the problem I described below. > > > > : > > > > > What's the solution? > > > > > > > > Bring lo up before bring others up. > > > > What does prevent you from doing this? > > > > (Do we need some bits to do this automatically?) > > > > > > When you use root-NFS, the kernel itself brings up the interfaces, > > > and IPv6 immediately comes in and tries to configure itself to them, > > > trying to create the routes. > > > > > > Unfortunately, the kernel doesn't bring up lo first because it > > > doesn't know to do that. > > > > Okay, would you try the following patch, please? > > This does appear to fix the problem. Thanks. David, please apply. --------------- [IPV6] Bring lo up before setting other interface up. IPv6 was not configured appropriately without lo. Noticed by / tested by Russell King . Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/ipconfig.c 1.39 vs edited ===== --- 1.39/net/ipv4/ipconfig.c 2004-07-01 07:26:09 +09:00 +++ edited/net/ipv4/ipconfig.c 2004-07-05 12:22:27 +09:00 @@ -183,7 +183,14 @@ last = &ic_first_dev; rtnl_shlock(); + + /* bring loopback device up first */ + if (dev_change_flags(&loopback_dev, loopback_dev.flags | IFF_UP) < 0) + printk(KERN_ERR "IP-Config: Failed to open %s\n", loopback_dev.name); + for (dev = dev_base; dev; dev = dev->next) { + if (dev == &loopback_dev) + continue; if (user_dev_name[0] ? !strcmp(dev->name, user_dev_name) : (!(dev->flags & IFF_LOOPBACK) && (dev->flags & (IFF_POINTOPOINT|IFF_BROADCAST)) && -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ahu@outpost.ds9a.nl Sun Jul 4 22:35:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jul 2004 22:35:08 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i655Z4gi019201 for ; Sun, 4 Jul 2004 22:35:07 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 392B54427; Mon, 5 Jul 2004 07:35:04 +0200 (CEST) Date: Mon, 5 Jul 2004 07:35:04 +0200 From: bert hubert To: Phy Prabab Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [still problems] Re: Slow internet access for 2.6.7bk15&16 Message-ID: <20040705053504.GA2602@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Phy Prabab , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040704165743.GD18688@outpost.ds9a.nl> <20040704232852.58634.qmail@web51802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040704232852.58634.qmail@web51802.mail.yahoo.com> User-Agent: Mutt/1.3.28i X-archive-position: 6591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1949 Lines: 63 On Sun, Jul 04, 2004 at 04:28:52PM -0700, Phy Prabab wrote: > Okay, so, I checked the latest bk (17) and found that > the fix indicated by the below link has already made > it in and still I see the slow down in ftp transfers > in comparison to 2.6.6 and 2.4.x kernels. Any > suggestions? I've forwarded your message to netdev@oss.sgi.com, but see also http://groups.google.com/groups?selm=2emz3-6GV-5%40gated-at.bofh.it&output=gplain Good luck! > > Dual Opteron > Broadcom Ge > using tg3 > > Thanks! > Phy > --- bert hubert wrote: > > On Sat, Jul 03, 2004 at 07:41:12PM -0700, Phy Prabab > > wrote: > > > Heelo, > > > > > > I have been watching a thread concerning the slow > > down > > > with accessing some websites but have not found a > > > resolution to the issue. > > > > Probably fixed by > > > http://linus.bkbits.net:8080/linux-2.5/cset@40e47ae2tQ_PIxw_HStw3YgsdJFHow?nav=index.html|ChangeSet@-4d > > > > -- > > http://www.PowerDNS.com Open source, database > > driven DNS Software > > http://lartc.org Linux Advanced Routing & > > Traffic Control HOWTO > > - > > To unsubscribe from this list: send the line > > "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From nakam@linux-ipv6.org Mon Jul 5 00:05:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 00:05:24 -0700 (PDT) Received: from localhost (galaxy.linux-ipv6.org [203.178.140.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6575Ggi022881 for ; Mon, 5 Jul 2004 00:05:17 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1BhNXE-0000WR-00; Mon, 05 Jul 2004 16:05:04 +0900 Date: Mon, 5 Jul 2004 16:05:00 +0900 From: Masahide NAKAMURA To: Herbert Xu , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-Id: <20040705160500.208591b5@localhost> In-Reply-To: <20040703094632.GA14235@gondor.apana.org.au> References: <20040703094632.GA14235@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1154 Lines: 39 Hello, On Sat, 3 Jul 2004 19:46:32 +1000 Herbert Xu wrote: > I'm in the process of writing two new modules fo ip(8), ippolicy and > ipstate which will be a NETLINK based replacement for setkey. > > In order to do so, I need to get libnetlink to speak the XFRM protocol. > Thus I've added a new nl_open function which allows the protocol to > be specified. I agree with it. Anyway, I have code for ip(8) for similar reason. The patch is below: http://www.linux-ipv6.org/~nakam/ipxfrm-20040705.diff Can you take a look at it, Stephen and Herbert? I'm in the process of writing Mobile IPv6 with extended xfrm, so I'm interested in extending "ip(8) which can handle xfrm". About "nl_open", my code is not the same for Herbert's one actually, but similar change is in it (and Herberts' one is also welcome for me). My patch is: - Checking SA's algorithm is not implemented yet - Command line option is `ip xfrm policy` and `ip xfrm state`. - defined "USE_MIP6" for Mobile IPv6. (please ignore MIPv6 now...) # I can prepare cleaner patch (e.g. removing Mobile IPV6 part), if you want. Regards, -- Masahide NAKAMURA From yoshfuji@linux-ipv6.org Mon Jul 5 00:27:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 00:27:49 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i657RNgi027231 for ; Mon, 5 Jul 2004 00:27:24 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id CD40433CE5; Mon, 5 Jul 2004 16:28:38 +0900 (JST) Date: Mon, 05 Jul 2004 16:28:38 +0900 (JST) Message-Id: <20040705.162838.67048785.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] [IPV6] fix flags for ndisc dst From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1227 Lines: 38 Hello. Because RTF_LOCAL is for local unicast address, it was wrong to set RTF_LOCAL to ndisc dst. This patch also adds some comment on other fields. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/route.c 1.76 vs edited ===== --- 1.76/net/ipv6/route.c 2004-06-13 02:51:53 +09:00 +++ edited/net/ipv6/route.c 2004-07-05 16:24:14 +09:00 @@ -605,14 +605,19 @@ rt->rt6i_dev = dev; rt->rt6i_idev = in6_dev_get(dev); rt->rt6i_nexthop = neigh; - rt->rt6i_expires = 0; - rt->rt6i_flags = RTF_LOCAL; - rt->rt6i_metric = 0; atomic_set(&rt->u.dst.__refcnt, 1); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = 255; rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.output = output; + +#if 0 /* there's no chance to use these for ndisc */ + rt->u.dst.flags = ipv6_addr_type(addr) & IPV6_ADDR_UNICAST + ? DST_HOST + : 0; + ipv6_addr_copy(&rt->rt6i_dst.addr, addr); + rt->rt6i_dst.plen = 128; +#endif write_lock_bh(&rt6_lock); rt->u.dst.next = ndisc_dst_gc_list; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Mon Jul 5 00:59:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 00:59:42 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i657xYgi028253 for ; Mon, 5 Jul 2004 00:59:37 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4F1EE33CE5; Mon, 5 Jul 2004 17:00:50 +0900 (JST) Date: Mon, 05 Jul 2004 17:00:50 +0900 (JST) Message-Id: <20040705.170050.44266970.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] TCP: inline message From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 564 Lines: 24 Hello. D: [TCP] Diet using "unknown time value" message in net/ipv4/tcp_timer.c. Signed-off-by: Hideaki YOSHIFUJI Thanks. ===== include/net/tcp.h 1.78 vs edited ===== --- 1.78/include/net/tcp.h 2004-06-24 14:01:03 +09:00 +++ edited/include/net/tcp.h 2004-07-05 16:39:04 +09:00 @@ -1036,7 +1036,7 @@ break; default: - printk(KERN_DEBUG "bug: unknown timer value\n"); + printk(timer_bug_msg); }; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Mon Jul 5 00:59:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 00:59:41 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i657xbgi028254 for ; Mon, 5 Jul 2004 00:59:38 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 44D5B33CE6; Mon, 5 Jul 2004 17:00:53 +0900 (JST) Date: Mon, 05 Jul 2004 17:00:53 +0900 (JST) Message-Id: <20040705.170053.22377235.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] NET: save space for dst underflow message From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1446 Lines: 53 Hello. Save space for "dst underflow" message. Signed-off-by: Hideaki YOSHIFUJI ===== include/net/dst.h 1.19 vs edited ===== --- 1.19/include/net/dst.h 2004-06-24 17:55:48 +09:00 +++ edited/include/net/dst.h 2004-07-05 16:44:17 +09:00 @@ -142,15 +142,14 @@ return dst; } +extern const char dst_underflow_bug_msg[]; + static inline void dst_release(struct dst_entry * dst) { if (dst) { - if (atomic_read(&dst->__refcnt) < 1) { - printk("BUG: dst underflow %d: %p\n", - atomic_read(&dst->__refcnt), - current_text_addr()); - } + if (atomic_read(&dst->__refcnt) < 1) + printk(dst_underflow_bug_msg, dst, current_text_addr()); atomic_dec(&dst->__refcnt); } } ===== net/core/dst.c 1.20 vs edited ===== --- 1.20/net/core/dst.c 2004-06-18 04:09:54 +09:00 +++ edited/net/core/dst.c 2004-07-05 16:43:13 +09:00 @@ -19,6 +19,8 @@ #include +const char dst_underflow_bug_msg[] = KERN_DEBUG "BUG: dst underflow %d: %p at %p\n"; + /* Locking strategy: * 1) Garbage collection state of dead destination cache * entries is protected by dst_lock. @@ -273,6 +275,7 @@ register_netdevice_notifier(&dst_dev_notifier); } +EXPORT_SYMBOL(dst_underflow_bug_msg); EXPORT_SYMBOL(__dst_free); EXPORT_SYMBOL(dst_alloc); EXPORT_SYMBOL(dst_destroy); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Mon Jul 5 01:08:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 01:08:22 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6588Egi028958 for ; Mon, 5 Jul 2004 01:08:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BhOW8-0007oM-00; Mon, 05 Jul 2004 18:08:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BhOVV-00011A-00; Mon, 05 Jul 2004 18:07:21 +1000 Date: Mon, 5 Jul 2004 18:07:06 +1000 To: Masahide NAKAMURA Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-ID: <20040705080706.GA3902@gondor.apana.org.au> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040705160500.208591b5@localhost> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 542 Lines: 16 On Mon, Jul 05, 2004 at 04:05:00PM +0900, Masahide NAKAMURA wrote: > > Anyway, I have code for ip(8) for similar reason. > The patch is below: > http://www.linux-ipv6.org/~nakam/ipxfrm-20040705.diff > > Can you take a look at it, Stephen and Herbert? Excellent. That'll save me a lot of work :) I'll have a look at it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hch@lst.de Mon Jul 5 03:53:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 03:53:32 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65ArSgi004460 for ; Mon, 5 Jul 2004 03:53:30 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i65ArHQc030296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 5 Jul 2004 12:53:17 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i65ArHYL030294; Mon, 5 Jul 2004 12:53:17 +0200 Date: Mon, 5 Jul 2004 12:53:17 +0200 From: Christoph Hellwig To: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] more DECLARE_MUTEX() in headers crap Message-ID: <20040705105317.GA30269@lst.de> References: <20040620112328.GB13691@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040620112328.GB13691@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 2250 Lines: 64 On Sun, Jun 20, 2004 at 01:23:28PM +0200, Christoph Hellwig wrote: > okay, the gunk we had in arp_tables is in ip6_tables and ip6_tables, > too. In fact those three files seem to be 80% copy & paste of each > other.. ping --- 1.8/include/linux/netfilter_ipv4/ip_tables.h 2004-06-19 20:55:10 +02:00 +++ edited/include/linux/netfilter_ipv4/ip_tables.h 2004-06-20 10:25:40 +02:00 @@ -284,8 +284,6 @@ struct ipt_entry entrytable[0]; }; -extern struct semaphore ipt_mutex; - /* Standard return verdict, or do jump. */ #define IPT_STANDARD_TARGET "" /* Error verdict. */ @@ -338,7 +336,6 @@ * Main firewall chains definitions and global var's definitions. */ #ifdef __KERNEL__ -static DECLARE_MUTEX(ipt_mutex); #include extern void ipt_init(void) __init; ===== include/linux/netfilter_ipv6/ip6_tables.h 1.7 vs edited ===== --- 1.7/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-19 20:55:10 +02:00 +++ edited/include/linux/netfilter_ipv6/ip6_tables.h 2004-06-20 10:26:32 +02:00 @@ -107,10 +107,6 @@ u_int64_t pcnt, bcnt; /* Packet and byte counters */ }; -#ifdef __KERNEL__ -static DECLARE_MUTEX(ip6t_mutex); -#endif - /* Values for "flag" field in struct ip6t_ip6 (general ip6 structure). */ #define IP6T_F_PROTO 0x01 /* Set if rule cares about upper protocols */ ===== net/ipv4/netfilter/ip_tables.c 1.24 vs edited ===== --- 1.24/net/ipv4/netfilter/ip_tables.c 2004-06-07 05:15:04 +02:00 +++ edited/net/ipv4/netfilter/ip_tables.c 2004-06-20 12:29:17 +02:00 @@ -61,6 +61,8 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) +static DECLARE_MUTEX(ipt_mutex); + /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) #define ASSERT_WRITE_LOCK(x) IP_NF_ASSERT(down_trylock(&ipt_mutex) != 0) ===== net/ipv6/netfilter/ip6_tables.c 1.29 vs edited ===== --- 1.29/net/ipv6/netfilter/ip6_tables.c 2004-06-07 05:15:04 +02:00 +++ edited/net/ipv6/netfilter/ip6_tables.c 2004-06-20 12:29:29 +02:00 @@ -66,6 +66,7 @@ #endif #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) +static DECLARE_MUTEX(ip6t_mutex); /* Must have mutex */ #define ASSERT_READ_LOCK(x) IP_NF_ASSERT(down_trylock(&ip6t_mutex) != 0) From meissner@suse.de Mon Jul 5 04:09:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 04:10:06 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65B9tgi005626 for ; Mon, 5 Jul 2004 04:09:56 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 9A6EE84BBF8 for ; Mon, 5 Jul 2004 13:09:49 +0200 (CEST) Date: Mon, 5 Jul 2004 13:09:49 +0200 From: Marcus Meissner To: netdev@oss.sgi.com Subject: [patch] do not readlock all buckets in /proc/net/tcp Message-ID: <20040705110949.GA1092@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 6604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: meissner@suse.de Precedence: bulk X-list: netdev Content-Length: 1955 Lines: 66 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, This patch makes the files /proc/net/tcp and /proc/net/tcp6 not acquire the readlock for every bucket. On ppc64 and ia64 the readlocks are so expensive, that reading /proc/net/tcp takes 0.25 seconds on a usual p670 LPAR. And it locks 65536 buckets where just 20 chains are used at all in a normal non-netserver setup. Ciao, Marcus Changelog: Readlock only non-empty hash chains to avoid 65536 readlocks. Signed-Off-By: Marcus Meissner --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=tcp-proc-walk --- linux-2.6.5/net/ipv4/tcp_ipv4.c.xx 2004-07-04 13:39:51.000000000 +0200 +++ linux-2.6.5/net/ipv4/tcp_ipv4.c 2004-07-04 13:51:57.000000000 +0200 @@ -2255,6 +2255,12 @@ struct hlist_node *node; struct tcp_tw_bucket *tw; + /* Avoid taking the readlock cost if we know the chain is empty, + * we have a lot of buckets. + */ + if (hlist_empty(&tcp_ehash[st->bucket].chain) && + hlist_empty(&tcp_ehash[st->bucket+tcp_ehash_size].chain)) + continue; read_lock(&tcp_ehash[st->bucket].lock); sk_for_each(sk, node, &tcp_ehash[st->bucket].chain) { if (sk->sk_family != st->family) { @@ -2301,13 +2307,17 @@ } read_unlock(&tcp_ehash[st->bucket].lock); st->state = TCP_SEQ_STATE_ESTABLISHED; - if (++st->bucket < tcp_ehash_size) { - read_lock(&tcp_ehash[st->bucket].lock); - sk = sk_head(&tcp_ehash[st->bucket].chain); - } else { + + while ((++st->bucket < tcp_ehash_size) && + hlist_empty(&tcp_ehash[st->bucket].chain) && + hlist_empty(&tcp_ehash[st->bucket+tcp_ehash_size].chain)) + /*empty*/; + if (st->bucket >= tcp_ehash_size) { cur = NULL; goto out; } + read_lock(&tcp_ehash[st->bucket].lock); + sk = sk_head(&tcp_ehash[st->bucket].chain); } else sk = sk_next(sk); --ew6BAiZeqk4r7MaW-- From herbert@gondor.apana.org.au Mon Jul 5 04:28:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 04:28:38 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65BSSgi009410 for ; Mon, 5 Jul 2004 04:28:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BhRds-0000Vo-00; Mon, 05 Jul 2004 21:28:12 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BhRda-0001Rs-00; Mon, 05 Jul 2004 21:27:54 +1000 From: Herbert Xu To: meissner@suse.de (Marcus Meissner) Subject: Re: [patch] do not readlock all buckets in /proc/net/tcp Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20040705110949.GA1092@suse.de> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Mon, 05 Jul 2004 21:27:54 +1000 X-archive-position: 6605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 648 Lines: 17 Marcus Meissner wrote: > > This patch makes the files /proc/net/tcp and /proc/net/tcp6 not acquire > the readlock for every bucket. > > On ppc64 and ia64 the readlocks are so expensive, that reading /proc/net/tcp > takes 0.25 seconds on a usual p670 LPAR. > > And it locks 65536 buckets where just 20 chains are used at all in a normal > non-netserver setup. Why not use NETLINK+TCP_DIAG instead? It's much faster. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Jul 5 05:07:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 05:07:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65C75gi010772 for ; Mon, 5 Jul 2004 05:07:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BhSFO-0000iV-00; Mon, 05 Jul 2004 22:06:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BhSEr-0001X0-00; Mon, 05 Jul 2004 22:06:25 +1000 Date: Mon, 5 Jul 2004 22:06:10 +1000 To: Marcus Meissner Cc: netdev@oss.sgi.com Subject: Re: [patch] do not readlock all buckets in /proc/net/tcp Message-ID: <20040705120610.GA5728@gondor.apana.org.au> References: <20040705110949.GA1092@suse.de> <20040705113555.GA28665@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040705113555.GA28665@suse.de> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 469 Lines: 14 On Mon, Jul 05, 2004 at 01:35:55PM +0200, Marcus Meissner wrote: > > Oh, and NETLINK+TCP_DIAG seems to have the same readlock contention problem, > see tcpdiag_dump(). Then you wouldn't mind adding this optimisation for tcp_diag as well, right? :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From meissner@suse.de Mon Jul 5 05:15:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 05:15:05 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65CEogi011386 for ; Mon, 5 Jul 2004 05:14:51 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id BEAC084C69F; Mon, 5 Jul 2004 13:35:55 +0200 (CEST) Date: Mon, 5 Jul 2004 13:35:55 +0200 From: Marcus Meissner To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [patch] do not readlock all buckets in /proc/net/tcp Message-ID: <20040705113555.GA28665@suse.de> References: <20040705110949.GA1092@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-archive-position: 6608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: meissner@suse.de Precedence: bulk X-list: netdev Content-Length: 692 Lines: 20 On Mon, Jul 05, 2004 at 09:27:54PM +1000, Herbert Xu wrote: > Marcus Meissner wrote: > > > > This patch makes the files /proc/net/tcp and /proc/net/tcp6 not acquire > > the readlock for every bucket. > > > > On ppc64 and ia64 the readlocks are so expensive, that reading /proc/net/tcp > > takes 0.25 seconds on a usual p670 LPAR. > > > > And it locks 65536 buckets where just 20 chains are used at all in a normal > > non-netserver setup. > > Why not use NETLINK+TCP_DIAG instead? It's much faster. Not sure if you want / can fix all proprietary software. Oh, and NETLINK+TCP_DIAG seems to have the same readlock contention problem, see tcpdiag_dump(). Ciao, Marcus From yoshfuji@linux-ipv6.org Mon Jul 5 05:24:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 05:24:20 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65CO8gi011775 for ; Mon, 5 Jul 2004 05:24:09 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 2D3A733CE5; Mon, 5 Jul 2004 21:25:24 +0900 (JST) Date: Mon, 05 Jul 2004 21:25:22 +0900 (JST) Message-Id: <20040705.212522.126409437.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au, meissner@suse.de Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [patch] do not readlock all buckets in /proc/net/tcp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040705120610.GA5728@gondor.apana.org.au> References: <20040705113555.GA28665@suse.de> <20040705120610.GA5728@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1108 Lines: 37 In article <20040705120610.GA5728@gondor.apana.org.au> (at Mon, 5 Jul 2004 22:06:10 +1000), Herbert Xu says: > On Mon, Jul 05, 2004 at 01:35:55PM +0200, Marcus Meissner wrote: > > > > Oh, and NETLINK+TCP_DIAG seems to have the same readlock contention problem, > > see tcpdiag_dump(). > > Then you wouldn't mind adding this optimisation for tcp_diag as well, > right? :) here it is. :-) Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/tcp_diag.c 1.15 vs edited ===== --- 1.15/net/ipv4/tcp_diag.c 2004-06-08 07:27:58 +09:00 +++ edited/net/ipv4/tcp_diag.c 2004-07-05 21:18:17 +09:00 @@ -522,9 +522,13 @@ if (i > s_i) s_num = 0; - read_lock_bh(&head->lock); - num = 0; + + if (hlist_empty(&head->chain) && + (!(r->tcpdiag_states&TCPF_TIME_WAIT) || hlist_empty(&head->chain))) + continue; + + read_lock_bh(&head->lock); sk_for_each(sk, node, &head->chain) { struct inet_opt *inet = inet_sk(sk); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Mon Jul 5 06:24:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 06:24:09 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65DO5gi013175 for ; Mon, 5 Jul 2004 06:24:06 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 560F133CE5; Mon, 5 Jul 2004 22:25:21 +0900 (JST) Date: Mon, 05 Jul 2004 22:25:13 +0900 (JST) Message-Id: <20040705.222513.81999836.yoshfuji@linux-ipv6.org> To: meissner@suse.de Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [patch] do not readlock all buckets in /proc/net/tcp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040705124511.GA17193@suse.de> References: <20040705120610.GA5728@gondor.apana.org.au> <20040705.212522.126409437.yoshfuji@linux-ipv6.org> <20040705124511.GA17193@suse.de> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 977 Lines: 33 In article <20040705124511.GA17193@suse.de> (at Mon, 5 Jul 2004 14:45:11 +0200), Marcus Meissner says: > The second hlist_empty is bad, you should be checking &tcp_ehash[i + > tcp_ehash_size].chain ((head+tcp_ehash_size) I think). Oops... Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/tcp_diag.c 1.15 vs edited ===== --- 1.15/net/ipv4/tcp_diag.c 2004-06-08 07:27:58 +09:00 +++ edited/net/ipv4/tcp_diag.c 2004-07-05 22:21:06 +09:00 @@ -522,9 +522,14 @@ if (i > s_i) s_num = 0; - read_lock_bh(&head->lock); - num = 0; + + if (hlist_empty(&head->chain) && + (!(r->tcpdiag_states&TCPF_TIME_WAIT) || + hlist_empty(&(head + tcp_ehash_size)->chain))) + continue; + + read_lock_bh(&head->lock); sk_for_each(sk, node, &head->chain) { struct inet_opt *inet = inet_sk(sk); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From meissner@suse.de Mon Jul 5 06:38:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 06:38:17 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65Dc4gi013678 for ; Mon, 5 Jul 2004 06:38:05 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id BE7E684B7AA; Mon, 5 Jul 2004 14:45:11 +0200 (CEST) Date: Mon, 5 Jul 2004 14:45:11 +0200 From: Marcus Meissner To: YOSHIFUJI Hideaki / =?utf-8?B?5ZCJ6Jek6Iux5piO?= Cc: netdev@oss.sgi.com Subject: Re: [patch] do not readlock all buckets in /proc/net/tcp Message-ID: <20040705124511.GA17193@suse.de> References: <20040705113555.GA28665@suse.de> <20040705120610.GA5728@gondor.apana.org.au> <20040705.212522.126409437.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20040705.212522.126409437.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i65Dc4gi013678 X-archive-position: 6611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: meissner@suse.de Precedence: bulk X-list: netdev Content-Length: 1147 Lines: 36 On Mon, Jul 05, 2004 at 09:25:22PM +0900, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article <20040705120610.GA5728@gondor.apana.org.au> (at Mon, 5 Jul 2004 22:06:10 +1000), Herbert Xu says: > > > On Mon, Jul 05, 2004 at 01:35:55PM +0200, Marcus Meissner wrote: > > > > > > Oh, and NETLINK+TCP_DIAG seems to have the same readlock contention problem, > > > see tcpdiag_dump(). > > > > Then you wouldn't mind adding this optimisation for tcp_diag as well, > > right? :) > > here it is. :-) > > Signed-off-by: Hideaki YOSHIFUJI > > ===== net/ipv4/tcp_diag.c 1.15 vs edited ===== > --- 1.15/net/ipv4/tcp_diag.c 2004-06-08 07:27:58 +09:00 > +++ edited/net/ipv4/tcp_diag.c 2004-07-05 21:18:17 +09:00 > @@ -522,9 +522,13 @@ > if (i > s_i) > s_num = 0; > > - read_lock_bh(&head->lock); > - > num = 0; > + > + if (hlist_empty(&head->chain) && > + (!(r->tcpdiag_states&TCPF_TIME_WAIT) || hlist_empty(&head->chain))) > + continue; The second hlist_empty is bad, you should be checking &tcp_ehash[i + tcp_ehash_size].chain ((head+tcp_ehash_size) I think). Ciao, Marcus From jgarzik@pobox.com Mon Jul 5 10:28:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 10:29:03 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65HSggi022821 for ; Mon, 5 Jul 2004 10:28:43 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BhXGf-0008Qh-56; Mon, 05 Jul 2004 18:28:40 +0100 Message-ID: <40E98FB8.4070900@pobox.com> Date: Mon, 05 Jul 2004 13:28:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kumar Gala , Netdev CC: David Woodhouse , jamal Subject: [RFR] gianfar ethernet driver References: <8F52CF1D-C916-11D8-BB6A-000393DBC2E8@freescale.com> In-Reply-To: <8F52CF1D-C916-11D8-BB6A-000393DBC2E8@freescale.com> Content-Type: multipart/mixed; boundary="------------050005000108000809040404" X-archive-position: 6615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 116050 Lines: 3887 This is a multi-part message in MIME format. --------------050005000108000809040404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (CC to netdev added) Kumar, I've merged the gianfar driver into my netdev-2.6 queue. This will get it automatically propagated into the -mm tree, and once some of these comments are resolved/discussed, pushed upstream as well. Follow-up patches should be incremental to this (your) patch. Others, I've attached the patch as Kumar submitted it. Please review. Comments: 1) Share the knowledge. Please CC comments (and criticisms!) to netdev. 2) I'm strongly pondering vetoing try_fastroute() code in this driver. Surely this should be in core net stack code... if it isn't already? Jamal? 3) delete this +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,41) +#define irqreturn_t void +#define IRQ_HANDLED +#endif 4) static? const? +#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.0, " +char gfar_driver_name[] = "Gianfar Ethernet"; +char gfar_driver_version[] = "1.0"; 5) Probably want to define DRV_NAME like the other drivers do. It's used in data bus, i/o region reservation, and ethtool ioctls at least. 6) sysfs support: call SET_NETDEV_DEV() 7) ethtool_ops should not be kmalloc'd. + dev_ethtool_ops = + (struct ethtool_ops *)kmalloc(sizeof(struct ethtool_ops), + GFP_KERNEL); 8) I recommend enabling _both_ hardware interrupt coalescing and NAPI, at the same time. Several other Linux net drivers need to be changed to do this, as well 9) in startup_gfar() you kmalloc() then dma-map the descriptors. don't bother -- just alloc consistent/coherent DMA memory. 10) recommend assigning a constant for your phy timer interval + init_timer(&priv->phy_info_timer); + priv->phy_info_timer.function = &gfar_phy_timer; + priv->phy_info_timer.data = (unsigned long) dev; + mod_timer(&priv->phy_info_timer, jiffies + 2 * HZ); rather than open-coding it. 11) this is ugly. do the casting on the other end, in the work function: + /* Set up the bottom half queue */ + INIT_WORK(&priv->tq, (void (*)(void *))gfar_phy_change, dev); 12) the above "bottom half" comment, or the code's intent, is incorrect. bottom halves more closely map to tasklet. however, slow-path phy manipulation certainly lends itself to process context workqueues. 13) use of a wait queue rxcleanupq is fairly questionable. 14) surely gfar_set_mac_address() needs some sort of synchronization? 15) gfar_change_mtu() synchronization appears absent? 16) in gfar_timeout(), proper behavior is to call netif_wake_queue() unconditionally, if you are assured that your stop/startup_gfar() cleared the TX queue (including dropping any pending skbs). 17) some drivers choose to simply schedule_work() when dev->tx_timeout() is fired, to move the error handling/reset tasks to process context. 18) As Jamal recently noted, no need to test netif_queue_stopped() 19) I think your gfar_poll() needs spin_lock_irqsave(), not spin_lock(). 20) You should ALWAYS have a work limit, NAPI or no. Otherwise under heavy load the non-NAPI driver will be doing nothing but sitting (shitting?) in your driver's interrupt handler. +#ifdef CONFIG_GFAR_NAPI +#define GFAR_RXDONE() ((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0)) +#else +#define GFAR_RXDONE() (bdp->status & RXBD_EMPTY) +#endif 21) a la #12, buggy comment: + /* Schedule the bottom half */ + schedule_work(&priv->tq); 22) use msleep() + /* Delay to give the PHY a chance to change the + * register state */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(timeout); 23) gfar_set_multi() does not appear to take into account huge multi-cast lists. Drivers usually handle large dev->mc_count by falling back to ALLMULTI behavior. 24) setting IFF_MULTICAST is suspicious at best, possibly wrong: + dev->mtu = 1500; + dev->set_multicast_list = gfar_set_multi; + dev->flags |= IFF_MULTICAST; + 25) kill this +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,41) +#include +#else +#include +#define work_struct tq_struct +#define schedule_work schedule_task +#endif 26) stat_gstrings[] are _not_ human-readable strings, but easily machine-parseable keys. For example, "tx&rx 1024-1518B frames" should be "tx-rx-1024-1518-frames" or somesuch. Kill spaces, punctuation, capital letters, etc. Make it look more like a C identifier. 27) as mentioned in #4/#5, the following is incorrect. The driver name is not an advertisement, it is the short Unix name associated with this driver. +void gfar_gdrvinfo(struct net_device *dev, struct + ethtool_drvinfo *drvinfo) +{ + strncpy(drvinfo->driver, gfar_driver_name, GFAR_INFOSTR_LEN); + strncpy(drvinfo->version, gfar_driver_version, GFAR_INFOSTR_LEN); 28) I see you support register dump (good!), now please send the register-pretty-print patch to the ethtool package :) 29) kill gfar_get_link(). you use netif_carrier_{on,off} (good!), so you should use the default ethtool_op_get_link() 30) use include/linux/mii.h where possible. Add GMII-related defines if necessary. 31) infinite loops, particularly on 1-bits, are discouraged: + /* Wait for the transaction to finish */ + while (gfar_read(®base->miimind) & (MIIMIND_NOTVALID | MIIMIND_BUSY)) + cpu_relax(); 32) gianfar_phy.c needs to be netdev_priv()-ized like the other parts of the driver 33) merge-stopper: mii_parse_sr(). never wait for autonegotiation to complete. it is an asynchronous operation that could exceed 30 seconds. 34) merge-stopper: dm9161_wait(). same thing as #33. 35) liberally borrow code and ideas from Ben H's sungem_phy.c. Eventually we want to move to a generic phy module. --------------050005000108000809040404 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2004-06-28 10:16:57 -05:00 +++ b/drivers/net/Kconfig 2004-06-28 10:16:57 -05:00 @@ -2111,6 +2111,17 @@ To compile this driver as a module, choose M here: the module will be called tg3. This is recommended. +config GIANFAR + tristate "Gianfar Ethernet" + depends on 85xx + help + This driver supports the Gigabit TSEC on the MPC85xx + family of chips, and the FEC on the 8540 + +config GFAR_NAPI + bool "NAPI Support" + depends on GIANFAR + endmenu # diff -Nru a/drivers/net/Makefile b/drivers/net/Makefile --- a/drivers/net/Makefile 2004-06-28 10:16:57 -05:00 +++ b/drivers/net/Makefile 2004-06-28 10:16:57 -05:00 @@ -10,6 +10,7 @@ obj-$(CONFIG_IBM_EMAC) += ibm_emac/ obj-$(CONFIG_IXGB) += ixgb/ obj-$(CONFIG_BONDING) += bonding/ +obj-$(CONFIG_GIANFAR) += gianfar.o gianfar_ethtool.o gianfar_phy.o # # link order important here diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/gianfar.c 2004-06-28 10:16:57 -05:00 @@ -0,0 +1,1921 @@ +/* + * drivers/net/gianfar.c + * + * Gianfar Ethernet Driver + * Driver for FEC on MPC8540 and TSEC on MPC8540/MPC8560 + * Based on 8260_io/fcc_enet.c + * + * Author: Andy Fleming + * Maintainer: Kumar Gala (kumar.gala@freescale.com) + * + * Copyright 2004 Freescale Semiconductor, Inc + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * Gianfar: AKA Lambda Draconis, "Dragon" + * RA 11 31 24.2 + * Dec +69 19 52 + * V 3.84 + * B-V +1.62 + * + * Theory of operation + * This driver is designed for the Triple-speed Ethernet + * controllers on the Freescale 8540/8560 integrated processors, + * as well as the Fast Ethernet Controller on the 8540. + * + * The driver is initialized through OCP. Structures which + * define the configuration needed by the board are defined in a + * board structure in arch/ppc/platforms (though I do not + * discount the possibility that other architectures could one + * day be supported. One assumption the driver currently makes + * is that the PHY is configured in such a way to advertise all + * capabilities. This is a sensible default, and on certain + * PHYs, changing this default encounters substantial errata + * issues. Future versions may remove this requirement, but for + * now, it is best for the firmware to ensure this is the case. + * + * The Gianfar Ethernet Controller uses a ring of buffer + * descriptors. The beginning is indicated by a register + * pointing to the physical address of the start of the ring. + * The end is determined by a "wrap" bit being set in the + * last descriptor of the ring. + * + * When a packet is received, the RXF bit in the + * IEVENT register is set, triggering an interrupt when the + * corresponding bit in the IMASK register is also set (if + * interrupt coalescing is active, then the interrupt may not + * happen immediately, but will wait until either a set number + * of frames or amount of time have passed.). In NAPI, the + * interrupt handler will signal there is work to be done, and + * exit. Without NAPI, the packet(s) will be handled + * immediately. Both methods will start at the last known empty + * descriptor, and process every subsequent descriptor until there + * are none left with data (NAPI will stop after a set number of + * packets to give time to other tasks, but will eventually + * process all the packets). The data arrives inside a + * pre-allocated skb, and so after the skb is passed up to the + * stack, a new skb must be allocated, and the address field in + * the buffer descriptor must be updated to indicate this new + * skb. + * + * When the kernel requests that a packet be transmitted, the + * driver starts where it left off last time, and points the + * descriptor at the buffer which was passed in. The driver + * then informs the DMA engine that there are packets ready to + * be transmitted. Once the controller is finished transmitting + * the packet, an interrupt may be triggered (under the same + * conditions as for reception, but depending on the TXF bit). + * The driver then cleans up the buffer. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "gianfar.h" +#include "gianfar_phy.h" +#ifdef CONFIG_NET_FASTROUTE +#include +#include +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,41) +#define irqreturn_t void +#define IRQ_HANDLED +#endif + +#define TX_TIMEOUT (1*HZ) +#define SKB_ALLOC_TIMEOUT 1000000 +#undef BRIEF_GFAR_ERRORS +#undef VERBOSE_GFAR_ERRORS + +#ifdef CONFIG_GFAR_NAPI +#define RECEIVE(x) netif_receive_skb(x) +#else +#define RECEIVE(x) netif_rx(x) +#endif + +#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.0, " +char gfar_driver_name[] = "Gianfar Ethernet"; +char gfar_driver_version[] = "1.0"; + +int startup_gfar(struct net_device *dev); +static int gfar_enet_open(struct net_device *dev); +static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev); +static void gfar_timeout(struct net_device *dev); +static int gfar_close(struct net_device *dev); +struct sk_buff *gfar_new_skb(struct net_device *dev, struct rxbd8 *bdp); +static struct net_device_stats *gfar_get_stats(struct net_device *dev); +static int gfar_set_mac_address(struct net_device *dev); +static int gfar_change_mtu(struct net_device *dev, int new_mtu); +static irqreturn_t gfar_error(int irq, void *dev_id, struct pt_regs *regs); +static irqreturn_t gfar_transmit(int irq, void *dev_id, struct pt_regs *regs); +irqreturn_t gfar_receive(int irq, void *dev_id, struct pt_regs *regs); +static irqreturn_t gfar_interrupt(int irq, void *dev_id, struct pt_regs *regs); +static irqreturn_t phy_interrupt(int irq, void *dev_id, struct pt_regs *regs); +static void gfar_phy_change(void *data); +static void gfar_phy_timer(unsigned long data); +static void adjust_link(struct net_device *dev); +static void init_registers(struct net_device *dev); +static int init_phy(struct net_device *dev); +static int gfar_probe(struct ocp_device *ocpdev); +static void gfar_remove(struct ocp_device *ocpdev); +void free_skb_resources(struct gfar_private *priv); +static void gfar_set_multi(struct net_device *dev); +static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr); +#ifdef CONFIG_GFAR_NAPI +static int gfar_poll(struct net_device *dev, int *budget); +#endif +#ifdef CONFIG_NET_FASTROUTE +static int gfar_accept_fastpath(struct net_device *dev, struct dst_entry *dst); +#endif +static inline int try_fastroute(struct sk_buff *skb, struct net_device *dev, int length); +#ifdef CONFIG_GFAR_NAPI +static int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit); +#else +static int gfar_clean_rx_ring(struct net_device *dev); +#endif +static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb, int length); + +extern struct ethtool_ops gfar_ethtool_ops; +extern void gfar_gstrings_normon(struct net_device *dev, u32 stringset, + u8 * buf); +extern void gfar_fill_stats_normon(struct net_device *dev, + struct ethtool_stats *dummy, u64 * buf); +extern int gfar_stats_count_normon(struct net_device *dev); + + +MODULE_AUTHOR("Freescale Semiconductor, Inc"); +MODULE_DESCRIPTION("Gianfar Ethernet Driver"); +MODULE_LICENSE("GPL"); + +/* Called by the ocp code to initialize device data structures + * required for bringing up the device + * returns 0 on success */ +static int gfar_probe(struct ocp_device *ocpdev) +{ + u32 tempval; + struct ocp_device *mdiodev; + struct net_device *dev = NULL; + struct gfar_private *priv = NULL; + struct ocp_gfar_data *einfo; + int idx; + int err = 0; + struct ethtool_ops *dev_ethtool_ops; + + einfo = (struct ocp_gfar_data *) ocpdev->def->additions; + + if (einfo == NULL) { + printk(KERN_ERR "gfar %d: Missing additional data!\n", + ocpdev->def->index); + + return -ENODEV; + } + + /* get a pointer to the register memory which can + * configure the PHYs. If it's different from this set, + * get the device which has those regs */ + if ((einfo->phyregidx >= 0) && (einfo->phyregidx != ocpdev->def->index)) { + mdiodev = ocp_find_device(OCP_ANY_ID, + OCP_FUNC_GFAR, einfo->phyregidx); + + /* If the device which holds the MDIO regs isn't + * up, wait for it to come up */ + if (mdiodev == NULL) + return -EAGAIN; + } else { + mdiodev = ocpdev; + } + + /* Create an ethernet device instance */ + dev = alloc_etherdev(sizeof (*priv)); + + if (dev == NULL) + return -ENOMEM; + + priv = netdev_priv(dev); + + /* Set the info in the priv to the current info */ + priv->einfo = einfo; + + /* get a pointer to the register memory */ + priv->regs = (struct gfar *) + ioremap(ocpdev->def->paddr, sizeof (struct gfar)); + + if (priv->regs == NULL) { + err = -ENOMEM; + goto regs_fail; + } + + /* Set the PHY base address */ + priv->phyregs = (struct gfar *) + ioremap(mdiodev->def->paddr, sizeof (struct gfar)); + + if (priv->phyregs == NULL) { + err = -ENOMEM; + goto phy_regs_fail; + } + + ocp_set_drvdata(ocpdev, dev); + + /* Stop the DMA engine now, in case it was running before */ + /* (The firmware could have used it, and left it running). */ + /* To do this, we write Graceful Receive Stop and Graceful */ + /* Transmit Stop, and then wait until the corresponding bits */ + /* in IEVENT indicate the stops have completed. */ + tempval = gfar_read(&priv->regs->dmactrl); + tempval &= ~(DMACTRL_GRS | DMACTRL_GTS); + gfar_write(&priv->regs->dmactrl, tempval); + + tempval = gfar_read(&priv->regs->dmactrl); + tempval |= (DMACTRL_GRS | DMACTRL_GTS); + gfar_write(&priv->regs->dmactrl, tempval); + + while (!(gfar_read(&priv->regs->ievent) & (IEVENT_GRSC | IEVENT_GTSC))) + cpu_relax(); + + /* Reset MAC layer */ + gfar_write(&priv->regs->maccfg1, MACCFG1_SOFT_RESET); + + tempval = (MACCFG1_TX_FLOW | MACCFG1_RX_FLOW); + gfar_write(&priv->regs->maccfg1, tempval); + + /* Initialize MACCFG2. */ + gfar_write(&priv->regs->maccfg2, MACCFG2_INIT_SETTINGS); + + /* Initialize ECNTRL */ + gfar_write(&priv->regs->ecntrl, ECNTRL_INIT_SETTINGS); + + /* Copy the station address into the dev structure, */ + /* and into the address registers MAC_STNADDR1,2. */ + /* Backwards, because little endian MACs are dumb. */ + /* Don't set the regs if the firmware already did */ + memcpy(dev->dev_addr, einfo->mac_addr, MAC_ADDR_LEN); + + /* Set the dev->base_addr to the gfar reg region */ + dev->base_addr = (unsigned long) (priv->regs); + + SET_MODULE_OWNER(dev); + + /* Fill in the dev structure */ + dev->open = gfar_enet_open; + dev->hard_start_xmit = gfar_start_xmit; + dev->tx_timeout = gfar_timeout; + dev->watchdog_timeo = TX_TIMEOUT; +#ifdef CONFIG_GFAR_NAPI + dev->poll = gfar_poll; + dev->weight = GFAR_DEV_WEIGHT; +#endif + dev->stop = gfar_close; + dev->get_stats = gfar_get_stats; + dev->change_mtu = gfar_change_mtu; + dev->mtu = 1500; + dev->set_multicast_list = gfar_set_multi; + dev->flags |= IFF_MULTICAST; + + dev_ethtool_ops = + (struct ethtool_ops *)kmalloc(sizeof(struct ethtool_ops), + GFP_KERNEL); + + if(dev_ethtool_ops == NULL) { + err = -ENOMEM; + goto ethtool_fail; + } + + memcpy(dev_ethtool_ops, &gfar_ethtool_ops, sizeof(gfar_ethtool_ops)); + + /* If there is no RMON support in this device, we don't + * want to expose non-existant statistics */ + if((priv->einfo->flags & GFAR_HAS_RMON) == 0) { + dev_ethtool_ops->get_strings = gfar_gstrings_normon; + dev_ethtool_ops->get_stats_count = gfar_stats_count_normon; + dev_ethtool_ops->get_ethtool_stats = gfar_fill_stats_normon; + } + + if((priv->einfo->flags & GFAR_HAS_COALESCE) == 0) { + dev_ethtool_ops->set_coalesce = NULL; + dev_ethtool_ops->get_coalesce = NULL; + } + + dev->ethtool_ops = dev_ethtool_ops; + +#ifdef CONFIG_NET_FASTROUTE + dev->accept_fastpath = gfar_accept_fastpath; +#endif + + priv->rx_buffer_size = DEFAULT_RX_BUFFER_SIZE; +#ifdef CONFIG_GFAR_BUFSTASH + priv->rx_stash_size = STASH_LENGTH; +#endif + priv->tx_ring_size = DEFAULT_TX_RING_SIZE; + priv->rx_ring_size = DEFAULT_RX_RING_SIZE; + + /* Initially, coalescing is disabled */ + priv->txcoalescing = 0; + priv->txcount = 0; + priv->txtime = 0; + priv->rxcoalescing = 0; + priv->rxcount = 0; + priv->rxtime = 0; + + err = register_netdev(dev); + + if (err) { + printk(KERN_ERR "%s: Cannot register net device, aborting.\n", + dev->name); + goto register_fail; + } + + /* Print out the device info */ + printk(DEVICE_NAME, dev->name); + for (idx = 0; idx < 6; idx++) + printk("%2.2x%c", dev->dev_addr[idx], idx == 5 ? ' ' : ':'); + printk("\n"); + + /* Even more device info helps when determining which kernel */ + /* provided which set of benchmarks. Since this is global for all */ + /* devices, we only print it once */ +#ifdef CONFIG_GFAR_NAPI + printk(KERN_INFO "%s: Running with NAPI enabled\n", dev->name); +#else + printk(KERN_INFO "%s: Running with NAPI disabled\n", dev->name); +#endif + printk(KERN_INFO "%s: %d/%d RX/TX BD ring size\n", + dev->name, priv->rx_ring_size, priv->tx_ring_size); + + return 0; + + +register_fail: + kfree(dev_ethtool_ops); +ethtool_fail: + iounmap((void *) priv->phyregs); +phy_regs_fail: + iounmap((void *) priv->regs); +regs_fail: + free_netdev(dev); + return -ENOMEM; +} + +static void gfar_remove(struct ocp_device *ocpdev) +{ + struct net_device *dev = ocp_get_drvdata(ocpdev); + struct gfar_private *priv = netdev_priv(dev); + + ocp_set_drvdata(ocpdev, NULL); + + kfree(dev->ethtool_ops); + iounmap((void *) priv->regs); + iounmap((void *) priv->phyregs); + free_netdev(dev); +} + +/* Configure the PHY for dev. + * returns 0 if success. -1 if failure + */ +static int init_phy(struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + struct phy_info *curphy; + + priv->link = 1; + priv->oldlink = 0; + priv->oldspeed = 0; + priv->olddplx = -1; + + /* get info for this PHY */ + curphy = get_phy_info(dev); + + if (curphy == NULL) { + printk(KERN_ERR "%s: No PHY found\n", dev->name); + return -1; + } + + priv->phyinfo = curphy; + + /* Run the commands which configure the PHY */ + phy_run_commands(dev, curphy->config); + + return 0; +} + +static void init_registers(struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + + /* Clear IEVENT */ + gfar_write(&priv->regs->ievent, IEVENT_INIT_CLEAR); + + /* Initialize IMASK */ + gfar_write(&priv->regs->imask, IMASK_INIT_CLEAR); + + /* Init hash registers to zero */ + gfar_write(&priv->regs->iaddr0, 0); + gfar_write(&priv->regs->iaddr1, 0); + gfar_write(&priv->regs->iaddr2, 0); + gfar_write(&priv->regs->iaddr3, 0); + gfar_write(&priv->regs->iaddr4, 0); + gfar_write(&priv->regs->iaddr5, 0); + gfar_write(&priv->regs->iaddr6, 0); + gfar_write(&priv->regs->iaddr7, 0); + + gfar_write(&priv->regs->gaddr0, 0); + gfar_write(&priv->regs->gaddr1, 0); + gfar_write(&priv->regs->gaddr2, 0); + gfar_write(&priv->regs->gaddr3, 0); + gfar_write(&priv->regs->gaddr4, 0); + gfar_write(&priv->regs->gaddr5, 0); + gfar_write(&priv->regs->gaddr6, 0); + gfar_write(&priv->regs->gaddr7, 0); + + /* Zero out rctrl */ + gfar_write(&priv->regs->rctrl, 0x00000000); + + /* Zero out the rmon mib registers if it has them */ + if (priv->einfo->flags & GFAR_HAS_RMON) { + memset((void *) &(priv->regs->rmon), 0, + sizeof (struct rmon_mib)); + + /* Mask off the CAM interrupts */ + gfar_write(&priv->regs->rmon.cam1, 0xffffffff); + gfar_write(&priv->regs->rmon.cam2, 0xffffffff); + } + + /* Initialize the max receive buffer length */ + gfar_write(&priv->regs->mrblr, priv->rx_buffer_size); + +#ifdef CONFIG_GFAR_BUFSTASH + /* If we are stashing buffers, we need to set the + * extraction length to the size of the buffer */ + gfar_write(&priv->regs->attreli, priv->rx_stash_size << 16); +#endif + + /* Initialize the Minimum Frame Length Register */ + gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS); + + /* Setup Attributes so that snooping is on for rx */ + gfar_write(&priv->regs->attr, ATTR_INIT_SETTINGS); + gfar_write(&priv->regs->attreli, ATTRELI_INIT_SETTINGS); + + /* Assign the TBI an address which won't conflict with the PHYs */ + gfar_write(&priv->regs->tbipa, TBIPA_VALUE); +} + +void stop_gfar(struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + struct gfar *regs = priv->regs; + unsigned long flags; + u32 tempval; + + /* Lock it down */ + spin_lock_irqsave(&priv->lock, flags); + + /* Tell the kernel the link is down */ + priv->link = 0; + adjust_link(dev); + + /* Mask all interrupts */ + gfar_write(®s->imask, IMASK_INIT_CLEAR); + + /* Clear all interrupts */ + gfar_write(®s->ievent, IEVENT_INIT_CLEAR); + + /* Stop the DMA, and wait for it to stop */ + tempval = gfar_read(&priv->regs->dmactrl); + if ((tempval & (DMACTRL_GRS | DMACTRL_GTS)) + != (DMACTRL_GRS | DMACTRL_GTS)) { + tempval |= (DMACTRL_GRS | DMACTRL_GTS); + gfar_write(&priv->regs->dmactrl, tempval); + + while (!(gfar_read(&priv->regs->ievent) & + (IEVENT_GRSC | IEVENT_GTSC))) + cpu_relax(); + } + + /* Disable Rx and Tx */ + tempval = gfar_read(®s->maccfg1); + tempval &= ~(MACCFG1_RX_EN | MACCFG1_TX_EN); + gfar_write(®s->maccfg1, tempval); + + if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { + phy_run_commands(dev, priv->phyinfo->shutdown); + } + + spin_unlock_irqrestore(&priv->lock, flags); + + /* Free the IRQs */ + if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) { + free_irq(priv->einfo->interruptError, dev); + free_irq(priv->einfo->interruptTransmit, dev); + free_irq(priv->einfo->interruptReceive, dev); + } else { + free_irq(priv->einfo->interruptTransmit, dev); + } + + if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { + free_irq(priv->einfo->interruptPHY, dev); + } else { + del_timer_sync(&priv->phy_info_timer); + } + + free_skb_resources(priv); + + dma_unmap_single(NULL, gfar_read(®s->tbase), + sizeof(struct txbd)*priv->tx_ring_size, + DMA_BIDIRECTIONAL); + dma_unmap_single(NULL, gfar_read(®s->rbase), + sizeof(struct rxbd)*priv->rx_ring_size, + DMA_BIDIRECTIONAL); + + /* Free the buffer descriptors */ + kfree(priv->tx_bd_base); +} + +/* If there are any tx skbs or rx skbs still around, free them. + * Then free tx_skbuff and rx_skbuff */ +void free_skb_resources(struct gfar_private *priv) +{ + struct rxbd8 *rxbdp; + struct txbd8 *txbdp; + int i; + + /* Go through all the buffer descriptors and free their data buffers */ + txbdp = priv->tx_bd_base; + + for (i = 0; i < priv->tx_ring_size; i++) { + + if (priv->tx_skbuff[i]) { + dma_unmap_single(NULL, txbdp->bufPtr, + txbdp->length, + DMA_TO_DEVICE); + dev_kfree_skb_any(priv->tx_skbuff[i]); + priv->tx_skbuff[i] = NULL; + } + } + + kfree(priv->tx_skbuff); + + rxbdp = priv->rx_bd_base; + + /* rx_skbuff is not guaranteed to be allocated, so only + * free it and its contents if it is allocated */ + if(priv->rx_skbuff != NULL) { + for (i = 0; i < priv->rx_ring_size; i++) { + if (priv->rx_skbuff[i]) { + dma_unmap_single(NULL, rxbdp->bufPtr, + priv->rx_buffer_size + + RXBUF_ALIGNMENT, + DMA_FROM_DEVICE); + + dev_kfree_skb_any(priv->rx_skbuff[i]); + priv->rx_skbuff[i] = NULL; + } + + rxbdp->status = 0; + rxbdp->length = 0; + rxbdp->bufPtr = 0; + + rxbdp++; + } + + kfree(priv->rx_skbuff); + } +} + +/* Bring the controller up and running */ +int startup_gfar(struct net_device *dev) +{ + struct txbd8 *txbdp; + struct rxbd8 *rxbdp; + unsigned long addr; + int i; + struct gfar_private *priv = netdev_priv(dev); + struct gfar *regs = priv->regs; + u32 tempval; + int err = 0; + + gfar_write(®s->imask, IMASK_INIT_CLEAR); + + /* Allocate memory for the buffer descriptors */ + addr = + (unsigned int) kmalloc(sizeof (struct txbd8) * priv->tx_ring_size + + sizeof (struct rxbd8) * priv->rx_ring_size, + GFP_KERNEL); + + if (addr == 0) { + printk(KERN_ERR "%s: Could not allocate buffer descriptors!\n", + dev->name); + return -ENOMEM; + } + + priv->tx_bd_base = (struct txbd8 *) addr; + + /* enet DMA only understands physical addresses */ + gfar_write(®s->tbase, + dma_map_single(NULL, (void *)addr, + sizeof(struct txbd8) * priv->tx_ring_size, + DMA_BIDIRECTIONAL)); + + /* Start the rx descriptor ring where the tx ring leaves off */ + addr = addr + sizeof (struct txbd8) * priv->tx_ring_size; + priv->rx_bd_base = (struct rxbd8 *) addr; + gfar_write(®s->rbase, + dma_map_single(NULL, (void *)addr, + sizeof(struct rxbd8) * priv->rx_ring_size, + DMA_BIDIRECTIONAL)); + + /* Setup the skbuff rings */ + priv->tx_skbuff = + (struct sk_buff **) kmalloc(sizeof (struct sk_buff *) * + priv->tx_ring_size, GFP_KERNEL); + + if (priv->tx_skbuff == NULL) { + printk(KERN_ERR "%s: Could not allocate tx_skbuff\n", + dev->name); + err = -ENOMEM; + goto tx_skb_fail; + } + + for (i = 0; i < priv->tx_ring_size; i++) + priv->tx_skbuff[i] = NULL; + + priv->rx_skbuff = + (struct sk_buff **) kmalloc(sizeof (struct sk_buff *) * + priv->rx_ring_size, GFP_KERNEL); + + if (priv->rx_skbuff == NULL) { + printk(KERN_ERR "%s: Could not allocate rx_skbuff\n", + dev->name); + err = -ENOMEM; + goto rx_skb_fail; + } + + for (i = 0; i < priv->rx_ring_size; i++) + priv->rx_skbuff[i] = NULL; + + /* Initialize some variables in our dev structure */ + priv->dirty_tx = priv->cur_tx = priv->tx_bd_base; + priv->cur_rx = priv->rx_bd_base; + priv->skb_curtx = priv->skb_dirtytx = 0; + priv->skb_currx = 0; + + /* Initialize Transmit Descriptor Ring */ + txbdp = priv->tx_bd_base; + for (i = 0; i < priv->tx_ring_size; i++) { + txbdp->status = 0; + txbdp->length = 0; + txbdp->bufPtr = 0; + txbdp++; + } + + /* Set the last descriptor in the ring to indicate wrap */ + txbdp--; + txbdp->status |= TXBD_WRAP; + + rxbdp = priv->rx_bd_base; + for (i = 0; i < priv->rx_ring_size; i++) { + struct sk_buff *skb = NULL; + + rxbdp->status = 0; + + skb = gfar_new_skb(dev, rxbdp); + + priv->rx_skbuff[i] = skb; + + rxbdp++; + } + + /* Set the last descriptor in the ring to wrap */ + rxbdp--; + rxbdp->status |= RXBD_WRAP; + + /* If the device has multiple interrupts, register for + * them. Otherwise, only register for the one */ + if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) { + /* Install our interrupt handlers for Error, + * Transmit, and Receive */ + if (request_irq(priv->einfo->interruptError, gfar_error, + 0, "enet_error", dev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d\n", + dev->name, priv->einfo->interruptError); + + err = -1; + goto err_irq_fail; + } + + if (request_irq(priv->einfo->interruptTransmit, gfar_transmit, + 0, "enet_tx", dev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d\n", + dev->name, priv->einfo->interruptTransmit); + + err = -1; + + goto tx_irq_fail; + } + + if (request_irq(priv->einfo->interruptReceive, gfar_receive, + 0, "enet_rx", dev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d (receive0)\n", + dev->name, priv->einfo->interruptReceive); + + err = -1; + goto rx_irq_fail; + } + } else { + if (request_irq(priv->einfo->interruptTransmit, gfar_interrupt, + 0, "gfar_interrupt", dev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d\n", + dev->name, priv->einfo->interruptError); + + err = -1; + goto err_irq_fail; + } + } + + /* Grab the PHY interrupt */ + if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { + if (request_irq(priv->einfo->interruptPHY, phy_interrupt, + SA_SHIRQ, "phy_interrupt", dev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", + dev->name, priv->einfo->interruptPHY); + + err = -1; + + if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) + goto phy_irq_fail; + else + goto tx_irq_fail; + } + } else { + init_timer(&priv->phy_info_timer); + priv->phy_info_timer.function = &gfar_phy_timer; + priv->phy_info_timer.data = (unsigned long) dev; + mod_timer(&priv->phy_info_timer, jiffies + 2 * HZ); + } + + /* Set up the bottom half queue */ + INIT_WORK(&priv->tq, (void (*)(void *))gfar_phy_change, dev); + + /* Configure the PHY interrupt */ + phy_run_commands(dev, priv->phyinfo->startup); + + /* Tell the kernel the link is up, and determine the + * negotiated features (speed, duplex) */ + adjust_link(dev); + + if (priv->link == 0) + printk(KERN_INFO "%s: No link detected\n", dev->name); + + /* Configure the coalescing support */ + if (priv->txcoalescing) + gfar_write(®s->txic, + mk_ic_value(priv->txcount, priv->txtime)); + else + gfar_write(®s->txic, 0); + + if (priv->rxcoalescing) + gfar_write(®s->rxic, + mk_ic_value(priv->rxcount, priv->rxtime)); + else + gfar_write(®s->rxic, 0); + + init_waitqueue_head(&priv->rxcleanupq); + + /* Enable Rx and Tx in MACCFG1 */ + tempval = gfar_read(®s->maccfg1); + tempval |= (MACCFG1_RX_EN | MACCFG1_TX_EN); + gfar_write(®s->maccfg1, tempval); + + /* Initialize DMACTRL to have WWR and WOP */ + tempval = gfar_read(&priv->regs->dmactrl); + tempval |= DMACTRL_INIT_SETTINGS; + gfar_write(&priv->regs->dmactrl, tempval); + + /* Clear THLT, so that the DMA starts polling now */ + gfar_write(®s->tstat, TSTAT_CLEAR_THALT); + + /* Make sure we aren't stopped */ + tempval = gfar_read(&priv->regs->dmactrl); + tempval &= ~(DMACTRL_GRS | DMACTRL_GTS); + gfar_write(&priv->regs->dmactrl, tempval); + + /* Unmask the interrupts we look for */ + gfar_write(®s->imask, IMASK_DEFAULT); + + return 0; + +phy_irq_fail: + free_irq(priv->einfo->interruptReceive, dev); +rx_irq_fail: + free_irq(priv->einfo->interruptTransmit, dev); +tx_irq_fail: + free_irq(priv->einfo->interruptError, dev); +err_irq_fail: +rx_skb_fail: + free_skb_resources(priv); +tx_skb_fail: + kfree(priv->tx_bd_base); + return err; +} + +/* Called when something needs to use the ethernet device */ +/* Returns 0 for success. */ +static int gfar_enet_open(struct net_device *dev) +{ + int err; + + /* Initialize a bunch of registers */ + init_registers(dev); + + gfar_set_mac_address(dev); + + err = init_phy(dev); + + if (err) + return err; + + err = startup_gfar(dev); + + netif_start_queue(dev); + + return err; +} + +/* This is called by the kernel when a frame is ready for transmission. */ +/* It is pointed to by the dev->hard_start_xmit function pointer */ +static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + struct txbd8 *txbdp; + + /* Update transmit stats */ + priv->stats.tx_bytes += skb->len; + + /* Lock priv now */ + spin_lock_irq(&priv->lock); + + /* Point at the first free tx descriptor */ + txbdp = priv->cur_tx; + + /* Clear all but the WRAP status flags */ + txbdp->status &= TXBD_WRAP; + + /* Set buffer length and pointer */ + txbdp->length = skb->len; + txbdp->bufPtr = dma_map_single(NULL, skb->data, + skb->len, DMA_TO_DEVICE); + + /* Save the skb pointer so we can free it later */ + priv->tx_skbuff[priv->skb_curtx] = skb; + + /* Update the current skb pointer (wrapping if this was the last) */ + priv->skb_curtx = + (priv->skb_curtx + 1) & TX_RING_MOD_MASK(priv->tx_ring_size); + + /* Flag the BD as interrupt-causing */ + txbdp->status |= TXBD_INTERRUPT; + + /* Flag the BD as ready to go, last in frame, and */ + /* in need of CRC */ + txbdp->status |= (TXBD_READY | TXBD_LAST | TXBD_CRC); + + dev->trans_start = jiffies; + + /* If this was the last BD in the ring, the next one */ + /* is at the beginning of the ring */ + if (txbdp->status & TXBD_WRAP) + txbdp = priv->tx_bd_base; + else + txbdp++; + + /* If the next BD still needs to be cleaned up, then the bds + are full. We need to tell the kernel to stop sending us stuff. */ + if (txbdp == priv->dirty_tx) { + netif_stop_queue(dev); + + priv->stats.tx_fifo_errors++; + } + + /* Update the current txbd to the next one */ + priv->cur_tx = txbdp; + + /* Tell the DMA to go go go */ + gfar_write(&priv->regs->tstat, TSTAT_CLEAR_THALT); + + /* Unlock priv */ + spin_unlock_irq(&priv->lock); + + return 0; +} + +/* Stops the kernel queue, and halts the controller */ +static int gfar_close(struct net_device *dev) +{ + stop_gfar(dev); + + netif_stop_queue(dev); + + return 0; +} + +/* returns a net_device_stats structure pointer */ +static struct net_device_stats * gfar_get_stats(struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + + return &(priv->stats); +} + +/* Changes the mac address if the controller is not running. */ +int gfar_set_mac_address(struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + int i; + char tmpbuf[MAC_ADDR_LEN]; + u32 tempval; + + /* Now copy it into the mac registers backwards, cuz */ + /* little endian is silly */ + for (i = 0; i < MAC_ADDR_LEN; i++) + tmpbuf[MAC_ADDR_LEN - 1 - i] = dev->dev_addr[i]; + + gfar_write(&priv->regs->macstnaddr1, *((u32 *) (tmpbuf))); + + tempval = *((u32 *) (tmpbuf + 4)); + + gfar_write(&priv->regs->macstnaddr2, tempval); + + return 0; +} + +/********************************************************************** + * gfar_accept_fastpath + * + * Used to authenticate to the kernel that a fast path entry can be + * added to device's routing table cache + * + * Input : pointer to ethernet interface network device structure and + * a pointer to the designated entry to be added to the cache. + * Output : zero upon success, negative upon failure + **********************************************************************/ +#ifdef CONFIG_NET_FASTROUTE +static int gfar_accept_fastpath(struct net_device *dev, struct dst_entry *dst) +{ + struct net_device *odev = dst->dev; + + if ((dst->ops->protocol != __constant_htons(ETH_P_IP)) + || (odev->type != ARPHRD_ETHER) + || (odev->accept_fastpath == NULL)) { + return -1; + } + + return 0; +} +#endif + +/* try_fastroute() -- Checks the fastroute cache to see if a given packet + * can be routed immediately to another device. If it can, we send it. + * If we used a fastroute, we return 1. Otherwise, we return 0. + * Returns 0 if CONFIG_NET_FASTROUTE is not on + */ +static inline int try_fastroute(struct sk_buff *skb, struct net_device *dev, int length) +{ +#ifdef CONFIG_NET_FASTROUTE + struct ethhdr *eth; + struct iphdr *iph; + unsigned int hash; + struct rtable *rt; + struct net_device *odev; + struct gfar_private *priv = netdev_priv(dev); + unsigned int CPU_ID = smp_processor_id(); + + eth = (struct ethhdr *) (skb->data); + + /* Only route ethernet IP packets */ + if (eth->h_proto == __constant_htons(ETH_P_IP)) { + iph = (struct iphdr *) (skb->data + ETH_HLEN); + + /* Generate the hash value */ + hash = ((*(u8 *) &iph->daddr) ^ (*(u8 *) & iph->saddr)) & NETDEV_FASTROUTE_HMASK; + + rt = (struct rtable *) (dev->fastpath[hash]); + if (rt != NULL + && ((*(u32 *) &iph->daddr) == (*(u32 *) &rt->key.dst)) + && ((*(u32 *) &iph->saddr) == (*(u32 *) &rt->key.src)) + && !(rt->u.dst.obsolete)) { + odev = rt->u.dst.dev; + netdev_rx_stat[CPU_ID].fastroute_hit++; + + /* Make sure the packet is: + * 1) IPv4 + * 2) without any options (header length of 5) + * 3) Not a multicast packet + * 4) going to a valid destination + * 5) Not out of time-to-live + */ + if (iph->version == 4 + && iph->ihl == 5 + && (!(eth->h_dest[0] & 0x01)) + && neigh_is_valid(rt->u.dst.neighbour) + && iph->ttl > 1) { + + /* Fast Route Path: Taken if the outgoing device is ready to transmit the packet now */ + if ((!netif_queue_stopped(odev)) + && (!spin_is_locked(odev->xmit_lock)) + && (skb->len <= (odev->mtu + ETH_HLEN + 2 + 4))) { + + skb->pkt_type = PACKET_FASTROUTE; + skb->protocol = __constant_htons(ETH_P_IP); + ip_decrease_ttl(iph); + memcpy(eth->h_source, odev->dev_addr, MAC_ADDR_LEN); + memcpy(eth->h_dest, rt->u.dst.neighbour->ha, MAC_ADDR_LEN); + skb->dev = odev; + + /* Prep the skb for the packet */ + skb_put(skb, length); + + if (odev->hard_start_xmit(skb, odev) != 0) { + panic("%s: FastRoute path corrupted", dev->name); + } + netdev_rx_stat[CPU_ID].fastroute_success++; + } + + /* Semi Fast Route Path: Mark the packet as needing fast routing, but let the + * stack handle getting it to the device */ + else { + skb->pkt_type = PACKET_FASTROUTE; + skb->nh.raw = skb->data + ETH_HLEN; + skb->protocol = __constant_htons(ETH_P_IP); + netdev_rx_stat[CPU_ID].fastroute_defer++; + + /* Prep the skb for the packet */ + skb_put(skb, length); + + if(RECEIVE(skb) == NET_RX_DROP) { + priv->extra_stats.kernel_dropped++; + } + } + + return 1; + } + } + } +#endif /* CONFIG_NET_FASTROUTE */ + return 0; +} + +static int gfar_change_mtu(struct net_device *dev, int new_mtu) +{ + int tempsize, tempval; + struct gfar_private *priv = netdev_priv(dev); + int oldsize = priv->rx_buffer_size; + int frame_size = new_mtu + 18; + + if ((frame_size < 64) || (frame_size > JUMBO_FRAME_SIZE)) { + printk(KERN_ERR "%s: Invalid MTU setting\n", dev->name); + return -EINVAL; + } + + tempsize = + (frame_size & ~(INCREMENTAL_BUFFER_SIZE - 1)) + + INCREMENTAL_BUFFER_SIZE; + + /* Only stop and start the controller if it isn't already + * stopped */ + if ((oldsize != tempsize) && (dev->flags & IFF_UP)) + stop_gfar(dev); + + priv->rx_buffer_size = tempsize; + + dev->mtu = new_mtu; + + gfar_write(&priv->regs->mrblr, priv->rx_buffer_size); + gfar_write(&priv->regs->maxfrm, priv->rx_buffer_size); + + /* If the mtu is larger than the max size for standard + * ethernet frames (ie, a jumbo frame), then set maccfg2 + * to allow huge frames, and to check the length */ + tempval = gfar_read(&priv->regs->maccfg2); + + if (priv->rx_buffer_size > DEFAULT_RX_BUFFER_SIZE) + tempval |= (MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK); + else + tempval &= ~(MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK); + + gfar_write(&priv->regs->maccfg2, tempval); + + if ((oldsize != tempsize) && (dev->flags & IFF_UP)) + startup_gfar(dev); + + return 0; +} + +/* gfar_timeout gets called when a packet has not been + * transmitted after a set amount of time. + * For now, assume that clearing out all the structures, and + * starting over will fix the problem. */ +static void gfar_timeout(struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + + priv->stats.tx_errors++; + + if (dev->flags & IFF_UP) { + stop_gfar(dev); + startup_gfar(dev); + } + + if (!netif_queue_stopped(dev)) + netif_schedule(dev); +} + +/* Interrupt Handler for Transmit complete */ +static irqreturn_t gfar_transmit(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = (struct net_device *) dev_id; + struct gfar_private *priv = netdev_priv(dev); + struct txbd8 *bdp; + + /* Clear IEVENT */ + gfar_write(&priv->regs->ievent, IEVENT_TX_MASK); + + /* Lock priv */ + spin_lock(&priv->lock); + bdp = priv->dirty_tx; + while ((bdp->status & TXBD_READY) == 0) { + /* If dirty_tx and cur_tx are the same, then either the */ + /* ring is empty or full now (it could only be full in the beginning, */ + /* obviously). If it is empty, we are done. */ + if ((bdp == priv->cur_tx) && (netif_queue_stopped(dev) == 0)) + break; + + priv->stats.tx_packets++; + + /* Deferred means some collisions occurred during transmit, */ + /* but we eventually sent the packet. */ + if (bdp->status & TXBD_DEF) + priv->stats.collisions++; + + /* Free the sk buffer associated with this TxBD */ + dev_kfree_skb_irq(priv->tx_skbuff[priv->skb_dirtytx]); + priv->tx_skbuff[priv->skb_dirtytx] = NULL; + priv->skb_dirtytx = + (priv->skb_dirtytx + + 1) & TX_RING_MOD_MASK(priv->tx_ring_size); + + /* update bdp to point at next bd in the ring (wrapping if necessary) */ + if (bdp->status & TXBD_WRAP) + bdp = priv->tx_bd_base; + else + bdp++; + + /* Move dirty_tx to be the next bd */ + priv->dirty_tx = bdp; + + /* We freed a buffer, so now we can restart transmission */ + if (netif_queue_stopped(dev)) + netif_wake_queue(dev); + } /* while ((bdp->status & TXBD_READY) == 0) */ + + /* If we are coalescing the interrupts, reset the timer */ + /* Otherwise, clear it */ + if (priv->txcoalescing) + gfar_write(&priv->regs->txic, + mk_ic_value(priv->txcount, priv->txtime)); + else + gfar_write(&priv->regs->txic, 0); + + spin_unlock(&priv->lock); + + return IRQ_HANDLED; +} + +struct sk_buff * gfar_new_skb(struct net_device *dev, struct rxbd8 *bdp) +{ + struct gfar_private *priv = netdev_priv(dev); + struct sk_buff *skb = NULL; + unsigned int timeout = SKB_ALLOC_TIMEOUT; + + /* We have to allocate the skb, so keep trying till we succeed */ + while ((!skb) && timeout--) + skb = dev_alloc_skb(priv->rx_buffer_size + RXBUF_ALIGNMENT); + + if (skb == NULL) + return NULL; + + /* We need the data buffer to be aligned properly. We will reserve + * as many bytes as needed to align the data properly + */ + skb_reserve(skb, + RXBUF_ALIGNMENT - + (((unsigned) skb->data) & (RXBUF_ALIGNMENT - 1))); + + skb->dev = dev; + + bdp->bufPtr = dma_map_single(NULL, skb->data, + priv->rx_buffer_size + RXBUF_ALIGNMENT, + DMA_FROM_DEVICE); + + bdp->length = 0; + + /* Mark the buffer empty */ + bdp->status |= (RXBD_EMPTY | RXBD_INTERRUPT); + + return skb; +} + +static inline void count_errors(unsigned short status, struct gfar_private *priv) +{ + struct net_device_stats *stats = &priv->stats; + struct gfar_extra_stats *estats = &priv->extra_stats; + + /* If the packet was truncated, none of the other errors + * matter */ + if (status & RXBD_TRUNCATED) { + stats->rx_length_errors++; + + estats->rx_trunc++; + + return; + } + /* Count the errors, if there were any */ + if (status & (RXBD_LARGE | RXBD_SHORT)) { + stats->rx_length_errors++; + + if (status & RXBD_LARGE) + estats->rx_large++; + else + estats->rx_short++; + } + if (status & RXBD_NONOCTET) { + stats->rx_frame_errors++; + estats->rx_nonoctet++; + } + if (status & RXBD_CRCERR) { + estats->rx_crcerr++; + stats->rx_crc_errors++; + } + if (status & RXBD_OVERRUN) { + estats->rx_overrun++; + stats->rx_crc_errors++; + } +} + +irqreturn_t gfar_receive(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = (struct net_device *) dev_id; + struct gfar_private *priv = netdev_priv(dev); + +#ifdef CONFIG_GFAR_NAPI + u32 tempval; +#endif + + /* Clear IEVENT, so rx interrupt isn't called again + * because of this interrupt */ + gfar_write(&priv->regs->ievent, IEVENT_RX_MASK); + + /* support NAPI */ +#ifdef CONFIG_GFAR_NAPI + if (netif_rx_schedule_prep(dev)) { + tempval = gfar_read(&priv->regs->imask); + tempval &= IMASK_RX_DISABLED; + gfar_write(&priv->regs->imask, tempval); + + __netif_rx_schedule(dev); + } else { +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: receive called twice (%x)[%x]\n", + dev->name, gfar_read(priv->regs->ievent), + gfar_read(priv->regs->imask)); +#endif + } +#else + + spin_lock(&priv->lock); + gfar_clean_rx_ring(dev); + + /* If we are coalescing interrupts, update the timer */ + /* Otherwise, clear it */ + if (priv->rxcoalescing) + gfar_write(&priv->regs->rxic, + mk_ic_value(priv->rxcount, priv->rxtime)); + else + gfar_write(&priv->regs->rxic, 0); + + /* Just in case we need to wake the ring param changer */ + priv->rxclean = 1; + + spin_unlock(&priv->lock); +#endif + + return IRQ_HANDLED; +} + + +/* gfar_process_frame() -- handle one incoming packet if skb + * isn't NULL. Try the fastroute before using the stack */ +static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb, + int length) +{ + struct gfar_private *priv = netdev_priv(dev); + + if (skb == NULL) { +#ifdef BRIEF_GFAR_ERRORS + printk(KERN_WARNING "%s: Missing skb!!.\n", + dev->name); +#endif + priv->stats.rx_dropped++; + priv->extra_stats.rx_skbmissing++; + } else { + if(try_fastroute(skb, dev, length) == 0) { + /* Prep the skb for the packet */ + skb_put(skb, length); + + /* Tell the skb what kind of packet this is */ + skb->protocol = eth_type_trans(skb, dev); + + /* Send the packet up the stack */ + if (RECEIVE(skb) == NET_RX_DROP) { + priv->extra_stats.kernel_dropped++; + } + } + } + + return 0; +} + +/* gfar_clean_rx_ring() -- Processes each frame in the rx ring + * until all are gone (or, in the case of NAPI, the budget/quota + * has been reached). Returns the number of frames handled + */ +#ifdef CONFIG_GFAR_NAPI +static int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit) +#else +static int gfar_clean_rx_ring(struct net_device *dev) +#endif +{ + struct rxbd8 *bdp; + struct sk_buff *skb; + u16 pkt_len; + int howmany = 0; + struct gfar_private *priv = netdev_priv(dev); + + /* Get the first full descriptor */ + bdp = priv->cur_rx; + +#ifdef CONFIG_GFAR_NAPI +#define GFAR_RXDONE() ((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0)) +#else +#define GFAR_RXDONE() (bdp->status & RXBD_EMPTY) +#endif + while (!GFAR_RXDONE()) { + skb = priv->rx_skbuff[priv->skb_currx]; + + if (!(bdp->status & + (RXBD_LARGE | RXBD_SHORT | RXBD_NONOCTET + | RXBD_CRCERR | RXBD_OVERRUN | RXBD_TRUNCATED))) { + /* Increment the number of packets */ + priv->stats.rx_packets++; + howmany++; + + /* Remove the FCS from the packet length */ + pkt_len = bdp->length - 4; + + gfar_process_frame(dev, skb, pkt_len); + + priv->stats.rx_bytes += pkt_len; + + } else { + count_errors(bdp->status, priv); + + if (skb) + dev_kfree_skb_any(skb); + + priv->rx_skbuff[priv->skb_currx] = NULL; + } + + dev->last_rx = jiffies; + + /* Clear the status flags for this buffer */ + bdp->status &= ~RXBD_STATS; + + /* Add another skb for the future */ + skb = gfar_new_skb(dev, bdp); + priv->rx_skbuff[priv->skb_currx] = skb; + + /* Update to the next pointer */ + if (bdp->status & RXBD_WRAP) + bdp = priv->rx_bd_base; + else + bdp++; + + /* update to point at the next skb */ + priv->skb_currx = + (priv->skb_currx + + 1) & RX_RING_MOD_MASK(priv->rx_ring_size); + + } + + /* Update the current rxbd pointer to be the next one */ + priv->cur_rx = bdp; + + /* If no packets have arrived since the + * last one we processed, clear the IEVENT RX and + * BSY bits so that another interrupt won't be + * generated when we set IMASK */ + if (bdp->status & RXBD_EMPTY) + gfar_write(&priv->regs->ievent, IEVENT_RX_MASK); + + return howmany; +} + +#ifdef CONFIG_GFAR_NAPI +static int gfar_poll(struct net_device *dev, int *budget) +{ + int howmany; + struct gfar_private *priv = netdev_priv(dev); + int rx_work_limit = *budget; + + if (rx_work_limit > dev->quota) + rx_work_limit = dev->quota; + + spin_lock(&priv->lock); + howmany = gfar_clean_rx_ring(dev, rx_work_limit); + + dev->quota -= howmany; + rx_work_limit -= howmany; + *budget -= howmany; + + if (rx_work_limit >= 0) { + netif_rx_complete(dev); + + /* Clear the halt bit in RSTAT */ + gfar_write(&priv->regs->rstat, RSTAT_CLEAR_RHALT); + + gfar_write(&priv->regs->imask, IMASK_DEFAULT); + + /* If we are coalescing interrupts, update the timer */ + /* Otherwise, clear it */ + if (priv->rxcoalescing) + gfar_write(&priv->regs->rxic, + mk_ic_value(priv->rxcount, priv->rxtime)); + else + gfar_write(&priv->regs->rxic, 0); + + /* Signal to the ring size changer that it's safe to go */ + priv->rxclean = 1; + } + + spin_unlock(priv->lock); + + return (rx_work_limit < 0) ? 1 : 0; +} +#endif + +/* The interrupt handler for devices with one interrupt */ +static irqreturn_t gfar_interrupt(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = dev_id; + struct gfar_private *priv = netdev_priv(dev); + + /* Save ievent for future reference */ + u32 events = gfar_read(&priv->regs->ievent); + + /* Clear IEVENT */ + gfar_write(&priv->regs->ievent, events); + + /* Check for reception */ + if ((events & IEVENT_RXF0) || (events & IEVENT_RXB0)) + gfar_receive(irq, dev_id, regs); + + /* Check for transmit completion */ + if ((events & IEVENT_TXF) || (events & IEVENT_TXB)) + gfar_transmit(irq, dev_id, regs); + + /* Update error statistics */ + if (events & IEVENT_TXE) { + priv->stats.tx_errors++; + + if (events & IEVENT_LC) + priv->stats.tx_window_errors++; + if (events & IEVENT_CRL) + priv->stats.tx_aborted_errors++; + if (events & IEVENT_XFUN) { +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_WARNING "%s: tx underrun. dropped packet\n", + dev->name); +#endif + priv->stats.tx_dropped++; + priv->extra_stats.tx_underrun++; + + /* Reactivate the Tx Queues */ + gfar_write(&priv->regs->tstat, TSTAT_CLEAR_THALT); + } + } + if (events & IEVENT_BSY) { + priv->stats.rx_errors++; + priv->extra_stats.rx_bsy++; + + gfar_receive(irq, dev_id, regs); + +#ifndef CONFIG_GFAR_NAPI + /* Clear the halt bit in RSTAT */ + gfar_write(&priv->regs->rstat, RSTAT_CLEAR_RHALT); +#endif + +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: busy error (rhalt: %x)\n", dev->name, + gfar_read(priv->regs->rstat)); +#endif + } + if (events & IEVENT_BABR) { + priv->stats.rx_errors++; + priv->extra_stats.rx_babr++; + +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: babbling error\n", dev->name); +#endif + } + if (events & IEVENT_EBERR) { + priv->extra_stats.eberr++; +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: EBERR\n", dev->name); +#endif + } + if (events & IEVENT_RXC) { +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: control frame\n", dev->name); +#endif + } + + if (events & IEVENT_BABT) { + priv->extra_stats.tx_babt++; +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: babt error\n", dev->name); +#endif + } + + return IRQ_HANDLED; +} + +static irqreturn_t phy_interrupt(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = (struct net_device *) dev_id; + struct gfar_private *priv = netdev_priv(dev); + + /* Run the commands which acknowledge the interrupt */ + phy_run_commands(dev, priv->phyinfo->ack_int); + + /* Schedule the bottom half */ + schedule_work(&priv->tq); + + return IRQ_HANDLED; +} + +/* Scheduled by the phy_interrupt/timer to handle PHY changes */ +static void gfar_phy_change(void *data) +{ + struct net_device *dev = (struct net_device *) data; + struct gfar_private *priv = netdev_priv(dev); + int timeout = HZ / 1000 + 1; + + /* Delay to give the PHY a chance to change the + * register state */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(timeout); + + /* Run the commands which check the link state */ + phy_run_commands(dev, priv->phyinfo->handle_int); + + /* React to the change in state */ + adjust_link(dev); +} + +/* Called every so often on systems that don't interrupt + * the core for PHY changes */ +static void gfar_phy_timer(unsigned long data) +{ + struct net_device *dev = (struct net_device *) data; + struct gfar_private *priv = netdev_priv(dev); + + schedule_work(&priv->tq); + + mod_timer(&priv->phy_info_timer, jiffies + 2 * HZ); +} + +/* Called every time the controller might need to be made + * aware of new link state. The PHY code conveys this + * information through variables in the priv structure, and this + * function converts those variables into the appropriate + * register values, and can bring down the device if needed. + */ +static void adjust_link(struct net_device *dev) +{ + struct gfar_private *priv = netdev_priv(dev); + struct gfar *regs = priv->regs; + u32 tempval; + + if (priv->link) { + /* Now we make sure that we can be in full duplex mode. + * If not, we operate in half-duplex mode. */ + if (priv->duplexity != priv->olddplx) { + if (!(priv->duplexity)) { + tempval = gfar_read(®s->maccfg2); + tempval &= ~(MACCFG2_FULL_DUPLEX); + gfar_write(®s->maccfg2, tempval); + + printk(KERN_INFO "%s: Half Duplex\n", + dev->name); + } else { + tempval = gfar_read(®s->maccfg2); + tempval |= MACCFG2_FULL_DUPLEX; + gfar_write(®s->maccfg2, tempval); + + printk(KERN_INFO "%s: Full Duplex\n", + dev->name); + } + + priv->olddplx = priv->duplexity; + } + + if (priv->speed != priv->oldspeed) { + switch (priv->speed) { + case 1000: + tempval = gfar_read(®s->maccfg2); + tempval = + ((tempval & ~(MACCFG2_IF)) | MACCFG2_GMII); + gfar_write(®s->maccfg2, tempval); + break; + case 100: + case 10: + tempval = gfar_read(®s->maccfg2); + tempval = + ((tempval & ~(MACCFG2_IF)) | MACCFG2_MII); + gfar_write(®s->maccfg2, tempval); + break; + default: + printk(KERN_WARNING + "%s: Ack! Speed (%d) is not 10/100/1000!\n", + dev->name, priv->speed); + break; + } + + printk(KERN_INFO "%s: Speed %dBT\n", dev->name, + priv->speed); + + priv->oldspeed = priv->speed; + } + + if (!priv->oldlink) { + printk(KERN_INFO "%s: Link is up\n", dev->name); + priv->oldlink = 1; + netif_carrier_on(dev); + netif_schedule(dev); + } + } else { + if (priv->oldlink) { + printk(KERN_INFO "%s: Link is down\n", dev->name); + priv->oldlink = 0; + priv->oldspeed = 0; + priv->olddplx = -1; + netif_carrier_off(dev); + } + } +} + + +/* Update the hash table based on the current list of multicast + * addresses we subscribe to. Also, change the promiscuity of + * the device based on the flags (this function is called + * whenever dev->flags is changed */ +static void gfar_set_multi(struct net_device *dev) +{ + struct dev_mc_list *mc_ptr; + struct gfar_private *priv = netdev_priv(dev); + struct gfar *regs = priv->regs; + u32 tempval; + + if(dev->flags & IFF_PROMISC) { + printk(KERN_INFO "%s: Entering promiscuous mode.\n", + dev->name); + /* Set RCTRL to PROM */ + tempval = gfar_read(®s->rctrl); + tempval |= RCTRL_PROM; + gfar_write(®s->rctrl, tempval); + } else { + /* Set RCTRL to not PROM */ + tempval = gfar_read(®s->rctrl); + tempval &= ~(RCTRL_PROM); + gfar_write(®s->rctrl, tempval); + } + + if(dev->flags & IFF_ALLMULTI) { + /* Set the hash to rx all multicast frames */ + gfar_write(®s->gaddr0, 0xffffffff); + gfar_write(®s->gaddr1, 0xffffffff); + gfar_write(®s->gaddr2, 0xffffffff); + gfar_write(®s->gaddr3, 0xffffffff); + gfar_write(®s->gaddr4, 0xffffffff); + gfar_write(®s->gaddr5, 0xffffffff); + gfar_write(®s->gaddr6, 0xffffffff); + gfar_write(®s->gaddr7, 0xffffffff); + } else { + /* zero out the hash */ + gfar_write(®s->gaddr0, 0x0); + gfar_write(®s->gaddr1, 0x0); + gfar_write(®s->gaddr2, 0x0); + gfar_write(®s->gaddr3, 0x0); + gfar_write(®s->gaddr4, 0x0); + gfar_write(®s->gaddr5, 0x0); + gfar_write(®s->gaddr6, 0x0); + gfar_write(®s->gaddr7, 0x0); + + if(dev->mc_count == 0) + return; + + /* Parse the list, and set the appropriate bits */ + for(mc_ptr = dev->mc_list; mc_ptr; mc_ptr = mc_ptr->next) { + gfar_set_hash_for_addr(dev, mc_ptr->dmi_addr); + } + } + + return; +} + +/* Set the appropriate hash bit for the given addr */ +/* The algorithm works like so: + * 1) Take the Destination Address (ie the multicast address), and + * do a CRC on it (little endian), and reverse the bits of the + * result. + * 2) Use the 8 most significant bits as a hash into a 256-entry + * table. The table is controlled through 8 32-bit registers: + * gaddr0-7. gaddr0's MSB is entry 0, and gaddr7's LSB is + * gaddr7. This means that the 3 most significant bits in the + * hash index which gaddr register to use, and the 5 other bits + * indicate which bit (assuming an IBM numbering scheme, which + * for PowerPC (tm) is usually the case) in the register holds + * the entry. */ +static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr) +{ + u32 tempval; + struct gfar_private *priv = netdev_priv(dev); + struct gfar *regs = priv->regs; + u32 *hash = ®s->gaddr0; + u32 result = ether_crc(MAC_ADDR_LEN, addr); + u8 whichreg = ((result >> 29) & 0x7); + u8 whichbit = ((result >> 24) & 0x1f); + u32 value = (1 << (31-whichbit)); + + tempval = gfar_read(&hash[whichreg]); + tempval |= value; + gfar_write(&hash[whichreg], tempval); + + return; +} + +/* GFAR error interrupt handler */ +static irqreturn_t gfar_error(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = dev_id; + struct gfar_private *priv = netdev_priv(dev); + + /* Save ievent for future reference */ + u32 events = gfar_read(&priv->regs->ievent); + + /* Clear IEVENT */ + gfar_write(&priv->regs->ievent, IEVENT_ERR_MASK); + + /* Hmm... */ +#if defined (BRIEF_GFAR_ERRORS) || defined (VERBOSE_GFAR_ERRORS) + printk(KERN_DEBUG "%s: error interrupt (ievent=0x%08x imask=0x%08x)\n", + dev->name, events, gfar_read(priv->regs->imask)); +#endif + + /* Update the error counters */ + if (events & IEVENT_TXE) { + priv->stats.tx_errors++; + + if (events & IEVENT_LC) + priv->stats.tx_window_errors++; + if (events & IEVENT_CRL) + priv->stats.tx_aborted_errors++; + if (events & IEVENT_XFUN) { +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: underrun. packet dropped.\n", + dev->name); +#endif + priv->stats.tx_dropped++; + priv->extra_stats.tx_underrun++; + + /* Reactivate the Tx Queues */ + gfar_write(&priv->regs->tstat, TSTAT_CLEAR_THALT); + } +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: Transmit Error\n", dev->name); +#endif + } + if (events & IEVENT_BSY) { + priv->stats.rx_errors++; + priv->extra_stats.rx_bsy++; + + gfar_receive(irq, dev_id, regs); + +#ifndef CONFIG_GFAR_NAPI + /* Clear the halt bit in RSTAT */ + gfar_write(&priv->regs->rstat, RSTAT_CLEAR_RHALT); +#endif + +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: busy error (rhalt: %x)\n", dev->name, + gfar_read(priv->regs->rstat)); +#endif + } + if (events & IEVENT_BABR) { + priv->stats.rx_errors++; + priv->extra_stats.rx_babr++; + +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: babbling error\n", dev->name); +#endif + } + if (events & IEVENT_EBERR) { + priv->extra_stats.eberr++; +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: EBERR\n", dev->name); +#endif + } + if (events & IEVENT_RXC) +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: control frame\n", dev->name); +#endif + + if (events & IEVENT_BABT) { + priv->extra_stats.tx_babt++; +#ifdef VERBOSE_GFAR_ERRORS + printk(KERN_DEBUG "%s: babt error\n", dev->name); +#endif + } + return IRQ_HANDLED; +} + +/* Structure for a device driver */ +static struct ocp_device_id gfar_ids[] = { + {.vendor = OCP_ANY_ID,.function = OCP_FUNC_GFAR}, + {.vendor = OCP_VENDOR_INVALID} +}; + +static struct ocp_driver gfar_driver = { + .name = "gianfar", + .id_table = gfar_ids, + + .probe = gfar_probe, + .remove = gfar_remove, +}; + +static int __init gfar_init(void) +{ + int rc; + + rc = ocp_register_driver(&gfar_driver); +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,41) + if (rc != 0) { +#else + if (rc == 0) { +#endif + ocp_unregister_driver(&gfar_driver); + return -ENODEV; + } + + return 0; +} + +static void __exit gfar_exit(void) +{ + ocp_unregister_driver(&gfar_driver); +} + +module_init(gfar_init); +module_exit(gfar_exit); diff -Nru a/drivers/net/gianfar.h b/drivers/net/gianfar.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/gianfar.h 2004-06-28 10:16:57 -05:00 @@ -0,0 +1,537 @@ +/* + * drivers/net/gianfar.h + * + * Gianfar Ethernet Driver + * Driver for FEC on MPC8540 and TSEC on MPC8540/MPC8560 + * Based on 8260_io/fcc_enet.c + * + * Author: Andy Fleming + * Maintainer: Kumar Gala (kumar.gala@freescale.com) + * + * Copyright 2004 Freescale Semiconductor, Inc + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * Still left to do: + * -Add support for module parameters + */ +#ifndef __GIANFAR_H +#define __GIANFAR_H + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,41) +#include +#else +#include +#define work_struct tq_struct +#define schedule_work schedule_task +#endif + +#include +#include +#include +#include "gianfar_phy.h" + +/* The maximum number of packets to be handled in one call of gfar_poll */ +#define GFAR_DEV_WEIGHT 64 + +/* Number of bytes to align the rx bufs to */ +#define RXBUF_ALIGNMENT 64 + +/* The number of bytes which composes a unit for the purpose of + * allocating data buffers. ie-for any given MTU, the data buffer + * will be the next highest multiple of 512 bytes. */ +#define INCREMENTAL_BUFFER_SIZE 512 + + +#define MAC_ADDR_LEN 6 + +extern char gfar_driver_name[]; +extern char gfar_driver_version[]; + +/* These need to be powers of 2 for this driver */ +#ifdef CONFIG_GFAR_NAPI +#define DEFAULT_TX_RING_SIZE 256 +#define DEFAULT_RX_RING_SIZE 256 +#else +#define DEFAULT_TX_RING_SIZE 64 +#define DEFAULT_RX_RING_SIZE 64 +#endif + +#define GFAR_RX_MAX_RING_SIZE 256 +#define GFAR_TX_MAX_RING_SIZE 256 + +#define DEFAULT_RX_BUFFER_SIZE 1536 +#define TX_RING_MOD_MASK(size) (size-1) +#define RX_RING_MOD_MASK(size) (size-1) +#define JUMBO_BUFFER_SIZE 9728 +#define JUMBO_FRAME_SIZE 9600 + +/* Latency of interface clock in nanoseconds */ +/* Interface clock latency , in this case, means the + * time described by a value of 1 in the interrupt + * coalescing registers' time fields. Since those fields + * refer to the time it takes for 64 clocks to pass, the + * latencies are as such: + * GBIT = 125MHz => 8ns/clock => 8*64 ns / tick + * 100 = 25 MHz => 40ns/clock => 40*64 ns / tick + * 10 = 2.5 MHz => 400ns/clock => 400*64 ns / tick + */ +#define GFAR_GBIT_TIME 512 +#define GFAR_100_TIME 2560 +#define GFAR_10_TIME 25600 + +#define DEFAULT_TXCOUNT 16 +#define DEFAULT_TXTIME 32768 + +#define DEFAULT_RXCOUNT 16 +#define DEFAULT_RXTIME 32768 + +#define TBIPA_VALUE 0x1f +#define MIIMCFG_INIT_VALUE 0x00000007 +#define MIIMCFG_RESET 0x80000000 +#define MIIMIND_BUSY 0x00000001 + +/* MAC register bits */ +#define MACCFG1_SOFT_RESET 0x80000000 +#define MACCFG1_RESET_RX_MC 0x00080000 +#define MACCFG1_RESET_TX_MC 0x00040000 +#define MACCFG1_RESET_RX_FUN 0x00020000 +#define MACCFG1_RESET_TX_FUN 0x00010000 +#define MACCFG1_LOOPBACK 0x00000100 +#define MACCFG1_RX_FLOW 0x00000020 +#define MACCFG1_TX_FLOW 0x00000010 +#define MACCFG1_SYNCD_RX_EN 0x00000008 +#define MACCFG1_RX_EN 0x00000004 +#define MACCFG1_SYNCD_TX_EN 0x00000002 +#define MACCFG1_TX_EN 0x00000001 + +#define MACCFG2_INIT_SETTINGS 0x00007205 +#define MACCFG2_FULL_DUPLEX 0x00000001 +#define MACCFG2_IF 0x00000300 +#define MACCFG2_MII 0x00000100 +#define MACCFG2_GMII 0x00000200 +#define MACCFG2_HUGEFRAME 0x00000020 +#define MACCFG2_LENGTHCHECK 0x00000010 + +#define ECNTRL_INIT_SETTINGS 0x00001000 +#define ECNTRL_TBI_MODE 0x00000020 + +#define MRBLR_INIT_SETTINGS DEFAULT_RX_BUFFER_SIZE + +#define MINFLR_INIT_SETTINGS 0x00000040 + +/* Init to do tx snooping for buffers and descriptors */ +#define DMACTRL_INIT_SETTINGS 0x000000c3 +#define DMACTRL_GRS 0x00000010 +#define DMACTRL_GTS 0x00000008 + +#define TSTAT_CLEAR_THALT 0x80000000 + +/* Interrupt coalescing macros */ +#define IC_ICEN 0x80000000 +#define IC_ICFT_MASK 0x1fe00000 +#define IC_ICFT_SHIFT 21 +#define mk_ic_icft(x) \ + (((unsigned int)x << IC_ICFT_SHIFT)&IC_ICFT_MASK) +#define IC_ICTT_MASK 0x0000ffff +#define mk_ic_ictt(x) (x&IC_ICTT_MASK) + +#define mk_ic_value(count, time) (IC_ICEN | \ + mk_ic_icft(count) | \ + mk_ic_ictt(time)) + +#define RCTRL_PROM 0x00000008 +#define RSTAT_CLEAR_RHALT 0x00800000 + +#define IEVENT_INIT_CLEAR 0xffffffff +#define IEVENT_BABR 0x80000000 +#define IEVENT_RXC 0x40000000 +#define IEVENT_BSY 0x20000000 +#define IEVENT_EBERR 0x10000000 +#define IEVENT_MSRO 0x04000000 +#define IEVENT_GTSC 0x02000000 +#define IEVENT_BABT 0x01000000 +#define IEVENT_TXC 0x00800000 +#define IEVENT_TXE 0x00400000 +#define IEVENT_TXB 0x00200000 +#define IEVENT_TXF 0x00100000 +#define IEVENT_LC 0x00040000 +#define IEVENT_CRL 0x00020000 +#define IEVENT_XFUN 0x00010000 +#define IEVENT_RXB0 0x00008000 +#define IEVENT_GRSC 0x00000100 +#define IEVENT_RXF0 0x00000080 +#define IEVENT_RX_MASK (IEVENT_RXB0 | IEVENT_RXF0) +#define IEVENT_TX_MASK (IEVENT_TXB | IEVENT_TXF) +#define IEVENT_ERR_MASK \ +(IEVENT_RXC | IEVENT_BSY | IEVENT_EBERR | IEVENT_MSRO | \ + IEVENT_BABT | IEVENT_TXC | IEVENT_TXE | IEVENT_LC \ + | IEVENT_CRL | IEVENT_XFUN) + +#define IMASK_INIT_CLEAR 0x00000000 +#define IMASK_BABR 0x80000000 +#define IMASK_RXC 0x40000000 +#define IMASK_BSY 0x20000000 +#define IMASK_EBERR 0x10000000 +#define IMASK_MSRO 0x04000000 +#define IMASK_GRSC 0x02000000 +#define IMASK_BABT 0x01000000 +#define IMASK_TXC 0x00800000 +#define IMASK_TXEEN 0x00400000 +#define IMASK_TXBEN 0x00200000 +#define IMASK_TXFEN 0x00100000 +#define IMASK_LC 0x00040000 +#define IMASK_CRL 0x00020000 +#define IMASK_XFUN 0x00010000 +#define IMASK_RXB0 0x00008000 +#define IMASK_GTSC 0x00000100 +#define IMASK_RXFEN0 0x00000080 +#define IMASK_RX_DISABLED ~(IMASK_RXFEN0 | IMASK_BSY) +#define IMASK_DEFAULT (IMASK_TXEEN | IMASK_TXFEN | IMASK_TXBEN | \ + IMASK_RXFEN0 | IMASK_BSY | IMASK_EBERR | IMASK_BABR | \ + IMASK_XFUN | IMASK_RXC | IMASK_BABT) + + +/* Attribute fields */ + +/* This enables rx snooping for buffers and descriptors */ +#ifdef CONFIG_GFAR_BDSTASH +#define ATTR_BDSTASH 0x00000800 +#else +#define ATTR_BDSTASH 0x00000000 +#endif + +#ifdef CONFIG_GFAR_BUFSTASH +#define ATTR_BUFSTASH 0x00004000 +#define STASH_LENGTH 64 +#else +#define ATTR_BUFSTASH 0x00000000 +#endif + +#define ATTR_SNOOPING 0x000000c0 +#define ATTR_INIT_SETTINGS (ATTR_SNOOPING \ + | ATTR_BDSTASH | ATTR_BUFSTASH) + +#define ATTRELI_INIT_SETTINGS 0x0 + + +/* TxBD status field bits */ +#define TXBD_READY 0x8000 +#define TXBD_PADCRC 0x4000 +#define TXBD_WRAP 0x2000 +#define TXBD_INTERRUPT 0x1000 +#define TXBD_LAST 0x0800 +#define TXBD_CRC 0x0400 +#define TXBD_DEF 0x0200 +#define TXBD_HUGEFRAME 0x0080 +#define TXBD_LATECOLLISION 0x0080 +#define TXBD_RETRYLIMIT 0x0040 +#define TXBD_RETRYCOUNTMASK 0x003c +#define TXBD_UNDERRUN 0x0002 + +/* RxBD status field bits */ +#define RXBD_EMPTY 0x8000 +#define RXBD_RO1 0x4000 +#define RXBD_WRAP 0x2000 +#define RXBD_INTERRUPT 0x1000 +#define RXBD_LAST 0x0800 +#define RXBD_FIRST 0x0400 +#define RXBD_MISS 0x0100 +#define RXBD_BROADCAST 0x0080 +#define RXBD_MULTICAST 0x0040 +#define RXBD_LARGE 0x0020 +#define RXBD_NONOCTET 0x0010 +#define RXBD_SHORT 0x0008 +#define RXBD_CRCERR 0x0004 +#define RXBD_OVERRUN 0x0002 +#define RXBD_TRUNCATED 0x0001 +#define RXBD_STATS 0x01ff + +struct txbd8 +{ + u16 status; /* Status Fields */ + u16 length; /* Buffer length */ + u32 bufPtr; /* Buffer Pointer */ +}; + +struct rxbd8 +{ + u16 status; /* Status Fields */ + u16 length; /* Buffer Length */ + u32 bufPtr; /* Buffer Pointer */ +}; + +struct rmon_mib +{ + u32 tr64; /* 0x.680 - Transmit and Receive 64-byte Frame Counter */ + u32 tr127; /* 0x.684 - Transmit and Receive 65-127 byte Frame Counter */ + u32 tr255; /* 0x.688 - Transmit and Receive 128-255 byte Frame Counter */ + u32 tr511; /* 0x.68c - Transmit and Receive 256-511 byte Frame Counter */ + u32 tr1k; /* 0x.690 - Transmit and Receive 512-1023 byte Frame Counter */ + u32 trmax; /* 0x.694 - Transmit and Receive 1024-1518 byte Frame Counter */ + u32 trmgv; /* 0x.698 - Transmit and Receive 1519-1522 byte Good VLAN Frame */ + u32 rbyt; /* 0x.69c - Receive Byte Counter */ + u32 rpkt; /* 0x.6a0 - Receive Packet Counter */ + u32 rfcs; /* 0x.6a4 - Receive FCS Error Counter */ + u32 rmca; /* 0x.6a8 - Receive Multicast Packet Counter */ + u32 rbca; /* 0x.6ac - Receive Broadcast Packet Counter */ + u32 rxcf; /* 0x.6b0 - Receive Control Frame Packet Counter */ + u32 rxpf; /* 0x.6b4 - Receive Pause Frame Packet Counter */ + u32 rxuo; /* 0x.6b8 - Receive Unknown OP Code Counter */ + u32 raln; /* 0x.6bc - Receive Alignment Error Counter */ + u32 rflr; /* 0x.6c0 - Receive Frame Length Error Counter */ + u32 rcde; /* 0x.6c4 - Receive Code Error Counter */ + u32 rcse; /* 0x.6c8 - Receive Carrier Sense Error Counter */ + u32 rund; /* 0x.6cc - Receive Undersize Packet Counter */ + u32 rovr; /* 0x.6d0 - Receive Oversize Packet Counter */ + u32 rfrg; /* 0x.6d4 - Receive Fragments Counter */ + u32 rjbr; /* 0x.6d8 - Receive Jabber Counter */ + u32 rdrp; /* 0x.6dc - Receive Drop Counter */ + u32 tbyt; /* 0x.6e0 - Transmit Byte Counter Counter */ + u32 tpkt; /* 0x.6e4 - Transmit Packet Counter */ + u32 tmca; /* 0x.6e8 - Transmit Multicast Packet Counter */ + u32 tbca; /* 0x.6ec - Transmit Broadcast Packet Counter */ + u32 txpf; /* 0x.6f0 - Transmit Pause Control Frame Counter */ + u32 tdfr; /* 0x.6f4 - Transmit Deferral Packet Counter */ + u32 tedf; /* 0x.6f8 - Transmit Excessive Deferral Packet Counter */ + u32 tscl; /* 0x.6fc - Transmit Single Collision Packet Counter */ + u32 tmcl; /* 0x.700 - Transmit Multiple Collision Packet Counter */ + u32 tlcl; /* 0x.704 - Transmit Late Collision Packet Counter */ + u32 txcl; /* 0x.708 - Transmit Excessive Collision Packet Counter */ + u32 tncl; /* 0x.70c - Transmit Total Collision Counter */ + u8 res1[4]; + u32 tdrp; /* 0x.714 - Transmit Drop Frame Counter */ + u32 tjbr; /* 0x.718 - Transmit Jabber Frame Counter */ + u32 tfcs; /* 0x.71c - Transmit FCS Error Counter */ + u32 txcf; /* 0x.720 - Transmit Control Frame Counter */ + u32 tovr; /* 0x.724 - Transmit Oversize Frame Counter */ + u32 tund; /* 0x.728 - Transmit Undersize Frame Counter */ + u32 tfrg; /* 0x.72c - Transmit Fragments Frame Counter */ + u32 car1; /* 0x.730 - Carry Register One */ + u32 car2; /* 0x.734 - Carry Register Two */ + u32 cam1; /* 0x.738 - Carry Mask Register One */ + u32 cam2; /* 0x.73c - Carry Mask Register Two */ +}; + +struct gfar_extra_stats { + u64 kernel_dropped; + u64 rx_large; + u64 rx_short; + u64 rx_nonoctet; + u64 rx_crcerr; + u64 rx_overrun; + u64 rx_bsy; + u64 rx_babr; + u64 rx_trunc; + u64 eberr; + u64 tx_babt; + u64 tx_underrun; + u64 rx_skbmissing; + u64 tx_timeout; +}; + +#define GFAR_RMON_LEN ((sizeof(struct rmon_mib) - 16)/sizeof(u32)) +#define GFAR_EXTRA_STATS_LEN (sizeof(struct gfar_extra_stats)/sizeof(u64)) + +/* Number of stats in the stats structure (ignore car and cam regs)*/ +#define GFAR_STATS_LEN (GFAR_RMON_LEN + GFAR_EXTRA_STATS_LEN) + +#define GFAR_INFOSTR_LEN 32 + +struct gfar_stats { + u64 extra[GFAR_EXTRA_STATS_LEN]; + u64 rmon[GFAR_RMON_LEN]; +}; + + +struct gfar { + u8 res1[16]; + u32 ievent; /* 0x.010 - Interrupt Event Register */ + u32 imask; /* 0x.014 - Interrupt Mask Register */ + u32 edis; /* 0x.018 - Error Disabled Register */ + u8 res2[4]; + u32 ecntrl; /* 0x.020 - Ethernet Control Register */ + u32 minflr; /* 0x.024 - Minimum Frame Length Register */ + u32 ptv; /* 0x.028 - Pause Time Value Register */ + u32 dmactrl; /* 0x.02c - DMA Control Register */ + u32 tbipa; /* 0x.030 - TBI PHY Address Register */ + u8 res3[88]; + u32 fifo_tx_thr; /* 0x.08c - FIFO transmit threshold register */ + u8 res4[8]; + u32 fifo_tx_starve; /* 0x.098 - FIFO transmit starve register */ + u32 fifo_tx_starve_shutoff; /* 0x.09c - FIFO transmit starve shutoff register */ + u8 res5[96]; + u32 tctrl; /* 0x.100 - Transmit Control Register */ + u32 tstat; /* 0x.104 - Transmit Status Register */ + u8 res6[4]; + u32 tbdlen; /* 0x.10c - Transmit Buffer Descriptor Data Length Register */ + u32 txic; /* 0x.110 - Transmit Interrupt Coalescing Configuration Register */ + u8 res7[16]; + u32 ctbptr; /* 0x.124 - Current Transmit Buffer Descriptor Pointer Register */ + u8 res8[92]; + u32 tbptr; /* 0x.184 - Transmit Buffer Descriptor Pointer Low Register */ + u8 res9[124]; + u32 tbase; /* 0x.204 - Transmit Descriptor Base Address Register */ + u8 res10[168]; + u32 ostbd; /* 0x.2b0 - Out-of-Sequence Transmit Buffer Descriptor Register */ + u32 ostbdp; /* 0x.2b4 - Out-of-Sequence Transmit Data Buffer Pointer Register */ + u8 res11[72]; + u32 rctrl; /* 0x.300 - Receive Control Register */ + u32 rstat; /* 0x.304 - Receive Status Register */ + u8 res12[4]; + u32 rbdlen; /* 0x.30c - RxBD Data Length Register */ + u32 rxic; /* 0x.310 - Receive Interrupt Coalescing Configuration Register */ + u8 res13[16]; + u32 crbptr; /* 0x.324 - Current Receive Buffer Descriptor Pointer */ + u8 res14[24]; + u32 mrblr; /* 0x.340 - Maximum Receive Buffer Length Register */ + u8 res15[64]; + u32 rbptr; /* 0x.384 - Receive Buffer Descriptor Pointer */ + u8 res16[124]; + u32 rbase; /* 0x.404 - Receive Descriptor Base Address */ + u8 res17[248]; + u32 maccfg1; /* 0x.500 - MAC Configuration 1 Register */ + u32 maccfg2; /* 0x.504 - MAC Configuration 2 Register */ + u32 ipgifg; /* 0x.508 - Inter Packet Gap/Inter Frame Gap Register */ + u32 hafdup; /* 0x.50c - Half Duplex Register */ + u32 maxfrm; /* 0x.510 - Maximum Frame Length Register */ + u8 res18[12]; + u32 miimcfg; /* 0x.520 - MII Management Configuration Register */ + u32 miimcom; /* 0x.524 - MII Management Command Register */ + u32 miimadd; /* 0x.528 - MII Management Address Register */ + u32 miimcon; /* 0x.52c - MII Management Control Register */ + u32 miimstat; /* 0x.530 - MII Management Status Register */ + u32 miimind; /* 0x.534 - MII Management Indicator Register */ + u8 res19[4]; + u32 ifstat; /* 0x.53c - Interface Status Register */ + u32 macstnaddr1; /* 0x.540 - Station Address Part 1 Register */ + u32 macstnaddr2; /* 0x.544 - Station Address Part 2 Register */ + u8 res20[312]; + struct rmon_mib rmon; + u8 res21[192]; + u32 iaddr0; /* 0x.800 - Indivdual address register 0 */ + u32 iaddr1; /* 0x.804 - Indivdual address register 1 */ + u32 iaddr2; /* 0x.808 - Indivdual address register 2 */ + u32 iaddr3; /* 0x.80c - Indivdual address register 3 */ + u32 iaddr4; /* 0x.810 - Indivdual address register 4 */ + u32 iaddr5; /* 0x.814 - Indivdual address register 5 */ + u32 iaddr6; /* 0x.818 - Indivdual address register 6 */ + u32 iaddr7; /* 0x.81c - Indivdual address register 7 */ + u8 res22[96]; + u32 gaddr0; /* 0x.880 - Global address register 0 */ + u32 gaddr1; /* 0x.884 - Global address register 1 */ + u32 gaddr2; /* 0x.888 - Global address register 2 */ + u32 gaddr3; /* 0x.88c - Global address register 3 */ + u32 gaddr4; /* 0x.890 - Global address register 4 */ + u32 gaddr5; /* 0x.894 - Global address register 5 */ + u32 gaddr6; /* 0x.898 - Global address register 6 */ + u32 gaddr7; /* 0x.89c - Global address register 7 */ + u8 res23[856]; + u32 attr; /* 0x.bf8 - Attributes Register */ + u32 attreli; /* 0x.bfc - Attributes Extract Length and Extract Index Register */ + u8 res24[1024]; + +}; + +/* Struct stolen almost completely (and shamelessly) from the FCC enet source + * (Ok, that's not so true anymore, but there is a family resemblence) + * The GFAR buffer descriptors track the ring buffers. The rx_bd_base + * and tx_bd_base always point to the currently available buffer. + * The dirty_tx tracks the current buffer that is being sent by the + * controller. The cur_tx and dirty_tx are equal under both completely + * empty and completely full conditions. The empty/ready indicator in + * the buffer descriptor determines the actual condition. + */ +struct gfar_private +{ + /* pointers to arrays of skbuffs for tx and rx */ + struct sk_buff ** tx_skbuff; + struct sk_buff ** rx_skbuff; + + /* indices pointing to the next free sbk in skb arrays */ + u16 skb_curtx; + u16 skb_currx; + + /* index of the first skb which hasn't been transmitted + * yet. */ + u16 skb_dirtytx; + + /* Configuration info for the coalescing features */ + unsigned char txcoalescing; + unsigned short txcount; + unsigned short txtime; + unsigned char rxcoalescing; + unsigned short rxcount; + unsigned short rxtime; + + /* GFAR addresses */ + struct rxbd8 *rx_bd_base; /* Base addresses of Rx and Tx Buffers */ + struct txbd8 *tx_bd_base; + struct rxbd8 *cur_rx; /* Next free rx ring entry */ + struct txbd8 *cur_tx; /* Next free ring entry */ + struct txbd8 *dirty_tx; /* The Ring entry to be freed. */ + struct gfar *regs; /* Pointer to the GFAR memory mapped Registers */ + struct phy_info *phyinfo; + struct gfar *phyregs; + struct work_struct tq; + struct timer_list phy_info_timer; + struct net_device_stats stats; /* linux network statistics */ + struct gfar_extra_stats extra_stats; + spinlock_t lock; + unsigned int rx_buffer_size; + unsigned int rx_stash_size; + unsigned int tx_ring_size; + unsigned int rx_ring_size; + wait_queue_head_t rxcleanupq; + unsigned int rxclean; + int link; /* current link state */ + int oldlink; + int duplexity; /* Indicates negotiated duplex state */ + int olddplx; + int speed; /* Indicates negotiated speed */ + int oldspeed; + + /* Info structure initialized by board setup code */ + struct ocp_gfar_data *einfo; +}; + +extern inline u32 gfar_read(volatile unsigned *addr) +{ + u32 val; + val = in_be32(addr); + return val; +} + +extern inline void gfar_write(volatile unsigned *addr, u32 val) +{ + out_be32(addr, val); +} + + + +#endif /* __GIANFAR_H */ diff -Nru a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/gianfar_ethtool.c 2004-06-28 10:16:57 -05:00 @@ -0,0 +1,484 @@ +/* + * drivers/net/gianfar_ethtool.c + * + * Gianfar Ethernet Driver + * Ethtool support for Gianfar Enet + * Based on e1000 ethtool support + * + * Author: Andy Fleming + * Maintainer: Kumar Gala (kumar.gala@freescale.com) + * + * Copyright 2004 Freescale Semiconductor, Inc + * + * This software may be used and distributed according to + * the terms of the GNU Public License, Version 2, incorporated herein + * by reference. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "gianfar.h" + +#define is_power_of_2(x) ((x) != 0 && (((x) & ((x) - 1)) == 0)) + +extern int startup_gfar(struct net_device *dev); +extern void stop_gfar(struct net_device *dev); +extern void gfar_receive(int irq, void *dev_id, struct pt_regs *regs); + +void gfar_fill_stats(struct net_device *dev, struct ethtool_stats *dummy, + u64 * buf); +void gfar_gstrings(struct net_device *dev, u32 stringset, u8 * buf); +int gfar_gcoalesce(struct net_device *dev, struct ethtool_coalesce *cvals); +int gfar_scoalesce(struct net_device *dev, struct ethtool_coalesce *cvals); +void gfar_gringparam(struct net_device *dev, struct ethtool_ringparam *rvals); +int gfar_sringparam(struct net_device *dev, struct ethtool_ringparam *rvals); +void gfar_gdrvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo); + +static char stat_gstrings[][ETH_GSTRING_LEN] = { + "RX Dropped by Kernel", + "RX Large Frame Errors", + "RX Short Frame Errors", + "RX Non-Octet Errors", + "RX CRC Errors", + "RX Overrun Errors", + "RX Busy Errors", + "RX Babbling Errors", + "RX Truncated Frames", + "Ethernet Bus Error", + "TX Babbling Errors", + "TX Underrun Errors", + "RX SKB Missing Errors", + "TX Timeout Errors", + "tx&rx 64B frames", + "tx&rx 65-127B frames", + "tx&rx 128-255B frames", + "tx&rx 256-511B frames", + "tx&rx 512-1023B frames", + "tx&rx 1024-1518B frames", + "tx&rx 1519-1522B Good VLAN", + "RX bytes", + "RX Packets", + "RX FCS Errors", + "Receive Multicast Packet", + "Receive Broadcast Packet", + "RX Control Frame Packets", + "RX Pause Frame Packets", + "RX Unknown OP Code", + "RX Alignment Error", + "RX Frame Length Error", + "RX Code Error", + "RX Carrier Sense Error", + "RX Undersize Packets", + "RX Oversize Packets", + "RX Fragmented Frames", + "RX Jabber Frames", + "RX Dropped Frames", + "TX Byte Counter", + "TX Packets", + "TX Multicast Packets", + "TX Broadcast Packets", + "TX Pause Control Frames", + "TX Deferral Packets", + "TX Excessive Deferral Packets", + "TX Single Collision Packets", + "TX Multiple Collision Packets", + "TX Late Collision Packets", + "TX Excessive Collision Packets", + "TX Total Collision", + "RESERVED", + "TX Dropped Frames", + "TX Jabber Frames", + "TX FCS Errors", + "TX Control Frames", + "TX Oversize Frames", + "TX Undersize Frames", + "TX Fragmented Frames", +}; + +/* Fill in an array of 64-bit statistics from various sources. + * This array will be appended to the end of the ethtool_stats + * structure, and returned to user space + */ +void gfar_fill_stats(struct net_device *dev, struct ethtool_stats *dummy, u64 * buf) +{ + int i; + struct gfar_private *priv = (struct gfar_private *) dev->priv; + u32 *rmon = (u32 *) & priv->regs->rmon; + u64 *extra = (u64 *) & priv->extra_stats; + struct gfar_stats *stats = (struct gfar_stats *) buf; + + for (i = 0; i < GFAR_RMON_LEN; i++) { + stats->rmon[i] = (u64) (rmon[i]); + } + + for (i = 0; i < GFAR_EXTRA_STATS_LEN; i++) { + stats->extra[i] = extra[i]; + } +} + +/* Returns the number of stats (and their corresponding strings) */ +int gfar_stats_count(struct net_device *dev) +{ + return GFAR_STATS_LEN; +} + +void gfar_gstrings_normon(struct net_device *dev, u32 stringset, u8 * buf) +{ + memcpy(buf, stat_gstrings, GFAR_EXTRA_STATS_LEN * ETH_GSTRING_LEN); +} + +void gfar_fill_stats_normon(struct net_device *dev, + struct ethtool_stats *dummy, u64 * buf) +{ + int i; + struct gfar_private *priv = (struct gfar_private *) dev->priv; + u64 *extra = (u64 *) & priv->extra_stats; + + for (i = 0; i < GFAR_EXTRA_STATS_LEN; i++) { + buf[i] = extra[i]; + } +} + + +int gfar_stats_count_normon(struct net_device *dev) +{ + return GFAR_EXTRA_STATS_LEN; +} +/* Fills in the drvinfo structure with some basic info */ +void gfar_gdrvinfo(struct net_device *dev, struct + ethtool_drvinfo *drvinfo) +{ + strncpy(drvinfo->driver, gfar_driver_name, GFAR_INFOSTR_LEN); + strncpy(drvinfo->version, gfar_driver_version, GFAR_INFOSTR_LEN); + strncpy(drvinfo->fw_version, "N/A", GFAR_INFOSTR_LEN); + strncpy(drvinfo->bus_info, "N/A", GFAR_INFOSTR_LEN); + drvinfo->n_stats = GFAR_STATS_LEN; + drvinfo->testinfo_len = 0; + drvinfo->regdump_len = 0; + drvinfo->eedump_len = 0; +} + +/* Return the current settings in the ethtool_cmd structure */ +int gfar_gsettings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + uint gigabit_support = + priv->einfo->flags & GFAR_HAS_GIGABIT ? SUPPORTED_1000baseT_Full : 0; + uint gigabit_advert = + priv->einfo->flags & GFAR_HAS_GIGABIT ? ADVERTISED_1000baseT_Full: 0; + + cmd->supported = (SUPPORTED_10baseT_Half + | SUPPORTED_100baseT_Half + | SUPPORTED_100baseT_Full + | gigabit_support | SUPPORTED_Autoneg); + + /* For now, we always advertise everything */ + cmd->advertising = (ADVERTISED_10baseT_Half + | ADVERTISED_100baseT_Half + | ADVERTISED_100baseT_Full + | gigabit_advert | ADVERTISED_Autoneg); + + cmd->speed = priv->speed; + cmd->duplex = priv->duplexity; + cmd->port = PORT_MII; + cmd->phy_address = priv->einfo->phyid; + cmd->transceiver = XCVR_EXTERNAL; + cmd->autoneg = AUTONEG_ENABLE; + cmd->maxtxpkt = priv->txcount; + cmd->maxrxpkt = priv->rxcount; + + return 0; +} + +/* Return the length of the register structure */ +int gfar_reglen(struct net_device *dev) +{ + return sizeof (struct gfar); +} + +/* Return a dump of the GFAR register space */ +void gfar_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *regbuf) +{ + int i; + struct gfar_private *priv = (struct gfar_private *) dev->priv; + u32 *theregs = (u32 *) priv->regs; + u32 *buf = (u32 *) regbuf; + + for (i = 0; i < sizeof (struct gfar) / sizeof (u32); i++) + buf[i] = theregs[i]; +} + +/* Return the link state 1 is up, 0 is down */ +u32 gfar_get_link(struct net_device *dev) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + return (u32) priv->link; +} + +/* Fill in a buffer with the strings which correspond to the + * stats */ +void gfar_gstrings(struct net_device *dev, u32 stringset, u8 * buf) +{ + memcpy(buf, stat_gstrings, GFAR_STATS_LEN * ETH_GSTRING_LEN); +} + +/* Convert microseconds to ethernet clock ticks, which changes + * depending on what speed the controller is running at */ +static unsigned int gfar_usecs2ticks(struct gfar_private *priv, unsigned int usecs) +{ + unsigned int count; + + /* The timer is different, depending on the interface speed */ + switch (priv->speed) { + case 1000: + count = GFAR_GBIT_TIME; + break; + case 100: + count = GFAR_100_TIME; + break; + case 10: + default: + count = GFAR_10_TIME; + break; + } + + /* Make sure we return a number greater than 0 + * if usecs > 0 */ + return ((usecs * 1000 + count - 1) / count); +} + +/* Convert ethernet clock ticks to microseconds */ +static unsigned int gfar_ticks2usecs(struct gfar_private *priv, unsigned int ticks) +{ + unsigned int count; + + /* The timer is different, depending on the interface speed */ + switch (priv->speed) { + case 1000: + count = GFAR_GBIT_TIME; + break; + case 100: + count = GFAR_100_TIME; + break; + case 10: + default: + count = GFAR_10_TIME; + break; + } + + /* Make sure we return a number greater than 0 */ + /* if ticks is > 0 */ + return ((ticks * count) / 1000); +} + +/* Get the coalescing parameters, and put them in the cvals + * structure. */ +int gfar_gcoalesce(struct net_device *dev, struct ethtool_coalesce *cvals) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + + cvals->rx_coalesce_usecs = gfar_ticks2usecs(priv, priv->rxtime); + cvals->rx_max_coalesced_frames = priv->rxcount; + + cvals->tx_coalesce_usecs = gfar_ticks2usecs(priv, priv->txtime); + cvals->tx_max_coalesced_frames = priv->txcount; + + cvals->use_adaptive_rx_coalesce = 0; + cvals->use_adaptive_tx_coalesce = 0; + + cvals->pkt_rate_low = 0; + cvals->rx_coalesce_usecs_low = 0; + cvals->rx_max_coalesced_frames_low = 0; + cvals->tx_coalesce_usecs_low = 0; + cvals->tx_max_coalesced_frames_low = 0; + + /* When the packet rate is below pkt_rate_high but above + * pkt_rate_low (both measured in packets per second) the + * normal {rx,tx}_* coalescing parameters are used. + */ + + /* When the packet rate is (measured in packets per second) + * is above pkt_rate_high, the {rx,tx}_*_high parameters are + * used. + */ + cvals->pkt_rate_high = 0; + cvals->rx_coalesce_usecs_high = 0; + cvals->rx_max_coalesced_frames_high = 0; + cvals->tx_coalesce_usecs_high = 0; + cvals->tx_max_coalesced_frames_high = 0; + + /* How often to do adaptive coalescing packet rate sampling, + * measured in seconds. Must not be zero. + */ + cvals->rate_sample_interval = 0; + + return 0; +} + +/* Change the coalescing values. + * Both cvals->*_usecs and cvals->*_frames have to be > 0 + * in order for coalescing to be active + */ +int gfar_scoalesce(struct net_device *dev, struct ethtool_coalesce *cvals) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + + /* Set up rx coalescing */ + if ((cvals->rx_coalesce_usecs == 0) || + (cvals->rx_max_coalesced_frames == 0)) + priv->rxcoalescing = 0; + else + priv->rxcoalescing = 1; + + priv->rxtime = gfar_usecs2ticks(priv, cvals->rx_coalesce_usecs); + priv->rxcount = cvals->rx_max_coalesced_frames; + + /* Set up tx coalescing */ + if ((cvals->tx_coalesce_usecs == 0) || + (cvals->tx_max_coalesced_frames == 0)) + priv->txcoalescing = 0; + else + priv->txcoalescing = 1; + + priv->txtime = gfar_usecs2ticks(priv, cvals->tx_coalesce_usecs); + priv->txcount = cvals->tx_max_coalesced_frames; + + if (priv->rxcoalescing) + gfar_write(&priv->regs->rxic, + mk_ic_value(priv->rxcount, priv->rxtime)); + else + gfar_write(&priv->regs->rxic, 0); + + if (priv->txcoalescing) + gfar_write(&priv->regs->txic, + mk_ic_value(priv->txcount, priv->txtime)); + else + gfar_write(&priv->regs->txic, 0); + + return 0; +} + +/* Fills in rvals with the current ring parameters. Currently, + * rx, rx_mini, and rx_jumbo rings are the same size, as mini and + * jumbo are ignored by the driver */ +void gfar_gringparam(struct net_device *dev, struct ethtool_ringparam *rvals) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + + rvals->rx_max_pending = GFAR_RX_MAX_RING_SIZE; + rvals->rx_mini_max_pending = GFAR_RX_MAX_RING_SIZE; + rvals->rx_jumbo_max_pending = GFAR_RX_MAX_RING_SIZE; + rvals->tx_max_pending = GFAR_TX_MAX_RING_SIZE; + + /* Values changeable by the user. The valid values are + * in the range 1 to the "*_max_pending" counterpart above. + */ + rvals->rx_pending = priv->rx_ring_size; + rvals->rx_mini_pending = priv->rx_ring_size; + rvals->rx_jumbo_pending = priv->rx_ring_size; + rvals->tx_pending = priv->tx_ring_size; +} + +/* Change the current ring parameters, stopping the controller if + * necessary so that we don't mess things up while we're in + * motion. We wait for the ring to be clean before reallocating + * the rings. */ +int gfar_sringparam(struct net_device *dev, struct ethtool_ringparam *rvals) +{ + u32 tempval; + struct gfar_private *priv = (struct gfar_private *) dev->priv; + int err = 0; + + if (rvals->rx_pending > GFAR_RX_MAX_RING_SIZE) + return -EINVAL; + + if (!is_power_of_2(rvals->rx_pending)) { + printk("%s: Ring sizes must be a power of 2\n", + dev->name); + return -EINVAL; + } + + if (rvals->tx_pending > GFAR_TX_MAX_RING_SIZE) + return -EINVAL; + + if (!is_power_of_2(rvals->tx_pending)) { + printk("%s: Ring sizes must be a power of 2\n", + dev->name); + return -EINVAL; + } + + /* Stop the controller so we don't rx any more frames */ + /* But first, make sure we clear the bits */ + tempval = gfar_read(&priv->regs->dmactrl); + tempval &= ~(DMACTRL_GRS | DMACTRL_GTS); + gfar_write(&priv->regs->dmactrl, tempval); + + tempval = gfar_read(&priv->regs->dmactrl); + tempval |= (DMACTRL_GRS | DMACTRL_GTS); + gfar_write(&priv->regs->dmactrl, tempval); + + while (!(gfar_read(&priv->regs->ievent) & (IEVENT_GRSC | IEVENT_GTSC))) + cpu_relax(); + + /* Note that rx is not clean right now */ + priv->rxclean = 0; + + if (dev->flags & IFF_UP) { + /* Tell the driver to process the rest of the frames */ + gfar_receive(0, (void *) dev, NULL); + + /* Now wait for it to be done */ + wait_event_interruptible(priv->rxcleanupq, priv->rxclean); + + /* Ok, all packets have been handled. Now we bring it down, + * change the ring size, and bring it up */ + + stop_gfar(dev); + } + + priv->rx_ring_size = rvals->rx_pending; + priv->tx_ring_size = rvals->tx_pending; + + if (dev->flags & IFF_UP) + err = startup_gfar(dev); + + return err; +} + +struct ethtool_ops gfar_ethtool_ops = { + .get_settings = gfar_gsettings, + .get_drvinfo = gfar_gdrvinfo, + .get_regs_len = gfar_reglen, + .get_regs = gfar_get_regs, + .get_link = gfar_get_link, + .get_coalesce = gfar_gcoalesce, + .set_coalesce = gfar_scoalesce, + .get_ringparam = gfar_gringparam, + .set_ringparam = gfar_sringparam, + .get_strings = gfar_gstrings, + .get_stats_count = gfar_stats_count, + .get_ethtool_stats = gfar_fill_stats, +}; diff -Nru a/drivers/net/gianfar_phy.c b/drivers/net/gianfar_phy.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/gianfar_phy.c 2004-06-28 10:16:57 -05:00 @@ -0,0 +1,504 @@ +/* + * drivers/net/gianfar_phy.c + * + * Gianfar Ethernet Driver -- PHY handling + * Driver for FEC on MPC8540 and TSEC on MPC8540/MPC8560 + * Based on 8260_io/fcc_enet.c + * + * Author: Andy Fleming + * Maintainer: Kumar Gala (kumar.gala@freescale.com) + * + * Copyright 2004 Freescale Semiconductor, Inc + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include "gianfar.h" +#include "gianfar_phy.h" + +/* Write value to the PHY for this device to the register at regnum, */ +/* waiting until the write is done before it returns. All PHY */ +/* configuration has to be done through the TSEC1 MIIM regs */ +void write_phy_reg(struct net_device *dev, u16 regnum, u16 value) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar *regbase = priv->phyregs; + struct ocp_gfar_data *einfo = priv->einfo; + + /* Set the PHY address and the register address we want to write */ + gfar_write(®base->miimadd, ((einfo->phyid) << 8) | regnum); + + /* Write out the value we want */ + gfar_write(®base->miimcon, value); + + /* Wait for the transaction to finish */ + while (gfar_read(®base->miimind) & MIIMIND_BUSY) + cpu_relax(); +} + +/* Reads from register regnum in the PHY for device dev, */ +/* returning the value. Clears miimcom first. All PHY */ +/* configuration has to be done through the TSEC1 MIIM regs */ +u16 read_phy_reg(struct net_device *dev, u16 regnum) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar *regbase = priv->phyregs; + struct ocp_gfar_data *einfo = priv->einfo; + u16 value; + + /* Set the PHY address and the register address we want to read */ + gfar_write(®base->miimadd, ((einfo->phyid) << 8) | regnum); + + /* Clear miimcom, and then initiate a read */ + gfar_write(®base->miimcom, 0); + gfar_write(®base->miimcom, MIIM_READ_COMMAND); + + /* Wait for the transaction to finish */ + while (gfar_read(®base->miimind) & (MIIMIND_NOTVALID | MIIMIND_BUSY)) + cpu_relax(); + + /* Grab the value of the register from miimstat */ + value = gfar_read(®base->miimstat); + + return value; +} + +/* returns which value to write to the control register. */ +/* For 10/100 the value is slightly different. */ +u16 mii_cr_init(u16 mii_reg, struct net_device * dev) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct ocp_gfar_data *einfo = priv->einfo; + + if (einfo->flags & GFAR_HAS_GIGABIT) + return MIIM_CONTROL_INIT; + else + return MIIM_CR_INIT; +} + +#define BRIEF_GFAR_ERRORS +/* Wait for auto-negotiation to complete */ +u16 mii_parse_sr(u16 mii_reg, struct net_device * dev) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + + unsigned int timeout = GFAR_AN_TIMEOUT; + + if (mii_reg & MIIM_STATUS_LINK) + priv->link = 1; + else + priv->link = 0; + + /* Only auto-negotiate if the link has just gone up */ + if (priv->link && !priv->oldlink) { + while ((!(mii_reg & MIIM_STATUS_AN_DONE)) && timeout--) + mii_reg = read_phy_reg(dev, MIIM_STATUS); + +#if defined(BRIEF_GFAR_ERRORS) + if (mii_reg & MIIM_STATUS_AN_DONE) + printk(KERN_INFO "%s: Auto-negotiation done\n", + dev->name); + else + printk(KERN_INFO "%s: Auto-negotiation timed out\n", + dev->name); +#endif + } + + return 0; +} + +/* Determine the speed and duplex which was negotiated */ +u16 mii_parse_88E1011_psr(u16 mii_reg, struct net_device * dev) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + unsigned int speed; + + if (priv->link) { + if (mii_reg & MIIM_88E1011_PHYSTAT_DUPLEX) + priv->duplexity = 1; + else + priv->duplexity = 0; + + speed = (mii_reg & MIIM_88E1011_PHYSTAT_SPEED); + + switch (speed) { + case MIIM_88E1011_PHYSTAT_GBIT: + priv->speed = 1000; + break; + case MIIM_88E1011_PHYSTAT_100: + priv->speed = 100; + break; + default: + priv->speed = 10; + break; + } + } else { + priv->speed = 0; + priv->duplexity = 0; + } + + return 0; +} + +u16 mii_parse_cis8201(u16 mii_reg, struct net_device * dev) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + unsigned int speed; + + if (priv->link) { + if (mii_reg & MIIM_CIS8201_AUXCONSTAT_DUPLEX) + priv->duplexity = 1; + else + priv->duplexity = 0; + + speed = mii_reg & MIIM_CIS8201_AUXCONSTAT_SPEED; + + switch (speed) { + case MIIM_CIS8201_AUXCONSTAT_GBIT: + priv->speed = 1000; + break; + case MIIM_CIS8201_AUXCONSTAT_100: + priv->speed = 100; + break; + default: + priv->speed = 10; + break; + } + } else { + priv->speed = 0; + priv->duplexity = 0; + } + + return 0; +} + +u16 mii_parse_dm9161_scsr(u16 mii_reg, struct net_device * dev) +{ + struct gfar_private *priv = (struct gfar_private *) dev->priv; + + if (mii_reg & (MIIM_DM9161_SCSR_100F | MIIM_DM9161_SCSR_100H)) + priv->speed = 100; + else + priv->speed = 10; + + if (mii_reg & (MIIM_DM9161_SCSR_100F | MIIM_DM9161_SCSR_10F)) + priv->duplexity = 1; + else + priv->duplexity = 0; + + return 0; +} + +u16 dm9161_wait(u16 mii_reg, struct net_device *dev) +{ + int timeout = HZ; + int secondary = 10; + u16 temp; + + do { + + /* Davicom takes a bit to come up after a reset, + * so wait here for a bit */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(timeout); + + temp = read_phy_reg(dev, MIIM_STATUS); + + secondary--; + } while ((!(temp & MIIM_STATUS_AN_DONE)) && secondary); + + return 0; +} + +static struct phy_info phy_info_M88E1011S = { + 0x01410c6, + "Marvell 88E1011S", + 4, + (const struct phy_cmd[]) { /* config */ + /* Reset and configure the PHY */ + {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* startup */ + /* Status is read once to clear old link state */ + {MIIM_STATUS, miim_read, NULL}, + /* Auto-negotiate */ + {MIIM_STATUS, miim_read, mii_parse_sr}, + /* Read the status */ + {MIIM_88E1011_PHY_STATUS, miim_read, mii_parse_88E1011_psr}, + /* Clear the IEVENT register */ + {MIIM_88E1011_IEVENT, miim_read, NULL}, + /* Set up the mask */ + {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_INIT, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* ack_int */ + /* Clear the interrupt */ + {MIIM_88E1011_IEVENT, miim_read, NULL}, + /* Disable interrupts */ + {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_CLEAR, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* handle_int */ + /* Read the Status (2x to make sure link is right) */ + {MIIM_STATUS, miim_read, NULL}, + /* Check the status */ + {MIIM_STATUS, miim_read, mii_parse_sr}, + {MIIM_88E1011_PHY_STATUS, miim_read, mii_parse_88E1011_psr}, + /* Enable Interrupts */ + {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_INIT, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* shutdown */ + {MIIM_88E1011_IEVENT, miim_read, NULL}, + {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_CLEAR, NULL}, + {miim_end,} + }, +}; + +/* Cicada 8204 */ +static struct phy_info phy_info_cis8204 = { + 0x3f11, + "Cicada Cis8204", + 6, + (const struct phy_cmd[]) { /* config */ + /* Override PHY config settings */ + {MIIM_CIS8201_AUX_CONSTAT, MIIM_CIS8201_AUXCONSTAT_INIT, NULL}, + /* Set up the interface mode */ + {MIIM_CIS8201_EXT_CON1, MIIM_CIS8201_EXTCON1_INIT, NULL}, + /* Configure some basic stuff */ + {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* startup */ + /* Read the Status (2x to make sure link is right) */ + {MIIM_STATUS, miim_read, NULL}, + /* Auto-negotiate */ + {MIIM_STATUS, miim_read, mii_parse_sr}, + /* Read the status */ + {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, + /* Clear the status register */ + {MIIM_CIS8204_ISTAT, miim_read, NULL}, + /* Enable interrupts */ + {MIIM_CIS8204_IMASK, MIIM_CIS8204_IMASK_MASK, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* ack_int */ + /* Clear the status register */ + {MIIM_CIS8204_ISTAT, miim_read, NULL}, + /* Disable interrupts */ + {MIIM_CIS8204_IMASK, 0x0, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* handle_int */ + /* Read the Status (2x to make sure link is right) */ + {MIIM_STATUS, miim_read, NULL}, + /* Auto-negotiate */ + {MIIM_STATUS, miim_read, mii_parse_sr}, + /* Read the status */ + {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, + /* Enable interrupts */ + {MIIM_CIS8204_IMASK, MIIM_CIS8204_IMASK_MASK, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* shutdown */ + /* Clear the status register */ + {MIIM_CIS8204_ISTAT, miim_read, NULL}, + /* Disable interrupts */ + {MIIM_CIS8204_IMASK, 0x0, NULL}, + {miim_end,} + }, +}; + +/* Cicada 8201 */ +static struct phy_info phy_info_cis8201 = { + 0xfc41, + "CIS8201", + 4, + (const struct phy_cmd[]) { /* config */ + /* Override PHY config settings */ + {MIIM_CIS8201_AUX_CONSTAT, MIIM_CIS8201_AUXCONSTAT_INIT, NULL}, + /* Set up the interface mode */ + {MIIM_CIS8201_EXT_CON1, MIIM_CIS8201_EXTCON1_INIT, NULL}, + /* Configure some basic stuff */ + {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* startup */ + /* Read the Status (2x to make sure link is right) */ + {MIIM_STATUS, miim_read, NULL}, + /* Auto-negotiate */ + {MIIM_STATUS, miim_read, mii_parse_sr}, + /* Read the status */ + {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* ack_int */ + {miim_end,} + }, + (const struct phy_cmd[]) { /* handle_int */ + {miim_end,} + }, + (const struct phy_cmd[]) { /* shutdown */ + {miim_end,} + }, +}; + +static struct phy_info phy_info_dm9161 = { + 0x0181b88, + "Davicom DM9161E", + 4, + (const struct phy_cmd[]) { /* config */ + {MIIM_CONTROL, MIIM_DM9161_CR_STOP, NULL}, + /* Do not bypass the scrambler/descrambler */ + {MIIM_DM9161_SCR, MIIM_DM9161_SCR_INIT, NULL}, + /* Clear 10BTCSR to default */ + {MIIM_DM9161_10BTCSR, MIIM_DM9161_10BTCSR_INIT, NULL}, + /* Configure some basic stuff */ + {MIIM_CONTROL, MIIM_CR_INIT, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* startup */ + /* Restart Auto Negotiation */ + {MIIM_CONTROL, MIIM_DM9161_CR_RSTAN, NULL}, + /* Status is read once to clear old link state */ + {MIIM_STATUS, miim_read, dm9161_wait}, + /* Auto-negotiate */ + {MIIM_STATUS, miim_read, mii_parse_sr}, + /* Read the status */ + {MIIM_DM9161_SCSR, miim_read, mii_parse_dm9161_scsr}, + /* Clear any pending interrupts */ + {MIIM_DM9161_INTR, miim_read, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* ack_int */ + {MIIM_DM9161_INTR, miim_read, NULL}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* handle_int */ + {MIIM_STATUS, miim_read, NULL}, + {MIIM_STATUS, miim_read, mii_parse_sr}, + {MIIM_DM9161_SCSR, miim_read, mii_parse_dm9161_scsr}, + {miim_end,} + }, + (const struct phy_cmd[]) { /* shutdown */ + {MIIM_DM9161_INTR, miim_read, NULL}, + {miim_end,} + }, +}; + +static struct phy_info *phy_info[] = { + &phy_info_cis8201, + &phy_info_cis8204, + &phy_info_M88E1011S, + &phy_info_dm9161, + NULL +}; + +/* Use the PHY ID registers to determine what type of PHY is attached + * to device dev. return a struct phy_info structure describing that PHY + */ +struct phy_info * get_phy_info(struct net_device *dev) +{ + u16 phy_reg; + u32 phy_ID; + int i; + struct phy_info *theInfo = NULL; + + /* Grab the bits from PHYIR1, and put them in the upper half */ + phy_reg = read_phy_reg(dev, MIIM_PHYIR1); + phy_ID = (phy_reg & 0xffff) << 16; + + /* Grab the bits from PHYIR2, and put them in the lower half */ + phy_reg = read_phy_reg(dev, MIIM_PHYIR2); + phy_ID |= (phy_reg & 0xffff); + + /* loop through all the known PHY types, and find one that */ + /* matches the ID we read from the PHY. */ + for (i = 0; phy_info[i]; i++) + if (phy_info[i]->id == (phy_ID >> phy_info[i]->shift)) + theInfo = phy_info[i]; + + if (theInfo == NULL) { + printk("%s: PHY id %x is not supported!\n", dev->name, phy_ID); + return NULL; + } else { + printk("%s: PHY is %s (%x)\n", dev->name, theInfo->name, + phy_ID); + } + + return theInfo; +} + +/* Take a list of struct phy_cmd, and, depending on the values, either */ +/* read or write, using a helper function if provided */ +/* It is assumed that all lists of struct phy_cmd will be terminated by */ +/* mii_end. */ +void phy_run_commands(struct net_device *dev, const struct phy_cmd *cmd) +{ + int i; + u16 result; + struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar *phyregs = priv->phyregs; + + /* Reset the management interface */ + gfar_write(&phyregs->miimcfg, MIIMCFG_RESET); + + /* Setup the MII Mgmt clock speed */ + gfar_write(&phyregs->miimcfg, MIIMCFG_INIT_VALUE); + + /* Wait until the bus is free */ + while (gfar_read(&phyregs->miimind) & MIIMIND_BUSY) + cpu_relax(); + + for (i = 0; cmd->mii_reg != miim_end; i++) { + /* The command is a read if mii_data is miim_read */ + if (cmd->mii_data == miim_read) { + /* Read the value of the PHY reg */ + result = read_phy_reg(dev, cmd->mii_reg); + + /* If a function was supplied, we need to let it process */ + /* the result. */ + if (cmd->funct != NULL) + (*(cmd->funct)) (result, dev); + } else { /* Otherwise, it's a write */ + /* If a function was supplied, it will provide + * the value to write */ + /* Otherwise, the value was supplied in cmd->mii_data */ + if (cmd->funct != NULL) + result = (*(cmd->funct)) (0, dev); + else + result = cmd->mii_data; + + /* Write the appropriate value to the PHY reg */ + write_phy_reg(dev, cmd->mii_reg, result); + } + cmd++; + } +} diff -Nru a/drivers/net/gianfar_phy.h b/drivers/net/gianfar_phy.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/gianfar_phy.h 2004-06-28 10:16:57 -05:00 @@ -0,0 +1,192 @@ +/* + * drivers/net/gianfar_phy.h + * + * Gianfar Ethernet Driver -- PHY handling + * Driver for FEC on MPC8540 and TSEC on MPC8540/MPC8560 + * Based on 8260_io/fcc_enet.c + * + * Author: Andy Fleming + * Maintainer: Kumar Gala (kumar.gala@freescale.com) + * + * Copyright 2004 Freescale Semiconductor, Inc + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#ifndef __GIANFAR_PHY_H +#define __GIANFAR_PHY_H + +#define miim_end ((u32)-2) +#define miim_read ((u32)-1) + +#define MIIMIND_BUSY 0x00000001 +#define MIIMIND_NOTVALID 0x00000004 + +#define MIIM_CONTROL 0x00 +#define MIIM_CONTROL_RESET 0x00008000 +#define MIIM_CONTROL_INIT 0x00001140 +#define MIIM_ANEN 0x00001000 + +#define MIIM_CR 0x00 +#define MIIM_CR_RST 0x00008000 +#define MIIM_CR_INIT 0x00001000 + +#define MIIM_STATUS 0x1 +#define MIIM_STATUS_AN_DONE 0x00000020 +#define MIIM_STATUS_LINK 0x0004 + +#define MIIM_PHYIR1 0x2 +#define MIIM_PHYIR2 0x3 + +#define GFAR_AN_TIMEOUT 0x000fffff + +#define MIIM_ANLPBPA 0x5 +#define MIIM_ANLPBPA_HALF 0x00000040 +#define MIIM_ANLPBPA_FULL 0x00000020 + +#define MIIM_ANEX 0x6 +#define MIIM_ANEX_NP 0x00000004 +#define MIIM_ANEX_PRX 0x00000002 + + +/* Cicada Extended Control Register 1 */ +#define MIIM_CIS8201_EXT_CON1 0x17 +#define MIIM_CIS8201_EXTCON1_INIT 0x0000 + +/* Cicada Interrupt Mask Register */ +#define MIIM_CIS8204_IMASK 0x19 +#define MIIM_CIS8204_IMASK_IEN 0x8000 +#define MIIM_CIS8204_IMASK_SPEED 0x4000 +#define MIIM_CIS8204_IMASK_LINK 0x2000 +#define MIIM_CIS8204_IMASK_DUPLEX 0x1000 +#define MIIM_CIS8204_IMASK_MASK 0xf000 + +/* Cicada Interrupt Status Register */ +#define MIIM_CIS8204_ISTAT 0x1a +#define MIIM_CIS8204_ISTAT_STATUS 0x8000 +#define MIIM_CIS8204_ISTAT_SPEED 0x4000 +#define MIIM_CIS8204_ISTAT_LINK 0x2000 +#define MIIM_CIS8204_ISTAT_DUPLEX 0x1000 + +/* Cicada Auxiliary Control/Status Register */ +#define MIIM_CIS8201_AUX_CONSTAT 0x1c +#define MIIM_CIS8201_AUXCONSTAT_INIT 0x0004 +#define MIIM_CIS8201_AUXCONSTAT_DUPLEX 0x0020 +#define MIIM_CIS8201_AUXCONSTAT_SPEED 0x0018 +#define MIIM_CIS8201_AUXCONSTAT_GBIT 0x0010 +#define MIIM_CIS8201_AUXCONSTAT_100 0x0008 + +/* 88E1011 PHY Status Register */ +#define MIIM_88E1011_PHY_STATUS 0x11 +#define MIIM_88E1011_PHYSTAT_SPEED 0xc000 +#define MIIM_88E1011_PHYSTAT_GBIT 0x8000 +#define MIIM_88E1011_PHYSTAT_100 0x4000 +#define MIIM_88E1011_PHYSTAT_DUPLEX 0x2000 +#define MIIM_88E1011_PHYSTAT_LINK 0x0400 + +#define MIIM_88E1011_IEVENT 0x13 +#define MIIM_88E1011_IEVENT_CLEAR 0x0000 + +#define MIIM_88E1011_IMASK 0x12 +#define MIIM_88E1011_IMASK_INIT 0x6400 +#define MIIM_88E1011_IMASK_CLEAR 0x0000 + +/* DM9161 Control register values */ +#define MIIM_DM9161_CR_STOP 0x0400 +#define MIIM_DM9161_CR_RSTAN 0x1200 + +#define MIIM_DM9161_SCR 0x10 +#define MIIM_DM9161_SCR_INIT 0x0610 + +/* DM9161 Specified Configuration and Status Register */ +#define MIIM_DM9161_SCSR 0x11 +#define MIIM_DM9161_SCSR_100F 0x8000 +#define MIIM_DM9161_SCSR_100H 0x4000 +#define MIIM_DM9161_SCSR_10F 0x2000 +#define MIIM_DM9161_SCSR_10H 0x1000 + +/* DM9161 Interrupt Register */ +#define MIIM_DM9161_INTR 0x15 +#define MIIM_DM9161_INTR_PEND 0x8000 +#define MIIM_DM9161_INTR_DPLX_MASK 0x0800 +#define MIIM_DM9161_INTR_SPD_MASK 0x0400 +#define MIIM_DM9161_INTR_LINK_MASK 0x0200 +#define MIIM_DM9161_INTR_MASK 0x0100 +#define MIIM_DM9161_INTR_DPLX_CHANGE 0x0010 +#define MIIM_DM9161_INTR_SPD_CHANGE 0x0008 +#define MIIM_DM9161_INTR_LINK_CHANGE 0x0004 +#define MIIM_DM9161_INTR_INIT 0x0000 +#define MIIM_DM9161_INTR_STOP \ +(MIIM_DM9161_INTR_DPLX_MASK | MIIM_DM9161_INTR_SPD_MASK \ + | MIIM_DM9161_INTR_LINK_MASK | MIIM_DM9161_INTR_MASK) + +/* DM9161 10BT Configuration/Status */ +#define MIIM_DM9161_10BTCSR 0x12 +#define MIIM_DM9161_10BTCSR_INIT 0x7800 + + +#define MIIM_READ_COMMAND 0x00000001 + +/* + * struct phy_cmd: A command for reading or writing a PHY register + * + * mii_reg: The register to read or write + * + * mii_data: For writes, the value to put in the register. + * A value of -1 indicates this is a read. + * + * funct: A function pointer which is invoked for each command. + * For reads, this function will be passed the value read + * from the PHY, and process it. + * For writes, the result of this function will be written + * to the PHY register + */ +struct phy_cmd { + u32 mii_reg; + u32 mii_data; + u16 (*funct) (u16 mii_reg, struct net_device * dev); +}; + +/* struct phy_info: a structure which defines attributes for a PHY + * + * id will contain a number which represents the PHY. During + * startup, the driver will poll the PHY to find out what its + * UID--as defined by registers 2 and 3--is. The 32-bit result + * gotten from the PHY will be shifted right by "shift" bits to + * discard any bits which may change based on revision numbers + * unimportant to functionality + * + * The struct phy_cmd entries represent pointers to an arrays of + * commands which tell the driver what to do to the PHY. + */ +struct phy_info { + u32 id; + char *name; + unsigned int shift; + /* Called to configure the PHY, and modify the controller + * based on the results */ + const struct phy_cmd *config; + + /* Called when starting up the controller. Usually sets + * up the interrupt for state changes */ + const struct phy_cmd *startup; + + /* Called inside the interrupt handler to acknowledge + * the interrupt */ + const struct phy_cmd *ack_int; + + /* Called in the bottom half to handle the interrupt */ + const struct phy_cmd *handle_int; + + /* Called when bringing down the controller. Usually stops + * the interrupts from being generated */ + const struct phy_cmd *shutdown; +}; + +struct phy_info *get_phy_info(struct net_device *dev); +void phy_run_commands(struct net_device *dev, const struct phy_cmd *cmd); + +#endif /* GIANFAR_PHY_H */ --------------050005000108000809040404-- From phyprabab@yahoo.com Mon Jul 5 11:17:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 11:17:56 -0700 (PDT) Received: from web51808.mail.yahoo.com (web51808.mail.yahoo.com [206.190.38.239]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65IHqgi024403 for ; Mon, 5 Jul 2004 11:17:52 -0700 Message-ID: <20040705181747.83811.qmail@web51808.mail.yahoo.com> Received: from [158.140.2.102] by web51808.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 11:17:47 PDT Date: Mon, 5 Jul 2004 11:17:47 -0700 (PDT) From: Phy Prabab Subject: Re: [still problems] Re: Slow internet access for 2.6.7bk15&16 To: bert hubert Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040705053504.GA2602@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: phyprabab@yahoo.com Precedence: bulk X-list: netdev Content-Length: 2586 Lines: 101 Appreciate the tips and help! Phy --- bert hubert wrote: > On Sun, Jul 04, 2004 at 04:28:52PM -0700, Phy Prabab > wrote: > > Okay, so, I checked the latest bk (17) and found > that > > the fix indicated by the below link has already > made > > it in and still I see the slow down in ftp > transfers > > in comparison to 2.6.6 and 2.4.x kernels. Any > > suggestions? > > I've forwarded your message to netdev@oss.sgi.com, > but see also > http://groups.google.com/groups?selm=2emz3-6GV-5%40gated-at.bofh.it&output=gplain > > Good luck! > > > > > Dual Opteron > > Broadcom Ge > > using tg3 > > > > Thanks! > > Phy > > --- bert hubert wrote: > > > On Sat, Jul 03, 2004 at 07:41:12PM -0700, Phy > Prabab > > > wrote: > > > > Heelo, > > > > > > > > I have been watching a thread concerning the > slow > > > down > > > > with accessing some websites but have not > found a > > > > resolution to the issue. > > > > > > Probably fixed by > > > > > > http://linus.bkbits.net:8080/linux-2.5/cset@40e47ae2tQ_PIxw_HStw3YgsdJFHow?nav=index.html|ChangeSet@-4d > > > > > > -- > > > http://www.PowerDNS.com Open source, > database > > > driven DNS Software > > > http://lartc.org Linux Advanced > Routing & > > > Traffic Control HOWTO > > > - > > > To unsubscribe from this list: send the line > > > "unsubscribe linux-kernel" in > > > the body of a message to > majordomo@vger.kernel.org > > > More majordomo info at > > > http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > New and Improved Yahoo! Mail - Send 10MB messages! > > http://promotions.yahoo.com/new_mail > > - > > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at > http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > http://www.PowerDNS.com Open source, database > driven DNS Software > http://lartc.org Linux Advanced Routing & > Traffic Control HOWTO > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From phyprabab@yahoo.com Mon Jul 5 11:51:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 11:51:47 -0700 (PDT) Received: from web51808.mail.yahoo.com (web51808.mail.yahoo.com [206.190.38.239]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65Ipigi025261 for ; Mon, 5 Jul 2004 11:51:44 -0700 Message-ID: <20040705185138.96848.qmail@web51808.mail.yahoo.com> Received: from [158.140.2.102] by web51808.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 11:51:38 PDT Date: Mon, 5 Jul 2004 11:51:38 -0700 (PDT) From: Phy Prabab Subject: Re: [still problems] Re: Slow internet access for 2.6.7bk15&16 To: Phy Prabab , bert hubert Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040705181747.83811.qmail@web51808.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: phyprabab@yahoo.com Precedence: bulk X-list: netdev Content-Length: 3785 Lines: 155 Hello, Concerning my issue with ftp'ing from remote sites, using these sysctl's I was able to get the performance back: net.ipv4.tcp_default_win_scale=0 net.ipv4.tcp_moderate_rcvbuf=0 2.6.7-bk18 w/out sysctls: 2573621 bytes received in 2e+02 seconds (12 Kbytes/s) ftp> by 2.6.7-bk18 w/sysctls: 2573621 bytes received in 0.69 seconds (3.6e+03 Kbytes/s) ftp> by I am curious why I must set these on the newer kernels or is this something that is being addressed? Is this an issue with firewalls? Thank you for your time. Phy --- Phy Prabab wrote: > Appreciate the tips and help! > Phy > > --- bert hubert wrote: > > On Sun, Jul 04, 2004 at 04:28:52PM -0700, Phy > Prabab > > wrote: > > > Okay, so, I checked the latest bk (17) and found > > that > > > the fix indicated by the below link has already > > made > > > it in and still I see the slow down in ftp > > transfers > > > in comparison to 2.6.6 and 2.4.x kernels. Any > > > suggestions? > > > > I've forwarded your message to netdev@oss.sgi.com, > > but see also > > > http://groups.google.com/groups?selm=2emz3-6GV-5%40gated-at.bofh.it&output=gplain > > > > Good luck! > > > > > > > > Dual Opteron > > > Broadcom Ge > > > using tg3 > > > > > > Thanks! > > > Phy > > > --- bert hubert wrote: > > > > On Sat, Jul 03, 2004 at 07:41:12PM -0700, Phy > > Prabab > > > > wrote: > > > > > Heelo, > > > > > > > > > > I have been watching a thread concerning the > > slow > > > > down > > > > > with accessing some websites but have not > > found a > > > > > resolution to the issue. > > > > > > > > Probably fixed by > > > > > > > > > > http://linus.bkbits.net:8080/linux-2.5/cset@40e47ae2tQ_PIxw_HStw3YgsdJFHow?nav=index.html|ChangeSet@-4d > > > > > > > > -- > > > > http://www.PowerDNS.com Open source, > > database > > > > driven DNS Software > > > > http://lartc.org Linux Advanced > > Routing & > > > > Traffic Control HOWTO > > > > - > > > > To unsubscribe from this list: send the line > > > > "unsubscribe linux-kernel" in > > > > the body of a message to > > majordomo@vger.kernel.org > > > > More majordomo info at > > > > http://vger.kernel.org/majordomo-info.html > > > > Please read the FAQ at > http://www.tux.org/lkml/ > > > > > > > > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > New and Improved Yahoo! Mail - Send 10MB > messages! > > > http://promotions.yahoo.com/new_mail > > > - > > > To unsubscribe from this list: send the line > > "unsubscribe linux-kernel" in > > > the body of a message to > majordomo@vger.kernel.org > > > More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > -- > > http://www.PowerDNS.com Open source, database > > driven DNS Software > > http://lartc.org Linux Advanced Routing > & > > Traffic Control HOWTO > > - > > To unsubscribe from this list: send the line > > "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From kuznet@ms2.inr.ac.ru Mon Jul 5 13:28:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 13:28:04 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65KS0gi031481 for ; Mon, 5 Jul 2004 13:28:01 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id AAA21380; Tue, 6 Jul 2004 00:27:27 +0400 Date: Tue, 6 Jul 2004 00:27:27 +0400 From: Alexey Kuznetsov To: jamal Cc: "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: bk16 changes to cbq Message-ID: <20040705202727.GA21226@ms2.inr.ac.ru> References: <1088861810.1039.298.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1088861810.1039.298.camel@jzny.localdomain> User-Agent: Mutt/1.5.6i X-archive-position: 6619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 586 Lines: 16 Hello! > What i remember is this (4-5 years back) used to cure a bug - cant > remember the details unfortunately, but Alexey may remember. Actually, I do not. It looks like an optimization: if the device is throttled we just do not need to add timer, qdisc will be woken up by unthrottle. I do not see any race condition here, but also I do not see why this check could be important. > At the expense of repeating a discussion that may have already happened, To be honest, I wish to be reminded. If this check cured something, it would be interesting to know what was this. Alexey From davem@redhat.com Mon Jul 5 15:38:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 15:38:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65Mc4gi003373 for ; Mon, 5 Jul 2004 15:38:05 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65Mc3e1005841; Mon, 5 Jul 2004 18:38:03 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65Mc3019443; Mon, 5 Jul 2004 18:38:03 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65MbZ8H004586; Mon, 5 Jul 2004 18:37:35 -0400 Date: Mon, 5 Jul 2004 15:35:38 -0700 From: "David S. Miller" To: Jaap Keuter Cc: netdev@oss.sgi.com Subject: Re: [PATCH] broadcast address on subnet Message-Id: <20040705153538.51efe4a5.davem@redhat.com> In-Reply-To: <20040630125858.K68876-100000@xs1.xs4all.nl> References: <20040630125858.K68876-100000@xs1.xs4all.nl> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 627 Lines: 15 On Wed, 30 Jun 2004 13:02:16 +0200 (CEST) Jaap Keuter wrote: > Digging a bit deeper revealed that it actually is an issue with > SIOIFNETMASK. Once you bring up an interface with SIOIFADDR, a classfull > netmask and broadcast address is set (if applicable for the type of > interface), in order to get a properly configured interface. But if you > subnet the network using SIOIFNETMASK no proper broadcast address is > set. So you always have to calculate it yourself, obviously leading to > configuration errors. Indeed that's odd behavior. I like this patch and will apply it to my trees. Thanks. From davem@redhat.com Mon Jul 5 15:49:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 15:49:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65MnIgi003852 for ; Mon, 5 Jul 2004 15:49:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65Mn5e1007827; Mon, 5 Jul 2004 18:49:05 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65Mn5022083; Mon, 5 Jul 2004 18:49:05 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65MmaZF007496; Mon, 5 Jul 2004 18:48:37 -0400 Date: Mon, 5 Jul 2004 15:46:39 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: Check connect address in NETLINK Message-Id: <20040705154639.5c827df6.davem@redhat.com> In-Reply-To: <20040630124050.GA1619@gondor.apana.org.au> References: <20040628231439.GA3021@gondor.apana.org.au> <20040629082252.GA26866@ms2.inr.ac.ru> <20040629084552.GA6202@gondor.apana.org.au> <20040629111433.GA28463@ms2.inr.ac.ru> <20040629111833.GA22880@gondor.apana.org.au> <20040630112751.GA31160@gondor.apana.org.au> <20040630120045.GA7973@ms2.inr.ac.ru> <20040630120828.GA31498@gondor.apana.org.au> <20040630121420.GA8183@ms2.inr.ac.ru> <20040630124050.GA1619@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 442 Lines: 19 On Wed, 30 Jun 2004 22:40:50 +1000 Herbert Xu wrote: > On Wed, Jun 30, 2004 at 04:14:20PM +0400, Alexey Kuznetsov wrote: > > > > cpu 0: cpu1 (or just preempted cpu) > > > > sk = netlink_lookup(...); > > ... closing sk > > netlink_release() clears sk_socket > > > > use sk->sk_socket. Oops. > > Thanks for the example. > > Here is a version that uses sk_state instead. Applied, thanks Herbert. From davem@redhat.com Mon Jul 5 15:50:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 15:50:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65MoOgi004182 for ; Mon, 5 Jul 2004 15:50:25 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65MoIe1008100; Mon, 5 Jul 2004 18:50:18 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65MoH022456; Mon, 5 Jul 2004 18:50:17 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65MnnnN007869; Mon, 5 Jul 2004 18:49:49 -0400 Date: Mon, 5 Jul 2004 15:47:52 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [NETLINK] Return err in netlink_connect Message-Id: <20040705154752.2aab97b9.davem@redhat.com> In-Reply-To: <20040630114144.GA31327@gondor.apana.org.au> References: <20040630114144.GA31327@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 483 Lines: 12 On Wed, 30 Jun 2004 21:41:44 +1000 Herbert Xu wrote: > This patch makes netlink_connect() return the value of err instead of 0. > It doesn't actually make any difference since the current implementation > of netlink_autobind() never fails. But since we went to all this trouble > to check the return status of autobind, might as well return the correct > value :) > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@redhat.com Mon Jul 5 15:51:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 15:51:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65MpMgi004752 for ; Mon, 5 Jul 2004 15:51:23 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65MpKe1008342; Mon, 5 Jul 2004 18:51:20 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65MpK022696; Mon, 5 Jul 2004 18:51:20 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65Mopvg008128; Mon, 5 Jul 2004 18:50:51 -0400 Date: Mon, 5 Jul 2004 15:48:54 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] allow large MTU on dummy net device Message-Id: <20040705154854.7d70728d.davem@redhat.com> In-Reply-To: <20040630113754.5ae6b14a@dell_ss3.pdx.osdl.net> References: <20040630113754.5ae6b14a@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 296 Lines: 9 On Wed, 30 Jun 2004 11:37:54 -0700 Stephen Hemminger wrote: > It is useful for testing to allow larger MTU value to be set on > the dummy network device. The current code limits it to valid Ether mtu's. > > Signed-off-by: Stephen Hemminger Applied. From davem@redhat.com Mon Jul 5 16:02:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:02:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65N21gi005242 for ; Mon, 5 Jul 2004 16:02:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65N1re1010108; Mon, 5 Jul 2004 19:01:53 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65N1r024697; Mon, 5 Jul 2004 19:01:53 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65N1OhU009871; Mon, 5 Jul 2004 19:01:24 -0400 Date: Mon, 5 Jul 2004 15:59:27 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [ESP4] Merge NAT-T code in esp_output Message-Id: <20040705155927.04ffb674.davem@redhat.com> In-Reply-To: <20040701123344.GA11639@gondor.apana.org.au> References: <20040701123344.GA11639@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 329 Lines: 12 On Thu, 1 Jul 2004 22:33:44 +1000 Herbert Xu wrote: > Hi Dave: > > This is another step on the way to distilling the tunnel mode encap > code between AH/ESP/IPCOMP. > > This patch removes the needless duplciation of NAT-T code between > transport mode and tunnel mode ESP4. Looks good, applied. From davem@redhat.com Mon Jul 5 16:05:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:05:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65N5Sgi005633 for ; Mon, 5 Jul 2004 16:05:28 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65N5Pe1010556; Mon, 5 Jul 2004 19:05:25 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65N5P025250; Mon, 5 Jul 2004 19:05:25 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65N4usS010288; Mon, 5 Jul 2004 19:04:57 -0400 Date: Mon, 5 Jul 2004 16:02:59 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 1/1] err1-28: rose_route locking fix Message-Id: <20040705160259.472e5528.davem@redhat.com> In-Reply-To: <200407020812.i628CFG17588@mail.osdl.org> References: <200407020812.i628CFG17588@mail.osdl.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 203 Lines: 9 On Fri, 02 Jul 2004 01:11:17 -0700 akpm@osdl.org wrote: > Fix deadlock in rose_del_loopback_node(). Found by the Stanford locking > checker. > > Signed-off-by: Andrew Morton Applied. From davem@redhat.com Mon Jul 5 16:06:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:06:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65N6Ngi005971 for ; Mon, 5 Jul 2004 16:06:24 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65N6Le1010779; Mon, 5 Jul 2004 19:06:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65N6L025460; Mon, 5 Jul 2004 19:06:21 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65N5q2v010395; Mon, 5 Jul 2004 19:05:52 -0400 Date: Mon, 5 Jul 2004 16:03:55 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 1/1] err1-62: ax25_ds_idletimer_expiry() locking fix Message-Id: <20040705160355.1e730c9a.davem@redhat.com> In-Reply-To: <200407020829.i628TNG20391@mail.osdl.org> References: <200407020829.i628TNG20391@mail.osdl.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 176 Lines: 8 On Fri, 02 Jul 2004 01:28:24 -0700 akpm@osdl.org wrote: > Fix deadlock identified by the Stanford locking checker. > > Signed-off-by: Andrew Morton Applied. From davem@redhat.com Mon Jul 5 16:07:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:07:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65N7Dgi006279 for ; Mon, 5 Jul 2004 16:07:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65N78e1010847; Mon, 5 Jul 2004 19:07:08 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65N78025643; Mon, 5 Jul 2004 19:07:08 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65N6dD4010791; Mon, 5 Jul 2004 19:06:40 -0400 Date: Mon, 5 Jul 2004 16:04:42 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 1/1] err1-67: lapb_unregister() locking fix Message-Id: <20040705160442.26672e91.davem@redhat.com> In-Reply-To: <200407020831.i628VmG20814@mail.osdl.org> References: <200407020831.i628VmG20814@mail.osdl.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 176 Lines: 8 On Fri, 02 Jul 2004 01:30:49 -0700 akpm@osdl.org wrote: > Fix deadlock identified by the Stanford locking checker. > > Signed-off-by: Andrew Morton Applied. From davem@redhat.com Mon Jul 5 16:07:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:07:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65N7igi006569 for ; Mon, 5 Jul 2004 16:07:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65N7ge1010919; Mon, 5 Jul 2004 19:07:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65N7g025754; Mon, 5 Jul 2004 19:07:42 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65N7D3n010820; Mon, 5 Jul 2004 19:07:13 -0400 Date: Mon, 5 Jul 2004 16:05:16 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 1/1] err2-15: ax25_rt_add() locking fix Message-Id: <20040705160516.10c1b23e.davem@redhat.com> In-Reply-To: <200407020847.i628lLG23044@mail.osdl.org> References: <200407020847.i628lLG23044@mail.osdl.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 196 Lines: 10 On Fri, 02 Jul 2004 01:46:23 -0700 akpm@osdl.org wrote: > It can return with the lock held. > > Found by the Stanford locking checker > > Signed-off-by: Andrew Morton Applied. From davem@redhat.com Mon Jul 5 16:10:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:10:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65NA1gi007026 for ; Mon, 5 Jul 2004 16:10:01 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65N9te1011183; Mon, 5 Jul 2004 19:09:55 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65N9t026167; Mon, 5 Jul 2004 19:09:55 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65N9Q3I011333; Mon, 5 Jul 2004 19:09:27 -0400 Date: Mon, 5 Jul 2004 16:07:29 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [AH4] Harmonisation of output function Message-Id: <20040705160729.2986bce2.davem@redhat.com> In-Reply-To: <20040702130652.GA20334@gondor.apana.org.au> References: <20040702130652.GA20334@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 439 Lines: 14 On Fri, 2 Jul 2004 23:06:52 +1000 Herbert Xu wrote: > This is another step towards the union of the tunnel mode encapsulation > between transforms. As there are significant differences between the > tunnel encapsulation of IPv4 and IPv6, I'll be dealing with IPv4 only > for now. > > This particular patch rearranges the code in ah_output to isolate the > tunnel mode encapsulation. Ok, applied. Thanks. From davem@redhat.com Mon Jul 5 16:14:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:14:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65NEMgi007417 for ; Mon, 5 Jul 2004 16:14:24 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65NEFe1011871; Mon, 5 Jul 2004 19:14:15 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65NEF026987; Mon, 5 Jul 2004 19:14:15 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65NDkZF012212; Mon, 5 Jul 2004 19:13:46 -0400 Date: Mon, 5 Jul 2004 16:11:48 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [XFRM] Convert XFRM_MSG_* macros to an enum Message-Id: <20040705161148.503722e7.davem@redhat.com> In-Reply-To: <20040703095215.GA16195@gondor.apana.org.au> References: <20040703095215.GA16195@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 517 Lines: 12 On Sat, 3 Jul 2004 19:52:15 +1000 Herbert Xu wrote: > I'd like to add two new xfrm_user messages, FLUSHSA and FLUSHPOLICY. > > I've cleaned up the existing MSG definitions by converting them to > an enum. This should make future additions slightly easier in that > XFRM_MSG_MAX won't have to be touched again. If we end up needing the define macros anyways, after that discussion with Yoshifuji, I don't see the point to this change any more and therefore I'm not going to apply it. From herbert@gondor.apana.org.au Mon Jul 5 16:21:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:21:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65NLogi010953 for ; Mon, 5 Jul 2004 16:21:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BhcmN-0004QS-00; Tue, 06 Jul 2004 09:21:43 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BhcmL-0002aX-00; Tue, 06 Jul 2004 09:21:41 +1000 Date: Tue, 6 Jul 2004 09:21:41 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [XFRM] Convert XFRM_MSG_* macros to an enum Message-ID: <20040705232141.GA9939@gondor.apana.org.au> References: <20040703095215.GA16195@gondor.apana.org.au> <20040705161148.503722e7.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040705161148.503722e7.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 846 Lines: 21 On Mon, Jul 05, 2004 at 04:11:48PM -0700, David S. Miller wrote: > > > I'd like to add two new xfrm_user messages, FLUSHSA and FLUSHPOLICY. > > > > I've cleaned up the existing MSG definitions by converting them to > > an enum. This should make future additions slightly easier in that > > XFRM_MSG_MAX won't have to be touched again. > > If we end up needing the define macros anyways, after that discussion > with Yoshifuji, I don't see the point to this change any more and > therefore I'm not going to apply it. The point is that with enums we won't have to change XFRM_MSG_MAX every time a new message type is added. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@redhat.com Mon Jul 5 16:33:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:33:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65NX1gi011904 for ; Mon, 5 Jul 2004 16:33:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65NWre1015784; Mon, 5 Jul 2004 19:32:53 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65NWr031979; Mon, 5 Jul 2004 19:32:53 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65NWOpi017425; Mon, 5 Jul 2004 19:32:25 -0400 Date: Mon, 5 Jul 2004 16:30:27 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: rmk+lkml@arm.linux.org.uk, netdev@oss.sgi.com Subject: Re: 2.6.6: IPv6 initialisation bug Message-Id: <20040705163027.31e5d6c0.davem@redhat.com> In-Reply-To: <20040705.123321.91002396.yoshfuji@linux-ipv6.org> References: <20040628184758.C9214@flint.arm.linux.org.uk> <20040629.095903.58985982.yoshfuji@linux-ipv6.org> <20040704170259.A16596@flint.arm.linux.org.uk> <20040705.123321.91002396.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i65NX1gi011904 X-archive-position: 6633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 205 Lines: 9 On Mon, 05 Jul 2004 12:33:21 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > David, please apply. ... > [IPV6] Bring lo up before setting other interface up. Applied. From davem@redhat.com Mon Jul 5 16:43:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:43:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65NhCgi012381 for ; Mon, 5 Jul 2004 16:43:13 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65Nh8e1017641; Mon, 5 Jul 2004 19:43:08 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65Nh8001376; Mon, 5 Jul 2004 19:43:08 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65Ngdgt019356; Mon, 5 Jul 2004 19:42:40 -0400 Date: Mon, 5 Jul 2004 16:40:42 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [IPV6] fix flags for ndisc dst Message-Id: <20040705164042.0493f4c2.davem@redhat.com> In-Reply-To: <20040705.162838.67048785.yoshfuji@linux-ipv6.org> References: <20040705.162838.67048785.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i65NhCgi012381 X-archive-position: 6634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 343 Lines: 11 On Mon, 05 Jul 2004 16:28:38 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Because RTF_LOCAL is for local unicast address, > it was wrong to set RTF_LOCAL to ndisc dst. > This patch also adds some comment on other fields. > > Signed-off-by: Hideaki YOSHIFUJI Applied, thanks. From davem@redhat.com Mon Jul 5 16:44:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:44:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65NiPgi012562 for ; Mon, 5 Jul 2004 16:44:25 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65NiNe1017944; Mon, 5 Jul 2004 19:44:23 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65NiN001694; Mon, 5 Jul 2004 19:44:23 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65NhrAf019780; Mon, 5 Jul 2004 19:43:54 -0400 Date: Mon, 5 Jul 2004 16:41:55 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TCP: inline message Message-Id: <20040705164155.0796edb5.davem@redhat.com> In-Reply-To: <20040705.170050.44266970.yoshfuji@linux-ipv6.org> References: <20040705.170050.44266970.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i65NiPgi012562 X-archive-position: 6635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 261 Lines: 9 On Mon, 05 Jul 2004 17:00:50 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > D: [TCP] Diet using "unknown time value" message in net/ipv4/tcp_timer.c. > > Signed-off-by: Hideaki YOSHIFUJI Applied. From davem@redhat.com Mon Jul 5 16:45:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:45:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65Njrgi013043 for ; Mon, 5 Jul 2004 16:45:54 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65Njpe1018365; Mon, 5 Jul 2004 19:45:51 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65Njp002093; Mon, 5 Jul 2004 19:45:51 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65NjM2Z020148; Mon, 5 Jul 2004 19:45:22 -0400 Date: Mon, 5 Jul 2004 16:43:24 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NET: save space for dst underflow message Message-Id: <20040705164324.11d4eaa7.davem@redhat.com> In-Reply-To: <20040705.170053.22377235.yoshfuji@linux-ipv6.org> References: <20040705.170053.22377235.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i65Njrgi013043 X-archive-position: 6636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 227 Lines: 9 On Mon, 05 Jul 2004 17:00:53 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Save space for "dst underflow" message. > > Signed-off-by: Hideaki YOSHIFUJI Applied. From davem@redhat.com Mon Jul 5 16:49:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 16:49:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i65Nnngi013408 for ; Mon, 5 Jul 2004 16:49:49 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i65Nnfe1018987; Mon, 5 Jul 2004 19:49:41 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i65Nnf002889; Mon, 5 Jul 2004 19:49:41 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i65NnCcj021003; Mon, 5 Jul 2004 19:49:12 -0400 Date: Mon, 5 Jul 2004 16:47:14 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [XFRM] Convert XFRM_MSG_* macros to an enum Message-Id: <20040705164714.5aac5b62.davem@redhat.com> In-Reply-To: <20040705232141.GA9939@gondor.apana.org.au> References: <20040703095215.GA16195@gondor.apana.org.au> <20040705161148.503722e7.davem@redhat.com> <20040705232141.GA9939@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 207 Lines: 7 On Tue, 6 Jul 2004 09:21:41 +1000 Herbert Xu wrote: > The point is that with enums we won't have to change XFRM_MSG_MAX > every time a new message type is added. Ok, applied. From hadi@cyberus.ca Mon Jul 5 18:28:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 18:28:34 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i661STgi015922 for ; Mon, 5 Jul 2004 18:28:30 -0700 Received: from mx01.cybersurf.com ([IPv6:::ffff:209.197.145.104]:44188 "EHLO mx01.cybersurf.com") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 02:28:28 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Bhekw-0003WZ-0v for netdev@linux-mips.org; Mon, 05 Jul 2004 21:28:22 -0400 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 1Bhekp-0007XC-K5; Mon, 05 Jul 2004 21:28:15 -0400 Subject: Re: bk16 changes to cbq From: jamal Reply-To: hadi@cyberus.ca To: Alexey Kuznetsov Cc: "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com In-Reply-To: <20040705202727.GA21226@ms2.inr.ac.ru> References: <1088861810.1039.298.camel@jzny.localdomain> <20040705202727.GA21226@ms2.inr.ac.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089077288.1068.5.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jul 2004 21:28:09 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 888 Lines: 26 On Mon, 2004-07-05 at 16:27, Alexey Kuznetsov wrote: > Hello! > > > What i remember is this (4-5 years back) used to cure a bug - cant > > remember the details unfortunately, but Alexey may remember. > > Actually, I do not. It looks like an optimization: if the device is > throttled we just do not need to add timer, qdisc will be woken up > by unthrottle. I do not see any race condition here, but also I do not > see why this check could be important. Indeed it looks like an optimization; instead of two events (queue watchdog and probably EOL )or device wdog) trying to reschedule device, only one does. > > At the expense of repeating a discussion that may have already happened, > > To be honest, I wish to be reminded. If this check cured something, > it would be interesting to know what was this. I searched the archives couldnt find anything relevant. cheers, jamal From hadi@cyberus.ca Mon Jul 5 19:38:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 19:38:36 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i662cWgi018383 for ; Mon, 5 Jul 2004 19:38:33 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1Bhfqr-0001Sx-5a for netdev@oss.sgi.com; Mon, 05 Jul 2004 22:38:33 -0400 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 1Bhfqj-0006Lr-2S; Mon, 05 Jul 2004 22:38:25 -0400 Subject: Re: [RFR] gianfar ethernet driver From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Kumar Gala , Netdev , David Woodhouse In-Reply-To: <40E98FB8.4070900@pobox.com> References: <8F52CF1D-C916-11D8-BB6A-000393DBC2E8@freescale.com> <40E98FB8.4070900@pobox.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089081499.1068.66.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Jul 2004 22:38:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2090 Lines: 71 On Mon, 2004-07-05 at 13:28, Jeff Garzik wrote: > (CC to netdev added) > > Kumar, > > I've merged the gianfar driver into my netdev-2.6 queue. This will get > it automatically propagated into the -mm tree, and once some of these > comments are resolved/discussed, pushed upstream as well. > > Follow-up patches should be incremental to this (your) patch. > > > Others, > > I've attached the patch as Kumar submitted it. Please review. > > > > Comments: Some pretty good comments there Jeff. > 1) Share the knowledge. Please CC comments (and criticisms!) to netdev. > > 2) I'm strongly pondering vetoing try_fastroute() code in this driver. > Surely this should be in core net stack code... if it isn't already? Jamal? I hardly know anybody still using this interface - i believe it is not useful after NAPI; maybe this comment would bring out some of the believers out of the woodwork to comment. Otherwise i would say kill it. > 8) I recommend enabling _both_ hardware interrupt coalescing and NAPI, > at the same time. Several other Linux net drivers need to be changed to > do this, as well Under low rates having both helps (by reducing the amount of PCI operations - at the expense of some added latency) > 18) As Jamal recently noted, no need to test netif_queue_stopped() > Since it is a new driver why dont we have him do more work? ;-> 1) The check (in gfar_start_xmit()): Should happen much sooner - i.e before the skb is touched. if (txbdp == priv->dirty_tx) { netif_stop_queue(dev) unlock return 1; } The rest of your code goes here .. Do this before the skb is touched. Note the return 1. This means dont add it to your priv->tx_skbuff[priv->skb_curtx] = skb before you do this. Dont understand why you have your own proivate list btw. 2) Also its pretty scary if you are doing: txbdp->status |= TXBD_INTERRUPT for every packet. Look at other drivers, they try to do this every few packets; or enable tx mitigation to slow the rate of those interupts. cheers, jamal From davem@redhat.com Mon Jul 5 19:52:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 19:52:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i662qEgi018857 for ; Mon, 5 Jul 2004 19:52:15 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i662pte1025908; Mon, 5 Jul 2004 22:51:55 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i662pt010589; Mon, 5 Jul 2004 22:51:55 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i662pQGK027312; Mon, 5 Jul 2004 22:51:26 -0400 Date: Mon, 5 Jul 2004 19:49:25 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: shemminger@osdl.org, util@deuroconsult.ro, netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040705194925.37b7efcb.davem@redhat.com> In-Reply-To: <1088824432.1043.271.camel@jzny.localdomain> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 96 Lines: 3 I'm going to hold off on Stephen's patches until Jamal and he has a chance to fight it out :-) From andreum@gmail.com Mon Jul 5 20:33:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jul 2004 20:33:22 -0700 (PDT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.253]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i663XLgi023135 for ; Mon, 5 Jul 2004 20:33:21 -0700 Received: by mproxy.gmail.com with SMTP id q44so3767258cwc for ; Mon, 05 Jul 2004 20:33:15 -0700 (PDT) Received: by 10.11.99.11 with SMTP id w11mr384508cwb; Mon, 05 Jul 2004 20:33:15 -0700 (PDT) Message-ID: Date: Tue, 6 Jul 2004 00:33:15 -0300 From: Andre Uratsuka Manoel Reply-To: andre@insite.com.br To: netdev@oss.sgi.com Subject: route cache overflow Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andreum@gmail.com Precedence: bulk X-list: netdev Content-Length: 659 Lines: 19 Hello, It seems that no resolution was found for the route cache DoS issue (am I wrong here?). I was wondering, and I'd like to persue this line of thought if you don't consider this stupid: wouldn't it be better, when we find that the machine is under DoS to avoid creating route cache entries instead of simply trying to drop entries that exist? Couldn't we create entries only once for every 1<; Tue, 6 Jul 2004 00:05:11 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BgkhM-0006j6-BJ for netdev@oss.sgi.com; Sat, 03 Jul 2004 09:36:56 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BgkhK-0006bf-0j; Sat, 03 Jul 2004 09:36:54 -0400 Subject: bk16 changes to cbq From: jamal Reply-To: hadi@cyberus.ca To: Alexey , "David S. Miller" Cc: Stephen Hemminger , netdev@oss.sgi.com Content-Type: text/plain Organization: jamalopolis Message-Id: <1088861810.1039.298.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jul 2004 09:36:50 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 916 Lines: 27 I am noticing this in bk16; it may be one of the changes that came from Stephen recently.. --- a/net/sched/sch_cbq.c 2004-02-20 18:37:25 -08:00 +++ b/net/sched/sch_cbq.c 2004-06-18 13:51:18 -07:00 @@ -1054,7 +1054,7 @@ if (sch->q.qlen) { sch->stats.overlimits++; - if (q->wd_expires && !netif_queue_stopped(sch->dev)) { + if (q->wd_expires) { long delay = PSCHED_US2JIFFIE(q->wd_expires); if (delay <= 0) delay = 1; What i remember is this (4-5 years back) used to cure a bug - cant remember the details unfortunately, but Alexey may remember. I am hoping removal of the above line implies that those conditions dont exist anymore? At the expense of repeating a discussion that may have already happened, what was the logic for removing this line? cheers, jamal From ahu@outpost.ds9a.nl Tue Jul 6 03:18:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 03:18:06 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66AHrgi007083 for ; Tue, 6 Jul 2004 03:17:53 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A16B1400E; Tue, 6 Jul 2004 11:35:03 +0200 (CEST) Date: Tue, 6 Jul 2004 11:35:03 +0200 From: bert hubert To: Arnaldo Carvalho de Melo Cc: "David S. Miller" , "linux-kernel @ vger. kernel. org Stephen Hemminger" , netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com Subject: analysis of TCP window size issues still around - several reports / SACK involved? Message-ID: <20040706093503.GA8147@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Arnaldo Carvalho de Melo , "David S. Miller" , "linux-kernel @ vger. kernel. org Stephen Hemminger" , netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040702013225.GA24707@conectiva.com.br> User-Agent: Mutt/1.3.28i X-archive-position: 6650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 3244 Lines: 77 On Thu, Jul 01, 2004 at 10:32:25PM -0300, Arnaldo Carvalho de Melo wrote: > > > Rather than using *tcp_prot.memory_pressure, just go back to looking at > > > tcp_memory_pressure. > > > > Hehe, applied thanks Stephen. People, There are still persistent reports of TCP problems, even after patching away the memory_pressure pointer problem. From one trace I've seen, by Alessandro Suardi, but I lack the SACK knowledge to fully interpret these traces: 22:42:40.890025 192.168.1.6.32843 > 204.152.189.116.http: S 1994994484:1994994484(0) win 5840 (DF) 22:42:41.143063 204.152.189.116.http > 192.168.1.6.32843: S 1404108869:1404108869(0) ack 1994994485 win 5792 (DF) 22:42:41.143123 192.168.1.6.32843 > 204.152.189.116.http: . ack 1 win 45 (DF) Alessandro's machine does perform window scaling, tcpdump however does not understand that and neglects to multiply 45 by 2^7 (=5760). Kernel.org does do wscale, but defaults to 2^0. 22:42:41.143362 192.168.1.6.32843 > 204.152.189.116.http: P 1:421(420) ack 1 win 45 (DF) Alessandro's machine sends a GET request. 22:42:41.147669 204.152.189.116.http > 192.168.1.6.32843: S 1404108869:1404108869(0) ack 1994994485 win 5792 (DF) www.kernel.org acts like it did not see our ACK. 22:42:41.147723 192.168.1.6.32843 > 204.152.189.116.http: . ack 1 win 45 (DF) Allessandro's machine sends a selective ACK - could have gotten away with a regular one I'd think? 22:42:41.408763 204.152.189.116.http > 192.168.1.6.32843: . ack 421 win 6432 (DF) www.kernel.org acks the GET, but from then on does not send anything. After a minute, Alessandro gets bored and presses STOP in Mozilla: 22:43:41.051537 192.168.1.6.32843 > 204.152.189.116.http: F 421:421(0) ack 1 win 45 (DF) k.o acks this FIN, but also sends a selective ack: 22:43:41.304371 204.152.189.116.http > 192.168.1.6.32843: . ack 422 win 6432 (DF) Here are the underlying reports: http://lkml.org/lkml/2004/7/4/116 (Alessandro Suardi) The _only_ site I found I can browse without disabling TCP window scaling is http://www.google.it. tcpdump at: http://xoomer.virgilio.it/incident/tcpdump.out http://lkml.org/lkml/2004/7/5/105 (Phy Prabab) Concerning my issue with ftp'ing from remote sites, using these sysctl's I was able to get the performance back: net.ipv4.tcp_default_win_scale=0 net.ipv4.tcp_moderate_rcvbuf=0 2.6.7-bk18 w/out sysctls: 2573621 bytes received in 2e+02 seconds (12 Kbytes/s) 2.6.7-bk18 w/sysctls: 2573621 bytes received in 0.69 seconds (3.6e+03 Kbytes/s) These both refer to bk after the *tcp_prot.memory_pressure patch was applied. Thanks for your attention. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From hch@lst.de Tue Jul 6 03:36:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 03:36:53 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Aamgi007642 for ; Tue, 6 Jul 2004 03:36:49 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i66AakQc014550 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Jul 2004 12:36:46 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i66AajTd014548; Tue, 6 Jul 2004 12:36:45 +0200 Date: Tue, 6 Jul 2004 12:36:45 +0200 From: Christoph Hellwig To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [PATCH] allow modular mv64340_eth Message-ID: <20040706103645.GA14521@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 2802 Lines: 110 Only tested together with some additional patches to make the driver work on PPC that need more work, but the changes are obvious. --- a/drivers/net/Kconfig~ 2004-07-06 14:32:32.380761120 +0200 +++ b/drivers/net/Kconfig 2004-07-06 14:32:40.494527640 +0200 @@ -2132,7 +2132,7 @@ will be called tg3. This is recommended. config MV64340_ETH - bool "MV-64340 Ethernet support" + tristate "MV-64340 Ethernet support" depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX help This driver supports the gigabit Ethernet on the Marvell MV64340 --- a/drivers/net/mv64340_eth.c~ 2004-07-06 14:26:47.163242160 +0200 +++ b/drivers/net/mv64340_eth.c 2004-07-06 14:32:15.198373240 +0200 @@ -1316,7 +1316,7 @@ * Input : number of port to initialize * Output : -ENONMEM if failed , 0 if success */ -static int mv64340_eth_init(int port_num) +static struct net_device *mv64340_eth_init(int port_num) { struct mv64340_private *mp; struct net_device *dev; @@ -1324,7 +1324,7 @@ dev = alloc_etherdev(sizeof(struct mv64340_private)); if (!dev) - return -ENOMEM; + return NULL; mp = netdev_priv(dev); @@ -1395,14 +1395,27 @@ printk("RX NAPI Enabled \n"); #endif - return 0; + return dev; out_free_dev: free_netdev(dev); - return err; + return NULL; +} + +static void mv64340_eth_remove(struct net_device *dev) +{ + struct mv64340_private *mp = netdev_priv(dev); + + unregister_netdev(dev); + flush_scheduled_work(); + free_netdev(dev); } +static struct net_device *mv64340_dev0; +static struct net_device *mv64340_dev1; +static struct net_device *mv64340_dev2; + /* * mv64340_init_module * @@ -1415,20 +1428,24 @@ static int __init mv64340_init_module(void) { printk(KERN_NOTICE "MV-64340 10/100/1000 Ethernet Driver\n"); + #ifdef CONFIG_MV64340_ETH_0 - if (mv64340_eth_init(0)) { + mv64340_dev0 = mv64340_eth_init(0); + if (!mv64340_dev0) { printk(KERN_ERR "Error registering MV-64360 ethernet port 0\n"); } #endif #ifdef CONFIG_MV64340_ETH_1 - if (mv64340_eth_init(1)) { + mv64340_dev1 = mv64340_eth_init(1); + if (!mv64340_dev1) { printk(KERN_ERR "Error registering MV-64360 ethernet port 1\n"); } #endif #ifdef CONFIG_MV64340_ETH_2 - if (mv64340_eth_init(2)) { + mv64340_dev2 = mv64340_eth_init(2); + if (!mv64340_dev2) { printk(KERN_ERR "Error registering MV-64360 ethernet port 2\n"); } @@ -1445,9 +1462,14 @@ * * Output : N/A */ -static void __init mv64340_cleanup_module(void) +static void __exit mv64340_cleanup_module(void) { - /* Nothing to do here ! it's not a removable module */ + if (mv64340_dev2) + mv64340_eth_remove(mv64340_dev2); + if (mv64340_dev1) + mv64340_eth_remove(mv64340_dev1); + if (mv64340_dev0) + mv64340_eth_remove(mv64340_dev0); } module_init(mv64340_init_module); From hch@lst.de Tue Jul 6 03:52:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 03:52:20 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66AqHgi008181 for ; Tue, 6 Jul 2004 03:52:18 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i66AqGQc014745 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Jul 2004 12:52:16 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i66AqFfw014743; Tue, 6 Jul 2004 12:52:15 +0200 Date: Tue, 6 Jul 2004 12:52:15 +0200 From: Christoph Hellwig To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [PATCH] fix compiler warnings in mv64340_eth Message-ID: <20040706105215.GA14731@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 2093 Lines: 56 The driver was trying to do pointer arithmetic on integers but forgot half of the casts.. Let's just do normal integer arithmetics instead. --- drivers/net/mv64340_eth.c~ 2004-07-06 14:26:47.163242160 +0200 +++ drivers/net/mv64340_eth.c 2004-07-06 14:48:31.053020784 +0200 @@ -752,9 +752,8 @@ p_rx_desc[i].byte_cnt = 0x0000; p_rx_desc[i].cmd_sts = ETH_BUFFER_OWNED_BY_DMA | ETH_RX_ENABLE_INTERRUPT; - p_rx_desc[i].next_desc_ptr = - (struct eth_rx_desc *) mp->rx_desc_dma + - (i + 1) % rx_desc_num; + p_rx_desc[i].next_desc_ptr = mp->rx_desc_dma + + ((i + 1) % rx_desc_num) * sizeof(struct eth_rx_desc); p_rx_desc[i].buf_ptr = buffer_addr; mp->rx_skb[i] = NULL; @@ -818,9 +817,8 @@ p_tx_desc[i].byte_cnt = 0x0000; p_tx_desc[i].l4i_chk = 0x0000; p_tx_desc[i].cmd_sts = 0x00000000; - p_tx_desc[i].next_desc_ptr = - (struct eth_tx_desc *) mp->tx_desc_dma + - (i + 1) % tx_desc_num; + p_tx_desc[i].next_desc_ptr = mp->tx_desc_dma + + ((i + 1) % tx_desc_num) * sizeof(struct eth_tx_desc); p_tx_desc[i].buf_ptr = 0x00000000; mp->tx_skb[i] = NULL; } @@ -2329,8 +2349,8 @@ first_descriptor->cmd_sts = command_status; first_descriptor->byte_cnt = p_pkt_info->byte_cnt; first_descriptor->buf_ptr = p_pkt_info->buf_ptr; - first_descriptor->next_desc_ptr = - (struct eth_tx_desc *) mp->tx_desc_dma + tx_next_desc; + first_descriptor->next_desc_ptr = mp->tx_desc_dma + + tx_next_desc * sizeof(struct eth_tx_desc); wmb(); } else { tx_first_desc = mp->tx_first_desc_q; @@ -2343,8 +2363,8 @@ current_descriptor->next_desc_ptr = 0x00000000; else { command_status |= ETH_BUFFER_OWNED_BY_DMA; - current_descriptor->next_desc_ptr = - (struct eth_tx_desc *) mp->tx_desc_dma + tx_next_desc; + current_descriptor->next_desc_ptr = mp->tx_desc_dma + + tx_next_desc * sizeof(struct eth_tx_desc); } } From ALESSANDRO.SUARDI@ORACLE.COM Tue Jul 6 05:31:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 05:31:59 -0700 (PDT) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66CVtgi020216 for ; Tue, 6 Jul 2004 05:31:55 -0700 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i66CWQfU019169; Tue, 6 Jul 2004 05:32:31 -0700 (PDT) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i66CUpRQ009832; Tue, 6 Jul 2004 06:30:51 -0600 Received: from web265.oracle.com (web265.oracle.com [148.87.122.175]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i66CUpiY009811; Tue, 6 Jul 2004 06:30:51 -0600 Message-ID: <6913615.1089117051125.JavaMail.oracle@web265.oracle.com> Date: Tue, 6 Jul 2004 06:30:51 -0600 (MDT) From: ALESSANDRO.SUARDI@ORACLE.COM To: bert hubert , Arnaldo Carvalho de Melo Subject: Re: analysis of TCP window size issues still around - several reports / SACK involved? Cc: "David S. Miller" , "linux-kernel @ vger. kernel. org Stephen Hemminger" , netdev@oss.sgi.com, phyprabab@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-Mailer: Oracle Webmail Client(UIX) X-archive-position: 6657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ALESSANDRO.SUARDI@ORACLE.COM Precedence: bulk X-list: netdev Content-Length: 4182 Lines: 151 Hi all, sorry about the silly formatting, but the webmail client isn't really nice in this respect :( Further data points: -bk18 built with GCC 3.4.1 still hangs talking to most of the world except google.it (redirected from google.com) from my home DSL (US Robotics USR9003 router). It _works_ without changing anything when in my office (unsure about hardware there). It _also_ works from my home _if_ I fire up the Cisco VPN client (4.0.4.B) to an Oracle VPN server and access the 'net (kernel.org and all) via our proxies through the VPN. Hope that helps, and sorry for top-posting. Bert Hubert wrote: > On Thu, Jul 01, 2004 at 10:32:25PM -0300, > Arnaldo Carvalho de Melo wrote: > > > > > Rather than using > *tcp_prot.memory_pressure, just go back to > looking at > > > > tcp_memory_pressure. > > > > > > Hehe, applied thanks Stephen. > > People, > > There are still persistent reports of TCP > problems, even after patching away > the memory_pressure pointer problem. From one > trace I've seen, by Alessandro > Suardi, but I lack the SACK knowledge to fully > interpret these traces: > > 22:42:40.890025 192.168.1.6.32843 > > 204.152.189.116.http: S 1994994484:1994994484(0) > win 5840 0,nop,wscale 7> (DF) > 22:42:41.143063 204.152.189.116.http > > 192.168.1.6.32843: S 1404108869:1404108869(0) > ack 1994994485 win 5792 1452,sackOK,timestamp 3383469176 > 4294940315,nop,wscale 0> (DF) > 22:42:41.143123 192.168.1.6.32843 > > 204.152.189.116.http: . ack 1 win 45 > (DF) > > Alessandro's machine does perform window > scaling, tcpdump however does not > understand that and neglects to multiply 45 by > 2^7 (=5760). Kernel.org does do > wscale, but defaults to 2^0. > > 22:42:41.143362 192.168.1.6.32843 > > 204.152.189.116.http: P 1:421(420) ack 1 win 45 > (DF) > > Alessandro's machine sends a GET request. > > 22:42:41.147669 204.152.189.116.http > > 192.168.1.6.32843: S 1404108869:1404108869(0) > ack 1994994485 win 5792 1452,sackOK,timestamp 3383469180 > 4294940315,nop,wscale 0> (DF) > > www.kernel.org acts like it did not see our ACK. > > > 22:42:41.147723 192.168.1.6.32843 > > 204.152.189.116.http: . ack 1 win 45 > 3383469180,nop,nop,sack sack 1 {0:1} > (DF) > > Allessandro's machine sends a selective ACK - > could have gotten away with a > regular one I'd think? > > 22:42:41.408763 204.152.189.116.http > > 192.168.1.6.32843: . ack 421 win 6432 > (DF) > > www.kernel.org acks the GET, but from then on > does not send anything. > > After a minute, Alessandro gets bored and > presses STOP in Mozilla: > > 22:43:41.051537 192.168.1.6.32843 > > 204.152.189.116.http: F 421:421(0) ack 1 win 45 > (DF) > > k.o acks this FIN, but also sends a selective > ack: > > 22:43:41.304371 204.152.189.116.http > > 192.168.1.6.32843: . ack 422 win 6432 > sack 1 {421:422} > (DF) > > Here are the underlying reports: > > http://lkml.org/lkml/2004/7/4/116 (Alessandro > Suardi) > The _only_ site I found I can browse without > disabling TCP > window scaling is http://www.google.it. > > tcpdump at: > http://xoomer.virgilio.it/incident/tcpdump.out > > http://lkml.org/lkml/2004/7/5/105 (Phy Prabab) > Concerning my issue with ftp'ing from remote > sites, > using these sysctl's I was able to get the > performance > back: > > net.ipv4.tcp_default_win_scale=0 > net.ipv4.tcp_moderate_rcvbuf=0 > > 2.6.7-bk18 w/out sysctls: > 2573621 bytes received in 2e+02 seconds (12 > Kbytes/s) > > 2.6.7-bk18 w/sysctls: > 2573621 bytes received in 0.69 seconds (3.6e+03 > > Kbytes/s) > > These both refer to bk after the > *tcp_prot.memory_pressure patch was > applied. > > Thanks for your attention. > > -- > http://www.PowerDNS.com Open source, > database driven DNS Software > http://lartc.org Linux Advanced > Routing & Traffic Control HOWTO > --alessandro From herbert@gondor.apana.org.au Tue Jul 6 05:31:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 05:31:50 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66CVggi020205 for ; Tue, 6 Jul 2004 05:31:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bhp6i-000745-00; Tue, 06 Jul 2004 22:31:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bhp6e-0004lE-00; Tue, 06 Jul 2004 22:31:28 +1000 Date: Tue, 6 Jul 2004 22:31:27 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPCOMP] Exclude IPCOMP header from props.header_len Message-ID: <20040706123127.GA18271@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2966 Lines: 99 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is another patch on the way towards a unified XFRM tunnel encapsulation function. This patch changes the value of props.header_len for IPCOMP to exclude the IPCOMP header. The reason is that the IPCOMP header is added only if the packet is compressible. That is, if the size of the compressed payload plus the size of the IPCOMP header is less than that of the original payload. This means that the IPCOMP encapsulation does not impose any overhead at all as far as the MTU is concerned. The current code incorrectly reduces the MTU by the size of the IPCOMP header. As a side-effect, this means that we don't have to move the IP header around when IPCOMP is used. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/ipcomp.c 1.24 vs edited ===== --- 1.24/net/ipv4/ipcomp.c 2004-06-25 18:38:22 +10:00 +++ edited/net/ipv4/ipcomp.c 2004-07-06 22:15:58 +10:00 @@ -114,8 +114,8 @@ goto out; } - memcpy(start, scratch, dlen); - pskb_trim(skb, ihlen + dlen); + memcpy(start + sizeof(struct ip_comp_hdr), scratch, dlen); + pskb_trim(skb, ihlen + dlen + sizeof(struct ip_comp_hdr)); out: return err; @@ -148,13 +148,9 @@ int err; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct iphdr *iph, *top_iph; + struct iphdr *iph; struct ip_comp_hdr *ipch; struct ipcomp_data *ipcd = x->data; - union { - struct iphdr iph; - char buf[60]; - } tmp_iph; int hdr_len = 0; if ((*pskb)->ip_summed == CHECKSUM_HW) { @@ -211,19 +207,15 @@ /* Install ipcomp header, convert into ipcomp datagram. */ iph = (*pskb)->nh.iph; - memcpy(&tmp_iph, iph, iph->ihl * 4); - top_iph = (struct iphdr *)skb_push(*pskb, sizeof(struct ip_comp_hdr)); - memcpy(top_iph, &tmp_iph, iph->ihl * 4); - iph = top_iph; if (x->props.mode && (x->props.flags & XFRM_STATE_NOECN)) IP_ECN_clear(iph); iph->tot_len = htons((*pskb)->len); - iph->protocol = IPPROTO_COMP; iph->check = 0; ipch = (struct ip_comp_hdr *)((char *)iph + iph->ihl * 4); - ipch->nexthdr = x->props.mode ? IPPROTO_IPIP : tmp_iph.iph.protocol; + ipch->nexthdr = x->props.mode ? IPPROTO_IPIP : iph->protocol; ipch->flags = 0; ipch->cpi = htons((u16 )ntohl(x->id.spi)); + iph->protocol = IPPROTO_COMP; ip_send_check(iph); (*pskb)->nh.raw = (*pskb)->data; @@ -365,7 +357,7 @@ goto error; memset(ipcd, 0, sizeof(*ipcd)); - x->props.header_len = sizeof(struct ip_comp_hdr); + x->props.header_len = 0; if (x->props.mode) x->props.header_len += sizeof(struct iphdr); --J/dobhs11T7y2rNN-- From laforge@gnumonks.org Tue Jul 6 05:30:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 05:30:12 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66CU1gi020031 for ; Tue, 6 Jul 2004 05:30:02 -0700 Received: from dsl-082-082-088-213.arcor-ip.net ([82.82.88.213] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1Bhp59-0006kq-PT for netdev@oss.sgi.com; Tue, 06 Jul 2004 14:29:56 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1Bhp4w-0002qg-35 for netdev@oss.sgi.com; Tue, 06 Jul 2004 14:29:42 +0200 Date: Tue, 6 Jul 2004 14:29:42 +0200 From: Harald Welte To: netdev@oss.sgi.com Subject: corruption of ICMP payload while forwarding Message-ID: <20040706122942.GC32707@sunbeam2> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tzZdJ4yHDV5r1Akt" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-archive-position: 6655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 55274 Lines: 1234 --tzZdJ4yHDV5r1Akt Content-Type: multipart/mixed; boundary="FhKpTYimqQF2+bfE" Content-Disposition: inline --FhKpTYimqQF2+bfE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I'm observing a quite strange phenomenon on one of the larger linux firewall deployments (Xeon 3.06GHz, ServerWorks Chipset, 16 Intel E100 chips (82559ER)): =20 The corruption of the data payload of ICMP packets being forwarded! This corruption happens to about 1% of all traffic, and only happens when there's some PF_PACKET socket open (like tcpdump, nacctd, ...). If you run tcpdump on the outbound interface of the firewall, the packet payload is still intact. This (production) system is running a custom 2.4.21 based kernel with lots of current netfilter patch-o-matic patches. However, the observed corruption is present in all packets, even those who are not NAT'ed, mangled or altered in any way. However, the reproducible connection to PF_PACKET sockets leads my focus a bit away from netfilter towards the core network stack. Attached is a lsmod and lspci of that machine, as well as packet captures taken via mirror port on the cisco switches on the inbound and outbound interface for that packet. Any clues, hints, ideas? Has anyone ever observed something similar? --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --FhKpTYimqQF2+bfE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=lspci Content-Transfer-Encoding: quoted-printable PCI devices found: Bus 0, device 0, function 0: Host bridge: ServerWorks CNB20-HE Host Bridge (rev 51). Bus 0, device 0, function 1: Host bridge: ServerWorks CNB20-HE Host Bridge (#2) (rev 0). Bus 0, device 0, function 2: Host bridge: ServerWorks CNB20-HE Host Bridge (#3) (rev 0). Bus 0, device 3, function 0: VGA compatible controller: ATI Technologies Inc Rage XL (rev 39). Master Capable. Latency=3D64. Min Gnt=3D8. Non-prefetchable 32 bit memory at 0xf6000000 [0xf6ffffff]. I/O at 0x2400 [0x24ff]. Non-prefetchable 32 bit memory at 0xf5ff0000 [0xf5ff0fff]. Bus 0, device 4, function 0: System peripheral: PCI device 0e11:b203 (Compaq Computer Corporation) (= rev 1). IRQ 5. I/O at 0x1800 [0x18ff]. Non-prefetchable 32 bit memory at 0xf5fe0000 [0xf5fe01ff]. Bus 0, device 4, function 2: System peripheral: PCI device 0e11:b204 (Compaq Computer Corporation) (= rev 1). IRQ 10. Master Capable. Latency=3D64. =20 I/O at 0x2800 [0x28ff]. Non-prefetchable 32 bit memory at 0xf5fd0000 [0xf5fd07ff]. Non-prefetchable 32 bit memory at 0xf5fc0000 [0xf5fc1fff]. Non-prefetchable 32 bit memory at 0xf5f00000 [0xf5f7ffff]. Bus 0, device 15, function 0: ISA bridge: ServerWorks CSB5 South Bridge (rev 147). Master Capable. Latency=3D32. =20 Bus 0, device 15, function 1: IDE interface: ServerWorks CSB5 IDE Controller (rev 147). Master Capable. Latency=3D64. =20 I/O at 0x2000 [0x200f]. Bus 0, device 15, function 2: USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 5). IRQ 11. Master Capable. Latency=3D64. Max Lat=3D80. Non-prefetchable 32 bit memory at 0xf5ef0000 [0xf5ef0fff]. Bus 0, device 15, function 3: Host bridge: ServerWorks GCLE Host Bridge (rev 0). Bus 0, device 16, function 0: Host bridge: PCI device 1166:0101 (ServerWorks) (rev 5). Master Capable. Latency=3D64. =20 Bus 0, device 16, function 2: Host bridge: PCI device 1166:0101 (ServerWorks) (rev 5). Master Capable. Latency=3D64. =20 Bus 0, device 17, function 0: Host bridge: PCI device 1166:0101 (ServerWorks) (rev 5). Master Capable. Latency=3D64. =20 Bus 0, device 17, function 2: Host bridge: PCI device 1166:0101 (ServerWorks) (rev 5). Master Capable. Latency=3D64. =20 Bus 1, device 3, function 0: SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 1). IRQ 15. Master Capable. Latency=3D64. Min Gnt=3D40.Max Lat=3D25. I/O at 0x3000 [0x30ff]. Non-prefetchable 64 bit memory at 0xf78f0000 [0xf78f0fff]. Bus 1, device 3, function 1: SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (#2) (rev= 1). IRQ 15. Master Capable. Latency=3D64. Min Gnt=3D40.Max Lat=3D25. I/O at 0x3400 [0x34ff]. Non-prefetchable 64 bit memory at 0xf78e0000 [0xf78e0fff]. Bus 1, device 4, function 0: Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Et= hernet (rev 2). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D64. Non-prefetchable 64 bit memory at 0xf78d0000 [0xf78dffff]. Bus 2, device 1, function 0: PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (rev 0). Master Capable. Latency=3D64. Min Gnt=3D7. Bus 2, device 2, function 0: PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (#2) (rev 0). Master Capable. Latency=3D64. Min Gnt=3D7. Bus 6, device 1, function 0: PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (#3) (rev 0). Master Capable. Latency=3D64. Min Gnt=3D7. Bus 10, device 1, function 0: PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (#4) (rev 0). Master Capable. Latency=3D64. Min Gnt=3D7. Bus 10, device 2, function 0: PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (#5) (rev 0). Master Capable. Latency=3D64. Min Gnt=3D7. Bus 3, device 0, function 0: Ethernet controller: Intel Corp. 82559ER (rev 9). IRQ 10. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf79f0000 [0xf79f0fff]. I/O at 0x4000 [0x403f]. Non-prefetchable 32 bit memory at 0xf79c0000 [0xf79dffff]. Bus 3, device 1, function 0: Ethernet controller: Intel Corp. 82559ER (#2) (rev 9). IRQ 5. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf79b0000 [0xf79b0fff]. I/O at 0x4040 [0x407f]. Non-prefetchable 32 bit memory at 0xf7980000 [0xf799ffff]. Bus 3, device 2, function 0: Ethernet controller: Intel Corp. 82559ER (#3) (rev 9). IRQ 10. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7970000 [0xf7970fff]. I/O at 0x4080 [0x40bf]. Non-prefetchable 32 bit memory at 0xf7940000 [0xf795ffff]. Bus 4, device 0, function 0: Ethernet controller: Intel Corp. 82559ER (#4) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7af0000 [0xf7af0fff]. I/O at 0x5000 [0x503f]. Non-prefetchable 32 bit memory at 0xf7ac0000 [0xf7adffff]. Bus 4, device 1, function 0: Ethernet controller: Intel Corp. 82559ER (#5) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7ab0000 [0xf7ab0fff]. I/O at 0x5040 [0x507f]. Non-prefetchable 32 bit memory at 0xf7a80000 [0xf7a9ffff]. Bus 4, device 2, function 0: Ethernet controller: Intel Corp. 82559ER (#6) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7a70000 [0xf7a70fff]. I/O at 0x5080 [0x50bf]. Non-prefetchable 32 bit memory at 0xf7a40000 [0xf7a5ffff]. Bus 7, device 0, function 0: Ethernet controller: Intel Corp. 82559ER (#7) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7df0000 [0xf7df0fff]. I/O at 0x7000 [0x703f]. Non-prefetchable 32 bit memory at 0xf7dc0000 [0xf7ddffff]. Bus 7, device 1, function 0: Ethernet controller: Intel Corp. 82559ER (#8) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7db0000 [0xf7db0fff]. I/O at 0x7040 [0x707f]. Non-prefetchable 32 bit memory at 0xf7d80000 [0xf7d9ffff]. Bus 7, device 2, function 0: Ethernet controller: Intel Corp. 82559ER (#9) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7d70000 [0xf7d70fff]. I/O at 0x7080 [0x70bf]. Non-prefetchable 32 bit memory at 0xf7d40000 [0xf7d5ffff]. Bus 11, device 0, function 0: Ethernet controller: Intel Corp. 82559ER (#10) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7ef0000 [0xf7ef0fff]. I/O at 0x8000 [0x803f]. Non-prefetchable 32 bit memory at 0xf7ec0000 [0xf7edffff]. Bus 11, device 1, function 0: Ethernet controller: Intel Corp. 82559ER (#11) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7eb0000 [0xf7eb0fff]. I/O at 0x8040 [0x807f]. Non-prefetchable 32 bit memory at 0xf7e80000 [0xf7e9ffff]. Bus 11, device 2, function 0: Ethernet controller: Intel Corp. 82559ER (#12) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7e70000 [0xf7e70fff]. I/O at 0x8080 [0x80bf]. Non-prefetchable 32 bit memory at 0xf7e40000 [0xf7e5ffff]. Bus 12, device 0, function 0: Ethernet controller: Intel Corp. 82559ER (#13) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7ff0000 [0xf7ff0fff]. I/O at 0x9000 [0x903f]. Non-prefetchable 32 bit memory at 0xf7fc0000 [0xf7fdffff]. Bus 12, device 1, function 0: Ethernet controller: Intel Corp. 82559ER (#14) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7fb0000 [0xf7fb0fff]. I/O at 0x9040 [0x907f]. Non-prefetchable 32 bit memory at 0xf7f80000 [0xf7f9ffff]. Bus 12, device 2, function 0: Ethernet controller: Intel Corp. 82559ER (#15) (rev 9). IRQ 11. Master Capable. Latency=3D64. Min Gnt=3D8.Max Lat=3D56. Non-prefetchable 32 bit memory at 0xf7f70000 [0xf7f70fff]. I/O at 0x9080 [0x90bf]. Non-prefetchable 32 bit memory at 0xf7f40000 [0xf7f5ffff]. Bus 3, device 3, function 0: Parallel controller: Oxford Semiconductor Ltd VScom 011H-EP1 1 port par= allel adaptor (rev 0). IRQ 5. I/O at 0x40c0 [0x40c7]. I/O at 0x40c8 [0x40cb]. I/O at 0x40e0 [0x40ff]. Non-prefetchable 32 bit memory at 0xf7930000 [0xf7930fff]. Bus 4, device 3, function 0: Parallel controller: Oxford Semiconductor Ltd VScom 011H-EP1 1 port par= allel adaptor (#2) (rev 0). IRQ 11. I/O at 0x50c0 [0x50c7]. I/O at 0x50c8 [0x50cb]. I/O at 0x50e0 [0x50ff]. Non-prefetchable 32 bit memory at 0xf7a30000 [0xf7a30fff]. Bus 7, device 3, function 0: Parallel controller: Oxford Semiconductor Ltd VScom 011H-EP1 1 port par= allel adaptor (#3) (rev 0). IRQ 11. I/O at 0x70c0 [0x70c7]. I/O at 0x70c8 [0x70cb]. I/O at 0x70e0 [0x70ff]. Non-prefetchable 32 bit memory at 0xf7d30000 [0xf7d30fff]. Bus 11, device 3, function 0: Parallel controller: Oxford Semiconductor Ltd VScom 011H-EP1 1 port par= allel adaptor (#4) (rev 0). IRQ 11. I/O at 0x80c0 [0x80c7]. I/O at 0x80c8 [0x80cb]. I/O at 0x80e0 [0x80ff]. Non-prefetchable 32 bit memory at 0xf7e30000 [0xf7e30fff]. Bus 12, device 3, function 0: Parallel controller: Oxford Semiconductor Ltd VScom 011H-EP1 1 port par= allel adaptor (#5) (rev 0). IRQ 11. I/O at 0x90c0 [0x90c7]. I/O at 0x90c8 [0x90cb]. I/O at 0x90e0 [0x90ff]. Non-prefetchable 32 bit memory at 0xf7f30000 [0xf7f30fff]. Bus 6, device 2, function 0: RAID bus controller: Compaq Computer Corporation Smart Array 5i/532 (re= v 1). IRQ 15. Master Capable. Latency=3D71. =20 Non-prefetchable 64 bit memory at 0xf7cc0000 [0xf7cfffff]. I/O at 0x6000 [0x60ff]. Prefetchable 64 bit memory at 0xf7bf0000 [0xf7bf3fff]. --FhKpTYimqQF2+bfE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=lsmod Content-Transfer-Encoding: quoted-printable Module Size Used by Not tainted ipt_CLASSIFY 792 2 (autoclean) ipt_tos 472 1 (autoclean) ipt_length 472 2 (autoclean) ipt_MASQUERADE 1336 9 (autoclean) ipt_dstlimit 7304 2 (autoclean) ip_nat_mms 3056 0 (unused) ip_nat_proto_gre 1316 0 (unused) ip_nat_pptp 2348 0 (unused) ip_nat_h323 2540 0 (unused) ip_nat_irc 2288 0 (unused) ip_nat_ftp 2864 0 (unused) iptable_nat 16888 7 [ipt_MASQUERADE ip_nat_mms ip_nat_proto_g= re ip_nat_pptp ip_nat_h323 ip_nat_irc ip_nat_ftp] iptable_mangle 2072 1=20 ip_conntrack_mms 3344 1=20 ip_conntrack_pptp 2936 1=20 ip_conntrack_proto_gre 2720 0 [ip_nat_pptp ip_conntrack_pptp] ip_conntrack_h323 2680 1=20 ip_conntrack_irc 3792 1=20 ip_conntrack_ftp 4592 1=20 nfnetlink_conntrack 8376 0 (unused) nfnetlink 2540 1 [nfnetlink_conntrack] ipt_owner 1272 23=20 ipt_REJECT 3224 1=20 ipt_LOG 3904 9=20 ipt_unclean 6808 0 (unused) pcmcia_core 42336 0=20 ipt_state 600 3 (autoclean) ipt_NOTRACK 696 2 (autoclean) iptable_raw 1200 1 (autoclean) af_packet 12360 0=20 ip_conntrack 25132 8 [ipt_MASQUERADE ip_nat_mms ip_nat_pptp ip= _nat_h323 ip_nat_irc ip_nat_ftp iptable_nat ip_conntrack_mms ip_conntrack_p= ptp ip_conntrack_proto_gre ip_conntrack_h323 ip_conntrack_irc ip_conntrack_= ftp nfnetlink_conntrack ipt_state ipt_NOTRACK] iptable_filter 1644 1 (autoclean) ip_tables 11936 17 [ipt_CLASSIFY ipt_tos ipt_length ipt_MASQ= UERADE ipt_dstlimit iptable_nat iptable_mangle ipt_owner ipt_REJECT ipt_LOG= ipt_unclean ipt_state ipt_NOTRACK iptable_raw iptable_filter] e100 45156 7=20 bcm5700 76168 1=20 cciss 27428 8=20 aic7xxx 160112 0=20 sd_mod 12256 0 (unused) scsi_mod 95084 2 [aic7xxx sd_mod] --FhKpTYimqQF2+bfE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="Output_01_fw_in.txt" Content-Transfer-Encoding: quoted-printable =0D - - - - - - - - - - - - - - - - - - - - Frame 647 - - - - - - - - - - - - -= - - - - - - -=0D Frame Status Source Destination B= ytes Rel Time =0D Delta Time Abs time Summary=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------=0D 647 [172.18.64.1] [172.18.1.59] = 414 0:00:00.975 =0D 0.000.828 05.04.2004 12:05:04 ICMP: Echo=0D DLC: ----- DLC Header -----=0D DLC: =0D DLC: Frame 647 arrived at 11:05:04.9495; frame size is 414 (019E he= x) bytes.=0D DLC: Destination =3D Station 000E7F2E9C96=0D DLC: Source =3D Station Cisco 82B084=0D DLC: Ethertype =3D 0800 (IP)=0D DLC: =0D IP: ----- IP Header -----=0D IP: =0D IP: Version =3D 4, header length =3D 20 bytes=0D IP: Type of service =3D 00=0D IP: 000. .... =3D routine=0D IP: ...0 .... =3D normal delay=0D IP: .... 0... =3D normal throughput=0D IP: .... .0.. =3D normal reliability=0D IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit=0D IP: .... ...0 =3D CE bit - no congestion=0D IP: Total length =3D 400 bytes=0D IP: Identification =3D 31828=0D IP: Flags =3D 0X=0D IP: .0.. .... =3D may fragment=0D IP: ..0. .... =3D last fragment=0D IP: Fragment offset =3D 0 bytes=0D IP: Time to live =3D 255 seconds/hops=0D IP: Protocol =3D 1 (ICMP)=0D IP: Header checksum =3D A4B7 (correct)=0D IP: Source address =3D [172.18.64.1]=0D IP: Destination address =3D [172.18.1.59]=0D IP: No options=0D IP: =0D ICMP: ----- ICMP header -----=0D ICMP: =0D ICMP: Type =3D 8 (Echo)=0D ICMP: Code =3D 0=0D ICMP: Checksum =3D E262 (correct)=0D ICMP: Identifier =3D 3494=0D ICMP: Sequence number =3D 1511=0D ICMP: [372 bytes of data]=0D ICMP: =0D ICMP: [Normal end of "ICMP header".]=0D ICMP: =0D ADDR HEX ASCII=0D 0000: 00 0e 7f 2e 9c 96 00 b0 8e 82 b0 84 08 00 45 00 | ..=7F.=9C=96.=B0=8E= =82=B0=84..E.=0D 0010: 01 90 7c 54 00 00 ff 01 a4 b7 ac 12 40 01 ac 12 | .=90|T..=FF.=A4=B7= =AC.@.=AC.=0D 0020: 01 3b 08 00 e2 62 0d a6 05 e7 00 00 00 00 24 cf | .;..=E2b.=A6.=E7...= =2E$=CF=0D 0030: b9 08 ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =B9.=AB=CD=AB=CD=AB= =CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0070: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0080: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0090: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00a0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00b0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00c0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00d0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00e0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=0D =0D - - - - - - - - - - - - - - - - - - - - Frame 648 - - - - - - - - - - - - -= - - - - - - -=0D Frame Status Source Destination B= ytes Rel Time =0D Delta Time Abs time Summary=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------=0D 648 [172.18.1.59] [172.18.64.1] = 414 0:00:00.978 =0D 0.002.597 05.04.2004 12:05:04 ICMP: Echo reply=0D DLC: ----- DLC Header -----=0D DLC: =0D DLC: Frame 648 arrived at 11:05:04.9521; frame size is 414 (019E he= x) bytes.=0D DLC: Destination =3D Station Cisco 82B084=0D DLC: Source =3D Station 000E7F2E9C96=0D DLC: Ethertype =3D 0800 (IP)=0D DLC: =0D IP: ----- IP Header -----=0D IP: =0D IP: Version =3D 4, header length =3D 20 bytes=0D IP: Type of service =3D 00=0D IP: 000. .... =3D routine=0D IP: ...0 .... =3D normal delay=0D IP: .... 0... =3D normal throughput=0D IP: .... .0.. =3D normal reliability=0D IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit=0D IP: .... ...0 =3D CE bit - no congestion=0D IP: Total length =3D 400 bytes=0D IP: Identification =3D 31828=0D IP: Flags =3D 0X=0D IP: .0.. .... =3D may fragment=0D IP: ..0. .... =3D last fragment=0D IP: Fragment offset =3D 0 bytes=0D IP: Time to live =3D 254 seconds/hops=0D IP: Protocol =3D 1 (ICMP)=0D IP: Header checksum =3D A5B7 (correct)=0D IP: Source address =3D [172.18.1.59]=0D IP: Destination address =3D [172.18.64.1]=0D IP: No options=0D IP: =0D ICMP: ----- ICMP header -----=0D ICMP: =0D ICMP: Type =3D 0 (Echo reply)=0D ICMP: Code =3D 0=0D ICMP: Checksum =3D EA62 (correct)=0D ICMP: Identifier =3D 3494=0D ICMP: Sequence number =3D 1511=0D ICMP: [372 bytes of data]=0D ICMP: =0D ICMP: [Normal end of "ICMP header".]=0D ICMP: =0D ADDR HEX ASCII=0D 0000: 00 b0 8e 82 b0 84 00 0e 7f 2e 9c 96 08 00 45 00 | .=B0=8E=82=B0=84..= =7F.=9C=96..E.=0D 0010: 01 90 7c 54 00 00 fe 01 a5 b7 ac 12 01 3b ac 12 | .=90|T..=FE.=A5=B7= =AC..;=AC.=0D 0020: 40 01 00 00 ea 62 0d a6 05 e7 00 00 00 00 24 cf | @...=EAb.=A6.=E7...= =2E$=CF=0D 0030: b9 08 ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =B9.=AB=CD=AB=CD=AB= =CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0070: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0080: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0090: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00a0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00b0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00c0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00d0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00e0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=0D =0D - - - - - - - - - - - - - - - - - - - - Frame 649 - - - - - - - - - - - - -= - - - - - - -=0D Frame Status Source Destination B= ytes Rel Time =0D Delta Time Abs time Summary=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------=0D 649 [172.18.64.1] [172.18.1.59] = 414 0:00:00.979 =0D 0.000.894 05.04.2004 12:05:04 ICMP: Echo=0D DLC: ----- DLC Header -----=0D DLC: =0D DLC: Frame 649 arrived at 11:05:04.9530; frame size is 414 (019E he= x) bytes.=0D DLC: Destination =3D Station 000E7F2E9C96=0D DLC: Source =3D Station Cisco 82B084=0D DLC: Ethertype =3D 0800 (IP)=0D DLC: =0D IP: ----- IP Header -----=0D IP: =0D IP: Version =3D 4, header length =3D 20 bytes=0D IP: Type of service =3D 00=0D IP: 000. .... =3D routine=0D IP: ...0 .... =3D normal delay=0D IP: .... 0... =3D normal throughput=0D IP: .... .0.. =3D normal reliability=0D IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit=0D IP: .... ...0 =3D CE bit - no congestion=0D IP: Total length =3D 400 bytes=0D IP: Identification =3D 31829=0D IP: Flags =3D 0X=0D IP: .0.. .... =3D may fragment=0D IP: ..0. .... =3D last fragment=0D IP: Fragment offset =3D 0 bytes=0D IP: Time to live =3D 255 seconds/hops=0D IP: Protocol =3D 1 (ICMP)=0D IP: Header checksum =3D A4B6 (correct)=0D IP: Source address =3D [172.18.64.1]=0D IP: Destination address =3D [172.18.1.59]=0D IP: No options=0D IP: =0D ICMP: ----- ICMP header -----=0D ICMP: =0D ICMP: Type =3D 8 (Echo)=0D ICMP: Code =3D 0=0D ICMP: Checksum =3D E25D (correct)=0D ICMP: Identifier =3D 3495=0D ICMP: Sequence number =3D 1511=0D ICMP: [372 bytes of data]=0D ICMP: =0D ICMP: [Normal end of "ICMP header".]=0D ICMP: =0D ADDR HEX ASCII=0D 0000: 00 0e 7f 2e 9c 96 00 b0 8e 82 b0 84 08 00 45 00 | ..=7F.=9C=96.=B0=8E= =82=B0=84..E.=0D 0010: 01 90 7c 55 00 00 ff 01 a4 b6 ac 12 40 01 ac 12 | .=90|U..=FF.=A4=B6= =AC.@.=AC.=0D 0020: 01 3b 08 00 e2 5d 0d a7 05 e7 00 00 00 00 24 cf | .;..=E2].=A7.=E7...= =2E$=CF=0D 0030: b9 0c ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =B9.=AB=CD=AB=CD=AB= =CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0070: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0080: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0090: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00a0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00b0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00c0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00d0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00e0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=0D =0D - - - - - - - - - - - - - - - - - - - - Frame 650 - - - - - - - - - - - - -= - - - - - - -=0D Frame Status Source Destination B= ytes Rel Time =0D Delta Time Abs time Summary=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------=0D 650 [172.18.64.1] [172.18.1.59] = 414 0:00:02.977 =0D 1.998.516 05.04.2004 12:05:06 ICMP: Echo=0D DLC: ----- DLC Header -----=0D DLC: =0D DLC: Frame 650 arrived at 11:05:06.9515; frame size is 414 (019E he= x) bytes.=0D DLC: Destination =3D Station 000E7F2E9C96=0D DLC: Source =3D Station Cisco 82B084=0D DLC: Ethertype =3D 0800 (IP)=0D DLC: =0D IP: ----- IP Header -----=0D IP: =0D IP: Version =3D 4, header length =3D 20 bytes=0D IP: Type of service =3D 00=0D IP: 000. .... =3D routine=0D IP: ...0 .... =3D normal delay=0D IP: .... 0... =3D normal throughput=0D IP: .... .0.. =3D normal reliability=0D IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit=0D IP: .... ...0 =3D CE bit - no congestion=0D IP: Total length =3D 400 bytes=0D IP: Identification =3D 31830=0D IP: Flags =3D 0X=0D IP: .0.. .... =3D may fragment=0D IP: ..0. .... =3D last fragment=0D IP: Fragment offset =3D 0 bytes=0D IP: Time to live =3D 255 seconds/hops=0D IP: Protocol =3D 1 (ICMP)=0D IP: Header checksum =3D A4B5 (correct)=0D IP: Source address =3D [172.18.64.1]=0D IP: Destination address =3D [172.18.1.59]=0D IP: No options=0D IP: =0D ICMP: ----- ICMP header -----=0D ICMP: =0D ICMP: Type =3D 8 (Echo)=0D ICMP: Code =3D 0=0D ICMP: Checksum =3D DA8C (correct)=0D ICMP: Identifier =3D 3496=0D ICMP: Sequence number =3D 1511=0D ICMP: [372 bytes of data]=0D ICMP: =0D ICMP: [Normal end of "ICMP header".]=0D ICMP: =0D ADDR HEX ASCII=0D 0000: 00 0e 7f 2e 9c 96 00 b0 8e 82 b0 84 08 00 45 00 | ..=7F.=9C=96.=B0=8E= =82=B0=84..E.=0D 0010: 01 90 7c 56 00 00 ff 01 a4 b5 ac 12 40 01 ac 12 | .=90|V..=FF.=A4=B5= =AC.@.=AC.=0D 0020: 01 3b 08 00 da 8c 0d a8 05 e7 00 00 00 00 24 cf | .;..=DA=8C.=A8.=E7.= =2E..$=CF=0D 0030: c0 dc ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =C0=DC=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0070: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0080: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0090: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00a0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00b0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00c0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00d0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00e0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD=0D 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=0D --FhKpTYimqQF2+bfE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="Output_01_fw_out.txt" Content-Transfer-Encoding: quoted-printable - - - - - - - - - - - - - - - - - - - - Frame 647 - - - - - - - - - - - - -= - - - - - - - Frame Status Source Destination B= ytes Rel Time =20 Delta Time Abs time Summary ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------- 647 [172.18.64.1] [172.18.1.59] = 414 0:00:00.975 =20 0.001.070 05.04.2004 12:05:03 ICMP: Echo DLC: ----- DLC Header ----- DLC: =20 DLC: Frame 647 arrived at 11:05:03.1245; frame size is 414 (019E he= x) bytes. DLC: Destination =3D Station Cisco 36CA88 DLC: Source =3D Station IEEE 20E55D DLC: Ethertype =3D 0800 (IP) DLC: =20 IP: ----- IP Header ----- IP:=20 IP: Version =3D 4, header length =3D 20 bytes IP: Type of service =3D 00 IP: 000. .... =3D routine IP: ...0 .... =3D normal delay IP: .... 0... =3D normal throughput IP: .... .0.. =3D normal reliability IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit IP: .... ...0 =3D CE bit - no congestion IP: Total length =3D 400 bytes IP: Identification =3D 31828 IP: Flags =3D 0X IP: .0.. .... =3D may fragment IP: ..0. .... =3D last fragment IP: Fragment offset =3D 0 bytes IP: Time to live =3D 254 seconds/hops IP: Protocol =3D 1 (ICMP) IP: Header checksum =3D A5B7 (correct) IP: Source address =3D [172.18.64.1] IP: Destination address =3D [172.18.1.59] IP: No options IP:=20 ICMP: ----- ICMP header ----- ICMP:=20 ICMP: Type =3D 8 (Echo) ICMP: Code =3D 0 ICMP: Checksum =3D E262 (correct) ICMP: Identifier =3D 3494 ICMP: Sequence number =3D 1511 ICMP: [372 bytes of data] ICMP:=20 ICMP: [Normal end of "ICMP header".] ICMP:=20 ADDR HEX ASCII 0000: 00 00 0c 36 ca 88 00 50 c2 20 e5 5d 08 00 45 00 | ...6=CA=88.P=C2 =E5= ]..E. 0010: 01 90 7c 54 00 00 fe 01 a5 b7 ac 12 40 01 ac 12 | .=90|T..=FE.=A5=B7= =AC.@.=AC. 0020: 01 3b 08 00 e2 62 0d a6 05 e7 00 00 00 00 24 cf | .;..=E2b.=A6.=E7...= =2E$=CF 0030: b9 08 ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =B9.=AB=CD=AB=CD=AB= =CD=AB=CD=AB=CD=AB=CD=AB=CD 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0070: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0080: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0090: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00a0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00b0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00c0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00d0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00e0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD - - - - - - - - - - - - - - - - - - - - Frame 648 - - - - - - - - - - - - -= - - - - - - - Frame Status Source Destination B= ytes Rel Time =20 Delta Time Abs time Summary ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------- 648 [172.18.1.59] [172.18.64.1] = 414 0:00:00.976 =20 0.001.178 05.04.2004 12:05:03 ICMP: Echo reply DLC: ----- DLC Header ----- DLC: =20 DLC: Frame 648 arrived at 11:05:03.1257; frame size is 414 (019E he= x) bytes. DLC: Destination =3D Station IEEE 20E55D DLC: Source =3D Station Cisco 36CA88 DLC: Ethertype =3D 0800 (IP) DLC: =20 IP: ----- IP Header ----- IP:=20 IP: Version =3D 4, header length =3D 20 bytes IP: Type of service =3D 00 IP: 000. .... =3D routine IP: ...0 .... =3D normal delay IP: .... 0... =3D normal throughput IP: .... .0.. =3D normal reliability IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit IP: .... ...0 =3D CE bit - no congestion IP: Total length =3D 400 bytes IP: Identification =3D 31828 IP: Flags =3D 0X IP: .0.. .... =3D may fragment IP: ..0. .... =3D last fragment IP: Fragment offset =3D 0 bytes IP: Time to live =3D 255 seconds/hops IP: Protocol =3D 1 (ICMP) IP: Header checksum =3D A4B7 (correct) IP: Source address =3D [172.18.1.59] IP: Destination address =3D [172.18.64.1] IP: No options IP:=20 ICMP: ----- ICMP header ----- ICMP:=20 ICMP: Type =3D 0 (Echo reply) ICMP: Code =3D 0 ICMP: Checksum =3D EA62 (correct) ICMP: Identifier =3D 3494 ICMP: Sequence number =3D 1511 ICMP: [372 bytes of data] ICMP:=20 ICMP: [Normal end of "ICMP header".] ICMP:=20 ADDR HEX ASCII 0000: 00 50 c2 20 e5 5d 00 00 0c 36 ca 88 08 00 45 00 | .P=C2 =E5]...6=CA= =88..E. 0010: 01 90 7c 54 00 00 ff 01 a4 b7 ac 12 01 3b ac 12 | .=90|T..=FF.=A4=B7= =AC..;=AC. 0020: 40 01 00 00 ea 62 0d a6 05 e7 00 00 00 00 24 cf | @...=EAb.=A6.=E7...= =2E$=CF 0030: b9 08 ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =B9.=AB=CD=AB=CD=AB= =CD=AB=CD=AB=CD=AB=CD=AB=CD 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0070: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0080: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0090: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00a0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00b0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00c0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00d0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00e0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD - - - - - - - - - - - - - - - - - - - - Frame 649 - - - - - - - - - - - - -= - - - - - - - Frame Status Source Destination B= ytes Rel Time =20 Delta Time Abs time Summary ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------- 649 [172.18.64.1] [172.18.1.59] = 414 0:00:00.979 =20 0.002.309 05.04.2004 12:05:03 ICMP: Echo DLC: ----- DLC Header ----- DLC: =20 DLC: Frame 649 arrived at 11:05:03.1280; frame size is 414 (019E he= x) bytes. DLC: Destination =3D Station Cisco 36CA88 DLC: Source =3D Station IEEE 20E55D DLC: Ethertype =3D 0800 (IP) DLC: =20 IP: ----- IP Header ----- IP:=20 IP: Version =3D 4, header length =3D 20 bytes IP: Type of service =3D 00 IP: 000. .... =3D routine IP: ...0 .... =3D normal delay IP: .... 0... =3D normal throughput IP: .... .0.. =3D normal reliability IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit IP: .... ...0 =3D CE bit - no congestion IP: Total length =3D 400 bytes IP: Identification =3D 31829 IP: Flags =3D 0X IP: .0.. .... =3D may fragment IP: ..0. .... =3D last fragment IP: Fragment offset =3D 0 bytes IP: Time to live =3D 254 seconds/hops IP: Protocol =3D 1 (ICMP) IP: Header checksum =3D A5B6 (correct) IP: Source address =3D [172.18.64.1] IP: Destination address =3D [172.18.1.59] IP: No options IP:=20 ICMP: ----- ICMP header ----- ICMP:=20 ICMP: Type =3D 8 (Echo) ICMP: Code =3D 0 ICMP: Checksum =3D E25D (should be FD10) ICMP: Identifier =3D 3495 ICMP: Sequence number =3D 1511 ICMP: [372 bytes of data] ICMP:=20 ICMP: [Normal end of "ICMP header".] ICMP:=20 ADDR HEX ASCII 0000: 00 00 0c 36 ca 88 00 50 c2 20 e5 5d 08 00 45 00 | ...6=CA=88.P=C2 =E5= ]..E. 0010: 01 90 7c 55 00 00 fe 01 a5 b6 ac 12 40 01 ac 12 | .=90|U..=FE.=A5=B6= =AC.@.=AC. 0020: 01 3b 08 00 e2 5d 0d a7 05 e7 00 00 00 00 24 cf | .;..=E2].=A7.=E7...= =2E$=CF 0030: b9 0c ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =B9.=AB=CD=AB=CD=AB= =CD=AB=CD=AB=CD=AB=CD=AB=CD 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd 2b 06 | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD+. 0070: 01 02 01 02 02 01 07 32 05 00 36 12 f2 9b 00 54 | .......2..6.=F2=9B.T 0080: 00 48 00 54 00 02 00 26 00 07 40 59 00 00 5c 00 | .H.T...&..@Y..\. 0090: 50 00 49 00 50 00 45 00 5c 00 00 00 00 00 05 00 | P.I.P.E.\....... 00a0: 0b 00 10 00 00 00 48 00 00 00 04 00 00 00 30 16 | ......H.......0. 00b0: 30 16 00 00 00 00 01 00 00 00 00 00 01 00 78 57 | 0.............xW 00c0: 34 12 34 12 cd ab ef 00 01 23 45 67 89 ab 00 00 | 4.4.=CD=AB=EF..#Eg= =89=AB.. 00d0: 00 00 04 5d 88 8a eb 1c c9 11 9f e8 08 00 2b 10 | ...]=88=8A=EB.=C9.= =9F=E8..+. 00e0: 48 60 02 00 00 00 74 61 62 6c 65 20 77 69 ab cd | H`....table wi=AB=CD 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD - - - - - - - - - - - - - - - - - - - - Frame 650 - - - - - - - - - - - - -= - - - - - - - Frame Status Source Destination B= ytes Rel Time =20 Delta Time Abs time Summary ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------- 650 [172.18.64.1] [172.18.1.59] = 414 0:00:02.977 =20 1.998.555 05.04.2004 12:05:05 ICMP: Echo DLC: ----- DLC Header ----- DLC: =20 DLC: Frame 650 arrived at 11:05:05.1266; frame size is 414 (019E he= x) bytes. DLC: Destination =3D Station Cisco 36CA88 DLC: Source =3D Station IEEE 20E55D DLC: Ethertype =3D 0800 (IP) DLC: =20 IP: ----- IP Header ----- IP:=20 IP: Version =3D 4, header length =3D 20 bytes IP: Type of service =3D 00 IP: 000. .... =3D routine IP: ...0 .... =3D normal delay IP: .... 0... =3D normal throughput IP: .... .0.. =3D normal reliability IP: .... ..0. =3D ECT bit - transport protocol will ignore the = CE bit IP: .... ...0 =3D CE bit - no congestion IP: Total length =3D 400 bytes IP: Identification =3D 31830 IP: Flags =3D 0X IP: .0.. .... =3D may fragment IP: ..0. .... =3D last fragment IP: Fragment offset =3D 0 bytes IP: Time to live =3D 254 seconds/hops IP: Protocol =3D 1 (ICMP) IP: Header checksum =3D A5B5 (correct) IP: Source address =3D [172.18.64.1] IP: Destination address =3D [172.18.1.59] IP: No options IP:=20 ICMP: ----- ICMP header ----- ICMP:=20 ICMP: Type =3D 8 (Echo) ICMP: Code =3D 0 ICMP: Checksum =3D DA8C (correct) ICMP: Identifier =3D 3496 ICMP: Sequence number =3D 1511 ICMP: [372 bytes of data] ICMP:=20 ICMP: [Normal end of "ICMP header".] ICMP:=20 ADDR HEX ASCII 0000: 00 00 0c 36 ca 88 00 50 c2 20 e5 5d 08 00 45 00 | ...6=CA=88.P=C2 =E5= ]..E. 0010: 01 90 7c 56 00 00 fe 01 a5 b5 ac 12 40 01 ac 12 | .=90|V..=FE.=A5=B5= =AC.@.=AC. 0020: 01 3b 08 00 da 8c 0d a8 05 e7 00 00 00 00 24 cf | .;..=DA=8C.=A8.=E7.= =2E..$=CF 0030: c0 dc ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =C0=DC=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0040: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0050: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0060: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0070: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0080: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0090: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00a0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00b0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00c0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00d0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00e0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 00f0: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0100: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0110: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0120: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0130: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0140: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0150: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0160: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0170: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0180: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD=AB=CD 0190: ab cd ab cd ab cd ab cd ab cd ab cd ab cd | =AB=CD=AB=CD=AB=CD= =AB=CD=AB=CD=AB=CD=AB=CD --FhKpTYimqQF2+bfE-- --tzZdJ4yHDV5r1Akt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6ps2XaXGVTD0i/8RArpiAJ9dpOUuJ/7VXeTDkHecI/hkCM/IYgCgkrMD b/PQVY3LusGSdT3Vrzpplng= =wfbb -----END PGP SIGNATURE----- --tzZdJ4yHDV5r1Akt-- From hadi@cyberus.ca Tue Jul 6 06:05:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 06:05:07 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66D54gi022178 for ; Tue, 6 Jul 2004 06:05:04 -0700 Received: from mx03.cybersurf.com ([IPv6:::ffff:209.197.145.106]:56755 "EHLO mx03.cybersurf.com") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 14:05:03 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1Bhpd4-0005nR-F9 for netdev@linux-mips.org; Tue, 06 Jul 2004 09:04:58 -0400 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 1Bhpcz-0006k0-Kr; Tue, 06 Jul 2004 09:04:53 -0400 Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: shemminger@osdl.org, util@deuroconsult.ro, netdev@oss.sgi.com, lartc@mailman.ds9a.nl In-Reply-To: <20040705194925.37b7efcb.davem@redhat.com> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040705194925.37b7efcb.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089119090.4260.2.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jul 2004 09:04:50 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 246 Lines: 10 On Mon, 2004-07-05 at 22:49, David S. Miller wrote: > I'm going to hold off on Stephen's patches until Jamal and he has > a chance to fight it out :-) Actually i would be fine with it if Stephen gets rid of the new "rate" thing. cheers, jamal From ahu@outpost.ds9a.nl Tue Jul 6 06:21:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 06:21:26 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66DLCgi022822 for ; Tue, 6 Jul 2004 06:21:12 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 0D8723FDC; Tue, 6 Jul 2004 14:42:54 +0200 (CEST) Date: Tue, 6 Jul 2004 14:42:54 +0200 From: bert hubert To: ALESSANDRO.SUARDI@ORACLE.COM Cc: Arnaldo Carvalho de Melo , "David S. Miller" , "linux-kernel @ vger. kernel. org Stephen Hemminger" , netdev@oss.sgi.com, phyprabab@yahoo.com Subject: Re: analysis of TCP window size issues still around - several reports / SACK involved? Message-ID: <20040706124254.GA13395@outpost.ds9a.nl> Mail-Followup-To: bert hubert , ALESSANDRO.SUARDI@ORACLE.COM, Arnaldo Carvalho de Melo , "David S. Miller" , "linux-kernel @ vger. kernel. org Stephen Hemminger" , netdev@oss.sgi.com, phyprabab@yahoo.com References: <6913615.1089117051125.JavaMail.oracle@web265.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6913615.1089117051125.JavaMail.oracle@web265.oracle.com> User-Agent: Mutt/1.3.28i X-archive-position: 6659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1027 Lines: 25 On Tue, Jul 06, 2004 at 06:30:51AM -0600, ALESSANDRO.SUARDI@ORACLE.COM wrote: > Further data points: -bk18 built with GCC 3.4.1 still hangs talking to > most of the world except google.it (redirected from google.com) from my > home DSL (US Robotics USR9003 router). I juist built 2.6.7-mm6 in an attempt to reproduce your problems but I can't see them, can you check with that version too? > It _also_ works from my home _if_ I fire up the Cisco VPN client (4.0.4.B) > to an Oracle VPN server and access the 'net (kernel.org and all) via our > proxies through the VPN. Is this the 5mb binary kernel module blob version? Can you reproduce the bug on a system that has never touched this module? Furthermore, can you email me your IP address and try to connect to http://ds9a.nl/hi-ahu afterwards I confirm receipt? I want to see the server side of the story. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From jberger@trustednetworktech.com Tue Jul 6 06:41:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 06:41:10 -0700 (PDT) Received: from deda37 ([216.119.112.38]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Df8gi023547 for ; Tue, 6 Jul 2004 06:41:09 -0700 Received: from UnknownHost [69.15.35.161] by deda37 with SMTP; Tue, 6 Jul 2004 06:46:54 -0700 Subject: Question about Cisco's ISL From: Joubert Berger To: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1089121054.22081.31.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 06 Jul 2004 09:37:34 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jberger@trustednetworktech.com Precedence: bulk X-list: netdev Content-Length: 276 Lines: 8 I am writing some code to decode Cisco ISL frames. I am having a difficult time figuring out how the FCS is calculated at the end of the frame. Does anyone have any experience with Cisco ISL frames and possibly how to calculate the CRC at the end of the frame. --joubert From jmorris@redhat.com Tue Jul 6 07:35:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 07:36:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66EZYgi026220 for ; Tue, 6 Jul 2004 07:35:54 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66EZ8e1031179; Tue, 6 Jul 2004 10:35:08 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66EZ5026601; Tue, 6 Jul 2004 10:35:05 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i66EYt4G027400; Tue, 6 Jul 2004 10:34:56 -0400 Date: Tue, 6 Jul 2004 10:34:55 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: Paul Wouters , "D. Hugh Redelmeier" , , Dominique Blas , Subject: Re: [Openswan dev] IPComp In-Reply-To: <20040703113732.GA22082@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 1126 Lines: 36 On Sat, 3 Jul 2004, Herbert Xu wrote: > On Sat, Jul 03, 2004 at 01:02:56PM +0200, Paul Wouters wrote: > > > > He seems to have generic memory problems though, so I don't think this is an > > openswan or kernel ipsec bug. > > He's probably having a memory fragmentation problem, but allocating > 64K physically contiguous memory is something that should never be > done over and over again. As the IPCOMP init function is called > regularly, this needs to be fixed. It's only called when an SA is initialized. This should not happen all the time, and if you can't find 64k for such an ooperation you have big problems. > > I haven't looked at the IPCOMP code in detail, but I'd guess that > we're allocating 64K as the largest IP packet size is 64K. Yes, we need to decompress into a local scratch buffer rather than the skb, in case the decompression fails. > Would it be possible to adjust the size of the buffer according > to the packet size and allocate it in ipcomp_input()/ipcomp_output() > instead? We should not perform this allocation for each packet. - James -- James Morris From sebek64@post.cz Tue Jul 6 08:09:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 08:09:52 -0700 (PDT) Received: from penguin.localdomain (pra69-d92.gd.dial-up.cz [193.85.69.92]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66F9hgi027130 for ; Tue, 6 Jul 2004 08:09:44 -0700 Received: by penguin.localdomain (Postfix, from userid 1000) id AA839189B22; Tue, 6 Jul 2004 17:09:18 +0200 (CEST) Date: Tue, 6 Jul 2004 17:09:18 +0200 To: davem@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, laforge@netfilter.org Subject: [PATCH 2.6] ip6t_LOG and packets with hop-by-hop options Message-ID: <20040706150918.GA5009@penguin.localdomain> Mail-Followup-To: davem@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, laforge@netfilter.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: sebek64@post.cz (Marcel Sebek) X-archive-position: 6663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sebek64@post.cz Precedence: bulk X-list: netdev Content-Length: 2450 Lines: 81 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Packet with IPPROTO_HOPOPTS extended header isn't logged properly by ip6t_LOG.c. It only prints PROTO=3D0 and nothing more, because IPPROTO_HOPOPTS=3D0 and in this file 0 is used to indicate last header. This patch fix it by using IPPROTO_NONE to indicate last header. Signed-off-by: Marcel Sebek diff -urpN linux-2.6/net/ipv6/netfilter/ip6t_LOG.c linux-2.6-new/net/ipv6/n= etfilter/ip6t_LOG.c --- linux-2.6/net/ipv6/netfilter/ip6t_LOG.c 2004-04-21 20:01:54.000000000 += 0200 +++ linux-2.6-new/net/ipv6/netfilter/ip6t_LOG.c 2004-07-06 16:48:20.0000000= 00 +0200 @@ -48,10 +48,10 @@ static spinlock_t log_lock =3D SPIN_LOCK_U =20 /* takes in current header and pointer to the header */ /* if another header exists, sets hdrptr to the next header - and returns the new header value, else returns 0 */ + and returns the new header value, else returns IPPROTO_NONE */ static u_int8_t ip6_nexthdr(u_int8_t currenthdr, u_int8_t **hdrptr) { - u_int8_t hdrlen, nexthdr =3D 0; + u_int8_t hdrlen, nexthdr =3D IPPROTO_NONE; =20 switch(currenthdr){ case IPPROTO_AH: @@ -77,7 +77,6 @@ static u_int8_t ip6_nexthdr(u_int8_t cur break; }=09 return nexthdr; - } =20 /* One level of recursion won't kill us */ @@ -101,7 +100,7 @@ static void dump_packet(const struct ip6 =20 fragment =3D 0; hdrptr =3D (u_int8_t *)(ipv6h + 1); - while (currenthdr) { + while (currenthdr !=3D IPPROTO_NONE) { if ((currenthdr =3D=3D IPPROTO_TCP) || (currenthdr =3D=3D IPPROTO_UDP) || (currenthdr =3D=3D IPPROTO_ICMPV6)) @@ -264,7 +263,7 @@ static void dump_packet(const struct ip6 } break; } - /* Max length: 10 "PROTO 255 " */ + /* Max length: 10 "PROTO=3D255 " */ default: printk("PROTO=3D%u ", currenthdr); } --=20 Marcel Sebek jabber: sebek@jabber.cz ICQ: 279852819 linux user number: 307850 GPG ID: 5F88735E GPG FP: 0F01 BAB8 3148 94DB B95D 1FCA 8B63 CA06 5F88 735E --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6sCei2PKBl+Ic14RAnMzAJ0eiT7tjALg/NK/CBncrOx4T7483ACgsbLW CH8XFhFINipmMwaX8CnB/4w= =dWBX -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From laforge@gnumonks.org Tue Jul 6 08:33:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 08:33:35 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66FXUgi031000 for ; Tue, 6 Jul 2004 08:33:31 -0700 Received: from dsl-082-082-095-119.arcor-ip.net ([82.82.95.119] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1Bhrwm-0002RO-07; Tue, 06 Jul 2004 17:33:28 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1BhrwX-0003Ao-DO; Tue, 06 Jul 2004 17:33:13 +0200 Date: Tue, 6 Jul 2004 17:33:13 +0200 From: Harald Welte To: jamal Cc: netdev@oss.sgi.com Subject: Re: corruption of ICMP payload while forwarding Message-ID: <20040706153313.GM32707@sunbeam2> References: <20040706122942.GC32707@sunbeam2> <1089124948.1040.2.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h85LGMdA0M9ASxa6" Content-Disposition: inline In-Reply-To: <1089124948.1040.2.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 6664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1739 Lines: 51 --h85LGMdA0M9ASxa6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 06, 2004 at 10:42:29AM -0400, jamal wrote: > Harald, Hi Jamal, thanks for your reply. > I would probably start by downing most of those devices and still see if > the problem is reproducible with two ethx devices. > If it is reproducible there then replace the nics with something else > like tulip or dlinks and see if it still happens there. > I suspect its a driver issue so if you try the above you can prove it is > not. Yes, that was my recommendation, too... I also recommended disabling more and more features (i.e. remove iptable_nat, iptable_mangle, ...) to see if the problem disappears at some point. However since this is a production machine, I doubt there is too much room for experimenting. We're now trying to reproduce this issue with a seperate box in the lab, though no success so far. > cheers, > jamal --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --h85LGMdA0M9ASxa6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6sY5XaXGVTD0i/8RAvJzAJ45N7WSkVdQZSmUaGVpNU+f7JGKigCfYsQu v2yvKuCJonr3PeQhnzWg3p8= =hwUM -----END PGP SIGNATURE----- --h85LGMdA0M9ASxa6-- From margitsw@t-online.de Tue Jul 6 08:45:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 08:45:29 -0700 (PDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66FjPgi031538 for ; Tue, 6 Jul 2004 08:45:25 -0700 Received: from fwd07.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1Bhs7v-0000hM-05; Tue, 06 Jul 2004 17:44:59 +0200 Received: from roglap.local (VyeoeyZQoeFFcQDWZSyh+7rPQZHE1vFLsdOoGxwNNTMBp47W0K-dQc@[80.128.219.214]) by fwd07.sul.t-online.com with esmtp id 1Bhs7i-0uRyUa0; Tue, 6 Jul 2004 17:44:46 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.7-bk19] prism54 freq to channel incorrect for 5GHz Date: Tue, 6 Jul 2004 17:38:07 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_fds6AERV+ss4GMa" Message-Id: <200407061738.07098.margitsw@t-online.de> X-Seen: false X-ID: VyeoeyZQoeFFcQDWZSyh+7rPQZHE1vFLsdOoGxwNNTMBp47W0K-dQc X-archive-position: 6665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 1486 Lines: 55 --Boundary-00=_fds6AERV+ss4GMa Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-06 Margit Schubert-While * The frequency to channel conversion is wrong for the 5GHz band * Although the (known) devices don't/can't use it, they do report it. (iwlist ethX freq) Margit --Boundary-00=_fds6AERV+ss4GMa Content-Type: text/x-diff; charset="us-ascii"; name="chanfreq.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="chanfreq.patch" diff -Naur linux-2.6.7-02/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.7-03/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.7-02/drivers/net/wireless/prism54/oid_mgt.c 2004-07-01 07:23:52.000000000 +0200 +++ linux-2.6.7-03/drivers/net/wireless/prism54/oid_mgt.c 2004-07-06 17:26:44.000000000 +0200 @@ -28,10 +28,6 @@ 2447, 2452, 2457, 2462, 2467, 2472, 2484 }; -const int frequency_list_a[] = { 5170, 5180, 5190, 5200, 5210, 5220, 5230, - 5240, 5260, 5280, 5300, 5320 -}; - int channel_of_freq(int f) { @@ -41,10 +37,8 @@ while ((c < 14) && (f != frequency_list_bg[c])) c++; return (c >= 14) ? 0 : ++c; - } else if ((f >= (int) 5170) && (f <= (int) 5320)) { - while ((c < 12) && (f != frequency_list_a[c])) - c++; - return (c >= 12) ? 0 : (c + 37); + } else if ((f >= (int) 5000) && (f <= (int) 6000)) { + return ( (f - 5000) / 5 ); } else return 0; } --Boundary-00=_fds6AERV+ss4GMa-- From sam@errno.com Tue Jul 6 08:48:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 08:48:11 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Fm9gi031880 for ; Tue, 6 Jul 2004 08:48:09 -0700 Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i66Fm8Wi023035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 6 Jul 2004 08:48:09 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: margitsw@t-online.de (Margit Schubert-While) Subject: Re: [PATCH Linux-2.6.7-bk19] prism54 freq to channel incorrect for 5GHz Date: Tue, 6 Jul 2004 08:50:49 -0700 User-Agent: KMail/1.6.1 Cc: jgarzik@pobox.com, netdev@oss.sgi.com, prism54-devel@prism54.org References: <200407061738.07098.margitsw@t-online.de> In-Reply-To: <200407061738.07098.margitsw@t-online.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407060850.49552.sam@errno.com> X-archive-position: 6666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 359 Lines: 10 On Tuesday 06 July 2004 08:38 am, Margit Schubert-While wrote: > 2004-07-06 Margit Schubert-While > > * The frequency to channel conversion is wrong for the 5GHz band > * Although the (known) devices don't/can't use it, > they do report it. (iwlist ethX freq) There is known good code to do this in the madwifi net80211 layer. Sam From laforge@netfilter.org Tue Jul 6 09:01:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 09:01:25 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66G1Lgi032399 for ; Tue, 6 Jul 2004 09:01:22 -0700 Received: from dsl-082-082-095-119.arcor-ip.net ([82.82.95.119] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1BhsNj-00038p-Ts; Tue, 06 Jul 2004 18:01:20 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1BhsNZ-0003C4-Er; Tue, 06 Jul 2004 18:01:09 +0200 Date: Tue, 6 Jul 2004 18:01:09 +0200 From: Harald Welte To: davem@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH 2.6] ip6t_LOG and packets with hop-by-hop options Message-ID: <20040706160109.GO32707@sunbeam2> Mail-Followup-To: Harald Welte , davem@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org References: <20040706150918.GA5009@penguin.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yZxAaITavNk3ADw/" Content-Disposition: inline In-Reply-To: <20040706150918.GA5009@penguin.localdomain> User-Agent: Mutt/1.5.6+20040523i X-archive-position: 6667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1437 Lines: 38 --yZxAaITavNk3ADw/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 06, 2004 at 05:09:18PM +0200, Marcel Sebek wrote: > Packet with IPPROTO_HOPOPTS extended header isn't logged properly by > ip6t_LOG.c. It only prints PROTO=3D0 and nothing more, because > IPPROTO_HOPOPTS=3D0 and in this file 0 is used to indicate last header. > This patch fix it by using IPPROTO_NONE to indicate last header. looks fine to me. Dave, can you please include this to your tree? Thanks. --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --yZxAaITavNk3ADw/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6szFXaXGVTD0i/8RAqyBAKCwVgXhaL90YOmbJdWeOmwtGtRC5wCcDh6z cdyKWtNc2S4+4qaOg28Tiig= =aqI8 -----END PGP SIGNATURE----- --yZxAaITavNk3ADw/-- From shemminger@osdl.org Tue Jul 6 09:09:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 09:10:10 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66G9qgi000664 for ; Tue, 6 Jul 2004 09:09:53 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i66G96G21338; Tue, 6 Jul 2004 09:09:06 -0700 Date: Tue, 6 Jul 2004 09:09:06 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040706090906.4ff6fb73@dell_ss3.pdx.osdl.net> In-Reply-To: <1088824432.1043.271.camel@jzny.localdomain> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1841 Lines: 39 On 02 Jul 2004 23:13:52 -0400 jamal wrote: > On Fri, 2004-07-02 at 16:44, Stephen Hemminger wrote: > > Here is an enhancement to netem to do allow emulating lower speed > > networks. The resolution is close, but obviously limited by the > > granularity of timers and size of packets. > > > > Also, fixes a rtnetlink dependency which showed up in some configurations > > and optimizes for the non-loss case by avoiding net_random call. > > > > I think its time i illustrate my comments earlier with some example > hopefully this will curb the amount of features on this qdisc. > I do think theres value in having this thing do delay and jitter, but > you have gone waay beyond that now; > Let illustrate things which apply to what you are trying to do in > network condituions emulation. Although i show ingress qdisc , this > applies to egress just the same. > > #drop 1 out 10 packets randomly using the netrand generator > tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ > match ip src 10.0.0.21/32 flowid 1:16 \ > action drop random netrand ok 0xa Your examples made me think about this more. The netfilter seem best suited to things that effect the flow of packets (dropping, reordering, even corrupting), and the qdisc seems best when the timing needs to change. The limit match in netfilter is not the same as the rate in the qdisc. The netem scheduler acts as if the link is a slow fixed rate. The netfilter limit is usually targeted to drop packets over the rate which is not the same. Reordering is also hard without going out to a user log or building a custom target. So, you have convinced me that loss is unnecessary but not the rate, or delay. If we can figure out how to re-ordering with netfilter then that could go too, which would make it possible to use a layered qdisc again. From manfred@colorfullife.com Tue Jul 6 09:23:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 09:23:55 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66GNfgi001243 for ; Tue, 6 Jul 2004 09:23:47 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i66GMcLw011244; Tue, 6 Jul 2004 18:22:47 +0200 Message-ID: <40EAD1CA.5010105@colorfullife.com> Date: Tue, 06 Jul 2004 18:22:34 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Roger Luethi , Netdev Subject: Re: multicast testing References: <40EACDB6.10008@pobox.com> In-Reply-To: <40EACDB6.10008@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Content-Length: 305 Lines: 13 Jeff Garzik wrote: > Didn't one of you have a multicast test app? Yes, it's at http://www.colorfullife.com/~manfred/TestApps/multicast/ In my experience, - if sending doesn't work then the routing entry is wrong/missing. - if receiving doesn't work then the hash table setup is broken. -- Manfred From jmorris@redhat.com Tue Jul 6 09:43:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 09:43:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66GhZgi002118 for ; Tue, 6 Jul 2004 09:43:35 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66GhPe1004363; Tue, 6 Jul 2004 12:43:25 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66GhN006309; Tue, 6 Jul 2004 12:43:23 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i66GhA4G003505; Tue, 6 Jul 2004 12:43:11 -0400 Date: Tue, 6 Jul 2004 12:43:10 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: dev@lists.openswan.org, , Paul Wouters Subject: Re: [Openswan dev] IPComp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 236 Lines: 14 On Tue, 6 Jul 2004, James Morris wrote: > We should not perform this allocation for each packet. Well, actually, IPComp is so slow that it may not do much more damage to performance. - James -- James Morris From hadi@cyberus.ca Tue Jul 6 10:06:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 10:06:31 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66H6Qgi003679 for ; Tue, 6 Jul 2004 10:06:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BguUF-0004Xz-Gu for netdev@oss.sgi.com; Sat, 03 Jul 2004 20:04:03 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BguUC-0002sg-Hv; Sat, 03 Jul 2004 20:04:01 -0400 Subject: Re: bk16 changes to cbq From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Alexey , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <20040703101646.52ae1e01.davem@redhat.com> References: <1088861810.1039.298.camel@jzny.localdomain> <20040703101646.52ae1e01.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1088899435.1039.650.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Jul 2004 20:03:56 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 717 Lines: 24 On Sat, 2004-07-03 at 13:16, David S. Miller wrote: > On 03 Jul 2004 09:36:50 -0400 > The test is racy with drivers, on the very next line the > driver could take a TX completion interrupt and unplug the > queue invalidating the test entirely. I could be wrong: The only thing the tx complete can do is open up the device for more packets to tx into the device... i.e !netif_queue_stopped(sch->dev) is true in that specific case. Which would mean theres no race. > If the test proves wrong, that's OK because we'll try again > at the top level of packet queue dispatch. > > There was a good explaination of Stephen's patch > on netdev when he posted it. Let me dig into the emails and get back. cheers, jamal From jgarzik@pobox.com Tue Jul 6 10:19:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 10:19:17 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66HJCgi004265 for ; Tue, 6 Jul 2004 10:19:15 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BhsRf-0004Ai-3J; Tue, 06 Jul 2004 17:05:23 +0100 Message-ID: <40EACDB6.10008@pobox.com> Date: Tue, 06 Jul 2004 12:05:10 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Luethi , Manfred Spraul CC: Netdev Subject: multicast testing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 45 Lines: 1 Didn't one of you have a multicast test app? From jgarzik@pobox.com Tue Jul 6 11:19:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 11:19:19 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66IJHgi002034 for ; Tue, 6 Jul 2004 11:19:18 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BgTfN-0002W1-OG; Fri, 02 Jul 2004 20:25:45 +0100 Message-ID: <40E5B6AD.6060904@pobox.com> Date: Fri, 02 Jul 2004 15:25:33 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Update in-kernel orinoco drivers to upstream current CVS References: <1088795498.18039.25.camel@dcbw.boston.redhat.com> In-Reply-To: <1088795498.18039.25.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 587 Lines: 23 Dan Williams wrote: > Hi, > > This patch is simply the fixed-up diff between the kernel's current > 0.13e version and the upstream 0.15rc1+ version from savannah CVS. > 0.15rc1 has been out for a couple months now and seems stable. > > The major benefits that this newer version brings are, of course, many > bugfixes, but best of all wireless scanning support for the Orinoco line > of cards. > > http://people.redhat.com/dcbw/linux-2.6.7-orinoco.patch.bz2 > > Dan Williams > Red Hat, Inc. I'm desperately hoping that someone will split this up into multiple patches... Jeff From shemminger@osdl.org Tue Jul 6 11:48:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 11:48:26 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66ImKgi002837 for ; Tue, 6 Jul 2004 11:48:20 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i66IlfG09616; Tue, 6 Jul 2004 11:47:41 -0700 Date: Tue, 6 Jul 2004 11:47:41 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bert hubert , Arnaldo Carvalho de Melo , netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> In-Reply-To: <20040706093503.GA8147@outpost.ds9a.nl> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3325 Lines: 91 Recent TCP changes exposed the problem that there ar lots of really broken firewalls that strip or alter TCP options. When the options are modified TCP gets busted now. The problem is that when we propose window scaling, we expect that the other side receives the same initial SYN request that we sent. If there is corrupting firewalls that strip it then the window we send is not correctly scaled; so the other side thinks there is not enough space to send. I propose that the following that will avoid sending window scaling that is big enough to break in these cases unless the tcp_rmem has been increased. It will keep default configuration from blowing in a corrupt world. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2004-07-06 11:45:18 -07:00 +++ b/include/linux/sysctl.h 2004-07-06 11:45:18 -07:00 @@ -337,7 +337,7 @@ NET_TCP_BIC=102, NET_TCP_BIC_FAST_CONVERGENCE=103, NET_TCP_BIC_LOW_WINDOW=104, - NET_TCP_DEFAULT_WIN_SCALE=105, +/* NET_TCP_DEFAULT_WIN_SCALE */ NET_TCP_MODERATE_RCVBUF=106, }; diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-07-06 11:45:18 -07:00 +++ b/include/net/tcp.h 2004-07-06 11:45:18 -07:00 @@ -611,7 +611,6 @@ extern int sysctl_tcp_bic; extern int sysctl_tcp_bic_fast_convergence; extern int sysctl_tcp_bic_low_window; -extern int sysctl_tcp_default_win_scale; extern int sysctl_tcp_moderate_rcvbuf; extern atomic_t tcp_memory_allocated; @@ -1690,6 +1689,13 @@ *ptr++ = htonl((TCPOPT_NOP << 24) | (TCPOPT_WINDOW << 16) | (TCPOLEN_WINDOW << 8) | (wscale)); } +/* Default window scaling based on the size of the maximum window */ +static inline __u8 tcp_default_win_scale(void) +{ + int b = ffs(sysctl_tcp_rmem[2]); + return (b < 17) ? 0 : b-16; +} + /* Determine a window scaling and initial window to offer. * Based on the assumption that the given amount of space * will be offered. Store the results in the tp structure. @@ -1732,8 +1738,7 @@ space - max((space>>sysctl_tcp_app_win), mss>>*rcv_wscale) < 65536/2) (*rcv_wscale)--; - *rcv_wscale = max((__u8)sysctl_tcp_default_win_scale, - *rcv_wscale); + *rcv_wscale = max(tcp_default_win_scale(), *rcv_wscale); } /* Set initial window to value enough for senders, diff -Nru a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c --- a/net/ipv4/sysctl_net_ipv4.c 2004-07-06 11:45:18 -07:00 +++ b/net/ipv4/sysctl_net_ipv4.c 2004-07-06 11:45:18 -07:00 @@ -667,14 +667,6 @@ .proc_handler = &proc_dointvec, }, { - .ctl_name = NET_TCP_DEFAULT_WIN_SCALE, - .procname = "tcp_default_win_scale", - .data = &sysctl_tcp_default_win_scale, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { .ctl_name = NET_TCP_MODERATE_RCVBUF, .procname = "tcp_moderate_rcvbuf", .data = &sysctl_tcp_moderate_rcvbuf, diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c 2004-07-06 11:45:18 -07:00 +++ b/net/ipv4/tcp.c 2004-07-06 11:45:18 -07:00 @@ -276,8 +276,6 @@ atomic_t tcp_orphan_count = ATOMIC_INIT(0); -int sysctl_tcp_default_win_scale = 7; - int sysctl_tcp_mem[3]; int sysctl_tcp_wmem[3] = { 4 * 1024, 16 * 1024, 128 * 1024 }; int sysctl_tcp_rmem[3] = { 4 * 1024, 87380, 87380 * 2 }; From jamie@shareable.org Tue Jul 6 12:40:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 12:40:43 -0700 (PDT) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Jeegi007443 for ; Tue, 6 Jul 2004 12:40:41 -0700 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id i66JeZ81011093; Tue, 6 Jul 2004 20:40:35 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id i66JeY4T011091; Tue, 6 Jul 2004 20:40:34 +0100 Date: Tue, 6 Jul 2004 20:40:34 +0100 From: Jamie Lokier To: Stephen Hemminger Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-ID: <20040706194034.GA11021@mail.shareable.org> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-archive-position: 6677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Content-Length: 725 Lines: 16 Stephen Hemminger wrote: > Recent TCP changes exposed the problem that there ar lots of really > broken firewalls that strip or alter TCP options. When the options > are modified TCP gets busted now. The problem is that when we > propose window scaling, we expect that the other side receives the > same initial SYN request that we sent. If there is corrupting > firewalls that strip it then the window we send is not correctly > scaled; so the other side thinks there is not enough space to send. If a firewall strips the window scaling option in both directions, then window scaling is disabled (RFC 1323 section 2.2). Are you saying there are broken firewalls which strip TCP options in one direction only? -- Jamie From niv@us.ibm.com Tue Jul 6 13:00:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:01:01 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66K0Igi008111 for ; Tue, 6 Jul 2004 13:00:38 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i66Jvuko701382; Tue, 6 Jul 2004 15:57:56 -0400 Received: from us.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i66JvsDB411366; Tue, 6 Jul 2004 13:57:55 -0600 Message-ID: <40EB04C7.4000007@us.ibm.com> Date: Tue, 06 Jul 2004 13:00:07 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , bert hubert , Arnaldo Carvalho de Melo , netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> In-Reply-To: <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1358 Lines: 30 Stephen Hemminger wrote: > Recent TCP changes exposed the problem that there ar lots of really broken firewalls > that strip or alter TCP options. We should not be accepting of this situation, surely. I mean, the firewalls have to get fixed. Multiple things are breaking here, due to this. What are the other options they are messing with, and and any idea why? > When the options are modified TCP gets busted now. The problem is that when > we propose window scaling, we expect that the other side receives the same initial > SYN request that we sent. If there is corrupting firewalls that strip it then > the window we send is not correctly scaled; so the other side thinks there is not > enough space to send. If the firewall is actually stripping the TCP window scaling option, then that tells the other end that we can't *receive* scaled windows either, since the option indicates both, we are sending and capable of receiving. i.e. The other end will not send us scaled windows. There is no way we can fix this on the rcv end. > I propose that the following that will avoid sending window scaling that > is big enough to break in these cases unless the tcp_rmem has been increased. > It will keep default configuration from blowing in a corrupt world. Does this need to be the default behaviour? Just how prevalent is this?? thanks, Nivedita From shemminger@osdl.org Tue Jul 6 13:06:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:06:36 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66K5vgi008483 for ; Tue, 6 Jul 2004 13:06:01 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i66K5nG25062; Tue, 6 Jul 2004 13:05:49 -0700 Date: Tue, 6 Jul 2004 13:05:49 -0700 From: Stephen Hemminger To: Jamie Lokier Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706130549.31daa8e0@dell_ss3.pdx.osdl.net> In-Reply-To: <20040706194034.GA11021@mail.shareable.org> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 836 Lines: 19 On Tue, 6 Jul 2004 20:40:34 +0100 Jamie Lokier wrote: > Stephen Hemminger wrote: > > Recent TCP changes exposed the problem that there ar lots of really > > broken firewalls that strip or alter TCP options. When the options > > are modified TCP gets busted now. The problem is that when we > > propose window scaling, we expect that the other side receives the > > same initial SYN request that we sent. If there is corrupting > > firewalls that strip it then the window we send is not correctly > > scaled; so the other side thinks there is not enough space to send. > > If a firewall strips the window scaling option in both directions, > then window scaling is disabled (RFC 1323 section 2.2). > > Are you saying there are broken firewalls which strip TCP options in > one direction only? It appears so. From davem@redhat.com Tue Jul 6 13:15:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:15:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KFNgi009039 for ; Tue, 6 Jul 2004 13:15:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KFKe1030482; Tue, 6 Jul 2004 16:15:20 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KFK010574; Tue, 6 Jul 2004 16:15:20 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KEpsT006909; Tue, 6 Jul 2004 16:14:51 -0400 Date: Tue, 6 Jul 2004 13:12:35 -0700 From: "David S. Miller" To: Jamie Lokier Cc: shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706131235.10b5afa8.davem@redhat.com> In-Reply-To: <20040706194034.GA11021@mail.shareable.org> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1828 Lines: 49 On Tue, 6 Jul 2004 20:40:34 +0100 Jamie Lokier wrote: > If a firewall strips the window scaling option in both directions, > then window scaling is disabled (RFC 1323 section 2.2). > > Are you saying there are broken firewalls which strip TCP options in > one direction only? It is this specific case: 1) SYN packet contains window scale option of ZERO. This says two things, that the system will use a window scale of ZERO and that it SUPPORTS send and receive window scaling. If the firewall were to delete this, we'd be OK, but it does not. It leaves the option with zero in there. 2) SYN+ACK goes back out with non-zero window scale option. Note that because of #1, it is impossible for the system which sent the SYN packet to "refuse" the window scale option sent in the SYN+ACK. Here is where we have problems. If the firewall patches the scale to zero, which is what some of these things are doing, it is then the firewall's responsibility to scale the window to make it appear to be zero-scaled. And this is not being done by these broken firewalls. BTW, this is why it is so important to get tcpdump traces at both ends of the connection to analyze problems like this. If you look at only one side with dumps, you might not get the side that is getting packets edited by a firewall or other device. These machines are so broken that I absolutely refuse to change how we behave to work around them. If they want window scaling to be effectively disabled, they should patch out the window scale option in the "SYN" packet, this prevents the SYN+ACK sending system from advertising any window scaling support. What these broken devices are doing is effectively making window scaling unusable on the internet, and I refuse to swallow such crap. From davem@redhat.com Tue Jul 6 13:19:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:19:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KJPgi009372 for ; Tue, 6 Jul 2004 13:19:25 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KJ2e1031508; Tue, 6 Jul 2004 16:19:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KJ2011564; Tue, 6 Jul 2004 16:19:02 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KIWeH008764; Tue, 6 Jul 2004 16:18:32 -0400 Date: Tue, 6 Jul 2004 13:16:17 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: shemminger@osdl.org, ahu@ds9a.nl, acme@conectiva.com.br, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706131617.39484eff.davem@redhat.com> In-Reply-To: <40EB04C7.4000007@us.ibm.com> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <40EB04C7.4000007@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1621 Lines: 36 On Tue, 06 Jul 2004 13:00:07 -0700 Nivedita Singhvi wrote: > Stephen Hemminger wrote: > > Recent TCP changes exposed the problem that there ar lots of really broken firewalls > > that strip or alter TCP options. > > We should not be accepting of this situation, surely. I mean, the firewalls > have to get fixed. Multiple things are breaking here, due to this. What > are the other options they are messing with, and and any idea why? I totally agree with Nivedita, and that's why I'm not going to apply Stephen's patch. > If the firewall is actually stripping the TCP window scaling option, > then that tells the other end that we can't *receive* scaled windows > either, since the option indicates both, we are sending and capable > of receiving. i.e. The other end will not send us scaled windows. > There is no way we can fix this on the rcv end. > That's correct. If the SYN contains a window scale option, this tells the SYN+ACK sending side that both receive and send side window scaling is supported. I think what's really happening is that the firewall is patching the non-zero window scale option in the SYN+ACK packet to be zero, yet not adjusting the window field of packets in the rest of the TCP stream. > Does this need to be the default behaviour? Just how prevalent is > this?? Frankly, I've personally seen none of this. I sit on a DSL line with no firewalling at my end and I can access all sites just fine. This seems to indicate that most of the breakage is local to the user's point of access to the net, rather than a firewall at google.com or kernel.org or similar. From davem@redhat.com Tue Jul 6 13:20:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:20:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KKIgi009537 for ; Tue, 6 Jul 2004 13:20:18 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KKGe1031864; Tue, 6 Jul 2004 16:20:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KKG012033; Tue, 6 Jul 2004 16:20:16 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KJk3I009514; Tue, 6 Jul 2004 16:19:47 -0400 Date: Tue, 6 Jul 2004 13:17:31 -0700 From: "David S. Miller" To: Jan-Benedict Glaw Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706131731.540dd5fd.davem@redhat.com> In-Reply-To: <20040706185856.GN18841@lug-owl.de> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706185856.GN18841@lug-owl.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 928 Lines: 20 On Tue, 6 Jul 2004 20:58:56 +0200 Jan-Benedict Glaw wrote: > On Tue, 2004-07-06 11:47:41 -0700, Stephen Hemminger > wrote in message <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net>: > > > I propose that the following that will avoid sending window scaling that > > is big enough to break in these cases unless the tcp_rmem has been increased. > > It will keep default configuration from blowing in a corrupt world. > > I'm not sure if this is the right way to react. I'd think it's okay to > give the user the possibility to scale the window so that it works with > his b0rk3d firewall, but default behavior should be to do whatever the > protocol dictates/allows. I totally agree, and that's why the sysctl is there for people to tweak as they desire. Jan, any particular reason you removed so much stuff (in particular netdev@oss.sgi.com) from the CC: list in your posting here? From davem@redhat.com Tue Jul 6 13:23:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:23:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KNMgi009994 for ; Tue, 6 Jul 2004 13:23:25 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KMee1032698; Tue, 6 Jul 2004 16:22:40 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KMe013077; Tue, 6 Jul 2004 16:22:40 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KMBa1011076; Tue, 6 Jul 2004 16:22:11 -0400 Date: Tue, 6 Jul 2004 13:19:55 -0700 From: "David S. Miller" To: bert hubert Cc: acme@conectiva.com.br, shemminger@osdl.org, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com Subject: Re: analysis of TCP window size issues still around - several reports / SACK involved? Message-Id: <20040706131955.3a3c6c8b.davem@redhat.com> In-Reply-To: <20040706093503.GA8147@outpost.ds9a.nl> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1320 Lines: 22 On Tue, 6 Jul 2004 11:35:03 +0200 bert hubert wrote: > 22:42:40.890025 192.168.1.6.32843 > 204.152.189.116.http: S 1994994484:1994994484(0) win 5840 (DF) > 22:42:41.143063 204.152.189.116.http > 192.168.1.6.32843: S 1404108869:1404108869(0) ack 1994994485 win 5792 (DF) > 22:42:41.143123 192.168.1.6.32843 > 204.152.189.116.http: . ack 1 win 45 (DF) > > Alessandro's machine does perform window scaling, tcpdump however does not > understand that and neglects to multiply 45 by 2^7 (=5760). Kernel.org does do > wscale, but defaults to 2^0. tcpdump's behavior is correct, it's just reporting the raw window field in the TCP header, unscaled, and that is fine. In fact I'd rather it do this, so that diagnosing dumps are easier. If tcpdump tries to be too clever, scaling the window, then I might end up chasing down a tcpdump bug rather than a TCP one :-) What would be more interesting is to get the tcpdump trace from the other side of this connection. This is crucial, as it will show how and in what way exactly the window scale options and/or window fields are being edited by a firewall or other device and thus causing the problems. From david+challenge-response@blue-labs.org Tue Jul 6 13:26:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:26:58 -0700 (PDT) Received: from blue-labs.org (wsip-68-99-153-203.ri.ri.cox.net [68.99.153.203]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KQWgi010337 for ; Tue, 6 Jul 2004 13:26:53 -0700 Received: from [24.250.19.246] (ip24-250-19-246.ri.ri.cox.net [24.250.19.246]) (authenticated bits=0) by blue-labs.org (8.12.11/8.12.11) with ESMTP id i66KPBn0028828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2004 16:25:16 -0400 Message-ID: <40EB0AE7.40803@blue-labs.org> Date: Tue, 06 Jul 2004 16:26:15 -0400 From: David Ford User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8a2) Gecko/20040706 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Nivedita Singhvi , shemminger@osdl.org, ahu@ds9a.nl, acme@conectiva.com.br, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <40EB04C7.4000007@us.ibm.com> <20040706131617.39484eff.davem@redhat.com> In-Reply-To: <20040706131617.39484eff.davem@redhat.com> Content-Type: multipart/mixed; boundary="------------060801060905010902050409" X-archive-position: 6684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david+challenge-response@blue-labs.org Precedence: bulk X-list: netdev Content-Length: 1222 Lines: 42 This is a multi-part message in MIME format. --------------060801060905010902050409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It's been a while since I used a 1460 MTU for PPTP over DSL, but unless OSDN got a clue recently, their firewalls drop the ICMP for PMTU discovery. Does anyone have a tool that exercises a bunch of TCP/IP options to detect such broken firewalls? David David S. Miller wrote: >[...] >Frankly, I've personally seen none of this. I sit on a DSL line with >no firewalling at my end and I can access all sites just fine. This >seems to indicate that most of the breakage is local to the user's >point of access to the net, rather than a firewall at google.com >or kernel.org or similar. > --------------060801060905010902050409 Content-Type: text/x-vcard; charset=utf-8; name="david+challenge-response.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="david+challenge-response.vcf" begin:vcard fn:David Ford n:Ford;David email;internet:david@blue-labs.org title:Industrial Geek tel;home:Ask please tel;cell:(203) 650-3611 x-mozilla-html:TRUE version:2.1 end:vcard --------------060801060905010902050409-- From davem@redhat.com Tue Jul 6 13:31:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:31:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KVDgi010731 for ; Tue, 6 Jul 2004 13:31:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KV7e1002549; Tue, 6 Jul 2004 16:31:07 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KV7015768; Tue, 6 Jul 2004 16:31:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KUb4I015573; Tue, 6 Jul 2004 16:30:37 -0400 Date: Tue, 6 Jul 2004 13:28:22 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706132822.70c8174a.davem@redhat.com> In-Reply-To: <20040706130549.31daa8e0@dell_ss3.pdx.osdl.net> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706130549.31daa8e0@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 499 Lines: 16 On Tue, 6 Jul 2004 13:05:49 -0700 Stephen Hemminger wrote: > On Tue, 6 Jul 2004 20:40:34 +0100 > Jamie Lokier wrote: > > > Are you saying there are broken firewalls which strip TCP options in > > one direction only? > > It appears so. Ok, this is a possibility. And why it breaks is that if the ACK for the SYN+ACK comes back, the SYN+ACK sender can only assume that the window scale was accepted. Stephen, do you have a trace showing exactly this? From shemminger@osdl.org Tue Jul 6 13:32:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:32:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KWGgi010912 for ; Tue, 6 Jul 2004 13:32:17 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i66KW1G30385; Tue, 6 Jul 2004 13:32:02 -0700 Date: Tue, 6 Jul 2004 13:31:46 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Jan-Benedict Glaw , linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706133146.7ed47c69@dell_ss3.pdx.osdl.net> In-Reply-To: <20040706131731.540dd5fd.davem@redhat.com> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706185856.GN18841@lug-owl.de> <20040706131731.540dd5fd.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1392 Lines: 31 On Tue, 6 Jul 2004 13:17:31 -0700 "David S. Miller" wrote: > On Tue, 6 Jul 2004 20:58:56 +0200 > Jan-Benedict Glaw wrote: > > > On Tue, 2004-07-06 11:47:41 -0700, Stephen Hemminger > > wrote in message <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net>: > > > > > I propose that the following that will avoid sending window scaling that > > > is big enough to break in these cases unless the tcp_rmem has been increased. > > > It will keep default configuration from blowing in a corrupt world. > > > > I'm not sure if this is the right way to react. I'd think it's okay to > > give the user the possibility to scale the window so that it works with > > his b0rk3d firewall, but default behavior should be to do whatever the > > protocol dictates/allows. > > I totally agree, and that's why the sysctl is there for people to > tweak as they desire. > > Jan, any particular reason you removed so much stuff (in particular > netdev@oss.sgi.com) from the CC: list in your posting here? The point is we are sending a bigger window scale then we need to. The maximum receive window is limited by tcp_rmem[2], so we only need to allow that much. Having a different sysctl just for that is unnecessary and potentially confusing. The default tcp_rmem[2] is 174760, so we only need a wscale of 2 to represent that. We were sending 7. From davem@redhat.com Tue Jul 6 13:35:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:35:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KZNgi011369 for ; Tue, 6 Jul 2004 13:35:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KRBe1001297; Tue, 6 Jul 2004 16:27:11 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KRB014284; Tue, 6 Jul 2004 16:27:11 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KQf77013285; Tue, 6 Jul 2004 16:26:41 -0400 Date: Tue, 6 Jul 2004 13:24:26 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: ahu@ds9a.nl, acme@conectiva.com.br, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706132426.097f71e6.davem@redhat.com> In-Reply-To: <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1491 Lines: 36 On Tue, 6 Jul 2004 11:47:41 -0700 Stephen Hemminger wrote: > The problem is that when > we propose window scaling, we expect that the other side receives the same initial > SYN request that we sent. If there is corrupting firewalls that strip it then > the window we send is not correctly scaled; so the other side thinks there is not > enough space to send. Inaccurate analysis Stephen. If the window option is edited out from the SYN by the firewall, it is impossible for the receiving system to respond with any window scaling option in the SYN+ACK packet. If a window scale option is not present in the SYN, it means that it does not support window scaling at all. What must be really happening, therefore, is that the firewall is patching the scale factor in the option, not deleting it outright. And then it isn't properly rescaling the window field in the TCP headers for the rest of the connection's lifetime. That would explain all of this. We can confirm this by getting a trace at both ends of a sick connection, and seeing if a non-zero window scale option gets patched to some other value by the time it reaches the receiving system. Then we will be aware of two bugs: 1) Cisco IOS, when NAT'ing, can mis-adjust SACK block options such that the sequence numbers are corrupt. 2) Some firewalls patch non-zero window scale options to be zero ones yet do not properly adjust the window field in TCP headers for the rest of the connection. From davem@redhat.com Tue Jul 6 13:36:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:36:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KZkgi011378 for ; Tue, 6 Jul 2004 13:36:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KY7e1003318; Tue, 6 Jul 2004 16:34:08 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KY7016937; Tue, 6 Jul 2004 16:34:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KXcDl016967; Tue, 6 Jul 2004 16:33:38 -0400 Date: Tue, 6 Jul 2004 13:31:22 -0700 From: "David S. Miller" To: bert hubert Cc: acme@conectiva.com.br, shemminger@osdl.org, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com Subject: Re: analysis of TCP window size issues still around - several reports / SACK involved? Message-Id: <20040706133122.25a05ca1.davem@redhat.com> In-Reply-To: <20040706202708.GA1385@outpost.ds9a.nl> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706131955.3a3c6c8b.davem@redhat.com> <20040706202708.GA1385@outpost.ds9a.nl> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 564 Lines: 15 On Tue, 6 Jul 2004 22:27:08 +0200 bert hubert wrote: > On Tue, Jul 06, 2004 at 01:19:55PM -0700, David S. Miller wrote: > > > What would be more interesting is to get the tcpdump trace from the > > other side of this connection. This is crucial, as it will show how > > and in what way exactly the window scale options and/or window fields > > are being edited by a firewall or other device and thus causing > > the problems. > > I have an appointment with Alessandro tomorrow evening at 11PM CEST to do > just that. That's great, thanks a lot. From davem@redhat.com Tue Jul 6 13:36:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:36:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KaVgi011816 for ; Tue, 6 Jul 2004 13:36:51 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66KaSe1004104; Tue, 6 Jul 2004 16:36:28 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66KaS017812; Tue, 6 Jul 2004 16:36:28 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KZwWA017992; Tue, 6 Jul 2004 16:35:58 -0400 Date: Tue, 6 Jul 2004 13:33:43 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jbglaw@lug-owl.de, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706133343.111556a8.davem@redhat.com> In-Reply-To: <20040706133146.7ed47c69@dell_ss3.pdx.osdl.net> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706185856.GN18841@lug-owl.de> <20040706131731.540dd5fd.davem@redhat.com> <20040706133146.7ed47c69@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 600 Lines: 14 On Tue, 6 Jul 2004 13:31:46 -0700 Stephen Hemminger wrote: > The default tcp_rmem[2] is 174760, so we only need a wscale of 2 to represent > that. We were sending 7. It's only going to paper over this problem, because a window scale of 2 still gets edited by the firewalls yet doesn't cause the kind of damage 7 does. Also, using a value of 7 is very safe, because it handles even the tinyest of MTU's in use today (512 byte SLIP connections, for example can still advertise sub-MTU sized chunks in the window). Since a window scale of 7 allows a granularity of 128 octets. From shemminger@osdl.org Tue Jul 6 13:37:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:37:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Kasgi011966 for ; Tue, 6 Jul 2004 13:37:14 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i66KafG31920; Tue, 6 Jul 2004 13:36:41 -0700 Date: Tue, 6 Jul 2004 13:36:41 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706133641.4a58af30@dell_ss3.pdx.osdl.net> In-Reply-To: <20040706132822.70c8174a.davem@redhat.com> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706130549.31daa8e0@dell_ss3.pdx.osdl.net> <20040706132822.70c8174a.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 750 Lines: 22 On Tue, 6 Jul 2004 13:28:22 -0700 "David S. Miller" wrote: > On Tue, 6 Jul 2004 13:05:49 -0700 > Stephen Hemminger wrote: > > > On Tue, 6 Jul 2004 20:40:34 +0100 > > Jamie Lokier wrote: > > > > > Are you saying there are broken firewalls which strip TCP options in > > > one direction only? > > > > It appears so. > > Ok, this is a possibility. And why it breaks is that if the ACK > for the SYN+ACK comes back, the SYN+ACK sender can only assume > that the window scale was accepted. > > Stephen, do you have a trace showing exactly this? No, I don't have a br0ken firewall here. I can get out fine. When I setup with same kernel as packages.gentoo.org, it works fine as well. From davem@redhat.com Tue Jul 6 13:39:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:39:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Kckgi012585 for ; Tue, 6 Jul 2004 13:39:06 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66Kcie1004645; Tue, 6 Jul 2004 16:38:44 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66Kci018530; Tue, 6 Jul 2004 16:38:44 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KcEeS019078; Tue, 6 Jul 2004 16:38:14 -0400 Date: Tue, 6 Jul 2004 13:35:59 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706133559.70b6380d.davem@redhat.com> In-Reply-To: <20040706133641.4a58af30@dell_ss3.pdx.osdl.net> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706130549.31daa8e0@dell_ss3.pdx.osdl.net> <20040706132822.70c8174a.davem@redhat.com> <20040706133641.4a58af30@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 745 Lines: 21 On Tue, 6 Jul 2004 13:36:41 -0700 Stephen Hemminger wrote: > > Ok, this is a possibility. And why it breaks is that if the ACK > > for the SYN+ACK comes back, the SYN+ACK sender can only assume > > that the window scale was accepted. > > > > Stephen, do you have a trace showing exactly this? > > No, I don't have a br0ken firewall here. I can get out fine. > When I setup with same kernel as packages.gentoo.org, it works fine as well. Therefore we do not know which of the following two it really is: 1) window scale option being stripped from SYN+ACK 2) non-zero window option being patched into a zero window scale option The trace Bert Hubert will get with Alessandro will give us the information we need. From tim@tsearch.com Tue Jul 6 13:43:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:43:08 -0700 (PDT) Received: from tsimail.tsearch.com (64-3-142-15.dia.xo.com [64.3.142.15] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Kh7gi012922 for ; Tue, 6 Jul 2004 13:43:07 -0700 Received: by 64-3-142-15.dia.xo.com with Internet Mail Service (5.5.2653.19) id <3D7HXQAK>; Tue, 6 Jul 2004 13:35:57 -0700 Message-ID: <828E111C7AEF60468FAA5FBC696DD80F67DF37@64-3-142-15.dia.xo.com> From: Tim Berti To: Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: RE: [PATCH] fix tcp_default_win_scale. Date: Tue, 6 Jul 2004 13:35:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 6692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tim@tsearch.com Precedence: bulk X-list: netdev Content-Length: 1267 Lines: 44 How do i get off this list? Tim Berti Senior Recruiter TECHNOLOGY SEARCH INTERNATIONAL 1737 North First Street, Suite 600 San Jose, CA. 95112 http://www.tsearch.com Email: tim@tsearch.com Phone: 408-437-9500 Ext. 303 -----Original Message----- From: Stephen Hemminger [mailto:shemminger@osdl.org] Sent: Tuesday, July 06, 2004 1:37 PM To: David S. Miller Cc: jamie@shareable.org; netdev@oss.sgi.com; linux-net@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. On Tue, 6 Jul 2004 13:28:22 -0700 "David S. Miller" wrote: > On Tue, 6 Jul 2004 13:05:49 -0700 > Stephen Hemminger wrote: > > > On Tue, 6 Jul 2004 20:40:34 +0100 > > Jamie Lokier wrote: > > > > > Are you saying there are broken firewalls which strip TCP options in > > > one direction only? > > > > It appears so. > > Ok, this is a possibility. And why it breaks is that if the ACK > for the SYN+ACK comes back, the SYN+ACK sender can only assume > that the window scale was accepted. > > Stephen, do you have a trace showing exactly this? No, I don't have a br0ken firewall here. I can get out fine. When I setup with same kernel as packages.gentoo.org, it works fine as well. From david+challenge-response@blue-labs.org Tue Jul 6 13:53:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:53:46 -0700 (PDT) Received: from blue-labs.org (wsip-68-99-153-203.ri.ri.cox.net [68.99.153.203]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KrNgi013392 for ; Tue, 6 Jul 2004 13:53:43 -0700 Received: from [24.250.19.246] (ip24-250-19-246.ri.ri.cox.net [24.250.19.246]) (authenticated bits=0) by blue-labs.org (8.12.11/8.12.11) with ESMTP id i66KrJtP001793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2004 16:53:22 -0400 Message-ID: <40EB1181.40406@blue-labs.org> Date: Tue, 06 Jul 2004 16:54:25 -0400 From: David Ford User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8a2) Gecko/20040706 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Berti CC: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. References: <828E111C7AEF60468FAA5FBC696DD80F67DF37@64-3-142-15.dia.xo.com> In-Reply-To: <828E111C7AEF60468FAA5FBC696DD80F67DF37@64-3-142-15.dia.xo.com> Content-Type: multipart/mixed; boundary="------------060300030605010502050107" X-archive-position: 6693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david+challenge-response@blue-labs.org Precedence: bulk X-list: netdev Content-Length: 2410 Lines: 97 This is a multi-part message in MIME format. --------------060300030605010502050107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit By recruiting someone with enough of a technology clue to scroll to the bottom of the message and read: "To unsubscribe from ...." :P David p.s. and I wonder why I have so little faith in marketing and HR. Tim Berti wrote: >How do i get off this list? > >Tim Berti >Senior Recruiter >TECHNOLOGY SEARCH INTERNATIONAL >1737 North First Street, Suite 600 >San Jose, CA. 95112 >http://www.tsearch.com >Email: tim@tsearch.com >Phone: 408-437-9500 Ext. 303 > > > >-----Original Message----- >From: Stephen Hemminger [mailto:shemminger@osdl.org] >Sent: Tuesday, July 06, 2004 1:37 PM >To: David S. Miller >Cc: jamie@shareable.org; netdev@oss.sgi.com; linux-net@vger.kernel.org; >linux-kernel@vger.kernel.org >Subject: Re: [PATCH] fix tcp_default_win_scale. > > >On Tue, 6 Jul 2004 13:28:22 -0700 >"David S. Miller" wrote: > > > >>On Tue, 6 Jul 2004 13:05:49 -0700 >>Stephen Hemminger wrote: >> >> >> >>>On Tue, 6 Jul 2004 20:40:34 +0100 >>>Jamie Lokier wrote: >>> >>> >>> >>>>Are you saying there are broken firewalls which strip TCP options in >>>>one direction only? >>>> >>>> >>>It appears so. >>> >>> >>Ok, this is a possibility. And why it breaks is that if the ACK >>for the SYN+ACK comes back, the SYN+ACK sender can only assume >>that the window scale was accepted. >> >>Stephen, do you have a trace showing exactly this? >> >> > >No, I don't have a br0ken firewall here. I can get out fine. >When I setup with same kernel as packages.gentoo.org, it works fine as well. >- >To unsubscribe from this list: send the line "unsubscribe linux-net" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html > > > --------------060300030605010502050107 Content-Type: text/x-vcard; charset=utf-8; name="david+challenge-response.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="david+challenge-response.vcf" begin:vcard fn:David Ford n:Ford;David email;internet:david@blue-labs.org title:Industrial Geek tel;home:Ask please tel;cell:(203) 650-3611 x-mozilla-html:TRUE version:2.1 end:vcard --------------060300030605010502050107-- From davem@redhat.com Tue Jul 6 13:58:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 13:58:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66KwZgi013729 for ; Tue, 6 Jul 2004 13:58:41 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66Kw4e1010054; Tue, 6 Jul 2004 16:58:04 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66Kw4026312; Tue, 6 Jul 2004 16:58:04 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66KvZpO031123; Tue, 6 Jul 2004 16:57:35 -0400 Date: Tue, 6 Jul 2004 13:55:19 -0700 From: "David S. Miller" To: Harald Welte Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH 2.6] ip6t_LOG and packets with hop-by-hop options Message-Id: <20040706135519.028b22b5.davem@redhat.com> In-Reply-To: <20040706160109.GO32707@sunbeam2> References: <20040706150918.GA5009@penguin.localdomain> <20040706160109.GO32707@sunbeam2> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 533 Lines: 13 On Tue, 6 Jul 2004 18:01:09 +0200 Harald Welte wrote: > On Tue, Jul 06, 2004 at 05:09:18PM +0200, Marcel Sebek wrote: > > Packet with IPPROTO_HOPOPTS extended header isn't logged properly by > > ip6t_LOG.c. It only prints PROTO=0 and nothing more, because > > IPPROTO_HOPOPTS=0 and in this file 0 is used to indicate last header. > > This patch fix it by using IPPROTO_NONE to indicate last header. > > looks fine to me. Dave, can you please include this to your tree? > Thanks. Applied, thanks everyone. From shemminger@osdl.org Tue Jul 6 14:06:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:06:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66L6Ngi014765 for ; Tue, 6 Jul 2004 14:06:27 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i66L5oG07181; Tue, 6 Jul 2004 14:05:50 -0700 Date: Tue, 6 Jul 2004 14:05:50 -0700 From: Stephen Hemminger To: Masahide NAKAMURA Cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-Id: <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> In-Reply-To: <20040705160500.208591b5@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 784 Lines: 24 On Mon, 5 Jul 2004 16:05:00 +0900 Masahide NAKAMURA wrote: > Hello, > > On Sat, 3 Jul 2004 19:46:32 +1000 > Herbert Xu wrote: > > > I'm in the process of writing two new modules fo ip(8), ippolicy and > > ipstate which will be a NETLINK based replacement for setkey. > > > > In order to do so, I need to get libnetlink to speak the XFRM protocol. > > Thus I've added a new nl_open function which allows the protocol to > > be specified. > > I agree with it. > > Anyway, I have code for ip(8) for similar reason. > The patch is below: > http://www.linux-ipv6.org/~nakam/ipxfrm-20040705.diff This code won't build with current kernel headers. There is no xfrmsel_icmp_type in current 2.6 definition of struct xfrm_selector. From davem@redhat.com Tue Jul 6 14:06:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:06:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66L5mgi014702 for ; Tue, 6 Jul 2004 14:06:08 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66L5ge1012233; Tue, 6 Jul 2004 17:05:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66L5g029115; Tue, 6 Jul 2004 17:05:42 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66L5Cmd002199; Tue, 6 Jul 2004 17:05:12 -0400 Date: Tue, 6 Jul 2004 14:02:56 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: util@deuroconsult.ro, netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040706140256.4a00251c.davem@redhat.com> In-Reply-To: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 548 Lines: 13 On Thu, 1 Jul 2004 11:33:12 -0700 Stephen Hemminger wrote: > This patch updates the network emulation packet scheduler. > * name changed from delay to netem since it does more than just delay > * Catalin's merged code to do packet reordering > * uses a socket queue's directly rather than layering on qdisc(fifo) > because this is used in performance tests. > * adds placeholder in API for future enhancements (rate and duplicate). > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From ahu@outpost.ds9a.nl Tue Jul 6 14:08:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:08:06 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66L7qgi015334 for ; Tue, 6 Jul 2004 14:07:53 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 59E104434; Tue, 6 Jul 2004 22:27:08 +0200 (CEST) Date: Tue, 6 Jul 2004 22:27:08 +0200 From: bert hubert To: "David S. Miller" Cc: acme@conectiva.com.br, shemminger@osdl.org, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com Subject: Re: analysis of TCP window size issues still around - several reports / SACK involved? Message-ID: <20040706202708.GA1385@outpost.ds9a.nl> Mail-Followup-To: bert hubert , "David S. Miller" , acme@conectiva.com.br, shemminger@osdl.org, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706131955.3a3c6c8b.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706131955.3a3c6c8b.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 6697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 923 Lines: 22 On Tue, Jul 06, 2004 at 01:19:55PM -0700, David S. Miller wrote: > rather it do this, so that diagnosing dumps are easier. If tcpdump > tries to be too clever, scaling the window, then I might end up > chasing down a tcpdump bug rather than a TCP one :-) True - it might want to print '43 (*128=5706)' or something like that. > What would be more interesting is to get the tcpdump trace from the > other side of this connection. This is crucial, as it will show how > and in what way exactly the window scale options and/or window fields > are being edited by a firewall or other device and thus causing > the problems. I have an appointment with Alessandro tomorrow evening at 11PM CEST to do just that. It sounds like window scaling may become yet another ECN... -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From davem@redhat.com Tue Jul 6 14:09:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:09:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66L97gi015668 for ; Tue, 6 Jul 2004 14:09:08 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66L92e1012962; Tue, 6 Jul 2004 17:09:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66L92030219; Tue, 6 Jul 2004 17:09:02 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66L8XT8004160; Tue, 6 Jul 2004 17:08:33 -0400 Date: Tue, 6 Jul 2004 14:06:17 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: util@deuroconsult.ro, netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.4] update to network emulation QOS scheduler Message-Id: <20040706140617.01e5c9c3.davem@redhat.com> In-Reply-To: <20040701131101.184f7840@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040701131101.184f7840@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 258 Lines: 9 On Thu, 1 Jul 2004 13:11:01 -0700 Stephen Hemminger wrote: > This is the 2.4 version of the conversion of simple network delay scheduler to > network emulator. > > Signed-off-by: Stephen Hemminger Also applied. From davem@redhat.com Tue Jul 6 14:14:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:14:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66LE2gi016127 for ; Tue, 6 Jul 2004 14:14:03 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66LDoe1013982; Tue, 6 Jul 2004 17:13:50 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66LDo031869; Tue, 6 Jul 2004 17:13:50 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66LDKjo006160; Tue, 6 Jul 2004 17:13:21 -0400 Date: Tue, 6 Jul 2004 14:11:05 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPCOMP] Exclude IPCOMP header from props.header_len Message-Id: <20040706141105.3b8920ba.davem@redhat.com> In-Reply-To: <20040706123127.GA18271@gondor.apana.org.au> References: <20040706123127.GA18271@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 732 Lines: 18 On Tue, 6 Jul 2004 22:31:27 +1000 Herbert Xu wrote: > This patch changes the value of props.header_len for IPCOMP to > exclude the IPCOMP header. The reason is that the IPCOMP header > is added only if the packet is compressible. That is, if the > size of the compressed payload plus the size of the IPCOMP header > is less than that of the original payload. > > This means that the IPCOMP encapsulation does not impose any > overhead at all as far as the MTU is concerned. The current > code incorrectly reduces the MTU by the size of the IPCOMP > header. > > As a side-effect, this means that we don't have to move the > IP header around when IPCOMP is used. Very nice patch Herbert, applied. From herbert@gondor.apana.org.au Tue Jul 6 14:32:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:32:38 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66LWQgi016678 for ; Tue, 6 Jul 2004 14:32:28 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BhxXW-0001bK-00; Wed, 07 Jul 2004 07:31:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BhxXM-0005au-00; Wed, 07 Jul 2004 07:31:36 +1000 Date: Wed, 7 Jul 2004 07:31:35 +1000 To: James Morris Cc: Paul Wouters , "D. Hugh Redelmeier" , dev@lists.openswan.org, Dominique Blas , netdev@oss.sgi.com Subject: Re: [Openswan dev] IPComp Message-ID: <20040706213135.GA21477@gondor.apana.org.au> References: <20040703113732.GA22082@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 743 Lines: 20 On Tue, Jul 06, 2004 at 10:34:55AM -0400, James Morris wrote: > > It's only called when an SA is initialized. This should not happen all > the time, and if you can't find 64k for such an ooperation you have big > problems. With most KMs the SAs are renegotiated periodically. So as time goes on memory fragmentation will eventually cause this to fail. You also to consider IPsec gateways where there are hundreds or thousands of SAs. Maybe we can use a vmalloc instead? That seems to be what the deflate module does. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@redhat.com Tue Jul 6 14:44:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:44:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66LiQgi017521 for ; Tue, 6 Jul 2004 14:44:27 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66LiIe1020942; Tue, 6 Jul 2004 17:44:18 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66LiI008949; Tue, 6 Jul 2004 17:44:18 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66Lhm4Q021695; Tue, 6 Jul 2004 17:43:49 -0400 Date: Tue, 6 Jul 2004 14:41:32 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: shemminger@osdl.org, util@deuroconsult.ro, netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040706144132.4a5fe83b.davem@redhat.com> In-Reply-To: <1089119090.4260.2.camel@jzny.localdomain> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040705194925.37b7efcb.davem@redhat.com> <1089119090.4260.2.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1961 Lines: 61 On 06 Jul 2004 09:04:50 -0400 jamal wrote: > On Mon, 2004-07-05 at 22:49, David S. Miller wrote: > > I'm going to hold off on Stephen's patches until Jamal and he has > > a chance to fight it out :-) > > Actually i would be fine with it if Stephen gets rid of the new "rate" > thing. Ok, so for now I'm going to just put in this part of Stephen's patch which just adds the rtnetlink.h include and the loss optimization. To be honest, the rate feature is such a tiny amount of code... it's not the end of the world if we put it in :-) # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/07/06 14:35:36-07:00 shemminger@osdl.org # [PKT_SCHED]: Two small netem fixes. # # - rtnetlink.h needs including # - optimize loss test so that net_random() call is not done # when no-loss is indicated # # Signed-off-by: Stephen Hemminger # Signed-off-by: David S. Miller # # net/sched/sch_netem.c # 2004/07/06 14:31:50-07:00 shemminger@osdl.org +2 -1 # [PKT_SCHED]: Two small netem fixes. # # - rtnetlink.h needs including # - optimize loss test so that net_random() call is not done # when no-loss is indicated # # Signed-off-by: Stephen Hemminger # Signed-off-by: David S. Miller # diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2004-07-06 14:36:05 -07:00 +++ b/net/sched/sch_netem.c 2004-07-06 14:36:05 -07:00 @@ -18,6 +18,7 @@ #include #include #include +#include #include @@ -54,7 +55,7 @@ pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); /* Random packet drop 0 => none, ~0 => all */ - if (q->loss >= net_random()) { + if (q->loss && q->loss >= net_random()) { sch->stats.drops++; return 0; /* lie about loss so TCP doesn't know */ } From jheffner@psc.edu Tue Jul 6 14:55:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 14:55:17 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66LtEgi017960 for ; Tue, 6 Jul 2004 14:55:14 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i66LtCD6016391 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Jul 2004 17:55:12 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i66LtCp3012796; Tue, 6 Jul 2004 17:55:12 -0400 (EDT) Date: Tue, 6 Jul 2004 17:55:12 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: , , Subject: Re: [PATCH] fix tcp_default_win_scale. In-Reply-To: <20040706133559.70b6380d.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 360 Lines: 10 Another bit to addr to the firewall / window scale mess: I remember from a while ago that the Cisco PIX firewalls would not allow a window scale of greater than 8. I don't know if they've fixed this or not. It seems like some sort of arbitrary limit. This is obviously not the problem people are seeing now, but could be a problem in the future. -John From davem@redhat.com Tue Jul 6 15:51:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 15:51:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Mpwgi019748 for ; Tue, 6 Jul 2004 15:51:58 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66Mpse1002620; Tue, 6 Jul 2004 18:51:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66Mps026540; Tue, 6 Jul 2004 18:51:54 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66MpOvP022682; Tue, 6 Jul 2004 18:51:25 -0400 Date: Tue, 6 Jul 2004 15:49:07 -0700 From: "David S. Miller" To: bert hubert Cc: jamie@shareable.org, shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706154907.422a6b73.davem@redhat.com> In-Reply-To: <20040706224453.GA6694@outpost.ds9a.nl> References: <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706131235.10b5afa8.davem@redhat.com> <20040706224453.GA6694@outpost.ds9a.nl> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1082 Lines: 23 On Wed, 7 Jul 2004 00:44:53 +0200 bert hubert wrote: > Not true - the outgoing SYN packet had window scale 7, when it was sent. The > SYN|ACK had window scale 0, when received by the initiating system. > > Also - even if the remote were to assume a 47 byte window size, would it not > be able to send small packets? Or does the window size also include > packet haders? SWS avoidance makes us not send packets. See this quote in an email from John Heffner the other week: ================================ To elaborate on my earlier mail. my hypothesis is that somehow the web server beleives that we sent a winscale of 0. In such a case, when we try to advertise our initial 4*MSS (5840 bytes) of window, with a window scale of 3 we use a value of 730 in the window field. All sender SWS avoidance (RFC1122) tests will fail, most notably 1 (because we already advertised 5840 bytes and 730 < 5840/2) and 3 (because 730 < 1460). With a winscale of 2, we will use a value of 1460 in the window field, so both tests will succeed. ================================ From jmorris@redhat.com Tue Jul 6 15:51:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 15:51:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66MpAgi019621 for ; Tue, 6 Jul 2004 15:51:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66Mome1002407; Tue, 6 Jul 2004 18:50:48 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66Mom026231; Tue, 6 Jul 2004 18:50:48 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i66Moi4G026375; Tue, 6 Jul 2004 18:50:45 -0400 Date: Tue, 6 Jul 2004 18:50:44 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: Paul Wouters , "D. Hugh Redelmeier" , , Dominique Blas , Subject: Re: [Openswan dev] IPComp In-Reply-To: <20040706213135.GA21477@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 722 Lines: 23 On Wed, 7 Jul 2004, Herbert Xu wrote: > With most KMs the SAs are renegotiated periodically. So as time > goes on memory fragmentation will eventually cause this to fail. > You also to consider IPsec gateways where there are hundreds or > thousands of SAs. > > Maybe we can use a vmalloc instead? That seems to be what the > deflate module does. I think it would be better to go with your original idea of allocating a scratch buffer for each packet, based on the size of the packet. IPComp is very slow path, and allocating 64k for each SA is optimizing for an uncommon worst case in a way which will potentially eat up a lot of memory (e.g. > 6MB for 100 tunnels). - James -- James Morris From davem@redhat.com Tue Jul 6 15:53:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 15:53:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Mr0gi020021 for ; Tue, 6 Jul 2004 15:53:00 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66Mr0e1002856; Tue, 6 Jul 2004 18:53:00 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66Mqx026825; Tue, 6 Jul 2004 18:52:59 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66MqUhV022993; Tue, 6 Jul 2004 18:52:30 -0400 Date: Tue, 6 Jul 2004 15:50:13 -0700 From: "David S. Miller" To: John Heffner Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040706155013.32af8e13.davem@redhat.com> In-Reply-To: References: <20040706133559.70b6380d.davem@redhat.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 484 Lines: 10 On Tue, 6 Jul 2004 17:55:12 -0400 (EDT) John Heffner wrote: > Another bit to addr to the firewall / window scale mess: I remember from > a while ago that the Cisco PIX firewalls would not allow a window scale of > greater than 8. I don't know if they've fixed this or not. It seems > like some sort of arbitrary limit. In what manner did it deal with > 8 window scales? By rewriting the option or deleting the option entirely from the SYN or SYN+ACK packets? From shemminger@osdl.org Tue Jul 6 15:59:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 15:59:21 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66MxAgi020644 for ; Tue, 6 Jul 2004 15:59:19 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i66MwwG26842; Tue, 6 Jul 2004 15:58:58 -0700 Date: Tue, 6 Jul 2004 15:58:58 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [RFC] TCP burst control Message-Id: <20040706155858.11b368e6@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 6832 Lines: 212 When using advanced congestion control it is possible for TCP to decide that it has a large window to fill with data right away. The problem is that if TCP creates long bursts, it becomes unfriendly to other flows and is more likely to overrun intermediate queues. This patch limits the amount of data in flight. It came from BICTCP 1.1 but it has been generalized to all TCP congestion algorithms. It has had some testing, but needs to be more widely tested. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2004-07-06 15:52:39 -07:00 +++ b/include/linux/sysctl.h 2004-07-06 15:52:39 -07:00 @@ -339,6 +339,7 @@ NET_TCP_BIC_LOW_WINDOW=104, NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, + NET_TCP_BURST_MODERATION=107, }; enum { diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h 2004-07-06 15:52:39 -07:00 +++ b/include/linux/tcp.h 2004-07-06 15:52:39 -07:00 @@ -341,6 +341,7 @@ __u32 sacked_out; /* SACK'd packets */ __u32 fackets_out; /* FACK'd packets */ __u32 high_seq; /* snd_nxt at onset of congestion */ + __u32 max_in_flight; /* for burst moderation */ __u32 retrans_stamp; /* Timestamp of the last retransmit, * also used in SYN-SENT to remember stamp of diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-07-06 15:52:39 -07:00 +++ b/include/net/tcp.h 2004-07-06 15:52:39 -07:00 @@ -613,6 +613,7 @@ extern int sysctl_tcp_bic_low_window; extern int sysctl_tcp_default_win_scale; extern int sysctl_tcp_moderate_rcvbuf; +extern int sysctl_tcp_burst_moderation; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; @@ -1335,8 +1336,11 @@ { tp->undo_marker = 0; tp->snd_ssthresh = tcp_recalc_ssthresh(tp); - tp->snd_cwnd = min(tp->snd_cwnd, - tcp_packets_in_flight(tp) + 1U); + if (sysctl_tcp_burst_moderation) + tp->snd_cwnd = min(tp->snd_cwnd, + max(tp->snd_ssthresh, tcp_packets_in_flight(tp) + 1U)); + else + tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp) + 1U); tp->snd_cwnd_cnt = 0; tp->high_seq = tp->snd_nxt; tp->snd_cwnd_stamp = tcp_time_stamp; @@ -1393,6 +1397,24 @@ tcp_minshall_check(tp)))); } +/* + * If doing packet burst moderation + * then check to see if we have used up our limit + */ +static __inline__ int +tcp_burst_exhausted(struct tcp_opt *tp) +{ + u32 cap = tp->max_in_flight; + + if (!sysctl_tcp_burst_moderation || cap == 0) + return 0; + + if (likely(tp->ca_state != TCP_CA_Recovery)) + cap += tcp_max_burst(tp) + (tp->snd_cwnd>>7); + + return (tcp_packets_in_flight(tp) >= cap); +} + /* This checks if the data bearing packet SKB (usually sk->sk_send_head) * should be put on the wire right now. */ @@ -1423,11 +1445,19 @@ /* Don't be strict about the congestion window for the * final FIN frame. -DaveM */ - return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && - ((tcp_packets_in_flight(tp) < tp->snd_cwnd) || - (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && - !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)); + if ((tcp_packets_in_flight(tp) >= tp->snd_cwnd || + tcp_burst_exhausted(tp)) && + !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) + return 0; /* no space in congestion window */ + + if (after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)) + return 0; /* send window full */ + + if (!((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode + || !tcp_nagle_check(tp, skb, cur_mss, nonagle))) + return 0; /* limited by sender */ + + return 1; } static __inline__ void tcp_check_probe_timer(struct sock *sk, struct tcp_opt *tp) diff -Nru a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c --- a/net/ipv4/sysctl_net_ipv4.c 2004-07-06 15:52:39 -07:00 +++ b/net/ipv4/sysctl_net_ipv4.c 2004-07-06 15:52:39 -07:00 @@ -682,6 +682,14 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_BURST_MODERATION, + .procname = "tcp_burst_moderation", + .data = &sysctl_tcp_burst_moderation, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-07-06 15:52:39 -07:00 +++ b/net/ipv4/tcp_input.c 2004-07-06 15:52:39 -07:00 @@ -91,6 +91,7 @@ int sysctl_tcp_vegas_cong_avoid; int sysctl_tcp_moderate_rcvbuf = 1; +int sysctl_tcp_burst_moderation = 1; /* Default values of the Vegas variables, in fixed-point representation * with V_PARAM_SHIFT bits to the right of the binary point. @@ -1596,7 +1597,11 @@ if (decr && tp->snd_cwnd > limit) tp->snd_cwnd -= decr; - tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1); + limit = tcp_packets_in_flight(tp)+1; + if (sysctl_tcp_burst_moderation) + limit = max(tp->snd_ssthresh, limit); + + tp->snd_cwnd = min(tp->snd_cwnd, limit); tp->snd_cwnd_stamp = tcp_time_stamp; } @@ -3823,8 +3828,13 @@ /* Limited by application or receiver window. */ u32 win_used = max(tp->snd_cwnd_used, 2U); if (win_used < tp->snd_cwnd) { + u32 limit = (tp->snd_cwnd + win_used) >> 1; tp->snd_ssthresh = tcp_current_ssthresh(tp); - tp->snd_cwnd = (tp->snd_cwnd + win_used) >> 1; + if (sysctl_tcp_burst_moderation) + tp->snd_cwnd = min(tp->snd_cwnd, + max(tp->snd_ssthresh, limit)); + else + tp->snd_cwnd = limit; } tp->snd_cwnd_used = 0; } @@ -4097,6 +4107,8 @@ struct tcphdr *th, unsigned len) { struct tcp_opt *tp = tcp_sk(sk); + + tp->max_in_flight = 0; /* * Header prediction. diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-07-06 15:52:39 -07:00 +++ b/net/ipv4/tcp_output.c 2004-07-06 15:52:39 -07:00 @@ -205,6 +205,10 @@ #define SYSCTL_FLAG_WSCALE 0x2 #define SYSCTL_FLAG_SACK 0x4 + if (sysctl_tcp_burst_moderation && !tp->max_in_flight) + tp->max_in_flight = tcp_packets_in_flight(tp) + + tcp_max_burst(tp); + sysctl_flags = 0; if (tcb->flags & TCPCB_FLAG_SYN) { tcp_header_size = sizeof(struct tcphdr) + TCPOLEN_MSS; @@ -948,6 +952,11 @@ if (tcp_packets_in_flight(tp) >= tp->snd_cwnd) return; + if (sysctl_tcp_burst_moderation && tp->max_in_flight) { + if (tcp_packets_in_flight(tp) >= tp->max_in_flight) + return; + } + if (sacked&TCPCB_LOST) { if (!(sacked&(TCPCB_SACKED_ACKED|TCPCB_SACKED_RETRANS))) { if (tcp_retransmit_skb(sk, skb)) @@ -996,6 +1005,11 @@ if (tcp_packets_in_flight(tp) >= tp->snd_cwnd) break; + + if (sysctl_tcp_burst_moderation && tp->max_in_flight) { + if (tcp_packets_in_flight(tp) >= tp->max_in_flight) + return; + } if(TCP_SKB_CB(skb)->sacked & TCPCB_TAGBITS) continue; From ahu@outpost.ds9a.nl Tue Jul 6 16:02:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 16:02:11 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66N1mgi020985 for ; Tue, 6 Jul 2004 16:02:08 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 3C9014468; Wed, 7 Jul 2004 01:01:47 +0200 (CEST) Date: Wed, 7 Jul 2004 01:01:47 +0200 From: bert hubert To: "David S. Miller" Cc: Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: PLS help fix: recent 2.6.7 won't connect to anything Re: [PATCH] fix tcp_default_win_scale. Message-ID: <20040706230147.GB6694@outpost.ds9a.nl> Mail-Followup-To: bert hubert , "David S. Miller" , Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org References: <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706130549.31daa8e0@dell_ss3.pdx.osdl.net> <20040706132822.70c8174a.davem@redhat.com> <20040706133641.4a58af30@dell_ss3.pdx.osdl.net> <20040706133559.70b6380d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706133559.70b6380d.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 6708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1529 Lines: 39 On Tue, Jul 06, 2004 at 01:35:59PM -0700, David S. Miller wrote: > Therefore we do not know which of the following two it really is: Anybody with this problem is kindly invited to try to connect to 213.244.168.210, port 10000, http://213.244.168.210:10000/ should work. If you have a problem, email me with your IP address, I have a tcpdump running. > 1) window scale option being stripped from SYN+ACK The remote is in fact zeus-pub.kernel.org. I assume it does not have a broken firewall, and I sure haven't, and it sends out to me: 00:46:31.936667 192.168.1.4.34018 > 204.152.189.116.80: S 2786942165:2786942165(0) win 5840 (DF) 00:46:32.097745 204.152.189.116.80 > 192.168.1.4.34018: S 2888442437:2888442437(0) ack 2786942166 win 5792 (DF) ^ 00:46:32.098170 192.168.1.4.34018 > 204.152.189.116.80: . ack 1 win 45 (DF) So I would rule out 1), as this is a network that does not have the problem. > 2) non-zero window option being patched into a zero window > scale option This looks more likely, on the outgoing SYN. We'll know tomorrow evening (CEST) or earlier if somebody with the problem volunteers. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From davem@redhat.com Tue Jul 6 16:07:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 16:08:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66N7cgi021398 for ; Tue, 6 Jul 2004 16:07:58 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i66N7Ze1005779; Tue, 6 Jul 2004 19:07:35 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i66N7Z030488; Tue, 6 Jul 2004 19:07:35 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i66N755r028068; Tue, 6 Jul 2004 19:07:05 -0400 Date: Tue, 6 Jul 2004 16:04:47 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, rhee@ncsu.edu Subject: Re: [RFC] TCP burst control Message-Id: <20040706160447.3c2efffa.davem@redhat.com> In-Reply-To: <20040706155858.11b368e6@dell_ss3.pdx.osdl.net> References: <20040706155858.11b368e6@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 721 Lines: 16 On Tue, 6 Jul 2004 15:58:58 -0700 Stephen Hemminger wrote: > When using advanced congestion control it is possible for TCP to decide that > it has a large window to fill with data right away. The problem is that if TCP > creates long bursts, it becomes unfriendly to other flows and is more likely > to overrun intermediate queues. > > This patch limits the amount of data in flight. It came from BICTCP 1.1 but it > has been generalized to all TCP congestion algorithms. It has had some testing, > but needs to be more widely tested. Both the New Reno and Westwood+ algorithms implement rate-halving to solve this problem. Why can't BICTCP use that instead of this special burst control hack? From lkml@metanurb.dk Tue Jul 6 16:19:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 16:19:55 -0700 (PDT) Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66NJUgi025140 for ; Tue, 6 Jul 2004 16:19:51 -0700 Received: from [192.168.1.2] (0x50c49cd1.adsl-fixed.tele.dk [80.196.156.209]) by pfepc.post.tele.dk (Postfix) with ESMTP id 3D699262810; Wed, 7 Jul 2004 01:19:25 +0200 (CEST) Subject: Re: [PATCH] fix tcp_default_win_scale. From: Redeeman To: Stephen Hemminger Cc: "David S. Miller" , bert hubert , Arnaldo Carvalho de Melo , netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, linux-net@vger.kernel.org, LKML Mailinglist In-Reply-To: <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> Content-Type: text/plain Date: Wed, 07 Jul 2004 01:19:25 +0200 Message-Id: <1089155965.15544.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9 Content-Transfer-Encoding: 7bit X-archive-position: 6710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lkml@metanurb.dk Precedence: bulk X-list: netdev Content-Length: 1196 Lines: 23 On Tue, 2004-07-06 at 11:47 -0700, Stephen Hemminger wrote: > Recent TCP changes exposed the problem that there ar lots of really broken firewalls > that strip or alter TCP options. > When the options are modified TCP gets busted now. The problem is that when > we propose window scaling, we expect that the other side receives the same initial > SYN request that we sent. If there is corrupting firewalls that strip it then > the window we send is not correctly scaled; so the other side thinks there is not > enough space to send. > > I propose that the following that will avoid sending window scaling that > is big enough to break in these cases unless the tcp_rmem has been increased. > It will keep default configuration from blowing in a corrupt world. so this should fix the issues? can you also tell me why this suddenly happend? that would make me a real happy man > Signed-off-by: Stephen Hemminger > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From ahu@outpost.ds9a.nl Tue Jul 6 16:21:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 16:21:29 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66NLDgi025348 for ; Tue, 6 Jul 2004 16:21:16 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D43C04466; Wed, 7 Jul 2004 00:44:53 +0200 (CEST) Date: Wed, 7 Jul 2004 00:44:53 +0200 From: bert hubert To: "David S. Miller" Cc: Jamie Lokier , shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-ID: <20040706224453.GA6694@outpost.ds9a.nl> Mail-Followup-To: bert hubert , "David S. Miller" , Jamie Lokier , shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org References: <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706131235.10b5afa8.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706131235.10b5afa8.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 6711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 626 Lines: 21 On Tue, Jul 06, 2004 at 01:12:35PM -0700, David S. Miller wrote: > It is this specific case: > > 1) SYN packet contains window scale option of ZERO. Not true - the outgoing SYN packet had window scale 7, when it was sent. The SYN|ACK had window scale 0, when received by the initiating system. Also - even if the remote were to assume a 47 byte window size, would it not be able to send small packets? Or does the window size also include packet haders? Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ak@suse.de Tue Jul 6 16:53:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 16:53:56 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i66Nrhgi026225 for ; Tue, 6 Jul 2004 16:53:44 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id AAE8E828D14; Wed, 7 Jul 2004 01:16:00 +0200 (CEST) Date: Wed, 7 Jul 2004 01:16:00 +0200 From: Andi Kleen To: "David S. Miller" Cc: Stephen Hemminger , ahu@ds9a.nl, acme@conectiva.com.br, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-ID: <20040706231600.GA18181@wotan.suse.de> References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706132426.097f71e6.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706132426.097f71e6.davem@redhat.com> X-archive-position: 6712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 610 Lines: 17 I would not change anything, just suggest that users who sit behind such a broken device do echo 0 > /proc/sys/net/ipv4/tcp_window_scaling and yell loudly at their ISPs to get this fixed. Crippling the stack by default just to work around such obvious bugs would be wrong. In the past there were similar bugs with broken VJ header compression algorithms that also corrupted window scaling. We just ignored these and suggested to the users to turn it off. That worked fine. [btw it's quite possible that this isn't a firewall, but also some kind of header compression that is doing the wrong thing] -Andi From rhee@eos.ncsu.edu Tue Jul 6 17:10:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 17:10:18 -0700 (PDT) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i670ACgi027139 for ; Tue, 6 Jul 2004 17:10:13 -0700 Received: from RHEEOFFICE (cpe-024-211-189-208.nc.rr.com [24.211.189.208]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i6709wiA026673; Tue, 6 Jul 2004 20:09:59 -0400 (EDT) Message-Id: <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com> From: "Injong Rhee" To: "'David S. Miller'" , "'Stephen Hemminger'" Cc: , , Subject: RE: [RFC] TCP burst control Date: Tue, 6 Jul 2004 20:09:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040706160447.3c2efffa.davem@redhat.com> Thread-Index: AcRjrX68uuqM9HCvQ7W9isYilMlczwAB/0zw X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 6713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rhee@eos.ncsu.edu Precedence: bulk X-list: netdev Content-Length: 2307 Lines: 57 Hi David and Stephen, We tested this rate halving. In fact, rate having in fact degrades the performance quite a bit. We can send you more information about it. Our test indicates that this feature introduces many timeouts (because of bursts), and also cause unnecessary cwnd backoff to reduce the transmission unjustifiably low -- so there are many (I will repeat, many) window and transmission oscillations during packet losses. We fix this problem completely using our own special burst control. It is very simple and easy technique to implement. If you need some data to back up our claims, I will send you more. Once we implemented our burst control, we don't have any timeouts and not much fluctuation other than congestion control related. Currently with rate having, current Linux tcp stack is full of hacks that in fact, hurt the performance of linux tcp (sorry to say this). Our burst control, in fact, simplifies a lot of that and makes sure cwnd to follow very closely to whatever congestion control algorithm is intended it to behave. The Linux Reno burst control in fact interferes with the original congestion control (in fact, it tries to do its own), and its performance is very hard to predict. Hope this helps. Injong Rhee, Associate Professor North Carolina State University Raleigh, NC 27699 rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee -----Original Message----- From: David S. Miller [mailto:davem@redhat.com] Sent: Tuesday, July 06, 2004 7:05 PM To: Stephen Hemminger Cc: netdev@oss.sgi.com; rhee@ncsu.edu Subject: Re: [RFC] TCP burst control On Tue, 6 Jul 2004 15:58:58 -0700 Stephen Hemminger wrote: > When using advanced congestion control it is possible for TCP to decide that > it has a large window to fill with data right away. The problem is that if TCP > creates long bursts, it becomes unfriendly to other flows and is more likely > to overrun intermediate queues. > > This patch limits the amount of data in flight. It came from BICTCP 1.1 but it > has been generalized to all TCP congestion algorithms. It has had some testing, > but needs to be more widely tested. Both the New Reno and Westwood+ algorithms implement rate-halving to solve this problem. Why can't BICTCP use that instead of this special burst control hack? From davem@redhat.com Tue Jul 6 17:32:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 17:32:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i670W6gi027769 for ; Tue, 6 Jul 2004 17:32:09 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i670W1e1022438; Tue, 6 Jul 2004 20:32:01 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i670W1018063; Tue, 6 Jul 2004 20:32:01 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i670VVaV018169; Tue, 6 Jul 2004 20:31:32 -0400 Date: Tue, 6 Jul 2004 17:29:13 -0700 From: "David S. Miller" To: "Injong Rhee" Cc: shemminger@osdl.org, netdev@oss.sgi.com, rhee@ncsu.edu, lxu2@ncsu.edu, mathis@psc.edu Subject: Re: [RFC] TCP burst control Message-Id: <20040706172913.590710fe.davem@redhat.com> In-Reply-To: <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com> References: <20040706160447.3c2efffa.davem@redhat.com> <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 391 Lines: 10 On Tue, 6 Jul 2004 20:09:41 -0400 "Injong Rhee" wrote: > Currently with rate having, current Linux tcp stack is full of hacks that in > fact, hurt the performance of linux tcp (sorry to say this). If rate-halving is broken, have you taken this up with it's creator, Mr. Mathis? What was his response? I've added him to the CC: list so this can be properly discussed. From jheffner@psc.edu Tue Jul 6 18:32:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 18:32:23 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i671WCgi029567 for ; Tue, 6 Jul 2004 18:32:12 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i671WABh021226 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Jul 2004 21:32:10 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i671W9p3013683; Tue, 6 Jul 2004 21:32:09 -0400 (EDT) Date: Tue, 6 Jul 2004 21:32:09 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: , , Subject: Re: [PATCH] fix tcp_default_win_scale. In-Reply-To: <20040706155013.32af8e13.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 653 Lines: 18 On Tue, 6 Jul 2004, David S. Miller wrote: > On Tue, 6 Jul 2004 17:55:12 -0400 (EDT) > John Heffner wrote: > > > Another bit to addr to the firewall / window scale mess: I remember from > > a while ago that the Cisco PIX firewalls would not allow a window scale of > > greater than 8. I don't know if they've fixed this or not. It seems > > like some sort of arbitrary limit. > > In what manner did it deal with > 8 window scales? By rewriting the option > or deleting the option entirely from the SYN or SYN+ACK packets? I don't recall. It was not as ugly as changing the option value. It may have just sent a RST. -John From hadi@cyberus.ca Tue Jul 6 18:36:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 18:36:32 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i671aTgi029897 for ; Tue, 6 Jul 2004 18:36:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1Bi1ML-0001w4-9d for netdev@oss.sgi.com; Tue, 06 Jul 2004 21:36:29 -0400 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 1Bi1MG-0000yw-Je; Tue, 06 Jul 2004 21:36:24 -0400 Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl In-Reply-To: <20040706090906.4ff6fb73@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040706090906.4ff6fb73@dell_ss3.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089164179.1039.26.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jul 2004 21:36:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2477 Lines: 48 On Tue, 2004-07-06 at 12:09, Stephen Hemminger wrote: > Your examples made me think about this more. The netfilter seem best > suited to things that effect the flow of packets (dropping, reordering, > even corrupting), and the qdisc seems best when the timing needs to change. Some of the attributes you are trying to control need queueing; no doubt the best spot to do queueing is on a qdisc. Delays, and reordering for example are ideal. Rate control as well fits here. There are other qdiscs which have done a really good job at rate control hence my arguement against you doing it - you will either not do a better job at it or if you do a good job you will be replicating what they already did; just stash your qdisc in another qdisc which can do a good rate control job (CBQ, TBF, HFSC, HTB) - we are flexible enough in Linux. Depending on where you want to do things, netfilter may be a good candidate (example IP protocol) or things that dont need queueing. The examples i gave are more powerful than anything netfilter can do at the moment though with only caveat theres only two "hooks". > The limit match in netfilter is not the same as the rate in the qdisc. > The netem scheduler acts as if the link is a slow fixed rate. The netfilter > limit is usually targeted to drop packets over the rate which is not the same. > Reordering is also hard without going out to a user log or building a custom > target. Not sure what the netfilter limit target is - i suspect its something that limits based on a group of flows. You can still do that with a fwamrk at the qdisc level. Reordering needs a queue. Even the example i gave uses a queue that resides on the dummy device. > So, you have convinced me that loss is unnecessary but not the rate, or delay. > If we can figure out how to re-ordering with netfilter then that could go too, > which would make it possible to use a layered qdisc again. I think keep the reordering aspect of it unless it is very complex. The delay is a must. If you can add configurable jitter to it that would be a big bonus. Keep the randomization. Duplication, dropping, bit error injection, and rate control are the ones i didnt see belonging there mostly because they can be done better elsewhere. Again this is just opinion, if you think that theres no complexity in the architecture, by all means keep all those features - my recommendation is to pick a few things that will work well and implement them well. cheers, jamal From davem@redhat.com Tue Jul 6 18:54:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 18:54:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i671shgi030452 for ; Tue, 6 Jul 2004 18:54:43 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i671sZe1008079; Tue, 6 Jul 2004 21:54:36 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i671sZ002610; Tue, 6 Jul 2004 21:54:35 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i671s58e008045; Tue, 6 Jul 2004 21:54:06 -0400 Date: Tue, 6 Jul 2004 18:51:46 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: shemminger@osdl.org, util@deuroconsult.ro, netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040706185146.4894e9d9.davem@redhat.com> In-Reply-To: <1089164179.1039.26.camel@jzny.localdomain> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040706090906.4ff6fb73@dell_ss3.pdx.osdl.net> <1089164179.1039.26.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 487 Lines: 12 On 06 Jul 2004 21:36:20 -0400 jamal wrote: > Not sure what the netfilter limit target is - i suspect its something > that limits based on a group of flows. You can still do that with a > fwamrk at the qdisc level. Reordering needs a queue. Even the example i > gave uses a queue that resides on the dummy device. It's a netfilter iptables module that essentially uses sch_tbf.c's simple token bucket filter algorithm. See net/ipv4/netfilter/ipt_limit.c for details. From hadi@cyberus.ca Tue Jul 6 20:41:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 20:41:47 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i673fggj003398 for ; Tue, 6 Jul 2004 20:41:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BgayX-0004lA-1h for netdev@oss.sgi.com; Fri, 02 Jul 2004 23:14:01 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BgayS-0002F1-JE; Fri, 02 Jul 2004 23:13:56 -0400 Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl In-Reply-To: <20040702134437.5891e998@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1088824432.1043.271.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Jul 2004 23:13:52 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3017 Lines: 80 On Fri, 2004-07-02 at 16:44, Stephen Hemminger wrote: > Here is an enhancement to netem to do allow emulating lower speed > networks. The resolution is close, but obviously limited by the > granularity of timers and size of packets. > > Also, fixes a rtnetlink dependency which showed up in some configurations > and optimizes for the non-loss case by avoiding net_random call. > I think its time i illustrate my comments earlier with some example hopefully this will curb the amount of features on this qdisc. I do think theres value in having this thing do delay and jitter, but you have gone waay beyond that now; Let illustrate things which apply to what you are trying to do in network condituions emulation. Although i show ingress qdisc , this applies to egress just the same. #drop 1 out 10 packets randomly using the netrand generator tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ match ip src 10.0.0.21/32 flowid 1:16 \ action drop random netrand ok 0xa Note, you can plugin another randomization algorithm (a point i was trying to make earlier; currently supporting netrandom and deterministic algorithms only) #deterministically accept every second packet, drop the rest tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ match ip src 10.0.0.22/32 flowid 1:16 \ action drop random determ ok 2 # deterministically duplicate every second packet # tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ match ip src 10.0.0.21/32 flowid 1:16 \ action ok random determ pipe 2 \ action mirred egress mirror dev dummy0 Interesting thing is depending on what you have attached on the dummy0 device you could reorder or delay. Example you could hookup that qdisc to delay. Lets do something more interesting ... # # deterministically duplicate every second packet that # exceeds 100Kbit for packets coming in from 10.0.0.31 # and give it a fwmark of 2. Dummy could do something # with that info # # tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ match ip src 10.0.0.31/32 flowid 1:16 \ action ipt -j mark --set-mark 1 \ action police rate 100kbit burst 90k pipe \ action ok random determ pipe 2 \ action ipt -j mark --set-mark 2 \ action mirred egress mirror dev dummy0 Lets do something even more interesting .. tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ match ip src 10.0.0.31/32 flowid 1:16 \ action police rate 100kbit burst 90k pipe \ action pedit munge offset 4 u32 set 0x12341234 \ action ok random determ pipe 2 \ action mirred egress mirror dev dummy0 Note: we introduced some error in the packet bits by randomly setting some value in some offset; checksums etc will be wrong as a result. This happens for all packets exceeding 100Kbits. Every second packet which has been trampled is also duplicated... I hope this makes my point clearer. For testing or emulating conditions just create actions and serialize them for the flows and in/egress device you want them on. Create new ones that dont exist. cheers, jamal From hadi@cyberus.ca Tue Jul 6 20:41:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 20:41:46 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i673fggi003398 for ; Tue, 6 Jul 2004 20:41:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Bi3JX-00049B-4B for netdev@oss.sgi.com; Tue, 06 Jul 2004 23:41:43 -0400 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 1Bi3JS-0005cM-Mh; Tue, 06 Jul 2004 23:41:38 -0400 Subject: Re: [RFR] gianfar ethernet driver From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Andy Fleming , Kumar Gala , netdev@oss.sgi.com, dwmw2@infradead.org In-Reply-To: <20040707032913.GA1822@havoc.gtf.org> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <1089170282.1038.80.camel@jzny.localdomain> <20040707032913.GA1822@havoc.gtf.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089171693.1037.87.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jul 2004 23:41:34 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1276 Lines: 45 On Tue, 2004-07-06 at 23:29, Jeff Garzik wrote: > On Tue, Jul 06, 2004 at 11:18:02PM -0400, jamal wrote: > > You dont return a 1 anywhere. > > That OK in one model. True returning 0 this is not wrong; it results in an extra call in the layer above the driver. (I was trying to point that out in earlier email) > When you are not dealing with fragments, the most optimal model > eliminates the overflow case completely, so your ->hard_start_xmit looks > like > > lock > queue packet to DMA ring > if (DMA ring full) > netif_stop_queue() > unlock > > return 0 > > If you can be sure -- by design -- that room is always available when > the queue is not stopped, then that's fine. > > With fragments, you cannot be sure of this, if you do not wish to > reserve MY_HW_MAX_FRAGMENTS slots on the DMA. Such a case would require > moving the "if no more descriptors" check up, and returning 1 when the > ring is empty. > > But ideally, you should write the driver where such a condition does not > occur at all. Ok, I overlooked fragments. I think it would be useful to capture this in the doc you were preping. BTW, why can you figure out the fragment count? If you can then the check for number of descriptors availabel could account for that. cheers, jamal From niv@us.ibm.com Tue Jul 6 21:07:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 21:07:30 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6747Rgi004489 for ; Tue, 6 Jul 2004 21:07:27 -0700 Received: from e3.ny.us.ibm.com (e3.esmtp.ibm.com [9.14.6.103]) by pokfb.esmtp.ibm.com (8.12.10/8.12.9) with ESMTP id i672JcYT028720 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 6 Jul 2004 22:19:39 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i672Iows710884; Tue, 6 Jul 2004 22:18:50 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i672Je4A118874; Tue, 6 Jul 2004 22:19:41 -0400 Message-ID: <40EB5E0B.1030407@us.ibm.com> Date: Tue, 06 Jul 2004 19:20:59 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Injong Rhee CC: "'David S. Miller'" , "'Stephen Hemminger'" , netdev@oss.sgi.com, rhee@ncsu.edu, lxu2@ncsu.edu Subject: Re: [RFC] TCP burst control References: <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com> In-Reply-To: <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1438 Lines: 31 Injong Rhee wrote: > Hi David and Stephen, > > We tested this rate halving. In fact, rate having in fact degrades the > performance quite a bit. We can send you more information about it. Our test > indicates that this feature introduces many timeouts (because of bursts), > and also cause unnecessary cwnd backoff to reduce the transmission > unjustifiably low -- so there are many (I will repeat, many) window and > transmission oscillations during packet losses. We fix this problem Could you point me to a paper or summary of your info? > completely using our own special burst control. It is very simple and easy > technique to implement. If you need some data to back up our claims, I will > send you more. Once we implemented our burst control, we don't have any > timeouts and not much fluctuation other than congestion control related. > Currently with rate having, current Linux tcp stack is full of hacks that in > fact, hurt the performance of linux tcp (sorry to say this). Our burst > control, in fact, simplifies a lot of that and makes sure cwnd to follow > very closely to whatever congestion control algorithm is intended it to > behave. The Linux Reno burst control in fact interferes with the original > congestion control (in fact, it tries to do its own), and its performance is > very hard to predict. Can you characterize the workload/traffic/error rate that each would be best suited for? thanks, Nivedita From nakam@linux-ipv6.org Tue Jul 6 21:10:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 21:10:05 -0700 (PDT) Received: from localhost (kame202.kame.net [203.178.141.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i674A2gi004898 for ; Tue, 6 Jul 2004 21:10:02 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1Bi3kl-0000ag-00; Wed, 07 Jul 2004 13:09:51 +0900 Date: Wed, 7 Jul 2004 13:09:50 +0900 From: Masahide NAKAMURA To: Stephen Hemminger Cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-Id: <20040707130950.0112edf6@localhost> In-Reply-To: <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1310 Lines: 42 On Tue, 6 Jul 2004 14:05:50 -0700 Stephen Hemminger wrote: > On Mon, 5 Jul 2004 16:05:00 +0900 > Masahide NAKAMURA wrote: > > > Hello, > > > > On Sat, 3 Jul 2004 19:46:32 +1000 > > Herbert Xu wrote: > > > > > I'm in the process of writing two new modules fo ip(8), ippolicy and > > > ipstate which will be a NETLINK based replacement for setkey. > > > > > > In order to do so, I need to get libnetlink to speak the XFRM protocol. > > > Thus I've added a new nl_open function which allows the protocol to > > > be specified. > > > > I agree with it. > > > > Anyway, I have code for ip(8) for similar reason. > > The patch is below: > > http://www.linux-ipv6.org/~nakam/ipxfrm-20040705.diff > > This code won't build with current kernel headers. There is no xfrmsel_icmp_type > in current 2.6 definition of struct xfrm_selector. I've made another patch which can build with 2.6.7 kernel headers. (And I removed some unnecessary code for the kernel.) Try below: http://www.linux-ipv6.org/~nakam/ipxfrm-20040707.diff BTW, The definition in previous patch is for understanding ICMP type/code by xfrm_selector. I wrote the kernel feature and I'm testing it. Anyway, I'll send it to the list, too. Thanks, -- Masahide NAKAMURA From garzik@havoc.gtf.org Tue Jul 6 21:11:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 21:11:29 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i674BHgi005224 for ; Tue, 6 Jul 2004 21:11:17 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id BE40C758D; Tue, 6 Jul 2004 23:29:38 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i673TDPW001954; Tue, 6 Jul 2004 23:29:13 -0400 Date: Tue, 6 Jul 2004 23:29:13 -0400 From: Jeff Garzik To: jamal Cc: Andy Fleming , Kumar Gala , netdev@oss.sgi.com, dwmw2@infradead.org Subject: Re: [RFR] gianfar ethernet driver Message-ID: <20040707032913.GA1822@havoc.gtf.org> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <1089170282.1038.80.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089170282.1038.80.camel@jzny.localdomain> User-Agent: Mutt/1.4.1i X-archive-position: 6722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 946 Lines: 41 On Tue, Jul 06, 2004 at 11:18:02PM -0400, jamal wrote: > You dont return a 1 anywhere. That OK in one model. > Heres what i mean (substitute your code): > if no more descriptors > netif_stop_queue(dev) > unlock > return 1 > process packet and stash on ring > return 0 When you are not dealing with fragments, the most optimal model eliminates the overflow case completely, so your ->hard_start_xmit looks like lock queue packet to DMA ring if (DMA ring full) netif_stop_queue() unlock return 0 If you can be sure -- by design -- that room is always available when the queue is not stopped, then that's fine. With fragments, you cannot be sure of this, if you do not wish to reserve MY_HW_MAX_FRAGMENTS slots on the DMA. Such a case would require moving the "if no more descriptors" check up, and returning 1 when the ring is empty. But ideally, you should write the driver where such a condition does not occur at all. Jeff From jgarzik@pobox.com Tue Jul 6 22:03:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:03:18 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6753Dgi006560 for ; Tue, 6 Jul 2004 22:03:14 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bi4aN-0004xG-UN; Wed, 07 Jul 2004 06:03:12 +0100 Message-ID: <40EB8403.9000802@pobox.com> Date: Wed, 07 Jul 2004 01:02:59 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.7-bk19] prism54 freq to channel incorrect for 5GHz References: <200407061738.07098.margitsw@t-online.de> In-Reply-To: <200407061738.07098.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 110 Lines: 6 applied. any comment on Sam's comment? is there generic code, so that we can avoid driver-specific code? From nakam@linux-ipv6.org Tue Jul 6 22:05:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:05:48 -0700 (PDT) Received: from localhost (kame202.kame.net [203.178.141.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6755igi006933 for ; Tue, 6 Jul 2004 22:05:45 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1Bi4cg-0000dq-00; Wed, 07 Jul 2004 14:05:34 +0900 Date: Wed, 7 Jul 2004 14:05:33 +0900 From: Masahide NAKAMURA To: Stephen Hemminger Cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-Id: <20040707140533.41c66c03@localhost> In-Reply-To: <20040707130950.0112edf6@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 492 Lines: 24 Oops, I'm sorry, the patch below is still broken. Please wait for fixing it. On Wed, 7 Jul 2004 13:09:50 +0900 Masahide NAKAMURA wrote: > Try below: > http://www.linux-ipv6.org/~nakam/ipxfrm-20040707.diff > > > BTW, The definition in previous patch is for understanding ICMP > type/code by xfrm_selector. I wrote the kernel feature and I'm > testing it. Anyway, I'll send it to the list, too. > > Thanks, > > -- > Masahide NAKAMURA > > -- Masahide NAKAMURA From jgarzik@pobox.com Tue Jul 6 22:08:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:08:49 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6758Qgi007258 for ; Tue, 6 Jul 2004 22:08:47 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bi4fS-00051R-26; Wed, 07 Jul 2004 06:08:26 +0100 Message-ID: <40EB853E.5000504@pobox.com> Date: Wed, 07 Jul 2004 01:08:14 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: netdev@oss.sgi.com Subject: Re: [PATCH] fix compiler warnings in mv64340_eth References: <20040706105215.GA14731@lst.de> In-Reply-To: <20040706105215.GA14731@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 33 Lines: 2 patch OK, but patch(1) rejected From davem@redhat.com Tue Jul 6 22:16:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:16:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i675GGgi007772 for ; Tue, 6 Jul 2004 22:16:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i675GAe1018408; Wed, 7 Jul 2004 01:16:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i675GA011779; Wed, 7 Jul 2004 01:16:10 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i675Fegg021868; Wed, 7 Jul 2004 01:15:40 -0400 Date: Tue, 6 Jul 2004 22:13:17 -0700 From: "David S. Miller" To: Alexey Kuznetsov Cc: hadi@cyberus.ca, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: bk16 changes to cbq Message-Id: <20040706221317.2f0585d1.davem@redhat.com> In-Reply-To: <20040705202727.GA21226@ms2.inr.ac.ru> References: <1088861810.1039.298.camel@jzny.localdomain> <20040705202727.GA21226@ms2.inr.ac.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1407 Lines: 32 On Tue, 6 Jul 2004 00:27:27 +0400 Alexey Kuznetsov wrote: > > What i remember is this (4-5 years back) used to cure a bug - cant > > remember the details unfortunately, but Alexey may remember. > > Actually, I do not. It looks like an optimization: if the device is > throttled we just do not need to add timer, qdisc will be woken up > by unthrottle. I do not see any race condition here, but also I do not > see why this check could be important. > > > At the expense of repeating a discussion that may have already happened, > > To be honest, I wish to be reminded. If this check cured something, > it would be interesting to know what was this. e1000 would hang the delay scheduler sometimes Let me look for the exact email from Stephen. Here it is: http://mailman.ds9a.nl/pipermail/lartc/2004q2/012736.html Jamal read this, and that is what prompted him to say that if the delay scheduler was made classful instead of "pretending" to be, the bug mentioned in Stephen's email would not occur. I do not understand things fully. I think it would help if, for example, each of the qdisc and classification operations had some comments describing the exact semantics of each ops->method. For example, what does requeue do and what is it indicating with each of the possible return values. What is expected of it? What kind of state is it allowed to leave the queue in? From jgarzik@pobox.com Tue Jul 6 22:27:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:28:03 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i675Rvgi008181 for ; Tue, 6 Jul 2004 22:27:58 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bi4yH-0005FB-E4; Wed, 07 Jul 2004 06:27:53 +0100 Message-ID: <40EB89CC.2040100@pobox.com> Date: Wed, 07 Jul 2004 01:27:40 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: Kumar Gala , netdev@oss.sgi.com, dwmw2@infradead.org, hadi@cyberus.ca Subject: Re: [RFR] gianfar ethernet driver References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> In-Reply-To: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 7901 Lines: 214 Andy Fleming wrote: >>> 7) ethtool_ops should not be kmalloc'd. >>> + dev_ethtool_ops = >>> + (struct ethtool_ops *)kmalloc(sizeof(struct >>> ethtool_ops), >>> + GFP_KERNEL); > > > Is there a particular reason? The reason I did it this way is because > the driver supports a 10/100 controller which does not have the RMON > statistics, and therefore should not read from that register space. So > I needed to use different functions to fill in the statistics lists. Just switch out one static pointer for another, once you know the hardware you're dealing with. You _must_ have that knowledge anyway, before calling register_netdev(), otherwise you're got a race in initialization versus interface-up. >>> 8) I recommend enabling _both_ hardware interrupt coalescing and NAPI, >>> at the same time. Several other Linux net drivers need to be changed to >>> do this, as well > > > Ok... but this is possible with the driver as it is. Interrupt > Coalescing is runtime configurable, and NAPI is a compile-time option. > NAPI can sometimes hurt performance, and so we'd like to have the > ability to disable it for some deployments. I guess I'm not sure what > change this suggestion was meant to cause. Default hardware mitigation to on in all cases, and preferably NAPI as well. If you see cases that hurt performance, that wants investigating. >>> 14) surely gfar_set_mac_address() needs some sort of synchronization? > > > I'm not sure why. It only gets called during gfar_open(), and > startup_gfar() gets called after it. Incorrect. Set-mac-address can be called when the interface is up and active, such as by the bonding driver. >>> 15) gfar_change_mtu() synchronization appears absent? > > > I'm not exactly sure what kind of synchronization is expected here. > stop_gfar() and startup_gfar() do modify the appropriate hardware values. Same conditions (and response) as set-mac-address. These can be called while you're actively DMAing packets. >>> 23) gfar_set_multi() does not appear to take into account huge >>> multi-cast lists. Drivers usually handle large dev->mc_count by falling >>> back to ALLMULTI behavior. > > > Actually, it does. The bits which are set represent hash table values. > Essentially, the MAC addr is converted to an 8-bit CRC. This value > then serves as an index to the 256-bit hash table. If the list is > large, then certain bits may be written twice, but if all the bits are > set, then the behavior is the same as in the ALLMULTI behavior -- every > multicast packet arrives. It would be a mistake, IMHO, to cut it off > after N entries, as several of those entries could overlap in the > bitmap. Clearly, the less bits which are set, the more effective the > hardware filter, so checking each address will, I think, always be a > performance win or tie (on the filtering side) over ALLMULTI ok >>> 24) setting IFF_MULTICAST is suspicious at best, possibly wrong: >>> + dev->mtu = 1500; >>> + dev->set_multicast_list = gfar_set_multi; >>> + dev->flags |= IFF_MULTICAST; >>> + > > > I'll believe you, but is there a reason for this? I guess it's already > set, by default, so easy fix. follow the other drivers, and behave predictably :) >>> 28) I see you support register dump (good!), now please send the >>> register-pretty-print patch to the ethtool package :) > > > Heh. Well, I haven't written that, yet. There's actually a slight > problem, in that the 85xx registers are 32-bit, and refuse to be > accessed as bytes. I'll be sure to look at that in the near...ish future. Nothing wrong with accessing registers as 32-bit quantities. That attribute is common to a lot of NICs. >>> 31) infinite loops, particularly on 1-bits, are discouraged: >>> + /* Wait for the transaction to finish */ >>> + while (gfar_read(®base->miimind) & (MIIMIND_NOTVALID | >>> MIIMIND_BUSY)) >>> + cpu_relax(); > > > What is the suggested method for waiting for the bus to be free? Should > I timeout after some time, and bring the driver down? it's really up to you, as it depends on the implementation platforms. The most simple is to include a counter that counts down to zero, and starts some absurdly large number like 100000. >>> 33) merge-stopper: mii_parse_sr(). never wait for autonegotiation to >>> complete. it is an asynchronous operation that could exceed 30 seconds. > > > Hmm... > >>> 34) merge-stopper: dm9161_wait(). same thing as #33. > > > This may be a problem. That function is there to work around an issue > in the PHY, wherein if you try to configure it before it has come up all > the way, it refuses to bring the link up. We've sworn at this code many > times, but there has, as of yet, not been a good suggestion as to how we > can ensure that the 9161 is ready before we configure it. I interpret that as a driver bug :) As common sense, regardless of phy bugs, you should not be trying to configure the MAC _or_ the phy in the middle of autonegotiation. Presumeably you are using a combination of netif_stop_queue(), netif_carrier_off(), and netif_device_detach() to achieve this. >>> 35) liberally borrow code and ideas from Ben H's sungem_phy.c. >>> Eventually we want to move to a generic phy module. > > > Heh. ironically, I stole liberally from the ibm_emac driver, which now > looks exactly like the sungem_phy code for phy handling. A generic phy > module would be a good thing, and I'm even interested in helping with > code and/or suggestions. If nothing else, I'll jump on the new generic > phy module bandwagon! Cool. This item #35 is more of a long term "think about it" type of request. Please do not hesitate to think of ways that you could share code with sungem_phy.c, and/or make them both use the same API, and submit patches along those lines :) It's not enough to just write a driver, help change Linux for the better :) > From Jamal: > >> >> 1) The check (in gfar_start_xmit()): >> >> Should happen much sooner - i.e before the skb is touched. > > > I'm not sure I agree here. What I am doing is detecting the full state > before an skb needs to be rejected. I am testing the NEXT descriptor to > see if it is ready (if not, dirty_tx will be pointing to it). This way, > I always handle any skb that is passed to gfar_start_xmit() See my comments to jamal as well: if you guarantee that you always have room on the DMA ring for an additional skb, that check should never be needed. Some extremely cautious/paranoid programmers will add a check, with a printk noting it's a BUG (i.e. impossible) condition, such as if (unlikely(... no more descriptors ...)) { printk(KERN_ERR "%s: BUG: no room for TX\n", dev->name); netif_stop_queue(); spin_unlock_irqrestore(); return 1; } ... queue TX to hardware ... if (no more descriptors) netif_stop_queue() spin_unlock_irqrestore() >> 2) Also its pretty scary if you are doing: >> txbdp->status |= TXBD_INTERRUPT for every packet. >> Look at other drivers, they try to do this every few packets; >> or enable tx mitigation to slow the rate of those interupts. > > > I don't believe this is as dire as you think. This bit only indicates > that, if the conditions are right, an interrupt will be generated once > that descriptor is processed, and its data sent. Conditions which > mitigate that are: > 1) coalescing is on, and the timer and counter have not triggered the > interrupt yet > 2) NAPI is enabled, and so interrupts are disabled after the first > packet arrives > 3) NAPI is disabled, but the driver is currently handling a previous > interrupt, so the interrupts are disabled for now. Even at 10/100 speeds, you really don't want to be generating one interrupt per Tx... Jeff From rhee@eos.ncsu.edu Tue Jul 6 22:46:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:46:57 -0700 (PDT) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i675kqgi008738 for ; Tue, 6 Jul 2004 22:46:52 -0700 Received: from RHEEOFFICE (cpe-024-211-189-208.nc.rr.com [24.211.189.208]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i675kkPf008128; Wed, 7 Jul 2004 01:46:46 -0400 (EDT) Message-Id: <200407070546.i675kkPf008128@ms-smtp-01-eri0.southeast.rr.com> From: "Injong Rhee" To: "'David S. Miller'" Cc: , , , , Subject: RE: [RFC] TCP burst control Date: Wed, 7 Jul 2004 01:46:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040706172913.590710fe.davem@redhat.com> Thread-Index: AcRjuUuAeciBdgh8RGO0vqMiaXPb8QAK2ljw X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 6728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rhee@eos.ncsu.edu Precedence: bulk X-list: netdev Content-Length: 4249 Lines: 92 Hi David, Let me clarify the issue a little. In my earlier message, I might have sounded like accusing rate halving of the burst problem and window oscillation. I might have misrepresented it a little in the heat of writing the email too fast :-). In fact, rate halving helps ease burst during fast recovery as written in the Internet draft. The main problem lies in the variable that rate halving is closely interacting with in TCP SACK implementation: packet_in_flight (or pipe_). In the current implementation of Linux TCP SACK, cwnd is set to packet_in_flight + C for every ack for CWR, recovery, and timeout-- Here C is 1 to 3. But many times, packet_in_flight drops *far* below cwnd during fast recovery. In high speed networks, a lot of packets can be lost in one RTT (even acks as well because of slow CPUs). If that happens, packet_in_flight becomes very small. At this time, Linux cwnd moderation (or burst control) kicks in by setting cwnd to packet_in_flight + C so that the sender does not burst all those packets between packet_in_flight and cwnd at a single time. However, there is a problem with this approach. Since cwnd is kept to very small, the transmission rate drops to almost zero during fast recovery -- it should drop only to half of the current transmission rate (or in high-speed protocols like BIC, it is only 87% of the current rate). Since fast recovery lasts more than several RTTs, the network capacity is highly underutilized during fast recovery. Furthermore, right after fast recovery, cwnd goes into slow start since cwnd is typically far smaller than ssthrsh after fast recovery. This also creates a lot of burst -- likely causing back to back losses or even timeouts. You can see this behavior in the following link: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B IC-600-75-7500-1-0-0-noburst/index.htm We run in a dummynet without any change in the burst control. You can see that whenever there is fast recovery, the rate almost drop to zero. The pink line is the throughput observed from the dummynet at every second, and red one is from Iperf. In the second figure, you can see cwnd. It drops to the bottom during fast recovery -- this is not part of congestion control. It is the burst control of Linux SACK doing it. But with our new burst control: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B IC-600-75-7500-1-0-0/index.htm You can see that cwnd is quite stabilized and the throughput does not have as much dip as in the original case. Here is what we do: instead of reducing cwnd to packet_in_flight (which is, in fact, meddling with congestion control), we reduce the gap between these two numbers by allowing transmitting more packets per ack (we set this to three more packets per ack) until packet_in_flight becomes close to cwnd. Also right after fast recovery, we increase packet_in_flight by 1% of packet_in_flight up to cwnd. This reduces the huge burst after fast recovery. Our implementation is trying to leave cwnd only to congestion control and separates burst control from congestion control. This makes the behavior of congestion control more predictable. We will report more on this tomorrow when we get back to the Lab to test some other environments, especially when we have smaller buffers. This scheme may not be the cure for all and needs more testing. So far, it has been working very well. Stay tuned. Injong. --- Injong Rhee, Associate Professor North Carolina State University Raleigh, NC 27699 rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee -----Original Message----- From: David S. Miller [mailto:davem@redhat.com] Sent: Tuesday, July 06, 2004 8:29 PM To: Injong Rhee Cc: shemminger@osdl.org; netdev@oss.sgi.com; rhee@ncsu.edu; lxu2@ncsu.edu; mathis@psc.edu Subject: Re: [RFC] TCP burst control On Tue, 6 Jul 2004 20:09:41 -0400 "Injong Rhee" wrote: > Currently with rate having, current Linux tcp stack is full of hacks that in > fact, hurt the performance of linux tcp (sorry to say this). If rate-halving is broken, have you taken this up with it's creator, Mr. Mathis? What was his response? I've added him to the CC: list so this can be properly discussed. From hadi@cyberus.ca Tue Jul 6 22:48:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:48:20 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i675mFgi008906 for ; Tue, 6 Jul 2004 22:48:16 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Bi2wo-0000f2-Ki for netdev@oss.sgi.com; Tue, 06 Jul 2004 23:18:14 -0400 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 1Bi2wh-0003gy-2I; Tue, 06 Jul 2004 23:18:07 -0400 Subject: Re: [RFR] gianfar ethernet driver From: jamal Reply-To: hadi@cyberus.ca To: Andy Fleming Cc: Jeff Garzik , Kumar Gala , netdev@oss.sgi.com, dwmw2@infradead.org In-Reply-To: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089170282.1038.80.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Jul 2004 23:18:02 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4806 Lines: 126 On Tue, 2004-07-06 at 20:42, Andy Fleming wrote: > I've made many of the changes, and am working on others, but I would > like a few clarifications: > > Jeff Wrote: > >> 2) I'm strongly pondering vetoing try_fastroute() code in this driver. > >> Surely this should be in core net stack code... if it isn't already? > >> Jamal? > > Jamal wrote: > > I hardly know anybody still using this interface - i believe it is not > > useful after NAPI; maybe this comment would bring out some of the > > believers out of the woodwork to comment. > > Otherwise i would say kill it. > > Hmm.. We had some testing done (admittedly in 2.4), and this code > substantially increased routing speed for some cases. I admit, though, > that the code is ugly. It would be nice if the part which is clearly > generic across all controllers were inside the stack, but if no one > uses it (and finding an example of a driver which did was difficult), > then maybe it's not worth the effort. Can you describe your test scenarios where it was valuable and what kind of throughput (and possibly latency) you were seeing? BTW, is this a gige interface? > >> 8) I recommend enabling _both_ hardware interrupt coalescing and NAPI, > >> at the same time. Several other Linux net drivers need to be changed > >> to > >> do this, as well > > Ok... but this is possible with the driver as it is. Interrupt > Coalescing is runtime configurable, and NAPI is a compile-time option. > NAPI can sometimes hurt performance, and so we'd like to have the > ability to disable it for some deployments. I guess I'm not sure what > change this suggestion was meant to cause. In your observation when is NAPI hurting performance? I am familiar with one case where extra PCI reads become a problem consuming extra CPU. We have so far rejected to "fix" that. > > if (txbdp == priv->dirty_tx) { > > netif_stop_queue(dev) > > unlock > > return 1; > > } > > The rest of your code goes here .. > > > > Do this before the skb is touched. Note the return 1. This means dont > > add it to your priv->tx_skbuff[priv->skb_curtx] = skb before you do > > this. > > Right. Technically, I'm doing that one full call before the skb is > touched. I think you're just missing the line above it where I > increment the descriptor pointer to the next one. You dont return a 1 anywhere. Heres what i mean (substitute your code): if no more descriptors netif_stop_queue(dev) unlock return 1 process packet and stash on ring return 0 > > Dont understand why you have your own proivate list btw. > > Is there another list which deallocates skbs after I have transmitted > them? TX completion interupt is supposed to keep free them typically at the interupt handler. So no need to track them unless you are trying something fancy - hence my question. > > > > 2) Also its pretty scary if you are doing: > > txbdp->status |= TXBD_INTERRUPT for every packet. > > Look at other drivers, they try to do this every few packets; > > or enable tx mitigation to slow the rate of those interupts. > > I don't believe this is as dire as you think. This bit only indicates > that, if the conditions are right, an interrupt will be generated once > that descriptor is processed, and its data sent. Conditions which > mitigate that are: > 1) coalescing is on, and the timer and counter have not triggered the > interrupt yet This is what i was recommending; but even without this, look at the Becker style approach in a lot of drivers of not triggering interupts in all cases. > 2) NAPI is enabled, and so interrupts are disabled after the first > packet arrives Depends on approach you took for NAPI (sorry deleted code/email). If you went e1000 styloe, then you are correct. If you went tulip style, the tx interupts are still on. > 3) NAPI is disabled, but the driver is currently handling a previous > interrupt, so the interrupts are disabled for now. > > Since interrupts are so often disabled at the controller, this has the > effect of not letting each packet trigger an interrupt. You are theorizing here and doing a very poor job. Have you actually tried and proven this? This will discount everything to date thats been done to reduce interupt rates. > However, in a > low-traffic case, not setting the Interrupt bit in the descriptor will > cause the packet to sit around indefinitely, until a packet with the > bit set is sent. I am not sure i followed. But it seems to me thats a bug. > Obviously, with interrupt coalescing enabled, this > becomes less of an issue (assuming our hardware doesn't require the bit > in order to increment the frame counter or start the timeout timer...). Your hardware seems to be buggy or you not explaining well. Anyways, you know what to do in this area. cheers, jamal From rhee@eos.ncsu.edu Tue Jul 6 22:49:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 22:50:02 -0700 (PDT) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i675nvgi009397 for ; Tue, 6 Jul 2004 22:49:57 -0700 Received: from RHEEOFFICE (cpe-024-211-189-208.nc.rr.com [24.211.189.208]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i675nrPf008824; Wed, 7 Jul 2004 01:49:53 -0400 (EDT) Message-Id: <200407070549.i675nrPf008824@ms-smtp-01-eri0.southeast.rr.com> From: "Injong Rhee" To: "'Injong Rhee'" , "'David S. Miller'" Cc: , , , , Subject: RE: [RFC] TCP burst control Date: Wed, 7 Jul 2004 01:49:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <200407070546.i675kkPf008128@ms-smtp-01-eri0.southeast.rr.com> Thread-Index: AcRjuUuAeciBdgh8RGO0vqMiaXPb8QAK2ljwAABZtvA= X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 6730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rhee@eos.ncsu.edu Precedence: bulk X-list: netdev Content-Length: 4789 Lines: 111 Also some additional reports on this moderation problem can be found in http://www.hep.ucl.ac.uk/~ytl/tcpip/linux/tcp_moderate_cwnd/ Injong Rhee, Associate Professor North Carolina State University Raleigh, NC 27699 rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee -----Original Message----- From: Injong Rhee [mailto:rhee@eos.ncsu.edu] Sent: Wednesday, July 07, 2004 1:46 AM To: 'David S. Miller' Cc: shemminger@osdl.org; netdev@oss.sgi.com; rhee@ncsu.edu; lxu2@ncsu.edu; mathis@psc.edu Subject: RE: [RFC] TCP burst control Hi David, Let me clarify the issue a little. In my earlier message, I might have sounded like accusing rate halving of the burst problem and window oscillation. I might have misrepresented it a little in the heat of writing the email too fast :-). In fact, rate halving helps ease burst during fast recovery as written in the Internet draft. The main problem lies in the variable that rate halving is closely interacting with in TCP SACK implementation: packet_in_flight (or pipe_). In the current implementation of Linux TCP SACK, cwnd is set to packet_in_flight + C for every ack for CWR, recovery, and timeout-- Here C is 1 to 3. But many times, packet_in_flight drops *far* below cwnd during fast recovery. In high speed networks, a lot of packets can be lost in one RTT (even acks as well because of slow CPUs). If that happens, packet_in_flight becomes very small. At this time, Linux cwnd moderation (or burst control) kicks in by setting cwnd to packet_in_flight + C so that the sender does not burst all those packets between packet_in_flight and cwnd at a single time. However, there is a problem with this approach. Since cwnd is kept to very small, the transmission rate drops to almost zero during fast recovery -- it should drop only to half of the current transmission rate (or in high-speed protocols like BIC, it is only 87% of the current rate). Since fast recovery lasts more than several RTTs, the network capacity is highly underutilized during fast recovery. Furthermore, right after fast recovery, cwnd goes into slow start since cwnd is typically far smaller than ssthrsh after fast recovery. This also creates a lot of burst -- likely causing back to back losses or even timeouts. You can see this behavior in the following link: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B IC-600-75-7500-1-0-0-noburst/index.htm We run in a dummynet without any change in the burst control. You can see that whenever there is fast recovery, the rate almost drop to zero. The pink line is the throughput observed from the dummynet at every second, and red one is from Iperf. In the second figure, you can see cwnd. It drops to the bottom during fast recovery -- this is not part of congestion control. It is the burst control of Linux SACK doing it. But with our new burst control: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B IC-600-75-7500-1-0-0/index.htm You can see that cwnd is quite stabilized and the throughput does not have as much dip as in the original case. Here is what we do: instead of reducing cwnd to packet_in_flight (which is, in fact, meddling with congestion control), we reduce the gap between these two numbers by allowing transmitting more packets per ack (we set this to three more packets per ack) until packet_in_flight becomes close to cwnd. Also right after fast recovery, we increase packet_in_flight by 1% of packet_in_flight up to cwnd. This reduces the huge burst after fast recovery. Our implementation is trying to leave cwnd only to congestion control and separates burst control from congestion control. This makes the behavior of congestion control more predictable. We will report more on this tomorrow when we get back to the Lab to test some other environments, especially when we have smaller buffers. This scheme may not be the cure for all and needs more testing. So far, it has been working very well. Stay tuned. Injong. --- Injong Rhee, Associate Professor North Carolina State University Raleigh, NC 27699 rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee -----Original Message----- >From: David S. Miller [mailto:davem@redhat.com] Sent: Tuesday, July 06, 2004 8:29 PM To: Injong Rhee Cc: shemminger@osdl.org; netdev@oss.sgi.com; rhee@ncsu.edu; lxu2@ncsu.edu; mathis@psc.edu Subject: Re: [RFC] TCP burst control On Tue, 6 Jul 2004 20:09:41 -0400 "Injong Rhee" wrote: > Currently with rate having, current Linux tcp stack is full of hacks that in > fact, hurt the performance of linux tcp (sorry to say this). If rate-halving is broken, have you taken this up with it's creator, Mr. Mathis? What was his response? I've added him to the CC: list so this can be properly discussed. From margitsw@t-online.de Tue Jul 6 23:39:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 23:39:03 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i676cxgi010634 for ; Tue, 6 Jul 2004 23:39:00 -0700 Received: from fwd08.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1Bi64x-0006pi-01; Wed, 07 Jul 2004 08:38:51 +0200 Received: from roglap.local (S8JBQ+ZTZeHRkF+pkrA9onHI4s6l+zmAVWRk1ziwdtzNc8v3RU1gQv@[217.224.24.219]) by fwd08.sul.t-online.com with esmtp id 1Bi64g-1nN5720; Wed, 7 Jul 2004 08:38:34 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.7-bk19] prism54 freq to channel incorrect for 5GHz Date: Wed, 7 Jul 2004 08:31:47 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200407070831.47896.margitsw@t-online.de> X-Seen: false X-ID: S8JBQ+ZTZeHRkF+pkrA9onHI4s6l+zmAVWRk1ziwdtzNc8v3RU1gQv X-archive-position: 6731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 1972 Lines: 66 Jeff scribeth: > any comment on Sam's comment ? Sam was referring to this from the sourceforge madwifi project : * Convert MHz frequency to IEEE channel number. */ u_int ieee80211_mhz2ieee(u_int freq, u_int flags) { if (flags & IEEE80211_CHAN_2GHZ) { /* 2GHz band */ if (freq == 2484) return 14; if (freq < 2484) return (freq - 2407) / 5; else return 15 + ((freq - 2512) / 20); } else if (flags & IEEE80211_CHAN_5GHZ) { /* 5Ghz band */ return (freq - 5000) / 5; } else { /* either, guess */ if (freq == 2484) return 14; if (freq < 2484) return (freq - 2407) / 5; if (freq < 5000) return 15 + ((freq - 2512) / 20); return (freq - 5000) / 5; } } Mostly, the wirless drivers (airo, orinoco, prism54, etc) have a table for the freq's. For something generic, I would suggest something like this : u_int ieee80211_freq_to_channel(u_int freq) { /* 2.4 GHz channel 14 */ if ( freq == 2484 ) return 14; /* 2.4 GHz channels 1 - 13 */ if ( freq >= 2412 && freq <= 2472 ) return (freq - 2407) / 5; /* 2.4 GHz unofficial channels */ if ( freq > 2484 && freq < 5000 ) return 15 + ((freq - 2512) / 20); /* 5 GHz channels 0 - 200 */ if ( freq >= 5000 && freq <= 6000 ) return (freq - 5000) / 5; /* Undefined */ return 0; } Note that AFAIK, the 5GHz WLAN channels start at 34 (5.17 GHz) (but I am not sure) and I don't know the top limit (except that it is <= 6GHz). Maybe somebody can shed light on this. If there is a clear definition, that should be reflected int the code. And something similar for channel_to_freq. Apparently Japan is doing something in the 10GHz band - will have to look for details. Margit From util@deuroconsult.ro Tue Jul 6 23:40:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 23:40:10 -0700 (PDT) Received: from hosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i676e4gi010791 for ; Tue, 6 Jul 2004 23:40:05 -0700 Received: from hosting.rdsbv.ro (hosting.rdsbv.ro [213.157.185.164]) by hosting.rdsbv.ro (8.12.11/8.12.11) with ESMTP id i676dYst005665; Wed, 7 Jul 2004 09:39:48 +0300 Date: Wed, 7 Jul 2004 09:39:34 +0300 (EEST) From: Catalin BOIE X-X-Sender: util@hosting.rdsbv.ro To: jamal cc: "David S. Miller" , shemminger@osdl.org, netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler In-Reply-To: <1089119090.4260.2.camel@jzny.localdomain> Message-ID: References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040705194925.37b7efcb.davem@redhat.com> <1089119090.4260.2.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 506 Lines: 22 On Tue, 6 Jul 2004, jamal wrote: > On Mon, 2004-07-05 at 22:49, David S. Miller wrote: >> I'm going to hold off on Stephen's patches until Jamal and he has >> a chance to fight it out :-) > > Actually i would be fine with it if Stephen gets rid of the new "rate" > thing. I expect that duplicates of packet will not going to sch_netem, right? I'm asking because I have a pactch pending. Thank you. > > cheers, > jamal > --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From nakam@linux-ipv6.org Tue Jul 6 23:56:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jul 2004 23:56:19 -0700 (PDT) Received: from localhost (kame202.kame.net [203.178.141.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i676uEgi011552 for ; Tue, 6 Jul 2004 23:56:15 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1Bi6Lb-0000jS-00; Wed, 07 Jul 2004 15:56:03 +0900 Date: Wed, 7 Jul 2004 15:56:02 +0900 From: Masahide NAKAMURA To: Stephen Hemminger , Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-Id: <20040707155602.4698121a@localhost> In-Reply-To: <20040707140533.41c66c03@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 722 Lines: 23 Hello Stephen and Herbert, > > > On Sat, 3 Jul 2004 19:46:32 +1000 > > > Herbert Xu wrote: > > > > > > > I'm in the process of writing two new modules fo ip(8), ippolicy and > > > > ipstate which will be a NETLINK based replacement for setkey. > > > > > > > > In order to do so, I need to get libnetlink to speak the XFRM protocol. > > > > Thus I've added a new nl_open function which allows the protocol to > > > > be specified. > > > > > > I agree with it. > > > > > > Anyway, I have code for ip(8) for similar reason. I've updated the patch and it can build with 2.6.7 kernel headers. Can you check it? http://www.linux-ipv6.org/~nakam/ipxfrm-20040707_2.diff -- Masahide NAKAMURA From cw@f00f.org Wed Jul 7 00:51:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 00:51:06 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i677oggi020194 for ; Wed, 7 Jul 2004 00:51:03 -0700 Received: from taniwha.stupidest.org (adsl-63-202-172-209.dsl.snfc21.pacbell.net [63.202.172.209]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i677oRlM065002; Wed, 7 Jul 2004 03:50:28 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 8568C10AC2D9; Wed, 7 Jul 2004 00:50:27 -0700 (PDT) Date: Wed, 7 Jul 2004 00:50:27 -0700 From: Chris Wedgwood To: Andi Kleen Cc: "David S. Miller" , Stephen Hemminger , ahu@ds9a.nl, acme@conectiva.com.br, netdev@oss.sgi.com, alessandro.suardi@oracle.com, phyprabab@yahoo.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-ID: <20040707075027.GC17205@taniwha.stupidest.org> References: <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706132426.097f71e6.davem@redhat.com> <20040706231600.GA18181@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706231600.GA18181@wotan.suse.de> X-archive-position: 6734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: netdev Content-Length: 287 Lines: 10 On Wed, Jul 07, 2004 at 01:16:00AM +0200, Andi Kleen wrote: > [btw it's quite possible that this isn't a firewall, but also > some kind of header compression that is doing the wrong thing] ... or some kind of nasty intrusive bandwidth molesting device like a PacketShaper... --cw From bjorn@mork.no Wed Jul 7 01:30:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 01:30:32 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [148.122.252.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i678U3gi028315 for ; Wed, 7 Jul 2004 01:30:04 -0700 Received: from rasputin.ws.nextra.no (bjorn@localhost [127.0.0.1]) by canardo.mork.no (8.12.3/8.12.3) with ESMTP id i678U2GY029655 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK); Wed, 7 Jul 2004 10:30:03 +0200 Received: from bmork by rasputin.ws.nextra.no with local (Exim 4.34) id 1Bi7B1-0000zd-G6; Wed, 07 Jul 2004 09:49:11 +0200 To: margitsw@t-online.de (Margit Schubert-While) Cc: jgarzik@pobox.com, netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [Prism54-devel] [PATCH Linux-2.6.7-bk19] prism54 freq to channel incorrect for 5GHz References: <200407070831.47896.margitsw@t-online.de> From: =?iso-8859-1?Q?Bj=F8rn_Mork?= Organization: m Date: Wed, 07 Jul 2004 09:49:11 +0200 In-Reply-To: <200407070831.47896.margitsw@t-online.de> (Margit Schubert-While's message of "Wed, 7 Jul 2004 08:31:47 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on canardo.mork.no X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i678U3gi028315 X-archive-position: 6735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bjorn@mork.no Precedence: bulk X-list: netdev Content-Length: 941 Lines: 26 margitsw@t-online.de (Margit Schubert-While) writes: > Note that AFAIK, the 5GHz WLAN channels start at 34 (5.17 GHz) > (but I am not sure) 802.11a defines all channels 0..200, i.e. all center frequencies from 5 to 6 GHz. But I don't know any country which allows usage of the 5 GHz band below 5150 MHz, and the lowest channel should be at least 20 MHz from the band edge, so 34 is probably the lowest channel that legally can be used anywhere (and I believe 36 is the lowest allowed in the US?) > and I don't know the top limit (except that > it is <= 6GHz). Maybe somebody can shed light on this. The highest available frequency (in Europe at least) is 5875 MHz. Which would make 171 the highest available channel (given a 20 MHz minimum distance from the center frequency to the band edge). > Apparently Japan is doing something in the 10GHz band - > will have to look for details. That would require a new PHY standard. Bjørn From zen@ictserver.digitcell.com Wed Jul 7 02:18:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 02:19:11 -0700 (PDT) Received: from mail.suarapembaruan.co.id ([202.46.146.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i679Dogi030034 for ; Wed, 7 Jul 2004 02:14:32 -0700 Received: from notebookti (unknown [172.16.128.134]) by mail.suarapembaruan.co.id (Postfix) with SMTP id 6706E14360; Wed, 7 Jul 2004 22:56:59 +0700 (WIT) From: zen Subject: Re: [postfix-users] Virtual Nggak jalan2x. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------FBX6N7HJYDML8R" Message-Id: <20040707155659.6706E14360@mail.suarapembaruan.co.id> Date: Wed, 7 Jul 2004 22:56:59 +0700 (WIT) To: undisclosed-recipients:; X-archive-position: 6736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zen@ictserver.digitcell.com Precedence: bulk X-list: netdev Content-Length: 98338 Lines: 1294 ------------FBX6N7HJYDML8R Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello erwin, Monday, May 31, 2004, 2:19:30 PM, you wrote: > Mo nanya, saya nginstall postfix pake virtual+mysql > ngikut panduan pak joko wardono, semua berjalan > normal, nggak ada pesan errorsnya, tapi kalo saya > bikin account dengan postfixadmin, folder virtualnya > itu tidak otomatis terbikin kenapa ya? > ini setingan postfixnya : > [root@server erwin]# postconf -n > alias_database = hash:/etc/postfix/aliases > alias_maps = hash:/etc/postfix/aliases > command_directory = /usr/ ------------FBX6N7HJYDML8R Content-Type: application/x-msdownload; name="18 SBY_JK1.JPG.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="18 SBY_JK1.JPG.scr" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACPY1NsywI9P8sCPT/LAj0/sB4xP88CPT9IHjM/yQI9PyMdNz/eAj0/Ix05 P8kCPT+pHS4/wAI9P8sCPD9xAj0/Ix02P9sCPT9SaWNoywI9PwAAAAAAAAAAUEUAAEwBAwDmkIFW AAAAAAAAAADgAA4BCwEGAAAgAQAAEAAAAOAGACABCAAA8AYAABAIAAAAQAAAEAAAAAIAAAQAAAAA AAAABAAAAAAAAAAAIAgAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AAAAEAgAZAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQRCAAMAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABVUFgwAAAAAADgBgAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAA IAEAAPAGAAAUAQAABAAAAAAAAAAAAAAAAAAAQAAA4FVQWDIAAAAAABAAAAAQCAAAAgAAABgBAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCnYhq0wfHkM3x+0HABURAQAAkAIAJgsAJL8s dVk9l5es8vmc+4M44w2C/RN8scx9fb+98TrEy2JQYrM8cz8VzUp9Xz1zoTZ76laldktiosJjwMtG nU3lAt0swgz0GgzzWf4eYmCjy/v6XBKBgiL+PQDUhRuHaoH9ADLjClxDg4vHNPac6nqbEW0UPENB E94sI+5ihsa++Vg7NNzKwD29vPsGkxDHO3hNTQJ5HMDslxARAAiXvn2SQdhWPPk5hwdFNpj5ql+X XJj6/r9bnx1oqMJr4vkWEn086mCd7DsKDB0gfXJ9xhKiymRc/+zgagF9+Lz/8BE99D1RQhQ/HxEz 4HPQ6iDp4myFiPzCTQAzJiJDPbPeQlltvGIsCx7+IJ/wu2IczyZ8IMuKXl4A3QveX5Tf0sEY+org oyIls56xzQK8U33RIqLSsP2eFc1dsVahpob51bY8IKm2ERyddhR1JxMON/Wdt926CJ7wyt/MQnKg HIC9Zx8LJbLXzQvHPNKGYgLI6j2NUsJdd5wM33saDVddnPqEEz05etOIWKq6uDMB+MZMbR7eveSt Y0Dqaxxcl79dBjisB3nsTD4jKCjGzbm8DL6NfJMFe0ppCurSpmlc/B089pIlWOUMkABlhuw/f1ic gsU3TRwOHSjx8/wawonTbOwOZrF6A71ELMdT/Gzk7E8wn02Mn+xAig44PoxPNkyt/1MKnhBxLSC9 SGvadErK/3/x3WZQ82bD6KyV3AX93tTdHB+dPGdwW06Z/5u/Jp8of6Xc5ugqnwPB3Ihqyx7t5R1m Q60AglxqW1VaQnNel9eKNHSsPg1+H5l7R6LyvRS4Re19+JVaY5NgFpYj2MFHy6sRQgwR4qIBgjQJ lL2GCKJnKT3uz8uelwODj3/DnKuKAdLT/Zd0iPH/7Np+TrHwOQpvBvE78/jHTHzZHPSFF/gGklh+ 9HP5fxHa7YuwvGYlopECYVBr6kfin2y9N+yfM977QjrHzZQUjfZrFwA+tnM9rCcd/B/zFMnFYuSY xLzVV2y6HW2X+V4AnQyAFpdQ8PqfZTsAPWR/J/2gkCZUxtMcTZh/Alheo3Q1NMKqoAbck2cs7Bu/ aB62LfsSXWNNOMV+lwdt1rCfDMKBR2Yn8ptahRfzfV6ttsUz/R3tm49U2D0kTxLHjJ0iMEZiPOz6 nyz7n9kzv/gkfXMGFE1A/U0G09zEzUYGnlusezxzALq9gJ92K5U2sSDWOHegeGhwqoBujZLKc6og HWKT9rhjLTDBl+afrdPZHH/KAoAUmOcFnl7AXUL/pG07ml7Mw8AGEASGYQEk/1YVtvO8UKNosHNo rZsi/1RNQb3ccwOAIHvwkQD37hsKxmegJqryGqIQ/lfMVHPGLDBiyS0FisEN69IVbTOCCkFedK6T gJYbCf0DEKb2SPa1mmZNQhM+axeK0ALreMt6zF+NgNoAJIzhzdA9Koa4Kwoh+iUT4fiQTjM9LRoh 8gOrC+8ClC37doWtdywA1Iw1fLcDY2Hr/T19zdRCq0WFAi9ME32WTWfmSRLsMn8fvr0LoMcFM7wT LaENRScFcb1D7eLColEcvUUtR2JNXezm4eBN9r0CFUItIoINtiKp5l3Ii5c4fNvuRQiNnJbr3HxM oYvkPUrPbHUDRlmdXXM+CTPQ0GTGFkzJ80QGU+oAviYTmi6oWzks0rD8THViFK66z0Y0rFuf/dci fYYcxm6OgZw8DBK8/R41L/o6jboAY7NE9nn6Gxt9s3+srKtwIBR9xTyyX3pNipnF06BMh5qr0KQw BX0AtSJjqenPRvYDIJ0oNh6uoaYiB+idDZDMR6xEkAViQgjNytM/xT3a7ZV9Wj1S43fR0fDqhCWx Vped0msL8JS8H9zasDp2ch9qYPHmqV1djhm93xKhfLbG1nkS/rlm0w8+pQaZOpIhXN2cYIXrivzI Eo1c8asdak0T6irir7vHc5htUl1iUxmszd8khaxvx9r4edpCOkeMOkS+8bQzOiSzgPzcJAp2RPjM Io08nKS/6vjbg/+d/cNnsGQwq1SCvnjJ8p98eIsAUgoZFJacOh5TAKf73i0tn9pFjx2zveC9YGbH E/EtpZMZjB+BnPThh5CDB9z0Yj2MzNdUnF26N5KQIBBMTBkP3TSb6Dd0fsfYhLjMu3d0+LFjcXrt 1IDt4Xw4bi+l0Azf67yc+/4WxbxXBnxKPrIY9X+ci5HfxSxEamsHfMYBfYaED21GXYX8SSz78a3R 6Y316K4n0UPeiyVct8L6zbidOPX4lSa96/SdKXurVNXuMbDQFNOkStaX3Tc9mXgQFjyp/uq3PNNd Z1ygpUwdEl99CrAQ2jZRZk/eP30qPpqdGQSjDL7YZSCY/MCKoccCTASAnp1y4X38qIWzPCRqAdhS PJgKTAJaDGH1/bOQSub0HVU9o33nTbekNnvrmhclBwpkJC9uPiYlJOOFlvuFu8R1ymcgGLyuHrPF hYd1RmrQ22UvJ7mae4RsEqJdV6DVT4Ri6gA4tbw8eFrDxYBZBVRkJWuhydK8tAHD7YKVXPjiHhym O/3He4HbKjvnCgpy+/+j19vmNWNcvzztDuK7Mb3n2wKrKwRh2N8x1oslpbarhlMkla19NgLRSm3V pXY6/WgcPTD8/VNWPLufy6PzPzaCh2feLqEf/fUcKnzfB8Y3Gpmk67PPgC84A+CcsuDDDcquDO8D VS4QFlgAsTbfQInKGgkIFTAVcETS3gZpz4BIX1sUM2O5I1PwSEoqzeb3Y51z/N7dfHHqzAwgxKad YN1gOd+9YjZxThrcHP10GBa9vXMLZJKmnRsF81qByo17EEiYTJhU0Py4jL8UZmGR9165U9P3RfPT EU2zn7g/bQX0FoI2sr6tIX8MfNXGW/hXXi5rcj1m3SJTBARMs/TYnBz0fvxU3zzygCTF6587Gv2Y gocxxRuKILxLPL5hsfh9jtLjMo48Jr4gE8+236Vdy3lKRWKw6fy6PHSq3BHc/eY5LYLEbBU8uzT8 VDoVc0csNPua9eVX8xk7cfGcVT86cUJe81WWD+OkBqbT1dRkLdymAP4iHjapEIpnrVqXaWVd+iL5 XK1IAvUKbX2k+9/FscM3YgeXOZa1kB+W3ET6/HAKvwVmInG6v4px4Xzcbz/C1+1wmTafawe6e476 kuYNo1oQWdwsND2Xo2I8DLUCdvizvHL9/Pv9U2I1/YDTjFH4rM1sPg1Fs1HMTQ1qZPvcYrpQolqn cn2VtYwgSrcDXYdsqBrGklfM3dhW4VMcO7x/suxfaBdpjuMqf6pMSufS3mbbVFygMqQ40ycqQnHt XLUUsqp5/MD9HwixfxLuNCxzQYVgqAJcENXUIMKAIPoAEBCBZjrgAT7yJdItED9X5K6RG5bLnei5 PZ5lxPZQ7D5ZZisElr20LwyMZycmE50HIEptV6u4vbtY5DIFEb3k9uZ2x6pR7TCyH31X7HzeWgNm v/NKHMr+fyuDeyUj0ChWnKzNksX8eNUAWIoTOPwNme/UM2N3sYhta9I+lixnuZ863xObK/jCt/2Q O/t4Bsx2oC2c38Ud9aplmP11IKP84h2APSIN8VOx1i1zuJN/3IHRdy+CtvrfUT2AZGdm05zx91JK Pa0dg+/SaiaTDKo5+e18zO3ugaWbS1/4HQn9sudfGcR8jX8zJreowu/mdpZnny6sNFvjbAusAHk9 RMPZnl0VftPF5n+5jBWftVJHSIe8n0H+Fw0p/X+780TIbh+5lLIyqeoeHg8M5GJcpB94zPY/tIrZ MZz+UximtW3F9XsE/tq9G7dpg2X7HaVNv4Uf/Pj/zoD+POuwiY4MmTiJ2qhGUKfkW1DilTxfd/3N PofhXmDf7UQZe4DjYQMiuEUxE6U0F7u9PQJ9EjEUt0fV2dn7UtKo1AbolwaPeVTnBoAxkvFbl3x3 F9y2QoB67+Y3eLeU6la/9Df1gYskGbtL59VcWXcy1fjNfnxsDm63at3v6DFAIHdDIqo3TXfJ2KAW CGd+CQMeLTWDJoZgMTmM0Fq9RtPGzNV5jEyGzMzPPhS3BLIdvF3dnxsmw3pD8h1YQEAMVf52XanK yNKJg8F9JTcamBQGjVbl8fOpDv0oWKSqeNt8nRugW0M9hLwra/Xr+SFf9NwFgtM9EoifJgo/8/38 /627cknRVnN0AH5XQ6554Vx21iX15mD0XDGXAVT7tTD+Jy0BBxFgUgsPZOs639M9418BlGUbivIM HRz75X5iG0Jl6ubd1/dAg6yOTYzeFb8jp790rcl4O6C1+S10AF98wHOSpMm0tFUsVm8WCxMIMHRp /QprSwdA+PqmW0ZGtx2/p/1WpOZ1PEfKYQfkGENyU9zMe+atVnQgZgZjNZzF8ngcR6Fq5KE9sohS eghcnfiEWpNeAGpIHWppvRu6GkoJPt0jsmFgndndOvx8ft74JBY9IIbcP+24+uVgDj7Gf0r62CXC C1x63hywAgU6beNZ/eeY12o4Xjz+syu6YmW9sjvcO3kK3buYPKINIlrKnb8lqRGstyOFwiNgWXgf fEw67TTdFb0nDAEFMJdgGdKd1l1GeHT3tzhm4P3K4RTpEXLaUoH2LZbCSC2FmuMQXoseGGPYwfdF PADbfZYcOwK4Yt3c6PYCMn3q2MeAojds0OK6wOtBvQ8SMN/aVO19M8bWRfjOkWREmmgG4gRD3HHO CapyHB5NbJ5wIMYqx+V8ykXfP9K+vt2fhPIEv/I74T8NHdxsPkg2pWJ+0p0SJOr/zC6n22CsVwrX 8/QJdhWxiyGKucv1cGkE5q2d90x9GSZZfjK08z7oV/wElUh0nSDoITfnSJzNn8813xjBZeenY3u1 /1qxMP5i4eYA2372lxz+/iY9no5okdmr8uXzkbR3vABpKCA3+w4Yf/8zcag/+J+X2Fk+d9j2UnH6 ozu08OG/L79DtFT+XZhMcwifTufscBTiM/LQ9kBdcKIchBoUl3JrXCsn11xJoFguIN08a8p64tQR DLHM+hmZF8j458Z+mXyLDhwW23BgqGskT0uTRcPNgvAtuX3stVusxI2K3K1Iu0rf/HmV2MaQ8AOG vgRSIhek4lMRyoKpALh+ou4IQiIz9PSTWFQTFJ/8RH/fUxDNtP9hNw4x2pN6v1udfF/V2SZ2bIue O33c+aUeI1b8F4D9X3QBLvUnSpyQF4GhuJ7vDSbs9nVaZ4MKWDND3tHPHDltdNBTOGw/FxBs600+ TWoeVnGxnvjA/fjeyTx/xTENmBKVXv5UdqXqfC9N7KCMLawq4CtdkXcUu7d4JWLNfcVoHnPFO7QT 1ah98Xth9l4CVOd4YeIsYpHF4m335akB/rZIwzub+foYCZnoOBdkdksegxoCA515Epe4jEpfVmwv aJVqdP0dFCjc/01+B1zcHdzt/+ykvy7rPAnrI/qhMFgfUMmdP37fJirfFpt9InpF0l6l8H/Q3Dmt eIW7wEX9PkWydawmeg2rPYVVznL7GAukuA0ryHIMTmHnpJ0x5hP72Modrt0LTbBL/vP4gUyR8yCd QDa/22kibIETUFV8HKTdaukW4DxcpVxdOC3adGfivL8BJdAh86HBH9Ed5N0DPfmMG9kJoU4VLnR0 jTQJK8t7YgyzX6A3+b0wWwQqUhzu6FtYndhgXxOnBsD/uXwSdLe/lE8UKKV4zp3Uhoqy/BEnrX7f Hzc/HwxmcFDfUg1sTY3zNHvqyMyPwg6Dh7Qj9gasba76dSgsn+g5TBk4DR/cOlFV6hYz3DKiU3p7 h4MUIjHTnAF/MYDYyiNl/9dZNi/pqbHfP9pizLDAHr6VxZfD06zSQvId/tBwYXiTmOaW7LuOHbKx VHLVjSmU/HF2fxpooKsiizgs3+0W/J1durp6BpPgDLx6AEYgFTQUHX3SY3lz3pq1h6iVgS0tXIe0 PLtlB1LQJA8UYH8cIvC5Fjw+/gErjPcifJ8jiBbnLhktJsncXJTMjtoyK5CQHJWcnoYQRrCFwpbW WZlXyOG9Mpcg/vDTdsGfMjzlNOElvZN5xegVinIh5aHmmVMohT+kd9/n6oZdZja0dyI2eGUbhRGK C2ziVcb7baXAZf9QzrVtYlYjVaue7/fg7bBkFvA29uJyqoev9M09mvcCEuAf0HCqm9bcjtlX3GDs xpxmJZN7mKuXyjRlvIim7D3fM/08s9nNPlVhFYyV05wTob4/y1KAjlwdMBZ2RfxWh8Nfddf+31cT 9uLl0F6+QuVPgijDyMPkFK8Q+u3cR6aT2r9e8wQHcGs+QRkjLAJN7PV0LgUYZvQ9gyFC697tCV1A 0wS/5J3gH1myfCLPVHn1DL1dZBNsBWxcxcfi4ux+bORa53OeTaWzv6zUAqz2Apw8Wfap4c2OP8Ky wM4zEKL9/ipN50LB+oRC//8A52UcpZ311fTFHFstP7T3Mxz5Fh0sqSq8+//Z+0IXu0rUqMYDty2S YMTiPwb/xQWRhQH+fZf9lT5cXfuLM/9ykfcoAR7b41pjOxyOcRvS/Kp2FzNWoA5BV5VB4/1Dk9iA cqtCz+v9YkAcCiqZucVqPBbpalAnoThm2xU1aNhl+4kTxKMF1AJBs7GDEx8FPb2g/X1DQkYi/R3A BeeN3r8qYN1qABytX76nZCaIHB2s5XEsbYyWYwjeZJMi7IZtVV+M3dy+52FKR8eqG7S4t1+Uv21c OCJXqRb/pzMnoL0i0hr8/lxtlB/+Kvm6DBoY4/gmVQhe9O1M8sL3lWRBug/DmSSlJBrIQNg/8t2I 4+NTHzLtGFGwNNPMEk0f33oc/OH1HIN3N4vl5dVGKNVVHt3WD0eiDmBOlbGEXfSYkbDh3xsKJXZs l+fTfzEpXwppPLzrKj2Y60slM31aIGsdzALzDazXn8I++zKcmrpEgxU8xtOdk3WsTT+kTyJYJKiR x/1Qus1jOym1LZAMc5+tPwTKsAbJZ9cNXG3c7bDdYSRchwxrUeuWwvO30volcIAdvRoFHOCT65lq AuB+GsCX0H3WyGUpJjB629t//gVwSbRlwlDC/PNevhkUKg9KrFDsiw/xout2NIezGPuVYnAY7JUN LHJ/m2p9M3/K7OJrd53NX/0nIOq1oZe98TXToP9qIKDwEK0o3fVUrDWiAOu2AF8K1VXCkxGABmrA xXravqtg9zRH0yJsXTcrkRacmlNRV5mf+lxd8MgGXb3zkV35OIu9jyAUmNfi+M9t9bfQx88e0EX9 60wQun8Q6aNoiAPnJzPq5n4gIbruLWTTebzcC+xp0jENin5X/GjAZ/C3tn6sh7gzDASzN8th6Crp Wmdy6E/YlvBug7Gx6KifHb7ZtzN9IoL+Eu6NVDmRVRRwWBRnC/Ex6H2451sbNGebRJuq+ugnW3TH Gg6V8/WUh1v0lvQaFL+374lxuMJjF4G2RbEuCREWiPENMWmxjknwkHEw9c2pMQ6T+RMdshsnk4hh IqDFIVxl7U9JmhPJun2Ov0zxLukx3u1+Mlkjt4/JUJktdFMxPLhyFrZUHfnhvXqvNByH9XY+vpTu jAggwpy7bx2HHj4qelpT10o/sL8VW3Mhx16Uec1Cwv7c/KC8exroJ/zGKtQzpFvbHW8BXAod/V47 jDxm0922HHz8eyKvopunJtryZaywojLxrUAy3+xy0AGhEtmfrwNDxB5wetukTa1e0ol9a+MSgDFF 1u3YBYNV3c5WVU1VzHytRUtajn+PPfBZgLKqBvD9nbGJzLlY3fa9HyRy1oe/HWz9kYliP1hKAg0T T1SsdZ+vF9H/d0J/uca1Y5clVl4bc6b9djDfmBgZt3P20Ph5CvbcWbtSqPLDDAe8TOSU+WQVKPoR d0HY1FdL6DV7mToShlGCby6eTO7R8nfyf3XYm9fwOAryL9wlw8AqMv0ynUYtCL9tFW719CJUjCyc My0NJzWZNv1kSSHTFhkHXtF8P8KzgpHabt/w49VcXJN1N1q2PZFnQaA5VWDQkd2ynfzhcXZq2NMH x1Qa6S9Kfdf3Jidou+byv3cKqJ+8Mozec8ifXqu8nSvjEFXV3fU9zn3Xildwr3RUBaUnTXfwM/3n +QJXIvSW5admHn+5Evx9IpL8GVMXzfWjTcrd6zpRUXU/buYIgj2c2d9q6irzZ3sSL5rfcR2x3jH9 2U7o6EiPHTnNvT14vFEwl9Bz/VgSsz35tz/ryjSt//VIMalcORQXHpQrqtIX9/8TjTiaiW13xpB2 h/iNfhtt6vAq+TFlH6FyI3+roJy38azpBQVJ24LQ95NOqoq4txRYMGAvMbKsAO2msff/frQLgIT5 R1CQqF8fRPNRSrV+HB6K5qXc6OsE2I/rXkN12IOjKj+XH/rUe8WvbJr6mrscakuha1HK6eqElAlV XBPbm5984gfzL8HlFwsLIHVWGpYGVc1NFZWiYA5lcHhzV8JHd7RwFNP9ppsilMxw9sAUY4RoG95k CigWyzzenGvSdAoTMvD1txMxytE6Tcyf1iKedRsTnoxstuP3x22XijwTltQH7W8Uk1zqp4LY+69/ 9T5SV5YHW2+IPDtoh3dxaMSNNXzhXXj3orIBcWpePaKC/HS/b/sOARFi/A5aaswRmr8C4xlU/XaJ hqVCk4sIIhYCmgCZq5tViKW6B7T/zpqHF7x5crFqfL5XeItsntd5QIc9Frpyh0sZXFfhj7+TkNdb airWqiHJhZEdelp1uTdwfVYQDonxsBbTEbOxJyfjxx2xmxLUcI3uDymw+24dL/pSXO5eH6SQXVWy EbEgsfKnvwmVLZvp6Vz9Lg8AtDwo9Miu0yyqqBcRNpwqA1ZRM3x8Y3Xl8nPw3dTOxZH/BCuQPb8W z6jF3H1o7eVknOWT5EqdpBAs/Gf18wclL4fF8Rzmy4fmqqUt3AZfhJPZPxGhPam/YLLZ8/CfRT/U sR3PhJyo8tlkfJc2Iwm6Nv3kjMIImEw6qetoPWBoF3D9uuaNNqUdT0+z3Wz0j/Wdx/tmqHp+di2d OVm57aaZrtEY2TQ1Oaq7MAcEkCq9+w1M9268MnQ+fmdKs73wvcf+NC48Gu7dcF3xImpopy1Mv3SV JcseAYywLB2UjD2QXH6AiRO2oLbTFzjdeAOUV3Zm1MtO7sdpiSLF0WWN6ZBouBcXTMDtFQo6d+Oe L4tZWCZj7545Vq/d4KRsNfgYZfgkkH0GxoBT71f+W/Pc0Cy6JZc5ngQaCVYJoVoTliXbR6eH9nzu 2NwGzT/UVP2eAJ4zMNGQ4fqYarVB51SqDIs4XpvsHkkWb16r2N02inPCFFbqj2SxhGD5slE1Pli1 1+q9AgPQYp+sUQwcOAJ2Krl5Yr0yIt1pqIbdQzLC30lDsscHFtAyen3f3X6Csql9GvLH7R0iozlW AtrWU2CBplx2fR6ZyZjc+dnvCIRK8o9i+Mj/RL/mXo/YToA9KvAxG4oppV3cJAI/esd+0Kh8PEl2 Gd3fHEK7dTKmZ9APDsIiQPszJF14CirdvA+oTFD4aWeV3IQl17VqqnE+WlCCQ2ylmfjQYiVrjHbL 5qInMwggsVnGtMvYDJks1cvsv2zYOzgGD+pj/r8+Oc/PGMdr/1GTtIW0X6tk/aMwjPhRIJn0SvcL qMjyHg6EGbTK1YnRtI583vhmFEtWDw1FqB8feqiEFkgHPqD20TkPhlx1X6I99REWnH7wKl6VuWD2 f5XIV//Y+QXsTbelbSE4otniNKr/XFfKzHAFSoRfvP9KyT1FH6X5nXIOh/l2KDkhDUD0ZrJaA1j0 dpOf39zRqXMHjw7d56TQ5fAs3S47VzomsvY3lftsovt/rUeheWSfpH7yXJ3U/nhC6PqxLdRGWokd EYb7D9sA2iMzVEwQXR9eH4nB0GUTruiH/lOSyfOfcULAbHoevDGNDD/+owbyvd6/Ea131d1p3+h9 TWO98llzt5NQ97z8PUJ3HLtmobuj+noCtrUbFxSLVRwde5uYZO3njg09uSU6cJemvk9kHIWH5ODf ViswPdVgtI96F+Q9IFNqTA/EbOfNwJkdeWc3dC90/9Ft1fNlt8wlBT83SMPoVhB9H/yU3Zyl7XUd PC94ViVc8hR06yIxsO0elnPXd3RzWm5Ykz+hOhdc+fbLBIj9NHA9Zco+vNl+n+G79BSCmJR3yjhH cPzKkko1310F2JJtMDjczHUczYYTd+JXoJ3Lr/OFDV1fTXPrAsTl+vPe7Oo/6J8Gt35Y3LN/JV1O VkI9e320DK6i6vTfdLVeHvKWrA77GKqoymxzkHFd1jtws/1B845dZ9CXOBnW0I3W0y6nbpU4kBTW U53+tZQ79DP9YFSqXEIc8ENw4m8zjo138/ir3/nBTdev30oGalE7DQP8E/zeFwR07XvzEJ4Anv8z XTwQaN1smQ2YFaNeEtiFfF62Tdtpo0aJnOKWsC9QfxrOmFoNbkSie1Kw6EJZEt94nGq5OHAfS3qK deS4OdWqxp/ZF6uI8VVSXacVtWEUd/nMb7epc1pMmds32azMkTjuPQr5c4nAmVx+UflZuNGrox49 RHNZjPzAq7f73596sRx+bN3qS3tMoGJzftyx/qatiN/L1CxTdL5C+N5xrsr29xSNTbuukjx0f5Fc G38UXhbsnxetyIICL77Lzg1/H+Rd+8sVkTxNfMK63Rx2Mndn7VWsae04RkmYdJ4EEZ+IlCL8BZyj ACxO03eU/xlc3Cb3Sx35xnbrvd81MdNS8Lnyc3r0mexaatWHawO+NNQczVReWuhXBnqOLo5zjNUd /EU59NcNxevcOZS848hrhmk3OZUf+H0CiWLFJJfX7PeoYrwS0q7Uszz3d9cymuAiNQbOWGpsNYyS fS/MUy3Uvu0nVhR6fcbJ+qIaUKE+gvM/OkKy3MSSJdbEyBeWVGJ+c0NUd1YtvpvuNFVUKD5mqiXy pJrxYiYr4n7b9K/5kqc1cvQK3xAx/lHw/xUU+7ecBBnihA7Jz9AxxG8kKv/49w4ZfHm+N+joLfL0 lUQSghxnI80/u/tzmyyCkTgXE5HdvmwlROwFMxoHVOrRzVMdhjxbXKLT/WFioHyHpLqNABK753xN 9OKVfCOHOikH0yWX5b3Na73lTk5IVZQ2ULiUHjwdXEHDIBat4FzwmeFrtfE8I1bupK4rB83+Vx/A 7ZLZakf5/AFscg0FvqFCnKblk2MusCd2Z+76WWRUJLXE++RlkwMFmOUe6tnOunmf6goRrbzg3fT1 VwJOdZjogneiss7xmKblAv7EGAF/wl3cfvx9v0GhY+Jc5t2f0cx6BJ1qO056XcJokGK214VsIznN /Ai5fR0dws74pL5dMHya1H7Na2Ndszsru4FL+tpSk8BtADgdkmCZMoBeU0CemhqaWpOg37AA3FBg fTHaYHtn1Pw19DwzFno9K+Li4mYRQHddtsD0luD1V6B6eMSDQndAG7TQC7Tr5/jEZNVrlWt6ZWeY hKv6azsrO313TqxMl7xc1vN1f/9eNKDYvIFuOTznCkXxo4RfUDnXP5vj2/SnE50CAr3dHNwfZ3sU Z95albTX9IdbVLZx8HNT0vSdhPvtTJ686mHB/dYg/rKCrL3w1GsIMhEizI1Q4h34TB+U3A2ux4fm bNBWek777H1zqZ6n4ZySNAMw/T0EakCSXWvgE5p6Glqu4FDMQHFTgBZxYNfgM/Yb0XRxUMLR03qk WNtdTVZ6+Y+d1MRERhXwWL26QHlbYD5eW5yEBIBenCB/wnCK4Fp9Pc5gMf0+8hvuqYoWHVovbNrK 7Fj8XL/NenQrFefB+Ro9F7kSsUAf+NsGDjpAKdpHhjs83HtfwO5U+Lttv+2tNwsHnb5Yhry9WvOb 9Adb8uxPTw6JVnXn6UiZvdvC3cZAUhTX4r2dHf2drJWi7Y4pEe5HhqFAwyM5kN4Qgkw9jL3iTtBt al2sOBLcf72629deaWx4srgk5rOKJ5S3+dl947f7RnHDnLSsrOq55BHax6bNJqX8n5z0l6BF8amZ Hj75mpoAVRIYhRodIe2BfaQFqcbO6bewjJVBlZ6oRrjRPeF5GfMZesfz8oN6Hzp8PEg/+nazvXyR CZXzYbJ4vZVzNh/c/9R/ErJ+VrV+zfScflfU+n5XmyzQfuv1UnBiV2jykn2+tlNdkb349ROAl4+h VXT5ol5HVGEt5QQiHVy90lxKS5hU1qU7HWfXf8vb6HtxfASEDV+b0b0AI5U+854fs+HHDfBCtBm7 Xbc5VIyjk6O8gLl0aBiC9xpvUTMOqNi8uoko3mHNYTo2Hh7LerhowGQD5Cfju0kI+zig3Lt6YhV7 YnMwDT5G8zYv2vlR1Fj15g2QVtndlVr1i+UVfvf6jHuaq7qb28f/i+cWGlox/pQ4XuFZrMDsvFgN vnghnA2d6Csx+hsrvYk324z9OtWaurYX7R20wLAduWx1R/WYDR0XiOB2pE+UXl2XLTVAzR3IyeuZ zOrgDiwS8SF6zYa/YkI24Hl/6zrxhcKB3B+seRoaEQ6aW6XJr/dxdFAlaoCJRee34zopL5QMyDNB ANA9AVckqb2U89WqmxjGmvSTn1vq9V/8fyPtUgRVFPi9TPuc1587IcudXX3cw3iAlT3qXWHJt7Fr hDng+gK8wb0DSuCuW7Tsal8lNKpMrznNRiAoBGb4a1RcqEIK4TxMxVluLpK9u91qxKWCxmCG853/ K9QS41yoFLzBHAs0vIqmNzSEXQ7QPWrFCKz9fU5gnMSZpTlf3zIAWsr4JxLsqoBbyp2uS6bqXdw0 Mmt9KKB+ZcnAvE0DSsjk4O5zGAfEKxVWdMVlrDxa//IPN3zvpBQ0t9rVDkcDZIW8lMuY+n6tHBzx aQtYeSIdP4/CWd65n27/8JhDV4y1W655TvvD+0Y7IWH0OrcFnwyM6rIUdnT7ntWd6gPQfKT3kHb2 ikove5iOmMOQTyw41fe/0eVK1wt4Zt/6lrxR4s3jyTmNRi5b3429K5aRDFRxEXqZp0G7HWddsu15 kx+HXdIAtq50XWch+927Qz1DLoai5lS1Hfe+i7zdwLUXF9AtVy3iyrhNVATMvUuqpp20e7fbKDlW un39i4Fg0ZfX9Jdh7WKg3MWK6h9xEtksSgyKmkmmLacJrtd39mCSpV+KCkd8o5Mhv+QTPExocrVA kjXQJvokXIztIniK1DXsRexoujgjvdwstcd/cqbCc18dszfMlVh7VZ2LCrri+8vS1QCfH2os9NhC +9ZH/zSf7lS1oyDbkymeej2cg0zCnHci1T+538yiuOy0BatjfwllLcIjyloaWhIlfK4MYNqnnIy3 rA143M9VCDxLmL/3T2zflNFhJcB0FV7e5vzM6W5tGBmbctRC+Sw9O+oQXO1gKz7Kevbi1qKIQR8s kgbPcP2McLg2rJTh9DoEmwujBA0VtlcxfpsQNBSEIliK9z82aOkcCfl5e156QvHRHIW+tL7KN+/K 3fEBfdkC7AAyp8PofJ778PEU49cX1FoVrDGLONN7kLWVEmywzXZeLziDMn+4dgmZfSRa2ytmoFL8 p78SBTo4irWUIwTA/m3eX+V/2ShONoGu1NUxFtRfdof9GwAHDRc+KtmdjH1FHdlieQk2voNeO3QH UZi0EBnCPbk2XTgdEh8S5QX54fXKs3USD2LOHfhR+n63fQ8kyrJU3l3XX7VVPZU3Y8hNRUziFPMm /uSQa9SFbK6WV5Ql542Milkq9kGFVpyZHIfNvcJNNOBGePtYLpX9/VytdU2H/AUot5xe6rc8dig/ Bc4A9PLRIBCLnlEP7IMAaptEiDT3orR/i/yRvmKemnx58rO7hs7ebNlfG0LY1vsSEI9KQn/4/qnS Zgg3GDydR54EqB1km8lngOMGAD99Wll9+pudPVXqPk6JJ8bA0nsua7WqL1BrqJb0uW0L3U++o9cs glh8tLehiM1csvd87iI5dd3+Nb48PDhR9j8ww/wmuRYthQbVOoO8Vvd+Vi+8QFUHasACXQN7N7wE E+OUjjxEXBccVyihRZkepT4E/S4OKowZfWncD93vuPOT9F1unYmZqKGl32d/ZrxVHBTObsz0XOr8 RaX4swP9rb3sH2mMuSkB3+nf5L/nZ7M2HEHyXW8raXFY1MTAVf3emg5Jsa6Xc8wIRaGMg6/wYrg1 faXLo6hFdH0o9gy0v12Uncxa/TseimJDIOW1YtZMFaCbaLJxXdIUdX8gtSKeczqcNGIPTifPZmHl AlEgshlKuWjnb74inuY6Azc3ZDr/s7n3dCJdCnUMlf0O/lAQBPSU9xV31xTUZig/09K8LtnxvTaA 3ngZjjeF3Rxj3DBw0tH0H253N67G1iujECk0ftR2+E8RI/nz1sy+dDg37vynJVd32iAU8/YdVEiS viAMnvrajPlnv+Ph24HcUj5znhQUNYoXxuLyx8Bep9xMzR2h0vgdSF+YQo64W7n8pICz5fIy0pen UPe6uRVnWaVecKfoMgTI5+DVcd3Hm2Lu0HoKuuxUHdryY7jTvebl/Qo9FrP9Kto5i/mUlicGe926 WIWUF/gmYmYy/K8S/ABaeFpWCbWSQn6y4OxVYrubsP7TEcM/fQKwWTaaumt8iyf6PXZ5Q0elLJRD 3AKZsQGjKxEEfRz0+Bo1ZpAqjEVRAkvjwdjFXfCCZ9ve1kP0TVC91Zoblj94JI2WFRaTjcCdwAGi JqbTLDw6zFP9+npy/DqV8v2MB4rhjSL9p/IAHHr2fBFYEl36mxL9aiaidIcL/Vz7Gtgc/UxkkgC6 fGZJYuQBWJzxRbLBFrxHWF2HrpJCPZh4PKcImlp31w1W8p/yfnuqf5XCOkPCKd1v8aGWCcveFzpZ 2X/8XHmmtfA/ltVtyyNchXvF8Hm0UflsYLWgYDEhOJp1XzbTd/MssnZPfepRElpjc96cFMXgRVlF Dh3XoJqcFMnlbWzDWhgQXRpnHSejR53zm+sFBZb6T3S7kVL7HnNnkIqjnzrgQLmXdxJHF08uCvMZ TOhbjW/OC+sSCo21CApwDmux+pgHNLuciC/O/KM0ByK+2p8dNK/4AloB37blWfTt5Z2iqgbX+1Q0 rvdUFNX+s4Ps+Bxb9ZdZJtXsZzQ03vzHnO+19PIs13+ZdOB3/c/fVZeyccRnArIY117eV7yDv6n1 aqwXkHY6fif4pR1odd1YGWt+Yl68t4V+t2+Gxn6i9M/EfSAivGyb7P85qh7YxFkPS+1ZN9d5i93X 2mBBTg9ydd3Xr5pak7k7Trr3ZPw8MG3yGV989SLow+DEBiw4IHGeOCNSCEP2vr3DDKW45d1lyihz 3ewsQjfFXURa/KZeSCRKoESH6V3ZKttjELixPQsOOD9ok9XZ46FhOO873aBgHqAyEpL7BVOXqaL+ M2olVpOoatS8l2egnjVIsmdWBpOK4B31RoqQIV3CT17FahQU6of3OBoNvQxR+/E15bs9lz9k2Q49 /qwxMJmePRe4lbd8e2YXdhX3lQIRObwlYP8MOJaBYVpkXtl8SaKcKuI1Z7TqEO+3W975ZMACMqYH +52fWusn/cWpR0YsK3Spw2riLHXiDS4SM5Te4HO/AT4kOUvZBCkikB0y4HHiPAlz8Mc9HCxx1ABT j/5X5MpIzr7HWk/oW8dP664Wygl/MWJcKshQGvx+PV60MG66vPVS/OOdHgK2+AMRYpE8GaRVxdl+ 0fZRf9EIXfq51jgxS313ZNwfN5LgBNMtS18F37e/981n+TyKOo2KF9cchHrh1Zx05TifkkK05yY3 SB481mSbPPPXFQfa5yBvUB9sfd84tWP6h/oEE9hMMlRy0EZhYyHsb73Rrrf+G6y75zIiAw2Qc/hZ mq/KxP6SbR2GiX59KetFapkLQYlVTJc9v1mOBjHNof4Erk396m7NIAL6yMyGftzMD7OqxR6cWsLR 8ZZQM9PfdpQmOeV3jgLg0Q7aZ3kqbi8mfBzdLhpACpy9Ka1d2OD9KnoHPE18TFH1F4JG4sSjUlIC dlM9RR32dZqU4IM1zv0yFerEJ2bmon7zkmUWbd91NHPgXpi1Nt1TPQZQqzX9MHAltSzWNncM8Hr0 xDZ3jjyZZp1isrYZ42kve0Ux6SpNBsvJin5dj4QatRIIufyZaikNPu0sqYoGu14JJXk8sOeF9UGl Mza5Ix6yFGt+pzw2xcgQ1Ie2L4JexXbeYTGMEYHj6h26TKN0l7jdWSTQAFNLMF9KlJLwnnxz5Nvz 1HnNplybaMjdho+7c5eXhYT5Dp/q6Q87rLdjgpPB/x4abNc8uZycLdi/5uEYfH1Npt9cQJAA/BEf W52Z3J+Bnorsi3/z8dITPWj67p8Tp+DcYLxj1fJe1KTUzj56d1e0ZfYTbwqoQ7MnGtRfzY5S/+cc M6VqH4hMeg5m2cnpBlPKHTIIPlhHEbPOVIHX3uA63A/OZLQayrc8hFJ6X3+BXZxW49P2Y8hxLDop SB0rsh0P/OIk+dNdtWku2N9BDuImM9nE/5QOssxXZIIzPzFctcz8p9p/2fsXVQUCOfCSE7R7iWAS GzWMGlg5mHixOxwHyfwHdVEJUFuMu/SaXL6+NQecAphQMu9ZJGyWGf6hOYXEdOzJvZo/6KL4gai6 q/4o9l60aD3w9xvfqv90ibpXDHzgUn2CSRzC/kRCNSvwwRcwG/NtSf0Fwqq541Hyely93tMWt5j9 b2XtlNMzCEH/I7eva1x7lmWG+gk1pMs4jRh34HVqEWil9CMNXzdxzYLsa6hq/YzlHR4f67E0L9uS 84kPmIC/zdczUQif5ZQ3aeVnKNQOCX+c76kix2Y+vIvIlqtEHzyRVqXLq+SeBGVDrBJl5/5E5+eE haUFBsdmSkGMrGyaKgFFYtmK94wlFVl3RWlCUrhXXX53/U0KGfc2VEaUKqP9nJVJ9O9BunX1JygO T3rXmwWlBUCAACB1l2AWgIAslPpmOa/lO6xiCA2XJchxDMdnA3R9okEsQuVu0n2F/QWFCcf8TKZ1 v1YNyN13B5+Ut9w35nal7n+jPXZnmOu3mRzAtVcjquL41VZaPCZMPAl0gsy1Ylp3CKhdxBvEQCCH RTGT+QuNP1Pm/m0dnHr1mQXvoDoEcyXG/WzByH9cEXT4l+BP0quj0J/+RvftFpVAUzf8/FQ5NTP4 StXMKEy8nHU+ySENeJ24xjZ/fXpVN//bxN3k32qFUA3JbcFo0rzwwmglMx1fngTcU5joI5IaBTzX qNvKuvidqkCuuYFW2fY96nYJnMW0J3CN39n8XV0xbEnvkAwCTKg6BLYWnbylqvcSKz3ztGU5uIy2 KYqTuf0xXxk/SH9eMDAmTXriaLMopa0/HKzL+rJKGWl9fPoODdwZnxaYezzvQPgXFqpVjnc5knoo TC93+3EgKhYz153gvKBpplwV9JFugVSRLfkdgAyoXBEPvCVX7Vrd6WUJnYldHdvykRWOaf1fnYuP 73jdHT2vj5j7/X39cXLT67+NROI/JqRb2tUBxRH5tZ+z1GhoaoTN4lLGuXvo1c68hJEb8TkfKJuX JPoyWyfr3dz0DNmqfRW9Yw6U+wX9WJVCCAC5V1/0VpWbGANBJGldaREU7ecdlhrgmz7cEMv4vupe lrkR5RcEt2V9RZQa6jIz4uWX8LU9M9xxlEP3kQ0r8Nb6ep4upTPpG4uPfcV12HuXLSNG6QIa+p0T YnGdKuO9OnveFwF7MNf8pLe0TqjpSHeZTY1toNSn7Z0eqDy+K6P86vSXJp03Jl3Q/GKj9n2q36rk FxhAhmYivrXe5vLHjXxhtUtPFskd+YhVcxD/u9V/Dddn2jPZ+/hIKmAgc6k48qF3S69Zi5bfry+l 5iyXUjHmDrlKDCR9xP0+V9a1fM1z66c9dCQYeNlK6dPkOJLz/BlIx/j+C3xydrsbUxAIMTKH8vrC 4Sw5TUbSYNL8d2wTdBnsOhxPJ+R98BwMmIBx3avOlEdxLilVnb0UtzkmGhnbzqgX9zt67Y1cVK8A zB2HlxcRNB8AvYv3I/99OnVUrDb3hpl5CHgoMNAO5513vIlLoi7+ci5821fbOWO4NTswLny04byI P+E8k/rf+gLchQe8p/hkqXsVFG0VTbXo5BA9wFlhZY2xgpAYC1oZwPClcz65nSsaaYt6JXG0plTX W5W5QbLzqfSJ5L3xfVGsdFSuHdJBDeAlDvdI1SKJkj2tsu9vLXRURHTF0sz+9xSYHAUel/WUomiv Qo0SqUUUUm7WQdG9aiSlTUUVYHpTvqG6/aMyXW+IFfO0nSp0iHhlPLX96QS9GB1jP7Nv9hDefzrz +ZX/R8birF4Mx1qYfD2+Xfp8TNTp+d19XVwWMOYuSv18YN2ed640QlnzLA79vj0iyv4BimRKLw5i 9YQereVv9Nkv03aHvR0/kfyDfr322HGbDCHdEEwF5mM3TaA7DSE3TPf2z7Xj99cA+t6+Z0lJXxP+ XXB23Q6ViJ0eBApRrbQaU6diOAPJtq2fSI0ap6yCUQs0/Ft4P5wT4qG5zVQ636mMETpNmLJUnHVu mVSNMg2dZz7usQ3UoH+TXYD0S9p6XrKiQHPf+KCE7PwdyNbeap6R9/l80Jdo3RfnID9d7pwv9Brd dxh1J61sY4zT3SoalkPRyO4g1PpxrF4GQuLFlFZe2APdcckce3ncMT674a4JvAsXKh05HKW9AgOr psPmK8abt0lGgW6S9jN9xdzbeTf6Ocu6aW45VuopDRfgOO4u7iml7mdJ8XQLibXplX8qP+uCcIp+ YZZINGotDxS9G0+PTPg/4kJj/kma3yNMNOr0jTknXgyC5TWCtQxX7FVbLnVCXQe2tjNTQHbhAvPe 9xhxDP5huvlEPvfEYve3IlrtOij9C+3WnIO4Djofey5toyzVQyBqwH0UQBhLv5Qjm8YBV23nM1d3 zRpiSQFcyRN9qV2NjP4eP53Oc9yEEUttAgxFfTTt4qHN3auZ2sKGFTFUlbSjFPwvHdUya4JzvKyL vF0NFYYPfroDlBGt00f3Jx0399UHDrhL8lrNEzbW/hiOqxllF/qylCpLD3LMfc2U5uC9Vv8XMcvC zMzQFMz19vQ3VnTpM4D9HWTUwn2XxE+tVCDTL38YJo3+Vh2NvRyxE5NC+IWZ7RSD8dQspOCObJxa 6oN6v/KNah8elV8kOl04Pk3bPBFhmQAFl4+3vVgv5XkS76qlGRlfpZ154CKC2UGDk2ssNEaUJUJ7 IQ/3KR08RZk9bTRwvS4amVEM9NRZ/g7RgO+r7fSkVGhofDUCLMtUi1RYzP7g3Y+39qWGMup7SSeT hYlpTjRPT929dWU89Sv+dXaF8qo4FTwM14I96q3y02DnWRdjM5UquG6Tkr3s3nO8LNIdsxFQ30IP /DhiNE8IPL52AvtCQboHPFmiTapi1LSDkU/VlicdQeO5vgX9GXlYPMeVR8B+kF60nBRt35ydkKEd vAqbdRG+m8iGS1zN4/FlmIoi3xHCvO2dR/Zs5A0kf24XBWnzLitkr2eNcqop4otU69rrtR2RhWKS Cwx+/BjyocJWkOITBD7jqoAC5+caOOn9J8+kvCRdZ7IyUOGNWcU7BFkMqy98pGuIru/h1XgML/Yi vqLojLIB2iOz+BTLEgx8+NJj/O5gcHxCPVMfzPTYohw8cpK4/mr4R8J4mHe92hqF1Dt/ZR8MZFbd jfXFvfuoqMS5oflsHXwA95m98/VB3P1XOl5Da9WGOUFnUm971Rwf6N11nP9Dog74/USwGUmiYjN0 PysRxyowYrX2O5UX99+CMShgNzQcqpPdru+Yt9QzSHL0VOW0tzcEWT0X/st2tEQDJxob70cMcnTc SGa+BJJ8xB3axGirfKJG1T2VH7TwC0sif9r+VXR/YIVxY460nMw/Gn0cExcoiSUWi9QRx59W9AR0 n0U36rOhFN0ENBeIXQ0/PeG39ywxD1SCl4NRkWVn4Pf1lEIRJ8Fe9GP0tcvyt4nX1bqN+loI4xHW QiN8hkOFsn79EYV3N5tgt9Ow5EUaQgqwMvyy+p8H4jC0Ahu4sX0wOF20TIBuohcd3gE7zoRaTR5K NzHr2d0f//RjvRjf/QEC5nqyeBpT35cLJS+sHby5L3/MEoAMBjk5fc2g+VtHEijTnE3Wtx4kFFcz vpQ1uCcaoGy0Qoq3TYJEEKVW1F3FQk8a2LYV6iUTFzhx7nIikn+ENALx67LF0poAUzx15lHw/1mz r1tRLWyhPMaxYzTQGxl4eoU+wK1WBlp9M8K+CTLyPDbTq3TbI91e8GKJHQ/cAsLLnYM66nPWXGBW 7wI6YXOVcnqY/FOWl3MyuaIYglxTnV0cX8CY6zu9vAbdOLEHlEDq7Y+vGbwT3zE9no6xwBy0r6/w q0ISREoDNiXvGIX6L2eGJohcLQ6fGrLifI3s42VX4wRRqWSY7dNwA1x8rnVTzXQOzeepUea9eKT/ A13/eXYvr2I+dqlq5S3p4sXdriVYRgwT83kpvx1ivGFnYJaAdIy/v40fvPtaOnBLLa4TkxMQHoA4 DVl08Wbakx11iOnrBkhwk6JT3jw3Bp8de1l6QzWsgAO/bwJag5yt9FAeQtgC1VvMyrUGV6zYvbdI JFXHHXTZN9oQq+pl89yykoLeW//rWfApxl3s2YecNeIrGRgCWzAijXk84b2CvzgjUqKj014l2WMl fCvdqTyg3Oe1wG2cPRWu5p0FGoPZodU/mSm9nO0KgvMbggLtgXA3XfJOkmBv6AfvzOqPJ+cA6SrB /vMtethZIP4GRj79gJJ42R3gEBdqpL9kmU1Ak1xDNIUaxfmu7SOK5Qp02/RURlu6M5RCJnnG7PwR M5w87X5+oZa+xh5RYN/rvPQM3M3fXY1+GBCTw3j23Bn89K3tVj0591u3qc+Yqyt8q+Je6MJA3YJ4 meN/t7DtqjVPrZvj9/O+TJS+CKx9c94U2z4UGnbxDK62Y6N7SpRsSS0Kb3vvrDdye+tdvDH/mQ+X dOqhmNhIvID/p8qJ2GECYlnVmELxWAEs+F0zmqpxSKw8X6+6NBaaW73gcDRHEoL/JdIhAPrDKbN2 l2sNcFC6Qhix47gsn+m6EkE1d09azdCZ62D/PGUKc9+DHSOIKBuC+l09coIzvbXAjxeQeUzdalNb jPYihJaQTDk9coL1fp09Mz3n4MRkXTA9PfB9fV4T/eWCliyjarlo0oOA0uN7KwDOnd+PrwzgIJla QgdeyQy/zf6N/Q8cqd6Vx3acluBXN+leYFqOmSSjeEjTTL1t2q0ZQny/poEvlTUUcjWwNtWfELpX 1fhM9Jve6IzwjJGrUfOaEUzdE5MseeEwkOjdPAt0fc1dfcxZge3d7mLzvJWa8BuVCGycrtwG6efK a5jpmMk9ExilNOnfxX7dRlUbzcZHkmwTF4XoBnIYbpSTl3f7pFfqPExavbxlf6WLnbpUqsQd+QA2 SzLoAnPcB6KKHt1qkOWzg191DPPVHVpkefEgYgTTvXLF22OjiuImXMMWIFOVq7y5ORS+F59UHesI CF8OeuB47N3bUkKWi/KhR5UQnFrR3ILxHSIzcewGM316jd+93R28zT0YI7NJPjCqLCUWZtQlKRIS QcdCo2KrZ5e4KtMBAkb/MfA8IbpoF6UIZtpd1t18vcZ9LSdtS9xsSfzlOxKZnW3dliq0GhqfcRym 3pMnrmo/qk4y0cc3mt7T95qDdHWe8fpKABViVJf9ktww6zTodF3ud12+chw1LN20njU+H+arpHoB s4VWc6IscP1IkGOC7B6aDL5m3mX2MozheXzeYK2iYavHykye3zNeX/yXYl2zHZrrhig9q7yMQv8M X133Pf2ovJgtJA9OSXFGpy9MffnqG593Cq5YvSFGAq3lBKVqFU3/O0NSyleNnr97EOg9vZxdV7v9 fDscPb8/hG3DOF/wFqL293ytYYb3sRZ2XOV1Ma68KLtUSF+IMn2UAvLD/043U+5Xj4Z5FJwUKp6W /dQ/RJtJKReRn/aEACKHnGuSnQD3Vxd0pdbIgZTdAMg2tsyplbynOeCiksi6Nqqda3ZRED8FjV87 Bq1VNRUiXzo084N8ZcoSH94U1sV305QrAE2dm8L1WvfrHtn/tucTHSbdMpXZ94fh/+Y2RuaImMGh 5pCdJkXu32LzLQvYg/IdFPES/TW1/oYiDtbc/P5bZvLev4Y5sgU/yJ3JwAZMJqRrRLQfmVwFR5V2 2e9Eej/TeZu2X2I2zBc8t5f3lY2UVDAzHte0C36HSla9XezYG4RN3RTarV/Ut2McoVID0/+enhUn WRShbRbP/nfuN5k+ulUElSac/IcKGx1AkJmjRFiRrUOs5NL82JPcSDrjDDCFnTACP02/E/45aJYh Lsj/wh05bULdJ9/G7EEEbBEfLTTehQ8I5VjR4x62gjVqeJBZ4TOUNVR/p6X1a5BT9dSObCUIU/Jt 8HjaxlVSE/R5fTbt/IiATQT/vhTMa/awrcicsewc9ldtItYGxBv/DBwy8BLn0oZY3379sB+wLFN/ Vz0hTp/ePkh20j0wKQ1R3mi/Ej4axXP8OJBeQtFosHCLnrFy0f1Qdd56xfbbhJN3/RBTFPBzWgDD DLUQ0xqbs3M70zO4CD3Z7DITuRIimedlse0tAp3IExxoHP8lyGivESXhbGhKOAHX2wbqNe4l5Qdi wu1+WP0REGWFZaXQEDAw7AwBBZCQLfPTlSMHDjJPfEpNZ2hozPRn8yweLRqwDNYlB215zOmM8Q8u INjv5JjOyLvzHogO+SkZWSSOrekJM8Uv7r6o4n9ouymSjBolHajNaEit688Yg3kxUZc2My+0q7fq 7r3U3BkWVZHsQb7rjUBoF6fN4teW6y3Wnr7MfpbSopJ8bTfDZS+GWEJyDL2YNxnadA5KYvISObq6 ZBPgbJIwLT3BrW69vzrR5f8ERH2cXZG+WO1hr9X+BT442WIz6gsLGqBzuaF4+rO/aNZ0C8xjnb1w nLO/3EXfvqV/1yOMNeJ3eS4zHZFdgLOa/VV1zdCfJyIeMPVYBWpt4/wWS+2z/h34Gr1d//Mdmj+W 3+MdnWDczWXmIpP/49oQMP/CKwwMEb2tkh73XWCt9iMPKUIBKHIinfcPHyl2feQpwBgVLbpPV53O yj7ruGRVJg4X0fwr928XRv4JmahWcAxnebp+KrHJo0wJZoHUIOi8nBEangx2wyqmODFRMJuiNBEo 4DmPQEuNZro5umSpf+w2HmHTeRqaDZAbR36pyDO6Lc801VOfxJBIFBlu2gDFcYtXu+KCCz2tvsdy HgIcfar5ZswgK9/8cahep12JPvyKnWabJG1ny5xkIKRv/eYkBNx7v/DePZXqReLYKR+MEV36OtyN uh8nO2RNlCZdm2140kPccf89zLP3PFoXVCoFatwC7SZ/rmKMlaI2fzhajNaHPk6KG3P8w/1T3791 lSi5Bl87oZUUOiW9tviHnvlT5gvOjA8jJSXBseC7+/6MPNE9p3KWyLK0B2Py7u0KwbqcNCL/Pg+d cOxZvUJcd/0W0mMG5TgRkU3zM3tu/h6FHwCY81n0HzQ4rsEK/thflDJM6F9Yj/+keC6zzyEIhXxV KCRRsX6/QdC6icyHCXgN79u/fMlf+qNelyzpU7x43YcCDRm2vTMAKD6NooCrfRMLGjq6mqluD3xX 02ZGnevD5salyULjokJuwsctBSjkruEbUBEVGkTNO0oUFEfMl9fkvQgUKX/grqvxnw13tOl24U28 Wchy4RYMdmoFkfuOyWbP/FEllHVHvuItiXjrJkZGvdEc4Icz80dz8MfxFlCdW16+HIdoG69hBafe VQcWPalS5PJhKJ0odssejlFlDKZFfZ09gNhZ7ZbiCIB6IiQ//bJ/BAJIvnwV1eMvpsjMzog+//CH xvkzrp3VVvSJ7LNn8Cp/NmG3qmC1+9NIjx22MlX9kBufLix5lnccNRIRkit8rQJA93wtbP0kElBq EWY6reX1WLGi43EYsschGP152G8MGScZcmUxEiljM5v53tiaO9zyZtruEwmcU70TsQKQTzizUCRk 9RgPPMs3ybUZaEsm2BKtfMzpKoWBFoYV9/64uKxxL/x33Os/bQFiaXV7RNuU1rhto12goFeTI3rr e7NDtXhtfG0XI/yViqxuLQXy163abBDb1czCCvJsrw4ujPysX+zKmmRgs6lQxYr+TJR9BZqkn1Ug RNmlpZ2/4Ya9jXSbTQ0RRo/1IxX6o9CvpBD3TnU4RIhankxucwRHVT28GEsS/IM7wwwF91OY9Ur6 +CGC8oid2qhhQOe5oHiYQHHHGUzAq8zlRZiJnuPl5ly59e5IN3m+ZGCZ/CbO+gLEBME8L+eunD35 aI5XlfccEFXfQT/z0PW7Pm3xnl7Vnp+z3t7+/nUlnl5+2Y12kKc+nvCF1PO+H195hI1cPnDeHv9T GXl5+JP1c3QIWmTBL6Q5P1IEQdrf9A/oxB/k4PEUrdy2esl/38Dsdzk19eysuKLL3U3CBFlUn5yx kSAWqhx03c4Z8J5/Odn87wLkgoDQUHgfMzUnEW293UQV043f6lWignoYJS65OigzJ+1Nljm/N6Y8 fh70UaK/wgggCsg4o4y0G/4cnVLjWHLUHQlr8bOSkpX3LREzPTxGhV/9EJ1+WhMrUnJiPL14s50s fP/1B98EE6bJQSMz6waKfluRg1mWJMvC3ND5NTzP4K3ifXPGjdEhchj2muUiMFDd3f9M0OOzkC1y Y1Oce5309pe6D/cWuar9HYxXNdR2Pu1gDzXbTO1du/mWWvz9Yv31mN145SwWddhGL1k3Iv59FXWn eHP74i26nYY758pBnQz0xNvFmqFldV0thkSD5FU1fQkJndVr+uOKSyKBQwraczk3V4xSPWfUXNtk vMwqK8fbtNjmlg90tDcfNT/AH5r/mHlvo0rMYNlF3WFqEnmeqHQUgJLh7EgoiVwFfVyKqah1lysl EKky3HwEnSHR6SJ8iQ2U7ApwQrsnHB/ciu37fbN8eo2ln0IgfmPu40FoBZcYkqgJEUTWN7h+04pQ c1CFNdxb2lOcO/1YeupcYjovfUbMZo66RICqMR3xyQm1c1wAmAn+BbJVJOvyCqZet7x4dWREGREE rCkcERg7P5bfyxtZhBFqB3Fs5Npt3MGNnPCdBCW42Jg9xKo3PHOSzyWfPQVmuU6QriiTeJ2leRBF WxkUDASWBM8uCB+lyLUHuhcsjwtG54FhgIVS/8ClbB/MhDoedyI89kHcrjYRKLkN+/G8K6J5jN0K mVD9Jouop3KOsq0Bva6snFMe2EM/v5clnRed85zurQMFPostxbtrzV2Qz52m951/59lYPzT9HUYa 4kJ62sWzYBf13X9y3EWiQ/OwXT7xQ2dr4Ihi+/o0TPBiaZ4bPQHUIiDXfRzb1hgbegleIkJqgbMf +o41zZ7EGwV9APd7/636XYRrVrLigRgSjU/X4N6/lqQ9Y0031QacLlpS30A3V0WywHZUmTw4K/Oi IADLvVoHnG1O5PlG0X3yGB2NzrSrLYKvrXpee8mA36/8uRM5Vw4txl2MZpUHCh0lZFjC8xMQf+s8 GylB7RMiscx6FHkboo0/XFJ4fp+CDXv/+OUPFitLd9I97syclte+h/T3M+UV13x8eZlT2cRiAsqy kKwOxUK7X7C1aopHlpz0DTVN3mdy5cZ/nW/34YUgL9bAlgJ3s/+3CCRvnTkmDOJc3DWto0/KM3i9 q410uxyWVbdMJKJzCKrwLbuccxrLHRIj2X581X3ks+bS9PFVUrgRrdR2G5nTHYDOZVRqHV36+FTY rx9pUhQfjIPX+Uc6ggFL8I7IEX9XpV0/t1tVfXVGK6wgXBv8y7dauvoNNoPVFD5YxhVqOe2zPUOn t5l+j55VTEc5lwcV0PmSuhTS/VIbh/vmibPpRV759/7psK7qK26p6NfYCGKeJ2KbQ3q0hEfmHEa1 730bJ6ulyia3i0BtX72d/RzcFD9aflV/YlqSgZdW7YnyQnJGCItUNPqnq/qIIzAAkqJuTrA2i/32 C6dwikntLSgnjyd9MFA/sx0GqqAT/spzU/02zDAYws8e+TVpDMrQqSNhHVi6CkaIYkPLtrktFt2K z9At5904lz33vN3ASA+nf1xYmpZH/au08za8NX/k9yPdNxeZ/uH0JN910JG90WLSap89BYW4nPIU zaKjZfjdKhnYZ8wCnfMV7/0abOYGte6yKG02uL9UySGYF1zcKHw/1ZvUngSUsVgCHuppXbx5bs0T njMZ28/cFzwc2qBsWVzvGogYAUO7FdyNRuZCvBEczdF14/8enHen2veaMH3OGAK89cfkfNivGnn0 twnBzZacnG16m+wcGrLaPR++m0LLe56z20L9EanupD1h/St7/8Vk2YtzmOOJaVvLfFlsKRB77agt nOw6O/mSUuwGhG2q6OAOzf5X9h+5zf0TWr8U9RgFPCa8cg6QBUcBVbwt/Dxq1K3of8R9/3q7OUVV jjf0JsV2mnzv8IbVNYKhx8ZSE/J+MWFGVdUcLanjHIw8A/06NoNxo/803P7Pvy2WcD3aSGOPBk/v 1djz3cK8/7cp28xU336f/cGfTN/3+RjR+hwaHJzuguEFxm0CBEPua2NPo013ek/soTz2YPw1HXvh GcAZCn2whc8/G/I9cZN2frPO95dtx2sNoyeYxJxdGn9lyzvl9b+sMIlP1YrWDH7vqc2deZFAShTD frpDMz2bVleRXfEoeTjPPc6VSowi9vGBDeKuXvp+PcOshdNY7pp3XxqdL39ywX1ze8/UMDVIFU5w VqkcnrwMxP1F/c1sAN0advx5Y5obTf+WnESdNBDlB6T9/52SvYBLD26bPfxkv3uz2cYPJkxH6MpN aB3LztatloO7RF20EzvepSQ9iBSZezQn+0J7PRl6GFoVhhDn2BWxnbsRvdWCxhEKtxs09YLfNNRy +gcjXNHbHJmprCxLmaez8LyyDr09Ft+pFve5B+XJkpTZ7J57BUo9n/uOrNR0eSlZO/IifY4YKCJX 8wV9HXuA3ZM56jtP4k0IT1tkjq2XVTj3k+FaMLkuJP048951boThBB0lKQydvjKID0k+JB2lu7jF qfhzxAIQlH4QjMJjPtu3l70/ORLRpG3QCvg3jnyHO2rkIVJ03Pbm0lCV5KDy6d9snvKaKsG9rAJ9 5LdIyqWtf32e+611ias8epn4JwQU/qxMvTOySJQ/Sdlm0/XnHLbYS502/N4EF8eHrPWa67G94H/T +HO5XYk/3/ynwVDcVI8ofZ/o5I9IfVqjbTyKVq9xf+l0AE7tmWIIiG9ILU918EWHYqfBABPLFpZn vU4U7ue9bYOeL5ziE7kv8KuZkAnNa3dHBz15bs4BWyxgGO8TpN0GZdb+zHSNJpjYuYJ1KoMZ2fv2 WAgeWX5avPhgNCN69Vl6ktiI+U4JAlYdtv7urH48fyM4FKsxI/Kp+NO/uKletdP2g4q+xe/yPVcL 6O335hj3ZxtIXjZYAKCC7epClLSw3zElXZ0ydTyDfpDTtG6CHwJeZDQ0Hf93PLV0t0LmfTApjW1Q IV2RnxW91X+KaVfgFI2FYyV8CfACmCT9vZf6Vh69dRaiADsymYmI3HuZjHeFa7PGNVrPSqtLHd25 t16wajyXKGDPCI1nPGbbZk8nMsPYdSoCRjeVnYgwhGbwfFmAnFZq951/eYH9YkkIIxFhdF0j1RIC iJJ9QZCErN+i9HfpERmY/zyUZYjtERndDBS5bQmVfe/fE6jf1O32fXAq2Df+tptB7d9KHf6nrxTW 8Owi0BwZzmIZDRJUTpA7/FJFGM9eDdF7AqQFbnjDHYf6KBdfo6iILwQNTLQ/GS+ehfkPFMgdEhE5 uqYY+NNsnztxD3CcNRrN+f9TRZI68RwCDUf3qz17Bv2qV47haA+WG3vOLW3h94Rc23g5q1ZNOaTc pwT9FzrddoLhQSHVfwUqAxdMtGX1SsfjyqFdLS1/dgw4wRYD3WMVXA/oAIi5RHR2wyycZD3/5Rg/ QhxzuDG0Ih9skl0Zmw2tIlHqNluMNTbmfsPj9hjtol/SPxHmfAtvc9Re+4ej/d9sIaOirq39lkw1 qdyifbGfnggfF9GFTb4F0tIs6KgkaC37DR6qWkVWzd9xkjMWKCghcXdZiAFC8Q8SKtu5onndcJaI tV+/P/UpSVuPT4xZ+6mpbyx5n4lJ6bPzvo9J67C6jGIjX4a+jGJL6OJd95nhCKL+G4p05yJ+i5jV +0LKYT7IYrW0nWuWF6GBO76yE+t6fXzLFdWCcyX9pqJmAhwzTJopAgkzJT3liWjbZVyBNOiiKX2C 0ewVib2e/h6ZsWkIQmjeBOQn/yYuGckKs8r9uBdo/k/ymSvda0rZuxgbK7dZ2TwSeZ+lif29/6a/ yG8Pi2lmIhrswSmI+Cz2wDOIaKiMfL6dq2kJD5b+rcjpaTcet17pEh4KFDSTDBkfFBNJ/T7sz5yV 9hHhz2x11RWV+5UdCxUVFRIhIbmVCb1PjTFo5Q8enD5TaMG8t5yre2Zv8xkKWJOJ4jkRjmFpyBk/ bW5LvVUMlNL+9aj5fT63dYh9pcXflZECnpcFO6RXGyrCHZA8YndLJlM5m3uzWtEUH7nqJ5FQYZB4 ukhZEnv6nd/s9tzYJZ8GDTs8DSpcyH0bxmGbZwt5yDl6wTno/jtCHyoe8D5PHhfGVN9hHe8+tUqD qObtiPMXVsZvSbF5VVUIfj+HNOavqWZIHrif3MYJOH2mQIyk5ayVL1manQyyuX+Qx1XVA+UmYpuo Th3LbgkIwGA7q80B38pen3s7W7IfX6f/K550JjXhIjXd3HRcApRuD0B+mkKZK+ky1+ioNOhdQnNU zX4tXe9I/5d/uLNMQgK9vmKvGFC3c53zFb16t2SaF1tO2ALMxN8peunpmV7/ngNXY50I4myj56+g fAc2NPuqnzUb/RYufv7BrHmReYGK3lyRjYr+pfk+RUkF7nKufeS5ub2IkR0IXMN++Or7mnW9jBj0 3xmbg38ItFdVmf5UCTb29Z7kGR6dAQL7uTnnr7zhft7iZcyu1vnum3WRygYvZ9Nntnec/IxknBXr 5jz8CMRByoI413yPBdwSmq/kz7alMBOi+OPt2sJRSjjMe265dxT1NUmgWO14ZwU1S/7FK6mSj11B TGL/3XB5YmQ3n+hH8+8QfZ39N51TLVyXPmRKMKiRxP+B/RIfil8kknLQF+wBfeMsdaIvAdV0OD2d vGnSqTZx+ZL/FFVfeZLr+UVlsejJ5JWq3LwnICU6ZnRRV/CcsHtZbXsOW0TYSs9t3b+0ZwwulrCX H+P9i5WdOEtzvix7z4zUCf90K551LjZ3BTzkNYTk2ob5fTpD/NgRvv4l/9jcYWcOyTR9/GLdJM2N fTyQjRLq1EINWzzXAuUw31l1OHPcnfyXexmdgN4VGri4eNdoN2Dm4oKMtr37bOWUjZ/8hfrowiOQ SwWGuEswYdyN6DsU9zGY3sT9H5pHYEUfGtgGPIxYwDsWroSHXPONUu9Li/Vn+WzZbi0VghkCVNfz pG0kq5J3E9hpFguASCLpBHKRDEjbFZO7Ckkh35m5wp/7PX27uOiir+ogai4Nb/Ld5oxH9PStXedR yyncGdEYvrrBErw/LVx/dUB8/g8czxI8vYDsS5LyDA2BArQt8cAHtO1TYPIm7rSugs7ZfxF27sxX HVQeslXq8TrwyYCp/2PxvTSN/klCGti+giz2IEy1fQvM0wFyzeOJWN0W9arY9Le9R541cXy+3OLF c8Z6WifbfX9OPC28o6Zltap5Rb5QH9MrwO80O01VyzGbb9sWW3pgBQhEf8H2vkfVqi7WU/EMD2/w 1ibdjp7XHfe7HK6ajz10P77zsjyMH+X+7tR1Sm3JTVASG7G8bC20uWNc2qcHlGf2ZHZQHLRsH+h5 XlevZRf+sPIPT/hB31++eXrUK0EfHrt32wQTQamZeovSy934iwDs0k09osv9673/tFkbYX163b0/ yobUv1D9X3C9HF8vJW3MUkhlBRdcd1HRpYVFJfDwk3PUn23E8n28Vi1E7tv5+k3/jK8BaVuiQ4wh T7vxFA4FD4jurY5vYekOEIlxacnb8XQ1qNlolRou4b0r8q60mCWr6vQ0bm6OLheX9haJ5oPoln6s SYqsHeSu3cgdFIG/Vl0MIZmt5g3ay/3cV1sNMn5wS7MTuc16i11Kva2IvR1p+5c/BSJZgFhDzOzh GS25aj1IdQ3V5/8Lapkf0OptpJnUHaCeR+dKDj9+IIalsZT+mJ9aet4VRWl+RU7ep0jZxX98eAR+ 91EGSiD0SOrdR5xFuRTPbSeymSJBrN3SH+MlQTp2sB0+jdhVvPPreafc7EdaRGMS/bztjUIqbSDK RczHnblNwFal/tPtADlLm17sXF4LFPq9axbFYiYl+vp7HId1uUrDokboZv39VDnJ9DuA/N16nu68 G3pdQ3+BFnF67HCLJ7JCuxe9cswjwoe2PM7e8zIOL2DFHV90F5QEyJPZAw5O9IU5dIyfKWPvge6v FA2UFSS83PO/E++P1DfqNfn5H44CS3CctSWdE4tF3VYVuMtTYiLXVO0dQ5oePLdlFR5Jbd2dc2po 3UCrF5QdW5z3IJ8pnSVoxSeQR7dI19RxKaBiw9UmH2zcV4Fp5XRAei4Fl9LjO5m0eo2Fnh8efmJJ HtxtR8K0U8Xm2KhKKfKwe18xiLLPack8XWUt9yVItePg/Q2lPh2FWmYzxpJ0EuUImDhcEt1SjtSd PCPBNN39dR1JpqeXJi85WvUZ4hTFrllkbdMNADgxTYM8vQ0hDhuL85EpejsEg3iCIgDUAojM9Z0r 2sT3ip+4k//4pExLDP4dAn0sBzqABabOmIismh2LCuYDTAQpuoLKRpWXs9l+kVPDuwesFN17ZOb9 vNY0kUQtnnFgMgHJPTwM95EDWA0FwMkuY12tpV2pQY70FHC/Y9rq47hsuRgm4OB9MgPJ/SXpfQW9 X9zHsN6cDFh7S6AqO/eMdI8dHe1+GOcYDXoF6qCC4vMc6uJiDkRNMiIiol+GnXjUxq45nphQsFBu gn6dItJKXbJyHoAgEOs6v3KN/Gd4Qljm2OUNXNAraLDJOC1WCxwzBQbOlD0YSd2SajBpAOc49sCd /G30eH263LJqPrLmN10yM8wCeO1mCcl9nRmKQhv8UUIqwHs/SSj+GX0GnONBEJP34tspuLISbgOZ k0XAiz9pfP5Fiju5JDb9RbYtfSVdKt9kaZuViaU6M1LM6cCuQ52egRxQ0NEkqBfjbn5+SiSTJXL9 HXLtLbuQRe6yp12mE2jAnlsiAr5zN9JUat35EIqak2mH3zs9c9zYxOSbGiLe6uNZc+A7JZwq9Lni 5y2ME6n7kAmAoIoGPf16do4EECXGtmrbn/UwvZw4Z+UWFmHsg50XYEscQqjWGOX6GRISXuP8LK6p 9wejWmqpWIdBrlFjkbwEWiK2oPcmcS0NuBq3fzOfEh4mPsEaTCeNzQy92GBVGuWwowvM3BeIPJY1 q7eYfze7GfseEp4xONwrnFU44HhO0YKxmAQ20edASVrte4DF3CZxio/dYmcBTTlefd84S6yVYv7d PfIyC5bFEdNq0zutcuv97y5FLa6c7uovTux8rH8aqk3l/qTsWBjm+zm3MV3k3uOsxpMkJ7lgubcS +fn1uNehvT1tEv8uH4tkXbK5YGWmJhhdXY1O0iPfncys3GGRXsFdr30w7TlSR3Ym/txgaKP5salb WXyqVhCi3T0SeT2SYvpSDdztRgJ/r+lyTcW4AY3jVBvgF/Q0/L9Gccx9v22oKIdWGnAs6ZIypb4m uEqEzuz0+dY7ib2aj7GjZpsMdn/z30z7fXMbeg9dLUv+aS9zwjo+ecoAri4/Wfge6CJzlBP8N2CE xaxOLrOYzTsTUh26M4gWhEaTOlJM9XrAfdGNHV48iygBED+8Ini8h8DIueDtiu+c+J1ixopsxv3X cgXsNxoUDgpaRiHDEsLCMr+MTNeM4FCqKqCz60qdkjQDAN0rRq2CocvWfOKMSJlSsuE791o3L1+1 /7NsBeDJfSpjZiI6xL0BG84btXIMT2DrnMMU81JYP19Ck5M6dfwWjai1oo/t+kKLbHyGfHi8OT9c 0MJ8Pfrk8CqsQvqdQho9STiW5qyMQlCzMgUJuuLLKjrn8h/q3V01zCPSGCqavBNIPAKyAdmE3dO1 g19S2Gzif0Alf3Z8LDViWq4DIq20ZTncZSmaNl+mDYRdMZ+XEekag72O2Nq9wxG8t0M0nzeGFpQm P/kr3WIRMcm5YCYrAEB/Xzs8i4QNDD0sXrNgcev8jZ0e7NpCetr6XMwMBj7F9ZHdHxbfgggVQHFZ 2uO+VS2IICLa5JLm0DdTWuX9kj31LGV3omrRWEj3XroEcraxAl3Vy0p8ILJYGZLcvtkHmCNSbT4+ cWsvHSVmbj6lW2gC/KiFneGV6L9LcLjcdFKCYSB7QDmQTd2I2b0AvuB9Zb/lSlOJdRGsl31Zsd3U M9oW0HJmDevhzJIi79Ft2ii/plEyvNz9Ga2wp+qY6nUfewKzI6/ffLpyCpEuEX0ct8y8zWDdu3q2 5tTSKlxtPlYSXVX1bq/JYGBUiPwx85cyGjVa3k0U7PSCXk6Soslz9Dol+v+uuQqy22zzfP29OdOw GGof+mD4IdzV5MEGQMVhi7mHrLVH2VtflNendTA098sBtUgLggKbTXOTLUDrVR1Kshf0Im+CV5kB orxlpAFPi2nB1CIg5AH2cD7e43fNcMFSkevKT5EdYgQBGEhWWPTDjjOdbcHZfwb1O3uaGMIkXCTL 6/TxpbN+PReU3XQ+vy7uI3X0tZQ8RqfWuXEbnH1uP8QIMjN1AP6tVDKYJGPtBKI8jLD5vHZAQ/vs dt3pJLnpy9pVFqAXIDSyMsd6ktZ/DNu+OqDe5TKcrmQzsBDOYK3Vlbwbesj+e30WEn6F0sRLjXKX 6jFr3wZdHToINxrwBo2Euhu7nU2iox3eZNf3NS2m8DOfQCWR2qG07Ve4Ctf6X24+Rvey6CiX3xxs Cm8w2kOURMOEQhnyJiJc9LwHTmQoFPwSAPkY2e/aLL6IimLjNboLgy7VLT89jIZxM1eI2xHu2dgt XP+a9avAbLwtKTKMw0X8ijGcbAzr9ZAgB2IyRBP9jGQiCtStzLy+sC09KfwvM/0qvbiABDXqNLSw zxGlBZGcTkyiDTJ2DAwp9UnwP83Gh7ZzeESq9G4nRl1g/ZSMZGt98MdrdQ3Ae+aLlM42PZPp5u3L fPT0a8x9DTQJGIJ5bPlaGciuCoX9ddkyRsp97ndi2zVbvlrAMnJP9B1R1WGqTUfd75IeIDJfSn2g GidcjCOdjdIk7JRT0l2Wvffn2BPVmkLTnn2S60rZHHIlW0wdKl3hxXM+gTMBfwo46+JAVC3iXFLe GFfX2SREnjg7BX35mSSHq0eFkl3DfEJMgKeQD1NjvMBGwhzd/3y5tL3bWUohkuaXvX9dlDwt5x0F gfFeHnwvAlQRtrBdBEbwqq51JndK1A2qVNDfTWwxamrKLdK9mwaWMRVTj2Iq3dp64jRi+7l6OBWa 5nJZpTMxOsZSPRGi/Kp9v/27QLjvB9FdKtLdLFz9XaexHPK6QF8tghkd/KSAPV3V/xmnxNJGio8z hriTwUXc3fyFvQUWzk5bynf3OSsGs4J3jttaa4YE3os7NIfMnFrrs8fMPpjcazw1XScUC//eMxwy m517YyXsEBzYvmKCXRXtEsH9jR3cf/lMUrO5v1J6/G28UZ5nBS1Njzb3Kh1IjA2Lm8WsGgxwIn+s 5DyvH8tdxdUMvAeUohCyLBPlO8bq8M2f8I1qWvQA0x59EsZsN6LwC6XWSifTR2u85B98E+BMSvxy 9Hw8YplKgiHIPpZic5yDWl3ezXT1D6HOWyGU6u1LY0X982G/rd06dUJTizo/TfzfjUxfEEaM7+gs ValCnPHpcLK3YjfKQqL0/kmWO4unVwh57SGvX6+7w9dc/4+rPeSdzCv9KZE9DuE/i/wq9wDUGp+B neMJibhlfgwt2cbSyntc4uZlqTWCfDO9tAM5YFzJxnQ1y93M0rzDGWCaXs2LJ7Hk7bzTx3FI3EhR e5g9zWKdcG/5DaRc5AHap+alTuUDPI0cf2QPomj9+tz45yg8HExweDGmHKx9NHs4F9RN2saTrPiD OR1dGb2HMF1+St1+gcz+5/BscR5vzRzG/XF8EqWR7nKztZXXFXuCH0dbxEvlB4imbsrntFh5I+/6 oGac3B2pXVeadvz28+UChup8XaTwrT3/HYu/velfHJ3Q81BtPbqDt20qtG08j0mnc7O8kA+2e/k+ lmfGADFKVSytam3NfvHGprgSIy2y8hIqqmM2zecXMluNuCWIGiMoz1E8U7Wi5ZeNnv4uudXcKu3Y aAHHPkmcX0QGUY2cQALusFNZlP9lHZ1iXRYqfLAfom3MtlppXsOFV/LKaWtQlO15l7gEJKWJPFgc RvEHiwVnkuGDIumtxh1n79trBeJNHWRO8zKmDAhqVOuhJBB200SJKunSda26zYEC2mQTvTB8IrHC oLP8jRKZchRnfX0y6RlX+IrCFNXbsEmdvULJCvMqOX9wlGKAtgaz6/ONlOdK+yrm+LtQV0fv0ngM i3eKqj7ULKVsx6WMAjNtIT72purmE70oJMB4KjbpPUUV1RveUivDPxNIRwFvwpe7OAtG1dEzymEE BRhSS9btxAdlN6EsCu4WAADTlOXdQNf8kstKIt19nnK39xPQWHyvGH0pFM3Tcn14t1aWg1aew7o+ MojEaSrGfNLxk+MdM5J8q7D7y8aN8dU6/JKLUiC+vB6+xzHTWRmSKupxLegfYdldutITLP7RZSpf H63Y0lh7s1FLqzTkEvfqXxsdZ7Yx0CsMWFNb/pLe2A1jLI4YmWMSSlkrHoYtzdWzFh4zLv4LpkKK bLd71n0pOsxxdvfNr7tq+fn9EsHTLR593dX0TH53uk5fOI33FmrBlXqxXFyelwZlfImYgmMsXOS9 bU3NxLeVj707zLcNL5sTXAz9Jn7kLBSbDfsdnReGhIDC7MfolIxG/xrBzKHLNhrftbMGAH3T6inl EsIvc1U03LqZ0RTkhw7Fx3NLzEiJHTk9qoHu32RRz88IbeXlpU2ONpzq010Ltgl685ghuC0hPkYc TcZ7UeoQX0Bi+IQ1dka0Gb3MVKE0UWs3Y3/5cR5jgLp00dogahINAN11YnmDRfJbOaZXPHRA/t71 WPjoQ7Pl5zX8ACyx8o8/1wgomXQ0OZl7f2pc3OX/LM3V9n3dlmBf8slm7RYoguHPrDvKB3ObFuuu fwg+GYYdbHayv/NY//PxTW/Xn1j/j0EpuHbxy9ETHRcMBcCXhVf0oH18cu4RYxhRtRUI5eDe8irN cf81Stt1pD5/kiSoXppdcxkjc5eqFKDHU54H1Hbcm4comRPnuG/iJBfFvJAqFrcqLEgxDZCK/92l cOJLRJXMEVYkl7z9kRR5uIWUAkWtivdwnvcFp53BHErgPPRuODRizBdckB20Nd8UtGNUaJm0+npJ 7a+CAv+5w1DdFzWU2n0OWvdbZU2SXT2bGhtQp2bRo/oZ1rMqj58MbeuFambMnRN9NYVzZC9WPZwq s05Kravq37NywXe8D64vg+ZyRn6IsBzx+9RUPVTQfxbaakmZLZ/2DAew5ii4nH+v+m0Thlny1iFO cFEgQ6dAE2h0GmZsXaQE5mittv3p7Yef+L07p0kYNiXpDQoFuN4+ai05m++aahqMrlt3RDW1Mnz9 gPY+V2d9L2egatjLI/2sYdzSFxwZPJkedezgUvQ/BR18smhfqpGVhAICRL19tzvp9gcP8TzWGz5B T9Sxn6A+XqqvLvUkHP5EmMtKNIGc7KgfOnxUb0DpIX93PoJjtJ6NVlpg88GEXLWcUZXHiNdthljt 4liOI5JiG7TX/7k1zJ23ieN4uEaLlLVhu9H4rjAVrsudJXKVqL1+MkC9GnyyJ52q173H6fh8mYcQ uoFVllP9HUHeYYY3yTc7RSJlOa6CsWiTpF1meCKf/U0q7mq0fR6euzceCT2pWV6DWLGXV+oZLZkF wzilvenOl+vfq9f829pU5/BSFI5qtHs3h5kfjT1f61ecKfzl53kHWIqAnebhhcZ/mMMUIayNXi0L MRya4C1s2paHnbZxDPJLRlikKEhwhX3H4/4UYKr4oVanZ9IpodpgIPDVBKbd5kpggeIy3S8tyasB vUF8OWFrtP6e6Bn5BFtl8/x4LKyvrnVcjSIwgo/9W6CznXfN4RTJaaoF1QbZyjpVnK0pqAgyfbR/ rPb7kB8L2sU5BbkDCQkdBUdmoszr03xhl2PiVIDm7Pd4uY9YI5sC5KyUYDd3ay+6BScMYN2bgDV+ WneBTQI0csWb23/amEkZzAKBnZh+PkzcE/R3NyXpCOkZ8I+or+8XWR/HpD5F/+xuIe9Z5xyNWzwZ TBVamllMNHkibJ6Pczc48WzbYsngnMh811S3Se8EYWy/aqiPDzd1/g9OgwxZA20tbc/Ue8LF/mq7 VNjiCwoXhWLZkaf1p0C83FfQvWV0lnkKvfQeXZxWlt+qrm49HxuiwkNCAiv1tAAmCCw9gevOUPHd e3p3GiqYnHjTe7j8fliViktxPX9fLShOABjYtWGsK074zI+Zq9fx8cdpYFxgKvuXSUp+/5sbFtc8 p1RVJoKBE2zXDhUdPCHusvkOXaXe9Q78J/Ns5T5hoCQ8AZJNekqo2x7e/5kXM7WCOFVbHF7deof4 f+vizohtoE0ba/FeS2st0XyscDiUP1X6Fe5JGQ1UpJ23XAr3v074HDRA/Ilf9hcEOz6v33af39+z bmL+l32414x1mb4UeeBXCHxmVSU/Jeqi6KlyfT8bN0tK/RbfNp1cSoznXao5HKJcgE8VGZz3o0jf 3AtX/fD6+9p7jUoFejw5/5Y415aZ/s3xYqVlEpwaVQ8WrGwz37D19OpmjEIRL1XsDEh3ncTSb1/F tuIsZf3/3Y5Og33qcmRlOVkdfT3dVuVLmNa09S10wH2wncc8zhwhfKFwl30loSz+95YekZpmFL11 0yfUdotpd8GdXX9IjZx6YfQ+y0mWvRzHdl2jInHxFqJXm/Q0t1Zy5aMXtJ93MF1+sbgsN8YGmHxx Qtsu0dyiMJDrGpT9M9h3eE1UPG2hEbMASmrt+RGUl3MAuB3VgNMq/xoS/yxAHtoOfDg8ReM4jXmY XHnQdLYipXdYZ0Ml0Y7dIu40ek25nFucKQgV9ViJOhVRjT+l0j6KQlZwhurwAF5qshjhbfiVU1+d nQYmigKZH0BZtVu8HVRgPsvtMKd9CnVj3N1Gqx1pLm59tPVSWEj5JPZz3e85k2OoPRLG9PyZtpGj vBN6Zez/ms2CwJbS22szqZ47HgoJimbsvtM0h95vje8+C5+ceiF26V5fTjLiChk8Os29lVCUDSUx uNkfehesfth2THxtLBCkEKktl1hx/40Pu1rQv/B2QYSRT/UZlpedLVtf5/k90E1vhYadjeEH4Dev Pjyfnq+ipovMiNXrfeBVHLCxw3KMAYBG5Rb9Rr+xfUWx24cnennqXrFtDLhY+JjRXh3UZY0olacD vNP+BUw9bhoCnp30DXb/y8ZgeYQWoF2VmdlL1Nd0l/2FZS8/Opg//GwgmZSvgLugGdkZ52EWpraH 396fhbzUhn0o5366wmLUi2NsHA+QOwQlA6yOmRZZ4xUVOEA/0BY2rW8rfMASFdYIrolh2rkAHV0/ vpkLmhBo0UplBLK/2N6GMPmSjZ32ZzGnWmpyPXNBOA7YnHYKqPqfOvazRCP/irxrmpArmb/cLes1 f5bEJ61uZlK3noGfzXicEU8QjPoWHGeL9P1VV0CL2Pv1nvjfCin+Hp7a0ha1bStlwn0lGqbPnd2v quJstUX3CxGUFSGCCtXcNDd7eezCjXyKQjcMX76UNs9y1woUSu9pbLJgESL/Nemenf/6SX3fFQMX qWgdU71/wj4aOPW6X1fJ3f9XX16X/BidHXw/KnPe9AF5fBAsUk6sBJC4+JVmabPnRaL5i6U6Eq+I MQIRq1+VYml9SD4+S3H6hkmaGNDc523XHFMC9mz9ZXK2YDhM5Vj5qTI+2U+ML3gxhDIQWt4ADW/1 udUwsx+UVJ31dEgW+rw9o/QkNOz43m3ytKI0FQXSXI+ZeJy56/ieHFDZ1WVQiEk4vniKPvik2D8e 7PimzHX1047cKdv6qt3tuT0sUOCDPiZoFYWC/k+VzTctsWdWaCPhUBE9Dq/OKtC9n0sqHrhvBUrd jR0+KXkIhfzlv9n8+Rs+Xb8tXP69fsgcINKU1uZYc3retp2MR+tO3Uflh/FizfVMVIr8p58oHpGg GOYnmgsI/MxdogV92vi8BNVNqHJUwDoC0z+Dt0L9fajVXbflX2znjP4UdpHKfD7tO/m4I12JRjWR 9+Tgt/8S6ZRCAGe6HRdFzTvsXWDNaPwuY+NN5tsAQiiqMqMml7dintX3+2IX6f0cw76vYtd51iBF d9qvu/SSWv1jPXQ9kC3yuqo9EuUBT45DmQGF8BSjGRxin963aOJtWplefvNMOedFINO1/ny+Qp9T VXrVAqxlLJaFW2OUYX5cLy69ZzLNiHkeAczrfBZfdCglfJikfdaF/uUikgrMPfl24kL1gP4MUkZQ r/5k+J6e8kTndvP9Hh2VExAUBKbkE0H+DTrAT5HAT3fXIuQ5I/nvwPxpVfEDSaT0CVxZGu7efj7c csLXXNQ1jM1AvLxyvrv5d/qWHp58K1Q1V/+SCRqLXgl9lBzlR6GkWyNhDKN5dgX/7rXG50E8PUrF TaIO7LX0tb3yb+WcbIMYEyXfV5jHhtJeRtBR/gpj6Mp2uQSaqFwHMFTMiLwf/rX5oJmZ6d99wEEM kFrjMtf31JXUdxyd0jMreoSBshhbGjRCOT2X/H+mrqt1AxkROCJtwOyeo5Y1MfSPCqkpEZxxl8wQ 1K/G9RFgN1Cjnkr0o7A6N6p9LJ8CVtck2hpN+jz8jUz16mfENPWg5ix/BuBeXO08dmXXFQM+emYv wj/l965OniwMfcwIrvXosH7E5imhBQ+fZrjdWB0Mrmy5RP2kncD9t3sTlACdbo5sbis5nB0yXH3G VkeFb8aIGyiwZy/OdBF0nxz1TAD2n6/KHSodpIjA0YLCVTa2NojhoGTSnlT+0PP2XSSf0F21nQLY RbVquJLdR5JAT7LUmCL4okS+CsgENcNn/By0Z/44Iy7dtBzXxXVAbZIqUR/3vTgWVj21wY1KuN89 N748yoScW4UyGpnue/EONb3c2Rp51HDtp/Ew+tuQ3VNdNXJP8P1o5wupNvH68VQ8lxzb9xtLP6uN B1rkfXWeqvfspxLmQ0bEVdl7jpI3RVcAng0vjTXrnQLy7vpwQHq2aLIfLH2PumRLFX4fcE/WEpqd 6p2919vSexkUHa+6PzIGKimo47yU3ni0DxPu6tFccfEJpUA9Rg3sFig454JysvVVMhgIOk/c+/Sw /wsRE4IFHcBW7FlkO127NljvfX7+lZZ/abY+A872t/xQZTGMu9Y/HI6hXYdh4OIZ7SATRZw89Pr/ NXnhSpm1FVkda6e8gvYuUBVVWTpBEncQjbGnCD/JCFznnZ1Reqc0uKMGX9wmEZSfhzInwE40GQIU Fxcak9h7SPrF2oQpuUTWYRcjrkvFdTBUsdf2kQHappxvEhd46Y2f8MBOSZSIwBi/JpseG/B8NLZG 1d7ftrN45sAwwFSRqqOi9w1ViZkg45npW6ysOMBiHUvruTuap6t6c4/MhWJR+OjvFayeSxh9lpWZ S/9G/l1urbwnXzwTWRl9Zfz4U+hm3nrEMCaz9WAhSWiUiBiHPmx/P/7pDsIWiSOCXfUiFxGFdLCV EC2X21uFeqLB9riTx6X7ApcV6qV790+A++xTx0WML7QXjRAdNFV761l3JiLuG/7PFPC6v52/c/0w O91H+uxcbJ0dY/2BchwSnYn9frlxnR3f/dlz/j/9gR3epY62WJ0sR/Wdv70zK3283oVdJZc9vKU9 AKpNmhwOnZ2sn3s9vHGd3XtsPHx5XOX9u3xzvfh6NIW8Wx2cPxTAeg0djggdupNSd9qZU2R9nJGc AFy3G2AQ34icVMbIzfSYBtcKKuN/4OEETO311BqeFN4DnPwGgkO2GTnnsSz+UHt1jjWN0imLaRZ4 AnS5kmYuXVqWVKkAIgM9IOEChWw6j/x4tlztXPxQwXIb15xHcD5U5JZw/2pL/w4PkP6zP1OyzRTn BXubEeqMgm+BjZ1v6cq9NNp+lmzZXaljQljZwbLAv28Tu2DtoF6nNP+rJHRlywiI2Kz1OBf4LbUx n/8DTR5+3L5doVBg/IPPm370NF8BcFe9vSALHpb/gvdDYuYYJcHK2aZrKLbZjjnru1M/nRtZVMKC k/81npceJqJ5D5b4Y7vdYkQxaQgCFHL1v/CfHvc3Mp1XTSjt6GmgOaSfZd9rcF6FnIWHflq553om zkCyMyZcSZ3UEGbAE2sBfOR+kYL0VvM3oXu0UNd3Lz6/JjrcdLe6+VVlTfeyYIxtFAzdvL7x/4hp OkHcgBctPXbnDSlfOWl47rwvWWlcGc3fcdV1lGIztf3vwS4VlP2amjdTLW/jADnafP9dfKO9s3ze ZoMUXj+b/2a8ehAPjYlafNxsfS6yox7zzp9SffyBS4itlrl9Y9pnng1SiGiWc/17rZmCwUoUBXC9 X42nIkLSfZ90YiyIvTdQdM9Zc5qS816TKkTm0Q2SXHVsy9/+XCTiXN/A3DQJhQgdvDNyPaB44fyp unWe1iWQvYp4W+rg5XsA/fhSnemk3Bl+trj7Z5mGYvXL09+ymr9YMwJ14hqArEk1n9h+DYrt4UwC 3HxyZjL/6PQC58ViPKC9AKNd+rtu32ubvwjUv30IVNRlXpqdBBcUt34ijE1ufP+Rb8/7qQ5ZPUw+ 7vlUf0sVLDX2NZiCOKrinmbsIPQ0WPST9AuFf5DbA4y3noKU7evBuc0DHSJTfvnjFOo4s/09+zqL HOH5ilwwflxpk3TToi0/NUTdc5YDQNJfOJwsxxqi0xTOaFj159v43XKyA4LWl0weHR3L2OwvchVu txKeSBCZ/BgqferYIdogv7+4Y9Pn4LR3Np0pkD9jWsuMzUjs35fmskOg+lT4g3g94Be9zFl07SYX ep+b/7hqtKQfdUMpupLYQjG/KqqfmninqS8s8WOs23pIrIrSTX8RGLjVShL81f33H/zveFk6JH/u n6K+Gu9cDp7aj03wpKl0HAk00v9VePJst79TB5hr1Ln3LCobrQI918nlx4Bd61VhmTQl1biXuByd tYpNMeyFcwLef0kg3fBkSvwSx9wSX8dkFZ+03vTYQ/xLJJUKVDnZe0E492KpN520PWt+POweWT7y 9xWSX2h4rm0p1sJ/h7V2yK/nvfj3n5d56Z+OiO2vlKovAo/pGXX4llWXpdB+7Nt0ljWr9bulOFLV oX61A/wMVzB9kAGchfmfETyw7d+NPJdAgh9fulUzcMQXzxmfjf1tl/L5/wQ/Owq/usHj/JPzNLwx lNYstbAHPtSWNLT7t4VZTRT7NPk+7TTQ9R+aMiG14bMcVHPu8OB1u+AHiP87IpXOv78S9Hv/TBZM 9YL4gpVskXW9i56leTd4J+E1zGjsMQqcwAIeXvVQhXU5NrS8tPZ//1ZsQbGbb0gXIuU2e/wg8SET i1jbT+GTy2Z6s3VaDQcNtM/huhLnejqC3VkI83y3Nzcg3Vo3/0BLLJuTrQQdedzNPgB1zcGUNKAn tR8YTmpWH3y8bNwx48Tt8jVUflj9vD01QprbXtyrsRSycqxWhCM8Gzw4hif9hUS8khzo4vxSqqJD KBQ4yUy0csVzNsPUpVFTPdSRiw4avuLFNQho+PU8x+peKDHVlD0b14lFHAT0M3RNwtm/0gqcTwoF lE+dwTC5aHBdrq+8gpN8Off9OKe7F86EvvkdgAX0cz1T9suVgV4b7fkS1dz9XY5MURQCVM3WAxD5 WJdKndU917q7G7Xn1Zh2npKiOYLseQCWn73nW7Tn7za90TaxHmqelQBPcOkPUOkg//k3T71fxTk0 kao+/iFaKqBV6PKY0nvLWBkWKEUfXTgKZXynmY2KespHzZy43G0Qnff0p8I/dzenLQmNdPz82eH0 F0vrFGnBFxl21wnVtkYRa/pZWoJcwv0Jd5yZWVYa7DP/v54fEsQHpa2WNye1j7xtTjKCUsUvhOKH cDA4I7cHEZACuR8nDegMsH2cem4JNPNfOt2UPempNHzd4NME5xQ5rO1TPZfC7O43MUbge7OZnPQ3 4B0+MC4YXCzuggtzzJVd/xAecFpWuf/fsTJUfBcb2Ax6b5y8nHMugWWnj9JBedITvbseGMI0DSTC lf1NJqbbLZAn+jN04l0toc4/rTwP15SeMGgQAocZRXw+vd95cY0z7N9cDsYTVv2wrPGEuhn+Pb/0 +WlfK1fFEn6LPNEzRBhADTQpFoAdqCocPXFsIB/nHIJwjUVN0BkyQg302S6C3O8fZns2O49NFP88 pm1W9P+/qXwPq/nyHbwScoODcc27sQqJ3J570rvddCCXiOiGHD3zveLfSIyoiVw0gvkQL12mzExs DOYnh2TMjGzM5GWlSqyMbMzqa6tSrIxszOhpqU65mW7M7m+0TvT1ddX1ejQ7eFn4auxy1fZ3PbxE Qga8bVD0jeQdM98yWJy6IwpZfPg8TWIfc+DYCQWjefgQnEym6jq9tCWFXYIaMLxf4j9rQzVa+D8H LX2z933Fr+5eVb6eHV/zojyXA4bfpqaXaWLobs0xoRErUPf+tgLxAIErt/aG9y3cd69evZF5EaCs X60sHGzAbf084QCDoIZY7jd1bEIJ2QQtR/v+E33qDgYjUxzQ5z111x+yw/KmZZwQH9B93AqGYS3V S5Bu60j9pts8wZ3u9ENaJXDdrOV3Gri94kvpRSJ0kBvMGA0TCiDgoowSOtkTu1VdDP16ZRM9Gjxg v73f8PKanrPD54SUX/IG2aX+Y/WEWZwcKzmgHAtEmhCY/vPH4GORfBcO12NoGT+IFB9or9Vz3qFv tMxE8Ke+pHYd7a6rH8t3ETRfHZgYGC1p25urXkY9+Fu6qKodzQia4BjmfgmVUe2O1HKTSnZ6DLSN S7Pfdd+XfbUTuOZc/dzdTl4r0n1WfUnQrjjTfVIZi8TENqHYeeL4mV61S8E15z70UPzNqBqIQN40 lxvXJYWTepG8VLhl3T0O2NEpfrlYEQO/S74XHPxr1D39mh3EQU2L4/0cZH2+sSj7p4NNcmQHjRwN 2QUcCKZNlrXhX5/d86uaKzpdPL25yY51PB0rNyBqXk6DkQJW6B7Ux/p3laU/nJ7EhcMzW3lHa149 0LnHI6kJbfAAFwkGVsrWhZQyBh2ivlO0nQMLYP5A7N99+7fCSN0afV5dFmzjAAAlaPBAa10svEPq VyCpwM3mKiOzvJpjfG2mXABs3lhJ6MbJqg1kmK0ol6cZVlada/tHENCAFQMt9Z3NVF83apQ9qXGy scaeqZIXubrSgrXPQamy0hZ1dfWgdwX+JLNV+vkFr/JTE7LMcNEvd14E9Voqe/2rub41Io19v8// 2AuGf/e7TKV9/x9Ahm4AT/XcrQBdWlO122xV3356FYgTWQJFKtoAj5i27o8MIb9+oUvz6+dznVP9 Z52zP6p7eess361bVYEcAkztudpdm4QFyEwEcvqFtfRUpXQACek0Hy11xDGiIrRkfJj5juMBy3BA CPSe/E3L4SC8CF9Ux3uzHozVwh5sTqEmskOnS0rdOWSzVfqkrSx5leO3YCjte9ID4npbWCRaKesb Khsb/MEaykFVJ12Wn2Xc0KtneQWRWDMW0gbCy6LGwB1YNF17tEIyNMAY5tsCmpQ/c/VsGj2HL3DT 8zN6zJ8t/pV3H2Xbfjbwehwnufz9ZwB3ZSkilh+aoVrNhwh36xgzPQY4ij2FCJWAP73i+VgMkUwM eizKEWkfEBmZLAQA8cUor36CiB5hpXlcWpEtbZE9kekxer3P/ouLsZ1G17zqi9V83nTtgMjaLFp7 6KHqpqjtfV38yAR+xVglG7Vg95d2eAv9Q/ilcApUegO2yh1N/LSeXMZ8wtdbmbae1RllHFBxlQtd BxojIG6K6+wJTFGTSV7kbY55rbqbqYzisEUixr41CcQtccEg102ilvPd0NQ2bc6dgbzNX7ZnEaSx OKo16bZIgUjYn6pzVo3iMsITXMbwddZTgz/VFOCLvJzTwFyy15N6clNV2EJy1JpyuDBoLJ7DYvdg dR6e+FWWvsW2eFzSy58t/LzCEtk1PkmZw4IrPeJZG2JC2yMdpVqHuS5pss1C+tmrfAIQ0HGiLflT nqlrwuUb2+FbMBQ5w3lfW9iT49xHISCRtgYYYlNnLukFXtDhnmRb7HbdQoqkJ9YFhUWTYoU5WAen K//GbF593sp1UMTWUHG481rCkG916F5udqjehoQSt3T/bjAg5z35saK70QGjjZi07Rm9YxOSSvNo e+0yrf4C42Uweq7NbhDAyy1zl6vD0PjOBGbHY/HqoaYjrNO+ctmA4M0MlD9jk7jMRDxULv3/KkLk 5PV/Y0vdtrqiC9H82q3cYNjSoOxqOEPTGS40IxG0bdXGvR1v3D26a/ZXGmV9GsDzGeq1UEzkBny6 WR/sA7lgEAJbH10k3pPAuxo85xVdJj16PBPp5x3ihRGQKZrNQflT1XXTf33zU7NyHJPcfRwzXN2z /b4Tneo7k/sAn+X9fZ4yHL3S0g566srdPP9HFAALttOdoEkv8DgNVxa6RnMjmpVaDagFrPMkypIE U79aJE/Wpr3vIXwt4WEjHZwgx9tKcJJ+uqNT+pgz+HkTPcvo6NLdtPUr3o5V1z8D3BQmuvlX/hpK 5kKUleZuFDOnuBOOm5zTHr2I9VLoz/KZ1jvfnqe+oAOAPBbVYByeVsetPFfCwzpyuffcJmHjtjL9 oJ5xJCYlXfTkFxIR/SAD/cBch2ccAcIIcvGUcwAHL5HZklFieYbs9UPPdJfiXg4abm9XGRs2WVri Enkw50hzIthZDKA7LhsSUzPc2HQZ+C8c0t1xArQdQeYgx2NV/fwT/wYMzT51XF0RzjLyo4ydfeDb rJ1/Qmbc+CRHvt+8fugc/Xtiv/DnMQZRYz3c+n2RYjBBqPetuGmJyWQL0GwW8j6i4yCHOU5qdZmX tFpXGJrH9y+LPXKsijPVPG3/GVNrwiNCMC9q/WP6YIA6hbVjU/zyk0JSHWWiBwoc8e16g5NZX9l7 GmXXJJ2ytx5M3og/CDoikHbbj5MtXzkmtf8All/ndbgYiii3/HWclfkR9FHvFvwGnEJvvFJGAscn MWAns9yHMQjiulITvtc/ew2+b6ihq/EfQd1rLFy7zzcvgoNbfuodk8AS3wIzE5CCPb3ubFsJXVVy x039xbvUdTpSlvZmJdh+s/nyvY2HKon22cKb/XltWh3dsA1NGAOixL3/Qs0HlcSvf50fZ7oTeq34 Rm1zAJ9Bcng+ACZElH2d9cB/XpRGxQdhwhx4/BWCWSZmJmeNn1yNR5/m2WaRZq+TfAf91CARM9z4 pXsYeuQLmZswVXIDl5JiQnuyVXSTOdKaSR4X2nNH/YH3kyeySXt8WIEwq3KUjQzANc9ai3DVH3Ca XR/CVxpg0H/StZdSHKHRmxmUvwHRlJtJA1vsIql+32IfxP8acWgEnYG8V0QT7cv+EhjVSGKbc1+C ntHi7dSnPhCWVINX+Z/ilrVVSrfjtBfyMcLWxItf6BSmovKmPtv/evIvdLJKP7N8ahz0q92ev3uR nxK0DTsiEjwrUB1O8LN3sFLAef96HI7uQNcarP0aaOq9dcGl+gA7XROkMVgBBxHBBQFwkSzZ+CbS t/Bd9b3Md19IxLw+Mje2gXYlVvnGijklMtw1wtWSc0oorz81EqfyU+vsQLAbQmzdrYV4WUu7oEIP L6qqPTXgxJ6cEBtkUgp9D2NVvsl4XVteDON3Qky+UR420x1vHDss1xeZcG124DG/M1wwC52QbtCF 1IbgbClRVpmjpR3u65BtU/xjYtyjYk1WKnR4+4hAIvt8LxjmsEMe2eJU9n2yUJoN7r28/1NN5haF mM8C1kCc2sgnixbfxltybNfFid14KZvXQbBkr33w9qIGM7x3y/jG3Unhkjyzytlwm14RhpX9vX09 30GSuBzBAI38hUxWv/U4ThEKMvLiWS+0M/ycbpEpHBewuw2aI3F/EV8RGWBzEiIDtrNBihnPIxft BiCEmdylb2CMgnygrX4bL5Am2OkSvzspUJOy10CqUKZvj9tCG7Mw4Y07ZEs17apg3ReTuxICfVCz WB/Bg4d3uLld3nNfvfMhDYtnumI+rfbbIgWrohsVOZ1tjX+W2jv/U+UYFvq/o26hZNNf3Hwa3Ub3 hJB8BqEZ7f5w8xtTTf244fEjYOrc1XeLft8Qr6S69FJAHDoIL+qmDksi6ebJ7VrAB/o/WApTGIBC mWX+o9J3pd43FD+ZJRf/vRk9vIqcvxc4n75cYrJnLvywmfPXZv2cfOXOyIN12umCR8yjRy3ulXgM vZpeOl0/Qsomg3UgQxA9GpovzN7GuS2YbFX9HxT5SndjF9L/CPs6i78q5xyYXEVNPdxg+dC9iItt kvq7sx88OFQTdOCTfTIsAX4TjNxTnTgNFkvz4M9Nc+lqEIzFxQ5dr7BdV/LwqFzWSVZNZJE6nBcA Y/jNn/te7Ly3CvTsZaewOfv8S9+2JcOqhOapg5GW81uecSqGDexan4UNLjS80xaq+WSSxh9mbRKi EQYGxoJ93HlAgtecM75WFEmZhp1hFXVa1l2ve7OoW9RWHWPJm346StC+eSFX6VLqPW8EbN83FB4c 8bDpHn3xp2W+tNSaPiWz3urLnWgSovi+3GZusGpw+KL01LTf0zNcRvXL5F3qnT69TnydHBAoePs+ 0nMbsHfjHyYlw1A9sNe8X5pmMVUVqxGw+dRzhO7CiEqPxMJgWgrWTQrjtJMQ2tDP7lohHOjV3FkF j2iyv/XaBhDd60QDvV3jRz5q/d7YukWcmRfKfiVc0gLmQXb8wLIUONrybQsXhsXZG+B7G5wFSwZO +av5fD3nDcLH6zTH+Pm4hmybDqUNNpuZKZSdcE7o1Q9TnqxUgZhdkhzcBb36QrBsaYlxXPpej5Uy SatS2GlJs5d54U82TjBb8/WBnaDAWf7CGwS31to8nd8ifvq+q3lfvUhirLwdUOK5jj8pjX0vp9av VtWUfjQsyGRDvyQpiSxfF/1xTR2KVwwSOItC6o2G4tGRejNuH71i4HYfsUM5n3ccXBnk4hDjN9Wt 6vx6QnLnYB0jNdWs+Rd8ysbG9TLV3ezzfCJcC0pldS1lnvR2deoSsXVzfYJnDt2fdfUiNMl0crdI ZD3aFb/zVV0kayIN/pe1tVdaYxxX1TvWOYtud5Q43r/fXLefvLqIf+q9C2q2YnS0Mg/AxIMfT91C YgBJvSdT2t8mPJcAjW8W7PWcHtVQ/TycbaBRaR6xZsX6Q/OxFPSsHgYUtIWyUYRcz2+9O9T8U3XX UEW7+/V0evWUd1T0x/D/2Hg885uEJwukxYAu4N1KHeg7x+2YcHLel7x4kjiKtSVvC/782xe6YQcL G93fP3wuNbNLoXCf6PuDmD1qLKIa/hP9/A/wnNM5q5P3oYW0+dpVhpxcDrtjyFiaGedMGt1g6BMr f9JsOHWnsvebFVD5J+JuDyErEj1GlkRcANQ5PhAHnKwSfVr264reINxmtP00Jhm2Gpf9zGqSUIf/ EXTGsaC+xj8Nv7Ec95IIKMRiOxA+evvmlsuOcv2c8FSr59N9fX3mKB7yWIak0GgF6fXjx70dTUV9 60Kf1xa5vExb8kAFg7H9JnzT+PYGQhDdKIfmPeecBpmmQIBI9Pme8AcuSySuZl3eOzIHl0nOO4oS rVZZ0Z1QK4T3A7pNkKI1tigQ1s66RVrSAqjPgqOFyqwoE9X7NxN16Um18gj12DeOMNpwziDQTNu/ 9G0M/UWBxS6q8vV+FReNEa/eKf7ybTyIn6q7tHaJd010qAQ9VOsQLchdXLQr1fqN4qAc4T/Gqp26 Co7hBu/UrMCcezdzsP//8xCvQvRIeHg7Zx6ZGZv9juFo27YrMBOZGepxalFSoYazHLZ7rWzl/M3n luj+dC2lq570kQxvAgMSOfxMzLUxnzd9IX7c/x1W1oUSdwVo58lQsjIPMVOYzvSpUG6/8xIKYLny +SyRHGJtOxAJdmtSVT1dOD/RxGoDRDg1cxXRmpMvicfkK8UbxGQp1dGd9eMrB+8i4VQwqJ1e6jz5 qTThZmPbSmDiKeDr/WVpDCyd8VyhdsvJOM8zwTOc8biLr7V+v+7iwzJrFfBMN8wX8p1fshWNLjEK HjL1IOl+V4m4BB8COCzHoH1MFBgEiGi5O3jVs+A6+CbyNeXynYeEZjr7x31ABmR5dRtzjvpEenK7 DcSNxHO0GXTaZBQLmmY2OoEr7dpFLeWFTYhZxleaI/0aE3DZcDM9vwKZTl2OhC6dNJjf4ORdCHo4 Z0Vdm7kipR7uBm9/V8K5ZJBL8VqDNq8TC3sCjC5Cv9H5PZlZCtUeG7ezQO1lKL31NAcHpnrCvym/ 8FzvIw38AevetY8SqrOxhRm0N5NlWgZqlG0nI9z7ZzVDj10aN9sFg6YN3HnWf9RSXDgkndUQeh83 eXBOhn9QYHBmHa54u+2ImEokCos/y/jR/gCIPE17ipRcVOMN4Xn8ExOmw3x5ZL3UzNV7mL+SrpQi s5pcPWANppjp1ZrYx8sZX3RSqMpX0VNcG9RqAfdrKq5dvQXrYLikD+wXBTO1891iB+x6W+XwBfBr sIbk211psBuo8Vf5NySvw+qd1m0jIz0zvT0zteVYd9hrRx8+IBMDMPey7x4Uz3BXbtVpiOuueIlx PSMabov/mUjq15xJeVS7Udc4lX94M7b8W33dokv9mvTOyNdXOCrcJ3zczPin4aAc7A+K94D6FTcA abdd7TYgptJt0OR+PWjQTyART+C0+w4SjBid9Ik3Fifylo8Gc2Kpoti6dHjbjZF/4h6NsDyS2Jx9 vFU5rPkQ0c2/LlilKlR/sPuUcEvqnETSY2UKnxwRskhdAnFU/Q0XB5oTO2qD+Ic0Kc+7s6frv2OA 678d/KbUhGLzdjPfxHN7mwr98/t5Xp3dO4PqEfJ0r91Cf3UVPqqA1Gu1XsvS0gDE/XNtgBOIURc9 ShdfoJe9zH3/1pmzuy+TlqklpZ7fHQRi6pAYwQi/cwLUFhwM2dzzCMB9fXZw0l6MPjy4nPO5f5oN TRPX8xdPHxFLfTZl8lwlR+py/Rb6UtivcCDtMX0g7elf/c5USlLdiOE+FQActB4KW4vYtDkTAOtZ HBKg0PoQ6L8wc9tHinO8/CzrMQ4d9B6fTjG7nOoBoVmSlufAxE2QmLxl9UzEwQESaOhtDQGpkSti CsG/vEQsckbVpsnNvAOh33q+woBlnB7Gf/x8JKyNvykIQ9WMmrE1JUH9UxMYAhSgVvuSe/5M1Ry7 dZnzloJY3J7XVXdHj4PmLJC1/FzpHU/9bIZO95cXf8ZAEe52n+T8Qx/30bg8V1e9Yv+LNNg9dsv9 iCTMi0t245yqzTUdOtfF341AqEHSLHWVcij1GTH11BjOfHzhrJn7xCuLBkSePUMsU9wQxpWlcb97 Bl+b/kOzhqLNXLMT3T9zkJZsqbZJiya49FV0Mf/C0st6ukX2EBB8IAVR3XDXoKcdB4VVfj185RSS XL4MGRLfd/Ao2ZKTzp6DjVuU43HFVxoNVwnt3YTlrLAsfpl2qh8qkStpXcH34jBY6Tz9S1qeCTyB ErFChoKmfWe9YEwdrRcDDBfB3yA3amd3at0DF0q9wDJboG9aTbz3nD0BkVGJaL7J6oez4mteybpi nvRmfvSUaSzPXx3WQ5j4fTkiygLyUg7sRZZ3O/89Q8TNKMLIvbjQj1bJgh9zbHYcKpBNr+6KNo3F 873YgmsWuSS8Nga56avwOzU7+Qq/EHofX/FWWHE9x59+JsacQRo8mfxzXDqc3Vjk+Z+RNUQoe/3e A2Wn7/CeluYQadQUrciCzv9kuTm8rh1E+od8DblicbrJjB+Yz5wiCmdh2ZXe5Q0X2z0MMTy1/z3n IJbzYBNEynd3jjqfeujMNX1E+3LFKpfpV2RvPfXVv+LEPqqw3MAhKSR5VQwhosVzXZaaPXKaR0EX TGwq4+YLZGhRBy+ac138VOKcyRNa1KHLhzt0Mx4Y87fIGR8RwezIkFoZWb11mDlb2Q0+adwN7Bna Fr6rf7X6BhkpVmqwJywczW4I2dKfzF0PUmQnEuP9R5/KXBDwJQuZXhW+LVTz1F2Serh2efnTuQxN cZfyILnSGLK9cxhXmTCTERz9YBySMOAV6P/6vv9gpvQp/I+QUfJ51JNLu+aT1vNen/hbajv84ODd VN0lUOy4gWUWQadjOa5dHJ0DRTfUlEearH4S8t16mYdX67fOw3kYNu2iS4Zg/Gq3XXcs/fo3H0F/ 9DRwro9maXXZkoW3Nwy5VQKuN+dmMj+8G5LGYnV9ktJbgphqrDULn3KC2jqycD89ZYW0ZP3KqNBW O+p3C2PsJnreYPqzaiUllJyzKyk9MTen5vdJawo+nCORDFz8lyX/HJG9Q1oltQx6sX0PAN3Lmcb+ PdDzzO37Hd4rp/7/QKvXsPB682dtilheVefByT8LCDicOBapl2ctMbzivmKehvuG9XWRHokYvjbf PfauNwFMQxx5J7FX/Sp+5jCrZ5Xj0ZxMeysK9b0vzlbFiaoLHHlXS13AovXer/nrUXn+OV2Bzpz9 6Jc6KKgBi7U1+FKdl45yaUM7/DVHPN0cOgxtKwq2Wax+vUhzBx4DQdkRPVvzCsig+daDKJQGyH1a 3JKHV/k/bnNcoLocX1KbGplzWEyGe4Lw+eam/3YSKp2V9sInh17aVQtyS0YdQrQiVxLeAjey5V6Z ycVmKhre3rNe9eZQ1+vH1JeQcSu9zGi+NWZSmPYZPoFGxzf02IQX/2B5nNKvDRdszJyHgCF6/O1E pt7X4j4ah4lD/HQN/n//BzS/L4bOwWccHb5BkG2E1vb2XSO8/ZQwwtTR3LVPVP2n1FvRXN91DTzG HCbQUO1+M5BfkJy07B+df5sCCjj03F0/9BYwy/bVk2QWuttCkV8FQoJP11dHlua5fsWQe8Y7kTI4 nZeWWROYNiRHXYGLfh65PmDJ4fslXjD8/cpeBZjiPNbTJlLA1JTM3ND+ZZJKnm0g0BfIndcVSOuE e+aQdOJdfXR9TCbm0CFdYrlgt5iyXPqoHRHBiVZygJ8AW2L8BzdW4P5O/rW1bQHpsZDn1eAd9MUU lZD7nJBsfBrvamKKMXc1+JAnDR6CFv2qJjE58wtB2os36jtVAz0Sw1bsGMo1lX9D55iefD0wPB13 tw0rcG7OPhXgt1Kvve9uXQMWf6S/M2XGPl19/RPL0BkQSd5XK0WFOSb7oty5cneB9TGOH1a+PWuk e5Wjnc2pVZQsuTR0aVTuzVyEbCl3WiNdND6/m22bePusuTyY44p/Kt5AB7LBeTaVH5agGHXXg5/t lN511X8Fx3cGRKdffSP3l5o2GUmFS449UGbclFAVAnYMIYEDnj4bGOWdlCy0FIBX7u2OJjhe56xb GDYzfhUaRqR9/feGW9Q3l2eeLKLbHGCb3Wvq1/fr55pzXHQDEQmts4S9yXG10ZK9wKQYvtwkExy+ GrTi/UCb8655cuL6fZz69x2OceoRfZ917vx6jTduSgiAWeWfF3waY97/lsd6foU7dUz9mz9mXBON qmq9tRjcos4Q4g9iE17Vz/C/Sp97Qh3R9ys6On0fBqsZAU48POiprVkXOal1fcbddDAo9ji4KTX6 sJJDXqbDsppYk73HgjTucmkXmoAcRCmb6W32i/waIuryzCRizLWLrLdsrYj+Bbf2Lcw2wbctpZhm bkA69awmzfa9LOd6YsILpZ2donJmXewGUkEc6sbdvKxnUkqdRGxeDVRC7aSKQT38Joa/bBJEKLoS YVp7S9aCU/b9YikWQ0LzFvpEU/Gax9OR+rLK2KKLgCJLED5zjI3EF9bNPN+6nII1+rkg8rykFd5i x/UQ0LVIFdbonu12h/17rH1lPdWUjkd7fznle8Nnmw7JPV19cx+4TNmd8hHbTc0cuuZmP4wkJ0qA hj/z47AhF11GQKSMF3sXD0QrPiAGIASSJ6DvMMO6s32R/EIDvGVKow5sFB1at78z9Uv0jEUfa1Dl sdyCBaIpzJwETxBznM6gHb6lBt9ast+WgKBgc+PdEm7/W5n/a7VVhboV7F0srS3MLLJ1qNRkmvWX 7MhsMKREDILDAf+rKXMB9iCAP4BWzctZlhueV1p6G08/gj+udM5G1XUA+KrgwxtDT4YQnYJ3/uJC Fdd9vDIAERi5OLt6CWf95gnekz979PjvHYHpF8vI2D5tBTMDUyNEHb2cpT2zAxzFxcpii0A5bkq6 wlWL3QhiC1vnbryp7r3Pk11lIfGTU/cdlBrd+U5vRFr5Hdle/f81dvR7vd1iFeN99WCucBQ7oZxm qtzqM8v7R+kcjuz8TYRF4THwPLD2nBfU+3mOj/wUGx/YXv/qrvB0f/yfXXXDnycOkOyVYKH/BoT/ x2AAGsVtH/zKPYtffDnu7wRoaP/pbx5sDvA0O1F+NnTelDPLe4d6Ptrevr+TS/vD9eN+NYBEnuVk pUFxa9mobKJt0Pv5Tm9CEReCNPkCam7QlJ79EcL15pEnDhCMdeal0WqJ+cs5ifvObRx8EoFCkrZs +hUVVVV19TUVVNT0lDT0tEI70fyXN/q3F5YWcTFx8RExYoKiwvGRMPCQcJBwMFAz0/OTM/OzUzLY +Js7+7tbO/u7+PiCnjXwq1rVV5VmCtXVBttQN/ryyDI9hx+qOv+F+emg0GN+3Q9/F2PiRfI/WZ9w +btc4D+9VuB7MO89Hn7mZYwe8j2GF2fucZYdWtG/Mq3ZfmDhnUrsZM3c7+hR/XM4AVijZq8w7YEG 4sXLN5/Fcvy57HmaAi0iHWjyci1Ld/ruAiIq/15oMddffUiuE72xiMcuB/GXz7YNv7xiIqJCCZM1 3l1qT50V8cvmRcWx94c/T0JZwp8eCZAVX52urlcQAkKCnBVDbK0v8ZdGwhxcDpCaNnfhhH89cOl/ HmhTwmeCAlQ8HKpMdrhRaeYGZ/nUxTQ5OgLCbRddUOICJqJuRYVmsTZnVceDNN98yNB0P/yLL9M9 cAnnZgJ6S8Kf7eNVvFdCLm62/ViJhwcP83dCAsIGJHy9qVB0XYLqatZ8cAlPh8UcXCgz9pZciy+2 9dHrw0Luaxy9yFP1fhzPjnUc9gimDF9cIyKDwavbnasu9twYO5RH1e4iUx15vJhKwsLCX1wpUHp+ vE7uvbhQqiemZXkWR1c8mJocHEqCHM4CJFbfNsgF9Vz/6Fz8767UnfBIxqGi2EWf/R3oMtZfH0tE N382aETkBQJD0n+9CTY2XllqbvouKCdGxLJfhxdOlNMi8pU/v7zTTmVEJ9F2zxcsQB987pJgv4Ki V379QUVCWHHr5mQHERRmEaNWvCnwtOL44uJ9tCGkVX1wqWbnBxl3Jvd/CxBW/X1qzBN9ENgMwAOJ x+aGx0Kc+RxqL7HAZ9LLAG0ksanRVZ6uKjckxSQR9xLbtcLkv49gmKHU3Uodc+gH5gXjn2oSod/f sDX+dFpXNduDDOMyQsIQW28ifThLf3/oUDVe/GkKFL8xLp44oiIn52fQP2Z0vFwoMDdW3TgWrgcT E+Im3lPeSNF1Y8luFf9QqcjPs9cC9iIwKRxru11ivU5s972RRYccP85WNT656K/6Axzk5VzwYSfm qm10piJ+9nccP4mzVX6fb8/X/fCAJsS0wypAV9ncKu2kECsvx8bwtO827DyhthB0//8o/R3vb5f+ kTZh40ICq1/JUCI9XWpOtDXQiKZKT3C0HF8tQILCNr15Caw0vFZoz0dHECKOF5/jYKKiY3fdcACH 3FzJMRd/Oa5sVXzxyKSuh/FZSkLALlyJjPd8UAjThh8cabEWFetvlXyRxsxH/BqqBtOc9ULbXYdn sKIdfzyIEPR/mAx2P+YHY4hAJ0Zu3xcdLg83/opHwsqQZXgCX7VVd2HEcx3x6EcGJ5BhLHDjVs9X bcN/T5btB7b/YpLiotLGqsfR1+bXR+AYfZwfy5N3OB0IDoJk66JapZa/XmhRlhzZyZA8MN8jA0up VmRzdgYW7gNjuwaKQsI8fU4TdFhfS24XHdPKlsY/n+5TVD9LzsKCu1A00cnE9t/eKZE1313rj1Od MOieOoQT/wGDeH1fuEJl2v4KV58f6/h1tqtKFh5Rid7C8iqZPxyouFp9/WJON34RK+be81WGEuN1 T9fPIyercTY9maqt0fs+1GxAR2bF++bIqnAJe9LxZwfkkd1QVb+8D3/ecyYje+hI1yH+LHV/U7sy 6DjUx4Zwl9d/6BE0dVJPV4F9XqXc0bgifPfs1YMeF+9tl73RYOaEWVCMKur3y5M16qwVvjBrvBJC g5jzguzESHO/qBHVPRnpnGNuAW+2vB8kGhSf3MNL/2cpsLRUyE533HHJOX+IXrK7QjbV/dxLpFdD qcbn/89gm9wcwgJifn3cH9dJZF48iCr9fFwp8DYcHY/POr3wMBDWsv6yuPXd9gw3kXxQMutyHumQ dX8r+M3c3go8Ew9/2JDIZjAuyfFKnJ15Onexk5EOafEMieoEJme7hEngkPyeW3V0Z1vU9nOsSSvE 74Hnm+aDcL2eGXFuyZG6lLFzLWmxjslOCGXnIBRHu+Tzgny5+1RxezTnG5PsieqEkU5hR6HT/X7Y uilR7on3kfIPyJST0W4KBwCTnV6Y+xQHG7XX8fKMhlt0xwkFh2EDmYxQYlYqK/0lPaKdt2e2twyH YuIsuLMCHcJ9/X18/Lz8XEKeXD3L9oI//x+/n36ePr4/6qJCPt7+nhk5GZnZWZlZONj4mDj4vlc/ yvqaOvp6Gho6EXbdiJkj9raW9pbR3HeCgjLxsVIykhKScrJtbW1tDe2tTSzM7Iws7L1CKc3sjzv7 k9FW0HMHZirLfjLY+1u70wBJLHDC4ERY8lu6CXMRmPgRGYZ5bDHdQNZCmXZ6+HY7VuIunwZknOaT Y56Te7S3zBTRzO1VGz5L2uNiUMLSXZy+qlxCi73kPuvi1GKDAKJ3ETGzPtAT8DHzyd5xFlBHcz4x 8f6zM53iAkAQ/vE91dRXPrBwMXF4vNx8uTWUlTOlH1h0Iugiv2j6Zrd7/04gvjwCpUq8jlqUkrgE P54cvfkPbPy9q2p2xwCosLxC+f0djLyHPDXwAdp7miuwVlqDM7d9RoK02PNxkzN3fUz4O59joB3S fvhMVlP2n4Nq9uii5xzZLLFsYNGa+Hk5ARini0mxPOo48dnSQhymas+IWXz3FZrXtZUPMpQdI3kU f6RY0zEwsHRd88+xG3Zfbb2fEBURAIWWenciKQUY3FeFDcXC7reOpbl+Yox26ThG6k+a1h5j9f/y 3fequja9xmss0dJhgnNX6gvtzjrgXAzWnU4VRONrhn1tgr7c1ILb4lypmgQpU3jzspEGDl2qyfA1 czcnO71YMOaA6IsY+zqEktzbDYvmM2b8G159tML80/EKv8GWvcR7FoTLl16XH4ga8qR7nhWpWJ0u 3sx0Q/5RnLzNfv9+K2KLQQ8CqI4fs3b1rsakeER+HazCGEGi1ExqjzV6hIJ/JDmxyi4x5S0om2gq 75XOcs9/DxnRig4xLDOT/3M//JAuELbs1UbGPM1w5V6yIh3pn99bm6McZ+P0edQb2vFi4RMd2P+4 lh+2Y9P9n/cCguJRnGXjtGEgIpVhM50BBEf6Cp0B0/2qG+kps/0B0zgMz3k74iIKABJR/h1zG51H E/K+c+vGAqv5/7/2qyzZMPO6YpUUIkLH/wm6zZ6+id/o9xTfHStaQmbfCZViELiU3JJKft7ToMfJ cbI/HGB5trJnnf/+//EcuFV0gWhr9RsGAhcXvK0W/w+uZSrYYvcZcj3eo6ekNJi3epM6OlEYoJLg 7JwuHqx5tDG8AiD1VaJlPPoaAoV5p9vxsv+uNEjnhntFU8qIYMvxinCxnc+8P9zDHD1m9edbBJ4f dFsxi45Uh/wzytnMJonB/hegoe1d1CiC9QxStTdo5hO/pPrkEluqTz38/XT4/9dsTGt2SMllZ/T8 uyvJv2w6313xIAKlQJ7UMZjzjdnKMzRS/aKOKvAQBZ9lP27OOnzdXojkzXIfQlktUpztL370mvzf UZHH0nkjn767IAgCaTvMcVyBm6oQnTMO9TuFSde2yfjC1YyKv81/zJuZTp3MUw1VN8TdA2v5cIgi ewNEGKXyGPVtfPwSJvrckX9s74ecsy3wKFJXG+ZS8JjedniGdhN985BFPnHjIq7BnxEd3cIJZyl5 U6DBf2L/16Bm2nrqyX1kmxNamsqseIaTu4xbeLbt8pc7eR/MPV7u2J88psQ+39MA9FGgesfyT8Wd P9MUJhipLbswbWN3VwQF7H9Tv0fTfXmiErzYWSSJEM13hCrVXQLTGVOYzpDShv0GtyKE87xmuxFm XcFGGc67X8N3DufvAzusgUvgCrF2PIAUeQvDVP1T6hD0itnbyQyAmfPcrmLGBqa253bEYZY4PMt1 lSgM7beZ+X6Xf1FpzVI0no1ivatQ7wEZ3pu1gT80f+kAChHSxlwWv9G9MbX8Xa/QstQx01zTcEQC UREQ8Bh9Hp3d8PGdPH8UEHDc0sZiKsIzEXPQ8v2QUNHQsfGc3TCDTMDrkz/yvHPwMzCduQjYQ0Mz 8dFTEPHTgJ1sLLLTMZCx8PAxez4SvHPgU5x2kJbTs/CRzILQbbGxUvnR85BRE7kR9hSLsd/Q3VT9 KnEoUREyQB4oKsB2Otw8um6L+h0Ob6KE1ToFyeFKnZ5QnZHXk4uRTn45O7RaWaK6uOZ79sHdpMWr 2vqd8PAIxvV6EDT6IgXQ0hVwsHD1c5x6PReQ+jvx0aK94tWRSpBC6NONMbDWM5E3m/NRSr23/kB+ xjDRuRet8VATs3s5AheHxl/nmZ+zd9dV1Ds7isgKYBoiLz0wkTAR8LPsSx2TkELsrigEXcv/j56Q kHPKAmvKNpTXN3XX93v3XdEzcTB8Ipb33bYCE3GTUpNQYiy5iNnFsBbpLh62sfHTVZbxsZEzJX06 V1McDsLikWY9GC1YT3jOeIgYCxiqWIS4p3ihQoKi0mDYY5jdWHlYGBgaGHWY9xj22LGYE9iymMx4 DziOuHYigqIrOOrYRNhHeIY44NjDmH3bnHi/e/nau7sbNUIiwsK7lPuW21F4UHtSey07DDhPO864 KVgKOGc7AzvCm92bPlWioiJbGltWW3FbkvuPW67b6VtI+4hbK9tre2ov4uKCQvvlm8VbZFuE+4db 5/uGW+H7glv8+77beXsYWxp7NXsiYkKiFJvW+9FbcFszu7L7jPuP+y57Sbvp+8v7Snsle4Yb4Tui 4uKCQHsDm91bfFu+21kbeBt4Gxq7FbvXG/ZbMxtNG6wbC7v6nFICZxtbG5cbAoJ8UQ6pqz0iouAH RKqJsS6J6A+Mc/bPqTEOFJp7Phziwrt0BxsABqTF6IdbdEcvLXNWFIGHW/Sa+J79wqLuiXGuw2GH 5UupkY6Jca/S8HbUqTEuyVobfvwiFEe7ZIJgpkUoz/KbVOebcbTVe5mRTnTHH4LiAyFkyfGOaWVr zg/NjonR7vMWlPVbvpuUk3E9o8Lg4SdHm7SHJOqprNL0h1t00BcVGL687onxGINiocelKzEOKbFJ DHNx9Ee2j8lbnj3jA4a0R5u0ZOsp7FLQ+5TnG5Z0tdj+kU5hxx2DYKdkSqmx7ikJD43w1o+J0W4V m3m/IsOAm5Tnm+cFq8nsh1t0RzMx9Bp4aXE49J58IyKhhw9J8Y7qi2mvkhHWrmmRdLteHGMjp5vU R4YkS+7slIdb9JP2FZueXG9pUTgjY0Gkiw7RLklxzBIQFjRzsY7J2vj+HGCCtCcbFACGBIqITnt0 RzssclA3tedbdEe72X8cQmlxLuEAAIZk68ivKREODo9ysJEX0a5pkXo4ud+d59uESeKAYyGGh5SH e5QFCw4PsrD7lOeb8Zd0NbvxWHRHOL7fYCLgSdHuaaEHhOXLj4nR7mkvLHKTULGu6XG2Vxt5n6c7 L0l83YBjAIbUJxuUhGWrSS7M+5Rnu9JwkXe051t0xxobGJlfaXE49Byd4ALAhg5Jcc6H5QsOTLOR jgkRkXe62Zzn25RTYEKhROqLlEfb9OkOjO0zUHt0x5txt1WbOZFOdMef/QAAJ2TJ8Y5pausOjDIu idHu8Rea+F68m5QHluGC4YflK0d79Idpr00TUHRnO3TWFBqZn11vadEYgWMhp4oL0S4JEYnuDJIQ SbGOSXbXlfrYlJPRbpl+vMEDQYT7lOeby2mPcrHnW3RHNDr4Hn9pcTh03YJhoAcqD0nxDsjubLOR F9Gu6XG1Wxl+nKc7JMnCYQEHa2l0Z1tU7JJwt/pYb2FHOz58QaOBBHFuyZHqiO4MM2mxjkn2FJr4 3pSH1u98osFjoaflu5Sn2+vujPOWh1t0Rze6WJ/9iZFOYUGjRoRqyK4pUW5OLDLxV7qbjwmR+B+d ZqEkx5tU54oIDgxydGc7dNAWlPo4X25pSzs95oDmR6WRzslximipT62pMS5J8JZ1ux40h9tvnGaj QSbF6Nv0x3sOj20ysOdbdEe2VBV72YmRWHRcvcbjJiUOSfGOK4lsM3G3kY4JEZR7OD+c59uU00YC 4yFHa3QnG3Rpz41zUdf4lOeberlfHaYDcW5JMSHnhGrLqTEuSe6MbbMRL4nRbhSa+JncJiKbFAcb gGYHhesnW3RHL63T8Vd0Zzv0lPqbeRxmbmlRLqPGZUkvspGOifGQd7pZv6c7JMlCh6DhR2V0Z1vU a4lvrPJQe3THm3a31fv4MVh0R77cYocDxwlx7olkKqtJTq+pMY5srVMWNBrbr2mR+B4dh+Nm59t0 h2WIj+3wlIdbdFY1OP/9546J8Q4AB4opT62Rjonxk3Y0O57n24TJXQdg5uSKlIf7NOivMnAXVW90 xxsYnnyng6HR7mkxp8ppDzJpsY7J0XeV+NmUh9ZvnvwHgoBGZJsUZ9uKaCkvbWc7dEczsdd1e2lr O3RZPKJHQKfuifEOBEpoTmyykY6J8RAWFJUbU7GOyVmfPOIEIHSnexSBZ8Rqq6n7lOcbjmytUxCH W3THFpR6u7npkVj0HAKE48GGD0nxDgSFa6mPEtGuaZHwlvcVO2e2j0n4n30kg4a0Rxt0ZKrobkzS +5Tnm3CxVJo7kVh0R7lfnCQDwAlx7gmGJAWILi+J0W4Mk3G1mxjbpOlxvlyEouCGhxuUZ0RrTq2z 9IdbdFE3tVo72e+Ja7tfBGJghkWx7umR6ojuDTNpsY7JVpU7eL6Uh9vvfCSiwQRKaLt0Z3tPLTN3 1TFYdEc5v0IEAMYJce6JZGpoz9KOidFukfcaGF68m5QHlmWiQIcqiEd79IfuDBIQdnRnO3RXtdp4 ubzuieub4gUABkSlkc5JkStubNO2qTEuSfSb+R+idEe75GWgQYfFq+mb1GebbzKz0fSLW3RHO7nf fSWj6VHuiWEk6qhvzqkxDg2Qdjp7vpuEifGcfaVAAYeHGxSHhWiuzNP0h1v0kHe1WD7c7oHnG51i pUDBJ1FuSTGlSwhvjakxLklw1xWaODST0e55PyLlI0GG+5TnG2XqCI7sJ1t0R7PR9/X7iYtb9Jl/ vcUgJ87p8Y7lSmlObLORjgmRcbRamF8nu5TTyuLhBGtpdCebNG9tUzHXtfiUZzu72H4dygNxbkmx QYSqaS9psY7JTRDxtnXEqTGOezm8QioAAVt0xxsG5Kqo7odbdMeN8xYXemlrO/SYf71KQ6buifEO hCWLaW6skY4JkW0ysFa0qTEuSXrYnn9dlOfbZAoCgGFHxeublOcbjmwzMXRnO3RHu1mevKLpkU7h CoPhB8SLjsnx7ohurFLQMTGOifGW9BoYPme7j8nfYgqARmS0J5t0CgiPbVPR+5Rnu9d1GxmfkU5h x53qgOakqylR7knuj/IQ1o+J0W6Uezk/XUugu3QHGwaFCAmOh1t0xwwSkPb1iYtb9BseHAvCgM7p 8Q6GZKpLzi0xjgkRE5B2NFUzsY5Je9kfgkuA9Mf79Idli4mPUnt0Rzsx9Jv5n5FOYccdCwOABkep sW7JZYhvshAuidHu9hUaGF6/m5STcaJLgCZkC0ebtAdpb9IQdnRnO3TUGph+XMLuifEYC4NhJ2Wr kQ6p0WmP7RMxabGOydf1erkeNIfbbxyLY6DmRGq7dGf7ieyN85CEW3THFpR7uZzJ8U7hCwOG6siP jsmxboxzMTc1u5aOiXE5Pvyd6EOnm1RnwIEGBGV0Zzv0CwgPkpBWe3RHu9R7GZ/9MU5pywiC4AYk aqmRTmnJj+2TMC+J0e72FxqZv0K7tGeWaCAn5YuOR3u0Zw0TkfT6iYtb9Jn/HQjDgc7pca7EKojv TbORjgkRERQaGT9nu4RJfcgDgEdkdGfbNGpoTqzzUXt0x5v3lfie/TFOaUsoIOcFKW6pkc7JbZB3 tRs0k9HueLnc6IJBh/uU5xtlaE4ssudbdMcQlvQae2FnO3RZPjxiCENvaVGuwWdEa4hOsa7pcaxS EXSapzYvSXjeHQljZpRHmzTqyWyTkFZ7dMebdzq4XwKRTmnLCQMGByVrqZFOaUgvLPLQjonR7na3 1Xtev5uUExECiWOhxApHm7RHCG5s0/GUh1v0l/oYn13J7onxjuAGhStJrpGOifENExGXFUe2j0n7 Hh8JYmCURxv0JoTqiI5Mc3RHO7JRl7r4mUt61If/nMHyycHd0WqP9+WVaQg9bk2p0U4J8xaVe/nR qSuT+onjHF3CN+0XYukyKeGcWNNQMDFQEJNYWmdQopAw8HOYMfORPRGRWLMzVTPREGCyH3BcUdBw l9Hx1lbwcFzAZLSGfPMC3LhRsQvjBfvNEJkQMRMT37Uy7mlLf9HTXP/w/x/GBHCG2Vh3sNhQc8KR MHDi0WKTYMY2k7W4cZCQXJ8YgtGiaKcRsDFR2FETWfHTsVNQczhLcQmzsjZxMqobp2QIxJ6x0RHQ kLOxw4OR8hDz9rMw0+nR8TAycXbT9yfSMMeRfBUX2DH2r8+ioDrR8NNTmpD40bBR6fomdlBmeDmw M+bi/jOwcTH/JyoW84W2thAzu5o2hwYuiUu/vRP98/EOykqn+vbcHHHvVkBllib24f6xhJ1Xxq7E 69glbsb40vGUEyCj8CtYnPHwjTGCc1NOipFgMTCEvp/c/TOnDhDT0dMYvHF1aCbYlnwIs3OIUf/2 fkBY6JST1NHQ/ZNnj3E/eLNTTaSxUPUw1lOcTzRMZ+60/7fhXraEZzDgEHNRC9x0ELDRUaZt5xls 3Nxxs9Y8bZc+9bw/MzsXxhWBgxqXUYeQEMaQODyacdfxHocm/vQ/HbM3KTcs8FCW9NFZt9wXpR7s GqiKPzaF30c4v9RUiZYHPsOnWnPTq4tMLtpW8H/lkQt2zKT53Hr9cxFuEBDn8lSYkzv/LAdxZlGk E3MbDStLwCsxZFl5vvDxpK1w9AWzkzq8vHx1SnkE+4kus9uWRRG5M/QcEX2tAvQXPBMzuD12HBB+ PSLGxMvljW+gOlAkBKYUrY0qkSjT1rkbgFBcUzOVk/A9s1hdNTjA3EjQB9m8EFEuCHZ4VJkH8AQ8 LiTbZr7MUXmPsj1I2HCxMZ/aB5Oa+nYQbNEc8fiOKvR2EvF9FCXLkLctNbGevxCjjLzVoNvcD78Y jkptH3npRh4cpA3/nJKNMZ1BrUF2Qx9e0zPMEzVI00jMUxG8nS2qU/DxcwnAMzDLESUfk98u8ROw ceLu8jNz02n/2J17QvxQUXDCMNY1/YnddO0tHpDSPmfERtFRPN70GFgxnRBj0+4hmIoQfxPcWnx3 nRwd2l1NepxA2P+xzQFY5oXy/d+TM3bcUqvA8jac3BBLZdapZ2zQ5vQ8KHOqHUut1trkMBFfoHg+ lnBQPFERkxel1qhOUfEwWDygdtjHpykxOdx/t2pYO/ZzGOjejvOnmzMTqrbc6Xw3pFCvk1McybXd lEBdH3MQN1PLtixvfjy8EH3q34v4c3n6y5WY0m05n7HkNm8O2z92Hw1pFDjokPHlPKlTMnMks4Q3 7Ah1fzA9DC1banE5ZQrNH6Tr/XFxMh6T7/1nERdLUzCbrIi2TY/pYhsdFTEThGzHfEQk1IeDe+VU avZMvzFpPKHoEK8vzFn903q1GVKPH9AQtJym0TRqEZHR8lXx/rRZNDiV5C1WthFE1b9xXJlay81S ct9/ZPmo0Uf4frfuOIDNzZx+JF4HZcp/k98FbfpOqDV/XBCwkBYrZHSqHhzx83m/SSX+cR+jVhj7 GH5/ub21eP2oVNpWNCybXI0s1pDTQ1gAa0jrkIzR8//GclW+EfjEyzwl9g0/xzNYUBp8ulSr2xvi eP55QHG82AqRXL5+jTN5D35HiTBk3MQruHXLkfh2U2bJAYkH43oV3NlX2mReyCjtzG9kmXV2m85m z5S5Ilj8ZdwzM5MxEPFDvByYb2lUqBL8Ns2WrMfc2EjfEZCug29KTvHo+X9YpIt+GPfRWlBFX5ye SVP+X5z4hAo3nHCSSBheiKxfEQux138LtKkFG7J8c60eC5s8nxZFjqhxFHFN1DwbF5WQsXRYQeoQ FvEcDWyQsJOk/9fNX3aci41dtBjgwlOPbOjLN2n5UaQTr9mS/3C/g3+TkvfkXGr88PCPvAS2y9LK FhxzvdMgvJFNzNeQJUxHh82UwTwFZDOhMKzMV3gwN9bwKevvjjxPVfGNO1bQR7yS/nZoh1G/WJwG 2XzmdpwieFExm6eg/kkS+LoQMlqzWLYFpT9q/B8RcSjj9blCWbn3lHGnucfBkLWxsAZfkZKPEtzw kNvR0g0l9ia8XeXfkbG+hoKYO/DzQL0QYA1WAcEd8Wi9MEFOhRAd0VcHiX0BbaS1Qn+xXPCNKbR5 /WeHUc0CT+Qwccq/141nXTdx5/yI5t0nSN7zgfy0ONGLkNAQ6zmeWbHtxNzJXTMfpF81xN//C93Y PNyyXCV2pftdR14YpJ11ZZVe7id0qaa6osPfa039Ft9xaVCqE9nW08/R83ATh0ekeeH4HG98HO1Q m90+nFIx2RFNUsrfp9/StjyxVEFn+U+bkFNUkjyjT2IfMHYXMB9YxDPb6TyLyvAVHmVZlbzvcxi5 /C9IXFzRdgSfPR/oBp/hEdmwcXTccbHrnX0GIJM2mD+HXtvxTDzu+9xx1MUzcxm4IDM1sj37mjF2 IKuWg2ZwqZW9iD/VK2EOvUo82FGHbDy/PHoQs1K4V/BQaUFTnMXezVMGqKtRErkTkZ9z4VoSXDvc hlN9jYvYN/9cnDB6U7iGsrDTInAZmc/W/eFQfWqqsiWf/1FEfDGOxx5hRzMeXPGOnKeS2zJ+cbQR EDlXlxEiEfNRC/nOX6/RMBOC39HK0R/+XNnREN8EfBnW/SCdSPeM8rdOTtB7bB/+kVplId14XD9f 5b13UGmfWvBvl35yKOMy3GkWM0PVyMFZZJwSiy5gdg7nGNHb0n7flucpUjmgVtFRh1mDkWzUlBwe vDnQC0axUH97dzqUN/MkX9Sdnj/xGM9OqBmQRzNRn17kmfBtg9xQnU8QRPsw0Zk8cXAx6LyNcwnQ YoeNVZ0rXPGHxdMp7XEXXpLGINW42ZIc/HCHU/6SR58QMHrfudeYCOf9//7Nj9hQ3/DXSX8qEWFc lze4uuXoMd7YGLHZDzJ6S7gwt9gmpx40uP3WJzBeOfLoPzy50IUtUpac8TE/kcSUwTGTnJg38epW 8zzSmTwIvU4LXOd+UPy0XJicm1NI8OL58h0DYIYTFm2UWEZwdRAfbDcQRd57ETeL0vHlfPwK4djd Dv9cX+4fZ9ipsP/cUW2xCn32EGqj0x+Wazksf1f5cVar76lhYFP/+VueXfy/Ex+t0tho3rrTU6Rm qNcQRNruTyvmBVFSFtPdA7q2rKmI9mdAX7Pxie9TnNM/mC+vG6OEyr92cKmZVQtvw79vn2CPHLzt TFjkgh3dDjW8rBnt7IpfHMrUHGiLHNFQ/l/6F/iZth3TrGnnIHTe4hgXKnR4+3GS7o1su+ka9gXk Qv4t9tw06acR85FW0C48r/GWXJEgHgFB7B8ccvHROVAH2I8+ddByr3Z/lMXTRNxjdqDQFHzTYbBo J3vWYDwpTfez9QAc47BIO8kGfJFztroxjpDZSlp4bdznq+AKmyWRf8yuFQJwYno0y22UDGzf0DHv V5XQZWZ80t+PhhMylH2xv6yoPA2b33vwk50ygMrbXHBt4bBiMzze11OWPRN0XBxx3fxObiZE/D56 T2QGPUCavEZWK6jjERDrEPMwaPgVwfzTmbw/v4ZlGxNGHNihu7hq3sZZc3Go2noYk8/DtctzHtbM vrGC0DdFkk7fH823lecfFP57SvELfFx6u1GPcRoT8Bf/Vch7DFQ/WPSYapmAnPXy+we+8nyRcKt8 MVG0Uxl9s838kTDEaI6QqHORVv6PDRNeRarTFXdrlrHLKFX0DYQW6fXh3Nt1GEE00dPQl/bp8Xd9 fKZoEV480fzM/VFgPR4wPL1GAZaUDVbedvAs+g8MiUSTKiyE0mf8Otm8eTYr/2tCXTibXxJf3G8x Jy3Z/1JxKimRP1HaL82ejydNai2x2J6rmh3nL7mseY2qP9G+dZeI+ylfv6Sz1MQdKdTuytNWpzq4 sAow8xpcjPi+WiDQSvkPPEXw5TPP5TZB8TAOc9yMQatktgMwvHNLK7EwB/+B9Bwu0BwkOCTfUZvc t9ts/B8Qezfncyb8GLihcJCWHEsMsd//1I0v9zFX0+bc9QkMSpYZbFN5Muc/pt8qEixK9v/q/hIe BL6830iik1+FEbxRnEXdVPYMcbEZNEnS+EKrKRcyJf78Ad73xbiWW1/FMaBw1d42eFBc2EacluHl /EwFGf8YyH84lz9R1lWbljlcSPi2akr8M168fZCmwit/0n2ZDT0pUva30Q2Y20D01tsfnp9aiGax EO+/XGZMmp+bFalZCDpcXHbrGqemX/HyUZaMltLQ3aF0nU2d7mv4ZWOfxJF47r8F8B8bEQTUUJNs zRdXvsoxubz2/APrns9W1WdUG/+ONGThgS2QRP+7d2WoXzg7uioUB3rJOUqEorDzs1DzHEmEhHqG hBACgFwp8JHG81Z/eDaw3kvaHlfeuEKY1WhxrzuWEiQe/4vJegpB2vBc949pNH4Yk9bWcITt+LqR XV0fENbA9OfE01M8y5BtW3IxqEf/hBX7z6jz8P8GC9G0r//ra5FKcT6v0fNR/qBzXNazX+xQMdD7 XfD/nfV8nXY3FNaRMXhdJP9LvLC8UH9qDs8pe6/+U13/jVAShw037RZl6hZRH5PNl8yfCxhvxddC 1DOFcj8I3Ght6Oqz3V8KBqtPzNefntCen8Robc5xHvgZCzC1sgkwfVAzK6hnYlbc2FPlKwshVt7R 0fqTOJxnC1UxZdP/kWfptnGSn1y38l6X1WftHnM7yUuhcUv/s/6cmdG5aX+4qN6VbNXF3Dy0xyq8 uXf2O+KNp5x9/bfTJYW/UKyK4bfTp6+qE8LQg9Pd6HaXZBDJ17odjgD88NyzNsloJtC9TTyQELfW NEsiT5zEp3M1euRqkPFms1/Nlgt4EN+4H5mWPA1HUDHexWrsOlAw2MaRvJhItdQMWJPqFYW9mBEy vNNYaJhQwrdCcxkGropWMxo2NVyxhkzNQqM//StxfQI8M+Xc/3/Txdyva+aHRLNkH8WwU3ywLD6u sf2NXlIAbnFcHGdXVBAtzSVKlcqobEgNmT/xV/HYnufx/fARP5MbJ83NqxFfcRAfkX8imnid/bex Ze7iO8p/n2ZT/DYsrrMx56kHz1aR/bE2m2X6y2GzE3N9ptyTwMUakuOzTtDZq79oO1vA0UfqHQ3Q buJK0LA7Xd+lnIVtiiecyoeq99vkGIx9cfHx6nHwA5XteHdTMIw/iDlHv4gWELBpmxxoR53Rxi/u ixEVn/jsQ/khf1GRMnxc/S7iqZbiuVC7lVcCUVDzfG23y7He3ebd8d7x6//QP0ogjE213wBRgvQ1 YV8axRUrKPh/nLrRJdF48BH+v+wZVQNd/G2NGgaRscJfTwuGaokQjV933Ihpf7VxcOGvvQyqO0yj SCsXq341P8eW6+9U3v9UqDZVfX0xJjzT3LtfmzHfVg1S3/VYW9KRjLuypNyjX28kX6vUVD8PmPiV a0n/b/VeaIjxnkPR8Ur99Qgc7KYhHcWxlhwWCQ3VvKCwVreOP9jk4hf4nucraHNanPEBd1C9pR7d +I00jn3SphFI89jlRZwRMXjvKPDI3QiTf3AcUe9l6wZxFPCWVtOmzfpCdviuplPtEQJGv9EGqXm9 avOQSpy+HWg6zP3FRfI7ZwwX7R90MRAzNBUuoB/XEcSoveiXSm9q+QvcUeJrTY0sq94RDP41ZNTq /9SYBnU3c3+xl6FZzDtWXmszzdw46AoNF53/8O8cP2t8/vGe0fgQnh192/B/WW3pCPXcWGESd489 AhW5mDNTMbjQxv0lRE9/0d5GooVFsN/x25lcwb01d9ufWXH5H1O9aXdR0xr47SWxSERR3mYIVKDZ 3jkTdH9MuCGT2tMxD1AEv7gx8aSRiF7P1nhc3h0DKyCRk3wFcbz46PWUSxGb1BCEn0lxXluKkHwf UW80dByRSMpuaQp9Utyekzz+V0B8Tkj/E3Lu0NRRPNFYu9vlb/INGzE8OTNoNVzJPvrcb3ao7+ns f9LQ76ifxjxgUDjhpIWqUPF0QZFBxR9XEBwRy+Bxj9V+chYQEdnolVhrM6LIMj9kfBA+XlixBMfM MPAcU7AYMtXNRXlwvnxl3UWUjZebxNQYGpiX5vjr2Rt2P9NwfDEcDBL2EFHRMbQPLNGWiML/Mzud mV8xPJvWEyj3EDCCu7Grf/2cEK1gHEhSXH55Pa+SS/F8ExxxUbq9+FbYx1AV+nmyUHNR+HAx7x2h MHhQUbCwTBFpVhEgwKsBkclx+mecUZPR7ZncB3xxZ4mpFWeRV3FbrNJyXAtNMUgKEhyIMOXvsxGm 9f1ijyy/MfkJaN/cXeDn+FZ7Z8uHUBZcmOF/7Nb7nNYfkfdpOfMfFpl8yJW2tMHZbzwt9lxBVOsW rWnfRNab6boSmVHQN8TR6WKA1OXb6OQVOrDrgViLPYRUDH6QURaVSjx3Potc1CcRz5I18QK8hV5s XFGWsBAfJ6s5Z1xNF+C4+Doc4oi0sQ1RCdCqwA31Ttxx6/y/NKr/wEqwTQtIJttY8UqxCq90hF9N fHjnUfWHQP98S5ed1l0cQ//xpZU9A6MfbA1Y7dO/IvhNpw9zn9yHvreL+k3ffClM/NZcmoT/6xG/ gTBrEaknW9nNG/CQU474n9xeV0u/3ekP3bn/MHXcsR+N1WVNbdrE3wNoAyzN7nmcnLnlSnaifCcc eAAq3/HP67cdefDwicL+27Lx/uMGFCc08CtfnwUZElk5cL7fh2ixul/g39JyjbCJWHMp7ZXymdnW ZizR+L+l1n8JTBJXXOOx/dSPP/Vfh82xwXHy/vOr/7+LWj6QEVVZ3jUe2DxEzqiZLz9dU+JBEXlW kPETPK82589iP7lRQJZPPIWfgHFQ0S+WtuhE12itpHkpgQP/WRz//LlIcb8qXJAQe9QUEE89JWwf TLZUl4U8RcE/SsJ1BfwK6B+sjZRbSPFxMCWuNn1RMDl8FHwMovaHWcyxyt6USJeUYu4HGT8xzCHR 23WlxL0K2Ch7OjizZ1EcU/EQ3YpyF37cSLiM3XC8GPeer8KzPHrZvbhyNybIOPv8JFZr+NffAKrB sarZFdhxU3MxnXSRPRtxr6wrOVjIH8FNVjUH8r+WYnAhOcJ2+cNpcdY2HeROXF8fR9ix+L5/n1aR PZ6f31yZsfQTf1wTfs7T3xBQKB8QMPEClIjQ0/7QDjt3k1AXX/gfyD2Rvwr2NyX1l6//FFKMn8ss cUaTDayGj3kfUJ/H0TBL2MtYfjF/cFxRWixdMwV2umlEk4UchTgPdSS1z8vMtiCX3z3v6lXzaf8d nZJkVQod5Fab7S7+CjR3mD10L9rzxb/d0hX4EX663IhWM5BxHGjkPKaWe1je/nF8PDHwJdab3Vto UKCt2BfO+fgX8vy0ejrSvb7QRQ7Reg/WGbAQtrB02E7mmoUbl70fHTbB2MHWszw/kDNYcTE41b3C /N/7gNqK7EDLWmh1/pKz8n8qtWilQlFx8x5U8PcQ/I+kMZrAnLxYhEVt+NAf/RY1jicencHRk4oY OVeaCbGQb0d2XmvHkB79aX3X1rD6dhyOMUmHPAd4X9MRxSqGXFjlPd54OtiVliem29D+Xniw+Nzx GePvt873H/w8tbj+tvFykuQkTbj707W9RqWyFW5yvIDxTeHVg47ngfdAAulk/JgOFvzYK9nQEZOn /CYzfmvxlM1Ymp9YIXR7jLw+cBG0MNDdGV3m3EDtDSlLM9Nf2hB3GHE5v16+WL7ykbNsBgUwXdPp 39r/YXFU+hFzZZCELg99zLh0sqhwvdlTs1yvcZvfqvx0HDz8AXAHwLgc2JbQPdsJnlgQPCKoX+pR yFzvnl82d2zRf/wRnln+F35caAHlNdxWaGbOHbNje9f0EB47nxAU2nQUhy5max8RU72VagcLf6C8 uEobD2bWEVRvNQXci3KlM1qnsu6GE/iY9Fj7JjhvCalbPx9o0qhtNFNqPHFx+i1+uazOt3728Kd0 ChhOUazINF9ZZJ0z9w9qrQ9RfhpXfPeIH/xtMT00nbRCcN/wL03sHxl8XI29KBFyHB77tOq7DZ7Q UT62j5xY2idTjVtf8z5fbHiwlwn73M+5XDz3/lSMfOiZVyWSn2HvJP7Wf+2eNYufqN96sLjFGqt4 ZLekER5fEfyI1OOyJxXSX+ly/69U6V7fhobvzREcdNyDKUc7C9zctzEBPXYX0dxUTXHMWhhPVicr GdV/7p//DlUHWdpc6HXUah9irlLN7e9T2XlC1BGNn53EOr7BUc/FkZFHTVmIMTk/EzCv1X4eG9/q 9agNEG25xFobJJ/+/1F5ulzxmNhJ7enz8GKcETR36pFwPAo8kB6ch5zOUW84kuUOfCmcHjV62BX4 E+ocXNJg+lFuGPopQY/9WFxxS/Wj+j1v37zwNoGu07tfFmyE6L/7MfyltqFlpLfdp444bp+cnHz2 DaB1hdM44KjCsHjfTZIRvXV9Twgf8tgdWjrkOsjV8B1G/9ZfjJBWOKt/PJ0Xn3/a3NjB0TxQ0b8w tOble7Wzo/+q9gt5/XPlGBOb9i9GnzfWaI1PvNjLuWP9OBAbcNZx0fE4kd858dCy2vZtvSwb5jDe YA1JnF08BxUf3Bf7H/O/EgyJzeDzYxI7TtoLX41vHd+YUuv/2dF0eHYnyNO8RMXciLF4H/juRax/ s7HRHEuRc+Er3fFOX1HzjSKYqvF2ePdEnJFFP5Z2GGs/aRR2WK9RZwzV6COg/9GK1FaZ+bpbT6S5 vMO+kujRFTasW6DKGXc+H/ifl3n2K/8Mvc6In/jcwdSdEQvMRX/d8WT8OPdQlZX8a5zVjS9XJdYt c4ssUxbctFMxHeUqMTSxlMavjqQRwqD8UFEIhmVCFlXc2rnnVexP8u0Hx9hiv3ZcJoRRK2ccObHQ M0nY8Bt79dhxbn3K8jDaE7zL7PoJkzbfW9iO3JjNtN9FZva8sXyesDzQbmW8/F7WXhFRD51MGQ1s SE0SPQ1VMBXqtE9jP1CLHz2HWIB7nKlxTBYYj5RCv/OfDPn9Pu8cRNDeGh4WfFwY/aS2kEpc1zY9 Q43jFfztW/GFrGPqSm1eRzdtOpS8vHPa0Vw4cG8q14Uq3xEROFYQazHNkd8VmpwF8b/1947nRSwu XBh8/wB5ALxRpwXluOKdU47ht2mxcp9Dk5GbNBxzV/8Uays4dSUNyh93pux3UtxR8VIX57AckzA4 4q67T+9IYzPAjGfpW9wm3cVeppwmcDFc9xzDd9N1EXwk3f2mb2vx7flWXrQNexjWyowetkJ48Vnu v4rcfWscST/RKZ6ex3j7n7ropXAcEwl4TDuJRehBLBhJ13Zonb7IFdZwElafiZxULW6IeXIfU604 Vh1s/2ycPbfJqKDfTZW7XlYwczA+FZeUo5zT0STzGrhIZyJBPxPwXd5kPNkw/UtyL2g8yA/cMEi8 5ROF6P+uUf8R+OMceNcccbEGOmbJRsTWk3wQJXpKeHXlcZn0Hyofa5DO38R6OH5xfJNwFwzE39rE 8PCf510304ec2bL77VG73EQaIafcGxBwEwiPRg/Z1tGwcfA8vVD7f269EmbCW40bPBytjHulT3vc hFigWfJ+3FpzH7MUYFTAPGozfB06HG55gtzRKH35Llw32FB6S7xnpFbvLhBzHPMYS4QctEn8M8hG HvahkXCdfC86nxxdkQR44eyFseHrv+u3B9ywYNMqHTq8OLRf5pYTMHsJvEP8sXZ4d3E80fX8FqBr ZdvxfhPgmLyRZ91G8VE4x7ExNvWtbUdeWnXMKJGT5nCSH5Mbi48yxRZn3+/fu35Hh/95fGd8UBlp XQ9m4niiMTNnyvC+JHzQ0b4RkRdrXTyWbOf8JVzxAlxr7/PVWzyRmpFRuR7/BHL8d4l0KHCFoV8q w3F97qkZEVEevFrzGGe80+pcHODcWsLO9GaQcWiYsn8d91xVj8h+4DwxNUkTkwQTXXuqvyFd36ge vN/QG7Q1+dzY0GCdWD8cwJHYpw5ZL00a3MFvJCkXrBx3HLpzbVOPfCOd95GxIBPrDQvlirJ8H9Pw iQi+tku/H5dc3HolMNPATAly63YfqKijjVSRbB0T/AVJBylefJ/4U72R3KzXl9yvzrjJyXxRXnMQ v8hMccPwU2M//QVrOlA5VQLv3Ux28NGzPlx3s1CTOFd2dZHKXFAc/MjLq2jgbHNVbTFlQx/d5fql Hh6YXeZLnbzqDX9wR2idSIHEOB8em/k+QVxR9eHZ9Hq4N9DINxsUIn/YP/fLwociyx98mrpz8HqQ 59zspkVX8Eo/7yQzUce/g1oxF+yqplgveVzF2TlywII4Fyr6PMgcFROKsHgxv7e1OUzZ+X8YBF/x OwXHUXNsdlZNsF//r7V5PRc3rraKVLxrPxhAfZFKqqrOs8wxnag1PgxSO7GTs8XDpJFW72N5oswJ 8qyckNiWZSI+FVe/0NadR9Q20dMRFxwSRr/Y+U5sJc+D3HFz0Rb+eJ5ifIvfiRK1bDOY2smjkjD9 D0SMnQTPEj/MfXtlaCZIYw/ffBLfGMh/yBik3PHRc36JfdVQQ2UdMOj239nT2fH6kXcaQN9YQbak o3zQ0DCHchdFXnQOw25oZ1aWkxbw/xPobdEErv9Ndkkxz7+GgHM21VlU+7gW7LKFCTkcwN3Jtse8 11GqAH/2F3gEcDl2YFSbP5CYV/0nDbG8bLOfUunrATG7v5Pv1jitf1s3m2o/Yr/RsZ+8ARaWUYNp PIO9dgQbynxxVnuMFIc26AmZky5wmN+sKPPxtL17ZYV61bSfJd1osZURmupz63+kon9x251YljE/ ND6bZL9og1DR3UT5ipi/chB7Nq13BOWP/vMMH09WX3jQm5y4lYG/RgRvLkW+ytD/ZdW4EiRfnIga OsusTBAAwlvOCODc41bREezR5WXcV3vh0jU+XF9U78qwlKbQ1pNA/5Cmu13WEdbSh7KsRIge1CYV d5Py3kY3X3Lx6LHdVcQ6/GhJdYUfwv+yFBmAAmt/4VFQPnac/+svwCdjeDbkomsL32C4Yp69ql9x 0i8c2vVsHBiXRjj9uOVyUK0NQZsOKXxT9pkL8MQQ+qhczDFR2Lt5ZNY7zxdN/ef3o0rPBJwt3snE lv2zYtCt3H13IxlNXPVxD+5VuLHFZPjpG1Z/HPqdLZW3MPKAZ8U/CtxQxfgw0T/f0L0Nngc8sr0X ED97XAdamZ9+5+7/SLQQvcV28hz13Tgxd5/A2i7bQx/xExYQBSzxHWbcsRco11i2R35fCU+i5Ve+ I3v/3oV//xBq3zNOk5naYFpe75CnPfG/9Oc4di0/3Me0f4N7OJx+EF3i2KJd/3ybr55sVhFK8P3c rrQynMVsfdsLntxJ0d8cf7j/UFQny78pB5FfMPdYyNOfHVxRjdnR91Tn6N8cRG+xse1vxXntHz4D vDQFpLMw8hFtcO1VvoivcPsRZJ2593znDfKKlWykv7GGrghH8ZJG0ZPGV8cb8RifK1zSkuTS3V/p cN6lzGxR2590JM+XKHEuStXapOL+cdNkWL3q8f1ccJ2/0Wt3XJHDbIzeFjgxM5zgEq+9XcebG7RU EHqiWzvbRBiIvtnNMb3UnIeenAut77/wEQeHCojfUduYW+gRGH80XERNinAa8XCaVrvu53992DQv H8t+cNBpOBy3P1h4L185U1YI4sqQvR1XdHVX9wlXV/lm9jTRMaxWU5UynQS29ecgd95WQBxX8PbY dARmeGXPlU/zFdG1KY40ssbxD8ECGxK9B4+udzWkgFxRw5HhIGfc0TEekLkZ/AUeCzznMijexqiQ PDU//lXTu3FrhfNwU/YgvduwoFXI7+m2Vu7EucYf1vIb+Hi2nXm/xgq2e4DbO1LLt2T2nfND9htf JH4Uz1b+1M/4fFybVu4blzfS2C2K9n1+EV5Hxwx9fBS8kDHu5DexSGt63M3+lGyLQ7VWOH1F9dM7 0I4qdFQWsR2VEK/qdbulRVqae5SmYhkEOld6lXXXEbGclr3c8FQbnzSXdAoR+GuANGiyUF3thiwa chy3tlN9G7vfVOtnb7yT9zcJU70xU8iXJ1vXk6ZQlVyZmfuOA7GtsgUvzw29y1aVllgGSv70Xt9d +jRH/5B30J15t+Zsqm2sZpb9v9SKek34jXWDmMte2w6ujVEc33XUiOqe5F/WjsntdhAAVigzXR91 +if91FhD5JkVFHaVsTD8GGCW5RBzltbdVLLxOnid+pNdO4mRA0yQtyC11+MW+Vi4QhpvzJ2sV8lh LJu3fhV3vzxftFucYBwrcF+3QNTOanbXu9ceMdoea8KVRXAzKQqxY/9dmR3GEJCz0wng5L/K87GQ E/ZZV559erKEOKJrFWAOepM4ONr7Ry6Qz625z23+FITYl75bQlEAI+IcnfkXGb4dHbOfglo5+PEP 3WQKgJMY8SFThK6ZHxpX1uX987yvhpONtBVUlNV0+wR8CjMOR37XuCI8Of13cFNPitmKwmT4v9Jt AAISc7aXk5OAS4qfWMOLm5g4fVAxE30z7Az+qYX94p77O4u8RgPyEHnce1KJEgItlTV1WxsWhajw tlWQQIIgJsEuuGQGBOSiwiTuBOS2Cot4lm+Ibi4kLmyyMAsK5oZ2Pzz27p2O7hgYyXLnWlBi9Bw2 P720J+IYY8ICotJ9Ep4+7JlxjDE9W+3TqeKxlUAOGVe8dYcMmbyFGWKCouJ1Elc5T2VRlGJ/dBxd 9euzeF/NJd8LKvq7cpD3+k38wiIigsLNpfO5/WyecACtKjNX/X06gFSJu3wff/3VghIbOHcdvcJi gsI8/58e+ZJ/jz8w7BxMbK2iX575Oy+4DxwQSSlP4t6JSI0yhwIIaZio2f5imuGiYt7iHgJzMZMP IiLiZO4iQ95IijLISGyCboJOYrZChgePMfaUGAK2mDmjTp6mVourYh7irpLi3qJg/TDQf+K4ohCC 4uKUr4IXDvGObwgH/NU4BEsic1AvLHWi4vQCoGPt/X2P/ZLdUp4LtziupeaonF5ziOdIgmLCYp8/ GYvMV2xf735Ru+EslnwNNQzymD1X6YZgEQgGpL2TgibMImXfXF1tTX6wNqLdElNz3p3NfnJNgmKi 4jJiPYwcjm6cPj2fLXY30Oz9eZV/Xc6PzdL5EvNJ+fUdguLC4j9LjnKJbIh1i8ufsc/oGS+s8wsl sQuvSDe+KgTkpNAlrQICAjdkNicXx1Vv3d29Zgah4cjX+Fvhu/ZcFVzwMuYCvlkg48NevFw/W77i giIAoBorBKXsIjviwmoN/V9KcaZNpsh5ajKfuDgOfb0clBoNm6jcQlACYvJd/nKFaKkqLf32nxsR BhdVGUKvP/d7NHFsgtYDgvkCLztTYOd3S/Uy7RxYfeTokb2bvlY5Nez3sj3IYpqHfbQJfzlQq6g0 /RtZ5kLCoqsU50n+Z5tyiVtt/ctxj/kyaqdF/A03bfVOutDMKqLCIZVdkMKFJurnAbhN8gKGXlyd gSHrzN7lHV0DwqICeukYhMIjA6OhwuNKfrGmIqFmIoZgRoYmRkaDJMvy5ydmJyfHp+AHJ2eCd+Jm 5n3nRERERCRE5CLFJOSFxKQlFi/yIgWl5aXlxUVKpWXlpcVFamUFeKICgUrr5eqKykoqqmpLi0pA qmsoyKvLuKKniguAa+iIaGhowMjoCAiIYo4u7knJyanuycnJac4uqW6uztvkRMiuzs9u7g+sjw9E 4jt7jy8vr8xMCczszgxt+A/KGK2tDS2tTW1s7Q3trALYVs9NTU0pyU1trCyy8u6S8l1PYKYpzg2y sxKSTxNC0/ZEa9Anqn2wQOMwkT+zqdsQ0RAcMCbH9QvKUJA0MAnwkBs5Uxa90LDxyLA7tjGZmOKK 8N9wNj4R/xZCISvQcSJxtzE2EZF2MPbWGDAWtl8x9vdYlp20gwuQ133WotbWVFbzljYWsuOjAnJ2 NzdRt7ZRV9eRV3dR1td3Fnb3dxcK+CTB1PT0R1QUVBUVKhpNTyLE5PqaO9I7+1jbOLIY2BlWWdmC bcD2vktLPhqUn9t/HRy19T09A/2gG8qdwN1CQz1FQseHIgF5cYqF50v85n1CxyLC47R+uo3dQIIi QuKiCj7ASrVeelGNxnwYqN5SvTiVCR8HMTyVLb0ZSR1NgYt4Ygj/r9+YNksyAVkMwoICIljc/05e fF6bEUN9Wc5PEj1ceFp7iqJ9DUTCO5wXLuGh4qaCYse535gCG/2VTWRcfph+GV9qlvV9wu+ilVSe ZZ0QEgICHzydzpJllXyvWtX+a3XquRxjUnwf4sI4JilNF5naVnmfGCJwF3j7TXzzofMyW0j/yvt5 HSoFN6iygQIyUpwnVUG1TG/12/9gbwtZJF8BDolzew1MOWAGAi6Ywvmv2MdVJN9tX2To9sLivhuy /XQ7E5L6jAxYN2RQx4mJD0l4GoeifTachd+JN/l0ul3c6HEd3a+juwOxEWLCIkLIyPQA6ohjmVOw R+TDKBoIhptMVUYO4hD1eaAJIimOBFgjY2LRtKvJdgi3LhPK/AJKTl1JUeRfmwfdslYrxCswaCji GGI8ovwGqJxL5ktEYKqL6vdw3UuLKqQTEZMkNZ0np9pU+SuPUXG2Zihd1gurGBpCmNZYvrgWQe4G 7aPeWJ99bMJNNSjrE30SPSLf7Qy7/lJ9AluZOr0C+pRingKcNeGlWLO2hCJigmKXuF2ZP9xNcUNt YFs6OU84yX06PH1Is9oAM3QpQxiix+J++Il3HksvWPN1wT85w5v7mNPcgqI/RnTevBm0Xn6wGK1+ +Ngx8mw+r4KiAsLU3DyU0Ft/WDv72HE3djAo3C60aT+bu/t4Pl3VFEgOvDZCAiJ0eBh535nbS7iJ LxWsbrzOGOrbJbuTmoXCQsqlCdXk3FR5TqSYLdu4eRunTNX+XHnIdPn+goI24XzTeNlFa0d13Dk+ 3BgY6nj/xjwo860OKsKKZwKztb4Mw14pVuz/hulf8+R1qt8c+KZ4e33g1OIwm1wzN/f+l82NObOp /GeltAKQQ5BK/x41BImFwhM2XVje2RgxLc3lPgKCosIbOAJ+p0V1RHJ504t7ZAuVtG9FN3+RdN9M 9Ds93MifJYIw3dyybRm2P/1OUOFMgt3cfwIrAypPRQVpSZkI/plEqZmcvMc3C2ujBH0LZ7/eghK1 /q+uSJ3/hL8f4xgaMYDM/819+ap7tX9FIoKKAFReXHlMhW0lz11vt3VWfREaaUIsRoyKjTIHICui YEifXkCuU20H9dbomnr58MW+O/Qr4j9icDag5iH9bJluOMtb7TsnNLx+JkszYkKpQoGkebAt+FJa Y7hZF/l0UjoAQUHvDKaQqrUc9ZlpnskiERapHYjBOBr2H0oCL8JCndu9SmZeeEQdjWpjekUjdoPQ DvvCvW0CAqLibyKhkPJhiHN1hwQs+gAIQdtW7CHSfMxlCRih0bmCYCG3h/DzkGKt0CLYCR5y8IIV /ZqGSPDle0XrCYIiArdcnTA6BoRxD6lzIfa0XR9x+BmdfXYtdoJoz3fwTeV3OHxCdSviYqJaHny9 ghyba4ZtnQwTKefB9gSACFL20VWXjzCy8ntTzlTq/6vXJBrhNbCcnuN1UkIi3X7PQZRDVnwVbfCu IRkfL8+KaFPiImLSsh7kW1BmTYgRaM4QpyJ9cCvh0Hm0hx3UwarBfZc6X3rKAi5Nk0ShdEpWEFKz wBIyGDsy0rE6/aimvGMCYkA0RX02br9YNes/AfyyPTEeuXXAk0hPqLcigkLQuYmkslR7QZcLxuxf gzu/fD5tu7T5EpXci1lOobterONQl9iejaDwhTwHnWIaDeI/bbz9uK4sBXYndlbCVBso0X3SR5m7 k9vjoiLsFPNPR5UJiVOWmDzJacek/4U2cXtXKqHCoiLC9S83Ikx3SJJJlq11yZ2Cv3eZ74VMx5A9 Hhu4tXRD8pfiQt0CUnWdqfHIB9Zt1NW+POBQrmINFRYRkWJpPbb/PQo6ElK7za0tbNFnwlIJs3lN 8jHTTb2vDA9MjJE4Lm7YE9ZnBf7Rm4FY5Iu+4KLgwUHhQQELFlePYUEboiYBjDaXWFiX2EQTJ9hn xmeCRKSEypCGiXnIZMTE/c5tpILP0oPyxeRE5XKFpQU6hSUl5YqK7KXRw0rrCxiriDAo31iKeWOS qUnug9LP4pzMTIzkI8tsbOxtnQ3Asi2N8bWt2O3aYQYNbbom6FbEEk3dUvLC8hmTM78XkW4Qqnoo 0I9djKKcsrF3l3Ua+kIYWDwr6U0l7n2QWlfjX6eQLTI9la1emv1MbD7CogK2600+2izsgnw/3N8Z 29ifDB05Wlp6fFgVNSxd+BIJ3Xx63HmcaBjZD0184iKCfUtqzf2Yy018/1/eXrme/9i5TFvalUwV mDRGYtVbWmtNPT1ZOvVVsBQc29mKcKEiKi28u2FB3FheyvJ8/ZVLkBF/lUPiY2NhqxiEoIAAAWEh fjOBugYivkFmpuHB5mbCo3EQLFn9wmYmBgempqRwk1V75yJMDSenJ3cO4OwEm0QlhOJkhARiAgby pGdAZKlIZGYkpaTEBaSkZUXkRaVqRSRGpdgko4GkAQpKZSUqCqrqooYpSkpKKsKw5aelpqHxsEoQ KyuiAsvJyIvJ96yOK0jLyBCyK3UoZyCIiGrGMGi/jXOG0vfLIslpqSmJCc5u6WiqBrjkD2nJiMTp 7u5sE06Gc3hL7g1PyKdubs9I76rP78+uXSIPT2lPMXMk588PPaIPbMxJB2Q54keMb0/MjqRMyytt A42hCI7ta8vuxc3ES9hYva1GzaKyEmFGdpuqZTPiU8pwk7FzMyPzje4Ts7ATTqLQ8SiIb7AwDRCy sUlEWiiw7XHR1vHR0b3RA0PwluI2thY2ljbWd9crGMSjt9c3tLX1WjjC0rjkGJmiglGKOFXBHvv0 yn1QSII2+b9c8SRRVX18Pb/8dmA+7rwiZrLhYxNUWsxelqxqBA29ohgiHatY3BoJrhFUXJnaQYJQ oyLZfJn8bpmTy3Ezh+6NHZkwnBWBFcRuGpT1osLiPyypn518kn87T4Pr3e19fNqS47uo/ZUXP1Yh YuL7vskGrHn9j5mxhKN4SZmfPp3hFjO+QuKiWOKPeDADgGRbKR+uP5v5sNxyaaVvu5DBRrDCQmIC pbHsEvmacI+eDiUtD7ixfBYqiwX9cphUkeKDHuG9XxriNuLC7zn0qAcZ8Y3Zcyh9egVRN1xPBnaV rTpcLju3fwICE19b8C9aSWodVBwrKJ74HnxFItl9DzU0YUmIYBm1tQ6kwiKCotQQGITDTmFPGqgl FtVlkV9atqyVruRsug2z9XWi/LqCou+iojNZZlOKZviETtm5a/mpF4LpMQYU3UztaTUGzxpN4BB7 nWS+XovCi2anw0PgwF1AA0PgAwPg44LDIvdx9mAAAEBGQaEhx2GBQaIWIkFBgQYGYUHnQUZmh0YB ZuaBxubGXYfxalBmp51Hpj1m5gejeqUcoifmJkcGZMYnxfSHle3XqEKdf/kiB1wAOUd33Z0nhwQH xcet3qm3RMSEHsFdyKoSRQXF5b0qZcWiqmUWQaBuwoKqJUUqRUVi5WDqamVuKpDrCtdbw2rqhyvD A+toaxAB1pDCSwsIwwtrSyk8q6k2COJGvaniawmrKEkjRSrIxuMIYSCpqCnuQQioSc5uD6dEyqf2 pYJoCQ9ICLKaSAit1kLsj0uMbsKVWs1aTfat0lIScqcupKNCcm4dsrICgHVLQmnSMzNyKfXTM0IC JISvcdGza5FRCNF28Un29k/3VvHjq/f0tFD0NBJIcJBQQJX1qPXNYnX1EvU11aKG0BDdNa/o1UJV Okn1+on6G2l6Gm3DJAIOevuoGvuIehsJ+ttp+pp6m1ZaXaMqoCvdmvqbKPqlBXvaO3NjO3eNO1zi LoJm+wIbWE/7eBcbG/t7WxCb9JL7OnA42MEi4gJEeLi4mBqQeNow2FgnWFkU+BiT+TttuRtkWXld wOrH8hnkedqXOblJBS2fn6nfvE/fgmKCfvqc89+fEJz1BP07Tv2USCK8ifhZN0vHZYoCaz6PYgSX fZ95fR/cTy39QtJsYiKS/XncX/7aTIHSnRwqNfS6/RhQhKl+QoICQrFhnB74n2WZ4d/hVWj2y3BB 5F3Yx8k8ETd9HUKtJ3k0oqJiIm53ZNvZRXxNLniarwkn4Y2e+q32uKYSE5lNlGjUoXCCwoJfNeWo VV9oTZ/gbaf5t84+Di9VHTWn/L+gvAABZwIiwh0USdUNwVVjScfF3D4bHQdI1uklnB5TQ5VcwiKC akwv6bQPnnWNRnFk39o692iwYOlTrL95l27boN3M2YLqkGPevDLXSe5iXLisqfNxxJnePxg9b8jC wqImWgUMuxDmih0ruSzZubjpG3Z9BeUMPmxx4kICGTRVCeROWGxi/V4f8fKOeiZCNH1YHxDwmWy9 0LLHAOlU6zFEZKqi4uIls7XdUGZEmVvdibBsemWSzrRpvWzUUrGbYiIide8PRkpAfE6xlf4F13VF ZvIYxx7kg+6hSrJqAgJimKl5DHxViGEtVxVaLyPvGXFy2MAJtGhNHzL9Hk4psSpI/UltMrCWlB9n d1WjXoLSvwD5RpS40dFRnOni3llhkU/iVpqdIbYXhn5yi5jQkbkYMxJ3XprqG6W4kMn9EoNcMVPw G/MbSNd0kpBiePBcCl2Fs3I+nv+Eq1PiUVRdfHl9Cwdmx+Jx4p098jkCAr5IfrITc5HiUzMzoi4C n2QcMIwLFSJdI1ieefh7URnd8W9A5UV8+l1+ldSZdXY9d1KcNAaUkXsjM8swt1H6c5fUkzB9CRS2 MVITa9OckBO9vdVRsV+W/GYIyxpC2YlV0yi3Rosfltu3QB1TsDRgymbglj/7VVE0WNi4WPAA4bkV zi09Wh61Zua/jVYx/3sY+1v+ufeg0z5GvWsZvhUHWtm1JyBxYordWPPbvDcS3LwUf9ypL3KABvdl FJT39zxfawcI8RGHvlXyMZC18nA7t8KVNoSxhAsoJiSTXrWin9D0zvdjwEw6FhD+bL7VgF2FIfIm +VUGMXlBMoF195EXPC7wavCct1/c8kBrCXFeVvdRcH1Zjl3Kuw8L27A1Jz7D1Bam3Ai+11S5zJNT 6SFxH7TxBHK/aZZJ+DcfL54Vvb54atNJ8v6DVcjuQvluNuZyTOsXdXh81NQ7etjpAFZL+h+a3d2Q bYLR0vEz8Tp+ONrzGnkzGTq5Q2gQqQJQuj7CXpqWmn0WzJBBephdMd3f84L+cc2a+lo5hoYjxzhW UHbeUayROD64mVTy3DrA6c1LnK3iaobEtyEfzXFfcUTYhAa4VOKfMbMeWQAzuLyjnl+Q0R5X6fH1 SsMQ7aBY4joV9Lc0j9T199dU1RAQ2Mr/EBev+JswWHJiZ7NT/jWedZTUer6ZuvMS8Xhf6U9cNN7V 1PW4ABCrtX7uOrT91VR0txeedWWKJgK313qUNV9eV/o0N3yXW5550OCdJ7r4fvgxTT0jIX9ZdLrU fMQ5lHPu1Bhv3QunUib3fVxTk5TzvjXEdpHiqxfz9N3YIBx75zl5jVO7Zw39ikDzeH27uFv2/DWQ ivva/Vx4+B3skUYQfYye33EQmmfZbxftltQEGguSsHf9dtpYeuwO+Th0B+1g+HtbEDbrMKsj3+QC OZd6dbVXWZF90tzgCFi4UlYSBJRwBfNOehaHMcnb5L1MU9N0NLvdDl11lh7ifDIMjMP6ZSf6Its/ 8mEdPbRNURMqG8xE1cedPZ8ia5fAfikHiBHGsgjahlq5VeK+UVxYKswlEQI1uFo1OVvKYIgZ0+ra +J82OiqVtDshtHiCMj+4fX7YQ/f9rUKPjIAp8LS+cG83azonrnZo76z6uK0GbqginKr/FruqGJm5 VBFNNxrbG70llyXft0aWqFt5/RMF/8V5VFS1VLUw33EqN3WEKBj6vbI0psBffKj3fP+/QQ5z9zfj KaZnuzAmmHSUDN6svFY1UD/T2iVENuN9Gxa+cbEQAu5WXJN0mH0YE2kyGN1AF90+TxzPshdM6hGj zBwMw5MqOLZ0X3K8aXRaM7xUjD1stPBK18dOeY/6+yWdYRFuwz1dxrbLmX0E+jxom4D9+xS50f2s PbCZ2bq81cbFMWX5PFKCGMl/XxbxQf3Sa97WN2CcWPhbn0cTaMIYzZw7+BUgVu1jnXi7GxN5kVRD orpjYZzV2vPVVba7GcpThf2PJtiKIuJighYCetN1nWOFEWVYsd/NQ0hOcjllddaebN4GqIpQxsLl IiKiYhiWHzYKjnebbadVcuZJIYYDuLl3XtgdjOHmTpPzw5mW4iIiYsTDOxTomXeL3Eb3AfoIEl+K jD71m+CstIr28dnU+6AIImKCIt1oQWGtVmlIaBvIYkBw3hLHqMRlxpXC4dT86Z1xhchOIlBgwmZA EKNbdpT/UrEOnxsK6Jp5cvftA5EBd8KCoqLct63RSmNXke2d8NBYlOyLqsuebgPaElIHOq71MlDg aWKCAqIAo097R5x8ngumvh1jKDQEaUsQT4iku4Ohwk1nVe5JgIoGAuJsnz9ySsFHd7+XFtKh3Hnq TbHivZDQ66s39MzfkM5U1fWdImW5nkbLGWLdSjM8ic+fUth4+I33RUR/7RQvkfBY7U0RlDRABi19 zAEzZiWtf1lcmBLPTF8qeVAIlOtEOo8I1dOfxCYw7B+UPqr3KGa9zZmqVPcu5I3ulcud+Erift2f R1BS8xV6ujW1q95pGxubLmfDqiJ3Gn7bG4FVVA8UGlsD38l69IRUGvW029IBmZMbPLlWNdUUVMmQ AVHxPHtXJJW6IElZ31XQERQNbQFK1qrhd3cfp2wqY3L7TeebtKO928rdzu6M07Sne3TzkfUZvL3u ifEYGAMABkSqkQ7JcYtuLTKQ6dGOydb1+xjZlIfWbx8dmOMgR2qblKd7C4luLbPnW3RHMTZ02vmJ kVh03534giMgD0lxzmGmxOWqS7Gu6fEIie+NEkmxjsnT8HY39N62LA6Vejo6Ch182BuH+9QHPThZ Hl5/eTDOdJx4osBh2LjH/DWNaKzWW0eByNr4Bh3nzDiYRa1ne+bwyTgKfcgumM3CLp9Vc9jxFjJj QiK6CBaPWB3TWPYcQKp0/Y+fBdA9TINCgkJwY7tJEcFJb1FOG41GnIkrZrO+YWem7Wenb9iU6wIC ImJdCpIo8p14i6Gs/grMUTzrfsMe6LA18IsjRvoKTfKnRsIiIgK+4OFGUHRLh0PF7YeNF6/Q/8oJ cNHTY5FC4AVxbZQ2QgJiigA/p/Ad5Zp8wuMcnSyFntC6FpxxVOEa1scwECKiwoKxCSThnXqVZ51U gi1cZLDr/ekiiYu7cK+L9UflKob6A0Iiv4KqyGEwB5F2ZnXE/Idmd3qkCOhYp/kaomZiYkLCNFL0 x0V/VoSqi0NLnnnFa/dPb8qk3OlKq47rXVl9Db1iwmJC9gsHvCX5gXyITZIwuPwUcZdIHtZKuvhx K4w6BjPd8CbCYiKiAsqepy/4nGfA7W1o8F7rK92J4aqOG0erIanl3VP7g2IibYhUiT0P/488Roq8 kXI4OrCdrwsoohWtDAL2kUFDVDCbUH4iov8DZ/iR7XSGYyAv/TCSKSKeKoM9jVcFHGOF4mJiQqco sTThi3+Aq4rMUq1LwqZ+xtH1eMf/wxKnrJHUh+L3gkpoYNaLVOR4mwgKKWEYque6CWbUR+/nggKi MFZFJOlig2eHsAERlUJnEHs1jVHI5AvW5jMY/VXpAwJCwR59e1Y0HYglstzGWhA9lKj6nZn8ogzi 76CtXpwFWUtxV+utMBCn8WuO4TbE3OIiIqLjBtYv5Yd5ma9ESItJh0U/+gsXknyLeJo2aouI0Msq fmJiogKNq4CrS2pOnOYLvQ5nSHN7lUfgSDOHLh/5Rj1NfyYTnyhiYiK88UEtGtFPetDw/IlWcNLc pByBbmI9L9lIUwiCwoKoTl1SNU98QMcp/U1xI0Ke4uUd8bb3sSPEqyIieEJyUBsQ/4E9zHM+5yIG +GeN1tLmPAR1xrGioqJikKarQ2NAimyVasufZ4zINmGpR2cSz2QOBWqnO9fDhlRigoKioLFKZFGX aomm/eu6VHtrFaY4vEf03rxoQ9Qd+zZSPVpCwsIiBUB25neGcYngbDAYU0px9WzrdsSeDdEqjkeQ mVvBMZdidkFCr7N8RF11/GpLXx1y2X0XapoqRfncCqgvYiIC4harmJ1xi3aJQmcleIRki8xOZzie CCbWqCUxzvkj0cBuQmIioqnQ8/1vkGKJ/V0OOjscIO1x3fPfN8LdEtRKz99Ti8GIgmJCYpiI8tte a1yO7KfPfGqn4UugprIepga8R2RnzbVB5+CDqmTCoqvmERDtph6E/yrydhlLQyazKCw1q58B1lWC 4n6SENC84gT6HbFWwltiKswizvHMUUhxA+diUFalMF/z4XwOIKfcJwNSKOLXrR3U5cvdWxZYaQNf 1sSUVVF1RuKiohjEmnQQ5Ihml+fHsbyGeqCaB9s3aEopJc5q5hLE4gKiAmu1QWJLmH6ASkqtRSrk mK+rFymJSzn9++Tqz93n5Dm3YkLCIuZXihGHeZhy8SvLVLbFIl6x1m9YkDg7Kvwrbsx8ZV7mDpoV wv1XzECdWMP6i728UcYDhgIkBO76HaImQImteTGAIrdgUMUcvtScoyA728au/yNfY9kCLT9jm/Mq 2m85QNtfN+Kuz5GxUfEwvtDRsB3Mlww9J1iU9k2t6XHhJy39/C5QsVz7tWrsrF/GF2zahLTVXHP5 H3uY9eYgJDn4tPriE/Px5EP8nHYcqBiQPScS6SQQff162jX3Zug33hj0n1xxEZWEnXz8GHoXVj+c QNxN4pBeLRj3kFX5+m4FUym22ctdFXtfdigBUA+w2dzd8e3wxaFd5Rby6E28yUZ9MNEeM61w/Jlq HHHCl06VjoRQ8oS1I/aV52FaHzwAfST9t63KArZOd2bQWXF2PfOFC9P4rCwDsxXTKl1nwI9Z0bGl M6RwNh4T+NHRswGLl1E4046TQufj8So3OjlQseFR0JD4+B2HAhKq4jrTV2vjXNFUMXyJti0MQDsR cNkTc95QrIgy/uZeER1zhDsKcuExnF7wwG+GRPCOepB6U9A0nt+THdIT2+jcn47fatvxE5q/PvEN QGJ8/niy9TOxwae3MxogUxeT1PddkIvE8/6iDQxLQL7/CRz2B8J3R/zgsJuPMpHUMfG4n+RMGoTq Ea0UaDoxtfFFFTgFtgL1VT4g1ApNeXBwQ+j08DdaoR7oQ1NVjYTUMCORZbgJeWe3zHOqQc053tYT mvHE7UTU0ktxoBHQPhQm/Bwcc31eADCj8RmTkJdW3i7bzua5q6tls7YhdHzRNcTIizWN9jNXVo9W Phel3kt/0v7+Sh/8Jv6eGnQqlDeu3l6h/tVU1DoljUnypGaPrrp5N9HxdpWNEmLVA7e71OmhhvH1 +pqX96t5BmeqEfaBp8flfp6+W1C+lKCKCT/pvcwAd4x4jDRi2oRzbfeLsZ6LV8ZV2O320L6a1d9q KSjOtHFcfsHTGYzYu1+WY9u14Z9ceE0qxjkYUUCORE2u9RvOWSblGMOtH8rIkX4FuF4b/5u1NOQD SnD+GCl+EN6FdTPPITwzmhqalxpNkRn4NDSW6rpPqaFW/b8SMbl7kr35NlA9xhVCrvkQ9ITygAtI 1bcCRtHq1vHj0duUiAD7sTVXG5t/wgK9RFSze/NwkVJze5t01Zv1SNg3RqKrS7cfNtO0Q3dXMLuR d7v2GzCUkapSOZYOg1S2G1r3Ug4p3nWProGYeKkGETXBOqYJ9bXV6qpWvtqLMnfnB0YxeTWQmyOC K8ERvjs7u2v4wq5l3v6XXtx/mwwYs9k6Sr2xpx7qAnV0NTd33MI/RlUXFPQzVzwB9jCU999d3/y5 VEQbe7e8CfgrzRpfWvu1ijOUQt0dSHaK4vmkkDcAIV9UWx+XgIWGlp21ejURXbPbG5cdkSTe0Lt6 BB6d1L5Drtxsn//EXM6tEUqkOzl5PQlvnT9/OMTOuPj8Wr7sFfR1OKu/a3+YGZOauNP+GspCYRm/ Pxk9P/P3SVD9T0J+wv5dTF3vAu+vnh4Kjmc6DwwBEw5hw1BabvErncx66RWpj2qWaLKHMRF355+Q C/Uo3vvLP25+sStYWlOnaL1FKyg8IskBd9VR/fN9Z/wBV8YbW/3f5vjCpm+b0bw7ldGSLOnpyh1E 9FHeGgctuHrwuFYY9y35rUcWDtDday2hZZrQG5PF7if8OD46AomseOI66hwVUbHQG/h7mJd9GRFD 92n7+PtY7xNFfBfB+x/zzutJvej8dl2NfWc6E5b3Gn8iE7jO9esCm9c3y3T3/DdbkYZe4Al3M9VW VNcc2CIXg/0x8g6QFFp3PLUuCvG6WOhrvTa5sxUK+XuWmZVfHnQZ3PPi/U+eny9dPZ2eUZ5fPTHX /FNx+bXdvd37JZ5N3T18RX7tHHz8vOq2aWtiLnJ8vJFjYu///R09fF2cfXxd3CJcAlxp0vk9NA/Y ThfDcnP0Al5dnPq9DEydcQrmshXbeHGePKUkAwEdEs1bqTv/MpQnGwYaU93xllR6eE60p3ue/IL6 Q8HR7umRZoeFasipMS7Jzm+N89CPidFulnQ6uJ4f27TzcT0644HmJEebNKdqC4nv7ZSHW/ST8BYU urv4lGe72X4fnTqi0e5pMaBGJGXrSbGOSekPjPLQj4nR7na3VRo4HtukaZF8vdrj4CaHGxSH5wWL aA6Uh1t0Ty2zUDbU+5TnGxqb+Z78MU5hR71aA+DGpylRbinkimupDi6J0e5vrVKQ8deQj4lxtVoY /jw2CsR8n+CO9FqxeLWXtc7yDi36VfM1Vxsb/BzHZZsrdTq2VNfcN5eHqEJWkgH8HFV3eBg+FkbL fPVVxtfcd9tDLNJjW7g8tTcX9Hq3W/s0YWeBPDf1V3vYFJzb+/rsRAe63ZK4180WOJxzdXQ797TJ DNwCECyEFd+V9PeXX8DUyxs3Gz0UprwzrqBoGRqLV9pVFSE8kFPYn3NfVxWfK3pkxKYXm8bf3OGU 8MBJmhMX9beU9R2rdWO8QYuXubyVu8U435g25htX/PbdHQp8R5X8lbR8PP+6N93O4PRX1xfm2bPd WDR3lXT31PXNNdzQIKx19J6V+fZL9jS2dDkf11S8GQTZSxKRnFt7sisG6P/89Fe/3FqUaxWThXke PDgly8CV07S0tcTUFBQDt0xL/DHRWp159J80xWsRotv/1NXUFfQNe0yJ9vyN1bS9FRwmjWIcVjWY ldU6tWZNGaqfFMXU9EkcWxHlBgwbW1ixfSO9l/94HLi1LdMrzdRT9FHcF1u1GDFM19vbfzr0lH/k dvSJoJW0KPP/hijXPBj9IvcGFoxZFTdXdvW4DXCHvgjYO7j78rzc7AtnHH7addRv+9QIcZtUXFwr Lw07zbyVFbQ1UY6k6xmgEOKW9Ryh1NBnlcGq1PVXG+QzOAf8XDzal3mQq+vIzp4cPJ/2ea5Y7ndB HH5aF6txncFV9bfOlfWM6IsUh5XOvI+4Ow2HFgn1d0v/VQA8tfPCvp+cW0a49DuUnSlrwO4f/LRa HrzwT5GWNNaatOYPLTxatFf0puf+Klm89VVXlLRVO9VH8ZyrF4XbYdRjR4uUaByU1zcV95V8hwDL dpXYlbQ0tiPch+0S/fZq1h4WhXII9ibUvG40PH6rRiG0dy+U/mIxv8L27NI+E/YQGJbffOwUV7U8 Mje4jl/cgkz5jtGBPcSCVj6agioiHjQRIpEILDU1mA48c7gvZHB8XHH49R2+N3LC/HsSBJKEs/jf vHjyQoqdfHJ73R0srxIc3OPb/3QN5Vcx9AzBcBj6lpqRmbFo2Ic+NNtn3pGaKOq2Ec78qjoQLr/e 0zx4+5FTWZB9M/DRvh7YmF38yPHz6WY8cGf33tj/H6XbbdivghznAtwwqcFqWjX69ABxdxv6EeL7 y4qUlDTfttX72ztxu6VhPd1bW+lW8Mh95AmYRR1ZC5fLRnn42lPZT/8/iCn+GOeW2QPYiOCtx/Cq eyVbczL4PQsUvSxtPht7mwamkXooQjS12rz8fIoSdlJ6Wz3wqlTLzejd13xQEY7zprtd8meQkgx2 sLMzaVFqUNpPON04M5PBqtFO8hGVCzH9kFQnmyxdczzREVAV7ShaUE849X98Nh6z/c4dDLxd8U7B x93iVeOg4cap0W6JZyQl6sudjNFuCAkOG6y9cFX7ERP/UdIGfxLezI4FOCVwp13/GdbT6Xu8PrPt bRfdmjO920uehIRG0F71m7pFVH9Fl/p2UVgeSFHoesb9LfZU6WA7ZFd0Vvv4FLzOAnjYkHged2D+ uhw39FXUNFoUNDW8sV2VlCadNB9zAaQhX1U0lFd6FbVfJB94cJjK8t+I2l/VNRMdlm1d1P0d/b07 YzbaU9tKS4lBVnRxkJoai3GWgSr8tbHLZCc++yb5JJFz7OiZQGKWBbDXKwc1nGeevXfiLUcVNYsb vFFwLFxpB9NOItpwJoIcSDGc7NYceb0BoQaYTz3c2W6tP9pV/ALyr29O6UhChqM9AgRuOrOZ9yLn 6UbZrLfU8qWZ+lzYujXcEF4uKDKaLfR9GjrCPD3elTU++RDmynM/rUyZY3UiuPBSxYaFnne+g53+ h7zf2dfWywcXm3ig9lkeQVmeiwYwYJR5XTRoLeh6fpgnCRvmGD8Q5LmGFW0X5ybSlpL2lWuGG1mX 1ZCJDSYlWod+3burlff5VXd68lw9KtGOuX8rdsHM9BUDmfneOtx8jbZMrN2elz4IXtAu16DQzx5v D+V1EQ9a6ZGbal6kS0LcOU1opr5AEA34swz4tZous8vViyuZU4i5vlkIv9AvkzcHbfBnXQbW+VPb 6mROruC2Ql2XH8xwDI9oh6Lqn3BGPxST/TE41q0tNKlempWh96efffyPa8ddGvmkGEus3KOOhleC 0KfREvO0UuNVNR1WefrKW6hLcFPyPn1BKHqz2lPxd6vpl/XU72BgPNzd9zv7P9wZ5ZUYWAe+1c3P pw5Qt37zpNyKo25t8VBTEYSwhV+kVbCW0V2aJbgO+B43yFEi+Yba1Nd1huTUyu+UbZ7/lAo8ORJe Jvq0TbXtysRD85J2f1Si2KVZk7akH08Xo2OcF5ZfE9kkza8/cNIwXtRSd3zK+DkPdt5CSNWd7xAV XODsaBm7t5OCFq7omYrynCY5Z89JeEB0NzxxTwgXEMVH7/dSx/Y1Nb4xfcCXbA/fVBx0zWR7bdPt Ig76rdXYlXI3haIXqn/ewJkeUPoWJnNFGmmSnQIBXB9sKsKZtkLduaqw07DyfM+yzR129ToUxXQW YmZ/9KIiApUx8LG3kbCQdMr8k+KpHN/18TNZkXT0pgVAfE5imn8Autd6ArVwkVC8NzkM2SzTVJaZ JWnuUyJ181FRlalyMaP2ELFQ9QpNopQYt8LgPXT/qFUTH8x+ObH0gTF4lnEY2nP2/GY7HNmDNTMe kOdB9qPQUTZwVOwtDfP5ovSc3pZA3alwK7e7G9ewq3+oAnYw0zGwM5+SHwFt4XireBNbIfFQFbba 551pG3TTfREVbUuPOLPFFFCoH2weTMFblfwfhrbfQhvWMdSRMRM2nrXs8b+wsZjf3a25IYF9VLj8 nFea+JMPnFqAOu/B0bUfE8N2HZJbt7WRELHc8jiX/D5qHp1ZS4AiQFMW9bx/Vig6H1iRsCiZpF5Q 0JO4cK/INO2oQ6MVWwuEaytRHNGSUaQd/9fvHE0YeZZV8QAUSxBLP6kcdxa4FfKXrlx6nwaxd3S/ NRSfRV+FAPSlWH/il7F90TedOibTV1AQvRAlJSfd/Xr9MbmxnKjBhF3O1JiLv11bRBI9V4m0YcX2 lmQE+5tHI4i/2Fa4URATENvrO/u6s5xmoNMiw1YPDzOQ47fmn2T1GXy+09YzhIuaqJB8tmkYs5dV 68D0Cv33utFIH3bYqllbNXZ+z/qfTXDf8N07vi1GYi16wdMEXpSRoI/o/TNNdXAQv2CgFhu3EAKw 1/HRc7QR03Tchep5mNk/sC01lDx1CveoX2Rbr0oifEvaxHf7xKL7N3MDpqGQtAiRWTRRs078tBD3 EKtzHtOXrn18WUR19c+8LDh3GYl4LgZ5lPCry2FstWYiuhyuQAXS/N+bGVx7eJ+mvXhFs870H9yO cWE6tvAfTlNNWwndd522f++A5wqS01CQXbYw0daxO/2Wc1wrR+rcIThREYm4PVC+RFhWPbF9QMIU 2NYi2lob2lfatJoXlVr2tEHkpLaCvaMeVrFzkaPlpn/9cLu+UUsXpcsTqAi3sV8zUjMecN1/Qdax d7O7zAJVRJxxe9HQlsZqIoxQtnWwsPGWcToVNt8mlhBVZrBeWghR/R0uwNiFW3NIciqTTtM0fL3N UBjDs/Ez0z24ceywapqx/fTRBKuREeFP6P1+cxC9cNMqHGHe/tlRmqww0aaHLIeSAR/w8awQ1lKm /sGYcrkFcAtctHr1JaIWFrbysPfoEO1UUie9ndlwGDvw5mcy8zm1I8Sgj/fT8FvXcBr08P3Q13Xz 801QdaEmff8a0zAKx+RpAXzQdp+F2Drm6WU9t7WwH0xxNC4rH4QdIpkNAbpu1NFFcTg9wBje/tea dToXkL1FNIjbV4pfMLXw0DAKpzLUGr8ZU3G54jnFdy1wWUeP4hqcBn27XZ0VhOxAAH5Ofm5UN1TT tK8W1WtK49obUZVXGzgfzSQZLN/TYd//XbGWVFhvWkZz3Rta5RI/XzctdbUqOPS6Knv0WNK4Y1Id aFjc1uo2DhWONqF+JCPS+Qk4E8gC0m8xB5tCO2Jf/FCQd4+Rt92cGz1csRcvMdPdf/1bj3FXb5Mf fZ08v4gPEffcvB+U4jKDFZJgGkL3fdnePBz93B2fHR2dtEPiIpw9PH1d/J1/VLu9fRwc/R09PF1e vWCk/b38Jkacvb5iGUIicpH5PTm/X3xfn2d9mF1+GN0cTl98vHw//VxcxiCLKzy4lR4bvh26ufx7 viamAkLdd30J3TzdXmx9HH1dfbyiHT08uX09nBwQ8DBQnb+8PfidP3/8fP7ZgmMmoB9cPDUcvN8f nD+8vFn83vydvIbDS0j2z514Hf2dP38Yup0dmzDWMwv8y/zcX/P4eb7fuP3ikHimH13cP3tLnfP9 2f5Rsp99ndSo0MAwfVTZ3x+fkJ+f68vLU9DBxB5YvlXa3RbZMOarBmRdv75f8NwUPrUb+r2iw2Lg fzxUD1+4X32fu/6dHVjfn15evxEdwj+FNsLEIh0ephCFanr935k7E39clD1Wu3f+vphcHaYibaK4 v1x9n/48+Rw1XFVctfz+W4lfPVo/I9CWMzz8OVy4WHn9m98tYJviHbscwNBoy4J6HSQ8XT+dTDze hsaGClJ22Vwf3bhZ6sGceJ941dwpGFYYYgCZ+dmxnZmZnr38ViVc+FuQqBIfG1jfC2KkHT9Vgmpr SEycPJ38flgStb2UuP4d/zygQtP4LcAee/p+9Ru3vJnaOX7w/q9Aum42t+ScHIK9I14P8r4//bz8 tN392UNSkj+dndqdfD2+A6hQpl3I+D9dfHTCNm27H/4Qvc53/V77HADi+Oy+/N/eWVx6e1b+/1md Obw8eSDcxgVfu3O9KVTCMry8+riqUOaG2Fz//Pi4mcK9eLa6P6IwJgKQ0ZxYnLmUFVDUnzlZdLWe uYKo6upAvnk7s9kZmVpRvZy+eTUPBlkR9j89nR9/4sWq19kelT/Uv+cY61zKU3q8X1442l9+/Qd8 WZLBW/9PmDMd9R3+fu7cHLz/HNzY38IcxbwfHP4/u9ywIul/PPzFOHMitZ4b2tBXOnzfXdndv5zu QOXSdf7um3U8/Jx+HX4+7f+uGHYQAuoxGd99n1h9vPv71Z0WAOBySRtb73afpVT8PZ+9P2d2uLA8 vZ+A3f1dCrEz/xwdaB8LAUtEy7gf/D8R32Tc/CU0SeSIXNxCkvw2iXICD6/+Ht2eHBb/mT48uN0b 3mA+gqgsV8O1fC5PiN0cEtUBULq9WNwIXFuefJxAh2KHTVkaH/z2dP2YfbN9ZDNcfatLpkb8j/fz LlMdU/h1ftUrVRFoAI89XqZ9fqcRG0dSC/Ret3nkiDcFE8Mff3Iz/x5QsTASXtP2VRxRUnweHY22 6Ss8qBhonP8fvrsX1n19ABMOCGC5MbrhMj9cMpP1g7VCefzdPB99nT1cvkkjOhv+ujy/3vTfnF6c TXUwEPvS/N4cvh94at7cuQvG9JzKntt63FsYUskdtYrE7+SQwnCGXvlVinQxMn+8/zm2eBvvdD/f 38BW+LgP3fzWFQrf2GK/OtLfHBoSuhwYv14yZqXLnDvfv0u/uCq7ftufOXzRl0J8JR7xf9pZ/+zM GD5P2qPGVRifnP7/3l/cfL2/pKZLK5fJbJz3VDi2Oye8pCInPN2xTwtH/R38C3x/FzL2Jvdwfhkw K911XXK7Vqjbb0QcNZ798CWzgbNCLZWd12c4/wi5/th4X22YUlj4P7N3HZfM1fX+P/y5CsbLYNn6 fPkSeridvVqvWNrHCQxWK6w4WHR0ZzyRHoCWEM0Y/1M8G07oWsTb1vY2o5dGxhMKlz/8e5xctAN/ 5R9b2RiWE+vWDTvfvlzaXBS8efN2ynB5/0xcPxpdHri+NBEGM8zKvD8uWcjSX05lvL9Q+T/GP/wW ZsiEbubeElzGfTm50id2Y90/fsU9+50a/7U9dV2+6vDSyXLu2RF93iRdt70cQokC5ZJY/re/Hs+v XVOYuT+wLjn+NRUVgiKsWKm7/zn0kDE0EPQovzQ0kVS05SN0IKOem5sJP3yiLh0cAuiDTeMYHB9t DZU+vV+938pdzNIxjo9J1RAodbkU0riaOZs8H44aYHDWSCl1mp/JnGNWNipLHZshlrt9YR08wQ2D e8v8HkXdEb1CyWBWQq8/OxwSCHWGqT3V4jB/MYTffL5RXx3rUBivJh043ha9X6I+nzPCz2G/m6Y9 2PkXc/jr+bxGQXGbwPO3eYp8PS1XDhhWfVjDFFaHK2sduXx+Kfyfln/W5DL3ECNdnP/8fJ+/Pd1c zLgUcP8G6UxW/BxfDBqSo6yTy7cHNtXCnECffSSr1448edGi3A2uhUucc97Mo9GfNwonvWqDi6hc iMSJA/OetpDVlfnQGavDrTK+16E/3htajQrYC8Vtw3wZOnkLrx7WNpYZ8h3d1x1c3Mobh4QY4819 5VD+HX6952WHlnHB3pfyyjxQ+9vejPWdt15oub4WCoMWDNz5fL96glDQHnbNR4hOdV+9+ps7ZqY2 HDxSPXHoRNYQ2129m1f+H1YuQusfe0qfGBy+GF50f1xfaI/dyrTeHzwJ0/6+HhWd8T2wc0gQpD2U Gbi0ntyhOIvxtJLib5oIinZXfPCdwsgAcdVQzA4ufDaS5+4vRzx8gP9enPYeg8oS3suZj77mb3k2 TpIxFAbdeWJtLPweUOpiXnaXN3rYuzT1epU+GEL+UaJtstfdu1z5/vh+1V2ZxnykWyKDUpb9utn5 PdRfOVSM9XyeeXx5fgY98PwntQZeGSF4H4AIEIrotTmUkZ+CkPmYPv61wmicZF+2qx5ceTrwVgPI 2FQ9EdFdkc9b2V5/oF33vYZOGtIx5Jdo+byokt1/xrXx3Bn8Hv10/Xm4/DtaHt+c0k1a/MU93tZY 8E7sVyn/ZisCvEaZiKepK2RZch31GU60YR2e+jDwrePxmX+e/z9Csf14guJ2mn+R+fk5WMGcGztf jt1WwB4CXru+4F/C3kwdKhs9Bt3+soiQ1pnkO1/d31s/ovgWbs7XFn7rRR6cHl+cezyA8ySlXhlt MNaN/8cnuz35AD8CxNOwuRX5o18e/xCoh5HyMKf0p1l99vn8XvAH1lbodQKVeT7521oc6/BZiz0U Qady8zSpO5lcvh5+Z2ZCo0KCYrJX4L0CjX+eeWfgNAK3oIJiGwTYljUfHD2YNdBUVH0cH3lv2DwE 4fYcC52EP0uSnuw5iQJJ0Bpdml8bPgKc0ZpE/BG4jrHc0pb+hFZsd1neugZe35AS/B1YhJw5v56z K0U19fE5GDfpXyBKLEHicZ+p/GvAgyJ4XQD8/h7+vr4mDYnmeV8g/FgUnEFbmCGzEDhmvxu9cYZD HLlaEahbWIp86/wRsPCCS2AHqRr/F163ed6/ev0/VFBgd1t++x8eWv/Jt7u4p38wmj+7rRjhkNkY h/w+uetx0Yw1wB0d1/puRjBJYyDMQv1MHkl7XnmHdtCLNQ2ds53y+bdmy780h18eKtgQSptC1tz3 VL9XNbsE+HGZfTo4e+gEAqsZItc93aA+4kCYohXdYuXQZuzffIpzHB9+8L027JRrieKebhW7ktIf 3ih5oFvY3b0XQNh4m7+dInc2OP9mNTyds8gaPsNwEI1d7ET93DxgBX69oq3snmKgGp99JT9DqGCX 0/AHfP5P6pR8RP//C2H2qTz8IM1ivz2fnWI9K4Kgtb2/zr+/YwKOG91CBIL1quGO4hriXALd/eKS /bnalX179xnC1kIvGo9iOkL8hp3iYtxyHQIP/Ly9fWLC+sP4dZHCYsxiSF2CANlinGYoGimhPRVO NAw7pXVCDb+/owCce90EnZrh/wK+/Z48fvX7/wbu7ykHufLm0qqnKi28YR0YBg08MisUOB0KBlAl oUSe6vH6Myd5/uCCouIKHWKi/mIiIuJiIiLioqJCgqJilLWFYL4A8EYAjb4AIPn/V4PN/+l6AQAA kJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJ g+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR 2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPC BIkHg8cEg+kEd/EBz+lM////Xon3uSsEAACKB0cs6DwBd/eAPwt18osHil8EZsHoCMHAEIbEKfiA 6+gB8IkHg8cFidji2Y2+ANAHAIsHCcB0RYtfBI2EMAAACAAB81CDxwj/lowACACVigdHCMB03In5 eQcPtwdHUEe5V0jyrlX/lpAACAAJwHQHiQODwwTr2P+WlAAIAIPHBI1e/DHAigdHCcB0IjzvdxEB w4sDhsTBwBCGxAHwiQPr4iQPweAQZosHg8cC6+Jh6aol+f8ACsm5HBEBACPkNACBNA4d01BPLADB BA4bi9uL0oEEDlyLLgI45Dj4hNPi3iwAcQCoWOld/v//BuLWO/aG9nUA6U/+///QdAAI5OlF/v// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQQCACMEAgAAAAAAAAA AAAAAAAA0RAIAJwQCAAAAAAAAAAAAAAAAADeEAgApBAIAAAAAAAAAAAAAAAAAOYQCACsEAgAAAAA AAAAAAAAAAAA8RAIALQQCAAAAAAAAAAAAAAAAAD8EAgAvBAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA CBEIABYRCAAmEQgAAAAAADQRCAAAAAAAQhEIAAAAAABSEQgAAAAAAFgRCAAAAAAAAQAAgAAAAABL RVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1QUi5kbGwATVNWQ1JULmRsbABVU0VSMzIuZGxsAFdT T0NLMzIuZGxsAAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABS ZWdDbG9zZUtleQAAAFdOZXRPcGVuRW51bUEAAABwdXRjAABTZXRUaW1lcgAAAAAIAAwAAAAiMQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------------FBX6N7HJYDML8R-- From herbert@gondor.apana.org.au Wed Jul 7 04:03:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 04:03:42 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67B3Ugi003192 for ; Wed, 7 Jul 2004 04:03:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiACs-0005UR-00; Wed, 07 Jul 2004 21:03:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiACp-0006nO-00; Wed, 07 Jul 2004 21:03:15 +1000 Date: Wed, 7 Jul 2004 21:03:15 +1000 To: Masahide NAKAMURA Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-ID: <20040707110315.GA26100@gondor.apana.org.au> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707155602.4698121a@localhost> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 814 Lines: 24 On Wed, Jul 07, 2004 at 03:56:02PM +0900, Masahide NAKAMURA wrote: > > I've updated the patch and it can build with 2.6.7 kernel headers. > Can you check it? > > http://www.linux-ipv6.org/~nakam/ipxfrm-20040707_2.diff Thanks. Could you please change the output of ip xfrm policy/state so that it can be fed directly back in? For example the output of ip ro ls can be fed back into ip ro add. Could you please also make it understand ip x p instead of ip x policy? And there seems to be something wrong with the keys in the output of ip x state. There are too many f's for it to be right. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed Jul 7 06:07:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 06:07:13 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67D75gi016242 for ; Wed, 7 Jul 2004 06:07:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiC8W-0006AI-00; Wed, 07 Jul 2004 23:06:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiC8S-0006zh-00; Wed, 07 Jul 2004 23:06:52 +1000 Date: Wed, 7 Jul 2004 23:06:52 +1000 To: James Morris , "David S. Miller" , netdev@oss.sgi.com Subject: pskb change in dst->output Message-ID: <20040707130652.GA26822@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1303 Lines: 32 Hi James: I'm working on merging the IPsec tunnel encapsulation code so that we have only one copy of it instead of four. In doing so I'm wondering why you changed dst->output to take a struct sk_buff ** from a struct sk_buff *. All of the dst->output functions already assumed that they have exclusive access to the skb. This is justified because all callers to dst_output() makes sure that the packet is neither shared nor cloned. So in practice the calls to skb_checksum_help() from AH/ESP/IPCOMP are never going to unshare the skb. In that case, couldn't we just have a version of skb_checksum_help() that was for the case where the skb is never shared? This would allow us to go back to the single pointer in dst->output. The double pointer is also an eye sore because in most of these dst->output functions, the first access to the skb after skb_checksum_help() usually assumes that the skb is neither shared nor cloned. This is bad because someone in future could assume that dst->output can take a shared/cloned skb based on the fact that it takes a struct sk_buff **. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From cfriesen@nortelnetworks.com Wed Jul 7 06:42:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 06:42:38 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67DgEgi017563 for ; Wed, 7 Jul 2004 06:42:34 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i67Dg6k29027 for ; Wed, 7 Jul 2004 09:42:06 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTAQXN; Wed, 7 Jul 2004 09:42:07 -0400 Message-ID: <40EBFDAE.8070903@nortelnetworks.com> Date: Wed, 07 Jul 2004 09:42:06 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 298 Lines: 12 I have a SOCK_STREAM PF_UNIX socket with no special options enabled using fcntl(). The default with sendmsg() and recvmsg() is to block. With sndmsg(), I can use the MSG_DONTWAIT flag to enable non-blocking operation for that one call. How do I do the equivalent for recvmsg()? Thanks, Chris From jmorris@redhat.com Wed Jul 7 07:58:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 07:58:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67EwWgi019355 for ; Wed, 7 Jul 2004 07:58:33 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67EwMe1020924; Wed, 7 Jul 2004 10:58:22 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67EwM021067; Wed, 7 Jul 2004 10:58:22 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i67EwL4G009723; Wed, 7 Jul 2004 10:58:21 -0400 Date: Wed, 7 Jul 2004 10:58:21 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , Subject: Re: pskb change in dst->output In-Reply-To: <20040707130652.GA26822@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 660 Lines: 24 On Wed, 7 Jul 2004, Herbert Xu wrote: > In doing so I'm wondering why you changed dst->output to take a > struct sk_buff ** from a struct sk_buff *. This was because skb_checksum_help() was changed to potentially replace the skb in the output path. > All of the dst->output functions already assumed that they have > exclusive access to the skb. This is justified because all callers to > dst_output() makes sure that the packet is neither shared nor cloned. Cloned skbs are regularly passed to dst_output(), thus we need to use the double pointer for skb_checksum_help() in case the skb is replaced. - James -- James Morris From hch@lst.de Wed Jul 7 08:16:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 08:16:35 -0700 (PDT) Received: from mail.lst.de ([212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67FGWgi020094 for ; Wed, 7 Jul 2004 08:16:33 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i67FGBQc014357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jul 2004 17:16:11 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i67FGAjq014355; Wed, 7 Jul 2004 17:16:10 +0200 Date: Wed, 7 Jul 2004 17:16:10 +0200 From: Christoph Hellwig To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: [PATCH] fix compiler warnings in mv64340_eth Message-ID: <20040707151610.GA14330@lst.de> References: <20040706105215.GA14731@lst.de> <40EB853E.5000504@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40EB853E.5000504@pobox.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 2087 Lines: 54 On Wed, Jul 07, 2004 at 01:08:14AM -0400, Jeff Garzik wrote: > patch OK, but patch(1) rejected hmm, looks like it was for patch -p0 --- a/drivers/net/mv64340_eth.c~ 2004-07-06 14:26:47.163242160 +0200 +++ b/drivers/net/mv64340_eth.c 2004-07-06 14:48:31.053020784 +0200 @@ -752,9 +752,8 @@ p_rx_desc[i].byte_cnt = 0x0000; p_rx_desc[i].cmd_sts = ETH_BUFFER_OWNED_BY_DMA | ETH_RX_ENABLE_INTERRUPT; - p_rx_desc[i].next_desc_ptr = - (struct eth_rx_desc *) mp->rx_desc_dma + - (i + 1) % rx_desc_num; + p_rx_desc[i].next_desc_ptr = mp->rx_desc_dma + + ((i + 1) % rx_desc_num) * sizeof(struct eth_rx_desc); p_rx_desc[i].buf_ptr = buffer_addr; mp->rx_skb[i] = NULL; @@ -818,9 +817,8 @@ p_tx_desc[i].byte_cnt = 0x0000; p_tx_desc[i].l4i_chk = 0x0000; p_tx_desc[i].cmd_sts = 0x00000000; - p_tx_desc[i].next_desc_ptr = - (struct eth_tx_desc *) mp->tx_desc_dma + - (i + 1) % tx_desc_num; + p_tx_desc[i].next_desc_ptr = mp->tx_desc_dma + + ((i + 1) % tx_desc_num) * sizeof(struct eth_tx_desc); p_tx_desc[i].buf_ptr = 0x00000000; mp->tx_skb[i] = NULL; } @@ -2329,8 +2349,8 @@ first_descriptor->cmd_sts = command_status; first_descriptor->byte_cnt = p_pkt_info->byte_cnt; first_descriptor->buf_ptr = p_pkt_info->buf_ptr; - first_descriptor->next_desc_ptr = - (struct eth_tx_desc *) mp->tx_desc_dma + tx_next_desc; + first_descriptor->next_desc_ptr = mp->tx_desc_dma + + tx_next_desc * sizeof(struct eth_tx_desc); wmb(); } else { tx_first_desc = mp->tx_first_desc_q; @@ -2343,8 +2363,8 @@ current_descriptor->next_desc_ptr = 0x00000000; else { command_status |= ETH_BUFFER_OWNED_BY_DMA; - current_descriptor->next_desc_ptr = - (struct eth_tx_desc *) mp->tx_desc_dma + tx_next_desc; + current_descriptor->next_desc_ptr = mp->tx_desc_dma + + tx_next_desc * sizeof(struct eth_tx_desc); } } From mathis@psc.edu Wed Jul 7 08:32:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 08:32:49 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67FWggi023777 for ; Wed, 7 Jul 2004 08:32:43 -0700 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i67FWS0T001835 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jul 2004 11:32:29 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.10/8.12.5) with ESMTP id i67FWSkh014061; Wed, 7 Jul 2004 11:32:28 -0400 (EDT) Date: Wed, 7 Jul 2004 11:31:17 -0400 (EDT) From: Matt Mathis To: Injong Rhee cc: "'David S. Miller'" , Stephen Hemminger , netdev@oss.sgi.com, rhee@ncsu.edu, lxu2@ncsu.edu, John Heffner , Jamshid Mahdavi Subject: RE: [RFC] TCP burst control In-Reply-To: <200407070546.i675kkPf008128@ms-smtp-01-eri0.southeast.rr.com> Message-ID: References: <200407070546.i675kkPf008128@ms-smtp-01-eri0.southeast.rr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mathis@psc.edu Precedence: bulk X-list: netdev Content-Length: 6647 Lines: 134 Yes, Injong is correct about the problem with Rate Having. I haven't looked at his fix to see if I agree with it, but let me summarize the problem that we never finished (and prevented us from formally publishing it). Basicly if the sender is under fluctuating resource stress such that awnd (the actual window) is frequently less than cwnd (remember this was written BEFORE cwnd validation.) then a loss that is detected when awnd is at a minimum sets cwnd to an unreasonably small value that has nothing to do with the actual state of the network. Since we also set ssthresh down to cwnd, this takes "forever" to recover. The real killer is if the application is periodicly bursty, such as copying from older unbuffered disks or timesharing systems running other compute bound applications (normal for supercomputers). Under these conditions TCP suffers from frequent idle intervals, each restarting with a full window burst (pre-cwnd validation!). If the burst was just slightly larger than the network pipe size, then the packets at the end of the burst are most at risk of being dropped. When the ACKs for subsequent packets arrive and the loss is detected, awnd will be nearly zero, resulting in nearly zero cwnd and ssthresh...... We were in the heat of investigating solutions to this and other related problems (there are multiple potential solutions), when we realized that autotuning is orders of magnitude more important (at least to our users). As the code points out there are other corner cases that we missed, such as reordering and such. In principle I would like to come back to congestion control work, revisit FACK-RH and fold in all of the new stuff such as cwnd validation and window moderation. (BTW I would not be surprised if these algorithms don't play nicely with rate halving - each was designed and tested without considering the effects of the others). Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and forcibly apply it to others. On Wed, 7 Jul 2004, Injong Rhee wrote: > > Hi David, > > Let me clarify the issue a little. In my earlier message, I might have > sounded like accusing rate halving of the burst problem and window > oscillation. I might have misrepresented it a little in the heat of writing > the email too fast :-). In fact, rate halving helps ease burst during fast > recovery as written in the Internet draft. > > The main problem lies in the variable that rate halving is closely > interacting with in TCP SACK implementation: packet_in_flight (or pipe_). In > the current implementation of Linux TCP SACK, cwnd is set to > packet_in_flight + C for every ack for CWR, recovery, and timeout-- Here C > is 1 to 3. But many times, packet_in_flight drops *far* below cwnd during > fast recovery. In high speed networks, a lot of packets can be lost in one > RTT (even acks as well because of slow CPUs). If that happens, > packet_in_flight becomes very small. At this time, Linux cwnd moderation (or > burst control) kicks in by setting cwnd to packet_in_flight + C so that the > sender does not burst all those packets between packet_in_flight and cwnd at > a single time. However, there is a problem with this approach. Since cwnd is > kept to very small, the transmission rate drops to almost zero during fast > recovery -- it should drop only to half of the current transmission rate (or > in high-speed protocols like BIC, it is only 87% of the current rate). Since > fast recovery lasts more than several RTTs, the network capacity is highly > underutilized during fast recovery. Furthermore, right after fast recovery, > cwnd goes into slow start since cwnd is typically far smaller than ssthrsh > after fast recovery. This also creates a lot of burst -- likely causing back > to back losses or even timeouts. > > You can see this behavior in the following link: > > http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B > IC-600-75-7500-1-0-0-noburst/index.htm > > We run in a dummynet without any change in the burst control. You can see > that whenever there is fast recovery, the rate almost drop to zero. The pink > line is the throughput observed from the dummynet at every second, and red > one is from Iperf. In the second figure, you can see cwnd. It drops to the > bottom during fast recovery -- this is not part of congestion control. It is > the burst control of Linux SACK doing it. > > But with our new burst control: > > http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B > IC-600-75-7500-1-0-0/index.htm > > You can see that cwnd is quite stabilized and the throughput does not have > as much dip as in the original case. > > Here is what we do: instead of reducing cwnd to packet_in_flight (which is, > in fact, meddling with congestion control), we reduce the gap between these > two numbers by allowing transmitting more packets per ack (we set this to > three more packets per ack) until packet_in_flight becomes close to cwnd. > Also right after fast recovery, we increase packet_in_flight by 1% of > packet_in_flight up to cwnd. This reduces the huge burst after fast > recovery. Our implementation is trying to leave cwnd only to congestion > control and separates burst control from congestion control. This makes the > behavior of congestion control more predictable. We will report more on > this tomorrow when we get back to the Lab to test some other environments, > especially when we have smaller buffers. This scheme may not be the cure for > all and needs more testing. So far, it has been working very well. > > Stay tuned. > Injong. > --- > Injong Rhee, Associate Professor > North Carolina State University > Raleigh, NC 27699 > rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee > > > > -----Original Message----- > From: David S. Miller [mailto:davem@redhat.com] > Sent: Tuesday, July 06, 2004 8:29 PM > To: Injong Rhee > Cc: shemminger@osdl.org; netdev@oss.sgi.com; rhee@ncsu.edu; lxu2@ncsu.edu; > mathis@psc.edu > Subject: Re: [RFC] TCP burst control > > On Tue, 6 Jul 2004 20:09:41 -0400 > "Injong Rhee" wrote: > >> Currently with rate having, current Linux tcp stack is full of hacks that > in >> fact, hurt the performance of linux tcp (sorry to say this). > > If rate-halving is broken, have you taken this up with it's creator, > Mr. Mathis? What was his response? > > I've added him to the CC: list so this can be properly discussed. > From kuznet@ms2.inr.ac.ru Wed Jul 7 09:00:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 09:00:34 -0700 (PDT) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67G0Tgi024669 for ; Wed, 7 Jul 2004 09:00:30 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id TAA10095; Wed, 7 Jul 2004 19:59:58 +0400 Date: Wed, 7 Jul 2004 19:59:58 +0400 From: Alexey Kuznetsov To: "David S. Miller" Cc: hadi@cyberus.ca, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: bk16 changes to cbq Message-ID: <20040707155958.GA9797@ms2.inr.ac.ru> References: <1088861810.1039.298.camel@jzny.localdomain> <20040705202727.GA21226@ms2.inr.ac.ru> <20040706221317.2f0585d1.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706221317.2f0585d1.davem@redhat.com> User-Agent: Mutt/1.5.6i X-archive-position: 6746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 2604 Lines: 65 Hello! > e1000 would hang the delay scheduler sometimes > > Let me look for the exact email from Stephen. Here it is: > > http://mailman.ds9a.nl/pipermail/lartc/2004q2/012736.html Well, that test was really meaningless. So, Stephen's patch is right. The problem is that Stephen's argument just does not look right and forces to suspect some worse bug somewhere. If netif_queue_stopped(), it will be awaken, so no loss of wakeups can happen. If a device sets stopped flag and forgets to wake up after that, it is really badly broken and this should be repaired, it inevitably will result in stalls. > Jamal read this, and that is what prompted him to say that if > the delay scheduler was made classful instead of "pretending" > to be, the bug mentioned in Stephen's email would not occur. It is not related issue. sch_delay allocates private fifo qdisc, which is quite pointless (it is not accessible for tuning anyway) and complicates things a lot. F.e. if it copied tbf structure, it would not have to use ->requeue. And if it is planned to be tunable and replacable with something else, it should be classful. > I do not understand things fully. I think it would help if, for example, > each of the qdisc and classification operations had some comments > describing the exact semantics of each ops->method. For example, > what does requeue do and what is it indicating with each of the > possible return values. What is expected of it? What kind of state > is it allowed to leave the queue in? Ideally, ->requeue() should return queue to the state before ->dequeue(), undoing all the state. When it fails (which is possible only due to some fault sort of failed memory allocation. In the case of sch_delay, which uses requeue of fifo it is absolutely impossible), it drops skb and returns NET_XMIT_DROP or NET_XMIT_CN. Stephen's statement: > Also, if requeuing the packet fails, it is probably because the queue became full > by a racing enqueue. is not true. Everything between dequeue() and requeue() happens under dev->queue_lock, so there is no place for races there. Simple qdiscs never fail. cbq cannot fail too, the place where it returns NET_XMIT_CN is rather for safety when some user drops lock somewhere between dequeue and requeue, which is not allowed actually. > So the right thing to do is to go back and try again In theory he is right. sch_delay just have no choice. If it just returns, when ->requeue() failed by some unknown reason, sch_delay would stall. But, again, sch_delay uses fifo, which never fails in any case. So, it does not matter. :-) Alexey From shemminger@osdl.org Wed Jul 7 09:55:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 09:55:17 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67Gstgi027074 for ; Wed, 7 Jul 2004 09:55:15 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67GshG29114; Wed, 7 Jul 2004 09:54:43 -0700 Date: Wed, 7 Jul 2004 09:54:43 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] deinline sock_i_uid,sock_i_ino Message-Id: <20040707095443.7b54b63d@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3045 Lines: 109 The sock_i_uid and sock_i_ino functions are only called by /proc type interfaces, so they don't need to be inlined. Also, the inline functions writeable, rcvtimeo, sndtimeo are test for value functions that don't change their argument. Signed-off-by: Stephen Hemminger diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h 2004-07-06 13:41:40 -07:00 +++ b/include/net/sock.h 2004-07-06 13:41:40 -07:00 @@ -917,25 +917,8 @@ write_unlock_bh(&sk->sk_callback_lock); } -static inline int sock_i_uid(struct sock *sk) -{ - int uid; - - read_lock(&sk->sk_callback_lock); - uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0; - read_unlock(&sk->sk_callback_lock); - return uid; -} - -static inline unsigned long sock_i_ino(struct sock *sk) -{ - unsigned long ino; - - read_lock(&sk->sk_callback_lock); - ino = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_ino : 0; - read_unlock(&sk->sk_callback_lock); - return ino; -} +extern int sock_i_uid(struct sock *sk); +extern unsigned long sock_i_ino(struct sock *sk); static inline struct dst_entry * __sk_dst_get(struct sock *sk) @@ -1219,7 +1202,7 @@ /* * Default write policy as shown to user space via poll/select/SIGIO */ -static inline int sock_writeable(struct sock *sk) +static inline int sock_writeable(const struct sock *sk) { return atomic_read(&sk->sk_wmem_alloc) < (sk->sk_sndbuf / 2); } @@ -1229,17 +1212,17 @@ return in_softirq() ? GFP_ATOMIC : GFP_KERNEL; } -static inline long sock_rcvtimeo(struct sock *sk, int noblock) +static inline long sock_rcvtimeo(const struct sock *sk, int noblock) { return noblock ? 0 : sk->sk_rcvtimeo; } -static inline long sock_sndtimeo(struct sock *sk, int noblock) +static inline long sock_sndtimeo(const struct sock *sk, int noblock) { return noblock ? 0 : sk->sk_sndtimeo; } -static inline int sock_rcvlowat(struct sock *sk, int waitall, int len) +static inline int sock_rcvlowat(const struct sock *sk, int waitall, int len) { return (waitall ? len : min_t(int, sk->sk_rcvlowat, len)) ? : 1; } diff -Nru a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c 2004-07-06 13:41:40 -07:00 +++ b/net/core/sock.c 2004-07-06 13:41:40 -07:00 @@ -711,6 +711,27 @@ atomic_sub(skb->truesize, &sk->sk_rmem_alloc); } + +int sock_i_uid(struct sock *sk) +{ + int uid; + + read_lock(&sk->sk_callback_lock); + uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0; + read_unlock(&sk->sk_callback_lock); + return uid; +} + +unsigned long sock_i_ino(struct sock *sk) +{ + unsigned long ino; + + read_lock(&sk->sk_callback_lock); + ino = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_ino : 0; + read_unlock(&sk->sk_callback_lock); + return ino; +} + /* * Allocate a skb from the socket's send buffer. */ @@ -1379,6 +1400,8 @@ EXPORT_SYMBOL(sock_setsockopt); EXPORT_SYMBOL(sock_wfree); EXPORT_SYMBOL(sock_wmalloc); +EXPORT_SYMBOL(sock_i_uid); +EXPORT_SYMBOL(sock_i_ino); #ifdef CONFIG_SYSCTL EXPORT_SYMBOL(sysctl_optmem_max); EXPORT_SYMBOL(sysctl_rmem_max); From util@deuroconsult.ro Wed Jul 7 10:41:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 10:41:41 -0700 (PDT) Received: from hosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67Hf9gi028582 for ; Wed, 7 Jul 2004 10:41:30 -0700 Received: from hosting.rdsbv.ro (hosting.rdsbv.ro [213.157.185.164]) by hosting.rdsbv.ro (8.12.11/8.12.11) with ESMTP id i6771UaA007321; Wed, 7 Jul 2004 10:01:30 +0300 Date: Wed, 7 Jul 2004 10:01:30 +0300 (EEST) From: Catalin BOIE X-X-Sender: util@hosting.rdsbv.ro To: jamal cc: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler In-Reply-To: <1089164179.1039.26.camel@jzny.localdomain> Message-ID: References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040706090906.4ff6fb73@dell_ss3.pdx.osdl.net> <1089164179.1039.26.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 2824 Lines: 60 On Wed, 6 Jul 2004, jamal wrote: > On Tue, 2004-07-06 at 12:09, Stephen Hemminger wrote: > >> Your examples made me think about this more. The netfilter seem best >> suited to things that effect the flow of packets (dropping, reordering, >> even corrupting), and the qdisc seems best when the timing needs to change. > > Some of the attributes you are trying to control need queueing; no doubt > the best spot to do queueing is on a qdisc. Delays, and reordering for > example are ideal. Rate control as well fits here. There are other > qdiscs which have done a really good job at rate control hence my > arguement against you doing it - you will either not do a better job at > it or if you do a good job you will be replicating what they already > did; just stash your qdisc in another qdisc which can do a good rate > control job (CBQ, TBF, HFSC, HTB) - we are flexible enough in Linux. > > Depending on where you want to do things, netfilter may be a good > candidate (example IP protocol) or things that dont need queueing. > The examples i gave are more powerful than anything netfilter can do at > the moment though with only caveat theres only two "hooks". > >> The limit match in netfilter is not the same as the rate in the qdisc. >> The netem scheduler acts as if the link is a slow fixed rate. The netfilter >> limit is usually targeted to drop packets over the rate which is not the same. >> Reordering is also hard without going out to a user log or building a custom >> target. > > Not sure what the netfilter limit target is - i suspect its something > that limits based on a group of flows. You can still do that with a > fwamrk at the qdisc level. Reordering needs a queue. Even the example i > gave uses a queue that resides on the dummy device. > >> So, you have convinced me that loss is unnecessary but not the rate, or delay. >> If we can figure out how to re-ordering with netfilter then that could go too, >> which would make it possible to use a layered qdisc again. > > I think keep the reordering aspect of it unless it is very complex. The > delay is a must. If you can add configurable jitter to it that would be > a big bonus. Keep the randomization. Duplication, dropping, bit error > injection, and rate control are the ones i didnt see belonging there > mostly because they can be done better elsewhere. > Again this is just opinion, if you think that theres no complexity in > the architecture, by all means keep all those features - my > recommendation is to pick a few things that will work well and implement > them well. > > cheers, > jamal I suggest to keep duplication because: 1. Adds 5-10 lines of code and no complexity 2. It's very easy to use it attached directly to a device. Thank you. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From shemminger@osdl.org Wed Jul 7 11:07:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:07:12 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67I7Agi029215 for ; Wed, 7 Jul 2004 11:07:10 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67I6rG11567; Wed, 7 Jul 2004 11:06:54 -0700 Date: Wed, 7 Jul 2004 11:06:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bert hubert , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040707110653.7c49bef1@dell_ss3.pdx.osdl.net> In-Reply-To: <20040706154907.422a6b73.davem@redhat.com> References: <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706131235.10b5afa8.davem@redhat.com> <20040706224453.GA6694@outpost.ds9a.nl> <20040706154907.422a6b73.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 456 Lines: 8 I do not argue with that the correct thing to do is to use window scaling and find/fix the poor sop's stuck behind busted networks. But: isn't it better to have just one sysctl parameter set (tcp_rmem) and set the window scale as needed rather than increasing the already bewildering array of dials and knobs? I can't see why it would be advantageous to set a window scale of 7 if the largest possible window ever offered is limited to a smaller value? From shemminger@osdl.org Wed Jul 7 11:08:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:08:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67I8cgi029542 for ; Wed, 7 Jul 2004 11:08:39 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67I8KG11791; Wed, 7 Jul 2004 11:08:20 -0700 Date: Wed, 7 Jul 2004 11:08:20 -0700 From: Stephen Hemminger To: Masahide NAKAMURA Cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-Id: <20040707110820.5ac56fa5@dell_ss3.pdx.osdl.net> In-Reply-To: <20040707155602.4698121a@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 917 Lines: 27 On Wed, 7 Jul 2004 15:56:02 +0900 Masahide NAKAMURA wrote: > Hello Stephen and Herbert, > > > > > On Sat, 3 Jul 2004 19:46:32 +1000 > > > > Herbert Xu wrote: > > > > > > > > > I'm in the process of writing two new modules fo ip(8), ippolicy and > > > > > ipstate which will be a NETLINK based replacement for setkey. > > > > > > > > > > In order to do so, I need to get libnetlink to speak the XFRM protocol. > > > > > Thus I've added a new nl_open function which allows the protocol to > > > > > be specified. > > > > > > > > I agree with it. > > > > > > > > Anyway, I have code for ip(8) for similar reason. > > I've updated the patch and it can build with 2.6.7 kernel headers. > Can you check it? > > http://www.linux-ipv6.org/~nakam/ipxfrm-20040707_2.diff > Got it, it builds and is in the current bk tree; will go out with next snapshot this week. From shemminger@osdl.org Wed Jul 7 11:11:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:11:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67IBigi029986 for ; Wed, 7 Jul 2004 11:11:45 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67IAtG12305; Wed, 7 Jul 2004 11:10:55 -0700 Date: Wed, 7 Jul 2004 11:10:55 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> In-Reply-To: <1088824432.1043.271.camel@jzny.localdomain> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 177 Lines: 4 Ok, I'll bite how would you do: Rate limit packet egress on a ethernet device (eth0) so it looks like a slow DSL link (25 Kbps) by not dropping packets but by pacing the data. From hadi@cyberus.ca Wed Jul 7 11:11:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:11:41 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67IBegi029985 for ; Wed, 7 Jul 2004 11:11:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BiGtO-0006MJ-0A for netdev@oss.sgi.com; Wed, 07 Jul 2004 14:11:38 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BiGtM-0002CH-Kn; Wed, 07 Jul 2004 14:11:37 -0400 Subject: Re: bk16 changes to cbq From: jamal Reply-To: hadi@cyberus.ca To: Alexey Kuznetsov Cc: "David S. Miller" , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <20040707155958.GA9797@ms2.inr.ac.ru> References: <1088861810.1039.298.camel@jzny.localdomain> <20040705202727.GA21226@ms2.inr.ac.ru> <20040706221317.2f0585d1.davem@redhat.com> <20040707155958.GA9797@ms2.inr.ac.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089223892.1026.309.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Jul 2004 14:11:32 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1051 Lines: 29 On Wed, 2004-07-07 at 11:59, Alexey Kuznetsov wrote: > Hello! > > > e1000 would hang the delay scheduler sometimes > > > > Let me look for the exact email from Stephen. Here it is: > > > > http://mailman.ds9a.nl/pipermail/lartc/2004q2/012736.html > > Well, that test was really meaningless. So, Stephen's patch is right. Not totaly Alexey. Its like you said before, the code there was an optimization. Heres a scenario especialy with drivers returning 0 on everything in their txmit() (discussion going elsewhere with Jeff Garzik): Driver does netif_queue_stop() because of full ring and returns 0. qdisc gets called and it decides to throttle. In that case if it starts watchdog (because it doesnt look at device state). That would be two possible future reschedules of device. One because of qdisc throttle timer and another because of netif_stop. Its not much code difference or cpu cycles, but still an optimization for that case. OTOH, this would not happen if the driver returned a 1 along with skb (the way e1000 does). cheers, jamal From shemminger@osdl.org Wed Jul 7 11:19:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:19:54 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67IJngi030799 for ; Wed, 7 Jul 2004 11:19:50 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67IJbG14066; Wed, 7 Jul 2004 11:19:37 -0700 Date: Wed, 7 Jul 2004 11:19:36 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] mark CSZ scheduler as broken Message-Id: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 636 Lines: 17 Since the configuration help for CSZ is broken, and other documentation says it just doesn't work. Why not mark it as broken to make it obvious? Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/Kconfig b/net/sched/Kconfig --- a/net/sched/Kconfig 2004-07-07 11:18:01 -07:00 +++ b/net/sched/Kconfig 2004-07-07 11:18:01 -07:00 @@ -51,7 +51,7 @@ config NET_SCH_CSZ tristate "CSZ packet scheduler" - depends on NET_SCHED + depends on NET_SCHED && BROKEN ---help--- Say Y here if you want to use the Clark-Shenker-Zhang (CSZ) packet scheduling algorithm for some of your network devices. At the From hadi@cyberus.ca Wed Jul 7 11:29:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:29:30 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67ITPgi031314 for ; Wed, 7 Jul 2004 11:29:26 -0700 Received: from mx01.cybersurf.com ([IPv6:::ffff:209.197.145.104]:11417 "EHLO mx01.cybersurf.com") by linux-mips.org with ESMTP id ; Wed, 7 Jul 2004 19:29:25 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BiHAX-0000mE-GA for netdev@linux-mips.org; Wed, 07 Jul 2004 14:29:21 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BiHAT-0004tA-0S; Wed, 07 Jul 2004 14:29:17 -0400 Subject: Re: [RFR] gianfar ethernet driver From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Andy Fleming , Kumar Gala , netdev@oss.sgi.com, dwmw2@infradead.org In-Reply-To: <40EB8B84.7040301@pobox.com> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <1089170282.1038.80.camel@jzny.localdomain> <20040707032913.GA1822@havoc.gtf.org> <1089171693.1037.87.camel@jzny.localdomain> <40EB8B84.7040301@pobox.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089224952.1027.340.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Jul 2004 14:29:12 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1797 Lines: 58 On Wed, 2004-07-07 at 01:35, Jeff Garzik wrote: > > > > True returning 0 this is not wrong; it > > results in an extra call in the layer above the driver. > > (I was trying to point that out in earlier email) > > er, I'm confused now? > > Every single ethernet driver returns zero, when it has queued a packet > to hardware :) That's the common case, I would hope it doesn't result > in additional work. Its a small optimization. In either case, the xmit() will not be invoked again until device wakes up - so both models are fine from that perspective. In the case of returning a zero there will be a few more lines of code executed trying to see if qdisc has a packet before realizing the device is stopped and requeueing that packet. Not something to sweat over to be honest. If i had 1000 hours available and nothing fun to work on (theres always something fun to do) then i will start changing things. I think you should encourage new drivers to use the return 1 scheme though. > > > > Ok, I overlooked fragments. I think it would be useful to capture this > > in the doc you were preping. BTW, why can you figure out the fragment > > count? If you can then the check for number of descriptors availabel > > could account for that. > > In one design, you can say > > queue packet > if (free descriptors < MAX_SKB_FRAGS) > netif_stop_queue() > return 0 > > That design wastes descriptors, but ensures you always have enough room > when ->hard_start_xmit is called, and thus ensures you never have to > return 1. > > Another design, that attempts to use more descriptors, is > > if (free descriptors < skb->frags) > netif_stop_queue() > return 1 > > queue packet > > if (free descriptors == 0) > netif_stop_queue() > return 0 > Looking good. cheers, jamal From hadi@cyberus.ca Wed Jul 7 11:44:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:45:00 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67Iivgi031926 for ; Wed, 7 Jul 2004 11:44:58 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:32420 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Wed, 7 Jul 2004 19:44:56 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BiHPZ-0000M6-Lh for netdev@linux-mips.org; Wed, 07 Jul 2004 14:44:53 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BiHPV-0007Cl-Ol; Wed, 07 Jul 2004 14:44:49 -0400 Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler From: jamal Reply-To: hadi@cyberus.ca To: Catalin BOIE Cc: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com, lartc@mailman.ds9a.nl In-Reply-To: References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040706090906.4ff6fb73@dell_ss3.pdx.osdl.net> <1089164179.1039.26.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089225886.1022.383.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Jul 2004 14:44:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 581 Lines: 20 On Wed, 2004-07-07 at 03:01, Catalin BOIE wrote: > I expect that duplicates of packet will not going to sch_netem, right? > I'm asking because I have a pactch pending. I dont think that should stop you from adding the feature. To answer your question, yes, duplicates can be sent to that qdisc using the tc extensions. > > I suggest to keep duplication because: > 1. Adds 5-10 lines of code and no complexity > 2. It's very easy to use it attached directly to a device. Go ahead. The tc extension creation of duplicates can be used with other qdiscs as well. cheers, jamal From hadi@cyberus.ca Wed Jul 7 11:57:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 11:58:01 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67Ivxgi032371 for ; Wed, 7 Jul 2004 11:57:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BiHcC-0001Bw-Ke for netdev@oss.sgi.com; Wed, 07 Jul 2004 14:57:56 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BiHcB-0000Zs-8B; Wed, 07 Jul 2004 14:57:55 -0400 Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl In-Reply-To: <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089226667.1027.411.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Jul 2004 14:57:48 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 924 Lines: 26 I seem to have hit the jackpot - all my emails to netdev are showing up and on time too. On Wed, 2004-07-07 at 14:10, Stephen Hemminger wrote: > Ok, I'll bite how would you do: > > Rate limit packet egress on a ethernet device (eth0) so it looks like a slow DSL link (25 Kbps) > by not dropping packets but by pacing the data. Doesnt TBF work? rate 25kbit burst 90k should probably do it. Maybe i misunderstood the question. You may be able to avoid dropping but dont think you can guarantee it simply because you have finite buffers. At some point you will congest that queue and packets will be dropped; and if you dont limit your queue buffer size, sooner than later you are bound to hog all the system memory. Having said that, i have never seen a good arguement for why pacing traffic vs dropping to initiate a slowdown is better than the other. So in that case, a policer/meter should suffice. cheers, jamal From hirofumi@mail.parknet.co.jp Wed Jul 7 12:25:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 12:25:45 -0700 (PDT) Received: from mail.parknet.co.jp (mail.parknet.co.jp [210.171.160.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67JPUgi003905 for ; Wed, 7 Jul 2004 12:25:41 -0700 Received: from ibmpc.myhome.or.jp [210.171.164.65] by mail.parknet.co.jp with ESMTP (SMTPD32-4.10) id AF326A410152; Thu, 08 Jul 2004 04:25:38 +0900 Received: from devron.myhome.or.jp (root@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i67JPSkS029056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jul 2004 04:25:28 +0900 Received: from devron.myhome.or.jp (hirofumi@localhost [127.0.0.1]) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i67JPSqc003270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jul 2004 04:25:28 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) id i67JPQYA003267; Thu, 8 Jul 2004 04:25:26 +0900 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] net/ipv4/ipmr.c fixes From: OGAWA Hirofumi Date: Thu, 08 Jul 2004 04:25:26 +0900 Message-ID: <877jtfmxg9.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hirofumi@mail.parknet.co.jp Precedence: bulk X-list: netdev Content-Length: 2072 Lines: 70 - pim_protocol warning fix - ipmr_vif_open() and ipmr_mfc_open() allocates the memory, so it should use seq_release_private(). - ipmr_mfc_seq_xxx is using it->cache, in order to control whether unlock should be do or not, but it->cache was not initialized in ipmr_mfc_seq_start(). So it can point the previous state if user did seek(). This become to the cause of twice unlock. Signed-off-by: OGAWA Hirofumi --- net/ipv4/ipmr.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff -puN net/ipv4/ipmr.c~ipmr-fixes net/ipv4/ipmr.c --- linux-2.6.7/net/ipv4/ipmr.c~ipmr-fixes 2004-07-07 23:08:48.000000000 +0900 +++ linux-2.6.7-hirofumi/net/ipv4/ipmr.c 2004-07-07 23:10:49.000000000 +0900 @@ -109,7 +109,9 @@ static int ip_mr_forward(struct sk_buff static int ipmr_cache_report(struct sk_buff *pkt, vifi_t vifi, int assert); static int ipmr_fill_mroute(struct sk_buff *skb, struct mfc_cache *c, struct rtmsg *rtm); +#ifdef CONFIG_IP_PIMSM_V2 static struct net_protocol pim_protocol; +#endif static struct timer_list ipmr_expire_timer; @@ -1702,7 +1704,7 @@ static struct file_operations ipmr_vif_f .open = ipmr_vif_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release, + .release = seq_release_private, }; struct ipmr_mfc_iter { @@ -1737,6 +1739,9 @@ static struct mfc_cache *ipmr_mfc_seq_id static void *ipmr_mfc_seq_start(struct seq_file *seq, loff_t *pos) { + struct ipmr_mfc_iter *it = seq->private; + it->cache = NULL; + it->ct = 0; return *pos ? ipmr_mfc_seq_idx(seq->private, *pos - 1) : SEQ_START_TOKEN; } @@ -1846,7 +1851,6 @@ static int ipmr_mfc_open(struct inode *i if (rc) goto out_kfree; - memset(s, 0, sizeof(*s)); seq = file->private_data; seq->private = s; out: @@ -1862,7 +1866,7 @@ static struct file_operations ipmr_mfc_f .open = ipmr_mfc_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release, + .release = seq_release_private, }; #endif _ -- OGAWA Hirofumi From hirofumi@mail.parknet.co.jp Wed Jul 7 12:26:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 12:26:19 -0700 (PDT) Received: from mail.parknet.co.jp (mail.parknet.co.jp [210.171.160.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67JQFgi003993 for ; Wed, 7 Jul 2004 12:26:16 -0700 Received: from ibmpc.myhome.or.jp [210.171.164.65] by mail.parknet.co.jp with ESMTP (SMTPD32-4.10) id AF6060F50154; Thu, 08 Jul 2004 04:26:24 +0900 Received: from devron.myhome.or.jp (root@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i67JQEpE029061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jul 2004 04:26:14 +0900 Received: from devron.myhome.or.jp (hirofumi@localhost [127.0.0.1]) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) with ESMTP id i67JQEvR003287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jul 2004 04:26:14 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.12.11/8.12.11/Debian-5) id i67JQEf7003284; Thu, 8 Jul 2004 04:26:14 +0900 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] net: cleanup miss usage of seq_release_private From: OGAWA Hirofumi Date: Thu, 08 Jul 2004 04:26:14 +0900 Message-ID: <871xjnmxex.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hirofumi@mail.parknet.co.jp Precedence: bulk X-list: netdev Content-Length: 2475 Lines: 66 These doesn't allocate memory and doesn't use seq->private. However kfree() ignores NULL, so these are not the problem. This patch just cleans these up. Signed-off-by: OGAWA Hirofumi --- net/ipv4/route.c | 2 +- net/irda/discovery.c | 2 +- net/irda/ircomm/ircomm_core.c | 2 +- net/irda/iriap.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff -puN net/ipv4/route.c~net-seq_release-cleanup net/ipv4/route.c --- linux-2.6.7/net/ipv4/route.c~net-seq_release-cleanup 2004-07-08 00:01:20.000000000 +0900 +++ linux-2.6.7-hirofumi/net/ipv4/route.c 2004-07-08 00:01:20.000000000 +0900 @@ -432,7 +432,7 @@ static struct file_operations rt_cpu_seq .open = rt_cpu_seq_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release_private, + .release = seq_release, }; #endif /* CONFIG_PROC_FS */ diff -puN net/irda/discovery.c~net-seq_release-cleanup net/irda/discovery.c --- linux-2.6.7/net/irda/discovery.c~net-seq_release-cleanup 2004-07-08 00:01:20.000000000 +0900 +++ linux-2.6.7-hirofumi/net/irda/discovery.c 2004-07-08 00:01:20.000000000 +0900 @@ -449,6 +449,6 @@ struct file_operations discovery_seq_fop .open = discovery_seq_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release_private, + .release = seq_release, }; #endif diff -puN net/irda/iriap.c~net-seq_release-cleanup net/irda/iriap.c --- linux-2.6.7/net/irda/iriap.c~net-seq_release-cleanup 2004-07-08 00:01:20.000000000 +0900 +++ linux-2.6.7-hirofumi/net/irda/iriap.c 2004-07-08 00:01:20.000000000 +0900 @@ -1093,7 +1093,7 @@ struct file_operations irias_seq_fops = .open = irias_seq_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release_private, + .release = seq_release, }; #endif /* PROC_FS */ diff -puN net/irda/ircomm/ircomm_core.c~net-seq_release-cleanup net/irda/ircomm/ircomm_core.c --- linux-2.6.7/net/irda/ircomm/ircomm_core.c~net-seq_release-cleanup 2004-07-08 00:01:20.000000000 +0900 +++ linux-2.6.7-hirofumi/net/irda/ircomm/ircomm_core.c 2004-07-08 00:01:20.000000000 +0900 @@ -62,7 +62,7 @@ static struct file_operations ircomm_pro .open = ircomm_seq_open, .read = seq_read, .llseek = seq_lseek, - .release = seq_release_private, + .release = seq_release, }; #endif /* CONFIG_PROC_FS */ _ -- OGAWA Hirofumi From jamie@shareable.org Wed Jul 7 12:31:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 12:31:38 -0700 (PDT) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67JVZgi004592 for ; Wed, 7 Jul 2004 12:31:36 -0700 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id i67JVP81019101; Wed, 7 Jul 2004 20:31:25 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id i67JVPg4019099; Wed, 7 Jul 2004 20:31:25 +0100 Date: Wed, 7 Jul 2004 20:31:25 +0100 From: Jamie Lokier To: Stephen Hemminger Cc: "David S. Miller" , bert hubert , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-ID: <20040707193125.GA17266@mail.shareable.org> References: <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706131235.10b5afa8.davem@redhat.com> <20040706224453.GA6694@outpost.ds9a.nl> <20040706154907.422a6b73.davem@redhat.com> <20040707110653.7c49bef1@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707110653.7c49bef1@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-archive-position: 6761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Content-Length: 698 Lines: 19 Stephen Hemminger wrote: > But: isn't it better to have just one sysctl parameter set > (tcp_rmem) and set the window scale as needed rather than increasing > the already bewildering array of dials and knobs? I can't see why > it would be advantageous to set a window scale of 7 if the largest > possible window ever offered is limited to a smaller value? That's a fair question. It seems to me the only effects of a larger scale than necessary are (a) the buffer size can be increased after the connection is established, and (b) coarser granularity which can only degrade performance over low mss links. So why do we set a larger window scale than necessary? Is it to support (a)? -- Jamie From jheffner@psc.edu Wed Jul 7 12:47:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 12:47:52 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67Jlpgi005208 for ; Wed, 7 Jul 2004 12:47:51 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i67JlX77009223 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jul 2004 15:47:33 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i67JlU2Q021984; Wed, 7 Jul 2004 15:47:30 -0400 (EDT) Date: Wed, 7 Jul 2004 15:47:30 -0400 (EDT) From: John Heffner To: Stephen Hemminger cc: "David S. Miller" , bert hubert , Arnaldo Carvalho de Melo , , , , , , Subject: Re: [PATCH] fix tcp_default_win_scale. In-Reply-To: <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 569 Lines: 24 On Tue, 6 Jul 2004, Stephen Hemminger wrote: > +/* Default window scaling based on the size of the maximum window */ > +static inline __u8 tcp_default_win_scale(void) > +{ > + int b = ffs(sysctl_tcp_rmem[2]); > + return (b < 17) ? 0 : b-16; > +} I would actually change this to be: static inline __u8 tcp_select_win_scale(void) { int b = ffs(tcp_win_from_space(max(sysctl_tcp_rmem[2], sysctl_rmem_max))); b = (b < 17) ? 0 : b-16; return max(b, 14); } Then you can also get rid of all the window scale calculation code in tcp_select_initial_window(). -John From ahu@outpost.ds9a.nl Wed Jul 7 13:11:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 13:11:46 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67KBCgi005987 for ; Wed, 7 Jul 2004 13:11:33 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A19A04018; Wed, 7 Jul 2004 21:38:02 +0200 (CEST) Date: Wed, 7 Jul 2004 21:38:02 +0200 From: bert hubert To: Jamie Lokier Cc: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-ID: <20040707193802.GA8117@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Jamie Lokier , Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org References: <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706131235.10b5afa8.davem@redhat.com> <20040706224453.GA6694@outpost.ds9a.nl> <20040706154907.422a6b73.davem@redhat.com> <20040707110653.7c49bef1@dell_ss3.pdx.osdl.net> <20040707193125.GA17266@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707193125.GA17266@mail.shareable.org> User-Agent: Mutt/1.3.28i X-archive-position: 6763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 585 Lines: 19 On Wed, Jul 07, 2004 at 08:31:25PM +0100, Jamie Lokier wrote: > So why do we set a larger window scale than necessary? > Is it to support (a)? It might be useful to shake out the bugs of the internet - so far I have indications that at least on residential ADSL router is responsible, it removes wscale when doing TCP portforwarding. If and when we decide to do larger rmem than now, we might have a better chance. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From jheffner@psc.edu Wed Jul 7 13:18:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 13:18:04 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67KHdgi006486 for ; Wed, 7 Jul 2004 13:18:00 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i67JfD77009086 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jul 2004 15:41:13 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i67JfD2Q021935; Wed, 7 Jul 2004 15:41:13 -0400 (EDT) Date: Wed, 7 Jul 2004 15:41:13 -0400 (EDT) From: John Heffner To: Stephen Hemminger cc: "David S. Miller" , bert hubert , , , , Subject: Re: [PATCH] fix tcp_default_win_scale. In-Reply-To: <20040707110653.7c49bef1@dell_ss3.pdx.osdl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 695 Lines: 21 On Wed, 7 Jul 2004, Stephen Hemminger wrote: > I do not argue with that the correct thing to do is to use window scaling > and find/fix the poor sop's stuck behind busted networks. > > But: isn't it better to have just one sysctl parameter set (tcp_rmem) > and set the window scale as needed rather than increasing the already > bewildering array of dials and knobs? I can't see why it would be advantageous > to set a window scale of 7 if the largest possible window ever offered > is limited to a smaller value? I personally agree with this. One can imagine cases where it would be useful to have a control on window scale, but the added complexity is probably not worth it. -John From ahu@outpost.ds9a.nl Wed Jul 7 13:33:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 13:33:10 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67KWkgi007018 for ; Wed, 7 Jul 2004 13:33:07 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id DA73F4018; Wed, 7 Jul 2004 22:32:45 +0200 (CEST) Date: Wed, 7 Jul 2004 22:32:45 +0200 From: bert hubert To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] mark CSZ scheduler as broken Message-ID: <20040707203245.GA9617@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com References: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.3.28i X-archive-position: 6765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 509 Lines: 10 On Wed, Jul 07, 2004 at 11:19:36AM -0700, Stephen Hemminger wrote: > Since the configuration help for CSZ is broken, and other documentation > says it just doesn't work. Why not mark it as broken to make it obvious? For all I care we can zonk it - even Alexey is unclear about its workings or use. More of a research project then something we should ship. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From vda@port.imtp.ilyichevsk.odessa.ua Wed Jul 7 13:51:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 13:51:09 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67Kp2gi007873 for ; Wed, 7 Jul 2004 13:51:05 -0700 Received: (qmail 22900 invoked by alias); 7 Jul 2004 20:50:57 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 07 Jul 2004 20:50:57 -0000 From: Denis Vlasenko To: Christoph Hellwig , Bernd Schubert , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.7: sk98lin unload oops Date: Wed, 7 Jul 2004 23:50:44 +0300 User-Agent: KMail/1.5.4 References: <200407041342.18821.bernd-schubert@web.de> <20040704151509.GA5100@infradead.org> <20040704152352.GA5243@infradead.org> In-Reply-To: <20040704152352.GA5243@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200407072350.44252.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 6767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 885 Lines: 21 On Sunday 04 July 2004 18:23, Christoph Hellwig wrote: > On Sun, Jul 04, 2004 at 04:15:09PM +0100, Christoph Hellwig wrote: > > > Fortunality everything still works fine (I'm running the script over > > > the network of the syskonnect cards). > > > > > > This machine has two of those syskonnect cards, on another machine > > > which has only one syskonnect card this oops doesn't occur. > > > > As a colleteral damage the following huge patch should fix it, and I need > > testers for it anyway ;-) > > Actually the problem sits deeper. sk98line tries to register a procfile > with the interfacename of the struct net_device. The patch below (ontop of > the previous one) makes it work unless you change the interface name > manually, but as Linux explicitly allows that the interface is > fundamentally broken and probably should just go away. hostap driver does this too -- vda From shemminger@osdl.org Wed Jul 7 13:59:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 13:59:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67KxLgi008296 for ; Wed, 7 Jul 2004 13:59:21 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67KwVG13315; Wed, 7 Jul 2004 13:58:31 -0700 Date: Wed, 7 Jul 2004 13:58:31 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040707135831.4c98dd51@dell_ss3.pdx.osdl.net> In-Reply-To: <1089226667.1027.411.camel@jzny.localdomain> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> <1089226667.1027.411.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1373 Lines: 38 On 07 Jul 2004 14:57:48 -0400 jamal wrote: > I seem to have hit the jackpot - all my emails to netdev are showing > up and on time too. > > On Wed, 2004-07-07 at 14:10, Stephen Hemminger wrote: > > Ok, I'll bite how would you do: > > > > Rate limit packet egress on a ethernet device (eth0) so it looks like a slow DSL link (25 Kbps) > > by not dropping packets but by pacing the data. > > Doesnt TBF work? > rate 25kbit burst 90k should probably do it. Maybe i misunderstood the > question. TBF works but since the sender (on the same local machine) may go over it's allocation, it will drop packets. For example, if I use tbf to simulate a slow 33k bits/sec link then TCP test never completes, it just hangs! TBF does work for intermediate sizes. But if I use the pacing simulation it works. > > You may be able to avoid dropping but dont think you can guarantee it > simply because you have finite buffers. At some point you will congest > that queue and packets will be dropped; and if you dont limit your queue > buffer size, sooner than later you are bound to hog all the system > memory. I understand that, every queue has to have a limit. > Having said that, i have never seen a good arguement for why pacing > traffic vs dropping to initiate a slowdown is better than the other. > So in that case, a policer/meter should suffice. From davem@redhat.com Wed Jul 7 14:10:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 14:10:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67LA1gi008857 for ; Wed, 7 Jul 2004 14:10:04 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67L9xe1024060; Wed, 7 Jul 2004 17:09:59 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67L9x020949; Wed, 7 Jul 2004 17:09:59 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i67L9TuN031561; Wed, 7 Jul 2004 17:09:29 -0400 Date: Wed, 7 Jul 2004 14:06:53 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] deinline sock_i_uid,sock_i_ino Message-Id: <20040707140653.513fbe84.davem@redhat.com> In-Reply-To: <20040707095443.7b54b63d@dell_ss3.pdx.osdl.net> References: <20040707095443.7b54b63d@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 352 Lines: 10 On Wed, 7 Jul 2004 09:54:43 -0700 Stephen Hemminger wrote: > The sock_i_uid and sock_i_ino functions are only called by /proc type > interfaces, so they don't need to be inlined. > > Also, the inline functions writeable, rcvtimeo, sndtimeo are test for > value functions that don't change their argument. Looks good, applied. From hadi@cyberus.ca Wed Jul 7 14:11:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 14:11:54 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67LBogi009205 for ; Wed, 7 Jul 2004 14:11:51 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:53898 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Wed, 7 Jul 2004 22:11:49 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BiJhj-0000zB-7R for netdev@linux-mips.org; Wed, 07 Jul 2004 17:11:47 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BiJhg-00035V-2D; Wed, 07 Jul 2004 17:11:44 -0400 Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl In-Reply-To: <20040707135831.4c98dd51@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> <1089226667.1027.411.camel@jzny.localdomain> <20040707135831.4c98dd51@dell_ss3.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089234699.1026.448.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Jul 2004 17:11:39 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 512 Lines: 19 On Wed, 2004-07-07 at 16:58, Stephen Hemminger wrote: > TBF works but since the sender (on the same local machine) may go over > it's allocation, it will drop packets. As should any queue that gets congested. > For example, if I use tbf to simulate a slow 33k bits/sec link then > TCP test never > completes, it just hangs! TBF does work for intermediate sizes. > > But if I use the pacing simulation it works. I am not sure i follow; is this because of the return code from the enqueue? cheers, jamal From davem@redhat.com Wed Jul 7 14:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 14:12:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67LCsgi009541 for ; Wed, 7 Jul 2004 14:12:54 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67LCqe1024925; Wed, 7 Jul 2004 17:12:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67LCq022037; Wed, 7 Jul 2004 17:12:52 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i67LCLBF000418; Wed, 7 Jul 2004 17:12:22 -0400 Date: Wed, 7 Jul 2004 14:09:45 -0700 From: "David S. Miller" To: OGAWA Hirofumi Cc: netdev@oss.sgi.com Subject: Re: [PATCH] net/ipv4/ipmr.c fixes Message-Id: <20040707140945.07c88057.davem@redhat.com> In-Reply-To: <877jtfmxg9.fsf@devron.myhome.or.jp> References: <877jtfmxg9.fsf@devron.myhome.or.jp> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 531 Lines: 14 On Thu, 08 Jul 2004 04:25:26 +0900 OGAWA Hirofumi wrote: > - pim_protocol warning fix > > - ipmr_vif_open() and ipmr_mfc_open() allocates the memory, so it > should use seq_release_private(). > > - ipmr_mfc_seq_xxx is using it->cache, in order to control whether > unlock should be do or not, but it->cache was not initialized in > ipmr_mfc_seq_start(). So it can point the previous state if user > did seek(). This become to the cause of twice unlock. Looks good, patch applied. Thanks! From davem@redhat.com Wed Jul 7 14:14:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 14:14:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67LE4gi009848 for ; Wed, 7 Jul 2004 14:14:04 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67LE2e1025114; Wed, 7 Jul 2004 17:14:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67LE2022193; Wed, 7 Jul 2004 17:14:02 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i67LDWWk000895; Wed, 7 Jul 2004 17:13:32 -0400 Date: Wed, 7 Jul 2004 14:10:56 -0700 From: "David S. Miller" To: OGAWA Hirofumi Cc: netdev@oss.sgi.com Subject: Re: [PATCH] net: cleanup miss usage of seq_release_private Message-Id: <20040707141056.110e7db8.davem@redhat.com> In-Reply-To: <871xjnmxex.fsf@devron.myhome.or.jp> References: <871xjnmxex.fsf@devron.myhome.or.jp> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 274 Lines: 9 On Thu, 08 Jul 2004 04:26:14 +0900 OGAWA Hirofumi wrote: > These doesn't allocate memory and doesn't use seq->private. However > kfree() ignores NULL, so these are not the problem. > > This patch just cleans these up. Patch applied, thanks. From shemminger@osdl.org Wed Jul 7 14:23:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 14:23:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67LN6gi010294 for ; Wed, 7 Jul 2004 14:23:06 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67LMGG18772; Wed, 7 Jul 2004 14:22:16 -0700 Date: Wed, 7 Jul 2004 14:22:16 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler Message-Id: <20040707142216.7c9763c3@dell_ss3.pdx.osdl.net> In-Reply-To: <1089234699.1026.448.camel@jzny.localdomain> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> <1089226667.1027.411.camel@jzny.localdomain> <20040707135831.4c98dd51@dell_ss3.pdx.osdl.net> <1089234699.1026.448.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 706 Lines: 22 On 07 Jul 2004 17:11:39 -0400 jamal wrote: > On Wed, 2004-07-07 at 16:58, Stephen Hemminger wrote: > > > TBF works but since the sender (on the same local machine) may go over > > it's allocation, it will drop packets. > > As should any queue that gets congested. > > For example, if I use tbf to simulate a slow 33k bits/sec link then > > TCP test never > > completes, it just hangs! TBF does work for intermediate sizes. > > > > But if I use the pacing simulation it works. > > I am not sure i follow; is this because of the return code from the > enqueue? Actually, the problem only occurs if burst is set large (like 2mb). I think it gets stuck waiting for that much data. From alessandro.suardi@oracle.com Wed Jul 7 14:23:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 14:23:33 -0700 (PDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67LNVgi010338 for ; Wed, 7 Jul 2004 14:23:31 -0700 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i67LIrGo008026; Wed, 7 Jul 2004 14:18:54 -0700 (PDT) Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i67LMZ5t022057; Wed, 7 Jul 2004 15:22:35 -0600 Received: from oracle.com (dhcp-emea-vpn-gw2-uk-141-144-128-80.vpn.oracle.com [141.144.128.80]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i67LMWrp021965; Wed, 7 Jul 2004 15:22:33 -0600 Message-ID: <40EC6A52.70207@oracle.com> Date: Wed, 07 Jul 2004 23:25:38 +0200 From: Alessandro Suardi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bert hubert CC: "David S. Miller" , acme@conectiva.com.br, shemminger@osdl.org, netdev@oss.sgi.com, phyprabab@yahoo.com Subject: Re: analysis of TCP window size issues still around - several reports / SACK involved? References: <32886.63.170.215.71.1088564087.squirrel@www.osdl.org> <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706131955.3a3c6c8b.davem@redhat.com> <20040706202708.GA1385@outpost.ds9a.nl> In-Reply-To: <20040706202708.GA1385@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alessandro.suardi@oracle.com Precedence: bulk X-list: netdev Content-Length: 1075 Lines: 33 bert hubert wrote: > On Tue, Jul 06, 2004 at 01:19:55PM -0700, David S. Miller wrote: > > >>rather it do this, so that diagnosing dumps are easier. If tcpdump >>tries to be too clever, scaling the window, then I might end up >>chasing down a tcpdump bug rather than a TCP one :-) > > > True - it might want to print '43 (*128=5706)' or something like that. > > >>What would be more interesting is to get the tcpdump trace from the >>other side of this connection. This is crucial, as it will show how >>and in what way exactly the window scale options and/or window fields >>are being edited by a firewall or other device and thus causing >>the problems. > > > I have an appointment with Alessandro tomorrow evening at 11PM CEST to do > just that. Sorry about being slightly late - I read the thread from my VPN link (which does work), now I'm turning it off and will email Bert with my actual IP address and my connection. Thanks, --alessandro "Practice is more important than theory. A _lot_ more important." (Linus Torvalds on lkml, 1 June 2004) From herbert@gondor.apana.org.au Wed Jul 7 14:28:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 14:28:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67LSGgi010962 for ; Wed, 7 Jul 2004 14:28:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiJxZ-0001d5-00; Thu, 08 Jul 2004 07:28:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiJxV-0007mc-00; Thu, 08 Jul 2004 07:28:05 +1000 Date: Thu, 8 Jul 2004 07:28:05 +1000 To: James Morris Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040707212805.GA29899@gondor.apana.org.au> References: <20040707130652.GA26822@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 850 Lines: 21 On Wed, Jul 07, 2004 at 10:58:21AM -0400, James Morris wrote: > > > All of the dst->output functions already assumed that they have > > exclusive access to the skb. This is justified because all callers to > > dst_output() makes sure that the packet is neither shared nor cloned. > > Cloned skbs are regularly passed to dst_output(), thus we need to use the > double pointer for skb_checksum_help() in case the skb is replaced. OK. Can you please tell me which caller of dst_output() passes a cloned skb to it? I need to know this because if this is the case, we need fix the various IPsec output functions to copy the skb. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@redhat.com Wed Jul 7 15:04:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 15:04:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67M4mgi011881 for ; Wed, 7 Jul 2004 15:04:48 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67M4de1004076; Wed, 7 Jul 2004 18:04:39 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67M4d004931; Wed, 7 Jul 2004 18:04:39 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i67M49Pa025384; Wed, 7 Jul 2004 18:04:10 -0400 Date: Wed, 7 Jul 2004 15:01:32 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-Id: <20040707150132.5dc470b6.davem@redhat.com> In-Reply-To: <20040707212805.GA29899@gondor.apana.org.au> References: <20040707130652.GA26822@gondor.apana.org.au> <20040707212805.GA29899@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 631 Lines: 17 On Thu, 8 Jul 2004 07:28:05 +1000 Herbert Xu wrote: > OK. Can you please tell me which caller of dst_output() passes > a cloned skb to it? > > I need to know this because if this is the case, we need fix the various > IPsec output functions to copy the skb. They do already, via skb_cow(). The case James's patch tries to deal with is when multicast loops back packets to localhost, see ip_mc_output(). Since the SKB is a clone, if we do anything with the checksum state of the clone, this messes up the hw checksumming state of the original SKB and we get output packets with corrupt checksums. From jheffner@psc.edu Wed Jul 7 15:15:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 15:15:12 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67MFAgi012553 for ; Wed, 7 Jul 2004 15:15:10 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i67LjD0T009085 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jul 2004 17:45:13 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i67LjD2Q022753; Wed, 7 Jul 2004 17:45:13 -0400 (EDT) Date: Wed, 7 Jul 2004 17:45:13 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: , Subject: [PATCH] window announcement with scaling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1721 Lines: 49 See comments in patch below. -John ===== net/ipv4/tcp_output.c 1.40 vs edited ===== --- 1.40/net/ipv4/tcp_output.c Tue Jun 22 02:52:20 2004 +++ edited/net/ipv4/tcp_output.c Wed Jul 7 17:39:42 2004 @@ -682,17 +682,30 @@ if (free_space > tp->rcv_ssthresh) free_space = tp->rcv_ssthresh; - /* Get the largest window that is a nice multiple of mss. - * Window clamp already applied above. - * If our current window offering is within 1 mss of the - * free space we just keep it. This prevents the divide - * and multiply from happening most of the time. - * We also don't do any window rounding when the free space - * is too small. + /* Don't do rounding if we are using window scaling, since the + * scaled window will not line up with the MSS boundary anyway. */ window = tp->rcv_wnd; - if (window <= free_space - mss || window > free_space) - window = (free_space/mss)*mss; + if (tp->rcv_wscale) { + window = free_space; + + /* Advertise enough space so that it won't get scaled away. + * Import case: prevent zero window announcement if + * 1< mss. */ + if (((window >> tp->rcv_wscale) << tp->rcv_wscale) != window) + window = ((window >> tp->rcv_wscale) + 1) << tp->rcv_wscale; + } else { + /* Get the largest window that is a nice multiple of mss. + * Window clamp already applied above. + * If our current window offering is within 1 mss of the + * free space we just keep it. This prevents the divide + * and multiply from happening most of the time. + * We also don't do any window rounding when the free space + * is too small. + */ + if (window <= free_space - mss || window > free_space) + window = (free_space/mss)*mss; + } return window; } From davem@redhat.com Wed Jul 7 15:30:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 15:30:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67MU5gi013175 for ; Wed, 7 Jul 2004 15:30:06 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67MU4e1009582; Wed, 7 Jul 2004 18:30:04 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67MU4011753; Wed, 7 Jul 2004 18:30:04 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i67MTYKm004161; Wed, 7 Jul 2004 18:29:35 -0400 Date: Wed, 7 Jul 2004 15:26:57 -0700 From: "David S. Miller" To: John Heffner Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] window announcement with scaling Message-Id: <20040707152657.67b47e3c.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 198 Lines: 9 On Wed, 7 Jul 2004 17:45:13 -0400 (EDT) John Heffner wrote: > See comments in patch below. I like this a lot. With some minor formatting changes I applied your patch. Thanks. From davem@redhat.com Wed Jul 7 15:30:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 15:30:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67MUbgi013296 for ; Wed, 7 Jul 2004 15:30:38 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67MUTe1009698; Wed, 7 Jul 2004 18:30:29 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67MUT011932; Wed, 7 Jul 2004 18:30:29 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i67MTxL0004367; Wed, 7 Jul 2004 18:29:59 -0400 Date: Wed, 7 Jul 2004 15:27:22 -0700 From: "David S. Miller" To: bert hubert Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] mark CSZ scheduler as broken Message-Id: <20040707152722.5660a6f0.davem@redhat.com> In-Reply-To: <20040707203245.GA9617@outpost.ds9a.nl> References: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> <20040707203245.GA9617@outpost.ds9a.nl> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 474 Lines: 11 On Wed, 7 Jul 2004 22:32:45 +0200 bert hubert wrote: > On Wed, Jul 07, 2004 at 11:19:36AM -0700, Stephen Hemminger wrote: > > Since the configuration help for CSZ is broken, and other documentation > > says it just doesn't work. Why not mark it as broken to make it obvious? > > For all I care we can zonk it - even Alexey is unclear about its workings or > use. More of a research project then something we should ship. Let's do it in 2.7.x, not in 2.6.x From davem@redhat.com Wed Jul 7 15:31:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 15:31:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67MVEgi013512 for ; Wed, 7 Jul 2004 15:31:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67MVAe1009922; Wed, 7 Jul 2004 18:31:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67MVA012129; Wed, 7 Jul 2004 18:31:10 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i67MUe6n004847; Wed, 7 Jul 2004 18:30:41 -0400 Date: Wed, 7 Jul 2004 15:28:03 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] mark CSZ scheduler as broken Message-Id: <20040707152803.6e2a7336.davem@redhat.com> In-Reply-To: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> References: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 320 Lines: 8 On Wed, 7 Jul 2004 11:19:36 -0700 Stephen Hemminger wrote: > Since the configuration help for CSZ is broken, and other documentation > says it just doesn't work. Why not mark it as broken to make it obvious? I think marking it as experimental is more appropriate and accurate. Don't you think? From herbert@gondor.apana.org.au Wed Jul 7 16:12:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 16:12:38 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67NCVgi014810 for ; Wed, 7 Jul 2004 16:12:32 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiLaS-0002Bb-00; Thu, 08 Jul 2004 09:12:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiLaP-0007xb-00; Thu, 08 Jul 2004 09:12:21 +1000 Date: Thu, 8 Jul 2004 09:12:21 +1000 To: "David S. Miller" Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040707231221.GA30565@gondor.apana.org.au> References: <20040707130652.GA26822@gondor.apana.org.au> <20040707212805.GA29899@gondor.apana.org.au> <20040707150132.5dc470b6.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707150132.5dc470b6.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 952 Lines: 25 On Wed, Jul 07, 2004 at 03:01:32PM -0700, David S. Miller wrote: > On Thu, 8 Jul 2004 07:28:05 +1000 > Herbert Xu wrote: > > > OK. Can you please tell me which caller of dst_output() passes > > a cloned skb to it? > > The case James's patch tries to deal with is when multicast > loops back packets to localhost, see ip_mc_output(). > Since the SKB is a clone, if we do anything with the checksum > state of the clone, this messes up the hw checksumming state > of the original SKB and we get output packets with corrupt > checksums. Thanks. I have no problems with that. But ip_mc_output() as far as I can see does not call dst_output. So is there a caller to dst_output that does this as well? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jmorris@redhat.com Wed Jul 7 16:33:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 16:33:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67NXRgi018494 for ; Wed, 7 Jul 2004 16:33:30 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i67NXJe1022850; Wed, 7 Jul 2004 19:33:19 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i67NXJ027974; Wed, 7 Jul 2004 19:33:19 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i67NXI4G011153; Wed, 7 Jul 2004 19:33:18 -0400 Date: Wed, 7 Jul 2004 19:33:18 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , Subject: Re: pskb change in dst->output In-Reply-To: <20040707231221.GA30565@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 313 Lines: 16 On Thu, 8 Jul 2004, Herbert Xu wrote: > Thanks. I have no problems with that. But ip_mc_output() as far > as I can see does not call dst_output. > > So is there a caller to dst_output that does this as well? The TCP code often clones skbs to be transmitted. - James -- James Morris From shemminger@osdl.org Wed Jul 7 16:56:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 16:56:41 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i67Nuegi019279 for ; Wed, 7 Jul 2004 16:56:40 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i67NuSG14219; Wed, 7 Jul 2004 16:56:28 -0700 Date: Wed, 7 Jul 2004 16:56:28 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] mark CSZ scheduler as broken Message-Id: <20040707165628.02246aaf@dell_ss3.pdx.osdl.net> In-Reply-To: <20040707152803.6e2a7336.davem@redhat.com> References: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> <20040707152803.6e2a7336.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 637 Lines: 15 On Wed, 7 Jul 2004 15:28:03 -0700 "David S. Miller" wrote: > On Wed, 7 Jul 2004 11:19:36 -0700 > Stephen Hemminger wrote: > > > Since the configuration help for CSZ is broken, and other documentation > > says it just doesn't work. Why not mark it as broken to make it obvious? > > I think marking it as experimental is more appropriate and > accurate. Don't you think? It builds fine and obeys all the conventions, so it isn't really BROKEN like other drivers. But do we really want to keep it in the tree at all? The code to set it up isn't in the any version of 'tc' I saw (only stubs). From herbert@gondor.apana.org.au Wed Jul 7 17:04:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 17:04:39 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6804Wgi019813 for ; Wed, 7 Jul 2004 17:04:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiMOn-0002Qe-00; Thu, 08 Jul 2004 10:04:25 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiMOj-00084G-00; Thu, 08 Jul 2004 10:04:21 +1000 Date: Thu, 8 Jul 2004 10:04:21 +1000 To: James Morris Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040708000421.GA30918@gondor.apana.org.au> References: <20040707231221.GA30565@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 926 Lines: 26 On Wed, Jul 07, 2004 at 07:33:18PM -0400, James Morris wrote: > > > So is there a caller to dst_output that does this as well? > > The TCP code often clones skbs to be transmitted. Thanks for the pointer. I've looked at it and that appears to be safe. The logic appears to be that the first packet passed to dst_output() via ip_queue_xmit() is a clone of the packet on the TCP output queue. The output functions are allowed to modify all parts of the skb except the TCP payload. Subsequent retransmits will unclone the packet before adding the TCP header and passing it to ip_queue_xmit(). So the bottom line is that we don't have to unclone the packet before touching the checksum in dst_output(). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ahu@outpost.ds9a.nl Wed Jul 7 17:04:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 17:04:49 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6804Wgi019814 for ; Wed, 7 Jul 2004 17:04:35 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 326674449; Thu, 8 Jul 2004 01:27:57 +0200 (CEST) Date: Thu, 8 Jul 2004 01:27:57 +0200 From: bert hubert To: "David S. Miller" , Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM Subject: preliminary conclusions regarding window size issues Message-ID: <20040707232757.GA14471@outpost.ds9a.nl> Mail-Followup-To: bert hubert , "David S. Miller" , Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 6785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 4049 Lines: 97 Two things: 1) packages.gentoo.org is currently unreachable by 2.6.7-recent. This has been confirmed from several places, very easy to reproduce. Bug has been filed with gentoo to fix their firewall. 2) What Alessandro Suardi sees is highly similar, except that he has it with *all* remotes, except for google.it and a very small number of other servers. This is what Alessandro saw going out. We artificially lowered the MTU because of possible tunelling loss: 01:03:36.323132 192.168.1.3.33992 > 213.244.168.210.10000: S [tcp sum ok] 3497585848:3497585848(0) win 5440 (DF) (ttl 64, id 43908, len 60) 01:03:36.396660 213.244.168.210.10000 > 192.168.1.3.33992: S [tcp sum ok] 3030562636:3030562636(0) ack 3497585849 win 5792 (DF) (ttl 53, id 0, len 60) 01:03:36.396719 192.168.1.3.33992 > 213.244.168.210.10000: . [tcp sum ok] ack 1 win 42 (DF) (ttl 64, id 43909, len 52) Perfect SYN, SYN|ACK, ACK. 01:03:36.397362 192.168.1.3.33992 > 213.244.168.210.10000: P 1:463(462) ack 1 win 42 (DF) (ttl 64, id 43910, len 514) The GET request. 01:03:36.497588 213.244.168.210.10000 > 192.168.1.3.33992: . [tcp sum ok] ack 463 win 6432 (DF) (ttl 53, id 59171, len 52) And acked by my server. This trace is identical to what I see on the receiving end: 29.84 62.211.168.xx.33992 > 213.244.168.210.10000: S [tcp sum ok] 3497585848:3497585848(0) win 5440 (DF) (ttl 50, id 43908, len 60) 29.84 213.244.168.210.10000 > 62.211.168.xx.33992: S [tcp sum ok] 3030562636:3030562636(0) ack 3497585849 win 5792 (DF) (ttl 64, id 0, len 60) 29.93 62.211.168.xx.33992 > 213.244.168.210.10000: . [tcp sum ok] 1:1(0) ack 1 win 42 (DF) (ttl 50, id 43909, len 52) 29.95 62.211.168.xx.33992 > 213.244.168.210.10000: P [tcp sum ok] 1:463(462) ack 1 win 42 (DF) (ttl 50, id 43910, len 514) 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1(0) ack 463 win 6432 (DF) (ttl 64, id 59171, len 52) Except for TTL and NAT, this is identical. From here, things start to differ. I measure that I send out: 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1349(1348) ack 463 win 6432 (DF) (ttl 64, id 59172, len 1400) 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: P [tcp sum ok] 1349:2697(1348) ack 463 win 6432 (DF) (ttl 64, id 59173, len 1400) This next packet is a repeat, because no ACK: 30.23 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1349(1348) ack 463 win 6432 (DF) (ttl 64, id 59174, len 1400) ad nauseam. Alessandro never sees these packets! After a while, he disconnects, which happens pretty normally. From another trace (NOTE!): 00:38:21.326397 192.168.1.3.33285 > 213.244.168.210.10000: F 420:420(0) ack 1 win 45 (DF) 00:38:21.410353 213.244.168.210.10000 > 192.168.1.3.33285: . ack 421 win 6432 (DF) We've tried with wscale=0,1,2 and these all work. Things go wrong for wscale>=3. My current feeling is that some kind of QoS device is interfering, and that the 'wscale gets stuffed' theory is wrong in this case. I recall that 'Packeteer' QoS devices try to mess with windows. Alessandro has this DSL modem, which crashed once during testing. http://www.usr.com/support/product-template.asp?prod=9003 So we're not done debugging. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From davem@redhat.com Wed Jul 7 17:21:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 17:21:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i680LGgi020793 for ; Wed, 7 Jul 2004 17:21:16 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i680L8e1002018; Wed, 7 Jul 2004 20:21:08 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i680L7008292; Wed, 7 Jul 2004 20:21:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i680KbQH014296; Wed, 7 Jul 2004 20:20:38 -0400 Date: Wed, 7 Jul 2004 17:17:59 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-Id: <20040707171759.025eb13b.davem@redhat.com> In-Reply-To: <20040708000421.GA30918@gondor.apana.org.au> References: <20040707231221.GA30565@gondor.apana.org.au> <20040708000421.GA30918@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1648 Lines: 47 On Thu, 8 Jul 2004 10:04:21 +1000 Herbert Xu wrote: > On Wed, Jul 07, 2004 at 07:33:18PM -0400, James Morris wrote: > > > > > So is there a caller to dst_output that does this as well? > > > > The TCP code often clones skbs to be transmitted. > > Thanks for the pointer. This isn't the case that prompted James's changes though. It's a UDP packet, to multicast, with hw checksumming enabled, that gets looped back via ip_mc_output() here: if (rt->rt_flags&RTCF_MULTICAST) { if ((!sk || inet_sk(sk)->mc_loop) #ifdef CONFIG_IP_MROUTE /* Small optimization: do not loopback not local frames, which returned after forwarding; they will be dropped by ip_mr_input in any case. Note, that local frames are looped back to be delivered to local recipients. This check is duplicated in ip_mr_input at the moment. */ && ((rt->rt_flags&RTCF_LOCAL) || !(IPCB(skb)->flags&IPSKB_FORWARDED)) #endif ) { struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC); if (newskb) NF_HOOK(PF_INET, NF_IP_POST_ROUTING, newskb, NULL, newskb->dev, ip_dev_loopback_xmit); } If this goes through netfilter, before James's changes, in any way shape or form, the checksum of the original SKB will be corrupted. This breaks dhcp for example, and it's really common because if you just build selinux even without using any rules, packets go through netfilter. That is what James's changes, to move the actual packet mucking deeper in the netfilter call chain (to where packet modifications really happen) so that we can fix the above described case without unneeded expense added. From herbert@gondor.apana.org.au Wed Jul 7 17:36:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 17:36:13 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i680a4gi021619 for ; Wed, 7 Jul 2004 17:36:05 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiMtJ-0002XR-00; Thu, 08 Jul 2004 10:35:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiMtG-00088K-00; Thu, 08 Jul 2004 10:35:54 +1000 Date: Thu, 8 Jul 2004 10:35:54 +1000 To: "David S. Miller" Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040708003554.GA31201@gondor.apana.org.au> References: <20040707231221.GA30565@gondor.apana.org.au> <20040708000421.GA30918@gondor.apana.org.au> <20040707171759.025eb13b.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707171759.025eb13b.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1808 Lines: 40 On Wed, Jul 07, 2004 at 05:17:59PM -0700, David S. Miller wrote: > > If this goes through netfilter, before James's changes, in any way > shape or form, the checksum of the original SKB will be corrupted. > This breaks dhcp for example, and it's really common because if you > just build selinux even without using any rules, packets go through > netfilter. Thanks, I've got no problems with the netfilter part of the change at all. What I am trying to find out is what has this got to do with dst_output(). Let's take ah_output() as an example. At the top of the function we've got a conditional call to skb_checksum_help() which will unclone the skb. This ostensibly allows us to call ah_output() with a cloned skb. However, if we look further down in ah_output() we will find code that modifies the contents of skb->data without uncloning it. So if someone calls ah_output() with a cloned packet that does not require skb_checksum_help() this will blow up. The TCP case is safe as the skb it provides is practically uncloned as long as you don't touch the TCP payload. This works currently as all callers to dst_output() provide it with an skb that is practically uncloned in the sense that you can modify all the headers at will. But if that is the case, I don't see why dst_output() needs to take a pskb instead of a plain skb. Of course the current call to skb_checksum_help() will unclone packets such as those generated by TCP, but I think that we ought to have a version of it that doesn't unclone the packet and call that in dst->output() functions like ah_output(). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jmorris@redhat.com Wed Jul 7 18:05:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 18:05:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6815Kgi022761 for ; Wed, 7 Jul 2004 18:05:21 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6815Ce1011420; Wed, 7 Jul 2004 21:05:12 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6815C017645; Wed, 7 Jul 2004 21:05:12 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6815B4G016125; Wed, 7 Jul 2004 21:05:11 -0400 Date: Wed, 7 Jul 2004 21:05:11 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: "David S. Miller" cc: Herbert Xu , Subject: Re: pskb change in dst->output In-Reply-To: <20040707171759.025eb13b.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 425 Lines: 17 On Wed, 7 Jul 2004, David S. Miller wrote: > That is what James's changes, to move the actual packet mucking deeper > in the netfilter call chain (to where packet modifications really happen) > so that we can fix the above described case without unneeded expense > added. Btw, this should also lead to a performance increase for Netfilter, although I haven't measured it. - James -- James Morris From herbert@gondor.apana.org.au Wed Jul 7 18:11:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 18:11:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i681B9gi023258 for ; Wed, 7 Jul 2004 18:11:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiNRH-0002eD-00; Thu, 08 Jul 2004 11:11:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiNRE-0008E6-00; Thu, 08 Jul 2004 11:11:00 +1000 Date: Thu, 8 Jul 2004 11:11:00 +1000 To: James Morris Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040708011100.GA31600@gondor.apana.org.au> References: <20040707171759.025eb13b.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 521 Lines: 15 On Wed, Jul 07, 2004 at 09:05:11PM -0400, James Morris wrote: > > Btw, this should also lead to a performance increase for Netfilter, > although I haven't measured it. I'm totally happy with the netfilter part of the change. I'm just a bit unsure whether the pskb change is needed in dst_output(). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jmorris@redhat.com Wed Jul 7 18:19:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 18:19:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i681JKgi023957 for ; Wed, 7 Jul 2004 18:19:21 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i681JCe1014785; Wed, 7 Jul 2004 21:19:12 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i681JC020589; Wed, 7 Jul 2004 21:19:12 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i681JB4G016853; Wed, 7 Jul 2004 21:19:11 -0400 Date: Wed, 7 Jul 2004 21:19:11 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , Subject: Re: pskb change in dst->output In-Reply-To: <20040708011100.GA31600@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 215 Lines: 13 On Thu, 8 Jul 2004, Herbert Xu wrote: > I'm just a bit unsure whether the pskb change is needed in dst_output(). I'm looking into it now, it may not be after all. - James -- James Morris From jamie@shareable.org Wed Jul 7 18:45:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 18:45:30 -0700 (PDT) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i681jRgi025214 for ; Wed, 7 Jul 2004 18:45:28 -0700 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id i681ih81020868; Thu, 8 Jul 2004 02:44:43 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id i681ihO2020866; Thu, 8 Jul 2004 02:44:43 +0100 Date: Thu, 8 Jul 2004 02:44:43 +0100 From: Jamie Lokier To: bert hubert , "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM Subject: Re: preliminary conclusions regarding window size issues Message-ID: <20040708014443.GE17266@mail.shareable.org> References: <20040707232757.GA14471@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707232757.GA14471@outpost.ds9a.nl> User-Agent: Mutt/1.4.1i X-archive-position: 6791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Content-Length: 722 Lines: 19 bert hubert wrote: > Alessandro never sees these packets! ... > My current feeling is that some kind of QoS device is interfering, > and that the 'wscale gets stuffed' theory is wrong in this case. > > I recall that 'Packeteer' QoS devices try to mess with windows. It's a bit fiddly to arrange, but can you repeat the test and artificially lower the TTL for these packets which disappear? An iptable mangle rule would do the trick -- mangle the TTL only on packets which match this point in the trace. The idea is to reduce the TTL like traceroute does, so you can see which hop is causing these packets to disappear -- perhaps it'll stand out proudly as a QoS device which can be named, blamed and shamed. -- Jamie From jmorris@redhat.com Wed Jul 7 20:35:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 20:35:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i683ZAgi007645 for ; Wed, 7 Jul 2004 20:35:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i683Z3e1014584; Wed, 7 Jul 2004 23:35:03 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i683Z2014918; Wed, 7 Jul 2004 23:35:02 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i683Yx4G023332; Wed, 7 Jul 2004 23:35:00 -0400 Date: Wed, 7 Jul 2004 23:34:59 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , Subject: Re: pskb change in dst->output In-Reply-To: <20040708011100.GA31600@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 859 Lines: 30 On Thu, 8 Jul 2004, Herbert Xu wrote: > I'm just a bit unsure whether the pskb change is needed in dst_output(). Ok, dst_output() iterates over the skb->dst stack: for (;;) { err = skb->dst->output(&skb); if (likely(err == 0)) return err; if (unlikely(err != NET_XMIT_BYPASS)) return err; } We need to pass a pointer to skb to skb->dst->output() because the skb can be changed by skb_checksum_help() in one of these output paths. Further iteration would otherwise pass an incorrect (freed) skb. The change to dst->output() which implements a double skb pointer is then propagated throughout the code, e.g. ah_output() has to change because it becomes an output function via xfrm->type->output(). - James -- James Morris From herbert@gondor.apana.org.au Wed Jul 7 21:02:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 21:02:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6842jgi008458 for ; Wed, 7 Jul 2004 21:02:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiQ7L-0003KB-00; Thu, 08 Jul 2004 14:02:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiQ7H-0008Vb-00; Thu, 08 Jul 2004 14:02:35 +1000 Date: Thu, 8 Jul 2004 14:02:35 +1000 To: James Morris Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040708040235.GA32678@gondor.apana.org.au> References: <20040708011100.GA31600@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 845 Lines: 20 On Wed, Jul 07, 2004 at 11:34:59PM -0400, James Morris wrote: > > We need to pass a pointer to skb to skb->dst->output() because the skb can > be changed by skb_checksum_help() in one of these output paths. Further > iteration would otherwise pass an incorrect (freed) skb. That's only because the dst->output() functions are calling skb_checksum_help(). Since those same functions assume the skb to be "uncloned" anyway (they modify it directly by adding headers etc.), they only need to call a version of skb_checksum_help() that does not do a copy of the skb. This is what dst->output() did before this change anyway. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ahu@outpost.ds9a.nl Wed Jul 7 23:03:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 23:03:32 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6863Rgi012522 for ; Wed, 7 Jul 2004 23:03:28 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9068E4453; Thu, 8 Jul 2004 08:03:26 +0200 (CEST) Date: Thu, 8 Jul 2004 08:03:26 +0200 From: bert hubert To: Jamie Lokier Cc: "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM Subject: Re: preliminary conclusions regarding window size issues Message-ID: <20040708060326.GA22258@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Jamie Lokier , "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM References: <20040707232757.GA14471@outpost.ds9a.nl> <20040708014443.GE17266@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040708014443.GE17266@mail.shareable.org> User-Agent: Mutt/1.3.28i X-archive-position: 6795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 2371 Lines: 60 On Thu, Jul 08, 2004 at 02:44:43AM +0100, Jamie Lokier wrote: > An iptable mangle rule would do the trick -- mangle the TTL only on > packets which match this point in the trace. Indeed fiddly - not only does the packet have to disappear, we need an ICMP to confirm that. This is because the packet currently disappears anyhow. Another thought that ocurred to me is that this might be a window tracking firewall that says, based on the scaled window size which it misinterprets because it does not understand window scaling: "I'm not going to let this packet pass, I've seen that the intended recipient announced a 43 byte window size". The idea such a silly firewall would have is that it 'protects' a host from traffic it can't handle. This jives with the observed fact that things work up to and including wscale=2, but breaks with wscale=3. With wscale=3, the scaled window size is 730. With wscale=2, the observed window of 1460 is big enough to let a packet pass. We could verify this assumption by checking if lowering the MTU to say 700 allows wscale=3 to work. Looking at the traceroute to Alessandro, my current suspect is this machine: (The 1655 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 81/tcp filtered hosts2-ns 135/tcp filtered msrpc 445/tcp filtered microsoft-ds 514/tcp open shell No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi). TCP/IP fingerprint: SInfo(V=3.50%P=i686-pc-linux-gnu%D=7/8%Time=40ECDF49%O=514%C=1) TSeq(Class=TR%IPID=Z%TS=U) T1(Resp=Y%DF=Y%W=1020%ACK=S++%Flags=AS%Ops=ME) T2(Resp=N) T3(Resp=Y%DF=Y%W=1020%ACK=S++%Flags=AS%Ops=ME) T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) PU(Resp=N) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: 9D217EAD 78BBFA4A 6C815E49 191A3C0A 2A07597F 8B869DAA IPID Sequence Generation: All zeros Nmap run completed -- 1 IP address (1 host up) scanned in 25.593 seconds TCP port 514 is rsh, but when I try rsh on that port it doesn't work. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@outpost.ds9a.nl Wed Jul 7 23:37:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jul 2004 23:37:05 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i686b1gi013539 for ; Wed, 7 Jul 2004 23:37:02 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D5FFC4018; Thu, 8 Jul 2004 08:37:00 +0200 (CEST) Date: Thu, 8 Jul 2004 08:37:00 +0200 From: bert hubert To: Jamie Lokier , "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM Subject: window tracking firewall involved, was: Re: preliminary conclusions regarding window size issues Message-ID: <20040708063700.GA23496@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Jamie Lokier , "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM References: <20040707232757.GA14471@outpost.ds9a.nl> <20040708014443.GE17266@mail.shareable.org> <20040708060326.GA22258@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040708060326.GA22258@outpost.ds9a.nl> User-Agent: Mutt/1.3.28i X-archive-position: 6796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 2286 Lines: 59 On Thu, Jul 08, 2004 at 08:03:26AM +0200, bert hubert wrote: [ theory that a window tracking firewall drops packets for which it thinks the intended recipient has no room, as they are larger than the window size it sees, where it neglects to scale that window size ] > We could verify this assumption by checking if lowering the MTU to say 700 > allows wscale=3 to work. This has now been confirmed with the packages.gentoo.org firewall! Setting MTU does not help because the kernel adjusts the window size too. However, fiddling with MSS helps. Setting wscale to 3 breaks connectivity to packages.gentoo.org, but one can restore it with: # iptables -t mangle -A OUTPUT -p tcp -o wlan0 -d 198.63.211.232 -j TCPMSS \ --set-mss=742 --tcp-flags SYN,RST SYN 742 is the limit value, note how this is pretty close to the scaled window size of 730. Trace of succesful connection: 08:29:54.799158 192.168.1.4.33116 > 198.63.211.232.80: S 258776237:258776237(0) win 5840 (DF) 08:29:54.935830 198.63.211.232.80 > 192.168.1.4.33116: S 3729725382:3729725382(0) ack 258776238 win 5792 (DF) 08:29:54.935997 192.168.1.4.33116 > 198.63.211.232.80: . ack 1 win 730 (DF) 08:29:54.936116 192.168.1.4.33116 > 198.63.211.232.80: P 1:107(106) ack 1 win 730 (DF) 08:29:55.058090 198.63.211.232.80 > 192.168.1.4.33116: . ack 107 win 5792 (DF) 08:29:55.058325 198.63.211.232.80 > 192.168.1.4.33116: . 1:731(730) ack 107 win 5792 (DF) 08:29:55.058425 192.168.1.4.33116 > 198.63.211.232.80: . ack 731 win 912 (DF) 08:29:55.181172 198.63.211.232.80 > 192.168.1.4.33116: . 731:1461(730) ack 107 win 5792 (DF) Packages.gentoo.org is behind a Running: Cisco IOS 12.X OS details: Cisco 7200 router running IOS 12.1(14)E6 OS Fingerprint: Not sure if that would be the culprit though. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From mtk-lists@gmx.net Thu Jul 8 01:34:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 01:35:22 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i688YHgi020690 for ; Thu, 8 Jul 2004 01:34:17 -0700 Received: (qmail 11741 invoked by uid 0); 8 Jul 2004 08:34:11 -0000 Received: from 62.245.207.82 by www62.gmx.net with HTTP; Thu, 8 Jul 2004 10:34:11 +0200 (MEST) Date: Thu, 8 Jul 2004 10:34:11 +0200 (MEST) From: "Michael T Kerrisk" To: Chris Friesen Cc: netdev@oss.sgi.com MIME-Version: 1.0 References: <40EBFDAE.8070903@nortelnetworks.com> Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() X-Priority: 3 (Normal) X-Authenticated: #18454895 Message-ID: <1525.1089275651@www62.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 6798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lists@gmx.net Precedence: bulk X-list: netdev Content-Length: 512 Lines: 21 > I have a SOCK_STREAM PF_UNIX socket with no special options enabled using > fcntl(). > > The default with sendmsg() and recvmsg() is to block. > > With sndmsg(), I can use the MSG_DONTWAIT flag to enable non-blocking > operation for that one call. > > How do I do the equivalent for recvmsg()? MSG_DONTWAIT should also work with recvmsg(). Cheers -- Michael Kerrisk mtk-lists@gmx.net "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info From hadi@cyberus.ca Thu Jul 8 06:36:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 06:36:31 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68DaQgi017483 for ; Thu, 8 Jul 2004 06:36:27 -0700 Received: from mx01.cybersurf.com ([IPv6:::ffff:209.197.145.104]:44453 "EHLO mx01.cybersurf.com") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 14:36:25 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BiZ4W-0006bP-PM for netdev@linux-mips.org; Thu, 08 Jul 2004 09:36:20 -0400 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 1BiZ4S-0005IK-Or; Thu, 08 Jul 2004 09:36:17 -0400 Subject: Re: [PATCH 2.6] update to network emulation QOS scheduler From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , Catalin BOIE , netdev@oss.sgi.com In-Reply-To: <20040707142216.7c9763c3@dell_ss3.pdx.osdl.net> References: <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> <1089226667.1027.411.camel@jzny.localdomain> <20040707135831.4c98dd51@dell_ss3.pdx.osdl.net> <1089234699.1026.448.camel@jzny.localdomain> <20040707142216.7c9763c3@dell_ss3.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089293774.1349.118.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jul 2004 09:36:14 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 566 Lines: 18 I have taken out lartc from the CC; it keeps bouncing emails back to me. On Wed, 2004-07-07 at 17:22, Stephen Hemminger wrote: > Actually, the problem only occurs if burst is set large (like 2mb). > I think it gets stuck waiting for that much data. Sounds like a bug. If you have the exact setup description i can chase it. What about CBQ, HTB, H-FSC? The other way to do it is actually put a router next to a localy generated traffic. I have used this many times in the past (a sample is at: ftp://ftp.isi.edu/in-notes/rfc2884.txt section 4.1) cheers, jamal From pp@ee.oulu.fi Thu Jul 8 06:38:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 06:39:00 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68Dcugi017774 for ; Thu, 8 Jul 2004 06:38:57 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.11/8.12.11) with ESMTP id i68Dcr9L028192; Thu, 8 Jul 2004 16:38:53 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.11/8.12.11/Submit) id i68Dcrcn020639; Thu, 8 Jul 2004 16:38:53 +0300 (EEST) Date: Thu, 8 Jul 2004 16:38:53 +0300 From: Pekka Pietikainen To: James Hubbard Cc: netdev@oss.sgi.com Subject: Re: Broadcom 4400 driver bm44 Message-ID: <20040708133853.GA20254@ee.oulu.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-archive-position: 6804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev Content-Length: 1158 Lines: 21 On Wed, Jul 07, 2004 at 02:21:49PM -0400, James Hubbard wrote: > I have two apps (AppA and AppB) that communicate via multicast. The > initial discovery process allows the apps to find each other. The > apps send hearbeats periodically to advertise that they are on the > network. After a period of time, AppB can't see AppA. I would say > that AppB stops seeing AppA after the initial discovery. I say this > If I use this command: > ifconfig eth0 allmulti > AppB receives all of the multicast data and can receive data from > AppA. This in turn causes a problem where standard communication via > TCP does not function. Pings, ssh, etc do not work. If I disable > allmulti. All other communication works except for multicast. Hiya I'll try to reproduce the problem. It's entirely possible that there's something wrong in the multicast filter code. What would be helpful is some sort of quick testcase that shows this problem. I tried a minimal multicast test program (mcast.py from the python distribution) and that worked ok. ifconfig eth1 allmulti did cause the connection to my home box to hang, so that I can reproduce at least ;) ;) ;) From davem@redhat.com Thu Jul 8 08:37:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 08:37:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68Fbigi031832 for ; Thu, 8 Jul 2004 08:37:45 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i68FbLe1008565; Thu, 8 Jul 2004 11:37:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i68FbL026937; Thu, 8 Jul 2004 11:37:21 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i68FaodJ030203; Thu, 8 Jul 2004 11:36:51 -0400 Date: Thu, 8 Jul 2004 08:37:08 -0700 From: "David S. Miller" To: bert hubert Cc: jamie@shareable.org, shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM Subject: Re: window tracking firewall involved, was: Re: preliminary conclusions regarding window size issues Message-Id: <20040708083708.5f63bc71.davem@redhat.com> In-Reply-To: <20040708063700.GA23496@outpost.ds9a.nl> References: <20040707232757.GA14471@outpost.ds9a.nl> <20040708014443.GE17266@mail.shareable.org> <20040708060326.GA22258@outpost.ds9a.nl> <20040708063700.GA23496@outpost.ds9a.nl> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1079 Lines: 27 On Thu, 8 Jul 2004 08:37:00 +0200 bert hubert wrote: > On Thu, Jul 08, 2004 at 08:03:26AM +0200, bert hubert wrote: > > [ theory that a window tracking firewall drops packets for which it thinks > the intended recipient has no room, as they are larger than the window size > it sees, where it neglects to scale that window size ] > > > We could verify this assumption by checking if lowering the MTU to say 700 > > allows wscale=3 to work. > > This has now been confirmed with the packages.gentoo.org firewall! It's the netfilter patches added to the gentoo WOLK kernel running on packages.gentoo.org Specifically, it's the tcp-window-tracking patch from netfilter's patch-o-matic. There's some bug in there wrt. it's window scaling support. I bet if the tcp-window-scaling diff is removed from the kernel running there, the problem will totally go away. I note that it is using a very old version of the tcp-window-tracking patch, the current version is 2.2 and probably fixes this bug. The gentoo linux-2.4.20-wolk-4.14 kernel is using version 1.7 From cfriesen@nortelnetworks.com Thu Jul 8 09:21:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 09:21:51 -0700 (PDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68GLlgi001155 for ; Thu, 8 Jul 2004 09:21:48 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i68GLaH17666; Thu, 8 Jul 2004 12:21:36 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTAXS9; Thu, 8 Jul 2004 12:21:37 -0400 Message-ID: <40ED748F.8000700@nortelnetworks.com> Date: Thu, 08 Jul 2004 12:21:35 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael T Kerrisk CC: netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() References: <1525.1089275651@www62.gmx.net> In-Reply-To: <1525.1089275651@www62.gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 189 Lines: 8 Michael T Kerrisk wrote: > MSG_DONTWAIT should also work with recvmsg(). Hmm... Just tried it with a DGRAM socket, and it seems to work. Any ideas why its not in the man pages? Chris From ak@suse.de Thu Jul 8 09:28:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 09:29:00 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68GSugi001637 for ; Thu, 8 Jul 2004 09:28:57 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id E644687B6AC; Thu, 8 Jul 2004 18:27:03 +0200 (CEST) Date: Thu, 8 Jul 2004 18:27:03 +0200 From: Andi Kleen To: Chris Friesen Cc: Michael T Kerrisk , netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() Message-ID: <20040708162703.GA12934@wotan.suse.de> References: <1525.1089275651@www62.gmx.net> <40ED748F.8000700@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40ED748F.8000700@nortelnetworks.com> X-archive-position: 6809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 318 Lines: 11 On Thu, Jul 08, 2004 at 12:21:35PM -0400, Chris Friesen wrote: > Michael T Kerrisk wrote: > > >MSG_DONTWAIT should also work with recvmsg(). > > Hmm... Just tried it with a DGRAM socket, and it seems to work. Any ideas > why its not in the man pages? Nobody ever added it? Just send a patch to aeb@cwi.nl -Andi From gandalf@wlug.westbo.se Thu Jul 8 09:35:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 09:35:06 -0700 (PDT) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68GZ4gi002442 for ; Thu, 8 Jul 2004 09:35:05 -0700 Received: by null.rsn.bth.se (Postfix, from userid 65534) id E4C422C0089; Thu, 8 Jul 2004 18:34:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id 60DB62C007A; Thu, 8 Jul 2004 18:34:58 +0200 (CEST) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id 95BB82C0084; Thu, 8 Jul 2004 18:34:57 +0200 (CEST) Received: by tux.rsn.bth.se (Postfix, from userid 501) id 49EE23EBD; Thu, 8 Jul 2004 18:34:58 +0200 (CEST) Subject: Re: window tracking firewall involved, was: Re: preliminary conclusions regarding window size issues From: Martin Josefsson To: "David S. Miller" Cc: bert hubert , jamie@shareable.org, shemminger@osdl.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, ALESSANDRO.SUARDI@ORACLE.COM In-Reply-To: <20040708083708.5f63bc71.davem@redhat.com> References: <20040707232757.GA14471@outpost.ds9a.nl> <20040708014443.GE17266@mail.shareable.org> <20040708060326.GA22258@outpost.ds9a.nl> <20040708063700.GA23496@outpost.ds9a.nl> <20040708083708.5f63bc71.davem@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8d09E3ns7FktNIp5ICAo" Message-Id: <1089304497.2588.12.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 08 Jul 2004 18:34:57 +0200 X-Virus-Scanned: by amavisd-new-20030616-p9 on null.rsn.bth.se X-archive-position: 6811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Content-Length: 1574 Lines: 48 --=-8d09E3ns7FktNIp5ICAo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-08 at 17:37, David S. Miller wrote: > > This has now been confirmed with the packages.gentoo.org firewall! >=20 > It's the netfilter patches added to the gentoo WOLK kernel running > on packages.gentoo.org >=20 > Specifically, it's the tcp-window-tracking patch from netfilter's > patch-o-matic. There's some bug in there wrt. it's window scaling > support. >=20 > I bet if the tcp-window-scaling diff is removed from the kernel running > there, the problem will totally go away. >=20 > I note that it is using a very old version of the tcp-window-tracking > patch, the current version is 2.2 and probably fixes this bug. The > gentoo linux-2.4.20-wolk-4.14 kernel is using version 1.7 That bug was probably fixed May 21 2003 according to cvs history. "Patch updated: window scaling bug fixed, improved, etc. (JK)." It updates the version to 1.9 As reference, I'm using v2.2 with -bk from 040626 which does use wscale=3D7 and I don't see any problems connecting to/from machines with lower or equal wscale. I drop and log all packets tcp-window-tracking classifies as INVALID. --=20 /Martin --=-8d09E3ns7FktNIp5ICAo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA7XexWm2vlfa207ERAhsZAKC7uBD+jwCHfMcQH4HXu4gTpMqghACfat5M BKR138LZyBmozfPJc2s/eq4= =xXsk -----END PGP SIGNATURE----- --=-8d09E3ns7FktNIp5ICAo-- From cfriesen@nortelnetworks.com Thu Jul 8 09:49:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 09:49:55 -0700 (PDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68Gnpgi002951 for ; Thu, 8 Jul 2004 09:49:52 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i68GnSH18131; Thu, 8 Jul 2004 12:49:28 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTAXYF; Thu, 8 Jul 2004 12:49:28 -0400 Message-ID: <40ED7B18.800@nortelnetworks.com> Date: Thu, 08 Jul 2004 12:49:28 -0400 X-Sybari-Trust: 5c4ff06e d27f880e eb185f71 00000104 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aeb@cwi.nl CC: Andi Kleen , Michael T Kerrisk , netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() References: <20040708162703.GA12934@wotan.suse.de> In-Reply-To: <20040708162703.GA12934@wotan.suse.de> Content-Type: multipart/mixed; boundary="------------040902000407060804000806" X-archive-position: 6812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 2882 Lines: 66 This is a multi-part message in MIME format. --------------040902000407060804000806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andi Kleen wrote: > On Thu, Jul 08, 2004 at 12:21:35PM -0400, Chris Friesen wrote: > > Michael T Kerrisk wrote: > > > > >MSG_DONTWAIT should also work with recvmsg(). > > > > Hmm... Just tried it with a DGRAM socket, and it seems to work. Any > ideas > > why its not in the man pages? > > Nobody ever added it? Just send a patch to aeb@cwi.nl Sending patch as suggested. Fundamentally, the delta is as follows, I've included an attachment with what I hope are the proper formatting codes (copied from send(2)). --- recv.man 2004-07-08 15:43:17.000000000 -0400 +++ recv2.man 2004-07-08 15:47:29.000000000 -0400 @@ -67,6 +67,11 @@ disconnect occurs, or the next data to be received is of a dif- ferent type than that returned. + MSG_DONTWAIT + Enables non-blocking operation; if the operation would block, + EAGAIN is returned (this can also be enabled using the O_NON- + BLOCK with the F_SETFL fcntl(2)). + MSG_NOSIGNAL This flag turns off raising of SIGPIPE on stream sockets when the other end disappears. Note also that there is a mention of MSG_DONTWAIT in the msg_flags field in the msghdr. It gives the impression that one can *set* that field to cause the non-blocking behaviour. My understanding is that the msg_flags field is a return value only. Perhaps that portion should be reworded as well. Chris --------------040902000407060804000806 Content-Type: application/octet-stream; name="man2recv.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="man2recv.diff" LS0tIHJlY3YubWFuCTIwMDQtMDctMDggMTU6NDM6MTcuMDAwMDAwMDAwIC0wNDAwCisrKyBy ZWN2Mi5tYW4JMjAwNC0wNy0wOCAxNTo0NzoyOS4wMDAwMDAwMDAgLTA0MDAKQEAgLTY3LDYg KzY3LDExIEBACiAgICAgICAgICAgICAgIGRpc2Nvbm5lY3Qgb2NjdXJzLCBvciB0aGUgbmV4 dCBkYXRhIHRvIGJlIHJlY2VpdmVkIGlzIG9mIGEgIGRpZi0KICAgICAgICAgICAgICAgZmVy ZW50IHR5cGUgdGhhbiB0aGF0IHJldHVybmVkLgogCisgICAgICAgTQhNUwhTRwhHXwhfRAhE TwhPTghOVAhUVwhXQQhBSQhJVAhUCisgICAgICAgICAgICAgIEVuYWJsZXMgIG5vbi1ibG9j a2luZyAgb3BlcmF0aW9uOyAgaWYgdGhlIG9wZXJhdGlvbiB3b3VsZCBibG9jaywKKyAgICAg ICAgICAgICAgRQhFQQhBRwhHQQhBSQhJTghOIGlzIHJldHVybmVkICh0aGlzIGNhbiBhbHNv IGJlIGVuYWJsZWQgIHVzaW5nICB0aGUgIE8IT18IX04ITk8IT04ITi0ILQorICAgICAgICAg ICAgICBCCEJMCExPCE9DCENLCEsgd2l0aCB0aGUgRghGXwhfUwhTRQhFVAhURghGTAhMIGYI ZmMIY24IbnQIdGwIbCgyKSkuCisKICAgICAgICBNCE1TCFNHCEdfCF9OCE5PCE9TCFNJCElH CEdOCE5BCEFMCEwKICAgICAgICAgICAgICAgVGhpcyAgZmxhZyAgdHVybnMgIG9mZiByYWlz aW5nIG9mIFMIU0kISUcIR1AIUEkISVAIUEUIRSBvbiBzdHJlYW0gc29ja2V0cyB3aGVuCiAg ICAgICAgICAgICAgIHRoZSBvdGhlciBlbmQgZGlzYXBwZWFycy4K --------------040902000407060804000806-- From aeb@cwi.nl Thu Jul 8 10:07:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 10:07:58 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68H7Zgi003558 for ; Thu, 8 Jul 2004 10:07:56 -0700 Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id i68H75kV010550 for ; Thu, 8 Jul 2004 19:07:05 +0200 (MEST) Received: by apps.cwi.nl id i68H75p12984; Thu, 8 Jul 2004 19:07:05 +0200 (MEST) Date: Thu, 8 Jul 2004 19:07:05 +0200 From: Andries Brouwer To: Chris Friesen Cc: Andries.Brouwer@cwi.nl, Andi Kleen , Michael T Kerrisk , netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() Message-ID: <20040708170705.GA6895@apps.cwi.nl> References: <20040708162703.GA12934@wotan.suse.de> <40ED7B18.800@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40ED7B18.800@nortelnetworks.com> User-Agent: Mutt/1.4i X-archive-position: 6813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Andries.Brouwer@cwi.nl Precedence: bulk X-list: netdev Content-Length: 1686 Lines: 46 On Thu, Jul 08, 2004 at 12:49:28PM -0400, Chris Friesen wrote: > > > why its not in the man pages? > > > >Nobody ever added it? Just send a patch to aeb@cwi.nl > > Sending patch as suggested. Fundamentally, the delta is as follows, I've > included an attachment with what I hope are the proper formatting codes > (copied from send(2)). > > --- recv.man 2004-07-08 15:43:17.000000000 -0400 > +++ recv2.man 2004-07-08 15:47:29.000000000 -0400 > @@ -67,6 +67,11 @@ > disconnect occurs, or the next data to be received is of a > dif- > ferent type than that returned. > > + MSG_DONTWAIT > + Enables non-blocking operation; if the operation would > block, > + EAGAIN is returned (this can also be enabled using the > O_NON- > + BLOCK with the F_SETFL fcntl(2)). > + > MSG_NOSIGNAL > This flag turns off raising of SIGPIPE on stream sockets > when > the other end disappears. > > > Note also that there is a mention of MSG_DONTWAIT in the msg_flags field in > the msghdr. It gives the impression that one can *set* that field to cause > the non-blocking behaviour. My understanding is that the msg_flags field > is a return value only. Perhaps that portion should be reworded as well. > > Chris Can you find the man-pages-1.67 package and construct a concrete patch? (Don't know precisely what you want to do. The above gives a filename recv.man, which would be recv.2 in my sources. But there is no MSG_NOSIGNAL in recv.2, only in send.2. The fragment of text that you give occurs already in recv.2.) Andries From niv@us.ibm.com Thu Jul 8 10:24:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 10:24:31 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68HO7gi004179 for ; Thu, 8 Jul 2004 10:24:29 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i68HNjtf509990; Thu, 8 Jul 2004 13:23:45 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i68HNXmZ145024; Thu, 8 Jul 2004 11:23:34 -0600 Message-ID: <40ED8399.2040907@us.ibm.com> Date: Thu, 08 Jul 2004 10:25:45 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Friesen CC: Michael T Kerrisk , netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() References: <1525.1089275651@www62.gmx.net> <40ED748F.8000700@nortelnetworks.com> In-Reply-To: <40ED748F.8000700@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 321 Lines: 18 Chris Friesen wrote: > Michael T Kerrisk wrote: > >> MSG_DONTWAIT should also work with recvmsg(). > > > Hmm... Just tried it with a DGRAM socket, and it seems to work. Any > ideas why its not in the man pages? Think you are on an older version of the man pages. It's been there for a while. thanks, Nivedita From shemminger@osdl.org Thu Jul 8 10:41:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 10:42:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68Hfugi004721 for ; Thu, 8 Jul 2004 10:41:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i68HfhG09051; Thu, 8 Jul 2004 10:41:44 -0700 Date: Thu, 8 Jul 2004 10:41:43 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6] bridge -- support different MTU sizes Message-Id: <20040708104143.67210e39@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3231 Lines: 113 This patch adds support for different size MTU's to bridging. It is useful for bridging Ethernet's with jumbo frames, etc. The mtu of the bridge pseudo-device is maintained as the minimum of all the underlying ports. And when forwarding a frame through the bridge, it will drop the frame if the outgoing port's MTU is less than the frame size (as per 802 standard). Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c 2004-06-30 11:48:01 -07:00 +++ b/net/bridge/br_device.c 2004-06-30 11:48:01 -07:00 @@ -89,6 +89,15 @@ return 0; } +static int br_change_mtu(struct net_device *dev, int new_mtu) +{ + if ((new_mtu < 68) || new_mtu > br_min_mtu(dev->priv)) + return -EINVAL; + + dev->mtu = new_mtu; + return 0; +} + static int br_dev_accept_fastpath(struct net_device *dev, struct dst_entry *dst) { return -1; @@ -105,6 +114,7 @@ dev->hard_start_xmit = br_dev_xmit; dev->open = br_dev_open; dev->set_multicast_list = br_dev_set_multicast_list; + dev->change_mtu = br_change_mtu; dev->destructor = free_netdev; SET_MODULE_OWNER(dev); dev->stop = br_dev_stop; diff -Nru a/net/bridge/br_forward.c b/net/bridge/br_forward.c --- a/net/bridge/br_forward.c 2004-06-30 11:48:01 -07:00 +++ b/net/bridge/br_forward.c 2004-06-30 11:48:01 -07:00 @@ -22,7 +22,8 @@ static inline int should_deliver(const struct net_bridge_port *p, const struct sk_buff *skb) { - if (skb->dev == p->dev || + if (skb->dev == p->dev || + skb->len > p->dev->mtu || p->state != BR_STATE_FORWARDING) return 0; diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c 2004-06-30 11:48:01 -07:00 +++ b/net/bridge/br_if.c 2004-06-30 11:48:01 -07:00 @@ -295,6 +295,24 @@ return ret; } +int br_min_mtu(const struct net_bridge *br) +{ + const struct net_bridge_port *p; + int mtu = 0; + + ASSERT_RTNL(); + + if (list_empty(&br->port_list)) + mtu = 1500; + else { + list_for_each_entry(p, &br->port_list, list) { + if (!mtu || p->dev->mtu < mtu) + mtu = p->dev->mtu; + } + } + return mtu; +} + /* called with RTNL */ int br_add_if(struct net_bridge *br, struct net_device *dev) { @@ -328,6 +346,8 @@ if ((br->dev->flags & IFF_UP) && (dev->flags & IFF_UP)) br_stp_enable_port(p); spin_unlock_bh(&br->lock); + + br->dev->mtu = br_min_mtu(br); } return err; diff -Nru a/net/bridge/br_notify.c b/net/bridge/br_notify.c --- a/net/bridge/br_notify.c 2004-06-30 11:48:01 -07:00 +++ b/net/bridge/br_notify.c 2004-06-30 11:48:01 -07:00 @@ -47,6 +47,10 @@ spin_unlock_bh(&br->lock); break; + case NETDEV_CHANGEMTU: + br->dev->mtu = br_min_mtu(br); + break; + case NETDEV_DOWN: if (br->dev->flags & IFF_UP) { spin_lock_bh(&br->lock); diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h 2004-06-30 11:48:01 -07:00 +++ b/net/bridge/br_private.h 2004-06-30 11:48:01 -07:00 @@ -168,6 +168,7 @@ struct net_device *dev); extern int br_del_if(struct net_bridge *br, struct net_device *dev); +extern int br_min_mtu(const struct net_bridge *br); /* br_input.c */ extern int br_handle_frame_finish(struct sk_buff *skb); From cfriesen@nortelnetworks.com Thu Jul 8 11:33:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 11:34:02 -0700 (PDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68IXggi006469 for ; Thu, 8 Jul 2004 11:33:46 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i68IXKH21017; Thu, 8 Jul 2004 14:33:20 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTAYVZ; Thu, 8 Jul 2004 14:33:20 -0400 Message-ID: <40ED936F.9000905@nortelnetworks.com> Date: Thu, 08 Jul 2004 14:33:19 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andries Brouwer CC: Andi Kleen , Michael T Kerrisk , netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() References: <20040708170705.GA6895@apps.cwi.nl> In-Reply-To: <20040708170705.GA6895@apps.cwi.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 1349 Lines: 32 Andries Brouwer wrote: > Can you find the man-pages-1.67 package and construct a concrete patch? > > (Don't know precisely what you want to do. The above gives a filename > recv.man, which would be recv.2 in my sources. But there is no MSG_NOSIGNAL > in recv.2, only in send.2. The fragment of text that you give occurs > already in recv.2.) Sorry, the filenames have no meaning since I wasn't working from the package, but from the output of the "man" command. Working from the webpage at: http://homepages.cwi.nl/~aeb/linux/man2html/man2/recv.2.html There is mention of MSG_DONTWAIT when discussing the "msg_flags" field in "struct msghdr". It contains exactly the text proposed. However, the msg_flags field is set on *return* of the call. Every other flag discussed there "indicates" something. The blurb for MSG_DONTWAIT says that it "enables" a behaviour, which doesn't make sense for a field set on call return. There is no mention of MSG_DONTWAIT when discussing the "flags" parameter of the recv/recvfrom/recvmsg call. Generally, I want to move the current blob from the "msg_flags" area to the "flags" area, and then add a different discussion for "msg_flags" if appropriate (I'm not sure about that part). Do you still want me to generate an actual patch against man-pages-1.67, or is that description enough? Chris From cfriesen@nortelnetworks.com Thu Jul 8 11:37:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 11:37:57 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68Ibrgi006905 for ; Thu, 8 Jul 2004 11:37:55 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i68IYbg27468; Thu, 8 Jul 2004 14:34:37 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTAYWG; Thu, 8 Jul 2004 14:34:37 -0400 Message-ID: <40ED93BC.1060901@nortelnetworks.com> Date: Thu, 08 Jul 2004 14:34:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi CC: Michael T Kerrisk , netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() References: <40ED8399.2040907@us.ibm.com> In-Reply-To: <40ED8399.2040907@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 530 Lines: 19 Nivedita Singhvi wrote: > Chris Friesen wrote: > > Michael T Kerrisk wrote: > > > >> MSG_DONTWAIT should also work with recvmsg(). > > > > > > Hmm... Just tried it with a DGRAM socket, and it seems to work. Any > > ideas why its not in the man pages? > > Think you are on an older version of the man pages. > It's been there for a while. It's mentioned in the "msg_flags" section, which is set on call *return*. It's not mentioned in the "flags" section. Perhaps its just in the wrong part of the man page... Chris From kumar.gala@freescale.com Thu Jul 8 11:53:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 11:53:31 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68IrTgi007545 for ; Thu, 8 Jul 2004 11:53:29 -0700 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i68InFl3027839; Thu, 8 Jul 2004 11:49:15 -0700 (MST) Received: from [10.82.17.247] ([10.82.17.247]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i68IkHsq005875; Thu, 8 Jul 2004 13:46:17 -0500 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, hadi@cyberus.ca From: Kumar Gala Subject: ethernet QoS support? Date: Thu, 8 Jul 2004 13:53:33 -0500 To: Jeff Garzik X-Mailer: Apple Mail (2.618) X-archive-position: 6818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumar.gala@freescale.com Precedence: bulk X-list: netdev Content-Length: 185 Lines: 10 Jeff, I was wondering if there was any support for handling ethernet devices that support multiple RX/TX queues to provide QoS. If so any pointers would be great. thanks - kumar From jgarzik@pobox.com Thu Jul 8 12:02:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 12:02:14 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68J22gi009103 for ; Thu, 8 Jul 2004 12:02:03 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bie9g-0007tD-Md; Thu, 08 Jul 2004 20:02:01 +0100 Message-ID: <40ED9A1C.4040707@pobox.com> Date: Thu, 08 Jul 2004 15:01:48 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kumar Gala CC: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: ethernet QoS support? References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> In-Reply-To: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 287 Lines: 14 Kumar Gala wrote: > Jeff, > > I was wondering if there was any support for handling ethernet devices > that support multiple RX/TX queues to provide QoS. If so any pointers > would be great. IIRC skb->priority provides priority bands for TX. Not sure about RX... jamal? Jeff From aeb@cwi.nl Thu Jul 8 12:06:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 12:06:14 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68J69gi010210 for ; Thu, 8 Jul 2004 12:06:09 -0700 Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id i68J5VkV027144 for ; Thu, 8 Jul 2004 21:05:31 +0200 (MEST) Received: by apps.cwi.nl id i68J5V424412; Thu, 8 Jul 2004 21:05:31 +0200 (MEST) Date: Thu, 8 Jul 2004 21:05:31 +0200 From: Andries Brouwer To: Chris Friesen Cc: Andries Brouwer , Andi Kleen , Michael T Kerrisk , netdev@oss.sgi.com Subject: Re: asymmetry with MSG_DONTWAIT in sendmsg() and recvmsg() Message-ID: <20040708190530.GA18139@apps.cwi.nl> References: <20040708170705.GA6895@apps.cwi.nl> <40ED936F.9000905@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40ED936F.9000905@nortelnetworks.com> User-Agent: Mutt/1.4i X-archive-position: 6820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Andries.Brouwer@cwi.nl Precedence: bulk X-list: netdev Content-Length: 854 Lines: 25 On Thu, Jul 08, 2004 at 02:33:19PM -0400, Chris Friesen wrote: > Andries Brouwer wrote: > >Can you find the man-pages-1.67 package and construct a concrete patch? > > > >(Don't know precisely what you want to do. The above gives a filename > >recv.man, which would be recv.2 in my sources. But there is no MSG_NOSIGNAL > >in recv.2, only in send.2. The fragment of text that you give occurs > >already in recv.2.) > > Working from the webpage at: > > http://homepages.cwi.nl/~aeb/linux/man2html/man2/recv.2.html Ah, that is how I am punished for neglecting to update these html pages :-) Will update them. I was confused by your MSG_NOSIGNAL, but indeed, that is still on that page, it was removed later. Have moved the MSG_DONTWAIT part to after the MSG_WAITALL description. [Will still check whether that is really appropriate.] Thanks! Andries From vkondra@mail.ru Thu Jul 8 12:15:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 12:15:23 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68JF6gi011873 for ; Thu, 8 Jul 2004 12:15:07 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 05989F8134 for ; Thu, 8 Jul 2004 22:45:14 +0400 (MSD) Received: from [82.80.132.207] (port=54083 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1Bidrn-000Fz2-00; Thu, 08 Jul 2004 22:43:50 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [PATCH Linux-2.6.7-bk19] prism54 freq to channel incorrect for 5GHz Date: Thu, 8 Jul 2004 21:43:04 +0300 User-Agent: KMail/1.6.2 Cc: margitsw@t-online.de (Margit Schubert-While), jgarzik@pobox.com, prism54-devel@prism54.org References: <200407070831.47896.margitsw@t-online.de> In-Reply-To: <200407070831.47896.margitsw@t-online.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200407082143.14882.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i68JF6gi011873 X-archive-position: 6821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2550 Lines: 73 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 07 July 2004 09:31, Margit Schubert-While wrote: [code skipped] > Note that AFAIK, the 5GHz WLAN channels start at 34 (5.17 GHz) > (but I am not sure) and I don't know the top limit (except that > it is <= 6GHz). Maybe somebody can shed light on this. > If there is a clear definition, that should be reflected int the code. > And something similar for channel_to_freq. > Apparently Japan is doing something in the 10GHz band - > will have to look for details. It is not 10 GHz band. They use the same 5 GHz band, exactly same frequencies, but channel is twice narrower - 10Mhz instead of 20Mhz as usual 802.11. In 10Mhz channels, they use 1/2 data rates as well. I.e. (6,9,12,18,24,36,48,54) rates replaced by (3,4.5,6,9,12,18,24,27) For frequencies, there are several documents. I'll try to summarize: 2.4Ghz band (as in code): in 802.11b standard, 14 channels defined: freq=channel*5 + 2407, channel=1..13 freq=2484, channel=14 Those "unofficial" frequencies are not defined. BTW, do anyone know document desctibing them? 5Ghz band (as in code): freq=channel*5 + 5000, channel=0..200 (from standard) For valid channels, 802.11a standard says there are 3 bands (all in US): 1: 36,40,44,48 2: 52,56,60,64 3: 149,153,157,161 TGh (regulation in Europe) adds channels 100..140 with interval 4 Tgj (japan) spec adds new rules: 10Mhz channels I mentioned above, and channel formula: freq=channel*5+dot11ChannelStartingFrequency; where dot11ChannelStartingFrequency may be 4000 or 5000 (as for .11a) For channels 183 and above, it is 4000, for others - 5000 Valid channels for Japan (note some channels may have both 10 and 20 Mhz width, some - only one of them): 20Mhz channels: 184,188,192,196;8,12,16,34,38,42,46 10Mhz channels: 183,184,185,187,188,189;7,8,11 For TGn (high throughput) standard expected to finalize around 2006, wide 40Mhz channels expected, with maybe some additional attributes. After describing this whole mess, some points to pay attention: - - channel number is not enough to determine frequency - there are same numbers in 2.4 and 5Ghz bands. - - to properly init hardware, channel witdh should be provided as well. Thus, we probable need to use (channel,band,width) triples or (channel,domain) tuples, where (band,width) mapped into domain. Vladimir -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7ZXAqxdj7mhC6o0RAje5AJ4rDQLYmUj4QuqZgVRz71eeoq99SgCcCAWm GQSHPKvBkPgLjbO7mONUyNI= =hyvM -----END PGP SIGNATURE----- From hadi@cyberus.ca Thu Jul 8 13:00:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 13:01:01 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68K0vgi017409 for ; Thu, 8 Jul 2004 13:00:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Bif4f-0002rw-OG for netdev@oss.sgi.com; Thu, 08 Jul 2004 16:00:53 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bif4c-0007iO-4b; Thu, 08 Jul 2004 16:00:50 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Kumar Gala , netdev@oss.sgi.com In-Reply-To: <40ED9A1C.4040707@pobox.com> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <40ED9A1C.4040707@pobox.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089316845.1072.1.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jul 2004 16:00:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 459 Lines: 17 On Thu, 2004-07-08 at 15:01, Jeff Garzik wrote: > Kumar Gala wrote: > > Jeff, > > > > I was wondering if there was any support for handling ethernet devices > > that support multiple RX/TX queues to provide QoS. If so any pointers > > would be great. > > IIRC skb->priority provides priority bands for TX. Not sure about RX... > jamal? The question was very ambigous. What is it that Kumar is looking for? Is it 802.1p, IP level etc? cheers, jamal From pp@ee.oulu.fi Thu Jul 8 13:43:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 13:43:52 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68Khngi018566 for ; Thu, 8 Jul 2004 13:43:50 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.11/8.12.11) with ESMTP id i68Khk3B005673; Thu, 8 Jul 2004 23:43:46 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.11/8.12.11/Submit) id i68Khk9O028900; Thu, 8 Jul 2004 23:43:46 +0300 (EEST) Date: Thu, 8 Jul 2004 23:43:46 +0300 From: Pekka Pietikainen To: James Hubbard Cc: netdev@oss.sgi.com Subject: Re: Broadcom 4400 driver bm44 Message-ID: <20040708204346.GA28693@ee.oulu.fi> References: <20040708133853.GA20254@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-archive-position: 6824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev Content-Length: 902 Lines: 20 On Thu, Jul 08, 2004 at 10:00:26AM -0400, James Hubbard wrote: > If I can make some time I'll look into writing a test case here also. > I just don't know when it will be though. I've got the source for the > net comms layer for the apps. Perhaps I can pull out some code that > may demonstrate the error. > > Thanks for the help. Ok, after some digging around ALLMULTI breaking is not a bug, the vendor-provided driver seems to break in similar ways, at least on 2.6, so that's a feature unless they fix it in theirs so I can copy the fix :-) I put a lots'o'debugging + some bit-flipping reordering to look more like bcm4400 version at http://www.ee.oulu.fi/~pp/b44-test.tgz. Probably won't fix the problem, but it's worth a shot I suppose. Should compile with make -C /lib/modules//build modules SUBDIRS=$PWD As a workaround I suppose ifconfig eth1 promisc might do the trick too. From shemminger@osdl.org Thu Jul 8 13:53:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 13:53:39 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68KrWgi019011 for ; Thu, 8 Jul 2004 13:53:33 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i68KrKG10730; Thu, 8 Jul 2004 13:53:20 -0700 Date: Thu, 8 Jul 2004 13:53:20 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [RFC] netem - add jitter support. Message-Id: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 25866 Lines: 894 This patch adds jitter if desired to the delayed packets in the netem scheduler. I dropped the rate stuff out and reorganized so that an underlying pfifo queue is used (next plan is to make it have class ops). The jitter is given as sigma to a Gaussian normal distribution. The actual implementation is a reduced form of the table driven stuff in NISTnet (free). Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h --- a/include/linux/pkt_sched.h 2004-07-08 13:45:06 -07:00 +++ b/include/linux/pkt_sched.h 2004-07-08 13:45:06 -07:00 @@ -447,6 +447,6 @@ __u32 loss; /* random packet loss (0=none ~0=100%) */ __u32 gap; /* re-ordering gap (0 for delay all) */ __u32 duplicate; /* random packet dup (0=none ~0=100%) */ - __u32 rate; /* maximum transmit rate (bytes/sec) */ + __u32 jitter; /* random jitter in latency (us) */ }; #endif diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2004-07-08 13:45:06 -07:00 +++ b/net/sched/sch_netem.c 2004-07-08 13:45:06 -07:00 @@ -18,6 +18,7 @@ #include #include #include +#include #include @@ -28,14 +29,16 @@ */ struct netem_sched_data { - struct sk_buff_head qnormal; - struct sk_buff_head qdelay; + struct Qdisc *qdisc; + struct sk_buff_head delayed; struct timer_list timer; u32 latency; u32 loss; + u32 limit; u32 counter; u32 gap; + u32 jitter; }; /* Time stamp put into socket buffer control block */ @@ -43,6 +46,558 @@ psched_time_t time_to_send; }; +/* This is the distribution table for the normal distribution produced + * with NISTnet tools. + * The entries represent a scaled inverse of the cumulative distribution + * function. + */ +#define TABLESIZE 2048 +#define TABLEFACTOR 8192 + +static const short disttable[TABLESIZE] = { + -31473, -26739, -25226, -24269, + -23560, -22993, -22518, -22109, + -21749, -21426, -21133, -20865, + -20618, -20389, -20174, -19972, + -19782, -19601, -19430, -19267, + -19112, -18962, -18819, -18681, + -18549, -18421, -18298, -18178, + -18062, -17950, -17841, -17735, + -17632, -17532, -17434, -17339, + -17245, -17155, -17066, -16979, + -16894, -16811, -16729, -16649, + -16571, -16494, -16419, -16345, + -16272, -16201, -16130, -16061, + -15993, -15926, -15861, -15796, + -15732, -15669, -15607, -15546, + -15486, -15426, -15368, -15310, + -15253, -15196, -15140, -15086, + -15031, -14977, -14925, -14872, + -14821, -14769, -14719, -14669, + -14619, -14570, -14522, -14473, + -14426, -14379, -14332, -14286, + -14241, -14196, -14150, -14106, + -14062, -14019, -13976, -13933, + -13890, -13848, -13807, -13765, + -13724, -13684, -13643, -13604, + -13564, -13525, -13486, -13447, + -13408, -13370, -13332, -13295, + -13258, -13221, -13184, -13147, + -13111, -13075, -13040, -13004, + -12969, -12934, -12899, -12865, + -12830, -12796, -12762, -12729, + -12695, -12662, -12629, -12596, + -12564, -12531, -12499, -12467, + -12435, -12404, -12372, -12341, + -12310, -12279, -12248, -12218, + -12187, -12157, -12127, -12097, + -12067, -12038, -12008, -11979, + -11950, -11921, -11892, -11863, + -11835, -11806, -11778, -11750, + -11722, -11694, -11666, -11639, + -11611, -11584, -11557, -11530, + -11503, -11476, -11450, -11423, + -11396, -11370, -11344, -11318, + -11292, -11266, -11240, -11214, + -11189, -11164, -11138, -11113, + -11088, -11063, -11038, -11013, + -10988, -10964, -10939, -10915, + -10891, -10866, -10843, -10818, + -10794, -10770, -10747, -10723, + -10700, -10676, -10652, -10630, + -10606, -10583, -10560, -10537, + -10514, -10491, -10469, -10446, + -10424, -10401, -10378, -10356, + -10334, -10312, -10290, -10267, + -10246, -10224, -10202, -10180, + -10158, -10137, -10115, -10094, + -10072, -10051, -10030, -10009, + -9988, -9967, -9945, -9925, + -9904, -9883, -9862, -9842, + -9821, -9800, -9780, -9760, + -9739, -9719, -9699, -9678, + -9658, -9638, -9618, -9599, + -9578, -9559, -9539, -9519, + -9499, -9480, -9461, -9441, + -9422, -9402, -9383, -9363, + -9344, -9325, -9306, -9287, + -9268, -9249, -9230, -9211, + -9192, -9173, -9155, -9136, + -9117, -9098, -9080, -9062, + -9043, -9025, -9006, -8988, + -8970, -8951, -8933, -8915, + -8897, -8879, -8861, -8843, + -8825, -8807, -8789, -8772, + -8754, -8736, -8718, -8701, + -8683, -8665, -8648, -8630, + -8613, -8595, -8578, -8561, + -8543, -8526, -8509, -8492, + -8475, -8458, -8441, -8423, + -8407, -8390, -8373, -8356, + -8339, -8322, -8305, -8289, + -8272, -8255, -8239, -8222, + -8206, -8189, -8172, -8156, + -8140, -8123, -8107, -8090, + -8074, -8058, -8042, -8025, + -8009, -7993, -7977, -7961, + -7945, -7929, -7913, -7897, + -7881, -7865, -7849, -7833, + -7817, -7802, -7786, -7770, + -7754, -7739, -7723, -7707, + -7692, -7676, -7661, -7645, + -7630, -7614, -7599, -7583, + -7568, -7553, -7537, -7522, + -7507, -7492, -7476, -7461, + -7446, -7431, -7416, -7401, + -7385, -7370, -7356, -7340, + -7325, -7311, -7296, -7281, + -7266, -7251, -7236, -7221, + -7207, -7192, -7177, -7162, + -7148, -7133, -7118, -7104, + -7089, -7075, -7060, -7046, + -7031, -7016, -7002, -6988, + -6973, -6959, -6944, -6930, + -6916, -6901, -6887, -6873, + -6859, -6844, -6830, -6816, + -6802, -6788, -6774, -6760, + -6746, -6731, -6717, -6704, + -6690, -6675, -6661, -6647, + -6633, -6620, -6606, -6592, + -6578, -6564, -6550, -6537, + -6523, -6509, -6495, -6482, + -6468, -6454, -6441, -6427, + -6413, -6400, -6386, -6373, + -6359, -6346, -6332, -6318, + -6305, -6291, -6278, -6264, + -6251, -6238, -6224, -6211, + -6198, -6184, -6171, -6158, + -6144, -6131, -6118, -6105, + -6091, -6078, -6065, -6052, + -6039, -6025, -6012, -5999, + -5986, -5973, -5960, -5947, + -5934, -5921, -5908, -5895, + -5882, -5869, -5856, -5843, + -5830, -5817, -5804, -5791, + -5779, -5766, -5753, -5740, + -5727, -5714, -5702, -5689, + -5676, -5663, -5650, -5638, + -5625, -5612, -5600, -5587, + -5575, -5562, -5549, -5537, + -5524, -5512, -5499, -5486, + -5474, -5461, -5449, -5436, + -5424, -5411, -5399, -5386, + -5374, -5362, -5349, -5337, + -5324, -5312, -5299, -5287, + -5275, -5263, -5250, -5238, + -5226, -5213, -5201, -5189, + -5177, -5164, -5152, -5140, + -5128, -5115, -5103, -5091, + -5079, -5067, -5055, -5043, + -5030, -5018, -5006, -4994, + -4982, -4970, -4958, -4946, + -4934, -4922, -4910, -4898, + -4886, -4874, -4862, -4850, + -4838, -4826, -4814, -4803, + -4791, -4778, -4767, -4755, + -4743, -4731, -4719, -4708, + -4696, -4684, -4672, -4660, + -4649, -4637, -4625, -4613, + -4601, -4590, -4578, -4566, + -4554, -4543, -4531, -4520, + -4508, -4496, -4484, -4473, + -4461, -4449, -4438, -4427, + -4415, -4403, -4392, -4380, + -4368, -4357, -4345, -4334, + -4322, -4311, -4299, -4288, + -4276, -4265, -4253, -4242, + -4230, -4219, -4207, -4196, + -4184, -4173, -4162, -4150, + -4139, -4128, -4116, -4105, + -4094, -4082, -4071, -4060, + -4048, -4037, -4026, -4014, + -4003, -3992, -3980, -3969, + -3958, -3946, -3935, -3924, + -3913, -3901, -3890, -3879, + -3868, -3857, -3845, -3834, + -3823, -3812, -3801, -3790, + -3779, -3767, -3756, -3745, + -3734, -3723, -3712, -3700, + -3689, -3678, -3667, -3656, + -3645, -3634, -3623, -3612, + -3601, -3590, -3579, -3568, + -3557, -3545, -3535, -3524, + -3513, -3502, -3491, -3480, + -3469, -3458, -3447, -3436, + -3425, -3414, -3403, -3392, + -3381, -3370, -3360, -3348, + -3337, -3327, -3316, -3305, + -3294, -3283, -3272, -3262, + -3251, -3240, -3229, -3218, + -3207, -3197, -3185, -3175, + -3164, -3153, -3142, -3132, + -3121, -3110, -3099, -3088, + -3078, -3067, -3056, -3045, + -3035, -3024, -3013, -3003, + -2992, -2981, -2970, -2960, + -2949, -2938, -2928, -2917, + -2906, -2895, -2885, -2874, + -2864, -2853, -2842, -2832, + -2821, -2810, -2800, -2789, + -2778, -2768, -2757, -2747, + -2736, -2725, -2715, -2704, + -2694, -2683, -2673, -2662, + -2651, -2641, -2630, -2620, + -2609, -2599, -2588, -2578, + -2567, -2556, -2546, -2535, + -2525, -2515, -2504, -2493, + -2483, -2472, -2462, -2451, + -2441, -2431, -2420, -2410, + -2399, -2389, -2378, -2367, + -2357, -2347, -2336, -2326, + -2315, -2305, -2295, -2284, + -2274, -2263, -2253, -2243, + -2232, -2222, -2211, -2201, + -2191, -2180, -2170, -2159, + -2149, -2139, -2128, -2118, + -2107, -2097, -2087, -2076, + -2066, -2056, -2046, -2035, + -2025, -2014, -2004, -1994, + -1983, -1973, -1963, -1953, + -1942, -1932, -1921, -1911, + -1901, -1891, -1880, -1870, + -1860, -1849, -1839, -1829, + -1819, -1808, -1798, -1788, + -1778, -1767, -1757, -1747, + -1736, -1726, -1716, -1706, + -1695, -1685, -1675, -1665, + -1654, -1644, -1634, -1624, + -1613, -1603, -1593, -1583, + -1573, -1563, -1552, -1542, + -1532, -1522, -1511, -1501, + -1491, -1481, -1471, -1461, + -1450, -1440, -1430, -1420, + -1409, -1400, -1389, -1379, + -1369, -1359, -1348, -1339, + -1328, -1318, -1308, -1298, + -1288, -1278, -1267, -1257, + -1247, -1237, -1227, -1217, + -1207, -1196, -1186, -1176, + -1166, -1156, -1146, -1135, + -1126, -1115, -1105, -1095, + -1085, -1075, -1065, -1055, + -1044, -1034, -1024, -1014, + -1004, -994, -984, -974, + -964, -954, -944, -933, + -923, -913, -903, -893, + -883, -873, -863, -853, + -843, -833, -822, -812, + -802, -792, -782, -772, + -762, -752, -742, -732, + -722, -712, -702, -691, + -682, -671, -662, -651, + -641, -631, -621, -611, + -601, -591, -581, -571, + -561, -551, -541, -531, + -521, -511, -501, -491, + -480, -471, -460, -451, + -440, -430, -420, -410, + -400, -390, -380, -370, + -360, -350, -340, -330, + -320, -310, -300, -290, + -280, -270, -260, -250, + -240, -230, -220, -210, + -199, -190, -179, -170, + -159, -150, -139, -129, + -119, -109, -99, -89, + -79, -69, -59, -49, + -39, -29, -19, -9, + 1, 11, 21, 31, + 41, 51, 61, 71, + 81, 91, 101, 111, + 121, 131, 141, 152, + 161, 172, 181, 192, + 202, 212, 222, 232, + 242, 252, 262, 272, + 282, 292, 302, 312, + 322, 332, 342, 352, + 362, 372, 382, 392, + 402, 412, 422, 433, + 442, 453, 462, 473, + 483, 493, 503, 513, + 523, 533, 543, 553, + 563, 573, 583, 593, + 603, 613, 623, 633, + 643, 653, 664, 673, + 684, 694, 704, 714, + 724, 734, 744, 754, + 764, 774, 784, 794, + 804, 815, 825, 835, + 845, 855, 865, 875, + 885, 895, 905, 915, + 925, 936, 946, 956, + 966, 976, 986, 996, + 1006, 1016, 1026, 1037, + 1047, 1057, 1067, 1077, + 1087, 1097, 1107, 1117, + 1128, 1138, 1148, 1158, + 1168, 1178, 1188, 1198, + 1209, 1219, 1229, 1239, + 1249, 1259, 1269, 1280, + 1290, 1300, 1310, 1320, + 1330, 1341, 1351, 1361, + 1371, 1381, 1391, 1402, + 1412, 1422, 1432, 1442, + 1452, 1463, 1473, 1483, + 1493, 1503, 1513, 1524, + 1534, 1544, 1554, 1565, + 1575, 1585, 1595, 1606, + 1616, 1626, 1636, 1647, + 1656, 1667, 1677, 1687, + 1697, 1708, 1718, 1729, + 1739, 1749, 1759, 1769, + 1780, 1790, 1800, 1810, + 1821, 1831, 1841, 1851, + 1862, 1872, 1883, 1893, + 1903, 1913, 1923, 1934, + 1944, 1955, 1965, 1975, + 1985, 1996, 2006, 2016, + 2027, 2037, 2048, 2058, + 2068, 2079, 2089, 2099, + 2110, 2120, 2130, 2141, + 2151, 2161, 2172, 2182, + 2193, 2203, 2213, 2224, + 2234, 2245, 2255, 2265, + 2276, 2286, 2297, 2307, + 2318, 2328, 2338, 2349, + 2359, 2370, 2380, 2391, + 2401, 2412, 2422, 2433, + 2443, 2454, 2464, 2475, + 2485, 2496, 2506, 2517, + 2527, 2537, 2548, 2559, + 2569, 2580, 2590, 2601, + 2612, 2622, 2632, 2643, + 2654, 2664, 2675, 2685, + 2696, 2707, 2717, 2728, + 2738, 2749, 2759, 2770, + 2781, 2791, 2802, 2813, + 2823, 2834, 2845, 2855, + 2866, 2877, 2887, 2898, + 2909, 2919, 2930, 2941, + 2951, 2962, 2973, 2984, + 2994, 3005, 3015, 3027, + 3037, 3048, 3058, 3069, + 3080, 3091, 3101, 3113, + 3123, 3134, 3145, 3156, + 3166, 3177, 3188, 3199, + 3210, 3220, 3231, 3242, + 3253, 3264, 3275, 3285, + 3296, 3307, 3318, 3329, + 3340, 3351, 3362, 3373, + 3384, 3394, 3405, 3416, + 3427, 3438, 3449, 3460, + 3471, 3482, 3493, 3504, + 3515, 3526, 3537, 3548, + 3559, 3570, 3581, 3592, + 3603, 3614, 3625, 3636, + 3647, 3659, 3670, 3681, + 3692, 3703, 3714, 3725, + 3736, 3747, 3758, 3770, + 3781, 3792, 3803, 3814, + 3825, 3837, 3848, 3859, + 3870, 3881, 3893, 3904, + 3915, 3926, 3937, 3949, + 3960, 3971, 3983, 3994, + 4005, 4017, 4028, 4039, + 4051, 4062, 4073, 4085, + 4096, 4107, 4119, 4130, + 4141, 4153, 4164, 4175, + 4187, 4198, 4210, 4221, + 4233, 4244, 4256, 4267, + 4279, 4290, 4302, 4313, + 4325, 4336, 4348, 4359, + 4371, 4382, 4394, 4406, + 4417, 4429, 4440, 4452, + 4464, 4475, 4487, 4499, + 4510, 4522, 4533, 4545, + 4557, 4569, 4581, 4592, + 4604, 4616, 4627, 4639, + 4651, 4663, 4674, 4686, + 4698, 4710, 4722, 4734, + 4746, 4758, 4769, 4781, + 4793, 4805, 4817, 4829, + 4841, 4853, 4865, 4877, + 4889, 4900, 4913, 4925, + 4936, 4949, 4961, 4973, + 4985, 4997, 5009, 5021, + 5033, 5045, 5057, 5070, + 5081, 5094, 5106, 5118, + 5130, 5143, 5155, 5167, + 5179, 5191, 5204, 5216, + 5228, 5240, 5253, 5265, + 5278, 5290, 5302, 5315, + 5327, 5340, 5352, 5364, + 5377, 5389, 5401, 5414, + 5426, 5439, 5451, 5464, + 5476, 5489, 5502, 5514, + 5527, 5539, 5552, 5564, + 5577, 5590, 5603, 5615, + 5628, 5641, 5653, 5666, + 5679, 5691, 5704, 5717, + 5730, 5743, 5756, 5768, + 5781, 5794, 5807, 5820, + 5833, 5846, 5859, 5872, + 5885, 5897, 5911, 5924, + 5937, 5950, 5963, 5976, + 5989, 6002, 6015, 6028, + 6042, 6055, 6068, 6081, + 6094, 6108, 6121, 6134, + 6147, 6160, 6174, 6187, + 6201, 6214, 6227, 6241, + 6254, 6267, 6281, 6294, + 6308, 6321, 6335, 6348, + 6362, 6375, 6389, 6403, + 6416, 6430, 6443, 6457, + 6471, 6485, 6498, 6512, + 6526, 6540, 6554, 6567, + 6581, 6595, 6609, 6623, + 6637, 6651, 6665, 6679, + 6692, 6706, 6721, 6735, + 6749, 6763, 6777, 6791, + 6805, 6819, 6833, 6848, + 6862, 6876, 6890, 6905, + 6919, 6933, 6948, 6962, + 6976, 6991, 7005, 7020, + 7034, 7049, 7064, 7078, + 7093, 7107, 7122, 7136, + 7151, 7166, 7180, 7195, + 7210, 7225, 7240, 7254, + 7269, 7284, 7299, 7314, + 7329, 7344, 7359, 7374, + 7389, 7404, 7419, 7434, + 7449, 7465, 7480, 7495, + 7510, 7526, 7541, 7556, + 7571, 7587, 7602, 7618, + 7633, 7648, 7664, 7680, + 7695, 7711, 7726, 7742, + 7758, 7773, 7789, 7805, + 7821, 7836, 7852, 7868, + 7884, 7900, 7916, 7932, + 7948, 7964, 7981, 7997, + 8013, 8029, 8045, 8061, + 8078, 8094, 8110, 8127, + 8143, 8160, 8176, 8193, + 8209, 8226, 8242, 8259, + 8276, 8292, 8309, 8326, + 8343, 8360, 8377, 8394, + 8410, 8428, 8444, 8462, + 8479, 8496, 8513, 8530, + 8548, 8565, 8582, 8600, + 8617, 8634, 8652, 8670, + 8687, 8704, 8722, 8740, + 8758, 8775, 8793, 8811, + 8829, 8847, 8865, 8883, + 8901, 8919, 8937, 8955, + 8974, 8992, 9010, 9029, + 9047, 9066, 9084, 9103, + 9121, 9140, 9159, 9177, + 9196, 9215, 9234, 9253, + 9272, 9291, 9310, 9329, + 9349, 9368, 9387, 9406, + 9426, 9445, 9465, 9484, + 9504, 9524, 9544, 9563, + 9583, 9603, 9623, 9643, + 9663, 9683, 9703, 9723, + 9744, 9764, 9785, 9805, + 9826, 9846, 9867, 9888, + 9909, 9930, 9950, 9971, + 9993, 10013, 10035, 10056, + 10077, 10099, 10120, 10142, + 10163, 10185, 10207, 10229, + 10251, 10273, 10294, 10317, + 10339, 10361, 10384, 10406, + 10428, 10451, 10474, 10496, + 10519, 10542, 10565, 10588, + 10612, 10635, 10658, 10682, + 10705, 10729, 10752, 10776, + 10800, 10824, 10848, 10872, + 10896, 10921, 10945, 10969, + 10994, 11019, 11044, 11069, + 11094, 11119, 11144, 11169, + 11195, 11221, 11246, 11272, + 11298, 11324, 11350, 11376, + 11402, 11429, 11456, 11482, + 11509, 11536, 11563, 11590, + 11618, 11645, 11673, 11701, + 11728, 11756, 11785, 11813, + 11842, 11870, 11899, 11928, + 11957, 11986, 12015, 12045, + 12074, 12104, 12134, 12164, + 12194, 12225, 12255, 12286, + 12317, 12348, 12380, 12411, + 12443, 12475, 12507, 12539, + 12571, 12604, 12637, 12670, + 12703, 12737, 12771, 12804, + 12839, 12873, 12907, 12942, + 12977, 13013, 13048, 13084, + 13120, 13156, 13192, 13229, + 13267, 13304, 13341, 13379, + 13418, 13456, 13495, 13534, + 13573, 13613, 13653, 13693, + 13734, 13775, 13817, 13858, + 13901, 13943, 13986, 14029, + 14073, 14117, 14162, 14206, + 14252, 14297, 14343, 14390, + 14437, 14485, 14533, 14582, + 14631, 14680, 14731, 14782, + 14833, 14885, 14937, 14991, + 15044, 15099, 15154, 15210, + 15266, 15324, 15382, 15441, + 15500, 15561, 15622, 15684, + 15747, 15811, 15877, 15943, + 16010, 16078, 16148, 16218, + 16290, 16363, 16437, 16513, + 16590, 16669, 16749, 16831, + 16915, 17000, 17088, 17177, + 17268, 17362, 17458, 17556, + 17657, 17761, 17868, 17977, + 18090, 18207, 18328, 18452, + 18581, 18715, 18854, 18998, + 19149, 19307, 19472, 19645, + 19828, 20021, 20226, 20444, + 20678, 20930, 21204, 21503, + 21835, 22206, 22630, 23124, + 23721, 24478, 25529, 27316, +}; + +/* tabledist - return a pseudo-randomly distributed value with mean mu and + * std deviation sigma. Uses table lookup to approximate the desired + * distribution, and a uniformly-distributed pseudo-random source. + */ +static inline int tabledist(int mu, int sigma) +{ + int x; + int index; + int sigmamod, sigmadiv; + + if (sigma == 0) + return mu; + + index = (net_random() & (TABLESIZE-1)); + sigmamod = sigma%TABLEFACTOR; + sigmadiv = sigma/TABLEFACTOR; + x = sigmamod*disttable[index]; + + if (x >= 0) + x += TABLEFACTOR/2; + else + x -= TABLEFACTOR/2; + + x /= TABLEFACTOR; + x += sigmadiv*disttable[index]; + x += mu; + return x; +} + /* Enqueue packets with underlying discipline (fifo) * but mark them with current time first. */ @@ -50,110 +605,116 @@ { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + psched_time_t now; + long delay; pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); /* Random packet drop 0 => none, ~0 => all */ - if (q->loss >= net_random()) { + if (q->loss && q->loss >= net_random()) { sch->stats.drops++; return 0; /* lie about loss so TCP doesn't know */ } - if (q->qnormal.qlen < sch->dev->tx_queue_len) { - PSCHED_GET_TIME(cb->time_to_send); - PSCHED_TADD(cb->time_to_send, q->latency); - __skb_queue_tail(&q->qnormal, skb); - sch->q.qlen++; - sch->stats.bytes += skb->len; - sch->stats.packets++; - return 0; + /* If doing simple delay then gap == 0 so all packets + * go into the delayed holding queue + * otherwise if doing out of order only "1 out of gap" + * packets will be delayed. + */ + if (q->counter < q->gap) { + int ret; + + ++q->counter; + ret = q->qdisc->enqueue(skb, q->qdisc); + if (ret) + sch->stats.drops++; + return ret; } - - sch->stats.drops++; - kfree_skb(skb); - return NET_XMIT_DROP; + + q->counter = 0; + + PSCHED_GET_TIME(now); + if (q->jitter) + delay = tabledist(q->latency, q->jitter); + else + delay = q->latency; + + PSCHED_TADD2(now, delay, cb->time_to_send); + + /* Always queue at tail to keep packets in order */ + __skb_queue_tail(&q->delayed, skb); + sch->q.qlen++; + sch->stats.bytes += skb->len; + sch->stats.packets++; + return 0; } /* Requeue packets but don't change time stamp */ static int netem_requeue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + int ret; - __skb_queue_head(&q->qnormal, skb); - sch->q.qlen++; - return 0; + if ((ret = q->qdisc->ops->requeue(skb, q->qdisc)) == 0) + sch->q.qlen++; + + return ret; } -/* - * Check the look aside buffer list, and see if any freshly baked buffers. - * If head of queue is not baked, set timer. - */ -static struct sk_buff *netem_get_delayed(struct netem_sched_data *q) +static unsigned int netem_drop(struct Qdisc* sch) { - struct sk_buff *skb; - psched_time_t now; - long delay; - - skb = skb_peek(&q->qdelay); - if (skb) { - const struct netem_skb_cb *cb - = (const struct netem_skb_cb *)skb->cb; - - PSCHED_GET_TIME(now); - delay = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_dequeue: delay queue %p@%lu %ld\n", - skb, jiffies, delay); - - /* it's baked enough */ - if (delay <= 0) { - __skb_unlink(skb, &q->qdelay); - del_timer(&q->timer); - return skb; - } + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + unsigned int len; - if (!timer_pending(&q->timer)) { - q->timer.expires = jiffies + delay; - add_timer(&q->timer); - } + if ((len = q->qdisc->ops->drop(q->qdisc)) != 0) { + sch->q.qlen--; + sch->stats.drops++; } - return NULL; + return len; } /* Dequeue packet. - * If packet needs to be held up, then put in the delay - * queue and set timer to wakeup later. + * Move all packets that are ready to send from the delay holding + * list to the underlying qdisc, then just call dequeue */ static struct sk_buff *netem_dequeue(struct Qdisc *sch) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; struct sk_buff *skb; + psched_time_t now; + + PSCHED_GET_TIME(now); + while ((skb = skb_peek(&q->delayed)) != NULL) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + long delay + = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_dequeue: delay queue %p@%lu %ld\n", + skb, jiffies, delay); - skb = netem_get_delayed(q); - if (!skb && (skb = __skb_dequeue(&q->qnormal))) { - /* are we doing out of order packet skip? */ - if (q->counter < q->gap) { - pr_debug("netem_dequeue: send %p normally\n", skb); - q->counter++; - } else { - /* don't send now hold for later */ - pr_debug("netem_dequeue: hold [%p]@%lu\n", skb, jiffies); - __skb_queue_tail(&q->qdelay, skb); - q->counter = 0; - skb = netem_get_delayed(q); + /* if more time remaining? */ + if (delay > 0) { + mod_timer(&q->timer, jiffies + delay); + break; } + __skb_unlink(skb, &q->delayed); + + if (q->qdisc->enqueue(skb, q->qdisc)) + sch->stats.drops++; } - if (skb) + skb = q->qdisc->dequeue(q->qdisc); + if (skb) sch->q.qlen--; return skb; } -static void netem_timer(unsigned long arg) +static void netem_watchdog(unsigned long arg) { struct Qdisc *sch = (struct Qdisc *)arg; - pr_debug("netem_timer: fired @%lu\n", jiffies); + pr_debug("netem_watchdog: fired @%lu\n", jiffies); netif_schedule(sch->dev); } @@ -161,24 +722,63 @@ { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; - skb_queue_purge(&q->qnormal); - skb_queue_purge(&q->qdelay); + qdisc_reset(q->qdisc); + skb_queue_purge(&q->delayed); sch->q.qlen = 0; del_timer_sync(&q->timer); } +static int set_fifo_limit(struct Qdisc *q, int limit) +{ + struct rtattr *rta; + int ret = -ENOMEM; + + rta = kmalloc(RTA_LENGTH(sizeof(struct tc_fifo_qopt)), GFP_KERNEL); + if (rta) { + rta->rta_type = RTM_NEWQDISC; + rta->rta_len = RTA_LENGTH(sizeof(struct tc_fifo_qopt)); + ((struct tc_fifo_qopt *)RTA_DATA(rta))->limit = limit; + + ret = q->ops->change(q, rta); + kfree(rta); + } + return ret; +} + static int netem_change(struct Qdisc *sch, struct rtattr *opt) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; struct tc_netem_qopt *qopt = RTA_DATA(opt); + struct Qdisc *child; + int ret; - if (qopt->limit) - sch->dev->tx_queue_len = qopt->limit; + if (opt->rta_len < RTA_LENGTH(sizeof(*qopt))) + return -EINVAL; - q->gap = qopt->gap; - q->loss = qopt->loss; - q->latency = qopt->latency; + child = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (!child) + return -EINVAL; + + ret = set_fifo_limit(child, qopt->limit); + if (ret) { + qdisc_destroy(child); + return ret; + } + + sch_tree_lock(sch); + if (child) { + child = xchg(&q->qdisc, child); + if (child != &noop_qdisc) + qdisc_destroy(child); + + q->latency = qopt->latency; + q->jitter = qopt->jitter; + q->limit = qopt->limit; + q->gap = qopt->gap; + q->loss = qopt->loss; + } + sch_tree_unlock(sch); return 0; } @@ -190,10 +790,11 @@ if (!opt) return -EINVAL; - skb_queue_head_init(&q->qnormal); - skb_queue_head_init(&q->qdelay); + skb_queue_head_init(&q->delayed); + q->qdisc = &noop_qdisc; + init_timer(&q->timer); - q->timer.function = netem_timer; + q->timer.function = netem_watchdog; q->timer.data = (unsigned long) sch; q->counter = 0; @@ -214,6 +815,7 @@ struct tc_netem_qopt qopt; qopt.latency = q->latency; + qopt.jitter = q->jitter; qopt.limit = sch->dev->tx_queue_len; qopt.loss = q->loss; qopt.gap = q->gap; @@ -233,6 +835,7 @@ .enqueue = netem_enqueue, .dequeue = netem_dequeue, .requeue = netem_requeue, + .drop = netem_drop, .init = netem_init, .reset = netem_reset, .destroy = netem_destroy, From lkml@metanurb.dk Thu Jul 8 14:57:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 14:57:11 -0700 (PDT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68Lv6gi021334 for ; Thu, 8 Jul 2004 14:57:07 -0700 Received: from [192.168.0.2] (0x50c49cd1.adsl-fixed.tele.dk [80.196.156.209]) by pfepa.post.tele.dk (Postfix) with ESMTP id 52E8747FE29; Thu, 8 Jul 2004 23:57:04 +0200 (CEST) Subject: Re: preliminary conclusions regarding window size issues From: Redeeman To: bert hubert Cc: "David S. Miller" , Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, LKML Mailinglist , ALESSANDRO.SUARDI@ORACLE.COM In-Reply-To: <20040707232757.GA14471@outpost.ds9a.nl> References: <20040707232757.GA14471@outpost.ds9a.nl> Content-Type: text/plain Date: Thu, 08 Jul 2004 23:57:04 +0200 Message-Id: <1089323824.27085.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9 Content-Transfer-Encoding: 7bit X-archive-position: 6827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lkml@metanurb.dk Precedence: bulk X-list: netdev Content-Length: 5414 Lines: 126 hey bert, a little update on things. for 2 days ago, when we chatted on irc first, i could reach lkml.org, however, i had played abit with various settings.. i cant get that working now, neither can i get tcpdump to give me info.... i replaced my ugly speedstream router with a linux box, and speed has rised, as you predicted :D, it must have been the host mapping that doing some bad things, thanks for suggesting that :D theres a new site, which i cant reach either.. with 2.6.7, but 2.6.5 can. its my ipv6 tunnel broker, netgroup, the url is: http://noodle.ngdc.net/~hroi/tb/ however, when i bring the ipv6 tunnel up, i can reach it, but thats probably via ipv6. with ipv6 i cant connect to lkml.org either.. if you help me with the tcpdump paramters i will gladly provide all info i can.. thanks for all the help you did. it seems very close now :D On Thu, 2004-07-08 at 01:27 +0200, bert hubert wrote: > Two things: > > 1) packages.gentoo.org is currently unreachable by 2.6.7-recent. > This has been confirmed from several places, very easy to reproduce. Bug has > been filed with gentoo to fix their firewall. > > 2) What Alessandro Suardi sees is highly similar, except that he has it with > *all* remotes, except for google.it and a very small number of other > servers. > > This is what Alessandro saw going out. We artificially lowered the MTU > because of possible tunelling loss: > > 01:03:36.323132 192.168.1.3.33992 > 213.244.168.210.10000: S [tcp sum ok] 3497585848:3497585848(0) > win 5440 > (DF) (ttl 64, id 43908, len 60) > 01:03:36.396660 213.244.168.210.10000 > 192.168.1.3.33992: S [tcp sum ok] 3030562636:3030562636(0) > ack 3497585849 win 5792 > (DF) (ttl 53, id 0, len 60) > 01:03:36.396719 192.168.1.3.33992 > 213.244.168.210.10000: . [tcp sum ok] > ack 1 win 42 > (DF) (ttl 64, id 43909, len 52) > > Perfect SYN, SYN|ACK, ACK. > > 01:03:36.397362 192.168.1.3.33992 > 213.244.168.210.10000: P 1:463(462) ack 1 win 42 > > (DF) (ttl 64, id 43910, len 514) > > The GET request. > > 01:03:36.497588 213.244.168.210.10000 > 192.168.1.3.33992: . [tcp sum ok] ack 463 > win 6432 > (DF) (ttl 53, id 59171, len 52) > > And acked by my server. This trace is identical to what I see on the > receiving end: > > 29.84 62.211.168.xx.33992 > 213.244.168.210.10000: S [tcp sum ok] 3497585848:3497585848(0) > win 5440 > (DF) (ttl 50, id 43908, len 60) > 29.84 213.244.168.210.10000 > 62.211.168.xx.33992: S [tcp sum ok] 3030562636:3030562636(0) > ack 3497585849 win 5792 > (DF) (ttl 64, id 0, len 60) > 29.93 62.211.168.xx.33992 > 213.244.168.210.10000: . [tcp sum ok] 1:1(0) > ack 1 win 42 > (DF) (ttl 50, id 43909, len 52) > > 29.95 62.211.168.xx.33992 > 213.244.168.210.10000: P [tcp sum ok] 1:463(462) > ack 1 win 42 > (DF) (ttl 50, id 43910, len 514) > 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1(0) > ack 463 win 6432 > (DF) (ttl 64, id 59171, len 52) > > Except for TTL and NAT, this is identical. > > From here, things start to differ. I measure that I send out: > > 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1349(1348) > ack 463 win 6432 > (DF) (ttl 64, id 59172, len 1400) > 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: P [tcp sum ok] 1349:2697(1348) > ack 463 win 6432 > (DF) (ttl 64, id 59173, len 1400) > > This next packet is a repeat, because no ACK: > > 30.23 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1349(1348) > ack 463 win 6432 > (DF) (ttl 64, id 59174, len 1400) > > ad nauseam. Alessandro never sees these packets! After a while, he > disconnects, which happens pretty normally. From another trace (NOTE!): > > 00:38:21.326397 192.168.1.3.33285 > 213.244.168.210.10000: F 420:420(0) > ack 1 win 45 > (DF) > 00:38:21.410353 213.244.168.210.10000 > 192.168.1.3.33285: . > ack 421 win 6432 > (DF) > > We've tried with wscale=0,1,2 and these all work. Things go wrong for > wscale>=3. My current feeling is that some kind of QoS device is > interfering, and that the 'wscale gets stuffed' theory is wrong in this > case. > > I recall that 'Packeteer' QoS devices try to mess with windows. > > Alessandro has this DSL modem, which crashed once during testing. > http://www.usr.com/support/product-template.asp?prod=9003 > > So we're not done debugging. > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From jgarzik@pobox.com Thu Jul 8 15:29:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 15:29:49 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68MTigi022681 for ; Thu, 8 Jul 2004 15:29:45 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BihOg-0002EC-3F; Thu, 08 Jul 2004 23:29:42 +0100 Message-ID: <40EDCAC8.2050509@pobox.com> Date: Thu, 08 Jul 2004 18:29:28 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: Andy Fleming , netdev@oss.sgi.com, Kumar Gala , hadi@cyberus.ca, dwmw2@infradead.org Subject: Re: [RFR] gianfar ethernet driver References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <40EB89CC.2040100@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 5847 Lines: 131 Andy Fleming wrote: > Ok, I will change the defaults. Our performance testing indicates that > ttcp performance with mtu=1500 drops if NAPI is enabled vs. when it is > not. This is for both TCP and UDP packets. This made sense to me, as > NAPI incurs a slight latency penalty, and for 1518 byte frames, it does > not gain much advantage from interrupt reduction. NAPI only begins to mitigate at the weighted traffic level. Maybe your poll weight is too low? It sounds like you still need to do some tuning and profiling. For periodic but not high volume traffic, NAPI shouldn't incur latency penalties as you should be re-enabling interrupts shortly thereafter. Only when you start hitting the NAPI thresholds does it start reducing interrupts. At which point you should be at traffic levels where eliminating interrupt overhead should -decrease- your CPU usage. > Hmm... Does it call dev->set_mac_addr()? Because that only seems to > copy the new address into the dev structure. While I haven't been able > to trace the notification chain to discover the exact sequence of events > when someone changes the MAC address, I was thought that, in order for > the change to take effect, the interface needed to be brought down, then > up. gfar_set_mac_address() is only called during gfar_open(), so I am > not aware of any way someone else could cause it to be called without > restarting the interface. How should I set it up so that some other > code could call it? [...] > Yes, which is why gfar_change_mtu() halts the controller (thus ceasing > all DMA activity, and freeing buffer memory), then changes the MTU, and > then starts the controller again, causing buffers to be reallocated. I > feel like I'm missing something obvious. Perhaps I don't understand > exactly what you mean when you say "synchronization"? Are we talking > about locking, or making sure the hardware is configured without > screwing things up? Or...what? Through ifconfig, you can test changing MTU and MAC address while the interface is up. Probably other tools (/sbin/ip?) also. Synchronization means, what happens if all of the following occur at the same time: 1) RX packet received 2) net stack calls dev->hard_start_xmit() to transmit a packet 3) user decides he wants to change MAC addr/MTU ? By synchronization, I mean that you must ensure all entry points into your driver are protected from racing against each other, or simultaneously accessing the same data structure(s). >>>>> 33) merge-stopper: mii_parse_sr(). never wait for autonegotiation to >>>>> complete. it is an asynchronous operation that could exceed 30 >>>>> seconds. >>> >>> Hmm... >>> >>>>> 34) merge-stopper: dm9161_wait(). same thing as #33. >>> >>> This may be a problem. That function is there to work around an >>> issue in the PHY, wherein if you try to configure it before it has >>> come up all the way, it refuses to bring the link up. We've sworn at >>> this code many times, but there has, as of yet, not been a good >>> suggestion as to how we can ensure that the 9161 is ready before we >>> configure it. >> >> >> I interpret that as a driver bug :) >> >> As common sense, regardless of phy bugs, you should not be trying to >> configure the MAC _or_ the phy in the middle of autonegotiation. >> Presumeably you are using a combination of netif_stop_queue(), >> netif_carrier_off(), and netif_device_detach() to achieve this. > > > Hrm... This will require some fun, then. My current scheme for PHY > configuration/management does not allow me to stop if autonegotiation > isn't done. Clearly, I will have to rework the PHY code... I'm not sure I understand the "My current scheme" sentence. Clearly RX/TX DMA is not running, if you are in the middle of autonegotiation. So just make efforts to ensure that the kernel doesn't try to TX packets during that time (netif_carrier_off and/or netif_stop_queue), and make sure that random user ioctls (such as change-mtu or set-mac-addr :)) do not stomp all over the MAC while the phy is in the middle of autoneg. Good hardware will give you an interrupt when it link is up, otherwise you'll probably have to use a timer to poll for link (which isn't present until autoneg ends, obviously). >>>> 2) Also its pretty scary if you are doing: >>>> txbdp->status |= TXBD_INTERRUPT for every packet. >>>> Look at other drivers, they try to do this every few packets; >>>> or enable tx mitigation to slow the rate of those interupts. >>> >>> I don't believe this is as dire as you think. This bit only >>> indicates that, if the conditions are right, an interrupt will be >>> generated once that descriptor is processed, and its data sent. >>> Conditions which mitigate that are: >>> 1) coalescing is on, and the timer and counter have not triggered the >>> interrupt yet >>> 2) NAPI is enabled, and so interrupts are disabled after the first >>> packet arrives >>> 3) NAPI is disabled, but the driver is currently handling a previous >>> interrupt, so the interrupts are disabled for now. >> >> >> Even at 10/100 speeds, you really don't want to be generating one >> interrupt per Tx... > > > Hmm... My concern is this from Documentation/networking/driver.txt: > > "For example, this means that it is not allowed for your TX > mitigation scheme to let TX packets "hang out" in the TX > ring unreclaimed forever if no new TX packets are sent. > This error can deadlock sockets waiting for send buffer room > to be freed up." > > Is this no longer accurate? Anyway, as long as coalescing is on, there > won't be one interrupt per frame. Hopefully your hardware provides something other than purely packet-based intr mitigation? Usually there is a timeout, if no TX (or RX) interrupt has been sent in X time period. Jeff From hadi@cyberus.ca Thu Jul 8 16:08:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 16:08:53 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68N8Ugi023697 for ; Thu, 8 Jul 2004 16:08:50 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1Bii0D-0002W6-J4 for netdev@oss.sgi.com; Thu, 08 Jul 2004 19:08:29 -0400 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 1Bii08-0005IN-GN; Thu, 08 Jul 2004 19:08:24 -0400 Subject: Re: [RFR] gianfar ethernet driver From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Andy Fleming , Kumar Gala , netdev@oss.sgi.com, dwmw2@infradead.org In-Reply-To: <40EDC7A7.8060906@pobox.com> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <1089170282.1038.80.camel@jzny.localdomain> <20040707032913.GA1822@havoc.gtf.org> <1089171693.1037.87.camel@jzny.localdomain> <40EB8B84.7040301@pobox.com> <1089224952.1027.340.camel@jzny.localdomain> <40EDC7A7.8060906@pobox.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089328099.1046.24.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jul 2004 19:08:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2323 Lines: 69 On Thu, 2004-07-08 at 18:16, Jeff Garzik wrote: > To see if I understand you correctly, tell me if these two rules are > right or wrong: > > 1) If netif_stop_queue() is called, return 1 Return 1 _iff_ you dont stash the packet on ring. If you return 1, the toplayer will retry later with the same skb. If you stash it on the ring, the danger is tx complete will try to free it later while the toplayer code is still referencing it. A good oops. > 2) Otherwise, return 0 This will always work, but not the most optimal. > ? > > Note carefully that with #1, you have two sub-cases: > a) queue packet > check free descriptors > maybe stop queue > b) check free descriptors > maybe stop queue > queue packet > ... In both above cases return 0. c) check free descriptors if no space stop queue; return 1 /* free space */ queue packet > i.e. the packet passed to dev->hard_start_xmit may or may not have been > sent to hardware's DMA ring, when you stop the queue and return 1. Dangerous to return 1 and queue packet. > Second point of note: > > I worry that returning 1 when skb has -not- been queued to DMA ring will > result in loss of packet, with certain packet schedulers. For example, > a real-time packet scheduler may choose to drop rather than requeue the > skb, as the NIC driver author would intend. This is well taken care queueing code; if the scheduler decides that the packet to be returned is the one thats to be dropped then thats the responsibility of the scheduler. all we do is hand it a packet and say "please requeue that". This is a clean separation of tasks in Alexeys architecture. The driver is just a transmitter; the intelligence(real time, rate control) is above it. > While it may be reasonable for the packet scheduler to drop the packet, > in normal use with skb fragments (sendfile/TSO) that would result in a > packet potentially being dropped each time the NIC driver's > dev->hard_start_xmit() could not queue a packet to hardware. The test > (described in another email) of "free descriptors < MAX_SKB_FRAGS" > following the queueing of an skb to hardware is intended to avoid this > condition. I think if thats what the scheduler is designed to do, it should, None of the current schedulers that mostly do rate control do so. cheers, jamal From jgarzik@pobox.com Thu Jul 8 16:26:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 16:26:12 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i68NPrgi027597 for ; Thu, 8 Jul 2004 16:26:10 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BiiH0-0002ff-3l; Fri, 09 Jul 2004 00:25:50 +0100 Message-ID: <40EDD7F1.6090309@pobox.com> Date: Thu, 08 Jul 2004 19:25:37 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Kumar Gala , Netdev , David Woodhouse , jamal Subject: Re: [RFR] gianfar ethernet driver References: <8F52CF1D-C916-11D8-BB6A-000393DBC2E8@freescale.com> <40E98FB8.4070900@pobox.com> <20040708231131.GA20305@infradead.org> In-Reply-To: <20040708231131.GA20305@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 324 Lines: 9 Christoph Hellwig wrote: > Are you sure someone ever tried building this driver modular? The makefile > would try to build it into three separate modules, and they'd fail to load > due to unresolved cross-depencies.. For embedded drivers isn't not uncommon that it's never used as a module, so it wouldn't surprise me. From hadi@cyberus.ca Thu Jul 8 18:14:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 18:14:24 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i691EKgi031183 for ; Thu, 8 Jul 2004 18:14:21 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:15307 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Fri, 9 Jul 2004 02:14:20 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Bijxy-0005Ae-JC for netdev@linux-mips.org; Thu, 08 Jul 2004 21:14:18 -0400 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 1Bijxv-0001jJ-GX; Thu, 08 Jul 2004 21:14:15 -0400 Subject: Re: [RFC] netem - add jitter support. From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> References: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089335650.1046.150.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jul 2004 21:14:10 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 724 Lines: 21 On Thu, 2004-07-08 at 16:53, Stephen Hemminger wrote: > This patch adds jitter if desired to the delayed packets in the > netem scheduler. I dropped the rate stuff out and reorganized so > that an underlying pfifo queue is used (next plan is to make it > have class ops). > > The jitter is given as sigma to a Gaussian normal distribution. The actual > implementation is a reduced form of the table driven stuff in NISTnet > (free). Good stuff. - Is that NIST code/reference ok to put there? I have a feeling its non-free. - Could that table be computed in user space instead? This way you are not restricted to just the normal distribution. I could also use them if available from within tc sources, cheers, jamal From hadi@cyberus.ca Thu Jul 8 18:32:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 18:32:41 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i691Wbgi001321 for ; Thu, 8 Jul 2004 18:32:38 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BikFh-00036l-BY for netdev@oss.sgi.com; Thu, 08 Jul 2004 21:32:37 -0400 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 1BikFZ-0003f8-Qw; Thu, 08 Jul 2004 21:32:30 -0400 Subject: Re: [RFR] gianfar ethernet driver From: jamal Reply-To: hadi@cyberus.ca To: Andy Fleming Cc: Jeff Garzik , Andy Fleming , netdev@oss.sgi.com, Kumar Gala , dwmw2@infradead.org In-Reply-To: <944A2374-D137-11D8-8835-000393C30512@freescale.com> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <40EB89CC.2040100@pobox.com> <40EDCAC8.2050509@pobox.com> <944A2374-D137-11D8-8835-000393C30512@freescale.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089336744.1048.169.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jul 2004 21:32:25 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1906 Lines: 43 On Thu, 2004-07-08 at 19:36, Andy Fleming wrote: > I guess we'll have to do some more testing. The latency I'm talking > about for NAPI, however, is the delay between calling > __netif_rx_schedule(), and actually processing the packets. If you are > dealing with a benchmark where you send a packet, and then wait for a > response, and then send the next, and so on, doesn't this mean that > there will be a performance penalty? Or have I misunderstood how NAPI > works? There may be some confusion. There is overhead with NAPI in the case of low packet rates. What "low rate" means is dependent on your cpu capacity. For example consider the following: - CPU interupted, interupt disabled, rx thread scheduled - rx thread picks a packet off the DMA ring and process it to completion - receive thread asks for another packet but none has come in since last one --> interupts enabled .. x ms go by - another packet comes in and process repeats. In the above case as you can see the CPU can process each packet fast enough i.e before next packet comes in. How fast depends on your CPU. The above also shows that there are now at least two extra PCI operations (dis/enabling) interupts which wouldnt happen in the non-NAPI case. This will show up via slightly increased CPU usage typically. Yep, those web bench people bitch about this but so far weve seen no reason to change this. At low rates you should have plenty of CPU anyways. Thats what i meant earlier that NAPI could be problematic at "low rates". Infact as hinted to you already once you exceed that "low rate" threshold, the CPU availability goes down. What you can do is amortize the cost of that interupt enable/disable operation by rx coalescing as suggested by Jeff. So now instead of getting an immediate interupt for each incoming packet you get it for more than one or after a timeout. Hopefully this helps. cheers, jamal From hadi@cyberus.ca Thu Jul 8 18:42:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 18:42:58 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i691gtgi001986 for ; Thu, 8 Jul 2004 18:42:55 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BikPe-0008SG-Vd for netdev@oss.sgi.com; Thu, 08 Jul 2004 21:42:54 -0400 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 1BikPb-0004qE-7U; Thu, 08 Jul 2004 21:42:51 -0400 Subject: Re: [RFR] gianfar ethernet driver From: jamal Reply-To: hadi@cyberus.ca To: Andy Fleming Cc: Jeff Garzik , Andy Fleming , netdev@oss.sgi.com, Kumar Gala , dwmw2@infradead.org In-Reply-To: <1089336744.1048.169.camel@jzny.localdomain> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <40EB89CC.2040100@pobox.com> <40EDCAC8.2050509@pobox.com> <944A2374-D137-11D8-8835-000393C30512@freescale.com> <1089336744.1048.169.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089337366.1050.179.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Jul 2004 21:42:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1788 Lines: 45 On Thu, 2004-07-08 at 21:32, jamal wrote: > There may be some confusion. > There is overhead with NAPI in the case of low packet rates. > What "low rate" means is dependent on your cpu capacity. For example > consider the following: > - CPU interupted, interupt disabled, rx thread scheduled > - rx thread picks a packet off the DMA ring and process it to completion > - receive thread asks for another packet but none has come in since last > one --> interupts enabled > .. x ms go by > - another packet comes in and process repeats. > > In the above case as you can see the CPU can process each packet fast > enough i.e before next packet comes in. How fast depends on your CPU. I should have said also how loaded your CPU is. If your CPU is already loaded with other work it probably wont be processing those packets fast enough. Try running a while(1); loop program in user space and see. > The above also shows that there are now at least two extra PCI > operations (dis/enabling) interupts which wouldnt happen in the non-NAPI > case. This will show up via slightly increased CPU usage typically. > Yep, those web bench people bitch about this but so far weve seen no > reason to change this. At low rates you should have plenty of CPU > anyways. > Thats what i meant earlier that NAPI could be problematic at "low > rates". Infact as hinted to you already once you exceed that "low rate" > threshold, the CPU availability goes down. Meant: CPU becomes more available. > What you can do is amortize the cost of that interupt enable/disable > operation by rx coalescing as suggested by Jeff. So now instead of > getting an immediate interupt for each incoming packet you get it for > more than one or after a timeout. > > Hopefully this helps. > > cheers, > jamal > > > From nakam@linux-ipv6.org Thu Jul 8 20:51:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 20:51:15 -0700 (PDT) Received: from localhost (galaxy.linux-ipv6.org [203.178.140.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i693pDgi008352 for ; Thu, 8 Jul 2004 20:51:14 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1BimPe-0000So-00; Fri, 09 Jul 2004 12:51:02 +0900 Date: Fri, 9 Jul 2004 12:51:00 +0900 From: Masahide NAKAMURA To: Herbert Xu Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] Add nl_open to libnetlink Message-Id: <20040709125100.3edce4e9@localhost> In-Reply-To: <20040707110315.GA26100@gondor.apana.org.au> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> <20040707110315.GA26100@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 611 Lines: 25 Hi Herbert, Thanks for comments. On Wed, 7 Jul 2004 21:03:15 +1000 Herbert Xu wrote: > Could you please change the output of ip xfrm policy/state so that > it can be fed directly back in? For example the output of ip ro ls > can be fed back into ip ro add. Yes. I'll fix the output to follow current command line option. > Could you please also make it understand ip x p instead of ip x policy? Sure. > And there seems to be something wrong with the keys in the output of > ip x state. There are too many f's for it to be right. OK. I'll check it. -- Masahide NAKAMURA From jmorris@redhat.com Thu Jul 8 21:21:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 21:21:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i694L9gi009900 for ; Thu, 8 Jul 2004 21:21:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i694L5e1022432; Fri, 9 Jul 2004 00:21:05 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i694L4009405; Fri, 9 Jul 2004 00:21:04 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i694Ku4G008925; Fri, 9 Jul 2004 00:20:56 -0400 Date: Fri, 9 Jul 2004 00:20:56 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Andrew Morton , "David S. Miller" cc: Nivedita Singhvi , , , , Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] In-Reply-To: <20040702143949.21a50b74.akpm@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 3657 Lines: 156 On Fri, 2 Jul 2004, Andrew Morton wrote: > Well no. Those games with deflate_gfp() really need to go away. > in_atomic() works OK if CONFIG_PREEMPT is enabled. But with > CONFIG_PREEMPT=n, in_atomic() returns false inside spinlock. And > in_atomic()'s return value is unaffected by local_irq_disable(). > > This all needs to be redesigned, sorry. Ok, fixed. Lazy allocation is gone. Please apply. Signed-off-by: James Morris diff -urN -X dontdiff linux-2.6.7-bk20.o/crypto/deflate.c linux-2.6.7-bk20.w/crypto/deflate.c --- linux-2.6.7-bk20.o/crypto/deflate.c 2004-06-16 01:20:04.000000000 -0400 +++ linux-2.6.7-bk20.w/crypto/deflate.c 2004-07-09 00:38:43.137189624 -0400 @@ -39,44 +39,16 @@ #define DEFLATE_DEF_MEMLEVEL MAX_MEM_LEVEL struct deflate_ctx { - int comp_initialized; - int decomp_initialized; struct z_stream_s comp_stream; struct z_stream_s decomp_stream; }; -static inline int deflate_gfp(void) -{ - return in_softirq() ? GFP_ATOMIC : GFP_KERNEL; -} - -static int deflate_init(void *ctx) -{ - return 0; -} - -static void deflate_exit(void *ctx) -{ - struct deflate_ctx *dctx = ctx; - - if (dctx->comp_initialized) - vfree(dctx->comp_stream.workspace); - if (dctx->decomp_initialized) - kfree(dctx->decomp_stream.workspace); -} - -/* - * Lazy initialization to make interface simple without allocating - * un-needed workspaces. Thus can be called in softirq context. - */ static int deflate_comp_init(struct deflate_ctx *ctx) { int ret = 0; struct z_stream_s *stream = &ctx->comp_stream; - stream->workspace = __vmalloc(zlib_deflate_workspacesize(), - deflate_gfp()|__GFP_HIGHMEM, - PAGE_KERNEL); + stream->workspace = vmalloc(zlib_deflate_workspacesize()); if (!stream->workspace ) { ret = -ENOMEM; goto out; @@ -89,7 +61,6 @@ ret = -EINVAL; goto out_free; } - ctx->comp_initialized = 1; out: return ret; out_free: @@ -102,8 +73,7 @@ int ret = 0; struct z_stream_s *stream = &ctx->decomp_stream; - stream->workspace = kmalloc(zlib_inflate_workspacesize(), - deflate_gfp()); + stream->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL); if (!stream->workspace ) { ret = -ENOMEM; goto out; @@ -114,7 +84,6 @@ ret = -EINVAL; goto out_free; } - ctx->decomp_initialized = 1; out: return ret; out_free: @@ -122,6 +91,36 @@ goto out; } +static void deflate_comp_exit(struct deflate_ctx *ctx) +{ + vfree(ctx->comp_stream.workspace); +} + +static void deflate_decomp_exit(struct deflate_ctx *ctx) +{ + kfree(ctx->decomp_stream.workspace); +} + +static int deflate_init(void *ctx) +{ + int ret; + + ret = deflate_comp_init(ctx); + if (ret) + goto out; + ret = deflate_decomp_init(ctx); + if (ret) + deflate_comp_exit(ctx); +out: + return ret; +} + +static void deflate_exit(void *ctx) +{ + deflate_comp_exit(ctx); + deflate_decomp_exit(ctx); +} + static int deflate_compress(void *ctx, const u8 *src, unsigned int slen, u8 *dst, unsigned int *dlen) { @@ -129,12 +128,6 @@ struct deflate_ctx *dctx = ctx; struct z_stream_s *stream = &dctx->comp_stream; - if (!dctx->comp_initialized) { - ret = deflate_comp_init(dctx); - if (ret) - goto out; - } - ret = zlib_deflateReset(stream); if (ret != Z_OK) { ret = -EINVAL; @@ -165,12 +158,6 @@ struct deflate_ctx *dctx = ctx; struct z_stream_s *stream = &dctx->decomp_stream; - if (!dctx->decomp_initialized) { - ret = deflate_decomp_init(dctx); - if (ret) - goto out; - } - ret = zlib_inflateReset(stream); if (ret != Z_OK) { ret = -EINVAL; From vkondra@mail.ru Thu Jul 8 23:59:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jul 2004 23:59:47 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i696xhgi014738 for ; Thu, 8 Jul 2004 23:59:43 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 381A43F506B for ; Fri, 9 Jul 2004 10:59:35 +0400 (MSD) Received: from [82.80.132.207] (port=38659 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BipL0-0001nt-00; Fri, 09 Jul 2004 10:58:28 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [PATCH Linux-2.6.7-bk19] prism54 freq to channel incorrect for 5GHz Date: Fri, 9 Jul 2004 09:58:01 +0300 User-Agent: KMail/1.6.2 Cc: margitsw@t-online.de (Margit Schubert-While), jgarzik@pobox.com, prism54-devel@prism54.org References: <200407070831.47896.margitsw@t-online.de> In-Reply-To: <200407070831.47896.margitsw@t-online.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407090958.09739.vkondra@mail.ru> X-archive-position: 6840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2537 Lines: 72 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 07 July 2004 09:31, Margit Schubert-While wrote: [code skipped] > Note that AFAIK, the 5GHz WLAN channels start at 34 (5.17 GHz) > (but I am not sure) and I don't know the top limit (except that > it is <= 6GHz). Maybe somebody can shed light on this. > If there is a clear definition, that should be reflected int the code. > And something similar for channel_to_freq. > Apparently Japan is doing something in the 10GHz band - > will have to look for details. It is not 10 GHz band. They use the same 5 GHz band, exactly same frequencies, but channel is twice narrower - 10Mhz instead of 20Mhz as usual 802.11. In 10Mhz channels, they use 1/2 data rates as well. I.e. (6,9,12,18,24,36,48,54) rates replaced by (3,4.5,6,9,12,18,24,27) For frequencies, there are several documents. I'll try to summarize: 2.4Ghz band (as in code): in 802.11b standard, 14 channels defined: freq=channel*5 + 2407, channel=1..13 freq=2484, channel=14 Those "unofficial" frequencies are not defined. BTW, do anyone know document desctibing them? 5Ghz band (as in code): freq=channel*5 + 5000, channel=0..200 (from standard) For valid channels, 802.11a standard says there are 3 bands (all in US): 1: 36,40,44,48 2: 52,56,60,64 3: 149,153,157,161 TGh (regulation in Europe) adds channels 100..140 with interval 4 Tgj (japan) spec adds new rules: 10Mhz channels I mentioned above, and channel formula: freq=channel*5+dot11ChannelStartingFrequency; where dot11ChannelStartingFrequency may be 4000 or 5000 (as for .11a) For channels 183 and above, it is 4000, for others - 5000 Valid channels for Japan (note some channels may have both 10 and 20 Mhz width, some - only one of them): 20Mhz channels: 184,188,192,196;8,12,16,34,38,42,46 10Mhz channels: 183,184,185,187,188,189;7,8,11 For TGn (high throughput) standard expected to finalize around 2006, wide 40Mhz channels expected, with maybe some additional attributes. After describing this whole mess, some points to pay attention: - - channel number is not enough to determine frequency - there are same numbers in 2.4 and 5Ghz bands. - - to properly init hardware, channel witdh should be provided as well. Thus, we probable need to use (channel,band,width) triples or (channel,domain) tuples, where (band,width) mapped into domain. Vladimir -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7kIAqxdj7mhC6o0RAgdvAJ9KaF5ciW+EjJP8ITc6nbVQGYV4NgCfYkS/ KnSqVGQxal52x5cPPePphYM= =CHNv -----END PGP SIGNATURE----- From herbert@gondor.apana.org.au Fri Jul 9 01:14:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 01:15:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i698Esgi020517 for ; Fri, 9 Jul 2004 01:14:57 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BiqWt-0007Vh-00; Fri, 09 Jul 2004 18:14:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BiqWp-0002tK-00; Fri, 09 Jul 2004 18:14:43 +1000 Date: Fri, 9 Jul 2004 18:14:43 +1000 To: James Morris Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040709081443.GA11101@gondor.apana.org.au> References: <20040708011100.GA31600@gondor.apana.org.au> <20040708040235.GA32678@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040708040235.GA32678@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 759 Lines: 18 On Thu, Jul 08, 2004 at 02:02:35PM +1000, herbert wrote: > > That's only because the dst->output() functions are calling > skb_checksum_help(). Since those same functions assume the > skb to be "uncloned" anyway (they modify it directly by adding > headers etc.), they only need to call a version of > skb_checksum_help() that does not do a copy of the skb. If there are no objections, I'd like to create a version of skb_checksum_help() that doesn't copy the packet, and call that version from ah_output()/esp_output()/ipcomp_output(). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Jul 9 03:02:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 03:02:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69A2Mgi024663 for ; Fri, 9 Jul 2004 03:02:24 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BisCt-000854-00; Fri, 09 Jul 2004 20:02:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BisCr-0003BF-00; Fri, 09 Jul 2004 20:02:13 +1000 Date: Fri, 9 Jul 2004 20:02:13 +1000 To: James Morris Cc: netdev@oss.sgi.com Subject: IPCOMP scratch buffer (was: [Openswan dev] IPComp) Message-ID: <20040709100213.GA12215@gondor.apana.org.au> References: <20040706213135.GA21477@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 644 Lines: 14 On Tue, Jul 06, 2004 at 06:50:44PM -0400, James Morris wrote: > > I think it would be better to go with your original idea of allocating a > scratch buffer for each packet, based on the size of the packet. IPComp > is very slow path, and allocating 64k for each SA is optimizing for an > uncommon worst case in a way which will potentially eat up a lot of memory > (e.g. > 6MB for 100 tunnels). What about a shared per-cpu buffer? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Jul 9 03:13:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 03:13:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69ADbgi025545 for ; Fri, 9 Jul 2004 03:13:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BisNm-0008C4-00; Fri, 09 Jul 2004 20:13:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BisNj-0003Ci-00; Fri, 09 Jul 2004 20:13:27 +1000 Date: Fri, 9 Jul 2004 20:13:27 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [XFRM] Add FLUSHSA and FLUSHPOLICY Message-ID: <20040709101327.GA12291@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2607 Lines: 96 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch adds FLUSHSA and FLUSHPOLICY to xfrm_user which are analagous to SADB_FLUSH and SADB_X_SPDFLUSH in af_key. This is useful in KMs on startup/shutdown so that the system is reset to a known state. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/xfrm.h 1.22 vs edited ===== --- 1.22/include/linux/xfrm.h 2004-07-03 20:12:21 +10:00 +++ edited/include/linux/xfrm.h 2004-07-03 20:25:50 +10:00 @@ -135,6 +135,11 @@ XFRM_MSG_POLEXPIRE, #define XFRM_MSG_POLEXPIRE XFRM_MSG_POLEXPIRE + XFRM_MSG_FLUSHSA, +#define XFRM_MSG_FLUSHSA XFRM_MSG_FLUSHSA + XFRM_MSG_FLUSHPOLICY, +#define XFRM_MSG_FLUSHPOLICY XFRM_MSG_FLUSHPOLICY + XFRM_MSG_MAX }; @@ -240,6 +245,10 @@ struct xfrm_user_polexpire { struct xfrm_userpolicy_info pol; __u8 hard; +}; + +struct xfrm_usersa_flush { + __u8 proto; }; #define XFRMGRP_ACQUIRE 1 ===== net/xfrm/xfrm_user.c 1.44 vs edited ===== --- 1.44/net/xfrm/xfrm_user.c 2004-06-28 19:34:34 +10:00 +++ edited/net/xfrm/xfrm_user.c 2004-07-06 19:34:17 +10:00 @@ -814,6 +814,20 @@ return err; } +static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) +{ + struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); + + xfrm_state_flush(p->proto); + return 0; +} + +static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) +{ + xfrm_policy_flush(); + return 0; +} + static const int xfrm_msg_min[(XFRM_MSG_MAX + 1 - XFRM_MSG_BASE)] = { NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)), /* NEW SA */ NLMSG_LENGTH(sizeof(struct xfrm_usersa_id)), /* DEL SA */ @@ -826,6 +840,9 @@ NLMSG_LENGTH(sizeof(struct xfrm_user_expire)), /* EXPIRE */ NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)),/* UPD POLICY */ NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)), /* UPD SA */ + NLMSG_LENGTH(sizeof(struct xfrm_user_polexpire)), /* POLEXPIRE */ + NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)), /* FLUSH SA */ + NLMSG_LENGTH(0), /* FLUSH POLICY */ }; static struct xfrm_link { @@ -849,6 +866,9 @@ {}, { .doit = xfrm_add_policy }, { .doit = xfrm_add_sa, }, + {}, + { .doit = xfrm_flush_sa }, + { .doit = xfrm_flush_policy }, }; static int xfrm_done(struct netlink_callback *cb) --J/dobhs11T7y2rNN-- From vkondra@mail.ru Fri Jul 9 03:19:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 03:19:15 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69AJ0gi025914 for ; Fri, 9 Jul 2004 03:19:01 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id DB1FF3D8733 for ; Fri, 9 Jul 2004 11:04:01 +0400 (MSD) Received: from [82.80.132.207] (port=39321 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BipPH-00037I-00; Fri, 09 Jul 2004 11:02:53 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: ethernet QoS support? Date: Fri, 9 Jul 2004 10:02:21 +0300 User-Agent: KMail/1.6.2 Cc: Jeff Garzik , Kumar Gala References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <40ED9A1C.4040707@pobox.com> <1089316845.1072.1.camel@jzny.localdomain> In-Reply-To: <1089316845.1072.1.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200407091002.26410.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i69AJ0gi025914 X-archive-position: 6845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1018 Lines: 36 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I guess, Kumar is asking for support for several Tx queues with different priorities. One need to start/stop these queues separately. This is dictated by presense of different priorities on physical layer. Kumar, is it 802.11? WME or TGE? Vladimir. On Thursday 08 July 2004 23:00, jamal wrote: > On Thu, 2004-07-08 at 15:01, Jeff Garzik wrote: > > Kumar Gala wrote: > > > Jeff, > > > > > > I was wondering if there was any support for handling ethernet devices > > > that support multiple RX/TX queues to provide QoS. If so any pointers > > > would be great. > > > > IIRC skb->priority provides priority bands for TX. Not sure about RX... > > jamal? > > The question was very ambigous. > What is it that Kumar is looking for? Is it 802.1p, IP level etc? > > cheers, > jamal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7kMCqxdj7mhC6o0RAkeKAJ96kf49fbVy4qOjqqBBuNzmCteTrQCfU55Q ke3RQ2prgMLEssvjeQIgegs= =/KHu -----END PGP SIGNATURE----- From herbert@gondor.apana.org.au Fri Jul 9 04:48:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 04:48:22 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69BmFgi001022 for ; Fri, 9 Jul 2004 04:48:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BitrK-0000Mq-00; Fri, 09 Jul 2004 21:48:06 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BitrG-0003wu-00; Fri, 09 Jul 2004 21:48:02 +1000 Date: Fri, 9 Jul 2004 21:48:02 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NATT] Fix uh->len with IP options Message-ID: <20040709114802.GA13344@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1101 Lines: 38 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I just noticed that the UDP header length in esp4_output() is incorrect when IP options are present (in transport mode). This patch fixes exactly that. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/esp4.c 1.50 vs edited ===== --- 1.50/net/ipv4/esp4.c 2004-07-09 20:19:08 +10:00 +++ edited/net/ipv4/esp4.c 2004-07-09 21:45:46 +10:00 @@ -124,7 +124,7 @@ uh = (struct udphdr *)esph; uh->source = encap->encap_sport; uh->dest = encap->encap_dport; - uh->len = htons((*pskb)->len + alen - sizeof(struct iphdr)); + uh->len = htons((*pskb)->len + alen - iph->ihl*4); uh->check = 0; switch (encap->encap_type) { --k1lZvvs/B4yU6o8G-- From SRS0+983522a47f8ba84c2b35+320+infradead.org+hch@pentafluge.srs.infradead.org Fri Jul 9 05:32:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 05:33:14 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69CWWgi002178 for ; Fri, 9 Jul 2004 05:32:33 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1BiiQT-0005PK-K7; Fri, 09 Jul 2004 00:35:37 +0100 Date: Fri, 9 Jul 2004 00:35:37 +0100 From: Christoph Hellwig To: Jeff Garzik Cc: Kumar Gala , Netdev , David Woodhouse , jamal Subject: Re: [RFR] gianfar ethernet driver Message-ID: <20040708233537.GA20763@infradead.org> References: <8F52CF1D-C916-11D8-BB6A-000393DBC2E8@freescale.com> <40E98FB8.4070900@pobox.com> <20040708231131.GA20305@infradead.org> <40EDD7F1.6090309@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40EDD7F1.6090309@pobox.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 538 Lines: 14 On Thu, Jul 08, 2004 at 07:25:37PM -0400, Jeff Garzik wrote: > Christoph Hellwig wrote: > >Are you sure someone ever tried building this driver modular? The > >makefile > >would try to build it into three separate modules, and they'd fail to load > >due to unresolved cross-depencies.. > > > For embedded drivers isn't not uncommon that it's never used as a > module, so it wouldn't surprise me. then it shouldn't be declare tristate at least. But given that modularizig a netdriver is trivial not doing so counts as a bug to me. From hadi@cyberus.ca Fri Jul 9 06:19:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 06:19:19 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69DJFgi004329 for ; Fri, 9 Jul 2004 06:19:16 -0700 Received: from mx01.cybersurf.com ([IPv6:::ffff:209.197.145.104]:21679 "EHLO mx01.cybersurf.com") by linux-mips.org with ESMTP id ; Fri, 9 Jul 2004 14:19:15 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BivHQ-0003kf-3E for netdev@linux-mips.org; Fri, 09 Jul 2004 09:19:08 -0400 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 1BivHI-0004t3-57; Fri, 09 Jul 2004 09:19:00 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Jeff Garzik , Kumar Gala In-Reply-To: <200407091002.26410.vkondra@mail.ru> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <40ED9A1C.4040707@pobox.com> <1089316845.1072.1.camel@jzny.localdomain> <200407091002.26410.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089379137.1047.242.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Jul 2004 09:18:57 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 406 Lines: 14 On Fri, 2004-07-09 at 03:02, Vladimir Kondratiev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I guess, Kumar is asking for support for several Tx queues with different > priorities. One need to start/stop these queues separately. This is dictated > by presense of different priorities on physical layer. Exactly. I referenced him to you. Have you started any work yet? cheers, jamal From jgarzik@pobox.com Fri Jul 9 06:39:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 06:39:23 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69DdLgi005062 for ; Fri, 9 Jul 2004 06:39:22 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bi55N-0005L6-85; Wed, 07 Jul 2004 06:35:13 +0100 Message-ID: <40EB8B84.7040301@pobox.com> Date: Wed, 07 Jul 2004 01:35:00 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Andy Fleming , Kumar Gala , netdev@oss.sgi.com, dwmw2@infradead.org Subject: Re: [RFR] gianfar ethernet driver References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <1089170282.1038.80.camel@jzny.localdomain> <20040707032913.GA1822@havoc.gtf.org> <1089171693.1037.87.camel@jzny.localdomain> In-Reply-To: <1089171693.1037.87.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1960 Lines: 73 jamal wrote: > On Tue, 2004-07-06 at 23:29, Jeff Garzik wrote: > >>On Tue, Jul 06, 2004 at 11:18:02PM -0400, jamal wrote: >> >>>You dont return a 1 anywhere. >> >>That OK in one model. > > > True returning 0 this is not wrong; it > results in an extra call in the layer above the driver. > (I was trying to point that out in earlier email) er, I'm confused now? Every single ethernet driver returns zero, when it has queued a packet to hardware :) That's the common case, I would hope it doesn't result in additional work. >>When you are not dealing with fragments, the most optimal model >>eliminates the overflow case completely, so your ->hard_start_xmit looks >>like >> >> lock >> queue packet to DMA ring >> if (DMA ring full) >> netif_stop_queue() >> unlock >> >> return 0 >> >>If you can be sure -- by design -- that room is always available when >>the queue is not stopped, then that's fine. >> >>With fragments, you cannot be sure of this, if you do not wish to >>reserve MY_HW_MAX_FRAGMENTS slots on the DMA. Such a case would require >>moving the "if no more descriptors" check up, and returning 1 when the >>ring is empty. >> >>But ideally, you should write the driver where such a condition does not >>occur at all. > > > Ok, I overlooked fragments. I think it would be useful to capture this > in the doc you were preping. BTW, why can you figure out the fragment > count? If you can then the check for number of descriptors availabel > could account for that. In one design, you can say queue packet if (free descriptors < MAX_SKB_FRAGS) netif_stop_queue() return 0 That design wastes descriptors, but ensures you always have enough room when ->hard_start_xmit is called, and thus ensures you never have to return 1. Another design, that attempts to use more descriptors, is if (free descriptors < skb->frags) netif_stop_queue() return 1 queue packet if (free descriptors == 0) netif_stop_queue() return 0 From vkondra@mail.ru Fri Jul 9 06:43:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 06:43:48 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69DhYgi005407 for ; Fri, 9 Jul 2004 06:43:45 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id A874C3D3B96 for ; Fri, 9 Jul 2004 17:43:25 +0400 (MSD) Received: from [82.80.132.207] (port=18736 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BivdX-0002Br-00; Fri, 09 Jul 2004 17:42:02 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: ethernet QoS support? Date: Fri, 9 Jul 2004 16:41:30 +0300 User-Agent: KMail/1.6.2 Cc: Jeff Garzik , Kumar Gala References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407091002.26410.vkondra@mail.ru> <1089379137.1047.242.camel@jzny.localdomain> In-Reply-To: <1089379137.1047.242.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200407091641.35651.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i69DhYgi005407 X-archive-position: 6850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1320 Lines: 37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 July 2004 16:18, jamal wrote: > On Fri, 2004-07-09 at 03:02, Vladimir Kondratiev wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I guess, Kumar is asking for support for several Tx queues with different > > priorities. One need to start/stop these queues separately. This is > > dictated by presense of different priorities on physical layer. > > Exactly. I referenced him to you. Have you started any work yet? > > cheers, > jamal Yes, I do. So far, I have hardware related parts working. I rely on skb->priority to determine traffic class and select proper queue. All this worth nothing if one can't do separate queues. qdisc assignment for driver is not in driver's hands, so it can't do any assumptions. Generic in-kernel support needed here. Stack should allow driver to request additional Tx queues, providing some classifiers for each one. I tried to imagine how to work it around, but there is no good solution without those several queues. This mean, I will be able to deliver QoS support when network stack will make it possible. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7qCPqxdj7mhC6o0RAoFEAJ4j3a7ekravvh9vQC229M5a8PXcHACfY5Rp PuvymlVUopAiUyNGqbSMl/c= =gvWz -----END PGP SIGNATURE----- From jmorris@redhat.com Fri Jul 9 07:02:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 07:02:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69E2Zgi006163 for ; Fri, 9 Jul 2004 07:02:55 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69E2Qe1019447; Fri, 9 Jul 2004 10:02:26 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69E2Q019816; Fri, 9 Jul 2004 10:02:26 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i69E2P4G005678; Fri, 9 Jul 2004 10:02:25 -0400 Date: Fri, 9 Jul 2004 10:02:25 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , Subject: Re: pskb change in dst->output In-Reply-To: <20040709081443.GA11101@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 719 Lines: 23 On Fri, 9 Jul 2004, Herbert Xu wrote: > On Thu, Jul 08, 2004 at 02:02:35PM +1000, herbert wrote: > > > > That's only because the dst->output() functions are calling > > skb_checksum_help(). Since those same functions assume the > > skb to be "uncloned" anyway (they modify it directly by adding > > headers etc.), they only need to call a version of > > skb_checksum_help() that does not do a copy of the skb. > > If there are no objections, I'd like to create a version of > skb_checksum_help() that doesn't copy the packet, and call > that version from ah_output()/esp_output()/ipcomp_output(). This will break when cloned packets are passed to these functions. - James -- James Morris From jmorris@redhat.com Fri Jul 9 07:03:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 07:03:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69E3Qgi006228 for ; Fri, 9 Jul 2004 07:03:47 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69E3Me1019751; Fri, 9 Jul 2004 10:03:22 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69E3L020204; Fri, 9 Jul 2004 10:03:21 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i69E3L4G005755; Fri, 9 Jul 2004 10:03:21 -0400 Date: Fri, 9 Jul 2004 10:03:21 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: netdev@oss.sgi.com Subject: Re: IPCOMP scratch buffer (was: [Openswan dev] IPComp) In-Reply-To: <20040709100213.GA12215@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 424 Lines: 19 On Fri, 9 Jul 2004, Herbert Xu wrote: > > scratch buffer for each packet, based on the size of the packet. IPComp > > is very slow path, and allocating 64k for each SA is optimizing for an > > uncommon worst case in a way which will potentially eat up a lot of memory > > (e.g. > 6MB for 100 tunnels). > > What about a shared per-cpu buffer? > You can try if you like. - James -- James Morris From hadi@cyberus.ca Fri Jul 9 07:34:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 07:34:05 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69EY0gi021153 for ; Fri, 9 Jul 2004 07:34:02 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BiwRp-00069V-S6 for netdev@oss.sgi.com; Fri, 09 Jul 2004 10:33:57 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BiwRj-0005zA-Dj; Fri, 09 Jul 2004 10:33:51 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Jeff Garzik , Kumar Gala In-Reply-To: <200407091641.35651.vkondra@mail.ru> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407091002.26410.vkondra@mail.ru> <1089379137.1047.242.camel@jzny.localdomain> <200407091641.35651.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089383622.1030.21.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Jul 2004 10:33:43 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1200 Lines: 31 On Fri, 2004-07-09 at 09:41, Vladimir Kondratiev wrote: > So far, I have hardware related parts working. I rely on skb->priority to > determine traffic class and select proper queue. Who marks the skb->priority? Is that the default mark as per TOS? I think the VLAN code marks it as well. > All this worth nothing if one can't do separate queues. qdisc assignment for > driver is not in driver's hands, so it can't do any assumptions. > Generic > in-kernel support needed here. Stack should allow driver to request > additional Tx queues, providing some classifiers for each one. I tried to > imagine how to work it around, but there is no good solution without those > several queues. I dont think we should put intelligence at the driver level. We can have drivers configured via parameter to look at the priority field. Only then do they look at it; else use only single ring. When multi-ring is on, you intepret the priority. priority field is set above driver based on which priority queue the packet was grabbed from (before sending to driver). > This mean, I will be able to deliver QoS support when network stack will make > it possible. So what do you do now? cheers, jamal From kumar.gala@freescale.com Fri Jul 9 08:46:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 08:46:27 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69FkQgi029491 for ; Fri, 9 Jul 2004 08:46:27 -0700 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i69FkKSE000706; Fri, 9 Jul 2004 08:46:20 -0700 (MST) Received: from [10.82.17.247] ([10.82.17.247]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i69Fk4Pi022212; Fri, 9 Jul 2004 10:46:05 -0500 In-Reply-To: <200407091002.26410.vkondra@mail.ru> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <40ED9A1C.4040707@pobox.com> <1089316845.1072.1.camel@jzny.localdomain> <200407091002.26410.vkondra@mail.ru> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2290273A-D1BF-11D8-B72C-000393DBC2E8@freescale.com> Content-Transfer-Encoding: 7bit Cc: , Kumar Gala , , Jeff Garzik From: Kumar Gala Subject: Re: ethernet QoS support? Date: Fri, 9 Jul 2004 10:46:25 -0500 To: Vladimir Kondratiev X-Mailer: Apple Mail (2.618) X-archive-position: 6856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumar.gala@freescale.com Precedence: bulk X-list: netdev Content-Length: 1212 Lines: 48 On Jul 9, 2004, at 2:02 AM, Vladimir Kondratiev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I guess, Kumar is asking for support for several Tx queues with > different > priorities. One need to start/stop these queues separately. This is > dictated > by presense of different priorities on physical layer. > > Kumar, is it 802.11? WME or TGE? I'm not sure what WME or TGE stand for, we are looking at a gig-e controller. > > Vladimir. > > On Thursday 08 July 2004 23:00, jamal wrote: >> On Thu, 2004-07-08 at 15:01, Jeff Garzik wrote: >>> Kumar Gala wrote: >>>> Jeff, >>>> >>>> I was wondering if there was any support for handling ethernet >>>> devices >>>> that support multiple RX/TX queues to provide QoS. If so any >>>> pointers >>>> would be great. >>> >>> IIRC skb->priority provides priority bands for TX. Not sure about >>> RX... >>> jamal? >> >> The question was very ambigous. >> What is it that Kumar is looking for? Is it 802.1p, IP level etc? >> >> cheers, >> jamal > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFA7kMCqxdj7mhC6o0RAkeKAJ96kf49fbVy4qOjqqBBuNzmCteTrQCfU55Q > ke3RQ2prgMLEssvjeQIgegs= > =/KHu > -----END PGP SIGNATURE----- From jgarzik@pobox.com Fri Jul 9 09:47:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 09:47:26 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69GlNgi031155 for ; Fri, 9 Jul 2004 09:47:24 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BiyWu-0000VY-4v; Fri, 09 Jul 2004 17:47:20 +0100 Message-ID: <40EECC0C.9040304@pobox.com> Date: Fri, 09 Jul 2004 12:47:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: David Woodhouse , Kumar Gala , jamal Subject: Phy layer notes (was Re: [RFR] gianfar ethernet driver) References: <8F52CF1D-C916-11D8-BB6A-000393DBC2E8@freescale.com> <40E98FB8.4070900@pobox.com> <1089375760.28614.1365.camel@hades.cambridge.redhat.com> In-Reply-To: <1089375760.28614.1365.camel@hades.cambridge.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1527 Lines: 42 David Woodhouse wrote: > Hmmm. > > eth0: Running with NAPI disabled > eth0: 64/64 RX/TX BD ring size > eth1: Gianfar Ethernet Controller Version 1.0, 05:e6:9e:c0:05:e6 > eth1: Running with NAPI disabled > eth1: 64/64 RX/TX BD ring size > eth0: PHY id 2060e1 is not supported! > eth0: No PHY found > IP-Config: Failed to open eth0 > IP-Config: Device `eth0' not found > > The PHY is a BCM5421S. Does it really have to give up completely? Isn't > there a subset of common MII support it could use? > > Is it expected that every NIC driver will include its own version of > support for the PHYs which have actually been seen paired with that NIC, > or is there some more generic support planned? David W and I discussed some of this on IRC. 1) most gige phys can be treated with generic GMII code. unfortunately experience shows that phy init can often involve phy-specific magic sequences. 2) we do need a generic phy layer, and I'm looking for volunteers who want to prototype a nice, small, compact one. BenH has a nice template in sungem_phy.c. 3) drivers/net/mii.c and include/linux/mii.h need GMII code and constants. Feel free to add. 4) generic TBI code would be nice, too. (TBI is a standard gige fibre interface) 5) sometimes a MAC+phy pairing is unique enough that you need MAC-specific support for a particular phy. For example, one might wind up with two phy drivers, one a generic Broadcom GMII phy driver (for use by any NIC driver), and one a tg3-specific Broadcom GMII phy driver. From rhee@eos.ncsu.edu Fri Jul 9 10:40:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 10:40:19 -0700 (PDT) Received: from uni01mr.unity.ncsu.edu (uni01mr.unity.ncsu.edu [152.1.1.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69He9gi032352 for ; Fri, 9 Jul 2004 10:40:10 -0700 Received: from localhost (localhost [127.0.0.1]) by uni01mr.unity.ncsu.edu (8.12.10/8.12.10/N.20040607.01) with ESMTP id i69FcNOc028683; Fri, 9 Jul 2004 11:38:23 -0400 (EDT) Received: from uni01mr.unity.ncsu.edu ([127.0.0.1]) by localhost (uni01mr.unity.ncsu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28550-04; Fri, 9 Jul 2004 11:38:22 -0400 (EDT) Received: from VALUED66329DCC (bakdu.csc.ncsu.edu [152.14.51.150]) by uni01mr.unity.ncsu.edu (8.12.10/8.12.10/N.20040607.01) with ESMTP id i69FcLQs028671; Fri, 9 Jul 2004 11:38:21 -0400 (EDT) Message-Id: <200407091538.i69FcLQs028671@uni01mr.unity.ncsu.edu> From: "Injong Rhee" To: "'Matt Mathis'" Cc: "'David S. Miller'" , "'Stephen Hemminger'" , , , , "'John Heffner'" , "'Jamshid Mahdavi'" Subject: RE: [RFC] TCP burst control Date: Fri, 9 Jul 2004 11:36:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRkNxt395y9KL1jTSCODC+yFpF74ABksRrQ In-Reply-To: X-archive-position: 6859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rhee@eos.ncsu.edu Precedence: bulk X-list: netdev Content-Length: 11307 Lines: 264 Hi David and Matt, The main cause of the problem is that the current linux implementation of TCP does not follow RFC, especially by incorporating its own burst control mechanisms. Rate halving is a form of burst control -- but this is not part of the problems. *The cause is the use of packet-in-flight to moderate cwnd*. This is not part of the standard and it interferes with a lot of congestion control functions including rate halving. Let me give you some more information below. When fast recovery kicks in, packet-in-flight (flightSize) can be very small because of lost packets. This is even more so with high speed connections having large cwnd values (i.e., you lose more packets with these connections). Because flightSize is small, but cwnd is still very large compared to flightSize (even after cwnd reduction due to fast recovery), there could be a lot of burst. This burst happens because the connection can send as many as (cwnd - flightSize) at a time. Here the current implementation makes mistake by reducing cwnd to flightSize + C -- this is a violation of RFC 2851. This surely helps burst -- because it does not send any new packets for a long time :-) Since cwnd becomes very close to flightSize, rate halving obviously does not work here. Note that rate halving gradually reduces cwnd to the half of cwnd as duplicate acks are arriving. But this burst control of Linux makes rate halving ineffective because cwnd is anyway reduced far below the half of cwnd because flightSize is far less than the half. This feature not only creates a lot of oscillation in transmission (so making the flow very unstable), but also reduces the throughput very significantly. Look at the link below: the experimental results with the current linux burst control with a scalable TCP flow. You can see that a back-to-back loss leaves big gaps in transmission. We chose Scalable TCP for demo because STCP may show a bigger difference as it has more fast recovery per second. There are three of them. http://www4.ncsu.edu/~lxu2/stcp_burst/ In the link, you can also find the experiment with our new burst control. It makes the flow quite smooth. This is a real problem (I would say a bug) with the current implementation that it does not follow RFC. In contrast, our implementation does not violate RFC since we are not modifying cwnd at all because of flightSize. We leave cwnd to congestion control. The burst control is just to regulate the transmission so that it would not create the burst; cwnd is only the guidance on how many packets you can send at a time and the burst control is simply to adjust the transmission to match cwnd, but without creating too much burst. In this regard, our control is pretty good. It may not be the best one and requires more work to find the optimal control, but you cannot go wrong with our technique since it does not violate RFC and it only makes improvement. Along with burst control, I would like to add one additional mechanism in ack processing. This does not cause any behavior change with TCP stack - it is going to make it run faster. Just implementation suggestion. When processing selective acks, the current linux implementation does too much redundant work; since some sack blocks are duplicates, duplicate sack blocks do not need a processing again. We need to remove this redundancy to speed up sack processing. Also every time that a new sack arrives, the current implementation performs a linear search on a list. This causes a lot of overhead especially with high speed -- because you are receiving many ACKs. This search processing can be greatly enhanced with a simple caching scheme. All these changes require only a few lines of code. Again, no behavior changes and just improves the speed. Also it is general enough to be used with any TCP variants. Our test indicates this simple mechanism is good enough (no need for any fancier implementation as HTCP suggests), and is originally implemented by Tom Kelly. Ok. enuf arguing and rest my case here. Injong and Lisong. > -----Original Message----- > From: Matt Mathis [mailto:mathis@psc.edu] > To: Injong Rhee > Cc: 'David S. Miller'; Stephen Hemminger; netdev@oss.sgi.com; > rhee@ncsu.edu; lxu2@ncsu.edu; John Heffner; Jamshid Mahdavi > Subject: RE: [RFC] TCP burst control > > Yes, Injong is correct about the problem with Rate Having. I haven't > looked at > his fix to see if I agree with it, but let me summarize the problem that > we > never finished (and prevented us from formally publishing it). > > Basicly if the sender is under fluctuating resource stress such that awnd > (the > actual window) is frequently less than cwnd (remember this was written > BEFORE > cwnd validation.) then a loss that is detected when awnd is at a minimum > sets > cwnd to an unreasonably small value that has nothing to do with the actual > state of the network. Since we also set ssthresh down to cwnd, this takes > "forever" to recover. > > The real killer is if the application is periodicly bursty, such as > copying > >from older unbuffered disks or timesharing systems running other compute > bound > applications (normal for supercomputers). Under these conditions TCP > suffers > >from frequent idle intervals, each restarting with a full window burst > (pre-cwnd validation!). If the burst was just slightly larger than the > network > pipe size, then the packets at the end of the burst are most at risk of > being > dropped. When the ACKs for subsequent packets arrive and the loss is > detected, > awnd will be nearly zero, resulting in nearly zero cwnd and ssthresh...... > > We were in the heat of investigating solutions to this and other related > problems (there are multiple potential solutions), when we realized that > autotuning is orders of magnitude more important (at least to our users). > > As the code points out there are other corner cases that we missed, such > as > reordering and such. In principle I would like to come back to congestion > control work, revisit FACK-RH and fold in all of the new stuff such as > cwnd > validation and window moderation. (BTW I would not be surprised if these > algorithms don't play nicely with rate halving - each was designed and > tested > without considering the effects of the others). > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis http://www.psc.edu/~mathis > Work:412.268.3319 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and forcibly apply it to others. > > On Wed, 7 Jul 2004, Injong Rhee wrote: > > > > > Hi David, > > > > Let me clarify the issue a little. In my earlier message, I might have > > sounded like accusing rate halving of the burst problem and window > > oscillation. I might have misrepresented it a little in the heat of > writing > > the email too fast :-). In fact, rate halving helps ease burst during > fast > > recovery as written in the Internet draft. > > > > The main problem lies in the variable that rate halving is closely > > interacting with in TCP SACK implementation: packet_in_flight (or pipe_). > In > > the current implementation of Linux TCP SACK, cwnd is set to > > packet_in_flight + C for every ack for CWR, recovery, and timeout-- Here > C > > is 1 to 3. But many times, packet_in_flight drops *far* below cwnd > during > > fast recovery. In high speed networks, a lot of packets can be lost in > one > > RTT (even acks as well because of slow CPUs). If that happens, > > packet_in_flight becomes very small. At this time, Linux cwnd moderation > (or > > burst control) kicks in by setting cwnd to packet_in_flight + C so that > the > > sender does not burst all those packets between packet_in_flight and > cwnd at > > a single time. However, there is a problem with this approach. Since > cwnd is > > kept to very small, the transmission rate drops to almost zero during > fast > > recovery -- it should drop only to half of the current transmission rate > (or > > in high-speed protocols like BIC, it is only 87% of the current rate). > Since > > fast recovery lasts more than several RTTs, the network capacity is > highly > > underutilized during fast recovery. Furthermore, right after fast > recovery, > > cwnd goes into slow start since cwnd is typically far smaller than > ssthrsh > > after fast recovery. This also creates a lot of burst -- likely causing > back > > to back losses or even timeouts. > > > > You can see this behavior in the following link: > > > > > http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments > /B > > IC-600-75-7500-1-0-0-noburst/index.htm > > > > We run in a dummynet without any change in the burst control. You can > see > > that whenever there is fast recovery, the rate almost drop to zero. The > pink > > line is the throughput observed from the dummynet at every second, and > red > > one is from Iperf. In the second figure, you can see cwnd. It drops to > the > > bottom during fast recovery -- this is not part of congestion control. > It is > > the burst control of Linux SACK doing it. > > > > But with our new burst control: > > > > > http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments > /B > > IC-600-75-7500-1-0-0/index.htm > > > > You can see that cwnd is quite stabilized and the throughput does not > have > > as much dip as in the original case. > > > > Here is what we do: instead of reducing cwnd to packet_in_flight (which > is, > > in fact, meddling with congestion control), we reduce the gap between > these > > two numbers by allowing transmitting more packets per ack (we set this > to > > three more packets per ack) until packet_in_flight becomes close to cwnd. > > Also right after fast recovery, we increase packet_in_flight by 1% of > > packet_in_flight up to cwnd. This reduces the huge burst after fast > > recovery. Our implementation is trying to leave cwnd only to congestion > > control and separates burst control from congestion control. This makes > the > > behavior of congestion control more predictable. We will report more on > > this tomorrow when we get back to the Lab to test some other > environments, > > especially when we have smaller buffers. This scheme may not be the cure > for > > all and needs more testing. So far, it has been working very well. > > > > Stay tuned. > > Injong. > > --- > > Injong Rhee, Associate Professor > > North Carolina State University > > Raleigh, NC 27699 > > rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee > > > > > > > > -----Original Message----- > > From: David S. Miller [mailto:davem@redhat.com] > > Sent: Tuesday, July 06, 2004 8:29 PM > > To: Injong Rhee > > Cc: shemminger@osdl.org; netdev@oss.sgi.com; rhee@ncsu.edu; > lxu2@ncsu.edu; > > mathis@psc.edu > > Subject: Re: [RFC] TCP burst control > > > > On Tue, 6 Jul 2004 20:09:41 -0400 > > "Injong Rhee" wrote: > > > >> Currently with rate having, current Linux tcp stack is full of hacks > that > > in > >> fact, hurt the performance of linux tcp (sorry to say this). > > > > If rate-halving is broken, have you taken this up with it's creator, > > Mr. Mathis? What was his response? > > > > I've added him to the CC: list so this can be properly discussed. > > From vkondra@mail.ru Fri Jul 9 11:29:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 11:29:30 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69ITQgi001318 for ; Fri, 9 Jul 2004 11:29:27 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 34C3F3D5910 for ; Fri, 9 Jul 2004 22:29:25 +0400 (MSD) Received: from [82.80.132.207] (port=24363 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1Bj05S-000P4V-00; Fri, 09 Jul 2004 22:27:07 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: ethernet QoS support? Date: Fri, 9 Jul 2004 21:26:37 +0300 User-Agent: KMail/1.6.2 Cc: Jeff Garzik , Kumar Gala References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407091641.35651.vkondra@mail.ru> <1089383622.1030.21.camel@jzny.localdomain> In-Reply-To: <1089383622.1030.21.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200407092126.43021.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i69ITQgi001318 X-archive-position: 6860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2684 Lines: 58 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 July 2004 17:33, jamal wrote: > On Fri, 2004-07-09 at 09:41, Vladimir Kondratiev wrote: > > So far, I have hardware related parts working. I rely on skb->priority to > > determine traffic class and select proper queue. > > Who marks the skb->priority? Is that the default mark as per TOS? > I think the VLAN code marks it as well. I don't care. It should not be driver's business. Actually, it is TOS. AFAIK, application supposed to do setsockoption(SO_PRIORITY) on its socket so set priority. > > > All this worth nothing if one can't do separate queues. qdisc assignment > > for driver is not in driver's hands, so it can't do any assumptions. > > Generic > > in-kernel support needed here. Stack should allow driver to request > > additional Tx queues, providing some classifiers for each one. I tried to > > imagine how to work it around, but there is no good solution without > > those several queues. > > I dont think we should put intelligence at the driver level. > We can have drivers configured via parameter to look at the priority > field. Only then do they look at it; else use only single ring. > When multi-ring is on, you intepret the priority. > priority field is set above driver based on which priority queue the > packet was grabbed from (before sending to driver). Agree about intelligence. Driver should serve link and MAC layer. But exactly because link layer have different priorities, driver need several Tx queues. It is stack's business to route packet to the proper queue. Driver should deliver it using appropriate MAC layer priority. > > > This mean, I will be able to deliver QoS support when network stack will > > make it possible. > > So what do you do now? Waiting. If no support will exist, it simply means we will be unable to use QoS provided by modern 802.11. Depending on market development, impact may range from being slightly slower relating to Windows clients, to being almost completely unable to communicate for traffic like VOIP. Later will be the case if most access points will implement QoS as in TGE. I can now deliver packets accordingly to skb->priority, but if stack have different idea for what is proper proportion between different sorts of traffic, driver's Tx path will be flooded with low priority frames. Situation is much worser for streams with admission control. I have no mechanism to communicate with stack for such traffic establishment and tear down. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7uNiqxdj7mhC6o0RAoDyAJ9dx9ibVRee1tV5RRZXyK5X+4QjswCeJ5Vj 4nZ3BKNlzLPnoga6oblpGNw= =n/gU -----END PGP SIGNATURE----- From jgarzik@pobox.com Fri Jul 9 12:19:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 12:19:37 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69JJVgi007106 for ; Fri, 9 Jul 2004 12:19:32 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bj0uA-00025R-HP; Fri, 09 Jul 2004 20:19:30 +0100 Message-ID: <40EEEFB6.9050302@pobox.com> Date: Fri, 09 Jul 2004 15:19:18 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: netdev@oss.sgi.com Subject: Re: [PATCH] fix compiler warnings in mv64340_eth References: <20040706105215.GA14731@lst.de> <40EB853E.5000504@pobox.com> <20040707151610.GA14330@lst.de> In-Reply-To: <20040707151610.GA14330@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From davem@redhat.com Fri Jul 9 12:36:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 12:36:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69Jargi010234 for ; Fri, 9 Jul 2004 12:36:53 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69Jaie1013222; Fri, 9 Jul 2004 15:36:44 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69Jai030738; Fri, 9 Jul 2004 15:36:44 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69JaDvV003969; Fri, 9 Jul 2004 15:36:13 -0400 Date: Fri, 9 Jul 2004 12:36:08 -0700 From: "David S. Miller" To: James Morris Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-Id: <20040709123608.1f9f9265.davem@redhat.com> In-Reply-To: References: <20040709081443.GA11101@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 867 Lines: 21 On Fri, 9 Jul 2004 10:02:25 -0400 (EDT) James Morris wrote: > On Fri, 9 Jul 2004, Herbert Xu wrote: > > > On Thu, Jul 08, 2004 at 02:02:35PM +1000, herbert wrote: > > > > > > That's only because the dst->output() functions are calling > > > skb_checksum_help(). Since those same functions assume the > > > skb to be "uncloned" anyway (they modify it directly by adding > > > headers etc.), they only need to call a version of > > > skb_checksum_help() that does not do a copy of the skb. > > > > If there are no objections, I'd like to create a version of > > skb_checksum_help() that doesn't copy the packet, and call > > that version from ah_output()/esp_output()/ipcomp_output(). > > This will break when cloned packets are passed to these functions. James is right Herbert. TCP will send clones down into these routines all the time. From herbert@gondor.apana.org.au Fri Jul 9 13:43:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 13:43:08 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69Kgegi011486 for ; Fri, 9 Jul 2004 13:43:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bj2CX-0004bh-00; Sat, 10 Jul 2004 06:42:33 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bj2CS-0000o0-00; Sat, 10 Jul 2004 06:42:28 +1000 Date: Sat, 10 Jul 2004 06:42:28 +1000 To: "David S. Miller" Cc: James Morris , netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040709204228.GA3015@gondor.apana.org.au> References: <20040709081443.GA11101@gondor.apana.org.au> <20040709123608.1f9f9265.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040709123608.1f9f9265.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1316 Lines: 32 On Fri, Jul 09, 2004 at 12:36:08PM -0700, David S. Miller wrote: > > > > If there are no objections, I'd like to create a version of > > > skb_checksum_help() that doesn't copy the packet, and call > > > that version from ah_output()/esp_output()/ipcomp_output(). > > > > This will break when cloned packets are passed to these functions. > > James is right Herbert. TCP will send clones down into these routines > all the time. The first TCP transmission will always be a clone of a packet off its output queue. However, the TCP code is written such that you can modify any part of the skb except the TCP payload. This includes the TCP header which is where the TCP checksum is. If this weren't the case then you'd have to copy the packet much earlier. This assumption is already made by tcp_transmit_skb(), ip_queue_xmit() and all the functions called by dst_output(). When TCP retransmits the packet, it will do a pskb_copy() on it so it's no longer a clone. So unless I've missed another case where someone will pass a clone down, it is safe to change the checksum on the TCP clones. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From garzik@havoc.gtf.org Fri Jul 9 13:56:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 13:56:19 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69Ktlgi012069 for ; Fri, 9 Jul 2004 13:56:07 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id F36847630 for ; Fri, 9 Jul 2004 16:14:30 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i69KEUq5022669 for netdev@oss.sgi.com; Fri, 9 Jul 2004 16:14:30 -0400 Date: Fri, 9 Jul 2004 16:14:30 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x net driver updates Message-ID: <20040709201430.GA22656@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i69Ktlgi012069 X-archive-position: 6864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1428 Lines: 52 Just emailed this to Andrew and Linus... Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/epic100.c | 426 ++++++++----- drivers/net/forcedeth.c | 848 +++++++++++++++++++------- drivers/net/natsemi.c | 1064 +++++++++++++++++++++++++-------- drivers/net/pci-skeleton.c | 27 drivers/net/sis900.c | 21 drivers/net/sk98lin/h/skdrv1st.h | 1 drivers/net/wireless/prism54/oid_mgt.c | 10 include/linux/pci_ids.h | 13 8 files changed, 1761 insertions(+), 649 deletions(-) through these ChangeSets: Daniele Venzano: o sis900-fix-phy-transceiver-detection.patch François Romieu: o epic100: code removal in irq handler o epic100: spin_unlock_irqrestore avoidance o [netdrvr epic100] napi fixes o [netdrvr epic100] napi 3/3 - transmit path o [netdrvr epic100] napi 2/3 - receive path o [netdrvr epic100] napi 1/3 - just shuffle some code around o [netdrvr epic100] minor cleanups Manfred Spraul: o Gigabit Ethernet support for forcedeth o natsemi 2: support packets > 1518 bytes o natsemi 1: switch to netdev_priv() o natsemi updates Margit Schubert-While: o prism54 freq to channel incorrect for 5GHz Pavel Roskin: o [netdrvr pci-skeleton] refresh Rusty Russell: o [TRIVIAL 2.6] sk98lin: kill dup include From herbert@gondor.apana.org.au Fri Jul 9 14:07:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 14:07:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69L7Cgi012539 for ; Fri, 9 Jul 2004 14:07:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bj2aH-0004rX-00; Sat, 10 Jul 2004 07:07:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bj2aD-0000rM-00; Sat, 10 Jul 2004 07:07:01 +1000 Date: Sat, 10 Jul 2004 07:07:01 +1000 To: "David S. Miller" Cc: James Morris , netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040709210701.GA3281@gondor.apana.org.au> References: <20040709081443.GA11101@gondor.apana.org.au> <20040709123608.1f9f9265.davem@redhat.com> <20040709204228.GA3015@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040709204228.GA3015@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 830 Lines: 22 On Sat, Jul 10, 2004 at 06:42:28AM +1000, herbert wrote: > > So unless I've missed another case where someone will pass a clone > down, it is safe to change the checksum on the TCP clones. Please note that even if you decide at the API-level that it is not OK for dst->output() functions to modify anything beyond the IP headers, we still don't need to copy the entire skb. Since it's already a clone anyway, skb_cow() suffices to allow changing the checksum. Is there a situation where someone will pass a shared (not cloned) skb down on the netfilter path? If not, then we can do skb_cow() there as well. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ahu@outpost.ds9a.nl Fri Jul 9 14:08:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 14:08:51 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69L8Igi012649 for ; Fri, 9 Jul 2004 14:08:39 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8BAC44437; Fri, 9 Jul 2004 22:24:49 +0200 (CEST) Date: Fri, 9 Jul 2004 22:24:49 +0200 From: bert hubert To: Redeeman Cc: "David S. Miller" , Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, LKML Mailinglist , ALESSANDRO.SUARDI@ORACLE.COM Subject: Re: preliminary conclusions regarding window size issues Message-ID: <20040709202449.GA21348@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Redeeman , "David S. Miller" , Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, LKML Mailinglist , ALESSANDRO.SUARDI@ORACLE.COM References: <20040707232757.GA14471@outpost.ds9a.nl> <1089323824.27085.6.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089323824.27085.6.camel@localhost> User-Agent: Mutt/1.3.28i X-archive-position: 6866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 932 Lines: 21 On Thu, Jul 08, 2004 at 11:57:04PM +0200, Redeeman wrote: > hey bert, a little update on things. > for 2 days ago, when we chatted on irc first, i could reach lkml.org, > however, i had played abit with various settings.. i cant get that > working now, neither can i get tcpdump to give me info.... This has been resolved as an IPv6 routing issue - lkml.org also has an AAAA record but Redeeman's IPv6 is not fully functional. Regarding the packages.gentoo.org kernel, 'NQWOLK' has been coined :-) Alessandro, shall we try the MSS clamp route to further determine what is going on? With packages.gentoo.org the TCP behaviour confirmed that a 'smart firewall' was to blame and not something that stamped over the wscale, perhaps we can narrow down your problem as well. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From davem@redhat.com Fri Jul 9 14:22:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 14:22:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69LMVgi013447 for ; Fri, 9 Jul 2004 14:22:52 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69LMMe1006497; Fri, 9 Jul 2004 17:22:22 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69LMM031518; Fri, 9 Jul 2004 17:22:22 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69LLpYI017157; Fri, 9 Jul 2004 17:21:51 -0400 Date: Fri, 9 Jul 2004 14:21:44 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-Id: <20040709142144.483369ec.davem@redhat.com> In-Reply-To: <20040709204228.GA3015@gondor.apana.org.au> References: <20040709081443.GA11101@gondor.apana.org.au> <20040709123608.1f9f9265.davem@redhat.com> <20040709204228.GA3015@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 2268 Lines: 56 On Sat, 10 Jul 2004 06:42:28 +1000 Herbert Xu wrote: > On Fri, Jul 09, 2004 at 12:36:08PM -0700, David S. Miller wrote: > > > > > > If there are no objections, I'd like to create a version of > > > > skb_checksum_help() that doesn't copy the packet, and call > > > > that version from ah_output()/esp_output()/ipcomp_output(). > > > > > > This will break when cloned packets are passed to these functions. > > > > James is right Herbert. TCP will send clones down into these routines > > all the time. > > The first TCP transmission will always be a clone of a packet off > its output queue. However, the TCP code is written such that you > can modify any part of the skb except the TCP payload. This > includes the TCP header which is where the TCP checksum is. > > If this weren't the case then you'd have to copy the packet much earlier. > This assumption is already made by tcp_transmit_skb(), ip_queue_xmit() > and all the functions called by dst_output(). > > When TCP retransmits the packet, it will do a pskb_copy() on it so > it's no longer a clone. Not necessarily true. If the device has finished transmission, which is true %99.9999 of the time when a retransmission happens, another clone will be made against the original SKB sitting in the write queue. > So unless I've missed another case where someone will pass a clone > down, it is safe to change the checksum on the TCP clones. The hw checksumming state is what we care about. And skb_cow()'s implementation is: 1) Always copy all data if cloned 2) Allocate a unique data area, and even the shared private skb area becomes local to the skb. In short only the data is uncloned. However, skb_checksum_help() is doing something entirely different. It makes a fully new skb, both data and sk_buff struct are uncloned. This is particularly important for the very case which ah_output() cares about, for example. If the skb is CHECKSUM_HW we have to unclone the full SKB. ah_output() does not use things like skb_cow() like ESP and others do. I really think the dst->output() SKB pointer passing is truly needed. You still won't be convinced, I know :-) So propose a patch and we'll shoot holes in it so we can discuss something concrete, ok? :))) From herbert@gondor.apana.org.au Fri Jul 9 14:43:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 14:43:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69LhLgi013998 for ; Fri, 9 Jul 2004 14:43:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bj39G-0005JN-00; Sat, 10 Jul 2004 07:43:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bj39C-0000ut-00; Sat, 10 Jul 2004 07:43:10 +1000 Date: Sat, 10 Jul 2004 07:43:10 +1000 To: "David S. Miller" Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: pskb change in dst->output Message-ID: <20040709214310.GA3474@gondor.apana.org.au> References: <20040709081443.GA11101@gondor.apana.org.au> <20040709123608.1f9f9265.davem@redhat.com> <20040709204228.GA3015@gondor.apana.org.au> <20040709142144.483369ec.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040709142144.483369ec.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2232 Lines: 59 On Fri, Jul 09, 2004 at 02:21:44PM -0700, David S. Miller wrote: > > > When TCP retransmits the packet, it will do a pskb_copy() on it so > > it's no longer a clone. > > Not necessarily true. If the device has finished transmission, > which is true %99.9999 of the time when a retransmission happens, > another clone will be made against the original SKB sitting in > the write queue. You're right. But that case is identical to the clone during the initial transmission. > The hw checksumming state is what we care about. And skb_cow()'s implementation > is: > > 1) Always copy all data if cloned > > 2) Allocate a unique data area, and even the shared private skb > area becomes local to the skb. > > In short only the data is uncloned. > > However, skb_checksum_help() is doing something entirely different. > It makes a fully new skb, both data and sk_buff struct are uncloned. I completely agree with these facts. > This is particularly important for the very case which ah_output() > cares about, for example. If the skb is CHECKSUM_HW we have to unclone > the full SKB. ah_output() does not use things like skb_cow() like > ESP and others do. > > I really think the dst->output() SKB pointer passing is truly needed. That's where we disagree. The very first thing ah_output() does after the *conditional* skb_checksum_help() call is skb_push(). This cannot be done on a shared skb. Therefore the skb must be totally private or at most cloned. This is the fundamental reason why there is no need to make a completely new skb because we already have (or assume to have) exlucsive access to the fields in the sk_buff struct. Now whether we need to unclone the data or not is a different question. My opinion is that we don't, but I'm not to fussed over that. > You still won't be convinced, I know :-) So propose a patch and we'll > shoot holes in it so we can discuss something concrete, ok? :))) OK, that's what I'll do once I finish working on the IPv4 IPsec encapsulation stuff. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jketreno@linux.jf.intel.com Fri Jul 9 14:44:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 14:44:28 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69LiOgi014140 for ; Fri, 9 Jul 2004 14:44:24 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i69Lkc0K015564 for ; Fri, 9 Jul 2004 21:46:38 GMT Received: from linux.jf.intel.com (vpnfm001-114-dhcp-client.fm.intel.com [10.19.13.114]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with ESMTP id i69Lf2xw030611 for ; Fri, 9 Jul 2004 21:41:03 GMT Message-ID: <40EF11AE.9020008@linux.jf.intel.com> Date: Fri, 09 Jul 2004 16:44:14 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: Limiting frame re-encryption with TCP retries... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 6869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.jf.intel.com Precedence: bulk X-list: netdev Content-Length: 1521 Lines: 32 The recent 'pskb change in dst-output' thread reminded me that I've been meaning to ask about this... With wireless drivers TCP retransmission occur pretty frequently. With WEP, etc. this means the driver has to re-encrypt the same frame with each retry. In one of the snapshots for ipw2100 I was encrypting over the SKB provided from the kernel via the xmit and putting new data at the head and tail (to hold the IV and ICV). Anyway, that broke all sorts of tools (ip_conntrack, netfilter, etc.) So now I allocate a new SKB on reception of an SKB from the networking stack and encrypt the copy. The question I have -- is there a way to attach the new SKB to the old one such that if the transmit is retried I can check that data and don't have to re-encrypt it? From the sk_buff.h description of the cb field, I only get to use that data while I control the SKB. Even if this weren't the case it wouldn't quite do what I need. Ideally I want to be able to attach the encrypted SKB to the original SKB such that when the network stack gets the ACK it can nuke the original SKB and the encrypted one and the driver doesn't have to know. This gets complicated further when 802.11 level fragmentation is required -- and one incoming SKB results in N outbound 802.11 fragments, each encrypted separately. Any ideas? I'm not too familiar with the internals of the kernel's network stack so if there is something obvious that I should have seen already, please point it out to me :) Thanks, James From sam@errno.com Fri Jul 9 15:32:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 15:32:44 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69MWggi015360 for ; Fri, 9 Jul 2004 15:32:42 -0700 Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i69MWYWi041309 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 9 Jul 2004 15:32:35 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Vladimir Kondratiev Subject: Re: ethernet QoS support? Date: Fri, 9 Jul 2004 15:34:53 -0700 User-Agent: KMail/1.6.1 Cc: netdev@oss.sgi.com, hadi@cyberus.ca, Jeff Garzik , Kumar Gala References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <1089383622.1030.21.camel@jzny.localdomain> <200407092126.43021.vkondra@mail.ru> In-Reply-To: <200407092126.43021.vkondra@mail.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407091534.53166.sam@errno.com> X-archive-position: 6870 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 1385 Lines: 29 On Friday 09 July 2004 11:26 am, Vladimir Kondratiev wrote: > > So what do you do now? > > Waiting. If no support will exist, it simply means we will be unable to use > QoS provided by modern 802.11. Depending on market development, impact may > range from being slightly slower relating to Windows clients, to being > almost completely unable to communicate for traffic like VOIP. Later will > be the case if most access points will implement QoS as in TGE. > > I can now deliver packets accordingly to skb->priority, but if stack have > different idea for what is proper proportion between different sorts of > traffic, driver's Tx path will be flooded with low priority frames. > > Situation is much worser for streams with admission control. I have no > mechanism to communicate with stack for such traffic establishment and tear > down. FWIW the madwifi net80211 layer parses TOS to calculate priority and sticks it in the skb. It also calculates the WME AC to form the QoS frame matter. This is then handed to drivers below. The Atheros driver supports multiple tx queues in h/w with appropriate scheduling (for 5212 MACs); it uses the AC to set packets on the appropriate queue. Clearly it'd be better if upper layers did the TOS stuff. Whatever is done however should consider the case where the driver (nee h/w) has it's own queueing/scheduling facilities. Sam From davem@redhat.com Fri Jul 9 16:14:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 16:14:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69NENgi016498 for ; Fri, 9 Jul 2004 16:14:43 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69NEEe1031922; Fri, 9 Jul 2004 19:14:14 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69NEE027946; Fri, 9 Jul 2004 19:14:14 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69NDgHk027696; Fri, 9 Jul 2004 19:13:43 -0400 Date: Fri, 9 Jul 2004 16:14:12 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: ahu@ds9a.nl, jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tcp_default_win_scale. Message-Id: <20040709161412.4fee5b04.davem@redhat.com> In-Reply-To: <20040707110653.7c49bef1@dell_ss3.pdx.osdl.net> References: <20040629222751.392f0a82.davem@redhat.com> <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net> <20040630153049.3ca25b76.davem@redhat.com> <20040701133738.301b9e46@dell_ss3.pdx.osdl.net> <20040701140406.62dfbc2a.davem@redhat.com> <20040702013225.GA24707@conectiva.com.br> <20040706093503.GA8147@outpost.ds9a.nl> <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net> <20040706194034.GA11021@mail.shareable.org> <20040706131235.10b5afa8.davem@redhat.com> <20040706224453.GA6694@outpost.ds9a.nl> <20040706154907.422a6b73.davem@redhat.com> <20040707110653.7c49bef1@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 780 Lines: 19 On Wed, 7 Jul 2004 11:06:53 -0700 Stephen Hemminger wrote: > But: isn't it better to have just one sysctl parameter set (tcp_rmem) > and set the window scale as needed rather than increasing the already > bewildering array of dials and knobs? I can't see why it would be advantageous > to set a window scale of 7 if the largest possible window ever offered > is limited to a smaller value? Stephen, here is what is going to happen if we apply your patch. The default window scale will be 2, which is under the value which starts to cause the problems which is 3. So things will silently work, and most people will not notice the problem. I'd much rather bugs scream out saying "I'm a bug fix me!" than to just silently linger around mostly unnoticed. From davem@redhat.com Fri Jul 9 16:16:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 16:16:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69NFxgi016680 for ; Fri, 9 Jul 2004 16:16:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69NFse1032363; Fri, 9 Jul 2004 19:15:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69NFs028330; Fri, 9 Jul 2004 19:15:54 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69NFNP6028086; Fri, 9 Jul 2004 19:15:23 -0400 Date: Fri, 9 Jul 2004 16:15:52 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] mark CSZ scheduler as broken Message-Id: <20040709161552.3785869a.davem@redhat.com> In-Reply-To: <20040707165628.02246aaf@dell_ss3.pdx.osdl.net> References: <20040707111936.760586b0@dell_ss3.pdx.osdl.net> <20040707152803.6e2a7336.davem@redhat.com> <20040707165628.02246aaf@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 410 Lines: 11 On Wed, 7 Jul 2004 16:56:28 -0700 Stephen Hemminger wrote: > It builds fine and obeys all the conventions, so it isn't really BROKEN like > other drivers. But do we really want to keep it in the tree at all? The code to > set it up isn't in the any version of 'tc' I saw (only stubs). Ok, I've been thinking about this a bit and we can just kill it from the 2.6.x tree. I'll do that. From davem@redhat.com Fri Jul 9 16:45:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 16:46:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69Njbgi023234 for ; Fri, 9 Jul 2004 16:45:57 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69NjYe1005751; Fri, 9 Jul 2004 19:45:34 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69NjY002421; Fri, 9 Jul 2004 19:45:34 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69Nj3Il002383; Fri, 9 Jul 2004 19:45:03 -0400 Date: Fri, 9 Jul 2004 16:45:32 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] bridge -- support different MTU sizes Message-Id: <20040709164532.22202ce2.davem@redhat.com> In-Reply-To: <20040708104143.67210e39@dell_ss3.pdx.osdl.net> References: <20040708104143.67210e39@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 486 Lines: 12 On Thu, 8 Jul 2004 10:41:43 -0700 Stephen Hemminger wrote: > This patch adds support for different size MTU's to bridging. > It is useful for bridging Ethernet's with jumbo frames, etc. > > The mtu of the bridge pseudo-device is maintained as the minimum > of all the underlying ports. And when forwarding a frame through > the bridge, it will drop the frame if the outgoing port's MTU > is less than the frame size (as per 802 standard). Looks fine, applied. From davem@redhat.com Fri Jul 9 16:49:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 16:49:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69NnUgi023544 for ; Fri, 9 Jul 2004 16:49:50 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69NnQe1006586; Fri, 9 Jul 2004 19:49:26 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69NnQ002981; Fri, 9 Jul 2004 19:49:26 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69Nmtxf003128; Fri, 9 Jul 2004 19:48:55 -0400 Date: Fri, 9 Jul 2004 16:49:24 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [RFC] netem - add jitter support. Message-Id: <20040709164924.46ac719b.davem@redhat.com> In-Reply-To: <1089335650.1046.150.camel@jzny.localdomain> References: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> <1089335650.1046.150.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 447 Lines: 13 On 08 Jul 2004 21:14:10 -0400 jamal wrote: > - Is that NIST code/reference ok to put there? I have a feeling its > non-free. The Nist NET homepage states: As a U.S. government publication, so to speak, NIST Net is not copyrighted. You can do whatever you want with it, including employing its code in whole or in part in any other package or product. You need not credit me or NIST (though not doing so would be a bit rude). From davem@redhat.com Fri Jul 9 16:53:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 16:53:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69NrJgi023877 for ; Fri, 9 Jul 2004 16:53:39 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69NrHe1007368; Fri, 9 Jul 2004 19:53:17 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69NrH003495; Fri, 9 Jul 2004 19:53:17 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69NqkKZ003633; Fri, 9 Jul 2004 19:52:46 -0400 Date: Fri, 9 Jul 2004 16:53:14 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [RFC] netem - add jitter support. Message-Id: <20040709165314.485cdc52.davem@redhat.com> In-Reply-To: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> References: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 549 Lines: 16 On Thu, 8 Jul 2004 13:53:20 -0700 Stephen Hemminger wrote: > This patch adds jitter if desired to the delayed packets in the > netem scheduler. I dropped the rate stuff out and reorganized so > that an underlying pfifo queue is used (next plan is to make it > have class ops). > > The jitter is given as sigma to a Gaussian normal distribution. The actual > implementation is a reduced form of the table driven stuff in NISTnet > (free). I'm going to apply this. Stephen please send me a 2.4.x version as well. Thanks. From davem@redhat.com Fri Jul 9 16:59:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 16:59:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69Nwlgi024232 for ; Fri, 9 Jul 2004 16:59:07 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69Nwfe1008343; Fri, 9 Jul 2004 19:58:41 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69Nwf004574; Fri, 9 Jul 2004 19:58:41 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69Nw90O004879; Fri, 9 Jul 2004 19:58:09 -0400 Date: Fri, 9 Jul 2004 16:58:38 -0700 From: "David S. Miller" To: James Morris Cc: akpm@osdl.org, niv@us.ibm.com, jmorris@intercode.com.au, netdev@oss.sgi.com, christophe@saout.de, mjbligh@us.ibm.com Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] Message-Id: <20040709165838.5f7058f0.davem@redhat.com> In-Reply-To: References: <20040702143949.21a50b74.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 522 Lines: 17 On Fri, 9 Jul 2004 00:20:56 -0400 (EDT) James Morris wrote: > On Fri, 2 Jul 2004, Andrew Morton wrote: > > > Well no. Those games with deflate_gfp() really need to go away. > > in_atomic() works OK if CONFIG_PREEMPT is enabled. But with > > CONFIG_PREEMPT=n, in_atomic() returns false inside spinlock. And > > in_atomic()'s return value is unaffected by local_irq_disable(). > > > > This all needs to be redesigned, sorry. > > Ok, fixed. Lazy allocation is gone. > > Please apply. Applied. From davem@redhat.com Fri Jul 9 17:00:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 17:00:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i69Nxsgi024317 for ; Fri, 9 Jul 2004 17:00:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i69Nxje1008534; Fri, 9 Jul 2004 19:59:45 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i69Nxj004773; Fri, 9 Jul 2004 19:59:45 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i69NxEJU005334; Fri, 9 Jul 2004 19:59:15 -0400 Date: Fri, 9 Jul 2004 16:59:43 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [XFRM] Add FLUSHSA and FLUSHPOLICY Message-Id: <20040709165943.32c396ff.davem@redhat.com> In-Reply-To: <20040709101327.GA12291@gondor.apana.org.au> References: <20040709101327.GA12291@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 339 Lines: 10 On Fri, 9 Jul 2004 20:13:27 +1000 Herbert Xu wrote: > This patch adds FLUSHSA and FLUSHPOLICY to xfrm_user which are > analagous to SADB_FLUSH and SADB_X_SPDFLUSH in af_key. > > This is useful in KMs on startup/shutdown so that the system is > reset to a known state. Looks good. Applied, thanks Herbert. From davem@redhat.com Fri Jul 9 17:05:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 17:05:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A05Agi024916 for ; Fri, 9 Jul 2004 17:05:30 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6A055e1009735; Fri, 9 Jul 2004 20:05:05 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6A055006287; Fri, 9 Jul 2004 20:05:05 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6A04Ytj006722; Fri, 9 Jul 2004 20:04:34 -0400 Date: Fri, 9 Jul 2004 17:05:02 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NATT] Fix uh->len with IP options Message-Id: <20040709170502.58a05039.davem@redhat.com> In-Reply-To: <20040709114802.GA13344@gondor.apana.org.au> References: <20040709114802.GA13344@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 389 Lines: 11 On Fri, 9 Jul 2004 21:48:02 +1000 Herbert Xu wrote: > I just noticed that the UDP header length in esp4_output() is incorrect > when IP options are present (in transport mode). This patch fixes exactly > that. At first I thought you should be using top_iph to compute the options length, but now I see why it's correct to be using 'iph'. Applied, thanks. From herbert@gondor.apana.org.au Fri Jul 9 17:52:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 17:53:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A0qkgi026101 for ; Fri, 9 Jul 2004 17:52:48 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bj65o-0006gW-00; Sat, 10 Jul 2004 10:51:52 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bj65i-0002sl-00; Sat, 10 Jul 2004 10:51:46 +1000 Date: Sat, 10 Jul 2004 10:51:46 +1000 To: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: [IPSEC] Move generic encap code into xfrm4_output Message-ID: <20040710005146.GA11023@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 16842 Lines: 610 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: I've finally finished merging the general encapsulation code for IPv4. Here is the patch. The idea is basically to make x->type->output similar in structure to x->type->input. That means moving the tunnel encapsulation and other generic code out. They have ended up in xfrm4_output.c. The advantage of this is that we have exactly one copy of the tunnel encapsulation code. So if we need to change it (e.g., set the TTL according to the route) then it's easier and less error-prone. In fact, in doing so I've already noticed that the ECN wasn't being copied correctly in everything except xfrm4_tunnel. Signed-off-by: Herbert Xu BTW, the ECN encapsulation stuff needs to be updated wrt RFC 3168. I'll send in a patch later. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff -Nru a/include/net/xfrm.h b/include/net/xfrm.h --- a/include/net/xfrm.h 2004-07-10 10:43:34 +10:00 +++ b/include/net/xfrm.h 2004-07-10 10:43:34 +10:00 @@ -818,6 +818,7 @@ extern int xfrm_check_selectors(struct xfrm_state **x, int n, struct flowi *fl); extern int xfrm_state_check(struct xfrm_state *x, struct sk_buff *skb); extern int xfrm4_rcv(struct sk_buff *skb); +extern int xfrm4_output(struct sk_buff **pskb); extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_check_size(struct sk_buff *skb); diff -Nru a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2004-07-10 10:43:34 +10:00 +++ b/net/ipv4/Makefile 2004-07-10 10:43:34 +10:00 @@ -23,4 +23,5 @@ obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ -obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o xfrm4_tunnel.o +obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ + xfrm4_tunnel.o xfrm4_output.o diff -Nru a/net/ipv4/ah4.c b/net/ipv4/ah4.c --- a/net/ipv4/ah4.c 2004-07-10 10:43:34 +10:00 +++ b/net/ipv4/ah4.c 2004-07-10 10:43:34 +10:00 @@ -67,52 +67,24 @@ char buf[60]; } tmp_iph; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } + top_iph = (*pskb)->nh.iph; + iph = &tmp_iph.iph; - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - iph = (*pskb)->nh.iph; - if (x->props.mode) { - err = xfrm4_tunnel_check_size(*pskb); + iph->tos = top_iph->tos; + iph->ttl = top_iph->ttl; + iph->frag_off = top_iph->frag_off; + iph->daddr = top_iph->daddr; + + if (top_iph->ihl != 5) { + memcpy(iph+1, top_iph+1, top_iph->ihl*4 - sizeof(struct iphdr)); + err = ip_clear_mutable_options(top_iph, &top_iph->daddr); if (err) goto error; - top_iph = (struct iphdr*)skb_push(*pskb, x->props.header_len); - top_iph->ihl = 5; - top_iph->version = 4; - top_iph->tos = iph->tos; - if (x->props.flags & XFRM_STATE_NOECN) - IP_ECN_clear(top_iph); - top_iph->frag_off = iph->frag_off & ~htons(IP_MF|IP_OFFSET); - if (!(iph->frag_off&htons(IP_DF))) - __ip_select_ident(top_iph, dst, 0); - top_iph->ttl = iph->ttl; - top_iph->saddr = x->props.saddr.a4; - top_iph->daddr = x->id.daddr.a4; - memcpy(&tmp_iph, top_iph, 20); - memset(&(IPCB(*pskb)->opt), 0, sizeof(struct ip_options)); - ah = (struct ip_auth_hdr*)(top_iph+1); - ah->nexthdr = IPPROTO_IPIP; - } else { - memcpy(&tmp_iph, (*pskb)->data, iph->ihl*4); - top_iph = (struct iphdr*)skb_push(*pskb, x->props.header_len); - memcpy(top_iph, &tmp_iph, iph->ihl*4); - if (top_iph->ihl != 5) { - err = ip_clear_mutable_options(top_iph, &top_iph->daddr); - if (err) - goto error; - } - ah = (struct ip_auth_hdr*)((char*)top_iph+iph->ihl*4); - ah->nexthdr = iph->protocol; } - iph = &tmp_iph.iph; + ah = (struct ip_auth_hdr *)((char *)top_iph+top_iph->ihl*4); + ah->nexthdr = top_iph->protocol; + top_iph->tos = 0; top_iph->tot_len = htons((*pskb)->len); top_iph->frag_off = 0; @@ -128,31 +100,19 @@ ah->spi = x->id.spi; ah->seq_no = htonl(++x->replay.oseq); ahp->icv(ahp, *pskb, ah->auth_data); + top_iph->tos = iph->tos; top_iph->ttl = iph->ttl; top_iph->frag_off = iph->frag_off; - if (!x->props.mode) { - top_iph->daddr = iph->daddr; - if (iph->ihl != 5) - memcpy(top_iph+1, iph+1, iph->ihl*4 - sizeof(struct iphdr)); - } - ip_send_check(top_iph); + top_iph->daddr = iph->daddr; + if (top_iph->ihl != 5) + memcpy(top_iph+1, iph+1, top_iph->ihl*4 - sizeof(struct iphdr)); - (*pskb)->nh.raw = (*pskb)->data; + ip_send_check(top_iph); - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + err = 0; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } diff -Nru a/net/ipv4/esp4.c b/net/ipv4/esp4.c --- a/net/ipv4/esp4.c 2004-07-10 10:43:34 +10:00 +++ b/net/ipv4/esp4.c 2004-07-10 10:43:34 +10:00 @@ -23,7 +23,7 @@ int err; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct iphdr *iph, *top_iph; + struct iphdr *top_iph; struct ip_esp_hdr *esph; struct crypto_tfm *tfm; struct esp_data *esp; @@ -32,32 +32,9 @@ int clen; int alen; int nfrags; - union { - struct iphdr iph; - char buf[60]; - } tmp_iph; - - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - if (x->props.mode) { - err = xfrm4_tunnel_check_size(*pskb); - if (err) - goto error; - } else { - /* Strip IP header in transport mode. Save it. */ - iph = (*pskb)->nh.iph; - memcpy(&tmp_iph, iph, iph->ihl*4); - __skb_pull(*pskb, iph->ihl*4); - } + /* Strip IP+ESP header. */ + __skb_pull(*pskb, (*pskb)->h.raw - (*pskb)->data); /* Now skb is pure payload to encrypt */ err = -ENOMEM; @@ -85,35 +62,11 @@ *(u8*)(trailer->tail + clen-(*pskb)->len - 2) = (clen - (*pskb)->len)-2; pskb_put(*pskb, trailer, clen - (*pskb)->len); - iph = (*pskb)->nh.iph; - if (x->props.mode) { - top_iph = (struct iphdr*)skb_push(*pskb, x->props.header_len); - esph = (struct ip_esp_hdr*)(top_iph+1); - *(u8*)(trailer->tail - 1) = IPPROTO_IPIP; - top_iph->ihl = 5; - top_iph->version = 4; - top_iph->tos = iph->tos; /* DS disclosed */ - if (x->props.flags & XFRM_STATE_NOECN) - IP_ECN_clear(top_iph); - top_iph->tot_len = htons((*pskb)->len + alen); - top_iph->frag_off = iph->frag_off&htons(IP_DF); - if (!(top_iph->frag_off)) - ip_select_ident(top_iph, dst, NULL); - top_iph->ttl = iph->ttl; /* TTL disclosed */ - top_iph->check = 0; - top_iph->saddr = x->props.saddr.a4; - top_iph->daddr = x->id.daddr.a4; - memset(&(IPCB(*pskb)->opt), 0, sizeof(struct ip_options)); - } else { - esph = (struct ip_esp_hdr*)skb_push(*pskb, x->props.header_len); - top_iph = (struct iphdr*)skb_push(*pskb, iph->ihl*4); - memcpy(top_iph, &tmp_iph, iph->ihl*4); - iph = &tmp_iph.iph; - top_iph->tot_len = htons((*pskb)->len + alen); - top_iph->check = 0; - top_iph->frag_off = iph->frag_off; - *(u8*)(trailer->tail - 1) = iph->protocol; - } + __skb_push(*pskb, (*pskb)->data - (*pskb)->nh.raw); + top_iph = (*pskb)->nh.iph; + esph = (struct ip_esp_hdr *)((*pskb)->nh.raw + top_iph->ihl*4); + top_iph->tot_len = htons((*pskb)->len + alen); + *(u8*)(trailer->tail - 1) = top_iph->protocol; /* this is non-NULL only with UDP Encapsulation */ if (x->encap) { @@ -124,7 +77,7 @@ uh = (struct udphdr *)esph; uh->source = encap->encap_sport; uh->dest = encap->encap_dport; - uh->len = htons((*pskb)->len + alen - iph->ihl*4); + uh->len = htons((*pskb)->len + alen - top_iph->ihl*4); uh->check = 0; switch (encap->encap_type) { @@ -176,21 +129,9 @@ ip_send_check(top_iph); - (*pskb)->nh.raw = (*pskb)->data; - - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + err = 0; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } diff -Nru a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c --- a/net/ipv4/ipcomp.c 2004-07-10 10:43:34 +10:00 +++ b/net/ipv4/ipcomp.c 2004-07-10 10:43:34 +10:00 @@ -121,28 +121,6 @@ return err; } -static void ipcomp_tunnel_encap(struct xfrm_state *x, struct sk_buff *skb) -{ - struct dst_entry *dst = skb->dst; - struct iphdr *iph, *top_iph; - - iph = skb->nh.iph; - top_iph = (struct iphdr *)skb_push(skb, sizeof(struct iphdr)); - top_iph->ihl = 5; - top_iph->version = 4; - top_iph->tos = iph->tos; - top_iph->tot_len = htons(skb->len); - if (!(iph->frag_off&htons(IP_DF))) - __ip_select_ident(top_iph, dst, 0); - top_iph->ttl = iph->ttl; - top_iph->check = 0; - top_iph->saddr = x->props.saddr.a4; - top_iph->daddr = x->id.daddr.a4; - top_iph->frag_off = iph->frag_off&~htons(IP_MF|IP_OFFSET); - memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->nh.raw = skb->data; -} - static int ipcomp_output(struct sk_buff **pskb) { int err; @@ -153,39 +131,17 @@ struct ipcomp_data *ipcd = x->data; int hdr_len = 0; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm4_tunnel_check_size(*pskb); - if (err) - goto error; - } else { - /* Don't bother compressing */ - iph = (*pskb)->nh.iph; - hdr_len = iph->ihl * 4; - } + iph = (*pskb)->nh.iph; + iph->tot_len = htons((*pskb)->len); + hdr_len = iph->ihl * 4; if (((*pskb)->len - hdr_len) < ipcd->threshold) { + /* Don't bother compressing */ if (x->props.mode) { - ipcomp_tunnel_encap(x, *pskb); - iph = (*pskb)->nh.iph; - iph->protocol = IPPROTO_IPIP; ip_send_check(iph); } goto out_ok; } - if (x->props.mode) - ipcomp_tunnel_encap(x, *pskb); - if ((skb_is_nonlinear(*pskb) || skb_cloned(*pskb)) && skb_linearize(*pskb, GFP_ATOMIC) != 0) { err = -ENOMEM; @@ -197,7 +153,6 @@ if (err == -EMSGSIZE) { if (x->props.mode) { iph = (*pskb)->nh.iph; - iph->protocol = IPPROTO_IPIP; ip_send_check(iph); } goto out_ok; @@ -207,36 +162,19 @@ /* Install ipcomp header, convert into ipcomp datagram. */ iph = (*pskb)->nh.iph; - if (x->props.mode && (x->props.flags & XFRM_STATE_NOECN)) - IP_ECN_clear(iph); iph->tot_len = htons((*pskb)->len); - iph->check = 0; ipch = (struct ip_comp_hdr *)((char *)iph + iph->ihl * 4); - ipch->nexthdr = x->props.mode ? IPPROTO_IPIP : iph->protocol; + ipch->nexthdr = iph->protocol; ipch->flags = 0; ipch->cpi = htons((u16 )ntohl(x->id.spi)); iph->protocol = IPPROTO_COMP; ip_send_check(iph); - (*pskb)->nh.raw = (*pskb)->data; out_ok: - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - err = NET_XMIT_BYPASS; + err = 0; -out_exit: - return err; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); - goto out_exit; + return err; } static void ipcomp4_err(struct sk_buff *skb, u32 info) diff -Nru a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/xfrm4_output.c 2004-07-10 10:43:34 +10:00 @@ -0,0 +1,120 @@ +/* + * xfrm4_output.c - Common IPsec encapsulation code for IPv4. + * Copyright (c) 2004 Herbert Xu + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include + +/* Add encapsulation header. + * + * In transport mode, the IP header will be moved forward to make space + * for the encapsulation header. + * + * In tunnel mode, the top IP header will be constructed per RFC 2401. + * The following fields in it shall be filled in by x->type->output: + * tot_len + * check + * + * On exit, skb->h will be set to the start of the payload to be processed + * by x->type->output and skb->nh will be set to the top IP header. + */ +static void xfrm4_encap(struct sk_buff *skb) +{ + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + struct iphdr *iph, *top_iph; + + iph = skb->nh.iph; + skb->h.ipiph = iph; + + skb->nh.raw = skb_push(skb, x->props.header_len); + top_iph = skb->nh.iph; + + if (!x->props.mode) { + skb->h.raw += iph->ihl*4; + memmove(top_iph, iph, iph->ihl*4); + return; + } + + top_iph->ihl = 5; + top_iph->version = 4; + + /* DS disclosed */ + top_iph->tos = INET_ECN_encapsulate(iph->tos, iph->tos); + if (x->props.flags & XFRM_STATE_NOECN) + IP_ECN_clear(top_iph); + + top_iph->frag_off = iph->frag_off & htons(IP_DF); + if (!top_iph->frag_off) + __ip_select_ident(top_iph, dst, 0); + + /* TTL disclosed */ + top_iph->ttl = iph->ttl; + + top_iph->saddr = x->props.saddr.a4; + top_iph->daddr = x->id.daddr.a4; + top_iph->protocol = IPPROTO_IPIP; + + memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); +} + +int xfrm4_output(struct sk_buff **pskb) +{ + struct sk_buff *skb = *pskb; + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + int err; + + if (skb->ip_summed == CHECKSUM_HW) { + err = skb_checksum_help(pskb, 0); + skb = *pskb; + if (err) + goto error_nolock; + } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; + + if (x->props.mode) { + err = xfrm4_tunnel_check_size(skb); + if (err) + goto error; + } + + xfrm4_encap(skb); + + err = x->type->output(pskb); + skb = *pskb; + if (err) + goto error; + + x->curlft.bytes += skb->len; + x->curlft.packets++; + + spin_unlock_bh(&x->lock); + + if (!(skb->dst = dst_pop(dst))) { + err = -EHOSTUNREACH; + goto error_nolock; + } + err = NET_XMIT_BYPASS; + +out_exit: + return err; +error: + spin_unlock_bh(&x->lock); +error_nolock: + kfree_skb(skb); + goto out_exit; +} diff -Nru a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 2004-07-10 10:43:34 +10:00 +++ b/net/ipv4/xfrm4_policy.c 2004-07-10 10:43:34 +10:00 @@ -139,7 +139,7 @@ /* Copy neighbout for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); dst_prev->input = rt->u.dst.input; - dst_prev->output = dst_prev->xfrm->type->output; + dst_prev->output = xfrm4_output; if (rt->peer) atomic_inc(&rt->peer->refcnt); x->u.rt.peer = rt->peer; diff -Nru a/net/ipv4/xfrm4_tunnel.c b/net/ipv4/xfrm4_tunnel.c --- a/net/ipv4/xfrm4_tunnel.c 2004-07-10 10:43:34 +10:00 +++ b/net/ipv4/xfrm4_tunnel.c 2004-07-10 10:43:34 +10:00 @@ -36,52 +36,13 @@ static int ipip_output(struct sk_buff **pskb) { struct sk_buff *skb = *pskb; - struct dst_entry *dst = skb->dst; - struct xfrm_state *x = dst->xfrm; - struct iphdr *iph, *top_iph; - int tos, err; - - if ((err = xfrm4_tunnel_check_size(skb)) != 0) - goto error_nolock; - + struct iphdr *iph; + iph = skb->nh.iph; + iph->tot_len = htons(skb->len); + ip_send_check(iph); - spin_lock_bh(&x->lock); - - tos = iph->tos; - - top_iph = (struct iphdr *) skb_push(skb, x->props.header_len); - top_iph->ihl = 5; - top_iph->version = 4; - top_iph->tos = INET_ECN_encapsulate(tos, iph->tos); - top_iph->tot_len = htons(skb->len); - top_iph->frag_off = iph->frag_off & ~htons(IP_MF|IP_OFFSET); - if (!(iph->frag_off & htons(IP_DF))) - __ip_select_ident(top_iph, dst, 0); - top_iph->ttl = iph->ttl; - top_iph->protocol = IPPROTO_IPIP; - top_iph->check = 0; - top_iph->saddr = x->props.saddr.a4; - top_iph->daddr = x->id.daddr.a4; - memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - ip_send_check(top_iph); - - skb->nh.raw = skb->data; - x->curlft.bytes += skb->len; - x->curlft.packets++; - - spin_unlock_bh(&x->lock); - - if ((skb->dst = dst_pop(dst)) == NULL) { - kfree_skb(skb); - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; - -error_nolock: - kfree_skb(skb); - return err; + return 0; } static int ipip_xfrm_rcv(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb) --/04w6evG8XlLl3ft-- From bunk@fs.tum.de Fri Jul 9 18:17:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 18:17:42 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A1Hagi026850 for ; Fri, 9 Jul 2004 18:17:37 -0700 Received: (qmail 26813 invoked from network); 10 Jul 2004 01:12:00 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 10 Jul 2004 01:12:00 -0000 Date: Sat, 10 Jul 2004 03:17:32 +0200 From: Adrian Bunk To: Trond Myklebust Cc: netdev@oss.sgi.com Subject: [2.6 patch] net/sunrpc/xprt.c: fix inline problem Message-ID: <20040710011732.GY28324@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 6880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Content-Length: 1844 Lines: 79 Trying to compile net/sunrpc/xprt.c with gcc 3.4 and # define inline __inline__ __attribute__((always_inline)) results in the following error: <-- snip --> ... CC net/sunrpc/xprt.o net/sunrpc/xprt.c: In function `xprt_reserve': net/sunrpc/xprt.c:84: sorry, unimplemented: inlining failed in call to 'do_xprt_reserve': function body not available net/sunrpc/xprt.c:1307: sorry, unimplemented: called from here make[2]: *** [net/sunrpc/xprt.o] Error 1 <-- snip --> The patch below moves the inline function in front of its' (only) caller. diffstat output: net/sunrpc/xprt.c | 36 ++++++++++++++++++------------------ 1 files changed, 18 insertions(+), 18 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.7-mm7-full-gcc3.4/net/sunrpc/xprt.c.old 2004-07-10 03:07:17.000000000 +0200 +++ linux-2.6.7-mm7-full-gcc3.4/net/sunrpc/xprt.c 2004-07-10 03:09:36.000000000 +0200 @@ -1293,24 +1293,6 @@ spin_unlock_bh(&xprt->sock_lock); } -/* - * Reserve an RPC call slot. - */ -void -xprt_reserve(struct rpc_task *task) -{ - struct rpc_xprt *xprt = task->tk_xprt; - - task->tk_status = -EIO; - if (!xprt->shutdown) { - spin_lock(&xprt->xprt_lock); - do_xprt_reserve(task); - spin_unlock(&xprt->xprt_lock); - if (task->tk_rqstp) - del_timer_sync(&xprt->timer); - } -} - static inline void do_xprt_reserve(struct rpc_task *task) { @@ -1333,6 +1315,24 @@ } /* + * Reserve an RPC call slot. + */ +void +xprt_reserve(struct rpc_task *task) +{ + struct rpc_xprt *xprt = task->tk_xprt; + + task->tk_status = -EIO; + if (!xprt->shutdown) { + spin_lock(&xprt->xprt_lock); + do_xprt_reserve(task); + spin_unlock(&xprt->xprt_lock); + if (task->tk_rqstp) + del_timer_sync(&xprt->timer); + } +} + +/* * Allocate a 'unique' XID */ static inline u32 xprt_alloc_xid(struct rpc_xprt *xprt) From herbert@gondor.apana.org.au Fri Jul 9 18:22:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 18:22:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A1M2gi027241 for ; Fri, 9 Jul 2004 18:22:04 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bj6Yu-0006ps-00; Sat, 10 Jul 2004 11:21:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bj6Yr-0002vz-00; Sat, 10 Jul 2004 11:21:53 +1000 Date: Sat, 10 Jul 2004 11:21:53 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [NATT] Fix uh->len with IP options Message-ID: <20040710012153.GA11236@gondor.apana.org.au> References: <20040709114802.GA13344@gondor.apana.org.au> <20040709170502.58a05039.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040709170502.58a05039.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 671 Lines: 19 On Fri, Jul 09, 2004 at 05:05:02PM -0700, David S. Miller wrote: > > At first I thought you should be using top_iph to compute the options > length, but now I see why it's correct to be using 'iph'. Mea culpa. This is broken in tunnel mode. My big patch that moves the tunnel code out will fix this since it gets rid of iph altogether. But if you want to hold out on that one for a bit then please make the obvious fix by changing iph to top_iph. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Jul 9 20:32:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 20:32:34 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A3WQgi032746 for ; Fri, 9 Jul 2004 20:32:28 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bj8b0-0007Zz-00; Sat, 10 Jul 2004 13:32:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bj8aw-0003jX-00; Sat, 10 Jul 2004 13:32:10 +1000 Date: Sat, 10 Jul 2004 13:32:09 +1000 To: "David S. Miller" , yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [IPCOMP6] Exclude IPCOMP header from props.header_len Message-ID: <20040710033209.GA14316@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6882 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2062 Lines: 72 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: Now that the IPv4 encap stuff is out of the way, I'll be sending you the IPv6 versions. Here is the one to remove the unnecessary extra space reserved for IPCOMP. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/ipcomp6.c 1.11 vs edited ===== --- 1.11/net/ipv6/ipcomp6.c 2004-06-18 16:20:58 +10:00 +++ edited/net/ipv6/ipcomp6.c 2004-07-10 13:26:45 +10:00 @@ -123,7 +123,7 @@ int err; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *tmp_iph = NULL, *iph, *top_iph; + struct ipv6hdr *iph, *top_iph; int hdr_len = 0; struct ipv6_comp_hdr *ipch; struct ipcomp_data *ipcd = x->data; @@ -193,19 +193,11 @@ if ((dlen + sizeof(struct ipv6_comp_hdr)) >= plen) { goto out_ok; } - memcpy(start, scratch, dlen); - pskb_trim(*pskb, hdr_len+dlen); + memcpy(start + sizeof(struct ip_comp_hdr), scratch, dlen); + pskb_trim(*pskb, hdr_len + dlen + sizeof(struct ip_comp_hdr)); /* insert ipcomp header and replace datagram */ - tmp_iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!tmp_iph) { - err = -ENOMEM; - goto error; - } - memcpy(tmp_iph, (*pskb)->nh.raw, hdr_len); - top_iph = (struct ipv6hdr*)skb_push(*pskb, sizeof(struct ipv6_comp_hdr)); - memcpy(top_iph, tmp_iph, hdr_len); - kfree(tmp_iph); + top_iph = (*pskb)->nh.ipv6h; if (x->props.mode && (x->props.flags & XFRM_STATE_NOECN)) IP6_ECN_clear(top_iph); @@ -358,7 +350,7 @@ goto error; memset(ipcd, 0, sizeof(*ipcd)); - x->props.header_len = sizeof(struct ipv6_comp_hdr); + x->props.header_len = 0; if (x->props.mode) x->props.header_len += sizeof(struct ipv6hdr); --C7zPtVaVf+AK4Oqc-- From yoshfuji@linux-ipv6.org Fri Jul 9 21:36:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 21:37:08 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A4ahgi001561 for ; Fri, 9 Jul 2004 21:36:44 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id B336A33CE5; Sat, 10 Jul 2004 13:36:43 +0900 (JST) Date: Sat, 10 Jul 2004 13:36:41 +0900 (JST) Message-Id: <20040710.133641.132032007.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au, davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [IPCOMP6] Exclude IPCOMP header from props.header_len From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040710033209.GA14316@gondor.apana.org.au> References: <20040710033209.GA14316@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 259 Lines: 8 In article <20040710033209.GA14316@gondor.apana.org.au> (at Sat, 10 Jul 2004 13:32:09 +1000), Herbert Xu says: > Now that the IPv4 encap stuff is out of the way, I'll be sending you > the IPv6 versions. Looks good. --yoshfuji From jmorris@redhat.com Fri Jul 9 23:34:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jul 2004 23:35:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A6Yngi003905 for ; Fri, 9 Jul 2004 23:34:49 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6A6Yce1014771; Sat, 10 Jul 2004 02:34:38 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6A6Yb003668; Sat, 10 Jul 2004 02:34:37 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6A6Ya4G027263; Sat, 10 Jul 2004 02:34:36 -0400 Date: Sat, 10 Jul 2004 02:34:36 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: kuznet@ms2.inr.ac.ru, , Subject: Re: [IPSEC] Move generic encap code into xfrm4_output In-Reply-To: <20040710005146.GA11023@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 277 Lines: 17 On Sat, 10 Jul 2004, Herbert Xu wrote: > Hi: > > I've finally finished merging the general encapsulation code for IPv4. > Here is the patch. This looks fine to me so far, also tests ok with various tunneled configurations. - James -- James Morris From herbert@gondor.apana.org.au Sat Jul 10 02:16:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 02:17:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6A9Glgi010374 for ; Sat, 10 Jul 2004 02:16:49 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BjDyF-0000m5-00; Sat, 10 Jul 2004 19:16:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BjDyA-0004Fh-00; Sat, 10 Jul 2004 19:16:30 +1000 Date: Sat, 10 Jul 2004 19:16:30 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: IPv6 and encapsulation headers Message-ID: <20040710091630.GA16312@gondor.apana.org.au> References: <20040710033209.GA14316@gondor.apana.org.au> <20040710.133641.132032007.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040710.133641.132032007.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1088 Lines: 28 On Sat, Jul 10, 2004 at 01:36:41PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Looks good. Thanks for reviewing it. I've got a couple of questions that you might be able to help me with. It appears that the value of hdr_len in ah6 for transport mode is broken. It's setting hdr_len to be skb->h.raw - skb->nh.raw. When AH is being applied outside an ESP tunnel, skb->h.raw will be pointing somewhere inside the tunnel. The end result is that leading bytes of the payload inside the tunnel gets moved before the AH header. So should it be changed to ip6_find_1stfragopt() as is the case with esp6 and ipcomp6? A second problem is that ip6_find_1stfragopt() seems to be the wrong thing to do for ah6/esp6/ipcomp6. RFC 2402/2406/3173 all say that fragment headers should be placed before the encapsulation header. So should it be changed accordingly? Thanks again, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From vkondra@mail.ru Sat Jul 10 05:37:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 05:38:27 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6ACbWgi019843 for ; Sat, 10 Jul 2004 05:37:32 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 51F2F24BE21; Sat, 10 Jul 2004 13:00:34 +0400 (MSD) Received: from [82.80.132.207] (port=54313 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BjDhf-0003hu-00; Sat, 10 Jul 2004 12:59:29 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: ethernet QoS support? Date: Sat, 10 Jul 2004 11:58:41 +0300 User-Agent: KMail/1.6.2 Cc: Sam Leffler , hadi@cyberus.ca, Jeff Garzik , Kumar Gala References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407092126.43021.vkondra@mail.ru> <200407091534.53166.sam@errno.com> In-Reply-To: <200407091534.53166.sam@errno.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200407101158.58089.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6ACbWgi019843 X-archive-position: 6888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2603 Lines: 62 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 10 July 2004 01:34, Sam Leffler wrote: > On Friday 09 July 2004 11:26 am, Vladimir Kondratiev wrote: > > > So what do you do now? > > > > Waiting. If no support will exist, it simply means we will be unable to > > use QoS provided by modern 802.11. Depending on market development, > > impact may range from being slightly slower relating to Windows clients, > > to being almost completely unable to communicate for traffic like VOIP. > > Later will be the case if most access points will implement QoS as in > > TGE. > > > > I can now deliver packets accordingly to skb->priority, but if stack have > > different idea for what is proper proportion between different sorts of > > traffic, driver's Tx path will be flooded with low priority frames. > > > > Situation is much worser for streams with admission control. I have no > > mechanism to communicate with stack for such traffic establishment and > > tear down. > > FWIW the madwifi net80211 layer parses TOS to calculate priority and sticks > it in the skb. It also calculates the WME AC to form the QoS frame matter. Sam, I think, to use skb->priority is more proper then parse TOS. Several points for this: 1. by default, IP code do it for you - it sets skb->priority equal to TOS; 2. stack may have better idea of what priority should be assigned. For this, it have all queuing/classifiers stuff with qdiscs. 3. it is layer violation to use information above MAC. It may be non-IP stack above you. > This is then handed to drivers below. The Atheros driver supports multiple > tx queues in h/w with appropriate scheduling (for 5212 MACs); it uses the > AC to set packets on the appropriate queue. > > Clearly it'd be better if upper layers did the TOS stuff. Whatever is done > however should consider the case where the driver (nee h/w) has it's own > queueing/scheduling facilities. > I also do something similar. But, to be honest, this is not working. If stack feeds you with different mixture of high and low priority streams, you can do nothing. All you can do by doing additional in-driver queuing is to smooth short spikes. What will you do for TGE? HCCA TSPECS and EDCA categories with admission control? I continue to insist that for true MAC layer QoS, we need several Tx queues. Anyway, I see we are on the same page with you, as we are facing same problems. Vladimir -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA76/Rqxdj7mhC6o0RAvyMAJ0UafCsb2P94oo5FVbNoIZ3+qVXEACfTI3D l9a0YAXR9xPvlpz0wZMlWdQ= =BrFw -----END PGP SIGNATURE----- From bunk@fs.tum.de Sat Jul 10 10:16:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 10:16:39 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6AHGZgi030726 for ; Sat, 10 Jul 2004 10:16:36 -0700 Received: (qmail 16668 invoked from network); 10 Jul 2004 17:10:57 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 10 Jul 2004 17:10:57 -0000 Date: Sat, 10 Jul 2004 19:16:28 +0200 From: Adrian Bunk To: Jeff Garzik Cc: linux-net@vger.kernel.org, Netdev Subject: Re: [2.6 patch] net/hamradio/dmascc: remove inlines Message-ID: <20040710171628.GT28324@fs.tum.de> References: <20040710010414.GX28324@fs.tum.de> <40F020C7.5010608@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40F020C7.5010608@pobox.com> User-Agent: Mutt/1.5.6i X-archive-position: 6889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Content-Length: 732 Lines: 24 On Sat, Jul 10, 2004 at 01:00:55PM -0400, Jeff Garzik wrote: >... > It seems like you are going directly against the intent of the author, > with this patch. The intend of the author might have been different - but the author didn't notice that his inlines never had any effect since the ordering of the functions was wrong. I could send a patch to reorder the file to get the inlines working, but I heavily doubt inlining e.g. rx_on would be an improvement. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From davem@redhat.com Sat Jul 10 12:02:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 12:02:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6AJ2Vgi001700 for ; Sat, 10 Jul 2004 12:02:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6AJ2Ke1007137; Sat, 10 Jul 2004 15:02:20 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6AJ2K023780; Sat, 10 Jul 2004 15:02:20 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6AJ1mri019467; Sat, 10 Jul 2004 15:01:49 -0400 Date: Sat, 10 Jul 2004 12:02:01 -0700 From: "David S. Miller" To: James Morris Cc: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [IPSEC] Move generic encap code into xfrm4_output Message-Id: <20040710120201.0decc8ac.davem@redhat.com> In-Reply-To: References: <20040710005146.GA11023@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 377 Lines: 14 On Sat, 10 Jul 2004 02:34:36 -0400 (EDT) James Morris wrote: > On Sat, 10 Jul 2004, Herbert Xu wrote: > > > Hi: > > > > I've finally finished merging the general encapsulation code for IPv4. > > Here is the patch. > > This looks fine to me so far, also tests ok with various tunneled > configurations. Looks good to me too. Applied, thanks Herbert. From davem@redhat.com Sat Jul 10 12:21:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 12:21:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6AJLbgi005594 for ; Sat, 10 Jul 2004 12:21:37 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6AJLPe1009607; Sat, 10 Jul 2004 15:21:25 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6AJLP026366; Sat, 10 Jul 2004 15:21:25 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6AJKs4D022418; Sat, 10 Jul 2004 15:20:54 -0400 Date: Sat, 10 Jul 2004 12:21:06 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [IPCOMP6] Exclude IPCOMP header from props.header_len Message-Id: <20040710122106.05951ea7.davem@redhat.com> In-Reply-To: <20040710.133641.132032007.yoshfuji@linux-ipv6.org> References: <20040710033209.GA14316@gondor.apana.org.au> <20040710.133641.132032007.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6AJLbgi005594 X-archive-position: 6891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 397 Lines: 12 On Sat, 10 Jul 2004 13:36:41 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <20040710033209.GA14316@gondor.apana.org.au> (at Sat, 10 Jul 2004 13:32:09 +1000), Herbert Xu says: > > > Now that the IPv4 encap stuff is out of the way, I'll be sending you > > the IPv6 versions. > > Looks good. To me too, patch applied. From bunk@fs.tum.de Sat Jul 10 12:33:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 12:33:41 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6AJXagi006074 for ; Sat, 10 Jul 2004 12:33:37 -0700 Received: (qmail 28136 invoked from network); 10 Jul 2004 19:27:58 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 10 Jul 2004 19:27:58 -0000 Date: Sat, 10 Jul 2004 21:33:29 +0200 From: Adrian Bunk To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [2.6 patch] NET_IPIP help: remove no longer available URL Message-ID: <20040710193329.GW28324@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 6892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Content-Length: 894 Lines: 20 This patch solves Bugzilla #2445 by removing a no longer available URL from the help text for NET_IPIP. Noted by Nils Hammar . Signed-off-by: Adrian Bunk --- linux-2.6.7-mm7-full/net/ipv4/Kconfig.old 2004-07-10 21:27:06.000000000 +0200 +++ linux-2.6.7-mm7-full/net/ipv4/Kconfig 2004-07-10 21:27:28.000000000 +0200 @@ -196,8 +196,7 @@ can be useful if you want to make your (or some other) machine appear on a different network than it physically is, or to use mobile-IP facilities (allowing laptops to seamlessly move between - networks without changing their IP addresses; check out - ). + networks without changing their IP addresses). Saying Y to this option will produce two modules ( = code which can be inserted in and removed from the running kernel whenever you From bunk@fs.tum.de Sat Jul 10 12:34:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 12:34:16 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6AJYDgi006164 for ; Sat, 10 Jul 2004 12:34:14 -0700 Received: (qmail 28151 invoked from network); 10 Jul 2004 19:28:36 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 10 Jul 2004 19:28:36 -0000 Date: Sat, 10 Jul 2004 21:34:07 +0200 From: Adrian Bunk To: netdev@oss.sgi.com, Marcelo Tosatti Cc: linux-kernel@vger.kernel.org Subject: [2.4 patch] NET_IPIP help: remove no longer available URL Message-ID: <20040710193407.GX28324@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 6893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Content-Length: 912 Lines: 19 This patch solves Bugzilla #2445 by removing a no longer available URL from the help text for NET_IPIP. Noted by Nils Hammar . Signed-off-by: Adrian Bunk --- linux-2.4.27-rc3-full/Documentation/Configure.help.old 2004-07-10 21:29:41.000000000 +0200 +++ linux-2.4.27-rc3-full/Documentation/Configure.help 2004-07-10 21:29:54.000000000 +0200 @@ -6172,8 +6172,7 @@ can be useful if you want to make your (or some other) machine appear on a different network than it physically is, or to use mobile-IP facilities (allowing laptops to seamlessly move between - networks without changing their IP addresses; check out - ). + networks without changing their IP addresses). Saying Y to this option will produce two modules ( = code which can be inserted in and removed from the running kernel whenever you From jgarzik@pobox.com Sat Jul 10 18:19:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 18:19:34 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6B1JVgi015498 for ; Sat, 10 Jul 2004 18:19:32 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bi4fF-00050v-Ty; Wed, 07 Jul 2004 06:08:14 +0100 Message-ID: <40EB8532.7020006@pobox.com> Date: Wed, 07 Jul 2004 01:08:02 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: netdev@oss.sgi.com Subject: Re: [PATCH] allow modular mv64340_eth References: <20040706103645.GA14521@lst.de> In-Reply-To: <20040706103645.GA14521@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Sat Jul 10 23:19:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jul 2004 23:19:26 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6B6JJgi031938 for ; Sat, 10 Jul 2004 23:19:20 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BjLDn-0007DE-Rq; Sat, 10 Jul 2004 18:01:08 +0100 Message-ID: <40F020C7.5010608@pobox.com> Date: Sat, 10 Jul 2004 13:00:55 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: linux-net@vger.kernel.org, Netdev Subject: Re: [2.6 patch] net/hamradio/dmascc: remove inlines References: <20040710010414.GX28324@fs.tum.de> In-Reply-To: <20040710010414.GX28324@fs.tum.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 3508 Lines: 113 Adrian Bunk wrote: > Trying to compile drivers/scsi/ips.c with gcc 3.4 and > # define inline __inline__ __attribute__((always_inline)) > results in compile errors starting with the following: > > <-- snip --> > > ... > CC drivers/net/hamradio/dmascc.o > drivers/net/hamradio/dmascc.c: In function `scc_isr': > drivers/net/hamradio/dmascc.c:250: sorry, unimplemented: inlining failed > in call to 'z8530_isr': function body not available > drivers/net/hamradio/dmascc.c:969: sorry, unimplemented: called from here > drivers/net/hamradio/dmascc.c:250: sorry, unimplemented: inlining failed > in call to 'z8530_isr': function body not available > drivers/net/hamradio/dmascc.c:978: sorry, unimplemented: called from here > make[3]: *** [drivers/net/hamradio/dmascc.o] Error 1 > > <-- snip --> > > > The patch below removes all inlines from dmascc.c . > > > diffstat output: > drivers/net/hamradio/dmascc.c | 20 ++++++++++---------- > 1 files changed, 10 insertions(+), 10 deletions(-) > > > Signed-off-by: Adrian Bunk > > --- linux-2.6.7-mm7-full-gcc3.4/drivers/net/hamradio/dmascc.c.old 2004-07-10 02:51:07.000000000 +0200 > +++ linux-2.6.7-mm7-full-gcc3.4/drivers/net/hamradio/dmascc.c 2004-07-10 03:00:43.000000000 +0200 > @@ -247,7 +247,7 @@ > static int scc_set_mac_address(struct net_device *dev, void *sa); > > static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs * regs); > -static inline void z8530_isr(struct scc_info *info); > +static void z8530_isr(struct scc_info *info); > static void rx_isr(struct scc_priv *priv); > static void special_condition(struct scc_priv *priv, int rc); > static void rx_bh(void *arg); > @@ -255,11 +255,11 @@ > static void es_isr(struct scc_priv *priv); > static void tm_isr(struct scc_priv *priv); > > -static inline void tx_on(struct scc_priv *priv); > -static inline void rx_on(struct scc_priv *priv); > -static inline void rx_off(struct scc_priv *priv); > +static void tx_on(struct scc_priv *priv); > +static void rx_on(struct scc_priv *priv); > +static void rx_off(struct scc_priv *priv); > static void start_timer(struct scc_priv *priv, int t, int r15); > -static inline unsigned char random(void); > +static unsigned char random(void); > > > /* Initialization variables */ > @@ -981,7 +981,7 @@ > } > > > -static inline void z8530_isr(struct scc_info *info) { > +static void z8530_isr(struct scc_info *info) { > int is, i = 100; > > while ((is = read_scc(&info->priv[0], R3)) && i--) { > @@ -1294,7 +1294,7 @@ > } > > > -static inline void tx_on(struct scc_priv *priv) { > +static void tx_on(struct scc_priv *priv) { > int i, n; > unsigned long flags; > > @@ -1330,7 +1330,7 @@ > } > > > -static inline void rx_on(struct scc_priv *priv) { > +static void rx_on(struct scc_priv *priv) { > unsigned long flags; > > /* Clear RX FIFO */ > @@ -1364,7 +1364,7 @@ > } > > > -static inline void rx_off(struct scc_priv *priv) { > +static void rx_off(struct scc_priv *priv) { > /* Disable receiver */ > write_scc(priv, R3, Rx8); > /* Disable DREQ / RX interrupt */ > @@ -1397,7 +1397,7 @@ > } > > > -static inline unsigned char random(void) { > +static unsigned char random(void) { > /* See "Numerical Recipes in C", second edition, p. 284 */ > rand = rand * 1664525L + 1013904223L; > return (unsigned char) (rand >> 24); It seems like you are going directly against the intent of the author, with this patch. Jeff From davem@redhat.com Sun Jul 11 17:52:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jul 2004 17:52:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6C0qIgi014972 for ; Sun, 11 Jul 2004 17:52:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6C0pDe1012027; Sun, 11 Jul 2004 20:51:13 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6C0pC010209; Sun, 11 Jul 2004 20:51:12 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6C0oe33013670; Sun, 11 Jul 2004 20:50:40 -0400 Date: Sun, 11 Jul 2004 17:50:29 -0700 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org Subject: Re: [2.4 patch] NET_IPIP help: remove no longer available URL Message-Id: <20040711175029.2a438085.davem@redhat.com> In-Reply-To: <20040710193407.GX28324@fs.tum.de> References: <20040710193407.GX28324@fs.tum.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 329 Lines: 11 On Sat, 10 Jul 2004 21:34:07 +0200 Adrian Bunk wrote: > This patch solves Bugzilla #2445 by removing a no longer available URL > from the help text for NET_IPIP. > > Noted by Nils Hammar . > > Signed-off-by: Adrian Bunk Both 2.4.x and 2.6.x versions applied, thanks Adrian. From kazunori@miyazawa.org Mon Jul 12 01:34:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 01:34:16 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6C8Xhgi014489 for ; Mon, 12 Jul 2004 01:34:03 -0700 Received: from [2001:200:1b0:2032:20c:29ff:febb:6598] ([2001:200:1b0:2032:20c:29ff:febb:6598]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Mon, 12 Jul 2004 17:25:37 +0900 id 00000F33.40F24B01.00006F49 From: Kazunori Miyazawa To: Herbert Xu Subject: Re: IPv6 and encapsulation headers Date: Mon, 12 Jul 2004 17:32:52 +0900 User-Agent: KMail/1.6.2 References: <20040710033209.GA14316@gondor.apana.org.au> <20040710.133641.132032007.yoshfuji@linux-ipv6.org> <20040710091630.GA16312@gondor.apana.org.au> In-Reply-To: <20040710091630.GA16312@gondor.apana.org.au> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Message-Id: <200407121732.52542.kazunori@miyazawa.org> X-archive-position: 6900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Content-Length: 1342 Lines: 39 Hello Herbert, > On Sat, Jul 10, 2004 at 01:36:41PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Looks good. > > Thanks for reviewing it. > > I've got a couple of questions that you might be able to help me with. > > It appears that the value of hdr_len in ah6 for transport mode is broken. > It's setting hdr_len to be skb->h.raw - skb->nh.raw. When AH is being > applied outside an ESP tunnel, skb->h.raw will be pointing somewhere > inside the tunnel. The end result is that leading bytes of the payload > inside the tunnel gets moved before the AH header. > right, esp6 tunnel doesn't care about skb->h.raw. we need to fix it. > So should it be changed to ip6_find_1stfragopt() as is the case with > esp6 and ipcomp6? Do we need to skip esp or ipcomp payload? I thinks those are similar with transport layer protocol in outer esp process. Did I misunderstand your question? > A second problem is that ip6_find_1stfragopt() seems to be the wrong > thing to do for ah6/esp6/ipcomp6. RFC 2402/2406/3173 all say that > fragment headers should be placed before the encapsulation header. > So should it be changed accordingly? > Because fragmentation takes place after IPsec processing, do we need to make ip6_find_1stfragopt care fragment header? I think there is no fragment header in skb at that point. --Kazunori Miyazawa From glen.turner@aarnet.edu.au Mon Jul 12 01:43:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 01:44:06 -0700 (PDT) Received: from clix.aarnet.edu.au ([192.94.63.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6C8hPgi015100 for ; Mon, 12 Jul 2004 01:43:46 -0700 Received: from [192.43.230.12] ([192.43.230.12]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id i6C8dFWo011832 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 12 Jul 2004 18:39:17 +1000 Subject: Re: ethernet QoS support? From: Glen Turner To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Sam Leffler , hadi@cyberus.ca, Jeff Garzik , Kumar Gala In-Reply-To: <200407101158.58089.vkondra@mail.ru> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407092126.43021.vkondra@mail.ru> <200407091534.53166.sam@errno.com> <200407101158.58089.vkondra@mail.ru> Content-Type: text/plain Organization: Australian Academic and Research Network Message-Id: <1089621532.3063.8.camel@andromache> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 12 Jul 2004 18:08:52 +0930 Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: glen.turner@aarnet.edu.au Precedence: bulk X-list: netdev Content-Length: 777 Lines: 25 On Sat, 2004-07-10 at 18:28, Vladimir Kondratiev wrote: > I continue to insist that for true MAC layer QoS, we need several Tx queues. If you have several MAC-layer queues, then do you have another set of MAC-layer scheduling? If so, how do you select the algorithm? I suggest this can of worms requires further thought before we end up with two layers of QoS queuing and scheduling. Cheers, Glen PS: Can we *please* deprecate use of the ToS bits. We had almost killed them and Linux is again encouraging their use, much to the despair of network operators (who want DiffServ, or at least DiffServ-compatible use of IP Precedence) -- Glen Turner Tel: +61 8 8303 3936 Australian Academic & Research Network www.aarnet.edu.au From herbert@gondor.apana.org.au Mon Jul 12 03:47:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 03:47:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CAlKgi020287 for ; Mon, 12 Jul 2004 03:47:42 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BjyL3-0001oa-00; Mon, 12 Jul 2004 20:47:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BjyL0-0000PE-00; Mon, 12 Jul 2004 20:47:10 +1000 Date: Mon, 12 Jul 2004 20:47:10 +1000 To: Kazunori Miyazawa Cc: netdev@oss.sgi.com Subject: Re: IPv6 and encapsulation headers Message-ID: <20040712104710.GC965@gondor.apana.org.au> References: <20040710033209.GA14316@gondor.apana.org.au> <20040710.133641.132032007.yoshfuji@linux-ipv6.org> <20040710091630.GA16312@gondor.apana.org.au> <200407121732.52542.kazunori@miyazawa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407121732.52542.kazunori@miyazawa.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2126 Lines: 55 On Mon, Jul 12, 2004 at 05:32:52PM +0900, Kazunori Miyazawa wrote: > > right, esp6 tunnel doesn't care about skb->h.raw. we need to fix it. The same needs to be done to the other tunnels as well. But please consider the issue in the next paragraph first before doing this. > > So should it be changed to ip6_find_1stfragopt() as is the case with > > esp6 and ipcomp6? > > Do we need to skip esp or ipcomp payload? > I thinks those are similar with transport layer protocol in outer esp process. > Did I misunderstand your question? I don't know because I didn't understand your question :) Let me state a few things and please tell me whether you agree or disagree: 1. AH's position should be determined by the bundle. So if the bundle says AH+ESP then AH goes on the outside, if the bundle says ESP+AH or just AH then AH goes on the inside. 2. If AH is the inner-most xfrm then it should be applied before the second destination options header. It seems to me that skb->h is not actually set to the spot pointed to ip6_find_1stfragopt() by anything apart from the xfrm output functions. Therefore if AH is the inner-most xfrm, then skb->h will also point to the wrong spot. It would appear to be safest to call ip6_find_1stfragopt() in AH instead of relying on the value of skb->h. Regardless of whether we use skb->h or ip6_find_1stfragopt() though, ah6/esp6/ipcomp6 should all use the same logic to find their spot for encapsulation. The reason is that the specification in 2402/2406/3173 is identical so we shouldn't have special-case code in AH. > Because fragmentation takes place after IPsec processing, > do we need to make ip6_find_1stfragopt care fragment header? > I think there is no fragment header in skb at that point. Good point. Hmm, what about address spoofing? Is there code in IPv6 to prevent another machine from relaying a packet through us with our source address? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Mon Jul 12 05:18:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 05:19:02 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CCIXgi027735 for ; Mon, 12 Jul 2004 05:18:54 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BjzlO-00077A-6U for netdev@oss.sgi.com; Mon, 12 Jul 2004 08:18:30 -0400 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 1BjzlJ-00049R-9z; Mon, 12 Jul 2004 08:18:25 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Jeff Garzik , Kumar Gala In-Reply-To: <200407092126.43021.vkondra@mail.ru> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407091641.35651.vkondra@mail.ru> <1089383622.1030.21.camel@jzny.localdomain> <200407092126.43021.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089634701.1055.260.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jul 2004 08:18:22 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2820 Lines: 70 On Fri, 2004-07-09 at 14:26, Vladimir Kondratiev wrote: > > Who marks the skb->priority? Is that the default mark as per TOS? > > I think the VLAN code marks it as well. > I don't care. It should not be driver's business. Actually, it is TOS. AFAIK, > application supposed to do setsockoption(SO_PRIORITY) on its socket so set > priority. That or if routed from another host, then TOS does get extracted and set to skb->priority > Agree about intelligence. Driver should serve link and MAC layer. But exactly > because link layer have different priorities, driver need several Tx queues. > It is stack's business to route packet to the proper queue. Driver should > deliver it using appropriate MAC layer priority. So far you have said there are two schedulers h/ware understands: strict priority(3 band strict priority is the deafult in Linux) and WRR. The qdisc level is already taken care of today. > Waiting. If no support will exist, it simply means we will be unable to use > QoS provided by modern 802.11. I think someone with motivation and hardware (such as you Vladimir ;->)should take the lead. I have offered to consult and review code. > Depending on market development, impact may > range from being slightly slower relating to Windows clients, to being almost > completely unable to communicate for traffic like VOIP. Later will be the > case if most access points will implement QoS as in TGE. > > I can now deliver packets accordingly to skb->priority, but if stack have > different idea for what is proper proportion between different sorts of > traffic, driver's Tx path will be flooded with low priority frames. I dont think so - as long as you map to a specific qdisc things should work fine. i.e the scheduling semantics will be taken good care of by the qdisc level. So lets separate the two levels, driver and qdisc level. I dont think they should be synchronized. In my opinion, the synchronization point is the configurator/operator/management s/ware of the box. > Situation is much worser for streams with admission control. I have no > mechanism to communicate with stack for such traffic establishment and tear > down. Let me make an interim suggestion: To illustrate i will assume 3 priorities with priority 1 higher than priority 3. Substitute with whatever driver does. Assuming the priorities will be reflected in the skb->priority. - Shut down device only when highest(1) priority ring is full. - if packets received for priority 2 and 3 and their respective rings are full, drop the packet in the driver and return a 0 i.e dont shut device. You can also do the following in the case of strict priority(caveat is reordering may happen): for each prio X try to stash on DMA ring of prio X. If full, try X+1, if full try X+2 etc. Thoughts? cheers, jamal From hadi@znyx.com Mon Jul 12 05:21:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 05:21:30 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CCL4gi028098 for ; Mon, 12 Jul 2004 05:21:25 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004071205212691:17277 ; Mon, 12 Jul 2004 05:21:26 -0700 Subject: [Fwd: Re: ethernet QoS support?] From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: netdev@oss.sgi.com Organization: ZNYX Networks Message-Id: <1089634861.1056.264.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jul 2004 08:21:01 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/12/2004 05:21:27 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/12/2004 05:21:49 AM, Serialize complete at 07/12/2004 05:21:49 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 6904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 3195 Lines: 82 Didnt see the echo - and we all know how enthusiastic the firewall admin at oss.sgi.com - so heres a resend -----Forwarded Message----- From: jamal To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Jeff Garzik , Kumar Gala Subject: Re: ethernet QoS support? Date: 12 Jul 2004 08:18:22 -0400 On Fri, 2004-07-09 at 14:26, Vladimir Kondratiev wrote: > > Who marks the skb->priority? Is that the default mark as per TOS? > > I think the VLAN code marks it as well. > I don't care. It should not be driver's business. Actually, it is TOS. AFAIK, > application supposed to do setsockoption(SO_PRIORITY) on its socket so set > priority. That or if routed from another host, then TOS does get extracted and set to skb->priority > Agree about intelligence. Driver should serve link and MAC layer. But exactly > because link layer have different priorities, driver need several Tx queues. > It is stack's business to route packet to the proper queue. Driver should > deliver it using appropriate MAC layer priority. So far you have said there are two schedulers h/ware understands: strict priority(3 band strict priority is the deafult in Linux) and WRR. The qdisc level is already taken care of today. > Waiting. If no support will exist, it simply means we will be unable to use > QoS provided by modern 802.11. I think someone with motivation and hardware (such as you Vladimir ;->)should take the lead. I have offered to consult and review code. > Depending on market development, impact may > range from being slightly slower relating to Windows clients, to being almost > completely unable to communicate for traffic like VOIP. Later will be the > case if most access points will implement QoS as in TGE. > > I can now deliver packets accordingly to skb->priority, but if stack have > different idea for what is proper proportion between different sorts of > traffic, driver's Tx path will be flooded with low priority frames. I dont think so - as long as you map to a specific qdisc things should work fine. i.e the scheduling semantics will be taken good care of by the qdisc level. So lets separate the two levels, driver and qdisc level. I dont think they should be synchronized. In my opinion, the synchronization point is the configurator/operator/management s/ware of the box. > Situation is much worser for streams with admission control. I have no > mechanism to communicate with stack for such traffic establishment and tear > down. Let me make an interim suggestion: To illustrate i will assume 3 priorities with priority 1 higher than priority 3. Substitute with whatever driver does. Assuming the priorities will be reflected in the skb->priority. - Shut down device only when highest(1) priority ring is full. - if packets received for priority 2 and 3 and their respective rings are full, drop the packet in the driver and return a 0 i.e dont shut device. You can also do the following in the case of strict priority(caveat is reordering may happen): for each prio X try to stash on DMA ring of prio X. If full, try X+1, if full try X+2 etc. Thoughts? cheers, jamal From hadi@cyberus.ca Mon Jul 12 05:27:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 05:27:30 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CCR8gi028818 for ; Mon, 12 Jul 2004 05:27:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Bjztg-00071L-Sq for netdev@oss.sgi.com; Mon, 12 Jul 2004 08:27:04 -0400 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 1Bjztc-0005Ca-Ji; Mon, 12 Jul 2004 08:27:00 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Glen Turner Cc: Vladimir Kondratiev , netdev@oss.sgi.com, Sam Leffler , Jeff Garzik , Kumar Gala In-Reply-To: <1089621532.3063.8.camel@andromache> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407092126.43021.vkondra@mail.ru> <200407091534.53166.sam@errno.com> <200407101158.58089.vkondra@mail.ru> <1089621532.3063.8.camel@andromache> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089635216.1054.271.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jul 2004 08:26:57 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1186 Lines: 34 On Mon, 2004-07-12 at 04:38, Glen Turner wrote: > On Sat, 2004-07-10 at 18:28, Vladimir Kondratiev wrote: > > > I continue to insist that for true MAC layer QoS, we need several Tx queues. > > If you have several MAC-layer queues, then do you have > another set of MAC-layer scheduling? If so, how do you > select the algorithm? A mapping is being suggested. Qdiscs handle the queueing. Send it to the driver/MAC layer with instructions of which queue it goes on. > I suggest this can of worms requires further thought > before we end up with two layers of QoS queuing and > scheduling. Refer to the thread earlier; i think the mapping is pretty much sufficient. > PS: Can we *please* deprecate use of the ToS bits. We had > almost killed them and Linux is again encouraging their > use, much to the despair of network operators (who want > DiffServ, or at least DiffServ-compatible use of IP > Precedence) I know you are refering to the default linux behavior, but do you use any of the diffserv enablers like dsmark to set DSCPs? I think 2.6.7+ we should change that default behavior. What exactly are the network operators complaining about? cheers, jamal From shemminger@osdl.org Mon Jul 12 08:13:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 08:13:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CFDNgi008839 for ; Mon, 12 Jul 2004 08:13:44 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6CFCdk06802; Mon, 12 Jul 2004 08:12:39 -0700 Date: Mon, 12 Jul 2004 08:12:39 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [RFC] netem - add jitter support. Message-Id: <20040712081239.21697179@dell_ss3.pdx.osdl.net> In-Reply-To: <1089335650.1046.150.camel@jzny.localdomain> References: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> <1089335650.1046.150.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1202 Lines: 35 On 08 Jul 2004 21:14:10 -0400 jamal wrote: > On Thu, 2004-07-08 at 16:53, Stephen Hemminger wrote: > > This patch adds jitter if desired to the delayed packets in the > > netem scheduler. I dropped the rate stuff out and reorganized so > > that an underlying pfifo queue is used (next plan is to make it > > have class ops). > > > > The jitter is given as sigma to a Gaussian normal distribution. The actual > > implementation is a reduced form of the table driven stuff in NISTnet > > (free). > > Good stuff. > - Is that NIST code/reference ok to put there? I have a feeling its > non-free. In README.License: As a U.S. government publication, so to speak, NIST Net is not copyrighted. You can do whatever you want with it, including employing its code in whole or in part in any other package or product. You need not credit me or NIST (though not doing so would be a bit rude). > - Could that table be computed in user space instead? This way you are > not restricted to just the normal distribution. I could also use them > if available from within tc sources, That wouldn't be hard, maybe even the ability to do correlated distributions. > cheers, > jamal > From shemminger@osdl.org Mon Jul 12 10:15:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 10:15:20 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CHFFgi023143 for ; Mon, 12 Jul 2004 10:15:16 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6CHF0k03221; Mon, 12 Jul 2004 10:15:00 -0700 Date: Mon, 12 Jul 2004 10:15:00 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] netem packet scheduler class support Message-Id: <20040712101500.4a0babd3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2520 Lines: 104 Simple enhancement to netem packet scheduler that makes it classful so that the underlying pfifo default discipline can be substituted with something else (tbf, red, ...) Signed-off-by: Stephen Hemminger --- linux-2.6/net/sched/sch_netem.c 2004-07-12 08:05:35.439533776 -0700 +++ tcp-2.6/net/sched/sch_netem.c 2004-07-12 09:00:23.251710352 -0700 @@ -829,8 +829,95 @@ rtattr_failure: return -1; } +static int netem_dump_class(struct Qdisc *sch, unsigned long cl, + struct sk_buff *skb, struct tcmsg *tcm) +{ + struct netem_sched_data *q = (struct netem_sched_data*)sch->data; + + if (cl != 1) /* only one class */ + return -ENOENT; + + tcm->tcm_handle |= TC_H_MIN(1); + tcm->tcm_info = q->qdisc->handle; + + return 0; +} + +static int netem_graft(struct Qdisc *sch, unsigned long arg, struct Qdisc *new, + struct Qdisc **old) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + if (new == NULL) + new = &noop_qdisc; + + sch_tree_lock(sch); + *old = xchg(&q->qdisc, new); + qdisc_reset(*old); + sch->q.qlen = 0; + sch_tree_unlock(sch); + + return 0; +} + +static struct Qdisc *netem_leaf(struct Qdisc *sch, unsigned long arg) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + return q->qdisc; +} + +static unsigned long netem_get(struct Qdisc *sch, u32 classid) +{ + return 1; +} + +static void netem_put(struct Qdisc *sch, unsigned long arg) +{ +} + +static int netem_change_class(struct Qdisc *sch, u32 classid, u32 parentid, + struct rtattr **tca, unsigned long *arg) +{ + return -ENOSYS; +} + +static int netem_delete(struct Qdisc *sch, unsigned long arg) +{ + return -ENOSYS; +} + +static void netem_walk(struct Qdisc *sch, struct qdisc_walker *walker) +{ + if (!walker->stop) { + if (walker->count >= walker->skip) + if (walker->fn(sch, 1, walker) < 0) { + walker->stop = 1; + return; + } + walker->count++; + } +} + +static struct tcf_proto **netem_find_tcf(struct Qdisc *sch, unsigned long cl) +{ + return NULL; +} + +static struct Qdisc_class_ops netem_class_ops = { + .graft = netem_graft, + .leaf = netem_leaf, + .get = netem_get, + .put = netem_put, + .change = netem_change_class, + .delete = netem_delete, + .walk = netem_walk, + .tcf_chain = netem_find_tcf, + .dump = netem_dump_class, +}; + static struct Qdisc_ops netem_qdisc_ops = { .id = "netem", + .cl_ops = &netem_class_ops, .priv_size = sizeof(struct netem_sched_data), .enqueue = netem_enqueue, .dequeue = netem_dequeue, From shemminger@osdl.org Mon Jul 12 10:29:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 10:29:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CHT7gi025466 for ; Mon, 12 Jul 2004 10:29:07 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6CHStk15631; Mon, 12 Jul 2004 10:28:55 -0700 Date: Mon, 12 Jul 2004 10:28:55 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] netem missing qdisc destroy Message-Id: <20040712102855.1a08262c@dell_ss3.pdx.osdl.net> In-Reply-To: <20040712101500.4a0babd3@dell_ss3.pdx.osdl.net> References: <20040712101500.4a0babd3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 572 Lines: 18 The underlying qdisc was not being properly destroyed, shows up as assertion failure on device removal. Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2004-07-12 10:27:10 -07:00 +++ b/net/sched/sch_netem.c 2004-07-12 10:27:10 -07:00 @@ -806,6 +806,9 @@ struct netem_sched_data *q = (struct netem_sched_data *)sch->data; del_timer_sync(&q->timer); + + qdisc_destroy(q->qdisc); + q->qdisc = &noop_qdisc; } static int netem_dump(struct Qdisc *sch, struct sk_buff *skb) From vkondra@mail.ru Mon Jul 12 11:07:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 11:07:46 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CI7fgi031489 for ; Mon, 12 Jul 2004 11:07:41 -0700 Received: from [212.179.236.146] (port=18646 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1Bk5DE-000B91-00; Mon, 12 Jul 2004 22:07:37 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: ethernet QoS support? Date: Mon, 12 Jul 2004 21:07:24 +0300 User-Agent: KMail/1.6.2 Cc: Jeff Garzik , Kumar Gala References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407092126.43021.vkondra@mail.ru> <1089634701.1055.260.camel@jzny.localdomain> In-Reply-To: <1089634701.1055.260.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200407122107.29389.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6CI7fgi031489 X-archive-position: 6909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 4155 Lines: 94 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 July 2004 15:18, jamal wrote: > On Fri, 2004-07-09 at 14:26, Vladimir Kondratiev wrote: > > > Who marks the skb->priority? Is that the default mark as per TOS? > > > I think the VLAN code marks it as well. > > > > I don't care. It should not be driver's business. Actually, it is TOS. > > AFAIK, application supposed to do setsockoption(SO_PRIORITY) on its > > socket so set priority. > > That or if routed from another host, then TOS does get extracted and set > to skb->priority this is not very important. From one side, it seems like bug in routing code. - From another side, 802.11 was supposed for link ends only. It is not supposed to appear in the middle of routers chain. > > > Agree about intelligence. Driver should serve link and MAC layer. But > > exactly because link layer have different priorities, driver need several > > Tx queues. It is stack's business to route packet to the proper queue. > > Driver should deliver it using appropriate MAC layer priority. > > So far you have said there are two schedulers h/ware understands: strict > priority(3 band strict priority is the deafult in Linux) and WRR. > The qdisc level is already taken care of today. > > > Waiting. If no support will exist, it simply means we will be unable to > > use QoS provided by modern 802.11. > > I think someone with motivation and hardware (such as you > Vladimir ;->)should take the lead. I have offered to consult and review > code. You know: schedule, plan, other job to do, limited time... And, I don't feel myself enough educated in network stack internals. Now I think I can speak for the driver. This is what I am trying to do. But I started looking for qdiscs and other stuff, so may be eventually I will get there. > > > Depending on market development, impact may > > range from being slightly slower relating to Windows clients, to being > > almost completely unable to communicate for traffic like VOIP. Later will > > be the case if most access points will implement QoS as in TGE. > > > > I can now deliver packets accordingly to skb->priority, but if stack have > > different idea for what is proper proportion between different sorts of > > traffic, driver's Tx path will be flooded with low priority frames. > > I dont think so - as long as you map to a specific qdisc things should > work fine. i.e the scheduling semantics will be taken good care of by > the qdisc level. > So lets separate the two levels, driver and qdisc level. > I dont think they should be synchronized. In my opinion, the > synchronization point is the configurator/operator/management s/ware of > the box. QoS policies are dictated by access point, they are coming to the driver from the link side. And I see no way to let upper layers to know these policies. > > > Situation is much worser for streams with admission control. I have no > > mechanism to communicate with stack for such traffic establishment and > > tear down. > > Let me make an interim suggestion: > To illustrate i will assume 3 priorities with priority 1 higher than > priority 3. Substitute with whatever driver does. Assuming the > priorities will be reflected in the skb->priority. > > - Shut down device only when highest(1) priority ring is full. > - if packets received for priority 2 and 3 and their respective rings > are full, drop the packet in the driver and return a 0 i.e dont shut > device. Real situation: - - highest priority is VOIP (200 bytes each 20ms). With decent link, it will always pass. - - low priority is ftp bulk transfer. stack pushes more then driver can tx. I will silently drop 9 out of 10 packets. Not a good behavior. > > You can also do the following in the case of strict priority(caveat is > reordering may happen): > for each prio X try to stash on DMA ring of prio X. If full, try X+1, if > full try X+2 etc. forbidden by spec. I will be disconnected immediately. > > Thoughts? > > cheers, > jamal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFA8tNhqxdj7mhC6o0RAsKoAJdfe1cMHghBSDI8Jel9zYsdmP6kAJ0fshJw M3b1lsvT4zq3oRR5fveylg== =6FLN -----END PGP SIGNATURE----- From vkondra@mail.ru Mon Jul 12 12:07:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 12:07:22 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CJ78gi013855 for ; Mon, 12 Jul 2004 12:07:09 -0700 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 30EB83D3E0E; Mon, 12 Jul 2004 22:18:54 +0400 (MSD) Received: from [212.179.236.146] (port=18650 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1Bk5N9-00067r-00; Mon, 12 Jul 2004 22:17:51 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: ethernet QoS support? Date: Mon, 12 Jul 2004 21:17:38 +0300 User-Agent: KMail/1.6.2 Cc: Glen Turner , Sam Leffler , Jeff Garzik , Kumar Gala References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <1089621532.3063.8.camel@andromache> <1089635216.1054.271.camel@jzny.localdomain> In-Reply-To: <1089635216.1054.271.camel@jzny.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200407122117.44069.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6CJ78gi013855 X-archive-position: 6910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2414 Lines: 60 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 July 2004 15:26, jamal wrote: > On Mon, 2004-07-12 at 04:38, Glen Turner wrote: > > On Sat, 2004-07-10 at 18:28, Vladimir Kondratiev wrote: > > > I continue to insist that for true MAC layer QoS, we need several Tx > > > queues. > > > > If you have several MAC-layer queues, then do you have > > another set of MAC-layer scheduling? If so, how do you > > select the algorithm? > > A mapping is being suggested. Qdiscs handle the queueing. Send it to > the driver/MAC layer with instructions of which queue it goes on. Problem is, I don't know how driver can dictate what qdiscs should be attached to it. AFAIK, it is under 'tc' control. What I suggest, is to provide some API for driver to configure its qdiscs. > > > I suggest this can of worms requires further thought > > before we end up with two layers of QoS queuing and > > scheduling. > > Refer to the thread earlier; i think the mapping is pretty much > sufficient. There is a bit more complex then just diffserv. Glen touched very good point: it should be no 2 QoS policies. Since in case of 802.11, policy dictated from link layer, driver should be able to configure upper layers accordingly. And most complex item: I don't know how to support intserv type of streams, i.e. streams with admission control. let's say it is like RSVP with support on link layer. Should I try to summarize QoS facilities defined in TGE (new standard for QoS in 802.11)? I tried to do it once, but I don't feel I expressed it clearly. > > > PS: Can we *please* deprecate use of the ToS bits. We had > > almost killed them and Linux is again encouraging their > > use, much to the despair of network operators (who want > > DiffServ, or at least DiffServ-compatible use of IP > > Precedence) One more reason why I prefer to use skb->priority over TOS: driver should be protocol agnostic. It may be non-IP, and TOS may be missing. > > I know you are refering to the default linux behavior, but > do you use any of the diffserv enablers like dsmark to set DSCPs? > I think 2.6.7+ we should change that default behavior. What exactly > are the network operators complaining about? > > cheers, > jamal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA8tXIqxdj7mhC6o0RAsICAKCBBsGH5fXO3z/muggJ0K/z7o5cMwCcDaFm qNV8hhHZRpoPHbcSSv1QHac= =AVLn -----END PGP SIGNATURE----- From margitsw@t-online.de Mon Jul 12 12:15:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 12:15:13 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CJF7gi015058 for ; Mon, 12 Jul 2004 12:15:08 -0700 Received: from fwd07.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1Bk6GN-0006j1-06; Mon, 12 Jul 2004 21:14:55 +0200 Received: from roglap.local (bdcHBTZDYezhkcq7qMtkPUHhnz33zOZJ0lBgIyGnAFxrBsj0BfDP0+@[217.255.117.137]) by fwd07.sul.t-online.com with esmtp id 1Bk6GI-1SfjrU0; Mon, 12 Jul 2004 21:14:50 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Fix wrong type for BSSID Date: Mon, 12 Jul 2004 21:08:16 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_gGu8Ak2HayVVLag" Message-Id: <200407122108.16380.margitsw@t-online.de> X-Seen: false X-ID: bdcHBTZDYezhkcq7qMtkPUHhnz33zOZJ0lBgIyGnAFxrBsj0BfDP0+ X-archive-position: 6911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 1888 Lines: 64 --Boundary-00=_gGu8Ak2HayVVLag Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-12 Margit Schubert-While * The OID type for BSSID was incorrectly set to type SSID. It should be type RAW. This lead to interesting reporting by "iwpriv ethX g_bssid". (Which caused garbage output and possibly an out of bound) * Be ultra-cautious in reporting SSID by changing the "%s" to "%.*s" and passing the length. (Prompted by the false type above, whereby length = 0 and a %s on a garbage field) Jeff, this is on top of the previous patch (chanfreq.patch) from 2004/07/06 (which isn't in 2.6.8-rc1). Margit --Boundary-00=_gGu8Ak2HayVVLag Content-Type: text/x-diff; charset="us-ascii"; name="bssid.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bssid.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.8-02/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c 2004-07-06 17:26:44.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/oid_mgt.c 2004-07-12 21:05:22.000000000 +0200 @@ -62,7 +62,7 @@ /* 802.11 */ OID_U32_C(DOT11_OID_BSSTYPE, 0x10000000), - OID_STRUCT_C(DOT11_OID_BSSID, 0x10000001, u8[6], OID_TYPE_SSID), + OID_STRUCT_C(DOT11_OID_BSSID, 0x10000001, u8[6], OID_TYPE_RAW), OID_STRUCT_C(DOT11_OID_SSID, 0x10000002, struct obj_ssid, OID_TYPE_SSID), OID_U32(DOT11_OID_STATE, 0x10000003), @@ -770,8 +770,9 @@ case OID_TYPE_SSID:{ struct obj_ssid *ssid = r->ptr; return snprintf(str, PRIV_STR_SIZE, - "length=%u\noctets=%s\n", - ssid->length, ssid->octets); + "length=%u\noctets=%.*s\n", + ssid->length, ssid->length, + ssid->octets); } break; case OID_TYPE_KEY:{ --Boundary-00=_gGu8Ak2HayVVLag-- From shemminger@osdl.org Mon Jul 12 15:03:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 15:04:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CM3vgi004940 for ; Mon, 12 Jul 2004 15:03:57 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6CM3gk16136; Mon, 12 Jul 2004 15:03:42 -0700 Date: Mon, 12 Jul 2004 15:03:41 -0700 From: Stephen Hemminger To: "David S. Miller" , coreteam@netfilter.org Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] bad initializer in ipv6 netfilter. Message-Id: <20040712150341.44a84ff6@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6913 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 537 Lines: 16 Missing equal sign in C99 initializer. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv6/netfilter/ip6table_raw.c b/net/ipv6/netfilter/ip6table_raw.c --- a/net/ipv6/netfilter/ip6table_raw.c 2004-07-12 14:46:39 -07:00 +++ b/net/ipv6/netfilter/ip6table_raw.c 2004-07-12 14:46:39 -07:00 @@ -74,7 +74,7 @@ { .entry = { .target_offset = sizeof(struct ip6t_entry), - .next_offset sizeof(struct ip6t_standard), + .next_offset = sizeof(struct ip6t_standard), }, .target = { .target = { From shemminger@osdl.org Mon Jul 12 15:04:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 15:05:00 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CM4ugi005182 for ; Mon, 12 Jul 2004 15:04:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6CM4ik18333; Mon, 12 Jul 2004 15:04:44 -0700 Date: Mon, 12 Jul 2004 15:04:44 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] missing annotation in ipv6 addrconf Message-Id: <20040712150444.0396b23e@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6914 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 539 Lines: 16 Missing __user annotation in simulated ioctl call. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2004-07-12 15:02:04 -07:00 +++ b/net/ipv6/addrconf.c 2004-07-12 15:02:04 -07:00 @@ -1544,7 +1544,7 @@ p.iph.ihl = 5; p.iph.protocol = IPPROTO_IPV6; p.iph.ttl = 64; - ifr.ifr_ifru.ifru_data = (void*)&p; + ifr.ifr_ifru.ifru_data = (void __user *)&p; oldfs = get_fs(); set_fs(KERNEL_DS); err = dev->do_ioctl(dev, &ifr, SIOCADDTUNNEL); From shemminger@osdl.org Mon Jul 12 15:44:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 15:45:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CMiugi011983 for ; Mon, 12 Jul 2004 15:44:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6CMiik04186; Mon, 12 Jul 2004 15:44:44 -0700 Date: Mon, 12 Jul 2004 15:44:44 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] minor #if complaint Message-Id: <20040712154444.46ae6922@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 567 Lines: 16 Minor sparse warning fix. it doesn't like #if when #ifdef is intended. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/pcmcia/nmclan_cs.c b/drivers/net/pcmcia/nmclan_cs.c --- a/drivers/net/pcmcia/nmclan_cs.c 2004-07-12 15:07:19 -07:00 +++ b/drivers/net/pcmcia/nmclan_cs.c 2004-07-12 15:07:19 -07:00 @@ -1472,7 +1472,7 @@ Modified from Am79C90 data sheet. ---------------------------------------------------------------------------- */ -#if BROKEN_MULTICAST +#ifdef BROKEN_MULTICAST static void updateCRC(int *CRC, int bit) { From bunk@fs.tum.de Mon Jul 12 16:05:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 16:05:13 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6CN54gi017277 for ; Mon, 12 Jul 2004 16:05:06 -0700 Received: (qmail 4657 invoked from network); 12 Jul 2004 22:59:17 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 12 Jul 2004 22:59:17 -0000 Date: Tue, 13 Jul 2004 01:04:56 +0200 From: Adrian Bunk To: Jeff Garzik Cc: linux-net@vger.kernel.org, Netdev Subject: Re: [2.6 patch] net/hamradio/dmascc: remove inlines Message-ID: <20040712230456.GZ4701@fs.tum.de> References: <20040710010414.GX28324@fs.tum.de> <40F020C7.5010608@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40F020C7.5010608@pobox.com> User-Agent: Mutt/1.5.6i X-archive-position: 6916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Content-Length: 12517 Lines: 377 On Sat, Jul 10, 2004 at 01:00:55PM -0400, Jeff Garzik wrote: >... > It seems like you are going directly against the intent of the author, > with this patch. Below is a patch without removing any inline. > Jeff Trying to compile drivers/scsi/ips.c with gcc 3.4 and # define inline __inline__ __attribute__((always_inline)) results in compile errors starting with the following: <-- snip --> ... CC drivers/net/hamradio/dmascc.o drivers/net/hamradio/dmascc.c: In function `scc_isr': drivers/net/hamradio/dmascc.c:250: sorry, unimplemented: inlining failed in call to 'z8530_isr': function body not available drivers/net/hamradio/dmascc.c:969: sorry, unimplemented: called from here drivers/net/hamradio/dmascc.c:250: sorry, unimplemented: inlining failed in call to 'z8530_isr': function body not available drivers/net/hamradio/dmascc.c:978: sorry, unimplemented: called from here make[3]: *** [drivers/net/hamradio/dmascc.o] Error 1 <-- snip --> The patch below moves all inline'd functions before their callers. diffstat output: drivers/net/hamradio/dmascc.c | 290 ++++++++++++++++------------------ 1 files changed, 144 insertions(+), 146 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.7-mm7-full-gcc3.4/drivers/net/hamradio/dmascc.c.old 2004-07-13 00:55:54.000000000 +0200 +++ linux-2.6.7-mm7-full-gcc3.4/drivers/net/hamradio/dmascc.c 2004-07-13 01:01:06.000000000 +0200 @@ -246,8 +246,14 @@ static struct net_device_stats *scc_get_stats(struct net_device *dev); static int scc_set_mac_address(struct net_device *dev, void *sa); -static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs * regs); +static inline void tx_on(struct scc_priv *priv); +static inline void rx_on(struct scc_priv *priv); +static inline void rx_off(struct scc_priv *priv); +static void start_timer(struct scc_priv *priv, int t, int r15); +static inline unsigned char random(void); + static inline void z8530_isr(struct scc_info *info); +static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs * regs); static void rx_isr(struct scc_priv *priv); static void special_condition(struct scc_priv *priv, int rc); static void rx_bh(void *arg); @@ -255,12 +261,6 @@ static void es_isr(struct scc_priv *priv); static void tm_isr(struct scc_priv *priv); -static inline void tx_on(struct scc_priv *priv); -static inline void rx_on(struct scc_priv *priv); -static inline void rx_off(struct scc_priv *priv); -static void start_timer(struct scc_priv *priv, int t, int r15); -static inline unsigned char random(void); - /* Initialization variables */ @@ -945,42 +945,115 @@ } -static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs * regs) { - struct scc_info *info = dev_id; +static inline void tx_on(struct scc_priv *priv) { + int i, n; + unsigned long flags; - spin_lock(info->priv[0].register_lock); - /* At this point interrupts are enabled, and the interrupt under service - is already acknowledged, but masked off. + if (priv->param.dma >= 0) { + n = (priv->chip == Z85230) ? 3 : 1; + /* Program DMA controller */ + flags = claim_dma_lock(); + set_dma_mode(priv->param.dma, DMA_MODE_WRITE); + set_dma_addr(priv->param.dma, (int) priv->tx_buf[priv->tx_tail]+n); + set_dma_count(priv->param.dma, priv->tx_len[priv->tx_tail]-n); + release_dma_lock(flags); + /* Enable TX underrun interrupt */ + write_scc(priv, R15, TxUIE); + /* Configure DREQ */ + if (priv->type == TYPE_TWIN) + outb((priv->param.dma == 1) ? TWIN_DMA_HDX_T1 : TWIN_DMA_HDX_T3, + priv->card_base + TWIN_DMA_CFG); + else + write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN | WT_RDY_ENAB); + /* Write first byte(s) */ + spin_lock_irqsave(priv->register_lock, flags); + for (i = 0; i < n; i++) + write_scc_data(priv, priv->tx_buf[priv->tx_tail][i], 1); + enable_dma(priv->param.dma); + spin_unlock_irqrestore(priv->register_lock, flags); + } else { + write_scc(priv, R15, TxUIE); + write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN | TxINT_ENAB); + tx_isr(priv); + } + /* Reset EOM latch if we do not have the AUTOEOM feature */ + if (priv->chip == Z8530) write_scc(priv, R0, RES_EOM_L); +} - Interrupt processing: We loop until we know that the IRQ line is - low. If another positive edge occurs afterwards during the ISR, - another interrupt will be triggered by the interrupt controller - as soon as the IRQ level is enabled again (see asm/irq.h). - Bottom-half handlers will be processed after scc_isr(). This is - important, since we only have small ringbuffers and want new data - to be fetched/delivered immediately. */ +static inline void rx_on(struct scc_priv *priv) { + unsigned long flags; - if (info->priv[0].type == TYPE_TWIN) { - int is, card_base = info->priv[0].card_base; - while ((is = ~inb(card_base + TWIN_INT_REG)) & - TWIN_INT_MSK) { - if (is & TWIN_SCC_MSK) { - z8530_isr(info); - } else if (is & TWIN_TMR1_MSK) { - inb(card_base + TWIN_CLR_TMR1); - tm_isr(&info->priv[0]); - } else { - inb(card_base + TWIN_CLR_TMR2); - tm_isr(&info->priv[1]); - } + /* Clear RX FIFO */ + while (read_scc(priv, R0) & Rx_CH_AV) read_scc_data(priv); + priv->rx_over = 0; + if (priv->param.dma >= 0) { + /* Program DMA controller */ + flags = claim_dma_lock(); + set_dma_mode(priv->param.dma, DMA_MODE_READ); + set_dma_addr(priv->param.dma, (int) priv->rx_buf[priv->rx_head]); + set_dma_count(priv->param.dma, BUF_SIZE); + release_dma_lock(flags); + enable_dma(priv->param.dma); + /* Configure PackeTwin DMA */ + if (priv->type == TYPE_TWIN) { + outb((priv->param.dma == 1) ? TWIN_DMA_HDX_R1 : TWIN_DMA_HDX_R3, + priv->card_base + TWIN_DMA_CFG); } - } else z8530_isr(info); - spin_unlock(info->priv[0].register_lock); - return IRQ_HANDLED; + /* Sp. cond. intr. only, ext int enable, RX DMA enable */ + write_scc(priv, R1, EXT_INT_ENAB | INT_ERR_Rx | + WT_RDY_RT | WT_FN_RDYFN | WT_RDY_ENAB); + } else { + /* Reset current frame */ + priv->rx_ptr = 0; + /* Intr. on all Rx characters and Sp. cond., ext int enable */ + write_scc(priv, R1, EXT_INT_ENAB | INT_ALL_Rx | WT_RDY_RT | + WT_FN_RDYFN); + } + write_scc(priv, R0, ERR_RES); + write_scc(priv, R3, RxENABLE | Rx8 | RxCRC_ENAB); +} + + +static inline void rx_off(struct scc_priv *priv) { + /* Disable receiver */ + write_scc(priv, R3, Rx8); + /* Disable DREQ / RX interrupt */ + if (priv->param.dma >= 0 && priv->type == TYPE_TWIN) + outb(0, priv->card_base + TWIN_DMA_CFG); + else + write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); + /* Disable DMA */ + if (priv->param.dma >= 0) disable_dma(priv->param.dma); +} + + +static void start_timer(struct scc_priv *priv, int t, int r15) { + unsigned long flags; + + outb(priv->tmr_mode, priv->tmr_ctrl); + if (t == 0) { + tm_isr(priv); + } else if (t > 0) { + save_flags(flags); + cli(); + outb(t & 0xFF, priv->tmr_cnt); + outb((t >> 8) & 0xFF, priv->tmr_cnt); + if (priv->type != TYPE_TWIN) { + write_scc(priv, R15, r15 | CTSIE); + priv->rr0 |= CTS; + } + restore_flags(flags); + } } +static inline unsigned char random(void) { + /* See "Numerical Recipes in C", second edition, p. 284 */ + rand = rand * 1664525L + 1013904223L; + return (unsigned char) (rand >> 24); +} + static inline void z8530_isr(struct scc_info *info) { int is, i = 100; @@ -1009,6 +1082,42 @@ } +static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs * regs) { + struct scc_info *info = dev_id; + + spin_lock(info->priv[0].register_lock); + /* At this point interrupts are enabled, and the interrupt under service + is already acknowledged, but masked off. + + Interrupt processing: We loop until we know that the IRQ line is + low. If another positive edge occurs afterwards during the ISR, + another interrupt will be triggered by the interrupt controller + as soon as the IRQ level is enabled again (see asm/irq.h). + + Bottom-half handlers will be processed after scc_isr(). This is + important, since we only have small ringbuffers and want new data + to be fetched/delivered immediately. */ + + if (info->priv[0].type == TYPE_TWIN) { + int is, card_base = info->priv[0].card_base; + while ((is = ~inb(card_base + TWIN_INT_REG)) & + TWIN_INT_MSK) { + if (is & TWIN_SCC_MSK) { + z8530_isr(info); + } else if (is & TWIN_TMR1_MSK) { + inb(card_base + TWIN_CLR_TMR1); + tm_isr(&info->priv[0]); + } else { + inb(card_base + TWIN_CLR_TMR2); + tm_isr(&info->priv[1]); + } + } + } else z8530_isr(info); + spin_unlock(info->priv[0].register_lock); + return IRQ_HANDLED; +} + + static void rx_isr(struct scc_priv *priv) { if (priv->param.dma >= 0) { /* Check special condition and perform error reset. See 2.4.7.5. */ @@ -1292,114 +1401,3 @@ break; } } - - -static inline void tx_on(struct scc_priv *priv) { - int i, n; - unsigned long flags; - - if (priv->param.dma >= 0) { - n = (priv->chip == Z85230) ? 3 : 1; - /* Program DMA controller */ - flags = claim_dma_lock(); - set_dma_mode(priv->param.dma, DMA_MODE_WRITE); - set_dma_addr(priv->param.dma, (int) priv->tx_buf[priv->tx_tail]+n); - set_dma_count(priv->param.dma, priv->tx_len[priv->tx_tail]-n); - release_dma_lock(flags); - /* Enable TX underrun interrupt */ - write_scc(priv, R15, TxUIE); - /* Configure DREQ */ - if (priv->type == TYPE_TWIN) - outb((priv->param.dma == 1) ? TWIN_DMA_HDX_T1 : TWIN_DMA_HDX_T3, - priv->card_base + TWIN_DMA_CFG); - else - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN | WT_RDY_ENAB); - /* Write first byte(s) */ - spin_lock_irqsave(priv->register_lock, flags); - for (i = 0; i < n; i++) - write_scc_data(priv, priv->tx_buf[priv->tx_tail][i], 1); - enable_dma(priv->param.dma); - spin_unlock_irqrestore(priv->register_lock, flags); - } else { - write_scc(priv, R15, TxUIE); - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN | TxINT_ENAB); - tx_isr(priv); - } - /* Reset EOM latch if we do not have the AUTOEOM feature */ - if (priv->chip == Z8530) write_scc(priv, R0, RES_EOM_L); -} - - -static inline void rx_on(struct scc_priv *priv) { - unsigned long flags; - - /* Clear RX FIFO */ - while (read_scc(priv, R0) & Rx_CH_AV) read_scc_data(priv); - priv->rx_over = 0; - if (priv->param.dma >= 0) { - /* Program DMA controller */ - flags = claim_dma_lock(); - set_dma_mode(priv->param.dma, DMA_MODE_READ); - set_dma_addr(priv->param.dma, (int) priv->rx_buf[priv->rx_head]); - set_dma_count(priv->param.dma, BUF_SIZE); - release_dma_lock(flags); - enable_dma(priv->param.dma); - /* Configure PackeTwin DMA */ - if (priv->type == TYPE_TWIN) { - outb((priv->param.dma == 1) ? TWIN_DMA_HDX_R1 : TWIN_DMA_HDX_R3, - priv->card_base + TWIN_DMA_CFG); - } - /* Sp. cond. intr. only, ext int enable, RX DMA enable */ - write_scc(priv, R1, EXT_INT_ENAB | INT_ERR_Rx | - WT_RDY_RT | WT_FN_RDYFN | WT_RDY_ENAB); - } else { - /* Reset current frame */ - priv->rx_ptr = 0; - /* Intr. on all Rx characters and Sp. cond., ext int enable */ - write_scc(priv, R1, EXT_INT_ENAB | INT_ALL_Rx | WT_RDY_RT | - WT_FN_RDYFN); - } - write_scc(priv, R0, ERR_RES); - write_scc(priv, R3, RxENABLE | Rx8 | RxCRC_ENAB); -} - - -static inline void rx_off(struct scc_priv *priv) { - /* Disable receiver */ - write_scc(priv, R3, Rx8); - /* Disable DREQ / RX interrupt */ - if (priv->param.dma >= 0 && priv->type == TYPE_TWIN) - outb(0, priv->card_base + TWIN_DMA_CFG); - else - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); - /* Disable DMA */ - if (priv->param.dma >= 0) disable_dma(priv->param.dma); -} - - -static void start_timer(struct scc_priv *priv, int t, int r15) { - unsigned long flags; - - outb(priv->tmr_mode, priv->tmr_ctrl); - if (t == 0) { - tm_isr(priv); - } else if (t > 0) { - save_flags(flags); - cli(); - outb(t & 0xFF, priv->tmr_cnt); - outb((t >> 8) & 0xFF, priv->tmr_cnt); - if (priv->type != TYPE_TWIN) { - write_scc(priv, R15, r15 | CTSIE); - priv->rr0 |= CTS; - } - restore_flags(flags); - } -} - - -static inline unsigned char random(void) { - /* See "Numerical Recipes in C", second edition, p. 284 */ - rand = rand * 1664525L + 1013904223L; - return (unsigned char) (rand >> 24); -} - From kazunori@miyazawa.org Mon Jul 12 18:43:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 18:43:44 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D1hfgi006059 for ; Mon, 12 Jul 2004 18:43:42 -0700 Received: from dhcp043.local.ini.jp (cp.64translator.com [::ffff:202.214.123.2]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Tue, 13 Jul 2004 10:35:31 +0900 id 00000AF0.40F33C64.00000494 From: Kazunori Miyazawa To: Herbert Xu Subject: Re: IPv6 and encapsulation headers Date: Tue, 13 Jul 2004 10:42:41 +0900 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: <20040710033209.GA14316@gondor.apana.org.au> <200407121732.52542.kazunori@miyazawa.org> <20040712104710.GC965@gondor.apana.org.au> In-Reply-To: <20040712104710.GC965@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Message-Id: <200407131042.41346.kazunori@miyazawa.org> X-archive-position: 6917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Content-Length: 2419 Lines: 68 2004/07/12($B7n(B) 19:47$B!"(BHerbert Xu wrote: > On Mon, Jul 12, 2004 at 05:32:52PM +0900, Kazunori Miyazawa wrote: > > right, esp6 tunnel doesn't care about skb->h.raw. we need to fix it. > > The same needs to be done to the other tunnels as well. But please > consider the issue in the next paragraph first before doing this. > > > > So should it be changed to ip6_find_1stfragopt() as is the case with > > > esp6 and ipcomp6? > > > > Do we need to skip esp or ipcomp payload? > > I thinks those are similar with transport layer protocol in outer esp > > process. Did I misunderstand your question? > > I don't know because I didn't understand your question :) > > Let me state a few things and please tell me whether you agree or > disagree: > > 1. AH's position should be determined by the bundle. So if the > bundle says AH+ESP then AH goes on the outside, if the bundle says > ESP+AH or just AH then AH goes on the inside. > agree. > 2. If AH is the inner-most xfrm then it should be applied before > the second destination options header. Yes. > > It seems to me that skb->h is not actually set to the spot pointed > to ip6_find_1stfragopt() by anything apart from the xfrm output > functions. > > Therefore if AH is the inner-most xfrm, then skb->h will also point > to the wrong spot. It would appear to be safest to call > ip6_find_1stfragopt() in AH instead of relying on the value of skb->h. > I agree with you. It should uses ip6_find_1stfragopt. However please consider zero_out_mutable_opts in ah6.c clears second destination options. We need to get the copy length by other way. Because ip6_find_1stfragopt returns the insert point of IPsec. > Regardless of whether we use skb->h or ip6_find_1stfragopt() though, > ah6/esp6/ipcomp6 should all use the same logic to find their spot for > encapsulation. The reason is that the specification in 2402/2406/3173 > is identical so we shouldn't have special-case code in AH. > > > Because fragmentation takes place after IPsec processing, > > do we need to make ip6_find_1stfragopt care fragment header? > > I think there is no fragment header in skb at that point. > > Good point. > > Hmm, what about address spoofing? Is there code in IPv6 to prevent > another machine from relaying a packet through us with our source > address? > Does it concern with IPsec or fragmentation? It might be netfiler stuff. Thank you, --Kazunori Miyazawa From kaber@trash.net Mon Jul 12 19:22:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 19:22:17 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D2MCgi007377 for ; Mon, 12 Jul 2004 19:22:12 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BkCyH-0005xM-00; Tue, 13 Jul 2004 04:24:41 +0200 Message-ID: <40F34740.5040100@trash.net> Date: Tue, 13 Jul 2004 04:21:52 +0200 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: "David S. Miller" CC: netdev@oss.sgi.com, devik Subject: [PATCH 2.6]: Make packet scheduler clock source configurable Content-Type: multipart/mixed; boundary="------------070903000700050408010104" X-archive-position: 6918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 12906 Lines: 191 This is a multi-part message in MIME format. --------------070903000700050408010104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, this patch replaces PSCHED_CLOCK_SOURCE by three new config options and fixes HTB compilation with CONFIG_NET_SCH_CLK_GETTIMEOFDAY. Patch compiles with all three options. If you like it I will also send you a 2.4 version. Regards Patrick --------------070903000700050408010104 Content-Type: application/octect-stream; name="psched-clk.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="psched-clk.diff" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2gu CiMKIyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDcvMTMgMDM6NDQ6MjkrMDI6MDAga2FiZXJAdHJh c2gubmV0IAojICAgW05FVF9TQ0hFRF06IE1ha2UgY2xvY2sgc291cmNlIGNvbmZpZ3VyYWJs ZQojICAgCiMgICBTaWduZWQtb2ZmLWJ5OiBQYXRyaWNrIE1jSGFyZHkgPGthYmVyQHRyYXNo Lm5ldD4KIyAKIyBuZXQvc2NoZWQvc2NoX2h0Yi5jCiMgICAyMDA0LzA3LzEzIDAzOjQ0OjE4 KzAyOjAwIGthYmVyQHRyYXNoLm5ldCArMTAgLTAKIyAgIFtORVRfU0NIRURdOiBNYWtlIGNs b2NrIHNvdXJjZSBjb25maWd1cmFibGUKIyAKIyBuZXQvc2NoZWQvc2NoX2hmc2MuYwojICAg MjAwNC8wNy8xMyAwMzo0NDoxOCswMjowMCBrYWJlckB0cmFzaC5uZXQgKzUgLTUKIyAgIFtO RVRfU0NIRURdOiBNYWtlIGNsb2NrIHNvdXJjZSBjb25maWd1cmFibGUKIyAKIyBuZXQvc2No ZWQvc2NoX2FwaS5jCiMgICAyMDA0LzA3LzEzIDAzOjQ0OjE4KzAyOjAwIGthYmVyQHRyYXNo Lm5ldCArNiAtNgojICAgW05FVF9TQ0hFRF06IE1ha2UgY2xvY2sgc291cmNlIGNvbmZpZ3Vy YWJsZQojIAojIG5ldC9zY2hlZC9LY29uZmlnCiMgICAyMDA0LzA3LzEzIDAzOjQ0OjE4KzAy OjAwIGthYmVyQHRyYXNoLm5ldCArMjggLTAKIyAgIFtORVRfU0NIRURdOiBNYWtlIGNsb2Nr IHNvdXJjZSBjb25maWd1cmFibGUKIyAKIyBpbmNsdWRlL25ldC9wa3Rfc2NoZWQuaAojICAg MjAwNC8wNy8xMyAwMzo0NDoxOCswMjowMCBrYWJlckB0cmFzaC5uZXQgKzE1IC0yMAojICAg W05FVF9TQ0hFRF06IE1ha2UgY2xvY2sgc291cmNlIGNvbmZpZ3VyYWJsZQojIApkaWZmIC1O cnUgYS9pbmNsdWRlL25ldC9wa3Rfc2NoZWQuaCBiL2luY2x1ZGUvbmV0L3BrdF9zY2hlZC5o Ci0tLSBhL2luY2x1ZGUvbmV0L3BrdF9zY2hlZC5oCTIwMDQtMDctMTMgMDM6NDY6NTUgKzAy OjAwCisrKyBiL2luY2x1ZGUvbmV0L3BrdF9zY2hlZC5oCTIwMDQtMDctMTMgMDM6NDY6NTUg KzAyOjAwCkBAIC0xLDEyICsxLDYgQEAKICNpZm5kZWYgX19ORVRfUEtUX1NDSEVEX0gKICNk ZWZpbmUgX19ORVRfUEtUX1NDSEVEX0gKIAotI2RlZmluZSBQU0NIRURfR0VUVElNRU9GREFZ CTEKLSNkZWZpbmUgUFNDSEVEX0pJRkZJRVMgCQkyCi0jZGVmaW5lIFBTQ0hFRF9DUFUgCQkz Ci0KLSNkZWZpbmUgUFNDSEVEX0NMT0NLX1NPVVJDRQlQU0NIRURfSklGRklFUwotCiAjaW5j bHVkZSA8bGludXgvY29uZmlnLmg+CiAjaW5jbHVkZSA8bGludXgvbmV0ZGV2aWNlLmg+CiAj aW5jbHVkZSA8bGludXgvdHlwZXMuaD4KQEAgLTE4NSwyNCArMTc5LDI0IEBACiAgICBnZXR0 aW1lb2ZkYXksIGl0IHJldHVybnMgaW52YWxpZCB0aW1lc3RhbXAsIHdoaWNoIGlzCiAgICBu b3QgdXBkYXRlZCwgd2hlbiBuZXRfYmggaXMgYWN0aXZlLgogCi0gICBTbywgdXNlIFBTQ0hF RF9DTE9DS19TT1VSQ0UgPSBQU0NIRURfQ1BVIG9uIGFscGhhIGFuZCBwZW50aXVtcwotICAg d2l0aCBydGRzYy4gQW5kIFBTQ0hFRF9KSUZGSUVTIG9uIGFsbCBvdGhlciBhcmNoaXRlY3R1 cmVzLCBpbmNsdWRpbmcgWzM0XTg2CisgICBTbywgdXNlIENPTkZJR19ORVRfU0NIX0NMS19U U0Mgb24gYWxwaGEgYW5kIHBlbnRpdW1zIHdpdGggcnRkc2MuCisgICBBbmQgQ09ORklHX05F VF9TQ0hfQ0xLX0pJRkZJRVMgb24gYWxsIG90aGVyIGFyY2hpdGVjdHVyZXMsIGluY2x1ZGlu ZyBbMzRdODYKICAgIGFuZCBwZW50aXVtcyB3aXRob3V0IHJ0ZHNjLgotICAgWW91IGNhbiB1 c2UgUFNDSEVEX0dFVFRJTUVPRkRBWSBvbiBhbm90aGVyIGFyY2hpdGVjdHVyZXMsCisgICBZ b3UgY2FuIHVzZSBDT05GSUdfTkVUX1NDSF9DTEtfR0VUVElNRU9GREFZIG9uIGFub3RoZXIg YXJjaGl0ZWN0dXJlcywKICAgIHdoaWNoIGhhdmUgZmFzdCBhbmQgcHJlY2lzZSBjbG9jayBz b3VyY2UsIGJ1dCBpdCBpcyB0b28gZXhwZW5zaXZlLgogICovCiAKIC8qIEdlbmVyYWwgbm90 ZSBhYm91dCBpbnRlcm5hbCBjbG9jay4KIAogICAgQW55IGNsb2NrIHNvdXJjZSByZXR1cm5z IHRpbWUgaW50ZXJ2YWxzLCBtZWFzdXJlZCBpbiB1bml0cwotICAgY2xvc2UgdG8gMXVzZWMu IFdpdGggc291cmNlIFBTQ0hFRF9HRVRUSU1FT0ZEQVkgaXQgaXMgcHJlY2lzZWx5CisgICBj bG9zZSB0byAxdXNlYy4gV2l0aCBzb3VyY2UgQ09ORklHX05FVF9TQ0hfQ0xLX0dFVFRJTUVP RkRBWSBpdCBpcyBwcmVjaXNlbHkKICAgIG1pY3Jvc2Vjb25kcywgb3RoZXJ3aXNlIHNvbWV0 aGluZyBjbG9zZSBidXQgZGlmZmVyZW50IGNob3NlbiB0byBtaW5pbWl6ZQogICAgYXJpdGht ZXRpYyBjb3N0LiBSYXRpbyB1c2VjL2ludGVybmFsIHVudGlzIGluIGZvcm0gbm9taW5hdG9y L2Rlbm9taW5hdG9yCiAgICBtYXkgYmUgcmVhZCBmcm9tIC9wcm9jL25ldC9wc2NoZWQuCiAg Ki8KIAogCi0jaWYgUFNDSEVEX0NMT0NLX1NPVVJDRSA9PSBQU0NIRURfR0VUVElNRU9GREFZ CisjaWZkZWYgQ09ORklHX05FVF9TQ0hfQ0xLX0dFVFRJTUVPRkRBWQogCiB0eXBlZGVmIHN0 cnVjdCB0aW1ldmFsCXBzY2hlZF90aW1lX3Q7CiB0eXBlZGVmIGxvbmcJCXBzY2hlZF90ZGlm Zl90OwpAQCAtMjExLDE0ICsyMDUsMTQgQEAKICNkZWZpbmUgUFNDSEVEX1VTMkpJRkZJRSh1 c2VjcykgKCgodXNlY3MpKygxMDAwMDAwL0haLTEpKS8oMTAwMDAwMC9IWikpCiAjZGVmaW5l IFBTQ0hFRF9KSUZGSUUyVVMoZGVsYXkpICgoZGVsYXkpKigxMDAwMDAwL0haKSkKIAotI2Vs c2UgLyogUFNDSEVEX0NMT0NLX1NPVVJDRSAhPSBQU0NIRURfR0VUVElNRU9GREFZICovCisj ZWxzZSAvKiAhQ09ORklHX05FVF9TQ0hfQ0xLX0dFVFRJTUVPRkRBWSAqLwogCiB0eXBlZGVm IHU2NAlwc2NoZWRfdGltZV90OwogdHlwZWRlZiBsb25nCXBzY2hlZF90ZGlmZl90OwogCiBl eHRlcm4gcHNjaGVkX3RpbWVfdAlwc2NoZWRfdGltZV9iYXNlOwogCi0jaWYgUFNDSEVEX0NM T0NLX1NPVVJDRSA9PSBQU0NIRURfSklGRklFUworI2lmZGVmIENPTkZJR19ORVRfU0NIX0NM S19KSUZGSUVTCiAKICNpZiBIWiA8IDk2CiAjZGVmaW5lIFBTQ0hFRF9KU0NBTEUgMTQKQEAg LTIzNiw3ICsyMzAsOCBAQAogI2RlZmluZSBQU0NIRURfVVMySklGRklFKGRlbGF5KSAoKChk ZWxheSkrKDE8PFBTQ0hFRF9KU0NBTEUpLTEpPj5QU0NIRURfSlNDQUxFKQogI2RlZmluZSBQ U0NIRURfSklGRklFMlVTKGRlbGF5KSAoKGRlbGF5KTw8UFNDSEVEX0pTQ0FMRSkKIAotI2Vs aWYgUFNDSEVEX0NMT0NLX1NPVVJDRSA9PSBQU0NIRURfQ1BVCisjZW5kaWYgLyogQ09ORklH X05FVF9TQ0hfQ0xLX0pJRkZJRVMgKi8KKyNpZmRlZiBDT05GSUdfTkVUX1NDSF9DTEtfVFND CiAKIGV4dGVybiBwc2NoZWRfdGRpZmZfdCBwc2NoZWRfY2xvY2tfcGVyX2h6OwogZXh0ZXJu IGludCBwc2NoZWRfY2xvY2tfc2NhbGU7CkBAIC0yNjgsMTUgKzI2MywxNSBAQAogCiAjZWxz ZQogCi0jZXJyb3IgUFNDSEVEX0NMT0NLX1NPVVJDRT1QU0NIRURfQ1BVIGlzIG5vdCBzdXBw b3J0ZWQgb24gdGhpcyBhcmNoLgorI2Vycm9yICJDT05GSUdfTkVUX1NDSF9DTEtfVFNDIGlz IG5vdCBzdXBwb3J0ZWQgb24gdGhpcyBhcmNoLiIKIAogI2VuZGlmIC8qIEFSQ0ggKi8KIAot I2VuZGlmIC8qIFBTQ0hFRF9DTE9DS19TT1VSQ0UgPT0gUFNDSEVEX0pJRkZJRVMgKi8KKyNl bmRpZiAvKiBDT05GSUdfTkVUX1NDSF9DTEtfVFNDICovCiAKLSNlbmRpZiAvKiBQU0NIRURf Q0xPQ0tfU09VUkNFID09IFBTQ0hFRF9HRVRUSU1FT0ZEQVkgKi8KKyNlbmRpZiAvKiAhQ09O RklHX05FVF9TQ0hfQ0xLX0dFVFRJTUVPRkRBWSAqLwogCi0jaWYgUFNDSEVEX0NMT0NLX1NP VVJDRSA9PSBQU0NIRURfR0VUVElNRU9GREFZCisjaWZkZWYgQ09ORklHX05FVF9TQ0hfQ0xL X0dFVFRJTUVPRkRBWQogI2RlZmluZSBQU0NIRURfVERJRkYodHYxLCB0djIpIFwKICh7IFwK IAkgICBpbnQgX19kZWx0YV9zZWMgPSAodHYxKS50dl9zZWMgLSAodHYyKS50dl9zZWM7IFwK QEAgLTM0MCw3ICszMzUsNyBAQAogCiAjZGVmaW5lCVBTQ0hFRF9BVURJVF9URElGRih0KSAo eyBpZiAoKHQpID4gMjAwMDAwMCkgKHQpID0gMjAwMDAwMDsgfSkKIAotI2Vsc2UKKyNlbHNl IC8qICFDT05GSUdfTkVUX1NDSF9DTEtfR0VUVElNRU9GREFZICovCiAKICNkZWZpbmUgUFND SEVEX1RESUZGKHR2MSwgdHYyKSAobG9uZykoKHR2MSkgLSAodHYyKSkKICNkZWZpbmUgUFND SEVEX1RESUZGX1NBRkUodHYxLCB0djIsIGJvdW5kKSBcCkBAIC0zNTQsNyArMzQ5LDcgQEAK ICNkZWZpbmUgUFNDSEVEX0lTX1BBU1RQRVJGRUNUKHQpCSgodCkgPT0gMCkKICNkZWZpbmUJ UFNDSEVEX0FVRElUX1RESUZGKHQpCiAKLSNlbmRpZgorI2VuZGlmIC8qICFDT05GSUdfTkVU X1NDSF9DTEtfR0VUVElNRU9GREFZICovCiAKIHN0cnVjdCB0Y2ZfcG9saWNlCiB7CmRpZmYg LU5ydSBhL25ldC9zY2hlZC9LY29uZmlnIGIvbmV0L3NjaGVkL0tjb25maWcKLS0tIGEvbmV0 L3NjaGVkL0tjb25maWcJMjAwNC0wNy0xMyAwMzo0Njo1NSArMDI6MDAKKysrIGIvbmV0L3Nj aGVkL0tjb25maWcJMjAwNC0wNy0xMyAwMzo0Njo1NSArMDI6MDAKQEAgLTEsNiArMSwzNCBA QAogIwogIyBUcmFmZmljIGNvbnRyb2wgY29uZmlndXJhdGlvbi4KICMgCitjaG9pY2UKKwlw cm9tcHQgIlBhY2tldCBzY2hlZHVsZXIgY2xvY2sgc291cmNlIgorCWRlcGVuZHMgb24gTkVU X1NDSEVECisJZGVmYXVsdCBORVRfU0NIX0NMS19KSUZGSUVTCisKK2NvbmZpZyBORVRfU0NI X0NMS19KSUZGSUVTCisJYm9vbCAiVGltZXIgaW50ZXJydXB0IgorCWhlbHAKKwkgIFNheSBZ IGhlcmUgaWYgeW91IHdhbnQgdG8gdXNlIHRoZSB0aW1lciBpbnRlcnJ1cHQgKGppZmZpZXMp IGFzIGNsb2NrCisJICBzb3VyY2UuIFRoaXMgaXMgYW4gaW5leHBlbnNpdmUgY2xvY2sgc291 cmNlLCBidXQgaXRzIHJlc29sdXRpb24gaXMgdG9vCisJICBsb3cgZm9yIGFjY3VyYXRlIHNo YXBpbmcgZXhjZXB0IGF0IHZlcnkgbG93IHNwZWVkLgorCitjb25maWcgTkVUX1NDSF9DTEtf R0VUVElNRU9GREFZCisJYm9vbCAiZ2V0dGltZW9mZGF5IgorCWhlbHAKKwkgIFNheSBZIGhl cmUgaWYgeW91IHdhbnQgdG8gdXNlIGdldHRpbWVvZmRheSBhcyBjbG9jayBzb3VyY2UuIFRo aXMgY2xvY2sKKwkgIHNvdXJjZSBoYXMgaGlnaCByZXNvbHV0aW9uLCBidXQgaXMgdG9vIGV4 cGVuc2l2ZSBmb3Igc2xvdyBDUFVzLgorCitjb25maWcgTkVUX1NDSF9DTEtfVFNDCisJYm9v bCAiVGltZXN0YW1wIGNvdW50ZXIiCisJZGVwZW5kcyBvbiBYODZfVFNDIHx8IEFMUEhBCisJ aGVscAorCSAgU2F5IFkgaGVyZSBpZiB5b3Ugd2FudCB0byB1c2UgdGhlIENQVSdzIHRpbWVz dGFtcCBjb3VudGVyIChUU0MpIGFzCisJICBjbG9jayBzb3VyY2UuIFRoaXMgaXMgYSBjaGVh cCBhbmQgaGlnaCByZXNvbHV0aW9uIGNsb2NrIHNvdXJjZSwgY2hvb3NlCisJICB0aGlzIGlm IHlvdXIgVFNDIGlzIHdvcmtpbmcgcHJvcGVybHkuCisKK2VuZGNob2ljZQorCiBjb25maWcg TkVUX1NDSF9DQlEKIAl0cmlzdGF0ZSAiQ0JRIHBhY2tldCBzY2hlZHVsZXIiCiAJZGVwZW5k cyBvbiBORVRfU0NIRUQKZGlmZiAtTnJ1IGEvbmV0L3NjaGVkL3NjaF9hcGkuYyBiL25ldC9z Y2hlZC9zY2hfYXBpLmMKLS0tIGEvbmV0L3NjaGVkL3NjaF9hcGkuYwkyMDA0LTA3LTEzIDAz OjQ2OjU1ICswMjowMAorKysgYi9uZXQvc2NoZWQvc2NoX2FwaS5jCTIwMDQtMDctMTMgMDM6 NDY6NTUgKzAyOjAwCkBAIC0xMDg4LDcgKzEwODgsNyBAQAogfTsJCiAjZW5kaWYKIAotI2lm IFBTQ0hFRF9DTE9DS19TT1VSQ0UgPT0gUFNDSEVEX0dFVFRJTUVPRkRBWQorI2lmZGVmIENP TkZJR19ORVRfU0NIX0NMS19HRVRUSU1FT0ZEQVkKIGludCBwc2NoZWRfdG9kX2RpZmYoaW50 IGRlbHRhX3NlYywgaW50IGJvdW5kKQogewogCWludCBkZWx0YTsKQEAgLTExMDUsNyArMTEw NSw3IEBACiAKIHBzY2hlZF90aW1lX3QgcHNjaGVkX3RpbWVfYmFzZTsKIAotI2lmIFBTQ0hF RF9DTE9DS19TT1VSQ0UgPT0gUFNDSEVEX0NQVQorI2lmZGVmIENPTkZJR19ORVRfU0NIX0NM S19UU0MKIHBzY2hlZF90ZGlmZl90IHBzY2hlZF9jbG9ja19wZXJfaHo7CiBpbnQgcHNjaGVk X2Nsb2NrX3NjYWxlOwogRVhQT1JUX1NZTUJPTChwc2NoZWRfY2xvY2tfcGVyX2h6KTsKQEAg LTExMjMsNyArMTEyMyw3IEBACiAKIHN0YXRpYyB2b2lkIHBzY2hlZF90aWNrKHVuc2lnbmVk IGxvbmcgZHVtbXkpCiB7Ci0jaWYgUFNDSEVEX0NMT0NLX1NPVVJDRSA9PSBQU0NIRURfQ1BV CisjaWZkZWYgQ09ORklHX05FVF9TQ0hfQ0xLX1RTQwogCXBzY2hlZF90aW1lX3QgZHVtbXlf c3RhbXA7CiAJUFNDSEVEX0dFVF9USU1FKGR1bW15X3N0YW1wKTsKIAkvKiBJdCBpcyBPSyB1 cCB0byA0R0h6IGNwdSAqLwpAQCAtMTEzOCw3ICsxMTM4LDcgQEAKIH0KICNlbmRpZgogCi0j aWYgUFNDSEVEX0NMT0NLX1NPVVJDRSA9PSBQU0NIRURfQ1BVCisjaWZkZWYgQ09ORklHX05F VF9TQ0hfQ0xLX1RTQwogaW50IF9faW5pdCBwc2NoZWRfY2FsaWJyYXRlX2Nsb2NrKHZvaWQp CiB7CiAJcHNjaGVkX3RpbWVfdCBzdGFtcCwgc3RhbXAxOwpAQCAtMTE3OSwxMCArMTE3OSwx MCBAQAogewogCXN0cnVjdCBydG5ldGxpbmtfbGluayAqbGlua19wOwogCi0jaWYgUFNDSEVE X0NMT0NLX1NPVVJDRSA9PSBQU0NIRURfQ1BVCisjaWZkZWYgQ09ORklHX05FVF9TQ0hfQ0xL X1RTQwogCWlmIChwc2NoZWRfY2FsaWJyYXRlX2Nsb2NrKCkgPCAwKQogCQlyZXR1cm4gLTE7 Ci0jZWxpZiBQU0NIRURfQ0xPQ0tfU09VUkNFID09IFBTQ0hFRF9KSUZGSUVTCisjZWxpZiBk ZWZpbmVkKENPTkZJR19ORVRfU0NIX0NMS19KSUZGSUVTKQogCXBzY2hlZF90aWNrX3Blcl91 cyA9IEhaPDxQU0NIRURfSlNDQUxFOwogCXBzY2hlZF91c19wZXJfdGljayA9IDEwMDAwMDA7 CiAjaWZkZWYgUFNDSEVEX1dBVENIRVIKZGlmZiAtTnJ1IGEvbmV0L3NjaGVkL3NjaF9oZnNj LmMgYi9uZXQvc2NoZWQvc2NoX2hmc2MuYwotLS0gYS9uZXQvc2NoZWQvc2NoX2hmc2MuYwky MDA0LTA3LTEzIDAzOjQ2OjU1ICswMjowMAorKysgYi9uZXQvc2NoZWQvc2NoX2hmc2MuYwky MDA0LTA3LTEzIDAzOjQ2OjU1ICswMjowMApAQCAtMTkzLDcgKzE5Myw3IEBACiAvKgogICog bWFjcm9zCiAgKi8KLSNpZiBQU0NIRURfQ0xPQ0tfU09VUkNFID09IFBTQ0hFRF9HRVRUSU1F T0ZEQVkKKyNpZmRlZiBDT05GSUdfTkVUX1NDSF9DTEtfR0VUVElNRU9GREFZCiAjaW5jbHVk ZSA8bGludXgvdGltZS5oPgogI3VuZGVmIFBTQ0hFRF9HRVRfVElNRQogI2RlZmluZSBQU0NI RURfR0VUX1RJTUUoc3RhbXApCQkJCQkJXApAQCAtNDI5LDEwICs0MjksMTAgQEAKICAqCWlz bTogKHBzY2hlZF91cy9ieXRlKSA8PCBJU01fU0hJRlQKICAqCWR4OiBwc2NoZWRfdXMKICAq Ci0gKiBUaW1lIHNvdXJjZSByZXNvbHV0aW9uCi0gKiAgUFNDSEVEX0pJRkZJRVM6IGZvciA0 ODw9SFo8PTE1MzQgcmVzb2x1dGlvbiBpcyBiZXR3ZWVuIDAuNjN1cyBhbmQgMS4yN3VzLgot ICogIFBTQ0hFRF9DUFU6IHJlc29sdXRpb24gaXMgYmV0d2VlbiAwLjV1cyBhbmQgMXVzLgot ICogIFBTQ0hFRF9HRVRUSU1FT0ZEQVk6IHJlc29sdXRpb24gaXMgZXhhY3RseSAxdXMuCisg KiBDbG9jayBzb3VyY2UgcmVzb2x1dGlvbiAoQ09ORklHX05FVF9TQ0hfQ0xLXyopCisgKiAg SklGRklFUzogZm9yIDQ4PD1IWjw9MTUzNCByZXNvbHV0aW9uIGlzIGJldHdlZW4gMC42M3Vz IGFuZCAxLjI3dXMuCisgKiAgVFNDOiByZXNvbHV0aW9uIGlzIGJldHdlZW4gMC41dXMgYW5k IDF1cy4KKyAqICBHRVRUSU1FT0ZEQVk6IHJlc29sdXRpb24gaXMgZXhhY3RseSAxdXMuCiAg KgogICogc20gYW5kIGlzbSBhcmUgc2NhbGVkIGluIG9yZGVyIHRvIGtlZXAgZWZmZWN0aXZl IGRpZ2l0cy4KICAqIFNNX1NISUZUIGFuZCBJU01fU0hJRlQgYXJlIHNlbGVjdGVkIHRvIGtl ZXAgYXQgbGVhc3QgNCBlZmZlY3RpdmUKZGlmZiAtTnJ1IGEvbmV0L3NjaGVkL3NjaF9odGIu YyBiL25ldC9zY2hlZC9zY2hfaHRiLmMKLS0tIGEvbmV0L3NjaGVkL3NjaF9odGIuYwkyMDA0 LTA3LTEzIDAzOjQ2OjU1ICswMjowMAorKysgYi9uZXQvc2NoZWQvc2NoX2h0Yi5jCTIwMDQt MDctMTMgMDM6NDY6NTUgKzAyOjAwCkBAIC04NTYsOCArODU2LDEzIEBACiAJCQlpZiAobmV0 X3JhdGVsaW1pdCgpKQogCQkJCXByaW50ayhLRVJOX0VSUiAiSFRCOiBiYWQgZGlmZiBpbiBj aGFyZ2UsIGNsPSVYIGRpZmY9JWxYIG5vdz0lTHUgdGhlbj0lTHUgaj0lbHVcbiIsCiAJCQkJ ICAgICAgIGNsLT5jbGFzc2lkLCBkaWZmLAorI2lmZGVmIENPTkZJR19ORVRfU0NIX0NMS19H RVRUSU1FT0ZEQVkKKwkJCQkgICAgICAgcS0+bm93LnR2X3NlYyAqIDEwMDAwMDBVTEwgKyBx LT5ub3cudHZfdXNlYywKKwkJCQkgICAgICAgY2wtPnRfYy50dl9zZWMgKiAxMDAwMDAwVUxM ICsgY2wtPnRfYy50dl91c2VjLAorI2Vsc2UKIAkJCQkgICAgICAgKHVuc2lnbmVkIGxvbmcg bG9uZykgcS0+bm93LAogCQkJCSAgICAgICAodW5zaWduZWQgbG9uZyBsb25nKSBjbC0+dF9j LAorI2VuZGlmCiAJCQkJICAgICAgIHEtPmppZmZpZXMpOwogCQkJZGlmZiA9IDEwMDA7CiAJ CX0KQEAgLTkyNyw4ICs5MzIsMTMgQEAKIAkJCWlmIChuZXRfcmF0ZWxpbWl0KCkpCiAJCQkJ cHJpbnRrKEtFUk5fRVJSICJIVEI6IGJhZCBkaWZmIGluIGV2ZW50cywgY2w9JVggZGlmZj0l bFggbm93PSVMdSB0aGVuPSVMdSBqPSVsdVxuIiwKIAkJCQkgICAgICAgY2wtPmNsYXNzaWQs IGRpZmYsCisjaWZkZWYgQ09ORklHX05FVF9TQ0hfQ0xLX0dFVFRJTUVPRkRBWQorCQkJCSAg ICAgICBxLT5ub3cudHZfc2VjICogMTAwMDAwMFVMTCArIHEtPm5vdy50dl91c2VjLAorCQkJ CSAgICAgICBjbC0+dF9jLnR2X3NlYyAqIDEwMDAwMDBVTEwgKyBjbC0+dF9jLnR2X3VzZWMs CisjZWxzZQogCQkJCSAgICAgICAodW5zaWduZWQgbG9uZyBsb25nKSBxLT5ub3csCiAJCQkJ ICAgICAgICh1bnNpZ25lZCBsb25nIGxvbmcpIGNsLT50X2MsCisjZW5kaWYKIAkJCQkgICAg ICAgcS0+amlmZmllcyk7CiAJCQlkaWZmID0gMTAwMDsKIAkJfQo= --------------070903000700050408010104-- From hadi@cyberus.ca Mon Jul 12 19:26:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 19:26:28 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D2QPgi007750 for ; Mon, 12 Jul 2004 19:26:26 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BkCzx-0001ad-UI for netdev@oss.sgi.com; Mon, 12 Jul 2004 22:26:25 -0400 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 1BkCzk-00063f-VV; Mon, 12 Jul 2004 22:26:13 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Jeff Garzik , Kumar Gala In-Reply-To: <200407122107.29389.vkondra@mail.ru> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407092126.43021.vkondra@mail.ru> <1089634701.1055.260.camel@jzny.localdomain> <200407122107.29389.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089685567.1046.9.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jul 2004 22:26:07 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2551 Lines: 61 On Mon, 2004-07-12 at 14:07, Vladimir Kondratiev wrote: > > That or if routed from another host, then TOS does get extracted and set > > to skb->priority > this is not very important. From one side, it seems like bug in routing code. > - From another side, 802.11 was supposed for link ends only. It is not supposed > to appear in the middle of routers chain. I dont see the bug - this is pretty standard. Actually there is one issue, now that i think of it. The way IEEE maps priority is the opposite of the way IETF does it ;-> If you have 8 priorities then priority 7 would be the highest in IEEE speak (i.e most important) but priority 0 would be the one considered most important for IEEE. so a strict TOS -> skb->priority wont work ;-> > > I dont think so - as long as you map to a specific qdisc things should > > work fine. i.e the scheduling semantics will be taken good care of by > > the qdisc level. > > So lets separate the two levels, driver and qdisc level. > > I dont think they should be synchronized. In my opinion, the > > synchronization point is the configurator/operator/management s/ware of > > the box. > QoS policies are dictated by access point, they are coming to the driver from > the link side. And I see no way to let upper layers to know these policies. Huh? Are these speacial L2 level frames which carry the policy? Sounds like the people doing this were on some cheap crack. Can you describe these frames a little more? > > - Shut down device only when highest(1) priority ring is full. > > - if packets received for priority 2 and 3 and their respective rings > > are full, drop the packet in the driver and return a 0 i.e dont shut > > device. > Real situation: > - - highest priority is VOIP (200 bytes each 20ms). With decent link, it will > always pass. > - - low priority is ftp bulk transfer. stack pushes more then driver can tx. I > will silently drop 9 out of 10 packets. Not a good behavior. Thats the definition of strict priority. In other words if theres VOIP packet you always send VOIP untuil theres no more VOIP. Only then you send ftp packets. On the case of WRR, you do give some break to ftp at some point. But this is not something you have to worry about once the qdiscs are configured properly. > > > > You can also do the following in the case of strict priority(caveat is > > reordering may happen): > > for each prio X try to stash on DMA ring of prio X. If full, try X+1, if > > full try X+2 etc. > forbidden by spec. I will be disconnected immediately. Ok. cheers, jamal From hadi@cyberus.ca Mon Jul 12 19:33:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 19:33:39 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D2Xagi008206 for ; Mon, 12 Jul 2004 19:33:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BkD6u-0006Yz-JU for netdev@oss.sgi.com; Mon, 12 Jul 2004 22:33:36 -0400 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 1BkD6p-0006kK-Tb; Mon, 12 Jul 2004 22:33:32 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Glen Turner , Sam Leffler , Jeff Garzik , Kumar Gala In-Reply-To: <200407122117.44069.vkondra@mail.ru> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <1089621532.3063.8.camel@andromache> <1089635216.1054.271.camel@jzny.localdomain> <200407122117.44069.vkondra@mail.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089686006.1046.17.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jul 2004 22:33:26 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1402 Lines: 39 > > A mapping is being suggested. Qdiscs handle the queueing. Send it to > > the driver/MAC layer with instructions of which queue it goes on. > > Problem is, I don't know how driver can dictate what qdiscs should be attached > to it. AFAIK, it is under 'tc' control. What I suggest, is to provide some > API for driver to configure its qdiscs. I think driver doing this is the wrong abstraction layer.. How about this: Write a user space daemon that receives those L2 policy frames from the driver. Daemon then uses netlink to configure the qdiscs appropriately. This replaces the human opertaor who would do this in the case of a static setup. > And most complex item: I don't know how to support intserv type of streams, > i.e. streams with admission control. let's say it is like RSVP with support > on link layer. OK, so it is RSVP being used for policy config then? You seem to indicate it RSVP-like? > Should I try to summarize QoS facilities defined in TGE (new standard for QoS > in 802.11)? I tried to do it once, but I don't feel I expressed it clearly. I think so. > One more reason why I prefer to use skb->priority over TOS: driver should be > protocol agnostic. It may be non-IP, and TOS may be missing. The TOS was being used as an example. The VLAN code for example sets skb->priority at L2 as well. So nothing protcol specific about skb->priority. cheers, jamal From hadi@cyberus.ca Mon Jul 12 19:37:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 19:37:23 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D2bKgi008594 for ; Mon, 12 Jul 2004 19:37:21 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:41098 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 03:37:19 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BkDAA-00087U-Jo for netdev@linux-mips.org; Mon, 12 Jul 2004 22:36:58 -0400 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 1BkDA7-00073v-10; Mon, 12 Jul 2004 22:36:55 -0400 Subject: Re: ethernet QoS support? From: jamal Reply-To: hadi@cyberus.ca To: Vladimir Kondratiev Cc: netdev@oss.sgi.com, Jeff Garzik , Kumar Gala In-Reply-To: <1089685567.1046.9.camel@jzny.localdomain> References: <1C440F3C-D110-11D8-8B61-000393DBC2E8@freescale.com> <200407092126.43021.vkondra@mail.ru> <1089634701.1055.260.camel@jzny.localdomain> <200407122107.29389.vkondra@mail.ru> <1089685567.1046.9.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089686209.1045.20.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jul 2004 22:36:50 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 286 Lines: 11 On Mon, 2004-07-12 at 22:26, jamal wrote: > If you have 8 priorities then priority 7 would be the highest in > IEEE speak (i.e most important) but priority 0 would be the one > considered most important for IEEE. that ^^^^ should be IETF. cheers, jamal From hadi@cyberus.ca Mon Jul 12 19:39:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 19:39:45 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D2dhgi008947 for ; Mon, 12 Jul 2004 19:39:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BkDCp-0000tP-Gc for netdev@oss.sgi.com; Mon, 12 Jul 2004 22:39:43 -0400 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 1BkDCn-0007M3-3H; Mon, 12 Jul 2004 22:39:41 -0400 Subject: Re: [RFC] netem - add jitter support. From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040712081239.21697179@dell_ss3.pdx.osdl.net> References: <20040708135320.03366bd7@dell_ss3.pdx.osdl.net> <1089335650.1046.150.camel@jzny.localdomain> <20040712081239.21697179@dell_ss3.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089686376.1044.24.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jul 2004 22:39:36 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 598 Lines: 16 On Mon, 2004-07-12 at 11:12, Stephen Hemminger wrote: > > - Could that table be computed in user space instead? This way you are > > not restricted to just the normal distribution. I could also use them > > if available from within tc sources, > > That wouldn't be hard, maybe even the ability to do correlated distributions. Exactly - i have a standard action which is currently programmable for randomization as well; so if you have a standard way to send from user space(tc) i will use it. Actually those tables are well done in NIST. I am suprised i missed them before now. cheers, jamal From wgshi2002@yahoo.ca Mon Jul 12 20:03:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 20:03:24 -0700 (PDT) Received: from web54102.mail.yahoo.com (web54102.mail.yahoo.com [206.190.37.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D33Lgi009714 for ; Mon, 12 Jul 2004 20:03:22 -0700 Message-ID: <20040713030312.50570.qmail@web54102.mail.yahoo.com> Received: from [129.128.209.16] by web54102.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 23:03:12 EDT Date: Mon, 12 Jul 2004 23:03:12 -0400 (EDT) From: Weiguang Shi Subject: Re: [RFC] netem - add jitter support. To: hadi@cyberus.ca Cc: netdev linux In-Reply-To: <1089686376.1044.24.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wgshi2002@yahoo.ca Precedence: bulk X-list: netdev Content-Length: 218 Lines: 9 Hi Jamal, What are the reasons for creating netem instead of using NIST Net? Thanks, Weiguang ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From shemminger@osdl.org Mon Jul 12 20:35:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 20:35:28 -0700 (PDT) Received: from fire-2.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D3ZRgi013884 for ; Mon, 12 Jul 2004 20:35:27 -0700 Received: from www.osdl.org (fire.osdl.org [65.172.181.4]) by fire-2.osdl.org (8.12.8/8.12.8) with SMTP id i6D3ZFwr019181; Mon, 12 Jul 2004 20:35:16 -0700 Received: from 63.170.215.71 (SquirrelMail authenticated user shemminger) by www.osdl.org with HTTP; Mon, 12 Jul 2004 20:35:16 -0700 (PDT) Message-ID: <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> In-Reply-To: <40F34740.5040100@trash.net> References: <40F34740.5040100@trash.net> Date: Mon, 12 Jul 2004 20:35:16 -0700 (PDT) Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable From: shemminger@osdl.org To: "Patrick McHardy" Cc: "David S. Miller" , netdev@oss.sgi.com, "devik" User-Agent: SquirrelMail/1.4.2-1_osdl_00 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-MIMEDefang-Filter: osdl$Revision: 1.70 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 6924 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 448 Lines: 14 > Hi Dave, > > this patch replaces PSCHED_CLOCK_SOURCE by three new config options > and fixes HTB compilation with CONFIG_NET_SCH_CLK_GETTIMEOFDAY. > Patch compiles with all three options. If you like it I will also send > you a 2.4 version. > > Regards > Patrick > I have a patch (to the original) which replaces the arch dependant CPU stuff with the arch neutral sched_clock() which although slightly slower works on a x86_64 and ia64 as well. From shemminger@osdl.org Mon Jul 12 20:37:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 20:37:38 -0700 (PDT) Received: from fire-2.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D3bZgi014196 for ; Mon, 12 Jul 2004 20:37:35 -0700 Received: from www.osdl.org (fire.osdl.org [65.172.181.4]) by fire-2.osdl.org (8.12.8/8.12.8) with SMTP id i6D3axwr019354; Mon, 12 Jul 2004 20:36:59 -0700 Received: from 63.170.215.71 (SquirrelMail authenticated user shemminger) by www.osdl.org with HTTP; Mon, 12 Jul 2004 20:36:59 -0700 (PDT) Message-ID: <1112.63.170.215.71.1089689819.squirrel@www.osdl.org> In-Reply-To: <20040713030312.50570.qmail@web54102.mail.yahoo.com> References: <1089686376.1044.24.camel@jzny.localdomain> <20040713030312.50570.qmail@web54102.mail.yahoo.com> Date: Mon, 12 Jul 2004 20:36:59 -0700 (PDT) Subject: Re: [RFC] netem - add jitter support. From: shemminger@osdl.org To: "Weiguang Shi" Cc: hadi@cyberus.ca, "netdev linux" User-Agent: SquirrelMail/1.4.2-1_osdl_00 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-MIMEDefang-Filter: osdl$Revision: 1.70 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 6925 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 346 Lines: 14 > Hi Jamal, > > What are the reasons for creating netem instead of using NIST Net? > > Thanks, > Weiguang > > ______________________________________________________________________ > Post your free ad now! http://personals.yahoo.ca > To be brutally honest, because NISTnet is mess and would never make it into the mainline kernel as it stands. From davem@redhat.com Mon Jul 12 20:51:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jul 2004 20:51:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D3pogi014778 for ; Mon, 12 Jul 2004 20:51:51 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6D3pie1028005; Mon, 12 Jul 2004 23:51:44 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6D3pi030708; Mon, 12 Jul 2004 23:51:44 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6D3pBoP012790; Mon, 12 Jul 2004 23:51:11 -0400 Date: Mon, 12 Jul 2004 20:50:37 -0700 From: "David S. Miller" To: shemminger@osdl.org Cc: kaber@trash.net, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040712205037.573411c0.davem@redhat.com> In-Reply-To: <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 509 Lines: 12 On Mon, 12 Jul 2004 20:35:16 -0700 (PDT) shemminger@osdl.org wrote: > I have a patch (to the original) which replaces the arch dependant CPU stuff > with the arch neutral sched_clock() which although slightly > slower works on a x86_64 and ia64 as well. I also want to add sparc64 %tick register support here too. This is an area with a lot of potential cleanup. We should made an asm/pkt_sched.h to abstract out the clock source implementation instead of loading net/pkt_sched.h up with a pile of ifdefs. From pranav@nodeinfotech.com Tue Jul 13 00:34:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 00:34:32 -0700 (PDT) Received: from bband.maa.sify.net (smtp.sifybroadband.com [202.144.76.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6D7YDgi023547 for ; Tue, 13 Jul 2004 00:34:15 -0700 Received: from sachintest (dialpool-210-214-17-134.maa.sify.net [210.214.17.134]) by bband.maa.sify.net (Relay) with SMTP id 34A032E82F; Tue, 13 Jul 2004 13:03:08 +0530 (IST) Reply-To: From: "Pranav" To: "James Kempf" Cc: , , Subject: RE: Problem of Race Condition in IKE implementation on linux system. Date: Tue, 13 Jul 2004 13:03:44 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <00b301c4682c$234af060$536115ac@dcml.docomolabsusa.com> X-archive-position: 6927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pranav@nodeinfotech.com Precedence: bulk X-list: netdev Content-Length: 314 Lines: 12 hi, I am currently working on ike implementation on linux system. i have got a problem starting the ike negotiation,when both the peers start the ike negotiation at the same time,causing race condition.so i need some feedback to overcome this problem. With Regards, pranav jahdav pranav@nodeinfotech.com From hadi@cyberus.ca Tue Jul 13 03:43:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 03:43:10 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6DAh5gi030299 for ; Tue, 13 Jul 2004 03:43:06 -0700 Received: from mx01.cybersurf.com ([IPv6:::ffff:209.197.145.104]:30415 "EHLO mx01.cybersurf.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 11:43:04 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BkKkU-0007hC-KW for netdev@linux-mips.org; Tue, 13 Jul 2004 06:42:58 -0400 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 1BkKkS-0005ts-VC; Tue, 13 Jul 2004 06:42:57 -0400 Subject: Re: [RFC] netem - add jitter support. From: jamal Reply-To: hadi@cyberus.ca To: shemminger@osdl.org Cc: Weiguang Shi , netdev linux In-Reply-To: <1112.63.170.215.71.1089689819.squirrel@www.osdl.org> References: <1089686376.1044.24.camel@jzny.localdomain> <20040713030312.50570.qmail@web54102.mail.yahoo.com> <1112.63.170.215.71.1089689819.squirrel@www.osdl.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089715375.1047.37.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Jul 2004 06:42:55 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 374 Lines: 16 On Mon, 2004-07-12 at 23:36, shemminger@osdl.org wrote: > > What are the reasons for creating netem instead of using NIST Net? > > To be brutally honest, because NISTnet is mess and would never > make it into the mainline kernel as it stands. Violently agree (as someone who attempted this). I am actualy not sure its even properly maintained anymore. cheers, jamal From herbert@gondor.apana.org.au Tue Jul 13 03:49:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 03:49:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6DAnKgi030757 for ; Tue, 13 Jul 2004 03:49:22 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BkKq7-0004Ze-00; Tue, 13 Jul 2004 20:48:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BkKpx-0002fr-00; Tue, 13 Jul 2004 20:48:37 +1000 Date: Tue, 13 Jul 2004 20:48:37 +1000 To: Kazunori Miyazawa Cc: netdev@oss.sgi.com Subject: Re: IPv6 and encapsulation headers Message-ID: <20040713104837.GA9670@gondor.apana.org.au> References: <20040710033209.GA14316@gondor.apana.org.au> <200407121732.52542.kazunori@miyazawa.org> <20040712104710.GC965@gondor.apana.org.au> <200407131042.41346.kazunori@miyazawa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407131042.41346.kazunori@miyazawa.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6929 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1859 Lines: 44 On Tue, Jul 13, 2004 at 10:42:41AM +0900, Kazunori Miyazawa wrote: > > I agree with you. It should uses ip6_find_1stfragopt. > However please consider zero_out_mutable_opts in ah6.c clears second > destination options. We need to get the copy length by other way. > Because ip6_find_1stfragopt returns the insert point of IPsec. Are there situations where it is desirable to have mutable options in the second destination header? Isn't the idea of the second destination header so that it is processed only by the final destination? I would've thought that it only made sense to have immutable options there. In fact if ESP were present then it guarantees the second dest header to be immutable. So perhaps we should simply disallow users from putting mutable options in the second destination header. Or we can document it as undefined and let the user handle the consequences (cf HDRINCL with raw sockets + IPsec). BTW, the current code in ipv6_clear_mutable_options() that deals with NEXTHDR_AUTH is buggy. It assumes that there are at most two AH headers. > > Hmm, what about address spoofing? Is there code in IPv6 to prevent > > another machine from relaying a packet through us with our source > > address? > > Does it concern with IPsec or fragmentation? > It might be netfiler stuff. Well it means that you can't make certain assumptions in the xfrm code. For example, you cannot rely on the ordering of extension headers since the original sender may have applied a different ordering mechanism. But I don't think it poses any security risks to the current xfrm6 code so we can just leave that as undefined behaviour. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dav@neocom.fr Tue Jul 13 05:12:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 05:12:45 -0700 (PDT) Received: from mx03.neocom.fr (mailhub.neocom.fr [82.96.130.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6DCCZgi004049 for ; Tue, 13 Jul 2004 05:12:36 -0700 Received: from mx03.neocom.fr (localhost.localdomain [127.0.0.1]) by localhost.neocom.fr (Postfix) with ESMTP id C24D74C1B7; Tue, 13 Jul 2004 14:15:11 +0200 (CEST) Received: from mailx.neocom.fr (mailx.neocom.fr [82.96.130.2])by mx03.neocom .fr (Postfix) with ESMTPid A90D04C13D; Tue, 13 Jul 2004 14:15:11 +0200 (CES T) Received: by mailx.neocom.fr (Postfix, from userid 502)id B24AC33CC2; Tue, 1 3 Jul 2004 14:10:29 +0200 (CEST) Date: Tue, 13 Jul 2004 14:10:29 +0200 From: David TILLOY To: Andrew Morton Cc: netdev@oss.sgi.com, dav@neocom.fr Subject: Re: Fw: [Bugme-new] [Bug 2782] New: ksoftirqd load system, kernel h anga fter a few minuts Message-ID: <20040713121029.GG2700@mailx.neocom.fr> References: <20040527115311.472d3c3a.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527115311.472d3c3a.akpm@osdl.org> User-Agent: Mutt/1.4i X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:39.41449 C:20 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-archive-position: 6930 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtilloy@neocom.fr Precedence: bulk X-list: netdev Content-Length: 36076 Lines: 755 On Thu, May 27, 2004 at 11:53:11AM -0700, Andrew Morton wrote: > > Suggest you try an up-to-date kernel. Ok, test in progress, and same problem occurs ;-( I'm waiting for packet lost before to submit new informations into ticket, do you want I collect some additional informations before to switch our production traffic on another system ? thx, dav. -- > > Begin forwarded message: > > Date: Thu, 27 May 2004 09:19:49 -0700 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 2782] New: ksoftirqd load system, kernel hang after a few minuts > > > http://bugme.osdl.org/show_bug.cgi?id=2782 > > Summary: ksoftirqd load system, kernel hang after a few minuts > Kernel Version: 2.4.20-2.4.22 > Status: NEW > Severity: blocking > Owner: other_other@kernel-bugs.osdl.org > Submitter: dav@neocom.fr > > > Distribution: Linux/RedHat 9/x86 > Hardware Environment:DELL PowerEdge-Dual Intel Xeon CPU 2.4G+hyperthreading > Software Environment:RedHat 9 > Problem Description:when network flow is near 15 Mb/s bandwith, ksoftirqd loads > and kernel freeze after a few minuts > > Steps to reproduce: > > 1. Boot system, > 2. put linux system into 2 subnets, > 3. generate 15Mb/s bandwith between to interface and wait for 1 hour > > --- additional informations --- > This occurs with a lot of kernel tested (2.4.20, 2.4.21, 2.4.22, 2.4.22-ac4) > and with standard linux RedHat kernel up to kernel-smp-2.4.20-28.9.i686.rpm. > > Datas collected when problem occurs : > > # cat /proc/version > Linux version 2.4.20-8smp (bhcompile@porky.devel.redhat.com) (gcc version 3.2.2 > 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Thu Mar 13 17:45:54 EST 2003 > > # w | head -1 > 22:34:33 up 21 days, 8:04, 3 users, load average: 1.17, 1.02, 0.99 > > # ps axuw > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 1 0.0 0.0 1372 472 ? S Oct07 0:20 init > root 2 0.0 0.0 0 0 ? SW Oct07 0:00 [migration/0] > root 3 0.0 0.0 0 0 ? SW Oct07 0:00 [migration/1] > root 4 0.0 0.0 0 0 ? SW Oct07 0:00 [migration/2] > root 5 0.0 0.0 0 0 ? SW Oct07 0:00 [migration/3] > root 6 0.0 0.0 0 0 ? SW Oct07 0:00 [keventd] > root 7 6.0 0.0 0 0 ? RWN Oct07 1862:18 [ksoftirqd_CPU0] > root 8 0.0 0.0 0 0 ? SWN Oct07 0:00 [ksoftirqd_CPU1] > root 9 0.0 0.0 0 0 ? SWN Oct07 0:00 [ksoftirqd_CPU2] > root 10 0.0 0.0 0 0 ? SWN Oct07 0:00 [ksoftirqd_CPU3] > root 15 0.0 0.0 0 0 ? SW Oct07 0:00 [bdflush] > root 11 0.0 0.0 0 0 ? SW Oct07 0:11 [kswapd] > root 12 0.0 0.0 0 0 ? SW Oct07 0:00 [kscand/DMA] > root 13 0.0 0.0 0 0 ? SW Oct07 4:43 [kscand/Normal] > root 14 0.0 0.0 0 0 ? SW Oct07 5:47 [kscand/HighMem] > root 16 0.0 0.0 0 0 ? SW Oct07 0:05 [kupdated] > root 17 0.0 0.0 0 0 ? SW Oct07 0:00 [mdrecoveryd] > root 23 0.0 0.0 0 0 ? SW Oct07 0:00 [aacraid] > root 24 0.0 0.0 0 0 ? SW Oct07 0:00 [scsi_eh_0] > root 27 0.0 0.0 0 0 ? SW Oct07 0:02 [kjournald] > root 84 0.0 0.0 0 0 ? SW Oct07 0:00 [khubd] > root 642 0.0 0.0 0 0 ? SW Oct07 0:00 [kjournald] > root 643 0.0 0.0 0 0 ? SW Oct07 0:13 [kjournald] > root 1210 0.0 0.0 1448 588 ? S Oct07 0:09 syslogd -m 0 > root 1214 0.0 0.0 1368 428 ? S Oct07 0:00 klogd -x > root 1266 0.0 0.1 3580 1396 ? S Oct07 0:02 /usr/sbin/sshd > .../... > > When system is loaded (by process ksoftirq_CPU0), some datas are lost > (monitorring system reports > each 10 minuts CRITICAL alerts => 50% of warning report for packet lost). > > report trafic when this issue occurs is like this : > .../... > eth5|Recv: 2.169G|Sent: 1.591G|Recv Speed: 1.25Kb/s|Sent speed: 1.03Mb/s| > eth5|Recv: 2.169G|Sent: 1.594G|Recv Speed: 0b/s|Sent speed: 776.96Kb/s| > eth5|Recv: 2.169G|Sent: 1.596G|Recv Speed: 1.75Kb/s|Sent speed: 958.87Kb/s| > eth5|Recv: 2.169G|Sent: 1.599G|Recv Speed: 939b/s|Sent speed: 978.17Kb/s| > eth5|Recv: 2.169G|Sent: 1.603G|Recv Speed: 640b/s|Sent speed:1009.87Kb/s| > eth5|Recv: 2.169G|Sent: 1.607G|Recv Speed: 85b/s|Sent speed: 1.29Mb/s| > eth5|Recv: 2.169G|Sent: 1.611G|Recv Speed: 853b/s|Sent speed: 1.28Mb/s| > eth5|Recv: 2.169G|Sent: 1.615G|Recv Speed: 0b/s|Sent speed: 1.68Mb/s| > .../... > > And we can see : > > # cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 0: 184391788 0 0 0 IO-APIC-edge timer > 1: 953 0 0 0 IO-APIC-edge keyboard > 2: 0 0 0 0 XT-PIC cascade > 5: 0 0 0 0 IO-APIC-level usb-ohci > 8: 1 0 0 0 IO-APIC-edge rtc > 14: 2 0 0 0 IO-APIC-edge ide0 > 16: 6640100 0 0 0 IO-APIC-level eth0 > 20: 2347915 0 0 0 IO-APIC-level eth2 > 21: 3242586 0 0 0 IO-APIC-level eth3 > 28: 1362515262 0 0 0 IO-APIC-level eth4 > 29: 1127825818 0 0 0 IO-APIC-level eth5 > 30: 831193 0 0 0 IO-APIC-level aacraid > NMI: 0 0 0 0 > LOC: 184394043 184394090 184394090 184394089 > ERR: 0 > MIS: 0 > > .../... > > eth4 Link encap:Ethernet HWaddr 00:06:5B:F3:61:5F > inet addr:192.168.20.245 Bcast:192.168.20.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:2184189475 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2195331 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:717500525 (684.2 Mb) TX bytes:153729558 (146.6 Mb) > Interrupt:28 > > eth5 Link encap:Ethernet HWaddr 00:06:5B:F3:61:60 > inet addr:194.xxx.xxx.248 Bcast:194.xxx.xxx.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:26145681 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2205082845 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:2328890724 (2221.0 Mb) TX bytes:1860452584 (1774.2 Mb) > Interrupt:29 > > # cat /proc/modules > tg3 52904 2 > e100 62340 3 > ipt_LOG 4280 0 (autoclean) > ipt_limit 1688 0 (autoclean) > ipt_REJECT 3928 0 (autoclean) > iptable_mangle 2776 0 (autoclean) (unused) > ipt_state 1080 0 (autoclean) > iptable_nat 22904 0 (autoclean) > ip_conntrack 29696 2 (autoclean) [ipt_state iptable_nat] > iptable_filter 2412 0 (autoclean) > ip_tables 15864 9 [ipt_LOG ipt_limit ipt_REJECT iptable_mangle > ipt_state iptable_nat iptable_filter] > keybdev 2976 0 (unused) > mousedev 5656 0 (unused) > hid 22308 0 (unused) > input 6208 0 [keybdev mousedev hid] > usb-ohci 22216 0 (unused) > usbcore 82592 1 [hid usb-ohci] > ext3 73376 3 > jbd 56336 3 [ext3] > aacraid 32580 4 > sd_mod 13452 8 > scsi_mod 110488 2 [aacraid sd_mod] > # cat /proc/ioports > 0000-001f : dma1 > 0020-003f : pic1 > 0040-005f : timer > 0060-006f : keyboard > 0070-007f : rtc > 0080-008f : dma page reg > 00a0-00bf : pic2 > 00c0-00df : dma2 > 00f0-00ff : fpu > 01f0-01f7 : ide0 > 02f8-02ff : serial(auto) > 03c0-03df : vga+ > 03f6-03f6 : ide0 > 03f8-03ff : serial(auto) > 08b0-08bf : ServerWorks CSB5 IDE Controller > 08b0-08b7 : ide0 > 08b8-08bf : ide1 > 0cf8-0cff : PCI conf1 > 9000-9fff : PCI Bus #07 > 9800-98ff : Adaptec RAID subsystem HBA (#2) > 9c00-9cff : Adaptec RAID subsystem HBA > c000-cfff : PCI Bus #03 > ccc0-ccdf : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#4) > ccc0-ccdf : e100 > cce0-ccff : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#3) > cce0-ccff : e100 > d000-dfff : PCI Bus #02 > dcc0-dcdf : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#2) > dcc0-dcdf : e100 > dce0-dcff : Intel Corp. 82557/8/9 [Ethernet Pro 100] > dce0-dcff : e100 > e800-e8ff : ATI Technologies Inc Rage XL > ec80-ecbf : Dell Computer Corporation PowerEdge Expandable RAID Controller 3/Di > ece8-ecef : Dell Computer Corporation Embedded Systems Management Device 4 > ecf4-ecf7 : PCI device 1028:000d (Dell Computer Corporation) > ecf8-ecff : Dell Computer Corporation Embedded Systems Management Device 4 > > # cat /proc/iomem > 00000000-0009ffff : System RAM > 000a0000-000bffff : Video RAM area > 000c0000-000c7fff : Video ROM > 000cc000-000cc5ff : Extension ROM > 000f0000-000fffff : System ROM > 00100000-3ffeffff : System RAM > 00100000-002720eb : Kernel code > 002720ec-00383ba3 : Kernel data > 3fff0000-3fffebff : ACPI Tables > 3fffec00-3fffefff : reserved > f0000000-f7ffffff : Dell Computer Corporation PowerEdge Expandable RAID > Controller 3 > fc300000-fc4fffff : PCI Bus #07 > fc3fe000-fc3fefff : Adaptec RAID subsystem HBA (#2) > fc3ff000-fc3fffff : Adaptec RAID subsystem HBA > fc600000-fc60ffff : Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (#2) > fc600000-fc60ffff : tg3 > fc610000-fc61ffff : Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet > fc610000-fc61ffff : tg3 > fc700000-fc7fffff : PCI Bus #03 > fc7fe000-fc7fefff : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#4) > fc7fe000-fc7fefff : e100 > fc7ff000-fc7fffff : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#3) > fc7ff000-fc7fffff : e100 > fc800000-fc8fffff : PCI Bus #02 > fc8fe000-fc8fefff : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#2) > fc8fe000-fc8fefff : e100 > fc8ff000-fc8fffff : Intel Corp. 82557/8/9 [Ethernet Pro 100] > fc8ff000-fc8fffff : e100 > fca00000-fccfffff : PCI Bus #03 > fca00000-fcafffff : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#4) > fca00000-fcafffff : e100 > fcb00000-fcbfffff : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#3) > fcb00000-fcbfffff : e100 > fcd00000-fcffffff : PCI Bus #02 > fcd00000-fcdfffff : Intel Corp. 82557/8/9 [Ethernet Pro 100] (#2) > fcd00000-fcdfffff : e100 > fce00000-fcefffff : Intel Corp. 82557/8/9 [Ethernet Pro 100] > fce00000-fcefffff : e100 > fd000000-fdffffff : ATI Technologies Inc Rage XL > fe100000-fe100fff : ServerWorks OSB4/CSB5 OHCI USB Controller > fe100000-fe100fff : usb-ohci > fe101000-fe101fff : ATI Technologies Inc Rage XL > fe102000-fe102fff : Dell Computer Corporation PowerEdge Expandable RAID > Controller 3/Di > feb00000-feb7ffff : Dell Computer Corporation PowerEdge Expandable RAID > Controller 3/Di > feb80000-feb80fff : Dell Computer Corporation Embedded Systems Management > Device 4 > fec00000-fec0ffff : reserved > fee00000-fee0ffff : reserved > fff80000-ffffffff : reserved > > 00:00.0 Host bridge: ServerWorks CMIC-LE (rev 13) > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:00.1 Host bridge: ServerWorks CMIC-LE > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:00.2 Host bridge: ServerWorks: Unknown device 0000 > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:04.0 Class ff00: Dell Computer Corporation Embedded Systems Management > Device 4 > Subsystem: Dell Computer Corporation Embedded Systems Management Device > 4 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32, cache line size 10 > Interrupt: pin A routed to IRQ 19 > Region 0: Memory at feb80000 (32-bit, prefetchable) [size=4K] > Region 1: I/O ports at ecf8 [size=8] > Region 2: I/O ports at ece8 [size=8] > Expansion ROM at fe000000 [disabled] [size=64K] > Capabilities: [48] 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:04.1 Class ff00: Dell Computer Corporation PowerEdge Expandable RAID > Controller 3/Di > Subsystem: Dell Computer Corporation PowerEdge Expandable RAID > Controller 3/Di > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Interrupt: pin B routed to IRQ 23 > Region 0: Memory at fe102000 (32-bit, non-prefetchable) [size=4K] > Region 1: I/O ports at ec80 [size=64] > Region 2: Memory at feb00000 (32-bit, prefetchable) [size=512K] > Capabilities: [48] 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:04.2 Class 0c07: Dell Computer Corporation: Unknown device 000d > Subsystem: Dell Computer Corporation: Unknown device 000d > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Interrupt: pin C routed to IRQ 27 > Region 0: I/O ports at ecf4 [size=4] > Capabilities: [48] 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:0e.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) (prog- > if 00 [VGA]) > Subsystem: Dell Computer Corporation: Unknown device 0121 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ ParErr- > Stepping+ SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (2000ns min), cache line size 10 > Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M] > Region 1: I/O ports at e800 [size=256] > Region 2: Memory at fe101000 (32-bit, non-prefetchable) [size=4K] > Expansion ROM at [disabled] [size=128K] > Capabilities: [5c] 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:0f.0 Host bridge: ServerWorks CSB5 South Bridge (rev 93) > Subsystem: ServerWorks CSB5 South Bridge > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 > 00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93) (prog-if 82 > [Master PriP]) > Subsystem: ServerWorks CSB5 IDE Controller > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 > Region 0: I/O ports at > Region 1: I/O ports at > Region 2: I/O ports at > Region 3: I/O ports at > Region 4: I/O ports at 08b0 [size=16] > 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05) > (prog-if 10 [OHCI]) > Subsystem: ServerWorks OSB4/CSB5 OHCI USB Controller > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (20000ns max) > Interrupt: pin A routed to IRQ 5 > Region 0: Memory at fe100000 (32-bit, non-prefetchable) [size=4K] > 00:0f.3 ISA bridge: ServerWorks GCLE Host Bridge > Subsystem: ServerWorks: Unknown device 0230 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > 00:10.0 Host bridge: ServerWorks: Unknown device 0101 (rev 03) > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Capabilities: [60] PCI-X non-bridge device. > Command: DPERE- ERO- RBC=0 OST=4 > Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, > DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- > 00:10.2 Host bridge: ServerWorks: Unknown device 0101 (rev 03) > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Capabilities: [60] PCI-X non-bridge device. > Command: DPERE- ERO- RBC=0 OST=4 > Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, > DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- > 00:11.0 Host bridge: ServerWorks: Unknown device 0101 (rev 03) > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Capabilities: [60] PCI-X non-bridge device. > Command: DPERE- ERO- RBC=0 OST=4 > Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, > DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- > 00:11.2 Host bridge: ServerWorks: Unknown device 0101 (rev 03) > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Capabilities: [60] PCI-X non-bridge device. > Command: DPERE- ERO- RBC=0 OST=4 > Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, > DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- > 01:06.0 PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (prog-if 00 [Normal > decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32, cache line size 10 > Bus: primary=01, secondary=02, subordinate=02, sec-latency=32 > I/O behind bridge: 0000d000-0000dfff > Memory behind bridge: fcd00000-fcffffff > Prefetchable memory behind bridge: 00000000fc800000-00000000fc800000 > BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [dc] 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- > Bridge: PM- B3+ > 01:08.0 PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (prog-if 00 [Normal > decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32, cache line size 10 > Bus: primary=01, secondary=03, subordinate=03, sec-latency=32 > I/O behind bridge: 0000c000-0000cfff > Memory behind bridge: fca00000-fccfffff > Prefetchable memory behind bridge: 00000000fc700000-00000000fc700000 > BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [dc] 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- > Bridge: PM- B3+ > 02:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05) > Subsystem: Intel Corp. EtherExpress PRO/100+ Dual Port Adapter > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 (2000ns min, 14000ns max), cache line size 10 > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at fc8ff000 (32-bit, prefetchable) [size=4K] > Region 1: I/O ports at dce0 [size=32] > Region 2: Memory at fce00000 (32-bit, non-prefetchable) [size=1M] > Capabilities: [dc] Power Management version 1 > Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME > (D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 02:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05) > Subsystem: Intel Corp. EtherExpress PRO/100+ Dual Port Adapter > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 (2000ns min, 14000ns max), cache line size 10 > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at fc8fe000 (32-bit, prefetchable) [size=4K] > Region 1: I/O ports at dcc0 [size=32] > Region 2: Memory at fcd00000 (32-bit, non-prefetchable) [size=1M] > Capabilities: [dc] Power Management version 1 > Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME > (D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 03:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05) > Subsystem: Intel Corp. EtherExpress PRO/100+ Dual Port Adapter > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 (2000ns min, 14000ns max), cache line size 10 > Interrupt: pin A routed to IRQ 20 > Region 0: Memory at fc7ff000 (32-bit, prefetchable) [size=4K] > Region 1: I/O ports at cce0 [size=32] > Region 2: Memory at fcb00000 (32-bit, non-prefetchable) [size=1M] > Capabilities: [dc] Power Management version 1 > Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME > (D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 03:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05) > Subsystem: Intel Corp. EtherExpress PRO/100+ Dual Port Adapter > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 (2000ns min, 14000ns max), cache line size 10 > Interrupt: pin A routed to IRQ 21 > Region 0: Memory at fc7fe000 (32-bit, prefetchable) [size=4K] > Region 1: I/O ports at ccc0 [size=32] > Region 2: Memory at fca00000 (32-bit, non-prefetchable) [size=1M] > Capabilities: [dc] Power Management version 1 > Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME > (D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 05:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit > Ethernet (rev 15) > Subsystem: Dell Computer Corporation Broadcom BCM5701 1000Base-T > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 (16000ns min), cache line size 10 > Interrupt: pin A routed to IRQ 28 > Region 0: Memory at fc610000 (64-bit, non-prefetchable) [size=64K] > Capabilities: [40] PCI-X non-bridge device. > Command: DPERE- ERO- RBC=0 OST=0 > Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, > DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- Capabilities: [48] Power Management > version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2- > ,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=1 PME- > Capabilities: [50] Vital Product Data > Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 > Enable- > Address: 52f48734a4062484 Data: c906 > 05:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit > Ethernet (rev 15) > Subsystem: Dell Computer Corporation Broadcom BCM5701 1000Base-T > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 (16000ns min), cache line size 10 > Interrupt: pin A routed to IRQ 29 > Region 0: Memory at fc600000 (64-bit, non-prefetchable) [size=64K] > Capabilities: [40] PCI-X non-bridge device. > Command: DPERE- ERO- RBC=0 OST=0 > Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, > DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- Capabilities: [48] Power Management > version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2- > ,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=1 PME- > Capabilities: [50] Vital Product Data > Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 > Enable- > Address: d616aa75c6ef8af0 Data: 80a0 > 06:08.0 PCI bridge: Intel Corp.: Unknown device 0309 (rev 01) (prog-if 00 > [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- SERR- Latency: 32, cache line size 10 > Bus: primary=06, secondary=07, subordinate=07, sec-latency=32 > I/O behind bridge: 00009000-00009fff > Memory behind bridge: fc300000-fc4fffff > Prefetchable memory behind bridge: fff00000-000fffff > BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [68] 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- > 06:08.1 RAID bus controller: Dell Computer Corporation PowerEdge Expandable > RAID Controller 3 (rev 01) > Subsystem: Dell Computer Corporation PowerEdge Expandable RAID > Controller 3/Di > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- SERR- Latency: 32, cache line size 10 > Interrupt: pin A routed to IRQ 30 > Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M] > Expansion ROM at fc200000 [disabled] [size=64K] > 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- > 07:06.0 SCSI storage controller: Adaptec RAID subsystem HBA (rev 01) > Subsystem: Dell Computer Corporation PowerEdge 2550 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (10000ns min, 6250ns max), cache line size 10 > Interrupt: pin A routed to IRQ 30 > BIST result: 00 > Region 0: I/O ports at 9c00 [size=256] > Region 1: Memory at fc3ff000 (64-bit, non-prefetchable) [size=4K] > Expansion ROM at fc400000 [disabled] [size=128K] > Capabilities: [dc] 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- > 07:06.1 SCSI storage controller: Adaptec RAID subsystem HBA (rev 01) > Subsystem: Dell Computer Corporation PowerEdge 2550 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (10000ns min, 6250ns max), cache line size 10 > Interrupt: pin B routed to IRQ 31 > BIST result: 00 > Region 0: I/O ports at 9800 [size=256] > Region 1: Memory at fc3fe000 (64-bit, non-prefetchable) [size=4K] > Expansion ROM at fc400000 [disabled] [size=128K] > Capabilities: [dc] 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- > > > # cat /proc/scsi/scsi > Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: DELL Model: PERCRAID RAID10 Rev: V1.0 > Type: Direct-Access ANSI SCSI revision: 02 > > # cat /proc/net/netstat > TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts > PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW > TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab DelayedACKs > DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops TCPPrequeued > TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue TCPPrequeueDropped TCPHPHits > TCPHPHitsToUser TCPPureAcks TCPHPAcks TCPRenoRecovery TCPSackRecovery > TCPSACKReneging TCPFACKReorder TCPSACKReorder TCPRenoReorder TCPTSReorder > TCPFullUndo TCPPartialUndo TCPDSACKUndo TCPLossUndo TCPLoss TCPLostRetransmit > TCPRenoFailures TCPSackFailures TCPLossFailures TCPFastRetrans > TCPForwardRetrans TCPSlowStartRetrans TCPTimeouts TCPRenoRecoveryFail > TCPSackRecoveryFail TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent > TCPDSACKOfoSent TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnSyn TCPAbortOnData > TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger > TCPAbortFailed TCPMemoryPressures > TcpExt: 0 0 0 23 0 0 0 0 0 0 5 0 0 0 0 0 17865 1 12 0 0 8574 0 9 0 197814 0 > 458166 187419 0 77 0 0 0 0 0 0 0 0 3 41 0 0 38 0 89 0 42 118 0 13 0 0 39 0 3 0 > 0 4 1 0 0 0 0 0 > > > # sh ver_linux > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > Linux FW2 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST 2003 i686 i686 i386 > GNU/Linux > Gnu C 18: > Gnu make 3.79.1 > util-linux 2.11y > mount 2.11y > modutils 2.4.22 > e2fsprogs 1.32 > Linux C Library 2.3.2 > Dynamic linker (ldd) 2.3.2 > Procps 2.0.11 > Net-tools 1.60 > Kbd 1.08 > Sh-utils 4.5.3 > Modules Loaded tg3 e100 ipt_LOG ipt_limit ipt_REJECT iptable_mangle > ipt_state iptable_nat ip_conntrack iptable_filter ip_tables keybdev mousedev > hid input usb-ohci usbcore ext3 jbd aacraid sd_mod scsi_mod > > # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Xeon(TM) CPU 2.40GHz > stepping : 7 > cpu MHz : 2392.327 > cache size : 512 KB > physical id : 0 > siblings : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > bogomips : 4771.02 > processor : 1 > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Xeon(TM) CPU 2.40GHz > stepping : 7 > cpu MHz : 2392.327 > cache size : 512 KB > physical id : 0 > siblings : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > bogomips : 4784.12 > processor : 2 > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Xeon(TM) CPU 2.40GHz > stepping : 7 > cpu MHz : 2392.327 > cache size : 512 KB > physical id : 3 > siblings : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > bogomips : 4784.12 > processor : 3 > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Xeon(TM) CPU 2.40GHz > stepping : 7 > cpu MHz : 2392.327 > cache size : 512 KB > physical id : 3 > siblings : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > bogomips : 4784.12 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. -- David TILLOY. Directeur Technique. NEOCOM MULTIMEDIA. Tel. 01.45.15.2000 - Fax. 01.45.15.2001 - 14, rue Jules VANZUPPE. 94854 IVRY SUR SEINE CEDEX. FRANCE From shemminger@osdl.org Tue Jul 13 09:16:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 09:16:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6DGGNgi021084 for ; Tue, 13 Jul 2004 09:16:26 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6DGG6k13709; Tue, 13 Jul 2004 09:16:06 -0700 Date: Tue, 13 Jul 2004 09:16:06 -0700 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com, devik Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040713091606.36f75611@dell_ss3.pdx.osdl.net> In-Reply-To: <40F34740.5040100@trash.net> References: <40F34740.5040100@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6931 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 5689 Lines: 198 Here is the patch I have been testing against 2.6.8-rc1 to use sched_clock. diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-07-12 11:06:52 -07:00 +++ b/include/net/pkt_sched.h 2004-07-12 11:06:52 -07:00 @@ -16,11 +16,6 @@ #include #include -#ifdef CONFIG_X86_TSC -#include -#endif - - struct rtattr; struct Qdisc; @@ -179,16 +174,19 @@ clock evaluated by integration of network data flow in the most critical places. - Note: we do not use fastgettimeofday. - The reason is that, when it is not the same thing as - gettimeofday, it returns invalid timestamp, which is - not updated, when net_bh is active. - - So, use PSCHED_CLOCK_SOURCE = PSCHED_CPU on alpha and pentiums - with rtdsc. And PSCHED_JIFFIES on all other architectures, including [34]86 - and pentiums without rtdsc. - You can use PSCHED_GETTIMEOFDAY on another architectures, - which have fast and precise clock source, but it is too expensive. + The problem is that there are kernel interfaces that provide: + + - high resolution (us or better) + - fast to read (minimal locking, no i/o access) + - synchronized on all processors and all architectures + - handles cpu clock frequency changes + + but no interface provides all of the above. By default + the current choice is to use PSCHED_JIFFIES because it is fast + to read, synchronized, and stable with frequency changes + + You can use PSCHED_CPU which maps to sched_clock on architectures + that have synchronized clocks. */ /* General note about internal clock. @@ -237,39 +235,12 @@ #elif PSCHED_CLOCK_SOURCE == PSCHED_CPU -extern psched_tdiff_t psched_clock_per_hz; -extern int psched_clock_scale; - -#define PSCHED_US2JIFFIE(delay) (((delay)+psched_clock_per_hz-1)/psched_clock_per_hz) -#define PSCHED_JIFFIE2US(delay) ((delay)*psched_clock_per_hz) - -#ifdef CONFIG_X86_TSC - -#define PSCHED_GET_TIME(stamp) \ -({ u64 __cur; \ - rdtscll(__cur); \ - (stamp) = __cur>>psched_clock_scale; \ -}) - -#elif defined (__alpha__) - -#define PSCHED_WATCHER u32 - -extern PSCHED_WATCHER psched_time_mark; - -#define PSCHED_GET_TIME(stamp) \ -({ u32 __res; \ - __asm__ __volatile__ ("rpcc %0" : "r="(__res)); \ - if (__res <= psched_time_mark) psched_time_base += 0x100000000UL; \ - psched_time_mark = __res; \ - (stamp) = (psched_time_base + __res)>>psched_clock_scale; \ -}) +extern unsigned long long sched_clock(void); -#else - -#error PSCHED_CLOCK_SOURCE=PSCHED_CPU is not supported on this arch. - -#endif /* ARCH */ +#define PSCHED_GET_TIME(stamp) \ + do { (stamp) = sched_clock(); do_div(stamp, 1000); } while(0) +#define PSCHED_US2JIFFIE(usecs) (((usecs)+(1000000/HZ-1))/(1000000/HZ)) +#define PSCHED_JIFFIE2US(delay)((delay)*(1000000/HZ)) #endif /* PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES */ @@ -496,7 +467,7 @@ /* Calculate maximal size of packet seen by hard_start_xmit routine of this device. */ -static inline unsigned psched_mtu(struct net_device *dev) +static inline unsigned psched_mtu(const struct net_device *dev) { unsigned mtu = dev->mtu; return dev->hard_header ? mtu + dev->hard_header_len : mtu; diff -Nru a/net/sched/sch_api.c b/net/sched/sch_api.c --- a/net/sched/sch_api.c 2004-07-12 11:06:52 -07:00 +++ b/net/sched/sch_api.c 2004-07-12 11:06:52 -07:00 @@ -1101,91 +1101,17 @@ EXPORT_SYMBOL(psched_tod_diff); #endif -psched_time_t psched_time_base; - -#if PSCHED_CLOCK_SOURCE == PSCHED_CPU -psched_tdiff_t psched_clock_per_hz; -int psched_clock_scale; -EXPORT_SYMBOL(psched_clock_per_hz); -EXPORT_SYMBOL(psched_clock_scale); -#endif - -#ifdef PSCHED_WATCHER -PSCHED_WATCHER psched_time_mark; -EXPORT_SYMBOL(psched_time_mark); -EXPORT_SYMBOL(psched_time_base); - -static void psched_tick(unsigned long); - -static struct timer_list psched_timer = TIMER_INITIALIZER(psched_tick, 0, 0); - -static void psched_tick(unsigned long dummy) -{ -#if PSCHED_CLOCK_SOURCE == PSCHED_CPU - psched_time_t dummy_stamp; - PSCHED_GET_TIME(dummy_stamp); - /* It is OK up to 4GHz cpu */ - psched_timer.expires = jiffies + 1*HZ; -#else - unsigned long now = jiffies; - psched_time_base += ((u64)(now-psched_time_mark))< delay) - return -1; - delay /= rdelay; - psched_tick_per_us = delay; - while ((delay>>=1) != 0) - psched_clock_scale++; - psched_us_per_tick = 1<>psched_clock_scale; - return 0; -} +EXPORT_SYMBOL(sched_clock); #endif static int __init pktsched_init(void) { struct rtnetlink_link *link_p; -#if PSCHED_CLOCK_SOURCE == PSCHED_CPU - if (psched_calibrate_clock() < 0) - return -1; -#elif PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES +#if PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES psched_tick_per_us = HZ<; Tue, 13 Jul 2004 10:10:55 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6DH9uk15014; Tue, 13 Jul 2004 10:09:57 -0700 Date: Tue, 13 Jul 2004 10:09:56 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] irlmp warnings. Message-Id: <20040713100956.66ff796f@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6932 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 945 Lines: 32 Get rid of sparse warnings about 0 vs NULL. in irlmp. Signed-off-by: Stephen Hemminger diff -Nru a/net/irda/irlmp.c b/net/irda/irlmp.c --- a/net/irda/irlmp.c 2004-07-13 10:05:18 -07:00 +++ b/net/irda/irlmp.c 2004-07-13 10:05:18 -07:00 @@ -1491,7 +1491,7 @@ service = kmalloc(sizeof(irlmp_service_t), GFP_ATOMIC); if (!service) { IRDA_DEBUG(1, "%s(), Unable to kmalloc!\n", __FUNCTION__); - return 0; + return NULL; } service->hints.word = hints; hashbin_insert(irlmp->services, (irda_queue_t *) service, @@ -1561,13 +1561,13 @@ irlmp_client_t *client; IRDA_DEBUG(1, "%s()\n", __FUNCTION__); - ASSERT(irlmp != NULL, return 0;); + ASSERT(irlmp != NULL, return NULL;); /* Make a new registration */ client = kmalloc(sizeof(irlmp_client_t), GFP_ATOMIC); if (!client) { IRDA_DEBUG( 1, "%s(), Unable to kmalloc!\n", __FUNCTION__); - return 0; + return NULL; } /* Register the details */ From shemminger@osdl.org Tue Jul 13 11:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 11:24:13 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6DIO1gi006789 for ; Tue, 13 Jul 2004 11:24:02 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6DINek17785; Tue, 13 Jul 2004 11:23:40 -0700 Date: Tue, 13 Jul 2004 11:23:40 -0700 From: Stephen Hemminger To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] af_inet6 -- 0 vs NULL Message-Id: <20040713112340.58712804@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1224 Lines: 24 Sparse complains about 0 vs NULL here. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c 2004-07-13 10:07:04 -07:00 +++ b/net/ipv6/af_inet6.c 2004-07-13 10:07:04 -07:00 @@ -719,13 +719,13 @@ /* allocate our sock slab caches */ tcp6_sk_cachep = kmem_cache_create("tcp6_sock", sizeof(struct tcp6_sock), 0, - SLAB_HWCACHE_ALIGN, 0, 0); + SLAB_HWCACHE_ALIGN, NULL, NULL); udp6_sk_cachep = kmem_cache_create("udp6_sock", sizeof(struct udp6_sock), 0, - SLAB_HWCACHE_ALIGN, 0, 0); + SLAB_HWCACHE_ALIGN, NULL, NULL); raw6_sk_cachep = kmem_cache_create("raw6_sock", sizeof(struct raw6_sock), 0, - SLAB_HWCACHE_ALIGN, 0, 0); + SLAB_HWCACHE_ALIGN, NULL, NULL); if (!tcp6_sk_cachep || !udp6_sk_cachep || !raw6_sk_cachep) printk(KERN_CRIT "%s: Can't create protocol sock SLAB " "caches!\n", __FUNCTION__); From shemminger@osdl.org Tue Jul 13 11:25:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 11:25:34 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i6DIPXgi007229 for ; Tue, 13 Jul 2004 11:25:33 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6DIPFk20154; Tue, 13 Jul 2004 11:25:15 -0700 Date: Tue, 13 Jul 2004 11:25:15 -0700 From: Stephen Hemminger To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [sparse] ipv6 -- more 0 vs NULL Message-Id: <20040713112515.51665b9b@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1666 Lines: 68 More sparse complaints about 0 vs. NULL diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c 2004-07-13 11:22:18 -07:00 +++ b/net/ipv6/ip6_output.c 2004-07-13 11:22:18 -07:00 @@ -561,7 +561,7 @@ err = 0; offset = 0; frag = skb_shinfo(skb)->frag_list; - skb_shinfo(skb)->frag_list = 0; + skb_shinfo(skb)->frag_list = NULL; /* BUILD HEADER */ tmp_hdr = kmalloc(hlen, GFP_ATOMIC); @@ -789,7 +789,7 @@ err = ipv6_get_saddr(*dst, &fl->fl6_dst, &fl->fl6_src); if (err) { -#if IP6_DEBUG >= 2 +#if defined(IP6_DEBUG) && IP6_DEBUG >= 2 printk(KERN_DEBUG "ip6_dst_lookup: " "no available source address\n"); #endif diff -Nru a/net/ipv6/mcast.c b/net/ipv6/mcast.c --- a/net/ipv6/mcast.c 2004-07-13 11:22:18 -07:00 +++ b/net/ipv6/mcast.c 2004-07-13 11:22:18 -07:00 @@ -210,7 +210,7 @@ mc_lst->ifindex = dev->ifindex; mc_lst->sfmode = MCAST_EXCLUDE; - mc_lst->sflist = 0; + mc_lst->sflist = NULL; /* * now add/increase the group membership on the device @@ -272,8 +272,8 @@ struct inet6_dev *ip6_mc_find_dev(struct in6_addr *group, int ifindex) { - struct net_device *dev = 0; - struct inet6_dev *idev = 0; + struct net_device *dev = NULL; + struct inet6_dev *idev = NULL; if (ifindex == 0) { struct rt6_info *rt; @@ -288,18 +288,18 @@ dev = dev_get_by_index(ifindex); if (!dev) - return 0; + return NULL; idev = in6_dev_get(dev); if (!idev) { dev_put(dev); - return 0; + return NULL; } read_lock_bh(&idev->lock); if (idev->dead) { read_unlock_bh(&idev->lock); in6_dev_put(idev); dev_put(dev); - return 0; + return NULL; } return idev; } From shemminger@osdl.org Tue Jul 13 15:20:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 15:20:18 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.13.0) with SMTP id i6DMKBHY014981 for ; Tue, 13 Jul 2004 15:20:14 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6DMJxk28954; Tue, 13 Jul 2004 15:19:59 -0700 Date: Tue, 13 Jul 2004 15:19:59 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] netem -- Message-Id: <20040713151959.2470a211@dell_ss3.pdx.osdl.net> In-Reply-To: <20040712101500.4a0babd3@dell_ss3.pdx.osdl.net> References: <20040712101500.4a0babd3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6935 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 895 Lines: 31 The netem scheduler needs to limit its delayed packet queue to prevent a application burst from chewing up too much memory. Signed-off-by: Stephen Hemminger diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2004-07-13 13:02:58 -07:00 +++ b/net/sched/sch_netem.c 2004-07-13 13:02:58 -07:00 @@ -643,11 +643,17 @@ PSCHED_TADD2(now, delay, cb->time_to_send); /* Always queue at tail to keep packets in order */ - __skb_queue_tail(&q->delayed, skb); - sch->q.qlen++; - sch->stats.bytes += skb->len; - sch->stats.packets++; - return 0; + if (likely(q->delayed.qlen < q->limit)) { + __skb_queue_tail(&q->delayed, skb); + sch->q.qlen++; + sch->stats.bytes += skb->len; + sch->stats.packets++; + return 0; + } + + sch->stats.drops++; + kfree_skb(skb); + return NET_XMIT_DROP; } /* Requeue packets but don't change time stamp */ From kaber@trash.net Tue Jul 13 18:02:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 18:02:58 -0700 (PDT) Received: from gw.localnet ([195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6E12rnP020604 for ; Tue, 13 Jul 2004 18:02:53 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BkYDD-0003sM-00; Wed, 14 Jul 2004 03:05:31 +0200 Message-ID: <40F4862D.3070802@trash.net> Date: Wed, 14 Jul 2004 03:02:37 +0200 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: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> In-Reply-To: <20040712205037.573411c0.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 869 Lines: 39 David S. Miller wrote: > > I also want to add sparc64 %tick register support here too. > This is an area with a lot of potential cleanup. We should > made an asm/pkt_sched.h to abstract out the clock source > implementation instead of loading net/pkt_sched.h up with > a pile of ifdefs. > Couldn't we just use get_cycles() ? Something like this: #include #if sizeof(cycles_t) == sizeof(u64) #define PSCHED_GET_TIME(stamp) \ do { \ u64 cur = get_cycles(); \ stamp) = cur >> psched_clock_scale; \ } while (0) #else #define PSCHED_WATCHER u32 extern PSCHED_WATCHER psched_time_mark; #define PSCHED_GET_TIME(stamp) \ do { \ u32 cur = get_cycles(); \ if (cur <= psched_time_mark) \ psched_time_base += 0x100000000UL; \ psched_time_mark = cur; \ (stamp) = (psched_time_base + cur) >> psched_clock_scale; \ } while (0) #endif Regards Patrick From kaber@trash.net Tue Jul 13 20:34:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 20:34:44 -0700 (PDT) Received: from gw.localnet ([195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6E3YaLB010197 for ; Tue, 13 Jul 2004 20:34:36 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BkaZx-0007CM-00; Wed, 14 Jul 2004 05:37:09 +0200 Message-ID: <40F4A9EF.1010802@trash.net> Date: Wed, 14 Jul 2004 05:35:11 +0200 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: "David S. Miller" CC: netdev Subject: [PATCH 2.6]: Remove dead timer code from sch_api.c Content-Type: multipart/mixed; boundary="------------030508000201000907050805" X-archive-position: 6937 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3018 Lines: 110 This is a multi-part message in MIME format. --------------030508000201000907050805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit With Stephen's recent changes to use get_jiffies_64 for PSCHED_JIFFIES PSCHED_WATCHER is no longer defined for PSCHED_JIFFIES. This patch removes some dead code to handle jiffies wraps from sch_api. --------------030508000201000907050805 Content-Type: text/plain; name="psched-dead-code.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="psched-dead-code.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/07/14 04:17:31+02:00 kaber@trash.net # [PKT_SCHED]: Remove dead timer code # # Signed-off-by: Patrick McHardy # # net/sched/sch_api.c # 2004/07/14 04:17:21+02:00 kaber@trash.net +1 -14 # [PKT_SCHED]: Remove dead timer code # # include/net/pkt_sched.h # 2004/07/14 04:17:21+02:00 kaber@trash.net +1 -2 # [PKT_SCHED]: Remove dead timer code # diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-07-14 04:19:55 +02:00 +++ b/include/net/pkt_sched.h 2004-07-14 04:19:55 +02:00 @@ -216,8 +216,6 @@ typedef u64 psched_time_t; typedef long psched_tdiff_t; -extern psched_time_t psched_time_base; - #if PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES #if HZ < 96 @@ -256,6 +254,7 @@ #define PSCHED_WATCHER u32 +extern psched_time_t psched_time_base; extern PSCHED_WATCHER psched_time_mark; #define PSCHED_GET_TIME(stamp) \ diff -Nru a/net/sched/sch_api.c b/net/sched/sch_api.c --- a/net/sched/sch_api.c 2004-07-14 04:19:55 +02:00 +++ b/net/sched/sch_api.c 2004-07-14 04:19:55 +02:00 @@ -1103,16 +1103,14 @@ EXPORT_SYMBOL(psched_tod_diff); #endif -psched_time_t psched_time_base; - #if PSCHED_CLOCK_SOURCE == PSCHED_CPU psched_tdiff_t psched_clock_per_hz; int psched_clock_scale; EXPORT_SYMBOL(psched_clock_per_hz); EXPORT_SYMBOL(psched_clock_scale); -#endif #ifdef PSCHED_WATCHER +psched_time_t psched_time_base; PSCHED_WATCHER psched_time_mark; EXPORT_SYMBOL(psched_time_mark); EXPORT_SYMBOL(psched_time_base); @@ -1123,22 +1121,14 @@ static void psched_tick(unsigned long dummy) { -#if PSCHED_CLOCK_SOURCE == PSCHED_CPU psched_time_t dummy_stamp; PSCHED_GET_TIME(dummy_stamp); /* It is OK up to 4GHz cpu */ psched_timer.expires = jiffies + 1*HZ; -#else - unsigned long now = jiffies; - psched_time_base += ((u64)(now-psched_time_mark))<; Tue, 13 Jul 2004 20:45:47 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1Bkaki-0007Rv-00; Wed, 14 Jul 2004 05:48:16 +0200 Message-ID: <40F4AC8B.40706@trash.net> Date: Wed, 14 Jul 2004 05:46:19 +0200 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: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> In-Reply-To: <40F4862D.3070802@trash.net> Content-Type: multipart/mixed; boundary="------------050608030600020308060104" X-archive-position: 6938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 4971 Lines: 179 This is a multi-part message in MIME format. --------------050608030600020308060104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > David S. Miller wrote: > >> >> I also want to add sparc64 %tick register support here too. >> This is an area with a lot of potential cleanup. We should >> made an asm/pkt_sched.h to abstract out the clock source >> implementation instead of loading net/pkt_sched.h up with >> a pile of ifdefs. >> > > Couldn't we just use get_cycles() ? Something like this: > > #include > > #if sizeof(cycles_t) == sizeof(u64) This one actually compiles ;). The assembler of PSCHED_GET_TIME is exactly the same on x86. There are 10 architectures that return something non-zero for get_cycles(), but I have no idea if it is suitable on all of them. Patch applies on top of the dead-code removal patch. Regards Patrick --------------050608030600020308060104 Content-Type: text/plain; name="psched-get_cycles.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="psched-get_cycles.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/07/14 05:22:57+02:00 kaber@trash.net # [PKT_SCHED]: Use get_cycles() for PSCHED_CPU clock source # # Signed-off-by: Patrick McHardy # # net/sched/sch_api.c # 2004/07/14 05:22:48+02:00 kaber@trash.net +12 -13 # [PKT_SCHED]: Use get_cycles() for PSCHED_CPU clock source # # include/net/pkt_sched.h # 2004/07/14 05:22:48+02:00 kaber@trash.net +15 -34 # [PKT_SCHED]: Use get_cycles() for PSCHED_CPU clock source # diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-07-14 05:23:48 +02:00 +++ b/include/net/pkt_sched.h 2004-07-14 05:23:48 +02:00 @@ -16,11 +16,6 @@ #include #include -#ifdef CONFIG_X86_TSC -#include -#endif - - struct rtattr; struct Qdisc; @@ -235,41 +230,27 @@ #define PSCHED_JIFFIE2US(delay) ((delay)< extern psched_tdiff_t psched_clock_per_hz; extern int psched_clock_scale; +extern psched_time_t psched_time_base; +extern cycles_t psched_time_mark; +#define PSCHED_GET_TIME(stamp) \ +do { \ + cycles_t cur = get_cycles(); \ + if (sizeof(cycles_t) == sizeof(u32)) { \ + if (cur <= psched_time_mark) \ + psched_time_base += 0x100000000ULL; \ + psched_time_mark = cur; \ + (stamp) = (psched_time_base + cur)>>psched_clock_scale; \ + } else { \ + (stamp) = cur>>psched_clock_scale; \ + } \ +} while (0) #define PSCHED_US2JIFFIE(delay) (((delay)+psched_clock_per_hz-1)/psched_clock_per_hz) #define PSCHED_JIFFIE2US(delay) ((delay)*psched_clock_per_hz) - -#ifdef CONFIG_X86_TSC - -#define PSCHED_GET_TIME(stamp) \ -({ u64 __cur; \ - rdtscll(__cur); \ - (stamp) = __cur>>psched_clock_scale; \ -}) - -#elif defined (__alpha__) - -#define PSCHED_WATCHER u32 - -extern psched_time_t psched_time_base; -extern PSCHED_WATCHER psched_time_mark; - -#define PSCHED_GET_TIME(stamp) \ -({ u32 __res; \ - __asm__ __volatile__ ("rpcc %0" : "r="(__res)); \ - if (__res <= psched_time_mark) psched_time_base += 0x100000000UL; \ - psched_time_mark = __res; \ - (stamp) = (psched_time_base + __res)>>psched_clock_scale; \ -}) - -#else - -#error PSCHED_CLOCK_SOURCE=PSCHED_CPU is not supported on this arch. - -#endif /* ARCH */ #endif /* PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES */ diff -Nru a/net/sched/sch_api.c b/net/sched/sch_api.c --- a/net/sched/sch_api.c 2004-07-14 05:23:48 +02:00 +++ b/net/sched/sch_api.c 2004-07-14 05:23:48 +02:00 @@ -1109,25 +1109,26 @@ EXPORT_SYMBOL(psched_clock_per_hz); EXPORT_SYMBOL(psched_clock_scale); -#ifdef PSCHED_WATCHER psched_time_t psched_time_base; -PSCHED_WATCHER psched_time_mark; +cycles_t psched_time_mark; EXPORT_SYMBOL(psched_time_mark); EXPORT_SYMBOL(psched_time_base); -static void psched_tick(unsigned long); - -static struct timer_list psched_timer = TIMER_INITIALIZER(psched_tick, 0, 0); - +/* + * Periodically adjust psched_time_base to avoid overflow + * with 32-bit get_cycles(). Safe up to 4GHz CPU. + */ static void psched_tick(unsigned long dummy) { + static struct timer_list psched_timer = { .function = psched_tick }; psched_time_t dummy_stamp; - PSCHED_GET_TIME(dummy_stamp); - /* It is OK up to 4GHz cpu */ - psched_timer.expires = jiffies + 1*HZ; - add_timer(&psched_timer); + + if (sizeof(cycles_t) == sizeof(u32)) { + PSCHED_GET_TIME(dummy_stamp); + psched_timer.expires = jiffies + 1*HZ; + add_timer(&psched_timer); + } } -#endif int __init psched_calibrate_clock(void) { @@ -1137,9 +1138,7 @@ long rdelay; unsigned long stop; -#ifdef PSCHED_WATCHER psched_tick(0); -#endif stop = jiffies + HZ/10; PSCHED_GET_TIME(stamp); do_gettimeofday(&tv); --------------050608030600020308060104-- From kazunori@miyazawa.org Tue Jul 13 21:44:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jul 2004 21:44:54 -0700 (PDT) Received: from miyazawa.org ([221.116.13.66]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6E4ic92020006 for ; Tue, 13 Jul 2004 21:44:38 -0700 Received: from lemans.local.ini.jp ([2001:240:2:0:20c:29ff:febb:6598]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Wed, 14 Jul 2004 13:36:21 +0900 id 00000745.40F4B845.00002421 From: Kazunori Miyazawa To: Herbert Xu Subject: Re: IPv6 and encapsulation headers Date: Wed, 14 Jul 2004 13:42:34 +0900 User-Agent: KMail/1.6.2 References: <20040710033209.GA14316@gondor.apana.org.au> <200407131042.41346.kazunori@miyazawa.org> <20040713104837.GA9670@gondor.apana.org.au> In-Reply-To: <20040713104837.GA9670@gondor.apana.org.au> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Message-Id: <200407141342.34174.kazunori@miyazawa.org> X-archive-position: 6939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Content-Length: 1628 Lines: 35 2004/07/13($B2P(B) 19:48$B!"(Byou wrote: > On Tue, Jul 13, 2004 at 10:42:41AM +0900, Kazunori Miyazawa wrote: > > I agree with you. It should uses ip6_find_1stfragopt. > > However please consider zero_out_mutable_opts in ah6.c clears second > > destination options. We need to get the copy length by other way. > > Because ip6_find_1stfragopt returns the insert point of IPsec. > > Are there situations where it is desirable to have mutable options > in the second destination header? Isn't the idea of the second > destination header so that it is processed only by the final > destination? I would've thought that it only made sense to have > immutable options there. > > In fact if ESP were present then it guarantees the second dest > header to be immutable. So perhaps we should simply disallow > users from putting mutable options in the second destination > header. Or we can document it as undefined and let the user > handle the consequences (cf HDRINCL with raw sockets + IPsec). > Well, we should disallow the operation. > BTW, the current code in ipv6_clear_mutable_options() that deals > with NEXTHDR_AUTH is buggy. It assumes that there are at most two > AH headers. Yes, but I guess most implementation and administrator do not set double or more AH header in a packet.This restriction doesn't effect interoperability except for KAME with special configuration. Honestly speaking, it is enough the IPsec stack processes just one AH, ESP and IPcomp header each. Of course the stack should process some set of those a header and payloads in tunnel mode. Thank you for your point out, --Kazunori Miyazawa From herbert@gondor.apana.org.au Wed Jul 14 04:14:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 04:14:46 -0700 (PDT) Received: from arnor.apana.org.au (mail@[203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6EBE8iB018098 for ; Wed, 14 Jul 2004 04:14:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bkhi3-0000Jo-00; Wed, 14 Jul 2004 21:13:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bkhi0-0005eJ-00; Wed, 14 Jul 2004 21:13:56 +1000 Date: Wed, 14 Jul 2004 21:13:56 +1000 To: Kazunori Miyazawa Cc: netdev@oss.sgi.com Subject: Re: IPv6 and encapsulation headers Message-ID: <20040714111356.GA21699@gondor.apana.org.au> References: <20040710033209.GA14316@gondor.apana.org.au> <200407131042.41346.kazunori@miyazawa.org> <20040713104837.GA9670@gondor.apana.org.au> <200407141342.34174.kazunori@miyazawa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407141342.34174.kazunori@miyazawa.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1205 Lines: 28 On Wed, Jul 14, 2004 at 01:42:34PM +0900, Kazunori Miyazawa wrote: > > > In fact if ESP were present then it guarantees the second dest > > header to be immutable. So perhaps we should simply disallow > > users from putting mutable options in the second destination > > header. Or we can document it as undefined and let the user > > handle the consequences (cf HDRINCL with raw sockets + IPsec). > > Well, we should disallow the operation. Great. That should simply things in AH. > Yes, but I guess most implementation and administrator do not set > double or more AH header in a packet.This restriction doesn't > effect interoperability except for KAME with special configuration. > Honestly speaking, it is enough the IPsec stack processes just > one AH, ESP and IPcomp header each. Of course the stack should process > some set of those a header and payloads in tunnel mode. Well if we disallow mutable options in the second destination header, then this becomes a non-issue. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From torvalds@osdl.org Wed Jul 14 14:28:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 14:28:45 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6ELSYTA019120 for ; Wed, 14 Jul 2004 14:28:34 -0700 Received: from localhost (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i6ELSBk04706; Wed, 14 Jul 2004 14:28:12 -0700 Date: Wed, 14 Jul 2004 14:28:11 -0700 (PDT) From: Linus Torvalds To: Jeff Garzik cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [BK PATCHES] 2.6.x net driver fixes In-Reply-To: <40F58EFD.7080904@pobox.com> Message-ID: References: <20040714192706.GA24447@havoc.gtf.org> <40F58EFD.7080904@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Content-Length: 675 Lines: 27 On Wed, 14 Jul 2004, Jeff Garzik wrote: > > > > The weaker ordering constraint is called "read_barrier_depends()", and > > should be a no-op on all but alpha. Would you want to use that to fix the > > alpha case too? > > What would the proper fix be? > > rmb(); > read_barrier_depends(); No, just a index = *indexpointer; read_barrier_depends(); data = dataptr[index]; which on most architectures is a no-op, but in case the hardware might do data or address speculation, and needs a dependent load barrier, it will do the right thing. For stuff that isn't data dependent, you have to use the full rmb(), which obviously isn't a no-op on most setups. Linus From alexeyt@sdf.lonestar.org Wed Jul 14 15:04:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 15:04:51 -0700 (PDT) Received: from sdf.lonestar.org (IDENT:root@ol.freeshell.org [192.94.73.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6EM4WkH020204 for ; Wed, 14 Jul 2004 15:04:32 -0700 Received: from sdf.lonestar.org (IDENT:alexeyt@ukato.freeshell.org [192.94.73.7]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i6EM4Qbh021404 for ; Wed, 14 Jul 2004 22:04:26 GMT Received: (from alexeyt@localhost) by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i6EM4P4j027592; Wed, 14 Jul 2004 22:04:25 GMT Date: Wed, 14 Jul 2004 22:04:25 +0000 (UTC) From: Alexey Toptygin To: netdev@oss.sgi.com Subject: kernel-manpage inconsistency Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6942 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexeyt@freeshell.org Precedence: bulk X-list: netdev Content-Length: 1240 Lines: 49 I don't know wether this is a kernel issue or a manpage issue, I just know that they disagree. In recv(2) it says: MSG_TRUNC Return the real length of the packet, even when it was longer than the passed buffer. Only valid for packet sockets. But this is not honored. Also, in udp(7), it says: IOCTLS These ioctls can be accessed using ioctl(2). The correct syntax is: int value; error = ioctl(tcp_socket, ioctl_type, &value); SIOCINQ Gets a pointer to an integer as argument. Returns the size of the next pending datagram in the integer in bytes, or 0 when no datagram is pending. SIOCOUTQ Returns the number of data bytes in the local send queue. Only supported with Linux 2.4 and above. These don't appear to be implemented. ( They're not in any headers and they're not listed in ioctl_list(2). ) Please tell me who I need to report this to to get it fixed. Also, if there is a way to get the length of the next incoming datagram, I would love to know about it. Currently I'm resorting to: while(1){ recvmsg(..., MSG_PEEK); if ( flags & MSG_TRUNC ){ double buffer size; } else { break; } } Alexey P.S. I'm not on the list, please reply directly. Thanks. From wgshi2002@yahoo.ca Wed Jul 14 17:11:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 17:12:05 -0700 (PDT) Received: from web54105.mail.yahoo.com (web54105.mail.yahoo.com [206.190.37.240]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F0Bw55026801 for ; Wed, 14 Jul 2004 17:11:59 -0700 Message-ID: <20040715001152.26115.qmail@web54105.mail.yahoo.com> Received: from [129.128.209.16] by web54105.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 20:11:52 EDT Date: Wed, 14 Jul 2004 20:11:52 -0400 (EDT) From: Weiguang Shi Subject: RE: [RFC] TCP burst control To: Injong Rhee Cc: netdev linux , Qiang Ye In-Reply-To: <200407070546.i675kkPf008128@ms-smtp-01-eri0.southeast.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wgshi2002@yahoo.ca Precedence: bulk X-list: netdev Hi, My question is: Why in_flight drops *far* below cwnd in the first place? The assumption is that each time an ack comes, TCP SHOULD decrease in_flight by the number of new segments that the ack acknowledges. During fast recovery, each packet after the lost is acked immediately (in the form of a duplicate ack) by the receiver since it is out of order. Each dupack should bring the latest SACK info, i.e., one more packet received. Therefore a packet cannot trigger a dupack acknowledging more than one new segment, not even in the multiple-packet-drop scenario. That is, sacked_out++ upon each ack during fast recovery; lost_out=0 according to the conservative SACK; and before the first (partial) ack that advances snd.una, retrans_out=1. Therefore, in_flight = packets_out - sacked_out + 1 This seems to indicate that with SACK, in_flight should gradually decrease instead of dropping suddenly during fast recovery. On the other hand, I've seen sudden-drops in my experiments. What happened? Regards, Wei --- Injong Rhee wrote: > > Hi David, > > ... > > The main problem lies in the variable that rate halving is closely > interacting with in TCP SACK implementation: packet_in_flight (or pipe_). In > the current implementation of Linux TCP SACK, cwnd is set to > packet_in_flight + C for every ack for CWR, recovery, and timeout-- Here C > is 1 to 3. But many times, packet_in_flight drops *far* below cwnd during > fast recovery. In high speed networks, a lot of packets can be lost in one > RTT (even acks as well because of slow CPUs). If that happens, > packet_in_flight becomes very small. At this time, Linux cwnd moderation (or > burst control) kicks in by setting cwnd to packet_in_flight + C so that the > sender does not burst all those packets between packet_in_flight and cwnd at > a single time. However, there is a problem with this approach. Since cwnd is > kept to very small, the transmission rate drops to almost zero during fast > recovery -- it should drop only to half of the current transmission rate (or > in high-speed protocols like BIC, it is only 87% of the current rate). Since > fast recovery lasts more than several RTTs, the network capacity is highly > underutilized during fast recovery. Furthermore, right after fast recovery, > cwnd goes into slow start since cwnd is typically far smaller than ssthrsh > after fast recovery. This also creates a lot of burst -- likely causing back > to back losses or even timeouts. > > You can see this behavior in the following link: > > http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B > IC-600-75-7500-1-0-0-noburst/index.htm > > We run in a dummynet without any change in the burst control. You can see > that whenever there is fast recovery, the rate almost drop to zero. The pink > line is the throughput observed from the dummynet at every second, and red > one is from Iperf. In the second figure, you can see cwnd. It drops to the > bottom during fast recovery -- this is not part of congestion control. It is > the burst control of Linux SACK doing it. > > But with our new burst control: > > http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/tiny_release/experiments/B > IC-600-75-7500-1-0-0/index.htm > > You can see that cwnd is quite stabilized and the throughput does not have > as much dip as in the original case. > > Here is what we do: instead of reducing cwnd to packet_in_flight (which is, > in fact, meddling with congestion control), we reduce the gap between these > two numbers by allowing transmitting more packets per ack (we set this to > three more packets per ack) until packet_in_flight becomes close to cwnd. > Also right after fast recovery, we increase packet_in_flight by 1% of > packet_in_flight up to cwnd. This reduces the huge burst after fast > recovery. Our implementation is trying to leave cwnd only to congestion > control and separates burst control from congestion control. This makes the > behavior of congestion control more predictable. We will report more on > this tomorrow when we get back to the Lab to test some other environments, > especially when we have smaller buffers. This scheme may not be the cure for > all and needs more testing. So far, it has been working very well. > > Stay tuned. > Injong. > --- > Injong Rhee, Associate Professor > North Carolina State University > Raleigh, NC 27699 > rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee > > > > -----Original Message----- > From: David S. Miller [mailto:davem@redhat.com] > Sent: Tuesday, July 06, 2004 8:29 PM > To: Injong Rhee > Cc: shemminger@osdl.org; netdev@oss.sgi.com; rhee@ncsu.edu; lxu2@ncsu.edu; > mathis@psc.edu > Subject: Re: [RFC] TCP burst control > > On Tue, 6 Jul 2004 20:09:41 -0400 > "Injong Rhee" wrote: > > > Currently with rate having, current Linux tcp stack is full of hacks that > in > > fact, hurt the performance of linux tcp (sorry to say this). > > If rate-halving is broken, have you taken this up with it's creator, > Mr. Mathis? What was his response? > > I've added him to the CC: list so this can be properly discussed. > > > ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From mcgrof@studorgs.rutgers.edu Wed Jul 14 18:32:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 18:33:00 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F1WKhs028745 for ; Wed, 14 Jul 2004 18:32:22 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 48724F9D4D; Wed, 14 Jul 2004 20:51:40 -0400 (EDT) Date: Wed, 14 Jul 2004 20:51:40 -0400 To: Marcelo Tosatti Cc: Netdev , prism54-devel@prism54.org, Linux Kernel Subject: [PATCH 2.4.26] add prism54 to 2.4 tree Message-ID: <20040715005140.GH14482@ruslug.rutgers.edu> Mail-Followup-To: Marcelo Tosatti , Netdev , prism54-devel@prism54.org, Linux Kernel Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7vLGWvOrvbSM0Ba8" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 6944 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev --7vLGWvOrvbSM0Ba8 Content-Type: multipart/mixed; boundary="sCNd3Ivk/oijKKf1" Content-Disposition: inline --sCNd3Ivk/oijKKf1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marcelo, Attached patch adds prism54 to 2.4 tree. This patch applies cleanly to 2.4.27-rc3 as well. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --sCNd3Ivk/oijKKf1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.4-prism54-cvs-latest.diff" Content-Transfer-Encoding: quoted-printable --- linux-2.4.26/Documentation/Configure.help 2004-04-14 13:05:24.000000000= +0000 +++ linux-2.4.26-prism54/Documentation/Configure.help 2004-07-15 00:30:04.0= 00000000 +0000 @@ -9968,6 +9968,49 @@ compile it as a module, say M here and read . =20 +Intersil 802.11(a/b/g) Prism GT/Duette/Indigo support +CONFIG_PRISM54 + Enable PCI and Cardbus support for the following chipset based cards: + + ISL3880 - Prism GT 802.11 b/g + ISL3877 - Prism Indigo 802.11 a + ISL3890 - Prism Duette 802.11 a/b/g + =20 + For a complete list of supported cards visit . + Here is the latest confirmed list of supported cards: + + 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 + Allnet ALL0271 PCI Card + Compex WL54G Cardbus Card + Corega CG-WLCB54GT Cardbus Card + D-Link Air Plus Xtreme G A1 Cardbus Card aka DWL-g650 + I-O Data WN-G54/CB Cardbus Card + Kobishi XG-300 aka Z-Com Cardbus Card + Netgear WG511 Cardbus Card + Ovislink WL-5400PCI PCI Card + Peabird WLG-PCI PCI Card + Sitecom WL-100i Cardbus Card + Sitecom WL-110i PCI Card + SMC2802W - EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card + SMC2835W - EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Card + Z-Com XG-900 PCI Card + Zyxel G-100 Cardbus Card + + If you enable this, you require a firmware file as well. + You will need to copy this to /usr/lib/hotplug/firmware/isl3890. + You can get this non-GPL'd firmware file from the Prism54 project page: + . + You will also need the /etc/hotplug/firmware.agent script from + a current hotplug package. + + + Note: You need a motherboard with DMA support to use any of these cards= =20 + =20 + If you want to compile the driver as a module ( =3D code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read . The module + will be called prism54.o. + Aironet 4500/4800 PROC interface CONFIG_AIRONET4500_PROC If you say Y here (and to the "/proc file system" below), you will diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/C= onfig.in linux-2.4.26-prism54/drivers/net/wireless/Config.in --- linux-2.4.26/drivers/net/wireless/Config.in 2004-04-14 13:05:30.0000000= 00 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/Config.in 2004-07-15 00:30:04= .000000000 +0000 @@ -27,6 +27,15 @@ dep_tristate ' Atmel at76c502/at76c504 PCMCIA cards' CONFIG_PCMCIA_ATM= EL $CONFIG_FW_LOADER fi =20 +# If PCI enabled, allow for prism54 driver. CONFIG_FW_LOADER required +comment 'Prism54 PCI/PCMCIA GT/Duette Driver - 802.11(a/b/g)' +dep_tristate 'Intersil Prism GT/Duette/Indigo PCI/PCMCIA' CONFIG_PRISM54 $= CONFIG_EXPERIMENTAL $CONFIG_PCI $CONFIG_HOTPLUG +if [ "$CONFIG_PRISM54" !=3D "n" ]; then + if [ "$CONFIG_FW_LOADER" !=3D "y" ]; then + define_tristate CONFIG_FW_LOADER $CONFIG_PRISM54 + fi +fi + # yes, this works even when no drivers are selected if [ "$CONFIG_ISA" =3D "y" -o "$CONFIG_PCI" =3D "y" -o \ "$CONFIG_ALL_PPC" =3D "y" -o "$CONFIG_PCMCIA" !=3D "n" ]; then diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/M= akefile linux-2.4.26-prism54/drivers/net/wireless/Makefile --- linux-2.4.26/drivers/net/wireless/Makefile 2004-04-14 13:05:30.00000000= 0 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/Makefile 2004-07-15 00:30:04.= 000000000 +0000 @@ -25,4 +25,9 @@ obj-$(CONFIG_AIRO_CS) +=3D airo_cs.o airo.o obj-$(CONFIG_PCMCIA_ATMEL) +=3D atmel_cs.o atmel.o =20 +ifeq ($(CONFIG_PRISM54),y) +obj-$(CONFIG_PRISM54) +=3D prism54/prism54.o +endif +subdir-$(CONFIG_PRISM54) +=3D prism54 + include $(TOPDIR)/Rules.make diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/Makefile linux-2.4.26-prism54/drivers/net/wireless/prism54/Makefile --- linux-2.4.26/drivers/net/wireless/prism54/Makefile 1970-01-01 00:00:00.= 000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/Makefile 2004-07-15 0= 0:30:04.000000000 +0000 @@ -0,0 +1,12 @@ + +O_TARGET :=3D prism54.o + +EXTRA_CFLAGS +=3D -DPRISM54_COMPAT24 + +obj-y :=3D isl_38xx.o islpci_dev.o islpci_eth.o \ + islpci_mgt.o islpci_hotplug.o isl_ioctl.o \ + oid_mgt.o + +obj-m +=3D prism54.o + +include $(TOPDIR)/Rules.make diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_38xx.c linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38x= x.c --- linux-2.4.26/drivers/net/wireless/prism54/isl_38xx.c 1970-01-01 00:00:0= 0.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38xx.c 2004-07-15= 00:30:04.000000000 +0000 @@ -0,0 +1,267 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003-2004 Luis R. Rodriguez _ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#define __KERNEL_SYSCALLS__ + +#include +#include +#include +#include + +#include +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" + +/*************************************************************************= ***** + Device Interface & Control functions +**************************************************************************= ****/ + +/** + * isl38xx_disable_interrupts - disable all interrupts + * @device: pci memory base address + * + * Instructs the device to disable all interrupt reporting by asserting= =20 + * the IRQ line. New events may still show up in the interrupt identifica= tion + * register located at offset %ISL38XX_INT_IDENT_REG. + */ +void +isl38xx_disable_interrupts(void *device) +{ + isl38xx_w32_flush(device, 0x00000000, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_handle_sleep_request(isl38xx_control_block *control_block, + int *powerstate, void *device_base) +{ + /* device requests to go into sleep mode + * check whether the transmit queues for data and management are empty */ + if (isl38xx_in_queue(control_block, ISL38XX_CB_TX_DATA_LQ)) + /* data tx queue not empty */ + return; + + if (isl38xx_in_queue(control_block, ISL38XX_CB_TX_MGMTQ)) + /* management tx queue not empty */ + return; + + /* check also whether received frames are pending */ + if (isl38xx_in_queue(control_block, ISL38XX_CB_RX_DATA_LQ)) + /* data rx queue not empty */ + return; + + if (isl38xx_in_queue(control_block, ISL38XX_CB_RX_MGMTQ)) + /* management rx queue not empty */ + return; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Device going to sleep mode\n"); +#endif + + /* all queues are empty, allow the device to go into sleep mode */ + *powerstate =3D ISL38XX_PSM_POWERSAVE_STATE; + + /* assert the Sleep interrupt in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_SLEEP, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_handle_wakeup(isl38xx_control_block *control_block, + int *powerstate, void *device_base) +{ + /* device is in active state, update the powerstate flag */ + *powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* now check whether there are frames pending for the card */ + if (!isl38xx_in_queue(control_block, ISL38XX_CB_TX_DATA_LQ) + && !isl38xx_in_queue(control_block, ISL38XX_CB_TX_MGMTQ)) + return; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_ANYTHING, "Wake up handler trigger the device\n"); +#endif + + /* either data or management transmit queue has a frame pending + * trigger the device by setting the Update bit in the Device Int reg */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_trigger_device(int asleep, void *device_base) +{ + struct timeval current_time; + u32 reg, counter =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "isl38xx trigger device\n"); +#endif + + /* check whether the device is in power save mode */ + if (asleep) { + /* device is in powersave, trigger the device for wakeup */ +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", + current_time.tv_sec, current_time.tv_usec); +#endif + + DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, + readl(device_base + ISL38XX_CTRL_STAT_REG)); + udelay(ISL38XX_WRITEIO_DELAY); + + if (reg =3D readl(device_base + ISL38XX_INT_IDENT_REG), + reg =3D=3D 0xabadface) { +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, + "%08li.%08li Device register abadface\n", + current_time.tv_sec, current_time.tv_usec); +#endif + /* read the Device Status Register until Sleepmode bit is set */ + while (reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG), + (reg & ISL38XX_CTRL_STAT_SLEEPMODE) =3D=3D 0) { + udelay(ISL38XX_WRITEIO_DELAY); + counter++; + } + + DEBUG(SHOW_TRACING, + "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, + readl(device_base + ISL38XX_CTRL_STAT_REG)); + udelay(ISL38XX_WRITEIO_DELAY); + +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, + "%08li.%08li Device asleep counter %i\n", + current_time.tv_sec, current_time.tv_usec, + counter); +#endif + } + /* assert the Wakeup interrupt in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_WAKEUP, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + /* perform another read on the Device Status Register */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, reg); +#endif + } else { + /* device is (still) awake */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Device is in active state\n"); +#endif + /* trigger the device by setting the Update bit in the Device Int reg */ + + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + } +} + +void +isl38xx_interface_reset(void *device_base, dma_addr_t host_address) +{ + u32 reg; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "isl38xx_interface_reset \n"); +#endif + + /* load the address of the control block in the device */ + isl38xx_w32_flush(device_base, host_address, ISL38XX_CTRL_BLK_BASE_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the reset bit in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_RESET, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + /* enable the interrupt for detecting initialization */ + + /* Note: Do not enable other interrupts here. We want the + * device to have come up first 100% before allowing any other=20 + * interrupts. */ + reg =3D ISL38XX_INT_IDENT_INIT; + + isl38xx_w32_flush(device_base, reg, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); /* allow complete full reset */ +} + +void +isl38xx_enable_common_interrupts(void *device_base) { + u32 reg; + reg =3D ( ISL38XX_INT_IDENT_UPDATE |=20 + ISL38XX_INT_IDENT_SLEEP | ISL38XX_INT_IDENT_WAKEUP); + isl38xx_w32_flush(device_base, reg, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +int +isl38xx_in_queue(isl38xx_control_block *cb, int queue) +{ + const s32 delta =3D (le32_to_cpu(cb->driver_curr_frag[queue]) - + le32_to_cpu(cb->device_curr_frag[queue])); + + /* determine the amount of fragments in the queue depending on the type + * of the queue, either transmit or receive */ + + BUG_ON(delta < 0); /* driver ptr must be ahead of device ptr */ + + switch (queue) { + /* send queues */ + case ISL38XX_CB_TX_MGMTQ: + BUG_ON(delta > ISL38XX_CB_MGMT_QSIZE); + case ISL38XX_CB_TX_DATA_LQ: + case ISL38XX_CB_TX_DATA_HQ: + BUG_ON(delta > ISL38XX_CB_TX_QSIZE); + return delta; + break; + + /* receive queues */ + case ISL38XX_CB_RX_MGMTQ: + BUG_ON(delta > ISL38XX_CB_MGMT_QSIZE); + return ISL38XX_CB_MGMT_QSIZE - delta; + break; + + case ISL38XX_CB_RX_DATA_LQ: + case ISL38XX_CB_RX_DATA_HQ: + BUG_ON(delta > ISL38XX_CB_RX_QSIZE); + return ISL38XX_CB_RX_QSIZE - delta; + break; + } + BUG(); + return 0; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_38xx.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38x= x.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_38xx.h 1970-01-01 00:00:0= 0.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38xx.h 2004-07-15= 00:30:04.000000000 +0000 @@ -0,0 +1,169 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISL_38XX_H +#define _ISL_38XX_H + +#include +#include +#include + +#define ISL38XX_CB_RX_QSIZE 8 +#define ISL38XX_CB_TX_QSIZE 32 + +/* ISL38XX Access Point Specific definitions */ +#define ISL38XX_MAX_WDS_LINKS 8 + +/* ISL38xx Client Specific definitions */ +#define ISL38XX_PSM_ACTIVE_STATE 0 +#define ISL38XX_PSM_POWERSAVE_STATE 1 + +/* ISL38XX Host Interface Definitions */ +#define ISL38XX_PCI_MEM_SIZE 0x02000 +#define ISL38XX_MEMORY_WINDOW_SIZE 0x01000 +#define ISL38XX_DEV_FIRMWARE_ADDRES 0x20000 +#define ISL38XX_WRITEIO_DELAY 10 /* in us */ +#define ISL38XX_RESET_DELAY 50 /* in ms */ +#define ISL38XX_WAIT_CYCLE 10 /* in 10ms */ +#define ISL38XX_MAX_WAIT_CYCLES 10 + +/* PCI Memory Area */ +#define ISL38XX_HARDWARE_REG 0x0000 +#define ISL38XX_CARDBUS_CIS 0x0800 +#define ISL38XX_DIRECT_MEM_WIN 0x1000 + +/* Hardware registers */ +#define ISL38XX_DEV_INT_REG 0x0000 +#define ISL38XX_INT_IDENT_REG 0x0010 +#define ISL38XX_INT_ACK_REG 0x0014 +#define ISL38XX_INT_EN_REG 0x0018 +#define ISL38XX_GEN_PURP_COM_REG_1 0x0020 +#define ISL38XX_GEN_PURP_COM_REG_2 0x0024 +#define ISL38XX_CTRL_BLK_BASE_REG ISL38XX_GEN_PURP_COM_REG_1 +#define ISL38XX_DIR_MEM_BASE_REG 0x0030 +#define ISL38XX_CTRL_STAT_REG 0x0078 + +/* High end mobos queue up pci writes, the following + * is used to "read" from after a write to force flush */ +#define ISL38XX_PCI_POSTING_FLUSH ISL38XX_INT_EN_REG + +/** + * isl38xx_w32_flush - PCI iomem write helper + * @base: (host) memory base address of the device + * @val: 32bit value (host order) to write + * @offset: byte offset into @base to write value to + *=20 + * This helper takes care of writing a 32bit datum to the + * specified offset into the device's pci memory space, and making sure= =20 + * the pci memory buffers get flushed by performing one harmless read=20 + * from the %ISL38XX_PCI_POSTING_FLUSH offset. + */ +static inline void +isl38xx_w32_flush(void *base, u32 val, unsigned long offset) +{ + writel(val, base + offset); + (void) readl(base + ISL38XX_PCI_POSTING_FLUSH); +} + +/* Device Interrupt register bits */ +#define ISL38XX_DEV_INT_RESET 0x0001 +#define ISL38XX_DEV_INT_UPDATE 0x0002 +#define ISL38XX_DEV_INT_WAKEUP 0x0008 +#define ISL38XX_DEV_INT_SLEEP 0x0010 + +/* Interrupt Identification/Acknowledge/Enable register bits */ +#define ISL38XX_INT_IDENT_UPDATE 0x0002 +#define ISL38XX_INT_IDENT_INIT 0x0004 +#define ISL38XX_INT_IDENT_WAKEUP 0x0008 +#define ISL38XX_INT_IDENT_SLEEP 0x0010 +#define ISL38XX_INT_SOURCES 0x001E + +/* Control/Status register bits */ +#define ISL38XX_CTRL_STAT_SLEEPMODE 0x00000200 +#define ISL38XX_CTRL_STAT_CLKRUN 0x00800000 +#define ISL38XX_CTRL_STAT_RESET 0x10000000 +#define ISL38XX_CTRL_STAT_RAMBOOT 0x20000000 +#define ISL38XX_CTRL_STAT_STARTHALTED 0x40000000 +#define ISL38XX_CTRL_STAT_HOST_OVERRIDE 0x80000000 + +/* Control Block definitions */ +#define ISL38XX_CB_RX_DATA_LQ 0 +#define ISL38XX_CB_TX_DATA_LQ 1 +#define ISL38XX_CB_RX_DATA_HQ 2 +#define ISL38XX_CB_TX_DATA_HQ 3 +#define ISL38XX_CB_RX_MGMTQ 4 +#define ISL38XX_CB_TX_MGMTQ 5 +#define ISL38XX_CB_QCOUNT 6 +#define ISL38XX_CB_MGMT_QSIZE 4 +#define ISL38XX_MIN_QTHRESHOLD 4 /* fragments */ + +/* Memory Manager definitions */ +#define MGMT_FRAME_SIZE 1500 /* >=3D size struct o= bj_bsslist */ +#define MGMT_TX_FRAME_COUNT 24 /* max 4 + spare 4 + 8 = init */ +#define MGMT_RX_FRAME_COUNT 24 /* 4*4 + spare 8 */ +#define MGMT_FRAME_COUNT (MGMT_TX_FRAME_COUNT + MGM= T_RX_FRAME_COUNT) +#define CONTROL_BLOCK_SIZE 1024 /* should be enough */ +#define PSM_FRAME_SIZE 1536 +#define PSM_MINIMAL_STATION_COUNT 64 +#define PSM_FRAME_COUNT PSM_MINIMAL_STATION_COUNT +#define PSM_BUFFER_SIZE PSM_FRAME_SIZE * PSM_FRAME= _COUNT +#define MAX_TRAP_RX_QUEUE 4 +#define HOST_MEM_BLOCK CONTROL_BLOCK_SIZE + PSM_B= UFFER_SIZE + +/* Fragment package definitions */ +#define FRAGMENT_FLAG_MF 0x0001 +#define MAX_FRAGMENT_SIZE 1536 + +/* In monitor mode frames have a header. I don't know exactly how big those + * frame can be but I've never seen any frame bigger than 1584... : + */ +#define MAX_FRAGMENT_SIZE_RX 1600 + +typedef struct { + u32 address; /* physical address on host */ + u16 size; /* packet size */ + u16 flags; /* set of bit-wise flags */ +} isl38xx_fragment; + +struct isl38xx_cb { + u32 driver_curr_frag[ISL38XX_CB_QCOUNT]; + u32 device_curr_frag[ISL38XX_CB_QCOUNT]; + isl38xx_fragment rx_data_low[ISL38XX_CB_RX_QSIZE]; + isl38xx_fragment tx_data_low[ISL38XX_CB_TX_QSIZE]; + isl38xx_fragment rx_data_high[ISL38XX_CB_RX_QSIZE]; + isl38xx_fragment tx_data_high[ISL38XX_CB_TX_QSIZE]; + isl38xx_fragment rx_data_mgmt[ISL38XX_CB_MGMT_QSIZE]; + isl38xx_fragment tx_data_mgmt[ISL38XX_CB_MGMT_QSIZE]; +}; + +typedef struct isl38xx_cb isl38xx_control_block; + +/* determine number of entries currently in queue */ +int isl38xx_in_queue(isl38xx_control_block *cb, int queue); + +void isl38xx_disable_interrupts(void *); +void isl38xx_enable_common_interrupts(void *); + +void isl38xx_handle_sleep_request(isl38xx_control_block *, int *, + void *); +void isl38xx_handle_wakeup(isl38xx_control_block *, int *, void *); +void isl38xx_trigger_device(int, void *); +void isl38xx_interface_reset(void *, dma_addr_t); + +#endif /* _ISL_38XX_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_ioctl.c linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_io= ctl.c --- linux-2.4.26/drivers/net/wireless/prism54/isl_ioctl.c 1970-01-01 00:00:= 00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_ioctl.c 2004-07-1= 5 00:30:04.000000000 +0000 @@ -0,0 +1,2261 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * (C) 2003,2004 Aurelien Alleaume + * (C) 2003 Herbert Valerio Riedel + * (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include +#include +#include +#include + +#include + +#include "prismcompat.h" +#include "isl_ioctl.h" +#include "islpci_mgt.h" +#include "isl_oid.h" /* additional types and defs for isl38xx fw */ +#include "oid_mgt.h" + +#include /* New driver API */ + +static int init_mode =3D CARD_DEFAULT_IW_MODE; +static int init_channel =3D CARD_DEFAULT_CHANNEL; +static int init_wep =3D CARD_DEFAULT_WEP; +static int init_filter =3D CARD_DEFAULT_FILTER; +static int init_authen =3D CARD_DEFAULT_AUTHEN; +static int init_dot1x =3D CARD_DEFAULT_DOT1X; +static int init_conformance =3D CARD_DEFAULT_CONFORMANCE; +static int init_mlme =3D CARD_DEFAULT_MLME_MODE; + +module_param(init_mode, int, 0); +MODULE_PARM_DESC(init_mode, + "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Ma= ster / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not sup= ported yet)\n6: Monitor"); + +module_param(init_channel, int, 0); +MODULE_PARM_DESC(init_channel, + "Check `iwpriv ethx channel` for available channels"); + +module_param(init_wep, int, 0); +module_param(init_filter, int, 0); + +module_param(init_authen, int, 0); +MODULE_PARM_DESC(init_authen, + "Authentication method. Can be of seven types:\n0 0x0000: None\n1 0x000= 1: DOT11_AUTH_OS (Default)\n2 0x0002: DOT11_AUTH_SK\n3 0x0003: DOT11_AUTH_B= OTH"); + +module_param(init_dot1x, int, 0); +MODULE_PARM_DESC(init_dot1x, + "\n0: None/not set (Default)\n1: DOT11_DOT1X_AUTHENABLED\n2: DOT11_DOT1= X_KEYTXENABLED"); + +module_param(init_mlme, int, 0); +MODULE_PARM_DESC(init_mlme, + "Sets the MAC layer management entity (MLME) mode of operation,\n0: DOT= 11_MLME_AUTO (Default)\n1: DOT11_MLME_INTERMEDIATE\n2: DOT11_MLME_EXTENDED"= ); + +/** + * prism54_mib_mode_helper - MIB change mode helper function + * @mib: the &struct islpci_mib object to modify + * @iw_mode: new mode (%IW_MODE_*) + *=20 + * This is a helper function, hence it does not lock. Make sure + * caller deals with locking *if* necessary. This function sets the=20 + * mode-dependent mib values and does the mapping of the Linux=20 + * Wireless API modes to Device firmware modes. It also checks for=20 + * correct valid Linux wireless modes.=20 + */ +int +prism54_mib_mode_helper(islpci_private *priv, u32 iw_mode) +{ + u32 config =3D INL_CONFIG_MANUALRUN; + u32 mode, bsstype; + + /* For now, just catch early the Repeater and Secondary modes here */ + if (iw_mode =3D=3D IW_MODE_REPEAT || iw_mode =3D=3D IW_MODE_SECOND) { + printk(KERN_DEBUG + "%s(): Sorry, Repeater mode and Secondary mode " + "are not yet supported by this driver.\n", __FUNCTION__); + return -EINVAL; + } + + priv->iw_mode =3D iw_mode; + + switch (iw_mode) { + case IW_MODE_AUTO: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_ANY; + break; + case IW_MODE_ADHOC: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_IBSS; + break; + case IW_MODE_INFRA: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_INFRA; + break; + case IW_MODE_MASTER: + mode =3D INL_MODE_AP; + bsstype =3D DOT11_BSSTYPE_INFRA; + break; + case IW_MODE_MONITOR: + mode =3D INL_MODE_PROMISCUOUS; + bsstype =3D DOT11_BSSTYPE_ANY; + config |=3D INL_CONFIG_RXANNEX; + break; + default: + return -EINVAL; + } + + if (init_wds) + config |=3D INL_CONFIG_WDS; + mgt_set(priv, DOT11_OID_BSSTYPE, &bsstype); + mgt_set(priv, OID_INL_CONFIG, &config); + mgt_set(priv, OID_INL_MODE, &mode); + + return 0; +} + +/** + * prism54_mib_init - fill MIB cache with defaults + * + * this function initializes the struct given as @mib with defaults, + * of which many are retrieved from the global module parameter + * variables. =20 + */ + +void +prism54_mib_init(islpci_private *priv) +{ + u32 t; + struct obj_buffer psm_buffer =3D { + .size =3D PSM_BUFFER_SIZE, + .addr =3D priv->device_psm_buffer + }; + + mgt_set(priv, DOT11_OID_CHANNEL, &init_channel); + mgt_set(priv, DOT11_OID_AUTHENABLE, &init_authen); + mgt_set(priv, DOT11_OID_PRIVACYINVOKED, &init_wep); + + mgt_set(priv, DOT11_OID_PSMBUFFER, &psm_buffer); + mgt_set(priv, DOT11_OID_EXUNENCRYPTED, &init_filter); + mgt_set(priv, DOT11_OID_DOT1XENABLE, &init_dot1x); + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &init_mlme); + mgt_set(priv, OID_INL_DOT11D_CONFORMANCE, &init_conformance); + + t =3D 127; + mgt_set(priv, OID_INL_OUTPUTPOWER, &t); + + /* Important: we are setting a default wireless mode and we are=20 + * forcing a valid one, so prism54_mib_mode_helper should just set + * mib values depending on what the wireless mode given is. No need + * for it save old values */ + if (init_mode > IW_MODE_MONITOR || init_mode < IW_MODE_AUTO) { + printk(KERN_DEBUG "%s(): You passed a non-valid init_mode. " + "Using default mode\n", __FUNCTION__); + init_mode =3D CARD_DEFAULT_IW_MODE; + } + /* This sets all of the mode-dependent values */ + prism54_mib_mode_helper(priv, init_mode); +} + +/* this will be executed outside of atomic context thanks to + * schedule_work(), thus we can as well use sleeping semaphore + * locking */ +void +prism54_update_stats(islpci_private *priv) +{ + char *data; + int j; + struct obj_bss bss, *bss2; + union oid_res_t r; + + if (down_interruptible(&priv->stats_sem)) + return; + +/* Noise floor. + * I'm not sure if the unit is dBm. + * Note : If we are not connected, this value seems to be irrelevant. */ + + mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); + priv->local_iwstatistics.qual.noise =3D r.u; + +/* Get the rssi of the link. To do this we need to retrieve a bss. */ + + /* First get the MAC address of the AP we are associated with. */ + mgt_get_request(priv, DOT11_OID_BSSID, 0, NULL, &r); + data =3D r.ptr; + + /* copy this MAC to the bss */ + memcpy(bss.address, data, 6); + kfree(data); + + /* now ask for the corresponding bss */ + j =3D mgt_get_request(priv, DOT11_OID_BSSFIND, 0, (void *) &bss, &r); + bss2 =3D r.ptr; + /* report the rssi and use it to calculate + * link quality through a signal-noise + * ratio */ + priv->local_iwstatistics.qual.level =3D bss2->rssi; + priv->local_iwstatistics.qual.qual =3D + bss2->rssi - priv->iwstatistics.qual.noise; + + kfree(bss2); + + /* report that the stats are new */ + priv->local_iwstatistics.qual.updated =3D 0x7; + +/* Rx : unable to decrypt the MPDU */ + mgt_get_request(priv, DOT11_OID_PRIVRXFAILED, 0, NULL, &r); + priv->local_iwstatistics.discard.code =3D r.u; + +/* Tx : Max MAC retries num reached */ + mgt_get_request(priv, DOT11_OID_MPDUTXFAILED, 0, NULL, &r); + priv->local_iwstatistics.discard.retries =3D r.u; + + up(&priv->stats_sem); + + return; +} + +struct iw_statistics * +prism54_get_wireless_stats(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + + /* If the stats are being updated return old data */ + if (down_trylock(&priv->stats_sem) =3D=3D 0) { + memcpy(&priv->iwstatistics, &priv->local_iwstatistics, + sizeof (struct iw_statistics)); + /* They won't be marked updated for the next time */ + priv->local_iwstatistics.qual.updated =3D 0; + up(&priv->stats_sem); + } else + priv->iwstatistics.qual.updated =3D 0; + + /* Update our wireless stats, but do not schedule to often=20 + * (max 1 HZ) */ + if ((priv->stats_timestamp =3D=3D 0) || + time_after(jiffies, priv->stats_timestamp + 1 * HZ)) { + schedule_work(&priv->stats_work); + priv->stats_timestamp =3D jiffies; + } + + return &priv->iwstatistics; +} + +static int +prism54_commit(struct net_device *ndev, struct iw_request_info *info, + char *cwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + /* simply re-set the last set SSID, this should commit most stuff */ + + /* Commit in Monitor mode is not necessary, also setting essid + * in Monitor mode does not make sense and isn't allowed for this + * device's firmware */ + if (priv->iw_mode !=3D IW_MODE_MONITOR) + return mgt_set_request(priv, DOT11_OID_SSID, 0, NULL); + return 0; +} + +static int +prism54_get_name(struct net_device *ndev, struct iw_request_info *info, + char *cwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + char *capabilities; + union oid_res_t r; + int rvalue; + + if (islpci_get_state(priv) < PRV_STATE_INIT) { + strncpy(cwrq, "NOT READY!", IFNAMSIZ); + return 0; + } + rvalue =3D mgt_get_request(priv, OID_INL_PHYCAPABILITIES, 0, NULL, &r); + + switch (r.u) { + case INL_PHYCAP_5000MHZ: + capabilities =3D "IEEE 802.11a/b/g"; + break; + case INL_PHYCAP_FAA: + capabilities =3D "IEEE 802.11b/g - FAA Support"; + break; + case INL_PHYCAP_2400MHZ: + default: + capabilities =3D "IEEE 802.11b/g"; /* Default */ + break; + } + strncpy(cwrq, capabilities, IFNAMSIZ); + return rvalue; +} + +static int +prism54_set_freq(struct net_device *ndev, struct iw_request_info *info, + struct iw_freq *fwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue; + u32 c; + + if (fwrq->m < 1000) + /* we have a channel number */ + c =3D fwrq->m; + else + c =3D (fwrq->e =3D=3D 1) ? channel_of_freq(fwrq->m / 100000) : 0; + + rvalue =3D c ? mgt_set_request(priv, DOT11_OID_CHANNEL, 0, &c) : -EINVAL; + + /* Call commit handler */ + return (rvalue ? rvalue : -EINPROGRESS); +} + +static int +prism54_get_freq(struct net_device *ndev, struct iw_request_info *info, + struct iw_freq *fwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_CHANNEL, 0, NULL, &r); + + fwrq->m =3D r.u; + fwrq->e =3D 0; + + return rvalue; +} + +static int +prism54_set_mode(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 mlmeautolevel =3D CARD_DEFAULT_MLME_MODE; + + /* Let's see if the user passed a valid Linux Wireless mode */ + if (*uwrq > IW_MODE_MONITOR || *uwrq < IW_MODE_AUTO) { + printk(KERN_DEBUG + "%s: %s() You passed a non-valid init_mode.\n", + priv->ndev->name, __FUNCTION__); + return -EINVAL; + } + + down_write(&priv->mib_sem); + + if (prism54_mib_mode_helper(priv, *uwrq)) { + up_write(&priv->mib_sem); + return -EOPNOTSUPP; + } + + /* the ACL code needs an intermediate mlmeautolevel. The wpa stuff an + * extended one. + */ + if ((*uwrq =3D=3D IW_MODE_MASTER) && (priv->acl.policy !=3D MAC_POLICY_OP= EN)) + mlmeautolevel =3D DOT11_MLME_INTERMEDIATE; + if (priv->wpa) + mlmeautolevel =3D DOT11_MLME_EXTENDED; + + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &mlmeautolevel); + + mgt_commit(priv); + priv->ndev->type =3D (priv->iw_mode =3D=3D IW_MODE_MONITOR) + ? priv->monitor_type : ARPHRD_ETHER; + up_write(&priv->mib_sem); + + return 0; +} + +/* Use mib cache */ +static int +prism54_get_mode(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + BUG_ON((priv->iw_mode < IW_MODE_AUTO) || (priv->iw_mode > + IW_MODE_MONITOR)); + *uwrq =3D priv->iw_mode; + + return 0; +} + +/* we use DOT11_OID_EDTHRESHOLD. From what I guess the card will not try to + * emit data if (sensitivity > rssi - noise) (in dBm). + * prism54_set_sens does not seem to work. + */ + +static int +prism54_set_sens(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 sens; + + /* by default the card sets this to 20. */ + sens =3D vwrq->disabled ? 20 : vwrq->value; + + return mgt_set_request(priv, DOT11_OID_EDTHRESHOLD, 0, &sens); +} + +static int +prism54_get_sens(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_EDTHRESHOLD, 0, NULL, &r); + + vwrq->value =3D r.u; + vwrq->disabled =3D (vwrq->value =3D=3D 0); + vwrq->fixed =3D 1; + + return rvalue; +} + +static int +prism54_get_range(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + struct iw_range *range =3D (struct iw_range *) extra; + islpci_private *priv =3D netdev_priv(ndev); + char *data; + int i, m, rvalue; + struct obj_frequencies *freq; + union oid_res_t r; + + memset(range, 0, sizeof (struct iw_range)); + dwrq->length =3D sizeof (struct iw_range); + + /* set the wireless extension version number */ + range->we_version_source =3D SUPPORTED_WIRELESS_EXT; + range->we_version_compiled =3D WIRELESS_EXT; + + /* Now the encoding capabilities */ + range->num_encoding_sizes =3D 3; + /* 64(40) bits WEP */ + range->encoding_size[0] =3D 5; + /* 128(104) bits WEP */ + range->encoding_size[1] =3D 13; + /* 256 bits for WPA-PSK */ + range->encoding_size[2] =3D 32; + /* 4 keys are allowed */ + range->max_encoding_tokens =3D 4; + + /* we don't know the quality range... */ + range->max_qual.level =3D 0; + range->max_qual.noise =3D 0; + range->max_qual.qual =3D 0; + /* these value describe an average quality. Needs more tweaking... */ + range->avg_qual.level =3D -80; /* -80 dBm */ + range->avg_qual.noise =3D 0; /* don't know what to put here */ + range->avg_qual.qual =3D 0; + + range->sensitivity =3D 200; + + /* retry limit capabilities */ + range->retry_capa =3D IW_RETRY_LIMIT | IW_RETRY_LIFETIME; + range->retry_flags =3D IW_RETRY_LIMIT; + range->r_time_flags =3D IW_RETRY_LIFETIME; + + /* I don't know the range. Put stupid things here */ + range->min_retry =3D 1; + range->max_retry =3D 65535; + range->min_r_time =3D 1024; + range->max_r_time =3D 65535 * 1024; + + /* txpower is supported in dBm's */ + range->txpower_capa =3D IW_TXPOW_DBM; + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return 0; + + /* Request the device for the supported frequencies + * not really relevant since some devices will report the 5 GHz band + * frequencies even if they don't support them. + */ + rvalue =3D + mgt_get_request(priv, DOT11_OID_SUPPORTEDFREQUENCIES, 0, NULL, &r); + freq =3D r.ptr; + + range->num_channels =3D freq->nr; + range->num_frequency =3D freq->nr; + + m =3D min(IW_MAX_FREQUENCIES, (int) freq->nr); + for (i =3D 0; i < m; i++) { + range->freq[i].m =3D freq->mhz[i]; + range->freq[i].e =3D 6; + range->freq[i].i =3D channel_of_freq(freq->mhz[i]); + } + kfree(freq); + + rvalue |=3D mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r); + data =3D r.ptr; + + /* We got an array of char. It is NULL terminated. */ + i =3D 0; + while ((i < IW_MAX_BITRATES) && (*data !=3D 0)) { + /* the result must be in bps. The card gives us 500Kbps */ + range->bitrate[i] =3D (__s32) (*data >> 1); + range->bitrate[i] *=3D 1000000; + i++; + data++; + } + range->num_bitrates =3D i; + kfree(r.ptr); + + return rvalue; +} + +/* Set AP address*/ + +static int +prism54_set_wap(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + char bssid[6]; + int rvalue; + + if (awrq->sa_family !=3D ARPHRD_ETHER) + return -EINVAL; + + /* prepare the structure for the set object */ + memcpy(&bssid[0], awrq->sa_data, 6); + + /* set the bssid -- does this make sense when in AP mode? */ + rvalue =3D mgt_set_request(priv, DOT11_OID_BSSID, 0, &bssid); + + return (rvalue ? rvalue : -EINPROGRESS); /* Call commit handler */ +} + +/* get AP address*/ + +static int +prism54_get_wap(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_BSSID, 0, NULL, &r); + memcpy(awrq->sa_data, r.ptr, 6); + awrq->sa_family =3D ARPHRD_ETHER; + kfree(r.ptr); + + return rvalue; +} + +static int +prism54_set_scan(struct net_device *dev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + /* hehe the device does this automagicaly */ + return 0; +} + +/* a little helper that will translate our data into a card independent + * format that the Wireless Tools will understand. This was inspired by + * the "Aironet driver for 4500 and 4800 series cards" (GPL) + */ + +static char * +prism54_translate_bss(struct net_device *ndev, char *current_ev, + char *end_buf, struct obj_bss *bss, char noise) +{ + struct iw_event iwe; /* Temporary buffer */ + short cap; + islpci_private *priv =3D netdev_priv(ndev); + + /* The first entry must be the MAC address */ + memcpy(iwe.u.ap_addr.sa_data, bss->address, 6); + iwe.u.ap_addr.sa_family =3D ARPHRD_ETHER; + iwe.cmd =3D SIOCGIWAP; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_ADDR_LEN); + + /* The following entries will be displayed in the same order we give them= */ + + /* The ESSID. */ + iwe.u.data.length =3D bss->ssid.length; + iwe.u.data.flags =3D 1; + iwe.cmd =3D SIOCGIWESSID; + current_ev =3D iwe_stream_add_point(current_ev, end_buf, + &iwe, bss->ssid.octets); + + /* Capabilities */ +#define CAP_ESS 0x01 +#define CAP_IBSS 0x02 +#define CAP_CRYPT 0x10 + + /* Mode */ + cap =3D bss->capinfo; + iwe.u.mode =3D 0; + if (cap & CAP_ESS) + iwe.u.mode =3D IW_MODE_MASTER; + else if (cap & CAP_IBSS) + iwe.u.mode =3D IW_MODE_ADHOC; + iwe.cmd =3D SIOCGIWMODE; + if (iwe.u.mode) + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, + IW_EV_UINT_LEN); + + /* Encryption capability */ + if (cap & CAP_CRYPT) + iwe.u.data.flags =3D IW_ENCODE_ENABLED | IW_ENCODE_NOKEY; + else + iwe.u.data.flags =3D IW_ENCODE_DISABLED; + iwe.u.data.length =3D 0; + iwe.cmd =3D SIOCGIWENCODE; + current_ev =3D iwe_stream_add_point(current_ev, end_buf, &iwe, NULL); + + /* Add frequency. (short) bss->channel is the frequency in MHz */ + iwe.u.freq.m =3D channel_of_freq(bss->channel); + iwe.u.freq.e =3D 0; + iwe.cmd =3D SIOCGIWFREQ; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); + + /* Add quality statistics */ + iwe.u.qual.level =3D bss->rssi; + iwe.u.qual.noise =3D noise; + /* do a simple SNR for quality */ + iwe.u.qual.qual =3D bss->rssi - noise; + iwe.cmd =3D IWEVQUAL; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_QUAL_LEN); + + if (priv->wpa) { + u8 wpa_ie[MAX_WPA_IE_LEN]; + char *buf, *p; + size_t wpa_ie_len; + int i; + + wpa_ie_len =3D prism54_wpa_ie_get(priv, bss->address, wpa_ie); + if (wpa_ie_len > 0 && + (buf =3D kmalloc(wpa_ie_len * 2 + 10, GFP_ATOMIC))) { + p =3D buf; + p +=3D sprintf(p, "wpa_ie=3D"); + for (i =3D 0; i < wpa_ie_len; i++) { + p +=3D sprintf(p, "%02x", wpa_ie[i]); + } + memset(&iwe, 0, sizeof (iwe)); + iwe.cmd =3D IWEVCUSTOM; + iwe.u.data.length =3D strlen(buf); + current_ev =3D iwe_stream_add_point(current_ev, end_buf, + &iwe, buf); + kfree(buf); + } + } + return current_ev; +} + +int +prism54_get_scan(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int i, rvalue; + struct obj_bsslist *bsslist; + u32 noise =3D 0; + char *current_ev =3D extra; + union oid_res_t r; + + if (islpci_get_state(priv) < PRV_STATE_INIT) { + /* device is not ready, fail gently */ + dwrq->length =3D 0; + return 0; + } + + /* first get the noise value. We will use it to report the link quality */ + rvalue =3D mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); + noise =3D r.u; + + /* Ask the device for a list of known bss. We can report at most + * IW_MAX_AP=3D64 to the range struct. But the device won't repport anyth= ing + * if you change the value of IWMAX_BSS=3D24. + */ + rvalue |=3D mgt_get_request(priv, DOT11_OID_BSSLIST, 0, NULL, &r); + bsslist =3D r.ptr; + + /* ok now, scan the list and translate its info */ + for (i =3D 0; i < min(IW_MAX_AP, (int) bsslist->nr); i++) + current_ev =3D prism54_translate_bss(ndev, current_ev, + extra + IW_SCAN_MAX_DATA, + &(bsslist->bsslist[i]), + noise); + kfree(bsslist); + dwrq->length =3D (current_ev - extra); + dwrq->flags =3D 0; /* todo */ + + return rvalue; +} + +static int +prism54_set_essid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_ssid essid; + + memset(essid.octets, 0, 33); + + /* Check if we were asked for `any' */ + if (dwrq->flags && dwrq->length) { + if (dwrq->length > min(33, IW_ESSID_MAX_SIZE + 1)) + return -E2BIG; + essid.length =3D dwrq->length - 1; + memcpy(essid.octets, extra, dwrq->length); + } else + essid.length =3D 0; + + if (priv->iw_mode !=3D IW_MODE_MONITOR) + return mgt_set_request(priv, DOT11_OID_SSID, 0, &essid); + + /* If in monitor mode, just save to mib */ + mgt_set(priv, DOT11_OID_SSID, &essid); + return 0; + +} + +static int +prism54_get_essid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_ssid *essid; + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_SSID, 0, NULL, &r); + essid =3D r.ptr; + + if (essid->length) { + dwrq->flags =3D 1; /* set ESSID to ON for Wireless Extensions */ + /* if it is to big, trunk it */ + dwrq->length =3D min(IW_ESSID_MAX_SIZE, essid->length + 1); + } else { + dwrq->flags =3D 0; + dwrq->length =3D 0; + } + essid->octets[essid->length] =3D '\0'; + memcpy(extra, essid->octets, dwrq->length); + kfree(essid); + + return rvalue; +} + +/* Provides no functionality, just completes the ioctl. In essence this is= a=20 + * just a cosmetic ioctl. + */ +static int +prism54_set_nick(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + if (dwrq->length > IW_ESSID_MAX_SIZE) + return -E2BIG; + + down_write(&priv->mib_sem); + memset(priv->nickname, 0, sizeof (priv->nickname)); + memcpy(priv->nickname, extra, dwrq->length); + up_write(&priv->mib_sem); + + return 0; +} + +static int +prism54_get_nick(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + dwrq->length =3D 0; + + down_read(&priv->mib_sem); + dwrq->length =3D strlen(priv->nickname) + 1; + memcpy(extra, priv->nickname, dwrq->length); + up_read(&priv->mib_sem); + + return 0; +} + +/* Set the allowed Bitrates */ + +static int +prism54_set_rate(struct net_device *ndev, + struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + + islpci_private *priv =3D netdev_priv(ndev); + u32 rate, profile; + char *data; + int ret, i; + union oid_res_t r; + + if (vwrq->value =3D=3D -1) { + /* auto mode. No limit. */ + profile =3D 1; + return mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); + } + + if ((ret =3D + mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r))) + return ret; + + rate =3D (u32) (vwrq->value / 500000); + data =3D r.ptr; + i =3D 0; + + while (data[i]) { + if (rate && (data[i] =3D=3D rate)) { + break; + } + if (vwrq->value =3D=3D i) { + break; + } + data[i] |=3D 0x80; + i++; + } + + if (!data[i]) { + return -EINVAL; + } + + data[i] |=3D 0x80; + data[i + 1] =3D 0; + + /* Now, check if we want a fixed or auto value */ + if (vwrq->fixed) { + data[0] =3D data[i]; + data[1] =3D 0; + } + +/* + i =3D 0; + printk("prism54 rate: "); + while(data[i]) { + printk("%u ", data[i]); + i++; + } + printk("0\n"); +*/ + profile =3D -1; + ret =3D mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); + ret |=3D mgt_set_request(priv, DOT11_OID_EXTENDEDRATES, 0, data); + ret |=3D mgt_set_request(priv, DOT11_OID_RATES, 0, data); + + kfree(r.ptr); + + return ret; +} + +/* Get the current bit rate */ +static int +prism54_get_rate(struct net_device *ndev, + struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue; + char *data; + union oid_res_t r; + + /* Get the current bit rate */ + if ((rvalue =3D mgt_get_request(priv, GEN_OID_LINKSTATE, 0, NULL, &r))) + return rvalue; + vwrq->value =3D r.u * 500000; + + /* request the device for the enabled rates */ + if ((rvalue =3D mgt_get_request(priv, DOT11_OID_RATES, 0, NULL, &r))) + return rvalue; + data =3D r.ptr; + vwrq->fixed =3D (data[0] !=3D 0) && (data[1] =3D=3D 0); + kfree(r.ptr); + + return 0; +} + +static int +prism54_set_rts(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + return mgt_set_request(priv, DOT11_OID_RTSTHRESH, 0, &vwrq->value); +} + +static int +prism54_get_rts(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + /* get the rts threshold */ + rvalue =3D mgt_get_request(priv, DOT11_OID_RTSTHRESH, 0, NULL, &r); + vwrq->value =3D r.u; + + return rvalue; +} + +static int +prism54_set_frag(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + return mgt_set_request(priv, DOT11_OID_FRAGTHRESH, 0, &vwrq->value); +} + +static int +prism54_get_frag(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_FRAGTHRESH, 0, NULL, &r); + vwrq->value =3D r.u; + + return rvalue; +} + +/* Here we have (min,max) =3D max retries for (small frames, big frames). = Where + * big frame <=3D> bigger than the rts threshold + * small frame <=3D> smaller than the rts threshold + * This is not really the behavior expected by the wireless tool but it se= ems + * to be a common behavior in other drivers. + */ + +static int +prism54_set_retry(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 slimit =3D 0, llimit =3D 0; /* short and long limit */ + u32 lifetime =3D 0; + int rvalue =3D 0; + + if (vwrq->disabled) + /* we cannot disable this feature */ + return -EINVAL; + + if (vwrq->flags & IW_RETRY_LIMIT) { + if (vwrq->flags & IW_RETRY_MIN) + slimit =3D vwrq->value; + else if (vwrq->flags & IW_RETRY_MAX) + llimit =3D vwrq->value; + else { + /* we are asked to set both */ + slimit =3D vwrq->value; + llimit =3D vwrq->value; + } + } + if (vwrq->flags & IW_RETRY_LIFETIME) + /* Wireless tools use us unit while the device uses 1024 us unit */ + lifetime =3D vwrq->value / 1024; + + /* now set what is requested */ + if (slimit) + rvalue =3D + mgt_set_request(priv, DOT11_OID_SHORTRETRIES, 0, &slimit); + if (llimit) + rvalue |=3D + mgt_set_request(priv, DOT11_OID_LONGRETRIES, 0, &llimit); + if (lifetime) + rvalue |=3D + mgt_set_request(priv, DOT11_OID_MAXTXLIFETIME, 0, + &lifetime); + return rvalue; +} + +static int +prism54_get_retry(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue =3D 0; + vwrq->disabled =3D 0; /* It cannot be disabled */ + + if ((vwrq->flags & IW_RETRY_TYPE) =3D=3D IW_RETRY_LIFETIME) { + /* we are asked for the life time */ + rvalue =3D + mgt_get_request(priv, DOT11_OID_MAXTXLIFETIME, 0, NULL, &r); + vwrq->value =3D r.u * 1024; + vwrq->flags =3D IW_RETRY_LIFETIME; + } else if ((vwrq->flags & IW_RETRY_MAX)) { + /* we are asked for the long retry limit */ + rvalue |=3D + mgt_get_request(priv, DOT11_OID_LONGRETRIES, 0, NULL, &r); + vwrq->value =3D r.u; + vwrq->flags =3D IW_RETRY_LIMIT | IW_RETRY_MAX; + } else { + /* default. get the short retry limit */ + rvalue |=3D + mgt_get_request(priv, DOT11_OID_SHORTRETRIES, 0, NULL, &r); + vwrq->value =3D r.u; + vwrq->flags =3D IW_RETRY_LIMIT | IW_RETRY_MIN; + } + + return rvalue; +} + +static int +prism54_set_encode(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue =3D 0, force =3D 0; + int authen =3D DOT11_AUTH_OS, invoke =3D 0, exunencrypt =3D 0; + union oid_res_t r; + + /* with the new API, it's impossible to get a NULL pointer. + * New version of iwconfig set the IW_ENCODE_NOKEY flag + * when no key is given, but older versions don't. */ + + if (dwrq->length > 0) { + /* we have a key to set */ + int index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + int current_index; + struct obj_key key =3D { DOT11_PRIV_WEP, 0, "" }; + + /* get the current key index */ + rvalue =3D mgt_get_request(priv, DOT11_OID_DEFKEYID, 0, NULL, &r); + current_index =3D r.u; + /* Verify that the key is not marked as invalid */ + if (!(dwrq->flags & IW_ENCODE_NOKEY)) { + key.length =3D dwrq->length > sizeof (key.key) ? + sizeof (key.key) : dwrq->length; + memcpy(key.key, extra, key.length); + if (key.length =3D=3D 32) + /* we want WPA-PSK */ + key.type =3D DOT11_PRIV_TKIP; + if ((index < 0) || (index > 3)) + /* no index provided use the current one */ + index =3D current_index; + + /* now send the key to the card */ + rvalue |=3D + mgt_set_request(priv, DOT11_OID_DEFKEYX, index, + &key); + } + /* + * If a valid key is set, encryption should be enabled=20 + * (user may turn it off later). + * This is also how "iwconfig ethX key on" works + */ + if ((index =3D=3D current_index) && (key.length > 0)) + force =3D 1; + } else { + int index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + if ((index >=3D 0) && (index <=3D 3)) { + /* we want to set the key index */ + rvalue |=3D + mgt_set_request(priv, DOT11_OID_DEFKEYID, 0, + &index); + } else { + if (!dwrq->flags & IW_ENCODE_MODE) { + /* we cannot do anything. Complain. */ + return -EINVAL; + } + } + } + /* now read the flags */ + if (dwrq->flags & IW_ENCODE_DISABLED) { + /* Encoding disabled,=20 + * authen =3D DOT11_AUTH_OS; + * invoke =3D 0; + * exunencrypt =3D 0; */ + } + if (dwrq->flags & IW_ENCODE_OPEN) + /* Encode but accept non-encoded packets. No auth */ + invoke =3D 1; + if ((dwrq->flags & IW_ENCODE_RESTRICTED) || force) { + /* Refuse non-encoded packets. Auth */ + authen =3D DOT11_AUTH_BOTH; + invoke =3D 1; + exunencrypt =3D 1; + } + /* do the change if requested */ + if ((dwrq->flags & IW_ENCODE_MODE) || force) { + rvalue |=3D + mgt_set_request(priv, DOT11_OID_AUTHENABLE, 0, &authen); + rvalue |=3D + mgt_set_request(priv, DOT11_OID_PRIVACYINVOKED, 0, &invoke); + rvalue |=3D + mgt_set_request(priv, DOT11_OID_EXUNENCRYPTED, 0, + &exunencrypt); + } + return rvalue; +} + +static int +prism54_get_encode(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_key *key; + u32 devindex, index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + u32 authen =3D 0, invoke =3D 0, exunencrypt =3D 0; + int rvalue; + union oid_res_t r; + + /* first get the flags */ + rvalue =3D mgt_get_request(priv, DOT11_OID_AUTHENABLE, 0, NULL, &r); + authen =3D r.u; + rvalue |=3D mgt_get_request(priv, DOT11_OID_PRIVACYINVOKED, 0, NULL, &r); + invoke =3D r.u; + rvalue |=3D mgt_get_request(priv, DOT11_OID_EXUNENCRYPTED, 0, NULL, &r); + exunencrypt =3D r.u; + + if (invoke && (authen =3D=3D DOT11_AUTH_BOTH) && exunencrypt) + dwrq->flags =3D IW_ENCODE_RESTRICTED; + else if ((authen =3D=3D DOT11_AUTH_OS) && !exunencrypt) { + if (invoke) + dwrq->flags =3D IW_ENCODE_OPEN; + else + dwrq->flags =3D IW_ENCODE_DISABLED; + } else + /* The card should not work in this state */ + dwrq->flags =3D 0; + + /* get the current device key index */ + rvalue |=3D mgt_get_request(priv, DOT11_OID_DEFKEYID, 0, NULL, &r); + devindex =3D r.u; + /* Now get the key, return it */ + if ((index < 0) || (index > 3)) + /* no index provided, use the current one */ + index =3D devindex; + rvalue |=3D mgt_get_request(priv, DOT11_OID_DEFKEYX, index, NULL, &r); + key =3D r.ptr; + dwrq->length =3D key->length; + memcpy(extra, key->key, dwrq->length); + kfree(key); + /* return the used key index */ + dwrq->flags |=3D devindex + 1; + + return rvalue; +} + +static int +prism54_get_txpower(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, OID_INL_OUTPUTPOWER, 0, NULL, &r); + /* intersil firmware operates in 0.25 dBm (1/4 dBm) */ + vwrq->value =3D (s32) r.u / 4; + vwrq->fixed =3D 1; + /* radio is not turned of + * btw: how is possible to turn off only the radio=20 + */ + vwrq->disabled =3D 0; + + return rvalue; +} + +static int +prism54_set_txpower(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + s32 u =3D vwrq->value; + + /* intersil firmware operates in 0.25 dBm (1/4) */ + u *=3D 4; + if (vwrq->disabled) { + /* don't know how to disable radio */ + printk(KERN_DEBUG + "%s: %s() disabling radio is not yet supported.\n", + priv->ndev->name, __FUNCTION__); + return -ENOTSUPP; + } else if (vwrq->fixed) + /* currently only fixed value is supported */ + return mgt_set_request(priv, OID_INL_OUTPUTPOWER, 0, &u); + else { + printk(KERN_DEBUG + "%s: %s() auto power will be implemented later.\n", + priv->ndev->name, __FUNCTION__); + return -ENOTSUPP; + } +} + +static int +prism54_reset(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_reset(netdev_priv(ndev), 0); + + return 0; +} + +static int +prism54_get_oid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + union oid_res_t r; + int rvalue; + enum oid_num_t n =3D dwrq->flags; + + rvalue =3D mgt_get_request((islpci_private *) ndev->priv, n, 0, NULL, &r); + dwrq->length =3D mgt_response_to_str(n, &r, extra); + if ((isl_oid[n].flags & OID_FLAG_TYPE) !=3D OID_TYPE_U32) + kfree(r.ptr); + return rvalue; +} + +static int +prism54_set_u32(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + u32 oid =3D uwrq[0], u =3D uwrq[1]; + + return mgt_set_request((islpci_private *) ndev->priv, oid, 0, &u); +} + +static int +prism54_set_raw(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + u32 oid =3D dwrq->flags; + + return mgt_set_request((islpci_private *) ndev->priv, oid, 0, extra); +} + +void +prism54_acl_init(struct islpci_acl *acl) +{ + sema_init(&acl->sem, 1); + INIT_LIST_HEAD(&acl->mac_list); + acl->size =3D 0; + acl->policy =3D MAC_POLICY_OPEN; +} + +static void +prism54_clear_mac(struct islpci_acl *acl) +{ + struct list_head *ptr, *next; + struct mac_entry *entry; + + if (down_interruptible(&acl->sem)) + return; + + if (acl->size =3D=3D 0) { + up(&acl->sem); + return; + } + + for (ptr =3D acl->mac_list.next, next =3D ptr->next; + ptr !=3D &acl->mac_list; ptr =3D next, next =3D ptr->next) { + entry =3D list_entry(ptr, struct mac_entry, _list); + list_del(ptr); + kfree(entry); + } + acl->size =3D 0; + up(&acl->sem); +} + +void +prism54_acl_clean(struct islpci_acl *acl) +{ + prism54_clear_mac(acl); +} + +static int +prism54_add_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct sockaddr *addr =3D (struct sockaddr *) extra; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + entry =3D kmalloc(sizeof (struct mac_entry), GFP_KERNEL); + if (entry =3D=3D NULL) + return -ENOMEM; + + memcpy(entry->addr, addr->sa_data, ETH_ALEN); + + if (down_interruptible(&acl->sem)) { + kfree(entry); + return -ERESTARTSYS; + } + list_add_tail(&entry->_list, &acl->mac_list); + acl->size++; + up(&acl->sem); + + return 0; +} + +static int +prism54_del_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct list_head *ptr; + struct sockaddr *addr =3D (struct sockaddr *) extra; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + + if (memcmp(entry->addr, addr->sa_data, ETH_ALEN) =3D=3D 0) { + list_del(ptr); + acl->size--; + kfree(entry); + up(&acl->sem); + return 0; + } + } + up(&acl->sem); + return -EINVAL; +} + +static int +prism54_get_mac(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct list_head *ptr; + struct sockaddr *dst =3D (struct sockaddr *) extra; + + dwrq->length =3D 0; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + + memcpy(dst->sa_data, entry->addr, ETH_ALEN); + dst->sa_family =3D ARPHRD_ETHER; + dwrq->length++; + dst++; + } + up(&acl->sem); + return 0; +} + +/* Setting policy also clears the MAC acl, even if we don't change the def= aut + * policy + */ + +static int +prism54_set_policy(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + u32 mlmeautolevel; + + prism54_clear_mac(acl); + + if ((*uwrq < MAC_POLICY_OPEN) || (*uwrq > MAC_POLICY_REJECT)) + return -EINVAL; + + down_write(&priv->mib_sem); + + acl->policy =3D *uwrq; + + /* the ACL code needs an intermediate mlmeautolevel */ + if ((priv->iw_mode =3D=3D IW_MODE_MASTER) && + (acl->policy !=3D MAC_POLICY_OPEN)) + mlmeautolevel =3D DOT11_MLME_INTERMEDIATE; + else + mlmeautolevel =3D CARD_DEFAULT_MLME_MODE; + if (priv->wpa) + mlmeautolevel =3D DOT11_MLME_EXTENDED; + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &mlmeautolevel); + /* restart the card with our new policy */ + mgt_commit(priv); + up_write(&priv->mib_sem); + + return 0; +} + +static int +prism54_get_policy(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + + *uwrq =3D acl->policy; + + return 0; +} + +/* Return 1 only if client should be accepted. */ + +static int +prism54_mac_accept(struct islpci_acl *acl, char *mac) +{ + struct list_head *ptr; + struct mac_entry *entry; + int res =3D 0; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + + if (acl->policy =3D=3D MAC_POLICY_OPEN) { + up(&acl->sem); + return 1; + } + + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + if (memcmp(entry->addr, mac, ETH_ALEN) =3D=3D 0) { + res =3D 1; + break; + } + } + res =3D (acl->policy =3D=3D MAC_POLICY_ACCEPT) ? !res : res; + up(&acl->sem); + + return res; +} + +static int +prism54_kick_all(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + struct obj_mlme *mlme; + int rvalue; + + mlme =3D kmalloc(sizeof (struct obj_mlme), GFP_KERNEL); + if (mlme =3D=3D NULL) + return -ENOMEM; + + /* Tell the card to kick every client */ + mlme->id =3D 0; + rvalue =3D + mgt_set_request(netdev_priv(ndev), DOT11_OID_DISASSOCIATE, 0, mlme); + kfree(mlme); + + return rvalue; +} + +static int +prism54_kick_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + struct obj_mlme *mlme; + struct sockaddr *addr =3D (struct sockaddr *) extra; + int rvalue; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + mlme =3D kmalloc(sizeof (struct obj_mlme), GFP_KERNEL); + if (mlme =3D=3D NULL) + return -ENOMEM; + + /* Tell the card to only kick the corresponding bastard */ + memcpy(mlme->address, addr->sa_data, ETH_ALEN); + mlme->id =3D -1; + rvalue =3D + mgt_set_request(netdev_priv(ndev), DOT11_OID_DISASSOCIATE, 0, mlme); + + kfree(mlme); + + return rvalue; +} + +/* Translate a TRAP oid into a wireless event. Called in islpci_mgt_receiv= e. */ + +static void +format_event(islpci_private *priv, char *dest, const char *str, + const struct obj_mlme *mlme, u16 *length, int error) +{ + const u8 *a =3D mlme->address; + int n =3D snprintf(dest, IW_CUSTOM_MAX, + "%s %s %2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X %s (%2.2X)", + str, + ((priv->iw_mode =3D=3D IW_MODE_MASTER) ? "from" : "to"), + a[0], a[1], a[2], a[3], a[4], a[5], + (error ? (mlme->code ? " : REJECTED " : " : ACCEPTED ") + : ""), mlme->code); + BUG_ON(n > IW_CUSTOM_MAX); + *length =3D n; +} + +static void +send_formatted_event(islpci_private *priv, const char *str, + const struct obj_mlme *mlme, int error) +{ + union iwreq_data wrqu; + + wrqu.data.pointer =3D kmalloc(IW_CUSTOM_MAX, GFP_KERNEL); + if (!wrqu.data.pointer) + return; + wrqu.data.length =3D 0; + format_event(priv, wrqu.data.pointer, str, mlme, &wrqu.data.length, + error); + wireless_send_event(priv->ndev, IWEVCUSTOM, &wrqu, wrqu.data.pointer); + kfree(wrqu.data.pointer); +} + +static void +send_simple_event(islpci_private *priv, const char *str) +{ + union iwreq_data wrqu; + int n =3D strlen(str); + + wrqu.data.pointer =3D kmalloc(IW_CUSTOM_MAX, GFP_KERNEL); + if (!wrqu.data.pointer) + return; + BUG_ON(n > IW_CUSTOM_MAX); + wrqu.data.length =3D n; + strcpy(wrqu.data.pointer, str); + wireless_send_event(priv->ndev, IWEVCUSTOM, &wrqu, wrqu.data.pointer); + kfree(wrqu.data.pointer); +} + +static void +link_changed(struct net_device *ndev, u32 bitrate) +{ + islpci_private *priv =3D netdev_priv(ndev); + + if (bitrate) { + if (priv->iw_mode =3D=3D IW_MODE_INFRA) { + union iwreq_data uwrq; + prism54_get_wap(ndev, NULL, (struct sockaddr *) &uwrq, + NULL); + wireless_send_event(ndev, SIOCGIWAP, &uwrq, NULL); + } else + send_simple_event(netdev_priv(ndev), + "Link established"); + } else + send_simple_event(netdev_priv(ndev), "Link lost"); +} + +/* Beacon/ProbeResp payload header */ +struct ieee80211_beacon_phdr { + u8 timestamp[8]; + u16 beacon_int; + u16 capab_info; +} __attribute__ ((packed)); + +#define WLAN_EID_GENERIC 0xdd +static u8 wpa_oid[4] =3D { 0x00, 0x50, 0xf2, 1 }; + +#define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5] +#define MACSTR "%02x:%02x:%02x:%02x:%02x:%02x" + +void +prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len) +{ + struct list_head *ptr; + struct islpci_bss_wpa_ie *bss =3D NULL; + + if (wpa_ie_len > MAX_WPA_IE_LEN) + wpa_ie_len =3D MAX_WPA_IE_LEN; + + if (down_interruptible(&priv->wpa_sem)) + return; + + /* try to use existing entry */ + list_for_each(ptr, &priv->bss_wpa_list) { + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + if (memcmp(bss->bssid, bssid, ETH_ALEN) =3D=3D 0) { + list_move(&bss->list, &priv->bss_wpa_list); + break; + } + bss =3D NULL; + } + + if (bss =3D=3D NULL) { + /* add a new BSS entry; if max number of entries is already + * reached, replace the least recently updated */ + if (priv->num_bss_wpa >=3D MAX_BSS_WPA_IE_COUNT) { + bss =3D list_entry(priv->bss_wpa_list.prev, + struct islpci_bss_wpa_ie, list); + list_del(&bss->list); + } else { + bss =3D kmalloc(sizeof (*bss), GFP_ATOMIC); + if (bss !=3D NULL) { + priv->num_bss_wpa++; + memset(bss, 0, sizeof (*bss)); + } + } + if (bss !=3D NULL) { + memcpy(bss->bssid, bssid, ETH_ALEN); + list_add(&bss->list, &priv->bss_wpa_list); + } + } + + if (bss !=3D NULL) { + memcpy(bss->wpa_ie, wpa_ie, wpa_ie_len); + bss->wpa_ie_len =3D wpa_ie_len; + bss->last_update =3D jiffies; + } else { + printk(KERN_DEBUG "Failed to add BSS WPA entry for " MACSTR + "\n", MAC2STR(bssid)); + } + + /* expire old entries from WPA list */ + while (priv->num_bss_wpa > 0) { + bss =3D list_entry(priv->bss_wpa_list.prev, + struct islpci_bss_wpa_ie, list); + if (!time_after(jiffies, bss->last_update + 60 * HZ)) + break; + + list_del(&bss->list); + priv->num_bss_wpa--; + kfree(bss); + } + + up(&priv->wpa_sem); +} + +size_t +prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie) +{ + struct list_head *ptr; + struct islpci_bss_wpa_ie *bss =3D NULL; + size_t len =3D 0; + + if (down_interruptible(&priv->wpa_sem)) + return 0; + + list_for_each(ptr, &priv->bss_wpa_list) { + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + if (memcmp(bss->bssid, bssid, ETH_ALEN) =3D=3D 0) + break; + bss =3D NULL; + } + if (bss) { + len =3D bss->wpa_ie_len; + memcpy(wpa_ie, bss->wpa_ie, len); + } + up(&priv->wpa_sem); + + return len; +} + +void +prism54_wpa_ie_init(islpci_private *priv) +{ + INIT_LIST_HEAD(&priv->bss_wpa_list); + sema_init(&priv->wpa_sem, 1); +} + +void +prism54_wpa_ie_clean(islpci_private *priv) +{ + struct list_head *ptr, *n; + + list_for_each_safe(ptr, n, &priv->bss_wpa_list) { + struct islpci_bss_wpa_ie *bss; + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + kfree(bss); + } +} + +static void +prism54_process_bss_data(islpci_private *priv, u32 oid, u8 *addr, + u8 *payload, size_t len) +{ + struct ieee80211_beacon_phdr *hdr; + u8 *pos, *end; + + if (!priv->wpa) + return; + + hdr =3D (struct ieee80211_beacon_phdr *) payload; + pos =3D (u8 *) (hdr + 1); + end =3D payload + len; + while (pos < end) { + if (pos + 2 + pos[1] > end) { + printk(KERN_DEBUG "Parsing Beacon/ProbeResp failed " + "for " MACSTR "\n", MAC2STR(addr)); + return; + } + if (pos[0] =3D=3D WLAN_EID_GENERIC && pos[1] >=3D 4 && + memcmp(pos + 2, wpa_oid, 4) =3D=3D 0) { + prism54_wpa_ie_add(priv, addr, pos, pos[1] + 2); + return; + } + pos +=3D 2 + pos[1]; + } +} + +static void +handle_request(islpci_private *priv, struct obj_mlme *mlme, enum oid_num_t= oid) +{ + if (((mlme->state =3D=3D DOT11_STATE_AUTHING) || + (mlme->state =3D=3D DOT11_STATE_ASSOCING)) + && mgt_mlme_answer(priv)) { + /* Someone is requesting auth and we must respond. Just send back + * the trap with error code set accordingly. + */ + mlme->code =3D prism54_mac_accept(&priv->acl, + mlme->address) ? 0 : 1; + mgt_set_request(priv, oid, 0, mlme); + } +} + +int +prism54_process_trap_helper(islpci_private *priv, enum oid_num_t oid, + char *data) +{ + struct obj_mlme *mlme =3D (struct obj_mlme *) data; + size_t len; + u8 *payload, *pos =3D (u8 *) (mlme + 1); + + len =3D pos[0] | (pos[1] << 8); /* little endian data length */ + payload =3D pos + 2; + + /* I think all trapable objects are listed here. + * Some oids have a EX version. The difference is that they are emitted + * in DOT11_MLME_EXTENDED mode (set with DOT11_OID_MLMEAUTOLEVEL) + * with more info. + * The few events already defined by the wireless tools are not really + * suited. We use the more flexible custom event facility. + */ + + /* I fear prism54_process_bss_data won't work with big endian data */ + if ((oid =3D=3D DOT11_OID_BEACON) || (oid =3D=3D DOT11_OID_PROBE)) + prism54_process_bss_data(priv, oid, mlme->address, + payload, len); + + mgt_le_to_cpu(isl_oid[oid].flags & OID_FLAG_TYPE, (void *) mlme); + + switch (oid) { + + case GEN_OID_LINKSTATE: + link_changed(priv->ndev, (u32) *data); + break; + + case DOT11_OID_MICFAILURE: + send_simple_event(priv, "Mic failure"); + break; + + case DOT11_OID_DEAUTHENTICATE: + send_formatted_event(priv, "DeAuthenticate request", mlme, 0); + break; + + case DOT11_OID_AUTHENTICATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Authenticate request", mlme, 1); + break; + + case DOT11_OID_DISASSOCIATE: + send_formatted_event(priv, "Disassociate request", mlme, 0); + break; + + case DOT11_OID_ASSOCIATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Associate request", mlme, 1); + break; + + case DOT11_OID_REASSOCIATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "ReAssociate request", mlme, 1); + break; + + case DOT11_OID_BEACON: + send_formatted_event(priv, + "Received a beacon from an unkown AP", + mlme, 0); + break; + + case DOT11_OID_PROBE: + /* we received a probe from a client. */ + send_formatted_event(priv, "Received a probe from client", mlme, + 0); + break; + + /* Note : "mlme" is actually a "struct obj_mlmeex *" here, but this + * is backward compatible layout-wise with "struct obj_mlme". + */ + + case DOT11_OID_DEAUTHENTICATEEX: + send_formatted_event(priv, "DeAuthenticate request", mlme, 0); + break; + + case DOT11_OID_AUTHENTICATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Authenticate request", mlme, 1); + break; + + case DOT11_OID_DISASSOCIATEEX: + send_formatted_event(priv, "Disassociate request", mlme, 0); + break; + + case DOT11_OID_ASSOCIATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Associate request", mlme, 1); + break; + + case DOT11_OID_REASSOCIATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Reassociate request", mlme, 1); + break; + + default: + return -EINVAL; + } + + return 0; +} + +/* + * Process a device trap. This is called via schedule_work(), outside of + * interrupt context, no locks held. + */ +void +prism54_process_trap(void *data) +{ + struct islpci_mgmtframe *frame =3D data; + struct net_device *ndev =3D frame->ndev; + enum oid_num_t n =3D mgt_oidtonum(frame->header->oid); + + if (n !=3D OID_NUM_LAST) + prism54_process_trap_helper(netdev_priv(ndev), n, frame->data); + islpci_mgt_release(frame); +} + +int +prism54_set_mac_address(struct net_device *ndev, void *addr) +{ + islpci_private *priv =3D netdev_priv(ndev); + int ret; + + if (ndev->addr_len !=3D 6) + return -EINVAL; + ret =3D mgt_set_request(priv, GEN_OID_MACADDRESS, 0, + &((struct sockaddr *) addr)->sa_data); + if (!ret) + memcpy(priv->ndev->dev_addr, + &((struct sockaddr *) addr)->sa_data, 6); + + return ret; +} + +int +prism54_set_wpa(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + down_write(&priv->mib_sem); + + priv->wpa =3D *uwrq; + if (priv->wpa) { + u32 l =3D DOT11_MLME_EXTENDED; + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &l); + } + /* restart the card with new level. Needed ? */ + mgt_commit(priv); + up_write(&priv->mib_sem); + + return 0; +} + +int +prism54_get_wpa(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + *uwrq =3D priv->wpa; + return 0; +} + +int +prism54_set_prismhdr(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + priv->monitor_type =3D + (*uwrq ? ARPHRD_IEEE80211_PRISM : ARPHRD_IEEE80211); + if (priv->iw_mode =3D=3D IW_MODE_MONITOR) + priv->ndev->type =3D priv->monitor_type; + + return 0; +} + +int +prism54_get_prismhdr(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + *uwrq =3D (priv->monitor_type =3D=3D ARPHRD_IEEE80211_PRISM); + return 0; +} + +int +prism54_debug_oid(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + priv->priv_oid =3D *uwrq; + printk("%s: oid 0x%08X\n", ndev->name, *uwrq); + + return 0; +} + +int +prism54_debug_get_oid(struct net_device *ndev, struct iw_request_info *inf= o, + struct iw_point *data, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_mgmtframe *response =3D NULL; + int ret =3D -EIO, response_op =3D PIMFOR_OP_ERROR; + + printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); + data->length =3D 0; + + if (islpci_get_state(priv) >=3D PRV_STATE_INIT) { + ret =3D + islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + priv->priv_oid, extra, 256, + &response); + response_op =3D response->header->operation; + printk("%s: ret: %i\n", ndev->name, ret); + printk("%s: response_op: %i\n", ndev->name, response_op); + if (ret || !response + || response->header->operation =3D=3D PIMFOR_OP_ERROR) { + if (response) { + islpci_mgt_release(response); + } + printk("%s: EIO\n", ndev->name); + ret =3D -EIO; + } + if (!ret) { + data->length =3D response->header->length; + memcpy(extra, response->data, data->length); + islpci_mgt_release(response); + printk("%s: len: %i\n", ndev->name, data->length); + } + } + + return ret; +} + +int +prism54_debug_set_oid(struct net_device *ndev, struct iw_request_info *inf= o, + struct iw_point *data, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_mgmtframe *response =3D NULL; + int ret =3D 0, response_op =3D PIMFOR_OP_ERROR; + + printk("%s: set_oid 0x%08X\tlen: %d\n", ndev->name, priv->priv_oid, + data->length); + + if (islpci_get_state(priv) >=3D PRV_STATE_INIT) { + ret =3D + islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, + priv->priv_oid, extra, data->length, + &response); + printk("%s: ret: %i\n", ndev->name, ret); + if (!ret) { + response_op =3D response->header->operation; + printk("%s: response_op: %i\n", ndev->name, + response_op); + islpci_mgt_release(response); + } + if (ret || response_op =3D=3D PIMFOR_OP_ERROR) { + printk("%s: EIO\n", ndev->name); + ret =3D -EIO; + } + } + + return (ret ? ret : -EINPROGRESS); +} + +static int +prism54_set_spy(struct net_device *ndev, + struct iw_request_info *info, + union iwreq_data *uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 u, oid =3D OID_INL_CONFIG; + + down_write(&priv->mib_sem); + mgt_get(priv, OID_INL_CONFIG, &u); + + if ((uwrq->data.length =3D=3D 0) && (priv->spy_data.spy_number > 0)) + /* disable spy */ + u &=3D ~INL_CONFIG_RXANNEX; + else if ((uwrq->data.length > 0) && (priv->spy_data.spy_number =3D=3D 0)) + /* enable spy */ + u |=3D INL_CONFIG_RXANNEX; + + mgt_set(priv, OID_INL_CONFIG, &u); + mgt_commit_list(priv, &oid, 1); + up_write(&priv->mib_sem); + + return iw_handler_set_spy(ndev, info, uwrq, extra); +} + +static const iw_handler prism54_handler[] =3D { + (iw_handler) prism54_commit, /* SIOCSIWCOMMIT */ + (iw_handler) prism54_get_name, /* SIOCGIWNAME */ + (iw_handler) NULL, /* SIOCSIWNWID */ + (iw_handler) NULL, /* SIOCGIWNWID */ + (iw_handler) prism54_set_freq, /* SIOCSIWFREQ */ + (iw_handler) prism54_get_freq, /* SIOCGIWFREQ */ + (iw_handler) prism54_set_mode, /* SIOCSIWMODE */ + (iw_handler) prism54_get_mode, /* SIOCGIWMODE */ + (iw_handler) prism54_set_sens, /* SIOCSIWSENS */ + (iw_handler) prism54_get_sens, /* SIOCGIWSENS */ + (iw_handler) NULL, /* SIOCSIWRANGE */ + (iw_handler) prism54_get_range, /* SIOCGIWRANGE */ + (iw_handler) NULL, /* SIOCSIWPRIV */ + (iw_handler) NULL, /* SIOCGIWPRIV */ + (iw_handler) NULL, /* SIOCSIWSTATS */ + (iw_handler) NULL, /* SIOCGIWSTATS */ + prism54_set_spy, /* SIOCSIWSPY */ + iw_handler_get_spy, /* SIOCGIWSPY */ + iw_handler_set_thrspy, /* SIOCSIWTHRSPY */ + iw_handler_get_thrspy, /* SIOCGIWTHRSPY */ + (iw_handler) prism54_set_wap, /* SIOCSIWAP */ + (iw_handler) prism54_get_wap, /* SIOCGIWAP */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) NULL, /* SIOCGIWAPLIST depreciated */ + (iw_handler) prism54_set_scan, /* SIOCSIWSCAN */ + (iw_handler) prism54_get_scan, /* SIOCGIWSCAN */ + (iw_handler) prism54_set_essid, /* SIOCSIWESSID */ + (iw_handler) prism54_get_essid, /* SIOCGIWESSID */ + (iw_handler) prism54_set_nick, /* SIOCSIWNICKN */ + (iw_handler) prism54_get_nick, /* SIOCGIWNICKN */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) prism54_set_rate, /* SIOCSIWRATE */ + (iw_handler) prism54_get_rate, /* SIOCGIWRATE */ + (iw_handler) prism54_set_rts, /* SIOCSIWRTS */ + (iw_handler) prism54_get_rts, /* SIOCGIWRTS */ + (iw_handler) prism54_set_frag, /* SIOCSIWFRAG */ + (iw_handler) prism54_get_frag, /* SIOCGIWFRAG */ + (iw_handler) prism54_set_txpower, /* SIOCSIWTXPOW */ + (iw_handler) prism54_get_txpower, /* SIOCGIWTXPOW */ + (iw_handler) prism54_set_retry, /* SIOCSIWRETRY */ + (iw_handler) prism54_get_retry, /* SIOCGIWRETRY */ + (iw_handler) prism54_set_encode, /* SIOCSIWENCODE */ + (iw_handler) prism54_get_encode, /* SIOCGIWENCODE */ + (iw_handler) NULL, /* SIOCSIWPOWER */ + (iw_handler) NULL, /* SIOCGIWPOWER */ +}; + +/* The low order bit identify a SET (0) or a GET (1) ioctl. */ + +#define PRISM54_RESET SIOCIWFIRSTPRIV +#define PRISM54_GET_POLICY SIOCIWFIRSTPRIV+1 +#define PRISM54_SET_POLICY SIOCIWFIRSTPRIV+2 +#define PRISM54_GET_MAC SIOCIWFIRSTPRIV+3 +#define PRISM54_ADD_MAC SIOCIWFIRSTPRIV+4 + +#define PRISM54_DEL_MAC SIOCIWFIRSTPRIV+6 + +#define PRISM54_KICK_MAC SIOCIWFIRSTPRIV+8 + +#define PRISM54_KICK_ALL SIOCIWFIRSTPRIV+10 + +#define PRISM54_GET_WPA SIOCIWFIRSTPRIV+11 +#define PRISM54_SET_WPA SIOCIWFIRSTPRIV+12 + +#define PRISM54_DBG_OID SIOCIWFIRSTPRIV+14 +#define PRISM54_DBG_GET_OID SIOCIWFIRSTPRIV+15 +#define PRISM54_DBG_SET_OID SIOCIWFIRSTPRIV+16 + +#define PRISM54_GET_OID SIOCIWFIRSTPRIV+17 +#define PRISM54_SET_OID_U32 SIOCIWFIRSTPRIV+18 +#define PRISM54_SET_OID_STR SIOCIWFIRSTPRIV+20 +#define PRISM54_SET_OID_ADDR SIOCIWFIRSTPRIV+22 + +#define PRISM54_GET_PRISMHDR SIOCIWFIRSTPRIV+23 +#define PRISM54_SET_PRISMHDR SIOCIWFIRSTPRIV+24 + +#define IWPRIV_SET_U32(n,x) { n, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1= , 0, "s_"x } +#define IWPRIV_SET_SSID(n,x) { n, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED |= 1, 0, "s_"x } +#define IWPRIV_SET_ADDR(n,x) { n, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED |= 1, 0, "s_"x } +#define IWPRIV_GET(n,x) { n, 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | P= RIV_STR_SIZE, "g_"x } + +#define IWPRIV_U32(n,x) IWPRIV_SET_U32(n,x), IWPRIV_GET(n,x) +#define IWPRIV_SSID(n,x) IWPRIV_SET_SSID(n,x), IWPRIV_GET(n,x) +#define IWPRIV_ADDR(n,x) IWPRIV_SET_ADDR(n,x), IWPRIV_GET(n,x) + +/* Note : limited to 128 private ioctls (wireless tools 26) */ + +static const struct iw_priv_args prism54_private_args[] =3D { +/*{ cmd, set_args, get_args, name } */ + {PRISM54_RESET, 0, 0, "reset"}, + {PRISM54_GET_PRISMHDR, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "get_prismhdr"}, + {PRISM54_SET_PRISMHDR, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "set_prismhdr"}, + {PRISM54_GET_POLICY, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "getPolicy"}, + {PRISM54_SET_POLICY, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "setPolicy"}, + {PRISM54_GET_MAC, 0, IW_PRIV_TYPE_ADDR | 64, "getMac"}, + {PRISM54_ADD_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "addMac"}, + {PRISM54_DEL_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "delMac"}, + {PRISM54_KICK_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "kickMac"}, + {PRISM54_KICK_ALL, 0, 0, "kickAll"}, + {PRISM54_GET_WPA, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "get_wpa"}, + {PRISM54_SET_WPA, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "set_wpa"}, + {PRISM54_DBG_OID, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "dbg_oid"}, + {PRISM54_DBG_GET_OID, 0, IW_PRIV_TYPE_BYTE | 256, "dbg_get_oid"}, + {PRISM54_DBG_SET_OID, IW_PRIV_TYPE_BYTE | 256, 0, "dbg_set_oid"}, + /* --- sub-ioctls handlers --- */ + {PRISM54_GET_OID, + 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | PRIV_STR_SIZE, ""}, + {PRISM54_SET_OID_U32, + IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + {PRISM54_SET_OID_STR, + IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + {PRISM54_SET_OID_ADDR, + IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + /* --- sub-ioctls definitions --- */ + IWPRIV_ADDR(GEN_OID_MACADDRESS, "addr"), + IWPRIV_GET(GEN_OID_LINKSTATE, "linkstate"), + IWPRIV_U32(DOT11_OID_BSSTYPE, "bsstype"), + IWPRIV_ADDR(DOT11_OID_BSSID, "bssid"), + IWPRIV_U32(DOT11_OID_STATE, "state"), + IWPRIV_U32(DOT11_OID_AID, "aid"), + + IWPRIV_SSID(DOT11_OID_SSIDOVERRIDE, "ssidoverride"), + + IWPRIV_U32(DOT11_OID_MEDIUMLIMIT, "medlimit"), + IWPRIV_U32(DOT11_OID_BEACONPERIOD, "beacon"), + IWPRIV_U32(DOT11_OID_DTIMPERIOD, "dtimperiod"), + + IWPRIV_U32(DOT11_OID_AUTHENABLE, "authenable"), + IWPRIV_U32(DOT11_OID_PRIVACYINVOKED, "privinvok"), + IWPRIV_U32(DOT11_OID_EXUNENCRYPTED, "exunencrypt"), + + IWPRIV_U32(DOT11_OID_REKEYTHRESHOLD, "rekeythresh"), + + IWPRIV_U32(DOT11_OID_MAXTXLIFETIME, "maxtxlife"), + IWPRIV_U32(DOT11_OID_MAXRXLIFETIME, "maxrxlife"), + IWPRIV_U32(DOT11_OID_ALOFT_FIXEDRATE, "fixedrate"), + IWPRIV_U32(DOT11_OID_MAXFRAMEBURST, "frameburst"), + IWPRIV_U32(DOT11_OID_PSM, "psm"), + + IWPRIV_U32(DOT11_OID_BRIDGELOCAL, "bridge"), + IWPRIV_U32(DOT11_OID_CLIENTS, "clients"), + IWPRIV_U32(DOT11_OID_CLIENTSASSOCIATED, "clientassoc"), + IWPRIV_U32(DOT11_OID_DOT1XENABLE, "dot1xenable"), + IWPRIV_U32(DOT11_OID_ANTENNARX, "rxant"), + IWPRIV_U32(DOT11_OID_ANTENNATX, "txant"), + IWPRIV_U32(DOT11_OID_ANTENNADIVERSITY, "antdivers"), + IWPRIV_U32(DOT11_OID_EDTHRESHOLD, "edthresh"), + IWPRIV_U32(DOT11_OID_PREAMBLESETTINGS, "preamble"), + IWPRIV_GET(DOT11_OID_RATES, "rates"), + IWPRIV_U32(DOT11_OID_OUTPUTPOWER, ".11outpower"), + IWPRIV_GET(DOT11_OID_SUPPORTEDRATES, "supprates"), + IWPRIV_GET(DOT11_OID_SUPPORTEDFREQUENCIES, "suppfreq"), + + IWPRIV_U32(DOT11_OID_NOISEFLOOR, "noisefloor"), + IWPRIV_GET(DOT11_OID_FREQUENCYACTIVITY, "freqactivity"), + IWPRIV_U32(DOT11_OID_NONERPPROTECTION, "nonerpprotec"), + IWPRIV_U32(DOT11_OID_PROFILES, "profile"), + IWPRIV_GET(DOT11_OID_EXTENDEDRATES, "extrates"), + IWPRIV_U32(DOT11_OID_MLMEAUTOLEVEL, "mlmelevel"), + + IWPRIV_GET(DOT11_OID_BSSS, "bsss"), + IWPRIV_GET(DOT11_OID_BSSLIST, "bsslist"), + IWPRIV_U32(OID_INL_MODE, "mode"), + IWPRIV_U32(OID_INL_CONFIG, "config"), + IWPRIV_U32(OID_INL_DOT11D_CONFORMANCE, ".11dconform"), + IWPRIV_GET(OID_INL_PHYCAPABILITIES, "phycapa"), + IWPRIV_U32(OID_INL_OUTPUTPOWER, "outpower"), +}; + +static const iw_handler prism54_private_handler[] =3D { + (iw_handler) prism54_reset, + (iw_handler) prism54_get_policy, + (iw_handler) prism54_set_policy, + (iw_handler) prism54_get_mac, + (iw_handler) prism54_add_mac, + (iw_handler) NULL, + (iw_handler) prism54_del_mac, + (iw_handler) NULL, + (iw_handler) prism54_kick_mac, + (iw_handler) NULL, + (iw_handler) prism54_kick_all, + (iw_handler) prism54_get_wpa, + (iw_handler) prism54_set_wpa, + (iw_handler) NULL, + (iw_handler) prism54_debug_oid, + (iw_handler) prism54_debug_get_oid, + (iw_handler) prism54_debug_set_oid, + (iw_handler) prism54_get_oid, + (iw_handler) prism54_set_u32, + (iw_handler) NULL, + (iw_handler) prism54_set_raw, + (iw_handler) NULL, + (iw_handler) prism54_set_raw, + (iw_handler) prism54_get_prismhdr, + (iw_handler) prism54_set_prismhdr, +}; + +const struct iw_handler_def prism54_handler_def =3D { + .num_standard =3D sizeof (prism54_handler) / sizeof (iw_handler), + .num_private =3D sizeof (prism54_private_handler) / sizeof (iw_handler), + .num_private_args =3D + sizeof (prism54_private_args) / sizeof (struct iw_priv_args), + .standard =3D (iw_handler *) prism54_handler, + .private =3D (iw_handler *) prism54_private_handler, + .private_args =3D (struct iw_priv_args *) prism54_private_args, + .spy_offset =3D offsetof(islpci_private, spy_data), +}; + +/* For ioctls that don't work with the new API */ + +int +prism54_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) +{ + + return -EOPNOTSUPP; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_ioctl.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_io= ctl.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_ioctl.h 1970-01-01 00:00:= 00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_ioctl.h 2004-07-1= 5 00:30:04.000000000 +0000 @@ -0,0 +1,54 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * (C) 2003 Aurelien Alleaume + * (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISL_IOCTL_H +#define _ISL_IOCTL_H + +#include "islpci_mgt.h" +#include "islpci_dev.h" + +#include /* New driver API */ + +#define SUPPORTED_WIRELESS_EXT 16 + +void prism54_mib_init(islpci_private *); + +struct iw_statistics *prism54_get_wireless_stats(struct net_device *); +void prism54_update_stats(islpci_private *); + +void prism54_acl_init(struct islpci_acl *); +void prism54_acl_clean(struct islpci_acl *); + +void prism54_process_trap(void *); + +void prism54_wpa_ie_init(islpci_private *priv); +void prism54_wpa_ie_clean(islpci_private *priv); +void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len); +size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie); + +int prism54_set_mac_address(struct net_device *, void *); + +int prism54_ioctl(struct net_device *, struct ifreq *, int); + +extern const struct iw_handler_def prism54_handler_def; + +#endif /* _ISL_IOCTL_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_oid.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_oid.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_oid.h 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_oid.h 2004-07-15 = 00:30:04.000000000 +0000 @@ -0,0 +1,498 @@ +/* + * + * =20 + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2004 Luis R. Rodriguez + * Copyright (C) 2004 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#if !defined(_ISL_OID_H) +#define _ISL_OID_H + +/*=20 + * MIB related constant and structure definitions for communicating + * with the device firmware + */ + +struct obj_ssid { + u8 length; + char octets[33]; +} __attribute__ ((packed)); + +struct obj_key { + u8 type; /* dot11_priv_t */ + u8 length; + char key[32]; +} __attribute__ ((packed)); + +struct obj_mlme { + u8 address[6]; + u16 id; + u16 state; + u16 code; +} __attribute__ ((packed)); + +struct obj_mlmeex { + u8 address[6]; + u16 id; + u16 state; + u16 code; + u16 size; + u8 data[0]; +} __attribute__ ((packed)); + +struct obj_buffer { + u32 size; + u32 addr; /* 32bit bus address */ +} __attribute__ ((packed)); + +struct obj_bss { + u8 address[6]; + int:16; /* padding */ + + char state; + char reserved; + short age; + + char quality; + char rssi; + + struct obj_ssid ssid; + short channel; + char beacon_period; + char dtim_period; + short capinfo; + short rates; + short basic_rates; + int:16; /* padding */ +} __attribute__ ((packed)); + +struct obj_bsslist { + u32 nr; + struct obj_bss bsslist[0]; +} __attribute__ ((packed)); + +struct obj_frequencies { + u16 nr; + u16 mhz[0]; +} __attribute__ ((packed)); + +/*=20 + * in case everything's ok, the inlined function below will be + * optimized away by the compiler... + */ +static inline void +__bug_on_wrong_struct_sizes(void) +{ + BUG_ON(sizeof (struct obj_ssid) !=3D 34); + BUG_ON(sizeof (struct obj_key) !=3D 34); + BUG_ON(sizeof (struct obj_mlme) !=3D 12); + BUG_ON(sizeof (struct obj_mlmeex) !=3D 14); + BUG_ON(sizeof (struct obj_buffer) !=3D 8); + BUG_ON(sizeof (struct obj_bss) !=3D 60); + BUG_ON(sizeof (struct obj_bsslist) !=3D 4); + BUG_ON(sizeof (struct obj_frequencies) !=3D 2); +} + +enum dot11_state_t { + DOT11_STATE_NONE =3D 0, + DOT11_STATE_AUTHING =3D 1, + DOT11_STATE_AUTH =3D 2, + DOT11_STATE_ASSOCING =3D 3, + + DOT11_STATE_ASSOC =3D 5, + DOT11_STATE_IBSS =3D 6, + DOT11_STATE_WDS =3D 7 +}; + +enum dot11_bsstype_t { + DOT11_BSSTYPE_NONE =3D 0, + DOT11_BSSTYPE_INFRA =3D 1, + DOT11_BSSTYPE_IBSS =3D 2, + DOT11_BSSTYPE_ANY =3D 3 +}; + +enum dot11_auth_t { + DOT11_AUTH_NONE =3D 0, + DOT11_AUTH_OS =3D 1, + DOT11_AUTH_SK =3D 2, + DOT11_AUTH_BOTH =3D 3 +}; + +enum dot11_mlme_t { + DOT11_MLME_AUTO =3D 0, + DOT11_MLME_INTERMEDIATE =3D 1, + DOT11_MLME_EXTENDED =3D 2 +}; + +enum dot11_priv_t { + DOT11_PRIV_WEP =3D 0, + DOT11_PRIV_TKIP =3D 1 +}; + +/* Prism "Nitro" / Frameburst / "Packet Frame Grouping" + * Value is in microseconds. Represents the # microseconds + * the firmware will take to group frames before sending out then out=20 + * together with a CSMA contention. Without this all frames are + * sent with a CSMA contention.=20 + * Bibliography:=20 + * http://www.hpl.hp.com/personal/Jean_Tourrilhes/Papers/Packet.Frame.Grou= ping.html + */ +enum dot11_maxframeburst_t {=20 + /* Values for DOT11_OID_MAXFRAMEBURST */ + DOT11_MAXFRAMEBURST_OFF =3D 0, /* Card firmware default */ + DOT11_MAXFRAMEBURST_MIXED_SAFE =3D 650, /* 802.11 a,b,g safe */ + DOT11_MAXFRAMEBURST_IDEAL =3D 1300, /* Theoretical ideal level */ + DOT11_MAXFRAMEBURST_MAX =3D 5000, /* Use this as max, + * Note: firmware allows for greater values. This is a + * recommended max. I'll update this as I find + * out what the real MAX is. Also note that you don't necessarily + * get better results with a greater value here. + */ +}; + +/* Support for 802.11 long and short frame preambles. + * Long preamble uses 128-bit sync field, 8-bit CRC + * Short preamble uses 56-bit sync field, 16-bit CRC + *=20 + * 802.11a -- not sure, both optionally ? + * 802.11b supports long and optionally short=20 + * 802.11g supports both */ +enum dot11_preamblesettings_t { + DOT11_PREAMBLESETTING_LONG =3D 0, + /* Allows *only* long 802.11 preambles */ + DOT11_PREAMBLESETTING_SHORT =3D 1, + /* Allows *only* short 802.11 preambles */ + DOT11_PREAMBLESETTING_DYNAMIC =3D 2 + /* AutomatiGically set */ +}; + +/* Support for 802.11 slot timing (time between packets). + * + * Long uses 802.11a slot timing (9 usec ?) + * Short uses 802.11b slot timing (20 use ?) */ +enum dot11_slotsettings_t { + DOT11_SLOTSETTINGS_LONG =3D 0,=20 + /* Allows *only* long 802.11b slot timing */ + DOT11_SLOTSETTINGS_SHORT =3D 1, + /* Allows *only* long 802.11a slot timing */ + DOT11_SLOTSETTINGS_DYNAMIC =3D 2 + /* AutomatiGically set */ +}; + +/* All you need to know, ERP is "Extended Rate PHY". + * An Extended Rate PHY (ERP) STA or AP shall support three different=20 + * preamble and header formats: + * Long preamble (refer to above) + * Short preamble (refer to above) + * OFDM preamble ( ? ) + * + * I'm assuming here Protection tells the AP + * to be careful, a STA which cannot handle the long pre-amble + * has joined. + */ +enum do11_nonerpstatus_t { + DOT11_ERPSTAT_NONEPRESENT =3D 0, + DOT11_ERPSTAT_USEPROTECTION =3D 1 +}; + +/* (ERP is "Extended Rate PHY") Way to read NONERP is NON-ERP-* + * The key here is DOT11 NON ERP NEVER protects against + * NON ERP STA's. You *don't* want this unless + * you know what you are doing. It means you will only=20 + * get Extended Rate capabilities */ +enum dot11_nonerpprotection_t { + DOT11_NONERP_NEVER =3D 0, + DOT11_NONERP_ALWAYS =3D 1, + DOT11_NONERP_DYNAMIC =3D 2 +}; + +/* Preset OID configuration for 802.11 modes=20 + * Note: DOT11_OID_CW[MIN|MAX] hold the values of the=20 + * DCS MIN|MAX backoff used */ +enum dot11_profile_t { /* And set/allowed values */ + /* Allowed values for DOT11_OID_PROFILES */ + DOT11_PROFILE_B_ONLY =3D 0, + /* DOT11_OID_RATES: 1, 2, 5.5, 11Mbps=20 + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_DYNAMIC + * DOT11_OID_CWMIN: 31 + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_DYNAMIC + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_LONG + */ + DOT11_PROFILE_MIXED_G_WIFI =3D 1, + /* DOT11_OID_RATES: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54Mbs + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_DYNAMIC + * DOT11_OID_CWMIN: 15 + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_DYNAMIC + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_DYNAMIC + */ + DOT11_PROFILE_MIXED_LONG =3D 2, /* "Long range" */ + /* Same as Profile MIXED_G_WIFI */ + DOT11_PROFILE_G_ONLY =3D 3, + /* Same as Profile MIXED_G_WIFI */ + DOT11_PROFILE_TEST =3D 4, + /* Same as Profile MIXED_G_WIFI except: + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_SHORT + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_NEVER + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_SHORT + */ + DOT11_PROFILE_B_WIFI =3D 5, + /* Same as Profile B_ONLY */ + DOT11_PROFILE_A_ONLY =3D 6, + /* Same as Profile MIXED_G_WIFI except: + * DOT11_OID_RATES: 6, 9, 12, 18, 24, 36, 48, 54Mbs + */ + DOT11_PROFILE_MIXED_SHORT =3D 7 + /* Same as MIXED_G_WIFI */ +}; + + +/* The dot11d conformance level configures the 802.11d conformance levels. + * The following conformance levels exist:*/ +enum oid_inl_conformance_t { + OID_INL_CONFORMANCE_NONE =3D 0, /* Perform active scanning */ + OID_INL_CONFORMANCE_STRICT =3D 1, /* Strictly adhere to 802.11d */ + OID_INL_CONFORMANCE_FLEXIBLE =3D 2, /* Use passed 802.11d info to + * determine channel AND/OR just make assumption that active=20 + * channels are valid channels */ +}; + +enum oid_inl_mode_t { + INL_MODE_NONE =3D -1, + INL_MODE_PROMISCUOUS =3D 0, + INL_MODE_CLIENT =3D 1, + INL_MODE_AP =3D 2, + INL_MODE_SNIFFER =3D 3 +}; + +enum oid_inl_config_t { + INL_CONFIG_NOTHING =3D 0x00, + INL_CONFIG_MANUALRUN =3D 0x01, + INL_CONFIG_FRAMETRAP =3D 0x02, + INL_CONFIG_RXANNEX =3D 0x04, + INL_CONFIG_TXANNEX =3D 0x08, + INL_CONFIG_WDS =3D 0x10 +}; + +enum oid_inl_phycap_t { + INL_PHYCAP_2400MHZ =3D 1, + INL_PHYCAP_5000MHZ =3D 2, + INL_PHYCAP_FAA =3D 0x80000000, /* Means card supports the FAA switch */ +}; + + +enum oid_num_t { + GEN_OID_MACADDRESS =3D 0, + GEN_OID_LINKSTATE, + GEN_OID_WATCHDOG, + GEN_OID_MIBOP, + GEN_OID_OPTIONS, + GEN_OID_LEDCONFIG, + + /* 802.11 */ + DOT11_OID_BSSTYPE, + DOT11_OID_BSSID, + DOT11_OID_SSID, + DOT11_OID_STATE, + DOT11_OID_AID, + DOT11_OID_COUNTRYSTRING, + DOT11_OID_SSIDOVERRIDE, + + DOT11_OID_MEDIUMLIMIT, + DOT11_OID_BEACONPERIOD, + DOT11_OID_DTIMPERIOD, + DOT11_OID_ATIMWINDOW, + DOT11_OID_LISTENINTERVAL, + DOT11_OID_CFPPERIOD, + DOT11_OID_CFPDURATION, + + DOT11_OID_AUTHENABLE, + DOT11_OID_PRIVACYINVOKED, + DOT11_OID_EXUNENCRYPTED, + DOT11_OID_DEFKEYID, + DOT11_OID_DEFKEYX, /* DOT11_OID_DEFKEY1,...DOT11_OID_DEFKEY4 */ + DOT11_OID_STAKEY, + DOT11_OID_REKEYTHRESHOLD, + DOT11_OID_STASC, + + DOT11_OID_PRIVTXREJECTED, + DOT11_OID_PRIVRXPLAIN, + DOT11_OID_PRIVRXFAILED, + DOT11_OID_PRIVRXNOKEY, + + DOT11_OID_RTSTHRESH, + DOT11_OID_FRAGTHRESH, + DOT11_OID_SHORTRETRIES, + DOT11_OID_LONGRETRIES, + DOT11_OID_MAXTXLIFETIME, + DOT11_OID_MAXRXLIFETIME, + DOT11_OID_AUTHRESPTIMEOUT, + DOT11_OID_ASSOCRESPTIMEOUT, + + DOT11_OID_ALOFT_TABLE, + DOT11_OID_ALOFT_CTRL_TABLE, + DOT11_OID_ALOFT_RETREAT, + DOT11_OID_ALOFT_PROGRESS, + DOT11_OID_ALOFT_FIXEDRATE, + DOT11_OID_ALOFT_RSSIGRAPH, + DOT11_OID_ALOFT_CONFIG, + + DOT11_OID_VDCFX, + DOT11_OID_MAXFRAMEBURST, + + DOT11_OID_PSM, + DOT11_OID_CAMTIMEOUT, + DOT11_OID_RECEIVEDTIMS, + DOT11_OID_ROAMPREFERENCE, + + DOT11_OID_BRIDGELOCAL, + DOT11_OID_CLIENTS, + DOT11_OID_CLIENTSASSOCIATED, + DOT11_OID_CLIENTX, /* DOT11_OID_CLIENTX,...DOT11_OID_CLIENT2007 */ + + DOT11_OID_CLIENTFIND, + DOT11_OID_WDSLINKADD, + DOT11_OID_WDSLINKREMOVE, + DOT11_OID_EAPAUTHSTA, + DOT11_OID_EAPUNAUTHSTA, + DOT11_OID_DOT1XENABLE, + DOT11_OID_MICFAILURE, + DOT11_OID_REKEYINDICATE, + + DOT11_OID_MPDUTXSUCCESSFUL, + DOT11_OID_MPDUTXONERETRY, + DOT11_OID_MPDUTXMULTIPLERETRIES, + DOT11_OID_MPDUTXFAILED, + DOT11_OID_MPDURXSUCCESSFUL, + DOT11_OID_MPDURXDUPS, + DOT11_OID_RTSSUCCESSFUL, + DOT11_OID_RTSFAILED, + DOT11_OID_ACKFAILED, + DOT11_OID_FRAMERECEIVES, + DOT11_OID_FRAMEERRORS, + DOT11_OID_FRAMEABORTS, + DOT11_OID_FRAMEABORTSPHY, + + DOT11_OID_SLOTTIME, + DOT11_OID_CWMIN, /* MIN DCS backoff */ + DOT11_OID_CWMAX, /* MAX DCS backoff */ + DOT11_OID_ACKWINDOW, + DOT11_OID_ANTENNARX, + DOT11_OID_ANTENNATX, + DOT11_OID_ANTENNADIVERSITY, + DOT11_OID_CHANNEL, + DOT11_OID_EDTHRESHOLD, + DOT11_OID_PREAMBLESETTINGS, + DOT11_OID_RATES, + DOT11_OID_CCAMODESUPPORTED, + DOT11_OID_CCAMODE, + DOT11_OID_RSSIVECTOR, + DOT11_OID_OUTPUTPOWERTABLE, + DOT11_OID_OUTPUTPOWER, + DOT11_OID_SUPPORTEDRATES, + DOT11_OID_FREQUENCY, + DOT11_OID_SUPPORTEDFREQUENCIES, + DOT11_OID_NOISEFLOOR, + DOT11_OID_FREQUENCYACTIVITY, + DOT11_OID_IQCALIBRATIONTABLE, + DOT11_OID_NONERPPROTECTION, + DOT11_OID_SLOTSETTINGS, + DOT11_OID_NONERPTIMEOUT, + DOT11_OID_PROFILES, + DOT11_OID_EXTENDEDRATES, + + DOT11_OID_DEAUTHENTICATE, + DOT11_OID_AUTHENTICATE, + DOT11_OID_DISASSOCIATE, + DOT11_OID_ASSOCIATE, + DOT11_OID_SCAN, + DOT11_OID_BEACON, + DOT11_OID_PROBE, + DOT11_OID_DEAUTHENTICATEEX, + DOT11_OID_AUTHENTICATEEX, + DOT11_OID_DISASSOCIATEEX, + DOT11_OID_ASSOCIATEEX, + DOT11_OID_REASSOCIATE, + DOT11_OID_REASSOCIATEEX, + + DOT11_OID_NONERPSTATUS, + + DOT11_OID_STATIMEOUT, + DOT11_OID_MLMEAUTOLEVEL, + DOT11_OID_BSSTIMEOUT, + DOT11_OID_ATTACHMENT, + DOT11_OID_PSMBUFFER, + + DOT11_OID_BSSS, + DOT11_OID_BSSX, /*DOT11_OID_BSS1,...,DOT11_OID_BSS64 */ + DOT11_OID_BSSFIND, + DOT11_OID_BSSLIST, + + OID_INL_TUNNEL, + OID_INL_MEMADDR, + OID_INL_MEMORY, + OID_INL_MODE, + OID_INL_COMPONENT_NR, + OID_INL_VERSION, + OID_INL_INTERFACE_ID, + OID_INL_COMPONENT_ID, + OID_INL_CONFIG, + OID_INL_DOT11D_CONFORMANCE, + OID_INL_PHYCAPABILITIES, + OID_INL_OUTPUTPOWER, + + OID_NUM_LAST +}; + +#define OID_FLAG_CACHED 0x80 +#define OID_FLAG_TYPE 0x7f + +#define OID_TYPE_U32 0x01 +#define OID_TYPE_SSID 0x02 +#define OID_TYPE_KEY 0x03 +#define OID_TYPE_BUFFER 0x04 +#define OID_TYPE_BSS 0x05 +#define OID_TYPE_BSSLIST 0x06 +#define OID_TYPE_FREQUENCIES 0x07 +#define OID_TYPE_MLME 0x08 +#define OID_TYPE_MLMEEX 0x09 +#define OID_TYPE_ADDR 0x0A +#define OID_TYPE_RAW 0x0B + +/* OID_TYPE_MLMEEX is special because of a variable size field when sendin= g. + * Not yet implemented (not used in driver anyway). + */ + +struct oid_t { + enum oid_num_t oid; + short range; /* to define a range of oid */ + short size; /* max size of the associated data */ + char flags; +}; + +union oid_res_t { + void *ptr; + u32 u; +}; + +#define IWMAX_BITRATES 20 +#define IWMAX_BSS 24 +#define IWMAX_FREQ 30 +#define PRIV_STR_SIZE 1024 + +#endif /* !defined(_ISL_OID_H) */ +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_dev.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_dev.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_dev.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_dev.c 2004-07-= 15 00:30:04.000000000 +0000 @@ -0,0 +1,931 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include + +#include +#include +#include +#include +#include + +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "isl_ioctl.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" +#include "islpci_eth.h" +#include "oid_mgt.h" + +#define ISL3877_IMAGE_FILE "isl3877" +#define ISL3890_IMAGE_FILE "isl3890" + +static int prism54_bring_down(islpci_private *); +static int islpci_alloc_memory(islpci_private *); + +/* Temporary dummy MAC address to use until firmware is loaded. + * The idea there is that some tools (such as nameif) may query + * the MAC address before the netdev is 'open'. By using a valid + * OUI prefix, they can process the netdev properly. + * Of course, this is not the final/real MAC address. It doesn't + * matter, as you are suppose to be able to change it anytime via + * ndev->set_mac_address. Jean II */ +const unsigned char dummy_mac[6] =3D { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 = }; + +static int +isl_upload_firmware(islpci_private *priv) +{ + u32 reg, rc; + void *device_base =3D priv->device_base; + + /* clear the RAMBoot and the Reset bit */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + reg &=3D ~ISL38XX_CTRL_STAT_RAMBOOT; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the Reset bit without reading the register ! */ + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the Reset bit */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + + /* wait a while for the device to reboot */ + mdelay(50); + + { + const struct firmware *fw_entry =3D 0; + long fw_len; + const u32 *fw_ptr; + + rc =3D request_firmware(&fw_entry, priv->firmware, PRISM_FW_PDEV); + if (rc) { + printk(KERN_ERR + "%s: request_firmware() failed for '%s'\n", + "prism54", priv->firmware); + return rc; + } + /* prepare the Direct Memory Base register */ + reg =3D ISL38XX_DEV_FIRMWARE_ADDRES; + + fw_ptr =3D (u32 *) fw_entry->data; + fw_len =3D fw_entry->size; + + if (fw_len % 4) { + printk(KERN_ERR + "%s: firmware '%s' size is not multiple of 32bit, aborting!\n", + "prism54", priv->firmware); + release_firmware(fw_entry); + return EILSEQ; /* Illegal byte sequence */; + } + + while (fw_len > 0) { + long _fw_len =3D + (fw_len > + ISL38XX_MEMORY_WINDOW_SIZE) ? + ISL38XX_MEMORY_WINDOW_SIZE : fw_len; + u32 *dev_fw_ptr =3D device_base + ISL38XX_DIRECT_MEM_WIN; + + /* set the cards base address for writting the data */ + isl38xx_w32_flush(device_base, reg, + ISL38XX_DIR_MEM_BASE_REG); + wmb(); /* be paranoid */ + + /* increment the write address for next iteration */ + reg +=3D _fw_len; + fw_len -=3D _fw_len; + + /* write the data to the Direct Memory Window 32bit-wise */ + /* memcpy_toio() doesn't guarantee 32bit writes :-| */ + while (_fw_len > 0) { + /* use non-swapping writel() */ + __raw_writel(*fw_ptr, dev_fw_ptr); + fw_ptr++, dev_fw_ptr++; + _fw_len -=3D 4; + } + + /* flush PCI posting */ + (void) readl(device_base + ISL38XX_PCI_POSTING_FLUSH); + wmb(); /* be paranoid again */ + + BUG_ON(_fw_len !=3D 0); + } + + BUG_ON(fw_len !=3D 0); + + release_firmware(fw_entry); + } + + /* now reset the device + * clear the Reset & ClkRun bit, set the RAMBoot bit */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~ISL38XX_CTRL_STAT_CLKRUN; + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + reg |=3D ISL38XX_CTRL_STAT_RAMBOOT; + isl38xx_w32_flush(device_base, reg, ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the reset bit latches the host override and RAMBoot bits + * into the device for operation when the reset bit is reset */ + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the reset bit should start the whole circus */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + return 0; +} + +/*************************************************************************= ***** + Device Interrupt Handler +**************************************************************************= ****/ + +irqreturn_t +islpci_interrupt(int irq, void *config, struct pt_regs *regs) +{ + u32 reg; + islpci_private *priv =3D config; + struct net_device *ndev =3D priv->ndev; + void *device =3D priv->device_base; + int powerstate =3D ISL38XX_PSM_POWERSAVE_STATE; + + /* received an interrupt request on a shared IRQ line + * first check whether the device is in sleep mode */ + reg =3D readl(device + ISL38XX_CTRL_STAT_REG); + if (reg & ISL38XX_CTRL_STAT_SLEEPMODE) + /* device is in sleep mode, IRQ was generated by someone else */ + { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Assuming someone else called the IRQ\n"); +#endif + return IRQ_NONE; + } + + if (islpci_get_state(priv) !=3D PRV_STATE_SLEEP) + powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* lock the interrupt handler */ + spin_lock(&priv->slock); + + /* check whether there is any source of interrupt on the device */ + reg =3D readl(device + ISL38XX_INT_IDENT_REG); + + /* also check the contents of the Interrupt Enable Register, because this + * will filter out interrupt sources from other devices on the same irq != */ + reg &=3D readl(device + ISL38XX_INT_EN_REG); + reg &=3D ISL38XX_INT_SOURCES; + + if (reg !=3D 0) { + /* reset the request bits in the Identification register */ + isl38xx_w32_flush(device, reg, ISL38XX_INT_ACK_REG); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, + "IRQ: Identification register 0x%p 0x%x \n", device, reg); +#endif + + /* check for each bit in the register separately */ + if (reg & ISL38XX_INT_IDENT_UPDATE) { +#if VERBOSE > SHOW_ERROR_MESSAGES + /* Queue has been updated */ + DEBUG(SHOW_TRACING, "IRQ: Update flag \n"); + + DEBUG(SHOW_QUEUE_INDEXES, + "CB drv Qs: [%i][%i][%i][%i][%i][%i]\n", + le32_to_cpu(priv->control_block-> + driver_curr_frag[0]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[1]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[2]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[3]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[4]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[5]) + ); + + DEBUG(SHOW_QUEUE_INDEXES, + "CB dev Qs: [%i][%i][%i][%i][%i][%i]\n", + le32_to_cpu(priv->control_block-> + device_curr_frag[0]), + le32_to_cpu(priv->control_block-> + device_curr_frag[1]), + le32_to_cpu(priv->control_block-> + device_curr_frag[2]), + le32_to_cpu(priv->control_block-> + device_curr_frag[3]), + le32_to_cpu(priv->control_block-> + device_curr_frag[4]), + le32_to_cpu(priv->control_block-> + device_curr_frag[5]) + ); +#endif + + /* cleanup the data low transmit queue */ + islpci_eth_cleanup_transmit(priv, priv->control_block); + + /* device is in active state, update the + * powerstate flag if necessary */ + powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* check all three queues in priority order + * call the PIMFOR receive function until the + * queue is empty */ + if (isl38xx_in_queue(priv->control_block, + ISL38XX_CB_RX_MGMTQ) !=3D 0) { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "Received frame in Management Queue\n"); +#endif + islpci_mgt_receive(ndev); + + islpci_mgt_cleanup_transmit(ndev); + + /* Refill slots in receive queue */ + islpci_mgmt_rx_fill(ndev); + + /* no need to trigger the device, next + islpci_mgt_transaction does it */ + } + + while (isl38xx_in_queue(priv->control_block, + ISL38XX_CB_RX_DATA_LQ) !=3D 0) { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "Received frame in Data Low Queue \n"); +#endif + islpci_eth_receive(priv); + } + + /* check whether the data transmit queues were full */ + if (priv->data_low_tx_full) { + /* check whether the transmit is not full anymore */ + if (ISL38XX_CB_TX_QSIZE - + isl38xx_in_queue(priv->control_block, + ISL38XX_CB_TX_DATA_LQ) >=3D + ISL38XX_MIN_QTHRESHOLD) { + /* nope, the driver is ready for more network frames */ + netif_wake_queue(priv->ndev); + + /* reset the full flag */ + priv->data_low_tx_full =3D 0; + } + } + } + + if (reg & ISL38XX_INT_IDENT_INIT) { + /* Device has been initialized */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "IRQ: Init flag, device initialized \n"); +#endif + wake_up(&priv->reset_done); + } + + if (reg & ISL38XX_INT_IDENT_SLEEP) { + /* Device intends to move to powersave state */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "IRQ: Sleep flag \n"); +#endif + isl38xx_handle_sleep_request(priv->control_block, + &powerstate, + priv->device_base); + } + + if (reg & ISL38XX_INT_IDENT_WAKEUP) { + /* Device has been woken up to active state */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "IRQ: Wakeup flag \n"); +#endif + + isl38xx_handle_wakeup(priv->control_block, + &powerstate, priv->device_base); + } + } + + /* sleep -> ready */ + if (islpci_get_state(priv) =3D=3D PRV_STATE_SLEEP + && powerstate =3D=3D ISL38XX_PSM_ACTIVE_STATE) + islpci_set_state(priv, PRV_STATE_READY); + + /* !sleep -> sleep */ + if (islpci_get_state(priv) !=3D PRV_STATE_SLEEP + && powerstate =3D=3D ISL38XX_PSM_POWERSAVE_STATE) + islpci_set_state(priv, PRV_STATE_SLEEP); + + /* unlock the interrupt handler */ + spin_unlock(&priv->slock); + + return IRQ_HANDLED; +} + +/*************************************************************************= ***** + Network Interface Control & Statistical functions +**************************************************************************= ****/ +static int +islpci_open(struct net_device *ndev) +{ + u32 rc; + islpci_private *priv =3D netdev_priv(ndev); + + printk(KERN_DEBUG "%s: islpci_open()\n", ndev->name); + + /* reset data structures, upload firmware and reset device */ + rc =3D islpci_reset(priv,1); + if (rc) { + prism54_bring_down(priv); + return rc; /* Returns informative message */ + } + + netif_start_queue(ndev); +/* netif_mark_up( ndev ); */ + + return 0; +} + +static int +islpci_close(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + + printk(KERN_DEBUG "%s: islpci_close ()\n", ndev->name); + + netif_stop_queue(ndev); + + return prism54_bring_down(priv); +} + +static int +prism54_bring_down(islpci_private *priv) +{ + void *device_base =3D priv->device_base; + u32 reg; + /* we are going to shutdown the device */ + islpci_set_state(priv, PRV_STATE_PREBOOT); + + /* disable all device interrupts in case they weren't */ + isl38xx_disable_interrupts(priv->device_base); =20 + + /* For safety reasons, we may want to ensure that no DMA transfer is + * currently in progress by emptying the TX and RX queues. */ + + /* wait until interrupts have finished executing on other CPUs */ + prism54_synchronize_irq(priv->pdev->irq); + + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~(ISL38XX_CTRL_STAT_RESET | ISL38XX_CTRL_STAT_RAMBOOT); + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the Reset bit */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + + /* wait a while for the device to reset */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(50*HZ/1000); + + return 0; +} + +static int +islpci_upload_fw(islpci_private *priv) +{ + islpci_state_t old_state; + u32 rc; + + old_state =3D islpci_set_state(priv, PRV_STATE_BOOT); + + printk(KERN_DEBUG "%s: uploading firmware...\n", priv->ndev->name); + + rc =3D isl_upload_firmware(priv); + if (rc) { + /* error uploading the firmware */ + printk(KERN_ERR "%s: could not upload firmware ('%s')\n", + priv->ndev->name, priv->firmware); + + islpci_set_state(priv, old_state); + return rc; + } + + printk(KERN_DEBUG + "%s: firmware uploaded done, now triggering reset...\n", + priv->ndev->name); + + islpci_set_state(priv, PRV_STATE_POSTBOOT); + + return 0; +} + +static int +islpci_reset_if(islpci_private *priv) +{ + long remaining; + int result =3D -ETIME; + int count; + + DEFINE_WAIT(wait); + prepare_to_wait(&priv->reset_done, &wait, TASK_UNINTERRUPTIBLE); +=09 + /* now the last step is to reset the interface */ + isl38xx_interface_reset(priv->device_base, priv->device_host_address); + islpci_set_state(priv, PRV_STATE_PREINIT); + + for(count =3D 0; count < 2 && result; count++) { + /* The software reset acknowledge needs about 220 msec here. + * Be conservative and wait for up to one second. */ +=09 + remaining =3D schedule_timeout(HZ); + + if(remaining > 0) { + result =3D 0; + break; + } + + /* If we're here it's because our IRQ hasn't yet gone through.=20 + * Retry a bit more... + */ + printk(KERN_ERR "%s: device soft reset timed out\n", + priv->ndev->name); + + } + + finish_wait(&priv->reset_done, &wait); + + if(result) + return result; + + islpci_set_state(priv, PRV_STATE_INIT); + + /* Now that the device is 100% up, let's allow + * for the other interrupts -- + * NOTE: this is not *yet* true since we've only allowed the=20 + * INIT interrupt on the IRQ line. We can perhaps poll + * the IRQ line until we know for sure the reset went through */ + isl38xx_enable_common_interrupts(priv->device_base); + + down_write(&priv->mib_sem); + mgt_commit(priv); + up_write(&priv->mib_sem); + + islpci_set_state(priv, PRV_STATE_READY); + + return 0; +} + +int +islpci_reset(islpci_private *priv, int reload_firmware) +{ + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + unsigned counter; + int rc; + + if (reload_firmware) + islpci_set_state(priv, PRV_STATE_PREBOOT); + else + islpci_set_state(priv, PRV_STATE_POSTBOOT); + + printk(KERN_DEBUG "%s: resetting device...\n", priv->ndev->name); + + /* disable all device interrupts in case they weren't */ + isl38xx_disable_interrupts(priv->device_base); + + /* flush all management queues */ + priv->index_mgmt_tx =3D 0; + priv->index_mgmt_rx =3D 0; + + /* clear the indexes in the frame pointer */ + for (counter =3D 0; counter < ISL38XX_CB_QCOUNT; counter++) { + cb->driver_curr_frag[counter] =3D cpu_to_le32(0); + cb->device_curr_frag[counter] =3D cpu_to_le32(0); + } + + /* reset the mgmt receive queue */ + for (counter =3D 0; counter < ISL38XX_CB_MGMT_QSIZE; counter++) { + isl38xx_fragment *frag =3D &cb->rx_data_mgmt[counter]; + frag->size =3D cpu_to_le16(MGMT_FRAME_SIZE); + frag->flags =3D 0; + frag->address =3D cpu_to_le32(priv->mgmt_rx[counter].pci_addr); + } + + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + cb->rx_data_low[counter].address =3D + cpu_to_le32((u32) priv->pci_map_rx_address[counter]); + } + + /* since the receive queues are filled with empty fragments, now we can + * set the corresponding indexes in the Control Block */ + priv->control_block->driver_curr_frag[ISL38XX_CB_RX_DATA_LQ] =3D + cpu_to_le32(ISL38XX_CB_RX_QSIZE); + priv->control_block->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] =3D + cpu_to_le32(ISL38XX_CB_MGMT_QSIZE); + + /* reset the remaining real index registers and full flags */ + priv->free_data_rx =3D 0; + priv->free_data_tx =3D 0; + priv->data_low_tx_full =3D 0; + + if (reload_firmware) { /* Should we load the firmware ? */ + /* now that the data structures are cleaned up, upload + * firmware and reset interface */ + rc =3D islpci_upload_fw(priv); + if (rc)=20 + return rc; + } + + /* finally reset interface */ + rc =3D islpci_reset_if(priv); + if (!rc) /* If successful */ + return rc; +=09 + printk(KERN_DEBUG "prism54: Your card/socket may be faulty, or IRQ line = too busy :(\n"); + return rc; + +} + +struct net_device_stats * +islpci_statistics(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_statistics \n"); +#endif + + return &priv->statistics; +} + +/*************************************************************************= ***** + Network device configuration functions +**************************************************************************= ****/ +static int +islpci_alloc_memory(islpci_private *priv) +{ + int counter; + +#if VERBOSE > SHOW_ERROR_MESSAGES + printk(KERN_DEBUG "islpci_alloc_memory\n"); +#endif + + /* remap the PCI device base address to accessable */ + if (!(priv->device_base =3D + ioremap(pci_resource_start(priv->pdev, 0), + ISL38XX_PCI_MEM_SIZE))) { + /* error in remapping the PCI device memory address range */ + printk(KERN_ERR "PCI memory remapping failed \n"); + return -1; + } + + /* memory layout for consistent DMA region: + * + * Area 1: Control Block for the device interface + * Area 2: Power Save Mode Buffer for temporary frame storage. Be aware t= hat + * the number of supported stations in the AP determines the mini= mal + * size of the buffer ! + */ + + /* perform the allocation */ + priv->driver_mem_address =3D pci_alloc_consistent(priv->pdev, + HOST_MEM_BLOCK, + &priv-> + device_host_address); + + if (!priv->driver_mem_address) { + /* error allocating the block of PCI memory */ + printk(KERN_ERR "%s: could not allocate DMA memory, aborting!", + "prism54"); + return -1; + } + + /* assign the Control Block to the first address of the allocated area */ + priv->control_block =3D + (isl38xx_control_block *) priv->driver_mem_address; + + /* set the Power Save Buffer pointer directly behind the CB */ + priv->device_psm_buffer =3D + priv->device_host_address + CONTROL_BLOCK_SIZE; + + /* make sure all buffer pointers are initialized */ + for (counter =3D 0; counter < ISL38XX_CB_QCOUNT; counter++) { + priv->control_block->driver_curr_frag[counter] =3D cpu_to_le32(0); + priv->control_block->device_curr_frag[counter] =3D cpu_to_le32(0); + } + + priv->index_mgmt_rx =3D 0; + memset(priv->mgmt_rx, 0, sizeof(priv->mgmt_rx)); + memset(priv->mgmt_tx, 0, sizeof(priv->mgmt_tx)); + + /* allocate rx queue for management frames */ + if (islpci_mgmt_rx_fill(priv->ndev) < 0) + goto out_free; + + /* now get the data rx skb's */ + memset(priv->data_low_rx, 0, sizeof (priv->data_low_rx)); + memset(priv->pci_map_rx_address, 0, sizeof (priv->pci_map_rx_address)); + + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + struct sk_buff *skb; + + /* allocate an sk_buff for received data frames storage + * each frame on receive size consists of 1 fragment + * include any required allignment operations */ + if (!(skb =3D dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2))) { + /* error allocating an sk_buff structure elements */ + printk(KERN_ERR "Error allocating skb.\n"); + skb =3D NULL; + goto out_free; + } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + /* add the new allocated sk_buff to the buffer array */ + priv->data_low_rx[counter] =3D skb; + + /* map the allocated skb data area to pci */ + priv->pci_map_rx_address[counter] =3D + pci_map_single(priv->pdev, (void *) skb->data, + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + if (!priv->pci_map_rx_address[counter]) { + /* error mapping the buffer to device + accessable memory address */ + printk(KERN_ERR "failed to map skb DMA'able\n"); + goto out_free; + } + } + + prism54_acl_init(&priv->acl); + prism54_wpa_ie_init(priv); + if (mgt_init(priv))=20 + goto out_free; + + return 0; + out_free: + islpci_free_memory(priv); + return -1; +} + +int +islpci_free_memory(islpci_private *priv) +{ + int counter; + + if (priv->device_base) + iounmap(priv->device_base); + priv->device_base =3D 0; + + /* free consistent DMA area... */ + if (priv->driver_mem_address) + pci_free_consistent(priv->pdev, HOST_MEM_BLOCK, + priv->driver_mem_address, + priv->device_host_address); + + /* clear some dangling pointers */ + priv->driver_mem_address =3D 0; + priv->device_host_address =3D 0; + priv->device_psm_buffer =3D 0; + priv->control_block =3D 0; + + /* clean up mgmt rx buffers */ + for (counter =3D 0; counter < ISL38XX_CB_MGMT_QSIZE; counter++) { + struct islpci_membuf *buf =3D &priv->mgmt_rx[counter]; + if (buf->pci_addr) + pci_unmap_single(priv->pdev, buf->pci_addr, + buf->size, PCI_DMA_FROMDEVICE); + buf->pci_addr =3D 0; + if (buf->mem) + kfree(buf->mem); + buf->size =3D 0; + buf->mem =3D NULL; + } + + /* clean up data rx buffers */ + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + if (priv->pci_map_rx_address[counter]) + pci_unmap_single(priv->pdev, + priv->pci_map_rx_address[counter], + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + priv->pci_map_rx_address[counter] =3D 0; + + if (priv->data_low_rx[counter]) + dev_kfree_skb(priv->data_low_rx[counter]); + priv->data_low_rx[counter] =3D 0; + } + + /* Free the acces control list and the WPA list */ + prism54_acl_clean(&priv->acl); + prism54_wpa_ie_clean(priv); + mgt_clean(priv); + + return 0; +} + +#if 0 +static void +islpci_set_multicast_list(struct net_device *dev) +{ + /* put device into promisc mode and let network layer handle it */ +} +#endif + +struct net_device * +islpci_setup(struct pci_dev *pdev) +{ + islpci_private *priv; + struct net_device *ndev =3D alloc_etherdev(sizeof (islpci_private)); + + if (!ndev) + return ndev; + + SET_MODULE_OWNER(ndev); + pci_set_drvdata(pdev, ndev); +#if defined(SET_NETDEV_DEV) + SET_NETDEV_DEV(ndev, &pdev->dev); +#endif + + /* setup the structure members */ + ndev->base_addr =3D pci_resource_start(pdev, 0); + ndev->irq =3D pdev->irq; + + /* initialize the function pointers */ + ndev->open =3D &islpci_open; + ndev->stop =3D &islpci_close; + ndev->get_stats =3D &islpci_statistics; + ndev->get_wireless_stats =3D &prism54_get_wireless_stats; + ndev->do_ioctl =3D &prism54_ioctl; + ndev->wireless_handlers =3D + (struct iw_handler_def *) &prism54_handler_def; + + ndev->hard_start_xmit =3D &islpci_eth_transmit; + /* ndev->set_multicast_list =3D &islpci_set_multicast_list; */ + ndev->addr_len =3D ETH_ALEN; + ndev->set_mac_address =3D &prism54_set_mac_address; + /* Get a non-zero dummy MAC address for nameif. Jean II */ + memcpy(ndev->dev_addr, dummy_mac, 6); + +#ifdef HAVE_TX_TIMEOUT + ndev->watchdog_timeo =3D ISLPCI_TX_TIMEOUT; + ndev->tx_timeout =3D &islpci_eth_tx_timeout; +#endif + + /* allocate a private device structure to the network device */ + priv =3D netdev_priv(ndev); + priv->ndev =3D ndev; + priv->pdev =3D pdev; + priv->monitor_type =3D ARPHRD_IEEE80211; + priv->ndev->type =3D (priv->iw_mode =3D=3D IW_MODE_MONITOR) ? + priv->monitor_type : ARPHRD_ETHER; + + /* save the start and end address of the PCI memory area */ + ndev->mem_start =3D (unsigned long) priv->device_base; + ndev->mem_end =3D ndev->mem_start + ISL38XX_PCI_MEM_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "PCI Memory remapped to 0x%p\n", priv->device_base); +#endif + + init_waitqueue_head(&priv->reset_done); + + /* init the queue read locks, process wait counter */ + sema_init(&priv->mgmt_sem, 1); + priv->mgmt_received =3D NULL; + init_waitqueue_head(&priv->mgmt_wqueue); + sema_init(&priv->stats_sem, 1); + spin_lock_init(&priv->slock); + + /* init state machine with off#1 state */ + priv->state =3D PRV_STATE_OFF; + priv->state_off =3D 1; + + /* initialize workqueue's */ + INIT_WORK(&priv->stats_work, + (void (*)(void *)) prism54_update_stats, priv); + priv->stats_timestamp =3D 0; + + INIT_WORK(&priv->reset_task, islpci_do_reset_and_wake, priv); + priv->reset_task_pending =3D 0; + + /* allocate various memory areas */ + if (islpci_alloc_memory(priv)) + goto do_free_netdev; + + /* select the firmware file depending on the device id */ + switch (pdev->device) { + case PCIDEVICE_ISL3890: + case PCIDEVICE_3COM6001: + strcpy(priv->firmware, ISL3890_IMAGE_FILE); + break; + case PCIDEVICE_ISL3877: + strcpy(priv->firmware, ISL3877_IMAGE_FILE); + break; + + default: + strcpy(priv->firmware, ISL3890_IMAGE_FILE); + break; + } + + if (register_netdev(ndev)) { + DEBUG(SHOW_ERROR_MESSAGES, + "ERROR: register_netdev() failed \n"); + goto do_islpci_free_memory; + } + + return ndev; + + do_islpci_free_memory: + islpci_free_memory(priv); + do_free_netdev: + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + return NULL; +} + +islpci_state_t +islpci_set_state(islpci_private *priv, islpci_state_t new_state) +{ + islpci_state_t old_state; + + /* lock */ + old_state =3D priv->state; + + /* this means either a race condition or some serious error in + * the driver code */ + switch (new_state) { + case PRV_STATE_OFF: + priv->state_off++; + default: + priv->state =3D new_state; + break; + + case PRV_STATE_PREBOOT: + /* there are actually many off-states, enumerated by + * state_off */ + if (old_state =3D=3D PRV_STATE_OFF) + priv->state_off--; + + /* only if hw_unavailable is zero now it means we either + * were in off#1 state, or came here from + * somewhere else */ + if (!priv->state_off) + priv->state =3D new_state; + break; + }; +#if 0 + printk(KERN_DEBUG "%s: state transition %d -> %d (off#%d)\n", + priv->ndev->name, old_state, new_state, priv->state_off); +#endif + + /* invariants */ + BUG_ON(priv->state_off < 0); + BUG_ON(priv->state_off && (priv->state !=3D PRV_STATE_OFF)); + BUG_ON(!priv->state_off && (priv->state =3D=3D PRV_STATE_OFF)); + + /* unlock */ + return old_state; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_dev.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_dev.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_dev.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_dev.h 2004-07-= 15 00:30:04.000000000 +0000 @@ -0,0 +1,215 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc.=20 + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2003 Luis R. Rodriguez + * Copyright (C) 2003 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISLPCI_DEV_H +#define _ISLPCI_DEV_H + +#include +#include +#include +#include +#include + +#include "isl_38xx.h" +#include "isl_oid.h" +#include "islpci_mgt.h" + +/* some states might not be superflous and may be removed when + design is finalized (hvr) */ +typedef enum { + PRV_STATE_OFF =3D 0, /* this means hw_unavailable is !=3D 0 */ + PRV_STATE_PREBOOT, /* we are in a pre-boot state (empty RAM) */ + PRV_STATE_BOOT, /* boot state (fw upload, run fw) */ + PRV_STATE_POSTBOOT, /* after boot state, need reset now */ + PRV_STATE_PREINIT, /* pre-init state */ + PRV_STATE_INIT, /* init state (restore MIB backup to device) */ + PRV_STATE_READY, /* driver&device are in operational state */ + PRV_STATE_SLEEP /* device in sleep mode */ +} islpci_state_t; + +/* ACL using MAC address */ +struct mac_entry { + struct list_head _list; + char addr[ETH_ALEN]; +}; + +struct islpci_acl { + enum { MAC_POLICY_OPEN=3D0, MAC_POLICY_ACCEPT=3D1, MAC_POLICY_REJECT=3D= 2 } policy; + struct list_head mac_list; /* a list of mac_entry */ + int size; /* size of queue */ + struct semaphore sem; /* accessed in ioctls and trap_work */ +}; + +struct islpci_membuf { + int size; /* size of memory */ + void *mem; /* address of memory as seen by CPU */ + dma_addr_t pci_addr; /* address of memory as seen by device */ +}; + +#define MAX_BSS_WPA_IE_COUNT 64 +#define MAX_WPA_IE_LEN 64 +struct islpci_bss_wpa_ie { + struct list_head list; + unsigned long last_update; + u8 bssid[ETH_ALEN]; + u8 wpa_ie[MAX_WPA_IE_LEN]; + size_t wpa_ie_len; +=09 +}; + +typedef struct { + spinlock_t slock; /* generic spinlock; */ +=09 + u32 priv_oid; + + /* our mib cache */ + u32 iw_mode; + struct rw_semaphore mib_sem; + void **mib; + char nickname[IW_ESSID_MAX_SIZE+1]; +=09 + /* Take care of the wireless stats */ + struct work_struct stats_work; + struct semaphore stats_sem; + /* remember when we last updated the stats */ + unsigned long stats_timestamp; + /* The first is accessed under semaphore locking. + * The second is the clean one we return to iwconfig. + */ + struct iw_statistics local_iwstatistics; + struct iw_statistics iwstatistics; + + struct iw_spy_data spy_data; /* iwspy support */ + + int monitor_type; /* ARPHRD_IEEE80211 or ARPHRD_IEEE80211_PRISM */ + + struct islpci_acl acl; + + /* PCI bus allocation & configuration members */ + struct pci_dev *pdev; /* PCI structure information */ + u32 pci_state[16]; /* used for suspend/resume */ + char firmware[33]; + + void *device_base; /* ioremapped device base address */ + + /* consistent DMA region */ + void *driver_mem_address; /* base DMA address */ + dma_addr_t device_host_address; /* base DMA address (bus address) */ + dma_addr_t device_psm_buffer; /* host memory for PSM buffering (bus addre= ss) */ + + /* our network_device structure */ + struct net_device *ndev; + + /* device queue interface members */ + struct isl38xx_cb *control_block; /* device control block=20 + (=3D=3D driver_mem_address!) */ + + /* Each queue has three indexes: + * free/index_mgmt/data_rx/tx (called index, see below), + * driver_curr_frag, and device_curr_frag (in the control block) + * All indexes are ever-increasing, but interpreted modulo the + * device queue size when used. + * index <=3D device_curr_frag <=3D driver_curr_frag at all times + * For rx queues, [index, device_curr_frag) contains fragments + * that the interrupt processing needs to handle (owned by driver). + * [device_curr_frag, driver_curr_frag) is the free space in the + * rx queue, waiting for data (owned by device). The driver + * increments driver_curr_frag to indicate to the device that more + * buffers are available. + * If device_curr_frag =3D=3D driver_curr_frag, no more rx buffers are + * available, and the rx DMA engine of the device is halted. + * For tx queues, [index, device_curr_frag) contains fragments + * where tx is done; they need to be freed (owned by driver). + * [device_curr_frag, driver_curr_frag) contains the frames + * that are being transferred (owned by device). The driver + * increments driver_curr_frag to indicate that more tx work + * needs to be done. + */ + u32 index_mgmt_rx; /* real index mgmt rx queue */ + u32 index_mgmt_tx; /* read index mgmt tx queue */ + u32 free_data_rx; /* free pointer data rx queue */ + u32 free_data_tx; /* free pointer data tx queue */ + u32 data_low_tx_full; /* full detected flag */ + + /* frame memory buffers for the device queues */ + struct islpci_membuf mgmt_tx[ISL38XX_CB_MGMT_QSIZE]; + struct islpci_membuf mgmt_rx[ISL38XX_CB_MGMT_QSIZE]; + struct sk_buff *data_low_tx[ISL38XX_CB_TX_QSIZE]; + struct sk_buff *data_low_rx[ISL38XX_CB_RX_QSIZE]; + dma_addr_t pci_map_tx_address[ISL38XX_CB_TX_QSIZE]; + dma_addr_t pci_map_rx_address[ISL38XX_CB_RX_QSIZE]; + + /* driver network interface members */ + struct net_device_stats statistics; + + /* wait for a reset interrupt */ + wait_queue_head_t reset_done; + + /* used by islpci_mgt_transaction */ + struct semaphore mgmt_sem; /* serialize access to mailbox and wqueue */ + struct islpci_mgmtframe *mgmt_received; /* mbox for incoming frame */ + wait_queue_head_t mgmt_wqueue; /* waitqueue for mbox */ + + /* state machine */ + islpci_state_t state; + int state_off; /* enumeration of off-state, if 0 then + * we're not in any off-state */ + + /* WPA stuff */ + int wpa; /* WPA mode enabled */ + struct list_head bss_wpa_list; + int num_bss_wpa; + struct semaphore wpa_sem; + + struct work_struct reset_task; + int reset_task_pending; +} islpci_private; + +static inline islpci_state_t +islpci_get_state(islpci_private *priv) +{ + /* lock */ + return priv->state; + /* unlock */ +} + +islpci_state_t islpci_set_state(islpci_private *priv, islpci_state_t new_s= tate); + +#define ISLPCI_TX_TIMEOUT (2*HZ) + +irqreturn_t islpci_interrupt(int, void *, struct pt_regs *); + +int prism54_post_setup(islpci_private *, int); +int islpci_reset(islpci_private *, int); + +static inline void +islpci_trigger(islpci_private *priv) +{ + isl38xx_trigger_device(islpci_get_state(priv) =3D=3D PRV_STATE_SLEEP, + priv->device_base); +} + +struct net_device_stats *islpci_statistics(struct net_device *); + +int islpci_free_memory(islpci_private *); +struct net_device *islpci_setup(struct pci_dev *); +#endif /* _ISLPCI_DEV_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_eth.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_eth.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_eth.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_eth.c 2004-07-= 15 00:30:04.000000000 +0000 @@ -0,0 +1,518 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2004 Aurelien Alleaume + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include + +#include +#include +#include +#include +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_eth.h" +#include "islpci_mgt.h" +#include "oid_mgt.h" + +/*************************************************************************= ***** + Network Interface functions +**************************************************************************= ****/ +void +islpci_eth_cleanup_transmit(islpci_private *priv, + isl38xx_control_block *control_block) +{ + struct sk_buff *skb; + u32 index; + + /* compare the control block read pointer with the free pointer */ + while (priv->free_data_tx !=3D + le32_to_cpu(control_block-> + device_curr_frag[ISL38XX_CB_TX_DATA_LQ])) { + /* read the index of the first fragment to be freed */ + index =3D priv->free_data_tx % ISL38XX_CB_TX_QSIZE; + + /* check for holes in the arrays caused by multi fragment frames=20 + * searching for the last fragment of a frame */ + if (priv->pci_map_tx_address[index] !=3D (dma_addr_t) NULL) { + /* entry is the last fragment of a frame + * free the skb structure and unmap pci memory */ + skb =3D priv->data_low_tx[index]; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "cleanup skb %p skb->data %p skb->len %u truesize %u\n ", + skb, skb->data, skb->len, skb->truesize); +#endif + + pci_unmap_single(priv->pdev, + priv->pci_map_tx_address[index], + skb->len, PCI_DMA_TODEVICE); + dev_kfree_skb_irq(skb); + skb =3D NULL; + } + /* increment the free data low queue pointer */ + priv->free_data_tx++; + } +} + +int +islpci_eth_transmit(struct sk_buff *skb, struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D priv->control_block; + u32 index; + dma_addr_t pci_map_address; + int frame_size; + isl38xx_fragment *fragment; + int offset; + struct sk_buff *newskb; + int newskb_offset; + unsigned long flags; + unsigned char wds_mac[6]; + u32 curr_frag; + int err =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_transmit \n"); +#endif + + /* lock the driver code */ + spin_lock_irqsave(&priv->slock, flags); + + /* determine the amount of fragments needed to store the frame */ + + frame_size =3D skb->len < ETH_ZLEN ? ETH_ZLEN : skb->len; + if (init_wds) + frame_size +=3D 6; + + /* check whether the destination queue has enough fragments for the frame= */ + curr_frag =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ]); + if (unlikely(curr_frag - priv->free_data_tx >=3D ISL38XX_CB_TX_QSIZE)) { + printk(KERN_ERR "%s: transmit device queue full when awake\n", + ndev->name); + netif_stop_queue(ndev); + + /* trigger the device */ + isl38xx_w32_flush(priv->device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + err =3D -EBUSY; + goto drop_free; + } + /* Check alignment and WDS frame formatting. The start of the packet shou= ld + * be aligned on a 4-byte boundary. If WDS is enabled add another 6 bytes + * and add WDS address information */ + if (likely(((long) skb->data & 0x03) | init_wds)) { + /* get the number of bytes to add and re-allign */ + offset =3D (4 - (long) skb->data) & 0x03; + offset +=3D init_wds ? 6 : 0; + + /* check whether the current skb can be used */ + if (!skb_cloned(skb) && (skb_tailroom(skb) >=3D offset)) { + unsigned char *src =3D skb->data; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "skb offset %i wds %i\n", offset, + init_wds); +#endif + + /* align the buffer on 4-byte boundary */ + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + if (init_wds) { + /* wds requires an additional address field of 6 bytes */ + skb_put(skb, 6); +#ifdef ISLPCI_ETH_DEBUG + printk("islpci_eth_transmit:wds_mac\n"); +#endif + memmove(skb->data + 6, src, skb->len); + memcpy(skb->data, wds_mac, 6); + } else { + memmove(skb->data, src, skb->len); + } + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "memmove %p %p %i \n", skb->data, + src, skb->len); +#endif + } else { + newskb =3D + dev_alloc_skb(init_wds ? skb->len + 6 : skb->len); + if (unlikely(newskb =3D=3D NULL)) { + printk(KERN_ERR "%s: Cannot allocate skb\n", + ndev->name); + err =3D -ENOMEM; + goto drop_free; + } + newskb_offset =3D (4 - (long) newskb->data) & 0x03; + + /* Check if newskb->data is aligned */ + if (newskb_offset) + skb_reserve(newskb, newskb_offset); + + skb_put(newskb, init_wds ? skb->len + 6 : skb->len); + if (init_wds) { + memcpy(newskb->data + 6, skb->data, skb->len); + memcpy(newskb->data, wds_mac, 6); +#ifdef ISLPCI_ETH_DEBUG + printk("islpci_eth_transmit:wds_mac\n"); +#endif + } else + memcpy(newskb->data, skb->data, skb->len); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "memcpy %p %p %i wds %i\n", + newskb->data, skb->data, skb->len, init_wds); +#endif + + newskb->dev =3D skb->dev; + dev_kfree_skb(skb); + skb =3D newskb; + } + } + /* display the buffer contents for debugging */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_BUFFER_CONTENTS, "\ntx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* map the skb buffer to pci memory for DMA operation */ + pci_map_address =3D pci_map_single(priv->pdev, + (void *) skb->data, skb->len, + PCI_DMA_TODEVICE); + if (unlikely(pci_map_address =3D=3D 0)) { + printk(KERN_WARNING "%s: cannot map buffer to PCI\n", + ndev->name); + + err =3D -EIO; + goto drop_free; + } + /* Place the fragment in the control block structure. */ + index =3D curr_frag % ISL38XX_CB_TX_QSIZE; + fragment =3D &cb->tx_data_low[index]; + + priv->pci_map_tx_address[index] =3D pci_map_address; + /* store the skb address for future freeing */ + priv->data_low_tx[index] =3D skb; + /* set the proper fragment start address and size information */ + fragment->size =3D cpu_to_le16(frame_size); + fragment->flags =3D cpu_to_le16(0); /* set to 1 if more fragments */ + fragment->address =3D cpu_to_le32(pci_map_address); + curr_frag++; + + /* The fragment address in the control block must have been + * written before announcing the frame buffer to device. */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ] =3D cpu_to_le32(curr_frag); + + if (curr_frag - priv->free_data_tx + ISL38XX_MIN_QTHRESHOLD + > ISL38XX_CB_TX_QSIZE) { + /* stop sends from upper layers */ + netif_stop_queue(ndev); + + /* set the full flag for the transmission queue */ + priv->data_low_tx_full =3D 1; + } + + /* trigger the device */ + islpci_trigger(priv); + + /* unlock the driver code */ + spin_unlock_irqrestore(&priv->slock, flags); + + /* set the transmission time */ + ndev->trans_start =3D jiffies; + priv->statistics.tx_packets++; + priv->statistics.tx_bytes +=3D skb->len; + + return 0; + + drop_free: + /* free the skbuf structure before aborting */ + dev_kfree_skb(skb); + skb =3D NULL; + + priv->statistics.tx_dropped++; + spin_unlock_irqrestore(&priv->slock, flags); + return err; +} + +static inline int +islpci_monitor_rx(islpci_private *priv, struct sk_buff **skb) +{ + /* The card reports full 802.11 packets but with a 20 bytes + * header and without the FCS. But there a is a bit that + * indicates if the packet is corrupted :-) */ + struct rfmon_header *hdr =3D (struct rfmon_header *) (*skb)->data; + if (hdr->flags & 0x01) + /* This one is bad. Drop it ! */ + return -1; + if (priv->ndev->type =3D=3D ARPHRD_IEEE80211_PRISM) { + struct avs_80211_1_header *avs; + /* extract the relevant data from the header */ + u32 clock =3D le32_to_cpu(hdr->clock); + u8 rate =3D hdr->rate; + u16 freq =3D le16_to_cpu(hdr->freq); + u8 rssi =3D hdr->rssi; + + skb_pull(*skb, sizeof (struct rfmon_header)); + + if (skb_headroom(*skb) < sizeof (struct avs_80211_1_header)) { + struct sk_buff *newskb =3D skb_copy_expand(*skb, + sizeof (struct + avs_80211_1_header), + 0, GFP_ATOMIC); + if (newskb) { + dev_kfree_skb_irq(*skb); + *skb =3D newskb; + } else + return -1; + /* This behavior is not very subtile... */ + } + + /* make room for the new header and fill it. */ + avs =3D + (struct avs_80211_1_header *) skb_push(*skb, + sizeof (struct + avs_80211_1_header)); + =09 + avs->version =3D cpu_to_be32(P80211CAPTURE_VERSION); + avs->length =3D cpu_to_be32(sizeof (struct avs_80211_1_header)); + avs->mactime =3D cpu_to_be64(le64_to_cpu(clock)); + avs->hosttime =3D cpu_to_be64(jiffies); + avs->phytype =3D cpu_to_be32(6); /*OFDM: 6 for (g), 8 for (a) */ + avs->channel =3D cpu_to_be32(channel_of_freq(freq)); + avs->datarate =3D cpu_to_be32(rate * 5); + avs->antenna =3D cpu_to_be32(0); /*unknown */ + avs->priority =3D cpu_to_be32(0); /*unknown */ + avs->ssi_type =3D cpu_to_be32(3); /*2: dBm, 3: raw RSSI */ + avs->ssi_signal =3D cpu_to_be32(rssi & 0x7f); + avs->ssi_noise =3D cpu_to_be32(priv->local_iwstatistics.qual.noise); /*b= etter than 'undefined', I assume */ + avs->preamble =3D cpu_to_be32(0); /*unknown */ + avs->encoding =3D cpu_to_be32(0); /*unknown */ + } else + skb_pull(*skb, sizeof (struct rfmon_header)); + + (*skb)->protocol =3D htons(ETH_P_802_2); + (*skb)->mac.raw =3D (*skb)->data; + (*skb)->pkt_type =3D PACKET_OTHERHOST; + + return 0; +} + +int +islpci_eth_receive(islpci_private *priv) +{ + struct net_device *ndev =3D priv->ndev; + isl38xx_control_block *control_block =3D priv->control_block; + struct sk_buff *skb; + u16 size; + u32 index, offset; + unsigned char *src; + int discard =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_receive \n"); +#endif + + /* the device has written an Ethernet frame in the data area + * of the sk_buff without updating the structure, do it now */ + index =3D priv->free_data_rx % ISL38XX_CB_RX_QSIZE; + size =3D le16_to_cpu(control_block->rx_data_low[index].size); + skb =3D priv->data_low_rx[index]; + offset =3D ((unsigned long) + le32_to_cpu(control_block->rx_data_low[index].address) - + (unsigned long) skb->data) & 3; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "frq->addr %x skb->data %p skb->len %u offset %u truesize %u\n ", + control_block->rx_data_low[priv->free_data_rx].address, skb->data, + skb->len, offset, skb->truesize); +#endif + + /* delete the streaming DMA mapping before processing the skb */ + pci_unmap_single(priv->pdev, + priv->pci_map_rx_address[index], + MAX_FRAGMENT_SIZE_RX + 2, PCI_DMA_FROMDEVICE); + + /* update the skb structure and allign the buffer */ + skb_put(skb, size); + if (offset) { + /* shift the buffer allocation offset bytes to get the right frame */ + skb_pull(skb, 2); + skb_put(skb, 2); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + /* display the buffer contents for debugging */ + DEBUG(SHOW_BUFFER_CONTENTS, "\nrx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* check whether WDS is enabled and whether the data frame is a WDS frame= */ + + if (init_wds) { + /* WDS enabled, check for the wds address on the first 6 bytes of the bu= ffer */ + src =3D skb->data + 6; + memmove(skb->data, src, skb->len - 6); + skb_trim(skb, skb->len - 6); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Fragment size %i in skb at %p\n", size, skb); + DEBUG(SHOW_TRACING, "Skb data at %p, length %i\n", skb->data, skb->len); + + /* display the buffer contents for debugging */ + DEBUG(SHOW_BUFFER_CONTENTS, "\nrx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* do some additional sk_buff and network layer parameters */ + skb->dev =3D ndev; + + /* take care of monitor mode and spy monitoring. */ + if (unlikely(priv->iw_mode =3D=3D IW_MODE_MONITOR)) + discard =3D islpci_monitor_rx(priv, &skb); + else { + if (unlikely(skb->data[2 * ETH_ALEN] =3D=3D 0)) { + /* The packet has a rx_annex. Read it for spy monitoring, Then + * remove it, while keeping the 2 leading MAC addr. + */ + struct iw_quality wstats; + struct rx_annex_header *annex =3D + (struct rx_annex_header *) skb->data; + wstats.level =3D annex->rfmon.rssi; + /* The noise value can be a bit outdated if nobody's=20 + * reading wireless stats... */ + wstats.noise =3D priv->local_iwstatistics.qual.noise; + wstats.qual =3D wstats.level - wstats.noise; + wstats.updated =3D 0x07; + /* Update spy records */ + wireless_spy_update(ndev, annex->addr2, &wstats); + + memcpy(skb->data + sizeof (struct rfmon_header), + skb->data, 2 * ETH_ALEN); + skb_pull(skb, sizeof (struct rfmon_header)); + } + skb->protocol =3D eth_type_trans(skb, ndev); + } + skb->ip_summed =3D CHECKSUM_NONE; + priv->statistics.rx_packets++; + priv->statistics.rx_bytes +=3D size; + + /* deliver the skb to the network layer */ +#ifdef ISLPCI_ETH_DEBUG + printk + ("islpci_eth_receive:netif_rx %2.2X %2.2X %2.2X %2.2X %2.2X %2.2X\n", + skb->data[0], skb->data[1], skb->data[2], skb->data[3], + skb->data[4], skb->data[5]); +#endif + if (unlikely(discard)) { + dev_kfree_skb_irq(skb); + skb =3D NULL; + } else + netif_rx(skb); + + /* increment the read index for the rx data low queue */ + priv->free_data_rx++; + + /* add one or more sk_buff structures */ + while (index =3D + le32_to_cpu(control_block-> + driver_curr_frag[ISL38XX_CB_RX_DATA_LQ]), + index - priv->free_data_rx < ISL38XX_CB_RX_QSIZE) { + /* allocate an sk_buff for received data frames storage + * include any required allignment operations */ + skb =3D dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2); + if (unlikely(skb =3D=3D NULL)) { + /* error allocating an sk_buff structure elements */ + DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb \n"); + break; + } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + /* store the new skb structure pointer */ + index =3D index % ISL38XX_CB_RX_QSIZE; + priv->data_low_rx[index] =3D skb; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "new alloc skb %p skb->data %p skb->len %u index %u truesize %u\n = ", + skb, skb->data, skb->len, index, skb->truesize); +#endif + + /* set the streaming DMA mapping for proper PCI bus operation */ + priv->pci_map_rx_address[index] =3D + pci_map_single(priv->pdev, (void *) skb->data, + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + if (unlikely(priv->pci_map_rx_address[index] =3D=3D (dma_addr_t) NULL)) { + /* error mapping the buffer to device accessable memory address */ + DEBUG(SHOW_ERROR_MESSAGES, + "Error mapping DMA address\n"); + + /* free the skbuf structure before aborting */ + dev_kfree_skb_irq((struct sk_buff *) skb); + skb =3D NULL; + break; + } + /* update the fragment address */ + control_block->rx_data_low[index].address =3D cpu_to_le32((u32) + priv-> + pci_map_rx_address + [index]); + wmb(); + + /* increment the driver read pointer */ + add_le32p((u32 *) &control_block-> + driver_curr_frag[ISL38XX_CB_RX_DATA_LQ], 1); + } + + /* trigger the device */ + islpci_trigger(priv); + + return 0; +} + +void +islpci_do_reset_and_wake(void *data) +{ + islpci_private *priv =3D (islpci_private *) data; + islpci_reset(priv, 1); + netif_wake_queue(priv->ndev); + priv->reset_task_pending =3D 0; +} + +void +islpci_eth_tx_timeout(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct net_device_stats *statistics =3D &priv->statistics; + + /* increment the transmit error counter */ + statistics->tx_errors++; + + if (!priv->reset_task_pending) { + priv->reset_task_pending =3D 1; + netif_stop_queue(ndev); + schedule_work(&priv->reset_task); + } + + return; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_eth.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_eth.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_eth.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_eth.h 2004-07-= 15 00:30:04.000000000 +0000 @@ -0,0 +1,73 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISLPCI_ETH_H +#define _ISLPCI_ETH_H + +#include "isl_38xx.h" +#include "islpci_dev.h" + +struct rfmon_header { + u16 unk0; /* =3D 0x0000 */ + u16 length; /* =3D 0x1400 */ + u32 clock; /* 1MHz clock */ + u8 flags; + u8 unk1; + u8 rate; + u8 unk2; + u16 freq; + u16 unk3; + u8 rssi; + u8 padding[3]; +} __attribute__ ((packed)); + +struct rx_annex_header { + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + struct rfmon_header rfmon; +} __attribute__ ((packed)); + +/* wlan-ng (and hopefully others) AVS header, version one. Fields in + * network byte order. */ +#define P80211CAPTURE_VERSION 0x80211001 + +struct avs_80211_1_header { + uint32_t version; + uint32_t length; + uint64_t mactime; + uint64_t hosttime; + uint32_t phytype; + uint32_t channel; + uint32_t datarate; + uint32_t antenna; + uint32_t priority; + uint32_t ssi_type; + int32_t ssi_signal; + int32_t ssi_noise; + uint32_t preamble; + uint32_t encoding; +}; + +void islpci_eth_cleanup_transmit(islpci_private *, isl38xx_control_block *= ); +int islpci_eth_transmit(struct sk_buff *, struct net_device *); +int islpci_eth_receive(islpci_private *); +void islpci_eth_tx_timeout(struct net_device *); +void islpci_do_reset_and_wake(void *data); + +#endif /* _ISL_GEN_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_hotplug.c linux-2.4.26-prism54/drivers/net/wireless/prism54/i= slpci_hotplug.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_hotplug.c 1970-01-01 0= 0:00:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_hotplug.c 2004= -07-15 00:30:04.000000000 +0000 @@ -0,0 +1,491 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Herbert Valerio Riedel + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include +#include +#include +#include /* For __init, __exit */ + +#include "prismcompat.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" /* for pc_debug */ +#include "isl_oid.h" + +#define DRV_NAME "prism54" +#define DRV_VERSION "1.2" + +MODULE_AUTHOR("[Intersil] R.Bastings and W.Termorshuizen, The prism54.org = Development Team "); +MODULE_DESCRIPTION("The Prism54 802.11 Wireless LAN adapter"); +MODULE_LICENSE("GPL"); + +/* In this order: vendor, device, subvendor, subdevice, class, class_mask, + * driver_data=20 + * If you have an update for this please contact prism54-devel@prism54.org= =20 + * The latest list can be found at http://prism54.org/supported_cards.php = */ +static const struct pci_device_id prism54_id_tbl[] =3D { + /* 3COM 3CRWE154G72 Wireless LAN adapter */ + { + PCIVENDOR_3COM, PCIDEVICE_3COM6001, + PCIVENDOR_3COM, PCIDEVICE_3COM6001, + 0, 0, 0 + }, + + /* D-Link Air Plus Xtreme G A1 - DWL-g650 A1 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_DLINK, 0x3202UL,=20 + 0, 0, 0 + }, + + /* I-O Data WN-G54/CB - WN-G54/CB */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_IODATA, 0xd019UL,=20 + 0, 0, 0 + }, + + /* Netgear WG511 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_NETGEAR, 0x4800UL, + 0, 0, 0 + }, + + /* Tekram Technology clones, Allnet, Netcomm, Zyxel */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_TTL, 0x1605UL, + 0, 0, 0 + }, + + /* SMC2802W */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0x2802UL, + 0, 0, 0 + }, + + /* SMC2835W */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0x2835UL, + 0, 0, 0 + }, + + /* Corega CG-WLCB54GT */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_ATI, 0xc104UL, + 0, 0, 0 + }, + + /* I4 Z-Com XG-600 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_I4, 0x0014UL, + 0, 0, 0 + }, + + /* I4 Z-Com XG-900 and clones Macer, Ovislink, Planex, Peabird, */ + /* Sitecom, Xterasys */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_I4, 0x0020UL, + 0, 0, 0 + }, + + /* SMC 2802W V2 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_ACCTON, 0xee03UL, + 0, 0, 0 + }, + + /* SMC 2835W V2 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0xa835UL, + 0, 0, 0 + }, + + /* Intersil PRISM Indigo Wireless LAN adapter */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3877, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, 0 + }, + + /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ + /* Default */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, 0 + }, + + /* End of list */ + {0,0,0,0,0,0,0} +}; + +/* register the device with the Hotplug facilities of the kernel */ +MODULE_DEVICE_TABLE(pci, prism54_id_tbl); + +static int prism54_probe(struct pci_dev *, const struct pci_device_id *); +static void prism54_remove(struct pci_dev *); +static int prism54_suspend(struct pci_dev *, u32 state); +static int prism54_resume(struct pci_dev *); + +static struct pci_driver prism54_driver =3D { + .name =3D DRV_NAME, + .id_table =3D prism54_id_tbl, + .probe =3D prism54_probe, + .remove =3D prism54_remove, + .suspend =3D prism54_suspend, + .resume =3D prism54_resume, + /* .enable_wake ; we don't support this yet */ +}; + +static void +prism54_get_card_model(struct net_device *ndev) +{ + islpci_private *priv; + char *modelp; + int notwork =3D 0; + + priv =3D netdev_priv(ndev); + switch (priv->pdev->subsystem_device) { + case PCIDEVICE_ISL3877: + modelp =3D "PRISM Indigo"; + break; + case PCIDEVICE_ISL3886: + modelp =3D "PRISM Javelin / Xbow"; + break; + case PCIDEVICE_3COM6001: + modelp =3D "3COM 3CRWE154G72"; + break; + case 0x3202UL: + modelp =3D "D-Link DWL-g650 A1"; + break; + case 0xd019UL: + modelp =3D "WN-G54/CB"; + break; + case 0x4800UL: + modelp =3D "Netgear WG511"; + break; + case 0x2802UL: + modelp =3D "SMC2802W"; + break; + case 0xee03UL: + modelp =3D "SMC2802W V2"; + notwork =3D 1; + break; + case 0x2835UL: + modelp =3D "SMC2835W"; + break; + case 0xa835UL: + modelp =3D "SMC2835W V2"; + notwork =3D 1; + break; + case 0xc104UL: + modelp =3D "CG-WLCB54GT"; + break; + case 0x1605UL: + modelp =3D "Tekram Technology clone"; + break; + /* Let's leave this one out for now since it seems bogus/wrong=20 + * Even if the manufacturer did use 0x0000UL it may not be correct + * by their part, therefore deserving no name ;) */ + /* case 0x0000UL:=20 + * modelp =3D "SparkLAN WL-850F"; + * break;*/ + + /* We have two reported for the one below :( */ + case 0x0014UL: + modelp =3D "I4 Z-Com XG-600 and clones"; + break; + case 0x0020UL: + modelp =3D "I4 Z-Com XG-900 and clones"; + break; +/* Default it */ +/* + case PCIDEVICE_ISL3890: + modelp =3D "PRISM Duette/GT"; + break; +*/ + default: + modelp =3D "PRISM Duette/GT"; + } + printk(KERN_DEBUG "%s: %s driver detected card model: %s\n", + ndev->name, DRV_NAME, modelp); + if ( notwork ) { + printk(KERN_DEBUG "%s: %s Warning - This may not work\n", + ndev->name, DRV_NAME); + } + return; +} + +/*************************************************************************= ***** + Module initialization functions +**************************************************************************= ****/ + +int +prism54_probe(struct pci_dev *pdev, const struct pci_device_id *id) +{ + struct net_device *ndev; + u8 latency_tmr; + u32 mem_addr; + islpci_private *priv; + int rvalue; + + /* TRACE(DRV_NAME); */ +=09 +=09 + /* Enable the pci device */ + if (pci_enable_device(pdev)) { + printk(KERN_ERR "%s: pci_enable_device() failed.\n", DRV_NAME); + return -ENODEV; + } + + /* check whether the latency timer is set correctly */ + pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency_tmr); +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "latency timer: %x\n", latency_tmr); +#endif + if (latency_tmr < PCIDEVICE_LATENCY_TIMER_MIN) { + /* set the latency timer */ + pci_write_config_byte(pdev, PCI_LATENCY_TIMER, + PCIDEVICE_LATENCY_TIMER_VAL); + } + + /* enable PCI DMA */ + if (pci_set_dma_mask(pdev, 0xffffffff)) { + printk(KERN_ERR "%s: 32-bit PCI DMA not supported", DRV_NAME); + goto do_pci_disable_device; + } + + /* 0x40 is the programmable timer to configure the response timeout (TRDY= _TIMEOUT) + * 0x41 is the programmable timer to configure the retry timeout (RETRY_T= IMEOUT) + * The RETRY_TIMEOUT is used to set the number of retries that the core,= as a + * Master, will perform before abandoning a cycle. The default value for + * RETRY_TIMEOUT is 0x80, which far exceeds the PCI 2.1 requirement for = new + * devices. A write of zero to the RETRY_TIMEOUT register disables this + * function to allow use with any non-compliant legacy devices that may + * execute more retries. + * + * Writing zero to both these two registers will disable both timeouts a= nd + * *can* solve problems caused by devices that are slow to respond. + */ + /* I am taking these out, we should not be poking around in the + * programmable timers - MSW + */ +/* Do not zero the programmable timers + pci_write_config_byte(pdev, 0x40, 0); + pci_write_config_byte(pdev, 0x41, 0); +*/ + + /* request the pci device I/O regions */ + rvalue =3D pci_request_regions(pdev, DRV_NAME); + if (rvalue) { + printk(KERN_ERR "%s: pci_request_regions failure (rc=3D%d)\n", + DRV_NAME, rvalue); + goto do_pci_disable_device; + } + + /* check if the memory window is indeed set */ + rvalue =3D pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &mem_addr); + if (rvalue || !mem_addr) { + printk(KERN_ERR "%s: PCI device memory region not configured; fix your B= IOS or CardBus bridge/drivers\n", + DRV_NAME); + goto do_pci_disable_device; + } + + /* enable PCI bus-mastering */ + DEBUG(SHOW_TRACING, "%s: pci_set_master(pdev)\n", DRV_NAME); + pci_set_master(pdev); + + /* enable MWI */ + pci_set_mwi(pdev); + + /* setup the network device interface and its structure */ + if (!(ndev =3D islpci_setup(pdev))) { + /* error configuring the driver as a network device */ + printk(KERN_ERR "%s: could not configure network device\n", + DRV_NAME); + goto do_pci_release_regions; + } + + priv =3D netdev_priv(ndev); + islpci_set_state(priv, PRV_STATE_PREBOOT); /* we are attempting to boot */ + + /* card is in unknown state yet, might have some interrupts pending */ + isl38xx_disable_interrupts(priv->device_base); + + /* request for the interrupt before uploading the firmware */ + rvalue =3D request_irq(pdev->irq, &islpci_interrupt, + SA_SHIRQ, ndev->name, priv); + + if (rvalue) { + /* error, could not hook the handler to the irq */ + printk(KERN_ERR "%s: could not install IRQ handler\n", + ndev->name); + goto do_unregister_netdev; + } + + /* firmware upload is triggered in islpci_open */ + + /* Pretty card model discovery output */ + prism54_get_card_model(ndev); + + return 0; + + do_unregister_netdev: + unregister_netdev(ndev); + islpci_free_memory(priv); + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + do_pci_release_regions: + pci_release_regions(pdev); + do_pci_disable_device: + pci_disable_device(pdev); + return -EIO; +} + +/* set by cleanup_module */ +static volatile int __in_cleanup_module =3D 0; + +/* this one removes one(!!) instance only */ +void +prism54_remove(struct pci_dev *pdev) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + if (!__in_cleanup_module) { + printk(KERN_DEBUG "%s: hot unplug detected\n", ndev->name); + islpci_set_state(priv, PRV_STATE_OFF); + } + + printk(KERN_DEBUG "%s: removing device\n", ndev->name); + + unregister_netdev(ndev); + + /* free the interrupt request */ + + if (islpci_get_state(priv) !=3D PRV_STATE_OFF) { + isl38xx_disable_interrupts(priv->device_base); + islpci_set_state(priv, PRV_STATE_OFF); + /* This bellow causes a lockup at rmmod time. It might be + * because some interrupts still linger after rmmod time,=20 + * see bug #17 */ + /* pci_set_power_state(pdev, 3);*/ /* try to power-off */ + } + + free_irq(pdev->irq, priv); + + /* free the PCI memory and unmap the remapped page */ + islpci_free_memory(priv); + + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + + pci_release_regions(pdev); + + pci_disable_device(pdev); +} + +int +prism54_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + printk(KERN_NOTICE "%s: got suspend request (state %d)\n", + ndev->name, state); + + pci_save_state(pdev, priv->pci_state); + + /* tell the device not to trigger interrupts for now... */ + isl38xx_disable_interrupts(priv->device_base); + + /* from now on assume the hardware was already powered down + and don't touch it anymore */ + islpci_set_state(priv, PRV_STATE_OFF); + + netif_stop_queue(ndev); + netif_device_detach(ndev); + + return 0; +} + +int +prism54_resume(struct pci_dev *pdev) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + printk(KERN_NOTICE "%s: got resume request\n", ndev->name); + + pci_restore_state(pdev, priv->pci_state); + + /* alright let's go into the PREBOOT state */ + islpci_reset(priv, 1); + + netif_device_attach(ndev); + netif_start_queue(ndev); + + return 0; +} + +static int __init +prism54_module_init(void) +{ + printk(KERN_INFO "Loaded %s driver, version %s\n", + DRV_NAME, DRV_VERSION); + + __bug_on_wrong_struct_sizes (); + + return pci_module_init(&prism54_driver); +} + +/* by the time prism54_module_exit() terminates, as a postcondition + * all instances will have been destroyed by calls to + * prism54_remove() */ +static void __exit +prism54_module_exit(void) +{ + __in_cleanup_module =3D 1; + + pci_unregister_driver(&prism54_driver); + + printk(KERN_INFO "Unloaded %s driver\n", DRV_NAME); + + __in_cleanup_module =3D 0; +} + +/* register entry points */ +module_init(prism54_module_init); +module_exit(prism54_module_exit); +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_mgt.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_mgt.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_mgt.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_mgt.c 2004-07-= 15 00:30:04.000000000 +0000 @@ -0,0 +1,508 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright 2004 Jens Maurer + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include +#include +#include + +#include +#include +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_mgt.h" +#include "isl_oid.h" /* additional types and defs for isl38xx fw */ +#include "isl_ioctl.h" + +#include + +/*************************************************************************= ***** + Global variable definition section +**************************************************************************= ****/ +int pc_debug =3D VERBOSE; +module_param(pc_debug, int, 0); + +/*************************************************************************= ***** + Driver general functions +**************************************************************************= ****/ +void +display_buffer(char *buffer, int length) +{ + if ((pc_debug & SHOW_BUFFER_CONTENTS) =3D=3D 0) + return; + + while (length > 0) { + printk("[%02x]", *buffer & 255); + length--; + buffer++; + } + + printk("\n"); +} + +/*************************************************************************= **** + Queue handling for management frames +**************************************************************************= ****/ + +/* + * Helper function to create a PIMFOR management frame header. + */ +static void +pimfor_encode_header(int operation, u32 oid, u32 length, pimfor_header_t *= h) +{ + h->version =3D PIMFOR_VERSION; + h->operation =3D operation; + h->device_id =3D PIMFOR_DEV_ID_MHLI_MIB; + h->flags =3D 0; + h->oid =3D cpu_to_be32(oid); + h->length =3D cpu_to_be32(length); +} + +/* + * Helper function to analyze a PIMFOR management frame header. + */ +static pimfor_header_t * +pimfor_decode_header(void *data, int len) +{ + pimfor_header_t *h =3D data; + + while ((void *) h < data + len) { + if (h->flags & PIMFOR_FLAG_LITTLE_ENDIAN) { + le32_to_cpus(&h->oid); + le32_to_cpus(&h->length); + } else { + be32_to_cpus(&h->oid); + be32_to_cpus(&h->length); + } + if (h->oid !=3D OID_INL_TUNNEL) + return h; + h++; + } + return NULL; +} + +/* + * Fill the receive queue for management frames with fresh buffers. + */ +int +islpci_mgmt_rx_fill(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + u32 curr =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ]); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgmt_rx_fill \n"); +#endif + + while (curr - priv->index_mgmt_rx < ISL38XX_CB_MGMT_QSIZE) { + u32 index =3D curr % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_rx[index]; + isl38xx_fragment *frag =3D &cb->rx_data_mgmt[index]; + + if (buf->mem =3D=3D NULL) { + buf->mem =3D kmalloc(MGMT_FRAME_SIZE, GFP_ATOMIC); + if (!buf->mem) { + printk(KERN_WARNING + "Error allocating management frame.\n"); + return -ENOMEM; + } + buf->size =3D MGMT_FRAME_SIZE; + } + if (buf->pci_addr =3D=3D 0) { + buf->pci_addr =3D pci_map_single(priv->pdev, buf->mem, + MGMT_FRAME_SIZE, + PCI_DMA_FROMDEVICE); + if (!buf->pci_addr) { + printk(KERN_WARNING + "Failed to make memory DMA'able\n."); + return -ENOMEM; + } + } + + /* be safe: always reset control block information */ + frag->size =3D cpu_to_le16(MGMT_FRAME_SIZE); + frag->flags =3D 0; + frag->address =3D cpu_to_le32(buf->pci_addr); + curr++; + + /* The fragment address in the control block must have + * been written before announcing the frame buffer to + * device */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] =3D cpu_to_le32(curr); + } + return 0; +} + +/* + * Create and transmit a management frame using "operation" and "oid", + * with arguments data/length. + * We either return an error and free the frame, or we return 0 and + * islpci_mgt_cleanup_transmit() frees the frame in the tx-done + * interrupt. + */ +static int +islpci_mgt_transmit(struct net_device *ndev, int operation, unsigned long = oid, + void *data, int length) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D + (isl38xx_control_block *) priv->control_block; + void *p; + int err =3D -EINVAL; + unsigned long flags; + isl38xx_fragment *frag; + struct islpci_membuf buf; + u32 curr_frag; + int index; + int frag_len =3D length + PIMFOR_HEADER_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_transmit\n"); +#endif + + if (frag_len > MGMT_FRAME_SIZE) { + printk(KERN_DEBUG "%s: mgmt frame too large %d\n", + ndev->name, frag_len); + goto error; + } + + err =3D -ENOMEM; + p =3D buf.mem =3D kmalloc(frag_len, GFP_KERNEL); + if (!buf.mem) { + printk(KERN_DEBUG "%s: cannot allocate mgmt frame\n", + ndev->name); + goto error; + } + buf.size =3D frag_len; + + /* create the header directly in the fragment data area */ + pimfor_encode_header(operation, oid, length, (pimfor_header_t *) p); + p +=3D PIMFOR_HEADER_SIZE; + + if (data) + memcpy(p, data, length); + else + memset(p, 0, length); + +#if VERBOSE > SHOW_ERROR_MESSAGES + { + pimfor_header_t *h =3D buf.mem; + DEBUG(SHOW_PIMFOR_FRAMES, + "PIMFOR: op %i, oid 0x%08lx, device %i, flags 0x%x length 0x%x \n", + h->operation, oid, h->device_id, h->flags, length); + + /* display the buffer contents for debugging */ + display_buffer((char *) h, sizeof (pimfor_header_t)); + display_buffer(p, length); + } +#endif + + err =3D -ENOMEM; + buf.pci_addr =3D pci_map_single(priv->pdev, buf.mem, frag_len, + PCI_DMA_TODEVICE); + if (!buf.pci_addr) { + printk(KERN_WARNING "%s: cannot map PCI memory for mgmt\n", + ndev->name); + goto error_free; + } + + /* Protect the control block modifications against interrupts. */ + spin_lock_irqsave(&priv->slock, flags); + curr_frag =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ]); + if (curr_frag - priv->index_mgmt_tx >=3D ISL38XX_CB_MGMT_QSIZE) { + printk(KERN_WARNING "%s: mgmt tx queue is still full\n", + ndev->name); + goto error_unlock; + } + + /* commit the frame to the tx device queue */ + index =3D curr_frag % ISL38XX_CB_MGMT_QSIZE; + priv->mgmt_tx[index] =3D buf; + frag =3D &cb->tx_data_mgmt[index]; + frag->size =3D cpu_to_le16(frag_len); + frag->flags =3D 0; /* for any other than the last fragment, set to 1 */ + frag->address =3D cpu_to_le32(buf.pci_addr); + + /* The fragment address in the control block must have + * been written before announcing the frame buffer to + * device */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ] =3D cpu_to_le32(curr_frag + 1); + spin_unlock_irqrestore(&priv->slock, flags); + + /* trigger the device */ + islpci_trigger(priv); + return 0; + + error_unlock: + spin_unlock_irqrestore(&priv->slock, flags); + error_free: + kfree(buf.mem); + error: + return err; +} + +/* + * Receive a management frame from the device. + * This can be an arbitrary number of traps, and at most one response + * frame for a previous request sent via islpci_mgt_transmit(). + */ +int +islpci_mgt_receive(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D + (isl38xx_control_block *) priv->control_block; + u32 curr_frag; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_receive \n"); +#endif + + /* Only once per interrupt, determine fragment range to + * process. This avoids an endless loop (i.e. lockup) if + * frames come in faster than we can process them. */ + curr_frag =3D le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_RX_MGMTQ]); + barrier(); + + for (; priv->index_mgmt_rx < curr_frag; priv->index_mgmt_rx++) { + pimfor_header_t *header; + u32 index =3D priv->index_mgmt_rx % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_rx[index]; + u16 frag_len; + int size; + struct islpci_mgmtframe *frame; + + /* I have no idea (and no documentation) if flags !=3D 0 + * is possible. Drop the frame, reuse the buffer. */ + if (le16_to_cpu(cb->rx_data_mgmt[index].flags) !=3D 0) { + printk(KERN_WARNING "%s: unknown flags 0x%04x\n", + ndev->name, + le16_to_cpu(cb->rx_data_mgmt[index].flags)); + continue; + } + + /* The device only returns the size of the header(s) here. */ + frag_len =3D le16_to_cpu(cb->rx_data_mgmt[index].size); + + /* + * We appear to have no way to tell the device the + * size of a receive buffer. Thus, if this check + * triggers, we likely have kernel heap corruption. */ + if (frag_len > MGMT_FRAME_SIZE) { + printk(KERN_WARNING + "%s: Bogus packet size of %d (%#x).\n", + ndev->name, frag_len, frag_len); + frag_len =3D MGMT_FRAME_SIZE; + } + + /* Ensure the results of device DMA are visible to the CPU. */ + pci_dma_sync_single(priv->pdev, buf->pci_addr, + buf->size, PCI_DMA_FROMDEVICE); + + /* Perform endianess conversion for PIMFOR header in-place. */ + header =3D pimfor_decode_header(buf->mem, frag_len); + if (!header) { + printk(KERN_WARNING "%s: no PIMFOR header found\n", + ndev->name); + continue; + } + + /* The device ID from the PIMFOR packet received from + * the MVC is always 0. We forward a sensible device_id. + * Not that anyone upstream would care... */ + header->device_id =3D priv->ndev->ifindex; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_PIMFOR_FRAMES, + "PIMFOR: op %i, oid 0x%08x, device %i, flags 0x%x length 0x%x \n", + header->operation, header->oid, header->device_id, + header->flags, header->length); + + /* display the buffer contents for debugging */ + display_buffer((char *) header, PIMFOR_HEADER_SIZE); + display_buffer((char *) header + PIMFOR_HEADER_SIZE, + header->length); +#endif + + /* nobody sends these */ + if (header->flags & PIMFOR_FLAG_APPLIC_ORIGIN) { + printk(KERN_DEBUG + "%s: errant PIMFOR application frame\n", + ndev->name); + continue; + } + + /* Determine frame size, skipping OID_INL_TUNNEL headers. */ + size =3D PIMFOR_HEADER_SIZE + header->length; + frame =3D kmalloc(sizeof (struct islpci_mgmtframe) + size, + GFP_ATOMIC); + if (!frame) { + printk(KERN_WARNING + "%s: Out of memory, cannot handle oid 0x%08x\n", + ndev->name, header->oid); + continue; + } + frame->ndev =3D ndev; + memcpy(&frame->buf, header, size); + frame->header =3D (pimfor_header_t *) frame->buf; + frame->data =3D frame->buf + PIMFOR_HEADER_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_PIMFOR_FRAMES, + "frame: header: %p, data: %p, size: %d\n", + frame->header, frame->data, size); +#endif + + if (header->operation =3D=3D PIMFOR_OP_TRAP) { +#if VERBOSE > SHOW_ERROR_MESSAGES + printk(KERN_DEBUG + "TRAP: oid 0x%x, device %i, flags 0x%x length %i\n", + header->oid, header->device_id, header->flags, + header->length); +#endif + + /* Create work to handle trap out of interrupt + * context. */ + INIT_WORK(&frame->ws, prism54_process_trap, frame); + schedule_work(&frame->ws); + + } else { + /* Signal the one waiting process that a response + * has been received. */ + if ((frame =3D xchg(&priv->mgmt_received, frame)) !=3D NULL) { + printk(KERN_WARNING + "%s: mgmt response not collected\n", + ndev->name); + kfree(frame); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Wake up Mgmt Queue\n"); +#endif + wake_up(&priv->mgmt_wqueue); + } + + } + + return 0; +} + +/* + * Cleanup the transmit queue by freeing all frames handled by the device. + */ +void +islpci_mgt_cleanup_transmit(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + u32 curr_frag; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_cleanup_transmit\n"); +#endif + + /* Only once per cleanup, determine fragment range to + * process. This avoids an endless loop (i.e. lockup) if + * the device became confused, incrementing device_curr_frag + * rapidly. */ + curr_frag =3D le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_TX_MGMTQ]); + barrier(); + + for (; priv->index_mgmt_tx < curr_frag; priv->index_mgmt_tx++) { + int index =3D priv->index_mgmt_tx % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_tx[index]; + pci_unmap_single(priv->pdev, buf->pci_addr, buf->size, + PCI_DMA_TODEVICE); + buf->pci_addr =3D 0; + kfree(buf->mem); + buf->mem =3D NULL; + buf->size =3D 0; + } +} + +/* + * Perform one request-response transaction to the device. + */ +int +islpci_mgt_transaction(struct net_device *ndev, + int operation, unsigned long oid, + void *senddata, int sendlen, + struct islpci_mgmtframe **recvframe) +{ + islpci_private *priv =3D netdev_priv(ndev); + const long wait_cycle_jiffies =3D (ISL38XX_WAIT_CYCLE * 10 * HZ) / 1000; + long timeout_left =3D ISL38XX_MAX_WAIT_CYCLES * wait_cycle_jiffies; + int err; + DEFINE_WAIT(wait); + + if (down_interruptible(&priv->mgmt_sem)) + return -ERESTARTSYS; + + prepare_to_wait(&priv->mgmt_wqueue, &wait, TASK_UNINTERRUPTIBLE); + err =3D islpci_mgt_transmit(ndev, operation, oid, senddata, sendlen); + if (err) + goto out; + + err =3D -ETIMEDOUT; + while (timeout_left > 0) { + int timeleft; + struct islpci_mgmtframe *frame; + + timeleft =3D schedule_timeout(wait_cycle_jiffies); + frame =3D xchg(&priv->mgmt_received, NULL); + if (frame) { + if (frame->header->oid =3D=3D oid) { + *recvframe =3D frame; + err =3D 0; + goto out; + } else { + printk(KERN_DEBUG + "%s: expecting oid 0x%x, received 0x%x.\n", + ndev->name, (unsigned int) oid, + frame->header->oid); + kfree(frame); + frame =3D NULL; + } + } + if (timeleft =3D=3D 0) { + printk(KERN_DEBUG + "%s: timeout waiting for mgmt response %lu, " + "triggering device\n", + ndev->name, timeout_left); + islpci_trigger(priv); + } + timeout_left +=3D timeleft - wait_cycle_jiffies; + } + printk(KERN_WARNING "%s: timeout waiting for mgmt response\n", + ndev->name); + + /* TODO: we should reset the device here */ =20 + out: + finish_wait(&priv->mgmt_wqueue, &wait); + up(&priv->mgmt_sem); + return err; +} + diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_mgt.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_mgt.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_mgt.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_mgt.h 2004-07-= 15 00:30:04.000000000 +0000 @@ -0,0 +1,162 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISLPCI_MGT_H +#define _ISLPCI_MGT_H + +#include +#include + +/* + * Function definitions + */ + +#define K_DEBUG(f, m, args...) do { if(f & m) printk(KERN_DEBUG args); } w= hile(0) +#define DEBUG(f, args...) K_DEBUG(f, pc_debug, args) + +#define TRACE(devname) K_DEBUG(SHOW_TRACING, VERBOSE, "%s: -> " __FUNCT= ION__ "()\n", devname) + +extern int pc_debug; +#define init_wds 0 /* help compiler optimize away dead code */ + + +/* General driver definitions */ +#define PCIVENDOR_INTERSIL 0x1260UL +#define PCIVENDOR_3COM 0x10b7UL +#define PCIVENDOR_DLINK 0x1186UL +#define PCIVENDOR_I4 0x17cfUL +#define PCIVENDOR_IODATA 0x10fcUL +#define PCIVENDOR_NETGEAR 0x1385UL +#define PCIVENDOR_SMC 0x10b8UL +#define PCIVENDOR_ACCTON 0x1113UL +#define PCIVENDOR_ATI 0x1259UL +#define PCIVENDOR_TTL 0x16a5UL + +#define PCIDEVICE_ISL3877 0x3877UL +#define PCIDEVICE_ISL3886 0x3886UL +#define PCIDEVICE_ISL3890 0x3890UL +#define PCIDEVICE_3COM6001 0x6001UL +#define PCIDEVICE_LATENCY_TIMER_MIN 0x40 +#define PCIDEVICE_LATENCY_TIMER_VAL 0x50 + +/* Debugging verbose definitions */ +#define SHOW_NOTHING 0x00 /* overrules everythi= ng */ +#define SHOW_ANYTHING 0xFF +#define SHOW_ERROR_MESSAGES 0x01 +#define SHOW_TRAPS 0x02 +#define SHOW_FUNCTION_CALLS 0x04 +#define SHOW_TRACING 0x08 +#define SHOW_QUEUE_INDEXES 0x10 +#define SHOW_PIMFOR_FRAMES 0x20 +#define SHOW_BUFFER_CONTENTS 0x40 +#define VERBOSE 0x01 + +/* Default card definitions */ +#define CARD_DEFAULT_CHANNEL 6 +#define CARD_DEFAULT_MODE INL_MODE_CLIENT +#define CARD_DEFAULT_IW_MODE IW_MODE_INFRA +#define CARD_DEFAULT_BSSTYPE DOT11_BSSTYPE_INFRA +#define CARD_DEFAULT_CLIENT_SSID "" +#define CARD_DEFAULT_AP_SSID "default" +#define CARD_DEFAULT_KEY1 "default_key_1" +#define CARD_DEFAULT_KEY2 "default_key_2" +#define CARD_DEFAULT_KEY3 "default_key_3" +#define CARD_DEFAULT_KEY4 "default_key_4" +#define CARD_DEFAULT_WEP 0 +#define CARD_DEFAULT_FILTER 0 +#define CARD_DEFAULT_WDS 0 +#define CARD_DEFAULT_AUTHEN DOT11_AUTH_OS +#define CARD_DEFAULT_DOT1X 0 +#define CARD_DEFAULT_MLME_MODE DOT11_MLME_AUTO +#define CARD_DEFAULT_CONFORMANCE OID_INL_CONFORMANCE_NONE +#define CARD_DEFAULT_PROFILE DOT11_PROFILE_MIXED_G_WIFI +#define CARD_DEFAULT_MAXFRAMEBURST DOT11_MAXFRAMEBURST_MIXED_SAFE + +/* PIMFOR package definitions */ +#define PIMFOR_ETHERTYPE 0x8828 +#define PIMFOR_HEADER_SIZE 12 +#define PIMFOR_VERSION 1 +#define PIMFOR_OP_GET 0 +#define PIMFOR_OP_SET 1 +#define PIMFOR_OP_RESPONSE 2 +#define PIMFOR_OP_ERROR 3 +#define PIMFOR_OP_TRAP 4 +#define PIMFOR_OP_RESERVED 5 /* till 255 */ +#define PIMFOR_DEV_ID_MHLI_MIB 0 +#define PIMFOR_FLAG_APPLIC_ORIGIN 0x01 +#define PIMFOR_FLAG_LITTLE_ENDIAN 0x02 + +static inline void +add_le32p(u32 * le_number, u32 add) +{ + *le_number =3D cpu_to_le32(le32_to_cpup(le_number) + add); +} + +void display_buffer(char *, int); + +/* + * Type definition section + * + * the structure defines only the header allowing copyless + * frame handling + */ +typedef struct { + u8 version; + u8 operation; + u32 oid; + u8 device_id; + u8 flags; + u32 length; +} __attribute__ ((packed)) +pimfor_header_t; + +/* A received and interrupt-processed management frame, either for + * schedule_work(prism54_process_trap) or for priv->mgmt_received, + * processed by islpci_mgt_transaction(). */ +struct islpci_mgmtframe { + struct net_device *ndev; /* pointer to network device */ + pimfor_header_t *header; /* payload header, points into buf */ + void *data; /* payload ex header, points into buf */ + struct work_struct ws; /* argument for schedule_work() */ + char buf[0]; /* fragment buffer */ +}; + +int +islpci_mgt_receive(struct net_device *ndev); + +int +islpci_mgmt_rx_fill(struct net_device *ndev); + +void +islpci_mgt_cleanup_transmit(struct net_device *ndev); + +int +islpci_mgt_transaction(struct net_device *ndev, + int operation, unsigned long oid, + void *senddata, int sendlen, + struct islpci_mgmtframe **recvframe); + +static inline void +islpci_mgt_release(struct islpci_mgmtframe *frame) +{ + kfree(frame); +} + +#endif /* _ISLPCI_MGT_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/oid_mgt.c linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.4.26/drivers/net/wireless/prism54/oid_mgt.c 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.c 2004-07-15 = 00:30:04.000000000 +0000 @@ -0,0 +1,807 @@ +/* =20 + * Copyright (C) 2003,2004 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include "prismcompat.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" +#include "isl_oid.h" +#include "oid_mgt.h" +#include "isl_ioctl.h" + +/* to convert between channel and freq */ +const int frequency_list_bg[] =3D { 2412, 2417, 2422, 2427, 2432, 2437, 24= 42, + 2447, 2452, 2457, 2462, 2467, 2472, 2484 +}; + +int +channel_of_freq(int f) +{ + int c =3D 0; + + if ((f >=3D 2412) && (f <=3D 2484)) { + while ((c < 14) && (f !=3D frequency_list_bg[c])) + c++; + return (c >=3D 14) ? 0 : ++c; + } else if ((f >=3D (int) 5000) && (f <=3D (int) 6000)) { + return ( (f - 5000) / 5 ); + } else + return 0; +} + +#define OID_STRUCT(name,oid,s,t) [name] =3D {oid, 0, sizeof(s), t} +#define OID_STRUCT_C(name,oid,s,t) OID_STRUCT(name,oid,s,t | OID_FLAG_CACH= ED) +#define OID_U32(name,oid) OID_STRUCT(name,oid,u32,OID_TYPE_U32) +#define OID_U32_C(name,oid) OID_STRUCT_C(name,oid,u32,OID_TYPE_U32) +#define OID_STRUCT_MLME(name,oid) OID_STRUCT(name,oid,struct obj_mlme,OID_= TYPE_MLME) +#define OID_STRUCT_MLMEEX(name,oid) OID_STRUCT(name,oid,struct obj_mlmeex,= OID_TYPE_MLMEEX) + +#define OID_UNKNOWN(name,oid) OID_STRUCT(name,oid,0,0) + +struct oid_t isl_oid[] =3D { + OID_STRUCT(GEN_OID_MACADDRESS, 0x00000000, u8[6], OID_TYPE_ADDR), + OID_U32(GEN_OID_LINKSTATE, 0x00000001), + OID_UNKNOWN(GEN_OID_WATCHDOG, 0x00000002), + OID_UNKNOWN(GEN_OID_MIBOP, 0x00000003), + OID_UNKNOWN(GEN_OID_OPTIONS, 0x00000004), + OID_UNKNOWN(GEN_OID_LEDCONFIG, 0x00000005), + + /* 802.11 */ + OID_U32_C(DOT11_OID_BSSTYPE, 0x10000000), + OID_STRUCT_C(DOT11_OID_BSSID, 0x10000001, u8[6], OID_TYPE_RAW), + OID_STRUCT_C(DOT11_OID_SSID, 0x10000002, struct obj_ssid, + OID_TYPE_SSID), + OID_U32(DOT11_OID_STATE, 0x10000003), + OID_U32(DOT11_OID_AID, 0x10000004), + OID_STRUCT(DOT11_OID_COUNTRYSTRING, 0x10000005, u8[4], OID_TYPE_RAW), + OID_STRUCT_C(DOT11_OID_SSIDOVERRIDE, 0x10000006, struct obj_ssid, + OID_TYPE_SSID), + + OID_U32(DOT11_OID_MEDIUMLIMIT, 0x11000000), + OID_U32_C(DOT11_OID_BEACONPERIOD, 0x11000001), + OID_U32(DOT11_OID_DTIMPERIOD, 0x11000002), + OID_U32(DOT11_OID_ATIMWINDOW, 0x11000003), + OID_U32(DOT11_OID_LISTENINTERVAL, 0x11000004), + OID_U32(DOT11_OID_CFPPERIOD, 0x11000005), + OID_U32(DOT11_OID_CFPDURATION, 0x11000006), + + OID_U32_C(DOT11_OID_AUTHENABLE, 0x12000000), + OID_U32_C(DOT11_OID_PRIVACYINVOKED, 0x12000001), + OID_U32_C(DOT11_OID_EXUNENCRYPTED, 0x12000002), + OID_U32_C(DOT11_OID_DEFKEYID, 0x12000003), + [DOT11_OID_DEFKEYX] =3D {0x12000004, 3, sizeof (struct obj_key), + OID_FLAG_CACHED | OID_TYPE_KEY}, /* DOT11_OID_DEFKEY1,...DOT11_O= ID_DEFKEY4 */ + OID_UNKNOWN(DOT11_OID_STAKEY, 0x12000008), + OID_U32(DOT11_OID_REKEYTHRESHOLD, 0x12000009), + OID_UNKNOWN(DOT11_OID_STASC, 0x1200000a), + + OID_U32(DOT11_OID_PRIVTXREJECTED, 0x1a000000), + OID_U32(DOT11_OID_PRIVRXPLAIN, 0x1a000001), + OID_U32(DOT11_OID_PRIVRXFAILED, 0x1a000002), + OID_U32(DOT11_OID_PRIVRXNOKEY, 0x1a000003), + + OID_U32_C(DOT11_OID_RTSTHRESH, 0x13000000), + OID_U32_C(DOT11_OID_FRAGTHRESH, 0x13000001), + OID_U32_C(DOT11_OID_SHORTRETRIES, 0x13000002), + OID_U32_C(DOT11_OID_LONGRETRIES, 0x13000003), + OID_U32_C(DOT11_OID_MAXTXLIFETIME, 0x13000004), + OID_U32(DOT11_OID_MAXRXLIFETIME, 0x13000005), + OID_U32(DOT11_OID_AUTHRESPTIMEOUT, 0x13000006), + OID_U32(DOT11_OID_ASSOCRESPTIMEOUT, 0x13000007), + + OID_UNKNOWN(DOT11_OID_ALOFT_TABLE, 0x1d000000), + OID_UNKNOWN(DOT11_OID_ALOFT_CTRL_TABLE, 0x1d000001), + OID_UNKNOWN(DOT11_OID_ALOFT_RETREAT, 0x1d000002), + OID_UNKNOWN(DOT11_OID_ALOFT_PROGRESS, 0x1d000003), + OID_U32(DOT11_OID_ALOFT_FIXEDRATE, 0x1d000004), + OID_UNKNOWN(DOT11_OID_ALOFT_RSSIGRAPH, 0x1d000005), + OID_UNKNOWN(DOT11_OID_ALOFT_CONFIG, 0x1d000006), + + [DOT11_OID_VDCFX] =3D {0x1b000000, 7, 0, 0}, + OID_U32(DOT11_OID_MAXFRAMEBURST, 0x1b000008), + + OID_U32(DOT11_OID_PSM, 0x14000000), + OID_U32(DOT11_OID_CAMTIMEOUT, 0x14000001), + OID_U32(DOT11_OID_RECEIVEDTIMS, 0x14000002), + OID_U32(DOT11_OID_ROAMPREFERENCE, 0x14000003), + + OID_U32(DOT11_OID_BRIDGELOCAL, 0x15000000), + OID_U32(DOT11_OID_CLIENTS, 0x15000001), + OID_U32(DOT11_OID_CLIENTSASSOCIATED, 0x15000002), + [DOT11_OID_CLIENTX] =3D {0x15000003, 2006, 0, 0}, /* DOT11_OID_CLIENTX,..= .DOT11_OID_CLIENT2007 */ + + OID_STRUCT(DOT11_OID_CLIENTFIND, 0x150007DB, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_WDSLINKADD, 0x150007DC, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_WDSLINKREMOVE, 0x150007DD, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_EAPAUTHSTA, 0x150007DE, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_EAPUNAUTHSTA, 0x150007DF, u8[6], OID_TYPE_ADDR), + OID_U32_C(DOT11_OID_DOT1XENABLE, 0x150007E0), + OID_UNKNOWN(DOT11_OID_MICFAILURE, 0x150007E1), + OID_UNKNOWN(DOT11_OID_REKEYINDICATE, 0x150007E2), + + OID_U32(DOT11_OID_MPDUTXSUCCESSFUL, 0x16000000), + OID_U32(DOT11_OID_MPDUTXONERETRY, 0x16000001), + OID_U32(DOT11_OID_MPDUTXMULTIPLERETRIES, 0x16000002), + OID_U32(DOT11_OID_MPDUTXFAILED, 0x16000003), + OID_U32(DOT11_OID_MPDURXSUCCESSFUL, 0x16000004), + OID_U32(DOT11_OID_MPDURXDUPS, 0x16000005), + OID_U32(DOT11_OID_RTSSUCCESSFUL, 0x16000006), + OID_U32(DOT11_OID_RTSFAILED, 0x16000007), + OID_U32(DOT11_OID_ACKFAILED, 0x16000008), + OID_U32(DOT11_OID_FRAMERECEIVES, 0x16000009), + OID_U32(DOT11_OID_FRAMEERRORS, 0x1600000A), + OID_U32(DOT11_OID_FRAMEABORTS, 0x1600000B), + OID_U32(DOT11_OID_FRAMEABORTSPHY, 0x1600000C), + + OID_U32(DOT11_OID_SLOTTIME, 0x17000000), + OID_U32(DOT11_OID_CWMIN, 0x17000001), + OID_U32(DOT11_OID_CWMAX, 0x17000002), + OID_U32(DOT11_OID_ACKWINDOW, 0x17000003), + OID_U32(DOT11_OID_ANTENNARX, 0x17000004), + OID_U32(DOT11_OID_ANTENNATX, 0x17000005), + OID_U32(DOT11_OID_ANTENNADIVERSITY, 0x17000006), + OID_U32_C(DOT11_OID_CHANNEL, 0x17000007), + OID_U32_C(DOT11_OID_EDTHRESHOLD, 0x17000008), + OID_U32(DOT11_OID_PREAMBLESETTINGS, 0x17000009), + OID_STRUCT(DOT11_OID_RATES, 0x1700000A, u8[IWMAX_BITRATES + 1], + OID_TYPE_RAW), + OID_U32(DOT11_OID_CCAMODESUPPORTED, 0x1700000B), + OID_U32(DOT11_OID_CCAMODE, 0x1700000C), + OID_UNKNOWN(DOT11_OID_RSSIVECTOR, 0x1700000D), + OID_UNKNOWN(DOT11_OID_OUTPUTPOWERTABLE, 0x1700000E), + OID_U32(DOT11_OID_OUTPUTPOWER, 0x1700000F), + OID_STRUCT(DOT11_OID_SUPPORTEDRATES, 0x17000010, + u8[IWMAX_BITRATES + 1], OID_TYPE_RAW), + OID_U32_C(DOT11_OID_FREQUENCY, 0x17000011), + [DOT11_OID_SUPPORTEDFREQUENCIES] =3D + {0x17000012, 0, sizeof (struct obj_frequencies) + + sizeof (u16) * IWMAX_FREQ, OID_TYPE_FREQUENCIES}, + + OID_U32(DOT11_OID_NOISEFLOOR, 0x17000013), + OID_STRUCT(DOT11_OID_FREQUENCYACTIVITY, 0x17000014, u8[IWMAX_FREQ + 1], + OID_TYPE_RAW), + OID_UNKNOWN(DOT11_OID_IQCALIBRATIONTABLE, 0x17000015), + OID_U32(DOT11_OID_NONERPPROTECTION, 0x17000016), + OID_U32(DOT11_OID_SLOTSETTINGS, 0x17000017), + OID_U32(DOT11_OID_NONERPTIMEOUT, 0x17000018), + OID_U32(DOT11_OID_PROFILES, 0x17000019), + OID_STRUCT(DOT11_OID_EXTENDEDRATES, 0x17000020, + u8[IWMAX_BITRATES + 1], OID_TYPE_RAW), + + OID_STRUCT_MLME(DOT11_OID_DEAUTHENTICATE, 0x18000000), + OID_STRUCT_MLME(DOT11_OID_AUTHENTICATE, 0x18000001), + OID_STRUCT_MLME(DOT11_OID_DISASSOCIATE, 0x18000002), + OID_STRUCT_MLME(DOT11_OID_ASSOCIATE, 0x18000003), + OID_UNKNOWN(DOT11_OID_SCAN, 0x18000004), + OID_STRUCT_MLMEEX(DOT11_OID_BEACON, 0x18000005), + OID_STRUCT_MLMEEX(DOT11_OID_PROBE, 0x18000006), + OID_STRUCT_MLMEEX(DOT11_OID_DEAUTHENTICATEEX, 0x18000007), + OID_STRUCT_MLMEEX(DOT11_OID_AUTHENTICATEEX, 0x18000008), + OID_STRUCT_MLMEEX(DOT11_OID_DISASSOCIATEEX, 0x18000009), + OID_STRUCT_MLMEEX(DOT11_OID_ASSOCIATEEX, 0x1800000A), + OID_STRUCT_MLMEEX(DOT11_OID_REASSOCIATE, 0x1800000B), + OID_STRUCT_MLMEEX(DOT11_OID_REASSOCIATEEX, 0x1800000C), + + OID_U32(DOT11_OID_NONERPSTATUS, 0x1E000000), + + OID_U32(DOT11_OID_STATIMEOUT, 0x19000000), + OID_U32_C(DOT11_OID_MLMEAUTOLEVEL, 0x19000001), + OID_U32(DOT11_OID_BSSTIMEOUT, 0x19000002), + OID_UNKNOWN(DOT11_OID_ATTACHMENT, 0x19000003), + OID_STRUCT_C(DOT11_OID_PSMBUFFER, 0x19000004, struct obj_buffer, + OID_TYPE_BUFFER), + + OID_U32(DOT11_OID_BSSS, 0x1C000000), + [DOT11_OID_BSSX] =3D {0x1C000001, 63, sizeof (struct obj_bss), + OID_TYPE_BSS}, /*DOT11_OID_BSS1,...,DOT11_OID_BSS64 */ + OID_STRUCT(DOT11_OID_BSSFIND, 0x1C000042, struct obj_bss, OID_TYPE_BSS), + [DOT11_OID_BSSLIST] =3D {0x1C000043, 0, sizeof (struct + obj_bsslist) + + sizeof (struct obj_bss[IWMAX_BSS]), + OID_TYPE_BSSLIST}, + + OID_UNKNOWN(OID_INL_TUNNEL, 0xFF020000), + OID_UNKNOWN(OID_INL_MEMADDR, 0xFF020001), + OID_UNKNOWN(OID_INL_MEMORY, 0xFF020002), + OID_U32_C(OID_INL_MODE, 0xFF020003), + OID_UNKNOWN(OID_INL_COMPONENT_NR, 0xFF020004), + OID_UNKNOWN(OID_INL_VERSION, 0xFF020005), + OID_UNKNOWN(OID_INL_INTERFACE_ID, 0xFF020006), + OID_UNKNOWN(OID_INL_COMPONENT_ID, 0xFF020007), + OID_U32_C(OID_INL_CONFIG, 0xFF020008), + OID_U32_C(OID_INL_DOT11D_CONFORMANCE, 0xFF02000C), + OID_U32(OID_INL_PHYCAPABILITIES, 0xFF02000D), + OID_U32_C(OID_INL_OUTPUTPOWER, 0xFF02000F), + +}; + +int +mgt_init(islpci_private *priv) +{ + int i; + + priv->mib =3D kmalloc(OID_NUM_LAST * sizeof (void *), GFP_KERNEL); + if (!priv->mib) + return -ENOMEM; + + memset(priv->mib, 0, OID_NUM_LAST * sizeof (void *)); + + /* Alloc the cache */ + for (i =3D 0; i < OID_NUM_LAST; i++) { + if (isl_oid[i].flags & OID_FLAG_CACHED) { + priv->mib[i] =3D kmalloc(isl_oid[i].size * + (isl_oid[i].range + 1), + GFP_KERNEL); + if (!priv->mib[i]) + return -ENOMEM; + memset(priv->mib[i], 0, + isl_oid[i].size * (isl_oid[i].range + 1)); + } else + priv->mib[i] =3D NULL; + } + + init_rwsem(&priv->mib_sem); + prism54_mib_init(priv); + + return 0; +} + +void +mgt_clean(islpci_private *priv) +{ + int i; + + if (!priv->mib) + return; + for (i =3D 0; i < OID_NUM_LAST; i++) + if (priv->mib[i]) { + kfree(priv->mib[i]); + priv->mib[i] =3D NULL; + } + kfree(priv->mib); + priv->mib =3D NULL; +} + +void +mgt_le_to_cpu(int type, void *data) +{ + switch (type) { + case OID_TYPE_U32: + *(u32 *) data =3D le32_to_cpu(*(u32 *) data); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D data; + buff->size =3D le32_to_cpu(buff->size); + buff->addr =3D le32_to_cpu(buff->addr); + break; + } + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D data; + bss->age =3D le16_to_cpu(bss->age); + bss->channel =3D le16_to_cpu(bss->channel); + bss->capinfo =3D le16_to_cpu(bss->capinfo); + bss->rates =3D le16_to_cpu(bss->rates); + bss->basic_rates =3D le16_to_cpu(bss->basic_rates); + break; + } + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D data; + int i; + list->nr =3D le32_to_cpu(list->nr); + for (i =3D 0; i < list->nr; i++) + mgt_le_to_cpu(OID_TYPE_BSS, &list->bsslist[i]); + break; + } + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D data; + int i; + freq->nr =3D le16_to_cpu(freq->nr); + for (i =3D 0; i < freq->nr; i++) + freq->mhz[i] =3D le16_to_cpu(freq->mhz[i]); + break; + } + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D data; + mlme->id =3D le16_to_cpu(mlme->id); + mlme->state =3D le16_to_cpu(mlme->state); + mlme->code =3D le16_to_cpu(mlme->code); + break; + } + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D data; + mlme->id =3D le16_to_cpu(mlme->id); + mlme->state =3D le16_to_cpu(mlme->state); + mlme->code =3D le16_to_cpu(mlme->code); + mlme->size =3D le16_to_cpu(mlme->size); + break; + } + case OID_TYPE_SSID: + case OID_TYPE_KEY: + case OID_TYPE_ADDR: + case OID_TYPE_RAW: + break; + default: + BUG(); + } +} + +static void +mgt_cpu_to_le(int type, void *data) +{ + switch (type) { + case OID_TYPE_U32: + *(u32 *) data =3D cpu_to_le32(*(u32 *) data); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D data; + buff->size =3D cpu_to_le32(buff->size); + buff->addr =3D cpu_to_le32(buff->addr); + break; + } + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D data; + bss->age =3D cpu_to_le16(bss->age); + bss->channel =3D cpu_to_le16(bss->channel); + bss->capinfo =3D cpu_to_le16(bss->capinfo); + bss->rates =3D cpu_to_le16(bss->rates); + bss->basic_rates =3D cpu_to_le16(bss->basic_rates); + break; + } + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D data; + int i; + list->nr =3D cpu_to_le32(list->nr); + for (i =3D 0; i < list->nr; i++) + mgt_cpu_to_le(OID_TYPE_BSS, &list->bsslist[i]); + break; + } + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D data; + int i; + freq->nr =3D cpu_to_le16(freq->nr); + for (i =3D 0; i < freq->nr; i++) + freq->mhz[i] =3D cpu_to_le16(freq->mhz[i]); + break; + } + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D data; + mlme->id =3D cpu_to_le16(mlme->id); + mlme->state =3D cpu_to_le16(mlme->state); + mlme->code =3D cpu_to_le16(mlme->code); + break; + } + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D data; + mlme->id =3D cpu_to_le16(mlme->id); + mlme->state =3D cpu_to_le16(mlme->state); + mlme->code =3D cpu_to_le16(mlme->code); + mlme->size =3D cpu_to_le16(mlme->size); + break; + } + case OID_TYPE_SSID: + case OID_TYPE_KEY: + case OID_TYPE_ADDR: + case OID_TYPE_RAW: + break; + default: + BUG(); + } +} + +/* Note : data is modified during this function */ + +int +mgt_set_request(islpci_private *priv, enum oid_num_t n, int extra, void *d= ata) +{ + int ret =3D 0; + struct islpci_mgmtframe *response; + int response_op =3D PIMFOR_OP_ERROR; + int dlen; + void *cache, *_data =3D data; + u32 oid; + + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(extra > isl_oid[n].range); + + if (!priv->mib) + /* memory has been freed */ + return -1; + + dlen =3D isl_oid[n].size; + cache =3D priv->mib[n]; + cache +=3D (cache ? extra * dlen : 0); + oid =3D isl_oid[n].oid + extra; + + if (_data =3D=3D NULL) + /* we are requested to re-set a cached value */ + _data =3D cache; + else + mgt_cpu_to_le(isl_oid[n].flags & OID_FLAG_TYPE, _data); + /* If we are going to write to the cache, we don't want anyone to read + * it -> acquire write lock. + * Else we could acquire a read lock to be sure we don't bother the + * commit process (which takes a write lock). But I'm not sure if it's + * needed. + */ + if (cache) + down_write(&priv->mib_sem); + + if (islpci_get_state(priv) >=3D PRV_STATE_READY) { + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, oid, + _data, dlen, &response); + if (!ret) { + response_op =3D response->header->operation; + islpci_mgt_release(response); + } + if (ret || response_op =3D=3D PIMFOR_OP_ERROR) + ret =3D -EIO; + } else if (!cache) + ret =3D -EIO; + + if (cache) { + if (!ret && data) + memcpy(cache, _data, dlen); + up_write(&priv->mib_sem); + } + + /* re-set given data to what it was */ + if (data) + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, data); + + return ret; +} + +int +mgt_get_request(islpci_private *priv, enum oid_num_t n, int extra, void *d= ata, + union oid_res_t *res) +{ + + int ret =3D -EIO; + int reslen =3D 0; + struct islpci_mgmtframe *response =3D NULL; + + int dlen; + void *cache, *_res =3D NULL; + u32 oid; + + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(extra > isl_oid[n].range); + + if (!priv->mib) + /* memory has been freed */ + return -1; + + dlen =3D isl_oid[n].size; + cache =3D priv->mib[n]; + cache +=3D cache ? extra * dlen : 0; + oid =3D isl_oid[n].oid + extra; + reslen =3D dlen; + + if (cache) + down_read(&priv->mib_sem); + + if (islpci_get_state(priv) >=3D PRV_STATE_READY) { + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + oid, data, dlen, &response); + if (ret || !response || + response->header->operation =3D=3D PIMFOR_OP_ERROR) { + if (response) + islpci_mgt_release(response); + ret =3D -EIO; + } + if (!ret) { + _res =3D response->data; + reslen =3D response->header->length; + } + } else if (cache) { + _res =3D cache; + ret =3D 0; + } + if ((isl_oid[n].flags & OID_FLAG_TYPE) =3D=3D OID_TYPE_U32) + res->u =3D ret ? 0 : le32_to_cpu(*(u32 *) _res); + else { + res->ptr =3D kmalloc(reslen, GFP_KERNEL); + BUG_ON(res->ptr =3D=3D NULL); + if (ret) + memset(res->ptr, 0, reslen); + else { + memcpy(res->ptr, _res, reslen); + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, + res->ptr); + } + } + if (cache) + up_read(&priv->mib_sem); + + if (response && !ret) + islpci_mgt_release(response); + + if (reslen > isl_oid[n].size) + printk(KERN_DEBUG + "mgt_get_request(0x%x): received data length was bigger " + "than expected (%d > %d). Memory is probably corrupted...", + oid, reslen, isl_oid[n].size); + + return ret; +} + +/* lock outside */ +int +mgt_commit_list(islpci_private *priv, enum oid_num_t *l, int n) +{ + int i, ret =3D 0; + struct islpci_mgmtframe *response; + + for (i =3D 0; i < n; i++) { + struct oid_t *t =3D &(isl_oid[l[i]]); + void *data =3D priv->mib[l[i]]; + int j =3D 0; + u32 oid =3D t->oid; + BUG_ON(data =3D=3D NULL); + while (j <=3D t->range) { + response =3D NULL; + ret |=3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, + oid, data, t->size, + &response); + if (response) { + ret |=3D (response->header->operation =3D=3D + PIMFOR_OP_ERROR); + islpci_mgt_release(response); + } + j++; + oid++; + data +=3D t->size; + } + } + return ret; +} + +/* Lock outside */ + +void +mgt_set(islpci_private *priv, enum oid_num_t n, void *data) +{ + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(priv->mib[n] =3D=3D NULL); + + memcpy(priv->mib[n], data, isl_oid[n].size); + mgt_cpu_to_le(isl_oid[n].flags & OID_FLAG_TYPE, priv->mib[n]); +} + +void +mgt_get(islpci_private *priv, enum oid_num_t n, void *res) +{ + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(priv->mib[n] =3D=3D NULL); + BUG_ON(res =3D=3D NULL); + + memcpy(res, priv->mib[n], isl_oid[n].size); + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, res); +} + +/* Commits the cache. Lock outside. */ + +static enum oid_num_t commit_part1[] =3D { + OID_INL_CONFIG, + OID_INL_MODE, + DOT11_OID_BSSTYPE, + DOT11_OID_CHANNEL, + DOT11_OID_MLMEAUTOLEVEL +}; + +static enum oid_num_t commit_part2[] =3D { + DOT11_OID_SSID, + DOT11_OID_PSMBUFFER, + DOT11_OID_AUTHENABLE, + DOT11_OID_PRIVACYINVOKED, + DOT11_OID_EXUNENCRYPTED, + DOT11_OID_DEFKEYX, /* MULTIPLE */ + DOT11_OID_DEFKEYID, + DOT11_OID_DOT1XENABLE, + OID_INL_DOT11D_CONFORMANCE, + OID_INL_OUTPUTPOWER, +}; + +/* update the MAC addr. */ +static int +mgt_update_addr(islpci_private *priv) +{ + struct islpci_mgmtframe *res; + int ret; + + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + isl_oid[GEN_OID_MACADDRESS].oid, NULL, + isl_oid[GEN_OID_MACADDRESS].size, &res); + + if ((ret =3D=3D 0) && res && (res->header->operation !=3D PIMFOR_OP_ERROR= )) + memcpy(priv->ndev->dev_addr, res->data, 6); + else + ret =3D -EIO; + if (res) + islpci_mgt_release(res); + + return ret; +} + +void +mgt_commit(islpci_private *priv) +{ + int rvalue; + u32 u; + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return; + + rvalue =3D mgt_commit_list(priv, commit_part1, + sizeof (commit_part1) / + sizeof (commit_part1[0])); + + if (priv->iw_mode !=3D IW_MODE_MONITOR) + rvalue |=3D mgt_commit_list(priv, commit_part2, + sizeof (commit_part2) / + sizeof (commit_part2[0])); + + u =3D OID_INL_MODE; + rvalue |=3D mgt_commit_list(priv, &u, 1); + rvalue |=3D mgt_update_addr(priv); + + if (rvalue) { + /* some request have failed. The device might be in an + incoherent state. We should reset it ! */ + printk(KERN_DEBUG "%s: mgt_commit has failed. Restart the " + "device \n", priv->ndev->name); + } +} + +/* This will tell you if you are allowed to answer a mlme(ex) request .*/ + +int +mgt_mlme_answer(islpci_private *priv) +{ + u32 mlmeautolevel; + /* Acquire a read lock because if we are in a mode change, it's + * possible to answer true, while the card is leaving master to managed + * mode. Answering to a mlme in this situation could hang the card. + */ + down_read(&priv->mib_sem); + mlmeautolevel =3D + le32_to_cpu(*(u32 *) priv->mib[DOT11_OID_MLMEAUTOLEVEL]); + up_read(&priv->mib_sem); + + return ((priv->iw_mode =3D=3D IW_MODE_MASTER) && + (mlmeautolevel >=3D DOT11_MLME_INTERMEDIATE)); +} + +enum oid_num_t +mgt_oidtonum(u32 oid) +{ + int i; + + for (i =3D 0; i < OID_NUM_LAST; i++) + if (isl_oid[i].oid =3D=3D oid) + return i; + + printk(KERN_DEBUG "looking for an unknown oid 0x%x", oid); + + return OID_NUM_LAST; +} + +int +mgt_response_to_str(enum oid_num_t n, union oid_res_t *r, char *str) +{ + switch (isl_oid[n].flags & OID_FLAG_TYPE) { + case OID_TYPE_U32: + return snprintf(str, PRIV_STR_SIZE, "%u\n", r->u); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "size=3D%u\naddr=3D0x%X\n", buff->size, + buff->addr); + } + break; + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "age=3D%u\nchannel=3D%u\n" + "capinfo=3D0x%X\nrates=3D0x%X\n" + "basic_rates=3D0x%X\n", bss->age, + bss->channel, bss->capinfo, + bss->rates, bss->basic_rates); + } + break; + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D r->ptr; + int i, k; + k =3D snprintf(str, PRIV_STR_SIZE, "nr=3D%u\n", list->nr); + for (i =3D 0; i < list->nr; i++) + k +=3D snprintf(str + k, PRIV_STR_SIZE - k, + "bss[%u] : \nage=3D%u\nchannel=3D%u\n" + "capinfo=3D0x%X\nrates=3D0x%X\n" + "basic_rates=3D0x%X\n", + i, list->bsslist[i].age, + list->bsslist[i].channel, + list->bsslist[i].capinfo, + list->bsslist[i].rates, + list->bsslist[i].basic_rates); + return k; + } + break; + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D r->ptr; + int i, t; + printk("nr : %u\n", freq->nr); + t =3D snprintf(str, PRIV_STR_SIZE, "nr=3D%u\n", freq->nr); + for (i =3D 0; i < freq->nr; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "mhz[%u]=3D%u\n", i, freq->mhz[i]); + return t; + } + break; + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "id=3D0x%X\nstate=3D0x%X\ncode=3D0x%X\n", + mlme->id, mlme->state, mlme->code); + } + break; + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "id=3D0x%X\nstate=3D0x%X\n" + "code=3D0x%X\nsize=3D0x%X\n", mlme->id, + mlme->state, mlme->code, mlme->size); + } + break; + case OID_TYPE_SSID:{ + struct obj_ssid *ssid =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "length=3D%u\noctets=3D%.*s\n", + ssid->length, ssid->length, + ssid->octets); + } + break; + case OID_TYPE_KEY:{ + struct obj_key *key =3D r->ptr; + int t, i; + t =3D snprintf(str, PRIV_STR_SIZE, + "type=3D0x%X\nlength=3D0x%X\nkey=3D0x", + key->type, key->length); + for (i =3D 0; i < key->length; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "%02X:", key->key[i]); + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, "\n"); + return t; + } + break; + case OID_TYPE_RAW: + case OID_TYPE_ADDR:{ + unsigned char *buff =3D r->ptr; + int t, i; + t =3D snprintf(str, PRIV_STR_SIZE, "hex data=3D"); + for (i =3D 0; i < isl_oid[n].size; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "%02X:", buff[i]); + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, "\n"); + return t; + } + break; + default: + BUG(); + } + return 0; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/oid_mgt.h linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.h --- linux-2.4.26/drivers/net/wireless/prism54/oid_mgt.h 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.h 2004-07-15 = 00:30:04.000000000 +0000 @@ -0,0 +1,58 @@ +/* + * Copyright (C) 2003 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#if !defined(_OID_MGT_H) +#define _OID_MGT_H + +#include "isl_oid.h" +#include "islpci_dev.h" + +extern struct oid_t isl_oid[]; + +int mgt_init(islpci_private *); + +void mgt_clean(islpci_private *); + +/* I don't know where to put these 3 */ +extern const int frequency_list_bg[]; +extern const int frequency_list_a[]; +int channel_of_freq(int); + +void mgt_le_to_cpu(int, void *); + +int mgt_set_request(islpci_private *, enum oid_num_t, int, void *); + +int mgt_get_request(islpci_private *, enum oid_num_t, int, void *, + union oid_res_t *); + +int mgt_commit_list(islpci_private *, enum oid_num_t *, int); + +void mgt_set(islpci_private *, enum oid_num_t, void *); + +void mgt_get(islpci_private *, enum oid_num_t, void *); + +void mgt_commit(islpci_private *); + +int mgt_mlme_answer(islpci_private *); + +enum oid_num_t mgt_oidtonum(u32 oid); + +int mgt_response_to_str(enum oid_num_t, union oid_res_t *, char *); + +#endif /* !defined(_OID_MGT_H) */ +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/prismcompat.h linux-2.4.26-prism54/drivers/net/wireless/prism54/pris= mcompat.h --- linux-2.4.26/drivers/net/wireless/prism54/prismcompat.h 1970-01-01 00:0= 0:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/prismcompat.h 2004-07= -15 00:30:04.000000000 +0000 @@ -0,0 +1,46 @@ +/* =20 + * (C) 2004 Margit Schubert-While + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +/* =20 + * Compatibility header file to aid support of different kernel versions + */ + +#ifdef PRISM54_COMPAT24 +#include "prismcompat24.h" +#else /* PRISM54_COMPAT24 */ + +#ifndef _PRISM_COMPAT_H +#define _PRISM_COMPAT_H + +#include +#include +#include +#include +#include +#include + +#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) +#error Firmware Loading is not configured in the kernel ! +#endif + +#define prism54_synchronize_irq(irq) synchronize_irq(irq) + +#define PRISM_FW_PDEV &priv->pdev->dev + +#endif /* _PRISM_COMPAT_H */ +#endif /* PRISM54_COMPAT24 */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/prismcompat24.h linux-2.4.26-prism54/drivers/net/wireless/prism54/pr= ismcompat24.h --- linux-2.4.26/drivers/net/wireless/prism54/prismcompat24.h 1970-01-01 00= :00:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/prismcompat24.h 2004-= 07-15 00:30:04.000000000 +0000 @@ -0,0 +1,69 @@ +/* =20 + * (C) 2004 Margit Schubert-While + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +/* =20 + * Compatibility header file to aid support of different kernel versions + */ + +#ifndef _PRISM_COMPAT_H +#define _PRISM_COMPAT_H + +#include +#include +#include +#include +#include +#include + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,25) +#define module_param(x, y, z) MODULE_PARM(x, "i") +#else +#include +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,23) +#define free_netdev(x) kfree(x) +#define pci_name(x) x->slot_name +#define irqreturn_t void +#define IRQ_HANDLED +#define IRQ_NONE +#else +#include +#endif + +#define work_struct tq_struct +#define INIT_WORK INIT_TQUEUE +#define schedule_work schedule_task + +#define netdev_priv(x) x->priv + +#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) +#error Firmware Loading is not configured in the kernel ! +#endif + +#define prism54_synchronize_irq(irq) synchronize_irq() + +#define DEFINE_WAIT(y) DECLARE_WAITQUEUE(y, current) +#define prepare_to_wait(x, y, z) set_current_state(z); \ + add_wait_queue(x, y) +#define finish_wait(x, y) remove_wait_queue(x, y); \ + set_current_state(TASK_RUNNING) + +#define PRISM_FW_PDEV pci_name(priv->pdev) + +#endif /* _PRISM_COMPAT_H */ --sCNd3Ivk/oijKKf1-- --7vLGWvOrvbSM0Ba8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9dUcat1JN+IKUl4RAp8IAJ0d74lO50BWDKx+B6kJC1VuQVPduwCggPB1 +Cg3T8xvrgvkgy5yA0CjJJ0= =Tarc -----END PGP SIGNATURE----- --7vLGWvOrvbSM0Ba8-- From rusty@au1.ibm.com Wed Jul 14 22:58:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 22:58:45 -0700 (PDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.com [202.81.18.186]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F5wZ9b010906 for ; Wed, 14 Jul 2004 22:58:36 -0700 Received: from sd0112e0 (d23rh903.au.ibm.com [202.81.18.201]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id i6F5wqhY057392 for ; Thu, 15 Jul 2004 15:58:53 +1000 Received: from ozlabs.au.ibm.com (haven.au.ibm.com [9.190.164.82]) by sd0112e0 (8.12.10/NCO/VER6.6) with ESMTP id i6F5xMuZ107372 for ; Thu, 15 Jul 2004 15:59:23 +1000 Received: from bach (localhost [127.0.0.1]) by ozlabs.au.ibm.com (Postfix) with ESMTP id 734A217DD8 for ; Thu, 15 Jul 2004 15:58:12 +1000 (EST) Subject: Fragment ID wrap workaround (read-only, untested). From: "Rusty Russell (IBM)" To: netdev@oss.sgi.com Content-Type: text/plain Organization: IBM Message-Id: <1089871078.3571.56.camel@bach> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 15 Jul 2004 15:57:58 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 6945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@au1.ibm.com Precedence: bulk X-list: netdev Hi all, I spoke about this today, thought I'd send the code out. Useful only for reading, as it's entirely untested and some is tricky and needs careful thinking. Name: Fragment ID Wrap Workaround Status: Untested Signed-off-by: Rusty Russell (authored) There's at least one old IBM Bugzilla bug, in which fragement IDs wrapped, causing NFS data corruption on UDP stresstesting. Solution presented here is twofold: 1) Move the offset of the fragments every time the ID wraps (usually the packet doesn't fit exactly into the MTU, so we have some slack), and 2) Check overlapping fragments that the contents match: if not, drop the whole thing. Note that I also implemented skb_iter functions, so I could compare the fragment overlap efficiently: really should be a separate patch. DaveM points out (FIXME) that doing the double walk means we need to guarantee two kmaps for the networking code. Also applies to IPv6. Simpler implementation would just drop all fragments on any overlap as a "doesn't happen IRL" case (it needs someone to duplicate a packet, then send each one by a different MTU path). diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/include/linux/ip.h .4882-linux-2.6.7-bk20.updated/include/linux/ip.h --- .4882-linux-2.6.7-bk20/include/linux/ip.h 2004-07-08 15:10:10.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/include/linux/ip.h 2004-07-09 13:08:42.000000000 +1000 @@ -118,12 +118,12 @@ struct inet_opt { int tos; /* TOS */ unsigned cmsg_flags; struct ip_options *opt; + __u32 id; /* ID counter for DF pkts */ __u16 sport; /* Source port */ unsigned char hdrincl; /* Include headers ? */ __u8 mc_ttl; /* Multicasting TTL */ __u8 mc_loop; /* Loopback */ __u8 pmtudisc; - __u16 id; /* ID counter for DF pkts */ unsigned recverr : 1, freebind : 1; int mc_index; /* Multicast device index */ diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/include/linux/skbuff.h .4882-linux-2.6.7-bk20.updated/include/linux/skbuff.h --- .4882-linux-2.6.7-bk20/include/linux/skbuff.h 2004-07-08 15:10:11.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/include/linux/skbuff.h 2004-07-09 14:31:11.000000000 +1000 @@ -1108,6 +1108,23 @@ extern void skb_split(struct sk_b extern void skb_init(void); extern void skb_add_mtu(int mtu); +struct skb_iter +{ + /* Iteration functions set these */ + unsigned char *data; + unsigned int len; + + /* Private to iteration */ + unsigned int nextfrag; + struct sk_buff *fraglist; +}; + +/* Keep iterating until skb_iter_next returns false. */ +extern void skb_iter_first(const struct sk_buff *skb, struct skb_iter *i); +extern int skb_iter_next(const struct sk_buff *skb, struct skb_iter *i); +/* Call this if aborting loop before !skb_iter_next */ +extern void skb_iter_abort(const struct sk_buff *skb, struct skb_iter *i); + #ifdef CONFIG_NETFILTER static inline void nf_conntrack_put(struct nf_ct_info *nfct) { diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/net/core/skbuff.c .4882-linux-2.6.7-bk20.updated/net/core/skbuff.c --- .4882-linux-2.6.7-bk20/net/core/skbuff.c 2004-07-08 15:10:12.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/net/core/skbuff.c 2004-07-09 14:35:28.000000000 +1000 @@ -929,6 +929,70 @@ fault: return -EFAULT; } +/* Keep iterating until skb_iter_next returns false. */ +void skb_iter_first(const struct sk_buff *skb, struct skb_iter *i) +{ + i->len = skb_headlen(skb); + i->data = (unsigned char *)skb->data; + i->nextfrag = 0; + i->fraglist = NULL; +} + +int skb_iter_next(const struct sk_buff *skb, struct skb_iter *i) +{ + /* Unmap previous, if not head fragment. */ + if (i->nextfrag) + kunmap_skb_frag(i->data); + + if (i->fraglist) { + fraglist: + /* We're iterating through fraglist. */ + if (i->nextfrag < skb_shinfo(i->fraglist)->nr_frags) { + i->data = kmap_skb_frag(&skb_shinfo(i->fraglist) + ->frags[i->nextfrag]); + i->len = skb_shinfo(i->fraglist)->frags[i->nextfrag] + .size; + i->nextfrag++; + return 1; + } + /* Fragments with fragments? Too hard! */ + BUG_ON(skb_shinfo(i->fraglist)->frag_list); + i->fraglist = i->fraglist->next; + if (!i->fraglist) + goto end; + + i->len = skb_headlen(i->fraglist); + i->data = i->fraglist->data; + i->nextfrag = 0; + return 1; + } + + if (i->nextfrag < skb_shinfo(skb)->nr_frags) { + i->data = kmap_skb_frag(&skb_shinfo(skb)->frags[i->nextfrag]); + i->len = skb_shinfo(skb)->frags[i->nextfrag].size; + i->nextfrag++; + return 1; + } + + i->fraglist = skb_shinfo(skb)->frag_list; + if (i->fraglist) + goto fraglist; + +end: + /* Bug trap for callers */ + i->data = NULL; + return 0; +} + +void skb_iter_abort(const struct sk_buff *skb, struct skb_iter *i) +{ + /* Unmap previous, if not head fragment. */ + if (i->data && i->nextfrag) + kunmap_skb_frag(i->data); + /* Bug trap for callers */ + i->data = NULL; +} + /* Checksum skb data. */ unsigned int skb_checksum(const struct sk_buff *skb, int offset, diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/net/ipv4/ip_fragment.c .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_fragment.c --- .4882-linux-2.6.7-bk20/net/ipv4/ip_fragment.c 2004-06-17 08:49:53.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_fragment.c 2004-07-09 15:28:48.000000000 +1000 @@ -399,8 +399,81 @@ static inline struct ipq *ip_find(struct return ip_frag_create(hash, iph); } -/* Add new segment to existing queue. */ -static void ip_frag_queue(struct ipq *qp, struct sk_buff *skb) +static int skb_data_equal(const struct sk_buff *new, int startnew, + const struct sk_buff *old, int startold, + int len) +{ + struct skb_iter newi, oldi; + int ret = 1; + + /* Move to first chunk with this offset in both cases */ + skb_iter_first(new, &newi); + while (newi.len < startnew) { + startnew -= newi.len; + skb_iter_next(new, &newi); + } + + skb_iter_first(old, &oldi); + while (oldi.len < startold) { + startold -= oldi.len; + skb_iter_next(old, &oldi); + } + + while (len > 0) { + int cmplen = len; + + /* How much can we compare? */ + if (cmplen > oldi.len - startold) + cmplen = oldi.len - startold; + if (cmplen > newi.len - startnew) + cmplen = newi.len - startnew; + if (memcmp(oldi.data+startold, newi.data+startnew, cmplen)) { + ret = 0; + break; + } + startnew += cmplen; + startold += cmplen; + if (startold == oldi.len) { + skb_iter_next(old, &oldi); + startold = 0; + } + if (startnew == newi.len) { + skb_iter_next(new, &newi); + startnew = 0; + } + len -= cmplen; + } + + skb_iter_abort(new, &newi); + skb_iter_abort(old, &oldi); + return ret; +} + +static int frag_overlap_mismatch(const struct sk_buff *new, + int offset, + const struct sk_buff *old) +{ + int old_offset = FRAG_CB(old)->offset; + int startnew, startold, len; + + if (offset < old_offset) { + startnew = old_offset - offset; + startold = 0; + } else { + startnew = 0; + startold = offset - old_offset; + } + + len = min(old->len - startold, new->len - startnew); + if (len < 0) + return 0; + + return !skb_data_equal(new, startnew, old, startold, len); +} + +/* Add new segment to existing queue. Return false if whole queue + * must drop. */ +static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) { struct sk_buff *prev, *next; int flags, offset; @@ -471,6 +544,8 @@ static void ip_frag_queue(struct ipq *qp offset += i; if (end <= offset) goto err; + if (frag_overlap_mismatch(skb, offset, prev)) + goto mismatch; if (!pskb_pull(skb, i)) goto err; if (skb->ip_summed != CHECKSUM_UNNECESSARY) @@ -481,6 +556,9 @@ static void ip_frag_queue(struct ipq *qp while (next && FRAG_CB(next)->offset < end) { int i = end - FRAG_CB(next)->offset; /* overlap is 'i' bytes */ + if (frag_overlap_mismatch(skb, offset, next)) + goto mismatch; + if (i < next->len) { /* Eat head of the next overlapped fragment * and leave the loop. The next ones cannot overlap. @@ -532,10 +610,17 @@ static void ip_frag_queue(struct ipq *qp list_move_tail(&qp->lru_list, &ipq_lru_list); write_unlock(&ipfrag_lock); - return; + return 1; err: kfree_skb(skb); + return 1; + +mismatch: + /* Roughly equiv. to checksum incorrect. */ + ipq_kill(qp); + kfree_skb(skb); + return 0; } @@ -650,12 +735,13 @@ struct sk_buff *ip_defrag(struct sk_buff spin_lock(&qp->lock); - ip_frag_queue(qp, skb); - - if (qp->last_in == (FIRST_IN|LAST_IN) && - qp->meat == qp->len) - ret = ip_frag_reasm(qp, dev); - + if (!ip_frag_queue(qp, skb)) + ipq_kill(qp); + else { + if (qp->last_in == (FIRST_IN|LAST_IN) && + qp->meat == qp->len) + ret = ip_frag_reasm(qp, dev); + } spin_unlock(&qp->lock); ipq_put(qp); return ret; diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/net/ipv4/ip_output.c .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_output.c --- .4882-linux-2.6.7-bk20/net/ipv4/ip_output.c 2004-07-08 15:10:12.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_output.c 2004-07-10 09:44:49.000000000 +1000 @@ -582,20 +582,33 @@ slow_path: offset = (ntohs(iph->frag_off) & IP_OFFSET) << 3; not_last_frag = iph->frag_off & htons(IP_MF); + len = left; + /* IF: it doesn't fit, use 'mtu' - the data space left */ + if (len > mtu) + len = mtu; + + /* IF: we are not sending upto and including the packet end + then align the next start on an eight byte boundary */ + if (len < left) + len &= ~7; + + /* Try to shift initial fragment boundary if we can, to help + * other end detect ID wrap. */ + if (skb->sk) { + unsigned int slack; + struct inet_opt *inet = inet_sk(skb->sk); + + slack = (left % mtu); + if (slack) + /* Shift by 8 bytes per id wrap. */ + len = mtu - (slack % ((inet->id >> 16) << 3)); + } + /* * Keep copying data until we run out. */ while(left > 0) { - len = left; - /* IF: it doesn't fit, use 'mtu' - the data space left */ - if (len > mtu) - len = mtu; - /* IF: we are not sending upto and including the packet end - then align the next start on an eight byte boundary */ - if (len < left) { - len &= ~7; - } /* * Allocate buffer. */ @@ -674,6 +687,16 @@ slow_path: err = output(skb2); if (err) goto fail; + + len = left; + /* IF: it doesn't fit, use 'mtu' - the data space left */ + if (len > mtu) + len = mtu; + /* IF: we are not sending upto and including the packet end + then align the next start on an eight byte boundary */ + if (len < left) { + len &= ~7; + } } kfree_skb(skb); IP_INC_STATS(FragOKs); From nakam@linux-ipv6.org Wed Jul 14 23:02:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 23:02:37 -0700 (PDT) Received: from localhost (galaxy.linux-ipv6.org [203.178.140.10]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F62T88011251 for ; Wed, 14 Jul 2004 23:02:30 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1BkzJv-0000YV-00; Thu, 15 Jul 2004 15:02:15 +0900 Date: Thu, 15 Jul 2004 15:02:14 +0900 From: Masahide NAKAMURA To: Stephen Hemminger Cc: Herbert Xu , netdev@oss.sgi.com, nakam@linux-ipv6.org Subject: [PATCH 1/3] iproute2 and xfrm Message-Id: <20040715150214.6067a457@localhost> In-Reply-To: <20040709125100.3edce4e9@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> <20040707110315.GA26100@gondor.apana.org.au> <20040709125100.3edce4e9@localhost> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Hello, This patch is minor fix for iproute2. It consists of two small ChangeSets. Regards, ChangeSet@1.55, 2004-07-12 19:58:53+09:00, nakam@linux-ipv6.org fix usage message for ipxfrm. diff -Nru a/ip/xfrm_policy.c b/ip/xfrm_policy.c --- a/ip/xfrm_policy.c 2004-07-14 16:35:49 +09:00 +++ b/ip/xfrm_policy.c 2004-07-14 16:35:49 +09:00 @@ -55,7 +55,6 @@ { fprintf(stderr, "Usage: ip xfrm policy { add | update } dir DIR sel SELECTOR [ index INDEX ] \n"); fprintf(stderr, " [ action ACTION ] [ priority PRIORITY ] [ LIMIT-LIST ] [ TMPL-LIST ]\n"); - fprintf(stderr, " [ sel SELECTOR | index INDEX ] [ TMPL-LIST ]\n"); fprintf(stderr, "Usage: ip xfrm policy { delete | get } dir DIR [ sel SELECTOR | index INDEX ]\n"); fprintf(stderr, "Usage: ip xfrm policy { flush | list } [ dir DIR ] [ sel SELECTOR ]\n"); fprintf(stderr, " [ index INDEX ] [ action ACTION ] [ priority PRIORITY ]\n"); @@ -75,7 +74,7 @@ fprintf(stderr, "LIMIT := [ [time-soft|time-hard|time-use-soft|time-use-hard] SECONDS ] |\n"); fprintf(stderr, " [ [byte-soft|byte-hard] SIZE ] | [ [packet-soft|packet-hard] NUMBER ]\n"); - fprintf(stderr, "TMPL-LIST := [ TMPL-LIST ] | [ tmpl TMPL ] | [ tmpl remain ](change only)\n"); + fprintf(stderr, "TMPL-LIST := [ TMPL-LIST ] | [ tmpl TMPL ]\n"); fprintf(stderr, "TMPL := ID [ mode MODE ] [ reqid REQID ] [ level LEVEL ]\n"); fprintf(stderr, "ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]\n"); ChangeSet@1.54, 2004-07-12 19:57:50+09:00, nakam@linux-ipv6.org fix command line option to understand "ip x p" and "ip x s". diff -Nru a/ip/ipxfrm.c b/ip/ipxfrm.c --- a/ip/ipxfrm.c 2004-07-14 16:35:49 +09:00 +++ b/ip/ipxfrm.c 2004-07-14 16:35:49 +09:00 @@ -793,13 +793,12 @@ if (argc < 1) usage(); - if (strcmp(*argv, "state") == 0 || - strcmp(*argv, "sa") == 0) { + if (matches(*argv, "state") == 0 || + matches(*argv, "sa") == 0) { return do_xfrm_state(argc-1, argv+1); - } else if (strcmp(*argv, "policy") == 0 || - strcmp(*argv, "pol") == 0) { + } else if (matches(*argv, "policy") == 0) return do_xfrm_policy(argc-1, argv+1); - } else if (strcmp(*argv, "help") == 0) { + else if (matches(*argv, "help") == 0) { usage(); fprintf(stderr, "xfrm Object \"%s\" is unknown.\n", *argv); exit(-1); -- Masahide NAKAMURA From nakam@linux-ipv6.org Wed Jul 14 23:02:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 23:02:40 -0700 (PDT) Received: from localhost (galaxy.linux-ipv6.org [203.178.140.10]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F62YKp011258 for ; Wed, 14 Jul 2004 23:02:34 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1BkzK2-0000Yb-00; Thu, 15 Jul 2004 15:02:22 +0900 Date: Thu, 15 Jul 2004 15:02:21 +0900 From: Masahide NAKAMURA To: Stephen Hemminger Cc: Herbert Xu , netdev@oss.sgi.com, nakam@linux-ipv6.org Subject: [PATCH 3/3] iproute2 and xfrm Message-Id: <20040715150221.537fee7d@localhost> In-Reply-To: <20040714174637.0ce79ae1@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> <20040707110315.GA26100@gondor.apana.org.au> <20040709125100.3edce4e9@localhost> <20040714174637.0ce79ae1@localhost> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev This patch is for iproute2 and fixes minor output format. Regards, ChangeSet@1.57, 2004-07-12 20:01:23+09:00, nakam@linux-ipv6.org fix message for protocol. diff -Nru a/ip/ipxfrm.c b/ip/ipxfrm.c --- a/ip/ipxfrm.c 2004-07-14 16:35:49 +09:00 +++ b/ip/ipxfrm.c 2004-07-14 16:35:49 +09:00 @@ -91,6 +91,23 @@ return str; } +const char *strxf_proto(__u8 proto) +{ + static char buf[32]; + struct protoent *pp; + const char *p; + + pp = getprotobynumber(proto); + if (pp) + p = pp->p_name; + else { + sprintf(buf, "%d", proto); + p = buf; + } + + return p; +} + void xfrm_id_info_print(xfrm_address_t *saddr, struct xfrm_id *id, __u8 mode, __u32 reqid, __u16 family, FILE *fp, const char *prefix) diff -Nru a/ip/xfrm.h b/ip/xfrm.h --- a/ip/xfrm.h 2004-07-14 16:35:49 +09:00 +++ b/ip/xfrm.h 2004-07-14 16:35:49 +09:00 @@ -80,6 +80,7 @@ const char *strxf_flags(__u8 flags); const char *strxf_share(__u8 share); +const char *strxf_proto(__u8 proto); void xfrm_id_info_print(xfrm_address_t *saddr, struct xfrm_id *id, __u8 mode, __u32 reqid, __u16 family, FILE *fp, const char *prefix); diff -Nru a/ip/xfrm_policy.c b/ip/xfrm_policy.c --- a/ip/xfrm_policy.c 2004-07-14 16:35:49 +09:00 +++ b/ip/xfrm_policy.c 2004-07-14 16:35:49 +09:00 @@ -78,7 +78,12 @@ fprintf(stderr, "TMPL := ID [ mode MODE ] [ reqid REQID ] [ level LEVEL ]\n"); fprintf(stderr, "ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]\n"); - fprintf(stderr, "XFRM_PROTO := [ esp | ah | ipcomp ]\n"); + //fprintf(stderr, "XFRM_PROTO := [ esp | ah | ipcomp ]\n"); + fprintf(stderr, "XFRM_PROTO := [ "); + fprintf(stderr, "%s | ", strxf_proto(IPPROTO_ESP)); + fprintf(stderr, "%s | ", strxf_proto(IPPROTO_AH)); + fprintf(stderr, "%s", strxf_proto(IPPROTO_COMP)); + fprintf(stderr, " ]\n"); fprintf(stderr, "MODE := [ transport | tunnel ](default=transport)\n"); //fprintf(stderr, "REQID - number(default=0)\n"); diff -Nru a/ip/xfrm_state.c b/ip/xfrm_state.c --- a/ip/xfrm_state.c 2004-07-14 16:35:49 +09:00 +++ b/ip/xfrm_state.c 2004-07-14 16:35:49 +09:00 @@ -63,7 +63,13 @@ fprintf(stderr, " [ FLAG_LIST ]\n"); fprintf(stderr, "ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]\n"); - fprintf(stderr, "XFRM_PROTO := [ esp | ah | ipcomp ]\n"); + //fprintf(stderr, "XFRM_PROTO := [ esp | ah | ipcomp ]\n"); + fprintf(stderr, "XFRM_PROTO := [ "); + fprintf(stderr, "%s | ", strxf_proto(IPPROTO_ESP)); + fprintf(stderr, "%s | ", strxf_proto(IPPROTO_AH)); + fprintf(stderr, "%s", strxf_proto(IPPROTO_COMP)); + fprintf(stderr, " ]\n"); + //fprintf(stderr, "SPI - security parameter index(default=0)\n"); fprintf(stderr, "MODE := [ transport | tunnel ](default=transport)\n"); -- Masahide NAKAMURA From nakam@linux-ipv6.org Wed Jul 14 23:08:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 23:08:10 -0700 (PDT) Received: from localhost (galaxy.linux-ipv6.org [203.178.140.10]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F68273011988 for ; Wed, 14 Jul 2004 23:08:03 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1BkzJz-0000YY-00; Thu, 15 Jul 2004 15:02:19 +0900 Date: Thu, 15 Jul 2004 15:02:19 +0900 From: Masahide NAKAMURA To: Stephen Hemminger Cc: Herbert Xu , netdev@oss.sgi.com, nakam@linux-ipv6.org Subject: [PATCH 2/3] iproute2 and xfrm Message-Id: <20040715150219.24a498a6@localhost> In-Reply-To: <20040714174233.2fc7dbc2@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> <20040707110315.GA26100@gondor.apana.org.au> <20040709125100.3edce4e9@localhost> <20040714174233.2fc7dbc2@localhost> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Hello, This patch is for iproute2. Please check comment in a ChangeSet below. Regards, ChangeSet@1.56, 2004-07-12 20:00:04+09:00, nakam@linux-ipv6.org fix output format to follow command line option style when using without "-s" option. diff -Nru a/ip/ipxfrm.c b/ip/ipxfrm.c --- a/ip/ipxfrm.c 2004-07-14 16:35:49 +09:00 +++ b/ip/ipxfrm.c 2004-07-14 16:35:49 +09:00 @@ -105,11 +105,11 @@ fprintf(fp, prefix); memset(abuf, '\0', sizeof(abuf)); - fprintf(fp, "%s ", rt_addr_n2a(family, sizeof(*saddr), - saddr, abuf, sizeof(abuf))); + fprintf(fp, "src %s ", rt_addr_n2a(family, sizeof(*saddr), + saddr, abuf, sizeof(abuf))); memset(abuf, '\0', sizeof(abuf)); - fprintf(fp, "%s\n", rt_addr_n2a(family, sizeof(id->daddr), - &id->daddr, abuf, sizeof(abuf))); + fprintf(fp, "dst %s\n", rt_addr_n2a(family, sizeof(id->daddr), + &id->daddr, abuf, sizeof(abuf))); if (prefix) fprintf(fp, prefix); @@ -122,30 +122,20 @@ sprintf(pbuf, "%d", id->proto); p = pbuf; } + fprintf(fp, "proto %s ", p); - switch (id->proto) { - case IPPROTO_ESP: - case IPPROTO_AH: - case IPPROTO_COMP: - fprintf(fp, "%s ", p); - break; - default: - fprintf(fp, "unspec(%s)", p); - break; - } - - switch (id->proto) { - case IPPROTO_ESP: - case IPPROTO_AH: - case IPPROTO_COMP: - default: - spi = ntohl(id->spi); - fprintf(fp, "spi %d(0x%08x) ", spi, spi); - break; - } + spi = ntohl(id->spi); + fprintf(fp, "spi %u", spi); + if (show_stats > 0) + fprintf(fp, "(0x%08x)", spi); + fprintf(fp, " "); + + fprintf(fp, "reqid %u", reqid); + if (show_stats > 0) + fprintf(fp, "(0x%08x)", reqid); + fprintf(fp, " "); - fprintf(fp, "reqid %d ", reqid); - fprintf(fp, "%s\n", (mode ? "tunnel" : "transport")); + fprintf(fp, "mode %s\n", (mode ? "tunnel" : "transport")); } static const char *strxf_limit(__u64 limit) @@ -279,16 +269,14 @@ fprintf(fp, prefix); memset(abuf, '\0', sizeof(abuf)); - fprintf(fp, "%s/%d[%u]", rt_addr_n2a(f, sizeof(sel->saddr), - &sel->saddr, - abuf, sizeof(abuf)), - sel->prefixlen_s, sel->sport); + fprintf(fp, "src %s/%d ", rt_addr_n2a(f, sizeof(sel->saddr), + &sel->saddr, abuf, sizeof(abuf)), + sel->prefixlen_s); memset(abuf, '\0', sizeof(abuf)); - fprintf(fp, " %s/%d[%u]", rt_addr_n2a(f, sizeof(sel->daddr), - &sel->daddr, - abuf, sizeof(abuf)), - sel->prefixlen_d, sel->dport); + fprintf(fp, "dst %s/%d", rt_addr_n2a(f, sizeof(sel->daddr), + &sel->daddr, abuf, sizeof(abuf)), + sel->prefixlen_d); fprintf(fp, "\n"); @@ -296,7 +284,8 @@ fprintf(fp, prefix); fprintf(fp, "\t"); - fprintf(fp, "upspec %u ", sel->proto); + fprintf(fp, "upspec proto %u ", sel->proto); + fprintf(fp, "sport %u dport %u ", sel->sport, sel->dport); if (sel->ifindex > 0) { char buf[IF_NAMESIZE]; @@ -304,10 +293,10 @@ memset(buf, '\0', sizeof(buf)); if_indextoname(sel->ifindex, buf); fprintf(fp, "dev %s ", buf); - } else - fprintf(fp, "dev (none) "); + } - fprintf(fp, "uid %u", sel->user); + if (show_stats > 0) + fprintf(fp, "uid %u", sel->user); fprintf(fp, "\n"); } @@ -367,35 +356,41 @@ __u16 family, FILE *fp, const char *prefix) { char buf[32]; - const char *p = NULL; int i; - if (prefix) { - strcpy(buf, prefix); - strcat(buf, " "); - } else - strcpy(buf, " "); - p = buf; - for (i = 0; i < ntmpls; i++) { struct xfrm_user_tmpl *tmpl = &tmpls[i]; if (prefix) fprintf(fp, prefix); - fprintf(fp, "tmpl-%d:\n", i+1); + + fprintf(fp, "tmpl"); xfrm_id_info_print(&tmpl->saddr, &tmpl->id, tmpl->mode, - tmpl->reqid, family, fp, p); + tmpl->reqid, family, fp, prefix); - fprintf(fp, p); + fprintf(fp, prefix); fprintf(fp, "\t"); - fprintf(fp, "level %s ", ((tmpl->optional == 0) ? "required" : - (tmpl->optional == 1) ? "use" : - "unknown-level")); - fprintf(fp, "share %s ", strxf_share(tmpl->share)); - fprintf(fp, "algo-mask:"); - fprintf(fp, "E=%s, ", strxf_mask(tmpl->ealgos)); - fprintf(fp, "A=%s, ", strxf_mask(tmpl->aalgos)); - fprintf(fp, "C=%s", strxf_mask(tmpl->calgos)); + fprintf(fp, "level "); + switch (tmpl->optional) { + case 0: + fprintf(fp, "required"); + break; + case 1: + fprintf(fp, "use"); + break; + default: + fprintf(fp, "%d", tmpl->optional); + break; + } + fprintf(fp, " "); + + if (show_stats > 0) { + fprintf(fp, "share %s ", strxf_share(tmpl->share)); + fprintf(fp, "algo-mask:"); + fprintf(fp, "E=%s, ", strxf_mask(tmpl->ealgos)); + fprintf(fp, "A=%s, ", strxf_mask(tmpl->aalgos)); + fprintf(fp, "C=%s", strxf_mask(tmpl->calgos)); + } fprintf(fp, "\n"); } } @@ -413,17 +408,17 @@ case XFRMA_ALG_CRYPT: if (prefix) fprintf(fp, prefix); - xfrm_algo_print((struct xfrm_algo *)data, fp, "E:"); + xfrm_algo_print((struct xfrm_algo *)data, fp, "algo E "); break; case XFRMA_ALG_AUTH: if (prefix) fprintf(fp, prefix); - xfrm_algo_print((struct xfrm_algo *)data, fp, "A:"); + xfrm_algo_print((struct xfrm_algo *)data, fp, "algo A "); break; case XFRMA_ALG_COMP: if (prefix) fprintf(fp, prefix); - xfrm_algo_print((struct xfrm_algo *)data, fp, "C:"); + xfrm_algo_print((struct xfrm_algo *)data, fp, "algo C "); break; case XFRMA_ENCAP: if (prefix) diff -Nru a/ip/xfrm_policy.c b/ip/xfrm_policy.c --- a/ip/xfrm_policy.c 2004-07-14 16:35:49 +09:00 +++ b/ip/xfrm_policy.c 2004-07-14 16:35:49 +09:00 @@ -357,20 +357,47 @@ if (n->nlmsg_type == XFRM_MSG_DELPOLICY) fprintf(fp, "Deleted "); + fprintf(fp, "sel "); xfrm_selector_print(&xpinfo->sel, preferred_family, fp, NULL); fprintf(fp, "\t"); - fprintf(fp, "%s ", (xpinfo->dir == XFRM_POLICY_IN ? "in " : - xpinfo->dir == XFRM_POLICY_OUT ? "out" : - xpinfo->dir == XFRM_POLICY_FWD ? "fwd" : - "unknown-dir")); - fprintf(fp, "%s ", (xpinfo->action == XFRM_POLICY_ALLOW ? "allow" : - xpinfo->action == XFRM_POLICY_BLOCK ? "block" : - "unknown-action")); + fprintf(fp, "dir "); + switch (xpinfo->dir) { + case XFRM_POLICY_IN: + fprintf(fp, "in"); + break; + case XFRM_POLICY_OUT: + fprintf(fp, "out"); + break; + case XFRM_POLICY_FWD: + fprintf(fp, "fwd"); + break; + default: + fprintf(fp, "%d", xpinfo->dir); + break; + } + fprintf(fp, " "); + + fprintf(fp, "action "); + switch (xpinfo->action) { + case XFRM_POLICY_ALLOW: + fprintf(fp, "allow"); + break; + case XFRM_POLICY_BLOCK: + fprintf(fp, "block"); + break; + default: + fprintf(fp, "%d", xpinfo->action); + break; + } + fprintf(fp, " "); + fprintf(fp, "index %u ", xpinfo->index); fprintf(fp, "priority %u ", xpinfo->priority); - fprintf(fp, "share %s ", strxf_share(xpinfo->share)); - fprintf(fp, "flags 0x%s", strxf_flags(xpinfo->flags)); + if (show_stats > 0) { + fprintf(fp, "share %s ", strxf_share(xpinfo->share)); + fprintf(fp, "flags 0x%s", strxf_flags(xpinfo->flags)); + } fprintf(fp, "\n"); if (show_stats > 0) diff -Nru a/ip/xfrm_state.c b/ip/xfrm_state.c --- a/ip/xfrm_state.c 2004-07-14 16:35:49 +09:00 +++ b/ip/xfrm_state.c 2004-07-14 16:35:49 +09:00 @@ -142,11 +142,20 @@ { int argc = *argcp; char **argv = *argvp; + int len = strlen(*argv); - if (strcmp(*argv, "noecn") == 0) - *flags |= XFRM_STATE_NOECN; - else - invarg("\"FLAG\" is invalid", *argv); + if (len > 2 && strncmp(*argv, "0x", 2) == 0) { + __u8 val = 0; + + if (get_u8(&val, *argv, 16)) + invarg("\"FLAG\" is invalid", *argv); + *flags = val; + } else { + if (strcmp(*argv, "noecn") == 0) + *flags |= XFRM_STATE_NOECN; + else + invarg("\"FLAG\" is invalid", *argv); + } filter.state_flags_mask = XFRM_FILTER_MASK_FULL; @@ -357,22 +366,26 @@ xfrm_id_info_print(&xsinfo->saddr, &xsinfo->id, xsinfo->mode, xsinfo->reqid, xsinfo->family, fp, NULL); + fprintf(fp, "\t"); if (show_stats > 0) { - fprintf(fp, "\t"); fprintf(fp, "seq 0x%08u ", xsinfo->seq); fprintf(fp, "replay-window %d ", xsinfo->replay_window); - fprintf(fp, "flags "); - if (xsinfo->flags & XFRM_STATE_NOECN) - fprintf(fp, "noecn "); - fprintf(fp, "(0x%s)", strxf_flags(xsinfo->flags)); - - fprintf(fp, "\n"); } + fprintf(fp, "flag 0x%s", strxf_flags(xsinfo->flags)); + if (show_stats > 0) { + if (xsinfo->flags) { + fprintf(fp, "("); + if (xsinfo->flags & XFRM_STATE_NOECN) + fprintf(fp, "noecn"); + fprintf(fp, ")"); + } + } + fprintf(fp, "\n"); xfrm_xfrma_print(tb, ntb, xsinfo->family, fp, "\t"); if (show_stats > 0) { - fprintf(fp, "\tsel:\n"); + fprintf(fp, "\tsel\n"); xfrm_selector_print(&xsinfo->sel, xsinfo->family, fp, "\t "); } -- Masahide NAKAMURA From rusty@au1.ibm.com Wed Jul 14 23:37:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jul 2004 23:37:32 -0700 (PDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.com [202.81.18.186]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F6bNFG017592 for ; Wed, 14 Jul 2004 23:37:24 -0700 Received: from sd0208e0 (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id i6F6bfhY171660 for ; Thu, 15 Jul 2004 16:37:41 +1000 Received: from sig-9-65-74-159.mts.ibm.com (sig-9-65-74-159.mts.ibm.com [9.65.74.159]) by sd0208e0 (8.12.10/NCO/VER6.6) with ESMTP id i6F6c8c1046490 for ; Thu, 15 Jul 2004 16:38:11 +1000 Subject: Fragment ID wrap workaround (read-only, untested). From: "Rusty Russell (IBM)" To: netdev@oss.sgi.com Content-Type: text/plain Organization: IBM Message-Id: <1089873416.6583.1.camel@bach> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 15 Jul 2004 16:36:56 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 6949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@au1.ibm.com Precedence: bulk X-list: netdev Hi all, I spoke about this today, thought I'd send the code out. Useful only for reading, as it's entirely untested and some is tricky and needs careful thinking. Name: Fragment ID Wrap Workaround Status: Untested Signed-off-by: Rusty Russell (authored) There's at least one old IBM Bugzilla bug, in which fragement IDs wrapped, causing NFS data corruption on UDP stresstesting. Solution presented here is twofold: 1) Move the offset of the fragments every time the ID wraps (usually the packet doesn't fit exactly into the MTU, so we have some slack), and 2) Check overlapping fragments that the contents match: if not, drop the whole thing. Note that I also implemented skb_iter functions, so I could compare the fragment overlap efficiently: really should be a separate patch. DaveM points out (FIXME) that doing the double walk means we need to guarantee two kmaps for the networking code. Also applies to IPv6. Simpler implementation would just drop all fragments on any overlap as a "doesn't happen IRL" case (it needs someone to duplicate a packet, then send each one by a different MTU path). diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/include/linux/ip.h .4882-linux-2.6.7-bk20.updated/include/linux/ip.h --- .4882-linux-2.6.7-bk20/include/linux/ip.h 2004-07-08 15:10:10.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/include/linux/ip.h 2004-07-09 13:08:42.000000000 +1000 @@ -118,12 +118,12 @@ struct inet_opt { int tos; /* TOS */ unsigned cmsg_flags; struct ip_options *opt; + __u32 id; /* ID counter for DF pkts */ __u16 sport; /* Source port */ unsigned char hdrincl; /* Include headers ? */ __u8 mc_ttl; /* Multicasting TTL */ __u8 mc_loop; /* Loopback */ __u8 pmtudisc; - __u16 id; /* ID counter for DF pkts */ unsigned recverr : 1, freebind : 1; int mc_index; /* Multicast device index */ diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/include/linux/skbuff.h .4882-linux-2.6.7-bk20.updated/include/linux/skbuff.h --- .4882-linux-2.6.7-bk20/include/linux/skbuff.h 2004-07-08 15:10:11.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/include/linux/skbuff.h 2004-07-09 14:31:11.000000000 +1000 @@ -1108,6 +1108,23 @@ extern void skb_split(struct sk_b extern void skb_init(void); extern void skb_add_mtu(int mtu); +struct skb_iter +{ + /* Iteration functions set these */ + unsigned char *data; + unsigned int len; + + /* Private to iteration */ + unsigned int nextfrag; + struct sk_buff *fraglist; +}; + +/* Keep iterating until skb_iter_next returns false. */ +extern void skb_iter_first(const struct sk_buff *skb, struct skb_iter *i); +extern int skb_iter_next(const struct sk_buff *skb, struct skb_iter *i); +/* Call this if aborting loop before !skb_iter_next */ +extern void skb_iter_abort(const struct sk_buff *skb, struct skb_iter *i); + #ifdef CONFIG_NETFILTER static inline void nf_conntrack_put(struct nf_ct_info *nfct) { diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/net/core/skbuff.c .4882-linux-2.6.7-bk20.updated/net/core/skbuff.c --- .4882-linux-2.6.7-bk20/net/core/skbuff.c 2004-07-08 15:10:12.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/net/core/skbuff.c 2004-07-09 14:35:28.000000000 +1000 @@ -929,6 +929,70 @@ fault: return -EFAULT; } +/* Keep iterating until skb_iter_next returns false. */ +void skb_iter_first(const struct sk_buff *skb, struct skb_iter *i) +{ + i->len = skb_headlen(skb); + i->data = (unsigned char *)skb->data; + i->nextfrag = 0; + i->fraglist = NULL; +} + +int skb_iter_next(const struct sk_buff *skb, struct skb_iter *i) +{ + /* Unmap previous, if not head fragment. */ + if (i->nextfrag) + kunmap_skb_frag(i->data); + + if (i->fraglist) { + fraglist: + /* We're iterating through fraglist. */ + if (i->nextfrag < skb_shinfo(i->fraglist)->nr_frags) { + i->data = kmap_skb_frag(&skb_shinfo(i->fraglist) + ->frags[i->nextfrag]); + i->len = skb_shinfo(i->fraglist)->frags[i->nextfrag] + .size; + i->nextfrag++; + return 1; + } + /* Fragments with fragments? Too hard! */ + BUG_ON(skb_shinfo(i->fraglist)->frag_list); + i->fraglist = i->fraglist->next; + if (!i->fraglist) + goto end; + + i->len = skb_headlen(i->fraglist); + i->data = i->fraglist->data; + i->nextfrag = 0; + return 1; + } + + if (i->nextfrag < skb_shinfo(skb)->nr_frags) { + i->data = kmap_skb_frag(&skb_shinfo(skb)->frags[i->nextfrag]); + i->len = skb_shinfo(skb)->frags[i->nextfrag].size; + i->nextfrag++; + return 1; + } + + i->fraglist = skb_shinfo(skb)->frag_list; + if (i->fraglist) + goto fraglist; + +end: + /* Bug trap for callers */ + i->data = NULL; + return 0; +} + +void skb_iter_abort(const struct sk_buff *skb, struct skb_iter *i) +{ + /* Unmap previous, if not head fragment. */ + if (i->data && i->nextfrag) + kunmap_skb_frag(i->data); + /* Bug trap for callers */ + i->data = NULL; +} + /* Checksum skb data. */ unsigned int skb_checksum(const struct sk_buff *skb, int offset, diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/net/ipv4/ip_fragment.c .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_fragment.c --- .4882-linux-2.6.7-bk20/net/ipv4/ip_fragment.c 2004-06-17 08:49:53.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_fragment.c 2004-07-09 15:28:48.000000000 +1000 @@ -399,8 +399,81 @@ static inline struct ipq *ip_find(struct return ip_frag_create(hash, iph); } -/* Add new segment to existing queue. */ -static void ip_frag_queue(struct ipq *qp, struct sk_buff *skb) +static int skb_data_equal(const struct sk_buff *new, int startnew, + const struct sk_buff *old, int startold, + int len) +{ + struct skb_iter newi, oldi; + int ret = 1; + + /* Move to first chunk with this offset in both cases */ + skb_iter_first(new, &newi); + while (newi.len < startnew) { + startnew -= newi.len; + skb_iter_next(new, &newi); + } + + skb_iter_first(old, &oldi); + while (oldi.len < startold) { + startold -= oldi.len; + skb_iter_next(old, &oldi); + } + + while (len > 0) { + int cmplen = len; + + /* How much can we compare? */ + if (cmplen > oldi.len - startold) + cmplen = oldi.len - startold; + if (cmplen > newi.len - startnew) + cmplen = newi.len - startnew; + if (memcmp(oldi.data+startold, newi.data+startnew, cmplen)) { + ret = 0; + break; + } + startnew += cmplen; + startold += cmplen; + if (startold == oldi.len) { + skb_iter_next(old, &oldi); + startold = 0; + } + if (startnew == newi.len) { + skb_iter_next(new, &newi); + startnew = 0; + } + len -= cmplen; + } + + skb_iter_abort(new, &newi); + skb_iter_abort(old, &oldi); + return ret; +} + +static int frag_overlap_mismatch(const struct sk_buff *new, + int offset, + const struct sk_buff *old) +{ + int old_offset = FRAG_CB(old)->offset; + int startnew, startold, len; + + if (offset < old_offset) { + startnew = old_offset - offset; + startold = 0; + } else { + startnew = 0; + startold = offset - old_offset; + } + + len = min(old->len - startold, new->len - startnew); + if (len < 0) + return 0; + + return !skb_data_equal(new, startnew, old, startold, len); +} + +/* Add new segment to existing queue. Return false if whole queue + * must drop. */ +static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) { struct sk_buff *prev, *next; int flags, offset; @@ -471,6 +544,8 @@ static void ip_frag_queue(struct ipq *qp offset += i; if (end <= offset) goto err; + if (frag_overlap_mismatch(skb, offset, prev)) + goto mismatch; if (!pskb_pull(skb, i)) goto err; if (skb->ip_summed != CHECKSUM_UNNECESSARY) @@ -481,6 +556,9 @@ static void ip_frag_queue(struct ipq *qp while (next && FRAG_CB(next)->offset < end) { int i = end - FRAG_CB(next)->offset; /* overlap is 'i' bytes */ + if (frag_overlap_mismatch(skb, offset, next)) + goto mismatch; + if (i < next->len) { /* Eat head of the next overlapped fragment * and leave the loop. The next ones cannot overlap. @@ -532,10 +610,17 @@ static void ip_frag_queue(struct ipq *qp list_move_tail(&qp->lru_list, &ipq_lru_list); write_unlock(&ipfrag_lock); - return; + return 1; err: kfree_skb(skb); + return 1; + +mismatch: + /* Roughly equiv. to checksum incorrect. */ + ipq_kill(qp); + kfree_skb(skb); + return 0; } @@ -650,12 +735,13 @@ struct sk_buff *ip_defrag(struct sk_buff spin_lock(&qp->lock); - ip_frag_queue(qp, skb); - - if (qp->last_in == (FIRST_IN|LAST_IN) && - qp->meat == qp->len) - ret = ip_frag_reasm(qp, dev); - + if (!ip_frag_queue(qp, skb)) + ipq_kill(qp); + else { + if (qp->last_in == (FIRST_IN|LAST_IN) && + qp->meat == qp->len) + ret = ip_frag_reasm(qp, dev); + } spin_unlock(&qp->lock); ipq_put(qp); return ret; diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .4882-linux-2.6.7-bk20/net/ipv4/ip_output.c .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_output.c --- .4882-linux-2.6.7-bk20/net/ipv4/ip_output.c 2004-07-08 15:10:12.000000000 +1000 +++ .4882-linux-2.6.7-bk20.updated/net/ipv4/ip_output.c 2004-07-10 09:44:49.000000000 +1000 @@ -582,20 +582,33 @@ slow_path: offset = (ntohs(iph->frag_off) & IP_OFFSET) << 3; not_last_frag = iph->frag_off & htons(IP_MF); + len = left; + /* IF: it doesn't fit, use 'mtu' - the data space left */ + if (len > mtu) + len = mtu; + + /* IF: we are not sending upto and including the packet end + then align the next start on an eight byte boundary */ + if (len < left) + len &= ~7; + + /* Try to shift initial fragment boundary if we can, to help + * other end detect ID wrap. */ + if (skb->sk) { + unsigned int slack; + struct inet_opt *inet = inet_sk(skb->sk); + + slack = (left % mtu); + if (slack) + /* Shift by 8 bytes per id wrap. */ + len = mtu - (slack % ((inet->id >> 16) << 3)); + } + /* * Keep copying data until we run out. */ while(left > 0) { - len = left; - /* IF: it doesn't fit, use 'mtu' - the data space left */ - if (len > mtu) - len = mtu; - /* IF: we are not sending upto and including the packet end - then align the next start on an eight byte boundary */ - if (len < left) { - len &= ~7; - } /* * Allocate buffer. */ @@ -674,6 +687,16 @@ slow_path: err = output(skb2); if (err) goto fail; + + len = left; + /* IF: it doesn't fit, use 'mtu' - the data space left */ + if (len > mtu) + len = mtu; + /* IF: we are not sending upto and including the packet end + then align the next start on an eight byte boundary */ + if (len < left) { + len &= ~7; + } } kfree_skb(skb); IP_INC_STATS(FragOKs); From dlstevens@us.ibm.com Thu Jul 15 01:28:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 01:28:29 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6F8SFT0024108 for ; Thu, 15 Jul 2004 01:28:21 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6F8S8tf356872 for ; Thu, 15 Jul 2004 04:28:08 -0400 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6F8S7jZ408668; Thu, 15 Jul 2004 02:28:08 -0600 In-Reply-To: <1089871078.3571.56.camel@bach> To: "Rusty Russell (IBM)" Cc: netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: Fragment ID wrap workaround (read-only, untested). X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 15 Jul 2004 02:28:05 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 07/15/2004 02:28:07, Serialize complete at 07/15/2004 02:28:07 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 6950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Rusty, Those ideas should work if both sides are Linux, but not when mixing with something else. A non-Linux receiver won't detect wrap and drop the packet, generally, even if the fragments overlap and don't match, and a non-Linux sender will send (typically) same-sized fragments that aren't offset. Doesn't hurt anything for those cases, so maybe in addition: My idea for solving this problem is to create an estimator for the reassembly timer. The fundamental problem as I see it is that the reassembly timer is fixed, and about 6000 times too long on a fast network (and worse the faster networks get). In the typical case, you'll receive lots of successfully reassembled packets from the same destination and, from those, you can build a good time estimate for how long it takes you to receive all the fragments, when you're going to. The reassembly timeout ought to be a little longer than that estimator, which might be a fraction of a millisecond on a local link, and maybe tens of seconds going across the Internet. Then you can time out and release the frags based on the expected behavior, rather than waiting so long the other side has time to wrap while you still have a valid frag queue. It also has the advantage that, on a faster link, a higher loss rate doesn't have you wasting memory holding fragments that aren't ever going to be reassembled successfully, anyway. The estimator could be very much like the TCP rtt estimator, and could go in the routing table (not so good for asymmetric paths), the fib, or its own little cache w/ timeout maintained by the reassembly code. There are some problems with this scheme, too, but I think it fixes most bad behavior on the receiver side with unmodified senders. Comments? +-DLS From ak@suse.de Thu Jul 15 03:05:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 03:05:46 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FA5MHE028819 for ; Thu, 15 Jul 2004 03:05:24 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 73D728D779B; Thu, 15 Jul 2004 11:27:26 +0200 (CEST) Date: Thu, 15 Jul 2004 11:27:17 +0200 From: Andi Kleen To: David Stevens Cc: "Rusty Russell (IBM)" , netdev@oss.sgi.com Subject: Re: Fragment ID wrap workaround (read-only, untested). Message-ID: <20040715092715.GA23131@wotan.suse.de> References: <1089871078.3571.56.camel@bach> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 6951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 02:28:05AM -0600, David Stevens wrote: > My idea for solving this problem is to create an estimator for the > reassembly timer. The fundamental problem as I see it is that the > reassembly timer is fixed, and about 6000 times too long on a > fast network (and worse the faster networks get). Won't that make the worst case behaviour on a congested link much worse? e.g. consider a very congested link with variable RTTs. Or a link that works relatively smoothly and suddenly the RTT increases. Yes, running fragmentation over those is not a good idea, but still it should not be made worse. Your variable timer even with a smoothing algorithm in the RTT estimator will expire far too early and very likely drop a lot more fragments in this scenario than before. In general handling a link where the RTT increases would seem tricky with your scheme. Unlike TCP there is no retransmit to save the day. -Andi From herbert@gondor.apana.org.au Thu Jul 15 04:49:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 04:49:14 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FBn2To002174 for ; Thu, 15 Jul 2004 04:49:04 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bl4jE-00044C-00; Thu, 15 Jul 2004 21:48:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bl4jA-0000MF-00; Thu, 15 Jul 2004 21:48:40 +1000 Date: Thu, 15 Jul 2004 21:48:40 +1000 To: "David S. Miller" Cc: James Morris , netdev@oss.sgi.com Subject: [CRYPTO] Fix stack overrun in crypt() Message-ID: <20040715114840.GA1325@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 6952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: The stack allocation in crypt() is bogus as whether tmp_src/tmp_dst is used is determined by factors unrelated to nbytes and src->length/dst->length. Since the condition for whether tmp_src/tmp_dst are used is very complex, let's allocate them always instead of guessing. This fixes a number of weird crashes including those AES crashes that people have been seeing with the 2.4 backport + ipt_conntrack. Signed-off-by: Herbert Xu PS I think someone should double-check the logic in the scatterwalk stuff, especially the whichbuf bits. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== crypto/cipher.c 1.18 vs edited ===== --- 1.18/crypto/cipher.c 2004-05-27 06:25:36 +10:00 +++ edited/crypto/cipher.c 2004-07-15 21:40:53 +10:00 @@ -52,8 +52,8 @@ { struct scatter_walk walk_in, walk_out; const unsigned int bsize = crypto_tfm_alg_blocksize(tfm); - u8 tmp_src[nbytes > src->length ? bsize : 0]; - u8 tmp_dst[nbytes > dst->length ? bsize : 0]; + u8 tmp_src[bsize]; + u8 tmp_dst[bsize]; if (!nbytes) return 0; --BOKacYhQ+x31HxR3-- From mtk-lists@gmx.net Thu Jul 15 05:51:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 05:51:49 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FCpghe003984 for ; Thu, 15 Jul 2004 05:51:43 -0700 Received: (qmail 3633 invoked by uid 0); 15 Jul 2004 12:51:35 -0000 Received: from 62.245.207.82 by www4.gmx.net with HTTP; Thu, 15 Jul 2004 14:51:35 +0200 (MEST) Date: Thu, 15 Jul 2004 14:51:35 +0200 (MEST) From: "Michael T Kerrisk" To: Alexey Toptygin Cc: netdev@oss.sgi.com MIME-Version: 1.0 References: Subject: Re: kernel-manpage inconsistency X-Priority: 3 (Normal) X-Authenticated: #18454895 Message-ID: <4407.1089895895@www4.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 6953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lists@gmx.net Precedence: bulk X-list: netdev Hello Alexey, > I don't know wether this is a kernel issue or a manpage issue, I just > know that they disagree. > > In recv(2) it says: > > MSG_TRUNC > Return the real length of the packet, even when it was longer > than the passed buffer. Only valid for packet sockets. > > But this is not honored. I don't know the details here, sorry. A quick glance at the source (raw_recvmsg() in net/ipv4/raw.c) shows that MSG_TRUNC is used there. > Also, in udp(7), it says: > > IOCTLS > These ioctls can be accessed using ioctl(2). The correct syntax is: > > int value; > error = ioctl(tcp_socket, ioctl_type, &value); > > SIOCINQ > Gets a pointer to an integer as argument. Returns the size of > the next pending datagram in the integer in bytes, or 0 when no > datagram is pending. > > SIOCOUTQ > Returns the number of data bytes in the local send queue. Only > supported with Linux 2.4 and above. > > These don't appear to be implemented. ( They're not in any headers and > they're not listed in ioctl_list(2). ) They're names in the kernel source. In userland, FIONREAD and TIOCOUTQ will do the trick for sockets. > Please tell me who I need to report this to to get it fixed. The latest Linux man pages can always be found at ftp://ftp.win.tue.nl/pub/linux-local/manpages/ and the maintainer is Andries Brouwer (Andries.Brouwer@cwi.nl) -- he'll take suitable new man pages, or patches in "diff -u" format. > Also, if there is a way to get the length of the next incoming datagram, > I would love to know about it. FIONREAD on a datagram socket will do this. > Currently I'm resorting to: > > while(1){ > recvmsg(..., MSG_PEEK); > if ( flags & MSG_TRUNC ){ > double buffer size; > } else { > break; > } > } Cheers, Michael -- Michael Kerrisk mtk-lists@gmx.net From johnpol@2ka.mipt.ru Thu Jul 15 06:30:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 06:30:47 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FDUW3v005147 for ; Thu, 15 Jul 2004 06:30:36 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6FDU59a027751; Thu, 15 Jul 2004 17:30:08 +0400 Subject: [0/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: netdev@oss.sgi.com Cc: netfilter-failover@lists.netfilter.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-O7aaoy7k985PjxHfVPSj" Organization: MIPT Message-Id: <1089898523.6114.865.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 15 Jul 2004 17:35:23 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6954 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-O7aaoy7k985PjxHfVPSj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, network developers. I'm glad to introduce CARP failover mechanism implementation. It is based on OpenBSD's CARP protocol but is not compatible with it since OpenBSD's implementation does not contain protection against repeated message sending. The main goal of the project is to implement CARP + firewall sync, but second part already implemented by Harald Welte and=20 KOVACS Krisztian in ct_sync. By design each node has it's own advertisement base and skew, node with the least timeval constructed from them became a master. It begins to advertise it's base and skew until shutdown or other node lower it's base+skew pair. CARP uses currently only IPv4 multicast, but can be easily changed to use IPv6.=20 Each CARP packet contains unique 64bit counter with it's SHA1 hmac digest with 20byte secret key. By design this counter is incremented in both master and backup before sending and while receiving accordingly. If master and backup counters do not coincide with each other while receiving backup node drops this packet and thus preventing repeated sending attack. When after predefined interval master didn't send any packet or it's base+skew is bigger than that in the remote node those node becomes a master and begins to advertise. CARP has 2 work queues for "became_master" and "became_backup" events. Such events may be easily registered in runtime by external modules. One of such event handlers may send netlink message to ct_sync and/or userspace daemon which will flush iptables rules, up/down interfaces and so on... Please review and comment. Code against 2.6 attached=20 in next 2 e-mails since netfilter-failover@lists.netfilter.org doesn't acce= pt e-mail greater than 40kb. Code also is available at http://www.2ka.mipt.ru/~johnpol/carp_latest.tar.gz --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-O7aaoy7k985PjxHfVPSj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9ogbIKTPhE+8wY0RAuX7AJ4674eNuTtvoUVdQqkU42vRhU23vwCdFE6G K9Sno/av6js48cchFHTUxuI= =3Oms -----END PGP SIGNATURE----- --=-O7aaoy7k985PjxHfVPSj-- From johnpol@2ka.mipt.ru Thu Jul 15 06:42:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 06:43:11 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FDgkCa005597 for ; Thu, 15 Jul 2004 06:42:52 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6FDVpfm027818; Thu, 15 Jul 2004 17:31:52 +0400 Subject: [2/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: netdev@oss.sgi.com Cc: netfilter-failover@lists.netfilter.org In-Reply-To: <1089898339.6114.860.camel@uganda> References: <1089898339.6114.860.camel@uganda> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8e7T7U6zlBuwtRlq0Usb" Organization: MIPT Message-Id: <1089898596.6114.867.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 15 Jul 2004 17:37:10 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-8e7T7U6zlBuwtRlq0Usb Content-Type: multipart/mixed; boundary="=-a+/kFhj9P+33ALSFH70e" --=-a+/kFhj9P+33ALSFH70e Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-15 at 17:32, Evgeniy Polyakov wrote: > Hello, network developers. >=20 > I'm glad to introduce CARP failover mechanism implementation. > It is based on OpenBSD's CARP protocol but is not compatible with it > since OpenBSD's implementation does not contain protection against > repeated message sending. >=20 > The main goal of the project is to implement CARP + firewall sync, but > second part already implemented by Harald Welte an= d=20 > KOVACS Krisztian in ct_sync. >=20 > By design each node has it's own advertisement base and skew, node with > the least timeval constructed from them became a master. > It begins to advertise it's base and skew until shutdown or other node > lower it's base+skew pair. > CARP uses currently only IPv4 multicast, but can be easily changed to > use IPv6.=20 > Each CARP packet contains unique 64bit counter with it's SHA1 hmac > digest with 20byte secret key. By design this counter is incremented in > both master and backup before sending and while receiving accordingly. > If master and backup counters do not coincide with each other while > receiving backup node drops this packet and thus preventing repeated > sending attack. > When after predefined interval master didn't send any packet or it's > base+skew is bigger than that in the remote node those node becomes a > master and begins to advertise. >=20 > CARP has 2 work queues for "became_master" and "became_backup" events. > Such events may be easily registered in runtime by external modules. > One of such event handlers may send netlink message to ct_sync and/or > userspace daemon which will flush iptables rules, up/down interfaces and > so on... >=20 > Please review and comment. >=20 > Code against 2.6 attached=20 > in next 2 e-mails since netfilter-failover@lists.netfilter.org doesn't ac= cept > e-mail greater than 40kb. >=20 > Code also is available at > http://www.2ka.mipt.ru/~johnpol/carp_latest.tar.gz --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-a+/kFhj9P+33ALSFH70e Content-Disposition: attachment; filename=carpctl.c Content-Type: text/x-csrc; name=carpctl.c; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwY3RsLmMNCiAqIA0KICogMjAwNCBDb3B5cmlnaHQgKGMpIEV2Z2VuaXkgUG9s eWFrb3YgPGpvaG5wb2xAMmthLm1pcHQucnU+DQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KICog DQogKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUg aXQgYW5kL29yIG1vZGlmeQ0KICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCiAqIHRoZSBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQogKiAoYXQgeW91 ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0 cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KICogYnV0IFdJVEhP VVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YNCiAq IE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNl ZSB0aGUNCiAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQog Kg0KICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwg UHVibGljIExpY2Vuc2UNCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRl IHRvIHRoZSBGcmVlIFNvZnR3YXJlDQogKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxh Y2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQogKg0KICovDQoNCiNp bmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRlIDxzeXMvaW9jdGwuaD4NCiNpbmNsdWRlIDxz eXMvc29ja2V0Lmg+DQoNCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHN0ZGludC5oPg0K I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPHVuaXN0 ZC5oPg0KI2luY2x1ZGUgPGVycm5vLmg+DQoNCiNpbmNsdWRlIDxsaW51eC9pZi5oPg0KDQojaW5j bHVkZSAiY2FycF9pb2N0bC5oIg0KDQojZGVmaW5lCUNBUlBfS0VZX0xFTgkJMjANCiNkZWZpbmUJ Q0FSUF9ITUFDX1BBRF9MRU4JNjQNCiNkZWZpbmUgSVBQUk9UT19DQVJQIAkJMTEyDQoNCnN0YXRp YyB2b2lkIHVzYWdlKGNvbnN0IGNoYXIgKnByKQ0Kew0KCWZwcmludGYoc3RkZXJyLCAiVXNhZ2U6 ICVzOiBbLWhdIFstaSBpcGhdIFstYiBhZHZiYXNlXSBbLXMgYWR2c2tld10gWy1kIGRldmljZV0g Wy12IHZoaWRdIFstayBrZXldIFstcCBwYWRdIFstUyBzdGF0ZV0gIg0KCQkJIlstbSBtZF90aW1l b3V0XSBbLWEgYWR2X3RpbW91dF0uXG4iLA0KCQkJcHIpOw0KfQ0KDQpzdGF0aWMgdm9pZCBjYXJw X2R1bXBfcGFyYW1zKHN0cnVjdCBjYXJwX2lvY3RsX3BhcmFtcyBwKQ0Kew0KCXByaW50ZigiQXR0 YWNoZWQgdG8gZGV2aWNlICVzLlxuIiwgcC5kZXZuYW1lKTsNCglwcmludGYoIkFEVjogYmFzZT0l ZCwgc2tldz0lZC5cbiIsIHAuY2FycF9hZHZiYXNlLCBwLmNhcnBfYWR2c2tldyk7DQoJcHJpbnRm KCJWSElEPSVkLCBTVEFURT0lZC5cbiIsIHAuY2FycF92aGlkLCBwLnN0YXRlKTsNCn0NCg0KaW50 IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCnsNCglpbnQgY2gsIGVyciwgcywgbmVlZF9j aGFuZ2U7DQoJc3RydWN0IGlmcmVxIGlmcjsNCgljaGFyIGRldm5hbWVbSUZOQU1TSVpdID0gImNh cnAwIjsNCglzdHJ1Y3QgY2FycF9pb2N0bF9wYXJhbXMgcDsNCg0KCW1lbXNldCgmcCwgMCwgc2l6 ZW9mKHApKTsNCgkNCgltZW1zZXQoJmlmciwgMCwgc2l6ZW9mKGlmcikpOw0KCXN0cm5jcHkoaWZy Lmlmcl9uYW1lLCBkZXZuYW1lLCBzaXplb2YoaWZyLmlmcl9uYW1lKSk7DQoJaWZyLmlmcl9pZnJ1 LmlmcnVfZGF0YSA9ICh2b2lkICopJnA7DQoNCglzID0gc29ja2V0KEFGX0lORVQsIFNPQ0tfREdS QU0sIDApOw0KCWlmIChzID09IC0xKQ0KCXsNCgkJZnByaW50ZihzdGRlcnIsICJGYWlsZWQgdG8g Y3JlYXRlIENBUlAgY29udHJvbCBzb2NrZXQ6IFslZF0gJXMuXG4iLA0KCQkJCWVycm5vLCBzdHJl cnJvcihlcnJubykpOw0KCQlyZXR1cm4gLTE7DQoJfQ0KCQ0KCWVyciA9IGlvY3RsKHMsIFNJT0Nf R0VUQ0FSUFBBUkFNUywgJmlmcik7DQoJaWYgKGVyciA9PSAtMSkNCgl7DQoJCWZwcmludGYoc3Rk ZXJyLCAiRmFpbGVkIHRvIGNhbGwgaW9jdGw6IFslZF0gJXMuXG4iLA0KCQkJCWVycm5vLCBzdHJl cnJvcihlcnJubykpOw0KCQljbG9zZShzKTsNCgkJcmV0dXJuIC0xOw0KCX0NCg0KCWNhcnBfZHVt cF9wYXJhbXMocCk7DQoNCgluZWVkX2NoYW5nZSA9IDA7DQoJd2hpbGUoKGNoID0gZ2V0b3B0KGFy Z2MsIGFyZ3YsICJoaTpiOnM6ZDp2Oms6cDpTOm06YToiKSkgIT0gLTEpDQoJew0KCQluZWVkX2No YW5nZSA9IDE7DQoJCXN3aXRjaCAoY2gpDQoJCXsNCgkJCWNhc2UgJ20nOg0KCQkJCXAubWRfdGlt ZW91dCA9IGF0b2kob3B0YXJnKTsNCgkJCQlicmVhazsNCgkJCWNhc2UgJ2EnOg0KCQkJCXAuYWR2 X3RpbWVvdXQgPSBhdG9pKG9wdGFyZyk7DQoJCQkJYnJlYWs7DQoJCQljYXNlICdiJzoNCgkJCQlw LmNhcnBfYWR2YmFzZSA9IGF0b2kob3B0YXJnKTsNCgkJCQlicmVhazsNCgkJCWNhc2UgJ3MnOg0K CQkJCXAuY2FycF9hZHZza2V3ID0gYXRvaShvcHRhcmcpOw0KCQkJCWJyZWFrOw0KCQkJY2FzZSAn ZCc6DQoJCQkJbWVtY3B5KHAuZGV2bmFtZSwgb3B0YXJnLCBzaXplb2YocC5kZXZuYW1lKSk7DQoJ CQkJcC5kZXZuYW1lW3NpemVvZihwLmRldm5hbWUpIC0gMV0gPSAnXDAnOw0KCQkJCWJyZWFrOw0K CQkJY2FzZSAndic6DQoJCQkJcC5jYXJwX3ZoaWQgPSBhdG9pKG9wdGFyZyk7DQoJCQkJYnJlYWs7 DQoJCQljYXNlICdrJzoNCgkJCQlpZiAoc3RybGVuKG9wdGFyZykgIT0gc2l6ZW9mKHAuY2FycF9r ZXkpKQ0KCQkJCXsNCgkJCQkJZnByaW50ZihzdGRlcnIsICJXcm9uZyBrZXkgbGVuZ3RoLiBNdXN0 IGJlICVkLlxuIiwgc2l6ZW9mKHAuY2FycF9rZXkpKTsNCgkJCQkJcmV0dXJuIC0xOw0KCQkJCX0N CgkJCQltZW1jcHkocC5jYXJwX2tleSwgb3B0YXJnLCBzaXplb2YocC5jYXJwX2tleSkpOw0KCQkJ CWJyZWFrOw0KCQkJY2FzZSAncCc6DQoJCQkJaWYgKHN0cmxlbihvcHRhcmcpICE9IHNpemVvZihw LmNhcnBfcGFkKSkNCgkJCQl7DQoJCQkJCWZwcmludGYoc3RkZXJyLCAiV3JvbmcgcGFkIGxlbmd0 aC4gTXVzdCBiZSAlZC5cbiIsIHNpemVvZihwLmNhcnBfcGFkKSk7DQoJCQkJCXJldHVybiAtMTsN CgkJCQl9DQoJCQkJbWVtY3B5KHAuY2FycF9wYWQsIG9wdGFyZywgc2l6ZW9mKHAuY2FycF9wYWQp KTsNCgkJCQlicmVhazsNCgkJCWNhc2UgJ1MnOg0KCQkJCXAuc3RhdGUgPSBhdG9pKG9wdGFyZyk7 DQoJCQkJYnJlYWs7DQoJCQljYXNlICdoJzoNCgkJCWRlZmF1bHQ6DQoJCQkJbmVlZF9jaGFuZ2Ug PSAwOw0KCQkJCXVzYWdlKGFyZ3ZbMF0pOw0KCQkJCXJldHVybiAtMTsNCgkJfQ0KCX0NCg0KCWlm ICghbmVlZF9jaGFuZ2UpDQoJew0KCQl1c2FnZShhcmd2WzBdKTsNCgkJcmV0dXJuIC0xOw0KCX0N CgkNCglpZnIuaWZyX2lmcnUuaWZydV9kYXRhID0gKHZvaWQgKikmcDsNCgkNCgllcnIgPSBpb2N0 bChzLCBTSU9DX1NFVENBUlBQQVJBTVMsICZpZnIpOw0KCWlmIChlcnIgPT0gLTEpDQoJew0KCQlm cHJpbnRmKHN0ZGVyciwgIkZhaWxlZCB0byBjYWxsIGlvY3RsOiBbJWRdICVzLlxuIiwNCgkJCQll cnJubywgc3RyZXJyb3IoZXJybm8pKTsNCgkJY2xvc2Uocyk7DQoJCXJldHVybiAtMTsNCgl9DQoN CgljbG9zZShzKTsNCg0KCXJldHVybiAwOw0KfQ0K --=-a+/kFhj9P+33ALSFH70e Content-Disposition: attachment; filename=carp_queue.c Content-Type: text/x-csrc; name=carp_queue.c; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwX3F1ZXVlLmMNCiAqIA0KICogMjAwNCBDb3B5cmlnaHQgKGMpIEV2Z2VuaXkg UG9seWFrb3YgPGpvaG5wb2xAMmthLm1pcHQucnU+DQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0K ICogDQogKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1 dGUgaXQgYW5kL29yIG1vZGlmeQ0KICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCiAqIHRoZSBGcmVlIFNvZnR3YXJl IEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQogKiAoYXQg eW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBk aXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KICogYnV0IFdJ VEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YN CiAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g IFNlZSB0aGUNCiAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMu DQogKg0KICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UNCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQogKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUg UGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQogKg0KICovDQoN CiNpbmNsdWRlIDxsaW51eC93b3JrcXVldWUuaD4NCiNpbmNsdWRlIDxhc20vc3BpbmxvY2suaD4N Cg0KI2luY2x1ZGUgImNhcnAuaCINCiNpbmNsdWRlICJjYXJwX2xvZy5oIg0KI2luY2x1ZGUgImNh cnBfcXVldWUuaCINCg0Kc3RhdGljIHNwaW5sb2NrX3QgY2FycF9xdWV1ZV9sb2NrID0gU1BJTl9M T0NLX1VOTE9DS0VEOw0Kc3RhdGljIHN0cnVjdCB3b3JrcXVldWVfc3RydWN0ICpjYXJwX3F1ZXVl WzJdOw0Kc3RhdGljIHN0cnVjdCBsaXN0X2hlYWQgY2FycF93b3Jrc1syXTsNCnN0YXRpYyBpbnQg Y2FycF93b3JrX2NvdW50ZXI7DQoNCnN0YXRpYyB2b2lkIGNhcnBfcXVldWVfd3JhcHBlcih2b2lk ICpkYXRhKQ0Kew0KCXN0cnVjdCBjYXJwX21hc3Rlcl90YXNrICp0ID0gKHN0cnVjdCBjYXJwX21h c3Rlcl90YXNrICopZGF0YTsNCg0KCWF0b21pY19pbmMoJnQtPnRhc2stPnJlZmNudCk7DQoJdC0+ dGFzay0+Y2FsbGJhY2sodC0+dGFzay0+ZGF0YSk7DQoJYXRvbWljX2RlYygmdC0+dGFzay0+cmVm Y250KTsNCn0NCg0Kc3RydWN0IGNhcnBfbWFzdGVyX3Rhc2sgKmNhcnBfYWxsb2NfdGFzayhzdHJ1 Y3QgX19jYXJwX21hc3Rlcl90YXNrICp0KQ0Kew0KCXN0cnVjdCBjYXJwX21hc3Rlcl90YXNrICpu ZXd0Ow0KDQoJbmV3dCA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBjYXJwX21hc3Rlcl90YXNrKSwg R0ZQX0tFUk5FTCk7DQoJaWYgKCFuZXd0KQ0KCXsNCgkJbG9nKCJGYWlsZWQgdG8gY3JlYXRlIG5l dyBDQVJQIG1hc3RlciB0YXNrLlxuIik7DQoJCXJldHVybiBOVUxMOw0KCX0NCg0KCW1lbXNldChu ZXd0LCAwLCBzaXplb2Yoc3RydWN0IGNhcnBfbWFzdGVyX3Rhc2spKTsNCgkNCglhdG9taWNfc2V0 KCZ0LT5yZWZjbnQsIDEpOw0KCW5ld3QtPnRhc2sgPSB0Ow0KCW5ld3QtPnRhc2stPmlkID0gY2Fy cF93b3JrX2NvdW50ZXIrKzsNCgkNCglJTklUX1dPUksoJm5ld3QtPndvcmssICZjYXJwX3F1ZXVl X3dyYXBwZXIsIG5ld3QpOw0KDQoJcmV0dXJuIG5ld3Q7DQp9DQoNCnN0YXRpYyB2b2lkIGNhcnBf ZnJlZV90YXNrKHN0cnVjdCBjYXJwX21hc3Rlcl90YXNrICp0KQ0Kew0KCWNhbmNlbF9kZWxheWVk X3dvcmsoJnQtPndvcmspOw0KDQoJd2hpbGUoYXRvbWljX3JlYWQoJnQtPnRhc2stPnJlZmNudCkp DQoJCXNjaGVkdWxlX3RpbWVvdXQoMTApOw0KCQ0KCWtmcmVlKHQpOw0KfQ0KDQppbnQgY2FycF9h ZGRfdGFzayhzdHJ1Y3QgX19jYXJwX21hc3Rlcl90YXNrICptdCwgaW50IG51bSkNCnsNCglzdHJ1 Y3QgY2FycF9tYXN0ZXJfdGFzayAqbmV3dDsNCg0KCWlmIChudW0gIT0gTUFTVEVSX1FVRVVFICYm IG51bSAhPSBCQUNLVVBfUVVFVUUpDQoJCXJldHVybiAtRUlOVkFMOw0KDQoJbmV3dCA9IGNhcnBf YWxsb2NfdGFzayhtdCk7DQoJaWYgKCFuZXd0KQ0KCQlyZXR1cm4gLUVOT01FTTsNCgkNCglzcGlu X2xvY2soJmNhcnBfcXVldWVfbG9jayk7DQoJbGlzdF9hZGRfdGFpbCgmbmV3dC0+ZW50cnksICZj YXJwX3dvcmtzW251bV0pOw0KCXNwaW5fdW5sb2NrKCZjYXJwX3F1ZXVlX2xvY2spOw0KDQoJcmV0 dXJuIDA7DQp9DQoNCnZvaWQgY2FycF9kZWxfdGFzayhzdHJ1Y3QgX19jYXJwX21hc3Rlcl90YXNr ICptdCwgaW50IG51bSkNCnsNCglzdHJ1Y3QgbGlzdF9oZWFkICplbnQsICpuOw0KCXN0cnVjdCBj YXJwX21hc3Rlcl90YXNrICp0ID0gTlVMTDsNCglpbnQgZm91bmQgPSAwOw0KCQ0KCWlmIChudW0g IT0gTUFTVEVSX1FVRVVFICYmIG51bSAhPSBCQUNLVVBfUVVFVUUpDQoJCXJldHVybjsNCgkNCglz cGluX2xvY2soJmNhcnBfcXVldWVfbG9jayk7DQoJbGlzdF9mb3JfZWFjaF9zYWZlKGVudCwgbiwg JmNhcnBfd29ya3NbbnVtXSkNCgl7DQoJCXQgPSBsaXN0X2VudHJ5KGVudCwgc3RydWN0IGNhcnBf bWFzdGVyX3Rhc2ssIGVudHJ5KTsNCg0KCQlpZiAodC0+dGFzay0+aWQgPT0gbXQtPmlkKSB7DQoJ CQlsaXN0X2RlbCgmdC0+ZW50cnkpOw0KCQkJZm91bmQgPSAxOw0KCQkJYnJlYWs7DQoJCX0NCgl9 DQoJc3Bpbl91bmxvY2soJmNhcnBfcXVldWVfbG9jayk7DQoNCglpZiAoZm91bmQpDQoJew0KCQlh dG9taWNfZGVjKCZ0LT50YXNrLT5yZWZjbnQpOw0KCQljYXJwX2ZyZWVfdGFzayh0KTsNCgl9DQp9 DQoNCnZvaWQgY2FycF9jYWxsX3F1ZXVlKGludCBudW0pDQp7DQoJc3RydWN0IGxpc3RfaGVhZCAq ZW50LCAqbjsNCglzdHJ1Y3QgY2FycF9tYXN0ZXJfdGFzayAqdDsNCgkNCglpZiAobnVtICE9IE1B U1RFUl9RVUVVRSAmJiBudW0gIT0gQkFDS1VQX1FVRVVFKQ0KCQlyZXR1cm47DQoJDQoJc3Bpbl9s b2NrKCZjYXJwX3F1ZXVlX2xvY2spOw0KCWxpc3RfZm9yX2VhY2hfc2FmZShlbnQsIG4sICZjYXJw X3dvcmtzW251bV0pDQoJew0KCQl0ID0gbGlzdF9lbnRyeShlbnQsIHN0cnVjdCBjYXJwX21hc3Rl cl90YXNrLCBlbnRyeSk7DQoJCXF1ZXVlX3dvcmsoY2FycF9xdWV1ZVtudW1dLCAmdC0+d29yayk7 DQoJfQ0KCXNwaW5fdW5sb2NrKCZjYXJwX3F1ZXVlX2xvY2spOw0KfQ0KDQppbnQgY2FycF9pbml0 X3F1ZXVlcyh2b2lkKQ0Kew0KCWludCBpOw0KDQoJZm9yIChpPTA7IGk8MjsgKytpKQ0KCQlJTklU X0xJU1RfSEVBRCgmY2FycF93b3Jrc1tpXSk7DQoNCgljYXJwX3F1ZXVlW01BU1RFUl9RVUVVRV0g PSBjcmVhdGVfd29ya3F1ZXVlKCJDQVJQX20iKTsNCglpZiAoIWNhcnBfcXVldWVbTUFTVEVSX1FV RVVFXSkNCgl7DQoJCWxvZygiRmFpbGVkIHRvIGNyZWF0ZSBtYXN0ZXIgQ0FSUCBxdWV1ZS5cbiIp Ow0KCQlyZXR1cm4gLTE7DQoJfQ0KCQ0KCWNhcnBfcXVldWVbQkFDS1VQX1FVRVVFXSA9IGNyZWF0 ZV93b3JrcXVldWUoIkNBUlBfYiIpOw0KCWlmICghY2FycF9xdWV1ZVtCQUNLVVBfUVVFVUVdKQ0K CXsNCgkJZGVzdHJveV93b3JrcXVldWUoY2FycF9xdWV1ZVtNQVNURVJfUVVFVUVdKTsNCgkJbG9n KCJGYWlsZWQgdG8gY3JlYXRlIGJhY2t1cCBDQVJQIHF1ZXVlLlxuIik7DQoJCXJldHVybiAtMTsN Cgl9DQoNCglyZXR1cm4gMDsNCn0NCg0Kdm9pZCBjYXJwX2ZsdXNoX3F1ZXVlKGludCBudW0pDQp7 DQoJaWYgKG51bSAhPSBNQVNURVJfUVVFVUUgJiYgbnVtICE9IEJBQ0tVUF9RVUVVRSkNCgkJcmV0 dXJuOw0KCQ0KCWZsdXNoX3dvcmtxdWV1ZShjYXJwX3F1ZXVlW251bV0pOw0KfQ0KDQp2b2lkIGNh cnBfZmluaV9xdWV1ZXModm9pZCkNCnsNCgljYXJwX2ZsdXNoX3F1ZXVlKE1BU1RFUl9RVUVVRSk7 DQoJZGVzdHJveV93b3JrcXVldWUoY2FycF9xdWV1ZVtNQVNURVJfUVVFVUVdKTsNCgljYXJwX2Zs dXNoX3F1ZXVlKEJBQ0tVUF9RVUVVRSk7DQoJZGVzdHJveV93b3JrcXVldWUoY2FycF9xdWV1ZVtC QUNLVVBfUVVFVUVdKTsNCn0NCg0K --=-a+/kFhj9P+33ALSFH70e Content-Disposition: attachment; filename=carp_queue.h Content-Type: text/x-chdr; name=carp_queue.h; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwX3F1ZXVlLmgNCiAqIA0KICogMjAwNCBDb3B5cmlnaHQgKGMpIEV2Z2VuaXkg UG9seWFrb3YgPGpvaG5wb2xAMmthLm1pcHQucnU+DQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0K ICogDQogKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1 dGUgaXQgYW5kL29yIG1vZGlmeQ0KICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCiAqIHRoZSBGcmVlIFNvZnR3YXJl IEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQogKiAoYXQg eW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBk aXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KICogYnV0IFdJ VEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YN CiAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g IFNlZSB0aGUNCiAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMu DQogKg0KICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UNCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQogKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUg UGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQogKg0KICovDQoN CiNpZm5kZWYgX19DQVJQX1FVRVVFX0gNCiNkZWZpbmUgX19DQVJQX1FVRVVFX0gNCg0KI2luY2x1 ZGUgPGxpbnV4L3dvcmtxdWV1ZS5oPg0KDQojaW5jbHVkZSA8YXNtL2F0b21pYy5oPg0KDQplbnVt IGNhcnBfcXVldWVfbnVtYmVyIHtNQVNURVJfUVVFVUUgPSAwLCBCQUNLVVBfUVVFVUV9Ow0KDQpz dHJ1Y3QgX19jYXJwX21hc3Rlcl90YXNrDQp7DQoJYXRvbWljX3QJcmVmY250Ow0KCXUzMgkJaWQ7 DQoNCgl2b2lkIAkJKCogY2FsbGJhY2spKHZvaWQgKik7DQoJdm9pZAkJKmRhdGE7DQoNCgl2b2lk CQkqcHJpdjsNCn07DQoNCnN0cnVjdCBjYXJwX21hc3Rlcl90YXNrDQp7DQoJc3RydWN0IGxpc3Rf aGVhZAkJZW50cnk7DQoJc3RydWN0IF9fY2FycF9tYXN0ZXJfdGFzawkqdGFzazsNCg0KCXN0cnVj dCB3b3JrX3N0cnVjdAkJd29yazsNCn07DQoNCmludCBjYXJwX2luaXRfcXVldWVzKHZvaWQpOw0K dm9pZCBjYXJwX2ZsdXNoX3F1ZXVlKGludCk7DQp2b2lkIGNhcnBfZmluaV9xdWV1ZXModm9pZCk7 DQp2b2lkIGNhcnBfY2FsbF9xdWV1ZShpbnQpOw0KDQppbnQgY2FycF9hZGRfdGFzayhzdHJ1Y3Qg X19jYXJwX21hc3Rlcl90YXNrICosIGludCk7DQp2b2lkIGNhcnBfZGVsX3Rhc2soc3RydWN0IF9f Y2FycF9tYXN0ZXJfdGFzayAqLCBpbnQpOw0KDQojZW5kaWYgLyogX19DQVJQX1FVRVVFX0ggKi8N Cg== --=-a+/kFhj9P+33ALSFH70e Content-Disposition: attachment; filename=carp_log.c Content-Type: text/x-csrc; name=carp_log.c; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwX2xvZy5jDQogKiANCiAqIDIwMDQgQ29weXJpZ2h0IChjKSBFdmdlbml5IFBv bHlha292IDxqb2hucG9sQDJrYS5taXB0LnJ1Pg0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAq IA0KICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl IGl0IGFuZC9vciBtb2RpZnkNCiAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQogKiB0aGUgRnJlZSBTb2Z0d2FyZSBG b3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcg0KICogKGF0IHlv dXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCiAqDQogKiBUaGlzIHByb2dyYW0gaXMgZGlz dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCiAqIGJ1dCBXSVRI T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQog KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT ZWUgdGhlDQogKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0K ICoNCiAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlDQogKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0 ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBs YWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQ0KICoNCiAqLw0KDQoj aW5jbHVkZSA8bGludXgvY29uZmlnLmg+DQojaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQojaW5j bHVkZSA8bGludXgvdHlwZXMuaD4NCiNpbmNsdWRlIDxsaW51eC9zY2hlZC5oPg0KI2luY2x1ZGUg PGxpbnV4L2tlcm5lbC5oPg0KI2luY2x1ZGUgPGxpbnV4L3NrYnVmZi5oPg0KI2luY2x1ZGUgPGxp bnV4L25ldGRldmljZS5oPg0KI2luY2x1ZGUgPGxpbnV4L2luLmg+DQojaW5jbHVkZSA8bGludXgv cmFuZG9tLmg+DQojaW5jbHVkZSA8bGludXgvY3J5cHRvLmg+DQoNCiNpbmNsdWRlIDxuZXQvc29j ay5oPg0KI2luY2x1ZGUgPG5ldC9pcC5oPg0KI2luY2x1ZGUgPG5ldC9pY21wLmg+DQojaW5jbHVk ZSA8bmV0L3Byb3RvY29sLmg+DQojaW5jbHVkZSA8bmV0L2FycC5oPg0KDQojaW5jbHVkZSA8YXNt L3NjYXR0ZXJsaXN0Lmg+DQojaW5jbHVkZSA8YXNtL2RlbGF5Lmg+DQoNCiNpbmNsdWRlICJjYXJw LmgiDQojaW5jbHVkZSAiY2FycF9sb2cuaCINCg0Kdm9pZCBkdW1wX2FkZHJfaW5mbyhzdHJ1Y3Qg Y2FycF9wcml2ICpjcCkNCnsNCglpbnQgaTsNCgkNCglwcmludGsoS0VSTl9JTkZPICJDQVJQIGFk ZHI6IGh3PSIpOw0KCWZvciAoaT0wOyBpPEVUSF9BTEVOOyArK2kpDQoJCXByaW50aygiJTAyeCVj IiwgKHVuc2lnbmVkIGNoYXIpY3AtPm9kZXYtPmRldl9hZGRyW2ldLCAoaT09RVRIX0FMRU4tMSk/ JyAnOic6Jyk7DQoJcHJpbnRrKCIsIHN3PSIpOw0KCWZvciAoaT0wOyBpPDQ7ICsraSkNCgkJcHJp bnRrKCIlZCVjIiwgKG50b2hsKGNwLT5pcGguc2FkZHIpID4+ICgzLWkpKjgpJjB4ZmYsIChpPT0z KT8nICc6Jy4nKTsNCglwcmludGsoIiwgZHN0PSIpOw0KCWZvciAoaT0wOyBpPDQ7ICsraSkNCgkJ cHJpbnRrKCIlZCVjIiwgKG50b2hsKGNwLT5pcGguZGFkZHIpID4+ICgzLWkpKjgpJjB4ZmYsIChp PT0zKT8nICc6Jy4nKTsNCglwcmludGsoIlxuIik7DQp9DQoNCnZvaWQgZHVtcF9obWFjX3BhcmFt cyhzdHJ1Y3QgY2FycF9wcml2ICpjcCkNCnsNCglpbnQgaTsNCgl1bnNpZ25lZCBpbnQga2V5bGVu Ow0KCXN0cnVjdCBzY2F0dGVybGlzdCBzZzsNCgl1OCBjYXJwX21kW0NBUlBfU0lHX0xFTl07DQoN CglrZXlsZW4gPSBzaXplb2YoY3AtPmNhcnBfa2V5KTsNCg0KCXNnLnBhZ2UJPSB2aXJ0X3RvX3Bh Z2UoJmNwLT5jYXJwX2Fkdl9jb3VudGVyKTsNCglzZy5vZmZzZXQgPSAodW5zaWduZWQgbG9uZyko JmNwLT5jYXJwX2Fkdl9jb3VudGVyKSAlIFBBR0VfU0laRTsNCglzZy5sZW5ndGggPSBzaXplb2Yo Y3AtPmNhcnBfYWR2X2NvdW50ZXIpOw0KCQ0KCWNyeXB0b19obWFjKGNwLT50Zm0sIGNwLT5jYXJw X2tleSwgJmtleWxlbiwgJnNnLCAxLCBjYXJwX21kKTsNCgkNCglwcmludGsoS0VSTl9JTkZPICJr ZXk6ICIpOw0KCWZvciAoaT0wOyBpPENBUlBfS0VZX0xFTjsgKytpKQ0KCQlwcmludGsoIiUwMngg IiwgY3AtPmNhcnBfa2V5W2ldKTsNCglwcmludGsoIlxuIik7DQoNCglwcmludGsoImNvdW50ZXI6 ICVsbHggIiwgY3AtPmNhcnBfYWR2X2NvdW50ZXIpOw0KDQoJcHJpbnRrKCJobWFjOiAiKTsNCglm b3IgKGk9MDsgaTxDQVJQX1NJR19MRU47ICsraSkNCgkJcHJpbnRrKCIlMDJ4ICIsIGNhcnBfbWRb aV0pOw0KCXByaW50aygiXG4iKTsNCn0NCg0Kdm9pZCBkdW1wX2NhcnBfaGVhZGVyKHN0cnVjdCBj YXJwX2hlYWRlciAqY2gpDQp7DQoJdTY0IGNvdW50ZXI7DQoJaW50IGk7DQoJDQoJY291bnRlciA9 IG50b2hsKGNoLT5jYXJwX2NvdW50ZXJbMF0pOw0KCWNvdW50ZXIgPSBjb3VudGVyPDwzMjsNCglj b3VudGVyICs9IG50b2hsKGNoLT5jYXJwX2NvdW50ZXJbMV0pOw0KCQ0KCWxvZygidHlwZT0ldSwg dmVyc2lvbj0ldSwgdmhpZD0ldSwgc2tldz0ldSwgYmFzZT0ldSwgY291bnRlcj0lbGx1LCBtZD17 IiwNCgkJCWNoLT5jYXJwX3R5cGUsDQoJCQljaC0+Y2FycF92ZXJzaW9uLA0KCQkJY2gtPmNhcnBf dmhpZCwNCgkJCWNoLT5jYXJwX2FkdnNrZXcsDQoJCQljaC0+Y2FycF9hZHZiYXNlLA0KCQkJY291 bnRlcik7DQoJDQoJZm9yIChpPTA7IGk8c2l6ZW9mKGNoLT5jYXJwX21kKTsgKytpKQ0KCXsNCgkJ cHJpbnRrKCIlMDJ4ICIsIGNoLT5jYXJwX21kW2ldKTsNCgl9DQoJcHJpbnRrKCJ9XG4iKTsNCn0N Cg0K --=-a+/kFhj9P+33ALSFH70e Content-Disposition: attachment; filename=carp_log.h Content-Type: text/x-chdr; name=carp_log.h; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwX2xvZy5oDQogKiANCiAqIDIwMDQgQ29weXJpZ2h0IChjKSBFdmdlbml5IFBv bHlha292IDxqb2hucG9sQDJrYS5taXB0LnJ1Pg0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAq IA0KICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl IGl0IGFuZC9vciBtb2RpZnkNCiAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQogKiB0aGUgRnJlZSBTb2Z0d2FyZSBG b3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcg0KICogKGF0IHlv dXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCiAqDQogKiBUaGlzIHByb2dyYW0gaXMgZGlz dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCiAqIGJ1dCBXSVRI T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQog KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT ZWUgdGhlDQogKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0K ICoNCiAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlDQogKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0 ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBs YWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQ0KICoNCiAqLw0KDQoj aWZuZGVmIF9fQ0FSUF9MT0dfSA0KI2RlZmluZSBfX0NBUlBfTE9HX0gNCg0KI2luY2x1ZGUgImNh cnAuaCINCg0KI2RlZmluZSBsb2coZiwgYS4uLikgcHJpbnRrKEtFUk5fSU5GTyBmLCAjI2EpDQoN CnZvaWQgZHVtcF9hZGRyX2luZm8oc3RydWN0IGNhcnBfcHJpdiAqKTsNCnZvaWQgZHVtcF9obWFj X3BhcmFtcyhzdHJ1Y3QgY2FycF9wcml2ICopOw0Kdm9pZCBkdW1wX2NhcnBfaGVhZGVyKHN0cnVj dCBjYXJwX2hlYWRlciAqKTsNCg0KI2VuZGlmIC8qIF9fQ0FSUF9MT0dfSCAqLw0K --=-a+/kFhj9P+33ALSFH70e Content-Disposition: attachment; filename=Makefile Content-Type: text/x-makefile; name=Makefile; charset=koi8-r Content-Transfer-Encoding: base64 b2JqLW0JCTo9IGlwX2NhcnAubw0KaXBfY2FycC1vYmpzCTo9IGNhcnAubyBjYXJwX2xvZy5vIGNh cnBfcXVldWUubw0KDQpLRElSCTo9IC91c3IvbG9jYWwvc3JjL2xpbnV4LTIuNg0KUFdECTo9ICQo c2hlbGwgcHdkKQ0KDQpkZWZhdWx0Og0KCSQoTUFLRSkgLUMgJChLRElSKSBTVUJESVJTPSQoUFdE KSBtb2R1bGVzDQoJZ2NjIC1XIC1XYWxsIGNhcnBjdGwuYyAtbyBjYXJwY3RsDQoNCmNvcHk6DQoJ c2NwIGlwX2NhcnAua28gY2FycGN0bCBtdGVzdDpjYXJwLw0KCXNjcCBpcF9jYXJwLmtvIGNhcnBj dGwgcGNpeDphV29yay9jYXJwLw0KDQpjbGVhbjoNCglybSAtZiAqLm8gKi5rbyAqLm1vZC4qIC4q LmNtZCAqfiBjYXJwY3RsDQoJcm0gLXJmIC50bXBfdmVyc2lvbnMNCg== --=-a+/kFhj9P+33ALSFH70e-- --=-8e7T7U6zlBuwtRlq0Usb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9ohkIKTPhE+8wY0RAk+SAJ9mjHxsXIJmP09tuQUSHamLTgQQTwCfYIMT naO2hbR7jdDNtH5UGzgf4bU= =2Nnu -----END PGP SIGNATURE----- --=-8e7T7U6zlBuwtRlq0Usb-- From alexeyt@sdf.lonestar.org Thu Jul 15 06:46:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 06:46:07 -0700 (PDT) Received: from sdf.lonestar.org (IDENT:root@ol.freeshell.org [192.94.73.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FDk1fA005938 for ; Thu, 15 Jul 2004 06:46:01 -0700 Received: from sdf.lonestar.org (IDENT:alexeyt@mx.freeshell.org [192.94.73.21]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i6FDjfY5015698; Thu, 15 Jul 2004 13:45:41 GMT Received: (from alexeyt@localhost) by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i6FDjeoS001786; Thu, 15 Jul 2004 13:45:40 GMT Date: Thu, 15 Jul 2004 13:45:40 +0000 (UTC) From: Alexey Toptygin To: Michael T Kerrisk cc: netdev@oss.sgi.com Subject: Re: kernel-manpage inconsistency In-Reply-To: <4407.1089895895@www4.gmx.net> Message-ID: References: <4407.1089895895@www4.gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexeyt@freeshell.org Precedence: bulk X-list: netdev On Thu, 15 Jul 2004, Michael T Kerrisk wrote: >> In recv(2) it says: >> >> MSG_TRUNC >> Return the real length of the packet, even when it was longer >> than the passed buffer. Only valid for packet sockets. >> >> But this is not honored. > > I don't know the details here, sorry. A quick glance at the source > (raw_recvmsg() in net/ipv4/raw.c) shows that MSG_TRUNC is used there. Yes, it's used, but like this: copied = skb->len; if (len < copied) { msg->msg_flags |= MSG_TRUNC; copied = len; } that is to say, MSG_TRUNC is set in the struct msghdr that you get back from the recvmsg call, but the length you get out is still <= what you passed in. This is not what the manpage is implying. Nearly identical code is in udp.c, in af_unix.c, etc. I guess my question is should this be changed in the kernel or in the manpage? >> Also, in udp(7), it says: >> >> IOCTLS >> These ioctls can be accessed using ioctl(2). The correct syntax is: >> >> int value; >> error = ioctl(tcp_socket, ioctl_type, &value); >> >> SIOCINQ >> Gets a pointer to an integer as argument. Returns the size of >> the next pending datagram in the integer in bytes, or 0 when no >> datagram is pending. >> >> SIOCOUTQ >> Returns the number of data bytes in the local send queue. Only >> supported with Linux 2.4 and above. >> >> These don't appear to be implemented. ( They're not in any headers and >> they're not listed in ioctl_list(2). ) > > They're names in the kernel source. In userland, FIONREAD and TIOCOUTQ will > do the trick for sockets. You're right! Here it is in include/linux/sockios.h: /* Linux-specific socket ioctls */ #define SIOCINQ FIONREAD #define SIOCOUTQ TIOCOUTQ But why would the man page document the kernel-specific names, and not the ones you can see in libc? >> Please tell me who I need to report this to to get it fixed. > > The latest Linux man pages can always be found at > ftp://ftp.win.tue.nl/pub/linux-local/manpages/ and the maintainer is > Andries Brouwer (Andries.Brouwer@cwi.nl) -- he'll take suitable new man > pages, or patches in "diff -u" format. Thanks. Alexey From margitsw@t-online.de Thu Jul 15 07:00:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 07:00:46 -0700 (PDT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FE0cP4010729 for ; Thu, 15 Jul 2004 07:00:41 -0700 Received: from fwd11.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1Bl6lT-0006Ga-02; Thu, 15 Jul 2004 15:59:11 +0200 Received: from roglap.local (TEbdmUZYQeb1tMAvY8rhNLWWRK7LePMmlpupfJJtVVv0PicF34b2ow@[217.224.17.124]) by fwd11.sul.t-online.com with esmtp id 1Bl6lD-0R4lZw0; Thu, 15 Jul 2004 15:58:55 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Fix reference to uninitialized pointer Date: Thu, 15 Jul 2004 15:52:02 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Dwo9ABdo1SDLJ2W" Message-Id: <200407151552.03289.margitsw@t-online.de> X-ID: TEbdmUZYQeb1tMAvY8rhNLWWRK7LePMmlpupfJJtVVv0PicF34b2ow X-archive-position: 6957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_Dwo9ABdo1SDLJ2W Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-15 Margit Schubert-While * oid_mgt.c is calling islpci_mgt_transaction passing the address of a pointer to the management frame. This is not being initialized by the caller. The callee only updates this pointer when successful. When not, boom. * Being ultracautious again, not only initialize in the caller, also null out the pointer unconditionally in the callee. Margit --Boundary-00=_Dwo9ABdo1SDLJ2W Content-Type: text/x-diff; charset="us-ascii"; name="mgtframeptr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mgtframeptr.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_mgt.c linux-2.6.8-03/drivers/net/wireless/prism54/islpci_mgt.c --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_mgt.c 2004-06-25 19:48:40.000000000 +0200 +++ linux-2.6.8-03/drivers/net/wireless/prism54/islpci_mgt.c 2004-07-15 15:17:21.000000000 +0200 @@ -458,6 +458,8 @@ int err; DEFINE_WAIT(wait); + *recvframe = NULL; + if (down_interruptible(&priv->mgmt_sem)) return -ERESTARTSYS; diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.8-03/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c 2004-07-14 21:55:11.000000000 +0200 +++ linux-2.6.8-03/drivers/net/wireless/prism54/oid_mgt.c 2004-07-15 15:13:53.000000000 +0200 @@ -408,7 +408,7 @@ mgt_set_request(islpci_private *priv, enum oid_num_t n, int extra, void *data) { int ret = 0; - struct islpci_mgmtframe *response; + struct islpci_mgmtframe *response = NULL; int response_op = PIMFOR_OP_ERROR; int dlen; void *cache, *_data = data; @@ -620,7 +620,7 @@ static int mgt_update_addr(islpci_private *priv) { - struct islpci_mgmtframe *res; + struct islpci_mgmtframe *res = NULL; int ret; ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, --Boundary-00=_Dwo9ABdo1SDLJ2W-- From johnpol@2ka.mipt.ru Thu Jul 15 07:03:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 07:17:58 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FE3PfY014875 for ; Thu, 15 Jul 2004 07:03:35 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6FDVGTV027799; Thu, 15 Jul 2004 17:31:16 +0400 Subject: [1/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: netdev@oss.sgi.com Cc: netfilter-failover@lists.netfilter.org In-Reply-To: <1089898303.6114.859.camel@uganda> References: <1089898303.6114.859.camel@uganda> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aENk32xTOCLiPN2oivF9" Organization: MIPT Message-Id: <1089898595.6114.866.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 15 Jul 2004 17:36:35 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6958 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-aENk32xTOCLiPN2oivF9 Content-Type: multipart/mixed; boundary="=-zMMMLADPc6OCZZ3l3ocw" --=-zMMMLADPc6OCZZ3l3ocw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-15 at 17:31, Evgeniy Polyakov wrote:=20 > Hello, network developers. >=20 > I'm glad to introduce CARP failover mechanism implementation. > It is based on OpenBSD's CARP protocol but is not compatible with it > since OpenBSD's implementation does not contain protection against > repeated message sending. >=20 > The main goal of the project is to implement CARP + firewall sync, but > second part already implemented by Harald Welte an= d=20 > KOVACS Krisztian in ct_sync. >=20 > By design each node has it's own advertisement base and skew, node with > the least timeval constructed from them became a master. > It begins to advertise it's base and skew until shutdown or other node > lower it's base+skew pair. > CARP uses currently only IPv4 multicast, but can be easily changed to > use IPv6.=20 > Each CARP packet contains unique 64bit counter with it's SHA1 hmac > digest with 20byte secret key. By design this counter is incremented in > both master and backup before sending and while receiving accordingly. > If master and backup counters do not coincide with each other while > receiving backup node drops this packet and thus preventing repeated > sending attack. > When after predefined interval master didn't send any packet or it's > base+skew is bigger than that in the remote node those node becomes a > master and begins to advertise. >=20 > CARP has 2 work queues for "became_master" and "became_backup" events. > Such events may be easily registered in runtime by external modules. > One of such event handlers may send netlink message to ct_sync and/or > userspace daemon which will flush iptables rules, up/down interfaces and > so on... >=20 > Please review and comment. >=20 > Code against 2.6 attached=20 > in next 2 e-mails since netfilter-failover@lists.netfilter.org doesn't ac= cept > e-mail greater than 40kb. >=20 > Code also is available at > http://www.2ka.mipt.ru/~johnpol/carp_latest.tar.gz --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-zMMMLADPc6OCZZ3l3ocw Content-Disposition: attachment; filename=carp.c Content-Type: text/x-csrc; name=carp.c; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwLmMNCiAqIA0KICogMjAwNCBDb3B5cmlnaHQgKGMpIEV2Z2VuaXkgUG9seWFr b3YgPGpvaG5wb2xAMmthLm1pcHQucnU+DQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KICogDQog KiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg YW5kL29yIG1vZGlmeQ0KICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQ dWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCiAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5k YXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQogKiAoYXQgeW91ciBv cHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmli dXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KICogYnV0IFdJVEhPVVQg QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YNCiAqIE1F UkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0 aGUNCiAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQogKg0K ICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UNCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRv IHRoZSBGcmVlIFNvZnR3YXJlDQogKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2Us IFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQogKg0KICovDQoNCiNpbmNs dWRlIDxsaW51eC9jb25maWcuaD4NCiNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4NCiNpbmNsdWRl IDxsaW51eC90eXBlcy5oPg0KI2luY2x1ZGUgPGxpbnV4L3NjaGVkLmg+DQojaW5jbHVkZSA8bGlu dXgva2VybmVsLmg+DQojaW5jbHVkZSA8YXNtL3VhY2Nlc3MuaD4NCiNpbmNsdWRlIDxsaW51eC9z a2J1ZmYuaD4NCiNpbmNsdWRlIDxsaW51eC9uZXRkZXZpY2UuaD4NCiNpbmNsdWRlIDxsaW51eC9p bi5oPg0KI2luY2x1ZGUgPGxpbnV4L3RjcC5oPg0KI2luY2x1ZGUgPGxpbnV4L3VkcC5oPg0KI2lu Y2x1ZGUgPGxpbnV4L2lmX2FycC5oPg0KI2luY2x1ZGUgPGxpbnV4L21yb3V0ZS5oPg0KI2luY2x1 ZGUgPGxpbnV4L2luaXQuaD4NCiNpbmNsdWRlIDxsaW51eC9pbjYuaD4NCiNpbmNsdWRlIDxsaW51 eC9pbmV0ZGV2aWNlLmg+DQojaW5jbHVkZSA8bGludXgvaWdtcC5oPg0KI2luY2x1ZGUgPGxpbnV4 L25ldGZpbHRlcl9pcHY0Lmg+DQojaW5jbHVkZSA8bGludXgvY3J5cHRvLmg+DQojaW5jbHVkZSA8 bGludXgvcmFuZG9tLmg+DQoNCiNpbmNsdWRlIDxuZXQvc29jay5oPg0KI2luY2x1ZGUgPG5ldC9p cC5oPg0KI2luY2x1ZGUgPG5ldC9pY21wLmg+DQojaW5jbHVkZSA8bmV0L3Byb3RvY29sLmg+DQoj aW5jbHVkZSA8bmV0L2FycC5oPg0KI2luY2x1ZGUgPG5ldC9jaGVja3N1bS5oPg0KI2luY2x1ZGUg PG5ldC9pbmV0X2Vjbi5oPg0KDQojaW5jbHVkZSA8YXNtL3NjYXR0ZXJsaXN0Lmg+DQoNCiNpZmRl ZiBDT05GSUdfSVBWNg0KI2luY2x1ZGUgPG5ldC9pcHY2Lmg+DQojaW5jbHVkZSA8bmV0L2lwNl9m aWIuaD4NCiNpbmNsdWRlIDxuZXQvaXA2X3JvdXRlLmg+DQojZW5kaWYNCg0KI2luY2x1ZGUgImNh cnAuaCINCiNpbmNsdWRlICJjYXJwX2xvZy5oIg0KI2luY2x1ZGUgImNhcnBfcXVldWUuaCINCiNp bmNsdWRlICJjYXJwX2lvY3RsLmgiDQoNCiNkZWZpbmUgdGltZXZhbF9iZWZvcmUoYmVmb3JlLCBh ZnRlcikJCQlcDQoJKCgoYmVmb3JlKS0+dHZfc2VjID09IChhZnRlciktPnR2X3NlYykgPyAoKGJl Zm9yZSktPnR2X3VzZWMgPCAoYWZ0ZXIpLT50dl91c2VjKSA6ICgoYmVmb3JlKS0+dHZfc2VjIDwg KGFmdGVyKS0+dHZfc2VjKSkNCg0KDQpzdGF0aWMgaW50IGNhcnBfaW5pdChzdHJ1Y3QgbmV0X2Rl dmljZSAqKTsNCnN0YXRpYyB2b2lkIGNhcnBfdW5pbml0KHN0cnVjdCBuZXRfZGV2aWNlICopOw0K c3RhdGljIHZvaWQgY2FycF9zZXR1cChzdHJ1Y3QgbmV0X2RldmljZSAqKTsNCnN0YXRpYyBpbnQg Y2FycF9jbG9zZShzdHJ1Y3QgbmV0X2RldmljZSAqKTsNCnN0YXRpYyBpbnQgY2FycF9vcGVuKHN0 cnVjdCBuZXRfZGV2aWNlICopOw0Kc3RhdGljIGludCBjYXJwX2lvY3RsIChzdHJ1Y3QgbmV0X2Rl dmljZSAqLCBzdHJ1Y3QgaWZyZXEgKiwgaW50KTsNCnN0YXRpYyBpbnQgY2FycF9jaGVja19wYXJh bXMoc3RydWN0IGNhcnBfaW9jdGxfcGFyYW1zKTsNCg0Kc3RhdGljIHZvaWQgY2FycF9lcnIoc3Ry dWN0IHNrX2J1ZmYgKiwgdTMyKTsNCnN0YXRpYyBpbnQgY2FycF9yY3Yoc3RydWN0IHNrX2J1ZmYg Kik7DQpzdGF0aWMgaW50IGNhcnBfeG1pdChzdHJ1Y3Qgc2tfYnVmZiAqLCBzdHJ1Y3QgbmV0X2Rl dmljZSAqKTsNCg0Kc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpjYXJwX2dldF9zdGF0 cyhzdHJ1Y3QgbmV0X2RldmljZSAqKTsNCg0Kc3RhdGljIHZvaWQgY2FycF9obWFjX3NpZ24oc3Ry dWN0IGNhcnBfcHJpdiAqLCBzdHJ1Y3QgY2FycF9oZWFkZXIgKik7DQpzdGF0aWMgaW50IGNhcnBf aG1hY192ZXJpZnkoc3RydWN0IGNhcnBfcHJpdiAqLCBzdHJ1Y3QgY2FycF9oZWFkZXIgKik7DQpz dGF0aWMgdTMyIGlubGluZSBhZGRyMnZhbCh1OCwgdTgsIHU4LCB1OCk7DQoNCnN0YXRpYyB2b2lk IGNhcnBfc2V0X3N0YXRlKHN0cnVjdCBjYXJwX3ByaXYgKiwgZW51bSBjYXJwX3N0YXRlKTsNCnN0 YXRpYyB2b2lkIGNhcnBfbWFzdGVyX2Rvd24odW5zaWduZWQgbG9uZyk7DQpzdGF0aWMgdm9pZCBj YXJwX2FkdmVydGlzZSh1bnNpZ25lZCBsb25nKTsNCg0Kc3RhdGljIGludCBfX2luaXQgZGV2aWNl X2NhcnBfaW5pdCh2b2lkKTsNCnZvaWQgX19leGl0IGRldmljZV9jYXJwX2Zpbmkodm9pZCk7DQoN CnN0YXRpYyBzdHJ1Y3QgbmV0X2RldmljZSAqY2FycF9kZXY7DQoNCnN0YXRpYyB2b2lkIGNhcnBf dW5pbml0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQp7DQoJc3RydWN0IGNhcnBfcHJpdiAqY3Ag PSBkZXYtPnByaXY7DQoJDQoJaWYgKHRpbWVyX3BlbmRpbmcoJmNwLT5tZF90aW1lcikpDQoJCWRl bF90aW1lcl9zeW5jKCZjcC0+bWRfdGltZXIpOw0KCWlmICh0aW1lcl9wZW5kaW5nKCZjcC0+YWR2 X3RpbWVyKSkNCgkJZGVsX3RpbWVyX3N5bmMoJmNwLT5hZHZfdGltZXIpOw0KCQkNCglsb2coIiVz XG4iLCBfX2Z1bmNfXyk7DQoJZGV2X3B1dChjcC0+b2Rldik7DQoJZGV2X3B1dChkZXYpOw0KfQ0K DQpzdGF0aWMgdm9pZCBjYXJwX2VycihzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCB1MzIgaW5mbykNCnsN Cglsb2coIiVzXG4iLCBfX2Z1bmNfXyk7DQoJa2ZyZWVfc2tiKHNrYik7DQp9DQoNCnN0YXRpYyB2 b2lkIGNhcnBfaG1hY19zaWduKHN0cnVjdCBjYXJwX3ByaXYgKmNwLCBzdHJ1Y3QgY2FycF9oZWFk ZXIgKmNoKQ0Kew0KCXVuc2lnbmVkIGludCBrZXlsZW4gPSBzaXplb2YoY3AtPmNhcnBfa2V5KTsN CglzdHJ1Y3Qgc2NhdHRlcmxpc3Qgc2c7DQoNCglzZy5wYWdlID0gdmlydF90b19wYWdlKGNoLT5j YXJwX2NvdW50ZXIpOw0KCXNnLm9mZnNldCA9ICgodW5zaWduZWQgbG9uZykoY2gtPmNhcnBfY291 bnRlcikpICUgUEFHRV9TSVpFOw0KCXNnLmxlbmd0aCA9IHNpemVvZihjaC0+Y2FycF9jb3VudGVy KTsNCg0KCWNyeXB0b19obWFjKGNwLT50Zm0sIGNwLT5jYXJwX2tleSwgJmtleWxlbiwgJnNnLCAx LCBjaC0+Y2FycF9tZCk7DQp9DQoNCnN0YXRpYyBpbnQgY2FycF9obWFjX3ZlcmlmeShzdHJ1Y3Qg Y2FycF9wcml2ICpjcCwgc3RydWN0IGNhcnBfaGVhZGVyICpjaCkNCnsNCgl1OCB0bXBfbWRbQ0FS UF9TSUdfTEVOXTsNCgl1bnNpZ25lZCBpbnQga2V5bGVuID0gc2l6ZW9mKGNwLT5jYXJwX2tleSk7 DQoJc3RydWN0IHNjYXR0ZXJsaXN0IHNnOw0KDQoJc2cucGFnZSA9IHZpcnRfdG9fcGFnZShjaC0+ Y2FycF9jb3VudGVyKTsNCglzZy5vZmZzZXQgPSAoKHVuc2lnbmVkIGxvbmcpKGNoLT5jYXJwX2Nv dW50ZXIpKSAlIFBBR0VfU0laRTsNCglzZy5sZW5ndGggPSBzaXplb2YoY2gtPmNhcnBfY291bnRl cik7DQoNCgljcnlwdG9faG1hYyhjcC0+dGZtLCBjcC0+Y2FycF9rZXksICZrZXlsZW4sICZzZywg MSwgdG1wX21kKTsNCiNpZiAwDQoJew0KCQlpbnQgaTsNCgkJcHJpbnRrKCJjYWxjdWxhdGVkOiAg Iik7DQoJCWZvciAoaT0wOyBpPENBUlBfU0lHX0xFTjsgKytpKQ0KCQkJcHJpbnRrKCIlMDJ4ICIs IHRtcF9tZFtpXSk7DQoJCXByaW50aygiXG4iKTsNCgkJcHJpbnRrKCJmcm9tIGhlYWRlcjogIik7 DQoJCWZvciAoaT0wOyBpPENBUlBfU0lHX0xFTjsgKytpKQ0KCQkJcHJpbnRrKCIlMDJ4ICIsIGNo LT5jYXJwX21kW2ldKTsNCgkJcHJpbnRrKCJcbiIpOw0KCX0NCiNlbmRpZg0KCXJldHVybiBtZW1j bXAodG1wX21kLCBjaC0+Y2FycF9tZCwgQ0FSUF9TSUdfTEVOKTsNCn0NCg0Kc3RhdGljIGludCBj YXJwX2NoZWNrX3BhcmFtcyhzdHJ1Y3QgY2FycF9pb2N0bF9wYXJhbXMgcCkNCnsNCglpZiAocC5z dGF0ZSAhPSBJTklUICYmIHAuc3RhdGUgIT0gQkFDS1VQICYmIHAuc3RhdGUgIT0gTUFTVEVSKQ0K CXsNCgkJbG9nKCJXcm9uZyBzdGF0ZSAlZC5cbiIsIHAuc3RhdGUpOw0KCQlyZXR1cm4gLTE7DQoJ fQ0KDQoJaWYgKCFfX2Rldl9nZXRfYnlfbmFtZShwLmRldm5hbWUpKQ0KCXsNCgkJbG9nKCJObyBz dWNoIGRldmljZSAlcy5cbiIsIHAuZGV2bmFtZSk7DQoJCXJldHVybiAtMjsNCgl9DQoNCglpZiAo cC5tZF90aW1lb3V0ID4gTUFYX01EX1RJTUVPVVQgfHwgcC5hZHZfdGltZW91dCA+IE1BWF9BRFZf VElNRU9VVCB8fA0KCSAgICAhcC5tZF90aW1lb3V0IHx8ICFwLmFkdl90aW1lb3V0KQ0KCQlyZXR1 cm4gLTM7DQoNCglyZXR1cm4gMDsNCn0NCg0Kc3RhdGljIHZvaWQgY2FycF9zZXRfc3RhdGUoc3Ry dWN0IGNhcnBfcHJpdiAqY3AsIGVudW0gY2FycF9zdGF0ZSBzdGF0ZSkNCnsNCglsb2coIiVzOiBT ZXR0aW5nIENBUlAgc3RhdGUgZnJvbSAlZCB0byAlZC5cbiIsIF9fZnVuY19fLCBjcC0+c3RhdGUs IHN0YXRlKTsNCgljcC0+c3RhdGUgPSBzdGF0ZTsNCg0KCXN3aXRjaCAoc3RhdGUpDQoJew0KCQlj YXNlIE1BU1RFUjoNCgkJCWNhcnBfY2FsbF9xdWV1ZShNQVNURVJfUVVFVUUpOw0KCQkJaWYgKCF0 aW1lcl9wZW5kaW5nKCZjcC0+YWR2X3RpbWVyKSkNCgkJCQltb2RfdGltZXIoJmNwLT5hZHZfdGlt ZXIsIGppZmZpZXMgKyBjcC0+YWR2X3RpbWVvdXQqSFopOw0KCQkJYnJlYWs7DQoJCWNhc2UgQkFD S1VQOg0KCQkJY2FycF9jYWxsX3F1ZXVlKEJBQ0tVUF9RVUVVRSk7DQoJCQlpZiAoIXRpbWVyX3Bl bmRpbmcoJmNwLT5tZF90aW1lcikpDQoJCQkJbW9kX3RpbWVyKCZjcC0+bWRfdGltZXIsIGppZmZp ZXMgKyBjcC0+bWRfdGltZW91dCpIWik7DQoJCQlicmVhazsNCgkJY2FzZSBJTklUOg0KCQkJaWYg KCF0aW1lcl9wZW5kaW5nKCZjcC0+bWRfdGltZXIpKQ0KCQkJCW1vZF90aW1lcigmY3AtPm1kX3Rp bWVyLCBqaWZmaWVzICsgY3AtPm1kX3RpbWVvdXQqSFopOw0KCQkJYnJlYWs7DQoJfQ0KfQ0KDQpz dGF0aWMgdm9pZCBjYXJwX21hc3Rlcl9kb3duKHVuc2lnbmVkIGxvbmcgZGF0YSkNCnsNCglzdHJ1 Y3QgY2FycF9wcml2ICpjcCA9IChzdHJ1Y3QgY2FycF9wcml2ICopZGF0YTsNCg0KCS8vbG9nKCIl czogc3RhdGU9JWQuXG4iLCBfX2Z1bmNfXywgY3AtPnN0YXRlKTsNCg0KCWlmIChjcC0+c3RhdGUg IT0gTUFTVEVSKQ0KCXsNCgkJaWYgKHRlc3RfYml0KENBUlBfREFUQV9BVkFJTCwgKGxvbmcgKikm Y3AtPmZsYWdzKSkNCgkJew0KCQkJaWYgKCF0aW1lcl9wZW5kaW5nKCZjcC0+bWRfdGltZXIpKQ0K CQkJCW1vZF90aW1lcigmY3AtPm1kX3RpbWVyLCBqaWZmaWVzICsgY3AtPm1kX3RpbWVvdXQqSFop Ow0KCQl9DQoJCWVsc2UNCgkJCWNhcnBfc2V0X3N0YXRlKGNwLCBNQVNURVIpOw0KCX0NCgkJCQ0K CWNsZWFyX2JpdChDQVJQX0RBVEFfQVZBSUwsIChsb25nICopJmNwLT5mbGFncyk7DQp9DQoNCnN0 YXRpYyBpbnQgY2FycF9yY3Yoc3RydWN0IHNrX2J1ZmYgKnNrYikNCnsNCglzdHJ1Y3QgaXBoZHIg KmlwaDsNCglzdHJ1Y3QgY2FycF9wcml2ICpjcCA9IGNhcnBfZGV2LT5wcml2Ow0KCXN0cnVjdCBj YXJwX2hlYWRlciAqY2g7DQoJaW50IGVyciA9IDA7DQoJdTY0IHRtcF9jb3VudGVyOw0KCXN0cnVj dCB0aW1ldmFsIGNwdHYsIGNodHY7DQoNCgkvL2xvZygiJXM6IHN0YXRlPSVkXG4iLCBfX2Z1bmNf XywgY3AtPnN0YXRlKTsNCgkNCglzcGluX2xvY2soJmNwLT5sb2NrKTsNCg0KCWlwaCA9IHNrYi0+ bmguaXBoOw0KCWNoID0gKHN0cnVjdCBjYXJwX2hlYWRlciAqKXNrYi0+ZGF0YTsNCg0KCS8vZHVt cF9jYXJwX2hlYWRlcihjaCk7DQoJDQoJaWYgKGNoLT5jYXJwX3ZlcnNpb24gIT0gY3AtPmhkci5j YXJwX3ZlcnNpb24pDQoJew0KCQlsb2coIkNBUlAgdmVyc2lvbiBtaXNtYXRjaDogcmVtb3RlPSVk LCBsb2NhbD0lZC5cbiIsDQoJCQljaC0+Y2FycF92ZXJzaW9uLCBjcC0+aGRyLmNhcnBfdmVyc2lv bik7DQoJCWNwLT5jc3RhdC52ZXJfZXJyb3JzKys7DQoJCWdvdG8gZXJyX291dF9za2JfZHJvcDsN Cgl9DQoJDQoJaWYgKGNoLT5jYXJwX3ZoaWQgIT0gY3AtPmhkci5jYXJwX3ZoaWQpDQoJew0KCQls b2coIkNBUlAgdmlydHVhbCBob3N0IGlkIG1pc21hdGNoOiByZW1vdGU9JWQsIGxvY2FsPSVkLlxu IiwNCgkJCWNoLT5jYXJwX3ZoaWQsIGNwLT5oZHIuY2FycF92aGlkKTsNCgkJY3AtPmNzdGF0LnZo aWRfZXJyb3JzKys7DQoJCWdvdG8gZXJyX291dF9za2JfZHJvcDsNCgl9DQoNCglpZiAoY2FycF9o bWFjX3ZlcmlmeShjcCwgY2gpKQ0KCXsNCgkJbG9nKCJITUFDIG1pc21hdGNoLlxuIik7DQoJCWNw LT5jc3RhdC5obWFjX2Vycm9ycysrOw0KCQlnb3RvIGVycl9vdXRfc2tiX2Ryb3A7DQoJfQ0KDQoJ dG1wX2NvdW50ZXIgPSBudG9obChjaC0+Y2FycF9jb3VudGVyWzBdKTsNCgl0bXBfY291bnRlciA9 IHRtcF9jb3VudGVyPDwzMjsNCgl0bXBfY291bnRlciArPSBudG9obChjaC0+Y2FycF9jb3VudGVy WzFdKTsNCgkNCglpZiAoY3AtPnN0YXRlID09IEJBQ0tVUCAmJiArK2NwLT5jYXJwX2Fkdl9jb3Vu dGVyICE9IHRtcF9jb3VudGVyKQ0KCXsNCgkJbG9nKCJDb3VudGVyIG1pc21hdGNoOiByZW1vdGU9 JWxsdSwgbG9jYWw9JWxsdS5cbiIsIHRtcF9jb3VudGVyLCBjcC0+Y2FycF9hZHZfY291bnRlcik7 DQoJCWNwLT5jc3RhdC5jb3VudGVyX2Vycm9ycysrOw0KCQlnb3RvIGVycl9vdXRfc2tiX2Ryb3A7 DQoJfQ0KDQoJY3B0di50dl9zZWMgPSBjcC0+aGRyLmNhcnBfYWR2YmFzZTsNCglpZiAoY3AtPmhk ci5jYXJwX2FkdmJhc2UgPCAgMjQwKQ0KCQljcHR2LnR2X3VzZWMgPSAyNDAgKiAxMDAwMDAwIC8g MjU2Ow0KCWVsc2UNCgkJY3B0di50dl91c2VjID0gY3AtPmhkci5jYXJwX2FkdnNrZXcgKiAxMDAw MDAwIC8gMjU2Ow0KCQ0KCWNodHYudHZfc2VjID0gY2gtPmNhcnBfYWR2YmFzZTsNCgljaHR2LnR2 X3VzZWMgPSBjaC0+Y2FycF9hZHZza2V3ICogMTAwMDAwMCAvIDI1NjsNCg0KCS8qbG9nKCJsb2Nh bD0lbHUuJWx1LCByZW1vdGU9JWx1LiVsdSwgbGNvdW50ZXI9JWxsdSwgcmVtY291bnRlcj0lbGx1 LCBzdGF0ZT0lZFxuIiwgDQoJCQljcHR2LnR2X3NlYywgY3B0di50dl91c2VjLA0KCQkJY2h0di50 dl9zZWMsIGNodHYudHZfdXNlYywNCgkJCWNwLT5jYXJwX2Fkdl9jb3VudGVyLCB0bXBfY291bnRl ciwNCgkJCWNwLT5zdGF0ZSk7DQoJKi8JDQoJc2V0X2JpdChDQVJQX0RBVEFfQVZBSUwsIChsb25n ICopJmNwLT5mbGFncyk7DQoNCglzd2l0Y2ggKGNwLT5zdGF0ZSkNCgl7DQoJCWNhc2UgSU5JVDoN CgkJCWlmICh0aW1ldmFsX2JlZm9yZSgmY2h0diwgJmNwdHYpKQ0KCQkJew0KCQkJCWNwLT5jYXJw X2Fkdl9jb3VudGVyID0gdG1wX2NvdW50ZXI7DQoJCQkJY2FycF9zZXRfc3RhdGUoY3AsIEJBQ0tV UCk7DQoJCQl9DQoJCQllbHNlDQoJCQl7DQoJCQkJY2FycF9zZXRfc3RhdGUoY3AsIE1BU1RFUik7 DQoJCQl9DQoJCQlicmVhazsNCgkJY2FzZSBNQVNURVI6DQoJCQlpZiAodGltZXZhbF9iZWZvcmUo JmNodHYsICZjcHR2KSkNCgkJCXsNCgkJCQljcC0+Y2FycF9hZHZfY291bnRlciA9IHRtcF9jb3Vu dGVyOw0KCQkJCWNhcnBfc2V0X3N0YXRlKGNwLCBCQUNLVVApOw0KCQkJfQ0KCQkJYnJlYWs7DQoJ CWNhc2UgQkFDS1VQOg0KCQkJaWYgKHRpbWV2YWxfYmVmb3JlKCZjcHR2LCAmY2h0dikpDQoJCQl7 DQoJCQkJY2FycF9zZXRfc3RhdGUoY3AsIE1BU1RFUik7DQoJCQl9DQoJCQlicmVhazsNCgl9DQoN CmVycl9vdXRfc2tiX2Ryb3A6DQoJa2ZyZWVfc2tiKHNrYik7DQoJc3Bpbl91bmxvY2soJmNwLT5s b2NrKTsNCg0KCXJldHVybiBlcnI7DQp9DQoNCnN0YXRpYyBpbnQgY2FycF94bWl0KHN0cnVjdCBz a19idWZmICpza2IsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQp7DQojaWYgMA0KCXN0cnVjdCBj YXJwX3ByaXYgKmNwID0gKHN0cnVjdCBjYXJwX3ByaXYgKilkZXYtPnByaXY7DQoJc3RydWN0IG5l dF9kZXZpY2Vfc3RhdHMgKnN0YXRzID0gJmNwLT5zdGF0Ow0KCXN0cnVjdCBpcGhkciAgKmlwaCA9 IHNrYi0+bmguaXBoOw0KCXU4ICAgICB0b3M7DQoJdTE2ICAgIGRmOw0KCXN0cnVjdCBydGFibGUg KnJ0Ow0KCXN0cnVjdCBuZXRfZGV2aWNlICp0ZGV2Ow0KCXUzMiAgICBkc3Q7DQoJaW50ICAgIG10 dTsNCglpbnQgZXJyOwkJCQkJCQkNCglpbnQgcGt0X2xlbiA9IHNrYi0+bGVuOwkNCglsb2coIiVz XG4iLCBfX2Z1bmNfXyk7DQoNCglza2ItPmlwX3N1bW1lZCA9IENIRUNLU1VNX05PTkU7DQoJc2ti LT5wcm90b2NvbCA9IGh0b25zKEVUSF9QX0lQKTsNCg0KCWlwX3NlbGVjdF9pZGVudChpcGgsICZy dC0+dS5kc3QsIE5VTEwpOw0KCWlwX3NlbmRfY2hlY2soaXBoKTsNCgllcnIgPSBORl9IT09LKFBG X0lORVQsIE5GX0lQX0xPQ0FMX09VVCwgc2tiLCBOVUxMLCBydC0+dS5kc3QuZGV2LCBkc3Rfb3V0 cHV0KTsNCglpZiAoZXJyID09IE5FVF9YTUlUX1NVQ0NFU1MgfHwgZXJyID09IE5FVF9YTUlUX0NO KSB7DQoJCXN0YXRzLT50eF9ieXRlcyArPSBwa3RfbGVuOw0KCQlzdGF0cy0+dHhfcGFja2V0cysr Ow0KCX0gZWxzZSB7DQoJCXN0YXRzLT50eF9lcnJvcnMrKzsNCgkJc3RhdHMtPnR4X2Fib3J0ZWRf ZXJyb3JzKys7DQoJfQ0KI2VuZGlmDQoJcmV0dXJuIDA7DQp9DQoNCnN0YXRpYyBpbnQgY2FycF9p b2N0bCAoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxICppZnIsIGludCBjbWQp DQp7DQoJaW50IGVyciA9IDA7DQoJc3RydWN0IGNhcnBfcHJpdiAqY3AgPSAoc3RydWN0IGNhcnBf cHJpdiAqKWRldi0+cHJpdjsNCglzdHJ1Y3QgbmV0X2RldmljZSAqdGRldiA9IE5VTEw7DQoJc3Ry dWN0IGNhcnBfaW9jdGxfcGFyYW1zIHA7DQoNCglsb2coIiVzXG4iLCBfX2Z1bmNfXyk7DQoNCglt ZW1zZXQoJnAsIDAsIHNpemVvZihwKSk7DQoJDQoJZXJyID0gLUVQRVJNOw0KCWlmICghY2FwYWJs ZShDQVBfTkVUX0FETUlOKSkNCgkJZ290byBlcnJfb3V0Ow0KDQoJc3dpdGNoIChjbWQpDQoJew0K I2lmIDANCgkJY2FzZSBTSU9DX1NFVElQSERSOg0KDQoJCQlsb2coIlNldHRpbmcgbmV3IGhlYWRl ci5cbiIpOw0KCQkJDQoJCQllcnIgPSAtRUZBVUxUOw0KCQkJaWYgKGNvcHlfZnJvbV91c2VyKCZp cGgsIGlmci0+aWZyX2lmcnUuaWZydV9kYXRhLCBzaXplb2YoaXBoKSkpDQoJCQkJZ290byBlcnJf b3V0Ow0KDQoJCQllcnIgPSAtRUlOVkFMOw0KCQkJaWYgKGlwaC52ZXJzaW9uICE9IDQgfHwgaXBo LnByb3RvY29sICE9IElQUFJPVE9fQ0FSUCB8fCBpcGguaWhsICE9IDUgfHwgIU1VTFRJQ0FTVChp cGguZGFkZHIpKQ0KCQkJCWdvdG8gZXJyX291dDsNCg0KCQkJc3Bpbl9sb2NrKCZjcC0+bG9jayk7 DQoJCQljYXJwX2Nsb3NlKGNwLT5kZXYpOw0KCQkJDQoJCQltZW1jcHkoJmNwLT5pcGgsICZpcGgs IHNpemVvZihpcGgpKTsNCgkJCQ0KCQkJY2FycF9vcGVuKGNwLT5kZXYpOw0KCQkJc3Bpbl91bmxv Y2soJmNwLT5sb2NrKTsNCgkJCWJyZWFrOw0KI2VuZGlmDQoJCWNhc2UgU0lPQ19TRVRDQVJQUEFS QU1TOg0KCQkJZXJyID0gLUVGQVVMVDsNCgkJCWlmIChjb3B5X2Zyb21fdXNlcigmcCwgaWZyLT5p ZnJfaWZydS5pZnJ1X2RhdGEsIHNpemVvZihwKSkpDQoJCQkJZ290byBlcnJfb3V0Ow0KDQoJCQll cnIgPSAtRUlOVkFMOw0KCQkJaWYgKGNhcnBfY2hlY2tfcGFyYW1zKHApKQ0KCQkJCWdvdG8gZXJy X291dDsNCg0KCQkJbG9nKCJTZXR0aW5nIG5ldyBDQVJQIHBhcmFtZXRlcnMuXG4iKTsNCg0KCQkJ aWYgKG1lbWNtcChwLmRldm5hbWUsIGNwLT5vZGV2LT5uYW1lLCBJRk5BTVNJWikgJiYgKHRkZXYg PSBkZXZfZ2V0X2J5X25hbWUocC5kZXZuYW1lKSkgIT0gTlVMTCkNCgkJCQljYXJwX2Nsb3NlKGNw LT5kZXYpOw0KDQoJCQlzcGluX2xvY2soJmNwLT5sb2NrKTsNCg0KCQkJaWYgKHRkZXYpDQoJCQl7 DQoJCQkJY3AtPm9kZXYtPmZsYWdzID0gY3AtPm9mbGFnczsNCgkJCQlkZXZfcHV0KGNwLT5vZGV2 KTsNCgkJCQkNCgkJCQljcC0+b2RldiAJPSB0ZGV2Ow0KCQkJCWNwLT5saW5rIAk9IGNwLT5vZGV2 LT5pZmluZGV4Ow0KCQkJCWNwLT5vZmxhZ3MgCT0gY3AtPm9kZXYtPmZsYWdzOw0KCQkJCWNwLT5v ZGV2LT5mbGFncyB8PSBJRkZfQlJPQURDQVNUIHwgSUZGX0FMTE1VTFRJOw0KCQkJfQ0KCQkJDQoJ CQljcC0+bWRfdGltZW91dCA9IHAubWRfdGltZW91dDsNCgkJCWNwLT5hZHZfdGltZW91dCA9IHAu YWR2X3RpbWVvdXQ7DQoJCQkNCgkJCWNhcnBfc2V0X3N0YXRlKGNwLCBwLnN0YXRlKTsNCgkJCW1l bWNweShjcC0+Y2FycF9wYWQsIHAuY2FycF9wYWQsIHNpemVvZihjcC0+Y2FycF9wYWQpKTsNCgkJ CW1lbWNweShjcC0+Y2FycF9rZXksIHAuY2FycF9rZXksIHNpemVvZihjcC0+Y2FycF9rZXkpKTsN CgkJCWNwLT5oZHIuY2FycF92aGlkID0gcC5jYXJwX3ZoaWQ7DQoJCQljcC0+aGRyLmNhcnBfYWR2 YmFzZSA9IHAuY2FycF9hZHZiYXNlOw0KCQkJY3AtPmhkci5jYXJwX2FkdnNrZXcgPSBwLmNhcnBf YWR2c2tldzsNCg0KCQkJc3Bpbl91bmxvY2soJmNwLT5sb2NrKTsNCgkJCWlmICh0ZGV2KQ0KCQkJ CWNhcnBfb3BlbihjcC0+ZGV2KTsNCgkJCWJyZWFrOw0KCQljYXNlIFNJT0NfR0VUQ0FSUFBBUkFN UzoNCg0KCQkJbG9nKCJEdW1waW5nIENBUlAgcGFyYW1ldGVycy5cbiIpOw0KDQoJCQlzcGluX2xv Y2soJmNwLT5sb2NrKTsNCgkJCXAuc3RhdGUgPSBjcC0+c3RhdGU7DQoJCQltZW1jcHkocC5jYXJw X3BhZCwgY3AtPmNhcnBfcGFkLCBzaXplb2YoY3AtPmNhcnBfcGFkKSk7DQoJCQltZW1jcHkocC5j YXJwX2tleSwgY3AtPmNhcnBfa2V5LCBzaXplb2YoY3AtPmNhcnBfa2V5KSk7DQoJCQlwLmNhcnBf dmhpZCA9IGNwLT5oZHIuY2FycF92aGlkOw0KCQkJcC5jYXJwX2FkdmJhc2UgPSBjcC0+aGRyLmNh cnBfYWR2YmFzZTsNCgkJCXAuY2FycF9hZHZza2V3ID0gY3AtPmhkci5jYXJwX2FkdnNrZXc7DQoJ CQlwLm1kX3RpbWVvdXQgPSBjcC0+bWRfdGltZW91dDsNCgkJCXAuYWR2X3RpbWVvdXQgPSBjcC0+ YWR2X3RpbWVvdXQ7DQoJCQltZW1jcHkocC5kZXZuYW1lLCBjcC0+b2Rldi0+bmFtZSwgc2l6ZW9m KHAuZGV2bmFtZSkpOw0KCQkJcC5kZXZuYW1lW3NpemVvZihwLmRldm5hbWUpIC0gMV0gPSAnXDAn Ow0KCQkJc3Bpbl91bmxvY2soJmNwLT5sb2NrKTsNCg0KCQkJZXJyID0gLUVGQVVMVDsNCgkJCWlm IChjb3B5X3RvX3VzZXIoaWZyLT5pZnJfaWZydS5pZnJ1X2RhdGEsICZwLCBzaXplb2YocCkpKQ0K CQkJCWdvdG8gZXJyX291dDsNCgkJCWJyZWFrOw0KCQlkZWZhdWx0Og0KCQkJZXJyID0gLUVJTlZB TDsNCgkJCWJyZWFrOw0KDQoJfQ0KCWVyciA9IDA7DQoJCQkNCmVycl9vdXQ6DQoJcmV0dXJuIGVy cjsNCn0NCg0Kc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpjYXJwX2dldF9zdGF0cyhz dHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0Kew0KCXN0cnVjdCBjYXJwX3ByaXYgKmNwID0gKHN0cnVj dCBjYXJwX3ByaXYgKilkZXYtPnByaXY7DQoJc3RydWN0IGNhcnBfc3RhdCAqY3MgPSAmY3AtPmNz dGF0Ow0KCQ0KCWxvZygiJXM6IGNyYz0lOGQsIHZlcj0lOGQsIG1lbT0lOGQsIHhtaXQ9JThkIHwg Ynl0ZXNfc2VudD0lOGRcbiIsIA0KCQkJX19mdW5jX18sIA0KCQkJY3MtPmNyY19lcnJvcnMsIGNz LT52ZXJfZXJyb3JzLCBjcy0+bWVtX2Vycm9ycywgY3MtPnhtaXRfZXJyb3JzLA0KCQkJY3MtPmJ5 dGVzX3NlbnQpOw0KCXJldHVybiAmKCgoc3RydWN0IGNhcnBfcHJpdiAqKWRldi0+cHJpdiktPnN0 YXQpOw0KfQ0KDQpzdGF0aWMgaW50IGNhcnBfY2hhbmdlX210dShzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2LCBpbnQgbmV3X210dSkNCnsNCglsb2coIiVzXG4iLCBfX2Z1bmNfXyk7DQoJZGV2LT5tdHUg PSBuZXdfbXR1Ow0KCXJldHVybiAwOw0KfQ0KDQpzdGF0aWMgdm9pZCBjYXJwX3NldHVwKHN0cnVj dCBuZXRfZGV2aWNlICpkZXYpDQp7DQoJbG9nKCIlc1xuIiwgX19mdW5jX18pOw0KCVNFVF9NT0RV TEVfT1dORVIoZGV2KTsNCglkZXYtPnVuaW5pdAkJPSBjYXJwX3VuaW5pdDsNCglkZXYtPmRlc3Ry dWN0b3IgCT0gZnJlZV9uZXRkZXY7DQoJZGV2LT5oYXJkX3N0YXJ0X3htaXQJPSBjYXJwX3htaXQ7 DQoJZGV2LT5nZXRfc3RhdHMJCT0gY2FycF9nZXRfc3RhdHM7DQoJZGV2LT5kb19pb2N0bAkJPSBj YXJwX2lvY3RsOw0KCWRldi0+Y2hhbmdlX210dQkJPSBjYXJwX2NoYW5nZV9tdHU7DQoNCglkZXYt PnR5cGUJCT0gQVJQSFJEX0VUSEVSOw0KCWRldi0+aGFyZF9oZWFkZXJfbGVuIAk9IExMX01BWF9I RUFERVI7DQoJZGV2LT5tdHUJCT0gMTUwMDsNCglkZXYtPmZsYWdzCQk9IElGRl9OT0FSUDsNCglk ZXYtPmlmbGluawkJPSAwOw0KCWRldi0+YWRkcl9sZW4JCT0gNDsNCn0NCg0Kc3RhdGljIGludCBj YXJwX29wZW4oc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCnsNCglzdHJ1Y3QgY2FycF9wcml2ICpj cCA9IChzdHJ1Y3QgY2FycF9wcml2ICopZGV2LT5wcml2Ow0KCXN0cnVjdCBmbG93aSBmbCA9IHsg Lm9pZiA9IGNwLT5saW5rLA0KCQkJICAgIC5ubF91ID0geyAuaXA0X3UgPQ0KCQkJCSAgICAgIHsg LmRhZGRyID0gY3AtPmlwaC5kYWRkciwNCgkJCQkJLnNhZGRyID0gY3AtPmlwaC5zYWRkciwNCgkJ CQkJLnRvcyA9IFJUX1RPUyhjcC0+aXBoLnRvcykgfSB9LA0KCQkJICAgIC5wcm90byA9IElQUFJP VE9fQ0FSUCB9Ow0KCXN0cnVjdCBydGFibGUgKnJ0Ow0KCQ0KCWlmIChpcF9yb3V0ZV9vdXRwdXRf a2V5KCZydCwgJmZsKSkNCgkJcmV0dXJuIC1FQUREUk5PVEFWQUlMOw0KCWRldiA9IHJ0LT51LmRz dC5kZXY7DQoJaXBfcnRfcHV0KHJ0KTsNCglpZiAoX19pbl9kZXZfZ2V0KGRldikgPT0gTlVMTCkN CgkJcmV0dXJuIC1FQUREUk5PVEFWQUlMOw0KCWNwLT5tbGluayA9IGRldi0+aWZpbmRleDsNCglp cF9tY19pbmNfZ3JvdXAoX19pbl9kZXZfZ2V0KGRldiksIGNwLT5pcGguZGFkZHIpOw0KDQoJcmV0 dXJuIDA7DQp9DQoNCnN0YXRpYyBpbnQgY2FycF9jbG9zZShzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 KQ0Kew0KCXN0cnVjdCBjYXJwX3ByaXYgKmNwID0gKHN0cnVjdCBjYXJwX3ByaXYgKilkZXYtPnBy aXY7DQoJc3RydWN0IGluX2RldmljZSAqaW5fZGV2ID0gaW5ldGRldl9ieV9pbmRleChjcC0+bWxp bmspOw0KCQ0KCWlmIChpbl9kZXYpIHsNCgkJaXBfbWNfZGVjX2dyb3VwKGluX2RldiwgY3AtPmlw aC5kYWRkcik7DQoJCWluX2Rldl9wdXQoaW5fZGV2KTsNCgl9DQoJcmV0dXJuIDA7DQp9DQoNCnN0 YXRpYyBpbnQgY2FycF9pbml0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQp7DQoJc3RydWN0IG5l dF9kZXZpY2UgKnRkZXYgPSBOVUxMOw0KCXN0cnVjdCBjYXJwX3ByaXYgKmNwOw0KCXN0cnVjdCBp cGhkciAqaXBoOw0KCWludCBobGVuID0gTExfTUFYX0hFQURFUjsNCglpbnQgbXR1ID0gMTUwMDsN Cg0KCWxvZygiJXMgLSAlc1xuIiwgX19mdW5jX18sIGRldi0+bmFtZSk7DQoJY3AgPSAoc3RydWN0 IGNhcnBfcHJpdiAqKWRldi0+cHJpdjsNCglpcGggPSAmY3AtPmlwaDsNCg0KCWlmICghaXBoLT5k YWRkciB8fCAhTVVMVElDQVNUKGlwaC0+ZGFkZHIpIHx8ICFpcGgtPnNhZGRyKQ0KCQlyZXR1cm4g LUVJTlZBTDsNCgkNCglkZXZfaG9sZChkZXYpOw0KDQoJY3AtPmRldiA9IGRldjsNCglzdHJuY3B5 KGNwLT5uYW1lLCBkZXYtPm5hbWUsIElGTkFNU0laKTsNCg0KCWlwX2V0aF9tY19tYXAoY3AtPmlw aC5kYWRkciwgZGV2LT5kZXZfYWRkcik7DQoJbWVtY3B5KGRldi0+YnJvYWRjYXN0LCAmaXBoLT5k YWRkciwgNCk7DQoNCgl7DQoJCXN0cnVjdCBmbG93aSBmbCA9IHsgLm9pZiA9IGNwLT5saW5rLA0K CQkJCSAgICAubmxfdSA9IHsgLmlwNF91ID0NCgkJCQkJICAgICAgeyAuZGFkZHIgPSBpcGgtPmRh ZGRyLA0KCQkJCQkJLnNhZGRyID0gaXBoLT5zYWRkciwNCgkJCQkJCS50b3MgPSBSVF9UT1MoaXBo LT50b3MpIH0gfSwNCgkJCQkgICAgLnByb3RvID0gSVBQUk9UT19DQVJQIH07DQoJCXN0cnVjdCBy dGFibGUgKnJ0Ow0KCQlpZiAoIWlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAmZmwpKSB7DQoJCQl0 ZGV2ID0gcnQtPnUuZHN0LmRldjsNCgkJCWlwX3J0X3B1dChydCk7DQoJCX0NCgl9DQoNCgljcC0+ b2ZsYWdzIAkJPSBjcC0+b2Rldi0+ZmxhZ3M7DQoJZGV2LT5mbGFncyAJCXw9IElGRl9CUk9BRENB U1QgfCBJRkZfQUxMTVVMVEk7DQoJY3AtPm9kZXYtPmZsYWdzIAl8PSBJRkZfQlJPQURDQVNUIHwg SUZGX0FMTE1VTFRJOw0KDQoJZGV2LT5vcGVuCQk9IGNhcnBfb3BlbjsNCglkZXYtPnN0b3AJCT0g Y2FycF9jbG9zZTsNCg0KCWlmICghdGRldiAmJiBjcC0+bGluaykNCgkJdGRldiA9IF9fZGV2X2dl dF9ieV9pbmRleChjcC0+bGluayk7DQoNCglpZiAodGRldikgew0KCQlobGVuID0gdGRldi0+aGFy ZF9oZWFkZXJfbGVuOw0KCQltdHUgPSB0ZGV2LT5tdHU7DQoJfQ0KCWRldi0+aWZsaW5rID0gY3At Pmxpbms7DQoNCglkZXYtPmhhcmRfaGVhZGVyX2xlbiA9IGhsZW47DQoJZGV2LT5tdHUgPSBtdHU7 DQoNCglyZXR1cm4gMDsNCn0NCg0Kc3RhdGljIHN0cnVjdCBpbmV0X3Byb3RvY29sIGNhcnBfcHJv dG9jb2wgPSB7DQoJLmhhbmRsZXIJPQljYXJwX3JjdiwNCgkuZXJyX2hhbmRsZXIJPQljYXJwX2Vy ciwNCn07DQoNCnN0YXRpYyB1MzIgaW5saW5lIGFkZHIydmFsKHU4IGExLCB1OCBhMiwgdTggYTMs IHU4IGE0KQ0Kew0KCXUzMiByZXQ7DQoNCglyZXQgPSAoKGExIDw8IDI0KSB8IChhMiA8PCAxNikg fCAoYTMgPDwgOCkgfCAoYTQgPDwgMCkpOw0KCQ0KCXJldHVybiBodG9ubChyZXQpOw0KfQ0KDQpz dGF0aWMgdm9pZCBjYXJwX2FkdmVydGlzZSh1bnNpZ25lZCBsb25nIGRhdGEpDQp7DQoJc3RydWN0 IGNhcnBfcHJpdiAqY3AgPSAoc3RydWN0IGNhcnBfcHJpdiAqKWRhdGE7DQoJc3RydWN0IGNhcnBf aGVhZGVyICpjaCA9ICZjcC0+aGRyOw0KCXN0cnVjdCBjYXJwX3N0YXQgKmNzID0gJmNwLT5jc3Rh dDsNCglzdHJ1Y3Qgc2tfYnVmZiAqc2tiOw0KCWludCBsZW47DQoJc3RydWN0IGV0aGhkciAqZXRo Ow0KCXN0cnVjdCBpcGhkciAqaXA7DQoJc3RydWN0IGNhcnBfaGVhZGVyICpjOw0KDQoJaWYgKGNw LT5zdGF0ZSA9PSBCQUNLVVAgfHwgIWNwLT5vZGV2KQ0KCQlyZXR1cm47DQoNCglsZW4gPSBzaXpl b2Yoc3RydWN0IGlwaGRyKSArIHNpemVvZihzdHJ1Y3QgY2FycF9oZWFkZXIpICsgc2l6ZW9mKHN0 cnVjdCBldGhoZHIpOw0KCQ0KCXNrYiA9IGFsbG9jX3NrYihsZW4gKyAyLCBHRlBfQVRPTUlDKTsN CglpZiAoIXNrYikNCgl7DQoJCWxvZygiRmFpbGVkIHRvIGFsbG9jYXRlIG5ldyBjYXJwIGZyYW1l LlxuIik7DQoJCWNzLT5tZW1fZXJyb3JzKys7DQoJCWdvdG8gb3V0Ow0KCX0NCgkNCglza2JfcmVz ZXJ2ZShza2IsIDE2KTsNCglldGggPSAoc3RydWN0IGV0aGhkciAqKSBza2JfcHVzaChza2IsIDE0 KTsNCglpcCA9IChzdHJ1Y3QgaXBoZHIgKilza2JfcHV0KHNrYiwgc2l6ZW9mKHN0cnVjdCBpcGhk cikpOw0KCWMgPSAoc3RydWN0IGNhcnBfaGVhZGVyICopc2tiX3B1dChza2IsIHNpemVvZihzdHJ1 Y3QgY2FycF9oZWFkZXIpKTsNCgkNCgltZW1zZXQoJihJUENCKHNrYiktPm9wdCksIDAsIHNpemVv ZihJUENCKHNrYiktPm9wdCkpOw0KCQ0KCWlwX2V0aF9tY19tYXAoY3AtPmlwaC5kYWRkciwgZXRo LT5oX2Rlc3QpOw0KCW1lbWNweShldGgtPmhfc291cmNlLCBjcC0+b2Rldi0+ZGV2X2FkZHIsIEVU SF9BTEVOKTsNCglldGgtPmhfcHJvdG8gCT0gaHRvbnMoRVRIX1BfSVApOw0KDQoJaXAtPmlobCAJ PSA1Ow0KCWlwLT52ZXJzaW9uIAk9IDQ7DQoJaXAtPnRvcwkJPSAwOw0KCWlwLT50b3RfbGVuCT0g aHRvbnMobGVuIC0gc2l6ZW9mKHN0cnVjdCBldGhoZHIpKTsNCglpcC0+ZnJhZ19vZmYJPSAwOw0K CWlwLT50dGwJCT0gQ0FSUF9UVEw7DQoJaXAtPnByb3RvY29sCT0gSVBQUk9UT19DQVJQOw0KCWlw LT5jaGVjawk9IDA7DQoJaXAtPnNhZGRyCT0gY3AtPmlwaC5zYWRkcjsNCglpcC0+ZGFkZHIJPSBj cC0+aXBoLmRhZGRyOw0KCWdldF9yYW5kb21fYnl0ZXMoJmlwLT5pZCwgMik7DQoJaXBfc2VuZF9j aGVjayhpcCk7DQoNCgltZW1jcHkoYywgY2gsIHNpemVvZihzdHJ1Y3QgY2FycF9oZWFkZXIpKTsN CgkNCglzcGluX2xvY2soJmNwLT5sb2NrKTsNCgljcC0+Y2FycF9hZHZfY291bnRlcisrOw0KCXNw aW5fdW5sb2NrKCZjcC0+bG9jayk7DQoNCgljaC0+Y2FycF9jb3VudGVyWzFdID0gaHRvbmwoY3At PmNhcnBfYWR2X2NvdW50ZXIgJiAweGZmZmZmZmZmKTsNCgljaC0+Y2FycF9jb3VudGVyWzBdID0g aHRvbmwoKGNwLT5jYXJwX2Fkdl9jb3VudGVyID4+IDMyKSAmIDB4ZmZmZmZmZmYpOw0KCWNhcnBf aG1hY19zaWduKGNwLCBjaCk7DQoJDQoJc2tiLT5wcm90b2NvbCAJPSBfX2NvbnN0YW50X2h0b25z KEVUSF9QX0lQKTsNCglza2ItPm1hYy5yYXcgCT0gKCh1OCAqKWlwKSAtIDE0Ow0KCXNrYi0+ZGV2 IAk9IGNwLT5vZGV2Ow0KCXNrYi0+cGt0X3R5cGUgCT0gUEFDS0VUX01VTFRJQ0FTVDsNCgkJDQoJ c3Bpbl9sb2NrX2JoKCZjcC0+b2Rldi0+eG1pdF9sb2NrKTsNCglpZiAoIW5ldGlmX3F1ZXVlX3N0 b3BwZWQoY3AtPm9kZXYpKSANCgl7DQoJCWF0b21pY19pbmMoJnNrYi0+dXNlcnMpOw0KDQoJCWlm IChjcC0+b2Rldi0+aGFyZF9zdGFydF94bWl0KHNrYiwgY3AtPm9kZXYpKSANCgkJew0KCQkJYXRv bWljX2RlYygmc2tiLT51c2Vycyk7DQoJCQljcy0+eG1pdF9lcnJvcnMrKzsNCgkJCWxvZygiSGFy ZCB4bWl0IGVycm9yLlxuIik7DQoJCX0NCgkJY3MtPmJ5dGVzX3NlbnQgKz0gbGVuOw0KCX0NCglz cGluX3VubG9ja19iaCgmY3AtPm9kZXYtPnhtaXRfbG9jayk7DQoNCgltb2RfdGltZXIoJmNwLT5h ZHZfdGltZXIsIGppZmZpZXMgKyBjcC0+YWR2X3RpbWVvdXQqSFopOw0KDQoJa2ZyZWVfc2tiKHNr Yik7DQpvdXQ6DQoJcmV0dXJuOw0KfQ0KDQpzdGF0aWMgaW50IF9faW5pdCBkZXZpY2VfY2FycF9p bml0KHZvaWQpDQp7DQoJaW50IGVycjsNCglzdHJ1Y3QgY2FycF9wcml2ICpjcDsNCg0KCXByaW50 ayhLRVJOX0lORk8gIkNBUlAgZHJpdmVyLlxuIik7DQoNCgljYXJwX2RldiA9IGFsbG9jX25ldGRl dihzaXplb2Yoc3RydWN0IGNhcnBfcHJpdiksICJjYXJwMCIsICBjYXJwX3NldHVwKTsNCglpZiAo IWNhcnBfZGV2KSANCgl7DQoJCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIGFsbG9jYXRlIENB UlAgbmV0d29yayBkZXZpY2Ugc3RydWN0dXJlLlxuIik7DQoJCXJldHVybiAtRU5PTUVNOw0KCX0N Cg0KCWlmIChpbmV0X2FkZF9wcm90b2NvbCgmY2FycF9wcm90b2NvbCwgSVBQUk9UT19DQVJQKSA8 IDApIA0KCXsNCgkJcHJpbnRrKEtFUk5fSU5GTyAiRmFpbGVkIHRvIGFkZCBDQVJQIHByb3RvY29s LlxuIik7DQoJCWVyciA9IC1FQUdBSU47DQoJCWdvdG8gZXJyX291dF9tZW1fZnJlZTsNCgl9DQoN CgljcCA9IGNhcnBfZGV2LT5wcml2Ow0KCQ0KCWNwLT5pcGguc2FkZHIgCT0gYWRkcjJ2YWwoMTAs IDAsIDAsIDMpOw0KCWNwLT5pcGguZGFkZHIgCT0gYWRkcjJ2YWwoMjI0LCAwLCAxLCAxMCk7DQoJ Y3AtPmlwaC50b3MJPSAwOw0KCWNwLT5tZF90aW1lb3V0CT0gMzsNCgljcC0+YWR2X3RpbWVvdXQJ PSAxOw0KCWNwLT5zdGF0ZQk9IElOSVQ7DQoJc3Bpbl9sb2NrX2luaXQoJmNwLT5sb2NrKTsNCg0K CWNwLT5vZGV2CT0gZGV2X2dldF9ieV9uYW1lKCJldGgwIik7DQoJaWYgKGNwLT5vZGV2KQ0KCXsN CgkJY3AtPmxpbmsJPSBjcC0+b2Rldi0+aWZpbmRleDsNCgkJY3AtPmlwaC5zYWRkcgk9IChfX2lu X2Rldl9nZXQoY3AtPm9kZXYpKS0+aWZhX2xpc3RbMF0uaWZhX2FkZHJlc3M7DQoJfQ0KDQoJbWVt c2V0KGNwLT5jYXJwX2tleSwgMSwgc2l6ZW9mKGNwLT5jYXJwX2tleSkpOw0KCWdldF9yYW5kb21f Ynl0ZXMoJmNwLT5jYXJwX2Fkdl9jb3VudGVyLCA4KTsNCgkNCglnZXRfcmFuZG9tX2J5dGVzKCZj cC0+aGRyLmNhcnBfYWR2c2tldywgMSk7DQoJZ2V0X3JhbmRvbV9ieXRlcygmY3AtPmhkci5jYXJw X2FkdmJhc2UsIDEpOw0KDQoJZHVtcF9hZGRyX2luZm8oY3ApOw0KDQoJaW5pdF90aW1lcigmY3At Pm1kX3RpbWVyKTsNCgljcC0+bWRfdGltZXIuZXhwaXJlcwk9IGppZmZpZXMgKyBjcC0+bWRfdGlt ZW91dCpIWjsNCgljcC0+bWRfdGltZXIuZGF0YQk9ICh1bnNpZ25lZCBsb25nKWNwOw0KCWNwLT5t ZF90aW1lci5mdW5jdGlvbgk9IGNhcnBfbWFzdGVyX2Rvd247DQoNCglpbml0X3RpbWVyKCZjcC0+ YWR2X3RpbWVyKTsNCgljcC0+YWR2X3RpbWVyLmV4cGlyZXMJPSBqaWZmaWVzICsgY3AtPmFkdl90 aW1lb3V0KkhaOw0KCWNwLT5hZHZfdGltZXIuZGF0YQk9ICh1bnNpZ25lZCBsb25nKWNwOw0KCWNw LT5hZHZfdGltZXIuZnVuY3Rpb24JPSBjYXJwX2FkdmVydGlzZTsNCg0KCWNhcnBfZGV2LT5pbml0 ID0gY2FycF9pbml0Ow0KDQoJY3AtPnRmbSA9IGNyeXB0b19hbGxvY190Zm0oInNoYTEiLCAwKTsN CglpZiAoIWNwLT50Zm0pDQoJew0KCQlwcmludGsoS0VSTl9FUlIgIkZhaWxlZCB0byBhbGxvY2F0 ZSBTSEExIHRmbS5cbiIpOw0KCQllcnIgPSAtRUlOVkFMOw0KCQlnb3RvIGVycl9vdXRfZGVsX3By b3RvY29sOw0KCX0NCg0KCWR1bXBfaG1hY19wYXJhbXMoY3ApOw0KDQoJZXJyID0gY2FycF9pbml0 X3F1ZXVlcygpOw0KCWlmIChlcnIpDQoJCWdvdG8gZXJyX291dF9jcnlwdG9fZnJlZTsNCg0KCWlm ICgoZXJyID0gcmVnaXN0ZXJfbmV0ZGV2KGNhcnBfZGV2KSkpDQoJCWdvdG8gZXJyX291dF9maW5p X2NhcnBfcXVldWVzOw0KDQoJYWRkX3RpbWVyKCZjcC0+bWRfdGltZXIpOw0KDQoJcmV0dXJuIGVy cjsNCg0KZXJyX291dF9maW5pX2NhcnBfcXVldWVzOg0KCWNhcnBfZmluaV9xdWV1ZXMoKTsNCmVy cl9vdXRfY3J5cHRvX2ZyZWU6DQoJY3J5cHRvX2ZyZWVfdGZtKGNwLT50Zm0pOw0KZXJyX291dF9k ZWxfcHJvdG9jb2w6DQoJaW5ldF9kZWxfcHJvdG9jb2woJmNhcnBfcHJvdG9jb2wsIElQUFJPVE9f Q0FSUCk7DQplcnJfb3V0X21lbV9mcmVlOg0KCWZyZWVfbmV0ZGV2KGNhcnBfZGV2KTsNCg0KCXJl dHVybiBlcnI7DQp9DQoNCnZvaWQgZGV2aWNlX2NhcnBfZmluaSh2b2lkKQ0Kew0KCXN0cnVjdCBj YXJwX3ByaXYgKmNwID0gY2FycF9kZXYtPnByaXY7DQoNCgljYXJwX2ZpbmlfcXVldWVzKCk7DQoN CglpZiAoaW5ldF9kZWxfcHJvdG9jb2woJmNhcnBfcHJvdG9jb2wsIElQUFJPVE9fQ0FSUCkgPCAw KQ0KCQlwcmludGsoS0VSTl9JTkZPICJGYWlsZWQgdG8gcmVtb3ZlIENBUlAgcHJvdG9jb2wgaGFu ZGxlci5cbiIpOw0KCQ0KCWNyeXB0b19mcmVlX3RmbShjcC0+dGZtKTsNCg0KCXVucmVnaXN0ZXJf bmV0ZGV2KGNhcnBfZGV2KTsNCn0NCg0KbW9kdWxlX2luaXQoZGV2aWNlX2NhcnBfaW5pdCk7DQpt b2R1bGVfZXhpdChkZXZpY2VfY2FycF9maW5pKTsNCk1PRFVMRV9MSUNFTlNFKCJHUEwiKTsNCk== --=-zMMMLADPc6OCZZ3l3ocw Content-Disposition: attachment; filename=carp.h Content-Type: text/x-chdr; name=carp.h; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwLmgNCiAqIA0KICogMjAwNCBDb3B5cmlnaHQgKGMpIEV2Z2VuaXkgUG9seWFr b3YgPGpvaG5wb2xAMmthLm1pcHQucnU+DQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KICogDQog KiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg YW5kL29yIG1vZGlmeQ0KICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQ dWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCiAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5k YXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQogKiAoYXQgeW91ciBv cHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmli dXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KICogYnV0IFdJVEhPVVQg QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YNCiAqIE1F UkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0 aGUNCiAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQogKg0K ICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UNCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRv IHRoZSBGcmVlIFNvZnR3YXJlDQogKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2Us IFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQogKg0KICovDQoNCiNpZm5k ZWYgX19DQVJQX0gNCiNkZWZpbmUgX19DQVJQX0gNCg0KI2luY2x1ZGUgPGxpbnV4L25ldGRldmlj ZS5oPg0KI2luY2x1ZGUgPGxpbnV4L2lmLmg+DQojaW5jbHVkZSA8bGludXgvaXAuaD4NCg0KI2lu Y2x1ZGUgImNhcnBfaW9jdGwuaCINCg0KI2RlZmluZSBJUFBST1RPX0NBUlAgCQkxMTINCiNkZWZp bmUJQ0FSUF9WRVJTSU9OCQkyDQojZGVmaW5lIENBUlBfVFRMCQkyNTUNCiNkZWZpbmUJQ0FSUF9T SUdfTEVOCQkyMA0KDQovKg0KICogY2FycF9wcml2LT5mbGFncyBkZWZpbml0aW9ucy4NCiAqLw0K I2RlZmluZSBDQVJQX0RBVEFfQVZBSUwJCSgxPDwwKQ0KDQpzdHJ1Y3QgY2FycF9oZWFkZXIgDQp7 DQojaWYgZGVmaW5lZChfX0xJVFRMRV9FTkRJQU5fQklURklFTEQpDQoJdTgJY2FycF90eXBlOjQs DQoJCWNhcnBfdmVyc2lvbjo0Ow0KI2VsaWYgZGVmaW5lZCAoX19CSUdfRU5ESUFOX0JJVEZJRUxE KQ0KCXU4CWNhcnBfdmVyc2lvbjo0LA0KCQljYXJwX3R5cGU6NDsNCiNlbHNlDQojZXJyb3IJIlBs ZWFzZSBmaXggPGFzbS9ieXRlb3JkZXIuaD4iDQojZW5kaWYNCgl1OAljYXJwX3ZoaWQ7DQoJdTgJ Y2FycF9hZHZza2V3Ow0KCXU4CWNhcnBfYXV0aGxlbjsNCgl1OAljYXJwX3BhZDE7DQoJdTgJY2Fy cF9hZHZiYXNlOwkNCgl1MTYJY2FycF9ja3N1bTsNCgl1MzIJY2FycF9jb3VudGVyWzJdOw0KCXU4 CWNhcnBfbWRbQ0FSUF9TSUdfTEVOXTsNCn07DQoNCnN0cnVjdCBjYXJwX3N0YXQNCnsNCgl1MzIJ Y3JjX2Vycm9yczsNCgl1MzIJdmVyX2Vycm9yczsNCgl1MzIJdmhpZF9lcnJvcnM7DQoJdTMyCWht YWNfZXJyb3JzOw0KCXUzMgljb3VudGVyX2Vycm9yczsNCg0KCXUzMgltZW1fZXJyb3JzOw0KCXUz Mgl4bWl0X2Vycm9yczsNCg0KCXUzMglieXRlc19zZW50Ow0KfTsNCg0Kc3RydWN0IGNhcnBfcHJp dg0Kew0KCXN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzCXN0YXQ7DQoJc3RydWN0IG5ldF9kZXZpY2UJ KmRldiwgKm9kZXY7DQoJY2hhciAJCQluYW1lW0lGTkFNU0laXTsNCg0KCWludAkJCWxpbmssIG1s aW5rOw0KCXN0cnVjdCBpcGhkcgkJaXBoOw0KDQoJdTMyCQkJbWRfdGltZW91dCwgYWR2X3RpbWVv dXQ7DQoJc3RydWN0IHRpbWVyX2xpc3QJbWRfdGltZXIsIGFkdl90aW1lcjsNCg0KCWVudW0gY2Fy cF9zdGF0ZQkJc3RhdGU7DQoJc3RydWN0IGNhcnBfaGVhZGVyIAloZHI7DQoJc3RydWN0IGNhcnBf c3RhdAljc3RhdDsNCg0KCXU4CQkJY2FycF9rZXlbQ0FSUF9LRVlfTEVOXTsNCgl1OAkJCWNhcnBf cGFkW0NBUlBfSE1BQ19QQURfTEVOXTsNCglzdHJ1Y3QgY3J5cHRvX3RmbSAJKnRmbTsNCg0KCXU2 NAkJCWNhcnBfYWR2X2NvdW50ZXI7DQoNCglzcGlubG9ja190CQlsb2NrOw0KDQoJdTMyCQkJZmxh Z3M7DQoJdW5zaWduZWQgc2hvcnQJCW9mbGFnczsNCn07DQoNCiNlbmRpZiAvKiBfX0NBUlBfSCAq Lw0K --=-zMMMLADPc6OCZZ3l3ocw Content-Disposition: attachment; filename=carp_ioctl.h Content-Type: text/x-chdr; name=carp_ioctl.h; charset=koi8-r Content-Transfer-Encoding: base64 LyoNCiAqIAljYXJwX2lvY3RsLmgNCiAqIA0KICogMjAwNCBDb3B5cmlnaHQgKGMpIEV2Z2VuaXkg UG9seWFrb3YgPGpvaG5wb2xAMmthLm1pcHQucnU+DQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0K ICogDQogKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1 dGUgaXQgYW5kL29yIG1vZGlmeQ0KICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCiAqIHRoZSBGcmVlIFNvZnR3YXJl IEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQogKiAoYXQg eW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBk aXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KICogYnV0IFdJ VEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YN CiAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g IFNlZSB0aGUNCiAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMu DQogKg0KICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UNCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQogKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUg UGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQogKg0KICovDQoN CiNpZm5kZWYgX19DQVJQX0lPQ1RMX0gNCiNkZWZpbmUgX19DQVJQX0lPQ1RMX0gNCg0KI2luY2x1 ZGUgPGxpbnV4L3NvY2tpb3MuaD4NCg0KI2RlZmluZQlDQVJQX0tFWV9MRU4JCTIwDQojZGVmaW5l CUNBUlBfSE1BQ19QQURfTEVOCTY0DQoNCiNkZWZpbmUgTUFYX01EX1RJTUVPVVQJCTUNCiNkZWZp bmUgTUFYX0FEVl9USU1FT1VUCQk1DQoNCmVudW0gY2FycF9zdGF0ZSB7SU5JVCA9IDAsIE1BU1RF UiwgQkFDS1VQfTsNCg0KZW51bSBjYXJwX2lvY3RscyANCnsNCglTSU9DX1NFVENBUlBQQVJBTVMg PSBTSU9DREVWUFJJVkFURSwNCglTSU9DX0dFVENBUlBQQVJBTVMsDQp9Ow0KDQpzdHJ1Y3QgY2Fy cF9pb2N0bF9wYXJhbXMNCnsNCglfX3U4CQljYXJwX2FkdnNrZXc7DQoJX191OAkJY2FycF9hZHZi YXNlOw0KCV9fdTgJCWNhcnBfdmhpZDsNCglfX3U4IAkJY2FycF9rZXlbQ0FSUF9LRVlfTEVOXTsN CglfX3U4IAkJY2FycF9wYWRbQ0FSUF9ITUFDX1BBRF9MRU5dOw0KCWVudW0gY2FycF9zdGF0ZQlz dGF0ZTsNCgljaGFyIAkJZGV2bmFtZVtJRk5BTVNJWl07DQoJX191MzIJCW1kX3RpbWVvdXQ7DQoJ X191MzIJCWFkdl90aW1lb3V0Ow0KCQ0KfTsNCg0KI2VuZGlmIC8qIF9fQ0FSUF9JT0NUTF9IICov DQo= --=-zMMMLADPc6OCZZ3l3ocw-- --=-aENk32xTOCLiPN2oivF9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9ohjIKTPhE+8wY0RAqmCAJ4ipYTj3GiAqvn5Wj/pfJ9e0vSvCgCdGh6Q g5OjGinV7NyeHolfgV7lVmY= =jZay -----END PGP SIGNATURE----- --=-aENk32xTOCLiPN2oivF9-- From hadi@cyberus.ca Thu Jul 15 07:44:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 07:44:34 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FEiRVK016187 for ; Thu, 15 Jul 2004 07:44:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Bl7TD-0000Pr-LR for netdev@oss.sgi.com; Thu, 15 Jul 2004 10:44:23 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bl7T9-0004HZ-UI; Thu, 15 Jul 2004 10:44:20 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089898595.6114.866.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089902654.1029.23.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Jul 2004 10:44:14 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6959 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 Evgeniy, Why do you need to put this stuff in the kernel? This should be implemented just the same way as VRRP was - in user space. BTW, is there a spec for this protocol or its one of those things where you have to follow Yodas advice? cheers, jamal From dlstevens@us.ibm.com Thu Jul 15 07:49:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 07:49:35 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FEnTA5016538 for ; Thu, 15 Jul 2004 07:49:29 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6FEnJtf244118; Thu, 15 Jul 2004 10:49:19 -0400 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6FEnFlG202972; Thu, 15 Jul 2004 08:49:18 -0600 In-Reply-To: <20040715092715.GA23131@wotan.suse.de> To: Andi Kleen Cc: netdev@oss.sgi.com, "Rusty Russell (IBM)" MIME-Version: 1.0 Subject: Re: Fragment ID wrap workaround (read-only, untested). X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 15 Jul 2004 07:49:13 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 07/15/2004 08:49:18, Serialize complete at 07/15/2004 08:49:18 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 6960 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Andi Kleen wrote on 07/15/2004 02:27:17 AM: > Won't that make the worst case behaviour on a congested link much worse? > e.g. consider a very congested link with variable RTTs. Or a > link that works relatively smoothly and suddenly the RTT increases. I know what you mean here, but just to be precise, this isn't an RTT estimator, but an estimator for the time to receive a complete set of fragments. And, of course, it'd need to be scaled to a (potential) max-sized packet, since the number of fragments isn't known in advance, and could be larger. Better multiple the time-out for a 4K reassembly by 16, in case you get a 64K datagram next. > Yes, running fragmentation over those is not a good idea, but > still it should not be made worse. Delivery to the user of incorrect data is the problem, and, no, it doesn't make that worse. :-) The scenario, to make it clear for everyone, is a small loss rate on a fast network leads to reassembling packets with the same IP ID that are not the same packet when the ID wraps before the frag queue timer has expired. If you're blasting away on a gigabit network (or faster) and you drop one fragment (or more) from a packet you've received, that frag queue will be there 65536 packets later when you reuse the same ID for a different packet. I think that works out to be 7 secs or so at full rate-- well within the 1-4 minute typical frag queue timer on most systems. When the second packet arrives, if it's big enough that the missing frag offsets can fulfill reassembly, it'll use them. So, 100% of the time when sending same-sized packets, like NFS mostly does, and you lose 1 fragment, you'll reassemble garbage when the IP ID wraps (well before the frag queue expires). And the checksum will pass anyway on average about 1/64K of the time. If you send at full rate and drop, say, 100 frags a second, it doesn't take too long to get a Frankenpacket-- reassembled from parts of others. :-) That's the problem the timer idea is trying to solve, and a higher loss rate here is acceptable-- the checksum only fails to catch the problem 1/64K of the time, so you probably have a relatively high loss rate to start with when it's occurring. > Your variable timer even with a smoothing algorithm in the RTT > estimator will expire far too early and very likely drop a lot more > fragments in this scenario than before. Not necessarily, because it doesn't at all have to be a "near" estimate, the way TCP is trying to make it. It can solve the problem by taking a close estimate to the actual time and then using a frag timeout that's 10 times bigger. As long as the frag timeout isn't thousands of times too large (as it is now), IP ID wrap can't happen before you dump the frag queue-- the whole point. > In general handling a link where the RTT increases would seem > tricky with your scheme. Unlike TCP there is no retransmit > to save the day. In the particular case (NFS over UDP), there is both a retransmit (done by RPC) and significant loss rate to start with. As long as the time-out is conservative, I don't think this has to affect other cases significantly. +-DLS From cfriesen@nortelnetworks.com Thu Jul 15 08:18:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 08:18:13 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FFI8nm017442 for ; Thu, 15 Jul 2004 08:18:08 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6FFHxH22270 for ; Thu, 15 Jul 2004 11:17:59 -0400 (EDT) Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTBT9W; Thu, 15 Jul 2004 11:18:00 -0400 Message-ID: <40F6A027.5050201@nortelnetworks.com> Date: Thu, 15 Jul 2004 11:17:59 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: netstat not tracking all packets Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev We just ran into an issue where incoming IP packets were being dropped due to socket buffer overflow, but there were no statistics showing it. Increasing the buffer size made the problems go away, but it was frustrating to not have accurate statistics. After a bit of digging, I found the following path: raw_v4_input skb_clone raw_rcv(sk, clone) raw_rcv_skb If the socket rx buffer is full raw_rcv_skb then drops the packet without incrementing any counters. There's a FIXME comment in there that looks like its been there for two years and counting. Anyone have a fix for this, or know of other areas where the counters are not accurate? Chris From johnpol@2ka.mipt.ru Thu Jul 15 08:22:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 08:22:38 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FFMUoM020909 for ; Thu, 15 Jul 2004 08:22:31 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6FFM5Yk031914; Thu, 15 Jul 2004 19:22:07 +0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: jamal Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089902654.1029.23.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hDCZSjtMqGKyhOIxok8K" Organization: MIPT Message-Id: <1089905244.6114.887.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 15 Jul 2004 19:27:24 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-hDCZSjtMqGKyhOIxok8K Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-15 at 18:44, jamal wrote: > Evgeniy, >=20 > Why do you need to put this stuff in the kernel? > This should be implemented just the same way as VRRP was - in user > space. Hmm... Just because i think it works better being implemented in the kernel? :) I don't think it is a good answer thought. It is faster, it is more flexible, it has access to kernel space... > BTW, is there a spec for this protocol or its one of those things where > you have to follow Yodas advice? Exactly :) Here are all links I found: http://www.countersiege.com/doc/pfsync-carp/ http://www.openbsd.org/cgi-bin/man.cgi?query=3Dcarp&apropos=3D0&sektion=3D0= &manpath=3DOpenBSD+Current&arch=3Di386&format=3Dhtml#SEE+ALSO http://www.openbsd.org/lyrics.html VRRP2 spec. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_carp.c I do want this to be in the mainline kernel, but actually I even don't think anyone will apply it. It is too special stuff for generic kernel, it has reserved 112 vrrp protocol number and so on... So if developers decide not to include or even not to discuss this cruft I will not beat myself by my heels. :) It just works as expected, it is reliable and simple. And it does it's work, so HA people would like it. > cheers, > jamal --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-hDCZSjtMqGKyhOIxok8K Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9qJcIKTPhE+8wY0RAmZvAJ99AOTG7YFuRAVvbZU7c38KJZ6PEgCfXGKX 0Hw/Z6O705yPJRI+D5w9Ag0= =AdlC -----END PGP SIGNATURE----- --=-hDCZSjtMqGKyhOIxok8K-- From johnpol@2ka.mipt.ru Thu Jul 15 08:50:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 08:50:46 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FFocXm021617 for ; Thu, 15 Jul 2004 08:50:40 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6FFoHf2000406; Thu, 15 Jul 2004 19:50:20 +0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: jamal Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089905244.6114.887.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-O+AOsa057WIIMHb6aivy" Organization: MIPT Message-Id: <1089906936.6114.904.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 15 Jul 2004 19:55:36 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-O+AOsa057WIIMHb6aivy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-15 at 19:27, Evgeniy Polyakov wrote: > On Thu, 2004-07-15 at 18:44, jamal wrote: > > Evgeniy, > >=20 > > Why do you need to put this stuff in the kernel? > > This should be implemented just the same way as VRRP was - in user > > space. >=20 > Hmm... > Just because i think it works better being implemented in the kernel? :) > I don't think it is a good answer thought. >=20 > It is faster, it is more flexible, it has access to kernel space... Just an addition[from private e-mail]: > would it be possible to do load balancing at the network level with a=20 > userland only implementation?=20 >=20 > OpenBSD's CARP does load balancing through Source Hashing (SH), which UCARP=20 > lacks support for. Userspace can't in principle. Current kernel implementation can't too, but it can. In principle. But better implementation should use both carp and ct_sync and some load balancing code, which should link ct_sync and carp. OpenBSD has one disadvantage in this regard: it is not modular, so their carp hooks live in if_ether.c. In Linux we just need to use connection tracking. ct_sync makes not exactly it but close to the idea. > > BTW, is there a spec for this protocol or its one of those things where > > you have to follow Yodas advice? >=20 > Exactly :) > Here are all links I found: > http://www.countersiege.com/doc/pfsync-carp/ > http://www.openbsd.org/cgi-bin/man.cgi?query=3Dcarp&apropos=3D0&sektion= =3D0&manpath=3DOpenBSD+Current&arch=3Di386&format=3Dhtml#SEE+ALSO > http://www.openbsd.org/lyrics.html > VRRP2 spec. > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_carp.c >=20 >=20 > I do want this to be in the mainline kernel, but actually I even don't > think anyone will apply it. > It is too special stuff for generic kernel, it has reserved 112 vrrp > protocol number and so on... > So if developers decide not to include or even not to discuss this cruft > I will not beat myself by my heels. :) >=20 > It just works as expected, it is reliable and simple. > And it does it's work, so HA people would like it. >=20 > > cheers, > > jamal --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-O+AOsa057WIIMHb6aivy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9qj3IKTPhE+8wY0RAmHfAJ42utg9iVc1Xda9ORYQwm2cPSPNagCdEmDZ XazOtvHSPIDn8+XEzMEbfqw= =Ul2U -----END PGP SIGNATURE----- --=-O+AOsa057WIIMHb6aivy-- From hadi@cyberus.ca Thu Jul 15 09:07:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:07:23 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FG7GxP022851 for ; Thu, 15 Jul 2004 09:07:16 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Bl8lM-00014x-Q9 for netdev@oss.sgi.com; Thu, 15 Jul 2004 12:07:12 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bl8lJ-00009l-Mf; Thu, 15 Jul 2004 12:07:10 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089905244.6114.887.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089907622.1027.48.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Jul 2004 12:07:02 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6964 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 Thu, 2004-07-15 at 11:27, Evgeniy Polyakov wrote: > On Thu, 2004-07-15 at 18:44, jamal wrote: > > Evgeniy, > > > > Why do you need to put this stuff in the kernel? > > This should be implemented just the same way as VRRP was - in user > > space. > > Hmm... > Just because i think it works better being implemented in the kernel? :) > I don't think it is a good answer thought. > > It is faster, it is more flexible, it has access to kernel space... Yeah, I know ;-> and probably thats what the opnebsd people did. I still think it should live in user space. This should apply to anything thats control related because such things tend to be continoulsy enrichned with features. ARP unfortunately is in there; one of my pet perpetual projects is to totaly rip it off. Theres already hooks to deliver to user space today and Alexey has a daemon for it, not sure how widely used it is. > > BTW, is there a spec for this protocol or its one of those things where > > you have to follow Yodas advice? > > Exactly :) > Here are all links I found: Thank you. I think a better idea would be to implement a sync message within CARP instead of that pfsync app doing its own thing. Unless i misread, pfsync seems to be a separate app. This way more than one app can use it via the CARP daemon in user space to sync state of their choice (with whatever pfsync does being one of many). This is an example of a rich application and further justification for it to live in user space. > I do want this to be in the mainline kernel, but actually I even don't > think anyone will apply it. > > It is too special stuff for generic kernel, it has reserved 112 vrrp > protocol number and so on... > So if developers decide not to include or even not to discuss this cruft > I will not beat myself by my heels. :) > > It just works as expected, it is reliable and simple. > And it does it's work, so HA people would like it. It is valuable, just doesnt belong to the kernel. BTW, i saw some claim that this is patent-free as opposed to VRRP? I do hope it takes off. What exactly is the patent issue that was at stake? I couldnt tell from the song lyrics ;-> One valuable thing that could be done is while still avoiding any patent issues make it interop with VRRP. cheers, jamal From margitsw@t-online.de Thu Jul 15 09:15:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:15:55 -0700 (PDT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGFkkN023469 for ; Thu, 15 Jul 2004 09:15:47 -0700 Received: from fwd06.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1Bl87j-00040G-05; Thu, 15 Jul 2004 17:26:15 +0200 Received: from roglap.local (Srcw9EZcweCvfsFZApuc20i0pcIZpJb8VkzKASXTUjJqL33D53E1Qp@[217.226.122.136]) by fwd06.sul.t-online.com with esmtp id 1Bl87V-1eQzZ20; Thu, 15 Jul 2004 17:26:01 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] pci.ids update for Prism GT devices Date: Thu, 15 Jul 2004 17:19:08 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_sBq9AFG0NM8Y7f4" Message-Id: <200407151719.09061.margitsw@t-online.de> X-ID: Srcw9EZcweCvfsFZApuc20i0pcIZpJb8VkzKASXTUjJqL33D53E1Qp X-archive-position: 6965 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_sBq9AFG0NM8Y7f4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-15 Margit Schubert-While * Update pci.ids for known Prism54 GT devices. Jeff, this has been passed to the pci.ids project. I am not sure if this should go through you/netdev. (Loosely related) If not please pass on to LKML. The one replacement of 17cf:0014 is correct; the devices originate with Z-Com; others are clones/repackages. (of which there are several) Margit --Boundary-00=_sBq9AFG0NM8Y7f4 Content-Type: text/x-diff; charset="us-ascii"; name="kernpciids.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kernpciids.patch" diff -Naur linux-2.6.8-01/drivers/pci/pci.ids linux-2.6.8-02/drivers/pci/pci.ids --- linux-2.6.8-01/drivers/pci/pci.ids 2004-07-12 19:31:57.000000000 +0200 +++ linux-2.6.8-02/drivers/pci/pci.ids 2004-07-15 07:32:33.000000000 +0200 @@ -4905,12 +4905,24 @@ 3873 Prism 2.5 Wavelan chipset 1186 3501 DWL-520 Wireless PCI Adapter 1186 3700 DWL-520 Wireless PCI Adapter, Rev E1 + 1385 4105 MA311 802.11b wireless adapter 1668 0414 HWP01170-01 802.11b PCI Wireless Adapter 16a5 1601 AIR.mate PC-400 PCI Wireless LAN Adapter 1737 3874 WMP11 Wireless 802.11b PCI Adapter 8086 2513 Wireless 802.11b MiniPCI Adapter + 3886 Intersil ISL3886 [Prism Javelin/Prism Xbow] + 17cf 0037 Z-Com XG-901 and clones Wireless Adapter 3890 Intersil ISL3890 [Prism GT/Prism Duette] - 17cf 0014 Ovislink WL-5400PCM, Prism GT + 10b8 2802 SMC2802W Wireless PCI Adapter + 10b8 2835 SMC2835W Wireless Cardbus Adapter + 10b8 a835 SMC2835W V2 Wireless Cardbus Adapter + 1113 ee03 SMC2802W V2 Wireless PCI Adapter + 1186 3202 D-Link DWL-G650 A1 Wireless Adapter + 1259 c104 Corega CG-WLCB54GT Wireless Adapter + 1385 4800 Netgear WG511 Wireless Adapter + 16a5 1605 ALLNET ALL0271 Wireless PCI Adapter + 17cf 0014 Z-Com XG-600 and clones Wireless Adapter + 17cf 0020 Z-Com XG-900 and clones Wireless Adapter 8130 HMP8130 NTSC/PAL Video Decoder 8131 HMP8131 NTSC/PAL Video Decoder 1261 Matsushita-Kotobuki Electronics Industries, Ltd. --Boundary-00=_sBq9AFG0NM8Y7f4-- From hadi@cyberus.ca Thu Jul 15 09:28:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:28:38 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGSWnN023977 for ; Thu, 15 Jul 2004 09:28:32 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:57544 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 17:28:30 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Bl95t-00031u-Ta for netdev@linux-mips.org; Thu, 15 Jul 2004 12:28:25 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bl95r-0003BX-7D; Thu, 15 Jul 2004 12:28:23 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089906936.6114.904.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089908900.1027.77.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Jul 2004 12:28:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6966 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 Thu, 2004-07-15 at 11:55, Evgeniy Polyakov wrote: > > OpenBSD's CARP does load balancing through Source Hashing (SH), which > UCARP > > lacks support for. > > Userspace can't in principle. > Current kernel implementation can't too, but it can. In principle. Easy with current traffic control extensions. We need an action written for this. User space dameon controls it. cheers, jamal From ak@suse.de Thu Jul 15 09:30:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:30:51 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGUi1L024293 for ; Thu, 15 Jul 2004 09:30:45 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 2430F8D93BA; Thu, 15 Jul 2004 18:27:37 +0200 (CEST) Date: Thu, 15 Jul 2004 18:27:35 +0200 From: Andi Kleen To: David Stevens Cc: netdev@oss.sgi.com, rusty@au1.ibm.com Subject: Re: Fragment ID wrap workaround (read-only, untested). Message-Id: <20040715182735.3787c8b1.ak@suse.de> In-Reply-To: References: <20040715092715.GA23131@wotan.suse.de> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6967 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, 15 Jul 2004 07:49:13 -0700 David Stevens wrote: > > > Yes, running fragmentation over those is not a good idea, but > > still it should not be made worse. > > Delivery to the user of incorrect data is the problem, and, no, it doesn't > make that worse. :-) The scenario, to make it clear for everyone, is a] The data corruption problem only starts to become a real issue at Gigabit Speeds and faster. Normally such congested links are much slower > small loss rate on a fast network leads to reassembling packets with the > same IP ID that are not the same packet when the ID wraps before the frag > queue timer has expired. If you're blasting away on a gigabit network (or > faster) and you drop one fragment (or more) from a packet you've received, > that frag queue will be there 65536 packets later when you reuse the same > ID > for a different packet. I think that works out to be 7 secs or so at full > rate-- well within the 1-4 minute typical frag queue timer on most > systems. [...] I'm well aware of the Gigabit+ NFS problem. My standard suggestion to solve it is to just get rid of NFS over UDP - it always was a bad idea. My point was just that you're concentrating on that one only, but you're potentially causing more problems for slow links. The stack has to work well both for slow and fast links though. > > > In general handling a link where the RTT increases would seem > > tricky with your scheme. Unlike TCP there is no retransmit > > to save the day. > > In the particular case (NFS over UDP), there is both a retransmit (done > by RPC) and significant loss rate to start with. As long as the time-out > is conservative, I don't think this has to affect other cases > significantly. NFS over UDP is just a bad idea. Don't do it. NFS over TCP works fine these days and should be the prefered choice for everybody. I don't really see the point of risking problems with slower links just to fix a fundamentally flawed protocol. And you cannot rely on all UDP based protocols doing this as well. -Andi From ak@muc.de Thu Jul 15 09:41:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:41:59 -0700 (PDT) Received: from zero.aec.at (Squatol_Johnes@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGfmRc024775 for ; Thu, 15 Jul 2004 09:41:54 -0700 Received: from averell.firstfloor.org.muc.de (Orrin_Goof@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i6FGdMc10491; Thu, 15 Jul 2004 18:39:23 +0200 To: netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com Subject: [PATCH] Drop ISA dependencies from IRDA drivers cc: the_nihilant@autistici.org From: Andi Kleen Date: Thu, 15 Jul 2004 18:39:21 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6968 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev http://bugme.osdl.org/show_bug.cgi?id=3077 Some IRDA chipsets currently don't work on x86-64, because they're dependent on CONFIG_ISA and x86-64 doesn't set this. CONFIG_ISA means real ISA slots, and I doubt these chips come on real ISA cards, so I just removed the bogus dependency. Please apply. -Andi diff -u linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig --- linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o 2004-07-12 06:09:05.000000000 +0200 +++ linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig 2004-07-15 18:33:48.000000000 +0200 @@ -310,7 +310,7 @@ config NSC_FIR tristate "NSC PC87108/PC87338" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build support for the NSC PC87108 and PC87338 IrDA chipsets. This driver supports SIR, @@ -321,7 +321,7 @@ config WINBOND_FIR tristate "Winbond W83977AF (IR)" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build IrDA support for the Winbond W83977AF super-io chipset. This driver should be used for the IrDA @@ -347,7 +347,7 @@ config SMC_IRCC_FIR tristate "SMSC IrCC (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the SMC Infrared Communications Controller. It is used in a wide variety of @@ -357,7 +357,7 @@ config ALI_FIR tristate "ALi M5123 FIR (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the ALi M5123 FIR Controller. The ALi M5123 FIR Controller is embedded in ALi M1543C, @@ -385,7 +385,7 @@ config VIA_FIR tristate "VIA VT8231/VT1211 SIR/MIR/FIR" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build support for the VIA VT8231 and VIA VT1211 IrDA controllers, found on the motherboards using From jheffner@psc.edu Thu Jul 15 09:52:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:52:36 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGqM19025265 for ; Thu, 15 Jul 2004 09:52:23 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i6FGOf8L020280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Jul 2004 12:24:41 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i6FGOj3m006834; Thu, 15 Jul 2004 12:24:45 -0400 (EDT) Date: Thu, 15 Jul 2004 12:24:45 -0400 (EDT) From: John Heffner To: David Stevens cc: Andi Kleen , , "Rusty Russell (IBM)" Subject: Re: Fragment ID wrap workaround (read-only, untested). In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 6969 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev FYI, we have an informational internet-draft documenting this problem. Currently can be foud at: . -John From johnpol@2ka.mipt.ru Thu Jul 15 09:54:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:54:29 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGsMOn025599 for ; Thu, 15 Jul 2004 09:54:23 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6FGrwsI002340; Thu, 15 Jul 2004 20:53:59 +0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089908900.1027.77.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c6beA3+FFR3nBPyCcawT" Organization: MIPT Message-Id: <1089910757.6114.965.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 15 Jul 2004 20:59:17 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6970 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-c6beA3+FFR3nBPyCcawT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-15 at 20:28, jamal wrote: > On Thu, 2004-07-15 at 11:55, Evgeniy Polyakov wrote: >=20 >=20 > > > OpenBSD's CARP does load balancing through Source Hashing (SH), which > > UCARP=20 > > > lacks support for. > >=20 > > Userspace can't in principle. > > Current kernel implementation can't too, but it can. In principle. >=20 > Easy with current traffic control extensions. We need an action written > for this. User space dameon controls it. Load balancing between different computers? How nodes will know about each other using only tc extension? Kernel traps packet, send info about it to userspace, it decides drop it or not... Not very fast path. Or you may hardcode parameters for packets to be sent through current machine in it's rules, and userspace will decide only _when_ apply all those rules. But if we want to change things we have following chain: driver <-0-> stack <-1-> tc <-2-> userspace carp <-3-> stack <-4-> other machine. With kernel implementation we may avoid 2 and 3. And the bigggest advantage of the CARP is that it may touch kernel bits. For any situation that may occure in HA world and will require touching kernel space we always need some inkernel agent and some state machine/protocol to connect it to userspace... CARP already may this. >=20 > cheers, > jamal --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-c6beA3+FFR3nBPyCcawT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9rflIKTPhE+8wY0RAvxyAJ4s54HrUETsdr9DnLAQhbTb9xbJ6gCePj6T yi2OQh4jNy2XwD7OkCmjtAE= =JBey -----END PGP SIGNATURE----- --=-c6beA3+FFR3nBPyCcawT-- From johnpol@2ka.mipt.ru Thu Jul 15 09:54:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:54:32 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGsO0h025600 for ; Thu, 15 Jul 2004 09:54:25 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6FGs1iX002353; Thu, 15 Jul 2004 20:54:01 +0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: jamal Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089907622.1027.48.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-w23J5Lt4NFSmfeMPtgq1" Organization: MIPT Message-Id: <1089910760.6114.967.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 15 Jul 2004 20:59:20 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 6971 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-w23J5Lt4NFSmfeMPtgq1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-15 at 20:07, jamal wrote: > > > Why do you need to put this stuff in the kernel? > > > This should be implemented just the same way as VRRP was - in user > > > space. > >=20 > > Hmm... > > Just because i think it works better being implemented in the kernel? := ) > > I don't think it is a good answer thought. > >=20 > > It is faster, it is more flexible, it has access to kernel space... >=20 > Yeah, I know ;-> and probably thats what the opnebsd people did. > =20 > I still think it should live in user space. This should apply to > anything thats control related because such things tend to be > continoulsy enrichned with features. ARP unfortunately is in there; one > of my pet perpetual projects is to totaly rip it off. Theres already > hooks to deliver to user space today and Alexey has a daemon for it, not > sure how widely used it is. Userspace is too slow. It can only initiate master's failover, load balancing is a good example here - userspace _itself_ can not control real time traffic. > > > BTW, is there a spec for this protocol or its one of those things whe= re > > > you have to follow Yodas advice? > >=20 > > Exactly :) > > Here are all links I found: >=20 > Thank you.=20 > I think a better idea would be to implement a sync message > within CARP instead of that pfsync app doing its own thing. Unless i > misread, pfsync seems to be a separate app. > This way more than one app can use it via the CARP daemon > in user space to sync state of their choice (with whatever pfsync does > being one of many).=20 ct_sync module does this. It uses connection tracking and sends firewall state across slaves. CARP is separate by design - anyone may "attach" to master/slave failover. > This is an example of a rich application and further justification for > it to live in user space. If it will live in userspace, it just can not control realtime traffic and even provide some mechanism to achive this. > > I do want this to be in the mainline kernel, but actually I even don't > > think anyone will apply it. > > > > It is too special stuff for generic kernel, it has reserved 112 vrrp > > protocol number and so on... > > So if developers decide not to include or even not to discuss this cruf= t > > I will not beat myself by my heels. :) > >=20 > > It just works as expected, it is reliable and simple. > > And it does it's work, so HA people would like it. >=20 > It is valuable, just doesnt belong to the kernel. > BTW, i saw some claim that this is patent-free as opposed to VRRP? > I do hope it takes off. What exactly is the patent issue that was at > stake? I couldnt tell from the song lyrics ;-> :) Cisco + hsrp =3D=3D vrrp, but the former is patented. Here is quote from Ryan McBride, an author of the CARP: * P.S. If anyone has concerns about the Cisco's patent #5,473,599 and how their claim that it applies to VRRP has forced us to design our own incompatible protocol, don't talk to us. Instead, call Cisco's lawyer at 408-525-9706, or email him: rbarr@cisco.com * > One valuable thing that could be done is while still avoiding any patent > issues make it interop with VRRP. VRRP is not secure, it is protocol dependent, it is not free... > cheers, > jamal --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-w23J5Lt4NFSmfeMPtgq1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9rfoIKTPhE+8wY0RAsynAJ4+N5RgnU/AbDlFcyjE9QILiEloEwCeIgGG rQgVt4D/k+RKRVIwsRDcm14= =Mh7g -----END PGP SIGNATURE----- --=-w23J5Lt4NFSmfeMPtgq1-- From dlstevens@us.ibm.com Thu Jul 15 09:55:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:55:13 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGt47j026016 for ; Thu, 15 Jul 2004 09:55:04 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6FGsvko493134; Thu, 15 Jul 2004 12:54:57 -0400 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6FGsuAu415948; Thu, 15 Jul 2004 10:54:56 -0600 In-Reply-To: <20040715182735.3787c8b1.ak@suse.de> To: Andi Kleen Cc: netdev@oss.sgi.com, rusty@au1.ibm.com MIME-Version: 1.0 Subject: Re: Fragment ID wrap workaround (read-only, untested). X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 15 Jul 2004 09:54:53 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 07/15/2004 10:54:56, Serialize complete at 07/15/2004 10:54:56 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 6972 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Andi Kleen wrote on 07/15/2004 09:27:35 AM: > I'm well aware of the Gigabit+ NFS problem. My standard suggestion to solve > it is to just get rid of NFS over UDP - it always was a bad idea. No disagreement here. > My point was just that you're concentrating on that one only, > but you're potentially causing more problems for slow links. > The stack has to work well both for slow and fast links though. That's the problem it's intended to solve, but of course any actual solution would have to behave well for all links, and that's in fact the whole reason to have a dynamic frag queue timeout instead of a fixed one for all links. As long as the timeout is conservative without being so enormously so that it allows IP ID wrap, it shouldn't affect any existing use at all. If the timeout were scaled to be only 10 (or 100!) times any reasonable expectation of success rather than thousands or tens of thousands of times too large, the problem wouldn't exist on fast links, and slow links would behave exactly as they do now. I agree that NFS over UDP should be dead as soon as possible, and fragmentation in general not far behind it. They aren't quite dead yet; until they are, why not make them better behaved? And if your argument is that it isn't worth fixing because it isn't used, then of course the argument that it'll break slow links to change it doesn't fly. Sites obviously have fast links where this can break, and done correctly, this shouldn't affect slow links at all. People who don't use NFS over UDP aren't affected by it either way, right? :-) +-DLS From jt@bougret.hpl.hp.com Thu Jul 15 09:58:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 09:58:32 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FGwHQ4026516 for ; Thu, 15 Jul 2004 09:58:18 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 79D784003AB; Thu, 15 Jul 2004 09:29:00 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id JAA16093; Thu, 15 Jul 2004 09:29:50 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bl96R-0006jF-00; Thu, 15 Jul 2004 09:28:59 -0700 Date: Thu, 15 Jul 2004 09:28:59 -0700 To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] irlmp warnings. Message-ID: <20040715162859.GB25405@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040713100956.66ff796f@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040713100956.66ff796f@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 6973 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Tue, Jul 13, 2004 at 10:09:56AM -0700, Stephen Hemminger wrote: > Get rid of sparse warnings about 0 vs NULL. in irlmp. I feel freat that you are on top of that. I currently have family at home, so please feel free to push that where it needs ;-) Have fun... Jean From hadi@cyberus.ca Thu Jul 15 10:24:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 10:25:04 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FHOu3T027243 for ; Thu, 15 Jul 2004 10:24:57 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:474 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 18:24:54 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Bl9yV-0005sP-B0 for netdev@linux-mips.org; Thu, 15 Jul 2004 13:24:51 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bl9yS-0002dg-C5; Thu, 15 Jul 2004 13:24:48 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089910760.6114.967.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089912285.1028.93.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Jul 2004 13:24:45 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6974 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 Thu, 2004-07-15 at 12:59, Evgeniy Polyakov wrote: > Userspace is too slow. > It can only initiate master's failover, load balancing is a good example > here - userspace _itself_ can not control real time traffic. What is it that CARP does that couldnt be achieved by VRRP? VRRP is implemented in user space. As a user myself i can assure you even with heartbeats at 100ms granularity i have seen no issues which can be blamed on the fact it runs on user space. And i have used it in fairly large setups. > ct_sync module does this. > It uses connection tracking and sends firewall state across slaves. > CARP is separate by design - anyone may "attach" to master/slave > failover. Can you explain a little more what you mean by "attching" to master/slave? I hope you are not saying that that this ct_sync thing sends every piece of connection tracking state across. That would be a collosal waste. > > This is an example of a rich application and further justification for > > it to live in user space. > > If it will live in userspace, it just can not control realtime traffic > and even provide some mechanism to achive this. What do you mean realtime traffic? Is it something that can be achieved by qos prioritization? > > It is valuable, just doesnt belong to the kernel. > > BTW, i saw some claim that this is patent-free as opposed to VRRP? > > I do hope it takes off. What exactly is the patent issue that was at > > stake? I couldnt tell from the song lyrics ;-> > > :) Cisco + hsrp == vrrp, but the former is patented. > Here is quote from Ryan McBride, an author of the CARP: > > * P.S. If anyone has concerns about the Cisco's patent #5,473,599 and > how their claim that it applies to VRRP has forced us to design our own > incompatible protocol, don't talk to us. Instead, call Cisco's lawyer at > 408-525-9706, or email him: rbarr@cisco.com * > In the end CISCO is going to be the loser in this of because something like CARP will take off and it cant talk to them. At the moment though they do have the market so interoping with them is valuable. > > One valuable thing that could be done is while still avoiding any patent > > issues make it interop with VRRP. > > VRRP is not secure, it is protocol dependent, it is not free... I was talking more from a deployment side rather than technology. The gentleman who now owns the VRRP daemon in Linux, Alexander Cassen, i believe had a chat with this Cisco lawyer and if my understanding is correct the main contention is CISCO is worried some idiot will sue them by writting a similar patent i.e the patent was not to have something to impose on other people rather a protection. I could be wrong. BTW, I am still not sure what the differences are that make CARP patent-free. In other words, I wouldnt bet at this point that if someone wanted to go after you for HSRP patent infrigement that it would be impossible. In any case i fully support the effort. BTW, I thought you could make VRRP secure. cheers, jamal From jt@bougret.hpl.hp.com Thu Jul 15 10:31:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 10:31:41 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FHVFiS027634 for ; Thu, 15 Jul 2004 10:31:15 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 4BC891782; Thu, 15 Jul 2004 10:00:25 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id KAA16972; Thu, 15 Jul 2004 10:01:15 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Bl9aq-0006z9-00; Thu, 15 Jul 2004 10:00:24 -0700 Date: Thu, 15 Jul 2004 10:00:24 -0700 To: Andi Kleen Cc: netdev@oss.sgi.com, irda-users@lists.sourceforge.net, the_nihilant@autistici.org Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040715170024.GH25405@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.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 Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 6976 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 06:39:21PM +0200, Andi Kleen wrote: > > http://bugme.osdl.org/show_bug.cgi?id=3077 > > Some IRDA chipsets currently don't work on x86-64, because > they're dependent on CONFIG_ISA and x86-64 doesn't set this. > CONFIG_ISA means real ISA slots, and I doubt these chips > come on real ISA cards, so I just removed the bogus > dependency. > > Please apply. > > -Andi I was because those driver were using isa_virt_to_bus. I think we can drop that now, but I don't have the problematic architecture. Well, I guess we will learn soon enough :-( Feel free to send that to Jeff. I currently have family, so will take time to process my patch queue. Regards, Jean From hadi@cyberus.ca Thu Jul 15 10:31:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 10:31:18 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FHVAPl027629 for ; Thu, 15 Jul 2004 10:31:12 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:47746 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 18:31:09 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BlA4Y-0008VT-5i for netdev@linux-mips.org; Thu, 15 Jul 2004 13:31:06 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BlA4T-0003RJ-KH; Thu, 15 Jul 2004 13:31:01 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089910757.6114.965.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089912658.1029.101.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Jul 2004 13:30:59 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 6975 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 Thu, 2004-07-15 at 12:59, Evgeniy Polyakov wrote: > On Thu, 2004-07-15 at 20:28, jamal wrote: > > Easy with current traffic control extensions. We need an action written > > for this. User space dameon controls it. > > Load balancing between different computers? > How nodes will know about each other using only tc extension? Why do they need to know about each other. Maybe explain a little how said load balancing is achieved. > Kernel traps packet, send info about it to userspace, it decides drop it > or not... Not very fast path. I am hoping CARP knows how to deal with dropped packets. > Or you may hardcode parameters for packets to be sent through current > machine in it's rules, and userspace will decide only _when_ apply all > those rules. But if we want to change things we have following chain: > driver <-0-> stack <-1-> tc <-2-> userspace carp <-3-> stack <-4-> other > machine. > With kernel implementation we may avoid 2 and 3. use socket to send to user space. When you want to install a load balancing rule, use netlink from user space to the kernel. Loadbalancing resides in the kernel as a tc action. > And the bigggest advantage of the CARP is that it may touch kernel bits. > For any situation that may occure in HA world and will require touching > kernel space we always need some inkernel agent and some state > machine/protocol to connect it to userspace... > CARP already may this. weak arguement, I am afraid. I am looking at the way the BSD people did it - which is what you are emulating and it is wrong. No need for this stuff to be done in kernel at all. cheers, jamal From ak@suse.de Thu Jul 15 10:37:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 10:37:43 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FHbZtM028277 for ; Thu, 15 Jul 2004 10:37:38 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 4025D894E2B; Thu, 15 Jul 2004 19:34:10 +0200 (CEST) Date: Thu, 15 Jul 2004 19:34:09 +0200 From: Andi Kleen To: "Rusty Russell (IBM)" Cc: netdev@oss.sgi.com Subject: Re: Fragment ID wrap workaround (read-only, untested). Message-ID: <20040715173409.GA14193@wotan.suse.de> References: <1089873416.6583.1.camel@bach> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089873416.6583.1.camel@bach> X-archive-position: 6977 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > + * other end detect ID wrap. */ > + if (skb->sk) { > + unsigned int slack; > + struct inet_opt *inet = inet_sk(skb->sk); > + > + slack = (left % mtu); > + if (slack) > + /* Shift by 8 bytes per id wrap. */ > + len = mtu - (slack % ((inet->id >> 16) << 3)); I'm pretty sure inet->id is wrong here. You would like the counter in the inet peer entry. inet_sk(sk)->id is just used for the pseudo counter in TCP that only works around VJ compression bugs. It's never used for real fragmentation. -Andi From ak@suse.de Thu Jul 15 10:53:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 10:53:43 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FHrKLj028763 for ; Thu, 15 Jul 2004 10:53:21 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C3C838DB527; Thu, 15 Jul 2004 19:02:50 +0200 (CEST) Date: Thu, 15 Jul 2004 19:02:49 +0200 From: Andi Kleen To: David Stevens Cc: netdev@oss.sgi.com, rusty@au1.ibm.com Subject: Re: Fragment ID wrap workaround (read-only, untested). Message-Id: <20040715190249.01a9c11e.ak@suse.de> In-Reply-To: References: <20040715182735.3787c8b1.ak@suse.de> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, 15 Jul 2004 09:54:53 -0700 David Stevens wrote: > I agree that NFS over UDP should be dead as soon as possible, > and fragmentation in general not far behind it. They aren't quite > dead yet; until they are, why not make them better behaved? And > if your argument is that it isn't worth fixing because it isn't I wouldn't go that far, just make extremly sure that any solution works on slow links too. The problem I see is that if you make the delay factor long enough to make the extremly variable links not regress you risk making the wrap on very fast links likely again. -Andi From bunk@fs.tum.de Thu Jul 15 12:25:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 12:25:39 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FJPTSS001513 for ; Thu, 15 Jul 2004 12:25:31 -0700 Received: (qmail 9937 invoked from network); 15 Jul 2004 19:19:24 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 15 Jul 2004 19:19:24 -0000 Date: Thu, 15 Jul 2004 21:25:16 +0200 From: Adrian Bunk To: roque@di.fc.ul.pt Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [2.6 patch] net/ipv6/route.c: fix inline compile error Message-ID: <20040715192516.GC25633@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 6979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Trying to compile net/ipv6/route.c in 2.6.8-rc1-mm1 using gcc 3.4 results in the following compile error: <-- snip --> ... CC net/ipv6/route.o net/ipv6/route.c: In function `ndisc_dst_alloc': net/ipv6/route.c:587: sorry, unimplemented: inlining failed in call to 'ipv6_advmss': function body not available net/ipv6/route.c:611: sorry, unimplemented: called from here make[2]: *** [net/ipv6/route.o] Error 1 <-- snip --> The patch below moves ipv6_advmss above the place where it's called the first time. An alternative approach would be to remove the inline. diffstat output: net/ipv6/route.c | 37 ++++++++++++++++++------------------- 1 files changed, 18 insertions(+), 19 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.7-mm6-full-gcc3.4/net/ipv6/route.c.old 2004-07-09 02:22:23.000000000 +0200 +++ linux-2.6.7-mm6-full-gcc3.4/net/ipv6/route.c 2004-07-09 02:23:21.000000000 +0200 @@ -584,7 +584,24 @@ /* Protected by rt6_lock. */ static struct dst_entry *ndisc_dst_gc_list; static int ipv6_get_mtu(struct net_device *dev); -static inline unsigned int ipv6_advmss(unsigned int mtu); + +static inline unsigned int ipv6_advmss(unsigned int mtu) +{ + mtu -= sizeof(struct ipv6hdr) + sizeof(struct tcphdr); + + if (mtu < ip6_rt_min_advmss) + mtu = ip6_rt_min_advmss; + + /* + * Maximal non-jumbo IPv6 payload is IPV6_MAXPLEN and + * corresponding MSS is IPV6_MAXPLEN - tcp_header_size. + * IPV6_MAXPLEN is also valid and means: "any MSS, + * rely only on pmtu discovery" + */ + if (mtu > IPV6_MAXPLEN - sizeof(struct tcphdr)) + mtu = IPV6_MAXPLEN; + return mtu; +} struct dst_entry *ndisc_dst_alloc(struct net_device *dev, struct neighbour *neigh, @@ -687,24 +704,6 @@ return mtu; } -static inline unsigned int ipv6_advmss(unsigned int mtu) -{ - mtu -= sizeof(struct ipv6hdr) + sizeof(struct tcphdr); - - if (mtu < ip6_rt_min_advmss) - mtu = ip6_rt_min_advmss; - - /* - * Maximal non-jumbo IPv6 payload is IPV6_MAXPLEN and - * corresponding MSS is IPV6_MAXPLEN - tcp_header_size. - * IPV6_MAXPLEN is also valid and means: "any MSS, - * rely only on pmtu discovery" - */ - if (mtu > IPV6_MAXPLEN - sizeof(struct tcphdr)) - mtu = IPV6_MAXPLEN; - return mtu; -} - static int ipv6_get_hoplimit(struct net_device *dev) { int hoplimit = ipv6_devconf.hop_limit; From johnpol@2ka.mipt.ru Thu Jul 15 12:41:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 12:41:49 -0700 (PDT) Received: from ffke-campus-gw.mipt.ru (ffke-campus-gw.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FJfg2D002375 for ; Thu, 15 Jul 2004 12:41:43 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by ffke-campus-gw.mipt.ru (8.12.11/8.12.11) with SMTP id i6FJfdXd021544; Thu, 15 Jul 2004 23:41:40 +0400 Date: Thu, 15 Jul 2004 23:53:13 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org Subject: Re: [1/2] CARP implementation. HA master's failover. Message-Id: <20040715235313.69897131@zanzibar.2ka.mipt.ru> In-Reply-To: <1089912285.1028.93.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6980 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On 15 Jul 2004 13:24:45 -0400 jamal wrote: > On Thu, 2004-07-15 at 12:59, Evgeniy Polyakov wrote: > > > Userspace is too slow. > > It can only initiate master's failover, load balancing is a good > > example here - userspace _itself_ can not control real time traffic. > > What is it that CARP does that couldnt be achieved by VRRP? I will answer a question by question, sorry. Has vrrp some authentification mechanism? Can it be used over IPv6? (CARP also can't but it is _very_ easy to add, I just don't have IPv6 network setup to test). May someone use vrrp in private commercial enviroment without fear of being convicted? > VRRP is implemented in user space. As a user myself i can assure you > even with heartbeats at 100ms granularity i have seen no issues which > can be blamed on the fact it runs on user space. And i have used it in > fairly large setups. > > > ct_sync module does this. > > It uses connection tracking and sends firewall state across slaves. > > CARP is separate by design - anyone may "attach" to master/slave > > failover. > > > Can you explain a little more what you mean by "attching" to > master/slave? Consider using some abstraction layer which makes some decisions based on knowledge of current HA state. > I hope you are not saying that that this ct_sync thing sends > every piece of connection tracking state across. That would be a > collosal waste. It looks like we do not understand each other :) Here is the explanation of the ct_sync: http://cvs.netfilter.org/netfilter-ha/README?rev=1.2&content-type=text/vnd.viewcvs-markup Harald Welte will have a talk about ct_sync at OLS. > > > This is an example of a rich application and further justification > > > for it to live in user space. > > > > If it will live in userspace, it just can not control realtime > > traffic and even provide some mechanism to achive this. > > What do you mean realtime traffic? > Is it something that can be achieved by qos prioritization? Yes it can. But who will control prioritization mechanism? Maybe userspace. But with such approach we need to create each time we need kernel access a kernel agent with it's own kernel<->user protocol, it's own connect to master/slave arbiter... With CARP just create one function in kernelspace and register it in CARP using provided mechanism. > > > It is valuable, just doesnt belong to the kernel. > > > BTW, i saw some claim that this is patent-free as opposed to VRRP? > > > I do hope it takes off. What exactly is the patent issue that was > > > at stake? I couldnt tell from the song lyrics ;-> > > > > :) Cisco + hsrp == vrrp, but the former is patented. > > Here is quote from Ryan McBride, an author of the CARP: > > > > * P.S. If anyone has concerns about the Cisco's patent #5,473,599 > > and how their claim that it applies to VRRP has forced us to design > > our own incompatible protocol, don't talk to us. Instead, call > > Cisco's lawyer at 408-525-9706, or email him: rbarr@cisco.com * > > > > In the end CISCO is going to be the loser in this of because > something like CARP will take off and it cant talk to them. At the > moment though they do have the market so interoping with them is > valuable. It is just marketing... The better software the more market it can eat. Theoretically... > > > One valuable thing that could be done is while still avoiding any > > > patent issues make it interop with VRRP. > > > > VRRP is not secure, it is protocol dependent, it is not free... > > I was talking more from a deployment side rather than technology. > The gentleman who now owns the VRRP daemon in Linux, Alexander Cassen, > i believe had a chat with this Cisco lawyer and if my understanding is > correct the main contention is CISCO is worried some idiot will sue > them by writting a similar patent i.e the patent was not to have > something to impose on other people rather a protection. I could be In theory practice and theory are the same, but in practice they are different. (c) Larry McVoy. Why use not good software and has even theoretical possibility to be convicted when we have free successor( :) I said it? Nah... ). > wrong. BTW, I am still not sure what the differences are that make > CARP patent-free. In other words, I wouldnt bet at this point that if > someone wanted to go after you for HSRP patent infrigement that it > would be impossible. In any case i fully support the effort. I have great confidence that Theo de Raadt will not include non patent-free code in OpenBSD. > BTW, I thought you could make VRRP secure. And protocol independent, and absolutely, even theoretically free, just better and different. It was already done by Ryan McBride. But he also changed name :) I believe it was Moor's law, that said than people always have time to rewrite project from scratch, but never have time to properly coordinate efforts and create good thing at the first time. Or something like this... > cheers, > jamal Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From ak@muc.de Thu Jul 15 13:50:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 13:50:13 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FKo4Ou010004 for ; Thu, 15 Jul 2004 13:50:04 -0700 Received: (qmail 4213 invoked by uid 3709); 15 Jul 2004 20:50:01 -0000 Date: 15 Jul 2004 22:50:01 +0200 Date: Thu, 15 Jul 2004 22:50:01 +0200 From: Andi Kleen To: Jeff Garzik Cc: netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040715205001.GA2527@muc.de> References: <40F6B547.7050800@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40F6B547.7050800@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 6981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 12:48:07PM -0400, Jeff Garzik wrote: > Andi Kleen wrote: > >http://bugme.osdl.org/show_bug.cgi?id=3077 > > > >Some IRDA chipsets currently don't work on x86-64, because > >they're dependent on CONFIG_ISA and x86-64 doesn't set this. > >CONFIG_ISA means real ISA slots, and I doubt these chips > >come on real ISA cards, so I just removed the bogus > >dependency. > > Honestly, the issue and patch need more thought, IMO. > > Regardless of theory, CONFIG_ISA is currently also used to indicate > legacy ISA devices that are today integrated into southbridges. I don't think so. I did most of the original CONFIG_ISA annotations and I only added it to real ISA devices. And the LPC devices in southbridges are normally not marked CONFIG_ISA. > > And with legacy ISA devices still around, I don't see a whole lot of > value in differentiating between "I have ISA slots" and "I have ISA > devices". There is great value. Basically most ISA drivers are not 64bit clean (if they even still work on i386 which is also often doubtful in 2.6) and it is a great way for 64bit archs to get rid of a lot of not working code. -Andi From jgarzik@pobox.com Thu Jul 15 14:00:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 14:01:02 -0700 (PDT) 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 SMTP id i6FL0shG010698 for ; Thu, 15 Jul 2004 14:00:55 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BlDLY-0007mh-Ap; Thu, 15 Jul 2004 22:00:52 +0100 Message-ID: <40F6F076.2080001@pobox.com> Date: Thu, 15 Jul 2004 17:00:38 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers References: <40F6B547.7050800@pobox.com> <20040715205001.GA2527@muc.de> In-Reply-To: <20040715205001.GA2527@muc.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Andi Kleen wrote: > On Thu, Jul 15, 2004 at 12:48:07PM -0400, Jeff Garzik wrote: >>And with legacy ISA devices still around, I don't see a whole lot of >>value in differentiating between "I have ISA slots" and "I have ISA >>devices". > > > There is great value. Basically most ISA drivers are not 64bit > clean (if they even still work on i386 which is also often doubtful > in 2.6) and it is a great way for 64bit archs to get rid of a lot > of not working code. I file that under "hiding bugs", since it will not be immediately obvious to a bug hunter or maintainer what the real problem is. If a driver is broken on 64-bit, please add "&& !64BIT" to the Kconfig. As you yourself just explained, your wish is to use CONFIG_ISA, but your intent is only coincedentally related to ISA. Jeff From ak@muc.de Thu Jul 15 14:55:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 14:56:04 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FLttUV012241 for ; Thu, 15 Jul 2004 14:55:55 -0700 Received: (qmail 52066 invoked by uid 3709); 15 Jul 2004 21:55:52 -0000 Date: 15 Jul 2004 23:55:52 +0200 Date: Thu, 15 Jul 2004 23:55:52 +0200 From: Andi Kleen To: Jeff Garzik Cc: netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040715215552.GA46635@muc.de> References: <40F6B547.7050800@pobox.com> <20040715205001.GA2527@muc.de> <40F6F076.2080001@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40F6F076.2080001@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 6983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 05:00:38PM -0400, Jeff Garzik wrote: > >There is great value. Basically most ISA drivers are not 64bit > >clean (if they even still work on i386 which is also often doubtful > >in 2.6) and it is a great way for 64bit archs to get rid of a lot > >of not working code. > > I file that under "hiding bugs", since it will not be immediately > obvious to a bug hunter or maintainer what the real problem is. They should be already aware that most ISA drivers are just not maintained anymore and very likely broken. I doubt there is any bug hunter or maintainer who is not aware of this fact. > If a driver is broken on 64-bit, please add "&& !64BIT" to the Kconfig. > > As you yourself just explained, your wish is to use CONFIG_ISA, but your > intent is only coincedentally related to ISA. There are no x86-64 machines with ISA slots. I think it is very related to ISA to disable drivers that are not used since the hardware has no physical mean to support it (yes, I am aware of PCMCIA, but that is not included in CONFIG_ISA). Same reason to not support CONFIG_EISA. LPC devices in southbridges are a different thing, but there doesn't seem to be any reason right now to add a CONFIG_LPC. If there was one I would have no problems with setting it. Anyways, this is only tangential to the original reason for the patch. Can you please drop the bogus ISA dependencies. Jean has clearly stated that the drivers have nothing to do with ISA itself. Here's the patch again for your convenience. -Andi -------------------------------------------------------------------- Remove wrong ISA dependencies for IRDA drivers. diff -u linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig --- linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o 2004-07-12 06:09:05.000000000 +0200 +++ linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig 2004-07-15 18:33:48.000000000 +0200 @@ -310,7 +310,7 @@ config NSC_FIR tristate "NSC PC87108/PC87338" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build support for the NSC PC87108 and PC87338 IrDA chipsets. This driver supports SIR, @@ -321,7 +321,7 @@ config WINBOND_FIR tristate "Winbond W83977AF (IR)" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build IrDA support for the Winbond W83977AF super-io chipset. This driver should be used for the IrDA @@ -347,7 +347,7 @@ config SMC_IRCC_FIR tristate "SMSC IrCC (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the SMC Infrared Communications Controller. It is used in a wide variety of @@ -357,7 +357,7 @@ config ALI_FIR tristate "ALi M5123 FIR (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the ALi M5123 FIR Controller. The ALi M5123 FIR Controller is embedded in ALi M1543C, @@ -385,7 +385,7 @@ config VIA_FIR tristate "VIA VT8231/VT1211 SIR/MIR/FIR" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build support for the VIA VT8231 and VIA VT1211 IrDA controllers, found on the motherboards using From jt@bougret.hpl.hp.com Thu Jul 15 15:35:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 15:35:42 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FMZY9F013147 for ; Thu, 15 Jul 2004 15:35:34 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 974591C0A13A; Thu, 15 Jul 2004 15:35:32 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id PAA27390; Thu, 15 Jul 2004 15:36:19 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BlEp6-0001DL-00; Thu, 15 Jul 2004 15:35:28 -0700 Date: Thu, 15 Jul 2004 15:35:28 -0700 To: Andi Kleen Cc: Jeff Garzik , netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040715223528.GA4645@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <40F6B547.7050800@pobox.com> <20040715205001.GA2527@muc.de> <40F6F076.2080001@pobox.com> <20040715215552.GA46635@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040715215552.GA46635@muc.de> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 6984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 11:55:52PM +0200, Andi Kleen wrote: > > Anyways, this is only tangential to the original reason for the patch. > Can you please drop the bogus ISA dependencies. Jean has clearly stated > that the drivers have nothing to do with ISA itself. Andy, I never said that, please quote me accurately. I personally don't have strong opinions on whether those drivers should be tagged with CONFIG_ISA or not, but those hardware are definitely mapped on the ISA bus. Also, I just had a report of an user having a problem with the removal of isa_virt_to_bus on x86-64 : http://bugme.osdl.org/show_bug.cgi?id=3073 Depending on how this bug pans out, we *may* have to revert the patch and brings back isa_virt_to_bus. Regards, Jean From jt@bougret.hpl.hp.com Thu Jul 15 15:42:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 15:42:43 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FMgb2j013637 for ; Thu, 15 Jul 2004 15:42:37 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 80CFA40D555; Thu, 15 Jul 2004 15:42:35 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id PAA27594; Thu, 15 Jul 2004 15:43:26 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BlEvz-0001LW-00; Thu, 15 Jul 2004 15:42:35 -0700 Date: Thu, 15 Jul 2004 15:42:35 -0700 To: Martin Diehl Cc: Andi Kleen , Jeff Garzik , netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040715224235.GA5164@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040715215552.GA46635@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 6985 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Fri, Jul 16, 2004 at 12:32:44AM +0200, Martin Diehl wrote: > On 15 Jul 2004, Andi Kleen wrote: > > > Remove wrong ISA dependencies for IRDA drivers. > > > > > > diff -u linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig > > --- linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o 2004-07-12 06:09:05.000000000 +0200 > > +++ linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig 2004-07-15 18:33:48.000000000 +0200 > > @@ -310,7 +310,7 @@ > > > > config NSC_FIR > > tristate "NSC PC87108/PC87338" > > - depends on IRDA && ISA > > + depends on IRDA > > > Admittedly I haven't tried either, but I'm pretty sure this patch will > break building those drivers because they are calling irda_setup_dma - > which is CONFIG_ISA. Maybe this can be dropped but I don't see what's > wrong with !64BIT instead. irda_setup_dma was (supposedly) fixed in 2.6.8-rc1, and no longer depend on CONFIG_ISA. Those driver are supposed to work on 64 bits. > Martin Jean From anton@ozlabs.org Thu Jul 15 16:03:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 16:04:01 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6FN3nd9025828 for ; Thu, 15 Jul 2004 16:03:50 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 227E52BEAF; Fri, 16 Jul 2004 09:03:42 +1000 (EST) Date: Thu, 15 Jul 2004 23:52:44 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Cc: cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jonmason@us.ibm.com, jkenisto@us.ibm.com Subject: Network device driver probe issues Message-ID: <20040715135244.GD27715@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-archive-position: 6986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Hi, With the advent of hotplug and udev we see network device driver opens called as soon as possible, ie after register_netdev. In a lot of cases drivers currently call register_netdev too early, before they are ready to handle an open. I think the e1000 had this problem (which has since been fixed), and the s2io appears to have this same issue. Once the register_netdev call is delayed until late in probe (it really should be the last thing the probe call does) we have an issue with device printks. One of the reasons register_netdev is often early in the probe routine of network drivers is that it provides a device name to append to printks. The e1000 gets around this by replicating register_netdev: rtnl_lock(); /* we need to set the name early since the DPRINTK macro needs it set */ if (dev_alloc_name(netdev, netdev->name) < 0) goto err_free_unlock; ... /* since we are holding the rtnl lock already, call the no-lock version */ if((err = register_netdevice(netdev))) goto err_register; cards_found++; rtnl_unlock(); The problem I have with this method has to do with how failures appear to the user. If you have two network cards and the first one fails during probe you will see: eth0: Intel(R) PRO/1000 Network Connection eth0: The EEPROM Checksum Is Not Valid eth0: Intel(R) PRO/1000 Network Connection This makes debugging the issue difficult. Where is the card that failed? We have machines with 100s of interfaces and there it becomes a real pain. We should instead use something stable to attach to printks during probe. pci_name() is the obvious choice, perhaps using dev_printk(). The failure then becomes: 0000:01:01.0 Intel(R) PRO/1000 Network Connection 0000:01:01.0 The EEPROM Checksum Is Not Valid 0000:02:01.0 Intel(R) PRO/1000 Network Connection Also it would be useful if somewhere during probe the network driver associated the network name with the pci id, eg: 0000:02:01.0 Intel(R) PRO/1000 Network Connection (eth0) I know we can get at it via other means but it would be nice to be able to look through the dmesg and work out what names were given to the cards. Anton From jgarzik@pobox.com Thu Jul 15 16:34:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 16:34:48 -0700 (PDT) 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 SMTP id i6FNYYOk030394 for ; Thu, 15 Jul 2004 16:34:37 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BlFkD-0002L1-E4; Fri, 16 Jul 2004 00:34:29 +0100 Message-ID: <40F71477.2020408@pobox.com> Date: Thu, 15 Jul 2004 19:34:15 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anton Blanchard CC: netdev@oss.sgi.com, cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jonmason@us.ibm.com, jkenisto@us.ibm.com Subject: Re: Network device driver probe issues References: <20040715135244.GD27715@krispykreme> In-Reply-To: <20040715135244.GD27715@krispykreme> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Anton Blanchard wrote: > The e1000 gets around this by replicating register_netdev: > > rtnl_lock(); > /* we need to set the name early since the DPRINTK macro needs it set */ > if (dev_alloc_name(netdev, netdev->name) < 0) > goto err_free_unlock; > > ... > > /* since we are holding the rtnl lock already, call the no-lock version */ > if((err = register_netdevice(netdev))) > goto err_register; > > cards_found++; > rtnl_unlock(); > > The problem I have with this method has to do with how failures appear > to the user. If you have two network cards and the first one fails > during probe you will see: Agreed, this is a hack and strongly discouraged. Hopefully Intel will hear this and send me a patch to fix... :) > We should instead use something stable to attach to printks during > probe. pci_name() is the obvious choice, perhaps using dev_printk(). > The failure then becomes: > > 0000:01:01.0 Intel(R) PRO/1000 Network Connection > 0000:01:01.0 The EEPROM Checksum Is Not Valid > 0000:02:01.0 Intel(R) PRO/1000 Network Connection pci_name() or a simple counter of devices found. I prefer pci_name() Jeff From jkenisto@us.ibm.com Thu Jul 15 18:04:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 18:04:37 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G14VPD032030 for ; Thu, 15 Jul 2004 18:04:31 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6G14Mtf542580; Thu, 15 Jul 2004 21:04:22 -0400 Received: from IBM-NI9DZTUKFQ8.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6G14KAu222106; Thu, 15 Jul 2004 19:04:21 -0600 Subject: Re: Network device driver probe issues From: Jim Keniston To: Jeff Garzik Cc: Anton Blanchard , netdev@oss.sgi.com, cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jonmason@us.ibm.com, Jim Keniston In-Reply-To: <40F71477.2020408@pobox.com> References: <20040715135244.GD27715@krispykreme> <40F71477.2020408@pobox.com> Content-Type: text/plain Organization: Message-Id: <1089939860.1709.70.camel@ibm-ni9dztukfq8.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 15 Jul 2004 18:04:20 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 6988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev On Thu, 2004-07-15 at 16:34, Jeff Garzik wrote: > Anton Blanchard wrote: > > The e1000 gets around this by replicating register_netdev: > > > > [snipped] > > > > The problem I have with this method has to do with how failures appear > > to the user. If you have two network cards and the first one fails > > during probe you will see: > > Agreed, this is a hack and strongly discouraged. > > Hopefully Intel will hear this and send me a patch to fix... :) > > > > We should instead use something stable to attach to printks during > > probe. pci_name() is the obvious choice, perhaps using dev_printk(). > > The failure then becomes: > > > > 0000:01:01.0 Intel(R) PRO/1000 Network Connection > > 0000:01:01.0 The EEPROM Checksum Is Not Valid > > 0000:02:01.0 Intel(R) PRO/1000 Network Connection > > pci_name() or a simple counter of devices found. I prefer pci_name() > > Jeff Delay registration until the end of the probe, and make DPRINTK smarter. DPRINTK should check adapter->netdev->reg_state == NETREG_REGISTERED and use the interface name (eth0) if the device is registered, or pci_name() if it's not. Jim From mja@laurelnetworks.com Thu Jul 15 20:54:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 20:54:24 -0700 (PDT) Received: from staple.laurelnetworks.com (nobody@staple.laurelnetworks.com [63.94.127.68]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G3sGIC006933 for ; Thu, 15 Jul 2004 20:54:17 -0700 Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by staple.laurelnetworks.com (Laurel/Laurel) with ESMTP id i6G3rMDr009374; Thu, 15 Jul 2004 23:53:22 -0400 Received: from mja-pc-linux.dhcp.pit.laurelnetworks.com (mja-pc-linux.dhcp.pit.laurelnetworks.com [10.0.21.237]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id i6G3rMWH027973; Thu, 15 Jul 2004 23:53:22 -0400 Received: from mja-pc-linux.dhcp.pit.laurelnetworks.com (IDENT:zooEvEs6GXgMSRSzSpxPjk/ZA1eu8SLG@localhost.dhcp.pit.laurelnetworks.com [127.0.0.1]) by mja-pc-linux.dhcp.pit.laurelnetworks.com (8.12.8/8.9.3) with ESMTP id i6G3rMHs018996; Thu, 15 Jul 2004 23:53:22 -0400 Received: (from mja@localhost) by mja-pc-linux.dhcp.pit.laurelnetworks.com (8.12.8/8.12.8/Submit) id i6G3rMTg018994 for linux-kernel; Thu, 15 Jul 2004 23:53:22 -0400 X-Original-To: lnxkrnl@gauley.ucs.indiana.edu Delivered-To: lnxkrnl@gauley.ucs.indiana.edu Received: from vger.kernel.org (vger.kernel.org [12.107.209.244]) by gauley.ucs.indiana.edu (Postfix) with ESMTP id 45D7061A1D for ; Wed, 2 Jun 2004 23:20:28 -0500 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265495AbUFCESP (ORCPT ); Thu, 3 Jun 2004 00:18:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265497AbUFCESO (ORCPT ); Thu, 3 Jun 2004 00:18:14 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:46038 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S265495AbUFCESK (ORCPT ); Thu, 3 Jun 2004 00:18:10 -0400 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BVjg9-0000W3-O8; Thu, 03 Jun 2004 05:18:09 +0100 Message-ID: <40BEA673.8080301@pobox.com> Date: Thu, 03 Jun 2004 00:17:55 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, jkmaline@cc.hut.fi, james.p.ketrenos@intel.com Subject: Re: wireless-2.6 queue opened References: <40BE9ED8.9020505@pobox.com> <20040602211038.287628ac.davem@redhat.com> In-Reply-To: <20040602211038.287628ac.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 6989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Wed, 02 Jun 2004 23:45:28 -0400 > Jeff Garzik wrote: > > >>Given that there are at least 3 complete wireless stacks (or >>thereabouts) floating about for Linux, I picked one that I felt had the >>best chance of being _evolved_ into a nice, clean, generic wireless >>stack: HostAP. > > > Even though I authored one of the "other" stacks, I'm totally fine > with this choice. Mainly because I simply lack the time or resources > to continue working on the stack I started. Actually... I want to use some of your stuff too. :) HostAP is a successful implementation, but your stuff was a good example of the glue needed to tie 802.11 tightly to the net stack. HostAP still has some "its a separate driver" stuff it needs to get rid of, as it is made more generic. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From dave@thedillows.org Thu Jul 15 21:49:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 21:49:18 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G4n7I0008231 for ; Thu, 15 Jul 2004 21:49:08 -0700 Received: (qmail 27478 invoked from network); 16 Jul 2004 04:49:05 -0000 Received: from unknown (HELO ori.thedillows.org) (69.1.45.93) by smtp1.knology.net with SMTP; 16 Jul 2004 04:49:05 -0000 Received: from ori.thedillows.org (localhost.thedillows.org [127.0.0.1]) by ori.thedillows.org (8.12.8/8.12.8) with ESMTP id i6G4n4Dm023695; Fri, 16 Jul 2004 00:49:04 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i6G4n4ST023693; Fri, 16 Jul 2004 00:49:04 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: Network device driver probe issues From: David Dillow To: Jim Keniston Cc: Jeff Garzik , Anton Blanchard , Netdev , cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jonmason@us.ibm.com In-Reply-To: <1089939860.1709.70.camel@ibm-ni9dztukfq8.beaverton.ibm.com> References: <20040715135244.GD27715@krispykreme> <40F71477.2020408@pobox.com> <1089939860.1709.70.camel@ibm-ni9dztukfq8.beaverton.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1089953344.23577.15.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Jul 2004 00:49:04 -0400 X-archive-position: 6990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev On Thu, 2004-07-15 at 21:04, Jim Keniston wrote: > On Thu, 2004-07-15 at 16:34, Jeff Garzik wrote: [snip] > > > We should instead use something stable to attach to printks during > > > probe. pci_name() is the obvious choice, perhaps using dev_printk(). > > > The failure then becomes: > > > > > > 0000:01:01.0 Intel(R) PRO/1000 Network Connection > > > 0000:01:01.0 The EEPROM Checksum Is Not Valid > > > 0000:02:01.0 Intel(R) PRO/1000 Network Connection > > > > pci_name() or a simple counter of devices found. I prefer pci_name() > > > > Jeff > > Delay registration until the end of the probe, and make DPRINTK smarter. > DPRINTK should check > adapter->netdev->reg_state == NETREG_REGISTERED > and use the interface name (eth0) if the device is registered, or > pci_name() if it's not. > > Jim In the typhoon driver, I have tp->name, and most everything that prints info/errors about the card use it. During probing, it is initially set to point to pci_name(), and once registered, it gets pointed to netdev->name. This seems fairly clean, though maybe a bit redundant. Dave From ak@muc.de Thu Jul 15 22:45:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 22:45:59 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G5jrV3009750 for ; Thu, 15 Jul 2004 22:45:53 -0700 Received: (qmail 22643 invoked by uid 3709); 16 Jul 2004 05:45:50 -0000 Date: 16 Jul 2004 07:45:50 +0200 Date: Fri, 16 Jul 2004 07:45:50 +0200 From: Andi Kleen To: Martin Diehl Cc: Jeff Garzik , netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040716054550.GA21819@muc.de> References: <20040715215552.GA46635@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 6991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Fri, Jul 16, 2004 at 12:32:44AM +0200, Martin Diehl wrote: > On 15 Jul 2004, Andi Kleen wrote: > > > Remove wrong ISA dependencies for IRDA drivers. > > > > > > diff -u linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig > > --- linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o 2004-07-12 06:09:05.000000000 +0200 > > +++ linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig 2004-07-15 18:33:48.000000000 +0200 > > @@ -310,7 +310,7 @@ > > > > config NSC_FIR > > tristate "NSC PC87108/PC87338" > > - depends on IRDA && ISA > > + depends on IRDA > > > Admittedly I haven't tried either, but I'm pretty sure this patch will > break building those drivers because they are calling irda_setup_dma - > which is CONFIG_ISA. Maybe this can be dropped but I don't see what's > wrong with !64BIT instead. Hmm, good point. !64BIT is not needed - apparently they are 64bit clean. The reason I want to drop the CONFIG_ISA depency is that they *should* be built on x86-64 too. -Andi From ak@muc.de Thu Jul 15 22:51:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 22:51:45 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G5pcwE010122 for ; Thu, 15 Jul 2004 22:51:39 -0700 Received: (qmail 25809 invoked by uid 3709); 16 Jul 2004 05:51:36 -0000 Date: 16 Jul 2004 07:51:36 +0200 Date: Fri, 16 Jul 2004 07:51:36 +0200 From: Andi Kleen To: jt@hpl.hp.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: [PATCH] Drop ISA dependencies for IRDA #2 Message-ID: <20040716055136.GB21819@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 6992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev This incorporates the changes suggested by Martin Diehl. Drop CONFIG_ISA dependencies for IRDA drivers. These chips really hang of a LPC bus, which doesn't have a special CONFIG. This makes them build on x86-64 Please apply. diff -u linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig --- linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o 2004-07-12 06:09:05.000000000 +0200 +++ linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig 2004-07-15 18:33:48.000000000 +0200 @@ -310,7 +310,7 @@ config NSC_FIR tristate "NSC PC87108/PC87338" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build support for the NSC PC87108 and PC87338 IrDA chipsets. This driver supports SIR, @@ -321,7 +321,7 @@ config WINBOND_FIR tristate "Winbond W83977AF (IR)" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build IrDA support for the Winbond W83977AF super-io chipset. This driver should be used for the IrDA @@ -347,7 +347,7 @@ config SMC_IRCC_FIR tristate "SMSC IrCC (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the SMC Infrared Communications Controller. It is used in a wide variety of @@ -357,7 +357,7 @@ config ALI_FIR tristate "ALi M5123 FIR (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the ALi M5123 FIR Controller. The ALi M5123 FIR Controller is embedded in ALi M1543C, @@ -385,7 +385,7 @@ config VIA_FIR tristate "VIA VT8231/VT1211 SIR/MIR/FIR" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build support for the VIA VT8231 and VIA VT1211 IrDA controllers, found on the motherboards using diff -u linux-2.6.8rc1-amd64/include/net/irda/irda_device.h-o linux-2.6.8rc1-amd64/include/net/irda/irda_device.h --- linux-2.6.8rc1-amd64/include/net/irda/irda_device.h-o 2004-07-12 06:09:09.000000000 +0200 +++ linux-2.6.8rc1-amd64/include/net/irda/irda_device.h 2004-07-16 07:47:20.000000000 +0200 @@ -237,9 +237,7 @@ dongle_t *irda_device_dongle_init(struct net_device *dev, int type); int irda_device_dongle_cleanup(dongle_t *dongle); -#ifdef CONFIG_ISA void irda_setup_dma(int channel, dma_addr_t buffer, int count, int mode); -#endif void irda_task_delete(struct irda_task *task); struct irda_task *irda_task_execute(void *instance, diff -u linux-2.6.8rc1-amd64/net/sunrpc/svcauth.c-o linux-2.6.8rc1-amd64/net/sunrpc/svcauth.c diff -u linux-2.6.8rc1-amd64/net/irda/irda_device.c-o linux-2.6.8rc1-amd64/net/irda/irda_device.c --- linux-2.6.8rc1-amd64/net/irda/irda_device.c-o 2004-07-12 06:09:10.000000000 +0200 +++ linux-2.6.8rc1-amd64/net/irda/irda_device.c 2004-07-16 07:47:14.000000000 +0200 @@ -529,11 +529,10 @@ return ret; } -#ifdef CONFIG_ISA /* * Function setup_dma (idev, buffer, count, mode) * - * Setup the DMA channel. Commonly used by ISA FIR drivers + * Setup the DMA channel. Commonly used by LPC FIR drivers * */ void irda_setup_dma(int channel, dma_addr_t buffer, int count, int mode) @@ -552,4 +551,3 @@ release_dma_lock(flags); } EXPORT_SYMBOL(irda_setup_dma); -#endif From Jayprakash_Gonella@Satyam.com Thu Jul 15 22:53:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 22:53:43 -0700 (PDT) Received: from vvamail.satyam.com (vvamail.satyam.com [208.220.248.10]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G5rZTU010443 for ; Thu, 15 Jul 2004 22:53:36 -0700 Received: from che1.satyam.com (che1.satyam.com [172.18.73.11]) by vvamail.satyam.com (8.11.6/8.11.6) with ESMTP id i6G5dd319515; Fri, 16 Jul 2004 01:39:40 -0400 Received: from cprnt003.satyam.com (localhost [127.0.0.1]) by che1.satyam.com (8.11.6/8.11.6) with ESMTP id i6G5jsv31151; Fri, 16 Jul 2004 11:15:54 +0530 Received: by cprnt003.satyam.com with Internet Mail Service (5.5.2657.72) id <3Y0FH9HN>; Fri, 16 Jul 2004 11:18:55 +0530 Message-ID: <7FF62A49079FD511B14400065B19EF1205911FDD@cprnt003.satyam.com> From: Jayprakash_Gonella To: netdev@oss.sgi.com, Linux Kernel Subject: Port Number Date: Fri, 16 Jul 2004 11:18:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 6993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Jayprakash_Gonella@Satyam.com Precedence: bulk X-list: netdev Howdy All, I hope I can post this question to this forum. A server is listening on so and so port number waiting for Client requests. Can anyone please tell, what exactly "port number" means? Does it refer to a process id in the OS on which which the server is running? Any ideas and opinions. thanks, jayprakash N.B: I am not subscribed to Linux_Kernel. Any ideas please mail at jayprakash_gonella@satyam.com ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** From pranav@nodeinfotech.com Thu Jul 15 22:54:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 22:54:28 -0700 (PDT) Received: from bband.maa.sify.net (smtp.sifybroadband.com [202.144.76.60]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G5sKDC010643; Thu, 15 Jul 2004 22:54:21 -0700 Received: from pranav (dialpool-210-214-16-108.maa.sify.net [210.214.16.108]) by bband.maa.sify.net (Relay) with SMTP id DD3EF2E498; Fri, 16 Jul 2004 11:19:58 +0530 (IST) Reply-To: From: "Pranav" To: Cc: Subject: problem in IKE implementation. Date: Fri, 16 Jul 2004 11:20:31 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-archive-position: 6994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pranav@nodeinfotech.com Precedence: bulk X-list: netdev hi every one, I am currently working on IKE implementation in linux system.i am facing a problem while when both the communating peers try to negotiate with each other at the same time resulting in a race condition.can any one help me regarding this issue. With Regards, Pranav Jahdav. From lists@mdiehl.de Thu Jul 15 23:13:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 23:13:20 -0700 (PDT) Received: from bart.webpack.hosteurope.de (bart.webpack.hosteurope.de [217.115.142.76]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G6DDLT012073 for ; Thu, 15 Jul 2004 23:13:14 -0700 Received: from pd9e952b3.dip0.t-ipconnect.de ([217.233.82.179] helo=notebook.home.mdiehl.de) by bart.webpack.hosteurope.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BlLxx-0007SP-41; Fri, 16 Jul 2004 08:13:05 +0200 Received: from notebook.home.mdiehl.de (localhost.localdomain [127.0.0.1]) by notebook.home.mdiehl.de (8.12.1/8.12.1) with ESMTP id i6G6J9ji018742; Fri, 16 Jul 2004 08:19:09 +0200 Received: from localhost (martin@localhost) by notebook.home.mdiehl.de (8.12.1/8.12.1/Submit) with ESMTP id i6G6J5Cp018739; Fri, 16 Jul 2004 08:19:08 +0200 X-Authentication-Warning: notebook.home.mdiehl.de: martin owned process doing -bs Date: Fri, 16 Jul 2004 08:19:04 +0200 (CEST) From: Martin Diehl X-X-Sender: martin@notebook.home.mdiehl.de To: Andi Kleen cc: Jeff Garzik , , , Jean Tourrilhes , , Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers In-Reply-To: <20040716054550.GA21819@muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HE-MXrcvd: no X-archive-position: 6995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lists@mdiehl.de Precedence: bulk X-list: netdev On 16 Jul 2004, Andi Kleen wrote: > > Admittedly I haven't tried either, but I'm pretty sure this patch will > > break building those drivers because they are calling irda_setup_dma - > > which is CONFIG_ISA. Maybe this can be dropped but I don't see what's > > wrong with !64BIT instead. > > Hmm, good point. > > !64BIT is not needed - apparently they are 64bit clean. I think you are right - however, AFAICS this is not the point in this case. These drivers do DMA to legacy devices (call it ISA, LPC, whatever). The documented way for those devices without struct pci_dev is to call the dma api functions with dev=NULL. For i386 the generic dma functions are overwritten so they use GFP_DMA f.e. in this case. According to include/asm-x86_64/dma-mapping.h there is no such override for x86-64. Hence the generic implementation is used which Oopses when called with dev=NULL in dma_alloc_coherent because it dereferences dev unconditionally. > The reason I want to drop the CONFIG_ISA depency is that they *should* > be built on x86-64 too. Yes, sure. The point is with current CONFIG_ISA requirement they cannot be build on x86-64 - with CONFIG_ISA removed they can, but will Oops. See the report Jean was refering to. I agree !64BIT isn't the clean way to handle this - IMHO x86-64 needs to support legacy devices (dev=NULL) in its dma api implementation. If it doesn't, I don't see how these drivers might work on this arch. Martin From ak@suse.de Thu Jul 15 23:20:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 23:20:15 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G6JxO5012470 for ; Thu, 15 Jul 2004 23:19:59 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0F3398DFECD; Fri, 16 Jul 2004 07:36:53 +0200 (CEST) Date: Fri, 16 Jul 2004 07:36:52 +0200 From: Andi Kleen To: jt@hpl.hp.com Cc: Andi Kleen , Jeff Garzik , netdev@oss.sgi.com, irda-users@lists.sourceforge.net, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040716053652.GA662@wotan.suse.de> References: <40F6B547.7050800@pobox.com> <20040715205001.GA2527@muc.de> <40F6F076.2080001@pobox.com> <20040715215552.GA46635@muc.de> <20040715223528.GA4645@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040715223528.GA4645@bougret.hpl.hp.com> X-archive-position: 6996 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 03:35:28PM -0700, Jean Tourrilhes wrote: > On Thu, Jul 15, 2004 at 11:55:52PM +0200, Andi Kleen wrote: > > > > Anyways, this is only tangential to the original reason for the patch. > > Can you please drop the bogus ISA dependencies. Jean has clearly stated > > that the drivers have nothing to do with ISA itself. > > Andy, I never said that, please quote me accurately. I > personally don't have strong opinions on whether those drivers should > be tagged with CONFIG_ISA or not, but those hardware are definitely > mapped on the ISA bus. More likely on LPC interface. And not on a ISA slot. Anyways, if you want them to work on x86-64 you will have to drop that bogus dependency. I have no plans to ever define CONFIG_ISA on x86-64. -Andi From ak@suse.de Thu Jul 15 23:55:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jul 2004 23:55:43 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G6tR9G013261 for ; Thu, 15 Jul 2004 23:55:28 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 739BC8E04DE; Fri, 16 Jul 2004 08:19:14 +0200 (CEST) Date: Fri, 16 Jul 2004 08:19:13 +0200 From: Andi Kleen To: Martin Diehl Cc: Andi Kleen , Jeff Garzik , netdev@oss.sgi.com, irda-users@lists.sourceforge.net, Jean Tourrilhes , the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers Message-ID: <20040716061913.GB662@wotan.suse.de> References: <20040716054550.GA21819@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 6997 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Fri, Jul 16, 2004 at 08:19:04AM +0200, Martin Diehl wrote: > On 16 Jul 2004, Andi Kleen wrote: > > > > Admittedly I haven't tried either, but I'm pretty sure this patch will > > > break building those drivers because they are calling irda_setup_dma - > > > which is CONFIG_ISA. Maybe this can be dropped but I don't see what's > > > wrong with !64BIT instead. > > > > Hmm, good point. > > > > !64BIT is not needed - apparently they are 64bit clean. > > I think you are right - however, AFAICS this is not the point in this > case. These drivers do DMA to legacy devices (call it ISA, LPC, whatever). > The documented way for those devices without struct pci_dev is to call the > dma api functions with dev=NULL. For i386 the generic dma functions are > overwritten so they use GFP_DMA f.e. in this case. There was at least one user report that at least one driver worked with CONFIG_ISA force defined. > > According to include/asm-x86_64/dma-mapping.h there is no such override > for x86-64. Hence the generic implementation is used which Oopses when > called with dev=NULL in dma_alloc_coherent because it dereferences dev > unconditionally. The old pci_alloc_coherent supported hwdev == NULL under x86-64. dma_alloc_consistent() should too. I will fix that. -Andi From jgarzik@pobox.com Fri Jul 16 00:17:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 00:17:50 -0700 (PDT) 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 SMTP id i6G7HWVJ014101 for ; Fri, 16 Jul 2004 00:17:40 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bl9PE-0003wA-26; Thu, 15 Jul 2004 17:48:24 +0100 Message-ID: <40F6B547.7050800@pobox.com> Date: Thu, 15 Jul 2004 12:48:07 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com, irda-users@lists.sourceforge.net, jt@hpl.hp.com, the_nihilant@autistici.org, Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6998 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Andi Kleen wrote: > http://bugme.osdl.org/show_bug.cgi?id=3077 > > Some IRDA chipsets currently don't work on x86-64, because > they're dependent on CONFIG_ISA and x86-64 doesn't set this. > CONFIG_ISA means real ISA slots, and I doubt these chips > come on real ISA cards, so I just removed the bogus > dependency. Honestly, the issue and patch need more thought, IMO. Regardless of theory, CONFIG_ISA is currently also used to indicate legacy ISA devices that are today integrated into southbridges. And with legacy ISA devices still around, I don't see a whole lot of value in differentiating between "I have ISA slots" and "I have ISA devices". Jeff From johnpol@2ka.mipt.ru Fri Jul 16 01:08:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 01:08:55 -0700 (PDT) Received: from ffke-campus-gw.mipt.ru (ffke-campus-gw.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G88kGt018719 for ; Fri, 16 Jul 2004 01:08:49 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by ffke-campus-gw.mipt.ru (8.12.11/8.12.11) with SMTP id i6FJ90Jt018243; Thu, 15 Jul 2004 23:09:00 +0400 Date: Thu, 15 Jul 2004 23:20:35 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org Subject: Re: [1/2] CARP implementation. HA master's failover. Message-Id: <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> In-Reply-To: <1089912658.1029.101.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> <1089912658.1029.101.camel@jzny.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7000 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2946 Lines: 76 On 15 Jul 2004 13:30:59 -0400 jamal wrote: > On Thu, 2004-07-15 at 12:59, Evgeniy Polyakov wrote: > > On Thu, 2004-07-15 at 20:28, jamal wrote: > > > > Easy with current traffic control extensions. We need an action > > > written for this. User space dameon controls it. > > > > Load balancing between different computers? > > How nodes will know about each other using only tc extension? > > Why do they need to know about each other. Maybe explain a little > how said load balancing is achieved. Kind of scuch scenario: If I am a masater, than get half of bandwidth, but if slave count is less than threshold than get more. If I am a slave and slave count is more than threshold than get 0.5/slave_count of the bandwidth and reserve some else get... > > Kernel traps packet, send info about it to userspace, it decides > > drop it or not... Not very fast path. > > I am hoping CARP knows how to deal with dropped packets. Tssss, OpenBSD's one just silently drops. Linux one will (if will) use some clever mechanism to be sure that someone got this packet and _I_ may drop it. > > Or you may hardcode parameters for packets to be sent through > > current machine in it's rules, and userspace will decide only _when_ > > apply all those rules. But if we want to change things we have > > following chain: driver <-0-> stack <-1-> tc <-2-> userspace carp > > <-3-> stack <-4-> other machine. > > With kernel implementation we may avoid 2 and 3. > > use socket to send to user space. When you want to install a load > balancing rule, use netlink from user space to the kernel. > Loadbalancing resides in the kernel as a tc action. What about case when you do need kernel space access based on CARP state? You will need to install each time new kernel agent for it. With CARP being implemented in kernelspace you need just one - CARP itself. > > And the bigggest advantage of the CARP is that it may touch kernel > > bits. For any situation that may occure in HA world and will require > > touching kernel space we always need some inkernel agent and some > > state machine/protocol to connect it to userspace... > > CARP already may this. > > weak arguement, I am afraid. I am looking at the way the BSD people > did it - which is what you are emulating and it is wrong. No need for > this stuff to be done in kernel at all. No. BSD people have kernel implementation: OpenBSD has, FreeBSD has port, NetBSD has port, but not included into mainline due to patent issue. It is case of abstraction: for some reason(and for most of all) you do not need kernel space implmentation. But reasons do exist to use it in kernel space, and if it will become an issue some day, you will anyway create a kernel agent. If you need kernel access in HA system, do not create new agents, just use CARP as kernel agent and arbiter. > > cheers, > jamal Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From ahu@outpost.ds9a.nl Fri Jul 16 02:34:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 02:34:10 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6G9Y3F0020814 for ; Fri, 16 Jul 2004 02:34:04 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 89B313FE6; Fri, 16 Jul 2004 11:33:59 +0200 (CEST) Date: Fri, 16 Jul 2004 11:33:59 +0200 From: bert hubert To: Pranav Cc: netdev@oss.sgi.com Subject: Re: problem in IKE implementation. Message-ID: <20040716093359.GA25457@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Pranav , netdev@oss.sgi.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-archive-position: 7001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 579 Lines: 13 On Fri, Jul 16, 2004 at 11:20:31AM +0530, Pranav wrote: > hi every one, > I am currently working on IKE implementation in linux system.i am > facing a problem while when both the communating peers try to negotiate with > each other at the same time resulting in a race condition.can any one help > me regarding this issue. I suggest reading the sources of racoon (or raccoon) or isakmpd to see how they handle this. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From hadi@cyberus.ca Fri Jul 16 05:34:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 05:35:16 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GCYt3E030220 for ; Fri, 16 Jul 2004 05:34:56 -0700 Received: from mx03.cybersurf.com ([IPv6:::ffff:209.197.145.106]:18854 "EHLO mx03.cybersurf.com") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 13:34:53 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BlRvL-0004OF-VN for netdev@linux-mips.org; Fri, 16 Jul 2004 08:34:47 -0400 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 1BlRvI-0005Ca-2z; Fri, 16 Jul 2004 08:34:44 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> <1089912658.1029.101.camel@jzny.localdomain> <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089981282.1060.1293.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Jul 2004 08:34:42 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7002 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2151 Lines: 59 On Thu, 2004-07-15 at 15:20, Evgeniy Polyakov wrote: > > > Load balancing between different computers? > > > How nodes will know about each other using only tc extension? > > > > Why do they need to know about each other. Maybe explain a little > > how said load balancing is achieved. > > Kind of scuch scenario: > If I am a masater, than get half of bandwidth, but if slave count is > less than threshold than get more. > If I am a slave and slave count is more than threshold than get > 0.5/slave_count of the bandwidth and reserve some else get... Ok, so some controller is in charge - seems like thats something that could be easily done in user space based on mastership transitions. > > > Kernel traps packet, send info about it to userspace, it decides > > > drop it or not... Not very fast path. > > > > I am hoping CARP knows how to deal with dropped packets. > > Tssss, OpenBSD's one just silently drops. Ok, i wont tell ;-> > Linux one will (if will) use some clever mechanism to be sure that > someone got this packet and _I_ may drop it. In VRRP for example its the number of heartbeats missed that makes the difference. Also the dead interval is valuable before a split-brain hits the fan. So maybe one or two dropped packets is ok. > > use socket to send to user space. When you want to install a load > > balancing rule, use netlink from user space to the kernel. > > Loadbalancing resides in the kernel as a tc action. > > What about case when you do need kernel space access based on CARP > state? What kind of access? To configure something? what kind of thing? > It is case of abstraction: for some reason(and for most of all) you do > not need kernel space implmentation. > But reasons do exist to use it in kernel space, and if it will become an > issue some day, you will anyway create a kernel agent. If you need > kernel access in HA system, do not create new agents, just use CARP as > kernel agent and arbiter. Iam not buying it Evgeniy, sorry ;-> BTW, I like that ARP balancing feature that CARP has. Pretty neat. Note that it could be easily done via a tc action with user space control. cheers, jamal From dsaxena@plexity.net Fri Jul 16 05:35:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 05:35:31 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GCZNVV030261 for ; Fri, 16 Jul 2004 05:35:24 -0700 Received: from plexity.net (c-24-20-152-76.client.comcast.net[24.20.152.76]) by comcast.net (sccrmhc12) with ESMTP id <2004071609290001200fkjn0e>; Fri, 16 Jul 2004 09:29:00 +0000 Received: by plexity.net (Postfix, from userid 1025) id BB9C6218354; Fri, 16 Jul 2004 02:28:59 -0700 (PDT) Date: Fri, 16 Jul 2004 02:28:59 -0700 From: Deepak Saxena To: jgarkzik@pobox.om Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH] Add IXDP2x01 board support to CS89x0 driver Message-ID: <20040716092859.GA16849@plexity.net> Reply-To: dsaxena@plexity.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Plexity Networks User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 7003 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dsaxena@plexity.net Precedence: bulk X-list: netdev Content-Length: 6711 Lines: 201 Jeff, The following patch modifies the CS89x0 driver to work on Intel's IXDP2401 and IXDP2801 (Intel ARm/XScale based) platforms: - The main change requried is that the IXDP2x01 boards have the chip connected through a CPLD so all registers appear at dword-aligned addresses. A macro in the header adjusts the register offsets appropriately. - The boards do not have ISA, so we need to explicitly check for IXDP2X01 in Kconfig. - There is what I believe is a bug in the driver as it currently only asks for the signature if ioaddr & 1 is set but then reads and checks against the expected signature even when !(ioaddr & 1). This causes the driver to not load on the IXDP2x01 since our ioaddr does not have bit 1 set. - #ifdef out some bits of code that assume the chip is really sitting on an ISA bus. The main IXDP2x01 support will be coming in through rmk's tree at a later date when all the drivers are merged upstream. Tnx, ~Deepak ===== drivers/net/Kconfig 1.79 vs edited ===== --- 1.79/drivers/net/Kconfig Fri Jun 18 09:43:06 2004 +++ edited/drivers/net/Kconfig Mon Jul 12 12:14:59 2004 @@ -1335,7 +1335,7 @@ config CS89x0 tristate "CS89x0 support" - depends on NET_PCI && ISA + depends on NET_PCI && (ISA || ARCH_IXDP2X01) ---help--- Support for CS89x0 chipset based Ethernet cards. If you have a network (Ethernet) card of this type, say Y and read the ===== drivers/net/cs89x0.c 1.24 vs edited ===== --- 1.24/drivers/net/cs89x0.c Sat May 22 10:40:55 2004 +++ edited/drivers/net/cs89x0.c Fri Jul 16 02:02:25 2004 @@ -84,6 +84,9 @@ Oskar Schirmer : oskar@scara.com : HiCO.SH4 (superh) support added (irq#1, cs89x0_media=) + Deepak Saxena : dsaxena@plexity.net + : Intel IXDP2x01 (XScale ixp2x00 NPU) platform support + */ /* Always include 'config.h' first in case the user wants to turn on @@ -97,7 +100,11 @@ * Note that even if DMA is turned off we still support the 'dma' and 'use_dma' * module options so we don't break any startup scripts. */ +#ifndef CONFIG_ARCH_IXDP2X01 +#define ALLOW_DMA 0 +#else #define ALLOW_DMA 1 +#endif /* * Set this to zero to remove all the debug statements via @@ -162,6 +169,10 @@ static unsigned int netcard_portlist[] __initdata = { 0x0300, 0}; static unsigned int cs8900_irq_map[] = {1,0,0,0}; +#elif defined(CONFIG_ARCH_IXDP2X01) +#include +static unsigned int netcard_portlist[] __initdata = {IXDP2X01_CS8900_VIRT_BASE, 0}; +static unsigned int cs8900_irq_map[] = {IRQ_IXDP2X01_CS8900, 0, 0, 0}; #else static unsigned int netcard_portlist[] __initdata = { 0x300, 0x320, 0x340, 0x360, 0x200, 0x220, 0x240, 0x260, 0x280, 0x2a0, 0x2c0, 0x2e0, 0}; @@ -454,11 +465,12 @@ retval = -ENODEV; goto out2; } - ioaddr &= ~3; - outw(PP_ChipID, ioaddr + ADD_PORT); } printk("PP_addr=0x%x\n", inw(ioaddr + ADD_PORT)); + ioaddr &= ~3; + outw(PP_ChipID, ioaddr + ADD_PORT); + if (inw(ioaddr + DATA_PORT) != CHIP_EISA_ID_SIG) { printk(KERN_ERR "%s: incorrect signature 0x%x\n", dev->name, inw(ioaddr + DATA_PORT)); @@ -665,6 +677,9 @@ } else { i = lp->isa_config & INT_NO_MASK; if (lp->chip_type == CS8900) { +#ifdef CONFIG_ARCH_IXDP2X01 + i = cs8900_irq_map[0]; +#else /* Translate the IRQ using the IRQ mapping table. */ if (i >= sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0])) printk("\ncs89x0: invalid ISA interrupt number %d\n", i); @@ -681,6 +696,7 @@ if ((irq_map_buff[0] & 0xff) == PNP_IRQ_FRMT) lp->irq_map = (irq_map_buff[0]>>8) | (irq_map_buff[1] << 8); } +#endif } if (!dev->irq) dev->irq = i; @@ -884,8 +900,10 @@ void __init reset_chip(struct net_device *dev) { +#ifndef CONFIG_ARCH_IXDP2X01 struct net_local *lp = netdev_priv(dev); int ioaddr = dev->base_addr; +#endif int reset_start_time; writereg(dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) | POWER_ON_RESET); @@ -894,6 +912,7 @@ current->state = TASK_INTERRUPTIBLE; schedule_timeout(30*HZ/1000); +#ifndef CONFIG_ARCH_IXDP2X01 if (lp->chip_type != CS8900) { /* Hardware problem requires PNP registers to be reconfigured after a reset */ outw(PP_CS8920_ISAINT, ioaddr + ADD_PORT); @@ -904,6 +923,8 @@ outb((dev->mem_start >> 16) & 0xff, ioaddr + DATA_PORT); outb((dev->mem_start >> 8) & 0xff, ioaddr + DATA_PORT + 1); } +#endif /* IXDP2x01 */ + /* Wait until the chip is reset */ reset_start_time = jiffies; while( (readreg(dev, PP_SelfST) & INIT_DONE) == 0 && jiffies - reset_start_time < 2) @@ -1155,12 +1176,14 @@ else #endif { +#ifndef CONFIG_ARCH_IXDP2X01 if (((1 << dev->irq) & lp->irq_map) == 0) { printk(KERN_ERR "%s: IRQ %d is not in our map of allowable IRQs, which is %x\n", dev->name, dev->irq, lp->irq_map); ret = -EAGAIN; goto bad_out; } +#endif /* FIXME: Cirrus' release had this: */ writereg(dev, PP_BusCTL, readreg(dev, PP_BusCTL)|ENABLE_IRQ ); /* And 2.3.47 had this: */ ===== drivers/net/cs89x0.h 1.3 vs edited ===== --- 1.3/drivers/net/cs89x0.h Mon Mar 17 15:42:26 2003 +++ edited/drivers/net/cs89x0.h Fri Jul 16 02:02:48 2004 @@ -16,6 +16,13 @@ #include +#ifdef CONFIG_ARCH_IXDP2X01 +/* IXDP2401/IXDP2801 uses dword-aligned register addressing */ +#define CS89x0_PORT(reg) ((reg) * 2) +#else +#define CS89x0_PORT(reg) (reg) +#endif + #define PP_ChipID 0x0000 /* offset 0h -> Corp -ID */ /* offset 2h -> Model/Product Number */ /* offset 3h -> Chip Revision Number */ @@ -324,16 +331,16 @@ #define RAM_SIZE 0x1000 /* The card has 4k bytes or RAM */ #define PKT_START PP_TxFrame /* Start of packet RAM */ -#define RX_FRAME_PORT 0x0000 +#define RX_FRAME_PORT CS89x0_PORT(0x0000) #define TX_FRAME_PORT RX_FRAME_PORT -#define TX_CMD_PORT 0x0004 +#define TX_CMD_PORT CS89x0_PORT(0x0004) #define TX_NOW 0x0000 /* Tx packet after 5 bytes copied */ #define TX_AFTER_381 0x0040 /* Tx packet after 381 bytes copied */ #define TX_AFTER_ALL 0x00c0 /* Tx packet after all bytes copied */ -#define TX_LEN_PORT 0x0006 -#define ISQ_PORT 0x0008 -#define ADD_PORT 0x000A -#define DATA_PORT 0x000C +#define TX_LEN_PORT CS89x0_PORT(0x0006) +#define ISQ_PORT CS89x0_PORT(0x0008) +#define ADD_PORT CS89x0_PORT(0x000A) +#define DATA_PORT CS89x0_PORT(0x000C) #define EEPROM_WRITE_EN 0x00F0 #define EEPROM_WRITE_DIS 0x0000 Signed-off-by: Deepak Saxena -- Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/ "Unlike me, many of you have accepted the situation of your imprisonment and will die here like rotten cabbages." - Number 6 From hadi@cyberus.ca Fri Jul 16 06:04:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 06:04:44 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GD4bZ2031206 for ; Fri, 16 Jul 2004 06:04:37 -0700 Received: from mx02.cybersurf.com ([IPv6:::ffff:209.197.145.105]:21165 "EHLO mx02.cybersurf.com") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 14:04:35 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BlSO4-0007Qx-T2 for netdev@linux-mips.org; Fri, 16 Jul 2004 09:04:28 -0400 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 1BlSO2-0000S7-Gr; Fri, 16 Jul 2004 09:04:26 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <20040715235313.69897131@zanzibar.2ka.mipt.ru> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> Content-Type: multipart/mixed; boundary="=-YqzZqbFM9C1jXaX6bkbO" Organization: jamalopolis Message-Id: <1089983064.1060.1328.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Jul 2004 09:04:24 -0400 X-archive-position: 7004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4802 Lines: 152 --=-YqzZqbFM9C1jXaX6bkbO Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2004-07-15 at 15:53, Evgeniy Polyakov wrote: > On 15 Jul 2004 13:24:45 -0400 > jamal wrote: > > What is it that CARP does that couldnt be achieved by VRRP? > > I will answer a question by question, sorry. ;-> > Has vrrp some authentification mechanism? They (at least used to) claim to be able to do so. > Can it be used over IPv6? (CARP also can't but it is _very_ easy to > add, I just don't have IPv6 network setup to test). Theres effort to have it do v6. http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-06.txt I agree its lame to have it as an after thought it seems > May someone use vrrp in private commercial enviroment without fear of > being convicted? That i dont know. > > > > Can you explain a little more what you mean by "attching" to > > master/slave? > > Consider using some abstraction layer which makes some decisions based > on knowledge of current HA state. sure; make it an API/callback/event to/from the carp daemon to other applications. > It looks like we do not understand each other :) > Here is the explanation of the ct_sync: > http://cvs.netfilter.org/netfilter-ha/README?rev=1.2&content-type=text/vnd.viewcvs-markup > > Harald Welte will have a talk about ct_sync at OLS. Ok, good. Maybe if you too come to OLS we can settle this ;-> Looking at what HArald has, the infrastructure seems to be the correct flavor. Seems something gets sent to user space via netlink and gets delivered via keepalived. I think the CARP loadbalancing feature is an improvement over what is being suggested by Harald. I have to say as well i am shocked that state is just being transfered blindly - but i will deal with Harald when he shows up in Ottawa ;-> > > What do you mean realtime traffic? > > Is it something that can be achieved by qos prioritization? > > Yes it can. But who will control prioritization mechanism? > Maybe userspace. > But with such approach we need to create each time we need kernel access > a kernel agent with it's own kernel<->user protocol, it's own connect > to master/slave arbiter... > With CARP just create one function in kernelspace and register it in > CARP using provided mechanism. bah. Ok, now you are forcing me to draw diagrams. I attached to avouid it being mangled. > > In the end CISCO is going to be the loser in this of because > > something like CARP will take off and it cant talk to them. At the > > moment though they do have the market so interoping with them is > > valuable. > > It is just marketing... > The better software the more market it can eat. Theoretically... I am afraid even if that sounds logical it doesnt work like that. Too many stupid people. If it worked like that MS would be dead and buried a few years ago. > In theory practice and theory are the same, but in practice they are > different. (c) Larry McVoy. Agreed. > Why use not good software and has even theoretical possibility to be > convicted when we have free successor( :) I said it? Nah... ). Ok, keep spreading fear ;-> You are getting me worried now ;-> > I have great confidence that Theo de Raadt will not include non > patent-free code in OpenBSD. I hope he is a lawyer or has some good lawyer advising him;-> cheers, jamal --=-YqzZqbFM9C1jXaX6bkbO Content-Disposition: attachment; filename=e1 Content-Type: text/plain; name=e1; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit User space +-------+ | CARPd | <-----> Other apps +---+---+ | | - netlink to control ARP LB action | - netlink to talk to ct_sync | - netlink to control QoS rules | - PF_PACKET or raw socket to send/rcv CARP pkts | ----------------------------------- Kernel network I/O etc Apps interface to Carpd to send CARP encapulated packets i was talking about earlier. With that thought lest redraw the diagram: User space +-------+ +-------+ +---------+ | App#X | <-----> | CARPd | <-----> | ctsyncd | +---+---+ +---+---+ +---+-----+ | | | | ------------------------------------------ Kernel network I/O etc So now ct_sync control is not owned by carpd. Rather. ctsync listens to the netlink msgs from the kernel, builds an app msg, passes it carpd which will send it if state is right. Note such a mesage which can be used by apps doesnt exist today, it would need to be defined. Apps could also register callbacks for events such as mastership transitions. --=-YqzZqbFM9C1jXaX6bkbO-- From hadi@cyberus.ca Fri Jul 16 06:09:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 06:10:02 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GD9uhj031671 for ; Fri, 16 Jul 2004 06:09:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BlSTI-0004XE-5j for netdev@oss.sgi.com; Fri, 16 Jul 2004 09:09:52 -0400 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 1BlSTF-00012W-S6; Fri, 16 Jul 2004 09:09:50 -0400 Subject: Re: [PATCH] Add IXDP2x01 board support to CS89x0 driver From: jamal Reply-To: hadi@cyberus.ca To: dsaxena@plexity.net Cc: jgarkzik@pobox.om, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040716092859.GA16849@plexity.net> References: <20040716092859.GA16849@plexity.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1089983382.1060.1332.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Jul 2004 09:09:42 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7005 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 292 Lines: 13 On Fri, 2004-07-16 at 05:28, Deepak Saxena wrote: > Jeff, > > The following patch modifies the CS89x0 driver to work on Intel's IXDP2401 > and IXDP2801 (Intel ARm/XScale based) platforms: > cool. Do you need anything else that is not in the kernel to boot either board? cheers, jamal From johnpol@2ka.mipt.ru Fri Jul 16 08:01:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 08:01:45 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GF1V9t009568 for ; Fri, 16 Jul 2004 08:01:33 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6GF13QO011871; Fri, 16 Jul 2004 19:01:04 +0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089981282.1060.1293.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> <1089912658.1029.101.camel@jzny.localdomain> <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> <1089981282.1060.1293.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+LSsMhrJDoe8R3omHZBp" Organization: MIPT Message-Id: <1089990384.6114.2842.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 16 Jul 2004 19:06:24 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 7006 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-+LSsMhrJDoe8R3omHZBp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-07-16 at 16:34, jamal wrote: > > If I am a master, than get half of bandwidth, but if slave count is > > less than threshold than get more. > > If I am a slave and slave count is more than threshold than get > > 0.5/slave_count of the bandwidth and reserve some else get... >=20 > Ok, so some controller is in charge - seems like thats something that > could be easily done in user space based on mastership transitions. Yes, but here is tricky but true example: Some time ago e1000 driver from Intel had possibility to do hardware bonding(i absolutely don't remember how it was called, but idea was the same as in bonding). Consider following scenario: if node is a master than it enables this bonding mode using e1000 internal registers. Ethtools doesn't support those mode. yes it also can be enabled through patching userspace, but with kernel CARP it is not needed. Or consider TGE example(...wireless HA... strange sentence, but...): If I am a master, than enable higher priority in driver. Current tc design can't be mapped to driver's internal structures :> But the main killer is following: consider firewall with thousands iptables rules, and if node becomes a master it needs to add or remove some rules from table. Copying such amounts to/from userspace/kernelspace memory will take _minutes_... Even using iptables chains. But kernel implementation may just add one rule. Yet another variant: you need to access CPU internal registers based on HA state, kind of turning on or off additional hotplug CPU and or memory, enabling/disabling NUMA access. Can you enable/disable bus arbiter from userspace? For example I'm using on-chip SDRAM in PPC440 as L2 cache or as jitter buffer for OPB access, decision to use each mode is based on some hardware loads. Userspace do not have access to such mechanism. It is deep kernel internals, and I do not see any good reason to export it to userspace. Actually last example can't be used as argument in our discussion, but it illustrates that sometimes we need to touch kernel-_only_ parts, and this decision is dictated from the outside of the touchable part. > > What about case when you do need kernel space access based on CARP > > state? >=20 > What kind of access? To configure something? what kind of thing? Some kind of scenarios above? > > It is case of abstraction: for some reason(and for most of all) you do > > not need kernel space implementation. > > But reasons do exist to use it in kernel space, and if it will become a= n > > issue some day, you will anyway create a kernel agent. If you need > > kernel access in HA system, do not create new agents, just use CARP as > > kernel agent and arbiter. >=20 > Iam not buying it Evgeniy, sorry ;-> I see :) > BTW, I like that ARP balancing feature that CARP has. Pretty neat. > Note that it could be easily done via a tc action with user space > control. Anything may be done in userspace. For example routing decision. Yes, it _may_ be done in userspace. But it is slow. SCSI over IP may be done as network block device. Or even copying packet to userspace through raw device and then send it using socket. QNX and Mach are even designed in this way. It is not talk about current possibilities, it is kind of design :) Yes, probably our _current_ needs may be satisfied using existing userspace tools. But I absolutely sure that we will need in-kernel support. I'm reading you second e-mail with pretty diagrams and already see where in-kernel CARP will live there :) > cheers, > jamal --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-+LSsMhrJDoe8R3omHZBp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9+7wIKTPhE+8wY0RArRVAJwOr1JqADlAw1lo2DuL1NRQvGx2pQCgl/k7 Hy3KqUN5YH3FruhYjvXtqNY= =Drpx -----END PGP SIGNATURE----- --=-+LSsMhrJDoe8R3omHZBp-- From johnpol@2ka.mipt.ru Fri Jul 16 08:01:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 08:01:52 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GF1esN009580 for ; Fri, 16 Jul 2004 08:01:41 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i6GF1Kjk011885; Fri, 16 Jul 2004 19:01:20 +0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089983064.1060.1328.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2b92lDLt1Vcl4kBLFbER" Organization: MIPT Message-Id: <1089990401.6114.2843.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 16 Jul 2004 19:06:41 +0400 X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 7007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-2b92lDLt1Vcl4kBLFbER Content-Type: multipart/mixed; boundary="=-WV3BhdYCLmcV66kUoF4c" --=-WV3BhdYCLmcV66kUoF4c Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-07-16 at 17:04, jamal wrote: > > Has vrrp some authentification mechanism? >=20 > They (at least used to) claim to be able to do so. Hm... Quote from draft-ietf-vrrp-spec-v2-08.txt 5.3.6.1 Authentication Type 0 5.3.6.2 Authentication Type 1 5.3.6.3 Authentication Type 2 1. 8bit virtual host ID. 2. Plain password. 3. HMAC. I think even 3 is not good. They do strong signed digest, but it does not have any kind of counter so i do not see replay attack prevention. > > Can it be used over IPv6? (CARP also can't but it is _very_ easy to > > add, I just don't have IPv6 network setup to test). >=20 > Theres effort to have it do v6. > http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-06.txt > I agree its lame to have it as an after thought it seems * VRRP for IPv6 does not currently include any type of authentication. * > > > Can you explain a little more what you mean by "attching" to > > > master/slave? > >=20 > > Consider using some abstraction layer which makes some decisions based > > on knowledge of current HA state. >=20 > sure; make it an API/callback/event to/from the carp daemon to other > applications. >=20 > > It looks like we do not understand each other :) > > Here is the explanation of the ct_sync: > > http://cvs.netfilter.org/netfilter-ha/README?rev=3D1.2&content-type=3Dt= ext/vnd.viewcvs-markup > >=20 > > Harald Welte will have a talk about ct_sync at OLS. >=20 >=20 > Ok, good. Maybe if you too come to OLS we can settle this ;-> :) Unfortunately no... > Looking at what HArald has, the infrastructure seems to be the correct > flavor. Seems something gets sent to user space via netlink and gets > delivered via keepalived. > I think the CARP loadbalancing feature is an improvement over what is > being suggested by Harald. > I have to say as well i am shocked that state is just being transfered > blindly - but i will deal with Harald when he shows up in Ottawa ;-> Harald, sorry :) > > > What do you mean realtime traffic? > > > Is it something that can be achieved by qos prioritization? > >=20 > > Yes it can. But who will control prioritization mechanism? > > Maybe userspace. > > But with such approach we need to create each time we need kernel acces= s > > a kernel agent with it's own kernel<->user protocol, it's own connect > > to master/slave arbiter... > > With CARP just create one function in kernelspace and register it in > > CARP using provided mechanism. >=20 > bah. > Ok, now you are forcing me to draw diagrams. > > I attached to avouid it being mangled. I will draw one too. > > > In the end CISCO is going to be the loser in this of because=20 > > > something like CARP will take off and it cant talk to them. At the > > > moment though they do have the market so interoping with them is > > > valuable. > >=20 > > It is just marketing... > > The better software the more market it can eat. Theoretically... >=20 > I am afraid even if that sounds logical it doesnt work like that. > Too many stupid people. If it worked like that MS would be dead and > buried a few years ago. For those who cares they are already done. > > I have great confidence that Theo de Raadt will not include non > > patent-free code in OpenBSD. >=20 > I hope he is a lawyer or has some good lawyer advising him;-> He is an OpenBSD creator, so he is just a bit more paranoidal than others :) > cheers, > jamal --=20 Evgeniy Polaykov ( s0mbre ) Crash is better than data corruption. -- Art Grabowski --=-WV3BhdYCLmcV66kUoF4c Content-Disposition: attachment; filename=carp_diagram.1 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=carp_diagram.1; charset=koi8-r Tm8sIHlvdXIgZGlhZ3JhbSBzaG91bGQgbG9va3MgbGlrZSB0aGlzOg0KDQogICAgICAgICBVc2Vy IHNwYWNlDQogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KCQkgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICAgIHwgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgfA0KCQkgICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8DQorLS0tLS0tLSsgICAgICAgICArLS0tLS0tLSsgICAgICAg ICArLS0tLS0tLS0tKyAgICAgICAgICstLS0tLS0tKyAgICAgICAgICArLS0tLS0tLSsgICAgICAg ICAgDQp8IEFwcCNYIHwgPC0tLS0tPiB8IENBUlBkIHwgPC0tLS0tPiB8IGN0c3luY2QgfCA8LS0t LS0+IHwgQXBwI1ggfCA8LS0tLS0+ICB8IEFwcCNYIHwgPC0tLS0tPiANCistLS0rLS0tKyAgICAg ICAgICstLS0rLS0tKyAgICAgICAgICstLS0rLS0tLS0rICAgICAgICAgKy0tLSstLS0rICAgICAg ICAgICstLS0rLS0tKyAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIA0KICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgIEtlcm5lbA0KICAgICAgICBuZXR3 b3JrIEkvTyBldGMNCg0KT3Igb25seSBoYXZlIG9uZSBCVVMoYW5kIGl0IGlzIGFjdHVhbGx5IGlt cGxlbWVudGVkIHVzaW5nIG5ldGxpbmspLg0KDQpZb3UgbmVlZCB0byBjb25uZWN0IGVhY2ggYXBw bGljYXRpb24gZGFlbW9uIHRvIGNhcnBkLCBldmVuIHVzaW5nIGJyb2FkY2FzdCBuZXRsaW5rLg0K QW5kIGZvciBhbnkgaW4ta2VybmVsIGFjY2VzcyB5b3Ugd2lsbCBuZWVkIHRvIGNyZWF0ZSBuZXcg QXBwIGFuZCBuZXcga2VybmVsIHBhcnQuDQoNCklmIHdlIHdpbGwgZXh0cmFwb2xhdGUgaXQgd2Ug Y2FuIGNyZWF0ZSBmb2xsb3dpbmc6DQp1c2Vyc3BhY2UgY2FycCBkZXRlcm1pbmVzIHRoYXQgaXQg aXMgYSBtYXN0ZXIsIGl0IHdpbGwgc3VzcGVuZCBhbGwga2VybmVsIG1lbW9yeSBvciBkdW1wIC9w cm9jL2ttZW0NCmFuZCBiZWdpbnMgdG8gYWR2ZXJ0aXNlIGl0LiBSZW1vdGUgbm9kZSByZWNlaXZl cyBpdCBhbmQgaGFzIHByZXR0eSB0aGUgc2FtZSBmaXJld2FsbCBzZXR0aW5ncywgDQpmbG93IGNv bnRyb2xzIGFuZCBhbnkgaW4ta2VybmVsIHN0YXRlLg0KTm8gbWF0dGVyIHRoYXQgaXQgdGFrZXMg YSBsb25nIHRpbWUuDQoNCg0KSXQgbWFrZSBzZW5jZSBpZiBBcHAjWCBuZWVkcyB1c2Vyc3BhY2Ug YWNjZXNzIG9ubHkuDQpCdXQgaGVyZSBpcyBvdGhlciBkaWFncmFtOg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlcnNwYWNlDQogICAgICAgICAgICAgICAgIHwN Ci0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAg ICAgICAgICAgICBDQVJQICAgICAgICAgICAgICAgICAga2VybmVsc3BhY2UNCiAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICB8DQorLS0tLS0tLS0tLSstLS0tLSstLS0tLSstLS0t LS0tLS0rLS0tLS0tLQ0KfCAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KY3Rfc3lu YyAgaVNDU0kgICAgICAgZTEwMDAgICAgICBDUFUNCg0KDQpNeSBtYWluIGlkZWEgZm9yIGluLWtl cm5lbCBDQVJQIHdhcyB0byBpbXBsZW1lbnQgaW52aXNpYmxlIEhBIG1lY2hhbmlzbSBzdWl0YWJs ZSBmb3IgaW4ta2VybmVsIHVzZS4NCllvdSBkbyBub3QgbmVlZCB0byBjcmVhdGUgbmV0bGluayBw cm90b2NvbCBwYXJzZXIsIHlvdSBkbyBub3QgbmVlZCB0byBjcmVhdGUgZXh0cmEgdXNlcnNwYWNl IG92ZXJoZWFkLA0KeW91IGRvIG5vdCBuZWVkIHRvIGNyZWF0ZSBzdWl0YWJsZSBmb3IgdXNlcnNw YWNlIGNvbnRyb2wgaG9va3MgaW4ga2VybmVsIGluZnJhc3RydWN0dXJlLg0KSnVzdCByZWdpc3Rl ciBjYWxsYmFjay4NCkJ1dCBldmVuIHdpdGggc3VjaCBzaW1wbGUgYXBwcm9hY2ggeW91IGhhdmUg b3Bwb3J0dW5pdHkgdG8gY29sbGFib3JhdGUgd2l0aCB1c2Vyc3BhY2UuIElmIHlvdSBuZWVkLg0K DQpXaHkgY3JlYXRpbmcgYWxsIHVzZXJzcGFjZSBjcnVmdCBpZi93aGVuIHlvdSBuZWVkIG9ubHkg a2VybmVsIG9uZT8NCg0KDQpSZXN1bWU6IA0KV2l0aCB5b3VyIGFwcHJvYWNoIGFueSBkYXRhIGZs b3cgTVVTVCBnbyB0aHJvdWdoIHVzZXJzcGFjZSBhcmJpdGVycyB3aXRoIGFsbCBvdmVyaGVhZCBh bmQgY29tcGxleGl0eS4NCldpdGggbXkgYXBwcm9hY2ggYW55IGRhdGEgZmxvdyBfTUFZXyBnbyB0 aHJvdWdoIHVzZXJzcGFjZSBhcmJpdGVycywgYnV0IGlmIHlvdSBkb19uZWVkL29ubHlfaGFzIA0K aW4ta2VybmVsIGFjY2VzcyB0aGFuIHVzaW5nIGluLWtlcm5lbCBDQVJQIGlzIHRoZSBvbmx5IHNv bHV0aW9uLg0K --=-WV3BhdYCLmcV66kUoF4c-- --=-2b92lDLt1Vcl4kBLFbER Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA9+8BIKTPhE+8wY0RAnt+AJ91oyr4of3i8A6cI0i3v/V2WSfgrACfS6ND plBwcsbRmlvqcW19HhzRitc= =NPUK -----END PGP SIGNATURE----- --=-2b92lDLt1Vcl4kBLFbER-- From brianm@fsg1.nws.noaa.gov Fri Jul 16 08:02:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 08:03:03 -0700 (PDT) Received: from fsg1.nws.noaa.gov (fsg1.nws.noaa.gov [140.90.91.103]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GF2ph5009928 for ; Fri, 16 Jul 2004 08:02:51 -0700 Received: from localhost (brianm@localhost) by fsg1.nws.noaa.gov (8.11.6/8.11.2) with ESMTP id i6GF1dB24857; Fri, 16 Jul 2004 11:01:49 -0400 Date: Fri, 16 Jul 2004 11:01:39 -0400 (EDT) From: Brian McEntire To: kaos@ocs.com.au, , , , Subject: Suggestions with hard lockup on 4 systems, have oops report Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1519150939-2025421746-1089990099=:20914" X-archive-position: 7008 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brianm@fsg1.nws.noaa.gov Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1519150939-2025421746-1089990099=:20914 Content-Type: TEXT/PLAIN; charset=US-ASCII Thank you for taking time from your busy days to read this. You all (kernel maintainers) rock! :) I have four Linux hosts, with identical hardware and OSs, that exhibit a very tough to troubleshoot hang/freeze. About once every two weeks (and infrequently, up to a couple of times a day) these systems lock up. I cannot ping them, cannot toggle caps lock or num lock, nor get any mouse movement. Even the Magic SysRQ key, enabled just while troubleshooting this issue, does not respond. (I have tested to make sure it works when the systems are not frozen.) The screen can be blank or frozen with a GNOME desktop visible. When it locks, it does not write an OOPS to the screen, nor to /var/log/messages, nor to the remote log host although syslog.conf is set up and does log to them under normal conditions. I connected a serial terminal and was able to capture an oops report there and have run it though ksymoops on the system where it was captured. That is attached (run through ksymoops) to this e-mail. This has proven impossible (so far) to replicate on demand. I've tried looping kernel compiles to stress test the CPUs, and replicated that test with the source on an NFS mounted file system to stress the network sub system but I can't force the hang to happen. I used memtest86, the RAM checks out okay. I don't think it could be a hardware issue since it affects all 4 identical systems. I remade the swap partition with -c to check and mark bad blocks. These did not fix the hang. The systems are: Dual Xeon 2.4GHz processors 2 GB RAM 2 GB swap Ethernet controller: PCI device 14e4:16a7 (BROADCOM Corporation) (rev 2) Dual channel SCSI storage controller: PCI device 1000:0030 (Symbios Logic Inc. (formerly NCR)) (rev 7) VGA compatible controller: nVidia Corporation NV11 Matrox Graphics, Inc. MGA G400 AGP The OS specifics: RH 7.2 with latest patches except running kernel 2.4.9-31enterprise for CM reasons (at one point, I tried the latest available RH 7.2 kernel but it did not improve stability so I went back.) bcm5700-7.1.22-1 nvidia ?? (no RPM listed, didn't know where to find the version.) I have been logging /proc/meminfo and `uptime` into a file in /tmp every minute. Load isn't usually above 1 when the systems lock. 0-10 people are on the system. Sometimes it happens during work hours, other times over night or over the weekend when no one is running any interactive commands. * HighFree and especially LowFree usually approach zero just before the hang. Also, although swap is enabled (`free` shows it and kswapd is running,) SwapUsed never goes above 0 for the duration of the uptime. Any ideas? I understand this is an old kernel and BCM5700 is a proprietary driver module so there may be little anyone can offer. But, just in case the swap is an issue, or the bug stems from something other than just the network module, I wanted to send a report in and see if anyone has ideas or fixes. Thank you so much! Brian McEntire [ksymoops output attached.] Also, tried Linus's trick to 'disassemble the "Code:" part' ... this doesn't mean anything to me but maybe its a big clue to someone else: (gdb) disassemble str Dump of assembler code for function str: 0x8049384 : movl $0x0,(%ebx) 0x804938a : mov 0xffffffec(%ebp),%ecx 0x804938d : mov %ebx,0x4(%esp,1) 0x8049391 : mov %ecx,(%esp,1) 0x8049394 : call 0x804fd15 0x8049399 : add %al,(%eax) 0x804939b : add %al,(%eax) End of assembler dump. --1519150939-2025421746-1089990099=:20914 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=oopstrace Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=oopstrace a3N5bW9vcHMgMi40LjEgb24gaTY4NiAyLjQuOS0zMWVudGVycHJpc2UuICBP cHRpb25zIHVzZWQNCiAgICAgLXYgL2Jvb3Qvdm1saW51ei0yLjQuOS0zMWVu dGVycHJpc2UgKHNwZWNpZmllZCkNCiAgICAgLWsgL3Byb2Mva3N5bXMgKGRl ZmF1bHQpDQogICAgIC1sIC9wcm9jL21vZHVsZXMgKGRlZmF1bHQpDQogICAg IC1vIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2UvIChkZWZhdWx0 KQ0KICAgICAtbSAvYm9vdC9TeXN0ZW0ubWFwLTIuNC45LTMxZW50ZXJwcmlz ZSAoZGVmYXVsdCkNCg0KRXJyb3IgKHBjbG9zZV9sb2NhbCk6IHJlYWRfbm1f c3ltYm9scyBwY2xvc2UgZmFpbGVkIDB4MTAwDQpXYXJuaW5nIChyZWFkX3Zt bGludXgpOiBubyBrZXJuZWwgc3ltYm9scyBpbiB2bWxpbnV4LCBpcyAvYm9v dC92bWxpbnV6LTIuNC45LTMxZW50ZXJwcmlzZSBhIHZhbGlkIHZtbGludXgg ZmlsZT8NCkVycm9yIChleHBhbmRfb2JqZWN0cyk6IGNhbm5vdCBzdGF0KC9s aWIvZXh0My5vKSBmb3IgZXh0Mw0KRXJyb3IgKGV4cGFuZF9vYmplY3RzKTog Y2Fubm90IHN0YXQoL2xpYi9qYmQubykgZm9yIGpiZA0KRXJyb3IgKGV4cGFu ZF9vYmplY3RzKTogY2Fubm90IHN0YXQoL2xpYi9tcHRzY3NpaC5vKSBmb3Ig bXB0c2NzaWgNCkVycm9yIChleHBhbmRfb2JqZWN0cyk6IGNhbm5vdCBzdGF0 KC9saWIvbXB0YmFzZS5vKSBmb3IgbXB0YmFzZQ0KRXJyb3IgKGV4cGFuZF9v YmplY3RzKTogY2Fubm90IHN0YXQoL2xpYi9zZF9tb2QubykgZm9yIHNkX21v ZA0KRXJyb3IgKGV4cGFuZF9vYmplY3RzKTogY2Fubm90IHN0YXQoL2xpYi9z Y3NpX21vZC5vKSBmb3Igc2NzaV9tb2QNCldhcm5pbmcgKGNvbXBhcmVfbWFw cyk6IGtzeW1zX2Jhc2Ugc3ltYm9sIEdQTE9OTFlfSU9fQVBJQ19nZXRfUENJ X2lycV92ZWN0b3Igbm90IGZvdW5kIGluIFN5c3RlbS5tYXAuICBJZ25vcmlu ZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBr c3ltc19iYXNlIHN5bWJvbCBHUExPTkxZX3BjaV9ocF9jaGFuZ2Vfc2xvdF9p bmZvIG5vdCBmb3VuZCBpbiBTeXN0ZW0ubWFwLiAgSWdub3Jpbmcga3N5bXNf YmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKToga3N5bXNfYmFz ZSBzeW1ib2wgR1BMT05MWV9wY2lfaHBfZGVyZWdpc3RlciBub3QgZm91bmQg aW4gU3lzdGVtLm1hcC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldh cm5pbmcgKGNvbXBhcmVfbWFwcyk6IGtzeW1zX2Jhc2Ugc3ltYm9sIEdQTE9O TFlfcGNpX2hwX3JlZ2lzdGVyIG5vdCBmb3VuZCBpbiBTeXN0ZW0ubWFwLiAg SWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9t YXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIF9fYnJsb2NrX2FycmF5ICAsIGtz eW1zX2Jhc2Ugc2F5cyBjMDJmMzNhMCwgU3lzdGVtLm1hcCBzYXlzIGMwMmYy MTYwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29t cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIF9jdHlwZSAgLCBrc3lt c19iYXNlIHNheXMgYzAyZjMyOGMsIFN5c3RlbS5tYXAgc2F5cyBjMDJmMjA0 Yy4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBh cmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBhYmlfZGVmaGFuZGxlcl9j b2ZmICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkY2EwYywgU3lzdGVtLm1hcCBz YXlzIGMwMmRiN2NjLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2Fy bmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGFiaV9k ZWZoYW5kbGVyX2VsZiAgLCBrc3ltc19iYXNlIHNheXMgYzAyZGNhMTAsIFN5 c3RlbS5tYXAgc2F5cyBjMDJkYjdkMC4gIElnbm9yaW5nIGtzeW1zX2Jhc2Ug ZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5 bWJvbCBhYmlfZGVmaGFuZGxlcl9sY2FsbDcgICwga3N5bXNfYmFzZSBzYXlz IGMwMmRjYTE0LCBTeXN0ZW0ubWFwIHNheXMgYzAyZGI3ZDQuICBJZ25vcmlu ZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBt aXNtYXRjaCBvbiBzeW1ib2wgYWJpX2RlZmhhbmRsZXJfbGliY3NvICAsIGtz eW1zX2Jhc2Ugc2F5cyBjMDJkY2ExOCwgU3lzdGVtLm1hcCBzYXlzIGMwMmRi N2Q4LiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29t cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGFycF9icm9rZW5fb3Bz ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJmMTA0MCwgU3lzdGVtLm1hcCBzYXlz IGMwMmVmZTAwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2Fybmlu ZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGFycF90Ymwg ICwga3N5bXNfYmFzZSBzYXlzIGMwMmYxMDYwLCBTeXN0ZW0ubWFwIHNheXMg YzAyZWZlMjAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5n IChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgYmxrX2J1ZmZl cnNfd2FpdCAgLCBrc3ltc19iYXNlIHNheXMgYzAyZTg5NGMsIFN5c3RlbS5t YXAgc2F5cyBjMDJlNzcwYy4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkN Cldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBi b290X2NwdV9kYXRhICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkYjUwMCwgU3lz dGVtLm1hcCBzYXlzIGMwMmRhMmMwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBl bnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3lt Ym9sIGJyX2ZkYl9nZXRfaG9vayAgLCBrc3ltc19iYXNlIHNheXMgYzAyZjJk MDQsIFN5c3RlbS5tYXAgc2F5cyBjMDJmMWFjNC4gIElnbm9yaW5nIGtzeW1z X2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNo IG9uIHN5bWJvbCBicl9mZGJfcHV0X2hvb2sgICwga3N5bXNfYmFzZSBzYXlz IGMwMmYyZDA4LCBTeXN0ZW0ubWFwIHNheXMgYzAyZjFhYzguICBJZ25vcmlu ZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBt aXNtYXRjaCBvbiBzeW1ib2wgYnJfaGFuZGxlX2ZyYW1lX2hvb2sgICwga3N5 bXNfYmFzZSBzYXlzIGMwMmVmMTQ4LCBTeXN0ZW0ubWFwIHNheXMgYzAyZWRm MDguICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21w YXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgYnVmZmVybWVtX3BhZ2Vz ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkZjUxYywgU3lzdGVtLm1hcCBzYXlz IGMwMmRlMmRjLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2Fybmlu ZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGNhcF9ic2V0 ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkZDlhYywgU3lzdGVtLm1hcCBzYXlz IGMwMmRjNzZjLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2Fybmlu ZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGNvbG9yX3Rh YmxlICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJlMmI3YywgU3lzdGVtLm1hcCBz YXlzIGMwMmUxOTNjLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2Fy bmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGRjYWNo ZV9sb2NrICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkZmE3OCwgU3lzdGVtLm1h cCBzYXlzIGMwMmRlODM4LiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0K V2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGRl Zl9ibGtfZm9wcyAgLCBrc3ltc19iYXNlIHNheXMgYzAyZGY2NDAsIFN5c3Rl bS5tYXAgc2F5cyBjMDJkZTQwMC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50 cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJv bCBkZWZhdWx0X2JsdSAgLCBrc3ltc19iYXNlIHNheXMgYzAyZTJjMGMsIFN5 c3RlbS5tYXAgc2F5cyBjMDJlMTljYy4gIElnbm9yaW5nIGtzeW1zX2Jhc2Ug ZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5 bWJvbCBkZWZhdWx0X2dybiAgLCBrc3ltc19iYXNlIHNheXMgYzAyZTJiY2Ms IFN5c3RlbS5tYXAgc2F5cyBjMDJlMTk4Yy4gIElnbm9yaW5nIGtzeW1zX2Jh c2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9u IHN5bWJvbCBkZWZhdWx0X3JlZCAgLCBrc3ltc19iYXNlIHNheXMgYzAyZTJi OGMsIFN5c3RlbS5tYXAgc2F5cyBjMDJlMTk0Yy4gIElnbm9yaW5nIGtzeW1z X2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNo IG9uIHN5bWJvbCBkZXZfYmFzZSAgLCBrc3ltc19iYXNlIHNheXMgYzAyZWI3 M2MsIFN5c3RlbS5tYXAgc2F5cyBjMDJlYTRmYy4gIElnbm9yaW5nIGtzeW1z X2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNo IG9uIHN5bWJvbCBkZXZfYmFzZV9sb2NrICAsIGtzeW1zX2Jhc2Ugc2F5cyBj MDJlYjc0MCwgU3lzdGVtLm1hcCBzYXlzIGMwMmVhNTAwLiAgSWdub3Jpbmcg a3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlz bWF0Y2ggb24gc3ltYm9sIGRtYV9zcGluX2xvY2sgICwga3N5bXNfYmFzZSBz YXlzIGMwMmRjOGMwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZGI2ODAuICBJZ25v cmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMp OiBtaXNtYXRjaCBvbiBzeW1ib2wgZmJjb25fY2ZiMTYgICwga3N5bXNfYmFz ZSBzYXlzIGMwMmVlNzQwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZWQ1MDAuICBJ Z25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21h cHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgZmJjb25fY2ZiMjQgICwga3N5bXNf YmFzZSBzYXlzIGMwMmVlNzgwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZWQ1NDAu ICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJl X21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgZmJjb25fY2ZiMzIgICwga3N5 bXNfYmFzZSBzYXlzIGMwMmVlN2MwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZWQ1 ODAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21w YXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgZmJjb25fY2ZiOCAgLCBr c3ltc19iYXNlIHNheXMgYzAyZWU2ZTAsIFN5c3RlbS5tYXAgc2F5cyBjMDJl ZDRhMC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNv bXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBmYmNvbl9kdW1teSAg LCBrc3ltc19iYXNlIHNheXMgYzAyZWU1MjAsIFN5c3RlbS5tYXAgc2F5cyBj MDJlZDJlMC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcg KGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBmaWxlX2xvY2tf bGlzdCAgLCBrc3ltc19iYXNlIHNheXMgYzAyZGZhNjgsIFN5c3RlbS5tYXAg c2F5cyBjMDJkZTgyOC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldh cm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBmaWxl c19sb2NrICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkZjQ5YywgU3lzdGVtLm1h cCBzYXlzIGMwMmRlMjVjLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0K V2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGZp bGVzX3N0YXQgICwga3N5bXNfYmFzZSBzYXlzIGMwMmRmNDgwLCBTeXN0ZW0u bWFwIHNheXMgYzAyZGUyNDAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5 DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wg ZnNfb3ZlcmZsb3dnaWQgICwga3N5bXNfYmFzZSBzYXlzIGMwMmRkYTJjLCBT eXN0ZW0ubWFwIHNheXMgYzAyZGM3ZWMuICBJZ25vcmluZyBrc3ltc19iYXNl IGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBz eW1ib2wgZnNfb3ZlcmZsb3d1aWQgICwga3N5bXNfYmFzZSBzYXlzIGMwMmRk YTI4LCBTeXN0ZW0ubWFwIHNheXMgYzAyZGM3ZTguICBJZ25vcmluZyBrc3lt c19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRj aCBvbiBzeW1ib2wgZ2VuZXJpY19yb19mb3BzICAsIGtzeW1zX2Jhc2Ugc2F5 cyBjMDJkZjM0MCwgU3lzdGVtLm1hcCBzYXlzIGMwMmRlMTAwLiAgSWdub3Jp bmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTog bWlzbWF0Y2ggb24gc3ltYm9sIGdsb2JhbF9pcnFfaG9sZGVyICAsIGtzeW1z X2Jhc2Ugc2F5cyBjMDJkYWQ0MCwgU3lzdGVtLm1hcCBzYXlzIGMwMmQ5YjAw LiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFy ZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGhvdHBsdWdfcGF0aCAgLCBr c3ltc19iYXNlIHNheXMgYzAyZGRiODAsIFN5c3RlbS5tYXAgc2F5cyBjMDJk Yzk0MC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNv bXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBpZGVfZm9wcyAgLCBr c3ltc19iYXNlIHNheXMgYzAyZWI5YTgsIFN5c3RlbS5tYXAgc2F5cyBjMDJl YTc2OC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNv bXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBpZl9wb3J0X3RleHQg ICwga3N5bXNfYmFzZSBzYXlzIGMwMmVmMTA4LCBTeXN0ZW0ubWFwIHNheXMg YzAyZWRlYzguICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5n IChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgaW5ldF9kZ3Jh bV9vcHMgICwga3N5bXNfYmFzZSBzYXlzIGMwMmYxYTAwLCBTeXN0ZW0ubWFw IHNheXMgYzAyZjA3YzAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpX YXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgaW5l dF9mYW1pbHlfb3BzICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJmMWE0NCwgU3lz dGVtLm1hcCBzYXlzIGMwMmYwODA0LiAgSWdub3Jpbmcga3N5bXNfYmFzZSBl bnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3lt Ym9sIGluZXRfc3RyZWFtX29wcyAgLCBrc3ltc19iYXNlIHNheXMgYzAyZjE5 YTAsIFN5c3RlbS5tYXAgc2F5cyBjMDJmMDc2MC4gIElnbm9yaW5nIGtzeW1z X2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNo IG9uIHN5bWJvbCBpbmV0ZGV2X2xvY2sgICwga3N5bXNfYmFzZSBzYXlzIGMw MmYxNDk4LCBTeXN0ZW0ubWFwIHNheXMgYzAyZjAyNTguICBJZ25vcmluZyBr c3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNt YXRjaCBvbiBzeW1ib2wgaW5pdF9tbSAgLCBrc3ltc19iYXNlIHNheXMgYzAy ZGE1YTAsIFN5c3RlbS5tYXAgc2F5cyBjMDJkOTM2MC4gIElnbm9yaW5nIGtz eW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21h dGNoIG9uIHN5bWJvbCBpb19yZXF1ZXN0X2xvY2sgICwga3N5bXNfYmFzZSBz YXlzIGMwMmU4OTQ4LCBTeXN0ZW0ubWFwIHNheXMgYzAyZTc3MDguICBJZ25v cmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMp OiBtaXNtYXRjaCBvbiBzeW1ib2wgaW9tZW1fcmVzb3VyY2UgICwga3N5bXNf YmFzZSBzYXlzIGMwMmRjY2Q4LCBTeXN0ZW0ubWFwIHNheXMgYzAyZGJhOTgu ICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJl X21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgaW9wb3J0X3Jlc291cmNlICAs IGtzeW1zX2Jhc2Ugc2F5cyBjMDJkY2NiYywgU3lzdGVtLm1hcCBzYXlzIGMw MmRiYTdjLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAo Y29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGlwdjRfc3BlY2lm aWMgICwga3N5bXNfYmFzZSBzYXlzIGMwMmYwMTYwLCBTeXN0ZW0ubWFwIHNh eXMgYzAyZWVmMjAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJu aW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgaXNhcG5w X2NhcmRzICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJlYzgwMCwgU3lzdGVtLm1h cCBzYXlzIGMwMmViNWMwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0K V2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGlz YXBucF9kZXZpY2VzICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJlYzgwOCwgU3lz dGVtLm1hcCBzYXlzIGMwMmViNWM4LiAgSWdub3Jpbmcga3N5bXNfYmFzZSBl bnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3lt Ym9sIGpoX3NwbGljZV9sb2NrICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkZmI4 YywgU3lzdGVtLm1hcCBzYXlzIGMwMmRlOTRjLiAgSWdub3Jpbmcga3N5bXNf YmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2gg b24gc3ltYm9sIGpvdXJuYWxfb29tX3JldHJ5ICAsIGtzeW1zX2Jhc2Ugc2F5 cyBjMDJkZmI5MCwgU3lzdGVtLm1hcCBzYXlzIGMwMmRlOTUwLiAgSWdub3Jp bmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTog bWlzbWF0Y2ggb24gc3ltYm9sIGtlcm5lbF9mbGFnICAsIGtzeW1zX2Jhc2Ug c2F5cyBjMDJkYmUwMCwgU3lzdGVtLm1hcCBzYXlzIGMwMmRhYmMwLiAgSWdu b3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBz KTogbWlzbWF0Y2ggb24gc3ltYm9sIGtleWJvYXJkX3Rhc2tsZXQgICwga3N5 bXNfYmFzZSBzYXlzIGMwMmU3MjJjLCBTeXN0ZW0ubWFwIHNheXMgYzAyZTVm ZWMuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21w YXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgbG9vcGJhY2tfZGV2ICAs IGtzeW1zX2Jhc2Ugc2F5cyBjMDJlYjYwMCwgU3lzdGVtLm1hcCBzYXlzIGMw MmVhM2MwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAo Y29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIGxvb3BzX3Blcl9q aWZmeSAgLCBrc3ltc19iYXNlIHNheXMgYzAyZGE2YzgsIFN5c3RlbS5tYXAg c2F5cyBjMDJkOTQ4OC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldh cm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBuZnNk X2xpbmthZ2UgICwga3N5bXNfYmFzZSBzYXlzIGMwMmRmYjg4LCBTeXN0ZW0u bWFwIHNheXMgYzAyZGU5NDguICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5 DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wg bm9vcF9xZGlzYyAgLCBrc3ltc19iYXNlIHNheXMgYzAyZWY5ODAsIFN5c3Rl bS5tYXAgc2F5cyBjMDJlZTc0MC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50 cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJv bCBvdmVyZmxvd2dpZCAgLCBrc3ltc19iYXNlIHNheXMgYzAyZGRhMjQsIFN5 c3RlbS5tYXAgc2F5cyBjMDJkYzdlNC4gIElnbm9yaW5nIGtzeW1zX2Jhc2Ug ZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5 bWJvbCBvdmVyZmxvd3VpZCAgLCBrc3ltc19iYXNlIHNheXMgYzAyZGRhMjAs IFN5c3RlbS5tYXAgc2F5cyBjMDJkYzdlMC4gIElnbm9yaW5nIGtzeW1zX2Jh c2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9u IHN5bWJvbCBwYWdlX2NhY2hlX3NpemUgICwga3N5bXNfYmFzZSBzYXlzIGMw MmRkZDYwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZGNiMjAuICBJZ25vcmluZyBr c3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNt YXRjaCBvbiBzeW1ib2wgcGFnZV9zeW1saW5rX2lub2RlX29wZXJhdGlvbnMg ICwga3N5bXNfYmFzZSBzYXlzIGMwMmRmOWEwLCBTeXN0ZW0ubWFwIHNheXMg YzAyZGU3NjAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5n IChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgcGFydGl0aW9u X25hbWUgICwga3N5bXNfYmFzZSBzYXlzIGMwMWMzZjgwLCBTeXN0ZW0ubWFw IHNheXMgYzAxNjJjZjAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpX YXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgcGNp X2RldmljZXMgICwga3N5bXNfYmFzZSBzYXlzIGMwMmVjNGE4LCBTeXN0ZW0u bWFwIHNheXMgYzAyZWIyNjguICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5 DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wg cGNpX21lbV9zdGFydCAgLCBrc3ltc19iYXNlIHNheXMgYzAyZGI1OTQsIFN5 c3RlbS5tYXAgc2F5cyBjMDJkYTM1NC4gIElnbm9yaW5nIGtzeW1zX2Jhc2Ug ZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5 bWJvbCBwY2lfcm9vdF9idXNlcyAgLCBrc3ltc19iYXNlIHNheXMgYzAyZWM0 YTAsIFN5c3RlbS5tYXAgc2F5cyBjMDJlYjI2MC4gIElnbm9yaW5nIGtzeW1z X2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNo IG9uIHN5bWJvbCBwZmlmb19xZGlzY19vcHMgICwga3N5bXNfYmFzZSBzYXlz IGMwMmVmYWUwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZWU4YTAuICBJZ25vcmlu ZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBt aXNtYXRjaCBvbiBzeW1ib2wgcHJvY19yb290ICAsIGtzeW1zX2Jhc2Ugc2F5 cyBjMDJkZmYwMCwgU3lzdGVtLm1hcCBzYXlzIGMwMmRlY2MwLiAgSWdub3Jp bmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTog bWlzbWF0Y2ggb24gc3ltYm9sIHFkaXNjX3RyZWVfbG9jayAgLCBrc3ltc19i YXNlIHNheXMgYzAyZWY5MjAsIFN5c3RlbS5tYXAgc2F5cyBjMDJlZTZlMC4g IElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVf bWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBydGNfbG9jayAgLCBrc3ltc19i YXNlIHNheXMgYzAyZGI5YTAsIFN5c3RlbS5tYXAgc2F5cyBjMDJkYTc2MC4g IElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVf bWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBydG5sX3NlbSAgLCBrc3ltc19i YXNlIHNheXMgYzAyZWY2MDAsIFN5c3RlbS5tYXAgc2F5cyBjMDJlZTNjMC4g IElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVf bWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBzZWN1cmViaXRzICAsIGtzeW1z X2Jhc2Ugc2F5cyBjMDJkYzgwMCwgU3lzdGVtLm1hcCBzYXlzIGMwMmRiNWMw LiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFy ZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHNtcF9udW1fY3B1cyAgLCBr c3ltc19iYXNlIHNheXMgYzAyZGJlMTAsIFN5c3RlbS5tYXAgc2F5cyBjMDJk YWJkMC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNv bXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBzb2NrZXRfZmlsZV9v cHMgICwga3N5bXNfYmFzZSBzYXlzIGMwMmVlZDgwLCBTeXN0ZW0ubWFwIHNh eXMgYzAyZWRiNDAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJu aW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgc3lzX2Nh bGxfdGFibGUgICwga3N5bXNfYmFzZSBzYXlzIGMwMmRhOGU0LCBTeXN0ZW0u bWFwIHNheXMgYzAyZDk2YTQuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5 DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wg c3lzX3R1eF9wdHIgICwga3N5bXNfYmFzZSBzYXlzIGMwMmVlZTc0LCBTeXN0 ZW0ubWFwIHNheXMgYzAyZWRjMzQuICBJZ25vcmluZyBrc3ltc19iYXNlIGVu dHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1i b2wgc3lzY3RsX2lwX2RlZmF1bHRfdHRsICAsIGtzeW1zX2Jhc2Ugc2F5cyBj MDJmMDA4MCwgU3lzdGVtLm1hcCBzYXlzIGMwMmVlZTQwLiAgSWdub3Jpbmcg a3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlz bWF0Y2ggb24gc3ltYm9sIHN5c2N0bF9sb2NhbF9wb3J0X3JhbmdlICAsIGtz eW1zX2Jhc2Ugc2F5cyBjMDJmMDEyNCwgU3lzdGVtLm1hcCBzYXlzIGMwMmVl ZWU0LiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29t cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHN5c2N0bF9tYXhfc3lu X2JhY2tsb2cgICwga3N5bXNfYmFzZSBzYXlzIGMwMmYwMTMwLCBTeXN0ZW0u bWFwIHNheXMgYzAyZWVlZjAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5 DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wg c3lzY3RsX3JtZW1fbWF4ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJlZWU4NCwg U3lzdGVtLm1hcCBzYXlzIGMwMmVkYzQ0LiAgSWdub3Jpbmcga3N5bXNfYmFz ZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24g c3ltYm9sIHN5c2N0bF90Y3BfZWNuICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJm MDBlMCwgU3lzdGVtLm1hcCBzYXlzIGMwMmVlZWEwLiAgSWdub3Jpbmcga3N5 bXNfYmFzZSBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0 Y2ggb24gc3ltYm9sIHN5c2N0bF90Y3BfcmVvcmRlcmluZyAgLCBrc3ltc19i YXNlIHNheXMgYzAyZjAwZGMsIFN5c3RlbS5tYXAgc2F5cyBjMDJlZWU5Yy4g IElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVf bWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBzeXNjdGxfdGNwX3JtZW0gICwg a3N5bXNfYmFzZSBzYXlzIGMwMmYwMGIwLCBTeXN0ZW0ubWFwIHNheXMgYzAy ZWVlNzAuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChj b21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgc3lzY3RsX3RjcF90 d19yZWN5Y2xlICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJmMDYyMCwgU3lzdGVt Lm1hcCBzYXlzIGMwMmVmM2UwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRy eQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9s IHN5c2N0bF90Y3Bfd21lbSAgLCBrc3ltc19iYXNlIHNheXMgYzAyZjAwYTQs IFN5c3RlbS5tYXAgc2F5cyBjMDJlZWU2NC4gIElnbm9yaW5nIGtzeW1zX2Jh c2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9u IHN5bWJvbCBzeXNjdGxfd21lbV9tYXggICwga3N5bXNfYmFzZSBzYXlzIGMw MmVlZTgwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZWRjNDAuICBJZ25vcmluZyBr c3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNt YXRjaCBvbiBzeW1ib2wgc3lzdGVtX3V0c25hbWUgICwga3N5bXNfYmFzZSBz YXlzIGMwMmRhNmUwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZDk0YTAuICBJZ25v cmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMp OiBtaXNtYXRjaCBvbiBzeW1ib2wgdGNwX3BvcnRfcm92ZXIgICwga3N5bXNf YmFzZSBzYXlzIGMwMmYwMTJjLCBTeXN0ZW0ubWFwIHNheXMgYzAyZWVlZWMu ICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJl X21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdGNwX3Byb3QgICwga3N5bXNf YmFzZSBzYXlzIGMwMmYwMWEwLCBTeXN0ZW0ubWFwIHNheXMgYzAyZWVmNjAu ICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJl X21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdHFfZGlzayAgLCBrc3ltc19i YXNlIHNheXMgYzAyZTg5NDAsIFN5c3RlbS5tYXAgc2F5cyBjMDJlNzcwMC4g IElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVf bWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCB0cV9pbW1lZGlhdGUgICwga3N5 bXNfYmFzZSBzYXlzIGMwMmRkOWM0LCBTeXN0ZW0ubWFwIHNheXMgYzAyZGM3 ODQuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21w YXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdHFfdGltZXIgICwga3N5 bXNfYmFzZSBzYXlzIGMwMmRkOWJjLCBTeXN0ZW0ubWFwIHNheXMgYzAyZGM3 N2MuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21w YXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdHF1ZXVlX2xvY2sgICwg a3N5bXNfYmFzZSBzYXlzIGMwMmRkOWY4LCBTeXN0ZW0ubWFwIHNheXMgYzAy ZGM3YjguICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChj b21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdHV4X21vZHVsZSAg LCBrc3ltc19iYXNlIHNheXMgYzAyZWVlNzgsIFN5c3RlbS5tYXAgc2F5cyBj MDJlZGMzOC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcg KGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCB0dXhfbW9kdWxl X2xvY2sgICwga3N5bXNfYmFzZSBzYXlzIGMwMmVlZTdjLCBTeXN0ZW0ubWFw IHNheXMgYzAyZWRjM2MuICBJZ25vcmluZyBrc3ltc19iYXNlIGVudHJ5DQpX YXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdWRw X2hhc2hfbG9jayAgLCBrc3ltc19iYXNlIHNheXMgYzAyZjBiNDAsIFN5c3Rl bS5tYXAgc2F5cyBjMDJlZjkwMC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50 cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJv bCB1ZHBfcHJvdCAgLCBrc3ltc19iYXNlIHNheXMgYzAyZjBiNjAsIFN5c3Rl bS5tYXAgc2F5cyBjMDJlZjkyMC4gIElnbm9yaW5nIGtzeW1zX2Jhc2UgZW50 cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJv bCB1dHNfc2VtICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDJkZGE1MCwgU3lzdGVt Lm1hcCBzYXlzIGMwMmRjODEwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRy eQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9s IHZtX21heF9yZWFkYWhlYWQgICwga3N5bXNfYmFzZSBzYXlzIGMwMmRkZDY0 LCBTeXN0ZW0ubWFwIHNheXMgYzAyZGNiMjQuICBJZ25vcmluZyBrc3ltc19i YXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBv biBzeW1ib2wgdm1fbWluX3JlYWRhaGVhZCAgLCBrc3ltc19iYXNlIHNheXMg YzAyZGRkNjgsIFN5c3RlbS5tYXAgc2F5cyBjMDJkY2IyOC4gIElnbm9yaW5n IGtzeW1zX2Jhc2UgZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1p c21hdGNoIG9uIHN5bWJvbCBfbnYwMDAxNzNybSAgLCBudmlkaWEgc2F5cyBm OGM3NTdjMCwgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJu ZWwvZHJpdmVycy92aWRlby9udmlkaWEubyBzYXlzIGY4Yzc1NWEwLiAgSWdu b3JpbmcgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwv ZHJpdmVycy92aWRlby9udmlkaWEubyBlbnRyeQ0KV2FybmluZyAoY29tcGFy ZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIG5sbXN2Y19ncmFjZV9wZXJp b2QgICwgbG9ja2Qgc2F5cyBmOGEwMDhmNCwgL2xpYi9tb2R1bGVzLzIuNC45 LTMxZW50ZXJwcmlzZS9rZXJuZWwvZnMvbG9ja2QvbG9ja2QubyBzYXlzIGY4 OWZmZDY4LiAgSWdub3JpbmcgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJw cmlzZS9rZXJuZWwvZnMvbG9ja2QvbG9ja2QubyBlbnRyeQ0KV2FybmluZyAo Y29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIG5sbXN2Y19vcHMg ICwgbG9ja2Qgc2F5cyBmOGEwMDhmMCwgL2xpYi9tb2R1bGVzLzIuNC45LTMx ZW50ZXJwcmlzZS9rZXJuZWwvZnMvbG9ja2QvbG9ja2QubyBzYXlzIGY4OWZm ZDY0LiAgSWdub3JpbmcgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlz ZS9rZXJuZWwvZnMvbG9ja2QvbG9ja2QubyBlbnRyeQ0KV2FybmluZyAoY29t cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIG5sbXN2Y190aW1lb3V0 ICAsIGxvY2tkIHNheXMgZjhhMDA4ZjgsIC9saWIvbW9kdWxlcy8yLjQuOS0z MWVudGVycHJpc2Uva2VybmVsL2ZzL2xvY2tkL2xvY2tkLm8gc2F5cyBmODlm ZmQ2Yy4gIElnbm9yaW5nIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJp c2Uva2VybmVsL2ZzL2xvY2tkL2xvY2tkLm8gZW50cnkNCldhcm5pbmcgKGNv bXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBuZnNfZGVidWcgICwg c3VucnBjIHNheXMgZjg5ZjBmMDAsIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVu dGVycHJpc2Uva2VybmVsL25ldC9zdW5ycGMvc3VucnBjLm8gc2F5cyBmODlm MGJlMC4gIElnbm9yaW5nIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJp c2Uva2VybmVsL25ldC9zdW5ycGMvc3VucnBjLm8gZW50cnkNCldhcm5pbmcg KGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBuZnNkX2RlYnVn ICAsIHN1bnJwYyBzYXlzIGY4OWYwZjA0LCAvbGliL21vZHVsZXMvMi40Ljkt MzFlbnRlcnByaXNlL2tlcm5lbC9uZXQvc3VucnBjL3N1bnJwYy5vIHNheXMg Zjg5ZjBiZTQuICBJZ25vcmluZyAvbGliL21vZHVsZXMvMi40LjktMzFlbnRl cnByaXNlL2tlcm5lbC9uZXQvc3VucnBjL3N1bnJwYy5vIGVudHJ5DQpXYXJu aW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgbmxtX2Rl YnVnICAsIHN1bnJwYyBzYXlzIGY4OWYwZjA4LCAvbGliL21vZHVsZXMvMi40 LjktMzFlbnRlcnByaXNlL2tlcm5lbC9uZXQvc3VucnBjL3N1bnJwYy5vIHNh eXMgZjg5ZjBiZTguICBJZ25vcmluZyAvbGliL21vZHVsZXMvMi40LjktMzFl bnRlcnByaXNlL2tlcm5lbC9uZXQvc3VucnBjL3N1bnJwYy5vIGVudHJ5DQpX YXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgcnBj X2RlYnVnICAsIHN1bnJwYyBzYXlzIGY4OWYwZWZjLCAvbGliL21vZHVsZXMv Mi40LjktMzFlbnRlcnByaXNlL2tlcm5lbC9uZXQvc3VucnBjL3N1bnJwYy5v IHNheXMgZjg5ZjBiZGMuICBJZ25vcmluZyAvbGliL21vZHVsZXMvMi40Ljkt MzFlbnRlcnByaXNlL2tlcm5lbC9uZXQvc3VucnBjL3N1bnJwYy5vIGVudHJ5 DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wg cnBjX2dhcmJhZ2VfYXJncyAgLCBzdW5ycGMgc2F5cyBmODlmMGVkYywgL2xp Yi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwvbmV0L3N1bnJw Yy9zdW5ycGMubyBzYXlzIGY4OWYwYmJjLiAgSWdub3JpbmcgL2xpYi9tb2R1 bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwvbmV0L3N1bnJwYy9zdW5y cGMubyBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2gg b24gc3ltYm9sIHJwY19zdWNjZXNzICAsIHN1bnJwYyBzYXlzIGY4OWYwZWNj LCAvbGliL21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNlL2tlcm5lbC9uZXQv c3VucnBjL3N1bnJwYy5vIHNheXMgZjg5ZjBiYWMuICBJZ25vcmluZyAvbGli L21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNlL2tlcm5lbC9uZXQvc3VucnBj L3N1bnJwYy5vIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNt YXRjaCBvbiBzeW1ib2wgcnBjX3N5c3RlbV9lcnIgICwgc3VucnBjIHNheXMg Zjg5ZjBlZTAsIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2Vy bmVsL25ldC9zdW5ycGMvc3VucnBjLm8gc2F5cyBmODlmMGJjMC4gIElnbm9y aW5nIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2VybmVsL25l dC9zdW5ycGMvc3VucnBjLm8gZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFw cyk6IG1pc21hdGNoIG9uIHN5bWJvbCB4ZHJfb25lICAsIHN1bnJwYyBzYXlz IGY4OWYwZWM0LCAvbGliL21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNlL2tl cm5lbC9uZXQvc3VucnBjL3N1bnJwYy5vIHNheXMgZjg5ZjBiYTQuICBJZ25v cmluZyAvbGliL21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNlL2tlcm5lbC9u ZXQvc3VucnBjL3N1bnJwYy5vIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21h cHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgeGRyX3R3byAgLCBzdW5ycGMgc2F5 cyBmODlmMGVjOCwgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9r ZXJuZWwvbmV0L3N1bnJwYy9zdW5ycGMubyBzYXlzIGY4OWYwYmE4LiAgSWdu b3JpbmcgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwv bmV0L3N1bnJwYy9zdW5ycGMubyBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9t YXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHhkcl96ZXJvICAsIHN1bnJwYyBz YXlzIGY4OWYwZWMwLCAvbGliL21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNl L2tlcm5lbC9uZXQvc3VucnBjL3N1bnJwYy5vIHNheXMgZjg5ZjBiYTAuICBJ Z25vcmluZyAvbGliL21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNlL2tlcm5l bC9uZXQvc3VucnBjL3N1bnJwYy5vIGVudHJ5DQpXYXJuaW5nIChjb21wYXJl X21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdXNiX2RldmZzX2hhbmRsZSAg LCB1c2Jjb3JlIHNheXMgZjg5NWZhYTAsIC9saWIvbW9kdWxlcy8yLjQuOS0z MWVudGVycHJpc2Uva2VybmVsL2RyaXZlcnMvdXNiL3VzYmNvcmUubyBzYXlz IGY4OTVmNWMwLiAgSWdub3JpbmcgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50 ZXJwcmlzZS9rZXJuZWwvZHJpdmVycy91c2IvdXNiY29yZS5vIGVudHJ5DQpX YXJuaW5nIChtYXBfa3N5bV90b19tb2R1bGUpOiBjYW5ub3QgbWF0Y2ggbG9h ZGVkIG1vZHVsZSBleHQzIHRvIGEgdW5pcXVlIG1vZHVsZSBvYmplY3QuICBU cmFjZSBtYXkgbm90IGJlIHJlbGlhYmxlLg0KV2FybmluZyAoY29tcGFyZV9t YXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIERtcFNlcnZpY2UgICwgbXB0YmFz ZSBzYXlzIGY4ODI2MDg0LCAvbGliL21vZHVsZXMvMi40LjktMzFlbnRlcnBy aXNlL2tlcm5lbC9kcml2ZXJzL21lc3NhZ2UvZnVzaW9uL21wdGJhc2UubyBz YXlzIGY4ODI2MDA0LiAgSWdub3JpbmcgL2xpYi9tb2R1bGVzLzIuNC45LTMx ZW50ZXJwcmlzZS9rZXJuZWwvZHJpdmVycy9tZXNzYWdlL2Z1c2lvbi9tcHRi YXNlLm8gZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNo IG9uIHN5bWJvbCBtcHRfQVNDUV9UYWJsZVN6ICAsIG1wdGJhc2Ugc2F5cyBm ODgyNjA5MCwgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJu ZWwvZHJpdmVycy9tZXNzYWdlL2Z1c2lvbi9tcHRiYXNlLm8gc2F5cyBmODgy NjAxMC4gIElnbm9yaW5nIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJp c2Uva2VybmVsL2RyaXZlcnMvbWVzc2FnZS9mdXNpb24vbXB0YmFzZS5vIGVu dHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1i b2wgbXB0X1Njc2lPcGNvZGVzUHRyICAsIG1wdGJhc2Ugc2F5cyBmODgyNjA4 YywgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwvZHJp dmVycy9tZXNzYWdlL2Z1c2lvbi9tcHRiYXNlLm8gc2F5cyBmODgyNjAwYy4g IElnbm9yaW5nIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2Vy bmVsL2RyaXZlcnMvbWVzc2FnZS9mdXNpb24vbXB0YmFzZS5vIGVudHJ5DQpX YXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgbXB0 X2FkYXB0ZXJzICAsIG1wdGJhc2Ugc2F5cyBmODgyNjA0MCwgL2xpYi9tb2R1 bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwvZHJpdmVycy9tZXNzYWdl L2Z1c2lvbi9tcHRiYXNlLm8gc2F5cyBmODgyNWZjMC4gIElnbm9yaW5nIC9s aWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2VybmVsL2RyaXZlcnMv bWVzc2FnZS9mdXNpb24vbXB0YmFzZS5vIGVudHJ5DQpXYXJuaW5nIChjb21w YXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgbXB0X3Byb2Nfcm9vdF9k aXIgICwgbXB0YmFzZSBzYXlzIGY4ODI2MDgwLCAvbGliL21vZHVsZXMvMi40 LjktMzFlbnRlcnByaXNlL2tlcm5lbC9kcml2ZXJzL21lc3NhZ2UvZnVzaW9u L21wdGJhc2UubyBzYXlzIGY4ODI2MDAwLiAgSWdub3JpbmcgL2xpYi9tb2R1 bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwvZHJpdmVycy9tZXNzYWdl L2Z1c2lvbi9tcHRiYXNlLm8gZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFw cyk6IG1pc21hdGNoIG9uIHN5bWJvbCBtcHRfdl9BU0NRX1RhYmxlUHRyICAs IG1wdGJhc2Ugc2F5cyBmODgyNjA4OCwgL2xpYi9tb2R1bGVzLzIuNC45LTMx ZW50ZXJwcmlzZS9rZXJuZWwvZHJpdmVycy9tZXNzYWdlL2Z1c2lvbi9tcHRi YXNlLm8gc2F5cyBmODgyNjAwOC4gIElnbm9yaW5nIC9saWIvbW9kdWxlcy8y LjQuOS0zMWVudGVycHJpc2Uva2VybmVsL2RyaXZlcnMvbWVzc2FnZS9mdXNp b24vbXB0YmFzZS5vIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBt aXNtYXRjaCBvbiBzeW1ib2wgc2QgICwgc2RfbW9kIHNheXMgZjg4MWNkYTAs IC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2VybmVsL2RyaXZl cnMvc2NzaS9zZF9tb2QubyBzYXlzIGY4ODFjZDAwLiAgSWdub3JpbmcgL2xp Yi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlzZS9rZXJuZWwvZHJpdmVycy9z Y3NpL3NkX21vZC5vIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBt aXNtYXRjaCBvbiBzeW1ib2wgcHJvY19zY3NpICAsIHNjc2lfbW9kIHNheXMg Zjg4MTgxZGMsIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2Vy bmVsL2RyaXZlcnMvc2NzaS9zY3NpX21vZC5vIHNheXMgZjg4MTZhMTQuICBJ Z25vcmluZyAvbGliL21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNlL2tlcm5l bC9kcml2ZXJzL3Njc2kvc2NzaV9tb2QubyBlbnRyeQ0KV2FybmluZyAoY29t cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHNjc2lfZGV2aWNlbGlz dCAgLCBzY3NpX21vZCBzYXlzIGY4ODE4MjA4LCAvbGliL21vZHVsZXMvMi40 LjktMzFlbnRlcnByaXNlL2tlcm5lbC9kcml2ZXJzL3Njc2kvc2NzaV9tb2Qu byBzYXlzIGY4ODE2YTQwLiAgSWdub3JpbmcgL2xpYi9tb2R1bGVzLzIuNC45 LTMxZW50ZXJwcmlzZS9rZXJuZWwvZHJpdmVycy9zY3NpL3Njc2lfbW9kLm8g ZW50cnkNCldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5 bWJvbCBzY3NpX2hvc3RsaXN0ICAsIHNjc2lfbW9kIHNheXMgZjg4MTgyMDQs IC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2VybmVsL2RyaXZl cnMvc2NzaS9zY3NpX21vZC5vIHNheXMgZjg4MTZhM2MuICBJZ25vcmluZyAv bGliL21vZHVsZXMvMi40LjktMzFlbnRlcnByaXNlL2tlcm5lbC9kcml2ZXJz L3Njc2kvc2NzaV9tb2QubyBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBz KTogbWlzbWF0Y2ggb24gc3ltYm9sIHNjc2lfaG9zdHMgICwgc2NzaV9tb2Qg c2F5cyBmODgxODIwYywgL2xpYi9tb2R1bGVzLzIuNC45LTMxZW50ZXJwcmlz ZS9rZXJuZWwvZHJpdmVycy9zY3NpL3Njc2lfbW9kLm8gc2F5cyBmODgxNmE0 NC4gIElnbm9yaW5nIC9saWIvbW9kdWxlcy8yLjQuOS0zMWVudGVycHJpc2Uv a2VybmVsL2RyaXZlcnMvc2NzaS9zY3NpX21vZC5vIGVudHJ5DQpXYXJuaW5n IChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgc2NzaV9sb2dn aW5nX2xldmVsICAsIHNjc2lfbW9kIHNheXMgZjg4MTgxZDgsIC9saWIvbW9k dWxlcy8yLjQuOS0zMWVudGVycHJpc2Uva2VybmVsL2RyaXZlcnMvc2NzaS9z Y3NpX21vZC5vIHNheXMgZjg4MTZhMTAuICBJZ25vcmluZyAvbGliL21vZHVs ZXMvMi40LjktMzFlbnRlcnByaXNlL2tlcm5lbC9kcml2ZXJzL3Njc2kvc2Nz aV9tb2QubyBlbnRyeQ0KVW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgTlVMTCBw b2ludGVyIGRlcmVmZXJlbmNlIGF0IHZpcnR1YWwgYWRkcmVzcyAwMDAwMDAw MA0KZjg5YjY2OWYNCipwZGUgPSAzNWRiODAwMQ0KT29wczogMDAwMg0KQ1BV OiAgICAwDQpFSVA6ICAgIDAwMTA6WzxmODliNjY5Zj5dICAgIFRhaW50ZWQ6 IFAgDQpVc2luZyBkZWZhdWx0cyBmcm9tIGtzeW1vb3BzIC10IGVsZjMyLWkz ODYgLWEgaTM4Ng0KRUZMQUdTOiAwMDAxMDI0Ng0KZWF4OiAwMDAwMDExYyAg IGVieDogMDAwMDAwMDAgICBlY3g6IDAwMDAwMDcxICAgZWR4OiAwMDAwMDEx Yw0KZXNpOiAwMDAwMDFmYiAgIGVkaTogZjc3YjAxNDAgICBlYnA6IGMwMmY1 ZjE4ICAgZXNwOiBjMDJmNWVmMA0KZHM6IDAwMTggICBlczogMDAxOCAgIHNz OiAwMDE4DQpQcm9jZXNzIHN3YXBwZXIgKHBpZDogMCwgc3RhY2twYWdlPWMw MmY1MDAwKQ0KU3RhY2s6IGY3N2IyMjMwIGY1ZTc0OWQ4IGMwMmY1ZjE4IDAw MDAwMjQ2IGY3N2IxYTFjIGY3N2IyMjMwIDAwMDAwMDAxIGY3N2IwMTQwIA0K ICAgICAgIDAwMDAwMDAwIDAwMDAwMGMzIGMwMmY1ZjQ4IGY4OWEzZTFmIGY3 N2IwMTQwIDAwMDA1ODA0IDAwMDAwMDAxIGMwMzdkZWEwIA0KICAgICAgIGMw MTIzYmMxIDAwMDAwMDQ2IDAwMDAwMDAxIGY3Y2Q3NjIwIDAwMDAwMDAwIDA0 MDAwMDAxIDAwMDAwMDMwIGMwMTA4YTZlIA0KQ2FsbCBUcmFjZTogWzxmODlh M2UxZj5dIGJjbTU3MDBfaW50ZXJydXB0IFtiY201NzAwXSAweDEyZiANCls8 YzAxMjNiYzE+XSBfX3J1bl90aW1lcnMgW2tlcm5lbF0gMHhkMSANCls8YzAx MDhhNmU+XSBoYW5kbGVfSVJRX2V2ZW50IFtrZXJuZWxdIDB4NWUgDQpbPGMw MTA4Yzc0Pl0gZG9fSVJRIFtrZXJuZWxdIDB4YTQgDQpbPGMwMTA1NDEwPl0g ZGVmYXVsdF9pZGxlIFtrZXJuZWxdIDB4MCANCls8YzAxMDU0MTA+XSBkZWZh dWx0X2lkbGUgW2tlcm5lbF0gMHgwIA0KWzxjMDIyZmFiMD5dIGNhbGxfZG9f SVJRIFtrZXJuZWxdIDB4NSANCls8YzAxMDU0MTA+XSBkZWZhdWx0X2lkbGUg W2tlcm5lbF0gMHgwIA0KWzxjMDEwNTQxMD5dIGRlZmF1bHRfaWRsZSBba2Vy bmVsXSAweDAgDQpbPGMwMTA1NDNkPl0gZGVmYXVsdF9pZGxlIFtrZXJuZWxd IDB4MmQgDQpbPGMwMTA1NGMyPl0gY3B1X2lkbGUgW2tlcm5lbF0gMHg1MiAN Cls8YzAxMDUwMDA+XSBzdGV4dCBba2VybmVsXSAweDAgDQpbPGMwMjJlN2Mw Pl0gLnJvZGF0YS5zdHIxLjMyIFtrZXJuZWxdIDB4NWMwIA0KQ29kZTogYzcg MDMgMDAgMDAgMDAgMDAgOGIgNGQgZWMgODkgNWMgMjQgMDQgODkgMGMgMjQg ZTggN2MgNjkgMDAgDQoNCj4+RUlQOyBmODliNjY5ZiA8W2JjbTU3MDBdTE1f U2VydmljZUludGVycnVwdHMrY2YvMjMwPiAgIDw9PT09PQ0KVHJhY2U7IGY4 OWEzZTFmIDxbYmNtNTcwMF1iY201NzAwX2ludGVycnVwdCsxMmYvNDEwPg0K VHJhY2U7IGMwMTIzYmMxIDxfX3J1bl90aW1lcnMrZDEvMTEwPg0KVHJhY2U7 IGMwMTA4YTZlIDxoYW5kbGVfSVJRX2V2ZW50KzVlLzkwPg0KVHJhY2U7IGMw MTA4Yzc0IDxkb19JUlErYTQvZjA+DQpUcmFjZTsgYzAxMDU0MTAgPGRlZmF1 bHRfaWRsZSswLzQwPg0KVHJhY2U7IGMwMTA1NDEwIDxkZWZhdWx0X2lkbGUr MC80MD4NClRyYWNlOyBjMDIyZmFiMCA8SVJRMHg2Zl9pbnRlcnJ1cHQrOC9j Pg0KVHJhY2U7IGMwMTA1NDEwIDxkZWZhdWx0X2lkbGUrMC80MD4NClRyYWNl OyBjMDEwNTQxMCA8ZGVmYXVsdF9pZGxlKzAvNDA+DQpUcmFjZTsgYzAxMDU0 M2QgPGRlZmF1bHRfaWRsZSsyZC80MD4NClRyYWNlOyBjMDEwNTRjMiA8Y3B1 X2lkbGUrNTIvNzA+DQpUcmFjZTsgYzAxMDUwMDAgPF9zdGV4dCswLzA+DQpU cmFjZTsgYzAyMmU3YzAgPGxsY19vdWkrOTkwLzE3NDA+DQpDb2RlOyAgZjg5 YjY2OWYgPFtiY201NzAwXUxNX1NlcnZpY2VJbnRlcnJ1cHRzK2NmLzIzMD4N CjAwMDAwMDAwIDxfRUlQPjoNCkNvZGU7ICBmODliNjY5ZiA8W2JjbTU3MDBd TE1fU2VydmljZUludGVycnVwdHMrY2YvMjMwPiAgIDw9PT09PQ0KICAgMDog ICBjNyAwMyAwMCAwMCAwMCAwMCAgICAgICAgIG1vdmwgICAkMHgwLCglZWJ4 KSAgIDw9PT09PQ0KQ29kZTsgIGY4OWI2NmE1IDxbYmNtNTcwMF1MTV9TZXJ2 aWNlSW50ZXJydXB0cytkNS8yMzA+DQogICA2OiAgIDhiIDRkIGVjICAgICAg ICAgICAgICAgICAgbW92ICAgIDB4ZmZmZmZmZWMoJWVicCksJWVjeA0KQ29k ZTsgIGY4OWI2NmE4IDxbYmNtNTcwMF1MTV9TZXJ2aWNlSW50ZXJydXB0cytk OC8yMzA+DQogICA5OiAgIDg5IDVjIDI0IDA0ICAgICAgICAgICAgICAgbW92 ICAgICVlYngsMHg0KCVlc3AsMSkNCkNvZGU7ICBmODliNjZhYyA8W2JjbTU3 MDBdTE1fU2VydmljZUludGVycnVwdHMrZGMvMjMwPg0KICAgZDogICA4OSAw YyAyNCAgICAgICAgICAgICAgICAgIG1vdiAgICAlZWN4LCglZXNwLDEpDQpD b2RlOyAgZjg5YjY2YWYgPFtiY201NzAwXUxNX1NlcnZpY2VJbnRlcnJ1cHRz K2RmLzIzMD4NCiAgMTA6ICAgZTggN2MgNjkgMDAgMDAgICAgICAgICAgICBj YWxsICAgNjk5MSA8X0VJUCsweDY5OTE+IGY4OWJkMDMwIDxbYmNtNTcwMF1R UV9QdXNoVGFpbCswLzQwPg0KDQogPDA+S2VybmVsIHBhbmljOiBBaWVlLCBr aWxsaW5nIGludGVycnVwdCBoYW5kbGVyIQ0KDQoxMzMgd2FybmluZ3MgYW5k IDcgZXJyb3JzIGlzc3VlZC4gIFJlc3VsdHMgbWF5IG5vdCBiZSByZWxpYWJs ZS4NCg== --1519150939-2025421746-1089990099=:20914-- From jmorris@redhat.com Fri Jul 16 08:28:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 08:28:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GFSQbK014109 for ; Fri, 16 Jul 2004 08:28:27 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6GFSHe1021731; Fri, 16 Jul 2004 11:28:17 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6GFSFa23496; Fri, 16 Jul 2004 11:28:15 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6GFSB4G004900; Fri, 16 Jul 2004 11:28:12 -0400 Date: Fri, 16 Jul 2004 11:27:36 -0400 (EDT) From: James Morris X-X-Sender: jmorris@devserv.devel.redhat.com To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [CRYPTO] Fix stack overrun in crypt() In-Reply-To: <20040715114840.GA1325@gondor.apana.org.au> Message-ID: References: <20040715114840.GA1325@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7009 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Thu, 15 Jul 2004, Herbert Xu wrote: > Hi: > > The stack allocation in crypt() is bogus as whether tmp_src/tmp_dst > is used is determined by factors unrelated to nbytes and > src->length/dst->length. > > Since the condition for whether tmp_src/tmp_dst are used is very > complex, let's allocate them always instead of guessing. > > This fixes a number of weird crashes including those AES crashes > that people have been seeing with the 2.4 backport + ipt_conntrack. Ok, thanks, looks good. > PS I think someone should double-check the logic in the scatterwalk > stuff, especially the whichbuf bits. Adam Richter rewrote that code, and I have walked through it before (I guess Dave did too). Any more code reviewers welcome. - James -- James Morris From dsaxena@plexity.net Fri Jul 16 10:29:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 10:29:49 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GHTfaS017210 for ; Fri, 16 Jul 2004 10:29:44 -0700 Received: from plexity.net (c-24-20-152-76.client.comcast.net[24.20.152.76]) by comcast.net (sccrmhc11) with ESMTP id <2004071617024101100sv9h8e>; Fri, 16 Jul 2004 17:02:41 +0000 Received: by plexity.net (Postfix, from userid 1025) id A34B32182C2; Fri, 16 Jul 2004 10:02:40 -0700 (PDT) Date: Fri, 16 Jul 2004 10:02:40 -0700 From: Deepak Saxena To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Add IXDP2x01 board support to CS89x0 driver Message-ID: <20040716170240.GA4880@plexity.net> Reply-To: dsaxena@plexity.net References: <20040716092859.GA16849@plexity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040716092859.GA16849@plexity.net> Organization: Plexity Networks User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 7010 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dsaxena@plexity.net Precedence: bulk X-list: netdev [resend b/c I typo'd Jeff's email address the first time...] Jeff, The following patch modifies the CS89x0 driver to work on Intel's IXDP2401 and IXDP2801 (Intel ARm/XScale based) platforms: - The main change requried is that the IXDP2x01 boards have the chip connected through a CPLD so all registers appear at dword-aligned addresses. A macro in the header adjusts the register offsets appropriately. - The boards do not have ISA, so we need to explicitly check for IXDP2X01 in Kconfig. - There is what I believe is a bug in the driver as it currently only asks for the signature if ioaddr & 1 is set but then reads and checks against the expected signature even when !(ioaddr & 1). This causes the driver to not load on the IXDP2x01 since our ioaddr does not have bit 1 set. - #ifdef out some bits of code that assume the chip is really sitting on an ISA bus. The main IXDP2x01 support will be coming in through rmk's tree at a later date when all the drivers are merged upstream. Tnx, ~Deepak ===== drivers/net/Kconfig 1.79 vs edited ===== --- 1.79/drivers/net/Kconfig Fri Jun 18 09:43:06 2004 +++ edited/drivers/net/Kconfig Mon Jul 12 12:14:59 2004 @@ -1335,7 +1335,7 @@ config CS89x0 tristate "CS89x0 support" - depends on NET_PCI && ISA + depends on NET_PCI && (ISA || ARCH_IXDP2X01) ---help--- Support for CS89x0 chipset based Ethernet cards. If you have a network (Ethernet) card of this type, say Y and read the ===== drivers/net/cs89x0.c 1.24 vs edited ===== --- 1.24/drivers/net/cs89x0.c Sat May 22 10:40:55 2004 +++ edited/drivers/net/cs89x0.c Fri Jul 16 02:02:25 2004 @@ -84,6 +84,9 @@ Oskar Schirmer : oskar@scara.com : HiCO.SH4 (superh) support added (irq#1, cs89x0_media=) + Deepak Saxena : dsaxena@plexity.net + : Intel IXDP2x01 (XScale ixp2x00 NPU) platform support + */ /* Always include 'config.h' first in case the user wants to turn on @@ -97,7 +100,11 @@ * Note that even if DMA is turned off we still support the 'dma' and 'use_dma' * module options so we don't break any startup scripts. */ +#ifndef CONFIG_ARCH_IXDP2X01 +#define ALLOW_DMA 0 +#else #define ALLOW_DMA 1 +#endif /* * Set this to zero to remove all the debug statements via @@ -162,6 +169,10 @@ static unsigned int netcard_portlist[] __initdata = { 0x0300, 0}; static unsigned int cs8900_irq_map[] = {1,0,0,0}; +#elif defined(CONFIG_ARCH_IXDP2X01) +#include +static unsigned int netcard_portlist[] __initdata = {IXDP2X01_CS8900_VIRT_BASE, 0}; +static unsigned int cs8900_irq_map[] = {IRQ_IXDP2X01_CS8900, 0, 0, 0}; #else static unsigned int netcard_portlist[] __initdata = { 0x300, 0x320, 0x340, 0x360, 0x200, 0x220, 0x240, 0x260, 0x280, 0x2a0, 0x2c0, 0x2e0, 0}; @@ -454,11 +465,12 @@ retval = -ENODEV; goto out2; } - ioaddr &= ~3; - outw(PP_ChipID, ioaddr + ADD_PORT); } printk("PP_addr=0x%x\n", inw(ioaddr + ADD_PORT)); + ioaddr &= ~3; + outw(PP_ChipID, ioaddr + ADD_PORT); + if (inw(ioaddr + DATA_PORT) != CHIP_EISA_ID_SIG) { printk(KERN_ERR "%s: incorrect signature 0x%x\n", dev->name, inw(ioaddr + DATA_PORT)); @@ -665,6 +677,9 @@ } else { i = lp->isa_config & INT_NO_MASK; if (lp->chip_type == CS8900) { +#ifdef CONFIG_ARCH_IXDP2X01 + i = cs8900_irq_map[0]; +#else /* Translate the IRQ using the IRQ mapping table. */ if (i >= sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0])) printk("\ncs89x0: invalid ISA interrupt number %d\n", i); @@ -681,6 +696,7 @@ if ((irq_map_buff[0] & 0xff) == PNP_IRQ_FRMT) lp->irq_map = (irq_map_buff[0]>>8) | (irq_map_buff[1] << 8); } +#endif } if (!dev->irq) dev->irq = i; @@ -884,8 +900,10 @@ void __init reset_chip(struct net_device *dev) { +#ifndef CONFIG_ARCH_IXDP2X01 struct net_local *lp = netdev_priv(dev); int ioaddr = dev->base_addr; +#endif int reset_start_time; writereg(dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) | POWER_ON_RESET); @@ -894,6 +912,7 @@ current->state = TASK_INTERRUPTIBLE; schedule_timeout(30*HZ/1000); +#ifndef CONFIG_ARCH_IXDP2X01 if (lp->chip_type != CS8900) { /* Hardware problem requires PNP registers to be reconfigured after a reset */ outw(PP_CS8920_ISAINT, ioaddr + ADD_PORT); @@ -904,6 +923,8 @@ outb((dev->mem_start >16) & 0xff, ioaddr + DATA_PORT); outb((dev->mem_start >8) & 0xff, ioaddr + DATA_PORT + 1); } +#endif /* IXDP2x01 */ + /* Wait until the chip is reset */ reset_start_time = jiffies; while( (readreg(dev, PP_SelfST) & INIT_DONE) == 0 && jiffies - reset_start_time < 2) @@ -1155,12 +1176,14 @@ else #endif { +#ifndef CONFIG_ARCH_IXDP2X01 if (((1 << dev->irq) & lp->irq_map) == 0) { printk(KERN_ERR "%s: IRQ %d is not in our map of allowable IRQs, which is %x\n", dev->name, dev->irq, lp->irq_map); ret = -EAGAIN; goto bad_out; } +#endif /* FIXME: Cirrus' release had this: */ writereg(dev, PP_BusCTL, readreg(dev, PP_BusCTL)|ENABLE_IRQ ); /* And 2.3.47 had this: */ ===== drivers/net/cs89x0.h 1.3 vs edited ===== --- 1.3/drivers/net/cs89x0.h Mon Mar 17 15:42:26 2003 +++ edited/drivers/net/cs89x0.h Fri Jul 16 02:02:48 2004 @@ -16,6 +16,13 @@ #include +#ifdef CONFIG_ARCH_IXDP2X01 +/* IXDP2401/IXDP2801 uses dword-aligned register addressing */ +#define CS89x0_PORT(reg) ((reg) * 2) +#else +#define CS89x0_PORT(reg) (reg) +#endif + #define PP_ChipID 0x0000 /* offset 0h -Corp -ID */ /* offset 2h -Model/Product Number */ /* offset 3h -Chip Revision Number */ @@ -324,16 +331,16 @@ #define RAM_SIZE 0x1000 /* The card has 4k bytes or RAM */ #define PKT_START PP_TxFrame /* Start of packet RAM */ -#define RX_FRAME_PORT 0x0000 +#define RX_FRAME_PORT CS89x0_PORT(0x0000) #define TX_FRAME_PORT RX_FRAME_PORT -#define TX_CMD_PORT 0x0004 +#define TX_CMD_PORT CS89x0_PORT(0x0004) #define TX_NOW 0x0000 /* Tx packet after 5 bytes copied */ #define TX_AFTER_381 0x0040 /* Tx packet after 381 bytes copied */ #define TX_AFTER_ALL 0x00c0 /* Tx packet after all bytes copied */ -#define TX_LEN_PORT 0x0006 -#define ISQ_PORT 0x0008 -#define ADD_PORT 0x000A -#define DATA_PORT 0x000C +#define TX_LEN_PORT CS89x0_PORT(0x0006) +#define ISQ_PORT CS89x0_PORT(0x0008) +#define ADD_PORT CS89x0_PORT(0x000A) +#define DATA_PORT CS89x0_PORT(0x000C) #define EEPROM_WRITE_EN 0x00F0 #define EEPROM_WRITE_DIS 0x0000 Signed-off-by: Deepak Saxena -- Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/ "Unlike me, many of you have accepted the situation of your imprisonment and will die here like rotten cabbages." - Number 6 From adk0212@mail.kroptech.com Fri Jul 16 10:33:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 10:33:52 -0700 (PDT) Received: from ms-smtp-03.nyroc.rr.com (ms-smtp-03.nyroc.rr.com [24.24.2.57]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GHXiCV017608 for ; Fri, 16 Jul 2004 10:33:45 -0700 Received: from mail.kroptech.com (roc-24-93-20-125.rochester.rr.com [24.93.20.125]) by ms-smtp-03.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id i6GHXNv2009103; Fri, 16 Jul 2004 13:33:24 -0400 (EDT) Received: by mail.kroptech.com (Postfix, from userid 500) id D0DA711376E; Fri, 16 Jul 2004 14:08:12 -0400 (EDT) Date: Fri, 16 Jul 2004 14:08:12 -0400 From: Adam Kropelin To: Brian McEntire Cc: kaos@ocs.com.au, linux-kernel@vger.kernel.org, akpm@zip.com.au, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Suggestions with hard lockup on 4 systems, have oops report Message-ID: <20040716140812.A8270@mail.kroptech.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from brianm@fsg1.nws.noaa.gov on Fri, Jul 16, 2004 at 11:01:39AM -0400 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 7011 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akropel1@rochester.rr.com Precedence: bulk X-list: netdev On Fri, Jul 16, 2004 at 11:01:39AM -0400, Brian McEntire wrote: > Thank you for taking time from your busy days to read this. You all > (kernel maintainers) rock! :) > > I have four Linux hosts, with identical hardware and OSs, that exhibit a > very tough to troubleshoot hang/freeze. About once every two weeks (and > The OS specifics: > RH 7.2 with latest patches except running kernel 2.4.9-31enterprise for > CM reasons (at one point, I tried the latest available RH 7.2 kernel but > it did not improve stability so I went back.) > bcm5700-7.1.22-1 > nvidia ?? (no RPM listed, didn't know where to find the version.) You've really got to eliminate the binary bcm5700 and nvidia modules in order to diagnose this. Based on the oops, bcm5700 looks suspect, but it could just be the unlucky guy whose memory was stepped on by nvidia or some other part of the kernel. Switch to an open NIC like e1000 temporarily (or better yet, permanently) and see if the lockup persists. Do the same with nvidia. If you can reproduce the problem without ever having loaded either module (unloading the module once it's loaded is not sufficient), post the new oops and you'll have a solid foundation for debugging. --Adam From jkenisto@us.ibm.com Fri Jul 16 11:26:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 11:27:01 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GIQggS018943 for ; Fri, 16 Jul 2004 11:26:49 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6GIQXZW567662; Fri, 16 Jul 2004 14:26:33 -0400 Received: from DYN318397BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6GIQVon389096; Fri, 16 Jul 2004 12:26:31 -0600 Subject: Re: Network device driver probe issues From: Jim Keniston To: David Dillow Cc: Jeff Garzik , Anton Blanchard , Netdev , cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jonmason@us.ibm.com, Jim Keniston In-Reply-To: <1089953344.23577.15.camel@ori.thedillows.org> References: <20040715135244.GD27715@krispykreme> <40F71477.2020408@pobox.com> <1089939860.1709.70.camel@ibm-ni9dztukfq8.beaverton.ibm.com> <1089953344.23577.15.camel@ori.thedillows.org> Content-Type: text/plain Organization: Message-Id: <1090002390.1690.113.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 16 Jul 2004 11:26:30 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 7012 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev On Thu, 2004-07-15 at 21:49, David Dillow wrote: > On Thu, 2004-07-15 at 21:04, Jim Keniston wrote: > > On Thu, 2004-07-15 at 16:34, Jeff Garzik wrote: > [snip] > > > > We should instead use something stable to attach to printks during > > > > probe. pci_name() is the obvious choice, perhaps using dev_printk(). > > > > The failure then becomes: > > > > > > > > 0000:01:01.0 Intel(R) PRO/1000 Network Connection > > > > 0000:01:01.0 The EEPROM Checksum Is Not Valid > > > > 0000:02:01.0 Intel(R) PRO/1000 Network Connection > > > > > > pci_name() or a simple counter of devices found. I prefer pci_name() > > > > > > Jeff > > > > Delay registration until the end of the probe, and make DPRINTK smarter. > > DPRINTK should check > > adapter->netdev->reg_state == NETREG_REGISTERED > > and use the interface name (eth0) if the device is registered, or > > pci_name() if it's not. > > > > Jim > > In the typhoon driver, I have tp->name, and most everything that prints > info/errors about the card use it. During probing, it is initially set > to point to pci_name(), and once registered, it gets pointed to > netdev->name. > > This seems fairly clean, though maybe a bit redundant. > > Dave > Works for me. While we're talking about DPRINTK, e100.c could use a similar adjustment. e100_probe() correctly defers registration until the probe has succeeded, but as a result, probe-time failure messages refer to "eth%d", right? Jim From ganesh.venkatesan@intel.com Fri Jul 16 12:16:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 12:16:45 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GJGWGn020150 for ; Fri, 16 Jul 2004 12:16:32 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6GCGblP006268; Fri, 16 Jul 2004 12:16:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6GJCJpQ013648; Fri, 16 Jul 2004 19:12:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004071612155802210 ; Fri, 16 Jul 2004 12:15:58 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 12:15:58 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Network device driver probe issues Date: Fri, 16 Jul 2004 12:15:57 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E01CEF1BF@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network device driver probe issues Thread-Index: AcRrYm5t41+wWWjRR/61649HuMZT3wABrn8A From: "Venkatesan, Ganesh" To: "Jim Keniston" , "David Dillow" Cc: "Jeff Garzik" , "Anton Blanchard" , "Netdev" , "cramerj" , "Ronciak, John" , X-OriginalArrivalTime: 16 Jul 2004 19:15:58.0269 (UTC) FILETIME=[5312B6D0:01C46B69] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6GJGWGn020150 X-archive-position: 7013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev We've fixed the e100 to have the same logic as e1000. I like the typhoon driver idea. Thanks, ganesh ------------------------------------------------- Ganesh Venkatesan Network/Storage Division, Hillsboro, OR -----Original Message----- From: Jim Keniston [mailto:jkenisto@us.ibm.com] Sent: Friday, July 16, 2004 11:27 AM To: David Dillow Cc: Jeff Garzik; Anton Blanchard; Netdev; cramerj; Ronciak, John; Venkatesan, Ganesh; jonmason@us.ibm.com; Jim Keniston Subject: Re: Network device driver probe issues On Thu, 2004-07-15 at 21:49, David Dillow wrote: > On Thu, 2004-07-15 at 21:04, Jim Keniston wrote: > > On Thu, 2004-07-15 at 16:34, Jeff Garzik wrote: > [snip] > > > > We should instead use something stable to attach to printks during > > > > probe. pci_name() is the obvious choice, perhaps using dev_printk(). > > > > The failure then becomes: > > > > > > > > 0000:01:01.0 Intel(R) PRO/1000 Network Connection > > > > 0000:01:01.0 The EEPROM Checksum Is Not Valid > > > > 0000:02:01.0 Intel(R) PRO/1000 Network Connection > > > > > > pci_name() or a simple counter of devices found. I prefer pci_name() > > > > > > Jeff > > > > Delay registration until the end of the probe, and make DPRINTK smarter. > > DPRINTK should check > > adapter->netdev->reg_state == NETREG_REGISTERED > > and use the interface name (eth0) if the device is registered, or > > pci_name() if it's not. > > > > Jim > > In the typhoon driver, I have tp->name, and most everything that prints > info/errors about the card use it. During probing, it is initially set > to point to pci_name(), and once registered, it gets pointed to > netdev->name. > > This seems fairly clean, though maybe a bit redundant. > > Dave > Works for me. While we're talking about DPRINTK, e100.c could use a similar adjustment. e100_probe() correctly defers registration until the probe has succeeded, but as a result, probe-time failure messages refer to "eth%d", right? Jim From ahu@outpost.ds9a.nl Fri Jul 16 12:18:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 12:19:00 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GJIqFs020478 for ; Fri, 16 Jul 2004 12:18:53 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 30B844434; Fri, 16 Jul 2004 21:18:50 +0200 (CEST) Date: Fri, 16 Jul 2004 21:18:50 +0200 From: bert hubert To: Brian McEntire Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Suggestions with hard lockup on 4 systems, have oops report Message-ID: <20040716191850.GA5997@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Brian McEntire , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.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-archive-position: 7014 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 On Fri, Jul 16, 2004 at 11:01:39AM -0400, Brian McEntire wrote: > Thank you for taking time from your busy days to read this. You all > (kernel maintainers) rock! :) You are running one of the kernels not a lot of people outside of red hat know the details about. > The systems are: > Dual Xeon 2.4GHz processors > 2 GB RAM > 2 GB swap > Ethernet controller: PCI device 14e4:16a7 (BROADCOM Corporation) (rev 2) > Dual channel SCSI storage controller: PCI device 1000:0030 (Symbios > Logic Inc. (formerly NCR)) (rev 7) This kind of hardware just asks for 2.6. Furthermore, you'll find that current kernel hackers will be in a far better position to help you. > bcm5700-7.1.22-1 In a recent kernel, you will probably be able to use the tg3 driver instead of this vendor supplied one, which is generally considered to be inferior or at least uglier than the in kernel one. > Code; f89b669f <[bcm5700]LM_ServiceInterrupts+cf/230> > 00000000 <_EIP>: > Code; f89b669f <[bcm5700]LM_ServiceInterrupts+cf/230> <===== > 0: c7 03 00 00 00 00 movl $0x0,(%ebx) <===== I'm no expert, but this strongly looks like problems in the broadcom driver. > 133 warnings and 7 errors issued. Results may not be reliable. 2.6 also has a built-in ksymoops, which gives far more reliable results. Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From jgarzik@pobox.com Fri Jul 16 12:53:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 12:53:29 -0700 (PDT) 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 SMTP id i6GJrIlv024523 for ; Fri, 16 Jul 2004 12:53:19 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BlYlb-00033X-Mb; Fri, 16 Jul 2004 20:53:11 +0100 Message-ID: <40F8321A.7000404@pobox.com> Date: Fri, 16 Jul 2004 15:52:58 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Venkatesan, Ganesh" CC: Jim Keniston , David Dillow , Anton Blanchard , Netdev , cramerj , "Ronciak, John" , jonmason@us.ibm.com Subject: Re: Network device driver probe issues References: <468F3FDA28AA87429AD807992E22D07E01CEF1BF@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01CEF1BF@orsmsx408> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7015 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Venkatesan, Ganesh wrote: > We've fixed the e100 to have the same logic as e1000. I like the typhoon > driver idea. Unfortunately both are wrong. e1000 should not be using dev_alloc_name(), and patches to add that to e100 will not be accepted. e100 should not be referencing netdev->name until after register_netdev() completes. The typhoon solution is fine with me. Other drivers don't bother and simply use pci_name() during probe. It's up to you as maintainer. Jeff From vkondra@mail.ru Fri Jul 16 14:17:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 14:17:16 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GLH7MC026355 for ; Fri, 16 Jul 2004 14:17:10 -0700 Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 670991A3B42 for ; Sat, 17 Jul 2004 01:17:04 +0400 (MSD) Received: from [212.179.226.190] (port=35968 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1Bla3k-000KA6-00 for netdev@oss.sgi.com; Sat, 17 Jul 2004 01:16:01 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: TGe overview #1 Date: Sat, 17 Jul 2004 00:15:53 +0300 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Message-Id: <200407170015.59373.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6GLH7MC026355 X-archive-position: 7016 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I promised to do overview for TGe. Now I am starting to deliver on promise. I did it once already, but now I will try to be more specific and cover almost all MAC aspects. I will only briefly mention PHY details. TGe is working group in IEEE, who is working on QoS for 802.11 wireless network. This work is close to completion, final draft will be voted and become standard shortly. To explain how QoS implemented for 802.11, some basics need to be understood. Sorry for long introduction. Briefly about classic 802.11. There are 2 modes of operation: IBSS, where there is no special station; and BSS, where there is one access point (AP), which coordinates activity for all stations in the BSS. Usually, AP is also bridge to the wired network. We will focus on BSS, where AP coordinates everyone's activity, as this is main mode of operation. In BSS, each STA send frames only to AP, which re-route it to proper destination. 802.11 is carrier sense collision avoidance system. For collision avoidance, all stations use carrier sense mechanism. To be able to transmit, STA should sense clear channel for some time. This time composed of some fixed interval and random backoff. There are 3 important time intervals - - - SIFS (short inter-frame space); - - PIFS (point coordinator function inter-frame space), which is 2 SIFS; - - DIFS (distributed coordinator function inter-frame space), which is 3 SIFS Typical value for SIFS is 16us for .11a These intervals are used in: SIFS is interval between frames in control frame exchange (later about frame types). PIFS is interval used by PCF (point coordinator function) to access media. AP uses it to gain access to the media when it acts as point coordinator (almost unused, will not talk about it) and in some other cases, will describe it later. DIFS used for all stations to gain access to the medium, after DIFS, they start to count down random backoff counter. Backoff is number of SIFS. PCF (point coordinator function) is dictate of AP. It decides who will speak next and polls next STA giving it right to transmit. DCF is equal competition for the channel. There is parameters: - - CWmin, CWmax (contention window min and max). Each STA, when it decides it want to Tx, generates random number up to CW. After DIFS, it start counting down from this number each SIFS. If it goes to 0, STA starts Tx. If it senses energy in the channel, it stops counting, and continue next time when channel is clear for DIFS. First, CW=CWmin. If collision occurs, STA doubles its CW, and do so up to CWmax. Collision detected by not having ACK(see below). Frame types: - - data frames, to carry data. - - management frames, to maintain MAC state. - - control frames, to do low level sequences. Control frames used to acknowledge data/management frame (ACK); to implement RTS/CTS protection and for some other jobs. Frame exchange consist of frame+ACK, or RTS+CTS+frame+ACK. Now, TGE. It introduces TXOP, transmit opportunity. Idea is to lower overhead of backoff window. Implementation: when STA wins channel access, it may use it for some time called TXOP. During this period, STA can start next frame exchange SIFS after previous one. TXOP=0 means one frame may be transmitted. To obtain TXOP, different interval, AIFS, introduced instead of DIFS, AIFS=DIFS+SIFS*AIFSN, where AIFSN is parameter. In EDCA (enhanced distributed channel access) mode, 4 access categories used, which differs by channel access parameters: CWmin, CWmax, AIFSN, TXOP. These 4 categories acts as independent channel access functions, independently competing for the channel. All parameters dictated by AP. This mechanism used to implement diffserv style QoS. To be continued... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA+EWOqxdj7mhC6o0RApUVAKCX8KSBvk7QeQZffS9E0xFLiaf/TwCgga06 7aclJYLLY1YnX7k2MIgdA7Y= =ruw3 -----END PGP SIGNATURE----- From lists@mdiehl.de Fri Jul 16 14:44:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 14:44:39 -0700 (PDT) Received: from bart.webpack.hosteurope.de (bart.webpack.hosteurope.de [217.115.142.76]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GLiVVi027213 for ; Fri, 16 Jul 2004 14:44:32 -0700 Received: from pd9e95406.dip0.t-ipconnect.de ([217.233.84.6] helo=notebook.home.mdiehl.de) by bart.webpack.hosteurope.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BlF53-0005z4-2C; Fri, 16 Jul 2004 00:51:57 +0200 Received: from notebook.home.mdiehl.de (localhost.localdomain [127.0.0.1]) by notebook.home.mdiehl.de (8.12.1/8.12.1) with ESMTP id i6FMw1ji017399; Fri, 16 Jul 2004 00:58:01 +0200 Received: from localhost (martin@localhost) by notebook.home.mdiehl.de (8.12.1/8.12.1/Submit) with ESMTP id i6FMvxCR017396; Fri, 16 Jul 2004 00:58:00 +0200 X-Authentication-Warning: notebook.home.mdiehl.de: martin owned process doing -bs Date: Fri, 16 Jul 2004 00:57:59 +0200 (CEST) From: Martin Diehl X-X-Sender: martin@notebook.home.mdiehl.de To: Jean Tourrilhes cc: Andi Kleen , Jeff Garzik , , , Jean Tourrilhes , , Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers In-Reply-To: <20040715224235.GA5164@bougret.hpl.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HE-MXrcvd: no X-archive-position: 7017 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lists@mdiehl.de Precedence: bulk X-list: netdev On Thu, 15 Jul 2004, Jean Tourrilhes wrote: > irda_setup_dma was (supposedly) fixed in 2.6.8-rc1, and no > longer depend on CONFIG_ISA. Those driver are supposed to work on 64 > bits. Ok, so maybe the following is missing in addition to Andi's patch? Martin ----------- --- linux-2.6.8-rc1/net/irda/irda_device.c Tue Jul 13 00:31:34 2004 +++ v2.6.8-rc1-md/net/irda/irda_device.c Fri Jul 16 00:45:08 2004 @@ -529,7 +529,6 @@ int irda_device_set_mode(struct net_devi return ret; } -#ifdef CONFIG_ISA /* * Function setup_dma (idev, buffer, count, mode) * @@ -552,4 +551,3 @@ void irda_setup_dma(int channel, dma_add release_dma_lock(flags); } EXPORT_SYMBOL(irda_setup_dma); -#endif From shemminger@osdl.org Fri Jul 16 15:22:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 15:22:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GMMaqw028358 for ; Fri, 16 Jul 2004 15:22:36 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6GMM1k15121; Fri, 16 Jul 2004 15:22:01 -0700 Date: Fri, 16 Jul 2004 15:22:01 -0700 From: Stephen Hemminger To: Masahide NAKAMURA Cc: Herbert Xu , netdev@oss.sgi.com, nakam@linux-ipv6.org Subject: Re: [PATCH 1/3] iproute2 and xfrm Message-Id: <20040716152201.6cb6bd60@dell_ss3.pdx.osdl.net> In-Reply-To: <20040715150214.6067a457@localhost> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> <20040707110315.GA26100@gondor.apana.org.au> <20040709125100.3edce4e9@localhost> <20040715150214.6067a457@localhost> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7018 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 15 Jul 2004 15:02:14 +0900 Masahide NAKAMURA wrote: > Hello, > > This patch is minor fix for iproute2. > It consists of two small ChangeSets. Applied to the iproute2 bk tree for next release. From herbert@gondor.apana.org.au Fri Jul 16 16:06:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 16:06:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6GN6Cvw029351 for ; Fri, 16 Jul 2004 16:06:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Blbm9-0004Gn-00; Sat, 17 Jul 2004 09:05:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Blbm5-0003lF-00; Sat, 17 Jul 2004 09:05:53 +1000 Date: Sat, 17 Jul 2004 09:05:53 +1000 To: Masahide NAKAMURA Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 2/3] iproute2 and xfrm Message-ID: <20040716230552.GA14245@gondor.apana.org.au> References: <20040703094632.GA14235@gondor.apana.org.au> <20040705160500.208591b5@localhost> <20040706140550.2d483dc8@dell_ss3.pdx.osdl.net> <20040707130950.0112edf6@localhost> <20040707140533.41c66c03@localhost> <20040707155602.4698121a@localhost> <20040707110315.GA26100@gondor.apana.org.au> <20040709125100.3edce4e9@localhost> <20040714174233.2fc7dbc2@localhost> <20040715150219.24a498a6@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040715150219.24a498a6@localhost> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7019 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Thu, Jul 15, 2004 at 03:02:19PM +0900, Masahide NAKAMURA wrote: > > This patch is for iproute2. > Please check comment in a ChangeSet below. Thanks for the patches. It's much better. I think some simplifications can still be made: Policies: * sel/upsec are redundant. You can disambiguate src/dst/proto by whether they're preceded by tmpl or not. * proto/sport/dport should be omitted if they're zero. * level should be omitted if it's required. * spi should be omitted if it's zero. * index should be omitted in the default output. It's not a part of the policy specification. * action should be omitted if it's allow. States: * spi should be shown in hex by default. Related tools like tcpdump show hex so this makes debugging easier. * flag should be omitted if it's zero. * Please use auth/enc instead of A/E. The latter looks out-of-place in ip(8). * You can also skip algo and use auth/enc to detect the start of an algorithm. * replay_window is not a statistic so it should shown in the main output. * The selector should be shown in the main output if it is not zero. The above changes can be summarised by these two principles: 1. By cut-n-pasting the output of ip x p/s, I should be able to recreate the exact same policies/states. 2. The output of ip x p/s should be minimal so that it is easy to understand and type in. Please also fix ip -o x so that the output can be on one line. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dsaxena@plexity.net Fri Jul 16 17:38:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 17:38:39 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6H0cXPf002496 for ; Fri, 16 Jul 2004 17:38:34 -0700 Received: from plexity.net (c-24-20-152-76.client.comcast.net[24.20.152.76]) by comcast.net (sccrmhc11) with ESMTP id <2004071616254601100sua76e>; Fri, 16 Jul 2004 16:25:51 +0000 Received: by plexity.net (Postfix, from userid 1025) id 5C31A2182C2; Fri, 16 Jul 2004 09:25:45 -0700 (PDT) Date: Fri, 16 Jul 2004 09:25:45 -0700 From: Deepak Saxena To: jamal Cc: jgarkzik@pobox.om, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Add IXDP2x01 board support to CS89x0 driver Message-ID: <20040716162545.GA4351@plexity.net> Reply-To: dsaxena@plexity.net References: <20040716092859.GA16849@plexity.net> <1089983382.1060.1332.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089983382.1060.1332.camel@jzny.localdomain> Organization: Plexity Networks User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 7020 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dsaxena@plexity.net Precedence: bulk X-list: netdev On Jul 16 2004, at 09:09, jamal was caught saying: > On Fri, 2004-07-16 at 05:28, Deepak Saxena wrote: > > Jeff, > > > > The following patch modifies the CS89x0 driver to work on Intel's IXDP2401 > > and IXDP2801 (Intel ARm/XScale based) platforms: > > > > cool. Do you need anything else that is not in the kernel to boot either > board? I have a patch I will be releasing today or monday (see linux-arm-announce list) that contains the arm-specific bits. Unfortunately since rmk is travelling for about 3 weeks it won't go upstream for atleast that time period. ~Deepak -- Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/ "Unlike me, many of you have accepted the situation of your imprisonment and will die here like rotten cabbages." - Number 6 From lists@mdiehl.de Fri Jul 16 20:44:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 20:44:09 -0700 (PDT) Received: from bart.webpack.hosteurope.de (bart.webpack.hosteurope.de [217.115.142.76]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6H3i1FK009087 for ; Fri, 16 Jul 2004 20:44:02 -0700 Received: from pd9e95406.dip0.t-ipconnect.de ([217.233.84.6] helo=notebook.home.mdiehl.de) by bart.webpack.hosteurope.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BlEgh-000334-8E; Fri, 16 Jul 2004 00:26:47 +0200 Received: from notebook.home.mdiehl.de (localhost.localdomain [127.0.0.1]) by notebook.home.mdiehl.de (8.12.1/8.12.1) with ESMTP id i6FMWkji017324; Fri, 16 Jul 2004 00:32:48 +0200 Received: from localhost (martin@localhost) by notebook.home.mdiehl.de (8.12.1/8.12.1/Submit) with ESMTP id i6FMWjBc017320; Fri, 16 Jul 2004 00:32:45 +0200 X-Authentication-Warning: notebook.home.mdiehl.de: martin owned process doing -bs Date: Fri, 16 Jul 2004 00:32:44 +0200 (CEST) From: Martin Diehl X-X-Sender: martin@notebook.home.mdiehl.de To: Andi Kleen cc: Jeff Garzik , , , , , Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers In-Reply-To: <20040715215552.GA46635@muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HE-MXrcvd: no X-archive-position: 7021 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lists@mdiehl.de Precedence: bulk X-list: netdev On 15 Jul 2004, Andi Kleen wrote: > Remove wrong ISA dependencies for IRDA drivers. > > > diff -u linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig > --- linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig-o 2004-07-12 06:09:05.000000000 +0200 > +++ linux-2.6.8rc1-amd64/drivers/net/irda/Kconfig 2004-07-15 18:33:48.000000000 +0200 > @@ -310,7 +310,7 @@ > > config NSC_FIR > tristate "NSC PC87108/PC87338" > - depends on IRDA && ISA > + depends on IRDA Admittedly I haven't tried either, but I'm pretty sure this patch will break building those drivers because they are calling irda_setup_dma - which is CONFIG_ISA. Maybe this can be dropped but I don't see what's wrong with !64BIT instead. Martin From lists@mdiehl.de Fri Jul 16 21:59:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jul 2004 21:59:10 -0700 (PDT) Received: from bart.webpack.hosteurope.de (bart.webpack.hosteurope.de [217.115.142.76]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6H4x3EX010382 for ; Fri, 16 Jul 2004 21:59:04 -0700 Received: from pd9e952b3.dip0.t-ipconnect.de ([217.233.82.179] helo=notebook.home.mdiehl.de) by bart.webpack.hosteurope.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BlMC4-0000nB-Jg; Fri, 16 Jul 2004 08:27:40 +0200 Received: from notebook.home.mdiehl.de (localhost.localdomain [127.0.0.1]) by notebook.home.mdiehl.de (8.12.1/8.12.1) with ESMTP id i6G6Xlji018781; Fri, 16 Jul 2004 08:33:47 +0200 Received: from localhost (martin@localhost) by notebook.home.mdiehl.de (8.12.1/8.12.1/Submit) with ESMTP id i6G6XjHS018778; Fri, 16 Jul 2004 08:33:46 +0200 X-Authentication-Warning: notebook.home.mdiehl.de: martin owned process doing -bs Date: Fri, 16 Jul 2004 08:33:45 +0200 (CEST) From: Martin Diehl X-X-Sender: martin@notebook.home.mdiehl.de To: Andi Kleen cc: Jeff Garzik , , , Jean Tourrilhes , , Linux Kernel Subject: Re: [PATCH] Drop ISA dependencies from IRDA drivers In-Reply-To: <20040716061913.GB662@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HE-MXrcvd: no X-archive-position: 7022 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lists@mdiehl.de Precedence: bulk X-list: netdev On Fri, 16 Jul 2004, Andi Kleen wrote: > > According to include/asm-x86_64/dma-mapping.h there is no such override > > for x86-64. Hence the generic implementation is used which Oopses when > > called with dev=NULL in dma_alloc_coherent because it dereferences dev > > unconditionally. > > The old pci_alloc_coherent supported hwdev == NULL under x86-64. > dma_alloc_consistent() should too. I will fix that. Ok, thanks. This sounds like the right solution. I think most/all functions in include/asm-generic/dma-mapping.h are not prepared to accept dev=NULL parameters, so it's a bit more than just dma_alloc_coherent() :-( Martin From herbert@gondor.apana.org.au Sat Jul 17 00:43:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 00:43:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6H7hUiU016449 for ; Sat, 17 Jul 2004 00:43:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bljqs-0007BV-00; Sat, 17 Jul 2004 17:43:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bljqp-0004vt-00; Sat, 17 Jul 2004 17:43:19 +1000 Date: Sat, 17 Jul 2004 17:43:19 +1000 To: James Morris Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [CRYPTO] Fix stack overrun in crypt() Message-ID: <20040717074319.GA18919@gondor.apana.org.au> References: <20040715114840.GA1325@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7023 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Jul 16, 2004 at 11:27:36AM -0400, James Morris wrote: > > > This fixes a number of weird crashes including those AES crashes > > that people have been seeing with the 2.4 backport + ipt_conntrack. > > Ok, thanks, looks good. Thanks for reviewing it. Unfortunately it looks like we still have a problem. gcc 3.3.4 appears to be generating incorrect output on i386 with the dynamic stack allocation used in crypt() and the functions around it. In particular, it can give you 8 bytes when you ask for 16 bytes. See my report at http://bugs.debian.org/259887 for details. Fortunately, it seems that overwriting 8 bytes beyond the end of the array in crypt() is not fatal. After all, that's why people only saw crashes with AES and not 3DES. But this is still a potential source of problem, especially given algorithms with bigger block sizes. I think we should stop people from building the kernel with gcc 3.3.* until this problem is addressed. What do you guys think? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From vkondra@mail.ru Sat Jul 17 02:11:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 02:11:26 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6H9BJVb018319 for ; Sat, 17 Jul 2004 02:11:19 -0700 Received: from [212.179.226.190] (port=24848 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BllDw-00037m-00 for netdev@oss.sgi.com; Sat, 17 Jul 2004 13:11:16 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: TGe overview #2 Date: Sat, 17 Jul 2004 12:11:09 +0300 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Message-Id: <200407171211.15486.vkondra@mail.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6H9BJVb018319 X-archive-position: 7024 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If we do only TXOP and 4 AC categories described in my previous posting, it will correspond to WME, which is another draft for QoS, implemented in some cards. Let's move on with TGe. It defines 16 Traffic Identifiers (TID) per destination address (DA). This defines 16 independent streams simultaneously maintained. From these 16 TID's, first 8 corresponds to 802.1d user priority and are statically mapped to 4 AC in this way: TID AC 1(BK) 1(AC_BK) 2 1(AC_BK) 0(BE) 0(AC_BE) 3(EE) 0(AC_BE) 4(CL) 2(AC_VI) 5(VI) 2(AC_VI) 6(VO) 3(AC_VO) 7(NC) 3(AC_VO) Other 8 TID's, 8-15, used to describe Traffic Streams (TS), and used to implement IntServ like QoS. To remind, access to the channel is per AC, with parameters dictated by AP. AP may change these parameters in run time. Mechanics of EDCA parameters propagation and other details: EDCA parameters (CWmin,CWmax,AIFSN,TXOP) included in beacon frame transmitted by AP periodically (every 100ms). TID included in each frame, there is special QoS field in 802.11 MAC header. How to distribute per AC time between TID's is not specified by standard. STA should specify its QoS capabilities when associating with AP. AP may reject STA that not support QoS. AP may analyze STA's behavour and disassociate it for protocol violation like over utilization of channel. To summarize, this defined diffserv QoS with parameters dictated by AP. In next post, I will describe HCCA (hybrid coordinated channel access) and IntServ like QoS. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA+O0zqxdj7mhC6o0RApt9AJ44/rSb7if9sjZYtE3WfnfTMnasLwCeOhuC kCGwr/mJeoVU30MVB+dpLI8= =GHGu -----END PGP SIGNATURE----- From herbert@gondor.apana.org.au Sat Jul 17 02:48:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 02:48:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6H9mcUS020808 for ; Sat, 17 Jul 2004 02:48:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bllnz-0007zU-00; Sat, 17 Jul 2004 19:48:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bllnx-00059S-00; Sat, 17 Jul 2004 19:48:29 +1000 Date: Sat, 17 Jul 2004 19:48:29 +1000 To: James Morris Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [CRYPTO] Fix stack overrun in crypt() Message-ID: <20040717094829.GA19791@gondor.apana.org.au> References: <20040715114840.GA1325@gondor.apana.org.au> <20040717074319.GA18919@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040717074319.GA18919@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7025 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Jul 17, 2004 at 05:43:19PM +1000, herbert wrote: > > Unfortunately it looks like we still have a problem. gcc 3.3.4 appears > to be generating incorrect output on i386 with the dynamic stack > allocation used in crypt() and the functions around it. > > In particular, it can give you 8 bytes when you ask for 16 bytes. > See my report at http://bugs.debian.org/259887 for details. I got it wrong. gcc is simply allocating some (12 bytes) of the space unconditionally. Sorry for the noise. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From Robert.Olsson@data.slu.se Sat Jul 17 03:08:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 03:08:19 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6HA8ADN021334 for ; Sat, 17 Jul 2004 03:08:11 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6HA87IR005923; Sat, 17 Jul 2004 12:08:07 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id E44FDEC33E; Sat, 17 Jul 2004 12:08:07 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16632.64135.856238.115334@robur.slu.se> Date: Sat, 17 Jul 2004 12:08:07 +0200 To: Christopher Chan Cc: netdev@oss.sgi.com, Robert.Olsson@data.slu.se Subject: dst cache overflow errors In-Reply-To: <40E69930.1080402@outblaze.com> References: <40E69930.1080402@outblaze.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7026 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Christopher Chan writes: > Recently, the Intel chaps wanted to have NAPI permanently enabled for > their e100 driver. However, i still get network connectivity problems if > I enable NAPI in e100 for 2.6.7. Severe cases result in the kernel not > logging clear messages about its bug traps...due to the messages being > obfuscated beyond understanding. > > I wonder then whether the cause/problem, that makes the kernel log dst > cache overflows and its BUG_TRAPs in the logs, has been identified? Hello! dst cache overflow most like indicates you have higher throughput and you should tune your hash tunings accordingly. So it might not be a bug. Verify this by monitoring the routing stats. rtstat is a utility for this. You probably most interested in three first columns. size IN: hit tot 8060 34009 271 This means we have 34 kpps of hits to existent hash entries. While 271 new were created per sec. The ratio will be different for you as you reach dst overflow but compare your two cases. There is now an option to set rhash_entries= at boot which is probably how you how to tune it. rtstat is in iproute2 package but also in: ftp://robur.slu.se/pub/Linux/net-development/rt_cache_stat/rtstat.c Cheers. --ro From Robert.Olsson@data.slu.se Sat Jul 17 04:27:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 04:27:07 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6HBQwGx026325 for ; Sat, 17 Jul 2004 04:27:00 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6HBQqIR022994; Sat, 17 Jul 2004 13:26:53 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id E5C4EEC33E; Sat, 17 Jul 2004 13:26:52 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16633.3324.909512.231023@robur.slu.se> Date: Sat, 17 Jul 2004 13:26:52 +0200 To: andre@insite.com.br Cc: netdev@oss.sgi.com, Robert.Olsson@data.slu.se Subject: route cache overflow X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7027 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Andre Uratsuka Manoel writes: > Hello, > > It seems that no resolution was found for the route cache DoS issue > (am I wrong here?). Well we see different performance for different flow lengths. The numbers we've see is 1 packet per flow is .22 (22%) of single flow for packet forwarding. Decreasing hash chain during DoS we could increase the t-put to .34 of single flow. Still Linux is very usable as it is very seldom in real scenarios that there is 100% DoS at all interface. > I was wondering, and I'd like to persue this line of thought if you > don't consider this stupid: wouldn't it be better, when we find that > the machine is under DoS to avoid creating route cache entries instead > of simply trying to drop entries that exist? I did some experiments to make the route hash per device but didn't see any performance wins compared to the global hash but for policy control and tuning it would probably improve things with per dev hash. ftp://robur.slu.se/pub/Linux/net-development/dhash But the problem is how to define/find DoS which is in reality mixed with real traffic. I'm getting to think we can not have any special DoS treatment at route level as this would open for new DoS attacks. We have to assume traffic is sane. > Couldn't we create entries only once for every 1< ip_route_input_slow so that flows with many packets will have route > cache entries created with higher probability than flows with very > little connections. The n variable could be adjusted according to > perceived DoS-ness. We have done a lot job already getting the skb into the CPU cache and also we must look up the address to verify if it belongs to a flow or not. It seems ipv6 does not create hash entries as ipv4 and should be more tolerant in this aspect but ipv6 has another major issue be design as the link nets have 2^64 addresses. Neighbor entries can overflow any table. Also it might be interesting to see what other lookup algorithms can do. Working on some LPC-trie (level path compresses seach tree) code hoping to able to test this for lookup someday. Cheers. --ro From ak@muc.de Sat Jul 17 04:40:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 04:40:17 -0700 (PDT) Received: from zero.aec.at (Barel_Dort@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6HBe9bf026826 for ; Sat, 17 Jul 2004 04:40:11 -0700 Received: from averell.firstfloor.org.muc.de (Hassan_Brubuddy@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i6HBaAc12254; Sat, 17 Jul 2004 13:36:15 +0200 To: chas@cmf.nrl.navy.mil cc: linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] Fix 64bit warning for firestream From: Andi Kleen Date: Sat, 17 Jul 2004 13:36:08 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7028 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Fix obvious 64bit issue in firestream driver. I haven't tested if it actually works on 64bit due to lack of hardware. -Andi diff -u linux-2.6.8rc1-amd64-pre2/drivers/atm/firestream.c-o linux-2.6.8rc1-amd64-pre2/drivers/atm/firestream.c --- linux-2.6.8rc1-amd64-pre2/drivers/atm/firestream.c-o 2004-07-17 13:26:01.000000000 +0200 +++ linux-2.6.8rc1-amd64-pre2/drivers/atm/firestream.c 2004-07-17 13:33:49.525480904 +0200 @@ -1380,7 +1380,7 @@ if (alignment <= 0x10) { t = kmalloc (size, flags); - if ((unsigned int)t & (alignment-1)) { + if ((unsigned long)t & (alignment-1)) { printk ("Kmalloc doesn't align things correctly! %p\n", t); kfree (t); return aligned_kmalloc (size, flags, alignment * 4); From hadi@cyberus.ca Sat Jul 17 04:52:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 04:52:26 -0700 (PDT) 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 i6HBqJJ8027327 for ; Sat, 17 Jul 2004 04:52:19 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Blnjh-0004yA-9g for netdev@oss.sgi.com; Sat, 17 Jul 2004 07:52:13 -0400 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 1Blnjg-00082N-4l; Sat, 17 Jul 2004 07:52:12 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089990384.6114.2842.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> <1089912658.1029.101.camel@jzny.localdomain> <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> <1089981282.1060.1293.camel@jzny.localdomain> <1089990384.6114.2842.camel@uganda> Content-Type: text/plain Organization: jamalopolis Message-Id: <1090065129.1066.1196.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Jul 2004 07:52:09 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7029 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 Fri, 2004-07-16 at 11:06, Evgeniy Polyakov wrote: > On Fri, 2004-07-16 at 16:34, jamal wrote: > > > > Ok, so some controller is in charge - seems like thats something that > > could be easily done in user space based on mastership transitions. > > Yes, but here is tricky but true example: > Some time ago e1000 driver from Intel had possibility to do hardware > bonding(i absolutely don't remember how it was called, but idea was the > same as in bonding). I remeber that cruft. Actually (sadly) people like montavista ship that thing in their distros (under the disguise of carrier grade linux;->). I think the current folks out of intel working on Linux drivers and bonding are a lot more knowledgeable - i do hope they have thrown that "thing" out of the window. > Consider following scenario: if node is a master than it enables this > bonding mode using e1000 internal registers. Ethtools doesn't support > those mode. yes it also can be enabled through patching userspace, but > with kernel CARP it is not needed. The way bonding works is the right way to do it. Forget about that other crap. There was a thread on netdev a while back to empower bonding to be controlled from user space; when that happens you are set. But even without that the link carrier netlink event messages should be a good start. > Or consider TGE example(...wireless HA... strange sentence, but...): > If I am a master, than enable higher priority in driver. > Current tc design can't be mapped to driver's internal structures :> Now you want to wakeup mr Vladimir ;-> Actually i think i just saw mails from him. Yes, these are some of the issues we wanna go work on. Still waiting for the brief review of RSVP-like control being used in TGE. And when done all that should be done in user space. > But the main killer is following: > consider firewall with thousands iptables rules, and if node becomes a > master it needs to add or remove some rules from table. > Copying such amounts to/from userspace/kernelspace memory will take > _minutes_... Even using iptables chains. > But kernel implementation may just add one rule. Thats a deficiency in iptables. Iptables should be fixed. I think there may be plans to fix it actually in place. > Yet another variant: you need to access CPU internal registers based on > HA state, kind of turning on or off additional hotplug CPU and or > memory, enabling/disabling NUMA access. Can you enable/disable bus > arbiter from userspace? I think you should be able to write an interface to access such functionality. Isnt there something along /sbin/hotplug used for such things? > For example I'm using on-chip SDRAM in PPC440 as L2 cache or as jitter > buffer for OPB access, decision to use each mode is based on some > hardware loads. Userspace do not have access to such mechanism. > It is deep kernel internals, and I do not see any good reason to export > it to userspace. > Actually last example can't be used as argument in our discussion, but > it illustrates that sometimes we need to touch kernel-_only_ parts, and > this decision is dictated from the outside of the touchable part. > I can tell you one thing: I am totaly against this thing being part of the kernel; not just because it adds noise but because it makes it harder to keep adding more and more functionality or integrating its capability into other apps. BTW, theres a very nice paper being presented at OLS by someone from .au who is trying infact to move drivers to user space ;-> I dont mind adding some needed datapath mechanism in the kernel to enable it to do interesting things; control of such mechanism and policy decisions should be very clearly separated and sit in userspace. > > BTW, I like that ARP balancing feature that CARP has. Pretty neat. > > Note that it could be easily done via a tc action with user space > > control. > > Anything may be done in userspace. > For example routing decision. > Yes, it _may_ be done in userspace. But it is slow. Big difference though with CARP. CARP shouldnt need to process 100Kpps; but even if it did, CARP packet contain control information that is valuable in policy settings. Control protocols tend to be "rich" and evolve over much shorter periods of time. A better comparison what you are saying is to move OSPF to the kernel. > SCSI over IP may be done as network block device. > Or even copying packet to userspace through raw device and then send it > using socket. Again all that is datapath. CARP is control. > QNX and Mach are even designed in this way. We just have better architecture thats all ;-> [BTW, A lot of people with experience in things like vxworks (one big flat memory space) always want to move things into the kernel. Typically after some fight they move certain things to user space with "you will hear from me" threats. I never hear back from them because it works fine. This after they wanted to shoot me because linux "wasnt realtime"] > It is not talk about current possibilities, it is kind of design :) > Yes, probably our _current_ needs may be satisfied using existing > userspace tools. > But I absolutely sure that we will need in-kernel support. > I'm reading you second e-mail with pretty diagrams and already see where > in-kernel CARP will live there :) Ok;-> I am looking forward to see your view on it. cheers, jamal From johnpol@2ka.mipt.ru Sat Jul 17 05:48:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 05:48:18 -0700 (PDT) Received: from ffke-campus-gw.mipt.ru (ffke-campus-gw.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6HCmAPV028507 for ; Sat, 17 Jul 2004 05:48:11 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by ffke-campus-gw.mipt.ru (8.12.11/8.12.11) with SMTP id i6HCm0Rx005560; Sat, 17 Jul 2004 16:48:01 +0400 Date: Sat, 17 Jul 2004 16:59:42 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org Subject: Re: [1/2] CARP implementation. HA master's failover. Message-Id: <20040717165942.1e7f847f@zanzibar.2ka.mipt.ru> In-Reply-To: <1090065129.1066.1196.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> <1089912658.1029.101.camel@jzny.localdomain> <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> <1089981282.1060.1293.camel@jzny.localdomain> <1089990384.6114.2842.camel@uganda> <1090065129.1066.1196.camel@jzny.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7031 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On 17 Jul 2004 07:52:09 -0400 jamal wrote: > > Actually last example can't be used as argument in our discussion, > > but it illustrates that sometimes we need to touch kernel-_only_ > > parts, and this decision is dictated from the outside of the > > touchable part. > > > > I can tell you one thing: I am totaly against this thing being part > of the kernel; not just because it adds noise but because it makes it > harder to keep adding more and more functionality or integrating its > capability into other apps. > BTW, theres a very nice paper being presented at OLS by someone from > .au who is trying infact to move drivers to user space ;-> I saw it... May I not comment it? I do not want to look like rude freak... :) > I dont mind adding some needed datapath mechanism in the kernel to > enable it to do interesting things; control of such mechanism and > policy decisions should be very clearly separated and sit in > userspace. > > > > BTW, I like that ARP balancing feature that CARP has. Pretty neat. > > > Note that it could be easily done via a tc action with user space > > > control. > > > > Anything may be done in userspace. > > For example routing decision. > > Yes, it _may_ be done in userspace. But it is slow. > > Big difference though with CARP. CARP shouldnt need to process > 100Kpps; but even if it did, CARP packet contain control information > that is valuable in policy settings. Control protocols tend to be > "rich" and evolve over much shorter periods of time. > A better comparison what you are saying is to move OSPF to the kernel. Only for now, since we can imagine only some examples now. When number of agents controlled/connected to CARP will became significant broadcasting and userspace arbiter's overhead may not satisfy HA needs. > > SCSI over IP may be done as network block device. > > Or even copying packet to userspace through raw device and then send > > it using socket. > > Again all that is datapath. CARP is control. Control, but it must have possibility to control any dataflow element. If using all_flows_one_arbiter, then we must have near standing controller like in-kernel CARP. If using one_flow_one_arbiter(like tc) then we may use far outstanding control mechanism and near standing arbiter. Like qdisk + tc + ucarp. The question is: "Do we need to create near standing ariters and far standing controller for scenatio A, while we may have near standing controller?". I do believe that for some situations we just need in-kernel controller without any overhead and simple in-kernel interface. > > QNX and Mach are even designed in this way. > > We just have better architecture thats all ;-> If we want to put as many as possible outside the kernel while it works better in kernel then we slowly go to meet microkernel and userspace thread for fs, for network, which will be controlled by broadcast messages for simplifying control protocol. But it is too far planes, so it is just "blah-blah" lyrics now... :) > [BTW, A lot of people with experience in things like vxworks (one big > flat memory space) always want to move things into the kernel. > Typically after some fight they move certain things to user space with > "you will hear from me" threats. I never hear back from them because > it works fine. This after they wanted to shoot me because linux "wasnt > realtime"] BTW, I just reread OpenBSD's load balancing code... IT is different from that one which may be created with tc and it's extensions. They look into each packet and if it's "signature" is controlled by node and this node is master than process this packet. They have one arbiter for any dataflow, while Linux has many arbiters each of which may be controlled from userspace, that is the difference. So their schema may not be implemented in userspace CARP, while in Linux it may be implemented using tc extensions with userspace CARP. I will rewrite my resume: With your approach any data flow MUST go through userspace arbiters with all overhead and complexity. With my approach any data flow _MAY_ go through userspace arbiters, but if you do_need/only_has in-kernel access than using in-kernel CARP is the only solution. My main idea for in-kernel CARP was to implement invisible HA mechanism suitable for in-kernel use. You do not need to create netlink protocol parser, you do not need to create extra userspace overhead, you do not need to create suitable for userspace control hooks in kernel infrastructure. Just register callback. But even with such simple approach you have opportunity to collaborate with userspace. If you need. Why creating all userspace cruft if/when you need only kernel one? > > It is not talk about current possibilities, it is kind of design :) > > Yes, probably our _current_ needs may be satisfied using existing > > userspace tools. > > But I absolutely sure that we will need in-kernel support. > > I'm reading you second e-mail with pretty diagrams and already see > > where in-kernel CARP will live there :) > > Ok;-> I am looking forward to see your view on it. > > cheers, > jamal Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From hadi@cyberus.ca Sat Jul 17 05:47:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 05:47:49 -0700 (PDT) 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 i6HClg8g028450 for ; Sat, 17 Jul 2004 05:47:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BlobJ-0000hZ-T9 for netdev@oss.sgi.com; Sat, 17 Jul 2004 08:47:37 -0400 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 1BlobI-0003KK-Fq; Sat, 17 Jul 2004 08:47:36 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <1089990401.6114.2843.camel@uganda> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> <1089990401.6114.2843.camel@uganda> Content-Type: multipart/mixed; boundary="=-Jg80ClHEA8W8IX24Rgxz" Organization: jamalopolis Message-Id: <1090068454.1064.1258.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Jul 2004 08:47:34 -0400 X-archive-position: 7030 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 --=-Jg80ClHEA8W8IX24Rgxz Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2004-07-16 at 11:06, Evgeniy Polyakov wrote: > On Fri, 2004-07-16 at 17:04, jamal wrote: > [..] > They do strong signed digest, but it does not have any kind of counter > so i do not see replay attack prevention. Ok, you are right. I do think that there are people who have run this over IPSEC though. I could swear that the current linux based one does. I wish we could get Alexander to comment on this discussion. > > > > Can it be used over IPv6? (CARP also can't but it is _very_ easy to > > > add, I just don't have IPv6 network setup to test). > > > > Theres effort to have it do v6. > > http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-06.txt > > I agree its lame to have it as an after thought it seems > > * VRRP for IPv6 does not currently include any type of authentication. * Fine. > I will draw one too. ok, my resonse attached. > For those who cares they are already done. I was done 10 years ago. But theres a lot of fools around. MS targets the fools. > > > I have great confidence that Theo de Raadt will not include non > > > patent-free code in OpenBSD. > > > > I hope he is a lawyer or has some good lawyer advising him;-> > > He is an OpenBSD creator, so he is just a bit more paranoidal than > others :) I see ;-> cheers, jamal --=-Jg80ClHEA8W8IX24Rgxz Content-Disposition: attachment; filename=carp.dig2 Content-Type: text/plain; name=carp.dig2; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit No, your diagram should looks like this: User space +----------------------------------------------------------+ | | | +-------------------------------------+ | | | | | +-------+ +-------+ +---------+ +-------+ +-------+ | App#A | <-----> | CARPd | <-----> | ctsyncd | <-----> | App#B | <-----> | App#C | <-----> +---+---+ +---+---+ +---+-----+ +---+---+ +---+---+ | | | | | | | | ------------------------------------------------------------------------------------------ Kernel network I/O etc Or only have one BUS(and it is actually implemented using netlink). jamal> I relabeled the Apps. I suppose you see some apps using ctsyncd for something? You need to connect each application daemon to carpd, even using broadcast netlink. And for any in-kernel access you will need to create new App and new kernel part. jamal> App2app doesnt have to go across kernel unless it turns out it is the jamal> best way. jamal> Alternatives include: unix or local host sockets, IPCs such as pipes or jamal> just shared libraries. jamal> If we will extrapolate it we can create following: userspace carp determines that it is a master, it will suspend all kernel memory or dump /proc/kmem and begins to advertise it. Remote node receives it and has pretty the same firewall settings, flow controls and any in-kernel state. jamal> I havent studied what Harald proposes in details. I think that the slave would jamal> continously be getting master updates. jamal> The interesting thing about CARP is the ARP balancing feature in which X nodes jamal> maybe masters of different IP flows all within the same subnet. jamal> VRRP load balances by subnet. I am not sure how challenge this will present to jamal> to ctsyncd. No matter that it takes a long time. It make sence if App#X needs userspace access only. But here is other diagram: userspace | -----------------+------------------------------- CARP kernelspace | | +----------+-----+-----+---------+------- | | | | ct_sync iSCSI e1000 CPU My main idea for in-kernel CARP was to implement invisible HA mechanism suitable for in-kernel use. You do not need to create netlink protocol parser, you do not need to create extra userspace overhead, you do not need to create suitable for userspace control hooks in kernel infrastructure. Just register callback. But even with such simple approach you have opportunity to collaborate with userspace. If you need. Why creating all userspace cruft if/when you need only kernel one? jamal> jamal> so we now move appA, B, C to the kernel too? jamal> There is absolutely no need to put this in kernel space. jamal> If you do this, your next step should be to put zebra in the kernel jamal> Resume: With your approach any data flow MUST go through userspace arbiters with all overhead and complexity. With my approach any data flow _MAY_ go through userspace arbiters, but if you do_need/only_has in-kernel access than using in-kernel CARP is the only solution. jamal> jamal> Yes, there is a cost. How much? Read the paper on user space drivers it actually does jamal> some cost analysis. jamal> If you prove that it is too expensive to put it in user space then prove it and lets jamal> have a re-discussion jamal> --=-Jg80ClHEA8W8IX24Rgxz-- From johnpol@2ka.mipt.ru Sat Jul 17 06:48:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 06:48:55 -0700 (PDT) Received: from ffke-campus-gw.mipt.ru (ffke-campus-gw.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6HDmjuE030373 for ; Sat, 17 Jul 2004 06:48:46 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by ffke-campus-gw.mipt.ru (8.12.11/8.12.11) with SMTP id i6HDmdjM010732; Sat, 17 Jul 2004 17:48:41 +0400 Date: Sat, 17 Jul 2004 18:00:19 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org Subject: Re: [1/2] CARP implementation. HA master's failover. Message-Id: <20040717180019.7db1473f@zanzibar.2ka.mipt.ru> In-Reply-To: <1090068454.1064.1258.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> <1089990401.6114.2843.camel@uganda> <1090068454.1064.1258.camel@jzny.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7032 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On 17 Jul 2004 08:47:34 -0400 jamal wrote: jamal> I relabeled the Apps. I suppose you see some apps using ctsyncd for something? >>You need to connect each application daemon to carpd, even using >>broadcast netlink. And for any in-kernel access you will need to >>create >>new App and new kernel part. jamal> App2app doesnt have to go across kernel unless it turns out it is jamal> the best way. jamal> Alternatives include: unix or local host sockets, IPCs such as jamal> pipes or jamal> just shared libraries. MICROKERNEL, I see it :) Non broacast/multicast will _strongly_ complicate protocol. Broadcast will waste apprication/kernel "bandwidth". >>If we will extrapolate it we can create following: >>userspace carp determines that it is a master, it will suspend all >>kernel memory or dump /proc/kmem and begins to advertise it. Remote >>node >>receives it and has pretty the same firewall settings, flow controls >>and >>any in-kernel state. jamal> I havent studied what Harald proposes in details. I think that jamal> the slave would jamal> continously be getting master updates. Is it is. jamal> The interesting thing about CARP is the ARP balancing feature in jamal> which X nodes jamal> maybe masters of different IP flows all within the jamal> same subnet. jamal> VRRP load balances by subnet. I am not sure how jamal> challenge this will present to jamal> to ctsyncd. CARP may do it, but it requires in-kernel hack into arp code. Actually OpenBSD's one has it's entry in if_ether.c so their CARP always has access to any network dataflow. BTW, with your approach hack from arp code needs to send a message to userspace carp to ask if it "good or bad" packet. Or you need to create tc for arp. Or to communicate with in-kernel CARP. :) >>No matter that it takes a long time. >>It make sence if App#X needs userspace access only. >>But here is other diagram: userspace | -----------------+------------------------------- CARP kernelspace | | +----------+-----+-----+---------+------- | | | | ct_sync iSCSI e1000 CPU >>My main idea for in-kernel CARP was to implement invisible HA >>mechanism >>suitable for in-kernel use. You do not need to create netlink protocol >>parser, you do not need to create extra userspace overhead, you do not >>need to create suitable for userspace control hooks in kernel >>infrastructure. Just register callback. >>But even with such simple approach you have opportunity to collaborate >>with userspace. If you need. >>Why creating all userspace cruft if/when you need only kernel one? jamal> jamal> so we now move appA, B, C to the kernel too? jamal> There is absolutely no need to put this in kernel space. jamal> If you do this, your next step should be to put zebra in the jamal> kernel No. And this is the beauty of the in-kernel CARP. You _already_ has in-kernel parts which may need master/slave failover. You just need to connect it to arbiter. With userspace you _need_ to create all those Apps connected to userspace carp, with in-kernel CARP you need to just register callback. One function call. BTW, someone created tux, khtpd, knfsd :) But i think zebra must live in userspace, since it do not need to control any kernel parameters. CARP _may_ control kernel parameters. If you do not need in-kernel functionality just use UCARP. >>Resume: >>With your approach any data flow MUST go through userspace arbiters >>with >>all overhead and complexity. With my approach any data flow _MAY_ go >>through userspace arbiters, but if you do_need/only_has in-kernel >>access >>than using in-kernel CARP is the only solution. jamal> Yes, there is a cost. How much? Read the paper on user space jamal> drivers it actually does jamal> some cost analysis. jamal> If you prove that it is too expensive to put it in user space jamal> then prove it and lets jamal> have a re-discussion Hey-ho, easily :) Consider embedded processors. Numbers: ppc405gp, 200mhz, 32mb sdram. Application - 4-8 DSP processors controlled by ppc. Each dsp processor generates 6-8 bytes frame with 8khz frequency in each channel(from 1 to 2). Driver reads data from each DSP and doing some postprocessing(mainly split it into B/D channels). Driver has clever mapping so userspace<->kernelspace dataflow may be zerocopied. Kernelspace processing takes up to 133mghz of 200. Consider userspace application that a. makes PCM stereo from different B/D logical channels (zerocopied from kernelspace). b. send it into network (using tcp by bad historical/compatibility reasons). Situation: if we have one userspace process(or even thread) per DSP, than context switching takes too long time and we see data corruption. None network parameter(100 mb network) can improve situation. Only one process per 4 DSP may send data into network stack without any data loss. P.S. It is 2.4.25 kernel. I do believe that Peter Chubb (peterc@gelato.unsw.edu.au) will talk about big machines where big tasks _may_ have big time latencies. May Oracle have little latencies? May. But it also _may_ have big latencies. Why not? DSP and sound/video capturing _may_not_ have big latencies. Although I do think that talk about userspace drivers is not an issue in our discussion :) > > cheers, > jamal > Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From hadi@cyberus.ca Sat Jul 17 08:47:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 08:48:04 -0700 (PDT) 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 i6HFlwZ2003997 for ; Sat, 17 Jul 2004 08:47:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BlrPm-0004TU-4w for netdev@oss.sgi.com; Sat, 17 Jul 2004 11:47:54 -0400 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 1BlrPh-0000El-Qy; Sat, 17 Jul 2004 11:47:50 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <20040717165942.1e7f847f@zanzibar.2ka.mipt.ru> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> <1089912658.1029.101.camel@jzny.localdomain> <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> <1089981282.1060.1293.camel@jzny.localdomain> <1089990384.6114.2842.camel@uganda> <1090065129.1066.1196.camel@jzny.localdomain> <20040717165942.1e7f847f@zanzibar.2ka.mipt.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1090079263.1063.1303.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Jul 2004 11:47:43 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7033 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, 2004-07-17 at 08:59, Evgeniy Polyakov wrote: > On 17 Jul 2004 07:52:09 -0400 > jamal wrote: > > BTW, theres a very nice paper being presented at OLS by someone from > > .au who is trying infact to move drivers to user space ;-> > > I saw it... > May I not comment it? I do not want to look like rude freak... :) rude freaks are not frowned upon here;-> They are loved (ok, maybe some uptight people may have a problem with it;->). But maybe we should keep that thread separate from this. > > Big difference though with CARP. CARP shouldnt need to process > > 100Kpps; but even if it did, CARP packet contain control information > > that is valuable in policy settings. Control protocols tend to be > > "rich" and evolve over much shorter periods of time. > > A better comparison what you are saying is to move OSPF to the kernel. > > Only for now, since we can imagine only some examples now. > When number of agents controlled/connected to CARP will became > significant broadcasting and userspace arbiter's overhead may not > satisfy HA needs. So let me put your fears to rest and share my experiences: I have some experience in using VRRP in a variety of very large, critical and at times very weird senseless setups. This is with some of the most anal telco types you can come across. They protect the network uptime just as if it was a part of their body. I hate to use dirty cliches like "carrier grade" - but it would probably be the closest qualifier; Telcos dont let you mess around their setups and create any holes which will bring down anything for a few seconds. Note, this is with VRRP running in user space. In _every_ case i have been in, i have always been challenged as to why its not in the kernel or running as realtime process. and in all cases, running in user space didnt prove to be the problem. The biggest challenge was fixing broadcast storms because someone created a bcast loop in which case the machine is under DoS attack. The otehr valuable thing to do is to make sure that VRRP packets (as any other control packets) get higher priority in the network. BTW, If you are thinking of instantiating carpd for every agent, then you got to rethink that plan. Hint: You need to handle all carp protocol within one daemon. Maybe thats what you are saying but only to do it in the kernel. Broadcasts: I wasnt sure what you meant. > Control, but it must have possibility to control any dataflow element. > If using all_flows_one_arbiter, then we must have near standing > controller like in-kernel CARP. > If using one_flow_one_arbiter(like tc) then we may use far outstanding > control mechanism and near standing arbiter. > Like qdisk + tc + ucarp. > > The question is: "Do we need to create near standing ariters and far > standing controller for scenatio A, while we may have near standing > controller?". > I do believe that for some situations we just need in-kernel controller > without any overhead and simple in-kernel interface. I think the example of ARP contradicts your view and may apply well here. For small setups, you can use in-kernel ARP. To scale it you move things to arpd in user space. Unfortunately, ARP has always been in the kernel for Linux; so that maybe the reason Alexey never ripped it out totaly. > > We just have better architecture thats all ;-> > > If we want to put as many as possible outside the kernel while it works > better in kernel then we slowly go to meet microkernel and userspace > thread for fs, for network, which will be controlled by broadcast > messages for simplifying control protocol. > > But it is too far planes, so it is just "blah-blah" lyrics now... :) hehe. Tell the guy who wrote openbsd song to make sure he doesnt quit his day job;-> There are a lot of people talking about moving pieces of the net stack to user space. I am not of that religion yet because i havent really seen the value. > BTW, I just reread OpenBSD's load balancing code... > IT is different from that one which may be created with tc and it's > extensions. > > They look into each packet and if it's "signature" is controlled by node > and this node is master than process this packet. > They have one arbiter for any dataflow, while Linux has many arbiters > each of which may be controlled from userspace, that is the difference. I think thats the wrong way to go about it. What you need is enter a simple rule like: filter: If you see ARP asking for our IPs action: Accept filter(installed by carpd): if you see ARP for IP X action: accept .... repeat a few similar ARP rules by carpd for different IPs .. default action: drop all ARPs. This is installed in the datapath before ARP code gets hit. The additional accepts are entered by carpd when it receives CARP packets which describe how to load balance. > So their schema may not be implemented in userspace CARP, while in > Linux it may be implemented using tc extensions with userspace CARP. You could do the above in the kernel. It means everytime i want to make changes i now have to change the kernel. > I will rewrite my resume: > With your approach any data flow MUST go through userspace arbiters with > all overhead and complexity. With my approach any data flow _MAY_ go > through userspace arbiters, but if you do_need/only_has in-kernel access > than using in-kernel CARP is the only solution. Evgeniy, this is the most valuable arguement you have for in-kernel. I suggest drop all the other ones because they are red herrings and lets focus on this one. > My main idea for in-kernel CARP was to implement invisible HA mechanism > suitable for in-kernel use. You do not need to create netlink protocol > parser, you do not need to create extra userspace overhead, you do not > need to create suitable for userspace control hooks in kernel > infrastructure. Just register callback. > But even with such simple approach you have opportunity to collaborate > with userspace. If you need. > > Why creating all userspace cruft if/when you need only kernel one? Because of all the reasons i have mentioned so far ;-> Again, i am not against kernel helpers. I am against putting CARP in the kernel. cheers, jamal From hadi@cyberus.ca Sat Jul 17 09:29:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 09:29:57 -0700 (PDT) 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 i6HGToF8004961 for ; Sat, 17 Jul 2004 09:29:51 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1Bls4J-0002CH-9h for netdev@oss.sgi.com; Sat, 17 Jul 2004 12:29:47 -0400 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 1Bls4G-0003Lp-NM; Sat, 17 Jul 2004 12:29:44 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <20040717180019.7db1473f@zanzibar.2ka.mipt.ru> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> <1089990401.6114.2843.camel@uganda> <1090068454.1064.1258.camel@jzny.localdomain> <20040717180019.7db1473f@zanzibar.2ka.mipt.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1090081781.1063.1346.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Jul 2004 12:29:41 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7034 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, 2004-07-17 at 10:00, Evgeniy Polyakov wrote: > On 17 Jul 2004 08:47:34 -0400 > jamal wrote: > jamal> App2app doesnt have to go across kernel unless it turns out it is > jamal> the best way. > jamal> Alternatives include: unix or local host sockets, IPCs such as > jamal> pipes or > jamal> just shared libraries. > > MICROKERNEL, I see it :) Maybe subconsciouly, but not intentional ;-> > Non broacast/multicast will _strongly_ complicate protocol. > Broadcast will waste apprication/kernel "bandwidth". You could run multicast UDP over localhost; But that will be valuable if you have one-to-many relationship. I guess theres such a relationship between CARPd and other apps. > > jamal> The interesting thing about CARP is the ARP balancing feature in > jamal> which X nodes > jamal> maybe masters of different IP flows all within the > jamal> same subnet. > jamal> VRRP load balances by subnet. I am not sure how > jamal> challenge this will present to > jamal> to ctsyncd. > > CARP may do it, but it requires in-kernel hack into arp code. > Actually OpenBSD's one has it's entry in if_ether.c so their CARP always > has access to any network dataflow. Look at my comment in other email. Pick 2.6.8-rc1 and you could do that in a hearbeat. > BTW, with your approach hack from arp code needs to send a message to > userspace carp to ask if it "good or bad" packet. > Or you need to create tc for arp. carpd gets a policy to tell it what rules to install. It installs them via netlink or tc. Unwanted arp packets get dropped before they ARP code sees them. > Or to communicate with in-kernel CARP. :) > userspace > | > -----------------+------------------------------- > CARP kernelspace > | > | > +----------+-----+-----+---------+------- > | | | | > ct_sync iSCSI e1000 CPU > > > >>My main idea for in-kernel CARP was to implement invisible HA > >>mechanism > >>suitable for in-kernel use. You do not need to create netlink protocol > >>parser, you do not need to create extra userspace overhead, you do not > >>need to create suitable for userspace control hooks in kernel > >>infrastructure. Just register callback. > >>But even with such simple approach you have opportunity to collaborate > >>with userspace. If you need. > > >>Why creating all userspace cruft if/when you need only kernel one? > > jamal> > jamal> so we now move appA, B, C to the kernel too? > jamal> There is absolutely no need to put this in kernel space. > jamal> If you do this, your next step should be to put zebra in the > jamal> kernel > > No. > And this is the beauty of the in-kernel CARP. > You _already_ has in-kernel parts which may need master/slave failover. > > You just need to connect it to arbiter. Sure - such arbitrer could reside in user space too. And apps could connect to it as well. App wishing to listen to mastership changes joins a UDP mcast on localhost. CARPd announces such changes on localhost mcast channel. To make it more interesting, allow apps to query mastership and other state. > With userspace you _need_ to create all those Apps connected to > userspace carp, with in-kernel CARP you need to just register callback. > One function call. Maybe i didnt explain well. Only apps interested in carp activities connect to it; such an app would be ctsyncd. If you use shared libraries, then you register a callback. Or you could use localhost mcast example i gave above. > BTW, someone created tux, khtpd, knfsd :) I thoughth there were people who can beat tux from userspace these days by virtue of numbers. But note again that things like these are datapath level apps unlike CARP. > But i think zebra must live in userspace, since it do not need to > control any kernel parameters. > > CARP _may_ control kernel parameters. > If you do not need in-kernel functionality just use UCARP. I am not sure i follow. You are proposing to do something like arp/arpd now? Look at that code. > jamal> If you prove that it is too expensive to put it in user space > jamal> then prove it and lets > jamal> have a re-discussion > > Hey-ho, easily :) > > Consider embedded processors. > Numbers: ppc405gp, 200mhz, 32mb sdram. > Application - 4-8 DSP processors controlled by ppc. > Each dsp processor generates 6-8 bytes frame with 8khz frequency in > each channel(from 1 to 2). > Driver reads data from each DSP and doing some postprocessing(mainly > split it into B/D channels). Driver has clever mapping so > userspace<->kernelspace dataflow may be zerocopied. Sure. Maybe mmap would suffice. > Kernelspace processing takes up to 133mghz of 200. How did you measure this? > Consider userspace application that > a. makes PCM stereo from different B/D logical channels (zerocopied from > kernelspace). > b. send it into network (using tcp by bad historical/compatibility > reasons). > > Situation: if we have one userspace process(or even thread) per DSP, > than context switching takes too long time and we see data corruption. > None network parameter(100 mb network) can improve situation. > Only one process per 4 DSP may send data into network stack without any > data loss. I am suprised abou the threads being problematic in context switch. > P.S. It is 2.4.25 kernel. I still dont like what you have described above ;-> It needs to be qunatitative instead of qualitative. i.e "heres some numbers when X was done and heres the numbers when Y was done". > I do believe that Peter Chubb (peterc@gelato.unsw.edu.au) will talk > about big machines where big tasks _may_ have big time latencies. > > May Oracle have little latencies? May. But it also _may_ have big > latencies. Why not? > > DSP and sound/video capturing _may_not_ have big latencies. > > Although I do think that talk about userspace drivers is not an issue in > our discussion :) I agree. Let me summarize what i think is the most valuable thing you have said so far - you could disagree, but this is my opinion of what i think the most valuable thing you said : in the model where all things have to cross userspace-kernel boundary, there is some cost associated. This is plausible when such crossings get to be _very_ frequent. _very frequent needs to be quantified. I claim from my experiences (running on small 824x ppc) that the cost is highly exagerated. How about this: Look at the way arp does things and emulate it. The way arp does it is still insufficient because it maintains a threshold first that when exceeded is the only time control packets get sent to user space. You should have a sysctl where your code ships things to user space every time when the systcl is set. This is easy to do if you wrote the whole thing as a tc action instead of a device driver. > Evgeniy Polyakov ( s0mbre ) > > Only failure makes us experts. -- Theo de Raadt To support mr de Raadt above: "repeating failures makes you a sinner" In other words, learn from the failures. cheers, jamal From johnpol@2ka.mipt.ru Sat Jul 17 12:52:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 12:52:37 -0700 (PDT) Received: from ffke-campus-gw.mipt.ru (ffke-campus-gw.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6HJqSBG011445 for ; Sat, 17 Jul 2004 12:52:30 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by ffke-campus-gw.mipt.ru (8.12.11/8.12.11) with SMTP id i6HJqH9g025892; Sat, 17 Jul 2004 23:52:18 +0400 Date: Sun, 18 Jul 2004 00:03:55 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org Subject: Re: [1/2] CARP implementation. HA master's failover. Message-Id: <20040718000355.52e1ac02@zanzibar.2ka.mipt.ru> In-Reply-To: <1090081781.1063.1346.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> <1089990401.6114.2843.camel@uganda> <1090068454.1064.1258.camel@jzny.localdomain> <20040717180019.7db1473f@zanzibar.2ka.mipt.ru> <1090081781.1063.1346.camel@jzny.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7035 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On 17 Jul 2004 12:29:41 -0400 jamal wrote: > > jamal> The interesting thing about CARP is the ARP balancing feature > > in jamal> which X nodes > > jamal> maybe masters of different IP flows all within the > > jamal> same subnet. > > jamal> VRRP load balances by subnet. I am not sure how > > jamal> challenge this will present to > > jamal> to ctsyncd. > > > > CARP may do it, but it requires in-kernel hack into arp code. > > Actually OpenBSD's one has it's entry in if_ether.c so their CARP > > always has access to any network dataflow. > > Look at my comment in other email. Pick 2.6.8-rc1 and you could do > that in a hearbeat. Sure. It is an example where kernel helper already exists. And it is similar to other networ arbiters - iptables, tc... > > BTW, with your approach hack from arp code needs to send a message > > to userspace carp to ask if it "good or bad" packet. > > Or you need to create tc for arp. > > carpd gets a policy to tell it what rules to install. > It installs them via netlink or tc. > Unwanted arp packets get dropped before they ARP code sees them. Only because they already exist, it is easy. I do not argue against it. Some situations may be easily controlled from the userspace, but not all. And for those we need in-kernel solution - it may be kernel helper plus userspace arbiter, but may just kernel callback. > > jamal> so we now move appA, B, C to the kernel too? > > jamal> There is absolutely no need to put this in kernel space. > > jamal> If you do this, your next step should be to put zebra in the > > jamal> kernel > > > > No. > > And this is the beauty of the in-kernel CARP. > > You _already_ has in-kernel parts which may need master/slave > > failover. > > > > You just need to connect it to arbiter. > > Sure - such arbitrer could reside in user space too. > And apps could connect to it as well. > App wishing to listen to mastership changes joins a UDP mcast on > localhost. CARPd announces such changes on localhost mcast channel. > To make it more interesting, allow apps to query mastership and > other state. But why do you want to create this extra application when you already have possibility to control it? Why does someone need to create userspace application, kernel helper for it, when it is only requres in-kernel access? > > With userspace you _need_ to create all those Apps connected to > > userspace carp, with in-kernel CARP you need to just register > > callback. One function call. > > Maybe i didnt explain well. Only apps interested in carp activities > connect to it; such an app would be ctsyncd. If you use shared > libraries, then you register a callback. Or you could use localhost > mcast example i gave above. I absolutely agree with you. All your arguments are just right. But whole you approach is not good for _any_ situation. > > BTW, someone created tux, khtpd, knfsd :) > > I thoughth there were people who can beat tux from userspace these > days by virtue of numbers. But note again that things like these are > datapath level apps unlike CARP. Sure, it is just example that if something is good for something, then no reason exist to move it around. Userspace is good, but not for all. > > But i think zebra must live in userspace, since it do not need to > > control any kernel parameters. > > > > CARP _may_ control kernel parameters. > > If you do not need in-kernel functionality just use UCARP. > > I am not sure i follow. You are proposing to do something like > arp/arpd now? Look at that code. It is good for arp, that we can control it from userspace. But I do not see any good reaon to control everething from userspace. > > jamal> If you prove that it is too expensive to put it in user space > > jamal> then prove it and lets > > jamal> have a re-discussion > > > > Hey-ho, easily :) > > > > Consider embedded processors. > > Numbers: ppc405gp, 200mhz, 32mb sdram. > > Application - 4-8 DSP processors controlled by ppc. > > Each dsp processor generates 6-8 bytes frame with 8khz frequency in > > each channel(from 1 to 2). > > Driver reads data from each DSP and doing some postprocessing(mainly > > split it into B/D channels). Driver has clever mapping so > > userspace<->kernelspace dataflow may be zerocopied. > > Sure. Maybe mmap would suffice. > > > Kernelspace processing takes up to 133mghz of 200. > > How did you measure this? get_cycles() is my friend. About 70mghz for DSP reading and the same for postprocessing. > > Consider userspace application that > > a. makes PCM stereo from different B/D logical channels (zerocopied > > from kernelspace). > > b. send it into network (using tcp by bad historical/compatibility > > reasons). > > > > Situation: if we have one userspace process(or even thread) per DSP, > > than context switching takes too long time and we see data > > corruption. None network parameter(100 mb network) can improve > > situation. Only one process per 4 DSP may send data into network > > stack without any data loss. > > I am suprised abou the threads being problematic in context switch. Me too, probably they will survive for less threads, not tested. The maximum configuration has 16 digital channels with 8bytes in 8khz each. 16 threads can not handle this. btw, i lie, it has 2 processes already plus threads or additional processes. > > P.S. It is 2.4.25 kernel. > > I still dont like what you have described above ;-> It needs to be > qunatitative instead of qualitative. i.e "heres some numbers when X > was done and heres the numbers when Y was done". Hmmm... It works if we have little number of context switches and does not work otherwise in above configuration. Almost what you asked :) > > I do believe that Peter Chubb (peterc@gelato.unsw.edu.au) will talk > > about big machines where big tasks _may_ have big time latencies. > > > > May Oracle have little latencies? May. But it also _may_ have big > > latencies. Why not? > > > > DSP and sound/video capturing _may_not_ have big latencies. > > > > Although I do think that talk about userspace drivers is not an > > issue in our discussion :) > > > I agree. Let me summarize what i think is the most valuable thing you > have said so far - you could disagree, but this is my opinion of what > i think the most valuable thing you said : > > in the model where all things have to cross userspace-kernel boundary, > there is some cost associated. This is plausible when such crossings > get to be _very_ frequent. _very frequent needs to be quantified. > I claim from my experiences (running on small 824x ppc) that the cost > is highly exagerated. > How about this: Look at the way arp does things and emulate it. > The way arp does it is still insufficient because it maintains a > threshold first that when exceeded is the only time control packets > get sent to user space. > You should have a sysctl where your code ships things to user space > every time when the systcl is set. > This is easy to do if you wrote the whole thing as a tc action instead > of a device driver. Sure. I totally agree. And I agree with your solution. It is right for almost all situation. But if you do not need userspace arbiter and kernel helper, you do not need to create it. ust use in-ernel solution. > > > Evgeniy Polyakov ( s0mbre ) > > > > Only failure makes us experts. -- Theo de Raadt > > To support mr de Raadt above: > > "repeating failures makes you a sinner" > In other words, learn from the failures. Or sinner just can not learn :) Thank you for interesting discussion, I think we see each one's position, we see it's advantages and disadvantages, but we have just a bit different vews :) With best regards. > > cheers, > jamal > Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From johnpol@2ka.mipt.ru Sat Jul 17 12:52:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 12:52:45 -0700 (PDT) Received: from ffke-campus-gw.mipt.ru (ffke-campus-gw.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6HJqagN011453 for ; Sat, 17 Jul 2004 12:52:39 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by ffke-campus-gw.mipt.ru (8.12.11/8.12.11) with SMTP id i6HJqWXh026065; Sat, 17 Jul 2004 23:52:32 +0400 Date: Sun, 18 Jul 2004 00:04:11 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org Subject: Re: [1/2] CARP implementation. HA master's failover. Message-Id: <20040718000411.0a5ae938@zanzibar.2ka.mipt.ru> In-Reply-To: <1090079263.1063.1303.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089906936.6114.904.camel@uganda> <1089908900.1027.77.camel@jzny.localdomain> <1089910757.6114.965.camel@uganda> <1089912658.1029.101.camel@jzny.localdomain> <20040715232035.37e016ef@zanzibar.2ka.mipt.ru> <1089981282.1060.1293.camel@jzny.localdomain> <1089990384.6114.2842.camel@uganda> <1090065129.1066.1196.camel@jzny.localdomain> <20040717165942.1e7f847f@zanzibar.2ka.mipt.ru> <1090079263.1063.1303.camel@jzny.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7036 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On 17 Jul 2004 11:47:43 -0400 jamal wrote: > On Sat, 2004-07-17 at 08:59, Evgeniy Polyakov wrote: > > On 17 Jul 2004 07:52:09 -0400 > > jamal wrote: > > > > BTW, theres a very nice paper being presented at OLS by someone > > > from.au who is trying infact to move drivers to user space ;-> > > > > I saw it... > > May I not comment it? I do not want to look like rude freak... :) > > rude freaks are not frowned upon here;-> They are loved (ok, maybe > some uptight people may have a problem with it;->). > But maybe we should keep that thread separate from this. :) Sure. > > > Big difference though with CARP. CARP shouldnt need to process > > > 100Kpps; but even if it did, CARP packet contain control > > > information that is valuable in policy settings. Control protocols > > > tend to be"rich" and evolve over much shorter periods of time. > > > A better comparison what you are saying is to move OSPF to the > > > kernel. > > > > Only for now, since we can imagine only some examples now. > > When number of agents controlled/connected to CARP will became > > significant broadcasting and userspace arbiter's overhead may not > > satisfy HA needs. > > So let me put your fears to rest and share my experiences: > I have some experience in using VRRP in a variety of very large, > critical and at times very weird senseless setups. This is with some > of the most anal telco types you can come across. They protect the > network uptime just as if it was a part of their body. I hate to use > dirty cliches like "carrier grade" - but it would probably be the > closest qualifier; Telcos dont let you mess around their setups and > create any holes which will bring down anything for a few seconds. > Note, this is with VRRP running in user space. In _every_ case i have > been in, i have always been challenged as to why its not in the kernel > or running as realtime process. and in all cases, running in user > space didnt prove to be the problem. The biggest challenge was fixing > broadcast storms because someone created a bcast loop in which case > the machine is under DoS attack. The otehr valuable thing to do is to > make sure that VRRP packets (as any other control packets) get higher > priority in the network. > > BTW, If you are thinking of instantiating carpd for every agent, then > you got to rethink that plan. Hint: You need to handle all carp > protocol within one daemon. Maybe thats what you are saying but only > to do it in the kernel. > > Broadcasts: I wasnt sure what you meant. Netlink broadcast... I absolutely agree with you, that userspace heartbeat application may satisfy most of current needs. But if you need kernel access you need to create not only kernel part, but also some userspace controlling application. So we will have carpd, which controls userspace application which in turn control kernel parts. Maybe it is solution, but sometimes better just to use existing kernel part with privided in-kernel carp. Your position is that any control arbiter must live in userspace, but I offer in-kernel solution for those who needs only in-kernel access. > > Control, but it must have possibility to control any dataflow > > element. If using all_flows_one_arbiter, then we must have near > > standing controller like in-kernel CARP. > > If using one_flow_one_arbiter(like tc) then we may use far > > outstanding control mechanism and near standing arbiter. > > Like qdisk + tc + ucarp. > > > > The question is: "Do we need to create near standing ariters and far > > standing controller for scenatio A, while we may have near standing > > controller?". > > I do believe that for some situations we just need in-kernel > > controller without any overhead and simple in-kernel interface. > > I think the example of ARP contradicts your view and may apply well > here. For small setups, you can use in-kernel ARP. > To scale it you move things to arpd in user space. Unfortunately, ARP > has always been in the kernel for Linux; so that maybe the reason > Alexey never ripped it out totaly. Yep, it is good example. But this medal has another side: linux handles all network traffik only in one processor in a time. Consider userspace process that binds to receiving interface or some address or even skb, and such processes may be processed in parallel, amy have prioritisation and so forth... Ridiculous example, i know, and absolutely exaggerated but moving from kernel to userspace not always good idea. Even if it is not dataflow and just rare control. > > BTW, I just reread OpenBSD's load balancing code... > > IT is different from that one which may be created with tc and it's > > extensions. > > > > They look into each packet and if it's "signature" is controlled by > > node and this node is master than process this packet. > > They have one arbiter for any dataflow, while Linux has many > > arbiters each of which may be controlled from userspace, that is the > > difference. > > I think thats the wrong way to go about it. > What you need is enter a simple rule like: > > filter: If you see ARP asking for our IPs > action: Accept > filter(installed by carpd): if you see ARP for IP X > action: accept > .... repeat a few similar ARP rules by carpd for different IPs .. > default action: drop all ARPs. > > This is installed in the datapath before ARP code gets hit. > The additional accepts are entered by carpd when it receives CARP > packets which describe how to load balance. Sure. It is do correct way of doing this. But we just lucky guys and can control this dataflow in such way. Not everithing may be fitted for such scenario. > > So their schema may not be implemented in userspace CARP, while in > > Linux it may be implemented using tc extensions with userspace CARP. > > You could do the above in the kernel. It means everytime i want to > make changes i now have to change the kernel. > > > I will rewrite my resume: > > With your approach any data flow MUST go through userspace arbiters > > with all overhead and complexity. With my approach any data flow > > _MAY_ go through userspace arbiters, but if you do_need/only_has > > in-kernel access than using in-kernel CARP is the only solution. > > Evgeniy, this is the most valuable arguement you have for in-kernel. I > suggest drop all the other ones because they are red herrings and lets > focus on this one. > > > My main idea for in-kernel CARP was to implement invisible HA > > mechanism suitable for in-kernel use. You do not need to create > > netlink protocol parser, you do not need to create extra userspace > > overhead, you do not need to create suitable for userspace control > > hooks in kernel infrastructure. Just register callback. > > But even with such simple approach you have opportunity to > > collaborate with userspace. If you need. > > > > Why creating all userspace cruft if/when you need only kernel one? > > Because of all the reasons i have mentioned so far ;-> > Again, i am not against kernel helpers. I am against putting CARP in > the kernel. Okey. I will summarize our views: on one side we have in-kernel solution which may control any process there, which may be used for in-kernel access. On the other side we have userspace solution which requres kernel helpers. One do may use any, question is, does concrete situation requires userspace control? If no, the using in-kernel solution if preferable. You think that any in-kernel access must have userspace arbiter, but i do think that in some situation we do not need it. For such situations you do not need to create kernel helper and userspace controller, only in-kernel carp. > cheers, > jamal > Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From hadi@cyberus.ca Sat Jul 17 13:32:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jul 2004 13:32:35 -0700 (PDT) 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 i6HKWQOK012636 for ; Sat, 17 Jul 2004 13:32:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1Blvr6-0004nk-3B for netdev@oss.sgi.com; Sat, 17 Jul 2004 16:32:24 -0400 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 1Blvr3-0005RG-Aj; Sat, 17 Jul 2004 16:32:21 -0400 Subject: Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com, netfilter-failover@lists.netfilter.org In-Reply-To: <20040718000355.52e1ac02@zanzibar.2ka.mipt.ru> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> <1089990401.6114.2843.camel@uganda> <1090068454.1064.1258.camel@jzny.localdomain> <20040717180019.7db1473f@zanzibar.2ka.mipt.ru> <1090081781.1063.1346.camel@jzny.localdomain> <20040718000355.52e1ac02@zanzibar.2ka.mipt.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1090096337.1064.1365.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Jul 2004 16:32:17 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7037 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, 2004-07-17 at 16:03, Evgeniy Polyakov wrote: > Thank you for interesting discussion, I think we see each one's > position, we see it's advantages and disadvantages, but we have just a > bit different vews :) Indeed. I would say we have agreed to disagree ;-> [Maybe at some point when i get excited about CARP you will see alternative (user space based) code. I am hoping someone else (Like Alexander Cassen) would beat me to it.] cheers, jamal From cspalletta@yahoo.com Sun Jul 18 12:48:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jul 2004 12:48:40 -0700 (PDT) Received: from web53805.mail.yahoo.com (web53805.mail.yahoo.com [206.190.36.200]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6IJmWdL030575 for ; Sun, 18 Jul 2004 12:48:33 -0700 Message-ID: <20040718194826.6164.qmail@web53805.mail.yahoo.com> Received: from [63.226.217.245] by web53805.mail.yahoo.com via HTTP; Sun, 18 Jul 2004 12:48:26 PDT Date: Sun, 18 Jul 2004 12:48:26 -0700 (PDT) From: Carl Spalletta Subject: [PATCH] Remove prototypes of nonexistent functions from net/sctp files To: lkml Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7038 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cspalletta@yahoo.com Precedence: bulk X-list: netdev diff -ru linux-2.6.7-orig/net/sctp/socket.c linux-2.6.7-new/net/sctp/socket.c --- linux-2.6.7-orig/net/sctp/socket.c 2004-06-15 22:20:26.000000000 -0700 +++ linux-2.6.7-new/net/sctp/socket.c 2004-07-18 08:54:08.000000000 -0700 @@ -109,7 +109,6 @@ static char *sctp_hmac_alg = SCTP_COOKIE_HMAC_ALG; extern kmem_cache_t *sctp_bucket_cachep; -extern int sctp_assoc_valid(struct sock *sk, struct sctp_association *asoc); /* Look up the association by its id. If this is not a UDP-style * socket, the ID field is always ignored. From cspalletta@yahoo.com Sun Jul 18 12:50:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jul 2004 12:50:45 -0700 (PDT) Received: from web53801.mail.yahoo.com (web53801.mail.yahoo.com [206.190.36.196]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6IJobtB030675 for ; Sun, 18 Jul 2004 12:50:38 -0700 Message-ID: <20040718195030.32683.qmail@web53801.mail.yahoo.com> Received: from [63.226.217.245] by web53801.mail.yahoo.com via HTTP; Sun, 18 Jul 2004 12:50:30 PDT Date: Sun, 18 Jul 2004 12:50:30 -0700 (PDT) From: Carl Spalletta Subject: [PATCH] Remove prototypes of nonexistent functions from net/atm files To: lkml Cc: netdev@oss.sgi.com, chas@cmf.nrl.navy.mil MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7039 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cspalletta@yahoo.com Precedence: bulk X-list: netdev diff -ru linux-2.6.7-orig/net/atm/common.h linux-2.6.7-new/net/atm/common.h --- linux-2.6.7-orig/net/atm/common.h 2004-06-15 22:19:43.000000000 -0700 +++ linux-2.6.7-new/net/atm/common.h 2004-07-18 08:52:50.000000000 -0700 @@ -24,11 +24,6 @@ int vcc_getsockopt(struct socket *sock, int level, int optname, char __user *optval, int __user *optlen); -void atm_shutdown_dev(struct atm_dev *dev); - -void pppoatm_ioctl_set(int (*hook)(struct atm_vcc *, unsigned int, unsigned long)); -void br2684_ioctl_set(int (*hook)(struct atm_vcc *, unsigned int, unsigned long)); - int atmpvc_init(void); void atmpvc_exit(void); int atmsvc_init(void); @@ -50,12 +45,6 @@ #endif /* CONFIG_PROC_FS */ /* SVC */ - -void svc_callback(struct atm_vcc *vcc); int svc_change_qos(struct atm_vcc *vcc,struct atm_qos *qos); -/* p2mp */ - -int create_leaf(struct socket *leaf,struct socket *session); - #endif diff -ru linux-2.6.7-orig/net/atm/lec.h linux-2.6.7-new/net/atm/lec.h --- linux-2.6.7-orig/net/atm/lec.h 2004-06-15 22:19:10.000000000 -0700 +++ linux-2.6.7-new/net/atm/lec.h 2004-07-18 08:50:35.000000000 -0700 @@ -151,7 +151,6 @@ int lec_vcc_attach(struct atm_vcc *vcc, void __user *arg); int lec_mcast_attach(struct atm_vcc *vcc, int arg); struct net_device *get_dev_lec(int itf); -int make_lec(struct atm_vcc *vcc); int send_to_lecd(struct lec_priv *priv, atmlec_msg_type type, unsigned char *mac_addr, unsigned char *atm_addr, struct sk_buff *data); From hidden@balabit.hu Mon Jul 19 00:16:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 00:16:19 -0700 (PDT) Received: from balabit.hu (catv-5062fad2.catv.broadband.hu [80.98.250.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6J7GB8J019987 for ; Mon, 19 Jul 2004 00:16:12 -0700 Subject: Re: [nf-failover] Re: [1/2] CARP implementation. HA master's failover. From: KOVACS Krisztian To: hadi@cyberus.ca Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com, Netfilter-failover list In-Reply-To: <1089983064.1060.1328.camel@jzny.localdomain> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-2 Message-Id: <1090221367.2551.27.camel@nienna.balabit> Mime-Version: 1.0 Date: Mon, 19 Jul 2004 09:16:07 +0200 Content-Transfer-Encoding: 8bit X-archive-position: 7040 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hidden@balabit.hu Precedence: bulk X-list: netdev Hi, 2004-07-16, p keltezéssel 15:04-kor jamal ezt írta: > Looking at what HArald has, the infrastructure seems to be the correct > flavor. Seems something gets sent to user space via netlink and gets > delivered via keepalived. Unfortunately this is not the case, as Evgeniy already mentioned. ct_sync is currently an completely in-kernel solution, with all the pros and cons of that. (Yes, it could be done in userspace with some minimal kernel code, and yes, it had a few advantages over the current solution. However, the kernel-side "agent" code would still be quite heavy-weight. Unfortunately Netfilter's conntrack subsystem is a more complicated than that of OpenBSD's pf. And the current code is not designed that way, so I think it would be better to first try to finish the current project, and then think about what should be done in a completely different way.) > I think the CARP loadbalancing feature is an improvement over what is > being suggested by Harald. What do you mean by that? Of course, it is a serious weakness of the current code that it is not capable of load balancing, only failover with passive slaves. However, load balancing would probably make things a lot more complicated. For example, see NAT-related problems described by Lennert Buytenhek here: http://lists.netfilter.org/pipermail/netfilter-failover/2001-September/000043.html > I have to say as well i am shocked that state is just being transfered > blindly - but i will deal with Harald when he shows up in Ottawa ;-> Would it be possible to summarize your ideas here? Yes, I know it is easier and faster to talk about those things in person, but unfortunately I won't be there in Ottawa, but am of course seriously interested in all ideas related to ct_sync... -- Regards, Krisztian KOVACS From mroos@linux.ee Mon Jul 19 02:44:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 02:44:41 -0700 (PDT) Received: from math.ut.ee (root@math.ut.ee [193.40.5.125]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6J9iW3q028679 for ; Mon, 19 Jul 2004 02:44:34 -0700 Received: from math.ut.ee (mroos@localhost [IPv6:::1]) by math.ut.ee (8.12.8+Sun/8.12.8/math-1.2) with ESMTP id i6J9iTRq024900 for ; Mon, 19 Jul 2004 12:44:29 +0300 (EEST) Received: from localhost (mroos@localhost) by math.ut.ee (8.12.8+Sun/8.12.2/Submit) with ESMTP id i6J9iScL024894 for ; Mon, 19 Jul 2004 12:44:28 +0300 (EEST) X-Authentication-Warning: math.ut.ee: mroos owned process doing -bs Date: Mon, 19 Jul 2004 12:44:28 +0300 (EEST) From: Meelis Roos To: netdev@oss.sgi.com Subject: netem compile failure on PPC (2.4 BK) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7041 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev netem fails to compile on PPC in 2.4.27+BK, __init etc are unknown. The patch below fixes it for me. gcc -D__KERNEL__ -I/home/mroos/compile/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/home/mroos/compile/linux-2.4/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -DMODULE -DMODVERSIONS -include /home/mroos/compile/linux-2.4/include/linux/modversions.h -nostdinc -iwithprefix include -DKBUILD_BASENAME=sch_netem -c -o sch_netem.o sch_netem.c sch_netem.c:245: error: parse error before "netem_module_init" sch_netem.c:246: warning: return type defaults to `int' sch_netem.c:249: error: parse error before "netem_module_exit" sch_netem.c:250: warning: return type defaults to `int' sch_netem.c:254: error: parse error before "module_exit" sch_netem.c:255: warning: return type defaults to `int' sch_netem.c:255: warning: function declaration isn't a prototype sch_netem.c: In function `module_exit': sch_netem.c:255: error: storage class specified for parameter `__module_license' sch_netem.c:255: error: parameter `__module_license' is initialized sch_netem.c:255: warning: `__used__' attribute ignored sch_netem.c:255: error: section attribute not allowed for `__module_license' sch_netem.c:255: error: parse error at end of input ===== net/sched/sch_netem.c 1.2 vs edited ===== --- 1.2/net/sched/sch_netem.c 2004-07-07 00:38:40 +03:00 +++ edited/net/sched/sch_netem.c 2004-07-19 12:32:27 +03:00 @@ -19,6 +19,7 @@ #include #include #include +#include #include -- Meelis Roos (mroos@linux.ee) From piggy@timesys.com Mon Jul 19 07:14:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 07:14:35 -0700 (PDT) Received: from kartuli.timesys (host-65-117-135-105.timesys.com [65.117.135.105] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6JEENSm008939 for ; Mon, 19 Jul 2004 07:14:24 -0700 Received: from timesys.com (tsqali.timesys [192.168.2.47]) by kartuli.timesys (8.12.5/8.12.5) with ESMTP id i6JEEB0k007861; Mon, 19 Jul 2004 10:14:11 -0400 Message-ID: <40FBD734.5040306@timesys.com> Date: Mon, 19 Jul 2004 10:14:12 -0400 From: "La Monte H.P. Yarroll" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Sridhar Samudrala CC: Carl Spalletta , lkml , netdev@oss.sgi.com, ML lksctp Subject: Re: [PATCH] Remove prototypes of nonexistent functions from net/sctp files References: <20040718194826.6164.qmail@web53805.mail.yahoo.com> In-Reply-To: <20040718194826.6164.qmail@web53805.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7042 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: piggy@timesys.com Precedence: bulk X-list: netdev This function went away in Februrary (change 1.67 on associola.c) due to changing the assoc id from a kernel address to an abstract address. The check is now done by looking at a single field in the association struct. Signed-off-by: La Monte H.P. Yarroll Carl Spalletta wrote: >diff -ru linux-2.6.7-orig/net/sctp/socket.c linux-2.6.7-new/net/sctp/socket.c >--- linux-2.6.7-orig/net/sctp/socket.c 2004-06-15 22:20:26.000000000 -0700 >+++ linux-2.6.7-new/net/sctp/socket.c 2004-07-18 08:54:08.000000000 -0700 >@@ -109,7 +109,6 @@ > static char *sctp_hmac_alg = SCTP_COOKIE_HMAC_ALG; > > extern kmem_cache_t *sctp_bucket_cachep; >-extern int sctp_assoc_valid(struct sock *sk, struct sctp_association *asoc); > > /* Look up the association by its id. If this is not a UDP-style > * socket, the ID field is always ignored. > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig From chas@cmf.nrl.navy.mil Mon Jul 19 14:36:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 14:36:19 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6JLaDqm029366 for ; Mon, 19 Jul 2004 14:36:14 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i6JLa4QO028602; Mon, 19 Jul 2004 17:36:04 -0400 (EDT) Message-Id: <200407192136.i6JLa4QO028602@ginger.cmf.nrl.navy.mil> To: davem@redhat.com Cc: netdev@oss.sgi.com, Stephen Hemminger Subject: Re: [PATCH] br2684 - use try_module_get appropriately In-Reply-To: Message from Stephen Hemminger of "Mon, 28 Jun 2004 09:33:17 PDT." <20040628093317.218220fe@dell_ss3.pdx.osdl.net> Date: Mon, 19 Jul 2004 17:36:05 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 7043 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev In message <20040628093317.218220fe@dell_ss3.pdx.osdl.net>,Stephen Hemminger wr ites: >Either way, just an (void) try_module_get() is WRONG. dave, please apply to 2.6 --thanks # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1819 -> 1.1820 # net/atm/pppoatm.c 1.12 -> 1.13 # net/atm/br2684.c 1.12 -> 1.13 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/07/19 chas@relax.cmf.nrl.navy.mil 1.1820 # [ATM]: use try_module_get appropriately (from Stephen Hemminger ) # -------------------------------------------- # diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c --- a/net/atm/br2684.c Mon Jul 19 17:33:00 2004 +++ b/net/atm/br2684.c Mon Jul 19 17:33:00 2004 @@ -563,7 +563,7 @@ BRPRIV(skb->dev)->stats.rx_packets--; br2684_push(atmvcc, skb); } - (void) try_module_get(THIS_MODULE); + __module_get(THIS_MODULE); return 0; error: write_unlock_irq(&devs_lock); diff -Nru a/net/atm/pppoatm.c b/net/atm/pppoatm.c --- a/net/atm/pppoatm.c Mon Jul 19 17:33:00 2004 +++ b/net/atm/pppoatm.c Mon Jul 19 17:33:00 2004 @@ -307,7 +307,7 @@ atmvcc->user_back = pvcc; atmvcc->push = pppoatm_push; atmvcc->pop = pppoatm_pop; - (void) try_module_get(THIS_MODULE); + __module_get(THIS_MODULE); return 0; } From afleming@freescale.com Mon Jul 19 16:30:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 16:30:10 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6JNU3lA006014 for ; Mon, 19 Jul 2004 16:30:04 -0700 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i6JNToxU029421; Mon, 19 Jul 2004 16:29:50 -0700 (MST) Received: from [10.82.16.241] ([10.82.16.241]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i6JLTiZk028752; Mon, 19 Jul 2004 16:29:44 -0500 In-Reply-To: <40F4A6E5.4060000@pobox.com> References: <2A724364-D53A-11D8-8835-000393C30512@freescale.com> <40F4A6E5.4060000@pobox.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <85DC52B0-D9DB-11D8-AE55-000393C30512@freescale.com> Content-Transfer-Encoding: 7bit Cc: Andy Fleming , , Kumar Gala , , From: Andy Fleming Subject: Re: [RFR] gianfar ethernet driver Date: Mon, 19 Jul 2004 18:29:47 -0500 To: Jeff Garzik X-Mailer: Apple Mail (2.618) X-archive-position: 7044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On Jul 13, 2004, at 22:22, Jeff Garzik wrote: > Andy Fleming wrote: >> Ok, I've got the new PHY code working, and I've done most of the >> changes, but I have a couple more questions: >>>> >>>> 6) sysfs support: call SET_NETDEV_DEV() >> Ok, the first argument should be dev, but what should the second >> argument be? This isn't a PCI device, it's >> an on-chip peripheral, so I'm not sure what the class_device should >> be. > > It's a struct device, which all devices need to have. > > I could have sworn OCP does struct device these days. If not, poke > the platform people. Ah, I found it. ocpdev->dev. Done. > > >>>> 19) I think your gfar_poll() needs spin_lock_irqsave(), not >>>> spin_lock(). >> Hmm... I tried that, but netif_receive_skb() will eventually call >> local_bh_enable(), which dislikes my disabling interrupts. I could >> avoid this by unlocking around netif_receive_skb(), but this solution >> seems ugly to me. What is the preferred way of doing this? > > Duh. I had a brainfart. > > RX "synchronization" is normally done by simply ensuring that no other > code will cause a NAPI poll. You shouldn't need spinlocks around that > section of code at all. Take a look at drivers/net/tg3.c, tg3_rx() Ok. I will send a new patch tomorrow. > > Jeff From SRS0+f2352bb9422016a9ebaf+331+infradead.org+dwmw2@pentafluge.srs.infradead.org Mon Jul 19 18:14:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 18:14:46 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6K1Ee5N009201 for ; Mon, 19 Jul 2004 18:14:41 -0700 Received: from [216.208.38.106] (helo=[192.168.99.116]) by pentafluge.infradead.org with asmtp (Exim 4.33 #1 (Red Hat Linux)) id 1BmjD7-0002O7-J8; Tue, 20 Jul 2004 02:14:26 +0100 Subject: Re: [RFR] gianfar ethernet driver From: David Woodhouse To: Andy Fleming Cc: Jeff Garzik , Andy Fleming , netdev@oss.sgi.com, Kumar Gala , hadi@cyberus.ca, rmk@arm.linux.org.uk, benh@kernel.crashing.org In-Reply-To: <85DC52B0-D9DB-11D8-AE55-000393C30512@freescale.com> References: <2A724364-D53A-11D8-8835-000393C30512@freescale.com> <40F4A6E5.4060000@pobox.com> <85DC52B0-D9DB-11D8-AE55-000393C30512@freescale.com> Content-Type: text/plain Date: Mon, 19 Jul 2004 21:13:29 -0400 Message-Id: <1090286009.4149.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.8 (1.5.8-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7045 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev On Mon, 2004-07-19 at 18:29 -0500, Andy Fleming wrote: > > I could have sworn OCP does struct device these days. If not, poke > > the platform people. > > Ah, I found it. ocpdev->dev. Done. So we have BenH talking about pre-populating sysfs with objects for all the on-chip peripherals and metadata like MAC addresses. We have some PPC platforms using 'OCP' which does much the same thing, and ARM platforms using yet another implementation. Some drivers support more than one of these. I suspect we need to bash some heads together... :) -- dwmw2 From uucp@ganesha.gnumonks.org Mon Jul 19 20:58:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 20:58:35 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6K3wRB2018778 for ; Mon, 19 Jul 2004 20:58:27 -0700 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.30) id 1Bmllo-0001P9-9j for netdev@oss.sgi.com; Tue, 20 Jul 2004 05:58:24 +0200 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1BmkfN-0008Qc-00; Mon, 19 Jul 2004 22:47:41 -0400 Date: Mon, 19 Jul 2004 22:47:41 -0400 From: Harald Welte To: Sebastien ESTIENNE Cc: linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: kernel 2.6.7 -> page allocation failure. order:1, mode:0x20 (netfilter?) Message-ID: <20040720024741.GF27487@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , Sebastien ESTIENNE , linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com References: <40FB93FE.90308@ovibes.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="phCU5ROyZO6kBE05" Content-Disposition: inline In-Reply-To: <40FB93FE.90308@ovibes.net> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.8-rc1-qs X-Date: Today is Setting Orange, the 54th day of Confusion in the YOLD 3170 User-Agent: Mutt/1.5.6+20040523i X-archive-position: 7046 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --phCU5ROyZO6kBE05 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 19, 2004 at 11:27:26AM +0200, Sebastien ESTIENNE wrote: > Hello, > i have some "swapper: page allocation failure. order:1, mode:0x20" > followed by kernel message, >=20 > the hardware is a dell poweredge 1750 > the kernel is a 2.6.7 vanilla >=20 > here for a dmesg > http://213.41.75.25/kernel/dmesg.txt the chunk below seems like a standard code path for a locally-generated outgoing packet: > [] skb_checksum_help+0x52/0x136 > [] ip_nat_fn+0x269/0x27a [iptable_nat] > [] ip_nat_local_fn+0x7b/0xaa [iptable_nat] > [] tcp_sendmsg+0x509/0x10f7 > [] tasklet_action+0x65/0xae > [] apic_timer_interrupt+0x1a/0x20 > [] dst_output+0x0/0x29 > [] inet_sendmsg+0x4d/0x59 > [] dst_output+0x0/0x29 > [] sock_aio_write+0xbd/0xdd > [] do_sync_write+0x8b/0xb7 > [] nf_iterate+0x71/0xa2 > [] copy_from_user+0x42/0x6e > [] vfs_write+0xe8/0x119 > [] sys_write+0x42/0x63 > [] syscall_call+0x7/0xb =20 what's worrying me is the part above... how would skb_checksum_help directly end up in copy_from_user()? > swapper: page allocation failure. order:1, mode:0x20 > [] __alloc_pages+0x2da/0x34a > [] __get_free_pages+0x25/0x3f > [] kmem_getpages+0x2b/0xdc > [] kfree_skbmem+0x24/0x2c > [] cache_grow+0xe5/0x2a4 > [] cache_grow+0x146/0x2a4 > [] cache_alloc_refill+0x1cf/0x29f > [] __kmalloc+0x85/0x8c > [] tcp_transmit_skb+0x411/0x68a > [] alloc_skb+0x47/0xe0 > [] tcp_write_xmit+0x16d/0x2d6 > [] skb_copy+0x33/0xde > [] copy_from_user+0x42/0x6e Does anybody have a clue what's going on? --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --phCU5ROyZO6kBE05 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/IfNXaXGVTD0i/8RAiv4AJ0d3Gv+nUtbZvnlod7DNVqSXgAZVQCfYEo0 IReZ37a9XbULaBQQb0L4+m4= =qpTK -----END PGP SIGNATURE----- --phCU5ROyZO6kBE05-- From uucp@ganesha.gnumonks.org Mon Jul 19 20:58:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jul 2004 20:58:35 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6K3wRMi018777 for ; Mon, 19 Jul 2004 20:58:27 -0700 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.30) id 1Bmllo-0001Ot-3S for netdev@oss.sgi.com; Tue, 20 Jul 2004 05:58:24 +0200 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1BmkWg-0008PB-00; Mon, 19 Jul 2004 22:38:42 -0400 Date: Mon, 19 Jul 2004 22:38:42 -0400 From: Harald Welte To: KOVACS Krisztian Cc: hadi@cyberus.ca, johnpol@2ka.mipt.ru, netdev@oss.sgi.com, Netfilter-failover list Subject: Re: [nf-failover] Re: [1/2] CARP implementation. HA master's failover. Message-ID: <20040720023842.GE27487@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , KOVACS Krisztian , hadi@cyberus.ca, johnpol@2ka.mipt.ru, netdev@oss.sgi.com, Netfilter-failover list References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> <1090221367.2551.27.camel@nienna.balabit> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6WlEvdN9Dv0WHSBl" Content-Disposition: inline In-Reply-To: <1090221367.2551.27.camel@nienna.balabit> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.8-rc1-qs X-Date: Today is Setting Orange, the 54th day of Confusion in the YOLD 3170 User-Agent: Mutt/1.5.6+20040523i X-archive-position: 7047 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --6WlEvdN9Dv0WHSBl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 19, 2004 at 09:16:07AM +0200, KOVACS Krisztian wrote: > Unfortunately this is not the case, as Evgeniy already mentioned. > ct_sync is currently an completely in-kernel solution, with all the pros > and cons of that. (Yes, it could be done in userspace with some minimal > kernel code, and yes, it had a few advantages over the current solution. I strongly disagree with this. Or, let's say - while it is doable in userspace, it would be at a very high cost... additional latency, lots of more per-packet data copying, and the possibility of being starved by some other random userspace application. > > I think the CARP loadbalancing feature is an improvement over what is > > being suggested by Harald. =20 Yes, I would also be interested in what Jamal was referring to. I cannot really remember having anything suggested as 'cluster manager'. > > I have to say as well i am shocked that state is just being transfered > > blindly - but i will deal with Harald when he shows up in Ottawa ;-> >=20 > Would it be possible to summarize your ideas here? Yes, I know it is > easier and faster to talk about those things in person, but > unfortunately I won't be there in Ottawa, but am of course seriously > interested in all ideas related to ct_sync... I was just talking to Jamal today. His basic proposal was something like: more than 90% of all connections last longer than 10 seconds, so we only replicate connections that exist for more time. I argued that this was not the level of synchronization that we want to achieve, and that in such a case he could just skip any kind of sync code and live with the existing 'connection pickup' code of ip_conntrack (ACK from both sides being able to establish connection even if no initial SYN handshake was seen). Jamal apparently wasn't aware of this. Anyway, there will be some more discussion after my presentation at OLS later this week. I'll keep you posted. > Regards, > Krisztian KOVACS btw: I think we should remove netdev for further discussions on ct_sync, since there is a more specific mailinglist. --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --6WlEvdN9Dv0WHSBl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/IWxXaXGVTD0i/8RAn5RAJ9M5vuED2YcCM92NlXtiADFT39RagCdEoQT KpSAfgmueJ7DiJQXEgkY2kk= =TzTJ -----END PGP SIGNATURE----- --6WlEvdN9Dv0WHSBl-- From sebest@ovibes.net Tue Jul 20 02:07:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jul 2004 02:07:12 -0700 (PDT) Received: from lastinfos.com (hosting-24.75.rev.fr.colt.net [213.41.75.24] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6K96w8a017692 for ; Tue, 20 Jul 2004 02:06:59 -0700 Received: (qmail 11202 invoked by uid 204); 20 Jul 2004 11:09:24 +0200 Received: from sebest@ovibes.net by lastinfos.com by uid 201 with qmail-scanner-1.16 (. Clear:. Processed in 0.10065 secs); 20 Jul 2004 09:09:24 -0000 Received: from unknown (HELO ?192.168.0.110?) (sebest@ovibes.net@82.101.6.94) by hosting-24.75.rev.fr.colt.net with SMTP; 20 Jul 2004 11:09:23 +0200 Subject: Re: kernel 2.6.7 -> page allocation failure. order:1, mode:0x20 (netfilter?) From: Sebastien ESTIENNE Reply-To: sebest@ovibes.net To: Harald Welte Cc: linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com In-Reply-To: <20040720024741.GF27487@obroa-skai.de.gnumonks.org> References: <40FB93FE.90308@ovibes.net> <20040720024741.GF27487@obroa-skai.de.gnumonks.org> Content-Type: text/plain; charset=utf-8 Organization: ethium Message-Id: <1090314411.13005.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 20 Jul 2004 11:06:51 +0200 Content-Transfer-Encoding: 8bit X-archive-position: 7048 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sebest@ovibes.net Precedence: bulk X-list: netdev Le mar 20/07/2004 à 04:47, Harald Welte a écrit : > On Mon, Jul 19, 2004 at 11:27:26AM +0200, Sebastien ESTIENNE wrote: > > Hello, > > i have some "swapper: page allocation failure. order:1, mode:0x20" > > followed by kernel message, > > > > the hardware is a dell poweredge 1750 > > the kernel is a 2.6.7 vanilla > > > > here for a dmesg > > http://213.41.75.25/kernel/dmesg.txt > the chunk below seems like a standard code path for a locally-generated > outgoing packet: > > > [] skb_checksum_help+0x52/0x136 > > [] ip_nat_fn+0x269/0x27a [iptable_nat] > > [] ip_nat_local_fn+0x7b/0xaa [iptable_nat] > > [] tcp_sendmsg+0x509/0x10f7 > > [] tasklet_action+0x65/0xae > > [] apic_timer_interrupt+0x1a/0x20 > > [] dst_output+0x0/0x29 > > [] inet_sendmsg+0x4d/0x59 > > [] dst_output+0x0/0x29 > > [] sock_aio_write+0xbd/0xdd > > [] do_sync_write+0x8b/0xb7 > > [] nf_iterate+0x71/0xa2 > > [] copy_from_user+0x42/0x6e > > [] vfs_write+0xe8/0x119 > > [] sys_write+0x42/0x63 > > [] syscall_call+0x7/0xb > > > what's worrying me is the part above... how would skb_checksum_help > directly end up in copy_from_user()? > > > swapper: page allocation failure. order:1, mode:0x20 > > [] __alloc_pages+0x2da/0x34a > > [] __get_free_pages+0x25/0x3f > > [] kmem_getpages+0x2b/0xdc > > [] kfree_skbmem+0x24/0x2c > > [] cache_grow+0xe5/0x2a4 > > [] cache_grow+0x146/0x2a4 > > [] cache_alloc_refill+0x1cf/0x29f > > [] __kmalloc+0x85/0x8c > > [] tcp_transmit_skb+0x411/0x68a > > [] alloc_skb+0x47/0xe0 > > [] tcp_write_xmit+0x16d/0x2d6 > > [] skb_copy+0x33/0xde > > [] copy_from_user+0x42/0x6e > > Does anybody have a clue what's going on? I was running apache bench v2 on localhost And Shorewall firewall script is installed on it (version 2.0.4) iptables version 2.0.4 hope it can help From solt@dns.toxicfilms.tv Tue Jul 20 03:46:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jul 2004 03:46:36 -0700 (PDT) Received: from dns.toxicfilms.tv (qmailr@dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6KAkSgB027890 for ; Tue, 20 Jul 2004 03:46:29 -0700 Received: (qmail 4594 invoked by uid 1027); 20 Jul 2004 12:46:23 +0200 Received: from solt@dns.toxicfilms.tv by dns by uid 1026 with qmail-scanner-1.22 (1.817 (20040719) Clear:RC:0(150.254.37.14):SA:0(0.0/5.0):. Processed in 4.076989 secs); 20 Jul 2004 10:46:23 -0000 X-Qmail-Scanner-Mail-From: solt@dns.toxicfilms.tv via dns X-Qmail-Scanner-Rcpt-To: jheffner@psc.edu,netdev@oss.sgi.com X-Qmail-Scanner: 1.22 (Clear:RC:0(150.254.37.14):SA:0(0.0/5.0):. Processed in 4.076989 secs) Received: from pysiak.ae.poznan.pl (solt@150.254.37.14) by 0 with AES256-SHA encrypted SMTP; 20 Jul 2004 12:46:19 +0200 Date: Tue, 20 Jul 2004 12:46:21 +0200 From: Maciej Soltysiak X-Mailer: SecureBat! Lite (v2.10.02) UNREG / CD5BF9353B3B7091 Reply-To: Maciej Soltysiak X-Priority: 3 (Normal) Message-ID: <1802866788.20040720124621@dns.toxicfilms.tv> To: John Heffner CC: netdev@oss.sgi.com Subject: Re[2]: [partially solved] tcp_window_scaling degrades performance In-Reply-To: References: <962257105.20040719201304@dns.toxicfilms.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7049 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev JH> Could you get sender-side dumps? Receiver-side ones don't really contain JH> as much information. I could only get before-firewall-that-propably-screws-things-up dumps. I will surely do that too. Locally it's not affected. JH> What happens if you set tcp_default_win_scale to 0, but leaving JH> tcp_window_scaling to 1? I suspect this a lot more than the changeset JH> your cite below, though if it's really better with that changeset backed JH> out, could you get a dump of that, too? With tcp_windows_scaling to 1 and tcp_default_win_scale to 0 everything seems normal again. Dumps of this will follow soon. Also, to fix the firewall we need to prolong the licence to get support to apply the hotfixes or to do a kernel upgrade or whatever would be necesarry. For this I will have to wait a bit :-( Regards, Maciej From hadi@cyberus.ca Tue Jul 20 07:24:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jul 2004 07:25:01 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6KEOqDY003904 for ; Tue, 20 Jul 2004 07:24:52 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072007250420:29323 ; Tue, 20 Jul 2004 07:25:04 -0700 Subject: Re: [nf-failover] Re: [1/2] CARP implementation. HA master's failover. From: jamal Reply-To: hadi@cyberus.ca To: KOVACS Krisztian Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com, Netfilter-failover list In-Reply-To: <1090221367.2551.27.camel@nienna.balabit> References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@jzny.localdomain> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@jzny.localdomain> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@jzny.localdomain> <20040715235313.69897131@zanzibar.2ka.mipt.ru> <1089983064.1060.1328.camel@jzny.localdomain> <1090221367.2551.27.camel@nienna.balabit> Organization: jamalopolis Message-Id: <1090333462.1136.58.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Jul 2004 10:24:22 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/20/2004 07:25:04 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/20/2004 07:25:09 AM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id i6KEOqDY003904 X-archive-position: 7050 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2004-07-19 at 03:16, KOVACS Krisztian wrote: > Hi, > > 2004-07-16, p keltezéssel 15:04-kor jamal ezt írta: > > Looking at what HArald has, the infrastructure seems to be the correct > > flavor. Seems something gets sent to user space via netlink and gets > > delivered via keepalived. > > Unfortunately this is not the case, as Evgeniy already mentioned. > ct_sync is currently an completely in-kernel solution, with all the pros > and cons of that. (Yes, it could be done in userspace with some minimal > kernel code, and yes, it had a few advantages over the current solution. > However, the kernel-side "agent" code would still be quite heavy-weight. > Unfortunately Netfilter's conntrack subsystem is a more complicated than > that of OpenBSD's pf. And the current code is not designed that way, so > I think it would be better to first try to finish the current project, > and then think about what should be done in a completely different way.) Thats fine. So you may have to use Evgeniys in-kernel implementation for now until things get better. How do you interact to keepalived? > > I think the CARP loadbalancing feature is an improvement over what is > > being suggested by Harald. > > What do you mean by that? Of course, it is a serious weakness of the > current code that it is not capable of load balancing, only failover > with passive slaves. However, load balancing would probably make things > a lot more complicated. For example, see NAT-related problems described > by Lennert Buytenhek here: > > http://lists.netfilter.org/pipermail/netfilter-failover/2001-September/000043.html i couldnt access that for some reason. Seems the wifi firewall is blocking any web access. What i meant was CARP with that feature infact has an active-active setup - ct_snyc seems to be purely active-backup. > > I have to say as well i am shocked that state is just being transfered > > blindly - but i will deal with Harald when he shows up in Ottawa ;-> > > Would it be possible to summarize your ideas here? Yes, I know it is > easier and faster to talk about those things in person, but > unfortunately I won't be there in Ottawa, but am of course seriously > interested in all ideas related to ct_sync... I talked briefly to Harald in the hallway and will attend his talk. I may understand a little more about ct_sync - and hopefully a lot more after his talk. My comments were based on the fact that most flows are really shortlived that there is no point in backing them up. Human nature on a web page that is taking too long to load (for example because the firewall failed) is to hit reload button - in which case the connection tracking will be established from the begining with the failed over to node. I will try to post a paper or two that have results on lifetimes of flows etc when i have better network connection. What i remember from one is that the majority of flows dont last longer than 10 secs to begin with. So back to what i was saying earlier, and my .ca $0.02: If the majority of the flows are only lasting that long, is there any value in backing them? One arguement i can see made is that you want to speed up the lookup etc when 100K flows migrate to the backed-to node. my opinion is the following: 1) it would be valuable to backup the rules if any exist and sync things across. 2) dont blindly migrate connection states until they are established and probably lasted more than 10-15 seconds. cheers, jamal From marcelo.tosatti@cyclades.com Tue Jul 20 08:08:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jul 2004 08:08:43 -0700 (PDT) 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 i6KF8Si5005616 for ; Tue, 20 Jul 2004 08:08:29 -0700 Received: from [127.0.0.1] (helo=dmt.cyclades) by www.linux.org.uk with esmtp (Exim 4.33) id 1BmwEB-0006Gu-7F; Tue, 20 Jul 2004 16:08:23 +0100 Received: by dmt.cyclades (Postfix, from userid 500) id 8249DA823B; Tue, 20 Jul 2004 10:24:54 -0300 (BRT) Date: Tue, 20 Jul 2004 10:24:53 -0300 From: Marcelo Tosatti To: Netdev , prism54-devel@prism54.org, jgarzik@pobox.com Subject: Re: [PATCH 2.4.26] add prism54 to 2.4 tree Message-ID: <20040720132453.GA2348@dmt.cyclades> References: <20040715005140.GH14482@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040715005140.GH14482@ruslug.rutgers.edu> User-Agent: Mutt/1.4i X-archive-position: 7051 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: netdev On Wed, Jul 14, 2004 at 08:51:40PM -0400, Luis R. Rodriguez wrote: > > Marcelo, > > Attached patch adds prism54 to 2.4 tree. This patch applies cleanly to > 2.4.27-rc3 as well. Hi Luis, This looks fine for inclusion on 2.4.28-pre, after Jeff/others take a look at it. > GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E > --- linux-2.4.26/Documentation/Configure.help 2004-04-14 13:05:24.000000000 +0000 > +++ linux-2.4.26-prism54/Documentation/Configure.help 2004-07-15 00:30:04.000000000 +0000 > @@ -9968,6 +9968,49 @@ > compile it as a module, say M here and read > . > > +Intersil 802.11(a/b/g) Prism GT/Duette/Indigo support > +CONFIG_PRISM54 > + Enable PCI and Cardbus support for the following chipset based cards: > + > + ISL3880 - Prism GT 802.11 b/g > + ISL3877 - Prism Indigo 802.11 a > + ISL3890 - Prism Duette 802.11 a/b/g > + > + For a complete list of supported cards visit . > + Here is the latest confirmed list of supported cards: > + > + 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 > + Allnet ALL0271 PCI Card > + Compex WL54G Cardbus Card > + Corega CG-WLCB54GT Cardbus Card > + D-Link Air Plus Xtreme G A1 Cardbus Card aka DWL-g650 > + I-O Data WN-G54/CB Cardbus Card > + Kobishi XG-300 aka Z-Com Cardbus Card > + Netgear WG511 Cardbus Card > + Ovislink WL-5400PCI PCI Card > + Peabird WLG-PCI PCI Card > + Sitecom WL-100i Cardbus Card > + Sitecom WL-110i PCI Card > + SMC2802W - EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card > + SMC2835W - EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Card > + Z-Com XG-900 PCI Card > + Zyxel G-100 Cardbus Card > + > + If you enable this, you require a firmware file as well. > + You will need to copy this to /usr/lib/hotplug/firmware/isl3890. > + You can get this non-GPL'd firmware file from the Prism54 project page: > + . > + You will also need the /etc/hotplug/firmware.agent script from > + a current hotplug package. > + > + > + Note: You need a motherboard with DMA support to use any of these cards > + > + If you want to compile the driver as a module ( = code which can be > + inserted in and removed from the running kernel whenever you want), > + say M here and read . The module > + will be called prism54.o. > + > Aironet 4500/4800 PROC interface > CONFIG_AIRONET4500_PROC > If you say Y here (and to the "/proc file system" below), you will From jheffner@psc.edu Tue Jul 20 08:29:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jul 2004 08:29:07 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6KFT0EJ009657 for ; Tue, 20 Jul 2004 08:29:01 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i6KFSqYB020984 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 20 Jul 2004 11:28:52 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i6KFSp0S016476; Tue, 20 Jul 2004 11:28:51 -0400 (EDT) Date: Tue, 20 Jul 2004 11:28:51 -0400 (EDT) From: John Heffner To: Maciej Soltysiak cc: Subject: Re[2]: [partially solved] tcp_window_scaling degrades performance In-Reply-To: <1802866788.20040720124621@dns.toxicfilms.tv> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 7052 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev See the thread on netdev earlier this month under the subject "preliminary conclusions regarding window size issues". Your problem is most likely with a buggy window-tracking firewall. -John From snitzer@gmail.com Tue Jul 20 18:07:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jul 2004 18:07:18 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6L1792Z030626 for ; Tue, 20 Jul 2004 18:07:10 -0700 Received: by mproxy.gmail.com with SMTP id d5so811093rng for ; Tue, 20 Jul 2004 18:07:02 -0700 (PDT) Received: by 10.38.81.69 with SMTP id e69mr271245rnb; Tue, 20 Jul 2004 18:07:02 -0700 (PDT) Message-ID: <170fa0d2040720180741cfa783@mail.gmail.com> Date: Tue, 20 Jul 2004 19:07:02 -0600 From: Mike Snitzer To: fastboot@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [Fastboot] [ANNOUNCE] [PATCH] 2.6.8-rc1-kexec1 (ppc & x86) Cc: "Eric W. Biederman" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040719181115.86378.qmail@web52302.mail.yahoo.com> X-archive-position: 7053 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: snitzer@gmail.com Precedence: bulk X-list: netdev On 20 Jul 2004 09:42:11 -0600, Eric W. Biederman wrote: ... > I will take a look at this as soon as I finish the x86-64 port. > Basically I am down to restructuring the generic code so it > does not use init_mm to identity map the reboot_code_buffer, > but instead does something architecture specific. > > Removing the dependence on init_mm is going to be painful > since it touches the generic code. But I really don't see > a choice at this point. > > Once everything works after that change, I think kexec should > be much closer to kernel inclusion. As kexec approaches kernel inclusion one thing to be mindful of is that, prior to kexec'ing, loaded drivers must let go of their PCI resources in order for the newly kexec'd kernel's device drivers to work. Device drivers that don't properly let go of their resources will likely be left in a funky state. I've been bitten by this issue with the e1000 (<= 5.2.52-k4) driver. With an "Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller", device id# 1010, I get: Intel(R) PRO/1000 Network Driver - version 5.2.30.1-k1 Copyright (c) 1999-2004 Intel Corporation. PCI: Enabling device 04:05.0 (0000 -> 0003) Uhhuh. NMI received for unknown reason 31. Dazed and confused, but trying to continue Do you have a strange power saving mode enabled? The EEPROM Checksum Is Not Valid PCI: Enabling device 04:05.1 (0000 -> 0003) The EEPROM Checksum Is Not Valid The 5.2.52-k4 has toned down, yet basically the same, errors. This message results when kexec'ing from a 2.6.7 kernel with the e1000 builtin; once I made the e1000 a module and unloaded it prior to kexec'ing all was fine. Looking at the e1000 source it is clear that removing the e1000 module triggers e1000_remove() via module_exit()'s pci_unregister_driver(). Once the e1000 let go of the PCI resources the kexec'd kernel's e1000 driver was happy. Kexec looks to call all loaded modules' shutdown() routine. The e1000 doesn't have shutdown(); but it does have a remove(). In preparation for kexec to be viable for 2.6 inclusion it would appear that some effort will need to go in to making sure all drivers in the kernel actually let go of their resources. Should there be an audit to verify all device drivers have a shutdown()? Another option is to call each module's remove() iff the module doesn't have shutdown(). This would require changing drivers/base/power/shutdown.c device_shutdown() to include ... else if (dev->driver && dev->driver->remove) ... As a side-effect it would make drivers like the e1000 safe for use with kexec. thoughts? Mike From vkondra@mail.ru Tue Jul 20 23:09:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jul 2004 23:09:59 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6L69fbc007664 for ; Tue, 20 Jul 2004 23:09:42 -0700 Received: from [212.179.226.190] (port=50552 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1BnAIL-0001Hk-00 for netdev@oss.sgi.com; Wed, 21 Jul 2004 10:09:38 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: driver certification Date: Wed, 21 Jul 2004 09:09:25 +0300 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Message-Id: <200407210909.34245.vkondra@mail.ru> X-Spam: Not detected Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6L69fbc007664 X-archive-position: 7055 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 649 Lines: 19 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anybody know whether there is certification tests for network driver? I.e. some procedure that will say: "yes, this driver do what proper network driver should do" or "no, you don't comply with items a,b,c..." If in kernel it is not defined yet, anyone from distributors (RedHat, SUSE) or vendors (HP,IBM), do you have one? If it is not exist yet, how could I set criteria for validation of the driver? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/gicqxdj7mhC6o0RAua3AJ4oUNK707YkHrnIANKsKKIrPkvRswCeJmQO /ArrWwdxC68WxqOK+RcwDhM= =hbaL -----END PGP SIGNATURE----- From margitsw@t-online.de Wed Jul 21 00:05:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 00:06:25 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6L75l1O008962 for ; Wed, 21 Jul 2004 00:05:47 -0700 Received: from fwd09.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1BnBAE-0004oz-01; Wed, 21 Jul 2004 09:05:18 +0200 Received: from roglap.local (Eq7Vs4ZcoecfXt8Vg11k-fvAaYxeKz4p83T4dTMZrZqAaRLpcPpRQM@[217.224.29.23]) by fwd09.sul.t-online.com with esmtp id 1BnBA9-1ukNRg0; Wed, 21 Jul 2004 09:05:13 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Refix TRDY/RETRY_TIMEOUT Date: Wed, 21 Jul 2004 08:58:00 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_4Ph/AAp4awx81Gr" Message-Id: <200407210858.00645.margitsw@t-online.de> X-ID: Eq7Vs4ZcoecfXt8Vg11k-fvAaYxeKz4p83T4dTMZrZqAaRLpcPpRQM X-archive-position: 7056 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 2375 Lines: 71 --Boundary-00=_4Ph/AAp4awx81Gr Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-21 Margit Schubert-While * Reintroduce pushing 0 into the TRDY_TIMEOUT and RETRY_TIMEOUT registers. Make this configurable with module parameter init_pcitm. * We now have the ludicrous situation that some hardware setups require this (not even pushing 0xFF helps), whilst others don't care either way (the majority), and yet others bork if anything is pushed into these regs. If anybody can explain this (including Conexant :-) ), my ears are open. Jeff, this patch together with the mgtframeptr patch from 07/15 are pretty urgent. Margit --Boundary-00=_4Ph/AAp4awx81Gr Content-Type: text/x-diff; charset="us-ascii"; name="pciretry.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pciretry.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.6.8-04/drivers/net/wireless/prism54/islpci_hotplug.c --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-01 07:23:52.000000000 +0200 +++ linux-2.6.8-04/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-20 19:07:30.000000000 +0200 @@ -36,6 +36,9 @@ MODULE_DESCRIPTION("The Prism54 802.11 Wireless LAN adapter"); MODULE_LICENSE("GPL"); +static int init_pcitm = 0; +module_param(init_pcitm, int, 0); + /* In this order: vendor, device, subvendor, subdevice, class, class_mask, * driver_data * If you have an update for this please contact prism54-devel@prism54.org @@ -292,14 +295,14 @@ * * Writing zero to both these two registers will disable both timeouts and * *can* solve problems caused by devices that are slow to respond. + * Make this configurable - MSW */ - /* I am taking these out, we should not be poking around in the - * programmable timers - MSW - */ -/* Do not zero the programmable timers - pci_write_config_byte(pdev, 0x40, 0); - pci_write_config_byte(pdev, 0x41, 0); -*/ + if ( init_pcitm >= 0 ) { + pci_write_config_byte(pdev, 0x40, (u8)init_pcitm); + pci_write_config_byte(pdev, 0x41, (u8)init_pcitm); + } else { + printk(KERN_INFO "PCI TRDY/RETRY unchanged\n"); + } /* request the pci device I/O regions */ rvalue = pci_request_regions(pdev, DRV_NAME); --Boundary-00=_4Ph/AAp4awx81Gr-- From mcgrof@studorgs.rutgers.edu Wed Jul 21 02:34:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 02:34:58 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6L9Y9HZ014695 for ; Wed, 21 Jul 2004 02:34:10 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id DABA7F9D4E; Wed, 21 Jul 2004 05:34:06 -0400 (EDT) Date: Wed, 21 Jul 2004 05:34:06 -0400 To: Marcelo Tosatti Cc: Netdev , prism54-devel@prism54.org, jgarzik@pobox.com Subject: Re: [PATCH 2.4.26] add prism54 to 2.4 tree Message-ID: <20040721093406.GB9141@ruslug.rutgers.edu> Mail-Followup-To: Marcelo Tosatti , Netdev , prism54-devel@prism54.org, jgarzik@pobox.com References: <20040715005140.GH14482@ruslug.rutgers.edu> <20040720132453.GA2348@dmt.cyclades> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: <20040720132453.GA2348@dmt.cyclades> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 7057 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 225781 Lines: 7547 --V0207lvV8h4k8FAm Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 20, 2004 at 10:24:53AM -0300, Marcelo Tosatti wrote: > On Wed, Jul 14, 2004 at 08:51:40PM -0400, Luis R. Rodriguez wrote: > >=20 > > Marcelo, > >=20 > > Attached patch adds prism54 to 2.4 tree. This patch applies cleanly to > > 2.4.27-rc3 as well. >=20 > Hi Luis,=20 >=20 > This looks fine for inclusion on 2.4.28-pre, after Jeff/others take a loo= k=20 > at it.=20 Marcelo, The attached patch catches a couple of recent changes which are important. Please consider this patch as *the* candidate for inclusion of prism54 onto= 2.4.=20 Jeff may take a look at it but all this has already been revised a lot so I wouldn't expect much more revising going on except for two new patches pending to sync our trees. Jeff, This patch has exactly what we had + two pending patches Margit just sent in. Can you give the green light for Marcelo to include this on 2.4? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.4-prism54-cvs-latest.diff" Content-Transfer-Encoding: quoted-printable --- linux-2.4.26/Documentation/Configure.help 2004-04-14 13:05:24.000000000= +0000 +++ linux-2.4.26-prism54/Documentation/Configure.help 2004-07-21 09:00:04.0= 00000000 +0000 @@ -9968,6 +9968,49 @@ compile it as a module, say M here and read . =20 +Intersil 802.11(a/b/g) Prism GT/Duette/Indigo support +CONFIG_PRISM54 + Enable PCI and Cardbus support for the following chipset based cards: + + ISL3880 - Prism GT 802.11 b/g + ISL3877 - Prism Indigo 802.11 a + ISL3890 - Prism Duette 802.11 a/b/g + =20 + For a complete list of supported cards visit . + Here is the latest confirmed list of supported cards: + + 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 + Allnet ALL0271 PCI Card + Compex WL54G Cardbus Card + Corega CG-WLCB54GT Cardbus Card + D-Link Air Plus Xtreme G A1 Cardbus Card aka DWL-g650 + I-O Data WN-G54/CB Cardbus Card + Kobishi XG-300 aka Z-Com Cardbus Card + Netgear WG511 Cardbus Card + Ovislink WL-5400PCI PCI Card + Peabird WLG-PCI PCI Card + Sitecom WL-100i Cardbus Card + Sitecom WL-110i PCI Card + SMC2802W - EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card + SMC2835W - EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Card + Z-Com XG-900 PCI Card + Zyxel G-100 Cardbus Card + + If you enable this, you require a firmware file as well. + You will need to copy this to /usr/lib/hotplug/firmware/isl3890. + You can get this non-GPL'd firmware file from the Prism54 project page: + . + You will also need the /etc/hotplug/firmware.agent script from + a current hotplug package. + + + Note: You need a motherboard with DMA support to use any of these cards= =20 + =20 + If you want to compile the driver as a module ( =3D code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read . The module + will be called prism54.o. + Aironet 4500/4800 PROC interface CONFIG_AIRONET4500_PROC If you say Y here (and to the "/proc file system" below), you will diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/C= onfig.in linux-2.4.26-prism54/drivers/net/wireless/Config.in --- linux-2.4.26/drivers/net/wireless/Config.in 2004-04-14 13:05:30.0000000= 00 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/Config.in 2004-07-21 09:00:04= .000000000 +0000 @@ -27,6 +27,15 @@ dep_tristate ' Atmel at76c502/at76c504 PCMCIA cards' CONFIG_PCMCIA_ATM= EL $CONFIG_FW_LOADER fi =20 +# If PCI enabled, allow for prism54 driver. CONFIG_FW_LOADER required +comment 'Prism54 PCI/PCMCIA GT/Duette Driver - 802.11(a/b/g)' +dep_tristate 'Intersil Prism GT/Duette/Indigo PCI/PCMCIA' CONFIG_PRISM54 $= CONFIG_EXPERIMENTAL $CONFIG_PCI $CONFIG_HOTPLUG +if [ "$CONFIG_PRISM54" !=3D "n" ]; then + if [ "$CONFIG_FW_LOADER" !=3D "y" ]; then + define_tristate CONFIG_FW_LOADER $CONFIG_PRISM54 + fi +fi + # yes, this works even when no drivers are selected if [ "$CONFIG_ISA" =3D "y" -o "$CONFIG_PCI" =3D "y" -o \ "$CONFIG_ALL_PPC" =3D "y" -o "$CONFIG_PCMCIA" !=3D "n" ]; then diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/M= akefile linux-2.4.26-prism54/drivers/net/wireless/Makefile --- linux-2.4.26/drivers/net/wireless/Makefile 2004-04-14 13:05:30.00000000= 0 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/Makefile 2004-07-21 09:00:04.= 000000000 +0000 @@ -25,4 +25,9 @@ obj-$(CONFIG_AIRO_CS) +=3D airo_cs.o airo.o obj-$(CONFIG_PCMCIA_ATMEL) +=3D atmel_cs.o atmel.o =20 +ifeq ($(CONFIG_PRISM54),y) +obj-$(CONFIG_PRISM54) +=3D prism54/prism54.o +endif +subdir-$(CONFIG_PRISM54) +=3D prism54 + include $(TOPDIR)/Rules.make diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/Makefile linux-2.4.26-prism54/drivers/net/wireless/prism54/Makefile --- linux-2.4.26/drivers/net/wireless/prism54/Makefile 1970-01-01 00:00:00.= 000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/Makefile 2004-07-21 0= 9:00:04.000000000 +0000 @@ -0,0 +1,12 @@ + +O_TARGET :=3D prism54.o + +EXTRA_CFLAGS +=3D -DPRISM54_COMPAT24 + +obj-y :=3D isl_38xx.o islpci_dev.o islpci_eth.o \ + islpci_mgt.o islpci_hotplug.o isl_ioctl.o \ + oid_mgt.o + +obj-m +=3D prism54.o + +include $(TOPDIR)/Rules.make diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_38xx.c linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38x= x.c --- linux-2.4.26/drivers/net/wireless/prism54/isl_38xx.c 1970-01-01 00:00:0= 0.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38xx.c 2004-07-21= 09:00:04.000000000 +0000 @@ -0,0 +1,267 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003-2004 Luis R. Rodriguez _ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#define __KERNEL_SYSCALLS__ + +#include +#include +#include +#include + +#include +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" + +/*************************************************************************= ***** + Device Interface & Control functions +**************************************************************************= ****/ + +/** + * isl38xx_disable_interrupts - disable all interrupts + * @device: pci memory base address + * + * Instructs the device to disable all interrupt reporting by asserting= =20 + * the IRQ line. New events may still show up in the interrupt identifica= tion + * register located at offset %ISL38XX_INT_IDENT_REG. + */ +void +isl38xx_disable_interrupts(void *device) +{ + isl38xx_w32_flush(device, 0x00000000, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_handle_sleep_request(isl38xx_control_block *control_block, + int *powerstate, void *device_base) +{ + /* device requests to go into sleep mode + * check whether the transmit queues for data and management are empty */ + if (isl38xx_in_queue(control_block, ISL38XX_CB_TX_DATA_LQ)) + /* data tx queue not empty */ + return; + + if (isl38xx_in_queue(control_block, ISL38XX_CB_TX_MGMTQ)) + /* management tx queue not empty */ + return; + + /* check also whether received frames are pending */ + if (isl38xx_in_queue(control_block, ISL38XX_CB_RX_DATA_LQ)) + /* data rx queue not empty */ + return; + + if (isl38xx_in_queue(control_block, ISL38XX_CB_RX_MGMTQ)) + /* management rx queue not empty */ + return; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Device going to sleep mode\n"); +#endif + + /* all queues are empty, allow the device to go into sleep mode */ + *powerstate =3D ISL38XX_PSM_POWERSAVE_STATE; + + /* assert the Sleep interrupt in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_SLEEP, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_handle_wakeup(isl38xx_control_block *control_block, + int *powerstate, void *device_base) +{ + /* device is in active state, update the powerstate flag */ + *powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* now check whether there are frames pending for the card */ + if (!isl38xx_in_queue(control_block, ISL38XX_CB_TX_DATA_LQ) + && !isl38xx_in_queue(control_block, ISL38XX_CB_TX_MGMTQ)) + return; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_ANYTHING, "Wake up handler trigger the device\n"); +#endif + + /* either data or management transmit queue has a frame pending + * trigger the device by setting the Update bit in the Device Int reg */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +void +isl38xx_trigger_device(int asleep, void *device_base) +{ + struct timeval current_time; + u32 reg, counter =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "isl38xx trigger device\n"); +#endif + + /* check whether the device is in power save mode */ + if (asleep) { + /* device is in powersave, trigger the device for wakeup */ +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", + current_time.tv_sec, current_time.tv_usec); +#endif + + DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, + readl(device_base + ISL38XX_CTRL_STAT_REG)); + udelay(ISL38XX_WRITEIO_DELAY); + + if (reg =3D readl(device_base + ISL38XX_INT_IDENT_REG), + reg =3D=3D 0xabadface) { +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, + "%08li.%08li Device register abadface\n", + current_time.tv_sec, current_time.tv_usec); +#endif + /* read the Device Status Register until Sleepmode bit is set */ + while (reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG), + (reg & ISL38XX_CTRL_STAT_SLEEPMODE) =3D=3D 0) { + udelay(ISL38XX_WRITEIO_DELAY); + counter++; + } + + DEBUG(SHOW_TRACING, + "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, + readl(device_base + ISL38XX_CTRL_STAT_REG)); + udelay(ISL38XX_WRITEIO_DELAY); + +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, + "%08li.%08li Device asleep counter %i\n", + current_time.tv_sec, current_time.tv_usec, + counter); +#endif + } + /* assert the Wakeup interrupt in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_WAKEUP, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + /* perform another read on the Device Status Register */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + +#if VERBOSE > SHOW_ERROR_MESSAGES + do_gettimeofday(¤t_time); + DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", + current_time.tv_sec, current_time.tv_usec, reg); +#endif + } else { + /* device is (still) awake */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Device is in active state\n"); +#endif + /* trigger the device by setting the Update bit in the Device Int reg */ + + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + } +} + +void +isl38xx_interface_reset(void *device_base, dma_addr_t host_address) +{ + u32 reg; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "isl38xx_interface_reset \n"); +#endif + + /* load the address of the control block in the device */ + isl38xx_w32_flush(device_base, host_address, ISL38XX_CTRL_BLK_BASE_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the reset bit in the Device Interrupt Register */ + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_RESET, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + /* enable the interrupt for detecting initialization */ + + /* Note: Do not enable other interrupts here. We want the + * device to have come up first 100% before allowing any other=20 + * interrupts. */ + reg =3D ISL38XX_INT_IDENT_INIT; + + isl38xx_w32_flush(device_base, reg, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); /* allow complete full reset */ +} + +void +isl38xx_enable_common_interrupts(void *device_base) { + u32 reg; + reg =3D ( ISL38XX_INT_IDENT_UPDATE |=20 + ISL38XX_INT_IDENT_SLEEP | ISL38XX_INT_IDENT_WAKEUP); + isl38xx_w32_flush(device_base, reg, ISL38XX_INT_EN_REG); + udelay(ISL38XX_WRITEIO_DELAY); +} + +int +isl38xx_in_queue(isl38xx_control_block *cb, int queue) +{ + const s32 delta =3D (le32_to_cpu(cb->driver_curr_frag[queue]) - + le32_to_cpu(cb->device_curr_frag[queue])); + + /* determine the amount of fragments in the queue depending on the type + * of the queue, either transmit or receive */ + + BUG_ON(delta < 0); /* driver ptr must be ahead of device ptr */ + + switch (queue) { + /* send queues */ + case ISL38XX_CB_TX_MGMTQ: + BUG_ON(delta > ISL38XX_CB_MGMT_QSIZE); + case ISL38XX_CB_TX_DATA_LQ: + case ISL38XX_CB_TX_DATA_HQ: + BUG_ON(delta > ISL38XX_CB_TX_QSIZE); + return delta; + break; + + /* receive queues */ + case ISL38XX_CB_RX_MGMTQ: + BUG_ON(delta > ISL38XX_CB_MGMT_QSIZE); + return ISL38XX_CB_MGMT_QSIZE - delta; + break; + + case ISL38XX_CB_RX_DATA_LQ: + case ISL38XX_CB_RX_DATA_HQ: + BUG_ON(delta > ISL38XX_CB_RX_QSIZE); + return ISL38XX_CB_RX_QSIZE - delta; + break; + } + BUG(); + return 0; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_38xx.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38x= x.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_38xx.h 1970-01-01 00:00:0= 0.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_38xx.h 2004-07-21= 09:00:04.000000000 +0000 @@ -0,0 +1,169 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISL_38XX_H +#define _ISL_38XX_H + +#include +#include +#include + +#define ISL38XX_CB_RX_QSIZE 8 +#define ISL38XX_CB_TX_QSIZE 32 + +/* ISL38XX Access Point Specific definitions */ +#define ISL38XX_MAX_WDS_LINKS 8 + +/* ISL38xx Client Specific definitions */ +#define ISL38XX_PSM_ACTIVE_STATE 0 +#define ISL38XX_PSM_POWERSAVE_STATE 1 + +/* ISL38XX Host Interface Definitions */ +#define ISL38XX_PCI_MEM_SIZE 0x02000 +#define ISL38XX_MEMORY_WINDOW_SIZE 0x01000 +#define ISL38XX_DEV_FIRMWARE_ADDRES 0x20000 +#define ISL38XX_WRITEIO_DELAY 10 /* in us */ +#define ISL38XX_RESET_DELAY 50 /* in ms */ +#define ISL38XX_WAIT_CYCLE 10 /* in 10ms */ +#define ISL38XX_MAX_WAIT_CYCLES 10 + +/* PCI Memory Area */ +#define ISL38XX_HARDWARE_REG 0x0000 +#define ISL38XX_CARDBUS_CIS 0x0800 +#define ISL38XX_DIRECT_MEM_WIN 0x1000 + +/* Hardware registers */ +#define ISL38XX_DEV_INT_REG 0x0000 +#define ISL38XX_INT_IDENT_REG 0x0010 +#define ISL38XX_INT_ACK_REG 0x0014 +#define ISL38XX_INT_EN_REG 0x0018 +#define ISL38XX_GEN_PURP_COM_REG_1 0x0020 +#define ISL38XX_GEN_PURP_COM_REG_2 0x0024 +#define ISL38XX_CTRL_BLK_BASE_REG ISL38XX_GEN_PURP_COM_REG_1 +#define ISL38XX_DIR_MEM_BASE_REG 0x0030 +#define ISL38XX_CTRL_STAT_REG 0x0078 + +/* High end mobos queue up pci writes, the following + * is used to "read" from after a write to force flush */ +#define ISL38XX_PCI_POSTING_FLUSH ISL38XX_INT_EN_REG + +/** + * isl38xx_w32_flush - PCI iomem write helper + * @base: (host) memory base address of the device + * @val: 32bit value (host order) to write + * @offset: byte offset into @base to write value to + *=20 + * This helper takes care of writing a 32bit datum to the + * specified offset into the device's pci memory space, and making sure= =20 + * the pci memory buffers get flushed by performing one harmless read=20 + * from the %ISL38XX_PCI_POSTING_FLUSH offset. + */ +static inline void +isl38xx_w32_flush(void *base, u32 val, unsigned long offset) +{ + writel(val, base + offset); + (void) readl(base + ISL38XX_PCI_POSTING_FLUSH); +} + +/* Device Interrupt register bits */ +#define ISL38XX_DEV_INT_RESET 0x0001 +#define ISL38XX_DEV_INT_UPDATE 0x0002 +#define ISL38XX_DEV_INT_WAKEUP 0x0008 +#define ISL38XX_DEV_INT_SLEEP 0x0010 + +/* Interrupt Identification/Acknowledge/Enable register bits */ +#define ISL38XX_INT_IDENT_UPDATE 0x0002 +#define ISL38XX_INT_IDENT_INIT 0x0004 +#define ISL38XX_INT_IDENT_WAKEUP 0x0008 +#define ISL38XX_INT_IDENT_SLEEP 0x0010 +#define ISL38XX_INT_SOURCES 0x001E + +/* Control/Status register bits */ +#define ISL38XX_CTRL_STAT_SLEEPMODE 0x00000200 +#define ISL38XX_CTRL_STAT_CLKRUN 0x00800000 +#define ISL38XX_CTRL_STAT_RESET 0x10000000 +#define ISL38XX_CTRL_STAT_RAMBOOT 0x20000000 +#define ISL38XX_CTRL_STAT_STARTHALTED 0x40000000 +#define ISL38XX_CTRL_STAT_HOST_OVERRIDE 0x80000000 + +/* Control Block definitions */ +#define ISL38XX_CB_RX_DATA_LQ 0 +#define ISL38XX_CB_TX_DATA_LQ 1 +#define ISL38XX_CB_RX_DATA_HQ 2 +#define ISL38XX_CB_TX_DATA_HQ 3 +#define ISL38XX_CB_RX_MGMTQ 4 +#define ISL38XX_CB_TX_MGMTQ 5 +#define ISL38XX_CB_QCOUNT 6 +#define ISL38XX_CB_MGMT_QSIZE 4 +#define ISL38XX_MIN_QTHRESHOLD 4 /* fragments */ + +/* Memory Manager definitions */ +#define MGMT_FRAME_SIZE 1500 /* >=3D size struct o= bj_bsslist */ +#define MGMT_TX_FRAME_COUNT 24 /* max 4 + spare 4 + 8 = init */ +#define MGMT_RX_FRAME_COUNT 24 /* 4*4 + spare 8 */ +#define MGMT_FRAME_COUNT (MGMT_TX_FRAME_COUNT + MGM= T_RX_FRAME_COUNT) +#define CONTROL_BLOCK_SIZE 1024 /* should be enough */ +#define PSM_FRAME_SIZE 1536 +#define PSM_MINIMAL_STATION_COUNT 64 +#define PSM_FRAME_COUNT PSM_MINIMAL_STATION_COUNT +#define PSM_BUFFER_SIZE PSM_FRAME_SIZE * PSM_FRAME= _COUNT +#define MAX_TRAP_RX_QUEUE 4 +#define HOST_MEM_BLOCK CONTROL_BLOCK_SIZE + PSM_B= UFFER_SIZE + +/* Fragment package definitions */ +#define FRAGMENT_FLAG_MF 0x0001 +#define MAX_FRAGMENT_SIZE 1536 + +/* In monitor mode frames have a header. I don't know exactly how big those + * frame can be but I've never seen any frame bigger than 1584... : + */ +#define MAX_FRAGMENT_SIZE_RX 1600 + +typedef struct { + u32 address; /* physical address on host */ + u16 size; /* packet size */ + u16 flags; /* set of bit-wise flags */ +} isl38xx_fragment; + +struct isl38xx_cb { + u32 driver_curr_frag[ISL38XX_CB_QCOUNT]; + u32 device_curr_frag[ISL38XX_CB_QCOUNT]; + isl38xx_fragment rx_data_low[ISL38XX_CB_RX_QSIZE]; + isl38xx_fragment tx_data_low[ISL38XX_CB_TX_QSIZE]; + isl38xx_fragment rx_data_high[ISL38XX_CB_RX_QSIZE]; + isl38xx_fragment tx_data_high[ISL38XX_CB_TX_QSIZE]; + isl38xx_fragment rx_data_mgmt[ISL38XX_CB_MGMT_QSIZE]; + isl38xx_fragment tx_data_mgmt[ISL38XX_CB_MGMT_QSIZE]; +}; + +typedef struct isl38xx_cb isl38xx_control_block; + +/* determine number of entries currently in queue */ +int isl38xx_in_queue(isl38xx_control_block *cb, int queue); + +void isl38xx_disable_interrupts(void *); +void isl38xx_enable_common_interrupts(void *); + +void isl38xx_handle_sleep_request(isl38xx_control_block *, int *, + void *); +void isl38xx_handle_wakeup(isl38xx_control_block *, int *, void *); +void isl38xx_trigger_device(int, void *); +void isl38xx_interface_reset(void *, dma_addr_t); + +#endif /* _ISL_38XX_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_ioctl.c linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_io= ctl.c --- linux-2.4.26/drivers/net/wireless/prism54/isl_ioctl.c 1970-01-01 00:00:= 00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_ioctl.c 2004-07-2= 1 09:00:04.000000000 +0000 @@ -0,0 +1,2261 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * (C) 2003,2004 Aurelien Alleaume + * (C) 2003 Herbert Valerio Riedel + * (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include +#include +#include +#include + +#include + +#include "prismcompat.h" +#include "isl_ioctl.h" +#include "islpci_mgt.h" +#include "isl_oid.h" /* additional types and defs for isl38xx fw */ +#include "oid_mgt.h" + +#include /* New driver API */ + +static int init_mode =3D CARD_DEFAULT_IW_MODE; +static int init_channel =3D CARD_DEFAULT_CHANNEL; +static int init_wep =3D CARD_DEFAULT_WEP; +static int init_filter =3D CARD_DEFAULT_FILTER; +static int init_authen =3D CARD_DEFAULT_AUTHEN; +static int init_dot1x =3D CARD_DEFAULT_DOT1X; +static int init_conformance =3D CARD_DEFAULT_CONFORMANCE; +static int init_mlme =3D CARD_DEFAULT_MLME_MODE; + +module_param(init_mode, int, 0); +MODULE_PARM_DESC(init_mode, + "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Ma= ster / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not sup= ported yet)\n6: Monitor"); + +module_param(init_channel, int, 0); +MODULE_PARM_DESC(init_channel, + "Check `iwpriv ethx channel` for available channels"); + +module_param(init_wep, int, 0); +module_param(init_filter, int, 0); + +module_param(init_authen, int, 0); +MODULE_PARM_DESC(init_authen, + "Authentication method. Can be of seven types:\n0 0x0000: None\n1 0x000= 1: DOT11_AUTH_OS (Default)\n2 0x0002: DOT11_AUTH_SK\n3 0x0003: DOT11_AUTH_B= OTH"); + +module_param(init_dot1x, int, 0); +MODULE_PARM_DESC(init_dot1x, + "\n0: None/not set (Default)\n1: DOT11_DOT1X_AUTHENABLED\n2: DOT11_DOT1= X_KEYTXENABLED"); + +module_param(init_mlme, int, 0); +MODULE_PARM_DESC(init_mlme, + "Sets the MAC layer management entity (MLME) mode of operation,\n0: DOT= 11_MLME_AUTO (Default)\n1: DOT11_MLME_INTERMEDIATE\n2: DOT11_MLME_EXTENDED"= ); + +/** + * prism54_mib_mode_helper - MIB change mode helper function + * @mib: the &struct islpci_mib object to modify + * @iw_mode: new mode (%IW_MODE_*) + *=20 + * This is a helper function, hence it does not lock. Make sure + * caller deals with locking *if* necessary. This function sets the=20 + * mode-dependent mib values and does the mapping of the Linux=20 + * Wireless API modes to Device firmware modes. It also checks for=20 + * correct valid Linux wireless modes.=20 + */ +int +prism54_mib_mode_helper(islpci_private *priv, u32 iw_mode) +{ + u32 config =3D INL_CONFIG_MANUALRUN; + u32 mode, bsstype; + + /* For now, just catch early the Repeater and Secondary modes here */ + if (iw_mode =3D=3D IW_MODE_REPEAT || iw_mode =3D=3D IW_MODE_SECOND) { + printk(KERN_DEBUG + "%s(): Sorry, Repeater mode and Secondary mode " + "are not yet supported by this driver.\n", __FUNCTION__); + return -EINVAL; + } + + priv->iw_mode =3D iw_mode; + + switch (iw_mode) { + case IW_MODE_AUTO: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_ANY; + break; + case IW_MODE_ADHOC: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_IBSS; + break; + case IW_MODE_INFRA: + mode =3D INL_MODE_CLIENT; + bsstype =3D DOT11_BSSTYPE_INFRA; + break; + case IW_MODE_MASTER: + mode =3D INL_MODE_AP; + bsstype =3D DOT11_BSSTYPE_INFRA; + break; + case IW_MODE_MONITOR: + mode =3D INL_MODE_PROMISCUOUS; + bsstype =3D DOT11_BSSTYPE_ANY; + config |=3D INL_CONFIG_RXANNEX; + break; + default: + return -EINVAL; + } + + if (init_wds) + config |=3D INL_CONFIG_WDS; + mgt_set(priv, DOT11_OID_BSSTYPE, &bsstype); + mgt_set(priv, OID_INL_CONFIG, &config); + mgt_set(priv, OID_INL_MODE, &mode); + + return 0; +} + +/** + * prism54_mib_init - fill MIB cache with defaults + * + * this function initializes the struct given as @mib with defaults, + * of which many are retrieved from the global module parameter + * variables. =20 + */ + +void +prism54_mib_init(islpci_private *priv) +{ + u32 t; + struct obj_buffer psm_buffer =3D { + .size =3D PSM_BUFFER_SIZE, + .addr =3D priv->device_psm_buffer + }; + + mgt_set(priv, DOT11_OID_CHANNEL, &init_channel); + mgt_set(priv, DOT11_OID_AUTHENABLE, &init_authen); + mgt_set(priv, DOT11_OID_PRIVACYINVOKED, &init_wep); + + mgt_set(priv, DOT11_OID_PSMBUFFER, &psm_buffer); + mgt_set(priv, DOT11_OID_EXUNENCRYPTED, &init_filter); + mgt_set(priv, DOT11_OID_DOT1XENABLE, &init_dot1x); + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &init_mlme); + mgt_set(priv, OID_INL_DOT11D_CONFORMANCE, &init_conformance); + + t =3D 127; + mgt_set(priv, OID_INL_OUTPUTPOWER, &t); + + /* Important: we are setting a default wireless mode and we are=20 + * forcing a valid one, so prism54_mib_mode_helper should just set + * mib values depending on what the wireless mode given is. No need + * for it save old values */ + if (init_mode > IW_MODE_MONITOR || init_mode < IW_MODE_AUTO) { + printk(KERN_DEBUG "%s(): You passed a non-valid init_mode. " + "Using default mode\n", __FUNCTION__); + init_mode =3D CARD_DEFAULT_IW_MODE; + } + /* This sets all of the mode-dependent values */ + prism54_mib_mode_helper(priv, init_mode); +} + +/* this will be executed outside of atomic context thanks to + * schedule_work(), thus we can as well use sleeping semaphore + * locking */ +void +prism54_update_stats(islpci_private *priv) +{ + char *data; + int j; + struct obj_bss bss, *bss2; + union oid_res_t r; + + if (down_interruptible(&priv->stats_sem)) + return; + +/* Noise floor. + * I'm not sure if the unit is dBm. + * Note : If we are not connected, this value seems to be irrelevant. */ + + mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); + priv->local_iwstatistics.qual.noise =3D r.u; + +/* Get the rssi of the link. To do this we need to retrieve a bss. */ + + /* First get the MAC address of the AP we are associated with. */ + mgt_get_request(priv, DOT11_OID_BSSID, 0, NULL, &r); + data =3D r.ptr; + + /* copy this MAC to the bss */ + memcpy(bss.address, data, 6); + kfree(data); + + /* now ask for the corresponding bss */ + j =3D mgt_get_request(priv, DOT11_OID_BSSFIND, 0, (void *) &bss, &r); + bss2 =3D r.ptr; + /* report the rssi and use it to calculate + * link quality through a signal-noise + * ratio */ + priv->local_iwstatistics.qual.level =3D bss2->rssi; + priv->local_iwstatistics.qual.qual =3D + bss2->rssi - priv->iwstatistics.qual.noise; + + kfree(bss2); + + /* report that the stats are new */ + priv->local_iwstatistics.qual.updated =3D 0x7; + +/* Rx : unable to decrypt the MPDU */ + mgt_get_request(priv, DOT11_OID_PRIVRXFAILED, 0, NULL, &r); + priv->local_iwstatistics.discard.code =3D r.u; + +/* Tx : Max MAC retries num reached */ + mgt_get_request(priv, DOT11_OID_MPDUTXFAILED, 0, NULL, &r); + priv->local_iwstatistics.discard.retries =3D r.u; + + up(&priv->stats_sem); + + return; +} + +struct iw_statistics * +prism54_get_wireless_stats(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + + /* If the stats are being updated return old data */ + if (down_trylock(&priv->stats_sem) =3D=3D 0) { + memcpy(&priv->iwstatistics, &priv->local_iwstatistics, + sizeof (struct iw_statistics)); + /* They won't be marked updated for the next time */ + priv->local_iwstatistics.qual.updated =3D 0; + up(&priv->stats_sem); + } else + priv->iwstatistics.qual.updated =3D 0; + + /* Update our wireless stats, but do not schedule to often=20 + * (max 1 HZ) */ + if ((priv->stats_timestamp =3D=3D 0) || + time_after(jiffies, priv->stats_timestamp + 1 * HZ)) { + schedule_work(&priv->stats_work); + priv->stats_timestamp =3D jiffies; + } + + return &priv->iwstatistics; +} + +static int +prism54_commit(struct net_device *ndev, struct iw_request_info *info, + char *cwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + /* simply re-set the last set SSID, this should commit most stuff */ + + /* Commit in Monitor mode is not necessary, also setting essid + * in Monitor mode does not make sense and isn't allowed for this + * device's firmware */ + if (priv->iw_mode !=3D IW_MODE_MONITOR) + return mgt_set_request(priv, DOT11_OID_SSID, 0, NULL); + return 0; +} + +static int +prism54_get_name(struct net_device *ndev, struct iw_request_info *info, + char *cwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + char *capabilities; + union oid_res_t r; + int rvalue; + + if (islpci_get_state(priv) < PRV_STATE_INIT) { + strncpy(cwrq, "NOT READY!", IFNAMSIZ); + return 0; + } + rvalue =3D mgt_get_request(priv, OID_INL_PHYCAPABILITIES, 0, NULL, &r); + + switch (r.u) { + case INL_PHYCAP_5000MHZ: + capabilities =3D "IEEE 802.11a/b/g"; + break; + case INL_PHYCAP_FAA: + capabilities =3D "IEEE 802.11b/g - FAA Support"; + break; + case INL_PHYCAP_2400MHZ: + default: + capabilities =3D "IEEE 802.11b/g"; /* Default */ + break; + } + strncpy(cwrq, capabilities, IFNAMSIZ); + return rvalue; +} + +static int +prism54_set_freq(struct net_device *ndev, struct iw_request_info *info, + struct iw_freq *fwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue; + u32 c; + + if (fwrq->m < 1000) + /* we have a channel number */ + c =3D fwrq->m; + else + c =3D (fwrq->e =3D=3D 1) ? channel_of_freq(fwrq->m / 100000) : 0; + + rvalue =3D c ? mgt_set_request(priv, DOT11_OID_CHANNEL, 0, &c) : -EINVAL; + + /* Call commit handler */ + return (rvalue ? rvalue : -EINPROGRESS); +} + +static int +prism54_get_freq(struct net_device *ndev, struct iw_request_info *info, + struct iw_freq *fwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_CHANNEL, 0, NULL, &r); + + fwrq->m =3D r.u; + fwrq->e =3D 0; + + return rvalue; +} + +static int +prism54_set_mode(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 mlmeautolevel =3D CARD_DEFAULT_MLME_MODE; + + /* Let's see if the user passed a valid Linux Wireless mode */ + if (*uwrq > IW_MODE_MONITOR || *uwrq < IW_MODE_AUTO) { + printk(KERN_DEBUG + "%s: %s() You passed a non-valid init_mode.\n", + priv->ndev->name, __FUNCTION__); + return -EINVAL; + } + + down_write(&priv->mib_sem); + + if (prism54_mib_mode_helper(priv, *uwrq)) { + up_write(&priv->mib_sem); + return -EOPNOTSUPP; + } + + /* the ACL code needs an intermediate mlmeautolevel. The wpa stuff an + * extended one. + */ + if ((*uwrq =3D=3D IW_MODE_MASTER) && (priv->acl.policy !=3D MAC_POLICY_OP= EN)) + mlmeautolevel =3D DOT11_MLME_INTERMEDIATE; + if (priv->wpa) + mlmeautolevel =3D DOT11_MLME_EXTENDED; + + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &mlmeautolevel); + + mgt_commit(priv); + priv->ndev->type =3D (priv->iw_mode =3D=3D IW_MODE_MONITOR) + ? priv->monitor_type : ARPHRD_ETHER; + up_write(&priv->mib_sem); + + return 0; +} + +/* Use mib cache */ +static int +prism54_get_mode(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + BUG_ON((priv->iw_mode < IW_MODE_AUTO) || (priv->iw_mode > + IW_MODE_MONITOR)); + *uwrq =3D priv->iw_mode; + + return 0; +} + +/* we use DOT11_OID_EDTHRESHOLD. From what I guess the card will not try to + * emit data if (sensitivity > rssi - noise) (in dBm). + * prism54_set_sens does not seem to work. + */ + +static int +prism54_set_sens(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 sens; + + /* by default the card sets this to 20. */ + sens =3D vwrq->disabled ? 20 : vwrq->value; + + return mgt_set_request(priv, DOT11_OID_EDTHRESHOLD, 0, &sens); +} + +static int +prism54_get_sens(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_EDTHRESHOLD, 0, NULL, &r); + + vwrq->value =3D r.u; + vwrq->disabled =3D (vwrq->value =3D=3D 0); + vwrq->fixed =3D 1; + + return rvalue; +} + +static int +prism54_get_range(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + struct iw_range *range =3D (struct iw_range *) extra; + islpci_private *priv =3D netdev_priv(ndev); + char *data; + int i, m, rvalue; + struct obj_frequencies *freq; + union oid_res_t r; + + memset(range, 0, sizeof (struct iw_range)); + dwrq->length =3D sizeof (struct iw_range); + + /* set the wireless extension version number */ + range->we_version_source =3D SUPPORTED_WIRELESS_EXT; + range->we_version_compiled =3D WIRELESS_EXT; + + /* Now the encoding capabilities */ + range->num_encoding_sizes =3D 3; + /* 64(40) bits WEP */ + range->encoding_size[0] =3D 5; + /* 128(104) bits WEP */ + range->encoding_size[1] =3D 13; + /* 256 bits for WPA-PSK */ + range->encoding_size[2] =3D 32; + /* 4 keys are allowed */ + range->max_encoding_tokens =3D 4; + + /* we don't know the quality range... */ + range->max_qual.level =3D 0; + range->max_qual.noise =3D 0; + range->max_qual.qual =3D 0; + /* these value describe an average quality. Needs more tweaking... */ + range->avg_qual.level =3D -80; /* -80 dBm */ + range->avg_qual.noise =3D 0; /* don't know what to put here */ + range->avg_qual.qual =3D 0; + + range->sensitivity =3D 200; + + /* retry limit capabilities */ + range->retry_capa =3D IW_RETRY_LIMIT | IW_RETRY_LIFETIME; + range->retry_flags =3D IW_RETRY_LIMIT; + range->r_time_flags =3D IW_RETRY_LIFETIME; + + /* I don't know the range. Put stupid things here */ + range->min_retry =3D 1; + range->max_retry =3D 65535; + range->min_r_time =3D 1024; + range->max_r_time =3D 65535 * 1024; + + /* txpower is supported in dBm's */ + range->txpower_capa =3D IW_TXPOW_DBM; + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return 0; + + /* Request the device for the supported frequencies + * not really relevant since some devices will report the 5 GHz band + * frequencies even if they don't support them. + */ + rvalue =3D + mgt_get_request(priv, DOT11_OID_SUPPORTEDFREQUENCIES, 0, NULL, &r); + freq =3D r.ptr; + + range->num_channels =3D freq->nr; + range->num_frequency =3D freq->nr; + + m =3D min(IW_MAX_FREQUENCIES, (int) freq->nr); + for (i =3D 0; i < m; i++) { + range->freq[i].m =3D freq->mhz[i]; + range->freq[i].e =3D 6; + range->freq[i].i =3D channel_of_freq(freq->mhz[i]); + } + kfree(freq); + + rvalue |=3D mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r); + data =3D r.ptr; + + /* We got an array of char. It is NULL terminated. */ + i =3D 0; + while ((i < IW_MAX_BITRATES) && (*data !=3D 0)) { + /* the result must be in bps. The card gives us 500Kbps */ + range->bitrate[i] =3D (__s32) (*data >> 1); + range->bitrate[i] *=3D 1000000; + i++; + data++; + } + range->num_bitrates =3D i; + kfree(r.ptr); + + return rvalue; +} + +/* Set AP address*/ + +static int +prism54_set_wap(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + char bssid[6]; + int rvalue; + + if (awrq->sa_family !=3D ARPHRD_ETHER) + return -EINVAL; + + /* prepare the structure for the set object */ + memcpy(&bssid[0], awrq->sa_data, 6); + + /* set the bssid -- does this make sense when in AP mode? */ + rvalue =3D mgt_set_request(priv, DOT11_OID_BSSID, 0, &bssid); + + return (rvalue ? rvalue : -EINPROGRESS); /* Call commit handler */ +} + +/* get AP address*/ + +static int +prism54_get_wap(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_BSSID, 0, NULL, &r); + memcpy(awrq->sa_data, r.ptr, 6); + awrq->sa_family =3D ARPHRD_ETHER; + kfree(r.ptr); + + return rvalue; +} + +static int +prism54_set_scan(struct net_device *dev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + /* hehe the device does this automagicaly */ + return 0; +} + +/* a little helper that will translate our data into a card independent + * format that the Wireless Tools will understand. This was inspired by + * the "Aironet driver for 4500 and 4800 series cards" (GPL) + */ + +static char * +prism54_translate_bss(struct net_device *ndev, char *current_ev, + char *end_buf, struct obj_bss *bss, char noise) +{ + struct iw_event iwe; /* Temporary buffer */ + short cap; + islpci_private *priv =3D netdev_priv(ndev); + + /* The first entry must be the MAC address */ + memcpy(iwe.u.ap_addr.sa_data, bss->address, 6); + iwe.u.ap_addr.sa_family =3D ARPHRD_ETHER; + iwe.cmd =3D SIOCGIWAP; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_ADDR_LEN); + + /* The following entries will be displayed in the same order we give them= */ + + /* The ESSID. */ + iwe.u.data.length =3D bss->ssid.length; + iwe.u.data.flags =3D 1; + iwe.cmd =3D SIOCGIWESSID; + current_ev =3D iwe_stream_add_point(current_ev, end_buf, + &iwe, bss->ssid.octets); + + /* Capabilities */ +#define CAP_ESS 0x01 +#define CAP_IBSS 0x02 +#define CAP_CRYPT 0x10 + + /* Mode */ + cap =3D bss->capinfo; + iwe.u.mode =3D 0; + if (cap & CAP_ESS) + iwe.u.mode =3D IW_MODE_MASTER; + else if (cap & CAP_IBSS) + iwe.u.mode =3D IW_MODE_ADHOC; + iwe.cmd =3D SIOCGIWMODE; + if (iwe.u.mode) + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, + IW_EV_UINT_LEN); + + /* Encryption capability */ + if (cap & CAP_CRYPT) + iwe.u.data.flags =3D IW_ENCODE_ENABLED | IW_ENCODE_NOKEY; + else + iwe.u.data.flags =3D IW_ENCODE_DISABLED; + iwe.u.data.length =3D 0; + iwe.cmd =3D SIOCGIWENCODE; + current_ev =3D iwe_stream_add_point(current_ev, end_buf, &iwe, NULL); + + /* Add frequency. (short) bss->channel is the frequency in MHz */ + iwe.u.freq.m =3D channel_of_freq(bss->channel); + iwe.u.freq.e =3D 0; + iwe.cmd =3D SIOCGIWFREQ; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); + + /* Add quality statistics */ + iwe.u.qual.level =3D bss->rssi; + iwe.u.qual.noise =3D noise; + /* do a simple SNR for quality */ + iwe.u.qual.qual =3D bss->rssi - noise; + iwe.cmd =3D IWEVQUAL; + current_ev =3D + iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_QUAL_LEN); + + if (priv->wpa) { + u8 wpa_ie[MAX_WPA_IE_LEN]; + char *buf, *p; + size_t wpa_ie_len; + int i; + + wpa_ie_len =3D prism54_wpa_ie_get(priv, bss->address, wpa_ie); + if (wpa_ie_len > 0 && + (buf =3D kmalloc(wpa_ie_len * 2 + 10, GFP_ATOMIC))) { + p =3D buf; + p +=3D sprintf(p, "wpa_ie=3D"); + for (i =3D 0; i < wpa_ie_len; i++) { + p +=3D sprintf(p, "%02x", wpa_ie[i]); + } + memset(&iwe, 0, sizeof (iwe)); + iwe.cmd =3D IWEVCUSTOM; + iwe.u.data.length =3D strlen(buf); + current_ev =3D iwe_stream_add_point(current_ev, end_buf, + &iwe, buf); + kfree(buf); + } + } + return current_ev; +} + +int +prism54_get_scan(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int i, rvalue; + struct obj_bsslist *bsslist; + u32 noise =3D 0; + char *current_ev =3D extra; + union oid_res_t r; + + if (islpci_get_state(priv) < PRV_STATE_INIT) { + /* device is not ready, fail gently */ + dwrq->length =3D 0; + return 0; + } + + /* first get the noise value. We will use it to report the link quality */ + rvalue =3D mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); + noise =3D r.u; + + /* Ask the device for a list of known bss. We can report at most + * IW_MAX_AP=3D64 to the range struct. But the device won't repport anyth= ing + * if you change the value of IWMAX_BSS=3D24. + */ + rvalue |=3D mgt_get_request(priv, DOT11_OID_BSSLIST, 0, NULL, &r); + bsslist =3D r.ptr; + + /* ok now, scan the list and translate its info */ + for (i =3D 0; i < min(IW_MAX_AP, (int) bsslist->nr); i++) + current_ev =3D prism54_translate_bss(ndev, current_ev, + extra + IW_SCAN_MAX_DATA, + &(bsslist->bsslist[i]), + noise); + kfree(bsslist); + dwrq->length =3D (current_ev - extra); + dwrq->flags =3D 0; /* todo */ + + return rvalue; +} + +static int +prism54_set_essid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_ssid essid; + + memset(essid.octets, 0, 33); + + /* Check if we were asked for `any' */ + if (dwrq->flags && dwrq->length) { + if (dwrq->length > min(33, IW_ESSID_MAX_SIZE + 1)) + return -E2BIG; + essid.length =3D dwrq->length - 1; + memcpy(essid.octets, extra, dwrq->length); + } else + essid.length =3D 0; + + if (priv->iw_mode !=3D IW_MODE_MONITOR) + return mgt_set_request(priv, DOT11_OID_SSID, 0, &essid); + + /* If in monitor mode, just save to mib */ + mgt_set(priv, DOT11_OID_SSID, &essid); + return 0; + +} + +static int +prism54_get_essid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_ssid *essid; + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_SSID, 0, NULL, &r); + essid =3D r.ptr; + + if (essid->length) { + dwrq->flags =3D 1; /* set ESSID to ON for Wireless Extensions */ + /* if it is to big, trunk it */ + dwrq->length =3D min(IW_ESSID_MAX_SIZE, essid->length + 1); + } else { + dwrq->flags =3D 0; + dwrq->length =3D 0; + } + essid->octets[essid->length] =3D '\0'; + memcpy(extra, essid->octets, dwrq->length); + kfree(essid); + + return rvalue; +} + +/* Provides no functionality, just completes the ioctl. In essence this is= a=20 + * just a cosmetic ioctl. + */ +static int +prism54_set_nick(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + if (dwrq->length > IW_ESSID_MAX_SIZE) + return -E2BIG; + + down_write(&priv->mib_sem); + memset(priv->nickname, 0, sizeof (priv->nickname)); + memcpy(priv->nickname, extra, dwrq->length); + up_write(&priv->mib_sem); + + return 0; +} + +static int +prism54_get_nick(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + dwrq->length =3D 0; + + down_read(&priv->mib_sem); + dwrq->length =3D strlen(priv->nickname) + 1; + memcpy(extra, priv->nickname, dwrq->length); + up_read(&priv->mib_sem); + + return 0; +} + +/* Set the allowed Bitrates */ + +static int +prism54_set_rate(struct net_device *ndev, + struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + + islpci_private *priv =3D netdev_priv(ndev); + u32 rate, profile; + char *data; + int ret, i; + union oid_res_t r; + + if (vwrq->value =3D=3D -1) { + /* auto mode. No limit. */ + profile =3D 1; + return mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); + } + + if ((ret =3D + mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r))) + return ret; + + rate =3D (u32) (vwrq->value / 500000); + data =3D r.ptr; + i =3D 0; + + while (data[i]) { + if (rate && (data[i] =3D=3D rate)) { + break; + } + if (vwrq->value =3D=3D i) { + break; + } + data[i] |=3D 0x80; + i++; + } + + if (!data[i]) { + return -EINVAL; + } + + data[i] |=3D 0x80; + data[i + 1] =3D 0; + + /* Now, check if we want a fixed or auto value */ + if (vwrq->fixed) { + data[0] =3D data[i]; + data[1] =3D 0; + } + +/* + i =3D 0; + printk("prism54 rate: "); + while(data[i]) { + printk("%u ", data[i]); + i++; + } + printk("0\n"); +*/ + profile =3D -1; + ret =3D mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); + ret |=3D mgt_set_request(priv, DOT11_OID_EXTENDEDRATES, 0, data); + ret |=3D mgt_set_request(priv, DOT11_OID_RATES, 0, data); + + kfree(r.ptr); + + return ret; +} + +/* Get the current bit rate */ +static int +prism54_get_rate(struct net_device *ndev, + struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue; + char *data; + union oid_res_t r; + + /* Get the current bit rate */ + if ((rvalue =3D mgt_get_request(priv, GEN_OID_LINKSTATE, 0, NULL, &r))) + return rvalue; + vwrq->value =3D r.u * 500000; + + /* request the device for the enabled rates */ + if ((rvalue =3D mgt_get_request(priv, DOT11_OID_RATES, 0, NULL, &r))) + return rvalue; + data =3D r.ptr; + vwrq->fixed =3D (data[0] !=3D 0) && (data[1] =3D=3D 0); + kfree(r.ptr); + + return 0; +} + +static int +prism54_set_rts(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + return mgt_set_request(priv, DOT11_OID_RTSTHRESH, 0, &vwrq->value); +} + +static int +prism54_get_rts(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + /* get the rts threshold */ + rvalue =3D mgt_get_request(priv, DOT11_OID_RTSTHRESH, 0, NULL, &r); + vwrq->value =3D r.u; + + return rvalue; +} + +static int +prism54_set_frag(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + return mgt_set_request(priv, DOT11_OID_FRAGTHRESH, 0, &vwrq->value); +} + +static int +prism54_get_frag(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, DOT11_OID_FRAGTHRESH, 0, NULL, &r); + vwrq->value =3D r.u; + + return rvalue; +} + +/* Here we have (min,max) =3D max retries for (small frames, big frames). = Where + * big frame <=3D> bigger than the rts threshold + * small frame <=3D> smaller than the rts threshold + * This is not really the behavior expected by the wireless tool but it se= ems + * to be a common behavior in other drivers. + */ + +static int +prism54_set_retry(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 slimit =3D 0, llimit =3D 0; /* short and long limit */ + u32 lifetime =3D 0; + int rvalue =3D 0; + + if (vwrq->disabled) + /* we cannot disable this feature */ + return -EINVAL; + + if (vwrq->flags & IW_RETRY_LIMIT) { + if (vwrq->flags & IW_RETRY_MIN) + slimit =3D vwrq->value; + else if (vwrq->flags & IW_RETRY_MAX) + llimit =3D vwrq->value; + else { + /* we are asked to set both */ + slimit =3D vwrq->value; + llimit =3D vwrq->value; + } + } + if (vwrq->flags & IW_RETRY_LIFETIME) + /* Wireless tools use us unit while the device uses 1024 us unit */ + lifetime =3D vwrq->value / 1024; + + /* now set what is requested */ + if (slimit) + rvalue =3D + mgt_set_request(priv, DOT11_OID_SHORTRETRIES, 0, &slimit); + if (llimit) + rvalue |=3D + mgt_set_request(priv, DOT11_OID_LONGRETRIES, 0, &llimit); + if (lifetime) + rvalue |=3D + mgt_set_request(priv, DOT11_OID_MAXTXLIFETIME, 0, + &lifetime); + return rvalue; +} + +static int +prism54_get_retry(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue =3D 0; + vwrq->disabled =3D 0; /* It cannot be disabled */ + + if ((vwrq->flags & IW_RETRY_TYPE) =3D=3D IW_RETRY_LIFETIME) { + /* we are asked for the life time */ + rvalue =3D + mgt_get_request(priv, DOT11_OID_MAXTXLIFETIME, 0, NULL, &r); + vwrq->value =3D r.u * 1024; + vwrq->flags =3D IW_RETRY_LIFETIME; + } else if ((vwrq->flags & IW_RETRY_MAX)) { + /* we are asked for the long retry limit */ + rvalue |=3D + mgt_get_request(priv, DOT11_OID_LONGRETRIES, 0, NULL, &r); + vwrq->value =3D r.u; + vwrq->flags =3D IW_RETRY_LIMIT | IW_RETRY_MAX; + } else { + /* default. get the short retry limit */ + rvalue |=3D + mgt_get_request(priv, DOT11_OID_SHORTRETRIES, 0, NULL, &r); + vwrq->value =3D r.u; + vwrq->flags =3D IW_RETRY_LIMIT | IW_RETRY_MIN; + } + + return rvalue; +} + +static int +prism54_set_encode(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + int rvalue =3D 0, force =3D 0; + int authen =3D DOT11_AUTH_OS, invoke =3D 0, exunencrypt =3D 0; + union oid_res_t r; + + /* with the new API, it's impossible to get a NULL pointer. + * New version of iwconfig set the IW_ENCODE_NOKEY flag + * when no key is given, but older versions don't. */ + + if (dwrq->length > 0) { + /* we have a key to set */ + int index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + int current_index; + struct obj_key key =3D { DOT11_PRIV_WEP, 0, "" }; + + /* get the current key index */ + rvalue =3D mgt_get_request(priv, DOT11_OID_DEFKEYID, 0, NULL, &r); + current_index =3D r.u; + /* Verify that the key is not marked as invalid */ + if (!(dwrq->flags & IW_ENCODE_NOKEY)) { + key.length =3D dwrq->length > sizeof (key.key) ? + sizeof (key.key) : dwrq->length; + memcpy(key.key, extra, key.length); + if (key.length =3D=3D 32) + /* we want WPA-PSK */ + key.type =3D DOT11_PRIV_TKIP; + if ((index < 0) || (index > 3)) + /* no index provided use the current one */ + index =3D current_index; + + /* now send the key to the card */ + rvalue |=3D + mgt_set_request(priv, DOT11_OID_DEFKEYX, index, + &key); + } + /* + * If a valid key is set, encryption should be enabled=20 + * (user may turn it off later). + * This is also how "iwconfig ethX key on" works + */ + if ((index =3D=3D current_index) && (key.length > 0)) + force =3D 1; + } else { + int index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + if ((index >=3D 0) && (index <=3D 3)) { + /* we want to set the key index */ + rvalue |=3D + mgt_set_request(priv, DOT11_OID_DEFKEYID, 0, + &index); + } else { + if (!dwrq->flags & IW_ENCODE_MODE) { + /* we cannot do anything. Complain. */ + return -EINVAL; + } + } + } + /* now read the flags */ + if (dwrq->flags & IW_ENCODE_DISABLED) { + /* Encoding disabled,=20 + * authen =3D DOT11_AUTH_OS; + * invoke =3D 0; + * exunencrypt =3D 0; */ + } + if (dwrq->flags & IW_ENCODE_OPEN) + /* Encode but accept non-encoded packets. No auth */ + invoke =3D 1; + if ((dwrq->flags & IW_ENCODE_RESTRICTED) || force) { + /* Refuse non-encoded packets. Auth */ + authen =3D DOT11_AUTH_BOTH; + invoke =3D 1; + exunencrypt =3D 1; + } + /* do the change if requested */ + if ((dwrq->flags & IW_ENCODE_MODE) || force) { + rvalue |=3D + mgt_set_request(priv, DOT11_OID_AUTHENABLE, 0, &authen); + rvalue |=3D + mgt_set_request(priv, DOT11_OID_PRIVACYINVOKED, 0, &invoke); + rvalue |=3D + mgt_set_request(priv, DOT11_OID_EXUNENCRYPTED, 0, + &exunencrypt); + } + return rvalue; +} + +static int +prism54_get_encode(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct obj_key *key; + u32 devindex, index =3D (dwrq->flags & IW_ENCODE_INDEX) - 1; + u32 authen =3D 0, invoke =3D 0, exunencrypt =3D 0; + int rvalue; + union oid_res_t r; + + /* first get the flags */ + rvalue =3D mgt_get_request(priv, DOT11_OID_AUTHENABLE, 0, NULL, &r); + authen =3D r.u; + rvalue |=3D mgt_get_request(priv, DOT11_OID_PRIVACYINVOKED, 0, NULL, &r); + invoke =3D r.u; + rvalue |=3D mgt_get_request(priv, DOT11_OID_EXUNENCRYPTED, 0, NULL, &r); + exunencrypt =3D r.u; + + if (invoke && (authen =3D=3D DOT11_AUTH_BOTH) && exunencrypt) + dwrq->flags =3D IW_ENCODE_RESTRICTED; + else if ((authen =3D=3D DOT11_AUTH_OS) && !exunencrypt) { + if (invoke) + dwrq->flags =3D IW_ENCODE_OPEN; + else + dwrq->flags =3D IW_ENCODE_DISABLED; + } else + /* The card should not work in this state */ + dwrq->flags =3D 0; + + /* get the current device key index */ + rvalue |=3D mgt_get_request(priv, DOT11_OID_DEFKEYID, 0, NULL, &r); + devindex =3D r.u; + /* Now get the key, return it */ + if ((index < 0) || (index > 3)) + /* no index provided, use the current one */ + index =3D devindex; + rvalue |=3D mgt_get_request(priv, DOT11_OID_DEFKEYX, index, NULL, &r); + key =3D r.ptr; + dwrq->length =3D key->length; + memcpy(extra, key->key, dwrq->length); + kfree(key); + /* return the used key index */ + dwrq->flags |=3D devindex + 1; + + return rvalue; +} + +static int +prism54_get_txpower(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + union oid_res_t r; + int rvalue; + + rvalue =3D mgt_get_request(priv, OID_INL_OUTPUTPOWER, 0, NULL, &r); + /* intersil firmware operates in 0.25 dBm (1/4 dBm) */ + vwrq->value =3D (s32) r.u / 4; + vwrq->fixed =3D 1; + /* radio is not turned of + * btw: how is possible to turn off only the radio=20 + */ + vwrq->disabled =3D 0; + + return rvalue; +} + +static int +prism54_set_txpower(struct net_device *ndev, struct iw_request_info *info, + struct iw_param *vwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + s32 u =3D vwrq->value; + + /* intersil firmware operates in 0.25 dBm (1/4) */ + u *=3D 4; + if (vwrq->disabled) { + /* don't know how to disable radio */ + printk(KERN_DEBUG + "%s: %s() disabling radio is not yet supported.\n", + priv->ndev->name, __FUNCTION__); + return -ENOTSUPP; + } else if (vwrq->fixed) + /* currently only fixed value is supported */ + return mgt_set_request(priv, OID_INL_OUTPUTPOWER, 0, &u); + else { + printk(KERN_DEBUG + "%s: %s() auto power will be implemented later.\n", + priv->ndev->name, __FUNCTION__); + return -ENOTSUPP; + } +} + +static int +prism54_reset(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_reset(netdev_priv(ndev), 0); + + return 0; +} + +static int +prism54_get_oid(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + union oid_res_t r; + int rvalue; + enum oid_num_t n =3D dwrq->flags; + + rvalue =3D mgt_get_request((islpci_private *) ndev->priv, n, 0, NULL, &r); + dwrq->length =3D mgt_response_to_str(n, &r, extra); + if ((isl_oid[n].flags & OID_FLAG_TYPE) !=3D OID_TYPE_U32) + kfree(r.ptr); + return rvalue; +} + +static int +prism54_set_u32(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + u32 oid =3D uwrq[0], u =3D uwrq[1]; + + return mgt_set_request((islpci_private *) ndev->priv, oid, 0, &u); +} + +static int +prism54_set_raw(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + u32 oid =3D dwrq->flags; + + return mgt_set_request((islpci_private *) ndev->priv, oid, 0, extra); +} + +void +prism54_acl_init(struct islpci_acl *acl) +{ + sema_init(&acl->sem, 1); + INIT_LIST_HEAD(&acl->mac_list); + acl->size =3D 0; + acl->policy =3D MAC_POLICY_OPEN; +} + +static void +prism54_clear_mac(struct islpci_acl *acl) +{ + struct list_head *ptr, *next; + struct mac_entry *entry; + + if (down_interruptible(&acl->sem)) + return; + + if (acl->size =3D=3D 0) { + up(&acl->sem); + return; + } + + for (ptr =3D acl->mac_list.next, next =3D ptr->next; + ptr !=3D &acl->mac_list; ptr =3D next, next =3D ptr->next) { + entry =3D list_entry(ptr, struct mac_entry, _list); + list_del(ptr); + kfree(entry); + } + acl->size =3D 0; + up(&acl->sem); +} + +void +prism54_acl_clean(struct islpci_acl *acl) +{ + prism54_clear_mac(acl); +} + +static int +prism54_add_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct sockaddr *addr =3D (struct sockaddr *) extra; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + entry =3D kmalloc(sizeof (struct mac_entry), GFP_KERNEL); + if (entry =3D=3D NULL) + return -ENOMEM; + + memcpy(entry->addr, addr->sa_data, ETH_ALEN); + + if (down_interruptible(&acl->sem)) { + kfree(entry); + return -ERESTARTSYS; + } + list_add_tail(&entry->_list, &acl->mac_list); + acl->size++; + up(&acl->sem); + + return 0; +} + +static int +prism54_del_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct list_head *ptr; + struct sockaddr *addr =3D (struct sockaddr *) extra; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + + if (memcmp(entry->addr, addr->sa_data, ETH_ALEN) =3D=3D 0) { + list_del(ptr); + acl->size--; + kfree(entry); + up(&acl->sem); + return 0; + } + } + up(&acl->sem); + return -EINVAL; +} + +static int +prism54_get_mac(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + struct mac_entry *entry; + struct list_head *ptr; + struct sockaddr *dst =3D (struct sockaddr *) extra; + + dwrq->length =3D 0; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + + memcpy(dst->sa_data, entry->addr, ETH_ALEN); + dst->sa_family =3D ARPHRD_ETHER; + dwrq->length++; + dst++; + } + up(&acl->sem); + return 0; +} + +/* Setting policy also clears the MAC acl, even if we don't change the def= aut + * policy + */ + +static int +prism54_set_policy(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + u32 mlmeautolevel; + + prism54_clear_mac(acl); + + if ((*uwrq < MAC_POLICY_OPEN) || (*uwrq > MAC_POLICY_REJECT)) + return -EINVAL; + + down_write(&priv->mib_sem); + + acl->policy =3D *uwrq; + + /* the ACL code needs an intermediate mlmeautolevel */ + if ((priv->iw_mode =3D=3D IW_MODE_MASTER) && + (acl->policy !=3D MAC_POLICY_OPEN)) + mlmeautolevel =3D DOT11_MLME_INTERMEDIATE; + else + mlmeautolevel =3D CARD_DEFAULT_MLME_MODE; + if (priv->wpa) + mlmeautolevel =3D DOT11_MLME_EXTENDED; + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &mlmeautolevel); + /* restart the card with our new policy */ + mgt_commit(priv); + up_write(&priv->mib_sem); + + return 0; +} + +static int +prism54_get_policy(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_acl *acl =3D &priv->acl; + + *uwrq =3D acl->policy; + + return 0; +} + +/* Return 1 only if client should be accepted. */ + +static int +prism54_mac_accept(struct islpci_acl *acl, char *mac) +{ + struct list_head *ptr; + struct mac_entry *entry; + int res =3D 0; + + if (down_interruptible(&acl->sem)) + return -ERESTARTSYS; + + if (acl->policy =3D=3D MAC_POLICY_OPEN) { + up(&acl->sem); + return 1; + } + + for (ptr =3D acl->mac_list.next; ptr !=3D &acl->mac_list; ptr =3D ptr->ne= xt) { + entry =3D list_entry(ptr, struct mac_entry, _list); + if (memcmp(entry->addr, mac, ETH_ALEN) =3D=3D 0) { + res =3D 1; + break; + } + } + res =3D (acl->policy =3D=3D MAC_POLICY_ACCEPT) ? !res : res; + up(&acl->sem); + + return res; +} + +static int +prism54_kick_all(struct net_device *ndev, struct iw_request_info *info, + struct iw_point *dwrq, char *extra) +{ + struct obj_mlme *mlme; + int rvalue; + + mlme =3D kmalloc(sizeof (struct obj_mlme), GFP_KERNEL); + if (mlme =3D=3D NULL) + return -ENOMEM; + + /* Tell the card to kick every client */ + mlme->id =3D 0; + rvalue =3D + mgt_set_request(netdev_priv(ndev), DOT11_OID_DISASSOCIATE, 0, mlme); + kfree(mlme); + + return rvalue; +} + +static int +prism54_kick_mac(struct net_device *ndev, struct iw_request_info *info, + struct sockaddr *awrq, char *extra) +{ + struct obj_mlme *mlme; + struct sockaddr *addr =3D (struct sockaddr *) extra; + int rvalue; + + if (addr->sa_family !=3D ARPHRD_ETHER) + return -EOPNOTSUPP; + + mlme =3D kmalloc(sizeof (struct obj_mlme), GFP_KERNEL); + if (mlme =3D=3D NULL) + return -ENOMEM; + + /* Tell the card to only kick the corresponding bastard */ + memcpy(mlme->address, addr->sa_data, ETH_ALEN); + mlme->id =3D -1; + rvalue =3D + mgt_set_request(netdev_priv(ndev), DOT11_OID_DISASSOCIATE, 0, mlme); + + kfree(mlme); + + return rvalue; +} + +/* Translate a TRAP oid into a wireless event. Called in islpci_mgt_receiv= e. */ + +static void +format_event(islpci_private *priv, char *dest, const char *str, + const struct obj_mlme *mlme, u16 *length, int error) +{ + const u8 *a =3D mlme->address; + int n =3D snprintf(dest, IW_CUSTOM_MAX, + "%s %s %2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X %s (%2.2X)", + str, + ((priv->iw_mode =3D=3D IW_MODE_MASTER) ? "from" : "to"), + a[0], a[1], a[2], a[3], a[4], a[5], + (error ? (mlme->code ? " : REJECTED " : " : ACCEPTED ") + : ""), mlme->code); + BUG_ON(n > IW_CUSTOM_MAX); + *length =3D n; +} + +static void +send_formatted_event(islpci_private *priv, const char *str, + const struct obj_mlme *mlme, int error) +{ + union iwreq_data wrqu; + + wrqu.data.pointer =3D kmalloc(IW_CUSTOM_MAX, GFP_KERNEL); + if (!wrqu.data.pointer) + return; + wrqu.data.length =3D 0; + format_event(priv, wrqu.data.pointer, str, mlme, &wrqu.data.length, + error); + wireless_send_event(priv->ndev, IWEVCUSTOM, &wrqu, wrqu.data.pointer); + kfree(wrqu.data.pointer); +} + +static void +send_simple_event(islpci_private *priv, const char *str) +{ + union iwreq_data wrqu; + int n =3D strlen(str); + + wrqu.data.pointer =3D kmalloc(IW_CUSTOM_MAX, GFP_KERNEL); + if (!wrqu.data.pointer) + return; + BUG_ON(n > IW_CUSTOM_MAX); + wrqu.data.length =3D n; + strcpy(wrqu.data.pointer, str); + wireless_send_event(priv->ndev, IWEVCUSTOM, &wrqu, wrqu.data.pointer); + kfree(wrqu.data.pointer); +} + +static void +link_changed(struct net_device *ndev, u32 bitrate) +{ + islpci_private *priv =3D netdev_priv(ndev); + + if (bitrate) { + if (priv->iw_mode =3D=3D IW_MODE_INFRA) { + union iwreq_data uwrq; + prism54_get_wap(ndev, NULL, (struct sockaddr *) &uwrq, + NULL); + wireless_send_event(ndev, SIOCGIWAP, &uwrq, NULL); + } else + send_simple_event(netdev_priv(ndev), + "Link established"); + } else + send_simple_event(netdev_priv(ndev), "Link lost"); +} + +/* Beacon/ProbeResp payload header */ +struct ieee80211_beacon_phdr { + u8 timestamp[8]; + u16 beacon_int; + u16 capab_info; +} __attribute__ ((packed)); + +#define WLAN_EID_GENERIC 0xdd +static u8 wpa_oid[4] =3D { 0x00, 0x50, 0xf2, 1 }; + +#define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5] +#define MACSTR "%02x:%02x:%02x:%02x:%02x:%02x" + +void +prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len) +{ + struct list_head *ptr; + struct islpci_bss_wpa_ie *bss =3D NULL; + + if (wpa_ie_len > MAX_WPA_IE_LEN) + wpa_ie_len =3D MAX_WPA_IE_LEN; + + if (down_interruptible(&priv->wpa_sem)) + return; + + /* try to use existing entry */ + list_for_each(ptr, &priv->bss_wpa_list) { + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + if (memcmp(bss->bssid, bssid, ETH_ALEN) =3D=3D 0) { + list_move(&bss->list, &priv->bss_wpa_list); + break; + } + bss =3D NULL; + } + + if (bss =3D=3D NULL) { + /* add a new BSS entry; if max number of entries is already + * reached, replace the least recently updated */ + if (priv->num_bss_wpa >=3D MAX_BSS_WPA_IE_COUNT) { + bss =3D list_entry(priv->bss_wpa_list.prev, + struct islpci_bss_wpa_ie, list); + list_del(&bss->list); + } else { + bss =3D kmalloc(sizeof (*bss), GFP_ATOMIC); + if (bss !=3D NULL) { + priv->num_bss_wpa++; + memset(bss, 0, sizeof (*bss)); + } + } + if (bss !=3D NULL) { + memcpy(bss->bssid, bssid, ETH_ALEN); + list_add(&bss->list, &priv->bss_wpa_list); + } + } + + if (bss !=3D NULL) { + memcpy(bss->wpa_ie, wpa_ie, wpa_ie_len); + bss->wpa_ie_len =3D wpa_ie_len; + bss->last_update =3D jiffies; + } else { + printk(KERN_DEBUG "Failed to add BSS WPA entry for " MACSTR + "\n", MAC2STR(bssid)); + } + + /* expire old entries from WPA list */ + while (priv->num_bss_wpa > 0) { + bss =3D list_entry(priv->bss_wpa_list.prev, + struct islpci_bss_wpa_ie, list); + if (!time_after(jiffies, bss->last_update + 60 * HZ)) + break; + + list_del(&bss->list); + priv->num_bss_wpa--; + kfree(bss); + } + + up(&priv->wpa_sem); +} + +size_t +prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie) +{ + struct list_head *ptr; + struct islpci_bss_wpa_ie *bss =3D NULL; + size_t len =3D 0; + + if (down_interruptible(&priv->wpa_sem)) + return 0; + + list_for_each(ptr, &priv->bss_wpa_list) { + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + if (memcmp(bss->bssid, bssid, ETH_ALEN) =3D=3D 0) + break; + bss =3D NULL; + } + if (bss) { + len =3D bss->wpa_ie_len; + memcpy(wpa_ie, bss->wpa_ie, len); + } + up(&priv->wpa_sem); + + return len; +} + +void +prism54_wpa_ie_init(islpci_private *priv) +{ + INIT_LIST_HEAD(&priv->bss_wpa_list); + sema_init(&priv->wpa_sem, 1); +} + +void +prism54_wpa_ie_clean(islpci_private *priv) +{ + struct list_head *ptr, *n; + + list_for_each_safe(ptr, n, &priv->bss_wpa_list) { + struct islpci_bss_wpa_ie *bss; + bss =3D list_entry(ptr, struct islpci_bss_wpa_ie, list); + kfree(bss); + } +} + +static void +prism54_process_bss_data(islpci_private *priv, u32 oid, u8 *addr, + u8 *payload, size_t len) +{ + struct ieee80211_beacon_phdr *hdr; + u8 *pos, *end; + + if (!priv->wpa) + return; + + hdr =3D (struct ieee80211_beacon_phdr *) payload; + pos =3D (u8 *) (hdr + 1); + end =3D payload + len; + while (pos < end) { + if (pos + 2 + pos[1] > end) { + printk(KERN_DEBUG "Parsing Beacon/ProbeResp failed " + "for " MACSTR "\n", MAC2STR(addr)); + return; + } + if (pos[0] =3D=3D WLAN_EID_GENERIC && pos[1] >=3D 4 && + memcmp(pos + 2, wpa_oid, 4) =3D=3D 0) { + prism54_wpa_ie_add(priv, addr, pos, pos[1] + 2); + return; + } + pos +=3D 2 + pos[1]; + } +} + +static void +handle_request(islpci_private *priv, struct obj_mlme *mlme, enum oid_num_t= oid) +{ + if (((mlme->state =3D=3D DOT11_STATE_AUTHING) || + (mlme->state =3D=3D DOT11_STATE_ASSOCING)) + && mgt_mlme_answer(priv)) { + /* Someone is requesting auth and we must respond. Just send back + * the trap with error code set accordingly. + */ + mlme->code =3D prism54_mac_accept(&priv->acl, + mlme->address) ? 0 : 1; + mgt_set_request(priv, oid, 0, mlme); + } +} + +int +prism54_process_trap_helper(islpci_private *priv, enum oid_num_t oid, + char *data) +{ + struct obj_mlme *mlme =3D (struct obj_mlme *) data; + size_t len; + u8 *payload, *pos =3D (u8 *) (mlme + 1); + + len =3D pos[0] | (pos[1] << 8); /* little endian data length */ + payload =3D pos + 2; + + /* I think all trapable objects are listed here. + * Some oids have a EX version. The difference is that they are emitted + * in DOT11_MLME_EXTENDED mode (set with DOT11_OID_MLMEAUTOLEVEL) + * with more info. + * The few events already defined by the wireless tools are not really + * suited. We use the more flexible custom event facility. + */ + + /* I fear prism54_process_bss_data won't work with big endian data */ + if ((oid =3D=3D DOT11_OID_BEACON) || (oid =3D=3D DOT11_OID_PROBE)) + prism54_process_bss_data(priv, oid, mlme->address, + payload, len); + + mgt_le_to_cpu(isl_oid[oid].flags & OID_FLAG_TYPE, (void *) mlme); + + switch (oid) { + + case GEN_OID_LINKSTATE: + link_changed(priv->ndev, (u32) *data); + break; + + case DOT11_OID_MICFAILURE: + send_simple_event(priv, "Mic failure"); + break; + + case DOT11_OID_DEAUTHENTICATE: + send_formatted_event(priv, "DeAuthenticate request", mlme, 0); + break; + + case DOT11_OID_AUTHENTICATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Authenticate request", mlme, 1); + break; + + case DOT11_OID_DISASSOCIATE: + send_formatted_event(priv, "Disassociate request", mlme, 0); + break; + + case DOT11_OID_ASSOCIATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Associate request", mlme, 1); + break; + + case DOT11_OID_REASSOCIATE: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "ReAssociate request", mlme, 1); + break; + + case DOT11_OID_BEACON: + send_formatted_event(priv, + "Received a beacon from an unkown AP", + mlme, 0); + break; + + case DOT11_OID_PROBE: + /* we received a probe from a client. */ + send_formatted_event(priv, "Received a probe from client", mlme, + 0); + break; + + /* Note : "mlme" is actually a "struct obj_mlmeex *" here, but this + * is backward compatible layout-wise with "struct obj_mlme". + */ + + case DOT11_OID_DEAUTHENTICATEEX: + send_formatted_event(priv, "DeAuthenticate request", mlme, 0); + break; + + case DOT11_OID_AUTHENTICATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Authenticate request", mlme, 1); + break; + + case DOT11_OID_DISASSOCIATEEX: + send_formatted_event(priv, "Disassociate request", mlme, 0); + break; + + case DOT11_OID_ASSOCIATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Associate request", mlme, 1); + break; + + case DOT11_OID_REASSOCIATEEX: + handle_request(priv, mlme, oid); + send_formatted_event(priv, "Reassociate request", mlme, 1); + break; + + default: + return -EINVAL; + } + + return 0; +} + +/* + * Process a device trap. This is called via schedule_work(), outside of + * interrupt context, no locks held. + */ +void +prism54_process_trap(void *data) +{ + struct islpci_mgmtframe *frame =3D data; + struct net_device *ndev =3D frame->ndev; + enum oid_num_t n =3D mgt_oidtonum(frame->header->oid); + + if (n !=3D OID_NUM_LAST) + prism54_process_trap_helper(netdev_priv(ndev), n, frame->data); + islpci_mgt_release(frame); +} + +int +prism54_set_mac_address(struct net_device *ndev, void *addr) +{ + islpci_private *priv =3D netdev_priv(ndev); + int ret; + + if (ndev->addr_len !=3D 6) + return -EINVAL; + ret =3D mgt_set_request(priv, GEN_OID_MACADDRESS, 0, + &((struct sockaddr *) addr)->sa_data); + if (!ret) + memcpy(priv->ndev->dev_addr, + &((struct sockaddr *) addr)->sa_data, 6); + + return ret; +} + +int +prism54_set_wpa(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + down_write(&priv->mib_sem); + + priv->wpa =3D *uwrq; + if (priv->wpa) { + u32 l =3D DOT11_MLME_EXTENDED; + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &l); + } + /* restart the card with new level. Needed ? */ + mgt_commit(priv); + up_write(&priv->mib_sem); + + return 0; +} + +int +prism54_get_wpa(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + *uwrq =3D priv->wpa; + return 0; +} + +int +prism54_set_prismhdr(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + priv->monitor_type =3D + (*uwrq ? ARPHRD_IEEE80211_PRISM : ARPHRD_IEEE80211); + if (priv->iw_mode =3D=3D IW_MODE_MONITOR) + priv->ndev->type =3D priv->monitor_type; + + return 0; +} + +int +prism54_get_prismhdr(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + *uwrq =3D (priv->monitor_type =3D=3D ARPHRD_IEEE80211_PRISM); + return 0; +} + +int +prism54_debug_oid(struct net_device *ndev, struct iw_request_info *info, + __u32 * uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + + priv->priv_oid =3D *uwrq; + printk("%s: oid 0x%08X\n", ndev->name, *uwrq); + + return 0; +} + +int +prism54_debug_get_oid(struct net_device *ndev, struct iw_request_info *inf= o, + struct iw_point *data, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_mgmtframe *response =3D NULL; + int ret =3D -EIO, response_op =3D PIMFOR_OP_ERROR; + + printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); + data->length =3D 0; + + if (islpci_get_state(priv) >=3D PRV_STATE_INIT) { + ret =3D + islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + priv->priv_oid, extra, 256, + &response); + response_op =3D response->header->operation; + printk("%s: ret: %i\n", ndev->name, ret); + printk("%s: response_op: %i\n", ndev->name, response_op); + if (ret || !response + || response->header->operation =3D=3D PIMFOR_OP_ERROR) { + if (response) { + islpci_mgt_release(response); + } + printk("%s: EIO\n", ndev->name); + ret =3D -EIO; + } + if (!ret) { + data->length =3D response->header->length; + memcpy(extra, response->data, data->length); + islpci_mgt_release(response); + printk("%s: len: %i\n", ndev->name, data->length); + } + } + + return ret; +} + +int +prism54_debug_set_oid(struct net_device *ndev, struct iw_request_info *inf= o, + struct iw_point *data, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct islpci_mgmtframe *response =3D NULL; + int ret =3D 0, response_op =3D PIMFOR_OP_ERROR; + + printk("%s: set_oid 0x%08X\tlen: %d\n", ndev->name, priv->priv_oid, + data->length); + + if (islpci_get_state(priv) >=3D PRV_STATE_INIT) { + ret =3D + islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, + priv->priv_oid, extra, data->length, + &response); + printk("%s: ret: %i\n", ndev->name, ret); + if (!ret) { + response_op =3D response->header->operation; + printk("%s: response_op: %i\n", ndev->name, + response_op); + islpci_mgt_release(response); + } + if (ret || response_op =3D=3D PIMFOR_OP_ERROR) { + printk("%s: EIO\n", ndev->name); + ret =3D -EIO; + } + } + + return (ret ? ret : -EINPROGRESS); +} + +static int +prism54_set_spy(struct net_device *ndev, + struct iw_request_info *info, + union iwreq_data *uwrq, char *extra) +{ + islpci_private *priv =3D netdev_priv(ndev); + u32 u, oid =3D OID_INL_CONFIG; + + down_write(&priv->mib_sem); + mgt_get(priv, OID_INL_CONFIG, &u); + + if ((uwrq->data.length =3D=3D 0) && (priv->spy_data.spy_number > 0)) + /* disable spy */ + u &=3D ~INL_CONFIG_RXANNEX; + else if ((uwrq->data.length > 0) && (priv->spy_data.spy_number =3D=3D 0)) + /* enable spy */ + u |=3D INL_CONFIG_RXANNEX; + + mgt_set(priv, OID_INL_CONFIG, &u); + mgt_commit_list(priv, &oid, 1); + up_write(&priv->mib_sem); + + return iw_handler_set_spy(ndev, info, uwrq, extra); +} + +static const iw_handler prism54_handler[] =3D { + (iw_handler) prism54_commit, /* SIOCSIWCOMMIT */ + (iw_handler) prism54_get_name, /* SIOCGIWNAME */ + (iw_handler) NULL, /* SIOCSIWNWID */ + (iw_handler) NULL, /* SIOCGIWNWID */ + (iw_handler) prism54_set_freq, /* SIOCSIWFREQ */ + (iw_handler) prism54_get_freq, /* SIOCGIWFREQ */ + (iw_handler) prism54_set_mode, /* SIOCSIWMODE */ + (iw_handler) prism54_get_mode, /* SIOCGIWMODE */ + (iw_handler) prism54_set_sens, /* SIOCSIWSENS */ + (iw_handler) prism54_get_sens, /* SIOCGIWSENS */ + (iw_handler) NULL, /* SIOCSIWRANGE */ + (iw_handler) prism54_get_range, /* SIOCGIWRANGE */ + (iw_handler) NULL, /* SIOCSIWPRIV */ + (iw_handler) NULL, /* SIOCGIWPRIV */ + (iw_handler) NULL, /* SIOCSIWSTATS */ + (iw_handler) NULL, /* SIOCGIWSTATS */ + prism54_set_spy, /* SIOCSIWSPY */ + iw_handler_get_spy, /* SIOCGIWSPY */ + iw_handler_set_thrspy, /* SIOCSIWTHRSPY */ + iw_handler_get_thrspy, /* SIOCGIWTHRSPY */ + (iw_handler) prism54_set_wap, /* SIOCSIWAP */ + (iw_handler) prism54_get_wap, /* SIOCGIWAP */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) NULL, /* SIOCGIWAPLIST depreciated */ + (iw_handler) prism54_set_scan, /* SIOCSIWSCAN */ + (iw_handler) prism54_get_scan, /* SIOCGIWSCAN */ + (iw_handler) prism54_set_essid, /* SIOCSIWESSID */ + (iw_handler) prism54_get_essid, /* SIOCGIWESSID */ + (iw_handler) prism54_set_nick, /* SIOCSIWNICKN */ + (iw_handler) prism54_get_nick, /* SIOCGIWNICKN */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) prism54_set_rate, /* SIOCSIWRATE */ + (iw_handler) prism54_get_rate, /* SIOCGIWRATE */ + (iw_handler) prism54_set_rts, /* SIOCSIWRTS */ + (iw_handler) prism54_get_rts, /* SIOCGIWRTS */ + (iw_handler) prism54_set_frag, /* SIOCSIWFRAG */ + (iw_handler) prism54_get_frag, /* SIOCGIWFRAG */ + (iw_handler) prism54_set_txpower, /* SIOCSIWTXPOW */ + (iw_handler) prism54_get_txpower, /* SIOCGIWTXPOW */ + (iw_handler) prism54_set_retry, /* SIOCSIWRETRY */ + (iw_handler) prism54_get_retry, /* SIOCGIWRETRY */ + (iw_handler) prism54_set_encode, /* SIOCSIWENCODE */ + (iw_handler) prism54_get_encode, /* SIOCGIWENCODE */ + (iw_handler) NULL, /* SIOCSIWPOWER */ + (iw_handler) NULL, /* SIOCGIWPOWER */ +}; + +/* The low order bit identify a SET (0) or a GET (1) ioctl. */ + +#define PRISM54_RESET SIOCIWFIRSTPRIV +#define PRISM54_GET_POLICY SIOCIWFIRSTPRIV+1 +#define PRISM54_SET_POLICY SIOCIWFIRSTPRIV+2 +#define PRISM54_GET_MAC SIOCIWFIRSTPRIV+3 +#define PRISM54_ADD_MAC SIOCIWFIRSTPRIV+4 + +#define PRISM54_DEL_MAC SIOCIWFIRSTPRIV+6 + +#define PRISM54_KICK_MAC SIOCIWFIRSTPRIV+8 + +#define PRISM54_KICK_ALL SIOCIWFIRSTPRIV+10 + +#define PRISM54_GET_WPA SIOCIWFIRSTPRIV+11 +#define PRISM54_SET_WPA SIOCIWFIRSTPRIV+12 + +#define PRISM54_DBG_OID SIOCIWFIRSTPRIV+14 +#define PRISM54_DBG_GET_OID SIOCIWFIRSTPRIV+15 +#define PRISM54_DBG_SET_OID SIOCIWFIRSTPRIV+16 + +#define PRISM54_GET_OID SIOCIWFIRSTPRIV+17 +#define PRISM54_SET_OID_U32 SIOCIWFIRSTPRIV+18 +#define PRISM54_SET_OID_STR SIOCIWFIRSTPRIV+20 +#define PRISM54_SET_OID_ADDR SIOCIWFIRSTPRIV+22 + +#define PRISM54_GET_PRISMHDR SIOCIWFIRSTPRIV+23 +#define PRISM54_SET_PRISMHDR SIOCIWFIRSTPRIV+24 + +#define IWPRIV_SET_U32(n,x) { n, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1= , 0, "s_"x } +#define IWPRIV_SET_SSID(n,x) { n, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED |= 1, 0, "s_"x } +#define IWPRIV_SET_ADDR(n,x) { n, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED |= 1, 0, "s_"x } +#define IWPRIV_GET(n,x) { n, 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | P= RIV_STR_SIZE, "g_"x } + +#define IWPRIV_U32(n,x) IWPRIV_SET_U32(n,x), IWPRIV_GET(n,x) +#define IWPRIV_SSID(n,x) IWPRIV_SET_SSID(n,x), IWPRIV_GET(n,x) +#define IWPRIV_ADDR(n,x) IWPRIV_SET_ADDR(n,x), IWPRIV_GET(n,x) + +/* Note : limited to 128 private ioctls (wireless tools 26) */ + +static const struct iw_priv_args prism54_private_args[] =3D { +/*{ cmd, set_args, get_args, name } */ + {PRISM54_RESET, 0, 0, "reset"}, + {PRISM54_GET_PRISMHDR, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "get_prismhdr"}, + {PRISM54_SET_PRISMHDR, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "set_prismhdr"}, + {PRISM54_GET_POLICY, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "getPolicy"}, + {PRISM54_SET_POLICY, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "setPolicy"}, + {PRISM54_GET_MAC, 0, IW_PRIV_TYPE_ADDR | 64, "getMac"}, + {PRISM54_ADD_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "addMac"}, + {PRISM54_DEL_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "delMac"}, + {PRISM54_KICK_MAC, IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, + "kickMac"}, + {PRISM54_KICK_ALL, 0, 0, "kickAll"}, + {PRISM54_GET_WPA, 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, + "get_wpa"}, + {PRISM54_SET_WPA, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "set_wpa"}, + {PRISM54_DBG_OID, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, + "dbg_oid"}, + {PRISM54_DBG_GET_OID, 0, IW_PRIV_TYPE_BYTE | 256, "dbg_get_oid"}, + {PRISM54_DBG_SET_OID, IW_PRIV_TYPE_BYTE | 256, 0, "dbg_set_oid"}, + /* --- sub-ioctls handlers --- */ + {PRISM54_GET_OID, + 0, IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | PRIV_STR_SIZE, ""}, + {PRISM54_SET_OID_U32, + IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + {PRISM54_SET_OID_STR, + IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + {PRISM54_SET_OID_ADDR, + IW_PRIV_TYPE_ADDR | IW_PRIV_SIZE_FIXED | 1, 0, ""}, + /* --- sub-ioctls definitions --- */ + IWPRIV_ADDR(GEN_OID_MACADDRESS, "addr"), + IWPRIV_GET(GEN_OID_LINKSTATE, "linkstate"), + IWPRIV_U32(DOT11_OID_BSSTYPE, "bsstype"), + IWPRIV_ADDR(DOT11_OID_BSSID, "bssid"), + IWPRIV_U32(DOT11_OID_STATE, "state"), + IWPRIV_U32(DOT11_OID_AID, "aid"), + + IWPRIV_SSID(DOT11_OID_SSIDOVERRIDE, "ssidoverride"), + + IWPRIV_U32(DOT11_OID_MEDIUMLIMIT, "medlimit"), + IWPRIV_U32(DOT11_OID_BEACONPERIOD, "beacon"), + IWPRIV_U32(DOT11_OID_DTIMPERIOD, "dtimperiod"), + + IWPRIV_U32(DOT11_OID_AUTHENABLE, "authenable"), + IWPRIV_U32(DOT11_OID_PRIVACYINVOKED, "privinvok"), + IWPRIV_U32(DOT11_OID_EXUNENCRYPTED, "exunencrypt"), + + IWPRIV_U32(DOT11_OID_REKEYTHRESHOLD, "rekeythresh"), + + IWPRIV_U32(DOT11_OID_MAXTXLIFETIME, "maxtxlife"), + IWPRIV_U32(DOT11_OID_MAXRXLIFETIME, "maxrxlife"), + IWPRIV_U32(DOT11_OID_ALOFT_FIXEDRATE, "fixedrate"), + IWPRIV_U32(DOT11_OID_MAXFRAMEBURST, "frameburst"), + IWPRIV_U32(DOT11_OID_PSM, "psm"), + + IWPRIV_U32(DOT11_OID_BRIDGELOCAL, "bridge"), + IWPRIV_U32(DOT11_OID_CLIENTS, "clients"), + IWPRIV_U32(DOT11_OID_CLIENTSASSOCIATED, "clientassoc"), + IWPRIV_U32(DOT11_OID_DOT1XENABLE, "dot1xenable"), + IWPRIV_U32(DOT11_OID_ANTENNARX, "rxant"), + IWPRIV_U32(DOT11_OID_ANTENNATX, "txant"), + IWPRIV_U32(DOT11_OID_ANTENNADIVERSITY, "antdivers"), + IWPRIV_U32(DOT11_OID_EDTHRESHOLD, "edthresh"), + IWPRIV_U32(DOT11_OID_PREAMBLESETTINGS, "preamble"), + IWPRIV_GET(DOT11_OID_RATES, "rates"), + IWPRIV_U32(DOT11_OID_OUTPUTPOWER, ".11outpower"), + IWPRIV_GET(DOT11_OID_SUPPORTEDRATES, "supprates"), + IWPRIV_GET(DOT11_OID_SUPPORTEDFREQUENCIES, "suppfreq"), + + IWPRIV_U32(DOT11_OID_NOISEFLOOR, "noisefloor"), + IWPRIV_GET(DOT11_OID_FREQUENCYACTIVITY, "freqactivity"), + IWPRIV_U32(DOT11_OID_NONERPPROTECTION, "nonerpprotec"), + IWPRIV_U32(DOT11_OID_PROFILES, "profile"), + IWPRIV_GET(DOT11_OID_EXTENDEDRATES, "extrates"), + IWPRIV_U32(DOT11_OID_MLMEAUTOLEVEL, "mlmelevel"), + + IWPRIV_GET(DOT11_OID_BSSS, "bsss"), + IWPRIV_GET(DOT11_OID_BSSLIST, "bsslist"), + IWPRIV_U32(OID_INL_MODE, "mode"), + IWPRIV_U32(OID_INL_CONFIG, "config"), + IWPRIV_U32(OID_INL_DOT11D_CONFORMANCE, ".11dconform"), + IWPRIV_GET(OID_INL_PHYCAPABILITIES, "phycapa"), + IWPRIV_U32(OID_INL_OUTPUTPOWER, "outpower"), +}; + +static const iw_handler prism54_private_handler[] =3D { + (iw_handler) prism54_reset, + (iw_handler) prism54_get_policy, + (iw_handler) prism54_set_policy, + (iw_handler) prism54_get_mac, + (iw_handler) prism54_add_mac, + (iw_handler) NULL, + (iw_handler) prism54_del_mac, + (iw_handler) NULL, + (iw_handler) prism54_kick_mac, + (iw_handler) NULL, + (iw_handler) prism54_kick_all, + (iw_handler) prism54_get_wpa, + (iw_handler) prism54_set_wpa, + (iw_handler) NULL, + (iw_handler) prism54_debug_oid, + (iw_handler) prism54_debug_get_oid, + (iw_handler) prism54_debug_set_oid, + (iw_handler) prism54_get_oid, + (iw_handler) prism54_set_u32, + (iw_handler) NULL, + (iw_handler) prism54_set_raw, + (iw_handler) NULL, + (iw_handler) prism54_set_raw, + (iw_handler) prism54_get_prismhdr, + (iw_handler) prism54_set_prismhdr, +}; + +const struct iw_handler_def prism54_handler_def =3D { + .num_standard =3D sizeof (prism54_handler) / sizeof (iw_handler), + .num_private =3D sizeof (prism54_private_handler) / sizeof (iw_handler), + .num_private_args =3D + sizeof (prism54_private_args) / sizeof (struct iw_priv_args), + .standard =3D (iw_handler *) prism54_handler, + .private =3D (iw_handler *) prism54_private_handler, + .private_args =3D (struct iw_priv_args *) prism54_private_args, + .spy_offset =3D offsetof(islpci_private, spy_data), +}; + +/* For ioctls that don't work with the new API */ + +int +prism54_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) +{ + + return -EOPNOTSUPP; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_ioctl.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_io= ctl.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_ioctl.h 1970-01-01 00:00:= 00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_ioctl.h 2004-07-2= 1 09:00:04.000000000 +0000 @@ -0,0 +1,54 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * (C) 2003 Aurelien Alleaume + * (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISL_IOCTL_H +#define _ISL_IOCTL_H + +#include "islpci_mgt.h" +#include "islpci_dev.h" + +#include /* New driver API */ + +#define SUPPORTED_WIRELESS_EXT 16 + +void prism54_mib_init(islpci_private *); + +struct iw_statistics *prism54_get_wireless_stats(struct net_device *); +void prism54_update_stats(islpci_private *); + +void prism54_acl_init(struct islpci_acl *); +void prism54_acl_clean(struct islpci_acl *); + +void prism54_process_trap(void *); + +void prism54_wpa_ie_init(islpci_private *priv); +void prism54_wpa_ie_clean(islpci_private *priv); +void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len); +size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie); + +int prism54_set_mac_address(struct net_device *, void *); + +int prism54_ioctl(struct net_device *, struct ifreq *, int); + +extern const struct iw_handler_def prism54_handler_def; + +#endif /* _ISL_IOCTL_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/isl_oid.h linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_oid.h --- linux-2.4.26/drivers/net/wireless/prism54/isl_oid.h 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/isl_oid.h 2004-07-21 = 09:00:04.000000000 +0000 @@ -0,0 +1,498 @@ +/* + * + * =20 + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2004 Luis R. Rodriguez + * Copyright (C) 2004 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#if !defined(_ISL_OID_H) +#define _ISL_OID_H + +/*=20 + * MIB related constant and structure definitions for communicating + * with the device firmware + */ + +struct obj_ssid { + u8 length; + char octets[33]; +} __attribute__ ((packed)); + +struct obj_key { + u8 type; /* dot11_priv_t */ + u8 length; + char key[32]; +} __attribute__ ((packed)); + +struct obj_mlme { + u8 address[6]; + u16 id; + u16 state; + u16 code; +} __attribute__ ((packed)); + +struct obj_mlmeex { + u8 address[6]; + u16 id; + u16 state; + u16 code; + u16 size; + u8 data[0]; +} __attribute__ ((packed)); + +struct obj_buffer { + u32 size; + u32 addr; /* 32bit bus address */ +} __attribute__ ((packed)); + +struct obj_bss { + u8 address[6]; + int:16; /* padding */ + + char state; + char reserved; + short age; + + char quality; + char rssi; + + struct obj_ssid ssid; + short channel; + char beacon_period; + char dtim_period; + short capinfo; + short rates; + short basic_rates; + int:16; /* padding */ +} __attribute__ ((packed)); + +struct obj_bsslist { + u32 nr; + struct obj_bss bsslist[0]; +} __attribute__ ((packed)); + +struct obj_frequencies { + u16 nr; + u16 mhz[0]; +} __attribute__ ((packed)); + +/*=20 + * in case everything's ok, the inlined function below will be + * optimized away by the compiler... + */ +static inline void +__bug_on_wrong_struct_sizes(void) +{ + BUG_ON(sizeof (struct obj_ssid) !=3D 34); + BUG_ON(sizeof (struct obj_key) !=3D 34); + BUG_ON(sizeof (struct obj_mlme) !=3D 12); + BUG_ON(sizeof (struct obj_mlmeex) !=3D 14); + BUG_ON(sizeof (struct obj_buffer) !=3D 8); + BUG_ON(sizeof (struct obj_bss) !=3D 60); + BUG_ON(sizeof (struct obj_bsslist) !=3D 4); + BUG_ON(sizeof (struct obj_frequencies) !=3D 2); +} + +enum dot11_state_t { + DOT11_STATE_NONE =3D 0, + DOT11_STATE_AUTHING =3D 1, + DOT11_STATE_AUTH =3D 2, + DOT11_STATE_ASSOCING =3D 3, + + DOT11_STATE_ASSOC =3D 5, + DOT11_STATE_IBSS =3D 6, + DOT11_STATE_WDS =3D 7 +}; + +enum dot11_bsstype_t { + DOT11_BSSTYPE_NONE =3D 0, + DOT11_BSSTYPE_INFRA =3D 1, + DOT11_BSSTYPE_IBSS =3D 2, + DOT11_BSSTYPE_ANY =3D 3 +}; + +enum dot11_auth_t { + DOT11_AUTH_NONE =3D 0, + DOT11_AUTH_OS =3D 1, + DOT11_AUTH_SK =3D 2, + DOT11_AUTH_BOTH =3D 3 +}; + +enum dot11_mlme_t { + DOT11_MLME_AUTO =3D 0, + DOT11_MLME_INTERMEDIATE =3D 1, + DOT11_MLME_EXTENDED =3D 2 +}; + +enum dot11_priv_t { + DOT11_PRIV_WEP =3D 0, + DOT11_PRIV_TKIP =3D 1 +}; + +/* Prism "Nitro" / Frameburst / "Packet Frame Grouping" + * Value is in microseconds. Represents the # microseconds + * the firmware will take to group frames before sending out then out=20 + * together with a CSMA contention. Without this all frames are + * sent with a CSMA contention.=20 + * Bibliography:=20 + * http://www.hpl.hp.com/personal/Jean_Tourrilhes/Papers/Packet.Frame.Grou= ping.html + */ +enum dot11_maxframeburst_t {=20 + /* Values for DOT11_OID_MAXFRAMEBURST */ + DOT11_MAXFRAMEBURST_OFF =3D 0, /* Card firmware default */ + DOT11_MAXFRAMEBURST_MIXED_SAFE =3D 650, /* 802.11 a,b,g safe */ + DOT11_MAXFRAMEBURST_IDEAL =3D 1300, /* Theoretical ideal level */ + DOT11_MAXFRAMEBURST_MAX =3D 5000, /* Use this as max, + * Note: firmware allows for greater values. This is a + * recommended max. I'll update this as I find + * out what the real MAX is. Also note that you don't necessarily + * get better results with a greater value here. + */ +}; + +/* Support for 802.11 long and short frame preambles. + * Long preamble uses 128-bit sync field, 8-bit CRC + * Short preamble uses 56-bit sync field, 16-bit CRC + *=20 + * 802.11a -- not sure, both optionally ? + * 802.11b supports long and optionally short=20 + * 802.11g supports both */ +enum dot11_preamblesettings_t { + DOT11_PREAMBLESETTING_LONG =3D 0, + /* Allows *only* long 802.11 preambles */ + DOT11_PREAMBLESETTING_SHORT =3D 1, + /* Allows *only* short 802.11 preambles */ + DOT11_PREAMBLESETTING_DYNAMIC =3D 2 + /* AutomatiGically set */ +}; + +/* Support for 802.11 slot timing (time between packets). + * + * Long uses 802.11a slot timing (9 usec ?) + * Short uses 802.11b slot timing (20 use ?) */ +enum dot11_slotsettings_t { + DOT11_SLOTSETTINGS_LONG =3D 0,=20 + /* Allows *only* long 802.11b slot timing */ + DOT11_SLOTSETTINGS_SHORT =3D 1, + /* Allows *only* long 802.11a slot timing */ + DOT11_SLOTSETTINGS_DYNAMIC =3D 2 + /* AutomatiGically set */ +}; + +/* All you need to know, ERP is "Extended Rate PHY". + * An Extended Rate PHY (ERP) STA or AP shall support three different=20 + * preamble and header formats: + * Long preamble (refer to above) + * Short preamble (refer to above) + * OFDM preamble ( ? ) + * + * I'm assuming here Protection tells the AP + * to be careful, a STA which cannot handle the long pre-amble + * has joined. + */ +enum do11_nonerpstatus_t { + DOT11_ERPSTAT_NONEPRESENT =3D 0, + DOT11_ERPSTAT_USEPROTECTION =3D 1 +}; + +/* (ERP is "Extended Rate PHY") Way to read NONERP is NON-ERP-* + * The key here is DOT11 NON ERP NEVER protects against + * NON ERP STA's. You *don't* want this unless + * you know what you are doing. It means you will only=20 + * get Extended Rate capabilities */ +enum dot11_nonerpprotection_t { + DOT11_NONERP_NEVER =3D 0, + DOT11_NONERP_ALWAYS =3D 1, + DOT11_NONERP_DYNAMIC =3D 2 +}; + +/* Preset OID configuration for 802.11 modes=20 + * Note: DOT11_OID_CW[MIN|MAX] hold the values of the=20 + * DCS MIN|MAX backoff used */ +enum dot11_profile_t { /* And set/allowed values */ + /* Allowed values for DOT11_OID_PROFILES */ + DOT11_PROFILE_B_ONLY =3D 0, + /* DOT11_OID_RATES: 1, 2, 5.5, 11Mbps=20 + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_DYNAMIC + * DOT11_OID_CWMIN: 31 + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_DYNAMIC + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_LONG + */ + DOT11_PROFILE_MIXED_G_WIFI =3D 1, + /* DOT11_OID_RATES: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54Mbs + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_DYNAMIC + * DOT11_OID_CWMIN: 15 + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_DYNAMIC + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_DYNAMIC + */ + DOT11_PROFILE_MIXED_LONG =3D 2, /* "Long range" */ + /* Same as Profile MIXED_G_WIFI */ + DOT11_PROFILE_G_ONLY =3D 3, + /* Same as Profile MIXED_G_WIFI */ + DOT11_PROFILE_TEST =3D 4, + /* Same as Profile MIXED_G_WIFI except: + * DOT11_OID_PREAMBLESETTINGS: DOT11_PREAMBLESETTING_SHORT + * DOT11_OID_NONEPROTECTION: DOT11_NOERP_NEVER + * DOT11_OID_SLOTSETTINGS: DOT11_SLOTSETTINGS_SHORT + */ + DOT11_PROFILE_B_WIFI =3D 5, + /* Same as Profile B_ONLY */ + DOT11_PROFILE_A_ONLY =3D 6, + /* Same as Profile MIXED_G_WIFI except: + * DOT11_OID_RATES: 6, 9, 12, 18, 24, 36, 48, 54Mbs + */ + DOT11_PROFILE_MIXED_SHORT =3D 7 + /* Same as MIXED_G_WIFI */ +}; + + +/* The dot11d conformance level configures the 802.11d conformance levels. + * The following conformance levels exist:*/ +enum oid_inl_conformance_t { + OID_INL_CONFORMANCE_NONE =3D 0, /* Perform active scanning */ + OID_INL_CONFORMANCE_STRICT =3D 1, /* Strictly adhere to 802.11d */ + OID_INL_CONFORMANCE_FLEXIBLE =3D 2, /* Use passed 802.11d info to + * determine channel AND/OR just make assumption that active=20 + * channels are valid channels */ +}; + +enum oid_inl_mode_t { + INL_MODE_NONE =3D -1, + INL_MODE_PROMISCUOUS =3D 0, + INL_MODE_CLIENT =3D 1, + INL_MODE_AP =3D 2, + INL_MODE_SNIFFER =3D 3 +}; + +enum oid_inl_config_t { + INL_CONFIG_NOTHING =3D 0x00, + INL_CONFIG_MANUALRUN =3D 0x01, + INL_CONFIG_FRAMETRAP =3D 0x02, + INL_CONFIG_RXANNEX =3D 0x04, + INL_CONFIG_TXANNEX =3D 0x08, + INL_CONFIG_WDS =3D 0x10 +}; + +enum oid_inl_phycap_t { + INL_PHYCAP_2400MHZ =3D 1, + INL_PHYCAP_5000MHZ =3D 2, + INL_PHYCAP_FAA =3D 0x80000000, /* Means card supports the FAA switch */ +}; + + +enum oid_num_t { + GEN_OID_MACADDRESS =3D 0, + GEN_OID_LINKSTATE, + GEN_OID_WATCHDOG, + GEN_OID_MIBOP, + GEN_OID_OPTIONS, + GEN_OID_LEDCONFIG, + + /* 802.11 */ + DOT11_OID_BSSTYPE, + DOT11_OID_BSSID, + DOT11_OID_SSID, + DOT11_OID_STATE, + DOT11_OID_AID, + DOT11_OID_COUNTRYSTRING, + DOT11_OID_SSIDOVERRIDE, + + DOT11_OID_MEDIUMLIMIT, + DOT11_OID_BEACONPERIOD, + DOT11_OID_DTIMPERIOD, + DOT11_OID_ATIMWINDOW, + DOT11_OID_LISTENINTERVAL, + DOT11_OID_CFPPERIOD, + DOT11_OID_CFPDURATION, + + DOT11_OID_AUTHENABLE, + DOT11_OID_PRIVACYINVOKED, + DOT11_OID_EXUNENCRYPTED, + DOT11_OID_DEFKEYID, + DOT11_OID_DEFKEYX, /* DOT11_OID_DEFKEY1,...DOT11_OID_DEFKEY4 */ + DOT11_OID_STAKEY, + DOT11_OID_REKEYTHRESHOLD, + DOT11_OID_STASC, + + DOT11_OID_PRIVTXREJECTED, + DOT11_OID_PRIVRXPLAIN, + DOT11_OID_PRIVRXFAILED, + DOT11_OID_PRIVRXNOKEY, + + DOT11_OID_RTSTHRESH, + DOT11_OID_FRAGTHRESH, + DOT11_OID_SHORTRETRIES, + DOT11_OID_LONGRETRIES, + DOT11_OID_MAXTXLIFETIME, + DOT11_OID_MAXRXLIFETIME, + DOT11_OID_AUTHRESPTIMEOUT, + DOT11_OID_ASSOCRESPTIMEOUT, + + DOT11_OID_ALOFT_TABLE, + DOT11_OID_ALOFT_CTRL_TABLE, + DOT11_OID_ALOFT_RETREAT, + DOT11_OID_ALOFT_PROGRESS, + DOT11_OID_ALOFT_FIXEDRATE, + DOT11_OID_ALOFT_RSSIGRAPH, + DOT11_OID_ALOFT_CONFIG, + + DOT11_OID_VDCFX, + DOT11_OID_MAXFRAMEBURST, + + DOT11_OID_PSM, + DOT11_OID_CAMTIMEOUT, + DOT11_OID_RECEIVEDTIMS, + DOT11_OID_ROAMPREFERENCE, + + DOT11_OID_BRIDGELOCAL, + DOT11_OID_CLIENTS, + DOT11_OID_CLIENTSASSOCIATED, + DOT11_OID_CLIENTX, /* DOT11_OID_CLIENTX,...DOT11_OID_CLIENT2007 */ + + DOT11_OID_CLIENTFIND, + DOT11_OID_WDSLINKADD, + DOT11_OID_WDSLINKREMOVE, + DOT11_OID_EAPAUTHSTA, + DOT11_OID_EAPUNAUTHSTA, + DOT11_OID_DOT1XENABLE, + DOT11_OID_MICFAILURE, + DOT11_OID_REKEYINDICATE, + + DOT11_OID_MPDUTXSUCCESSFUL, + DOT11_OID_MPDUTXONERETRY, + DOT11_OID_MPDUTXMULTIPLERETRIES, + DOT11_OID_MPDUTXFAILED, + DOT11_OID_MPDURXSUCCESSFUL, + DOT11_OID_MPDURXDUPS, + DOT11_OID_RTSSUCCESSFUL, + DOT11_OID_RTSFAILED, + DOT11_OID_ACKFAILED, + DOT11_OID_FRAMERECEIVES, + DOT11_OID_FRAMEERRORS, + DOT11_OID_FRAMEABORTS, + DOT11_OID_FRAMEABORTSPHY, + + DOT11_OID_SLOTTIME, + DOT11_OID_CWMIN, /* MIN DCS backoff */ + DOT11_OID_CWMAX, /* MAX DCS backoff */ + DOT11_OID_ACKWINDOW, + DOT11_OID_ANTENNARX, + DOT11_OID_ANTENNATX, + DOT11_OID_ANTENNADIVERSITY, + DOT11_OID_CHANNEL, + DOT11_OID_EDTHRESHOLD, + DOT11_OID_PREAMBLESETTINGS, + DOT11_OID_RATES, + DOT11_OID_CCAMODESUPPORTED, + DOT11_OID_CCAMODE, + DOT11_OID_RSSIVECTOR, + DOT11_OID_OUTPUTPOWERTABLE, + DOT11_OID_OUTPUTPOWER, + DOT11_OID_SUPPORTEDRATES, + DOT11_OID_FREQUENCY, + DOT11_OID_SUPPORTEDFREQUENCIES, + DOT11_OID_NOISEFLOOR, + DOT11_OID_FREQUENCYACTIVITY, + DOT11_OID_IQCALIBRATIONTABLE, + DOT11_OID_NONERPPROTECTION, + DOT11_OID_SLOTSETTINGS, + DOT11_OID_NONERPTIMEOUT, + DOT11_OID_PROFILES, + DOT11_OID_EXTENDEDRATES, + + DOT11_OID_DEAUTHENTICATE, + DOT11_OID_AUTHENTICATE, + DOT11_OID_DISASSOCIATE, + DOT11_OID_ASSOCIATE, + DOT11_OID_SCAN, + DOT11_OID_BEACON, + DOT11_OID_PROBE, + DOT11_OID_DEAUTHENTICATEEX, + DOT11_OID_AUTHENTICATEEX, + DOT11_OID_DISASSOCIATEEX, + DOT11_OID_ASSOCIATEEX, + DOT11_OID_REASSOCIATE, + DOT11_OID_REASSOCIATEEX, + + DOT11_OID_NONERPSTATUS, + + DOT11_OID_STATIMEOUT, + DOT11_OID_MLMEAUTOLEVEL, + DOT11_OID_BSSTIMEOUT, + DOT11_OID_ATTACHMENT, + DOT11_OID_PSMBUFFER, + + DOT11_OID_BSSS, + DOT11_OID_BSSX, /*DOT11_OID_BSS1,...,DOT11_OID_BSS64 */ + DOT11_OID_BSSFIND, + DOT11_OID_BSSLIST, + + OID_INL_TUNNEL, + OID_INL_MEMADDR, + OID_INL_MEMORY, + OID_INL_MODE, + OID_INL_COMPONENT_NR, + OID_INL_VERSION, + OID_INL_INTERFACE_ID, + OID_INL_COMPONENT_ID, + OID_INL_CONFIG, + OID_INL_DOT11D_CONFORMANCE, + OID_INL_PHYCAPABILITIES, + OID_INL_OUTPUTPOWER, + + OID_NUM_LAST +}; + +#define OID_FLAG_CACHED 0x80 +#define OID_FLAG_TYPE 0x7f + +#define OID_TYPE_U32 0x01 +#define OID_TYPE_SSID 0x02 +#define OID_TYPE_KEY 0x03 +#define OID_TYPE_BUFFER 0x04 +#define OID_TYPE_BSS 0x05 +#define OID_TYPE_BSSLIST 0x06 +#define OID_TYPE_FREQUENCIES 0x07 +#define OID_TYPE_MLME 0x08 +#define OID_TYPE_MLMEEX 0x09 +#define OID_TYPE_ADDR 0x0A +#define OID_TYPE_RAW 0x0B + +/* OID_TYPE_MLMEEX is special because of a variable size field when sendin= g. + * Not yet implemented (not used in driver anyway). + */ + +struct oid_t { + enum oid_num_t oid; + short range; /* to define a range of oid */ + short size; /* max size of the associated data */ + char flags; +}; + +union oid_res_t { + void *ptr; + u32 u; +}; + +#define IWMAX_BITRATES 20 +#define IWMAX_BSS 24 +#define IWMAX_FREQ 30 +#define PRIV_STR_SIZE 1024 + +#endif /* !defined(_ISL_OID_H) */ +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_dev.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_dev.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_dev.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_dev.c 2004-07-= 21 09:00:04.000000000 +0000 @@ -0,0 +1,931 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include + +#include +#include +#include +#include +#include + +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "isl_ioctl.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" +#include "islpci_eth.h" +#include "oid_mgt.h" + +#define ISL3877_IMAGE_FILE "isl3877" +#define ISL3890_IMAGE_FILE "isl3890" + +static int prism54_bring_down(islpci_private *); +static int islpci_alloc_memory(islpci_private *); + +/* Temporary dummy MAC address to use until firmware is loaded. + * The idea there is that some tools (such as nameif) may query + * the MAC address before the netdev is 'open'. By using a valid + * OUI prefix, they can process the netdev properly. + * Of course, this is not the final/real MAC address. It doesn't + * matter, as you are suppose to be able to change it anytime via + * ndev->set_mac_address. Jean II */ +const unsigned char dummy_mac[6] =3D { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 = }; + +static int +isl_upload_firmware(islpci_private *priv) +{ + u32 reg, rc; + void *device_base =3D priv->device_base; + + /* clear the RAMBoot and the Reset bit */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + reg &=3D ~ISL38XX_CTRL_STAT_RAMBOOT; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the Reset bit without reading the register ! */ + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the Reset bit */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + + /* wait a while for the device to reboot */ + mdelay(50); + + { + const struct firmware *fw_entry =3D 0; + long fw_len; + const u32 *fw_ptr; + + rc =3D request_firmware(&fw_entry, priv->firmware, PRISM_FW_PDEV); + if (rc) { + printk(KERN_ERR + "%s: request_firmware() failed for '%s'\n", + "prism54", priv->firmware); + return rc; + } + /* prepare the Direct Memory Base register */ + reg =3D ISL38XX_DEV_FIRMWARE_ADDRES; + + fw_ptr =3D (u32 *) fw_entry->data; + fw_len =3D fw_entry->size; + + if (fw_len % 4) { + printk(KERN_ERR + "%s: firmware '%s' size is not multiple of 32bit, aborting!\n", + "prism54", priv->firmware); + release_firmware(fw_entry); + return EILSEQ; /* Illegal byte sequence */; + } + + while (fw_len > 0) { + long _fw_len =3D + (fw_len > + ISL38XX_MEMORY_WINDOW_SIZE) ? + ISL38XX_MEMORY_WINDOW_SIZE : fw_len; + u32 *dev_fw_ptr =3D device_base + ISL38XX_DIRECT_MEM_WIN; + + /* set the cards base address for writting the data */ + isl38xx_w32_flush(device_base, reg, + ISL38XX_DIR_MEM_BASE_REG); + wmb(); /* be paranoid */ + + /* increment the write address for next iteration */ + reg +=3D _fw_len; + fw_len -=3D _fw_len; + + /* write the data to the Direct Memory Window 32bit-wise */ + /* memcpy_toio() doesn't guarantee 32bit writes :-| */ + while (_fw_len > 0) { + /* use non-swapping writel() */ + __raw_writel(*fw_ptr, dev_fw_ptr); + fw_ptr++, dev_fw_ptr++; + _fw_len -=3D 4; + } + + /* flush PCI posting */ + (void) readl(device_base + ISL38XX_PCI_POSTING_FLUSH); + wmb(); /* be paranoid again */ + + BUG_ON(_fw_len !=3D 0); + } + + BUG_ON(fw_len !=3D 0); + + release_firmware(fw_entry); + } + + /* now reset the device + * clear the Reset & ClkRun bit, set the RAMBoot bit */ + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~ISL38XX_CTRL_STAT_CLKRUN; + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + reg |=3D ISL38XX_CTRL_STAT_RAMBOOT; + isl38xx_w32_flush(device_base, reg, ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* set the reset bit latches the host override and RAMBoot bits + * into the device for operation when the reset bit is reset */ + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the reset bit should start the whole circus */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + /* don't do flush PCI posting here! */ + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + return 0; +} + +/*************************************************************************= ***** + Device Interrupt Handler +**************************************************************************= ****/ + +irqreturn_t +islpci_interrupt(int irq, void *config, struct pt_regs *regs) +{ + u32 reg; + islpci_private *priv =3D config; + struct net_device *ndev =3D priv->ndev; + void *device =3D priv->device_base; + int powerstate =3D ISL38XX_PSM_POWERSAVE_STATE; + + /* received an interrupt request on a shared IRQ line + * first check whether the device is in sleep mode */ + reg =3D readl(device + ISL38XX_CTRL_STAT_REG); + if (reg & ISL38XX_CTRL_STAT_SLEEPMODE) + /* device is in sleep mode, IRQ was generated by someone else */ + { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Assuming someone else called the IRQ\n"); +#endif + return IRQ_NONE; + } + + if (islpci_get_state(priv) !=3D PRV_STATE_SLEEP) + powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* lock the interrupt handler */ + spin_lock(&priv->slock); + + /* check whether there is any source of interrupt on the device */ + reg =3D readl(device + ISL38XX_INT_IDENT_REG); + + /* also check the contents of the Interrupt Enable Register, because this + * will filter out interrupt sources from other devices on the same irq != */ + reg &=3D readl(device + ISL38XX_INT_EN_REG); + reg &=3D ISL38XX_INT_SOURCES; + + if (reg !=3D 0) { + /* reset the request bits in the Identification register */ + isl38xx_w32_flush(device, reg, ISL38XX_INT_ACK_REG); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, + "IRQ: Identification register 0x%p 0x%x \n", device, reg); +#endif + + /* check for each bit in the register separately */ + if (reg & ISL38XX_INT_IDENT_UPDATE) { +#if VERBOSE > SHOW_ERROR_MESSAGES + /* Queue has been updated */ + DEBUG(SHOW_TRACING, "IRQ: Update flag \n"); + + DEBUG(SHOW_QUEUE_INDEXES, + "CB drv Qs: [%i][%i][%i][%i][%i][%i]\n", + le32_to_cpu(priv->control_block-> + driver_curr_frag[0]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[1]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[2]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[3]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[4]), + le32_to_cpu(priv->control_block-> + driver_curr_frag[5]) + ); + + DEBUG(SHOW_QUEUE_INDEXES, + "CB dev Qs: [%i][%i][%i][%i][%i][%i]\n", + le32_to_cpu(priv->control_block-> + device_curr_frag[0]), + le32_to_cpu(priv->control_block-> + device_curr_frag[1]), + le32_to_cpu(priv->control_block-> + device_curr_frag[2]), + le32_to_cpu(priv->control_block-> + device_curr_frag[3]), + le32_to_cpu(priv->control_block-> + device_curr_frag[4]), + le32_to_cpu(priv->control_block-> + device_curr_frag[5]) + ); +#endif + + /* cleanup the data low transmit queue */ + islpci_eth_cleanup_transmit(priv, priv->control_block); + + /* device is in active state, update the + * powerstate flag if necessary */ + powerstate =3D ISL38XX_PSM_ACTIVE_STATE; + + /* check all three queues in priority order + * call the PIMFOR receive function until the + * queue is empty */ + if (isl38xx_in_queue(priv->control_block, + ISL38XX_CB_RX_MGMTQ) !=3D 0) { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "Received frame in Management Queue\n"); +#endif + islpci_mgt_receive(ndev); + + islpci_mgt_cleanup_transmit(ndev); + + /* Refill slots in receive queue */ + islpci_mgmt_rx_fill(ndev); + + /* no need to trigger the device, next + islpci_mgt_transaction does it */ + } + + while (isl38xx_in_queue(priv->control_block, + ISL38XX_CB_RX_DATA_LQ) !=3D 0) { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "Received frame in Data Low Queue \n"); +#endif + islpci_eth_receive(priv); + } + + /* check whether the data transmit queues were full */ + if (priv->data_low_tx_full) { + /* check whether the transmit is not full anymore */ + if (ISL38XX_CB_TX_QSIZE - + isl38xx_in_queue(priv->control_block, + ISL38XX_CB_TX_DATA_LQ) >=3D + ISL38XX_MIN_QTHRESHOLD) { + /* nope, the driver is ready for more network frames */ + netif_wake_queue(priv->ndev); + + /* reset the full flag */ + priv->data_low_tx_full =3D 0; + } + } + } + + if (reg & ISL38XX_INT_IDENT_INIT) { + /* Device has been initialized */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "IRQ: Init flag, device initialized \n"); +#endif + wake_up(&priv->reset_done); + } + + if (reg & ISL38XX_INT_IDENT_SLEEP) { + /* Device intends to move to powersave state */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "IRQ: Sleep flag \n"); +#endif + isl38xx_handle_sleep_request(priv->control_block, + &powerstate, + priv->device_base); + } + + if (reg & ISL38XX_INT_IDENT_WAKEUP) { + /* Device has been woken up to active state */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "IRQ: Wakeup flag \n"); +#endif + + isl38xx_handle_wakeup(priv->control_block, + &powerstate, priv->device_base); + } + } + + /* sleep -> ready */ + if (islpci_get_state(priv) =3D=3D PRV_STATE_SLEEP + && powerstate =3D=3D ISL38XX_PSM_ACTIVE_STATE) + islpci_set_state(priv, PRV_STATE_READY); + + /* !sleep -> sleep */ + if (islpci_get_state(priv) !=3D PRV_STATE_SLEEP + && powerstate =3D=3D ISL38XX_PSM_POWERSAVE_STATE) + islpci_set_state(priv, PRV_STATE_SLEEP); + + /* unlock the interrupt handler */ + spin_unlock(&priv->slock); + + return IRQ_HANDLED; +} + +/*************************************************************************= ***** + Network Interface Control & Statistical functions +**************************************************************************= ****/ +static int +islpci_open(struct net_device *ndev) +{ + u32 rc; + islpci_private *priv =3D netdev_priv(ndev); + + printk(KERN_DEBUG "%s: islpci_open()\n", ndev->name); + + /* reset data structures, upload firmware and reset device */ + rc =3D islpci_reset(priv,1); + if (rc) { + prism54_bring_down(priv); + return rc; /* Returns informative message */ + } + + netif_start_queue(ndev); +/* netif_mark_up( ndev ); */ + + return 0; +} + +static int +islpci_close(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + + printk(KERN_DEBUG "%s: islpci_close ()\n", ndev->name); + + netif_stop_queue(ndev); + + return prism54_bring_down(priv); +} + +static int +prism54_bring_down(islpci_private *priv) +{ + void *device_base =3D priv->device_base; + u32 reg; + /* we are going to shutdown the device */ + islpci_set_state(priv, PRV_STATE_PREBOOT); + + /* disable all device interrupts in case they weren't */ + isl38xx_disable_interrupts(priv->device_base); =20 + + /* For safety reasons, we may want to ensure that no DMA transfer is + * currently in progress by emptying the TX and RX queues. */ + + /* wait until interrupts have finished executing on other CPUs */ + prism54_synchronize_irq(priv->pdev->irq); + + reg =3D readl(device_base + ISL38XX_CTRL_STAT_REG); + reg &=3D ~(ISL38XX_CTRL_STAT_RESET | ISL38XX_CTRL_STAT_RAMBOOT); + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + reg |=3D ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + udelay(ISL38XX_WRITEIO_DELAY); + + /* clear the Reset bit */ + reg &=3D ~ISL38XX_CTRL_STAT_RESET; + writel(reg, device_base + ISL38XX_CTRL_STAT_REG); + wmb(); + + /* wait a while for the device to reset */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(50*HZ/1000); + + return 0; +} + +static int +islpci_upload_fw(islpci_private *priv) +{ + islpci_state_t old_state; + u32 rc; + + old_state =3D islpci_set_state(priv, PRV_STATE_BOOT); + + printk(KERN_DEBUG "%s: uploading firmware...\n", priv->ndev->name); + + rc =3D isl_upload_firmware(priv); + if (rc) { + /* error uploading the firmware */ + printk(KERN_ERR "%s: could not upload firmware ('%s')\n", + priv->ndev->name, priv->firmware); + + islpci_set_state(priv, old_state); + return rc; + } + + printk(KERN_DEBUG + "%s: firmware uploaded done, now triggering reset...\n", + priv->ndev->name); + + islpci_set_state(priv, PRV_STATE_POSTBOOT); + + return 0; +} + +static int +islpci_reset_if(islpci_private *priv) +{ + long remaining; + int result =3D -ETIME; + int count; + + DEFINE_WAIT(wait); + prepare_to_wait(&priv->reset_done, &wait, TASK_UNINTERRUPTIBLE); +=09 + /* now the last step is to reset the interface */ + isl38xx_interface_reset(priv->device_base, priv->device_host_address); + islpci_set_state(priv, PRV_STATE_PREINIT); + + for(count =3D 0; count < 2 && result; count++) { + /* The software reset acknowledge needs about 220 msec here. + * Be conservative and wait for up to one second. */ +=09 + remaining =3D schedule_timeout(HZ); + + if(remaining > 0) { + result =3D 0; + break; + } + + /* If we're here it's because our IRQ hasn't yet gone through.=20 + * Retry a bit more... + */ + printk(KERN_ERR "%s: device soft reset timed out\n", + priv->ndev->name); + + } + + finish_wait(&priv->reset_done, &wait); + + if(result) + return result; + + islpci_set_state(priv, PRV_STATE_INIT); + + /* Now that the device is 100% up, let's allow + * for the other interrupts -- + * NOTE: this is not *yet* true since we've only allowed the=20 + * INIT interrupt on the IRQ line. We can perhaps poll + * the IRQ line until we know for sure the reset went through */ + isl38xx_enable_common_interrupts(priv->device_base); + + down_write(&priv->mib_sem); + mgt_commit(priv); + up_write(&priv->mib_sem); + + islpci_set_state(priv, PRV_STATE_READY); + + return 0; +} + +int +islpci_reset(islpci_private *priv, int reload_firmware) +{ + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + unsigned counter; + int rc; + + if (reload_firmware) + islpci_set_state(priv, PRV_STATE_PREBOOT); + else + islpci_set_state(priv, PRV_STATE_POSTBOOT); + + printk(KERN_DEBUG "%s: resetting device...\n", priv->ndev->name); + + /* disable all device interrupts in case they weren't */ + isl38xx_disable_interrupts(priv->device_base); + + /* flush all management queues */ + priv->index_mgmt_tx =3D 0; + priv->index_mgmt_rx =3D 0; + + /* clear the indexes in the frame pointer */ + for (counter =3D 0; counter < ISL38XX_CB_QCOUNT; counter++) { + cb->driver_curr_frag[counter] =3D cpu_to_le32(0); + cb->device_curr_frag[counter] =3D cpu_to_le32(0); + } + + /* reset the mgmt receive queue */ + for (counter =3D 0; counter < ISL38XX_CB_MGMT_QSIZE; counter++) { + isl38xx_fragment *frag =3D &cb->rx_data_mgmt[counter]; + frag->size =3D cpu_to_le16(MGMT_FRAME_SIZE); + frag->flags =3D 0; + frag->address =3D cpu_to_le32(priv->mgmt_rx[counter].pci_addr); + } + + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + cb->rx_data_low[counter].address =3D + cpu_to_le32((u32) priv->pci_map_rx_address[counter]); + } + + /* since the receive queues are filled with empty fragments, now we can + * set the corresponding indexes in the Control Block */ + priv->control_block->driver_curr_frag[ISL38XX_CB_RX_DATA_LQ] =3D + cpu_to_le32(ISL38XX_CB_RX_QSIZE); + priv->control_block->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] =3D + cpu_to_le32(ISL38XX_CB_MGMT_QSIZE); + + /* reset the remaining real index registers and full flags */ + priv->free_data_rx =3D 0; + priv->free_data_tx =3D 0; + priv->data_low_tx_full =3D 0; + + if (reload_firmware) { /* Should we load the firmware ? */ + /* now that the data structures are cleaned up, upload + * firmware and reset interface */ + rc =3D islpci_upload_fw(priv); + if (rc)=20 + return rc; + } + + /* finally reset interface */ + rc =3D islpci_reset_if(priv); + if (!rc) /* If successful */ + return rc; +=09 + printk(KERN_DEBUG "prism54: Your card/socket may be faulty, or IRQ line = too busy :(\n"); + return rc; + +} + +struct net_device_stats * +islpci_statistics(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_statistics \n"); +#endif + + return &priv->statistics; +} + +/*************************************************************************= ***** + Network device configuration functions +**************************************************************************= ****/ +static int +islpci_alloc_memory(islpci_private *priv) +{ + int counter; + +#if VERBOSE > SHOW_ERROR_MESSAGES + printk(KERN_DEBUG "islpci_alloc_memory\n"); +#endif + + /* remap the PCI device base address to accessable */ + if (!(priv->device_base =3D + ioremap(pci_resource_start(priv->pdev, 0), + ISL38XX_PCI_MEM_SIZE))) { + /* error in remapping the PCI device memory address range */ + printk(KERN_ERR "PCI memory remapping failed \n"); + return -1; + } + + /* memory layout for consistent DMA region: + * + * Area 1: Control Block for the device interface + * Area 2: Power Save Mode Buffer for temporary frame storage. Be aware t= hat + * the number of supported stations in the AP determines the mini= mal + * size of the buffer ! + */ + + /* perform the allocation */ + priv->driver_mem_address =3D pci_alloc_consistent(priv->pdev, + HOST_MEM_BLOCK, + &priv-> + device_host_address); + + if (!priv->driver_mem_address) { + /* error allocating the block of PCI memory */ + printk(KERN_ERR "%s: could not allocate DMA memory, aborting!", + "prism54"); + return -1; + } + + /* assign the Control Block to the first address of the allocated area */ + priv->control_block =3D + (isl38xx_control_block *) priv->driver_mem_address; + + /* set the Power Save Buffer pointer directly behind the CB */ + priv->device_psm_buffer =3D + priv->device_host_address + CONTROL_BLOCK_SIZE; + + /* make sure all buffer pointers are initialized */ + for (counter =3D 0; counter < ISL38XX_CB_QCOUNT; counter++) { + priv->control_block->driver_curr_frag[counter] =3D cpu_to_le32(0); + priv->control_block->device_curr_frag[counter] =3D cpu_to_le32(0); + } + + priv->index_mgmt_rx =3D 0; + memset(priv->mgmt_rx, 0, sizeof(priv->mgmt_rx)); + memset(priv->mgmt_tx, 0, sizeof(priv->mgmt_tx)); + + /* allocate rx queue for management frames */ + if (islpci_mgmt_rx_fill(priv->ndev) < 0) + goto out_free; + + /* now get the data rx skb's */ + memset(priv->data_low_rx, 0, sizeof (priv->data_low_rx)); + memset(priv->pci_map_rx_address, 0, sizeof (priv->pci_map_rx_address)); + + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + struct sk_buff *skb; + + /* allocate an sk_buff for received data frames storage + * each frame on receive size consists of 1 fragment + * include any required allignment operations */ + if (!(skb =3D dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2))) { + /* error allocating an sk_buff structure elements */ + printk(KERN_ERR "Error allocating skb.\n"); + skb =3D NULL; + goto out_free; + } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + /* add the new allocated sk_buff to the buffer array */ + priv->data_low_rx[counter] =3D skb; + + /* map the allocated skb data area to pci */ + priv->pci_map_rx_address[counter] =3D + pci_map_single(priv->pdev, (void *) skb->data, + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + if (!priv->pci_map_rx_address[counter]) { + /* error mapping the buffer to device + accessable memory address */ + printk(KERN_ERR "failed to map skb DMA'able\n"); + goto out_free; + } + } + + prism54_acl_init(&priv->acl); + prism54_wpa_ie_init(priv); + if (mgt_init(priv))=20 + goto out_free; + + return 0; + out_free: + islpci_free_memory(priv); + return -1; +} + +int +islpci_free_memory(islpci_private *priv) +{ + int counter; + + if (priv->device_base) + iounmap(priv->device_base); + priv->device_base =3D 0; + + /* free consistent DMA area... */ + if (priv->driver_mem_address) + pci_free_consistent(priv->pdev, HOST_MEM_BLOCK, + priv->driver_mem_address, + priv->device_host_address); + + /* clear some dangling pointers */ + priv->driver_mem_address =3D 0; + priv->device_host_address =3D 0; + priv->device_psm_buffer =3D 0; + priv->control_block =3D 0; + + /* clean up mgmt rx buffers */ + for (counter =3D 0; counter < ISL38XX_CB_MGMT_QSIZE; counter++) { + struct islpci_membuf *buf =3D &priv->mgmt_rx[counter]; + if (buf->pci_addr) + pci_unmap_single(priv->pdev, buf->pci_addr, + buf->size, PCI_DMA_FROMDEVICE); + buf->pci_addr =3D 0; + if (buf->mem) + kfree(buf->mem); + buf->size =3D 0; + buf->mem =3D NULL; + } + + /* clean up data rx buffers */ + for (counter =3D 0; counter < ISL38XX_CB_RX_QSIZE; counter++) { + if (priv->pci_map_rx_address[counter]) + pci_unmap_single(priv->pdev, + priv->pci_map_rx_address[counter], + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + priv->pci_map_rx_address[counter] =3D 0; + + if (priv->data_low_rx[counter]) + dev_kfree_skb(priv->data_low_rx[counter]); + priv->data_low_rx[counter] =3D 0; + } + + /* Free the acces control list and the WPA list */ + prism54_acl_clean(&priv->acl); + prism54_wpa_ie_clean(priv); + mgt_clean(priv); + + return 0; +} + +#if 0 +static void +islpci_set_multicast_list(struct net_device *dev) +{ + /* put device into promisc mode and let network layer handle it */ +} +#endif + +struct net_device * +islpci_setup(struct pci_dev *pdev) +{ + islpci_private *priv; + struct net_device *ndev =3D alloc_etherdev(sizeof (islpci_private)); + + if (!ndev) + return ndev; + + SET_MODULE_OWNER(ndev); + pci_set_drvdata(pdev, ndev); +#if defined(SET_NETDEV_DEV) + SET_NETDEV_DEV(ndev, &pdev->dev); +#endif + + /* setup the structure members */ + ndev->base_addr =3D pci_resource_start(pdev, 0); + ndev->irq =3D pdev->irq; + + /* initialize the function pointers */ + ndev->open =3D &islpci_open; + ndev->stop =3D &islpci_close; + ndev->get_stats =3D &islpci_statistics; + ndev->get_wireless_stats =3D &prism54_get_wireless_stats; + ndev->do_ioctl =3D &prism54_ioctl; + ndev->wireless_handlers =3D + (struct iw_handler_def *) &prism54_handler_def; + + ndev->hard_start_xmit =3D &islpci_eth_transmit; + /* ndev->set_multicast_list =3D &islpci_set_multicast_list; */ + ndev->addr_len =3D ETH_ALEN; + ndev->set_mac_address =3D &prism54_set_mac_address; + /* Get a non-zero dummy MAC address for nameif. Jean II */ + memcpy(ndev->dev_addr, dummy_mac, 6); + +#ifdef HAVE_TX_TIMEOUT + ndev->watchdog_timeo =3D ISLPCI_TX_TIMEOUT; + ndev->tx_timeout =3D &islpci_eth_tx_timeout; +#endif + + /* allocate a private device structure to the network device */ + priv =3D netdev_priv(ndev); + priv->ndev =3D ndev; + priv->pdev =3D pdev; + priv->monitor_type =3D ARPHRD_IEEE80211; + priv->ndev->type =3D (priv->iw_mode =3D=3D IW_MODE_MONITOR) ? + priv->monitor_type : ARPHRD_ETHER; + + /* save the start and end address of the PCI memory area */ + ndev->mem_start =3D (unsigned long) priv->device_base; + ndev->mem_end =3D ndev->mem_start + ISL38XX_PCI_MEM_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "PCI Memory remapped to 0x%p\n", priv->device_base); +#endif + + init_waitqueue_head(&priv->reset_done); + + /* init the queue read locks, process wait counter */ + sema_init(&priv->mgmt_sem, 1); + priv->mgmt_received =3D NULL; + init_waitqueue_head(&priv->mgmt_wqueue); + sema_init(&priv->stats_sem, 1); + spin_lock_init(&priv->slock); + + /* init state machine with off#1 state */ + priv->state =3D PRV_STATE_OFF; + priv->state_off =3D 1; + + /* initialize workqueue's */ + INIT_WORK(&priv->stats_work, + (void (*)(void *)) prism54_update_stats, priv); + priv->stats_timestamp =3D 0; + + INIT_WORK(&priv->reset_task, islpci_do_reset_and_wake, priv); + priv->reset_task_pending =3D 0; + + /* allocate various memory areas */ + if (islpci_alloc_memory(priv)) + goto do_free_netdev; + + /* select the firmware file depending on the device id */ + switch (pdev->device) { + case PCIDEVICE_ISL3890: + case PCIDEVICE_3COM6001: + strcpy(priv->firmware, ISL3890_IMAGE_FILE); + break; + case PCIDEVICE_ISL3877: + strcpy(priv->firmware, ISL3877_IMAGE_FILE); + break; + + default: + strcpy(priv->firmware, ISL3890_IMAGE_FILE); + break; + } + + if (register_netdev(ndev)) { + DEBUG(SHOW_ERROR_MESSAGES, + "ERROR: register_netdev() failed \n"); + goto do_islpci_free_memory; + } + + return ndev; + + do_islpci_free_memory: + islpci_free_memory(priv); + do_free_netdev: + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + return NULL; +} + +islpci_state_t +islpci_set_state(islpci_private *priv, islpci_state_t new_state) +{ + islpci_state_t old_state; + + /* lock */ + old_state =3D priv->state; + + /* this means either a race condition or some serious error in + * the driver code */ + switch (new_state) { + case PRV_STATE_OFF: + priv->state_off++; + default: + priv->state =3D new_state; + break; + + case PRV_STATE_PREBOOT: + /* there are actually many off-states, enumerated by + * state_off */ + if (old_state =3D=3D PRV_STATE_OFF) + priv->state_off--; + + /* only if hw_unavailable is zero now it means we either + * were in off#1 state, or came here from + * somewhere else */ + if (!priv->state_off) + priv->state =3D new_state; + break; + }; +#if 0 + printk(KERN_DEBUG "%s: state transition %d -> %d (off#%d)\n", + priv->ndev->name, old_state, new_state, priv->state_off); +#endif + + /* invariants */ + BUG_ON(priv->state_off < 0); + BUG_ON(priv->state_off && (priv->state !=3D PRV_STATE_OFF)); + BUG_ON(!priv->state_off && (priv->state =3D=3D PRV_STATE_OFF)); + + /* unlock */ + return old_state; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_dev.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_dev.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_dev.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_dev.h 2004-07-= 21 09:00:04.000000000 +0000 @@ -0,0 +1,215 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc.=20 + * Copyright (C) 2003 Herbert Valerio Riedel + * Copyright (C) 2003 Luis R. Rodriguez + * Copyright (C) 2003 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISLPCI_DEV_H +#define _ISLPCI_DEV_H + +#include +#include +#include +#include +#include + +#include "isl_38xx.h" +#include "isl_oid.h" +#include "islpci_mgt.h" + +/* some states might not be superflous and may be removed when + design is finalized (hvr) */ +typedef enum { + PRV_STATE_OFF =3D 0, /* this means hw_unavailable is !=3D 0 */ + PRV_STATE_PREBOOT, /* we are in a pre-boot state (empty RAM) */ + PRV_STATE_BOOT, /* boot state (fw upload, run fw) */ + PRV_STATE_POSTBOOT, /* after boot state, need reset now */ + PRV_STATE_PREINIT, /* pre-init state */ + PRV_STATE_INIT, /* init state (restore MIB backup to device) */ + PRV_STATE_READY, /* driver&device are in operational state */ + PRV_STATE_SLEEP /* device in sleep mode */ +} islpci_state_t; + +/* ACL using MAC address */ +struct mac_entry { + struct list_head _list; + char addr[ETH_ALEN]; +}; + +struct islpci_acl { + enum { MAC_POLICY_OPEN=3D0, MAC_POLICY_ACCEPT=3D1, MAC_POLICY_REJECT=3D= 2 } policy; + struct list_head mac_list; /* a list of mac_entry */ + int size; /* size of queue */ + struct semaphore sem; /* accessed in ioctls and trap_work */ +}; + +struct islpci_membuf { + int size; /* size of memory */ + void *mem; /* address of memory as seen by CPU */ + dma_addr_t pci_addr; /* address of memory as seen by device */ +}; + +#define MAX_BSS_WPA_IE_COUNT 64 +#define MAX_WPA_IE_LEN 64 +struct islpci_bss_wpa_ie { + struct list_head list; + unsigned long last_update; + u8 bssid[ETH_ALEN]; + u8 wpa_ie[MAX_WPA_IE_LEN]; + size_t wpa_ie_len; +=09 +}; + +typedef struct { + spinlock_t slock; /* generic spinlock; */ +=09 + u32 priv_oid; + + /* our mib cache */ + u32 iw_mode; + struct rw_semaphore mib_sem; + void **mib; + char nickname[IW_ESSID_MAX_SIZE+1]; +=09 + /* Take care of the wireless stats */ + struct work_struct stats_work; + struct semaphore stats_sem; + /* remember when we last updated the stats */ + unsigned long stats_timestamp; + /* The first is accessed under semaphore locking. + * The second is the clean one we return to iwconfig. + */ + struct iw_statistics local_iwstatistics; + struct iw_statistics iwstatistics; + + struct iw_spy_data spy_data; /* iwspy support */ + + int monitor_type; /* ARPHRD_IEEE80211 or ARPHRD_IEEE80211_PRISM */ + + struct islpci_acl acl; + + /* PCI bus allocation & configuration members */ + struct pci_dev *pdev; /* PCI structure information */ + u32 pci_state[16]; /* used for suspend/resume */ + char firmware[33]; + + void *device_base; /* ioremapped device base address */ + + /* consistent DMA region */ + void *driver_mem_address; /* base DMA address */ + dma_addr_t device_host_address; /* base DMA address (bus address) */ + dma_addr_t device_psm_buffer; /* host memory for PSM buffering (bus addre= ss) */ + + /* our network_device structure */ + struct net_device *ndev; + + /* device queue interface members */ + struct isl38xx_cb *control_block; /* device control block=20 + (=3D=3D driver_mem_address!) */ + + /* Each queue has three indexes: + * free/index_mgmt/data_rx/tx (called index, see below), + * driver_curr_frag, and device_curr_frag (in the control block) + * All indexes are ever-increasing, but interpreted modulo the + * device queue size when used. + * index <=3D device_curr_frag <=3D driver_curr_frag at all times + * For rx queues, [index, device_curr_frag) contains fragments + * that the interrupt processing needs to handle (owned by driver). + * [device_curr_frag, driver_curr_frag) is the free space in the + * rx queue, waiting for data (owned by device). The driver + * increments driver_curr_frag to indicate to the device that more + * buffers are available. + * If device_curr_frag =3D=3D driver_curr_frag, no more rx buffers are + * available, and the rx DMA engine of the device is halted. + * For tx queues, [index, device_curr_frag) contains fragments + * where tx is done; they need to be freed (owned by driver). + * [device_curr_frag, driver_curr_frag) contains the frames + * that are being transferred (owned by device). The driver + * increments driver_curr_frag to indicate that more tx work + * needs to be done. + */ + u32 index_mgmt_rx; /* real index mgmt rx queue */ + u32 index_mgmt_tx; /* read index mgmt tx queue */ + u32 free_data_rx; /* free pointer data rx queue */ + u32 free_data_tx; /* free pointer data tx queue */ + u32 data_low_tx_full; /* full detected flag */ + + /* frame memory buffers for the device queues */ + struct islpci_membuf mgmt_tx[ISL38XX_CB_MGMT_QSIZE]; + struct islpci_membuf mgmt_rx[ISL38XX_CB_MGMT_QSIZE]; + struct sk_buff *data_low_tx[ISL38XX_CB_TX_QSIZE]; + struct sk_buff *data_low_rx[ISL38XX_CB_RX_QSIZE]; + dma_addr_t pci_map_tx_address[ISL38XX_CB_TX_QSIZE]; + dma_addr_t pci_map_rx_address[ISL38XX_CB_RX_QSIZE]; + + /* driver network interface members */ + struct net_device_stats statistics; + + /* wait for a reset interrupt */ + wait_queue_head_t reset_done; + + /* used by islpci_mgt_transaction */ + struct semaphore mgmt_sem; /* serialize access to mailbox and wqueue */ + struct islpci_mgmtframe *mgmt_received; /* mbox for incoming frame */ + wait_queue_head_t mgmt_wqueue; /* waitqueue for mbox */ + + /* state machine */ + islpci_state_t state; + int state_off; /* enumeration of off-state, if 0 then + * we're not in any off-state */ + + /* WPA stuff */ + int wpa; /* WPA mode enabled */ + struct list_head bss_wpa_list; + int num_bss_wpa; + struct semaphore wpa_sem; + + struct work_struct reset_task; + int reset_task_pending; +} islpci_private; + +static inline islpci_state_t +islpci_get_state(islpci_private *priv) +{ + /* lock */ + return priv->state; + /* unlock */ +} + +islpci_state_t islpci_set_state(islpci_private *priv, islpci_state_t new_s= tate); + +#define ISLPCI_TX_TIMEOUT (2*HZ) + +irqreturn_t islpci_interrupt(int, void *, struct pt_regs *); + +int prism54_post_setup(islpci_private *, int); +int islpci_reset(islpci_private *, int); + +static inline void +islpci_trigger(islpci_private *priv) +{ + isl38xx_trigger_device(islpci_get_state(priv) =3D=3D PRV_STATE_SLEEP, + priv->device_base); +} + +struct net_device_stats *islpci_statistics(struct net_device *); + +int islpci_free_memory(islpci_private *); +struct net_device *islpci_setup(struct pci_dev *); +#endif /* _ISLPCI_DEV_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_eth.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_eth.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_eth.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_eth.c 2004-07-= 21 09:00:04.000000000 +0000 @@ -0,0 +1,518 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2004 Aurelien Alleaume + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include + +#include +#include +#include +#include +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_eth.h" +#include "islpci_mgt.h" +#include "oid_mgt.h" + +/*************************************************************************= ***** + Network Interface functions +**************************************************************************= ****/ +void +islpci_eth_cleanup_transmit(islpci_private *priv, + isl38xx_control_block *control_block) +{ + struct sk_buff *skb; + u32 index; + + /* compare the control block read pointer with the free pointer */ + while (priv->free_data_tx !=3D + le32_to_cpu(control_block-> + device_curr_frag[ISL38XX_CB_TX_DATA_LQ])) { + /* read the index of the first fragment to be freed */ + index =3D priv->free_data_tx % ISL38XX_CB_TX_QSIZE; + + /* check for holes in the arrays caused by multi fragment frames=20 + * searching for the last fragment of a frame */ + if (priv->pci_map_tx_address[index] !=3D (dma_addr_t) NULL) { + /* entry is the last fragment of a frame + * free the skb structure and unmap pci memory */ + skb =3D priv->data_low_tx[index]; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "cleanup skb %p skb->data %p skb->len %u truesize %u\n ", + skb, skb->data, skb->len, skb->truesize); +#endif + + pci_unmap_single(priv->pdev, + priv->pci_map_tx_address[index], + skb->len, PCI_DMA_TODEVICE); + dev_kfree_skb_irq(skb); + skb =3D NULL; + } + /* increment the free data low queue pointer */ + priv->free_data_tx++; + } +} + +int +islpci_eth_transmit(struct sk_buff *skb, struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D priv->control_block; + u32 index; + dma_addr_t pci_map_address; + int frame_size; + isl38xx_fragment *fragment; + int offset; + struct sk_buff *newskb; + int newskb_offset; + unsigned long flags; + unsigned char wds_mac[6]; + u32 curr_frag; + int err =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_transmit \n"); +#endif + + /* lock the driver code */ + spin_lock_irqsave(&priv->slock, flags); + + /* determine the amount of fragments needed to store the frame */ + + frame_size =3D skb->len < ETH_ZLEN ? ETH_ZLEN : skb->len; + if (init_wds) + frame_size +=3D 6; + + /* check whether the destination queue has enough fragments for the frame= */ + curr_frag =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ]); + if (unlikely(curr_frag - priv->free_data_tx >=3D ISL38XX_CB_TX_QSIZE)) { + printk(KERN_ERR "%s: transmit device queue full when awake\n", + ndev->name); + netif_stop_queue(ndev); + + /* trigger the device */ + isl38xx_w32_flush(priv->device_base, ISL38XX_DEV_INT_UPDATE, + ISL38XX_DEV_INT_REG); + udelay(ISL38XX_WRITEIO_DELAY); + + err =3D -EBUSY; + goto drop_free; + } + /* Check alignment and WDS frame formatting. The start of the packet shou= ld + * be aligned on a 4-byte boundary. If WDS is enabled add another 6 bytes + * and add WDS address information */ + if (likely(((long) skb->data & 0x03) | init_wds)) { + /* get the number of bytes to add and re-allign */ + offset =3D (4 - (long) skb->data) & 0x03; + offset +=3D init_wds ? 6 : 0; + + /* check whether the current skb can be used */ + if (!skb_cloned(skb) && (skb_tailroom(skb) >=3D offset)) { + unsigned char *src =3D skb->data; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "skb offset %i wds %i\n", offset, + init_wds); +#endif + + /* align the buffer on 4-byte boundary */ + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + if (init_wds) { + /* wds requires an additional address field of 6 bytes */ + skb_put(skb, 6); +#ifdef ISLPCI_ETH_DEBUG + printk("islpci_eth_transmit:wds_mac\n"); +#endif + memmove(skb->data + 6, src, skb->len); + memcpy(skb->data, wds_mac, 6); + } else { + memmove(skb->data, src, skb->len); + } + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "memmove %p %p %i \n", skb->data, + src, skb->len); +#endif + } else { + newskb =3D + dev_alloc_skb(init_wds ? skb->len + 6 : skb->len); + if (unlikely(newskb =3D=3D NULL)) { + printk(KERN_ERR "%s: Cannot allocate skb\n", + ndev->name); + err =3D -ENOMEM; + goto drop_free; + } + newskb_offset =3D (4 - (long) newskb->data) & 0x03; + + /* Check if newskb->data is aligned */ + if (newskb_offset) + skb_reserve(newskb, newskb_offset); + + skb_put(newskb, init_wds ? skb->len + 6 : skb->len); + if (init_wds) { + memcpy(newskb->data + 6, skb->data, skb->len); + memcpy(newskb->data, wds_mac, 6); +#ifdef ISLPCI_ETH_DEBUG + printk("islpci_eth_transmit:wds_mac\n"); +#endif + } else + memcpy(newskb->data, skb->data, skb->len); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "memcpy %p %p %i wds %i\n", + newskb->data, skb->data, skb->len, init_wds); +#endif + + newskb->dev =3D skb->dev; + dev_kfree_skb(skb); + skb =3D newskb; + } + } + /* display the buffer contents for debugging */ +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_BUFFER_CONTENTS, "\ntx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* map the skb buffer to pci memory for DMA operation */ + pci_map_address =3D pci_map_single(priv->pdev, + (void *) skb->data, skb->len, + PCI_DMA_TODEVICE); + if (unlikely(pci_map_address =3D=3D 0)) { + printk(KERN_WARNING "%s: cannot map buffer to PCI\n", + ndev->name); + + err =3D -EIO; + goto drop_free; + } + /* Place the fragment in the control block structure. */ + index =3D curr_frag % ISL38XX_CB_TX_QSIZE; + fragment =3D &cb->tx_data_low[index]; + + priv->pci_map_tx_address[index] =3D pci_map_address; + /* store the skb address for future freeing */ + priv->data_low_tx[index] =3D skb; + /* set the proper fragment start address and size information */ + fragment->size =3D cpu_to_le16(frame_size); + fragment->flags =3D cpu_to_le16(0); /* set to 1 if more fragments */ + fragment->address =3D cpu_to_le32(pci_map_address); + curr_frag++; + + /* The fragment address in the control block must have been + * written before announcing the frame buffer to device. */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_TX_DATA_LQ] =3D cpu_to_le32(curr_frag); + + if (curr_frag - priv->free_data_tx + ISL38XX_MIN_QTHRESHOLD + > ISL38XX_CB_TX_QSIZE) { + /* stop sends from upper layers */ + netif_stop_queue(ndev); + + /* set the full flag for the transmission queue */ + priv->data_low_tx_full =3D 1; + } + + /* trigger the device */ + islpci_trigger(priv); + + /* unlock the driver code */ + spin_unlock_irqrestore(&priv->slock, flags); + + /* set the transmission time */ + ndev->trans_start =3D jiffies; + priv->statistics.tx_packets++; + priv->statistics.tx_bytes +=3D skb->len; + + return 0; + + drop_free: + /* free the skbuf structure before aborting */ + dev_kfree_skb(skb); + skb =3D NULL; + + priv->statistics.tx_dropped++; + spin_unlock_irqrestore(&priv->slock, flags); + return err; +} + +static inline int +islpci_monitor_rx(islpci_private *priv, struct sk_buff **skb) +{ + /* The card reports full 802.11 packets but with a 20 bytes + * header and without the FCS. But there a is a bit that + * indicates if the packet is corrupted :-) */ + struct rfmon_header *hdr =3D (struct rfmon_header *) (*skb)->data; + if (hdr->flags & 0x01) + /* This one is bad. Drop it ! */ + return -1; + if (priv->ndev->type =3D=3D ARPHRD_IEEE80211_PRISM) { + struct avs_80211_1_header *avs; + /* extract the relevant data from the header */ + u32 clock =3D le32_to_cpu(hdr->clock); + u8 rate =3D hdr->rate; + u16 freq =3D le16_to_cpu(hdr->freq); + u8 rssi =3D hdr->rssi; + + skb_pull(*skb, sizeof (struct rfmon_header)); + + if (skb_headroom(*skb) < sizeof (struct avs_80211_1_header)) { + struct sk_buff *newskb =3D skb_copy_expand(*skb, + sizeof (struct + avs_80211_1_header), + 0, GFP_ATOMIC); + if (newskb) { + dev_kfree_skb_irq(*skb); + *skb =3D newskb; + } else + return -1; + /* This behavior is not very subtile... */ + } + + /* make room for the new header and fill it. */ + avs =3D + (struct avs_80211_1_header *) skb_push(*skb, + sizeof (struct + avs_80211_1_header)); + =09 + avs->version =3D cpu_to_be32(P80211CAPTURE_VERSION); + avs->length =3D cpu_to_be32(sizeof (struct avs_80211_1_header)); + avs->mactime =3D cpu_to_be64(le64_to_cpu(clock)); + avs->hosttime =3D cpu_to_be64(jiffies); + avs->phytype =3D cpu_to_be32(6); /*OFDM: 6 for (g), 8 for (a) */ + avs->channel =3D cpu_to_be32(channel_of_freq(freq)); + avs->datarate =3D cpu_to_be32(rate * 5); + avs->antenna =3D cpu_to_be32(0); /*unknown */ + avs->priority =3D cpu_to_be32(0); /*unknown */ + avs->ssi_type =3D cpu_to_be32(3); /*2: dBm, 3: raw RSSI */ + avs->ssi_signal =3D cpu_to_be32(rssi & 0x7f); + avs->ssi_noise =3D cpu_to_be32(priv->local_iwstatistics.qual.noise); /*b= etter than 'undefined', I assume */ + avs->preamble =3D cpu_to_be32(0); /*unknown */ + avs->encoding =3D cpu_to_be32(0); /*unknown */ + } else + skb_pull(*skb, sizeof (struct rfmon_header)); + + (*skb)->protocol =3D htons(ETH_P_802_2); + (*skb)->mac.raw =3D (*skb)->data; + (*skb)->pkt_type =3D PACKET_OTHERHOST; + + return 0; +} + +int +islpci_eth_receive(islpci_private *priv) +{ + struct net_device *ndev =3D priv->ndev; + isl38xx_control_block *control_block =3D priv->control_block; + struct sk_buff *skb; + u16 size; + u32 index, offset; + unsigned char *src; + int discard =3D 0; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_receive \n"); +#endif + + /* the device has written an Ethernet frame in the data area + * of the sk_buff without updating the structure, do it now */ + index =3D priv->free_data_rx % ISL38XX_CB_RX_QSIZE; + size =3D le16_to_cpu(control_block->rx_data_low[index].size); + skb =3D priv->data_low_rx[index]; + offset =3D ((unsigned long) + le32_to_cpu(control_block->rx_data_low[index].address) - + (unsigned long) skb->data) & 3; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "frq->addr %x skb->data %p skb->len %u offset %u truesize %u\n ", + control_block->rx_data_low[priv->free_data_rx].address, skb->data, + skb->len, offset, skb->truesize); +#endif + + /* delete the streaming DMA mapping before processing the skb */ + pci_unmap_single(priv->pdev, + priv->pci_map_rx_address[index], + MAX_FRAGMENT_SIZE_RX + 2, PCI_DMA_FROMDEVICE); + + /* update the skb structure and allign the buffer */ + skb_put(skb, size); + if (offset) { + /* shift the buffer allocation offset bytes to get the right frame */ + skb_pull(skb, 2); + skb_put(skb, 2); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + /* display the buffer contents for debugging */ + DEBUG(SHOW_BUFFER_CONTENTS, "\nrx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* check whether WDS is enabled and whether the data frame is a WDS frame= */ + + if (init_wds) { + /* WDS enabled, check for the wds address on the first 6 bytes of the bu= ffer */ + src =3D skb->data + 6; + memmove(skb->data, src, skb->len - 6); + skb_trim(skb, skb->len - 6); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Fragment size %i in skb at %p\n", size, skb); + DEBUG(SHOW_TRACING, "Skb data at %p, length %i\n", skb->data, skb->len); + + /* display the buffer contents for debugging */ + DEBUG(SHOW_BUFFER_CONTENTS, "\nrx %p ", skb->data); + display_buffer((char *) skb->data, skb->len); +#endif + + /* do some additional sk_buff and network layer parameters */ + skb->dev =3D ndev; + + /* take care of monitor mode and spy monitoring. */ + if (unlikely(priv->iw_mode =3D=3D IW_MODE_MONITOR)) + discard =3D islpci_monitor_rx(priv, &skb); + else { + if (unlikely(skb->data[2 * ETH_ALEN] =3D=3D 0)) { + /* The packet has a rx_annex. Read it for spy monitoring, Then + * remove it, while keeping the 2 leading MAC addr. + */ + struct iw_quality wstats; + struct rx_annex_header *annex =3D + (struct rx_annex_header *) skb->data; + wstats.level =3D annex->rfmon.rssi; + /* The noise value can be a bit outdated if nobody's=20 + * reading wireless stats... */ + wstats.noise =3D priv->local_iwstatistics.qual.noise; + wstats.qual =3D wstats.level - wstats.noise; + wstats.updated =3D 0x07; + /* Update spy records */ + wireless_spy_update(ndev, annex->addr2, &wstats); + + memcpy(skb->data + sizeof (struct rfmon_header), + skb->data, 2 * ETH_ALEN); + skb_pull(skb, sizeof (struct rfmon_header)); + } + skb->protocol =3D eth_type_trans(skb, ndev); + } + skb->ip_summed =3D CHECKSUM_NONE; + priv->statistics.rx_packets++; + priv->statistics.rx_bytes +=3D size; + + /* deliver the skb to the network layer */ +#ifdef ISLPCI_ETH_DEBUG + printk + ("islpci_eth_receive:netif_rx %2.2X %2.2X %2.2X %2.2X %2.2X %2.2X\n", + skb->data[0], skb->data[1], skb->data[2], skb->data[3], + skb->data[4], skb->data[5]); +#endif + if (unlikely(discard)) { + dev_kfree_skb_irq(skb); + skb =3D NULL; + } else + netif_rx(skb); + + /* increment the read index for the rx data low queue */ + priv->free_data_rx++; + + /* add one or more sk_buff structures */ + while (index =3D + le32_to_cpu(control_block-> + driver_curr_frag[ISL38XX_CB_RX_DATA_LQ]), + index - priv->free_data_rx < ISL38XX_CB_RX_QSIZE) { + /* allocate an sk_buff for received data frames storage + * include any required allignment operations */ + skb =3D dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2); + if (unlikely(skb =3D=3D NULL)) { + /* error allocating an sk_buff structure elements */ + DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb \n"); + break; + } + skb_reserve(skb, (4 - (long) skb->data) & 0x03); + /* store the new skb structure pointer */ + index =3D index % ISL38XX_CB_RX_QSIZE; + priv->data_low_rx[index] =3D skb; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, + "new alloc skb %p skb->data %p skb->len %u index %u truesize %u\n = ", + skb, skb->data, skb->len, index, skb->truesize); +#endif + + /* set the streaming DMA mapping for proper PCI bus operation */ + priv->pci_map_rx_address[index] =3D + pci_map_single(priv->pdev, (void *) skb->data, + MAX_FRAGMENT_SIZE_RX + 2, + PCI_DMA_FROMDEVICE); + if (unlikely(priv->pci_map_rx_address[index] =3D=3D (dma_addr_t) NULL)) { + /* error mapping the buffer to device accessable memory address */ + DEBUG(SHOW_ERROR_MESSAGES, + "Error mapping DMA address\n"); + + /* free the skbuf structure before aborting */ + dev_kfree_skb_irq((struct sk_buff *) skb); + skb =3D NULL; + break; + } + /* update the fragment address */ + control_block->rx_data_low[index].address =3D cpu_to_le32((u32) + priv-> + pci_map_rx_address + [index]); + wmb(); + + /* increment the driver read pointer */ + add_le32p((u32 *) &control_block-> + driver_curr_frag[ISL38XX_CB_RX_DATA_LQ], 1); + } + + /* trigger the device */ + islpci_trigger(priv); + + return 0; +} + +void +islpci_do_reset_and_wake(void *data) +{ + islpci_private *priv =3D (islpci_private *) data; + islpci_reset(priv, 1); + netif_wake_queue(priv->ndev); + priv->reset_task_pending =3D 0; +} + +void +islpci_eth_tx_timeout(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + struct net_device_stats *statistics =3D &priv->statistics; + + /* increment the transmit error counter */ + statistics->tx_errors++; + + if (!priv->reset_task_pending) { + priv->reset_task_pending =3D 1; + netif_stop_queue(ndev); + schedule_work(&priv->reset_task); + } + + return; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_eth.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_eth.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_eth.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_eth.h 2004-07-= 21 09:00:04.000000000 +0000 @@ -0,0 +1,73 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISLPCI_ETH_H +#define _ISLPCI_ETH_H + +#include "isl_38xx.h" +#include "islpci_dev.h" + +struct rfmon_header { + u16 unk0; /* =3D 0x0000 */ + u16 length; /* =3D 0x1400 */ + u32 clock; /* 1MHz clock */ + u8 flags; + u8 unk1; + u8 rate; + u8 unk2; + u16 freq; + u16 unk3; + u8 rssi; + u8 padding[3]; +} __attribute__ ((packed)); + +struct rx_annex_header { + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + struct rfmon_header rfmon; +} __attribute__ ((packed)); + +/* wlan-ng (and hopefully others) AVS header, version one. Fields in + * network byte order. */ +#define P80211CAPTURE_VERSION 0x80211001 + +struct avs_80211_1_header { + uint32_t version; + uint32_t length; + uint64_t mactime; + uint64_t hosttime; + uint32_t phytype; + uint32_t channel; + uint32_t datarate; + uint32_t antenna; + uint32_t priority; + uint32_t ssi_type; + int32_t ssi_signal; + int32_t ssi_noise; + uint32_t preamble; + uint32_t encoding; +}; + +void islpci_eth_cleanup_transmit(islpci_private *, isl38xx_control_block *= ); +int islpci_eth_transmit(struct sk_buff *, struct net_device *); +int islpci_eth_receive(islpci_private *); +void islpci_eth_tx_timeout(struct net_device *); +void islpci_do_reset_and_wake(void *data); + +#endif /* _ISL_GEN_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_hotplug.c linux-2.4.26-prism54/drivers/net/wireless/prism54/i= slpci_hotplug.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_hotplug.c 1970-01-01 0= 0:00:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_hotplug.c 2004= -07-21 09:00:04.000000000 +0000 @@ -0,0 +1,494 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Herbert Valerio Riedel + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include +#include +#include +#include /* For __init, __exit */ + +#include "prismcompat.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" /* for pc_debug */ +#include "isl_oid.h" + +#define DRV_NAME "prism54" +#define DRV_VERSION "1.2" + +MODULE_AUTHOR("[Intersil] R.Bastings and W.Termorshuizen, The prism54.org = Development Team "); +MODULE_DESCRIPTION("The Prism54 802.11 Wireless LAN adapter"); +MODULE_LICENSE("GPL"); + +static int init_pcitm =3D 0; +module_param(init_pcitm, int, 0); + +/* In this order: vendor, device, subvendor, subdevice, class, class_mask, + * driver_data=20 + * If you have an update for this please contact prism54-devel@prism54.org= =20 + * The latest list can be found at http://prism54.org/supported_cards.php = */ +static const struct pci_device_id prism54_id_tbl[] =3D { + /* 3COM 3CRWE154G72 Wireless LAN adapter */ + { + PCIVENDOR_3COM, PCIDEVICE_3COM6001, + PCIVENDOR_3COM, PCIDEVICE_3COM6001, + 0, 0, 0 + }, + + /* D-Link Air Plus Xtreme G A1 - DWL-g650 A1 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_DLINK, 0x3202UL,=20 + 0, 0, 0 + }, + + /* I-O Data WN-G54/CB - WN-G54/CB */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_IODATA, 0xd019UL,=20 + 0, 0, 0 + }, + + /* Netgear WG511 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_NETGEAR, 0x4800UL, + 0, 0, 0 + }, + + /* Tekram Technology clones, Allnet, Netcomm, Zyxel */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_TTL, 0x1605UL, + 0, 0, 0 + }, + + /* SMC2802W */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0x2802UL, + 0, 0, 0 + }, + + /* SMC2835W */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0x2835UL, + 0, 0, 0 + }, + + /* Corega CG-WLCB54GT */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_ATI, 0xc104UL, + 0, 0, 0 + }, + + /* I4 Z-Com XG-600 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_I4, 0x0014UL, + 0, 0, 0 + }, + + /* I4 Z-Com XG-900 and clones Macer, Ovislink, Planex, Peabird, */ + /* Sitecom, Xterasys */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_I4, 0x0020UL, + 0, 0, 0 + }, + + /* SMC 2802W V2 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_ACCTON, 0xee03UL, + 0, 0, 0 + }, + + /* SMC 2835W V2 */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCIVENDOR_SMC, 0xa835UL, + 0, 0, 0 + }, + + /* Intersil PRISM Indigo Wireless LAN adapter */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3877, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, 0 + }, + + /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ + /* Default */ + { + PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, 0 + }, + + /* End of list */ + {0,0,0,0,0,0,0} +}; + +/* register the device with the Hotplug facilities of the kernel */ +MODULE_DEVICE_TABLE(pci, prism54_id_tbl); + +static int prism54_probe(struct pci_dev *, const struct pci_device_id *); +static void prism54_remove(struct pci_dev *); +static int prism54_suspend(struct pci_dev *, u32 state); +static int prism54_resume(struct pci_dev *); + +static struct pci_driver prism54_driver =3D { + .name =3D DRV_NAME, + .id_table =3D prism54_id_tbl, + .probe =3D prism54_probe, + .remove =3D prism54_remove, + .suspend =3D prism54_suspend, + .resume =3D prism54_resume, + /* .enable_wake ; we don't support this yet */ +}; + +static void +prism54_get_card_model(struct net_device *ndev) +{ + islpci_private *priv; + char *modelp; + int notwork =3D 0; + + priv =3D netdev_priv(ndev); + switch (priv->pdev->subsystem_device) { + case PCIDEVICE_ISL3877: + modelp =3D "PRISM Indigo"; + break; + case PCIDEVICE_ISL3886: + modelp =3D "PRISM Javelin / Xbow"; + break; + case PCIDEVICE_3COM6001: + modelp =3D "3COM 3CRWE154G72"; + break; + case 0x3202UL: + modelp =3D "D-Link DWL-g650 A1"; + break; + case 0xd019UL: + modelp =3D "WN-G54/CB"; + break; + case 0x4800UL: + modelp =3D "Netgear WG511"; + break; + case 0x2802UL: + modelp =3D "SMC2802W"; + break; + case 0xee03UL: + modelp =3D "SMC2802W V2"; + notwork =3D 1; + break; + case 0x2835UL: + modelp =3D "SMC2835W"; + break; + case 0xa835UL: + modelp =3D "SMC2835W V2"; + notwork =3D 1; + break; + case 0xc104UL: + modelp =3D "CG-WLCB54GT"; + break; + case 0x1605UL: + modelp =3D "Tekram Technology clone"; + break; + /* Let's leave this one out for now since it seems bogus/wrong=20 + * Even if the manufacturer did use 0x0000UL it may not be correct + * by their part, therefore deserving no name ;) */ + /* case 0x0000UL:=20 + * modelp =3D "SparkLAN WL-850F"; + * break;*/ + + /* We have two reported for the one below :( */ + case 0x0014UL: + modelp =3D "I4 Z-Com XG-600 and clones"; + break; + case 0x0020UL: + modelp =3D "I4 Z-Com XG-900 and clones"; + break; +/* Default it */ +/* + case PCIDEVICE_ISL3890: + modelp =3D "PRISM Duette/GT"; + break; +*/ + default: + modelp =3D "PRISM Duette/GT"; + } + printk(KERN_DEBUG "%s: %s driver detected card model: %s\n", + ndev->name, DRV_NAME, modelp); + if ( notwork ) { + printk(KERN_DEBUG "%s: %s Warning - This may not work\n", + ndev->name, DRV_NAME); + } + return; +} + +/*************************************************************************= ***** + Module initialization functions +**************************************************************************= ****/ + +int +prism54_probe(struct pci_dev *pdev, const struct pci_device_id *id) +{ + struct net_device *ndev; + u8 latency_tmr; + u32 mem_addr; + islpci_private *priv; + int rvalue; + + /* TRACE(DRV_NAME); */ +=09 +=09 + /* Enable the pci device */ + if (pci_enable_device(pdev)) { + printk(KERN_ERR "%s: pci_enable_device() failed.\n", DRV_NAME); + return -ENODEV; + } + + /* check whether the latency timer is set correctly */ + pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency_tmr); +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "latency timer: %x\n", latency_tmr); +#endif + if (latency_tmr < PCIDEVICE_LATENCY_TIMER_MIN) { + /* set the latency timer */ + pci_write_config_byte(pdev, PCI_LATENCY_TIMER, + PCIDEVICE_LATENCY_TIMER_VAL); + } + + /* enable PCI DMA */ + if (pci_set_dma_mask(pdev, 0xffffffff)) { + printk(KERN_ERR "%s: 32-bit PCI DMA not supported", DRV_NAME); + goto do_pci_disable_device; + } + + /* 0x40 is the programmable timer to configure the response timeout (TRDY= _TIMEOUT) + * 0x41 is the programmable timer to configure the retry timeout (RETRY_T= IMEOUT) + * The RETRY_TIMEOUT is used to set the number of retries that the core,= as a + * Master, will perform before abandoning a cycle. The default value for + * RETRY_TIMEOUT is 0x80, which far exceeds the PCI 2.1 requirement for = new + * devices. A write of zero to the RETRY_TIMEOUT register disables this + * function to allow use with any non-compliant legacy devices that may + * execute more retries. + * + * Writing zero to both these two registers will disable both timeouts a= nd + * *can* solve problems caused by devices that are slow to respond. + * Make this configurable - MSW + */ + if ( init_pcitm >=3D 0 ) { + pci_write_config_byte(pdev, 0x40, (u8)init_pcitm); + pci_write_config_byte(pdev, 0x41, (u8)init_pcitm); + } else { + printk(KERN_INFO "PCI TRDY/RETRY unchanged\n"); + } + + /* request the pci device I/O regions */ + rvalue =3D pci_request_regions(pdev, DRV_NAME); + if (rvalue) { + printk(KERN_ERR "%s: pci_request_regions failure (rc=3D%d)\n", + DRV_NAME, rvalue); + goto do_pci_disable_device; + } + + /* check if the memory window is indeed set */ + rvalue =3D pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &mem_addr); + if (rvalue || !mem_addr) { + printk(KERN_ERR "%s: PCI device memory region not configured; fix your B= IOS or CardBus bridge/drivers\n", + DRV_NAME); + goto do_pci_disable_device; + } + + /* enable PCI bus-mastering */ + DEBUG(SHOW_TRACING, "%s: pci_set_master(pdev)\n", DRV_NAME); + pci_set_master(pdev); + + /* enable MWI */ + pci_set_mwi(pdev); + + /* setup the network device interface and its structure */ + if (!(ndev =3D islpci_setup(pdev))) { + /* error configuring the driver as a network device */ + printk(KERN_ERR "%s: could not configure network device\n", + DRV_NAME); + goto do_pci_release_regions; + } + + priv =3D netdev_priv(ndev); + islpci_set_state(priv, PRV_STATE_PREBOOT); /* we are attempting to boot */ + + /* card is in unknown state yet, might have some interrupts pending */ + isl38xx_disable_interrupts(priv->device_base); + + /* request for the interrupt before uploading the firmware */ + rvalue =3D request_irq(pdev->irq, &islpci_interrupt, + SA_SHIRQ, ndev->name, priv); + + if (rvalue) { + /* error, could not hook the handler to the irq */ + printk(KERN_ERR "%s: could not install IRQ handler\n", + ndev->name); + goto do_unregister_netdev; + } + + /* firmware upload is triggered in islpci_open */ + + /* Pretty card model discovery output */ + prism54_get_card_model(ndev); + + return 0; + + do_unregister_netdev: + unregister_netdev(ndev); + islpci_free_memory(priv); + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + do_pci_release_regions: + pci_release_regions(pdev); + do_pci_disable_device: + pci_disable_device(pdev); + return -EIO; +} + +/* set by cleanup_module */ +static volatile int __in_cleanup_module =3D 0; + +/* this one removes one(!!) instance only */ +void +prism54_remove(struct pci_dev *pdev) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + if (!__in_cleanup_module) { + printk(KERN_DEBUG "%s: hot unplug detected\n", ndev->name); + islpci_set_state(priv, PRV_STATE_OFF); + } + + printk(KERN_DEBUG "%s: removing device\n", ndev->name); + + unregister_netdev(ndev); + + /* free the interrupt request */ + + if (islpci_get_state(priv) !=3D PRV_STATE_OFF) { + isl38xx_disable_interrupts(priv->device_base); + islpci_set_state(priv, PRV_STATE_OFF); + /* This bellow causes a lockup at rmmod time. It might be + * because some interrupts still linger after rmmod time,=20 + * see bug #17 */ + /* pci_set_power_state(pdev, 3);*/ /* try to power-off */ + } + + free_irq(pdev->irq, priv); + + /* free the PCI memory and unmap the remapped page */ + islpci_free_memory(priv); + + pci_set_drvdata(pdev, 0); + free_netdev(ndev); + priv =3D 0; + + pci_release_regions(pdev); + + pci_disable_device(pdev); +} + +int +prism54_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + printk(KERN_NOTICE "%s: got suspend request (state %d)\n", + ndev->name, state); + + pci_save_state(pdev, priv->pci_state); + + /* tell the device not to trigger interrupts for now... */ + isl38xx_disable_interrupts(priv->device_base); + + /* from now on assume the hardware was already powered down + and don't touch it anymore */ + islpci_set_state(priv, PRV_STATE_OFF); + + netif_stop_queue(ndev); + netif_device_detach(ndev); + + return 0; +} + +int +prism54_resume(struct pci_dev *pdev) +{ + struct net_device *ndev =3D pci_get_drvdata(pdev); + islpci_private *priv =3D ndev ? netdev_priv(ndev) : 0; + BUG_ON(!priv); + + printk(KERN_NOTICE "%s: got resume request\n", ndev->name); + + pci_restore_state(pdev, priv->pci_state); + + /* alright let's go into the PREBOOT state */ + islpci_reset(priv, 1); + + netif_device_attach(ndev); + netif_start_queue(ndev); + + return 0; +} + +static int __init +prism54_module_init(void) +{ + printk(KERN_INFO "Loaded %s driver, version %s\n", + DRV_NAME, DRV_VERSION); + + __bug_on_wrong_struct_sizes (); + + return pci_module_init(&prism54_driver); +} + +/* by the time prism54_module_exit() terminates, as a postcondition + * all instances will have been destroyed by calls to + * prism54_remove() */ +static void __exit +prism54_module_exit(void) +{ + __in_cleanup_module =3D 1; + + pci_unregister_driver(&prism54_driver); + + printk(KERN_INFO "Unloaded %s driver\n", DRV_NAME); + + __in_cleanup_module =3D 0; +} + +/* register entry points */ +module_init(prism54_module_init); +module_exit(prism54_module_exit); +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_mgt.c linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_mgt.c --- linux-2.4.26/drivers/net/wireless/prism54/islpci_mgt.c 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_mgt.c 2004-07-= 21 09:00:04.000000000 +0000 @@ -0,0 +1,510 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright 2004 Jens Maurer + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include +#include +#include +#include + +#include +#include +#include + +#include "prismcompat.h" +#include "isl_38xx.h" +#include "islpci_mgt.h" +#include "isl_oid.h" /* additional types and defs for isl38xx fw */ +#include "isl_ioctl.h" + +#include + +/*************************************************************************= ***** + Global variable definition section +**************************************************************************= ****/ +int pc_debug =3D VERBOSE; +module_param(pc_debug, int, 0); + +/*************************************************************************= ***** + Driver general functions +**************************************************************************= ****/ +void +display_buffer(char *buffer, int length) +{ + if ((pc_debug & SHOW_BUFFER_CONTENTS) =3D=3D 0) + return; + + while (length > 0) { + printk("[%02x]", *buffer & 255); + length--; + buffer++; + } + + printk("\n"); +} + +/*************************************************************************= **** + Queue handling for management frames +**************************************************************************= ****/ + +/* + * Helper function to create a PIMFOR management frame header. + */ +static void +pimfor_encode_header(int operation, u32 oid, u32 length, pimfor_header_t *= h) +{ + h->version =3D PIMFOR_VERSION; + h->operation =3D operation; + h->device_id =3D PIMFOR_DEV_ID_MHLI_MIB; + h->flags =3D 0; + h->oid =3D cpu_to_be32(oid); + h->length =3D cpu_to_be32(length); +} + +/* + * Helper function to analyze a PIMFOR management frame header. + */ +static pimfor_header_t * +pimfor_decode_header(void *data, int len) +{ + pimfor_header_t *h =3D data; + + while ((void *) h < data + len) { + if (h->flags & PIMFOR_FLAG_LITTLE_ENDIAN) { + le32_to_cpus(&h->oid); + le32_to_cpus(&h->length); + } else { + be32_to_cpus(&h->oid); + be32_to_cpus(&h->length); + } + if (h->oid !=3D OID_INL_TUNNEL) + return h; + h++; + } + return NULL; +} + +/* + * Fill the receive queue for management frames with fresh buffers. + */ +int +islpci_mgmt_rx_fill(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + u32 curr =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ]); + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgmt_rx_fill \n"); +#endif + + while (curr - priv->index_mgmt_rx < ISL38XX_CB_MGMT_QSIZE) { + u32 index =3D curr % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_rx[index]; + isl38xx_fragment *frag =3D &cb->rx_data_mgmt[index]; + + if (buf->mem =3D=3D NULL) { + buf->mem =3D kmalloc(MGMT_FRAME_SIZE, GFP_ATOMIC); + if (!buf->mem) { + printk(KERN_WARNING + "Error allocating management frame.\n"); + return -ENOMEM; + } + buf->size =3D MGMT_FRAME_SIZE; + } + if (buf->pci_addr =3D=3D 0) { + buf->pci_addr =3D pci_map_single(priv->pdev, buf->mem, + MGMT_FRAME_SIZE, + PCI_DMA_FROMDEVICE); + if (!buf->pci_addr) { + printk(KERN_WARNING + "Failed to make memory DMA'able\n."); + return -ENOMEM; + } + } + + /* be safe: always reset control block information */ + frag->size =3D cpu_to_le16(MGMT_FRAME_SIZE); + frag->flags =3D 0; + frag->address =3D cpu_to_le32(buf->pci_addr); + curr++; + + /* The fragment address in the control block must have + * been written before announcing the frame buffer to + * device */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ] =3D cpu_to_le32(curr); + } + return 0; +} + +/* + * Create and transmit a management frame using "operation" and "oid", + * with arguments data/length. + * We either return an error and free the frame, or we return 0 and + * islpci_mgt_cleanup_transmit() frees the frame in the tx-done + * interrupt. + */ +static int +islpci_mgt_transmit(struct net_device *ndev, int operation, unsigned long = oid, + void *data, int length) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D + (isl38xx_control_block *) priv->control_block; + void *p; + int err =3D -EINVAL; + unsigned long flags; + isl38xx_fragment *frag; + struct islpci_membuf buf; + u32 curr_frag; + int index; + int frag_len =3D length + PIMFOR_HEADER_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_transmit\n"); +#endif + + if (frag_len > MGMT_FRAME_SIZE) { + printk(KERN_DEBUG "%s: mgmt frame too large %d\n", + ndev->name, frag_len); + goto error; + } + + err =3D -ENOMEM; + p =3D buf.mem =3D kmalloc(frag_len, GFP_KERNEL); + if (!buf.mem) { + printk(KERN_DEBUG "%s: cannot allocate mgmt frame\n", + ndev->name); + goto error; + } + buf.size =3D frag_len; + + /* create the header directly in the fragment data area */ + pimfor_encode_header(operation, oid, length, (pimfor_header_t *) p); + p +=3D PIMFOR_HEADER_SIZE; + + if (data) + memcpy(p, data, length); + else + memset(p, 0, length); + +#if VERBOSE > SHOW_ERROR_MESSAGES + { + pimfor_header_t *h =3D buf.mem; + DEBUG(SHOW_PIMFOR_FRAMES, + "PIMFOR: op %i, oid 0x%08lx, device %i, flags 0x%x length 0x%x \n", + h->operation, oid, h->device_id, h->flags, length); + + /* display the buffer contents for debugging */ + display_buffer((char *) h, sizeof (pimfor_header_t)); + display_buffer(p, length); + } +#endif + + err =3D -ENOMEM; + buf.pci_addr =3D pci_map_single(priv->pdev, buf.mem, frag_len, + PCI_DMA_TODEVICE); + if (!buf.pci_addr) { + printk(KERN_WARNING "%s: cannot map PCI memory for mgmt\n", + ndev->name); + goto error_free; + } + + /* Protect the control block modifications against interrupts. */ + spin_lock_irqsave(&priv->slock, flags); + curr_frag =3D le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ]); + if (curr_frag - priv->index_mgmt_tx >=3D ISL38XX_CB_MGMT_QSIZE) { + printk(KERN_WARNING "%s: mgmt tx queue is still full\n", + ndev->name); + goto error_unlock; + } + + /* commit the frame to the tx device queue */ + index =3D curr_frag % ISL38XX_CB_MGMT_QSIZE; + priv->mgmt_tx[index] =3D buf; + frag =3D &cb->tx_data_mgmt[index]; + frag->size =3D cpu_to_le16(frag_len); + frag->flags =3D 0; /* for any other than the last fragment, set to 1 */ + frag->address =3D cpu_to_le32(buf.pci_addr); + + /* The fragment address in the control block must have + * been written before announcing the frame buffer to + * device */ + wmb(); + cb->driver_curr_frag[ISL38XX_CB_TX_MGMTQ] =3D cpu_to_le32(curr_frag + 1); + spin_unlock_irqrestore(&priv->slock, flags); + + /* trigger the device */ + islpci_trigger(priv); + return 0; + + error_unlock: + spin_unlock_irqrestore(&priv->slock, flags); + error_free: + kfree(buf.mem); + error: + return err; +} + +/* + * Receive a management frame from the device. + * This can be an arbitrary number of traps, and at most one response + * frame for a previous request sent via islpci_mgt_transmit(). + */ +int +islpci_mgt_receive(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D + (isl38xx_control_block *) priv->control_block; + u32 curr_frag; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_receive \n"); +#endif + + /* Only once per interrupt, determine fragment range to + * process. This avoids an endless loop (i.e. lockup) if + * frames come in faster than we can process them. */ + curr_frag =3D le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_RX_MGMTQ]); + barrier(); + + for (; priv->index_mgmt_rx < curr_frag; priv->index_mgmt_rx++) { + pimfor_header_t *header; + u32 index =3D priv->index_mgmt_rx % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_rx[index]; + u16 frag_len; + int size; + struct islpci_mgmtframe *frame; + + /* I have no idea (and no documentation) if flags !=3D 0 + * is possible. Drop the frame, reuse the buffer. */ + if (le16_to_cpu(cb->rx_data_mgmt[index].flags) !=3D 0) { + printk(KERN_WARNING "%s: unknown flags 0x%04x\n", + ndev->name, + le16_to_cpu(cb->rx_data_mgmt[index].flags)); + continue; + } + + /* The device only returns the size of the header(s) here. */ + frag_len =3D le16_to_cpu(cb->rx_data_mgmt[index].size); + + /* + * We appear to have no way to tell the device the + * size of a receive buffer. Thus, if this check + * triggers, we likely have kernel heap corruption. */ + if (frag_len > MGMT_FRAME_SIZE) { + printk(KERN_WARNING + "%s: Bogus packet size of %d (%#x).\n", + ndev->name, frag_len, frag_len); + frag_len =3D MGMT_FRAME_SIZE; + } + + /* Ensure the results of device DMA are visible to the CPU. */ + pci_dma_sync_single(priv->pdev, buf->pci_addr, + buf->size, PCI_DMA_FROMDEVICE); + + /* Perform endianess conversion for PIMFOR header in-place. */ + header =3D pimfor_decode_header(buf->mem, frag_len); + if (!header) { + printk(KERN_WARNING "%s: no PIMFOR header found\n", + ndev->name); + continue; + } + + /* The device ID from the PIMFOR packet received from + * the MVC is always 0. We forward a sensible device_id. + * Not that anyone upstream would care... */ + header->device_id =3D priv->ndev->ifindex; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_PIMFOR_FRAMES, + "PIMFOR: op %i, oid 0x%08x, device %i, flags 0x%x length 0x%x \n", + header->operation, header->oid, header->device_id, + header->flags, header->length); + + /* display the buffer contents for debugging */ + display_buffer((char *) header, PIMFOR_HEADER_SIZE); + display_buffer((char *) header + PIMFOR_HEADER_SIZE, + header->length); +#endif + + /* nobody sends these */ + if (header->flags & PIMFOR_FLAG_APPLIC_ORIGIN) { + printk(KERN_DEBUG + "%s: errant PIMFOR application frame\n", + ndev->name); + continue; + } + + /* Determine frame size, skipping OID_INL_TUNNEL headers. */ + size =3D PIMFOR_HEADER_SIZE + header->length; + frame =3D kmalloc(sizeof (struct islpci_mgmtframe) + size, + GFP_ATOMIC); + if (!frame) { + printk(KERN_WARNING + "%s: Out of memory, cannot handle oid 0x%08x\n", + ndev->name, header->oid); + continue; + } + frame->ndev =3D ndev; + memcpy(&frame->buf, header, size); + frame->header =3D (pimfor_header_t *) frame->buf; + frame->data =3D frame->buf + PIMFOR_HEADER_SIZE; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_PIMFOR_FRAMES, + "frame: header: %p, data: %p, size: %d\n", + frame->header, frame->data, size); +#endif + + if (header->operation =3D=3D PIMFOR_OP_TRAP) { +#if VERBOSE > SHOW_ERROR_MESSAGES + printk(KERN_DEBUG + "TRAP: oid 0x%x, device %i, flags 0x%x length %i\n", + header->oid, header->device_id, header->flags, + header->length); +#endif + + /* Create work to handle trap out of interrupt + * context. */ + INIT_WORK(&frame->ws, prism54_process_trap, frame); + schedule_work(&frame->ws); + + } else { + /* Signal the one waiting process that a response + * has been received. */ + if ((frame =3D xchg(&priv->mgmt_received, frame)) !=3D NULL) { + printk(KERN_WARNING + "%s: mgmt response not collected\n", + ndev->name); + kfree(frame); + } +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Wake up Mgmt Queue\n"); +#endif + wake_up(&priv->mgmt_wqueue); + } + + } + + return 0; +} + +/* + * Cleanup the transmit queue by freeing all frames handled by the device. + */ +void +islpci_mgt_cleanup_transmit(struct net_device *ndev) +{ + islpci_private *priv =3D netdev_priv(ndev); + isl38xx_control_block *cb =3D /* volatile not needed */ + (isl38xx_control_block *) priv->control_block; + u32 curr_frag; + +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_cleanup_transmit\n"); +#endif + + /* Only once per cleanup, determine fragment range to + * process. This avoids an endless loop (i.e. lockup) if + * the device became confused, incrementing device_curr_frag + * rapidly. */ + curr_frag =3D le32_to_cpu(cb->device_curr_frag[ISL38XX_CB_TX_MGMTQ]); + barrier(); + + for (; priv->index_mgmt_tx < curr_frag; priv->index_mgmt_tx++) { + int index =3D priv->index_mgmt_tx % ISL38XX_CB_MGMT_QSIZE; + struct islpci_membuf *buf =3D &priv->mgmt_tx[index]; + pci_unmap_single(priv->pdev, buf->pci_addr, buf->size, + PCI_DMA_TODEVICE); + buf->pci_addr =3D 0; + kfree(buf->mem); + buf->mem =3D NULL; + buf->size =3D 0; + } +} + +/* + * Perform one request-response transaction to the device. + */ +int +islpci_mgt_transaction(struct net_device *ndev, + int operation, unsigned long oid, + void *senddata, int sendlen, + struct islpci_mgmtframe **recvframe) +{ + islpci_private *priv =3D netdev_priv(ndev); + const long wait_cycle_jiffies =3D (ISL38XX_WAIT_CYCLE * 10 * HZ) / 1000; + long timeout_left =3D ISL38XX_MAX_WAIT_CYCLES * wait_cycle_jiffies; + int err; + DEFINE_WAIT(wait); + + *recvframe =3D NULL; + + if (down_interruptible(&priv->mgmt_sem)) + return -ERESTARTSYS; + + prepare_to_wait(&priv->mgmt_wqueue, &wait, TASK_UNINTERRUPTIBLE); + err =3D islpci_mgt_transmit(ndev, operation, oid, senddata, sendlen); + if (err) + goto out; + + err =3D -ETIMEDOUT; + while (timeout_left > 0) { + int timeleft; + struct islpci_mgmtframe *frame; + + timeleft =3D schedule_timeout(wait_cycle_jiffies); + frame =3D xchg(&priv->mgmt_received, NULL); + if (frame) { + if (frame->header->oid =3D=3D oid) { + *recvframe =3D frame; + err =3D 0; + goto out; + } else { + printk(KERN_DEBUG + "%s: expecting oid 0x%x, received 0x%x.\n", + ndev->name, (unsigned int) oid, + frame->header->oid); + kfree(frame); + frame =3D NULL; + } + } + if (timeleft =3D=3D 0) { + printk(KERN_DEBUG + "%s: timeout waiting for mgmt response %lu, " + "triggering device\n", + ndev->name, timeout_left); + islpci_trigger(priv); + } + timeout_left +=3D timeleft - wait_cycle_jiffies; + } + printk(KERN_WARNING "%s: timeout waiting for mgmt response\n", + ndev->name); + + /* TODO: we should reset the device here */ =20 + out: + finish_wait(&priv->mgmt_wqueue, &wait); + up(&priv->mgmt_sem); + return err; +} + diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/islpci_mgt.h linux-2.4.26-prism54/drivers/net/wireless/prism54/islpc= i_mgt.h --- linux-2.4.26/drivers/net/wireless/prism54/islpci_mgt.h 1970-01-01 00:00= :00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/islpci_mgt.h 2004-07-= 21 09:00:04.000000000 +0000 @@ -0,0 +1,162 @@ +/* + * =20 + * Copyright (C) 2002 Intersil Americas Inc. + * Copyright (C) 2003 Luis R. Rodriguez + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#ifndef _ISLPCI_MGT_H +#define _ISLPCI_MGT_H + +#include +#include + +/* + * Function definitions + */ + +#define K_DEBUG(f, m, args...) do { if(f & m) printk(KERN_DEBUG args); } w= hile(0) +#define DEBUG(f, args...) K_DEBUG(f, pc_debug, args) + +#define TRACE(devname) K_DEBUG(SHOW_TRACING, VERBOSE, "%s: -> " __FUNCT= ION__ "()\n", devname) + +extern int pc_debug; +#define init_wds 0 /* help compiler optimize away dead code */ + + +/* General driver definitions */ +#define PCIVENDOR_INTERSIL 0x1260UL +#define PCIVENDOR_3COM 0x10b7UL +#define PCIVENDOR_DLINK 0x1186UL +#define PCIVENDOR_I4 0x17cfUL +#define PCIVENDOR_IODATA 0x10fcUL +#define PCIVENDOR_NETGEAR 0x1385UL +#define PCIVENDOR_SMC 0x10b8UL +#define PCIVENDOR_ACCTON 0x1113UL +#define PCIVENDOR_ATI 0x1259UL +#define PCIVENDOR_TTL 0x16a5UL + +#define PCIDEVICE_ISL3877 0x3877UL +#define PCIDEVICE_ISL3886 0x3886UL +#define PCIDEVICE_ISL3890 0x3890UL +#define PCIDEVICE_3COM6001 0x6001UL +#define PCIDEVICE_LATENCY_TIMER_MIN 0x40 +#define PCIDEVICE_LATENCY_TIMER_VAL 0x50 + +/* Debugging verbose definitions */ +#define SHOW_NOTHING 0x00 /* overrules everythi= ng */ +#define SHOW_ANYTHING 0xFF +#define SHOW_ERROR_MESSAGES 0x01 +#define SHOW_TRAPS 0x02 +#define SHOW_FUNCTION_CALLS 0x04 +#define SHOW_TRACING 0x08 +#define SHOW_QUEUE_INDEXES 0x10 +#define SHOW_PIMFOR_FRAMES 0x20 +#define SHOW_BUFFER_CONTENTS 0x40 +#define VERBOSE 0x01 + +/* Default card definitions */ +#define CARD_DEFAULT_CHANNEL 6 +#define CARD_DEFAULT_MODE INL_MODE_CLIENT +#define CARD_DEFAULT_IW_MODE IW_MODE_INFRA +#define CARD_DEFAULT_BSSTYPE DOT11_BSSTYPE_INFRA +#define CARD_DEFAULT_CLIENT_SSID "" +#define CARD_DEFAULT_AP_SSID "default" +#define CARD_DEFAULT_KEY1 "default_key_1" +#define CARD_DEFAULT_KEY2 "default_key_2" +#define CARD_DEFAULT_KEY3 "default_key_3" +#define CARD_DEFAULT_KEY4 "default_key_4" +#define CARD_DEFAULT_WEP 0 +#define CARD_DEFAULT_FILTER 0 +#define CARD_DEFAULT_WDS 0 +#define CARD_DEFAULT_AUTHEN DOT11_AUTH_OS +#define CARD_DEFAULT_DOT1X 0 +#define CARD_DEFAULT_MLME_MODE DOT11_MLME_AUTO +#define CARD_DEFAULT_CONFORMANCE OID_INL_CONFORMANCE_NONE +#define CARD_DEFAULT_PROFILE DOT11_PROFILE_MIXED_G_WIFI +#define CARD_DEFAULT_MAXFRAMEBURST DOT11_MAXFRAMEBURST_MIXED_SAFE + +/* PIMFOR package definitions */ +#define PIMFOR_ETHERTYPE 0x8828 +#define PIMFOR_HEADER_SIZE 12 +#define PIMFOR_VERSION 1 +#define PIMFOR_OP_GET 0 +#define PIMFOR_OP_SET 1 +#define PIMFOR_OP_RESPONSE 2 +#define PIMFOR_OP_ERROR 3 +#define PIMFOR_OP_TRAP 4 +#define PIMFOR_OP_RESERVED 5 /* till 255 */ +#define PIMFOR_DEV_ID_MHLI_MIB 0 +#define PIMFOR_FLAG_APPLIC_ORIGIN 0x01 +#define PIMFOR_FLAG_LITTLE_ENDIAN 0x02 + +static inline void +add_le32p(u32 * le_number, u32 add) +{ + *le_number =3D cpu_to_le32(le32_to_cpup(le_number) + add); +} + +void display_buffer(char *, int); + +/* + * Type definition section + * + * the structure defines only the header allowing copyless + * frame handling + */ +typedef struct { + u8 version; + u8 operation; + u32 oid; + u8 device_id; + u8 flags; + u32 length; +} __attribute__ ((packed)) +pimfor_header_t; + +/* A received and interrupt-processed management frame, either for + * schedule_work(prism54_process_trap) or for priv->mgmt_received, + * processed by islpci_mgt_transaction(). */ +struct islpci_mgmtframe { + struct net_device *ndev; /* pointer to network device */ + pimfor_header_t *header; /* payload header, points into buf */ + void *data; /* payload ex header, points into buf */ + struct work_struct ws; /* argument for schedule_work() */ + char buf[0]; /* fragment buffer */ +}; + +int +islpci_mgt_receive(struct net_device *ndev); + +int +islpci_mgmt_rx_fill(struct net_device *ndev); + +void +islpci_mgt_cleanup_transmit(struct net_device *ndev); + +int +islpci_mgt_transaction(struct net_device *ndev, + int operation, unsigned long oid, + void *senddata, int sendlen, + struct islpci_mgmtframe **recvframe); + +static inline void +islpci_mgt_release(struct islpci_mgmtframe *frame) +{ + kfree(frame); +} + +#endif /* _ISLPCI_MGT_H */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/oid_mgt.c linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.4.26/drivers/net/wireless/prism54/oid_mgt.c 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.c 2004-07-21 = 09:00:04.000000000 +0000 @@ -0,0 +1,807 @@ +/* =20 + * Copyright (C) 2003,2004 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#include "prismcompat.h" +#include "islpci_dev.h" +#include "islpci_mgt.h" +#include "isl_oid.h" +#include "oid_mgt.h" +#include "isl_ioctl.h" + +/* to convert between channel and freq */ +const int frequency_list_bg[] =3D { 2412, 2417, 2422, 2427, 2432, 2437, 24= 42, + 2447, 2452, 2457, 2462, 2467, 2472, 2484 +}; + +int +channel_of_freq(int f) +{ + int c =3D 0; + + if ((f >=3D 2412) && (f <=3D 2484)) { + while ((c < 14) && (f !=3D frequency_list_bg[c])) + c++; + return (c >=3D 14) ? 0 : ++c; + } else if ((f >=3D (int) 5000) && (f <=3D (int) 6000)) { + return ( (f - 5000) / 5 ); + } else + return 0; +} + +#define OID_STRUCT(name,oid,s,t) [name] =3D {oid, 0, sizeof(s), t} +#define OID_STRUCT_C(name,oid,s,t) OID_STRUCT(name,oid,s,t | OID_FLAG_CACH= ED) +#define OID_U32(name,oid) OID_STRUCT(name,oid,u32,OID_TYPE_U32) +#define OID_U32_C(name,oid) OID_STRUCT_C(name,oid,u32,OID_TYPE_U32) +#define OID_STRUCT_MLME(name,oid) OID_STRUCT(name,oid,struct obj_mlme,OID_= TYPE_MLME) +#define OID_STRUCT_MLMEEX(name,oid) OID_STRUCT(name,oid,struct obj_mlmeex,= OID_TYPE_MLMEEX) + +#define OID_UNKNOWN(name,oid) OID_STRUCT(name,oid,0,0) + +struct oid_t isl_oid[] =3D { + OID_STRUCT(GEN_OID_MACADDRESS, 0x00000000, u8[6], OID_TYPE_ADDR), + OID_U32(GEN_OID_LINKSTATE, 0x00000001), + OID_UNKNOWN(GEN_OID_WATCHDOG, 0x00000002), + OID_UNKNOWN(GEN_OID_MIBOP, 0x00000003), + OID_UNKNOWN(GEN_OID_OPTIONS, 0x00000004), + OID_UNKNOWN(GEN_OID_LEDCONFIG, 0x00000005), + + /* 802.11 */ + OID_U32_C(DOT11_OID_BSSTYPE, 0x10000000), + OID_STRUCT_C(DOT11_OID_BSSID, 0x10000001, u8[6], OID_TYPE_RAW), + OID_STRUCT_C(DOT11_OID_SSID, 0x10000002, struct obj_ssid, + OID_TYPE_SSID), + OID_U32(DOT11_OID_STATE, 0x10000003), + OID_U32(DOT11_OID_AID, 0x10000004), + OID_STRUCT(DOT11_OID_COUNTRYSTRING, 0x10000005, u8[4], OID_TYPE_RAW), + OID_STRUCT_C(DOT11_OID_SSIDOVERRIDE, 0x10000006, struct obj_ssid, + OID_TYPE_SSID), + + OID_U32(DOT11_OID_MEDIUMLIMIT, 0x11000000), + OID_U32_C(DOT11_OID_BEACONPERIOD, 0x11000001), + OID_U32(DOT11_OID_DTIMPERIOD, 0x11000002), + OID_U32(DOT11_OID_ATIMWINDOW, 0x11000003), + OID_U32(DOT11_OID_LISTENINTERVAL, 0x11000004), + OID_U32(DOT11_OID_CFPPERIOD, 0x11000005), + OID_U32(DOT11_OID_CFPDURATION, 0x11000006), + + OID_U32_C(DOT11_OID_AUTHENABLE, 0x12000000), + OID_U32_C(DOT11_OID_PRIVACYINVOKED, 0x12000001), + OID_U32_C(DOT11_OID_EXUNENCRYPTED, 0x12000002), + OID_U32_C(DOT11_OID_DEFKEYID, 0x12000003), + [DOT11_OID_DEFKEYX] =3D {0x12000004, 3, sizeof (struct obj_key), + OID_FLAG_CACHED | OID_TYPE_KEY}, /* DOT11_OID_DEFKEY1,...DOT11_O= ID_DEFKEY4 */ + OID_UNKNOWN(DOT11_OID_STAKEY, 0x12000008), + OID_U32(DOT11_OID_REKEYTHRESHOLD, 0x12000009), + OID_UNKNOWN(DOT11_OID_STASC, 0x1200000a), + + OID_U32(DOT11_OID_PRIVTXREJECTED, 0x1a000000), + OID_U32(DOT11_OID_PRIVRXPLAIN, 0x1a000001), + OID_U32(DOT11_OID_PRIVRXFAILED, 0x1a000002), + OID_U32(DOT11_OID_PRIVRXNOKEY, 0x1a000003), + + OID_U32_C(DOT11_OID_RTSTHRESH, 0x13000000), + OID_U32_C(DOT11_OID_FRAGTHRESH, 0x13000001), + OID_U32_C(DOT11_OID_SHORTRETRIES, 0x13000002), + OID_U32_C(DOT11_OID_LONGRETRIES, 0x13000003), + OID_U32_C(DOT11_OID_MAXTXLIFETIME, 0x13000004), + OID_U32(DOT11_OID_MAXRXLIFETIME, 0x13000005), + OID_U32(DOT11_OID_AUTHRESPTIMEOUT, 0x13000006), + OID_U32(DOT11_OID_ASSOCRESPTIMEOUT, 0x13000007), + + OID_UNKNOWN(DOT11_OID_ALOFT_TABLE, 0x1d000000), + OID_UNKNOWN(DOT11_OID_ALOFT_CTRL_TABLE, 0x1d000001), + OID_UNKNOWN(DOT11_OID_ALOFT_RETREAT, 0x1d000002), + OID_UNKNOWN(DOT11_OID_ALOFT_PROGRESS, 0x1d000003), + OID_U32(DOT11_OID_ALOFT_FIXEDRATE, 0x1d000004), + OID_UNKNOWN(DOT11_OID_ALOFT_RSSIGRAPH, 0x1d000005), + OID_UNKNOWN(DOT11_OID_ALOFT_CONFIG, 0x1d000006), + + [DOT11_OID_VDCFX] =3D {0x1b000000, 7, 0, 0}, + OID_U32(DOT11_OID_MAXFRAMEBURST, 0x1b000008), + + OID_U32(DOT11_OID_PSM, 0x14000000), + OID_U32(DOT11_OID_CAMTIMEOUT, 0x14000001), + OID_U32(DOT11_OID_RECEIVEDTIMS, 0x14000002), + OID_U32(DOT11_OID_ROAMPREFERENCE, 0x14000003), + + OID_U32(DOT11_OID_BRIDGELOCAL, 0x15000000), + OID_U32(DOT11_OID_CLIENTS, 0x15000001), + OID_U32(DOT11_OID_CLIENTSASSOCIATED, 0x15000002), + [DOT11_OID_CLIENTX] =3D {0x15000003, 2006, 0, 0}, /* DOT11_OID_CLIENTX,..= .DOT11_OID_CLIENT2007 */ + + OID_STRUCT(DOT11_OID_CLIENTFIND, 0x150007DB, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_WDSLINKADD, 0x150007DC, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_WDSLINKREMOVE, 0x150007DD, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_EAPAUTHSTA, 0x150007DE, u8[6], OID_TYPE_ADDR), + OID_STRUCT(DOT11_OID_EAPUNAUTHSTA, 0x150007DF, u8[6], OID_TYPE_ADDR), + OID_U32_C(DOT11_OID_DOT1XENABLE, 0x150007E0), + OID_UNKNOWN(DOT11_OID_MICFAILURE, 0x150007E1), + OID_UNKNOWN(DOT11_OID_REKEYINDICATE, 0x150007E2), + + OID_U32(DOT11_OID_MPDUTXSUCCESSFUL, 0x16000000), + OID_U32(DOT11_OID_MPDUTXONERETRY, 0x16000001), + OID_U32(DOT11_OID_MPDUTXMULTIPLERETRIES, 0x16000002), + OID_U32(DOT11_OID_MPDUTXFAILED, 0x16000003), + OID_U32(DOT11_OID_MPDURXSUCCESSFUL, 0x16000004), + OID_U32(DOT11_OID_MPDURXDUPS, 0x16000005), + OID_U32(DOT11_OID_RTSSUCCESSFUL, 0x16000006), + OID_U32(DOT11_OID_RTSFAILED, 0x16000007), + OID_U32(DOT11_OID_ACKFAILED, 0x16000008), + OID_U32(DOT11_OID_FRAMERECEIVES, 0x16000009), + OID_U32(DOT11_OID_FRAMEERRORS, 0x1600000A), + OID_U32(DOT11_OID_FRAMEABORTS, 0x1600000B), + OID_U32(DOT11_OID_FRAMEABORTSPHY, 0x1600000C), + + OID_U32(DOT11_OID_SLOTTIME, 0x17000000), + OID_U32(DOT11_OID_CWMIN, 0x17000001), + OID_U32(DOT11_OID_CWMAX, 0x17000002), + OID_U32(DOT11_OID_ACKWINDOW, 0x17000003), + OID_U32(DOT11_OID_ANTENNARX, 0x17000004), + OID_U32(DOT11_OID_ANTENNATX, 0x17000005), + OID_U32(DOT11_OID_ANTENNADIVERSITY, 0x17000006), + OID_U32_C(DOT11_OID_CHANNEL, 0x17000007), + OID_U32_C(DOT11_OID_EDTHRESHOLD, 0x17000008), + OID_U32(DOT11_OID_PREAMBLESETTINGS, 0x17000009), + OID_STRUCT(DOT11_OID_RATES, 0x1700000A, u8[IWMAX_BITRATES + 1], + OID_TYPE_RAW), + OID_U32(DOT11_OID_CCAMODESUPPORTED, 0x1700000B), + OID_U32(DOT11_OID_CCAMODE, 0x1700000C), + OID_UNKNOWN(DOT11_OID_RSSIVECTOR, 0x1700000D), + OID_UNKNOWN(DOT11_OID_OUTPUTPOWERTABLE, 0x1700000E), + OID_U32(DOT11_OID_OUTPUTPOWER, 0x1700000F), + OID_STRUCT(DOT11_OID_SUPPORTEDRATES, 0x17000010, + u8[IWMAX_BITRATES + 1], OID_TYPE_RAW), + OID_U32_C(DOT11_OID_FREQUENCY, 0x17000011), + [DOT11_OID_SUPPORTEDFREQUENCIES] =3D + {0x17000012, 0, sizeof (struct obj_frequencies) + + sizeof (u16) * IWMAX_FREQ, OID_TYPE_FREQUENCIES}, + + OID_U32(DOT11_OID_NOISEFLOOR, 0x17000013), + OID_STRUCT(DOT11_OID_FREQUENCYACTIVITY, 0x17000014, u8[IWMAX_FREQ + 1], + OID_TYPE_RAW), + OID_UNKNOWN(DOT11_OID_IQCALIBRATIONTABLE, 0x17000015), + OID_U32(DOT11_OID_NONERPPROTECTION, 0x17000016), + OID_U32(DOT11_OID_SLOTSETTINGS, 0x17000017), + OID_U32(DOT11_OID_NONERPTIMEOUT, 0x17000018), + OID_U32(DOT11_OID_PROFILES, 0x17000019), + OID_STRUCT(DOT11_OID_EXTENDEDRATES, 0x17000020, + u8[IWMAX_BITRATES + 1], OID_TYPE_RAW), + + OID_STRUCT_MLME(DOT11_OID_DEAUTHENTICATE, 0x18000000), + OID_STRUCT_MLME(DOT11_OID_AUTHENTICATE, 0x18000001), + OID_STRUCT_MLME(DOT11_OID_DISASSOCIATE, 0x18000002), + OID_STRUCT_MLME(DOT11_OID_ASSOCIATE, 0x18000003), + OID_UNKNOWN(DOT11_OID_SCAN, 0x18000004), + OID_STRUCT_MLMEEX(DOT11_OID_BEACON, 0x18000005), + OID_STRUCT_MLMEEX(DOT11_OID_PROBE, 0x18000006), + OID_STRUCT_MLMEEX(DOT11_OID_DEAUTHENTICATEEX, 0x18000007), + OID_STRUCT_MLMEEX(DOT11_OID_AUTHENTICATEEX, 0x18000008), + OID_STRUCT_MLMEEX(DOT11_OID_DISASSOCIATEEX, 0x18000009), + OID_STRUCT_MLMEEX(DOT11_OID_ASSOCIATEEX, 0x1800000A), + OID_STRUCT_MLMEEX(DOT11_OID_REASSOCIATE, 0x1800000B), + OID_STRUCT_MLMEEX(DOT11_OID_REASSOCIATEEX, 0x1800000C), + + OID_U32(DOT11_OID_NONERPSTATUS, 0x1E000000), + + OID_U32(DOT11_OID_STATIMEOUT, 0x19000000), + OID_U32_C(DOT11_OID_MLMEAUTOLEVEL, 0x19000001), + OID_U32(DOT11_OID_BSSTIMEOUT, 0x19000002), + OID_UNKNOWN(DOT11_OID_ATTACHMENT, 0x19000003), + OID_STRUCT_C(DOT11_OID_PSMBUFFER, 0x19000004, struct obj_buffer, + OID_TYPE_BUFFER), + + OID_U32(DOT11_OID_BSSS, 0x1C000000), + [DOT11_OID_BSSX] =3D {0x1C000001, 63, sizeof (struct obj_bss), + OID_TYPE_BSS}, /*DOT11_OID_BSS1,...,DOT11_OID_BSS64 */ + OID_STRUCT(DOT11_OID_BSSFIND, 0x1C000042, struct obj_bss, OID_TYPE_BSS), + [DOT11_OID_BSSLIST] =3D {0x1C000043, 0, sizeof (struct + obj_bsslist) + + sizeof (struct obj_bss[IWMAX_BSS]), + OID_TYPE_BSSLIST}, + + OID_UNKNOWN(OID_INL_TUNNEL, 0xFF020000), + OID_UNKNOWN(OID_INL_MEMADDR, 0xFF020001), + OID_UNKNOWN(OID_INL_MEMORY, 0xFF020002), + OID_U32_C(OID_INL_MODE, 0xFF020003), + OID_UNKNOWN(OID_INL_COMPONENT_NR, 0xFF020004), + OID_UNKNOWN(OID_INL_VERSION, 0xFF020005), + OID_UNKNOWN(OID_INL_INTERFACE_ID, 0xFF020006), + OID_UNKNOWN(OID_INL_COMPONENT_ID, 0xFF020007), + OID_U32_C(OID_INL_CONFIG, 0xFF020008), + OID_U32_C(OID_INL_DOT11D_CONFORMANCE, 0xFF02000C), + OID_U32(OID_INL_PHYCAPABILITIES, 0xFF02000D), + OID_U32_C(OID_INL_OUTPUTPOWER, 0xFF02000F), + +}; + +int +mgt_init(islpci_private *priv) +{ + int i; + + priv->mib =3D kmalloc(OID_NUM_LAST * sizeof (void *), GFP_KERNEL); + if (!priv->mib) + return -ENOMEM; + + memset(priv->mib, 0, OID_NUM_LAST * sizeof (void *)); + + /* Alloc the cache */ + for (i =3D 0; i < OID_NUM_LAST; i++) { + if (isl_oid[i].flags & OID_FLAG_CACHED) { + priv->mib[i] =3D kmalloc(isl_oid[i].size * + (isl_oid[i].range + 1), + GFP_KERNEL); + if (!priv->mib[i]) + return -ENOMEM; + memset(priv->mib[i], 0, + isl_oid[i].size * (isl_oid[i].range + 1)); + } else + priv->mib[i] =3D NULL; + } + + init_rwsem(&priv->mib_sem); + prism54_mib_init(priv); + + return 0; +} + +void +mgt_clean(islpci_private *priv) +{ + int i; + + if (!priv->mib) + return; + for (i =3D 0; i < OID_NUM_LAST; i++) + if (priv->mib[i]) { + kfree(priv->mib[i]); + priv->mib[i] =3D NULL; + } + kfree(priv->mib); + priv->mib =3D NULL; +} + +void +mgt_le_to_cpu(int type, void *data) +{ + switch (type) { + case OID_TYPE_U32: + *(u32 *) data =3D le32_to_cpu(*(u32 *) data); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D data; + buff->size =3D le32_to_cpu(buff->size); + buff->addr =3D le32_to_cpu(buff->addr); + break; + } + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D data; + bss->age =3D le16_to_cpu(bss->age); + bss->channel =3D le16_to_cpu(bss->channel); + bss->capinfo =3D le16_to_cpu(bss->capinfo); + bss->rates =3D le16_to_cpu(bss->rates); + bss->basic_rates =3D le16_to_cpu(bss->basic_rates); + break; + } + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D data; + int i; + list->nr =3D le32_to_cpu(list->nr); + for (i =3D 0; i < list->nr; i++) + mgt_le_to_cpu(OID_TYPE_BSS, &list->bsslist[i]); + break; + } + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D data; + int i; + freq->nr =3D le16_to_cpu(freq->nr); + for (i =3D 0; i < freq->nr; i++) + freq->mhz[i] =3D le16_to_cpu(freq->mhz[i]); + break; + } + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D data; + mlme->id =3D le16_to_cpu(mlme->id); + mlme->state =3D le16_to_cpu(mlme->state); + mlme->code =3D le16_to_cpu(mlme->code); + break; + } + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D data; + mlme->id =3D le16_to_cpu(mlme->id); + mlme->state =3D le16_to_cpu(mlme->state); + mlme->code =3D le16_to_cpu(mlme->code); + mlme->size =3D le16_to_cpu(mlme->size); + break; + } + case OID_TYPE_SSID: + case OID_TYPE_KEY: + case OID_TYPE_ADDR: + case OID_TYPE_RAW: + break; + default: + BUG(); + } +} + +static void +mgt_cpu_to_le(int type, void *data) +{ + switch (type) { + case OID_TYPE_U32: + *(u32 *) data =3D cpu_to_le32(*(u32 *) data); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D data; + buff->size =3D cpu_to_le32(buff->size); + buff->addr =3D cpu_to_le32(buff->addr); + break; + } + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D data; + bss->age =3D cpu_to_le16(bss->age); + bss->channel =3D cpu_to_le16(bss->channel); + bss->capinfo =3D cpu_to_le16(bss->capinfo); + bss->rates =3D cpu_to_le16(bss->rates); + bss->basic_rates =3D cpu_to_le16(bss->basic_rates); + break; + } + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D data; + int i; + list->nr =3D cpu_to_le32(list->nr); + for (i =3D 0; i < list->nr; i++) + mgt_cpu_to_le(OID_TYPE_BSS, &list->bsslist[i]); + break; + } + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D data; + int i; + freq->nr =3D cpu_to_le16(freq->nr); + for (i =3D 0; i < freq->nr; i++) + freq->mhz[i] =3D cpu_to_le16(freq->mhz[i]); + break; + } + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D data; + mlme->id =3D cpu_to_le16(mlme->id); + mlme->state =3D cpu_to_le16(mlme->state); + mlme->code =3D cpu_to_le16(mlme->code); + break; + } + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D data; + mlme->id =3D cpu_to_le16(mlme->id); + mlme->state =3D cpu_to_le16(mlme->state); + mlme->code =3D cpu_to_le16(mlme->code); + mlme->size =3D cpu_to_le16(mlme->size); + break; + } + case OID_TYPE_SSID: + case OID_TYPE_KEY: + case OID_TYPE_ADDR: + case OID_TYPE_RAW: + break; + default: + BUG(); + } +} + +/* Note : data is modified during this function */ + +int +mgt_set_request(islpci_private *priv, enum oid_num_t n, int extra, void *d= ata) +{ + int ret =3D 0; + struct islpci_mgmtframe *response =3D NULL; + int response_op =3D PIMFOR_OP_ERROR; + int dlen; + void *cache, *_data =3D data; + u32 oid; + + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(extra > isl_oid[n].range); + + if (!priv->mib) + /* memory has been freed */ + return -1; + + dlen =3D isl_oid[n].size; + cache =3D priv->mib[n]; + cache +=3D (cache ? extra * dlen : 0); + oid =3D isl_oid[n].oid + extra; + + if (_data =3D=3D NULL) + /* we are requested to re-set a cached value */ + _data =3D cache; + else + mgt_cpu_to_le(isl_oid[n].flags & OID_FLAG_TYPE, _data); + /* If we are going to write to the cache, we don't want anyone to read + * it -> acquire write lock. + * Else we could acquire a read lock to be sure we don't bother the + * commit process (which takes a write lock). But I'm not sure if it's + * needed. + */ + if (cache) + down_write(&priv->mib_sem); + + if (islpci_get_state(priv) >=3D PRV_STATE_READY) { + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, oid, + _data, dlen, &response); + if (!ret) { + response_op =3D response->header->operation; + islpci_mgt_release(response); + } + if (ret || response_op =3D=3D PIMFOR_OP_ERROR) + ret =3D -EIO; + } else if (!cache) + ret =3D -EIO; + + if (cache) { + if (!ret && data) + memcpy(cache, _data, dlen); + up_write(&priv->mib_sem); + } + + /* re-set given data to what it was */ + if (data) + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, data); + + return ret; +} + +int +mgt_get_request(islpci_private *priv, enum oid_num_t n, int extra, void *d= ata, + union oid_res_t *res) +{ + + int ret =3D -EIO; + int reslen =3D 0; + struct islpci_mgmtframe *response =3D NULL; + + int dlen; + void *cache, *_res =3D NULL; + u32 oid; + + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(extra > isl_oid[n].range); + + if (!priv->mib) + /* memory has been freed */ + return -1; + + dlen =3D isl_oid[n].size; + cache =3D priv->mib[n]; + cache +=3D cache ? extra * dlen : 0; + oid =3D isl_oid[n].oid + extra; + reslen =3D dlen; + + if (cache) + down_read(&priv->mib_sem); + + if (islpci_get_state(priv) >=3D PRV_STATE_READY) { + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + oid, data, dlen, &response); + if (ret || !response || + response->header->operation =3D=3D PIMFOR_OP_ERROR) { + if (response) + islpci_mgt_release(response); + ret =3D -EIO; + } + if (!ret) { + _res =3D response->data; + reslen =3D response->header->length; + } + } else if (cache) { + _res =3D cache; + ret =3D 0; + } + if ((isl_oid[n].flags & OID_FLAG_TYPE) =3D=3D OID_TYPE_U32) + res->u =3D ret ? 0 : le32_to_cpu(*(u32 *) _res); + else { + res->ptr =3D kmalloc(reslen, GFP_KERNEL); + BUG_ON(res->ptr =3D=3D NULL); + if (ret) + memset(res->ptr, 0, reslen); + else { + memcpy(res->ptr, _res, reslen); + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, + res->ptr); + } + } + if (cache) + up_read(&priv->mib_sem); + + if (response && !ret) + islpci_mgt_release(response); + + if (reslen > isl_oid[n].size) + printk(KERN_DEBUG + "mgt_get_request(0x%x): received data length was bigger " + "than expected (%d > %d). Memory is probably corrupted...", + oid, reslen, isl_oid[n].size); + + return ret; +} + +/* lock outside */ +int +mgt_commit_list(islpci_private *priv, enum oid_num_t *l, int n) +{ + int i, ret =3D 0; + struct islpci_mgmtframe *response; + + for (i =3D 0; i < n; i++) { + struct oid_t *t =3D &(isl_oid[l[i]]); + void *data =3D priv->mib[l[i]]; + int j =3D 0; + u32 oid =3D t->oid; + BUG_ON(data =3D=3D NULL); + while (j <=3D t->range) { + response =3D NULL; + ret |=3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, + oid, data, t->size, + &response); + if (response) { + ret |=3D (response->header->operation =3D=3D + PIMFOR_OP_ERROR); + islpci_mgt_release(response); + } + j++; + oid++; + data +=3D t->size; + } + } + return ret; +} + +/* Lock outside */ + +void +mgt_set(islpci_private *priv, enum oid_num_t n, void *data) +{ + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(priv->mib[n] =3D=3D NULL); + + memcpy(priv->mib[n], data, isl_oid[n].size); + mgt_cpu_to_le(isl_oid[n].flags & OID_FLAG_TYPE, priv->mib[n]); +} + +void +mgt_get(islpci_private *priv, enum oid_num_t n, void *res) +{ + BUG_ON(OID_NUM_LAST <=3D n); + BUG_ON(priv->mib[n] =3D=3D NULL); + BUG_ON(res =3D=3D NULL); + + memcpy(res, priv->mib[n], isl_oid[n].size); + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, res); +} + +/* Commits the cache. Lock outside. */ + +static enum oid_num_t commit_part1[] =3D { + OID_INL_CONFIG, + OID_INL_MODE, + DOT11_OID_BSSTYPE, + DOT11_OID_CHANNEL, + DOT11_OID_MLMEAUTOLEVEL +}; + +static enum oid_num_t commit_part2[] =3D { + DOT11_OID_SSID, + DOT11_OID_PSMBUFFER, + DOT11_OID_AUTHENABLE, + DOT11_OID_PRIVACYINVOKED, + DOT11_OID_EXUNENCRYPTED, + DOT11_OID_DEFKEYX, /* MULTIPLE */ + DOT11_OID_DEFKEYID, + DOT11_OID_DOT1XENABLE, + OID_INL_DOT11D_CONFORMANCE, + OID_INL_OUTPUTPOWER, +}; + +/* update the MAC addr. */ +static int +mgt_update_addr(islpci_private *priv) +{ + struct islpci_mgmtframe *res =3D NULL; + int ret; + + ret =3D islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, + isl_oid[GEN_OID_MACADDRESS].oid, NULL, + isl_oid[GEN_OID_MACADDRESS].size, &res); + + if ((ret =3D=3D 0) && res && (res->header->operation !=3D PIMFOR_OP_ERROR= )) + memcpy(priv->ndev->dev_addr, res->data, 6); + else + ret =3D -EIO; + if (res) + islpci_mgt_release(res); + + return ret; +} + +void +mgt_commit(islpci_private *priv) +{ + int rvalue; + u32 u; + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return; + + rvalue =3D mgt_commit_list(priv, commit_part1, + sizeof (commit_part1) / + sizeof (commit_part1[0])); + + if (priv->iw_mode !=3D IW_MODE_MONITOR) + rvalue |=3D mgt_commit_list(priv, commit_part2, + sizeof (commit_part2) / + sizeof (commit_part2[0])); + + u =3D OID_INL_MODE; + rvalue |=3D mgt_commit_list(priv, &u, 1); + rvalue |=3D mgt_update_addr(priv); + + if (rvalue) { + /* some request have failed. The device might be in an + incoherent state. We should reset it ! */ + printk(KERN_DEBUG "%s: mgt_commit has failed. Restart the " + "device \n", priv->ndev->name); + } +} + +/* This will tell you if you are allowed to answer a mlme(ex) request .*/ + +int +mgt_mlme_answer(islpci_private *priv) +{ + u32 mlmeautolevel; + /* Acquire a read lock because if we are in a mode change, it's + * possible to answer true, while the card is leaving master to managed + * mode. Answering to a mlme in this situation could hang the card. + */ + down_read(&priv->mib_sem); + mlmeautolevel =3D + le32_to_cpu(*(u32 *) priv->mib[DOT11_OID_MLMEAUTOLEVEL]); + up_read(&priv->mib_sem); + + return ((priv->iw_mode =3D=3D IW_MODE_MASTER) && + (mlmeautolevel >=3D DOT11_MLME_INTERMEDIATE)); +} + +enum oid_num_t +mgt_oidtonum(u32 oid) +{ + int i; + + for (i =3D 0; i < OID_NUM_LAST; i++) + if (isl_oid[i].oid =3D=3D oid) + return i; + + printk(KERN_DEBUG "looking for an unknown oid 0x%x", oid); + + return OID_NUM_LAST; +} + +int +mgt_response_to_str(enum oid_num_t n, union oid_res_t *r, char *str) +{ + switch (isl_oid[n].flags & OID_FLAG_TYPE) { + case OID_TYPE_U32: + return snprintf(str, PRIV_STR_SIZE, "%u\n", r->u); + break; + case OID_TYPE_BUFFER:{ + struct obj_buffer *buff =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "size=3D%u\naddr=3D0x%X\n", buff->size, + buff->addr); + } + break; + case OID_TYPE_BSS:{ + struct obj_bss *bss =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "age=3D%u\nchannel=3D%u\n" + "capinfo=3D0x%X\nrates=3D0x%X\n" + "basic_rates=3D0x%X\n", bss->age, + bss->channel, bss->capinfo, + bss->rates, bss->basic_rates); + } + break; + case OID_TYPE_BSSLIST:{ + struct obj_bsslist *list =3D r->ptr; + int i, k; + k =3D snprintf(str, PRIV_STR_SIZE, "nr=3D%u\n", list->nr); + for (i =3D 0; i < list->nr; i++) + k +=3D snprintf(str + k, PRIV_STR_SIZE - k, + "bss[%u] : \nage=3D%u\nchannel=3D%u\n" + "capinfo=3D0x%X\nrates=3D0x%X\n" + "basic_rates=3D0x%X\n", + i, list->bsslist[i].age, + list->bsslist[i].channel, + list->bsslist[i].capinfo, + list->bsslist[i].rates, + list->bsslist[i].basic_rates); + return k; + } + break; + case OID_TYPE_FREQUENCIES:{ + struct obj_frequencies *freq =3D r->ptr; + int i, t; + printk("nr : %u\n", freq->nr); + t =3D snprintf(str, PRIV_STR_SIZE, "nr=3D%u\n", freq->nr); + for (i =3D 0; i < freq->nr; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "mhz[%u]=3D%u\n", i, freq->mhz[i]); + return t; + } + break; + case OID_TYPE_MLME:{ + struct obj_mlme *mlme =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "id=3D0x%X\nstate=3D0x%X\ncode=3D0x%X\n", + mlme->id, mlme->state, mlme->code); + } + break; + case OID_TYPE_MLMEEX:{ + struct obj_mlmeex *mlme =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "id=3D0x%X\nstate=3D0x%X\n" + "code=3D0x%X\nsize=3D0x%X\n", mlme->id, + mlme->state, mlme->code, mlme->size); + } + break; + case OID_TYPE_SSID:{ + struct obj_ssid *ssid =3D r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "length=3D%u\noctets=3D%.*s\n", + ssid->length, ssid->length, + ssid->octets); + } + break; + case OID_TYPE_KEY:{ + struct obj_key *key =3D r->ptr; + int t, i; + t =3D snprintf(str, PRIV_STR_SIZE, + "type=3D0x%X\nlength=3D0x%X\nkey=3D0x", + key->type, key->length); + for (i =3D 0; i < key->length; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "%02X:", key->key[i]); + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, "\n"); + return t; + } + break; + case OID_TYPE_RAW: + case OID_TYPE_ADDR:{ + unsigned char *buff =3D r->ptr; + int t, i; + t =3D snprintf(str, PRIV_STR_SIZE, "hex data=3D"); + for (i =3D 0; i < isl_oid[n].size; i++) + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, + "%02X:", buff[i]); + t +=3D snprintf(str + t, PRIV_STR_SIZE - t, "\n"); + return t; + } + break; + default: + BUG(); + } + return 0; +} diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/oid_mgt.h linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.h --- linux-2.4.26/drivers/net/wireless/prism54/oid_mgt.h 1970-01-01 00:00:00= .000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/oid_mgt.h 2004-07-21 = 09:00:04.000000000 +0000 @@ -0,0 +1,58 @@ +/* + * Copyright (C) 2003 Aurelien Alleaume + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +#if !defined(_OID_MGT_H) +#define _OID_MGT_H + +#include "isl_oid.h" +#include "islpci_dev.h" + +extern struct oid_t isl_oid[]; + +int mgt_init(islpci_private *); + +void mgt_clean(islpci_private *); + +/* I don't know where to put these 3 */ +extern const int frequency_list_bg[]; +extern const int frequency_list_a[]; +int channel_of_freq(int); + +void mgt_le_to_cpu(int, void *); + +int mgt_set_request(islpci_private *, enum oid_num_t, int, void *); + +int mgt_get_request(islpci_private *, enum oid_num_t, int, void *, + union oid_res_t *); + +int mgt_commit_list(islpci_private *, enum oid_num_t *, int); + +void mgt_set(islpci_private *, enum oid_num_t, void *); + +void mgt_get(islpci_private *, enum oid_num_t, void *); + +void mgt_commit(islpci_private *); + +int mgt_mlme_answer(islpci_private *); + +enum oid_num_t mgt_oidtonum(u32 oid); + +int mgt_response_to_str(enum oid_num_t, union oid_res_t *, char *); + +#endif /* !defined(_OID_MGT_H) */ +/* EOF */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/prismcompat.h linux-2.4.26-prism54/drivers/net/wireless/prism54/pris= mcompat.h --- linux-2.4.26/drivers/net/wireless/prism54/prismcompat.h 1970-01-01 00:0= 0:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/prismcompat.h 2004-07= -21 09:00:04.000000000 +0000 @@ -0,0 +1,46 @@ +/* =20 + * (C) 2004 Margit Schubert-While + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +/* =20 + * Compatibility header file to aid support of different kernel versions + */ + +#ifdef PRISM54_COMPAT24 +#include "prismcompat24.h" +#else /* PRISM54_COMPAT24 */ + +#ifndef _PRISM_COMPAT_H +#define _PRISM_COMPAT_H + +#include +#include +#include +#include +#include +#include + +#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) +#error Firmware Loading is not configured in the kernel ! +#endif + +#define prism54_synchronize_irq(irq) synchronize_irq(irq) + +#define PRISM_FW_PDEV &priv->pdev->dev + +#endif /* _PRISM_COMPAT_H */ +#endif /* PRISM54_COMPAT24 */ diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.4.26/drivers/net/wireless/p= rism54/prismcompat24.h linux-2.4.26-prism54/drivers/net/wireless/prism54/pr= ismcompat24.h --- linux-2.4.26/drivers/net/wireless/prism54/prismcompat24.h 1970-01-01 00= :00:00.000000000 +0000 +++ linux-2.4.26-prism54/drivers/net/wireless/prism54/prismcompat24.h 2004-= 07-21 09:00:04.000000000 +0000 @@ -0,0 +1,72 @@ +/* =20 + * (C) 2004 Margit Schubert-While + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + * + */ + +/* =20 + * Compatibility header file to aid support of different kernel versions + */ + +#ifndef _PRISM_COMPAT_H +#define _PRISM_COMPAT_H + +#include +#include +#include +#include +#include +#include +#include + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,25) +#define module_param(x, y, z) MODULE_PARM(x, "i") +#else +#include +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,23) +#define free_netdev(x) kfree(x) +#define pci_name(x) x->slot_name +#define irqreturn_t void +#define IRQ_HANDLED +#define IRQ_NONE +#else +#include +#endif + +#define work_struct tq_struct +#define INIT_WORK INIT_TQUEUE +#define schedule_work schedule_task + +#if !defined(HAVE_NETDEV_PRIV) +#define netdev_priv(x) x->priv +#endif + +#if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) +#error Firmware Loading is not configured in the kernel ! +#endif + +#define prism54_synchronize_irq(irq) synchronize_irq() + +#define DEFINE_WAIT(y) DECLARE_WAITQUEUE(y, current) +#define prepare_to_wait(x, y, z) set_current_state(z); \ + add_wait_queue(x, y) +#define finish_wait(x, y) remove_wait_queue(x, y); \ + set_current_state(TASK_RUNNING) + +#define PRISM_FW_PDEV pci_name(priv->pdev) + +#endif /* _PRISM_COMPAT_H */ --fUYQa+Pmc3FrFX/N-- --V0207lvV8h4k8FAm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/jiOat1JN+IKUl4RAp3xAJ0Q2m1hJlgNwIblex3byV1zchQbgQCeLuzz 8ILBB5dEwOdBo3cyx/7jnZQ= =kDNL -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- From master@tentacle.sectorb.msk.ru Wed Jul 21 04:48:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 04:48:19 -0700 (PDT) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LBlvVP021977 for ; Wed, 21 Jul 2004 04:47:59 -0700 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 3AE6B2FD6; Wed, 21 Jul 2004 15:47:51 +0400 (MSD) Date: Wed, 21 Jul 2004 15:47:51 +0400 From: "Vladimir B. Savkin" To: Francois Romieu , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: r8169 in 2.6.7: transfer stops after few seconds Message-ID: <20040721114750.GA7668@tentacle.sectorb.msk.ru> References: <20040721083406.GA5785@usr.lcm.msu.ru> <20040721125622.A31273@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20040721125622.A31273@electric-eye.fr.zoreil.com> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.26 User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 7058 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev Content-Length: 13115 Lines: 303 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Wed, Jul 21, 2004 at 12:56:22PM +0200, Francois Romieu wrote: > Vladimir B. Savkin : > > My realtek-8169 based NIC doesn't work with 2.6. > > Kernel versions tried: 2.6.7, 2.6.7-mm7. > > Works OK with 2.4.26. > [...] > > Is there any other info I can supply you with to debug this problem? > > - dmesg once the card is up/stopped (please provide complete dmesg from > boot as it usually gets truncated and misses the compiler info) Attached as dmesg.boot. No additional messages after card is stopped. (I use vlans, but can reproduce the problem without them). > - ifconfig output once the card is stopped Attached as ifconfig.eth1 Look, seems like the card stops after 64 packets transmitted - I checked this several times! > - lspci -vx Attached as lspci-vx. > > Did you try 2.6.6 or previous kernel in the 2.6.x serie ? Just checked - 2.6.6 couldn't boot on this machine - hda: lost interrupt > > Please redirect traffic to netdev@oss.sgi.com. > > -- > Ueimor > ~ :wq With best regards, Vladimir Savkin. --0F1p//8PRICkK4MW Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="dmesg.boot" Linux version 2.6.7-mm7 (vsavkin@abyss) (gcc version 2.95.4 20011002 (Debian prerelease)) #2 Wed Jul 21 00:18:02 MSD 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000fff0000 (usable) BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data) BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 255MB LOWMEM available. On node 0 totalpages: 65520 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61424 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI disabled because your bios is from 2000 and too old You can enable it with acpi=force Built 1 zonelists Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! Initializing CPU#0 Kernel command line: BOOT_IMAGE=mm7 ro root=303 PID hash table entries: 1024 (order 10: 8192 bytes) Detected 909.470 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 256288k/262080k available (1480k kernel code, 5096k reserved, 624k data, 336k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1781.76 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0183fbff c1c7fbff 00000000 00000000 CPU: After vendor identify, caps: 0183fbff c1c7fbff 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0183fbff c1c7fbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 908.0736 MHz. ..... host bus clock speed is 201.0941 MHz. NET: Registered protocol family 16 spurious 8259A interrupt: IRQ7. PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router AMD756 [1022/740b] at 0000:00:07.3 TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca) Machine check exception polling timer started. IA-32 Microcode Update Driver: v1.14 Initializing Cryptographic API Real Time Clock Driver v1.12 Using anticipatory io scheduler Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx AMD7409: IDE controller at PCI slot 0000:00:07.1 AMD7409: chipset revision 7 AMD7409: not 100% native mode: will probe irqs later AMD7409: 0000:00:07.1 (rev 07) UDMA66 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio hda: SAMSUNG SP0802N, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: IDE/ATAPI CD-ROM 50XS, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 PDC20269: IDE controller at PCI slot 0000:00:0b.0 AMD756: dev 105a:4d69, router pirq : 4 get irq : 11 PCI: Found IRQ 11 for device 0000:00:0b.0 PDC20269: chipset revision 2 PDC20269: ROM enabled at 0xeffe0000 PDC20269: 100% native mode on irq 11 ide2: BM-DMA at 0xcc00-0xcc07, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xcc08-0xcc0f, BIOS settings: hdg:pio, hdh:pio hde: ST380021A, ATA DISK drive ide2 at 0xdc00-0xdc07,0xd802 on irq 11 hdg: Maxtor 7Y250P0, ATA DISK drive ide3 at 0xd400-0xd407,0xd002 on irq 11 hda: max request size: 1024KiB hda: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(33) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 > hde: max request size: 128KiB hde: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hde: cache flushes supported hde: hde1 hdg: max request size: 1024KiB hdg: 490234752 sectors (251000 MB) w/2048KiB Cache, CHS=30515/255/63, UDMA(133) hdg: cache flushes supported hdg: hdg1 hdc: ATAPI 11X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 ide-floppy driver 0.99.newide serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 input: PC Speaker NET: Registered protocol family 2 IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 336k freed Adding 1228964k swap on /dev/hda2. Priority:-1 extents:1 8139too Fast Ethernet driver 0.9.27 AMD756: dev 10ec:8139, router pirq : 1 get irq : 12 PCI: Found IRQ 12 for device 0000:00:08.0 eth0: RealTek RTL8139 at 0xd08a2e00, 00:02:44:00:5c:19, IRQ 12 eth0: Identified 8139 chip type 'RTL-8139C' r8169 Gigabit Ethernet driver 1.2 loaded AMD756: dev 10ec:8169, router pirq : 3 get irq : 10 PCI: Found IRQ 10 for device 0000:00:0a.0 r8169: NAPI enabled eth1: Identified chip type is 'RTL8169'. eth1: RTL8169 at 0xd08b0f00, 00:50:fc:b8:2a:c4, IRQ 10 ReiserFS: hda5: found reiserfs format "3.6" with standard journal ReiserFS: hda5: using ordered data mode ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda5: checking transaction log (hda5) ReiserFS: hda5: Using r5 hash to sort names ReiserFS: hda6: found reiserfs format "3.6" with standard journal ReiserFS: hda6: using ordered data mode ReiserFS: hda6: journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda6: checking transaction log (hda6) ReiserFS: hda6: Using r5 hash to sort names ReiserFS: hda7: found reiserfs format "3.6" with standard journal ReiserFS: hda7: using ordered data mode ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda7: checking transaction log (hda7) ReiserFS: hda7: Using r5 hash to sort names vlan0303: add 01:00:5e:00:00:01 mcast address to master interface r8169: eth1: link up --0F1p//8PRICkK4MW Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename=lspci-vx 0000:00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller (rev 25) Flags: bus master, medium devsel, latency 120 Memory at e8000000 (32-bit, prefetchable) [size=64M] Memory at efdff000 (32-bit, prefetchable) [size=4K] I/O ports at c000 [disabled] [size=4] Capabilities: [a0] AGP version 1.0 00: 22 10 06 70 06 01 10 22 25 00 00 06 00 78 80 00 10: 08 00 00 e8 08 f0 df ef 01 c0 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 0000:00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 120 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 00008000-00008fff Memory behind bridge: efe00000-efefffff Prefetchable memory behind bridge: e7c00000-e7cfffff 00: 22 10 07 70 07 01 20 02 01 00 04 06 00 78 81 00 10: 00 00 00 00 00 00 00 00 00 01 01 20 81 81 20 22 20: e0 ef e0 ef c0 e7 c0 e7 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 00 0000:00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ISA (rev 01) Flags: bus master, medium devsel, latency 0 00: 22 10 08 74 0f 00 00 02 01 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-756 [Viper] IDE (rev 07) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at f000 [size=16] 00: 22 10 09 74 05 00 00 02 07 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ACPI (rev 03) Flags: medium devsel 00: 22 10 0b 74 00 00 80 02 03 00 80 06 00 78 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 64, IRQ 12 I/O ports at c400 [size=256] Memory at efffbe00 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00: ec 10 39 81 07 01 90 02 10 00 00 02 00 40 00 00 10: 01 c4 00 00 00 be ff ef 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81 30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 01 20 40 0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10 I/O ports at c800 [size=256] Memory at efffbf00 (32-bit, non-prefetchable) [size=256] Expansion ROM at effd0000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [60] Vital Product Data 00: ec 10 69 81 17 01 b0 02 10 00 00 02 08 40 00 00 10: 01 c8 00 00 00 bf ff ef 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 fd ef dc 00 00 00 00 00 00 00 0a 01 20 40 0000:00:0b.0 Unknown mass storage controller: Promise Technology, Inc. 20269 (rev 02) (prog-if 85) Subsystem: Promise Technology, Inc. Ultra133TX2 Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 11 I/O ports at dc00 [size=8] I/O ports at d800 [size=4] I/O ports at d400 [size=8] I/O ports at d000 [size=4] I/O ports at cc00 [size=16] Memory at efffc000 (32-bit, non-prefetchable) [size=16K] Expansion ROM at effe0000 [disabled] [size=16K] Capabilities: [60] Power Management version 1 00: 5a 10 69 4d 07 00 30 04 02 85 80 01 08 40 00 00 10: 01 dc 00 00 01 d8 00 00 01 d4 00 00 01 d0 00 00 20: 01 cc 00 00 00 c0 ff ef 00 00 00 00 5a 10 68 4d 30: 01 00 fe ef 60 00 00 00 00 00 00 00 0b 01 04 12 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=koi8-r Content-Description: ifconfig.eth1 Content-Disposition: attachment; filename="ifconfig.eth1.2" eth1 Link encap:Ethernet HWaddr 00:50:FC:B8:2A:C4 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5423 errors:0 dropped:0 overruns:0 frame:0 TX packets:64 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:406122 (396.6 KiB) TX bytes:59792 (58.3 KiB) Interrupt:10 Base address:0xf00 --0F1p//8PRICkK4MW-- From romieu@fr.zoreil.com Wed Jul 21 11:11:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 11:11:40 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LIBUZd002229 for ; Wed, 21 Jul 2004 11:11:31 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i6LIAqh9003722; Wed, 21 Jul 2004 20:10:52 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i6LIApAG003721; Wed, 21 Jul 2004 20:10:51 +0200 Date: Wed, 21 Jul 2004 20:10:51 +0200 From: Francois Romieu To: "Vladimir B. Savkin" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: r8169 in 2.6.7: transfer stops after few seconds Message-ID: <20040721201051.A3513@electric-eye.fr.zoreil.com> Mail-Followup-To: Francois Romieu , "Vladimir B. Savkin" , linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20040721083406.GA5785@usr.lcm.msu.ru> <20040721125622.A31273@electric-eye.fr.zoreil.com> <20040721114750.GA7668@tentacle.sectorb.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040721114750.GA7668@tentacle.sectorb.msk.ru>; from master@sectorb.msk.ru on Wed, Jul 21, 2004 at 03:47:51PM +0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 7059 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 221 Lines: 8 Vladimir B. Savkin : [...] > Linux version 2.6.7-mm7 (vsavkin@abyss) (gcc version 2.95.4 20011002 (Debian prerelease)) #2 Wed Jul 21 00:18:02 MSD 2004 Can you try a non 2.95.x kernel ? -- Ueimor From romieu@fr.zoreil.com Wed Jul 21 11:55:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 11:55:40 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LItUsS003644 for ; Wed, 21 Jul 2004 11:55:31 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i6LIqNh9004383; Wed, 21 Jul 2004 20:52:23 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i6LIqNt2004382; Wed, 21 Jul 2004 20:52:23 +0200 Date: Wed, 21 Jul 2004 20:52:23 +0200 From: Francois Romieu To: "Vladimir B. Savkin" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: r8169 in 2.6.7: transfer stops after few seconds Message-ID: <20040721205223.B3513@electric-eye.fr.zoreil.com> Mail-Followup-To: Francois Romieu , "Vladimir B. Savkin" , linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20040721083406.GA5785@usr.lcm.msu.ru> <20040721125622.A31273@electric-eye.fr.zoreil.com> <20040721114750.GA7668@tentacle.sectorb.msk.ru> <20040721201051.A3513@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040721201051.A3513@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Wed, Jul 21, 2004 at 08:10:51PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 7060 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 139 Lines: 6 Francois Romieu : [...] > Can you try a non 2.95.x kernel ? ^^^^^^ -> compiler -- Ueimor From ebiederm@xmission.com Wed Jul 21 12:09:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 12:09:50 -0700 (PDT) Received: from ebiederm.dsl.xmission.com (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LJ9hKP004405 for ; Wed, 21 Jul 2004 12:09:44 -0700 Received: from ebiederm.dsl.xmission.com (localhost [127.0.0.1]) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6LJ9CEE005541; Wed, 21 Jul 2004 13:09:12 -0600 Received: (from eric@localhost) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-6.6) id i6LJ9BMe005538; Wed, 21 Jul 2004 13:09:11 -0600 X-Authentication-Warning: ebiederm.dsl.xmission.com: eric set sender to ebiederm@xmission.com using -f To: Mike Snitzer Cc: fastboot@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [BUG] e1000 on reboot/boot path. References: <20040719181115.86378.qmail@web52302.mail.yahoo.com> <170fa0d2040720180741cfa783@mail.gmail.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: 21 Jul 2004 13:09:11 -0600 In-Reply-To: <170fa0d2040720180741cfa783@mail.gmail.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7061 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Content-Length: 1416 Lines: 35 Mike Snitzer writes: So you have a problem that the e1000 driver does not properly shutdown the e1000 in the reboot path (no code). But it does properly cleanup when you remove the module. > I've been bitten by this issue > with the e1000 (<= 5.2.52-k4) driver. With an "Ethernet controller: > Intel Corp. 82546EB Gigabit Ethernet Controller", device id# 1010, I > get: > > Intel(R) PRO/1000 Network Driver - version 5.2.30.1-k1 > Copyright (c) 1999-2004 Intel Corporation. > PCI: Enabling device 04:05.0 (0000 -> 0003) > Uhhuh. NMI received for unknown reason 31. > Dazed and confused, but trying to continue > Do you have a strange power saving mode enabled? > The EEPROM Checksum Is Not Valid > PCI: Enabling device 04:05.1 (0000 -> 0003) > The EEPROM Checksum Is Not Valid > > The 5.2.52-k4 has toned down, yet basically the same, errors. This > message results when kexec'ing from a 2.6.7 kernel with the e1000 > builtin; once I made the e1000 a module and unloaded it prior to > kexec'ing all was fine. > > Looking at the e1000 source it is clear that removing the e1000 module > triggers e1000_remove() via module_exit()'s pci_unregister_driver(). > Once the e1000 let go of the PCI resources the kexec'd kernel's e1000 > driver was happy. Kexec looks to call all loaded modules' shutdown() > routine. The e1000 doesn't have shutdown(); but it does have a > remove(). > Eric From ebiederm@xmission.com Wed Jul 21 12:40:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 12:40:57 -0700 (PDT) Received: from ebiederm.dsl.xmission.com (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LJeoZm008161 for ; Wed, 21 Jul 2004 12:40:51 -0700 Received: from ebiederm.dsl.xmission.com (localhost [127.0.0.1]) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6LJeJEE005727; Wed, 21 Jul 2004 13:40:19 -0600 Received: (from eric@localhost) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-6.6) id i6LJeIu6005724; Wed, 21 Jul 2004 13:40:18 -0600 X-Authentication-Warning: ebiederm.dsl.xmission.com: eric set sender to ebiederm@xmission.com using -f To: Mike Snitzer Cc: fastboot@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [Fastboot] [ANNOUNCE] [PATCH] 2.6.8-rc1-kexec1 (ppc & x86) References: <20040719181115.86378.qmail@web52302.mail.yahoo.com> <170fa0d2040720180741cfa783@mail.gmail.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: 21 Jul 2004 13:40:18 -0600 In-Reply-To: <170fa0d2040720180741cfa783@mail.gmail.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7062 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Content-Length: 1940 Lines: 50 Mike Snitzer writes: > In preparation for kexec to be viable for 2.6 inclusion it would > appear that some effort will need to go in to making sure all drivers > in the kernel actually let go of their resources. Should there be an > audit to verify all device drivers have a shutdown()? Right this is a janitorial type task that needs to done. - First there are a lot of devices that don't need a shutdown method. Mostly either because they are not stateful or their initialization method can bring them out of whatever state they are in. Although if the kexec stuff gets in this might just happen with a pile of bug reports like yours. > Another option is to call each module's remove() iff the module > doesn't have shutdown(). This would require changing > drivers/base/power/shutdown.c device_shutdown() to include ... else if > (dev->driver && dev->driver->remove) ... As a side-effect it would > make drivers like the e1000 safe for use with kexec. Last time I had this conversation it was not wanted to merge shutdown() and remove() because shutdown is just required to touch the hardware and not to clean up the kernel data structures. Which if you machine is in an unstable state already could be an advantage. But calling shutdown on device remove is perfectly legitimate. And it should help ensure the code path gets tested. Ah... Looking more closely there is a method for testing the shutdown method and the related power management states. Details are in documentation/power/devices.txt But in short there is a "detach_state" file for each file in sysfs. If you do "echo 4 > detach_state" it the shutdown method should be called on device removal. Other low power states can be handles the same way. I still think drivers will want to call their shutdown method from their remove method if there is any work to do. But at least there is now a way to test the code path. Eric From afleming@freescale.com Wed Jul 21 12:59:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 12:59:54 -0700 (PDT) Received: from motgate6.mot.com (motgate6.mot.com [144.189.100.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LJxlPS008648 for ; Wed, 21 Jul 2004 12:59:47 -0700 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i6LJpHXQ028118; Wed, 21 Jul 2004 12:51:17 -0700 (MST) Received: from [10.82.17.240] ([10.82.17.240]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i6LHpANH031294; Wed, 21 Jul 2004 12:51:11 -0500 In-Reply-To: <20040707032913.GA1822@havoc.gtf.org> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <1089170282.1038.80.camel@jzny.localdomain> <20040707032913.GA1822@havoc.gtf.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/mixed; boundary=Apple-Mail-2-463122003 Message-Id: <51120A19-DB4F-11D8-A2B5-000393C30512@freescale.com> Cc: Andy Fleming , , Kumar Gala , jamal , From: Andy Fleming Subject: Re: [RFR] gianfar ethernet driver Date: Wed, 21 Jul 2004 14:51:11 -0500 To: Jeff Garzik X-Mailer: Apple Mail (2.618) X-archive-position: 7063 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 70620 Lines: 2404 --Apple-Mail-2-463122003 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Ok, here's the new patch to apply on top of the old patch. This is my first time using bk to generate a patch, so I beg forgiveness if something goes wrong. ... Ok, I had to find a bug in the patch, first, so this got delayed from yesterday. But now it works. The patch includes a one-line addition to mii.h, declaring BMCR_SPEED1000, which is undefined on 10/100 PHYs, but seems to be used on all gigabit PHYs to form a two-bit field with BMCR_SPEED100, indicating gigabit speeds when their values are 1 and 0, respectively. Andy --Apple-Mail-2-463122003 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="gfarpatch" Content-Disposition: attachment; filename=gfarpatch diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c --- a/drivers/net/gianfar.c Wed Jul 21 12:37:04 2004 +++ b/drivers/net/gianfar.c Wed Jul 21 12:37:04 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -101,11 +101,6 @@ #include #endif -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,41) -#define irqreturn_t void -#define IRQ_HANDLED -#endif - #define TX_TIMEOUT (1*HZ) #define SKB_ALLOC_TIMEOUT 1000000 #undef BRIEF_GFAR_ERRORS @@ -117,9 +112,8 @@ #define RECEIVE(x) netif_rx(x) #endif -#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.0, " -char gfar_driver_name[] = "Gianfar Ethernet"; -char gfar_driver_version[] = "1.0"; +const char gfar_driver_name[] = "Gianfar Ethernet"; +const char gfar_driver_version[] = "1.1"; int startup_gfar(struct net_device *dev); static int gfar_enet_open(struct net_device *dev); @@ -152,12 +146,9 @@ static int gfar_accept_fastpath(struct net_device *dev, struct dst_entry *dst); #endif static inline int try_fastroute(struct sk_buff *skb, struct net_device *dev, int length); -#ifdef CONFIG_GFAR_NAPI static int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit); -#else -static int gfar_clean_rx_ring(struct net_device *dev); -#endif static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb, int length); +static void gfar_phy_startup_timer(unsigned long data); extern struct ethtool_ops gfar_ethtool_ops; extern void gfar_gstrings_normon(struct net_device *dev, u32 stringset, @@ -183,7 +174,7 @@ struct ocp_gfar_data *einfo; int idx; int err = 0; - struct ethtool_ops *dev_ethtool_ops; + int dev_ethtool_ops = 0; einfo = (struct ocp_gfar_data *) ocpdev->def->additions; @@ -278,6 +269,7 @@ dev->base_addr = (unsigned long) (priv->regs); SET_MODULE_OWNER(dev); + SET_NETDEV_DEV(dev, &ocpdev->dev); /* Fill in the dev structure */ dev->open = gfar_enet_open; @@ -293,33 +285,16 @@ dev->change_mtu = gfar_change_mtu; dev->mtu = 1500; dev->set_multicast_list = gfar_set_multi; - dev->flags |= IFF_MULTICAST; - dev_ethtool_ops = - (struct ethtool_ops *)kmalloc(sizeof(struct ethtool_ops), - GFP_KERNEL); + /* Index into the array of possible ethtool + * ops to catch all 4 possibilities */ + if((priv->einfo->flags & GFAR_HAS_RMON) == 0) + dev_ethtool_ops += 1; - if(dev_ethtool_ops == NULL) { - err = -ENOMEM; - goto ethtool_fail; - } - - memcpy(dev_ethtool_ops, &gfar_ethtool_ops, sizeof(gfar_ethtool_ops)); + if((priv->einfo->flags & GFAR_HAS_COALESCE) == 0) + dev_ethtool_ops += 2; - /* If there is no RMON support in this device, we don't - * want to expose non-existant statistics */ - if((priv->einfo->flags & GFAR_HAS_RMON) == 0) { - dev_ethtool_ops->get_strings = gfar_gstrings_normon; - dev_ethtool_ops->get_stats_count = gfar_stats_count_normon; - dev_ethtool_ops->get_ethtool_stats = gfar_fill_stats_normon; - } - - if((priv->einfo->flags & GFAR_HAS_COALESCE) == 0) { - dev_ethtool_ops->set_coalesce = NULL; - dev_ethtool_ops->get_coalesce = NULL; - } - - dev->ethtool_ops = dev_ethtool_ops; + dev->ethtool_ops = gfar_op_array[dev_ethtool_ops]; #ifdef CONFIG_NET_FASTROUTE dev->accept_fastpath = gfar_accept_fastpath; @@ -332,13 +307,12 @@ priv->tx_ring_size = DEFAULT_TX_RING_SIZE; priv->rx_ring_size = DEFAULT_RX_RING_SIZE; - /* Initially, coalescing is disabled */ - priv->txcoalescing = 0; - priv->txcount = 0; - priv->txtime = 0; - priv->rxcoalescing = 0; - priv->rxcount = 0; - priv->rxtime = 0; + priv->txcoalescing = DEFAULT_TX_COALESCE; + priv->txcount = DEFAULT_TXCOUNT; + priv->txtime = DEFAULT_TXTIME; + priv->rxcoalescing = DEFAULT_RX_COALESCE; + priv->rxcount = DEFAULT_RXCOUNT; + priv->rxtime = DEFAULT_RXTIME; err = register_netdev(dev); @@ -369,8 +343,6 @@ register_fail: - kfree(dev_ethtool_ops); -ethtool_fail: iounmap((void *) priv->phyregs); phy_regs_fail: iounmap((void *) priv->regs); @@ -399,26 +371,89 @@ { struct gfar_private *priv = netdev_priv(dev); struct phy_info *curphy; + unsigned int timeout = PHY_INIT_TIMEOUT; + struct gfar *phyregs = priv->phyregs; + struct gfar_mii_info *mii_info; + int err; - priv->link = 1; priv->oldlink = 0; priv->oldspeed = 0; - priv->olddplx = -1; + priv->oldduplex = -1; + + mii_info = kmalloc(sizeof(struct gfar_mii_info), + GFP_KERNEL); + + if(NULL == mii_info) { + printk(KERN_ERR "%s: Could not allocate mii_info\n", + dev->name); + return -ENOMEM; + } + + mii_info->speed = SPEED_1000; + mii_info->duplex = DUPLEX_FULL; + mii_info->pause = 0; + mii_info->link = 1; + + mii_info->advertising = (ADVERTISED_10baseT_Half | + ADVERTISED_10baseT_Full | + ADVERTISED_100baseT_Half | + ADVERTISED_100baseT_Full | + ADVERTISED_1000baseT_Full); + mii_info->autoneg = 1; + + mii_info->mii_id = priv->einfo->phyid; + + mii_info->dev = dev; + + mii_info->mdio_read = &read_phy_reg; + mii_info->mdio_write = &write_phy_reg; + + priv->mii_info = mii_info; + + /* Reset the management interface */ + gfar_write(&phyregs->miimcfg, MIIMCFG_RESET); + + /* Setup the MII Mgmt clock speed */ + gfar_write(&phyregs->miimcfg, MIIMCFG_INIT_VALUE); + + /* Wait until the bus is free */ + while ((gfar_read(&phyregs->miimind) & MIIMIND_BUSY) && + timeout--) + cpu_relax(); + + if(timeout <= 0) { + printk(KERN_ERR "%s: The MII Bus is stuck!\n", + dev->name); + err = -1; + goto bus_fail; + } /* get info for this PHY */ - curphy = get_phy_info(dev); + curphy = get_phy_info(priv->mii_info); if (curphy == NULL) { printk(KERN_ERR "%s: No PHY found\n", dev->name); - return -1; + err = -1; + goto no_phy; } - priv->phyinfo = curphy; + mii_info->phyinfo = curphy; + + /* Run the commands which initialize the PHY */ + if(curphy->init) + err = curphy->init(priv->mii_info); - /* Run the commands which configure the PHY */ - phy_run_commands(dev, curphy->config); + if (err) + goto phy_init_fail; return 0; + +phy_init_fail: +no_phy: +bus_fail: + kfree(mii_info); + + return err; } static void init_registers(struct net_device *dev) @@ -483,6 +518,20 @@ gfar_write(&priv->regs->tbipa, TBIPA_VALUE); } +void mii_clear_phy_interrupt(struct gfar_mii_info *mii_info) +{ + if(mii_info->phyinfo->ack_interrupt) + mii_info->phyinfo->ack_interrupt(mii_info); +} + + +void mii_configure_phy_interrupt(struct gfar_mii_info *mii_info, u32 interrupts) +{ + mii_info->interrupts = interrupts; + mii_info->phyinfo->config_intr(mii_info); +} + + void stop_gfar(struct net_device *dev) { struct gfar_private *priv = netdev_priv(dev); @@ -494,7 +543,7 @@ spin_lock_irqsave(&priv->lock, flags); /* Tell the kernel the link is down */ - priv->link = 0; + priv->mii_info->link = 0; adjust_link(dev); /* Mask all interrupts */ @@ -521,7 +570,12 @@ gfar_write(®s->maccfg1, tempval); if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { - phy_run_commands(dev, priv->phyinfo->shutdown); + /* Clear any pending interrupts */ + mii_clear_phy_interrupt(priv->mii_info); + + /* Disable PHY Interrupts */ + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_DISABLED); } spin_unlock_irqrestore(&priv->lock, flags); @@ -552,6 +606,7 @@ /* Free the buffer descriptors */ kfree(priv->tx_bd_base); + kfree(priv->mii_info); } /* If there are any tx skbs or rx skbs still around, free them. @@ -610,7 +665,8 @@ { struct txbd8 *txbdp; struct rxbd8 *rxbdp; - unsigned long addr; + dma_addr_t addr; + unsigned long vaddr; int i; struct gfar_private *priv = netdev_priv(dev); struct gfar *regs = priv->regs; @@ -620,32 +676,27 @@ gfar_write(®s->imask, IMASK_INIT_CLEAR); /* Allocate memory for the buffer descriptors */ - addr = - (unsigned int) kmalloc(sizeof (struct txbd8) * priv->tx_ring_size + - sizeof (struct rxbd8) * priv->rx_ring_size, - GFP_KERNEL); + vaddr = (unsigned long) dma_alloc_coherent(NULL, + sizeof (struct txbd8) * priv->tx_ring_size + + sizeof (struct rxbd8) * priv->rx_ring_size, + &addr, GFP_KERNEL); - if (addr == 0) { + if (vaddr == 0) { printk(KERN_ERR "%s: Could not allocate buffer descriptors!\n", dev->name); return -ENOMEM; } - priv->tx_bd_base = (struct txbd8 *) addr; + priv->tx_bd_base = (struct txbd8 *) vaddr; /* enet DMA only understands physical addresses */ - gfar_write(®s->tbase, - dma_map_single(NULL, (void *)addr, - sizeof(struct txbd8) * priv->tx_ring_size, - DMA_BIDIRECTIONAL)); + gfar_write(®s->tbase, addr); /* Start the rx descriptor ring where the tx ring leaves off */ addr = addr + sizeof (struct txbd8) * priv->tx_ring_size; - priv->rx_bd_base = (struct rxbd8 *) addr; - gfar_write(®s->rbase, - dma_map_single(NULL, (void *)addr, - sizeof(struct rxbd8) * priv->rx_ring_size, - DMA_BIDIRECTIONAL)); + vaddr = vaddr + sizeof (struct txbd8) * priv->tx_ring_size; + priv->rx_bd_base = (struct rxbd8 *) vaddr; + gfar_write(®s->rbase, addr); /* Setup the skbuff rings */ priv->tx_skbuff = @@ -755,39 +806,13 @@ } } - /* Grab the PHY interrupt */ - if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { - if (request_irq(priv->einfo->interruptPHY, phy_interrupt, - SA_SHIRQ, "phy_interrupt", dev) < 0) { - printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", - dev->name, priv->einfo->interruptPHY); + /* Set up the PHY change work queue */ + INIT_WORK(&priv->tq, gfar_phy_change, dev); - err = -1; - - if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) - goto phy_irq_fail; - else - goto tx_irq_fail; - } - } else { - init_timer(&priv->phy_info_timer); - priv->phy_info_timer.function = &gfar_phy_timer; - priv->phy_info_timer.data = (unsigned long) dev; - mod_timer(&priv->phy_info_timer, jiffies + 2 * HZ); - } - - /* Set up the bottom half queue */ - INIT_WORK(&priv->tq, (void (*)(void *))gfar_phy_change, dev); - - /* Configure the PHY interrupt */ - phy_run_commands(dev, priv->phyinfo->startup); - - /* Tell the kernel the link is up, and determine the - * negotiated features (speed, duplex) */ - adjust_link(dev); - - if (priv->link == 0) - printk(KERN_INFO "%s: No link detected\n", dev->name); + init_timer(&priv->phy_info_timer); + priv->phy_info_timer.function = &gfar_phy_startup_timer; + priv->phy_info_timer.data = (unsigned long) priv->mii_info; + mod_timer(&priv->phy_info_timer, jiffies + HZ); /* Configure the coalescing support */ if (priv->txcoalescing) @@ -827,8 +852,6 @@ return 0; -phy_irq_fail: - free_irq(priv->einfo->interruptReceive, dev); rx_irq_fail: free_irq(priv->einfo->interruptTransmit, dev); tx_irq_fail: @@ -838,6 +861,11 @@ free_skb_resources(priv); tx_skb_fail: kfree(priv->tx_bd_base); + kfree(priv->mii_info); + + if (priv->mii_info->phyinfo->close) + priv->mii_info->phyinfo->close(priv->mii_info); + return err; } @@ -854,7 +882,7 @@ err = init_phy(dev); - if (err) + if(err) return err; err = startup_gfar(dev); @@ -1148,8 +1176,7 @@ startup_gfar(dev); } - if (!netif_queue_stopped(dev)) - netif_schedule(dev); + netif_schedule(dev); } /* Interrupt Handler for Transmit complete */ @@ -1315,7 +1342,7 @@ #else spin_lock(&priv->lock); - gfar_clean_rx_ring(dev); + gfar_clean_rx_ring(dev, priv->rx_ring_size); /* If we are coalescing interrupts, update the timer */ /* Otherwise, clear it */ @@ -1368,14 +1395,10 @@ } /* gfar_clean_rx_ring() -- Processes each frame in the rx ring - * until all are gone (or, in the case of NAPI, the budget/quota - * has been reached). Returns the number of frames handled + * until the budget/quota has been reached. Returns the number + * of frames handled */ -#ifdef CONFIG_GFAR_NAPI static int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit) -#else -static int gfar_clean_rx_ring(struct net_device *dev) -#endif { struct rxbd8 *bdp; struct sk_buff *skb; @@ -1386,12 +1409,7 @@ /* Get the first full descriptor */ bdp = priv->cur_rx; -#ifdef CONFIG_GFAR_NAPI -#define GFAR_RXDONE() ((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0)) -#else -#define GFAR_RXDONE() (bdp->status & RXBD_EMPTY) -#endif - while (!GFAR_RXDONE()) { + while (!((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0))) { skb = priv->rx_skbuff[priv->skb_currx]; if (!(bdp->status & @@ -1462,7 +1480,6 @@ if (rx_work_limit > dev->quota) rx_work_limit = dev->quota; - spin_lock(&priv->lock); howmany = gfar_clean_rx_ring(dev, rx_work_limit); dev->quota -= howmany; @@ -1489,8 +1506,6 @@ priv->rxclean = 1; } - spin_unlock(priv->lock); - return (rx_work_limit < 0) ? 1 : 0; } #endif @@ -1586,10 +1601,14 @@ struct net_device *dev = (struct net_device *) dev_id; struct gfar_private *priv = netdev_priv(dev); - /* Run the commands which acknowledge the interrupt */ - phy_run_commands(dev, priv->phyinfo->ack_int); + /* Clear the interrupt */ + mii_clear_phy_interrupt(priv->mii_info); - /* Schedule the bottom half */ + /* Disable PHY interrupts */ + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_DISABLED); + + /* Schedule the phy change */ schedule_work(&priv->tq); return IRQ_HANDLED; @@ -1600,18 +1619,24 @@ { struct net_device *dev = (struct net_device *) data; struct gfar_private *priv = netdev_priv(dev); - int timeout = HZ / 1000 + 1; + int result = 0; /* Delay to give the PHY a chance to change the * register state */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(timeout); + msleep(1); - /* Run the commands which check the link state */ - phy_run_commands(dev, priv->phyinfo->handle_int); + /* Update the link, speed, duplex */ + result = priv->mii_info->phyinfo->read_status(priv->mii_info); - /* React to the change in state */ - adjust_link(dev); + /* Adjust the known status as long as the link + * isn't still coming up */ + if((0 == result) || (priv->mii_info->link == 0)) + adjust_link(dev); + + /* Reenable interrupts, if needed */ + if (priv->einfo->flags & GFAR_HAS_PHY_INTR) + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_ENABLED); } /* Called every so often on systems that don't interrupt @@ -1623,7 +1648,72 @@ schedule_work(&priv->tq); - mod_timer(&priv->phy_info_timer, jiffies + 2 * HZ); + mod_timer(&priv->phy_info_timer, jiffies + + GFAR_PHY_CHANGE_TIME * HZ); +} + +/* Keep trying aneg for some time + * If, after GFAR_AN_TIMEOUT seconds, it has not + * finished, we switch to forced. + * Either way, once the process has completed, we either + * request the interrupt, or switch the timer over to + * using gfar_phy_timer to check status */ +static void gfar_phy_startup_timer(unsigned long data) +{ + int result; + static int secondary = GFAR_AN_TIMEOUT; + struct gfar_mii_info *mii_info = (struct gfar_mii_info *)data; + struct gfar_private *priv = netdev_priv(mii_info->dev); + + /* Configure the Auto-negotiation */ + result = mii_info->phyinfo->config_aneg(mii_info); + + /* If autonegotiation failed to start, and + * we haven't timed out, reset the timer, and return */ + if (result && secondary--) { + mod_timer(&priv->phy_info_timer, jiffies + HZ); + return; + } else if (result) { + /* Couldn't start autonegotiation. + * Try switching to forced */ + mii_info->autoneg = 0; + result = mii_info->phyinfo->config_aneg(mii_info); + + /* Forcing failed! Give up */ + if(result) { + printk(KERN_ERR "%s: Forcing failed!\n", + mii_info->dev->name); + return; + } + } + + /* Kill the timer so it can be restarted */ + del_timer_sync(&priv->phy_info_timer); + + /* Grab the PHY interrupt, if necessary/possible */ + if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { + if (request_irq(priv->einfo->interruptPHY, + phy_interrupt, + SA_SHIRQ, + "phy_interrupt", + mii_info->dev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", + mii_info->dev->name, + priv->einfo->interruptPHY); + } else { + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_ENABLED); + return; + } + } + + /* Start the timer again, this time in order to + * handle a change in status */ + init_timer(&priv->phy_info_timer); + priv->phy_info_timer.function = &gfar_phy_timer; + priv->phy_info_timer.data = (unsigned long) mii_info->dev; + mod_timer(&priv->phy_info_timer, jiffies + + GFAR_PHY_CHANGE_TIME * HZ); } /* Called every time the controller might need to be made @@ -1637,12 +1727,13 @@ struct gfar_private *priv = netdev_priv(dev); struct gfar *regs = priv->regs; u32 tempval; + struct gfar_mii_info *mii_info = priv->mii_info; - if (priv->link) { + if (mii_info->link) { /* Now we make sure that we can be in full duplex mode. * If not, we operate in half-duplex mode. */ - if (priv->duplexity != priv->olddplx) { - if (!(priv->duplexity)) { + if (mii_info->duplex != priv->oldduplex) { + if (!(mii_info->duplex)) { tempval = gfar_read(®s->maccfg2); tempval &= ~(MACCFG2_FULL_DUPLEX); gfar_write(®s->maccfg2, tempval); @@ -1658,11 +1749,11 @@ dev->name); } - priv->olddplx = priv->duplexity; + priv->oldduplex = mii_info->duplex; } - if (priv->speed != priv->oldspeed) { - switch (priv->speed) { + if (priv->mii_info->speed != priv->oldspeed) { + switch (priv->mii_info->speed) { case 1000: tempval = gfar_read(®s->maccfg2); tempval = @@ -1679,14 +1770,14 @@ default: printk(KERN_WARNING "%s: Ack! Speed (%d) is not 10/100/1000!\n", - dev->name, priv->speed); + dev->name, priv->mii_info->speed); break; } printk(KERN_INFO "%s: Speed %dBT\n", dev->name, - priv->speed); + priv->mii_info->speed); - priv->oldspeed = priv->speed; + priv->oldspeed = priv->mii_info->speed; } if (!priv->oldlink) { @@ -1700,7 +1791,7 @@ printk(KERN_INFO "%s: Link is down\n", dev->name); priv->oldlink = 0; priv->oldspeed = 0; - priv->olddplx = -1; + priv->oldduplex = -1; netif_carrier_off(dev); } } diff -Nru a/drivers/net/gianfar.h b/drivers/net/gianfar.h --- a/drivers/net/gianfar.h Wed Jul 21 12:37:04 2004 +++ b/drivers/net/gianfar.h Wed Jul 21 12:37:04 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -42,15 +42,7 @@ #include #include #include - -#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,41) #include -#else -#include -#define work_struct tq_struct -#define schedule_work schedule_task -#endif - #include #include #include @@ -70,8 +62,13 @@ #define MAC_ADDR_LEN 6 -extern char gfar_driver_name[]; -extern char gfar_driver_version[]; +#define PHY_INIT_TIMEOUT 100000 +#define GFAR_PHY_CHANGE_TIME 2 + +#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.1, " +#define DRV_NAME "gfar-enet" +extern const char gfar_driver_name[]; +extern const char gfar_driver_version[]; /* These need to be powers of 2 for this driver */ #ifdef CONFIG_GFAR_NAPI @@ -105,9 +102,11 @@ #define GFAR_100_TIME 2560 #define GFAR_10_TIME 25600 +#define DEFAULT_TX_COALESCE 1 #define DEFAULT_TXCOUNT 16 #define DEFAULT_TXTIME 32768 +#define DEFAULT_RX_COALESCE 1 #define DEFAULT_RXCOUNT 16 #define DEFAULT_RXTIME 32768 @@ -467,8 +466,7 @@ * empty and completely full conditions. The empty/ready indicator in * the buffer descriptor determines the actual condition. */ -struct gfar_private -{ +struct gfar_private { /* pointers to arrays of skbuffs for tx and rx */ struct sk_buff ** tx_skbuff; struct sk_buff ** rx_skbuff; @@ -496,7 +494,6 @@ struct txbd8 *cur_tx; /* Next free ring entry */ struct txbd8 *dirty_tx; /* The Ring entry to be freed. */ struct gfar *regs; /* Pointer to the GFAR memory mapped Registers */ - struct phy_info *phyinfo; struct gfar *phyregs; struct work_struct tq; struct timer_list phy_info_timer; @@ -509,15 +506,14 @@ unsigned int rx_ring_size; wait_queue_head_t rxcleanupq; unsigned int rxclean; - int link; /* current link state */ - int oldlink; - int duplexity; /* Indicates negotiated duplex state */ - int olddplx; - int speed; /* Indicates negotiated speed */ - int oldspeed; - + /* Info structure initialized by board setup code */ struct ocp_gfar_data *einfo; + + struct gfar_mii_info *mii_info; + int oldspeed; + int oldduplex; + int oldlink; }; extern inline u32 gfar_read(volatile unsigned *addr) @@ -532,6 +528,6 @@ out_be32(addr, val); } - +extern struct ethtool_ops *gfar_op_array[]; #endif /* __GIANFAR_H */ diff -Nru a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c --- a/drivers/net/gianfar_ethtool.c Wed Jul 21 12:37:04 2004 +++ b/drivers/net/gianfar_ethtool.c Wed Jul 21 12:37:04 2004 @@ -1,18 +1,18 @@ /* - * drivers/net/gianfar_ethtool.c + * drivers/net/gianfar_ethtool.c * - * Gianfar Ethernet Driver - * Ethtool support for Gianfar Enet - * Based on e1000 ethtool support + * Gianfar Ethernet Driver + * Ethtool support for Gianfar Enet + * Based on e1000 ethtool support * - * Author: Andy Fleming - * Maintainer: Kumar Gala (kumar.gala@freescale.com) + * Author: Andy Fleming + * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2003,2004 Freescale Semiconductor, Inc. * - * This software may be used and distributed according to - * the terms of the GNU Public License, Version 2, incorporated herein - * by reference. + * This software may be used and distributed according to + * the terms of the GNU Public License, Version 2, incorporated herein + * by reference. */ #include @@ -58,64 +58,64 @@ void gfar_gdrvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo); static char stat_gstrings[][ETH_GSTRING_LEN] = { - "RX Dropped by Kernel", - "RX Large Frame Errors", - "RX Short Frame Errors", - "RX Non-Octet Errors", - "RX CRC Errors", - "RX Overrun Errors", - "RX Busy Errors", - "RX Babbling Errors", - "RX Truncated Frames", - "Ethernet Bus Error", - "TX Babbling Errors", - "TX Underrun Errors", - "RX SKB Missing Errors", - "TX Timeout Errors", - "tx&rx 64B frames", - "tx&rx 65-127B frames", - "tx&rx 128-255B frames", - "tx&rx 256-511B frames", - "tx&rx 512-1023B frames", - "tx&rx 1024-1518B frames", - "tx&rx 1519-1522B Good VLAN", - "RX bytes", - "RX Packets", - "RX FCS Errors", - "Receive Multicast Packet", - "Receive Broadcast Packet", - "RX Control Frame Packets", - "RX Pause Frame Packets", - "RX Unknown OP Code", - "RX Alignment Error", - "RX Frame Length Error", - "RX Code Error", - "RX Carrier Sense Error", - "RX Undersize Packets", - "RX Oversize Packets", - "RX Fragmented Frames", - "RX Jabber Frames", - "RX Dropped Frames", - "TX Byte Counter", - "TX Packets", - "TX Multicast Packets", - "TX Broadcast Packets", - "TX Pause Control Frames", - "TX Deferral Packets", - "TX Excessive Deferral Packets", - "TX Single Collision Packets", - "TX Multiple Collision Packets", - "TX Late Collision Packets", - "TX Excessive Collision Packets", - "TX Total Collision", - "RESERVED", - "TX Dropped Frames", - "TX Jabber Frames", - "TX FCS Errors", - "TX Control Frames", - "TX Oversize Frames", - "TX Undersize Frames", - "TX Fragmented Frames", + "rx-dropped-by-kernel", + "rx-large-frame-errors", + "rx-short-frame-errors", + "rx-non-octet-errors", + "rx-crc-errors", + "rx-overrun-errors", + "rx-busy-errors", + "rx-babbling-errors", + "rx-truncated-frames", + "ethernet-bus-error", + "tx-babbling-errors", + "tx-underrun-errors", + "rx-skb-missing-errors", + "tx-timeout-errors", + "tx-rx-64-frames", + "tx-rx-65-127-frames", + "tx-rx-128-255-frames", + "tx-rx-256-511-frames", + "tx-rx-512-1023-frames", + "tx-rx-1024-1518-frames", + "tx-rx-1519-1522-good-vlan", + "rx-bytes", + "rx-packets", + "rx-fcs-errors", + "receive-multicast-packet", + "receive-broadcast-packet", + "rx-control-frame-packets", + "rx-pause-frame-packets", + "rx-unknown-op-code", + "rx-alignment-error", + "rx-frame-length-error", + "rx-code-error", + "rx-carrier-sense-error", + "rx-undersize-packets", + "rx-oversize-packets", + "rx-fragmented-frames", + "rx-jabber-frames", + "rx-dropped-frames", + "tx-byte-counter", + "tx-packets", + "tx-multicast-packets", + "tx-broadcast-packets", + "tx-pause-control-frames", + "tx-deferral-packets", + "tx-excessive-deferral-packets", + "tx-single-collision-packets", + "tx-multiple-collision-packets", + "tx-late-collision-packets", + "tx-excessive-collision-packets", + "tx-total-collision", + "reserved", + "tx-dropped-frames", + "tx-jabber-frames", + "tx-fcs-errors", + "tx-control-frames", + "tx-oversize-frames", + "tx-undersize-frames", + "tx-fragmented-frames", }; /* Fill in an array of 64-bit statistics from various sources. @@ -125,7 +125,7 @@ void gfar_fill_stats(struct net_device *dev, struct ethtool_stats *dummy, u64 * buf) { int i; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); u32 *rmon = (u32 *) & priv->regs->rmon; u64 *extra = (u64 *) & priv->extra_stats; struct gfar_stats *stats = (struct gfar_stats *) buf; @@ -154,7 +154,7 @@ struct ethtool_stats *dummy, u64 * buf) { int i; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); u64 *extra = (u64 *) & priv->extra_stats; for (i = 0; i < GFAR_EXTRA_STATS_LEN; i++) { @@ -171,7 +171,7 @@ void gfar_gdrvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo) { - strncpy(drvinfo->driver, gfar_driver_name, GFAR_INFOSTR_LEN); + strncpy(drvinfo->driver, DRV_NAME, GFAR_INFOSTR_LEN); strncpy(drvinfo->version, gfar_driver_version, GFAR_INFOSTR_LEN); strncpy(drvinfo->fw_version, "N/A", GFAR_INFOSTR_LEN); strncpy(drvinfo->bus_info, "N/A", GFAR_INFOSTR_LEN); @@ -184,7 +184,7 @@ /* Return the current settings in the ethtool_cmd structure */ int gfar_gsettings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); uint gigabit_support = priv->einfo->flags & GFAR_HAS_GIGABIT ? SUPPORTED_1000baseT_Full : 0; uint gigabit_advert = @@ -201,10 +201,10 @@ | ADVERTISED_100baseT_Full | gigabit_advert | ADVERTISED_Autoneg); - cmd->speed = priv->speed; - cmd->duplex = priv->duplexity; + cmd->speed = priv->mii_info->speed; + cmd->duplex = priv->mii_info->duplex; cmd->port = PORT_MII; - cmd->phy_address = priv->einfo->phyid; + cmd->phy_address = priv->mii_info->mii_id; cmd->transceiver = XCVR_EXTERNAL; cmd->autoneg = AUTONEG_ENABLE; cmd->maxtxpkt = priv->txcount; @@ -223,7 +223,7 @@ void gfar_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *regbuf) { int i; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); u32 *theregs = (u32 *) priv->regs; u32 *buf = (u32 *) regbuf; @@ -231,13 +231,6 @@ buf[i] = theregs[i]; } -/* Return the link state 1 is up, 0 is down */ -u32 gfar_get_link(struct net_device *dev) -{ - struct gfar_private *priv = (struct gfar_private *) dev->priv; - return (u32) priv->link; -} - /* Fill in a buffer with the strings which correspond to the * stats */ void gfar_gstrings(struct net_device *dev, u32 stringset, u8 * buf) @@ -252,7 +245,7 @@ unsigned int count; /* The timer is different, depending on the interface speed */ - switch (priv->speed) { + switch (priv->mii_info->speed) { case 1000: count = GFAR_GBIT_TIME; break; @@ -276,7 +269,7 @@ unsigned int count; /* The timer is different, depending on the interface speed */ - switch (priv->speed) { + switch (priv->mii_info->speed) { case 1000: count = GFAR_GBIT_TIME; break; @@ -298,7 +291,7 @@ * structure. */ int gfar_gcoalesce(struct net_device *dev, struct ethtool_coalesce *cvals) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); cvals->rx_coalesce_usecs = gfar_ticks2usecs(priv, priv->rxtime); cvals->rx_max_coalesced_frames = priv->rxcount; @@ -344,7 +337,7 @@ */ int gfar_scoalesce(struct net_device *dev, struct ethtool_coalesce *cvals) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); /* Set up rx coalescing */ if ((cvals->rx_coalesce_usecs == 0) || @@ -386,7 +379,7 @@ * jumbo are ignored by the driver */ void gfar_gringparam(struct net_device *dev, struct ethtool_ringparam *rvals) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); rvals->rx_max_pending = GFAR_RX_MAX_RING_SIZE; rvals->rx_mini_max_pending = GFAR_RX_MAX_RING_SIZE; @@ -409,7 +402,7 @@ int gfar_sringparam(struct net_device *dev, struct ethtool_ringparam *rvals) { u32 tempval; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); int err = 0; if (rvals->rx_pending > GFAR_RX_MAX_RING_SIZE) @@ -473,7 +466,7 @@ .get_drvinfo = gfar_gdrvinfo, .get_regs_len = gfar_reglen, .get_regs = gfar_get_regs, - .get_link = gfar_get_link, + .get_link = ethtool_op_get_link, .get_coalesce = gfar_gcoalesce, .set_coalesce = gfar_scoalesce, .get_ringparam = gfar_gringparam, @@ -481,4 +474,52 @@ .get_strings = gfar_gstrings, .get_stats_count = gfar_stats_count, .get_ethtool_stats = gfar_fill_stats, +}; + +struct ethtool_ops gfar_normon_nocoalesce_ethtool_ops = { + .get_settings = gfar_gsettings, + .get_drvinfo = gfar_gdrvinfo, + .get_regs_len = gfar_reglen, + .get_regs = gfar_get_regs, + .get_link = ethtool_op_get_link, + .get_ringparam = gfar_gringparam, + .set_ringparam = gfar_sringparam, + .get_strings = gfar_gstrings_normon, + .get_stats_count = gfar_stats_count_normon, + .get_ethtool_stats = gfar_fill_stats_normon, +}; + +struct ethtool_ops gfar_nocoalesce_ethtool_ops = { + .get_settings = gfar_gsettings, + .get_drvinfo = gfar_gdrvinfo, + .get_regs_len = gfar_reglen, + .get_regs = gfar_get_regs, + .get_link = ethtool_op_get_link, + .get_ringparam = gfar_gringparam, + .set_ringparam = gfar_sringparam, + .get_strings = gfar_gstrings, + .get_stats_count = gfar_stats_count, + .get_ethtool_stats = gfar_fill_stats, +}; + +struct ethtool_ops gfar_normon_ethtool_ops = { + .get_settings = gfar_gsettings, + .get_drvinfo = gfar_gdrvinfo, + .get_regs_len = gfar_reglen, + .get_regs = gfar_get_regs, + .get_link = ethtool_op_get_link, + .get_coalesce = gfar_gcoalesce, + .set_coalesce = gfar_scoalesce, + .get_ringparam = gfar_gringparam, + .set_ringparam = gfar_sringparam, + .get_strings = gfar_gstrings_normon, + .get_stats_count = gfar_stats_count_normon, + .get_ethtool_stats = gfar_fill_stats_normon, +}; + +struct ethtool_ops *gfar_op_array[] = { + &gfar_ethtool_ops, + &gfar_normon_ethtool_ops, + &gfar_nocoalesce_ethtool_ops, + &gfar_normon_nocoalesce_ethtool_ops }; diff -Nru a/drivers/net/gianfar_phy.c b/drivers/net/gianfar_phy.c --- a/drivers/net/gianfar_phy.c Wed Jul 21 12:37:04 2004 +++ b/drivers/net/gianfar_phy.c Wed Jul 21 12:37:04 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -38,21 +38,31 @@ #include #include #include +#include #include "gianfar.h" #include "gianfar_phy.h" +static void config_genmii_advert(struct gfar_mii_info *mii_info); +static void genmii_setup_forced(struct gfar_mii_info *mii_info); +static void genmii_restart_aneg(struct gfar_mii_info *mii_info); +static int gbit_config_aneg(struct gfar_mii_info *mii_info); +static int genmii_config_aneg(struct gfar_mii_info *mii_info); +static int genmii_update_link(struct gfar_mii_info *mii_info); +static int genmii_read_status(struct gfar_mii_info *mii_info); +u16 phy_read(struct gfar_mii_info *mii_info, u16 regnum); +void phy_write(struct gfar_mii_info *mii_info, u16 regnum, u16 val); + /* Write value to the PHY for this device to the register at regnum, */ /* waiting until the write is done before it returns. All PHY */ /* configuration has to be done through the TSEC1 MIIM regs */ -void write_phy_reg(struct net_device *dev, u16 regnum, u16 value) +void write_phy_reg(struct net_device *dev, int mii_id, int regnum, int value) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); struct gfar *regbase = priv->phyregs; - struct ocp_gfar_data *einfo = priv->einfo; /* Set the PHY address and the register address we want to write */ - gfar_write(®base->miimadd, ((einfo->phyid) << 8) | regnum); + gfar_write(®base->miimadd, (mii_id << 8) | regnum); /* Write out the value we want */ gfar_write(®base->miimcon, value); @@ -65,19 +75,18 @@ /* Reads from register regnum in the PHY for device dev, */ /* returning the value. Clears miimcom first. All PHY */ /* configuration has to be done through the TSEC1 MIIM regs */ -u16 read_phy_reg(struct net_device *dev, u16 regnum) +int read_phy_reg(struct net_device *dev, int mii_id, int regnum) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); struct gfar *regbase = priv->phyregs; - struct ocp_gfar_data *einfo = priv->einfo; u16 value; /* Set the PHY address and the register address we want to read */ - gfar_write(®base->miimadd, ((einfo->phyid) << 8) | regnum); + gfar_write(®base->miimadd, (mii_id << 8) | regnum); /* Clear miimcom, and then initiate a read */ gfar_write(®base->miimcom, 0); - gfar_write(®base->miimcom, MIIM_READ_COMMAND); + gfar_write(®base->miimcom, MII_READ_COMMAND); /* Wait for the transaction to finish */ while (gfar_read(®base->miimind) & (MIIMIND_NOTVALID | MIIMIND_BUSY)) @@ -89,362 +98,515 @@ return value; } -/* returns which value to write to the control register. */ -/* For 10/100 the value is slightly different. */ -u16 mii_cr_init(u16 mii_reg, struct net_device * dev) +/* Writes MII_ADVERTISE with the appropriate values, after + * sanitizing advertise to make sure only supported features + * are advertised + */ +static void config_genmii_advert(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; - struct ocp_gfar_data *einfo = priv->einfo; + u32 advertise; + u16 adv; - if (einfo->flags & GFAR_HAS_GIGABIT) - return MIIM_CONTROL_INIT; - else - return MIIM_CR_INIT; + /* Only allow advertising what this PHY supports */ + mii_info->advertising &= mii_info->phyinfo->features; + advertise = mii_info->advertising; + + /* Setup standard advertisement */ + adv = phy_read(mii_info, MII_ADVERTISE); + adv &= ~(ADVERTISE_ALL | ADVERTISE_100BASE4); + if (advertise & ADVERTISED_10baseT_Half) + adv |= ADVERTISE_10HALF; + if (advertise & ADVERTISED_10baseT_Full) + adv |= ADVERTISE_10FULL; + if (advertise & ADVERTISED_100baseT_Half) + adv |= ADVERTISE_100HALF; + if (advertise & ADVERTISED_100baseT_Full) + adv |= ADVERTISE_100FULL; + phy_write(mii_info, MII_ADVERTISE, adv); +} + +static void genmii_setup_forced(struct gfar_mii_info *mii_info) +{ + u16 ctrl; + u32 features = mii_info->phyinfo->features; + + ctrl = phy_read(mii_info, MII_BMCR); + + ctrl &= ~(BMCR_FULLDPLX|BMCR_SPEED100|BMCR_SPEED1000|BMCR_ANENABLE); + ctrl |= BMCR_RESET; + + switch(mii_info->speed) { + case SPEED_1000: + if(features & (SUPPORTED_1000baseT_Half + | SUPPORTED_1000baseT_Full)) { + ctrl |= BMCR_SPEED1000; + break; + } + mii_info->speed = SPEED_100; + case SPEED_100: + if (features & (SUPPORTED_100baseT_Half + | SUPPORTED_100baseT_Full)) { + ctrl |= BMCR_SPEED100; + break; + } + mii_info->speed = SPEED_10; + case SPEED_10: + if (features & (SUPPORTED_10baseT_Half + | SUPPORTED_10baseT_Full)) + break; + default: /* Unsupported speed! */ + printk(KERN_ERR "%s: Bad speed!\n", + mii_info->dev->name); + break; + } + + phy_write(mii_info, MII_BMCR, ctrl); +} + + +/* Enable and Restart Autonegotiation */ +static void genmii_restart_aneg(struct gfar_mii_info *mii_info) +{ + u16 ctl; + + ctl = phy_read(mii_info, MII_BMCR); + ctl |= (BMCR_ANENABLE | BMCR_ANRESTART); + phy_write(mii_info, MII_BMCR, ctl); +} + + +static int gbit_config_aneg(struct gfar_mii_info *mii_info) +{ + u16 adv; + u32 advertise; + + if(mii_info->autoneg) { + /* Configure the ADVERTISE register */ + config_genmii_advert(mii_info); + advertise = mii_info->advertising; + + adv = phy_read(mii_info, MII_1000BASETCONTROL); + adv &= ~(MII_1000BASETCONTROL_FULLDUPLEXCAP | + MII_1000BASETCONTROL_HALFDUPLEXCAP); + if (advertise & SUPPORTED_1000baseT_Half) + adv |= MII_1000BASETCONTROL_HALFDUPLEXCAP; + if (advertise & SUPPORTED_1000baseT_Full) + adv |= MII_1000BASETCONTROL_FULLDUPLEXCAP; + phy_write(mii_info, MII_1000BASETCONTROL, adv); + + /* Start/Restart aneg */ + genmii_restart_aneg(mii_info); + } else + genmii_setup_forced(mii_info); + + return 0; } -#define BRIEF_GFAR_ERRORS -/* Wait for auto-negotiation to complete */ -u16 mii_parse_sr(u16 mii_reg, struct net_device * dev) + +static int genmii_config_aneg(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + if (mii_info->autoneg) { + config_genmii_advert(mii_info); + genmii_restart_aneg(mii_info); + } else + genmii_setup_forced(mii_info); - unsigned int timeout = GFAR_AN_TIMEOUT; + return 0; +} - if (mii_reg & MIIM_STATUS_LINK) - priv->link = 1; + +static int genmii_update_link(struct gfar_mii_info *mii_info) +{ + u16 status; + + /* Do a fake read */ + phy_read(mii_info, MII_BMSR); + + /* Read link and autonegotiation status */ + status = phy_read(mii_info, MII_BMSR); + if ((status & BMSR_LSTATUS) == 0) + mii_info->link = 0; else - priv->link = 0; + mii_info->link = 1; - /* Only auto-negotiate if the link has just gone up */ - if (priv->link && !priv->oldlink) { - while ((!(mii_reg & MIIM_STATUS_AN_DONE)) && timeout--) - mii_reg = read_phy_reg(dev, MIIM_STATUS); - -#if defined(BRIEF_GFAR_ERRORS) - if (mii_reg & MIIM_STATUS_AN_DONE) - printk(KERN_INFO "%s: Auto-negotiation done\n", - dev->name); - else - printk(KERN_INFO "%s: Auto-negotiation timed out\n", - dev->name); -#endif - } + /* If we are autonegotiating, and not done, + * return an error */ + if (mii_info->autoneg && !(status & BMSR_ANEGCOMPLETE)) + return -EAGAIN; return 0; } -/* Determine the speed and duplex which was negotiated */ -u16 mii_parse_88E1011_psr(u16 mii_reg, struct net_device * dev) +static int genmii_read_status(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; - unsigned int speed; + u16 status; + int err; + + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; - if (priv->link) { - if (mii_reg & MIIM_88E1011_PHYSTAT_DUPLEX) - priv->duplexity = 1; + if (mii_info->autoneg) { + status = phy_read(mii_info, MII_LPA); + + if (status & (LPA_10FULL | LPA_100FULL)) + mii_info->duplex = DUPLEX_FULL; + else + mii_info->duplex = DUPLEX_HALF; + if (status & (LPA_100FULL | LPA_100HALF)) + mii_info->speed = SPEED_100; else - priv->duplexity = 0; + mii_info->speed = SPEED_10; + mii_info->pause = 0; + } + /* On non-aneg, we assume what we put in BMCR is the speed, + * though magic-aneg shouldn't prevent this case from occurring + */ - speed = (mii_reg & MIIM_88E1011_PHYSTAT_SPEED); + return 0; +} +static int marvell_read_status(struct gfar_mii_info *mii_info) +{ + u16 status; + int err; - switch (speed) { - case MIIM_88E1011_PHYSTAT_GBIT: - priv->speed = 1000; - break; - case MIIM_88E1011_PHYSTAT_100: - priv->speed = 100; - break; - default: - priv->speed = 10; - break; + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; + + /* If the link is up, read the speed and duplex */ + /* If we aren't autonegotiating, assume speeds + * are as set */ + if (mii_info->autoneg && mii_info->link) { + int speed; + status = phy_read(mii_info, MII_M1011_PHY_SPEC_STATUS); + +#if 0 + /* If speed and duplex aren't resolved, + * return an error. Isn't this handled + * by checking aneg? + */ + if ((status & MII_M1011_PHY_SPEC_STATUS_RESOLVED) == 0) + return -EAGAIN; +#endif + + /* Get the duplexity */ + if (status & MII_M1011_PHY_SPEC_STATUS_FULLDUPLEX) + mii_info->duplex = DUPLEX_FULL; + else + mii_info->duplex = DUPLEX_HALF; + + /* Get the speed */ + speed = status & MII_M1011_PHY_SPEC_STATUS_SPD_MASK; + switch(speed) { + case MII_M1011_PHY_SPEC_STATUS_1000: + mii_info->speed = SPEED_1000; + break; + case MII_M1011_PHY_SPEC_STATUS_100: + mii_info->speed = SPEED_100; + break; + default: + mii_info->speed = SPEED_10; + break; } - } else { - priv->speed = 0; - priv->duplexity = 0; + mii_info->pause = 0; } return 0; } -u16 mii_parse_cis8201(u16 mii_reg, struct net_device * dev) + +static int cis820x_read_status(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; - unsigned int speed; + u16 status; + int err; - if (priv->link) { - if (mii_reg & MIIM_CIS8201_AUXCONSTAT_DUPLEX) - priv->duplexity = 1; + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; + + /* If the link is up, read the speed and duplex */ + /* If we aren't autonegotiating, assume speeds + * are as set */ + if (mii_info->autoneg && mii_info->link) { + int speed; + + status = phy_read(mii_info, MII_CIS8201_AUX_CONSTAT); + if (status & MII_CIS8201_AUXCONSTAT_DUPLEX) + mii_info->duplex = DUPLEX_FULL; else - priv->duplexity = 0; + mii_info->duplex = DUPLEX_HALF; - speed = mii_reg & MIIM_CIS8201_AUXCONSTAT_SPEED; + speed = status & MII_CIS8201_AUXCONSTAT_SPEED; switch (speed) { - case MIIM_CIS8201_AUXCONSTAT_GBIT: - priv->speed = 1000; + case MII_CIS8201_AUXCONSTAT_GBIT: + mii_info->speed = SPEED_1000; break; - case MIIM_CIS8201_AUXCONSTAT_100: - priv->speed = 100; + case MII_CIS8201_AUXCONSTAT_100: + mii_info->speed = SPEED_100; break; default: - priv->speed = 10; + mii_info->speed = SPEED_10; break; } - } else { - priv->speed = 0; - priv->duplexity = 0; } return 0; } -u16 mii_parse_dm9161_scsr(u16 mii_reg, struct net_device * dev) +static int marvell_ack_interrupt(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + /* Clear the interrupts by reading the reg */ + phy_read(mii_info, MII_M1011_IEVENT); + + return 0; +} - if (mii_reg & (MIIM_DM9161_SCSR_100F | MIIM_DM9161_SCSR_100H)) - priv->speed = 100; +static int marvell_config_intr(struct gfar_mii_info *mii_info) +{ + if(mii_info->interrupts == MII_INTERRUPT_ENABLED) + phy_write(mii_info, MII_M1011_IMASK, MII_M1011_IMASK_INIT); else - priv->speed = 10; + phy_write(mii_info, MII_M1011_IMASK, MII_M1011_IMASK_CLEAR); - if (mii_reg & (MIIM_DM9161_SCSR_100F | MIIM_DM9161_SCSR_10F)) - priv->duplexity = 1; + return 0; +} + +static int cis820x_init(struct gfar_mii_info *mii_info) +{ + phy_write(mii_info, MII_CIS8201_AUX_CONSTAT, + MII_CIS8201_AUXCONSTAT_INIT); + phy_write(mii_info, MII_CIS8201_EXT_CON1, + MII_CIS8201_EXTCON1_INIT); + + return 0; +} + +static int cis820x_ack_interrupt(struct gfar_mii_info *mii_info) +{ + phy_read(mii_info, MII_CIS8201_ISTAT); + + return 0; +} + +static int cis820x_config_intr(struct gfar_mii_info *mii_info) +{ + if(mii_info->interrupts == MII_INTERRUPT_ENABLED) + phy_write(mii_info, MII_CIS8201_IMASK, MII_CIS8201_IMASK_MASK); else - priv->duplexity = 0; + phy_write(mii_info, MII_CIS8201_IMASK, 0); return 0; } -u16 dm9161_wait(u16 mii_reg, struct net_device *dev) +#define DM9161_DELAY 10 + +static int dm9161_read_status(struct gfar_mii_info *mii_info) { - int timeout = HZ; - int secondary = 10; - u16 temp; - - do { - - /* Davicom takes a bit to come up after a reset, - * so wait here for a bit */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(timeout); - - temp = read_phy_reg(dev, MIIM_STATUS); - - secondary--; - } while ((!(temp & MIIM_STATUS_AN_DONE)) && secondary); - - return 0; -} - -static struct phy_info phy_info_M88E1011S = { - 0x01410c6, - "Marvell 88E1011S", - 4, - (const struct phy_cmd[]) { /* config */ - /* Reset and configure the PHY */ - {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Status is read once to clear old link state */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_88E1011_PHY_STATUS, miim_read, mii_parse_88E1011_psr}, - /* Clear the IEVENT register */ - {MIIM_88E1011_IEVENT, miim_read, NULL}, - /* Set up the mask */ - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_INIT, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - /* Clear the interrupt */ - {MIIM_88E1011_IEVENT, miim_read, NULL}, - /* Disable interrupts */ - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_CLEAR, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Check the status */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - {MIIM_88E1011_PHY_STATUS, miim_read, mii_parse_88E1011_psr}, - /* Enable Interrupts */ - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_INIT, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - {MIIM_88E1011_IEVENT, miim_read, NULL}, - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_CLEAR, NULL}, - {miim_end,} - }, -}; + u16 status; + int err; + + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; + + /* If the link is up, read the speed and duplex */ + /* If we aren't autonegotiating, assume speeds + * are as set */ + if (mii_info->autoneg && mii_info->link) { + status = phy_read(mii_info, MII_DM9161_SCSR); + if (status & (MII_DM9161_SCSR_100F | MII_DM9161_SCSR_100H)) + mii_info->speed = SPEED_100; + else + mii_info->speed = SPEED_10; + + if (status & (MII_DM9161_SCSR_100F | MII_DM9161_SCSR_10F)) + mii_info->duplex = DUPLEX_FULL; + else + mii_info->duplex = DUPLEX_HALF; + } + + return 0; +} + + +static int dm9161_config_aneg(struct gfar_mii_info *mii_info) +{ + struct dm9161_private *priv = mii_info->priv; + + if(0 == priv->resetdone) + return -EAGAIN; + + return 0; +} + +static void dm9161_timer(unsigned long data) +{ + struct gfar_mii_info *mii_info = (struct gfar_mii_info *)data; + struct dm9161_private *priv = mii_info->priv; + u16 status = phy_read(mii_info, MII_BMSR); + + if (status & BMSR_ANEGCOMPLETE) { + priv->resetdone = 1; + } else + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); +} + +static int dm9161_init(struct gfar_mii_info *mii_info) +{ + struct dm9161_private *priv; + + /* Allocate the private data structure */ + priv = kmalloc(sizeof(struct dm9161_private), GFP_KERNEL); + + if (NULL == priv) + return -ENOMEM; + + mii_info->priv = priv; + + /* Reset is not done yet */ + priv->resetdone = 0; + + /* Isolate the PHY */ + phy_write(mii_info, MII_BMCR, BMCR_ISOLATE); + + /* Do not bypass the scrambler/descrambler */ + phy_write(mii_info, MII_DM9161_SCR, MII_DM9161_SCR_INIT); + + /* Clear 10BTCSR to default */ + phy_write(mii_info, MII_DM9161_10BTCSR, MII_DM9161_10BTCSR_INIT); + + /* Reconnect the PHY, and enable Autonegotiation */ + phy_write(mii_info, MII_BMCR, BMCR_ANENABLE); + + /* Start a timer for DM9161_DELAY seconds to wait + * for the PHY to be ready */ + init_timer(&priv->timer); + priv->timer.function = &dm9161_timer; + priv->timer.data = (unsigned long) mii_info; + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + + return 0; +} -/* Cicada 8204 */ -static struct phy_info phy_info_cis8204 = { - 0x3f11, +static void dm9161_close(struct gfar_mii_info *mii_info) +{ + struct dm9161_private *priv = mii_info->priv; + + del_timer_sync(&priv->timer); + kfree(priv); +} + +#if 0 +static int dm9161_ack_interrupt(struct gfar_mii_info *mii_info) +{ + phy_read(mii_info, MII_DM9161_INTR); + + return 0; +} +#endif + +/* Cicada 820x */ +static struct phy_info phy_info_cis820x = { + 0x000fc440, "Cicada Cis8204", - 6, - (const struct phy_cmd[]) { /* config */ - /* Override PHY config settings */ - {MIIM_CIS8201_AUX_CONSTAT, MIIM_CIS8201_AUXCONSTAT_INIT, NULL}, - /* Set up the interface mode */ - {MIIM_CIS8201_EXT_CON1, MIIM_CIS8201_EXTCON1_INIT, NULL}, - /* Configure some basic stuff */ - {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, - /* Clear the status register */ - {MIIM_CIS8204_ISTAT, miim_read, NULL}, - /* Enable interrupts */ - {MIIM_CIS8204_IMASK, MIIM_CIS8204_IMASK_MASK, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - /* Clear the status register */ - {MIIM_CIS8204_ISTAT, miim_read, NULL}, - /* Disable interrupts */ - {MIIM_CIS8204_IMASK, 0x0, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, - /* Enable interrupts */ - {MIIM_CIS8204_IMASK, MIIM_CIS8204_IMASK_MASK, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - /* Clear the status register */ - {MIIM_CIS8204_ISTAT, miim_read, NULL}, - /* Disable interrupts */ - {MIIM_CIS8204_IMASK, 0x0, NULL}, - {miim_end,} - }, + 0x000fffc0, + .features = MII_GBIT_FEATURES, + .init = &cis820x_init, + .config_aneg = &gbit_config_aneg, + .read_status = &cis820x_read_status, + .ack_interrupt = &cis820x_ack_interrupt, + .config_intr = &cis820x_config_intr, }; -/* Cicada 8201 */ -static struct phy_info phy_info_cis8201 = { - 0xfc41, - "CIS8201", - 4, - (const struct phy_cmd[]) { /* config */ - /* Override PHY config settings */ - {MIIM_CIS8201_AUX_CONSTAT, MIIM_CIS8201_AUXCONSTAT_INIT, NULL}, - /* Set up the interface mode */ - {MIIM_CIS8201_EXT_CON1, MIIM_CIS8201_EXTCON1_INIT, NULL}, - /* Configure some basic stuff */ - {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - {miim_end,} - }, +static struct phy_info phy_info_dm9161 = { + .phy_id = 0x0181b880, + .name = "Davicom DM9161E", + .phy_id_mask = 0x0ffffff0, + .init = dm9161_init, + .config_aneg = dm9161_config_aneg, + .read_status = dm9161_read_status, + .close = dm9161_close, }; -static struct phy_info phy_info_dm9161 = { - 0x0181b88, - "Davicom DM9161E", - 4, - (const struct phy_cmd[]) { /* config */ - {MIIM_CONTROL, MIIM_DM9161_CR_STOP, NULL}, - /* Do not bypass the scrambler/descrambler */ - {MIIM_DM9161_SCR, MIIM_DM9161_SCR_INIT, NULL}, - /* Clear 10BTCSR to default */ - {MIIM_DM9161_10BTCSR, MIIM_DM9161_10BTCSR_INIT, NULL}, - /* Configure some basic stuff */ - {MIIM_CONTROL, MIIM_CR_INIT, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Restart Auto Negotiation */ - {MIIM_CONTROL, MIIM_DM9161_CR_RSTAN, NULL}, - /* Status is read once to clear old link state */ - {MIIM_STATUS, miim_read, dm9161_wait}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_DM9161_SCSR, miim_read, mii_parse_dm9161_scsr}, - /* Clear any pending interrupts */ - {MIIM_DM9161_INTR, miim_read, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - {MIIM_DM9161_INTR, miim_read, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - {MIIM_STATUS, miim_read, NULL}, - {MIIM_STATUS, miim_read, mii_parse_sr}, - {MIIM_DM9161_SCSR, miim_read, mii_parse_dm9161_scsr}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - {MIIM_DM9161_INTR, miim_read, NULL}, - {miim_end,} - }, +static struct phy_info phy_info_marvell = { + .phy_id = 0x01410c00, + .phy_id_mask = 0xffffff00, + .name = "Marvell 88E1101", + .features = MII_GBIT_FEATURES, + .config_aneg = &gbit_config_aneg, + .read_status = &marvell_read_status, + .ack_interrupt = &marvell_ack_interrupt, + .config_intr = &marvell_config_intr, +}; + +static struct phy_info phy_info_genmii= { + .phy_id = 0x00000000, + .phy_id_mask = 0x00000000, + .name = "Generic MII", + .features = MII_BASIC_FEATURES, + .config_aneg = genmii_config_aneg, + .read_status = genmii_read_status, }; static struct phy_info *phy_info[] = { - &phy_info_cis8201, - &phy_info_cis8204, - &phy_info_M88E1011S, + &phy_info_cis820x, + &phy_info_marvell, &phy_info_dm9161, + &phy_info_genmii, NULL }; +u16 phy_read(struct gfar_mii_info *mii_info, u16 regnum) +{ + return mii_info->mdio_read(mii_info->dev, mii_info->mii_id, regnum); +} + +void phy_write(struct gfar_mii_info *mii_info, u16 regnum, u16 val) +{ + mii_info->mdio_write(mii_info->dev, + mii_info->mii_id, + regnum, val); +} + /* Use the PHY ID registers to determine what type of PHY is attached * to device dev. return a struct phy_info structure describing that PHY */ -struct phy_info * get_phy_info(struct net_device *dev) +struct phy_info * get_phy_info(struct gfar_mii_info *mii_info) { u16 phy_reg; u32 phy_ID; int i; struct phy_info *theInfo = NULL; + struct net_device *dev = mii_info->dev; /* Grab the bits from PHYIR1, and put them in the upper half */ - phy_reg = read_phy_reg(dev, MIIM_PHYIR1); + phy_reg = phy_read(mii_info, MII_PHYSID1); phy_ID = (phy_reg & 0xffff) << 16; /* Grab the bits from PHYIR2, and put them in the lower half */ - phy_reg = read_phy_reg(dev, MIIM_PHYIR2); + phy_reg = phy_read(mii_info, MII_PHYSID2); phy_ID |= (phy_reg & 0xffff); /* loop through all the known PHY types, and find one that */ /* matches the ID we read from the PHY. */ for (i = 0; phy_info[i]; i++) - if (phy_info[i]->id == (phy_ID >> phy_info[i]->shift)) + if (phy_info[i]->phy_id == + (phy_ID & phy_info[i]->phy_id_mask)) { theInfo = phy_info[i]; + break; + } + /* This shouldn't happen, as we have generic PHY support */ if (theInfo == NULL) { printk("%s: PHY id %x is not supported!\n", dev->name, phy_ID); return NULL; @@ -454,51 +616,4 @@ } return theInfo; -} - -/* Take a list of struct phy_cmd, and, depending on the values, either */ -/* read or write, using a helper function if provided */ -/* It is assumed that all lists of struct phy_cmd will be terminated by */ -/* mii_end. */ -void phy_run_commands(struct net_device *dev, const struct phy_cmd *cmd) -{ - int i; - u16 result; - struct gfar_private *priv = (struct gfar_private *) dev->priv; - struct gfar *phyregs = priv->phyregs; - - /* Reset the management interface */ - gfar_write(&phyregs->miimcfg, MIIMCFG_RESET); - - /* Setup the MII Mgmt clock speed */ - gfar_write(&phyregs->miimcfg, MIIMCFG_INIT_VALUE); - - /* Wait until the bus is free */ - while (gfar_read(&phyregs->miimind) & MIIMIND_BUSY) - cpu_relax(); - - for (i = 0; cmd->mii_reg != miim_end; i++) { - /* The command is a read if mii_data is miim_read */ - if (cmd->mii_data == miim_read) { - /* Read the value of the PHY reg */ - result = read_phy_reg(dev, cmd->mii_reg); - - /* If a function was supplied, we need to let it process */ - /* the result. */ - if (cmd->funct != NULL) - (*(cmd->funct)) (result, dev); - } else { /* Otherwise, it's a write */ - /* If a function was supplied, it will provide - * the value to write */ - /* Otherwise, the value was supplied in cmd->mii_data */ - if (cmd->funct != NULL) - result = (*(cmd->funct)) (0, dev); - else - result = cmd->mii_data; - - /* Write the appropriate value to the PHY reg */ - write_phy_reg(dev, cmd->mii_reg, result); - } - cmd++; - } } diff -Nru a/drivers/net/gianfar_phy.h b/drivers/net/gianfar_phy.h --- a/drivers/net/gianfar_phy.h Wed Jul 21 12:37:04 2004 +++ b/drivers/net/gianfar_phy.h Wed Jul 21 12:37:04 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -19,135 +19,138 @@ #ifndef __GIANFAR_PHY_H #define __GIANFAR_PHY_H -#define miim_end ((u32)-2) -#define miim_read ((u32)-1) +#define MII_end ((u32)-2) +#define MII_read ((u32)-1) #define MIIMIND_BUSY 0x00000001 #define MIIMIND_NOTVALID 0x00000004 -#define MIIM_CONTROL 0x00 -#define MIIM_CONTROL_RESET 0x00008000 -#define MIIM_CONTROL_INIT 0x00001140 -#define MIIM_ANEN 0x00001000 - -#define MIIM_CR 0x00 -#define MIIM_CR_RST 0x00008000 -#define MIIM_CR_INIT 0x00001000 - -#define MIIM_STATUS 0x1 -#define MIIM_STATUS_AN_DONE 0x00000020 -#define MIIM_STATUS_LINK 0x0004 - -#define MIIM_PHYIR1 0x2 -#define MIIM_PHYIR2 0x3 - -#define GFAR_AN_TIMEOUT 0x000fffff - -#define MIIM_ANLPBPA 0x5 -#define MIIM_ANLPBPA_HALF 0x00000040 -#define MIIM_ANLPBPA_FULL 0x00000020 - -#define MIIM_ANEX 0x6 -#define MIIM_ANEX_NP 0x00000004 -#define MIIM_ANEX_PRX 0x00000002 +#define GFAR_AN_TIMEOUT 2000 +/* 1000BT control (Marvell & BCM54xx at least) */ +#define MII_1000BASETCONTROL 0x09 +#define MII_1000BASETCONTROL_FULLDUPLEXCAP 0x0200 +#define MII_1000BASETCONTROL_HALFDUPLEXCAP 0x0100 /* Cicada Extended Control Register 1 */ -#define MIIM_CIS8201_EXT_CON1 0x17 -#define MIIM_CIS8201_EXTCON1_INIT 0x0000 +#define MII_CIS8201_EXT_CON1 0x17 +#define MII_CIS8201_EXTCON1_INIT 0x0000 /* Cicada Interrupt Mask Register */ -#define MIIM_CIS8204_IMASK 0x19 -#define MIIM_CIS8204_IMASK_IEN 0x8000 -#define MIIM_CIS8204_IMASK_SPEED 0x4000 -#define MIIM_CIS8204_IMASK_LINK 0x2000 -#define MIIM_CIS8204_IMASK_DUPLEX 0x1000 -#define MIIM_CIS8204_IMASK_MASK 0xf000 +#define MII_CIS8201_IMASK 0x19 +#define MII_CIS8201_IMASK_IEN 0x8000 +#define MII_CIS8201_IMASK_SPEED 0x4000 +#define MII_CIS8201_IMASK_LINK 0x2000 +#define MII_CIS8201_IMASK_DUPLEX 0x1000 +#define MII_CIS8201_IMASK_MASK 0xf000 /* Cicada Interrupt Status Register */ -#define MIIM_CIS8204_ISTAT 0x1a -#define MIIM_CIS8204_ISTAT_STATUS 0x8000 -#define MIIM_CIS8204_ISTAT_SPEED 0x4000 -#define MIIM_CIS8204_ISTAT_LINK 0x2000 -#define MIIM_CIS8204_ISTAT_DUPLEX 0x1000 +#define MII_CIS8201_ISTAT 0x1a +#define MII_CIS8201_ISTAT_STATUS 0x8000 +#define MII_CIS8201_ISTAT_SPEED 0x4000 +#define MII_CIS8201_ISTAT_LINK 0x2000 +#define MII_CIS8201_ISTAT_DUPLEX 0x1000 /* Cicada Auxiliary Control/Status Register */ -#define MIIM_CIS8201_AUX_CONSTAT 0x1c -#define MIIM_CIS8201_AUXCONSTAT_INIT 0x0004 -#define MIIM_CIS8201_AUXCONSTAT_DUPLEX 0x0020 -#define MIIM_CIS8201_AUXCONSTAT_SPEED 0x0018 -#define MIIM_CIS8201_AUXCONSTAT_GBIT 0x0010 -#define MIIM_CIS8201_AUXCONSTAT_100 0x0008 +#define MII_CIS8201_AUX_CONSTAT 0x1c +#define MII_CIS8201_AUXCONSTAT_INIT 0x0004 +#define MII_CIS8201_AUXCONSTAT_DUPLEX 0x0020 +#define MII_CIS8201_AUXCONSTAT_SPEED 0x0018 +#define MII_CIS8201_AUXCONSTAT_GBIT 0x0010 +#define MII_CIS8201_AUXCONSTAT_100 0x0008 /* 88E1011 PHY Status Register */ -#define MIIM_88E1011_PHY_STATUS 0x11 -#define MIIM_88E1011_PHYSTAT_SPEED 0xc000 -#define MIIM_88E1011_PHYSTAT_GBIT 0x8000 -#define MIIM_88E1011_PHYSTAT_100 0x4000 -#define MIIM_88E1011_PHYSTAT_DUPLEX 0x2000 -#define MIIM_88E1011_PHYSTAT_LINK 0x0400 - -#define MIIM_88E1011_IEVENT 0x13 -#define MIIM_88E1011_IEVENT_CLEAR 0x0000 - -#define MIIM_88E1011_IMASK 0x12 -#define MIIM_88E1011_IMASK_INIT 0x6400 -#define MIIM_88E1011_IMASK_CLEAR 0x0000 - -/* DM9161 Control register values */ -#define MIIM_DM9161_CR_STOP 0x0400 -#define MIIM_DM9161_CR_RSTAN 0x1200 +#define MII_M1011_PHY_SPEC_STATUS 0x11 +#define MII_M1011_PHY_SPEC_STATUS_1000 0x8000 +#define MII_M1011_PHY_SPEC_STATUS_100 0x4000 +#define MII_M1011_PHY_SPEC_STATUS_SPD_MASK 0xc000 +#define MII_M1011_PHY_SPEC_STATUS_FULLDUPLEX 0x2000 +#define MII_M1011_PHY_SPEC_STATUS_RESOLVED 0x0800 +#define MII_M1011_PHY_SPEC_STATUS_LINK 0x0400 + +#define MII_M1011_IEVENT 0x13 +#define MII_M1011_IEVENT_CLEAR 0x0000 + +#define MII_M1011_IMASK 0x12 +#define MII_M1011_IMASK_INIT 0x6400 +#define MII_M1011_IMASK_CLEAR 0x0000 -#define MIIM_DM9161_SCR 0x10 -#define MIIM_DM9161_SCR_INIT 0x0610 +#define MII_DM9161_SCR 0x10 +#define MII_DM9161_SCR_INIT 0x0610 /* DM9161 Specified Configuration and Status Register */ -#define MIIM_DM9161_SCSR 0x11 -#define MIIM_DM9161_SCSR_100F 0x8000 -#define MIIM_DM9161_SCSR_100H 0x4000 -#define MIIM_DM9161_SCSR_10F 0x2000 -#define MIIM_DM9161_SCSR_10H 0x1000 +#define MII_DM9161_SCSR 0x11 +#define MII_DM9161_SCSR_100F 0x8000 +#define MII_DM9161_SCSR_100H 0x4000 +#define MII_DM9161_SCSR_10F 0x2000 +#define MII_DM9161_SCSR_10H 0x1000 /* DM9161 Interrupt Register */ -#define MIIM_DM9161_INTR 0x15 -#define MIIM_DM9161_INTR_PEND 0x8000 -#define MIIM_DM9161_INTR_DPLX_MASK 0x0800 -#define MIIM_DM9161_INTR_SPD_MASK 0x0400 -#define MIIM_DM9161_INTR_LINK_MASK 0x0200 -#define MIIM_DM9161_INTR_MASK 0x0100 -#define MIIM_DM9161_INTR_DPLX_CHANGE 0x0010 -#define MIIM_DM9161_INTR_SPD_CHANGE 0x0008 -#define MIIM_DM9161_INTR_LINK_CHANGE 0x0004 -#define MIIM_DM9161_INTR_INIT 0x0000 -#define MIIM_DM9161_INTR_STOP \ -(MIIM_DM9161_INTR_DPLX_MASK | MIIM_DM9161_INTR_SPD_MASK \ - | MIIM_DM9161_INTR_LINK_MASK | MIIM_DM9161_INTR_MASK) +#define MII_DM9161_INTR 0x15 +#define MII_DM9161_INTR_PEND 0x8000 +#define MII_DM9161_INTR_DPLX_MASK 0x0800 +#define MII_DM9161_INTR_SPD_MASK 0x0400 +#define MII_DM9161_INTR_LINK_MASK 0x0200 +#define MII_DM9161_INTR_MASK 0x0100 +#define MII_DM9161_INTR_DPLX_CHANGE 0x0010 +#define MII_DM9161_INTR_SPD_CHANGE 0x0008 +#define MII_DM9161_INTR_LINK_CHANGE 0x0004 +#define MII_DM9161_INTR_INIT 0x0000 +#define MII_DM9161_INTR_STOP \ +(MII_DM9161_INTR_DPLX_MASK | MII_DM9161_INTR_SPD_MASK \ + | MII_DM9161_INTR_LINK_MASK | MII_DM9161_INTR_MASK) /* DM9161 10BT Configuration/Status */ -#define MIIM_DM9161_10BTCSR 0x12 -#define MIIM_DM9161_10BTCSR_INIT 0x7800 +#define MII_DM9161_10BTCSR 0x12 +#define MII_DM9161_10BTCSR_INIT 0x7800 - -#define MIIM_READ_COMMAND 0x00000001 - -/* - * struct phy_cmd: A command for reading or writing a PHY register - * - * mii_reg: The register to read or write - * - * mii_data: For writes, the value to put in the register. - * A value of -1 indicates this is a read. - * - * funct: A function pointer which is invoked for each command. - * For reads, this function will be passed the value read - * from the PHY, and process it. - * For writes, the result of this function will be written - * to the PHY register - */ -struct phy_cmd { - u32 mii_reg; - u32 mii_data; - u16 (*funct) (u16 mii_reg, struct net_device * dev); +#define MII_BASIC_FEATURES (SUPPORTED_10baseT_Half | \ + SUPPORTED_10baseT_Full | \ + SUPPORTED_100baseT_Half | \ + SUPPORTED_100baseT_Full | \ + SUPPORTED_Autoneg | \ + SUPPORTED_TP | \ + SUPPORTED_MII) + +#define MII_GBIT_FEATURES (MII_BASIC_FEATURES | \ + SUPPORTED_1000baseT_Half | \ + SUPPORTED_1000baseT_Full) + +#define MII_READ_COMMAND 0x00000001 + +#define MII_INTERRUPT_DISABLED 0x0 +#define MII_INTERRUPT_ENABLED 0x1 +/* Taken from mii_if_info and sungem_phy.h */ +struct gfar_mii_info { + /* Information about the PHY type */ + /* And management functions */ + struct phy_info *phyinfo; + + /* forced speed & duplex (no autoneg) + * partner speed & duplex & pause (autoneg) + */ + int speed; + int duplex; + int pause; + + /* The most recently read link state */ + int link; + + /* Enabled Interrupts */ + u32 interrupts; + + u32 advertising; + int autoneg; + int mii_id; + + /* private data pointer */ + /* For use by PHYs to maintain extra state */ + void *priv; + + /* Provided by host chip */ + struct net_device *dev; + int (*mdio_read) (struct net_device *dev, int mii_id, int reg); + void (*mdio_write) (struct net_device *dev, int mii_id, int reg, int val); }; /* struct phy_info: a structure which defines attributes for a PHY @@ -155,38 +158,48 @@ * id will contain a number which represents the PHY. During * startup, the driver will poll the PHY to find out what its * UID--as defined by registers 2 and 3--is. The 32-bit result - * gotten from the PHY will be shifted right by "shift" bits to + * gotten from the PHY will be ANDed with phy_id_mask to * discard any bits which may change based on revision numbers * unimportant to functionality * - * The struct phy_cmd entries represent pointers to an arrays of - * commands which tell the driver what to do to the PHY. + * There are 6 commands which take a gfar_mii_info structure. + * Each PHY must declare config_aneg, and read_status. */ struct phy_info { - u32 id; - char *name; - unsigned int shift; - /* Called to configure the PHY, and modify the controller - * based on the results */ - const struct phy_cmd *config; - - /* Called when starting up the controller. Usually sets - * up the interrupt for state changes */ - const struct phy_cmd *startup; - - /* Called inside the interrupt handler to acknowledge - * the interrupt */ - const struct phy_cmd *ack_int; - - /* Called in the bottom half to handle the interrupt */ - const struct phy_cmd *handle_int; - - /* Called when bringing down the controller. Usually stops - * the interrupts from being generated */ - const struct phy_cmd *shutdown; + u32 phy_id; + char *name; + unsigned int phy_id_mask; + u32 features; + + /* Called to initialize the PHY */ + int (*init)(struct gfar_mii_info *mii_info); + + /* Called to suspend the PHY for power */ + int (*suspend)(struct gfar_mii_info *mii_info); + + /* Reconfigures autonegotiation (or disables it) */ + int (*config_aneg)(struct gfar_mii_info *mii_info); + + /* Determines the negotiated speed and duplex */ + int (*read_status)(struct gfar_mii_info *mii_info); + + /* Clears any pending interrupts */ + int (*ack_interrupt)(struct gfar_mii_info *mii_info); + + /* Enables or disables interrupts */ + int (*config_intr)(struct gfar_mii_info *mii_info); + + /* Clears up any memory if needed */ + void (*close)(struct gfar_mii_info *mii_info); }; -struct phy_info *get_phy_info(struct net_device *dev); -void phy_run_commands(struct net_device *dev, const struct phy_cmd *cmd); +struct phy_info *get_phy_info(struct gfar_mii_info *mii_info); +int read_phy_reg(struct net_device *dev, int mii_id, int regnum); +void write_phy_reg(struct net_device *dev, int mii_id, int regnum, int value); + +struct dm9161_private { + struct timer_list timer; + int resetdone; +}; #endif /* GIANFAR_PHY_H */ diff -Nru a/include/linux/mii.h b/include/linux/mii.h --- a/include/linux/mii.h Wed Jul 21 12:37:04 2004 +++ b/include/linux/mii.h Wed Jul 21 12:37:04 2004 @@ -33,7 +33,8 @@ #define MII_NCONFIG 0x1c /* Network interface config */ /* Basic mode control register. */ -#define BMCR_RESV 0x007f /* Unused... */ +#define BMCR_RESV 0x003f /* Unused... */ +#define BMCR_SPEED1000 0x0040 /* MSB of Speed (1000) */ #define BMCR_CTST 0x0080 /* Collision test */ #define BMCR_FULLDPLX 0x0100 /* Full duplex */ #define BMCR_ANRESTART 0x0200 /* Auto negotiation restart */ --Apple-Mail-2-463122003-- From SRS0+f09ec8d37566da824300+332+infradead.org+dwmw2@pentafluge.srs.infradead.org Wed Jul 21 13:15:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 13:15:26 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LKFKtm009233 for ; Wed, 21 Jul 2004 13:15:21 -0700 Received: from ip47-168.ott.istop.com ([66.11.168.47] helo=[192.168.91.196]) by pentafluge.infradead.org with asmtp (Exim 4.33 #1 (Red Hat Linux)) id 1BnNUc-0000YB-W8; Wed, 21 Jul 2004 21:15:11 +0100 Subject: Re: [RFR] gianfar ethernet driver From: David Woodhouse To: Andy Fleming Cc: Jeff Garzik , Andy Fleming , netdev@oss.sgi.com, Kumar Gala , jamal In-Reply-To: <51120A19-DB4F-11D8-A2B5-000393C30512@freescale.com> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <1089170282.1038.80.camel@jzny.localdomain> <20040707032913.GA1822@havoc.gtf.org> <51120A19-DB4F-11D8-A2B5-000393C30512@freescale.com> Content-Type: text/plain Date: Wed, 21 Jul 2004 16:14:08 -0400 Message-Id: <1090440848.4134.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.8 (1.5.8-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7064 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 213 Lines: 9 On Wed, 2004-07-21 at 14:51 -0500, Andy Fleming wrote: > Ok, here's the new patch to apply on top of the old patch. Thanks. Will test when I get back from OLS and add the BCM5421S PHY support again. -- dwmw2 From davem@redhat.com Wed Jul 21 13:50:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 13:50:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LKo6u2009973 for ; Wed, 21 Jul 2004 13:50:09 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6LKo2e1001103; Wed, 21 Jul 2004 16:50:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6LKo1a25567; Wed, 21 Jul 2004 16:50:01 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6LKnO6X013961; Wed, 21 Jul 2004 16:49:24 -0400 Date: Wed, 21 Jul 2004 13:45:57 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] netem -- Message-Id: <20040721134557.7c0a4a8d.davem@redhat.com> In-Reply-To: <20040713151959.2470a211@dell_ss3.pdx.osdl.net> References: <20040712101500.4a0babd3@dell_ss3.pdx.osdl.net> <20040713151959.2470a211@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7065 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 222 Lines: 6 All 3 netem patches applied to 2.6.x, thanks Stephen. The 2.4.x copy of this thing is falling behind the 2.6.x code. By diffing the two you can see what is missing, the randomization jitter feature is the biggest part. From davem@redhat.com Wed Jul 21 13:50:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 13:50:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LKolEp010076 for ; Wed, 21 Jul 2004 13:50:47 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6LKobe1001214; Wed, 21 Jul 2004 16:50:37 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6LKoba25832; Wed, 21 Jul 2004 16:50:37 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6LKnxWO014440; Wed, 21 Jul 2004 16:50:00 -0400 Date: Wed, 21 Jul 2004 13:46:33 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: coreteam@netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] bad initializer in ipv6 netfilter. Message-Id: <20040721134633.5a495df7.davem@redhat.com> In-Reply-To: <20040712150341.44a84ff6@dell_ss3.pdx.osdl.net> References: <20040712150341.44a84ff6@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7066 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 267 Lines: 9 On Mon, 12 Jul 2004 15:03:41 -0700 Stephen Hemminger wrote: > Missing equal sign in C99 initializer. > > Signed-off-by: Stephen Hemminger Viro pushed a fix for this into the tree before I got a chance to apply yours :-) From davem@redhat.com Wed Jul 21 13:51:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 13:51:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LKpcUQ010332 for ; Wed, 21 Jul 2004 13:51:38 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6LKpYe1001441; Wed, 21 Jul 2004 16:51:34 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6LKpXa26141; Wed, 21 Jul 2004 16:51:33 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6LKousP014974; Wed, 21 Jul 2004 16:50:57 -0400 Date: Wed, 21 Jul 2004 13:47:30 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [sparse] missing annotation in ipv6 addrconf Message-Id: <20040721134730.6fa3480d.davem@redhat.com> In-Reply-To: <20040712150444.0396b23e@dell_ss3.pdx.osdl.net> References: <20040712150444.0396b23e@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7067 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 222 Lines: 8 On Mon, 12 Jul 2004 15:04:44 -0700 Stephen Hemminger wrote: > Missing __user annotation in simulated ioctl call. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From davem@redhat.com Wed Jul 21 14:36:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 14:36:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LLa1LV012573 for ; Wed, 21 Jul 2004 14:36:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6LLZMe1010808; Wed, 21 Jul 2004 17:35:22 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6LLZHa06199; Wed, 21 Jul 2004 17:35:22 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6LLYbJs015737; Wed, 21 Jul 2004 17:34:38 -0400 Date: Wed, 21 Jul 2004 14:31:10 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040721143110.4ab944bf.davem@redhat.com> In-Reply-To: <40F4AC8B.40706@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7068 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 922 Lines: 23 On Wed, 14 Jul 2004 05:46:19 +0200 Patrick McHardy wrote: > This one actually compiles ;). The assembler of PSCHED_GET_TIME is > exactly the same on x86. There are 10 architectures that return > something non-zero for get_cycles(), but I have no idea if it is > suitable on all of them. Patch applies on top of the dead-code > removal patch. This looks great. As you mention some platforms return zero, for example sparc32, for get_cycles(). I suggest we just expand the dependency list for NET_SCH_CLK_TSC to include SPARC64 PPC64 and perhaps some other easy to verify as having a working get_cycles() implementation. I believe that as long as it increments at some rate >= jiffies, the psched calibration will get things into a working state. A lot of patches have been posted in this area and I'm losing track of what to apply first etc. Can you repost your work one change at a time? Thanks. From davem@redhat.com Wed Jul 21 15:02:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 15:02:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LM2W1V013792 for ; Wed, 21 Jul 2004 15:02:33 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6LM2Je1016031; Wed, 21 Jul 2004 18:02:20 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6LM2Ja13428; Wed, 21 Jul 2004 18:02:19 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6LM1gEq032154; Wed, 21 Jul 2004 18:01:42 -0400 Date: Wed, 21 Jul 2004 14:58:15 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: [CRYPTO] Fix stack overrun in crypt() Message-Id: <20040721145815.307c5e39.davem@redhat.com> In-Reply-To: <20040715114840.GA1325@gondor.apana.org.au> References: <20040715114840.GA1325@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7069 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 722 Lines: 20 On Thu, 15 Jul 2004 21:48:40 +1000 Herbert Xu wrote: > The stack allocation in crypt() is bogus as whether tmp_src/tmp_dst > is used is determined by factors unrelated to nbytes and > src->length/dst->length. > > Since the condition for whether tmp_src/tmp_dst are used is very > complex, let's allocate them always instead of guessing. > > This fixes a number of weird crashes including those AES crashes > that people have been seeing with the 2.4 backport + ipt_conntrack. Applied, thanks Herbert. > PS I think someone should double-check the logic in the scatterwalk > stuff, especially the whichbuf bits. I've looked at this before, when it went in, but I'll double- check it now. From davem@redhat.com Wed Jul 21 15:06:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 15:06:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LM6VjD014144 for ; Wed, 21 Jul 2004 15:06:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6LM6Oe1016828; Wed, 21 Jul 2004 18:06:24 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6LM6Oa14366; Wed, 21 Jul 2004 18:06:24 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6LM5k9J002389; Wed, 21 Jul 2004 18:05:47 -0400 Date: Wed, 21 Jul 2004 15:02:19 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: [CRYPTO] Fix stack overrun in crypt() Message-Id: <20040721150219.18b7b1f9.davem@redhat.com> In-Reply-To: <20040715114840.GA1325@gondor.apana.org.au> References: <20040715114840.GA1325@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7070 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 774 Lines: 23 On Thu, 15 Jul 2004 21:48:40 +1000 Herbert Xu wrote: > PS I think someone should double-check the logic in the scatterwalk > stuff, especially the whichbuf bits. The goal of scatterwalk_whichbuf() is to use the temporary buffer if we are walking over a page boundary. We can use walk->data, and thus directly the page involved, if we do not cross such a boundary. The test is that all of the following conditions pass: 1) nbytes is <= walk->len_this_page When scatterwalk_start() is invoked, walk->len_this_page is set to the minimum of the remaining scatterlist segment length and the remaining bytes in that page itself. 2) walk->data + nbytes does not straddle a PAGE_CACHE_SIZE boundary This looks all fine to me. From davem@redhat.com Wed Jul 21 16:19:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 16:19:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6LNJaLi019264 for ; Wed, 21 Jul 2004 16:19:39 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6LNJQe1029770; Wed, 21 Jul 2004 19:19:26 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6LNJPa32279; Wed, 21 Jul 2004 19:19:25 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6LNImpU014006; Wed, 21 Jul 2004 19:18:49 -0400 Date: Wed, 21 Jul 2004 16:15:20 -0700 From: "David S. Miller" To: "chas williams (contractor)" Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: [PATCH] br2684 - use try_module_get appropriately Message-Id: <20040721161520.39541ccd.davem@redhat.com> In-Reply-To: <200407192136.i6JLa4QO028602@ginger.cmf.nrl.navy.mil> References: <20040628093317.218220fe@dell_ss3.pdx.osdl.net> <200407192136.i6JLa4QO028602@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7071 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 307 Lines: 10 On Mon, 19 Jul 2004 17:36:05 -0400 "chas williams (contractor)" wrote: > In message <20040628093317.218220fe@dell_ss3.pdx.osdl.net>,Stephen Hemminger wr > ites: > >Either way, just an (void) try_module_get() is WRONG. > > dave, please apply to 2.6 --thanks Applied, thanks guys. From master@tentacle.sectorb.msk.ru Wed Jul 21 22:45:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jul 2004 22:45:32 -0700 (PDT) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6M5jPH9029556 for ; Wed, 21 Jul 2004 22:45:26 -0700 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 742522FE8; Thu, 22 Jul 2004 09:45:22 +0400 (MSD) Date: Thu, 22 Jul 2004 09:45:22 +0400 From: "Vladimir B. Savkin" To: Francois Romieu , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: r8169 in 2.6.7: transfer stops after few seconds Message-ID: <20040722054522.GA17080@tentacle.sectorb.msk.ru> References: <20040721083406.GA5785@usr.lcm.msu.ru> <20040721125622.A31273@electric-eye.fr.zoreil.com> <20040721114750.GA7668@tentacle.sectorb.msk.ru> <20040721201051.A3513@electric-eye.fr.zoreil.com> <20040721205223.B3513@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040721205223.B3513@electric-eye.fr.zoreil.com> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.26 User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 7072 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev Content-Length: 401 Lines: 16 On Wed, Jul 21, 2004 at 08:52:23PM +0200, Francois Romieu wrote: > Francois Romieu : > [...] > > Can you try a non 2.95.x kernel ? > ^^^^^^ -> compiler Recompiling with gcc-3.3 made this problem go away. > -- > Ueimor > ~ :wq With best regards, Vladimir Savkin. From margitsw@t-online.de Thu Jul 22 01:35:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 01:35:40 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6M8ZRYg004958 for ; Thu, 22 Jul 2004 01:35:27 -0700 Received: from fwd11.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1BnZ2o-0005BI-09; Thu, 22 Jul 2004 10:35:14 +0200 Received: from roglap.local (VOsBfwZQgea6YwTM7OIerlmXButaIVZsLGijSX6gWVF2X+hi2pcrwL@[80.128.220.217]) by fwd11.sul.t-online.com with esmtp id 1BnZ2f-0PKhMG0; Thu, 22 Jul 2004 10:35:05 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Fix initialization with older firmware Date: Thu, 22 Jul 2004 10:27:32 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_0p3/AQCrJ6m8A6H" Message-Id: <200407221027.33023.margitsw@t-online.de> X-ID: VOsBfwZQgea6YwTM7OIerlmXButaIVZsLGijSX6gWVF2X+hi2pcrwL X-archive-position: 7073 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 1335 Lines: 45 --Boundary-00=_0p3/AQCrJ6m8A6H Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-22 Margit Schubert-While * In the card initialization routine, we try to set the output power. For firmware < 1.0.4.3, this leads to a worrying "mgt_commit has failed .." in the log although the device continues to react normally. Fix is simple, do not try to configure output power. (which I believe we should not be doing anyway as it is probably against local country regulations) Margit --Boundary-00=_0p3/AQCrJ6m8A6H Content-Type: text/x-diff; charset="us-ascii"; name="outputpow.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="outputpow.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.8-04/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c 2004-07-15 17:21:42.000000000 +0200 +++ linux-2.6.8-04/drivers/net/wireless/prism54/oid_mgt.c 2004-07-22 09:50:20.000000000 +0200 @@ -613,7 +613,9 @@ DOT11_OID_DEFKEYID, DOT11_OID_DOT1XENABLE, OID_INL_DOT11D_CONFORMANCE, + /* Do not initialize this - fw < 1.0.4.3 rejects it OID_INL_OUTPUTPOWER, + */ }; /* update the MAC addr. */ --Boundary-00=_0p3/AQCrJ6m8A6H-- From Bernd.Schubert@tc.pci.uni-heidelberg.de Thu Jul 22 02:01:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 02:01:57 -0700 (PDT) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6M91VI2005874 for ; Thu, 22 Jul 2004 02:01:32 -0700 Received: from euklid.pci.uni-heidelberg.de (euklid.pci.uni-heidelberg.de [129.206.21.104]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i6M91JIY011789; Thu, 22 Jul 2004 11:01:20 +0200 (MET DST) Received: from bernd by euklid.pci.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1BnZS3-0002fX-00; Thu, 22 Jul 2004 11:01:19 +0200 From: Bernd Schubert To: Christoph Hellwig Subject: 2.6.7 oops, sk98lin related? Date: Thu, 22 Jul 2004 11:01:14 +0200 User-Agent: KMail/1.6.2 Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200407221101.16388.bernd-schubert@web.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6M91VI2005874 X-archive-position: 7074 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd-schubert@web.de Precedence: bulk X-list: netdev Content-Length: 1730 Lines: 59 Hello Christoph and all others, is this an sk98lin oops, maybe related to your patches or is it a completely different problem? dsmc: page allocation failure. order:2, mode:0x20 [] dump_stack+0x1e/0x20 [] __alloc_pages+0x2bb/0x330 [] __get_free_pages+0x27/0x40 [] kmem_getpages+0x20/0xd0 [] cache_grow+0xd3/0x290 [] cache_alloc_refill+0x1a0/0x270 [] __kmalloc+0x83/0x90 [] alloc_skb+0x48/0xf0 [] FillRxDescriptor+0x2b/0xc0 [sk98lin] [] FillRxRing+0x6c/0x80 [sk98lin] [] SkDrvEvent+0xb12/0xb70 [sk98lin] [] SkEventDispatcher+0xc5/0x160 [sk98lin] [] SkGeIsrOnePort+0x118/0x1f0 [sk98lin] [] handle_IRQ_event+0x3b/0x70 [] do_IRQ+0xbb/0x1a0 [] common_interrupt+0x18/0x20 [] shrink_zone+0xa5/0xe0 [] shrink_caches+0x6c/0x70 [] try_to_free_pages+0xa2/0x170 [] __alloc_pages+0x1b4/0x330 [] __get_free_pages+0x27/0x40 [] __pollwait+0x76/0xb0 [] tcp_poll+0x36/0x180 [] sock_poll+0x29/0x30 [] do_select+0x237/0x2b0 [] sys_select+0x290/0x480 [] syscall_call+0x7/0xb I have another 190KB of traces uploaded (http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/oopses/minicom.log). All kernel bootup messages are at the end this file as well. Yesterday Marvell Yukon announced a new sk98lin driver, should I try this version? Thanks a lot in advance, Bernd -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg e-mail: bernd.schubert@pci.uni-heidelberg.de From mcgrof@studorgs.rutgers.edu Thu Jul 22 03:42:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 03:43:07 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MAgqN6009803 for ; Thu, 22 Jul 2004 03:42:52 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 82E79F9D4D; Thu, 22 Jul 2004 06:42:49 -0400 (EDT) Date: Thu, 22 Jul 2004 06:42:49 -0400 To: Margit Schubert-While Cc: jgarzik@pobox.com, netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.8-rc1] prism54 Fix initialization with older firmware Message-ID: <20040722104249.GD9141@ruslug.rutgers.edu> Mail-Followup-To: Margit Schubert-While , jgarzik@pobox.com, netdev@oss.sgi.com, prism54-devel@prism54.org References: <200407221027.33023.margitsw@t-online.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline In-Reply-To: <200407221027.33023.margitsw@t-online.de> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 7075 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1595 Lines: 56 --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 22, 2004 at 10:27:32AM +0200, Margit Schubert-While wrote: > 2004-07-22 Margit Schubert-While >=20 > * In the card initialization routine, we try to set the > output power. For firmware < 1.0.4.3, this leads to a > worrying "mgt_commit has failed .." in the log although > the device continues to react normally. > Fix is simple, do not try to configure output power. > (which I believe we should not be doing anyway as it is=20 > probably against local country regulations) >=20 > Margit Margit, I think we should rather detect the version of the firmware and depending on this decide what to do. A quick test proves you can obtain firmware verion from [OID_INL_VERSION] =3D {0xFF020005, 0, 8, OID_TYPE_RAW}, Then somewhere, union oid_res_t r; char *ver; mgt_get_request(priv, OID_INL_VERSION, 0, NULL, &r); ver =3D (char *) r.ptr; printk(KERN_DEBUG "Version: %s\n", ver); This will either be 1.0.4.3.arm or 1.0.3.0.arm. You can then strcmp and do the right thing. I'd finish this work up but I'm busy with WPA. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/5opat1JN+IKUl4RAoDPAJ9Et3OLSiiOrqAbS1fEYietbCFNXwCfd4PY eWfJM2DRTu2H2lCJBNe0qdQ= =6EcK -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai-- From herbert@gondor.apana.org.au Thu Jul 22 04:34:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 04:35:01 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MBYj0X014914 for ; Thu, 22 Jul 2004 04:34:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BnbqN-0002Ew-00; Thu, 22 Jul 2004 21:34:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BnbqI-0004JC-00; Thu, 22 Jul 2004 21:34:30 +1000 Date: Thu, 22 Jul 2004 21:34:29 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPCOMP6] Fix ICMP type check Message-ID: <20040722113429.GA15083@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7076 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 989 Lines: 34 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: It looks like IPCOMP was missed when the same problem was fixed in AH/ESP. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="1.1806" diff -Nru a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c --- a/net/ipv6/ipcomp6.c 2004-07-16 20:46:17 +10:00 +++ b/net/ipv6/ipcomp6.c 2004-07-16 20:46:17 +10:00 @@ -240,7 +240,7 @@ struct ipv6_comp_hdr *ipcomph = (struct ipv6_comp_hdr*)(skb->data+offset); struct xfrm_state *x; - if (type != ICMPV6_DEST_UNREACH || type != ICMPV6_PKT_TOOBIG) + if (type != ICMPV6_DEST_UNREACH && type != ICMPV6_PKT_TOOBIG) return; spi = ntohl(ntohs(ipcomph->cpi)); --lrZ03NoBR/3+SXJZ-- From herbert@gondor.apana.org.au Thu Jul 22 05:00:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 05:00:52 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MC0ZuV015442 for ; Thu, 22 Jul 2004 05:00:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BncFO-0002Pu-00; Thu, 22 Jul 2004 22:00:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BncFK-0004lb-00; Thu, 22 Jul 2004 22:00:22 +1000 Date: Thu, 22 Jul 2004 22:00:21 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [INET] Create enum of ECN bits Message-ID: <20040722120021.GA18293@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7077 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3350 Lines: 125 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch is a preparation for an update of the ECN encap/decap code with respect to RFC3168. It creates an enum of the four code-points defined by RFC3168 and uses them throughout the inet_ecn.h file. The only non-trivial bit is in IP_ECN_set_ce/IP6_ECN_set_ce where the patch uses INET_ECN_CE instead of 1. This is OK as those functions assume that the ECT bit is already set. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff -Nru a/include/net/inet_ecn.h b/include/net/inet_ecn.h --- a/include/net/inet_ecn.h 2004-07-22 21:35:12 +10:00 +++ b/include/net/inet_ecn.h 2004-07-22 21:35:12 +10:00 @@ -3,39 +3,48 @@ #include +enum { + INET_ECN_NOT_ECT = 0, + INET_ECN_ECT_1 = 1, + INET_ECN_ECT_0 = 2, + INET_ECN_CE = 3, + INET_ECN_MASK = 3, +}; + static inline int INET_ECN_is_ce(__u8 dsfield) { - return (dsfield&3) == 3; + return (dsfield & INET_ECN_MASK) == INET_ECN_CE; } static inline int INET_ECN_is_not_ce(__u8 dsfield) { - return (dsfield&3) == 2; + return (dsfield & INET_ECN_MASK) == INET_ECN_ECT_0; } static inline int INET_ECN_is_capable(__u8 dsfield) { - return (dsfield&2); + return (dsfield & INET_ECN_ECT_0); } static inline __u8 INET_ECN_encapsulate(__u8 outer, __u8 inner) { - outer &= ~3; + outer &= ~INET_ECN_MASK; if (INET_ECN_is_capable(inner)) - outer |= (inner & 3); + outer |= (inner & INET_ECN_MASK); return outer; } -#define INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= 2; } while (0) -#define INET_ECN_dontxmit(sk) do { inet_sk(sk)->tos &= ~3; } while (0) +#define INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; } while (0) +#define INET_ECN_dontxmit(sk) \ + do { inet_sk(sk)->tos &= ~INET_ECN_MASK; } while (0) -#define IP6_ECN_flow_init(label) do { \ - (label) &= ~htonl(3<<20); \ +#define IP6_ECN_flow_init(label) do { \ + (label) &= ~htonl(INET_ECN_MASK << 20); \ } while (0) -#define IP6_ECN_flow_xmit(sk, label) do { \ - if (INET_ECN_is_capable(inet_sk(sk)->tos)) \ - (label) |= __constant_htons(2 << 4); \ +#define IP6_ECN_flow_xmit(sk, label) do { \ + if (INET_ECN_is_capable(inet_sk(sk)->tos)) \ + (label) |= __constant_htons(INET_ECN_ECT_0 << 4); \ } while (0) static inline void IP_ECN_set_ce(struct iphdr *iph) @@ -43,24 +52,24 @@ u32 check = iph->check; check += __constant_htons(0xFFFE); iph->check = check + (check>=0xFFFF); - iph->tos |= 1; + iph->tos |= INET_ECN_CE; } static inline void IP_ECN_clear(struct iphdr *iph) { - iph->tos &= ~3; + iph->tos &= ~INET_ECN_MASK; } struct ipv6hdr; static inline void IP6_ECN_set_ce(struct ipv6hdr *iph) { - *(u32*)iph |= htonl(1<<20); + *(u32*)iph |= htonl(INET_ECN_CE << 20); } static inline void IP6_ECN_clear(struct ipv6hdr *iph) { - *(u32*)iph &= ~htonl(3<<20); + *(u32*)iph &= ~htonl(INET_ECN_MASK << 20); } #define ip6_get_dsfield(iph) ((ntohs(*(u16*)(iph)) >> 4) & 0xFF) --2fHTh5uZTiUOsy+g-- From uucp@ganesha.gnumonks.org Thu Jul 22 06:29:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 06:29:34 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MDTR29018452 for ; Thu, 22 Jul 2004 06:29:28 -0700 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.30) id 1BnddS-00087k-Ft for netdev@oss.sgi.com; Thu, 22 Jul 2004 15:29:22 +0200 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1BnO0Z-0004Z5-00; Wed, 21 Jul 2004 16:48:11 -0400 Date: Wed, 21 Jul 2004 16:48:11 -0400 From: Harald Welte To: Christoph Hellwig Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] more DECLARE_MUTEX() in headers crap Message-ID: <20040721204811.GO27487@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , Christoph Hellwig , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org References: <20040620112328.GB13691@lst.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jITzwD3HDGXid3BE" Content-Disposition: inline In-Reply-To: <20040620112328.GB13691@lst.de> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.8-rc1-qs X-Date: Today is Setting Orange, the 54th day of Confusion in the YOLD 3170 User-Agent: Mutt/1.5.6+20040523i X-archive-position: 7078 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1386 Lines: 39 --jITzwD3HDGXid3BE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 20, 2004 at 01:23:28PM +0200, Christoph Hellwig wrote: > okay, the gunk we had in arp_tables is in ip6_tables and ip6_tables, > too. In fact those three files see to be 80% copy & paste of each > other.. yes, we wrote ip_tables.c, and people did copy+paste ports. Work is being done on generalization and unification. I'll push your patch uptream. --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --jITzwD3HDGXid3BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/taLXaXGVTD0i/8RAovmAJ9m7/jU+E342vfzmq0ko8SBM8+ewwCeIRt0 Xd1F8mmNnBuF0NbzKzD38tg= =hhd/ -----END PGP SIGNATURE----- --jITzwD3HDGXid3BE-- From jmorris@redhat.com Thu Jul 22 07:26:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 07:26:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MEQDVx020066 for ; Thu, 22 Jul 2004 07:26:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6MEQ3e1022296; Thu, 22 Jul 2004 10:26:03 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6MEQ2a02127; Thu, 22 Jul 2004 10:26:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6MEQ1Li026877; Thu, 22 Jul 2004 10:26:02 -0400 Date: Thu, 22 Jul 2004 10:25:24 -0400 (EDT) From: James Morris X-X-Sender: jmorris@devserv.devel.redhat.com To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [IPCOMP6] Fix ICMP type check In-Reply-To: <20040722113429.GA15083@gondor.apana.org.au> Message-ID: References: <20040722113429.GA15083@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7079 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 231 Lines: 14 On Thu, 22 Jul 2004, Herbert Xu wrote: > Hi Dave: > > It looks like IPCOMP was missed when the same problem was fixed in AH/ESP. What about esp4/ah4/ipcomp? They look wrong too. - James -- James Morris From ceder@ingate.com Thu Jul 22 08:00:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 08:01:01 -0700 (PDT) Received: from usagi.ingate.se (IDENT:PfP5c0mqw1RCoSvNdsSRiTwE6hEvwPkF@usagi.ingate.se [193.180.23.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MF0qnw020699 for ; Thu, 22 Jul 2004 08:00:53 -0700 Received: from plebeian.ingate.se (IDENT:xlR111aBuM51uDGFpdEwrumT1PtzzQ6R@plebeian.ingate.se [193.180.23.113]) by usagi.ingate.se (8.12.8/8.11.6) with ESMTP id i6MF0gTx030589; Thu, 22 Jul 2004 17:00:42 +0200 Received: from plebeian.ingate.se (IDENT:PUgu7pu4oU+5Q1xGKg+YRKin3ZjVbzQ9@localhost.localdomain [127.0.0.1]) by plebeian.ingate.se (8.12.8/8.11.6) with ESMTP id i6MF0gE9011206; Thu, 22 Jul 2004 17:00:42 +0200 Received: (from ceder@localhost) by plebeian.ingate.se (8.12.8/8.12.8/Submit) id i6MF0gpJ011202; Thu, 22 Jul 2004 17:00:42 +0200 X-Authentication-Warning: plebeian.ingate.se: ceder set sender to ceder@ingate.com using -f To: netdev@oss.sgi.com Subject: PROBLEM: ICMP redirect that violates RFC 1812 is sent From: Per Cederqvist Date: 22 Jul 2004 17:00:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7080 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ceder@ingate.com Precedence: bulk X-list: netdev Content-Length: 5184 Lines: 143 [1.] One line summary of the problem: ICMP redirect that violates RFC 1812 is sent [2.] Full description of the problem/report: RFC 1812, "Requirements for IP Version 4 Routers", states when ICMP redirects should be sent (quoted from "5.2.7.2 Redirect"): > Routers MUST NOT generate a Redirect Message unless all the following > conditions are met: > > o The packet is being forwarded out the same physical interface that > it was received from, > > o The IP source address in the packet is on the same Logical IP > (sub)network as the next-hop IP address, and > > o The packet does not contain an IP source route option. Linux 2.4.27 fails to check the middle condition. I've looked at the source code of Linux 2.6.7, and the problem seems to still be there. There are two problems: Problem 1 (less important): bad default value of shared_media The default value of /proc/sys/net/ipv4/conf/*/shared_media is TRUE. It should be FALSE for RFC 1812 compliance. When it is TRUE, the middle condition is intentionally not checked. There may be later standards work that I'm not aware of that makes this a valid default. I've tried to locate such work, but failed. RFC 1620 ("Internet Architecture Extensions for Shared Media") suggests that this change could be made, but it is just an informational RFC. Problem 2 (more important): bug in route.c Even when shared_media is FALSE, the middle condition fails, due to a bug in route.c. Consider this code: if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && (IN_DEV_SHARED_MEDIA(out_dev) || inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) flags |= RTCF_DOREDIRECT; If the next-hop IP address is on a different logical IP network, but it still is on a network that is directly connected to the Linux box, FIB_RES_GW(res) will return 0. inet_addr_onlink() will always return true in that case. This means that RTFC_DOREDIRECT will be set, and a standards-violating ICMP Redirect will be sent. The enclosed patch changes the final argument of inet_addr_onlink() to: FIB_RES_GW(res) ? FIB_RES_GW(res) : daddr [3.] Keywords (i.e., modules, networking, kernel): networking, icmp, redirect, non-compliant, RFC 1812 [4.] Kernel version (from /proc/version): 2.4.27. Problem initially found on 2.4.26. http://seclists.org/lists/linux-kernel/2000/Oct/0923.html indicates that this bug was present in 2.2.17 as well. Inspection of the 2.6.7 kernel indicates that it isn't fixed there either. [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) [6.] A small shell script or example program which triggers the problem (if possible) To trigger this, you need two linux boxes. On the box acting as router (it only needs one ethernet interface), do: ifconfig eth0 down ifconfig eth0 192.168.10.1 netmask 255.255.255.0 ifconfig eth0:1 192.168.99.1 netmask 255.255.255.0 echo 1 > /proc/sys/net/ipv4/ip_forward for f in /proc/sys/net/ipv4/conf/*/shared_media do echo 0 > $f done On the other box, start a sniffer such as ethereal, and do: ifconfig eth0 down ifconfig eth0 192.168.10.2 netmask 255.255.255.0 ping 192.168.99.2 You will see ICMP redirect packets similar to these: > Frame 257 (242 bytes on wire, 242 bytes captured) > Ethernet II, Src: 00:20:fc:1e:cc:c4, Dst: 00:03:e3:11:f4:31 > Internet Protocol, Src Addr: 192.168.10.1 (192.168.10.1), Dst Addr: 192.168.10.2 (192.168.10.2) > Internet Control Message Protocol > Type: 5 (Redirect) > Code: 1 (Redirect for host) > Checksum: 0x252b (correct) > Gateway address: 192.168.99.2 (192.168.99.2) > [...] [X.] Other notes, patches, fixes, workarounds: Acknowledgement: Mario Lorenz (ml_at_vdazone.org) reported this problem back in 2000, with a patch. However, unfortunately apparently nobody believed him. See http://seclists.org/lists/linux-kernel/2000/Oct/0923.html. I've taken his patch, updated it for 2.4.17, and tested it. As far as I can tell, it works. Here is the patch: # This patch fixes a bug that caused Linux to send ICMP redirect # when hosts on two directly connected networks attempted to talk # to each other. In that case, FIB_RES_GW(res) will be 0.0.0.0, and # inet_addr_onlink will always return true. # # The patch was originally found on # http://seclists.org/lists/linux-kernel/2000/Oct/0923.html and is # written by Mario Lorenz (ml_at_vdazone.org) for Linux 2.2.17. It # was updated for Linux 2.4.27 by ceder@ingate.com on 2004-07-21. # --- linux-2.4.27/net/ipv4/route.c.orig Fri Oct 6 13:41:50 2000 +++ linux-2.4.27/net/ipv4/route.c Fri Oct 6 15:12:25 2000 @@ -1524,7 +1524,8 @@ if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && (IN_DEV_SHARED_MEDIA(out_dev) || - inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) + inet_addr_onlink(out_dev, saddr, + FIB_RES_GW(res) ? FIB_RES_GW(res) : daddr))) flags |= RTCF_DOREDIRECT; if (skb->protocol != htons(ETH_P_IP)) { Yours, /ceder -- Per Cederqvist , Chief Architect, Ingate Systems AB From SRS0+ae7d5470440d69fb33b0+333+infradead.org+hch@pentafluge.srs.infradead.org Thu Jul 22 08:03:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 08:03:27 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MF3HsX021007 for ; Thu, 22 Jul 2004 08:03:18 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1Bnf6I-0003WL-4T; Thu, 22 Jul 2004 16:03:14 +0100 Date: Thu, 22 Jul 2004 16:03:14 +0100 From: Christoph Hellwig To: Bernd Schubert Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.7 oops, sk98lin related? Message-ID: <20040722150314.GB13195@infradead.org> Mail-Followup-To: Christoph Hellwig , Bernd Schubert , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <200407221101.16388.bernd-schubert@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407221101.16388.bernd-schubert@web.de> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7081 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 363 Lines: 11 On Thu, Jul 22, 2004 at 11:01:14AM +0200, Bernd Schubert wrote: > Hello Christoph and all others, > > is this an sk98lin oops, maybe related to your patches or is it a completely > different problem? I don't think there's skge patches from me in 2.6.7 yet, but certainly not in that area ;-) This is just a big memory allocation failing, not an oops anyway. From Bernd.Schubert@tc.pci.uni-heidelberg.de Thu Jul 22 10:09:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 10:09:08 -0700 (PDT) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MH8uRG027784 for ; Thu, 22 Jul 2004 10:08:59 -0700 Received: from euklid.pci.uni-heidelberg.de (euklid.pci.uni-heidelberg.de [129.206.21.104]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i6MH8gIY021292; Thu, 22 Jul 2004 19:08:43 +0200 (MET DST) Received: from bernd by euklid.pci.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1Bnh3i-00030S-00; Thu, 22 Jul 2004 19:08:42 +0200 From: Bernd Schubert To: Christoph Hellwig , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.7 oops, sk98lin related? Date: Thu, 22 Jul 2004 19:08:38 +0200 User-Agent: KMail/1.6.2 References: <200407221101.16388.bernd-schubert@web.de> <20040722150314.GB13195@infradead.org> In-Reply-To: <20040722150314.GB13195@infradead.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200407221908.41468.bernd-schubert@web.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6MH8uRG027784 X-archive-position: 7082 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd-schubert@web.de Precedence: bulk X-list: netdev Content-Length: 941 Lines: 35 > > is this an sk98lin oops, maybe related to your patches or is it a > > completely different problem? > > I don't think there's skge patches from me in 2.6.7 yet, but certainly not > in that area ;-) Well just remember, on 20040704 you send me a 'huge patch' which should also fix our module unload problems. > > This is just a big memory allocation failing, not an oops anyway. Unfortunality I began to capture via serial console only a few hour after the server crashed. As there is also nothing in the logs, I don't have the beginning trace of the problems. Since there is something about sk98 in almost all traces, I thought it might be a sk98lin problem. Anyway, do you have an idea what might have cause this memory allocation problem? Thanks, Bernd -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg e-mail: bernd.schubert@pci.uni-heidelberg.de From shemminger@osdl.org Thu Jul 22 10:29:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 10:30:02 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MHTqZI028457 for ; Thu, 22 Jul 2004 10:29:53 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6MHSj130266; Thu, 22 Jul 2004 10:28:45 -0700 Date: Thu, 22 Jul 2004 10:28:43 -0700 From: Stephen Hemminger To: Jeff Garzik , "David S. Miller" Cc: netdev@oss.sgi.com, Greg KH Subject: pcmcia ether drivers can't be unloaded Message-Id: <20040722102843.1e8f505c@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7083 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 432 Lines: 8 It looks like pcmica modular ether (example orinoco) can never be manually unloaded because module refcount is always 1. This comes from the owner field in the pcmcia_driver.owner being set. One fix is to not set owner field but then there is a hot plug/module remove race. But the right fix seems to fix up pcmcia to be a true bus in the driver model and have the same hotplug as other buses; usb and pci don't have the problem. From davem@redhat.com Thu Jul 22 12:24:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 12:24:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MJOPim001161 for ; Thu, 22 Jul 2004 12:24:26 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6MJOFe1016787; Thu, 22 Jul 2004 15:24:15 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6MJOFa21939; Thu, 22 Jul 2004 15:24:15 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6MJNbUW012821; Thu, 22 Jul 2004 15:23:37 -0400 Date: Thu, 22 Jul 2004 12:19:52 -0700 From: "David S. Miller" To: James Morris Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [IPCOMP6] Fix ICMP type check Message-Id: <20040722121952.407cc9c2.davem@redhat.com> In-Reply-To: References: <20040722113429.GA15083@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7084 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 22 Jul 2004 10:25:24 -0400 (EDT) James Morris wrote: > On Thu, 22 Jul 2004, Herbert Xu wrote: > > > It looks like IPCOMP was missed when the same problem was fixed in > > AH/ESP. > > What about esp4/ah4/ipcomp? They look wrong too. Those are testing something else, and I believe their tests are correct. They are saying: if (type != X || code != Y) return; in these cases Herbert is mentioning it is testing against multiple possible settings of just "type". Herbert, I'll apply your patch, thanks. From davem@redhat.com Thu Jul 22 12:27:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 12:27:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MJR7KJ001446 for ; Thu, 22 Jul 2004 12:27:08 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6MJR1e1017824; Thu, 22 Jul 2004 15:27:01 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6MJR0a23590; Thu, 22 Jul 2004 15:27:00 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6MJQNwg014961; Thu, 22 Jul 2004 15:26:23 -0400 Date: Thu, 22 Jul 2004 12:22:38 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [INET] Create enum of ECN bits Message-Id: <20040722122238.6759b75b.davem@redhat.com> In-Reply-To: <20040722120021.GA18293@gondor.apana.org.au> References: <20040722120021.GA18293@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7085 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 22 Jul 2004 22:00:21 +1000 Herbert Xu wrote: > This patch is a preparation for an update of the ECN encap/decap > code with respect to RFC3168. > > It creates an enum of the four code-points defined by RFC3168 > and uses them throughout the inet_ecn.h file. > > The only non-trivial bit is in IP_ECN_set_ce/IP6_ECN_set_ce where > the patch uses INET_ECN_CE instead of 1. This is OK as those > functions assume that the ECT bit is already set. Looks great, applied. From shemminger@osdl.org Thu Jul 22 13:46:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 13:46:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MKkOEk002890 for ; Thu, 22 Jul 2004 13:46:24 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6MKjb101801; Thu, 22 Jul 2004 13:45:38 -0700 Date: Thu, 22 Jul 2004 13:45:22 -0700 From: Stephen Hemminger To: "David S. Miller" , Jamal Hadi Salim Cc: Arkadiusz Miskiewicz , netdev@oss.sgi.com Subject: [PATCH] pkt_cls.h incompatiables Message-Id: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> In-Reply-To: <200407172357.15832.arekm@pld-linux.org> References: <200407161544.59342.arekm@pld-linux.org> <20040716103759.1928c2ae@dell_ss3.pdx.osdl.net> <200407172357.15832.arekm@pld-linux.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7086 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The recent changes to (6 Jul 04) pkt_cls.h are evil, you can't build a version of 'tc' to work unless you know the kernel config! It has several API problems: - API data structures change on kernel config options - new fields should be added at the end of a structure to allow binary compatibility. This patch tries to clean this up. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h --- a/include/linux/pkt_cls.h 2004-07-22 13:44:04 -07:00 +++ b/include/linux/pkt_cls.h 2004-07-22 13:44:04 -07:00 @@ -117,17 +117,8 @@ struct tc_police { __u32 index; -#ifdef CONFIG_NET_CLS_ACT int refcnt; int bindcnt; -#endif -/* Turned off because it requires new tc - * to work (for now maintain ABI) - * -#ifdef CONFIG_NET_CLS_ACT - __u32 capab; -#endif -*/ int action; #define TC_POLICE_UNSPEC TC_ACT_UNSPEC #define TC_POLICE_OK TC_ACT_OK @@ -195,12 +186,8 @@ TCA_U32_DIVISOR, TCA_U32_SEL, TCA_U32_POLICE, -#ifdef CONFIG_NET_CLS_ACT TCA_U32_ACT, -#endif -#ifdef CONFIG_NET_CLS_IND TCA_U32_INDEV, -#endif __TCA_U32_MAX }; @@ -212,9 +199,7 @@ __u32 val; int off; int offmask; -#ifdef CONFIG_CLS_U32_PERF - unsigned long kcnt; -#endif + __u32 kcnt; }; struct tc_u32_sel @@ -229,11 +214,9 @@ short hoff; __u32 hmask; -#ifdef CONFIG_CLS_U32_PERF + struct tc_u32_key keys[0]; unsigned long rcnt; unsigned long rhit; -#endif - struct tc_u32_key keys[0]; }; /* Flags */ @@ -300,12 +283,8 @@ TCA_FW_UNSPEC, TCA_FW_CLASSID, TCA_FW_POLICE, -#ifdef CONFIG_NET_CLS_IND TCA_FW_INDEV, -#endif -#ifdef CONFIG_NET_CLS_ACT TCA_FW_ACT, -#endif __TCA_FW_MAX }; From davem@redhat.com Thu Jul 22 13:58:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 13:58:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MKwBU8003327 for ; Thu, 22 Jul 2004 13:58:13 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6MKw3e1013625; Thu, 22 Jul 2004 16:58:03 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6MKw3a28157; Thu, 22 Jul 2004 16:58:03 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6MKvPtN007653; Thu, 22 Jul 2004 16:57:26 -0400 Date: Thu, 22 Jul 2004 13:53:39 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: hadi@znyx.com, arekm@pld-linux.org, netdev@oss.sgi.com Subject: Re: [PATCH] pkt_cls.h incompatiables Message-Id: <20040722135339.181321b1.davem@redhat.com> In-Reply-To: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> References: <200407161544.59342.arekm@pld-linux.org> <20040716103759.1928c2ae@dell_ss3.pdx.osdl.net> <200407172357.15832.arekm@pld-linux.org> <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7087 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 22 Jul 2004 13:45:22 -0700 Stephen Hemminger wrote: > The recent changes to (6 Jul 04) pkt_cls.h are evil, you can't build a version > of 'tc' to work unless you know the kernel config! > > It has several API problems: > - API data structures change on kernel config options > - new fields should be added at the end of a structure to allow > binary compatibility. > > This patch tries to clean this up. I totally agree and I've discussed this with Jamal already. We just haven't gotten around to coding up the patch, but now you have :-) I'll apply this, thanks Stephen. From kaber@trash.net Thu Jul 22 16:29:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 16:29:49 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MNTfqR008924 for ; Thu, 22 Jul 2004 16:29:43 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1Bnn3L-0004Yt-00; Fri, 23 Jul 2004 01:32:43 +0200 Message-ID: <41004DBB.5030801@trash.net> Date: Fri, 23 Jul 2004 01:28:59 +0200 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: Balint Marton CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] get_random_bytes returns the same on every boot References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7088 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 Balint Marton wrote: > Hi, > > At boot time, get_random_bytes always returns the same random data, as if > there were a constant random seed. For example, if I use the kernel level > ip autoconfiguration with dhcp, the kernel will create a dhcp request > packet with always the same transaction ID. (If you have more than one > computers, and they are booting at the same time, then this is a big > problem) > > That happens, because only the primary entropy pool is initialized with > the system time, in function rand_initialize. The secondary pool is only > cleared. In this early stage of booting, there is usually no user > interaction, or usable disk interrupts, so the kernel can't add any real > random bytes to the primary pool. And altough the system time is in the > primary pool, the kernel does not consider it real random data, so you > can't read from the primary pool, before at least a part of it will be > filled with some real randomness (interrupt timing). > Therefore all random data will come from the secondary pool, and the > kernel cannot reseed the secondary pool, because there is no real > randomness in the primary one. > > The solution is simple: Initialize not just the primary, but also the > secondary pool with the system time. My patch worked for me with > 2.6.8-rc2, but it was not tested too long. Many network hashes use get_random_bytes() to initialize a secret value to avoid attacks on the hash function when first used. I assume if DHCP can get bad random, they can too. Is this patch enough to prevent get_random_bytes() from returning predictable data at boot time ? Regards Patrick From kaber@trash.net Thu Jul 22 16:37:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 16:37:20 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MNbE7w011011 for ; Thu, 22 Jul 2004 16:37:15 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BnnAc-0004jJ-00; Fri, 23 Jul 2004 01:40:14 +0200 Message-ID: <41004F76.1080807@trash.net> Date: Fri, 23 Jul 2004 01:36:22 +0200 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: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> In-Reply-To: <20040721143110.4ab944bf.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7089 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 David S. Miller wrote: > This looks great. > > As you mention some platforms return zero, for example sparc32, > for get_cycles(). > > I suggest we just expand the dependency list for NET_SCH_CLK_TSC > to include SPARC64 PPC64 and perhaps some other easy to verify > as having a working get_cycles() implementation. I believe that > as long as it increments at some rate >= jiffies, the psched > calibration will get things into a working state. It needs to increment at slightly above 1Mhz, otherwise delay will be zero after this division and everything will fall apart: delay /= rdelay. > A lot of patches have been posted in this area and I'm losing > track of what to apply first etc. Can you repost your work > one change at a time? Thanks. The following two patches remove some dead timer code and change PSCHED_GET_TIME to use get_cycles. I'm going to send the configurable clock-source patch tomorrow after checking the arches. Regards Patrick From kaber@trash.net Thu Jul 22 16:40:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 16:40:57 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MNeqXp011361 for ; Thu, 22 Jul 2004 16:40:52 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BnnEM-0004ou-00; Fri, 23 Jul 2004 01:44:06 +0200 Message-ID: <41005069.3030703@trash.net> Date: Fri, 23 Jul 2004 01:40:25 +0200 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: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH 2.6 1/2]: Remove dead timer code Content-Type: multipart/mixed; boundary="------------090606060601010006000003" X-archive-position: 7090 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------090606060601010006000003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch removes some dead timer code left over from the PSCHED_JIFFIES clock source change to use get_jiffies_64(). --------------090606060601010006000003 Content-Type: application/octect-stream; name="01-psched-dead_code.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="01-psched-dead_code.diff" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2gu CiMKIyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDcvMjIgMDE6Mjk6MjMrMDI6MDAga2FiZXJAdHJh c2gubmV0IAojICAgW1BLVF9TQ0hFRF06IFJlbW92ZSBkZWFkIHRpbWVyIGNvZGUKIyAgIAoj ICAgU2lnbmVkLW9mZi1ieTogUGF0cmljayBNY0hhcmR5IDxrYWJlckB0cmFzaC5uZXQ+CiMg CiMgbmV0L3NjaGVkL3NjaF9hcGkuYwojICAgMjAwNC8wNy8yMiAwMToyOToxMiswMjowMCBr YWJlckB0cmFzaC5uZXQgKzEgLTE0CiMgICBbUEtUX1NDSEVEXTogUmVtb3ZlIGRlYWQgdGlt ZXIgY29kZQojIAojIGluY2x1ZGUvbmV0L3BrdF9zY2hlZC5oCiMgICAyMDA0LzA3LzIyIDAx OjI5OjEyKzAyOjAwIGthYmVyQHRyYXNoLm5ldCArMSAtMgojICAgW1BLVF9TQ0hFRF06IFJl bW92ZSBkZWFkIHRpbWVyIGNvZGUKIyAKZGlmZiAtTnJ1IGEvaW5jbHVkZS9uZXQvcGt0X3Nj aGVkLmggYi9pbmNsdWRlL25ldC9wa3Rfc2NoZWQuaAotLS0gYS9pbmNsdWRlL25ldC9wa3Rf c2NoZWQuaAkyMDA0LTA3LTIyIDIyOjE5OjQzICswMjowMAorKysgYi9pbmNsdWRlL25ldC9w a3Rfc2NoZWQuaAkyMDA0LTA3LTIyIDIyOjE5OjQzICswMjowMApAQCAtMjE2LDggKzIxNiw2 IEBACiB0eXBlZGVmIHU2NAlwc2NoZWRfdGltZV90OwogdHlwZWRlZiBsb25nCXBzY2hlZF90 ZGlmZl90OwogCi1leHRlcm4gcHNjaGVkX3RpbWVfdAlwc2NoZWRfdGltZV9iYXNlOwotCiAj aWYgUFNDSEVEX0NMT0NLX1NPVVJDRSA9PSBQU0NIRURfSklGRklFUwogCiAjaWYgSFogPCA5 NgpAQCAtMjU2LDYgKzI1NCw3IEBACiAKICNkZWZpbmUgUFNDSEVEX1dBVENIRVIgdTMyCiAK K2V4dGVybiBwc2NoZWRfdGltZV90IHBzY2hlZF90aW1lX2Jhc2U7CiBleHRlcm4gUFNDSEVE X1dBVENIRVIgcHNjaGVkX3RpbWVfbWFyazsKIAogI2RlZmluZSBQU0NIRURfR0VUX1RJTUUo c3RhbXApIFwKZGlmZiAtTnJ1IGEvbmV0L3NjaGVkL3NjaF9hcGkuYyBiL25ldC9zY2hlZC9z Y2hfYXBpLmMKLS0tIGEvbmV0L3NjaGVkL3NjaF9hcGkuYwkyMDA0LTA3LTIyIDIyOjE5OjQz ICswMjowMAorKysgYi9uZXQvc2NoZWQvc2NoX2FwaS5jCTIwMDQtMDctMjIgMjI6MTk6NDMg KzAyOjAwCkBAIC0xMTAzLDE2ICsxMTAzLDE0IEBACiBFWFBPUlRfU1lNQk9MKHBzY2hlZF90 b2RfZGlmZik7CiAjZW5kaWYKIAotcHNjaGVkX3RpbWVfdCBwc2NoZWRfdGltZV9iYXNlOwot CiAjaWYgUFNDSEVEX0NMT0NLX1NPVVJDRSA9PSBQU0NIRURfQ1BVCiBwc2NoZWRfdGRpZmZf dCBwc2NoZWRfY2xvY2tfcGVyX2h6OwogaW50IHBzY2hlZF9jbG9ja19zY2FsZTsKIEVYUE9S VF9TWU1CT0wocHNjaGVkX2Nsb2NrX3Blcl9oeik7CiBFWFBPUlRfU1lNQk9MKHBzY2hlZF9j bG9ja19zY2FsZSk7Ci0jZW5kaWYKIAogI2lmZGVmIFBTQ0hFRF9XQVRDSEVSCitwc2NoZWRf dGltZV90IHBzY2hlZF90aW1lX2Jhc2U7CiBQU0NIRURfV0FUQ0hFUiBwc2NoZWRfdGltZV9t YXJrOwogRVhQT1JUX1NZTUJPTChwc2NoZWRfdGltZV9tYXJrKTsKIEVYUE9SVF9TWU1CT0wo cHNjaGVkX3RpbWVfYmFzZSk7CkBAIC0xMTIzLDIyICsxMTIxLDE0IEBACiAKIHN0YXRpYyB2 b2lkIHBzY2hlZF90aWNrKHVuc2lnbmVkIGxvbmcgZHVtbXkpCiB7Ci0jaWYgUFNDSEVEX0NM T0NLX1NPVVJDRSA9PSBQU0NIRURfQ1BVCiAJcHNjaGVkX3RpbWVfdCBkdW1teV9zdGFtcDsK IAlQU0NIRURfR0VUX1RJTUUoZHVtbXlfc3RhbXApOwogCS8qIEl0IGlzIE9LIHVwIHRvIDRH SHogY3B1ICovCiAJcHNjaGVkX3RpbWVyLmV4cGlyZXMgPSBqaWZmaWVzICsgMSpIWjsKLSNl bHNlCi0JdW5zaWduZWQgbG9uZyBub3cgPSBqaWZmaWVzOwotCXBzY2hlZF90aW1lX2Jhc2Ug Kz0gKCh1NjQpKG5vdy1wc2NoZWRfdGltZV9tYXJrKSk8PFBTQ0hFRF9KU0NBTEU7Ci0JcHNj aGVkX3RpbWVfbWFyayA9IG5vdzsKLQlwc2NoZWRfdGltZXIuZXhwaXJlcyA9IG5vdyArIDYw KjYwKkhaOwotI2VuZGlmCiAJYWRkX3RpbWVyKCZwc2NoZWRfdGltZXIpOwogfQogI2VuZGlm CiAKLSNpZiBQU0NIRURfQ0xPQ0tfU09VUkNFID09IFBTQ0hFRF9DUFUKIGludCBfX2luaXQg cHNjaGVkX2NhbGlicmF0ZV9jbG9jayh2b2lkKQogewogCXBzY2hlZF90aW1lX3Qgc3RhbXAs IHN0YW1wMTsKQEAgLTExODUsOSArMTE3NSw2IEBACiAjZWxpZiBQU0NIRURfQ0xPQ0tfU09V UkNFID09IFBTQ0hFRF9KSUZGSUVTCiAJcHNjaGVkX3RpY2tfcGVyX3VzID0gSFo8PFBTQ0hF RF9KU0NBTEU7CiAJcHNjaGVkX3VzX3Blcl90aWNrID0gMTAwMDAwMDsKLSNpZmRlZiBQU0NI RURfV0FUQ0hFUgotCXBzY2hlZF90aWNrKDApOwotI2VuZGlmCiAjZW5kaWYKIAogCWxpbmtf cCA9IHJ0bmV0bGlua19saW5rc1tQRl9VTlNQRUNdOwo= --------------090606060601010006000003-- From kaber@trash.net Thu Jul 22 16:42:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 16:42:48 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6MNghbt011691 for ; Thu, 22 Jul 2004 16:42:43 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BnnG9-0004tD-00; Fri, 23 Jul 2004 01:45:57 +0200 Message-ID: <410050D7.4030507@trash.net> Date: Fri, 23 Jul 2004 01:42:15 +0200 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: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH 2.6 2/2]: Use get_cycles for PSCHED_CPU clock source Content-Type: multipart/mixed; boundary="------------050007080004080806020709" X-archive-position: 7091 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------050007080004080806020709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch changes PSCHED_CPU clock source to use get_cycles. --------------050007080004080806020709 Content-Type: application/octect-stream; name="02-psched-get_cycles.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="02-psched-get_cycles.diff" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2gu CiMKIyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDcvMjIgMDE6NDM6NDgrMDI6MDAga2FiZXJAdHJh c2gubmV0IAojICAgW1BLVF9TQ0hFRF06IFVzZSBnZXRfY3ljbGVzKCkgZm9yIFBTQ0hFRF9D UFUgY2xvY2sgc291cmNlCiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IFBhdHJpY2sgTWNIYXJk eSA8a2FiZXJAdHJhc2gubmV0PgojIAojIG5ldC9zY2hlZC9zY2hfYXBpLmMKIyAgIDIwMDQv MDcvMjIgMDE6NDM6MzcrMDI6MDAga2FiZXJAdHJhc2gubmV0ICsxMSAtMTEKIyAgIFtQS1Rf U0NIRURdOiBVc2UgZ2V0X2N5Y2xlcygpIGZvciBQU0NIRURfQ1BVIGNsb2NrIHNvdXJjZQoj IAojIGluY2x1ZGUvbmV0L3BrdF9zY2hlZC5oCiMgICAyMDA0LzA3LzIyIDAxOjQzOjM3KzAy OjAwIGthYmVyQHRyYXNoLm5ldCArMTUgLTM0CiMgICBbUEtUX1NDSEVEXTogVXNlIGdldF9j eWNsZXMoKSBmb3IgUFNDSEVEX0NQVSBjbG9jayBzb3VyY2UKIyAKZGlmZiAtTnJ1IGEvaW5j bHVkZS9uZXQvcGt0X3NjaGVkLmggYi9pbmNsdWRlL25ldC9wa3Rfc2NoZWQuaAotLS0gYS9p bmNsdWRlL25ldC9wa3Rfc2NoZWQuaAkyMDA0LTA3LTIyIDIyOjIwOjA0ICswMjowMAorKysg Yi9pbmNsdWRlL25ldC9wa3Rfc2NoZWQuaAkyMDA0LTA3LTIyIDIyOjIwOjA0ICswMjowMApA QCAtMTYsMTEgKzE2LDYgQEAKICNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KICNpbmNsdWRl IDxsaW51eC9ydG5ldGxpbmsuaD4KIAotI2lmZGVmIENPTkZJR19YODZfVFNDCi0jaW5jbHVk ZSA8YXNtL21zci5oPgotI2VuZGlmCi0KLQogc3RydWN0IHJ0YXR0cjsKIHN0cnVjdCBRZGlz YzsKIApAQCAtMjM1LDQxICsyMzAsMjcgQEAKICNkZWZpbmUgUFNDSEVEX0pJRkZJRTJVUyhk ZWxheSkgKChkZWxheSk8PFBTQ0hFRF9KU0NBTEUpCiAKICNlbGlmIFBTQ0hFRF9DTE9DS19T T1VSQ0UgPT0gUFNDSEVEX0NQVQorI2luY2x1ZGUgPGFzbS90aW1leC5oPgogCiBleHRlcm4g cHNjaGVkX3RkaWZmX3QgcHNjaGVkX2Nsb2NrX3Blcl9oejsKIGV4dGVybiBpbnQgcHNjaGVk X2Nsb2NrX3NjYWxlOworZXh0ZXJuIHBzY2hlZF90aW1lX3QgcHNjaGVkX3RpbWVfYmFzZTsK K2V4dGVybiBjeWNsZXNfdCBwc2NoZWRfdGltZV9tYXJrOwogCisjZGVmaW5lIFBTQ0hFRF9H RVRfVElNRShzdGFtcCkJCQkJCQlcCitkbyB7CQkJCQkJCQkJXAorCWN5Y2xlc190IGN1ciA9 IGdldF9jeWNsZXMoKTsJCQkJCVwKKwlpZiAoc2l6ZW9mKGN5Y2xlc190KSA9PSBzaXplb2Yo dTMyKSkgewkJCQlcCisJCWlmIChjdXIgPD0gcHNjaGVkX3RpbWVfbWFyaykJCQkJXAorCQkJ cHNjaGVkX3RpbWVfYmFzZSArPSAweDEwMDAwMDAwMFVMTDsJCVwKKwkJcHNjaGVkX3RpbWVf bWFyayA9IGN1cjsJCQkJCVwKKwkJKHN0YW1wKSA9IChwc2NoZWRfdGltZV9iYXNlICsgY3Vy KT4+cHNjaGVkX2Nsb2NrX3NjYWxlOwlcCisJfSBlbHNlIHsJCQkJCQkJXAorCQkoc3RhbXAp ID0gY3VyPj5wc2NoZWRfY2xvY2tfc2NhbGU7CQkJXAorCX0JCQkJCQkJCVwKK30gd2hpbGUg KDApCiAjZGVmaW5lIFBTQ0hFRF9VUzJKSUZGSUUoZGVsYXkpICgoKGRlbGF5KStwc2NoZWRf Y2xvY2tfcGVyX2h6LTEpL3BzY2hlZF9jbG9ja19wZXJfaHopCiAjZGVmaW5lIFBTQ0hFRF9K SUZGSUUyVVMoZGVsYXkpICgoZGVsYXkpKnBzY2hlZF9jbG9ja19wZXJfaHopCi0KLSNpZmRl ZiBDT05GSUdfWDg2X1RTQwotCi0jZGVmaW5lIFBTQ0hFRF9HRVRfVElNRShzdGFtcCkgXAot KHsgdTY0IF9fY3VyOyBcCi0gICByZHRzY2xsKF9fY3VyKTsgXAotICAgKHN0YW1wKSA9IF9f Y3VyPj5wc2NoZWRfY2xvY2tfc2NhbGU7IFwKLX0pCi0KLSNlbGlmIGRlZmluZWQgKF9fYWxw aGFfXykKLQotI2RlZmluZSBQU0NIRURfV0FUQ0hFUiB1MzIKLQotZXh0ZXJuIHBzY2hlZF90 aW1lX3QgcHNjaGVkX3RpbWVfYmFzZTsKLWV4dGVybiBQU0NIRURfV0FUQ0hFUiBwc2NoZWRf dGltZV9tYXJrOwotCi0jZGVmaW5lIFBTQ0hFRF9HRVRfVElNRShzdGFtcCkgXAotKHsgdTMy IF9fcmVzOyBcCi0gICBfX2FzbV9fIF9fdm9sYXRpbGVfXyAoInJwY2MgJTAiIDogInI9Iihf X3JlcykpOyBcCi0gICBpZiAoX19yZXMgPD0gcHNjaGVkX3RpbWVfbWFyaykgcHNjaGVkX3Rp bWVfYmFzZSArPSAweDEwMDAwMDAwMFVMOyBcCi0gICBwc2NoZWRfdGltZV9tYXJrID0gX19y ZXM7IFwKLSAgIChzdGFtcCkgPSAocHNjaGVkX3RpbWVfYmFzZSArIF9fcmVzKT4+cHNjaGVk X2Nsb2NrX3NjYWxlOyBcCi19KQotCi0jZWxzZQotCi0jZXJyb3IgUFNDSEVEX0NMT0NLX1NP VVJDRT1QU0NIRURfQ1BVIGlzIG5vdCBzdXBwb3J0ZWQgb24gdGhpcyBhcmNoLgotCi0jZW5k aWYgLyogQVJDSCAqLwogCiAjZW5kaWYgLyogUFNDSEVEX0NMT0NLX1NPVVJDRSA9PSBQU0NI RURfSklGRklFUyAqLwogCmRpZmYgLU5ydSBhL25ldC9zY2hlZC9zY2hfYXBpLmMgYi9uZXQv c2NoZWQvc2NoX2FwaS5jCi0tLSBhL25ldC9zY2hlZC9zY2hfYXBpLmMJMjAwNC0wNy0yMiAy MjoyMDowNCArMDI6MDAKKysrIGIvbmV0L3NjaGVkL3NjaF9hcGkuYwkyMDA0LTA3LTIyIDIy OjIwOjA0ICswMjowMApAQCAtMTEwOSwyNSArMTEwOSwyNyBAQAogRVhQT1JUX1NZTUJPTChw c2NoZWRfY2xvY2tfcGVyX2h6KTsKIEVYUE9SVF9TWU1CT0wocHNjaGVkX2Nsb2NrX3NjYWxl KTsKIAotI2lmZGVmIFBTQ0hFRF9XQVRDSEVSCiBwc2NoZWRfdGltZV90IHBzY2hlZF90aW1l X2Jhc2U7Ci1QU0NIRURfV0FUQ0hFUiBwc2NoZWRfdGltZV9tYXJrOworY3ljbGVzX3QgcHNj aGVkX3RpbWVfbWFyazsKIEVYUE9SVF9TWU1CT0wocHNjaGVkX3RpbWVfbWFyayk7CiBFWFBP UlRfU1lNQk9MKHBzY2hlZF90aW1lX2Jhc2UpOwogCisvKgorICogUGVyaW9kaWNhbGx5IGFk anVzdCBwc2NoZWRfdGltZV9iYXNlIHRvIGF2b2lkIG92ZXJmbG93CisgKiB3aXRoIDMyLWJp dCBnZXRfY3ljbGVzKCkuIFNhZmUgdXAgdG8gNEdIeiBDUFUuCisgKi8KIHN0YXRpYyB2b2lk IHBzY2hlZF90aWNrKHVuc2lnbmVkIGxvbmcpOwotCiBzdGF0aWMgc3RydWN0IHRpbWVyX2xp c3QgcHNjaGVkX3RpbWVyID0gVElNRVJfSU5JVElBTElaRVIocHNjaGVkX3RpY2ssIDAsIDAp OwogCiBzdGF0aWMgdm9pZCBwc2NoZWRfdGljayh1bnNpZ25lZCBsb25nIGR1bW15KQogewot CXBzY2hlZF90aW1lX3QgZHVtbXlfc3RhbXA7Ci0JUFNDSEVEX0dFVF9USU1FKGR1bW15X3N0 YW1wKTsKLQkvKiBJdCBpcyBPSyB1cCB0byA0R0h6IGNwdSAqLwotCXBzY2hlZF90aW1lci5l eHBpcmVzID0gamlmZmllcyArIDEqSFo7Ci0JYWRkX3RpbWVyKCZwc2NoZWRfdGltZXIpOwor CWlmIChzaXplb2YoY3ljbGVzX3QpID09IHNpemVvZih1MzIpKSB7CisJCXBzY2hlZF90aW1l X3QgZHVtbXlfc3RhbXA7CisJCVBTQ0hFRF9HRVRfVElNRShkdW1teV9zdGFtcCk7CisJCXBz Y2hlZF90aW1lci5leHBpcmVzID0gamlmZmllcyArIDEqSFo7CisJCWFkZF90aW1lcigmcHNj aGVkX3RpbWVyKTsKKwl9CiB9Ci0jZW5kaWYKIAogaW50IF9faW5pdCBwc2NoZWRfY2FsaWJy YXRlX2Nsb2NrKHZvaWQpCiB7CkBAIC0xMTM3LDkgKzExMzksNyBAQAogCWxvbmcgcmRlbGF5 OwogCXVuc2lnbmVkIGxvbmcgc3RvcDsKIAotI2lmZGVmIFBTQ0hFRF9XQVRDSEVSCiAJcHNj aGVkX3RpY2soMCk7Ci0jZW5kaWYKIAlzdG9wID0gamlmZmllcyArIEhaLzEwOwogCVBTQ0hF RF9HRVRfVElNRShzdGFtcCk7CiAJZG9fZ2V0dGltZW9mZGF5KCZ0dik7Cg== --------------050007080004080806020709-- From yoshfuji@linux-ipv6.org Thu Jul 22 17:04:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 17:04:26 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N04JBK012210 for ; Thu, 22 Jul 2004 17:04:20 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1742E33CE5; Fri, 23 Jul 2004 09:04:32 +0900 (JST) Date: Thu, 22 Jul 2004 20:04:26 -0400 (EDT) Message-Id: <20040722.200426.99255296.yoshfuji@linux-ipv6.org> To: shemminger@osdl.org Cc: davem@redhat.com, hadi@znyx.com, arekm@pld-linux.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] pkt_cls.h incompatiables From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> References: <20040716103759.1928c2ae@dell_ss3.pdx.osdl.net> <200407172357.15832.arekm@pld-linux.org> <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7092 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> (at Thu, 22 Jul 2004 13:45:22 -0700), Stephen Hemminger says: > The recent changes to (6 Jul 04) pkt_cls.h are evil, you can't build a version > of 'tc' to work unless you know the kernel config! > > It has several API problems: > - API data structures change on kernel config options > - new fields should be added at the end of a structure to allow > binary compatibility. - We cannot add new variable(s) after the last member which is an variable-length array in effect. > @@ -229,11 +214,9 @@ > > short hoff; > __u32 hmask; > -#ifdef CONFIG_CLS_U32_PERF > + struct tc_u32_key keys[0]; > unsigned long rcnt; > unsigned long rhit; > -#endif > - struct tc_u32_key keys[0]; > }; > > /* Flags */ We cannot do this because keys holds key of variable length. Solutions are, for example, to allocate new TCA_U32_xxx for rcnt and rhit, or, to rename TCA_U32_SEL to TCA_U32_OLS_SEL and allocate new value for TCA_U32_SEL. --yoshfuji From jt@bougret.hpl.hp.com Thu Jul 22 17:21:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 17:21:27 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N0LIo6012923 for ; Thu, 22 Jul 2004 17:21:19 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 3A5F9609B; Thu, 22 Jul 2004 17:21:16 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id RAA10760; Thu, 22 Jul 2004 17:22:20 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1BnnoI-00034i-00; Thu, 22 Jul 2004 17:21:14 -0700 Date: Thu, 22 Jul 2004 17:21:14 -0700 To: Javier Achirica , Jeff Garzik , netdev@oss.sgi.com Subject: [PATCH 2.6] airo.c set_bit bug Message-ID: <20040723002114.GA11815@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 7093 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Hi Javier, Managed to find a bug in the usage of set_bit/clear_bit in the airo driver. I'm not sure if I caught all occurence of this pattern, and not sure about exact consequences of the bug, but we might as well fix it... Patch below... Have fun... Jean -------------------------------------------------------- --- linux/drivers/net/wireless/airo.j1.c Thu Jul 22 15:27:48 2004 +++ linux/drivers/net/wireless/airo.c Thu Jul 22 15:29:11 2004 @@ -1808,7 +1808,8 @@ static int writeConfigRid(struct airo_in if (!test_bit (FLAG_COMMIT, &ai->flags)) return SUCCESS; - clear_bit (FLAG_COMMIT | FLAG_RESET, &ai->flags); + clear_bit (FLAG_COMMIT, &ai->flags); + clear_bit (FLAG_RESET, &ai->flags); checkThrottle(ai); cfgr = ai->config; @@ -6158,7 +6159,8 @@ static int airo_set_txpow(struct net_dev readCapabilityRid(local, &cap_rid); if (vwrq->disabled) { - set_bit (FLAG_RADIO_OFF | FLAG_COMMIT, &local->flags); + set_bit (FLAG_RADIO_OFF, &local->flags); + set_bit (FLAG_COMMIT, &local->flags); return -EINPROGRESS; /* Call commit handler */ } if (vwrq->flags != IW_TXPOW_MWATT) { From davem@redhat.com Thu Jul 22 17:22:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 17:22:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N0MVhs013048 for ; Thu, 22 Jul 2004 17:22:32 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6N0MJe1028843; Thu, 22 Jul 2004 20:22:19 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6N0MJa20385; Thu, 22 Jul 2004 20:22:19 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6N0LfKd019895; Thu, 22 Jul 2004 20:21:42 -0400 Date: Thu, 22 Jul 2004 17:17:52 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040722171752.341d2476.davem@redhat.com> In-Reply-To: <41004F76.1080807@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7094 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 01:36:22 +0200 Patrick McHardy wrote: > > I suggest we just expand the dependency list for NET_SCH_CLK_TSC > > to include SPARC64 PPC64 and perhaps some other easy to verify > > as having a working get_cycles() implementation. I believe that > > as long as it increments at some rate >= jiffies, the psched > > calibration will get things into a working state. > > It needs to increment at slightly above 1Mhz, otherwise delay will > be zero after this division and everything will fall apart: > delay /= rdelay. I see. I know for a fact that sparc64 meets this criterion, and I'm pretty sure ppc64 does too. We could bug check this in psched calibration, in fact I think we should. From davem@redhat.com Thu Jul 22 17:27:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 17:27:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N0RipP013570 for ; Thu, 22 Jul 2004 17:27:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6N0Rge1030596; Thu, 22 Jul 2004 20:27:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6N0Rfa22495; Thu, 22 Jul 2004 20:27:41 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6N0R32B022931; Thu, 22 Jul 2004 20:27:04 -0400 Date: Thu, 22 Jul 2004 17:23:14 -0700 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 1/2]: Remove dead timer code Message-Id: <20040722172314.7ae19c0c.davem@redhat.com> In-Reply-To: <41005069.3030703@trash.net> References: <41005069.3030703@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7095 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 01:40:25 +0200 Patrick McHardy wrote: > This patch removes some dead timer code left over from the > PSCHED_JIFFIES clock source change to use get_jiffies_64(). Applied, thanks Patrick. From davem@redhat.com Thu Jul 22 17:30:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 17:30:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N0UmwI013886 for ; Thu, 22 Jul 2004 17:30:48 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6N0Uje1031809; Thu, 22 Jul 2004 20:30:45 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6N0Uja23893; Thu, 22 Jul 2004 20:30:45 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6N0U8Xu024600; Thu, 22 Jul 2004 20:30:08 -0400 Date: Thu, 22 Jul 2004 17:26:19 -0700 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 2/2]: Use get_cycles for PSCHED_CPU clock source Message-Id: <20040722172619.4699987a.davem@redhat.com> In-Reply-To: <410050D7.4030507@trash.net> References: <410050D7.4030507@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7096 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 01:42:15 +0200 Patrick McHardy wrote: > This patch changes PSCHED_CPU clock source to use get_cycles. Also applied, thanks Patrick. From kaber@trash.net Thu Jul 22 17:53:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 17:53:08 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N0r1Ue014510 for ; Thu, 22 Jul 2004 17:53:02 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BnoMA-0006YM-00; Fri, 23 Jul 2004 02:56:14 +0200 Message-ID: <41006150.9000702@trash.net> Date: Fri, 23 Jul 2004 02:52:32 +0200 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: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> In-Reply-To: <20040722171752.341d2476.davem@redhat.com> Content-Type: multipart/mixed; boundary="------------030106070601060508090004" X-archive-position: 7097 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------030106070601060508090004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David S. Miller wrote: >>It needs to increment at slightly above 1Mhz, otherwise delay will >>be zero after this division and everything will fall apart: >>delay /= rdelay. > > I see. I know for a fact that sparc64 meets this criterion, and > I'm pretty sure ppc64 does too. I'm pretty sure x86, x86_64, alpha, sparc64, ppc64 and ia64 can be used. I'm not sure if the frequency of all ppcs is high enough, so I won't add support for them. > We could bug check this in psched calibration, in fact I think > we should. Done by this patch. I used BUG_ON instead of just printing a warning because using packet schedulers after this error will cause a division by zero. Regards Patrick --------------030106070601060508090004 Content-Type: application/octect-stream; name="psched-bug_on_invalid_cycles.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="psched-bug_on_invalid_cycles.diff" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2gu CiMKIyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDcvMjMgMDI6NDU6MzkrMDI6MDAga2FiZXJAdHJh c2gubmV0IAojICAgW1BLVF9TQ0hFRF06IEJVR19PTiBpbnZhbGlkIGRlbGF5IGZyb20gY3lj bGUgY291bnRlciBpbiBwc2NoZWRfY2FsaWJyYXRlX2Nsb2NrCiMgICAKIyAgIFNpZ25lZC1v ZmYtYnk6IFBhdHJpY2sgTWNIYXJkeSA8a2FiZXJAdHJhc2gubmV0PgojIAojIG5ldC9zY2hl ZC9zY2hfYXBpLmMKIyAgIDIwMDQvMDcvMjMgMDI6NDU6MjcrMDI6MDAga2FiZXJAdHJhc2gu bmV0ICsxIC0wCiMgICBbUEtUX1NDSEVEXTogQlVHX09OIGludmFsaWQgZGVsYXkgZnJvbSBj eWNsZSBjb3VudGVyIGluIHBzY2hlZF9jYWxpYnJhdGVfY2xvY2sKIyAKZGlmZiAtTnJ1IGEv bmV0L3NjaGVkL3NjaF9hcGkuYyBiL25ldC9zY2hlZC9zY2hfYXBpLmMKLS0tIGEvbmV0L3Nj aGVkL3NjaF9hcGkuYwkyMDA0LTA3LTIzIDAyOjQ5OjI1ICswMjowMAorKysgYi9uZXQvc2No ZWQvc2NoX2FwaS5jCTIwMDQtMDctMjMgMDI6NDk6MjUgKzAyOjAwCkBAIC0xMTU2LDYgKzEx NTYsNyBAQAogCWlmIChyZGVsYXkgPiBkZWxheSkKIAkJcmV0dXJuIC0xOwogCWRlbGF5IC89 IHJkZWxheTsKKwlCVUdfT04oZGVsYXkgPT0gMCk7CiAJcHNjaGVkX3RpY2tfcGVyX3VzID0g ZGVsYXk7CiAJd2hpbGUgKChkZWxheT4+PTEpICE9IDApCiAJCXBzY2hlZF9jbG9ja19zY2Fs ZSsrOwo= --------------030106070601060508090004-- From kaber@trash.net Thu Jul 22 18:01:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 18:01:29 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N11MUT015047 for ; Thu, 22 Jul 2004 18:01:23 -0700 Received: from [172.20.0.3] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BnoUE-0006jk-00; Fri, 23 Jul 2004 03:04:34 +0200 Message-ID: <41006344.3070402@trash.net> Date: Fri, 23 Jul 2004 03:00:52 +0200 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: Patrick McHardy CC: "David S. Miller" , shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> In-Reply-To: <41006150.9000702@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7098 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Patrick McHardy wrote: > David S. Miller wrote: >> We could bug check this in psched calibration, in fact I think >> we should. > > > Done by this patch. I used BUG_ON instead of just printing a warning > because using packet schedulers after this error will cause a division > by zero. Please drop this patch, psched_calibrate_clock already checks if rdelay > delay a couple of lines above. > Regards > Patrick From davem@redhat.com Thu Jul 22 18:03:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jul 2004 18:03:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6N13mYg015383 for ; Thu, 22 Jul 2004 18:03:49 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6N13Je1009099; Thu, 22 Jul 2004 21:03:19 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6N13Ja00741; Thu, 22 Jul 2004 21:03:19 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6N12eIo010139; Thu, 22 Jul 2004 21:02:41 -0400 Date: Thu, 22 Jul 2004 18:03:17 -0700 From: "David S. Miller" To: Patrick McHardy Cc: kaber@trash.net, shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040722180317.0b2ae203.davem@redhat.com> In-Reply-To: <41006344.3070402@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41006344.3070402@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7099 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 03:00:52 +0200 Patrick McHardy wrote: > Patrick McHardy wrote: > > David S. Miller wrote: > >> We could bug check this in psched calibration, in fact I think > >> we should. > > > > > > Done by this patch. I used BUG_ON instead of just printing a warning > > because using packet schedulers after this error will cause a division > > by zero. > > Please drop this patch, psched_calibrate_clock already checks if > rdelay > delay a couple of lines above. Ok. From herbert@gondor.apana.org.au Fri Jul 23 04:06:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 04:07:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NB6h5F003888 for ; Fri, 23 Jul 2004 04:06:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bnxso-0002yx-00; Fri, 23 Jul 2004 21:06:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bnxsh-00005y-00; Fri, 23 Jul 2004 21:06:27 +1000 Date: Fri, 23 Jul 2004 21:06:26 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Missing unlock in policy timer Message-ID: <20040723110626.GA31264@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7100 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is one of those cases where the cure is worse than the disease :) I added read locks in the policy timer to close an unlikely race, but I missed an unlock on the expire path which leads to all sort of weird things. I'll stay away from the timers for a while :) Signed-off-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/xfrm/xfrm_policy.c 1.51 vs edited ===== --- 1.51/net/xfrm/xfrm_policy.c 2004-05-30 05:45:43 +10:00 +++ edited/net/xfrm/xfrm_policy.c 2004-07-23 21:00:52 +10:00 @@ -204,6 +204,7 @@ return; expired: + read_unlock(&xp->lock); km_policy_expired(xp, dir, 1); xfrm_policy_delete(xp, dir); xfrm_pol_put(xp); --EeQfGwPcQSOJBaQU-- From mlindner@syskonnect.de Fri Jul 23 04:15:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 04:15:53 -0700 (PDT) Received: from gatekeeper.syskonnect.de (gatekeeper.syskonnect.de [213.144.13.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NBFisP004434 for ; Fri, 23 Jul 2004 04:15:45 -0700 Received: from syskonnect.de (skd.de [10.9.15.1]) by gatekeeper.syskonnect.de (8.12.10/8.12.10) with ESMTP id i6NBFhS5004570; Fri, 23 Jul 2004 13:15:43 +0200 (MET DST) Received: from syskonnect.de (localhost [127.0.0.1]) by syskonnect.de (8.12.9-patch8.359.2.8/8.12.9) with ESMTP id i6NBFciO011351; Fri, 23 Jul 2004 13:15:38 +0200 (MET DST) Message-ID: <4100F51C.3030709@syskonnect.de> Date: Fri, 23 Jul 2004 13:23:08 +0200 From: Mirko Lindner User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: netdev@oss.sgi.com, Ralph Roesler , Jeff Garzik Subject: Re: [PATCH] convert skge to pci_driver API (2nd try) References: <20040620112859.GA13794@lst.de> In-Reply-To: <20040620112859.GA13794@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7101 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mlindner@syskonnect.de Precedence: bulk X-list: netdev Hi Christoph, I'm sorry for this late answer. I was in holiday last weeks and couldn't check my company emails regulary. Thanks a lot for the patch. Actually, we were busy with the new driver version 7.x which yukon ec and yukon2 support, which involves also the new init and deinit pci driver API. The patch you have created is very similar to our work created about few months ago. The new driver version can be found at the moment for all testers on out page (http://www.syskonnect.de/syskonnect/support/driver/htm/sk9e21_lin.htm) and we are busy with additional stability and robustness tests. As soon as the driver is ready for the kernel stability we'll send the patches to Jeff and the KML. Therefore we would like to keep our driver consistent and it's not possible for us to merge your changes into our code tree. Please don't apply the patch to the kernel tree, there are several problems with proc and locking which will probably lead to kernel oops. The new V7.05 version includes all kernel patches since the last v6 driver release and additional code for handling the new descriptor (lists) logic of yukon ec and yukon2 cards, ethtool support, tcp-segmentation, power management. proc fs cleanups and changes for the interrupt moderation. Cheers, Mirko From herbert@gondor.apana.org.au Fri Jul 23 06:53:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 06:53:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NDrjro009693 for ; Fri, 23 Jul 2004 06:53:48 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bo0UI-00040b-00; Fri, 23 Jul 2004 23:53:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bo0UD-0007ks-00; Fri, 23 Jul 2004 23:53:21 +1000 Date: Fri, 23 Jul 2004 23:53:21 +1000 To: Kazunori Miyazawa , "David S. Miller" , netdev@oss.sgi.com Subject: [AH6] Disallow mutable bits after AH header Message-ID: <20040723135320.GA26000@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7102 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: As we discussed before, mutable headers should not be allowed after the AH header. In fact, this appears to be the intention of RFC 2402. It is further clarified in section 3.1.1 of http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-07.txt This allows us to simplify the code in ah6.c. As a result, this also fixes the following issues: * Dependence on skb->h in ah6_output(). * Bogus clearing of auth_data of 2nd AH header in ipv6_clear_mutable_options(). Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/ah6.c 1.32 vs edited ===== --- 1.32/net/ipv6/ah6.c 2004-06-18 16:20:58 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-23 23:44:50 +10:00 @@ -74,34 +74,29 @@ return 0; } -static int ipv6_clear_mutable_options(struct sk_buff *skb, u16 *nh_offset, int dir) +static int ipv6_clear_mutable_options(struct sk_buff *skb, + unsigned int hdr_len) { u16 offset = sizeof(struct ipv6hdr); struct ipv6_opt_hdr *exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); - unsigned int packet_len = skb->tail - skb->nh.raw; u8 nexthdr = skb->nh.ipv6h->nexthdr; - u8 nextnexthdr = 0; - *nh_offset = ((unsigned char *)&skb->nh.ipv6h->nexthdr) - skb->nh.raw; - - while (offset + 1 <= packet_len) { + while (offset + 1 <= hdr_len) { switch (nexthdr) { case NEXTHDR_HOP: - *nh_offset = offset; offset += ipv6_optlen(exthdr); if (!zero_out_mutable_opts(exthdr)) { LIMIT_NETDEBUG( printk(KERN_WARNING "overrun hopopts\n")); - return 0; + return -EINVAL; } nexthdr = exthdr->nexthdr; exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); break; case NEXTHDR_ROUTING: - *nh_offset = offset; offset += ipv6_optlen(exthdr); ((struct ipv6_rt_hdr*)exthdr)->segments_left = 0; nexthdr = exthdr->nexthdr; @@ -109,39 +104,22 @@ break; case NEXTHDR_DEST: - *nh_offset = offset; offset += ipv6_optlen(exthdr); if (!zero_out_mutable_opts(exthdr)) { LIMIT_NETDEBUG( printk(KERN_WARNING "overrun destopt\n")); - return 0; + return -EINVAL; } nexthdr = exthdr->nexthdr; exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); break; - case NEXTHDR_AUTH: - if (dir == XFRM_POLICY_OUT) { - memset(((struct ipv6_auth_hdr*)exthdr)->auth_data, 0, - (((struct ipv6_auth_hdr*)exthdr)->hdrlen - 1) << 2); - } - if (exthdr->nexthdr == NEXTHDR_DEST) { - offset += (((struct ipv6_auth_hdr*)exthdr)->hdrlen + 2) << 2; - exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); - nextnexthdr = exthdr->nexthdr; - if (!zero_out_mutable_opts(exthdr)) { - LIMIT_NETDEBUG( - printk(KERN_WARNING "overrun destopt\n")); - return 0; - } - } - return nexthdr; default : - return nexthdr; + return 0; } } - return nexthdr; + return 0; } int ah6_output(struct sk_buff **pskb) @@ -153,7 +131,6 @@ struct ipv6hdr *iph = NULL; struct ip_auth_hdr *ah; struct ah_data *ahp; - u16 nh_offset = 0; u8 nexthdr; if ((*pskb)->ip_summed == CHECKSUM_HW) { @@ -184,7 +161,11 @@ ah = (struct ip_auth_hdr*)((*pskb)->nh.ipv6h+1); ah->nexthdr = IPPROTO_IPV6; } else { - hdr_len = (*pskb)->h.raw - (*pskb)->nh.raw; + u8 *prevhdr; + + hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); + nexthdr = *prevhdr; + *prevhdr = IPPROTO_AH; iph = kmalloc(hdr_len, GFP_ATOMIC); if (!iph) { err = -ENOMEM; @@ -192,13 +173,12 @@ } memcpy(iph, (*pskb)->data, hdr_len); (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); + iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - nexthdr = ipv6_clear_mutable_options(*pskb, &nh_offset, XFRM_POLICY_OUT); - if (nexthdr == 0) + err = ipv6_clear_mutable_options(*pskb, hdr_len); + if (err) goto error_free_iph; - (*pskb)->nh.raw[nh_offset] = IPPROTO_AH; - (*pskb)->nh.ipv6h->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); ah = (struct ip_auth_hdr*)((*pskb)->nh.raw+hdr_len); (*pskb)->h.raw = (unsigned char*) ah; ah->nexthdr = nexthdr; @@ -229,8 +209,6 @@ IP6_ECN_clear((*pskb)->nh.ipv6h); } else { memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - (*pskb)->nh.raw[nh_offset] = IPPROTO_AH; - (*pskb)->nh.ipv6h->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); kfree (iph); } @@ -259,7 +237,6 @@ * Before process AH * [IPv6][Ext1][Ext2][AH][Dest][Payload] * |<-------------->| hdr_len - * |<------------------------>| cleared_hlen * * To erase AH: * Keeping copy of cleared headers. After AH processing, @@ -276,7 +253,6 @@ unsigned char *tmp_hdr = NULL; u16 hdr_len; u16 ah_hlen; - u16 cleared_hlen; u16 nh_offset = 0; u8 nexthdr = 0; u8 *prevhdr; @@ -291,17 +267,10 @@ goto out; hdr_len = skb->data - skb->nh.raw; - cleared_hlen = hdr_len; ah = (struct ipv6_auth_hdr*)skb->data; ahp = x->data; nexthdr = ah->nexthdr; ah_hlen = (ah->hdrlen + 2) << 2; - cleared_hlen += ah_hlen; - - if (nexthdr == NEXTHDR_DEST) { - struct ipv6_opt_hdr *dsthdr = (struct ipv6_opt_hdr*)(skb->data + ah_hlen); - cleared_hlen += ipv6_optlen(dsthdr); - } if (ah_hlen != XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + ahp->icv_full_len) && ah_hlen != XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + ahp->icv_trunc_len)) @@ -310,11 +279,12 @@ if (!pskb_may_pull(skb, ah_hlen)) goto out; - tmp_hdr = kmalloc(cleared_hlen, GFP_ATOMIC); + tmp_hdr = kmalloc(hdr_len, GFP_ATOMIC); if (!tmp_hdr) goto out; - memcpy(tmp_hdr, skb->nh.raw, cleared_hlen); - ipv6_clear_mutable_options(skb, &nh_offset, XFRM_POLICY_IN); + memcpy(tmp_hdr, skb->nh.raw, hdr_len); + if (ipv6_clear_mutable_options(skb, hdr_len)) + goto out; skb->nh.ipv6h->priority = 0; skb->nh.ipv6h->flow_lbl[0] = 0; skb->nh.ipv6h->flow_lbl[1] = 0; @@ -338,11 +308,6 @@ skb->nh.raw = skb_pull(skb, ah_hlen); memcpy(skb->nh.raw, tmp_hdr, hdr_len); - if (nexthdr == NEXTHDR_DEST) { - memcpy(skb->nh.raw + hdr_len, - tmp_hdr + hdr_len + ah_hlen, - cleared_hlen - hdr_len - ah_hlen); - } prevhdr = (u8*)(skb->nh.raw + nh_offset); *prevhdr = nexthdr; skb->nh.ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); --ibTvN161/egqYuK8-- From SRS0+111ad9f4f8fa51f37f42+334+infradead.org+hch@pentafluge.srs.infradead.org Fri Jul 23 07:22:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 07:22:51 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NEMhqv010432 for ; Fri, 23 Jul 2004 07:22:45 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1Bo0wP-0007yV-I0; Fri, 23 Jul 2004 15:22:29 +0100 Date: Fri, 23 Jul 2004 15:22:29 +0100 From: Christoph Hellwig To: Mirko Lindner Cc: Christoph Hellwig , netdev@oss.sgi.com, Ralph Roesler , Jeff Garzik Subject: Re: [PATCH] convert skge to pci_driver API (2nd try) Message-ID: <20040723142229.GA30611@infradead.org> References: <20040620112859.GA13794@lst.de> <4100F51C.3030709@syskonnect.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4100F51C.3030709@syskonnect.de> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7103 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Fri, Jul 23, 2004 at 01:23:08PM +0200, Mirko Lindner wrote: > (http://www.syskonnect.de/syskonnect/support/driver/htm/sk9e21_lin.htm) > and we are busy with additional stability and robustness tests. As soon > as the driver is ready for the kernel stability we'll send the patches > to Jeff and the KML. > > Therefore we would like to keep our driver consistent and it's not > possible for us to merge your changes into our code tree. Please don't > apply the patch to the kernel tree, there are several problems with proc Submitting big blobs is not how linux kernel development works. Please submit your encehancements in small, splitup patches ontop of mine that are in Jeff's netdev queue already. From hadi@znyx.com Fri Jul 23 07:42:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 07:42:29 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NEgEYG010942 for ; Fri, 23 Jul 2004 07:42:15 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072307422053:34727 ; Fri, 23 Jul 2004 07:42:20 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: shemminger@osdl.org, "David S. Miller" , arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <20040722.200426.99255296.yoshfuji@linux-ipv6.org> References: <20040716103759.1928c2ae@dell_ss3.pdx.osdl.net> <200407172357.15832.arekm@pld-linux.org> <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> Organization: ZNYX Networks Message-Id: <1090593676.1128.25.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Jul 2004 10:41:16 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 07:42:21 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 07:42:29 AM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id i6NEgEYG010942 X-archive-position: 7104 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev On Thu, 2004-07-22 at 20:04, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> (at Thu, 22 Jul 2004 13:45:22 -0700), Stephen Hemminger says: > > > The recent changes to (6 Jul 04) pkt_cls.h are evil, you can't build a version > > of 'tc' to work unless you know the kernel config! > > > > It has several API problems: > > - API data structures change on kernel config options > > - new fields should be added at the end of a structure to allow > > binary compatibility. > - We cannot add new variable(s) after the last member which is > an variable-length array in effect. Agreed. The enum types are easy to handle - we just keep adding to the end which doesnt break any ABI (as long as we keep the enum types in the same spot even if they are no longer being used). For the data structures it does get tricky to augment as proposed above because it does _break the ABI_. In particular it gets tricky if someone is to debug why the policy they are submitting is getting rejected. Maybe a sizeof check followed by a debug printk would help. Clearly even a sizeof is problematic in this case when keys[] is variable which brings me to a slightly different topic: One little proposal is to start adding versioning to some of the important fields. I have done this for the netlink header so i could figure if tc was broken. Dave is against this idea. His opinion is now we will get a lot of idjots mod-ing the structures and then bumping the version numbers. All the actions extensions actually have versioning fields. Another related topic: tc SHOULD be able to probe configured kernel options. It is a Good Thing to be able to do. Avoiding it as in this patch is not the answer. I have some suggestions when i get time i will speak with code. If someone wants this discussed we can continue on the list. > > @@ -229,11 +214,9 @@ > > > > short hoff; > > __u32 hmask; > > -#ifdef CONFIG_CLS_U32_PERF > > + struct tc_u32_key keys[0]; > > unsigned long rcnt; > > unsigned long rhit; > > -#endif > > - struct tc_u32_key keys[0]; > > }; > > > > /* Flags */ > > We cannot do this because keys holds key of variable length. Yes - please change this. > Solutions are, for example, > to allocate new TCA_U32_xxx for rcnt and rhit, > or, > to rename TCA_U32_SEL to TCA_U32_OLS_SEL and allocate new value for > TCA_U32_SEL. we could do this, but since we are already fscking the ABI it is not valuable. cheeers. jamal From yoshfuji@linux-ipv6.org Fri Jul 23 08:00:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 08:00:13 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NExxkR011635 for ; Fri, 23 Jul 2004 08:00:00 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E0CB333CE5; Sat, 24 Jul 2004 00:00:12 +0900 (JST) Date: Fri, 23 Jul 2004 11:00:07 -0400 (EDT) Message-Id: <20040723.110007.27520072.yoshfuji@linux-ipv6.org> To: hadi@znyx.com Cc: shemminger@osdl.org, davem@redhat.com, arekm@pld-linux.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] pkt_cls.h incompatiables From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1090593676.1128.25.camel@jzny.localdomain> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7105 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <1090593676.1128.25.camel@jzny.localdomain> (at 23 Jul 2004 10:41:16 -0400), Jamal Hadi Salim says: > > Solutions are, for example, > > to allocate new TCA_U32_xxx for rcnt and rhit, > > or, > > to rename TCA_U32_SEL to TCA_U32_OLS_SEL and allocate new value for > > TCA_U32_SEL. > > > we could do this, but since we are already fscking the ABI it is not > valuable. BTW, what's for rcnt etc.? I don't see the point. They're not (effectively) used in kernel. I'd suggest to remove these things and to maintain the original ABI. If rcnt etc. are for other purposes, such as statistics for userspace, please allocate another structure / interface for it. (And... cheking size is too strict; we need to relax it to accept old binaries if we add something at the tail of structure.) Thanks. --yoshfuji From max@stro.at Fri Jul 23 08:43:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 08:43:27 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NFhIED016329 for ; Fri, 23 Jul 2004 08:43:19 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id ED77C5C009; Fri, 23 Jul 2004 17:43:14 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17555-03; Fri, 23 Jul 2004 17:43:11 +0200 (CEST) Received: from sputnik (M956P029.adsl.highway.telekom.at [62.47.151.125]) by baikonur.stro.at (Postfix) with ESMTP id 905A55C008; Fri, 23 Jul 2004 17:43:11 +0200 (CEST) Received: from max by sputnik with local (Exim 4.32) id 1Bo2CW-0007al-F3; Fri, 23 Jul 2004 17:43:12 +0200 Date: Fri, 23 Jul 2004 17:43:12 +0200 From: maks attems To: saw@saw.sw.com.sg, jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [patch-kj] remove old ifdefs net/eepro100.c Message-ID: <20040723154312.GO1795@stro.at> Mail-Followup-To: saw@saw.sw.com.sg, jgarzik@pobox.com, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 7106 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: debian@sternwelten.at Precedence: bulk X-list: netdev Patches to remove some old ifdefs, 2.2 comptability. then remove unused #include applies cleanly to 2.6.8-rc2 From: Domen Puncer Signed-off-by: Maximilian Attems --- linux-2.6.7-bk20-max/drivers/net/eepro100.c | 17 ----------------- 1 files changed, 17 deletions(-) diff -puN drivers/net/eepro100.c~remove-old-ifdefs-eepro100 drivers/net/eepro100.c --- linux-2.6.7-bk20/drivers/net/eepro100.c~remove-old-ifdefs-eepro100 2004-07-11 14:42:27.000000000 +0200 +++ linux-2.6.7-bk20-max/drivers/net/eepro100.c 2004-07-11 14:42:27.000000000 +0200 @@ -88,7 +88,6 @@ static int options[] = {-1, -1, -1, -1, #define PKT_BUF_SZ 1536 #include -#include #include #include @@ -2447,22 +2446,6 @@ static struct pci_driver eepro100_driver #endif /* CONFIG_PM */ }; -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,48) -static int pci_module_init(struct pci_driver *pdev) -{ - int rc; - - rc = pci_register_driver(pdev); - if (rc <= 0) { - printk(KERN_INFO "%s: No cards found, driver not installed.\n", - pdev->name); - pci_unregister_driver(pdev); - return -ENODEV; - } - return 0; -} -#endif - static int __init eepro100_init_module(void) { #ifdef MODULE From shemminger@osdl.org Fri Jul 23 09:21:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 09:21:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NGLaVn017238 for ; Fri, 23 Jul 2004 09:21:37 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6NGLB104462; Fri, 23 Jul 2004 09:21:11 -0700 Date: Fri, 23 Jul 2004 09:21:11 -0700 From: Stephen Hemminger To: YOSHIFUJI Hideaki / =?ISO-8859-1?B?X19fX19fX19fX19f?= Cc: hadi@znyx.com, davem@redhat.com, arekm@pld-linux.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] pkt_cls.h incompatiables Message-Id: <20040723092111.44b289a9@dell_ss3.pdx.osdl.net> In-Reply-To: <20040723.110007.27520072.yoshfuji@linux-ipv6.org> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6NGLaVn017238 X-archive-position: 7107 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 11:00:07 -0400 (EDT) YOSHIFUJI Hideaki / ____________ wrote: > In article <1090593676.1128.25.camel@jzny.localdomain> (at 23 Jul 2004 10:41:16 -0400), Jamal Hadi Salim says: > > > > Solutions are, for example, > > > to allocate new TCA_U32_xxx for rcnt and rhit, > > > or, > > > to rename TCA_U32_SEL to TCA_U32_OLS_SEL and allocate new value for > > > TCA_U32_SEL. > > > > > > we could do this, but since we are already fscking the ABI it is not > > valuable. > > BTW, what's for rcnt etc.? I don't see the point. > > They're not (effectively) used in kernel. > I'd suggest to remove these things and to maintain the original ABI. > > If rcnt etc. are for other purposes, such as statistics for userspace, > please allocate another structure / interface for it. > > (And... cheking size is too strict; > we need to relax it to accept old binaries if we add something > at the tail of structure.) Looking at the netlink style, wouldn't it make sense to add additional separate payloads for the new features. This keeps the API the same and the kernel can easily adapt for new/old values. From kaber@trash.net Fri Jul 23 10:14:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 10:14:11 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NHE2eG018334 for ; Fri, 23 Jul 2004 10:14:03 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1Bo3fY-0000bQ-00; Fri, 23 Jul 2004 19:17:16 +0200 Message-ID: <41014788.4070301@trash.net> Date: Fri, 23 Jul 2004 19:14:48 +0200 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: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> In-Reply-To: <41006150.9000702@trash.net> Content-Type: multipart/mixed; boundary="------------040608040801010605080705" X-archive-position: 7108 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040608040801010605080705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > I'm pretty sure x86, x86_64, alpha, sparc64, ppc64 and ia64 can > be used. I'm not sure if the frequency of all ppcs is high enough, > so I won't add support for them. This is the patch for configurable clock source. I've double-checked the arches, I think all mentioned above work fine. I've taken some text from Stephen's patch for the help text .. thanks ;) Dave, do you want me to provide patches for 2.4 as well ? Regards Patrick --------------040608040801010605080705 Content-Type: text/plain; name="psched-configurable_clock_source.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="psched-configurable_clock_source.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/07/23 18:57:36+02:00 kaber@trash.net # [PKT_SCHED]: Make clock source configurable # # Signed-off-by: Patrick McHardy # # net/sched/sch_htb.c # 2004/07/23 18:57:24+02:00 kaber@trash.net +10 -0 # [PKT_SCHED]: Make clock source configurable # # net/sched/sch_hfsc.c # 2004/07/23 18:57:24+02:00 kaber@trash.net +5 -5 # [PKT_SCHED]: Make clock source configurable # # net/sched/sch_api.c # 2004/07/23 18:57:24+02:00 kaber@trash.net +4 -4 # [PKT_SCHED]: Make clock source configurable # # net/sched/Kconfig # 2004/07/23 18:57:24+02:00 kaber@trash.net +55 -0 # [PKT_SCHED]: Make clock source configurable # # include/net/pkt_sched.h # 2004/07/23 18:57:24+02:00 kaber@trash.net +11 -22 # [PKT_SCHED]: Make clock source configurable # diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-07-23 18:59:48 +02:00 +++ b/include/net/pkt_sched.h 2004-07-23 18:59:48 +02:00 @@ -1,12 +1,6 @@ #ifndef __NET_PKT_SCHED_H #define __NET_PKT_SCHED_H -#define PSCHED_GETTIMEOFDAY 1 -#define PSCHED_JIFFIES 2 -#define PSCHED_CPU 3 - -#define PSCHED_CLOCK_SOURCE PSCHED_JIFFIES - #include #include #include @@ -179,25 +173,19 @@ The reason is that, when it is not the same thing as gettimeofday, it returns invalid timestamp, which is not updated, when net_bh is active. - - So, use PSCHED_CLOCK_SOURCE = PSCHED_CPU on alpha and pentiums - with rtdsc. And PSCHED_JIFFIES on all other architectures, including [34]86 - and pentiums without rtdsc. - You can use PSCHED_GETTIMEOFDAY on another architectures, - which have fast and precise clock source, but it is too expensive. */ /* General note about internal clock. Any clock source returns time intervals, measured in units - close to 1usec. With source PSCHED_GETTIMEOFDAY it is precisely + close to 1usec. With source CONFIG_NET_SCH_CLK_GETTIMEOFDAY it is precisely microseconds, otherwise something close but different chosen to minimize arithmetic cost. Ratio usec/internal untis in form nominator/denominator may be read from /proc/net/psched. */ -#if PSCHED_CLOCK_SOURCE == PSCHED_GETTIMEOFDAY +#ifdef CONFIG_NET_SCH_CLK_GETTIMEOFDAY typedef struct timeval psched_time_t; typedef long psched_tdiff_t; @@ -206,12 +194,12 @@ #define PSCHED_US2JIFFIE(usecs) (((usecs)+(1000000/HZ-1))/(1000000/HZ)) #define PSCHED_JIFFIE2US(delay) ((delay)*(1000000/HZ)) -#else /* PSCHED_CLOCK_SOURCE != PSCHED_GETTIMEOFDAY */ +#else /* !CONFIG_NET_SCH_CLK_GETTIMEOFDAY */ typedef u64 psched_time_t; typedef long psched_tdiff_t; -#if PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES +#ifdef CONFIG_NET_SCH_CLK_JIFFIES #if HZ < 96 #define PSCHED_JSCALE 14 @@ -229,7 +217,8 @@ #define PSCHED_US2JIFFIE(delay) (((delay)+(1<>PSCHED_JSCALE) #define PSCHED_JIFFIE2US(delay) ((delay)< extern psched_tdiff_t psched_clock_per_hz; @@ -252,11 +241,11 @@ #define PSCHED_US2JIFFIE(delay) (((delay)+psched_clock_per_hz-1)/psched_clock_per_hz) #define PSCHED_JIFFIE2US(delay) ((delay)*psched_clock_per_hz) -#endif /* PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES */ +#endif /* CONFIG_NET_SCH_CLK_CPU */ -#endif /* PSCHED_CLOCK_SOURCE == PSCHED_GETTIMEOFDAY */ +#endif /* !CONFIG_NET_SCH_CLK_GETTIMEOFDAY */ -#if PSCHED_CLOCK_SOURCE == PSCHED_GETTIMEOFDAY +#ifdef CONFIG_NET_SCH_CLK_GETTIMEOFDAY #define PSCHED_TDIFF(tv1, tv2) \ ({ \ int __delta_sec = (tv1).tv_sec - (tv2).tv_sec; \ @@ -320,7 +309,7 @@ #define PSCHED_AUDIT_TDIFF(t) ({ if ((t) > 2000000) (t) = 2000000; }) -#else +#else /* !CONFIG_NET_SCH_CLK_GETTIMEOFDAY */ #define PSCHED_TDIFF(tv1, tv2) (long)((tv1) - (tv2)) #define PSCHED_TDIFF_SAFE(tv1, tv2, bound) \ @@ -334,7 +323,7 @@ #define PSCHED_IS_PASTPERFECT(t) ((t) == 0) #define PSCHED_AUDIT_TDIFF(t) -#endif +#endif /* !CONFIG_NET_SCH_CLK_GETTIMEOFDAY */ struct tcf_police { diff -Nru a/net/sched/Kconfig b/net/sched/Kconfig --- a/net/sched/Kconfig 2004-07-23 18:59:48 +02:00 +++ b/net/sched/Kconfig 2004-07-23 18:59:48 +02:00 @@ -1,6 +1,61 @@ # # Traffic control configuration. # +choice + prompt "Packet scheduler clock source" + depends on NET_SCHED + default NET_SCH_CLK_JIFFIES + help + Packet schedulers need a monotonic clock that increments at a static + rate. The kernel provides several suitable interfaces, each with + different properties: + + - high resolution (us or better) + - fast to read (minimal locking, no i/o access) + - synchronized on all processors + - handles cpu clock frequency changes + + but nothing provides all of the above. + +config NET_SCH_CLK_JIFFIES + bool "Timer interrupt" + help + Say Y here if you want to use the timer interrupt (jiffies) as clock + source. This clock source is fast, synchronized on all processors and + handles cpu clock frequency changes, but its resolution is too low + for accurate shaping except at very low speed. + +config NET_SCH_CLK_GETTIMEOFDAY + bool "gettimeofday" + help + Say Y here if you want to use gettimeofday as clock source. This clock + source has high resolution, is synchronized on all processors and + handles cpu clock frequency changes, but it is slow. + + Choose this if you need a high resolution clock source but can't use + the CPU's cycle counter. + +config NET_SCH_CLK_CPU + bool "CPU cycle counter" + depends on X86_TSC || X86_64 || ALPHA || SPARC64 || PPC64 || IA64 + help + Say Y here if you want to use the CPU's cycle counter as clock source. + This is a cheap and high resolution clock source, but on some + architectures it is not synchronized on all processors and doesn't + handle cpu clock frequency changes. + + The useable cycle counters are: + + x86/x86_64 - Timestamp Counter + alpha - Cycle Counter + sparc64 - %ticks register + ppc64 - Time base + ia64 - Interval Time Counter + + Choose this if your CPU's cycle counter is working properly. + +endchoice + config NET_SCH_CBQ tristate "CBQ packet scheduler" depends on NET_SCHED diff -Nru a/net/sched/sch_api.c b/net/sched/sch_api.c --- a/net/sched/sch_api.c 2004-07-23 18:59:48 +02:00 +++ b/net/sched/sch_api.c 2004-07-23 18:59:48 +02:00 @@ -1088,7 +1088,7 @@ }; #endif -#if PSCHED_CLOCK_SOURCE == PSCHED_GETTIMEOFDAY +#ifdef CONFIG_NET_SCH_CLK_GETTIMEOFDAY int psched_tod_diff(int delta_sec, int bound) { int delta; @@ -1103,7 +1103,7 @@ EXPORT_SYMBOL(psched_tod_diff); #endif -#if PSCHED_CLOCK_SOURCE == PSCHED_CPU +#ifdef CONFIG_NET_SCH_CLK_CPU psched_tdiff_t psched_clock_per_hz; int psched_clock_scale; EXPORT_SYMBOL(psched_clock_per_hz); @@ -1169,10 +1169,10 @@ { struct rtnetlink_link *link_p; -#if PSCHED_CLOCK_SOURCE == PSCHED_CPU +#ifdef CONFIG_NET_SCH_CLK_CPU if (psched_calibrate_clock() < 0) return -1; -#elif PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES +#elif defined(CONFIG_NET_SCH_CLK_JIFFIES) psched_tick_per_us = HZ< #undef PSCHED_GET_TIME #define PSCHED_GET_TIME(stamp) \ @@ -429,10 +429,10 @@ * ism: (psched_us/byte) << ISM_SHIFT * dx: psched_us * - * Time source resolution - * PSCHED_JIFFIES: for 48<=HZ<=1534 resolution is between 0.63us and 1.27us. - * PSCHED_CPU: resolution is between 0.5us and 1us. - * PSCHED_GETTIMEOFDAY: resolution is exactly 1us. + * Clock source resolution (CONFIG_NET_SCH_CLK_*) + * JIFFIES: for 48<=HZ<=1534 resolution is between 0.63us and 1.27us. + * CPU: resolution is between 0.5us and 1us. + * GETTIMEOFDAY: resolution is exactly 1us. * * sm and ism are scaled in order to keep effective digits. * SM_SHIFT and ISM_SHIFT are selected to keep at least 4 effective diff -Nru a/net/sched/sch_htb.c b/net/sched/sch_htb.c --- a/net/sched/sch_htb.c 2004-07-23 18:59:48 +02:00 +++ b/net/sched/sch_htb.c 2004-07-23 18:59:48 +02:00 @@ -856,8 +856,13 @@ if (net_ratelimit()) printk(KERN_ERR "HTB: bad diff in charge, cl=%X diff=%lX now=%Lu then=%Lu j=%lu\n", cl->classid, diff, +#ifdef CONFIG_NET_SCH_CLK_GETTIMEOFDAY + q->now.tv_sec * 1000000ULL + q->now.tv_usec, + cl->t_c.tv_sec * 1000000ULL + cl->t_c.tv_usec, +#else (unsigned long long) q->now, (unsigned long long) cl->t_c, +#endif q->jiffies); diff = 1000; } @@ -927,8 +932,13 @@ if (net_ratelimit()) printk(KERN_ERR "HTB: bad diff in events, cl=%X diff=%lX now=%Lu then=%Lu j=%lu\n", cl->classid, diff, +#ifdef CONFIG_NET_SCH_CLK_GETTIMEOFDAY + q->now.tv_sec * 1000000ULL + q->now.tv_usec, + cl->t_c.tv_sec * 1000000ULL + cl->t_c.tv_usec, +#else (unsigned long long) q->now, (unsigned long long) cl->t_c, +#endif q->jiffies); diff = 1000; } --------------040608040801010605080705-- From shemminger@osdl.org Fri Jul 23 10:53:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 10:53:46 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NHrfG6019087 for ; Fri, 23 Jul 2004 10:53:41 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6NHrO121560; Fri, 23 Jul 2004 10:53:24 -0700 Date: Fri, 23 Jul 2004 10:53:24 -0700 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040723105324.458aa878@dell_ss3.pdx.osdl.net> In-Reply-To: <41014788.4070301@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7109 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 19:14:48 +0200 Patrick McHardy wrote: > Patrick McHardy wrote: > > I'm pretty sure x86, x86_64, alpha, sparc64, ppc64 and ia64 can > > be used. I'm not sure if the frequency of all ppcs is high enough, > > so I won't add support for them. > > This is the patch for configurable clock source. I've double-checked > the arches, I think all mentioned above work fine. I've taken some text > from Stephen's patch for the help text .. thanks ;) > > Dave, do you want me to provide patches for 2.4 as well ? > > Regards > Patrick > Looks great, glad to see this cleaned up. From hadi@znyx.com Fri Jul 23 12:58:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 12:58:46 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NJwd49024974 for ; Fri, 23 Jul 2004 12:58:40 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072312585104:35122 ; Fri, 23 Jul 2004 12:58:51 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: shemminger@osdl.org, "David S. Miller" , arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <20040723.110007.27520072.yoshfuji@linux-ipv6.org> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> Organization: ZNYX Networks Message-Id: <1090612669.1218.47.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Jul 2004 15:57:49 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 12:58:51 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 12:58:54 PM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id i6NJwd49024974 X-archive-position: 7110 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev On Fri, 2004-07-23 at 11:00, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > > BTW, what's for rcnt etc.? I don't see the point. > > They're not (effectively) used in kernel. It is transported to user space for analysis of how to reorganize hash table optimally. > I'd suggest to remove these things and to maintain the original ABI. > > If rcnt etc. are for other purposes, such as statistics for userspace, > please allocate another structure / interface for it. I could send a separate TLV, i dont think this will resolve the problem of ABI breakage but it will be more of a cleans. Part of the counters i need for analysis is in the key structure. > (And... cheking size is too strict; > we need to relax it to accept old binaries if we add something > at the tail of structure.) A lot of size checks for every structure at both kernel/userspace is needed. Not much is done today as is - which means old binaries may break when modified structures are transported to user space. I think one of the main challenges with the u32 structures is the keys[] table. In the future if we could make that a TLV it would help. We need not just be backward compatible but also forward compatible. I will do some testing when i get back next week to see if current patch breaks anything. cheers, jamal From shemminger@osdl.org Fri Jul 23 13:11:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 13:12:05 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NKBwpi025465 for ; Fri, 23 Jul 2004 13:11:59 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6NKBh113335; Fri, 23 Jul 2004 13:11:43 -0700 Date: Fri, 23 Jul 2004 13:11:42 -0700 From: Stephen Hemminger To: "David S. Miller" , wensong@linux-vs.org Cc: netdev@oss.sgi.com, Rusty Russell Subject: [PATCH 2.6] convert ipvs to module_param Message-Id: <20040723131142.13081ed3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7111 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert IPVS to not use MODULE_PARM. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/ipvs/ip_vs_ftp.c b/net/ipv4/ipvs/ip_vs_ftp.c --- a/net/ipv4/ipvs/ip_vs_ftp.c 2004-07-23 13:04:54 -07:00 +++ b/net/ipv4/ipvs/ip_vs_ftp.c 2004-07-23 13:04:54 -07:00 @@ -25,6 +25,7 @@ */ #include +#include #include #include #include @@ -44,16 +45,17 @@ * First port is set to the default port. */ static int ports[IP_VS_APP_MAX_PORTS] = {21, 0}; +static int ports_c; +module_param_array(ports, int, ports_c, 0); /* * Debug level */ #ifdef CONFIG_IP_VS_DEBUG static int debug=0; -MODULE_PARM(debug, "i"); +module_param(debug, int, 0); #endif -MODULE_PARM(ports, "1-" __MODULE_STRING(IP_VS_APP_MAX_PORTS) "i"); /* Dummy variable */ static int ip_vs_ftp_pasv; From hadi@znyx.com Fri Jul 23 13:25:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 13:25:42 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NKPatU025918 for ; Fri, 23 Jul 2004 13:25:36 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072313254918:35145 ; Fri, 23 Jul 2004 13:25:49 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Stephen Hemminger Cc: YOSHIFUJI Hideaki / ____________ , "David S. Miller" , arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <20040723092111.44b289a9@dell_ss3.pdx.osdl.net> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <20040723092111.44b289a9@dell_ss3.pdx.osdl.net> Organization: ZNYX Networks Message-Id: <1090614331.1220.50.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Jul 2004 16:25:31 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 01:25:49 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 01:25:50 PM, Serialize complete at 07/23/2004 01:25:50 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 7112 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev On Fri, 2004-07-23 at 12:21, Stephen Hemminger wrote: > Looking at the netlink style, wouldn't it make sense to add additional > separate payloads for the new features. This keeps the API the same and > the kernel can easily adapt for new/old values. If things were perfect this is the way to go. Maybe in 2.7 we can start scrubbing some of this issues. cheers, jamal From davem@redhat.com Fri Jul 23 13:34:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 13:35:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NKYu6w026340 for ; Fri, 23 Jul 2004 13:34:59 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6NKYke1015679; Fri, 23 Jul 2004 16:34:46 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6NKYka09048; Fri, 23 Jul 2004 16:34:46 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6NKY8MF024678; Fri, 23 Jul 2004 16:34:08 -0400 Date: Fri, 23 Jul 2004 13:34:28 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Missing unlock in policy timer Message-Id: <20040723133428.5474c751.davem@redhat.com> In-Reply-To: <20040723110626.GA31264@gondor.apana.org.au> References: <20040723110626.GA31264@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7113 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 21:06:26 +1000 Herbert Xu wrote: > This is one of those cases where the cure is worse than the disease :) > I added read locks in the policy timer to close an unlikely race, but > I missed an unlock on the expire path which leads to all sort of weird > things. > > I'll stay away from the timers for a while :) Hehe, applied. Thanks Herbert. From davem@redhat.com Fri Jul 23 13:38:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 13:38:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NKc9JO026644 for ; Fri, 23 Jul 2004 13:38:12 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6NKbte1016511; Fri, 23 Jul 2004 16:37:55 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6NKbta10443; Fri, 23 Jul 2004 16:37:55 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6NKbHkM027073; Fri, 23 Jul 2004 16:37:17 -0400 Date: Fri, 23 Jul 2004 13:37:37 -0700 From: "David S. Miller" To: Herbert Xu Cc: kazunori@miyazawa.org, netdev@oss.sgi.com Subject: Re: [AH6] Disallow mutable bits after AH header Message-Id: <20040723133737.447a9598.davem@redhat.com> In-Reply-To: <20040723135320.GA26000@gondor.apana.org.au> References: <20040723135320.GA26000@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7114 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 23:53:21 +1000 Herbert Xu wrote: > As we discussed before, mutable headers should not be allowed after > the AH header. In fact, this appears to be the intention of RFC 2402. > It is further clarified in section 3.1.1 of > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-07.txt > > This allows us to simplify the code in ah6.c. As a result, this also > fixes the following issues: > > * Dependence on skb->h in ah6_output(). > * Bogus clearing of auth_data of 2nd AH header in ipv6_clear_mutable_options(). Applied, thanks Herbert. From davem@redhat.com Fri Jul 23 13:55:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 13:55:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NKtQWN027219 for ; Fri, 23 Jul 2004 13:55:26 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6NKtIe1020663; Fri, 23 Jul 2004 16:55:18 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6NKtIa16524; Fri, 23 Jul 2004 16:55:18 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6NKse45008250; Fri, 23 Jul 2004 16:54:40 -0400 Date: Fri, 23 Jul 2004 13:54:59 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040723135459.2ee5c42c.davem@redhat.com> In-Reply-To: <41014788.4070301@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7115 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 19:14:48 +0200 Patrick McHardy wrote: > Patrick McHardy wrote: > > I'm pretty sure x86, x86_64, alpha, sparc64, ppc64 and ia64 can > > be used. I'm not sure if the frequency of all ppcs is high enough, > > so I won't add support for them. > > This is the patch for configurable clock source. I've double-checked > the arches, I think all mentioned above work fine. I've taken some text > from Stephen's patch for the help text .. thanks ;) We can't use this stuff on Alpha, it's cycle counter overflows after just 10 minutes. It works very strangely, something like only the lower 32-bits are guarenteed to be continually incrementing. I'm going to apply your patch and delete the Alpha parts. Meanwhile, ping Richard Henderson (rth@redhat.com) or one of the other Alpha experts for me to get confirmation on this stuff. Thanks. From davem@redhat.com Fri Jul 23 13:58:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 13:58:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NKwZVh027524 for ; Fri, 23 Jul 2004 13:58:39 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6NKw3e1021166; Fri, 23 Jul 2004 16:58:03 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6NKw3a17137; Fri, 23 Jul 2004 16:58:03 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6NKvP88011133; Fri, 23 Jul 2004 16:57:25 -0400 Date: Fri, 23 Jul 2004 13:57:44 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040723135744.70ee6d87.davem@redhat.com> In-Reply-To: <41014788.4070301@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7116 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 19:14:48 +0200 Patrick McHardy wrote: > Dave, do you want me to provide patches for 2.4 as well ? Sure, give it a shot. If it gets too ugly I may not take it though, so be warned :-) From davem@redhat.com Fri Jul 23 14:00:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 14:00:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NL0Bm5027829 for ; Fri, 23 Jul 2004 14:00:12 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6NL04e1021558; Fri, 23 Jul 2004 17:00:04 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6NL04a17605; Fri, 23 Jul 2004 17:00:04 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6NKxQTP012627; Fri, 23 Jul 2004 16:59:26 -0400 Date: Fri, 23 Jul 2004 13:59:45 -0700 From: "David S. Miller" To: hadi@znyx.com Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com Subject: Re: [PATCH] pkt_cls.h incompatiables Message-Id: <20040723135945.7f50b02c.davem@redhat.com> In-Reply-To: <1090612669.1218.47.camel@jzny.localdomain> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <1090612669.1218.47.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7117 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev The current 2.6.x tree is obviously busted. Can someone send me a patch soon'ish that does something about it, so that 2.6.8 doesn't go out with things like this? Thanks. From davem@redhat.com Fri Jul 23 14:23:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 14:23:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NLNkkP028494 for ; Fri, 23 Jul 2004 14:23:47 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6NLNae1026454; Fri, 23 Jul 2004 17:23:36 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6NLNaa24680; Fri, 23 Jul 2004 17:23:36 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6NLMvdt031384; Fri, 23 Jul 2004 17:22:58 -0400 Date: Fri, 23 Jul 2004 14:23:17 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: wensong@linux-vs.org, netdev@oss.sgi.com, rusty@rustcorp.com.au Subject: Re: [PATCH 2.6] convert ipvs to module_param Message-Id: <20040723142317.2f0b7587.davem@redhat.com> In-Reply-To: <20040723131142.13081ed3@dell_ss3.pdx.osdl.net> References: <20040723131142.13081ed3@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7118 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Applied, thanks Stephen. From jolt@tuxbox.org Fri Jul 23 14:35:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 14:35:53 -0700 (PDT) Received: from taytron.net (ipx-98-250-190-80.ipxserver.de [80.190.250.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NLZijd028829 for ; Fri, 23 Jul 2004 14:35:45 -0700 Received: from localhost [82.83.130.69] by taytron.net with ESMTP (SMTPD32-8.11) id A41A47E0052; Fri, 23 Jul 2004 23:33:14 +0200 From: Florian Schirmer To: jgarzik@pobox.com Subject: b44: add 47xx support Date: Fri, 23 Jul 2004 23:35:30 +0200 User-Agent: KMail/1.6.1 Cc: pp@ee.oulu.fi, linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_iSYAB8dJI0zLw5S" Message-Id: <200407232335.37809.jolt@tuxbox.org> X-archive-position: 7119 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jolt@tuxbox.org Precedence: bulk X-list: netdev --Boundary-00=_iSYAB8dJI0zLw5S Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, this patch adds support for the BCM47xx device to the b44 driver. Please=20 apply. BTW what happened to the 1GB DMA fix? The SiliconBackplane cores _are_ limi= ted=20 to a 1GB DMA window so we need to take that into account. Any reason why=20 those patches where dropped? Regards, Florian =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAYSlXRF2vHoIlBsRAu+YAKCGzT01hW+yW5SMCbFGOCqx89uIxwCguwZT zeDLpFVyILUSnaYNJe2A4YU=3D =3D6269 =2D----END PGP SIGNATURE----- --Boundary-00=_iSYAB8dJI0zLw5S Content-Type: text/x-diff; charset="us-ascii"; name="b44-47xx.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="b44-47xx.patch" Index: include/linux/pci_ids.h =================================================================== RCS file: /home/cvs/linux/include/linux/pci_ids.h,v retrieving revision 1.124 diff -a -u -p -r1.124 pci_ids.h --- mips/include/linux/pci_ids.h 20 Jul 2004 20:21:26 -0000 1.124 +++ mips/include/linux/pci_ids.h 23 Jul 2004 21:10:45 -0000 @@ -1913,6 +1913,7 @@ #define PCI_DEVICE_ID_BCM4401 0x4401 #define PCI_DEVICE_ID_BCM4401B0 0x4402 #define PCI_DEVICE_ID_BCM4401B1 0x170c +#define PCI_DEVICE_ID_BCM4713 0x4713 #define PCI_VENDOR_ID_ENE 0x1524 #define PCI_DEVICE_ID_ENE_1211 0x1211 Index: drivers/net/b44.c =================================================================== RCS file: /home/cvs/linux/drivers/net/b44.c,v retrieving revision 1.14 diff -a -u -p -r1.14 b44.c --- mips/drivers/net/b44.c 9 Jun 2004 14:12:09 -0000 1.14 +++ mips/drivers/net/b44.c 23 Jul 2004 21:10:47 -0000 @@ -75,7 +75,7 @@ static char version[] __devinitdata = DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n"; MODULE_AUTHOR("David S. Miller (davem@redhat.com)"); -MODULE_DESCRIPTION("Broadcom 4400 10/100 PCI ethernet driver"); +MODULE_DESCRIPTION("Broadcom 4400/47xx 10/100 PCI ethernet driver"); MODULE_LICENSE("GPL"); MODULE_PARM(b44_debug, "i"); MODULE_PARM_DESC(b44_debug, "B44 bitmapped debugging message enable value"); @@ -89,6 +89,8 @@ static struct pci_device_id b44_pci_tbl[ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401B1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4713, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { } /* terminate list with empty entry */ }; @@ -130,41 +132,8 @@ static int b44_wait_bit(struct b44 *bp, * interrupts disabled. */ -#define SBID_SDRAM 0 -#define SBID_PCI_MEM 1 -#define SBID_PCI_CFG 2 -#define SBID_PCI_DMA 3 -#define SBID_SDRAM_SWAPPED 4 -#define SBID_ENUM 5 -#define SBID_REG_SDRAM 6 -#define SBID_REG_ILINE20 7 -#define SBID_REG_EMAC 8 -#define SBID_REG_CODEC 9 -#define SBID_REG_USB 10 -#define SBID_REG_PCI 11 -#define SBID_REG_MIPS 12 -#define SBID_REG_EXTIF 13 -#define SBID_EXTIF 14 -#define SBID_EJTAG 15 -#define SBID_MAX 16 - -static u32 ssb_get_addr(struct b44 *bp, u32 id, u32 instance) -{ - switch (id) { - case SBID_PCI_DMA: - return 0x40000000; - case SBID_ENUM: - return 0x18000000; - case SBID_REG_EMAC: - return 0x18000000; - case SBID_REG_CODEC: - return 0x18001000; - case SBID_REG_PCI: - return 0x18002000; - default: - return 0; - }; -} +#define SB_PCI_DMA 0x40000000 /* Client Mode PCI memory access space (1 GB) */ +#define BCM4400_PCI_CORE_ADDR 0x18002000 /* Address of PCI core on BCM4400 cards */ static u32 ssb_get_core_rev(struct b44 *bp) { @@ -176,8 +145,7 @@ static u32 ssb_pci_setup(struct b44 *bp, u32 bar_orig, pci_rev, val; pci_read_config_dword(bp->pdev, SSB_BAR0_WIN, &bar_orig); - pci_write_config_dword(bp->pdev, SSB_BAR0_WIN, - ssb_get_addr(bp, SBID_REG_PCI, 0)); + pci_write_config_dword(bp->pdev, SSB_BAR0_WIN, BCM4400_PCI_CORE_ADDR); pci_rev = ssb_get_core_rev(bp); val = br32(B44_SBINTVEC); @@ -307,6 +275,9 @@ static int b44_readphy(struct b44 *bp, i { int err; + if (bp->flags & B44_FLAG_NO_PHY) + return 0; + bw32(B44_EMAC_ISTAT, EMAC_INT_MII); bw32(B44_MDIO_DATA, (MDIO_DATA_SB_START | (MDIO_OP_READ << MDIO_DATA_OP_SHIFT) | @@ -321,6 +292,9 @@ static int b44_readphy(struct b44 *bp, i static int b44_writephy(struct b44 *bp, int reg, u32 val) { + if (bp->flags & B44_FLAG_NO_PHY) + return 0; + bw32(B44_EMAC_ISTAT, EMAC_INT_MII); bw32(B44_MDIO_DATA, (MDIO_DATA_SB_START | (MDIO_OP_WRITE << MDIO_DATA_OP_SHIFT) | @@ -359,6 +333,9 @@ static int b44_phy_reset(struct b44 *bp) u32 val; int err; + if (bp->flags & B44_FLAG_NO_PHY) + return 0; + err = b44_writephy(bp, MII_BMCR, BMCR_RESET); if (err) return err; @@ -429,6 +406,9 @@ static int b44_setup_phy(struct b44 *bp) u32 val; int err; + if (bp->flags & B44_FLAG_NO_PHY) + return 0; + if ((err = b44_readphy(bp, B44_MII_ALEDCTRL, &val)) != 0) goto out; if ((err = b44_writephy(bp, B44_MII_ALEDCTRL, @@ -521,6 +501,19 @@ static void b44_check_phy(struct b44 *bp { u32 bmsr, aux; + if (bp->flags & B44_FLAG_NO_PHY) { + bp->flags |= B44_FLAG_100_BASE_T; + bp->flags |= B44_FLAG_FULL_DUPLEX; + if (!netif_carrier_ok(bp->dev)) { + u32 val = br32(B44_TX_CTRL); + val |= TX_CTRL_DUPLEX; + bw32(B44_TX_CTRL, val); + netif_carrier_on(bp->dev); + b44_link_report(bp); + } + return; + } + if (!b44_readphy(bp, MII_BMSR, &bmsr) && !b44_readphy(bp, B44_MII_AUXCTRL, &aux) && (bmsr != 0xffff)) { @@ -1132,18 +1125,28 @@ static void b44_chip_reset(struct b44 *b bw32(B44_DMARX_CTRL, 0); bp->rx_prod = bp->rx_cons = 0; } else { - ssb_pci_setup(bp, (bp->core_unit == 0 ? - SBINTVEC_ENET0 : - SBINTVEC_ENET1)); + if (bp->pdev->device != PCI_DEVICE_ID_BCM4713) + ssb_pci_setup(bp, (bp->core_unit == 0 ? + SBINTVEC_ENET0 : + SBINTVEC_ENET1)); } ssb_core_reset(bp); b44_clear_stats(bp); - /* Make PHY accessible. */ - bw32(B44_MDIO_CTRL, (MDIO_CTRL_PREAMBLE | - (0x0d & MDIO_CTRL_MAXF_MASK))); + if (bp->pdev->device == PCI_DEVICE_ID_BCM4713) { + /* + * BCM47xx boards don't have a PHY. Usually there is a switch + * chip with multiple PHYs conntected to the PHY port. + */ + bp->flags |= B44_FLAG_NO_PHY; + bw32(B44_MDIO_CTRL, 0x94); + } else { + /* Make PHY accessible. */ + bw32(B44_MDIO_CTRL, (MDIO_CTRL_PREAMBLE | + (0x0d & MDIO_CTRL_MAXF_MASK))); + } br32(B44_MDIO_CTRL); if (!(br32(B44_DEVCTRL) & DEVCTRL_IPP)) { @@ -1659,21 +1662,38 @@ static int b44_read_eeprom(struct b44 *b static int __devinit b44_get_invariants(struct b44 *bp) { u8 eeprom[128]; - int err; + int err = 0; + static int instance = 0; - err = b44_read_eeprom(bp, &eeprom[0]); - if (err) - goto out; + if (bp->pdev->device == PCI_DEVICE_ID_BCM4713) { + bp->dev->dev_addr[0] = 0x01; + bp->dev->dev_addr[1] = 0x01; + bp->dev->dev_addr[2] = 0x02; + bp->dev->dev_addr[3] = 0x02; + bp->dev->dev_addr[4] = 0x01; + bp->dev->dev_addr[5] = 0x01 + instance; + + bp->phy_addr = 30; + bp->mdc_port = instance++; + + bp->dma_offset = 0; + } else { + err = b44_read_eeprom(bp, &eeprom[0]); + if (err) + goto out; - bp->dev->dev_addr[0] = eeprom[79]; - bp->dev->dev_addr[1] = eeprom[78]; - bp->dev->dev_addr[2] = eeprom[81]; - bp->dev->dev_addr[3] = eeprom[80]; - bp->dev->dev_addr[4] = eeprom[83]; - bp->dev->dev_addr[5] = eeprom[82]; + bp->dev->dev_addr[0] = eeprom[79]; + bp->dev->dev_addr[1] = eeprom[78]; + bp->dev->dev_addr[2] = eeprom[81]; + bp->dev->dev_addr[3] = eeprom[80]; + bp->dev->dev_addr[4] = eeprom[83]; + bp->dev->dev_addr[5] = eeprom[82]; - bp->phy_addr = eeprom[90] & 0x1f; - bp->mdc_port = (eeprom[90] >> 14) & 0x1; + bp->phy_addr = eeprom[90] & 0x1f; + bp->mdc_port = (eeprom[90] >> 14) & 0x1; + + bp->dma_offset = SB_PCI_DMA; + } /* With this, plus the rx_header prepended to the data by the * hardware, we'll land the ethernet header on a 2-byte boundary. @@ -1683,7 +1703,6 @@ static int __devinit b44_get_invariants( bp->imask = IMASK_DEF; bp->core_unit = ssb_core_unit(bp); - bp->dma_offset = ssb_get_addr(bp, SBID_PCI_DMA, 0); /* XXX - really required? bp->flags |= B44_FLAG_BUGGY_TXPTR; @@ -1818,7 +1837,8 @@ static int __devinit b44_init_one(struct pci_save_state(bp->pdev, bp->pci_cfg_state); - printk(KERN_INFO "%s: Broadcom 4400 10/100BaseT Ethernet ", dev->name); + printk(KERN_INFO "%s: Broadcom %s 10/100BaseT Ethernet ", dev->name, + (pdev->device == PCI_DEVICE_ID_BCM4713) ? "47xx" : "4400"); for (i = 0; i < 6; i++) printk("%2.2x%c", dev->dev_addr[i], i == 5 ? '\n' : ':'); Index: drivers/net/b44.h =================================================================== RCS file: /home/cvs/linux/drivers/net/b44.h,v retrieving revision 1.5 diff -a -u -p -r1.5 b44.h --- mips/drivers/net/b44.h 6 Jun 2004 02:12:45 -0000 1.5 +++ mips/drivers/net/b44.h 23 Jul 2004 21:10:51 -0000 @@ -356,16 +356,6 @@ #define SBIDHIGH_VC_MASK 0xffff0000 /* Vendor Code */ #define SBIDHIGH_VC_SHIFT 16 -#define CORE_CODE_ILINE20 0x801 -#define CORE_CODE_SDRAM 0x803 -#define CORE_CODE_PCI 0x804 -#define CORE_CODE_MIPS 0x805 -#define CORE_CODE_ENET 0x806 -#define CORE_CODE_CODEC 0x807 -#define CORE_CODE_USB 0x808 -#define CORE_CODE_ILINE100 0x80a -#define CORE_CODE_EXTIF 0x811 - /* SSB PCI config space registers. */ #define SSB_BAR0_WIN 0x80 #define SSB_BAR1_WIN 0x84 @@ -520,6 +510,7 @@ struct b44 { #define B44_FLAG_ADV_100HALF 0x04000000 #define B44_FLAG_ADV_100FULL 0x08000000 #define B44_FLAG_INTERNAL_PHY 0x10000000 +#define B44_FLAG_NO_PHY 0x20000000 u32 rx_offset; --Boundary-00=_iSYAB8dJI0zLw5S-- From kaber@trash.net Fri Jul 23 16:18:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 16:18:11 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NNI3ZL030137 for ; Fri, 23 Jul 2004 16:18:05 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1Bo9Lq-0008VW-00; Sat, 24 Jul 2004 01:21:18 +0200 Message-ID: <41019CDA.9050401@trash.net> Date: Sat, 24 Jul 2004 01:18:50 +0200 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: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> <20040723135459.2ee5c42c.davem@redhat.com> In-Reply-To: <20040723135459.2ee5c42c.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7120 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 David S. Miller wrote: > We can't use this stuff on Alpha, it's cycle counter overflows after > just 10 minutes. It works very strangely, something like only the > lower 32-bits are guarenteed to be continually incrementing. The code (although racy) can handle 32-bit cycle counters. get_cycles() on alpha returns a 32-bit value, so psched_tick calls PSCHED_GET_TIME to adjust psched_time_base once a second. It is basically the same as before. This is the second condition for this too work, besides get_cycles() incrementing at >1MHz, it needs to return either a 32-bit value and really use the full 32 bit or return something bigger, which is assumed not to overflow. Alpha seems to satisfy both conditions. > I'm going to apply your patch and delete the Alpha parts. > Meanwhile, ping Richard Henderson (rth@redhat.com) or one > of the other Alpha experts for me to get confirmation on > this stuff. Even better. Regards Patrick From kaber@trash.net Fri Jul 23 16:20:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 16:20:31 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6NNKNuE001047 for ; Fri, 23 Jul 2004 16:20:26 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1Bo9O6-00007E-00; Sat, 24 Jul 2004 01:23:38 +0200 Message-ID: <41019D66.1060209@trash.net> Date: Sat, 24 Jul 2004 01:21:10 +0200 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: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> <20040723135744.70ee6d87.davem@redhat.com> In-Reply-To: <20040723135744.70ee6d87.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7121 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 David S. Miller wrote: > On Fri, 23 Jul 2004 19:14:48 +0200 > Patrick McHardy wrote: > > >>Dave, do you want me to provide patches for 2.4 as well ? > > > Sure, give it a shot. If it gets too ugly I may not take > it though, so be warned :-) > I've tried it before, IIRC the 2.4 config system doesn't allow to express this nicely, so it probably will get ugly. I'm going to try, but just throw it away if it gets too ugly .. Regards Patrick From sri@us.ibm.com Fri Jul 23 17:18:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 17:18:47 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6O0ITVO001936 for ; Fri, 23 Jul 2004 17:18:36 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6O0IDmi458098; Fri, 23 Jul 2004 20:18:13 -0400 Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6O0JMha103770; Fri, 23 Jul 2004 20:19:23 -0400 Date: Fri, 23 Jul 2004 17:18:11 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@redhat.com cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [BK PATCH] 2.6 SCTP updates Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Dave, Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work to get the following SCTP updates to 2.6.8-rc2. Thanks Sridhar # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/07/23 16:41:31-07:00 sri@us.ibm.com # [SCTP] Mark chunks as ineligible for fast retransmit after they are # retransmitted. Also mark any chunks that could not be fit in the # PMTU sized packet as ineligible for fast retransmit. # # Signed-off-by: Sridhar Samudrala # # net/sctp/outqueue.c # # ChangeSet # 2004/07/22 23:22:01-07:00 sri@us.ibm.com # [SCTP] Fix missing '+' in the computation of sack chunk size in # sctp_sm_pull_sack(). # # Signed-off-by: Jorge Hernandez # Signed-off-by: Sridhar Samudrala # # net/sctp/sm_statefuns.c # # ChangeSet # 2004/07/22 23:18:24-07:00 sri@us.ibm.com # [SCTP] Use idr_get_new_above() with a starting id of 1 to avoid returning # an associd of 0. # # Signed-off-by: Sridhar Samudrala # # net/sctp/sm_make_chunk.c # # ChangeSet # 2004/07/22 23:15:55-07:00 sri@us.ibm.com # [SCTP] Fix issues with handling stale cookie error over multihoming # associations. # # Signed-off-by: Jorge Hernandez # Signed-off-by: Sridhar Samudrala # # net/sctp/sm_statefuns.c # net/sctp/sm_sideeffect.c # include/net/sctp/command.h # # ChangeSet # 2004/07/22 23:13:05-07:00 sri@us.ibm.com # [SCTP] Fix data not being delivered to user in SHUTDOWN_SENT state. # # Also cleaned up sctp_sf_eat_data_6_2() and sctp_sf_eat_data_fast_4_4() # as they have a lot of common code. # # Signed-off-by: Jorge Hernandez # Signed-off-by: Sridhar Samudrala # # net/sctp/sm_statefuns.c # net/sctp/associola.c # include/net/sctp/sm.h # include/net/sctp/constants.h # # ChangeSet # 2004/07/22 23:09:04-07:00 sri@us.ibm.com # [SCTP] Set/Get default SCTP_PEER_ADDR_PARAMS for endpoint when associd # and peer address are 0. # # Signed-off-by: Anand R. Setlur # Signed-off-by: Sridhar Samudrala # # net/sctp/socket.c # diff -Nru a/include/net/sctp/command.h b/include/net/sctp/command.h --- a/include/net/sctp/command.h 2004-07-23 17:08:07 -07:00 +++ b/include/net/sctp/command.h 2004-07-23 17:08:07 -07:00 @@ -94,6 +94,9 @@ SCTP_CMD_REPORT_FWDTSN, /* Report new cumulative TSN Ack. */ SCTP_CMD_PROCESS_FWDTSN, /* Skips were reported, so process further. */ SCTP_CMD_CLEAR_INIT_TAG, /* Clears association peer's inittag. */ + SCTP_CMD_DEL_NON_PRIMARY, /* Removes non-primary peer transports. */ + SCTP_CMD_T3_RTX_TIMERS_STOP, /* Stops T3-rtx pending timers */ + SCTP_CMD_FORCE_PRIM_RETRAN, /* Forces retrans. over primary path. */ SCTP_CMD_LAST } sctp_verb_t; diff -Nru a/include/net/sctp/constants.h b/include/net/sctp/constants.h --- a/include/net/sctp/constants.h 2004-07-23 17:08:07 -07:00 +++ b/include/net/sctp/constants.h 2004-07-23 17:08:07 -07:00 @@ -175,6 +175,10 @@ SCTP_IERROR_BAD_TAG, SCTP_IERROR_BIG_GAP, SCTP_IERROR_DUP_TSN, + SCTP_IERROR_HIGH_TSN, + SCTP_IERROR_IGNORE_TSN, + SCTP_IERROR_NO_DATA, + SCTP_IERROR_BAD_STREAM, } sctp_ierror_t; diff -Nru a/include/net/sctp/sm.h b/include/net/sctp/sm.h --- a/include/net/sctp/sm.h 2004-07-23 17:08:07 -07:00 +++ b/include/net/sctp/sm.h 2004-07-23 17:08:07 -07:00 @@ -322,6 +322,9 @@ const struct sctp_chunk *chunk, sctp_cmd_seq_t *commands, struct sctp_chunk *err_chunk); +int sctp_eat_data(const struct sctp_association *asoc, + struct sctp_chunk *chunk, + sctp_cmd_seq_t *commands); /* 3rd level prototypes */ __u32 sctp_generate_tag(const struct sctp_endpoint *); diff -Nru a/net/sctp/associola.c b/net/sctp/associola.c --- a/net/sctp/associola.c 2004-07-23 17:08:07 -07:00 +++ b/net/sctp/associola.c 2004-07-23 17:08:07 -07:00 @@ -1093,6 +1093,7 @@ case SCTP_STATE_ESTABLISHED: case SCTP_STATE_SHUTDOWN_PENDING: case SCTP_STATE_SHUTDOWN_RECEIVED: + case SCTP_STATE_SHUTDOWN_SENT: if ((asoc->rwnd > asoc->a_rwnd) && ((asoc->rwnd - asoc->a_rwnd) >= min_t(__u32, (asoc->base.sk->sk_rcvbuf >> 1), asoc->pmtu))) diff -Nru a/net/sctp/outqueue.c b/net/sctp/outqueue.c --- a/net/sctp/outqueue.c 2004-07-23 17:08:07 -07:00 +++ b/net/sctp/outqueue.c 2004-07-23 17:08:07 -07:00 @@ -525,10 +525,10 @@ int rtx_timeout, int *start_timer) { struct list_head *lqueue; - struct list_head *lchunk; + struct list_head *lchunk, *lchunk1; struct sctp_transport *transport = pkt->transport; sctp_xmit_t status; - struct sctp_chunk *chunk; + struct sctp_chunk *chunk, *chunk1; struct sctp_association *asoc; int error = 0; @@ -615,6 +615,12 @@ * the transmitted list. */ list_add_tail(lchunk, &transport->transmitted); + + /* Mark the chunk as ineligible for fast retransmit + * after it is retransmitted. + */ + chunk->fast_retransmit = 0; + *start_timer = 1; q->empty = 0; @@ -622,6 +628,18 @@ lchunk = sctp_list_dequeue(lqueue); break; }; + + /* If we are here due to a retransmit timeout or a fast + * retransmit and if there are any chunks left in the retransmit + * queue that could not fit in the PMTU sized packet, they need * to be marked as ineligible for a subsequent fast retransmit. + */ + if (rtx_timeout && !lchunk) { + list_for_each(lchunk1, lqueue) { + chunk1 = list_entry(lchunk1, struct sctp_chunk, + transmitted_list); + chunk1->fast_retransmit = 0; + } + } } return error; diff -Nru a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c --- a/net/sctp/sm_make_chunk.c 2004-07-23 17:08:07 -07:00 +++ b/net/sctp/sm_make_chunk.c 2004-07-23 17:08:07 -07:00 @@ -1846,9 +1846,8 @@ if (unlikely(!idr_pre_get(&sctp_assocs_id, gfp))) goto clean_up; spin_lock_bh(&sctp_assocs_id_lock); - error = idr_get_new(&sctp_assocs_id, - (void *)asoc, - &assoc_id); + error = idr_get_new_above(&sctp_assocs_id, (void *)asoc, 1, + &assoc_id); spin_unlock_bh(&sctp_assocs_id_lock); if (error == -EAGAIN) goto retry; diff -Nru a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c --- a/net/sctp/sm_sideeffect.c 2004-07-23 17:08:07 -07:00 +++ b/net/sctp/sm_sideeffect.c 2004-07-23 17:08:07 -07:00 @@ -529,6 +529,23 @@ } } +/* Helper function to stop any pending T3-RTX timers */ +static void sctp_cmd_t3_rtx_timers_stop(sctp_cmd_seq_t *cmds, + struct sctp_association *asoc) +{ + struct sctp_transport *t; + struct list_head *pos; + + list_for_each(pos, &asoc->peer.transport_addr_list) { + t = list_entry(pos, struct sctp_transport, transports); + if (timer_pending(&t->T3_rtx_timer) && + del_timer(&t->T3_rtx_timer)) { + sctp_transport_put(t); + } + } +} + + /* Helper function to update the heartbeat timer. */ static void sctp_cmd_hb_timer_update(sctp_cmd_seq_t *cmds, struct sctp_association *asoc, @@ -749,6 +766,26 @@ return; } +/* Helper function to remove the association non-primary peer + * transports. + */ +static void sctp_cmd_del_non_primary(struct sctp_association *asoc) +{ + struct sctp_transport *t; + struct list_head *pos; + struct list_head *temp; + + list_for_each_safe(pos, temp, &asoc->peer.transport_addr_list) { + t = list_entry(pos, struct sctp_transport, transports); + if (!sctp_cmp_addr_exact(&t->ipaddr, + &asoc->peer.primary_addr)) { + sctp_assoc_del_peer(asoc, &t->ipaddr); + } + } + + return; +} + /* These three macros allow us to pull the debugging code out of the * main flow of sctp_do_sm() to keep attention focused on the real * functionality there. @@ -1048,6 +1085,27 @@ if (cmd->obj.ptr) sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(cmd->obj.ptr)); + + /* FIXME - Eventually come up with a cleaner way to + * enabling COOKIE-ECHO + DATA bundling during + * multihoming stale cookie scenarios, the following + * command plays with asoc->peer.retran_path to + * avoid the problem of sending the COOKIE-ECHO and + * DATA in different paths, which could result + * in the association being ABORTed if the DATA chunk + * is processed first by the server. Checking the + * init error counter simply causes this command + * to be executed only during failed attempts of + * association establishment. + */ + if ((asoc->peer.retran_path != + asoc->peer.primary_path) && + (asoc->counters[SCTP_COUNTER_INIT_ERROR] > 0)) { + sctp_add_cmd_sf(commands, + SCTP_CMD_FORCE_PRIM_RETRAN, + SCTP_NULL()); + } + break; case SCTP_CMD_GEN_SHUTDOWN: @@ -1281,6 +1339,19 @@ break; case SCTP_CMD_CLEAR_INIT_TAG: asoc->peer.i.init_tag = 0; + break; + case SCTP_CMD_DEL_NON_PRIMARY: + sctp_cmd_del_non_primary(asoc); + break; + case SCTP_CMD_T3_RTX_TIMERS_STOP: + sctp_cmd_t3_rtx_timers_stop(commands, asoc); + break; + case SCTP_CMD_FORCE_PRIM_RETRAN: + t = asoc->peer.retran_path; + asoc->peer.retran_path = asoc->peer.primary_path; + error = sctp_outq_uncork(&asoc->outqueue); + local_cork = 0; + asoc->peer.retran_path = t; break; default: printk(KERN_WARNING "Impossible command: %u, %p\n", diff -Nru a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c --- a/net/sctp/sm_statefuns.c 2004-07-23 17:08:07 -07:00 +++ b/net/sctp/sm_statefuns.c 2004-07-23 17:08:07 -07:00 @@ -472,8 +472,6 @@ */ sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP, SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT)); - sctp_add_cmd_sf(commands, SCTP_CMD_COUNTER_RESET, - SCTP_COUNTER(SCTP_COUNTER_INIT_ERROR)); sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START, SCTP_TO(SCTP_EVENT_TIMEOUT_T1_COOKIE)); sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE, @@ -674,6 +672,15 @@ if (!sctp_vtag_verify(chunk, asoc)) return sctp_sf_pdiscard(ep, asoc, type, arg, commands); + /* Reset init error count upon receipt of COOKIE-ACK, + * to avoid problems with the managemement of this + * counter in stale cookie situations when a transition back + * from the COOKIE-ECHOED state to the COOKIE-WAIT + * state is performed. + */ + sctp_add_cmd_sf(commands, SCTP_CMD_COUNTER_RESET, + SCTP_COUNTER(SCTP_COUNTER_INIT_ERROR)); + /* RFC 2960 5.1 Normal Establishment of an Association * * E) Upon reception of the COOKIE ACK, endpoint "A" will move @@ -1872,8 +1879,6 @@ time_t stale; sctp_cookie_preserve_param_t bht; sctp_errhdr_t *err; - struct list_head *pos; - struct sctp_transport *t; struct sctp_chunk *reply; struct sctp_bind_addr *bp; int attempts; @@ -1920,20 +1925,27 @@ /* Clear peer's init_tag cached in assoc as we are sending a new INIT */ sctp_add_cmd_sf(commands, SCTP_CMD_CLEAR_INIT_TAG, SCTP_NULL()); + /* Stop pending T3-rtx and heartbeat timers */ + sctp_add_cmd_sf(commands, SCTP_CMD_T3_RTX_TIMERS_STOP, SCTP_NULL()); + sctp_add_cmd_sf(commands, SCTP_CMD_HB_TIMERS_STOP, SCTP_NULL()); + + /* Delete non-primary peer ip addresses since we are transitioning + * back to the COOKIE-WAIT state + */ + sctp_add_cmd_sf(commands, SCTP_CMD_DEL_NON_PRIMARY, SCTP_NULL()); + + /* If we've sent any data bundled with COOKIE-ECHO we will need to + * resend + */ + sctp_add_cmd_sf(commands, SCTP_CMD_RETRAN, + SCTP_TRANSPORT(asoc->peer.primary_path)); + /* Cast away the const modifier, as we want to just * rerun it through as a sideffect. */ sctp_add_cmd_sf(commands, SCTP_CMD_COUNTER_INC, SCTP_COUNTER(SCTP_COUNTER_INIT_ERROR)); - /* If we've sent any data bundled with COOKIE-ECHO we need to - * resend. - */ - list_for_each(pos, &asoc->peer.transport_addr_list) { - t = list_entry(pos, struct sctp_transport, transports); - sctp_add_cmd_sf(commands, SCTP_CMD_RETRAN, SCTP_TRANSPORT(t)); - } - sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP, SCTP_TO(SCTP_EVENT_TIMEOUT_T1_COOKIE)); sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE, @@ -2321,12 +2333,7 @@ sctp_cmd_seq_t *commands) { struct sctp_chunk *chunk = arg; - sctp_datahdr_t *data_hdr; - struct sctp_chunk *err; - size_t datalen; - sctp_verb_t deliver; - int tmp; - __u32 tsn; + int error; if (!sctp_vtag_verify(chunk, asoc)) { sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG, @@ -2334,158 +2341,22 @@ return sctp_sf_pdiscard(ep, asoc, type, arg, commands); } - data_hdr = chunk->subh.data_hdr = (sctp_datahdr_t *)chunk->skb->data; - skb_pull(chunk->skb, sizeof(sctp_datahdr_t)); - - tsn = ntohl(data_hdr->tsn); - SCTP_DEBUG_PRINTK("eat_data: TSN 0x%x.\n", tsn); - - /* ASSERT: Now skb->data is really the user data. */ - - /* Process ECN based congestion. - * - * Since the chunk structure is reused for all chunks within - * a packet, we use ecn_ce_done to track if we've already - * done CE processing for this packet. - * - * We need to do ECN processing even if we plan to discard the - * chunk later. - */ - - if (!chunk->ecn_ce_done) { - struct sctp_af *af; - chunk->ecn_ce_done = 1; - - af = sctp_get_af_specific( - ipver2af(chunk->skb->nh.iph->version)); - - if (af && af->is_ce(chunk->skb) && asoc->peer.ecn_capable) { - /* Do real work as sideffect. */ - sctp_add_cmd_sf(commands, SCTP_CMD_ECN_CE, - SCTP_U32(tsn)); - } - } - - tmp = sctp_tsnmap_check(&asoc->peer.tsn_map, tsn); - if (tmp < 0) { - /* The TSN is too high--silently discard the chunk and - * count on it getting retransmitted later. - */ + error = sctp_eat_data(asoc, chunk, commands ); + switch (error) { + case SCTP_IERROR_NO_ERROR: + break; + case SCTP_IERROR_HIGH_TSN: + case SCTP_IERROR_BAD_STREAM: goto discard_noforce; - } else if (tmp > 0) { - /* This is a duplicate. Record it. */ - sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_DUP, SCTP_U32(tsn)); + case SCTP_IERROR_DUP_TSN: + case SCTP_IERROR_IGNORE_TSN: goto discard_force; + case SCTP_IERROR_NO_DATA: + goto consume; + default: + BUG(); } - /* This is a new TSN. */ - - /* Discard if there is no room in the receive window. - * Actually, allow a little bit of overflow (up to a MTU). - */ - datalen = ntohs(chunk->chunk_hdr->length); - datalen -= sizeof(sctp_data_chunk_t); - - deliver = SCTP_CMD_CHUNK_ULP; - - /* Think about partial delivery. */ - if ((datalen >= asoc->rwnd) && (!asoc->ulpq.pd_mode)) { - - /* Even if we don't accept this chunk there is - * memory pressure. - */ - sctp_add_cmd_sf(commands, SCTP_CMD_PART_DELIVER, SCTP_NULL()); - } - - /* Spill over rwnd a little bit. Note: While allowed, this spill over - * seems a bit troublesome in that frag_point varies based on - * PMTU. In cases, such as loopback, this might be a rather - * large spill over. - */ - if (!asoc->rwnd || asoc->rwnd_over || - (datalen > asoc->rwnd + asoc->frag_point)) { - - /* If this is the next TSN, consider reneging to make - * room. Note: Playing nice with a confused sender. A - * malicious sender can still eat up all our buffer - * space and in the future we may want to detect and - * do more drastic reneging. - */ - if (sctp_tsnmap_has_gap(&asoc->peer.tsn_map) && - (sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + 1) == tsn) { - SCTP_DEBUG_PRINTK("Reneging for tsn:%u\n", tsn); - deliver = SCTP_CMD_RENEGE; - } else { - SCTP_DEBUG_PRINTK("Discard tsn: %u len: %Zd, " - "rwnd: %d\n", tsn, datalen, - asoc->rwnd); - goto discard_force; - } - } - - /* - * Section 3.3.10.9 No User Data (9) - * - * Cause of error - * --------------- - * No User Data: This error cause is returned to the originator of a - * DATA chunk if a received DATA chunk has no user data. - */ - if (unlikely(0 == datalen)) { - err = sctp_make_abort_no_data(asoc, chunk, tsn); - if (err) { - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, - SCTP_CHUNK(err)); - } - /* We are going to ABORT, so we might as well stop - * processing the rest of the chunks in the packet. - */ - sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET,SCTP_NULL()); - sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED, - SCTP_U32(SCTP_ERROR_NO_DATA)); - SCTP_INC_STATS(SctpAborteds); - SCTP_DEC_STATS(SctpCurrEstab); - return SCTP_DISPOSITION_CONSUME; - } - - /* If definately accepting the DATA chunk, record its TSN, otherwise - * wait for renege processing. - */ - if (SCTP_CMD_CHUNK_ULP == deliver) - sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN, SCTP_U32(tsn)); - - /* Note: Some chunks may get overcounted (if we drop) or overcounted - * if we renege and the chunk arrives again. - */ - if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) - SCTP_INC_STATS(SctpInUnorderChunks); - else - SCTP_INC_STATS(SctpInOrderChunks); - - /* RFC 2960 6.5 Stream Identifier and Stream Sequence Number - * - * If an endpoint receive a DATA chunk with an invalid stream - * identifier, it shall acknowledge the reception of the DATA chunk - * following the normal procedure, immediately send an ERROR chunk - * with cause set to "Invalid Stream Identifier" (See Section 3.3.10) - * and discard the DATA chunk. - */ - if (ntohs(data_hdr->stream) >= asoc->c.sinit_max_instreams) { - err = sctp_make_op_error(asoc, chunk, SCTP_ERROR_INV_STRM, - &data_hdr->stream, - sizeof(data_hdr->stream)); - if (err) - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, - SCTP_CHUNK(err)); - goto discard_noforce; - } - - /* Send the data up to the user. Note: Schedule the - * SCTP_CMD_CHUNK_ULP cmd before the SCTP_CMD_GEN_SACK, as the SACK - * chunk needs the updated rwnd. - */ - sctp_add_cmd_sf(commands, deliver, SCTP_CHUNK(chunk)); - if (asoc->autoclose) { sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART, SCTP_TO(SCTP_EVENT_TIMEOUT_AUTOCLOSE)); @@ -2551,6 +2422,9 @@ SCTP_TO(SCTP_EVENT_TIMEOUT_SACK)); } return SCTP_DISPOSITION_DISCARD; +consume: + return SCTP_DISPOSITION_CONSUME; + } /* @@ -2576,11 +2450,7 @@ sctp_cmd_seq_t *commands) { struct sctp_chunk *chunk = arg; - sctp_datahdr_t *data_hdr; - struct sctp_chunk *err; - size_t datalen; - int tmp; - __u32 tsn; + int error; if (!sctp_vtag_verify(chunk, asoc)) { sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG, @@ -2588,110 +2458,23 @@ return sctp_sf_pdiscard(ep, asoc, type, arg, commands); } - data_hdr = chunk->subh.data_hdr = (sctp_datahdr_t *) chunk->skb->data; - skb_pull(chunk->skb, sizeof(sctp_datahdr_t)); - - tsn = ntohl(data_hdr->tsn); - - SCTP_DEBUG_PRINTK("eat_data: TSN 0x%x.\n", tsn); - - /* ASSERT: Now skb->data is really the user data. */ - - /* Process ECN based congestion. - * - * Since the chunk structure is reused for all chunks within - * a packet, we use ecn_ce_done to track if we've already - * done CE processing for this packet. - * - * We need to do ECN processing even if we plan to discard the - * chunk later. - */ - if (!chunk->ecn_ce_done) { - struct sctp_af *af; - chunk->ecn_ce_done = 1; - - af = sctp_get_af_specific( - ipver2af(chunk->skb->nh.iph->version)); - - if (af && af->is_ce(chunk->skb) && asoc->peer.ecn_capable) { - /* Do real work as sideffect. */ - sctp_add_cmd_sf(commands, SCTP_CMD_ECN_CE, - SCTP_U32(tsn)); - } - } - - tmp = sctp_tsnmap_check(&asoc->peer.tsn_map, tsn); - if (tmp < 0) { - /* The TSN is too high--silently discard the chunk and - * count on it getting retransmitted later. - */ - goto gen_shutdown; - } else if (tmp > 0) { - /* This is a duplicate. Record it. */ - sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_DUP, SCTP_U32(tsn)); - goto gen_shutdown; - } - - /* This is a new TSN. */ - datalen = ntohs(chunk->chunk_hdr->length); - datalen -= sizeof(sctp_data_chunk_t); - - /* - * Section 3.3.10.9 No User Data (9) - * - * Cause of error - * --------------- - * No User Data: This error cause is returned to the originator of a - * DATA chunk if a received DATA chunk has no user data. - */ - if (unlikely(0 == datalen)) { - err = sctp_make_abort_no_data(asoc, chunk, tsn); - if (err) { - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, - SCTP_CHUNK(err)); - } - /* We are going to ABORT, so we might as well stop - * processing the rest of the chunks in the packet. - */ - sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET,SCTP_NULL()); - sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED, - SCTP_U32(SCTP_ERROR_NO_DATA)); - SCTP_INC_STATS(SctpAborteds); - SCTP_DEC_STATS(SctpCurrEstab); - return SCTP_DISPOSITION_CONSUME; - } - - /* We are accepting this DATA chunk. */ - - /* Record the fact that we have received this TSN. */ - sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN, SCTP_U32(tsn)); - - if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) - SCTP_INC_STATS(SctpInUnorderChunks); - else - SCTP_INC_STATS(SctpInOrderChunks); - - /* RFC 2960 6.5 Stream Identifier and Stream Sequence Number - * - * If an endpoint receive a DATA chunk with an invalid stream - * identifier, it shall acknowledge the reception of the DATA chunk - * following the normal procedure, immediately send an ERROR chunk - * with cause set to "Invalid Stream Identifier" (See Section 3.3.10) - * and discard the DATA chunk. - */ - if (ntohs(data_hdr->stream) >= asoc->c.sinit_max_instreams) { - err = sctp_make_op_error(asoc, chunk, SCTP_ERROR_INV_STRM, - &data_hdr->stream, - sizeof(data_hdr->stream)); - if (err) { - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, - SCTP_CHUNK(err)); - } + error = sctp_eat_data(asoc, chunk, commands ); + switch (error) { + case SCTP_IERROR_NO_ERROR: + case SCTP_IERROR_HIGH_TSN: + case SCTP_IERROR_DUP_TSN: + case SCTP_IERROR_IGNORE_TSN: + case SCTP_IERROR_BAD_STREAM: + break; + case SCTP_IERROR_NO_DATA: + goto consume; + default: + BUG(); } /* Go a head and force a SACK, since we are shutting down. */ -gen_shutdown: + /* Implementor's Guide. * * While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately @@ -2707,6 +2490,8 @@ sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART, SCTP_TO(SCTP_EVENT_TIMEOUT_T2_SHUTDOWN)); } + +consume: return SCTP_DISPOSITION_CONSUME; } @@ -4709,7 +4494,7 @@ num_blocks = ntohs(sack->num_gap_ack_blocks); num_dup_tsns = ntohs(sack->num_dup_tsns); len = sizeof(struct sctp_sackhdr); - len = (num_blocks + num_dup_tsns) * sizeof(__u32); + len += (num_blocks + num_dup_tsns) * sizeof(__u32); if (len > chunk->skb->len) return NULL; @@ -4847,4 +4632,172 @@ } else sctp_chunk_free (err_chunk); } +} + + +/* Process a data chunk */ +int sctp_eat_data(const struct sctp_association *asoc, + struct sctp_chunk *chunk, + sctp_cmd_seq_t *commands) +{ + sctp_datahdr_t *data_hdr; + struct sctp_chunk *err; + size_t datalen; + sctp_verb_t deliver; + int tmp; + __u32 tsn; + + data_hdr = chunk->subh.data_hdr = (sctp_datahdr_t *)chunk->skb->data; + skb_pull(chunk->skb, sizeof(sctp_datahdr_t)); + + tsn = ntohl(data_hdr->tsn); + SCTP_DEBUG_PRINTK("eat_data: TSN 0x%x.\n", tsn); + + /* ASSERT: Now skb->data is really the user data. */ + + /* Process ECN based congestion. + * + * Since the chunk structure is reused for all chunks within + * a packet, we use ecn_ce_done to track if we've already + * done CE processing for this packet. + * + * We need to do ECN processing even if we plan to discard the + * chunk later. + */ + + if (!chunk->ecn_ce_done) { + struct sctp_af *af; + chunk->ecn_ce_done = 1; + + af = sctp_get_af_specific( + ipver2af(chunk->skb->nh.iph->version)); + + if (af && af->is_ce(chunk->skb) && asoc->peer.ecn_capable) { + /* Do real work as sideffect. */ + sctp_add_cmd_sf(commands, SCTP_CMD_ECN_CE, + SCTP_U32(tsn)); + } + } + + tmp = sctp_tsnmap_check(&asoc->peer.tsn_map, tsn); + if (tmp < 0) { + /* The TSN is too high--silently discard the chunk and + * count on it getting retransmitted later. + */ + return SCTP_IERROR_HIGH_TSN; + } else if (tmp > 0) { + /* This is a duplicate. Record it. */ + sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_DUP, SCTP_U32(tsn)); + return SCTP_IERROR_DUP_TSN; + } + + /* This is a new TSN. */ + + /* Discard if there is no room in the receive window. + * Actually, allow a little bit of overflow (up to a MTU). + */ + datalen = ntohs(chunk->chunk_hdr->length); + datalen -= sizeof(sctp_data_chunk_t); + + deliver = SCTP_CMD_CHUNK_ULP; + + /* Think about partial delivery. */ + if ((datalen >= asoc->rwnd) && (!asoc->ulpq.pd_mode)) { + + /* Even if we don't accept this chunk there is + * memory pressure. + */ + sctp_add_cmd_sf(commands, SCTP_CMD_PART_DELIVER, SCTP_NULL()); + } + + /* Spill over rwnd a little bit. Note: While allowed, this spill over + * seems a bit troublesome in that frag_point varies based on + * PMTU. In cases, such as loopback, this might be a rather + * large spill over. + */ + if (!asoc->rwnd || asoc->rwnd_over || + (datalen > asoc->rwnd + asoc->frag_point)) { + + /* If this is the next TSN, consider reneging to make + * room. Note: Playing nice with a confused sender. A + * malicious sender can still eat up all our buffer + * space and in the future we may want to detect and + * do more drastic reneging. + */ + if (sctp_tsnmap_has_gap(&asoc->peer.tsn_map) && + (sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + 1) == tsn) { + SCTP_DEBUG_PRINTK("Reneging for tsn:%u\n", tsn); + deliver = SCTP_CMD_RENEGE; + } else { + SCTP_DEBUG_PRINTK("Discard tsn: %u len: %Zd, " + "rwnd: %d\n", tsn, datalen, + asoc->rwnd); + return SCTP_IERROR_IGNORE_TSN; + } + } + + /* + * Section 3.3.10.9 No User Data (9) + * + * Cause of error + * --------------- + * No User Data: This error cause is returned to the originator of a + * DATA chunk if a received DATA chunk has no user data. + */ + if (unlikely(0 == datalen)) { + err = sctp_make_abort_no_data(asoc, chunk, tsn); + if (err) { + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, + SCTP_CHUNK(err)); + } + /* We are going to ABORT, so we might as well stop + * processing the rest of the chunks in the packet. + */ + sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET,SCTP_NULL()); + sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED, + SCTP_U32(SCTP_ERROR_NO_DATA)); + SCTP_INC_STATS(SctpAborteds); + SCTP_DEC_STATS(SctpCurrEstab); + return SCTP_IERROR_NO_DATA; + } + + /* If definately accepting the DATA chunk, record its TSN, otherwise + * wait for renege processing. + */ + if (SCTP_CMD_CHUNK_ULP == deliver) + sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN, SCTP_U32(tsn)); + + /* Note: Some chunks may get overcounted (if we drop) or overcounted + * if we renege and the chunk arrives again. + */ + if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) + SCTP_INC_STATS(SctpInUnorderChunks); + else + SCTP_INC_STATS(SctpInOrderChunks); + + /* RFC 2960 6.5 Stream Identifier and Stream Sequence Number + * + * If an endpoint receive a DATA chunk with an invalid stream + * identifier, it shall acknowledge the reception of the DATA chunk + * following the normal procedure, immediately send an ERROR chunk + * with cause set to "Invalid Stream Identifier" (See Section 3.3.10) + * and discard the DATA chunk. + */ + if (ntohs(data_hdr->stream) >= asoc->c.sinit_max_instreams) { + err = sctp_make_op_error(asoc, chunk, SCTP_ERROR_INV_STRM, + &data_hdr->stream, + sizeof(data_hdr->stream)); + if (err) + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, + SCTP_CHUNK(err)); + return SCTP_IERROR_BAD_STREAM; + } + + /* Send the data up to the user. Note: Schedule the + * SCTP_CMD_CHUNK_ULP cmd before the SCTP_CMD_GEN_SACK, as the SACK + * chunk needs the updated rwnd. + */ + sctp_add_cmd_sf(commands, deliver, SCTP_CHUNK(chunk)); + + return SCTP_IERROR_NO_ERROR; } diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c 2004-07-23 17:08:07 -07:00 +++ b/net/sctp/socket.c 2004-07-23 17:08:07 -07:00 @@ -1697,6 +1697,32 @@ if (copy_from_user(¶ms, optval, optlen)) return -EFAULT; + /* + * API 7. Socket Options (setting the default value for the endpoint) + * All options that support specific settings on an association by + * filling in either an association id variable or a sockaddr_storage + * SHOULD also support setting of the same value for the entire endpoint + * (i.e. future associations). To accomplish this the following logic is + * used when setting one of these options: + + * c) If neither the sockaddr_storage or association identification is + * set i.e. the sockaddr_storage is set to all 0's (INADDR_ANY) and + * the association identification is 0, the settings are a default + * and to be applied to the endpoint (all future associations). + */ + + /* update default value for endpoint (all future associations) */ + if (!params.spp_assoc_id && + sctp_is_any(( union sctp_addr *)¶ms.spp_address)) { + if (params.spp_hbinterval) + sctp_sk(sk)->paddrparam.spp_hbinterval = + params.spp_hbinterval; + if (sctp_max_retrans_path) + sctp_sk(sk)->paddrparam.spp_pathmaxrxt = + params.spp_pathmaxrxt; + return 0; + } + trans = sctp_addr_id2transport(sk, ¶ms.spp_address, params.spp_assoc_id); if (!trans) @@ -2864,6 +2890,17 @@ if (copy_from_user(¶ms, optval, len)) return -EFAULT; + /* If no association id is specified retrieve the default value + * for the endpoint that will be used for all future associations + */ + if (!params.spp_assoc_id && + sctp_is_any(( union sctp_addr *)¶ms.spp_address)) { + params.spp_hbinterval = sctp_sk(sk)->paddrparam.spp_hbinterval; + params.spp_pathmaxrxt = sctp_sk(sk)->paddrparam.spp_pathmaxrxt; + + goto done; + } + trans = sctp_addr_id2transport(sk, ¶ms.spp_address, params.spp_assoc_id); if (!trans) @@ -2883,6 +2920,7 @@ */ params.spp_pathmaxrxt = trans->error_threshold; +done: if (copy_to_user(optval, ¶ms, len)) return -EFAULT; From hadi@znyx.com Fri Jul 23 17:49:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 17:49:25 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6O0nKCq002494 for ; Fri, 23 Jul 2004 17:49:20 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072317493294:35391 ; Fri, 23 Jul 2004 17:49:32 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <20040723135945.7f50b02c.davem@redhat.com> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> Organization: ZNYX Networks Message-Id: <1090630154.1134.6.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Jul 2004 20:49:15 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 05:49:33 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/23/2004 05:49:34 PM, Serialize complete at 07/23/2004 05:49:34 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 7123 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev I will take care of it next week when i get back. If 2.6.8 is coming out before end of next week, i would suggest undoing Stephens patch. The way it was before was backward compatible as long as you dont turn on those features; and those features all have a strong warning not to turn them on unless you a new iproute2;-> And if you turn them on and used my patches to tc all will work just fine ... cheers, jamal On Fri, 2004-07-23 at 16:59, David S. Miller wrote: > The current 2.6.x tree is obviously busted. > > Can someone send me a patch soon'ish that does something > about it, so that 2.6.8 doesn't go et with things > like this? > > Thanks. From yoshfuji@linux-ipv6.org Fri Jul 23 18:42:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 18:42:44 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6O1gZVC003307 for ; Fri, 23 Jul 2004 18:42:35 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6FC6C33CE5; Sat, 24 Jul 2004 10:42:48 +0900 (JST) Date: Fri, 23 Jul 2004 21:42:40 -0400 (EDT) Message-Id: <20040723.214240.76745170.yoshfuji@linux-ipv6.org> To: hadi@znyx.com, davem@redhat.com Cc: shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, hadi@znyx.com Subject: Re: [PATCH] pkt_cls.h incompatiables From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1090630154.1134.6.camel@jzny.localdomain> References: <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7124 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <1090630154.1134.6.camel@jzny.localdomain> (at 23 Jul 2004 20:49:15 -0400), Jamal Hadi Salim says: > I will take care of it next week when i get back. > If 2.6.8 is coming out before end of next week, i would suggest undoing > Stephens patch. I've talked about this with Jamal. I believe it is very important to maintain th original (or traditional) ABI, which has been used in -2.6.7(?). So, I'd rather say, let's remove (or disable) whole thing until we find the way to avoid breaking ABIs. --yoshfuji From herbert@gondor.apana.org.au Fri Jul 23 18:44:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 18:44:42 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6O1iVkm003515 for ; Fri, 23 Jul 2004 18:44:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BoBaF-0000Nc-00; Sat, 24 Jul 2004 11:44:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BoBaB-0001Ww-00; Sat, 24 Jul 2004 11:44:15 +1000 Date: Sat, 24 Jul 2004 11:44:15 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [AH4] Save daddr iff options are present Message-ID: <20040724014415.GA5866@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7125 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is a little optimisation for AH4. When I moved the tunnel code out, I put the daddr copying code on the main path which is unnecessary since daddr is only mutable if IP options are present. This patch moves the saving and restoring of daddr under the check for the existence of IP options. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/ah4.c 1.37 vs edited ===== --- 1.37/net/ipv4/ah4.c 2004-07-12 20:00:21 +10:00 +++ edited/net/ipv4/ah4.c 2004-07-24 11:39:40 +10:00 @@ -73,9 +73,9 @@ iph->tos = top_iph->tos; iph->ttl = top_iph->ttl; iph->frag_off = top_iph->frag_off; - iph->daddr = top_iph->daddr; if (top_iph->ihl != 5) { + iph->daddr = top_iph->daddr; memcpy(iph+1, top_iph+1, top_iph->ihl*4 - sizeof(struct iphdr)); err = ip_clear_mutable_options(top_iph, &top_iph->daddr); if (err) @@ -104,9 +104,10 @@ top_iph->tos = iph->tos; top_iph->ttl = iph->ttl; top_iph->frag_off = iph->frag_off; - top_iph->daddr = iph->daddr; - if (top_iph->ihl != 5) + if (top_iph->ihl != 5) { + top_iph->daddr = iph->daddr; memcpy(top_iph+1, iph+1, top_iph->ihl*4 - sizeof(struct iphdr)); + } ip_send_check(top_iph); --r5Pyd7+fXNt84Ff3-- From herbert@gondor.apana.org.au Fri Jul 23 21:51:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jul 2004 21:51:18 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6O4p7A5009103 for ; Fri, 23 Jul 2004 21:51:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BoEUf-0001Ce-00; Sat, 24 Jul 2004 14:50:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BoEUb-0001sd-00; Sat, 24 Jul 2004 14:50:41 +1000 Date: Sat, 24 Jul 2004 14:50:41 +1000 To: "David S. Miller" , Kazunori Miyazawa , netdev@oss.sgi.com Subject: [AH6] Replace skb by iph in clear_mutable_options Message-ID: <20040724045041.GA7091@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7126 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch replaces the skb argument in ipv6_clear_mutable_options() by an ipv6hdr. Doing so allows us to point skb->nh elsewhere when calling this function. I've also thrown in some obvious clean-ups for that function. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== ah6.c 1.33 vs edited ===== --- 1.33/net/ipv6/ah6.c 2004-07-24 09:54:15 +10:00 +++ edited/ah6.c 2004-07-24 14:39:24 +10:00 @@ -74,49 +74,42 @@ return 0; } -static int ipv6_clear_mutable_options(struct sk_buff *skb, - unsigned int hdr_len) +static int ipv6_clear_mutable_options(struct ipv6hdr *iph, int len) { - u16 offset = sizeof(struct ipv6hdr); - struct ipv6_opt_hdr *exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); - u8 nexthdr = skb->nh.ipv6h->nexthdr; + union { + struct ipv6hdr *iph; + struct ipv6_opt_hdr *opth; + struct ipv6_rt_hdr *rth; + char *raw; + } exthdr = { .iph = iph }; + char *end = exthdr.raw + len; + int nexthdr = iph->nexthdr; - while (offset + 1 <= hdr_len) { + exthdr.iph++; + while (exthdr.raw < end) { switch (nexthdr) { - case NEXTHDR_HOP: - offset += ipv6_optlen(exthdr); - if (!zero_out_mutable_opts(exthdr)) { - LIMIT_NETDEBUG( - printk(KERN_WARNING "overrun hopopts\n")); + case NEXTHDR_DEST: + if (!zero_out_mutable_opts(exthdr.opth)) { + LIMIT_NETDEBUG(printk( + KERN_WARNING "overrun %sopts\n", + nexthdr == NEXTHDR_HOP ? + "hop" : "dest")); return -EINVAL; } - nexthdr = exthdr->nexthdr; - exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); break; case NEXTHDR_ROUTING: - offset += ipv6_optlen(exthdr); - ((struct ipv6_rt_hdr*)exthdr)->segments_left = 0; - nexthdr = exthdr->nexthdr; - exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); - break; - - case NEXTHDR_DEST: - offset += ipv6_optlen(exthdr); - if (!zero_out_mutable_opts(exthdr)) { - LIMIT_NETDEBUG( - printk(KERN_WARNING "overrun destopt\n")); - return -EINVAL; - } - nexthdr = exthdr->nexthdr; - exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); + exthdr.rth->segments_left = 0; break; default : return 0; } + + nexthdr = exthdr.opth->nexthdr; + exthdr.raw += ipv6_optlen(exthdr.opth); } return 0; @@ -175,7 +168,7 @@ (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - err = ipv6_clear_mutable_options(*pskb, hdr_len); + err = ipv6_clear_mutable_options((*pskb)->nh.ipv6h, hdr_len); if (err) goto error_free_iph; @@ -283,7 +276,7 @@ if (!tmp_hdr) goto out; memcpy(tmp_hdr, skb->nh.raw, hdr_len); - if (ipv6_clear_mutable_options(skb, hdr_len)) + if (ipv6_clear_mutable_options(skb->nh.ipv6h, hdr_len)) goto out; skb->nh.ipv6h->priority = 0; skb->nh.ipv6h->flow_lbl[0] = 0; --GvXjxJ+pjyke8COw-- From herbert@gondor.apana.org.au Sat Jul 24 01:37:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 01:37:50 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6O8bcWV016442 for ; Sat, 24 Jul 2004 01:37:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BoI1p-000260-00; Sat, 24 Jul 2004 18:37:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BoI1l-0002Tp-00; Sat, 24 Jul 2004 18:37:09 +1000 Date: Sat, 24 Jul 2004 18:37:09 +1000 To: "David S. Miller" , Kazunori Miyazawa , netdev@oss.sgi.com Subject: [AH6] Rearrange routing headers Message-ID: <20040724083709.GA9416@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7127 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch rearranges the IPv6 routing header so that the destination addresses appear in the order as they would on the destination. This is specified in Appendix A2 of RFC 2402. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/ah6.c 1.34 vs edited ===== --- 1.34/net/ipv6/ah6.c 2004-07-24 14:52:21 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-24 18:35:47 +10:00 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,45 @@ return 0; } +/** + * ipv6_rearrange_rthdr - rearrange IPv6 routing header + * @iph: IPv6 header + * @rthdr: routing header + * + * Rearrange the destination address in @iph and the addresses in @rthdr + * so that they appear in the order they will at the final destination. + * See Appendix A2 of RFC 2402 for details. + */ +static void ipv6_rearrange_rthdr(struct ipv6hdr *iph, struct ipv6_rt_hdr *rthdr) +{ + int segments, segments_left; + struct in6_addr *addrs; + struct in6_addr final_addr; + + segments_left = rthdr->segments_left; + if (segments_left == 0) + return; + rthdr->segments_left = 0; + + /* The value of rthdr->hdrlen has been verified either by the system + * call if it is locally generated, or by ipv6_rthdr_rcv() for incoming + * packets. So we can assume that it is even and that segments is + * greater than or equal to segments_left. + * + * For the same reason we can assume that this option is of type 0. + */ + segments = rthdr->hdrlen >> 1; + + addrs = ((struct rt0_hdr *)rthdr)->addr; + ipv6_addr_copy(&final_addr, addrs + segments - 1); + + addrs += segments - segments_left; + memmove(addrs + 1, addrs, (segments_left - 1) * sizeof(*addrs)); + + ipv6_addr_copy(addrs, &iph->daddr); + ipv6_addr_copy(&iph->daddr, &final_addr); +} + static int ipv6_clear_mutable_options(struct ipv6hdr *iph, int len) { union { @@ -101,7 +141,7 @@ break; case NEXTHDR_ROUTING: - exthdr.rth->segments_left = 0; + ipv6_rearrange_rthdr(iph, exthdr.rth); break; default : --3V7upXqbjpZ4EhLz-- From hadi@znyx.com Sat Jul 24 05:16:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 05:16:52 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OCGi4A026289 for ; Sat, 24 Jul 2004 05:16:44 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072405165599:35942 ; Sat, 24 Jul 2004 05:16:55 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: "David S. Miller" , shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <20040723.214240.76745170.yoshfuji@linux-ipv6.org> References: <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> <20040723.214240.76745170.yoshfuji@linux-ipv6.org> Organization: ZNYX Networks Message-Id: <1090671399.1160.0.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Jul 2004 08:16:39 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/24/2004 05:16:56 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/24/2004 05:16:57 AM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id i6OCGi4A026289 X-archive-position: 7128 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev On Fri, 2004-07-23 at 21:42, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article <1090630154.1134.6.camel@jzny.localdomain> (at 23 Jul 2004 20:49:15 -0400), Jamal Hadi Salim says: > > > I will take care of it next week when i get back. > > If 2.6.8 is coming out before end of next week, i would suggest undoing > > Stephens patch. > > I've talked about this with Jamal. > > I believe it is very important to maintain th original (or > traditional) ABI, which has been used in -2.6.7(?). > > So, I'd rather say, let's remove (or disable) whole thing > until we find the way to avoid breaking ABIs. Just back out Stephens patch for now until i get back. cheers, jamal From mikulas@artax.karlin.mff.cuni.cz Sat Jul 24 06:08:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 06:08:29 -0700 (PDT) Received: from artax.karlin.mff.cuni.cz (postfix@artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OD8NPt027198 for ; Sat, 24 Jul 2004 06:08:24 -0700 Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 17421) id 68C164315; Sat, 24 Jul 2004 15:08:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by artax.karlin.mff.cuni.cz (Postfix) with ESMTP id 6844A420D for ; Sat, 24 Jul 2004 15:08:19 +0200 (CEST) Date: Sat, 24 Jul 2004 15:08:19 +0200 (CEST) From: Mikulas Patocka To: netdev@oss.sgi.com Subject: ICMP breaks TCP connection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7129 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mikulas@artax.karlin.mff.cuni.cz Precedence: bulk X-list: netdev Hi I found that Linux 2.2.16 and 2.4.25 break tcp connection (with no route to host error) after first attempt when received ICMP packet with type 3 and code 1 (ICMP_UNREACH_HOST). RFC1122, section 3.2.2.1 says, that the message MUST be interpreted as hint, not proof of unreachable machine. Mikulas From hadi@cyberus.ca Sat Jul 24 06:34:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 06:34:07 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6ODY2pb027823 for ; Sat, 24 Jul 2004 06:34:02 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072406340866:36001 ; Sat, 24 Jul 2004 06:34:08 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <1090630154.1134.6.camel@jzny.localdomain> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> Organization: jamalopolis Message-Id: <1090675993.1161.11.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Jul 2004 09:33:52 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/24/2004 06:34:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/24/2004 06:34:16 AM, Serialize complete at 07/24/2004 06:34:16 AM Content-Type: multipart/mixed; boundary="=-Wuxvn3vFz2yEmJYKNOxp" X-archive-position: 7130 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 --=-Wuxvn3vFz2yEmJYKNOxp Content-Transfer-Encoding: 7bit Content-Type: text/plain alright heres a patch against the old code(before Stevens patch). Makes the performance counters a separate TLV - a little bit of a pain, but acceptable given its optional. Compiles but hasnt been tested; user space code will have to change. I dont want to touch the policer for now. Dont apply yet, i need to run my regression tests when i get back. In the minimal back out Stephens change. cheers, jamal --=-Wuxvn3vFz2yEmJYKNOxp Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=ols1 Content-Type: text/plain; name=ols1; charset=ISO-8859-1 --- a/include/linux/pkt_cls.h 2004/07/24 12:35:40 1.1 +++ b/include/linux/pkt_cls.h 2004/07/24 12:57:20 @@ -117,17 +117,6 @@ struct tc_police { __u32 index; -#ifdef CONFIG_NET_CLS_ACT - int refcnt; - int bindcnt; -#endif -/* Turned off because it requires new tc - * to work (for now maintain ABI) - * -#ifdef CONFIG_NET_CLS_ACT - __u32 capab; -#endif -*/ int action; #define TC_POLICE_UNSPEC TC_ACT_UNSPEC #define TC_POLICE_OK TC_ACT_OK @@ -140,6 +129,17 @@ __u32 mtu; struct tc_ratespec rate; struct tc_ratespec peakrate; +#ifdef CONFIG_NET_CLS_ACT + int refcnt; + int bindcnt; +#endif +/* Turned off because it requires new tc + * to work (for now maintain ABI) + * +#ifdef CONFIG_NET_CLS_ACT + __u32 capab; +#endif +*/ }; struct tcf_t @@ -195,12 +195,9 @@ TCA_U32_DIVISOR, TCA_U32_SEL, TCA_U32_POLICE, -#ifdef CONFIG_NET_CLS_ACT TCA_U32_ACT, -#endif -#ifdef CONFIG_NET_CLS_IND TCA_U32_INDEV, -#endif + TCA_U32_PCNT, __TCA_U32_MAX }; @@ -212,9 +209,6 @@ __u32 val; int off; int offmask; -#ifdef CONFIG_CLS_U32_PERF - unsigned long kcnt; -#endif }; struct tc_u32_sel @@ -229,13 +223,17 @@ short hoff; __u32 hmask; + struct tc_u32_key keys[0]; +}; + #ifdef CONFIG_CLS_U32_PERF +struct tc_u32_pcnt +{ unsigned long rcnt; unsigned long rhit; -#endif - struct tc_u32_key keys[0]; + unsigned long kcnts[]; }; - +#endif /* Flags */ #define TC_U32_TERMINAL 1 @@ -300,12 +298,8 @@ TCA_FW_UNSPEC, TCA_FW_CLASSID, TCA_FW_POLICE, -#ifdef CONFIG_NET_CLS_IND - TCA_FW_INDEV, -#endif -#ifdef CONFIG_NET_CLS_ACT - TCA_FW_ACT, -#endif + TCA_FW_INDEV, /* used by CONFIG_NET_CLS_IND */ + TCA_FW_ACT, /* used by CONFIG_NET_CLS_ACT */ __TCA_FW_MAX }; --- a/net/sched/cls_u32.c 2004/07/24 12:38:52 1.1 +++ b/net/sched/cls_u32.c 2004/07/24 13:22:29 @@ -76,6 +76,9 @@ struct tcf_result res; struct tc_u_hnode *ht_down; struct tc_u32_sel sel; +#ifdef CONFIG_CLS_U32_PERF + struct tc_u32_pcnt pf; +#endif }; struct tc_u_hnode @@ -120,6 +123,9 @@ int sdepth = 0; int off2 = 0; int sel = 0; +#ifdef CONFIG_CLS_U32_PERF + int j; +#endif int i; next_ht: @@ -130,7 +136,8 @@ struct tc_u32_key *key = n->sel.keys; #ifdef CONFIG_CLS_U32_PERF - n->sel.rcnt +=1; + n->pf.rcnt +=1; + j = 0; #endif for (i = n->sel.nkeys; i>0; i--, key++) { @@ -139,7 +146,8 @@ goto next_knode; } #ifdef CONFIG_CLS_U32_PERF - key->kcnt +=1; + n->pf.kcnts[j] +=1; + j++; #endif } if (n->ht_down == NULL) { @@ -164,7 +172,7 @@ } #endif #ifdef CONFIG_CLS_U32_PERF - n->sel.rhit +=1; + n->pf.rhit +=1; #endif if (n->action) { int pol_res = tcf_action_exec(skb, n->action); @@ -682,16 +690,10 @@ s = RTA_DATA(tb[TCA_U32_SEL-1]); -#ifdef CONFIG_CLS_U32_PERF - if (RTA_PAYLOAD(tb[TCA_U32_SEL-1]) < - (s->nkeys*sizeof(struct tc_u32_key)) + sizeof(struct tc_u32_sel)) { - printk("Please upgrade your iproute2 tools or compile proper options in!\n"); - return -EINVAL; -} -#endif n = kmalloc(sizeof(*n) + s->nkeys*sizeof(struct tc_u32_key), GFP_KERNEL); if (n == NULL) return -ENOBUFS; + memset(n, 0, sizeof(*n) + s->nkeys*sizeof(struct tc_u32_key)); memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key)); n->ht_up = ht; @@ -851,6 +853,11 @@ } #endif #endif +#ifdef CONFIG_CLS_U32_PERF + RTA_PUT(skb, TCA_U32_PCNT, + sizeof(struct tc_u32_pcnt) + n->sel.nkeys*sizeof(unsigned long), + &n->pf); +#endif return skb->len; rtattr_failure: --=-Wuxvn3vFz2yEmJYKNOxp-- From rusty@rustcorp.com.au Sat Jul 24 07:46:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 07:46:40 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OEkXcd029033 for ; Sat, 24 Jul 2004 07:46:33 -0700 Received: from ip91-152.site (ip47-168.ott.istop.com [66.11.168.47]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id C37EB2BD43; Sun, 25 Jul 2004 00:46:18 +1000 (EST) Subject: Re: [PATCH 2.6] convert ipvs to module_param From: Rusty Russell To: Stephen Hemminger Cc: "David S. Miller" , wensong@linux-vs.org, netdev@oss.sgi.com In-Reply-To: <20040723131142.13081ed3@dell_ss3.pdx.osdl.net> References: <20040723131142.13081ed3@dell_ss3.pdx.osdl.net> Content-Type: text/plain Message-Id: <1090680357.4508.4.camel@bach> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 25 Jul 2004 00:45:57 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 7131 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev On Sat, 2004-07-24 at 06:11, Stephen Hemminger wrote: > #ifdef CONFIG_IP_VS_DEBUG > static int debug=0; > -MODULE_PARM(debug, "i"); > +module_param(debug, int, 0); > #endif Sure you want 0 here? Wouldn't it be nice to change it on the fly? Rusty. -- Anyone who quotes me in their signature is an idiot -- Rusty Russell From kazunori@miyazawa.org Sat Jul 24 10:22:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 10:22:43 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OHMXtN025046 for ; Sat, 24 Jul 2004 10:22:35 -0700 Received: from ip91-1.site (ip47-168.ott.istop.com [::ffff:66.11.168.47]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Sun, 25 Jul 2004 02:21:30 +0900 id 00000260.41029A9A.000015DA From: Kazunori Miyazawa To: Herbert Xu Subject: Re: [AH6] Rearrange routing headers Date: Sun, 25 Jul 2004 02:22:22 +0900 User-Agent: KMail/1.6.2 Cc: "David S. Miller" , netdev@oss.sgi.com References: <20040724083709.GA9416@gondor.apana.org.au> In-Reply-To: <20040724083709.GA9416@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200407250222.22934.kazunori@miyazawa.org> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-archive-position: 7132 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev 2004/07/24($BEZ(B) 17:37$B!"(BHerbert Xu wrote: > Hi: > > This patch rearranges the IPv6 routing header so that the destination > addresses appear in the order as they would on the destination. This > is specified in Appendix A2 of RFC 2402. > > Signed-off-by: Herbert Xu > > Cheers, I saw roughly the packet. It needs to check direction of the process. We don't need to do that in INBOUND. --Kazunori Miyazawa From anton@ozlabs.org Sat Jul 24 10:44:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 10:44:28 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OHiL0J025524 for ; Sat, 24 Jul 2004 10:44:22 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id E66CF2BD43; Sun, 25 Jul 2004 03:44:13 +1000 (EST) Date: Sun, 25 Jul 2004 03:43:48 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Cc: jes@trained-monkey.org, davem@redhat.com Subject: Use NET_IP_ALIGN in acenic Message-ID: <20040724174348.GL4556@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-archive-position: 7133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Use NET_IP_ALIGN in acenic driver. Also remove the 16 byte padding, caches can be anywhere from 16 to 256 bytes and the skb should be cacheline aligned already. Signed-off-by: Anton Blanchard ===== drivers/net/acenic.c 1.50 vs edited ===== --- 1.50/drivers/net/acenic.c Thu Jul 15 05:12:55 2004 +++ edited/drivers/net/acenic.c Mon Jul 19 12:03:55 2004 @@ -369,9 +369,9 @@ */ #define ACE_MINI_SIZE 100 -#define ACE_MINI_BUFSIZE (ACE_MINI_SIZE + 2 + 16) -#define ACE_STD_BUFSIZE (ACE_STD_MTU + ETH_HLEN + 2+4+16) -#define ACE_JUMBO_BUFSIZE (ACE_JUMBO_MTU + ETH_HLEN + 2+4+16) +#define ACE_MINI_BUFSIZE ACE_MINI_SIZE +#define ACE_STD_BUFSIZE (ACE_STD_MTU + ETH_HLEN + 4) +#define ACE_JUMBO_BUFSIZE (ACE_JUMBO_MTU + ETH_HLEN + 4) /* * There seems to be a magic difference in the effect between 995 and 996 @@ -678,7 +678,7 @@ ringp = &ap->skb->rx_std_skbuff[i]; mapping = pci_unmap_addr(ringp, mapping); pci_unmap_page(ap->pdev, mapping, - ACE_STD_BUFSIZE - (2 + 16), + ACE_STD_BUFSIZE, PCI_DMA_FROMDEVICE); ap->rx_std_ring[i].size = 0; @@ -698,7 +698,7 @@ ringp = &ap->skb->rx_mini_skbuff[i]; mapping = pci_unmap_addr(ringp,mapping); pci_unmap_page(ap->pdev, mapping, - ACE_MINI_BUFSIZE - (2 + 16), + ACE_MINI_BUFSIZE, PCI_DMA_FROMDEVICE); ap->rx_mini_ring[i].size = 0; @@ -717,7 +717,7 @@ ringp = &ap->skb->rx_jumbo_skbuff[i]; mapping = pci_unmap_addr(ringp, mapping); pci_unmap_page(ap->pdev, mapping, - ACE_JUMBO_BUFSIZE - (2 + 16), + ACE_JUMBO_BUFSIZE, PCI_DMA_FROMDEVICE); ap->rx_jumbo_ring[i].size = 0; @@ -1257,7 +1257,7 @@ set_aceaddr(&info->stats2_ptr, (dma_addr_t) tmp_ptr); set_aceaddr(&info->rx_std_ctrl.rngptr, ap->rx_ring_base_dma); - info->rx_std_ctrl.max_len = ACE_STD_MTU + ETH_HLEN + 4; + info->rx_std_ctrl.max_len = ACE_STD_BUFSIZE; info->rx_std_ctrl.flags = RCB_FLG_TCP_UDP_SUM | RCB_FLG_NO_PSEUDO_HDR | ACE_RCB_VLAN_FLAG; @@ -1700,17 +1700,14 @@ struct rx_desc *rd; dma_addr_t mapping; - skb = alloc_skb(ACE_STD_BUFSIZE, GFP_ATOMIC); + skb = alloc_skb(ACE_STD_BUFSIZE + NET_IP_ALIGN, GFP_ATOMIC); if (!skb) break; - /* - * Make sure IP header starts on a fresh cache line. - */ - skb_reserve(skb, 2 + 16); + skb_reserve(skb, NET_IP_ALIGN); mapping = pci_map_page(ap->pdev, virt_to_page(skb->data), offset_in_page(skb->data), - ACE_STD_BUFSIZE - (2 + 16), + ACE_STD_BUFSIZE, PCI_DMA_FROMDEVICE); ap->skb->rx_std_skbuff[idx].skb = skb; pci_unmap_addr_set(&ap->skb->rx_std_skbuff[idx], @@ -1718,7 +1715,7 @@ rd = &ap->rx_std_ring[idx]; set_aceaddr(&rd->addr, mapping); - rd->size = ACE_STD_MTU + ETH_HLEN + 4; + rd->size = ACE_STD_BUFSIZE; rd->idx = idx; idx = (idx + 1) % RX_STD_RING_ENTRIES; } @@ -1766,17 +1763,14 @@ struct rx_desc *rd; dma_addr_t mapping; - skb = alloc_skb(ACE_MINI_BUFSIZE, GFP_ATOMIC); + skb = alloc_skb(ACE_MINI_BUFSIZE + NET_IP_ALIGN, GFP_ATOMIC); if (!skb) break; - /* - * Make sure the IP header ends up on a fresh cache line - */ - skb_reserve(skb, 2 + 16); + skb_reserve(skb, NET_IP_ALIGN); mapping = pci_map_page(ap->pdev, virt_to_page(skb->data), offset_in_page(skb->data), - ACE_MINI_BUFSIZE - (2 + 16), + ACE_MINI_BUFSIZE, PCI_DMA_FROMDEVICE); ap->skb->rx_mini_skbuff[idx].skb = skb; pci_unmap_addr_set(&ap->skb->rx_mini_skbuff[idx], @@ -1784,7 +1778,7 @@ rd = &ap->rx_mini_ring[idx]; set_aceaddr(&rd->addr, mapping); - rd->size = ACE_MINI_SIZE; + rd->size = ACE_MINI_BUFSIZE; rd->idx = idx; idx = (idx + 1) % RX_MINI_RING_ENTRIES; } @@ -1827,17 +1821,14 @@ struct rx_desc *rd; dma_addr_t mapping; - skb = alloc_skb(ACE_JUMBO_BUFSIZE, GFP_ATOMIC); + skb = alloc_skb(ACE_JUMBO_BUFSIZE + NET_IP_ALIGN, GFP_ATOMIC); if (!skb) break; - /* - * Make sure the IP header ends up on a fresh cache line - */ - skb_reserve(skb, 2 + 16); + skb_reserve(skb, NET_IP_ALIGN); mapping = pci_map_page(ap->pdev, virt_to_page(skb->data), offset_in_page(skb->data), - ACE_JUMBO_BUFSIZE - (2 + 16), + ACE_JUMBO_BUFSIZE, PCI_DMA_FROMDEVICE); ap->skb->rx_jumbo_skbuff[idx].skb = skb; pci_unmap_addr_set(&ap->skb->rx_jumbo_skbuff[idx], @@ -1845,7 +1836,7 @@ rd = &ap->rx_jumbo_ring[idx]; set_aceaddr(&rd->addr, mapping); - rd->size = ACE_JUMBO_MTU + ETH_HLEN + 4; + rd->size = ACE_JUMBO_BUFSIZE; rd->idx = idx; idx = (idx + 1) % RX_JUMBO_RING_ENTRIES; } @@ -2027,19 +2018,19 @@ */ case 0: rip = &ap->skb->rx_std_skbuff[skbidx]; - mapsize = ACE_STD_BUFSIZE - (2 + 16); + mapsize = ACE_STD_BUFSIZE; rxdesc = &ap->rx_std_ring[skbidx]; std_count++; break; case BD_FLG_JUMBO: rip = &ap->skb->rx_jumbo_skbuff[skbidx]; - mapsize = ACE_JUMBO_BUFSIZE - (2 + 16); + mapsize = ACE_JUMBO_BUFSIZE; rxdesc = &ap->rx_jumbo_ring[skbidx]; atomic_dec(&ap->cur_jumbo_bufs); break; case BD_FLG_MINI: rip = &ap->skb->rx_mini_skbuff[skbidx]; - mapsize = ACE_MINI_BUFSIZE - (2 + 16); + mapsize = ACE_MINI_BUFSIZE; rxdesc = &ap->rx_mini_ring[skbidx]; mini_count++; break; From yoshfuji@linux-ipv6.org Sat Jul 24 11:21:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 11:21:57 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OILnk0026320 for ; Sat, 24 Jul 2004 11:21:50 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id B4FE833CE5; Sun, 25 Jul 2004 03:22:03 +0900 (JST) Date: Sat, 24 Jul 2004 14:22:03 -0400 (EDT) Message-Id: <20040724.142203.15175626.yoshfuji@linux-ipv6.org> To: kazunori@miyazawa.org, davem@redhat.com, herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [AH6] Rearrange routing headers From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200407250222.22934.kazunori@miyazawa.org> References: <20040724083709.GA9416@gondor.apana.org.au> <200407250222.22934.kazunori@miyazawa.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 7134 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <200407250222.22934.kazunori@miyazawa.org> (at Sun, 25 Jul 2004 02:22:22 +0900), Kazunori Miyazawa says: > 2004/07/24($BEZ(B) 17:37$B!"(BHerbert Xu wrote: > > Hi: > > > > This patch rearranges the IPv6 routing header so that the destination > > addresses appear in the order as they would on the destination. This > > is specified in Appendix A2 of RFC 2402. > > > > Signed-off-by: Herbert Xu > > > > Cheers, > > I saw roughly the packet. > It needs to check direction of the process. > We don't need to do that in INBOUND. Here's the patch (on top of the Xu's patch). Signed-off-by: Hideaki YOSHIFUJI --- linux26/net/ipv6/ah6.c 2004-07-24 13:53:08.000000000 -0400 +++ linux26/net/ipv6/ah6.c 2004-07-24 14:01:12.000000000 -0400 @@ -93,7 +93,6 @@ segments_left = rthdr->segments_left; if (segments_left == 0) return; - rthdr->segments_left = 0; /* The value of rthdr->hdrlen has been verified either by the system * call if it is locally generated, or by ipv6_rthdr_rcv() for incoming @@ -114,7 +113,7 @@ ipv6_addr_copy(&iph->daddr, &final_addr); } -static int ipv6_clear_mutable_options(struct ipv6hdr *iph, int len) +static int ipv6_clear_mutable_options(struct ipv6hdr *iph, int len, int dir) { union { struct ipv6hdr *iph; @@ -141,7 +140,9 @@ break; case NEXTHDR_ROUTING: - ipv6_rearrange_rthdr(iph, exthdr.rth); + if (dir == XFRM_POLICY_OUT) + ipv6_rearrange_rthdr(iph, exthdr.rth); + exthdr.rth->segments_left = 0; break; default : @@ -208,7 +209,8 @@ (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - err = ipv6_clear_mutable_options((*pskb)->nh.ipv6h, hdr_len); + err = ipv6_clear_mutable_options((*pskb)->nh.ipv6h, hdr_len, + XFRM_POLICY_OUT); if (err) goto error_free_iph; @@ -316,7 +318,7 @@ if (!tmp_hdr) goto out; memcpy(tmp_hdr, skb->nh.raw, hdr_len); - if (ipv6_clear_mutable_options(skb->nh.ipv6h, hdr_len)) + if (ipv6_clear_mutable_options(skb->nh.ipv6h, hdr_len, XFRM_POLICY_IN)) goto out; skb->nh.ipv6h->priority = 0; skb->nh.ipv6h->flow_lbl[0] = 0; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From kazunori@miyazawa.org Sat Jul 24 12:17:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 12:17:34 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OJHRQu027426 for ; Sat, 24 Jul 2004 12:17:28 -0700 Received: from ip91-1.site (ip47-168.ott.istop.com [::ffff:66.11.168.47]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Sun, 25 Jul 2004 04:16:24 +0900 id 00000745.4102B589.000017BA From: Kazunori Miyazawa To: Herbert Xu Subject: Re: [AH6] Rearrange routing headers Date: Sun, 25 Jul 2004 04:10:03 +0900 User-Agent: KMail/1.6.2 Cc: "David S. Miller" , netdev@oss.sgi.com References: <20040724083709.GA9416@gondor.apana.org.au> In-Reply-To: <20040724083709.GA9416@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Message-Id: <200407250410.03741.kazunori@miyazawa.org> X-archive-position: 7135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev 2004/07/24($BEZ(B) 17:37$B!"(BHerbert Xu wrote: > Hi: > > This patch rearranges the IPv6 routing header so that the destination > addresses appear in the order as they would on the destination. This > is specified in Appendix A2 of RFC 2402. > > Signed-off-by: Herbert Xu > To process routing header correctly, we should fix the codes which calls ip6_dst_lookup in ipv6 because there is difference of destinatio addresses for routing resolution and looking up xfrm_policy. So, we needs to separate ip6_dst_lookpu and xfrm_lookup. I will send the patch later. Thank you, --Kazunori Miyazawa From herbert@gondor.apana.org.au Sat Jul 24 12:32:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 12:32:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6OJWWlP031151 for ; Sat, 24 Jul 2004 12:32:35 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BoSFW-0005Mu-00; Sun, 25 Jul 2004 05:32:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BoSFS-000491-00; Sun, 25 Jul 2004 05:31:58 +1000 Date: Sun, 25 Jul 2004 05:31:58 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: kazunori@miyazawa.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [AH6] Rearrange routing headers Message-ID: <20040724193158.GA15897@gondor.apana.org.au> References: <20040724083709.GA9416@gondor.apana.org.au> <200407250222.22934.kazunori@miyazawa.org> <20040724.142203.15175626.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040724.142203.15175626.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7136 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Jul 24, 2004 at 02:22:03PM -0400, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > I saw roughly the packet. > > It needs to check direction of the process. > > We don't need to do that in INBOUND. > > Here's the patch (on top of the Xu's patch). This is unnecessary because if we're calling this from ah6_input(), then rthdr->segments_left must be zero. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From niranjan_cs2905@yahoo.com Sat Jul 24 15:33:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 15:33:25 -0700 (PDT) Received: from web53004.mail.yahoo.com (web53004.mail.yahoo.com [206.190.39.194]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6OMXH2i002414 for ; Sat, 24 Jul 2004 15:33:18 -0700 Message-ID: <20040724223310.68910.qmail@web53004.mail.yahoo.com> Received: from [128.119.85.178] by web53004.mail.yahoo.com via HTTP; Sat, 24 Jul 2004 15:33:10 PDT Date: Sat, 24 Jul 2004 15:33:10 -0700 (PDT) From: Niranjan Subject: kernel bug at sched.c:564! + linux kernel 2.4.25 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niranjan_cs2905@yahoo.com Precedence: bulk X-list: netdev Hi, I am working on Linux Kernel 2.4.25. I am trying to add cryptoapi (cryptoapi-0.1.0) support to wireless lan driver (linux-wlan-ng-0.2.1.pre14) of prism-based cards. Cardctl version is 3.1.31. When I am using "null" as a encryption cipher to check the coding sequence, everything is working fine. But when I change it to any other cipher for e.g. "blowfish" or "rc5", it is giving kernel panic. I have included Ksymoops extract from the kernel Ooops reports below. Can anyone please help me in what can be possible error by looking at the log ? I will greatly appreciate any help in this matter. Regards, -Niranjan Research Assistant, UMASS. Ksymoops extract from the kernel Ooops reports: =============================================== ksymoops 2.4.8 on i686 2.4.25. Options used -V (default) -k log4_ksyms (specified) -l log4_modules (specified) -o /lib/modules/2.4.25/ (specified) -m /boot/System.map-2.4.25 (specified) kernel bug at sched.c:564! CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000018 ebx: 00000000 ecx: cf244000 edx: cf245f7c esi: c6d44000 edi: 00000000 ebp: c6d45af4 esp: c6d45ac8 ds: 0018 es: 0018 ss: 0018 Process ping (pid:2814, stackpage=c6d45000) Stack: c02f10aa 00000000 c5d77e00 d08fd0b9 c6d45aec c6d44000 cb846034 3acbc7bc c6d45b18 d08390c6 00000000 c5d77e08 d08fd93b cd577e00 c6d45b18 00000000 00000008 00000000 00000001 c6d44000 bcc7cb3a c698f6d0 00000000 cb846000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 34 02 a2 10 2f c0 e9 b7 fb ff ff 0f 0b 2d 02 a2 10 2f >>EIP; c0117be6 <===== >>ecx; cf244000 <_end+ee33c9c/104c1cfc> >>edx; cf245f7c <_end+ee35c18/104c1cfc> >>esi; c6d44000 <_end+6933c9c/104c1cfc> >>ebp; c6d45af4 <_end+6935790/104c1cfc> >>esp; c6d45ac8 <_end+6935764/104c1cfc> Trace; d08fd0b9 <[cipher-blowfish]blowfish_encrypt+59/70> Trace; d08e90c6 <[p80211].rodata.end+233/f2d> Trace; d08fd93b <[cipher-blowfish]blowfish_cbc_encrypt+11b/120> Trace; d08390be <_end+10428d5a/104c1cfc> Trace; d08e06b6 <[cryptoapi]default_encrypt+36/40> Trace; d08e90be <[p80211].rodata.end+22b/f2d> Trace; d08fd0b9 <[cipher-blowfish]blowfish_encrypt+59/70> Trace; d08e90be <[p80211].rodata.end+22b/f2d> Trace; d08e5c79 <[p80211]run_cipher+99/160> Trace; d08e90be <[p80211].rodata.end+22b/f2d> Trace; d08e3240 <[p80211].text.start+1e0/450> Trace; d08e93c0 <[p80211].rodata.end+52d/f2d> Trace; d08e8394 <[p80211]bf_sbox+5d4/10d3> Trace; d08e6826 <[p80211]p80211knetdev_hard_start_xmit+276/290> Trace; c0116630 Trace; c028c4e3 Trace; c0281f80 Trace; c02b7975 Trace; c02b7365 Trace; c02879d6 <__neigh_event_send+116/250> Trace; c028831c Trace; c027d0de Trace; c029882d Trace; c0297ff7 Trace; c02b476a Trace; c02b4460 Trace; c02b776b Trace; c02bd7f2 Trace; c027a445 Trace; c027bb57 Trace; c012c1af Trace; c012c105 Trace; c012c381 Trace; c01167b8 Trace; c01bf87a Trace; c02bb84d Trace; c027c056 Trace; c01075ff Code; c0117be6 00000000 <_EIP>: Code; c0117be6 <===== 0: 0f 0b ud2a <===== Code; c0117be8 2: 34 02 xor $0x2,%al Code; c0117bea 4: a2 10 2f c0 e9 mov %al,0xe9c02f10 Code; c0117bef 9: b7 fb mov $0xfb,%bh Code; c0117bf1 b: ff (bad) Code; c0117bf2 c: ff 0f decl (%edi) Code; c0117bf4 e: 0b 2d 02 a2 10 2f or 0x2f10a202,%ebp <0> Kernel Panic: Aieee, killing interrupt handler! __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From yoshfuji@linux-ipv6.org Sat Jul 24 18:33:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 18:33:18 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P1X9CK009534 for ; Sat, 24 Jul 2004 18:33:12 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9B36D33CE5; Sun, 25 Jul 2004 10:33:23 +0900 (JST) Date: Sat, 24 Jul 2004 21:33:23 -0400 (EDT) Message-Id: <20040724.213323.61478122.yoshfuji@linux-ipv6.org> To: hadi@cyberus.ca Cc: davem@redhat.com, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] pkt_cls.h incompatiables From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1090675993.1161.11.camel@jzny.localdomain> References: <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> <1090675993.1161.11.camel@jzny.localdomain> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7138 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. In article <1090675993.1161.11.camel@jzny.localdomain> (at 24 Jul 2004 09:33:52 -0400), jamal says: > Makes the performance counters a separate TLV - a little bit of a pain, > but acceptable given its optional. > Compiles but hasnt been tested; user space code will have to change. basically, looks fine. 1. is it okay to use unsigned long? I'd rather prefer __u32 or __u64. 2. please use kcnts[0] instead of kcnts[] because user probably want to do sizeof(struct tc_u32_pcnt) > I dont want to touch the policer for now. hmm. :-P Thanks. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Sat Jul 24 22:28:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 22:28:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P5SSD5016422 for ; Sat, 24 Jul 2004 22:28:29 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6P5SIe1010776; Sun, 25 Jul 2004 01:28:18 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6P5SIa03676; Sun, 25 Jul 2004 01:28:18 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6P5RdWJ006699; Sun, 25 Jul 2004 01:27:39 -0400 Date: Sat, 24 Jul 2004 22:27:31 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [BK PATCH] 2.6 SCTP updates Message-Id: <20040724222731.0ed048ef.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7139 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 23 Jul 2004 17:18:11 -0700 (PDT) Sridhar Samudrala wrote: > Please do a > bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work > > to get the following SCTP updates to 2.6.8-rc2. Pulled, thanks Sridhar. Will there be a 2.4.x version of any of these SCTP changes? Thanks again. From davem@redhat.com Sat Jul 24 22:29:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 22:29:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P5Tn0m016523 for ; Sat, 24 Jul 2004 22:29:50 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6P5Tee1010889; Sun, 25 Jul 2004 01:29:40 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6P5Tea03774; Sun, 25 Jul 2004 01:29:40 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6P5T1IH007190; Sun, 25 Jul 2004 01:29:01 -0400 Date: Sat, 24 Jul 2004 22:28:53 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com Subject: Re: [PATCH] pkt_cls.h incompatiables Message-Id: <20040724222853.752137d6.davem@redhat.com> In-Reply-To: <1090675993.1161.11.camel@jzny.localdomain> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> <1090675993.1161.11.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7140 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 24 Jul 2004 09:33:52 -0400 jamal wrote: > Dont apply yet, i need to run my regression tests when i get back. > In the minimal back out Stephens change. Ok, I'll keep this in my inbox until you give the word. Thanks. From davem@redhat.com Sat Jul 24 22:36:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 22:36:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P5aH61017120 for ; Sat, 24 Jul 2004 22:36:17 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6P5Zve1011754; Sun, 25 Jul 2004 01:35:57 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6P5Zva04334; Sun, 25 Jul 2004 01:35:57 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6P5ZIYN008744; Sun, 25 Jul 2004 01:35:19 -0400 Date: Sat, 24 Jul 2004 22:35:11 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [AH4] Save daddr iff options are present Message-Id: <20040724223511.49847caa.davem@redhat.com> In-Reply-To: <20040724014415.GA5866@gondor.apana.org.au> References: <20040724014415.GA5866@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 24 Jul 2004 11:44:15 +1000 Herbert Xu wrote: > This is a little optimisation for AH4. When I moved the tunnel code out, > I put the daddr copying code on the main path which is unnecessary since > daddr is only mutable if IP options are present. > > This patch moves the saving and restoring of daddr under the check for > the existence of IP options. Looks good to me, applied. Thanks Herbert. From davem@redhat.com Sat Jul 24 22:38:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 22:38:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P5cLTm017444 for ; Sat, 24 Jul 2004 22:38:21 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6P5c7e1012059; Sun, 25 Jul 2004 01:38:07 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6P5c7a04962; Sun, 25 Jul 2004 01:38:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6P5bS0I009723; Sun, 25 Jul 2004 01:37:28 -0400 Date: Sat, 24 Jul 2004 22:37:20 -0700 From: "David S. Miller" To: Herbert Xu Cc: kazunori@miyazawa.org, netdev@oss.sgi.com Subject: Re: [AH6] Replace skb by iph in clear_mutable_options Message-Id: <20040724223720.6c107448.davem@redhat.com> In-Reply-To: <20040724045041.GA7091@gondor.apana.org.au> References: <20040724045041.GA7091@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 24 Jul 2004 14:50:41 +1000 Herbert Xu wrote: > This patch replaces the skb argument in ipv6_clear_mutable_options() by > an ipv6hdr. Doing so allows us to point skb->nh elsewhere when calling > this function. > > I've also thrown in some obvious clean-ups for that function. Applied, thanks Herbert. BTW, watch your patch rooting: --- 1.33/net/ipv6/ah6.c 2004-07-24 09:54:15 +10:00 +++ edited/ah6.c 2004-07-24 14:39:24 +10:00 From davem@redhat.com Sat Jul 24 22:42:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 22:42:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P5gR7o017844 for ; Sat, 24 Jul 2004 22:42:28 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6P5gOe1012569; Sun, 25 Jul 2004 01:42:24 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6P5gOa05414; Sun, 25 Jul 2004 01:42:24 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6P5fipC010885; Sun, 25 Jul 2004 01:41:46 -0400 Date: Sat, 24 Jul 2004 22:41:36 -0700 From: "David S. Miller" To: Anton Blanchard Cc: netdev@oss.sgi.com, jes@trained-monkey.org Subject: Re: Use NET_IP_ALIGN in acenic Message-Id: <20040724224136.070b6c36.davem@redhat.com> In-Reply-To: <20040724174348.GL4556@krispykreme> References: <20040724174348.GL4556@krispykreme> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 25 Jul 2004 03:43:48 +1000 Anton Blanchard wrote: > > Use NET_IP_ALIGN in acenic driver. Also remove the 16 byte padding, > caches can be anywhere from 16 to 256 bytes and the skb should be > cacheline aligned already. Looks fine to me, applied. Thanks Anton. From davem@redhat.com Sat Jul 24 23:26:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 23:27:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P6Quq2018690 for ; Sat, 24 Jul 2004 23:26:57 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6P6Qke1018240; Sun, 25 Jul 2004 02:26:46 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6P6Qka10535; Sun, 25 Jul 2004 02:26:46 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6P6Q73C025059; Sun, 25 Jul 2004 02:26:07 -0400 Date: Sat, 24 Jul 2004 23:25:58 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: hadi@cyberus.ca, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com Subject: Re: [PATCH] pkt_cls.h incompatiables Message-Id: <20040724232558.7c4aea69.davem@redhat.com> In-Reply-To: <20040724.213323.61478122.yoshfuji@linux-ipv6.org> References: <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> <1090675993.1161.11.camel@jzny.localdomain> <20040724.213323.61478122.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6P6Quq2018690 X-archive-position: 7144 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 24 Jul 2004 21:33:23 -0400 (EDT) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > 1. is it okay to use unsigned long? > I'd rather prefer __u32 or __u64. Me too, for public APIs use strictly sized types please. From davem@redhat.com Sat Jul 24 23:28:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jul 2004 23:28:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P6S0FY018785 for ; Sat, 24 Jul 2004 23:28:01 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6P6Rre1018362; Sun, 25 Jul 2004 02:27:53 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6P6Rra10724; Sun, 25 Jul 2004 02:27:53 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6P6RDux025353; Sun, 25 Jul 2004 02:27:14 -0400 Date: Sat, 24 Jul 2004 23:27:05 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040724232705.237396b4.davem@redhat.com> In-Reply-To: <41019CDA.9050401@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> <20040723135459.2ee5c42c.davem@redhat.com> <41019CDA.9050401@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7145 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 24 Jul 2004 01:18:50 +0200 Patrick McHardy wrote: > > I'm going to apply your patch and delete the Alpha parts. > > Meanwhile, ping Richard Henderson (rth@redhat.com) or one > > of the other Alpha experts for me to get confirmation on > > this stuff. > > Even better. Let me know if you get feedback or not. For now I'm pushing to Linus with Alpha removed from the list. From herbert@gondor.apana.org.au Sun Jul 25 01:04:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 01:04:59 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6P84gSg023542 for ; Sun, 25 Jul 2004 01:04:48 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BodzD-0008B5-00; Sun, 25 Jul 2004 18:03:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bodz1-0005Gt-00; Sun, 25 Jul 2004 18:03:47 +1000 Date: Sun, 25 Jul 2004 18:03:47 +1000 To: Kazunori Miyazawa Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [AH6] Rearrange routing headers Message-ID: <20040725080347.GA20251@gondor.apana.org.au> References: <20040724083709.GA9416@gondor.apana.org.au> <200407250410.03741.kazunori@miyazawa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407250410.03741.kazunori@miyazawa.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7146 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Jul 25, 2004 at 04:10:03AM +0900, Kazunori Miyazawa wrote: > > To process routing header correctly, we should fix the codes which > calls ip6_dst_lookup in ipv6 because there is difference of destinatio > addresses for routing resolution and looking up xfrm_policy. What do you mean? Isn't the code in icmp.c/raw.c/tcp_ipv6.c/udp.c that sets fl.fl6_dst using opt->srcrt enough? If not then we'll need to change IPv4 as well. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Jul 25 03:48:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 03:48:59 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6PAmIfN028947 for ; Sun, 25 Jul 2004 03:48:19 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BogQx-0000bE-00; Sun, 25 Jul 2004 20:40:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BogQe-0006SM-00; Sun, 25 Jul 2004 20:40:28 +1000 Date: Sun, 25 Jul 2004 20:40:28 +1000 To: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com, YOSHIFUJI Hideaki , Kazunori Miyazawa Subject: [IPSEC] Move generic encap code into xfrm6_output Message-ID: <20040725104028.GA24547@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7147 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: Here is the IPv6 version of the generic tunnel encapsulation code. It is amazing to see how similar the IPv6 transform code is to its IPv4 counterpart (except for AH) once the tunnel encapsulation code is gone. Maybe we can merge them one day. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff -Nru a/include/net/xfrm.h b/include/net/xfrm.h --- a/include/net/xfrm.h 2004-07-25 20:34:45 +10:00 +++ b/include/net/xfrm.h 2004-07-25 20:34:45 +10:00 @@ -823,6 +823,7 @@ extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_check_size(struct sk_buff *skb); extern int xfrm6_rcv(struct sk_buff **pskb, unsigned int *nhoffp); +extern int xfrm6_output(struct sk_buff **pskb); extern int xfrm6_tunnel_register(struct xfrm6_tunnel *handler); extern int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler); extern int xfrm6_tunnel_check_size(struct sk_buff *skb); diff -Nru a/net/ipv6/Makefile b/net/ipv6/Makefile --- a/net/ipv6/Makefile 2004-07-25 20:34:45 +10:00 +++ b/net/ipv6/Makefile 2004-07-25 20:34:45 +10:00 @@ -11,7 +11,7 @@ ip6_flowlabel.o ipv6_syms.o ipv6-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o xfrm6_input.o \ - xfrm6_tunnel.o + xfrm6_tunnel.o xfrm6_output.o ipv6-objs += $(ipv6-y) obj-$(CONFIG_INET6_AH) += ah6.o diff -Nru a/net/ipv6/ah6.c b/net/ipv6/ah6.c --- a/net/ipv6/ah6.c 2004-07-25 20:34:45 +10:00 +++ b/net/ipv6/ah6.c 2004-07-25 20:34:45 +10:00 @@ -158,65 +158,50 @@ int ah6_output(struct sk_buff **pskb) { int err; - int hdr_len = sizeof(struct ipv6hdr); + int extlen; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL; + struct ipv6hdr *top_iph; struct ip_auth_hdr *ah; struct ah_data *ahp; u8 nexthdr; - - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - iph = (*pskb)->nh.ipv6h; - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->nh.ipv6h->version = 6; - (*pskb)->nh.ipv6h->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.ipv6h->nexthdr = IPPROTO_AH; - ipv6_addr_copy(&(*pskb)->nh.ipv6h->saddr, - (struct in6_addr *) &x->props.saddr); - ipv6_addr_copy(&(*pskb)->nh.ipv6h->daddr, - (struct in6_addr *) &x->id.daddr); - ah = (struct ip_auth_hdr*)((*pskb)->nh.ipv6h+1); - ah->nexthdr = IPPROTO_IPV6; - } else { - u8 *prevhdr; - - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_AH; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { + char tmp_base[8]; + struct { + struct in6_addr daddr; + char hdrs[0]; + } *tmp_ext; + + top_iph = (struct ipv6hdr *)(*pskb)->data; + top_iph->payload_len = htons((*pskb)->len - sizeof(*top_iph)); + + nexthdr = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_AH; + + /* When there are no extension headers, we only need to save the first + * 8 bytes of the base IP header. + */ + memcpy(tmp_base, top_iph, sizeof(tmp_base)); + + tmp_ext = NULL; + extlen = (*pskb)->h.raw - (unsigned char *)(top_iph + 1); + if (extlen) { + extlen += sizeof(*tmp_ext); + tmp_ext = kmalloc(extlen, GFP_ATOMIC); + if (!tmp_ext) { err = -ENOMEM; goto error; } - memcpy(iph, (*pskb)->data, hdr_len); - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - err = ipv6_clear_mutable_options((*pskb)->nh.ipv6h, hdr_len); + memcpy(tmp_ext, &top_iph->daddr, extlen); + err = ipv6_clear_mutable_options(top_iph, + extlen - sizeof(*tmp_ext) + + sizeof(*top_iph)); if (err) goto error_free_iph; - - ah = (struct ip_auth_hdr*)((*pskb)->nh.raw+hdr_len); - (*pskb)->h.raw = (unsigned char*) ah; - ah->nexthdr = nexthdr; } + ah = (struct ip_auth_hdr *)(*pskb)->h.raw; + ah->nexthdr = nexthdr; + (*pskb)->nh.ipv6h->priority = 0; (*pskb)->nh.ipv6h->flow_lbl[0] = 0; (*pskb)->nh.ipv6h->flow_lbl[1] = 0; @@ -232,35 +217,16 @@ ah->seq_no = htonl(++x->replay.oseq); ahp->icv(ahp, *pskb, ah->auth_data); - if (x->props.mode) { - (*pskb)->nh.ipv6h->hop_limit = iph->hop_limit; - (*pskb)->nh.ipv6h->priority = iph->priority; - (*pskb)->nh.ipv6h->flow_lbl[0] = iph->flow_lbl[0]; - (*pskb)->nh.ipv6h->flow_lbl[1] = iph->flow_lbl[1]; - (*pskb)->nh.ipv6h->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear((*pskb)->nh.ipv6h); - } else { - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - kfree (iph); - } - - (*pskb)->nh.raw = (*pskb)->data; + err = 0; - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + memcpy(top_iph, tmp_base, sizeof(tmp_base)); + if (tmp_ext) { + memcpy(&top_iph->daddr, tmp_ext, extlen); error_free_iph: - kfree(iph); + kfree(tmp_ext); + } + error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } diff -Nru a/net/ipv6/esp6.c b/net/ipv6/esp6.c --- a/net/ipv6/esp6.c 2004-07-25 20:34:45 +10:00 +++ b/net/ipv6/esp6.c 2004-07-25 20:34:45 +10:00 @@ -41,10 +41,10 @@ int esp6_output(struct sk_buff **pskb) { int err; - int hdr_len = 0; + int hdr_len; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL, *top_iph; + struct ipv6hdr *top_iph; struct ipv6_esp_hdr *esph; struct crypto_tfm *tfm; struct esp_data *esp; @@ -53,37 +53,13 @@ int clen; int alen; int nfrags; - u8 *prevhdr; - u8 nexthdr = 0; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; + esp = x->data; + hdr_len = (*pskb)->h.raw - (*pskb)->data + + sizeof(*esph) + esp->conf.ivlen; - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - } else { - /* Strip IP header in transport mode. Save it. */ - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_ESP; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { - err = -ENOMEM; - goto error; - } - memcpy(iph, (*pskb)->nh.raw, hdr_len); - __skb_pull(*pskb, hdr_len); - } + /* Strip IP+ESP header. */ + __skb_pull(*pskb, hdr_len); /* Now skb is pure payload to encrypt */ err = -ENOMEM; @@ -91,7 +67,6 @@ /* Round to block size */ clen = (*pskb)->len; - esp = x->data; alen = esp->auth.icv_trunc_len; tfm = esp->conf.tfm; blksize = (crypto_tfm_alg_blocksize(tfm) + 3) & ~3; @@ -100,7 +75,6 @@ clen = (clen + esp->conf.padlen-1)&~(esp->conf.padlen-1); if ((nfrags = skb_cow_data(*pskb, clen-(*pskb)->len+alen, &trailer)) < 0) { - if (!x->props.mode && iph) kfree(iph); goto error; } @@ -113,34 +87,11 @@ *(u8*)(trailer->tail + clen-(*pskb)->len - 2) = (clen - (*pskb)->len)-2; pskb_put(*pskb, trailer, clen - (*pskb)->len); - if (x->props.mode) { - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - esph = (struct ipv6_esp_hdr*)(top_iph+1); - *(u8*)(trailer->tail - 1) = IPPROTO_IPV6; - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear(top_iph); - top_iph->nexthdr = IPPROTO_ESP; - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - ipv6_addr_copy(&top_iph->saddr, - (struct in6_addr *)&x->props.saddr); - ipv6_addr_copy(&top_iph->daddr, - (struct in6_addr *)&x->id.daddr); - } else { - esph = (struct ipv6_esp_hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->h.raw = (unsigned char*)esph; - top_iph = (struct ipv6hdr*)skb_push(*pskb, hdr_len); - memcpy(top_iph, iph, hdr_len); - kfree(iph); - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - *(u8*)(trailer->tail - 1) = nexthdr; - } + top_iph = (struct ipv6hdr *)__skb_push(*pskb, hdr_len); + esph = (struct ipv6_esp_hdr *)(*pskb)->h.raw; + top_iph->payload_len = htons((*pskb)->len + alen - sizeof(*top_iph)); + *(u8*)(trailer->tail - 1) = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_ESP; esph->spi = x->id.spi; esph->seq_no = htonl(++x->replay.oseq); @@ -173,21 +124,9 @@ pskb_put(*pskb, trailer, alen); } - (*pskb)->nh.raw = (*pskb)->data; - - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + err = 0; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } diff -Nru a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c --- a/net/ipv6/ipcomp6.c 2004-07-25 20:34:45 +10:00 +++ b/net/ipv6/ipcomp6.c 2004-07-25 20:34:45 +10:00 @@ -123,52 +123,14 @@ int err; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int hdr_len = 0; + struct ipv6hdr *top_iph; + int hdr_len; struct ipv6_comp_hdr *ipch; struct ipcomp_data *ipcd = x->data; - u8 *prevhdr; - u8 nexthdr = 0; int plen, dlen; u8 *start, *scratch = ipcd->scratch; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - hdr_len = sizeof(struct ipv6hdr); - nexthdr = IPPROTO_IPV6; - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr *)skb_push(*pskb, sizeof(struct ipv6hdr)); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; /* initial */ - top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - (*pskb)->nh.raw = (*pskb)->data; /* == top_iph */ - (*pskb)->h.raw = (*pskb)->nh.raw + hdr_len; - } else { - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - } + hdr_len = (*pskb)->h.raw - (*pskb)->data; /* check whether datagram len is larger than threshold */ if (((*pskb)->len - hdr_len) < ipcd->threshold) { @@ -184,7 +146,7 @@ /* compression */ plen = (*pskb)->len - hdr_len; dlen = IPCOMP_SCRATCH_SIZE; - start = (*pskb)->data + hdr_len; + start = (*pskb)->h.raw; err = crypto_comp_compress(ipcd->tfm, start, plen, scratch, &dlen); if (err) { @@ -197,39 +159,21 @@ pskb_trim(*pskb, hdr_len + dlen + sizeof(struct ip_comp_hdr)); /* insert ipcomp header and replace datagram */ - top_iph = (*pskb)->nh.ipv6h; + top_iph = (struct ipv6hdr *)(*pskb)->data; - if (x->props.mode && (x->props.flags & XFRM_STATE_NOECN)) - IP6_ECN_clear(top_iph); top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.raw = (*pskb)->data; /* top_iph */ - ip6_find_1stfragopt(*pskb, &prevhdr); - *prevhdr = IPPROTO_COMP; - ipch = (struct ipv6_comp_hdr *)((unsigned char *)top_iph + hdr_len); - ipch->nexthdr = nexthdr; + ipch = (struct ipv6_comp_hdr *)start; + ipch->nexthdr = *(*pskb)->nh.raw; ipch->flags = 0; ipch->cpi = htons((u16 )ntohl(x->id.spi)); + *(*pskb)->nh.raw = IPPROTO_COMP; - (*pskb)->h.raw = (unsigned char*)ipch; out_ok: - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - err = NET_XMIT_BYPASS; + err = 0; -out_exit: - return err; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); - goto out_exit; + return err; } static void ipcomp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt, diff -Nru a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv6/xfrm6_output.c 2004-07-25 20:34:45 +10:00 @@ -0,0 +1,123 @@ +/* + * xfrm6_output.c - Common IPsec encapsulation code for IPv6. + * Copyright (c) 2004 Herbert Xu + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include + +/* Add encapsulation header. + * + * In transport mode, the IP header and mutable extension headers will be moved + * forward to make space for the encapsulation header. + * + * In tunnel mode, the top IP header will be constructed per RFC 2401. + * The following fields in it shall be filled in by x->type->output: + * payload_len + * + * On exit, skb->h will be set to the start of the encapsulation header to be + * filled in by x->type->output and skb->nh will be set to the nextheader field + * of the extension header directly preceding the encapsulation header, or in + * its absence, that of the top IP header. The value of skb->data will always + * point to the top IP header. + */ +static void xfrm6_encap(struct sk_buff *skb) +{ + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + struct ipv6hdr *iph, *top_iph; + + skb_push(skb, x->props.header_len); + iph = skb->nh.ipv6h; + + if (!x->props.mode) { + u8 *prevhdr; + int hdr_len; + + hdr_len = ip6_find_1stfragopt(skb, &prevhdr); + skb->nh.raw = prevhdr - hdr_len; + skb->h.ipv6h = iph; + skb->h.raw += hdr_len; + memmove(skb->data, iph, hdr_len); + return; + } + + skb->nh.raw = skb->data; + top_iph = skb->nh.ipv6h; + skb->nh.raw = &top_iph->nexthdr; + skb->h.ipv6h = top_iph + 1; + + top_iph->version = 6; + top_iph->priority = iph->priority; + if (x->props.flags & XFRM_STATE_NOECN) + IP6_ECN_clear(top_iph); + top_iph->flow_lbl[0] = iph->flow_lbl[0]; + top_iph->flow_lbl[1] = iph->flow_lbl[1]; + top_iph->flow_lbl[2] = iph->flow_lbl[2]; + top_iph->nexthdr = IPPROTO_IPV6; + top_iph->hop_limit = iph->hop_limit; + ipv6_addr_copy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr); + ipv6_addr_copy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr); +} + +int xfrm6_output(struct sk_buff **pskb) +{ + struct sk_buff *skb = *pskb; + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + int err; + + if (skb->ip_summed == CHECKSUM_HW) { + err = skb_checksum_help(pskb, 0); + skb = *pskb; + if (err) + goto error_nolock; + } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; + + if (x->props.mode) { + err = xfrm6_tunnel_check_size(skb); + if (err) + goto error; + } + + xfrm6_encap(skb); + + err = x->type->output(pskb); + skb = *pskb; + if (err) + goto error; + + x->curlft.bytes += skb->len; + x->curlft.packets++; + + spin_unlock_bh(&x->lock); + + skb->nh.raw = skb->data; + + if (!(skb->dst = dst_pop(dst))) { + err = -EHOSTUNREACH; + goto error_nolock; + } + err = NET_XMIT_BYPASS; + +out_exit: + return err; +error: + spin_unlock_bh(&x->lock); +error_nolock: + kfree_skb(skb); + goto out_exit; +} diff -Nru a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c --- a/net/ipv6/xfrm6_policy.c 2004-07-25 20:34:45 +10:00 +++ b/net/ipv6/xfrm6_policy.c 2004-07-25 20:34:45 +10:00 @@ -157,7 +157,7 @@ /* Copy neighbour for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); dst_prev->input = rt->u.dst.input; - dst_prev->output = dst_prev->xfrm->type->output; + dst_prev->output = xfrm6_output; /* Sheit... I remember I did this right. Apparently, * it was magically lost, so this code needs audit */ x->u.rt6.rt6i_flags = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL); diff -Nru a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c --- a/net/ipv6/xfrm6_tunnel.c 2004-07-25 20:34:45 +10:00 +++ b/net/ipv6/xfrm6_tunnel.c 2004-07-25 20:34:45 +10:00 @@ -365,46 +365,12 @@ static int xfrm6_tunnel_output(struct sk_buff **pskb) { struct sk_buff *skb = *pskb; - struct dst_entry *dst = skb->dst; - struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int err; + struct ipv6hdr *top_iph; - if ((err = xfrm6_tunnel_check_size(skb)) != 0) - goto error_nolock; - - iph = skb->nh.ipv6h; - - top_iph = (struct ipv6hdr *)skb_push(skb, x->props.header_len); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; + top_iph = (struct ipv6hdr *)skb->data; top_iph->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - skb->nh.raw = skb->data; - skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr); - - x->curlft.bytes += skb->len; - x->curlft.packets++; - - spin_unlock_bh(&x->lock); - - if ((skb->dst = dst_pop(dst)) == NULL) { - kfree_skb(skb); - err = -EHOSTUNREACH; - goto error_nolock; - } - - return NET_XMIT_BYPASS; -error_nolock: - kfree_skb(skb); - return err; + return 0; } static int xfrm6_tunnel_input(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb) --0OAP2g/MAC+5xKAE-- From kazunori@miyazawa.org Sun Jul 25 03:50:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 03:50:19 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6PAoDQr029050 for ; Sun, 25 Jul 2004 03:50:14 -0700 Received: from [192.168.218.128] ([::ffff:216.208.38.106]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Sun, 25 Jul 2004 19:49:06 +0900 id 000009C8.41039022.0000224A From: Kazunori Miyazawa To: Herbert Xu Subject: Re: [AH6] Rearrange routing headers Date: Sun, 25 Jul 2004 15:32:13 +0900 User-Agent: KMail/1.6.2 Cc: "David S. Miller" , netdev@oss.sgi.com References: <20040724083709.GA9416@gondor.apana.org.au> <200407250410.03741.kazunori@miyazawa.org> <20040725080347.GA20251@gondor.apana.org.au> In-Reply-To: <20040725080347.GA20251@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Message-Id: <200407251532.13292.kazunori@miyazawa.org> X-archive-position: 7148 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev 2004/07/25($BF|(B) 17:03$B!"(BHerbert Xu wrote: > On Sun, Jul 25, 2004 at 04:10:03AM +0900, Kazunori Miyazawa wrote: > > To process routing header correctly, we should fix the codes which > > calls ip6_dst_lookup in ipv6 because there is difference of destinatio > > addresses for routing resolution and looking up xfrm_policy. > > What do you mean? Isn't the code in icmp.c/raw.c/tcp_ipv6.c/udp.c > that sets fl.fl6_dst using opt->srcrt enough? > > If not then we'll need to change IPv4 as well. > routing is looked up with srcrt but xfrm is looked up with final destination, isn't it? we have the codes in our repository. sorry, I'm goring back to home from OLS2004. I'll send the patch when I will arrive at home. Thank you, --Kazunori Miyazawa From mika.penttila@kolumbus.fi Sun Jul 25 04:23:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 04:24:02 -0700 (PDT) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6PBNsoD006195 for ; Sun, 25 Jul 2004 04:23:55 -0700 Received: from kolumbus.fi ([193.166.136.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2004072514264340:37840 ; Sun, 25 Jul 2004 14:26:43 +0300 Message-ID: <410398D4.2080608@kolumbus.fi> Date: Sun, 25 Jul 2004 14:26:12 +0300 From: =?ISO-2022-JP?B?TWlrYSBQZW50dGlsYSI=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kazunori Miyazawa CC: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [AH6] Rearrange routing headers References: <20040724083709.GA9416@gondor.apana.org.au> <200407250410.03741.kazunori@miyazawa.org> <20040725080347.GA20251@gondor.apana.org.au> <200407251532.13292.kazunori@miyazawa.org> In-Reply-To: <200407251532.13292.kazunori@miyazawa.org> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 25.07.2004 14:26:43, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 25.07.2004 14:25:40, Serialize complete at 25.07.2004 14:25:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-2022-JP X-archive-position: 7149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev Kazunori Miyazawa wrote: >2004/07/25($BF|(B) 17:03$B!"(BHerbert Xu wrote: > > >>On Sun, Jul 25, 2004 at 04:10:03AM +0900, Kazunori Miyazawa wrote: >> >> >>>To process routing header correctly, we should fix the codes which >>>calls ip6_dst_lookup in ipv6 because there is difference of destinatio >>>addresses for routing resolution and looking up xfrm_policy. >>> >>> >>What do you mean? Isn't the code in icmp.c/raw.c/tcp_ipv6.c/udp.c >>that sets fl.fl6_dst using opt->srcrt enough? >> >>If not then we'll need to change IPv4 as well. >> >> >> >routing is looked up with srcrt but xfrm is looked up with final >destination, isn't it? we have the codes in our repository. >sorry, I'm goring back to home from OLS2004. >I'll send the patch when I will arrive at home. > > We are not doing this in ipv4 either. But it makes sense to do xfrm lookup based on the final destination. >Thank you, > >--Kazunori Miyazawa > > --Mika From herbert@gondor.apana.org.au Sun Jul 25 04:49:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 04:49:50 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6PBmCXe006833 for ; Sun, 25 Jul 2004 04:49:22 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Boh0E-0000mm-00; Sun, 25 Jul 2004 21:17:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bogzh-00076z-00; Sun, 25 Jul 2004 21:16:41 +1000 Date: Sun, 25 Jul 2004 21:16:41 +1000 To: Kazunori Miyazawa Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [AH6] Rearrange routing headers Message-ID: <20040725111641.GA27265@gondor.apana.org.au> References: <20040724083709.GA9416@gondor.apana.org.au> <200407250410.03741.kazunori@miyazawa.org> <20040725080347.GA20251@gondor.apana.org.au> <200407251532.13292.kazunori@miyazawa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407251532.13292.kazunori@miyazawa.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Jul 25, 2004 at 03:32:13PM +0900, Kazunori Miyazawa wrote: > > routing is looked up with srcrt but xfrm is looked up with final > destination, isn't it? we have the codes in our repository. You're right. I only skimmed through the code and took the presence of code that dealt with the option/extension header as evidence that it did the right thing :) So both IPv4 and IPv6 are broken in this respect as they use the first address rather than the final address for policy lookup. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Sun Jul 25 06:36:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 06:36:11 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6PDa36C009056 for ; Sun, 25 Jul 2004 06:36:04 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EB5CE33CE5; Sun, 25 Jul 2004 22:36:17 +0900 (JST) Date: Sun, 25 Jul 2004 09:36:17 -0400 (EDT) Message-Id: <20040725.093617.15482200.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com, kazunori@miyazawa.org, yoshfuji@linux-ipv6.org, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Move generic encap code into xfrm6_output From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040725104028.GA24547@gondor.apana.org.au> References: <20040725104028.GA24547@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20040725104028.GA24547@gondor.apana.org.au> (at Sun, 25 Jul 2004 20:40:28 +1000), Herbert Xu says: > Here is the IPv6 version of the generic tunnel encapsulation code. Well, since we're on the way back to home from OLS, we'll review when we're back to Japan. One thing: please retain our credit in net/ipv6/xfrm6_output.c. Thank you. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Sun Jul 25 14:31:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 14:32:06 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6PLVwtX027225 for ; Sun, 25 Jul 2004 14:31:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Boqab-0003il-00; Mon, 26 Jul 2004 07:31:25 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BoqaY-00081r-00; Mon, 26 Jul 2004 07:31:22 +1000 Date: Mon, 26 Jul 2004 07:31:22 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com, kazunori@miyazawa.org, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Move generic encap code into xfrm6_output Message-ID: <20040725213122.GA30819@gondor.apana.org.au> References: <20040725104028.GA24547@gondor.apana.org.au> <20040725.093617.15482200.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040725.093617.15482200.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Jul 25, 2004 at 09:36:17AM -0400, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Well, since we're on the way back to home from OLS, > we'll review when we're back to Japan. Thanks. > One thing: please retain our credit in net/ipv6/xfrm6_output.c. Sure. But can you please send in a follow-up patch on that since I'm not sure what I should be putting there. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sun Jul 25 14:56:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 14:56:32 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6PLu5ra027789 for ; Sun, 25 Jul 2004 14:56:06 -0700 Received: from ws.localnet ([192.168.0.23] ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1Bor1i-0001rl-00; Sun, 25 Jul 2004 23:59:26 +0200 Message-ID: <41042CA3.2050702@trash.net> Date: Sun, 25 Jul 2004 23:56:51 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040722 Debian/1.7.1-3 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> <20040723135459.2ee5c42c.davem@redhat.com> <41019CDA.9050401@trash.net> <20040724232705.237396b4.davem@redhat.com> In-Reply-To: <20040724232705.237396b4.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7153 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 David S. Miller wrote: > Let me know if you get feedback or not. > > For now I'm pushing to Linus with Alpha removed from the > list. According to Richard Henderson it should work fine. The fastest Alpha cycle counter (1.2 GHz) takes 3.57 seconds to overflow. Regards Patrick From davem@redhat.com Sun Jul 25 17:03:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 17:03:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6Q03URk000423 for ; Sun, 25 Jul 2004 17:03:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6Q03Fe1024056; Sun, 25 Jul 2004 20:03:15 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6Q03Fa04317; Sun, 25 Jul 2004 20:03:15 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6Q02ZFU026796; Sun, 25 Jul 2004 20:02:36 -0400 Date: Sun, 25 Jul 2004 17:02:12 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH 2.6]: Make packet scheduler clock source configurable Message-Id: <20040725170212.36b04c3c.davem@redhat.com> In-Reply-To: <41042CA3.2050702@trash.net> References: <40F34740.5040100@trash.net> <1107.63.170.215.71.1089689716.squirrel@www.osdl.org> <20040712205037.573411c0.davem@redhat.com> <40F4862D.3070802@trash.net> <40F4AC8B.40706@trash.net> <20040721143110.4ab944bf.davem@redhat.com> <41004F76.1080807@trash.net> <20040722171752.341d2476.davem@redhat.com> <41006150.9000702@trash.net> <41014788.4070301@trash.net> <20040723135459.2ee5c42c.davem@redhat.com> <41019CDA.9050401@trash.net> <20040724232705.237396b4.davem@redhat.com> <41042CA3.2050702@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 25 Jul 2004 23:56:51 +0200 Patrick McHardy wrote: > David S. Miller wrote: > > Let me know if you get feedback or not. > > > > For now I'm pushing to Linus with Alpha removed from the > > list. > > According to Richard Henderson it should work fine. The fastest > Alpha cycle counter (1.2 GHz) takes 3.57 seconds to overflow. That's word enough for me, I'll put ALPHA back into the list. Thanks. From akpm@osdl.org Sun Jul 25 18:01:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 18:01:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6Q11Od7001522 for ; Sun, 25 Jul 2004 18:01:25 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6Q117112034; Sun, 25 Jul 2004 18:01:07 -0700 Date: Sun, 25 Jul 2004 17:59:45 -0700 From: Andrew Morton To: Harald Welte Cc: sebest@ovibes.net, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: kernel 2.6.7 -> page allocation failure. order:1, mode:0x20 (netfilter?) Message-Id: <20040725175945.15999990.akpm@osdl.org> In-Reply-To: <20040720024741.GF27487@obroa-skai.de.gnumonks.org> References: <40FB93FE.90308@ovibes.net> <20040720024741.GF27487@obroa-skai.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7155 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Harald Welte wrote: > > what's worrying me is the part above... how would skb_checksum_help > directly end up in copy_from_user()? That'll be leftover gunk on the stack. Enabling frame pointers makes that go away. > > swapper: page allocation failure. order:1, mode:0x20 > > [] __alloc_pages+0x2da/0x34a > > [] __get_free_pages+0x25/0x3f > > [] kmem_getpages+0x2b/0xdc > > [] kfree_skbmem+0x24/0x2c > > [] cache_grow+0xe5/0x2a4 > > [] cache_grow+0x146/0x2a4 > > [] cache_alloc_refill+0x1cf/0x29f > > [] __kmalloc+0x85/0x8c > > [] tcp_transmit_skb+0x411/0x68a > > [] alloc_skb+0x47/0xe0 > > [] tcp_write_xmit+0x16d/0x2d6 > > [] skb_copy+0x33/0xde > > [] copy_from_user+0x42/0x6e > > Does anybody have a clue what's going on? Networking tried to do an atomic 1-order allocation and there were no 1-order pages available in the free page pools. It's pretty much unavoidable, and the caller simply needs to handle it - presumably by dropping the packet. Its frequency can be reduced by increasing /proc/sys/vm/min_free_kbytes. It can be eliminated by using GFP_KERNEL. It can be hugely reduced by sticking to 0-order allocations. I wouldn't worry about this unless someone is seeing a lot of them (a significant number of packets are getting dropped) From p_gortmaker@yahoo.com Sun Jul 25 22:33:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jul 2004 22:33:44 -0700 (PDT) Received: from gold.muskoka.com (gold.muskoka.com [216.123.107.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6Q5Xdlw009692 for ; Sun, 25 Jul 2004 22:33:39 -0700 Received: from yahoo.com (ppp167.muskoka.com [216.123.108.177]) by gold.muskoka.com (8.12.3/8.12.3/Debian-6.4) with ESMTP id i6Q5Ys87011313; Mon, 26 Jul 2004 01:34:55 -0400 Message-ID: <410495AC.5040108@yahoo.com> Date: Mon, 26 Jul 2004 01:25:00 -0400 From: Paul Gortmaker User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: Jeff Garzik Subject: [PATCH] Remove obsolete code in 8390 driver Content-Type: multipart/mixed; boundary="------------040100050904050704010802" X-archive-position: 7156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: p_gortmaker@yahoo.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040100050904050704010802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The 8390 drivers had provision for using a single Tx buffer, which was educational back in the day when it served as an example driver, but it really hasn't been used and can go away which will make future maintenance easier. Patch against vanilla 2.6.7. Thanks, Paul. --------------040100050904050704010802 Content-Type: text/plain; name="2.6.7-8390-no-1Tx-diff0" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6.7-8390-no-1Tx-diff0" diff -ur linux/drivers/net/8390.c linux-8390/drivers/net/8390.c --- linux/drivers/net/8390.c Sun May 9 19:33:36 2004 +++ linux-8390/drivers/net/8390.c Mon Jul 26 01:15:39 2004 @@ -41,6 +41,7 @@ module by all drivers that require it. Alan Cox : Spinlocking work, added 'BUG_83C690' Paul Gortmaker : Separate out Tx timeout code from Tx path. + Paul Gortmaker : Remove old unused single Tx buffer code. Sources: The National Semiconductor LAN Databook, and the 3Com 3c503 databook. @@ -289,8 +290,6 @@ send_length = ETH_ZLEN < length ? length : ETH_ZLEN; -#ifdef EI_PINGPONG - /* * We have two Tx slots available for use. Find the first free * slot, and then perform some sanity checks. With two Tx bufs, @@ -309,7 +308,7 @@ } else if (ei_local->tx2 == 0) { - output_page = ei_local->tx_start_page + TX_1X_PAGES; + output_page = ei_local->tx_start_page + TX_PAGES/2; ei_local->tx2 = send_length; if (ei_debug && ei_local->tx1 > 0) printk(KERN_DEBUG "%s: idle transmitter, tx1=%d, lasttx=%d, txing=%d.\n", @@ -366,28 +365,6 @@ else netif_start_queue(dev); -#else /* EI_PINGPONG */ - - /* - * Only one Tx buffer in use. You need two Tx bufs to come close to - * back-to-back transmits. Expect a 20 -> 25% performance hit on - * reasonable hardware if you only use one Tx buffer. - */ - - if (length == send_length) - ei_block_output(dev, length, skb->data, ei_local->tx_start_page); - else { - memset(scratch, 0, ETH_ZLEN); - memcpy(scratch, skb->data, skb->len); - ei_block_output(dev, ETH_ZLEN, scratch, ei_local->tx_start_page); - } - ei_local->txing = 1; - NS8390_trigger_send(dev, send_length, ei_local->tx_start_page); - dev->trans_start = jiffies; - netif_stop_queue(dev); - -#endif /* EI_PINGPONG */ - /* Turn 8390 interrupts back on. */ ei_local->irqlock = 0; outb_p(ENISR_ALL, e8390_base + EN0_IMR); @@ -590,8 +567,6 @@ outb_p(ENISR_TX, e8390_base + EN0_ISR); /* Ack intr. */ -#ifdef EI_PINGPONG - /* * There are two Tx buffers, see which one finished, and trigger * the send of another one if it exists. @@ -633,13 +608,6 @@ } // else printk(KERN_WARNING "%s: unexpected TX-done interrupt, lasttx=%d.\n", // dev->name, ei_local->lasttx); - -#else /* EI_PINGPONG */ - /* - * Single Tx buffer: mark it free so another packet can be loaded. - */ - ei_local->txing = 0; -#endif /* Minimize Tx latency: update the statistics after we restart TXing. */ if (status & ENTSR_COL) diff -ur linux/drivers/net/8390.h linux-8390/drivers/net/8390.h --- linux/drivers/net/8390.h Tue Jun 15 22:20:42 2004 +++ linux-8390/drivers/net/8390.h Mon Jul 26 01:10:51 2004 @@ -12,17 +12,7 @@ #include #include -#define TX_2X_PAGES 12 -#define TX_1X_PAGES 6 - -/* Should always use two Tx slots to get back-to-back transmits. */ -#define EI_PINGPONG - -#ifdef EI_PINGPONG -#define TX_PAGES TX_2X_PAGES -#else -#define TX_PAGES TX_1X_PAGES -#endif +#define TX_PAGES 12 /* Two Tx slots */ #define ETHER_ADDR_LEN 6 --------------040100050904050704010802-- From margitsw@t-online.de Mon Jul 26 06:19:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 06:19:26 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QDJKp8030068 for ; Mon, 26 Jul 2004 06:19:20 -0700 Received: from fwd02.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1Bp5NQ-0008Iw-08; Mon, 26 Jul 2004 15:18:48 +0200 Received: from roglap.local (r9rmRcZLoeVnGggr5ua+9pG6fyngZwyDy+Sw53nSgfPuu95yQHLwg6@[217.226.125.229]) by fwd02.sul.t-online.com with esmtp id 1Bp5NC-1gFjcG0; Mon, 26 Jul 2004 15:18:34 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Fix null pointer reference (Bug 100) Date: Mon, 26 Jul 2004 15:10:45 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_VLQBB+T1w2GWG9d" Message-Id: <200407261510.45615.margitsw@t-online.de> X-ID: r9rmRcZLoeVnGggr5ua+9pG6fyngZwyDy+Sw53nSgfPuu95yQHLwg6 X-archive-position: 7159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 2174 Lines: 76 --Boundary-00=_VLQBB+T1w2GWG9d Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-22 Margit Schubert-While * prism54_get/set_debug_oid are missing checks for a null pointer. Reported in Bugzilla number 100. Margit --Boundary-00=_VLQBB+T1w2GWG9d Content-Type: text/x-diff; charset="us-ascii"; name="bugptr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bugptr.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.8-04/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.8-01/drivers/net/wireless/prism54/isl_ioctl.c 2004-07-01 07:23:52.000000000 +0200 +++ linux-2.6.8-04/drivers/net/wireless/prism54/isl_ioctl.c 2004-07-26 10:35:17.000000000 +0200 @@ -1942,7 +1942,7 @@ { islpci_private *priv = netdev_priv(ndev); struct islpci_mgmtframe *response = NULL; - int ret = -EIO, response_op = PIMFOR_OP_ERROR; + int ret = -EIO; printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); data->length = 0; @@ -1952,9 +1952,7 @@ islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, priv->priv_oid, extra, 256, &response); - response_op = response->header->operation; printk("%s: ret: %i\n", ndev->name, ret); - printk("%s: response_op: %i\n", ndev->name, response_op); if (ret || !response || response->header->operation == PIMFOR_OP_ERROR) { if (response) { @@ -1991,16 +1989,20 @@ priv->priv_oid, extra, data->length, &response); printk("%s: ret: %i\n", ndev->name, ret); + if (ret || !response + || response->header->operation == PIMFOR_OP_ERROR) { + if (response) { + islpci_mgt_release(response); + } + printk("%s: EIO\n", ndev->name); + ret = -EIO; + } if (!ret) { response_op = response->header->operation; printk("%s: response_op: %i\n", ndev->name, response_op); islpci_mgt_release(response); } - if (ret || response_op == PIMFOR_OP_ERROR) { - printk("%s: EIO\n", ndev->name); - ret = -EIO; - } } return (ret ? ret : -EINPROGRESS); --Boundary-00=_VLQBB+T1w2GWG9d-- From jameshubbard@gmail.com Mon Jul 26 06:49:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 06:50:03 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QDnwOc001559 for ; Mon, 26 Jul 2004 06:49:58 -0700 Received: by mproxy.gmail.com with SMTP id 73so70165rnk for ; Mon, 26 Jul 2004 06:49:55 -0700 (PDT) Received: by 10.38.81.69 with SMTP id e69mr214776rnb; Mon, 26 Jul 2004 06:49:55 -0700 (PDT) Message-ID: Date: Mon, 26 Jul 2004 09:49:55 -0400 From: James Hubbard To: Pekka Pietikainen Subject: Re: Broadcom 4400 driver bm44 Cc: netdev@oss.sgi.com In-Reply-To: <20040708204346.GA28693@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040708133853.GA20254@ee.oulu.fi> <20040708204346.GA28693@ee.oulu.fi> X-archive-position: 7160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jameshubbard@gmail.com Precedence: bulk X-list: netdev Content-Length: 1004 Lines: 29 On Thu, 8 Jul 2004 23:43:46 +0300, Pekka Pietikainen wrote: > Ok, after some digging around ALLMULTI breaking is not a bug, the > vendor-provided driver seems to break in similar ways, at least on 2.6, > so that's a feature unless they fix it in theirs so I can copy the fix :-) > > I put a lots'o'debugging + some bit-flipping reordering to look > more like bcm4400 version at http://www.ee.oulu.fi/~pp/b44-test.tgz. > Probably won't fix the problem, but it's worth a shot I suppose. > > Should compile with > > make -C /lib/modules//build modules SUBDIRS=$PWD > > As a workaround I suppose ifconfig eth1 promisc might do the trick too. > Hello, Just to let you know, I've not forgotten about this problem. I've got another Dell laptop that I can reproduce it on. I'm going to try to get the stock 2.6.7 kernel on it and try it out. Hopefully I can get you some more information by the end of the week. James -- James Hubbard http://www.mcs.uvawise.edu/~jhubbard From sri@us.ibm.com Mon Jul 26 06:51:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 06:51:37 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QDpV74002499 for ; Mon, 26 Jul 2004 06:51:32 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6QDpGDb321166; Mon, 26 Jul 2004 09:51:16 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6QDpDFN412464; Mon, 26 Jul 2004 07:51:15 -0600 Message-ID: <41050C5C.202@us.ibm.com> Date: Mon, 26 Jul 2004 15:51:24 +0200 From: Sridhar Samudrala User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [BK PATCH] 2.6 SCTP updates References: <20040724222731.0ed048ef.davem@redhat.com> In-Reply-To: <20040724222731.0ed048ef.davem@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 632 Lines: 30 David S. Miller wrote: >On Fri, 23 Jul 2004 17:18:11 -0700 (PDT) >Sridhar Samudrala wrote: > > > >>Please do a >> bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work >> >>to get the following SCTP updates to 2.6.8-rc2. >> >> > >Pulled, thanks Sridhar. Will there be a 2.4.x version of >any of these SCTP changes? > > > Dave, I plan to submit a 2.4 version of these patches along with the 2.6 sparse cleanup stuff so that both the codebases don't deviate too much, but it may be a couple of weeks from now. I am currently at an SCTP interop event and will be on vacation next week. Thanks Sridhar From DanE@aiinet.com Mon Jul 26 06:57:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 06:57:35 -0700 (PDT) Received: from aiexchange.ai.aiinet.com (ai181-26.aiinet.com [205.245.181.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QDvQ6W003123 for ; Mon, 26 Jul 2004 06:57:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] get_random_bytes returns the same on every boot Date: Mon, 26 Jul 2004 09:57:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] get_random_bytes returns the same on every boot Thread-Index: AcRwQ8wUAT76ixO3Rmym6D+yRq5zWQC0/K6Q From: "Eble, Dan" To: "Balint Marton" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6QDvQ6W003123 X-archive-position: 7162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: DanE@aiinet.com Precedence: bulk X-list: netdev Content-Length: 479 Lines: 11 Balint Marton wrote: > At boot time, get_random_bytes always returns the same > random data, as if there were a constant random seed. > packet with always the same transaction ID. (If you have > more than one computers, and they are booting at the > same time, then this is a big problem) If many systems are booting at the same time, is seeding with the system time really an appropriate solution? Shouldn't some system-specific value also contribute to the randomization? From pp@ee.oulu.fi Mon Jul 26 07:11:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 07:11:46 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QEBbtI004315 for ; Mon, 26 Jul 2004 07:11:40 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.11/8.12.11) with ESMTP id i6QEBXJl002924; Mon, 26 Jul 2004 17:11:33 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.13.0/8.13.0/Submit) id i6QEBSCC026886; Mon, 26 Jul 2004 17:11:28 +0300 (EEST) Date: Mon, 26 Jul 2004 17:11:28 +0300 From: Pekka Pietikainen To: Florian Schirmer Cc: jgarzik@pobox.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: b44: add 47xx support Message-ID: <20040726141128.GA5435@ee.oulu.fi> References: <200407232335.37809.jolt@tuxbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200407232335.37809.jolt@tuxbox.org> User-Agent: Mutt/1.4.2i X-archive-position: 7164 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev Content-Length: 869 Lines: 26 On Fri, Jul 23, 2004 at 11:35:30PM +0200, Florian Schirmer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > this patch adds support for the BCM47xx device to the b44 driver. Please > apply. > > BTW what happened to the 1GB DMA fix? The SiliconBackplane cores _are_ limited > to a 1GB DMA window so we need to take that into account. Any reason why > those patches where dropped? Hiya Looks good (well, won't be able to test that it doesn't break 4401 until next week :-) ). As for the 1GB patch going in, I sure hope they would (perhaps in a cleaned up state, it might be more pretty if I just unconditionally enabled the workaround and had a b44_alloc_skb() that tries a normal dev_alloc_skb and if that gives something over 1GB retry with GFP_DMA... A situation where it breaks even without 4g4g would help in getting the patch in :-) From ptsjohol@cc.jyu.fi Mon Jul 26 08:16:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 08:16:14 -0700 (PDT) Received: from posti5.jyu.fi (posti5.jyu.fi [130.234.4.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QFG5gr012615 for ; Mon, 26 Jul 2004 08:16:06 -0700 Received: from silmu.st.jyu.fi (IDENT:ULzj6PxenA1tuPbt14q6jSMLI/PIXDju@silmu.st.jyu.fi [130.234.4.64]) by posti5.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6QFFccn004985; Mon, 26 Jul 2004 18:15:38 +0300 Date: Mon, 26 Jul 2004 18:15:34 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Francois Romieu cc: H?ctor Mart?n , Linux-Kernel , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <20040725235927.B30025@electric-eye.fr.zoreil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti5.jyu.fi; Mon, 26 Jul 2004 18:15:40 +0300 X-archive-position: 7165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev Content-Length: 7556 Lines: 204 On Sun, 25 Jul 2004, Francois Romieu wrote: > Pasi Sjoholm : > [...] > > I haven't been able to reproduce this with normal www-browsing or > > ssh-connections but it's always reproducible when my eth0 is under heavy > > load. > I guess it can be reproduced even if the binary (nvidia ?) module is never > loaded after boot, right ? After 24 hours of hard working I can answer yes to this question. Now I can reproduce this from 2 to 15 minutes with 2 cp-processes from samba->workstation->nfs, some software building with make -j 3, playing some mp3 via nfs to notice when kernel goes down.. =) and so on.. After that ksoftirqd takes almost all the cpu-time and the network is not working at all. First I made some debugging with: -- readprofile -r sleep 10 readprofile -n -v -m /boot/System.map-2.6.7-mm7| sort -n +2 | tail -40 -- I tried this tree different times and here are the results: -1- c0114020 unshare_files 1 0.0104 c0134400 vma_prio_tree_add 1 0.0057 c01f1c50 fast_clear_page 1 0.0104 c01f2190 __copy_to_user_ll 7 0.0625 c017dbf0 write_profile 9 0.1406 c02d1f50 net_rx_action 10 0.0368 00000000 total 29 0.0000 -1- -2- c0111c80 finish_task_switch 1 0.0069 c011f9e0 get_signal_to_deliver 1 0.0012 c01364c0 __kmalloc 1 0.0078 c013ad60 copy_page_range 1 0.0017 c0141370 page_remove_rmap 1 0.0069 c014a9f0 do_sync_write 1 0.0057 c014aaa0 vfs_write 1 0.0033 c0195840 start_this_handle 1 0.0010 c01f1c20 add_timer_randomness 1 0.0035 c023f4e0 idedisk_release 1 0.0052 c017dbf0 write_profile 5 0.0781 c01f1f30 extract_entropy 5 0.0060 c02d1f90 rt_may_expire 14 0.0972 00000000 total 34 0.0000 -2- -3- c01105b0 do_page_fault 1 0.0007 c012d920 find_lock_page 1 0.0045 c0131130 bad_page 1 0.0063 c01ec430 slow_copy_page 1 0.0208 c01ec2f0 fast_copy_page 3 0.0117 c017dcf0 kclist_add 4 0.0625 c01ec900 copy_from_user 4 0.0312 c02c5f00 dev_ifname 6 0.0341 00000000 total 21 0.0000 -3- There are quite few ticks in total-rows at least when you are comparing to normal operation of kernel: -- c017dcf0 kclist_add 9 0.1406 c0119100 __do_softirq 268 2.0938 c0101eb0 default_idle 9396 195.7500 00000000 total 9779 0.0043 -- Also made some debugging with patch which Andrew Morton gave to brad (http://seclists.org/lists/linux-kernel/2004/Mar/2295.html) --cut-- diff -puN include/linux/kernel.h~proc-sys-debug include/linux/kernel.h --- 25/include/linux/kernel.h~proc-sys-debug 2004-02-25 23:12:56.000000000 -0800+++ 25-akpm/include/linux/kernel.h 2004-02-25 23:12:57.000000000 -0800 @@ -214,6 +214,8 @@ extern void dump_stack(void); 1; \ }) +extern int proc_sys_debug[8]; + #endif /* __KERNEL__ */ #define SI_LOAD_SHIFT 16 diff -puN -L kernel/ksyms.c /dev/null /dev/null diff -puN kernel/sysctl.c~proc-sys-debug kernel/sysctl.c --- 25/kernel/sysctl.c~proc-sys-debug 2004-02-25 23:12:56.000000000 -0800 +++ 25-akpm/kernel/sysctl.c 2004-02-25 23:21:37.000000000 -0800 @@ -849,7 +849,26 @@ static ctl_table fs_table[] = { { .ctl_name = 0 } }; +int proc_sys_debug[8]; +EXPORT_SYMBOL(proc_sys_debug); + static ctl_table debug_table[] = { + {1, "0", &proc_sys_debug[0], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, + {2, "1", &proc_sys_debug[1], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, + {3, "2", &proc_sys_debug[2], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, + {4, "3", &proc_sys_debug[3], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, + {5, "4", &proc_sys_debug[4], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, + {6, "5", &proc_sys_debug[5], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, + {7, "6", &proc_sys_debug[6], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, + {8, "7", &proc_sys_debug[7], sizeof(int), 0644, NULL, + &proc_dointvec_minmax, &sysctl_intvec, NULL, NULL, NULL}, { .ctl_name = 0 } }; _ kernel/softirq.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletion(-) diff -puN kernel/softirq.c~a kernel/softirq.c --- 25/kernel/softirq.c~a 2004-03-11 02:05:20.000000000 -0800 +++ 25-akpm/kernel/softirq.c 2004-03-11 02:06:02.000000000 -0800 @@ -54,8 +54,13 @@ static inline void wakeup_softirqd(void) /* Interrupts are disabled: no need to stop preemption */ struct task_struct *tsk = __get_cpu_var(ksoftirqd); - if (tsk && tsk->state != TASK_RUNNING) + if (tsk && tsk->state != TASK_RUNNING) { + if (proc_sys_debug[0]) { + printk("%s wakes ksoftirqd\n", current->comm); + dump_stack(); + } wake_up_process(tsk); + } } --cut-- and running: dmesg -c echo 1 > /proc/sys/debug/0 ; sleep 5; echo 0 > /proc/sys/debug/0 dmesg -s 1000000 > /tmp/foo but it resulted nothing in /tmp/foo and ksoftirqd was eating my cpu time. SysRq: Show regs gave this: -- Pid: 2, comm: ksoftirqd/0 EIP: 0060:[] CPU: 0 EIP is at rtl8139_poll+0xb4/0x100 [8139too] EFLAGS: 00000247 Not tainted (2.6.7-mm7) EAX: ffffe000 EBX: 00000040 ECX: df4824f8 EDX: c0441978 ESI: df482400 EDI: e0868000 EBP: dff85f80 DS: 007b ES: 007b CR0: 8005003b CR2: b7c5a000 CR3: 1fafd000 CR4: 000006d0 [] ksoftirqd+0x0/0xc0 [] net_rx_action+0x6a/0x110 [] __do_softirq+0xa9/0xb0 [] do_softirq+0x27/0x30 [] ksoftirqd+0x68/0xc0 [] kthread+0xa5/0xb0 [] kthread+0x0/0xb0 [] kernel_thread_helper+0x5/0x14 -- I'm not a kernel expert but it would seem that ksoftirqd is in some sort a loop because I didn't get any "printk("%s wakes ksoftirqd\n", current->comm);"-lines. And rtl8139_poll-function in rtl-8139-drivers is a function made directly for NAPI's poll(). But for me is hard to say what's wrong... I will try other 8139-card later today if it has a same problem. > [...] > > Same thing for me also, except for me it's interrupt 10 (CMI8738-MC6, > > eth0), so it's pointing more and more something rtl-8139 related. > Possible. Which 8139 module do you use ? 8139too. > It would be nice if this thread could be fed to netdev@oss.sgi.com. Included in cc. I haven't changed anything else in my hardware but just upgraded my 10Mbps hub to 100Mbps switch. I guess 10Mbps wasn't generating too many interrupts. =) Hope this helps.. -- Pasi Sjöholm From kalev@smartlink.ee Mon Jul 26 08:54:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 08:54:56 -0700 (PDT) Received: from kiire.colleduc.ee (myyr.colleduc.ee [193.40.113.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QFsmI2022175 for ; Mon, 26 Jul 2004 08:54:50 -0700 Received: from smartlink.ee (mail.smartlink.ee [213.180.16.242]) (authenticated bits=0) by kiire.colleduc.ee (8.12.11/8.12.10) with ESMTP id i6QFsV8D011434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jul 2004 18:54:32 +0300 Message-ID: <41052937.5010101@smartlink.ee> Date: Mon, 26 Jul 2004 18:54:31 +0300 From: Kalev Lember User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jgarzik@pobox.com CC: netdev@oss.sgi.com, manfred@colorfullife.com Subject: [PATCH] natsemi netpoll support Content-Type: multipart/mixed; boundary="------------030605060906010102010202" X-Virus-Scanned: clamd / ClamAV version 0.72, clamav-milter version 0.72 on localhost X-Virus-Status: Clean X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.26.0.10; VDF 6.26.0.43 X-archive-position: 7166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kalev@smartlink.ee Precedence: bulk X-list: netdev Content-Length: 1913 Lines: 61 This is a multi-part message in MIME format. --------------030605060906010102010202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I have implemented netpoll support in natsemi.c. I am sending you the patch, it is against linux-2.6.8-rc2. It has not recieved a lot of testing, I can only tell that netconsole now works for me. -- Best regards, Kalev Lember --------------030605060906010102010202 Content-Type: text/x-patch; name="natsemi_netconsole.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="natsemi_netconsole.diff" --- linux-2.6.8-rc2/drivers/net/natsemi.c.orig 2004-07-25 23:37:05.000000000 +0300 +++ linux-2.6.8-rc2/drivers/net/natsemi.c 2004-07-26 00:02:32.000000000 +0300 @@ -750,6 +750,7 @@ static void netdev_error(struct net_devi static void netdev_rx(struct net_device *dev); static void netdev_tx_done(struct net_device *dev); static int natsemi_change_mtu(struct net_device *dev, int new_mtu); +static void natsemi_poll_controller(struct net_device *dev); static void __set_rx_mode(struct net_device *dev); static void set_rx_mode(struct net_device *dev); static void __get_stats(struct net_device *dev); @@ -920,6 +921,9 @@ static int __devinit natsemi_probe1 (str dev->do_ioctl = &netdev_ioctl; dev->tx_timeout = &tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller = &natsemi_poll_controller; +#endif if (mtu) dev->mtu = mtu; @@ -2364,6 +2368,15 @@ static struct net_device_stats *get_stat return &np->stats; } +#ifdef CONFIG_NET_POLL_CONTROLLER +static void natsemi_poll_controller(struct net_device *dev) +{ + disable_irq(dev->irq); + intr_handler(dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif + #define HASH_TABLE 0x200 static void __set_rx_mode(struct net_device *dev) { --------------030605060906010102010202-- From Robert.Olsson@data.slu.se Mon Jul 26 09:38:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 09:38:21 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QGcFV5001745 for ; Mon, 26 Jul 2004 09:38:15 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6QGbPIR023607; Mon, 26 Jul 2004 18:37:25 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 1FED3EC33E; Mon, 26 Jul 2004 18:37:26 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16645.13126.52445.630789@robur.slu.se> Date: Mon, 26 Jul 2004 18:37:26 +0200 To: Pasi Sjoholm Cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <20040725235927.B30025@electric-eye.fr.zoreil.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1462 Lines: 41 Pasi Sjoholm writes: > Pid: 2, comm: ksoftirqd/0 > EIP: 0060:[] CPU: 0 > EIP is at rtl8139_poll+0xb4/0x100 [8139too] > EFLAGS: 00000247 Not tainted (2.6.7-mm7) > EAX: ffffe000 EBX: 00000040 ECX: df4824f8 EDX: c0441978 > ESI: df482400 EDI: e0868000 EBP: dff85f80 DS: 007b ES: 007b > CR0: 8005003b CR2: b7c5a000 CR3: 1fafd000 CR4: 000006d0 > [] ksoftirqd+0x0/0xc0 > [] net_rx_action+0x6a/0x110 > [] __do_softirq+0xa9/0xb0 > [] do_softirq+0x27/0x30 > [] ksoftirqd+0x68/0xc0 > [] kthread+0xa5/0xb0 > [] kthread+0x0/0xb0 > [] kernel_thread_helper+0x5/0x14 > -- > > I'm not a kernel expert but it would seem that ksoftirqd is in some sort a > loop because I didn't get any "printk("%s wakes ksoftirqd\n", > current->comm);"-lines. Hello! This looks very much like the problem we see when doing route DoS testing with Alexey. In summary: High softirq loads can totally kill userland. The reason is that do_softirq() is run from many places hard interrupts, local_bh_enable etc and bypasses the ksoftirqd protection. It just been discussed at OLS with Andrea and Dipankar and others. Current RCU suffers from this problem as well. I've experimented some code to defer softirq's to ksoftirqd after a time as well as deferring all softirq's to ksoftirqd. Andrea had some ideas as well as Ingo. Cheers. --ro From shemminger@osdl.org Mon Jul 26 09:55:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 09:55:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QGtnZM005169 for ; Mon, 26 Jul 2004 09:55:51 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6QGt5109790; Mon, 26 Jul 2004 09:55:05 -0700 Date: Mon, 26 Jul 2004 09:55:05 -0700 From: Stephen Hemminger To: Pasi Sjoholm Cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) Message-Id: <20040726095505.2ddb3bec@dell_ss3.pdx.osdl.net> In-Reply-To: References: <20040725235927.B30025@electric-eye.fr.zoreil.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1035 Lines: 24 On Mon, 26 Jul 2004 18:15:34 +0300 (EEST) Pasi Sjoholm wrote: > On Sun, 25 Jul 2004, Francois Romieu wrote: > > > Pasi Sjoholm : > > [...] > > > I haven't been able to reproduce this with normal www-browsing or > > > ssh-connections but it's always reproducible when my eth0 is under heavy > > > load. > > I guess it can be reproduced even if the binary (nvidia ?) module is never > > loaded after boot, right ? > > After 24 hours of hard working I can answer yes to this question. > Now I can reproduce this from 2 to 15 minutes with 2 cp-processes from > samba->workstation->nfs, some software building with make -j 3, playing > some mp3 via nfs to notice when kernel goes down.. =) and so on.. > > After that ksoftirqd takes almost all the cpu-time and the network is not > working at all. Is network traffic still coming in? or perhaps there is a network packet that causes some soft irq to go into an infinite loop. The recent iptables bug with ip options would be an example. From shemminger@osdl.org Mon Jul 26 11:34:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 11:34:25 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QIYGwQ009087 for ; Mon, 26 Jul 2004 11:34:16 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6QIY2126046; Mon, 26 Jul 2004 11:34:02 -0700 Date: Mon, 26 Jul 2004 11:34:02 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] de-inline qdiscipline locking functions. Message-Id: <20040726113402.25ba72ee@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 7323 Lines: 266 This qdisc code has several inline functions for locking that is only used when adding/deleting queuing disciplines; so make them functions instead. The new qdisc_lock_tree encapsulates the locking used throughout this code. Also qdisc_run() is only called from net/core/dev.c so it should be defined there. Signed-off-by: Stephen Hemminger diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h --- a/include/net/pkt_sched.h 2004-07-26 10:21:24 -07:00 +++ b/include/net/pkt_sched.h 2004-07-26 10:21:24 -07:00 @@ -105,43 +105,15 @@ int refcnt; }; -static inline void sch_tree_lock(struct Qdisc *q) -{ - write_lock(&qdisc_tree_lock); - spin_lock_bh(&q->dev->queue_lock); -} - -static inline void sch_tree_unlock(struct Qdisc *q) -{ - spin_unlock_bh(&q->dev->queue_lock); - write_unlock(&qdisc_tree_lock); -} - -static inline void tcf_tree_lock(struct tcf_proto *tp) -{ - write_lock(&qdisc_tree_lock); - spin_lock_bh(&tp->q->dev->queue_lock); -} - -static inline void tcf_tree_unlock(struct tcf_proto *tp) -{ - spin_unlock_bh(&tp->q->dev->queue_lock); - write_unlock(&qdisc_tree_lock); -} +extern void qdisc_lock_tree(struct net_device *dev); +extern void qdisc_unlock_tree(struct net_device *dev); +#define sch_tree_lock(q) qdisc_lock_tree((q)->dev) +#define sch_tree_unlock(q) qdisc_unlock_tree((q)->dev) +#define tcf_tree_lock(tp) qdisc_lock_tree((tp)->q->dev) +#define tcf_tree_unlock(tp) qdisc_unlock_tree((tp)->q->dev) -static inline unsigned long -cls_set_class(struct tcf_proto *tp, unsigned long *clp, unsigned long cl) -{ - unsigned long old_cl; - - tcf_tree_lock(tp); - old_cl = *clp; - *clp = cl; - tcf_tree_unlock(tp); - return old_cl; -} - +#define cls_set_class(tp, clp, cl) tcf_set_class(tp, clp, cl) static inline unsigned long __cls_set_class(unsigned long *clp, unsigned long cl) { @@ -407,6 +379,8 @@ extern int tcf_act_police(struct sk_buff **skb, struct tc_action *a); #endif +extern unsigned long tcf_set_class(struct tcf_proto *tp, unsigned long *clp, + unsigned long cl); extern int tcf_police(struct sk_buff *skb, struct tcf_police *p); extern int qdisc_copy_stats(struct sk_buff *skb, struct tc_stats *st, spinlock_t *lock); extern void tcf_police_destroy(struct tcf_police *p); @@ -457,13 +431,6 @@ void qdisc_put_rtab(struct qdisc_rate_table *tab); extern int qdisc_restart(struct net_device *dev); - -static inline void qdisc_run(struct net_device *dev) -{ - while (!netif_queue_stopped(dev) && - qdisc_restart(dev)<0) - /* NOTHING */; -} /* Calculate maximal size of packet seen by hard_start_xmit routine of this device. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2004-07-26 10:21:24 -07:00 +++ b/net/core/dev.c 2004-07-26 10:21:24 -07:00 @@ -1320,6 +1320,13 @@ } \ } +static inline void qdisc_run(struct net_device *dev) +{ + while (!netif_queue_stopped(dev) && + qdisc_restart(dev)<0) + /* NOTHING */; +} + /** * dev_queue_xmit - transmit a buffer * @skb: buffer to transmit diff -Nru a/net/sched/cls_api.c b/net/sched/cls_api.c --- a/net/sched/cls_api.c 2004-07-26 10:21:24 -07:00 +++ b/net/sched/cls_api.c 2004-07-26 10:21:24 -07:00 @@ -236,12 +236,12 @@ kfree(tp); goto errout; } - write_lock(&qdisc_tree_lock); - spin_lock_bh(&dev->queue_lock); + + qdisc_lock_tree(dev); tp->next = *back; *back = tp; - spin_unlock_bh(&dev->queue_lock); - write_unlock(&qdisc_tree_lock); + qdisc_unlock_tree(dev); + } else if (tca[TCA_KIND-1] && rtattr_strcmp(tca[TCA_KIND-1], tp->ops->kind)) goto errout; @@ -249,11 +249,10 @@ if (fh == 0) { if (n->nlmsg_type == RTM_DELTFILTER && t->tcm_handle == 0) { - write_lock(&qdisc_tree_lock); - spin_lock_bh(&dev->queue_lock); + qdisc_lock_tree(dev); *back = tp->next; - spin_unlock_bh(&dev->queue_lock); - write_unlock(&qdisc_tree_lock); + qdisc_unlock_tree(dev); + tfilter_notify(skb, n, tp, fh_s, RTM_DELTFILTER); tcf_destroy(tp); err = 0; @@ -294,6 +293,19 @@ return err; } +unsigned long tcf_set_class(struct tcf_proto *tp, unsigned long *clp, + unsigned long cl) +{ + unsigned long old_cl; + + tcf_tree_lock(tp); + old_cl = __cls_set_class(clp, cl); + tcf_tree_unlock(tp); + + return old_cl; +} + + static int tcf_fill_node(struct sk_buff *skb, struct tcf_proto *tp, unsigned long fh, u32 pid, u32 seq, unsigned flags, int event) @@ -459,3 +471,4 @@ EXPORT_SYMBOL(register_tcf_proto_ops); EXPORT_SYMBOL(unregister_tcf_proto_ops); +EXPORT_SYMBOL(tcf_set_class); diff -Nru a/net/sched/sch_api.c b/net/sched/sch_api.c --- a/net/sched/sch_api.c 2004-07-26 10:21:24 -07:00 +++ b/net/sched/sch_api.c 2004-07-26 10:21:24 -07:00 @@ -306,8 +306,7 @@ if (dev->flags & IFF_UP) dev_deactivate(dev); - write_lock(&qdisc_tree_lock); - spin_lock_bh(&dev->queue_lock); + qdisc_lock_tree(dev); if (qdisc && qdisc->flags&TCQ_F_INGRES) { oqdisc = dev->qdisc_ingress; /* Prune old scheduler */ @@ -334,8 +333,7 @@ dev->qdisc = &noop_qdisc; } - spin_unlock_bh(&dev->queue_lock); - write_unlock(&qdisc_tree_lock); + qdisc_unlock_tree(dev); if (dev->flags & IFF_UP) dev_activate(dev); @@ -454,10 +452,11 @@ * before we set a netdevice's qdisc pointer to sch */ smp_wmb(); if (!ops->init || (err = ops->init(sch, tca[TCA_OPTIONS-1])) == 0) { - write_lock(&qdisc_tree_lock); + qdisc_lock_tree(dev); sch->next = dev->qdisc_list; dev->qdisc_list = sch; - write_unlock(&qdisc_tree_lock); + qdisc_unlock_tree(dev); + #ifdef CONFIG_NET_ESTIMATOR if (tca[TCA_RATE-1]) qdisc_new_estimator(&sch->stats, sch->stats_lock, diff -Nru a/net/sched/sch_generic.c b/net/sched/sch_generic.c --- a/net/sched/sch_generic.c 2004-07-26 10:21:24 -07:00 +++ b/net/sched/sch_generic.c 2004-07-26 10:21:24 -07:00 @@ -54,6 +54,18 @@ */ rwlock_t qdisc_tree_lock = RW_LOCK_UNLOCKED; +void qdisc_lock_tree(struct net_device *dev) +{ + write_lock(&qdisc_tree_lock); + spin_lock_bh(&dev->queue_lock); +} + +void qdisc_unlock_tree(struct net_device *dev) +{ + spin_unlock_bh(&dev->queue_lock); + write_unlock(&qdisc_tree_lock); +} + /* dev->queue_lock serializes queue accesses for this device AND dev->qdisc pointer itself. @@ -513,13 +525,11 @@ void dev_init_scheduler(struct net_device *dev) { - write_lock(&qdisc_tree_lock); - spin_lock_bh(&dev->queue_lock); + qdisc_lock_tree(dev); dev->qdisc = &noop_qdisc; - spin_unlock_bh(&dev->queue_lock); dev->qdisc_sleeping = &noop_qdisc; dev->qdisc_list = NULL; - write_unlock(&qdisc_tree_lock); + qdisc_unlock_tree(dev); dev_watchdog_init(dev); } @@ -528,8 +538,7 @@ { struct Qdisc *qdisc; - write_lock(&qdisc_tree_lock); - spin_lock_bh(&dev->queue_lock); + qdisc_lock_tree(dev); qdisc = dev->qdisc_sleeping; dev->qdisc = &noop_qdisc; dev->qdisc_sleeping = &noop_qdisc; @@ -543,8 +552,7 @@ BUG_TRAP(dev->qdisc_list == NULL); BUG_TRAP(!timer_pending(&dev->watchdog_timer)); dev->qdisc_list = NULL; - spin_unlock_bh(&dev->queue_lock); - write_unlock(&qdisc_tree_lock); + qdisc_unlock_tree(dev); } EXPORT_SYMBOL(__netdev_watchdog_up); @@ -554,4 +562,5 @@ EXPORT_SYMBOL(qdisc_destroy); EXPORT_SYMBOL(qdisc_reset); EXPORT_SYMBOL(qdisc_restart); -EXPORT_SYMBOL(qdisc_tree_lock); +EXPORT_SYMBOL(qdisc_lock_tree); +EXPORT_SYMBOL(qdisc_unlock_tree); From cus@fazekas.hu Mon Jul 26 12:32:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 12:32:13 -0700 (PDT) Received: from cinke.fazekas.hu ([195.199.63.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QJW4LF015596 for ; Mon, 26 Jul 2004 12:32:06 -0700 Received: from localhost (localhost [127.0.0.1]) by cinke.fazekas.hu (Postfix) with ESMTP id A693A33CD2; Mon, 26 Jul 2004 21:31:40 +0200 (CEST) Received: from cinke.fazekas.hu ([127.0.0.1]) by localhost (cinke [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29722-14; Mon, 26 Jul 2004 21:31:38 +0200 (CEST) Received: from cinke.fazekas.hu (cinke.fazekas.hu [195.199.63.65]) by cinke.fazekas.hu (Postfix) with ESMTP id 7DC5933CD1; Mon, 26 Jul 2004 21:31:38 +0200 (CEST) Date: Mon, 26 Jul 2004 21:31:38 +0200 (CEST) From: Balint Marton To: "Eble, Dan" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: RE: [PATCH] get_random_bytes returns the same on every boot In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at fazekas.hu X-archive-position: 7170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cus@fazekas.hu Precedence: bulk X-list: netdev Content-Length: 1106 Lines: 23 On Mon, 26 Jul 2004, Eble, Dan wrote: > If many systems are booting at the same time, is seeding with the system > time really an appropriate solution? Shouldn't some system-specific > value also contribute to the randomization? Yes, i agree, it would be nicer, if we could also use some system-specific stuff for the seeding, but i don't know if there is such data during the initialization of the random module. For example, we may use the MAC address of a network device, but unless i am mistaken the initialization of such network devices take place after the random dirver init. By the way, i made a little test with 40 computers. They were totally equvivalent by hardware, and all of them had a synchronized system clock. I turned them on by Wake On LAN exactly at the same time. All of them used the kernel level ip autoconfig, all of them got their right IP address, and i didn't even find a line of DHCPNAK in the dhcpd logfile. Conclusion: Although using some system-specific data and the clock would be nicer, the system time alone also does the right thing dependably. bye, Cus From oxymoron@waste.org Mon Jul 26 14:06:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 14:06:35 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QL6PAs019819 for ; Mon, 26 Jul 2004 14:06:27 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6QL6EDj017009; Mon, 26 Jul 2004 16:06:14 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i6QL6Drq017005; Mon, 26 Jul 2004 16:06:13 -0500 Date: Mon, 26 Jul 2004 16:06:13 -0500 From: Matt Mackall To: Niranjan Cc: netdev@oss.sgi.com Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 Message-ID: <20040726210613.GR5414@waste.org> References: <20040724223310.68910.qmail@web53004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040724223310.68910.qmail@web53004.mail.yahoo.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 7171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 874 Lines: 22 On Sat, Jul 24, 2004 at 03:33:10PM -0700, Niranjan wrote: > Hi, > I am working on Linux Kernel 2.4.25. I am trying to > add cryptoapi (cryptoapi-0.1.0) support to wireless > lan driver (linux-wlan-ng-0.2.1.pre14) of prism-based > cards. Cardctl version is 3.1.31. > When I am using "null" as a encryption cipher to check > the coding sequence, everything is working fine. But > when I change it to any other cipher for e.g. > "blowfish" or "rc5", it is giving kernel panic. I have > included Ksymoops extract from the kernel Ooops > reports below. > Can anyone please help me in what can be possible > error by looking at the log ? > I will greatly appreciate any help in this matter. The cryptoapi currently decides to sleep at various points internally when digesting a block which is probably what you're seeing. -- Mathematics is the supreme nostalgia of our time. From ptsjohol@cc.jyu.fi Mon Jul 26 14:28:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 14:28:31 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QLSP7W020563 for ; Mon, 26 Jul 2004 14:28:25 -0700 Received: from silmu.st.jyu.fi (IDENT:mOuazBaPiyeSKxeLJ6A07+HeYIwjSyge@silmu.st.jyu.fi [130.234.4.64]) by posti6.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6QLS5ob004730; Tue, 27 Jul 2004 00:28:05 +0300 Date: Tue, 27 Jul 2004 00:28:04 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Stephen Hemminger cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <20040726095505.2ddb3bec@dell_ss3.pdx.osdl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti6.jyu.fi; Tue, 27 Jul 2004 00:28:07 +0300 X-archive-position: 7172 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev Content-Length: 1239 Lines: 33 On Mon, 26 Jul 2004, Stephen Hemminger wrote: >>>> I haven't been able to reproduce this with normal www-browsing or >>>> ssh-connections but it's always reproducible when my eth0 is under heavy >>>> load. >>> I guess it can be reproduced even if the binary (nvidia ?) module is never >>> loaded after boot, right ? >> After 24 hours of hard working I can answer yes to this question. >> Now I can reproduce this from 2 to 15 minutes with 2 cp-processes from >> samba->workstation->nfs, some software building with make -j 3, playing >> some mp3 via nfs to notice when kernel goes down.. =) and so on.. >> After that ksoftirqd takes almost all the cpu-time and the network is not >> working at all. > Is network traffic still coming in? At least tcpdump doesn't say anything, I can only see only arp-packets which my computer (not other computer's arp-packets) has made but no response to those. > or perhaps there is a network packet that causes some soft irq to go > into an infinite loop. The recent iptables bug with ip options would be > an example. That would make sense but Robert Olsson had some knowledge of this and said that this issue is probably the same that they have discussed in OSL. -- Pasi Sjöholm From ptsjohol@cc.jyu.fi Mon Jul 26 14:47:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 14:47:23 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QLlGmh021156 for ; Mon, 26 Jul 2004 14:47:17 -0700 Received: from silmu.st.jyu.fi (IDENT:wLVgyOkS5QakeubTnm/ZeupN7jEfVK7W@silmu.st.jyu.fi [130.234.4.64]) by posti6.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6QLktob004858; Tue, 27 Jul 2004 00:46:55 +0300 Date: Tue, 27 Jul 2004 00:46:54 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Robert Olsson cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16645.13126.52445.630789@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti6.jyu.fi; Tue, 27 Jul 2004 00:46:56 +0300 X-archive-position: 7173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev Content-Length: 1960 Lines: 53 On Mon, 26 Jul 2004, Robert Olsson wrote: > Pasi Sjoholm writes: > > Pid: 2, comm: ksoftirqd/0 > > EIP: 0060:[] CPU: 0 > > EIP is at rtl8139_poll+0xb4/0x100 [8139too] > > EFLAGS: 00000247 Not tainted (2.6.7-mm7) > > EAX: ffffe000 EBX: 00000040 ECX: df4824f8 EDX: c0441978 > > ESI: df482400 EDI: e0868000 EBP: dff85f80 DS: 007b ES: 007b > > CR0: 8005003b CR2: b7c5a000 CR3: 1fafd000 CR4: 000006d0 > > [] ksoftirqd+0x0/0xc0 > > [] net_rx_action+0x6a/0x110 > > [] __do_softirq+0xa9/0xb0 > > [] do_softirq+0x27/0x30 > > [] ksoftirqd+0x68/0xc0 > > [] kthread+0xa5/0xb0 > > [] kthread+0x0/0xb0 > > [] kernel_thread_helper+0x5/0x14 > > -- > > I'm not a kernel expert but it would seem that ksoftirqd is in some sort a > > loop because I didn't get any "printk("%s wakes ksoftirqd\n", > > current->comm);"-lines. > Hello! Hur är läget Robert?-) > This looks very much like the problem we see when doing route DoS testing > with Alexey. Hmm, at least it sounds like same problem and in both situations network interface is kept busy. > In summary: High softirq loads can totally kill userland. The reason is that > do_softirq() is run from many places hard interrupts, local_bh_enable etc > and bypasses the ksoftirqd protection. It just been discussed at OLS with > Andrea and Dipankar and others. Current RCU suffers from this problem as well. Ok, this explanation makes sense and my point of view I think this is quite critical problem if you can "crash" linux kernel just sending enough packets to network interface for an example. > I've experimented some code to defer softirq's to ksoftirqd after a time as > well as deferring all softirq's to ksoftirqd. Andrea had some ideas as well > as Ingo. I would be more than glad to help you in testing if you want to publish some patches. -- Pasi Sjöholm From afleming@freescale.com Mon Jul 26 15:07:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 15:07:17 -0700 (PDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QM78jl021847 for ; Mon, 26 Jul 2004 15:07:08 -0700 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i6QM7YJW008012; Mon, 26 Jul 2004 15:07:34 -0700 (MST) Received: from [10.82.16.241] ([10.82.16.241]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i6QM6eGQ017633; Mon, 26 Jul 2004 17:06:40 -0500 In-Reply-To: <40EB89CC.2040100@pobox.com> References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <40EB89CC.2040100@pobox.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/mixed; boundary=Apple-Mail-1-903248500 Message-Id: <10E7AA25-DF50-11D8-90B5-000393C30512@freescale.com> Cc: Andy Fleming , , Kumar Gala , , From: Andy Fleming Subject: Re: [RFR] gianfar ethernet driver Date: Mon, 26 Jul 2004 17:06:37 -0500 To: Jeff Garzik X-Mailer: Apple Mail (2.618) X-archive-position: 7174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 72918 Lines: 2484 --Apple-Mail-1-903248500 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Argh. We found a couple bugs in that last patch. This patch fixes those bugs. However, please note that the patch is done against the original submission from weeks ago. This patch replaces my most recent patch. --Apple-Mail-1-903248500 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="mypatch" Content-Disposition: attachment; filename=mypatch diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c --- a/drivers/net/gianfar.c Mon Jul 26 17:01:55 2004 +++ b/drivers/net/gianfar.c Mon Jul 26 17:01:55 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -101,11 +101,6 @@ #include #endif -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,41) -#define irqreturn_t void -#define IRQ_HANDLED -#endif - #define TX_TIMEOUT (1*HZ) #define SKB_ALLOC_TIMEOUT 1000000 #undef BRIEF_GFAR_ERRORS @@ -117,9 +112,8 @@ #define RECEIVE(x) netif_rx(x) #endif -#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.0, " -char gfar_driver_name[] = "Gianfar Ethernet"; -char gfar_driver_version[] = "1.0"; +const char gfar_driver_name[] = "Gianfar Ethernet"; +const char gfar_driver_version[] = "1.1"; int startup_gfar(struct net_device *dev); static int gfar_enet_open(struct net_device *dev); @@ -152,12 +146,9 @@ static int gfar_accept_fastpath(struct net_device *dev, struct dst_entry *dst); #endif static inline int try_fastroute(struct sk_buff *skb, struct net_device *dev, int length); -#ifdef CONFIG_GFAR_NAPI static int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit); -#else -static int gfar_clean_rx_ring(struct net_device *dev); -#endif static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb, int length); +static void gfar_phy_startup_timer(unsigned long data); extern struct ethtool_ops gfar_ethtool_ops; extern void gfar_gstrings_normon(struct net_device *dev, u32 stringset, @@ -183,7 +174,7 @@ struct ocp_gfar_data *einfo; int idx; int err = 0; - struct ethtool_ops *dev_ethtool_ops; + int dev_ethtool_ops = 0; einfo = (struct ocp_gfar_data *) ocpdev->def->additions; @@ -197,7 +188,8 @@ /* get a pointer to the register memory which can * configure the PHYs. If it's different from this set, * get the device which has those regs */ - if ((einfo->phyregidx >= 0) && (einfo->phyregidx != ocpdev->def->index)) { + if ((einfo->phyregidx >= 0) && + (einfo->phyregidx != ocpdev->def->index)) { mdiodev = ocp_find_device(OCP_ANY_ID, OCP_FUNC_GFAR, einfo->phyregidx); @@ -222,7 +214,7 @@ /* get a pointer to the register memory */ priv->regs = (struct gfar *) - ioremap(ocpdev->def->paddr, sizeof (struct gfar)); + ioremap(ocpdev->def->paddr, sizeof (struct gfar)); if (priv->regs == NULL) { err = -ENOMEM; @@ -238,6 +230,8 @@ goto phy_regs_fail; } + spin_lock_init(&priv->lock); + ocp_set_drvdata(ocpdev, dev); /* Stop the DMA engine now, in case it was running before */ @@ -269,15 +263,13 @@ gfar_write(&priv->regs->ecntrl, ECNTRL_INIT_SETTINGS); /* Copy the station address into the dev structure, */ - /* and into the address registers MAC_STNADDR1,2. */ - /* Backwards, because little endian MACs are dumb. */ - /* Don't set the regs if the firmware already did */ memcpy(dev->dev_addr, einfo->mac_addr, MAC_ADDR_LEN); /* Set the dev->base_addr to the gfar reg region */ dev->base_addr = (unsigned long) (priv->regs); SET_MODULE_OWNER(dev); + SET_NETDEV_DEV(dev, &ocpdev->dev); /* Fill in the dev structure */ dev->open = gfar_enet_open; @@ -293,33 +285,16 @@ dev->change_mtu = gfar_change_mtu; dev->mtu = 1500; dev->set_multicast_list = gfar_set_multi; - dev->flags |= IFF_MULTICAST; - - dev_ethtool_ops = - (struct ethtool_ops *)kmalloc(sizeof(struct ethtool_ops), - GFP_KERNEL); - - if(dev_ethtool_ops == NULL) { - err = -ENOMEM; - goto ethtool_fail; - } - - memcpy(dev_ethtool_ops, &gfar_ethtool_ops, sizeof(gfar_ethtool_ops)); - /* If there is no RMON support in this device, we don't - * want to expose non-existant statistics */ - if((priv->einfo->flags & GFAR_HAS_RMON) == 0) { - dev_ethtool_ops->get_strings = gfar_gstrings_normon; - dev_ethtool_ops->get_stats_count = gfar_stats_count_normon; - dev_ethtool_ops->get_ethtool_stats = gfar_fill_stats_normon; - } + /* Index into the array of possible ethtool + * ops to catch all 4 possibilities */ + if((priv->einfo->flags & GFAR_HAS_RMON) == 0) + dev_ethtool_ops += 1; - if((priv->einfo->flags & GFAR_HAS_COALESCE) == 0) { - dev_ethtool_ops->set_coalesce = NULL; - dev_ethtool_ops->get_coalesce = NULL; - } + if((priv->einfo->flags & GFAR_HAS_COALESCE) == 0) + dev_ethtool_ops += 2; - dev->ethtool_ops = dev_ethtool_ops; + dev->ethtool_ops = gfar_op_array[dev_ethtool_ops]; #ifdef CONFIG_NET_FASTROUTE dev->accept_fastpath = gfar_accept_fastpath; @@ -332,19 +307,18 @@ priv->tx_ring_size = DEFAULT_TX_RING_SIZE; priv->rx_ring_size = DEFAULT_RX_RING_SIZE; - /* Initially, coalescing is disabled */ - priv->txcoalescing = 0; - priv->txcount = 0; - priv->txtime = 0; - priv->rxcoalescing = 0; - priv->rxcount = 0; - priv->rxtime = 0; + priv->txcoalescing = DEFAULT_TX_COALESCE; + priv->txcount = DEFAULT_TXCOUNT; + priv->txtime = DEFAULT_TXTIME; + priv->rxcoalescing = DEFAULT_RX_COALESCE; + priv->rxcount = DEFAULT_RXCOUNT; + priv->rxtime = DEFAULT_RXTIME; err = register_netdev(dev); if (err) { printk(KERN_ERR "%s: Cannot register net device, aborting.\n", - dev->name); + dev->name); goto register_fail; } @@ -367,10 +341,7 @@ return 0; - register_fail: - kfree(dev_ethtool_ops); -ethtool_fail: iounmap((void *) priv->phyregs); phy_regs_fail: iounmap((void *) priv->regs); @@ -386,7 +357,6 @@ ocp_set_drvdata(ocpdev, NULL); - kfree(dev->ethtool_ops); iounmap((void *) priv->regs); iounmap((void *) priv->phyregs); free_netdev(dev); @@ -399,26 +369,90 @@ { struct gfar_private *priv = netdev_priv(dev); struct phy_info *curphy; + unsigned int timeout = PHY_INIT_TIMEOUT; + struct gfar *phyregs = priv->phyregs; + struct gfar_mii_info *mii_info; + int err; - priv->link = 1; priv->oldlink = 0; priv->oldspeed = 0; - priv->olddplx = -1; + priv->oldduplex = -1; + + mii_info = kmalloc(sizeof(struct gfar_mii_info), + GFP_KERNEL); + + if(NULL == mii_info) { + printk(KERN_ERR "%s: Could not allocate mii_info\n", + dev->name); + return -ENOMEM; + } + + mii_info->speed = SPEED_1000; + mii_info->duplex = DUPLEX_FULL; + mii_info->pause = 0; + mii_info->link = 1; + + mii_info->advertising = (ADVERTISED_10baseT_Half | + ADVERTISED_10baseT_Full | + ADVERTISED_100baseT_Half | + ADVERTISED_100baseT_Full | + ADVERTISED_1000baseT_Full); + mii_info->autoneg = 1; + + mii_info->mii_id = priv->einfo->phyid; + + mii_info->dev = dev; + + mii_info->mdio_read = &read_phy_reg; + mii_info->mdio_write = &write_phy_reg; + + priv->mii_info = mii_info; + + /* Reset the management interface */ + gfar_write(&phyregs->miimcfg, MIIMCFG_RESET); + + /* Setup the MII Mgmt clock speed */ + gfar_write(&phyregs->miimcfg, MIIMCFG_INIT_VALUE); + + /* Wait until the bus is free */ + while ((gfar_read(&phyregs->miimind) & MIIMIND_BUSY) && + timeout--) + cpu_relax(); + + if(timeout <= 0) { + printk(KERN_ERR "%s: The MII Bus is stuck!\n", + dev->name); + err = -1; + goto bus_fail; + } /* get info for this PHY */ - curphy = get_phy_info(dev); + curphy = get_phy_info(priv->mii_info); if (curphy == NULL) { printk(KERN_ERR "%s: No PHY found\n", dev->name); - return -1; + err = -1; + goto no_phy; } - priv->phyinfo = curphy; + mii_info->phyinfo = curphy; - /* Run the commands which configure the PHY */ - phy_run_commands(dev, curphy->config); + /* Run the commands which initialize the PHY */ + if(curphy->init) { + err = curphy->init(priv->mii_info); + + if (err) + goto phy_init_fail; + } return 0; + +phy_init_fail: +no_phy: +bus_fail: + kfree(mii_info); + + return err; } static void init_registers(struct net_device *dev) @@ -483,6 +517,20 @@ gfar_write(&priv->regs->tbipa, TBIPA_VALUE); } +void mii_clear_phy_interrupt(struct gfar_mii_info *mii_info) +{ + if(mii_info->phyinfo->ack_interrupt) + mii_info->phyinfo->ack_interrupt(mii_info); +} + + +void mii_configure_phy_interrupt(struct gfar_mii_info *mii_info, u32 interrupts) +{ + mii_info->interrupts = interrupts; + mii_info->phyinfo->config_intr(mii_info); +} + + void stop_gfar(struct net_device *dev) { struct gfar_private *priv = netdev_priv(dev); @@ -494,7 +542,7 @@ spin_lock_irqsave(&priv->lock, flags); /* Tell the kernel the link is down */ - priv->link = 0; + priv->mii_info->link = 0; adjust_link(dev); /* Mask all interrupts */ @@ -521,7 +569,12 @@ gfar_write(®s->maccfg1, tempval); if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { - phy_run_commands(dev, priv->phyinfo->shutdown); + /* Clear any pending interrupts */ + mii_clear_phy_interrupt(priv->mii_info); + + /* Disable PHY Interrupts */ + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_DISABLED); } spin_unlock_irqrestore(&priv->lock, flags); @@ -543,15 +596,14 @@ free_skb_resources(priv); - dma_unmap_single(NULL, gfar_read(®s->tbase), - sizeof(struct txbd)*priv->tx_ring_size, - DMA_BIDIRECTIONAL); - dma_unmap_single(NULL, gfar_read(®s->rbase), - sizeof(struct rxbd)*priv->rx_ring_size, - DMA_BIDIRECTIONAL); + dma_free_coherent(NULL, + sizeof(struct txbd8)*priv->tx_ring_size + + sizeof(struct rxbd8)*priv->rx_ring_size, + priv->tx_bd_base, + gfar_read(®s->tbase)); /* Free the buffer descriptors */ - kfree(priv->tx_bd_base); + kfree(priv->mii_info); } /* If there are any tx skbs or rx skbs still around, free them. @@ -610,7 +662,8 @@ { struct txbd8 *txbdp; struct rxbd8 *rxbdp; - unsigned long addr; + dma_addr_t addr; + unsigned long vaddr; int i; struct gfar_private *priv = netdev_priv(dev); struct gfar *regs = priv->regs; @@ -620,32 +673,27 @@ gfar_write(®s->imask, IMASK_INIT_CLEAR); /* Allocate memory for the buffer descriptors */ - addr = - (unsigned int) kmalloc(sizeof (struct txbd8) * priv->tx_ring_size + - sizeof (struct rxbd8) * priv->rx_ring_size, - GFP_KERNEL); + vaddr = (unsigned long) dma_alloc_coherent(NULL, + sizeof (struct txbd8) * priv->tx_ring_size + + sizeof (struct rxbd8) * priv->rx_ring_size, + &addr, GFP_KERNEL); - if (addr == 0) { + if (vaddr == 0) { printk(KERN_ERR "%s: Could not allocate buffer descriptors!\n", dev->name); return -ENOMEM; } - priv->tx_bd_base = (struct txbd8 *) addr; + priv->tx_bd_base = (struct txbd8 *) vaddr; /* enet DMA only understands physical addresses */ - gfar_write(®s->tbase, - dma_map_single(NULL, (void *)addr, - sizeof(struct txbd8) * priv->tx_ring_size, - DMA_BIDIRECTIONAL)); + gfar_write(®s->tbase, addr); /* Start the rx descriptor ring where the tx ring leaves off */ addr = addr + sizeof (struct txbd8) * priv->tx_ring_size; - priv->rx_bd_base = (struct rxbd8 *) addr; - gfar_write(®s->rbase, - dma_map_single(NULL, (void *)addr, - sizeof(struct rxbd8) * priv->rx_ring_size, - DMA_BIDIRECTIONAL)); + vaddr = vaddr + sizeof (struct txbd8) * priv->tx_ring_size; + priv->rx_bd_base = (struct rxbd8 *) vaddr; + gfar_write(®s->rbase, addr); /* Setup the skbuff rings */ priv->tx_skbuff = @@ -755,39 +803,13 @@ } } - /* Grab the PHY interrupt */ - if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { - if (request_irq(priv->einfo->interruptPHY, phy_interrupt, - SA_SHIRQ, "phy_interrupt", dev) < 0) { - printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", - dev->name, priv->einfo->interruptPHY); - - err = -1; - - if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) - goto phy_irq_fail; - else - goto tx_irq_fail; - } - } else { - init_timer(&priv->phy_info_timer); - priv->phy_info_timer.function = &gfar_phy_timer; - priv->phy_info_timer.data = (unsigned long) dev; - mod_timer(&priv->phy_info_timer, jiffies + 2 * HZ); - } - - /* Set up the bottom half queue */ - INIT_WORK(&priv->tq, (void (*)(void *))gfar_phy_change, dev); + /* Set up the PHY change work queue */ + INIT_WORK(&priv->tq, gfar_phy_change, dev); - /* Configure the PHY interrupt */ - phy_run_commands(dev, priv->phyinfo->startup); - - /* Tell the kernel the link is up, and determine the - * negotiated features (speed, duplex) */ - adjust_link(dev); - - if (priv->link == 0) - printk(KERN_INFO "%s: No link detected\n", dev->name); + init_timer(&priv->phy_info_timer); + priv->phy_info_timer.function = &gfar_phy_startup_timer; + priv->phy_info_timer.data = (unsigned long) priv->mii_info; + mod_timer(&priv->phy_info_timer, jiffies + HZ); /* Configure the coalescing support */ if (priv->txcoalescing) @@ -827,8 +849,6 @@ return 0; -phy_irq_fail: - free_irq(priv->einfo->interruptReceive, dev); rx_irq_fail: free_irq(priv->einfo->interruptTransmit, dev); tx_irq_fail: @@ -838,6 +858,11 @@ free_skb_resources(priv); tx_skb_fail: kfree(priv->tx_bd_base); + kfree(priv->mii_info); + + if (priv->mii_info->phyinfo->close) + priv->mii_info->phyinfo->close(priv->mii_info); + return err; } @@ -854,7 +879,7 @@ err = init_phy(dev); - if (err) + if(err) return err; err = startup_gfar(dev); @@ -1148,8 +1173,7 @@ startup_gfar(dev); } - if (!netif_queue_stopped(dev)) - netif_schedule(dev); + netif_schedule(dev); } /* Interrupt Handler for Transmit complete */ @@ -1315,7 +1339,7 @@ #else spin_lock(&priv->lock); - gfar_clean_rx_ring(dev); + gfar_clean_rx_ring(dev, priv->rx_ring_size); /* If we are coalescing interrupts, update the timer */ /* Otherwise, clear it */ @@ -1368,14 +1392,10 @@ } /* gfar_clean_rx_ring() -- Processes each frame in the rx ring - * until all are gone (or, in the case of NAPI, the budget/quota - * has been reached). Returns the number of frames handled + * until the budget/quota has been reached. Returns the number + * of frames handled */ -#ifdef CONFIG_GFAR_NAPI static int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit) -#else -static int gfar_clean_rx_ring(struct net_device *dev) -#endif { struct rxbd8 *bdp; struct sk_buff *skb; @@ -1386,12 +1406,7 @@ /* Get the first full descriptor */ bdp = priv->cur_rx; -#ifdef CONFIG_GFAR_NAPI -#define GFAR_RXDONE() ((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0)) -#else -#define GFAR_RXDONE() (bdp->status & RXBD_EMPTY) -#endif - while (!GFAR_RXDONE()) { + while (!((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0))) { skb = priv->rx_skbuff[priv->skb_currx]; if (!(bdp->status & @@ -1462,7 +1477,6 @@ if (rx_work_limit > dev->quota) rx_work_limit = dev->quota; - spin_lock(&priv->lock); howmany = gfar_clean_rx_ring(dev, rx_work_limit); dev->quota -= howmany; @@ -1489,8 +1503,6 @@ priv->rxclean = 1; } - spin_unlock(priv->lock); - return (rx_work_limit < 0) ? 1 : 0; } #endif @@ -1586,10 +1598,14 @@ struct net_device *dev = (struct net_device *) dev_id; struct gfar_private *priv = netdev_priv(dev); - /* Run the commands which acknowledge the interrupt */ - phy_run_commands(dev, priv->phyinfo->ack_int); + /* Clear the interrupt */ + mii_clear_phy_interrupt(priv->mii_info); + + /* Disable PHY interrupts */ + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_DISABLED); - /* Schedule the bottom half */ + /* Schedule the phy change */ schedule_work(&priv->tq); return IRQ_HANDLED; @@ -1600,18 +1616,24 @@ { struct net_device *dev = (struct net_device *) data; struct gfar_private *priv = netdev_priv(dev); - int timeout = HZ / 1000 + 1; + int result = 0; /* Delay to give the PHY a chance to change the * register state */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(timeout); + msleep(1); - /* Run the commands which check the link state */ - phy_run_commands(dev, priv->phyinfo->handle_int); + /* Update the link, speed, duplex */ + result = priv->mii_info->phyinfo->read_status(priv->mii_info); - /* React to the change in state */ - adjust_link(dev); + /* Adjust the known status as long as the link + * isn't still coming up */ + if((0 == result) || (priv->mii_info->link == 0)) + adjust_link(dev); + + /* Reenable interrupts, if needed */ + if (priv->einfo->flags & GFAR_HAS_PHY_INTR) + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_ENABLED); } /* Called every so often on systems that don't interrupt @@ -1623,7 +1645,72 @@ schedule_work(&priv->tq); - mod_timer(&priv->phy_info_timer, jiffies + 2 * HZ); + mod_timer(&priv->phy_info_timer, jiffies + + GFAR_PHY_CHANGE_TIME * HZ); +} + +/* Keep trying aneg for some time + * If, after GFAR_AN_TIMEOUT seconds, it has not + * finished, we switch to forced. + * Either way, once the process has completed, we either + * request the interrupt, or switch the timer over to + * using gfar_phy_timer to check status */ +static void gfar_phy_startup_timer(unsigned long data) +{ + int result; + static int secondary = GFAR_AN_TIMEOUT; + struct gfar_mii_info *mii_info = (struct gfar_mii_info *)data; + struct gfar_private *priv = netdev_priv(mii_info->dev); + + /* Configure the Auto-negotiation */ + result = mii_info->phyinfo->config_aneg(mii_info); + + /* If autonegotiation failed to start, and + * we haven't timed out, reset the timer, and return */ + if (result && secondary--) { + mod_timer(&priv->phy_info_timer, jiffies + HZ); + return; + } else if (result) { + /* Couldn't start autonegotiation. + * Try switching to forced */ + mii_info->autoneg = 0; + result = mii_info->phyinfo->config_aneg(mii_info); + + /* Forcing failed! Give up */ + if(result) { + printk(KERN_ERR "%s: Forcing failed!\n", + mii_info->dev->name); + return; + } + } + + /* Kill the timer so it can be restarted */ + del_timer_sync(&priv->phy_info_timer); + + /* Grab the PHY interrupt, if necessary/possible */ + if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { + if (request_irq(priv->einfo->interruptPHY, + phy_interrupt, + SA_SHIRQ, + "phy_interrupt", + mii_info->dev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", + mii_info->dev->name, + priv->einfo->interruptPHY); + } else { + mii_configure_phy_interrupt(priv->mii_info, + MII_INTERRUPT_ENABLED); + return; + } + } + + /* Start the timer again, this time in order to + * handle a change in status */ + init_timer(&priv->phy_info_timer); + priv->phy_info_timer.function = &gfar_phy_timer; + priv->phy_info_timer.data = (unsigned long) mii_info->dev; + mod_timer(&priv->phy_info_timer, jiffies + + GFAR_PHY_CHANGE_TIME * HZ); } /* Called every time the controller might need to be made @@ -1637,12 +1724,13 @@ struct gfar_private *priv = netdev_priv(dev); struct gfar *regs = priv->regs; u32 tempval; + struct gfar_mii_info *mii_info = priv->mii_info; - if (priv->link) { + if (mii_info->link) { /* Now we make sure that we can be in full duplex mode. * If not, we operate in half-duplex mode. */ - if (priv->duplexity != priv->olddplx) { - if (!(priv->duplexity)) { + if (mii_info->duplex != priv->oldduplex) { + if (!(mii_info->duplex)) { tempval = gfar_read(®s->maccfg2); tempval &= ~(MACCFG2_FULL_DUPLEX); gfar_write(®s->maccfg2, tempval); @@ -1658,11 +1746,11 @@ dev->name); } - priv->olddplx = priv->duplexity; + priv->oldduplex = mii_info->duplex; } - if (priv->speed != priv->oldspeed) { - switch (priv->speed) { + if (priv->mii_info->speed != priv->oldspeed) { + switch (priv->mii_info->speed) { case 1000: tempval = gfar_read(®s->maccfg2); tempval = @@ -1679,14 +1767,14 @@ default: printk(KERN_WARNING "%s: Ack! Speed (%d) is not 10/100/1000!\n", - dev->name, priv->speed); + dev->name, priv->mii_info->speed); break; } printk(KERN_INFO "%s: Speed %dBT\n", dev->name, - priv->speed); + priv->mii_info->speed); - priv->oldspeed = priv->speed; + priv->oldspeed = priv->mii_info->speed; } if (!priv->oldlink) { @@ -1700,7 +1788,7 @@ printk(KERN_INFO "%s: Link is down\n", dev->name); priv->oldlink = 0; priv->oldspeed = 0; - priv->olddplx = -1; + priv->oldduplex = -1; netif_carrier_off(dev); } } diff -Nru a/drivers/net/gianfar.h b/drivers/net/gianfar.h --- a/drivers/net/gianfar.h Mon Jul 26 17:01:55 2004 +++ b/drivers/net/gianfar.h Mon Jul 26 17:01:55 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -42,15 +42,7 @@ #include #include #include - -#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,41) #include -#else -#include -#define work_struct tq_struct -#define schedule_work schedule_task -#endif - #include #include #include @@ -70,8 +62,13 @@ #define MAC_ADDR_LEN 6 -extern char gfar_driver_name[]; -extern char gfar_driver_version[]; +#define PHY_INIT_TIMEOUT 100000 +#define GFAR_PHY_CHANGE_TIME 2 + +#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.1, " +#define DRV_NAME "gfar-enet" +extern const char gfar_driver_name[]; +extern const char gfar_driver_version[]; /* These need to be powers of 2 for this driver */ #ifdef CONFIG_GFAR_NAPI @@ -105,11 +102,13 @@ #define GFAR_100_TIME 2560 #define GFAR_10_TIME 25600 +#define DEFAULT_TX_COALESCE 1 #define DEFAULT_TXCOUNT 16 -#define DEFAULT_TXTIME 32768 +#define DEFAULT_TXTIME 400 +#define DEFAULT_RX_COALESCE 1 #define DEFAULT_RXCOUNT 16 -#define DEFAULT_RXTIME 32768 +#define DEFAULT_RXTIME 400 #define TBIPA_VALUE 0x1f #define MIIMCFG_INIT_VALUE 0x00000007 @@ -467,8 +466,7 @@ * empty and completely full conditions. The empty/ready indicator in * the buffer descriptor determines the actual condition. */ -struct gfar_private -{ +struct gfar_private { /* pointers to arrays of skbuffs for tx and rx */ struct sk_buff ** tx_skbuff; struct sk_buff ** rx_skbuff; @@ -496,7 +494,6 @@ struct txbd8 *cur_tx; /* Next free ring entry */ struct txbd8 *dirty_tx; /* The Ring entry to be freed. */ struct gfar *regs; /* Pointer to the GFAR memory mapped Registers */ - struct phy_info *phyinfo; struct gfar *phyregs; struct work_struct tq; struct timer_list phy_info_timer; @@ -509,15 +506,14 @@ unsigned int rx_ring_size; wait_queue_head_t rxcleanupq; unsigned int rxclean; - int link; /* current link state */ - int oldlink; - int duplexity; /* Indicates negotiated duplex state */ - int olddplx; - int speed; /* Indicates negotiated speed */ - int oldspeed; - + /* Info structure initialized by board setup code */ struct ocp_gfar_data *einfo; + + struct gfar_mii_info *mii_info; + int oldspeed; + int oldduplex; + int oldlink; }; extern inline u32 gfar_read(volatile unsigned *addr) @@ -532,6 +528,6 @@ out_be32(addr, val); } - +extern struct ethtool_ops *gfar_op_array[]; #endif /* __GIANFAR_H */ diff -Nru a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c --- a/drivers/net/gianfar_ethtool.c Mon Jul 26 17:01:55 2004 +++ b/drivers/net/gianfar_ethtool.c Mon Jul 26 17:01:55 2004 @@ -1,18 +1,18 @@ /* - * drivers/net/gianfar_ethtool.c + * drivers/net/gianfar_ethtool.c * - * Gianfar Ethernet Driver - * Ethtool support for Gianfar Enet - * Based on e1000 ethtool support + * Gianfar Ethernet Driver + * Ethtool support for Gianfar Enet + * Based on e1000 ethtool support * - * Author: Andy Fleming - * Maintainer: Kumar Gala (kumar.gala@freescale.com) + * Author: Andy Fleming + * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2003,2004 Freescale Semiconductor, Inc. * - * This software may be used and distributed according to - * the terms of the GNU Public License, Version 2, incorporated herein - * by reference. + * This software may be used and distributed according to + * the terms of the GNU Public License, Version 2, incorporated herein + * by reference. */ #include @@ -58,64 +58,64 @@ void gfar_gdrvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo); static char stat_gstrings[][ETH_GSTRING_LEN] = { - "RX Dropped by Kernel", - "RX Large Frame Errors", - "RX Short Frame Errors", - "RX Non-Octet Errors", - "RX CRC Errors", - "RX Overrun Errors", - "RX Busy Errors", - "RX Babbling Errors", - "RX Truncated Frames", - "Ethernet Bus Error", - "TX Babbling Errors", - "TX Underrun Errors", - "RX SKB Missing Errors", - "TX Timeout Errors", - "tx&rx 64B frames", - "tx&rx 65-127B frames", - "tx&rx 128-255B frames", - "tx&rx 256-511B frames", - "tx&rx 512-1023B frames", - "tx&rx 1024-1518B frames", - "tx&rx 1519-1522B Good VLAN", - "RX bytes", - "RX Packets", - "RX FCS Errors", - "Receive Multicast Packet", - "Receive Broadcast Packet", - "RX Control Frame Packets", - "RX Pause Frame Packets", - "RX Unknown OP Code", - "RX Alignment Error", - "RX Frame Length Error", - "RX Code Error", - "RX Carrier Sense Error", - "RX Undersize Packets", - "RX Oversize Packets", - "RX Fragmented Frames", - "RX Jabber Frames", - "RX Dropped Frames", - "TX Byte Counter", - "TX Packets", - "TX Multicast Packets", - "TX Broadcast Packets", - "TX Pause Control Frames", - "TX Deferral Packets", - "TX Excessive Deferral Packets", - "TX Single Collision Packets", - "TX Multiple Collision Packets", - "TX Late Collision Packets", - "TX Excessive Collision Packets", - "TX Total Collision", - "RESERVED", - "TX Dropped Frames", - "TX Jabber Frames", - "TX FCS Errors", - "TX Control Frames", - "TX Oversize Frames", - "TX Undersize Frames", - "TX Fragmented Frames", + "rx-dropped-by-kernel", + "rx-large-frame-errors", + "rx-short-frame-errors", + "rx-non-octet-errors", + "rx-crc-errors", + "rx-overrun-errors", + "rx-busy-errors", + "rx-babbling-errors", + "rx-truncated-frames", + "ethernet-bus-error", + "tx-babbling-errors", + "tx-underrun-errors", + "rx-skb-missing-errors", + "tx-timeout-errors", + "tx-rx-64-frames", + "tx-rx-65-127-frames", + "tx-rx-128-255-frames", + "tx-rx-256-511-frames", + "tx-rx-512-1023-frames", + "tx-rx-1024-1518-frames", + "tx-rx-1519-1522-good-vlan", + "rx-bytes", + "rx-packets", + "rx-fcs-errors", + "receive-multicast-packet", + "receive-broadcast-packet", + "rx-control-frame-packets", + "rx-pause-frame-packets", + "rx-unknown-op-code", + "rx-alignment-error", + "rx-frame-length-error", + "rx-code-error", + "rx-carrier-sense-error", + "rx-undersize-packets", + "rx-oversize-packets", + "rx-fragmented-frames", + "rx-jabber-frames", + "rx-dropped-frames", + "tx-byte-counter", + "tx-packets", + "tx-multicast-packets", + "tx-broadcast-packets", + "tx-pause-control-frames", + "tx-deferral-packets", + "tx-excessive-deferral-packets", + "tx-single-collision-packets", + "tx-multiple-collision-packets", + "tx-late-collision-packets", + "tx-excessive-collision-packets", + "tx-total-collision", + "reserved", + "tx-dropped-frames", + "tx-jabber-frames", + "tx-fcs-errors", + "tx-control-frames", + "tx-oversize-frames", + "tx-undersize-frames", + "tx-fragmented-frames", }; /* Fill in an array of 64-bit statistics from various sources. @@ -125,7 +125,7 @@ void gfar_fill_stats(struct net_device *dev, struct ethtool_stats *dummy, u64 * buf) { int i; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); u32 *rmon = (u32 *) & priv->regs->rmon; u64 *extra = (u64 *) & priv->extra_stats; struct gfar_stats *stats = (struct gfar_stats *) buf; @@ -154,7 +154,7 @@ struct ethtool_stats *dummy, u64 * buf) { int i; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); u64 *extra = (u64 *) & priv->extra_stats; for (i = 0; i < GFAR_EXTRA_STATS_LEN; i++) { @@ -171,7 +171,7 @@ void gfar_gdrvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo) { - strncpy(drvinfo->driver, gfar_driver_name, GFAR_INFOSTR_LEN); + strncpy(drvinfo->driver, DRV_NAME, GFAR_INFOSTR_LEN); strncpy(drvinfo->version, gfar_driver_version, GFAR_INFOSTR_LEN); strncpy(drvinfo->fw_version, "N/A", GFAR_INFOSTR_LEN); strncpy(drvinfo->bus_info, "N/A", GFAR_INFOSTR_LEN); @@ -184,7 +184,7 @@ /* Return the current settings in the ethtool_cmd structure */ int gfar_gsettings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); uint gigabit_support = priv->einfo->flags & GFAR_HAS_GIGABIT ? SUPPORTED_1000baseT_Full : 0; uint gigabit_advert = @@ -201,10 +201,10 @@ | ADVERTISED_100baseT_Full | gigabit_advert | ADVERTISED_Autoneg); - cmd->speed = priv->speed; - cmd->duplex = priv->duplexity; + cmd->speed = priv->mii_info->speed; + cmd->duplex = priv->mii_info->duplex; cmd->port = PORT_MII; - cmd->phy_address = priv->einfo->phyid; + cmd->phy_address = priv->mii_info->mii_id; cmd->transceiver = XCVR_EXTERNAL; cmd->autoneg = AUTONEG_ENABLE; cmd->maxtxpkt = priv->txcount; @@ -223,7 +223,7 @@ void gfar_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *regbuf) { int i; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); u32 *theregs = (u32 *) priv->regs; u32 *buf = (u32 *) regbuf; @@ -231,13 +231,6 @@ buf[i] = theregs[i]; } -/* Return the link state 1 is up, 0 is down */ -u32 gfar_get_link(struct net_device *dev) -{ - struct gfar_private *priv = (struct gfar_private *) dev->priv; - return (u32) priv->link; -} - /* Fill in a buffer with the strings which correspond to the * stats */ void gfar_gstrings(struct net_device *dev, u32 stringset, u8 * buf) @@ -252,7 +245,7 @@ unsigned int count; /* The timer is different, depending on the interface speed */ - switch (priv->speed) { + switch (priv->mii_info->speed) { case 1000: count = GFAR_GBIT_TIME; break; @@ -276,7 +269,7 @@ unsigned int count; /* The timer is different, depending on the interface speed */ - switch (priv->speed) { + switch (priv->mii_info->speed) { case 1000: count = GFAR_GBIT_TIME; break; @@ -298,7 +291,7 @@ * structure. */ int gfar_gcoalesce(struct net_device *dev, struct ethtool_coalesce *cvals) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); cvals->rx_coalesce_usecs = gfar_ticks2usecs(priv, priv->rxtime); cvals->rx_max_coalesced_frames = priv->rxcount; @@ -344,7 +337,7 @@ */ int gfar_scoalesce(struct net_device *dev, struct ethtool_coalesce *cvals) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); /* Set up rx coalescing */ if ((cvals->rx_coalesce_usecs == 0) || @@ -386,7 +379,7 @@ * jumbo are ignored by the driver */ void gfar_gringparam(struct net_device *dev, struct ethtool_ringparam *rvals) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); rvals->rx_max_pending = GFAR_RX_MAX_RING_SIZE; rvals->rx_mini_max_pending = GFAR_RX_MAX_RING_SIZE; @@ -409,7 +402,7 @@ int gfar_sringparam(struct net_device *dev, struct ethtool_ringparam *rvals) { u32 tempval; - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); int err = 0; if (rvals->rx_pending > GFAR_RX_MAX_RING_SIZE) @@ -473,7 +466,7 @@ .get_drvinfo = gfar_gdrvinfo, .get_regs_len = gfar_reglen, .get_regs = gfar_get_regs, - .get_link = gfar_get_link, + .get_link = ethtool_op_get_link, .get_coalesce = gfar_gcoalesce, .set_coalesce = gfar_scoalesce, .get_ringparam = gfar_gringparam, @@ -481,4 +474,52 @@ .get_strings = gfar_gstrings, .get_stats_count = gfar_stats_count, .get_ethtool_stats = gfar_fill_stats, +}; + +struct ethtool_ops gfar_normon_nocoalesce_ethtool_ops = { + .get_settings = gfar_gsettings, + .get_drvinfo = gfar_gdrvinfo, + .get_regs_len = gfar_reglen, + .get_regs = gfar_get_regs, + .get_link = ethtool_op_get_link, + .get_ringparam = gfar_gringparam, + .set_ringparam = gfar_sringparam, + .get_strings = gfar_gstrings_normon, + .get_stats_count = gfar_stats_count_normon, + .get_ethtool_stats = gfar_fill_stats_normon, +}; + +struct ethtool_ops gfar_nocoalesce_ethtool_ops = { + .get_settings = gfar_gsettings, + .get_drvinfo = gfar_gdrvinfo, + .get_regs_len = gfar_reglen, + .get_regs = gfar_get_regs, + .get_link = ethtool_op_get_link, + .get_ringparam = gfar_gringparam, + .set_ringparam = gfar_sringparam, + .get_strings = gfar_gstrings, + .get_stats_count = gfar_stats_count, + .get_ethtool_stats = gfar_fill_stats, +}; + +struct ethtool_ops gfar_normon_ethtool_ops = { + .get_settings = gfar_gsettings, + .get_drvinfo = gfar_gdrvinfo, + .get_regs_len = gfar_reglen, + .get_regs = gfar_get_regs, + .get_link = ethtool_op_get_link, + .get_coalesce = gfar_gcoalesce, + .set_coalesce = gfar_scoalesce, + .get_ringparam = gfar_gringparam, + .set_ringparam = gfar_sringparam, + .get_strings = gfar_gstrings_normon, + .get_stats_count = gfar_stats_count_normon, + .get_ethtool_stats = gfar_fill_stats_normon, +}; + +struct ethtool_ops *gfar_op_array[] = { + &gfar_ethtool_ops, + &gfar_normon_ethtool_ops, + &gfar_nocoalesce_ethtool_ops, + &gfar_normon_nocoalesce_ethtool_ops }; diff -Nru a/drivers/net/gianfar_phy.c b/drivers/net/gianfar_phy.c --- a/drivers/net/gianfar_phy.c Mon Jul 26 17:01:55 2004 +++ b/drivers/net/gianfar_phy.c Mon Jul 26 17:01:55 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -38,21 +38,31 @@ #include #include #include +#include #include "gianfar.h" #include "gianfar_phy.h" +static void config_genmii_advert(struct gfar_mii_info *mii_info); +static void genmii_setup_forced(struct gfar_mii_info *mii_info); +static void genmii_restart_aneg(struct gfar_mii_info *mii_info); +static int gbit_config_aneg(struct gfar_mii_info *mii_info); +static int genmii_config_aneg(struct gfar_mii_info *mii_info); +static int genmii_update_link(struct gfar_mii_info *mii_info); +static int genmii_read_status(struct gfar_mii_info *mii_info); +u16 phy_read(struct gfar_mii_info *mii_info, u16 regnum); +void phy_write(struct gfar_mii_info *mii_info, u16 regnum, u16 val); + /* Write value to the PHY for this device to the register at regnum, */ /* waiting until the write is done before it returns. All PHY */ /* configuration has to be done through the TSEC1 MIIM regs */ -void write_phy_reg(struct net_device *dev, u16 regnum, u16 value) +void write_phy_reg(struct net_device *dev, int mii_id, int regnum, int value) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); struct gfar *regbase = priv->phyregs; - struct ocp_gfar_data *einfo = priv->einfo; /* Set the PHY address and the register address we want to write */ - gfar_write(®base->miimadd, ((einfo->phyid) << 8) | regnum); + gfar_write(®base->miimadd, (mii_id << 8) | regnum); /* Write out the value we want */ gfar_write(®base->miimcon, value); @@ -65,19 +75,18 @@ /* Reads from register regnum in the PHY for device dev, */ /* returning the value. Clears miimcom first. All PHY */ /* configuration has to be done through the TSEC1 MIIM regs */ -u16 read_phy_reg(struct net_device *dev, u16 regnum) +int read_phy_reg(struct net_device *dev, int mii_id, int regnum) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + struct gfar_private *priv = netdev_priv(dev); struct gfar *regbase = priv->phyregs; - struct ocp_gfar_data *einfo = priv->einfo; u16 value; /* Set the PHY address and the register address we want to read */ - gfar_write(®base->miimadd, ((einfo->phyid) << 8) | regnum); + gfar_write(®base->miimadd, (mii_id << 8) | regnum); /* Clear miimcom, and then initiate a read */ gfar_write(®base->miimcom, 0); - gfar_write(®base->miimcom, MIIM_READ_COMMAND); + gfar_write(®base->miimcom, MII_READ_COMMAND); /* Wait for the transaction to finish */ while (gfar_read(®base->miimind) & (MIIMIND_NOTVALID | MIIMIND_BUSY)) @@ -89,362 +98,531 @@ return value; } -/* returns which value to write to the control register. */ -/* For 10/100 the value is slightly different. */ -u16 mii_cr_init(u16 mii_reg, struct net_device * dev) +/* Writes MII_ADVERTISE with the appropriate values, after + * sanitizing advertise to make sure only supported features + * are advertised + */ +static void config_genmii_advert(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; - struct ocp_gfar_data *einfo = priv->einfo; + u32 advertise; + u16 adv; - if (einfo->flags & GFAR_HAS_GIGABIT) - return MIIM_CONTROL_INIT; - else - return MIIM_CR_INIT; + /* Only allow advertising what this PHY supports */ + mii_info->advertising &= mii_info->phyinfo->features; + advertise = mii_info->advertising; + + /* Setup standard advertisement */ + adv = phy_read(mii_info, MII_ADVERTISE); + adv &= ~(ADVERTISE_ALL | ADVERTISE_100BASE4); + if (advertise & ADVERTISED_10baseT_Half) + adv |= ADVERTISE_10HALF; + if (advertise & ADVERTISED_10baseT_Full) + adv |= ADVERTISE_10FULL; + if (advertise & ADVERTISED_100baseT_Half) + adv |= ADVERTISE_100HALF; + if (advertise & ADVERTISED_100baseT_Full) + adv |= ADVERTISE_100FULL; + phy_write(mii_info, MII_ADVERTISE, adv); +} + +static void genmii_setup_forced(struct gfar_mii_info *mii_info) +{ + u16 ctrl; + u32 features = mii_info->phyinfo->features; + + ctrl = phy_read(mii_info, MII_BMCR); + + ctrl &= ~(BMCR_FULLDPLX|BMCR_SPEED100|BMCR_SPEED1000|BMCR_ANENABLE); + ctrl |= BMCR_RESET; + + switch(mii_info->speed) { + case SPEED_1000: + if(features & (SUPPORTED_1000baseT_Half + | SUPPORTED_1000baseT_Full)) { + ctrl |= BMCR_SPEED1000; + break; + } + mii_info->speed = SPEED_100; + case SPEED_100: + if (features & (SUPPORTED_100baseT_Half + | SUPPORTED_100baseT_Full)) { + ctrl |= BMCR_SPEED100; + break; + } + mii_info->speed = SPEED_10; + case SPEED_10: + if (features & (SUPPORTED_10baseT_Half + | SUPPORTED_10baseT_Full)) + break; + default: /* Unsupported speed! */ + printk(KERN_ERR "%s: Bad speed!\n", + mii_info->dev->name); + break; + } + + phy_write(mii_info, MII_BMCR, ctrl); } -#define BRIEF_GFAR_ERRORS -/* Wait for auto-negotiation to complete */ -u16 mii_parse_sr(u16 mii_reg, struct net_device * dev) + +/* Enable and Restart Autonegotiation */ +static void genmii_restart_aneg(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + u16 ctl; + + ctl = phy_read(mii_info, MII_BMCR); + ctl |= (BMCR_ANENABLE | BMCR_ANRESTART); + phy_write(mii_info, MII_BMCR, ctl); +} - unsigned int timeout = GFAR_AN_TIMEOUT; - if (mii_reg & MIIM_STATUS_LINK) - priv->link = 1; +static int gbit_config_aneg(struct gfar_mii_info *mii_info) +{ + u16 adv; + u32 advertise; + + if(mii_info->autoneg) { + /* Configure the ADVERTISE register */ + config_genmii_advert(mii_info); + advertise = mii_info->advertising; + + adv = phy_read(mii_info, MII_1000BASETCONTROL); + adv &= ~(MII_1000BASETCONTROL_FULLDUPLEXCAP | + MII_1000BASETCONTROL_HALFDUPLEXCAP); + if (advertise & SUPPORTED_1000baseT_Half) + adv |= MII_1000BASETCONTROL_HALFDUPLEXCAP; + if (advertise & SUPPORTED_1000baseT_Full) + adv |= MII_1000BASETCONTROL_FULLDUPLEXCAP; + phy_write(mii_info, MII_1000BASETCONTROL, adv); + + /* Start/Restart aneg */ + genmii_restart_aneg(mii_info); + } else + genmii_setup_forced(mii_info); + + return 0; +} + +static int marvell_config_aneg(struct gfar_mii_info *mii_info) +{ + /* The Marvell PHY has an errata which requires + * that certain registers get written in order + * to restart autonegotiation */ + phy_write(mii_info, MII_BMCR, BMCR_RESET); + + phy_write(mii_info, 0x1d, 0x1f); + phy_write(mii_info, 0x1e, 0x200c); + phy_write(mii_info, 0x1d, 0x5); + phy_write(mii_info, 0x1e, 0); + phy_write(mii_info, 0x1e, 0x100); + + gbit_config_aneg(mii_info); + + return 0; +} +static int genmii_config_aneg(struct gfar_mii_info *mii_info) +{ + if (mii_info->autoneg) { + config_genmii_advert(mii_info); + genmii_restart_aneg(mii_info); + } else + genmii_setup_forced(mii_info); + + return 0; +} + + +static int genmii_update_link(struct gfar_mii_info *mii_info) +{ + u16 status; + + /* Do a fake read */ + phy_read(mii_info, MII_BMSR); + + /* Read link and autonegotiation status */ + status = phy_read(mii_info, MII_BMSR); + if ((status & BMSR_LSTATUS) == 0) + mii_info->link = 0; else - priv->link = 0; + mii_info->link = 1; - /* Only auto-negotiate if the link has just gone up */ - if (priv->link && !priv->oldlink) { - while ((!(mii_reg & MIIM_STATUS_AN_DONE)) && timeout--) - mii_reg = read_phy_reg(dev, MIIM_STATUS); - -#if defined(BRIEF_GFAR_ERRORS) - if (mii_reg & MIIM_STATUS_AN_DONE) - printk(KERN_INFO "%s: Auto-negotiation done\n", - dev->name); - else - printk(KERN_INFO "%s: Auto-negotiation timed out\n", - dev->name); -#endif - } + /* If we are autonegotiating, and not done, + * return an error */ + if (mii_info->autoneg && !(status & BMSR_ANEGCOMPLETE)) + return -EAGAIN; return 0; } -/* Determine the speed and duplex which was negotiated */ -u16 mii_parse_88E1011_psr(u16 mii_reg, struct net_device * dev) +static int genmii_read_status(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; - unsigned int speed; + u16 status; + int err; - if (priv->link) { - if (mii_reg & MIIM_88E1011_PHYSTAT_DUPLEX) - priv->duplexity = 1; + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; + + if (mii_info->autoneg) { + status = phy_read(mii_info, MII_LPA); + + if (status & (LPA_10FULL | LPA_100FULL)) + mii_info->duplex = DUPLEX_FULL; + else + mii_info->duplex = DUPLEX_HALF; + if (status & (LPA_100FULL | LPA_100HALF)) + mii_info->speed = SPEED_100; else - priv->duplexity = 0; + mii_info->speed = SPEED_10; + mii_info->pause = 0; + } + /* On non-aneg, we assume what we put in BMCR is the speed, + * though magic-aneg shouldn't prevent this case from occurring + */ - speed = (mii_reg & MIIM_88E1011_PHYSTAT_SPEED); + return 0; +} +static int marvell_read_status(struct gfar_mii_info *mii_info) +{ + u16 status; + int err; - switch (speed) { - case MIIM_88E1011_PHYSTAT_GBIT: - priv->speed = 1000; - break; - case MIIM_88E1011_PHYSTAT_100: - priv->speed = 100; - break; - default: - priv->speed = 10; - break; + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; + + /* If the link is up, read the speed and duplex */ + /* If we aren't autonegotiating, assume speeds + * are as set */ + if (mii_info->autoneg && mii_info->link) { + int speed; + status = phy_read(mii_info, MII_M1011_PHY_SPEC_STATUS); + +#if 0 + /* If speed and duplex aren't resolved, + * return an error. Isn't this handled + * by checking aneg? + */ + if ((status & MII_M1011_PHY_SPEC_STATUS_RESOLVED) == 0) + return -EAGAIN; +#endif + + /* Get the duplexity */ + if (status & MII_M1011_PHY_SPEC_STATUS_FULLDUPLEX) + mii_info->duplex = DUPLEX_FULL; + else + mii_info->duplex = DUPLEX_HALF; + + /* Get the speed */ + speed = status & MII_M1011_PHY_SPEC_STATUS_SPD_MASK; + switch(speed) { + case MII_M1011_PHY_SPEC_STATUS_1000: + mii_info->speed = SPEED_1000; + break; + case MII_M1011_PHY_SPEC_STATUS_100: + mii_info->speed = SPEED_100; + break; + default: + mii_info->speed = SPEED_10; + break; } - } else { - priv->speed = 0; - priv->duplexity = 0; + mii_info->pause = 0; } return 0; } -u16 mii_parse_cis8201(u16 mii_reg, struct net_device * dev) + +static int cis820x_read_status(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; - unsigned int speed; + u16 status; + int err; - if (priv->link) { - if (mii_reg & MIIM_CIS8201_AUXCONSTAT_DUPLEX) - priv->duplexity = 1; + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; + + /* If the link is up, read the speed and duplex */ + /* If we aren't autonegotiating, assume speeds + * are as set */ + if (mii_info->autoneg && mii_info->link) { + int speed; + + status = phy_read(mii_info, MII_CIS8201_AUX_CONSTAT); + if (status & MII_CIS8201_AUXCONSTAT_DUPLEX) + mii_info->duplex = DUPLEX_FULL; else - priv->duplexity = 0; + mii_info->duplex = DUPLEX_HALF; - speed = mii_reg & MIIM_CIS8201_AUXCONSTAT_SPEED; + speed = status & MII_CIS8201_AUXCONSTAT_SPEED; switch (speed) { - case MIIM_CIS8201_AUXCONSTAT_GBIT: - priv->speed = 1000; + case MII_CIS8201_AUXCONSTAT_GBIT: + mii_info->speed = SPEED_1000; break; - case MIIM_CIS8201_AUXCONSTAT_100: - priv->speed = 100; + case MII_CIS8201_AUXCONSTAT_100: + mii_info->speed = SPEED_100; break; default: - priv->speed = 10; + mii_info->speed = SPEED_10; break; } - } else { - priv->speed = 0; - priv->duplexity = 0; } return 0; } -u16 mii_parse_dm9161_scsr(u16 mii_reg, struct net_device * dev) +static int marvell_ack_interrupt(struct gfar_mii_info *mii_info) { - struct gfar_private *priv = (struct gfar_private *) dev->priv; + /* Clear the interrupts by reading the reg */ + phy_read(mii_info, MII_M1011_IEVENT); - if (mii_reg & (MIIM_DM9161_SCSR_100F | MIIM_DM9161_SCSR_100H)) - priv->speed = 100; + return 0; +} + +static int marvell_config_intr(struct gfar_mii_info *mii_info) +{ + if(mii_info->interrupts == MII_INTERRUPT_ENABLED) + phy_write(mii_info, MII_M1011_IMASK, MII_M1011_IMASK_INIT); else - priv->speed = 10; + phy_write(mii_info, MII_M1011_IMASK, MII_M1011_IMASK_CLEAR); + + return 0; +} + +static int cis820x_init(struct gfar_mii_info *mii_info) +{ + phy_write(mii_info, MII_CIS8201_AUX_CONSTAT, + MII_CIS8201_AUXCONSTAT_INIT); + phy_write(mii_info, MII_CIS8201_EXT_CON1, + MII_CIS8201_EXTCON1_INIT); + + return 0; +} + +static int cis820x_ack_interrupt(struct gfar_mii_info *mii_info) +{ + phy_read(mii_info, MII_CIS8201_ISTAT); + + return 0; +} - if (mii_reg & (MIIM_DM9161_SCSR_100F | MIIM_DM9161_SCSR_10F)) - priv->duplexity = 1; +static int cis820x_config_intr(struct gfar_mii_info *mii_info) +{ + if(mii_info->interrupts == MII_INTERRUPT_ENABLED) + phy_write(mii_info, MII_CIS8201_IMASK, MII_CIS8201_IMASK_MASK); else - priv->duplexity = 0; + phy_write(mii_info, MII_CIS8201_IMASK, 0); return 0; } -u16 dm9161_wait(u16 mii_reg, struct net_device *dev) +#define DM9161_DELAY 10 + +static int dm9161_read_status(struct gfar_mii_info *mii_info) { - int timeout = HZ; - int secondary = 10; - u16 temp; - - do { - - /* Davicom takes a bit to come up after a reset, - * so wait here for a bit */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(timeout); - - temp = read_phy_reg(dev, MIIM_STATUS); - - secondary--; - } while ((!(temp & MIIM_STATUS_AN_DONE)) && secondary); - - return 0; -} - -static struct phy_info phy_info_M88E1011S = { - 0x01410c6, - "Marvell 88E1011S", - 4, - (const struct phy_cmd[]) { /* config */ - /* Reset and configure the PHY */ - {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Status is read once to clear old link state */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_88E1011_PHY_STATUS, miim_read, mii_parse_88E1011_psr}, - /* Clear the IEVENT register */ - {MIIM_88E1011_IEVENT, miim_read, NULL}, - /* Set up the mask */ - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_INIT, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - /* Clear the interrupt */ - {MIIM_88E1011_IEVENT, miim_read, NULL}, - /* Disable interrupts */ - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_CLEAR, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Check the status */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - {MIIM_88E1011_PHY_STATUS, miim_read, mii_parse_88E1011_psr}, - /* Enable Interrupts */ - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_INIT, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - {MIIM_88E1011_IEVENT, miim_read, NULL}, - {MIIM_88E1011_IMASK, MIIM_88E1011_IMASK_CLEAR, NULL}, - {miim_end,} - }, -}; + u16 status; + int err; + + /* Update the link, but return if there + * was an error */ + err = genmii_update_link(mii_info); + if (err) + return err; + + /* If the link is up, read the speed and duplex */ + /* If we aren't autonegotiating, assume speeds + * are as set */ + if (mii_info->autoneg && mii_info->link) { + status = phy_read(mii_info, MII_DM9161_SCSR); + if (status & (MII_DM9161_SCSR_100F | MII_DM9161_SCSR_100H)) + mii_info->speed = SPEED_100; + else + mii_info->speed = SPEED_10; + + if (status & (MII_DM9161_SCSR_100F | MII_DM9161_SCSR_10F)) + mii_info->duplex = DUPLEX_FULL; + else + mii_info->duplex = DUPLEX_HALF; + } + + return 0; +} + + +static int dm9161_config_aneg(struct gfar_mii_info *mii_info) +{ + struct dm9161_private *priv = mii_info->priv; + + if(0 == priv->resetdone) + return -EAGAIN; + + return 0; +} + +static void dm9161_timer(unsigned long data) +{ + struct gfar_mii_info *mii_info = (struct gfar_mii_info *)data; + struct dm9161_private *priv = mii_info->priv; + u16 status = phy_read(mii_info, MII_BMSR); + + if (status & BMSR_ANEGCOMPLETE) { + priv->resetdone = 1; + } else + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); +} + +static int dm9161_init(struct gfar_mii_info *mii_info) +{ + struct dm9161_private *priv; + + /* Allocate the private data structure */ + priv = kmalloc(sizeof(struct dm9161_private), GFP_KERNEL); + + if (NULL == priv) + return -ENOMEM; + + mii_info->priv = priv; + + /* Reset is not done yet */ + priv->resetdone = 0; + + /* Isolate the PHY */ + phy_write(mii_info, MII_BMCR, BMCR_ISOLATE); + + /* Do not bypass the scrambler/descrambler */ + phy_write(mii_info, MII_DM9161_SCR, MII_DM9161_SCR_INIT); + + /* Clear 10BTCSR to default */ + phy_write(mii_info, MII_DM9161_10BTCSR, MII_DM9161_10BTCSR_INIT); + + /* Reconnect the PHY, and enable Autonegotiation */ + phy_write(mii_info, MII_BMCR, BMCR_ANENABLE); + + /* Start a timer for DM9161_DELAY seconds to wait + * for the PHY to be ready */ + init_timer(&priv->timer); + priv->timer.function = &dm9161_timer; + priv->timer.data = (unsigned long) mii_info; + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + + return 0; +} + +static void dm9161_close(struct gfar_mii_info *mii_info) +{ + struct dm9161_private *priv = mii_info->priv; + + del_timer_sync(&priv->timer); + kfree(priv); +} + +#if 0 +static int dm9161_ack_interrupt(struct gfar_mii_info *mii_info) +{ + phy_read(mii_info, MII_DM9161_INTR); + + return 0; +} +#endif -/* Cicada 8204 */ -static struct phy_info phy_info_cis8204 = { - 0x3f11, +/* Cicada 820x */ +static struct phy_info phy_info_cis820x = { + 0x000fc440, "Cicada Cis8204", - 6, - (const struct phy_cmd[]) { /* config */ - /* Override PHY config settings */ - {MIIM_CIS8201_AUX_CONSTAT, MIIM_CIS8201_AUXCONSTAT_INIT, NULL}, - /* Set up the interface mode */ - {MIIM_CIS8201_EXT_CON1, MIIM_CIS8201_EXTCON1_INIT, NULL}, - /* Configure some basic stuff */ - {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, - /* Clear the status register */ - {MIIM_CIS8204_ISTAT, miim_read, NULL}, - /* Enable interrupts */ - {MIIM_CIS8204_IMASK, MIIM_CIS8204_IMASK_MASK, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - /* Clear the status register */ - {MIIM_CIS8204_ISTAT, miim_read, NULL}, - /* Disable interrupts */ - {MIIM_CIS8204_IMASK, 0x0, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, - /* Enable interrupts */ - {MIIM_CIS8204_IMASK, MIIM_CIS8204_IMASK_MASK, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - /* Clear the status register */ - {MIIM_CIS8204_ISTAT, miim_read, NULL}, - /* Disable interrupts */ - {MIIM_CIS8204_IMASK, 0x0, NULL}, - {miim_end,} - }, + 0x000fffc0, + .features = MII_GBIT_FEATURES, + .init = &cis820x_init, + .config_aneg = &gbit_config_aneg, + .read_status = &cis820x_read_status, + .ack_interrupt = &cis820x_ack_interrupt, + .config_intr = &cis820x_config_intr, }; -/* Cicada 8201 */ -static struct phy_info phy_info_cis8201 = { - 0xfc41, - "CIS8201", - 4, - (const struct phy_cmd[]) { /* config */ - /* Override PHY config settings */ - {MIIM_CIS8201_AUX_CONSTAT, MIIM_CIS8201_AUXCONSTAT_INIT, NULL}, - /* Set up the interface mode */ - {MIIM_CIS8201_EXT_CON1, MIIM_CIS8201_EXTCON1_INIT, NULL}, - /* Configure some basic stuff */ - {MIIM_CONTROL, MIIM_CONTROL_INIT, mii_cr_init}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Read the Status (2x to make sure link is right) */ - {MIIM_STATUS, miim_read, NULL}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_CIS8201_AUX_CONSTAT, miim_read, mii_parse_cis8201}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - {miim_end,} - }, +static struct phy_info phy_info_dm9161 = { + .phy_id = 0x0181b880, + .name = "Davicom DM9161E", + .phy_id_mask = 0x0ffffff0, + .init = dm9161_init, + .config_aneg = dm9161_config_aneg, + .read_status = dm9161_read_status, + .close = dm9161_close, }; -static struct phy_info phy_info_dm9161 = { - 0x0181b88, - "Davicom DM9161E", - 4, - (const struct phy_cmd[]) { /* config */ - {MIIM_CONTROL, MIIM_DM9161_CR_STOP, NULL}, - /* Do not bypass the scrambler/descrambler */ - {MIIM_DM9161_SCR, MIIM_DM9161_SCR_INIT, NULL}, - /* Clear 10BTCSR to default */ - {MIIM_DM9161_10BTCSR, MIIM_DM9161_10BTCSR_INIT, NULL}, - /* Configure some basic stuff */ - {MIIM_CONTROL, MIIM_CR_INIT, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* startup */ - /* Restart Auto Negotiation */ - {MIIM_CONTROL, MIIM_DM9161_CR_RSTAN, NULL}, - /* Status is read once to clear old link state */ - {MIIM_STATUS, miim_read, dm9161_wait}, - /* Auto-negotiate */ - {MIIM_STATUS, miim_read, mii_parse_sr}, - /* Read the status */ - {MIIM_DM9161_SCSR, miim_read, mii_parse_dm9161_scsr}, - /* Clear any pending interrupts */ - {MIIM_DM9161_INTR, miim_read, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* ack_int */ - {MIIM_DM9161_INTR, miim_read, NULL}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* handle_int */ - {MIIM_STATUS, miim_read, NULL}, - {MIIM_STATUS, miim_read, mii_parse_sr}, - {MIIM_DM9161_SCSR, miim_read, mii_parse_dm9161_scsr}, - {miim_end,} - }, - (const struct phy_cmd[]) { /* shutdown */ - {MIIM_DM9161_INTR, miim_read, NULL}, - {miim_end,} - }, +static struct phy_info phy_info_marvell = { + .phy_id = 0x01410c00, + .phy_id_mask = 0xffffff00, + .name = "Marvell 88E1101", + .features = MII_GBIT_FEATURES, + .config_aneg = &marvell_config_aneg, + .read_status = &marvell_read_status, + .ack_interrupt = &marvell_ack_interrupt, + .config_intr = &marvell_config_intr, +}; + +static struct phy_info phy_info_genmii= { + .phy_id = 0x00000000, + .phy_id_mask = 0x00000000, + .name = "Generic MII", + .features = MII_BASIC_FEATURES, + .config_aneg = genmii_config_aneg, + .read_status = genmii_read_status, }; static struct phy_info *phy_info[] = { - &phy_info_cis8201, - &phy_info_cis8204, - &phy_info_M88E1011S, + &phy_info_cis820x, + &phy_info_marvell, &phy_info_dm9161, + &phy_info_genmii, NULL }; +u16 phy_read(struct gfar_mii_info *mii_info, u16 regnum) +{ + return mii_info->mdio_read(mii_info->dev, mii_info->mii_id, regnum); +} + +void phy_write(struct gfar_mii_info *mii_info, u16 regnum, u16 val) +{ + mii_info->mdio_write(mii_info->dev, + mii_info->mii_id, + regnum, val); +} + /* Use the PHY ID registers to determine what type of PHY is attached * to device dev. return a struct phy_info structure describing that PHY */ -struct phy_info * get_phy_info(struct net_device *dev) +struct phy_info * get_phy_info(struct gfar_mii_info *mii_info) { u16 phy_reg; u32 phy_ID; int i; struct phy_info *theInfo = NULL; + struct net_device *dev = mii_info->dev; /* Grab the bits from PHYIR1, and put them in the upper half */ - phy_reg = read_phy_reg(dev, MIIM_PHYIR1); + phy_reg = phy_read(mii_info, MII_PHYSID1); phy_ID = (phy_reg & 0xffff) << 16; /* Grab the bits from PHYIR2, and put them in the lower half */ - phy_reg = read_phy_reg(dev, MIIM_PHYIR2); + phy_reg = phy_read(mii_info, MII_PHYSID2); phy_ID |= (phy_reg & 0xffff); /* loop through all the known PHY types, and find one that */ /* matches the ID we read from the PHY. */ for (i = 0; phy_info[i]; i++) - if (phy_info[i]->id == (phy_ID >> phy_info[i]->shift)) + if (phy_info[i]->phy_id == + (phy_ID & phy_info[i]->phy_id_mask)) { theInfo = phy_info[i]; + break; + } + /* This shouldn't happen, as we have generic PHY support */ if (theInfo == NULL) { printk("%s: PHY id %x is not supported!\n", dev->name, phy_ID); return NULL; @@ -454,51 +632,4 @@ } return theInfo; -} - -/* Take a list of struct phy_cmd, and, depending on the values, either */ -/* read or write, using a helper function if provided */ -/* It is assumed that all lists of struct phy_cmd will be terminated by */ -/* mii_end. */ -void phy_run_commands(struct net_device *dev, const struct phy_cmd *cmd) -{ - int i; - u16 result; - struct gfar_private *priv = (struct gfar_private *) dev->priv; - struct gfar *phyregs = priv->phyregs; - - /* Reset the management interface */ - gfar_write(&phyregs->miimcfg, MIIMCFG_RESET); - - /* Setup the MII Mgmt clock speed */ - gfar_write(&phyregs->miimcfg, MIIMCFG_INIT_VALUE); - - /* Wait until the bus is free */ - while (gfar_read(&phyregs->miimind) & MIIMIND_BUSY) - cpu_relax(); - - for (i = 0; cmd->mii_reg != miim_end; i++) { - /* The command is a read if mii_data is miim_read */ - if (cmd->mii_data == miim_read) { - /* Read the value of the PHY reg */ - result = read_phy_reg(dev, cmd->mii_reg); - - /* If a function was supplied, we need to let it process */ - /* the result. */ - if (cmd->funct != NULL) - (*(cmd->funct)) (result, dev); - } else { /* Otherwise, it's a write */ - /* If a function was supplied, it will provide - * the value to write */ - /* Otherwise, the value was supplied in cmd->mii_data */ - if (cmd->funct != NULL) - result = (*(cmd->funct)) (0, dev); - else - result = cmd->mii_data; - - /* Write the appropriate value to the PHY reg */ - write_phy_reg(dev, cmd->mii_reg, result); - } - cmd++; - } } diff -Nru a/drivers/net/gianfar_phy.h b/drivers/net/gianfar_phy.h --- a/drivers/net/gianfar_phy.h Mon Jul 26 17:01:55 2004 +++ b/drivers/net/gianfar_phy.h Mon Jul 26 17:01:55 2004 @@ -8,7 +8,7 @@ * Author: Andy Fleming * Maintainer: Kumar Gala (kumar.gala@freescale.com) * - * Copyright 2004 Freescale Semiconductor, Inc + * Copyright (c) 2002-2004 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -19,135 +19,138 @@ #ifndef __GIANFAR_PHY_H #define __GIANFAR_PHY_H -#define miim_end ((u32)-2) -#define miim_read ((u32)-1) +#define MII_end ((u32)-2) +#define MII_read ((u32)-1) #define MIIMIND_BUSY 0x00000001 #define MIIMIND_NOTVALID 0x00000004 -#define MIIM_CONTROL 0x00 -#define MIIM_CONTROL_RESET 0x00008000 -#define MIIM_CONTROL_INIT 0x00001140 -#define MIIM_ANEN 0x00001000 - -#define MIIM_CR 0x00 -#define MIIM_CR_RST 0x00008000 -#define MIIM_CR_INIT 0x00001000 - -#define MIIM_STATUS 0x1 -#define MIIM_STATUS_AN_DONE 0x00000020 -#define MIIM_STATUS_LINK 0x0004 - -#define MIIM_PHYIR1 0x2 -#define MIIM_PHYIR2 0x3 - -#define GFAR_AN_TIMEOUT 0x000fffff - -#define MIIM_ANLPBPA 0x5 -#define MIIM_ANLPBPA_HALF 0x00000040 -#define MIIM_ANLPBPA_FULL 0x00000020 - -#define MIIM_ANEX 0x6 -#define MIIM_ANEX_NP 0x00000004 -#define MIIM_ANEX_PRX 0x00000002 +#define GFAR_AN_TIMEOUT 2000 +/* 1000BT control (Marvell & BCM54xx at least) */ +#define MII_1000BASETCONTROL 0x09 +#define MII_1000BASETCONTROL_FULLDUPLEXCAP 0x0200 +#define MII_1000BASETCONTROL_HALFDUPLEXCAP 0x0100 /* Cicada Extended Control Register 1 */ -#define MIIM_CIS8201_EXT_CON1 0x17 -#define MIIM_CIS8201_EXTCON1_INIT 0x0000 +#define MII_CIS8201_EXT_CON1 0x17 +#define MII_CIS8201_EXTCON1_INIT 0x0000 /* Cicada Interrupt Mask Register */ -#define MIIM_CIS8204_IMASK 0x19 -#define MIIM_CIS8204_IMASK_IEN 0x8000 -#define MIIM_CIS8204_IMASK_SPEED 0x4000 -#define MIIM_CIS8204_IMASK_LINK 0x2000 -#define MIIM_CIS8204_IMASK_DUPLEX 0x1000 -#define MIIM_CIS8204_IMASK_MASK 0xf000 +#define MII_CIS8201_IMASK 0x19 +#define MII_CIS8201_IMASK_IEN 0x8000 +#define MII_CIS8201_IMASK_SPEED 0x4000 +#define MII_CIS8201_IMASK_LINK 0x2000 +#define MII_CIS8201_IMASK_DUPLEX 0x1000 +#define MII_CIS8201_IMASK_MASK 0xf000 /* Cicada Interrupt Status Register */ -#define MIIM_CIS8204_ISTAT 0x1a -#define MIIM_CIS8204_ISTAT_STATUS 0x8000 -#define MIIM_CIS8204_ISTAT_SPEED 0x4000 -#define MIIM_CIS8204_ISTAT_LINK 0x2000 -#define MIIM_CIS8204_ISTAT_DUPLEX 0x1000 +#define MII_CIS8201_ISTAT 0x1a +#define MII_CIS8201_ISTAT_STATUS 0x8000 +#define MII_CIS8201_ISTAT_SPEED 0x4000 +#define MII_CIS8201_ISTAT_LINK 0x2000 +#define MII_CIS8201_ISTAT_DUPLEX 0x1000 /* Cicada Auxiliary Control/Status Register */ -#define MIIM_CIS8201_AUX_CONSTAT 0x1c -#define MIIM_CIS8201_AUXCONSTAT_INIT 0x0004 -#define MIIM_CIS8201_AUXCONSTAT_DUPLEX 0x0020 -#define MIIM_CIS8201_AUXCONSTAT_SPEED 0x0018 -#define MIIM_CIS8201_AUXCONSTAT_GBIT 0x0010 -#define MIIM_CIS8201_AUXCONSTAT_100 0x0008 +#define MII_CIS8201_AUX_CONSTAT 0x1c +#define MII_CIS8201_AUXCONSTAT_INIT 0x0004 +#define MII_CIS8201_AUXCONSTAT_DUPLEX 0x0020 +#define MII_CIS8201_AUXCONSTAT_SPEED 0x0018 +#define MII_CIS8201_AUXCONSTAT_GBIT 0x0010 +#define MII_CIS8201_AUXCONSTAT_100 0x0008 /* 88E1011 PHY Status Register */ -#define MIIM_88E1011_PHY_STATUS 0x11 -#define MIIM_88E1011_PHYSTAT_SPEED 0xc000 -#define MIIM_88E1011_PHYSTAT_GBIT 0x8000 -#define MIIM_88E1011_PHYSTAT_100 0x4000 -#define MIIM_88E1011_PHYSTAT_DUPLEX 0x2000 -#define MIIM_88E1011_PHYSTAT_LINK 0x0400 - -#define MIIM_88E1011_IEVENT 0x13 -#define MIIM_88E1011_IEVENT_CLEAR 0x0000 - -#define MIIM_88E1011_IMASK 0x12 -#define MIIM_88E1011_IMASK_INIT 0x6400 -#define MIIM_88E1011_IMASK_CLEAR 0x0000 - -/* DM9161 Control register values */ -#define MIIM_DM9161_CR_STOP 0x0400 -#define MIIM_DM9161_CR_RSTAN 0x1200 +#define MII_M1011_PHY_SPEC_STATUS 0x11 +#define MII_M1011_PHY_SPEC_STATUS_1000 0x8000 +#define MII_M1011_PHY_SPEC_STATUS_100 0x4000 +#define MII_M1011_PHY_SPEC_STATUS_SPD_MASK 0xc000 +#define MII_M1011_PHY_SPEC_STATUS_FULLDUPLEX 0x2000 +#define MII_M1011_PHY_SPEC_STATUS_RESOLVED 0x0800 +#define MII_M1011_PHY_SPEC_STATUS_LINK 0x0400 + +#define MII_M1011_IEVENT 0x13 +#define MII_M1011_IEVENT_CLEAR 0x0000 + +#define MII_M1011_IMASK 0x12 +#define MII_M1011_IMASK_INIT 0x6400 +#define MII_M1011_IMASK_CLEAR 0x0000 -#define MIIM_DM9161_SCR 0x10 -#define MIIM_DM9161_SCR_INIT 0x0610 +#define MII_DM9161_SCR 0x10 +#define MII_DM9161_SCR_INIT 0x0610 /* DM9161 Specified Configuration and Status Register */ -#define MIIM_DM9161_SCSR 0x11 -#define MIIM_DM9161_SCSR_100F 0x8000 -#define MIIM_DM9161_SCSR_100H 0x4000 -#define MIIM_DM9161_SCSR_10F 0x2000 -#define MIIM_DM9161_SCSR_10H 0x1000 +#define MII_DM9161_SCSR 0x11 +#define MII_DM9161_SCSR_100F 0x8000 +#define MII_DM9161_SCSR_100H 0x4000 +#define MII_DM9161_SCSR_10F 0x2000 +#define MII_DM9161_SCSR_10H 0x1000 /* DM9161 Interrupt Register */ -#define MIIM_DM9161_INTR 0x15 -#define MIIM_DM9161_INTR_PEND 0x8000 -#define MIIM_DM9161_INTR_DPLX_MASK 0x0800 -#define MIIM_DM9161_INTR_SPD_MASK 0x0400 -#define MIIM_DM9161_INTR_LINK_MASK 0x0200 -#define MIIM_DM9161_INTR_MASK 0x0100 -#define MIIM_DM9161_INTR_DPLX_CHANGE 0x0010 -#define MIIM_DM9161_INTR_SPD_CHANGE 0x0008 -#define MIIM_DM9161_INTR_LINK_CHANGE 0x0004 -#define MIIM_DM9161_INTR_INIT 0x0000 -#define MIIM_DM9161_INTR_STOP \ -(MIIM_DM9161_INTR_DPLX_MASK | MIIM_DM9161_INTR_SPD_MASK \ - | MIIM_DM9161_INTR_LINK_MASK | MIIM_DM9161_INTR_MASK) +#define MII_DM9161_INTR 0x15 +#define MII_DM9161_INTR_PEND 0x8000 +#define MII_DM9161_INTR_DPLX_MASK 0x0800 +#define MII_DM9161_INTR_SPD_MASK 0x0400 +#define MII_DM9161_INTR_LINK_MASK 0x0200 +#define MII_DM9161_INTR_MASK 0x0100 +#define MII_DM9161_INTR_DPLX_CHANGE 0x0010 +#define MII_DM9161_INTR_SPD_CHANGE 0x0008 +#define MII_DM9161_INTR_LINK_CHANGE 0x0004 +#define MII_DM9161_INTR_INIT 0x0000 +#define MII_DM9161_INTR_STOP \ +(MII_DM9161_INTR_DPLX_MASK | MII_DM9161_INTR_SPD_MASK \ + | MII_DM9161_INTR_LINK_MASK | MII_DM9161_INTR_MASK) /* DM9161 10BT Configuration/Status */ -#define MIIM_DM9161_10BTCSR 0x12 -#define MIIM_DM9161_10BTCSR_INIT 0x7800 +#define MII_DM9161_10BTCSR 0x12 +#define MII_DM9161_10BTCSR_INIT 0x7800 - -#define MIIM_READ_COMMAND 0x00000001 - -/* - * struct phy_cmd: A command for reading or writing a PHY register - * - * mii_reg: The register to read or write - * - * mii_data: For writes, the value to put in the register. - * A value of -1 indicates this is a read. - * - * funct: A function pointer which is invoked for each command. - * For reads, this function will be passed the value read - * from the PHY, and process it. - * For writes, the result of this function will be written - * to the PHY register - */ -struct phy_cmd { - u32 mii_reg; - u32 mii_data; - u16 (*funct) (u16 mii_reg, struct net_device * dev); +#define MII_BASIC_FEATURES (SUPPORTED_10baseT_Half | \ + SUPPORTED_10baseT_Full | \ + SUPPORTED_100baseT_Half | \ + SUPPORTED_100baseT_Full | \ + SUPPORTED_Autoneg | \ + SUPPORTED_TP | \ + SUPPORTED_MII) + +#define MII_GBIT_FEATURES (MII_BASIC_FEATURES | \ + SUPPORTED_1000baseT_Half | \ + SUPPORTED_1000baseT_Full) + +#define MII_READ_COMMAND 0x00000001 + +#define MII_INTERRUPT_DISABLED 0x0 +#define MII_INTERRUPT_ENABLED 0x1 +/* Taken from mii_if_info and sungem_phy.h */ +struct gfar_mii_info { + /* Information about the PHY type */ + /* And management functions */ + struct phy_info *phyinfo; + + /* forced speed & duplex (no autoneg) + * partner speed & duplex & pause (autoneg) + */ + int speed; + int duplex; + int pause; + + /* The most recently read link state */ + int link; + + /* Enabled Interrupts */ + u32 interrupts; + + u32 advertising; + int autoneg; + int mii_id; + + /* private data pointer */ + /* For use by PHYs to maintain extra state */ + void *priv; + + /* Provided by host chip */ + struct net_device *dev; + int (*mdio_read) (struct net_device *dev, int mii_id, int reg); + void (*mdio_write) (struct net_device *dev, int mii_id, int reg, int val); }; /* struct phy_info: a structure which defines attributes for a PHY @@ -155,38 +158,48 @@ * id will contain a number which represents the PHY. During * startup, the driver will poll the PHY to find out what its * UID--as defined by registers 2 and 3--is. The 32-bit result - * gotten from the PHY will be shifted right by "shift" bits to + * gotten from the PHY will be ANDed with phy_id_mask to * discard any bits which may change based on revision numbers * unimportant to functionality * - * The struct phy_cmd entries represent pointers to an arrays of - * commands which tell the driver what to do to the PHY. + * There are 6 commands which take a gfar_mii_info structure. + * Each PHY must declare config_aneg, and read_status. */ struct phy_info { - u32 id; - char *name; - unsigned int shift; - /* Called to configure the PHY, and modify the controller - * based on the results */ - const struct phy_cmd *config; - - /* Called when starting up the controller. Usually sets - * up the interrupt for state changes */ - const struct phy_cmd *startup; - - /* Called inside the interrupt handler to acknowledge - * the interrupt */ - const struct phy_cmd *ack_int; - - /* Called in the bottom half to handle the interrupt */ - const struct phy_cmd *handle_int; - - /* Called when bringing down the controller. Usually stops - * the interrupts from being generated */ - const struct phy_cmd *shutdown; + u32 phy_id; + char *name; + unsigned int phy_id_mask; + u32 features; + + /* Called to initialize the PHY */ + int (*init)(struct gfar_mii_info *mii_info); + + /* Called to suspend the PHY for power */ + int (*suspend)(struct gfar_mii_info *mii_info); + + /* Reconfigures autonegotiation (or disables it) */ + int (*config_aneg)(struct gfar_mii_info *mii_info); + + /* Determines the negotiated speed and duplex */ + int (*read_status)(struct gfar_mii_info *mii_info); + + /* Clears any pending interrupts */ + int (*ack_interrupt)(struct gfar_mii_info *mii_info); + + /* Enables or disables interrupts */ + int (*config_intr)(struct gfar_mii_info *mii_info); + + /* Clears up any memory if needed */ + void (*close)(struct gfar_mii_info *mii_info); }; -struct phy_info *get_phy_info(struct net_device *dev); -void phy_run_commands(struct net_device *dev, const struct phy_cmd *cmd); +struct phy_info *get_phy_info(struct gfar_mii_info *mii_info); +int read_phy_reg(struct net_device *dev, int mii_id, int regnum); +void write_phy_reg(struct net_device *dev, int mii_id, int regnum, int value); + +struct dm9161_private { + struct timer_list timer; + int resetdone; +}; #endif /* GIANFAR_PHY_H */ diff -Nru a/include/linux/mii.h b/include/linux/mii.h --- a/include/linux/mii.h Mon Jul 26 17:01:54 2004 +++ b/include/linux/mii.h Mon Jul 26 17:01:54 2004 @@ -33,7 +33,8 @@ #define MII_NCONFIG 0x1c /* Network interface config */ /* Basic mode control register. */ -#define BMCR_RESV 0x007f /* Unused... */ +#define BMCR_RESV 0x003f /* Unused... */ +#define BMCR_SPEED1000 0x0040 /* MSB of Speed (1000) */ #define BMCR_CTST 0x0080 /* Collision test */ #define BMCR_FULLDPLX 0x0100 /* Full duplex */ #define BMCR_ANRESTART 0x0200 /* Auto negotiation restart */ --Apple-Mail-1-903248500-- From jgarzik@pobox.com Mon Jul 26 15:10:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 15:10:36 -0700 (PDT) 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 i6QMAT2m022275 for ; Mon, 26 Jul 2004 15:10:30 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpDfq-0006sD-Vm; Mon, 26 Jul 2004 23:10:23 +0100 Message-ID: <41058139.5040400@pobox.com> Date: Mon, 26 Jul 2004 18:10:01 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: Andy Fleming , netdev@oss.sgi.com, Kumar Gala , hadi@cyberus.ca, dwmw2@infradead.org Subject: Re: [RFR] gianfar ethernet driver References: <89563A5C-CFAE-11D8-BA44-000393C30512@freescale.com> <40EB89CC.2040100@pobox.com> <10E7AA25-DF50-11D8-90B5-000393C30512@freescale.com> In-Reply-To: <10E7AA25-DF50-11D8-90B5-000393C30512@freescale.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 462 Lines: 16 Andy Fleming wrote: > Argh. We found a couple bugs in that last patch. This patch fixes > those bugs. However, please note that the patch is done against the > original submission from weeks ago. This patch replaces my most recent > patch. Thanks, I'll look it over. I've been away celebrating (or mourning) my 30th birthday, and have several patches to run through. I'll add it to the pile, though it may be a few days before I get to it. Jeff From Robert.Olsson@data.slu.se Mon Jul 26 15:38:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 15:38:38 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QMcV5U023042 for ; Mon, 26 Jul 2004 15:38:32 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6QMcCIR028083; Tue, 27 Jul 2004 00:38:12 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id D3498EC33E; Tue, 27 Jul 2004 00:38:12 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16645.34772.760879.146784@robur.slu.se> Date: Tue, 27 Jul 2004 00:38:12 +0200 To: Pasi Sjoholm Cc: Robert Olsson , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <16645.13126.52445.630789@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6QMcV5U023042 X-archive-position: 7176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1944 Lines: 64 Pasi Sjoholm writes: > Hur är läget Robert?-) Tack bra! > > In summary: High softirq loads can totally kill userland. The reason is that > > do_softirq() is run from many places hard interrupts, local_bh_enable etc > > and bypasses the ksoftirqd protection. It just been discussed at OLS with > > Andrea and Dipankar and others. Current RCU suffers from this problem as well. > > Ok, this explanation makes sense and my point of view I think this is > quite critical problem if you can "crash" linux kernel just sending enough > packets to network interface for an example. Well the packets also has to create hard softirq loads in practice this means route lookup or something else for normal traffic the RX_SOFIRQ is very well behaved and schedules itself to give other softirq's a chance to run also I'll guess you have softirq's not only from the network. If you decrease your load a bit you come to more nomal operation? > I would be more than glad to help you in testing if you want to publish > some patches. Well maybe we should start to verify that this problem. Alexey did a litte program doing gettimeofday to run to see how long user mode could be starved. Also note we add new source of softirq's. #include #include #include main() { struct timeval tv, prev_tv; __s64 diff; __u32 i; __s32 maxlat = 50; gettimeofday(&prev_tv, NULL); printf("time control loop starting\n"); for (i=0;;i++) { gettimeofday(&tv, NULL); diff = (tv.tv_sec - prev_tv.tv_sec)*1000000 + (tv.tv_usec - prev_tv.tv_usec); if (diff > 1000000) printf("**%lld\n", diff); prev_tv = tv; if (diff > maxlat) { maxlat = diff; printf("new maxlat = %d\n", maxlat); } if(!(i % 1000000)) printf("timestamp diff = %lld, maxlat = %d\n", diff, maxlat); } } Cheers. --ro From shemminger@osdl.org Mon Jul 26 16:22:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 16:22:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QNMfAK027120 for ; Mon, 26 Jul 2004 16:22:42 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6QNMG122688; Mon, 26 Jul 2004 16:22:16 -0700 Date: Mon, 26 Jul 2004 16:22:16 -0700 From: Stephen Hemminger To: Jeff Garzik , Jes Sorensen Cc: netdev@oss.sgi.com Subject: [PATCH] (1/2) module_param for acenic Message-Id: <20040726162216.74a89f81@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1719 Lines: 39 Convert acenic driver to use module_param instead of the older MODULE_PARM macro. Someday, Rusty wants to get rid of MODULE_PARM. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-07-26 16:19:55 -07:00 +++ b/drivers/net/acenic.c 2004-07-26 16:19:55 -07:00 @@ -52,6 +52,7 @@ #include #include +#include #include #include #include @@ -425,13 +426,15 @@ MODULE_AUTHOR("Jes Sorensen "); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("AceNIC/3C985/GA620 Gigabit Ethernet driver"); -MODULE_PARM(link, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(trace, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(tx_coal_tick, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(max_tx_desc, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(rx_coal_tick, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(max_rx_desc, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(tx_ratio, "1-" __MODULE_STRING(8) "i"); + +static int num_params; +module_param_array(link, int, num_params, 0); +module_param_array(trace, int, num_params, 0); +module_param_array(tx_coal_tick, int, num_params, 0); +module_param_array(max_tx_desc, int, num_params, 0); +module_param_array(rx_coal_tick, int, num_params, 0); +module_param_array(max_rx_desc, int, num_params, 0); +module_param_array(tx_ratio, int, num_params, 0); MODULE_PARM_DESC(link, "AceNIC/3C985/NetGear link state"); MODULE_PARM_DESC(trace, "AceNIC/3C985/NetGear firmware trace level"); MODULE_PARM_DESC(tx_coal_tick, "AceNIC/3C985/GA620 max clock ticks to wait from first tx descriptor arrives"); From shemminger@osdl.org Mon Jul 26 16:26:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 16:26:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6QNQf7n027433 for ; Mon, 26 Jul 2004 16:26:42 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6QNQU123153; Mon, 26 Jul 2004 16:26:30 -0700 Date: Mon, 26 Jul 2004 16:26:30 -0700 From: Stephen Hemminger To: Jeff Garzik , Jes Sorensen Cc: netdev@oss.sgi.com Subject: [PATCH] (2/2) acenic - don't print eth%d in messages Message-Id: <20040726162630.4520a785@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 15025 Lines: 546 Get rid of all the places the acenic driver could print "eth%d" because the device hasn't been registered yet. Use the method of having a name pointer in the private device structure that changes from pci_name() to dev->name. There was already a field named 'name[]' in the private data structure, but it was set and never used! Use netdev_priv(dev) rather than dev->priv as well. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-07-26 16:20:07 -07:00 +++ b/drivers/net/acenic.c 2004-07-26 16:20:07 -07:00 @@ -477,6 +477,7 @@ ap = dev->priv; ap->pdev = pdev; + ap->name = pci_name(pdev); dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM; #if ACENIC_DO_VLAN @@ -519,7 +520,7 @@ if (!(ap->pci_command & PCI_COMMAND_MEMORY)) { printk(KERN_INFO "%s: Enabling PCI Memory Mapped " "access - was not enabled by BIOS/Firmware\n", - dev->name); + ap->name); ap->pci_command = ap->pci_command | PCI_COMMAND_MEMORY; pci_write_config_word(ap->pdev, PCI_COMMAND, ap->pci_command); @@ -542,55 +543,40 @@ if (!ap->regs) { printk(KERN_ERR "%s: Unable to map I/O register, " "AceNIC %i will be disabled.\n", - dev->name, boards_found); + ap->name, boards_found); goto fail_free_netdev; } switch(pdev->vendor) { case PCI_VENDOR_ID_ALTEON: if (pdev->device == PCI_DEVICE_ID_FARALLON_PN9100T) { - strncpy(ap->name, "Farallon PN9100-T " - "Gigabit Ethernet", sizeof (ap->name)); printk(KERN_INFO "%s: Farallon PN9100-T ", - dev->name); + ap->name); } else { - strncpy(ap->name, "AceNIC Gigabit Ethernet", - sizeof (ap->name)); printk(KERN_INFO "%s: Alteon AceNIC ", - dev->name); + ap->name); } break; case PCI_VENDOR_ID_3COM: - strncpy(ap->name, "3Com 3C985 Gigabit Ethernet", - sizeof (ap->name)); - printk(KERN_INFO "%s: 3Com 3C985 ", dev->name); + printk(KERN_INFO "%s: 3Com 3C985 ", ap->name); break; case PCI_VENDOR_ID_NETGEAR: - strncpy(ap->name, "NetGear GA620 Gigabit Ethernet", - sizeof (ap->name)); - printk(KERN_INFO "%s: NetGear GA620 ", dev->name); + printk(KERN_INFO "%s: NetGear GA620 ", ap->name); break; case PCI_VENDOR_ID_DEC: if (pdev->device == PCI_DEVICE_ID_FARALLON_PN9000SX) { - strncpy(ap->name, "Farallon PN9000-SX " - "Gigabit Ethernet", sizeof (ap->name)); printk(KERN_INFO "%s: Farallon PN9000-SX ", - dev->name); + ap->name); break; } case PCI_VENDOR_ID_SGI: - strncpy(ap->name, "SGI AceNIC Gigabit Ethernet", - sizeof (ap->name)); - printk(KERN_INFO "%s: SGI AceNIC ", dev->name); + printk(KERN_INFO "%s: SGI AceNIC ", ap->name); break; default: - strncpy(ap->name, "Unknown AceNIC based Gigabit " - "Ethernet", sizeof (ap->name)); - printk(KERN_INFO "%s: Unknown AceNIC ", dev->name); + printk(KERN_INFO "%s: Unknown AceNIC ", ap->name); break; } - ap->name [sizeof (ap->name) - 1] = '\0'; printk("Gigabit Ethernet at 0x%08lx, ", dev->base_addr); #ifdef __sparc__ printk("irq %s\n", __irq_itoa(pdev->irq)); @@ -625,6 +611,7 @@ printk(KERN_ERR "acenic: device registration failed\n"); goto fail_uninit; } + ap->name = dev->name; if (ap->pci_using_dac) dev->features |= NETIF_F_HIGHDMA; @@ -644,7 +631,7 @@ static void __devexit acenic_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; short i; @@ -755,7 +742,7 @@ static void ace_free_descriptors(struct net_device *dev) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); int size; if (ap->rx_std_ring != NULL) { @@ -805,7 +792,7 @@ static int ace_allocate_descriptors(struct net_device *dev) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); int size; size = (sizeof(struct rx_desc) * @@ -876,7 +863,7 @@ { struct ace_private *ap; - ap = dev->priv; + ap = netdev_priv(dev); ace_free_descriptors(dev); @@ -924,7 +911,7 @@ short i; unsigned char cache_size; - ap = dev->priv; + ap = netdev_priv(dev); regs = ap->regs; board_idx = ap->board_idx; @@ -1390,7 +1377,7 @@ if (board_idx == BOARD_IDX_OVERFLOW) { printk(KERN_WARNING "%s: more than %i NICs detected, " "ignoring module parameters!\n", - dev->name, ACE_MAX_MOD_PARMS); + ap->name, ACE_MAX_MOD_PARMS); } else if (board_idx >= 0) { if (tx_coal_tick[board_idx]) writel(tx_coal_tick[board_idx], @@ -1429,7 +1416,7 @@ if (option & 0x01) { printk(KERN_INFO "%s: Setting half duplex link\n", - dev->name); + ap->name); tmp &= ~LNK_FULL_DUPLEX; } if (option & 0x02) @@ -1442,7 +1429,7 @@ tmp |= LNK_1000MB; if ((option & 0x70) == 0) { printk(KERN_WARNING "%s: No media speed specified, " - "forcing auto negotiation\n", dev->name); + "forcing auto negotiation\n", ap->name); tmp |= LNK_NEGOTIATE | LNK_1000MB | LNK_100MB | LNK_10MB; } @@ -1450,12 +1437,12 @@ tmp |= LNK_NEG_FCTL; else printk(KERN_INFO "%s: Disabling flow control " - "negotiation\n", dev->name); + "negotiation\n", ap->name); if (option & 0x200) tmp |= LNK_RX_FLOW_CTL_Y; if ((option & 0x400) && (ap->version >= 2)) { printk(KERN_INFO "%s: Enabling TX flow control\n", - dev->name); + ap->name); tmp |= LNK_TX_FLOW_CTL_Y; } } @@ -1512,7 +1499,7 @@ cpu_relax(); if (!ap->fw_running) { - printk(KERN_ERR "%s: Firmware NOT running!\n", dev->name); + printk(KERN_ERR "%s: Firmware NOT running!\n", ap->name); ace_dump_trace(ap); writel(readl(®s->CpuCtrl) | CPU_HALT, ®s->CpuCtrl); @@ -1545,13 +1532,13 @@ ace_load_std_rx_ring(ap, RX_RING_SIZE); else printk(KERN_ERR "%s: Someone is busy refilling the RX ring\n", - dev->name); + ap->name); if (ap->version >= 2) { if (!test_and_set_bit(0, &ap->mini_refill_busy)) ace_load_mini_rx_ring(ap, RX_MINI_SIZE); else printk(KERN_ERR "%s: Someone is busy refilling " - "the RX mini ring\n", dev->name); + "the RX mini ring\n", ap->name); } return 0; @@ -1567,7 +1554,7 @@ struct ace_regs *regs; int board_idx; - ap = dev->priv; + ap = netdev_priv(dev); regs = ap->regs; board_idx = ap->board_idx; @@ -1607,7 +1594,7 @@ static void ace_watchdog(struct net_device *data) { struct net_device *dev = data; - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; /* @@ -1881,13 +1868,13 @@ { struct ace_private *ap; - ap = dev->priv; + ap = netdev_priv(dev); while (evtcsm != evtprd) { switch (ap->evt_ring[evtcsm].evt) { case E_FW_RUNNING: printk(KERN_INFO "%s: Firmware up and running\n", - dev->name); + ap->name); ap->fw_running = 1; wmb(); break; @@ -1902,7 +1889,7 @@ u32 state = readl(&ap->regs->GigLnkState); printk(KERN_WARNING "%s: Optical link UP " "(%s Duplex, Flow Control: %s%s)\n", - dev->name, + ap->name, state & LNK_FULL_DUPLEX ? "Full":"Half", state & LNK_TX_FLOW_CTL_Y ? "TX " : "", state & LNK_RX_FLOW_CTL_Y ? "RX" : ""); @@ -1910,15 +1897,15 @@ } case E_C_LINK_DOWN: printk(KERN_WARNING "%s: Optical link DOWN\n", - dev->name); + ap->name); break; case E_C_LINK_10_100: printk(KERN_WARNING "%s: 10/100BaseT link " - "UP\n", dev->name); + "UP\n", ap->name); break; default: printk(KERN_ERR "%s: Unknown optical link " - "state %02x\n", dev->name, code); + "state %02x\n", ap->name, code); } break; } @@ -1926,19 +1913,19 @@ switch(ap->evt_ring[evtcsm].code) { case E_C_ERR_INVAL_CMD: printk(KERN_ERR "%s: invalid command error\n", - dev->name); + ap->name); break; case E_C_ERR_UNIMP_CMD: printk(KERN_ERR "%s: unimplemented command " - "error\n", dev->name); + "error\n", ap->name); break; case E_C_ERR_BAD_CFG: printk(KERN_ERR "%s: bad config error\n", - dev->name); + ap->name); break; default: printk(KERN_ERR "%s: unknown error %02x\n", - dev->name, ap->evt_ring[evtcsm].code); + ap->name, ap->evt_ring[evtcsm].code); } break; case E_RESET_JUMBO_RNG: @@ -1967,13 +1954,13 @@ ap->jumbo = 0; ap->rx_jumbo_skbprd = 0; printk(KERN_INFO "%s: Jumbo ring flushed\n", - dev->name); + ap->name); clear_bit(0, &ap->jumbo_refill_busy); break; } default: printk(KERN_ERR "%s: Unhandled event 0x%02x\n", - dev->name, ap->evt_ring[evtcsm].evt); + ap->name, ap->evt_ring[evtcsm].evt); } evtcsm = (evtcsm + 1) % EVT_RING_ENTRIES; } @@ -1984,7 +1971,7 @@ static void ace_rx_int(struct net_device *dev, u32 rxretprd, u32 rxretcsm) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); u32 idx; int mini_count = 0, std_count = 0; @@ -2111,7 +2098,7 @@ static inline void ace_tx_int(struct net_device *dev, u32 txcsm, u32 idx) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); do { struct sk_buff *skb; @@ -2184,7 +2171,7 @@ u32 txcsm, rxretcsm, rxretprd; u32 evtcsm, evtprd; - ap = dev->priv; + ap = netdev_priv(dev); regs = ap->regs; /* @@ -2307,7 +2294,7 @@ #if ACENIC_DO_VLAN static void ace_vlan_rx_register(struct net_device *dev, struct vlan_group *grp) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); unsigned long flags; local_irq_save(flags); @@ -2322,7 +2309,7 @@ static void ace_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); unsigned long flags; local_irq_save(flags); @@ -2343,7 +2330,7 @@ struct ace_regs *regs; struct cmd cmd; - ap = dev->priv; + ap = netdev_priv(dev); regs = ap->regs; if (!(ap->fw_running)) { @@ -2410,7 +2397,7 @@ */ netif_stop_queue(dev); - ap = dev->priv; + ap = netdev_priv(dev); regs = ap->regs; if (ap->promisc) { @@ -2525,7 +2512,7 @@ static int ace_start_xmit(struct sk_buff *skb, struct net_device *dev) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; struct tx_desc *desc; u32 idx, flagsize; @@ -2664,7 +2651,7 @@ static int ace_change_mtu(struct net_device *dev, int new_mtu) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; if (new_mtu > ACE_JUMBO_MTU) @@ -2701,7 +2688,7 @@ static int ace_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; u32 link; @@ -2754,7 +2741,7 @@ static int ace_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; u32 link, speed; @@ -2817,7 +2804,7 @@ static void ace_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); strlcpy(info->driver, "acenic", sizeof(info->driver)); snprintf(info->version, sizeof(info->version), "%i.%i.%i", @@ -2847,7 +2834,7 @@ da = (u8 *)dev->dev_addr; - regs = ((struct ace_private *)dev->priv)->regs; + regs = ((struct ace_private *)netdev_priv(dev))->regs; writel(da[0] << 8 | da[1], ®s->MacAddrHi); writel((da[2] << 24) | (da[3] << 16) | (da[4] << 8) | da[5], ®s->MacAddrLo); @@ -2863,7 +2850,7 @@ static void ace_set_multicast_list(struct net_device *dev) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; struct cmd cmd; @@ -2917,7 +2904,7 @@ static struct net_device_stats *ace_get_stats(struct net_device *dev) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_mac_stats *mac_stats = (struct ace_mac_stats *)ap->regs->Stats; @@ -3000,12 +2987,12 @@ struct ace_private *ap; struct ace_regs *regs; - ap = dev->priv; + ap = netdev_priv(dev); regs = ap->regs; if (!(readl(®s->CpuCtrl) & CPU_HALTED)) { printk(KERN_ERR "%s: trying to download firmware while the " - "CPU is running!\n", dev->name); + "CPU is running!\n", ap->name); return -EFAULT; } @@ -3181,6 +3168,7 @@ static int __init read_eeprom_byte(struct net_device *dev, unsigned long offset) { + struct ace_private *ap; struct ace_regs *regs; unsigned long flags; u32 local; @@ -3190,10 +3178,11 @@ if (!dev) { printk(KERN_ERR "No device!\n"); result = -ENODEV; - goto eeprom_read_error; + goto out; } - regs = ((struct ace_private *)dev->priv)->regs; + ap = netdev_priv(dev); + regs = ap->regs; /* * Don't take interrupts on this CPU will bit banging @@ -3206,7 +3195,7 @@ eeprom_prep(regs, EEPROM_WRITE_SELECT); if (eeprom_check_ack(regs)) { local_irq_restore(flags); - printk(KERN_ERR "%s: Unable to sync eeprom\n", dev->name); + printk(KERN_ERR "%s: Unable to sync eeprom\n", ap->name); result = -EIO; goto eeprom_read_error; } @@ -3215,7 +3204,7 @@ if (eeprom_check_ack(regs)) { local_irq_restore(flags); printk(KERN_ERR "%s: Unable to set address byte 0\n", - dev->name); + ap->name); result = -EIO; goto eeprom_read_error; } @@ -3224,7 +3213,7 @@ if (eeprom_check_ack(regs)) { local_irq_restore(flags); printk(KERN_ERR "%s: Unable to set address byte 1\n", - dev->name); + ap->name); result = -EIO; goto eeprom_read_error; } @@ -3234,7 +3223,7 @@ if (eeprom_check_ack(regs)) { local_irq_restore(flags); printk(KERN_ERR "%s: Unable to set READ_SELECT\n", - dev->name); + ap->name); result = -EIO; goto eeprom_read_error; } @@ -3291,7 +3280,7 @@ eeprom_read_error: printk(KERN_ERR "%s: Unable to read eeprom byte 0x%02lx\n", - dev->name, offset); + ap->name, offset); goto out; } diff -Nru a/drivers/net/acenic.h b/drivers/net/acenic.h --- a/drivers/net/acenic.h 2004-07-26 16:20:07 -07:00 +++ b/drivers/net/acenic.h 2004-07-26 16:20:07 -07:00 @@ -693,7 +693,7 @@ int board_idx; u16 pci_command; u8 pci_latency; - char name[48]; + const char *name; #ifdef INDEX_DEBUG spinlock_t debug_lock __attribute__ ((aligned (SMP_CACHE_BYTES))); From ptsjohol@cc.jyu.fi Mon Jul 26 17:17:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jul 2004 17:17:18 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6R0H9im028755 for ; Mon, 26 Jul 2004 17:17:12 -0700 Received: from silmu.st.jyu.fi (IDENT:Tmbksh7Ns+OYZjlJXL5vQOzOavu8e9vu@silmu.st.jyu.fi [130.234.4.64]) by posti6.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6R0Gqob005839; Tue, 27 Jul 2004 03:16:52 +0300 Date: Tue, 27 Jul 2004 03:16:50 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Robert Olsson cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16645.34772.760879.146784@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti6.jyu.fi; Tue, 27 Jul 2004 03:16:53 +0300 X-archive-position: 7179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev Content-Length: 2902 Lines: 88 On Tue, 27 Jul 2004, Robert Olsson wrote: >>> In summary: High softirq loads can totally kill userland. The reason is that >>> do_softirq() is run from many places hard interrupts, local_bh_enable etc >>> and bypasses the ksoftirqd protection. It just been discussed at OLS with >>> Andrea and Dipankar and others. Current RCU suffers from this problem as well. >> Ok, this explanation makes sense and my point of view I think this is >> quite critical problem if you can "crash" linux kernel just sending enough >> packets to network interface for an example. > > Well the packets also has to create hard softirq loads in practice this means route > lookup or something else for normal traffic the RX_SOFIRQ is very well behaved > and schedules itself to give other softirq's a chance to run also I'll guess you > have softirq's not only from the network. If you decrease your load a bit you come > to more nomal operation? The system will be more responsive but won't ever come back to normal operation and if I use my computer just for some chatting/writing/browsing the ksoftirqd-problem won't ever happen. It is also very hard to reproduce with only high network load. I ran some test with 100Mbps load (RX and TX both) for 24hours without any problems but soon as I started to compile some stuff or doing something cpu-intensive the system would do crash-boom-bang. >> I would be more than glad to help you in testing if you want to publish >> some patches. > Well maybe we should start to verify that this problem. Alexey did a litte program > doing gettimeofday to run to see how long user mode could be starved. Also note we > add new source of softirq's. First run: -- timestamp diff = 1, maxlat = 50963 timestamp diff = 0, maxlat = 50963 timestamp diff = 0, maxlat = 50963 timestamp diff = 1, maxlat = 50963 timestamp diff = 0, maxlat = 50963 timestamp diff = 0, maxlat = 50963 new maxlat = 124428 new maxlat = 511817 timestamp diff = 1, maxlat = 511817 new maxlat = 749913 new maxlat = 775142 **4581159 new maxlat = 4581159 **1704065 **1464153 timestamp diff = 1, maxlat = 4581159 **1448939 **1464013 **1021339 **1568588 **1861657 timestamp diff = 0, maxlat = 4581159 -- Second run: -- timestamp diff = 0, maxlat = 832003 timestamp diff = 1, maxlat = 832003 timestamp diff = 0, maxlat = 832003 timestamp diff = 0, maxlat = 832003 timestamp diff = 0, maxlat = 832003 timestamp diff = 1, maxlat = 832003 **1793951 new maxlat = 1793951 timestamp diff = 0, maxlat = 1793951 **2579893 new maxlat = 2579893 timestamp diff = 0, maxlat = 2579893 timestamp diff = 0, maxlat = 2579893 timestamp diff = 0, maxlat = 2579893 **1004449 **3199625 new maxlat = 3199625 timestamp diff = 0, maxlat = 3199625 timestamp diff = 1, maxlat = 3199625 -- When the system has gone to this state you will have to wait quite a long time to receive a new line. -- Pasi Sjöholm From Robert.Olsson@data.slu.se Tue Jul 27 04:10:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 04:11:12 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RBAto9022571 for ; Tue, 27 Jul 2004 04:10:56 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6RBAbIR013946; Tue, 27 Jul 2004 13:10:37 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id C639FEC33E; Tue, 27 Jul 2004 13:10:37 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16646.14381.740376.204381@robur.slu.se> Date: Tue, 27 Jul 2004 13:10:37 +0200 To: Pasi Sjoholm Cc: Robert Olsson , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <16645.34772.760879.146784@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Pasi Sjoholm writes: > First run: > timestamp diff = 0, maxlat = 4581159 Yes you starved your user apps for ~5 sec. Any idea where your load comes from? Pure NFS network load cannot be hard. Cheers. --ro From okir@suse.de Tue Jul 27 05:43:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 05:43:21 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RCh4uL002414 for ; Tue, 27 Jul 2004 05:43:05 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 6644995C290; Tue, 27 Jul 2004 14:38:43 +0200 (CEST) Date: Tue, 27 Jul 2004 14:38:42 +0200 From: Olaf Kirch To: David Stevens Cc: Andi Kleen , netdev@oss.sgi.com, "Rusty Russell (IBM)" Subject: Re: Fragment ID wrap workaround (read-only, untested). Message-ID: <20040727123842.GF27188@suse.de> References: <20040715092715.GA23131@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-archive-position: 7181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev > you'll reassemble garbage when the IP ID wraps (well before the frag queue > expires). And the checksum will pass anyway on average about 1/64K of the > time. If you send at full rate and drop, say, 100 frags a second, it > doesn't take too long to get a Frankenpacket-- reassembled from parts of > others. :-) In the scenarios we were looking at, packet loss rate was fairly low. What compounded the problem was that the NFS payload wasn't very varied, so the UDP checksum distribution was far from even. When we looked into the problem, we considered implementing a per-route parameter where the admin can set lower reassembly timeouts. I think this is a solution that both addresses the problem, and does not interfere with WAN traffic. The user space tools could even select reasonable defaults based on the hardware type when setting up the device. (We did not implement this because we decided to go for NFS over TCP by default instead). > > In general handling a link where the RTT increases would seem > > tricky with your scheme. Unlike TCP there is no retransmit > > to save the day. > > In the particular case (NFS over UDP), there is both a retransmit (done > by RPC) and significant loss rate to start with. As long as the time-out > is conservative, I don't think this has to affect other cases > significantly. NFS isn't the only application making heavy use of UDP. Video and audio do so too, and these don't have retransmits. Granted, these should choose a paket size that is below the path MTU, but not all applications always do. IMO an estimator such as you describe would need to be very sensitive to jitter in fragment latencies, and it may be fairly hard to find a solution that works from 802.11 up to 10GE. A per-route reassembly timeout is probably a lot less of a headache. Olaf -- Olaf Kirch | The Hardware Gods hate me. okir@suse.de | ---------------+ From ptsjohol@cc.jyu.fi Tue Jul 27 07:21:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 07:21:09 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6REL2Hu006468 for ; Tue, 27 Jul 2004 07:21:03 -0700 Received: from silmu.st.jyu.fi (IDENT:eZwerlNFMF/XkebGKT7zBMdDpxD7wK5F@silmu.st.jyu.fi [130.234.4.64]) by posti6.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6REKLob020574; Tue, 27 Jul 2004 17:20:21 +0300 Date: Tue, 27 Jul 2004 17:20:18 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Robert Olsson cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16646.14381.740376.204381@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti6.jyu.fi; Tue, 27 Jul 2004 17:20:23 +0300 X-archive-position: 7182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev On Tue, 27 Jul 2004, Robert Olsson wrote: > > First run: > > timestamp diff = 0, maxlat = 4581159 > Yes you starved your user apps for ~5 sec. > Any idea where your load comes from? Pure NFS network load cannot be hard. Yeah, when the ksoftirqd is taking all the cpu it will be like that, but when the kernel is behaving normally the starving diff is between 0->1sec. With two samba-server-> workstation -> nfs-server file copys on the diff is normally 0.02secs if I'm not doing anything else but If I will do something cpu-intensive like compiling the kernel with "make -j3", the ksoftirqd will be soon taking all the cpu-time but this requires that I will also have those network file transfers going on. -- Pasi Sjöholm From jgarzik@pobox.com Tue Jul 27 09:26:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 09:26:34 -0700 (PDT) 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 i6RGQSwd013251 for ; Tue, 27 Jul 2004 09:26:29 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpUmX-0007fI-Ey; Tue, 27 Jul 2004 17:26:25 +0100 Message-ID: <41068224.2030902@pobox.com> Date: Tue, 27 Jul 2004 12:26:12 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.8-rc1] prism54 Fix initialization with older firmware References: <200407221027.33023.margitsw@t-online.de> In-Reply-To: <200407221027.33023.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Jul 27 09:26:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 09:26:52 -0700 (PDT) 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 i6RGQiYk013370 for ; Tue, 27 Jul 2004 09:26:45 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpUmn-0007fg-EB; Tue, 27 Jul 2004 17:26:41 +0100 Message-ID: <41068234.6060301@pobox.com> Date: Tue, 27 Jul 2004 12:26:28 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.8-rc1] prism54 Fix reference to uninitialized pointer References: <200407151552.03289.margitsw@t-online.de> In-Reply-To: <200407151552.03289.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Jul 27 09:26:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 09:26:42 -0700 (PDT) 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 i6RGQboN013295 for ; Tue, 27 Jul 2004 09:26:37 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpUmf-0007fO-Mt; Tue, 27 Jul 2004 17:26:33 +0100 Message-ID: <4106822C.70204@pobox.com> Date: Tue, 27 Jul 2004 12:26:20 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.8-rc1] prism54 Refix TRDY/RETRY_TIMEOUT References: <200407210858.00645.margitsw@t-online.de> In-Reply-To: <200407210858.00645.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Jul 27 09:26:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 09:26:34 -0700 (PDT) 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 i6RGQP25013246 for ; Tue, 27 Jul 2004 09:26:26 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpUmT-0007fE-OO; Tue, 27 Jul 2004 17:26:21 +0100 Message-ID: <4106821E.6080401@pobox.com> Date: Tue, 27 Jul 2004 12:26:06 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.8-rc1] prism54 Fix null pointer reference (Bug 100) References: <200407261510.45615.margitsw@t-online.de> In-Reply-To: <200407261510.45615.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From shemminger@osdl.org Tue Jul 27 09:51:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 09:51:18 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RGpDmK015061 for ; Tue, 27 Jul 2004 09:51:13 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6RGov126216; Tue, 27 Jul 2004 09:50:57 -0700 Date: Tue, 27 Jul 2004 09:50:57 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Jamal Hadi Salim Subject: [PATCH] kill rtnl_exlock stubs Message-Id: <20040727095057.78c7419c@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Rtnetlink has some macro's that are relics from earlier locking. They are only used a couple of places so are easy to kill. diff -Nru a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h --- a/include/linux/rtnetlink.h 2004-07-27 09:40:03 -07:00 +++ b/include/linux/rtnetlink.h 2004-07-27 09:40:03 -07:00 @@ -746,10 +746,6 @@ extern struct semaphore rtnl_sem; -#define rtnl_exlock() do { } while(0) -#define rtnl_exunlock() do { } while(0) -#define rtnl_exlock_nowait() (0) - #define rtnl_shlock() down(&rtnl_sem) #define rtnl_shlock_nowait() down_trylock(&rtnl_sem) diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2004-07-27 09:40:03 -07:00 +++ b/net/core/dev.c 2004-07-27 09:40:03 -07:00 @@ -3041,7 +3041,6 @@ while (atomic_read(&dev->refcnt) != 0) { if (time_after(jiffies, rebroadcast_time + 1 * HZ)) { rtnl_shlock(); - rtnl_exlock(); /* Rebroadcast unregister notification */ notifier_call_chain(&netdev_chain, @@ -3058,7 +3057,6 @@ linkwatch_run_queue(); } - rtnl_exunlock(); rtnl_shunlock(); rebroadcast_time = jiffies; diff -Nru a/net/core/link_watch.c b/net/core/link_watch.c --- a/net/core/link_watch.c 2004-07-27 09:40:03 -07:00 +++ b/net/core/link_watch.c 2004-07-27 09:40:03 -07:00 @@ -93,9 +93,7 @@ clear_bit(LW_RUNNING, &linkwatch_flags); rtnl_shlock(); - rtnl_exlock(); linkwatch_run_queue(); - rtnl_exunlock(); rtnl_shunlock(); } diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c --- a/net/core/rtnetlink.c 2004-07-27 09:40:03 -07:00 +++ b/net/core/rtnetlink.c 2004-07-27 09:40:03 -07:00 @@ -56,12 +56,10 @@ void rtnl_lock(void) { rtnl_shlock(); - rtnl_exlock(); } void rtnl_unlock(void) { - rtnl_exunlock(); rtnl_shunlock(); netdev_run_todo(); @@ -404,13 +402,8 @@ return -1; } - if (kind != 2) { - if (rtnl_exlock_nowait()) { - *errp = 0; - return -1; - } + if (kind != 2) exclusive = 1; - } memset(&rta, 0, sizeof(rta)); @@ -439,14 +432,10 @@ goto err_inval; err = link->doit(skb, nlh, (void *)&rta); - if (exclusive) - rtnl_exunlock(); *errp = err; return err; err_inval: - if (exclusive) - rtnl_exunlock(); *errp = -EINVAL; return -1; } From jgarzik@pobox.com Tue Jul 27 09:53:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 09:53:25 -0700 (PDT) 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 i6RGrKPZ015362 for ; Tue, 27 Jul 2004 09:53:21 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpVCX-0008HG-FK; Tue, 27 Jul 2004 17:53:17 +0100 Message-ID: <4106886C.8020704@pobox.com> Date: Tue, 27 Jul 2004 12:53:00 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Gortmaker CC: netdev@oss.sgi.com Subject: Re: [PATCH] Remove obsolete code in 8390 driver References: <410495AC.5040108@yahoo.com> In-Reply-To: <410495AC.5040108@yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Jul 27 10:09:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 10:09:53 -0700 (PDT) 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 i6RH9jqs017087 for ; Tue, 27 Jul 2004 10:09:46 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpVSP-0000NG-Ph; Tue, 27 Jul 2004 18:09:41 +0100 Message-ID: <41068C49.9070406@pobox.com> Date: Tue, 27 Jul 2004 13:09:29 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: Marcelo Tosatti , Netdev , prism54-devel@prism54.org Subject: Re: [PATCH 2.4.26] add prism54 to 2.4 tree References: <20040715005140.GH14482@ruslug.rutgers.edu> <20040720132453.GA2348@dmt.cyclades> <20040721093406.GB9141@ruslug.rutgers.edu> In-Reply-To: <20040721093406.GB9141@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Sure, it is now queued for Marcelo. Note that it won't be sent to him until the current Release Candidate cycle is completed. Jeff From margitsw@t-online.de Tue Jul 27 10:35:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 10:35:31 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RHZQE8017951 for ; Tue, 27 Jul 2004 10:35:27 -0700 Received: from fwd04.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1BpVqn-000456-01; Tue, 27 Jul 2004 19:34:53 +0200 Received: from roglap.local (Givxc8ZEreRxqRUvIyCE3j2x5FL2SBMEnWTs9zP9S-gDCbwI+FyS68@[217.226.119.61]) by fwd04.sul.t-online.com with esmtp id 1BpVqe-20GSHo0; Tue, 27 Jul 2004 19:34:44 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Fix initialization with older firmware Date: Tue, 27 Jul 2004 19:26:44 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_UBpBBZ4K8ECFHYG" Message-Id: <200407271926.45038.margitsw@t-online.de> X-ID: Givxc8ZEreRxqRUvIyCE3j2x5FL2SBMEnWTs9zP9S-gDCbwI+FyS68 X-archive-position: 7190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_UBpBBZ4K8ECFHYG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Regardless of Luis's comments, we should not try to tamper with this. Please apply. Forthcoming fixes may well be able to do better. However, until more information is known, the fix is correct. The version OID will be evaluated in a later fix (for info only). Margit --Boundary-00=_UBpBBZ4K8ECFHYG Content-Type: text/x-diff; charset="us-ascii"; name="outputpow.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="outputpow.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.8-04/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.8-01/drivers/net/wireless/prism54/oid_mgt.c 2004-07-15 17:21:42.000000000 +0200 +++ linux-2.6.8-04/drivers/net/wireless/prism54/oid_mgt.c 2004-07-22 09:50:20.000000000 +0200 @@ -613,7 +613,9 @@ DOT11_OID_DEFKEYID, DOT11_OID_DOT1XENABLE, OID_INL_DOT11D_CONFORMANCE, + /* Do not initialize this - fw < 1.0.4.3 rejects it OID_INL_OUTPUTPOWER, + */ }; /* update the MAC addr. */ --Boundary-00=_UBpBBZ4K8ECFHYG-- From jgarzik@pobox.com Tue Jul 27 10:59:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 10:59:11 -0700 (PDT) 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 i6RHx62s018765 for ; Tue, 27 Jul 2004 10:59:07 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpWEA-0001Ok-HJ; Tue, 27 Jul 2004 18:59:02 +0100 Message-ID: <410697D6.7070305@pobox.com> Date: Tue, 27 Jul 2004 13:58:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jes Sorensen , netdev@oss.sgi.com Subject: Re: [PATCH] (1/2) module_param for acenic References: <20040726162216.74a89f81@dell_ss3.pdx.osdl.net> In-Reply-To: <20040726162216.74a89f81@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied both patches From jgarzik@pobox.com Tue Jul 27 10:59:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 10:59:41 -0700 (PDT) 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 i6RHxajg018838 for ; Tue, 27 Jul 2004 10:59:36 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpWEe-0001PO-6h; Tue, 27 Jul 2004 18:59:32 +0100 Message-ID: <410697F8.2050205@pobox.com> Date: Tue, 27 Jul 2004 13:59:20 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kalev Lember CC: netdev@oss.sgi.com, manfred@colorfullife.com Subject: Re: [PATCH] natsemi netpoll support References: <41052937.5010101@smartlink.ee> In-Reply-To: <41052937.5010101@smartlink.ee> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev please also #ifdef the prototype From jgarzik@pobox.com Tue Jul 27 11:00:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:01:05 -0700 (PDT) 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 i6RI0qLs019315 for ; Tue, 27 Jul 2004 11:00:52 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpWFs-0001R6-TG; Tue, 27 Jul 2004 19:00:49 +0100 Message-ID: <41069845.5040504@pobox.com> Date: Tue, 27 Jul 2004 14:00:37 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maks attems CC: saw@saw.sw.com.sg, netdev@oss.sgi.com Subject: Re: [patch-kj] remove old ifdefs net/eepro100.c References: <20040723154312.GO1795@stro.at> In-Reply-To: <20040723154312.GO1795@stro.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From cus@fazekas.hu Tue Jul 27 11:02:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:02:29 -0700 (PDT) Received: from cinke.fazekas.hu ([195.199.63.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RI2NDL019548 for ; Tue, 27 Jul 2004 11:02:23 -0700 Received: from localhost (localhost [127.0.0.1]) by cinke.fazekas.hu (Postfix) with ESMTP id 8DAEB33CD1; Tue, 27 Jul 2004 20:01:59 +0200 (CEST) Received: from cinke.fazekas.hu ([127.0.0.1]) by localhost (cinke [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26530-06; Tue, 27 Jul 2004 20:01:57 +0200 (CEST) Received: from cinke.fazekas.hu (cinke.fazekas.hu [195.199.63.65]) by cinke.fazekas.hu (Postfix) with ESMTP id 8DE9633CC9; Tue, 27 Jul 2004 20:01:57 +0200 (CEST) Date: Tue, 27 Jul 2004 20:01:57 +0200 (CEST) From: Balint Marton To: "Eble, Dan" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: RE: [PATCH] get_random_bytes returns the same on every boot In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at fazekas.hu X-archive-position: 7194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cus@fazekas.hu Precedence: bulk X-list: netdev Hi, In my previous email, i wrote about a 40 computer test. Today, I repeated my test, and although every computer got the right IP address, there were at least 7 lines of DHCPNAK in the dhcpd logfile. So the system time alone is not as good as it looked like. Cus From vkondra@mail.ru Tue Jul 27 11:03:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:03:32 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RI3Qte019958 for ; Tue, 27 Jul 2004 11:03:27 -0700 Received: from [81.218.247.48] (port=37541 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BpWIM-000ECF-00; Tue, 27 Jul 2004 22:03:22 +0400 From: Vladimir Kondratiev To: Matt Mackall Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 Date: Tue, 27 Jul 2004 21:02:39 +0300 User-Agent: KMail/1.6.82 Cc: Niranjan , netdev@oss.sgi.com References: <20040724223310.68910.qmail@web53004.mail.yahoo.com> <20040726210613.GR5414@waste.org> In-Reply-To: <20040726210613.GR5414@waste.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1671741.xCzNJaUZY8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200407272102.58638.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 7195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev --nextPart1671741.xCzNJaUZY8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline We also saw the same (crypto modules goes to sleep). Due to this, we decided to not use cryptoapi for our wireless driver, but=20 compile the same crypto functions into the driver. I know this is code=20 duplication, but Tx and Rx paths work in BH context (I reschedule it on IRQ= =20 Rx to use cheaper time). Do cryptoapi maintainers aware of this issue? On Tuesday 27 July 2004 00:06, Matt Mackall wrote: > On Sat, Jul 24, 2004 at 03:33:10PM -0700, Niranjan wrote: > > Hi, > > I am working on Linux Kernel 2.4.25. I am trying to > > add cryptoapi (cryptoapi-0.1.0) support to wireless > > lan driver (linux-wlan-ng-0.2.1.pre14) of prism-based > > cards. Cardctl version is 3.1.31. > > When I am using "null" as a encryption cipher to check > > the coding sequence, everything is working fine. But > > when I change it to any other cipher for e.g. > > "blowfish" or "rc5", it is giving kernel panic. I have > > included Ksymoops extract from the kernel Ooops > > reports below. > > Can anyone please help me in what can be possible > > error by looking at the log ? > > I will greatly appreciate any help in this matter. > > The cryptoapi currently decides to sleep at various points internally > when digesting a block which is probably what you're seeing. --nextPart1671741.xCzNJaUZY8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBBpjSqxdj7mhC6o0RApe4AJ9dEp1qL9DY2uXZg9pJ8QTMKnGZ8ACdGODD cp9PU4WVEOoeRImi6j7oWug= =Y/c1 -----END PGP SIGNATURE----- --nextPart1671741.xCzNJaUZY8-- From jgarzik@pobox.com Tue Jul 27 11:15:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:15:17 -0700 (PDT) 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 i6RIFALN020595 for ; Tue, 27 Jul 2004 11:15:10 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpWTi-0001v7-Vq; Tue, 27 Jul 2004 19:15:07 +0100 Message-ID: <41069B9E.8050101@pobox.com> Date: Tue, 27 Jul 2004 14:14:54 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.8-rc1] prism54 Fix initialization with older firmware References: <200407271926.45038.margitsw@t-online.de> In-Reply-To: <200407271926.45038.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev this patch rejected, once the four previous patches had been applied From margitsw@t-online.de Tue Jul 27 11:18:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:18:57 -0700 (PDT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIIm6R020937 for ; Tue, 27 Jul 2004 11:18:48 -0700 Received: from fwd09.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1BpWX9-0001Ac-02; Tue, 27 Jul 2004 20:18:39 +0200 Received: from roglap.local (ZZ75EGZvZeC-HyCgfEqMWE2m3MmYAjk3eUEvyImv0rPmvxpT7haLgC@[217.226.119.61]) by fwd09.sul.t-online.com with esmtp id 1BpWX0-0rZVke0; Tue, 27 Jul 2004 20:18:30 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Clean up dev ids totally Date: Tue, 27 Jul 2004 20:10:25 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_RqpBB9ZxgVIyDE5" Message-Id: <200407272010.25762.margitsw@t-online.de> X-ID: ZZ75EGZvZeC-HyCgfEqMWE2m3MmYAjk3eUEvyImv0rPmvxpT7haLgC X-archive-position: 7197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_RqpBB9ZxgVIyDE5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-27 Margit Schubert-While * As Jeff previously stated, we do not need all this bloat. An updated pci.ids, both kernel and user space, gives us all the required info :-) Just leave the stuff we are interested in. Proposed in prism54 devel with no objections. Margit --Boundary-00=_RqpBB9ZxgVIyDE5 Content-Type: text/x-diff; charset="us-ascii"; name="devidtab.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devidtab.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.8-02/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_dev.c 2004-07-27 19:42:33.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/islpci_dev.c 2004-07-27 19:46:45.000000000 +0200 @@ -39,6 +39,7 @@ #include "oid_mgt.h" #define ISL3877_IMAGE_FILE "isl3877" +#define ISL3886_IMAGE_FILE "isl3886" #define ISL3890_IMAGE_FILE "isl3890" static int prism54_bring_down(islpci_private *); @@ -856,14 +857,14 @@ /* select the firmware file depending on the device id */ switch (pdev->device) { - case PCIDEVICE_ISL3890: - case PCIDEVICE_3COM6001: - strcpy(priv->firmware, ISL3890_IMAGE_FILE); - break; - case PCIDEVICE_ISL3877: + case 0x3877: strcpy(priv->firmware, ISL3877_IMAGE_FILE); break; + case 0x3886: + strcpy(priv->firmware, ISL3886_IMAGE_FILE); + break; + default: strcpy(priv->firmware, ISL3890_IMAGE_FILE); break; diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.6.8-02/drivers/net/wireless/prism54/islpci_hotplug.c --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-27 19:42:33.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-27 19:46:45.000000000 +0200 @@ -44,102 +44,30 @@ * If you have an update for this please contact prism54-devel@prism54.org * The latest list can be found at http://prism54.org/supported_cards.php */ static const struct pci_device_id prism54_id_tbl[] = { - /* 3COM 3CRWE154G72 Wireless LAN adapter */ - { - PCIVENDOR_3COM, PCIDEVICE_3COM6001, - PCIVENDOR_3COM, PCIDEVICE_3COM6001, - 0, 0, 0 - }, - - /* D-Link Air Plus Xtreme G A1 - DWL-g650 A1 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_DLINK, 0x3202UL, - 0, 0, 0 - }, - - /* I-O Data WN-G54/CB - WN-G54/CB */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_IODATA, 0xd019UL, - 0, 0, 0 - }, - - /* Netgear WG511 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_NETGEAR, 0x4800UL, - 0, 0, 0 - }, - - /* Tekram Technology clones, Allnet, Netcomm, Zyxel */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_TTL, 0x1605UL, - 0, 0, 0 - }, - - /* SMC2802W */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0x2802UL, - 0, 0, 0 - }, - - /* SMC2835W */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0x2835UL, - 0, 0, 0 - }, - - /* Corega CG-WLCB54GT */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_ATI, 0xc104UL, - 0, 0, 0 - }, - - /* I4 Z-Com XG-600 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_I4, 0x0014UL, - 0, 0, 0 - }, - - /* I4 Z-Com XG-900 and clones Macer, Ovislink, Planex, Peabird, */ - /* Sitecom, Xterasys */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_I4, 0x0020UL, - 0, 0, 0 - }, - - /* SMC 2802W V2 */ + /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_ACCTON, 0xee03UL, + 0x1260, 0x3890, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, - /* SMC 2835W V2 */ + /* 3COM 3CRWE154G72 Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0xa835UL, + 0x10b7, 0x6001, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, /* Intersil PRISM Indigo Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3877, + 0x1260, 0x3877, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, - /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ - /* Default */ + /* Intersil PRISM Javelin/Xbow Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + 0x1260, 0x3886, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, @@ -166,85 +94,6 @@ /* .enable_wake ; we don't support this yet */ }; -static void -prism54_get_card_model(struct net_device *ndev) -{ - islpci_private *priv; - char *modelp; - int notwork = 0; - - priv = netdev_priv(ndev); - switch (priv->pdev->subsystem_device) { - case PCIDEVICE_ISL3877: - modelp = "PRISM Indigo"; - break; - case PCIDEVICE_ISL3886: - modelp = "PRISM Javelin / Xbow"; - break; - case PCIDEVICE_3COM6001: - modelp = "3COM 3CRWE154G72"; - break; - case 0x3202UL: - modelp = "D-Link DWL-g650 A1"; - break; - case 0xd019UL: - modelp = "WN-G54/CB"; - break; - case 0x4800UL: - modelp = "Netgear WG511"; - break; - case 0x2802UL: - modelp = "SMC2802W"; - break; - case 0xee03UL: - modelp = "SMC2802W V2"; - notwork = 1; - break; - case 0x2835UL: - modelp = "SMC2835W"; - break; - case 0xa835UL: - modelp = "SMC2835W V2"; - notwork = 1; - break; - case 0xc104UL: - modelp = "CG-WLCB54GT"; - break; - case 0x1605UL: - modelp = "Tekram Technology clone"; - break; - /* Let's leave this one out for now since it seems bogus/wrong - * Even if the manufacturer did use 0x0000UL it may not be correct - * by their part, therefore deserving no name ;) */ - /* case 0x0000UL: - * modelp = "SparkLAN WL-850F"; - * break;*/ - - /* We have two reported for the one below :( */ - case 0x0014UL: - modelp = "I4 Z-Com XG-600 and clones"; - break; - case 0x0020UL: - modelp = "I4 Z-Com XG-900 and clones"; - break; -/* Default it */ -/* - case PCIDEVICE_ISL3890: - modelp = "PRISM Duette/GT"; - break; -*/ - default: - modelp = "PRISM Duette/GT"; - } - printk(KERN_DEBUG "%s: %s driver detected card model: %s\n", - ndev->name, DRV_NAME, modelp); - if ( notwork ) { - printk(KERN_DEBUG "%s: %s Warning - This may not work\n", - ndev->name, DRV_NAME); - } - return; -} - /****************************************************************************** Module initialization functions ******************************************************************************/ @@ -354,9 +203,6 @@ /* firmware upload is triggered in islpci_open */ - /* Pretty card model discovery output */ - prism54_get_card_model(ndev); - return 0; do_unregister_netdev: diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_mgt.h linux-2.6.8-02/drivers/net/wireless/prism54/islpci_mgt.h --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_mgt.h 2004-07-27 19:42:33.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/islpci_mgt.h 2004-07-15 08:52:10.000000000 +0200 @@ -38,21 +38,6 @@ /* General driver definitions */ -#define PCIVENDOR_INTERSIL 0x1260UL -#define PCIVENDOR_3COM 0x10b7UL -#define PCIVENDOR_DLINK 0x1186UL -#define PCIVENDOR_I4 0x17cfUL -#define PCIVENDOR_IODATA 0x10fcUL -#define PCIVENDOR_NETGEAR 0x1385UL -#define PCIVENDOR_SMC 0x10b8UL -#define PCIVENDOR_ACCTON 0x1113UL -#define PCIVENDOR_ATI 0x1259UL -#define PCIVENDOR_TTL 0x16a5UL - -#define PCIDEVICE_ISL3877 0x3877UL -#define PCIDEVICE_ISL3886 0x3886UL -#define PCIDEVICE_ISL3890 0x3890UL -#define PCIDEVICE_3COM6001 0x6001UL #define PCIDEVICE_LATENCY_TIMER_MIN 0x40 #define PCIDEVICE_LATENCY_TIMER_VAL 0x50 --Boundary-00=_RqpBB9ZxgVIyDE5-- From shemminger@osdl.org Tue Jul 27 11:19:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:19:48 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIJgBZ021009 for ; Tue, 27 Jul 2004 11:19:42 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6RIJY111804 for ; Tue, 27 Jul 2004 11:19:34 -0700 Date: Tue, 27 Jul 2004 11:19:34 -0700 From: Stephen Hemminger To: netdev@oss.sgi.com Subject: Linux kernel networking summit Message-Id: <20040727111934.25d0e9bb@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev As a pre-cursor to Ottawa Kernel Summit, there was a meeting in Beaverton covering kernel networking topics. I put a web site up with notes and the followup presentation in Ottawa http://developer.osdl.org/shemminger/ns2004 From kalev@smartlink.ee Tue Jul 27 11:23:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:23:16 -0700 (PDT) Received: from kiire.colleduc.ee (myyr.colleduc.ee [193.40.113.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIMxBE021572 for ; Tue, 27 Jul 2004 11:23:00 -0700 Received: from smartlink.ee (mail.smartlink.ee [213.180.16.242]) (authenticated bits=0) by kiire.colleduc.ee (8.12.11/8.12.10) with ESMTP id i6RIMfKe010464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jul 2004 21:22:42 +0300 Message-ID: <41069D70.9030207@smartlink.ee> Date: Tue, 27 Jul 2004 21:22:40 +0300 From: Kalev Lember User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com, manfred@colorfullife.com Subject: Re: [PATCH] natsemi netpoll support References: <41052937.5010101@smartlink.ee> <410697F8.2050205@pobox.com> In-Reply-To: <410697F8.2050205@pobox.com> Content-Type: multipart/mixed; boundary="------------030800070407040709060509" X-Virus-Scanned: clamd / ClamAV version 0.72, clamav-milter version 0.72 on localhost X-Virus-Status: Clean X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.26.0.10; VDF 6.26.0.47 X-archive-position: 7199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kalev@smartlink.ee Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------030800070407040709060509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jeff Garzik wrote: > please also #ifdef the prototype Sorry. Attached updated patch. -- Kalev Lember --------------030800070407040709060509 Content-Type: text/x-patch; name="natsemi_netconsole.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="natsemi_netconsole.diff" --- linux-2.6.8-rc2/drivers/net/natsemi.c.orig 2004-07-25 23:37:05.000000000 +0300 +++ linux-2.6.8-rc2/drivers/net/natsemi.c 2004-07-27 21:18:52.676300394 +0300 @@ -750,6 +750,9 @@ static void netdev_error(struct net_devi static void netdev_rx(struct net_device *dev); static void netdev_tx_done(struct net_device *dev); static int natsemi_change_mtu(struct net_device *dev, int new_mtu); +#ifdef CONFIG_NET_POLL_CONTROLLER +static void natsemi_poll_controller(struct net_device *dev); +#endif static void __set_rx_mode(struct net_device *dev); static void set_rx_mode(struct net_device *dev); static void __get_stats(struct net_device *dev); @@ -920,6 +923,9 @@ static int __devinit natsemi_probe1 (str dev->do_ioctl = &netdev_ioctl; dev->tx_timeout = &tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller = &natsemi_poll_controller; +#endif if (mtu) dev->mtu = mtu; @@ -2364,6 +2370,15 @@ static struct net_device_stats *get_stat return &np->stats; } +#ifdef CONFIG_NET_POLL_CONTROLLER +static void natsemi_poll_controller(struct net_device *dev) +{ + disable_irq(dev->irq); + intr_handler(dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif + #define HASH_TABLE 0x200 static void __set_rx_mode(struct net_device *dev) { --------------030800070407040709060509-- From kaber@trash.net Tue Jul 27 11:37:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:38:07 -0700 (PDT) Received: from gw.localnet (port-195-158-167-243.dynamic.qsc.de [195.158.167.243]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIbuAT022059 for ; Tue, 27 Jul 2004 11:37:57 -0700 Received: from ws.localnet ([192.168.0.23] ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BpWt8-0006E7-00; Tue, 27 Jul 2004 20:41:22 +0200 Message-ID: <4106A132.8040207@trash.net> Date: Tue, 27 Jul 2004 20:38:42 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040722 Debian/1.7.1-3 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Stephen Hemminger , netdev@oss.sgi.com, Jamal Hadi Salim Subject: Re: [PATCH] kill rtnl_exlock stubs References: <20040727095057.78c7419c@dell_ss3.pdx.osdl.net> In-Reply-To: <20040727095057.78c7419c@dell_ss3.pdx.osdl.net> Content-Type: multipart/mixed; boundary="------------050300050105030606070004" X-archive-position: 7200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------050300050105030606070004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Hemminger wrote: > Rtnetlink has some macro's that are relics from earlier locking. > They are only used a couple of places so are easy to kill. The variable "exclusive" in rtnetlink_rcv_msg becomes useless with this patch. This patch (on top of Stephen's patch) removes it. Regards Patrick --------------050300050105030606070004 Content-Type: text/x-patch; name="useless-var.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="useless-var.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/07/27 20:32:23+02:00 kaber@trash.net # [NET]: Remove useless variable in rtnetlink_rcv_msg # # Signed-off-by: Patrick McHardy # # net/core/rtnetlink.c # 2004/07/27 20:32:10+02:00 kaber@trash.net +0 -4 # [NET]: Remove useless variable in rtnetlink_rcv_msg # diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c --- a/net/core/rtnetlink.c 2004-07-27 20:33:47 +02:00 +++ b/net/core/rtnetlink.c 2004-07-27 20:33:47 +02:00 @@ -335,7 +335,6 @@ struct rtnetlink_link *link_tab; struct rtattr *rta[RTATTR_MAX]; - int exclusive = 0; int sz_idx, kind; int min_len; int family; @@ -401,9 +400,6 @@ skb_pull(skb, rlen); return -1; } - - if (kind != 2) - exclusive = 1; memset(&rta, 0, sizeof(rta)); --------------050300050105030606070004-- From jmorris@redhat.com Tue Jul 27 11:39:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:39:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIdUrt022247 for ; Tue, 27 Jul 2004 11:39:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6RIdQe1013771; Tue, 27 Jul 2004 14:39:26 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6RIdQa14138; Tue, 27 Jul 2004 14:39:26 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6RIdPc2017325; Tue, 27 Jul 2004 14:39:26 -0400 Date: Tue, 27 Jul 2004 14:39:25 -0400 (EDT) From: James Morris X-X-Sender: jmorris@dhcp83-76.boston.redhat.com To: Vladimir Kondratiev cc: Matt Mackall , Niranjan , Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 In-Reply-To: <200407272102.58638.vkondra@mail.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Tue, 27 Jul 2004, Vladimir Kondratiev wrote: > We also saw the same (crypto modules goes to sleep). > Due to this, we decided to not use cryptoapi for our wireless driver, but > compile the same crypto functions into the driver. I know this is code > duplication, but Tx and Rx paths work in BH context (I reschedule it on IRQ > Rx to use cheaper time). > > Do cryptoapi maintainers aware of this issue? The crypto functions should be safe to use in softirq context. - James -- James Morris From margitsw@t-online.de Tue Jul 27 11:41:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:41:24 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIfEnv022689 for ; Tue, 27 Jul 2004 11:41:17 -0700 Received: from fwd03.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1BpWsr-0006iW-07; Tue, 27 Jul 2004 20:41:05 +0200 Received: from roglap.local (TWq7byZGYeSHN-70XE1nIAb7UZLOYar4v7y7DTUAgIWEdyr9DOD+UV@[217.226.119.61]) by fwd03.sul.t-online.com with esmtp id 1BpWsi-0b10BE0; Tue, 27 Jul 2004 20:40:56 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc1] prism54 Clarification to Viro's patch Date: Tue, 27 Jul 2004 20:32:56 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Y/pBBYUOevdlgyY" Message-Id: <200407272032.56667.margitsw@t-online.de> X-ID: TWq7byZGYeSHN-70XE1nIAb7UZLOYar4v7y7DTUAgIWEdyr9DOD+UV X-archive-position: 7202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_Y/pBBYUOevdlgyY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-27 Margit Schubert-While * It seems that Viro patched prism54 with the following patch set : http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/ cset-viro@www.linux.org.uk[torvalds]|ChangeSet|20040727040034|54764.txt * I do not see any indication in any mailing list of this. It would be nice if we could be informed of such changes :-) * (Changes committed to our CVS) Margit --Boundary-00=_Y/pBBYUOevdlgyY Content-Type: text/x-diff; charset="us-ascii"; name="devidtab.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devidtab.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.8-02/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_dev.c 2004-07-27 19:42:33.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/islpci_dev.c 2004-07-27 19:46:45.000000000 +0200 @@ -39,6 +39,7 @@ #include "oid_mgt.h" #define ISL3877_IMAGE_FILE "isl3877" +#define ISL3886_IMAGE_FILE "isl3886" #define ISL3890_IMAGE_FILE "isl3890" static int prism54_bring_down(islpci_private *); @@ -856,14 +857,14 @@ /* select the firmware file depending on the device id */ switch (pdev->device) { - case PCIDEVICE_ISL3890: - case PCIDEVICE_3COM6001: - strcpy(priv->firmware, ISL3890_IMAGE_FILE); - break; - case PCIDEVICE_ISL3877: + case 0x3877: strcpy(priv->firmware, ISL3877_IMAGE_FILE); break; + case 0x3886: + strcpy(priv->firmware, ISL3886_IMAGE_FILE); + break; + default: strcpy(priv->firmware, ISL3890_IMAGE_FILE); break; diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.6.8-02/drivers/net/wireless/prism54/islpci_hotplug.c --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-27 19:42:33.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-27 19:46:45.000000000 +0200 @@ -44,102 +44,30 @@ * If you have an update for this please contact prism54-devel@prism54.org * The latest list can be found at http://prism54.org/supported_cards.php */ static const struct pci_device_id prism54_id_tbl[] = { - /* 3COM 3CRWE154G72 Wireless LAN adapter */ - { - PCIVENDOR_3COM, PCIDEVICE_3COM6001, - PCIVENDOR_3COM, PCIDEVICE_3COM6001, - 0, 0, 0 - }, - - /* D-Link Air Plus Xtreme G A1 - DWL-g650 A1 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_DLINK, 0x3202UL, - 0, 0, 0 - }, - - /* I-O Data WN-G54/CB - WN-G54/CB */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_IODATA, 0xd019UL, - 0, 0, 0 - }, - - /* Netgear WG511 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_NETGEAR, 0x4800UL, - 0, 0, 0 - }, - - /* Tekram Technology clones, Allnet, Netcomm, Zyxel */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_TTL, 0x1605UL, - 0, 0, 0 - }, - - /* SMC2802W */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0x2802UL, - 0, 0, 0 - }, - - /* SMC2835W */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0x2835UL, - 0, 0, 0 - }, - - /* Corega CG-WLCB54GT */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_ATI, 0xc104UL, - 0, 0, 0 - }, - - /* I4 Z-Com XG-600 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_I4, 0x0014UL, - 0, 0, 0 - }, - - /* I4 Z-Com XG-900 and clones Macer, Ovislink, Planex, Peabird, */ - /* Sitecom, Xterasys */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_I4, 0x0020UL, - 0, 0, 0 - }, - - /* SMC 2802W V2 */ + /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_ACCTON, 0xee03UL, + 0x1260, 0x3890, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, - /* SMC 2835W V2 */ + /* 3COM 3CRWE154G72 Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0xa835UL, + 0x10b7, 0x6001, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, /* Intersil PRISM Indigo Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3877, + 0x1260, 0x3877, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, - /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ - /* Default */ + /* Intersil PRISM Javelin/Xbow Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + 0x1260, 0x3886, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, @@ -166,85 +94,6 @@ /* .enable_wake ; we don't support this yet */ }; -static void -prism54_get_card_model(struct net_device *ndev) -{ - islpci_private *priv; - char *modelp; - int notwork = 0; - - priv = netdev_priv(ndev); - switch (priv->pdev->subsystem_device) { - case PCIDEVICE_ISL3877: - modelp = "PRISM Indigo"; - break; - case PCIDEVICE_ISL3886: - modelp = "PRISM Javelin / Xbow"; - break; - case PCIDEVICE_3COM6001: - modelp = "3COM 3CRWE154G72"; - break; - case 0x3202UL: - modelp = "D-Link DWL-g650 A1"; - break; - case 0xd019UL: - modelp = "WN-G54/CB"; - break; - case 0x4800UL: - modelp = "Netgear WG511"; - break; - case 0x2802UL: - modelp = "SMC2802W"; - break; - case 0xee03UL: - modelp = "SMC2802W V2"; - notwork = 1; - break; - case 0x2835UL: - modelp = "SMC2835W"; - break; - case 0xa835UL: - modelp = "SMC2835W V2"; - notwork = 1; - break; - case 0xc104UL: - modelp = "CG-WLCB54GT"; - break; - case 0x1605UL: - modelp = "Tekram Technology clone"; - break; - /* Let's leave this one out for now since it seems bogus/wrong - * Even if the manufacturer did use 0x0000UL it may not be correct - * by their part, therefore deserving no name ;) */ - /* case 0x0000UL: - * modelp = "SparkLAN WL-850F"; - * break;*/ - - /* We have two reported for the one below :( */ - case 0x0014UL: - modelp = "I4 Z-Com XG-600 and clones"; - break; - case 0x0020UL: - modelp = "I4 Z-Com XG-900 and clones"; - break; -/* Default it */ -/* - case PCIDEVICE_ISL3890: - modelp = "PRISM Duette/GT"; - break; -*/ - default: - modelp = "PRISM Duette/GT"; - } - printk(KERN_DEBUG "%s: %s driver detected card model: %s\n", - ndev->name, DRV_NAME, modelp); - if ( notwork ) { - printk(KERN_DEBUG "%s: %s Warning - This may not work\n", - ndev->name, DRV_NAME); - } - return; -} - /****************************************************************************** Module initialization functions ******************************************************************************/ @@ -354,9 +203,6 @@ /* firmware upload is triggered in islpci_open */ - /* Pretty card model discovery output */ - prism54_get_card_model(ndev); - return 0; do_unregister_netdev: diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_mgt.h linux-2.6.8-02/drivers/net/wireless/prism54/islpci_mgt.h --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_mgt.h 2004-07-27 19:42:33.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/islpci_mgt.h 2004-07-15 08:52:10.000000000 +0200 @@ -38,21 +38,6 @@ /* General driver definitions */ -#define PCIVENDOR_INTERSIL 0x1260UL -#define PCIVENDOR_3COM 0x10b7UL -#define PCIVENDOR_DLINK 0x1186UL -#define PCIVENDOR_I4 0x17cfUL -#define PCIVENDOR_IODATA 0x10fcUL -#define PCIVENDOR_NETGEAR 0x1385UL -#define PCIVENDOR_SMC 0x10b8UL -#define PCIVENDOR_ACCTON 0x1113UL -#define PCIVENDOR_ATI 0x1259UL -#define PCIVENDOR_TTL 0x16a5UL - -#define PCIDEVICE_ISL3877 0x3877UL -#define PCIDEVICE_ISL3886 0x3886UL -#define PCIDEVICE_ISL3890 0x3890UL -#define PCIDEVICE_3COM6001 0x6001UL #define PCIDEVICE_LATENCY_TIMER_MIN 0x40 #define PCIDEVICE_LATENCY_TIMER_VAL 0x50 --Boundary-00=_Y/pBBYUOevdlgyY-- From vkondra@mail.ru Tue Jul 27 11:51:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:51:20 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIpFWp023058 for ; Tue, 27 Jul 2004 11:51:15 -0700 Received: from [81.218.247.48] (port=50416 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1BpX2c-000NnL-00; Tue, 27 Jul 2004 22:51:11 +0400 From: Vladimir Kondratiev To: James Morris Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 Date: Tue, 27 Jul 2004 21:50:27 +0300 User-Agent: KMail/1.6.82 Cc: Matt Mackall , Niranjan , netdev@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1175970.E4tr3HR44W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200407272150.50664.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 7203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev --nextPart1175970.E4tr3HR44W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 27 July 2004 21:39, James Morris wrote: > On Tue, 27 Jul 2004, Vladimir Kondratiev wrote: > > We also saw the same (crypto modules goes to sleep). > > Due to this, we decided to not use cryptoapi for our wireless driver, but > > compile the same crypto functions into the driver. I know this is code > > duplication, but Tx and Rx paths work in BH context (I reschedule it on > > IRQ Rx to use cheaper time). > > > > Do cryptoapi maintainers aware of this issue? > > The crypto functions should be safe to use in softirq context. It should be, but: struct crypto_tfm *crypto_alloc_tfm(const char *name, u32 flags) { struct crypto_tfm *tfm = NULL; struct crypto_alg *alg; alg = crypto_alg_mod_lookup(name); if (alg == NULL) goto out; tfm = kmalloc(sizeof(*tfm) + alg->cra_ctxsize, GFP_KERNEL); Note kmalloc(GFP_KERNEL) > > > - James --nextPart1175970.E4tr3HR44W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBBqQKqxdj7mhC6o0RAl3yAJwNJTUOsn0X0pyZEXT3sL/pI2qfJQCfZV/k dyuRi6ZO1SvSqalKaA8H+Hk= =PWtG -----END PGP SIGNATURE----- --nextPart1175970.E4tr3HR44W-- From jmorris@redhat.com Tue Jul 27 11:57:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 11:57:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RIv9aO023419 for ; Tue, 27 Jul 2004 11:57:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6RIv5e1018721; Tue, 27 Jul 2004 14:57:05 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6RIv5a24342; Tue, 27 Jul 2004 14:57:05 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6RIv5c2018544; Tue, 27 Jul 2004 14:57:05 -0400 Date: Tue, 27 Jul 2004 14:57:04 -0400 (EDT) From: James Morris X-X-Sender: jmorris@dhcp83-76.boston.redhat.com To: Vladimir Kondratiev cc: Matt Mackall , Niranjan , Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 In-Reply-To: <200407272150.50664.vkondra@mail.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Tue, 27 Jul 2004, Vladimir Kondratiev wrote: > > The crypto functions should be safe to use in softirq context. > It should be, but: > > struct crypto_tfm *crypto_alloc_tfm(const char *name, u32 flags) > { > struct crypto_tfm *tfm = NULL; > struct crypto_alg *alg; > > alg = crypto_alg_mod_lookup(name); > if (alg == NULL) > goto out; > > tfm = kmalloc(sizeof(*tfm) + alg->cra_ctxsize, GFP_KERNEL); > By crypto functions I meant encrypt() decrypt() etc, not the allocation. - James -- James Morris From jgarzik@pobox.com Tue Jul 27 12:05:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 12:05:58 -0700 (PDT) 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 i6RJ5oqi023813 for ; Tue, 27 Jul 2004 12:05:50 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BpXGk-0002SS-Kj; Tue, 27 Jul 2004 20:05:47 +0100 Message-ID: <4106A77D.2070508@pobox.com> Date: Tue, 27 Jul 2004 15:05:33 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , Andrew Morton Subject: netdev-2.6 queue updated Content-Type: multipart/mixed; boundary="------------010506040403050403020809" X-archive-position: 7205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------010506040403050403020809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Those who are mirroring netdev-2.6 repository, please delete and re-clone it. Attached is a summary of the current contents of the netdev-2.6 queue. Several groups of patches are either waiting for the kernel to get out of Release Candidate status, or are "simmering"... waiting around for additional testing and review. netdev-2.6 is only available through BitKeeper, or Andrew Morton's -mm patches. Jeff --------------010506040403050403020809 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" BK users may do a bk pull bk://gkernel.bkbits.net/netdev-2.6 This will update the following files: include/asm-mips/mv64340.h | 1039 ---------- arch/mips/configs/jaguar-atx_defconfig | 8 arch/mips/configs/ocelot_c_defconfig | 2 arch/mips/momentum/jaguar_atx/prom.c | 4 arch/mips/momentum/ocelot_c/prom.c | 6 drivers/net/8139too.c | 4 drivers/net/8390.c | 36 drivers/net/8390.h | 12 drivers/net/Kconfig | 45 drivers/net/Makefile | 3 drivers/net/acenic.c | 156 - drivers/net/acenic.h | 2 drivers/net/e100.c | 29 drivers/net/eepro100.c | 17 drivers/net/epic100.c | 426 ++-- drivers/net/gianfar.c | 1921 ++++++++++++++++++ drivers/net/gianfar.h | 537 +++++ drivers/net/gianfar_ethtool.c | 484 ++++ drivers/net/gianfar_phy.c | 504 ++++ drivers/net/gianfar_phy.h | 192 + drivers/net/gt64240eth.h | 402 +++ drivers/net/gt96100eth.c | 119 - drivers/net/mv643xx_eth.c | 2646 ++++++++++++++++++++++++++ drivers/net/mv643xx_eth.h | 601 +++++ drivers/net/r8169.c | 655 ++++-- drivers/net/sk98lin/h/skdrv2nd.h | 54 drivers/net/sk98lin/skaddr.c | 4 drivers/net/sk98lin/skge.c | 742 +++---- drivers/net/via-rhine.c | 695 +++--- drivers/net/via-velocity.c | 566 ++--- drivers/net/via-velocity.h | 4 drivers/net/wireless/prism54/isl_ioctl.c | 16 drivers/net/wireless/prism54/islpci_hotplug.c | 17 drivers/net/wireless/prism54/islpci_mgt.c | 2 drivers/net/wireless/prism54/oid_mgt.c | 6 include/linux/mv643xx.h | 1039 ++++++++++ include/linux/pci_ids.h | 1 37 files changed, 10215 insertions(+), 2781 deletions(-) through these ChangeSets: Adrian Bunk: o 2.6.8-rc1-mm1: 8139too: uninline rtl8139_start_thread Andrew Morton: o via-velocity warning fixes o fix via-velocity oopses Christoph Hellwig: o remove dead code from mv64340_eth o fix compiler warnings in mv64340_eth o allow modular mv64340_eth o convert skge to pci_driver API (2nd try) Domen Puncer: o remove old ifdefs net/eepro100.c François Romieu: o via-velocity: use common crc16 code for WOL o via-velocity: unneeded forward declarations o via-velocity: ordering of Rx descriptors operations o via-velocity: Rx copybreak o via-velocity: Rx buffers allocation rework o via-velocity: velocity_receive_frame diets o via-velocity: uniformize use of OWNED_BY_NIC o via-velocity: PCI ID move o r8169: tx lock removal o r8169: gcc bug workaround o r8169: initial link setup rework o r8169: link handling and phy reset rework o r8169: ethtool .get_{settings/link} o r8169: ethtool .set_settings o r8169: janitoring o r8169: cosmetic renaming of a register o r8169: napi support o epic100: code removal in irq handler o epic100: spin_unlock_irqrestore avoidance o [netdrvr epic100] napi fixes o [netdrvr epic100] napi 3/3 - transmit path o [netdrvr epic100] napi 2/3 - receive path o [netdrvr epic100] napi 1/3 - just shuffle some code around o [netdrvr epic100] minor cleanups Herbert Xu: o Fix successive calls to spin_lock_irqsave in sk98lin Kumar Gala: o add new ethernet driver 'gianfar' Margit Schubert-While: o prism54 Fix null pointer reference (Bug 100) o prism54 Fix initialization with older firmware o prism54 Refix TRDY/RETRY_TIMEOUT o prism54 Fix reference to uninitialized pointer Mika Kukkonen: o Fix warnings drivers/net/sk98lin/skaddr.c Paul Gortmaker: o Remove obsolete code in 8390 driver Ralf Bächle: o GT96100 update o [netdrvr mv643xx] rename from mv64340 to mv643xx o New driver for MV64340 GigE Roger Luethi: o Add WOL support o Small fixes and clean-up o Media mode rewrite o Fix Tx engine race for good o Remove options, full_duplex parameters o Rewrite PHY detection o Remove lingering PHY special casing o fix mc_filter on big-endian arch o Restructure reset code Scott Feldman: o e100: use NAPI mode all the time Stephen Hemminger: o acenic - don't print eth%d in messages o module_param for acenic o [sparse] minor #if complaint --------------010506040403050403020809-- From akpm@osdl.org Tue Jul 27 12:11:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 12:12:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RJBeGY024282 for ; Tue, 27 Jul 2004 12:11:40 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6RJBV122197; Tue, 27 Jul 2004 12:11:31 -0700 Date: Tue, 27 Jul 2004 12:10:08 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: mitya@school.ioffe.ru Subject: Fw: Opps with 2.6.7, 2.6.8-rc2 at shutdown Message-Id: <20040727121008.144dfd57.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__27_Jul_2004_12_10_08_-0700_o_GwI5AxebEaXXWL" X-archive-position: 7206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --Multipart=_Tue__27_Jul_2004_12_10_08_-0700_o_GwI5AxebEaXXWL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Begin forwarded message: Date: Tue, 27 Jul 2004 22:35:55 +0400 From: mitya@school.ioffe.ru (Dmitry Baryshkov) To: linux-kernel@vger.kernel.org Subject: Opps with 2.6.7, 2.6.8-rc2 at shutdown Hello, At shutdown, when calling ip route del 192.168.0.0/16 dev eth0 src 192.168.5.2 I'm getting following oops (text attached). I'm getting this oops at Debian 2.6.7-3 and vanilla 2.6.8-rc2 kernels. I'm getting this problem both with eepro100 and e100 drivers. I don't have this problem with 2.4 kernels (using 2.4.26). The box is dual PIII on VIA Apollo Pro chipset (GA-6VXDC7 motherboard). Tell me if you need more info. (attached oops text, dmesg with 2.6.8-rc2 and .config with that kernel) -- With best wishes Dmitry Baryshkov --Multipart=_Tue__27_Jul_2004_12_10_08_-0700_o_GwI5AxebEaXXWL Content-Type: text/plain; name="oops.txt" Content-Disposition: attachment; filename="oops.txt" Content-Transfer-Encoding: 7bit Unable to handle kernel paging request at virtual address f0a6a170 printing eip: f0a6a170 *pde = 2fe2b067 *pte = 00000000 Oops: 0000 [#1] SMP Modules linked in: nls_cp866 ipx p8022 llc lp smbfs ohci_hcd ehci_hcd uhci_hcd ipt_REJECT ipt_state ipt_LOG iptable_nat iptable_mangle iptable_filter ip_conntrack_irc ip_conntrack_ftp ip_conntrack ip_tables reiserfs via686a i2c_sensor i2c_isa i2c_dev i2c_core vfat fat sg scsi_mod CPU: 1 EIP: 0060:[] Not tainted EFLAGS: 00010282 (2.6.8-rc2) EIP is at 0xf0a6a170 eax: f0a6a170 ebx: 00000000 ecx: 00000000 edx: 0000000c esi: ee2d1000 edi: 00000006 ebp: 00000000 esp: ee1a3c38 ds: 007b es: 007b ss: 0068 Process ip (pid: 5052, threadinfo=ee1a2000 task=ef0ce710) Stack: c02e4750 ee2d1000 00000006 00000008 c040df68 c040df68 00000000 00000ce8 ed71122c 000005c8 ee2d1000 00000003 00000000 efcbf560 c02e48f8 ed7a0ec0 ee2d1000 00000010 000013bc 410695e9 00000000 efcbf560 ed7a0ec0 efcbf560 Call Trace: [] rtnetlink_fill_ifinfo+0x3a0/0x4c0 [] rtnetlink_dump_ifinfo+0x88/0x90 [] netlink_dump+0x63/0x1d0 [] netlink_dump_start+0xdc/0x130 [] rtnetlink_rcv+0x35f/0x3a0 [] rtnetlink_dump_ifinfo+0x0/0x90 [] rtnetlink_done+0x0/0x10 [] journal_stop+0x1b1/0x270 [] netlink_data_read+0x60/0x70 [] netlink_sendskb+0xa3/0xb0 [] netlink_sendmsg+0x219/0x310 [] __mark_inode_dirty+0x1ba/0x1c0 [] sock_sendmsg+0x9d/0xc0 [] find_get_page+0x29/0x40 [] move_addr_to_kernel+0x38/0x50 [] sys_sendto+0xdc/0x100 [] do_page_fault+0x14c/0x570 [] __sock_create+0xd5/0x200 [] cpy_from_user+0x42/0x70 [] sys_socketcall+0x195/0x260 [] syscall_call+0x7/0xb Code: Bad EIP value. --Multipart=_Tue__27_Jul_2004_12_10_08_-0700_o_GwI5AxebEaXXWL Content-Type: text/plain; name="dmesg" Content-Disposition: attachment; filename="dmesg" Content-Transfer-Encoding: 7bit Linux version 2.6.8-rc2 (root@chimpanzee) (gcc version 3.3.4 (Debian 1:3.3.4-3)) #1 SMP Tue Jul 27 21:30:44 MSD 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000002fff0000 (usable) BIOS-e820: 000000002fff0000 - 000000002fff8000 (ACPI data) BIOS-e820: 000000002fff8000 - 0000000030000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 767MB LOWMEM available. found SMP MP-table at 000fb170 On node 0 totalpages: 196592 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 192496 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000fc5b0 ACPI: RSDT (v001 AMIINT 0x00000010 MSFT 0x00000099) @ 0x2fff0000 ACPI: FADT (v001 AMIINT 0x00000011 MSFT 0x00000099) @ 0x2fff0030 ACPI: MADT (v001 AMIINT 0x00000009 MSFT 0x00000099) @ 0x2fff00b0 ACPI: DSDT (v001 VIA APOLLO-P 0x00001000 MSFT 0x0100000b) @ 0x00000000 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: Assigned apic_id 2 IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ5 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Built 1 zonelists Kernel command line: BOOT_IMAGE=Linux ro root=90b devfs=nomount Initializing CPU#0 PID hash table entries: 4096 (order 12: 32768 bytes) Detected 864.157 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 774636k/786368k available (2372k kernel code, 10984k reserved, 1003k data, 192k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1708.03 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 06 per-CPU timeslice cutoff: 730.77 usecs. task migration cache decay timeout: 1 msecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000084 ESR value after enabling vector: 00000000 Booting processor 1/1 eip 3000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 1724.41 BogoMIPS CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (3432.44 BogoMIPS). ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 863.0476 MHz. ..... host bus clock speed is 132.0842 MHz. checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs CPU0: online domain 0: span 3 groups: 1 2 CPU1: online domain 0: span 3 groups: 2 1 NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs. mtrr: corrected configuration. ACPI: Subsystem revision 20040326 tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:............................................................................................................. Table [DSDT](id F004) - 450 Objects with 35 Devices 109 Methods 31 Regions ACPI Namespace successfully loaded at root c049fcfc evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode successful evgpeblk-0867 [06] ev_create_gpe_block : GPE 00 to 15 [_GPE] 2 regs at 0000000000000820 on int 5 evgpeblk-0925 [06] ev_create_gpe_block : Found 0 Wake, Enabled 4 Runtime GPEs in this block Completing Region/Field/Buffer/Package initialization:................................................................................................ Initialized 31/31 Regions 19/19 Fields 31/31 Buffers 15/15 Packages (459 nodes) Executing all Device _STA and_INI methods:...................................... 38 Devices found containing: 38 _STA, 2 _INI methods 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: Power Resource [URP1] (off) ACPI: Power Resource [URP2] (off) ACPI: Power Resource [FDDP] (off) ACPI: Power Resource [LPTP] (off) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00f6a10 PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x58e4, dseg 0xf0000 PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9 ACPI: PCI interrupt 0000:00:07.2[D] -> GSI 9 (level, low) -> IRQ 9 ACPI: PCI interrupt 0000:00:07.3[D] -> GSI 9 (level, low) -> IRQ 9 ACPI: PCI interrupt 0000:00:09.0[A] -> GSI 17 (level, low) -> IRQ 17 ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 17 (level, low) -> IRQ 17 number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011 .... register #02: 00000000 ....... : arbitration: 00 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 003 03 0 0 0 0 0 1 1 39 02 003 03 0 0 0 0 0 1 1 31 03 003 03 0 0 0 0 0 1 1 41 04 003 03 0 0 0 0 0 1 1 49 05 003 03 0 1 0 1 0 1 1 51 06 003 03 0 0 0 0 0 1 1 59 07 003 03 0 0 0 0 0 1 1 61 08 003 03 0 0 0 0 0 1 1 69 09 003 03 1 1 0 1 0 1 1 71 0a 003 03 0 0 0 0 0 1 1 79 0b 003 03 0 0 0 0 0 1 1 81 0c 003 03 0 0 0 0 0 1 1 89 0d 003 03 0 0 0 0 0 1 1 91 0e 003 03 0 0 0 0 0 1 1 99 0f 003 03 0 0 0 0 0 1 1 A1 10 003 03 1 1 0 1 0 1 1 B1 11 003 03 1 1 0 1 0 1 1 A9 12 000 00 1 0 0 0 0 0 0 00 13 000 00 1 0 0 0 0 0 0 00 14 050 00 1 0 0 0 0 0 2 40 15 000 00 1 0 0 0 0 0 0 00 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 .................................... done. IA-32 Microcode Update Driver: v1.14 Starting balanced_irq VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x0 Installing knfsd (copyright (C) 1996 okir@monad.swb.de). NTFS driver 2.1.15 [Flags: R/W]. Initializing Cryptographic API PCI: Enabling Via external APIC routing ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Processor [CPU1] (supports C1) ACPI: Processor [CPU2] (supports C1) ACPI: Thermal Zone [THRM] (40 C) isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Real Time Clock Driver v1.12 Non-volatile memory driver v1.2 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA Apollo Pro 133 chipset agpgart: Maximum main memory to use for agp memory: 690M agpgart: AGP aperture is 16M @ 0xe0000000 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport_pc: Via 686A parallel port: io=0x378 Using anticipatory io scheduler Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize e100: Intel(R) PRO/100 Network Driver, 3.0.18 e100: Copyright(c) 1999-2004 Intel Corporation ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 16 (level, low) -> IRQ 16 e100: eth0: e100_probe: addr 0xdbfed000, irq 16, MAC addr 00:D0:B7:3C:EC:78 ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 17 (level, low) -> IRQ 17 e100: eth1: e100_probe: addr 0xdbfee000, irq 17, MAC addr 00:D0:B7:3C:EC:7A 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:07.1 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci0000:00:07.1 ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA hda: ST340014A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: ST340014A, ATA DISK drive hdd: IBM-DTLA-307030, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 1024KiB hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(66) /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 > hdc: max request size: 1024KiB hdc: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(66) /dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 > hdd: max request size: 128KiB hdd: 60036480 sectors (30738 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(66) /dev/ide/host0/bus1/target1/lun0: p1 mice: PS/2 mouse device common for all mice input: PC Speaker serio: i8042 AUX port at 0x60,0x64 irq 12 input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 md: raid5 personality registered as nr 4 raid5: automatically using best checksumming function: pIII_sse pIII_sse : 1728.000 MB/sec raid5: using function: pIII_sse (1728.000 MB/sec) 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 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 ACPI: (supports S0 S1 S4 S5) BIOS EDD facility v0.16 2004-Jun-25, 3 devices found md: Autodetecting RAID arrays. md: autorun ... md: considering hdd1 ... md: adding hdd1 ... md: adding hdc7 ... md: hdc6 has different UUID to hdd1 md: hdc5 has different UUID to hdd1 md: hdc3 has different UUID to hdd1 md: hdc1 has different UUID to hdd1 md: adding hda7 ... md: hda6 has different UUID to hdd1 md: hda5 has different UUID to hdd1 md: hda3 has different UUID to hdd1 md: hda2 has different UUID to hdd1 md: hda1 has different UUID to hdd1 md: created md20 md: bind md: bind md: bind md: running: md: considering hdc6 ... md: adding hdc6 ... md: hdc5 has different UUID to hdc6 md: hdc3 has different UUID to hdc6 md: hdc1 has different UUID to hdc6 md: adding hda6 ... md: hda5 has different UUID to hdc6 md: hda3 has different UUID to hdc6 md: hda2 has different UUID to hdc6 md: hda1 has different UUID to hdc6 md: created md16 md: bind md: bind md: running: raid1: raid set md16 active with 2 out of 2 mirrors md: considering hdc5 ... md: adding hdc5 ... md: hdc3 has different UUID to hdc5 md: hdc1 has different UUID to hdc5 md: adding hda5 ... md: hda3 has different UUID to hdc5 md: hda2 has different UUID to hdc5 md: hda1 has different UUID to hdc5 md: created md15 md: bind md: bind md: running: raid1: raid set md15 active with 2 out of 2 mirrors md: considering hdc3 ... md: adding hdc3 ... md: hdc1 has different UUID to hdc3 md: adding hda3 ... md: hda2 has different UUID to hdc3 md: hda1 has different UUID to hdc3 md: created md13 md: bind md: bind md: running: raid1: raid set md13 active with 2 out of 2 mirrors md: considering hdc1 ... md: adding hdc1 ... md: hda2 has different UUID to hdc1 md: adding hda1 ... md: created md11 md: bind md: bind md: running: raid1: raid set md11 active with 2 out of 2 mirrors md: considering hda2 ... md: adding hda2 ... md: created md12 md: bind md: running: raid1: raid set md12 active with 1 out of 2 mirrors md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 192k freed Adding 995896k swap on /dev/md13. Priority:-1 extents:1 EXT3 FS on md11, internal journal SCSI subsystem initialized i2c /dev entries driver kjournald starting. Commit interval 5 seconds EXT3 FS on md15, internal journal EXT3-fs: mounted filesystem with ordered data mode. ReiserFS: hdc8: found reiserfs format "3.6" with standard journal ReiserFS: hdc8: using ordered data mode ReiserFS: hdc8: journal params: device hdc8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hdc8: checking transaction log (hdc8) ReiserFS: hdc8: Using r5 hash to sort names kjournald starting. Commit interval 5 seconds EXT3 FS on md16, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md12, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md20, internal journal EXT3-fs: mounted filesystem with ordered data mode. ip_tables: (C) 2000-2002 Netfilter core team ip_conntrack version 2.1 (6143 buckets, 49144 max) - 300 bytes per conntrack USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:07.2[D] -> GSI 9 (level, low) -> IRQ 9 uhci_hcd 0000:00:07.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:07.2: irq 9, io base 0000d000 uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:07.3[D] -> GSI 9 (level, low) -> IRQ 9 uhci_hcd 0000:00:07.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:07.3: irq 9, io base 0000d400 uhci_hcd 0000:00:07.3: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci_hcd: block sizes: ed 64 td 64 e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex IPv4 over IPv4 tunneling driver e100: eth1: e100_watchdog: link up, 100Mbps, full-duplex --Multipart=_Tue__27_Jul_2004_12_10_08_-0700_o_GwI5AxebEaXXWL Content-Type: text/plain; name="config-2.6.8-rc2" Content-Disposition: attachment; filename="config-2.6.8-rc2" Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y # CONFIG_STANDALONE is not set # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_SMP=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_SOFTWARE_SUSPEND is not set # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_USE_VECTOR is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_CML1=y CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y CONFIG_PNPBIOS=y CONFIG_PNPBIOS_PROC_FS=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # # CONFIG_IDE_GENERIC is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=m CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set # CONFIG_SCSI_ATA_PIIX is not set # CONFIG_SCSI_SATA_NV is not set # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_SX4 is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIS is not set # CONFIG_SCSI_SATA_VIA is not set # CONFIG_SCSI_SATA_VITESSE is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=m # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y # CONFIG_MD_RAID6 is not set CONFIG_MD_MULTIPATH=m # CONFIG_BLK_DEV_DM is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # CONFIG_I2O=m CONFIG_I2O_CONFIG=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y # CONFIG_IP_ROUTE_NAT is not set # CONFIG_IP_ROUTE_MULTIPATH is not set CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set CONFIG_LLC=m CONFIG_LLC2=m CONFIG_IPX=m # CONFIG_IPX_INTERN is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m # CONFIG_CLS_U32_PERF is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m # CONFIG_EQUALIZER is not set CONFIG_TUN=m # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y CONFIG_E100_NAPI=y # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set # CONFIG_NET_FC is not set CONFIG_SHAPER=m CONFIG_NETCONSOLE=m # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set # CONFIG_QIC02_TAPE is not set # # IPMI # CONFIG_IPMI_HANDLER=m CONFIG_IPMI_PANIC_EVENT=y CONFIG_IPMI_PANIC_STRING=y CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_I8XX_TCO is not set # CONFIG_SC1200_WDT is not set # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_MACHZ_WDT is not set # # ISA-based Watchdog Cards # # CONFIG_PCWATCHDOG is not set # CONFIG_MIXCOMWD is not set # CONFIG_WDT is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_HW_RANDOM=y CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_INTEL_MCH is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y # CONFIG_AGP_EFFICEON is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_NOMMAP=y # CONFIG_HANGCHECK_TIMER is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ALGOPCF is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set CONFIG_I2C_ISA=m # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # # Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM75 is not set CONFIG_SENSORS_LM77=m # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_MAX1619 is not set CONFIG_SENSORS_VIA686A=m # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # # Other I2C Chip support # CONFIG_SENSORS_EEPROM=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # CONFIG_W1=m # CONFIG_W1_MATROX is not set CONFIG_W1_THERM=m # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # # CONFIG_USB_DEVICEFS is not set # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_RW_DETECT is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETSERVO is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y # CONFIG_REISERFS_FS_XATTR is not set # CONFIG_JFS_FS is not set CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_MINIX_FS is not set CONFIG_ROMFS_FS=m CONFIG_QUOTA=y CONFIG_QFMT_V1=y CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=866 CONFIG_FAT_DEFAULT_IOCHARSET="koi8-r" CONFIG_NTFS_FS=y # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_CRAMFS=y # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="koi8-r" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set CONFIG_NLS_CODEPAGE_855=m # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set CONFIG_NLS_CODEPAGE_866=m # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set CONFIG_NLS_ISO8859_5=m # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=y # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_SLAB is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --Multipart=_Tue__27_Jul_2004_12_10_08_-0700_o_GwI5AxebEaXXWL-- From garzik@havoc.gtf.org Tue Jul 27 12:52:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 12:52:49 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RJqYpZ028210 for ; Tue, 27 Jul 2004 12:52:34 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 0EF3E7717; Tue, 27 Jul 2004 15:52:20 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i6RJqJjv029867; Tue, 27 Jul 2004 15:52:19 -0400 Date: Tue, 27 Jul 2004 15:52:19 -0400 From: Jeff Garzik To: Andrew Morton , Linus Torvalds Cc: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x prism54 fixes Message-ID: <20040727195219.GA29777@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 7207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/wireless/prism54/isl_ioctl.c | 16 +++++++++------- drivers/net/wireless/prism54/islpci_hotplug.c | 17 ++++++++++------- drivers/net/wireless/prism54/islpci_mgt.c | 2 ++ drivers/net/wireless/prism54/oid_mgt.c | 6 ++++-- 4 files changed, 25 insertions(+), 16 deletions(-) through these ChangeSets: (04/07/27 1.1932) [PATCH] prism54 Fix null pointer reference (Bug 100) * prism54_get/set_debug_oid are missing checks for a null pointer. Reported in Bugzilla number 100. (04/07/27 1.1931) [PATCH] prism54 Fix initialization with older firmware * In the card initialization routine, we try to set the output power. For firmware < 1.0.4.3, this leads to a worrying "mgt_commit has failed .." in the log although the device continues to react normally. Fix is simple, do not try to configure output power. (which I believe we should not be doing anyway as it is probably against local country regulations) (04/07/27 1.1930) [PATCH] prism54 Refix TRDY/RETRY_TIMEOUT * Reintroduce pushing 0 into the TRDY_TIMEOUT and RETRY_TIMEOUT registers. Make this configurable with module parameter init_pcitm. * We now have the ludicrous situation that some hardware setups require this (not even pushing 0xFF helps), whilst others don't care either way (the majority), and yet others bork if anything is pushed into these regs. If anybody can explain this (including Conexant :-) ), my ears are open. (04/07/27 1.1929) [PATCH] prism54 Fix reference to uninitialized pointer * oid_mgt.c is calling islpci_mgt_transaction passing the address of a pointer to the management frame. This is not being initialized by the caller. The callee only updates this pointer when successful. When not, boom. * Being ultracautious again, not only initialize in the caller, also null out the pointer unconditionally in the callee. diff -Nru a/drivers/net/wireless/prism54/isl_ioctl.c b/drivers/net/wireless/prism54/isl_ioctl.c --- a/drivers/net/wireless/prism54/isl_ioctl.c 2004-07-27 15:51:18 -04:00 +++ b/drivers/net/wireless/prism54/isl_ioctl.c 2004-07-27 15:51:18 -04:00 @@ -1942,7 +1942,7 @@ { islpci_private *priv = netdev_priv(ndev); struct islpci_mgmtframe *response = NULL; - int ret = -EIO, response_op = PIMFOR_OP_ERROR; + int ret = -EIO; printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); data->length = 0; @@ -1952,9 +1952,7 @@ islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, priv->priv_oid, extra, 256, &response); - response_op = response->header->operation; printk("%s: ret: %i\n", ndev->name, ret); - printk("%s: response_op: %i\n", ndev->name, response_op); if (ret || !response || response->header->operation == PIMFOR_OP_ERROR) { if (response) { @@ -1991,15 +1989,19 @@ priv->priv_oid, extra, data->length, &response); printk("%s: ret: %i\n", ndev->name, ret); + if (ret || !response + || response->header->operation == PIMFOR_OP_ERROR) { + if (response) { + islpci_mgt_release(response); + } + printk("%s: EIO\n", ndev->name); + ret = -EIO; + } if (!ret) { response_op = response->header->operation; printk("%s: response_op: %i\n", ndev->name, response_op); islpci_mgt_release(response); - } - if (ret || response_op == PIMFOR_OP_ERROR) { - printk("%s: EIO\n", ndev->name); - ret = -EIO; } } diff -Nru a/drivers/net/wireless/prism54/islpci_hotplug.c b/drivers/net/wireless/prism54/islpci_hotplug.c --- a/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-27 15:51:18 -04:00 +++ b/drivers/net/wireless/prism54/islpci_hotplug.c 2004-07-27 15:51:18 -04:00 @@ -36,6 +36,9 @@ MODULE_DESCRIPTION("The Prism54 802.11 Wireless LAN adapter"); MODULE_LICENSE("GPL"); +static int init_pcitm = 0; +module_param(init_pcitm, int, 0); + /* In this order: vendor, device, subvendor, subdevice, class, class_mask, * driver_data * If you have an update for this please contact prism54-devel@prism54.org @@ -292,14 +295,14 @@ * * Writing zero to both these two registers will disable both timeouts and * *can* solve problems caused by devices that are slow to respond. + * Make this configurable - MSW */ - /* I am taking these out, we should not be poking around in the - * programmable timers - MSW - */ -/* Do not zero the programmable timers - pci_write_config_byte(pdev, 0x40, 0); - pci_write_config_byte(pdev, 0x41, 0); -*/ + if ( init_pcitm >= 0 ) { + pci_write_config_byte(pdev, 0x40, (u8)init_pcitm); + pci_write_config_byte(pdev, 0x41, (u8)init_pcitm); + } else { + printk(KERN_INFO "PCI TRDY/RETRY unchanged\n"); + } /* request the pci device I/O regions */ rvalue = pci_request_regions(pdev, DRV_NAME); diff -Nru a/drivers/net/wireless/prism54/islpci_mgt.c b/drivers/net/wireless/prism54/islpci_mgt.c --- a/drivers/net/wireless/prism54/islpci_mgt.c 2004-07-27 15:51:18 -04:00 +++ b/drivers/net/wireless/prism54/islpci_mgt.c 2004-07-27 15:51:18 -04:00 @@ -458,6 +458,8 @@ int err; DEFINE_WAIT(wait); + *recvframe = NULL; + if (down_interruptible(&priv->mgmt_sem)) return -ERESTARTSYS; diff -Nru a/drivers/net/wireless/prism54/oid_mgt.c b/drivers/net/wireless/prism54/oid_mgt.c --- a/drivers/net/wireless/prism54/oid_mgt.c 2004-07-27 15:51:18 -04:00 +++ b/drivers/net/wireless/prism54/oid_mgt.c 2004-07-27 15:51:18 -04:00 @@ -408,7 +408,7 @@ mgt_set_request(islpci_private *priv, enum oid_num_t n, int extra, void *data) { int ret = 0; - struct islpci_mgmtframe *response; + struct islpci_mgmtframe *response = NULL; int response_op = PIMFOR_OP_ERROR; int dlen; void *cache, *_data = data; @@ -613,14 +613,16 @@ DOT11_OID_DEFKEYID, DOT11_OID_DOT1XENABLE, OID_INL_DOT11D_CONFORMANCE, + /* Do not initialize this - fw < 1.0.4.3 rejects it OID_INL_OUTPUTPOWER, + */ }; /* update the MAC addr. */ static int mgt_update_addr(islpci_private *priv) { - struct islpci_mgmtframe *res; + struct islpci_mgmtframe *res = NULL; int ret; ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, From Robert.Olsson@data.slu.se Tue Jul 27 13:24:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 13:24:24 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RKOIkq029215 for ; Tue, 27 Jul 2004 13:24:19 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6RKO1IR009741; Tue, 27 Jul 2004 22:24:02 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id CFAD5EC33E; Tue, 27 Jul 2004 22:24:01 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16646.47585.814327.628319@robur.slu.se> Date: Tue, 27 Jul 2004 22:24:01 +0200 To: Pasi Sjoholm Cc: Robert Olsson , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <16646.14381.740376.204381@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Pasi Sjoholm writes: > Yeah, when the ksoftirqd is taking all the cpu it will be like that, but > when the kernel is behaving normally the starving diff is between 0->1sec. Well ksoftirqd makes your kernel load just visible which is good and ksofirqd gets accounted for this when softirq's get deferred to it. It may look like goes from 0 to 100% but thats probably not the case. The problem is we can starve userland at high loads. As said we were trying some way to cure this I may have some old patch if you like to try. Cheers. --ro From ptsjohol@cc.jyu.fi Tue Jul 27 14:27:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 14:28:00 -0700 (PDT) Received: from posti5.jyu.fi (posti5.jyu.fi [130.234.4.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RLRqwS030345 for ; Tue, 27 Jul 2004 14:27:53 -0700 Received: from silmu.st.jyu.fi (IDENT:snMp+Lun+1lfmouA2fRm+DECel9zLPYT@silmu.st.jyu.fi [130.234.4.64]) by posti5.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6RLRRcn020365; Wed, 28 Jul 2004 00:27:27 +0300 Date: Wed, 28 Jul 2004 00:27:26 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Robert Olsson cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16646.47585.814327.628319@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti5.jyu.fi; Wed, 28 Jul 2004 00:27:29 +0300 X-archive-position: 7209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev On Tue, 27 Jul 2004, Robert Olsson wrote: > > Yeah, when the ksoftirqd is taking all the cpu it will be like that, but > > when the kernel is behaving normally the starving diff is between 0->1sec. > Well ksoftirqd makes your kernel load just visible which is good and > ksofirqd gets accounted for this when softirq's get deferred to it. > It may look like goes from 0 to 100% but thats probably not the case. > The problem is we can starve userland at high loads. As said we were > trying some way to cure this I may have some old patch if you like to try. Ok, as I said before I'm willing to test your patches. It would be nice that one could use the full capacity of his/her computer. This is not a big problem for everyday use for a workstation but prevents 2.6-series to be used in production-enviroments in the servers. But hey.. we need to do some work and maybe we will resolve this. =) -- Pasi Sjöholm From niranjan_cs2905@yahoo.com Tue Jul 27 15:23:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 15:23:47 -0700 (PDT) Received: from web53005.mail.yahoo.com (web53005.mail.yahoo.com [206.190.39.195]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6RMNfXS031419 for ; Tue, 27 Jul 2004 15:23:41 -0700 Message-ID: <20040727222333.14936.qmail@web53005.mail.yahoo.com> Received: from [128.119.85.178] by web53005.mail.yahoo.com via HTTP; Tue, 27 Jul 2004 15:23:33 PDT Date: Tue, 27 Jul 2004 15:23:33 -0700 (PDT) From: Niranjan Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 To: Vladimir Kondratiev , James Morris Cc: Matt Mackall , Niranjan , netdev@oss.sgi.com In-Reply-To: <200407272150.50664.vkondra@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niranjan_cs2905@yahoo.com Precedence: bulk X-list: netdev Thanks for all your help. I didn't found any group which is maintaining CryptoAPI. I am using cryptoapi-0.1.0 and there is no crypto/api.c file. But the memory allocation in this version (cryptoapi-0.1.0) is using GFP_KERNEL. I really didn't understand how to solve the problem using BH. Now, I am reading kernel locking HOWTO to understand BH and softirq. I will also try adding crypto functions inside the WLAN driver. Warm Regards, -Niranjan UMASS. --- Vladimir Kondratiev wrote: > On Tuesday 27 July 2004 21:39, James Morris wrote: > > On Tue, 27 Jul 2004, Vladimir Kondratiev wrote: > > > We also saw the same (crypto modules goes to > sleep). > > > Due to this, we decided to not use cryptoapi for > our wireless driver, but > > > compile the same crypto functions into the > driver. I know this is code > > > duplication, but Tx and Rx paths work in BH > context (I reschedule it on > > > IRQ Rx to use cheaper time). > > > > > > Do cryptoapi maintainers aware of this issue? > > > > The crypto functions should be safe to use in > softirq context. > It should be, but: > > struct crypto_tfm *crypto_alloc_tfm(const char > *name, u32 flags) > { > struct crypto_tfm *tfm = NULL; > struct crypto_alg *alg; > > alg = crypto_alg_mod_lookup(name); > if (alg == NULL) > goto out; > > tfm = kmalloc(sizeof(*tfm) + > alg->cra_ctxsize, GFP_KERNEL); > > Note kmalloc(GFP_KERNEL) > > > > > > - James > > ATTACHMENT part 2 application/pgp-signature __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From rmk+netdev=oss.sgi.com@arm.linux.org.uk Tue Jul 27 15:36:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 15:36:43 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6RMaZYS031857 for ; Tue, 27 Jul 2004 15:36:36 -0700 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.33) id 1BpaYV-0003GK-PY; Tue, 27 Jul 2004 23:36:20 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.33) id 1BpaYS-0008FX-Ma; Tue, 27 Jul 2004 23:36:16 +0100 Date: Tue, 27 Jul 2004 23:36:14 +0100 From: Russell King To: Jeff Garzik , shemminger@osdl.org, davem@redhat.com, netdev@oss.sgi.com, Greg KH Subject: Re: [Fwd: pcmcia ether drivers can't be unloaded] Message-ID: <20040727233614.B30782@flint.arm.linux.org.uk> References: <41068BEF.7010200@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <41068BEF.7010200@pobox.com>; from jgarzik@pobox.com on Tue, Jul 27, 2004 at 01:07:59PM -0400 X-archive-position: 7211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: netdev On Tue, Jul 27, 2004 at 01:07:59PM -0400, Jeff Garzik wrote: > It looks like pcmica modular ether (example orinoco) can never be manually > unloaded because module refcount is always 1. This comes from the owner > field in the pcmcia_driver.owner being set. Intended behaviour. As long as the driver is bound to a socket, there are references to the driver, so we need to keep the refcount non-zero. Once the driver is unbound (by ejecting cards) then the ref count will drop to zero and the module can be unloaded. > One fix is to not set owner field but then there is a hot plug/module > remove race. But the right fix seems to fix up pcmcia to be a true bus > in the driver model and have the same hotplug as other buses; usb and > pci don't have the problem. No, the right fix is not to try to fsck with PCMCIA refcounting - it isn't up to having drivers randomly unloaded. IOW, it remains 2.4 behaviour. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core From davem@redhat.com Tue Jul 27 17:21:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 17:21:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6S0LV64004116 for ; Tue, 27 Jul 2004 17:21:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6S0LEe1026377; Tue, 27 Jul 2004 20:21:14 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6S0LEa22732; Tue, 27 Jul 2004 20:21:14 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6S0KXbA009591; Tue, 27 Jul 2004 20:20:34 -0400 Date: Tue, 27 Jul 2004 17:19:29 -0700 From: "David S. Miller" To: Russell King Cc: jgarzik@pobox.com, shemminger@osdl.org, netdev@oss.sgi.com, greg@kroah.com Subject: Re: [Fwd: pcmcia ether drivers can't be unloaded] Message-Id: <20040727171929.17858c7b.davem@redhat.com> In-Reply-To: <20040727233614.B30782@flint.arm.linux.org.uk> References: <41068BEF.7010200@pobox.com> <20040727233614.B30782@flint.arm.linux.org.uk> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 27 Jul 2004 23:36:14 +0100 Russell King wrote: > > One fix is to not set owner field but then there is a hot plug/module > > remove race. But the right fix seems to fix up pcmcia to be a true bus > > in the driver model and have the same hotplug as other buses; usb and > > pci don't have the problem. > > No, the right fix is not to try to fsck with PCMCIA refcounting - it > isn't up to having drivers randomly unloaded. IOW, it remains 2.4 > behaviour. I totally disagree. This is a bogus argument for two reasons: 1) If the PCMCIA layer can handle cards popping out at any time, physically, it is illogical to handicap it on the software side in terms of this. 2) There is no way I can stomache "some" networking cards not being able to have their modules yanked at any point in time. An enormous amount of effort has gone into making networking devices and drivers yankable regardless of how configured they are and what resources are attached to it. You have to be kidding me to say that the one subsystem that should handle hot plugging of stuff the best (PCMCIA) can't handle something that all of our "normal" PCI and USB drivers can? The fact is this, device unload of an arbitrary network driver should work at any point in time, and succeed unloading within a second or two. Anything else is a bug. From chas@cmf.nrl.navy.mil Tue Jul 27 17:42:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 17:42:06 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6S0fxg4004694 for ; Tue, 27 Jul 2004 17:41:59 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i6S0fcMe010687; Tue, 27 Jul 2004 20:41:40 -0400 (EDT) Message-Id: <200407280041.i6S0fcMe010687@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com, carnil@cs.tut.fi Subject: [PATCH][ATM]: [lec] remove unnecessary inlines (from Adrian Bunk ) Reply-To: chas3@users.sourceforge.net Date: Tue, 27 Jul 2004 20:41:39 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 7213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev please apply to 2.6 -- thanks! # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1882 -> 1.1883 # net/atm/lec.c 1.43 -> 1.44 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/07/27 chas@relax.cmf.nrl.navy.mil 1.1883 # [ATM]: [lec] remove unnecessary inlines (from Adrian Bunk ) # -------------------------------------------- # diff -Nru a/net/atm/lec.c b/net/atm/lec.c --- a/net/atm/lec.c Tue Jul 27 20:06:05 2004 +++ b/net/atm/lec.c Tue Jul 27 20:06:05 2004 @@ -71,9 +71,9 @@ static int lec_close(struct net_device *dev); static struct net_device_stats *lec_get_stats(struct net_device *dev); static void lec_init(struct net_device *dev); -static inline struct lec_arp_table* lec_arp_find(struct lec_priv *priv, +static struct lec_arp_table* lec_arp_find(struct lec_priv *priv, unsigned char *mac_addr); -static inline int lec_arp_remove(struct lec_priv *priv, +static int lec_arp_remove(struct lec_priv *priv, struct lec_arp_table *to_remove); /* LANE2 functions */ static void lane2_associate_ind (struct net_device *dev, u8 *mac_address, @@ -1468,7 +1468,7 @@ /* * Remove entry from lec_arp_table */ -static inline int +static int lec_arp_remove(struct lec_priv *priv, struct lec_arp_table *to_remove) { @@ -1755,7 +1755,7 @@ /* * Find entry by mac_address */ -static inline struct lec_arp_table* +static struct lec_arp_table* lec_arp_find(struct lec_priv *priv, unsigned char *mac_addr) { From jes@trained-monkey.org Tue Jul 27 23:37:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jul 2004 23:37:38 -0700 (PDT) Received: from jaguar.mkp.net (jaguar.mkp.net [192.139.46.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6S6bWkM013767 for ; Tue, 27 Jul 2004 23:37:32 -0700 Received: from jes by jaguar.mkp.net with local (Exim 3.35 #1) id 1Bpi46-0004BA-00; Wed, 28 Jul 2004 02:37:26 -0400 To: Anton Blanchard Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: Use NET_IP_ALIGN in acenic References: <20040724174348.GL4556@krispykreme> From: Jes Sorensen Date: 28 Jul 2004 02:37:25 -0400 In-Reply-To: <20040724174348.GL4556@krispykreme> Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jes@wildopensource.com Precedence: bulk X-list: netdev >>>>> "Anton" == Anton Blanchard writes: Anton> Use NET_IP_ALIGN in acenic driver. Also remove the 16 byte Anton> padding, caches can be anywhere from 16 to 256 bytes and the Anton> skb should be cacheline aligned already. Hi Anton, I don't have any objections to this one, however the main reason for the 14 byte padding was to 32 bit align the IP header to avoid too many misaligned loads rather than hitting any cache boundary. Cheers, Jes From weixl@cs.caltech.edu Wed Jul 28 02:48:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 02:49:07 -0700 (PDT) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6S9mnqN022425 for ; Wed, 28 Jul 2004 02:48:49 -0700 Received: from weixl (c-67-161-36-77.client.comcast.net [67.161.36.77]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id B7D8CDF2DB; Wed, 28 Jul 2004 02:48:44 -0700 (PDT) Message-ID: <013001c47488$12a03500$8900a8c0@weixl> From: "Xiaoliang (David) Wei" To: "Injong Rhee" , "'David S. Miller'" , "'Stephen Hemminger'" Cc: , , References: <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com> Subject: Re: [RFC] TCP burst control Date: Wed, 28 Jul 2004 02:48:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weixl@cs.caltech.edu Precedence: bulk X-list: netdev Hi Injong and other Gurus, I support this approach to decouple congestion control and burstiness control. But I have a question for the patch code. My question is about the tcp_cwnd_application_limited() in tcp_input.c (@@ -3823,8 +3828,13 @@ in the patch). My understanding is that tcp_cwnd_application_limited() is to reduce the cwnd, according to RFC 2861, to avoid a large sending rate when the connection resumes full sending speed. The window reduction here is not to reduce burstiness, but to reduce the cwnd (since the cwnd is not a good congestion measure after the idling period). But the patch seems to take this congestion window reduction as a burstiness reduction mechanism, too. I guess we don't need to change the window reduction in this function? Please correct me if I made any mistake. Thanks:) I copied the part of patch codes that I'm not sure: ------------------------------------------------------------ @@ -3823,8 +3828,13 @@ /* Limited by application or receiver window. */ u32 win_used = max(tp->snd_cwnd_used, 2U); if (win_used < tp->snd_cwnd) { + u32 limit = (tp->snd_cwnd + win_used) >> 1; tp->snd_ssthresh = tcp_current_ssthresh(tp); - tp->snd_cwnd = (tp->snd_cwnd + win_used) >> 1; + if (sysctl_tcp_burst_moderation) + tp->snd_cwnd = min(tp->snd_cwnd, + max(tp->snd_ssthresh, limit)); + else + tp->snd_cwnd = limit; } tp->snd_cwnd_used = 0; } ------------------------------------------------------------ -David Xiaoliang (David) Wei Graduate Student in CS@Caltech http://www.cs.caltech.edu/~weixl ==================================================== ----- Original Message ----- From: "Injong Rhee" To: "'David S. Miller'" ; "'Stephen Hemminger'" Cc: ; ; Sent: Tuesday, July 06, 2004 5:09 PM Subject: RE: [RFC] TCP burst control > Hi David and Stephen, > > We tested this rate halving. In fact, rate having in fact degrades the > performance quite a bit. We can send you more information about it. Our test > indicates that this feature introduces many timeouts (because of bursts), > and also cause unnecessary cwnd backoff to reduce the transmission > unjustifiably low -- so there are many (I will repeat, many) window and > transmission oscillations during packet losses. We fix this problem > completely using our own special burst control. It is very simple and easy > technique to implement. If you need some data to back up our claims, I will > send you more. Once we implemented our burst control, we don't have any > timeouts and not much fluctuation other than congestion control related. > Currently with rate having, current Linux tcp stack is full of hacks that in > fact, hurt the performance of linux tcp (sorry to say this). Our burst > control, in fact, simplifies a lot of that and makes sure cwnd to follow > very closely to whatever congestion control algorithm is intended it to > behave. The Linux Reno burst control in fact interferes with the original > congestion control (in fact, it tries to do its own), and its performance is > very hard to predict. > > Hope this helps. > > Injong Rhee, Associate Professor > North Carolina State University > Raleigh, NC 27699 > rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee > > > -----Original Message----- > From: David S. Miller [mailto:davem@redhat.com] > Sent: Tuesday, July 06, 2004 7:05 PM > To: Stephen Hemminger > Cc: netdev@oss.sgi.com; rhee@ncsu.edu > Subject: Re: [RFC] TCP burst control > > On Tue, 6 Jul 2004 15:58:58 -0700 > Stephen Hemminger wrote: > > > When using advanced congestion control it is possible for TCP to decide > that > > it has a large window to fill with data right away. The problem is that if > TCP > > creates long bursts, it becomes unfriendly to other flows and is more > likely > > to overrun intermediate queues. > > > > This patch limits the amount of data in flight. It came from BICTCP 1.1 > but it > > has been generalized to all TCP congestion algorithms. It has had some > testing, > > but needs to be more widely tested. > > Both the New Reno and Westwood+ algorithms implement rate-halving to > solve this problem. > > Why can't BICTCP use that instead of this special burst control hack? > > > From herbert@gondor.apana.org.au Wed Jul 28 04:46:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 04:47:09 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SBkn2b028679 for ; Wed, 28 Jul 2004 04:46:50 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BpmtG-0003wg-00; Wed, 28 Jul 2004 21:46:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BpmtE-0001tU-00; Wed, 28 Jul 2004 21:46:32 +1000 Date: Wed, 28 Jul 2004 21:46:32 +1000 To: "David S. Miller" Cc: kazunori@miyazawa.org, netdev@oss.sgi.com Subject: Re: [AH6] Disallow mutable bits after AH header Message-ID: <20040728114632.GA7103@gondor.apana.org.au> References: <20040723135320.GA26000@gondor.apana.org.au> <20040723133737.447a9598.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20040723133737.447a9598.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 23, 2004 at 01:37:37PM -0700, David S. Miller wrote: > On Fri, 23 Jul 2004 23:53:21 +1000 > Herbert Xu wrote: > > > As we discussed before, mutable headers should not be allowed after > > the AH header. In fact, this appears to be the intention of RFC 2402. > > It is further clarified in section 3.1.1 of > > Applied, thanks Herbert. Unfortunately I broke ah6_input() in that patch. Thanks to Miyazawa-san for notifying me of the problem. In that patch I removed the nh_offset parameter to ipv6_clear_mutable_options. That broke ah6_input() because it relies on that variable to set the nexthdr. The following patch fixes this by moving this work out to the caller xfrm6_rcv() where the information is already available. It also removes an unnecessary call to ip6_find_1stfragopt() in xfrm6_rcv() since nhoffp already points to the nexthdr preceding the current header. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=r ===== net/ipv6/ah6.c 1.36 vs edited ===== --- 1.36/net/ipv6/ah6.c 2004-07-25 20:33:46 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-28 19:36:35 +10:00 @@ -252,9 +252,7 @@ unsigned char *tmp_hdr = NULL; u16 hdr_len; u16 ah_hlen; - u16 nh_offset = 0; - u8 nexthdr = 0; - u8 *prevhdr; + int nexthdr; if (!pskb_may_pull(skb, sizeof(struct ip_auth_hdr))) goto out; @@ -307,8 +305,6 @@ skb->nh.raw = skb_pull(skb, ah_hlen); memcpy(skb->nh.raw, tmp_hdr, hdr_len); - prevhdr = (u8*)(skb->nh.raw + nh_offset); - *prevhdr = nexthdr; skb->nh.ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); skb_pull(skb, hdr_len); skb->h.raw = skb->data; ===== net/ipv6/esp6.c 1.31 vs edited ===== --- 1.31/net/ipv6/esp6.c 2004-07-25 20:33:46 +10:00 +++ edited/net/ipv6/esp6.c 2004-07-28 19:35:13 +10:00 @@ -197,7 +197,6 @@ u8 nexthdr[2]; struct scatterlist *sg = &esp->sgbuf[0]; u8 padlen; - u8 *prevhdr; if (unlikely(nfrags > ESP_NUM_FAST_SG)) { sg = kmalloc(sizeof(struct scatterlist)*nfrags, GFP_ATOMIC); @@ -228,8 +227,7 @@ skb->nh.raw += sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen; memcpy(skb->nh.raw, tmp_hdr, hdr_len); skb->nh.ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); - ip6_find_1stfragopt(skb, &prevhdr); - ret = *prevhdr = nexthdr[1]; + ret = nexthdr[1]; } out: ===== net/ipv6/ipcomp6.c 1.16 vs edited ===== --- 1.16/net/ipv6/ipcomp6.c 2004-07-25 20:33:46 +10:00 +++ edited/net/ipv6/ipcomp6.c 2004-07-28 19:37:00 +10:00 @@ -49,7 +49,6 @@ { int err = 0; u8 nexthdr = 0; - u8 *prevhdr; int hdr_len = skb->h.raw - skb->nh.raw; unsigned char *tmp_hdr = NULL; struct ipv6hdr *iph; @@ -106,8 +105,6 @@ iph = skb->nh.ipv6h; iph->payload_len = htons(skb->len); - ip6_find_1stfragopt(skb, &prevhdr); - *prevhdr = nexthdr; out: if (tmp_hdr) kfree(tmp_hdr); ===== net/ipv6/xfrm6_input.c 1.15 vs edited ===== --- 1.15/net/ipv6/xfrm6_input.c 2004-02-14 18:06:45 +11:00 +++ edited/net/ipv6/xfrm6_input.c 2004-07-28 19:42:26 +10:00 @@ -34,12 +34,11 @@ struct xfrm_state *x; int xfrm_nr = 0; int decaps = 0; - int nexthdr = 0; - u8 *prevhdr = NULL; + int nexthdr; + unsigned int nhoff; - ip6_find_1stfragopt(skb, &prevhdr); - nexthdr = *prevhdr; - *nhoffp = prevhdr - skb->nh.raw; + nhoff = *nhoffp; + nexthdr = skb->nh.raw[nhoff]; if ((err = xfrm_parse_spi(skb, nexthdr, &spi, &seq)) != 0) goto drop; @@ -66,6 +65,8 @@ nexthdr = x->type->input(x, &(xfrm_vec[xfrm_nr].decap), skb); if (nexthdr <= 0) goto drop_unlock; + + skb->nh.raw[nhoff] = nexthdr; if (x->props.replay_window) xfrm_replay_advance(x, seq); --82I3+IH0IqGh5yIs-- From herbert@gondor.apana.org.au Wed Jul 28 05:16:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 05:16:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SCGQml029546 for ; Wed, 28 Jul 2004 05:16:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BpnLI-00045Y-00; Wed, 28 Jul 2004 22:15:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BpnLC-00023S-00; Wed, 28 Jul 2004 22:15:26 +1000 Date: Wed, 28 Jul 2004 22:15:26 +1000 To: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com, YOSHIFUJI Hideaki , Kazunori Miyazawa Subject: Re: [IPSEC] Move generic encap code into xfrm6_output Message-ID: <20040728121526.GA7791@gondor.apana.org.au> References: <20040725104028.GA24547@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20040725104028.GA24547@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 25, 2004 at 08:40:28PM +1000, herbert wrote: > > Here is the IPv6 version of the generic tunnel encapsulation code. > > It is amazing to see how similar the IPv6 transform code is to its > IPv4 counterpart (except for AH) once the tunnel encapsulation code > is gone. Maybe we can merge them one day. That version is buggy. It breaks both AH and transport mode. Here is an incremental patch showing the fixes as well as the corrected patch in its entirety. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=incremental ===== net/ipv6/ah6.c 1.37 vs edited ===== --- 1.37/net/ipv6/ah6.c 2004-07-28 21:48:18 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-28 21:55:21 +10:00 @@ -202,11 +202,11 @@ ah = (struct ip_auth_hdr *)(*pskb)->h.raw; ah->nexthdr = nexthdr; - (*pskb)->nh.ipv6h->priority = 0; - (*pskb)->nh.ipv6h->flow_lbl[0] = 0; - (*pskb)->nh.ipv6h->flow_lbl[1] = 0; - (*pskb)->nh.ipv6h->flow_lbl[2] = 0; - (*pskb)->nh.ipv6h->hop_limit = 0; + top_iph->priority = 0; + top_iph->flow_lbl[0] = 0; + top_iph->flow_lbl[1] = 0; + top_iph->flow_lbl[2] = 0; + top_iph->hop_limit = 0; ahp = x->data; ah->hdrlen = (XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + ===== net/ipv6/xfrm6_output.c 1.1 vs edited ===== --- 1.1/net/ipv6/xfrm6_output.c 2004-07-25 20:33:46 +10:00 +++ edited/net/ipv6/xfrm6_output.c 2004-07-28 20:58:15 +10:00 @@ -43,9 +43,8 @@ int hdr_len; hdr_len = ip6_find_1stfragopt(skb, &prevhdr); - skb->nh.raw = prevhdr - hdr_len; - skb->h.ipv6h = iph; - skb->h.raw += hdr_len; + skb->nh.raw = prevhdr - x->props.header_len; + skb->h.raw = skb->data + hdr_len; memmove(skb->data, iph, hdr_len); return; } --a8Wt8u1KmwUX3Y2C Content-Type: text/x-pascal; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/Makefile 1.17 vs edited ===== --- 1.17/net/ipv6/Makefile 2004-06-18 15:25:06 +10:00 +++ edited/net/ipv6/Makefile 2004-07-28 22:10:28 +10:00 @@ -11,7 +11,7 @@ ip6_flowlabel.o ipv6_syms.o ipv6-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o xfrm6_input.o \ - xfrm6_tunnel.o + xfrm6_tunnel.o xfrm6_output.o ipv6-objs += $(ipv6-y) obj-$(CONFIG_INET6_AH) += ah6.o ===== net/ipv6/ah6.c 1.34 vs edited ===== --- 1.34/net/ipv6/ah6.c 2004-07-25 15:26:11 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-28 22:10:44 +10:00 @@ -118,70 +118,55 @@ int ah6_output(struct sk_buff **pskb) { int err; - int hdr_len = sizeof(struct ipv6hdr); + int extlen; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL; + struct ipv6hdr *top_iph; struct ip_auth_hdr *ah; struct ah_data *ahp; u8 nexthdr; - - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - iph = (*pskb)->nh.ipv6h; - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->nh.ipv6h->version = 6; - (*pskb)->nh.ipv6h->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.ipv6h->nexthdr = IPPROTO_AH; - ipv6_addr_copy(&(*pskb)->nh.ipv6h->saddr, - (struct in6_addr *) &x->props.saddr); - ipv6_addr_copy(&(*pskb)->nh.ipv6h->daddr, - (struct in6_addr *) &x->id.daddr); - ah = (struct ip_auth_hdr*)((*pskb)->nh.ipv6h+1); - ah->nexthdr = IPPROTO_IPV6; - } else { - u8 *prevhdr; - - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_AH; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { + char tmp_base[8]; + struct { + struct in6_addr daddr; + char hdrs[0]; + } *tmp_ext; + + top_iph = (struct ipv6hdr *)(*pskb)->data; + top_iph->payload_len = htons((*pskb)->len - sizeof(*top_iph)); + + nexthdr = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_AH; + + /* When there are no extension headers, we only need to save the first + * 8 bytes of the base IP header. + */ + memcpy(tmp_base, top_iph, sizeof(tmp_base)); + + tmp_ext = NULL; + extlen = (*pskb)->h.raw - (unsigned char *)(top_iph + 1); + if (extlen) { + extlen += sizeof(*tmp_ext); + tmp_ext = kmalloc(extlen, GFP_ATOMIC); + if (!tmp_ext) { err = -ENOMEM; goto error; } - memcpy(iph, (*pskb)->data, hdr_len); - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - err = ipv6_clear_mutable_options((*pskb)->nh.ipv6h, hdr_len); + memcpy(tmp_ext, &top_iph->daddr, extlen); + err = ipv6_clear_mutable_options(top_iph, + extlen - sizeof(*tmp_ext) + + sizeof(*top_iph)); if (err) goto error_free_iph; - - ah = (struct ip_auth_hdr*)((*pskb)->nh.raw+hdr_len); - (*pskb)->h.raw = (unsigned char*) ah; - ah->nexthdr = nexthdr; } - (*pskb)->nh.ipv6h->priority = 0; - (*pskb)->nh.ipv6h->flow_lbl[0] = 0; - (*pskb)->nh.ipv6h->flow_lbl[1] = 0; - (*pskb)->nh.ipv6h->flow_lbl[2] = 0; - (*pskb)->nh.ipv6h->hop_limit = 0; + ah = (struct ip_auth_hdr *)(*pskb)->h.raw; + ah->nexthdr = nexthdr; + + top_iph->priority = 0; + top_iph->flow_lbl[0] = 0; + top_iph->flow_lbl[1] = 0; + top_iph->flow_lbl[2] = 0; + top_iph->hop_limit = 0; ahp = x->data; ah->hdrlen = (XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + @@ -192,35 +177,16 @@ ah->seq_no = htonl(++x->replay.oseq); ahp->icv(ahp, *pskb, ah->auth_data); - if (x->props.mode) { - (*pskb)->nh.ipv6h->hop_limit = iph->hop_limit; - (*pskb)->nh.ipv6h->priority = iph->priority; - (*pskb)->nh.ipv6h->flow_lbl[0] = iph->flow_lbl[0]; - (*pskb)->nh.ipv6h->flow_lbl[1] = iph->flow_lbl[1]; - (*pskb)->nh.ipv6h->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear((*pskb)->nh.ipv6h); - } else { - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - kfree (iph); - } - - (*pskb)->nh.raw = (*pskb)->data; + err = 0; - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + memcpy(top_iph, tmp_base, sizeof(tmp_base)); + if (tmp_ext) { + memcpy(&top_iph->daddr, tmp_ext, extlen); error_free_iph: - kfree(iph); + kfree(tmp_ext); + } + error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } ===== net/ipv6/esp6.c 1.30 vs edited ===== --- 1.30/net/ipv6/esp6.c 2004-06-23 06:53:57 +10:00 +++ edited/net/ipv6/esp6.c 2004-07-28 22:10:28 +10:00 @@ -41,10 +41,10 @@ int esp6_output(struct sk_buff **pskb) { int err; - int hdr_len = 0; + int hdr_len; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL, *top_iph; + struct ipv6hdr *top_iph; struct ipv6_esp_hdr *esph; struct crypto_tfm *tfm; struct esp_data *esp; @@ -53,37 +53,13 @@ int clen; int alen; int nfrags; - u8 *prevhdr; - u8 nexthdr = 0; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; + esp = x->data; + hdr_len = (*pskb)->h.raw - (*pskb)->data + + sizeof(*esph) + esp->conf.ivlen; - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - } else { - /* Strip IP header in transport mode. Save it. */ - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_ESP; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { - err = -ENOMEM; - goto error; - } - memcpy(iph, (*pskb)->nh.raw, hdr_len); - __skb_pull(*pskb, hdr_len); - } + /* Strip IP+ESP header. */ + __skb_pull(*pskb, hdr_len); /* Now skb is pure payload to encrypt */ err = -ENOMEM; @@ -91,7 +67,6 @@ /* Round to block size */ clen = (*pskb)->len; - esp = x->data; alen = esp->auth.icv_trunc_len; tfm = esp->conf.tfm; blksize = (crypto_tfm_alg_blocksize(tfm) + 3) & ~3; @@ -100,7 +75,6 @@ clen = (clen + esp->conf.padlen-1)&~(esp->conf.padlen-1); if ((nfrags = skb_cow_data(*pskb, clen-(*pskb)->len+alen, &trailer)) < 0) { - if (!x->props.mode && iph) kfree(iph); goto error; } @@ -113,34 +87,11 @@ *(u8*)(trailer->tail + clen-(*pskb)->len - 2) = (clen - (*pskb)->len)-2; pskb_put(*pskb, trailer, clen - (*pskb)->len); - if (x->props.mode) { - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - esph = (struct ipv6_esp_hdr*)(top_iph+1); - *(u8*)(trailer->tail - 1) = IPPROTO_IPV6; - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear(top_iph); - top_iph->nexthdr = IPPROTO_ESP; - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - ipv6_addr_copy(&top_iph->saddr, - (struct in6_addr *)&x->props.saddr); - ipv6_addr_copy(&top_iph->daddr, - (struct in6_addr *)&x->id.daddr); - } else { - esph = (struct ipv6_esp_hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->h.raw = (unsigned char*)esph; - top_iph = (struct ipv6hdr*)skb_push(*pskb, hdr_len); - memcpy(top_iph, iph, hdr_len); - kfree(iph); - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - *(u8*)(trailer->tail - 1) = nexthdr; - } + top_iph = (struct ipv6hdr *)__skb_push(*pskb, hdr_len); + esph = (struct ipv6_esp_hdr *)(*pskb)->h.raw; + top_iph->payload_len = htons((*pskb)->len + alen - sizeof(*top_iph)); + *(u8*)(trailer->tail - 1) = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_ESP; esph->spi = x->id.spi; esph->seq_no = htonl(++x->replay.oseq); @@ -173,21 +124,9 @@ pskb_put(*pskb, trailer, alen); } - (*pskb)->nh.raw = (*pskb)->data; - - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + err = 0; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } ===== net/ipv6/ipcomp6.c 1.13 vs edited ===== --- 1.13/net/ipv6/ipcomp6.c 2004-07-23 05:14:21 +10:00 +++ edited/net/ipv6/ipcomp6.c 2004-07-28 22:10:28 +10:00 @@ -123,52 +123,14 @@ int err; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int hdr_len = 0; + struct ipv6hdr *top_iph; + int hdr_len; struct ipv6_comp_hdr *ipch; struct ipcomp_data *ipcd = x->data; - u8 *prevhdr; - u8 nexthdr = 0; int plen, dlen; u8 *start, *scratch = ipcd->scratch; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - hdr_len = sizeof(struct ipv6hdr); - nexthdr = IPPROTO_IPV6; - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr *)skb_push(*pskb, sizeof(struct ipv6hdr)); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; /* initial */ - top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - (*pskb)->nh.raw = (*pskb)->data; /* == top_iph */ - (*pskb)->h.raw = (*pskb)->nh.raw + hdr_len; - } else { - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - } + hdr_len = (*pskb)->h.raw - (*pskb)->data; /* check whether datagram len is larger than threshold */ if (((*pskb)->len - hdr_len) < ipcd->threshold) { @@ -184,7 +146,7 @@ /* compression */ plen = (*pskb)->len - hdr_len; dlen = IPCOMP_SCRATCH_SIZE; - start = (*pskb)->data + hdr_len; + start = (*pskb)->h.raw; err = crypto_comp_compress(ipcd->tfm, start, plen, scratch, &dlen); if (err) { @@ -197,39 +159,21 @@ pskb_trim(*pskb, hdr_len + dlen + sizeof(struct ip_comp_hdr)); /* insert ipcomp header and replace datagram */ - top_iph = (*pskb)->nh.ipv6h; + top_iph = (struct ipv6hdr *)(*pskb)->data; - if (x->props.mode && (x->props.flags & XFRM_STATE_NOECN)) - IP6_ECN_clear(top_iph); top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.raw = (*pskb)->data; /* top_iph */ - ip6_find_1stfragopt(*pskb, &prevhdr); - *prevhdr = IPPROTO_COMP; - ipch = (struct ipv6_comp_hdr *)((unsigned char *)top_iph + hdr_len); - ipch->nexthdr = nexthdr; + ipch = (struct ipv6_comp_hdr *)start; + ipch->nexthdr = *(*pskb)->nh.raw; ipch->flags = 0; ipch->cpi = htons((u16 )ntohl(x->id.spi)); + *(*pskb)->nh.raw = IPPROTO_COMP; - (*pskb)->h.raw = (unsigned char*)ipch; out_ok: - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - err = NET_XMIT_BYPASS; + err = 0; -out_exit: - return err; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); - goto out_exit; + return err; } static void ipcomp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt, ===== net/ipv6/xfrm6_policy.c 1.19 vs edited ===== --- 1.19/net/ipv6/xfrm6_policy.c 2004-06-18 15:25:06 +10:00 +++ edited/net/ipv6/xfrm6_policy.c 2004-07-28 22:10:29 +10:00 @@ -157,7 +157,7 @@ /* Copy neighbour for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); dst_prev->input = rt->u.dst.input; - dst_prev->output = dst_prev->xfrm->type->output; + dst_prev->output = xfrm6_output; /* Sheit... I remember I did this right. Apparently, * it was magically lost, so this code needs audit */ x->u.rt6.rt6i_flags = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL); ===== net/ipv6/xfrm6_tunnel.c 1.2 vs edited ===== --- 1.2/net/ipv6/xfrm6_tunnel.c 2004-06-20 05:48:05 +10:00 +++ edited/net/ipv6/xfrm6_tunnel.c 2004-07-28 22:10:29 +10:00 @@ -365,46 +365,12 @@ static int xfrm6_tunnel_output(struct sk_buff **pskb) { struct sk_buff *skb = *pskb; - struct dst_entry *dst = skb->dst; - struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int err; + struct ipv6hdr *top_iph; - if ((err = xfrm6_tunnel_check_size(skb)) != 0) - goto error_nolock; - - iph = skb->nh.ipv6h; - - top_iph = (struct ipv6hdr *)skb_push(skb, x->props.header_len); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; + top_iph = (struct ipv6hdr *)skb->data; top_iph->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - skb->nh.raw = skb->data; - skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr); - - x->curlft.bytes += skb->len; - x->curlft.packets++; - - spin_unlock_bh(&x->lock); - - if ((skb->dst = dst_pop(dst)) == NULL) { - kfree_skb(skb); - err = -EHOSTUNREACH; - goto error_nolock; - } - - return NET_XMIT_BYPASS; -error_nolock: - kfree_skb(skb); - return err; + return 0; } static int xfrm6_tunnel_input(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb) --- /dev/null 2004-06-14 11:16:19.000000000 +1000 +++ linux-2.6/net/ipv6/xfrm6_output.c 2004-07-28 22:10:44.000000000 +1000 @@ -0,0 +1,122 @@ +/* + * xfrm6_output.c - Common IPsec encapsulation code for IPv6. + * Copyright (c) 2004 Herbert Xu + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include + +/* Add encapsulation header. + * + * In transport mode, the IP header and mutable extension headers will be moved + * forward to make space for the encapsulation header. + * + * In tunnel mode, the top IP header will be constructed per RFC 2401. + * The following fields in it shall be filled in by x->type->output: + * payload_len + * + * On exit, skb->h will be set to the start of the encapsulation header to be + * filled in by x->type->output and skb->nh will be set to the nextheader field + * of the extension header directly preceding the encapsulation header, or in + * its absence, that of the top IP header. The value of skb->data will always + * point to the top IP header. + */ +static void xfrm6_encap(struct sk_buff *skb) +{ + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + struct ipv6hdr *iph, *top_iph; + + skb_push(skb, x->props.header_len); + iph = skb->nh.ipv6h; + + if (!x->props.mode) { + u8 *prevhdr; + int hdr_len; + + hdr_len = ip6_find_1stfragopt(skb, &prevhdr); + skb->nh.raw = prevhdr - x->props.header_len; + skb->h.raw = skb->data + hdr_len; + memmove(skb->data, iph, hdr_len); + return; + } + + skb->nh.raw = skb->data; + top_iph = skb->nh.ipv6h; + skb->nh.raw = &top_iph->nexthdr; + skb->h.ipv6h = top_iph + 1; + + top_iph->version = 6; + top_iph->priority = iph->priority; + if (x->props.flags & XFRM_STATE_NOECN) + IP6_ECN_clear(top_iph); + top_iph->flow_lbl[0] = iph->flow_lbl[0]; + top_iph->flow_lbl[1] = iph->flow_lbl[1]; + top_iph->flow_lbl[2] = iph->flow_lbl[2]; + top_iph->nexthdr = IPPROTO_IPV6; + top_iph->hop_limit = iph->hop_limit; + ipv6_addr_copy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr); + ipv6_addr_copy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr); +} + +int xfrm6_output(struct sk_buff **pskb) +{ + struct sk_buff *skb = *pskb; + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + int err; + + if (skb->ip_summed == CHECKSUM_HW) { + err = skb_checksum_help(pskb, 0); + skb = *pskb; + if (err) + goto error_nolock; + } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; + + if (x->props.mode) { + err = xfrm6_tunnel_check_size(skb); + if (err) + goto error; + } + + xfrm6_encap(skb); + + err = x->type->output(pskb); + skb = *pskb; + if (err) + goto error; + + x->curlft.bytes += skb->len; + x->curlft.packets++; + + spin_unlock_bh(&x->lock); + + skb->nh.raw = skb->data; + + if (!(skb->dst = dst_pop(dst))) { + err = -EHOSTUNREACH; + goto error_nolock; + } + err = NET_XMIT_BYPASS; + +out_exit: + return err; +error: + spin_unlock_bh(&x->lock); +error_nolock: + kfree_skb(skb); + goto out_exit; +} --a8Wt8u1KmwUX3Y2C-- From ak@suse.de Wed Jul 28 06:26:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 06:26:55 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SDQdsn003079 for ; Wed, 28 Jul 2004 06:26:40 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C1DAF96B67A; Wed, 28 Jul 2004 15:25:59 +0200 (CEST) Date: Wed, 28 Jul 2004 15:25:59 +0200 From: Andi Kleen To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [PATCH] Fix ADMtek Comet on x86-64 Message-ID: <20040728132559.GB23406@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 7218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev This Tulip clone doesn't like an Cache Line setting over 8 words. This broke it on x86-64. Make it the same as on i386. Some testing if I didn't break other Tulips on x86-64 would be appreciated. -Andi diff -u linux/drivers/net/tulip/tulip_core.c-o linux/drivers/net/tulip/tulip_core.c --- linux/drivers/net/tulip/tulip_core.c-o 2004-04-06 13:12:12.000000000 +0200 +++ linux/drivers/net/tulip/tulip_core.c 2004-07-28 14:45:05.000000000 +0200 @@ -88,9 +88,9 @@ ToDo: Non-Intel setting could be better. */ -#if defined(__alpha__) || defined(__ia64__) || defined(__x86_64__) +#if defined(__alpha__) || defined(__ia64__) static int csr0 = 0x01A00000 | 0xE000; -#elif defined(__i386__) || defined(__powerpc__) +#elif defined(__i386__) || defined(__powerpc__) || defined(__x86_64__) static int csr0 = 0x01A00000 | 0x8000; #elif defined(__sparc__) || defined(__hppa__) /* The UltraSparc PCI controllers will disconnect at every 64-byte From lxu2@unity.ncsu.edu Wed Jul 28 06:41:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 06:42:16 -0700 (PDT) Received: from uni09mr.unity.ncsu.edu (uni09mr.unity.ncsu.edu [152.1.1.172]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SDfwT8003710 for ; Wed, 28 Jul 2004 06:41:58 -0700 Received: from nanegrc (old-computer.csc.ncsu.edu [152.14.51.140]) by uni09mr.unity.ncsu.edu (8.12.10/8.12.10/N.20040607.01) with SMTP id i6SDfk6J002885; Wed, 28 Jul 2004 09:41:47 -0400 (EDT) Message-ID: <007301c474a9$1bb665d0$8c330e98@nanegrc> From: "Lisong Xu" To: "Xiaoliang \(David\) Wei" , "Injong Rhee" , "'David S. Miller'" , "'Stephen Hemminger'" Cc: , , References: <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com> <013001c47488$12a03500$8900a8c0@weixl> Subject: Re: [RFC] TCP burst control Date: Wed, 28 Jul 2004 09:45:11 -0400 Organization: NC State University MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.7.27.108885 X-archive-position: 7219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lxu2@unity.ncsu.edu Precedence: bulk X-list: netdev Hi Xiaoliang: You are right that tcp_cwnd_application_limited() is designed to avoid a large sending rate when the connection resumes full sending speed after an idling period. But actually we have observed that tcp_cwnd_application_limited() is also triggered in non-idling cases, and interfere with our burst control algorithm, so we have modified tcp_cwnd_application_limited(). We understand that our current implementation is not a perfect solution, and we are working on a better one. Thank you! Lisong ----- Original Message ----- From: "Xiaoliang (David) Wei" To: "Injong Rhee" ; "'David S. Miller'" ; "'Stephen Hemminger'" Cc: ; ; Sent: Wednesday, July 28, 2004 5:48 AM Subject: Re: [RFC] TCP burst control > Hi Injong and other Gurus, > > I support this approach to decouple congestion control and burstiness > control. But I have a question for the patch code. > > My question is about the tcp_cwnd_application_limited() in tcp_input.c > (@@ -3823,8 +3828,13 @@ in the patch). > My understanding is that tcp_cwnd_application_limited() is to reduce the > cwnd, according to RFC 2861, to avoid a large sending rate when the > connection resumes full sending speed. The window reduction here is not to > reduce burstiness, but to reduce the cwnd (since the cwnd is not a good > congestion measure after the idling period). But the patch seems to take > this congestion window reduction as a burstiness reduction mechanism, too. I > guess we don't need to change the window reduction in this function? Please > correct me if I made any mistake. Thanks:) > > I copied the part of patch codes that I'm not sure: > ------------------------------------------------------------ > @@ -3823,8 +3828,13 @@ > /* Limited by application or receiver window. */ > u32 win_used = max(tp->snd_cwnd_used, 2U); > if (win_used < tp->snd_cwnd) { > + u32 limit = (tp->snd_cwnd + win_used) >> 1; > tp->snd_ssthresh = tcp_current_ssthresh(tp); > - tp->snd_cwnd = (tp->snd_cwnd + win_used) >> 1; > + if (sysctl_tcp_burst_moderation) > + tp->snd_cwnd = min(tp->snd_cwnd, > + max(tp->snd_ssthresh, limit)); > + else > + tp->snd_cwnd = limit; > } > tp->snd_cwnd_used = 0; > } > ------------------------------------------------------------ > > -David > > Xiaoliang (David) Wei Graduate Student in CS@Caltech > http://www.cs.caltech.edu/~weixl > ==================================================== > ----- Original Message ----- > From: "Injong Rhee" > To: "'David S. Miller'" ; "'Stephen Hemminger'" > > Cc: ; ; > Sent: Tuesday, July 06, 2004 5:09 PM > Subject: RE: [RFC] TCP burst control > > > > Hi David and Stephen, > > > > We tested this rate halving. In fact, rate having in fact degrades the > > performance quite a bit. We can send you more information about it. Our > test > > indicates that this feature introduces many timeouts (because of bursts), > > and also cause unnecessary cwnd backoff to reduce the transmission > > unjustifiably low -- so there are many (I will repeat, many) window and > > transmission oscillations during packet losses. We fix this problem > > completely using our own special burst control. It is very simple and easy > > technique to implement. If you need some data to back up our claims, I > will > > send you more. Once we implemented our burst control, we don't have any > > timeouts and not much fluctuation other than congestion control related. > > Currently with rate having, current Linux tcp stack is full of hacks that > in > > fact, hurt the performance of linux tcp (sorry to say this). Our burst > > control, in fact, simplifies a lot of that and makes sure cwnd to follow > > very closely to whatever congestion control algorithm is intended it to > > behave. The Linux Reno burst control in fact interferes with the original > > congestion control (in fact, it tries to do its own), and its performance > is > > very hard to predict. > > > > Hope this helps. > > > > Injong Rhee, Associate Professor > > North Carolina State University > > Raleigh, NC 27699 > > rhee@eos.ncsu.edu, http://www.csc.ncsu.edu/faculty/rhee > > > > > > -----Original Message----- > > From: David S. Miller [mailto:davem@redhat.com] > > Sent: Tuesday, July 06, 2004 7:05 PM > > To: Stephen Hemminger > > Cc: netdev@oss.sgi.com; rhee@ncsu.edu > > Subject: Re: [RFC] TCP burst control > > > > On Tue, 6 Jul 2004 15:58:58 -0700 > > Stephen Hemminger wrote: > > > > > When using advanced congestion control it is possible for TCP to decide > > that > > > it has a large window to fill with data right away. The problem is that > if > > TCP > > > creates long bursts, it becomes unfriendly to other flows and is more > > likely > > > to overrun intermediate queues. > > > > > > This patch limits the amount of data in flight. It came from BICTCP 1.1 > > but it > > > has been generalized to all TCP congestion algorithms. It has had some > > testing, > > > but needs to be more widely tested. > > > > Both the New Reno and Westwood+ algorithms implement rate-halving to > > solve this problem. > > > > Why can't BICTCP use that instead of this special burst control hack? > > > > > > > > From nakam@linux-ipv6.org Wed Jul 28 08:11:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 08:11:50 -0700 (PDT) Received: from mail206.noc.n-bone.net (mail2.noc.n-bone.net [138.243.50.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SFBWWW005717 for ; Wed, 28 Jul 2004 08:11:35 -0700 Received: from localhost (galaxy.linux-ipv6.org [203.178.140.10]) by mail206.noc.n-bone.net (NBONE-MTA) with ESMTP id 7C82AFAB; Thu, 29 Jul 2004 00:11:23 +0900 (JST) Date: Thu, 29 Jul 2004 00:10:58 +0900 From: Masahide Nakamura To: , netdev@oss.sgi.com Subject: [PATCH]Fix adding SA through netlink(xfrm_user) Message-Id: <20040729001058.48cd1791@localhost> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Hello, When adding IPsec SA with PF_KEY (pfkey_add()), xfrm_probe_algs() is called to make all algorithms valid. However, it is missing to call it with netlink (xfrm_user) case and it causes xfrm_aalg_get_byname() return NULL even if the name of algorithm seems to be correct. The patch fixes it and is against 2.6.7. Please apply it. Index: linux26/net/xfrm/xfrm_user.c =================================================================== RCS file: /cvsroot/usagi/usagi/kernel/linux26/net/xfrm/xfrm_user.c,v retrieving revision 1.1.1.13 diff -u -r1.1.1.13 xfrm_user.c --- linux26/net/xfrm/xfrm_user.c 3 Apr 2004 05:52:43 -0000 1.1.1.13 +++ linux26/net/xfrm/xfrm_user.c 28 Jul 2004 14:26:21 -0000 @@ -258,6 +258,8 @@ if (err) return err; + xfrm_probe_algs(); + x = xfrm_state_construct(p, (struct rtattr **) xfrma, &err); if (!x) return err; -- Masahide NAKAMURA From solt@dns.toxicfilms.tv Wed Jul 28 08:37:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 08:38:14 -0700 (PDT) Received: from dns.toxicfilms.tv (qmailr@dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SFbuXV009539 for ; Wed, 28 Jul 2004 08:37:57 -0700 Received: (qmail 2126 invoked by uid 1027); 28 Jul 2004 17:37:49 +0200 Received: from solt@dns.toxicfilms.tv by dns by uid 1026 with qmail-scanner-1.22 (1.823 (20040726) Clear:RC:0(150.254.37.14):SA:0(0.0/5.0):. Processed in 10.206416 secs); 28 Jul 2004 15:37:49 -0000 X-Qmail-Scanner-Mail-From: solt@dns.toxicfilms.tv via dns X-Qmail-Scanner-Rcpt-To: netdev@oss.sgi.com X-Qmail-Scanner: 1.22 (Clear:RC:0(150.254.37.14):SA:0(0.0/5.0):. Processed in 10.206416 secs) Received: from pysiak.ae.poznan.pl (solt@150.254.37.14) by 0 with AES256-SHA encrypted SMTP; 28 Jul 2004 17:37:39 +0200 Date: Wed, 28 Jul 2004 17:37:40 +0200 From: Maciej Soltysiak X-Mailer: SecureBat! Lite (v2.10.02) UNREG / CD5BF9353B3B7091 Reply-To: Maciej Soltysiak X-Priority: 3 (Normal) Message-ID: <754869571.20040728173740@dns.toxicfilms.tv> To: netdev@oss.sgi.com Subject: more on "tcp_window_scaling degrades performance" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev Hi, I was posting about problems with TCP lately. It might still be a problem with the kernel and not the firewall. I am having problems with machines on the same LAN. Here is what I do to reproduce (sometimes works, sometimes not) # ssh user@host.on.lan [login] # su - [su login] # iptraf [choosing detailed interface statistics on a busy interface] It shows the statistics nice, but after a few seconds it gets seriously lagged, even my keystrokes to exit work with a lag. It also happens eg. when removing a lot of files in midnight commander via ssh. FTP transfers also suffer I am not doing andy filtering or mangling on the way between the hosts. I have this behaviour with a 2.6.8-rc1 kernel and 2.6.7+ kernels and alos with 2.6.8-rc1 and 2.4.26 kernel. I suspect changes in 2.6.7-8 devel cycle to have changed something bad. I made a tcpdump -v (human readable) of the problematic connection: http://www.soltysiak.com/tcp_ws.txt It is a connection between 150.254.37.24 (2.6.8-rc1) and 150.254.36.4 (2.4.26) Same effects are seen between 150.254.37.24 and 150.254.37.3 so it is not a router issue. Follow what's below: 16:17:01.669931: logging on with ssh, typing commands, waiting for the problem to appear. Notice tcpdump's bad tcp checksums at the beginning! 16:17:19.195772: 2.6.8-rc1 kernel sends the first packet with a very small win and we have a problem. (is it SWS?) in the mean time i am trying to get out of iptraf and log out 16:17:40.372086: closing the connection, notice the tcp bad checksums again. 2.4.26 sysctls are as default 2.6.8 sysctls are as default except that: tcp_windows_scaling is 0 tcp_bic is 0 tcp_sack is 0 tcp_fack is 0 I tried to zero these options to fix the problem, although with these enabled the problems still exists. What would you suggest? Regards, Maciej From jmorris@redhat.com Wed Jul 28 08:41:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 08:42:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SFfnmq010242 for ; Wed, 28 Jul 2004 08:41:49 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6SFfZe1032410; Wed, 28 Jul 2004 11:41:35 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6SFfYa12296; Wed, 28 Jul 2004 11:41:34 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6SFfYc2017077; Wed, 28 Jul 2004 11:41:34 -0400 Date: Wed, 28 Jul 2004 11:41:33 -0400 (EDT) From: James Morris X-X-Sender: jmorris@dhcp83-76.boston.redhat.com To: Masahide Nakamura cc: "David S. Miller" , , Herbert Xu Subject: Re: [PATCH]Fix adding SA through netlink(xfrm_user) In-Reply-To: <20040729001058.48cd1791@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Jul 2004, Masahide Nakamura wrote: > Hello, > > When adding IPsec SA with PF_KEY (pfkey_add()), > xfrm_probe_algs() is called to make all algorithms valid. > However, it is missing to call it with netlink (xfrm_user) case and > it causes xfrm_aalg_get_byname() return NULL even if the name of > algorithm seems to be correct. Looks ok, but odd that this has not been picked up before. > > The patch fixes it and is against 2.6.7. Please apply it. > > Index: linux26/net/xfrm/xfrm_user.c > =================================================================== > RCS file: /cvsroot/usagi/usagi/kernel/linux26/net/xfrm/xfrm_user.c,v > retrieving revision 1.1.1.13 > diff -u -r1.1.1.13 xfrm_user.c > --- linux26/net/xfrm/xfrm_user.c 3 Apr 2004 05:52:43 -0000 1.1.1.13 > +++ linux26/net/xfrm/xfrm_user.c 28 Jul 2004 14:26:21 -0000 > @@ -258,6 +258,8 @@ > if (err) > return err; > > + xfrm_probe_algs(); > + > x = xfrm_state_construct(p, (struct rtattr **) xfrma, &err); > if (!x) > return err; > > > > -- James Morris From rmk+netdev=oss.sgi.com@arm.linux.org.uk Wed Jul 28 08:50:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 08:50:57 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SFodBs010889 for ; Wed, 28 Jul 2004 08:50:41 -0700 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.33) id 1BpqhG-0004hq-20; Wed, 28 Jul 2004 16:50:26 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.33) id 1BpqhE-0002Ed-TW; Wed, 28 Jul 2004 16:50:24 +0100 Date: Wed, 28 Jul 2004 16:50:24 +0100 From: Russell King To: "David S. Miller" Cc: jgarzik@pobox.com, shemminger@osdl.org, netdev@oss.sgi.com, greg@kroah.com Subject: Re: [Fwd: pcmcia ether drivers can't be unloaded] Message-ID: <20040728165024.A8475@flint.arm.linux.org.uk> References: <41068BEF.7010200@pobox.com> <20040727233614.B30782@flint.arm.linux.org.uk> <20040727171929.17858c7b.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040727171929.17858c7b.davem@redhat.com>; from davem@redhat.com on Tue, Jul 27, 2004 at 05:19:29PM -0700 X-archive-position: 7223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: netdev On Tue, Jul 27, 2004 at 05:19:29PM -0700, David S. Miller wrote: > I totally disagree. This is a bogus argument for two reasons: You may disagree, that is your option. However, facts are facts - this is how the PCMCIA layer currently works, and short of rewriting the whole damned thing it isn't going to change. Sorry. PS, I'm on holiday for the next week or so, so don't expect anything to happen, even if you rant and rave about it. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core From niranjan_cs2905@yahoo.com Wed Jul 28 08:56:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 08:56:23 -0700 (PDT) Received: from web53006.mail.yahoo.com (web53006.mail.yahoo.com [206.190.39.196]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6SFu5ih011462 for ; Wed, 28 Jul 2004 08:56:06 -0700 Message-ID: <20040728155557.38198.qmail@web53006.mail.yahoo.com> Received: from [128.119.85.178] by web53006.mail.yahoo.com via HTTP; Wed, 28 Jul 2004 08:55:57 PDT Date: Wed, 28 Jul 2004 08:55:57 -0700 (PDT) From: Niranjan Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 To: James Morris , Vladimir Kondratiev Cc: Matt Mackall , Niranjan , netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niranjan_cs2905@yahoo.com Precedence: bulk X-list: netdev Hi, I got the code working by including the encrypt() and decrypt() function inside the WLAN driver. Is there any better way to get the CrytoAPI code working from the driver or some other CryptoAPI implementation ? Warm Regards, -Niranjan --- James Morris wrote: > On Tue, 27 Jul 2004, Vladimir Kondratiev wrote: > > > > The crypto functions should be safe to use in > softirq context. > > It should be, but: > > > > struct crypto_tfm *crypto_alloc_tfm(const char > *name, u32 flags) > > { > > struct crypto_tfm *tfm = NULL; > > struct crypto_alg *alg; > > > > alg = crypto_alg_mod_lookup(name); > > if (alg == NULL) > > goto out; > > > > tfm = kmalloc(sizeof(*tfm) + > alg->cra_ctxsize, GFP_KERNEL); > > > > By crypto functions I meant encrypt() decrypt() etc, > not the allocation. > > > - James > -- > James Morris > > > > > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From davem@redhat.com Wed Jul 28 08:56:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 08:56:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SFuSiF011773 for ; Wed, 28 Jul 2004 08:56:28 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6SFuIe1005193; Wed, 28 Jul 2004 11:56:18 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6SFuIa17963; Wed, 28 Jul 2004 11:56:18 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6SFtbBW014066; Wed, 28 Jul 2004 11:55:37 -0400 Date: Wed, 28 Jul 2004 08:54:19 -0700 From: "David S. Miller" To: Russell King Cc: jgarzik@pobox.com, shemminger@osdl.org, netdev@oss.sgi.com, greg@kroah.com Subject: Re: [Fwd: pcmcia ether drivers can't be unloaded] Message-Id: <20040728085419.773c4d94.davem@redhat.com> In-Reply-To: <20040728165024.A8475@flint.arm.linux.org.uk> References: <41068BEF.7010200@pobox.com> <20040727233614.B30782@flint.arm.linux.org.uk> <20040727171929.17858c7b.davem@redhat.com> <20040728165024.A8475@flint.arm.linux.org.uk> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004 16:50:24 +0100 Russell King wrote: > On Tue, Jul 27, 2004 at 05:19:29PM -0700, David S. Miller wrote: > > I totally disagree. This is a bogus argument for two reasons: > > You may disagree, that is your option. However, facts are facts - > this is how the PCMCIA layer currently works, and short of rewriting > the whole damned thing it isn't going to change. Sorry. Stephen offered a solution, moving this stray refcount into a toplevel pcmcia bus type object. We are not constrained by how the PCMCIA layer currently works, just as we were not constrained a year ago by how the generic network device handling worked when it was totally broken in this area. We just fixed it instead of whining. From jmorris@redhat.com Wed Jul 28 09:10:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 09:11:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SGAoW8012830 for ; Wed, 28 Jul 2004 09:10:50 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6SGAje1009909; Wed, 28 Jul 2004 12:10:45 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6SGAja24150; Wed, 28 Jul 2004 12:10:45 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6SGAic2019367; Wed, 28 Jul 2004 12:10:45 -0400 Date: Wed, 28 Jul 2004 12:10:43 -0400 (EDT) From: James Morris X-X-Sender: jmorris@dhcp83-76.boston.redhat.com To: Niranjan cc: Vladimir Kondratiev , Matt Mackall , Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 In-Reply-To: <20040728155557.38198.qmail@web53006.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004, Niranjan wrote: > Hi, > I got the code working by including the encrypt() and > decrypt() function inside the WLAN driver. > Is there any better way to get the CrytoAPI code > working from the driver or some other CryptoAPI > implementation ? Where is the driver code? - James -- James Morris From davem@redhat.com Wed Jul 28 09:12:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 09:12:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SGC52P013158 for ; Wed, 28 Jul 2004 09:12:05 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6SGBpe1010274; Wed, 28 Jul 2004 12:11:51 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6SGBoa24604; Wed, 28 Jul 2004 12:11:50 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6SGBAfN026776; Wed, 28 Jul 2004 12:11:10 -0400 Date: Wed, 28 Jul 2004 09:09:52 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, carnil@cs.tut.fi Subject: Re: [PATCH][ATM]: [lec] remove unnecessary inlines (from Adrian Bunk ) Message-Id: <20040728090952.1001aea6.davem@redhat.com> In-Reply-To: <200407280041.i6S0fcMe010687@ginger.cmf.nrl.navy.mil> References: <200407280041.i6S0fcMe010687@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 27 Jul 2004 20:41:39 -0400 "chas williams (contractor)" wrote: > please apply to 2.6 -- thanks! Applied, thanks Chas. From davem@redhat.com Wed Jul 28 09:14:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 09:14:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SGE3I4013487 for ; Wed, 28 Jul 2004 09:14:06 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6SGDle1010758; Wed, 28 Jul 2004 12:13:47 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6SGDla25279; Wed, 28 Jul 2004 12:13:47 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6SGD6MA028581; Wed, 28 Jul 2004 12:13:07 -0400 Date: Wed, 28 Jul 2004 09:11:48 -0700 From: "David S. Miller" To: Herbert Xu Cc: kazunori@miyazawa.org, netdev@oss.sgi.com Subject: Re: [AH6] Disallow mutable bits after AH header Message-Id: <20040728091148.63defec2.davem@redhat.com> In-Reply-To: <20040728114632.GA7103@gondor.apana.org.au> References: <20040723135320.GA26000@gondor.apana.org.au> <20040723133737.447a9598.davem@redhat.com> <20040728114632.GA7103@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004 21:46:32 +1000 Herbert Xu wrote: > In that patch I removed the nh_offset parameter to ipv6_clear_mutable_options. > That broke ah6_input() because it relies on that variable to set the nexthdr. > > The following patch fixes this by moving this work out to the caller > xfrm6_rcv() where the information is already available. It also removes > an unnecessary call to ip6_find_1stfragopt() in xfrm6_rcv() since nhoffp > already points to the nexthdr preceding the current header. Applied, thanks. From niranjan_cs2905@yahoo.com Wed Jul 28 09:30:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 09:30:53 -0700 (PDT) Received: from web53001.mail.yahoo.com (web53001.mail.yahoo.com [206.190.39.191]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6SGUbEC014152 for ; Wed, 28 Jul 2004 09:30:38 -0700 Message-ID: <20040728163029.55069.qmail@web53001.mail.yahoo.com> Received: from [128.119.85.178] by web53001.mail.yahoo.com via HTTP; Wed, 28 Jul 2004 09:30:29 PDT Date: Wed, 28 Jul 2004 09:30:29 -0700 (PDT) From: Niranjan Subject: Re: kernel bug at sched.c:564! + linux kernel 2.4.25 To: James Morris Cc: Vladimir Kondratiev , Matt Mackall , netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niranjan_cs2905@yahoo.com Precedence: bulk X-list: netdev The driver code is in kernel loadable module. The linux-wlan-ng driver for the linux wireless cards has two kernel loadable modules - prism2_cs and p80211. I included the encrypt() and decrypt() function of cryptoapi inside the p80211.o kernel module instead of using cipher-.o module for encryption and decryption. The cipher context (cipher name and cipher mode) and key (key length and cipher key) is still set through cryptoapi.o module. Warm Regards, -Niranjan --- James Morris wrote: > On Wed, 28 Jul 2004, Niranjan wrote: > > > Hi, > > I got the code working by including the encrypt() > and > > decrypt() function inside the WLAN driver. > > Is there any better way to get the CrytoAPI code > > working from the driver or some other CryptoAPI > > implementation ? > > Where is the driver code? > > > - James > -- > James Morris > > > > > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From jgarzik@pobox.com Wed Jul 28 10:08:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 10:08:46 -0700 (PDT) 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 i6SH8UpJ015463 for ; Wed, 28 Jul 2004 10:08:31 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bpruk-0000tr-K6; Wed, 28 Jul 2004 18:08:26 +0100 Message-ID: <4107DD7E.9020101@pobox.com> Date: Wed, 28 Jul 2004 13:08:14 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kalev Lember CC: netdev@oss.sgi.com, manfred@colorfullife.com Subject: Re: [PATCH] natsemi netpoll support References: <41052937.5010101@smartlink.ee> <410697F8.2050205@pobox.com> <41069D70.9030207@smartlink.ee> In-Reply-To: <41069D70.9030207@smartlink.ee> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Wed Jul 28 10:11:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 10:11:27 -0700 (PDT) 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 i6SHBAcX015911 for ; Wed, 28 Jul 2004 10:11:10 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BprxH-0000vZ-SW; Wed, 28 Jul 2004 18:11:04 +0100 Message-ID: <4107DE1C.1060008@pobox.com> Date: Wed, 28 Jul 2004 13:10:52 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH Linux-2.6.8-rc1] prism54 Clean up dev ids totally References: <200407272010.25762.margitsw@t-online.de> In-Reply-To: <200407272010.25762.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev I have applied this, but it will not go upstream (i.e. to Linus) until after Release Candidate series is over. The other four patches I acknowledged as applied are already in the upstream 2.6.x, and should be in the 2.6.8 release. Jeff From yoshfuji@linux-ipv6.org Wed Jul 28 10:16:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 10:16:48 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SHGVcP016295 for ; Wed, 28 Jul 2004 10:16:32 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 536CD33CE5; Thu, 29 Jul 2004 02:16:49 +0900 (JST) Date: Thu, 29 Jul 2004 02:16:43 +0900 (JST) Message-Id: <20040729.021643.25787950.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] [IPV6] Misc. Trivial Patches From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. Here's misc. patches. Also available at . Thanks. DIFFSTAT -------- include/linux/icmpv6.h | 32 +++++++++++++++++++++----------- include/net/addrconf.h | 4 ++-- net/ipv6/af_inet6.c | 2 -- net/ipv6/icmp.c | 6 ++++++ 4 files changed, 29 insertions(+), 15 deletions(-) CHANGESET --------- ChangeSet@1.1857, 2004-07-29 02:00:59+09:00, yoshfuji@linux-ipv6.org [IPV6] fix typoes in macro definitions. Signed-Off-By: Hideaki YOSHIFUJI diff -Nru a/include/net/addrconf.h b/include/net/addrconf.h --- a/include/net/addrconf.h 2004-07-29 02:08:20 +09:00 +++ b/include/net/addrconf.h 2004-07-29 02:08:20 +09:00 @@ -160,8 +160,8 @@ inet6_ifa_finish_destroy(ifp); } -#define __in6_ifa_put(idev) atomic_dec(&(idev)->refcnt) -#define in6_ifa_hold(idev) atomic_inc(&(idev)->refcnt) +#define __in6_ifa_put(ifp) atomic_dec(&(ifp)->refcnt) +#define in6_ifa_hold(ifp) atomic_inc(&(ifp)->refcnt) extern void addrconf_forwarding_on(void); ChangeSet@1.1858, 2004-07-29 02:02:25+09:00, yoshfuji@linux-ipv6.org [IPV6] remove unused macro. diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c 2004-07-29 02:08:23 +09:00 +++ b/net/ipv6/af_inet6.c 2004-07-29 02:08:23 +09:00 @@ -560,8 +560,6 @@ .flags = INET_PROTOSW_REUSE, }; -#define INETSW6_ARRAY_LEN (sizeof(inetsw6_array) / sizeof(struct inet_protosw)) - void inet6_register_protosw(struct inet_protosw *p) { ChangeSet@1.1859, 2004-07-29 02:04:10+09:00, yoshfuji@linux-ipv6.org [IPV6] fix the order of icmpv6 definitions for consistency. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/linux/icmpv6.h b/include/linux/icmpv6.h --- a/include/linux/icmpv6.h 2004-07-29 02:08:26 +09:00 +++ b/include/linux/icmpv6.h 2004-07-29 02:08:26 +09:00 @@ -85,18 +85,7 @@ #define ICMPV6_MGM_QUERY 130 #define ICMPV6_MGM_REPORT 131 #define ICMPV6_MGM_REDUCTION 132 - -/* definitions for MLDv2 */ - -#define MLD2_MODE_IS_INCLUDE 1 -#define MLD2_MODE_IS_EXCLUDE 2 -#define MLD2_CHANGE_TO_INCLUDE 3 -#define MLD2_CHANGE_TO_EXCLUDE 4 -#define MLD2_ALLOW_NEW_SOURCES 5 -#define MLD2_BLOCK_OLD_SOURCES 6 - #define ICMPV6_MLD2_REPORT 143 -#define MLD2_ALL_MCR_INIT { { { 0xff,0x02,0,0,0,0,0,0,0,0,0,0,0,0,0,0x16 } } } /* * Codes for Destination Unreachable @@ -138,6 +127,18 @@ struct icmp6_filter { __u32 data[8]; }; + +/* + * Definitions for MLDv2 + */ +#define MLD2_MODE_IS_INCLUDE 1 +#define MLD2_MODE_IS_EXCLUDE 2 +#define MLD2_CHANGE_TO_INCLUDE 3 +#define MLD2_CHANGE_TO_EXCLUDE 4 +#define MLD2_ALLOW_NEW_SOURCES 5 +#define MLD2_BLOCK_OLD_SOURCES 6 + +#define MLD2_ALL_MCR_INIT { { { 0xff,0x02,0,0,0,0,0,0,0,0,0,0,0,0,0,0x16 } } } #ifdef __KERNEL__ ChangeSet@1.1860, 2004-07-29 02:07:10+09:00, yoshfuji@linux-ipv6.org [IPV6] add missing known icmpv6 types. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/linux/icmpv6.h b/include/linux/icmpv6.h --- a/include/linux/icmpv6.h 2004-07-29 02:08:29 +09:00 +++ b/include/linux/icmpv6.h 2004-07-29 02:08:29 +09:00 @@ -85,7 +85,16 @@ #define ICMPV6_MGM_QUERY 130 #define ICMPV6_MGM_REPORT 131 #define ICMPV6_MGM_REDUCTION 132 + +#define ICMPV6_NI_QUERY 139 +#define ICMPV6_NI_REPLY 140 + #define ICMPV6_MLD2_REPORT 143 + +#define ICMPV6_DHAAD_REQUEST 144 +#define ICMPV6_DHAAD_REPLY 145 +#define ICMPV6_MOBILE_PREFIX_SOL 146 +#define ICMPV6_MOBILE_PREFIX_ADV 147 /* * Codes for Destination Unreachable diff -Nru a/net/ipv6/icmp.c b/net/ipv6/icmp.c --- a/net/ipv6/icmp.c 2004-07-29 02:08:29 +09:00 +++ b/net/ipv6/icmp.c 2004-07-29 02:08:29 +09:00 @@ -646,7 +646,13 @@ break; case ICMPV6_MGM_REDUCTION: + case ICMPV6_NI_QUERY: + case ICMPV6_NI_REPLY: case ICMPV6_MLD2_REPORT: + case ICMPV6_DHAAD_REQUEST: + case ICMPV6_DHAAD_REPLY: + case ICMPV6_MOBILE_PREFIX_SOL: + case ICMPV6_MOBILE_PREFIX_ADV: break; default: -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From Robert.Olsson@data.slu.se Wed Jul 28 11:36:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 11:36:19 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SIa30c018253 for ; Wed, 28 Jul 2004 11:36:04 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6SIZjIR001401; Wed, 28 Jul 2004 20:35:45 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 2F571EC33E; Wed, 28 Jul 2004 20:35:45 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16647.61953.158512.433946@robur.slu.se> Date: Wed, 28 Jul 2004 20:35:45 +0200 To: Pasi Sjoholm Cc: Robert Olsson , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <16646.47585.814327.628319@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Pasi Sjoholm writes: > On Tue, 27 Jul 2004, Robert Olsson wrote: > It would be nice that one could use the full capacity of his/her computer. > This is not a big problem for everyday use for a workstation but prevents > 2.6-series to be used in production-enviroments in the servers. > But hey.. we need to do some work and maybe we will resolve this. =) Well the 2.6 problem we ran into was due to the fact that RCU suffered from this userland starvation. I think Dipankar is pushing a patch for RCU this now. But it does not address userland starvation so if you your workload can give reproduceably results wrt starvation (Alexey's app) we can do some tests. First I think should be collect data from current system and check that results a reproduceable. Below is a patch to monitor softirq's it uses fastroute stats in softnet_stat you may have to hack it. And maybe we should take the experiment disussions off the list. Cheers. --ro --- kernel/softirq.c.orig 2004-03-11 03:55:24.000000000 +0100 +++ kernel/softirq.c 2004-03-31 18:15:26.000000000 +0200 @@ -69,7 +69,13 @@ */ #define MAX_SOFTIRQ_RESTART 10 -asmlinkage void do_softirq(void) + +/* Use the fastroute stats. */ + +#include +DECLARE_PER_CPU(struct netif_rx_stats, netdev_rx_stat); + +asmlinkage void do_softirq(int from) { int max_restart = MAX_SOFTIRQ_RESTART; __u32 pending; @@ -84,9 +90,44 @@ if (pending) { struct softirq_action *h; + struct task_struct *tsk = __get_cpu_var(ksoftirqd); local_bh_disable(); +#if 0 + /* Avoid softirq's from DoS'ing user apps incl. RCU's etc */ + + if (unlikely(from != SIRQ_FROM_KSOFTIRQD && + tsk && + sched_clock() - tsk->timestamp > + (unsigned long long) 2*1000000000 && + !(current->state & (TASK_DEAD | TASK_ZOMBIE)))) { + + set_tsk_need_resched(current); + local_irq_disable(); + goto done; + } +#endif + restart: + switch (from) { + + case SIRQ_FROM_BH: + __get_cpu_var(netdev_rx_stat).fastroute_hit++; + break; + + case SIRQ_FROM_KSOFTIRQD: + __get_cpu_var(netdev_rx_stat).fastroute_success++; + break; + + case SIRQ_FROM_IRQEXIT: + __get_cpu_var(netdev_rx_stat).fastroute_defer++; + break; + + + default: + __get_cpu_var(netdev_rx_stat).fastroute_deferred_out++; + + } /* Reset the pending bitmask before enabling irqs */ local_softirq_pending() = 0; @@ -106,6 +147,7 @@ pending = local_softirq_pending(); if (pending && --max_restart) goto restart; + done: if (pending) wakeup_softirqd(); __local_bh_enable(); @@ -122,7 +164,7 @@ WARN_ON(irqs_disabled()); if (unlikely(!in_interrupt() && local_softirq_pending())) - invoke_softirq(); + invoke_softirq(SIRQ_FROM_BH); preempt_check_resched(); } EXPORT_SYMBOL(local_bh_enable); @@ -324,7 +366,7 @@ __set_current_state(TASK_RUNNING); while (local_softirq_pending()) { - do_softirq(); + do_softirq(SIRQ_FROM_KSOFTIRQD); cond_resched(); } --- include/linux/netdevice.h~ 2004-03-11 03:55:44.000000000 +0100 +++ include/linux/netdevice.h 2004-03-31 12:24:57.000000000 +0200 @@ -669,7 +669,7 @@ { int err = netif_rx(skb); if (softirq_pending(smp_processor_id())) - do_softirq(); + do_softirq(SIRQ_FROM_NETIF_RX_NI); return err; } --- include/linux/interrupt.h.orig 2004-03-31 18:24:03.000000000 +0200 +++ include/linux/interrupt.h 2004-03-31 18:19:28.000000000 +0200 @@ -92,7 +92,17 @@ void *data; }; -asmlinkage void do_softirq(void); +/* Softirq originator */ +enum +{ + SIRQ_FROM_KSOFTIRQD=0, + SIRQ_FROM_IRQEXIT, + SIRQ_FROM_BH, + SIRQ_FROM_NETIF_RX_NI, + SIRQ_FROM_PKTGEN +}; + +asmlinkage void do_softirq(int from); extern void open_softirq(int nr, void (*action)(struct softirq_action*), void *data); extern void softirq_init(void); #define __raise_softirq_irqoff(nr) do { local_softirq_pending() |= 1UL << (nr); } while (0) @@ -100,7 +110,7 @@ extern void FASTCALL(raise_softirq(unsigned int nr)); #ifndef invoke_softirq -#define invoke_softirq() do_softirq() +#define invoke_softirq(from) do_softirq(from) #endif --- include/asm-i386/hardirq.h.orig 2004-03-11 03:55:37.000000000 +0100 +++ include/asm-i386/hardirq.h 2004-03-31 18:27:17.000000000 +0200 @@ -88,7 +88,7 @@ do { \ preempt_count() -= IRQ_EXIT_OFFSET; \ if (!in_interrupt() && softirq_pending(smp_processor_id())) \ - do_softirq(); \ + do_softirq(SIRQ_FROM_IRQEXIT); \ preempt_enable_no_resched(); \ } while (0) --- net/core/pktgen.c~ 2004-03-11 03:55:36.000000000 +0100 +++ net/core/pktgen.c 2004-03-31 12:24:57.000000000 +0200 @@ -710,7 +710,7 @@ if (need_resched()) schedule(); else - do_softirq(); + do_softirq(SIRQ_FROM_PKTGEN); } while (netif_queue_stopped(odev)); idle = cycles() - idle_start; info->idle_acc += idle; From shemminger@osdl.org Wed Jul 28 11:39:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 11:39:42 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SIdOdx018643 for ; Wed, 28 Jul 2004 11:39:25 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6SIdA119644; Wed, 28 Jul 2004 11:39:10 -0700 Date: Wed, 28 Jul 2004 11:39:10 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] ethertap module_param Message-Id: <20040728113910.3c7cab65@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Change ethertap to use module_param Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/ethertap.c b/drivers/net/ethertap.c --- a/drivers/net/ethertap.c 2004-07-23 13:29:32 -07:00 +++ b/drivers/net/ethertap.c 2004-07-23 13:29:32 -07:00 @@ -13,7 +13,7 @@ #include #include - +#include #include #include #include @@ -45,7 +45,7 @@ static int ethertap_debug; static int max_taps = 1; -MODULE_PARM(max_taps, "i"); +module_param(max_taps, int, 0); MODULE_PARM_DESC(max_taps,"Max number of ethernet tap devices"); static struct net_device **tap_map; /* Returns the tap device for a given netlink */ From shemminger@osdl.org Wed Jul 28 11:40:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 11:41:13 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SIetE3019037 for ; Wed, 28 Jul 2004 11:40:55 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6SIeb120025; Wed, 28 Jul 2004 11:40:37 -0700 Date: Wed, 28 Jul 2004 11:40:37 -0700 From: Stephen Hemminger To: "David S. Miller" , Robert Olsson Cc: netdev@oss.sgi.com Subject: [PATCH] convert pktgen to module_param Message-Id: <20040728114037.7bad51e2@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert packet generator to module_param Signed-off-by: Stephen Hemminger diff -Nru a/net/core/pktgen.c b/net/core/pktgen.c --- a/net/core/pktgen.c 2004-07-23 13:26:21 -07:00 +++ b/net/core/pktgen.c 2004-07-23 13:26:21 -07:00 @@ -56,6 +56,7 @@ */ #include +#include #include #include #include @@ -1409,7 +1410,7 @@ MODULE_AUTHOR("Robert Olsson ; Wed, 28 Jul 2004 12:09:34 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6SJ9Ee1027495; Wed, 28 Jul 2004 15:09:14 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6SJ9Ea23749; Wed, 28 Jul 2004 15:09:14 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6SJ9Ec2031830; Wed, 28 Jul 2004 15:09:14 -0400 Date: Wed, 28 Jul 2004 15:09:13 -0400 (EDT) From: James Morris X-X-Sender: jmorris@dhcp83-76.boston.redhat.com To: Robert Olsson cc: Pasi Sjoholm , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16647.61953.158512.433946@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004, Robert Olsson wrote: > And maybe we should take the experiment disussions off the list. This is what netdev is for :-) - James -- James Morris From manfred@colorfullife.com Wed Jul 28 13:23:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 13:23:21 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SKN1Zw028190 for ; Wed, 28 Jul 2004 13:23:02 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6SKMsuG018208 for ; Wed, 28 Jul 2004 22:22:56 +0200 Message-ID: <41080B83.7060707@colorfullife.com> Date: Wed, 28 Jul 2004 22:24:35 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: [PATCH] jumbo frame support for forcedeth, wol updates Content-Type: multipart/mixed; boundary="------------030408080100030105050308" X-archive-position: 7237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------030408080100030105050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, the attached patch adds jumbo frame support for the gigabit ethernet nForce nic. I've also found a critical bug that might affect all nForce nics: there is a race in nv_close, it seems the rx ring entries are kfreed while the nic is still active. At least ifdown with wol enabled is affected. I've tried to fix it, but the fix might have broken wol. Please test it - it works on my nForce-250Gb board. -- Manfred --------------030408080100030105050308 Content-Type: text/plain; name="patch-forcedeth-jumbo" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forcedeth-jumbo" // $Header$ // Kernel Version: // VERSION = 2 // PATCHLEVEL = 6 // SUBLEVEL = 8 // EXTRAVERSION =-rc1-mm1 --- 2.6/drivers/net/forcedeth.c 2004-07-19 22:00:27.000000000 +0200 +++ build-2.6/drivers/net/forcedeth.c 2004-07-28 21:37:51.684357344 +0200 @@ -75,6 +75,8 @@ * added CK804/MCP04 device IDs, code fixes * for registers, link status and other minor fixes. * 0.28: 21 Jun 2004: Big cleanup, making driver mostly endian safe + * 0.29: 28 Jul 2004: Add jumbo frame support. Add reset into nv_close, + * previous code clobbered kfree'd memory. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -86,7 +88,7 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.28" +#define FORCEDETH_VERSION "0.29" #define DRV_NAME "forcedeth" #include @@ -361,9 +363,13 @@ struct ring_desc { #define TX_LIMIT_START 62 /* rx/tx mac addr + type + vlan + align + slack*/ -#define RX_NIC_BUFSIZE (ETH_DATA_LEN + 64) -/* even more slack */ -#define RX_ALLOC_BUFSIZE (ETH_DATA_LEN + 128) +#define NV_RX_HEADERS (64) +/* even more slack. */ +#define NV_RX_ALLOC_PAD (64) + +/* maximum mtu size */ +#define NV_PKTLIMIT_1 ETH_DATA_LEN /* hard limit not known */ +#define NV_PKTLIMIT_2 9100 /* Actual limit according to NVidia: 9202 */ #define OOM_REFILL (1+HZ/20) #define POLL_WAIT (1+HZ/100) @@ -443,6 +449,7 @@ struct fe_priv { struct sk_buff *rx_skbuff[RX_RING]; dma_addr_t rx_dma[RX_RING]; unsigned int rx_buf_sz; + unsigned int pkt_limit; struct timer_list oom_kick; struct timer_list nic_poll; @@ -842,7 +849,7 @@ static int nv_alloc_rx(struct net_device nr = refill_rx % RX_RING; if (np->rx_skbuff[nr] == NULL) { - skb = dev_alloc_skb(RX_ALLOC_BUFSIZE); + skb = dev_alloc_skb(np->rx_buf_sz + NV_RX_ALLOC_PAD); if (!skb) break; @@ -855,7 +862,7 @@ static int nv_alloc_rx(struct net_device PCI_DMA_FROMDEVICE); np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]); wmb(); - np->rx_ring[nr].FlagLen = cpu_to_le32(RX_NIC_BUFSIZE | NV_RX_AVAIL); + np->rx_ring[nr].FlagLen = cpu_to_le32(np->rx_buf_sz | NV_RX_AVAIL); dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n", dev->name, refill_rx); refill_rx++; @@ -881,19 +888,31 @@ static void nv_do_rx_refill(unsigned lon enable_irq(dev->irq); } -static int nv_init_ring(struct net_device *dev) +static void nv_init_rx(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); int i; - np->next_tx = np->nic_tx = 0; - for (i = 0; i < TX_RING; i++) - np->tx_ring[i].FlagLen = 0; - np->cur_rx = RX_RING; np->refill_rx = 0; for (i = 0; i < RX_RING; i++) np->rx_ring[i].FlagLen = 0; +} + +static void nv_init_tx(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + int i; + + np->next_tx = np->nic_tx = 0; + for (i = 0; i < TX_RING; i++) + np->tx_ring[i].FlagLen = 0; +} + +static int nv_init_ring(struct net_device *dev) +{ + nv_init_tx(dev); + nv_init_rx(dev); return nv_alloc_rx(dev); } @@ -1191,15 +1210,82 @@ next_pkt: } } +static void set_bufsize(struct net_device *dev) +{ + struct fe_priv *np = netdev_priv(dev); + + if (dev->mtu <= ETH_DATA_LEN) + np->rx_buf_sz = ETH_DATA_LEN + NV_RX_HEADERS; + else + np->rx_buf_sz = dev->mtu + NV_RX_HEADERS; +} + /* * nv_change_mtu: dev->change_mtu function * Called with dev_base_lock held for read. */ static int nv_change_mtu(struct net_device *dev, int new_mtu) { - if (new_mtu > ETH_DATA_LEN) + struct fe_priv *np = get_nvpriv(dev); + int old_mtu; + + if (new_mtu < 64 || new_mtu > np->pkt_limit) return -EINVAL; + + old_mtu = dev->mtu; dev->mtu = new_mtu; + + /* return early if the buffer sizes will not change */ + if (old_mtu <= ETH_DATA_LEN && new_mtu <= ETH_DATA_LEN) + return 0; + if (old_mtu == new_mtu) + return 0; + + /* synchronized against open : rtnl_lock() held by caller */ + if (netif_running(dev)) { + u8 *base = get_hwbase(dev); + /* + * It seems that the nic preloads valid ring entries into an + * internal buffer. The procedure for flushing everything is + * guessed, there is probably a simpler approach. + * Changing the MTU is a rare event, it shouldn't matter. + */ + disable_irq(dev->irq); + spin_lock_bh(&dev->xmit_lock); + spin_lock(&np->lock); + /* stop engines */ + nv_stop_rx(dev); + nv_stop_tx(dev); + nv_txrx_reset(dev); + /* drain rx queue */ + nv_drain_rx(dev); + nv_drain_tx(dev); + /* reinit driver view of the rx queue */ + nv_init_rx(dev); + nv_init_tx(dev); + /* alloc new rx buffers */ + set_bufsize(dev); + if (nv_alloc_rx(dev)) { + if (!np->in_shutdown) + mod_timer(&np->oom_kick, jiffies + OOM_REFILL); + } + /* reinit nic view of the rx queue */ + writel(np->rx_buf_sz, base + NvRegOffloadConfig); + writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr); + writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr); + writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT), + base + NvRegRingSizes); + pci_push(base); + writel(NVREG_TXRXCTL_KICK|np->desc_ver, get_hwbase(dev) + NvRegTxRxControl); + pci_push(base); + + /* restart rx engine */ + nv_start_rx(dev); + nv_start_tx(dev); + spin_unlock(&np->lock); + spin_unlock_bh(&dev->xmit_lock); + enable_irq(dev->irq); + } return 0; } @@ -1519,6 +1605,7 @@ static int nv_open(struct net_device *de writel(0, base + NvRegAdapterControl); /* 2) initialize descriptor rings */ + set_bufsize(dev); oom = nv_init_ring(dev); writel(0, base + NvRegLinkSpeed); @@ -1567,7 +1654,7 @@ static int nv_open(struct net_device *de writel(NVREG_MISC1_FORCE | NVREG_MISC1_HD, base + NvRegMisc1); writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus); writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags); - writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig); + writel(np->rx_buf_sz, base + NvRegOffloadConfig); writel(readl(base + NvRegReceiverStatus), base + NvRegReceiverStatus); get_random_bytes(&i, sizeof(i)); @@ -1655,9 +1742,10 @@ static int nv_close(struct net_device *d spin_lock_irq(&np->lock); nv_stop_tx(dev); nv_stop_rx(dev); - base = get_hwbase(dev); + nv_txrx_reset(dev); /* disable interrupts on the nic or we will lock up */ + base = get_hwbase(dev); writel(0, base + NvRegIrqMask); pci_push(base); dprintk(KERN_INFO "%s: Irqmask is zero again\n", dev->name); @@ -1736,11 +1824,14 @@ static int __devinit nv_probe(struct pci /* handle different descriptor versions */ if (pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_1 || - pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 || - pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3) + pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 || + pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3) { np->desc_ver = DESC_VER_1; - else + np->pkt_limit = NV_PKTLIMIT_1; + } else { np->desc_ver = DESC_VER_2; + np->pkt_limit = NV_PKTLIMIT_2; + } err = -ENOMEM; dev->base_addr = (unsigned long) ioremap(addr, NV_PCI_REGSZ); --------------030408080100030105050308-- From herbert@gondor.apana.org.au Wed Jul 28 14:31:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 14:31:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SLVgL7030335 for ; Wed, 28 Jul 2004 14:31:43 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bpw1J-0000tp-00; Thu, 29 Jul 2004 07:31:29 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bpw1E-0002we-00; Thu, 29 Jul 2004 07:31:24 +1000 Date: Thu, 29 Jul 2004 07:31:24 +1000 To: "David S. Miller" Cc: Masahide Nakamura , James Morris , netdev@oss.sgi.com Subject: Re: Fw: Re: [PATCH]Fix adding SA through netlink(xfrm_user) Message-ID: <20040728213124.GA11280@gondor.apana.org.au> References: <20040728091224.4d577c47.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728091224.4d577c47.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Wed, Jul 28, 2004 at 09:12:24AM -0700, David S. Miller wrote: > > Indeed, this is mysterious. How come you never hit this, doesn't > superfreeswan use netlink XFRM purely these days? That's because it isn't purely netlink. It still relies on af_key to get the list of algorithms. BTW Superfreeswan is now known as Opeswan. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed Jul 28 14:39:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 14:40:15 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SLcWV4030777 for ; Wed, 28 Jul 2004 14:39:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bpw7n-0000xX-00; Thu, 29 Jul 2004 07:38:11 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bpw7l-0002y8-00; Thu, 29 Jul 2004 07:38:09 +1000 Date: Thu, 29 Jul 2004 07:38:09 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC] Move generic encap code into xfrm6_output Message-ID: <20040728213809.GC11280@gondor.apana.org.au> References: <20040725104028.GA24547@gondor.apana.org.au> <20040725.093617.15482200.yoshfuji@linux-ipv6.org> <20040725213122.GA30819@gondor.apana.org.au> <20040729.010159.77611229.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20040729.010159.77611229.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 29, 2004 at 01:01:59AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > diff -ru linux26-ipsectunnel/net/ipv6/xfrm6_output.c linux26-ipsectunnel.fix/net/ipv6/xfrm6_output.c > --- linux26-ipsectunnel/net/ipv6/xfrm6_output.c Thu Jul 29 00:35:07 2004 > +++ linux26-ipsectunnel.fix/net/ipv6/xfrm6_output.c Thu Jul 29 00:37:35 2004 > @@ -1,5 +1,6 @@ > /* > * xfrm6_output.c - Common IPsec encapsulation code for IPv6. > + * Copyright (C) 2002 USAGI/WIDE Project > * Copyright (c) 2004 Herbert Xu > * > * This program is free software; you can redistribute it and/or Great. I've included the updated patch here. > BTW, please consider followings when you send multiple patches. > (I was confused when I tried applying your patches.) I agree with your suggestions. > 2. It would not be so good to post incremental patch > if the the base change might introduce discussion. I presume you mean the incremental patch I posted in this thread. That was only meant to illustrate the bugs in the original patch. It was posted alongside with a complete patch. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/Makefile 1.17 vs edited ===== --- 1.17/net/ipv6/Makefile 2004-06-18 15:25:06 +10:00 +++ edited/net/ipv6/Makefile 2004-07-29 07:33:44 +10:00 @@ -11,7 +11,7 @@ ip6_flowlabel.o ipv6_syms.o ipv6-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o xfrm6_input.o \ - xfrm6_tunnel.o + xfrm6_tunnel.o xfrm6_output.o ipv6-objs += $(ipv6-y) obj-$(CONFIG_INET6_AH) += ah6.o ===== net/ipv6/ah6.c 1.34 vs edited ===== --- 1.34/net/ipv6/ah6.c 2004-07-25 15:26:11 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-29 07:33:44 +10:00 @@ -118,70 +118,55 @@ int ah6_output(struct sk_buff **pskb) { int err; - int hdr_len = sizeof(struct ipv6hdr); + int extlen; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL; + struct ipv6hdr *top_iph; struct ip_auth_hdr *ah; struct ah_data *ahp; u8 nexthdr; - - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - iph = (*pskb)->nh.ipv6h; - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->nh.ipv6h->version = 6; - (*pskb)->nh.ipv6h->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.ipv6h->nexthdr = IPPROTO_AH; - ipv6_addr_copy(&(*pskb)->nh.ipv6h->saddr, - (struct in6_addr *) &x->props.saddr); - ipv6_addr_copy(&(*pskb)->nh.ipv6h->daddr, - (struct in6_addr *) &x->id.daddr); - ah = (struct ip_auth_hdr*)((*pskb)->nh.ipv6h+1); - ah->nexthdr = IPPROTO_IPV6; - } else { - u8 *prevhdr; - - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_AH; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { + char tmp_base[8]; + struct { + struct in6_addr daddr; + char hdrs[0]; + } *tmp_ext; + + top_iph = (struct ipv6hdr *)(*pskb)->data; + top_iph->payload_len = htons((*pskb)->len - sizeof(*top_iph)); + + nexthdr = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_AH; + + /* When there are no extension headers, we only need to save the first + * 8 bytes of the base IP header. + */ + memcpy(tmp_base, top_iph, sizeof(tmp_base)); + + tmp_ext = NULL; + extlen = (*pskb)->h.raw - (unsigned char *)(top_iph + 1); + if (extlen) { + extlen += sizeof(*tmp_ext); + tmp_ext = kmalloc(extlen, GFP_ATOMIC); + if (!tmp_ext) { err = -ENOMEM; goto error; } - memcpy(iph, (*pskb)->data, hdr_len); - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - err = ipv6_clear_mutable_options((*pskb)->nh.ipv6h, hdr_len); + memcpy(tmp_ext, &top_iph->daddr, extlen); + err = ipv6_clear_mutable_options(top_iph, + extlen - sizeof(*tmp_ext) + + sizeof(*top_iph)); if (err) goto error_free_iph; - - ah = (struct ip_auth_hdr*)((*pskb)->nh.raw+hdr_len); - (*pskb)->h.raw = (unsigned char*) ah; - ah->nexthdr = nexthdr; } - (*pskb)->nh.ipv6h->priority = 0; - (*pskb)->nh.ipv6h->flow_lbl[0] = 0; - (*pskb)->nh.ipv6h->flow_lbl[1] = 0; - (*pskb)->nh.ipv6h->flow_lbl[2] = 0; - (*pskb)->nh.ipv6h->hop_limit = 0; + ah = (struct ip_auth_hdr *)(*pskb)->h.raw; + ah->nexthdr = nexthdr; + + top_iph->priority = 0; + top_iph->flow_lbl[0] = 0; + top_iph->flow_lbl[1] = 0; + top_iph->flow_lbl[2] = 0; + top_iph->hop_limit = 0; ahp = x->data; ah->hdrlen = (XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + @@ -192,35 +177,16 @@ ah->seq_no = htonl(++x->replay.oseq); ahp->icv(ahp, *pskb, ah->auth_data); - if (x->props.mode) { - (*pskb)->nh.ipv6h->hop_limit = iph->hop_limit; - (*pskb)->nh.ipv6h->priority = iph->priority; - (*pskb)->nh.ipv6h->flow_lbl[0] = iph->flow_lbl[0]; - (*pskb)->nh.ipv6h->flow_lbl[1] = iph->flow_lbl[1]; - (*pskb)->nh.ipv6h->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear((*pskb)->nh.ipv6h); - } else { - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - kfree (iph); - } - - (*pskb)->nh.raw = (*pskb)->data; + err = 0; - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + memcpy(top_iph, tmp_base, sizeof(tmp_base)); + if (tmp_ext) { + memcpy(&top_iph->daddr, tmp_ext, extlen); error_free_iph: - kfree(iph); + kfree(tmp_ext); + } + error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } ===== net/ipv6/esp6.c 1.30 vs edited ===== --- 1.30/net/ipv6/esp6.c 2004-06-23 06:53:57 +10:00 +++ edited/net/ipv6/esp6.c 2004-07-29 07:33:44 +10:00 @@ -41,10 +41,10 @@ int esp6_output(struct sk_buff **pskb) { int err; - int hdr_len = 0; + int hdr_len; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL, *top_iph; + struct ipv6hdr *top_iph; struct ipv6_esp_hdr *esph; struct crypto_tfm *tfm; struct esp_data *esp; @@ -53,37 +53,13 @@ int clen; int alen; int nfrags; - u8 *prevhdr; - u8 nexthdr = 0; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; + esp = x->data; + hdr_len = (*pskb)->h.raw - (*pskb)->data + + sizeof(*esph) + esp->conf.ivlen; - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - } else { - /* Strip IP header in transport mode. Save it. */ - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_ESP; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { - err = -ENOMEM; - goto error; - } - memcpy(iph, (*pskb)->nh.raw, hdr_len); - __skb_pull(*pskb, hdr_len); - } + /* Strip IP+ESP header. */ + __skb_pull(*pskb, hdr_len); /* Now skb is pure payload to encrypt */ err = -ENOMEM; @@ -91,7 +67,6 @@ /* Round to block size */ clen = (*pskb)->len; - esp = x->data; alen = esp->auth.icv_trunc_len; tfm = esp->conf.tfm; blksize = (crypto_tfm_alg_blocksize(tfm) + 3) & ~3; @@ -100,7 +75,6 @@ clen = (clen + esp->conf.padlen-1)&~(esp->conf.padlen-1); if ((nfrags = skb_cow_data(*pskb, clen-(*pskb)->len+alen, &trailer)) < 0) { - if (!x->props.mode && iph) kfree(iph); goto error; } @@ -113,34 +87,11 @@ *(u8*)(trailer->tail + clen-(*pskb)->len - 2) = (clen - (*pskb)->len)-2; pskb_put(*pskb, trailer, clen - (*pskb)->len); - if (x->props.mode) { - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - esph = (struct ipv6_esp_hdr*)(top_iph+1); - *(u8*)(trailer->tail - 1) = IPPROTO_IPV6; - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear(top_iph); - top_iph->nexthdr = IPPROTO_ESP; - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - ipv6_addr_copy(&top_iph->saddr, - (struct in6_addr *)&x->props.saddr); - ipv6_addr_copy(&top_iph->daddr, - (struct in6_addr *)&x->id.daddr); - } else { - esph = (struct ipv6_esp_hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->h.raw = (unsigned char*)esph; - top_iph = (struct ipv6hdr*)skb_push(*pskb, hdr_len); - memcpy(top_iph, iph, hdr_len); - kfree(iph); - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - *(u8*)(trailer->tail - 1) = nexthdr; - } + top_iph = (struct ipv6hdr *)__skb_push(*pskb, hdr_len); + esph = (struct ipv6_esp_hdr *)(*pskb)->h.raw; + top_iph->payload_len = htons((*pskb)->len + alen - sizeof(*top_iph)); + *(u8*)(trailer->tail - 1) = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_ESP; esph->spi = x->id.spi; esph->seq_no = htonl(++x->replay.oseq); @@ -173,21 +124,9 @@ pskb_put(*pskb, trailer, alen); } - (*pskb)->nh.raw = (*pskb)->data; - - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + err = 0; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } ===== net/ipv6/ipcomp6.c 1.13 vs edited ===== --- 1.13/net/ipv6/ipcomp6.c 2004-07-23 05:14:21 +10:00 +++ edited/net/ipv6/ipcomp6.c 2004-07-29 07:33:44 +10:00 @@ -123,52 +123,14 @@ int err; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int hdr_len = 0; + struct ipv6hdr *top_iph; + int hdr_len; struct ipv6_comp_hdr *ipch; struct ipcomp_data *ipcd = x->data; - u8 *prevhdr; - u8 nexthdr = 0; int plen, dlen; u8 *start, *scratch = ipcd->scratch; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - hdr_len = sizeof(struct ipv6hdr); - nexthdr = IPPROTO_IPV6; - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr *)skb_push(*pskb, sizeof(struct ipv6hdr)); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; /* initial */ - top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - (*pskb)->nh.raw = (*pskb)->data; /* == top_iph */ - (*pskb)->h.raw = (*pskb)->nh.raw + hdr_len; - } else { - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - } + hdr_len = (*pskb)->h.raw - (*pskb)->data; /* check whether datagram len is larger than threshold */ if (((*pskb)->len - hdr_len) < ipcd->threshold) { @@ -184,7 +146,7 @@ /* compression */ plen = (*pskb)->len - hdr_len; dlen = IPCOMP_SCRATCH_SIZE; - start = (*pskb)->data + hdr_len; + start = (*pskb)->h.raw; err = crypto_comp_compress(ipcd->tfm, start, plen, scratch, &dlen); if (err) { @@ -197,39 +159,21 @@ pskb_trim(*pskb, hdr_len + dlen + sizeof(struct ip_comp_hdr)); /* insert ipcomp header and replace datagram */ - top_iph = (*pskb)->nh.ipv6h; + top_iph = (struct ipv6hdr *)(*pskb)->data; - if (x->props.mode && (x->props.flags & XFRM_STATE_NOECN)) - IP6_ECN_clear(top_iph); top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.raw = (*pskb)->data; /* top_iph */ - ip6_find_1stfragopt(*pskb, &prevhdr); - *prevhdr = IPPROTO_COMP; - ipch = (struct ipv6_comp_hdr *)((unsigned char *)top_iph + hdr_len); - ipch->nexthdr = nexthdr; + ipch = (struct ipv6_comp_hdr *)start; + ipch->nexthdr = *(*pskb)->nh.raw; ipch->flags = 0; ipch->cpi = htons((u16 )ntohl(x->id.spi)); + *(*pskb)->nh.raw = IPPROTO_COMP; - (*pskb)->h.raw = (unsigned char*)ipch; out_ok: - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - err = NET_XMIT_BYPASS; + err = 0; -out_exit: - return err; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); - goto out_exit; + return err; } static void ipcomp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt, ===== net/ipv6/xfrm6_policy.c 1.19 vs edited ===== --- 1.19/net/ipv6/xfrm6_policy.c 2004-06-18 15:25:06 +10:00 +++ edited/net/ipv6/xfrm6_policy.c 2004-07-29 07:33:44 +10:00 @@ -157,7 +157,7 @@ /* Copy neighbour for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); dst_prev->input = rt->u.dst.input; - dst_prev->output = dst_prev->xfrm->type->output; + dst_prev->output = xfrm6_output; /* Sheit... I remember I did this right. Apparently, * it was magically lost, so this code needs audit */ x->u.rt6.rt6i_flags = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL); ===== net/ipv6/xfrm6_tunnel.c 1.2 vs edited ===== --- 1.2/net/ipv6/xfrm6_tunnel.c 2004-06-20 05:48:05 +10:00 +++ edited/net/ipv6/xfrm6_tunnel.c 2004-07-29 07:33:44 +10:00 @@ -365,46 +365,12 @@ static int xfrm6_tunnel_output(struct sk_buff **pskb) { struct sk_buff *skb = *pskb; - struct dst_entry *dst = skb->dst; - struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int err; + struct ipv6hdr *top_iph; - if ((err = xfrm6_tunnel_check_size(skb)) != 0) - goto error_nolock; - - iph = skb->nh.ipv6h; - - top_iph = (struct ipv6hdr *)skb_push(skb, x->props.header_len); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; + top_iph = (struct ipv6hdr *)skb->data; top_iph->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - skb->nh.raw = skb->data; - skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr); - - x->curlft.bytes += skb->len; - x->curlft.packets++; - - spin_unlock_bh(&x->lock); - - if ((skb->dst = dst_pop(dst)) == NULL) { - kfree_skb(skb); - err = -EHOSTUNREACH; - goto error_nolock; - } - - return NET_XMIT_BYPASS; -error_nolock: - kfree_skb(skb); - return err; + return 0; } static int xfrm6_tunnel_input(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb) --- /dev/null 2004-06-14 11:16:19.000000000 +1000 +++ linux-2.6/net/ipv6/xfrm6_output.c 2004-07-29 07:33:47.000000000 +1000 @@ -0,0 +1,123 @@ +/* + * xfrm6_output.c - Common IPsec encapsulation code for IPv6. + * Copyright (C) 2002 USAGI/WIDE Project + * Copyright (c) 2004 Herbert Xu + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include + +/* Add encapsulation header. + * + * In transport mode, the IP header and mutable extension headers will be moved + * forward to make space for the encapsulation header. + * + * In tunnel mode, the top IP header will be constructed per RFC 2401. + * The following fields in it shall be filled in by x->type->output: + * payload_len + * + * On exit, skb->h will be set to the start of the encapsulation header to be + * filled in by x->type->output and skb->nh will be set to the nextheader field + * of the extension header directly preceding the encapsulation header, or in + * its absence, that of the top IP header. The value of skb->data will always + * point to the top IP header. + */ +static void xfrm6_encap(struct sk_buff *skb) +{ + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + struct ipv6hdr *iph, *top_iph; + + skb_push(skb, x->props.header_len); + iph = skb->nh.ipv6h; + + if (!x->props.mode) { + u8 *prevhdr; + int hdr_len; + + hdr_len = ip6_find_1stfragopt(skb, &prevhdr); + skb->nh.raw = prevhdr - x->props.header_len; + skb->h.raw = skb->data + hdr_len; + memmove(skb->data, iph, hdr_len); + return; + } + + skb->nh.raw = skb->data; + top_iph = skb->nh.ipv6h; + skb->nh.raw = &top_iph->nexthdr; + skb->h.ipv6h = top_iph + 1; + + top_iph->version = 6; + top_iph->priority = iph->priority; + if (x->props.flags & XFRM_STATE_NOECN) + IP6_ECN_clear(top_iph); + top_iph->flow_lbl[0] = iph->flow_lbl[0]; + top_iph->flow_lbl[1] = iph->flow_lbl[1]; + top_iph->flow_lbl[2] = iph->flow_lbl[2]; + top_iph->nexthdr = IPPROTO_IPV6; + top_iph->hop_limit = iph->hop_limit; + ipv6_addr_copy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr); + ipv6_addr_copy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr); +} + +int xfrm6_output(struct sk_buff **pskb) +{ + struct sk_buff *skb = *pskb; + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + int err; + + if (skb->ip_summed == CHECKSUM_HW) { + err = skb_checksum_help(pskb, 0); + skb = *pskb; + if (err) + goto error_nolock; + } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; + + if (x->props.mode) { + err = xfrm6_tunnel_check_size(skb); + if (err) + goto error; + } + + xfrm6_encap(skb); + + err = x->type->output(pskb); + skb = *pskb; + if (err) + goto error; + + x->curlft.bytes += skb->len; + x->curlft.packets++; + + spin_unlock_bh(&x->lock); + + skb->nh.raw = skb->data; + + if (!(skb->dst = dst_pop(dst))) { + err = -EHOSTUNREACH; + goto error_nolock; + } + err = NET_XMIT_BYPASS; + +out_exit: + return err; +error: + spin_unlock_bh(&x->lock); +error_nolock: + kfree_skb(skb); + goto out_exit; +} --oyUTqETQ0mS9luUI-- From shemminger@osdl.org Wed Jul 28 15:38:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 15:38:50 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SMbgeo031826 for ; Wed, 28 Jul 2004 15:38:24 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6SMbP104759; Wed, 28 Jul 2004 15:37:25 -0700 Date: Wed, 28 Jul 2004 15:37:25 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH] (1/4) propgate bridge internal MTU changes Message-Id: <20040728153725.7ace281c@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Need to propagate MTU changes that the bridge does to it's pseudo interface up to others. There ends up being a double call to br_min_mtu() but that's harmless. Cleans up the EXPORT_SYMBOLS including dev_change_flags which is used by vlan. Shouldn't be basing exports on kernel config options like this. Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c 2004-07-28 15:33:20 -07:00 +++ b/net/bridge/br_if.c 2004-07-28 15:33:20 -07:00 @@ -295,6 +295,7 @@ return ret; } +/* Mtu of the bridge pseudo-device 1500 or the minimum of the ports */ int br_min_mtu(const struct net_bridge *br) { const struct net_bridge_port *p; @@ -347,7 +348,7 @@ br_stp_enable_port(p); spin_unlock_bh(&br->lock); - br->dev->mtu = br_min_mtu(br); + dev_set_mtu(br->dev, br_min_mtu(br)); } return err; diff -Nru a/net/bridge/br_notify.c b/net/bridge/br_notify.c --- a/net/bridge/br_notify.c 2004-07-28 15:33:20 -07:00 +++ b/net/bridge/br_notify.c 2004-07-28 15:33:20 -07:00 @@ -48,7 +48,7 @@ break; case NETDEV_CHANGEMTU: - br->dev->mtu = br_min_mtu(br); + dev_set_mtu(br->dev, br_min_mtu(br)); break; case NETDEV_DOWN: diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2004-07-28 15:33:20 -07:00 +++ b/net/core/dev.c 2004-07-28 15:33:20 -07:00 @@ -3426,6 +3426,8 @@ EXPORT_SYMBOL(dev_remove_pack); EXPORT_SYMBOL(dev_set_allmulti); EXPORT_SYMBOL(dev_set_promiscuity); +EXPORT_SYMBOL(dev_change_flags); +EXPORT_SYMBOL(dev_set_mtu); EXPORT_SYMBOL(free_netdev); EXPORT_SYMBOL(netdev_boot_setup_check); EXPORT_SYMBOL(netdev_set_master); @@ -3443,10 +3445,7 @@ #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) EXPORT_SYMBOL(br_handle_frame_hook); #endif -/* for 801q VLAN support */ -#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) -EXPORT_SYMBOL(dev_change_flags); -#endif + #ifdef CONFIG_KMOD EXPORT_SYMBOL(dev_load); #endif From shemminger@osdl.org Wed Jul 28 15:39:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 15:40:19 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SMdFdo031851 for ; Wed, 28 Jul 2004 15:39:44 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6SMcv105145; Wed, 28 Jul 2004 15:38:57 -0700 Date: Wed, 28 Jul 2004 15:38:57 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH] (2/4) bridge dev_xmit cleanup Message-Id: <20040728153857.70851b16@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The br_dev_xmit function was broken in two pieces (needlessly). Put it back together. Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c 2004-07-28 15:31:58 -07:00 +++ b/net/bridge/br_device.c 2004-07-28 15:31:58 -07:00 @@ -28,43 +28,29 @@ return &br->statistics; } -static int __br_dev_xmit(struct sk_buff *skb, struct net_device *dev) +int br_dev_xmit(struct sk_buff *skb, struct net_device *dev) { - struct net_bridge *br; - unsigned char *dest; + struct net_bridge *br = netdev_priv(dev); + const unsigned char *dest = skb->data; struct net_bridge_fdb_entry *dst; - br = dev->priv; br->statistics.tx_packets++; br->statistics.tx_bytes += skb->len; - dest = skb->mac.raw = skb->data; + skb->mac.raw = skb->data; skb_pull(skb, ETH_HLEN); - if (dest[0] & 1) { + rcu_read_lock(); + if (dest[0] & 1) br_flood_deliver(br, skb, 0); - return 0; - } - - if ((dst = br_fdb_get(br, dest)) != NULL) { + else if ((dst = br_fdb_get(br, dest)) != NULL) { br_deliver(dst->dst, skb); br_fdb_put(dst); - return 0; - } - - br_flood_deliver(br, skb, 0); - return 0; -} - -int br_dev_xmit(struct sk_buff *skb, struct net_device *dev) -{ - int ret; + } else + br_flood_deliver(br, skb, 0); - rcu_read_lock(); - ret = __br_dev_xmit(skb, dev); rcu_read_unlock(); - - return ret; + return 0; } static int br_dev_open(struct net_device *dev) From shemminger@osdl.org Wed Jul 28 16:25:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 16:25:38 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SNOdvh003697 for ; Wed, 28 Jul 2004 16:25:16 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6SNON116341; Wed, 28 Jul 2004 16:24:23 -0700 Date: Wed, 28 Jul 2004 16:24:23 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH] (4/4) bridge forwarding table RCU Message-Id: <20040728162423.6e4f8bb9@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert the bridge forwarding database over to using RCU. This avoids a read_lock and atomic_inc/dec in the fast path of output. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/list.h b/include/linux/list.h --- a/include/linux/list.h 2004-07-28 15:30:04 -07:00 +++ b/include/linux/list.h 2004-07-28 15:30:04 -07:00 @@ -678,6 +678,24 @@ pos && ({ n = pos->next; 1; }) && \ ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;}); \ pos = n) + +/** + * hlist_for_each_entry_rcu - iterate over rcu list of given type + * @pos: the type * to use as a loop counter. + * @pos: the &struct hlist_node to use as a loop counter. + * @head: the head for your list. + * @member: the name of the hlist_node within the struct. + * + * This list-traversal primitive may safely run concurrently with + * the _rcu list-mutation primitives such as hlist_add_rcu() + * as long as the traversal is guarded by rcu_read_lock(). + */ +#define hlist_for_each_entry_rcu(tpos, pos, head, member) \ + for (pos = (head)->first; \ + pos && ({ prefetch(pos->next); 1;}) && \ + ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;}); \ + pos = pos->next, ({ smp_read_barrier_depends(); 0; }) ) + #else #warning "don't include kernel headers in userspace" #endif /* __KERNEL__ */ diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_device.c 2004-07-28 15:30:04 -07:00 @@ -43,10 +43,9 @@ rcu_read_lock(); if (dest[0] & 1) br_flood_deliver(br, skb, 0); - else if ((dst = br_fdb_get(br, dest)) != NULL) { + else if ((dst = __br_fdb_get(br, dest)) != NULL) br_deliver(dst->dst, skb); - br_fdb_put(dst); - } else + else br_flood_deliver(br, skb, 0); rcu_read_unlock(); diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_fdb.c 2004-07-28 15:30:04 -07:00 @@ -73,7 +73,7 @@ static __inline__ void fdb_delete(struct net_bridge_fdb_entry *f) { - hlist_del(&f->hlist); + hlist_del_rcu(&f->hlist); if (!f->is_static) list_del(&f->age_list); @@ -85,7 +85,7 @@ struct net_bridge *br = p->br; int i; - write_lock_bh(&br->hash_lock); + spin_lock_bh(&br->hash_lock); /* Search all chains since old address/hash is unknown */ for (i = 0; i < BR_HASH_SIZE; i++) { @@ -117,7 +117,7 @@ fdb_insert(br, p, newaddr, 1); - write_unlock_bh(&br->hash_lock); + spin_unlock_bh(&br->hash_lock); } void br_fdb_cleanup(unsigned long _data) @@ -126,7 +126,7 @@ struct list_head *l, *n; unsigned long delay; - write_lock_bh(&br->hash_lock); + spin_lock_bh(&br->hash_lock); delay = hold_time(br); list_for_each_safe(l, n, &br->age_list) { @@ -144,14 +144,14 @@ break; } } - write_unlock_bh(&br->hash_lock); + spin_unlock_bh(&br->hash_lock); } void br_fdb_delete_by_port(struct net_bridge *br, struct net_bridge_port *p) { int i; - write_lock_bh(&br->hash_lock); + spin_lock_bh(&br->hash_lock); for (i = 0; i < BR_HASH_SIZE; i++) { struct hlist_node *h, *g; @@ -182,33 +182,42 @@ skip_delete: ; } } - write_unlock_bh(&br->hash_lock); + spin_unlock_bh(&br->hash_lock); } -struct net_bridge_fdb_entry *br_fdb_get(struct net_bridge *br, unsigned char *addr) +/* No locking or refcounting, assumes caller has no preempt (rcu_read_lock) */ +struct net_bridge_fdb_entry *__br_fdb_get(struct net_bridge *br, + const unsigned char *addr) { struct hlist_node *h; + struct net_bridge_fdb_entry *fdb; - read_lock_bh(&br->hash_lock); - - hlist_for_each(h, &br->hash[br_mac_hash(addr)]) { - struct net_bridge_fdb_entry *fdb - = hlist_entry(h, struct net_bridge_fdb_entry, hlist); - + hlist_for_each_entry_rcu(fdb, h, &br->hash[br_mac_hash(addr)], hlist) { if (!memcmp(fdb->addr.addr, addr, ETH_ALEN)) { - if (has_expired(br, fdb)) - goto ret_null; - - atomic_inc(&fdb->use_count); - read_unlock_bh(&br->hash_lock); + if (unlikely(has_expired(br, fdb))) + break; return fdb; } } - ret_null: - read_unlock_bh(&br->hash_lock); + return NULL; } +/* Interface used by ATM hook that keeps a ref count */ +struct net_bridge_fdb_entry *br_fdb_get(struct net_bridge *br, + unsigned char *addr) +{ + struct net_bridge_fdb_entry *fdb; + + rcu_read_lock(); + fdb = __br_fdb_get(br, addr); + if (fdb) + atomic_inc(&fdb->use_count); + rcu_read_unlock(); + return fdb; +} + + void br_fdb_put(struct net_bridge_fdb_entry *ent) { if (atomic_dec_and_test(&ent->use_count)) @@ -229,9 +238,9 @@ memset(buf, 0, maxnum*sizeof(struct __fdb_entry)); - read_lock_bh(&br->hash_lock); + rcu_read_lock(); for (i = 0; i < BR_HASH_SIZE; i++) { - hlist_for_each_entry(f, h, &br->hash[i], hlist) { + hlist_for_each_entry_rcu(f, h, &br->hash[i], hlist) { if (num >= maxnum) goto out; @@ -255,7 +264,7 @@ } out: - read_unlock_bh(&br->hash_lock); + rcu_read_unlock(); return num; } @@ -309,7 +318,7 @@ memcpy(fdb->addr.addr, addr, ETH_ALEN); atomic_set(&fdb->use_count, 1); - hlist_add_head(&fdb->hlist, &br->hash[hash]); + hlist_add_head_rcu(&fdb->hlist, &br->hash[hash]); if (!timer_pending(&br->gc_timer)) { br->gc_timer.expires = jiffies + hold_time(br); @@ -332,8 +341,8 @@ { int ret; - write_lock_bh(&br->hash_lock); + spin_lock_bh(&br->hash_lock); ret = fdb_insert(br, source, addr, is_local); - write_unlock_bh(&br->hash_lock); + spin_unlock_bh(&br->hash_lock); return ret; } diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_if.c 2004-07-28 15:30:04 -07:00 @@ -149,7 +149,7 @@ br->lock = SPIN_LOCK_UNLOCKED; INIT_LIST_HEAD(&br->port_list); - br->hash_lock = RW_LOCK_UNLOCKED; + br->hash_lock = SPIN_LOCK_UNLOCKED; br->bridge_id.prio[0] = 0x80; br->bridge_id.prio[1] = 0x00; diff -Nru a/net/bridge/br_input.c b/net/bridge/br_input.c --- a/net/bridge/br_input.c 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_input.c 2004-07-28 15:30:04 -07:00 @@ -83,19 +83,17 @@ goto out; } - dst = br_fdb_get(br, dest); + dst = __br_fdb_get(br, dest); if (dst != NULL && dst->is_local) { if (!passedup) br_pass_frame_up(br, skb); else kfree_skb(skb); - br_fdb_put(dst); goto out; } if (dst != NULL) { br_forward(dst->dst, skb); - br_fdb_put(dst); goto out; } diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_private.h 2004-07-28 15:30:04 -07:00 @@ -86,7 +86,7 @@ struct list_head port_list; struct net_device *dev; struct net_device_stats statistics; - rwlock_t hash_lock; + spinlock_t hash_lock; struct hlist_head hash[BR_HASH_SIZE]; struct list_head age_list; @@ -136,8 +136,10 @@ extern void br_fdb_cleanup(unsigned long arg); extern void br_fdb_delete_by_port(struct net_bridge *br, struct net_bridge_port *p); +extern struct net_bridge_fdb_entry *__br_fdb_get(struct net_bridge *br, + const unsigned char *addr); extern struct net_bridge_fdb_entry *br_fdb_get(struct net_bridge *br, - unsigned char *addr); + unsigned char *addr); extern void br_fdb_put(struct net_bridge_fdb_entry *ent); extern int br_fdb_fillbuf(struct net_bridge *br, void *buf, unsigned long count, unsigned long off); From shemminger@osdl.org Wed Jul 28 16:38:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 16:38:51 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SNabAW004121 for ; Wed, 28 Jul 2004 16:38:24 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6SNaM119203; Wed, 28 Jul 2004 16:36:22 -0700 Date: Wed, 28 Jul 2004 16:36:22 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] netem update for 2.4 Message-Id: <20040728163622.7a431e97@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This makes the netem code for 2.4 equivalent to the 2.6.8 stuff. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h --- a/include/linux/pkt_sched.h 2004-07-28 16:35:54 -07:00 +++ b/include/linux/pkt_sched.h 2004-07-28 16:35:54 -07:00 @@ -440,7 +440,7 @@ __u32 loss; /* random packet loss (0=none ~0=100%) */ __u32 gap; /* re-ordering gap (0 for delay all) */ __u32 duplicate; /* random packet dup (0=none ~0=100%) */ - __u32 rate; /* maximum transmit rate (bytes/sec) */ + __u32 jitter; /* random jitter in latency (us) */ }; #endif diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2004-07-28 16:35:54 -07:00 +++ b/net/sched/sch_netem.c 2004-07-28 16:35:54 -07:00 @@ -30,14 +30,16 @@ */ struct netem_sched_data { - struct sk_buff_head qnormal; - struct sk_buff_head qdelay; + struct Qdisc *qdisc; + struct sk_buff_head delayed; struct timer_list timer; u32 latency; u32 loss; + u32 limit; u32 counter; u32 gap; + u32 jitter; }; /* Time stamp put into socket buffer control block */ @@ -45,6 +47,558 @@ psched_time_t time_to_send; }; +/* This is the distribution table for the normal distribution produced + * with NISTnet tools. + * The entries represent a scaled inverse of the cumulative distribution + * function. + */ +#define TABLESIZE 2048 +#define TABLEFACTOR 8192 + +static const short disttable[TABLESIZE] = { + -31473, -26739, -25226, -24269, + -23560, -22993, -22518, -22109, + -21749, -21426, -21133, -20865, + -20618, -20389, -20174, -19972, + -19782, -19601, -19430, -19267, + -19112, -18962, -18819, -18681, + -18549, -18421, -18298, -18178, + -18062, -17950, -17841, -17735, + -17632, -17532, -17434, -17339, + -17245, -17155, -17066, -16979, + -16894, -16811, -16729, -16649, + -16571, -16494, -16419, -16345, + -16272, -16201, -16130, -16061, + -15993, -15926, -15861, -15796, + -15732, -15669, -15607, -15546, + -15486, -15426, -15368, -15310, + -15253, -15196, -15140, -15086, + -15031, -14977, -14925, -14872, + -14821, -14769, -14719, -14669, + -14619, -14570, -14522, -14473, + -14426, -14379, -14332, -14286, + -14241, -14196, -14150, -14106, + -14062, -14019, -13976, -13933, + -13890, -13848, -13807, -13765, + -13724, -13684, -13643, -13604, + -13564, -13525, -13486, -13447, + -13408, -13370, -13332, -13295, + -13258, -13221, -13184, -13147, + -13111, -13075, -13040, -13004, + -12969, -12934, -12899, -12865, + -12830, -12796, -12762, -12729, + -12695, -12662, -12629, -12596, + -12564, -12531, -12499, -12467, + -12435, -12404, -12372, -12341, + -12310, -12279, -12248, -12218, + -12187, -12157, -12127, -12097, + -12067, -12038, -12008, -11979, + -11950, -11921, -11892, -11863, + -11835, -11806, -11778, -11750, + -11722, -11694, -11666, -11639, + -11611, -11584, -11557, -11530, + -11503, -11476, -11450, -11423, + -11396, -11370, -11344, -11318, + -11292, -11266, -11240, -11214, + -11189, -11164, -11138, -11113, + -11088, -11063, -11038, -11013, + -10988, -10964, -10939, -10915, + -10891, -10866, -10843, -10818, + -10794, -10770, -10747, -10723, + -10700, -10676, -10652, -10630, + -10606, -10583, -10560, -10537, + -10514, -10491, -10469, -10446, + -10424, -10401, -10378, -10356, + -10334, -10312, -10290, -10267, + -10246, -10224, -10202, -10180, + -10158, -10137, -10115, -10094, + -10072, -10051, -10030, -10009, + -9988, -9967, -9945, -9925, + -9904, -9883, -9862, -9842, + -9821, -9800, -9780, -9760, + -9739, -9719, -9699, -9678, + -9658, -9638, -9618, -9599, + -9578, -9559, -9539, -9519, + -9499, -9480, -9461, -9441, + -9422, -9402, -9383, -9363, + -9344, -9325, -9306, -9287, + -9268, -9249, -9230, -9211, + -9192, -9173, -9155, -9136, + -9117, -9098, -9080, -9062, + -9043, -9025, -9006, -8988, + -8970, -8951, -8933, -8915, + -8897, -8879, -8861, -8843, + -8825, -8807, -8789, -8772, + -8754, -8736, -8718, -8701, + -8683, -8665, -8648, -8630, + -8613, -8595, -8578, -8561, + -8543, -8526, -8509, -8492, + -8475, -8458, -8441, -8423, + -8407, -8390, -8373, -8356, + -8339, -8322, -8305, -8289, + -8272, -8255, -8239, -8222, + -8206, -8189, -8172, -8156, + -8140, -8123, -8107, -8090, + -8074, -8058, -8042, -8025, + -8009, -7993, -7977, -7961, + -7945, -7929, -7913, -7897, + -7881, -7865, -7849, -7833, + -7817, -7802, -7786, -7770, + -7754, -7739, -7723, -7707, + -7692, -7676, -7661, -7645, + -7630, -7614, -7599, -7583, + -7568, -7553, -7537, -7522, + -7507, -7492, -7476, -7461, + -7446, -7431, -7416, -7401, + -7385, -7370, -7356, -7340, + -7325, -7311, -7296, -7281, + -7266, -7251, -7236, -7221, + -7207, -7192, -7177, -7162, + -7148, -7133, -7118, -7104, + -7089, -7075, -7060, -7046, + -7031, -7016, -7002, -6988, + -6973, -6959, -6944, -6930, + -6916, -6901, -6887, -6873, + -6859, -6844, -6830, -6816, + -6802, -6788, -6774, -6760, + -6746, -6731, -6717, -6704, + -6690, -6675, -6661, -6647, + -6633, -6620, -6606, -6592, + -6578, -6564, -6550, -6537, + -6523, -6509, -6495, -6482, + -6468, -6454, -6441, -6427, + -6413, -6400, -6386, -6373, + -6359, -6346, -6332, -6318, + -6305, -6291, -6278, -6264, + -6251, -6238, -6224, -6211, + -6198, -6184, -6171, -6158, + -6144, -6131, -6118, -6105, + -6091, -6078, -6065, -6052, + -6039, -6025, -6012, -5999, + -5986, -5973, -5960, -5947, + -5934, -5921, -5908, -5895, + -5882, -5869, -5856, -5843, + -5830, -5817, -5804, -5791, + -5779, -5766, -5753, -5740, + -5727, -5714, -5702, -5689, + -5676, -5663, -5650, -5638, + -5625, -5612, -5600, -5587, + -5575, -5562, -5549, -5537, + -5524, -5512, -5499, -5486, + -5474, -5461, -5449, -5436, + -5424, -5411, -5399, -5386, + -5374, -5362, -5349, -5337, + -5324, -5312, -5299, -5287, + -5275, -5263, -5250, -5238, + -5226, -5213, -5201, -5189, + -5177, -5164, -5152, -5140, + -5128, -5115, -5103, -5091, + -5079, -5067, -5055, -5043, + -5030, -5018, -5006, -4994, + -4982, -4970, -4958, -4946, + -4934, -4922, -4910, -4898, + -4886, -4874, -4862, -4850, + -4838, -4826, -4814, -4803, + -4791, -4778, -4767, -4755, + -4743, -4731, -4719, -4708, + -4696, -4684, -4672, -4660, + -4649, -4637, -4625, -4613, + -4601, -4590, -4578, -4566, + -4554, -4543, -4531, -4520, + -4508, -4496, -4484, -4473, + -4461, -4449, -4438, -4427, + -4415, -4403, -4392, -4380, + -4368, -4357, -4345, -4334, + -4322, -4311, -4299, -4288, + -4276, -4265, -4253, -4242, + -4230, -4219, -4207, -4196, + -4184, -4173, -4162, -4150, + -4139, -4128, -4116, -4105, + -4094, -4082, -4071, -4060, + -4048, -4037, -4026, -4014, + -4003, -3992, -3980, -3969, + -3958, -3946, -3935, -3924, + -3913, -3901, -3890, -3879, + -3868, -3857, -3845, -3834, + -3823, -3812, -3801, -3790, + -3779, -3767, -3756, -3745, + -3734, -3723, -3712, -3700, + -3689, -3678, -3667, -3656, + -3645, -3634, -3623, -3612, + -3601, -3590, -3579, -3568, + -3557, -3545, -3535, -3524, + -3513, -3502, -3491, -3480, + -3469, -3458, -3447, -3436, + -3425, -3414, -3403, -3392, + -3381, -3370, -3360, -3348, + -3337, -3327, -3316, -3305, + -3294, -3283, -3272, -3262, + -3251, -3240, -3229, -3218, + -3207, -3197, -3185, -3175, + -3164, -3153, -3142, -3132, + -3121, -3110, -3099, -3088, + -3078, -3067, -3056, -3045, + -3035, -3024, -3013, -3003, + -2992, -2981, -2970, -2960, + -2949, -2938, -2928, -2917, + -2906, -2895, -2885, -2874, + -2864, -2853, -2842, -2832, + -2821, -2810, -2800, -2789, + -2778, -2768, -2757, -2747, + -2736, -2725, -2715, -2704, + -2694, -2683, -2673, -2662, + -2651, -2641, -2630, -2620, + -2609, -2599, -2588, -2578, + -2567, -2556, -2546, -2535, + -2525, -2515, -2504, -2493, + -2483, -2472, -2462, -2451, + -2441, -2431, -2420, -2410, + -2399, -2389, -2378, -2367, + -2357, -2347, -2336, -2326, + -2315, -2305, -2295, -2284, + -2274, -2263, -2253, -2243, + -2232, -2222, -2211, -2201, + -2191, -2180, -2170, -2159, + -2149, -2139, -2128, -2118, + -2107, -2097, -2087, -2076, + -2066, -2056, -2046, -2035, + -2025, -2014, -2004, -1994, + -1983, -1973, -1963, -1953, + -1942, -1932, -1921, -1911, + -1901, -1891, -1880, -1870, + -1860, -1849, -1839, -1829, + -1819, -1808, -1798, -1788, + -1778, -1767, -1757, -1747, + -1736, -1726, -1716, -1706, + -1695, -1685, -1675, -1665, + -1654, -1644, -1634, -1624, + -1613, -1603, -1593, -1583, + -1573, -1563, -1552, -1542, + -1532, -1522, -1511, -1501, + -1491, -1481, -1471, -1461, + -1450, -1440, -1430, -1420, + -1409, -1400, -1389, -1379, + -1369, -1359, -1348, -1339, + -1328, -1318, -1308, -1298, + -1288, -1278, -1267, -1257, + -1247, -1237, -1227, -1217, + -1207, -1196, -1186, -1176, + -1166, -1156, -1146, -1135, + -1126, -1115, -1105, -1095, + -1085, -1075, -1065, -1055, + -1044, -1034, -1024, -1014, + -1004, -994, -984, -974, + -964, -954, -944, -933, + -923, -913, -903, -893, + -883, -873, -863, -853, + -843, -833, -822, -812, + -802, -792, -782, -772, + -762, -752, -742, -732, + -722, -712, -702, -691, + -682, -671, -662, -651, + -641, -631, -621, -611, + -601, -591, -581, -571, + -561, -551, -541, -531, + -521, -511, -501, -491, + -480, -471, -460, -451, + -440, -430, -420, -410, + -400, -390, -380, -370, + -360, -350, -340, -330, + -320, -310, -300, -290, + -280, -270, -260, -250, + -240, -230, -220, -210, + -199, -190, -179, -170, + -159, -150, -139, -129, + -119, -109, -99, -89, + -79, -69, -59, -49, + -39, -29, -19, -9, + 1, 11, 21, 31, + 41, 51, 61, 71, + 81, 91, 101, 111, + 121, 131, 141, 152, + 161, 172, 181, 192, + 202, 212, 222, 232, + 242, 252, 262, 272, + 282, 292, 302, 312, + 322, 332, 342, 352, + 362, 372, 382, 392, + 402, 412, 422, 433, + 442, 453, 462, 473, + 483, 493, 503, 513, + 523, 533, 543, 553, + 563, 573, 583, 593, + 603, 613, 623, 633, + 643, 653, 664, 673, + 684, 694, 704, 714, + 724, 734, 744, 754, + 764, 774, 784, 794, + 804, 815, 825, 835, + 845, 855, 865, 875, + 885, 895, 905, 915, + 925, 936, 946, 956, + 966, 976, 986, 996, + 1006, 1016, 1026, 1037, + 1047, 1057, 1067, 1077, + 1087, 1097, 1107, 1117, + 1128, 1138, 1148, 1158, + 1168, 1178, 1188, 1198, + 1209, 1219, 1229, 1239, + 1249, 1259, 1269, 1280, + 1290, 1300, 1310, 1320, + 1330, 1341, 1351, 1361, + 1371, 1381, 1391, 1402, + 1412, 1422, 1432, 1442, + 1452, 1463, 1473, 1483, + 1493, 1503, 1513, 1524, + 1534, 1544, 1554, 1565, + 1575, 1585, 1595, 1606, + 1616, 1626, 1636, 1647, + 1656, 1667, 1677, 1687, + 1697, 1708, 1718, 1729, + 1739, 1749, 1759, 1769, + 1780, 1790, 1800, 1810, + 1821, 1831, 1841, 1851, + 1862, 1872, 1883, 1893, + 1903, 1913, 1923, 1934, + 1944, 1955, 1965, 1975, + 1985, 1996, 2006, 2016, + 2027, 2037, 2048, 2058, + 2068, 2079, 2089, 2099, + 2110, 2120, 2130, 2141, + 2151, 2161, 2172, 2182, + 2193, 2203, 2213, 2224, + 2234, 2245, 2255, 2265, + 2276, 2286, 2297, 2307, + 2318, 2328, 2338, 2349, + 2359, 2370, 2380, 2391, + 2401, 2412, 2422, 2433, + 2443, 2454, 2464, 2475, + 2485, 2496, 2506, 2517, + 2527, 2537, 2548, 2559, + 2569, 2580, 2590, 2601, + 2612, 2622, 2632, 2643, + 2654, 2664, 2675, 2685, + 2696, 2707, 2717, 2728, + 2738, 2749, 2759, 2770, + 2781, 2791, 2802, 2813, + 2823, 2834, 2845, 2855, + 2866, 2877, 2887, 2898, + 2909, 2919, 2930, 2941, + 2951, 2962, 2973, 2984, + 2994, 3005, 3015, 3027, + 3037, 3048, 3058, 3069, + 3080, 3091, 3101, 3113, + 3123, 3134, 3145, 3156, + 3166, 3177, 3188, 3199, + 3210, 3220, 3231, 3242, + 3253, 3264, 3275, 3285, + 3296, 3307, 3318, 3329, + 3340, 3351, 3362, 3373, + 3384, 3394, 3405, 3416, + 3427, 3438, 3449, 3460, + 3471, 3482, 3493, 3504, + 3515, 3526, 3537, 3548, + 3559, 3570, 3581, 3592, + 3603, 3614, 3625, 3636, + 3647, 3659, 3670, 3681, + 3692, 3703, 3714, 3725, + 3736, 3747, 3758, 3770, + 3781, 3792, 3803, 3814, + 3825, 3837, 3848, 3859, + 3870, 3881, 3893, 3904, + 3915, 3926, 3937, 3949, + 3960, 3971, 3983, 3994, + 4005, 4017, 4028, 4039, + 4051, 4062, 4073, 4085, + 4096, 4107, 4119, 4130, + 4141, 4153, 4164, 4175, + 4187, 4198, 4210, 4221, + 4233, 4244, 4256, 4267, + 4279, 4290, 4302, 4313, + 4325, 4336, 4348, 4359, + 4371, 4382, 4394, 4406, + 4417, 4429, 4440, 4452, + 4464, 4475, 4487, 4499, + 4510, 4522, 4533, 4545, + 4557, 4569, 4581, 4592, + 4604, 4616, 4627, 4639, + 4651, 4663, 4674, 4686, + 4698, 4710, 4722, 4734, + 4746, 4758, 4769, 4781, + 4793, 4805, 4817, 4829, + 4841, 4853, 4865, 4877, + 4889, 4900, 4913, 4925, + 4936, 4949, 4961, 4973, + 4985, 4997, 5009, 5021, + 5033, 5045, 5057, 5070, + 5081, 5094, 5106, 5118, + 5130, 5143, 5155, 5167, + 5179, 5191, 5204, 5216, + 5228, 5240, 5253, 5265, + 5278, 5290, 5302, 5315, + 5327, 5340, 5352, 5364, + 5377, 5389, 5401, 5414, + 5426, 5439, 5451, 5464, + 5476, 5489, 5502, 5514, + 5527, 5539, 5552, 5564, + 5577, 5590, 5603, 5615, + 5628, 5641, 5653, 5666, + 5679, 5691, 5704, 5717, + 5730, 5743, 5756, 5768, + 5781, 5794, 5807, 5820, + 5833, 5846, 5859, 5872, + 5885, 5897, 5911, 5924, + 5937, 5950, 5963, 5976, + 5989, 6002, 6015, 6028, + 6042, 6055, 6068, 6081, + 6094, 6108, 6121, 6134, + 6147, 6160, 6174, 6187, + 6201, 6214, 6227, 6241, + 6254, 6267, 6281, 6294, + 6308, 6321, 6335, 6348, + 6362, 6375, 6389, 6403, + 6416, 6430, 6443, 6457, + 6471, 6485, 6498, 6512, + 6526, 6540, 6554, 6567, + 6581, 6595, 6609, 6623, + 6637, 6651, 6665, 6679, + 6692, 6706, 6721, 6735, + 6749, 6763, 6777, 6791, + 6805, 6819, 6833, 6848, + 6862, 6876, 6890, 6905, + 6919, 6933, 6948, 6962, + 6976, 6991, 7005, 7020, + 7034, 7049, 7064, 7078, + 7093, 7107, 7122, 7136, + 7151, 7166, 7180, 7195, + 7210, 7225, 7240, 7254, + 7269, 7284, 7299, 7314, + 7329, 7344, 7359, 7374, + 7389, 7404, 7419, 7434, + 7449, 7465, 7480, 7495, + 7510, 7526, 7541, 7556, + 7571, 7587, 7602, 7618, + 7633, 7648, 7664, 7680, + 7695, 7711, 7726, 7742, + 7758, 7773, 7789, 7805, + 7821, 7836, 7852, 7868, + 7884, 7900, 7916, 7932, + 7948, 7964, 7981, 7997, + 8013, 8029, 8045, 8061, + 8078, 8094, 8110, 8127, + 8143, 8160, 8176, 8193, + 8209, 8226, 8242, 8259, + 8276, 8292, 8309, 8326, + 8343, 8360, 8377, 8394, + 8410, 8428, 8444, 8462, + 8479, 8496, 8513, 8530, + 8548, 8565, 8582, 8600, + 8617, 8634, 8652, 8670, + 8687, 8704, 8722, 8740, + 8758, 8775, 8793, 8811, + 8829, 8847, 8865, 8883, + 8901, 8919, 8937, 8955, + 8974, 8992, 9010, 9029, + 9047, 9066, 9084, 9103, + 9121, 9140, 9159, 9177, + 9196, 9215, 9234, 9253, + 9272, 9291, 9310, 9329, + 9349, 9368, 9387, 9406, + 9426, 9445, 9465, 9484, + 9504, 9524, 9544, 9563, + 9583, 9603, 9623, 9643, + 9663, 9683, 9703, 9723, + 9744, 9764, 9785, 9805, + 9826, 9846, 9867, 9888, + 9909, 9930, 9950, 9971, + 9993, 10013, 10035, 10056, + 10077, 10099, 10120, 10142, + 10163, 10185, 10207, 10229, + 10251, 10273, 10294, 10317, + 10339, 10361, 10384, 10406, + 10428, 10451, 10474, 10496, + 10519, 10542, 10565, 10588, + 10612, 10635, 10658, 10682, + 10705, 10729, 10752, 10776, + 10800, 10824, 10848, 10872, + 10896, 10921, 10945, 10969, + 10994, 11019, 11044, 11069, + 11094, 11119, 11144, 11169, + 11195, 11221, 11246, 11272, + 11298, 11324, 11350, 11376, + 11402, 11429, 11456, 11482, + 11509, 11536, 11563, 11590, + 11618, 11645, 11673, 11701, + 11728, 11756, 11785, 11813, + 11842, 11870, 11899, 11928, + 11957, 11986, 12015, 12045, + 12074, 12104, 12134, 12164, + 12194, 12225, 12255, 12286, + 12317, 12348, 12380, 12411, + 12443, 12475, 12507, 12539, + 12571, 12604, 12637, 12670, + 12703, 12737, 12771, 12804, + 12839, 12873, 12907, 12942, + 12977, 13013, 13048, 13084, + 13120, 13156, 13192, 13229, + 13267, 13304, 13341, 13379, + 13418, 13456, 13495, 13534, + 13573, 13613, 13653, 13693, + 13734, 13775, 13817, 13858, + 13901, 13943, 13986, 14029, + 14073, 14117, 14162, 14206, + 14252, 14297, 14343, 14390, + 14437, 14485, 14533, 14582, + 14631, 14680, 14731, 14782, + 14833, 14885, 14937, 14991, + 15044, 15099, 15154, 15210, + 15266, 15324, 15382, 15441, + 15500, 15561, 15622, 15684, + 15747, 15811, 15877, 15943, + 16010, 16078, 16148, 16218, + 16290, 16363, 16437, 16513, + 16590, 16669, 16749, 16831, + 16915, 17000, 17088, 17177, + 17268, 17362, 17458, 17556, + 17657, 17761, 17868, 17977, + 18090, 18207, 18328, 18452, + 18581, 18715, 18854, 18998, + 19149, 19307, 19472, 19645, + 19828, 20021, 20226, 20444, + 20678, 20930, 21204, 21503, + 21835, 22206, 22630, 23124, + 23721, 24478, 25529, 27316, +}; + +/* tabledist - return a pseudo-randomly distributed value with mean mu and + * std deviation sigma. Uses table lookup to approximate the desired + * distribution, and a uniformly-distributed pseudo-random source. + */ +static inline int tabledist(int mu, int sigma) +{ + int x; + int index; + int sigmamod, sigmadiv; + + if (sigma == 0) + return mu; + + index = (net_random() & (TABLESIZE-1)); + sigmamod = sigma%TABLEFACTOR; + sigmadiv = sigma/TABLEFACTOR; + x = sigmamod*disttable[index]; + + if (x >= 0) + x += TABLEFACTOR/2; + else + x -= TABLEFACTOR/2; + + x /= TABLEFACTOR; + x += sigmadiv*disttable[index]; + x += mu; + return x; +} + /* Enqueue packets with underlying discipline (fifo) * but mark them with current time first. */ @@ -52,6 +606,8 @@ { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + psched_time_t now; + long delay; pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); @@ -61,11 +617,35 @@ return 0; /* lie about loss so TCP doesn't know */ } - if (q->qnormal.qlen < sch->dev->tx_queue_len) { - PSCHED_GET_TIME(cb->time_to_send); - PSCHED_TADD(cb->time_to_send, q->latency); - __skb_queue_tail(&q->qnormal, skb); + /* If doing simple delay then gap == 0 so all packets + * go into the delayed holding queue + * otherwise if doing out of order only "1 out of gap" + * packets will be delayed. + */ + if (q->counter < q->gap) { + int ret; + + ++q->counter; + ret = q->qdisc->enqueue(skb, q->qdisc); + if (ret) + sch->stats.drops++; + return ret; + } + + q->counter = 0; + + PSCHED_GET_TIME(now); + if (q->jitter) + delay = tabledist(q->latency, q->jitter); + else + delay = q->latency; + + PSCHED_TADD2(now, delay, cb->time_to_send); + + /* Always queue at tail to keep packets in order */ + if (likely(q->delayed.qlen < q->limit)) { + __skb_queue_tail(&q->delayed, skb); sch->q.qlen++; sch->stats.bytes += skb->len; sch->stats.packets++; @@ -81,81 +661,67 @@ static int netem_requeue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + int ret; - __skb_queue_head(&q->qnormal, skb); - sch->q.qlen++; - return 0; + if ((ret = q->qdisc->ops->requeue(skb, q->qdisc)) == 0) + sch->q.qlen++; + + return ret; } -/* - * Check the look aside buffer list, and see if any freshly baked buffers. - * If head of queue is not baked, set timer. - */ -static struct sk_buff *netem_get_delayed(struct netem_sched_data *q) +static unsigned int netem_drop(struct Qdisc* sch) { - struct sk_buff *skb; - psched_time_t now; - long delay; - - skb = skb_peek(&q->qdelay); - if (skb) { - const struct netem_skb_cb *cb - = (const struct netem_skb_cb *)skb->cb; - - PSCHED_GET_TIME(now); - delay = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_dequeue: delay queue %p@%lu %ld\n", - skb, jiffies, delay); - - /* it's baked enough */ - if (delay <= 0) { - __skb_unlink(skb, &q->qdelay); - del_timer(&q->timer); - return skb; - } + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + unsigned int len; - if (!timer_pending(&q->timer)) { - q->timer.expires = jiffies + delay; - add_timer(&q->timer); - } + if ((len = q->qdisc->ops->drop(q->qdisc)) != 0) { + sch->q.qlen--; + sch->stats.drops++; } - return NULL; + return len; } /* Dequeue packet. - * If packet needs to be held up, then put in the delay - * queue and set timer to wakeup later. + * Move all packets that are ready to send from the delay holding + * list to the underlying qdisc, then just call dequeue */ static struct sk_buff *netem_dequeue(struct Qdisc *sch) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; struct sk_buff *skb; + psched_time_t now; + + PSCHED_GET_TIME(now); + while ((skb = skb_peek(&q->delayed)) != NULL) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + long delay + = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_dequeue: delay queue %p@%lu %ld\n", + skb, jiffies, delay); - skb = netem_get_delayed(q); - if (!skb && (skb = __skb_dequeue(&q->qnormal))) { - /* are we doing out of order packet skip? */ - if (q->counter < q->gap) { - pr_debug("netem_dequeue: send %p normally\n", skb); - q->counter++; - } else { - /* don't send now hold for later */ - pr_debug("netem_dequeue: hold [%p]@%lu\n", skb, jiffies); - __skb_queue_tail(&q->qdelay, skb); - q->counter = 0; - skb = netem_get_delayed(q); + /* if more time remaining? */ + if (delay > 0) { + mod_timer(&q->timer, jiffies + delay); + break; } + __skb_unlink(skb, &q->delayed); + + if (q->qdisc->enqueue(skb, q->qdisc)) + sch->stats.drops++; } - if (skb) + skb = q->qdisc->dequeue(q->qdisc); + if (skb) sch->q.qlen--; return skb; } -static void netem_timer(unsigned long arg) +static void netem_watchdog(unsigned long arg) { struct Qdisc *sch = (struct Qdisc *)arg; - pr_debug("netem_timer: fired @%lu\n", jiffies); + pr_debug("netem_watchdog: fired @%lu\n", jiffies); netif_schedule(sch->dev); } @@ -163,24 +729,63 @@ { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; - skb_queue_purge(&q->qnormal); - skb_queue_purge(&q->qdelay); + qdisc_reset(q->qdisc); + skb_queue_purge(&q->delayed); sch->q.qlen = 0; del_timer_sync(&q->timer); } +static int set_fifo_limit(struct Qdisc *q, int limit) +{ + struct rtattr *rta; + int ret = -ENOMEM; + + rta = kmalloc(RTA_LENGTH(sizeof(struct tc_fifo_qopt)), GFP_KERNEL); + if (rta) { + rta->rta_type = RTM_NEWQDISC; + rta->rta_len = RTA_LENGTH(sizeof(struct tc_fifo_qopt)); + ((struct tc_fifo_qopt *)RTA_DATA(rta))->limit = limit; + + ret = q->ops->change(q, rta); + kfree(rta); + } + return ret; +} + static int netem_change(struct Qdisc *sch, struct rtattr *opt) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; struct tc_netem_qopt *qopt = RTA_DATA(opt); + struct Qdisc *child; + int ret; + + if (opt->rta_len < RTA_LENGTH(sizeof(*qopt))) + return -EINVAL; + + child = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (!child) + return -EINVAL; - if (qopt->limit) - sch->dev->tx_queue_len = qopt->limit; + ret = set_fifo_limit(child, qopt->limit); + if (ret) { + qdisc_destroy(child); + return ret; + } - q->gap = qopt->gap; - q->loss = qopt->loss; - q->latency = qopt->latency; + sch_tree_lock(sch); + if (child) { + child = xchg(&q->qdisc, child); + if (child != &noop_qdisc) + qdisc_destroy(child); + + q->latency = qopt->latency; + q->jitter = qopt->jitter; + q->limit = qopt->limit; + q->gap = qopt->gap; + q->loss = qopt->loss; + } + sch_tree_unlock(sch); return 0; } @@ -188,25 +793,36 @@ static int netem_init(struct Qdisc *sch, struct rtattr *opt) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + int err; if (!opt) return -EINVAL; - skb_queue_head_init(&q->qnormal); - skb_queue_head_init(&q->qdelay); + MOD_INC_USE_COUNT; + skb_queue_head_init(&q->delayed); + q->qdisc = &noop_qdisc; + init_timer(&q->timer); - q->timer.function = netem_timer; + q->timer.function = netem_watchdog; q->timer.data = (unsigned long) sch; q->counter = 0; - return netem_change(sch, opt); + err = netem_change(sch, opt); + if (err != 0) + MOD_DEC_USE_COUNT; + return err; } static void netem_destroy(struct Qdisc *sch) { struct netem_sched_data *q = (struct netem_sched_data *)sch->data; - del_timer_sync(&q->timer); + del_timer(&q->timer); + + qdisc_destroy(q->qdisc); + q->qdisc = &noop_qdisc; + + MOD_DEC_USE_COUNT; } static int netem_dump(struct Qdisc *sch, struct sk_buff *skb) @@ -216,6 +832,7 @@ struct tc_netem_qopt qopt; qopt.latency = q->latency; + qopt.jitter = q->jitter; qopt.limit = sch->dev->tx_queue_len; qopt.loss = q->loss; qopt.gap = q->gap; @@ -229,12 +846,100 @@ return -1; } +static int netem_dump_class(struct Qdisc *sch, unsigned long cl, + struct sk_buff *skb, struct tcmsg *tcm) +{ + struct netem_sched_data *q = (struct netem_sched_data*)sch->data; + + if (cl != 1) /* only one class */ + return -ENOENT; + + tcm->tcm_handle |= TC_H_MIN(1); + tcm->tcm_info = q->qdisc->handle; + + return 0; +} + +static int netem_graft(struct Qdisc *sch, unsigned long arg, struct Qdisc *new, + struct Qdisc **old) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + + if (new == NULL) + new = &noop_qdisc; + + sch_tree_lock(sch); + *old = xchg(&q->qdisc, new); + qdisc_reset(*old); + sch->q.qlen = 0; + sch_tree_unlock(sch); + + return 0; +} + +static struct Qdisc *netem_leaf(struct Qdisc *sch, unsigned long arg) +{ + struct netem_sched_data *q = (struct netem_sched_data *)sch->data; + return q->qdisc; +} + +static unsigned long netem_get(struct Qdisc *sch, u32 classid) +{ + return 1; +} + +static void netem_put(struct Qdisc *sch, unsigned long arg) +{ +} + +static int netem_change_class(struct Qdisc *sch, u32 classid, u32 parentid, + struct rtattr **tca, unsigned long *arg) +{ + return -ENOSYS; +} + +static int netem_delete(struct Qdisc *sch, unsigned long arg) +{ + return -ENOSYS; +} + +static void netem_walk(struct Qdisc *sch, struct qdisc_walker *walker) +{ + if (!walker->stop) { + if (walker->count >= walker->skip) + if (walker->fn(sch, 1, walker) < 0) { + walker->stop = 1; + return; + } + walker->count++; + } +} + +static struct tcf_proto **netem_find_tcf(struct Qdisc *sch, unsigned long cl) +{ + return NULL; +} + +static struct Qdisc_class_ops netem_class_ops = { + .graft = netem_graft, + .leaf = netem_leaf, + .get = netem_get, + .put = netem_put, + .change = netem_change_class, + .delete = netem_delete, + .walk = netem_walk, + .tcf_chain = netem_find_tcf, + .dump = netem_dump_class, +}; + static struct Qdisc_ops netem_qdisc_ops = { .id = "netem", + .cl_ops = &netem_class_ops, .priv_size = sizeof(struct netem_sched_data), .enqueue = netem_enqueue, .dequeue = netem_dequeue, .requeue = netem_requeue, + .drop = netem_drop, .init = netem_init, .reset = netem_reset, .destroy = netem_destroy, From shemminger@osdl.org Wed Jul 28 16:24:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 16:25:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6SNOTiL003683 for ; Wed, 28 Jul 2004 16:24:46 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6SNOE116324; Wed, 28 Jul 2004 16:24:15 -0700 Date: Wed, 28 Jul 2004 16:24:13 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH] (3/4) bridge linkstate handling Message-Id: <20040728162413.0de73ea3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This makes bridge port status reflect both the state of the interface from software (up/down) and the carrier. It makes STP handle link failure (cable breakage, etc). The original concept comes from a Mark Ruijter who implemented it differently. My way is simpler and requires no polling. Obviously, this link state detection will only work if the network card handles the events properly. Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c 2004-07-28 15:56:15 -07:00 +++ b/net/bridge/br_if.c 2004-07-28 15:56:15 -07:00 @@ -344,7 +344,8 @@ spin_lock_bh(&br->lock); br_stp_recalculate_bridge_id(br); - if ((br->dev->flags & IFF_UP) && (dev->flags & IFF_UP)) + if ((br->dev->flags & IFF_UP) + && (dev->flags & IFF_UP) && netif_carrier_ok(dev)) br_stp_enable_port(p); spin_unlock_bh(&br->lock); diff -Nru a/net/bridge/br_notify.c b/net/bridge/br_notify.c --- a/net/bridge/br_notify.c 2004-07-28 15:56:15 -07:00 +++ b/net/bridge/br_notify.c 2004-07-28 15:56:15 -07:00 @@ -19,58 +19,59 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, void *ptr); -struct notifier_block br_device_notifier = -{ +struct notifier_block br_device_notifier = { .notifier_call = br_device_event }; static int br_device_event(struct notifier_block *unused, unsigned long event, void *ptr) { - struct net_device *dev; - struct net_bridge_port *p; + struct net_device *dev = ptr; + struct net_bridge_port *p = dev->br_port; struct net_bridge *br; - dev = ptr; - p = dev->br_port; - if (p == NULL) return NOTIFY_DONE; br = p->br; + if ( !(br->dev->flags & IFF_UP)) + return NOTIFY_DONE; + + if (event == NETDEV_CHANGEMTU) { + dev_set_mtu(br->dev, br_min_mtu(br)); + return NOTIFY_DONE; + } + spin_lock_bh(&br->lock); switch (event) { case NETDEV_CHANGEADDR: - spin_lock_bh(&br->lock); br_fdb_changeaddr(p, dev->dev_addr); - if (br->dev->flags & IFF_UP) - br_stp_recalculate_bridge_id(br); - spin_unlock_bh(&br->lock); + br_stp_recalculate_bridge_id(br); break; - case NETDEV_CHANGEMTU: - dev_set_mtu(br->dev, br_min_mtu(br)); + case NETDEV_CHANGE: /* device is up but carrier changed */ + if (netif_carrier_ok(dev)) { + if (p->state == BR_STATE_DISABLED) + br_stp_enable_port(p); + } else { + if (p->state != BR_STATE_DISABLED) + br_stp_disable_port(p); + } break; case NETDEV_DOWN: - if (br->dev->flags & IFF_UP) { - spin_lock_bh(&br->lock); - br_stp_disable_port(p); - spin_unlock_bh(&br->lock); - } + br_stp_disable_port(p); break; case NETDEV_UP: - if (br->dev->flags & IFF_UP) { - spin_lock_bh(&br->lock); + if (netif_carrier_ok(dev)) br_stp_enable_port(p); - spin_unlock_bh(&br->lock); - } break; case NETDEV_UNREGISTER: br_del_if(br, dev); break; - } + } + spin_unlock_bh(&br->lock); return NOTIFY_DONE; } diff -Nru a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c --- a/net/bridge/br_stp_if.c 2004-07-28 15:56:15 -07:00 +++ b/net/bridge/br_stp_if.c 2004-07-28 15:56:15 -07:00 @@ -52,7 +52,7 @@ br_config_bpdu_generation(br); list_for_each_entry(p, &br->port_list, list) { - if (p->dev->flags & IFF_UP) + if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev)) br_stp_enable_port(p); } From ptsjohol@cc.jyu.fi Wed Jul 28 18:04:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 18:05:18 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T0ki8W006426 for ; Wed, 28 Jul 2004 17:47:47 -0700 Received: from silmu.st.jyu.fi (IDENT:zkRxumxo6z/k0GxEuTcHJUbsLKL/e/gw@silmu.st.jyu.fi [130.234.4.64]) by posti6.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6T0kCob022000; Thu, 29 Jul 2004 03:46:12 +0300 Date: Thu, 29 Jul 2004 03:46:10 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Robert Olsson cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16647.61953.158512.433946@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti6.jyu.fi; Thu, 29 Jul 2004 03:46:13 +0300 X-archive-position: 7245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev On Wed, 28 Jul 2004, Robert Olsson wrote: >> It would be nice that one could use the full capacity of his/her computer. >> This is not a big problem for everyday use for a workstation but prevents >> 2.6-series to be used in production-enviroments in the servers. >> But hey.. we need to do some work and maybe we will resolve this. =) > this now. But it does not address userland starvation so if you your workload > can give reproduceably results wrt starvation (Alexey's app) we can do some > tests. First I think should be collect data from current system and check > that results a reproduceable. It takes about 2 minutes to reproduce the symptoms so it's not a problem anymore when I know exactly what I have to do. > Below is a patch to monitor softirq's it uses fastroute stats in softnet_stat > you may have to hack it. Ok, I had to do some modifications but here are the results: while true; cat /proc/net/softnet_stat | tee -a log.txt; sleep 5; done The first log is when running exact same patch you sent. -- 000401f1 00000000 00000000 00000000 000002ec 000000d8 00084026 0004495c 00000000 00000000 00000000 00000326 000000d8 0008ae93 0004820b 00000000 00000000 00000000 0000034a 000000d8 00090755 0004a613 00000000 00000000 00000000 00000358 000000d8 00093f0f 0004ca12 00000000 00000000 00000000 00000370 000000da 000976c9 000500f2 00000000 00000000 00000000 0000045e 000000da 0009cf4b 0005417b 00000000 00000000 00000000 000005f8 000000da 000a36b5 00056a66 00000000 00000000 00000000 0000064c 000000da 000a7619 0005a94b 00000000 00000000 00000000 000007bf 000000da 000ad9da 0005d9b7 00000000 00000000 00000000 00000816 000000db 000b1fff 00060286 00000000 00000000 00000000 00000834 000000db 000b5dee 00064ffb 00000000 00000000 00000000 00000a0c 000000db 000bd33c 00069498 00000000 00000000 00000000 00000b97 000000db 000c3d62 0006cdf1 00000000 00000000 00000000 00000cc5 000000db 000c972b 0006f9cc 00000000 00000000 00000000 00000d43 000000db 000cde12 0007280d 00000000 00000000 00000000 00000dea 000000db 000d268d 00074f33 00000000 00000000 00000000 00000e3e 000000db 000d655b 00078271 00000000 00000000 00000000 00000f45 000000db 000db849 0007beee 00000000 00000000 00000000 0000106e 000000db 000e18ae 0007e402 00000000 00000000 00000000 00001086 000000db 000e513b 000815c4 00000000 00000000 00000000 0000114d 000000db 000e9d33 00082abc 00000000 0000076c 00000000 000011f0 000001ad 000ec552 00082abc 00000000 00001180 00000000 000014e8 00000207 000ecc14 00082abc 00000000 00001b44 00000000 000014e8 00000257 000ed588 00082abc 00000000 0000251c 00000000 000018bc 000002bb 000edb28 00082abc 00000000 00002ee0 00000000 00001970 0000033d 000ee3b6 00082abc 00000000 000038e0 00000000 00001eac 0000038d 000ee82a 00082abc 00000000 0000443e 00000000 00002244 00000405 000eef78 00082abc 00000000 00004e02 00000000 000024c4 00000469 000ef658 00082abc 00000000 000057c6 00000000 000026cc 000004c3 000efdba 00082abc 00000000 000061da 00000000 00002910 00000513 000f053a 00082abc 00000000 00006bbc 00000000 00002b2c 0000056d 000f0ca6 00082abe 00000000 000075c6 00000000 00002e10 000005d1 000f1368 00082abe 00000000 00007f9e 00000000 000030a4 00000635 000f1a48 00082abe 00000000 000089da 00000000 00003338 000006a3 000f2182 00082abe 00000000 00009420 00000000 00003554 000006fd 000f2952 00082abe 00000000 00009e70 00000000 00003c34 00000829 000f2b96 00082ac0 00000000 0000a8c0 00000000 000044cc 00000991 000f2be6 00082ac0 00000000 0000b2e8 00000000 00004814 00000fd1 000f2c86 00082ac0 00000000 0000bcfc 00000000 00004814 0000199f 000f2ccc 00082ac0 00000000 0000c72e 00000000 00004814 00002377 000f2d26 00082ac2 00000000 0000d142 00000000 00004864 00002c19 000f2e48 00082ac2 00000000 0000db56 00000000 00004864 0000358d 000f2ee8 00082ac2 00000000 0000e574 00000000 00004864 00003f33 000f2f60 00082ac2 00000000 0000ef9c 00000000 0000497c 000047e9 000f2fba 00082ac2 00000000 0000f9b0 00000000 0000497c 000051ad 000f300a 00082ac2 00000000 000103ce 00000000 0000497c 00005b7b 000f305a 00082ac4 00000000 00010dec 00000000 0000497c 00006549 000f30aa 00082ac4 00000000 0001180a 00000000 0000497c 00006f17 000f30fa 00082ac4 00000000 0001225a 00000000 00004a94 00007809 000f3140 -- and the second one is when that if-condition is true (just wanted to try if that would make any difference): #if 1 /* Avoid softirq's from DoS'ing user apps incl. RCU's etc */ -- 00000082 00000000 00000000 00000000 00000010 00000116 0001fe40 00000082 00000000 00000000 00000000 00000010 00000119 000211f9 0000094d 00000000 00000000 00000000 00000014 0000011b 00022e69 00004ab8 00000000 00000000 00000000 00000032 0000011d 0002877e 00006b19 00000000 00000000 00000000 0000003f 0000011f 0002cb8e 0000c7a0 00000000 00000000 00000000 00000073 00000122 0003409e 0001334a 00000000 00000000 00000000 000000d6 00000124 0003dd4e 00017537 00000000 00000000 00000000 00000113 00000127 00044598 0001b528 00000000 00000000 00000000 0000015a 00000129 0004acb5 0001ec8f 00000000 00000000 00000000 000001ae 0000012b 0005024a 00021186 00000000 00000000 00000000 000001c1 0000012e 00053ace 000236f1 00000000 00000000 00000000 00000205 0000012e 000575c7 00026980 00000000 00000000 00000000 0000032b 0000012e 0005c601 0002a70a 00000000 00000000 00000000 000004aa 0000012e 0006258f 0002e715 00000000 00000000 00000000 00000664 0000012e 00068ddc 00030c8b 00000000 00000000 00000000 00000690 0000012e 0006c872 0003303e 00000000 00000000 00000000 000006a3 0000012e 0006ffc6 00036172 00000000 00000000 00000000 00000786 0000012e 00074e6d 0003a3c8 00000000 00000000 00000000 0000096a 0000012e 0007b998 0003d62b 00000000 00000000 00000000 00000a85 0000012e 000808b0 000401ab 00000000 00000000 00000000 00000aa4 0000012e 000847bf 000426ba 00000000 00000000 00000000 00000ab5 0000012e 0008807b 00046099 00000000 00000000 00000000 00000c57 0000012e 0008dd31 0004a27a 00000000 00000000 00000000 00000e0b 0000012e 00094686 0004c2dc 00000000 00000122 00000000 00000e2c 000001b0 000979c8 0004c2dc 00000000 00000bae 00000000 00000e2c 00000228 000983dc 0004c2dc 00000000 00001568 00000000 00001084 00000282 00098ae4 0004c2dc 00000000 00001f0e 00000000 00001084 000002f0 0009941c 0004c2dc 00000000 00002968 00000000 00001084 00000368 00099dfe 0004c2dc 00000000 00003354 00000000 00001426 000003ae 0009a402 0004c2dc 00000000 00003d04 00000000 0000150c 0000041c 0009ac5e 0004c2dc 00000000 00004790 00000000 00001548 00000494 0009b636 0004c2dc 00000000 00005140 00000000 00001548 00000502 0009bf78 0004c2de 00000000 00005b68 00000000 00001548 0000057a 0009c928 0004c2e0 00000000 000065ae 00000000 00001598 000005e8 0009d2b0 0004c2e2 00000000 00006f4a 00000000 00001598 00000660 0009dbd4 0004c2e2 00000000 000079a4 00000000 00001660 000006ce 0009e4f8 0004c2e2 00000000 000083d6 00000000 00001660 00000746 0009eeb2 0004c2e2 00000000 00008e08 00000000 00001764 000007b4 0009f772 0004c2ee 00000000 00009858 00000000 00001764 0000082c 000a014a 0004c2f6 00000000 0000a1fe 00000000 00001764 0000089a 000a0a82 0004c2fc 00000000 0000abcc 00000000 0000182c 000008f4 000a132e 0004c2fc 00000000 0000b626 00000000 0000182c 000011aa 000a14d2 0004c302 00000000 0000c03a 00000000 00001872 00001aec 000a155e -- and it did not make any difference. I have cut out the output of "cat softnet_stat to show columns from 1 to 7. - When the ksoftirqd starts to eat cpu-time time_squeeze-value (3rd column) starts growing (in both cases it's same thing). - We are also getting more hits from SIRQ_FROM_KSOFTIRQD immediately after that. (6th column) - Total-column's value stops growing although network file transfers are still on. (1st column) > And maybe we should take the experiment disussions off the list. I think that we should leave netdev as Francois requested it in first place but we can drop the lkml if you want to. -- Pasi Sjöholm From davem@redhat.com Wed Jul 28 18:57:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 18:57:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T1vHVg007788 for ; Wed, 28 Jul 2004 18:57:18 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T1v7e1022286; Wed, 28 Jul 2004 21:57:07 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T1v7a12535; Wed, 28 Jul 2004 21:57:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T1uQCG013497; Wed, 28 Jul 2004 21:56:27 -0400 Date: Wed, 28 Jul 2004 18:55:01 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] de-inline qdiscipline locking functions. Message-Id: <20040728185501.3807c0f0.davem@redhat.com> In-Reply-To: <20040726113402.25ba72ee@dell_ss3.pdx.osdl.net> References: <20040726113402.25ba72ee@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 26 Jul 2004 11:34:02 -0700 Stephen Hemminger wrote: > This qdisc code has several inline functions for locking that is only > used when adding/deleting queuing disciplines; so make them functions > instead. The new qdisc_lock_tree encapsulates the locking used throughout > this code. > > Also qdisc_run() is only called from net/core/dev.c so it should be > defined there. Looks good, thanks Stephen. From davem@redhat.com Wed Jul 28 19:01:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 19:01:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T21a1a008165 for ; Wed, 28 Jul 2004 19:01:36 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T21Ve1023415; Wed, 28 Jul 2004 22:01:31 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T21Va14339; Wed, 28 Jul 2004 22:01:31 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T20n2b016166; Wed, 28 Jul 2004 22:00:49 -0400 Date: Wed, 28 Jul 2004 18:59:23 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, hadi@znyx.com Subject: Re: [PATCH] kill rtnl_exlock stubs Message-Id: <20040728185923.304bac86.davem@redhat.com> In-Reply-To: <4106A132.8040207@trash.net> References: <20040727095057.78c7419c@dell_ss3.pdx.osdl.net> <4106A132.8040207@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 27 Jul 2004 20:38:42 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > Rtnetlink has some macro's that are relics from earlier locking. > > They are only used a couple of places so are easy to kill. > > The variable "exclusive" in rtnetlink_rcv_msg becomes useless with > this patch. This patch (on top of Stephen's patch) removes it. Both patches look fine, thanks guys. I thought maybe Alexey might have had some fantastic plan with exclusive locks, but this stuff has gone beyond bitrot :-) From davem@redhat.com Wed Jul 28 19:09:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 19:10:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T29nT8008564 for ; Wed, 28 Jul 2004 19:09:50 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T29Ze1025073; Wed, 28 Jul 2004 22:09:35 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T29Za16466; Wed, 28 Jul 2004 22:09:35 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T28sZ8020639; Wed, 28 Jul 2004 22:08:54 -0400 Date: Wed, 28 Jul 2004 19:07:28 -0700 From: "David S. Miller" To: James Morris Cc: nakam@linux-ipv6.org, netdev@oss.sgi.com, herbert@gondor.apana.org.au Subject: Re: [PATCH]Fix adding SA through netlink(xfrm_user) Message-Id: <20040728190728.2dcf06f7.davem@redhat.com> In-Reply-To: References: <20040729001058.48cd1791@localhost> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004 11:41:33 -0400 (EDT) James Morris wrote: > On Thu, 29 Jul 2004, Masahide Nakamura wrote: > > > When adding IPsec SA with PF_KEY (pfkey_add()), > > xfrm_probe_algs() is called to make all algorithms valid. > > However, it is missing to call it with netlink (xfrm_user) case and > > it causes xfrm_aalg_get_byname() return NULL even if the name of > > algorithm seems to be correct. > > Looks ok, but odd that this has not been picked up before. As discovered, this never got picked up before mostly because the most popular user of xfrm_user (Openswan) is still using PF_KEY to probe the algorithms. Patch applied, arigato Masahide-san. From davem@redhat.com Wed Jul 28 19:11:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 19:11:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T2BhQd008879 for ; Wed, 28 Jul 2004 19:11:46 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T2Bde1025571; Wed, 28 Jul 2004 22:11:39 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T2Bda16852; Wed, 28 Jul 2004 22:11:39 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T2Av7x021496; Wed, 28 Jul 2004 22:10:57 -0400 Date: Wed, 28 Jul 2004 19:09:31 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [IPV6] Misc. Trivial Patches Message-Id: <20040728190931.5a821022.davem@redhat.com> In-Reply-To: <20040729.021643.25787950.yoshfuji@linux-ipv6.org> References: <20040729.021643.25787950.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6T2BhQd008879 X-archive-position: 7249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Jul 2004 02:16:43 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Here's misc. patches. > Also available at . Pulled, thank you. Yoshifuji-san, I imagine that you are now tired of airplanes :-) From davem@redhat.com Wed Jul 28 19:16:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 19:16:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T2GjOp009248 for ; Wed, 28 Jul 2004 19:16:45 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T2Gde1026781; Wed, 28 Jul 2004 22:16:39 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T2Gda18039; Wed, 28 Jul 2004 22:16:39 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T2FwJ8024126; Wed, 28 Jul 2004 22:15:59 -0400 Date: Wed, 28 Jul 2004 19:14:32 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] netem update for 2.4 Message-Id: <20040728191432.503ba6b2.davem@redhat.com> In-Reply-To: <20040728163622.7a431e97@dell_ss3.pdx.osdl.net> References: <20040728163622.7a431e97@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004 16:36:22 -0700 Stephen Hemminger wrote: > This makes the netem code for 2.4 equivalent to the 2.6.8 stuff. > > Signed-off-by: Stephen Hemminger Applied, thanks. From davem@redhat.com Wed Jul 28 19:18:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 19:18:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T2IFqn009540 for ; Wed, 28 Jul 2004 19:18:15 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T2I9e1027025; Wed, 28 Jul 2004 22:18:09 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T2I9a18158; Wed, 28 Jul 2004 22:18:09 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T2HSHD024686; Wed, 28 Jul 2004 22:17:28 -0400 Date: Wed, 28 Jul 2004 19:16:02 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ethertap module_param Message-Id: <20040728191602.050dd927.davem@redhat.com> In-Reply-To: <20040728113910.3c7cab65@dell_ss3.pdx.osdl.net> References: <20040728113910.3c7cab65@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004 11:39:10 -0700 Stephen Hemminger wrote: > Change ethertap to use module_param Applied. From davem@redhat.com Wed Jul 28 19:18:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 19:18:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T2Iotk009840 for ; Wed, 28 Jul 2004 19:18:51 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T2Ige1027137; Wed, 28 Jul 2004 22:18:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T2Iga18272; Wed, 28 Jul 2004 22:18:42 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T2I1NS024875; Wed, 28 Jul 2004 22:18:01 -0400 Date: Wed, 28 Jul 2004 19:16:35 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: robert.olsson@its.uu.se, netdev@oss.sgi.com Subject: Re: [PATCH] convert pktgen to module_param Message-Id: <20040728191635.3d14de9c.davem@redhat.com> In-Reply-To: <20040728114037.7bad51e2@dell_ss3.pdx.osdl.net> References: <20040728114037.7bad51e2@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jul 2004 11:40:37 -0700 Stephen Hemminger wrote: > Convert packet generator to module_param Also applied. From davem@redhat.com Wed Jul 28 19:19:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 19:19:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T2JcCp010207 for ; Wed, 28 Jul 2004 19:19:38 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T2JVe1027301; Wed, 28 Jul 2004 22:19:31 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T2JVa18415; Wed, 28 Jul 2004 22:19:31 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6T2Ioph025220; Wed, 28 Jul 2004 22:18:50 -0400 Date: Wed, 28 Jul 2004 19:17:24 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) propgate bridge internal MTU changes Message-Id: <20040728191724.4afacdce.davem@redhat.com> In-Reply-To: <20040728153725.7ace281c@dell_ss3.pdx.osdl.net> References: <20040728153725.7ace281c@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev I assume these 4 patches are for 2.6.x? I'll hit them tomorrow, regardless. From shemminger@osdl.org Wed Jul 28 22:11:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jul 2004 22:11:14 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6T5B5wT017325 for ; Wed, 28 Jul 2004 22:11:08 -0700 Received: from www.osdl.org (fire.osdl.org [65.172.181.4]) by fire-1.osdl.org (8.12.8/8.12.8) with SMTP id i6T5AuSe003930; Wed, 28 Jul 2004 22:10:56 -0700 Received: from 63.170.215.71 (SquirrelMail authenticated user shemminger) by www.osdl.org with HTTP; Wed, 28 Jul 2004 22:10:56 -0700 (PDT) Message-ID: <33064.63.170.215.71.1091077856.squirrel@www.osdl.org> In-Reply-To: <20040728191724.4afacdce.davem@redhat.com> References: <20040728153725.7ace281c@dell_ss3.pdx.osdl.net> <20040728191724.4afacdce.davem@redhat.com> Date: Wed, 28 Jul 2004 22:10:56 -0700 (PDT) Subject: Re: [Bridge] Re: [PATCH] (1/4) propgate bridge internal MTU changes From: shemminger@osdl.org To: "David S. Miller" Cc: "Stephen Hemminger" , netdev@oss.sgi.com, bridge@osdl.org User-Agent: SquirrelMail/1.4.2-1_osdl_00 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-MIMEDefang-Filter: osdl$Revision: 1.73 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev > > I assume these 4 patches are for 2.6.x? I'll hit them tomorrow, > regardless. > _______________________________________________ > Bridge mailing list > Bridge@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/bridge There is one missing additional piece, the fdb RCU code needs to use call_rcu(). Testing it now. From pranav@nodeinfotech.com Thu Jul 29 03:43:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 03:43:22 -0700 (PDT) Received: from bband.maa.sify.net (smtp.sifybroadband.com [202.144.76.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TAhGtV029947; Thu, 29 Jul 2004 03:43:17 -0700 Received: from pranav (dialpool-210-214-19-107.maa.sify.net [210.214.19.107]) by bband.maa.sify.net (Relay) with SMTP id 616962F462; Thu, 29 Jul 2004 15:07:42 +0530 (IST) Reply-To: From: "Pranav" To: Cc: Subject: Problem in IKE implemenation in linux(RACE CONDITION) Date: Thu, 29 Jul 2004 15:08:08 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-archive-position: 7255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pranav@nodeinfotech.com Precedence: bulk X-list: netdev hi everyone, I am working on IKE implementaion on linux. i have got a problem in negoatiation when both the peers start negotiating at the same time, both peers acting as initiator causing race condition. Race condition happens only when both the peer's start the same application(like ping or telnet)with eachother at the same time. can anybody help me out of this problem.. With Regards, Pranav Jadhav From hadi@cyberus.ca Thu Jul 29 04:22:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 04:22:39 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TBMWhg002271 for ; Thu, 29 Jul 2004 04:22:33 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072904223196:42247 ; Thu, 29 Jul 2004 04:22:31 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <20040724222853.752137d6.davem@redhat.com> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> <1090675993.1161.11.camel@jzny.localdomain> <20040724222853.752137d6.davem@redhat.com> Organization: jamalopolis Message-Id: <1091100138.1044.549.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 07:22:18 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 04:22:32 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 04:22:42 AM, Serialize complete at 07/29/2004 04:22:42 AM Content-Type: multipart/mixed; boundary="=-ntp7cnPbJrTVEws5Jy23" X-archive-position: 7256 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 --=-ntp7cnPbJrTVEws5Jy23 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Sun, 2004-07-25 at 01:28, David S. Miller wrote: > Ok, I'll keep this in my inbox until you give the word. [Still trying to recover after all those conferences]. Heres a patch that passes all my regression tests. I use a __u64 instead of u64 for perf counters since user space understands it. cheers, jamal PS:- at some point we need to scrub the general backward compatibility issues going forward. --=-ntp7cnPbJrTVEws5Jy23 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=p2 Content-Type: text/plain; name=p2; charset=ISO-8859-1 --- a/267-bk20-act+dummy/net/sched/cls_u32.c 2004/07/24 12:38:52 1.1 +++ b/267-bk20-act+dummy/net/sched/cls_u32.c 2004/07/28 18:37:06 @@ -64,17 +64,20 @@ struct tc_u_hnode *ht_up; #ifdef CONFIG_NET_CLS_ACT struct tc_action *action; -#ifdef CONFIG_NET_CLS_IND - char indev[IFNAMSIZ]; -#endif #else #ifdef CONFIG_NET_CLS_POLICE struct tcf_police *police; #endif #endif +#ifdef CONFIG_NET_CLS_IND + char indev[IFNAMSIZ]; +#endif u8 fshift; struct tcf_result res; struct tc_u_hnode *ht_down; +#ifdef CONFIG_CLS_U32_PERF + struct tc_u32_pcnt *pf; +#endif struct tc_u32_sel sel; }; @@ -120,6 +123,9 @@ int sdepth = 0; int off2 = 0; int sel = 0; +#ifdef CONFIG_CLS_U32_PERF + int j; +#endif int i; next_ht: @@ -130,7 +136,8 @@ struct tc_u32_key *key = n->sel.keys; #ifdef CONFIG_CLS_U32_PERF - n->sel.rcnt +=1; + n->pf->rcnt +=1; + j = 0; #endif for (i = n->sel.nkeys; i>0; i--, key++) { @@ -139,7 +146,8 @@ goto next_knode; } #ifdef CONFIG_CLS_U32_PERF - key->kcnt +=1; + n->pf->kcnts[j] +=1; + j++; #endif } if (n->ht_down == NULL) { @@ -147,7 +155,6 @@ if (n->sel.flags&TC_U32_TERMINAL) { *res = n->res; -#ifdef CONFIG_NET_CLS_ACT #ifdef CONFIG_NET_CLS_IND /* yes, i know it sucks but the feature is ** optional dammit! - JHS */ @@ -164,8 +171,9 @@ } #endif #ifdef CONFIG_CLS_U32_PERF - n->sel.rhit +=1; + n->pf->rhit +=1; #endif +#ifdef CONFIG_NET_CLS_ACT if (n->action) { int pol_res = tcf_action_exec(skb, n->action); if (skb->tc_classid > 0) { @@ -358,6 +366,10 @@ #endif if (n->ht_down) n->ht_down->refcnt--; +#ifdef CONFIG_CLS_U32_PERF + if (n && (NULL != n->pf)) + kfree(n->pf); +#endif kfree(n); return 0; } @@ -571,18 +583,6 @@ tcf_action_destroy(act, TCA_ACT_UNBIND); } -#ifdef CONFIG_NET_CLS_IND - n->indev[0] = 0; - if(tb[TCA_U32_INDEV-1]) { - struct rtattr *input_dev = tb[TCA_U32_INDEV-1]; - if (RTA_PAYLOAD(input_dev) >= IFNAMSIZ) { - printk("cls_u32: bad indev name %s\n",(char*)RTA_DATA(input_dev)); - /* should we clear state first? */ - return -EINVAL; - } - sprintf(n->indev, "%s", (char*)RTA_DATA(input_dev)); - } -#endif #else #ifdef CONFIG_NET_CLS_POLICE @@ -595,6 +595,19 @@ } #endif #endif +#ifdef CONFIG_NET_CLS_IND + n->indev[0] = 0; + if(tb[TCA_U32_INDEV-1]) { + struct rtattr *input_dev = tb[TCA_U32_INDEV-1]; + if (RTA_PAYLOAD(input_dev) >= IFNAMSIZ) { + printk("cls_u32: bad indev name %s\n",(char*)RTA_DATA(input_dev)); + /* should we clear state first? */ + return -EINVAL; + } + sprintf(n->indev, "%s", (char*)RTA_DATA(input_dev)); + printk("got IND %s\n",n->indev); + } +#endif return 0; } @@ -682,17 +695,20 @@ s = RTA_DATA(tb[TCA_U32_SEL-1]); -#ifdef CONFIG_CLS_U32_PERF - if (RTA_PAYLOAD(tb[TCA_U32_SEL-1]) < - (s->nkeys*sizeof(struct tc_u32_key)) + sizeof(struct tc_u32_sel)) { - printk("Please upgrade your iproute2 tools or compile proper options in!\n"); - return -EINVAL; -} -#endif n = kmalloc(sizeof(*n) + s->nkeys*sizeof(struct tc_u32_key), GFP_KERNEL); if (n == NULL) return -ENOBUFS; + memset(n, 0, sizeof(*n) + s->nkeys*sizeof(struct tc_u32_key)); +#ifdef CONFIG_CLS_U32_PERF + n->pf = kmalloc(sizeof(struct tc_u32_pcnt) + s->nkeys*sizeof(__u64), GFP_KERNEL); + if (n->pf == NULL) { + kfree(n); + return -ENOBUFS; + } + memset(n->pf, 0, sizeof(struct tc_u32_pcnt) + s->nkeys*sizeof(__u64)); +#endif + memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key)); n->ht_up = ht; n->handle = handle; @@ -721,6 +737,10 @@ *arg = (unsigned long)n; return 0; } +#ifdef CONFIG_CLS_U32_PERF + if (n && (NULL != n->pf)) + kfree(n->pf); +#endif kfree(n); return err; } @@ -812,13 +832,6 @@ p_rta->rta_len = skb->tail - (u8*)p_rta; } -#ifdef CONFIG_NET_CLS_IND - if(strlen(n->indev)) { - struct rtattr * p_rta = (struct rtattr*)skb->tail; - RTA_PUT(skb, TCA_U32_INDEV, IFNAMSIZ, n->indev); - p_rta->rta_len = skb->tail - (u8*)p_rta; - } -#endif #else #ifdef CONFIG_NET_CLS_POLICE @@ -834,13 +847,28 @@ } #endif #endif + +#ifdef CONFIG_NET_CLS_IND + if(strlen(n->indev)) { + struct rtattr * p_rta = (struct rtattr*)skb->tail; + RTA_PUT(skb, TCA_U32_INDEV, IFNAMSIZ, n->indev); + p_rta->rta_len = skb->tail - (u8*)p_rta; + } +#endif +#ifdef CONFIG_CLS_U32_PERF + RTA_PUT(skb, TCA_U32_PCNT, + sizeof(struct tc_u32_pcnt) + n->sel.nkeys*sizeof(__u64), + n->pf); +#endif } rta->rta_len = skb->tail - b; #ifdef CONFIG_NET_CLS_ACT - if (TC_U32_KEY(n->handle) && n->action && n->action->type == TCA_OLD_COMPAT) { - if (tcf_action_copy_stats(skb,n->action)) - goto rtattr_failure; + if (TC_U32_KEY(n->handle) != 0) { + if (TC_U32_KEY(n->handle) && n->action && n->action->type == TCA_OLD_COMPAT) { + if (tcf_action_copy_stats(skb,n->action)) + goto rtattr_failure; + } } #else #ifdef CONFIG_NET_CLS_POLICE @@ -875,6 +903,19 @@ static int __init init_u32(void) { + printk("u32 classifier\n"); +#ifdef CONFIG_CLS_U32_PERF + printk(" Perfomance counters on\n"); +#endif +#ifdef CONFIG_NET_CLS_POLICE + printk(" OLD policer on \n"); +#endif +#ifdef CONFIG_NET_CLS_IND + printk(" input device check on \n"); +#endif +#ifdef CONFIG_NET_CLS_ACT + printk(" Actions configured \n"); +#endif return register_tcf_proto_ops(&cls_u32_ops); } --- a/267-bk20-act+dummy/include/linux/pkt_cls.h 2004/07/24 12:35:40 1.1 +++ b/267-bk20-act+dummy/include/linux/pkt_cls.h 2004/07/28 18:38:01 @@ -117,17 +117,6 @@ struct tc_police { __u32 index; -#ifdef CONFIG_NET_CLS_ACT - int refcnt; - int bindcnt; -#endif -/* Turned off because it requires new tc - * to work (for now maintain ABI) - * -#ifdef CONFIG_NET_CLS_ACT - __u32 capab; -#endif -*/ int action; #define TC_POLICE_UNSPEC TC_ACT_UNSPEC #define TC_POLICE_OK TC_ACT_OK @@ -140,6 +129,9 @@ __u32 mtu; struct tc_ratespec rate; struct tc_ratespec peakrate; + int refcnt; + int bindcnt; + __u32 capab; }; struct tcf_t @@ -195,12 +187,9 @@ TCA_U32_DIVISOR, TCA_U32_SEL, TCA_U32_POLICE, -#ifdef CONFIG_NET_CLS_ACT TCA_U32_ACT, -#endif -#ifdef CONFIG_NET_CLS_IND TCA_U32_INDEV, -#endif + TCA_U32_PCNT, __TCA_U32_MAX }; @@ -212,9 +201,6 @@ __u32 val; int off; int offmask; -#ifdef CONFIG_CLS_U32_PERF - unsigned long kcnt; -#endif }; struct tc_u32_sel @@ -229,13 +215,17 @@ short hoff; __u32 hmask; -#ifdef CONFIG_CLS_U32_PERF - unsigned long rcnt; - unsigned long rhit; -#endif struct tc_u32_key keys[0]; }; +#ifdef CONFIG_CLS_U32_PERF +struct tc_u32_pcnt +{ + __u64 rcnt; + __u64 rhit; + __u64 kcnts[0]; +}; +#endif /* Flags */ #define TC_U32_TERMINAL 1 @@ -300,12 +290,8 @@ TCA_FW_UNSPEC, TCA_FW_CLASSID, TCA_FW_POLICE, -#ifdef CONFIG_NET_CLS_IND - TCA_FW_INDEV, -#endif -#ifdef CONFIG_NET_CLS_ACT - TCA_FW_ACT, -#endif + TCA_FW_INDEV, /* used by CONFIG_NET_CLS_IND */ + TCA_FW_ACT, /* used by CONFIG_NET_CLS_ACT */ __TCA_FW_MAX }; --=-ntp7cnPbJrTVEws5Jy23-- From hadi@cyberus.ca Thu Jul 29 04:30:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 04:30:13 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TBU8lR002723 for ; Thu, 29 Jul 2004 04:30:09 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072904301568:42253 ; Thu, 29 Jul 2004 04:30:15 -0700 Subject: Re: [PATCH] pkt_cls.h incompatiables From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com In-Reply-To: <1091100138.1044.549.camel@jzny.localdomain> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> <1090675993.1161.11.camel@jzny.localdomain> <20040724222853.752137d6.davem@redhat.com> <1091100138.1044.549.camel@jzny.localdomain> Organization: jamalopolis Message-Id: <1091100602.1043.557.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 07:30:02 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 04:30:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 04:30:17 AM, Serialize complete at 07/29/2004 04:30:17 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 7257 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 Patch was against 2.6.8-rc2 not bk20. cheers, jamal On Thu, 2004-07-29 at 07:22, jamal wrote: > On Sun, 2004-07-25 at 01:28, David S. Miller wrote: > > > Ok, I'll keep this in my inbox until you give the word. > > [Still trying to recover after all those conferences]. > > Heres a patch that passes all my regression tests. I use a > __u64 instead of u64 for perf counters since user space understands it. > > cheers, > jamal > > PS:- at some point we need to scrub the general backward compatibility > issues going forward. From herbert@gondor.apana.org.au Thu Jul 29 04:41:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 04:41:31 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TBf6xO003242 for ; Thu, 29 Jul 2004 04:41:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bq9HM-0006ug-00; Thu, 29 Jul 2004 21:40:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bq9HI-0004Bt-00; Thu, 29 Jul 2004 21:40:52 +1000 Date: Thu, 29 Jul 2004 21:40:52 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NET] Allow MD5 to be a module Message-ID: <20040729114052.GA16001@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I found that recent 2.6 kernels no longer allowed me to build MD5 as a module even though everything that used it were modules (including ipv6 and sctp). It turns out that there were boolean options selecting MD5 in the Kconfig files. Due to limitations in the current kconfig implementation, this forces MD5 to be a boolean as well. The usual workaround in these cases is to move the selection up to the closest tristate. This is what the following patch does. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=md5-module-patch ===== net/ipv6/Kconfig 1.8 vs edited ===== --- 1.8/net/ipv6/Kconfig 2003-08-09 19:14:55 +10:00 +++ edited/net/ipv6/Kconfig 2004-07-29 21:37:54 +10:00 @@ -4,8 +4,6 @@ config IPV6_PRIVACY bool "IPv6: Privacy Extensions (RFC 3041) support" depends on IPV6 - select CRYPTO - select CRYPTO_MD5 ---help--- Privacy Extensions for Stateless Address Autoconfiguration in IPv6 support. With this option, additional periodically-alter ===== net/sctp/Kconfig 1.12 vs edited ===== --- 1.12/net/sctp/Kconfig 2004-03-24 05:58:14 +11:00 +++ edited/net/sctp/Kconfig 2004-07-29 21:38:32 +10:00 @@ -8,6 +8,10 @@ config IP_SCTP tristate "The SCTP Protocol (EXPERIMENTAL)" depends on IPV6 || IPV6=n + select CRYPTO if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 + select CRYPTO_HMAC if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 + select CRYPTO_SHA1 if SCTP_HMAC_SHA1 + select CRYPTO_MD5 if SCTP_HMAC_MD5 ---help--- Stream Control Transmission Protocol @@ -71,18 +75,12 @@ config SCTP_HMAC_SHA1 bool "HMAC-SHA1" - select CRYPTO - select CRYPTO_HMAC - select CRYPTO_SHA1 help Enable the use of HMAC-SHA1 during association establishment. It is advised to use either HMAC-MD5 or HMAC-SHA1. config SCTP_HMAC_MD5 bool "HMAC-MD5" - select CRYPTO - select CRYPTO_HMAC - select CRYPTO_MD5 help Enable the use of HMAC-MD5 during association establishment. It is advised to use either HMAC-MD5 or HMAC-SHA1. ===== net/Kconfig 1.34 vs edited ===== --- 1.34/net/Kconfig 2004-04-06 08:22:50 +10:00 +++ edited/net/Kconfig 2004-07-29 21:37:54 +10:00 @@ -109,6 +109,8 @@ config IPV6 tristate "The IPv6 protocol (EXPERIMENTAL)" depends on INET && EXPERIMENTAL + select CRYPTO if IPV6_PRIVACY + select CRYPTO_MD5 if IPV6_PRIVACY ---help--- This is experimental support for the IP version 6 (formerly called IPng "IP next generation"). You will still be able to do --gKMricLos+KVdGMg-- From hadi@cyberus.ca Thu Jul 29 05:12:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 05:12:56 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TCCn5g006959 for ; Thu, 29 Jul 2004 05:12:49 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072905125728:42290 ; Thu, 29 Jul 2004 05:12:57 -0700 Subject: Re: [PATCH] (3/4) bridge linkstate handling From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , bridge@osdl.org, netdev@oss.sgi.com In-Reply-To: <20040728162413.0de73ea3@dell_ss3.pdx.osdl.net> References: <20040728162413.0de73ea3@dell_ss3.pdx.osdl.net> Organization: jamalopolis Message-Id: <1091103164.1046.591.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 08:12:44 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 05:12:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 05:12:58 AM, Serialize complete at 07/29/2004 05:12:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 7259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2004-07-28 at 19:24, Stephen Hemminger wrote: > This makes bridge port status reflect both the state of the interface > from software (up/down) and the carrier. It makes STP handle link failure > (cable breakage, etc). The original concept comes from a > Mark Ruijter who implemented it differently. > My way is simpler and requires no polling. > > Obviously, this link state detection will only work if the network card > handles the events properly. > nice. Does this entrench STP further in the kernel? Still planning to move it out to user space? cheers, jamal From hadi@znyx.com Thu Jul 29 06:16:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 06:16:41 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TDGYcZ010110 for ; Thu, 29 Jul 2004 06:16:34 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004072906164127:42338 ; Thu, 29 Jul 2004 06:16:41 -0700 Subject: Re: [PATCH] kill rtnl_exlock stubs From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com, Alexey In-Reply-To: <20040727095057.78c7419c@dell_ss3.pdx.osdl.net> References: <20040727095057.78c7419c@dell_ss3.pdx.osdl.net> Organization: ZNYX Networks Message-Id: <1091106988.1045.654.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 09:16:28 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 06:16:41 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 07/29/2004 06:16:43 AM, Serialize complete at 07/29/2004 06:16:43 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 7261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 800 Lines: 43 On Tue, 2004-07-27 at 12:50, Stephen Hemminger wrote: > @@ -404,13 +402,8 @@ > return -1; > } > > - if (kind != 2) { > - if (rtnl_exlock_nowait()) { > - *errp = 0; > - return -1; > - } > + if (kind != 2) > exclusive = 1; > - } > > memset(&rta, 0, sizeof(rta)); > > @@ -439,14 +432,10 @@ > goto err_inval; > err = link->doit(skb, nlh, (void *)&rta); > > - if (exclusive) > - rtnl_exunlock(); > *errp = err; > return err; > > err_inval: > - if (exclusive) > - rtnl_exunlock(); > *errp = -EINVAL; > return -1; > } This piece is the only one i would worry about. I dont remember the historical reasoning for rtnl_ex* I know its not useful as is right now. OTOH, if it was useful then the above code would have meant something. Dave/Alexey? cheers, jamal From DanE@aiinet.com Thu Jul 29 06:25:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 06:25:08 -0700 (PDT) Received: from aiexchange.ai.aiinet.com (ai181-26.aiinet.com [205.245.181.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TDP2Ce010736 for ; Thu, 29 Jul 2004 06:25:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] (3/4) bridge linkstate handling Date: Thu, 29 Jul 2004 09:24:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] (3/4) bridge linkstate handling Thread-Index: AcR1ZWR6/dWjVsnZQqSw9QfJJKX7mgABwyZQ From: "Eble, Dan" To: , "Stephen Hemminger" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6TDP2Ce010736 X-archive-position: 7262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: DanE@aiinet.com Precedence: bulk X-list: netdev Content-Length: 1125 Lines: 25 > > This makes bridge port status reflect both the > > state of the interface from software (up/down) > > and the carrier. It makes STP handle link failure > > (cable breakage, etc). > > nice. Does this entrench STP further in the kernel? > Still planning to move it out to user space? > Even if STP were implemented in user space, this part should be done in the kernel to make sure that there is no window of time for a packet to be received or transmitted after the link state changes. Cable failure is not the worst problem here. Imagine some dunce pulling out a cable, realizing he pulled the wrong one, and then plugging it back into the wrong port. If he has created a loop in the network, even a single packet getting through can cause problems. One could be really paranoid and flush the hardware transmit queue too. Is there a way to do that for a port from the bridge driver? (Or should the device drivers do that anyway after a link change?) Are there any ethernet controllers that can automatically disable tx/rx after a link change, requiring the driver to reenable them? That would also be useful. From hadi@cyberus.ca Thu Jul 29 07:32:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 07:33:00 -0700 (PDT) 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 i6TEWpUS013240 for ; Thu, 29 Jul 2004 07:32:54 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BqBxd-0006jt-LN for netdev@oss.sgi.com; Thu, 29 Jul 2004 10:32:45 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BqBxc-0006U3-AY; Thu, 29 Jul 2004 10:32:44 -0400 Subject: RE: [PATCH] (3/4) bridge linkstate handling From: jamal Reply-To: hadi@cyberus.ca To: "Eble, Dan" Cc: Stephen Hemminger , bridge@osdl.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1091111561.1021.17.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 10:32:41 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2118 Lines: 47 On Thu, 2004-07-29 at 09:24, Eble, Dan wrote: > > > This makes bridge port status reflect both the > > > state of the interface from software (up/down) > > > and the carrier. It makes STP handle link failure > > > (cable breakage, etc). > > > > nice. Does this entrench STP further in the kernel? > > Still planning to move it out to user space? > > > > Even if STP were implemented in user space, this part should be done in > the kernel to make sure that there is no window of time for a packet to > be received or transmitted after the link state changes. Cable failure > is not the worst problem here. Imagine some dunce pulling out a cable, > realizing he pulled the wrong one, and then plugging it back into the > wrong port. If he has created a loop in the network, even a single > packet getting through can cause problems. Your main problem there would be STP convergence time. Transfering the packet to user space and reacting should be several factors of magnitude faster than it takes STP to converge. The STP state should stay in the kernel. Control of it and BPDU handling is what i am suggesting to take out. > One could be really paranoid and flush the hardware transmit queue too. > Is there a way to do that for a port from the bridge driver? (Or should > the device drivers do that anyway after a link change?) A admin down/up should help via utilities like ifconfig. You are right though, there should be an optional scheme to flush the s/ware queues as well reset the device tx DMAs on link down. Note emphasis on optional. > Are there any ethernet controllers that can automatically disable tx/rx > after a link change, requiring the driver to reenable them? That would > also be useful. Havent heard of any; if any exist it should be optional. There could be use to continue a transmit right after pluging a cable back. Think of a single port TCP server. In general i think link management would be safer to decouple. As it is right now for capable drivers we have a multicast netlink msg being sent; should be able to listen to that and do something with result. cheers, jamal From hadi@cyberus.ca Thu Jul 29 07:43:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 07:43:33 -0700 (PDT) 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 i6TEhKit013762 for ; Thu, 29 Jul 2004 07:43:20 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BqC7l-00014L-Sv for netdev@oss.sgi.com; Thu, 29 Jul 2004 10:43:13 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BqC7k-00081K-9v; Thu, 29 Jul 2004 10:43:12 -0400 Subject: Re: [PATCH] kill rtnl_exlock stubs From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com, Alexey In-Reply-To: <1091106988.1045.654.camel@jzny.localdomain> References: <20040727095057.78c7419c@dell_ss3.pdx.osdl.net> <1091106988.1045.654.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1091112184.1022.26.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 10:43:04 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1486 Lines: 54 On Thu, 2004-07-29 at 09:16, Jamal Hadi Salim wrote: > On Tue, 2004-07-27 at 12:50, Stephen Hemminger wrote: > > > @@ -404,13 +402,8 @@ > > return -1; > > } > > > > - if (kind != 2) { > > - if (rtnl_exlock_nowait()) { > > - *errp = 0; > > - return -1; > > - } > > + if (kind != 2) > > exclusive = 1; > > - } > > > > memset(&rta, 0, sizeof(rta)); > > > > @@ -439,14 +432,10 @@ > > goto err_inval; > > err = link->doit(skb, nlh, (void *)&rta); > > > > - if (exclusive) > > - rtnl_exunlock(); > > *errp = err; > > return err; > > > > err_inval: > > - if (exclusive) > > - rtnl_exunlock(); > > *errp = -EINVAL; > > return -1; > > } > > This piece is the only one i would worry about. > I dont remember the historical reasoning for rtnl_ex* I know its not > useful as is right now. OTOH, if it was useful then the above code would > have meant something. Dave/Alexey? I think i may have figured it out. The rtnl_ex* seems to have been intended as more fine grain exclusive writer locking to the ->doit() functions which do make modifications to data. In other words if there are several rtnetlink sockets trying to modify the routing table, this would act as a serialization point. At the moment, the RTNL_SEM (grabbed around rtnetlink_rcv() viartnl_shlock_nowait ) seems to protect on this but its too fat a lock. So at some point we may need to clean it. Before you take my word on it, lets wait to hear from Alexey/Dave. cheers, jamal From DanE@aiinet.com Thu Jul 29 08:11:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:11:18 -0700 (PDT) Received: from aiexchange.ai.aiinet.com (ai181-26.aiinet.com [205.245.181.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFBBOR014704 for ; Thu, 29 Jul 2004 08:11:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] (3/4) bridge linkstate handling Date: Thu, 29 Jul 2004 11:11:02 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] (3/4) bridge linkstate handling Thread-Index: AcR1eOl+HPLL9ObYQ42Fvp9b95BGsAAAuoJQ From: "Eble, Dan" To: Cc: "Stephen Hemminger" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6TFBBOR014704 X-archive-position: 7265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: DanE@aiinet.com Precedence: bulk X-list: netdev Content-Length: 1021 Lines: 25 > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > > On Thu, 2004-07-29 at 09:24, Eble, Dan wrote: > > Even if STP were implemented in user space, this part > should be done in > > the kernel to make sure that there is no window of time for > a packet to > > be received or transmitted after the link state changes. > > Your main problem there would be STP convergence time. Transfering the > packet to user space and reacting should be several factors > of magnitude > faster than it takes STP to converge. > The STP state should stay in the kernel. Control of it and > BPDU handling > is what i am suggesting to take out. Is the time it takes STP to converge really the issue in this case? When a port loses and then regains carrier, it needs to enter the Blocking state without delay. If the carrier state change were handled by a daemon, the bridge driver would have some time to transmit or receive packets via that port before the daemon could tell it to block the port, wouldn't it? From ganesh.venkatesan@intel.com Thu Jul 29 08:42:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:42:31 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFgPHM019011 for ; Thu, 29 Jul 2004 08:42:25 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFhYbw006027; Thu, 29 Jul 2004 15:43:34 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFiBEW006097; Thu, 29 Jul 2004 15:44:16 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908421511712 ; Thu, 29 Jul 2004 08:42:15 -0700 Date: Thu, 29 Jul 2004 08:26:09 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 0/6 2.5] e100 driver update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 440 Lines: 16 Jeff: Following is a list of patches against the 2.6 tot for e100: 1 -- fix diagnostic test to restore current speed/duplex/autoneg settings after the completion of the diagnostic tests 2 -- Support for Intel(R) PRO/100 VE Network Connection (82562) adapter 3 -- fix errors in counting rx_length_errors and rx_over_errors 4 -- support for loading device firmware 5 -- Auto MDI/MDI-X Support 6 -- driver version change thanks, ganesh. From ganesh.venkatesan@intel.com Thu Jul 29 08:42:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:42:13 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFg5rg018927 for ; Thu, 29 Jul 2004 08:42:07 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFfQQn004822; Thu, 29 Jul 2004 15:41:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFbROj030216; Thu, 29 Jul 2004 15:37:27 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908415116134 ; Thu, 29 Jul 2004 08:41:51 -0700 Date: Thu, 29 Jul 2004 08:25:45 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 0/12 2.4] e1000 driver update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 916 Lines: 27 Jeff: Patches against 2.4 tot -- 1 -- ethtool support cleanup, register dump chacks controller type before dumping registers, interrupt diagnostic test addresses shared IRQ case 2 -- Enable TSO needs another patch to be submitted separately 3 -- replace kmalloc with vmalloc for data structures that are not shared with the hardware 4 -- TSO context descriptor setup fixes (in preparation for IPv6 TSO) 5 -- Fix to prevent infinite loop trying to re-establish link while actively attempting to communicate 6 -- Fix the condition that determines when to quit pollong mode to include work done in the Tx path 7 -- empty (not a patch) 8 -- Shutdown PHY while bringing the interface down (if WoL is not enabled) 9 -- add likely/unlikely to assist branch prediction, other cleanup 10 -- more DPRINTK messages 11 -- suspend/resume fix from alex@zodiac.dasalias.org 12 -- white space corrections thanks, ganesh. From ganesh.venkatesan@intel.com Thu Jul 29 08:42:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:42:46 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFgfmE019059 for ; Thu, 29 Jul 2004 08:42:41 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFhnv3007147; Thu, 29 Jul 2004 15:43:49 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFiWsB030077; Thu, 29 Jul 2004 15:45:13 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908422905468 ; Thu, 29 Jul 2004 08:42:29 -0700 Date: Thu, 29 Jul 2004 08:26:22 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 1/6 2.5] e100 - restore speed/duplex/autoneg settings after diagnostic test Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 981 Lines: 34 --- linux-2.5/drivers/net/e100.c 2004-07-29 00:23:31.781375960 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-07-29 00:24:52.375123848 -0700 @@ -1961,18 +1961,27 @@ static int e100_diag_test_count(struct n static void e100_diag_test(struct net_device *netdev, struct ethtool_test *test, u64 *data) { + struct ethtool_cmd cmd; struct nic *nic = netdev_priv(netdev); - int i; + int i, err; memset(data, 0, E100_TEST_LEN * sizeof(u64)); data[0] = !mii_link_ok(&nic->mii); data[1] = e100_eeprom_load(nic); if(test->flags & ETH_TEST_FL_OFFLINE) { + + /* save speed, duplex & autoneg settings */ + err = mii_ethtool_gset(&nic->mii, &cmd); + if(netif_running(netdev)) e100_down(nic); data[2] = e100_self_test(nic); data[3] = e100_loopback_test(nic, lb_mac); data[4] = e100_loopback_test(nic, lb_phy); + + /* restore speed, duplex & autoneg settings */ + err = mii_ethtool_sset(&nic->mii, &cmd); + if(netif_running(netdev)) e100_up(nic); } From ganesh.venkatesan@intel.com Thu Jul 29 08:40:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:40:24 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFeJBu018744 for ; Thu, 29 Jul 2004 08:40:19 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFgmTL018263; Thu, 29 Jul 2004 15:42:48 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFgksD028847; Thu, 29 Jul 2004 15:42:51 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908400405045 ; Thu, 29 Jul 2004 08:40:04 -0700 Date: Thu, 29 Jul 2004 08:23:58 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 0/12 2.5] e1000 driver update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 929 Lines: 25 Jeff: Patches against 2.5 tot -- 1 -- ethtool support cleanup, register dump chacks controller type before dumping registers, interrupt diagnostic test addresses shared IRQ case 2 -- Enable TSO needs another patch to be submitted separately 3 -- replace kmalloc with vmalloc for data structures that are not shared with the hardware 4 -- TSO context descriptor setup fixes (in preparation for IPv6 TSO) 5 -- Fix to prevent infinite loop trying to re-establish link while actively attempting to communicate 6 -- Fix the condition that determines when to quit pollong mode to include work done in the Tx path 7 -- use pci_dma_single_[for_device|for_cpu] 8 -- Shutdown PHY while bringing the interface down (if WoL is not enabled) 9 -- add likely/unlikely to assist branch prediction, other cleanup 10 -- more DPRINTK messages 11 -- suspend/resume fix from alex@zodiac.dasalias.org 12 -- white space corrections thanks, ganesh. From ganesh.venkatesan@intel.com Thu Jul 29 08:43:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:43:27 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFhNa6019475 for ; Thu, 29 Jul 2004 08:43:23 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFjsTL019843; Thu, 29 Jul 2004 15:45:54 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFi9Ew006052; Thu, 29 Jul 2004 15:45:11 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908431014869 ; Thu, 29 Jul 2004 08:43:10 -0700 Date: Thu, 29 Jul 2004 08:27:04 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 5/6 2.5] e100 - Auto MDI/MDI-X support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 945 Lines: 32 --- linux-2.5/drivers/net/e100.c 2004-07-29 00:28:31.783768664 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-07-29 00:28:57.405873512 -0700 @@ -333,11 +333,16 @@ enum eeprom_op { }; enum eeprom_offsets { + eeprom_cnfg_mdix = 0x03, eeprom_id = 0x0A, eeprom_config_asf = 0x0D, eeprom_smbus_addr = 0x90, }; +enum eeprom_cnfg_mdix { + eeprom_mdix_enabled = 0x0080, +}; + enum eeprom_id { eeprom_id_wol = 0x0020, }; @@ -1074,7 +1079,9 @@ static int e100_phy_init(struct nic *nic mdio_write(netdev, nic->mii.phy_id, MII_NSC_CONG, cong); } - if(nic->mac >= mac_82550_D102) + if((nic->mac >= mac_82550_D102) || ((nic->flags & ich) && + (mdio_read(netdev, nic->mii.phy_id, MII_TPISTATUS) & 0x8000) && + (nic->eeprom[eeprom_cnfg_mdix] & eeprom_mdix_enabled))) /* enable/disable MDI/MDI-X auto-switching */ mdio_write(netdev, nic->mii.phy_id, MII_NCONFIG, nic->mii.force_media ? 0 : NCONFIG_AUTO_SWITCH); From ganesh.venkatesan@intel.com Thu Jul 29 08:43:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:43:36 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFhVgG019488 for ; Thu, 29 Jul 2004 08:43:32 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFhh1M013110; Thu, 29 Jul 2004 15:43:43 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFi9F6006052; Thu, 29 Jul 2004 15:45:23 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908432214894 ; Thu, 29 Jul 2004 08:43:22 -0700 Date: Thu, 29 Jul 2004 08:27:16 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 6/6 2.5] e100 - driver version update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 507 Lines: 18 --- linux-2.5/drivers/net/e100.c 2004-07-29 00:29:00.291434840 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-07-29 00:29:27.438307888 -0700 @@ -158,7 +158,12 @@ #define DRV_NAME "e100" -#define DRV_VERSION "3.0.18" +#ifndef CONFIG_E100_NAPI +#define DRV_EXT +#else +#define DRV_EXT "-NAPI" +#endif +#define DRV_VERSION "3.0.27-k2"DRV_EXT #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" #define DRV_COPYRIGHT "Copyright(c) 1999-2004 Intel Corporation" #define PFX DRV_NAME ": " From ganesh.venkatesan@intel.com Thu Jul 29 08:43:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:43:46 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFhcKT019589 for ; Thu, 29 Jul 2004 08:43:40 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFgvQn005988; Thu, 29 Jul 2004 15:42:58 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFc7Op030869; Thu, 29 Jul 2004 15:38:44 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908430016420 ; Thu, 29 Jul 2004 08:43:00 -0700 Date: Thu, 29 Jul 2004 08:26:54 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 4/6 2.5] e100 - Support to load device firmware Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2019 Lines: 69 --- linux-2.5/drivers/net/e100.c 2004-07-29 00:27:31.495933808 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-07-29 00:28:30.382981616 -0700 @@ -353,10 +353,12 @@ enum cb_status { }; enum cb_command { + cb_nop = 0x0000, cb_iaaddr = 0x0001, cb_config = 0x0002, cb_multi = 0x0003, cb_tx = 0x0004, + cb_ucode = 0x0005, cb_dump = 0x0006, cb_tx_sf = 0x0008, cb_cid = 0x1f00, @@ -431,12 +433,14 @@ struct multi { }; /* Important: keep total struct u32-aligned */ +#define UCODE_SIZE 134 struct cb { u16 status; u16 command; u32 link; union { u8 iaaddr[ETH_ALEN]; + u32 ucode[UCODE_SIZE]; struct config config; struct multi multi; struct { @@ -984,6 +988,27 @@ static void e100_configure(struct nic *n c[16], c[17], c[18], c[19], c[20], c[21], c[22], c[23]); } +static void e100_load_ucode(struct nic *nic, struct cb *cb, struct sk_buff *skb) +{ + int i; + static const u32 ucode[UCODE_SIZE] = { + /* NFS packets are misinterpreted as TCO packets and + * incorrectly routed to the BMC over SMBus. This + * microcode patch checks the fragmented IP bit in the + * NFS/UDP header to distinguish between NFS and TCO. */ + 0x0EF70E36, 0x1FFF1FFF, 0x1FFF1FFF, 0x1FFF1FFF, 0x1FFF1FFF, + 0x1FFF1FFF, 0x00906E41, 0x00800E3C, 0x00E00E39, 0x00000000, + 0x00906EFD, 0x00900EFD, 0x00E00EF8, + }; + + if(nic->mac == mac_82551_F || nic->mac == mac_82551_10) { + for(i = 0; i < UCODE_SIZE; i++) + cb->u.ucode[i] = cpu_to_le32(ucode[i]); + cb->command = cpu_to_le16(cb_ucode); + } else + cb->command = cpu_to_le16(cb_nop); +} + static void e100_setup_iaaddr(struct nic *nic, struct cb *cb, struct sk_buff *skb) { @@ -1073,6 +1098,8 @@ static int e100_hw_init(struct nic *nic) return err; if((err = e100_exec_cmd(nic, ruc_load_base, 0))) return err; + if((err = e100_exec_cb(nic, NULL, e100_load_ucode))) + return err; if((err = e100_exec_cb(nic, NULL, e100_configure))) return err; if((err = e100_exec_cb(nic, NULL, e100_setup_iaaddr))) From ganesh.venkatesan@intel.com Thu Jul 29 08:44:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:44:34 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFiSnW020383 for ; Thu, 29 Jul 2004 08:44:29 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6T8ipT7001472; Thu, 29 Jul 2004 08:45:03 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFcOOj031221; Thu, 29 Jul 2004 15:38:32 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908424516361 ; Thu, 29 Jul 2004 08:42:46 -0700 Date: Thu, 29 Jul 2004 08:26:38 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 3/6 2.5] e100 - fix stat counters rx_length_error and rx_over_error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1337 Lines: 34 --- linux-2.5/drivers/net/e100.c 2004-07-29 00:26:06.001930872 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-07-29 00:27:27.360562480 -0700 @@ -551,6 +551,7 @@ struct nic { u32 rx_fc_pause; u32 rx_fc_unsupported; u32 rx_tco_frames; + u32 rx_over_length_errors; u8 rev_id; u16 leds; @@ -1146,9 +1147,11 @@ static void e100_update_stats(struct nic ns->tx_errors += le32_to_cpu(s->tx_max_collisions) + le32_to_cpu(s->tx_lost_crs); ns->rx_dropped += le32_to_cpu(s->rx_resource_errors); - ns->rx_length_errors += le32_to_cpu(s->rx_short_frame_errors); + ns->rx_length_errors += le32_to_cpu(s->rx_short_frame_errors) + + nic->rx_over_length_errors; ns->rx_crc_errors += le32_to_cpu(s->rx_crc_errors); ns->rx_frame_errors += le32_to_cpu(s->rx_alignment_errors); + ns->rx_over_errors += le32_to_cpu(s->rx_overrun_errors); ns->rx_fifo_errors += le32_to_cpu(s->rx_overrun_errors); ns->rx_errors += le32_to_cpu(s->rx_crc_errors) + le32_to_cpu(s->rx_alignment_errors) + @@ -1459,7 +1462,7 @@ static inline int e100_rx_indicate(struc dev_kfree_skb_any(skb); } else if(actual_size > nic->netdev->mtu + VLAN_ETH_HLEN) { /* Don't indicate oversized frames */ - nic->net_stats.rx_over_errors++; + nic->rx_over_length_errors++; nic->net_stats.rx_dropped++; dev_kfree_skb_any(skb); } else { From ganesh.venkatesan@intel.com Thu Jul 29 08:45:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:45:46 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFjdlM021120 for ; Thu, 29 Jul 2004 08:45:40 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFklv3008676; Thu, 29 Jul 2004 15:46:47 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFm6sB032530; Thu, 29 Jul 2004 15:48:14 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908452905887 ; Thu, 29 Jul 2004 08:45:29 -0700 Date: Thu, 29 Jul 2004 08:29:23 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 1/12 2.4] e1000 - ethtool support (register dump, interrupt test, cleanup) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 11239 Lines: 356 diff -up linux-2.4/drivers/net/e1000/e1000_ethtool.c linux-2.4/drivers/net/e1000.new/e1000_ethtool.c --- linux-2.4/drivers/net/e1000/e1000_ethtool.c 2004-07-28 08:47:08.171582912 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_ethtool.c 2004-07-28 08:47:09.432391240 -0700 @@ -88,13 +88,13 @@ static const struct e1000_stats e1000_gs { "rx_flow_control_xoff", E1000_STAT(stats.xoffrxc) }, { "tx_flow_control_xon", E1000_STAT(stats.xontxc) }, { "tx_flow_control_xoff", E1000_STAT(stats.xofftxc) }, + { "rx_long_byte_count", E1000_STAT(stats.gorcl) }, { "rx_csum_offload_good", E1000_STAT(hw_csum_good) }, - { "rx_csum_offload_errors", E1000_STAT(hw_csum_err) }, - { "rx_long_byte_count", E1000_STAT(stats.gorcl) } + { "rx_csum_offload_errors", E1000_STAT(hw_csum_err) } }; #define E1000_STATS_LEN \ sizeof(e1000_gstrings_stats) / sizeof(struct e1000_stats) -static char e1000_gstrings_test[][ETH_GSTRING_LEN] = { +static const char e1000_gstrings_test[][ETH_GSTRING_LEN] = { "Register test (offline)", "Eeprom test (offline)", "Interrupt test (offline)", "Loopback test (offline)", "Link test (on/offline)" @@ -170,7 +170,8 @@ e1000_get_settings(struct net_device *ne ecmd->duplex = -1; } - ecmd->autoneg = (hw->autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE); + ecmd->autoneg = ((hw->media_type == e1000_media_type_fiber) || + hw->autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE; return 0; } @@ -192,6 +193,7 @@ e1000_set_settings(struct net_device *ne if(netif_running(adapter->netdev)) { e1000_down(adapter); + e1000_reset(adapter); e1000_up(adapter); } else e1000_reset(adapter); @@ -199,12 +201,13 @@ e1000_set_settings(struct net_device *ne return 0; } -static void +static void e1000_get_pauseparam(struct net_device *netdev, - struct ethtool_pauseparam *pause) + struct ethtool_pauseparam *pause) { struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; + pause->autoneg = (adapter->fc_autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE); @@ -218,9 +221,9 @@ e1000_get_pauseparam(struct net_device * } } -static int +static int e1000_set_pauseparam(struct net_device *netdev, - struct ethtool_pauseparam *pause) + struct ethtool_pauseparam *pause) { struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; @@ -271,7 +274,7 @@ e1000_set_rx_csum(struct net_device *net e1000_reset(adapter); return 0; } - + static uint32_t e1000_get_tx_csum(struct net_device *netdev) { @@ -337,7 +340,7 @@ e1000_get_regs_len(struct net_device *ne static void e1000_get_regs(struct net_device *netdev, - struct ethtool_regs *regs, void *p) + struct ethtool_regs *regs, void *p) { struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; @@ -418,6 +421,10 @@ e1000_get_regs(struct net_device *netdev e1000_read_phy_reg(hw, PHY_1000T_STATUS, &phy_data); regs_buff[24] = (uint32_t)phy_data; /* phy local receiver status */ regs_buff[25] = regs_buff[24]; /* phy remote receiver status */ + if(hw->mac_type >= e1000_82540 && + hw->media_type == e1000_media_type_copper) { + regs_buff[26] = E1000_READ_REG(hw, MANC); + } } static int @@ -438,7 +445,7 @@ e1000_get_eeprom(struct net_device *netd int ret_val = 0; uint16_t i; - if(eeprom->len == 0) + if(eeprom->len == 0) return -EINVAL; eeprom->magic = hw->vendor_id | (hw->device_id << 16); @@ -446,9 +453,9 @@ e1000_get_eeprom(struct net_device *netd first_word = eeprom->offset >> 1; last_word = (eeprom->offset + eeprom->len - 1) >> 1; - eeprom_buff = kmalloc(sizeof(uint16_t) * + eeprom_buff = kmalloc(sizeof(uint16_t) * (last_word - first_word + 1), GFP_KERNEL); - if (!eeprom_buff) + if(!eeprom_buff) return -ENOMEM; if(hw->eeprom.type == e1000_eeprom_spi) @@ -466,9 +473,8 @@ e1000_get_eeprom(struct net_device *netd for (i = 0; i < last_word - first_word + 1; i++) le16_to_cpus(&eeprom_buff[i]); - - memcpy(bytes, (uint8_t *)eeprom_buff + (eeprom->offset%2), - eeprom->len); + memcpy(bytes, (uint8_t *)eeprom_buff + (eeprom->offset & 1), + eeprom->len); kfree(eeprom_buff); return ret_val; @@ -520,6 +526,7 @@ e1000_set_eeprom(struct net_device *netd le16_to_cpus(&eeprom_buff[i]); memcpy(ptr, bytes, eeprom->len); + for (i = 0; i < last_word - first_word + 1; i++) eeprom_buff[i] = cpu_to_le16(eeprom_buff[i]); @@ -575,17 +582,16 @@ static int e1000_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { - int err; struct e1000_adapter *adapter = netdev->priv; e1000_mac_type mac_type = adapter->hw.mac_type; struct e1000_desc_ring *txdr = &adapter->tx_ring; struct e1000_desc_ring *rxdr = &adapter->rx_ring; - struct e1000_desc_ring tx_old, tx_new; - struct e1000_desc_ring rx_old, rx_new; + struct e1000_desc_ring tx_old, tx_new, rx_old, rx_new; + int err; tx_old = adapter->tx_ring; rx_old = adapter->rx_ring; - + if(netif_running(adapter->netdev)) e1000_down(adapter); @@ -600,15 +606,15 @@ e1000_set_ringparam(struct net_device *n E1000_ROUNDUP(txdr->count, REQ_TX_DESCRIPTOR_MULTIPLE); if(netif_running(adapter->netdev)) { - /* try to get new resources before deleting old */ + /* Try to get new resources before deleting old */ if((err = e1000_setup_rx_resources(adapter))) goto err_setup_rx; if((err = e1000_setup_tx_resources(adapter))) goto err_setup_tx; /* save the new, restore the old in order to free it, - * then restore the new back again */ - + * then restore the new back again */ + rx_new = adapter->rx_ring; tx_new = adapter->tx_ring; adapter->rx_ring = rx_old; @@ -620,6 +626,7 @@ e1000_set_ringparam(struct net_device *n if((err = e1000_up(adapter))) return err; } + return 0; err_setup_tx: e1000_free_rx_resources(adapter); @@ -766,13 +773,15 @@ static int e1000_intr_test(struct e1000_adapter *adapter, uint64_t *data) { struct net_device *netdev = adapter->netdev; - uint32_t icr, mask, i=0; + uint32_t icr, mask, i=0, shared_int = TRUE; + uint32_t irq = adapter->pdev->irq; *data = 0; /* Hook up test interrupt handler just for this test */ - if(request_irq(adapter->pdev->irq, &e1000_test_intr, SA_SHIRQ, - netdev->name, netdev)) { + if(!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) { + shared_int = FALSE; + } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, netdev->name, netdev)){ *data = 1; return -1; } @@ -802,20 +811,22 @@ e1000_intr_test(struct e1000_adapter *ad /* Interrupt to test */ mask = 1 << i; - /* Disable the interrupt to be reported in - * the cause register and then force the same - * interrupt and see if one gets posted. If - * an interrupt was posted to the bus, the - * test failed. - */ - adapter->test_icr = 0; - E1000_WRITE_REG(&adapter->hw, IMC, mask); - E1000_WRITE_REG(&adapter->hw, ICS, mask); - msec_delay(10); - - if(adapter->test_icr & mask) { - *data = 3; - break; + if(!shared_int) { + /* Disable the interrupt to be reported in + * the cause register and then force the same + * interrupt and see if one gets posted. If + * an interrupt was posted to the bus, the + * test failed. + */ + adapter->test_icr = 0; + E1000_WRITE_REG(&adapter->hw, IMC, mask); + E1000_WRITE_REG(&adapter->hw, ICS, mask); + msec_delay(10); + + if(adapter->test_icr & mask) { + *data = 3; + break; + } } /* Enable the interrupt to be reported in @@ -834,20 +845,22 @@ e1000_intr_test(struct e1000_adapter *ad break; } - /* Disable the other interrupts to be reported in - * the cause register and then force the other - * interrupts and see if any get posted. If - * an interrupt was posted to the bus, the - * test failed. - */ - adapter->test_icr = 0; - E1000_WRITE_REG(&adapter->hw, IMC, ~mask); - E1000_WRITE_REG(&adapter->hw, ICS, ~mask); - msec_delay(10); + if(!shared_int) { + /* Disable the other interrupts to be reported in + * the cause register and then force the other + * interrupts and see if any get posted. If + * an interrupt was posted to the bus, the + * test failed. + */ + adapter->test_icr = 0; + E1000_WRITE_REG(&adapter->hw, IMC, ~mask); + E1000_WRITE_REG(&adapter->hw, ICS, ~mask); + msec_delay(10); - if(adapter->test_icr) { - *data = 5; - break; + if(adapter->test_icr) { + *data = 5; + break; + } } } @@ -856,7 +869,7 @@ e1000_intr_test(struct e1000_adapter *ad msec_delay(10); /* Unhook test interrupt handler */ - free_irq(adapter->pdev->irq, netdev); + free_irq(irq, netdev); return *data; } @@ -1020,7 +1033,7 @@ e1000_setup_desc_rings(struct e1000_adap return 0; - err_nomem: +err_nomem: e1000_free_desc_rings(adapter); return ret_val; } @@ -1356,7 +1369,7 @@ e1000_diag_test_count(struct net_device } static void -e1000_diag_test(struct net_device *netdev, +e1000_diag_test(struct net_device *netdev, struct ethtool_test *eth_test, uint64_t *data) { struct e1000_adapter *adapter = netdev->priv; @@ -1367,7 +1380,7 @@ e1000_diag_test(struct net_device *netde /* save speed, duplex, autoneg settings */ uint16_t autoneg_advertised = adapter->hw.autoneg_advertised; - uint8_t forced_speed_duplex = adapter->hw.forced_speed_duplex; + uint8_t forced_speed_duplex = adapter->hw.forced_speed_duplex; uint8_t autoneg = adapter->hw.autoneg; /* Link test performed before hardware reset so autoneg doesn't @@ -1395,10 +1408,11 @@ e1000_diag_test(struct net_device *netde if(e1000_loopback_test(adapter, &data[3])) eth_test->flags |= ETH_TEST_FL_FAILED; - /* restore Autoneg/speed/duplex settings */ + /* restore speed, duplex, autoneg settings */ adapter->hw.autoneg_advertised = autoneg_advertised; - adapter->hw.forced_speed_duplex = forced_speed_duplex; - adapter->hw.autoneg = autoneg; + adapter->hw.forced_speed_duplex = forced_speed_duplex; + adapter->hw.autoneg = autoneg; + e1000_reset(adapter); if(if_running) e1000_up(adapter); @@ -1426,6 +1440,7 @@ e1000_get_wol(struct net_device *netdev, case E1000_DEV_ID_82543GC_FIBER: case E1000_DEV_ID_82543GC_COPPER: case E1000_DEV_ID_82544EI_FIBER: + case E1000_DEV_ID_82546EB_QUAD_COPPER: wol->supported = 0; wol->wolopts = 0; return; @@ -1468,6 +1483,7 @@ e1000_set_wol(struct net_device *netdev, case E1000_DEV_ID_82543GC_FIBER: case E1000_DEV_ID_82543GC_COPPER: case E1000_DEV_ID_82544EI_FIBER: + case E1000_DEV_ID_82546EB_QUAD_COPPER: return wol->wolopts ? -EOPNOTSUPP : 0; case E1000_DEV_ID_82546EB_FIBER: @@ -1570,8 +1586,8 @@ e1000_get_ethtool_stats(struct net_devic e1000_update_stats(adapter); for(i = 0; i < E1000_STATS_LEN; i++) { char *p = (char *)adapter+e1000_gstrings_stats[i].stat_offset; - data[i] = (e1000_gstrings_stats[i].sizeof_stat == sizeof(uint64_t)) - ? *(uint64_t *)p : *(uint32_t *)p; + data[i] = (e1000_gstrings_stats[i].sizeof_stat == + sizeof(uint64_t)) ? *(uint64_t *)p : *(uint32_t *)p; } } From ganesh.venkatesan@intel.com Thu Jul 29 08:45:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:45:47 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFjTxZ021066 for ; Thu, 29 Jul 2004 08:45:29 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFkZv3008578; Thu, 29 Jul 2004 15:46:35 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFiiBP020357; Thu, 29 Jul 2004 15:45:08 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908451205846 ; Thu, 29 Jul 2004 08:45:12 -0700 Date: Thu, 29 Jul 2004 08:29:06 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 1/1 2.4] e100 - upgrade 2.4 tree to include 3.0.x version of e100 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2037997309-179616242-1091110109=:21929" Content-ID: X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 122102 Lines: 1976 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2037997309-179616242-1091110109=:21929 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Attached. ---2037997309-179616242-1091110109=:21929 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="p1.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="p1.diff" LS0tIC9tbnQvc3RvcmFnZS9CSy9saW51eC0yLjQvRG9jdW1lbnRhdGlvbi9u ZXR3b3JraW5nL2UxMDAudHh0CTIwMDQtMDItMTIgMTQ6MzU6MzguMDAwMDAw MDAwIC0wODAwDQorKysgbGludXgtMi40LjI3LXJjMy9Eb2N1bWVudGF0aW9u L25ldHdvcmtpbmcvZTEwMC50eHQJMjAwNC0wNy0yOCAyMToyMTozMS40Mjc1 MjIwODggLTA3MDANCkBAIC0xLDIzMiArMSwxMzMgQEANCiBMaW51eCogQmFz ZSBEcml2ZXIgZm9yIHRoZSBJbnRlbChSKSBQUk8vMTAwIEZhbWlseSBvZiBB ZGFwdGVycw0KID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogDQotTm92ZW1iZXIgMTks IDIwMDINCi0NCitKdWx5IDEyLCAyMDA0DQogDQogQ29udGVudHMNCiA9PT09 PT09PQ0KIA0KIC0gSW4gVGhpcyBSZWxlYXNlDQogLSBTdXBwb3J0ZWQgQWRh cHRlcnMNCi0tIENvbW1hbmQgTGluZSBQYXJhbWV0ZXJzDQotLSBDUFUgQ3lj bGUgU2F2ZXINCistIERyaXZlciBDb25maWd1cmF0aW9uIFBhcmFtZXRlcnMN CiAtIEFkZGl0aW9uYWwgQ29uZmlndXJhdGlvbnMNCiAtIFN1cHBvcnQNCiAN Ci0NCiBJbiBUaGlzIFJlbGVhc2UNCiA9PT09PT09PT09PT09PT0NCiANCiBU aGlzIGZpbGUgZGVzY3JpYmVzIHRoZSBMaW51eCogQmFzZSBEcml2ZXIgZm9y IHRoZSBJbnRlbChSKSBQUk8vMTAwIEZhbWlseSBvZg0KLUFkYXB0ZXJzLCB2 ZXJzaW9uIDIuMi54LiAgVGhpcyBkcml2ZXIgaW5jbHVkZXMgc3VwcG9ydCBm b3IgSXRhbml1bShUTSktYmFzZWQgDQorQWRhcHRlcnMsIHZlcnNpb24gMy4w LnguIFRoaXMgZHJpdmVyIGluY2x1ZGVzIHN1cHBvcnQgZm9yIEl0YW5pdW0o VE0pLWJhc2VkIA0KIHN5c3RlbXMuDQogDQorRm9yIHF1ZXN0aW9ucyByZWxh dGVkIHRvIGhhcmR3YXJlIHJlcXVpcmVtZW50cywgcmVmZXIgdG8gdGhlIGRv Y3VtZW50YXRpb24NCitzdXBwbGllZCB3aXRoIHlvdXIgSW50ZWwgUFJPLzEw MCBhZGFwdGVyLg0KIA0KIFN1cHBvcnRlZCBBZGFwdGVycw0KID09PT09PT09 PT09PT09PT09PQ0KIA0KLVRoZSBmb2xsb3dpbmcgSW50ZWwgbmV0d29yayBh ZGFwdGVycyBhcmUgY29tcGF0aWJsZSB3aXRoIHRoZSBkcml2ZXJzIA0KLWlu IHRoaXMgcmVsZWFzZToNCi0NCi1Db250cm9sbGVyICBBZGFwdGVyIE5hbWUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQm9hcmQgSURzDQotLS0tLS0t LS0tLSAgLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tLS0tLS0tLQ0KLQ0KLTgyNTU4ICAgICAgIFBSTy8xMDArIFBDSSBBZGFw dGVyICAgICAgICAgICAgICAgICAgICA2NjgwODEteHh4LCA2ODk2NjEteHh4 DQotDQotODI1NTggICAgICAgUFJPLzEwMCsgTWFuYWdlbWVudCBBZGFwdGVy ICAgICAgICAgICAgIDY5MTMzNC14eHgsIDcwMTczOC14eHgsDQotICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDcyMTM4My14eHgNCi0NCi04MjU1OCAgICAgICBQUk8vMTAwKyBEdWFsIFBv cnQgU2VydmVyIEFkYXB0ZXIgICAgICAgNzE0MzAzLXh4eCwgNzExMjY5LXh4 eCwgDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEEyODI3Ni14eHgNCi0NCi04MjU1OCAgICAgICBQUk8v MTAwKyBQQ0kgU2VydmVyIEFkYXB0ZXIgICAgICAgICAgICAgNzEwNTUwLXh4 eA0KK1RvIHZlcmlmeSB0aGF0IHlvdXIgYWRhcHRlciBpcyBzdXBwb3J0ZWQs IGZpbmQgdGhlIGJvYXJkIElEIG51bWJlciBvbiB0aGUgDQorYWRhcHRlci4g TG9vayBmb3IgYSBsYWJlbCB0aGF0IGhhcyBhIGJhcmNvZGUgYW5kIGEgbnVt YmVyIGluIHRoZSBmb3JtYXQgDQorQTEyMzQ1LTAwMS4gDQogDQotODI1NTAg ICAgICAgUFJPLzEwMCBTIFNlcnZlciBBZGFwdGVyICAgICAgICAgICAgICAg IDc1MjQzOC14eHggKDgyNTUwKQ0KLTgyNTU5ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBNTY4MzEteHh4LCBBMTA1 NjMteHh4LA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBMTIxNzEteHh4LCBBMTIzMjEteHh4LCANCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQTEyMzIwLXh4eCwgQTEyMTcwLXh4eA0KLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3NDg1Njgt eHh4ICg4MjU1OSkNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgNzQ4NTY1LXh4eCAoODI1NTkpDQorRm9y IG1vcmUgaW5mb3JtYXRpb24gb24gaG93IHRvIGlkZW50aWZ5IHlvdXIgYWRh cHRlciwgZ28gdG8gdGhlIEFkYXB0ZXIgJiANCitEcml2ZXIgSUQgR3VpZGUg YXQ6DQogDQorICBodHRwOi8vc3VwcG9ydC5pbnRlbC5jb20vc3VwcG9ydC9u ZXR3b3JrL2FkYXB0ZXIvcHJvMTAwLzIxMzk3Lmh0bQ0KIA0KLTgyNTUwICAg ICAgIFBSTy8xMDAgUyBEZXNrdG9wIEFkYXB0ZXIgICAgICAgICAgICAgICA3 NTE3NjcteHh4ICg4MjU1MCkNCi04MjU1OSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgNzQ4NTkyLXh4eCwgQTEyMTY3 LXh4eCwgDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEExMjMxOC14eHgsIEExMjMxNy14eHgsIA0KLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBMTIxNjUteHh4DQotICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDc0ODU2OS14eHggKDgyNTU5KQ0K K0ZvciB0aGUgbGF0ZXN0IEludGVsIG5ldHdvcmsgZHJpdmVycyBmb3IgTGlu dXgsIHJlZmVyIHRvIHRoZSBmb2xsb3dpbmcgDQord2Vic2l0ZS4gSW4gdGhl IHNlYXJjaCBmaWVsZCwgZW50ZXIgeW91ciBhZGFwdGVyIG5hbWUgb3IgdHlw ZSwgb3IgdXNlIHRoZSANCituZXR3b3JraW5nIGxpbmsgb24gdGhlIGxlZnQg dG8gc2VhcmNoIGZvciB5b3VyIGFkYXB0ZXI6DQogDQorICBodHRwOi8vZG93 bmxvYWRmaW5kZXIuaW50ZWwuY29tL3NjcmlwdHMtZGYvc3VwcG9ydF9pbnRl bC5hc3ANCiANCitEcml2ZXIgQ29uZmlndXJhdGlvbiBQYXJhbWV0ZXJzDQor PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIA0KLTgyNTU5ICAg ICAgIFBSTy8xMDArIFNlcnZlciBBZGFwdGVyICAgICAgICAgICAgICAgICA3 Mjk3NTcteHh4DQorVGhlIGRlZmF1bHQgdmFsdWUgZm9yIGVhY2ggcGFyYW1l dGVyIGlzIGdlbmVyYWxseSB0aGUgcmVjb21tZW5kZWQgc2V0dGluZywNCit1 bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkLg0KIA0KLTgyNTU5ICAgICAgIFBSTy8x MDAgUyBNYW5hZ2VtZW50IEFkYXB0ZXIgICAgICAgICAgICA3NDg1NjYteHh4 LCA3NDg1NjQteHh4DQorUnggRGVzY3JpcHRvcnM6IE51bWJlciBvZiByZWNl aXZlIGRlc2NyaXB0b3JzLiBBIHJlY2VpdmUgZGVzY3JpcHRvciBpcyBhIGRh dGEgDQorICAgc3RydWN0dXJlIHRoYXQgZGVzY3JpYmVzIGEgcmVjZWl2ZSBi dWZmZXIgYW5kIGl0cyBhdHRyaWJ1dGVzIHRvIHRoZSBuZXR3b3JrIA0KKyAg IGNvbnRyb2xsZXIuIFRoZSBkYXRhIGluIHRoZSBkZXNjcmlwdG9yIGlzIHVz ZWQgYnkgdGhlIGNvbnRyb2xsZXIgdG8gd3JpdGUgDQorICAgZGF0YSBmcm9t IHRoZSBjb250cm9sbGVyIHRvIGhvc3QgbWVtb3J5LiBJbiB0aGUgMy4wLngg ZHJpdmVyIHRoZSB2YWxpZCByYW5nZQ0KKyAgIGZvciB0aGlzIHBhcmFtZXRl ciBpcyA2NC0yNTYuIFRoZSBkZWZhdWx0IHZhbHVlIGlzIDY0LiBUaGlzIHBh cmFtZXRlciBjYW4gYmUgDQorICAgY2hhbmdlZCB1c2luZyB0aGUgY29tbWFu ZCANCisgDQorICAgZXRodG9vbCAtRyBldGg/IHJ4IG4sIHdoZXJlIG4gaXMg dGhlIG51bWJlciBvZiBkZXNpcmVkIHJ4IGRlc2NyaXB0b3JzLg0KIA0KLTgy NTUwICAgICAgIFBSTy8xMDAgUyBEdWFsIFBvcnQgU2VydmVyIEFkYXB0ZXIg ICAgICBBNTY4MzEteHh4DQorVHggRGVzY3JpcHRvcnM6IE51bWJlciBvZiB0 cmFuc21pdCBkZXNjcmlwdG9ycy4gQSB0cmFuc21pdCBkZXNjcmlwdG9yIGlz IGEgZGF0YSANCisgICBzdHJ1Y3R1cmUgdGhhdCBkZXNjcmliZXMgYSB0cmFu c21pdCBidWZmZXIgYW5kIGl0cyBhdHRyaWJ1dGVzIHRvIHRoZSBuZXR3b3Jr IA0KKyAgIGNvbnRyb2xsZXIuIFRoZSBkYXRhIGluIHRoZSBkZXNjcmlwdG9y IGlzIHVzZWQgYnkgdGhlIGNvbnRyb2xsZXIgdG8gcmVhZCANCisgICBkYXRh IGZyb20gdGhlIGhvc3QgbWVtb3J5IHRvIHRoZSBjb250cm9sbGVyLiBJbiB0 aGUgMy4wLnggZHJpdmVyIHRoZSB2YWxpZCANCisgICByYW5nZSBmb3IgdGhp cyBwYXJhbWV0ZXIgaXMgNjQtMjU2LiBUaGUgZGVmYXVsdCB2YWx1ZSBpcyA2 NC4gVGhpcyBwYXJhbWV0ZXIgDQorICAgY2FuIGJlIGNoYW5nZWQgdXNpbmcg dGhlIGNvbW1hbmQgDQogDQotODI1NTEgICAgICAgUFJPLzEwMCBNIERlc2t0 b3AgQWRhcHRlciAgICAgICAgICAgICAgIEE4MDg5Ny14eHgNCisgICBldGh0 b29sIC1HIGV0aD8gdHggbiwgd2hlcmUgbiBpcyB0aGUgbnVtYmVyIG9mIGRl c2lyZWQgdHggZGVzY3JpcHRvcnMuDQogDQotICAgICAgICAgICAgUFJPLzEw MCBTIEFkdmFuY2VkIE1hbmFnZW1lbnQgQWRhcHRlciAgIDc0Nzg0Mi14eHgs IDc0NTE3MS14eHgNCitTcGVlZC9EdXBsZXg6IFRoZSBkcml2ZXIgYXV0by1u ZWdvdGlhdGVzIHRoZSBsaW5rIHNwZWVkIGFuZCBkdXBsZXggc2V0dGluZ3Mg YnkgDQorICAgZGVmYXVsdC4gRXRodG9vbCBjYW4gYmUgdXNlZCBhcyBmb2xs b3dzIHRvIGZvcmNlIHNwZWVkL2R1cGxleC4gDQogDQotQ05SICAgICAgICAg UFJPLzEwMCBWRSBEZXNrdG9wIEFkYXB0ZXIgICAgICAgICAgICAgIEExMDM4 Ni14eHgsIEExMDcyNS14eHgsIA0KLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBMjM4MDEteHh4LCBBMTk3 MTYteHh4DQorICAgZXRodG9vbCAtcyBldGg/ICBhdXRvbmVnIG9mZiBzcGVl ZCB7MTB8MTAwfSBkdXBsZXgge2Z1bGx8aGFsZn0NCiANCisgICBOT1RFOiBz ZXR0aW5nIHRoZSBzcGVlZC9kdXBsZXggdG8gaW5jb3JyZWN0IHZhbHVlcyB3 aWxsIGNhdXNlIHRoZSBsaW5rIHRvIA0KKyAgIGZhaWwuDQogDQotICAgICAg ICAgICAgUFJPLzEwMCBWTSBEZXNrdG9wIEFkYXB0ZXIgICAgICAgICAgICAg IEExNDMyMy14eHgsIEExOTcyNS14eHgsIA0KLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBMjM4MDEteHh4 LCBBMjIyMjAteHh4LCANCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQTIzNzk2LXh4eA0KLSAgIA0KK0V2 ZW50IExvZyBNZXNzYWdlIExldmVsOiAgVGhlIGRyaXZlciB1c2VzIHRoZSBt ZXNzYWdlIGxldmVsIGZsYWcgdG8gbG9nIGV2ZW50cyANCisgICB0byBzeXNs b2cuIFRoZSBtZXNzYWdlIGxldmVsIGNhbiBiZSBzZXQgYXQgZHJpdmVyIGxv YWQgdGltZS4gSXQgY2FuIGFsc28gYmUgDQorICAgc2V0IHVzaW5nIHRoZSBj b21tYW5kDQogDQotVG8gdmVyaWZ5IHRoYXQgeW91ciBhZGFwdGVyIGlzIHN1 cHBvcnRlZCwgZmluZCB0aGUgYm9hcmQgSUQgbnVtYmVyIG9uIHRoZSANCi1h ZGFwdGVyLiBMb29rIGZvciBhIGxhYmVsIHRoYXQgaGFzIGEgYmFyY29kZSBh bmQgYSBudW1iZXIgaW4gdGhlIGZvcm1hdCANCi1BMTIzNDUtMDAxLiBNYXRj aCB0aGlzIHRvIHRoZSBsaXN0IG9mIG51bWJlcnMgYWJvdmUuDQorICAgZXRo dG9vbCAtcyBldGg/IG1zZ2x2bCBuDQogDQotRm9yIG1vcmUgaW5mb3JtYXRp b24gb24gaG93IHRvIGlkZW50aWZ5IHlvdXIgYWRhcHRlciwgZ28gdG8gdGhl IEFkYXB0ZXIgJiANCi1Ecml2ZXIgSUQgR3VpZGUgYXQ6DQorQWRkaXRpb25h bCBDb25maWd1cmF0aW9ucw0KKz09PT09PT09PT09PT09PT09PT09PT09PT0N CiANCi0gIGh0dHA6Ly9zdXBwb3J0LmludGVsLmNvbS9zdXBwb3J0L25ldHdv cmsvYWRhcHRlci9wcm8xMDAvMjEzOTcuaHRtDQorICBWaWV3aW5nIExpbmsg TWVzc2FnZXMNCisgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KKyAgSW4gb3Jk ZXIgdG8gc2VlIGxpbmsgbWVzc2FnZXMgYW5kIG90aGVyIEludGVsIGRyaXZl ciBpbmZvcm1hdGlvbiBvbiB5b3VyIA0KKyAgY29uc29sZSwgeW91IG11c3Qg c2V0IHRoZSBkbWVzZyBsZXZlbCB1cCB0byBzaXguIFRoaXMgY2FuIGJlIGRv bmUgYnkgDQorICBlbnRlcmluZyB0aGUgZm9sbG93aW5nIG9uIHRoZSBjb21t YW5kIGxpbmUgYmVmb3JlIGxvYWRpbmcgdGhlIGUxMDAgZHJpdmVyOiANCiAN Ci1Gb3IgdGhlIGxhdGVzdCBJbnRlbCBQUk8vMTAwIG5ldHdvcmsgZHJpdmVy IGZvciBMaW51eCwgc2VlOg0KKyAgICAgICBkbWVzZyAtbiA4DQogDQotICBo dHRwOi8vZG93bmxvYWRmaW5kZXIuaW50ZWwuY29tL3NjcmlwdHMtZGYvc3Vw cG9ydF9pbnRlbC5hc3ANCisgIElmIHlvdSB3aXNoIHRvIHNlZSBhbGwgbWVz c2FnZXMgaXNzdWVkIGJ5IHRoZSBkcml2ZXIsIGluY2x1ZGluZyBkZWJ1ZyAN CisgIG1lc3NhZ2VzLCBzZXQgdGhlIGRtZXNnIGxldmVsIHRvIGVpZ2h0Lg0K IA0KKyAgTk9URTogVGhpcyBzZXR0aW5nIGlzIG5vdCBzYXZlZCBhY3Jvc3Mg cmVib290cy4NCiANCi1Db21tYW5kIExpbmUgUGFyYW1ldGVycw0KLT09PT09 PT09PT09PT09PT09PT09PT09DQorICBFdGh0b29sDQorICAtLS0tLS0tDQog DQotSWYgdGhlIGRyaXZlciBpcyBidWlsdCBhcyBhIG1vZHVsZSwgdGhlICBm b2xsb3dpbmcgb3B0aW9uYWwgcGFyYW1ldGVycyBhcmUgDQotdXNlZCBieSBl bnRlcmluZyB0aGVtIG9uIHRoZSBjb21tYW5kIGxpbmUgd2l0aCB0aGUgbW9k cHJvYmUgb3IgaW5zbW9kIGNvbW1hbmQNCi11c2luZyB0aGlzIHN5bnRheDoN CisgIFRoZSBkcml2ZXIgdXRpbGl6ZXMgdGhlIGV0aHRvb2wgaW50ZXJmYWNl IGZvciBkcml2ZXIgY29uZmlndXJhdGlvbiBhbmQNCisgIGRpYWdub3N0aWNz LCBhcyB3ZWxsIGFzIGRpc3BsYXlpbmcgc3RhdGlzdGljYWwgaW5mb3JtYXRp b24uICBFdGh0b29sDQorICB2ZXJzaW9uIDEuNiBvciBsYXRlciBpcyByZXF1 aXJlZCBmb3IgdGhpcyBmdW5jdGlvbmFsaXR5Lg0KIA0KLSAgICAgbW9kcHJv YmUgZTEwMCBbPG9wdGlvbj49PFZBTDE+LDxWQUwyPiwuLi5dDQorICBUaGUg bGF0ZXN0IHJlbGVhc2Ugb2YgZXRodG9vbCBjYW4gYmUgZm91bmQgYXQ6DQor ICBodHRwOi8vc2YubmV0L3Byb2plY3RzL2drZXJuZWwuICANCiANCi0gICAg IGluc21vZCBlMTAwIFs8b3B0aW9uPj08VkFMMT4sPFZBTDI+LC4uLl0gDQor ICBBZnRlciBldGh0b29sIGlzIGluc3RhbGxlZCwgZXRodG9vbC1jb3B5Lmgg bXVzdCBiZSBjb3BpZWQgYW5kIHJlbmFtZWQgdG8NCisgIGV0aHRvb2wuaCBp biB5b3VyIGtlcm5lbCBzb3VyY2UgdHJlZSBhdCA8bGludXhfa2VybmVsX3Ny Yz4vaW5jbHVkZS9saW51eC4gIA0KKyAgQmFja3VwIHRoZSBvcmlnaW5hbCBl dGh0b29sLmggYXMgbmVlZGVkIGJlZm9yZSBjb3B5aW5nLiAgVGhlIGRyaXZl ciB0aGVuIA0KKyAgbXVzdCBiZSByZWNvbXBpbGVkIGluIG9yZGVyIHRvIHRh a2UgYWR2YW50YWdlIG9mIHRoZSBsYXRlc3QgZXRodG9vbCANCisgIGZlYXR1 cmVzLg0KIA0KLUZvciBleGFtcGxlLCB3aXRoIHR3byBJbnRlbCBQUk8vMTAw IFBDSSBhZGFwdGVycywgZW50ZXJpbmc6DQotCQ0KLSAgICAgbW9kcHJvYmUg ZTEwMCBUeERlc2NyaXB0b3JzPTMyLDEyOA0KKyAgTk9URTogVGhpcyBkcml2 ZXIgdXNlcyBtaWkgc3VwcG9ydCBmcm9tIHRoZSBrZXJuZWwuIEFzIGEgcmVz dWx0LCB3aGVuIA0KKyAgdGhlcmUgaXMgbm8gbGluaywgZXRodG9vbCB3aWxs IHJlcG9ydCBzcGVlZC9kdXBsZXggdG8gYmUgMTAvaGFsZi4NCiANCi1sb2Fk cyB0aGUgZTEwMCBkcml2ZXIgd2l0aCAzMiBUWCByZXNvdXJjZXMgZm9yIHRo ZSBmaXJzdCBhZGFwdGVyIGFuZCAxMjggVFggDQotcmVzb3VyY2VzIGZvciB0 aGUgc2Vjb25kIGFkYXB0ZXIuIFRoaXMgY29uZmlndXJhdGlvbiBmYXZvcnMg dGhlIHNlY29uZCANCi1hZGFwdGVyLiBUaGUgZHJpdmVyIHN1cHBvcnRzIHVw IHRvIDE2IG5ldHdvcmsgYWRhcHRlcnMgY29uY3VycmVudGx5Lg0KKyAgTk9U RTogRXRodG9vbCAxLjYgb25seSBzdXBwb3J0cyBhIGxpbWl0ZWQgc2V0IG9m IGV0aHRvb2wgb3B0aW9ucy4gU3VwcG9ydCANCisgIGZvciBhIG1vcmUgY29t cGxldGUgZXRodG9vbCBmZWF0dXJlIHNldCBjYW4gYmUgZW5hYmxlZCBieSB1 cGdyYWRpbmcgDQorICBldGh0b29sIHRvIGV0aHRvb2wtMS44LjEuIA0KIA0K LVRoZSBkZWZhdWx0IHZhbHVlIGZvciBlYWNoIHBhcmFtZXRlciBpcyBnZW5l cmFsbHkgdGhlIHJlY29tbWVuZGVkIHNldHRpbmcsDQotdW5sZXNzIG90aGVy d2lzZSBub3RlZC4NCisgIEVuYWJsaW5nIFdha2Ugb24gTEFOKiAoV29MKQ0K KyAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQorICBXb0wgaXMgcHJv dmlkZWQgdGhyb3VnaCB0aGUgRXRodG9vbCogdXRpbGl0eS4gRXRodG9vbCBp cyBpbmNsdWRlZCB3aXRoIFJlZCANCisgIEhhdCogOC4wLiBGb3Igb3RoZXIg TGludXggZGlzdHJpYnV0aW9ucywgZG93bmxvYWQgYW5kIGluc3RhbGwgRXRo dG9vbCBmcm9tIA0KKyAgdGhlIGZvbGxvd2luZyB3ZWJzaXRlOiBodHRwOi8v c291cmNlZm9yZ2UubmV0L3Byb2plY3RzL2drZXJuZWwuIA0KIA0KLU5PVEU6 IEdpdmluZyBhbnkgY29tbWFuZCBsaW5lIG9wdGlvbiB0aGUgdmFsdWUgIi0x IiBjYXVzZXMgdGhlIGRyaXZlciB0byB1c2UgDQotICAgICAgdGhlIGFwcHJv cHJpYXRlIGRlZmF1bHQgdmFsdWUgZm9yIHRoYXQgb3B0aW9uLCBhcyBpZiBu byB2YWx1ZSB3YXMgDQotICAgICAgc3BlY2lmaWVkLg0KLQ0KLQ0KLUJ1bmRs ZU1heA0KLVZhbGlkIFJhbmdlOiAxLTY1NTM1DQotRGVmYXVsdCBWYWx1ZTog Ng0KLSAgIFRoaXMgcGFyYW1ldGVyIGhvbGRzIHRoZSBtYXhpbXVtIG51bWJl ciBvZiBzbWFsbCBwYWNrZXRzIChsZXNzIHRoYW4gMTI4DQotICAgYnl0ZXMp IGluIGEgYnVuZGxlLiBTdWdnZXN0ZWQgdmFsdWVzIHJhbmdlIGZyb20gMiB0 byAxMC4gU2VlICJDUFUgQ3ljbGUgDQotICAgU2F2ZXIuIg0KLQ0KLUJ1bmRs ZVNtYWxsRnINCi1WYWxpZCBSYW5nZTogMC0xICgwPW9mZiwgMT1vbikNCi1E ZWZhdWx0IFZhbHVlOiAwDQotICAgVGhlIHZhbHVlIDEgKG9uKSBjYXVzZXMg c21hbGwgcGFja2V0cyAobGVzcyB0aGFuIDEyOCBieXRlcykgdG8gYmUgYnVu ZGxlZC4gDQotICAgU2VlICJDUFUgQ3ljbGUgU2F2ZXIuIg0KLQ0KLWUxMDBf c3BlZWRfZHVwbGV4DQotVmFsaWQgUmFuZ2U6IDAtNCAoMT0xMGhhbGY7Mj0x MGZ1bGw7Mz0xMDBoYWxmOzQ9MTAwZnVsbCkNCi1EZWZhdWx0IFZhbHVlOiAw DQotICAgVGhlIGRlZmF1bHQgdmFsdWUgb2YgMCBzZXRzIHRoZSBhZGFwdGVy IHRvIGF1dG8tbmVnb3RpYXRlLiBPdGhlciB2YWx1ZXMNCi0gICBzZXQgdGhl IGFkYXB0ZXIgdG8gZm9yY2VkIHNwZWVkIGFuZCBkdXBsZXguIA0KLSAgIEV4 YW1wbGUgdXNhZ2U6IGluc21vZCBlMTAwLm8gZTEwMF9zcGVlZF9kdXBsZXg9 NCw0IChmb3IgdHdvIGFkYXB0ZXJzKQ0KLQ0KLWZsb3dfY29udHJvbA0KLVZh bGlkIFJhbmdlOiAwLTEgKDA9b2ZmLCAxPW9uKQ0KLURlZmF1bHQgVmFsdWU6 IDANCi0gICBUaGlzIHBhcmFtZXRlciBjb250cm9scyB0aGUgYXV0b21hdGlj IGdlbmVyYXRpb24oVHgpIGFuZCByZXNwb25zZShSeCkgdG8gDQotICAgRXRo ZXJuZXQgUEFVU0UgZnJhbWVzLiBmbG93X2NvbnRyb2wgc2hvdWxkIE5PVCBi ZSBzZXQgdG8gMSB3aGVuIHRoZSANCi0gICBhZGFwdGVyIGlzIGNvbm5lY3Rl ZCB0byBhbiBpbnRlcmZhY2UgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IEV0aGVy bmV0IFBBVVNFIA0KLSAgIGZyYW1lcyBhbmQgd2hlbiB0aGUgZTEwMF9zcGVl ZF9kdXBsZXggcGFyYW1ldGVyIGlzIE5PVCBzZXQgdG8gemVyby4gDQotDQot SW50RGVsYXkNCi1WYWxpZCBSYW5nZTogMC02NTUzNSAoMD1vZmYpDQotRGVm YXVsdCBWYWx1ZTogMTUzNg0KLSAgIFRoaXMgcGFyYW1ldGVyIGhvbGRzIHRo ZSBudW1iZXIgb2YgdGltZSB1bml0cyAoaW4gYWRhcHRlciB0ZXJtaW5vbG9n eSkNCi0gICB1bnRpbCB0aGUgYWRhcHRlciBnZW5lcmF0ZXMgYW4gaW50ZXJy dXB0LiBUaGUgcmVjb21tZW5kZWQgdmFsdWUgZm9yIA0KLSAgIEludERlbGF5 IGlzIDE1MzYgKHVwb24gaW5pdGlhbGl6YXRpb24pLiBTdWdnZXN0ZWQgdmFs dWVzIHJhbmdlIGZyb20gDQotICAgNTEyIHRvIDIwNDguIFNlZSAiQ1BVIEN5 Y2xlIFNhdmVyLiINCi0NCi1JRlMNCi1WYWxpZCBSYW5nZTogMC0xICgwPW9m ZiwgMT1vbikNCi1EZWZhdWx0IFZhbHVlOiAxDQotICBJbnRlciBGcmFtZSBT cGFjaW5nIChJRlMpIGFpbXMgdG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgRXRo ZXJuZXQgZnJhbWUNCi0gIGNvbGxpc2lvbnMgYnkgYWx0ZXJpbmcgdGhlIHRp bWUgYmV0d2VlbiBmcmFtZSB0cmFuc21pc3Npb25zLiBXaGVuIElGUyBpcyAN Ci0gIGVuYWJsZWQgdGhlIGRyaXZlciB0cmllcyB0byBmaW5kIGFuIG9wdGlt YWwgSUZTIHZhbHVlLiBJdCBpcyB1c2VkIG9ubHkgYXQgDQotICBoYWxmIGR1 cGxleC4NCi0NCi1SeERlc2NyaXB0b3JzDQotVmFsaWQgUmFuZ2U6IDgtMTAy NA0KLURlZmF1bHQgVmFsdWU6IDY0DQotICAgVGhpcyBwYXJhbWV0ZXIgZGVm aW5lcyB0aGUgbnVtYmVyIG9mIHJlY2VpdmUgZGVzY3JpcHRvcnMgYWxsb2Nh dGVkIGJ5IA0KLSAgIHRoZSBkcml2ZXIuIEluY3JlYXNpbmcgdGhpcyB2YWx1 ZSBhbGxvd3MgdGhlIGRyaXZlciB0byBidWZmZXIgbW9yZSANCi0gICBpbmNv bWluZyBwYWNrZXRzIGJlZm9yZSB0aGUgZHJpdmVyIGlzIHJlcXVpcmVkIHRv IHNlcnZpY2UgYW4gaW50ZXJydXB0LiANCi0gICBUaGUgbWF4aW11bSB2YWx1 ZSBmb3IgSXRhbml1bS1iYXNlZCBzeXN0ZW1zIGlzIDY0Lg0KLQ0KLVR4RGVz Y3JpcHRvcnMNCi1WYWxpZCBSYW5nZTogMTktMTAyNA0KLURlZmF1bHQgVmFs dWU6IDY0DQotICAgVGhpcyB2YWx1ZSBpcyB0aGUgbnVtYmVyIG9mIHRyYW5z bWl0IGRlc2NyaXB0b3JzIGFsbG9jYXRlZCBieSB0aGUgZHJpdmVyLiANCi0g ICBJbmNyZWFzaW5nIHRoaXMgdmFsdWUgYWxsb3dzIHRoZSBwcm90b2NvbCBz dGFjayB0byBxdWV1ZSBtb3JlIHRyYW5zbWl0cyBhdA0KLSAgIHRoZSBkcml2 ZXIgbGV2ZWwuIFRoZSBtYXhpbXVtIHZhbHVlIGZvciBJdGFuaXVtLWJhc2Vk IHN5c3RlbXMgaXMgNjQuDQotDQotdWNvZGUNCi1WYWxpZCBSYW5nZTogMC0x ICgwPW9mZiwgMT1vbikNCi1EZWZhdWx0IFZhbHVlOiAwIGZvciA4MjU1OC1i YXNlZCBhZGFwdGVycw0KLSAgICAgICAgICAgICAgIDEgZm9yIDgyNTU5LCA4 MjU1MCwgYW5kIDgyNTUxLWJhc2VkIGFkYXB0ZXJzDQotICAgT24gdXBsb2Fk cyB0aGUgbWljcm8gY29kZSB0byB0aGUgYWRhcHRlciwgd2hpY2ggZW5hYmxl cyBDUFUgQ3ljbGUgU2F2ZXIuIA0KLSAgIFNlZSB0aGUgc2VjdGlvbiAiQ1BV IEN5Y2xlIFNhdmVyIiBiZWxvdy4NCi0gICBFeGFtcGxlIHVzYWdlOiBpbnNt b2QgZTEwMC5vIHVjb2RlPTENCi0NCi0gICBOb3QgYXZhaWxhYmxlIG9uIDgy NTU3LWJhc2VkIGFkYXB0ZXJzLg0KLQ0KLVhzdW1SWA0KLVZhbGlkIFJhbmdl OiAwLTEgKDA9b2ZmLCAxPW9uKQ0KLURlZmF1bHQgVmFsdWU6IDENCi0gICBP biBhbGxvd3MgUnggY2hlY2tzdW0gb2ZmbG9hZGluZyBmb3IgVENQL1VEUCBw YWNrZXRzLiBSZXF1aXJlcyB0aGF0IHRoZSANCi0gICBoYXJkd2FyZSBzdXBw b3J0IHRoaXMgZmVhdHVyZS4NCi0NCi0gICBOb3QgYXZhaWxhYmxlIG9uIDgy NTU3IGFuZCA4MjU1OC1iYXNlZCBhZGFwdGVycy4NCi0NCi0NCi1DUFUgQ3lj bGUgU2F2ZXINCi09PT09PT09PT09PT09PT09DQotDQotQ1BVIEN5Y2xlIFNh dmVyIHJlZHVjZXMgQ1BVIHV0aWxpemF0aW9uIGJ5IHJlZHVjaW5nIHRoZSBu dW1iZXIgb2YgaW50ZXJydXB0cyANCi10aGF0IHRoZSBhZGFwdGVyIGdlbmVy YXRlcy4NCi0NCi1XaGVuIENQVSBDeWNsZSBTYXZlciBpcyB0dXJuZWQgb2Zm LCB0aGUgYWRhcHRlciBnZW5lcmF0ZXMgb25lIGludGVycnVwdCBmb3IgDQot ZXZlcnkgZnJhbWUgdGhhdCBpcyByZWNlaXZlZC4gVGhpcyBtZWFucyB0aGF0 IHRoZSBvcGVyYXRpbmcgc3lzdGVtIHN0b3BzIHdoYXQNCi1pdCBpcyBkb2lu ZyBhbmQgc3dpdGNoZXMgdG8gdGhlIG5ldHdvcmsgZHJpdmVyIGluIG9yZGVy IHRvIHByb2Nlc3MgdGhlIA0KLXJlY2VpdmUuDQotDQotV2hlbiBDUFUgQ3lj bGUgU2F2ZXIgaXMgb24sIHRoZSBhZGFwdGVyIGRvZXMgbm90IGdlbmVyYXRl IGFuIGludGVycnVwdCBmb3IgDQotZXZlcnkgZnJhbWUgaXQgcmVjZWl2ZXMu IEluc3RlYWQsIGl0IHdhaXRzIHVudGlsIGl0IHJlY2VpdmVzIHNldmVyYWwg ZnJhbWVzIA0KLWJlZm9yZSBnZW5lcmF0aW5nIGFuIGludGVycnVwdC4gVGhp cyByZWR1Y2VzIHRoZSBhbW91bnQgb2YgdGltZSBzcGVudCANCi1zd2l0Y2hp bmcgdG8gYW5kIGZyb20gdGhlIGRyaXZlci4gDQotDQotQ1BVIEN5Y2xlIFNh dmVyIGNvbnNpc3RzIG9mIHRoZXNlIGFyZ3VtZW50czogSW50RGVsYXksIEJ1 bmRsZU1heCBhbmQgDQotQnVuZGxlU21hbGxGci4gV2hlbiBJbnREZWxheSBp cyBpbmNyZWFzZWQsIHRoZSBhZGFwdGVyIHdhaXRzIGxvbmdlciBmb3IgDQot ZnJhbWVzIHRvIGFycml2ZSBiZWZvcmUgZ2VuZXJhdGluZyB0aGUgaW50ZXJy dXB0LiBCeSBpbmNyZWFzaW5nIEJ1bmRsZU1heCwgDQotdGhlIG5ldHdvcmsg YWRhcHRlciB3YWl0cyBmb3IgdGhlIG51bWJlciBvZiBzbWFsbCBmcmFtZXMg KGxlc3MgdGhhbiAxMjggYnl0ZXMpDQotc3BlY2lmaWVkIHRvIGFycml2ZSBi ZWZvcmUgZ2VuZXJhdGluZyB0aGUgaW50ZXJydXB0LiBXaGVuIEJ1bmRsZVNt YWxsRnIgaXMgDQotZGlzYWJsZWQsIHRoZSBhZGFwdGVyIGRvZXMgbm90IGJ1 bmRsZSBzbWFsbCBwYWNrZXRzLiBTdWNoIHNtYWxsIHBhY2tldHMgYXJlIA0K LW9mdGVuLCBidXQgbm90IGFsd2F5cywgY29udHJvbCBwYWNrZXRzIHRoYXQg YXJlIGJldHRlciBzZXJ2ZWQgaW1tZWRpYXRlbHk7DQotdGhlcmVmb3JlLCBC dW5kbGVTbWFsbEZyIGlzIGRpc2FibGVkIGJ5IGRlZmF1bHQuDQotDQotRm9y IG1vc3QgdXNlcnMsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgQ1BVIEN5Y2xl IFNhdmVyIGJlIHVzZWQgd2l0aCB0aGUgDQotZGVmYXVsdCB2YWx1ZXMgc3Bl Y2lmaWVkIGluIHRoZSBDb21tYW5kIExpbmUgUGFyYW1ldGVycyBzZWN0aW9u LiBIb3dldmVyLCBpbiANCi1zb21lIGNhc2VzLCBwZXJmb3JtYW5jZSBwcm9i bGVtcyBtYXkgb2NjdXIgd2l0aCBDUFUgQ3ljbGUgU2F2ZXIuIElmIHN1Y2gg DQotcHJvYmxlbXMgYXJlIG9ic2VydmVkLCB3ZSByZWNvbW1lbmQgdHVybmlu ZyBvZmYgdGhpcyBmZWF0dXJlIGJ5IHNldHRpbmcgDQotdWNvZGU9MC4NCisg IEZvciBpbnN0cnVjdGlvbnMgb24gZW5hYmxpbmcgV29MIHdpdGggRXRodG9v bCwgcmVmZXIgdG8gdGhlIEV0aHRvb2wgbWFuIHBhZ2UuDQogDQorICBXb0wg d2lsbCBiZSBlbmFibGVkIG9uIHRoZSBzeXN0ZW0gZHVyaW5nIHRoZSBuZXh0 IHNodXQgZG93biBvciByZWJvb3QuIEZvcg0KKyAgdGhpcyBkcml2ZXIgdmVy c2lvbiwgaW4gb3JkZXIgdG8gZW5hYmxlIFdvTCwgdGhlIGUxMDAgZHJpdmVy IG11c3QgYmUgDQorICBsb2FkZWQgd2hlbiBzaHV0dGluZyBkb3duIG9yIHJl Ym9vdGluZyB0aGUgc3lzdGVtLg0KIA0KIFN1cHBvcnQNCiA9PT09PT09DQpA QCAtMjM5LDcgKzE0MCw2IEBAIElmIGFuIGlzc3VlIGlzIGlkZW50aWZpZWQg d2l0aCB0aGUgcmVsZWENCiBrZXJuZWwgd2l0aCBhIHN1cHBvcnRlZCBhZGFw dGVyLCBlbWFpbCB0aGUgc3BlY2lmaWMgaW5mb3JtYXRpb24gcmVsYXRlZCB0 byANCiB0aGUgaXNzdWUgdG8gbGludXgubmljc0BpbnRlbC5jb20uDQogDQot DQogTGljZW5zZQ0KID09PT09PT0NCiANCi0tLSAvbW50L3N0b3JhZ2UvQksv bGludXgtMi40L0RvY3VtZW50YXRpb24vQ29uZmlndXJlLmhlbHAJMjAwNC0w Ny0xMyAwNDowMjoxMi4wMDAwMDAwMDAgLTA3MDANCisrKyBsaW51eC0yLjQu MjctcmMzL0RvY3VtZW50YXRpb24vQ29uZmlndXJlLmhlbHAJMjAwNC0wNy0y OCAyMTo0MDoxNS4zNDQ2NjA3MTIgLTA3MDANCkBAIC0xMjE2Nyw2ICsxMjE2 NywyMCBAQCBDT05GSUdfRTEwMA0KICAgbW9kdWxlLCBzYXkgTSBoZXJlIGFu ZCByZWFkIDxmaWxlOkRvY3VtZW50YXRpb24vbW9kdWxlcy50eHQ+IGFzIHdl bGwNCiAgIGFzIDxmaWxlOkRvY3VtZW50YXRpb24vbmV0d29ya2luZy9uZXQt bW9kdWxlcy50eHQ+Lg0KIA0KK0NPTkZJR19FMTAwX05BUEkNCisgIE5BUEkg aXMgYSBuZXcgZHJpdmVyIEFQSSBkZXNpZ25lZCB0byByZWR1Y2UgQ1BVIGFu ZCBpbnRlcnJ1cHQgbG9hZA0KKyAgd2hlbiB0aGUgZHJpdmVyIGlzIHJlY2Vp dmluZyBsb3RzIG9mIHBhY2tldHMgZnJvbSB0aGUgY2FyZC4gSXQgaXMNCisg IHN0aWxsIHNvbWV3aGF0IGV4cGVyaW1lbnRhbCBhbmQgdGh1cyBub3QgeWV0 IGVuYWJsZWQgYnkgZGVmYXVsdC4NCisNCisgIElmIHlvdXIgZXN0aW1hdGVk IFJ4IGxvYWQgaXMgMTBrcHBzIG9yIG1vcmUsIG9yIGlmIHRoZSBjYXJkIHdp bGwgYmUNCisgIGRlcGxveWVkIG9uIHBvdGVudGlhbGx5IHVuZnJpZW5kbHkg bmV0d29ya3MgKGUuZy4gaW4gYSBmaXJld2FsbCksDQorICB0aGVuIHNheSBZ IGhlcmUuDQorDQorICBTZWUgPGZpbGU6RG9jdW1lbnRhdGlvbi9uZXR3b3Jr aW5nL05BUElfSE9XVE8udHh0PiBmb3IgbW9yZQ0KKyAgaW5mb3JtYXRpb24u DQorDQorICBJZiBpbiBkb3VidCwgc2F5IE4uDQorDQogSW50ZWwoUikgUFJP LzEwMDAgR2lnYWJpdCBFdGhlcm5ldCBzdXBwb3J0DQogQ09ORklHX0UxMDAw DQogICBUaGlzIGRyaXZlciBzdXBwb3J0cyBJbnRlbChSKSBQUk8vMTAwMCBn aWdhYml0IGV0aGVybmV0IGZhbWlseSBvZg0KLS0tIC9tbnQvc3RvcmFnZS9C Sy9saW51eC0yLjQvZHJpdmVycy9uZXQvQ29uZmlnLmluCTIwMDQtMDUtMTUg MDQ6MDI6MTguMDAwMDAwMDAwIC0wNzAwDQorKysgbGludXgtMi40LjI3LXJj My9kcml2ZXJzL25ldC9Db25maWcuaW4JMjAwNC0wNy0yOCAyMTozMTowMS4y NDc4OTYyMjQgLTA3MDANCkBAIC0xOTQsNiArMTk0LDkgQEAgaWYgWyAiJENP TkZJR19ORVRfRVRIRVJORVQiID0gInkiIF07IHRoZQ0KICAgICAgICAgIGRl cF9tYm9vbCAnICAgICAgVXNlIFBJTyBpbnN0ZWFkIG9mIE1NSU8nIENPTkZJ R19FRVBSTzEwMF9QSU8gJENPTkZJR19FRVBSTzEwMA0KICAgICAgIGZpICAN CiAgICAgICBkZXBfdHJpc3RhdGUgJyAgICBFdGhlckV4cHJlc3NQcm8vMTAw IHN1cHBvcnQgKGUxMDAsIEFsdGVybmF0ZSBJbnRlbCBkcml2ZXIpJyBDT05G SUdfRTEwMCAkQ09ORklHX1BDSQ0KKwlpZiBbICIkQ09ORklHX0UxMDAiICE9 ICJuIiBdOyB0aGVuDQorCSAgIGJvb2wgJyAgICAgICBVc2UgUnggUG9sbGlu ZyAoTkFQSSknIENPTkZJR19FMTAwX05BUEkNCisJZmkNCiAgICAgICBkZXBf dHJpc3RhdGUgJyAgICBNeWxleCBFSVNBIExORTM5MEEvQiBzdXBwb3J0IChF WFBFUklNRU5UQUwpJyBDT05GSUdfTE5FMzkwICRDT05GSUdfRUlTQSAkQ09O RklHX0VYUEVSSU1FTlRBTA0KICAgICAgIGRlcF90cmlzdGF0ZSAnICAgIE15 c29uIE1URC04eHggUENJIEV0aGVybmV0IHN1cHBvcnQnIENPTkZJR19GRUFM TlggJENPTkZJR19QQ0kNCiAgICAgICBkZXBfdHJpc3RhdGUgJyAgICBOYXRp b25hbCBTZW1pY29uZHVjdG9yIERQODM4MXggc2VyaWVzIFBDSSBFdGhlcm5l dCBzdXBwb3J0JyBDT05GSUdfTkFUU0VNSSAkQ09ORklHX1BDSQ0KLS0tIC9t bnQvc3RvcmFnZS9CSy9saW51eC0yLjQvZHJpdmVycy9uZXQvTWFrZWZpbGUJ MjAwNC0wNS0xNSAwNDowMjoxOC4wMDAwMDAwMDAgLTA3MDANCisrKyBsaW51 eC0yLjQuMjctcmMzL2RyaXZlcnMvbmV0L01ha2VmaWxlCTIwMDQtMDctMjgg MjA6Mjg6MzAuNjczMDcwMjY0IC0wNzAwDQpAQCAtNTEsNyArNTEsNiBAQCBz dWJkaXItJChDT05GSUdfQVJDTkVUKSArPSBhcmNuZXQNCiBzdWJkaXItJChD T05GSUdfREVWX0FQUExFVEFMSykgKz0gYXBwbGV0YWxrDQogc3ViZGlyLSQo Q09ORklHX1NLOThMSU4pICs9IHNrOThsaW4NCiBzdWJkaXItJChDT05GSUdf U0tGUCkgKz0gc2tmcA0KLXN1YmRpci0kKENPTkZJR19FMTAwKSArPSBlMTAw DQogc3ViZGlyLSQoQ09ORklHX0UxMDAwKSArPSBlMTAwMA0KIHN1YmRpci0k KENPTkZJR19CT05ESU5HKSArPSBib25kaW5nDQogDQpAQCAtODIsNiArODEs NyBAQCBvYmotJChDT05GSUdfVFlQSE9PTikgKz0gdHlwaG9vbi5vDQogb2Jq LSQoQ09ORklHX05FMktfUENJKSArPSBuZTJrLXBjaS5vIDgzOTAubw0KIG9i ai0kKENPTkZJR19QQ05FVDMyKSArPSBwY25ldDMyLm8gbWlpLm8NCiBvYmot JChDT05GSUdfRUVQUk8xMDApICs9IGVlcHJvMTAwLm8gbWlpLm8NCitvYmot JChDT05GSUdfRTEwMCkgKz0gZTEwMC5vIG1paS5vDQogb2JqLSQoQ09ORklH X1RMQU4pICs9IHRsYW4ubw0KIG9iai0kKENPTkZJR19FUElDMTAwKSArPSBl cGljMTAwLm8gbWlpLm8NCiBvYmotJChDT05GSUdfU0lTOTAwKSArPSBzaXM5 MDAubyBtaWkubw0KQEAgLTk2LDEwICs5Niw2IEBAIG9iai0kKENPTkZJR19G RUFMTlgpICs9IGZlYWxueC5vIG1paS5vDQogb2JqLSQoQ09ORklHX1RDMzU4 MTUpICs9IHRjMzU4MTUubw0KIG9iai0kKENPTkZJR19USUdPTjMpICs9IHRn My5vDQogDQotaWZlcSAoJChDT05GSUdfRTEwMCkseSkNCi0gIG9iai15ICs9 IGUxMDAvZTEwMC5vDQotZW5kaWYNCi0NCiBpZmVxICgkKENPTkZJR19TSzk4 TElOKSx5KQ0KIG9iai15ICs9IHNrOThsaW4vc2s5OGxpbi5vDQogZW5kaWYN Ci0tLSAvbW50L3N0b3JhZ2UvQksvbGludXgtMi40L2RyaXZlcnMvbmV0L2Ux MDAuYwkxOTY5LTEyLTMxIDE2OjAwOjAwLjAwMDAwMDAwMCAtMDgwMA0KKysr IGxpbnV4LTIuNC4yNy1yYzMvZHJpdmVycy9uZXQvZTEwMC5jCTIwMDQtMDct MjggMjA6MjA6MzYuNzg4MTExNzI4IC0wNzAwDQpAQCAtMCwwICsxLDIzNjQg QEANCisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKw0K KyAgDQorICBDb3B5cmlnaHQoYykgMTk5OSAtIDIwMDQgSW50ZWwgQ29ycG9y YXRpb24uIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQorICANCisgIFRoaXMgcHJv Z3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBp dCBhbmQvb3IgbW9kaWZ5IGl0IA0KKyAgdW5kZXIgdGhlIHRlcm1zIG9mIHRo ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkg dGhlIEZyZWUgDQorICBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVy c2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIA0K KyAgYW55IGxhdGVyIHZlcnNpb24uDQorICANCisgIFRoaXMgcHJvZ3JhbSBp cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNl ZnVsLCBidXQgV0lUSE9VVCANCisgIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElUWSBv ciANCisgIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2Vl IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgDQorICBtb3Jl IGRldGFpbHMuDQorICANCisgIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBh IGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25n IHdpdGgNCisgIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUg RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuLCA1OSANCisgIFRlbXBs ZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNywg VVNBLg0KKyAgDQorICBUaGUgZnVsbCBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj ZW5zZSBpcyBpbmNsdWRlZCBpbiB0aGlzIGRpc3RyaWJ1dGlvbiBpbiB0aGUN CisgIGZpbGUgY2FsbGVkIExJQ0VOU0UuDQorICANCisgIENvbnRhY3QgSW5m b3JtYXRpb246DQorICBMaW51eCBOSUNTIDxsaW51eC5uaWNzQGludGVsLmNv bT4NCisgIEludGVsIENvcnBvcmF0aW9uLCA1MjAwIE4uRS4gRWxhbSBZb3Vu ZyBQYXJrd2F5LCBIaWxsc2Jvcm8sIE9SIDk3MTI0LTY0OTcNCisNCisqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLw0KKw0KKy8qDQorICoJ ZTEwMC5jOiBJbnRlbChSKSBQUk8vMTAwIGV0aGVybmV0IGRyaXZlcg0KKyAq DQorICoJKFJlKXdyaXR0ZW4gMjAwMyBieSBzY290dC5mZWxkbWFuQGludGVs LmNvbS4gIEJhc2VkIGxvb3NlbHkgb24NCisgKglvcmlnaW5hbCBlMTAwIGRy aXZlciwgYnV0IGJldHRlciBkZXNjcmliZWQgYXMgYSBtdW5naW5nIG9mDQor ICoJZTEwMCwgZTEwMDAsIGVlcHJvMTAwLCB0ZzMsIDgxMzljcCwgYW5kIG90 aGVyIGRyaXZlcnMuDQorICoNCisgKglSZWZlcmVuY2VzOg0KKyAqCQlJbnRl bCA4MjU1eCAxMC8xMDAgTWJwcyBFdGhlcm5ldCBDb250cm9sbGVyIEZhbWls eSwNCisgKgkJT3BlbiBTb3VyY2UgU29mdHdhcmUgRGV2ZWxvcGVycyBNYW51 YWwsDQorICoJCWh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvZTEw MDANCisgKg0KKyAqDQorICoJICAgICAgICAgICAgICAgICAgICAgIFRoZW9y eSBvZiBPcGVyYXRpb24NCisgKg0KKyAqCUkuICAgR2VuZXJhbA0KKyAqDQor ICoJVGhlIGRyaXZlciBzdXBwb3J0cyBJbnRlbChSKSAxMC8xMDAgTWJwcyBQ Q0kgRmFzdCBFdGhlcm5ldA0KKyAqCWNvbnRyb2xsZXIgZmFtaWx5LCB3aGlj aCBpbmNsdWRlcyB0aGUgODI1NTcsIDgyNTU4LCA4MjU1OSwgODI1NTAsDQor ICoJODI1NTEsIGFuZCA4MjU2MiBkZXZpY2VzLiAgODI1NTggYW5kIGdyZWF0 ZXIgY29udHJvbGxlcnMNCisgKglpbnRlZ3JhdGUgdGhlIEludGVsIDgyNTU1 IFBIWS4gIFRoZSBjb250cm9sbGVycyBhcmUgdXNlZCBpbg0KKyAqCXNlcnZl ciBhbmQgY2xpZW50IG5ldHdvcmsgaW50ZXJmYWNlIGNhcmRzLCBhcyB3ZWxs IGFzIGluDQorICoJTEFOLU9uLU1vdGhlcmJvYXJkIChMT00pLCBDYXJkQnVz LCBNaW5pUENJLCBhbmQgSUNIeA0KKyAqCWNvbmZpZ3VyYXRpb25zLiAgODI1 NXggc3VwcG9ydHMgYSAzMi1iaXQgbGluZWFyIGFkZHJlc3NpbmcNCisgKglt b2RlIGFuZCBvcGVyYXRlcyBhdCAzM01oeiBQQ0kgY2xvY2sgcmF0ZS4NCisg Kg0KKyAqCUlJLiAgRHJpdmVyIE9wZXJhdGlvbg0KKyAqDQorICoJTWVtb3J5 LW1hcHBlZCBtb2RlIGlzIHVzZWQgZXhjbHVzaXZlbHkgdG8gYWNjZXNzIHRo ZSBkZXZpY2Uncw0KKyAqCXNoYXJlZC1tZW1vcnkgc3RydWN0dXJlLCB0aGUg Q29udHJvbC9TdGF0dXMgUmVnaXN0ZXJzIChDU1IpLiBBbGwNCisgKglzZXR1 cCwgY29uZmlndXJhdGlvbiwgYW5kIGNvbnRyb2wgb2YgdGhlIGRldmljZSwg aW5jbHVkaW5nIHF1ZXVpbmcNCisgKglvZiBUeCwgUngsIGFuZCBjb25maWd1 cmF0aW9uIGNvbW1hbmRzIGlzIHRocm91Z2ggdGhlIENTUi4NCisgKgljbWRf bG9jayBzZXJpYWxpemVzIGFjY2Vzc2VzIHRvIHRoZSBDU1IgY29tbWFuZCBy ZWdpc3Rlci4gIGNiX2xvY2sNCisgKglwcm90ZWN0cyB0aGUgc2hhcmVkIENv bW1hbmQgQmxvY2sgTGlzdCAoQ0JMKS4NCisgKg0KKyAqCTgyNTV4IGlzIGhp Z2hseSBNSUktY29tcGxpYW50IGFuZCBhbGwgYWNjZXNzIHRvIHRoZSBQSFkg Z28NCisgKgl0aHJvdWdoIHRoZSBNYW5hZ2VtZW50IERhdGEgSW50ZXJmYWNl IChNREkpLiAgQ29uc2VxdWVudGx5LCB0aGUNCisgKglkcml2ZXIgbGV2ZXJh Z2VzIHRoZSBtaWkuYyBsaWJyYXJ5IHNoYXJlZCB3aXRoIG90aGVyIE1JSS1j b21wbGlhbnQNCisgKglkZXZpY2VzLg0KKyAqDQorICoJQmlnLSBhbmQgTGl0 dGxlLUVuZGlhbiBieXRlIG9yZGVyIGFzIHdlbGwgYXMgMzItIGFuZCA2NC1i aXQNCisgKglhcmNocyBhcmUgc3VwcG9ydGVkLiAgV2Vhay1vcmRlcmVkIG1l bW9yeSBhbmQgbm9uLWNhY2hlLWNvaGVyZW50DQorICoJYXJjaHMgYXJlIHN1 cHBvcnRlZC4NCisgKg0KKyAqCUlJSS4gVHJhbnNtaXQNCisgKg0KKyAqCUEg VHggc2tiIGlzIG1hcHBlZCBhbmQgaGFuZ3Mgb2ZmIG9mIGEgVENCLiAgVENC cyBhcmUgbGlua2VkDQorICoJdG9nZXRoZXIgaW4gYSBmaXhlZC1zaXplIHJp bmcgKENCTCkgdGh1cyBmb3JtaW5nIHRoZSBmbGV4aWJsZSBtb2RlDQorICoJ bWVtb3J5IHN0cnVjdHVyZS4gIEEgVENCIG1hcmtlZCB3aXRoIHRoZSBzdXNw ZW5kLWJpdCBpbmRpY2F0ZXMNCisgKgl0aGUgZW5kIG9mIHRoZSByaW5nLiAg VGhlIGxhc3QgVENCIHByb2Nlc3NlZCBzdXNwZW5kcyB0aGUNCisgKgljb250 cm9sbGVyLCBhbmQgdGhlIGNvbnRyb2xsZXIgY2FuIGJlIHJlc3RhcnRlZCBi eSBpc3N1ZSBhIENVDQorICoJcmVzdW1lIGNvbW1hbmQgdG8gY29udGludWUg ZnJvbSB0aGUgc3VzcGVuZCBwb2ludCwgb3IgYSBDVSBzdGFydA0KKyAqCWNv bW1hbmQgdG8gc3RhcnQgYXQgYSBnaXZlbiBwb3NpdGlvbiBpbiB0aGUgcmlu Zy4NCisgKg0KKyAqCU5vbi1UeCBjb21tYW5kcyAoY29uZmlnLCBtdWx0aWNh c3Qgc2V0dXAsIGV0YykgYXJlIGxpbmtlZA0KKyAqCWludG8gdGhlIENCTCBy aW5nIGFsb25nIHdpdGggVHggY29tbWFuZHMuICBUaGUgY29tbW9uIHN0cnVj dHVyZQ0KKyAqCXVzZWQgZm9yIGJvdGggVHggYW5kIG5vbi1UeCBjb21tYW5k cyBpcyB0aGUgQ29tbWFuZCBCbG9jayAoQ0IpLg0KKyAqDQorICoJY2JfdG9f dXNlIGlzIHRoZSBuZXh0IENCIHRvIHVzZSBmb3IgcXVldWluZyBhIGNvbW1h bmQ7IGNiX3RvX2NsZWFuDQorICoJaXMgdGhlIG5leHQgQ0IgdG8gY2hlY2sg Zm9yIGNvbXBsZXRpb247IGNiX3RvX3NlbmQgaXMgdGhlIGZpcnN0DQorICoJ Q0IgdG8gc3RhcnQgb24gaW4gY2FzZSBvZiBhIHByZXZpb3VzIGZhaWx1cmUg dG8gcmVzdW1lLiAgQ0IgY2xlYW4NCisgKgl1cCBoYXBwZW5zIGluIGludGVy cnVwdCBjb250ZXh0IGluIHJlc3BvbnNlIHRvIGEgQ1UgaW50ZXJydXB0Lg0K KyAqCWNic19hdmFpbCBrZWVwcyB0cmFjayBvZiBudW1iZXIgb2YgZnJlZSBD QiByZXNvdXJjZXMgYXZhaWxhYmxlLg0KKyAqDQorICogCUhhcmR3YXJlIHBh ZGRpbmcgb2Ygc2hvcnQgcGFja2V0cyB0byBtaW5pbXVtIHBhY2tldCBzaXpl IGlzDQorICogCWVuYWJsZWQuICA4MjU1NyBwYWRzIHdpdGggN0VoLCB3aGls ZSB0aGUgbGF0ZXIgY29udHJvbGxlcnMgcGFkDQorICogCXdpdGggMDBoLg0K KyAqDQorICoJSVYuICBSZWNpZXZlDQorICoNCisgKglUaGUgUmVjZWl2ZSBG cmFtZSBBcmVhIChSRkEpIGNvbXByaXNlcyBhIHJpbmcgb2YgUmVjZWl2ZSBG cmFtZQ0KKyAqCURlc2NyaXB0b3JzIChSRkQpICsgZGF0YSBidWZmZXIsIHRo dXMgZm9ybWluZyB0aGUgc2ltcGxpZmllZCBtb2RlDQorICoJbWVtb3J5IHN0 cnVjdHVyZS4gIFJ4IHNrYnMgYXJlIGFsbG9jYXRlZCB0byBjb250YWluIGJv dGggdGhlIFJGRA0KKyAqCWFuZCB0aGUgZGF0YSBidWZmZXIsIGJ1dCB0aGUg UkZEIGlzIHB1bGxlZCBvZmYgYmVmb3JlIHRoZSBza2IgaXMNCisgKglpbmRp Y2F0ZWQuICBUaGUgZGF0YSBidWZmZXIgaXMgYWxpZ25lZCBzdWNoIHRoYXQg ZW5jYXBzdWxhdGVkDQorICoJcHJvdG9jb2wgaGVhZGVycyBhcmUgdTMyLWFs aWduZWQuICBTaW5jZSB0aGUgUkZEIGlzIHBhcnQgb2YgdGhlDQorICoJbWFw cGVkIHNoYXJlZCBtZW1vcnksIGFuZCBjb21wbGV0aW9uIHN0YXR1cyBpcyBj b250YWluZWQgd2l0aGluDQorICoJdGhlIFJGRCwgdGhlIFJGRCBtdXN0IGJl IGRtYV9zeW5jJ2VkIHRvIG1haW50YWluIGEgY29uc2lzdGVudA0KKyAqCXZp ZXcgZnJvbSBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUuDQorICoNCisgKglVbmRl ciB0eXBpY2FsIG9wZXJhdGlvbiwgdGhlICByZWNlaXZlIHVuaXQgKFJVKSBp cyBzdGFydCBvbmNlLA0KKyAqCWFuZCB0aGUgY29udHJvbGxlciBoYXBwaWx5 IGZpbGxzIFJGRHMgYXMgZnJhbWVzIGFycml2ZS4gIElmDQorICoJcmVwbGFj ZW1lbnQgUkZEcyBjYW5ub3QgYmUgYWxsb2NhdGVkLCBvciB0aGUgUlUgZ29l cyBub24tYWN0aXZlLA0KKyAqCXRoZSBSVSBtdXN0IGJlIHJlc3RhcnRlZC4g IEZyYW1lIGFycml2YWwgZ2VuZXJhdGVzIGFuIGludGVycnVwdCwNCisgKglh bmQgUnggaW5kaWNhdGlvbiBhbmQgcmUtYWxsb2NhdGlvbiBoYXBwZW4gaW4g dGhlIHNhbWUgY29udGV4dCwNCisgKgl0aGVyZWZvcmUgbm8gbG9ja2luZyBp cyByZXF1aXJlZC4gIEEgc29mdHdhcmUtZ2VuZXJhdGVkIGludGVycnVwdA0K KyAqCWlzIGdlbmVyYXRlZCBmcm9tIHRoZSB3YXRjaGRvZyB0byByZWNvdmVy IGZyb20gYSBmYWlsZWQgYWxsb2NhdGlvbg0KKyAqCXNlbmFyaW8gd2hlcmUg YWxsIFJ4IHJlc291cmNlcyBoYXZlIGJlZW4gaW5kaWNhdGVkIGFuZCBub25l IHJlLQ0KKyAqCXBsYWNlZC4NCisgKg0KKyAqCVYuICAgTWlzY2VsbGFuZW91 cw0KKyAqDQorICogCVZMQU4gb2ZmbG9hZGluZyBvZiB0YWdnaW5nLCBzdHJp cHBpbmcgYW5kIGZpbHRlcmluZyBpcyBub3QNCisgKiAJc3VwcG9ydGVkLCBi dXQgZHJpdmVyIHdpbGwgYWNjb21tb2RhdGUgdGhlIGV4dHJhIDQtYnl0ZSBW TEFOIHRhZw0KKyAqIAlmb3IgcHJvY2Vzc2luZyBieSB1cHBlciBsYXllcnMu ICBUeC9SeCBDaGVja3N1bSBvZmZsb2FkaW5nIGlzIG5vdA0KKyAqIAlzdXBw b3J0ZWQuICBUeCBTY2F0dGVyL0dhdGhlciBpcyBub3Qgc3VwcG9ydGVkLiAg SnVtYm8gRnJhbWVzIGlzDQorICogCW5vdCBzdXBwb3J0ZWQgKGhhcmR3YXJl IGxpbWl0YXRpb24pLg0KKyAqDQorICogCU1hZ2ljUGFja2V0KHRtKSBXb0wg c3VwcG9ydCBpcyBlbmFibGVkL2Rpc2FibGVkIHZpYSBldGh0b29sLg0KKyAq DQorICogCVRoYW5rcyB0byBKQyAoamNoYXBtYW5Aa2F0YWxpeC5jb20pIGZv ciBoZWxwaW5nIHdpdGgNCisgKiAJdGVzdGluZy90cm91Ymxlc2hvb3Rpbmcg dGhlIGRldmVsb3BtZW50IGRyaXZlci4NCisgKg0KKyAqIAlUT0RPOg0KKyAq IAlvIHNldmVyYWwgZW50cnkgcG9pbnRzIHJhY2Ugd2l0aCBkZXYtPmNsb3Nl DQorICogCW8gY2hlY2sgZm9yIHR4LW5vLXJlc291cmNlcy9zdG9wIFEgcmFj ZXMgd2l0aCB0eCBjbGVhbi93YWtlIFENCisgKi8NCisNCisjaW5jbHVkZSA8 bGludXgvY29uZmlnLmg+DQorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0K KyNpbmNsdWRlIDxsaW51eC9tb2R1bGVwYXJhbS5oPg0KKyNpbmNsdWRlIDxs aW51eC9rZXJuZWwuaD4NCisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4NCisj aW5jbHVkZSA8bGludXgvc2xhYi5oPg0KKyNpbmNsdWRlIDxsaW51eC9kZWxh eS5oPg0KKyNpbmNsdWRlIDxsaW51eC9pbml0Lmg+DQorI2luY2x1ZGUgPGxp bnV4L3BjaS5oPg0KKyNpbmNsdWRlIDxsaW51eC9uZXRkZXZpY2UuaD4NCisj aW5jbHVkZSA8bGludXgvZXRoZXJkZXZpY2UuaD4NCisjaW5jbHVkZSA8bGlu dXgvbWlpLmg+DQorI2luY2x1ZGUgPGxpbnV4L2lmX3ZsYW4uaD4NCisjaW5j bHVkZSA8bGludXgvc2tidWZmLmg+DQorI2luY2x1ZGUgPGxpbnV4L2V0aHRv b2wuaD4NCisjaW5jbHVkZSA8bGludXgvc3RyaW5nLmg+DQorI2luY2x1ZGUg PGFzbS91bmFsaWduZWQuaD4NCisNCisNCisjZGVmaW5lIERSVl9OQU1FCQki ZTEwMCINCisjZGVmaW5lIERSVl9FWFQJCSItTkFQSSINCisjZGVmaW5lIERS Vl9WRVJTSU9OCQkiMy4wLjI3LWsxIkRSVl9FWFQNCisjZGVmaW5lIERSVl9E RVNDUklQVElPTgkJIkludGVsKFIpIFBSTy8xMDAgTmV0d29yayBEcml2ZXIi DQorI2RlZmluZSBEUlZfQ09QWVJJR0hUCQkiQ29weXJpZ2h0KGMpIDE5OTkt MjAwNCBJbnRlbCBDb3Jwb3JhdGlvbiINCisjZGVmaW5lIFBGWAkJCURSVl9O QU1FICI6ICINCisNCisjZGVmaW5lIEUxMDBfV0FUQ0hET0dfUEVSSU9ECSgy ICogSFopDQorI2RlZmluZSBFMTAwX05BUElfV0VJR0hUCTE2DQorDQorTU9E VUxFX0RFU0NSSVBUSU9OKERSVl9ERVNDUklQVElPTik7DQorTU9EVUxFX0FV VEhPUihEUlZfQ09QWVJJR0hUKTsNCitNT0RVTEVfTElDRU5TRSgiR1BMIik7 DQorDQorc3RhdGljIGludCBkZWJ1ZyA9IDM7DQorbW9kdWxlX3BhcmFtKGRl YnVnLCBpbnQsIDApOw0KK01PRFVMRV9QQVJNX0RFU0MoZGVidWcsICJEZWJ1 ZyBsZXZlbCAoMD1ub25lLC4uLiwxNj1hbGwpIik7DQorI2RlZmluZSBEUFJJ TlRLKG5sZXZlbCwga2xldmVsLCBmbXQsIGFyZ3MuLi4pIFwNCisJKHZvaWQp KChORVRJRl9NU0dfIyNubGV2ZWwgJiBuaWMtPm1zZ19lbmFibGUpICYmIFwN CisJcHJpbnRrKEtFUk5fIyNrbGV2ZWwgUEZYICIlczogJXM6ICIgZm10LCBu aWMtPm5ldGRldi0+bmFtZSwgXA0KKwkJX19GVU5DVElPTl9fICwgIyMgYXJn cykpDQorDQorI2RlZmluZSBJTlRFTF84MjU1WF9FVEhFUk5FVF9ERVZJQ0Uo ZGV2aWNlX2lkLCBpY2gpIHtcDQorCVBDSV9WRU5ET1JfSURfSU5URUwsIGRl dmljZV9pZCwgUENJX0FOWV9JRCwgUENJX0FOWV9JRCwgXA0KKwlQQ0lfQ0xB U1NfTkVUV09SS19FVEhFUk5FVCA8PCA4LCAweEZGRkYwMCwgaWNoIH0NCitz dGF0aWMgc3RydWN0IHBjaV9kZXZpY2VfaWQgZTEwMF9pZF90YWJsZVtdID0g ew0KKwlJTlRFTF84MjU1WF9FVEhFUk5FVF9ERVZJQ0UoMHgxMDI5LCAwKSwN CisJSU5URUxfODI1NVhfRVRIRVJORVRfREVWSUNFKDB4MTAzMCwgMCksDQor CUlOVEVMXzgyNTVYX0VUSEVSTkVUX0RFVklDRSgweDEwMzEsIDMpLA0KKwlJ TlRFTF84MjU1WF9FVEhFUk5FVF9ERVZJQ0UoMHgxMDMyLCAzKSwNCisJSU5U RUxfODI1NVhfRVRIRVJORVRfREVWSUNFKDB4MTAzMywgMyksDQorCUlOVEVM XzgyNTVYX0VUSEVSTkVUX0RFVklDRSgweDEwMzQsIDMpLA0KKwlJTlRFTF84 MjU1WF9FVEhFUk5FVF9ERVZJQ0UoMHgxMDM4LCAzKSwNCisJSU5URUxfODI1 NVhfRVRIRVJORVRfREVWSUNFKDB4MTAzOSwgNCksDQorCUlOVEVMXzgyNTVY X0VUSEVSTkVUX0RFVklDRSgweDEwM0EsIDQpLA0KKwlJTlRFTF84MjU1WF9F VEhFUk5FVF9ERVZJQ0UoMHgxMDNCLCA0KSwNCisJSU5URUxfODI1NVhfRVRI RVJORVRfREVWSUNFKDB4MTAzQywgNCksDQorCUlOVEVMXzgyNTVYX0VUSEVS TkVUX0RFVklDRSgweDEwM0QsIDQpLA0KKwlJTlRFTF84MjU1WF9FVEhFUk5F VF9ERVZJQ0UoMHgxMDNFLCA0KSwNCisJSU5URUxfODI1NVhfRVRIRVJORVRf REVWSUNFKDB4MTA1MCwgNSksDQorCUlOVEVMXzgyNTVYX0VUSEVSTkVUX0RF VklDRSgweDEwNTEsIDUpLA0KKwlJTlRFTF84MjU1WF9FVEhFUk5FVF9ERVZJ Q0UoMHgxMDUyLCA1KSwNCisJSU5URUxfODI1NVhfRVRIRVJORVRfREVWSUNF KDB4MTA1MywgNSksDQorCUlOVEVMXzgyNTVYX0VUSEVSTkVUX0RFVklDRSgw eDEwNTQsIDUpLA0KKwlJTlRFTF84MjU1WF9FVEhFUk5FVF9ERVZJQ0UoMHgx MDU1LCA1KSwNCisJSU5URUxfODI1NVhfRVRIRVJORVRfREVWSUNFKDB4MTA1 NiwgNSksDQorCUlOVEVMXzgyNTVYX0VUSEVSTkVUX0RFVklDRSgweDEwNTcs IDUpLA0KKwlJTlRFTF84MjU1WF9FVEhFUk5FVF9ERVZJQ0UoMHgxMDY0LCA2 KSwNCisJSU5URUxfODI1NVhfRVRIRVJORVRfREVWSUNFKDB4MTA2NSwgNiks DQorCUlOVEVMXzgyNTVYX0VUSEVSTkVUX0RFVklDRSgweDEwNjYsIDYpLA0K KwlJTlRFTF84MjU1WF9FVEhFUk5FVF9ERVZJQ0UoMHgxMDY3LCA2KSwNCisJ SU5URUxfODI1NVhfRVRIRVJORVRfREVWSUNFKDB4MTA2OCwgNiksDQorCUlO VEVMXzgyNTVYX0VUSEVSTkVUX0RFVklDRSgweDEwNjksIDYpLA0KKwlJTlRF TF84MjU1WF9FVEhFUk5FVF9ERVZJQ0UoMHgxMDZBLCA2KSwNCisJSU5URUxf ODI1NVhfRVRIRVJORVRfREVWSUNFKDB4MTA2QiwgNiksDQorCUlOVEVMXzgy NTVYX0VUSEVSTkVUX0RFVklDRSgweDEwNTksIDApLA0KKwlJTlRFTF84MjU1 WF9FVEhFUk5FVF9ERVZJQ0UoMHgxMjA5LCAwKSwNCisJSU5URUxfODI1NVhf RVRIRVJORVRfREVWSUNFKDB4MTIyOSwgMCksDQorCUlOVEVMXzgyNTVYX0VU SEVSTkVUX0RFVklDRSgweDI0NDksIDIpLA0KKwlJTlRFTF84MjU1WF9FVEhF Uk5FVF9ERVZJQ0UoMHgyNDU5LCAyKSwNCisJSU5URUxfODI1NVhfRVRIRVJO RVRfREVWSUNFKDB4MjQ1RCwgMiksDQorCXsgMCwgfQ0KK307DQorTU9EVUxF X0RFVklDRV9UQUJMRShwY2ksIGUxMDBfaWRfdGFibGUpOw0KKw0KK2VudW0g bWFjIHsNCisJbWFjXzgyNTU3X0QxMDBfQSAgPSAwLA0KKwltYWNfODI1NTdf RDEwMF9CICA9IDEsDQorCW1hY184MjU1N19EMTAwX0MgID0gMiwNCisJbWFj XzgyNTU4X0QxMDFfQTQgPSA0LA0KKwltYWNfODI1NThfRDEwMV9CMCA9IDUs DQorCW1hY184MjU1OV9EMTAxTSAgID0gOCwNCisJbWFjXzgyNTU5X0QxMDFT ICAgPSA5LA0KKwltYWNfODI1NTBfRDEwMiAgICA9IDEyLA0KKwltYWNfODI1 NTBfRDEwMl9DICA9IDEzLA0KKwltYWNfODI1NTFfRSAgICAgICA9IDE0LA0K KwltYWNfODI1NTFfRiAgICAgICA9IDE1LA0KKwltYWNfODI1NTFfMTAgICAg ICA9IDE2LA0KKwltYWNfdW5rbm93biAgICAgICA9IDB4RkYsDQorfTsNCisN CitlbnVtIHBoeSB7DQorCXBoeV8xMDBhICAgICA9IDB4MDAwMDAzRTAsDQor CXBoeV8xMDBjICAgICA9IDB4MDM1MDAyQTgsDQorCXBoeV84MjU1NV90eCA9 IDB4MDE1MDAyQTgsDQorCXBoeV9uc2NfdHggICA9IDB4NUMwMDIwMDAsDQor CXBoeV84MjU2Ml9ldCA9IDB4MDMzMDAyQTgsDQorCXBoeV84MjU2Ml9lbSA9 IDB4MDMyMDAyQTgsDQorCXBoeV84MjU2Ml9layA9IDB4MDMxMDAyQTgsDQor CXBoeV84MjU2Ml9laCA9IDB4MDE3MDAyQTgsDQorCXBoeV91bmtub3duICA9 IDB4RkZGRkZGRkYsDQorfTsNCisNCisvKiBDU1IgKENvbnRyb2wvU3RhdHVz IFJlZ2lzdGVycykgKi8NCitzdHJ1Y3QgY3NyIHsNCisJc3RydWN0IHsNCisJ CXU4IHN0YXR1czsNCisJCXU4IHN0YXRfYWNrOw0KKwkJdTggY21kX2xvOw0K KwkJdTggY21kX2hpOw0KKwkJdTMyIGdlbl9wdHI7DQorCX0gc2NiOw0KKwl1 MzIgcG9ydDsNCisJdTE2IGZsYXNoX2N0cmw7DQorCXU4IGVlcHJvbV9jdHJs X2xvOw0KKwl1OCBlZXByb21fY3RybF9oaTsNCisJdTMyIG1kaV9jdHJsOw0K Kwl1MzIgcnhfZG1hX2NvdW50Ow0KK307DQorDQorZW51bSBzY2Jfc3RhdHVz IHsNCisJcnVzX3JlYWR5ICAgICAgICA9IDB4MTAsDQorCXJ1c19tYXNrICAg ICAgICAgPSAweDNDLA0KK307DQorDQorZW51bSBzY2Jfc3RhdF9hY2sgew0K KwlzdGF0X2Fja19ub3Rfb3VycyAgICA9IDB4MDAsDQorCXN0YXRfYWNrX3N3 X2dlbiAgICAgID0gMHgwNCwNCisJc3RhdF9hY2tfcm5yICAgICAgICAgPSAw eDEwLA0KKwlzdGF0X2Fja19jdV9pZGxlICAgICA9IDB4MjAsDQorCXN0YXRf YWNrX2ZyYW1lX3J4ICAgID0gMHg0MCwNCisJc3RhdF9hY2tfY3VfY21kX2Rv bmUgPSAweDgwLA0KKwlzdGF0X2Fja19ub3RfcHJlc2VudCA9IDB4RkYsDQor CXN0YXRfYWNrX3J4ID0gKHN0YXRfYWNrX3N3X2dlbiB8IHN0YXRfYWNrX3Ju ciB8IHN0YXRfYWNrX2ZyYW1lX3J4KSwNCisJc3RhdF9hY2tfdHggPSAoc3Rh dF9hY2tfY3VfaWRsZSB8IHN0YXRfYWNrX2N1X2NtZF9kb25lKSwNCit9Ow0K Kw0KK2VudW0gc2NiX2NtZF9oaSB7DQorCWlycV9tYXNrX25vbmUgPSAweDAw LA0KKwlpcnFfbWFza19hbGwgID0gMHgwMSwNCisJaXJxX3N3X2dlbiAgICA9 IDB4MDIsDQorfTsNCisNCitlbnVtIHNjYl9jbWRfbG8gew0KKwljdWNfbm9w ICAgICAgICA9IDB4MDAsDQorCXJ1Y19zdGFydCAgICAgID0gMHgwMSwNCisJ cnVjX2xvYWRfYmFzZSAgPSAweDA2LA0KKwljdWNfc3RhcnQgICAgICA9IDB4 MTAsDQorCWN1Y19yZXN1bWUgICAgID0gMHgyMCwNCisJY3VjX2R1bXBfYWRk ciAgPSAweDQwLA0KKwljdWNfZHVtcF9zdGF0cyA9IDB4NTAsDQorCWN1Y19s b2FkX2Jhc2UgID0gMHg2MCwNCisJY3VjX2R1bXBfcmVzZXQgPSAweDcwLA0K K307DQorDQorZW51bSBjdWNfZHVtcCB7DQorCWN1Y19kdW1wX2NvbXBsZXRl ICAgICAgID0gMHgwMDAwQTAwNSwNCisJY3VjX2R1bXBfcmVzZXRfY29tcGxl dGUgPSAweDAwMDBBMDA3LA0KK307DQorCQkNCitlbnVtIHBvcnQgew0KKwlz b2Z0d2FyZV9yZXNldCAgPSAweDAwMDAsDQorCXNlbGZ0ZXN0ICAgICAgICA9 IDB4MDAwMSwNCisJc2VsZWN0aXZlX3Jlc2V0ID0gMHgwMDAyLA0KK307DQor DQorZW51bSBlZXByb21fY3RybF9sbyB7DQorCWVlc2sgPSAweDAxLA0KKwll ZWNzID0gMHgwMiwNCisJZWVkaSA9IDB4MDQsDQorCWVlZG8gPSAweDA4LA0K K307DQorDQorZW51bSBtZGlfY3RybCB7DQorCW1kaV93cml0ZSA9IDB4MDQw MDAwMDAsDQorCW1kaV9yZWFkICA9IDB4MDgwMDAwMDAsDQorCW1kaV9yZWFk eSA9IDB4MTAwMDAwMDAsDQorfTsNCisNCitlbnVtIGVlcHJvbV9vcCB7DQor CW9wX3dyaXRlID0gMHgwNSwNCisJb3BfcmVhZCAgPSAweDA2LA0KKwlvcF9l d2RzICA9IDB4MTAsDQorCW9wX2V3ZW4gID0gMHgxMywNCit9Ow0KKw0KK2Vu dW0gZWVwcm9tX29mZnNldHMgew0KKwllZXByb21fY25mZ19tZGl4ICA9IDB4 MDMsDQorCWVlcHJvbV9pZCAgICAgICAgID0gMHgwQSwNCisJZWVwcm9tX2Nv bmZpZ19hc2YgPSAweDBELA0KKwllZXByb21fc21idXNfYWRkciA9IDB4OTAs DQorfTsNCisNCitlbnVtIGVlcHJvbV9jbmZnX21kaXggew0KKwllZXByb21f bWRpeF9lbmFibGVkID0gMHgwMDgwLA0KK307DQorDQorZW51bSBlZXByb21f aWQgew0KKwllZXByb21faWRfd29sID0gMHgwMDIwLA0KK307DQorDQorZW51 bSBlZXByb21fY29uZmlnX2FzZiB7DQorCWVlcHJvbV9hc2YgPSAweDgwMDAs DQorCWVlcHJvbV9nY2wgPSAweDQwMDAsDQorfTsNCisNCitlbnVtIGNiX3N0 YXR1cyB7DQorCWNiX2NvbXBsZXRlID0gMHg4MDAwLA0KKwljYl9vayAgICAg ICA9IDB4MjAwMCwNCit9Ow0KKw0KK2VudW0gY2JfY29tbWFuZCB7DQorCWNi X25vcCAgICA9IDB4MDAwMCwNCisJY2JfaWFhZGRyID0gMHgwMDAxLA0KKwlj Yl9jb25maWcgPSAweDAwMDIsDQorCWNiX211bHRpICA9IDB4MDAwMywNCisJ Y2JfdHggICAgID0gMHgwMDA0LA0KKwljYl91Y29kZSAgPSAweDAwMDUsDQor CWNiX2R1bXAgICA9IDB4MDAwNiwNCisJY2JfdHhfc2YgID0gMHgwMDA4LA0K KwljYl9jaWQgICAgPSAweDFmMDAsDQorCWNiX2kgICAgICA9IDB4MjAwMCwN CisJY2JfcyAgICAgID0gMHg0MDAwLA0KKwljYl9lbCAgICAgPSAweDgwMDAs DQorfTsNCisNCitzdHJ1Y3QgcmZkIHsNCisJdTE2IHN0YXR1czsNCisJdTE2 IGNvbW1hbmQ7DQorCXUzMiBsaW5rOw0KKwl1MzIgcmJkOw0KKwl1MTYgYWN0 dWFsX3NpemU7DQorCXUxNiBzaXplOw0KK307DQorDQorc3RydWN0IHJ4IHsN CisJc3RydWN0IHJ4ICpuZXh0LCAqcHJldjsNCisJc3RydWN0IHNrX2J1ZmYg KnNrYjsNCisJZG1hX2FkZHJfdCBkbWFfYWRkcjsNCit9Ow0KKw0KKyNpZiBk ZWZpbmVkKF9fQklHX0VORElBTl9CSVRGSUVMRCkNCisjZGVmaW5lIFgoYSxi KQliLGENCisjZWxzZQ0KKyNkZWZpbmUgWChhLGIpCWEsYg0KKyNlbmRpZg0K K3N0cnVjdCBjb25maWcgew0KKy8qMCovCXU4IFgoYnl0ZV9jb3VudDo2LCBw YWQwOjIpOw0KKy8qMSovCXU4IFgoWChyeF9maWZvX2xpbWl0OjQsIHR4X2Zp Zm9fbGltaXQ6MyksIHBhZDE6MSk7DQorLyoyKi8JdTggYWRhcHRpdmVfaWZz Ow0KKy8qMyovCXU4IFgoWChYKFgobXdpX2VuYWJsZToxLCB0eXBlX2VuYWJs ZToxKSwgcmVhZF9hbGlnbl9lbmFibGU6MSksDQorCSAgIHRlcm1fd3JpdGVf Y2FjaGVfbGluZToxKSwgcGFkMzo0KTsNCisvKjQqLwl1OCBYKHJ4X2RtYV9t YXhfY291bnQ6NywgcGFkNDoxKTsNCisvKjUqLwl1OCBYKHR4X2RtYV9tYXhf Y291bnQ6NywgZG1hX21heF9jb3VudF9lbmFibGU6MSk7DQorLyo2Ki8JdTgg WChYKFgoWChYKFgoWChsYXRlX3NjYl91cGRhdGU6MSwgZGlyZWN0X3J4X2Rt YToxKSwNCisJICAgdG5vX2ludHI6MSksIGNuYV9pbnRyOjEpLCBzdGFuZGFy ZF90Y2I6MSksIHN0YW5kYXJkX3N0YXRfY291bnRlcjoxKSwNCisJICAgcnhf ZGlzY2FyZF9vdmVycnVuczoxKSwgcnhfc2F2ZV9iYWRfZnJhbWVzOjEpOw0K Ky8qNyovCXU4IFgoWChYKFgoWChyeF9kaXNjYXJkX3Nob3J0X2ZyYW1lczox LCB0eF91bmRlcnJ1bl9yZXRyeToyKSwNCisJICAgcGFkNzoyKSwgcnhfZXh0 ZW5kZWRfcmZkOjEpLCB0eF90d29fZnJhbWVzX2luX2ZpZm86MSksDQorCSAg IHR4X2R5bmFtaWNfdGJkOjEpOw0KKy8qOCovCXU4IFgoWChtaWlfbW9kZTox LCBwYWQ4OjYpLCBjc21hX2Rpc2FibGVkOjEpOw0KKy8qOSovCXU4IFgoWChY KFgoWChyeF90Y3B1ZHBfY2hlY2tzdW06MSwgcGFkOTozKSwgdmxhbl9hcnBf dGNvOjEpLA0KKwkgICBsaW5rX3N0YXR1c193YWtlOjEpLCBhcnBfd2FrZTox KSwgbWNtYXRjaF93YWtlOjEpOw0KKy8qMTAqLwl1OCBYKFgoWChwYWQxMDoz LCBub19zb3VyY2VfYWRkcl9pbnNlcnRpb246MSksIHByZWFtYmxlX2xlbmd0 aDoyKSwNCisJICAgbG9vcGJhY2s6Mik7DQorLyoxMSovCXU4IFgobGluZWFy X3ByaW9yaXR5OjMsIHBhZDExOjUpOw0KKy8qMTIqLwl1OCBYKFgobGluZWFy X3ByaW9yaXR5X21vZGU6MSwgcGFkMTI6MyksIGlmczo0KTsNCisvKjEzKi8J dTggaXBfYWRkcl9sbzsNCisvKjE0Ki8JdTggaXBfYWRkcl9oaTsNCisvKjE1 Ki8JdTggWChYKFgoWChYKFgoWChwcm9taXNjdW91c19tb2RlOjEsIGJyb2Fk Y2FzdF9kaXNhYmxlZDoxKSwNCisJICAgd2FpdF9hZnRlcl93aW46MSksIHBh ZDE1XzE6MSksIGlnbm9yZV91bF9iaXQ6MSksIGNyY18xNl9iaXQ6MSksDQor CSAgIHBhZDE1XzI6MSksIGNyc19vcl9jZHQ6MSk7DQorLyoxNiovCXU4IGZj X2RlbGF5X2xvOw0KKy8qMTcqLwl1OCBmY19kZWxheV9oaTsNCisvKjE4Ki8J dTggWChYKFgoWChYKHJ4X3N0cmlwcGluZzoxLCB0eF9wYWRkaW5nOjEpLCBy eF9jcmNfdHJhbnNmZXI6MSksDQorCSAgIHJ4X2xvbmdfb2s6MSksIGZjX3By aW9yaXR5X3RocmVzaG9sZDozKSwgcGFkMTg6MSk7DQorLyoxOSovCXU4IFgo WChYKFgoWChYKFgoYWRkcl93YWtlOjEsIG1hZ2ljX3BhY2tldF9kaXNhYmxl OjEpLA0KKwkgICBmY19kaXNhYmxlOjEpLCBmY19yZXN0b3A6MSksIGZjX3Jl c3RhcnQ6MSksIGZjX3JlamVjdDoxKSwNCisJICAgZnVsbF9kdXBsZXhfZm9y Y2U6MSksIGZ1bGxfZHVwbGV4X3BpbjoxKTsNCisvKjIwKi8JdTggWChYKFgo cGFkMjBfMTo1LCBmY19wcmlvcml0eV9sb2NhdGlvbjoxKSwgbXVsdGlfaWE6 MSksIHBhZDIwXzI6MSk7DQorLyoyMSovCXU4IFgoWChwYWQyMV8xOjMsIG11 bHRpY2FzdF9hbGw6MSksIHBhZDIxXzI6NCk7DQorLyoyMiovCXU4IFgoWChy eF9kMTAyX21vZGU6MSwgcnhfdmxhbl9kcm9wOjEpLCBwYWQyMjo2KTsNCisJ dTggcGFkX2QxMDJbOV07DQorfTsNCisNCisjZGVmaW5lIEUxMDBfTUFYX01V TFRJQ0FTVF9BRERSUwk2NA0KK3N0cnVjdCBtdWx0aSB7DQorCXUxNiBjb3Vu dDsNCisJdTggYWRkcltFMTAwX01BWF9NVUxUSUNBU1RfQUREUlMgKiBFVEhf QUxFTiArIDIvKnBhZCovXTsNCit9Ow0KKw0KKy8qIEltcG9ydGFudDoga2Vl cCB0b3RhbCBzdHJ1Y3QgdTMyLWFsaWduZWQgKi8NCisjZGVmaW5lIFVDT0RF X1NJWkUJCQkxMzQNCitzdHJ1Y3QgY2Igew0KKwl1MTYgc3RhdHVzOw0KKwl1 MTYgY29tbWFuZDsNCisJdTMyIGxpbms7DQorCXVuaW9uIHsNCisJCXU4IGlh YWRkcltFVEhfQUxFTl07DQorCQl1MzIgdWNvZGVbVUNPREVfU0laRV07DQor CQlzdHJ1Y3QgY29uZmlnIGNvbmZpZzsNCisJCXN0cnVjdCBtdWx0aSBtdWx0 aTsNCisJCXN0cnVjdCB7DQorCQkJdTMyIHRiZF9hcnJheTsNCisJCQl1MTYg dGNiX2J5dGVfY291bnQ7DQorCQkJdTggdGhyZXNob2xkOw0KKwkJCXU4IHRi ZF9jb3VudDsNCisJCQlzdHJ1Y3Qgew0KKwkJCQl1MzIgYnVmX2FkZHI7DQor CQkJCXUxNiBzaXplOw0KKwkJCQl1MTYgZW9sOw0KKwkJCX0gdGJkOw0KKwkJ fSB0Y2I7DQorCQl1MzIgZHVtcF9idWZmZXJfYWRkcjsNCisJfSB1Ow0KKwlz dHJ1Y3QgY2IgKm5leHQsICpwcmV2Ow0KKwlkbWFfYWRkcl90IGRtYV9hZGRy Ow0KKwlzdHJ1Y3Qgc2tfYnVmZiAqc2tiOw0KK307DQorDQorZW51bSBsb29w YmFjayB7DQorCWxiX25vbmUgPSAwLCBsYl9tYWMgPSAxLCBsYl9waHkgPSAz LA0KK307DQorDQorc3RydWN0IHN0YXRzIHsNCisJdTMyIHR4X2dvb2RfZnJh bWVzLCB0eF9tYXhfY29sbGlzaW9ucywgdHhfbGF0ZV9jb2xsaXNpb25zLA0K KwkJdHhfdW5kZXJydW5zLCB0eF9sb3N0X2NycywgdHhfZGVmZXJyZWQsIHR4 X3NpbmdsZV9jb2xsaXNpb25zLA0KKwkJdHhfbXVsdGlwbGVfY29sbGlzaW9u cywgdHhfdG90YWxfY29sbGlzaW9uczsNCisJdTMyIHJ4X2dvb2RfZnJhbWVz LCByeF9jcmNfZXJyb3JzLCByeF9hbGlnbm1lbnRfZXJyb3JzLA0KKwkJcnhf cmVzb3VyY2VfZXJyb3JzLCByeF9vdmVycnVuX2Vycm9ycywgcnhfY2R0X2Vy cm9ycywNCisJCXJ4X3Nob3J0X2ZyYW1lX2Vycm9yczsNCisJdTMyIGZjX3ht dF9wYXVzZSwgZmNfcmN2X3BhdXNlLCBmY19yY3ZfdW5zdXBwb3J0ZWQ7DQor CXUxNiB4bXRfdGNvX2ZyYW1lcywgcmN2X3Rjb19mcmFtZXM7DQorCXUzMiBj b21wbGV0ZTsNCit9Ow0KKw0KK3N0cnVjdCBtZW0gew0KKwlzdHJ1Y3Qgew0K KwkJdTMyIHNpZ25hdHVyZTsNCisJCXUzMiByZXN1bHQ7DQorCX0gc2VsZnRl c3Q7DQorCXN0cnVjdCBzdGF0cyBzdGF0czsNCisJdTggZHVtcF9idWZbNTk2 XTsNCit9Ow0KKw0KK3N0cnVjdCBwYXJhbV9yYW5nZSB7DQorCXUzMiBtaW47 DQorCXUzMiBtYXg7DQorCXUzMiBjb3VudDsNCit9Ow0KKw0KK3N0cnVjdCBw YXJhbXMgew0KKwlzdHJ1Y3QgcGFyYW1fcmFuZ2UgcmZkczsNCisJc3RydWN0 IHBhcmFtX3JhbmdlIGNiczsNCit9Ow0KKw0KK3N0cnVjdCBuaWMgew0KKwkv KiBCZWdpbjogZnJlcXVlbnRseSB1c2VkIHZhbHVlczoga2VlcCBhZGphY2Vu dCBmb3IgY2FjaGUgZWZmZWN0ICovDQorCXUzMiBtc2dfZW5hYmxlCQkJCV9f X19jYWNoZWxpbmVfYWxpZ25lZDsNCisJc3RydWN0IG5ldF9kZXZpY2UgKm5l dGRldjsNCisJc3RydWN0IHBjaV9kZXYgKnBkZXY7DQorDQorCXN0cnVjdCBy eCAqcnhzCQkJCV9fX19jYWNoZWxpbmVfYWxpZ25lZDsNCisJc3RydWN0IHJ4 ICpyeF90b191c2U7DQorCXN0cnVjdCByeCAqcnhfdG9fY2xlYW47DQorCXN0 cnVjdCByZmQgYmxhbmtfcmZkOw0KKwlpbnQgcnVfcnVubmluZzsNCisNCisJ c3BpbmxvY2tfdCBjYl9sb2NrCQkJX19fX2NhY2hlbGluZV9hbGlnbmVkOw0K KwlzcGlubG9ja190IGNtZF9sb2NrOw0KKwlzdHJ1Y3QgY3NyICpjc3I7DQor CWVudW0gc2NiX2NtZF9sbyBjdWNfY21kOw0KKwl1bnNpZ25lZCBpbnQgY2Jz X2F2YWlsOw0KKwlzdHJ1Y3QgY2IgKmNiczsNCisJc3RydWN0IGNiICpjYl90 b191c2U7DQorCXN0cnVjdCBjYiAqY2JfdG9fc2VuZDsNCisJc3RydWN0IGNi ICpjYl90b19jbGVhbjsNCisJdTE2IHR4X2NvbW1hbmQ7DQorCS8qIEVuZDog ZnJlcXVlbnRseSB1c2VkIHZhbHVlczoga2VlcCBhZGphY2VudCBmb3IgY2Fj aGUgZWZmZWN0ICovDQorDQorCWVudW0gew0KKwkJaWNoICAgICAgICAgICAg ICAgID0gKDEgPDwgMCksDQorCQlwcm9taXNjdW91cyAgICAgICAgPSAoMSA8 PCAxKSwNCisJCW11bHRpY2FzdF9hbGwgICAgICA9ICgxIDw8IDIpLA0KKwkJ d29sX21hZ2ljICAgICAgICAgID0gKDEgPDwgMyksDQorCQlpY2hfMTBoX3dv cmthcm91bmQgPSAoMSA8PCA0KSwNCisJfSBmbGFncwkJCQkJX19fX2NhY2hl bGluZV9hbGlnbmVkOw0KKw0KKwllbnVtIG1hYyBtYWM7DQorCWVudW0gcGh5 IHBoeTsNCisJc3RydWN0IHBhcmFtcyBwYXJhbXM7DQorCXN0cnVjdCBuZXRf ZGV2aWNlX3N0YXRzIG5ldF9zdGF0czsNCisJc3RydWN0IHRpbWVyX2xpc3Qg d2F0Y2hkb2c7DQorCXN0cnVjdCB0aW1lcl9saXN0IGJsaW5rX3RpbWVyOw0K KwlzdHJ1Y3QgbWlpX2lmX2luZm8gbWlpOw0KKwllbnVtIGxvb3BiYWNrIGxv b3BiYWNrOw0KKw0KKwlzdHJ1Y3QgbWVtICptZW07DQorCWRtYV9hZGRyX3Qg ZG1hX2FkZHI7DQorDQorCWRtYV9hZGRyX3QgY2JzX2RtYV9hZGRyOw0KKwl1 OCBhZGFwdGl2ZV9pZnM7DQorCXU4IHR4X3RocmVzaG9sZDsNCisJdTMyIHR4 X2ZyYW1lczsNCisJdTMyIHR4X2NvbGxpc2lvbnM7DQorCXUzMiB0eF9kZWZl cnJlZDsNCisJdTMyIHR4X3NpbmdsZV9jb2xsaXNpb25zOw0KKwl1MzIgdHhf bXVsdGlwbGVfY29sbGlzaW9uczsNCisJdTMyIHR4X2ZjX3BhdXNlOw0KKwl1 MzIgdHhfdGNvX2ZyYW1lczsNCisNCisJdTMyIHJ4X2ZjX3BhdXNlOw0KKwl1 MzIgcnhfZmNfdW5zdXBwb3J0ZWQ7DQorCXUzMiByeF90Y29fZnJhbWVzOw0K Kwl1MzIgcnhfb3Zlcl9sZW5ndGhfZXJyb3JzOw0KKw0KKwl1OCByZXZfaWQ7 DQorCXUxNiBsZWRzOw0KKwl1MTYgZWVwcm9tX3djOw0KKwl1MTYgZWVwcm9t WzI1Nl07DQorCXUzMiBwbV9zdGF0ZVsxNl07DQorfTsNCisNCitzdGF0aWMg aW5saW5lIHZvaWQgZTEwMF93cml0ZV9mbHVzaChzdHJ1Y3QgbmljICpuaWMp DQorew0KKwkvKiBGbHVzaCBwcmV2aW91cyBQQ0kgd3JpdGVzIHRocm91Z2gg aW50ZXJtZWRpYXRlIGJyaWRnZXMNCisJICogYnkgZG9pbmcgYSBiZW5pZ24g cmVhZCAqLw0KKwkodm9pZClyZWFkYigmbmljLT5jc3ItPnNjYi5zdGF0dXMp Ow0KK30NCisNCitzdGF0aWMgaW5saW5lIHZvaWQgZTEwMF9lbmFibGVfaXJx KHN0cnVjdCBuaWMgKm5pYykNCit7DQorCXdyaXRlYihpcnFfbWFza19ub25l LCAmbmljLT5jc3ItPnNjYi5jbWRfaGkpOw0KKwllMTAwX3dyaXRlX2ZsdXNo KG5pYyk7DQorfQ0KKw0KK3N0YXRpYyBpbmxpbmUgdm9pZCBlMTAwX2Rpc2Fi bGVfaXJxKHN0cnVjdCBuaWMgKm5pYykNCit7DQorCXdyaXRlYihpcnFfbWFz a19hbGwsICZuaWMtPmNzci0+c2NiLmNtZF9oaSk7DQorCWUxMDBfd3JpdGVf Zmx1c2gobmljKTsNCit9DQorDQorc3RhdGljIHZvaWQgZTEwMF9od19yZXNl dChzdHJ1Y3QgbmljICpuaWMpDQorew0KKwkvKiBQdXQgQ1UgYW5kIFJVIGlu dG8gaWRsZSB3aXRoIGEgc2VsZWN0aXZlIHJlc2V0IHRvIGdldA0KKwkgKiBk ZXZpY2Ugb2ZmIG9mIFBDSSBidXMgKi8NCisJd3JpdGVsKHNlbGVjdGl2ZV9y ZXNldCwgJm5pYy0+Y3NyLT5wb3J0KTsNCisJZTEwMF93cml0ZV9mbHVzaChu aWMpOyB1ZGVsYXkoMjApOw0KKw0KKwkvKiBOb3cgZnVsbHkgcmVzZXQgZGV2 aWNlICovDQorCXdyaXRlbChzb2Z0d2FyZV9yZXNldCwgJm5pYy0+Y3NyLT5w b3J0KTsNCisJZTEwMF93cml0ZV9mbHVzaChuaWMpOyB1ZGVsYXkoMjApOw0K Kw0KKwkvKiBUQ08gd29ya2Fyb3VuZCAtIDgyNTU5IGFuZCBncmVhdGVyICov DQorCWlmKG5pYy0+bWFjID49IG1hY184MjU1OV9EMTAxTSkgew0KKwkJLyog SXNzdWUgYSByZWR1bmRhbnQgQ1UgbG9hZCBiYXNlIHdpdGhvdXQgc2V0dGlu Zw0KKwkJICogZ2VuZXJhbCBwb2ludGVyLCBhbmQgd2l0aG91dCB3YWl0aW5n IGZvciBzY2IgdG8NCisJCSAqIGNsZWFyLiAgVGhpcyBnZXRzIHVzIGludG8g cG9zdC1kcml2ZXIuICBGaW5hbGx5LA0KKwkJICogd2FpdCAyMCBtc2VjIGZv ciByZXNldCB0byB0YWtlIGVmZmVjdC4gKi8NCisJCXdyaXRlYihjdWNfbG9h ZF9iYXNlLCAmbmljLT5jc3ItPnNjYi5jbWRfbG8pOw0KKwkJbWRlbGF5KDIw KTsNCisJfQ0KKw0KKwkvKiBNYXNrIG9mZiBvdXIgaW50ZXJydXB0IGxpbmUg LSBpdCdzIHVubWFza2VkIGFmdGVyIHJlc2V0ICovDQorCWUxMDBfZGlzYWJs ZV9pcnEobmljKTsNCit9DQorDQorc3RhdGljIGludCBlMTAwX3NlbGZfdGVz dChzdHJ1Y3QgbmljICpuaWMpDQorew0KKwl1MzIgZG1hX2FkZHIgPSBuaWMt PmRtYV9hZGRyICsgb2Zmc2V0b2Yoc3RydWN0IG1lbSwgc2VsZnRlc3QpOw0K Kw0KKwkvKiBQYXNzaW5nIHRoZSBzZWxmLXRlc3QgaXMgYSBwcmV0dHkgZ29v ZCBpbmRpY2F0aW9uDQorCSAqIHRoYXQgdGhlIGRldmljZSBjYW4gRE1BIHRv L2Zyb20gaG9zdCBtZW1vcnkgKi8NCisNCisJbmljLT5tZW0tPnNlbGZ0ZXN0 LnNpZ25hdHVyZSA9IDA7DQorCW5pYy0+bWVtLT5zZWxmdGVzdC5yZXN1bHQg PSAweEZGRkZGRkZGOw0KKw0KKwl3cml0ZWwoc2VsZnRlc3QgfCBkbWFfYWRk ciwgJm5pYy0+Y3NyLT5wb3J0KTsNCisJZTEwMF93cml0ZV9mbHVzaChuaWMp Ow0KKwkvKiBXYWl0IDEwIG1zZWMgZm9yIHNlbGYtdGVzdCB0byBjb21wbGV0 ZSAqLw0KKwlzZXRfY3VycmVudF9zdGF0ZShUQVNLX1VOSU5URVJSVVBUSUJM RSk7DQorCXNjaGVkdWxlX3RpbWVvdXQoSFogLyAxMDAgKyAxKTsNCisNCisJ LyogSW50ZXJydXB0cyBhcmUgZW5hYmxlZCBhZnRlciBzZWxmLXRlc3QgKi8N CisJZTEwMF9kaXNhYmxlX2lycShuaWMpOw0KKw0KKwkvKiBDaGVjayByZXN1 bHRzIG9mIHNlbGYtdGVzdCAqLw0KKwlpZihuaWMtPm1lbS0+c2VsZnRlc3Qu cmVzdWx0ICE9IDApIHsNCisJCURQUklOVEsoSFcsIEVSUiwgIlNlbGYtdGVz dCBmYWlsZWQ6IHJlc3VsdD0weCUwOFhcbiIsDQorCQkJbmljLT5tZW0tPnNl bGZ0ZXN0LnJlc3VsdCk7DQorCQlyZXR1cm4gLUVUSU1FRE9VVDsNCisJfQ0K KwlpZihuaWMtPm1lbS0+c2VsZnRlc3Quc2lnbmF0dXJlID09IDApIHsNCisJ CURQUklOVEsoSFcsIEVSUiwgIlNlbGYtdGVzdCBmYWlsZWQ6IHRpbWVkIG91 dFxuIik7DQorCQlyZXR1cm4gLUVUSU1FRE9VVDsNCisJfQ0KKw0KKwlyZXR1 cm4gMDsNCit9DQorDQorc3RhdGljIHZvaWQgZTEwMF9lZXByb21fd3JpdGUo c3RydWN0IG5pYyAqbmljLCB1MTYgYWRkcl9sZW4sIHUxNiBhZGRyLCB1MTYg ZGF0YSkNCit7DQorCXUzMiBjbWRfYWRkcl9kYXRhWzNdOw0KKwl1OCBjdHJs Ow0KKwlpbnQgaSwgajsNCisNCisJLyogVGhyZWUgY21kczogd3JpdGUvZXJh c2UgZW5hYmxlLCB3cml0ZSBkYXRhLCB3cml0ZS9lcmFzZSBkaXNhYmxlICov DQorCWNtZF9hZGRyX2RhdGFbMF0gPSBvcF9ld2VuIDw8IChhZGRyX2xlbiAt IDIpOw0KKwljbWRfYWRkcl9kYXRhWzFdID0gKCgob3Bfd3JpdGUgPDwgYWRk cl9sZW4pIHwgYWRkcikgPDwgMTYpIHwNCisJCWNwdV90b19sZTE2KGRhdGEp Ow0KKwljbWRfYWRkcl9kYXRhWzJdID0gb3BfZXdkcyA8PCAoYWRkcl9sZW4g LSAyKTsNCisNCisJLyogQml0LWJhbmcgY21kcyB0byB3cml0ZSB3b3JkIHRv IGVlcHJvbSAqLw0KKwlmb3IoaiA9IDA7IGogPCAzOyBqKyspIHsNCisNCisJ CS8qIENoaXAgc2VsZWN0ICovDQorCQl3cml0ZWIoZWVjcyB8IGVlc2ssICZu aWMtPmNzci0+ZWVwcm9tX2N0cmxfbG8pOw0KKwkJZTEwMF93cml0ZV9mbHVz aChuaWMpOyB1ZGVsYXkoNCk7DQorDQorCQlmb3IoaSA9IDMxOyBpID49IDA7 IGktLSkgew0KKwkJCWN0cmwgPSAoY21kX2FkZHJfZGF0YVtqXSAmICgxIDw8 IGkpKSA/DQorCQkJCWVlY3MgfCBlZWRpIDogZWVjczsNCisJCQl3cml0ZWIo Y3RybCwgJm5pYy0+Y3NyLT5lZXByb21fY3RybF9sbyk7DQorCQkJZTEwMF93 cml0ZV9mbHVzaChuaWMpOyB1ZGVsYXkoNCk7DQorDQorCQkJd3JpdGViKGN0 cmwgfCBlZXNrLCAmbmljLT5jc3ItPmVlcHJvbV9jdHJsX2xvKTsNCisJCQll MTAwX3dyaXRlX2ZsdXNoKG5pYyk7IHVkZWxheSg0KTsNCisJCX0NCisJCS8q IFdhaXQgMTAgbXNlYyBmb3IgY21kIHRvIGNvbXBsZXRlICovDQorCQlzZXRf Y3VycmVudF9zdGF0ZShUQVNLX1VOSU5URVJSVVBUSUJMRSk7DQorCQlzY2hl ZHVsZV90aW1lb3V0KEhaIC8gMTAwICsgMSk7DQorDQorCQkvKiBDaGlwIGRl c2VsZWN0ICovDQorCQl3cml0ZWIoMCwgJm5pYy0+Y3NyLT5lZXByb21fY3Ry bF9sbyk7DQorCQllMTAwX3dyaXRlX2ZsdXNoKG5pYyk7IHVkZWxheSg0KTsN CisJfQ0KK307DQorDQorLyogR2VuZXJhbCB0ZWNobmlxdWUgc3RvbGVuIGZy b20gdGhlIGVlcHJvMTAwIGRyaXZlciAtIHZlcnkgY2xldmVyICovDQorc3Rh dGljIHUxNiBlMTAwX2VlcHJvbV9yZWFkKHN0cnVjdCBuaWMgKm5pYywgdTE2 ICphZGRyX2xlbiwgdTE2IGFkZHIpDQorew0KKwl1MzIgY21kX2FkZHJfZGF0 YTsNCisJdTE2IGRhdGEgPSAwOw0KKwl1OCBjdHJsOw0KKwlpbnQgaTsNCisN CisJY21kX2FkZHJfZGF0YSA9ICgob3BfcmVhZCA8PCAqYWRkcl9sZW4pIHwg YWRkcikgPDwgMTY7DQorDQorCS8qIENoaXAgc2VsZWN0ICovDQorCXdyaXRl YihlZWNzIHwgZWVzaywgJm5pYy0+Y3NyLT5lZXByb21fY3RybF9sbyk7DQor CWUxMDBfd3JpdGVfZmx1c2gobmljKTsgdWRlbGF5KDQpOw0KKw0KKwkvKiBC aXQtYmFuZyB0byByZWFkIHdvcmQgZnJvbSBlZXByb20gKi8NCisJZm9yKGkg PSAzMTsgaSA+PSAwOyBpLS0pIHsNCisJCWN0cmwgPSAoY21kX2FkZHJfZGF0 YSAmICgxIDw8IGkpKSA/IGVlY3MgfCBlZWRpIDogZWVjczsNCisJCXdyaXRl YihjdHJsLCAmbmljLT5jc3ItPmVlcHJvbV9jdHJsX2xvKTsNCisJCWUxMDBf d3JpdGVfZmx1c2gobmljKTsgdWRlbGF5KDQpOw0KKwkJDQorCQl3cml0ZWIo Y3RybCB8IGVlc2ssICZuaWMtPmNzci0+ZWVwcm9tX2N0cmxfbG8pOw0KKwkJ ZTEwMF93cml0ZV9mbHVzaChuaWMpOyB1ZGVsYXkoNCk7DQorCQkNCisJCS8q IEVlcHJvbSBkcml2ZXMgYSBkdW1teSB6ZXJvIHRvIEVFRE8gYWZ0ZXIgcmVj ZWl2aW5nDQorCQkgKiBjb21wbGV0ZSBhZGRyZXNzLiAgVXNlIHRoaXMgdG8g YWRqdXN0IGFkZHJfbGVuLiAqLw0KKwkJY3RybCA9IHJlYWRiKCZuaWMtPmNz ci0+ZWVwcm9tX2N0cmxfbG8pOw0KKwkJaWYoIShjdHJsICYgZWVkbykgJiYg aSA+IDE2KSB7DQorCQkJKmFkZHJfbGVuIC09IChpIC0gMTYpOw0KKwkJCWkg PSAxNzsNCisJCX0NCisJCQ0KKwkJZGF0YSA9IChkYXRhIDw8IDEpIHwgKGN0 cmwgJiBlZWRvID8gMSA6IDApOw0KKwl9DQorDQorCS8qIENoaXAgZGVzZWxl Y3QgKi8NCisJd3JpdGViKDAsICZuaWMtPmNzci0+ZWVwcm9tX2N0cmxfbG8p Ow0KKwllMTAwX3dyaXRlX2ZsdXNoKG5pYyk7IHVkZWxheSg0KTsNCisNCisJ cmV0dXJuIGxlMTZfdG9fY3B1KGRhdGEpOw0KK307DQorDQorLyogTG9hZCBl bnRpcmUgRUVQUk9NIGltYWdlIGludG8gZHJpdmVyIGNhY2hlIGFuZCB2YWxp ZGF0ZSBjaGVja3N1bSAqLw0KK3N0YXRpYyBpbnQgZTEwMF9lZXByb21fbG9h ZChzdHJ1Y3QgbmljICpuaWMpDQorew0KKwl1MTYgYWRkciwgYWRkcl9sZW4g PSA4LCBjaGVja3N1bSA9IDA7DQorDQorCS8qIFRyeSByZWFkaW5nIHdpdGgg YW4gOC1iaXQgYWRkciBsZW4gdG8gZGlzY292ZXIgYWN0dWFsIGFkZHIgbGVu ICovDQorCWUxMDBfZWVwcm9tX3JlYWQobmljLCAmYWRkcl9sZW4sIDApOw0K KwluaWMtPmVlcHJvbV93YyA9IDEgPDwgYWRkcl9sZW47DQorDQorCWZvcihh ZGRyID0gMDsgYWRkciA8IG5pYy0+ZWVwcm9tX3djOyBhZGRyKyspIHsNCisJ CW5pYy0+ZWVwcm9tW2FkZHJdID0gZTEwMF9lZXByb21fcmVhZChuaWMsICZh ZGRyX2xlbiwgYWRkcik7DQorCQlpZihhZGRyIDwgbmljLT5lZXByb21fd2Mg LSAxKQ0KKwkJCWNoZWNrc3VtICs9IGNwdV90b19sZTE2KG5pYy0+ZWVwcm9t W2FkZHJdKTsNCisJfQ0KKw0KKwkvKiBUaGUgY2hlY2tzdW0sIHN0b3JlZCBp biB0aGUgbGFzdCB3b3JkLCBpcyBjYWxjdWxhdGVkIHN1Y2ggdGhhdA0KKwkg KiB0aGUgc3VtIG9mIHdvcmRzIHNob3VsZCBiZSAweEJBQkEgKi8NCisJY2hl Y2tzdW0gPSBsZTE2X3RvX2NwdSgweEJBQkEgLSBjaGVja3N1bSk7DQorCWlm KGNoZWNrc3VtICE9IG5pYy0+ZWVwcm9tW25pYy0+ZWVwcm9tX3djIC0gMV0p IHsNCisJCURQUklOVEsoUFJPQkUsIEVSUiwgIkVFUFJPTSBjb3JydXB0ZWRc biIpOw0KKwkJcmV0dXJuIC1FQUdBSU47DQorCX0NCisNCisJcmV0dXJuIDA7 DQorfQ0KKw0KKy8qIFNhdmUgKHBvcnRpb24gb2YpIGRyaXZlciBFRVBST00g Y2FjaGUgdG8gZGV2aWNlIGFuZCB1cGRhdGUgY2hlY2tzdW0gKi8NCitzdGF0 aWMgaW50IGUxMDBfZWVwcm9tX3NhdmUoc3RydWN0IG5pYyAqbmljLCB1MTYg c3RhcnQsIHUxNiBjb3VudCkNCit7DQorCXUxNiBhZGRyLCBhZGRyX2xlbiA9 IDgsIGNoZWNrc3VtID0gMDsNCisNCisJLyogVHJ5IHJlYWRpbmcgd2l0aCBh biA4LWJpdCBhZGRyIGxlbiB0byBkaXNjb3ZlciBhY3R1YWwgYWRkciBsZW4g Ki8NCisJZTEwMF9lZXByb21fcmVhZChuaWMsICZhZGRyX2xlbiwgMCk7DQor CW5pYy0+ZWVwcm9tX3djID0gMSA8PCBhZGRyX2xlbjsNCisNCisJaWYoc3Rh cnQgKyBjb3VudCA+PSBuaWMtPmVlcHJvbV93YykNCisJCXJldHVybiAtRUlO VkFMOw0KKw0KKwlmb3IoYWRkciA9IHN0YXJ0OyBhZGRyIDwgc3RhcnQgKyBj b3VudDsgYWRkcisrKQ0KKwkJZTEwMF9lZXByb21fd3JpdGUobmljLCBhZGRy X2xlbiwgYWRkciwgbmljLT5lZXByb21bYWRkcl0pOw0KKw0KKwkvKiBUaGUg Y2hlY2tzdW0sIHN0b3JlZCBpbiB0aGUgbGFzdCB3b3JkLCBpcyBjYWxjdWxh dGVkIHN1Y2ggdGhhdA0KKwkgKiB0aGUgc3VtIG9mIHdvcmRzIHNob3VsZCBi ZSAweEJBQkEgKi8NCisJZm9yKGFkZHIgPSAwOyBhZGRyIDwgbmljLT5lZXBy b21fd2MgLSAxOyBhZGRyKyspDQorCQljaGVja3N1bSArPSBjcHVfdG9fbGUx NihuaWMtPmVlcHJvbVthZGRyXSk7DQorCW5pYy0+ZWVwcm9tW25pYy0+ZWVw cm9tX3djIC0gMV0gPSBsZTE2X3RvX2NwdSgweEJBQkEgLSBjaGVja3N1bSk7 DQorCWUxMDBfZWVwcm9tX3dyaXRlKG5pYywgYWRkcl9sZW4sIG5pYy0+ZWVw cm9tX3djIC0gMSwNCisJCW5pYy0+ZWVwcm9tW25pYy0+ZWVwcm9tX3djIC0g MV0pOw0KKw0KKwlyZXR1cm4gMDsNCit9DQorDQorI2RlZmluZSBFMTAwX1dB SVRfU0NCX1RJTUVPVVQgNDANCitzdGF0aWMgaW5saW5lIGludCBlMTAwX2V4 ZWNfY21kKHN0cnVjdCBuaWMgKm5pYywgdTggY21kLCBkbWFfYWRkcl90IGRt YV9hZGRyKQ0KK3sNCisJdW5zaWduZWQgbG9uZyBmbGFnczsNCisJdW5zaWdu ZWQgaW50IGk7DQorCWludCBlcnIgPSAwOw0KKw0KKwlzcGluX2xvY2tfaXJx c2F2ZSgmbmljLT5jbWRfbG9jaywgZmxhZ3MpOw0KKw0KKwkvKiBQcmV2aW91 cyBjb21tYW5kIGlzIGFjY2VwdGVkIHdoZW4gU0NCIGNsZWFycyAqLw0KKwlm b3IoaSA9IDA7IGkgPCBFMTAwX1dBSVRfU0NCX1RJTUVPVVQ7IGkrKykgew0K KwkJaWYobGlrZWx5KCFyZWFkYigmbmljLT5jc3ItPnNjYi5jbWRfbG8pKSkN CisJCQlicmVhazsNCisJCWNwdV9yZWxheCgpOw0KKwkJaWYodW5saWtlbHko aSA+IChFMTAwX1dBSVRfU0NCX1RJTUVPVVQgPj4gMSkpKQ0KKwkJCXVkZWxh eSg1KTsNCisJfQ0KKwlpZih1bmxpa2VseShpID09IEUxMDBfV0FJVF9TQ0Jf VElNRU9VVCkpIHsNCisJCWVyciA9IC1FQUdBSU47DQorCQlnb3RvIGVycl91 bmxvY2s7DQorCX0NCisNCisJaWYodW5saWtlbHkoY21kICE9IGN1Y19yZXN1 bWUpKQ0KKwkJd3JpdGVsKGRtYV9hZGRyLCAmbmljLT5jc3ItPnNjYi5nZW5f cHRyKTsNCisJd3JpdGViKGNtZCwgJm5pYy0+Y3NyLT5zY2IuY21kX2xvKTsN CisNCitlcnJfdW5sb2NrOg0KKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZu aWMtPmNtZF9sb2NrLCBmbGFncyk7DQorDQorCXJldHVybiBlcnI7DQorfQ0K Kw0KK3N0YXRpYyBpbmxpbmUgaW50IGUxMDBfZXhlY19jYihzdHJ1Y3Qgbmlj ICpuaWMsIHN0cnVjdCBza19idWZmICpza2IsDQorCXZvaWQgKCpjYl9wcmVw YXJlKShzdHJ1Y3QgbmljICosIHN0cnVjdCBjYiAqLCBzdHJ1Y3Qgc2tfYnVm ZiAqKSkNCit7DQorCXN0cnVjdCBjYiAqY2I7DQorCXVuc2lnbmVkIGxvbmcg ZmxhZ3M7DQorCWludCBlcnIgPSAwOw0KKw0KKwlzcGluX2xvY2tfaXJxc2F2 ZSgmbmljLT5jYl9sb2NrLCBmbGFncyk7DQorDQorCWlmKHVubGlrZWx5KCFu aWMtPmNic19hdmFpbCkpIHsNCisJCWVyciA9IC1FTk9NRU07DQorCQlnb3Rv IGVycl91bmxvY2s7DQorCX0NCisNCisJY2IgPSBuaWMtPmNiX3RvX3VzZTsN CisJbmljLT5jYl90b191c2UgPSBjYi0+bmV4dDsNCisJbmljLT5jYnNfYXZh aWwtLTsNCisJY2ItPnNrYiA9IHNrYjsNCisNCisJaWYodW5saWtlbHkoIW5p Yy0+Y2JzX2F2YWlsKSkNCisJCWVyciA9IC1FTk9TUEM7DQorDQorCWNiX3By ZXBhcmUobmljLCBjYiwgc2tiKTsNCisNCisJLyogT3JkZXIgaXMgaW1wb3J0 YW50IG90aGVyd2lzZSB3ZSdsbCBiZSBpbiBhIHJhY2Ugd2l0aCBoL3c6DQor CSAqIHNldCBTLWJpdCBpbiBjdXJyZW50IGZpcnN0LCB0aGVuIGNsZWFyIFMt Yml0IGluIHByZXZpb3VzLiAqLw0KKwljYi0+Y29tbWFuZCB8PSBjcHVfdG9f bGUxNihjYl9zKTsNCisJd21iKCk7DQorCWNiLT5wcmV2LT5jb21tYW5kICY9 IGNwdV90b19sZTE2KH5jYl9zKTsNCisNCisJd2hpbGUobmljLT5jYl90b19z ZW5kICE9IG5pYy0+Y2JfdG9fdXNlKSB7DQorCQlpZih1bmxpa2VseShlMTAw X2V4ZWNfY21kKG5pYywgbmljLT5jdWNfY21kLA0KKwkJCW5pYy0+Y2JfdG9f c2VuZC0+ZG1hX2FkZHIpKSkgew0KKwkJCS8qIE9rLCBoZXJlJ3Mgd2hlcmUg dGhpbmdzIGdldCBzdGlja3kuICBJdCdzDQorCQkJICogcG9zc2libGUgdGhh dCB3ZSBjYW4ndCBzY2hlZHVsZSB0aGUgY29tbWFuZA0KKwkJCSAqIGJlY2F1 c2UgdGhlIGNvbnRyb2xsZXIgaXMgdG9vIGJ1c3ksIHNvDQorCQkJICogbGV0 J3MganVzdCBxdWV1ZSB0aGUgY29tbWFuZCBhbmQgdHJ5IGFnYWluDQorCQkJ ICogd2hlbiBhbm90aGVyIGNvbW1hbmQgaXMgc2NoZWR1bGVkLiAqLw0KKwkJ CWJyZWFrOw0KKwkJfSBlbHNlIHsNCisJCQluaWMtPmN1Y19jbWQgPSBjdWNf cmVzdW1lOw0KKwkJCW5pYy0+Y2JfdG9fc2VuZCA9IG5pYy0+Y2JfdG9fc2Vu ZC0+bmV4dDsNCisJCX0NCisJfQ0KKw0KK2Vycl91bmxvY2s6DQorCXNwaW5f dW5sb2NrX2lycXJlc3RvcmUoJm5pYy0+Y2JfbG9jaywgZmxhZ3MpOw0KKw0K KwlyZXR1cm4gZXJyOw0KK30NCisNCitzdGF0aWMgdTE2IG1kaW9fY3RybChz dHJ1Y3QgbmljICpuaWMsIHUzMiBhZGRyLCB1MzIgZGlyLCB1MzIgcmVnLCB1 MTYgZGF0YSkNCit7DQorCXUzMiBkYXRhX291dCA9IDA7DQorCXVuc2lnbmVk IGludCBpOw0KKw0KKwl3cml0ZWwoKHJlZyA8PCAxNikgfCAoYWRkciA8PCAy MSkgfCBkaXIgfCBkYXRhLCAmbmljLT5jc3ItPm1kaV9jdHJsKTsNCisNCisJ Zm9yKGkgPSAwOyBpIDwgMTAwOyBpKyspIHsNCisJCXVkZWxheSgyMCk7DQor CQlpZigoZGF0YV9vdXQgPSByZWFkbCgmbmljLT5jc3ItPm1kaV9jdHJsKSkg JiBtZGlfcmVhZHkpDQorCQkJYnJlYWs7DQorCX0NCisNCisJRFBSSU5USyhI VywgREVCVUcsDQorCQkiJXM6YWRkcj0lZCwgcmVnPSVkLCBkYXRhX2luPTB4 JTA0WCwgZGF0YV9vdXQ9MHglMDRYXG4iLA0KKwkJZGlyID09IG1kaV9yZWFk ID8gIlJFQUQiIDogIldSSVRFIiwgYWRkciwgcmVnLCBkYXRhLCBkYXRhX291 dCk7DQorCXJldHVybiAodTE2KWRhdGFfb3V0Ow0KK30NCisNCitzdGF0aWMg aW50IG1kaW9fcmVhZChzdHJ1Y3QgbmV0X2RldmljZSAqbmV0ZGV2LCBpbnQg YWRkciwgaW50IHJlZykNCit7DQorCXJldHVybiBtZGlvX2N0cmwobmV0ZGV2 X3ByaXYobmV0ZGV2KSwgYWRkciwgbWRpX3JlYWQsIHJlZywgMCk7DQorfQ0K Kw0KK3N0YXRpYyB2b2lkIG1kaW9fd3JpdGUoc3RydWN0IG5ldF9kZXZpY2Ug Km5ldGRldiwgaW50IGFkZHIsIGludCByZWcsIGludCBkYXRhKQ0KK3sNCisJ bWRpb19jdHJsKG5ldGRldl9wcml2KG5ldGRldiksIGFkZHIsIG1kaV93cml0 ZSwgcmVnLCBkYXRhKTsNCit9DQorDQorc3RhdGljIHZvaWQgZTEwMF9nZXRf ZGVmYXVsdHMoc3RydWN0IG5pYyAqbmljKQ0KK3sNCisJc3RydWN0IHBhcmFt X3JhbmdlIHJmZHMgPSB7IC5taW4gPSA2NCwgLm1heCA9IDI1NiwgLmNvdW50 ID0gNjQgfTsNCisJc3RydWN0IHBhcmFtX3JhbmdlIGNicyAgPSB7IC5taW4g PSA2NCwgLm1heCA9IDI1NiwgLmNvdW50ID0gNjQgfTsNCisNCisJcGNpX3Jl YWRfY29uZmlnX2J5dGUobmljLT5wZGV2LCBQQ0lfUkVWSVNJT05fSUQsICZu aWMtPnJldl9pZCk7DQorCS8qIE1BQyB0eXBlIGlzIGVuY29kZWQgYXMgcmV2 IElEOyBleGNlcHRpb246IElDSCBpcyB0cmVhdGVkIGFzIDgyNTU5ICovDQor CW5pYy0+bWFjID0gKG5pYy0+ZmxhZ3MgJiBpY2gpID8gbWFjXzgyNTU5X0Qx MDFNIDogbmljLT5yZXZfaWQ7DQorCWlmKG5pYy0+bWFjID09IG1hY191bmtu b3duKQ0KKwkJbmljLT5tYWMgPSBtYWNfODI1NTdfRDEwMF9BOw0KKw0KKwlu aWMtPnBhcmFtcy5yZmRzID0gcmZkczsNCisJbmljLT5wYXJhbXMuY2JzID0g Y2JzOw0KKw0KKwkvKiBRdWFkd29yZHMgdG8gRE1BIGludG8gRklGTyBiZWZv cmUgc3RhcnRpbmcgZnJhbWUgdHJhbnNtaXQgKi8NCisJbmljLT50eF90aHJl c2hvbGQgPSAweEUwOw0KKw0KKwluaWMtPnR4X2NvbW1hbmQgPSBjcHVfdG9f bGUxNihjYl90eCB8IGNiX2kgfCBjYl90eF9zZiB8DQorCQkoKG5pYy0+bWFj ID49IG1hY184MjU1OF9EMTAxX0E0KSA/IGNiX2NpZCA6IDApKTsNCisNCisJ LyogVGVtcGxhdGUgZm9yIGEgZnJlc2hseSBhbGxvY2F0ZWQgUkZEICovDQor CW5pYy0+YmxhbmtfcmZkLmNvbW1hbmQgPSBjcHVfdG9fbGUxNihjYl9lbCk7 DQorCW5pYy0+YmxhbmtfcmZkLnJiZCA9IDB4RkZGRkZGRkY7DQorCW5pYy0+ YmxhbmtfcmZkLnNpemUgPSBjcHVfdG9fbGUxNihWTEFOX0VUSF9GUkFNRV9M RU4pOw0KKw0KKwkvKiBNSUkgc2V0dXAgKi8NCisJbmljLT5taWkucGh5X2lk X21hc2sgPSAweDFGOw0KKwluaWMtPm1paS5yZWdfbnVtX21hc2sgPSAweDFG Ow0KKwluaWMtPm1paS5kZXYgPSBuaWMtPm5ldGRldjsNCisJbmljLT5taWku bWRpb19yZWFkID0gbWRpb19yZWFkOw0KKwluaWMtPm1paS5tZGlvX3dyaXRl ID0gbWRpb193cml0ZTsNCit9DQorDQorc3RhdGljIHZvaWQgZTEwMF9jb25m aWd1cmUoc3RydWN0IG5pYyAqbmljLCBzdHJ1Y3QgY2IgKmNiLCBzdHJ1Y3Qg c2tfYnVmZiAqc2tiKQ0KK3sNCisJc3RydWN0IGNvbmZpZyAqY29uZmlnID0g JmNiLT51LmNvbmZpZzsNCisJdTggKmMgPSAodTggKiljb25maWc7DQorDQor CWNiLT5jb21tYW5kID0gY3B1X3RvX2xlMTYoY2JfY29uZmlnKTsNCisNCisJ bWVtc2V0KGNvbmZpZywgMCwgc2l6ZW9mKHN0cnVjdCBjb25maWcpKTsNCisN CisJY29uZmlnLT5ieXRlX2NvdW50ID0gMHgxNjsJCS8qIGJ5dGVzIGluIHRo aXMgc3RydWN0ICovDQorCWNvbmZpZy0+cnhfZmlmb19saW1pdCA9IDB4ODsJ CS8qIGJ5dGVzIGluIEZJRk8gYmVmb3JlIERNQSAqLw0KKwljb25maWctPmRp cmVjdF9yeF9kbWEgPSAweDE7CQkvKiByZXNlcnZlZCAqLw0KKwljb25maWct PnN0YW5kYXJkX3RjYiA9IDB4MTsJCS8qIDE9c3RhbmRhcmQsIDA9ZXh0ZW5k ZWQgKi8NCisJY29uZmlnLT5zdGFuZGFyZF9zdGF0X2NvdW50ZXIgPSAweDE7 CS8qIDE9c3RhbmRhcmQsIDA9ZXh0ZW5kZWQgKi8NCisJY29uZmlnLT5yeF9k aXNjYXJkX3Nob3J0X2ZyYW1lcyA9IDB4MTsJLyogMT1kaXNjYXJkLCAwPXBh c3MgKi8NCisJY29uZmlnLT50eF91bmRlcnJ1bl9yZXRyeSA9IDB4MzsJLyog IyBvZiB1bmRlcnJ1biByZXRyaWVzICovDQorCWNvbmZpZy0+bWlpX21vZGUg PSAweDE7CQkJLyogMT1NSUkgbW9kZSwgMD01MDMgbW9kZSAqLw0KKwljb25m aWctPnBhZDEwID0gMHg2Ow0KKwljb25maWctPm5vX3NvdXJjZV9hZGRyX2lu c2VydGlvbiA9IDB4MTsJLyogMT1ubywgMD15ZXMgKi8NCisJY29uZmlnLT5w cmVhbWJsZV9sZW5ndGggPSAweDI7CQkvKiAwPTEsIDE9MywgMj03LCAzPTE1 IGJ5dGVzICovDQorCWNvbmZpZy0+aWZzID0gMHg2OwkJCS8qIHgxNiA9IGlu dGVyIGZyYW1lIHNwYWNpbmcgKi8NCisJY29uZmlnLT5pcF9hZGRyX2hpID0g MHhGMjsJCS8qIEFSUCBJUCBmaWx0ZXIgLSBub3QgdXNlZCAqLw0KKwljb25m aWctPnBhZDE1XzEgPSAweDE7DQorCWNvbmZpZy0+cGFkMTVfMiA9IDB4MTsN CisJY29uZmlnLT5jcnNfb3JfY2R0ID0gMHgwOwkJLyogMD1DUlMgb25seSwg MT1DUlMgb3IgQ0RUICovDQorCWNvbmZpZy0+ZmNfZGVsYXlfaGkgPSAweDQw OwkJLyogdGltZSBkZWxheSBmb3IgZmMgZnJhbWUgKi8NCisJY29uZmlnLT50 eF9wYWRkaW5nID0gMHgxOwkJLyogMT1wYWQgc2hvcnQgZnJhbWVzICovDQor CWNvbmZpZy0+ZmNfcHJpb3JpdHlfdGhyZXNob2xkID0gMHg3OwkvKiA3PXBy aW9yaXR5IGZjIGRpc2FibGVkICovDQorCWNvbmZpZy0+cGFkMTggPSAweDE7 DQorCWNvbmZpZy0+ZnVsbF9kdXBsZXhfcGluID0gMHgxOwkJLyogMT1leGFt aW5lIEZEWCMgcGluICovDQorCWNvbmZpZy0+cGFkMjBfMSA9IDB4MUY7DQor CWNvbmZpZy0+ZmNfcHJpb3JpdHlfbG9jYXRpb24gPSAweDE7CS8qIDE9Ynl0 ZSMzMSwgMD1ieXRlIzE5ICovDQorCWNvbmZpZy0+cGFkMjFfMSA9IDB4NTsN CisNCisJY29uZmlnLT5hZGFwdGl2ZV9pZnMgPSBuaWMtPmFkYXB0aXZlX2lm czsNCisJY29uZmlnLT5sb29wYmFjayA9IG5pYy0+bG9vcGJhY2s7DQorDQor CWlmKG5pYy0+bWlpLmZvcmNlX21lZGlhICYmIG5pYy0+bWlpLmZ1bGxfZHVw bGV4KQ0KKwkJY29uZmlnLT5mdWxsX2R1cGxleF9mb3JjZSA9IDB4MTsJLyog MT1mb3JjZSwgMD1hdXRvICovDQorDQorCWlmKG5pYy0+ZmxhZ3MgJiBwcm9t aXNjdW91cyB8fCBuaWMtPmxvb3BiYWNrKSB7DQorCQljb25maWctPnJ4X3Nh dmVfYmFkX2ZyYW1lcyA9IDB4MTsJLyogMT1zYXZlLCAwPWRpc2NhcmQgKi8N CisJCWNvbmZpZy0+cnhfZGlzY2FyZF9zaG9ydF9mcmFtZXMgPSAweDA7CS8q IDE9ZGlzY2FyZCwgMD1zYXZlICovDQorCQljb25maWctPnByb21pc2N1b3Vz X21vZGUgPSAweDE7CQkvKiAxPW9uLCAwPW9mZiAqLw0KKwl9DQorDQorCWlm KG5pYy0+ZmxhZ3MgJiBtdWx0aWNhc3RfYWxsKQ0KKwkJY29uZmlnLT5tdWx0 aWNhc3RfYWxsID0gMHgxOwkJLyogMT1hY2NlcHQsIDA9bm8gKi8NCisNCisJ aWYoIShuaWMtPmZsYWdzICYgd29sX21hZ2ljKSkNCisJCWNvbmZpZy0+bWFn aWNfcGFja2V0X2Rpc2FibGUgPSAweDE7CS8qIDE9b2ZmLCAwPW9uICovDQor DQorCWlmKG5pYy0+bWFjID49IG1hY184MjU1OF9EMTAxX0E0KSB7DQorCQlj b25maWctPmZjX2Rpc2FibGUgPSAweDE7CS8qIDE9VHggZmMgb2ZmLCAwPVR4 IGZjIG9uICovDQorCQljb25maWctPm13aV9lbmFibGUgPSAweDE7CS8qIDE9 ZW5hYmxlLCAwPWRpc2FibGUgKi8NCisJCWNvbmZpZy0+c3RhbmRhcmRfdGNi ID0gMHgwOwkvKiAxPXN0YW5kYXJkLCAwPWV4dGVuZGVkICovDQorCQljb25m aWctPnJ4X2xvbmdfb2sgPSAweDE7CS8qIDE9VkxBTnMgb2ssIDA9c3RhbmRh cmQgKi8NCisJCWlmKG5pYy0+bWFjID49IG1hY184MjU1OV9EMTAxTSkNCisJ CQljb25maWctPnRub19pbnRyID0gMHgxOwkJLyogVENPIHN0YXRzIGVuYWJs ZSAqLw0KKwkJZWxzZQ0KKwkJCWNvbmZpZy0+c3RhbmRhcmRfc3RhdF9jb3Vu dGVyID0gMHgwOw0KKwl9DQorDQorCURQUklOVEsoSFcsIERFQlVHLCAiWzAw LTA3XT0lMDJYOiUwMlg6JTAyWDolMDJYOiUwMlg6JTAyWDolMDJYOiUwMlhc biIsDQorCQljWzBdLCBjWzFdLCBjWzJdLCBjWzNdLCBjWzRdLCBjWzVdLCBj WzZdLCBjWzddKTsNCisJRFBSSU5USyhIVywgREVCVUcsICJbMDgtMTVdPSUw Mlg6JTAyWDolMDJYOiUwMlg6JTAyWDolMDJYOiUwMlg6JTAyWFxuIiwNCisJ CWNbOF0sIGNbOV0sIGNbMTBdLCBjWzExXSwgY1sxMl0sIGNbMTNdLCBjWzE0 XSwgY1sxNV0pOw0KKwlEUFJJTlRLKEhXLCBERUJVRywgIlsxNi0yM109JTAy WDolMDJYOiUwMlg6JTAyWDolMDJYOiUwMlg6JTAyWDolMDJYXG4iLA0KKwkJ Y1sxNl0sIGNbMTddLCBjWzE4XSwgY1sxOV0sIGNbMjBdLCBjWzIxXSwgY1sy Ml0sIGNbMjNdKTsNCit9DQorDQorc3RhdGljIHZvaWQgZTEwMF9sb2FkX3Vj b2RlKHN0cnVjdCBuaWMgKm5pYywgc3RydWN0IGNiICpjYiwgc3RydWN0IHNr X2J1ZmYgKnNrYikNCit7DQorCWludCBpOw0KKwlzdGF0aWMgY29uc3QgdTMy IHVjb2RlW1VDT0RFX1NJWkVdID0gew0KKwkJLyogTkZTIHBhY2tldHMgYXJl IG1pc2ludGVycHJldGVkIGFzIFRDTyBwYWNrZXRzIGFuZA0KKwkJICogaW5j b3JyZWN0bHkgcm91dGVkIHRvIHRoZSBCTUMgb3ZlciBTTUJ1cy4gIFRoaXMN CisJCSAqIG1pY3JvY29kZSBwYXRjaCBjaGVja3MgdGhlIGZyYWdtZW50ZWQg SVAgYml0IGluIHRoZQ0KKwkJICogTkZTL1VEUCBoZWFkZXIgdG8gZGlzdGlu Z3Vpc2ggYmV0d2VlbiBORlMgYW5kIFRDTy4gKi8NCisJCTB4MEVGNzBFMzYs IDB4MUZGRjFGRkYsIDB4MUZGRjFGRkYsIDB4MUZGRjFGRkYsIDB4MUZGRjFG RkYsDQorCQkweDFGRkYxRkZGLCAweDAwOTA2RTQxLCAweDAwODAwRTNDLCAw eDAwRTAwRTM5LCAweDAwMDAwMDAwLA0KKwkJMHgwMDkwNkVGRCwgMHgwMDkw MEVGRCwJMHgwMEUwMEVGOCwNCisJfTsNCisNCisJaWYobmljLT5tYWMgPT0g bWFjXzgyNTUxX0YgfHwgbmljLT5tYWMgPT0gbWFjXzgyNTUxXzEwKSB7DQor CQlmb3IoaSA9IDA7IGkgPCBVQ09ERV9TSVpFOyBpKyspDQorCQkJY2ItPnUu dWNvZGVbaV0gPSBjcHVfdG9fbGUzMih1Y29kZVtpXSk7DQorCQljYi0+Y29t bWFuZCA9IGNwdV90b19sZTE2KGNiX3Vjb2RlKTsNCisJfSBlbHNlDQorCQlj Yi0+Y29tbWFuZCA9IGNwdV90b19sZTE2KGNiX25vcCk7DQorfQ0KKw0KK3N0 YXRpYyB2b2lkIGUxMDBfc2V0dXBfaWFhZGRyKHN0cnVjdCBuaWMgKm5pYywg c3RydWN0IGNiICpjYiwNCisJc3RydWN0IHNrX2J1ZmYgKnNrYikNCit7DQor CWNiLT5jb21tYW5kID0gY3B1X3RvX2xlMTYoY2JfaWFhZGRyKTsNCisJbWVt Y3B5KGNiLT51LmlhYWRkciwgbmljLT5uZXRkZXYtPmRldl9hZGRyLCBFVEhf QUxFTik7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGUxMDBfZHVtcChzdHJ1Y3Qg bmljICpuaWMsIHN0cnVjdCBjYiAqY2IsIHN0cnVjdCBza19idWZmICpza2Ip DQorew0KKwljYi0+Y29tbWFuZCA9IGNwdV90b19sZTE2KGNiX2R1bXApOw0K KwljYi0+dS5kdW1wX2J1ZmZlcl9hZGRyID0gY3B1X3RvX2xlMzIobmljLT5k bWFfYWRkciArDQorCQlvZmZzZXRvZihzdHJ1Y3QgbWVtLCBkdW1wX2J1Zikp Ow0KK30NCisNCisjZGVmaW5lIE5DT05GSUdfQVVUT19TV0lUQ0gJMHgwMDgw DQorI2RlZmluZSBNSUlfTlNDX0NPTkcJCU1JSV9SRVNWMQ0KKyNkZWZpbmUg TlNDX0NPTkdfRU5BQkxFCQkweDAxMDANCisjZGVmaW5lIE5TQ19DT05HX1RY UkVBRFkJMHgwNDAwDQorI2RlZmluZSBBRFZFUlRJU0VfRkNfU1VQUE9SVEVE CTB4MDQwMA0KK3N0YXRpYyBpbnQgZTEwMF9waHlfaW5pdChzdHJ1Y3Qgbmlj ICpuaWMpDQorew0KKwlzdHJ1Y3QgbmV0X2RldmljZSAqbmV0ZGV2ID0gbmlj LT5uZXRkZXY7DQorCXUzMiBhZGRyOw0KKwl1MTYgYm1jciwgc3RhdCwgaWRf bG8sIGlkX2hpLCBjb25nOw0KKw0KKwkvKiBEaXNjb3ZlciBwaHkgYWRkciBi eSBzZWFyY2hpbmcgYWRkcnMgaW4gb3JkZXIgezEsMCwyLC4uLiwgMzF9ICov DQorCWZvcihhZGRyID0gMDsgYWRkciA8IDMyOyBhZGRyKyspIHsNCisJCW5p Yy0+bWlpLnBoeV9pZCA9IChhZGRyID09IDApID8gMSA6IChhZGRyID09IDEp ID8gMCA6IGFkZHI7DQorCQlibWNyID0gbWRpb19yZWFkKG5ldGRldiwgbmlj LT5taWkucGh5X2lkLCBNSUlfQk1DUik7DQorCQlzdGF0ID0gbWRpb19yZWFk KG5ldGRldiwgbmljLT5taWkucGh5X2lkLCBNSUlfQk1TUik7DQorCQlzdGF0 ID0gbWRpb19yZWFkKG5ldGRldiwgbmljLT5taWkucGh5X2lkLCBNSUlfQk1T Uik7DQorCQlpZighKChibWNyID09IDB4RkZGRikgfHwgKChzdGF0ID09IDAp ICYmIChibWNyID09IDApKSkpDQorCQkJYnJlYWs7DQorCX0NCisJRFBSSU5U SyhIVywgREVCVUcsICJwaHlfYWRkciA9ICVkXG4iLCBuaWMtPm1paS5waHlf aWQpOw0KKwlpZihhZGRyID09IDMyKQ0KKwkJcmV0dXJuIC1FQUdBSU47DQor DQorCS8qIFNlbGVjdGVkIHRoZSBwaHkgYW5kIGlzb2xhdGUgdGhlIHJlc3Qg Ki8NCisJZm9yKGFkZHIgPSAwOyBhZGRyIDwgMzI7IGFkZHIrKykgew0KKwkJ aWYoYWRkciAhPSBuaWMtPm1paS5waHlfaWQpIHsNCisJCQltZGlvX3dyaXRl KG5ldGRldiwgYWRkciwgTUlJX0JNQ1IsIEJNQ1JfSVNPTEFURSk7DQorCQl9 IGVsc2Ugew0KKwkJCWJtY3IgPSBtZGlvX3JlYWQobmV0ZGV2LCBhZGRyLCBN SUlfQk1DUik7DQorCQkJbWRpb193cml0ZShuZXRkZXYsIGFkZHIsIE1JSV9C TUNSLA0KKwkJCQlibWNyICYgfkJNQ1JfSVNPTEFURSk7DQorCQl9DQorCX0N CisNCisJLyogR2V0IHBoeSBJRCAqLw0KKwlpZF9sbyA9IG1kaW9fcmVhZChu ZXRkZXYsIG5pYy0+bWlpLnBoeV9pZCwgTUlJX1BIWVNJRDEpOw0KKwlpZF9o aSA9IG1kaW9fcmVhZChuZXRkZXYsIG5pYy0+bWlpLnBoeV9pZCwgTUlJX1BI WVNJRDIpOw0KKwluaWMtPnBoeSA9ICh1MzIpaWRfaGkgPDwgMTYgfCAodTMy KWlkX2xvOw0KKwlEUFJJTlRLKEhXLCBERUJVRywgInBoeSBJRCA9IDB4JTA4 WFxuIiwgbmljLT5waHkpOw0KKw0KKwkvKiBIYW5kbGUgTmF0aW9uYWwgdHgg cGh5cyAqLw0KKyNkZWZpbmUgTkNTX1BIWV9NT0RFTF9NQVNLCTB4RkZGMEZG RkYNCisJaWYoKG5pYy0+cGh5ICYgTkNTX1BIWV9NT0RFTF9NQVNLKSA9PSBw aHlfbnNjX3R4KSB7DQorCQkvKiBEaXNhYmxlIGNvbmdlc3Rpb24gY29udHJv bCAqLw0KKwkJY29uZyA9IG1kaW9fcmVhZChuZXRkZXYsIG5pYy0+bWlpLnBo eV9pZCwgTUlJX05TQ19DT05HKTsNCisJCWNvbmcgfD0gTlNDX0NPTkdfVFhS RUFEWTsNCisJCWNvbmcgJj0gfk5TQ19DT05HX0VOQUJMRTsNCisJCW1kaW9f d3JpdGUobmV0ZGV2LCBuaWMtPm1paS5waHlfaWQsIE1JSV9OU0NfQ09ORywg Y29uZyk7DQorCX0NCisNCisJaWYoKG5pYy0+bWFjID49IG1hY184MjU1MF9E MTAyKSB8fCAoKG5pYy0+ZmxhZ3MgJiBpY2gpICYmIA0KKwkJKG1kaW9fcmVh ZChuZXRkZXYsIG5pYy0+bWlpLnBoeV9pZCwgTUlJX1RQSVNUQVRVUykgJiAw eDgwMDApICYmIA0KKwkJKG5pYy0+ZWVwcm9tW2VlcHJvbV9jbmZnX21kaXhd ICYgZWVwcm9tX21kaXhfZW5hYmxlZCkpKQ0KKwkJLyogZW5hYmxlL2Rpc2Fi bGUgTURJL01ESS1YIGF1dG8tc3dpdGNoaW5nICovDQorCQltZGlvX3dyaXRl KG5ldGRldiwgbmljLT5taWkucGh5X2lkLCBNSUlfTkNPTkZJRywNCisJCQlu aWMtPm1paS5mb3JjZV9tZWRpYSA/IDAgOiBOQ09ORklHX0FVVE9fU1dJVENI KTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgZTEwMF9o d19pbml0KHN0cnVjdCBuaWMgKm5pYykNCit7DQorCWludCBlcnI7DQorDQor CWUxMDBfaHdfcmVzZXQobmljKTsNCisNCisJRFBSSU5USyhIVywgRVJSLCAi ZTEwMF9od19pbml0XG4iKTsNCisJaWYoIWluX2ludGVycnVwdCgpICYmIChl cnIgPSBlMTAwX3NlbGZfdGVzdChuaWMpKSkNCisJCXJldHVybiBlcnI7DQor DQorCWlmKChlcnIgPSBlMTAwX3BoeV9pbml0KG5pYykpKQ0KKwkJcmV0dXJu IGVycjsNCisJaWYoKGVyciA9IGUxMDBfZXhlY19jbWQobmljLCBjdWNfbG9h ZF9iYXNlLCAwKSkpDQorCQlyZXR1cm4gZXJyOw0KKwlpZigoZXJyID0gZTEw MF9leGVjX2NtZChuaWMsIHJ1Y19sb2FkX2Jhc2UsIDApKSkNCisJCXJldHVy biBlcnI7DQorCWlmKChlcnIgPSBlMTAwX2V4ZWNfY2IobmljLCBOVUxMLCBl MTAwX2xvYWRfdWNvZGUpKSkNCisJCXJldHVybiBlcnI7DQorCWlmKChlcnIg PSBlMTAwX2V4ZWNfY2IobmljLCBOVUxMLCBlMTAwX2NvbmZpZ3VyZSkpKQ0K KwkJcmV0dXJuIGVycjsNCisJaWYoKGVyciA9IGUxMDBfZXhlY19jYihuaWMs IE5VTEwsIGUxMDBfc2V0dXBfaWFhZGRyKSkpDQorCQlyZXR1cm4gZXJyOw0K KwlpZigoZXJyID0gZTEwMF9leGVjX2NtZChuaWMsIGN1Y19kdW1wX2FkZHIs DQorCQluaWMtPmRtYV9hZGRyICsgb2Zmc2V0b2Yoc3RydWN0IG1lbSwgc3Rh dHMpKSkpDQorCQlyZXR1cm4gZXJyOw0KKwlpZigoZXJyID0gZTEwMF9leGVj X2NtZChuaWMsIGN1Y19kdW1wX3Jlc2V0LCAwKSkpDQorCQlyZXR1cm4gZXJy Ow0KKw0KKwllMTAwX2Rpc2FibGVfaXJxKG5pYyk7DQorDQorCXJldHVybiAw Ow0KK30NCisNCitzdGF0aWMgdm9pZCBlMTAwX211bHRpKHN0cnVjdCBuaWMg Km5pYywgc3RydWN0IGNiICpjYiwgc3RydWN0IHNrX2J1ZmYgKnNrYikNCit7 DQorCXN0cnVjdCBuZXRfZGV2aWNlICpuZXRkZXYgPSBuaWMtPm5ldGRldjsN CisJc3RydWN0IGRldl9tY19saXN0ICpsaXN0ID0gbmV0ZGV2LT5tY19saXN0 Ow0KKwl1MTYgaSwgY291bnQgPSBtaW4obmV0ZGV2LT5tY19jb3VudCwgRTEw MF9NQVhfTVVMVElDQVNUX0FERFJTKTsNCisNCisJY2ItPmNvbW1hbmQgPSBj cHVfdG9fbGUxNihjYl9tdWx0aSk7DQorCWNiLT51Lm11bHRpLmNvdW50ID0g Y3B1X3RvX2xlMTYoY291bnQgKiBFVEhfQUxFTik7DQorCWZvcihpID0gMDsg bGlzdCAmJiBpIDwgY291bnQ7IGkrKywgbGlzdCA9IGxpc3QtPm5leHQpDQor CQltZW1jcHkoJmNiLT51Lm11bHRpLmFkZHJbaSpFVEhfQUxFTl0sICZsaXN0 LT5kbWlfYWRkciwNCisJCQlFVEhfQUxFTik7DQorfQ0KKw0KK3N0YXRpYyB2 b2lkIGUxMDBfc2V0X211bHRpY2FzdF9saXN0KHN0cnVjdCBuZXRfZGV2aWNl ICpuZXRkZXYpDQorew0KKwlzdHJ1Y3QgbmljICpuaWMgPSBuZXRkZXZfcHJp dihuZXRkZXYpOw0KKw0KKwlEUFJJTlRLKEhXLCBERUJVRywgIm1jX2NvdW50 PSVkLCBmbGFncz0weCUwNFhcbiIsDQorCQluZXRkZXYtPm1jX2NvdW50LCBu ZXRkZXYtPmZsYWdzKTsNCisNCisJaWYobmV0ZGV2LT5mbGFncyAmIElGRl9Q Uk9NSVNDKQ0KKwkJbmljLT5mbGFncyB8PSBwcm9taXNjdW91czsNCisJZWxz ZQ0KKwkJbmljLT5mbGFncyAmPSB+cHJvbWlzY3VvdXM7DQorDQorCWlmKG5l dGRldi0+ZmxhZ3MgJiBJRkZfQUxMTVVMVEkgfHwNCisJCW5ldGRldi0+bWNf Y291bnQgPiBFMTAwX01BWF9NVUxUSUNBU1RfQUREUlMpDQorCQluaWMtPmZs YWdzIHw9IG11bHRpY2FzdF9hbGw7DQorCWVsc2UNCisJCW5pYy0+ZmxhZ3Mg Jj0gfm11bHRpY2FzdF9hbGw7DQorDQorCWUxMDBfZXhlY19jYihuaWMsIE5V TEwsIGUxMDBfY29uZmlndXJlKTsNCisJZTEwMF9leGVjX2NiKG5pYywgTlVM TCwgZTEwMF9tdWx0aSk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGUxMDBfdXBk YXRlX3N0YXRzKHN0cnVjdCBuaWMgKm5pYykNCit7DQorCXN0cnVjdCBuZXRf ZGV2aWNlX3N0YXRzICpucyA9ICZuaWMtPm5ldF9zdGF0czsNCisJc3RydWN0 IHN0YXRzICpzID0gJm5pYy0+bWVtLT5zdGF0czsNCisJdTMyICpjb21wbGV0 ZSA9IChuaWMtPm1hYyA8IG1hY184MjU1OF9EMTAxX0E0KSA/ICZzLT5mY194 bXRfcGF1c2UgOg0KKwkJKG5pYy0+bWFjIDwgbWFjXzgyNTU5X0QxMDFNKSA/ ICh1MzIgKikmcy0+eG10X3Rjb19mcmFtZXMgOg0KKwkJJnMtPmNvbXBsZXRl Ow0KKw0KKwkvKiBEZXZpY2UncyBzdGF0cyByZXBvcnRpbmcgbWF5IHRha2Ug c2V2ZXJhbCBtaWNyb3NlY29uZHMgdG8NCisJICogY29tcGxldGUsIHNvIHdo ZXJlIGFsd2F5cyB3YWl0aW5nIGZvciByZXN1bHRzIG9mIHRoZQ0KKwkgKiBw cmV2aW91cyBjb21tYW5kLiAqLw0KKw0KKwlpZigqY29tcGxldGUgPT0gbGUz Ml90b19jcHUoY3VjX2R1bXBfcmVzZXRfY29tcGxldGUpKSB7DQorCQkqY29t cGxldGUgPSAwOw0KKwkJbmljLT50eF9mcmFtZXMgPSBsZTMyX3RvX2NwdShz LT50eF9nb29kX2ZyYW1lcyk7DQorCQluaWMtPnR4X2NvbGxpc2lvbnMgPSBs ZTMyX3RvX2NwdShzLT50eF90b3RhbF9jb2xsaXNpb25zKTsNCisJCW5zLT50 eF9hYm9ydGVkX2Vycm9ycyArPSBsZTMyX3RvX2NwdShzLT50eF9tYXhfY29s bGlzaW9ucyk7DQorCQlucy0+dHhfd2luZG93X2Vycm9ycyArPSBsZTMyX3Rv X2NwdShzLT50eF9sYXRlX2NvbGxpc2lvbnMpOw0KKwkJbnMtPnR4X2NhcnJp ZXJfZXJyb3JzICs9IGxlMzJfdG9fY3B1KHMtPnR4X2xvc3RfY3JzKTsNCisJ CW5zLT50eF9maWZvX2Vycm9ycyArPSBsZTMyX3RvX2NwdShzLT50eF91bmRl cnJ1bnMpOw0KKwkJbnMtPmNvbGxpc2lvbnMgKz0gbmljLT50eF9jb2xsaXNp b25zOw0KKwkJbnMtPnR4X2Vycm9ycyArPSBsZTMyX3RvX2NwdShzLT50eF9t YXhfY29sbGlzaW9ucykgKw0KKwkJCWxlMzJfdG9fY3B1KHMtPnR4X2xvc3Rf Y3JzKTsNCisJCW5zLT5yeF9kcm9wcGVkICs9IGxlMzJfdG9fY3B1KHMtPnJ4 X3Jlc291cmNlX2Vycm9ycyk7DQorCQlucy0+cnhfbGVuZ3RoX2Vycm9ycyAr PSBsZTMyX3RvX2NwdShzLT5yeF9zaG9ydF9mcmFtZV9lcnJvcnMpICsNCisJ CQluaWMtPnJ4X292ZXJfbGVuZ3RoX2Vycm9yczsNCisJCW5zLT5yeF9jcmNf ZXJyb3JzICs9IGxlMzJfdG9fY3B1KHMtPnJ4X2NyY19lcnJvcnMpOw0KKwkJ bnMtPnJ4X2ZyYW1lX2Vycm9ycyArPSBsZTMyX3RvX2NwdShzLT5yeF9hbGln bm1lbnRfZXJyb3JzKTsNCisJCW5zLT5yeF9vdmVyX2Vycm9ycyArPSBsZTMy X3RvX2NwdShzLT5yeF9vdmVycnVuX2Vycm9ycyk7DQorCQlucy0+cnhfZmlm b19lcnJvcnMgKz0gbGUzMl90b19jcHUocy0+cnhfb3ZlcnJ1bl9lcnJvcnMp Ow0KKwkJbnMtPnJ4X2Vycm9ycyArPSBsZTMyX3RvX2NwdShzLT5yeF9jcmNf ZXJyb3JzKSArDQorCQkJbGUzMl90b19jcHUocy0+cnhfYWxpZ25tZW50X2Vy cm9ycykgKw0KKwkJCWxlMzJfdG9fY3B1KHMtPnJ4X3Nob3J0X2ZyYW1lX2Vy cm9ycykgKw0KKwkJCWxlMzJfdG9fY3B1KHMtPnJ4X2NkdF9lcnJvcnMpOw0K KwkJbmljLT50eF9kZWZlcnJlZCArPSBsZTMyX3RvX2NwdShzLT50eF9kZWZl cnJlZCk7DQorCQluaWMtPnR4X3NpbmdsZV9jb2xsaXNpb25zICs9DQorCQkJ bGUzMl90b19jcHUocy0+dHhfc2luZ2xlX2NvbGxpc2lvbnMpOw0KKwkJbmlj LT50eF9tdWx0aXBsZV9jb2xsaXNpb25zICs9DQorCQkJbGUzMl90b19jcHUo cy0+dHhfbXVsdGlwbGVfY29sbGlzaW9ucyk7DQorCQlpZihuaWMtPm1hYyA+ PSBtYWNfODI1NThfRDEwMV9BNCkgew0KKwkJCW5pYy0+dHhfZmNfcGF1c2Ug Kz0gbGUzMl90b19jcHUocy0+ZmNfeG10X3BhdXNlKTsNCisJCQluaWMtPnJ4 X2ZjX3BhdXNlICs9IGxlMzJfdG9fY3B1KHMtPmZjX3Jjdl9wYXVzZSk7DQor CQkJbmljLT5yeF9mY191bnN1cHBvcnRlZCArPQ0KKwkJCQlsZTMyX3RvX2Nw dShzLT5mY19yY3ZfdW5zdXBwb3J0ZWQpOw0KKwkJCWlmKG5pYy0+bWFjID49 IG1hY184MjU1OV9EMTAxTSkgew0KKwkJCQluaWMtPnR4X3Rjb19mcmFtZXMg Kz0NCisJCQkJCWxlMTZfdG9fY3B1KHMtPnhtdF90Y29fZnJhbWVzKTsNCisJ CQkJbmljLT5yeF90Y29fZnJhbWVzICs9DQorCQkJCQlsZTE2X3RvX2NwdShz LT5yY3ZfdGNvX2ZyYW1lcyk7DQorCQkJfQ0KKwkJfQ0KKwl9DQorDQorCWUx MDBfZXhlY19jbWQobmljLCBjdWNfZHVtcF9yZXNldCwgMCk7DQorfQ0KKw0K K3N0YXRpYyB2b2lkIGUxMDBfYWRqdXN0X2FkYXB0aXZlX2lmcyhzdHJ1Y3Qg bmljICpuaWMsIGludCBzcGVlZCwgaW50IGR1cGxleCkNCit7DQorCS8qIEFk anVzdCBpbnRlci1mcmFtZS1zcGFjaW5nIChJRlMpIGJldHdlZW4gdHdvIHRy YW5zbWl0cyBpZg0KKwkgKiB3ZSdyZSBnZXR0aW5nIGNvbGxpc2lvbnMgb24g YSBoYWxmLWR1cGxleCBjb25uZWN0aW9uLiAqLw0KKw0KKwlpZihkdXBsZXgg PT0gRFVQTEVYX0hBTEYpIHsNCisJCXUzMiBwcmV2ID0gbmljLT5hZGFwdGl2 ZV9pZnM7DQorCQl1MzIgbWluX2ZyYW1lcyA9IChzcGVlZCA9PSBTUEVFRF8x MDApID8gMTAwMCA6IDEwMDsNCisNCisJCWlmKChuaWMtPnR4X2ZyYW1lcyAv IDMyIDwgbmljLT50eF9jb2xsaXNpb25zKSAmJg0KKwkJICAgKG5pYy0+dHhf ZnJhbWVzID4gbWluX2ZyYW1lcykpIHsNCisJCQlpZihuaWMtPmFkYXB0aXZl X2lmcyA8IDYwKQ0KKwkJCQluaWMtPmFkYXB0aXZlX2lmcyArPSA1Ow0KKwkJ fSBlbHNlIGlmIChuaWMtPnR4X2ZyYW1lcyA8IG1pbl9mcmFtZXMpIHsNCisJ CQlpZihuaWMtPmFkYXB0aXZlX2lmcyA+PSA1KQ0KKwkJCQluaWMtPmFkYXB0 aXZlX2lmcyAtPSA1Ow0KKwkJfQ0KKwkJaWYobmljLT5hZGFwdGl2ZV9pZnMg IT0gcHJldikNCisJCQllMTAwX2V4ZWNfY2IobmljLCBOVUxMLCBlMTAwX2Nv bmZpZ3VyZSk7DQorCX0NCit9DQorDQorc3RhdGljIHZvaWQgZTEwMF93YXRj aGRvZyh1bnNpZ25lZCBsb25nIGRhdGEpDQorew0KKwlzdHJ1Y3QgbmljICpu aWMgPSAoc3RydWN0IG5pYyAqKWRhdGE7DQorCXN0cnVjdCBldGh0b29sX2Nt ZCBjbWQ7DQorDQorCURQUklOVEsoVElNRVIsIERFQlVHLCAicmlnaHQgbm93 ID0gJWxkXG4iLCBqaWZmaWVzKTsNCisNCisJLyogbWlpIGxpYnJhcnkgaGFu ZGxlcyBsaW5rIG1haW50ZW5hbmNlIHRhc2tzICovDQorDQorCW1paV9ldGh0 b29sX2dzZXQoJm5pYy0+bWlpLCAmY21kKTsNCisNCisJaWYobWlpX2xpbmtf b2soJm5pYy0+bWlpKSAmJiAhbmV0aWZfY2Fycmllcl9vayhuaWMtPm5ldGRl dikpIHsNCisJCURQUklOVEsoTElOSywgSU5GTywgImxpbmsgdXAsICVzTWJw cywgJXMtZHVwbGV4XG4iLA0KKwkJCWNtZC5zcGVlZCA9PSBTUEVFRF8xMDAg PyAiMTAwIiA6ICIxMCIsDQorCQkJY21kLmR1cGxleCA9PSBEVVBMRVhfRlVM TCA/ICJmdWxsIiA6ICJoYWxmIik7DQorCX0gZWxzZSBpZighbWlpX2xpbmtf b2soJm5pYy0+bWlpKSAmJiBuZXRpZl9jYXJyaWVyX29rKG5pYy0+bmV0ZGV2 KSkgew0KKwkJRFBSSU5USyhMSU5LLCBJTkZPLCAibGluayBkb3duXG4iKTsN CisJfQ0KKw0KKwltaWlfY2hlY2tfbGluaygmbmljLT5taWkpOw0KKw0KKwkv KiBTb2Z0d2FyZSBnZW5lcmF0ZWQgaW50ZXJydXB0IHRvIHJlY292ZXIgZnJv bSAocmFyZSkgUngNCisJICogYWxsb2NhdGlvbiBmYWlsdXJlICovDQorCXdy aXRlYihpcnFfc3dfZ2VuLCAmbmljLT5jc3ItPnNjYi5jbWRfaGkpOw0KKwll MTAwX3dyaXRlX2ZsdXNoKG5pYyk7DQorDQorCWUxMDBfdXBkYXRlX3N0YXRz KG5pYyk7DQorCWUxMDBfYWRqdXN0X2FkYXB0aXZlX2lmcyhuaWMsIGNtZC5z cGVlZCwgY21kLmR1cGxleCk7DQorDQorCWlmKG5pYy0+bWFjIDw9IG1hY184 MjU1N19EMTAwX0MpDQorCQkvKiBJc3N1ZSBhIG11bHRpY2FzdCBjb21tYW5k IHRvIHdvcmthcm91bmQgYSA1NTcgbG9jayB1cCAqLw0KKwkJZTEwMF9zZXRf bXVsdGljYXN0X2xpc3QobmljLT5uZXRkZXYpOw0KKw0KKwlpZihuaWMtPmZs YWdzICYgaWNoICYmIGNtZC5zcGVlZD09U1BFRURfMTAgJiYgY21kLmR1cGxl eD09RFVQTEVYX0hBTEYpDQorCQkvKiBOZWVkIFNXIHdvcmthcm91bmQgZm9y IElDSFt4XSAxME1icHMvaGFsZiBkdXBsZXggVHggaGFuZy4gKi8NCisJCW5p Yy0+ZmxhZ3MgfD0gaWNoXzEwaF93b3JrYXJvdW5kOw0KKwllbHNlDQorCQlu aWMtPmZsYWdzICY9IH5pY2hfMTBoX3dvcmthcm91bmQ7DQorDQorCW1vZF90 aW1lcigmbmljLT53YXRjaGRvZywgamlmZmllcyArIEUxMDBfV0FUQ0hET0df UEVSSU9EKTsNCit9DQorDQorc3RhdGljIGlubGluZSB2b2lkIGUxMDBfeG1p dF9wcmVwYXJlKHN0cnVjdCBuaWMgKm5pYywgc3RydWN0IGNiICpjYiwNCisJ c3RydWN0IHNrX2J1ZmYgKnNrYikNCit7DQorCWNiLT5jb21tYW5kID0gbmlj LT50eF9jb21tYW5kOw0KKwljYi0+dS50Y2IudGJkX2FycmF5ID0gY2ItPmRt YV9hZGRyICsgb2Zmc2V0b2Yoc3RydWN0IGNiLCB1LnRjYi50YmQpOw0KKwlj Yi0+dS50Y2IudGNiX2J5dGVfY291bnQgPSAwOw0KKwljYi0+dS50Y2IudGhy ZXNob2xkID0gbmljLT50eF90aHJlc2hvbGQ7DQorCWNiLT51LnRjYi50YmRf Y291bnQgPSAxOw0KKwljYi0+dS50Y2IudGJkLmJ1Zl9hZGRyID0gY3B1X3Rv X2xlMzIocGNpX21hcF9zaW5nbGUobmljLT5wZGV2LA0KKwkJc2tiLT5kYXRh LCBza2ItPmxlbiwgUENJX0RNQV9UT0RFVklDRSkpOw0KKwljYi0+dS50Y2Iu dGJkLnNpemUgPSBjcHVfdG9fbGUxNihza2ItPmxlbik7DQorfQ0KKw0KK3N0 YXRpYyBpbnQgZTEwMF94bWl0X2ZyYW1lKHN0cnVjdCBza19idWZmICpza2Is IHN0cnVjdCBuZXRfZGV2aWNlICpuZXRkZXYpDQorew0KKwlzdHJ1Y3Qgbmlj ICpuaWMgPSBuZXRkZXZfcHJpdihuZXRkZXYpOw0KKwlpbnQgZXJyOw0KKw0K KwlpZihuaWMtPmZsYWdzICYgaWNoXzEwaF93b3JrYXJvdW5kKSB7DQorCQkv KiBTVyB3b3JrYXJvdW5kIGZvciBJQ0hbeF0gMTBNYnBzL2hhbGYgZHVwbGV4 IFR4IGhhbmcuDQorCQkgICBJc3N1ZSBhIE5PUCBjb21tYW5kIGZvbGxvd2Vk IGJ5IGEgMXVzIGRlbGF5IGJlZm9yZQ0KKwkJICAgaXNzdWluZyB0aGUgVHgg Y29tbWFuZC4gKi8NCisJCWUxMDBfZXhlY19jbWQobmljLCBjdWNfbm9wLCAw KTsNCisJCXVkZWxheSgxKTsNCisJfQ0KKw0KKwllcnIgPSBlMTAwX2V4ZWNf Y2IobmljLCBza2IsIGUxMDBfeG1pdF9wcmVwYXJlKTsNCisNCisJc3dpdGNo KGVycikgew0KKwljYXNlIC1FTk9TUEM6DQorCQkvKiBXZSBxdWV1ZWQgdGhl IHNrYiwgYnV0IG5vdyB3ZSdyZSBvdXQgb2Ygc3BhY2UuICovDQorCQluZXRp Zl9zdG9wX3F1ZXVlKG5ldGRldik7DQorCQlicmVhazsNCisJY2FzZSAtRU5P TUVNOg0KKwkJLyogVGhpcyBpcyBhIGhhcmQgZXJyb3IgLSBsb2cgaXQuICov DQorCQlEUFJJTlRLKFRYX0VSUiwgREVCVUcsICJPdXQgb2YgVHggcmVzb3Vy Y2VzLCByZXR1cm5pbmcgc2tiXG4iKTsNCisJCW5ldGlmX3N0b3BfcXVldWUo bmV0ZGV2KTsNCisJCXJldHVybiAxOw0KKwl9DQorDQorCW5ldGRldi0+dHJh bnNfc3RhcnQgPSBqaWZmaWVzOw0KKwlyZXR1cm4gMDsNCit9DQorDQorc3Rh dGljIGlubGluZSBpbnQgZTEwMF90eF9jbGVhbihzdHJ1Y3QgbmljICpuaWMp DQorew0KKwlzdHJ1Y3QgY2IgKmNiOw0KKwlpbnQgdHhfY2xlYW5lZCA9IDA7 DQorDQorCXNwaW5fbG9jaygmbmljLT5jYl9sb2NrKTsNCisNCisJRFBSSU5U SyhUWF9ET05FLCBERUJVRywgImNiLT5zdGF0dXMgPSAweCUwNFhcbiIsDQor CQluaWMtPmNiX3RvX2NsZWFuLT5zdGF0dXMpOw0KKw0KKwkvKiBDbGVhbiBD QnMgbWFya2VkIGNvbXBsZXRlICovDQorCWZvcihjYiA9IG5pYy0+Y2JfdG9f Y2xlYW47DQorCSAgICBjYi0+c3RhdHVzICYgY3B1X3RvX2xlMTYoY2JfY29t cGxldGUpOw0KKwkgICAgY2IgPSBuaWMtPmNiX3RvX2NsZWFuID0gY2ItPm5l eHQpIHsNCisJCWlmKGxpa2VseShjYi0+c2tiICE9IE5VTEwpKSB7DQorCQkJ bmljLT5uZXRfc3RhdHMudHhfcGFja2V0cysrOw0KKwkJCW5pYy0+bmV0X3N0 YXRzLnR4X2J5dGVzICs9IGNiLT5za2ItPmxlbjsNCisNCisJCQlwY2lfdW5t YXBfc2luZ2xlKG5pYy0+cGRldiwNCisJCQkJbGUzMl90b19jcHUoY2ItPnUu dGNiLnRiZC5idWZfYWRkciksDQorCQkJCWxlMTZfdG9fY3B1KGNiLT51LnRj Yi50YmQuc2l6ZSksDQorCQkJCVBDSV9ETUFfVE9ERVZJQ0UpOw0KKwkJCWRl dl9rZnJlZV9za2JfYW55KGNiLT5za2IpOw0KKwkJCWNiLT5za2IgPSBOVUxM Ow0KKwkJCXR4X2NsZWFuZWQgPSAxOw0KKwkJfQ0KKwkJY2ItPnN0YXR1cyA9 IDA7DQorCQluaWMtPmNic19hdmFpbCsrOw0KKwl9DQorDQorCXNwaW5fdW5s b2NrKCZuaWMtPmNiX2xvY2spOw0KKw0KKwkvKiBSZWNvdmVyIGZyb20gcnVu bmluZyBvdXQgb2YgVHggcmVzb3VyY2VzIGluIHhtaXRfZnJhbWUgKi8NCisJ aWYodW5saWtlbHkodHhfY2xlYW5lZCAmJiBuZXRpZl9xdWV1ZV9zdG9wcGVk KG5pYy0+bmV0ZGV2KSkpDQorCQluZXRpZl93YWtlX3F1ZXVlKG5pYy0+bmV0 ZGV2KTsNCisNCisJcmV0dXJuIHR4X2NsZWFuZWQ7DQorfQ0KKw0KK3N0YXRp YyB2b2lkIGUxMDBfY2xlYW5fY2JzKHN0cnVjdCBuaWMgKm5pYykNCit7DQor CWlmKG5pYy0+Y2JzKSB7DQorCQl3aGlsZShuaWMtPmNic19hdmFpbCAhPSBu aWMtPnBhcmFtcy5jYnMuY291bnQpIHsNCisJCQlzdHJ1Y3QgY2IgKmNiID0g bmljLT5jYl90b19jbGVhbjsNCisJCQlpZihjYi0+c2tiKSB7DQorCQkJCXBj aV91bm1hcF9zaW5nbGUobmljLT5wZGV2LA0KKwkJCQkJbGUzMl90b19jcHUo Y2ItPnUudGNiLnRiZC5idWZfYWRkciksDQorCQkJCQlsZTE2X3RvX2NwdShj Yi0+dS50Y2IudGJkLnNpemUpLA0KKwkJCQkJUENJX0RNQV9UT0RFVklDRSk7 DQorCQkJCWRldl9rZnJlZV9za2IoY2ItPnNrYik7DQorCQkJfQ0KKwkJCW5p Yy0+Y2JfdG9fY2xlYW4gPSBuaWMtPmNiX3RvX2NsZWFuLT5uZXh0Ow0KKwkJ CW5pYy0+Y2JzX2F2YWlsKys7DQorCQl9DQorCQlwY2lfZnJlZV9jb25zaXN0 ZW50KG5pYy0+cGRldiwNCisJCQlzaXplb2Yoc3RydWN0IGNiKSAqIG5pYy0+ cGFyYW1zLmNicy5jb3VudCwNCisJCQluaWMtPmNicywgbmljLT5jYnNfZG1h X2FkZHIpOw0KKwkJbmljLT5jYnMgPSBOVUxMOw0KKwkJbmljLT5jYnNfYXZh aWwgPSAwOw0KKwl9DQorCW5pYy0+Y3VjX2NtZCA9IGN1Y19zdGFydDsNCisJ bmljLT5jYl90b191c2UgPSBuaWMtPmNiX3RvX3NlbmQgPSBuaWMtPmNiX3Rv X2NsZWFuID0NCisJCW5pYy0+Y2JzOw0KK30NCisNCitzdGF0aWMgaW50IGUx MDBfYWxsb2NfY2JzKHN0cnVjdCBuaWMgKm5pYykNCit7DQorCXN0cnVjdCBj YiAqY2I7DQorCXVuc2lnbmVkIGludCBpLCBjb3VudCA9IG5pYy0+cGFyYW1z LmNicy5jb3VudDsNCisNCisJbmljLT5jdWNfY21kID0gY3VjX3N0YXJ0Ow0K KwluaWMtPmNiX3RvX3VzZSA9IG5pYy0+Y2JfdG9fc2VuZCA9IG5pYy0+Y2Jf dG9fY2xlYW4gPSBOVUxMOw0KKwluaWMtPmNic19hdmFpbCA9IDA7DQorDQor CW5pYy0+Y2JzID0gcGNpX2FsbG9jX2NvbnNpc3RlbnQobmljLT5wZGV2LA0K KwkJc2l6ZW9mKHN0cnVjdCBjYikgKiBjb3VudCwgJm5pYy0+Y2JzX2RtYV9h ZGRyKTsNCisJaWYoIW5pYy0+Y2JzKQ0KKwkJcmV0dXJuIC1FTk9NRU07DQor DQorCWZvcihjYiA9IG5pYy0+Y2JzLCBpID0gMDsgaSA8IGNvdW50OyBjYisr LCBpKyspIHsNCisJCWNiLT5uZXh0ID0gKGkgKyAxIDwgY291bnQpID8gY2Ig KyAxIDogbmljLT5jYnM7DQorCQljYi0+cHJldiA9IChpID09IDApID8gbmlj LT5jYnMgKyBjb3VudCAtIDEgOiBjYiAtIDE7DQorDQorCQljYi0+ZG1hX2Fk ZHIgPSBuaWMtPmNic19kbWFfYWRkciArIGkgKiBzaXplb2Yoc3RydWN0IGNi KTsNCisJCWNiLT5saW5rID0gY3B1X3RvX2xlMzIobmljLT5jYnNfZG1hX2Fk ZHIgKw0KKwkJCSgoaSsxKSAlIGNvdW50KSAqIHNpemVvZihzdHJ1Y3QgY2Ip KTsNCisJCWNiLT5za2IgPSBOVUxMOw0KKwl9DQorDQorCW5pYy0+Y2JfdG9f dXNlID0gbmljLT5jYl90b19zZW5kID0gbmljLT5jYl90b19jbGVhbiA9IG5p Yy0+Y2JzOw0KKwluaWMtPmNic19hdmFpbCA9IGNvdW50Ow0KKw0KKwlyZXR1 cm4gMDsNCit9DQorDQorc3RhdGljIGlubGluZSB2b2lkIGUxMDBfc3RhcnRf cmVjZWl2ZXIoc3RydWN0IG5pYyAqbmljKQ0KK3sNCisJLyogKFJlKXN0YXJ0 IFJVIGlmIHN1c3BlbmRlZCBvciBpZGxlIGFuZCBSRkEgaXMgbm9uLU5VTEwg Ki8NCisJaWYoIW5pYy0+cnVfcnVubmluZyAmJiBuaWMtPnJ4X3RvX2NsZWFu LT5za2IpIHsNCisJCWUxMDBfZXhlY19jbWQobmljLCBydWNfc3RhcnQsIG5p Yy0+cnhfdG9fY2xlYW4tPmRtYV9hZGRyKTsNCisJCW5pYy0+cnVfcnVubmlu ZyA9IDE7DQorCX0NCit9DQorDQorI2RlZmluZSBSRkRfQlVGX0xFTiAoc2l6 ZW9mKHN0cnVjdCByZmQpICsgVkxBTl9FVEhfRlJBTUVfTEVOKQ0KK3N0YXRp YyBpbmxpbmUgaW50IGUxMDBfcnhfYWxsb2Nfc2tiKHN0cnVjdCBuaWMgKm5p Yywgc3RydWN0IHJ4ICpyeCkNCit7DQorCXVuc2lnbmVkIGludCByeF9vZmZz ZXQgPSAyOyAvKiB1MzIgYWxpZ24gcHJvdG9jb2wgaGVhZGVycyAqLw0KKw0K KwlpZighKHJ4LT5za2IgPSBkZXZfYWxsb2Nfc2tiKFJGRF9CVUZfTEVOICsg cnhfb2Zmc2V0KSkpDQorCQlyZXR1cm4gLUVOT01FTTsNCisNCisJLyogQWxp Z24sIGluaXQsIGFuZCBtYXAgdGhlIFJGRC4gKi8NCisJcngtPnNrYi0+ZGV2 ID0gbmljLT5uZXRkZXY7DQorCXNrYl9yZXNlcnZlKHJ4LT5za2IsIHJ4X29m ZnNldCk7DQorCW1lbWNweShyeC0+c2tiLT5kYXRhLCAmbmljLT5ibGFua19y ZmQsIHNpemVvZihzdHJ1Y3QgcmZkKSk7DQorCXJ4LT5kbWFfYWRkciA9IHBj aV9tYXBfc2luZ2xlKG5pYy0+cGRldiwgcngtPnNrYi0+ZGF0YSwNCisJCVJG RF9CVUZfTEVOLCBQQ0lfRE1BX0JJRElSRUNUSU9OQUwpOw0KKw0KKwkvKiBM aW5rIHRoZSBSRkQgdG8gZW5kIG9mIFJGQSBieSBsaW5raW5nIHByZXZpb3Vz IFJGRCB0bw0KKwkgKiB0aGlzIG9uZSwgYW5kIGNsZWFyaW5nIEVMIGJpdCBv ZiBwcmV2aW91cy4gICovDQorCWlmKHJ4LT5wcmV2LT5za2IpIHsNCisJCXN0 cnVjdCByZmQgKnByZXZfcmZkID0gKHN0cnVjdCByZmQgKilyeC0+cHJldi0+ c2tiLT5kYXRhOw0KKwkJcHV0X3VuYWxpZ25lZChjcHVfdG9fbGUzMihyeC0+ ZG1hX2FkZHIpLA0KKwkJCSh1MzIgKikmcHJldl9yZmQtPmxpbmspOw0KKwkJ d21iKCk7DQorCQlwcmV2X3JmZC0+Y29tbWFuZCAmPSB+Y3B1X3RvX2xlMTYo Y2JfZWwpOw0KKwkJcGNpX2RtYV9zeW5jX3NpbmdsZShuaWMtPnBkZXYsIHJ4 LT5wcmV2LT5kbWFfYWRkciwNCisJCQlzaXplb2Yoc3RydWN0IHJmZCksIFBD SV9ETUFfVE9ERVZJQ0UpOw0KKwl9DQorDQorCXJldHVybiAwOw0KK30NCisN CitzdGF0aWMgaW5saW5lIGludCBlMTAwX3J4X2luZGljYXRlKHN0cnVjdCBu aWMgKm5pYywgc3RydWN0IHJ4ICpyeCwNCisJdW5zaWduZWQgaW50ICp3b3Jr X2RvbmUsIHVuc2lnbmVkIGludCB3b3JrX3RvX2RvKQ0KK3sNCisJc3RydWN0 IHNrX2J1ZmYgKnNrYiA9IHJ4LT5za2I7DQorCXN0cnVjdCByZmQgKnJmZCA9 IChzdHJ1Y3QgcmZkICopc2tiLT5kYXRhOw0KKwl1MTYgcmZkX3N0YXR1cywg YWN0dWFsX3NpemU7DQorDQorCWlmKHVubGlrZWx5KHdvcmtfZG9uZSAmJiAq d29ya19kb25lID49IHdvcmtfdG9fZG8pKQ0KKwkJcmV0dXJuIC1FQUdBSU47 DQorDQorCS8qIE5lZWQgdG8gc3luYyBiZWZvcmUgdGFraW5nIGEgcGVlayBh dCBjYl9jb21wbGV0ZSBiaXQgKi8NCisJcGNpX2RtYV9zeW5jX3NpbmdsZShu aWMtPnBkZXYsIHJ4LT5kbWFfYWRkciwNCisJCXNpemVvZihzdHJ1Y3QgcmZk KSwgUENJX0RNQV9GUk9NREVWSUNFKTsNCisJcmZkX3N0YXR1cyA9IGxlMTZf dG9fY3B1KHJmZC0+c3RhdHVzKTsNCisNCisJRFBSSU5USyhSWF9TVEFUVVMs IERFQlVHLCAic3RhdHVzPTB4JTA0WFxuIiwgcmZkX3N0YXR1cyk7DQorDQor CS8qIElmIGRhdGEgaXNuJ3QgcmVhZHksIG5vdGhpbmcgdG8gaW5kaWNhdGUg Ki8NCisJaWYodW5saWtlbHkoIShyZmRfc3RhdHVzICYgY2JfY29tcGxldGUp KSkNCisgICAgICAgCQlyZXR1cm4gLUVBR0FJTjsNCisNCisJLyogR2V0IGFj dHVhbCBkYXRhIHNpemUgKi8NCisJYWN0dWFsX3NpemUgPSBsZTE2X3RvX2Nw dShyZmQtPmFjdHVhbF9zaXplKSAmIDB4M0ZGRjsNCisJaWYodW5saWtlbHko YWN0dWFsX3NpemUgPiBSRkRfQlVGX0xFTiAtIHNpemVvZihzdHJ1Y3QgcmZk KSkpDQorCQlhY3R1YWxfc2l6ZSA9IFJGRF9CVUZfTEVOIC0gc2l6ZW9mKHN0 cnVjdCByZmQpOw0KKw0KKwkvKiBHZXQgZGF0YSAqLw0KKwlwY2lfdW5tYXBf c2luZ2xlKG5pYy0+cGRldiwgcngtPmRtYV9hZGRyLA0KKwkJUkZEX0JVRl9M RU4sIFBDSV9ETUFfRlJPTURFVklDRSk7DQorDQorCS8qIFB1bGwgb2ZmIHRo ZSBSRkQgYW5kIHB1dCB0aGUgYWN0dWFsIGRhdGEgKG1pbnVzIGV0aCBoZHIp ICovDQorCXNrYl9yZXNlcnZlKHNrYiwgc2l6ZW9mKHN0cnVjdCByZmQpKTsN CisJc2tiX3B1dChza2IsIGFjdHVhbF9zaXplKTsNCisJc2tiLT5wcm90b2Nv bCA9IGV0aF90eXBlX3RyYW5zKHNrYiwgbmljLT5uZXRkZXYpOw0KKw0KKwlp Zih1bmxpa2VseSghKHJmZF9zdGF0dXMgJiBjYl9vaykpKSB7DQorCQkvKiBE b24ndCBpbmRpY2F0ZSBpZiBoYXJkd2FyZSBpbmRpY2F0ZXMgZXJyb3JzICov DQorCQluaWMtPm5ldF9zdGF0cy5yeF9kcm9wcGVkKys7DQorCQlkZXZfa2Zy ZWVfc2tiX2FueShza2IpOw0KKwl9IGVsc2UgaWYoYWN0dWFsX3NpemUgPiBu aWMtPm5ldGRldi0+bXR1ICsgVkxBTl9FVEhfSExFTikgew0KKwkJLyogRG9u J3QgaW5kaWNhdGUgb3ZlcnNpemVkIGZyYW1lcyAqLw0KKwkJbmljLT5yeF9v dmVyX2xlbmd0aF9lcnJvcnMrKzsNCisJCW5pYy0+bmV0X3N0YXRzLnJ4X2Ry b3BwZWQrKzsNCisJCWRldl9rZnJlZV9za2JfYW55KHNrYik7DQorCX0gZWxz ZSB7DQorCQluaWMtPm5ldF9zdGF0cy5yeF9wYWNrZXRzKys7DQorCQluaWMt Pm5ldF9zdGF0cy5yeF9ieXRlcyArPSBhY3R1YWxfc2l6ZTsNCisJCW5pYy0+ bmV0ZGV2LT5sYXN0X3J4ID0gamlmZmllczsNCisJCW5ldGlmX3JlY2VpdmVf c2tiKHNrYik7DQorCQlpZih3b3JrX2RvbmUpDQorCQkJKCp3b3JrX2RvbmUp Kys7DQorCX0NCisNCisJcngtPnNrYiA9IE5VTEw7DQorDQorCXJldHVybiAw Ow0KK30NCisNCitzdGF0aWMgaW5saW5lIHZvaWQgZTEwMF9yeF9jbGVhbihz dHJ1Y3QgbmljICpuaWMsIHVuc2lnbmVkIGludCAqd29ya19kb25lLA0KKwl1 bnNpZ25lZCBpbnQgd29ya190b19kbykNCit7DQorCXN0cnVjdCByeCAqcng7 DQorDQorCS8qIEluZGljYXRlIG5ld2x5IGFycml2ZWQgcGFja2V0cyAqLw0K Kwlmb3IocnggPSBuaWMtPnJ4X3RvX2NsZWFuOyByeC0+c2tiOyByeCA9IG5p Yy0+cnhfdG9fY2xlYW4gPSByeC0+bmV4dCkgew0KKwkJaWYoZTEwMF9yeF9p bmRpY2F0ZShuaWMsIHJ4LCB3b3JrX2RvbmUsIHdvcmtfdG9fZG8pKQ0KKwkJ CWJyZWFrOyAvKiBObyBtb3JlIHRvIGNsZWFuICovDQorCX0NCisNCisJLyog QWxsb2MgbmV3IHNrYnMgdG8gcmVmaWxsIGxpc3QgKi8NCisJZm9yKHJ4ID0g bmljLT5yeF90b191c2U7ICFyeC0+c2tiOyByeCA9IG5pYy0+cnhfdG9fdXNl ID0gcngtPm5leHQpIHsNCisJCWlmKHVubGlrZWx5KGUxMDBfcnhfYWxsb2Nf c2tiKG5pYywgcngpKSkNCisJCQlicmVhazsgLyogQmV0dGVyIGx1Y2sgbmV4 dCB0aW1lIChzZWUgd2F0Y2hkb2cpICovDQorCX0NCisNCisJZTEwMF9zdGFy dF9yZWNlaXZlcihuaWMpOw0KK30NCisNCitzdGF0aWMgdm9pZCBlMTAwX3J4 X2NsZWFuX2xpc3Qoc3RydWN0IG5pYyAqbmljKQ0KK3sNCisJc3RydWN0IHJ4 ICpyeDsNCisJdW5zaWduZWQgaW50IGksIGNvdW50ID0gbmljLT5wYXJhbXMu cmZkcy5jb3VudDsNCisNCisJaWYobmljLT5yeHMpIHsNCisJCWZvcihyeCA9 IG5pYy0+cnhzLCBpID0gMDsgaSA8IGNvdW50OyByeCsrLCBpKyspIHsNCisJ CQlpZihyeC0+c2tiKSB7DQorCQkJCXBjaV91bm1hcF9zaW5nbGUobmljLT5w ZGV2LCByeC0+ZG1hX2FkZHIsDQorCQkJCQlSRkRfQlVGX0xFTiwgUENJX0RN QV9GUk9NREVWSUNFKTsNCisJCQkJZGV2X2tmcmVlX3NrYihyeC0+c2tiKTsN CisJCQl9DQorCQl9DQorCQlrZnJlZShuaWMtPnJ4cyk7DQorCQluaWMtPnJ4 cyA9IE5VTEw7DQorCX0NCisNCisJbmljLT5yeF90b191c2UgPSBuaWMtPnJ4 X3RvX2NsZWFuID0gTlVMTDsNCisJbmljLT5ydV9ydW5uaW5nID0gMDsNCit9 DQorDQorc3RhdGljIGludCBlMTAwX3J4X2FsbG9jX2xpc3Qoc3RydWN0IG5p YyAqbmljKQ0KK3sNCisJc3RydWN0IHJ4ICpyeDsNCisJdW5zaWduZWQgaW50 IGksIGNvdW50ID0gbmljLT5wYXJhbXMucmZkcy5jb3VudDsNCisNCisJbmlj LT5yeF90b191c2UgPSBuaWMtPnJ4X3RvX2NsZWFuID0gTlVMTDsNCisNCisJ aWYoIShuaWMtPnJ4cyA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCByeCkgKiBj b3VudCwgR0ZQX0FUT01JQykpKQ0KKwkJcmV0dXJuIC1FTk9NRU07DQorCW1l bXNldChuaWMtPnJ4cywgMCwgc2l6ZW9mKHN0cnVjdCByeCkgKiBjb3VudCk7 DQorDQorCWZvcihyeCA9IG5pYy0+cnhzLCBpID0gMDsgaSA8IGNvdW50OyBy eCsrLCBpKyspIHsNCisJCXJ4LT5uZXh0ID0gKGkgKyAxIDwgY291bnQpID8g cnggKyAxIDogbmljLT5yeHM7DQorCQlyeC0+cHJldiA9IChpID09IDApID8g bmljLT5yeHMgKyBjb3VudCAtIDEgOiByeCAtIDE7DQorCQlpZihlMTAwX3J4 X2FsbG9jX3NrYihuaWMsIHJ4KSkgew0KKwkJCWUxMDBfcnhfY2xlYW5fbGlz dChuaWMpOw0KKwkJCXJldHVybiAtRU5PTUVNOw0KKwkJfQ0KKwl9DQorDQor CW5pYy0+cnhfdG9fdXNlID0gbmljLT5yeF90b19jbGVhbiA9IG5pYy0+cnhz Ow0KKw0KKwlyZXR1cm4gMDsNCit9DQorDQorc3RhdGljIGlycXJldHVybl90 IGUxMDBfaW50cihpbnQgaXJxLCB2b2lkICpkZXZfaWQsIHN0cnVjdCBwdF9y ZWdzICpyZWdzKQ0KK3sNCisJc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldiA9 IGRldl9pZDsNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2X3ByaXYobmV0 ZGV2KTsNCisJdTggc3RhdF9hY2sgPSByZWFkYigmbmljLT5jc3ItPnNjYi5z dGF0X2Fjayk7DQorDQorCURQUklOVEsoSU5UUiwgREVCVUcsICJzdGF0X2Fj ayA9IDB4JTAyWFxuIiwgc3RhdF9hY2spOw0KKw0KKwlpZihzdGF0X2FjayA9 PSBzdGF0X2Fja19ub3Rfb3VycyB8fAkvKiBOb3Qgb3VyIGludGVycnVwdCAq Lw0KKwkgICBzdGF0X2FjayA9PSBzdGF0X2Fja19ub3RfcHJlc2VudCkJLyog SGFyZHdhcmUgaXMgZWplY3RlZCAqLw0KKwkJcmV0dXJuIElSUV9OT05FOw0K Kw0KKwkvKiBBY2sgaW50ZXJydXB0KHMpICovDQorCXdyaXRlYihzdGF0X2Fj aywgJm5pYy0+Y3NyLT5zY2Iuc3RhdF9hY2spOw0KKw0KKwkvKiBXZSBoaXQg UmVjZWl2ZSBObyBSZXNvdXJjZSAoUk5SKTsgcmVzdGFydCBSVSBhZnRlciBj bGVhbmluZyAqLw0KKwlpZihzdGF0X2FjayAmIHN0YXRfYWNrX3JucikNCisJ CW5pYy0+cnVfcnVubmluZyA9IDA7DQorDQorCWUxMDBfZGlzYWJsZV9pcnEo bmljKTsNCisJbmV0aWZfcnhfc2NoZWR1bGUobmV0ZGV2KTsNCisNCisJcmV0 dXJuIElSUV9IQU5ETEVEOw0KK30NCisNCitzdGF0aWMgaW50IGUxMDBfcG9s bChzdHJ1Y3QgbmV0X2RldmljZSAqbmV0ZGV2LCBpbnQgKmJ1ZGdldCkNCit7 DQorCXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRldl9wcml2KG5ldGRldik7DQor CXVuc2lnbmVkIGludCB3b3JrX3RvX2RvID0gbWluKG5ldGRldi0+cXVvdGEs ICpidWRnZXQpOw0KKwl1bnNpZ25lZCBpbnQgd29ya19kb25lID0gMDsNCisJ aW50IHR4X2NsZWFuZWQ7DQorDQorCWUxMDBfcnhfY2xlYW4obmljLCAmd29y a19kb25lLCB3b3JrX3RvX2RvKTsNCisJdHhfY2xlYW5lZCA9IGUxMDBfdHhf Y2xlYW4obmljKTsNCisNCisJLyogSWYgbm8gUnggYW5kIFR4IGNsZWFudXAg d29yayB3YXMgZG9uZSwgZXhpdCBwb2xsaW5nIG1vZGUuICovDQorCWlmKCgh dHhfY2xlYW5lZCAmJiAod29ya19kb25lID09IDApKSB8fCAhbmV0aWZfcnVu bmluZyhuZXRkZXYpKSB7DQorCQluZXRpZl9yeF9jb21wbGV0ZShuZXRkZXYp Ow0KKwkJZTEwMF9lbmFibGVfaXJxKG5pYyk7DQorCQlyZXR1cm4gMDsNCisJ fQ0KKw0KKwkqYnVkZ2V0IC09IHdvcmtfZG9uZTsNCisJbmV0ZGV2LT5xdW90 YSAtPSB3b3JrX2RvbmU7DQorDQorCXJldHVybiAxOw0KK30NCisNCisjaWZk ZWYgQ09ORklHX05FVF9QT0xMX0NPTlRST0xMRVINCitzdGF0aWMgdm9pZCBl MTAwX25ldHBvbGwoc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldikNCit7DQor CXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRldl9wcml2KG5ldGRldik7DQorCWUx MDBfZGlzYWJsZV9pcnEobmljKTsNCisJZTEwMF9pbnRyKG5pYy0+cGRldi0+ aXJxLCBuZXRkZXYsIE5VTEwpOw0KKwllMTAwX2VuYWJsZV9pcnEobmljKTsN Cit9DQorI2VuZGlmDQorDQorc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0 YXRzICplMTAwX2dldF9zdGF0cyhzdHJ1Y3QgbmV0X2RldmljZSAqbmV0ZGV2 KQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2X3ByaXYobmV0ZGV2 KTsNCisJcmV0dXJuICZuaWMtPm5ldF9zdGF0czsNCit9DQorDQorc3RhdGlj IGludCBlMTAwX3NldF9tYWNfYWRkcmVzcyhzdHJ1Y3QgbmV0X2RldmljZSAq bmV0ZGV2LCB2b2lkICpwKQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0 ZGV2X3ByaXYobmV0ZGV2KTsNCisJc3RydWN0IHNvY2thZGRyICphZGRyID0g cDsNCisNCisJaWYgKCFpc192YWxpZF9ldGhlcl9hZGRyKGFkZHItPnNhX2Rh dGEpKQ0KKwkJcmV0dXJuIC1FQUREUk5PVEFWQUlMOw0KKw0KKwltZW1jcHko bmV0ZGV2LT5kZXZfYWRkciwgYWRkci0+c2FfZGF0YSwgbmV0ZGV2LT5hZGRy X2xlbik7DQorCWUxMDBfZXhlY19jYihuaWMsIE5VTEwsIGUxMDBfc2V0dXBf aWFhZGRyKTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQg ZTEwMF9jaGFuZ2VfbXR1KHN0cnVjdCBuZXRfZGV2aWNlICpuZXRkZXYsIGlu dCBuZXdfbXR1KQ0KK3sNCisJaWYobmV3X210dSA8IEVUSF9aTEVOIHx8IG5l d19tdHUgPiBFVEhfREFUQV9MRU4pDQorCQlyZXR1cm4gLUVJTlZBTDsNCisJ bmV0ZGV2LT5tdHUgPSBuZXdfbXR1Ow0KKwlyZXR1cm4gMDsNCit9DQorDQor c3RhdGljIGludCBlMTAwX2FzZihzdHJ1Y3QgbmljICpuaWMpDQorew0KKwkv KiBBU0YgY2FuIGJlIGVuYWJsZWQgZnJvbSBlZXByb20gKi8NCisJcmV0dXJu KChuaWMtPnBkZXYtPmRldmljZSA+PSAweDEwNTApICYmIChuaWMtPnBkZXYt PmRldmljZSA8PSAweDEwNTcpICYmDQorCSAgIChuaWMtPmVlcHJvbVtlZXBy b21fY29uZmlnX2FzZl0gJiBlZXByb21fYXNmKSAmJg0KKwkgICAhKG5pYy0+ ZWVwcm9tW2VlcHJvbV9jb25maWdfYXNmXSAmIGVlcHJvbV9nY2wpICYmDQor CSAgICgobmljLT5lZXByb21bZWVwcm9tX3NtYnVzX2FkZHJdICYgMHhGRikg IT0gMHhGRSkpOw0KK30NCisNCitzdGF0aWMgaW50IGUxMDBfdXAoc3RydWN0 IG5pYyAqbmljKQ0KK3sNCisJaW50IGVycjsNCisNCisJaWYoKGVyciA9IGUx MDBfcnhfYWxsb2NfbGlzdChuaWMpKSkNCisJCXJldHVybiBlcnI7DQorCWlm KChlcnIgPSBlMTAwX2FsbG9jX2NicyhuaWMpKSkNCisJCWdvdG8gZXJyX3J4 X2NsZWFuX2xpc3Q7DQorCWlmKChlcnIgPSBlMTAwX2h3X2luaXQobmljKSkp DQorCQlnb3RvIGVycl9jbGVhbl9jYnM7DQorCWUxMDBfc2V0X211bHRpY2Fz dF9saXN0KG5pYy0+bmV0ZGV2KTsNCisJZTEwMF9zdGFydF9yZWNlaXZlcihu aWMpOw0KKwltb2RfdGltZXIoJm5pYy0+d2F0Y2hkb2csIGppZmZpZXMpOw0K KwlpZigoZXJyID0gcmVxdWVzdF9pcnEobmljLT5wZGV2LT5pcnEsIGUxMDBf aW50ciwgU0FfU0hJUlEsDQorCQluaWMtPm5ldGRldi0+bmFtZSwgbmljLT5u ZXRkZXYpKSkNCisJCWdvdG8gZXJyX25vX2lycTsNCisJZTEwMF9lbmFibGVf aXJxKG5pYyk7DQorCW5ldGlmX3dha2VfcXVldWUobmljLT5uZXRkZXYpOw0K KwlyZXR1cm4gMDsNCisNCitlcnJfbm9faXJxOg0KKwlkZWxfdGltZXJfc3lu YygmbmljLT53YXRjaGRvZyk7DQorZXJyX2NsZWFuX2NiczoNCisJZTEwMF9j bGVhbl9jYnMobmljKTsNCitlcnJfcnhfY2xlYW5fbGlzdDoNCisJZTEwMF9y eF9jbGVhbl9saXN0KG5pYyk7DQorCXJldHVybiBlcnI7DQorfQ0KKw0KK3N0 YXRpYyB2b2lkIGUxMDBfZG93bihzdHJ1Y3QgbmljICpuaWMpDQorew0KKwll MTAwX2h3X3Jlc2V0KG5pYyk7DQorCWZyZWVfaXJxKG5pYy0+cGRldi0+aXJx LCBuaWMtPm5ldGRldik7DQorCWRlbF90aW1lcl9zeW5jKCZuaWMtPndhdGNo ZG9nKTsNCisJbmV0aWZfY2Fycmllcl9vZmYobmljLT5uZXRkZXYpOw0KKwlu ZXRpZl9zdG9wX3F1ZXVlKG5pYy0+bmV0ZGV2KTsNCisJZTEwMF9jbGVhbl9j YnMobmljKTsNCisJZTEwMF9yeF9jbGVhbl9saXN0KG5pYyk7DQorfQ0KKw0K K3N0YXRpYyB2b2lkIGUxMDBfdHhfdGltZW91dChzdHJ1Y3QgbmV0X2Rldmlj ZSAqbmV0ZGV2KQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2X3By aXYobmV0ZGV2KTsNCisNCisJRFBSSU5USyhUWF9FUlIsIERFQlVHLCAic2Ni LnN0YXR1cz0weCUwMlhcbiIsDQorCQlyZWFkYigmbmljLT5jc3ItPnNjYi5z dGF0dXMpKTsNCisJZTEwMF9kb3duKG5ldGRldl9wcml2KG5ldGRldikpOw0K KwllMTAwX3VwKG5ldGRldl9wcml2KG5ldGRldikpOw0KK30NCisNCitzdGF0 aWMgaW50IGUxMDBfbG9vcGJhY2tfdGVzdChzdHJ1Y3QgbmljICpuaWMsIGVu dW0gbG9vcGJhY2sgbG9vcGJhY2tfbW9kZSkNCit7DQorCWludCBlcnI7DQor CXN0cnVjdCBza19idWZmICpza2I7DQorDQorCS8qIFVzZSBkcml2ZXIgcmVz b3VyY2VzIHRvIHBlcmZvcm0gaW50ZXJuYWwgTUFDIG9yIFBIWQ0KKwkgKiBs b29wYmFjayB0ZXN0LiAgQSBzaW5nbGUgcGFja2V0IGlzIHByZXBhcmVkIGFu ZCB0cmFuc21pdHRlZA0KKwkgKiBpbiBsb29wYmFjayBtb2RlLCBhbmQgdGhl IHRlc3QgcGFzc2VzIGlmIHRoZSByZWNlaXZlZA0KKwkgKiBwYWNrZXQgY29t cGFyZXMgYnl0ZS1mb3ItYnl0ZSB0byB0aGUgdHJhbnNtaXR0ZWQgcGFja2V0 LiAqLw0KKw0KKwlpZigoZXJyID0gZTEwMF9yeF9hbGxvY19saXN0KG5pYykp KQ0KKwkJcmV0dXJuIGVycjsNCisJaWYoKGVyciA9IGUxMDBfYWxsb2NfY2Jz KG5pYykpKQ0KKwkJZ290byBlcnJfY2xlYW5fcng7DQorDQorCS8qIElDSCBQ SFkgbG9vcGJhY2sgaXMgYnJva2VuIHNvIGRvIE1BQyBsb29wYmFjayBpbnN0 ZWFkICovDQorCWlmKG5pYy0+ZmxhZ3MgJiBpY2ggJiYgbG9vcGJhY2tfbW9k ZSA9PSBsYl9waHkpDQorCQlsb29wYmFja19tb2RlID0gbGJfbWFjOw0KKw0K KwluaWMtPmxvb3BiYWNrID0gbG9vcGJhY2tfbW9kZTsNCisJaWYoKGVyciA9 IGUxMDBfaHdfaW5pdChuaWMpKSkNCisJCWdvdG8gZXJyX2xvb3BiYWNrX25v bmU7DQorDQorCWlmKGxvb3BiYWNrX21vZGUgPT0gbGJfcGh5KQ0KKwkJbWRp b193cml0ZShuaWMtPm5ldGRldiwgbmljLT5taWkucGh5X2lkLCBNSUlfQk1D UiwNCisJCQlCTUNSX0xPT1BCQUNLKTsNCisNCisJZTEwMF9zdGFydF9yZWNl aXZlcihuaWMpOw0KKw0KKwlpZighKHNrYiA9IGRldl9hbGxvY19za2IoRVRI X0RBVEFfTEVOKSkpIHsNCisJCWVyciA9IC1FTk9NRU07DQorCQlnb3RvIGVy cl9sb29wYmFja19ub25lOw0KKwl9DQorCXNrYl9wdXQoc2tiLCBFVEhfREFU QV9MRU4pOw0KKwltZW1zZXQoc2tiLT5kYXRhLCAweEZGLCBFVEhfREFUQV9M RU4pOw0KKwllMTAwX3htaXRfZnJhbWUoc2tiLCBuaWMtPm5ldGRldik7DQor DQorCXNldF9jdXJyZW50X3N0YXRlKFRBU0tfVU5JTlRFUlJVUFRJQkxFKTsN CisJc2NoZWR1bGVfdGltZW91dChIWiAvIDEwMCArIDEpOw0KKw0KKwlpZiht ZW1jbXAobmljLT5yeF90b19jbGVhbi0+c2tiLT5kYXRhICsgc2l6ZW9mKHN0 cnVjdCByZmQpLA0KKwkgICBza2ItPmRhdGEsIEVUSF9EQVRBX0xFTikpDQor ICAgICAgIAkJZXJyID0gLUVBR0FJTjsNCisNCitlcnJfbG9vcGJhY2tfbm9u ZToNCisJbWRpb193cml0ZShuaWMtPm5ldGRldiwgbmljLT5taWkucGh5X2lk LCBNSUlfQk1DUiwgMCk7DQorCW5pYy0+bG9vcGJhY2sgPSBsYl9ub25lOw0K KwllMTAwX2h3X2luaXQobmljKTsNCisJZTEwMF9jbGVhbl9jYnMobmljKTsN CitlcnJfY2xlYW5fcng6DQorCWUxMDBfcnhfY2xlYW5fbGlzdChuaWMpOw0K KwlyZXR1cm4gZXJyOw0KK30NCisNCisjZGVmaW5lIE1JSV9MRURfQ09OVFJP TAkweDFCDQorc3RhdGljIHZvaWQgZTEwMF9ibGlua19sZWQodW5zaWduZWQg bG9uZyBkYXRhKQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gKHN0cnVjdCBu aWMgKilkYXRhOw0KKwllbnVtIGxlZF9zdGF0ZSB7DQorCQlsZWRfb24gICAg ID0gMHgwMSwNCisJCWxlZF9vZmYgICAgPSAweDA0LA0KKwkJbGVkX29uXzU1 OSA9IDB4MDUsDQorCQlsZWRfb25fNTU3ID0gMHgwNywNCisJfTsNCisNCisJ bmljLT5sZWRzID0gKG5pYy0+bGVkcyAmIGxlZF9vbikgPyBsZWRfb2ZmIDoN CisJCShuaWMtPm1hYyA8IG1hY184MjU1OV9EMTAxTSkgPyBsZWRfb25fNTU3 IDogbGVkX29uXzU1OTsNCisJbWRpb193cml0ZShuaWMtPm5ldGRldiwgbmlj LT5taWkucGh5X2lkLCBNSUlfTEVEX0NPTlRST0wsIG5pYy0+bGVkcyk7DQor CW1vZF90aW1lcigmbmljLT5ibGlua190aW1lciwgamlmZmllcyArIEhaIC8g NCk7DQorfQ0KKw0KK3N0YXRpYyBpbnQgZTEwMF9nZXRfc2V0dGluZ3Moc3Ry dWN0IG5ldF9kZXZpY2UgKm5ldGRldiwgc3RydWN0IGV0aHRvb2xfY21kICpj bWQpDQorew0KKwlzdHJ1Y3QgbmljICpuaWMgPSBuZXRkZXZfcHJpdihuZXRk ZXYpOw0KKwlyZXR1cm4gbWlpX2V0aHRvb2xfZ3NldCgmbmljLT5taWksIGNt ZCk7DQorfQ0KKw0KK3N0YXRpYyBpbnQgZTEwMF9zZXRfc2V0dGluZ3Moc3Ry dWN0IG5ldF9kZXZpY2UgKm5ldGRldiwgc3RydWN0IGV0aHRvb2xfY21kICpj bWQpDQorew0KKwlzdHJ1Y3QgbmljICpuaWMgPSBuZXRkZXZfcHJpdihuZXRk ZXYpOw0KKwlpbnQgZXJyOw0KKw0KKwltZGlvX3dyaXRlKG5ldGRldiwgbmlj LT5taWkucGh5X2lkLCBNSUlfQk1DUiwgQk1DUl9SRVNFVCk7DQorCWVyciA9 IG1paV9ldGh0b29sX3NzZXQoJm5pYy0+bWlpLCBjbWQpOw0KKwllMTAwX2V4 ZWNfY2IobmljLCBOVUxMLCBlMTAwX2NvbmZpZ3VyZSk7DQorDQorCXJldHVy biBlcnI7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGUxMDBfZ2V0X2RydmluZm8o c3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldiwNCisJc3RydWN0IGV0aHRvb2xf ZHJ2aW5mbyAqaW5mbykNCit7DQorCXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRl dl9wcml2KG5ldGRldik7DQorCXN0cmNweShpbmZvLT5kcml2ZXIsIERSVl9O QU1FKTsNCisJc3RyY3B5KGluZm8tPnZlcnNpb24sIERSVl9WRVJTSU9OKTsN CisJc3RyY3B5KGluZm8tPmZ3X3ZlcnNpb24sICJOL0EiKTsNCisJc3RyY3B5 KGluZm8tPmJ1c19pbmZvLCBwY2lfbmFtZShuaWMtPnBkZXYpKTsNCit9DQor DQorc3RhdGljIGludCBlMTAwX2dldF9yZWdzX2xlbihzdHJ1Y3QgbmV0X2Rl dmljZSAqbmV0ZGV2KQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2 X3ByaXYobmV0ZGV2KTsNCisjZGVmaW5lIEUxMDBfUEhZX1JFR1MJCTB4MUMN CisjZGVmaW5lIEUxMDBfUkVHU19MRU4JCTEgKyBFMTAwX1BIWV9SRUdTICsg XA0KKwlzaXplb2YobmljLT5tZW0tPmR1bXBfYnVmKSAvIHNpemVvZih1MzIp DQorCXJldHVybiBFMTAwX1JFR1NfTEVOICogc2l6ZW9mKHUzMik7DQorfQ0K Kw0KK3N0YXRpYyB2b2lkIGUxMDBfZ2V0X3JlZ3Moc3RydWN0IG5ldF9kZXZp Y2UgKm5ldGRldiwNCisJc3RydWN0IGV0aHRvb2xfcmVncyAqcmVncywgdm9p ZCAqcCkNCit7DQorCXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRldl9wcml2KG5l dGRldik7DQorCXUzMiAqYnVmZiA9IHA7DQorCWludCBpOw0KKw0KKwlyZWdz LT52ZXJzaW9uID0gKDEgPDwgMjQpIHwgbmljLT5yZXZfaWQ7DQorCWJ1ZmZb MF0gPSByZWFkYigmbmljLT5jc3ItPnNjYi5jbWRfaGkpIDw8IDI0IHwNCisJ CXJlYWRiKCZuaWMtPmNzci0+c2NiLmNtZF9sbykgPDwgMTYgfA0KKwkJcmVh ZHcoJm5pYy0+Y3NyLT5zY2Iuc3RhdHVzKTsNCisJZm9yKGkgPSBFMTAwX1BI WV9SRUdTOyBpID49IDA7IGktLSkNCisJCWJ1ZmZbMSArIEUxMDBfUEhZX1JF R1MgLSBpXSA9DQorCQkJbWRpb19yZWFkKG5ldGRldiwgbmljLT5taWkucGh5 X2lkLCBpKTsNCisJbWVtc2V0KG5pYy0+bWVtLT5kdW1wX2J1ZiwgMCwgc2l6 ZW9mKG5pYy0+bWVtLT5kdW1wX2J1ZikpOw0KKwllMTAwX2V4ZWNfY2Iobmlj LCBOVUxMLCBlMTAwX2R1bXApOw0KKwlzZXRfY3VycmVudF9zdGF0ZShUQVNL X1VOSU5URVJSVVBUSUJMRSk7DQorCXNjaGVkdWxlX3RpbWVvdXQoSFogLyAx MDAgKyAxKTsNCisJbWVtY3B5KCZidWZmWzIgKyBFMTAwX1BIWV9SRUdTXSwg bmljLT5tZW0tPmR1bXBfYnVmLA0KKwkJc2l6ZW9mKG5pYy0+bWVtLT5kdW1w X2J1ZikpOw0KK30NCisNCitzdGF0aWMgdm9pZCBlMTAwX2dldF93b2woc3Ry dWN0IG5ldF9kZXZpY2UgKm5ldGRldiwgc3RydWN0IGV0aHRvb2xfd29saW5m byAqd29sKQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2X3ByaXYo bmV0ZGV2KTsNCisJd29sLT5zdXBwb3J0ZWQgPSAobmljLT5tYWMgPj0gbWFj XzgyNTU4X0QxMDFfQTQpID8gIFdBS0VfTUFHSUMgOiAwOw0KKwl3b2wtPndv bG9wdHMgPSAobmljLT5mbGFncyAmIHdvbF9tYWdpYykgPyBXQUtFX01BR0lD IDogMDsNCit9DQorDQorc3RhdGljIGludCBlMTAwX3NldF93b2woc3RydWN0 IG5ldF9kZXZpY2UgKm5ldGRldiwgc3RydWN0IGV0aHRvb2xfd29saW5mbyAq d29sKQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2X3ByaXYobmV0 ZGV2KTsNCisNCisJaWYod29sLT53b2xvcHRzICE9IFdBS0VfTUFHSUMgJiYg d29sLT53b2xvcHRzICE9IDApDQorCQlyZXR1cm4gLUVPUE5PVFNVUFA7DQor DQorCWlmKHdvbC0+d29sb3B0cykNCisJCW5pYy0+ZmxhZ3MgfD0gd29sX21h Z2ljOw0KKwllbHNlDQorCQluaWMtPmZsYWdzICY9IH53b2xfbWFnaWM7DQor DQorCXBjaV9lbmFibGVfd2FrZShuaWMtPnBkZXYsIDAsIG5pYy0+ZmxhZ3Mg JiAod29sX21hZ2ljIHwgZTEwMF9hc2YobmljKSkpOw0KKwllMTAwX2V4ZWNf Y2IobmljLCBOVUxMLCBlMTAwX2NvbmZpZ3VyZSk7DQorDQorCXJldHVybiAw Ow0KK30NCisNCitzdGF0aWMgdTMyIGUxMDBfZ2V0X21zZ2xldmVsKHN0cnVj dCBuZXRfZGV2aWNlICpuZXRkZXYpDQorew0KKwlzdHJ1Y3QgbmljICpuaWMg PSBuZXRkZXZfcHJpdihuZXRkZXYpOw0KKwlyZXR1cm4gbmljLT5tc2dfZW5h YmxlOw0KK30NCisNCitzdGF0aWMgdm9pZCBlMTAwX3NldF9tc2dsZXZlbChz dHJ1Y3QgbmV0X2RldmljZSAqbmV0ZGV2LCB1MzIgdmFsdWUpDQorew0KKwlz dHJ1Y3QgbmljICpuaWMgPSBuZXRkZXZfcHJpdihuZXRkZXYpOw0KKwluaWMt Pm1zZ19lbmFibGUgPSB2YWx1ZTsNCit9DQorDQorc3RhdGljIGludCBlMTAw X253YXlfcmVzZXQoc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldikNCit7DQor CXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRldl9wcml2KG5ldGRldik7DQorCXJl dHVybiBtaWlfbndheV9yZXN0YXJ0KCZuaWMtPm1paSk7DQorfQ0KKw0KK3N0 YXRpYyB1MzIgZTEwMF9nZXRfbGluayhzdHJ1Y3QgbmV0X2RldmljZSAqbmV0 ZGV2KQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2X3ByaXYobmV0 ZGV2KTsNCisJcmV0dXJuIG1paV9saW5rX29rKCZuaWMtPm1paSk7DQorfQ0K Kw0KK3N0YXRpYyBpbnQgZTEwMF9nZXRfZWVwcm9tX2xlbihzdHJ1Y3QgbmV0 X2RldmljZSAqbmV0ZGV2KQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0 ZGV2X3ByaXYobmV0ZGV2KTsNCisJcmV0dXJuIG5pYy0+ZWVwcm9tX3djIDw8 IDE7DQorfQ0KKw0KKyNkZWZpbmUgRTEwMF9FRVBST01fTUFHSUMJMHgxMjM0 DQorc3RhdGljIGludCBlMTAwX2dldF9lZXByb20oc3RydWN0IG5ldF9kZXZp Y2UgKm5ldGRldiwNCisJc3RydWN0IGV0aHRvb2xfZWVwcm9tICplZXByb20s IHU4ICpieXRlcykNCit7DQorCXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRldl9w cml2KG5ldGRldik7DQorDQorCWVlcHJvbS0+bWFnaWMgPSBFMTAwX0VFUFJP TV9NQUdJQzsNCisJbWVtY3B5KGJ5dGVzLCAmKCh1OCAqKW5pYy0+ZWVwcm9t KVtlZXByb20tPm9mZnNldF0sIGVlcHJvbS0+bGVuKTsNCisNCisJcmV0dXJu IDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgZTEwMF9zZXRfZWVwcm9tKHN0cnVj dCBuZXRfZGV2aWNlICpuZXRkZXYsDQorCXN0cnVjdCBldGh0b29sX2VlcHJv bSAqZWVwcm9tLCB1OCAqYnl0ZXMpDQorew0KKwlzdHJ1Y3QgbmljICpuaWMg PSBuZXRkZXZfcHJpdihuZXRkZXYpOw0KKw0KKwlpZihlZXByb20tPm1hZ2lj ICE9IEUxMDBfRUVQUk9NX01BR0lDKQ0KKwkJcmV0dXJuIC1FSU5WQUw7DQor DQorCW1lbWNweSgmKCh1OCAqKW5pYy0+ZWVwcm9tKVtlZXByb20tPm9mZnNl dF0sIGJ5dGVzLCBlZXByb20tPmxlbik7DQorDQorCXJldHVybiBlMTAwX2Vl cHJvbV9zYXZlKG5pYywgZWVwcm9tLT5vZmZzZXQgPj4gMSwNCisJCShlZXBy b20tPmxlbiA+PiAxKSArIDEpOw0KK30NCisNCitzdGF0aWMgdm9pZCBlMTAw X2dldF9yaW5ncGFyYW0oc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldiwNCisJ c3RydWN0IGV0aHRvb2xfcmluZ3BhcmFtICpyaW5nKQ0KK3sNCisJc3RydWN0 IG5pYyAqbmljID0gbmV0ZGV2X3ByaXYobmV0ZGV2KTsNCisJc3RydWN0IHBh cmFtX3JhbmdlICpyZmRzID0gJm5pYy0+cGFyYW1zLnJmZHM7DQorCXN0cnVj dCBwYXJhbV9yYW5nZSAqY2JzID0gJm5pYy0+cGFyYW1zLmNiczsNCisNCisJ cmluZy0+cnhfbWF4X3BlbmRpbmcgPSByZmRzLT5tYXg7DQorCXJpbmctPnR4 X21heF9wZW5kaW5nID0gY2JzLT5tYXg7DQorCXJpbmctPnJ4X21pbmlfbWF4 X3BlbmRpbmcgPSAwOw0KKwlyaW5nLT5yeF9qdW1ib19tYXhfcGVuZGluZyA9 IDA7DQorCXJpbmctPnJ4X3BlbmRpbmcgPSByZmRzLT5jb3VudDsNCisJcmlu Zy0+dHhfcGVuZGluZyA9IGNicy0+Y291bnQ7DQorCXJpbmctPnJ4X21pbmlf cGVuZGluZyA9IDA7DQorCXJpbmctPnJ4X2p1bWJvX3BlbmRpbmcgPSAwOw0K K30NCisNCitzdGF0aWMgaW50IGUxMDBfc2V0X3JpbmdwYXJhbShzdHJ1Y3Qg bmV0X2RldmljZSAqbmV0ZGV2LA0KKwlzdHJ1Y3QgZXRodG9vbF9yaW5ncGFy YW0gKnJpbmcpDQorew0KKwlzdHJ1Y3QgbmljICpuaWMgPSBuZXRkZXZfcHJp dihuZXRkZXYpOw0KKwlzdHJ1Y3QgcGFyYW1fcmFuZ2UgKnJmZHMgPSAmbmlj LT5wYXJhbXMucmZkczsNCisJc3RydWN0IHBhcmFtX3JhbmdlICpjYnMgPSAm bmljLT5wYXJhbXMuY2JzOw0KKw0KKwlpZihuZXRpZl9ydW5uaW5nKG5ldGRl dikpDQorCQllMTAwX2Rvd24obmljKTsNCisJcmZkcy0+Y291bnQgPSBtYXgo cmluZy0+cnhfcGVuZGluZywgcmZkcy0+bWluKTsNCisJcmZkcy0+Y291bnQg PSBtaW4ocmZkcy0+Y291bnQsIHJmZHMtPm1heCk7DQorCWNicy0+Y291bnQg PSBtYXgocmluZy0+dHhfcGVuZGluZywgY2JzLT5taW4pOw0KKwljYnMtPmNv dW50ID0gbWluKGNicy0+Y291bnQsIGNicy0+bWF4KTsNCisJaWYobmV0aWZf cnVubmluZyhuZXRkZXYpKQ0KKwkJZTEwMF91cChuaWMpOw0KKw0KKwlyZXR1 cm4gMDsNCit9DQorDQorc3RhdGljIGNvbnN0IGNoYXIgZTEwMF9nc3RyaW5n c190ZXN0W11bRVRIX0dTVFJJTkdfTEVOXSA9IHsNCisJIkxpbmsgdGVzdCAg ICAgKG9uL29mZmxpbmUpIiwNCisJIkVlcHJvbSB0ZXN0ICAgKG9uL29mZmxp bmUpIiwNCisJIlNlbGYgdGVzdCAgICAgICAgKG9mZmxpbmUpIiwNCisJIk1h YyBsb29wYmFjayAgICAgKG9mZmxpbmUpIiwNCisJIlBoeSBsb29wYmFjayAg ICAgKG9mZmxpbmUpIiwNCit9Ow0KKyNkZWZpbmUgRTEwMF9URVNUX0xFTglz aXplb2YoZTEwMF9nc3RyaW5nc190ZXN0KSAvIEVUSF9HU1RSSU5HX0xFTg0K Kw0KK3N0YXRpYyBpbnQgZTEwMF9kaWFnX3Rlc3RfY291bnQoc3RydWN0IG5l dF9kZXZpY2UgKm5ldGRldikNCit7DQorCXJldHVybiBFMTAwX1RFU1RfTEVO Ow0KK30NCisNCitzdGF0aWMgdm9pZCBlMTAwX2RpYWdfdGVzdChzdHJ1Y3Qg bmV0X2RldmljZSAqbmV0ZGV2LA0KKwlzdHJ1Y3QgZXRodG9vbF90ZXN0ICp0 ZXN0LCB1NjQgKmRhdGEpDQorew0KKwlzdHJ1Y3QgZXRodG9vbF9jbWQgY21k Ow0KKwlzdHJ1Y3QgbmljICpuaWMgPSBuZXRkZXZfcHJpdihuZXRkZXYpOw0K KwlpbnQgaSwgZXJyOw0KKw0KKwltZW1zZXQoZGF0YSwgMCwgRTEwMF9URVNU X0xFTiAqIHNpemVvZih1NjQpKTsNCisJZGF0YVswXSA9ICFtaWlfbGlua19v aygmbmljLT5taWkpOw0KKwlkYXRhWzFdID0gZTEwMF9lZXByb21fbG9hZChu aWMpOw0KKwlpZih0ZXN0LT5mbGFncyAmIEVUSF9URVNUX0ZMX09GRkxJTkUp IHsNCisNCisJCS8qIHNhdmUgc3BlZWQsIGR1cGxleCAmIGF1dG9uZWcgc2V0 dGluZ3MgKi8NCisJCWVyciA9IG1paV9ldGh0b29sX2dzZXQoJm5pYy0+bWlp LCAmY21kKTsNCisNCisJCWlmKG5ldGlmX3J1bm5pbmcobmV0ZGV2KSkNCisJ CQllMTAwX2Rvd24obmljKTsNCisJCWRhdGFbMl0gPSBlMTAwX3NlbGZfdGVz dChuaWMpOw0KKwkJZGF0YVszXSA9IGUxMDBfbG9vcGJhY2tfdGVzdChuaWMs IGxiX21hYyk7DQorCQlkYXRhWzRdID0gZTEwMF9sb29wYmFja190ZXN0KG5p YywgbGJfcGh5KTsNCisNCisJCS8qIHJlc3RvcmUgc3BlZWQsIGR1cGxleCAm IGF1dG9uZWcgc2V0dGluZ3MgKi8NCisJCWVyciA9IG1paV9ldGh0b29sX3Nz ZXQoJm5pYy0+bWlpLCAmY21kKTsNCisNCisJCWlmKG5ldGlmX3J1bm5pbmco bmV0ZGV2KSkNCisJCQllMTAwX3VwKG5pYyk7DQorCX0NCisJZm9yKGkgPSAw OyBpIDwgRTEwMF9URVNUX0xFTjsgaSsrKQ0KKwkJdGVzdC0+ZmxhZ3MgfD0g ZGF0YVtpXSA/IEVUSF9URVNUX0ZMX0ZBSUxFRCA6IDA7DQorfQ0KKw0KK3N0 YXRpYyBpbnQgZTEwMF9waHlzX2lkKHN0cnVjdCBuZXRfZGV2aWNlICpuZXRk ZXYsIHUzMiBkYXRhKQ0KK3sNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2 X3ByaXYobmV0ZGV2KTsNCisNCisJaWYoIWRhdGEgfHwgZGF0YSA+ICh1MzIp KE1BWF9TQ0hFRFVMRV9USU1FT1VUIC8gSFopKQ0KKwkJZGF0YSA9ICh1MzIp KE1BWF9TQ0hFRFVMRV9USU1FT1VUIC8gSFopOw0KKwltb2RfdGltZXIoJm5p Yy0+YmxpbmtfdGltZXIsIGppZmZpZXMpOw0KKwlzZXRfY3VycmVudF9zdGF0 ZShUQVNLX0lOVEVSUlVQVElCTEUpOw0KKwlzY2hlZHVsZV90aW1lb3V0KGRh dGEgKiBIWik7DQorCWRlbF90aW1lcl9zeW5jKCZuaWMtPmJsaW5rX3RpbWVy KTsNCisJbWRpb193cml0ZShuZXRkZXYsIG5pYy0+bWlpLnBoeV9pZCwgTUlJ X0xFRF9DT05UUk9MLCAwKTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KK3N0 YXRpYyBjb25zdCBjaGFyIGUxMDBfZ3N0cmluZ3Nfc3RhdHNbXVtFVEhfR1NU UklOR19MRU5dID0gew0KKwkicnhfcGFja2V0cyIsICJ0eF9wYWNrZXRzIiwg InJ4X2J5dGVzIiwgInR4X2J5dGVzIiwgInJ4X2Vycm9ycyIsDQorCSJ0eF9l cnJvcnMiLCAicnhfZHJvcHBlZCIsICJ0eF9kcm9wcGVkIiwgIm11bHRpY2Fz dCIsICJjb2xsaXNpb25zIiwNCisJInJ4X2xlbmd0aF9lcnJvcnMiLCAicnhf b3Zlcl9lcnJvcnMiLCAicnhfY3JjX2Vycm9ycyIsDQorCSJyeF9mcmFtZV9l cnJvcnMiLCAicnhfZmlmb19lcnJvcnMiLCAicnhfbWlzc2VkX2Vycm9ycyIs DQorCSJ0eF9hYm9ydGVkX2Vycm9ycyIsICJ0eF9jYXJyaWVyX2Vycm9ycyIs ICJ0eF9maWZvX2Vycm9ycyIsDQorCSJ0eF9oZWFydGJlYXRfZXJyb3JzIiwg InR4X3dpbmRvd19lcnJvcnMiLA0KKwkvKiBkZXZpY2Utc3BlY2lmaWMgc3Rh dHMgKi8NCisJInR4X2RlZmVycmVkIiwgInR4X3NpbmdsZV9jb2xsaXNpb25z IiwgInR4X211bHRpX2NvbGxpc2lvbnMiLA0KKwkidHhfZmxvd19jb250cm9s X3BhdXNlIiwgInJ4X2Zsb3dfY29udHJvbF9wYXVzZSIsDQorCSJyeF9mbG93 X2NvbnRyb2xfdW5zdXBwb3J0ZWQiLCAidHhfdGNvX3BhY2tldHMiLCAicnhf dGNvX3BhY2tldHMiLA0KK307DQorI2RlZmluZSBFMTAwX05FVF9TVEFUU19M RU4JMjENCisjZGVmaW5lIEUxMDBfU1RBVFNfTEVOCXNpemVvZihlMTAwX2dz dHJpbmdzX3N0YXRzKSAvIEVUSF9HU1RSSU5HX0xFTg0KKw0KK3N0YXRpYyBp bnQgZTEwMF9nZXRfc3RhdHNfY291bnQoc3RydWN0IG5ldF9kZXZpY2UgKm5l dGRldikNCit7DQorCXJldHVybiBFMTAwX1NUQVRTX0xFTjsNCit9DQorDQor c3RhdGljIHZvaWQgZTEwMF9nZXRfZXRodG9vbF9zdGF0cyhzdHJ1Y3QgbmV0 X2RldmljZSAqbmV0ZGV2LA0KKwlzdHJ1Y3QgZXRodG9vbF9zdGF0cyAqc3Rh dHMsIHU2NCAqZGF0YSkNCit7DQorCXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRl dl9wcml2KG5ldGRldik7DQorCWludCBpOw0KKw0KKwlmb3IoaSA9IDA7IGkg PCBFMTAwX05FVF9TVEFUU19MRU47IGkrKykNCisJCWRhdGFbaV0gPSAoKHVu c2lnbmVkIGxvbmcgKikmbmljLT5uZXRfc3RhdHMpW2ldOw0KKw0KKwlkYXRh W2krK10gPSBuaWMtPnR4X2RlZmVycmVkOw0KKwlkYXRhW2krK10gPSBuaWMt PnR4X3NpbmdsZV9jb2xsaXNpb25zOw0KKwlkYXRhW2krK10gPSBuaWMtPnR4 X211bHRpcGxlX2NvbGxpc2lvbnM7DQorCWRhdGFbaSsrXSA9IG5pYy0+dHhf ZmNfcGF1c2U7DQorCWRhdGFbaSsrXSA9IG5pYy0+cnhfZmNfcGF1c2U7DQor CWRhdGFbaSsrXSA9IG5pYy0+cnhfZmNfdW5zdXBwb3J0ZWQ7DQorCWRhdGFb aSsrXSA9IG5pYy0+dHhfdGNvX2ZyYW1lczsNCisJZGF0YVtpKytdID0gbmlj LT5yeF90Y29fZnJhbWVzOw0KK30NCisNCitzdGF0aWMgdm9pZCBlMTAwX2dl dF9zdHJpbmdzKHN0cnVjdCBuZXRfZGV2aWNlICpuZXRkZXYsIHUzMiBzdHJp bmdzZXQsIHU4ICpkYXRhKQ0KK3sNCisJc3dpdGNoKHN0cmluZ3NldCkgew0K KwljYXNlIEVUSF9TU19URVNUOg0KKwkJbWVtY3B5KGRhdGEsICplMTAwX2dz dHJpbmdzX3Rlc3QsIHNpemVvZihlMTAwX2dzdHJpbmdzX3Rlc3QpKTsNCisJ CWJyZWFrOw0KKwljYXNlIEVUSF9TU19TVEFUUzoNCisJCW1lbWNweShkYXRh LCAqZTEwMF9nc3RyaW5nc19zdGF0cywgc2l6ZW9mKGUxMDBfZ3N0cmluZ3Nf c3RhdHMpKTsNCisJCWJyZWFrOw0KKwl9DQorfQ0KKw0KK3N0YXRpYyBzdHJ1 Y3QgZXRodG9vbF9vcHMgZTEwMF9ldGh0b29sX29wcyA9IHsNCisJLmdldF9z ZXR0aW5ncwkJPSBlMTAwX2dldF9zZXR0aW5ncywNCisJLnNldF9zZXR0aW5n cwkJPSBlMTAwX3NldF9zZXR0aW5ncywNCisJLmdldF9kcnZpbmZvCQk9IGUx MDBfZ2V0X2RydmluZm8sDQorCS5nZXRfcmVnc19sZW4JCT0gZTEwMF9nZXRf cmVnc19sZW4sDQorCS5nZXRfcmVncwkJPSBlMTAwX2dldF9yZWdzLA0KKwku Z2V0X3dvbAkJPSBlMTAwX2dldF93b2wsDQorCS5zZXRfd29sCQk9IGUxMDBf c2V0X3dvbCwNCisJLmdldF9tc2dsZXZlbAkJPSBlMTAwX2dldF9tc2dsZXZl bCwNCisJLnNldF9tc2dsZXZlbAkJPSBlMTAwX3NldF9tc2dsZXZlbCwNCisJ Lm53YXlfcmVzZXQJCT0gZTEwMF9ud2F5X3Jlc2V0LA0KKwkuZ2V0X2xpbmsJ CT0gZTEwMF9nZXRfbGluaywNCisJLmdldF9lZXByb21fbGVuCQk9IGUxMDBf Z2V0X2VlcHJvbV9sZW4sDQorCS5nZXRfZWVwcm9tCQk9IGUxMDBfZ2V0X2Vl cHJvbSwNCisJLnNldF9lZXByb20JCT0gZTEwMF9zZXRfZWVwcm9tLA0KKwku Z2V0X3JpbmdwYXJhbQkJPSBlMTAwX2dldF9yaW5ncGFyYW0sDQorCS5zZXRf cmluZ3BhcmFtCQk9IGUxMDBfc2V0X3JpbmdwYXJhbSwNCisJLnNlbGZfdGVz dF9jb3VudAk9IGUxMDBfZGlhZ190ZXN0X2NvdW50LA0KKwkuc2VsZl90ZXN0 CQk9IGUxMDBfZGlhZ190ZXN0LA0KKwkuZ2V0X3N0cmluZ3MJCT0gZTEwMF9n ZXRfc3RyaW5ncywNCisJLnBoeXNfaWQJCT0gZTEwMF9waHlzX2lkLA0KKwku Z2V0X3N0YXRzX2NvdW50CT0gZTEwMF9nZXRfc3RhdHNfY291bnQsDQorCS5n ZXRfZXRodG9vbF9zdGF0cwk9IGUxMDBfZ2V0X2V0aHRvb2xfc3RhdHMsDQor fTsNCisNCitzdGF0aWMgaW50IGUxMDBfZG9faW9jdGwoc3RydWN0IG5ldF9k ZXZpY2UgKm5ldGRldiwgc3RydWN0IGlmcmVxICppZnIsIGludCBjbWQpDQor ew0KKwlzdHJ1Y3QgbmljICpuaWMgPSBuZXRkZXZfcHJpdihuZXRkZXYpOw0K KwlzdHJ1Y3QgbWlpX2lvY3RsX2RhdGEgKm1paSA9IChzdHJ1Y3QgbWlpX2lv Y3RsX2RhdGEgKikmaWZyLT5pZnJfZGF0YTsNCisJcmV0dXJuIGdlbmVyaWNf bWlpX2lvY3RsKCZuaWMtPm1paSwgbWlpLCBjbWQsIE5VTEwpOw0KK30NCisN CitzdGF0aWMgaW50IGUxMDBfYWxsb2Moc3RydWN0IG5pYyAqbmljKQ0KK3sN CisJbmljLT5tZW0gPSBwY2lfYWxsb2NfY29uc2lzdGVudChuaWMtPnBkZXYs IHNpemVvZihzdHJ1Y3QgbWVtKSwNCisJCSZuaWMtPmRtYV9hZGRyKTsNCisJ cmV0dXJuIG5pYy0+bWVtID8gMCA6IC1FTk9NRU07DQorfQ0KKw0KK3N0YXRp YyB2b2lkIGUxMDBfZnJlZShzdHJ1Y3QgbmljICpuaWMpDQorew0KKwlpZihu aWMtPm1lbSkgew0KKwkJcGNpX2ZyZWVfY29uc2lzdGVudChuaWMtPnBkZXYs IHNpemVvZihzdHJ1Y3QgbWVtKSwNCisJCQluaWMtPm1lbSwgbmljLT5kbWFf YWRkcik7DQorCQluaWMtPm1lbSA9IE5VTEw7DQorCX0NCit9DQorDQorc3Rh dGljIGludCBlMTAwX29wZW4oc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldikN Cit7DQorCXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRldl9wcml2KG5ldGRldik7 DQorCWludCBlcnIgPSAwOw0KKw0KKwluZXRpZl9jYXJyaWVyX29mZihuZXRk ZXYpOw0KKwlpZigoZXJyID0gZTEwMF91cChuaWMpKSkNCisJCURQUklOVEso SUZVUCwgRVJSLCAiQ2Fubm90IG9wZW4gaW50ZXJmYWNlLCBhYm9ydGluZy5c biIpOw0KKwlyZXR1cm4gZXJyOw0KK30NCisNCitzdGF0aWMgaW50IGUxMDBf Y2xvc2Uoc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldikNCit7DQorCWUxMDBf ZG93bihuZXRkZXZfcHJpdihuZXRkZXYpKTsNCisJcmV0dXJuIDA7DQorfQ0K Kw0KK3N0YXRpYyBpbnQgX19kZXZpbml0IGUxMDBfcHJvYmUoc3RydWN0IHBj aV9kZXYgKnBkZXYsDQorCWNvbnN0IHN0cnVjdCBwY2lfZGV2aWNlX2lkICpl bnQpDQorew0KKwlzdHJ1Y3QgbmV0X2RldmljZSAqbmV0ZGV2Ow0KKwlzdHJ1 Y3QgbmljICpuaWM7DQorCWludCBlcnI7DQorDQorCWlmKCEobmV0ZGV2ID0g YWxsb2NfZXRoZXJkZXYoc2l6ZW9mKHN0cnVjdCBuaWMpKSkpIHsNCisJCWlm KCgoMSA8PCBkZWJ1ZykgLSAxKSAmIE5FVElGX01TR19QUk9CRSkNCisJCQlw cmludGsoS0VSTl9FUlIgUEZYICJFdGhlcmRldiBhbGxvYyBmYWlsZWQsIGFi b3J0LlxuIik7DQorCQlyZXR1cm4gLUVOT01FTTsNCisJfQ0KKw0KKwluZXRk ZXYtPm9wZW4gPSBlMTAwX29wZW47DQorCW5ldGRldi0+c3RvcCA9IGUxMDBf Y2xvc2U7DQorCW5ldGRldi0+aGFyZF9zdGFydF94bWl0ID0gZTEwMF94bWl0 X2ZyYW1lOw0KKwluZXRkZXYtPmdldF9zdGF0cyA9IGUxMDBfZ2V0X3N0YXRz Ow0KKwluZXRkZXYtPnNldF9tdWx0aWNhc3RfbGlzdCA9IGUxMDBfc2V0X211 bHRpY2FzdF9saXN0Ow0KKwluZXRkZXYtPnNldF9tYWNfYWRkcmVzcyA9IGUx MDBfc2V0X21hY19hZGRyZXNzOw0KKwluZXRkZXYtPmNoYW5nZV9tdHUgPSBl MTAwX2NoYW5nZV9tdHU7DQorCW5ldGRldi0+ZG9faW9jdGwgPSBlMTAwX2Rv X2lvY3RsOw0KKwlTRVRfRVRIVE9PTF9PUFMobmV0ZGV2LCAmZTEwMF9ldGh0 b29sX29wcyk7DQorCW5ldGRldi0+dHhfdGltZW91dCA9IGUxMDBfdHhfdGlt ZW91dDsNCisJbmV0ZGV2LT53YXRjaGRvZ190aW1lbyA9IEUxMDBfV0FUQ0hE T0dfUEVSSU9EOw0KKwluZXRkZXYtPnBvbGwgPSBlMTAwX3BvbGw7DQorCW5l dGRldi0+d2VpZ2h0ID0gRTEwMF9OQVBJX1dFSUdIVDsNCisjaWZkZWYgQ09O RklHX05FVF9QT0xMX0NPTlRST0xMRVINCisJbmV0ZGV2LT5wb2xsX2NvbnRy b2xsZXIgPSBlMTAwX25ldHBvbGw7DQorI2VuZGlmDQorDQorCW5pYyA9IG5l dGRldl9wcml2KG5ldGRldik7DQorCW5pYy0+bmV0ZGV2ID0gbmV0ZGV2Ow0K KwluaWMtPnBkZXYgPSBwZGV2Ow0KKwluaWMtPm1zZ19lbmFibGUgPSAoMSA8 PCBkZWJ1ZykgLSAxOw0KKwlwY2lfc2V0X2RydmRhdGEocGRldiwgbmV0ZGV2 KTsNCisNCisJaWYoKGVyciA9IHBjaV9lbmFibGVfZGV2aWNlKHBkZXYpKSkg ew0KKwkJRFBSSU5USyhQUk9CRSwgRVJSLCAiQ2Fubm90IGVuYWJsZSBQQ0kg ZGV2aWNlLCBhYm9ydGluZy5cbiIpOw0KKwkJZ290byBlcnJfb3V0X2ZyZWVf ZGV2Ow0KKwl9DQorDQorCWlmKCEocGNpX3Jlc291cmNlX2ZsYWdzKHBkZXYs IDApICYgSU9SRVNPVVJDRV9NRU0pKSB7DQorCQlEUFJJTlRLKFBST0JFLCBF UlIsICJDYW5ub3QgZmluZCBwcm9wZXIgUENJIGRldmljZSAiDQorCQkJImJh c2UgYWRkcmVzcywgYWJvcnRpbmcuXG4iKTsNCisJCWVyciA9IC1FTk9ERVY7 DQorCQlnb3RvIGVycl9vdXRfZGlzYWJsZV9wZGV2Ow0KKwl9DQorDQorCWlm KChlcnIgPSBwY2lfcmVxdWVzdF9yZWdpb25zKHBkZXYsIERSVl9OQU1FKSkp IHsNCisJCURQUklOVEsoUFJPQkUsIEVSUiwgIkNhbm5vdCBvYnRhaW4gUENJ IHJlc291cmNlcywgYWJvcnRpbmcuXG4iKTsNCisJCWdvdG8gZXJyX291dF9k aXNhYmxlX3BkZXY7DQorCX0NCisNCisJcGNpX3NldF9tYXN0ZXIocGRldik7 DQorDQorCWlmKChlcnIgPSBwY2lfc2V0X2RtYV9tYXNrKHBkZXYsIDB4RkZG RkZGRkZVTEwpKSkgew0KKwkJRFBSSU5USyhQUk9CRSwgRVJSLCAiTm8gdXNh YmxlIERNQSBjb25maWd1cmF0aW9uLCBhYm9ydGluZy5cbiIpOw0KKwkJZ290 byBlcnJfb3V0X2ZyZWVfcmVzOw0KKwl9DQorDQorCVNFVF9NT0RVTEVfT1dO RVIobmV0ZGV2KTsNCisJU0VUX05FVERFVl9ERVYobmV0ZGV2LCAmcGRldi0+ ZGV2KTsNCisNCisJbmljLT5jc3IgPSBpb3JlbWFwKHBjaV9yZXNvdXJjZV9z dGFydChwZGV2LCAwKSwgc2l6ZW9mKHN0cnVjdCBjc3IpKTsNCisJaWYoIW5p Yy0+Y3NyKSB7DQorCQlEUFJJTlRLKFBST0JFLCBFUlIsICJDYW5ub3QgbWFw IGRldmljZSByZWdpc3RlcnMsIGFib3J0aW5nLlxuIik7DQorCQllcnIgPSAt RU5PTUVNOw0KKwkJZ290byBlcnJfb3V0X2ZyZWVfcmVzOw0KKwl9DQorDQor CWlmKGVudC0+ZHJpdmVyX2RhdGEpDQorCQluaWMtPmZsYWdzIHw9IGljaDsN CisJZWxzZQ0KKwkJbmljLT5mbGFncyAmPSB+aWNoOw0KKw0KKwlzcGluX2xv Y2tfaW5pdCgmbmljLT5jYl9sb2NrKTsNCisJc3Bpbl9sb2NrX2luaXQoJm5p Yy0+Y21kX2xvY2spOw0KKw0KKwlpbml0X3RpbWVyKCZuaWMtPndhdGNoZG9n KTsNCisJbmljLT53YXRjaGRvZy5mdW5jdGlvbiA9IGUxMDBfd2F0Y2hkb2c7 DQorCW5pYy0+d2F0Y2hkb2cuZGF0YSA9ICh1bnNpZ25lZCBsb25nKW5pYzsN CisJaW5pdF90aW1lcigmbmljLT5ibGlua190aW1lcik7DQorCW5pYy0+Ymxp bmtfdGltZXIuZnVuY3Rpb24gPSBlMTAwX2JsaW5rX2xlZDsNCisJbmljLT5i bGlua190aW1lci5kYXRhID0gKHVuc2lnbmVkIGxvbmcpbmljOw0KKw0KKwlp ZigoZXJyID0gZTEwMF9hbGxvYyhuaWMpKSkgew0KKwkJRFBSSU5USyhQUk9C RSwgRVJSLCAiQ2Fubm90IGFsbG9jIGRyaXZlciBtZW1vcnksIGFib3J0aW5n LlxuIik7DQorCQlnb3RvIGVycl9vdXRfaW91bm1hcDsNCisJfQ0KKw0KKwll MTAwX2dldF9kZWZhdWx0cyhuaWMpOw0KKwllMTAwX2h3X3Jlc2V0KG5pYyk7 DQorCWUxMDBfcGh5X2luaXQobmljKTsNCisNCisJaWYoKGVyciA9IGUxMDBf ZWVwcm9tX2xvYWQobmljKSkpDQorCQlnb3RvIGVycl9vdXRfZnJlZTsNCisN CisJbWVtY3B5KG5ldGRldi0+ZGV2X2FkZHIsIG5pYy0+ZWVwcm9tLCBFVEhf QUxFTik7DQorCWlmKCFpc192YWxpZF9ldGhlcl9hZGRyKG5ldGRldi0+ZGV2 X2FkZHIpKSB7DQorCQlEUFJJTlRLKFBST0JFLCBFUlIsICJJbnZhbGlkIE1B QyBhZGRyZXNzIGZyb20gIg0KKwkJCSJFRVBST00sIGFib3J0aW5nLlxuIik7 DQorCQllcnIgPSAtRUFHQUlOOw0KKwkJZ290byBlcnJfb3V0X2ZyZWU7DQor CX0NCisNCisJLyogV29sIG1hZ2ljIHBhY2tldCBjYW4gYmUgZW5hYmxlZCBm cm9tIGVlcHJvbSAqLw0KKwlpZigobmljLT5tYWMgPj0gbWFjXzgyNTU4X0Qx MDFfQTQpICYmDQorCSAgIChuaWMtPmVlcHJvbVtlZXByb21faWRdICYgZWVw cm9tX2lkX3dvbCkpDQorCQluaWMtPmZsYWdzIHw9IHdvbF9tYWdpYzsNCisN CisJcGNpX2VuYWJsZV93YWtlKHBkZXYsIDAsIG5pYy0+ZmxhZ3MgJiAod29s X21hZ2ljIHwgZTEwMF9hc2YobmljKSkpOw0KKw0KKwlpZigoZXJyID0gcmVn aXN0ZXJfbmV0ZGV2KG5ldGRldikpKSB7DQorCQlEUFJJTlRLKFBST0JFLCBF UlIsICJDYW5ub3QgcmVnaXN0ZXIgbmV0IGRldmljZSwgYWJvcnRpbmcuXG4i KTsNCisJCWdvdG8gZXJyX291dF9mcmVlOw0KKwl9DQorDQorCURQUklOVEso UFJPQkUsIElORk8sICJhZGRyIDB4JWx4LCBpcnEgJWQsICINCisJCSJNQUMg YWRkciAlMDJYOiUwMlg6JTAyWDolMDJYOiUwMlg6JTAyWFxuIiwNCisJCXBj aV9yZXNvdXJjZV9zdGFydChwZGV2LCAwKSwgcGRldi0+aXJxLA0KKwkJbmV0 ZGV2LT5kZXZfYWRkclswXSwgbmV0ZGV2LT5kZXZfYWRkclsxXSwgbmV0ZGV2 LT5kZXZfYWRkclsyXSwNCisJCW5ldGRldi0+ZGV2X2FkZHJbM10sIG5ldGRl di0+ZGV2X2FkZHJbNF0sIG5ldGRldi0+ZGV2X2FkZHJbNV0pOw0KKw0KKwly ZXR1cm4gMDsNCisNCitlcnJfb3V0X2ZyZWU6DQorCWUxMDBfZnJlZShuaWMp Ow0KK2Vycl9vdXRfaW91bm1hcDoNCisJaW91bm1hcChuaWMtPmNzcik7DQor ZXJyX291dF9mcmVlX3JlczoNCisJcGNpX3JlbGVhc2VfcmVnaW9ucyhwZGV2 KTsNCitlcnJfb3V0X2Rpc2FibGVfcGRldjoNCisJcGNpX2Rpc2FibGVfZGV2 aWNlKHBkZXYpOw0KK2Vycl9vdXRfZnJlZV9kZXY6DQorCXBjaV9zZXRfZHJ2 ZGF0YShwZGV2LCBOVUxMKTsNCisJZnJlZV9uZXRkZXYobmV0ZGV2KTsNCisJ cmV0dXJuIGVycjsNCit9DQorDQorc3RhdGljIHZvaWQgX19kZXZleGl0IGUx MDBfcmVtb3ZlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KK3sNCisJc3RydWN0 IG5ldF9kZXZpY2UgKm5ldGRldiA9IHBjaV9nZXRfZHJ2ZGF0YShwZGV2KTsN CisNCisJaWYobmV0ZGV2KSB7DQorCQlzdHJ1Y3QgbmljICpuaWMgPSBuZXRk ZXZfcHJpdihuZXRkZXYpOw0KKwkJdW5yZWdpc3Rlcl9uZXRkZXYobmV0ZGV2 KTsNCisJCWUxMDBfZnJlZShuaWMpOw0KKwkJaW91bm1hcChuaWMtPmNzcik7 DQorCQlmcmVlX25ldGRldihuZXRkZXYpOw0KKwkJcGNpX3JlbGVhc2VfcmVn aW9ucyhwZGV2KTsNCisJCXBjaV9kaXNhYmxlX2RldmljZShwZGV2KTsNCisJ CXBjaV9zZXRfZHJ2ZGF0YShwZGV2LCBOVUxMKTsNCisJfQ0KK30NCisNCisj aWZkZWYgQ09ORklHX1BNDQorc3RhdGljIGludCBlMTAwX3N1c3BlbmQoc3Ry dWN0IHBjaV9kZXYgKnBkZXYsIHUzMiBzdGF0ZSkNCit7DQorCXN0cnVjdCBu ZXRfZGV2aWNlICpuZXRkZXYgPSBwY2lfZ2V0X2RydmRhdGEocGRldik7DQor CXN0cnVjdCBuaWMgKm5pYyA9IG5ldGRldl9wcml2KG5ldGRldik7DQorDQor CWlmKG5ldGlmX3J1bm5pbmcobmV0ZGV2KSkNCisJCWUxMDBfZG93bihuaWMp Ow0KKwllMTAwX2h3X3Jlc2V0KG5pYyk7DQorCW5ldGlmX2RldmljZV9kZXRh Y2gobmV0ZGV2KTsNCisNCisJcGNpX3NhdmVfc3RhdGUocGRldiwgbmljLT5w bV9zdGF0ZSk7DQorCXBjaV9lbmFibGVfd2FrZShwZGV2LCBzdGF0ZSwgbmlj LT5mbGFncyAmICh3b2xfbWFnaWMgfCBlMTAwX2FzZihuaWMpKSk7DQorCXBj aV9kaXNhYmxlX2RldmljZShwZGV2KTsNCisJcGNpX3NldF9wb3dlcl9zdGF0 ZShwZGV2LCBzdGF0ZSk7DQorDQorCXJldHVybiAwOw0KK30NCisNCitzdGF0 aWMgaW50IGUxMDBfcmVzdW1lKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KK3sN CisJc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldiA9IHBjaV9nZXRfZHJ2ZGF0 YShwZGV2KTsNCisJc3RydWN0IG5pYyAqbmljID0gbmV0ZGV2X3ByaXYobmV0 ZGV2KTsNCisNCisJcGNpX3NldF9wb3dlcl9zdGF0ZShwZGV2LCAwKTsNCisJ cGNpX3Jlc3RvcmVfc3RhdGUocGRldiwgbmljLT5wbV9zdGF0ZSk7DQorCWUx MDBfaHdfaW5pdChuaWMpOw0KKw0KKwluZXRpZl9kZXZpY2VfYXR0YWNoKG5l dGRldik7DQorCWlmKG5ldGlmX3J1bm5pbmcobmV0ZGV2KSkNCisJCWUxMDBf dXAobmljKTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKyNlbmRpZg0KKw0KK3N0 YXRpYyBzdHJ1Y3QgcGNpX2RyaXZlciBlMTAwX2RyaXZlciA9IHsNCisJLm5h bWUgPSAgICAgICAgIERSVl9OQU1FLA0KKwkuaWRfdGFibGUgPSAgICAgZTEw MF9pZF90YWJsZSwNCisJLnByb2JlID0gICAgICAgIGUxMDBfcHJvYmUsDQor CS5yZW1vdmUgPSAgICAgICBfX2RldmV4aXRfcChlMTAwX3JlbW92ZSksDQor I2lmZGVmIENPTkZJR19QTQ0KKwkuc3VzcGVuZCA9ICAgICAgZTEwMF9zdXNw ZW5kLA0KKwkucmVzdW1lID0gICAgICAgZTEwMF9yZXN1bWUsDQorI2VuZGlm DQorfTsNCisNCitzdGF0aWMgaW50IF9faW5pdCBlMTAwX2luaXRfbW9kdWxl KHZvaWQpDQorew0KKwlpZigoKDEgPDwgZGVidWcpIC0gMSkgJiBORVRJRl9N U0dfRFJWKSB7DQorCQlwcmludGsoS0VSTl9JTkZPIFBGWCAiJXMsICVzXG4i LCBEUlZfREVTQ1JJUFRJT04sIERSVl9WRVJTSU9OKTsNCisJCXByaW50ayhL RVJOX0lORk8gUEZYICIlc1xuIiwgRFJWX0NPUFlSSUdIVCk7DQorCX0NCisg ICAgICAgIHJldHVybiBwY2lfbW9kdWxlX2luaXQoJmUxMDBfZHJpdmVyKTsN Cit9DQorDQorc3RhdGljIHZvaWQgX19leGl0IGUxMDBfY2xlYW51cF9tb2R1 bGUodm9pZCkNCit7DQorCXBjaV91bnJlZ2lzdGVyX2RyaXZlcigmZTEwMF9k cml2ZXIpOw0KK30NCisNCittb2R1bGVfaW5pdChlMTAwX2luaXRfbW9kdWxl KTsNCittb2R1bGVfZXhpdChlMTAwX2NsZWFudXBfbW9kdWxlKTsNCg== ---2037997309-179616242-1091110109=:21929-- From ganesh.venkatesan@intel.com Thu Jul 29 08:45:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:45:59 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFjrIb021220 for ; Thu, 29 Jul 2004 08:45:53 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFl2bw008386; Thu, 29 Jul 2004 15:47:02 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFm0sP032447; Thu, 29 Jul 2004 15:48:28 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908454305929 ; Thu, 29 Jul 2004 08:45:44 -0700 Date: Thu, 29 Jul 2004 08:29:37 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 3/12 2.4] e1000 - use vmalloc for data structures not shared with h/w Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2310 Lines: 70 diff -up linux-2.4/drivers/net/e1000/e1000.h linux-2.4/drivers/net/e1000.new/e1000.h --- linux-2.4/drivers/net/e1000/e1000.h 2004-07-28 08:47:08.172582760 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000.h 2004-07-28 08:47:09.439390176 -0700 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include #include diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -786,7 +786,7 @@ e1000_setup_tx_resources(struct e1000_ad int size; size = sizeof(struct e1000_buffer) * txdr->count; - txdr->buffer_info = kmalloc(size, GFP_KERNEL); + txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { return -ENOMEM; } @@ -799,7 +820,7 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { - kfree(txdr->buffer_info); + vfree(txdr->buffer_info); return -ENOMEM; } memset(txdr->desc, 0, txdr->size); @@ -903,7 +926,7 @@ e1000_setup_rx_resources(struct e1000_ad int size; size = sizeof(struct e1000_buffer) * rxdr->count; - rxdr->buffer_info = kmalloc(size, GFP_KERNEL); + rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { return -ENOMEM; } @@ -917,7 +942,7 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { - kfree(rxdr->buffer_info); + vfree(rxdr->buffer_info); return -ENOMEM; } memset(rxdr->desc, 0, rxdr->size); @@ -1041,7 +1041,7 @@ e1000_free_tx_resources(struct e1000_ada e1000_clean_tx_ring(adapter); - kfree(adapter->tx_ring.buffer_info); + vfree(adapter->tx_ring.buffer_info); adapter->tx_ring.buffer_info = NULL; pci_free_consistent(pdev, adapter->tx_ring.size, @@ -1110,7 +1110,7 @@ e1000_free_rx_resources(struct e1000_ada e1000_clean_rx_ring(adapter); - kfree(rx_ring->buffer_info); + vfree(rx_ring->buffer_info); rx_ring->buffer_info = NULL; pci_free_consistent(pdev, rx_ring->size, rx_ring->desc, rx_ring->dma); From ganesh.venkatesan@intel.com Thu Jul 29 08:46:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:46:13 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFk4SW021441 for ; Thu, 29 Jul 2004 08:46:04 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFlEbw008519; Thu, 29 Jul 2004 15:47:14 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFjnBD021432; Thu, 29 Jul 2004 15:45:49 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908455405970 ; Thu, 29 Jul 2004 08:45:54 -0700 Date: Thu, 29 Jul 2004 08:29:48 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 4/12 2.4] e1000 - TSO fixes (in preparation for IPv6 TSO) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2320 Lines: 59 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -1475,8 +1475,9 @@ e1000_tso(struct e1000_adapter *adapter, #ifdef NETIF_F_TSO struct e1000_context_desc *context_desc; unsigned int i; - uint8_t ipcss, ipcso, tucss, tucso, hdr_len; + uint32_t cmd_length = 0; uint16_t ipcse, tucse, mss; + uint8_t ipcss, ipcso, tucss, tucso, hdr_len; if(skb_shinfo(skb)->tso_size) { hdr_len = ((skb->h.raw - skb->data) + (skb->h.th->doff << 2)); @@ -1495,6 +1496,10 @@ e1000_tso(struct e1000_adapter *adapter, tucso = (void *)&(skb->h.th->check) - (void *)skb->data; tucse = 0; + cmd_length |= (E1000_TXD_CMD_DEXT | E1000_TXD_CMD_TSE | + E1000_TXD_CMD_IP | E1000_TXD_CMD_TCP | + (skb->len - (hdr_len))); + i = adapter->tx_ring.next_to_use; context_desc = E1000_CONTEXT_DESC(adapter->tx_ring, i); @@ -1506,10 +1511,7 @@ e1000_tso(struct e1000_adapter *adapter, context_desc->upper_setup.tcp_fields.tucse = cpu_to_le16(tucse); context_desc->tcp_seg_setup.fields.mss = cpu_to_le16(mss); context_desc->tcp_seg_setup.fields.hdr_len = hdr_len; - context_desc->cmd_and_length = cpu_to_le32( - E1000_TXD_CMD_DEXT | E1000_TXD_CMD_TSE | - E1000_TXD_CMD_IP | E1000_TXD_CMD_TCP | - (skb->len - (hdr_len))); + context_desc->cmd_and_length = cpu_to_le32(cmd_length); if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; @@ -1526,17 +1551,16 @@ e1000_tx_csum(struct e1000_adapter *adap { struct e1000_context_desc *context_desc; unsigned int i; - uint8_t css, cso; + uint8_t css; if(skb->ip_summed == CHECKSUM_HW) { css = skb->h.raw - skb->data; - cso = (skb->h.raw + skb->csum) - skb->data; i = adapter->tx_ring.next_to_use; context_desc = E1000_CONTEXT_DESC(adapter->tx_ring, i); context_desc->upper_setup.tcp_fields.tucss = css; - context_desc->upper_setup.tcp_fields.tucso = cso; + context_desc->upper_setup.tcp_fields.tucso = css + skb->csum; context_desc->upper_setup.tcp_fields.tucse = 0; context_desc->tcp_seg_setup.data = 0; context_desc->cmd_and_length = cpu_to_le32(E1000_TXD_CMD_DEXT); From ganesh.venkatesan@intel.com Thu Jul 29 08:46:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:46:18 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFkAmY021548 for ; Thu, 29 Jul 2004 08:46:10 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFkM1M014403; Thu, 29 Jul 2004 15:46:22 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFmks9000516; Thu, 29 Jul 2004 15:48:46 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908460005991 ; Thu, 29 Jul 2004 08:46:00 -0700 Date: Thu, 29 Jul 2004 08:29:55 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 5/12 2.4] e1000 - avoid infinite loop while trying to re-establish link Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 496 Lines: 16 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -1842,10 +1842,8 @@ e1000_tx_timeout_task(struct net_device { struct e1000_adapter *adapter = netdev->priv; - netif_device_detach(netdev); e1000_down(adapter); e1000_up(adapter); - netif_device_attach(netdev); } /** From ganesh.venkatesan@intel.com Thu Jul 29 08:46:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:46:31 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFkNZ9021750 for ; Thu, 29 Jul 2004 08:46:25 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by fmsfmr004.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFlw40025807; Thu, 29 Jul 2004 15:48:01 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFm0sj032447; Thu, 29 Jul 2004 15:48:55 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908461106013 ; Thu, 29 Jul 2004 08:46:11 -0700 Date: Thu, 29 Jul 2004 08:30:04 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 6/12 2.4] e1000 - include work done in tx-path to decide when to quit polling mode Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 937 Lines: 26 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -2137,15 +2137,18 @@ e1000_clean(struct net_device *netdev, i { struct e1000_adapter *adapter = netdev->priv; int work_to_do = min(*budget, netdev->quota); + int tx_cleaned; int work_done = 0; - e1000_clean_tx_irq(adapter); + tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - if(work_done < work_to_do || !netif_running(netdev)) { + /* if no Rx and Tx cleanup work was done, exit the polling mode */ + if(!tx_cleaned || (work_done < work_to_do) || + !netif_running(netdev)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; From ganesh.venkatesan@intel.com Thu Jul 29 08:46:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:46:44 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFkcwE021958 for ; Thu, 29 Jul 2004 08:46:38 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFm3HE026427; Thu, 29 Jul 2004 15:48:04 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFdoPV032516; Thu, 29 Jul 2004 15:42:03 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908462617218 ; Thu, 29 Jul 2004 08:46:26 -0700 Date: Thu, 29 Jul 2004 08:30:20 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 7/12 2.4] e1000 - null patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 147 Lines: 8 This is a NULL Intel(R) PRO/100 VE Network Connection patch. This helps keep the patch numbering the same between 2.4 and 2.5 trees. ganesh. From ganesh.venkatesan@intel.com Thu Jul 29 08:46:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:47:04 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFkqOQ022222 for ; Thu, 29 Jul 2004 08:46:52 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFl31M014711; Thu, 29 Jul 2004 15:47:03 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFmYEW009523; Thu, 29 Jul 2004 15:48:44 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908463715393 ; Thu, 29 Jul 2004 08:46:37 -0700 Date: Thu, 29 Jul 2004 08:30:31 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 8/12 2.4] e1000 - Shutdown PHY while bringing the interface down (if WoL is off) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1913 Lines: 64 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -256,6 +256,14 @@ e1000_up(struct e1000_adapter *adapter) /* hardware has been reset, we need to reload some things */ + /* Reset the PHY if it was previously powered down */ + if(adapter->hw.media_type == e1000_media_type_copper) { + uint16_t mii_reg; + e1000_read_phy_reg(&adapter->hw, PHY_CTRL, &mii_reg); + if(mii_reg & MII_CR_POWER_DOWN) + e1000_phy_reset(&adapter->hw); + } + e1000_set_multi(netdev); e1000_restore_vlan(adapter); @@ -294,6 +302,15 @@ e1000_down(struct e1000_adapter *adapter e1000_reset(adapter); e1000_clean_tx_ring(adapter); e1000_clean_rx_ring(adapter); + + /* If WoL is not enabled + * Power down the PHY so no link is implied when interface is down */ + if(!adapter->wol && adapter->hw.media_type == e1000_media_type_copper) { + uint16_t mii_reg; + e1000_read_phy_reg(&adapter->hw, PHY_CTRL, &mii_reg); + mii_reg |= MII_CR_POWER_DOWN; + e1000_write_phy_reg(&adapter->hw, PHY_CTRL, mii_reg); + } } void @@ -2544,6 +2521,8 @@ e1000_mii_ioctl(struct net_device *netde switch (data->reg_num) { case PHY_CTRL: if(data->val_in & MII_CR_AUTO_NEG_EN) { + if(mii_reg & MII_CR_POWER_DOWN) + break; adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = 0x2F; } else { @@ -2573,6 +2592,18 @@ e1000_mii_ioctl(struct net_device *netde return -EIO; break; } + } else { + switch (data->reg_num) { + case PHY_CTRL: + if(mii_reg & MII_CR_POWER_DOWN) + break; + if(netif_running(adapter->netdev)) { + e1000_down(adapter); + e1000_up(adapter); + } else + e1000_reset(adapter); + break; + } } break; default: From ganesh.venkatesan@intel.com Thu Jul 29 08:47:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:47:40 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFlVk3022837 for ; Thu, 29 Jul 2004 08:47:32 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFo3TL021934; Thu, 29 Jul 2004 15:50:03 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFnIEW010000; Thu, 29 Jul 2004 15:49:23 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908472215489 ; Thu, 29 Jul 2004 08:47:23 -0700 Date: Thu, 29 Jul 2004 08:31:16 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 11/12 2.4] e1000 - suspend/resume fix from alex@zodiac.dasalias.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 668 Lines: 22 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -2902,6 +2902,8 @@ e1000_suspend(struct pci_dev *pdev, uint } } + pci_disable_device(pdev); + state = (state > 0) ? 3 : 0; pci_set_power_state(pdev, state); @@ -2916,6 +2918,7 @@ e1000_resume(struct pci_dev *pdev) struct e1000_adapter *adapter = netdev->priv; uint32_t manc; + pci_enable_device(pdev); pci_set_power_state(pdev, 0); pci_restore_state(pdev, adapter->pci_state); From ganesh.venkatesan@intel.com Thu Jul 29 08:47:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:47:49 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFlf5T022950 for ; Thu, 29 Jul 2004 08:47:41 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFn8HE027124; Thu, 29 Jul 2004 15:49:08 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFgfOp002826; Thu, 29 Jul 2004 15:43:07 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908473017480 ; Thu, 29 Jul 2004 08:47:30 -0700 Date: Thu, 29 Jul 2004 08:31:24 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 2/12 2.4] e1000 - Enable TSO Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 870 Lines: 27 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -476,7 +476,6 @@ e1000_probe(struct pci_dev *pdev, } #ifdef NETIF_F_TSO -#ifdef BROKEN_ON_NON_IA_ARCHS /* Disbaled for now until root-cause is found for * hangs reported against non-IA archs. TSO can be * enabled using ethtool -K eth tso on */ @@ -484,11 +483,10 @@ e1000_probe(struct pci_dev *pdev, (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; #endif -#endif - if(pci_using_dac) netdev->features |= NETIF_F_HIGHDMA; + adapter->en_mng_pt = e1000_enable_mng_pass_thru(&adapter->hw); /* before reading the EEPROM, reset the controller to From ganesh.venkatesan@intel.com Thu Jul 29 08:47:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:47:33 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFlMqW022637 for ; Thu, 29 Jul 2004 08:47:23 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFmSv3009370; Thu, 29 Jul 2004 15:48:28 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFmsEg009658; Thu, 29 Jul 2004 15:49:12 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908471115466 ; Thu, 29 Jul 2004 08:47:12 -0700 Date: Thu, 29 Jul 2004 08:31:05 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 10/12 2.4] e1000 - more DPRINTK messages to syslog Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2604 Lines: 74 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -347,7 +347,8 @@ e1000_reset(struct e1000_adapter *adapte e1000_reset_hw(&adapter->hw); if(adapter->hw.mac_type >= e1000_82544) E1000_WRITE_REG(&adapter->hw, WUC, 0); - e1000_init_hw(&adapter->hw); + if(e1000_init_hw(&adapter->hw)) + DPRINTK(PROBE, ERR, "Hardware Error\n"); /* Enable h/w to recognize an 802.1Q VLAN Ethernet packet */ E1000_WRITE_REG(&adapter->hw, VET, ETHERNET_IEEE_VLAN_TYPE); @@ -517,10 +517,12 @@ e1000_probe(struct pci_dev *pdev, /* copy the MAC address out of the EEPROM */ - e1000_read_mac_addr(&adapter->hw); + if (e1000_read_mac_addr(&adapter->hw)) + DPRINTK(PROBE, ERR, "EEPROM Read Error\n"); memcpy(netdev->dev_addr, adapter->hw.mac_addr, netdev->addr_len); if(!is_valid_ether_addr(netdev->dev_addr)) { + DPRINTK(PROBE, ERR, "Invalid MAC Address\n"); err = -EIO; goto err_eeprom; } @@ -801,6 +789,8 @@ e1000_setup_tx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * txdr->count; txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Transmit descriptor ring\n"); return -ENOMEM; } memset(txdr->buffer_info, 0, size); @@ -812,6 +802,8 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } @@ -918,6 +906,8 @@ e1000_setup_rx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * rxdr->count; rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Recieve descriptor ring\n"); return -ENOMEM; } memset(rxdr->buffer_info, 0, size); @@ -930,6 +920,8 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } @@ -2796,6 +2807,8 @@ e1000_set_spd_dplx(struct e1000_adapter break; case SPEED_1000 + DUPLEX_HALF: /* not supported */ default: + DPRINTK(PROBE, ERR, + "Unsupported Speed/Duplexity configuration\n"); return -EINVAL; } return 0; From ganesh.venkatesan@intel.com Thu Jul 29 08:47:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:47:15 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFl4Jx022385 for ; Thu, 29 Jul 2004 08:47:04 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFlF1M014803; Thu, 29 Jul 2004 15:47:15 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFnds9001088; Thu, 29 Jul 2004 15:49:39 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908465406113 ; Thu, 29 Jul 2004 08:46:54 -0700 Date: Thu, 29 Jul 2004 08:30:48 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 9/12 2.4] e1000 - Add compiler hints (likely/unlikely), check return codes, related cleanup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 21001 Lines: 628 diff -up linux-2.4/drivers/net/e1000/e1000.h linux-2.4/drivers/net/e1000.new/e1000.h --- linux-2.4/drivers/net/e1000/e1000.h 2004-07-28 08:47:08.172582760 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000.h 2004-07-28 08:47:09.439390176 -0700 @@ -63,6 +63,7 @@ #include #include #include +#include #include #ifdef NETIF_F_TSO #include @@ -79,6 +79,8 @@ #define PCI_DMA_64BIT 0xffffffffffffffffULL #define PCI_DMA_32BIT 0x00000000ffffffffULL +#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)} struct e1000_adapter; @@ -155,9 +158,9 @@ struct e1000_adapter; struct e1000_buffer { struct sk_buff *skb; uint64_t dma; - unsigned long length; unsigned long time_stamp; - unsigned int next_to_watch; + uint16_t length; + uint16_t next_to_watch; }; struct e1000_desc_ring { diff -up linux-2.4/drivers/net/e1000/e1000_hw.c linux-2.4/drivers/net/e1000.new/e1000_hw.c --- linux-2.4/drivers/net/e1000/e1000_hw.c 2004-07-28 08:47:08.174582456 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_hw.c 2004-07-28 08:47:09.499381056 -0700 @@ -251,6 +251,7 @@ e1000_set_mac_type(struct e1000_hw *hw) break; case E1000_DEV_ID_82541ER: case E1000_DEV_ID_82541GI: + case E1000_DEV_ID_82541GI_LF: case E1000_DEV_ID_82541GI_MOBILE: hw->mac_type = e1000_82541_rev_2; break; @@ -920,7 +921,8 @@ e1000_setup_copper_link(struct e1000_hw if(ret_val) return ret_val; - if(hw->mac_type == e1000_82545_rev_3) { + if((hw->mac_type == e1000_82545_rev_3) || + (hw->mac_type == e1000_82546_rev_3)) { ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, &phy_data); phy_data |= 0x00000008; ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data); @@ -3057,16 +3059,6 @@ e1000_init_eeprom_params(struct e1000_hw } break; default: - eeprom->type = e1000_eeprom_spi; - eeprom->opcode_bits = 8; - eeprom->delay_usec = 1; - if (eecd & E1000_EECD_ADDR_BITS) { - eeprom->page_size = 32; - eeprom->address_bits = 16; - } else { - eeprom->page_size = 8; - eeprom->address_bits = 8; - } break; } diff -up linux-2.4/drivers/net/e1000/e1000_hw.h linux-2.4/drivers/net/e1000.new/e1000_hw.h --- linux-2.4/drivers/net/e1000/e1000_hw.h 2004-07-28 08:47:08.176582152 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_hw.h 2004-07-28 08:47:09.531376192 -0700 @@ -357,11 +357,11 @@ int32_t e1000_set_d3_lplu_state(struct e #define E1000_DEV_ID_82547GI 0x1075 #define E1000_DEV_ID_82541GI 0x1076 #define E1000_DEV_ID_82541GI_MOBILE 0x1077 +#define E1000_DEV_ID_82541GI_LF 0x107C #define E1000_DEV_ID_82546GB_COPPER 0x1079 #define E1000_DEV_ID_82546GB_FIBER 0x107A #define E1000_DEV_ID_82546GB_SERDES 0x107B #define E1000_DEV_ID_82547EI 0x1019 - #define NODE_ADDRESS_SIZE 6 #define ETH_LENGTH_OF_ADDRESS 6 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -27,73 +27,69 @@ *******************************************************************************/ #include "e1000.h" -#include /* Change Log + * 5.3.12 6/7/04 + * - kcompat NETIF_MSG for older kernels (2.4.9) + * - if_mii support and associated kcompat for older kernels + * - More errlogging support from Jon Mason + * - Fix TSO issues on PPC64 machines -- Jon Mason * - * 5.2.51 5/14/04 - * o set default configuration to 'NAPI disabled'. NAPI enabled driver - * causes kernel panic when the interface is shutdown while data is being - * transferred. - * 5.2.47 5/04/04 - * o fixed ethtool -t implementation - * 5.2.45 4/29/04 - * o fixed ethtool -e implementation - * o Support for ethtool ops [Stephen Hemminger (shemminger@osdl.org)] - * 5.2.42 4/26/04 - * o Added support for the DPRINTK macro for enhanced error logging. Some - * parts of the patch were supplied by Jon Mason. - * o Move the register_netdevice() donw in the probe routine due to a - * loading/unloading test issue. - * o Added a long RX byte count the the extra ethtool data members for BER - * testing purposes. - * 5.2.39 3/12/04 + * 5.3.11 6/4/04 + * - ethtool register dump reads MANC register conditionally. + * + * 5.3.10 6/1/04 */ char e1000_driver_name[] = "e1000"; char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; -char e1000_driver_version[] = "5.2.52-k3"; +#ifndef CONFIG_E1000_NAPI +#define DRIVERNAPI +#else +#define DRIVERNAPI "-NAPI" +#endif +char e1000_driver_version[] = "5.3.19-k1"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table * - * Wildcard entries (PCI_ANY_ID) should come last * Last entry must be all 0s * - * { Vendor ID, Device ID, SubVendor ID, SubDevice ID, - * Class, Class Mask, private data (not used) } + * Macro expands to... + * {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)} */ static struct pci_device_id e1000_pci_tbl[] = { - {0x8086, 0x1000, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1001, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1004, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1008, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1009, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1010, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1011, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1012, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1013, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1015, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1016, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1017, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1018, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1019, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x101D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x101E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1026, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1027, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1028, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1075, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1076, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1077, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1078, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1079, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x107A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x107B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + INTEL_E1000_ETHERNET_DEVICE(0x1000), + INTEL_E1000_ETHERNET_DEVICE(0x1001), + INTEL_E1000_ETHERNET_DEVICE(0x1004), + INTEL_E1000_ETHERNET_DEVICE(0x1008), + INTEL_E1000_ETHERNET_DEVICE(0x1009), + INTEL_E1000_ETHERNET_DEVICE(0x100C), + INTEL_E1000_ETHERNET_DEVICE(0x100D), + INTEL_E1000_ETHERNET_DEVICE(0x100E), + INTEL_E1000_ETHERNET_DEVICE(0x100F), + INTEL_E1000_ETHERNET_DEVICE(0x1010), + INTEL_E1000_ETHERNET_DEVICE(0x1011), + INTEL_E1000_ETHERNET_DEVICE(0x1012), + INTEL_E1000_ETHERNET_DEVICE(0x1013), + INTEL_E1000_ETHERNET_DEVICE(0x1015), + INTEL_E1000_ETHERNET_DEVICE(0x1016), + INTEL_E1000_ETHERNET_DEVICE(0x1017), + INTEL_E1000_ETHERNET_DEVICE(0x1018), + INTEL_E1000_ETHERNET_DEVICE(0x1019), + INTEL_E1000_ETHERNET_DEVICE(0x101D), + INTEL_E1000_ETHERNET_DEVICE(0x101E), + INTEL_E1000_ETHERNET_DEVICE(0x1026), + INTEL_E1000_ETHERNET_DEVICE(0x1027), + INTEL_E1000_ETHERNET_DEVICE(0x1028), + INTEL_E1000_ETHERNET_DEVICE(0x1075), + INTEL_E1000_ETHERNET_DEVICE(0x1076), + INTEL_E1000_ETHERNET_DEVICE(0x1077), + INTEL_E1000_ETHERNET_DEVICE(0x1078), + INTEL_E1000_ETHERNET_DEVICE(0x1079), + INTEL_E1000_ETHERNET_DEVICE(0x107A), + INTEL_E1000_ETHERNET_DEVICE(0x107B), + INTEL_E1000_ETHERNET_DEVICE(0x107C), /* required last entry */ {0,} }; @@ -202,7 +198,7 @@ MODULE_AUTHOR("Intel Corporation, mac_type == e1000_82541) || - (hw->mac_type == e1000_82547) || - (hw->mac_type == e1000_82541_rev_2) || - (hw->mac_type == e1000_82547_rev_2)) + switch(hw->mac_type) { + default: + break; + case e1000_82541: + case e1000_82547: + case e1000_82541_rev_2: + case e1000_82547_rev_2: hw->phy_init_script = 1; + break; + } e1000_set_media_type(hw); - if(hw->mac_type < e1000_82543) - hw->report_tx_early = 0; - else - hw->report_tx_early = 1; - hw->wait_autoneg_complete = FALSE; hw->tbi_compatibility_en = TRUE; hw->adaptive_ifs = TRUE; @@ -751,7 +747,7 @@ e1000_open(struct net_device *netdev) if((err = e1000_up(adapter))) goto err_up; - return 0; + return E1000_SUCCESS; err_up: e1000_free_rx_resources(adapter); @@ -893,10 +889,10 @@ e1000_configure_tx(struct e1000_adapter adapter->txd_cmd = E1000_TXD_CMD_IDE | E1000_TXD_CMD_EOP | E1000_TXD_CMD_IFCS; - if(adapter->hw.report_tx_early == 1) - adapter->txd_cmd |= E1000_TXD_CMD_RS; - else + if(adapter->hw.mac_type < e1000_82543) adapter->txd_cmd |= E1000_TXD_CMD_RPS; + else + adapter->txd_cmd |= E1000_TXD_CMD_RS; /* Cache if we're 82544 running in PCI-X because we'll * need this to apply a workaround later in the send path. */ @@ -1547,7 +1538,7 @@ e1000_tx_csum(struct e1000_adapter *adap unsigned int i; uint8_t css; - if(skb->ip_summed == CHECKSUM_HW) { + if(likely(skb->ip_summed == CHECKSUM_HW)) { css = skb->h.raw - skb->data; i = adapter->tx_ring.next_to_use; @@ -1559,7 +1538,7 @@ context_desc->tcp_seg_setup.data = 0; context_desc->cmd_and_length = cpu_to_le32(E1000_TXD_CMD_DEXT); - if(++i == adapter->tx_ring.count) i = 0; + if(unlikely(++i == adapter->tx_ring.count)) i = 0; adapter->tx_ring.next_to_use = i; return TRUE; @@ -1592,14 +1585,14 @@ e1000_tx_map(struct e1000_adapter *adapt #ifdef NETIF_F_TSO /* Workaround for premature desc write-backs * in TSO mode. Append 4-byte sentinel desc */ - if(mss && !nr_frags && size == len && size > 8) + if(unlikely(mss && !nr_frags && size == len && size > 8)) size -= 4; #endif /* Workaround for potential 82544 hang in PCI-X. Avoid * terminating buffers within evenly-aligned dwords. */ - if(adapter->pcix_82544 && + if(unlikely(adapter->pcix_82544 && !((unsigned long)(skb->data + offset + size - 1) & 4) && - size > 4) + size > 4)) size -= 4; buffer_info->length = size; @@ -1613,7 +1606,7 @@ e1000_tx_map(struct e1000_adapter *adapt len -= size; offset += size; count++; - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } for(f = 0; f < nr_frags; f++) { @@ -1629,15 +1622,15 @@ e1000_tx_map(struct e1000_adapter *adapt #ifdef NETIF_F_TSO /* Workaround for premature desc write-backs * in TSO mode. Append 4-byte sentinel desc */ - if(mss && f == (nr_frags-1) && size == len && size > 8) + if(unlikely(mss && f == (nr_frags-1) && size == len && size > 8)) size -= 4; #endif /* Workaround for potential 82544 hang in PCI-X. * Avoid terminating buffers within evenly-aligned * dwords. */ - if(adapter->pcix_82544 && + if(unlikely(adapter->pcix_82544 && !((unsigned long)(frag->page+offset+size-1) & 4) && - size > 4) + size > 4)) size -= 4; buffer_info->length = size; @@ -1652,7 +1645,7 @@ e1000_tx_map(struct e1000_adapter *adapt len -= size; offset += size; count++; - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } } i = (i == 0) ? tx_ring->count - 1 : i - 1; @@ -1671,18 +1667,18 @@ e1000_tx_queue(struct e1000_adapter *ada uint32_t txd_upper = 0, txd_lower = E1000_TXD_CMD_IFCS; unsigned int i; - if(tx_flags & E1000_TX_FLAGS_TSO) { + if(likely(tx_flags & E1000_TX_FLAGS_TSO)) { txd_lower |= E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D | E1000_TXD_CMD_TSE; txd_upper |= (E1000_TXD_POPTS_IXSM | E1000_TXD_POPTS_TXSM) << 8; } - if(tx_flags & E1000_TX_FLAGS_CSUM) { + if(likely(tx_flags & E1000_TX_FLAGS_CSUM)) { txd_lower |= E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D; txd_upper |= E1000_TXD_POPTS_TXSM << 8; } - if(tx_flags & E1000_TX_FLAGS_VLAN) { + if(unlikely(tx_flags & E1000_TX_FLAGS_VLAN)) { txd_lower |= E1000_TXD_CMD_VLE; txd_upper |= (tx_flags & E1000_TX_FLAGS_VLAN_MASK); } @@ -1696,7 +1692,7 @@ e1000_tx_queue(struct e1000_adapter *ada tx_desc->lower.data = cpu_to_le32(txd_lower | buffer_info->length); tx_desc->upper.data = cpu_to_le32(txd_upper); - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } tx_desc->lower.data |= cpu_to_le32(adapter->txd_cmd); @@ -1765,7 +1751,8 @@ e1000_xmit_frame(struct sk_buff *skb, st unsigned int f; nr_frags = skb_shinfo(skb)->nr_frags; len -= skb->data_len; - if(skb->len <= 0) { + + if(unlikely(skb->len <= 0)) { dev_kfree_skb_any(skb); return 0; } @@ -1811,8 +1776,8 @@ e1000_xmit_frame(struct sk_buff *skb, st } spin_unlock_irqrestore(&adapter->tx_lock, flags); - if(adapter->hw.mac_type == e1000_82547) { - if(e1000_82547_fifo_workaround(adapter, skb)) { + if(unlikely(adapter->hw.mac_type == e1000_82547)) { + if(unlikely(e1000_82547_fifo_workaround(adapter, skb))) { netif_stop_queue(netdev); mod_timer(&adapter->tx_fifo_stall_timer, jiffies); return 1; @@ -1819,7 +1776,7 @@ } } - if(adapter->vlgrp && vlan_tx_tag_present(skb)) { + if(unlikely(adapter->vlgrp && vlan_tx_tag_present(skb))) { tx_flags |= E1000_TX_FLAGS_VLAN; tx_flags |= (vlan_tx_tag_get(skb) << E1000_TX_FLAGS_VLAN_SHIFT); } @@ -1826,9 +1776,9 @@ first = adapter->tx_ring.next_to_use; - if(e1000_tso(adapter, skb)) + if(likely(e1000_tso(adapter, skb))) tx_flags |= E1000_TX_FLAGS_TSO; - else if(e1000_tx_csum(adapter, skb)) + else if(likely(e1000_tx_csum(adapter, skb))) tx_flags |= E1000_TX_FLAGS_CSUM; e1000_tx_queue(adapter, @@ -2090,7 +2087,7 @@ e1000_irq_disable(struct e1000_adapter * static inline void e1000_irq_enable(struct e1000_adapter *adapter) { - if(atomic_dec_and_test(&adapter->irq_sem)) { + if(likely(atomic_dec_and_test(&adapter->irq_sem))) { E1000_WRITE_REG(&adapter->hw, IMS, IMS_ENABLE_MASK); E1000_WRITE_FLUSH(&adapter->hw); } @@ -2109,21 +2106,21 @@ e1000_intr(int irq, void *data, struct p struct net_device *netdev = data; struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; - uint32_t icr = E1000_READ_REG(&adapter->hw, ICR); + uint32_t icr = E1000_READ_REG(hw, ICR); #ifndef CONFIG_E1000_NAPI unsigned int i; #endif - if(!icr) + if(unlikely(!icr)) return IRQ_NONE; /* Not our interrupt */ - if(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { + if(unlikely(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))) { hw->get_link_status = 1; mod_timer(&adapter->watchdog_timer, jiffies); } #ifdef CONFIG_E1000_NAPI - if(netif_rx_schedule_prep(netdev)) { + if(likely(netif_rx_schedule_prep(netdev))) { /* Disable interrupts and register for poll. The flush of the posted write is intentionally left out. @@ -2135,8 +2132,8 @@ e1000_intr(int irq, void *data, struct p } #else for(i = 0; i < E1000_MAX_INTR; i++) - if(!e1000_clean_rx_irq(adapter) & - !e1000_clean_tx_irq(adapter)) + if(unlikely(!e1000_clean_rx_irq(adapter) & + !e1000_clean_tx_irq(adapter))) break; #endif @@ -2202,8 +2184,8 @@ e1000_clean_tx_irq(struct e1000_adapter tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; - if(buffer_info->dma) { + if(likely(buffer_info->dma)) { pci_unmap_page(pdev, buffer_info->dma, buffer_info->length, @@ -2224,7 +2221,7 @@ e1000_clean_tx_irq(struct e1000_adapter tx_desc->upper.data = 0; cleaned = (i == eop); - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } eop = tx_ring->buffer_info[i].next_to_watch; @@ -2235,7 +2232,8 @@ e1000_clean_tx_irq(struct e1000_adapter spin_lock(&adapter->tx_lock); - if(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev)) + if(unlikely(cleaned && netif_queue_stopped(netdev) && + netif_carrier_ok(netdev))) netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); @@ -2291,25 +2276,21 @@ e1000_clean_rx_irq(struct e1000_adapter skb = buffer_info->skb; length = le16_to_cpu(rx_desc->length); - if(!(rx_desc->status & E1000_RXD_STAT_EOP)) { + if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) { /* All receives must fit into a single buffer */ - E1000_DBG("%s: Receive packet consumed multiple buffers\n", - netdev->name); + E1000_DBG("%s: Receive packet consumed multiple" + " buffers\n", netdev->name); dev_kfree_skb_irq(skb); - rx_desc->status = 0; - buffer_info->skb = NULL; - if(++i == rx_ring->count) i = 0; - rx_desc = E1000_RX_DESC(*rx_ring, i); - continue; + goto next_desc; } - if(rx_desc->errors & E1000_RXD_ERR_FRAME_ERR_MASK) { + if(unlikely(rx_desc->errors & E1000_RXD_ERR_FRAME_ERR_MASK)) { last_byte = *(skb->data + length - 1); if(TBI_ACCEPT(&adapter->hw, rx_desc->status, @@ -2327,13 +2276,9 @@ } else { dev_kfree_skb_irq(skb); - rx_desc->status = 0; - buffer_info->skb = NULL; - if(++i == rx_ring->count) i = 0; - rx_desc = E1000_RX_DESC(*rx_ring, i); - continue; + goto next_desc; } } @@ -2345,7 +2317,8 @@ e1000_clean_rx_irq(struct e1000_adapter skb->protocol = eth_type_trans(skb, netdev); #ifdef CONFIG_E1000_NAPI - if(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP)) { + if(unlikely(adapter->vlgrp && + (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_receive_skb(skb, adapter->vlgrp, le16_to_cpu(rx_desc->special & E1000_RXD_SPC_VLAN_MASK)); @@ -2353,7 +2317,8 @@ netif_receive_skb(skb); } #else /* CONFIG_E1000_NAPI */ - if(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP)) { + if(unlikely(adapter->vlgrp && + (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_rx(skb, adapter->vlgrp, le16_to_cpu(rx_desc->special & E1000_RXD_SPC_VLAN_MASK)); @@ -2363,10 +2335,10 @@ e1000_clean_rx_irq(struct e1000_adapter #endif /* CONFIG_E1000_NAPI */ netdev->last_rx = jiffies; +next_desc: rx_desc->status = 0; buffer_info->skb = NULL; - - if(++i == rx_ring->count) i = 0; + if(unlikely(++i == rx_ring->count)) i = 0; rx_desc = E1000_RX_DESC(*rx_ring, i); } @@ -2399,8 +2371,6 @@ e1000_alloc_rx_buffers(struct e1000_adap buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { - rx_desc = E1000_RX_DESC(*rx_ring, i); - skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len); if(!skb) { @@ -2424,9 +2390,10 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); - if((i & ~(E1000_RX_BUFFER_WRITE - 1)) == i) { + if(unlikely((i & ~(E1000_RX_BUFFER_WRITE - 1)) == i)) { /* Force memory writes to complete before letting h/w * know there are new descriptors to fetch. (Only * applicable for weak-ordered memory model archs, @@ -2436,7 +2427,7 @@ e1000_alloc_rx_buffers(struct e1000_adap E1000_WRITE_REG(&adapter->hw, RDT, i); } - if(++i == rx_ring->count) i = 0; + if(unlikely(++i == rx_ring->count)) i = 0; buffer_info = &rx_ring->buffer_info[i]; } @@ -2625,11 +2616,11 @@ e1000_rx_checksum(struct e1000_adapter * struct sk_buff *skb) { /* 82543 or newer only */ - if((adapter->hw.mac_type < e1000_82543) || + if(unlikely((adapter->hw.mac_type < e1000_82543) || /* Ignore Checksum bit is set */ (rx_desc->status & E1000_RXD_STAT_IXSM) || /* TCP Checksum has not been calculated */ - (!(rx_desc->status & E1000_RXD_STAT_TCPCS))) { + (!(rx_desc->status & E1000_RXD_STAT_TCPCS)))) { skb->ip_summed = CHECKSUM_NONE; return; } @@ -2652,7 +2643,8 @@ e1000_pci_set_mwi(struct e1000_hw *hw) { struct e1000_adapter *adapter = hw->back; - pci_set_mwi(adapter->pdev); + int ret; + ret = pci_set_mwi(adapter->pdev); } void From ganesh.venkatesan@intel.com Thu Jul 29 08:47:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:03 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFlsuS023183 for ; Thu, 29 Jul 2004 08:47:55 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFn1v3009666; Thu, 29 Jul 2004 15:49:02 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFneEU010368; Thu, 29 Jul 2004 15:49:45 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908473812539 ; Thu, 29 Jul 2004 08:47:38 -0700 Date: Thu, 29 Jul 2004 08:31:32 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 1/12 2.5] e1000 - ethtool support (register dump, interrupt test, cleanup) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 10974 Lines: 351 diff -up linux-2.5/drivers/net/e1000/e1000_ethtool.c linux-2.5/drivers/net/e1000.new/e1000_ethtool.c --- linux-2.5/drivers/net/e1000/e1000_ethtool.c 2004-07-28 21:50:08.576475768 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_ethtool.c 2004-07-28 21:50:09.395351280 -0700 @@ -88,9 +88,9 @@ static const struct e1000_stats e1000_gs { "rx_flow_control_xoff", E1000_STAT(stats.xoffrxc) }, { "tx_flow_control_xon", E1000_STAT(stats.xontxc) }, { "tx_flow_control_xoff", E1000_STAT(stats.xofftxc) }, + { "rx_long_byte_count", E1000_STAT(stats.gorcl) }, { "rx_csum_offload_good", E1000_STAT(hw_csum_good) }, - { "rx_csum_offload_errors", E1000_STAT(hw_csum_err) }, - { "rx_long_byte_count", E1000_STAT(stats.gorcl) } + { "rx_csum_offload_errors", E1000_STAT(hw_csum_err) } }; #define E1000_STATS_LEN \ sizeof(e1000_gstrings_stats) / sizeof(struct e1000_stats) @@ -170,7 +170,8 @@ e1000_get_settings(struct net_device *ne ecmd->duplex = -1; } - ecmd->autoneg = (hw->autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE); + ecmd->autoneg = ((hw->media_type == e1000_media_type_fiber) || + hw->autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE; return 0; } @@ -192,6 +193,7 @@ e1000_set_settings(struct net_device *ne if(netif_running(adapter->netdev)) { e1000_down(adapter); + e1000_reset(adapter); e1000_up(adapter); } else e1000_reset(adapter); @@ -199,12 +201,13 @@ e1000_set_settings(struct net_device *ne return 0; } -static void +static void e1000_get_pauseparam(struct net_device *netdev, - struct ethtool_pauseparam *pause) + struct ethtool_pauseparam *pause) { struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; + pause->autoneg = (adapter->fc_autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE); @@ -218,9 +221,9 @@ e1000_get_pauseparam(struct net_device * } } -static int +static int e1000_set_pauseparam(struct net_device *netdev, - struct ethtool_pauseparam *pause) + struct ethtool_pauseparam *pause) { struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; @@ -271,7 +274,7 @@ e1000_set_rx_csum(struct net_device *net e1000_reset(adapter); return 0; } - + static uint32_t e1000_get_tx_csum(struct net_device *netdev) { @@ -337,7 +340,7 @@ e1000_get_regs_len(struct net_device *ne static void e1000_get_regs(struct net_device *netdev, - struct ethtool_regs *regs, void *p) + struct ethtool_regs *regs, void *p) { struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; @@ -418,6 +421,10 @@ e1000_get_regs(struct net_device *netdev e1000_read_phy_reg(hw, PHY_1000T_STATUS, &phy_data); regs_buff[24] = (uint32_t)phy_data; /* phy local receiver status */ regs_buff[25] = regs_buff[24]; /* phy remote receiver status */ + if(hw->mac_type >= e1000_82540 && + hw->media_type == e1000_media_type_copper) { + regs_buff[26] = E1000_READ_REG(hw, MANC); + } } static int @@ -438,7 +445,7 @@ e1000_get_eeprom(struct net_device *netd int ret_val = 0; uint16_t i; - if(eeprom->len == 0) + if(eeprom->len == 0) return -EINVAL; eeprom->magic = hw->vendor_id | (hw->device_id << 16); @@ -446,9 +453,9 @@ e1000_get_eeprom(struct net_device *netd first_word = eeprom->offset >> 1; last_word = (eeprom->offset + eeprom->len - 1) >> 1; - eeprom_buff = kmalloc(sizeof(uint16_t) * + eeprom_buff = kmalloc(sizeof(uint16_t) * (last_word - first_word + 1), GFP_KERNEL); - if (!eeprom_buff) + if(!eeprom_buff) return -ENOMEM; if(hw->eeprom.type == e1000_eeprom_spi) @@ -466,9 +473,8 @@ e1000_get_eeprom(struct net_device *netd for (i = 0; i < last_word - first_word + 1; i++) le16_to_cpus(&eeprom_buff[i]); - - memcpy(bytes, (uint8_t *)eeprom_buff + (eeprom->offset%2), - eeprom->len); + memcpy(bytes, (uint8_t *)eeprom_buff + (eeprom->offset & 1), + eeprom->len); kfree(eeprom_buff); return ret_val; @@ -520,6 +526,7 @@ e1000_set_eeprom(struct net_device *netd le16_to_cpus(&eeprom_buff[i]); memcpy(ptr, bytes, eeprom->len); + for (i = 0; i < last_word - first_word + 1; i++) eeprom_buff[i] = cpu_to_le16(eeprom_buff[i]); @@ -575,17 +582,16 @@ static int e1000_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { - int err; struct e1000_adapter *adapter = netdev->priv; e1000_mac_type mac_type = adapter->hw.mac_type; struct e1000_desc_ring *txdr = &adapter->tx_ring; struct e1000_desc_ring *rxdr = &adapter->rx_ring; - struct e1000_desc_ring tx_old, tx_new; - struct e1000_desc_ring rx_old, rx_new; + struct e1000_desc_ring tx_old, tx_new, rx_old, rx_new; + int err; tx_old = adapter->tx_ring; rx_old = adapter->rx_ring; - + if(netif_running(adapter->netdev)) e1000_down(adapter); @@ -600,15 +606,15 @@ e1000_set_ringparam(struct net_device *n E1000_ROUNDUP(txdr->count, REQ_TX_DESCRIPTOR_MULTIPLE); if(netif_running(adapter->netdev)) { - /* try to get new resources before deleting old */ + /* Try to get new resources before deleting old */ if((err = e1000_setup_rx_resources(adapter))) goto err_setup_rx; if((err = e1000_setup_tx_resources(adapter))) goto err_setup_tx; /* save the new, restore the old in order to free it, - * then restore the new back again */ - + * then restore the new back again */ + rx_new = adapter->rx_ring; tx_new = adapter->tx_ring; adapter->rx_ring = rx_old; @@ -620,6 +626,7 @@ e1000_set_ringparam(struct net_device *n if((err = e1000_up(adapter))) return err; } + return 0; err_setup_tx: e1000_free_rx_resources(adapter); @@ -766,13 +773,15 @@ static int e1000_intr_test(struct e1000_adapter *adapter, uint64_t *data) { struct net_device *netdev = adapter->netdev; - uint32_t icr, mask, i=0; + uint32_t icr, mask, i=0, shared_int = TRUE; + uint32_t irq = adapter->pdev->irq; *data = 0; /* Hook up test interrupt handler just for this test */ - if(request_irq(adapter->pdev->irq, &e1000_test_intr, SA_SHIRQ, - netdev->name, netdev)) { + if(!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) { + shared_int = FALSE; + } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, netdev->name, netdev)){ *data = 1; return -1; } @@ -802,20 +811,22 @@ e1000_intr_test(struct e1000_adapter *ad /* Interrupt to test */ mask = 1 << i; - /* Disable the interrupt to be reported in - * the cause register and then force the same - * interrupt and see if one gets posted. If - * an interrupt was posted to the bus, the - * test failed. - */ - adapter->test_icr = 0; - E1000_WRITE_REG(&adapter->hw, IMC, mask); - E1000_WRITE_REG(&adapter->hw, ICS, mask); - msec_delay(10); - - if(adapter->test_icr & mask) { - *data = 3; - break; + if(!shared_int) { + /* Disable the interrupt to be reported in + * the cause register and then force the same + * interrupt and see if one gets posted. If + * an interrupt was posted to the bus, the + * test failed. + */ + adapter->test_icr = 0; + E1000_WRITE_REG(&adapter->hw, IMC, mask); + E1000_WRITE_REG(&adapter->hw, ICS, mask); + msec_delay(10); + + if(adapter->test_icr & mask) { + *data = 3; + break; + } } /* Enable the interrupt to be reported in @@ -834,20 +845,22 @@ e1000_intr_test(struct e1000_adapter *ad break; } - /* Disable the other interrupts to be reported in - * the cause register and then force the other - * interrupts and see if any get posted. If - * an interrupt was posted to the bus, the - * test failed. - */ - adapter->test_icr = 0; - E1000_WRITE_REG(&adapter->hw, IMC, ~mask); - E1000_WRITE_REG(&adapter->hw, ICS, ~mask); - msec_delay(10); + if(!shared_int) { + /* Disable the other interrupts to be reported in + * the cause register and then force the other + * interrupts and see if any get posted. If + * an interrupt was posted to the bus, the + * test failed. + */ + adapter->test_icr = 0; + E1000_WRITE_REG(&adapter->hw, IMC, ~mask); + E1000_WRITE_REG(&adapter->hw, ICS, ~mask); + msec_delay(10); - if(adapter->test_icr) { - *data = 5; - break; + if(adapter->test_icr) { + *data = 5; + break; + } } } @@ -856,7 +869,7 @@ e1000_intr_test(struct e1000_adapter *ad msec_delay(10); /* Unhook test interrupt handler */ - free_irq(adapter->pdev->irq, netdev); + free_irq(irq, netdev); return *data; } @@ -1021,7 +1034,7 @@ e1000_setup_desc_rings(struct e1000_adap return 0; - err_nomem: +err_nomem: e1000_free_desc_rings(adapter); return ret_val; } @@ -1357,7 +1370,7 @@ e1000_diag_test_count(struct net_device } static void -e1000_diag_test(struct net_device *netdev, +e1000_diag_test(struct net_device *netdev, struct ethtool_test *eth_test, uint64_t *data) { struct e1000_adapter *adapter = netdev->priv; @@ -1368,7 +1381,7 @@ e1000_diag_test(struct net_device *netde /* save speed, duplex, autoneg settings */ uint16_t autoneg_advertised = adapter->hw.autoneg_advertised; - uint8_t forced_speed_duplex = adapter->hw.forced_speed_duplex; + uint8_t forced_speed_duplex = adapter->hw.forced_speed_duplex; uint8_t autoneg = adapter->hw.autoneg; /* Link test performed before hardware reset so autoneg doesn't @@ -1396,10 +1409,11 @@ e1000_diag_test(struct net_device *netde if(e1000_loopback_test(adapter, &data[3])) eth_test->flags |= ETH_TEST_FL_FAILED; - /* restore Autoneg/speed/duplex settings */ + /* restore speed, duplex, autoneg settings */ adapter->hw.autoneg_advertised = autoneg_advertised; - adapter->hw.forced_speed_duplex = forced_speed_duplex; - adapter->hw.autoneg = autoneg; + adapter->hw.forced_speed_duplex = forced_speed_duplex; + adapter->hw.autoneg = autoneg; + e1000_reset(adapter); if(if_running) e1000_up(adapter); @@ -1427,6 +1441,7 @@ e1000_get_wol(struct net_device *netdev, case E1000_DEV_ID_82543GC_FIBER: case E1000_DEV_ID_82543GC_COPPER: case E1000_DEV_ID_82544EI_FIBER: + case E1000_DEV_ID_82546EB_QUAD_COPPER: wol->supported = 0; wol->wolopts = 0; return; @@ -1469,6 +1484,7 @@ e1000_set_wol(struct net_device *netdev, case E1000_DEV_ID_82543GC_FIBER: case E1000_DEV_ID_82543GC_COPPER: case E1000_DEV_ID_82544EI_FIBER: + case E1000_DEV_ID_82546EB_QUAD_COPPER: return wol->wolopts ? -EOPNOTSUPP : 0; case E1000_DEV_ID_82546EB_FIBER: @@ -1571,8 +1587,8 @@ e1000_get_ethtool_stats(struct net_devic e1000_update_stats(adapter); for(i = 0; i < E1000_STATS_LEN; i++) { char *p = (char *)adapter+e1000_gstrings_stats[i].stat_offset; - data[i] = (e1000_gstrings_stats[i].sizeof_stat == sizeof(uint64_t)) - ? *(uint64_t *)p : *(uint32_t *)p; + data[i] = (e1000_gstrings_stats[i].sizeof_stat == + sizeof(uint64_t)) ? *(uint64_t *)p : *(uint32_t *)p; } } From ganesh.venkatesan@intel.com Thu Jul 29 08:48:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:22 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFm9p9023489 for ; Thu, 29 Jul 2004 08:48:09 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFofTL022299; Thu, 29 Jul 2004 15:50:41 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFnsEW010625; Thu, 29 Jul 2004 15:50:01 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908480012622 ; Thu, 29 Jul 2004 08:48:00 -0700 Date: Thu, 29 Jul 2004 08:31:54 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 3/12 2.5] e1000 - Use vmalloc for data structures not shared with hardware Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2310 Lines: 70 diff -up linux-2.5/drivers/net/e1000/e1000.h linux-2.5/drivers/net/e1000.new/e1000.h --- linux-2.5/drivers/net/e1000/e1000.h 2004-07-28 21:50:08.578475464 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000.h 2004-07-28 21:50:09.401350368 -0700 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include #include diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -786,7 +786,7 @@ e1000_setup_tx_resources(struct e1000_ad int size; size = sizeof(struct e1000_buffer) * txdr->count; - txdr->buffer_info = kmalloc(size, GFP_KERNEL); + txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { return -ENOMEM; } @@ -799,7 +820,7 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { - kfree(txdr->buffer_info); + vfree(txdr->buffer_info); return -ENOMEM; } memset(txdr->desc, 0, txdr->size); @@ -903,7 +926,7 @@ e1000_setup_rx_resources(struct e1000_ad int size; size = sizeof(struct e1000_buffer) * rxdr->count; - rxdr->buffer_info = kmalloc(size, GFP_KERNEL); + rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { return -ENOMEM; } @@ -917,7 +942,7 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { - kfree(rxdr->buffer_info); + vfree(rxdr->buffer_info); return -ENOMEM; } memset(rxdr->desc, 0, rxdr->size); @@ -1041,7 +1041,7 @@ e1000_free_tx_resources(struct e1000_ada e1000_clean_tx_ring(adapter); - kfree(adapter->tx_ring.buffer_info); + vfree(adapter->tx_ring.buffer_info); adapter->tx_ring.buffer_info = NULL; pci_free_consistent(pdev, adapter->tx_ring.size, @@ -1110,7 +1110,7 @@ e1000_free_rx_resources(struct e1000_ada e1000_clean_rx_ring(adapter); - kfree(rx_ring->buffer_info); + vfree(rx_ring->buffer_info); rx_ring->buffer_info = NULL; pci_free_consistent(pdev, rx_ring->size, rx_ring->desc, rx_ring->dma); From ganesh.venkatesan@intel.com Thu Jul 29 08:48:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:22 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFmAUa023510 for ; Thu, 29 Jul 2004 08:48:10 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFn8v3009722; Thu, 29 Jul 2004 15:49:18 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFndEW010354; Thu, 29 Jul 2004 15:49:53 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908474712570 ; Thu, 29 Jul 2004 08:47:47 -0700 Date: Thu, 29 Jul 2004 08:31:41 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 2/12 2.5] e1000 - Enable TSO Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 869 Lines: 26 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -476,7 +476,6 @@ e1000_probe(struct pci_dev *pdev, } #ifdef NETIF_F_TSO -#ifdef BROKEN_ON_NON_IA_ARCHS /* Disbaled for now until root-cause is found for * hangs reported against non-IA archs. TSO can be * enabled using ethtool -K eth tso on */ @@ -484,11 +483,10 @@ e1000_probe(struct pci_dev *pdev, (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; #endif -#endif - if(pci_using_dac) netdev->features |= NETIF_F_HIGHDMA; + adapter->en_mng_pt = e1000_enable_mng_pass_thru(&adapter->hw); /* before reading the EEPROM, reset the controller to From ganesh.venkatesan@intel.com Thu Jul 29 08:48:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:32 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFmNPA023698 for ; Thu, 29 Jul 2004 08:48:24 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFnmHE027676; Thu, 29 Jul 2004 15:49:49 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFgfP5002810; Thu, 29 Jul 2004 15:43:45 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908480717609 ; Thu, 29 Jul 2004 08:48:07 -0700 Date: Thu, 29 Jul 2004 08:32:01 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 4/12 2.5] e1000 - TSO fixes (in preparation for IPv6 TSO) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2320 Lines: 59 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -1475,8 +1475,9 @@ e1000_tso(struct e1000_adapter *adapter, #ifdef NETIF_F_TSO struct e1000_context_desc *context_desc; unsigned int i; - uint8_t ipcss, ipcso, tucss, tucso, hdr_len; + uint32_t cmd_length = 0; uint16_t ipcse, tucse, mss; + uint8_t ipcss, ipcso, tucss, tucso, hdr_len; if(skb_shinfo(skb)->tso_size) { hdr_len = ((skb->h.raw - skb->data) + (skb->h.th->doff << 2)); @@ -1495,6 +1496,10 @@ e1000_tso(struct e1000_adapter *adapter, tucso = (void *)&(skb->h.th->check) - (void *)skb->data; tucse = 0; + cmd_length |= (E1000_TXD_CMD_DEXT | E1000_TXD_CMD_TSE | + E1000_TXD_CMD_IP | E1000_TXD_CMD_TCP | + (skb->len - (hdr_len))); + i = adapter->tx_ring.next_to_use; context_desc = E1000_CONTEXT_DESC(adapter->tx_ring, i); @@ -1506,10 +1511,7 @@ e1000_tso(struct e1000_adapter *adapter, context_desc->upper_setup.tcp_fields.tucse = cpu_to_le16(tucse); context_desc->tcp_seg_setup.fields.mss = cpu_to_le16(mss); context_desc->tcp_seg_setup.fields.hdr_len = hdr_len; - context_desc->cmd_and_length = cpu_to_le32( - E1000_TXD_CMD_DEXT | E1000_TXD_CMD_TSE | - E1000_TXD_CMD_IP | E1000_TXD_CMD_TCP | - (skb->len - (hdr_len))); + context_desc->cmd_and_length = cpu_to_le32(cmd_length); if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; @@ -1526,17 +1551,16 @@ e1000_tx_csum(struct e1000_adapter *adap { struct e1000_context_desc *context_desc; unsigned int i; - uint8_t css, cso; + uint8_t css; if(skb->ip_summed == CHECKSUM_HW) { css = skb->h.raw - skb->data; - cso = (skb->h.raw + skb->csum) - skb->data; i = adapter->tx_ring.next_to_use; context_desc = E1000_CONTEXT_DESC(adapter->tx_ring, i); context_desc->upper_setup.tcp_fields.tucss = css; - context_desc->upper_setup.tcp_fields.tucso = cso; + context_desc->upper_setup.tcp_fields.tucso = css + skb->csum; context_desc->upper_setup.tcp_fields.tucse = 0; context_desc->tcp_seg_setup.data = 0; context_desc->cmd_and_length = cpu_to_le32(E1000_TXD_CMD_DEXT); From ganesh.venkatesan@intel.com Thu Jul 29 08:48:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:41 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFmY8E023845 for ; Thu, 29 Jul 2004 08:48:34 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFnhbw010244; Thu, 29 Jul 2004 15:49:44 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TForsD001935; Thu, 29 Jul 2004 15:51:07 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908482206361 ; Thu, 29 Jul 2004 08:48:22 -0700 Date: Thu, 29 Jul 2004 08:32:16 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 6/12 2.5] e1000 - include work down in tx path to decide when to quit polling mode Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 937 Lines: 26 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -2137,15 +2137,18 @@ e1000_clean(struct net_device *netdev, i { struct e1000_adapter *adapter = netdev->priv; int work_to_do = min(*budget, netdev->quota); + int tx_cleaned; int work_done = 0; - e1000_clean_tx_irq(adapter); + tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - if(work_done < work_to_do || !netif_running(netdev)) { + /* if no Rx and Tx cleanup work was done, exit the polling mode */ + if(!tx_cleaned || (work_done < work_to_do) || + !netif_running(netdev)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; From ganesh.venkatesan@intel.com Thu Jul 29 08:48:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:50 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFmgUd024042 for ; Thu, 29 Jul 2004 08:48:42 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFpETL022709; Thu, 29 Jul 2004 15:51:14 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFnSEk010134; Thu, 29 Jul 2004 15:50:34 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908483312735 ; Thu, 29 Jul 2004 08:48:33 -0700 Date: Thu, 29 Jul 2004 08:32:27 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 7/12 2.5] e1000 - Use pci_dma_sync_single_[for_device|for_cpu] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 998 Lines: 25 diff -up linux-2.5/drivers/net/e1000/e1000_ethtool.c linux-2.5/drivers/net/e1000.new/e1000_ethtool.c --- linux-2.5/drivers/net/e1000/e1000_ethtool.c 2004-07-28 21:50:08.576475768 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_ethtool.c 2004-07-28 21:50:09.395351280 -0700 @@ -1325,15 +1325,15 @@ e1000_run_loopback_test(struct e1000_ada for(i = 0; i < 64; i++) { e1000_create_lbtest_frame(txdr->buffer_info[i].skb, 1024); - pci_dma_sync_single(pdev, txdr->buffer_info[i].dma, - txdr->buffer_info[i].length, - PCI_DMA_TODEVICE); + pci_dma_sync_single_for_device(pdev, txdr->buffer_info[i].dma, + txdr->buffer_info[i].length, + PCI_DMA_TODEVICE); } E1000_WRITE_REG(&adapter->hw, TDT, i); msec_delay(200); - pci_dma_sync_single(pdev, rxdr->buffer_info[0].dma, + pci_dma_sync_single_for_cpu(pdev, rxdr->buffer_info[0].dma, rxdr->buffer_info[0].length, PCI_DMA_FROMDEVICE); return e1000_check_lbtest_frame(rxdr->buffer_info[0].skb, 1024); From ganesh.venkatesan@intel.com Thu Jul 29 08:48:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:49 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFmeaX023971 for ; Thu, 29 Jul 2004 08:48:40 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFndv3010115; Thu, 29 Jul 2004 15:49:41 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFnrsZ001243; Thu, 29 Jul 2004 15:51:01 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908481506337 ; Thu, 29 Jul 2004 08:48:15 -0700 Date: Thu, 29 Jul 2004 08:32:09 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 5/12 2.5] e1000 - Avoid infinite loop while trying to re-establish link Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 496 Lines: 16 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -1842,10 +1842,8 @@ e1000_tx_timeout_task(struct net_device { struct e1000_adapter *adapter = netdev->priv; - netif_device_detach(netdev); e1000_down(adapter); e1000_up(adapter); - netif_device_attach(netdev); } /** From ganesh.venkatesan@intel.com Thu Jul 29 08:48:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:48:59 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFmoiO024196 for ; Thu, 29 Jul 2004 08:48:50 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFpMTL022781; Thu, 29 Jul 2004 15:51:22 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFoVsT001657; Thu, 29 Jul 2004 15:51:25 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908484006412 ; Thu, 29 Jul 2004 08:48:40 -0700 Date: Thu, 29 Jul 2004 08:32:34 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 8/12 2.5] e1000 - Shutdown PHY while bringing the interface down (if WoL is off) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1913 Lines: 64 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -256,6 +256,14 @@ e1000_up(struct e1000_adapter *adapter) /* hardware has been reset, we need to reload some things */ + /* Reset the PHY if it was previously powered down */ + if(adapter->hw.media_type == e1000_media_type_copper) { + uint16_t mii_reg; + e1000_read_phy_reg(&adapter->hw, PHY_CTRL, &mii_reg); + if(mii_reg & MII_CR_POWER_DOWN) + e1000_phy_reset(&adapter->hw); + } + e1000_set_multi(netdev); e1000_restore_vlan(adapter); @@ -294,6 +302,15 @@ e1000_down(struct e1000_adapter *adapter e1000_reset(adapter); e1000_clean_tx_ring(adapter); e1000_clean_rx_ring(adapter); + + /* If WoL is not enabled + * Power down the PHY so no link is implied when interface is down */ + if(!adapter->wol && adapter->hw.media_type == e1000_media_type_copper) { + uint16_t mii_reg; + e1000_read_phy_reg(&adapter->hw, PHY_CTRL, &mii_reg); + mii_reg |= MII_CR_POWER_DOWN; + e1000_write_phy_reg(&adapter->hw, PHY_CTRL, mii_reg); + } } void @@ -2543,6 +2521,8 @@ e1000_mii_ioctl(struct net_device *netde switch (data->reg_num) { case PHY_CTRL: if(data->val_in & MII_CR_AUTO_NEG_EN) { + if(mii_reg & MII_CR_POWER_DOWN) + break; adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = 0x2F; } else { @@ -2572,6 +2591,18 @@ e1000_mii_ioctl(struct net_device *netde return -EIO; break; } + } else { + switch (data->reg_num) { + case PHY_CTRL: + if(mii_reg & MII_CR_POWER_DOWN) + break; + if(netif_running(adapter->netdev)) { + e1000_down(adapter); + e1000_up(adapter); + } else + e1000_reset(adapter); + break; + } } break; default: From ganesh.venkatesan@intel.com Thu Jul 29 08:48:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:49:07 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFmupU024281 for ; Thu, 29 Jul 2004 08:48:57 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFo6bw010555; Thu, 29 Jul 2004 15:50:06 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFnSEs010134; Thu, 29 Jul 2004 15:50:48 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908484712786 ; Thu, 29 Jul 2004 08:48:47 -0700 Date: Thu, 29 Jul 2004 08:32:41 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 9/12 2.5] e1000 - add compiler hints (likely/unlikely), check return codes and other cleanup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 20954 Lines: 630 diff -up linux-2.5/drivers/net/e1000/e1000.h linux-2.5/drivers/net/e1000.new/e1000.h --- linux-2.5/drivers/net/e1000/e1000.h 2004-07-28 21:50:08.578475464 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000.h 2004-07-28 21:50:09.401350368 -0700 @@ -64,6 +64,7 @@ #include #include #include +#include #include #ifdef NETIF_F_TSO #include @@ -78,6 +70,8 @@ #define BAR_1 1 #define BAR_5 5 +#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)} struct e1000_adapter; @@ -154,9 +154,9 @@ struct e1000_adapter; struct e1000_buffer { struct sk_buff *skb; uint64_t dma; - unsigned long length; unsigned long time_stamp; - unsigned int next_to_watch; + uint16_t length; + uint16_t next_to_watch; }; struct e1000_desc_ring { diff -up linux-2.5/drivers/net/e1000/e1000_hw.c linux-2.5/drivers/net/e1000.new/e1000_hw.c --- linux-2.5/drivers/net/e1000/e1000_hw.c 2004-07-28 21:50:08.627468016 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_hw.c 2004-07-28 21:50:09.462341096 -0700 @@ -251,6 +251,7 @@ e1000_set_mac_type(struct e1000_hw *hw) break; case E1000_DEV_ID_82541ER: case E1000_DEV_ID_82541GI: + case E1000_DEV_ID_82541GI_LF: case E1000_DEV_ID_82541GI_MOBILE: hw->mac_type = e1000_82541_rev_2; break; @@ -920,7 +921,8 @@ e1000_setup_copper_link(struct e1000_hw if(ret_val) return ret_val; - if(hw->mac_type == e1000_82545_rev_3) { + if((hw->mac_type == e1000_82545_rev_3) || + (hw->mac_type == e1000_82546_rev_3)) { ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, &phy_data); phy_data |= 0x00000008; ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data); @@ -3057,16 +3059,6 @@ e1000_init_eeprom_params(struct e1000_hw } break; default: - eeprom->type = e1000_eeprom_spi; - eeprom->opcode_bits = 8; - eeprom->delay_usec = 1; - if (eecd & E1000_EECD_ADDR_BITS) { - eeprom->page_size = 32; - eeprom->address_bits = 16; - } else { - eeprom->page_size = 8; - eeprom->address_bits = 8; - } break; } diff -up linux-2.5/drivers/net/e1000/e1000_hw.h linux-2.5/drivers/net/e1000.new/e1000_hw.h --- linux-2.5/drivers/net/e1000/e1000_hw.h 2004-07-28 21:50:08.652464216 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_hw.h 2004-07-28 21:50:09.494336232 -0700 @@ -357,11 +357,11 @@ int32_t e1000_set_d3_lplu_state(struct e #define E1000_DEV_ID_82547GI 0x1075 #define E1000_DEV_ID_82541GI 0x1076 #define E1000_DEV_ID_82541GI_MOBILE 0x1077 +#define E1000_DEV_ID_82541GI_LF 0x107C #define E1000_DEV_ID_82546GB_COPPER 0x1079 #define E1000_DEV_ID_82546GB_FIBER 0x107A #define E1000_DEV_ID_82546GB_SERDES 0x107B #define E1000_DEV_ID_82547EI 0x1019 - #define NODE_ADDRESS_SIZE 6 #define ETH_LENGTH_OF_ADDRESS 6 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -27,73 +27,69 @@ *******************************************************************************/ #include "e1000.h" -#include /* Change Log + * 5.3.12 6/7/04 + * - kcompat NETIF_MSG for older kernels (2.4.9) + * - if_mii support and associated kcompat for older kernels + * - More errlogging support from Jon Mason + * - Fix TSO issues on PPC64 machines -- Jon Mason * - * 5.2.51 5/14/04 - * o set default configuration to 'NAPI disabled'. NAPI enabled driver - * causes kernel panic when the interface is shutdown while data is being - * transferred. - * 5.2.47 5/04/04 - * o fixed ethtool -t implementation - * 5.2.45 4/29/04 - * o fixed ethtool -e implementation - * o Support for ethtool ops [Stephen Hemminger (shemminger@osdl.org)] - * 5.2.42 4/26/04 - * o Added support for the DPRINTK macro for enhanced error logging. Some - * parts of the patch were supplied by Jon Mason. - * o Move the register_netdevice() donw in the probe routine due to a - * loading/unloading test issue. - * o Added a long RX byte count the the extra ethtool data members for BER - * testing purposes. - * 5.2.39 3/12/04 + * 5.3.11 6/4/04 + * - ethtool register dump reads MANC register conditionally. + * + * 5.3.10 6/1/04 */ char e1000_driver_name[] = "e1000"; char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; -char e1000_driver_version[] = "5.2.52-k4"; +#ifndef CONFIG_E1000_NAPI +#define DRIVERNAPI +#else +#define DRIVERNAPI "-NAPI" +#endif +char e1000_driver_version[] = "5.3.19-k2"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table * - * Wildcard entries (PCI_ANY_ID) should come last * Last entry must be all 0s * - * { Vendor ID, Device ID, SubVendor ID, SubDevice ID, - * Class, Class Mask, private data (not used) } + * Macro expands to... + * {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)} */ static struct pci_device_id e1000_pci_tbl[] = { - {0x8086, 0x1000, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1001, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1004, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1008, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1009, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x100F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1010, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1011, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1012, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1013, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1015, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1016, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1017, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1018, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1019, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x101D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x101E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1026, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1027, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1028, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1075, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1076, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1077, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1078, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x1079, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x107A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x8086, 0x107B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + INTEL_E1000_ETHERNET_DEVICE(0x1000), + INTEL_E1000_ETHERNET_DEVICE(0x1001), + INTEL_E1000_ETHERNET_DEVICE(0x1004), + INTEL_E1000_ETHERNET_DEVICE(0x1008), + INTEL_E1000_ETHERNET_DEVICE(0x1009), + INTEL_E1000_ETHERNET_DEVICE(0x100C), + INTEL_E1000_ETHERNET_DEVICE(0x100D), + INTEL_E1000_ETHERNET_DEVICE(0x100E), + INTEL_E1000_ETHERNET_DEVICE(0x100F), + INTEL_E1000_ETHERNET_DEVICE(0x1010), + INTEL_E1000_ETHERNET_DEVICE(0x1011), + INTEL_E1000_ETHERNET_DEVICE(0x1012), + INTEL_E1000_ETHERNET_DEVICE(0x1013), + INTEL_E1000_ETHERNET_DEVICE(0x1015), + INTEL_E1000_ETHERNET_DEVICE(0x1016), + INTEL_E1000_ETHERNET_DEVICE(0x1017), + INTEL_E1000_ETHERNET_DEVICE(0x1018), + INTEL_E1000_ETHERNET_DEVICE(0x1019), + INTEL_E1000_ETHERNET_DEVICE(0x101D), + INTEL_E1000_ETHERNET_DEVICE(0x101E), + INTEL_E1000_ETHERNET_DEVICE(0x1026), + INTEL_E1000_ETHERNET_DEVICE(0x1027), + INTEL_E1000_ETHERNET_DEVICE(0x1028), + INTEL_E1000_ETHERNET_DEVICE(0x1075), + INTEL_E1000_ETHERNET_DEVICE(0x1076), + INTEL_E1000_ETHERNET_DEVICE(0x1077), + INTEL_E1000_ETHERNET_DEVICE(0x1078), + INTEL_E1000_ETHERNET_DEVICE(0x1079), + INTEL_E1000_ETHERNET_DEVICE(0x107A), + INTEL_E1000_ETHERNET_DEVICE(0x107B), + INTEL_E1000_ETHERNET_DEVICE(0x107C), /* required last entry */ {0,} }; @@ -202,7 +198,7 @@ MODULE_AUTHOR("Intel Corporation, mac_type == e1000_82541) || - (hw->mac_type == e1000_82547) || - (hw->mac_type == e1000_82541_rev_2) || - (hw->mac_type == e1000_82547_rev_2)) + switch(hw->mac_type) { + default: + break; + case e1000_82541: + case e1000_82547: + case e1000_82541_rev_2: + case e1000_82547_rev_2: hw->phy_init_script = 1; + break; + } e1000_set_media_type(hw); - if(hw->mac_type < e1000_82543) - hw->report_tx_early = 0; - else - hw->report_tx_early = 1; - hw->wait_autoneg_complete = FALSE; hw->tbi_compatibility_en = TRUE; hw->adaptive_ifs = TRUE; @@ -751,7 +747,7 @@ e1000_open(struct net_device *netdev) if((err = e1000_up(adapter))) goto err_up; - return 0; + return E1000_SUCCESS; err_up: e1000_free_rx_resources(adapter); @@ -893,10 +889,10 @@ e1000_configure_tx(struct e1000_adapter adapter->txd_cmd = E1000_TXD_CMD_IDE | E1000_TXD_CMD_EOP | E1000_TXD_CMD_IFCS; - if(adapter->hw.report_tx_early == 1) - adapter->txd_cmd |= E1000_TXD_CMD_RS; - else + if(adapter->hw.mac_type < e1000_82543) adapter->txd_cmd |= E1000_TXD_CMD_RPS; + else + adapter->txd_cmd |= E1000_TXD_CMD_RS; /* Cache if we're 82544 running in PCI-X because we'll * need this to apply a workaround later in the send path. */ @@ -1547,7 +1538,7 @@ e1000_tx_csum(struct e1000_adapter *adap unsigned int i; uint8_t css; - if(skb->ip_summed == CHECKSUM_HW) { + if(likely(skb->ip_summed == CHECKSUM_HW)) { css = skb->h.raw - skb->data; i = adapter->tx_ring.next_to_use; @@ -1559,7 +1538,7 @@ context_desc->tcp_seg_setup.data = 0; context_desc->cmd_and_length = cpu_to_le32(E1000_TXD_CMD_DEXT); - if(++i == adapter->tx_ring.count) i = 0; + if(unlikely(++i == adapter->tx_ring.count)) i = 0; adapter->tx_ring.next_to_use = i; return TRUE; @@ -1592,14 +1585,14 @@ e1000_tx_map(struct e1000_adapter *adapt #ifdef NETIF_F_TSO /* Workaround for premature desc write-backs * in TSO mode. Append 4-byte sentinel desc */ - if(mss && !nr_frags && size == len && size > 8) + if(unlikely(mss && !nr_frags && size == len && size > 8)) size -= 4; #endif /* Workaround for potential 82544 hang in PCI-X. Avoid * terminating buffers within evenly-aligned dwords. */ - if(adapter->pcix_82544 && + if(unlikely(adapter->pcix_82544 && !((unsigned long)(skb->data + offset + size - 1) & 4) && - size > 4) + size > 4)) size -= 4; buffer_info->length = size; @@ -1613,7 +1606,7 @@ e1000_tx_map(struct e1000_adapter *adapt len -= size; offset += size; count++; - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } for(f = 0; f < nr_frags; f++) { @@ -1629,15 +1622,15 @@ e1000_tx_map(struct e1000_adapter *adapt #ifdef NETIF_F_TSO /* Workaround for premature desc write-backs * in TSO mode. Append 4-byte sentinel desc */ - if(mss && f == (nr_frags-1) && size == len && size > 8) + if(unlikely(mss && f == (nr_frags-1) && size == len && size > 8)) size -= 4; #endif /* Workaround for potential 82544 hang in PCI-X. * Avoid terminating buffers within evenly-aligned * dwords. */ - if(adapter->pcix_82544 && + if(unlikely(adapter->pcix_82544 && !((unsigned long)(frag->page+offset+size-1) & 4) && - size > 4) + size > 4)) size -= 4; buffer_info->length = size; @@ -1652,7 +1645,7 @@ e1000_tx_map(struct e1000_adapter *adapt len -= size; offset += size; count++; - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } } i = (i == 0) ? tx_ring->count - 1 : i - 1; @@ -1671,18 +1667,18 @@ e1000_tx_queue(struct e1000_adapter *ada uint32_t txd_upper = 0, txd_lower = E1000_TXD_CMD_IFCS; unsigned int i; - if(tx_flags & E1000_TX_FLAGS_TSO) { + if(likely(tx_flags & E1000_TX_FLAGS_TSO)) { txd_lower |= E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D | E1000_TXD_CMD_TSE; txd_upper |= (E1000_TXD_POPTS_IXSM | E1000_TXD_POPTS_TXSM) << 8; } - if(tx_flags & E1000_TX_FLAGS_CSUM) { + if(likely(tx_flags & E1000_TX_FLAGS_CSUM)) { txd_lower |= E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D; txd_upper |= E1000_TXD_POPTS_TXSM << 8; } - if(tx_flags & E1000_TX_FLAGS_VLAN) { + if(unlikely(tx_flags & E1000_TX_FLAGS_VLAN)) { txd_lower |= E1000_TXD_CMD_VLE; txd_upper |= (tx_flags & E1000_TX_FLAGS_VLAN_MASK); } @@ -1696,7 +1692,7 @@ e1000_tx_queue(struct e1000_adapter *ada tx_desc->lower.data = cpu_to_le32(txd_lower | buffer_info->length); tx_desc->upper.data = cpu_to_le32(txd_upper); - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } tx_desc->lower.data |= cpu_to_le32(adapter->txd_cmd); @@ -1765,7 +1751,7 @@ e1000_xmit_frame(struct sk_buff *skb, st unsigned int f; nr_frags = skb_shinfo(skb)->nr_frags; len -= skb->data_len; - if(skb->len <= 0) { + if(unlikely(skb->len <= 0)) { dev_kfree_skb_any(skb); return 0; } @@ -1811,8 +1777,8 @@ e1000_xmit_frame(struct sk_buff *skb, st } spin_unlock_irqrestore(&adapter->tx_lock, flags); - if(adapter->hw.mac_type == e1000_82547) { - if(e1000_82547_fifo_workaround(adapter, skb)) { + if(unlikely(adapter->hw.mac_type == e1000_82547)) { + if(unlikely(e1000_82547_fifo_workaround(adapter, skb))) { netif_stop_queue(netdev); mod_timer(&adapter->tx_fifo_stall_timer, jiffies); return 1; @@ -1819,7 +1777,7 @@ } } - if(adapter->vlgrp && vlan_tx_tag_present(skb)) { + if(unlikely(adapter->vlgrp && vlan_tx_tag_present(skb))) { tx_flags |= E1000_TX_FLAGS_VLAN; tx_flags |= (vlan_tx_tag_get(skb) << E1000_TX_FLAGS_VLAN_SHIFT); } @@ -1826,9 +1777,9 @@ first = adapter->tx_ring.next_to_use; - if(e1000_tso(adapter, skb)) + if(likely(e1000_tso(adapter, skb))) tx_flags |= E1000_TX_FLAGS_TSO; - else if(e1000_tx_csum(adapter, skb)) + else if(likely(e1000_tx_csum(adapter, skb))) tx_flags |= E1000_TX_FLAGS_CSUM; e1000_tx_queue(adapter, @@ -2090,7 +2086,7 @@ e1000_irq_disable(struct e1000_adapter * static inline void e1000_irq_enable(struct e1000_adapter *adapter) { - if(atomic_dec_and_test(&adapter->irq_sem)) { + if(likely(atomic_dec_and_test(&adapter->irq_sem))) { E1000_WRITE_REG(&adapter->hw, IMS, IMS_ENABLE_MASK); E1000_WRITE_FLUSH(&adapter->hw); } @@ -2109,21 +2105,21 @@ e1000_intr(int irq, void *data, struct p struct net_device *netdev = data; struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; - uint32_t icr = E1000_READ_REG(&adapter->hw, ICR); + uint32_t icr = E1000_READ_REG(hw, ICR); #ifndef CONFIG_E1000_NAPI unsigned int i; #endif - if(!icr) + if(unlikely(!icr)) return IRQ_NONE; /* Not our interrupt */ - if(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { + if(unlikely(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))) { hw->get_link_status = 1; mod_timer(&adapter->watchdog_timer, jiffies); } #ifdef CONFIG_E1000_NAPI - if(netif_rx_schedule_prep(netdev)) { + if(likely(netif_rx_schedule_prep(netdev))) { /* Disable interrupts and register for poll. The flush of the posted write is intentionally left out. @@ -2135,8 +2131,8 @@ e1000_intr(int irq, void *data, struct p } #else for(i = 0; i < E1000_MAX_INTR; i++) - if(!e1000_clean_rx_irq(adapter) & - !e1000_clean_tx_irq(adapter)) + if(unlikely(!e1000_clean_rx_irq(adapter) & + !e1000_clean_tx_irq(adapter))) break; #endif @@ -2202,8 +2185,8 @@ e1000_clean_tx_irq(struct e1000_adapter tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; - if(buffer_info->dma) { + if(likely(buffer_info->dma)) { pci_unmap_page(pdev, buffer_info->dma, buffer_info->length, @@ -2224,7 +2220,7 @@ e1000_clean_tx_irq(struct e1000_adapter tx_desc->upper.data = 0; cleaned = (i == eop); - if(++i == tx_ring->count) i = 0; + if(unlikely(++i == tx_ring->count)) i = 0; } eop = tx_ring->buffer_info[i].next_to_watch; @@ -2235,7 +2231,8 @@ e1000_clean_tx_irq(struct e1000_adapter spin_lock(&adapter->tx_lock); - if(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev)) + if(unlikely(cleaned && netif_queue_stopped(netdev) && + netif_carrier_ok(netdev))) netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); @@ -2291,8 +2277,8 @@ e1000_clean_rx_irq(struct e1000_adapter skb = buffer_info->skb; length = le16_to_cpu(rx_desc->length); - if(!(rx_desc->status & E1000_RXD_STAT_EOP)) { + if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) { /* All receives must fit into a single buffer */ E1000_DBG("%s: Receive packet consumed multiple buffers\n", @@ -2299,17 +2277,13 @@ netdev->name); dev_kfree_skb_irq(skb); - rx_desc->status = 0; - buffer_info->skb = NULL; - if(++i == rx_ring->count) i = 0; - rx_desc = E1000_RX_DESC(*rx_ring, i); - continue; + goto next_desc; } - if(rx_desc->errors & E1000_RXD_ERR_FRAME_ERR_MASK) { + if(unlikely(rx_desc->errors & E1000_RXD_ERR_FRAME_ERR_MASK)) { last_byte = *(skb->data + length - 1); if(TBI_ACCEPT(&adapter->hw, rx_desc->status, @@ -2327,13 +2277,9 @@ } else { dev_kfree_skb_irq(skb); - rx_desc->status = 0; - buffer_info->skb = NULL; - if(++i == rx_ring->count) i = 0; - rx_desc = E1000_RX_DESC(*rx_ring, i); - continue; + goto next_desc; } } @@ -2345,7 +2318,8 @@ e1000_clean_rx_irq(struct e1000_adapter skb->protocol = eth_type_trans(skb, netdev); #ifdef CONFIG_E1000_NAPI - if(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP)) { + if(unlikely(adapter->vlgrp && + (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_receive_skb(skb, adapter->vlgrp, le16_to_cpu(rx_desc->special & E1000_RXD_SPC_VLAN_MASK)); @@ -2353,7 +2318,8 @@ netif_receive_skb(skb); } #else /* CONFIG_E1000_NAPI */ - if(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP)) { + if(unlikely(adapter->vlgrp && + (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_rx(skb, adapter->vlgrp, le16_to_cpu(rx_desc->special & E1000_RXD_SPC_VLAN_MASK)); @@ -2363,10 +2336,11 @@ e1000_clean_rx_irq(struct e1000_adapter #endif /* CONFIG_E1000_NAPI */ netdev->last_rx = jiffies; +next_desc: rx_desc->status = 0; buffer_info->skb = NULL; - if(++i == rx_ring->count) i = 0; + if(unlikely(++i == rx_ring->count)) i = 0; rx_desc = E1000_RX_DESC(*rx_ring, i); } @@ -2398,11 +2364,9 @@ e1000_alloc_rx_buffers(struct e1000_adap buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { - rx_desc = E1000_RX_DESC(*rx_ring, i); skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); - - if(!skb) { + if(unlikely(!skb)) { /* Better luck next round */ break; } @@ -2423,9 +2384,10 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); - if((i & ~(E1000_RX_BUFFER_WRITE - 1)) == i) { + if(unlikely((i & ~(E1000_RX_BUFFER_WRITE - 1)) == i)) { /* Force memory writes to complete before letting h/w * know there are new descriptors to fetch. (Only * applicable for weak-ordered memory model archs, @@ -2435,7 +2426,7 @@ e1000_alloc_rx_buffers(struct e1000_adap E1000_WRITE_REG(&adapter->hw, RDT, i); } - if(++i == rx_ring->count) i = 0; + if(unlikely(++i == rx_ring->count)) i = 0; buffer_info = &rx_ring->buffer_info[i]; } @@ -2624,11 +2615,11 @@ e1000_rx_checksum(struct e1000_adapter * struct sk_buff *skb) { /* 82543 or newer only */ - if((adapter->hw.mac_type < e1000_82543) || + if(unlikely((adapter->hw.mac_type < e1000_82543) || /* Ignore Checksum bit is set */ (rx_desc->status & E1000_RXD_STAT_IXSM) || /* TCP Checksum has not been calculated */ - (!(rx_desc->status & E1000_RXD_STAT_TCPCS))) { + (!(rx_desc->status & E1000_RXD_STAT_TCPCS)))) { skb->ip_summed = CHECKSUM_NONE; return; } @@ -2651,7 +2642,8 @@ e1000_pci_set_mwi(struct e1000_hw *hw) { struct e1000_adapter *adapter = hw->back; - pci_set_mwi(adapter->pdev); + int ret; + ret = pci_set_mwi(adapter->pdev); } void From ganesh.venkatesan@intel.com Thu Jul 29 08:49:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:49:30 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFnIHi024776 for ; Thu, 29 Jul 2004 08:49:18 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFpoTL023003; Thu, 29 Jul 2004 15:51:50 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFprs9002823; Thu, 29 Jul 2004 15:51:53 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908490906478 ; Thu, 29 Jul 2004 08:49:09 -0700 Date: Thu, 29 Jul 2004 08:33:03 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 12/12 2.5] e1000 - white space and related cleanup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 24227 Lines: 757 diff -up linux-2.5/drivers/net/e1000/e1000.h linux-2.5/drivers/net/e1000.new/e1000.h --- linux-2.5/drivers/net/e1000/e1000.h 2004-07-28 21:50:08.578475464 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000.h 2004-07-28 21:50:09.401350368 -0700 @@ -102,11 +102,12 @@ struct e1000_adapter; #define E1000_MAX_INTR 10 -/* How many descriptors for TX and RX ? */ +/* TX/RX descriptor defines */ #define E1000_DEFAULT_TXD 256 #define E1000_MAX_TXD 256 #define E1000_MIN_TXD 80 #define E1000_MAX_82544_TXD 4096 + #define E1000_DEFAULT_RXD 256 #define E1000_MAX_RXD 256 #define E1000_MIN_RXD 80 @@ -127,14 +128,11 @@ struct e1000_adapter; #define E1000_TX_HEAD_ADDR_SHIFT 7 #define E1000_PBA_TX_MASK 0xFFFF0000 -/* Flow Control High-Watermark: 5688 bytes below Rx FIFO size */ -#define E1000_FC_HIGH_DIFF 0x1638 - -/* Flow Control Low-Watermark: 5696 bytes below Rx FIFO size */ -#define E1000_FC_LOW_DIFF 0x1640 +/* Flow Control Watermarks */ +#define E1000_FC_HIGH_DIFF 0x1638 /* High: 5688 bytes below Rx FIFO size */ +#define E1000_FC_LOW_DIFF 0x1640 /* Low: 5696 bytes below Rx FIFO size */ -/* Flow Control Pause Time: 858 usec */ -#define E1000_FC_PAUSE_TIME 0x0680 +#define E1000_FC_PAUSE_TIME 0x0680 /* 858 usec */ /* How many Tx Descriptors do we need to call netif_wake_queue ? */ #define E1000_TX_QUEUE_WAKE 16 @@ -206,7 +204,7 @@ struct e1000_adapter { spinlock_t stats_lock; atomic_t irq_sem; struct work_struct tx_timeout_task; - uint8_t fc_autoneg; + uint8_t fc_autoneg; struct timer_list blink_timer; unsigned long led_status; diff -up linux-2.5/drivers/net/e1000/e1000_hw.c linux-2.5/drivers/net/e1000.new/e1000_hw.c --- linux-2.5/drivers/net/e1000/e1000_hw.c 2004-07-28 21:50:08.627468016 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_hw.c 2004-07-28 21:50:09.462341096 -0700 @@ -3445,7 +3445,6 @@ e1000_read_eeprom(struct e1000_hw *hw, uint32_t i = 0; DEBUGFUNC("e1000_read_eeprom"); - /* A check for invalid values: offset too large, too many words, and not * enough words. */ @@ -5216,3 +5215,4 @@ e1000_enable_mng_pass_thru(struct e1000_ } return FALSE; } + diff -up linux-2.5/drivers/net/e1000/e1000_hw.h linux-2.5/drivers/net/e1000.new/e1000_hw.h --- linux-2.5/drivers/net/e1000/e1000_hw.h 2004-07-28 21:50:08.652464216 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_hw.h 2004-07-28 21:50:09.494336232 -0700 @@ -1043,7 +1043,6 @@ struct e1000_hw { #define E1000_EEPROM_SWDPIN0 0x0001 /* SWDPIN 0 EEPROM Value */ #define E1000_EEPROM_LED_LOGIC 0x0020 /* Led Logic Word */ - /* Register Bit Masks */ /* Device Control */ #define E1000_CTRL_FD 0x00000001 /* Full duplex.0=half; 1=full */ diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -168,7 +168,7 @@ static int e1000_resume(struct pci_dev * #ifdef CONFIG_NET_POLL_CONTROLLER /* for netdump / net console */ -static void e1000_netpoll (struct net_device *dev); +static void e1000_netpoll (struct net_device *netdev); #endif struct notifier_block e1000_notifier_reboot = { @@ -181,7 +181,6 @@ struct notifier_block e1000_notifier_reb extern void e1000_check_options(struct e1000_adapter *adapter); - static struct pci_driver e1000_driver = { .name = e1000_driver_name, .id_table = e1000_pci_tbl, @@ -336,10 +335,10 @@ e1000_reset(struct e1000_adapter *adapte E1000_WRITE_REG(&adapter->hw, PBA, pba); /* flow control settings */ - adapter->hw.fc_high_water = - (pba << E1000_PBA_BYTES_SHIFT) - E1000_FC_HIGH_DIFF; - adapter->hw.fc_low_water = - (pba << E1000_PBA_BYTES_SHIFT) - E1000_FC_LOW_DIFF; + adapter->hw.fc_high_water = (pba << E1000_PBA_BYTES_SHIFT) - + E1000_FC_HIGH_DIFF; + adapter->hw.fc_low_water = (pba << E1000_PBA_BYTES_SHIFT) - + E1000_FC_LOW_DIFF; adapter->hw.fc_pause_time = E1000_FC_PAUSE_TIME; adapter->hw.fc_send_xon = 1; adapter->hw.fc = adapter->hw.original_fc; @@ -424,8 +423,8 @@ e1000_probe(struct pci_dev *pdev, adapter->msg_enable = (1 << debug) - 1; rtnl_lock(); - /* we need to set the name early since the DPRINTK macro needs it set */ - if (dev_alloc_name(netdev, netdev->name) < 0) + /* we need to set the name early for the DPRINTK macro */ + if(dev_alloc_name(netdev, netdev->name) < 0) goto err_free_unlock; mmio_start = pci_resource_start(pdev, BAR_0); @@ -583,10 +582,9 @@ e1000_probe(struct pci_dev *pdev, adapter->wol |= E1000_WUFC_MAG; /* reset the hardware with the new settings */ - e1000_reset(adapter); - /* since we are holding the rtnl lock already, call the no-lock version */ + /* We're already holding the rtnl lock; call the no-lock version */ if((err = register_netdevice(netdev))) goto err_register; @@ -677,7 +675,7 @@ e1000_sw_init(struct e1000_adapter *adap /* identify the MAC */ - if (e1000_set_mac_type(hw)) { + if(e1000_set_mac_type(hw)) { DPRINTK(PROBE, ERR, "Unknown MAC Type\n"); return -EIO; } @@ -975,7 +973,9 @@ e1000_setup_rctl(struct e1000_adapter *a else rctl &= ~E1000_RCTL_SBP; + /* Setup buffer sizes */ rctl &= ~(E1000_RCTL_SZ_4096); + rctl |= (E1000_RCTL_BSEX | E1000_RCTL_LPE); switch (adapter->rx_buffer_len) { case E1000_RXBUFFER_2048: default: @@ -983,13 +983,13 @@ e1000_setup_rctl(struct e1000_adapter *a rctl &= ~(E1000_RCTL_BSEX | E1000_RCTL_LPE); break; case E1000_RXBUFFER_4096: - rctl |= E1000_RCTL_SZ_4096 | E1000_RCTL_BSEX | E1000_RCTL_LPE; + rctl |= E1000_RCTL_SZ_4096; break; case E1000_RXBUFFER_8192: - rctl |= E1000_RCTL_SZ_8192 | E1000_RCTL_BSEX | E1000_RCTL_LPE; + rctl |= E1000_RCTL_SZ_8192; break; case E1000_RXBUFFER_16384: - rctl |= E1000_RCTL_SZ_16384 | E1000_RCTL_BSEX | E1000_RCTL_LPE; + rctl |= E1000_RCTL_SZ_16384; break; } @@ -1011,13 +1011,11 @@ e1000_configure_rx(struct e1000_adapter uint32_t rctl; uint32_t rxcsum; - /* make sure receives are disabled while setting up the descriptors */ - + /* disable receives while setting up the descriptors */ rctl = E1000_READ_REG(&adapter->hw, RCTL); E1000_WRITE_REG(&adapter->hw, RCTL, rctl & ~E1000_RCTL_EN); /* set the Receive Delay Timer Register */ - E1000_WRITE_REG(&adapter->hw, RDTR, adapter->rx_int_delay); if(adapter->hw.mac_type >= e1000_82540) { @@ -1028,7 +1026,6 @@ e1000_configure_rx(struct e1000_adapter } /* Setup the Base and Length of the Rx Descriptor Ring */ - E1000_WRITE_REG(&adapter->hw, RDBAL, (rdba & 0x00000000ffffffffULL)); E1000_WRITE_REG(&adapter->hw, RDBAH, (rdba >> 32)); @@ -1047,7 +1044,6 @@ e1000_configure_rx(struct e1000_adapter } /* Enable Receives */ - E1000_WRITE_REG(&adapter->hw, RCTL, rctl); } @@ -1095,9 +1091,9 @@ e1000_clean_tx_ring(struct e1000_adapter if(buffer_info->skb) { pci_unmap_page(pdev, - buffer_info->dma, - buffer_info->length, - PCI_DMA_TODEVICE); + buffer_info->dma, + buffer_info->length, + PCI_DMA_TODEVICE); dev_kfree_skb(buffer_info->skb); @@ -1163,12 +1159,11 @@ e1000_clean_rx_ring(struct e1000_adapter if(buffer_info->skb) { pci_unmap_single(pdev, - buffer_info->dma, - buffer_info->length, - PCI_DMA_FROMDEVICE); + buffer_info->dma, + buffer_info->length, + PCI_DMA_FROMDEVICE); dev_kfree_skb(buffer_info->skb); - buffer_info->skb = NULL; } } @@ -1334,7 +1329,8 @@ e1000_set_multi(struct net_device *netde e1000_leave_82542_rst(adapter); } -/* need to wait a few seconds after link up to get diagnostic information from the phy */ +/* Need to wait a few seconds after link up to get diagnostic information from + * the phy */ static void e1000_update_phy_info(unsigned long data) @@ -1442,7 +1438,7 @@ e1000_watchdog(unsigned long data) adapter->tpt_old = adapter->stats.tpt; adapter->hw.collision_delta = adapter->stats.colc - adapter->colc_old; adapter->colc_old = adapter->stats.colc; - + adapter->gorcl = adapter->stats.gorcl - adapter->gorcl_old; adapter->gorcl_old = adapter->stats.gorcl; adapter->gotcl = adapter->stats.gotcl - adapter->gotcl_old; @@ -1590,7 +1586,6 @@ e1000_tx_map(struct e1000_adapter *adapt unsigned int f; len -= skb->data_len; - i = tx_ring->next_to_use; while(len) { @@ -1662,10 +1639,11 @@ e1000_tx_map(struct e1000_adapter *adapt if(unlikely(++i == tx_ring->count)) i = 0; } } + i = (i == 0) ? tx_ring->count - 1 : i - 1; tx_ring->buffer_info[i].skb = skb; tx_ring->buffer_info[first].next_to_watch = i; - + return count; } @@ -1756,7 +1752,7 @@ no_fifo_stall_required: return 0; } -#define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1 ) +#define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1 ) static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev) { @@ -1764,14 +1744,15 @@ e1000_xmit_frame(struct sk_buff *skb, st unsigned int first, max_per_txd = E1000_MAX_DATA_PER_TXD; unsigned int max_txd_pwr = E1000_MAX_TXD_PWR; unsigned int tx_flags = 0; - unsigned long flags; unsigned int len = skb->len; - int count = 0; - unsigned int mss = 0; + unsigned long flags; unsigned int nr_frags = 0; + unsigned int mss = 0; + int count = 0; unsigned int f; nr_frags = skb_shinfo(skb)->nr_frags; len -= skb->data_len; + if(unlikely(skb->len <= 0)) { dev_kfree_skb_any(skb); return 0; @@ -1779,7 +1744,7 @@ #ifdef NETIF_F_TSO mss = skb_shinfo(skb)->tso_size; - /* The controller does a simple calculation to + /* The controller does a simple calculation to * make sure there is enough room in the FIFO before * initiating the DMA for each buffer. The calc is: * 4 = ceil(buffer len/mss). To make sure we don't @@ -1789,15 +1769,16 @@ e1000_xmit_frame(struct sk_buff *skb, st max_per_txd = min(mss << 2, max_per_txd); max_txd_pwr = fls(max_per_txd) - 1; } + if((mss) || (skb->ip_summed == CHECKSUM_HW)) count++; - count++; /*for sentinel desc*/ + count++; /* for sentinel desc */ #else if(skb->ip_summed == CHECKSUM_HW) count++; #endif - count += TXD_USE_COUNT(len, max_txd_pwr); + if(adapter->pcix_82544) count++; @@ -1804,18 +1769,20 @@ nr_frags = skb_shinfo(skb)->nr_frags; for(f = 0; f < nr_frags; f++) count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size, - max_txd_pwr); + max_txd_pwr); if(adapter->pcix_82544) count += nr_frags; - + spin_lock_irqsave(&adapter->tx_lock, flags); - /* need: count + 2 desc gap to keep tail from touching + + /* need: count + 2 desc gap to keep tail from touching * head, otherwise try next time */ - if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2 ) { + if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2) { netif_stop_queue(netdev); spin_unlock_irqrestore(&adapter->tx_lock, flags); return 1; } + spin_unlock_irqrestore(&adapter->tx_lock, flags); if(unlikely(adapter->hw.mac_type == e1000_82547)) { @@ -1838,8 +1769,8 @@ else if(likely(e1000_tx_csum(adapter, skb))) tx_flags |= E1000_TX_FLAGS_CSUM; - e1000_tx_queue(adapter, - e1000_tx_map(adapter, skb, first, max_per_txd, nr_frags, mss), + e1000_tx_queue(adapter, + e1000_tx_map(adapter, skb, first, max_per_txd, nr_frags, mss), tx_flags); netdev->trans_start = jiffies; @@ -1926,7 +1926,6 @@ e1000_change_mtu(struct net_device *netd } if(old_mtu != adapter->rx_buffer_len && netif_running(netdev)) { - e1000_down(adapter); e1000_up(adapter); } @@ -1972,8 +1971,6 @@ e1000_update_stats(struct e1000_adapter adapter->stats.prc1023 += E1000_READ_REG(hw, PRC1023); adapter->stats.prc1522 += E1000_READ_REG(hw, PRC1522); - /* the rest of the counters are only modified here */ - adapter->stats.symerrs += E1000_READ_REG(hw, SYMERRS); adapter->stats.mpc += E1000_READ_REG(hw, MPC); adapter->stats.scc += E1000_READ_REG(hw, SCC); @@ -2180,8 +2177,8 @@ e1000_clean(struct net_device *netdev, i return (work_done >= work_to_do); } -#endif +#endif /** * e1000_clean_tx_irq - Reclaim resources after transmit completes * @adapter: board private structure @@ -2198,31 +2177,25 @@ e1000_clean_tx_irq(struct e1000_adapter unsigned int i, eop; boolean_t cleaned = FALSE; - i = tx_ring->next_to_clean; eop = tx_ring->buffer_info[i].next_to_watch; eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { - for(cleaned = FALSE; !cleaned; ) { tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; - if(likely(buffer_info->dma)) { pci_unmap_page(pdev, buffer_info->dma, buffer_info->length, PCI_DMA_TODEVICE); - buffer_info->dma = 0; } if(buffer_info->skb) { - dev_kfree_skb_any(buffer_info->skb); - buffer_info->skb = NULL; } @@ -2252,7 +2243,7 @@ e1000_clean_tx_irq(struct e1000_adapter } /** - * e1000_clean_rx_irq - Send received data up the network stack, + * e1000_clean_rx_irq - Send received data up the network stack * @adapter: board private structure **/ @@ -2281,14 +2272,11 @@ e1000_clean_rx_irq(struct e1000_adapter while(rx_desc->status & E1000_RXD_STAT_DD) { buffer_info = &rx_ring->buffer_info[i]; - #ifdef CONFIG_E1000_NAPI if(*work_done >= work_to_do) break; - (*work_done)++; #endif - cleaned = TRUE; pci_unmap_single(pdev, @@ -2299,40 +2278,27 @@ e1000_clean_rx_irq(struct e1000_adapter skb = buffer_info->skb; length = le16_to_cpu(rx_desc->length); - if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) { /* All receives must fit into a single buffer */ - - E1000_DBG("%s: Receive packet consumed multiple buffers\n", - netdev->name); - + E1000_DBG("%s: Receive packet consumed multiple" + " buffers\n", netdev->name); dev_kfree_skb_irq(skb); - - goto next_desc; } - if(unlikely(rx_desc->errors & E1000_RXD_ERR_FRAME_ERR_MASK)) { last_byte = *(skb->data + length - 1); - if(TBI_ACCEPT(&adapter->hw, rx_desc->status, rx_desc->errors, length, last_byte)) { - spin_lock_irqsave(&adapter->stats_lock, flags); - e1000_tbi_adjust_stats(&adapter->hw, &adapter->stats, length, skb->data); - spin_unlock_irqrestore(&adapter->stats_lock, flags); length--; } else { - dev_kfree_skb_irq(skb); - - goto next_desc; } } @@ -2348,8 +2332,8 @@ e1000_clean_rx_irq(struct e1000_adapter if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_receive_skb(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & - E1000_RXD_SPC_VLAN_MASK)); + le16_to_cpu(rx_desc->special & + E1000_RXD_SPC_VLAN_MASK)); } else { netif_receive_skb(skb); } @@ -2357,7 +2332,7 @@ if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_rx(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & + le16_to_cpu(rx_desc->special & E1000_RXD_SPC_VLAN_MASK)); } else { netif_rx(skb); @@ -2368,7 +2350,6 @@ e1000_clean_rx_irq(struct e1000_adapter next_desc: rx_desc->status = 0; buffer_info->skb = NULL; - if(unlikely(++i == rx_ring->count)) i = 0; rx_desc = E1000_RX_DESC(*rx_ring, i); @@ -2418,11 +2399,10 @@ e1000_alloc_rx_buffers(struct e1000_adap buffer_info->skb = skb; buffer_info->length = adapter->rx_buffer_len; - buffer_info->dma = - pci_map_single(pdev, - skb->data, - adapter->rx_buffer_len, - PCI_DMA_FROMDEVICE); + buffer_info->dma = pci_map_single(pdev, + skb->data, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); @@ -2556,24 +2546,24 @@ e1000_mii_ioctl(struct net_device *netde return -EFAULT; mii_reg = data->val_in; if (e1000_write_phy_reg(&adapter->hw, data->reg_num, - data->val_in)) + mii_reg)) return -EIO; if (adapter->hw.phy_type == e1000_phy_m88) { switch (data->reg_num) { case PHY_CTRL: - if(data->val_in & MII_CR_AUTO_NEG_EN) { if(mii_reg & MII_CR_POWER_DOWN) break; + if(mii_reg & MII_CR_AUTO_NEG_EN) { adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = 0x2F; } else { - if (data->val_in & 0x40) + if (mii_reg & 0x40) spddplx = SPEED_1000; - else if (data->val_in & 0x2000) + else if (mii_reg & 0x2000) spddplx = SPEED_100; else spddplx = SPEED_10; - spddplx += (data->val_in & 0x100) + spddplx += (mii_reg & 0x100) ? FULL_DUPLEX : HALF_DUPLEX; retval = e1000_set_spd_dplx(adapter, @@ -2642,7 +2615,7 @@ e1000_rx_checksum(struct e1000_adapter * skb->ip_summed = CHECKSUM_NONE; adapter->hw_csum_err++; } else { - /* TCP checksum is good */ + /* TCP checksum is good */ skb->ip_summed = CHECKSUM_UNNECESSARY; adapter->hw_csum_good++; } @@ -2704,26 +2677,22 @@ e1000_vlan_rx_register(struct net_device if(grp) { /* enable VLAN tag insert/strip */ - ctrl = E1000_READ_REG(&adapter->hw, CTRL); ctrl |= E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, CTRL, ctrl); /* enable VLAN receive filtering */ - rctl = E1000_READ_REG(&adapter->hw, RCTL); rctl |= E1000_RCTL_VFE; rctl &= ~E1000_RCTL_CFIEN; E1000_WRITE_REG(&adapter->hw, RCTL, rctl); } else { /* disable VLAN tag insert/strip */ - ctrl = E1000_READ_REG(&adapter->hw, CTRL); ctrl &= ~E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, CTRL, ctrl); /* disable VLAN filtering */ - rctl = E1000_READ_REG(&adapter->hw, RCTL); rctl &= ~E1000_RCTL_VFE; E1000_WRITE_REG(&adapter->hw, RCTL, rctl); @@ -2739,7 +2708,6 @@ e1000_vlan_rx_add_vid(struct net_device uint32_t vfta, index; /* add VID to filter table */ - index = (vid >> 5) & 0x7F; vfta = E1000_READ_REG_ARRAY(&adapter->hw, VFTA, index); vfta |= (1 << (vid & 0x1F)); @@ -2759,8 +2727,7 @@ e1000_vlan_rx_kill_vid(struct net_device e1000_irq_enable(adapter); - /* remove VID from filter table*/ - + /* remove VID from filter table */ index = (vid >> 5) & 0x7F; vfta = E1000_READ_REG_ARRAY(&adapter->hw, VFTA, index); vfta &= ~(1 << (vid & 0x1F)); @@ -2949,12 +2916,12 @@ e1000_resume(struct pci_dev *pdev) * without having to re-enable interrupts. It's not called while * the interrupt routine is executing. */ - -static void e1000_netpoll (struct net_device *dev) +static void +e1000_netpoll (struct net_device *netdev) { - struct e1000_adapter *adapter = dev->priv; + struct e1000_adapter *adapter = netdev->priv; disable_irq(adapter->pdev->irq); - e1000_intr (adapter->pdev->irq, dev, NULL); + e1000_intr(adapter->pdev->irq, netdev, NULL); enable_irq(adapter->pdev->irq); } #endif diff -up linux-2.5/drivers/net/e1000/e1000_param.c linux-2.5/drivers/net/e1000.new/e1000_param.c --- linux-2.5/drivers/net/e1000/e1000_param.c 2004-07-28 21:50:08.683459504 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_param.c 2004-07-28 21:50:09.537329696 -0700 @@ -235,7 +235,7 @@ struct e1000_option { static int __devinit e1000_validate_option(int *value, struct e1000_option *opt, - struct e1000_adapter *adapter) + struct e1000_adapter *adapter) { if(*value == OPTION_UNSET) { *value = opt->def; @@ -256,7 +256,7 @@ e1000_validate_option(int *value, struct case range_option: if(*value >= opt->arg.r.min && *value <= opt->arg.r.max) { DPRINTK(PROBE, INFO, - "%s set to %i\n", opt->name, *value); + "%s set to %i\n", opt->name, *value); return 0; } break; @@ -449,8 +449,7 @@ e1000_check_options(struct e1000_adapter DPRINTK(PROBE, INFO, "%s turned off\n", opt.name); break; case 1: - DPRINTK(PROBE, INFO, - "%s set to dynamic mode\n", opt.name); + DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", opt.name); break; default: e1000_validate_option(&adapter->itr, &opt, adapter); @@ -493,8 +492,9 @@ e1000_check_fiber_options(struct e1000_a "parameter ignored\n"); } if((AutoNeg[bd] != OPTION_UNSET) && (AutoNeg[bd] != 0x20)) { - DPRINTK(PROBE, INFO, "AutoNeg other than Full/1000 is " - "not valid for fiber adapters, parameter ignored\n"); + DPRINTK(PROBE, INFO, "AutoNeg other than 1000/Full is " + "not valid for fiber adapters, " + "parameter ignored\n"); } } @@ -611,24 +611,24 @@ e1000_check_copper_options(struct e1000_ break; case HALF_DUPLEX: DPRINTK(PROBE, INFO, "Half Duplex specified without Speed\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at Half Duplex only\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "Half Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | ADVERTISE_100_HALF; break; case FULL_DUPLEX: DPRINTK(PROBE, INFO, "Full Duplex specified without Speed\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at Full Duplex only\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_FULL | ADVERTISE_100_FULL | ADVERTISE_1000_FULL; break; case SPEED_10: - DPRINTK(PROBE, INFO, - "10 Mbps Speed specified without Duplex\n"); + DPRINTK(PROBE, INFO, "10 Mbps Speed specified " + "without Duplex\n"); DPRINTK(PROBE, INFO, "Using Autonegotiation at 10 Mbps only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | @@ -647,10 +647,10 @@ e1000_check_copper_options(struct e1000_ adapter->hw.autoneg_advertised = 0; break; case SPEED_100: - DPRINTK(PROBE, INFO, - "100 Mbps Speed specified without Duplex\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at 100 Mbps only\n"); + DPRINTK(PROBE, INFO, "100 Mbps Speed specified " + "without Duplex\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "100 Mbps only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_100_HALF | ADVERTISE_100_FULL; @@ -668,10 +668,11 @@ e1000_check_copper_options(struct e1000_ adapter->hw.autoneg_advertised = 0; break; case SPEED_1000: + DPRINTK(PROBE, INFO, "1000 Mbps Speed specified without " + "Duplex\n"); DPRINTK(PROBE, INFO, - "1000 Mbps Speed specified without Duplex\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + "Using Autonegotiation at 1000 Mbps " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; @@ -679,7 +680,8 @@ e1000_check_copper_options(struct e1000_ DPRINTK(PROBE, INFO, "Half Duplex is not supported at 1000 Mbps\n"); DPRINTK(PROBE, INFO, - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + "Using Autonegotiation at 1000 Mbps " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; @@ -696,8 +698,8 @@ e1000_check_copper_options(struct e1000_ /* Speed, AutoNeg and MDI/MDI-X must all play nice */ if (e1000_validate_mdi_setting(&(adapter->hw)) < 0) { DPRINTK(PROBE, INFO, - "Speed, AutoNeg and MDI-X specifications are " - "incompatible. Setting MDI-X to a compatible value.\n"); + "Speed, AutoNeg and MDI-X specifications are " + "incompatible. Setting MDI-X to a compatible value.\n"); } } Only in linux-2.5/drivers/net/e1000.new: kcompat_ethtool.c From ganesh.venkatesan@intel.com Thu Jul 29 08:49:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:49:27 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFnGat024731 for ; Thu, 29 Jul 2004 08:49:16 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr004.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFol40027166; Thu, 29 Jul 2004 15:50:48 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFmTBH023455; Thu, 29 Jul 2004 15:48:52 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908485506496 ; Thu, 29 Jul 2004 08:48:55 -0700 Date: Thu, 29 Jul 2004 08:32:49 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 10/12 2.5] e1000 - more DPRINTK messages to syslog Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2604 Lines: 74 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -347,7 +347,8 @@ e1000_reset(struct e1000_adapter *adapte e1000_reset_hw(&adapter->hw); if(adapter->hw.mac_type >= e1000_82544) E1000_WRITE_REG(&adapter->hw, WUC, 0); - e1000_init_hw(&adapter->hw); + if(e1000_init_hw(&adapter->hw)) + DPRINTK(PROBE, ERR, "Hardware Error\n"); /* Enable h/w to recognize an 802.1Q VLAN Ethernet packet */ E1000_WRITE_REG(&adapter->hw, VET, ETHERNET_IEEE_VLAN_TYPE); @@ -517,10 +518,12 @@ e1000_probe(struct pci_dev *pdev, /* copy the MAC address out of the EEPROM */ - e1000_read_mac_addr(&adapter->hw); + if (e1000_read_mac_addr(&adapter->hw)) + DPRINTK(PROBE, ERR, "EEPROM Read Error\n"); memcpy(netdev->dev_addr, adapter->hw.mac_addr, netdev->addr_len); if(!is_valid_ether_addr(netdev->dev_addr)) { + DPRINTK(PROBE, ERR, "Invalid MAC Address\n"); err = -EIO; goto err_eeprom; } @@ -801,6 +789,8 @@ e1000_setup_tx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * txdr->count; txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Transmit descriptor ring\n"); return -ENOMEM; } memset(txdr->buffer_info, 0, size); @@ -812,6 +802,8 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } @@ -918,6 +906,8 @@ e1000_setup_rx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * rxdr->count; rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Recieve descriptor ring\n"); return -ENOMEM; } memset(rxdr->buffer_info, 0, size); @@ -930,6 +920,8 @@ e1000_setup_rx_resources(struct e1000_ad rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { + DPRINTK(PROBE, ERR, + "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } @@ -2795,6 +2806,8 @@ e1000_set_spd_dplx(struct e1000_adapter break; case SPEED_1000 + DUPLEX_HALF: /* not supported */ default: + DPRINTK(PROBE, ERR, + "Unsupported Speed/Duplexity configuration\n"); return -EINVAL; } return 0; From ganesh.venkatesan@intel.com Thu Jul 29 08:49:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:49:42 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFnThX024976 for ; Thu, 29 Jul 2004 08:49:32 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFmoQn010029; Thu, 29 Jul 2004 15:48:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFhtOp004023; Thu, 29 Jul 2004 15:44:43 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908490117837 ; Thu, 29 Jul 2004 08:49:01 -0700 Date: Thu, 29 Jul 2004 08:32:55 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 11/12 2.5] e1000 - suspend/resume fix from alex@zodiac.dasalias.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 668 Lines: 22 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-07-28 21:50:08.672461176 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-07-28 21:50:09.523331824 -0700 @@ -2901,6 +2901,8 @@ e1000_suspend(struct pci_dev *pdev, uint } } + pci_disable_device(pdev); + state = (state > 0) ? 3 : 0; pci_set_power_state(pdev, state); @@ -2915,6 +2917,7 @@ e1000_resume(struct pci_dev *pdev) struct e1000_adapter *adapter = netdev->priv; uint32_t manc; + pci_enable_device(pdev); pci_set_power_state(pdev, 0); pci_restore_state(pdev, adapter->pci_state); From ganesh.venkatesan@intel.com Thu Jul 29 08:49:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:49:48 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFnciv025088 for ; Thu, 29 Jul 2004 08:49:39 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFolbw010978; Thu, 29 Jul 2004 15:50:47 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFn4BP024036; Thu, 29 Jul 2004 15:49:18 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908492306570 ; Thu, 29 Jul 2004 08:49:23 -0700 Date: Thu, 29 Jul 2004 08:33:16 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 12/12 2.4] e1000 - white space and other cleanup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 23466 Lines: 735 diff -up linux-2.4/drivers/net/e1000/e1000.h linux-2.4/drivers/net/e1000.new/e1000.h --- linux-2.4/drivers/net/e1000/e1000.h 2004-07-28 08:47:08.172582760 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000.h 2004-07-28 08:47:09.439390176 -0700 @@ -103,11 +103,12 @@ struct e1000_adapter; #define E1000_MAX_INTR 10 -/* How many descriptors for TX and RX ? */ +/* TX/RX descriptor defines */ #define E1000_DEFAULT_TXD 256 #define E1000_MAX_TXD 256 #define E1000_MIN_TXD 80 #define E1000_MAX_82544_TXD 4096 + #define E1000_DEFAULT_RXD 256 #define E1000_MAX_RXD 256 #define E1000_MIN_RXD 80 @@ -128,14 +129,11 @@ struct e1000_adapter; #define E1000_TX_HEAD_ADDR_SHIFT 7 #define E1000_PBA_TX_MASK 0xFFFF0000 -/* Flow Control High-Watermark: 5688 bytes below Rx FIFO size */ -#define E1000_FC_HIGH_DIFF 0x1638 - -/* Flow Control Low-Watermark: 5696 bytes below Rx FIFO size */ -#define E1000_FC_LOW_DIFF 0x1640 +/* Flow Control Watermarks */ +#define E1000_FC_HIGH_DIFF 0x1638 /* High: 5688 bytes below Rx FIFO size */ +#define E1000_FC_LOW_DIFF 0x1640 /* Low: 5696 bytes below Rx FIFO size */ -/* Flow Control Pause Time: 858 usec */ -#define E1000_FC_PAUSE_TIME 0x0680 +#define E1000_FC_PAUSE_TIME 0x0680 /* 858 usec */ /* How many Tx Descriptors do we need to call netif_wake_queue ? */ #define E1000_TX_QUEUE_WAKE 16 diff -up linux-2.4/drivers/net/e1000/e1000_hw.c linux-2.4/drivers/net/e1000.new/e1000_hw.c --- linux-2.4/drivers/net/e1000/e1000_hw.c 2004-07-28 08:47:08.174582456 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_hw.c 2004-07-28 08:47:09.499381056 -0700 @@ -3445,7 +3445,6 @@ e1000_read_eeprom(struct e1000_hw *hw, uint32_t i = 0; DEBUGFUNC("e1000_read_eeprom"); - /* A check for invalid values: offset too large, too many words, and not * enough words. */ @@ -5216,3 +5215,4 @@ e1000_enable_mng_pass_thru(struct e1000_ } return FALSE; } + diff -up linux-2.4/drivers/net/e1000/e1000_hw.h linux-2.4/drivers/net/e1000.new/e1000_hw.h --- linux-2.4/drivers/net/e1000/e1000_hw.h 2004-07-28 08:47:08.176582152 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_hw.h 2004-07-28 08:47:09.531376192 -0700 @@ -1043,7 +1043,6 @@ struct e1000_hw { #define E1000_EEPROM_SWDPIN0 0x0001 /* SWDPIN 0 EEPROM Value */ #define E1000_EEPROM_LED_LOGIC 0x0020 /* Led Logic Word */ - /* Register Bit Masks */ /* Device Control */ #define E1000_CTRL_FD 0x00000001 /* Full duplex.0=half; 1=full */ diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-07-28 08:47:08.177582000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-07-28 08:47:09.559371936 -0700 @@ -168,7 +168,7 @@ static int e1000_resume(struct pci_dev * #ifdef CONFIG_NET_POLL_CONTROLLER /* for netdump / net console */ -static void e1000_netpoll (struct net_device *dev); +static void e1000_netpoll (struct net_device *netdev); #endif struct notifier_block e1000_notifier_reboot = { @@ -181,7 +181,6 @@ struct notifier_block e1000_notifier_reb extern void e1000_check_options(struct e1000_adapter *adapter); - static struct pci_driver e1000_driver = { .name = e1000_driver_name, .id_table = e1000_pci_tbl, @@ -336,10 +335,10 @@ e1000_reset(struct e1000_adapter *adapte E1000_WRITE_REG(&adapter->hw, PBA, pba); /* flow control settings */ - adapter->hw.fc_high_water = - (pba << E1000_PBA_BYTES_SHIFT) - E1000_FC_HIGH_DIFF; - adapter->hw.fc_low_water = - (pba << E1000_PBA_BYTES_SHIFT) - E1000_FC_LOW_DIFF; + adapter->hw.fc_high_water = (pba << E1000_PBA_BYTES_SHIFT) - + E1000_FC_HIGH_DIFF; + adapter->hw.fc_low_water = (pba << E1000_PBA_BYTES_SHIFT) - + E1000_FC_LOW_DIFF; adapter->hw.fc_pause_time = E1000_FC_PAUSE_TIME; adapter->hw.fc_send_xon = 1; adapter->hw.fc = adapter->hw.original_fc; @@ -424,8 +423,8 @@ e1000_probe(struct pci_dev *pdev, adapter->msg_enable = (1 << debug) - 1; rtnl_lock(); - /* we need to set the name early since the DPRINTK macro needs it set */ - if (dev_alloc_name(netdev, netdev->name) < 0) + /* we need to set the name early for the DPRINTK macro */ + if(dev_alloc_name(netdev, netdev->name) < 0) goto err_free_unlock; mmio_start = pci_resource_start(pdev, BAR_0); @@ -583,10 +582,9 @@ e1000_probe(struct pci_dev *pdev, adapter->wol |= E1000_WUFC_MAG; /* reset the hardware with the new settings */ - e1000_reset(adapter); - /* since we are holding the rtnl lock already, call the no-lock version */ + /* We're already holding the rtnl lock; call the no-lock version */ if((err = register_netdevice(netdev))) goto err_register; @@ -677,7 +675,7 @@ e1000_sw_init(struct e1000_adapter *adap /* identify the MAC */ - if (e1000_set_mac_type(hw)) { + if(e1000_set_mac_type(hw)) { DPRINTK(PROBE, ERR, "Unknown MAC Type\n"); return -EIO; } @@ -975,7 +973,9 @@ e1000_setup_rctl(struct e1000_adapter *a else rctl &= ~E1000_RCTL_SBP; + /* Setup buffer sizes */ rctl &= ~(E1000_RCTL_SZ_4096); + rctl |= (E1000_RCTL_BSEX | E1000_RCTL_LPE); switch (adapter->rx_buffer_len) { case E1000_RXBUFFER_2048: default: @@ -983,13 +983,13 @@ e1000_setup_rctl(struct e1000_adapter *a rctl &= ~(E1000_RCTL_BSEX | E1000_RCTL_LPE); break; case E1000_RXBUFFER_4096: - rctl |= E1000_RCTL_SZ_4096 | E1000_RCTL_BSEX | E1000_RCTL_LPE; + rctl |= E1000_RCTL_SZ_4096; break; case E1000_RXBUFFER_8192: - rctl |= E1000_RCTL_SZ_8192 | E1000_RCTL_BSEX | E1000_RCTL_LPE; + rctl |= E1000_RCTL_SZ_8192; break; case E1000_RXBUFFER_16384: - rctl |= E1000_RCTL_SZ_16384 | E1000_RCTL_BSEX | E1000_RCTL_LPE; + rctl |= E1000_RCTL_SZ_16384; break; } @@ -1011,13 +1011,11 @@ e1000_configure_rx(struct e1000_adapter uint32_t rctl; uint32_t rxcsum; - /* make sure receives are disabled while setting up the descriptors */ - + /* disable receives while setting up the descriptors */ rctl = E1000_READ_REG(&adapter->hw, RCTL); E1000_WRITE_REG(&adapter->hw, RCTL, rctl & ~E1000_RCTL_EN); /* set the Receive Delay Timer Register */ - E1000_WRITE_REG(&adapter->hw, RDTR, adapter->rx_int_delay); if(adapter->hw.mac_type >= e1000_82540) { @@ -1028,7 +1026,6 @@ e1000_configure_rx(struct e1000_adapter } /* Setup the Base and Length of the Rx Descriptor Ring */ - E1000_WRITE_REG(&adapter->hw, RDBAL, (rdba & 0x00000000ffffffffULL)); E1000_WRITE_REG(&adapter->hw, RDBAH, (rdba >> 32)); @@ -1047,7 +1044,6 @@ e1000_configure_rx(struct e1000_adapter } /* Enable Receives */ - E1000_WRITE_REG(&adapter->hw, RCTL, rctl); } @@ -1095,9 +1091,9 @@ e1000_clean_tx_ring(struct e1000_adapter if(buffer_info->skb) { pci_unmap_page(pdev, - buffer_info->dma, - buffer_info->length, - PCI_DMA_TODEVICE); + buffer_info->dma, + buffer_info->length, + PCI_DMA_TODEVICE); dev_kfree_skb(buffer_info->skb); @@ -1163,12 +1159,11 @@ e1000_clean_rx_ring(struct e1000_adapter if(buffer_info->skb) { pci_unmap_single(pdev, - buffer_info->dma, - buffer_info->length, - PCI_DMA_FROMDEVICE); + buffer_info->dma, + buffer_info->length, + PCI_DMA_FROMDEVICE); dev_kfree_skb(buffer_info->skb); - buffer_info->skb = NULL; } } @@ -1334,7 +1329,8 @@ e1000_set_multi(struct net_device *netde e1000_leave_82542_rst(adapter); } -/* need to wait a few seconds after link up to get diagnostic information from the phy */ +/* Need to wait a few seconds after link up to get diagnostic information from + * the phy */ static void e1000_update_phy_info(unsigned long data) @@ -1442,7 +1438,7 @@ e1000_watchdog(unsigned long data) adapter->tpt_old = adapter->stats.tpt; adapter->hw.collision_delta = adapter->stats.colc - adapter->colc_old; adapter->colc_old = adapter->stats.colc; - + adapter->gorcl = adapter->stats.gorcl - adapter->gorcl_old; adapter->gorcl_old = adapter->stats.gorcl; adapter->gotcl = adapter->stats.gotcl - adapter->gotcl_old; @@ -1590,7 +1586,6 @@ e1000_tx_map(struct e1000_adapter *adapt unsigned int f; len -= skb->data_len; - i = tx_ring->next_to_use; while(len) { @@ -1662,10 +1639,11 @@ e1000_tx_map(struct e1000_adapter *adapt if(unlikely(++i == tx_ring->count)) i = 0; } } + i = (i == 0) ? tx_ring->count - 1 : i - 1; tx_ring->buffer_info[i].skb = skb; tx_ring->buffer_info[first].next_to_watch = i; - + return count; } @@ -1756,7 +1752,7 @@ no_fifo_stall_required: return 0; } -#define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1 ) +#define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1 ) static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev) { @@ -1764,11 +1744,11 @@ e1000_xmit_frame(struct sk_buff *skb, st unsigned int first, max_per_txd = E1000_MAX_DATA_PER_TXD; unsigned int max_txd_pwr = E1000_MAX_TXD_PWR; unsigned int tx_flags = 0; - unsigned long flags; unsigned int len = skb->len; - int count = 0; - unsigned int mss = 0; + unsigned long flags; unsigned int nr_frags = 0; + unsigned int mss = 0; + int count = 0; unsigned int f; nr_frags = skb_shinfo(skb)->nr_frags; len -= skb->data_len; @@ -1780,7 +1744,7 @@ #ifdef NETIF_F_TSO mss = skb_shinfo(skb)->tso_size; - /* The controller does a simple calculation to + /* The controller does a simple calculation to * make sure there is enough room in the FIFO before * initiating the DMA for each buffer. The calc is: * 4 = ceil(buffer len/mss). To make sure we don't @@ -1790,15 +1769,16 @@ e1000_xmit_frame(struct sk_buff *skb, st max_per_txd = min(mss << 2, max_per_txd); max_txd_pwr = fls(max_per_txd) - 1; } + if((mss) || (skb->ip_summed == CHECKSUM_HW)) count++; - count++; /*for sentinel desc*/ + count++; /* for sentinel desc */ #else if(skb->ip_summed == CHECKSUM_HW) count++; #endif - count += TXD_USE_COUNT(len, max_txd_pwr); + if(adapter->pcix_82544) count++; @@ -1805,18 +1769,20 @@ nr_frags = skb_shinfo(skb)->nr_frags; for(f = 0; f < nr_frags; f++) count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size, - max_txd_pwr); + max_txd_pwr); if(adapter->pcix_82544) count += nr_frags; - + spin_lock_irqsave(&adapter->tx_lock, flags); - /* need: count + 2 desc gap to keep tail from touching + + /* need: count + 2 desc gap to keep tail from touching * head, otherwise try next time */ - if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2 ) { + if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2) { netif_stop_queue(netdev); spin_unlock_irqrestore(&adapter->tx_lock, flags); return 1; } + spin_unlock_irqrestore(&adapter->tx_lock, flags); if(unlikely(adapter->hw.mac_type == e1000_82547)) { @@ -1839,8 +1769,8 @@ else if(likely(e1000_tx_csum(adapter, skb))) tx_flags |= E1000_TX_FLAGS_CSUM; - e1000_tx_queue(adapter, - e1000_tx_map(adapter, skb, first, max_per_txd, nr_frags, mss), + e1000_tx_queue(adapter, + e1000_tx_map(adapter, skb, first, max_per_txd, nr_frags, mss), tx_flags); netdev->trans_start = jiffies; @@ -1927,7 +1908,6 @@ e1000_change_mtu(struct net_device *netd } if(old_mtu != adapter->rx_buffer_len && netif_running(netdev)) { - e1000_down(adapter); e1000_up(adapter); } @@ -2181,8 +2179,8 @@ e1000_clean(struct net_device *netdev, i return (work_done >= work_to_do); } -#endif +#endif /** * e1000_clean_tx_irq - Reclaim resources after transmit completes * @adapter: board private structure @@ -2199,31 +2175,25 @@ e1000_clean_tx_irq(struct e1000_adapter unsigned int i, eop; boolean_t cleaned = FALSE; - i = tx_ring->next_to_clean; eop = tx_ring->buffer_info[i].next_to_watch; eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { - for(cleaned = FALSE; !cleaned; ) { tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; - if(likely(buffer_info->dma)) { pci_unmap_page(pdev, buffer_info->dma, buffer_info->length, PCI_DMA_TODEVICE); - buffer_info->dma = 0; } if(buffer_info->skb) { - dev_kfree_skb_any(buffer_info->skb); - buffer_info->skb = NULL; } @@ -2253,7 +2245,7 @@ e1000_clean_tx_irq(struct e1000_adapter } /** - * e1000_clean_rx_irq - Send received data up the network stack, + * e1000_clean_rx_irq - Send received data up the network stack * @adapter: board private structure **/ @@ -2282,14 +2274,11 @@ e1000_clean_rx_irq(struct e1000_adapter while(rx_desc->status & E1000_RXD_STAT_DD) { buffer_info = &rx_ring->buffer_info[i]; - #ifdef CONFIG_E1000_NAPI if(*work_done >= work_to_do) break; - (*work_done)++; #endif - cleaned = TRUE; pci_unmap_single(pdev, @@ -2300,40 +2276,27 @@ e1000_clean_rx_irq(struct e1000_adapter skb = buffer_info->skb; length = le16_to_cpu(rx_desc->length); - if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) { /* All receives must fit into a single buffer */ - - E1000_DBG("%s: Receive packet consumed multiple" " buffers\n", netdev->name); dev_kfree_skb_irq(skb); - - goto next_desc; } - if(unlikely(rx_desc->errors & E1000_RXD_ERR_FRAME_ERR_MASK)) { last_byte = *(skb->data + length - 1); - if(TBI_ACCEPT(&adapter->hw, rx_desc->status, rx_desc->errors, length, last_byte)) { - spin_lock_irqsave(&adapter->stats_lock, flags); - e1000_tbi_adjust_stats(&adapter->hw, &adapter->stats, length, skb->data); - spin_unlock_irqrestore(&adapter->stats_lock, flags); length--; } else { - dev_kfree_skb_irq(skb); - - goto next_desc; } } @@ -2349,8 +2330,8 @@ e1000_clean_rx_irq(struct e1000_adapter if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_receive_skb(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & - E1000_RXD_SPC_VLAN_MASK)); + le16_to_cpu(rx_desc->special & + E1000_RXD_SPC_VLAN_MASK)); } else { netif_receive_skb(skb); } @@ -2358,7 +2330,7 @@ if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_rx(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & + le16_to_cpu(rx_desc->special & E1000_RXD_SPC_VLAN_MASK)); } else { netif_rx(skb); @@ -2404,7 +2384,7 @@ e1000_alloc_rx_buffers(struct e1000_adap while(!buffer_info->skb) { skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len); - if(!skb) { + if(unlikely(!skb)) { /* Better luck next round */ break; } @@ -2419,11 +2403,10 @@ e1000_alloc_rx_buffers(struct e1000_adap buffer_info->skb = skb; buffer_info->length = adapter->rx_buffer_len; - buffer_info->dma = - pci_map_single(pdev, - skb->data, - adapter->rx_buffer_len, - PCI_DMA_FROMDEVICE); + buffer_info->dma = pci_map_single(pdev, + skb->data, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); @@ -2557,24 +2544,24 @@ e1000_mii_ioctl(struct net_device *netde return -EFAULT; mii_reg = data->val_in; if (e1000_write_phy_reg(&adapter->hw, data->reg_num, - data->val_in)) + mii_reg)) return -EIO; if (adapter->hw.phy_type == e1000_phy_m88) { switch (data->reg_num) { case PHY_CTRL: - if(data->val_in & MII_CR_AUTO_NEG_EN) { if(mii_reg & MII_CR_POWER_DOWN) break; + if(mii_reg & MII_CR_AUTO_NEG_EN) { adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = 0x2F; } else { - if (data->val_in & 0x40) + if (mii_reg & 0x40) spddplx = SPEED_1000; - else if (data->val_in & 0x2000) + else if (mii_reg & 0x2000) spddplx = SPEED_100; else spddplx = SPEED_10; - spddplx += (data->val_in & 0x100) + spddplx += (mii_reg & 0x100) ? FULL_DUPLEX : HALF_DUPLEX; retval = e1000_set_spd_dplx(adapter, @@ -2643,7 +2618,7 @@ e1000_rx_checksum(struct e1000_adapter * skb->ip_summed = CHECKSUM_NONE; adapter->hw_csum_err++; } else { - /* TCP checksum is good */ + /* TCP checksum is good */ skb->ip_summed = CHECKSUM_UNNECESSARY; adapter->hw_csum_good++; } @@ -2705,26 +2680,22 @@ e1000_vlan_rx_register(struct net_device if(grp) { /* enable VLAN tag insert/strip */ - ctrl = E1000_READ_REG(&adapter->hw, CTRL); ctrl |= E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, CTRL, ctrl); /* enable VLAN receive filtering */ - rctl = E1000_READ_REG(&adapter->hw, RCTL); rctl |= E1000_RCTL_VFE; rctl &= ~E1000_RCTL_CFIEN; E1000_WRITE_REG(&adapter->hw, RCTL, rctl); } else { /* disable VLAN tag insert/strip */ - ctrl = E1000_READ_REG(&adapter->hw, CTRL); ctrl &= ~E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, CTRL, ctrl); /* disable VLAN filtering */ - rctl = E1000_READ_REG(&adapter->hw, RCTL); rctl &= ~E1000_RCTL_VFE; E1000_WRITE_REG(&adapter->hw, RCTL, rctl); @@ -2740,7 +2711,6 @@ e1000_vlan_rx_add_vid(struct net_device uint32_t vfta, index; /* add VID to filter table */ - index = (vid >> 5) & 0x7F; vfta = E1000_READ_REG_ARRAY(&adapter->hw, VFTA, index); vfta |= (1 << (vid & 0x1F)); @@ -2760,8 +2730,7 @@ e1000_vlan_rx_kill_vid(struct net_device e1000_irq_enable(adapter); - /* remove VID from filter table*/ - + /* remove VID from filter table */ index = (vid >> 5) & 0x7F; vfta = E1000_READ_REG_ARRAY(&adapter->hw, VFTA, index); vfta &= ~(1 << (vid & 0x1F)); @@ -2950,12 +2919,12 @@ e1000_resume(struct pci_dev *pdev) * without having to re-enable interrupts. It's not called while * the interrupt routine is executing. */ - -static void e1000_netpoll (struct net_device *dev) +static void +e1000_netpoll (struct net_device *netdev) { - struct e1000_adapter *adapter = dev->priv; + struct e1000_adapter *adapter = netdev->priv; disable_irq(adapter->pdev->irq); - e1000_intr (adapter->pdev->irq, dev, NULL); + e1000_intr(adapter->pdev->irq, netdev, NULL); enable_irq(adapter->pdev->irq); } #endif diff -up linux-2.4/drivers/net/e1000/e1000_param.c linux-2.4/drivers/net/e1000.new/e1000_param.c --- linux-2.4/drivers/net/e1000/e1000_param.c 2004-07-28 08:47:08.179581696 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_param.c 2004-07-28 08:47:09.574369656 -0700 @@ -235,7 +235,7 @@ struct e1000_option { static int __devinit e1000_validate_option(int *value, struct e1000_option *opt, - struct e1000_adapter *adapter) + struct e1000_adapter *adapter) { if(*value == OPTION_UNSET) { *value = opt->def; @@ -256,7 +256,7 @@ e1000_validate_option(int *value, struct case range_option: if(*value >= opt->arg.r.min && *value <= opt->arg.r.max) { DPRINTK(PROBE, INFO, - "%s set to %i\n", opt->name, *value); + "%s set to %i\n", opt->name, *value); return 0; } break; @@ -449,8 +449,7 @@ e1000_check_options(struct e1000_adapter DPRINTK(PROBE, INFO, "%s turned off\n", opt.name); break; case 1: - DPRINTK(PROBE, INFO, - "%s set to dynamic mode\n", opt.name); + DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", opt.name); break; default: e1000_validate_option(&adapter->itr, &opt, adapter); @@ -493,8 +492,9 @@ e1000_check_fiber_options(struct e1000_a "parameter ignored\n"); } if((AutoNeg[bd] != OPTION_UNSET) && (AutoNeg[bd] != 0x20)) { - DPRINTK(PROBE, INFO, "AutoNeg other than Full/1000 is " - "not valid for fiber adapters, parameter ignored\n"); + DPRINTK(PROBE, INFO, "AutoNeg other than 1000/Full is " + "not valid for fiber adapters, " + "parameter ignored\n"); } } @@ -611,24 +611,24 @@ e1000_check_copper_options(struct e1000_ break; case HALF_DUPLEX: DPRINTK(PROBE, INFO, "Half Duplex specified without Speed\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at Half Duplex only\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "Half Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | ADVERTISE_100_HALF; break; case FULL_DUPLEX: DPRINTK(PROBE, INFO, "Full Duplex specified without Speed\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at Full Duplex only\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_FULL | ADVERTISE_100_FULL | ADVERTISE_1000_FULL; break; case SPEED_10: - DPRINTK(PROBE, INFO, - "10 Mbps Speed specified without Duplex\n"); + DPRINTK(PROBE, INFO, "10 Mbps Speed specified " + "without Duplex\n"); DPRINTK(PROBE, INFO, "Using Autonegotiation at 10 Mbps only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | @@ -647,10 +647,10 @@ e1000_check_copper_options(struct e1000_ adapter->hw.autoneg_advertised = 0; break; case SPEED_100: - DPRINTK(PROBE, INFO, - "100 Mbps Speed specified without Duplex\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at 100 Mbps only\n"); + DPRINTK(PROBE, INFO, "100 Mbps Speed specified " + "without Duplex\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "100 Mbps only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_100_HALF | ADVERTISE_100_FULL; @@ -668,10 +668,11 @@ e1000_check_copper_options(struct e1000_ adapter->hw.autoneg_advertised = 0; break; case SPEED_1000: + DPRINTK(PROBE, INFO, "1000 Mbps Speed specified without " + "Duplex\n"); DPRINTK(PROBE, INFO, - "1000 Mbps Speed specified without Duplex\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + "Using Autonegotiation at 1000 Mbps " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; @@ -679,7 +680,8 @@ e1000_check_copper_options(struct e1000_ DPRINTK(PROBE, INFO, "Half Duplex is not supported at 1000 Mbps\n"); DPRINTK(PROBE, INFO, - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + "Using Autonegotiation at 1000 Mbps " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; @@ -696,8 +698,8 @@ e1000_check_copper_options(struct e1000_ /* Speed, AutoNeg and MDI/MDI-X must all play nice */ if (e1000_validate_mdi_setting(&(adapter->hw)) < 0) { DPRINTK(PROBE, INFO, - "Speed, AutoNeg and MDI-X specifications are " - "incompatible. Setting MDI-X to a compatible value.\n"); + "Speed, AutoNeg and MDI-X specifications are " + "incompatible. Setting MDI-X to a compatible value.\n"); } } Only in linux-2.4/drivers/net/e1000.new: kcompat_ethtool.c From ganesh.venkatesan@intel.com Thu Jul 29 08:49:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:49:58 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFnlfJ025275 for ; Thu, 29 Jul 2004 08:49:48 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by fmsfmr004.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFpQ40027474; Thu, 29 Jul 2004 15:51:26 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFq8sF002996; Thu, 29 Jul 2004 15:52:23 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908493806536 ; Thu, 29 Jul 2004 08:49:38 -0700 Date: Thu, 29 Jul 2004 08:33:32 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 2/6 2.5] e100 - Support for Intel(R) PRO/100 VE Network Connection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1209 Lines: 30 --- linux-2.5/drivers/net/e100.c 2004-07-29 00:25:01.873679848 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-07-29 00:26:04.553151120 -0700 @@ -201,6 +201,8 @@ static struct pci_device_id e100_id_tabl INTEL_8255X_ETHERNET_DEVICE(0x1053, 5), INTEL_8255X_ETHERNET_DEVICE(0x1054, 5), INTEL_8255X_ETHERNET_DEVICE(0x1055, 5), + INTEL_8255X_ETHERNET_DEVICE(0x1056, 5), + INTEL_8255X_ETHERNET_DEVICE(0x1057, 5), INTEL_8255X_ETHERNET_DEVICE(0x1064, 6), INTEL_8255X_ETHERNET_DEVICE(0x1065, 6), INTEL_8255X_ETHERNET_DEVICE(0x1066, 6), @@ -242,6 +244,7 @@ enum phy { phy_nsc_tx = 0x5C002000, phy_82562_et = 0x033002A8, phy_82562_em = 0x032002A8, + phy_82562_ek = 0x031002A8, phy_82562_eh = 0x017002A8, phy_unknown = 0xFFFFFFFF, }; @@ -1641,7 +1644,7 @@ static int e100_change_mtu(struct net_de static int e100_asf(struct nic *nic) { /* ASF can be enabled from eeprom */ - return((nic->pdev->device >= 0x1050) && (nic->pdev->device <= 0x1055) && + return((nic->pdev->device >= 0x1050) && (nic->pdev->device <= 0x1057) && (nic->eeprom[eeprom_config_asf] & eeprom_asf) && !(nic->eeprom[eeprom_config_asf] & eeprom_gcl) && ((nic->eeprom[eeprom_smbus_addr] & 0xFF) != 0xFE)); From ganesh.venkatesan@intel.com Thu Jul 29 08:50:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 08:50:11 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TFo3Rp025601 for ; Thu, 29 Jul 2004 08:50:03 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TFqWTL023323; Thu, 29 Jul 2004 15:52:35 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TFq8sN002996; Thu, 29 Jul 2004 15:52:35 GMT Received: from Westville2.jf.intel.com ([134.134.3.161]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072908495106556 ; Thu, 29 Jul 2004 08:49:51 -0700 Date: Thu, 29 Jul 2004 08:33:44 -0700 (PDT) From: ganesh.venkatesan@intel.com X-X-Sender: gvenkate@westville2.jf.intel.com Reply-To: ganesh.venkatesan@intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [PATCH 0/1 2.4] e100 driver update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 7300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 355 Lines: 11 Jeff: This is a huge patch to replace the 2.3.x e100 driver with the 3.0.x version in the 2.4 kernel. The patch includes (in addition to the driver source) updates to Documentation/networking/e100.txt, drivers/net/Config.in and Documentation/Configure.help. The driver is functionally the same as the one included in the 2.5 tree. thanks, ganesh. From hadi@cyberus.ca Thu Jul 29 09:03:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 09:03:27 -0700 (PDT) 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 i6TG3KIm029940 for ; Thu, 29 Jul 2004 09:03:20 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BqDNC-0006Le-E4 for netdev@oss.sgi.com; Thu, 29 Jul 2004 12:03:14 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BqDNA-0003Cv-Ua; Thu, 29 Jul 2004 12:03:13 -0400 Subject: RE: [PATCH] (3/4) bridge linkstate handling From: jamal Reply-To: hadi@cyberus.ca To: "Eble, Dan" Cc: Stephen Hemminger , bridge@osdl.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1091116989.1033.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 12:03:10 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2257 Lines: 52 On Thu, 2004-07-29 at 11:11, Eble, Dan wrote: > > -----Original Message----- > > From: jamal [mailto:hadi@cyberus.ca] > > Your main problem there would be STP convergence time. Transfering the > > packet to user space and reacting should be several factors > > of magnitude faster than it takes STP to converge. > > The STP state should stay in the kernel. Control of it and > > BPDU handling is what i am suggesting to take out. > > Is the time it takes STP to converge really the issue in this case? > When a port loses and then regains carrier, it needs to enter the > Blocking state without delay. I must have misunderstood Stevens patch then. Are you saying it opens a port that was previously blocked because a link was reinserted? Or the other way round: it would put a port that was previously blocked into forwarding state because a previously forwarding link had a link going down? I think all this needs to be policy driven. > If the carrier state change were handled > by a daemon, the bridge driver would have some time to transmit or > receive packets via that port before the daemon could tell it to block > the port, wouldn't it? Refer to my note above; opening or closing ports should be serialized via user space. Let me clarify. I think there are two issues at stake: 1) STP state - derived from the BPDUs. The state transition machinery should run in kernel. The inteligence to transition the state machine should reside in user space (call it control plane if it makes it more palatable). 2) Other inputs like Links going up or down or VRRP state changes for HA or somebody farting (pardon my language, just trying to drive a point) also need to feed to the same policy decision making engine. The result of the policy engine is a STP state transition for a port. For the policy decision you need to make certain assumptions about the STP topology i.e you need to have some knowledge of what connects to you. Or you need to compute such things. All such decisions in my opinion belong to some policy decision engine which should reside in user space. CISCOs UplinkFast, portFast (assumes a end host connected to port), RSTP, dynamic 802.1w or whatever new "innovation" comes up ends being very easy to add. cheers, jamal From jgarzik@pobox.com Thu Jul 29 09:05:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 09:05:59 -0700 (PDT) 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 i6TG5roP030650 for ; Thu, 29 Jul 2004 09:05:54 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BqDPh-0007JA-NR; Thu, 29 Jul 2004 17:05:49 +0100 Message-ID: <4109204D.6010507@pobox.com> Date: Thu, 29 Jul 2004 12:05:33 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ganesh.venkatesan@intel.com CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/12 2.5] e1000 - ethtool support (register dump, interrupt test, cleanup) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 29 Lines: 2 applied 12 patches to 2.6.x From jgarzik@pobox.com Thu Jul 29 09:10:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 09:10:39 -0700 (PDT) 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 i6TGAXnl031561 for ; Thu, 29 Jul 2004 09:10:34 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BqDUD-0007M9-W7; Thu, 29 Jul 2004 17:10:30 +0100 Message-ID: <4109216A.2050006@pobox.com> Date: Thu, 29 Jul 2004 12:10:18 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ganesh.venkatesan@intel.com CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/12 2.4] e1000 - ethtool support (register dump, interrupt test, cleanup) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 33 Lines: 2 applied all 12 patches to 2.4.x From jgarzik@pobox.com Thu Jul 29 09:18:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 09:18:18 -0700 (PDT) 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 i6TGIC4b032735 for ; Thu, 29 Jul 2004 09:18:12 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BqDbc-0007bk-9i; Thu, 29 Jul 2004 17:18:08 +0100 Message-ID: <41092334.2050004@pobox.com> Date: Thu, 29 Jul 2004 12:17:56 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ganesh.venkatesan@intel.com CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/6 2.5] e100 - restore speed/duplex/autoneg settings after diagnostic test References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 32 Lines: 2 applied all 6 patches to 2.6.x From shemminger@osdl.org Thu Jul 29 09:32:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 09:32:22 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TGWGD6000814 for ; Thu, 29 Jul 2004 09:32:16 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6TGVL111675; Thu, 29 Jul 2004 09:31:21 -0700 Date: Thu, 29 Jul 2004 09:31:20 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (3/4) bridge linkstate handling Message-Id: <20040729093120.58258ba9@dell_ss3.pdx.osdl.net> In-Reply-To: <1091103164.1046.591.camel@jzny.localdomain> References: <20040728162413.0de73ea3@dell_ss3.pdx.osdl.net> <1091103164.1046.591.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 844 Lines: 19 On 29 Jul 2004 08:12:44 -0400 jamal wrote: > On Wed, 2004-07-28 at 19:24, Stephen Hemminger wrote: > > This makes bridge port status reflect both the state of the interface > > from software (up/down) and the carrier. It makes STP handle link failure > > (cable breakage, etc). The original concept comes from a > > Mark Ruijter who implemented it differently. > > My way is simpler and requires no polling. > > > > Obviously, this link state detection will only work if the network card > > handles the events properly. > > > > nice. Does this entrench STP further in the kernel? > Still planning to move it out to user space? The same logic would apply in user space, it would just use the netlink events that come from netlink messages (RTM_NEWLINK) rather than notifier chain (NETDEV_CHANGE). From DanE@aiinet.com Thu Jul 29 09:36:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 09:36:52 -0700 (PDT) Received: from aiexchange.ai.aiinet.com (ai181-26.aiinet.com [205.245.181.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TGakJi001276 for ; Thu, 29 Jul 2004 09:36:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] (3/4) bridge linkstate handling Date: Thu, 29 Jul 2004 12:36:38 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] (3/4) bridge linkstate handling Thread-Index: AcR1hY0W3lVJqpgiTWaiHUJVHXbchwAAlbgQ From: "Eble, Dan" To: Cc: "Stephen Hemminger" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6TGakJi001276 X-archive-position: 7306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: DanE@aiinet.com Precedence: bulk X-list: netdev Content-Length: 1203 Lines: 28 > I must have misunderstood Stevens patch then. Are you saying > it opens a > port that was previously blocked because a link was reinserted? > Or the other way round: it would put a port that was > previously blocked > into forwarding state because a previously forwarding link had a link > going down? > I think all this needs to be policy driven. His patch ensures that when a port regains carrier, it is Blocked. Before the patch, a Forwarding port would remain Forwarding if the other end of the cable were unplugged and then plugged into some other place. > 2) Other inputs like Links going up or down or VRRP state > changes for HA > or somebody farting (pardon my language, just trying to drive a point) > also need to feed to the same policy decision making engine. > The result > of the policy engine is a STP state transition for a port. I think I see. So then when an event happens that might affect the port state, the bridge should temporarily block traffic on the port (in case the policy daemon will tell it to start blocking) and wait for the daemon to respond with a "start blocking" or "continue forwarding" decision. Is that the idea, or have I completely misunderstood? From SRS0+369673ad07e67e9b823b+340+infradead.org+hch@phoenix-185026.srs.infradead.org Thu Jul 29 10:50:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 10:50:56 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6THolhY003394 for ; Thu, 29 Jul 2004 10:50:50 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BqF2w-0001Zg-Eu; Thu, 29 Jul 2004 18:50:26 +0100 Date: Thu, 29 Jul 2004 18:50:26 +0100 From: Christoph Hellwig To: ganesh.venkatesan@intel.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 3/12 2.4] e1000 - use vmalloc for data structures not shared with h/w Message-ID: <20040729185026.A6033@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ganesh.venkatesan@intel.com on Thu, Jul 29, 2004 at 08:29:37AM -0700 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev This sounds rather bogus. vmallocspace is a scare ressource, don't use it unless nessecary. From shemminger@osdl.org Thu Jul 29 10:59:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 10:59:56 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6THxlmF003818 for ; Thu, 29 Jul 2004 10:59:48 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6THxV102324; Thu, 29 Jul 2004 10:59:31 -0700 Date: Thu, 29 Jul 2004 10:59:31 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) propgate bridge internal MTU changes Message-Id: <20040729105931.25815479@dell_ss3.pdx.osdl.net> In-Reply-To: <20040728191724.4afacdce.davem@redhat.com> References: <20040728153725.7ace281c@dell_ss3.pdx.osdl.net> <20040728191724.4afacdce.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Follow up to earlier RCU patch. Since now using RCU, need to use deferred free. Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2004-07-29 11:00:07 -07:00 +++ b/net/bridge/br_fdb.c 2004-07-29 11:00:07 -07:00 @@ -217,11 +217,18 @@ return fdb; } +static void fdb_rcu_free(struct rcu_head *head) +{ + struct net_bridge_fdb_entry *ent + = container_of(head, struct net_bridge_fdb_entry, rcu); + kmem_cache_free(br_fdb_cache, ent); +} +/* Set entry up for deletion with RCU */ void br_fdb_put(struct net_bridge_fdb_entry *ent) { if (atomic_dec_and_test(&ent->use_count)) - kmem_cache_free(br_fdb_cache, ent); + call_rcu(&ent->rcu, fdb_rcu_free); } /* diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h 2004-07-29 11:00:07 -07:00 +++ b/net/bridge/br_private.h 2004-07-29 11:00:07 -07:00 @@ -46,7 +46,10 @@ { struct hlist_node hlist; struct net_bridge_port *dst; - struct list_head age_list; + union { + struct list_head age_list; + struct rcu_head rcu; + }; atomic_t use_count; unsigned long ageing_timer; mac_addr addr; From ganesh.venkatesan@intel.com Thu Jul 29 11:17:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 11:18:05 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TIHvuE004506 for ; Thu, 29 Jul 2004 11:17:58 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TBILT7026178; Thu, 29 Jul 2004 11:18:33 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TIJUVF013346; Thu, 29 Jul 2004 18:19:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072911172505317 ; Thu, 29 Jul 2004 11:17:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jul 2004 11:17:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH 3/12 2.4] e1000 - use vmalloc for data structures not shared with h/w Date: Thu, 29 Jul 2004 11:17:08 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E01F23824@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 3/12 2.4] e1000 - use vmalloc for data structures not shared with h/w Thread-Index: AcR1lK+7UxSfm13fSLqBLIDNWSSQ3gAA2G5w From: "Venkatesan, Ganesh" To: "Christoph Hellwig" Cc: , X-OriginalArrivalTime: 29 Jul 2004 18:17:10.0346 (UTC) FILETIME=[43A322A0:01C47598] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6TIHvuE004506 X-archive-position: 7309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Vmalloc space is less scarce than kmalloc space. Am I right? This patch trades kmalloc space for vmalloc space. Ganesh. -----Original Message----- From: Christoph Hellwig [mailto:hch@infradead.org] Sent: Thursday, July 29, 2004 10:50 AM To: Venkatesan, Ganesh Cc: jgarzik@pobox.com; netdev@oss.sgi.com Subject: Re: [PATCH 3/12 2.4] e1000 - use vmalloc for data structures not shared with h/w This sounds rather bogus. vmallocspace is a scare ressource, don't use it unless nessecary. From SRS0+07c5e5d7ca44fc160493+340+infradead.org+hch@phoenix-192521.srs.infradead.org Thu Jul 29 11:25:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 11:25:37 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TIPU0x004937 for ; Thu, 29 Jul 2004 11:25:31 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BqFah-0001cg-Js; Thu, 29 Jul 2004 19:25:19 +0100 Date: Thu, 29 Jul 2004 19:25:19 +0100 From: Christoph Hellwig To: "Venkatesan, Ganesh" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 3/12 2.4] e1000 - use vmalloc for data structures not shared with h/w Message-ID: <20040729192519.A6235@infradead.org> References: <468F3FDA28AA87429AD807992E22D07E01F23824@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01F23824@orsmsx408>; from ganesh.venkatesan@intel.com on Thu, Jul 29, 2004 at 11:17:08AM -0700 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Thu, Jul 29, 2004 at 11:17:08AM -0700, Venkatesan, Ganesh wrote: > Vmalloc space is less scarce than kmalloc space. Am I right? This patch > trades kmalloc space for vmalloc space. No, it's not. vmalloc needs virtual space that's rather limited (e.g. 64MB on PAE x86) in addition to physical memory. Unless you do really big allocations stay away from vmalloc. From shemminger@osdl.org Thu Jul 29 11:29:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 11:29:54 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TITmhQ005351 for ; Thu, 29 Jul 2004 11:29:48 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6TITY110603; Thu, 29 Jul 2004 11:29:34 -0700 Date: Thu, 29 Jul 2004 11:29:34 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6] BIC tcp congestion calculation timestamp Message-Id: <20040729112934.32002c24@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Small change to bictcp based on the BIC 1.1 patches for web100. Keep track of last time congestion was computed, and recompute if cwnd changes or every 1/32 of a second. Also changes the initialization location for the parameters. Signed-off-by: Stephen Hemminger diff -urN -X dontdiff linux-2.6/include/linux/tcp.h tcp-2.6/include/linux/tcp.h --- linux-2.6/include/linux/tcp.h 2004-06-23 09:29:47.000000000 -0700 +++ tcp-2.6/include/linux/tcp.h 2004-07-27 10:26:52.000000000 -0700 @@ -420,6 +420,7 @@ __u32 cnt; /* increase cwnd by 1 after this number of ACKs */ __u32 last_max_cwnd; /* last maximium snd_cwnd */ __u32 last_cwnd; /* the last snd_cwnd */ + __u32 last_stamp; /* time when updated last_cwnd */ } bictcp; }; diff -urN -X dontdiff linux-2.6/net/ipv4/tcp_input.c tcp-2.6/net/ipv4/tcp_input.c --- linux-2.6/net/ipv4/tcp_input.c 2004-07-23 09:36:18.000000000 -0700 +++ tcp-2.6/net/ipv4/tcp_input.c 2004-07-28 13:52:50.000000000 -0700 @@ -330,6 +330,15 @@ tp->snd_cwnd_stamp = tcp_time_stamp; } +static void init_bictcp(struct tcp_opt *tp) +{ + tp->bictcp.cnt = 0; + + tp->bictcp.last_max_cwnd = 0; + tp->bictcp.last_cwnd = 0; + tp->bictcp.last_stamp = 0; +} + /* 5. Recalculate window clamp after socket hit its memory bounds. */ static void tcp_clamp_window(struct sock *sk, struct tcp_opt *tp) { @@ -1233,6 +1242,8 @@ tcp_set_ca_state(tp, TCP_CA_Loss); tp->high_seq = tp->frto_highmark; TCP_ECN_queue_cwr(tp); + + init_bictcp(tp); } void tcp_clear_retrans(struct tcp_opt *tp) @@ -2011,10 +2022,12 @@ if (!sysctl_tcp_bic) return tp->snd_cwnd; - if (tp->bictcp.last_cwnd == tp->snd_cwnd) - return tp->bictcp.cnt; /* same cwnd, no update */ - + if (tp->bictcp.last_cwnd == tp->snd_cwnd && + (s32)(tcp_time_stamp - tp->bictcp.last_stamp) <= (HZ>>5)) + return tp->bictcp.cnt; + tp->bictcp.last_cwnd = tp->snd_cwnd; + tp->bictcp.last_stamp = tcp_time_stamp; /* start off normal */ if (tp->snd_cwnd <= sysctl_tcp_bic_low_window) @@ -4612,6 +4625,7 @@ return 1; init_westwood(sk); + init_bictcp(tp); /* Now we have several options: In theory there is * nothing else in the frame. KA9Q has an option to @@ -4635,6 +4649,7 @@ case TCP_SYN_SENT: init_westwood(sk); + init_bictcp(tp); queued = tcp_rcv_synsent_state_process(sk, skb, th, len); if (queued >= 0) diff -urN -X dontdiff linux-2.6/net/ipv4/tcp_minisocks.c tcp-2.6/net/ipv4/tcp_minisocks.c --- linux-2.6/net/ipv4/tcp_minisocks.c 2004-07-23 09:36:18.000000000 -0700 +++ tcp-2.6/net/ipv4/tcp_minisocks.c 2004-07-23 09:48:07.000000000 -0700 @@ -767,9 +767,6 @@ newtp->snd_cwnd = 2; newtp->snd_cwnd_cnt = 0; - newtp->bictcp.cnt = 0; - newtp->bictcp.last_max_cwnd = newtp->bictcp.last_cwnd = 0; - newtp->frto_counter = 0; newtp->frto_highmark = 0; From shemminger@osdl.org Thu Jul 29 11:35:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 11:35:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TIZgcT005731 for ; Thu, 29 Jul 2004 11:35:43 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6TIZM112384; Thu, 29 Jul 2004 11:35:22 -0700 Date: Thu, 29 Jul 2004 11:35:22 -0700 From: Stephen Hemminger To: "David S. Miller" , ralf@linux-mips.org Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH 2.6] convert ROSE to use module_param Message-Id: <20040729113522.30add0e5@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Switch to module_param and the hash list can be local. Signed-off-by: Stephen Hemminger diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c 2004-07-23 13:33:31 -07:00 +++ b/net/rose/af_rose.c 2004-07-23 13:33:31 -07:00 @@ -11,6 +11,7 @@ */ #include #include +#include #include #include #include @@ -57,7 +58,7 @@ int sysctl_rose_maximum_vcs = ROSE_DEFAULT_MAXVC; int sysctl_rose_window_size = ROSE_DEFAULT_WINDOW_SIZE; -HLIST_HEAD(rose_list); +static HLIST_HEAD(rose_list); spinlock_t rose_list_lock = SPIN_LOCK_UNLOCKED; static struct proto_ops rose_proto_ops; @@ -1550,7 +1551,7 @@ } module_init(rose_proto_init); -MODULE_PARM(rose_ndevs, "i"); +module_param(rose_ndevs, int, 0); MODULE_PARM_DESC(rose_ndevs, "number of ROSE devices"); MODULE_AUTHOR("Jonathan Naylor G4KLX "); From shemminger@osdl.org Thu Jul 29 11:37:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 11:37:15 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TIbA6k006046 for ; Thu, 29 Jul 2004 11:37:10 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6TIap112587; Thu, 29 Jul 2004 11:36:51 -0700 Date: Thu, 29 Jul 2004 11:36:51 -0700 From: Stephen Hemminger To: "David S. Miller" , Ralf Baechel Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH 2.6] convert netrom to module_param Message-Id: <20040729113651.6517fe27@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert Netrom to use module_param Signed-off-by: Stephen Hemminger diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c 2004-07-23 13:27:52 -07:00 +++ b/net/netrom/af_netrom.c 2004-07-23 13:27:52 -07:00 @@ -10,6 +10,7 @@ */ #include #include +#include #include #include #include @@ -1451,8 +1452,7 @@ module_init(nr_proto_init); - -MODULE_PARM(nr_ndevs, "i"); +module_param(nr_ndevs, int, 0); MODULE_PARM_DESC(nr_ndevs, "number of NET/ROM devices"); MODULE_AUTHOR("Jonathan Naylor G4KLX "); From hadi@cyberus.ca Thu Jul 29 12:40:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 12:40:18 -0700 (PDT) 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 i6TJeA5m011103 for ; Thu, 29 Jul 2004 12:40:12 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BqGl3-0005QK-Bn for netdev@oss.sgi.com; Thu, 29 Jul 2004 15:40:05 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BqGl1-0000AF-Nc; Thu, 29 Jul 2004 15:40:03 -0400 Subject: RE: [PATCH] (3/4) bridge linkstate handling From: jamal Reply-To: hadi@cyberus.ca To: "Eble, Dan" Cc: Stephen Hemminger , bridge@osdl.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1091130000.1022.185.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Jul 2004 15:40:00 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7314 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 Thu, 2004-07-29 at 12:36, Eble, Dan wrote: > His patch ensures that when a port regains carrier, it is Blocked. > Before the patch, a Forwarding port would remain Forwarding if the other > end of the cable were unplugged and then plugged into some other place. Ok, this is sensible. With a user space control you could probably do more interesting things with that link info. > > I think I see. So then when an event happens that might affect the port > state, the bridge should temporarily block traffic on the port (in case > the policy daemon will tell it to start blocking) and wait for the > daemon to respond with a "start blocking" or "continue forwarding" > decision. Is that the idea, or have I completely misunderstood? Everything is still driven by the STP state machine. So no smartness on the bridge itself; it is just told what to do and it transitions state. On startup, the port is in blocked state. Only passes BPDUs to user space. Based on BPDUs and other input (like link info of say unrelated port) the port state is transitioned. Since all state control is in user space i.e at one location, no loops should happen. Not sure if it makese sense. cheers, jamal From davem@redhat.com Thu Jul 29 14:54:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 14:54:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TLs0IA015404 for ; Thu, 29 Jul 2004 14:54:01 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6TLrqe1023912; Thu, 29 Jul 2004 17:53:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6TLrqa30770; Thu, 29 Jul 2004 17:53:52 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6TLrA3w023345; Thu, 29 Jul 2004 17:53:10 -0400 Date: Thu, 29 Jul 2004 14:51:28 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) propgate bridge internal MTU changes Message-Id: <20040729145128.35791769.davem@redhat.com> In-Reply-To: <20040729105931.25815479@dell_ss3.pdx.osdl.net> References: <20040728153725.7ace281c@dell_ss3.pdx.osdl.net> <20040728191724.4afacdce.davem@redhat.com> <20040729105931.25815479@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Jul 2004 10:59:31 -0700 Stephen Hemminger wrote: > Follow up to earlier RCU patch. Since now using RCU, need to use > deferred free. All bridge patches applied, thanks Stephen. From greearb@candelatech.com Thu Jul 29 15:25:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 15:25:45 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TMPdBG017695 for ; Thu, 29 Jul 2004 15:25:40 -0700 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i6TMdcSb027312 for ; Thu, 29 Jul 2004 15:39:38 -0700 Message-ID: <4109795F.20300@candelatech.com> Date: Thu, 29 Jul 2004 15:25:35 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: Question on TCP_INFO and retransmits. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev The tcp_info structure that is available with getsockopt(...TCP_INFO) has a tcpi_retransmits field and a tcpi_retrans field. I was hoping that one of these would be monatomically incrementing and keep track of all of the retransmits for the socket since it was opened... However, it appears that these counters are reset to zero fairly often, making it difficult or impossible to use them to detect actual TCP retransmits. Is there some other way to detect the number of retransmitted packets? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From scarfboy@gmail.com Thu Jul 29 15:41:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 15:41:20 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TMfB07019292 for ; Thu, 29 Jul 2004 15:41:12 -0700 Received: by mproxy.gmail.com with SMTP id 75so24812rnl for ; Thu, 29 Jul 2004 15:41:03 -0700 (PDT) Received: by 10.38.9.5 with SMTP id 5mr18794rni; Thu, 29 Jul 2004 15:41:03 -0700 (PDT) Message-ID: Date: Fri, 30 Jul 2004 00:41:03 +0200 From: Bart Alewijnse To: netdev@oss.sgi.com Subject: Re: gigabit trouble Cc: linux-kernel@vger.kernel.org In-Reply-To: <20040729210401.A32456@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040729210401.A32456@electric-eye.fr.zoreil.com> X-archive-position: 7317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scarfboy@gmail.com Precedence: bulk X-list: netdev I was going to do an exhaustive test, but because my computer stopped running completely, I'll reply to the one or two bits I can now. On Thu, 29 Jul 2004 21:04:01 +0200, Francois Romieu wrote: > Bart Alewijnse : > [...] > > I run gentoo on both, which until yesterday was 2.6.7-ck5 (on both), > > and currently run 2.6.7-mm6 (again, both), as I saw the suggestion > > somewhere it had better support for the card - something about a new > > net card inferface that's nicer to interrupts. > > NAPI support for r8169 is available in recent -mm kernel and there is > a small (though noticeable) optimization wrt to interrupt disabling. Well, I noticed a max of 6500 interrupts/s on eth1 on both computers, with or without napi - and that 6500 is also the figure of packets per second. So I'm slightly dubious. (notice 6500 *1500 bytes is about 10MB/s) > [...] > > So, question one - how do I see the link speed under linux, and how, > > if at all, do I control it? > > ethtool Thanks. That wasn't the problem - the line speed's a gbit. > [...] > > Disturbingly, in such a linux-to-linux speed test, my new computer > > froze.As in, in text mode, have the screen freeze and apparently be > > half written full of nonsense. > > These messages would be welcome (pen/paper/serial line/image/log file > or whatever). No messages, no oops, no log messages that I noticed. It was video memory corruption in text mode. As to the rest, I'll do it when I revive my computer. Right now, I'm thinking the power supply may be dodgy. I'll see if I can get a minimum to run off my even older 235Watt. But as a note, with two cards, two cdroms and a hard drive less, it was still making the noise. I think it still is now, but since no OS actually boots completely right now, I can't say for sure. I'll do a memtest, that makes sense. --Bart From davem@redhat.com Thu Jul 29 15:57:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 15:57:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TMvEra021119 for ; Thu, 29 Jul 2004 15:57:15 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6TMv4e1007199; Thu, 29 Jul 2004 18:57:04 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6TMv4a18027; Thu, 29 Jul 2004 18:57:04 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6TMuMRN027426; Thu, 29 Jul 2004 18:56:22 -0400 Date: Thu, 29 Jul 2004 15:54:33 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, arekm@pld-linux.org, netdev@oss.sgi.com Subject: Re: [PATCH] pkt_cls.h incompatiables Message-Id: <20040729155433.07d11f23.davem@redhat.com> In-Reply-To: <1091100602.1043.557.camel@jzny.localdomain> References: <20040722134522.4e7e0b07@dell_ss3.pdx.osdl.net> <20040722.200426.99255296.yoshfuji@linux-ipv6.org> <1090593676.1128.25.camel@jzny.localdomain> <20040723.110007.27520072.yoshfuji@linux-ipv6.org> <1090612669.1218.47.camel@jzny.localdomain> <20040723135945.7f50b02c.davem@redhat.com> <1090630154.1134.6.camel@jzny.localdomain> <1090675993.1161.11.camel@jzny.localdomain> <20040724222853.752137d6.davem@redhat.com> <1091100138.1044.549.camel@jzny.localdomain> <1091100602.1043.557.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 29 Jul 2004 07:30:02 -0400 jamal wrote: > Patch was against 2.6.8-rc2 not bk20. Applied, thanks Jamal. From davem@redhat.com Thu Jul 29 15:59:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 16:00:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TMxu2u021851 for ; Thu, 29 Jul 2004 15:59:56 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6TMxie1008122; Thu, 29 Jul 2004 18:59:44 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6TMxia19196; Thu, 29 Jul 2004 18:59:44 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6TMx2TK028678; Thu, 29 Jul 2004 18:59:03 -0400 Date: Thu, 29 Jul 2004 15:57:19 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NET] Allow MD5 to be a module Message-Id: <20040729155719.288882b5.davem@redhat.com> In-Reply-To: <20040729114052.GA16001@gondor.apana.org.au> References: <20040729114052.GA16001@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Jul 2004 21:40:52 +1000 Herbert Xu wrote: > I found that recent 2.6 kernels no longer allowed me to build MD5 as > a module even though everything that used it were modules (including > ipv6 and sctp). It turns out that there were boolean options > selecting MD5 in the Kconfig files. Due to limitations in the current > kconfig implementation, this forces MD5 to be a boolean as well. > > The usual workaround in these cases is to move the selection up > to the closest tristate. This is what the following patch does. Applied, thanks Herbert. From davem@redhat.com Thu Jul 29 16:03:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 16:03:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TN3i3A022753 for ; Thu, 29 Jul 2004 16:03:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6TN3ce1009830; Thu, 29 Jul 2004 19:03:39 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6TN3ca21251; Thu, 29 Jul 2004 19:03:38 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6TN2vjq031419; Thu, 29 Jul 2004 19:02:57 -0400 Date: Thu, 29 Jul 2004 16:01:14 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] BIC tcp congestion calculation timestamp Message-Id: <20040729160114.050adaae.davem@redhat.com> In-Reply-To: <20040729112934.32002c24@dell_ss3.pdx.osdl.net> References: <20040729112934.32002c24@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Jul 2004 11:29:34 -0700 Stephen Hemminger wrote: > + __u32 last_stamp; /* time when updated last_cwnd */ ... > +static void init_bictcp(struct tcp_opt *tp) > +{ > + tp->bictcp.cnt = 0; > + > + tp->bictcp.last_max_cwnd = 0; > + tp->bictcp.last_cwnd = 0; > + tp->bictcp.last_stamp = 0; > +} ... > + if (tp->bictcp.last_cwnd == tp->snd_cwnd && > + (s32)(tcp_time_stamp - tp->bictcp.last_stamp) <= (HZ>>5)) > + return tp->bictcp.cnt; What if tcp_time_stamp is zero the first time this code runs after init_bictcp()? Maybe a better initialization value in init_bictcp() would be "tcp_time_stamp - ((HZ >> 5) + 1)"? From davem@redhat.com Thu Jul 29 16:04:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 16:04:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TN4UOD023164 for ; Thu, 29 Jul 2004 16:04:30 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6TN4Le1010116; Thu, 29 Jul 2004 19:04:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6TN4La21647; Thu, 29 Jul 2004 19:04:21 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6TN3dTk031654; Thu, 29 Jul 2004 19:03:40 -0400 Date: Thu, 29 Jul 2004 16:01:56 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: ralf@linux-mips.org, netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH 2.6] convert ROSE to use module_param Message-Id: <20040729160156.25854b37.davem@redhat.com> In-Reply-To: <20040729113522.30add0e5@dell_ss3.pdx.osdl.net> References: <20040729113522.30add0e5@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Jul 2004 11:35:22 -0700 Stephen Hemminger wrote: > Switch to module_param and the hash list can be local. Applied. From davem@redhat.com Thu Jul 29 16:05:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 16:05:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6TN5QY0023687 for ; Thu, 29 Jul 2004 16:05:26 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6TN5Ke1010615; Thu, 29 Jul 2004 19:05:20 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6TN5Ka22373; Thu, 29 Jul 2004 19:05:20 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6TN4cUk032289; Thu, 29 Jul 2004 19:04:38 -0400 Date: Thu, 29 Jul 2004 16:02:54 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: ralf@linux-mips.org, netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH 2.6] convert netrom to module_param Message-Id: <20040729160254.030a92d8.davem@redhat.com> In-Reply-To: <20040729113651.6517fe27@dell_ss3.pdx.osdl.net> References: <20040729113651.6517fe27@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7322 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Jul 2004 11:36:51 -0700 Stephen Hemminger wrote: > Convert Netrom to use module_param Also applied, thanks. From davem@redhat.com Thu Jul 29 18:20:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 18:20:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U1K4hT006819 for ; Thu, 29 Jul 2004 18:20:05 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6U1Joe1006417; Thu, 29 Jul 2004 21:19:50 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6U1Joa21414; Thu, 29 Jul 2004 21:19:50 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6U1J8cW029956; Thu, 29 Jul 2004 21:19:09 -0400 Date: Thu, 29 Jul 2004 18:19:48 -0700 From: "David S. Miller" To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: patches Message-Id: <20040729181948.5d36f47f.davem@redhat.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7323 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev The patches in the threads with subject: 1) [AH6] Rearrange routing headers and 2) [IPSEC] Move generic encap code into xfrm6_output I've simply lost track of. Herbert, can you resend the patches that I should be reviewing and applying to my tree? Thanks. From herbert@gondor.apana.org.au Thu Jul 29 18:24:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 18:25:05 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U1OtGg007226 for ; Thu, 29 Jul 2004 18:24:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqM8Q-0006tZ-00; Fri, 30 Jul 2004 11:24:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqM8N-0005X3-00; Fri, 30 Jul 2004 11:24:31 +1000 Date: Fri, 30 Jul 2004 11:24:31 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: patches Message-ID: <20040730012431.GA21253@gondor.apana.org.au> References: <20040729181948.5d36f47f.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20040729181948.5d36f47f.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 29, 2004 at 06:19:48PM -0700, David S. Miller wrote: > > I've simply lost track of. Herbert, can you resend the > patches that I should be reviewing and applying to > my tree? Yes it has been a bit chaotic. Here is the routing headers patch again. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/ah6.c 1.34 vs edited ===== --- 1.34/net/ipv6/ah6.c 2004-07-24 14:52:21 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-24 18:35:47 +10:00 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,45 @@ return 0; } +/** + * ipv6_rearrange_rthdr - rearrange IPv6 routing header + * @iph: IPv6 header + * @rthdr: routing header + * + * Rearrange the destination address in @iph and the addresses in @rthdr + * so that they appear in the order they will at the final destination. + * See Appendix A2 of RFC 2402 for details. + */ +static void ipv6_rearrange_rthdr(struct ipv6hdr *iph, struct ipv6_rt_hdr *rthdr) +{ + int segments, segments_left; + struct in6_addr *addrs; + struct in6_addr final_addr; + + segments_left = rthdr->segments_left; + if (segments_left == 0) + return; + rthdr->segments_left = 0; + + /* The value of rthdr->hdrlen has been verified either by the system + * call if it is locally generated, or by ipv6_rthdr_rcv() for incoming + * packets. So we can assume that it is even and that segments is + * greater than or equal to segments_left. + * + * For the same reason we can assume that this option is of type 0. + */ + segments = rthdr->hdrlen >> 1; + + addrs = ((struct rt0_hdr *)rthdr)->addr; + ipv6_addr_copy(&final_addr, addrs + segments - 1); + + addrs += segments - segments_left; + memmove(addrs + 1, addrs, (segments_left - 1) * sizeof(*addrs)); + + ipv6_addr_copy(addrs, &iph->daddr); + ipv6_addr_copy(&iph->daddr, &final_addr); +} + static int ipv6_clear_mutable_options(struct ipv6hdr *iph, int len) { union { @@ -101,7 +141,7 @@ break; case NEXTHDR_ROUTING: - exthdr.rth->segments_left = 0; + ipv6_rearrange_rthdr(iph, exthdr.rth); break; default : --pf9I7BMVVzbSWLtt-- From herbert@gondor.apana.org.au Thu Jul 29 18:26:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 18:26:23 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U1QEUS007563 for ; Thu, 29 Jul 2004 18:26:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqM9q-0006vN-00; Fri, 30 Jul 2004 11:26:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqM9q-0005Xs-00; Fri, 30 Jul 2004 11:26:02 +1000 Date: Fri, 30 Jul 2004 11:26:02 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: patches Message-ID: <20040730012602.GA21307@gondor.apana.org.au> References: <20040729181948.5d36f47f.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20040729181948.5d36f47f.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 29, 2004 at 06:19:48PM -0700, David S. Miller wrote: > > 2) [IPSEC] Move generic encap code into xfrm6_output And here is the current gencap patch. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/Makefile 1.17 vs edited ===== --- 1.17/net/ipv6/Makefile 2004-06-18 15:25:06 +10:00 +++ edited/net/ipv6/Makefile 2004-07-29 07:33:44 +10:00 @@ -11,7 +11,7 @@ ip6_flowlabel.o ipv6_syms.o ipv6-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o xfrm6_input.o \ - xfrm6_tunnel.o + xfrm6_tunnel.o xfrm6_output.o ipv6-objs += $(ipv6-y) obj-$(CONFIG_INET6_AH) += ah6.o ===== net/ipv6/ah6.c 1.34 vs edited ===== --- 1.34/net/ipv6/ah6.c 2004-07-25 15:26:11 +10:00 +++ edited/net/ipv6/ah6.c 2004-07-29 07:33:44 +10:00 @@ -118,70 +118,55 @@ int ah6_output(struct sk_buff **pskb) { int err; - int hdr_len = sizeof(struct ipv6hdr); + int extlen; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL; + struct ipv6hdr *top_iph; struct ip_auth_hdr *ah; struct ah_data *ahp; u8 nexthdr; - - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - iph = (*pskb)->nh.ipv6h; - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->nh.ipv6h->version = 6; - (*pskb)->nh.ipv6h->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.ipv6h->nexthdr = IPPROTO_AH; - ipv6_addr_copy(&(*pskb)->nh.ipv6h->saddr, - (struct in6_addr *) &x->props.saddr); - ipv6_addr_copy(&(*pskb)->nh.ipv6h->daddr, - (struct in6_addr *) &x->id.daddr); - ah = (struct ip_auth_hdr*)((*pskb)->nh.ipv6h+1); - ah->nexthdr = IPPROTO_IPV6; - } else { - u8 *prevhdr; - - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_AH; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { + char tmp_base[8]; + struct { + struct in6_addr daddr; + char hdrs[0]; + } *tmp_ext; + + top_iph = (struct ipv6hdr *)(*pskb)->data; + top_iph->payload_len = htons((*pskb)->len - sizeof(*top_iph)); + + nexthdr = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_AH; + + /* When there are no extension headers, we only need to save the first + * 8 bytes of the base IP header. + */ + memcpy(tmp_base, top_iph, sizeof(tmp_base)); + + tmp_ext = NULL; + extlen = (*pskb)->h.raw - (unsigned char *)(top_iph + 1); + if (extlen) { + extlen += sizeof(*tmp_ext); + tmp_ext = kmalloc(extlen, GFP_ATOMIC); + if (!tmp_ext) { err = -ENOMEM; goto error; } - memcpy(iph, (*pskb)->data, hdr_len); - (*pskb)->nh.ipv6h = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - err = ipv6_clear_mutable_options((*pskb)->nh.ipv6h, hdr_len); + memcpy(tmp_ext, &top_iph->daddr, extlen); + err = ipv6_clear_mutable_options(top_iph, + extlen - sizeof(*tmp_ext) + + sizeof(*top_iph)); if (err) goto error_free_iph; - - ah = (struct ip_auth_hdr*)((*pskb)->nh.raw+hdr_len); - (*pskb)->h.raw = (unsigned char*) ah; - ah->nexthdr = nexthdr; } - (*pskb)->nh.ipv6h->priority = 0; - (*pskb)->nh.ipv6h->flow_lbl[0] = 0; - (*pskb)->nh.ipv6h->flow_lbl[1] = 0; - (*pskb)->nh.ipv6h->flow_lbl[2] = 0; - (*pskb)->nh.ipv6h->hop_limit = 0; + ah = (struct ip_auth_hdr *)(*pskb)->h.raw; + ah->nexthdr = nexthdr; + + top_iph->priority = 0; + top_iph->flow_lbl[0] = 0; + top_iph->flow_lbl[1] = 0; + top_iph->flow_lbl[2] = 0; + top_iph->hop_limit = 0; ahp = x->data; ah->hdrlen = (XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + @@ -192,35 +177,16 @@ ah->seq_no = htonl(++x->replay.oseq); ahp->icv(ahp, *pskb, ah->auth_data); - if (x->props.mode) { - (*pskb)->nh.ipv6h->hop_limit = iph->hop_limit; - (*pskb)->nh.ipv6h->priority = iph->priority; - (*pskb)->nh.ipv6h->flow_lbl[0] = iph->flow_lbl[0]; - (*pskb)->nh.ipv6h->flow_lbl[1] = iph->flow_lbl[1]; - (*pskb)->nh.ipv6h->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear((*pskb)->nh.ipv6h); - } else { - memcpy((*pskb)->nh.ipv6h, iph, hdr_len); - kfree (iph); - } - - (*pskb)->nh.raw = (*pskb)->data; + err = 0; - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + memcpy(top_iph, tmp_base, sizeof(tmp_base)); + if (tmp_ext) { + memcpy(&top_iph->daddr, tmp_ext, extlen); error_free_iph: - kfree(iph); + kfree(tmp_ext); + } + error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } ===== net/ipv6/esp6.c 1.30 vs edited ===== --- 1.30/net/ipv6/esp6.c 2004-06-23 06:53:57 +10:00 +++ edited/net/ipv6/esp6.c 2004-07-29 07:33:44 +10:00 @@ -41,10 +41,10 @@ int esp6_output(struct sk_buff **pskb) { int err; - int hdr_len = 0; + int hdr_len; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph = NULL, *top_iph; + struct ipv6hdr *top_iph; struct ipv6_esp_hdr *esph; struct crypto_tfm *tfm; struct esp_data *esp; @@ -53,37 +53,13 @@ int clen; int alen; int nfrags; - u8 *prevhdr; - u8 nexthdr = 0; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, *pskb); - if (err) - goto error; + esp = x->data; + hdr_len = (*pskb)->h.raw - (*pskb)->data + + sizeof(*esph) + esp->conf.ivlen; - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - } else { - /* Strip IP header in transport mode. Save it. */ - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - *prevhdr = IPPROTO_ESP; - iph = kmalloc(hdr_len, GFP_ATOMIC); - if (!iph) { - err = -ENOMEM; - goto error; - } - memcpy(iph, (*pskb)->nh.raw, hdr_len); - __skb_pull(*pskb, hdr_len); - } + /* Strip IP+ESP header. */ + __skb_pull(*pskb, hdr_len); /* Now skb is pure payload to encrypt */ err = -ENOMEM; @@ -91,7 +67,6 @@ /* Round to block size */ clen = (*pskb)->len; - esp = x->data; alen = esp->auth.icv_trunc_len; tfm = esp->conf.tfm; blksize = (crypto_tfm_alg_blocksize(tfm) + 3) & ~3; @@ -100,7 +75,6 @@ clen = (clen + esp->conf.padlen-1)&~(esp->conf.padlen-1); if ((nfrags = skb_cow_data(*pskb, clen-(*pskb)->len+alen, &trailer)) < 0) { - if (!x->props.mode && iph) kfree(iph); goto error; } @@ -113,34 +87,11 @@ *(u8*)(trailer->tail + clen-(*pskb)->len - 2) = (clen - (*pskb)->len)-2; pskb_put(*pskb, trailer, clen - (*pskb)->len); - if (x->props.mode) { - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr*)skb_push(*pskb, x->props.header_len); - esph = (struct ipv6_esp_hdr*)(top_iph+1); - *(u8*)(trailer->tail - 1) = IPPROTO_IPV6; - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear(top_iph); - top_iph->nexthdr = IPPROTO_ESP; - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - ipv6_addr_copy(&top_iph->saddr, - (struct in6_addr *)&x->props.saddr); - ipv6_addr_copy(&top_iph->daddr, - (struct in6_addr *)&x->id.daddr); - } else { - esph = (struct ipv6_esp_hdr*)skb_push(*pskb, x->props.header_len); - (*pskb)->h.raw = (unsigned char*)esph; - top_iph = (struct ipv6hdr*)skb_push(*pskb, hdr_len); - memcpy(top_iph, iph, hdr_len); - kfree(iph); - top_iph->payload_len = htons((*pskb)->len + alen - sizeof(struct ipv6hdr)); - *(u8*)(trailer->tail - 1) = nexthdr; - } + top_iph = (struct ipv6hdr *)__skb_push(*pskb, hdr_len); + esph = (struct ipv6_esp_hdr *)(*pskb)->h.raw; + top_iph->payload_len = htons((*pskb)->len + alen - sizeof(*top_iph)); + *(u8*)(trailer->tail - 1) = *(*pskb)->nh.raw; + *(*pskb)->nh.raw = IPPROTO_ESP; esph->spi = x->id.spi; esph->seq_no = htonl(++x->replay.oseq); @@ -173,21 +124,9 @@ pskb_put(*pskb, trailer, alen); } - (*pskb)->nh.raw = (*pskb)->data; - - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - return NET_XMIT_BYPASS; + err = 0; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); return err; } ===== net/ipv6/ipcomp6.c 1.13 vs edited ===== --- 1.13/net/ipv6/ipcomp6.c 2004-07-23 05:14:21 +10:00 +++ edited/net/ipv6/ipcomp6.c 2004-07-29 07:33:44 +10:00 @@ -123,52 +123,14 @@ int err; struct dst_entry *dst = (*pskb)->dst; struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int hdr_len = 0; + struct ipv6hdr *top_iph; + int hdr_len; struct ipv6_comp_hdr *ipch; struct ipcomp_data *ipcd = x->data; - u8 *prevhdr; - u8 nexthdr = 0; int plen, dlen; u8 *start, *scratch = ipcd->scratch; - if ((*pskb)->ip_summed == CHECKSUM_HW) { - err = skb_checksum_help(pskb, 0); - if (err) - goto error_nolock; - } - - spin_lock_bh(&x->lock); - - err = xfrm_state_check(x, *pskb); - if (err) - goto error; - - if (x->props.mode) { - err = xfrm6_tunnel_check_size(*pskb); - if (err) - goto error; - - hdr_len = sizeof(struct ipv6hdr); - nexthdr = IPPROTO_IPV6; - iph = (*pskb)->nh.ipv6h; - top_iph = (struct ipv6hdr *)skb_push(*pskb, sizeof(struct ipv6hdr)); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; /* initial */ - top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - (*pskb)->nh.raw = (*pskb)->data; /* == top_iph */ - (*pskb)->h.raw = (*pskb)->nh.raw + hdr_len; - } else { - hdr_len = ip6_find_1stfragopt(*pskb, &prevhdr); - nexthdr = *prevhdr; - } + hdr_len = (*pskb)->h.raw - (*pskb)->data; /* check whether datagram len is larger than threshold */ if (((*pskb)->len - hdr_len) < ipcd->threshold) { @@ -184,7 +146,7 @@ /* compression */ plen = (*pskb)->len - hdr_len; dlen = IPCOMP_SCRATCH_SIZE; - start = (*pskb)->data + hdr_len; + start = (*pskb)->h.raw; err = crypto_comp_compress(ipcd->tfm, start, plen, scratch, &dlen); if (err) { @@ -197,39 +159,21 @@ pskb_trim(*pskb, hdr_len + dlen + sizeof(struct ip_comp_hdr)); /* insert ipcomp header and replace datagram */ - top_iph = (*pskb)->nh.ipv6h; + top_iph = (struct ipv6hdr *)(*pskb)->data; - if (x->props.mode && (x->props.flags & XFRM_STATE_NOECN)) - IP6_ECN_clear(top_iph); top_iph->payload_len = htons((*pskb)->len - sizeof(struct ipv6hdr)); - (*pskb)->nh.raw = (*pskb)->data; /* top_iph */ - ip6_find_1stfragopt(*pskb, &prevhdr); - *prevhdr = IPPROTO_COMP; - ipch = (struct ipv6_comp_hdr *)((unsigned char *)top_iph + hdr_len); - ipch->nexthdr = nexthdr; + ipch = (struct ipv6_comp_hdr *)start; + ipch->nexthdr = *(*pskb)->nh.raw; ipch->flags = 0; ipch->cpi = htons((u16 )ntohl(x->id.spi)); + *(*pskb)->nh.raw = IPPROTO_COMP; - (*pskb)->h.raw = (unsigned char*)ipch; out_ok: - x->curlft.bytes += (*pskb)->len; - x->curlft.packets++; - spin_unlock_bh(&x->lock); - - if (((*pskb)->dst = dst_pop(dst)) == NULL) { - err = -EHOSTUNREACH; - goto error_nolock; - } - err = NET_XMIT_BYPASS; + err = 0; -out_exit: - return err; error: - spin_unlock_bh(&x->lock); -error_nolock: - kfree_skb(*pskb); - goto out_exit; + return err; } static void ipcomp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt, ===== net/ipv6/xfrm6_policy.c 1.19 vs edited ===== --- 1.19/net/ipv6/xfrm6_policy.c 2004-06-18 15:25:06 +10:00 +++ edited/net/ipv6/xfrm6_policy.c 2004-07-29 07:33:44 +10:00 @@ -157,7 +157,7 @@ /* Copy neighbour for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); dst_prev->input = rt->u.dst.input; - dst_prev->output = dst_prev->xfrm->type->output; + dst_prev->output = xfrm6_output; /* Sheit... I remember I did this right. Apparently, * it was magically lost, so this code needs audit */ x->u.rt6.rt6i_flags = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL); ===== net/ipv6/xfrm6_tunnel.c 1.2 vs edited ===== --- 1.2/net/ipv6/xfrm6_tunnel.c 2004-06-20 05:48:05 +10:00 +++ edited/net/ipv6/xfrm6_tunnel.c 2004-07-29 07:33:44 +10:00 @@ -365,46 +365,12 @@ static int xfrm6_tunnel_output(struct sk_buff **pskb) { struct sk_buff *skb = *pskb; - struct dst_entry *dst = skb->dst; - struct xfrm_state *x = dst->xfrm; - struct ipv6hdr *iph, *top_iph; - int err; + struct ipv6hdr *top_iph; - if ((err = xfrm6_tunnel_check_size(skb)) != 0) - goto error_nolock; - - iph = skb->nh.ipv6h; - - top_iph = (struct ipv6hdr *)skb_push(skb, x->props.header_len); - top_iph->version = 6; - top_iph->priority = iph->priority; - top_iph->flow_lbl[0] = iph->flow_lbl[0]; - top_iph->flow_lbl[1] = iph->flow_lbl[1]; - top_iph->flow_lbl[2] = iph->flow_lbl[2]; - top_iph->nexthdr = IPPROTO_IPV6; + top_iph = (struct ipv6hdr *)skb->data; top_iph->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); - top_iph->hop_limit = iph->hop_limit; - memcpy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr, sizeof(struct in6_addr)); - memcpy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr, sizeof(struct in6_addr)); - skb->nh.raw = skb->data; - skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr); - - x->curlft.bytes += skb->len; - x->curlft.packets++; - - spin_unlock_bh(&x->lock); - - if ((skb->dst = dst_pop(dst)) == NULL) { - kfree_skb(skb); - err = -EHOSTUNREACH; - goto error_nolock; - } - - return NET_XMIT_BYPASS; -error_nolock: - kfree_skb(skb); - return err; + return 0; } static int xfrm6_tunnel_input(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb) --- /dev/null 2004-06-14 11:16:19.000000000 +1000 +++ linux-2.6/net/ipv6/xfrm6_output.c 2004-07-29 07:33:47.000000000 +1000 @@ -0,0 +1,123 @@ +/* + * xfrm6_output.c - Common IPsec encapsulation code for IPv6. + * Copyright (C) 2002 USAGI/WIDE Project + * Copyright (c) 2004 Herbert Xu + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include + +/* Add encapsulation header. + * + * In transport mode, the IP header and mutable extension headers will be moved + * forward to make space for the encapsulation header. + * + * In tunnel mode, the top IP header will be constructed per RFC 2401. + * The following fields in it shall be filled in by x->type->output: + * payload_len + * + * On exit, skb->h will be set to the start of the encapsulation header to be + * filled in by x->type->output and skb->nh will be set to the nextheader field + * of the extension header directly preceding the encapsulation header, or in + * its absence, that of the top IP header. The value of skb->data will always + * point to the top IP header. + */ +static void xfrm6_encap(struct sk_buff *skb) +{ + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + struct ipv6hdr *iph, *top_iph; + + skb_push(skb, x->props.header_len); + iph = skb->nh.ipv6h; + + if (!x->props.mode) { + u8 *prevhdr; + int hdr_len; + + hdr_len = ip6_find_1stfragopt(skb, &prevhdr); + skb->nh.raw = prevhdr - x->props.header_len; + skb->h.raw = skb->data + hdr_len; + memmove(skb->data, iph, hdr_len); + return; + } + + skb->nh.raw = skb->data; + top_iph = skb->nh.ipv6h; + skb->nh.raw = &top_iph->nexthdr; + skb->h.ipv6h = top_iph + 1; + + top_iph->version = 6; + top_iph->priority = iph->priority; + if (x->props.flags & XFRM_STATE_NOECN) + IP6_ECN_clear(top_iph); + top_iph->flow_lbl[0] = iph->flow_lbl[0]; + top_iph->flow_lbl[1] = iph->flow_lbl[1]; + top_iph->flow_lbl[2] = iph->flow_lbl[2]; + top_iph->nexthdr = IPPROTO_IPV6; + top_iph->hop_limit = iph->hop_limit; + ipv6_addr_copy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr); + ipv6_addr_copy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr); +} + +int xfrm6_output(struct sk_buff **pskb) +{ + struct sk_buff *skb = *pskb; + struct dst_entry *dst = skb->dst; + struct xfrm_state *x = dst->xfrm; + int err; + + if (skb->ip_summed == CHECKSUM_HW) { + err = skb_checksum_help(pskb, 0); + skb = *pskb; + if (err) + goto error_nolock; + } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; + + if (x->props.mode) { + err = xfrm6_tunnel_check_size(skb); + if (err) + goto error; + } + + xfrm6_encap(skb); + + err = x->type->output(pskb); + skb = *pskb; + if (err) + goto error; + + x->curlft.bytes += skb->len; + x->curlft.packets++; + + spin_unlock_bh(&x->lock); + + skb->nh.raw = skb->data; + + if (!(skb->dst = dst_pop(dst))) { + err = -EHOSTUNREACH; + goto error_nolock; + } + err = NET_XMIT_BYPASS; + +out_exit: + return err; +error: + spin_unlock_bh(&x->lock); +error_nolock: + kfree_skb(skb); + goto out_exit; +} --nFreZHaLTZJo0R7j-- From davem@redhat.com Thu Jul 29 19:21:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 19:21:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U2L1ad010050 for ; Thu, 29 Jul 2004 19:21:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6U2Kme1019144; Thu, 29 Jul 2004 22:20:48 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6U2Kma01868; Thu, 29 Jul 2004 22:20:48 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6U2K7N4024912; Thu, 29 Jul 2004 22:20:07 -0400 Date: Thu, 29 Jul 2004 19:20:46 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: patches Message-Id: <20040729192046.0a3fb71d.davem@redhat.com> In-Reply-To: <20040730012431.GA21253@gondor.apana.org.au> References: <20040729181948.5d36f47f.davem@redhat.com> <20040730012431.GA21253@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 30 Jul 2004 11:24:31 +1000 Herbert Xu wrote: > Here is the routing headers patch again. > > Signed-off-by: Herbert Xu Applied. Based upon reading of the rest of the thread about this patch I understand that: 1) Direction checking suggested by Yoshifuji is unecessary because on input segments_left will be zero in the type 0 routing header. 2) Both ipv4 and ipv6 erroneously do the xfrm route lookup using the first hop destination not the final destination. And this needs to be fixed with a followon patch. Is this correct? From herbert@gondor.apana.org.au Thu Jul 29 19:23:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 19:23:11 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U2N11w010406 for ; Thu, 29 Jul 2004 19:23:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqN2r-0007Fy-00; Fri, 30 Jul 2004 12:22:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqN2q-0005e3-00; Fri, 30 Jul 2004 12:22:52 +1000 Date: Fri, 30 Jul 2004 12:22:52 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: patches Message-ID: <20040730022252.GA21689@gondor.apana.org.au> References: <20040729181948.5d36f47f.davem@redhat.com> <20040730012431.GA21253@gondor.apana.org.au> <20040729192046.0a3fb71d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040729192046.0a3fb71d.davem@redhat.com> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Thu, Jul 29, 2004 at 07:20:46PM -0700, David S. Miller wrote: > > Based upon reading of the rest of the thread about > this patch I understand that: > > 1) Direction checking suggested by Yoshifuji is unecessary > because on input segments_left will be zero in the type 0 > routing header. > > 2) Both ipv4 and ipv6 erroneously do the xfrm route lookup > using the first hop destination not the final destination. > And this needs to be fixed with a followon patch. > > Is this correct? Yes. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@redhat.com Thu Jul 29 19:30:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 19:30:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U2UQ9R010886 for ; Thu, 29 Jul 2004 19:30:27 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6U2UGe1021090; Thu, 29 Jul 2004 22:30:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6U2UGa03978; Thu, 29 Jul 2004 22:30:16 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6U2TYiR029169; Thu, 29 Jul 2004 22:29:35 -0400 Date: Thu, 29 Jul 2004 19:30:13 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: patches Message-Id: <20040729193013.385ae3c6.davem@redhat.com> In-Reply-To: <20040730012602.GA21307@gondor.apana.org.au> References: <20040729181948.5d36f47f.davem@redhat.com> <20040730012602.GA21307@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 30 Jul 2004 11:26:02 +1000 Herbert Xu wrote: > On Thu, Jul 29, 2004 at 06:19:48PM -0700, David S. Miller wrote: > > > > 2) [IPSEC] Move generic encap code into xfrm6_output > > And here is the current gencap patch. I like this patch very much. Great cleanup Herbert. Applied. From davem@redhat.com Thu Jul 29 21:18:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 21:19:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U4Iw6g016533 for ; Thu, 29 Jul 2004 21:18:59 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6U4Ipe1008652; Fri, 30 Jul 2004 00:18:51 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6U4Ipa22165; Fri, 30 Jul 2004 00:18:51 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6U4I6I5009703; Fri, 30 Jul 2004 00:18:07 -0400 Date: Thu, 29 Jul 2004 21:18:44 -0700 From: "David S. Miller" To: kaber@trash.net Cc: hadi@cyberus.ca, devik@cdi.cz, netdev@oss.sgi.com Subject: Fw: hfsc and huge set of rules Message-Id: <20040729211844.61e8d328.davem@redhat.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__29_Jul_2004_21_18_44_-0700_NIkkprkv1fCQq2fm" X-archive-position: 7329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --Multipart=_Thu__29_Jul_2004_21_18_44_-0700_NIkkprkv1fCQq2fm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Looks like qdisc destruction has some expensive algorithms. Any quick ideas about the root culprit at least in the hfsc case? He says htb does it too. Begin forwarded message: Date: Tue, 27 Jul 2004 11:47:02 +0200 From: Tomasz Paszkowski To: linux-kernel@vger.kernel.org Subject: hfsc and huge set of rules Hello, I'am running hfsc qdisc with huge set of rules loaded. root@hades:/home/system/scr/etc/hfsc_rebuild# cat tc.batch | grep hfsc | wc -l 27884 Always when I delete the root qdisc (qdisc del dev eth0 root) the machine stop responding for about 5-6 seconds. As I think it's due the hfsc_destory_qdisc is executed in main kernel thread. Similar problem is present also in htb scheduler. Is there any quick solution to solve this problem ? -- Tomasz Paszkowski Administrator Miejskie Sieci Informatyczne e-wro http://www.e-wro.pl --Multipart=_Thu__29_Jul_2004_21_18_44_-0700_NIkkprkv1fCQq2fm Content-Type: application/pgp-signature; name="00000000.mimetmp" Content-Disposition: attachment; filename="00000000.mimetmp" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi4xIChHTlUv TGludXgpCgppRDhEQlFGQkJpU1djTlhPTDk4WGV5c1JBaVE1QUp3S20zTVdITkhsVUtEaXJ2QkUv TS9zZVN5ekpnQ2ZlVUNKCmNZR0k0L3FwSkZZcEFNQTBUQTFybHhnPQo9QWMrdwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0KCg== --Multipart=_Thu__29_Jul_2004_21_18_44_-0700_NIkkprkv1fCQq2fm-- From greearb@candelatech.com Thu Jul 29 22:01:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 22:02:17 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U51rjl017615 for ; Thu, 29 Jul 2004 22:01:53 -0700 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i6U5FtSb031402 for ; Thu, 29 Jul 2004 22:15:55 -0700 Message-ID: <4109D63E.5070006@candelatech.com> Date: Thu, 29 Jul 2004 22:01:50 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: Long-term TCP connections suffer on high-latency links. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev I have been running a TCP connection over a link with 2 seconds round-trip-time. It started off well, about 16Mbps in both directions (cwnd trained up to 2100 after a few seconds). After several hours of running, it is now doing only about 2.2Mbps in one direction, and 3.4Mbps in the other direction. I have watched the cwnd slowly increasing by one every 2-5 seconds (it is at 440 on one side and 655 on the other as I type). Occasionally, the cwnd drops in half or maybe even goes to zero. The un-acked packets is always == snd_cwnd. My suspicion is that for connections needing a cwnd of 2000 or so, the cwnd does not grow nearly fast enough after the connection has been established for a while. My naive suggestion would be to increase cwnd by a certain percentage instead of a fixed number (1). But, TCP has been around a long while, and surely other people have noticed things like this, so what am I missing? Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From chengjin@cs.caltech.edu Thu Jul 29 22:28:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 22:28:25 -0700 (PDT) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U5S8KC018449 for ; Thu, 29 Jul 2004 22:28:08 -0700 Received: from fast2.cs.caltech.edu (fast2.cs.caltech.edu [131.215.45.55]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 5B486DF2DA; Thu, 29 Jul 2004 22:28:04 -0700 (PDT) Received: by fast2.cs.caltech.edu (Postfix, from userid 20269) id 6AE951FF02; Thu, 29 Jul 2004 22:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fast2.cs.caltech.edu (Postfix) with ESMTP id 840D0143639; Thu, 29 Jul 2004 22:28:01 -0700 (PDT) Date: Thu, 29 Jul 2004 22:28:01 -0700 (PDT) From: Cheng Jin To: Ben Greear Cc: "'netdev@oss.sgi.com'" Subject: Re: Long-term TCP connections suffer on high-latency links. In-Reply-To: <4109D63E.5070006@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Ben, > But, TCP has been around a long while, and surely other people > have noticed things like this, so what am I missing? There are a number of research groups working on addressing the inefficiencies of the current TCP (NewReno) at large windows in both theory and experimental work. The experimental work would probably be more interesting for this mailing list. The protocols (that I know) that try to address this issue are: Highspeed TCP: http://www.icir.org/floyd/hstcp.html Scalable TCP: http://www-lce.eng.cam.ac.uk/~ctk21/scalable/ FAST TCP: http://netlab.caltech.edu/FAST H-TCP: http://hamilton.ie/net/main.htm?index BIC TCP/CUBIC: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ a related project for finding performance bottlenecks in the network stack is web100: http://www.web100.org As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in wireless networks, BIC TCP, and TCP Vegas are all included besides TCP NewReno, although not enabled by default. The others can be downloaded from the given websites. There are probably others that I forgot to mention. Apologies to them in advance. Making the current TCP more ``efficient'' by increasing cwnd faster is not an adequate solution, although doing that will likely produce higher throughput in today's Internet. We also must consider issues such as fairness to other flows, stability of the network in terms of queue oscillation and packet loss, and how well these solutions would scale in future networks. A lot of experiments are still needed to determine which is the most appropriate under what circumstances. Cheng From garzik@havoc.gtf.org Thu Jul 29 23:04:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 23:04:18 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U63vtn019456 for ; Thu, 29 Jul 2004 23:04:00 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id C41BB7752; Fri, 30 Jul 2004 02:03:48 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i6U63mqd023159; Fri, 30 Jul 2004 02:03:48 -0400 Date: Fri, 30 Jul 2004 02:03:48 -0400 From: Jeff Garzik To: davem@redhat.com, hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: [RFC,PATCH] fastroute dead code... Message-ID: <20040730060348.GA22854@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 7332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev While investigating what the heck ->accept_fastpath hook does (I had no specific idea), I found out... it does nothing at all. :) In net/ipv4/route.c and nowhere else, ->accept_fastpath is called. If it returns zero, the bit RTCF_FAST is set. RTCF_FAST is never tested anywhere AFAICS, so that makes ->accept_fastpath dead code. I created a test tree and removed all the code that was verifyably dead, and the following is what I came up with. The only reason why I did not remove CONFIG_NET_FASTROUTE completely is because of the lone swatch of code that remains from my pogrom, in net/core/dev.c (netif_receive_skb): #ifdef CONFIG_NET_FASTROUTE if (skb->pkt_type == PACKET_FASTROUTE) { __get_cpu_var(netdev_rx_stat).fastroute_deferred_out++; return dev_queue_xmit(skb); } #endif This actually does something, dependent upon options from the packet socket, so I left it alone. The rest was dead code. If nobody objects I can push to David, but right now this is more an RFC than a merge request for David. BK repo: bk pull bk://kernel.bkbits.net/jgarzik/net-2.6 This will update the following files: arch/ia64/hp/sim/simeth.c | 9 ----- drivers/net/bonding/bond_main.c | 10 ----- drivers/net/dummy.c | 10 ----- include/linux/in_route.h | 1 include/linux/netdevice.h | 12 ------ net/bridge/br_device.c | 6 --- net/core/dev.c | 70 ---------------------------------------- net/core/sysctl_net_core.c | 10 ----- net/ipv4/route.c | 11 ------ 9 files changed, 139 deletions(-) through these ChangeSets: (04/07/30 1.1914) [NET] remove more fastroute-related remnants Remove more code and data structures that are no longer used, now that other fastroute-related code is gone. (04/07/30 1.1913) [NET] remove net_device ->accept_fastpath hook Since its only user is gone, and didn't work anyway, we may now remove the ->accept_fastpath callback in struct net_device. This also allows removal of dev_clear_fastroute(), which required accept_fastpath presence (but never called it). (04/07/30 1.1912) [NET] remove unused RTCF_FAST definition, and the code that sets it In one case that no one cared about, this bit would be set. But, that bit was never used. diff -Nru a/arch/ia64/hp/sim/simeth.c b/arch/ia64/hp/sim/simeth.c --- a/arch/ia64/hp/sim/simeth.c 2004-07-30 01:55:49 -04:00 +++ b/arch/ia64/hp/sim/simeth.c 2004-07-30 01:55:49 -04:00 @@ -527,13 +527,4 @@ printk(KERN_WARNING "%s: set_multicast_list called\n", dev->name); } -#ifdef CONFIG_NET_FASTROUTE -static int -simeth_accept_fastpath(struct net_device *dev, struct dst_entry *dst) -{ - printk(KERN_WARNING "%s: simeth_accept_fastpath called\n", dev->name); - return -1; -} -#endif - __initcall(simeth_probe); diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c 2004-07-30 01:55:49 -04:00 +++ b/drivers/net/bonding/bond_main.c 2004-07-30 01:55:49 -04:00 @@ -4214,13 +4214,6 @@ return 0; } -#ifdef CONFIG_NET_FASTROUTE -static int bond_accept_fastpath(struct net_device *bond_dev, struct dst_entry *dst) -{ - return -1; -} -#endif - /*------------------------- Device initialization ---------------------------*/ /* @@ -4294,9 +4287,6 @@ bond_set_mode_ops(bond_dev, bond->params.mode); bond_dev->destructor = free_netdev; -#ifdef CONFIG_NET_FASTROUTE - bond_dev->accept_fastpath = bond_accept_fastpath; -#endif /* Initialize the device options */ bond_dev->tx_queue_len = 0; diff -Nru a/drivers/net/dummy.c b/drivers/net/dummy.c --- a/drivers/net/dummy.c 2004-07-30 01:55:49 -04:00 +++ b/drivers/net/dummy.c 2004-07-30 01:55:49 -04:00 @@ -57,13 +57,6 @@ { } -#ifdef CONFIG_NET_FASTROUTE -static int dummy_accept_fastpath(struct net_device *dev, struct dst_entry *dst) -{ - return -1; -} -#endif - static void __init dummy_setup(struct net_device *dev) { /* Initialize the device structure. */ @@ -71,9 +64,6 @@ dev->hard_start_xmit = dummy_xmit; dev->set_multicast_list = set_multicast_list; dev->set_mac_address = dummy_set_address; -#ifdef CONFIG_NET_FASTROUTE - dev->accept_fastpath = dummy_accept_fastpath; -#endif /* Fill in device structure with ethernet-generic values. */ ether_setup(dev); diff -Nru a/include/linux/in_route.h b/include/linux/in_route.h --- a/include/linux/in_route.h 2004-07-30 01:55:49 -04:00 +++ b/include/linux/in_route.h 2004-07-30 01:55:49 -04:00 @@ -14,7 +14,6 @@ #define RTCF_REDIRECTED 0x00040000 #define RTCF_TPROXY 0x00080000 -#define RTCF_FAST 0x00200000 #define RTCF_MASQ 0x00400000 #define RTCF_SNAT 0x00800000 #define RTCF_DOREDIRECT 0x01000000 diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h 2004-07-30 01:55:49 -04:00 +++ b/include/linux/netdevice.h 2004-07-30 01:55:49 -04:00 @@ -461,7 +461,6 @@ int (*hard_header_parse)(struct sk_buff *skb, unsigned char *haddr); int (*neigh_setup)(struct net_device *dev, struct neigh_parms *); - int (*accept_fastpath)(struct net_device *, struct dst_entry*); #ifdef CONFIG_NETPOLL_RX int netpoll_rx; #endif @@ -472,12 +471,6 @@ /* bridge stuff */ struct net_bridge_port *br_port; -#ifdef CONFIG_NET_FASTROUTE -#define NETDEV_FASTROUTE_HMASK 0xF - /* Semi-private data. Keep it at the end of device struct. */ - rwlock_t fastpath_lock; - struct dst_entry *fastpath[NETDEV_FASTROUTE_HMASK+1]; -#endif #ifdef CONFIG_NET_DIVERT /* this will get initialized at each interface type init routine */ struct divert_blk *divert; @@ -947,11 +940,6 @@ extern atomic_t netdev_dropping; extern int netdev_set_master(struct net_device *dev, struct net_device *master); extern int skb_checksum_help(struct sk_buff **pskb, int inward); -#ifdef CONFIG_NET_FASTROUTE -extern int netdev_fastroute; -extern int netdev_fastroute_obstacles; -extern void dev_clear_fastroute(struct net_device *dev); -#endif #ifdef CONFIG_SYSCTL extern char *net_sysctl_strdup(const char *s); diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c 2004-07-30 01:55:49 -04:00 +++ b/net/bridge/br_device.c 2004-07-30 01:55:49 -04:00 @@ -98,11 +98,6 @@ return 0; } -static int br_dev_accept_fastpath(struct net_device *dev, struct dst_entry *dst) -{ - return -1; -} - void br_dev_setup(struct net_device *dev) { memset(dev->dev_addr, 0, ETH_ALEN); @@ -118,7 +113,6 @@ dev->destructor = free_netdev; SET_MODULE_OWNER(dev); dev->stop = br_dev_stop; - dev->accept_fastpath = br_dev_accept_fastpath; dev->tx_queue_len = 0; dev->set_mac_address = NULL; dev->priv_flags = IFF_EBRIDGE; diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2004-07-30 01:55:49 -04:00 +++ b/net/core/dev.c 2004-07-30 01:55:49 -04:00 @@ -216,11 +216,6 @@ */ DEFINE_PER_CPU(struct softnet_data, softnet_data) = { 0, }; -#ifdef CONFIG_NET_FASTROUTE -int netdev_fastroute; -int netdev_fastroute_obstacles; -#endif - #ifdef CONFIG_SYSFS extern int netdev_sysfs_init(void); extern int netdev_register_sysfs(struct net_device *); @@ -278,12 +273,6 @@ int hash; spin_lock_bh(&ptype_lock); -#ifdef CONFIG_NET_FASTROUTE - if (pt->af_packet_priv) { - netdev_fastroute_obstacles++; - dev_clear_fastroute(pt->dev); - } -#endif if (pt->type == htons(ETH_P_ALL)) { netdev_nit++; list_add_rcu(&pt->list, &ptype_all); @@ -326,10 +315,6 @@ list_for_each_entry(pt1, head, list) { if (pt == pt1) { -#ifdef CONFIG_NET_FASTROUTE - if (pt->af_packet_priv) - netdev_fastroute_obstacles--; -#endif list_del_rcu(&pt->list); goto out; } @@ -971,39 +956,6 @@ return ret; } -#ifdef CONFIG_NET_FASTROUTE - -static void dev_do_clear_fastroute(struct net_device *dev) -{ - if (dev->accept_fastpath) { - int i; - - for (i = 0; i <= NETDEV_FASTROUTE_HMASK; i++) { - struct dst_entry *dst; - - write_lock_irq(&dev->fastpath_lock); - dst = dev->fastpath[i]; - dev->fastpath[i] = NULL; - write_unlock_irq(&dev->fastpath_lock); - - dst_release(dst); - } - } -} - -void dev_clear_fastroute(struct net_device *dev) -{ - if (dev) { - dev_do_clear_fastroute(dev); - } else { - read_lock(&dev_base_lock); - for (dev = dev_base; dev; dev = dev->next) - dev_do_clear_fastroute(dev); - read_unlock(&dev_base_lock); - } -} -#endif - /** * dev_close - shutdown an interface. * @dev: device to shutdown @@ -1056,9 +1008,6 @@ */ dev->flags &= ~IFF_UP; -#ifdef CONFIG_NET_FASTROUTE - dev_clear_fastroute(dev); -#endif /* * Tell people we are down @@ -2366,13 +2315,6 @@ if ((dev->promiscuity += inc) == 0) dev->flags &= ~IFF_PROMISC; if (dev->flags ^ old_flags) { -#ifdef CONFIG_NET_FASTROUTE - if (dev->flags & IFF_PROMISC) { - netdev_fastroute_obstacles++; - dev_clear_fastroute(dev); - } else - netdev_fastroute_obstacles--; -#endif dev_mc_upload(dev); printk(KERN_INFO "device %s %s promiscuous mode\n", dev->name, (dev->flags & IFF_PROMISC) ? "entered" : @@ -2925,10 +2867,6 @@ spin_lock_init(&dev->ingress_lock); #endif -#ifdef CONFIG_NET_FASTROUTE - dev->fastpath_lock = RW_LOCK_UNLOCKED; -#endif - ret = alloc_divert_blk(dev); if (ret) goto out; @@ -3249,10 +3187,6 @@ synchronize_net(); -#ifdef CONFIG_NET_FASTROUTE - dev_clear_fastroute(dev); -#endif - /* Shutdown queueing discipline. */ dev_shutdown(dev); @@ -3455,10 +3389,6 @@ EXPORT_SYMBOL(netdev_fc_xoff); EXPORT_SYMBOL(netdev_register_fc); EXPORT_SYMBOL(netdev_unregister_fc); -#endif -#ifdef CONFIG_NET_FASTROUTE -EXPORT_SYMBOL(netdev_fastroute); -EXPORT_SYMBOL(netdev_fastroute_obstacles); #endif #ifdef CONFIG_NET_CLS_ACT diff -Nru a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c --- a/net/core/sysctl_net_core.c 2004-07-30 01:55:49 -04:00 +++ b/net/core/sysctl_net_core.c 2004-07-30 01:55:49 -04:00 @@ -130,16 +130,6 @@ .mode = 0644, .proc_handler = &proc_dointvec }, -#ifdef CONFIG_NET_FASTROUTE - { - .ctl_name = NET_CORE_FASTROUTE, - .procname = "netdev_fastroute", - .data = &netdev_fastroute, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec - }, -#endif { .ctl_name = NET_CORE_MSG_COST, .procname = "message_cost", diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c 2004-07-30 01:55:49 -04:00 +++ b/net/ipv4/route.c 2004-07-30 01:55:49 -04:00 @@ -1729,17 +1729,6 @@ rth->rt_flags = flags; -#ifdef CONFIG_NET_FASTROUTE - if (netdev_fastroute && !(flags&(RTCF_NAT|RTCF_MASQ|RTCF_DOREDIRECT))) { - struct net_device *odev = rth->u.dst.dev; - if (odev != dev && - dev->accept_fastpath && - odev->mtu >= dev->mtu && - dev->accept_fastpath(dev, &rth->u.dst) == 0) - rth->rt_flags |= RTCF_FAST; - } -#endif - intern: err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); done: From greearb@candelatech.com Thu Jul 29 23:25:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jul 2004 23:25:57 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U6PeVf020289 for ; Thu, 29 Jul 2004 23:25:40 -0700 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i6U6dfSb000314; Thu, 29 Jul 2004 23:39:41 -0700 Message-ID: <4109E9E0.9010208@candelatech.com> Date: Thu, 29 Jul 2004 23:25:36 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cheng Jin CC: "'netdev@oss.sgi.com'" Subject: Re: Long-term TCP connections suffer on high-latency links. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Cheng Jin wrote: > As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in > wireless networks, BIC TCP, and TCP Vegas are all included besides TCP > NewReno, although not enabled by default. The others can be downloaded > from the given websites. There are probably others that I forgot to > mention. Apologies to them in advance. Any chance Westwood will get into the 2.4 kernel as well? > Making the current TCP more ``efficient'' by increasing cwnd faster is not > an adequate solution, although doing that will likely produce higher > throughput in today's Internet. We also must consider issues such as > fairness to other flows, stability of the network in terms of queue > oscillation and packet loss, and how well these solutions would scale in > future networks. A lot of experiments are still needed to determine which > is the most appropriate under what circumstances. Both of the two that I read about (Highspeed TCP and FAST tcp) did indeed increase the cwnd faster, unless I mis-understood the papers. Granted they do it in clever ways... Thanks for the links. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From baruch@ev-en.org Fri Jul 30 00:35:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 00:35:12 -0700 (PDT) Received: from galon.ev-en.org (rrcs-central-24-123-59-149.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U7Z3uP025359 for ; Fri, 30 Jul 2004 00:35:04 -0700 Received: by galon.ev-en.org (Postfix, from userid 1002) id DF87311A63E; Fri, 30 Jul 2004 10:34:53 +0300 (IDT) Date: Fri, 30 Jul 2004 10:34:53 +0300 From: Baruch Even To: Ben Greear Cc: Cheng Jin , "'netdev@oss.sgi.com'" Subject: Re: Long-term TCP connections suffer on high-latency links. Message-ID: <20040730073453.GA14412@ev-en.org> References: <4109E9E0.9010208@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4109E9E0.9010208@candelatech.com> User-Agent: Mutt/1.3.28i X-archive-position: 7334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev * Ben Greear [040730 09:25]: > Cheng Jin wrote: > > >As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in > >wireless networks, BIC TCP, and TCP Vegas are all included besides TCP > >NewReno, although not enabled by default. The others can be downloaded > >from the given websites. There are probably others that I forgot to > >mention. Apologies to them in advance. > > Any chance Westwood will get into the 2.4 kernel as well? > > >Making the current TCP more ``efficient'' by increasing cwnd faster is not > >an adequate solution, although doing that will likely produce higher > >throughput in today's Internet. We also must consider issues such as > >fairness to other flows, stability of the network in terms of queue > >oscillation and packet loss, and how well these solutions would scale in > >future networks. A lot of experiments are still needed to determine which > >is the most appropriate under what circumstances. > > Both of the two that I read about (Highspeed TCP and FAST tcp) > did indeed increase the cwnd faster, unless I mis-understood > the papers. Granted they do it in clever ways... At least H-TCP does increase the alpha parameter to increase the rate of change, but it also changes the beta parameter in accordance with the alpha, this is done to maintain fairness and the other good values we want to promote. You can find the patches for Linux 2.4.23 on the Hamilton website at: http://hamilton.ie/net/main.htm?index The parameters are changed in a mode-switch method so that H-TCP will work together with TCP and will work also on low Bandwidth Delay Product networks. Baruch From kazunori@miyazawa.org Fri Jul 30 01:12:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 01:12:59 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U8CnJB027587 for ; Fri, 30 Jul 2004 01:12:52 -0700 Received: from lemans ([2001:240:2:0:209:6bff:fe4d:3a14]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by miyazawa.org with esmtp; Fri, 30 Jul 2004 17:11:14 +0900 id 00000B78.410A02A2.00002197 Date: Fri, 30 Jul 2004 17:12:05 +0900 From: Kazunori Miyazawa To: davem@redhat.com, herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com, usagi-core@linux-ipv6.org, kazunori@miyazawa.org Subject: [PATCH][IPv6] separation xfrm_lookup from ip6_dst_lookup Message-Id: <20040730171205.114f22ba.kazunori@miyazawa.org> Organization: X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.4; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Hello, This patch separates xfrm_lookup from ip6_dst_lookup to support srcrt correctly. ip6_dst_lookup should be called with next hop. however xfrm_lookup should be called with final destination. It fixes them. This patch makes AH support routing header with previous Mr Hervert's patch. Of course this fixes ESP and IPcomp. I consider copying flowi(fl_rt) uses too much stack at the moment. I'll re-send the fixed patch again. Thank you, --Kazunori Miyazawa diff -ruNBE a/net/ipv6/datagram.c b/net/ipv6/datagram.c --- a/net/ipv6/datagram.c 2004-07-28 10:07:16.000000000 +0900 +++ b/net/ipv6/datagram.c 2004-07-28 10:29:13.000000000 +0900 @@ -40,7 +40,7 @@ struct ipv6_pinfo *np = inet6_sk(sk); struct in6_addr *daddr; struct dst_entry *dst; - struct flowi fl; + struct flowi fl, fl_rt, *flp = &fl; struct ip6_flowlabel *flowlabel = NULL; int addr_type; int err; @@ -157,17 +157,27 @@ if (flowlabel) { if (flowlabel->opt && flowlabel->opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *) flowlabel->opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } } else if (np->opt && np->opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *)np->opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } - err = ip6_dst_lookup(sk, &dst, &fl); + err = ip6_dst_lookup(sk, &dst, flp); if (err) goto out; + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + dst_release(dst); + dst = NULL; + goto out; + } + /* source address lookup done in ip6_dst_lookup */ if (ipv6_addr_any(&np->saddr)) diff -ruNBE a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c 2004-07-28 10:07:09.000000000 +0900 +++ b/net/ipv6/ip6_output.c 2004-07-28 10:29:20.000000000 +0900 @@ -796,10 +796,6 @@ goto out_err_release; } } - if ((err = xfrm_lookup(dst, fl, sk, 0)) < 0) { - err = -ENETUNREACH; - goto out_err_release; - } return 0; diff -ruNBE a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c 2004-07-28 10:08:26.000000000 +0900 +++ b/net/ipv6/raw.c 2004-07-28 10:30:22.000000000 +0900 @@ -567,7 +567,7 @@ struct ipv6_txoptions *opt = NULL; struct ip6_flowlabel *flowlabel = NULL; struct dst_entry *dst = NULL; - struct flowi fl; + struct flowi fl, fl_rt, *flp = &fl; int addr_len = msg->msg_namelen; int hlimit = -1; u16 proto; @@ -674,6 +674,7 @@ opt = fl6_merge_options(&opt_space, flowlabel, opt); fl.proto = proto; + ipv6_addr_copy(&fl.fl6_dst, daddr); if (ipv6_addr_any(&fl.fl6_src) && !ipv6_addr_any(&np->saddr)) ipv6_addr_copy(&fl.fl6_src, &np->saddr); @@ -681,16 +682,24 @@ /* merge ip6_build_xmit from ip6_output */ if (opt && opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *) opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst)) fl.oif = np->mcast_oif; - err = ip6_dst_lookup(sk, &dst, &fl); + err = ip6_dst_lookup(sk, &dst, flp); if (err) goto out; + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + dst_release(dst); + dst = NULL; + goto out; + } + if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl.fl6_dst)) hlimit = np->mcast_hops; diff -ruNBE a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c 2004-07-28 10:09:10.000000000 +0900 +++ b/net/ipv6/tcp_ipv6.c 2004-07-28 10:29:37.000000000 +0900 @@ -550,7 +550,7 @@ struct ipv6_pinfo *np = inet6_sk(sk); struct tcp_opt *tp = tcp_sk(sk); struct in6_addr *saddr = NULL; - struct flowi fl; + struct flowi fl, fl_rt, *flp = &fl; struct dst_entry *dst; int addr_type; int err; @@ -666,14 +666,21 @@ if (np->opt && np->opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *)np->opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } - err = ip6_dst_lookup(sk, &dst, &fl); - + err = ip6_dst_lookup(sk, &dst, flp); if (err) goto failure; + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + dst_release(dst); + dst = NULL; + goto failure; + } + if (saddr == NULL) { saddr = &fl.fl6_src; ipv6_addr_copy(&np->rcv_saddr, saddr); @@ -793,6 +800,14 @@ sk->sk_err_soft = -err; goto out; } + + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + sk->sk_err_soft = -err; + dst_release(dst); + dst = NULL; + goto out; + } + } else dst_hold(dst); @@ -863,7 +878,7 @@ struct ipv6_pinfo *np = inet6_sk(sk); struct sk_buff * skb; struct ipv6_txoptions *opt = NULL; - struct flowi fl; + struct flowi fl, fl_rt, *flp = &fl; int err = -1; memset(&fl, 0, sizeof(fl)); @@ -888,12 +903,22 @@ if (opt && opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *) opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } - err = ip6_dst_lookup(sk, &dst, &fl); + err = ip6_dst_lookup(sk, &dst, flp); if (err) goto done; + + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + dst_release(dst); + dst = NULL; + goto done; + } + + } skb = tcp_make_synack(sk, dst, req); @@ -1021,6 +1046,12 @@ /* sk = NULL, but it is safe for now. RST socket required. */ if (!ip6_dst_lookup(NULL, &buff->dst, &fl)) { + + if ((xfrm_lookup(&buff->dst, &fl, NULL, 0)) < 0) { + dst_release(buff->dst); + return; + } + ip6_xmit(NULL, buff, &fl, NULL, 0); TCP_INC_STATS_BH(TCP_MIB_OUTSEGS); TCP_INC_STATS_BH(TCP_MIB_OUTRSTS); @@ -1082,6 +1113,12 @@ fl.fl_ip_sport = t1->source; if (!ip6_dst_lookup(NULL, &buff->dst, &fl)) { + + if ((xfrm_lookup(&buff->dst, &fl, NULL, 0)) < 0) { + dst_release(buff->dst); + return; + } + ip6_xmit(NULL, buff, &fl, NULL, 0); TCP_INC_STATS_BH(TCP_MIB_OUTSEGS); return; @@ -1313,22 +1350,31 @@ } if (dst == NULL) { - struct flowi fl; + struct flowi fl, fl_rt, *flp = &fl; memset(&fl, 0, sizeof(fl)); fl.proto = IPPROTO_TCP; ipv6_addr_copy(&fl.fl6_dst, &req->af.v6_req.rmt_addr); if (opt && opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *) opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } ipv6_addr_copy(&fl.fl6_src, &req->af.v6_req.loc_addr); fl.oif = sk->sk_bound_dev_if; fl.fl_ip_dport = req->rmt_port; fl.fl_ip_sport = inet_sk(sk)->sport; - if (ip6_dst_lookup(sk, &dst, &fl)) + if (ip6_dst_lookup(sk, &dst, flp)) goto out; + + if ((xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + dst_release(dst); + dst = NULL; + goto out; + } + } newsk = tcp_create_openreq_child(sk, req, skb); @@ -1710,7 +1756,7 @@ if (dst == NULL) { struct inet_opt *inet = inet_sk(sk); - struct flowi fl; + struct flowi fl, fl_rt, *flp = &fl; memset(&fl, 0, sizeof(fl)); fl.proto = IPPROTO_TCP; @@ -1723,16 +1769,25 @@ if (np->opt && np->opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *) np->opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } - err = ip6_dst_lookup(sk, &dst, &fl); + err = ip6_dst_lookup(sk, &dst, flp); if (err) { sk->sk_route_caps = 0; return err; } + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + sk->sk_route_caps = 0; + dst_release(dst); + return err; + } + + ip6_dst_store(sk, dst, NULL); sk->sk_route_caps = dst->dev->features & ~(NETIF_F_IP_CSUM | NETIF_F_TSO); @@ -1747,7 +1802,7 @@ struct sock *sk = skb->sk; struct inet_opt *inet = inet_sk(sk); struct ipv6_pinfo *np = inet6_sk(sk); - struct flowi fl; + struct flowi fl, fl_rt, *flp = &fl; struct dst_entry *dst; memset(&fl, 0, sizeof(fl)); @@ -1762,19 +1817,27 @@ if (np->opt && np->opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *) np->opt->srcrt; - ipv6_addr_copy(&fl.fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } dst = __sk_dst_check(sk, np->dst_cookie); if (dst == NULL) { - int err = ip6_dst_lookup(sk, &dst, &fl); + int err = ip6_dst_lookup(sk, &dst, flp); if (err) { sk->sk_err_soft = -err; return err; } + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) { + sk->sk_err_soft = -err; + dst_release(dst); + return err; + } + ip6_dst_store(sk, dst, NULL); sk->sk_route_caps = dst->dev->features & ~(NETIF_F_IP_CSUM | NETIF_F_TSO); diff -ruNBE a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c 2004-07-28 10:10:23.000000000 +0900 +++ b/net/ipv6/udp.c 2004-07-28 10:29:41.000000000 +0900 @@ -630,13 +630,13 @@ struct in6_addr *daddr; struct ipv6_txoptions *opt = NULL; struct ip6_flowlabel *flowlabel = NULL; - struct flowi *fl = &inet->cork.fl; - struct dst_entry *dst; + struct flowi *fl = &inet->cork.fl, fl_rt, *flp = fl; + struct dst_entry *dst = NULL; int addr_len = msg->msg_namelen; int ulen = len; int hlimit = -1; int corkreq = up->corkflag || msg->msg_flags&MSG_MORE; - int err; + int err = 0; /* destination address check */ if (sin6) { @@ -779,20 +779,28 @@ if (ipv6_addr_any(&fl->fl6_src) && !ipv6_addr_any(&np->saddr)) ipv6_addr_copy(&fl->fl6_src, &np->saddr); fl->fl_ip_sport = inet->sport; - + /* merge ip6_build_xmit from ip6_output */ if (opt && opt->srcrt) { struct rt0_hdr *rt0 = (struct rt0_hdr *) opt->srcrt; - ipv6_addr_copy(&fl->fl6_dst, rt0->addr); + memcpy(&fl_rt, &fl, sizeof(fl_rt)); + ipv6_addr_copy(&fl_rt.fl6_dst, rt0->addr); + flp = &fl_rt; } if (!fl->oif && ipv6_addr_is_multicast(&fl->fl6_dst)) fl->oif = np->mcast_oif; - err = ip6_dst_lookup(sk, &dst, fl); + err = ip6_dst_lookup(sk, &dst, flp); if (err) goto out; + if ((err = xfrm_lookup(&dst, fl, sk, 0)) < 0) { + dst_release(dst); + dst = NULL; + goto out; + } + if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl->fl6_dst)) hlimit = np->mcast_hops; From margitsw@t-online.de Fri Jul 30 01:33:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 01:33:43 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U8XWSQ028246 for ; Fri, 30 Jul 2004 01:33:35 -0700 Received: from fwd08.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1BqSoS-0007eL-05; Fri, 30 Jul 2004 10:32:24 +0200 Received: from roglap.local (ZYKGcZZcgeNRVskvOyu-ZqvrP4-jf2w-KxyptDlF3tI2YZTs8jfwc1@[217.224.22.144]) by fwd08.sul.t-online.com with esmtp id 1BqSoA-0EBOPA0; Fri, 30 Jul 2004 10:32:06 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.6.8-rc2] prism54 URGENT - Fix IRQ handling Date: Fri, 30 Jul 2004 10:23:57 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_eWgCBKI6CxpnqJ1" Message-Id: <200407301023.58457.margitsw@t-online.de> X-ID: ZYKGcZZcgeNRVskvOyu-ZqvrP4-jf2w-KxyptDlF3tI2YZTs8jfwc1 X-archive-position: 7336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_eWgCBKI6CxpnqJ1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-07-30 Margit Schubert-While * We are handing back HANDLED even though the IRQ is not for us. We also change device state. This is plainly wrong. AFAICT we also need to take the spin lock early. Tested/running on UP/SMP for about a week now. (Discovered on one of my lappies that had the X driver on the same IRQ) (Proposed on Prism54 Devel with no objections) * Jeff, I think we need to squeeze this one into 2.6.8 Margit --Boundary-00=_eWgCBKI6CxpnqJ1 Content-Type: text/x-diff; charset="us-ascii"; name="interrupt.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="interrupt.patch" diff -Naur linux-2.6.8-01/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.8-02/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.8-01/drivers/net/wireless/prism54/islpci_dev.c 2004-07-28 13:58:06.000000000 +0200 +++ linux-2.6.8-02/drivers/net/wireless/prism54/islpci_dev.c 2004-07-28 14:04:08.000000000 +0200 @@ -186,6 +186,9 @@ void *device = priv->device_base; int powerstate = ISL38XX_PSM_POWERSAVE_STATE; + /* lock the interrupt handler */ + spin_lock(&priv->slock); + /* received an interrupt request on a shared IRQ line * first check whether the device is in sleep mode */ reg = readl(device + ISL38XX_CTRL_STAT_REG); @@ -195,14 +198,10 @@ #if VERBOSE > SHOW_ERROR_MESSAGES DEBUG(SHOW_TRACING, "Assuming someone else called the IRQ\n"); #endif + spin_unlock(&priv->slock); return IRQ_NONE; } - if (islpci_get_state(priv) != PRV_STATE_SLEEP) - powerstate = ISL38XX_PSM_ACTIVE_STATE; - - /* lock the interrupt handler */ - spin_lock(&priv->slock); /* check whether there is any source of interrupt on the device */ reg = readl(device + ISL38XX_INT_IDENT_REG); @@ -213,6 +212,9 @@ reg &= ISL38XX_INT_SOURCES; if (reg != 0) { + if (islpci_get_state(priv) != PRV_STATE_SLEEP) + powerstate = ISL38XX_PSM_ACTIVE_STATE; + /* reset the request bits in the Identification register */ isl38xx_w32_flush(device, reg, ISL38XX_INT_ACK_REG); @@ -340,6 +342,12 @@ isl38xx_handle_wakeup(priv->control_block, &powerstate, priv->device_base); } + } else { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Assuming someone else called the IRQ\n"); +#endif + spin_unlock(&priv->slock); + return IRQ_NONE; } /* sleep -> ready */ --Boundary-00=_eWgCBKI6CxpnqJ1-- From Robert.Olsson@data.slu.se Fri Jul 30 02:19:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 02:19:30 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6U9JGMw029721 for ; Fri, 30 Jul 2004 02:19:17 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6U9IuIR023141; Fri, 30 Jul 2004 11:18:56 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 824E3EC33E; Fri, 30 Jul 2004 11:18:56 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16650.4736.456106.603065@robur.slu.se> Date: Fri, 30 Jul 2004 11:18:56 +0200 To: Pasi Sjoholm Cc: Robert Olsson , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <16647.61953.158512.433946@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Pasi Sjoholm writes: You should monitor the the user app (gettimeofday()monitoring for starvation this is the most important measure and what we are trying to improve. We can hardly expect softirq's alone to give us the balance of load we wish. At overload something has to get less resources. Even we defer all softirq's to scheduler context there is no way making any distinguish between them unless we run them in separate processes i.e one RX_SOFIRQ, TX_SOFIRQ etc. This could solve some problem I just discussed with Jamal where the RX softirq overruns the TX softirq and causes drop at egress (qdisc) when bus BW is saturated. Running softirq's under schedules context's can cause other delays and other problems. About tour test; I dunno if the absolute values are comparable but we see a some change in behavior. I use your two last lines from your test assuming these are the highest loaded BH KSOFT IRQ-exit -------------------------------------------------------------- 00082ac4 00000000 0001180a 00000000 0000497c 00006f17 000f30fa 00082ac4 00000000 0001225a 00000000 00004a94 00007809 000f3140 280+2290+70 = 2640 10 87 3 % (Deffering to ksoftirqd after 2 sec patch) 0004c2fc 00000000 0000b626 00000000 0000182c 000011aa 000a14d2 0004c302 00000000 0000c03a 00000000 00001872 00001aec 000a155e 70+2370+140=2580 3 92 5 % So most ksoftirq's runs most softirq's which is good. Without this you would not be able to type any commands at all. Also we see some effects from the path. Can you monitor userland starvation here too? > - When the ksoftirqd starts to eat cpu-time time_squeeze-value (3rd > column) starts growing (in both cases it's same thing). This OK as we have to throttle. > - We are also getting more hits from SIRQ_FROM_KSOFTIRQD > immediately after that. (6th column) Good. > - Total-column's value stops growing although network file transfers > are still on. (1st column) Well ksoftirqd now runs RX softirq and competes heavily with other processes for your CPU you may have to adjust priorities to get your desired balance. Can you experiment a bit? > > And maybe we should take the experiment disussions off the list. > I think that we should leave netdev as Francois requested it in first > place but we can drop the lkml if you want to. Well it's not only a network issue. Cheers. --ro From kaber@trash.net Fri Jul 30 03:34:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 03:34:54 -0700 (PDT) Received: from gw.localnet (port-195-158-169-111.dynamic.qsc.de [195.158.169.111]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UAYOR6008070 for ; Fri, 30 Jul 2004 03:34:25 -0700 Received: from ws.localnet ([192.168.0.23] ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BqUlf-0003fL-00; Fri, 30 Jul 2004 12:37:39 +0200 Message-ID: <410A2449.3020701@trash.net> Date: Fri, 30 Jul 2004 12:34:49 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040722 Debian/1.7.1-3 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: hadi@cyberus.ca, devik@cdi.cz, netdev@oss.sgi.com, tomasz.paszkowski@e-wro.pl Subject: Re: Fw: hfsc and huge set of rules References: <20040729211844.61e8d328.davem@redhat.com> In-Reply-To: <20040729211844.61e8d328.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7338 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 David S. Miller wrote: > Looks like qdisc destruction has some expensive algorithms. > Any quick ideas about the root culprit at least in the hfsc > case? He says htb does it too. hfsc_destroy_qdisc takes O(n) time wrt. the number of classes, but 5-6 seconds is still long. If all these classes contain inner qdiscs other than the default, I guess removing the classes from dev->qdisc_list in qdisc_destroy takes up most of the time, with n O(n) operations. The __qdisc_destroy rcu callback also calls reset before destroy, I don't know any qdisc where this is really neccessary. Without inner qdiscs, I need to see the script first to judge what's going wrong. Tomasz ? BTW: The lockless loopback patch broke qdisc_destroy in multiple ways. The rcu callback doesn't do any locking, to add locking all read/write_lock(qdisc_tree_lock) need to be changed to read/write_lock_bh because the callback is called from a tasklet, until now all changes to the tree structure were made in process-context. Additionally it invalidates the assumption made by dev_shutdown that qdisc_destroy will destroy all qdiscs and clear dev->qdisc_list immediately. Since qdisc->dev is not refcounted netdev_wait_allrefs won't notice when the rcu callback hasn't destroyed all qdiscs yet and free the device, but qdisc_destroy called from ops->destroy called from the callback will still access the memory. Patch coming up soon. Regards Patrick > Begin forwarded message: > > Date: Tue, 27 Jul 2004 11:47:02 +0200 > From: Tomasz Paszkowski > To: linux-kernel@vger.kernel.org > Subject: hfsc and huge set of rules > > > Hello, > > I'am running hfsc qdisc with huge set of rules loaded. > > root@hades:/home/system/scr/etc/hfsc_rebuild# cat tc.batch | grep hfsc | wc -l > 27884 > > > Always when I delete the root qdisc (qdisc del dev eth0 root) > the machine stop responding for about 5-6 seconds. As I think it's due the > hfsc_destory_qdisc is executed in main kernel thread. Similar problem is > present also in htb scheduler. > > Is there any quick solution to solve this problem ? > From acid@krezus.e-wro.net Fri Jul 30 04:08:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 04:08:51 -0700 (PDT) Received: from krezus.e-wro.net (krezus.e-wro.net [82.143.159.250]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UB8a9M009192 for ; Fri, 30 Jul 2004 04:08:37 -0700 Received: from krezus.e-wro.net (localhost [127.0.0.1]) by krezus.e-wro.net (8.12.10/8.12.10) with ESMTP id i6UB8NOC008722; Fri, 30 Jul 2004 13:08:23 +0200 Received: (from acid@localhost) by krezus.e-wro.net (8.12.10/8.12.10/Submit) id i6UB8FIK008721; Fri, 30 Jul 2004 13:08:15 +0200 Date: Fri, 30 Jul 2004 13:08:15 +0200 From: Tomasz Paszkowski To: Patrick McHardy Cc: "David S. Miller" , hadi@cyberus.ca, devik@cdi.cz, netdev@oss.sgi.com Subject: Re: Fw: hfsc and huge set of rules Message-ID: <20040730110815.GA7812@krezus.e-wro.net> References: <20040729211844.61e8d328.davem@redhat.com> <410A2449.3020701@trash.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <410A2449.3020701@trash.net> User-Agent: Mutt/1.4i X-NCC-RegID: pl.e-wro X-Scanned-By: MIMEDefang 2.42 X-archive-position: 7339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tomasz.paszkowski@e-wro.pl Precedence: bulk X-list: netdev --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 30, 2004 at 12:34:49PM +0200, Patrick McHardy wrote: > David S. Miller wrote: > >Looks like qdisc destruction has some expensive algorithms. > >Any quick ideas about the root culprit at least in the hfsc > >case? He says htb does it too. >=20 > hfsc_destroy_qdisc takes O(n) time wrt. the number of classes, > but 5-6 seconds is still long. If all these classes contain inner > qdiscs other than the default, I guess removing the classes from > dev->qdisc_list in qdisc_destroy takes up most of the time, with > n O(n) operations. The __qdisc_destroy rcu callback also calls > reset before destroy, I don't know any qdisc where this is really > neccessary. Without inner qdiscs, I need to see the script first to > judge what's going wrong. Tomasz ? http://www.e-wro.pl/~acid/tc.batch.gz. In my opinion it's not the case of expensive algorithms, but the number of classes. With this rule set load= ed (tc -b tc.batch) command: for i in 'e1.903 e0.930 e0.931 e0.932' ; do tc qdisc del dev ${i} root done completly freezes machine for about 5-6 seconds. I was trying do modify the code od hfsc_qdisc_destroy scheduling another task using schedule_task (), but i don't have enough knowledge to do deal with proper locking of qdisc structures. --=20 Tomasz Paszkowski --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBCiwfcNXOL98XeysRAlSMAKCM7HYVMAYP6yDx2dSgaoM3eCIy8gCfRBbU +SbQkyCFUo5sjFRZ50ZkVrY= =+Wgu -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From herbert@gondor.apana.org.au Fri Jul 30 04:50:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 04:50:52 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UBob3M013390 for ; Fri, 30 Jul 2004 04:50:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqVtv-0002Kc-00; Fri, 30 Jul 2004 21:50:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqVtp-0001Uj-00; Fri, 30 Jul 2004 21:50:09 +1000 Date: Fri, 30 Jul 2004 21:50:09 +1000 To: Andreas Steffen , "David S. Miller" Cc: dev@lists.openswan.org, users@lists.strongswan.org, netdev@oss.sgi.com Subject: Re: SPI generation by netlink_get_spi() Message-ID: <20040730115009.GA5689@gondor.apana.org.au> References: <4108F5F5.4020001@strongsec.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <4108F5F5.4020001@strongsec.net> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 29, 2004 at 03:04:53PM +0200, Andreas Steffen wrote: > > : | message ID: 65 7e 1a 0f > : | netlink_get_spi: allocated 0x9f4c9788 for esp.0@145.254.54.68 > : | SPI 9f 4c 97 88 > > The netlink interface of the 2.6 kernel is used to request an SPI for > the IPsec SA. > > Immediately after the first Quick Mode message the second pending Quick Mode > is inititated: > : | message ID: a1 01 a2 b2 > : | netlink_get_spi: allocated 0x9f4c9788 for esp.0@145.254.54.68 > : | SPI 9f 4c 97 88 > > And here the error happens. The two Quick Mode negotiations have different > Message IDs (65 7e 1a 0f versus a1 01 a2 b2) which will cause two phase2 > state objects to be created on the peer side but the generated SPI 9f 4c 97 > 88 > is the same. This will trigger the assertion passert(0) in > kernel_pfkey.c:finish_pfkey_msg() in freeswan-2.0x because twice the same > SADB_ADD command is executed for the outbound esp. Removing the assertion > as in Openswan does not help - several retrials will not succeed in setting > up the IPsec SA. Yes this is a kernel bug. The issue is that two successive calls to netlink_get_spi is returning the same SA. Since netlink_get_spi is meant to be a creation operation this is incorrect. The netlink_get_spi operation is modelled off the PFKEY SADB_GETSPI command which is specified in RFC 2367. The purpose of SADB_GETSPI is to create a new larval SA that can then be filled in by SADB_UPDATE. Its semantics does not allow two SADB_GETSPI calls to return the same SA, even if there is no SADB_UPDATE call in between. The reason the second netlink_get_spi is returning the same SA is because in find_acq(), the code is looking at all larval states as opposed to only larval states with an SPI of zero. Since the only other caller of find_acq() -- xfrm_state_add() intentionally ignores all return values with a non-zero SPI, it is safe to not look at SAs with non-zero SPIs at all in find_acq(). The following patch does exactly that. Signed-off-by: Herbert Xu In fact, the find_acq() call in xfrm_state_add() is a remnant from the days when we had xfrm_state_replace() instead of xfrm_state_add() and xfrm_state_update(). It can now be safely removed. I'll post a separate patch for that. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/xfrm4_state.c 1.10 vs edited ===== --- 1.10/net/ipv4/xfrm4_state.c 2004-07-09 20:19:08 +10:00 +++ edited/net/ipv4/xfrm4_state.c 2004-07-30 21:26:21 +10:00 @@ -74,11 +74,8 @@ proto == x->id.proto && saddr->a4 == x->props.saddr.a4 && reqid == x->props.reqid && - x->km.state == XFRM_STATE_ACQ) { - if (!x0) - x0 = x; - if (x->id.spi) - continue; + x->km.state == XFRM_STATE_ACQ && + !x->id.spi) { x0 = x; break; } ===== net/ipv6/xfrm6_state.c 1.11 vs edited ===== --- 1.11/net/ipv6/xfrm6_state.c 2004-05-27 18:57:44 +10:00 +++ edited/net/ipv6/xfrm6_state.c 2004-07-30 21:27:07 +10:00 @@ -81,11 +81,8 @@ proto == x->id.proto && !ipv6_addr_cmp((struct in6_addr *)saddr, (struct in6_addr *)x->props.saddr.a6) && reqid == x->props.reqid && - x->km.state == XFRM_STATE_ACQ) { - if (!x0) - x0 = x; - if (x->id.spi) - continue; + x->km.state == XFRM_STATE_ACQ && + !x->id.spi) { x0 = x; break; } --x+6KMIRAuhnl3hBn-- From herbert@gondor.apana.org.au Fri Jul 30 05:11:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 05:11:19 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UCB9fn014249 for ; Fri, 30 Jul 2004 05:11:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqWE0-0002VB-00; Fri, 30 Jul 2004 22:11:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqWDw-0001aH-00; Fri, 30 Jul 2004 22:10:56 +1000 Date: Fri, 30 Jul 2004 22:10:56 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Remove redundant check in xfrm_state_add() Message-ID: <20040730121056.GA5911@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is the patch referred to in the netlink_get_spi thread. I was actually wrong about the reason for this patch though. Firstly it's the SPI check that is redundant and not the find_acq() call. And it's redundant because of the find_acq() patch, not because of the fact that this is in xfrm_state_add(). Now that find_acq() only returns SAs with SPIs, we don't need to check this in xfrm_state_add() anymore. We do still need the call though to clean up leftover larval states. Another side-effect of the change is that we can move the existence check above find_acq() since find_acq() will never return any SAs matching the SPI we're trying to add (It doesn't need to because if an SA with a matching SPI existed, it would've been returned by state_lookup() already). Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/xfrm/xfrm_state.c 1.48 vs edited ===== --- 1.48/net/xfrm/xfrm_state.c 2004-07-30 21:16:40 +10:00 +++ edited/net/xfrm/xfrm_state.c 2004-07-30 22:07:01 +10:00 @@ -400,22 +400,16 @@ spin_lock_bh(&xfrm_state_lock); x1 = afinfo->state_lookup(&x->id.daddr, x->id.spi, x->id.proto); - if (!x1) { - x1 = afinfo->find_acq( - x->props.mode, x->props.reqid, x->id.proto, - &x->id.daddr, &x->props.saddr, 0); - if (x1 && x1->id.spi != x->id.spi && x1->id.spi) { - xfrm_state_put(x1); - x1 = NULL; - } - } - - if (x1 && x1->id.spi) { + if (x1) { xfrm_state_put(x1); x1 = NULL; err = -EEXIST; goto out; } + + x1 = afinfo->find_acq( + x->props.mode, x->props.reqid, x->id.proto, + &x->id.daddr, &x->props.saddr, 0); __xfrm_state_insert(x); err = 0; --y0ulUmNC+osPPQO6-- From ptsjohol@cc.jyu.fi Fri Jul 30 05:56:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 05:56:44 -0700 (PDT) Received: from posti5.jyu.fi (posti5.jyu.fi [130.234.4.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UCualZ015457 for ; Fri, 30 Jul 2004 05:56:38 -0700 Received: from silmu.st.jyu.fi (IDENT:Y1XgaUFiF4BxTZnTE5tIE53QqV7pocLm@silmu.st.jyu.fi [130.234.4.64]) by posti5.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6UCuCcn026069; Fri, 30 Jul 2004 15:56:13 +0300 Date: Fri, 30 Jul 2004 15:56:10 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Robert Olsson cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16650.4736.456106.603065@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti5.jyu.fi; Fri, 30 Jul 2004 15:56:15 +0300 X-archive-position: 7342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev On Fri, 30 Jul 2004, Robert Olsson wrote: > You should monitor the the user app (gettimeofday()monitoring for starvation > this is the most important measure and what we are trying to improve. I can do that after couple of days.. I have to get married tomorrow and spend some time with my wife. =) > We can hardly expect softirq's alone to give us the balance of load we wish. > At overload something has to get less resources. Even we defer all softirq's > to scheduler context there is no way making any distinguish between them > unless we run them in separate processes i.e one RX_SOFIRQ, TX_SOFIRQ etc. > This could solve some problem I just discussed with Jamal where the RX > softirq overruns the TX softirq and causes drop at egress (qdisc) when bus > BW is saturated. Running softirq's under schedules context's can cause other > delays and other problems. Ok, I understand that you can't do 110% if you have only 100% so someone has to wait. It would not matter if networks speed would slow down to 1/100 from the maximum speed if it would still somehow work and not crashing the whole userspace. I don't remember if I have said this but when the ksoftirqd has started to take all the cpu-time there is no way to stop it excluding booting computer. You can kill or stop all the processes which are taking your cpu-time (ie. source compiling) but network wont start to work or neither there is no free cpu-time for use because ksoftirqd won't stop eating it. Actually, for now I would not care how much the kernel would slow down but we have to get some stability. Restarting your computer everytime this happens is not a solution. > So most ksoftirq's runs most softirq's which is good. Without this you would > not be able to type any commands at all. Also we see some effects from the > path. Can you monitor userland starvation here too? Sure.. > > - When the ksoftirqd starts to eat cpu-time time_squeeze-value (3rd > > column) starts growing (in both cases it's same thing). > This OK as we have to throttle. Sure, but we should not crash the whole userspace. Why does kernel suddenly think that it won't give any time for softirq's. Or it does because I can write commands and etc. but the network won't work at all. > > - Total-column's value stops growing although network file transfers > > are still on. (1st column) > Well ksoftirqd now runs RX softirq and competes heavily with other processes > for your CPU you may have to adjust priorities to get your desired balance. > Can you experiment a bit? There is nothing to priorise after I have killed/quitted the jobs which we taking all the cpu-time. Nothing more left than ksoftirqd and it will eat all the cpu-time. Of course I could try something like "nice make -j3" and see if it will still do the same shit. -- Pasi Sjöholm From andreas.steffen@strongsec.net Fri Jul 30 06:40:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 06:40:47 -0700 (PDT) Received: from lists.strongswan.org (pluto.zhwin.ch [160.85.180.0]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UDeco3017394 for ; Fri, 30 Jul 2004 06:40:38 -0700 Received: from [160.85.106.4] (tandoori.strongsec.com [160.85.106.4]) by lists.strongswan.org (Postfix) with ESMTP id 21896496F6B; Fri, 30 Jul 2004 15:40:28 +0200 (CEST) Message-ID: <410A4FC9.1040201@strongsec.net> Date: Fri, 30 Jul 2004 15:40:25 +0200 From: Andreas Steffen Organization: strongSec GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: "David S. Miller" , dev@lists.openswan.org, users@lists.strongswan.org, netdev@oss.sgi.com Subject: Re: SPI generation by netlink_get_spi() References: <4108F5F5.4020001@strongsec.net> <20040730115009.GA5689@gondor.apana.org.au> In-Reply-To: <20040730115009.GA5689@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 7343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andreas.steffen@strongsec.net Precedence: bulk X-list: netdev Hi Herbert, I successfully applied your patch to my 2.6.7 kernel. After kernel recompilation and a system reboot, strongSwan can now handle two identical Quick Modes in immediate succession without any problems. Will your patch make it into the 2.6.8 kernel release? Many thanks Andreas Herbert Xu wrote: > On Thu, Jul 29, 2004 at 03:04:53PM +0200, Andreas Steffen wrote: > >>: | message ID: 65 7e 1a 0f >>: | netlink_get_spi: allocated 0x9f4c9788 for esp.0@145.254.54.68 >>: | SPI 9f 4c 97 88 >> >>The netlink interface of the 2.6 kernel is used to request an SPI for >>the IPsec SA. >> >>Immediately after the first Quick Mode message the second pending Quick Mode >>is inititated: > > >>: | message ID: a1 01 a2 b2 >>: | netlink_get_spi: allocated 0x9f4c9788 for esp.0@145.254.54.68 >>: | SPI 9f 4c 97 88 >> >>And here the error happens. The two Quick Mode negotiations have different >>Message IDs (65 7e 1a 0f versus a1 01 a2 b2) which will cause two phase2 >>state objects to be created on the peer side but the generated SPI 9f 4c 97 >>88 >>is the same. This will trigger the assertion passert(0) in >>kernel_pfkey.c:finish_pfkey_msg() in freeswan-2.0x because twice the same >>SADB_ADD command is executed for the outbound esp. Removing the assertion >>as in Openswan does not help - several retrials will not succeed in setting >>up the IPsec SA. > > > Yes this is a kernel bug. > > The issue is that two successive calls to netlink_get_spi is returning > the same SA. Since netlink_get_spi is meant to be a creation operation > this is incorrect. > > The netlink_get_spi operation is modelled off the PFKEY SADB_GETSPI > command which is specified in RFC 2367. The purpose of SADB_GETSPI > is to create a new larval SA that can then be filled in by SADB_UPDATE. > > Its semantics does not allow two SADB_GETSPI calls to return the same > SA, even if there is no SADB_UPDATE call in between. > > The reason the second netlink_get_spi is returning the same SA is > because in find_acq(), the code is looking at all larval states as > opposed to only larval states with an SPI of zero. > > Since the only other caller of find_acq() -- xfrm_state_add() intentionally > ignores all return values with a non-zero SPI, it is safe to not look at > SAs with non-zero SPIs at all in find_acq(). > > The following patch does exactly that. > > Signed-off-by: Herbert Xu > > In fact, the find_acq() call in xfrm_state_add() is a remnant from > the days when we had xfrm_state_replace() instead of xfrm_state_add() > and xfrm_state_update(). It can now be safely removed. > > I'll post a separate patch for that. > > Cheers, > > > ------------------------------------------------------------------------ > > ===== net/ipv4/xfrm4_state.c 1.10 vs edited ===== > --- 1.10/net/ipv4/xfrm4_state.c 2004-07-09 20:19:08 +10:00 > +++ edited/net/ipv4/xfrm4_state.c 2004-07-30 21:26:21 +10:00 > @@ -74,11 +74,8 @@ > proto == x->id.proto && > saddr->a4 == x->props.saddr.a4 && > reqid == x->props.reqid && > - x->km.state == XFRM_STATE_ACQ) { > - if (!x0) > - x0 = x; > - if (x->id.spi) > - continue; > + x->km.state == XFRM_STATE_ACQ && > + !x->id.spi) { > x0 = x; > break; > } > ===== net/ipv6/xfrm6_state.c 1.11 vs edited ===== > --- 1.11/net/ipv6/xfrm6_state.c 2004-05-27 18:57:44 +10:00 > +++ edited/net/ipv6/xfrm6_state.c 2004-07-30 21:27:07 +10:00 > @@ -81,11 +81,8 @@ > proto == x->id.proto && > !ipv6_addr_cmp((struct in6_addr *)saddr, (struct in6_addr *)x->props.saddr.a6) && > reqid == x->props.reqid && > - x->km.state == XFRM_STATE_ACQ) { > - if (!x0) > - x0 = x; > - if (x->id.spi) > - continue; > + x->km.state == XFRM_STATE_ACQ && > + !x->id.spi) { > x0 = x; > break; > } ======================================================================= Andreas Steffen e-mail: andreas.steffen@strongsec.com strongSec GmbH home: http://www.strongsec.com Alter Zürichweg 20 phone: +41 1 730 80 64 CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65 ==========================================[strong internet security]=== From Robert.Olsson@data.slu.se Fri Jul 30 07:06:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 07:06:16 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UE69jA018687 for ; Fri, 30 Jul 2004 07:06:10 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6UE5tIR023570; Fri, 30 Jul 2004 16:05:55 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id DE7BCEC33E; Fri, 30 Jul 2004 16:05:55 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16650.21955.869485.332365@robur.slu.se> Date: Fri, 30 Jul 2004 16:05:55 +0200 To: Pasi Sjoholm Cc: Robert Olsson , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <16650.4736.456106.603065@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 7344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Pasi Sjoholm writes: > I don't remember if I have said this but when the ksoftirqd has started to > take all the cpu-time there is no way to stop it excluding booting > computer. You can kill or stop all the processes which are taking your > cpu-time (ie. source compiling) but network wont start to work or neither > there is no free cpu-time for use because ksoftirqd won't stop eating it. No you didn't then it seems you are hit by some bug. Have the bug happen. Kill userland processes like as you did. Try find out what's running. I would look in /proc/interrupt /proc/net/softnet_stat /proc/net/dev or maybe best to take a profile if possible or Magic SysRq to find out what's looping. Also try ifconfig down. Cheers. --ro From Robert.Olsson@data.slu.se Fri Jul 30 07:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 07:12:59 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UECrKO019269 for ; Fri, 30 Jul 2004 07:12:54 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i6UECbIR025612; Fri, 30 Jul 2004 16:12:37 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 48E81EC33E; Fri, 30 Jul 2004 16:12:37 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16650.22357.261909.257155@robur.slu.se> Date: Fri, 30 Jul 2004 16:12:37 +0200 To: Pasi Sjoholm Cc: Robert Olsson , Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: References: <16650.4736.456106.603065@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i6UECrKO019269 X-archive-position: 7345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Pasi Sjoholm writes: > I can do that after couple of days.. I have to get married tomorrow and > spend some time with my wife. =) Gratulerar! Jag höll på missa det. No hurry for me I have a couple of days off. --ro From scarfboy@gmail.com Fri Jul 30 08:15:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 08:15:56 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UFFoTk022183 for ; Fri, 30 Jul 2004 08:15:50 -0700 Received: by mproxy.gmail.com with SMTP id 74so45436rnl for ; Fri, 30 Jul 2004 08:15:41 -0700 (PDT) Received: by 10.38.2.75 with SMTP id 75mr4614rnb; Fri, 30 Jul 2004 08:15:41 -0700 (PDT) Message-ID: Date: Fri, 30 Jul 2004 17:15:41 +0200 From: Bart Alewijnse To: netdev@oss.sgi.com Subject: Re: gigabit trouble In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040729210401.A32456@electric-eye.fr.zoreil.com> X-archive-position: 7346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scarfboy@gmail.com Precedence: bulk X-list: netdev On Fri, 30 Jul 2004 00:41:03 +0200, Bart Alewijnse wrote: > I was going to do an exhaustive test, but because my computer stopped > running completely, I'll reply to the one or two bits I can now. ...which was unrelated. Although I can't get the noise anymore now either. I'm not too happy, I like my problems reproducable. Of course, in the course of tring to fix the nonbootability, I changed a bunch of things. Hrm. I'll try getting it back later. > > > So, question one - how do I see the link speed under linux, and how, > > > if at all, do I control it? > > > > ethtool > Thanks. That wasn't the problem - the line speed's a gbit. Definately. I've now seen speeds up to 22MB/s, but only in pure network benching (netio), and only with udp, although I guess that makes a some sense. (Also, for some reason it makes a respectable difference which computer I run the netio server on. I mean, netio measures speed both ways on one run, and it's different depending on where I run it. I guess that suggests io limiting) So the hanging around ten MB/s was just coincidence - it still does it in both nfs and samba, but I guess it's io limited *somewhere*, but trying to figure out why doesn't belong in this list, I guess. Or maybe it does; I've always wondered why samba hangs around 3, 4, 5, maybe 6 MB/s on a 100mbit link - which with netio shows that it can go at 11MB/s, its full speed - and even nfs rarely tops above eight. On my friend's setup too, and he *does* have respectable hardware in his server:) I assume the 20MB/s top speed on my gbit cards is io limiting, and possibly the fact that they're 32bit cards in 33mhz slots. Still, it's far from impressive. Any suggestions (on where to go) about improving it? Anyhow, thanks for the help so far. --Bart Alewijnse From devik@cdi.cz Fri Jul 30 08:58:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 08:58:27 -0700 (PDT) Received: from www1.cdi.cz (www1.cdi.cz [194.213.194.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UFwK0q026430 for ; Fri, 30 Jul 2004 08:58:21 -0700 Received: from gprs40-129.eurotel.cz ([160.218.40.129] helo=devix) by www1.cdi.cz with asmtp (Exim 4.31) id 1BqZlj-0008Mi-Uu; Fri, 30 Jul 2004 17:58:07 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 1BqZiR-0004bu-00; Fri, 30 Jul 2004 17:54:39 +0200 Date: Fri, 30 Jul 2004 17:54:39 +0200 (CEST) From: devik X-X-Sender: To: Patrick McHardy cc: "David S. Miller" , , , Subject: Re: Fw: hfsc and huge set of rules In-Reply-To: <410A2449.3020701@trash.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: devik@cdi.cz Precedence: bulk X-list: netdev Also IIRC class lookup is done before each remove. With hashing size a few tens of buckets the complexity starts to be very near to O(n^2). devik On Fri, 30 Jul 2004, Patrick McHardy wrote: > David S. Miller wrote: > > Looks like qdisc destruction has some expensive algorithms. > > Any quick ideas about the root culprit at least in the hfsc > > case? He says htb does it too. > > hfsc_destroy_qdisc takes O(n) time wrt. the number of classes, > but 5-6 seconds is still long. If all these classes contain inner > qdiscs other than the default, I guess removing the classes from > dev->qdisc_list in qdisc_destroy takes up most of the time, with > n O(n) operations. The __qdisc_destroy rcu callback also calls > reset before destroy, I don't know any qdisc where this is really > neccessary. Without inner qdiscs, I need to see the script first to > judge what's going wrong. Tomasz ? > > BTW: The lockless loopback patch broke qdisc_destroy in multiple ways. > The rcu callback doesn't do any locking, to add locking all > read/write_lock(qdisc_tree_lock) need to be changed to > read/write_lock_bh because the callback is called from a tasklet, > until now all changes to the tree structure were made in > process-context. Additionally it invalidates the assumption made by > dev_shutdown that qdisc_destroy will destroy all qdiscs and clear > dev->qdisc_list immediately. Since qdisc->dev is not refcounted > netdev_wait_allrefs won't notice when the rcu callback hasn't destroyed > all qdiscs yet and free the device, but qdisc_destroy called from > ops->destroy called from the callback will still access the memory. > Patch coming up soon. > > Regards > Patrick > > > Begin forwarded message: > > > > Date: Tue, 27 Jul 2004 11:47:02 +0200 > > From: Tomasz Paszkowski > > To: linux-kernel@vger.kernel.org > > Subject: hfsc and huge set of rules > > > > > > Hello, > > > > I'am running hfsc qdisc with huge set of rules loaded. > > > > root@hades:/home/system/scr/etc/hfsc_rebuild# cat tc.batch | grep hfsc | wc -l > > 27884 > > > > > > Always when I delete the root qdisc (qdisc del dev eth0 root) > > the machine stop responding for about 5-6 seconds. As I think it's due the > > hfsc_destory_qdisc is executed in main kernel thread. Similar problem is > > present also in htb scheduler. > > > > Is there any quick solution to solve this problem ? > > > > > From shemminger@osdl.org Fri Jul 30 09:17:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 09:17:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UGHHRC027381 for ; Fri, 30 Jul 2004 09:17:17 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6UGGx128307; Fri, 30 Jul 2004 09:16:59 -0700 Date: Fri, 30 Jul 2004 09:16:59 -0700 From: Stephen Hemminger To: Ben Greear Cc: Cheng Jin , "'netdev@oss.sgi.com'" Subject: Re: Long-term TCP connections suffer on high-latency links. Message-Id: <20040730091659.0d06352a@dell_ss3.pdx.osdl.net> In-Reply-To: <4109E9E0.9010208@candelatech.com> References: <4109E9E0.9010208@candelatech.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 29 Jul 2004 23:25:36 -0700 Ben Greear wrote: > Cheng Jin wrote: > > > As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in > > wireless networks, BIC TCP, and TCP Vegas are all included besides TCP > > NewReno, although not enabled by default. The others can be downloaded > > from the given websites. There are probably others that I forgot to > > mention. Apologies to them in advance. > > Any chance Westwood will get into the 2.4 kernel as well? Both BIC and westwood are in 2.4 now. From ahu@outpost.ds9a.nl Fri Jul 30 10:07:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 10:07:38 -0700 (PDT) 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 i6UH7VqJ029026 for ; Fri, 30 Jul 2004 10:07:32 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 947B13FEA; Fri, 30 Jul 2004 19:07:26 +0200 (CEST) Date: Fri, 30 Jul 2004 19:07:26 +0200 From: bert hubert To: netdev@oss.sgi.com Subject: ipsec, nat-t, iproute2? Message-ID: <20040730170726.GA5144@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 7349 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 Hi people, I'm once again trying to get a hang of the state of ipsec in linux, and I have some questions. 1) One can configure ipsec over netlink (XFRM_USER), is this the preferred interface? Is it documented somehwere, or is there some source which uses this interface? Alternatively, is PFKEY considered deprecated? 2) I hear people are working on iproute so it can use XFRM_USER, is this code available somewhere? 3) NAT-Traversal, how does one set this up either using setkey, iproute2+stuff, or XFRM_USER? Is it supposed to work right now? Is NAT-T 'UDP_ENCAP_ESPINUDP'? Thanks. What I'll figure out from these questions I'll document. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@outpost.ds9a.nl Fri Jul 30 11:12:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 11:12:58 -0700 (PDT) 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 i6UICojq030806 for ; Fri, 30 Jul 2004 11:12:51 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 729A93FEA; Fri, 30 Jul 2004 20:12:46 +0200 (CEST) Date: Fri, 30 Jul 2004 20:12:46 +0200 From: bert hubert To: netdev@oss.sgi.com Subject: Re: ipsec, nat-t, iproute2? Message-ID: <20040730181246.GA7431@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com References: <20040730170726.GA5144@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730170726.GA5144@outpost.ds9a.nl> User-Agent: Mutt/1.3.28i X-archive-position: 7350 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 On Fri, Jul 30, 2004 at 07:07:26PM +0200, bert hubert wrote: > 2) I hear people are working on iproute so it can use XFRM_USER, is this > code available somewhere? Ok, this is rather embarassing, turns out that this is all discussed on my own LARTC mailinglist. I should read it every once in a while. The code is in the bitkeeper described on http://developer.osdl.org/dev/iproute2/ > 3) NAT-Traversal, how does one set this up either using setkey, > iproute2+stuff, or XFRM_USER? Is it supposed to work right now? > Is NAT-T 'UDP_ENCAP_ESPINUDP'? Sadly, this code does not yet do encap. *Swan appears to have support for this over XFRM_USER, currently reading it. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ptsjohol@cc.jyu.fi Fri Jul 30 11:41:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 11:41:18 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UIf8SM031467 for ; Fri, 30 Jul 2004 11:41:08 -0700 Received: from silmu.st.jyu.fi (IDENT:5b48kNo5/larkWU+hTbMyry+bSfohzTp@silmu.st.jyu.fi [130.234.4.64]) by posti6.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i6UIeTob003619; Fri, 30 Jul 2004 21:40:29 +0300 Date: Fri, 30 Jul 2004 21:40:28 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Robert Olsson cc: Francois Romieu , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <16650.21955.869485.332365@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-360562684-1274709044-1091212828=:23238" X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti6.jyu.fi; Fri, 30 Jul 2004 21:40:33 +0300 X-archive-position: 7351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---360562684-1274709044-1091212828=:23238 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT >> I don't remember if I have said this but when the ksoftirqd has started to >> take all the cpu-time there is no way to stop it excluding booting >> computer. You can kill or stop all the processes which are taking your >> cpu-time (ie. source compiling) but network wont start to work or neither >> there is no free cpu-time for use because ksoftirqd won't stop eating it. > No you didn't then it seems you are hit by some bug. Have the bug happen. > Kill userland processes like as you did. Try find out what's running. I would > look in /proc/interrupt /proc/net/softnet_stat /proc/net/dev or maybe best to > take a profile if possible or Magic SysRq to find out what's looping. Also try > ifconfig down. Ok, now I know how to go back in the normal state of kernel operation. I just have to do "ifconfig eth0 down" and ksoftirqd stop taking all the cpu-time, after that I can do "ifconfig eth0 up" and everything is working fine. So I guess it is 8139too-driver which has a bug. First "SysRq : Show Regs" when the kernel is ok: -- Pid: 0, comm: swapper EIP: 0060:[] CPU: 0 EIP is at default_idle+0x23/0x30 EFLAGS: 00000246 Not tainted (2.6.7-mm7) EAX: 00000000 EBX: c03cc000 ECX: 00000000 EDX: 0006a546 ESI: 00099100 EDI: c0427120 EBP: 0046e007 DS: 007b ES: 007b CR0: 8005003b CR2: 08101000 CR3: 1e9b7000 CR4: 000006d0 [] cpu_idle+0x2c/0x40 [] start_kernel+0x162/0x180 [] unknown_bootoption+0x0/0x160 -- Second "SysRq : Show Regs" when the ksoftirqd has started to take all the cpu-time: -- Pid: 2, comm: ksoftirqd/0 EIP: 0060:[] CPU: 0 EIP is at rtl8139_poll+0xb4/0x100 [8139too] EFLAGS: 00000247 Not tainted (2.6.7-mm7) EAX: ffffe000 EBX: 00000040 ECX: dfa654f8 EDX: c0441978 ESI: dfa65400 EDI: e0868000 EBP: dff85f84 DS: 007b ES: 007b CR0: 8005003b CR2: 080e9024 CR3: 1e9b7000 CR4: 000006d0 [] ksoftirqd+0x0/0xc0 [] net_rx_action+0x6a/0x110 [] __do_softirq+0x7d/0x80 [] do_softirq+0x26/0x30 [] ksoftirqd+0x68/0xc0 [] kthread+0xa5/0xb0 [] kthread+0x0/0xb0 [] kernel_thread_helper+0x5/0x14 -- Third one after I have done ifconfig eth0 down/up. -- Pid: 0, comm: swapper EIP: 0060:[] CPU: 0 EIP is at default_idle+0x23/0x30 EFLAGS: 00000246 Not tainted (2.6.7-mm7) EAX: 00000000 EBX: c03cc000 ECX: 00000000 EDX: 000cf65e ESI: 00099100 EDI: c0427120 EBP: 0046e007 DS: 007b ES: 007b CR0: 8005003b CR2: b7c5a000 CR3: 1e9b7000 CR4: 000006d0 [] cpu_idle+0x2c/0x40 [] start_kernel+0x162/0x180 [] unknown_bootoption+0x0/0x160 -- I also compiled 8139too-driver with debub-options on and the logfile is included as attachment. Everything is going ok until end of the 20:41:29, then it happens: -- 20:41:29 kernel: rtl8139_rx: eth0: In rtl8139_rx(), current 004c BufAddr 0c80, free to 003c, Cmd 0c. 20:41:29 kernel: rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0001. 20:41:29 kernel: rtl8139_rx: eth0: In rtl8139_rx(), current 11bc BufAddr 22e0, free to 11ac, Cmd 0c. 20:41:29 kernel: rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0000. 20:41:29 last message repeated 4 times 20:41:29 kernel: rtl8139_rx: eth0: In rtl8139_rx(), current 2438 BufAddr 242c, free to 2428, Cmd 0d. 20:41:29 kernel: rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0010. 20:41:29 kernel: rtl8139_rx: eth0: In rtl8139_rx(), current 2438 BufAddr 242c, free to 2428, Cmd 0d. 20:41:29 kernel: rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0010. 20:41:29 kernel: rtl8139_rx: eth0: In rtl8139_rx(), current 2438 BufAddr 242c, free to 2428, Cmd 0d. 20:41:29 kernel: rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0010. 20:41:29 kernel: rtl8139_rx: eth0: In rtl8139_rx(), current 2438 BufAddr 242c, free to 2428, Cmd 0d. -- The hardest part is to tell where the problem is but I think that rtl8139_poll-function would be good place to start looking for the bug? readprofile didn't tell much.. Where to go next? I'm not so good programmer that I could find the right place to fix.. -- Pasi Sjöholm ---360562684-1274709044-1091212828=:23238 Content-Type: APPLICATION/x-gzip; name="rtl8139-debug.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="rtl8139-debug.gz" H4sICJGSCkEAA3J0bDgxMzktZGVidWcA7F3LjlzHkd37K2pj2AJkId+PBrTw aCVgjDGMmTWRT6lhiSS6mzY9Xz8ZrXHnucU21XDdrMrqpFaCBF6eOJmVNyLv ORHc32h7o9nh8Ndy97b8dHP47s//c3P4Y30od4cfyttyd5sOt7m8fbit//j6 kML7+5sDk05WX+sh8RQf/4X9/z9P//Ib/rkH/628ze/uPnnu6Q8OP/10uH17 +3D/9Mhf/vnVB4vnHlwefmTtEd//AvO25IPj0h/Sj7fvDw//eF8Ov/vLf//n H+i/ffe73wh2I+2N4P2P3z38RP/vDQF6E9+Fu3xz+PP3/3W4Kz/cvnt7uL/9 33L49tsD+8hbWC/743/602l/nqDfl4fG/OH33CvDtWXafEWPuX2by8eD+frf Ceq77w9//tPh7+Gv5cP7X/sz796Wm0OI7z48HB7ePcZyTyuXy99uUzm8DT83 mhvxv/1tg5hrMDox9tU333zzzHP/jfVR8lNYP/79zf1DuHu4edw6h/ihVtpK Od+V+/ty/8yffPOmkfjm7uObn9/l8oTj6YHwP3/PmRBfHXKL+vCHPxz+8vGQ 3r2ttz88brtqXfjm5MfLlz7+p3D/cPi5xRR+KI349yU8NMrE4eH252ej7MvW Fujuw/uHf0IpH28fbt/+cHj6H1/Tv94Riw8f7r9lH+lvfy6wk57IP/fEu4// fNT3b+E//v6rdhB8uLtrG+SRksN/fKh/bAt7YNyorw/1rhTahbVW9vXhu5/z gaUzLsieRLsbPu8T+eee+JKla6sFSxdcXzrGtdou3StnIrjOhOAKmfDuEybc 7rifeeJLcDeogFvjCgr26QruhftpBZXYm4nnnvgiJjSuYEzIhDpaQX+j7L5M 7PhE/rknvoiJmDoTkjFkIqSVmJD4apIaf9Xi+NU0NRMzcqvh5JEBd5lUahi3 p+MOsCe0xXNC+mvaEycz0YIHJgoyoc2ZzolfT56nYqwAY0bhntd5qZO1BQ9M ONw7Ro77FX0W96vh1uEuy5jTGTtul52OO0MGZg3+Oky6pgxswj3R6ARuI2Yy Vl/TW2tGbiNkMm6TL9swcSbjMLt1Bs9ge67s9rre340kYCziyer0hU7WCzER 4az2DM8TF76c1Sdx2+gEbjd3Mq6OO0/W4BZveXzAfesH3vKcjjvAnghqg9tf 6B3zWvZEo7NzGzdnWZCjf2+K3TCzKxP/4okvYSLiyZM2mUw4Onnob9mfiX33 xL944kuYSJgbpc3NXzzKjeZmYkZu8eYvbW7+khq3y07HjTd/ZXPzl/w17YmT mSh481c2N3/l6OZvGBO/WjnMxRje/FWJOV3J4xj7LO7LMNGCByY2N39VuCv6 FU34u6x481c3N3/VXmiXvQg33Pxxtrn5q+nLnjiFW6ITuMWbP870Nb21ZuQW bv44x3yZszBvJkNQATfe/HF2ruz2Mu9vua8Gac8nfhbjC1ZVVZv7stacUEln 0yfLOhHwhhW0AHivWnP85Hf0itdQU/RwxVyx8JThk1fhq6aiRY9VxuYetIzb FacDb1j78arypjzKS60hRd+pCBzWkKv0SUb6qqlo0T9RIRjDl25g43bFycAJ awduNllOrUutIUXfqYgS1lDo48SJ3wj/b/01vqgEPxstMlDefjXpJX/PKQSd gJzAduQOcxAtjnOQHZGzGblwkNbogj8c7Y7TmtfORYFfjpGY1+j8sl/OhZAT 2I7cYxpi5HEa8spXkcLvXFQBq2j8cWbz2rlo4T9xYTWmNqbycfvidOQEtiOP mIlYfZyJvPJVpPCfuHBMwSracJzcvHIuKPzOhcHsxjE5bl/sgLyB7ciThDet M2KxVWzhP3HhN5d7Lom1MjAKv3OxkRR7rmfOoz0Kdn1GAYI/Fuy++lXMIBgI wuMq5mPBwCvngsLvXDgH+yIIN3MeTWA78mLhTRucXWwVW/hPXESJH+VCMWtl YBR+58KjiTzK449ocyH3YPqO1cObNnq/2Cq28J+4SAqlB/FR5LEQFxR+5yIk 2BdJHcsZ5kLewD4hzyzBmzaFuNYqUvidC11hFTOLa2VgFH7n4lEA+8TFo/F3 2h1NYJ+QF17gTZtjWWsVKfzOhRWwioXntTIwCr9zkbFhS7F85jyawHaVh2Tw pm1n1lqrSOF3LhzaYqqoa2VgFH7noqDEuDo5cx5NYLvQQwl409ZyLAl+3atY KXwwqBkUvSi+VAZWKXyQM2vU0TzaImfd0ZXAdtmL1htBs1prFSl8kACh4J9r tVQGVil80AA5lNKEY4H+VMgJLIiALLxpBbNrrSKFDyqgCKsojFkqA6sU/hMX kqOhWsQwcR5dCWxHbj28aSX3a60ihd+5SBlWUVq3VgZG4T9x0bIx3BcpTZxH VwLbkTtsYalEXGsVKfzORa6wisqFtTIwCr/rECXadVUuM+fRBLYj9wUVlPLY NvvKV5HC71xUDquofV4rA6Pwuw5Rc9wXlc2cRxPYjjxisxGj2VqrSOF3HSLD dpjmk3Yjr5wLCr9zYSTsC8vkzHk0ge3Ik0AFpRGLrWILv+sQN7MMbOJrZWAO hwM4i23M3PFwgMmQW2gS5rJCBaVVi61iC7/rEIXDVcxyrQyMwu9cOGwA5IWd OY8msB15saigdMcNe177Krbwuw5RBlzFYtbKwCj8zoXHVlxB+pnzaALbkVeP Ckp/3Izrta9iC7/rEBW6RUN1a2VgFH7nIqD/NKqB/tMdkAdwiyaGTTBiWMst Win8zoVGt2hix10wXjsXGvynKaL/NOmB/tMdkEdwi2aOfTBSXMstWin8zoVF t2jmAx39U3JhwX+aM/pPsx3oP90BeQa3aNmMxsppLbdoLTgcqzh0i5bj4Viv ngsH/tNS0H9a3ED/6Q7IC7hFq0JHfylruUUrhd+58OgWrWqgo39KLjz4T2tF /2n1A/2nOyCv2F5ao6O/rfBKqxgYhQ9jA9AtyvRAR/+UXATwn3KG/lMWBvpP T0dOYDtys23XuZRbtHFhwNHPI7pFuRno6J+Siwj+U8HRf8rjQP/p6cgJbEdu 0dEv+FJu0caFBUe/SOgWFXago/+zXLwAeYyVgZahGtQyVLaUlqFxYUDLUCNq GapeSsvQuIg43JOjlqHGibUMMRFYGJOIWgbGl9IyNC4saBlYQi0Ds0tpGRoX CbQMXGxGsqWJtQwxcRxrzx1qGfjxWPvXvooUfucio5aBu6W0DI2LDFoGIVHL wPPEWoaYCGxH7lHLIORSWobGhQctgyioZRB+KS1D46KAlkEq1DKIMrGWISYC 25EH1DJItZSWoXERQMsgK2oZZFhKy9C4qKBlUBq1DLJOrGWIicB25BG1DEov pWVoXETQMmiGWgYVl9IyxEThdy4Mahk0m1jL0JAb0DLohFoGbZbSMjQucDqB Eahl0COnE8zIBYXfuXCoZTBiYi1DQ+5Ay2A20wmMXUrL0LjA6QRWopbBjJxO MCMXFH7nwqOWwcqJtQwNuQctg91MJ7B+KS1D4wKnEziFWgY7cjrBjFxQ+J2L gFoGpybWMjTkAbQMfjOdwIWltAwxeZxO4DVqGfzI6QRTcqFBy+Ajahm8nljL 0JBH0DKEzXQCH5fSMsQUcDpBMKhlCCOnE0zJhQEtQ0ioZQhmYi1DQ55AyxA3 0wlCWkrLEFPE6QTRopYhiktpGS7FhYVe2jFjL+1oB/bS3gF5hs7XaTOdIOal Ol/HlHA6QXLY+TqNnE4wJRcOemknj1VycgN7ae+A3ENNmyrWtMlPXdMSWOhC jzVtqovVtBR+5yJgTZv1YjUthd8dJwxr2hymrmkJbEdusKYtbLGalsLvXESs aYtZrKal8LuCkmNNW+LUNS2B7cgt1rSVL1bTUvidi4Q1bbWL1bQUfldQCqxp a5q5ps0EtiN3WNMysVZNmyn8zkXGmpa5tWraTOF3BaXEmpblmWvaTGA7co81 LZdr1bSZwu9cFKxpuV+rps0UfldQKpwPxcvMNW0msB15wIl7Qi01zalxEWDi nmQ4zUmEgRP3ZuSCwu9cGJwPJdnA+VA7IDcwzUlGnLgn9VLTnBoXESbuKY7T nGQcOHFvRi4o/M6FxflQig+cD7UDciuwCz1O3FN2qWlOjYsME/e0wGlOKg+c uDcjFxR+58LhfCgtBs6H2gG5g2lOuuDEPe2WmubUuCgwcc9InOaky8CJezNy QeF3LjzOhzJy4HyoHZB7mOZkKk7cM36paU6NiwoT96zCaU6mDpy4NyMXFH7n IuB8KKsGzofaAXmAaU6O4cQ9G5aa5hQzhd+50DjNybGBE/em5ELDfCgXcT6U 0wPnQ+2APMI0J89x4p6LS01zipnC71wYnObk+cCJe1NyYWA+lE84H8qbgfOh dkCeYJpTEDhxz6elpjnFTOF3LhxOcwpi4MS9Kblw0FMpFOypFNzAnko7IC/Q ASlKnLgX8lodkDKF37nw2AEpyoET96bkwkNPpVixp1L0YuY8msBCF3qcuBfr Wh2QMoXfuQjYASnpgRP3puQiQE+lzLCnUgoDeyqdjpzAduQGu9RltlYHpEzh dy4idkDKZmCXuim5iNBTqXDsqZTjwJ5KpyMnsB25xS51ha/VASlT+J2LhB2Q ih3YpW5KLhL0VKoCeyqVNLCn0unICWxH7rBLXctH1lpFCr9zkbEDUnUDu9RN yUWGnkpMYk+lmgf2VDoZeSGwHbnHLnVMrtUBqVD4nYuCHZCYH9ilbkouCvRU 4gp7KrEysKfS6cgJbEcesEsdV2t1QCoUftchMuyAxMPALnUzckHhdy4M9lTi dWBPpR2QG+iAJCJ2qRN6rQ5IhcLvOkSOblERB3apm5ELCr9zYdF/KvlA/+kO yC24RWXGLnXSruUWLRR+1yEKdIvKPLBL3YxcUPidC4f+UyUG+k93QO7ALaoK +u+VW8stWij8rkOU6BZVZaCjf0YuKPzOhUf/qZYD/ac7IPfgFtUVHf3ar+UW LRR+1yEqdIvqOtDRPyMXFH7nIqD/1KiB/tMdkAdwi1qGjn4T1nKLFgq/c6HR LWrZQEf//lxMya4GR6uN6Gi1ei1Ha6Hwu7KRY9cBG9dytBYKv3Nh0NHq+Mxd BwqB7cgt1t3OnMvR+lO4fzj8XO7vww/lcFfel/BQ8kEcHm7bf5yQMwv1ubP4 FdvZc/WHep4zPS9n8LXblU1XXbvWBKFC4XcFrcKa0pWBNeXpyAlsR+43PXDV uSrA53e+nHXnE03AGX5P9f5SleIkT7zmtwAtZV/Xit+GvZ/62zCB7Xpnjd+G fV3s2zCF37kI+G046MW+DVP4nYuItWMIU38bJrBd78yxLgtxsbqMwod+0FiX Rb5YXUbhdy4S1mXRTl2XEVjoZI11WUyXrcvsrG9koqlzVrALT8xTfzclsF3p r9QG+VpdeAqFD66HTcdrdanq6FJchE0Pbay3UrhUD+3Xs9MqVGapYmWW6rl6 yJ71Hkd9qcw36w8VXNZYwaU6dQVHYMFHgxVc1otVcBQ+dGXHCi7HmWdQFwIL DiCstwo713zTK/vNEk2dM4HK18IHVnoXufsy066CAM1tcai5LXytOaaFwu9c ZFTxFjtQxTtjvkrhd++Qwgqs5JlnTRcCC8hRrVnluSqwK7sBJ5qAM/Q+VnVV U0VmPFeI0M5uQDdlVQPdlFNyEcCfydjGnxkG+jMnPGMrhd+50Fi1MnZV/swJ d1olQju7aTOFQ89cE1YC2/1xAlWQLK2lgqwUfufCbfxx4lwqyOtS6FSiCSZU 4GwDbmf20VUCC/MkcFoML2tNIqgUPkyowDxWqIHTYl6w89WsO1/gxPdfHHZ9 ksXM7qRKYMEpiDM4JF+rv3ul8DsXm2nW0g6cwXHNO1/iHG0lsQ+3HDlH+3Tk BLYj95vJBnKtrtmVwgePIqoclB842eCasx2iqXNWsS+zKmtNcqoUfncEMry1 U/VcnZ6v7OQkmoAz7IKs6lqKjUrhdy44zgrS7Fx9la9t/3CYUqQF9hzWfK0p RZXCxylF6Ejm5+pifF3fQSvRBF587PCrxcCZQDPeiFL42JcAf0vyXD2Dr+38 kTCBRyu17V+wVv5D4QMXOHVGq3N16L22/aNg3o3W2L1Wq7Xm3VQKH7jAWkLr c/XDvbb9o7HmMPh1U+u1pstUCh+4wFpCm3N1n722/MdgzWFRu6nNWrNcKoUP ky03tYQ9lxr02s4fhzWHwz6o2q41OaVS+NDLalNLuHN1Vr22/eOx5ghs00Vr YM2xA/IAekUdNpm/P1fX0Wtb7YAVQhR4woaBFcIOyCN05NRxk6fHc3XkvLbc ImI+n9CNp+Na8y0qhQ9cbPL0dK7+l9d2WiTM5/OmN2Raa5pEpfCBi02ens/V bfLa9k/GfL6gBlHntdxdlcIHLjZ5ejmXqvHa9k/BfL5iNwxd1pqUUCn83tWU bfL0eq5uGFeW/xBNwBkqQXW9lKPphchBCWo45umGnUsJemWnBdEEnFU4YQ0f WCHsgbxCx2KBebrh5Utu8SxnAvJ5I1HrasTMvQcrgQXkmFUbeS6t67WttoTs 2zx68jpnA7PvGVUCFD72et/0N5dfMoHnOYPs22jUBxu1mKeIwgcuMKs2+lyK 42s7fzRm38bhma0HZt87IG9gATnmwMbYL7nF85xh9m0jnrBmMR8Whd+5yBW5 sGHqGqqB7TMOJLoJTC5rKQsp/M6Fx2zZyst2YZw2ZyCagLOKcyH8wDx9D+S1 n1+2loTIy1rnF4UPEy1Q029rXusOkcLvXETMgp05l1b/ynIBoqlzlhTOFYmL +fMofOACs2CX5MwnIoHtPe6Fw1VMA7Pg/XMBPSG7RGhn16FvwQu7VqZF4Xcu MtYO3p3Lj3Bd/bcq0dQ5K9gVyeeBNcaMZyyF32cXqIRclIFdkU5HTmBhAgW6 B4KKa70pKfzORcXaIYQvTuTnOatQtcRHv+0TZ3WxqoXChzkgHH5LkaW1TkQK H+aAcJwgwdlaFRyFD9M00CERLVtsX2RwPiSBlVlMl3VbT5tpEU2ds0dP8VOn eDGwgptx/1D4wIWB31IrZmfOtAhsR+41rqLUF/oadSkuWvgw+wJdIMmrqVex ghcjK6x6Uj2XW3vSJ57OLhHa2Q042zarqeuoHKGLX+GoBsvxqrpRn84Fhd+5 MFgTFH5Z18a0HcGIJujjj/0DixlYO+yAPEMXvypR2VTywC5+M+58Cr9z4TFT q/KyfoFpdz7RBJyhVqH6qTM6AtuRV9QqVD9QqzDlzq+gVWAGte+1LtXRMDEK v3Px6Nl86oVuLut6nfQUaJw1mqB/PH7xZ1HP+/5LjMBCt3dUhnOxVC+9xoUD xTfPOP2Xuy9+y+c5ywH7x+N3WJ4nnhKcGIGFbu+oSRZqqS5ujYsAWmNRMYsR 4bJOv2nPfKKp90w3+O1R1EtpPV+EnMBCt3fUC0izVP+wxkUCHYB6dHH1Lu7n 0gFc2c4nmqDzPX4dU0KMO/Pn0yE1LiR8HVMev44pOfDr2A7IPcMu7uhvU26p Ll6Ni6qwoytq9VS9rL9t2lOAaILOnfhFSKtLKfBehlxr7L8aYOdrPfD7zYw7 n8KHHldlw4Wf12XWkMeC3vtNp4U48M5mvi+SiVH44B7DWUaGX7Z3w6S6hMYZ zjwyFh0r5mwzjyZ94h7sggfGOMyrjb0qD8yU7DrIwE3B+0bjBmbgU559BW4w rdp05SgDbzBn5ILCB/8gTvayaqmZdo0LnOxlg4R3oh052WsH5A1s9zwx7Cls g5g5J3MM7lSd2bj92GJ3qhQ+OB+xynDmS8+L5zmLUI384pLrzsepqxECC8jR Q+OS+fLt6HnOwL3jRdx4Owe6d05HTmA7cr9xj4nFbtApfHDSJTjnvJ9Y9diQ F5hX7yveY/tyqXn1y50CRDysQsHfUp36Bp3Adsedxv66vua1qrBgYKZDSOge C+Zcc+Rm4SKhe4zjzXhI53KPXVXnm8SIps7Zoy+oO+4u5am4FBctfOACs+Ao xJdv0s9zBvl3fHQkdc7OlX/PwoUEN0eUAX9LcqCbY8rfUgu/c+FxBkd8VPuv tC88zNaIFauW6JeardG4qFC1JIVVS6wDq5Zr/mJGNHXONLp8khpYL824fyh8 4AKrlqQH+ob2QA5VS4pYtSQ9sGqZchUjTPvIHL1+KS417SMxCr9zYRm6V/lV 9f+Ykt1GKLCLOpts6mI7zYJyJxd0W2V7KeXOy5AX8EYVhQ7JXM7ljZqECwq/ c+Gx4ipqoPPxmu86iabOWUDdRvGXqsxehjyAyqIyVFmUsJhPjMLvXBh0SFa2 mMqCwu9cRKwJqhnofLzmuyqiqXOW0DNX49S1A4Ht3mCB+o6a1tJ3cAq/c+HQ LcrEQH3HDsgdeDZbTgP7j7mBns0r/s1yoqlzVlCrwPLMOSsnsN3VrNDt197q S725OYXfuQjoc+Vqqa6/jYsA/lXBMBfl4Vz9P64rf+dEU+fMYI9dwS6lNX4Z cgOdbkVGPb4wS3W6bVxkUM9LgfmXyAPV89f8/iOaOmceO59KMTDz2wG5h/6j sqK3U/ql+o82Lip4NpXCLEbWgZ7Na975RFPnTOMXZKUG5k87INfwvVdF/N6r 9FrfezmF332uHPXZKp7re+//tXdvWYrbQABAtyS/IbvBBva/hIznIy53mJyZ NLZldDfQfV0IU3qUKpNYzI+/xGKIdxZ01V5dE072FpjDtMTsHncKu37D2xLe IL+Hfb2+jaecu/up9vW+H4v58ZdYXOPNzX271132Jxv5c5iWmN3ibl1/3fDO 6DfIb2G3bkjxtvX+tuFuXYbn4Kr58ZdY9LEabUgb3t+e41tgfvwlFuMjdibt N6wyO/PKxxympb7tZ43TPzEb7xlXaVQzdpFf4mnYS30ta/1zfvwlFo9YWXy5 7HUa9mS/f3OYlvqk9hnenJfHhpUt35fP2EV+W1VWtY+cc9YZu1QTpSFW5t32 OqN4snE6h2mJ2aqHwy31ZeX5t9jD4TbElY/blj0c3iAfYi/Ge6z9uQ2FrVPM jx/qoMb4Kd7V1L+M2RymUPsT+1mM9a2s8TPGfhZjE0+6j1v2s3iHPJxLH9uY p43NXufSz1VBWs1hWmLWpTjy27IqkKv58UMs4jrX2D7t7b+OWVjnGlc9QMbu VL3R3hCL2ANk7GP+PR7cAyTf8dOH/HscYv499oXl3/Pjh1isqm6HY3uo5Tt+ hlidu+rEMg6F7daOsRPLeImZ/3hwJ5Z8859LzPyvq8z/Ulrmf42Z/3WV+V+P 7WSX7/vnGuccq34447WsWthqjP1wxnE1lzi4H06+42eMc44x3sc+3jacc7xD Hm5PH6dV5j8ee3t6vp/2FGcI0zO+YaeyKmGr+fGXWNxXmf/0kK28jNk9zhAe sZ50vGe9Qj9jg3yVpz/2qv4829viEfP5Va+h8bFXPp9LLGKvofG5ytMP7jWU 7/h5hnx+bn8QY7ZXPp9JLObHD7GIefqU3Cv+i5iFfH6qLvHOo7RhPv8G+Q9s kMeseqoGucXrmIV8fqpjxeu0ZTekHM99zo8fYhHz9Kk+tr9lvm+LOuTzU3OP b9h6r3w+l1j8ePxwT2LM06dmkq28jFnswjO1sUp42rILT5bvnzbUHU9dzPyn dq+647ONny7MEKY+3qU+dRvOEN4g78PN59Oq/8/Uu/n8FzGL+fwQK6un3foE 5RKLIdRqT8MqTx/2qtU+29tiiDOER+w2MA17zRCyiMWMWu7oSXGu9Hzuderp Q3/J53Ausa3iHklKx+6R9Hl+M+cghbvS4q5Aqo6qPvzzb1Hc+wzfojs3Nzc3 Nzc3Nzc3Nzc3N3e+7t1Wxc664vT+tbfz3iqxXsOq4umBTdewMlxbrsN51VTH irZUq2h7GbFQz5aaeE421RvWs33b3YSzqqmJtWepObb2LNdPugmVZ6mNJ1pT s2Hl2bfdbThVmtpYJZbao+6H2GrsZLr/PYd9+Qy6eJo1tRtWnWW4w9aFM6qp j/ll6o6tOct17PQxs+1jZpu6z9nv/fMcP973sd/O97l+s1K47ePr7CLjW22/ ZOTxZo79MvJzfdJVuJfj6z58UfdyZDyHyfUX5qA5TIZjZ53jx54Bm+b4Jx47 begY8GV20WTcMeBLRh7vnjsuI/+t/Dnc/5a62NUpdXvd//Z6hNaZjtAudvPs Y9aYuqN6On3K+zKHjDzTvyh33zd3f28GXa16n35QBn1QbEN3sS85eXVUd7EM cu06duUoLdeuQ6+N1NSrWceGvTaK+O1oQgfXr/OYDTu4ZhiJ9fykS6eZn3Rx 1+a62rVpfTu+uSMW535TWu2IFfXt+PHwS6fw6rbajRnPtDf43UhUVegiU11S WA+oqg27yOQ3JuaHD5Howm9HNTw/7ERSpqtqc9iXPubNJX4Gl9Yu6b8jNgcp RCx2Lq2bId/f+bq9hS7tfRU71rfXM33bvhuJZnqEPs6XKoz5ZrofOuZzrb09 aPXtvStbU+xVn/XKVhVXMerV3L3achXjLbvSv/UuapZ3Ud3GGXn9szvPNme/ q//Mgbi5ubm5ubm5ubm5ubm5S3E3aQ/3q//CzZ2PW4S4ubm5ubm5ubm5ubm5 ubm5uct0ixA3Nzc3Nzc3Nzc3Nzc3Nzc3d5luEeLm5ubm5ubm5ubm5ubm5ubm LtP9f/9Td9IIcXNzc3Nzc3Nzc3Nzc3Nzc3NzWxnj5ubm5ubm5ubm5ubm5ubm 5i7ZLULc3Nzc3Nzc3Nzc3Nzc3Nzc3GW6RYibm5ubm5ubm5ubm5ubm5ubu0y3 CHFzc3Nzc3Nzc3Nzc3Nzc3Nzl+kWIW5ubm5ubm5ubm5ubm5ubm7uMt0ixM3N zc3Nzc3Nzc3Nzc3Nzc1dpluEuLm5ubm5ubm5ubm5ubm5ubnLdIsQNzc3Nzc3 Nzc3Nzc3Nzc3N3eZbhHi5ubm5ubm5ubm5ubm5ubm5i7TLULc3Nzc3Nzc3Nzc 3Nzc3Nzc3GW6RYibm5ubm5ubm5ubm5ubm5ubu0y3CHFzc3Nzc3Nzc3Nzc3Nz c3Nzl+kWIW5ubm5ubm5ubm5ubm5ubm7uMt0ixM3Nzc3Nzc3Nzc3Nzc3Nzc1d pluEuLm5ubm5ubm5ubm5ubm5ubnLdIsQNzc3Nzc3Nzc3Nzc3Nzc3N3eZbhHi 5uYuy93+lS7vdb/+i9zcp3UX9Kjc3Nzc3Nzc3Nzc3Nzc3Nzc3Nxv3DT7/Ahx c3Nzc3Nzc3Nzc3Nzc3Nzc3+mW4S4ubm5ubm5ubm5ubm5ubm5uct0ixA3Nzc3 Nzc3Nzc3Nzc3Nzc3d5luEeLm5ubm5ubm5ubm5ubm5ubmLtMtQtzc3Nzc3Nzc 3Nzc3Nzc3NzcZbpFiJubm5ubm5ubm5ubm5ubm5u7TLcIcXNzc3Nzc3Nzc3Nz c3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nz c3Nzc3Nzc3Nzc3Nzc3Nzc3N/pvtv0llo08WjBAA= ---360562684-1274709044-1091212828=:23238-- From jmorris@redhat.com Fri Jul 30 11:55:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 11:55:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UItUie031997 for ; Fri, 30 Jul 2004 11:55:30 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6UItKe1007576; Fri, 30 Jul 2004 14:55:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6UItKa31758; Fri, 30 Jul 2004 14:55:20 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i6UItKc2019891; Fri, 30 Jul 2004 14:55:20 -0400 Date: Fri, 30 Jul 2004 14:55:19 -0400 (EDT) From: James Morris X-X-Sender: jmorris@dhcp83-76.boston.redhat.com To: bert hubert cc: netdev@oss.sgi.com Subject: Re: ipsec, nat-t, iproute2? In-Reply-To: <20040730170726.GA5144@outpost.ds9a.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Fri, 30 Jul 2004, bert hubert wrote: > 1) One can configure ipsec over netlink (XFRM_USER), is this the preferred > interface? Is it documented somehwere, or is there some source which uses > this interface? Alternatively, is PFKEY considered deprecated? PF_KEY is not deprecated, it's an IETF standard and required for compliance & compatibility. XFRM_USER is simply the native Linux interface. - James -- James Morris From romieu@fr.zoreil.com Fri Jul 30 11:56:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 11:56:47 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UIudDm032715 for ; Fri, 30 Jul 2004 11:56:40 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i6UIsCh9016448; Fri, 30 Jul 2004 20:54:12 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i6UIsCod016447; Fri, 30 Jul 2004 20:54:12 +0200 Date: Fri, 30 Jul 2004 20:54:12 +0200 From: Francois Romieu To: Bart Alewijnse Cc: netdev@oss.sgi.com Subject: Re: gigabit trouble Message-ID: <20040730205412.A15669@electric-eye.fr.zoreil.com> References: <20040729210401.A32456@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from scarfboy@gmail.com on Fri, Jul 30, 2004 at 05:15:41PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 7353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Bart Alewijnse : [...] > Definately. I've now seen speeds up to 22MB/s, but only in pure > network benching (netio), and only with udp, although I guess > that makes a some sense. It seems low. On a non-napi setup, I'd expect your celeron box to stand at least 20~30 kIRQ/s if the hardware is not flawed. [...] > I assume the 20MB/s top speed on my gbit cards is io limiting, > and possibly the fact that they're 32bit cards in 33mhz slots. > Still, it's far from impressive. Any suggestions (on where to > go) about improving it? See Documentation/networking/ip-sysctl.txt and the r/wmem parameters for a start. The 2.6.8-rc2-mm1 version of the r8169 driver is suggested. A dumb 'vmstat 1' output during test could give some hint. Can I assume that the systems are stable if not fast ? -- Ueimor From tmattox@gmail.com Fri Jul 30 12:29:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 12:29:42 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UJTXGV004239 for ; Fri, 30 Jul 2004 12:29:34 -0700 Received: by mproxy.gmail.com with SMTP id 73so65300rnk for ; Fri, 30 Jul 2004 12:29:25 -0700 (PDT) Received: by 10.38.3.79 with SMTP id 79mr43274rnc; Fri, 30 Jul 2004 12:29:25 -0700 (PDT) Message-ID: Date: Fri, 30 Jul 2004 15:29:25 -0400 From: Tim Mattox To: Jeff Garzik Subject: Re: [RFC,PATCH] fastroute dead code... Cc: davem@redhat.com, hadi@cyberus.ca, netdev@oss.sgi.com In-Reply-To: <20040730060348.GA22854@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040730060348.GA22854@havoc.gtf.org> X-archive-position: 7354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@gmail.com Precedence: bulk X-list: netdev I looked into fastroute about a year ago as well. It's been used in some clusters AFAIK, but I'm not sure if it's still being actively used. I was considering trying to use it myself in some cluster FNN research work I'm doing. But that's probably still 6 months away if I get to it. Since I'd be having to patch other things anyway, I have no qualms with it going away from mainline... Especially with GigE so cheap today, and legacy PCI bandwidths so low, it's not particularly economical today to route through nodes in an HPC cluster that uses TCP/IP interconnect. I don't know if the webserver/load balancing community would mind it going away though. On Fri, 30 Jul 2004 02:03:48 -0400, Jeff Garzik wrote: [snip] > This actually does something, dependent upon options from the packet > socket, so I left it alone. The rest was dead code. > > If nobody objects I can push to David, but right now this is more > an RFC than a merge request for David. [snip] -- Tim Mattox - tmattox@gmail.com - http://homepage.mac.com/tmattox/ From garzik@havoc.gtf.org Fri Jul 30 12:35:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 12:35:49 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [216.162.42.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UJZPR1004640 for ; Fri, 30 Jul 2004 12:35:44 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id D02F976C2; Fri, 30 Jul 2004 15:35:15 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i6UJZFXr011479; Fri, 30 Jul 2004 15:35:15 -0400 Date: Fri, 30 Jul 2004 15:35:15 -0400 From: Jeff Garzik To: Tim Mattox Cc: davem@redhat.com, hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC,PATCH] fastroute dead code... Message-ID: <20040730193515.GA11365@havoc.gtf.org> References: <20040730060348.GA22854@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 7355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Fri, Jul 30, 2004 at 03:29:25PM -0400, Tim Mattox wrote: > I looked into fastroute about a year ago as well. It's been used in > some clusters > AFAIK, but I'm not sure if it's still being actively used. I was > considering trying to > use it myself in some cluster FNN research work I'm doing. But that's probably > still 6 months away if I get to it. Since I'd be having to patch > other things anyway, > I have no qualms with it going away from mainline... Especially with GigE so > cheap today, and legacy PCI bandwidths so low, it's not particularly economical > today to route through nodes in an HPC cluster that uses TCP/IP interconnect. > > I don't know if the webserver/load balancing community would mind it going > away though. Well my main point is that the code _doesn't do anything_. It is dead code, as-is, in the kernel. It would require patches to actually work at all. It is impossible that fastrouting is being actively used, without patches. Jeff From davem@redhat.com Fri Jul 30 13:10:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 13:10:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UKAbdP005700 for ; Fri, 30 Jul 2004 13:10:40 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6UKAVe1026429; Fri, 30 Jul 2004 16:10:31 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6UKAVa24841; Fri, 30 Jul 2004 16:10:31 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i6UK9eml010930; Fri, 30 Jul 2004 16:09:46 -0400 Date: Fri, 30 Jul 2004 13:10:04 -0700 From: "David S. Miller" To: Jeff Garzik Cc: tmattox@gmail.com, hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC,PATCH] fastroute dead code... Message-Id: <20040730131004.2be1274d.davem@redhat.com> In-Reply-To: <20040730193515.GA11365@havoc.gtf.org> References: <20040730060348.GA22854@havoc.gtf.org> <20040730193515.GA11365@havoc.gtf.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 30 Jul 2004 15:35:15 -0400 Jeff Garzik wrote: > It is dead code, as-is, in the kernel. It would require patches to > actually work at all. > > It is impossible that fastrouting is being actively used, without patches. I totally agree. And people can always resurrect it from the repository history or an old tarball if they wish. I think it should be killed entirely, and that's what I'm going to do. From tmattox@gmail.com Fri Jul 30 13:29:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 13:29:23 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UKTEHZ006284 for ; Fri, 30 Jul 2004 13:29:17 -0700 Received: by mproxy.gmail.com with SMTP id 73so68108rnk for ; Fri, 30 Jul 2004 13:29:06 -0700 (PDT) Received: by 10.38.5.73 with SMTP id 73mr167600rne; Fri, 30 Jul 2004 13:29:05 -0700 (PDT) Message-ID: Date: Fri, 30 Jul 2004 16:29:05 -0400 From: Tim Mattox To: Jeff Garzik Subject: Re: [RFC,PATCH] fastroute dead code... Cc: davem@redhat.com, hadi@cyberus.ca, netdev@oss.sgi.com In-Reply-To: <20040730193515.GA11365@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040730060348.GA22854@havoc.gtf.org> <20040730193515.GA11365@havoc.gtf.org> X-archive-position: 7357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@gmail.com Precedence: bulk X-list: netdev The code that uses (used?) fastroute is not in mainline. AFAIK there were two ethernet drivers that you could load that used it, one tulip based and the other 8390 based. Here's one of several archives of the ancient driver code: http://www.linuxgrill.com/anonymous/fire/alexey/fastroute/ They do not look like they have been maintained, in many years. It dates from early 2.2 kernel days. Apparently in it's day, a Linux box with fastroute could keep up with a Cisco router, but I've not been able to find the relevant benchmark numbers via google as of yet, and I've stopped looking. So, yes, I don't dispute that it's dead code as seen in mainline kernel source, and should probably be removed now. If it was still important, we would have seen fastroute GigE drivers by now, IMHO. On Fri, 30 Jul 2004 15:35:15 -0400, Jeff Garzik wrote: [snip] > Well my main point is that the code _doesn't do anything_. > > It is dead code, as-is, in the kernel. It would require patches to > actually work at all. > > It is impossible that fastrouting is being actively used, without patches. > > Jeff Some might consider dropping in a new network driver module a patch, others wouldn't... Anyway, as I said before, IMHO I agree its dead code worthy of removal unless someone comes up with a GigE driver that actually uses it. -- Tim Mattox - tmattox@gmail.com - http://homepage.mac.com/tmattox/ From hadi@cyberus.ca Fri Jul 30 13:29:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 13:29:31 -0700 (PDT) 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 i6UKTNJ1006289 for ; Fri, 30 Jul 2004 13:29:23 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1Bqe0F-0005xm-K9 for netdev@oss.sgi.com; Fri, 30 Jul 2004 16:29:19 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bqdyr-0000ID-LS; Fri, 30 Jul 2004 16:27:53 -0400 Subject: Re: [RFC,PATCH] fastroute dead code... From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Jeff Garzik , tmattox@gmail.com, netdev@oss.sgi.com, Ralf Baechle In-Reply-To: <20040730131004.2be1274d.davem@redhat.com> References: <20040730060348.GA22854@havoc.gtf.org> <20040730193515.GA11365@havoc.gtf.org> <20040730131004.2be1274d.davem@redhat.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1091219266.1029.470.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 30 Jul 2004 16:27:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7358 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 Fri, 2004-07-30 at 16:10, David S. Miller wrote: > On Fri, 30 Jul 2004 15:35:15 -0400 > Jeff Garzik wrote: > > > It is dead code, as-is, in the kernel. It would require patches to > > actually work at all. > > > > It is impossible that fastrouting is being actively used, without patches. > > I totally agree. And people can always resurrect it from the > repository history or an old tarball if they wish. Patches are needed for the driver to use that code. So its not entirely dead code i.e it is referenced from fastroute enabled drivers. Sample (really old) code found at: http://ftp.iasi.roedu.net/mirrors/ftp.inr.ac.ru/ip-routing/fastroute/ > I think it should be killed entirely, and that's what I'm going > to do. Nod from here. Before you kill it lets hear from Ralf who is acquinted with someone that uses it and sings praises of it (although i personaly dont believe it ;->). cheers, jamal From hadi@cyberus.ca Fri Jul 30 13:38:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 13:38:59 -0700 (PDT) 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 i6UKcm1P007023 for ; Fri, 30 Jul 2004 13:38:51 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1Bqe9M-0003UO-6j for netdev@oss.sgi.com; Fri, 30 Jul 2004 16:38:44 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Bqe9I-0001PC-GL; Fri, 30 Jul 2004 16:38:40 -0400 Subject: Re: Fw: hfsc and huge set of rules From: jamal Reply-To: hadi@cyberus.ca To: Tomasz Paszkowski Cc: Patrick McHardy , "David S. Miller" , devik@cdi.cz, netdev@oss.sgi.com In-Reply-To: <20040730110815.GA7812@krezus.e-wro.net> References: <20040729211844.61e8d328.davem@redhat.com> <410A2449.3020701@trash.net> <20040730110815.GA7812@krezus.e-wro.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1091219916.1029.496.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 30 Jul 2004 16:38:37 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7359 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 Tomasz, Have you verified that this happens on other Linux versions like earlier 2.4.x (2.4.21 for example)? Also can you try just deleting the filters first and see what happens? i.e something like: filter add dev e0.931 protocol ip parent 1:101 pref 5 filter del dev e0.932 protocol ip parent 1:101 pref 5 .. delete them as specified above because that nips them at the prio level. BTW, since you are one of the few people i have seen use clever hashing tricks with u32, could you test out u32 in 2.6.8-rc2 and make sure it doesnt break anything? There is a bug fix that deals with selecting hash buckets. cheers, jamal From Manish_Lachwani@pmc-sierra.com Fri Jul 30 13:43:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 13:43:16 -0700 (PDT) Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.com [216.241.224.12]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i6UKh5eL007392 for ; Fri, 30 Jul 2004 13:43:09 -0700 Received: (qmail 19621 invoked by uid 101); 30 Jul 2004 20:42:56 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 30 Jul 2004 20:42:56 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id i6UKgomh027944; Fri, 30 Jul 2004 13:42:50 -0700 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 30 Jul 2004 13:42:50 -0700 Message-ID: <9DFF23E1E33391449FDC324526D1F25902833769@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> From: Manish Lachwani To: "'hadi@cyberus.ca'" Cc: Jeff Garzik , tmattox@gmail.com, netdev@oss.sgi.com, Ralf Baechle Subject: RE: [RFC,PATCH] fastroute dead code... Date: Fri, 30 Jul 2004 13:31:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-archive-position: 7360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Manish_Lachwani@pmc-sierra.com Precedence: bulk X-list: netdev Is this a 2.6 issue or a 2.4 issue? This is because I am using 2.4.21 kernel and so do the customers of the board. This board supports 1.0 Ghz PMC-Sierra Rm9000 processor. With fast routing, the IP forwarding numbers are about 900 Kpps. While in the case where there is no fast routing, the numbers are about 450 Kpps (NAPI enabled) I still have not done any 2.6 benchmarking since the board support is not completely functional in 2.6 as yet. Thanks Manish -----Original Message----- From: jamal [mailto:hadi@cyberus.ca] Sent: Friday, July 30, 2004 1:35 PM To: Manish Lachwani Cc: Jeff Garzik; tmattox@gmail.com; netdev@oss.sgi.com; Ralf Baechle Subject: Re: [RFC,PATCH] fastroute dead code... On Fri, 2004-07-30 at 16:10, David S. Miller wrote: > On Fri, 30 Jul 2004 15:35:15 -0400 > Jeff Garzik wrote: > > > It is dead code, as-is, in the kernel. It would require patches to > > actually work at all. > > > > It is impossible that fastrouting is being actively used, without patches. > > I totally agree. And people can always resurrect it from the > repository history or an old tarball if they wish. Patches are needed for the driver to use that code. So its not entirely dead code i.e it is referenced from fastroute enabled drivers. Sample (really old) code found at: http://ftp.iasi.roedu.net/mirrors/ftp.inr.ac.ru/ip-routing/fastroute/ > I think it should be killed entirely, and that's what I'm going > to do. Nod from here. Before you kill it lets hear from Ralf who is acquinted with someone that uses it and sings praises of it (although i personaly dont believe it ;->). cheers, jamal From scarfboy@gmail.com Fri Jul 30 14:03:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 14:03:46 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UL3cY6008024 for ; Fri, 30 Jul 2004 14:03:38 -0700 Received: by mproxy.gmail.com with SMTP id 74so56203rnl for ; Fri, 30 Jul 2004 14:03:29 -0700 (PDT) Received: by 10.38.2.75 with SMTP id 75mr115143rnb; Fri, 30 Jul 2004 14:03:29 -0700 (PDT) Message-ID: Date: Fri, 30 Jul 2004 23:03:29 +0200 From: Bart Alewijnse To: Francois Romieu Subject: Re: gigabit trouble Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040730205412.A15669@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040729210401.A32456@electric-eye.fr.zoreil.com> <20040730205412.A15669@electric-eye.fr.zoreil.com> X-archive-position: 7361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scarfboy@gmail.com Precedence: bulk X-list: netdev You are aware that this is a celeron at 400 mhz, and not whatever 400 is or possibly isn't in that annoying new naming scheme? (Just checking...) Both systems are not overclocked, so are stable in that respect. The nonbooting thing was a loose ground wire touching my hard drive jumpers, making it think it was a slave. I'm surprised winxp managed to do anything at all. I've used both these systems for ages, never had any real trouble except for the strange pci slot/irq problems in my new computer, but that was mostly a work-or-not thing - although it also increases pci latency. I'm still not sure whether it's a card that's in there, a card that was in there, (I replaced my sound card, and can suddently get a much lower midi-to-wave playing latency - but the sound card has been known to click and pop randomly over several reconfigurations the last few days) or just a screwy motherboard. I should hope it's not the last, it's a brand board. Anyhow, on transmit from the celeron box, under extreme benchy circumstrances, I've seen it around 16Kints/s on transmit and 13k on receive. But under everyday nfs/samba, 6400 is about the best it does either way. The maximum amount of interrupts/s I've seen so far 22302 (including the 1000 in the kernel timer, 'course). Nothing much else changes, except the context switches raising from an idle 10~30 to 1000~1500 to, sometimes 30000. Actually, using netio seems to busy the system completely: # top -d 0.5 | grep Cpu\( Cpu(s): 8.8% us, 36.8% sy, 0.0% ni, 1.5% id, 0.0% wa, 13.2% hi, 39.7% si Cpu(s): 7.5% us, 38.8% sy, 0.0% ni, 0.0% id, 0.0% wa, 14.9% hi, 38.8% si Cpu(s): 5.7% us, 41.4% sy, 0.0% ni, 0.0% id, 0.0% wa, 14.9% hi, 37.9% si Cpu(s): 5.0% us, 44.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 14.5% hi, 36.5% si Cpu(s): 4.4% us, 50.5% sy, 0.0% ni, 1.1% id, 0.0% wa, 12.1% hi, 31.9% si Cpu(s): 3.8% us, 50.9% sy, 0.0% ni, 0.0% id, 0.0% wa, 17.0% hi, 28.3% si But a to-winxp smb file transfer, hangin around 7, 8MB/s, doesn't: Cpu(s): 3.8% us, 50.0% sy, 0.0% ni, 17.9% id, 0.0% wa, 7.5% hi, 20.8% si Cpu(s): 5.0% us, 43.0% sy, 0.0% ni, 27.0% id, 0.0% wa, 7.0% hi, 18.0% si Cpu(s): 4.8% us, 40.4% sy, 0.0% ni, 29.8% id, 0.0% wa, 5.8% hi, 19.2% si Cpu(s): 5.1% us, 43.9% sy, 0.0% ni, 26.5% id, 0.0% wa, 5.1% hi, 19.4% si Cpu(s): 5.3% us, 42.5% sy, 0.0% ni, 26.5% id, 0.0% wa, 6.2% hi, 19.5% si Cpu(s): 5.9% us, 43.1% sy, 0.0% ni, 25.5% id, 1.0% wa, 5.9% hi, 18.6% si Cpu(s): 4.6% us, 41.7% sy, 0.0% ni, 25.9% id, 0.0% wa, 5.6% hi, 22.2% si Cpu(s): 6.2% us, 44.6% sy, 0.0% ni, 23.2% id, 0.0% wa, 5.4% hi, 20.5% si Cpu(s): 4.2% us, 34.7% sy, 0.0% ni, 38.9% id, 0.0% wa, 5.3% hi, 16.8% si It's not too consistent all over either; windows netio transmits slowly when packet sizes are >1k (the mtu?), as low as 5MB/s, while the receive speed for the same packet size goes at ~22MB Ooh, finally, a proper kernel pan --er, bug, it says. On my old computer this time. I know, incidentally, that the memory works; I recently did a three-hour memtest on this computer. Picture here: http://www.scarfboy.com/other/panic-30jul.gif This may be due to fiddling with said wmem, etc values, I set some of them considerably larger. I did get a few percent apparent speed increase, incidentally, though that may have been wishful thinking. I guess I should try >= 2.6.8-rc2-mm1 next? --Bart Alewijnse From hadi@cyberus.ca Fri Jul 30 14:06:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 14:06:44 -0700 (PDT) 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 i6UL6ckh008384 for ; Fri, 30 Jul 2004 14:06:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BqeaI-00008R-3C for netdev@oss.sgi.com; Fri, 30 Jul 2004 17:06:34 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BqeYv-0003vC-Nw; Fri, 30 Jul 2004 17:05:09 -0400 Subject: RE: [RFC,PATCH] fastroute dead code... From: jamal Reply-To: hadi@cyberus.ca To: Manish Lachwani Cc: Jeff Garzik , tmattox@gmail.com, netdev@oss.sgi.com, Ralf Baechle In-Reply-To: <9DFF23E1E33391449FDC324526D1F25902833769@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> References: <9DFF23E1E33391449FDC324526D1F25902833769@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> Content-Type: text/plain Organization: jamalopolous Message-Id: <1091221502.1032.547.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 30 Jul 2004 17:05:02 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 7362 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 Fri, 2004-07-30 at 16:31, Manish Lachwani wrote: > Is this a 2.6 issue or a 2.4 issue? This is because I am using 2.4.21 > kernel and so do the customers of the board. This board supports 1.0 > Ghz PMC-Sierra Rm9000 processor. With fast routing, the IP forwarding > numbers are about 900 Kpps. While in the case where there is no fast > routing, the numbers are about 450 Kpps (NAPI enabled) There could be many reasons why this is happening. Lets start with some simple experiment: - drop packets in netif_receive_skb(); this way they get counted by the driver stats but they dont get transfered. Count the rate at which you can receive packets. - On net/core/dev.c comment out do_gettimeofday() in netif_receive_skb() and do some measurement with regular routing. - repeat same tests with droping at netif_receive_skb(). When you are forwarding, try to collect qdisc stats on egress as well so we could see if you are bus bound. I have a feeling this will never be a problem for you - those mups things normaly have some obscenely fast bus compared to say er PCI. > I still have not done any 2.6 benchmarking since the board support is > not completely functional in 2.6 as yet. You will see improvements in 2.6.x. cheers, jamal From jgarzik@pobox.com Fri Jul 30 14:09:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 14:09:28 -0700 (PDT) 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 i6UL9LaJ008737 for ; Fri, 30 Jul 2004 14:09:22 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bqeco-00088g-2K; Fri, 30 Jul 2004 22:09:10 +0100 Message-ID: <410AB8E6.1010102@pobox.com> Date: Fri, 30 Jul 2004 17:08:54 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Mattox CC: davem@redhat.com, hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC,PATCH] fastroute dead code... References: <20040730060348.GA22854@havoc.gtf.org> <20040730193515.GA11365@havoc.gtf.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Tim Mattox wrote: >>It is dead code, as-is, in the kernel. It would require patches to >>actually work at all. >> >>It is impossible that fastrouting is being actively used, without patches. >> >> Jeff > > > Some might consider dropping in a new network driver module a patch, > others wouldn't... Anyway, as I said before, IMHO I agree its dead code > worthy of removal unless someone comes up with a GigE driver that > actually uses it. Driver use is completely irrelevant :) Regardless of what any driver does, the IPv4 code in the kernel does not make use of the RTCF_FAST flag, once set. All the fastrouting driver support API/code amounts to precisely nothing. Unless the --core net stack-- is patched again to support fastrouting, all this is dead code. Jeff From jgarzik@pobox.com Fri Jul 30 14:12:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 14:12:08 -0700 (PDT) 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 i6ULC1Fg009134 for ; Fri, 30 Jul 2004 14:12:01 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Bqeeq-00089w-5h; Fri, 30 Jul 2004 22:11:16 +0100 Message-ID: <410AB967.2010202@pobox.com> Date: Fri, 30 Jul 2004 17:11:03 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , tmattox@gmail.com, netdev@oss.sgi.com, Ralf Baechle Subject: Re: [RFC,PATCH] fastroute dead code... References: <20040730060348.GA22854@havoc.gtf.org> <20040730193515.GA11365@havoc.gtf.org> <20040730131004.2be1274d.davem@redhat.com> <1091219266.1029.470.camel@jzny.localdomain> In-Reply-To: <1091219266.1029.470.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev jamal wrote: > On Fri, 2004-07-30 at 16:10, David S. Miller wrote: >>I totally agree. And people can always resurrect it from the >>repository history or an old tarball if they wish. > > > Patches are needed for the driver to use that code. So its not entirely > dead code i.e it is referenced from fastroute enabled drivers. > Sample (really old) code found at: > http://ftp.iasi.roedu.net/mirrors/ftp.inr.ac.ru/ip-routing/fastroute/ Actually the opposite... the driver infrastructure is pretty much in place. It's the core IPv4 routing code that no longer does what people think :) grep for RTCF_FAST in 2.4.x and then in 2.6.x... Jeff From romieu@fr.zoreil.com Fri Jul 30 14:44:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 14:44:36 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6ULiK8t009766 for ; Fri, 30 Jul 2004 14:44:21 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i6ULfKh9019177; Fri, 30 Jul 2004 23:41:20 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i6ULfKh8019176; Fri, 30 Jul 2004 23:41:20 +0200 Date: Fri, 30 Jul 2004 23:41:20 +0200 From: Francois Romieu To: Bart Alewijnse Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: gigabit trouble Message-ID: <20040730234120.A15536@electric-eye.fr.zoreil.com> References: <20040729210401.A32456@electric-eye.fr.zoreil.com> <20040730205412.A15669@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from scarfboy@gmail.com on Fri, Jul 30, 2004 at 11:03:29PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 7365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Bart Alewijnse : > You are aware that this is a celeron at 400 mhz, and not whatever 400 > is or possibly isn't in that annoying new naming scheme? (Just > checking...) Yes. It is good enough to handle some network traffic. [...] > Anyhow, on transmit from the celeron box, under extreme benchy > circumstrances, I've seen it around 16Kints/s on transmit and 13k on > receive. But under everyday nfs/samba, 6400 is about the best it does > either way. The figures does not seem bad. I am curious: which chipset does the motherboard include ? An 'lspci -vx' sums it quite well. [...] > This may be due to fiddling with said wmem, etc values, I set some of them It should not. > considerably larger. I did get a few percent apparent speed increase, > incidentally, though that may have been wishful thinking. > > I guess I should try >= 2.6.8-rc2-mm1 next? Please. Do not compile in preempt/ipv6/smp. SMP is supposed to be safe but you do not need it and it will not make your r8169 faster if you have only one CPU. I'd welcome a 'vmstat 1' output as it gives the bi/bo. -- Ueimor From shemminger@osdl.org Fri Jul 30 15:37:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 15:37:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6UMbOVE010723 for ; Fri, 30 Jul 2004 15:37:25 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i6UMbG103486; Fri, 30 Jul 2004 15:37:16 -0700 Date: Fri, 30 Jul 2004 15:37:15 -0700 From: Stephen Hemminger To: netdev@oss.sgi.com Cc: lartc@mailman.ds9a.nl, linux-net@vger.kernel.org Subject: [announce] iproute2 update Message-Id: <20040730153715.453c14cf@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This version supports: * changes 'tc' for latest netem queuing discipline * additions to 'ip' to support xfrm * more robust configuration (works with older 2.4 systems) to detect xfrm, hfsc, htb, etc. The versioning scheme is to label the highest version of kernel used. It should build and run on older systems as well, but obviously can't support stuff your kernel doesn't have. So if a new feature (like netem scheduler) got added in 2.6.8 kernel, then you would need the corresponding iproute2 to use it. Available at: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.8-ss040730.tar.gz From ahu@outpost.ds9a.nl Fri Jul 30 15:38:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 15:38:20 -0700 (PDT) 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 i6UMcCT5010911 for ; Fri, 30 Jul 2004 15:38:13 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2E8484452; Sat, 31 Jul 2004 00:38:09 +0200 (CEST) Date: Sat, 31 Jul 2004 00:38:09 +0200 From: bert hubert To: James Morris Cc: netdev@oss.sgi.com Subject: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-ID: <20040730223808.GA12660@outpost.ds9a.nl> Mail-Followup-To: bert hubert , James Morris , netdev@oss.sgi.com References: <20040730170726.GA5144@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 7367 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 On Fri, Jul 30, 2004 at 02:55:19PM -0400, James Morris wrote: > PF_KEY is not deprecated, it's an IETF standard and required for > compliance & compatibility. XFRM_USER is simply the native Linux > interface. Ok, thanks. I've gotten to the point where I can configure nat-t over XFRM, however, I find that it does not work. The encoding looks fine but the receiving side does not appear to listen: 00:34:09.491228 IP 192.168.1.4.4500 > 10.0.0.3.4500: UDP, length: 88 00:34:09.492290 IP 10.0.0.3 > 192.168.1.4: icmp 124: 10.0.0.3 udp port 4500 unreachable 00:34:10.492245 IP 192.168.1.4.4500 > 10.0.0.3.4500: UDP, length: 88 00:34:10.493332 IP 10.0.0.3 > 192.168.1.4: icmp 124: 10.0.0.3 udp port 4500 unreachable 00:34:11.493090 IP 192.168.1.4.4500 > 10.0.0.3.4500: UDP, length: 88 00:34:11.494337 IP 10.0.0.3 > 192.168.1.4: icmp 124: 10.0.0.3 udp port 4500 unreachable This is the setkey configuration I use on 10.0.0.3: #!/usr/sbin/setkey -f flush; spdflush; add 192.168.1.4 10.0.0.3 esp-udp 10.0.0.3 34501 -E 3des-cbc "123456789012123456789012"; spdadd 192.168.1.4 10.0.0.3 icmp -P in ipsec esp/transport//require; And on the other side (192.168.1.4): #!/usr/sbin/setkey -f flush; spdflush; add 192.168.1.4 10.0.0.3 esp-udp 192.168.1.4 34501 -E 3des-cbc "123456789012123456789012"; spdadd 192.168.1.4 10.0.0.3 icmp -P out ipsec esp/transport//require; I've toyed a bit with the IP address after esp-udp, not sure what it does. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From herbert@gondor.apana.org.au Fri Jul 30 19:01:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jul 2004 19:01:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6V20xNF017562 for ; Fri, 30 Jul 2004 19:01:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqjB2-0000Fo-00; Sat, 31 Jul 2004 12:00:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqjAy-0003bn-00; Sat, 31 Jul 2004 12:00:44 +1000 Date: Sat, 31 Jul 2004 12:00:44 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] xfrm_alloc_spi always succeeds on non-trivial range Message-ID: <20040731020044.GA13830@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: xfrm_alloc_spi will always succeed if minspi < maxspi, even if minspi + 1 == maxspi. If the range is already occupied this will obviously lead to breakage. Of course this is very unlikely to occur in reality due to the size of the range. Although with IPCOMP it might actually happen on a very large server. The fix is obivous. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/xfrm/xfrm_state.c 1.49 vs edited ===== --- 1.49/net/xfrm/xfrm_state.c 2004-07-30 22:12:11 +10:00 +++ edited/net/xfrm/xfrm_state.c 2004-07-31 11:56:29 +10:00 @@ -624,11 +624,12 @@ for (h=0; hid.daddr, htonl(spi), x->id.proto, x->props.family); - if (x0 == NULL) + if (x0 == NULL) { + x->id.spi = htonl(spi); break; + } xfrm_state_put(x0); } - x->id.spi = htonl(spi); } if (x->id.spi) { spin_lock_bh(&xfrm_state_lock); --Kj7319i9nmIyA2yE-- From herbert@gondor.apana.org.au Sat Jul 31 00:39:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 00:39:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6V7dcZ9031532 for ; Sat, 31 Jul 2004 00:39:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqoRk-0001kn-00; Sat, 31 Jul 2004 17:38:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqoRX-0004DH-00; Sat, 31 Jul 2004 17:38:11 +1000 From: Herbert Xu To: hch@infradead.org (Christoph Hellwig) Subject: Re: [PATCH 3/12 2.4] e1000 - use vmalloc for data structures not shared with h/w Cc: ganesh.venkatesan@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Organization: Core In-Reply-To: <20040729192519.A6235@infradead.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Sat, 31 Jul 2004 17:38:11 +1000 X-archive-position: 7369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Christoph Hellwig wrote: > On Thu, Jul 29, 2004 at 11:17:08AM -0700, Venkatesan, Ganesh wrote: >> Vmalloc space is less scarce than kmalloc space. Am I right? This patch >> trades kmalloc space for vmalloc space. > > No, it's not. vmalloc needs virtual space that's rather limited (e.g. 64MB > on PAE x86) in addition to physical memory. Unless you do really big > allocations stay away from vmalloc. How big is really big? 64K? 256K? 1M? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Jul 31 00:50:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 00:50:37 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6V7oRP7031914 for ; Sat, 31 Jul 2004 00:50:28 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bqod7-0001nF-00; Sat, 31 Jul 2004 17:50:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bqod3-0004FB-00; Sat, 31 Jul 2004 17:50:05 +1000 From: Herbert Xu To: ahu@ds9a.nl (bert hubert) Subject: Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Cc: jmorris@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040730223808.GA12660@outpost.ds9a.nl> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Sat, 31 Jul 2004 17:50:05 +1000 X-archive-position: 7370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev bert hubert wrote: > > The encoding looks fine but the receiving side does not appear to listen: > > 00:34:09.491228 IP 192.168.1.4.4500 > 10.0.0.3.4500: UDP, length: 88 > 00:34:09.492290 IP 10.0.0.3 > 192.168.1.4: icmp 124: 10.0.0.3 udp port 4500 > unreachable You need to have someone open a socket on port 4500 and do the appropriate setsockopt() on it. > This is the setkey configuration I use on 10.0.0.3: Any reason why you aren't using automatic keying? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ahu@outpost.ds9a.nl Sat Jul 31 01:35:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 01:35:07 -0700 (PDT) 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 i6V8Z00W000649 for ; Sat, 31 Jul 2004 01:35:01 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8C6804494; Sat, 31 Jul 2004 10:34:56 +0200 (CEST) Date: Sat, 31 Jul 2004 10:34:56 +0200 From: bert hubert To: Herbert Xu Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-ID: <20040731083456.GA24761@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Herbert Xu , jmorris@redhat.com, netdev@oss.sgi.com References: <20040730223808.GA12660@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 7371 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 On Sat, Jul 31, 2004 at 05:50:05PM +1000, Herbert Xu wrote: > You need to have someone open a socket on port 4500 and do the > appropriate setsockopt() on it. Would this be: #define UDP_ESPINUDP 100, known in the kernel as UDP_ENCAP? Does the socket need to be kept open after the setsockopt? Do the encapsulated packets reach userspace? The right way to do this is probably to first get a socket, set it to UDP_ENCAP, and only then try to negotiate an SA, using the port number assigned previously? > > This is the setkey configuration I use on 10.0.0.3: > > Any reason why you aren't using automatic keying? I'm trying to figure out how this stuff works with an eye on documenting it. So far I haven't been able to get openswan to do nat-t, hence I've been trying to do this from the ground up. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From herbert@gondor.apana.org.au Sat Jul 31 03:05:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 03:05:44 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VA5XHw004967 for ; Sat, 31 Jul 2004 03:05:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqqjR-0002f7-00; Sat, 31 Jul 2004 20:04:49 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqqjM-0004VU-00; Sat, 31 Jul 2004 20:04:44 +1000 Date: Sat, 31 Jul 2004 20:04:44 +1000 To: kuznet@ms2.inr.ac.ru, davem@redhat.com, jmorris@redhat.com, netdev@oss.sgi.com Subject: [PFKEY] spirange should be in host byte order Message-ID: <20040731100444.GA17201@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: I'm looking through the xfrm_alloc_spi stuff and noticed that the netlink alloc_spi function takes the range in host order while the PFKEY alloc_spi function takes them in network order. First I thought that I stuffed up since I was the one who changed the code in the netlink interface to take them in host order :) But reading RFC 2367 seems to indicate otherwise. It says that all fields are host order unless specified otherwise. And the spirange fields are not specified to be network order at all. Looking at the existing PFKEY users: User Space ---------- Openswan - Doesn't use PFKEY for this. Racoon - Puts zeros in there so it doesn't care. However its test-pfkey program stores things in host order. ISAKMPD - Stores things in host order. So the conclusion is that we can and should change our PFKEY implementation to use host order for these fields. This patch does exactly that. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/key/af_key.c 1.64 vs edited ===== --- 1.64/net/key/af_key.c 2004-07-01 19:11:29 +10:00 +++ edited/net/key/af_key.c 2004-07-31 20:00:19 +10:00 @@ -1182,10 +1182,10 @@ min_spi = range->sadb_spirange_min; max_spi = range->sadb_spirange_max; } else { - min_spi = htonl(0x100); - max_spi = htonl(0x0fffffff); + min_spi = 0x100; + max_spi = 0x0fffffff; } - xfrm_alloc_spi(x, min_spi, max_spi); + xfrm_alloc_spi(x, htonl(min_spi), htonl(max_spi)); if (x->id.spi) resp_skb = pfkey_xfrm_state2msg(x, 0, 3); } --envbJBWh7q8WU6mo-- From herbert@gondor.apana.org.au Sat Jul 31 03:32:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 03:32:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VAWPlR005758 for ; Sat, 31 Jul 2004 03:32:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Bqr9u-0002xu-00; Sat, 31 Jul 2004 20:32:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Bqr9r-0004av-00; Sat, 31 Jul 2004 20:32:07 +1000 From: Herbert Xu To: ahu@ds9a.nl (bert hubert) Subject: Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Cc: herbert@gondor.apana.org.au, jmorris@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040731083456.GA24761@outpost.ds9a.nl> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Sat, 31 Jul 2004 20:32:07 +1000 X-archive-position: 7373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev bert hubert wrote: > > Would this be: > #define UDP_ESPINUDP 100, known in the kernel as UDP_ENCAP? Correct. > Does the socket need to be kept open after the setsockopt? Do the Yes. > encapsulated packets reach userspace? No. > The right way to do this is probably to first get a socket, set it to > UDP_ENCAP, and only then try to negotiate an SA, using the port number > assigned previously? Theoretically you can use another port if you're the initiator, but the draft document requires you to use port 4500. > I'm trying to figure out how this stuff works with an eye on documenting it. > So far I haven't been able to get openswan to do nat-t, hence I've been > trying to do this from the ground up. There is a NAT-T bug in Opeswan 2.1.* which was recently fixed. Here is the patch. In future please ask on users@lists.openswan.org. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Index: programs/pluto/server.c =================================================================== RCS file: /public/cvs/openswan-2/programs/pluto/server.c,v retrieving revision 1.97 diff -u -r1.97 server.c --- programs/pluto/server.c 2 Jun 2004 12:42:50 -0000 1.97 +++ programs/pluto/server.c 22 Jul 2004 03:34:50 -0000 @@ -523,6 +523,51 @@ } #endif +#if defined(linux) && defined(KERNEL26_SUPPORT) + if (!no_klips && kernel_ops->type == KERNEL_TYPE_LINUX) + { + struct sadb_x_policy policy; + int level, opt; + + policy.sadb_x_policy_len = sizeof(policy) / IPSEC_PFKEYv2_ALIGN; + policy.sadb_x_policy_exttype = SADB_X_EXT_POLICY; + policy.sadb_x_policy_type = IPSEC_POLICY_BYPASS; + policy.sadb_x_policy_dir = IPSEC_DIR_INBOUND; + policy.sadb_x_policy_reserved = 0; + policy.sadb_x_policy_id = 0; + policy.sadb_x_policy_reserved2 = 0; + + if (addrtypeof(&ifp->addr) == AF_INET6) + { + level = IPPROTO_IPV6; + opt = IPV6_IPSEC_POLICY; + } + else + { + level = IPPROTO_IP; + opt = IP_IPSEC_POLICY; + } + + if (setsockopt(fd, level, opt + , &policy, sizeof(policy)) < 0) + { + log_errno((e, "setsockopt IPSEC_POLICY in process_raw_ifaces()")); + close(fd); + return -1; + } + + policy.sadb_x_policy_dir = IPSEC_DIR_OUTBOUND; + + if (setsockopt(fd, level, opt + , &policy, sizeof(policy)) < 0) + { + log_errno((e, "setsockopt IPSEC_POLICY in process_raw_ifaces()")); + close(fd); + return -1; + } + } +#endif + setportof(htons(port), &ifp->addr); if (bind(fd, sockaddrof(&ifp->addr), sockaddrlenof(&ifp->addr)) < 0) { @@ -659,13 +704,10 @@ if (q == NULL) { /* matches nothing -- create a new entry */ - int fd = socket(addrtypeof(&ifp->addr), SOCK_DGRAM, IPPROTO_UDP); + int fd = create_socket(ifp, v->name, pluto_port); if (fd < 0) - { - log_errno((e, "socket() in process_raw_ifaces()")); break; - } #ifdef NAT_TRAVERSAL if (nat_traversal_support_non_ike) @@ -673,96 +715,6 @@ nat_traversal_espinudp_socket(fd, ESPINUDP_WITH_NON_IKE); } #endif - if (fcntl(fd, F_SETFD, FD_CLOEXEC) == -1) - { - log_errno((e, "fcntl(,, FD_CLOEXEC) in process_raw_ifaces()")); - break; - } - - if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR - , (const void *)&on, sizeof(on)) < 0) - { - log_errno((e, "setsockopt SO_REUSEADDR in process_raw_ifaces()")); - break; - } - - /* To improve error reporting. See ip(7). */ -#if defined(IP_RECVERR) && defined(MSG_ERRQUEUE) - if (setsockopt(fd, SOL_IP, IP_RECVERR - , (const void *)&on, sizeof(on)) < 0) - { - log_errno((e, "setsockopt IP_RECVERR in process_raw_ifaces()")); - break; - } -#endif - - /* With IPv6, there is no fragmentation after - * it leaves our interface. PMTU discovery - * is mandatory but doesn't work well with IKE (why?). - * So we must set the IPV6_USE_MIN_MTU option. - * See draft-ietf-ipngwg-rfc2292bis-01.txt 11.1 - */ -#ifdef IPV6_USE_MIN_MTU /* YUCK: not always defined */ - if (addrtypeof(&ifp->addr) == AF_INET6 - && setsockopt(fd, SOL_SOCKET, IPV6_USE_MIN_MTU - , (const void *)&on, sizeof(on)) < 0) - { - log_errno((e, "setsockopt IPV6_USE_MIN_MTU in process_raw_ifaces()")); - break; - } -#endif - -#if defined(linux) && defined(KERNEL26_SUPPORT) - if (!no_klips && kernel_ops->type == KERNEL_TYPE_LINUX) - { - struct sadb_x_policy policy; - int level, opt; - - policy.sadb_x_policy_len = sizeof(policy) / IPSEC_PFKEYv2_ALIGN; - policy.sadb_x_policy_exttype = SADB_X_EXT_POLICY; - policy.sadb_x_policy_type = IPSEC_POLICY_BYPASS; - policy.sadb_x_policy_dir = IPSEC_DIR_INBOUND; - policy.sadb_x_policy_reserved = 0; - policy.sadb_x_policy_id = 0; - policy.sadb_x_policy_reserved2 = 0; - - if (addrtypeof(&ifp->addr) == AF_INET6) - { - level = IPPROTO_IPV6; - opt = IPV6_IPSEC_POLICY; - } - else - { - level = IPPROTO_IP; - opt = IP_IPSEC_POLICY; - } - - if (setsockopt(fd, level, opt - , &policy, sizeof(policy)) < 0) - { - log_errno((e, "setsockopt IPSEC_POLICY in process_raw_ifaces()")); - break; - } - - policy.sadb_x_policy_dir = IPSEC_DIR_OUTBOUND; - - if (setsockopt(fd, level, opt - , &policy, sizeof(policy)) < 0) - { - log_errno((e, "setsockopt IPSEC_POLICY in process_raw_ifaces()")); - break; - } - } -#endif - - setportof(htons(pluto_port), &ifp->addr); - if (bind(fd, sockaddrof(&ifp->addr), sockaddrlenof(&ifp->addr)) < 0) - { - log_errno((e, "bind() for %s/%s %s:%u in process_raw_ifaces()" - , ifp->name, v->name - , ip_str(&ifp->addr), (unsigned) pluto_port)); - break; - } q = alloc_thing(struct iface, "struct iface"); q->rname = clone_str(ifp->name, "real device name"); From ahu@outpost.ds9a.nl Sat Jul 31 04:20:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 04:21:02 -0700 (PDT) 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 i6VBKr3B010314 for ; Sat, 31 Jul 2004 04:20:55 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1FB943FDC; Sat, 31 Jul 2004 13:20:49 +0200 (CEST) Date: Sat, 31 Jul 2004 13:20:49 +0200 From: bert hubert To: Herbert Xu Cc: jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-ID: <20040731112048.GA27893@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Herbert Xu , jmorris@redhat.com, netdev@oss.sgi.com References: <20040731083456.GA24761@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 7374 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 On Sat, Jul 31, 2004 at 08:32:07PM +1000, Herbert Xu wrote: > > encapsulated packets reach userspace? > > No. socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(4500), sin_addr=inet_addr("10.0.0.3")}, 16) = 0 setsockopt(3, SOL_UDP, 100, [1], 4) = 0 read(3, "\0\0\206\305\0\0\f\311\27\263\3379\313z\377T\310\6\25\217"..., 1024) = 104 I do see packets coming in on 2.6.8-rc2 and tethereal verifies that the packets at least appear to be ESP: Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 10.0.0.3 (10.0.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 132 Identification: 0x00f0 (240) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x6dca (correct) Source: 192.168.1.4 (192.168.1.4) Destination: 10.0.0.3 (10.0.0.3) User Datagram Protocol, Src Port: 4500 (4500), Dst Port: 4500 (4500) Source port: 4500 (4500) Destination port: 4500 (4500) Length: 112 Checksum: 0x0000 (none) UDP Encapsulation of IPsec Packets Encapsulating Security Payload SPI: 0x000086c5 Sequence: 4116 Data (96 bytes) I'm trying to reverse engineer the code out there but can't find other things I need to do to get this to work - right now the kernel does not see the ESP packets, but passes them to userspace. I have this SA in place on the receiving end: 192.168.1.4[4500] 10.0.0.3[4500] esp-udp mode=transport spi=34501(0x000086c5) reqid=0(0x00000000) E: aes-cbc 31323334 35363738 39303132 31323334 35363738 39303132 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 31 13:12:09 2004 current: Jul 31 13:12:13 2004 diff: 4(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=595 refcnt=0 Note how the SPI matches with what tethereal sees. And this policy on 10.0.0.3. 192.168.1.4[any] 10.0.0.3[any] icmp in ipsec esp/transport//require created: Jul 31 13:14:22 2004 lastused: lifetime: 0(s) validtime: 0(s) spid=16 seq=0 pid=659 refcnt=1 Any further ideas? -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From herbert@gondor.apana.org.au Sat Jul 31 04:52:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 04:52:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VBqnT0010966 for ; Sat, 31 Jul 2004 04:52:50 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqsPi-0003ET-00; Sat, 31 Jul 2004 21:52:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqsPe-0004q6-00; Sat, 31 Jul 2004 21:52:30 +1000 Date: Sat, 31 Jul 2004 21:52:30 +1000 To: bert hubert , jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-ID: <20040731115230.GA18537@gondor.apana.org.au> References: <20040731083456.GA24761@outpost.ds9a.nl> <20040731112048.GA27893@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731112048.GA27893@outpost.ds9a.nl> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Jul 31, 2004 at 01:20:49PM +0200, bert hubert wrote: > > setsockopt(3, SOL_UDP, 100, [1], 4) = 0 You chose NON_IKE. > read(3, "\0\0\206\305\0\0\f\311\27\263\3379\313z\377T\310\6\25\217"..., 1024) = 104 This packet is NON_ESP, aka UDP_ENCAP_ESPINUDP. > Any further ideas? Either change the receiving end to using NON_ESP or change the sender to use NON_IKE. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ahu@outpost.ds9a.nl Sat Jul 31 05:18:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 05:18:38 -0700 (PDT) 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 i6VCIWNW011647 for ; Sat, 31 Jul 2004 05:18:33 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 0030E3FDC; Sat, 31 Jul 2004 14:18:28 +0200 (CEST) Date: Sat, 31 Jul 2004 14:18:28 +0200 From: bert hubert To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-ID: <20040731121828.GA29497@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Herbert Xu , netdev@oss.sgi.com References: <20040731083456.GA24761@outpost.ds9a.nl> <20040731112048.GA27893@outpost.ds9a.nl> <20040731115230.GA18537@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <20040731115230.GA18537@gondor.apana.org.au> User-Agent: Mutt/1.3.28i X-archive-position: 7376 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 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jul 31, 2004 at 09:52:30PM +1000, Herbert Xu wrote: > On Sat, Jul 31, 2004 at 01:20:49PM +0200, bert hubert wrote: > > > > setsockopt(3, SOL_UDP, 100, [1], 4) = 0 > > You chose NON_IKE. I've tried it both ways, both don't work. I should have mentioned that. I've attached the code that tries to setup the receiving end so things work. It is in c++, I hope that does not offend too many people. g++ udpencap.cc -o udpencap You can strace it to see what it is doing in any case. Thanks again. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO --AhhlLboLdkugWU4S Content-Type: application/octet-stream Content-Disposition: attachment; filename="udpencap.tar.gz" Content-Transfer-Encoding: base64 H4sIAKONC0EAA+1ae2/bthbvv/WnYF0glRLXsZOuBeKoQNo4a7AuCZIUxbANBi3RsVBZEkQq nm+XffZ7Dh8SJTvO42a7uBfiViQiDw/P88dDMnmQstin6Xauf+n6/rMnbj1ob9+8wZ/9dz/0 7J+yvdvZedbv9Xs773pvd99Af//N7m7/Gek9tSCrWs4FzQh5Rqf5Wrq7xrUuxc//kfYyjP0o Dxhpcy7yyaQ7nbZbRed+zEQI/zA6utP3rTAWZEbD2HFbIlu0vreeXyT+NyYId45jwbITJuZJ 9q1DDqmgVxmddcjx2dn56eXp6MvhmTtoPT8+G8ZBmiAjljrtXlf+1+6QNz/0ekjAu+MwDhyW wkfrOdJNAo93r5j4ROMgYg70vwzYBMQiw4uz4xNgPPp6fPlpdHJ6Mjr+aUj6a8ahh+wotmKR Mm8lBUrBBAfNklQ4k6BDLk4/owId0u/1OmQDp3YID//FkomDH64UlossjK9IgIoDj0mSOYOB S8BKoFXGaODIIdTyuZ/kYn+//YkGJKVowm63vb/PQEMYvWndtHwq/KnD/vBZKsIkJhvMRXv7 LMtg3hHYN9ojOKU7n1LhuGbyzcP8b9J+u3D/08fY+vzf2envvlP5//bd293+W8z/3rvdJv// ifYynMSQLeTi8svR0ejTpyJ3ig4LDVSAv7d7oIvRmd0VJst9ELRxggBizVzwbUwdXu3O45CL YJmUS5yp9htwCuNqP81Suo0jK9iwiPm1/okfi6hGKgKVee9brZxjUsd0xjhkKiMwBsne8iPK OdGAN8yyJCN7JM3HUeiTLI9FOGMjht2Qtap7r0Uq9I7Gi/l04bX1AJEjbRd4VZg4QNT1RzDD cV3g8/2mzsyfQhhv3peX5nGDmmxvvyDnLM0YZ7GgEmySCaExQDc5CALo51rb4zPzbeuUjwBO d3dGgowXgg1IC/qQ5+WUEQgmmkeinElCTjToA1nR7UiB4B+RTLzeAH6/0Yw+JjEonvtCC0U1 qzHlLCAgLiXalNmSGknMKuv4yMuQb2RslghWrq2XCeMRriEXGsiBcOK8wIgaUZHEjppm/AEb AhJKv2AT0yyZV53T/pjkUUDiRBAQ4Jplgrxqbyk2W+1XRCRV1druoLQF9nX5yAhzY+x7zkSe xTWbUPifpKCdoOOIaUVbxGhM+YX8xXGJtESheaIIVOqSRC2vjJXHPLyKwdIqxGIvYyFu9mBq MfIpF/sr6DbfOxsovVYk2d93inGY7W7GW1uwj3XbTzduulVPpqyTdKWPlOEw3BFzEPBk1Pbf jjA2z5JMDFQiHEr049qqRa0yn4b+VNoD4ImX+VGYPQ7Q7sCHxPlszLIiYwwLK2VkQJp+x/1+ Q6RD98lwloqFPadCuCp0O1p6QnFtr4fJrmXSUQrhiUOOJMC15EpWSpFJHkUL1G0SXuUZ2JfZ y5u81VwHslMumUqrESDPZwR7LhHOyfeDk1+8Hphagosc1DyO6CyElb7bpaJ3cDQ6Phle3gyU YBd5inxBCmPaCc4KGVesVL2JK5Hvpsj0Lk4//jQ6/PH84OfOhQxg1XNxeT48+HmZs9pLSsYm JNDRZ1kiEj+JcIWliakelLUjvxU5tZAyKGY0XmCnADD8wLJvsP8swOKxj9Rg1WsaRpipOl7U TIyVLLymgiG+qj7tfs16Q0a0+UhSlgEwZd4yUTlfldIl1gWjcT6JWOxB4fVmUHZNWObFbC6z +FdD9LshULbzJoHKqHIXqAG1MTKozlPmh5MQ7FeNAzRP6c5uKWmNbNKxvc5Fp+IkkmLYW1pJ ty48OimQ2ynEVj8cYIlsUuG6+701sI1oKH+R9YvrDh5pOAnZf2ntlKwKX6OEs0I6wx5CRLBf fy+YVkD/WIWSti5splC7S6QHQwcJIgNPOkACIybKyDyMIjKnIfgfqhSKqR4zOVTG0Cb1sd5x lvZCXAlTEeCSKERRYmI/6Af4Cb1oDX0c0qijiGZsBicppwCrXnFq0mSaDmOTe3t7WghjkY5j ViebbsFkQy3oFv7l4EQttPyW3vK84cGPB8cnbuu53gp6g9aaHfpALi33SMtAcMTaUoi7FAx6 /ZuWvd2g/7WfuVtx3AUY2fIc7PhxEr8eR/CpdujrJARoYuIkiT/oXssbMnsjesU9Wa6WJjoa /Ti8PPrcgcMz0hmbSNr9HvnzT1KbQI5GF3KGJPnzFE+9Hz4DXrpkbTK0QQOhAszSwChwl6EK O3yA033NENSCCGvvkQaRlwEK1ayrgw2Wrg1UEIpGlRBcrllkMQNViqR1O72Ojkz1rb0rP7pw AjCwYvClPmwVaR5Lu3rz6sqKuEYqd+op1JHcAUq5LSuSwtFilnr9MrzLu4jCiXghgXvc8BJ+ HZ0Pv1wMDw4PzzvyGAC5Ahy0PsjsTpRDt6F/9TqwNYYRC8Cn7tYyBhq59vakc6xkrToCc1Zq XbPsgyH3sbGj0/jh4WPj3J3xY8qsIoCq0KbPCreGkDV+ZwxZtLcHUekeo/9aD2lUrcn+GB9p Jx3BHhPoykw7indAdJ+F1wz8VYzh/h8xCqg5n7KMEdiffDhlk0mWzJDX5uaT8cL2W0qRUl7B ka+4JY5hHH5C5MxDMZWBZRhW57D01glJFl6FsanwCnk2t00QgrDXRyCFOe1vBOZe9FHheK9t F5li1PCyBJKfHgqDJrF2A1NldIq6Rm7Ta3fex1RNqrZB3btQ6MJBzilWlrJpslrce6vTo6CV aRCLZGqOO0VyVJFjdSBB2R7YUSTxJGActjmqy6Pbo/Aek5fC7nJdiOEggkwcQIBZjNYEF8pw mdROhjrA/iPU+ztRS7mrRK1yn4sDkdihKaOluGVRnxjv+HVbjD4BkKmQ+ZqFgqlKGi2P/i23 HiixKZY9gDIZElE48iBAYCQT7JrDbHAlSXJBjLewj8V1bwHvapknErm0hyNdSLcrMXWsxM5M Wis+ah9KRabotbW0VYOkqIthGhTYUoTSxDCto5fTK0hPAC2W1K3nq8pApEbJ1eYr+dxdJasb NODrrmY6PD3CizzFrl1M0rK99gqlCZzasq3y+2Y+hVLFKZWwXQgigTtA0LnypSLSXkIcRGZV x+qUf8TMDhmDr4MECPCeb0a/wUguowOO/DQiV1CxWGFRzX9k9xnqI5nwxbrL25eRRN0yITQo mVCUbAG0EhzsqzLsl3OcWsB07GirhmBh3ntGjYoZz1t7ftA+ni/HT9tCAeDzvmCjT1VSHENQ O91VCHvWXvNEsVvFA/6QIHrAjK6+zeVkCkLLSyNFPmcWmCz7dv6PONY+Xz8ZJNy06h62q0h8 LuV4ey/Voj7U3sp0VvnfUjpBXiGNdViWlvBNyCi1QVv1BGuU3fA7/YqWtVjyK/fIr/tFMEgs h0WjMGZOBcZBcvBfloXjaAHrsskk9EMWl7fsCqKxULURXa+kkMzxvUIh94X3ul+aHmdvefKI 5/oWrvqe9+q3+BVA6xhU/Faa13oqQGtSIk/r8qoId7S6PZX7zIuBrl7BZLdvVavsWpR1pp5c CqU1kYSC4lpStPvHkrRrvazMWO0K5gFWKEjg+JdIXFXqgqIqzUzRXJTadxtmRbX7d9qkhp32 RRSv6RuFHOFFHmpo8Wane8cUThzJFRqj39OoZMJDkVReZoiqWLy+dSkrT6OatjCHoltfoK24 c1Js7o3aBlaFLq6zGHZiOMTh0yT3szAVSWYK7AK8NaqYPzipPZVpwxpFzEulfWWPDOxxFTP2 ha6iUAlSfpsS+0a/Rn3Ex8IYIMQHHJQPBOM8BNfIGiFFufX1LV7smo31y+EZHAyya5aZd1vo +SzNxqqv0ZU7e+Cga1r5tFUcG5SdxjiAu7csdVWNr8oO5RDgZq1yx5VLMGIpnBUMAobCXI2v fPUtBUtifA+wn9k68oLQ7D1QgUsfT6jPeE0i69GqKkj1vNnDRx/iFe9ee3sHJ78MSmJ5gjEv X7cLj0dGP0Ls52SWcBEtlKR8WU6i/sCAkm8QnCwiCsbwtcl6Tazqci8FjOlXatC7Xfy/bllJ PkssRb2dY7X7mIzhUpyE+GAqr0laD7gTqT/Nm4Vfvy9mq1nWzYeFcXHAlw7nirL1qLPz7eJo PquEsRBBLmmbe4mTZ70drP5juuL9ySyt71/l38qp4slecjkfrR79gljpqT8jLpPbsDBSCWze j8rAkOj1EqwSTlr/7T9valrTmta0pjWtaU1rWtOa1rSmNa1pTWta05rWtKY1rWlNa1rTmta0 pjWtaU1rWtOa1rT/2/ZvkP2GRgBQAAA= --AhhlLboLdkugWU4S-- From mcr@sandelman.ottawa.on.ca Sat Jul 31 05:19:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 05:19:19 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VCIbPb011652; Sat, 31 Jul 2004 05:18:38 -0700 Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i6VCIU800980 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 31 Jul 2004 08:18:31 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6VCIUUU014822 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 31 Jul 2004 08:18:30 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6VCAoNb014502; Sat, 31 Jul 2004 08:12:00 -0400 To: pranav@nodeinfotech.com cc: netdev-bounce@oss.sgi.com, netdev@oss.sgi.com Subject: Re: Problem in IKE implemenation in linux(RACE CONDITION) In-Reply-To: Message from "Pranav" of "Thu, 29 Jul 2004 15:08:08 +0530." References: X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 31 Jul 2004 08:10:50 -0400 Message-ID: <14501.1091275850@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 7377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pranav" == Pranav writes: Pranav> hi everyone, I am working on IKE implementaion on linux. i Pranav> have got a problem in negoatiation when both the peers start Pranav> negotiating at the same time, both peers acting as initiator Pranav> causing race condition. Pranav> Race condition happens only when both the peer's start the Pranav> same application(like ping or telnet)with eachother at the Pranav> same time. Yes, in general you have to create both tunnels for receive. It is up to you to decide which tunnel to create for sending. If you want to get rid of them, then wait 5 minutes, and then rekey the tunnels. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQQt/04qHRg3pndX9AQHCyAQAull2/qeUcL0mfxKyeRKRsiViMAMgNiDA KH62L05FP4mbiCrdhGBppaIIuK/hcu9axp8VQ7IDWS/Pa5S6FmMquegaJPTDGohd 3wZZi6vlBq4LiVnVqcBpFinNTP5dH43vfDNK42WSV+fUjrVc09uX9XWXhmFXh593 knlESrpooPI= =Wq/Q -----END PGP SIGNATURE----- From romieu@fr.zoreil.com Sat Jul 31 05:36:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 05:36:24 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VCaD9M012421 for ; Sat, 31 Jul 2004 05:36:15 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i6VCXWh9026549; Sat, 31 Jul 2004 14:33:32 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i6VCXUnO026548; Sat, 31 Jul 2004 14:33:30 +0200 Date: Sat, 31 Jul 2004 14:33:30 +0200 From: Francois Romieu To: Pasi Sjoholm Cc: Robert Olsson , H?ctor Mart?n , Linux-Kernel , akpm@osdl.org, netdev@oss.sgi.com, brad@brad-x.com, shemminger@osdl.org Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) Message-ID: <20040731143330.A25736@electric-eye.fr.zoreil.com> References: <16650.21955.869485.332365@robur.slu.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ptsjohol@cc.jyu.fi on Fri, Jul 30, 2004 at 09:40:28PM +0300 X-Organisation: Land of Sunshine Inc. X-archive-position: 7378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Pasi Sjoholm : [interesting report] > The hardest part is to tell where the problem is but I think that > rtl8139_poll-function would be good place to start looking for the bug? > > readprofile didn't tell much.. Where to go next? I'm not so good > programmer that I could find the right place to fix.. In case it could make a difference: did you check if CONFIG_8139_OLD_RX_RESET changes the behavior or not ? If it does not, I'd welcome a test report + log with the two attached patch applied. The first one is just a placebo but the second one could help. Btw, you are probably right that the issue is not related to ksoftirqd at all. -- Ueimor --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8139-10.patch" drivers/net/8139too.c | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff -puN drivers/net/8139too.c~r8139-10 drivers/net/8139too.c --- linux-2.6.8-rc2/drivers/net/8139too.c~r8139-10 2004-07-31 12:43:44.000000000 +0200 +++ linux-2.6.8-rc2-romieu/drivers/net/8139too.c 2004-07-31 12:43:44.000000000 +0200 @@ -1934,6 +1934,7 @@ static int rtl8139_rx(struct net_device int received = 0; unsigned char *rx_ring = tp->rx_ring; unsigned int cur_rx = tp->cur_rx; + u16 status; DPRINTK ("%s: In rtl8139_rx(), current %4.4x BufAddr %4.4x," " free to %4.4x, Cmd %2.2x.\n", dev->name, cur_rx, @@ -1947,7 +1948,6 @@ static int rtl8139_rx(struct net_device unsigned int rx_size; unsigned int pkt_size; struct sk_buff *skb; - u16 status; rmb(); @@ -2024,17 +2024,17 @@ static int rtl8139_rx(struct net_device cur_rx = (cur_rx + rx_size + 4 + 3) & ~3; RTL_W16 (RxBufPtr, (u16) (cur_rx - 16)); + } - /* Clear out errors and receive interrupts */ - status = RTL_R16 (IntrStatus) & RxAckBits; - if (likely(status != 0)) { - if (unlikely(status & (RxFIFOOver | RxOverflow))) { - tp->stats.rx_errors++; - if (status & RxFIFOOver) - tp->stats.rx_fifo_errors++; - } - RTL_W16_F (IntrStatus, RxAckBits); + /* Clear out errors and receive interrupts */ + status = RTL_R16 (IntrStatus) & RxAckBits; + if (likely(status != 0)) { + if (unlikely(status & (RxFIFOOver | RxOverflow))) { + tp->stats.rx_errors++; + if (status & RxFIFOOver) + tp->stats.rx_fifo_errors++; } + RTL_W16_F (IntrStatus, RxAckBits); } done: _ --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8139-20.patch" drivers/net/8139too.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletion(-) diff -puN drivers/net/8139too.c~r8139-20 drivers/net/8139too.c --- linux-2.6.8-rc2/drivers/net/8139too.c~r8139-20 2004-07-31 12:44:12.000000000 +0200 +++ linux-2.6.8-rc2-romieu/drivers/net/8139too.c 2004-07-31 14:20:36.000000000 +0200 @@ -593,6 +593,7 @@ struct rtl8139_private { int time_to_die; struct mii_if_info mii; unsigned int regs_len; + unsigned long fifo_copy_timeout; }; MODULE_AUTHOR ("Jeff Garzik "); @@ -1937,7 +1938,7 @@ static int rtl8139_rx(struct net_device u16 status; DPRINTK ("%s: In rtl8139_rx(), current %4.4x BufAddr %4.4x," - " free to %4.4x, Cmd %2.2x.\n", dev->name, cur_rx, + " free to %4.4x, Cmd %2.2x.\n", dev->name, (u16)cur_rx, RTL_R16 (RxBufAddr), RTL_R16 (RxBufPtr), RTL_R8 (ChipCmd)); @@ -1977,6 +1978,14 @@ static int rtl8139_rx(struct net_device */ if (unlikely(rx_size == 0xfff0)) { tp->xstats.early_rx++; + if (!tp->fifo_copy_timeout) + tp->fifo_copy_timeout = jiffies + 2; + else if (time_after(jiffies, tp->fifo_copy_timeout)) { + DPRINTK ("%s: hung FIFO. Reset.", dev->name); + tp->fifo_copy_timeout = 0; + rtl8139_rx_err (rx_status, dev, tp, ioaddr); + return -1; + } goto done; } _ --Qxx1br4bt0+wmkIi-- From ahu@outpost.ds9a.nl Sat Jul 31 06:08:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 06:09:03 -0700 (PDT) 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 i6VD8vs8013023 for ; Sat, 31 Jul 2004 06:08:57 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7237F3FDC; Sat, 31 Jul 2004 15:08:53 +0200 (CEST) Date: Sat, 31 Jul 2004 15:08:53 +0200 From: bert hubert To: Herbert Xu , netdev@oss.sgi.com Cc: davem@redhat.com Subject: [IPSEC PATCH] missing break in UDP decap code Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-ID: <20040731130853.GA30481@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Herbert Xu , netdev@oss.sgi.com, davem@redhat.com References: <20040731083456.GA24761@outpost.ds9a.nl> <20040731112048.GA27893@outpost.ds9a.nl> <20040731115230.GA18537@gondor.apana.org.au> <20040731121828.GA29497@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731121828.GA29497@outpost.ds9a.nl> User-Agent: Mutt/1.3.28i X-archive-position: 7379 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 > I've tried it both ways, both don't work. I should have mentioned that. Against 2.6.8-rc2, neatly solves the problem. The missing break causes the packet to be tested against both encapsulation types, one will always fail. --- linux-2.6.8-rc2/net/ipv4/udp.c~orig 2004-07-31 15:04:56.000000000 +0200 +++ linux-2.6.8-rc2/net/ipv4/udp.c 2004-07-31 15:05:19.000000000 +0200 @@ -975,7 +975,7 @@ } else /* Must be an IKE packet.. pass it through */ return 1; - + break; case UDP_ENCAP_ESPINUDP_NON_IKE: /* Check if this is a keepalive packet. If so, eat it. */ if (len == 1 && udpdata[0] == 0xff) { @@ -988,6 +988,7 @@ } else /* Must be an IKE packet.. pass it through */ return 1; + break; } /* At this point we are sure that this is an ESPinUDP packet, -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From herbert@gondor.apana.org.au Sat Jul 31 12:32:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 12:32:31 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VJWJI4028771 for ; Sat, 31 Jul 2004 12:32:21 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BqzaU-0005ia-00; Sun, 01 Aug 2004 05:32:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BqzaO-0005Q7-00; Sun, 01 Aug 2004 05:32:04 +1000 Date: Sun, 1 Aug 2004 05:32:04 +1000 To: bert hubert , netdev@oss.sgi.com, davem@redhat.com Subject: Re: [IPSEC PATCH] missing break in UDP decap code Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-ID: <20040731193204.GA20793@gondor.apana.org.au> References: <20040731083456.GA24761@outpost.ds9a.nl> <20040731112048.GA27893@outpost.ds9a.nl> <20040731115230.GA18537@gondor.apana.org.au> <20040731121828.GA29497@outpost.ds9a.nl> <20040731130853.GA30481@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731130853.GA30481@outpost.ds9a.nl> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Jul 31, 2004 at 03:08:53PM +0200, bert hubert wrote: > > Against 2.6.8-rc2, neatly solves the problem. The missing break causes the > packet to be tested against both encapsulation types, one will always fail. Sorry, that was my fault. Dave, please apply his patch to fix NON_ESP reception. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From scarfboy@gmail.com Sat Jul 31 12:51:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 12:51:44 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VJpaeS029184 for ; Sat, 31 Jul 2004 12:51:37 -0700 Received: by mproxy.gmail.com with SMTP id 75so72099rnl for ; Sat, 31 Jul 2004 12:51:27 -0700 (PDT) Received: by 10.38.3.58 with SMTP id 58mr244838rnc; Sat, 31 Jul 2004 12:51:27 -0700 (PDT) Message-ID: Date: Sat, 31 Jul 2004 21:51:27 +0200 From: Bart Alewijnse To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: gigabit trouble In-Reply-To: <20040730234120.A15536@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_44_6682347.1091303487749" References: <20040729210401.A32456@electric-eye.fr.zoreil.com> <20040730205412.A15669@electric-eye.fr.zoreil.com> <20040730234120.A15536@electric-eye.fr.zoreil.com> X-archive-position: 7381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scarfboy@gmail.com Precedence: bulk X-list: netdev ------=_Part_44_6682347.1091303487749 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, 30 Jul 2004 23:41:20 +0200, Francois Romieu wrote: > [...] > > Anyhow, on transmit from the celeron box, under extreme benchy > > circumstrances, I've seen it around 16Kints/s on transmit and 13k on > > receive. But under everyday nfs/samba, 6400 is about the best it does > > either way. > > The figures does not seem bad. Except they're about a factor 1.2 to 1.7 faster than my 100mbit, in practical (network filesystem) application. That's very short of spectacular. > I am curious: which chipset does the motherboard include ? > An 'lspci -vx' sums it quite well. Ermm... VIA, I believe it was called Apollo Pro. VT82C693. But as the rest may matter, the full lspci -vx listing's attached. > [...] > > This may be due to fiddling with said wmem, etc values, I set some of them > It should not. If my computer did what it should do, would I be here?:) > > considerably larger. I did get a few percent apparent speed increase, > > incidentally, though that may have been wishful thinking. > > > > I guess I should try >= 2.6.8-rc2-mm1 next? > > Please. Do not compile in preempt/ipv6/smp. SMP is supposed to be safe > but you do not need it and it will not make your r8169 faster if you have > only one CPU. I'd welcome a 'vmstat 1' output as it gives the bi/bo. ipv6 was nonsense anyhow (and I think loaded as a module), smp was force of habit as something kernely ages back wanted it. But is there really no point to preempting in a server? Right, both computers now run 2.6.8-rc2-mm1. It's better. Roughly speaking, the top *benchmark* speeds, rouding slightly up, are: udp: 33MB/s (using ~26Kints) one way, 12MB/s (9Kints/s) the other, tcp: 22MB/s (16Kints)one way, 12MB/s (9Kints/s) the other. (The 9Kints ca be 12 when the packet size is 1K or 2K) Oddly enough, the slow direction is sending from my new computer (XP1700, KT333, 1GB ram) to my old (both running linux and the mentioned kernel). I'm fairly sure this is due to the fact that my asus motherboard is crap, and I guess I'll have to settle for it, unless one of you is very good at black magic. Because trust me, the way hardware and chooses not to work, apparently based on slots and/or irq's is just *weird*. Bah. Practical speeds increased far less dramatically. nfs now sustains at 10MB/s, with the occasional 12. Samba increased less, about half a meg a second, it sustains speeds slightly over 8MB/s, to both linux and windows. I guess no network filesystems focuses on speed? I mean, I did always wonder why nfs and samba on 100mbit transfers averaged around half the line speed, and that's counting large files (no tcp startup to blame). I don't suppose any of you know a good windows nfs client. I guess I'll have to settle for this. I'm just annoyed that the 'giga' is basically a joke, especially on my setup. --Bart Alewijnse ------=_Part_44_6682347.1091303487749 Content-Type: text/plain; name="lspci-vx.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="lspci-vx.txt" 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO= 133x] (rev 06) =09Flags: bus master, medium devsel, latency 0 =09Memory at dc000000 (32-bit, prefetchable) =09Capabilities: [a0] AGP version 1.0 00: 06 11 91 06 06 00 90 a2 06 00 00 06 00 00 00 00 10: 08 00 00 dc 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/= Pro133x AGP] (prog-if 00 [Normal decode]) =09Flags: bus master, 66Mhz, medium devsel, latency 0 =09Bus: primary=3D00, secondary=3D01, subordinate=3D01, sec-latency=3D0 00: 06 11 98 85 07 00 20 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South]= (rev 11) =09Subsystem: VIA Technologies, Inc. VT82C596/A/B PCI to ISA Bridge =09Flags: bus master, stepping, medium devsel, latency 0 00: 06 11 96 05 87 00 00 02 11 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B= /VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) =09Flags: bus master, medium devsel, latency 32 =09I/O ports at e000 [size=3D16] 00: 06 11 71 05 07 00 80 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 0000:00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management = (rev 20) =09Flags: medium devsel 00: 06 11 51 30 00 00 80 02 20 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:00:09.0 VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 06) (pr= og-if 00 [VGA]) =09Flags: bus master, medium devsel, latency 32, IRQ 15 =09Memory at d8000000 (32-bit, non-prefetchable) 00: 33 53 31 56 07 00 00 02 06 00 00 03 00 20 00 00 10: 00 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 01 04 ff 0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/= 8139C/8139C+ (rev 10) =09Subsystem: Realtek Semiconductor Co., Ltd. RT8139 =09Flags: bus master, medium devsel, latency 32, IRQ 11 =09I/O ports at e800 =09Memory at df001000 (32-bit, non-prefetchable) [size=3D256] =09Capabilities: [50] Power Management version 2 00: ec 10 39 81 07 00 90 02 10 00 00 02 00 20 00 00 10: 01 e8 00 00 00 10 00 df 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 20 40 0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 = Gigabit Ethernet (rev 10) =09Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet =09Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 10 =09I/O ports at ec00 [size=3Dde000000] =09Memory at df000000 (32-bit, non-prefetchable) [size=3D256] =09Expansion ROM at 00010000 [disabled] =09Capabilities: [dc] Power Management version 2 00: ec 10 69 81 07 00 b0 02 10 00 00 02 08 20 00 00 10: 01 ec 00 00 00 00 00 df 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 00 de dc 00 00 00 00 00 00 00 0a 01 20 40 ------=_Part_44_6682347.1091303487749-- From romieu@fr.zoreil.com Sat Jul 31 14:19:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 14:19:52 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i6VLJirc030430 for ; Sat, 31 Jul 2004 14:19:45 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i6VLIah9031514; Sat, 31 Jul 2004 23:18:36 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i6VLIa3E031513; Sat, 31 Jul 2004 23:18:36 +0200 Date: Sat, 31 Jul 2004 23:18:36 +0200 From: Francois Romieu To: Bart Alewijnse Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: gigabit trouble Message-ID: <20040731231836.A31121@electric-eye.fr.zoreil.com> References: <20040729210401.A32456@electric-eye.fr.zoreil.com> <20040730205412.A15669@electric-eye.fr.zoreil.com> <20040730234120.A15536@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from scarfboy@gmail.com on Sat, Jul 31, 2004 at 09:51:27PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 7382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Bart Alewijnse : [...] > of habit as something kernely ages back wanted it. But is there really no > point to preempting in a server? I don't know: I have no URL for the figures at hand. > Right, both computers now run 2.6.8-rc2-mm1. It's better. Roughly > speaking, the top *benchmark* speeds, rouding slightly up, are: > udp: 33MB/s (using ~26Kints) one way, 12MB/s (9Kints/s) the other, > tcp: 22MB/s (16Kints)one way, 12MB/s (9Kints/s) the other. > > (The 9Kints ca be 12 when the packet size is 1K or 2K) Can you give a try to a napi version of the module (it is a compile-time option) ? You may want higher {r/w}mem_max as well as renicing ksoftirqd with a strongly < 0 value on the celeron client. > Oddly enough, the slow direction is sending from my new computer > (XP1700, KT333, 1GB ram) to my old (both running linux and the > mentioned kernel). I'm fairly sure this is due to the fact that my The r8169 driver has been reported to be faster on Rx than on Tx so your observation makes sense. [...] > I guess I'll have to settle for this. I'm just annoyed that the 'giga' > is basically a joke, especially on my setup. It should be possible to make things slightly better for the celeron box as a client. I'll cook up a patch. Would you be kind enough to do some ftp transfer test where the celeron box retrieves data and send the 'vmstat 1' output of the client during the test ? -- Ueimor From davem@redhat.com Sat Jul 31 23:41:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 23:41:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i716f70D027011 for ; Sat, 31 Jul 2004 23:41:08 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i716epe1017661; Sun, 1 Aug 2004 02:40:51 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i716epa30111; Sun, 1 Aug 2004 02:40:51 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i716e8jj024532; Sun, 1 Aug 2004 02:40:08 -0400 Date: Sat, 31 Jul 2004 23:40:03 -0700 From: "David S. Miller" To: Herbert Xu Cc: andreas.steffen@strongsec.net, dev@lists.openswan.org, users@lists.strongswan.org, netdev@oss.sgi.com Subject: Re: SPI generation by netlink_get_spi() Message-Id: <20040731234003.64cf8b5d.davem@redhat.com> In-Reply-To: <20040730115009.GA5689@gondor.apana.org.au> References: <4108F5F5.4020001@strongsec.net> <20040730115009.GA5689@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Looks good to me. Patch applied, thanks Herbert. From davem@redhat.com Sat Jul 31 23:42:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 23:42:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i716gdQg027191 for ; Sat, 31 Jul 2004 23:42:39 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i716gVe1017943; Sun, 1 Aug 2004 02:42:31 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i716gVa30594; Sun, 1 Aug 2004 02:42:31 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i716fmrG025075; Sun, 1 Aug 2004 02:41:48 -0400 Date: Sat, 31 Jul 2004 23:41:43 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Remove redundant check in xfrm_state_add() Message-Id: <20040731234143.2b11ff3c.davem@redhat.com> In-Reply-To: <20040730121056.GA5911@gondor.apana.org.au> References: <20040730121056.GA5911@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 30 Jul 2004 22:10:56 +1000 Herbert Xu wrote: > This is the patch referred to in the netlink_get_spi thread. Yep, looks good. Applied. From davem@redhat.com Sat Jul 31 23:46:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 23:46:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i716kAw0027773 for ; Sat, 31 Jul 2004 23:46:11 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i716k1e1018484; Sun, 1 Aug 2004 02:46:01 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i716k1a31120; Sun, 1 Aug 2004 02:46:01 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i716jJmP026150; Sun, 1 Aug 2004 02:45:19 -0400 Date: Sat, 31 Jul 2004 23:45:13 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] xfrm_alloc_spi always succeeds on non-trivial range Message-Id: <20040731234513.744d4793.davem@redhat.com> In-Reply-To: <20040731020044.GA13830@gondor.apana.org.au> References: <20040731020044.GA13830@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 31 Jul 2004 12:00:44 +1000 Herbert Xu wrote: > xfrm_alloc_spi will always succeed if minspi < maxspi, even if > minspi + 1 == maxspi. If the range is already occupied this > will obviously lead to breakage. > > Of course this is very unlikely to occur in reality due to the > size of the range. Although with IPCOMP it might actually happen > on a very large server. > > The fix is obivous. Indeed, applied. You're certainly making the rounds auditing the SPI handling lately. :-) It is much appreciated. From davem@redhat.com Sat Jul 31 23:52:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 23:52:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i716qVT8028229 for ; Sat, 31 Jul 2004 23:52:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i716qEe1019360; Sun, 1 Aug 2004 02:52:14 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i716qEa32127; Sun, 1 Aug 2004 02:52:14 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i716pVeF028229; Sun, 1 Aug 2004 02:51:31 -0400 Date: Sat, 31 Jul 2004 23:51:26 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: [PFKEY] spirange should be in host byte order Message-Id: <20040731235126.40344324.davem@redhat.com> In-Reply-To: <20040731100444.GA17201@gondor.apana.org.au> References: <20040731100444.GA17201@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 31 Jul 2004 20:04:44 +1000 Herbert Xu wrote: > So the conclusion is that we can and should change our PFKEY > implementation to use host order for these fields. I agree with this conclusion and have applied your patch. Good thing we caught this now. Thanks Herbert. From davem@redhat.com Sat Jul 31 23:54:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jul 2004 23:54:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i716sIAT028583 for ; Sat, 31 Jul 2004 23:54:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i716s4e1019578; Sun, 1 Aug 2004 02:54:04 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i716s4a32339; Sun, 1 Aug 2004 02:54:04 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i716rLWC028740; Sun, 1 Aug 2004 02:53:21 -0400 Date: Sat, 31 Jul 2004 23:53:16 -0700 From: "David S. Miller" To: Herbert Xu Cc: ahu@ds9a.nl, netdev@oss.sgi.com Subject: Re: [IPSEC PATCH] missing break in UDP decap code Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2? Message-Id: <20040731235316.19e0db75.davem@redhat.com> In-Reply-To: <20040731193204.GA20793@gondor.apana.org.au> References: <20040731083456.GA24761@outpost.ds9a.nl> <20040731112048.GA27893@outpost.ds9a.nl> <20040731115230.GA18537@gondor.apana.org.au> <20040731121828.GA29497@outpost.ds9a.nl> <20040731130853.GA30481@outpost.ds9a.nl> <20040731193204.GA20793@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 1 Aug 2004 05:32:04 +1000 Herbert Xu wrote: > On Sat, Jul 31, 2004 at 03:08:53PM +0200, bert hubert wrote: > > > > Against 2.6.8-rc2, neatly solves the problem. The missing break causes the > > packet to be tested against both encapsulation types, one will always fail. > > Sorry, that was my fault. > > Dave, please apply his patch to fix NON_ESP reception. Done, thanks guys.