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+t0tho3