From jfvogel at gmail.com Wed Oct 1 22:16:48 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Oct 1 22:16:56 2008 Subject: potential nasty bug in igb and ixgbe Message-ID: <2a41acea0810011516u77ca05b1k2df527e453dfe392@mail.gmail.com> Jeff Roberson uncovered an issue that might be behind any number of possible problems. Our newer hardware (meaning those supported by the igb and ixgbe drivers) overwrites the buffer address in the RX descriptor with a variety of data in support of advanced features (see the relevant header files for details). However, in the rxeof code, if you fail to get a new mbuf, and hence, will discard, the descriptor is being left in the wb form, meaning that the address is jibberish for the next time the engine uses that descriptor. I am modifying get_buf so that it fixes the address in the descriptor when this happens. I know when my test group has had the igb driver under heavy load they have had some panics, right now I'm not sure if this has been at the root of those or not. If you want to see how I'm changing the code just speak up :) And thanks for finding this Jeff. Jack From linimon at FreeBSD.org Thu Oct 2 01:19:11 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 2 01:19:17 2008 Subject: bin/127719: arp: Segmentation fault (core dumped) Message-ID: <200810020119.m921JABO028974@freefall.freebsd.org> Synopsis: arp: Segmentation fault (core dumped) State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Thu Oct 2 01:18:22 UTC 2008 State-Changed-Why: To submitter: since the patch was not encoded, it confused GNATS. Can you reply with a followup that has it encoded somehow? Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=127719 From yonyossef.lists at gmail.com Thu Oct 2 09:40:35 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Oct 2 09:40:41 2008 Subject: Freeing an mbuf cluster Message-ID: <20def4870810020216x31f9c0d8yd4776622928c412e@mail.gmail.com> Hi All, I'm trying to manually build an mbuf chain with clusters in various sizes. I'm doing it using the MGETHDR and MEXTADD macros, it works fine. Now I'm looking for the simplest way to free an mbuf cluster, since I want to free the clusters seperately. This function will be given as a parameter to MEXTADD. Is there a simple command like 'free(buf)' to free an mbuf cluster? Thanks Yony From Livitin at itprofservice.ru Thu Oct 2 11:40:04 2008 From: Livitin at itprofservice.ru (=?koi8-r?B?7MnXydTJziDzxdLHxco=?=) Date: Thu Oct 2 11:40:14 2008 Subject: bin/127719: arp: Segmentation fault (core dumped) Message-ID: <200810021140.m92Be4Dw018958@freefall.freebsd.org> The following reply was made to PR bin/127719; it has been noted by GNATS. From: =?koi8-r?B?7MnXydTJziDzxdLHxco=?= To: Cc: Subject: Re: bin/127719: arp: Segmentation fault (core dumped) Date: Thu, 2 Oct 2008 15:15:24 +0400 This is a multi-part message in MIME format. ------_=_NextPart_001_01C92480.2901E19D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C92480.2901E19D" ------_=_NextPart_002_01C92480.2901E19D Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable <>=20 Livitin Serg livitin@itprofservice.ru ------_=_NextPart_002_01C92480.2901E19D Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Re: bin/127719: arp: Segmentation fault (core dumped)

= <<arp.rar>>
Livitin = Serg
livitin@itprofservice.ru

------_=_NextPart_002_01C92480.2901E19D-- ------_=_NextPart_001_01C92480.2901E19D Content-Type: application/octet-stream; name="arp.rar" Content-Transfer-Encoding: base64 Content-Description: arp.rar Content-Disposition: attachment; filename="arp.rar" UmFyIRoHAM+QcwAADQAAAAAAAACF1HTAkC0AbwQBAACwIwACRpODO8Z5QjkdMwgAIAAAAGFycC5j b3JlAPBcmVomYdkVEMiRnhQgOZJk6CMQgKCCRS0QTE6ZkCHTHHXBOtIDFgqKwTMJMhIGTJjkyHT7 jrggKDIbs1TVNdmrHdHdNdNWCgorm64oCm7o6xfRQ9WL7F11YIKTfr0ei7Fn77/6rlyEzIVy7vJm SJ1K7++/ffsqSsro86K88rp51Zzl3JP63c5y/9Wf18qvlVXyrr5Vc/L+fnyq8rnnK503fOXec5l1 7XksxyddsjdJoRXzYuaurP8tNGUVSm3uawrCpQ8Xhg7+um25lSFkoGqr8fNhP5NxsYqB6VBbjFnv tOmOjmtN9nMdVlqlTrtxF7IPShGZnrHPq4FzCL2NduOZnJzm9QraT1jn1UDVwizro0jn1/noqx4G NdTGsc+n8/Ilwca1lyOfUwMlwkNzVQL2G7f0EZTbpknz62BqsrPua+Jf8lCtzKJudwVLSlA5Seuq qtjnyXoJKLlae5SnKXLQ3LGBmfUQ3LOBNy8NzM0EewjuWkCx9lCtnVbHPqYGq52fc1VEp/j82FJs VTpTtRW8W85RYL8ndW1t6fNcjNXVou1urmbbmfsREfgUSmfrWZxzUReYrUX2r+JkJvMQN79xtJ9J Ewm0WudppPOWHh675tRWeH23A2Hd/g8R4ysDwmZLfvQ2HE0L5xWB+9kHi99rSzVUR8Z+13ibx5l9 r/OZv0fpPh9tsfTTxe7e96/0H1PR+57X/143F9jxHg8Lf/O7b9UVZ9b2/tfyfmg6ePgBD4Xf3/6t jsdL1Wd/Xs3qr+79Z1Wx3bqvRS0Eny8l/TX4/K3+u/v8PaP9HqrSQWoPfdwfW5+B1mR4DXc14Oz+ /vZRXWXnAV/0a/gO5/swJ67Y/hwitXQfUyedR4Vdd4zXf0/80Sbt4Glses1+u7f8WJF4PfWdvu3U 5ag/1nX1Je67iNul5gA2rG80BuQr+sr6a0HgSlzdwpewOs5HgMCH5pS/vg9183xLJTeS6zkagTrq Eb6x4jyEja12S29H75+wgbHFXdpQkt/63osAH/P6aFr277Glrtd3f6JPKgnf+8kMyv2fA+7ru+kN +/+BKKpv/SiB9L9eEWMr9WB713/uJQdd/fQFrv1YS/75vm/69qf8qjSN7DS3Nf+T+vSdb8yhDXgf xVE39GSa0Mk6nKI2orjUwOszfAVAf9EJa7q5R/W3fopvWdZ/vmuo8HLaXksj1vOa7S2dSZ7mKCWT 4CRXx/04ORc83VMZHXa/v4HfbWXXfklO/dR3GW9jznb9b8iierrb7gqHJGPXetke2T0vnu4kjfS6 TZXtMj1X2d26r10TreUr6D4o0fkXXpSGRSoTqctIb6Xe9LylRDH0e/qJ7ooMd5hUVs1KL3b5Hrcb 1P1cBnWQPEfJ19ljXnoFl7idbzQ79SC8zVB4zK/Z6m/u9p/yL/rebrusy2Cn5qrSboVxXd9RTW11 dI9vF4+9RJvdvk8niqJd/E7+pXOZLrM3h1C32NdBaXkslpeVseq/ywXrGB+flN1rpVW1Cdto/57P I193yXVfnlSG03g6kvdrHJWt+jS/6jBm6jusX1F/Xdbk7HqP+1f4oXU/gkAvfSY+73eUlb72LpWn ooCorfgYLtIHR9FZbp4hmoVxu0F+GU16S3eqvJOyLXoYP08DwLjXeB9/Z3zPqyS31HG4rAB8yVS3 9HGUT/qlav2UoV7+mRb/DJ5RM563kcbj6Ft/y/f20x6pMT834ILv/CkOLLT4NuTqTnOs/Pd5+y9x pMjIdeuokPq/gw7B+xsn/Udxk/Y+y53nO3lF62iafxqDXolqUR4cH8F9iFfxQenfNgdb2noqKkdt RUMd//tVG3Q0SK4ieB76UHlYO0aaBlIP1cCVQrxQuZx8lP2NrtXKBjtm9R4eR9pjO2yNFYzlq7dv k43PUVT3NYCtj7fW+Jb/K/ZrWzvpaDX3ag9b9peR9/X9R28hk1Qb1hrkYP8cpnUjLaPwM2/YKHzv Dx/Ua7FdZ8/534d+rvn/U/Tx3/e87jv/01Uvc7B38h93/f4ahKPzMH2L6lUd5KD979+pbjv8ZKL0 +GyrZyv+DZ30qP3h7G73ja27HV6XqLKiF4FfKJ0mv6juK+VmzIZgHyOu4XXUT+cj2/AVtSfcvS0d 1nMpb6DnspnNHpMpoOJ43i+GtrfPeJLq70HD5rheipZXh+MpcRY2PFZSX7yvHUrHjMvxOVy9jxdL O566pcl0lzS4CbgdHgh7Lm0Fxd211cWtvS6O60Vxz9LOaHOzeIdBgiyf3eipbQ9JUfaPRZzoba7m we7XO0sEHRaHcQGCHobma50nPTLfpZuet7XaLn9Fb20iroLbOSDXVroLea1wJaLBvpq7t7DNct6n kOU5bk+Q9TzPJ+jmuMGeohnPYFbbBdwWLiUi0V1JHuQkj7otq1oPE/JXefklnBopYP+dwU9Ho6XB bTeCm0e0DxQ85a3FKiXNK52qfSdLti/UJVbcNo+l0cpPuGwI7WzQ2viebObRbfBNwcMEiSnLe32p coylobbQ4FNrrnbba4eJah6oGqwSg02XSsHo6VUbZ3aBSqslq6VLhs9g5eK3bXFrgi7dHYMuf0WD rO6XsZTO+ckbGQ/Z/c2DXnc9o81oMvNhzFpSezui2uNRLNt0mgwRNpee52g27vRYBNqF0lCHNsjf huGkLwDYHJKVKY1OeLzNWUtorm2qRHA5bjsBvjH0m56VJ63wU7apUN+mjl4u1Kaw2jZzRaG5oWMG ylgkXWhwU5SZmpSUmBLR5+2wM2FWfqifno8RH4GujttBdZ2UV7G2rUeeck/2vnQ4H+GupVNSg3V3 6Xgekmy/A9JIBns7ndBQNYOuhoc6K3waKHc9gh23RybQ/57Atnefk9mmqVvOawSM7RV5UqucGDa6 6Cia7KjraH4lpaPSXNzorqpRakzSaOgf23TvaKlaqnzBf2sG2qtpqtU+qgak7VWf9VKsF+4pcbY8 RKoX6LQYI02FPXkfek0F3iDlSitgpyrl7vpbm221Y9NtLwESs2MGnBX0GCFJ7os9trIru156Vi5N t1T+zUJVJzPO0JaiSsz5zZ1Wy6k821m/c5Uq2dmUUHuc5zbzTRw+T4q/seG0GGsYCuGtcSH2mXHO eMDaigdrz9tl/HhWElU0o6iddrc3NvoM5RMui6M7XTQaOiueurW70G1Um4r+ivx/d6jy+3gcQT3i s/r8RF+HPq+DHV+1TPmTmM1MVq/gOm9/VdzUDye+S4hHFw4dkWf46uvaZiWQcbGcwtmS3mmZGiB7 naP5mct/hSUc5wHTyRVAP28VjZzUe2gqLBj60ix5ijXzKxSlb46wozknNSO8VTM/Oebibu85Odf1 cFQ/uZO7wsInmq2vxSyZnRZnq6iBoqEJr5O/d9xW2cHlhmEoU7TvpPmSM9PtW+b7ivsODkrMvJvq GpyfmLDoJO9NE9y98+G+W1/MbrYfYifhifpWPuMhYed0sVwcTLtblvE/sJzoJzpnuXvnw3y038vm rD7ET8MSl2O82GQ00V52Jr++wV8vOeonMzk8AfQTnTTmrzO72Hvonw4mq6HaP/nOfYnPwptxZKaq l/bvVhY/InWKmnx9D/Nd/i+b82lf+MVwj7+SqGVhI0obNT1aLmd/XYB8zf19OmJB5+UOe2FtU9Rd mL3HQVlhbgdbxj9Pf19PKtuDOgX9uV3Y36J1dEPU7vj+2iYTcLagTv89dUco3APptfOtbAwm1hvP T9VYlY1kTH/OgsJuFt0+nftayCpVVrY+x+dX7Zs2ERIXzVbbBLOL1UFzcCnabCj5z01ZeRpOXsSn abCTc5xEItHYwJ7TU7TnB7gY1cCnaLuayneVrIl7PHhwKdpsKPpU5YQul8+Cp2i9PCONhmv/Fv5W JPapRXnjiVKnFzEp2rbgup3w9PNkt4x/XxKdqkl6093CRL+EX8CnaL1dYXl2ta6BPaL1sI4vcDGS 7eCntF6+eMJR4VSONnMJs2FWyzw0SpDiWkg+E2ocrC7LcKN9XEp2i6UI43cDGqgT2qI8pxxTJO+g T2rblf02ZxFXKcTdxX4+nlO54soX2ECe09J4y8b8zEntUpieOMa90kCe1Ok7tIzoh6nJY/UzlO1O k8elaqsY7qBTtNTdOPSRv18Se09J443EyuJvfcwVO2FumlziKuU4s4FO0005PGEiXMYz8CnaaamT xTtaRjTwKdqdJ445p3bQJ7TTYSfac6PpSyWP1vc19PKbCvWpC9+wqreiHkt3x+P+hX7ZtOmPhXdo Wqxu58wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEP8tKp6P9VDd3jfV9H+TF5LDf11LJVvR0Ho/K2xzUxujlH1ds Um3eMslBRyj8md+q3GZNTiJXqqc7+M4mEUx8M2vhObeMQmTqnKN3SVPSC6x9/5maFtsNT+frpsKY dff5GrGbd6XodPHwCH8WIzkW58whgfgzYyvxUSj68TNPuazGU697qvvcrNH1clI+/WeBfezwofF7 xtAxsv1NkNL9zwrObyszjaCdfBc9z9tlZvQewzP0Osmj6daUuoWoWldDZ87xldDTj+zh7l/2Pm81 CVdCu7998jJ46aHs0yNbGFOrmn9r9cfS6ywjKNrvVQ9/moam74/9NdNT9eP8XMbtDU0sOR6yGnz/ GfxfZ7GaHi+n4eGp62HI9jDV4b0Xt4eM0/2sXDT5zy/ajNw073+TdOx+BDxnz/f4+Ono48jnIafP 6b/tz3YQ8Z6XGw1PR+X6V2sNOT4Hpv6u8mh4vvMZHUyk/I6GGnzvusf6b0U0PF/Z42GpmIci3jrf C/HDxnf7rHUuo8jQw0yzEm+a+HjPhf8Q1O8n5FxT1uw3uHjPQaKGp6mnyOmhpyNx2P+HZw8Zuk0+ pzXxIe/sKepzfxOr7SHaYuNN/hp/38xiIFnN5eZuMkp5eWEiNdrDvcksW+isZvLLPH6V+nhp5mvh qftEk2O4rTY06TU/744/Dq99U9LQzz1M2Gx2PtZp8fIYVK9Dipo9zk8n/8uUjj8MF0FzxfD2t1c2 s37gRoLi7mj+tqZt4x9De61O7wpNHHyGBdfNjN1yU5yHVzqum13by0cm64qdZnbaQz/P33pPO4z+ CFLL8/Mwy810GQ9BoNdytr1/cYubEsx1T0zGtHYfc5Xgt5xX7do87Lar5HsKDSujWoeYqCo0mxuO kC3HSlYlVYqGt9z82M476PmoU/8/ayUMu8yek9L1P3v6d1xOmSjotPX4v9u2kEc2KhGPhXYbjtKl aHo59HLXsFi4FbVjzM4nUUb1v+3uxfgYzJVG+Ms21E99rv27UPI5TVUXF4xWUXta3pqv37MOnb1U lVXtfC2I1Ev21bfpxiNaq5T33nJvWaXFzeMs3SsqtFe0UTwVdfKknP6DPWNPnV/lKryb/7bUQZOx yWP7ridl0WKbCx22/pMtlYLjcQD00ofUybqFN81TPpQjssrhk/vQLmM7LiILLUzMJ3ppz6qiuPN1 oum+uk/7HEA/BgfenNhCO4ifXUVKZHiZ5cjTinbUQOuidlWj/IWftt0z9+3kvKt2v9tud/v27zyr da/bblX79u2eVboP224j9+3W/2m5pUriqVHdE97y6pbc+YAAAAAAAAAAAAAAAAAEPG9fU9bYSynP 11PAOY37IaO2tbrOZ+ld9LdaK30F3w9vos5a2+QuLXQ220i66LZVKpEZ/RaO7yE3//9lfNuk2Dv5 mbxrlvufHwAAAAAAAAAAAAAABD9Cwqez4Fmttx/yc3aaHrX/hecsJt73fH1G1fJxut5NWq7EP9z5 gABDxFT2k+t1nP17nvm//U8fBDDPQ0rjR6Po9Bd5zP8PnNFcZ6w4r0dLhqUva82Jc372gzltSqha UHoOf0lHtdvsvbCXchgbxPtdJ22AfKbcb0va6VsrS4ixseLyljxWyuJ8TcVl8rlsvluMpaTQ209c EXIc/daLSXOCFgR0Nzgu1YPO1YG0S40GjyEucNNHl6kq0dLO4MNJszIXGDd0eiuuhwgGQwHSl5nd sbVWFtxno8/bW9vthKypo9sVsKI24lc7U270U6wy1dXOcwn0258wAAAAAAAAAAAAAAAAAAAQ+TmO S5n1PrfU8NxHF8fx+V5HK8Tw+J83+qVhleO4jh8rxfG8PxFjw/G8VL3sLaxscvlbbL8TxmX43Zud 57L2vG0tFcUpfy4/tt72C1kMMs8RxWW3TdOf6PcDvaBkMr5IK4fIbnvN/Nz5gACH1NVU974z79dV 98eZn51Hv7nlHge5Eq6aWw3amnlqZU0zdOdGnm5ozwo+rp33DIq6d/oyp23ExufMAAIceZq+L/Mt O/D2M78s+IAzzep3fH7vNHodXNvH7kRc1pTT1jO98uIGn/dEzU/uhHX/ui5qp+r20/V1Eerfu6j1 dz5gAIYlZ1Pf6K4jC8f+bd/V1dtP2f6YCddNvH7EX0njAvTOrg+ux1hS+TwO55/wNJufMAAAABD+ TL5fK7pBYX8f7W2/j/ebdw+PZDK8RxnD2Mv1lfKQ9/ePD/Mfue+YDm58wABD6ffTx/6nL/Yz7+/Y XD9OdrcPf06rcfhYRjE8ffEodbj63wg+38fa82Fx9fTbnzAACH8vV1tPzvcXBXuxj2/prjQaOahu duIVwod1c5yafHwACHy9PV4f5/BDL/6r+8AWZ1O74+z1W70fYFLHX7Pvaz/Pyj7+Ji1nEm7OFevo EnjMxcYvYP40Ky/ukHfxi0oKRi5gWcI7Gg5PG58wAAAAAAAQ8Z3v/nquorfx/W8Vx2VxXEWOLyvF 8bsvjuIx2guOGtc7nbqvqf4ZPWRwA3+7TY2gXwdjNx2K5/o8dV4/RjIUmxmAzQ4EsfcW13UeYq60 lN++wIS/wfOuxv5t0y97QXMDdfR/gzVRHbrjeZzXDZn1fLV+yszyV/ob/e9qFNXVAOSxma9ZzPLc hR9eS5rFZrkpsQDyOKwK43McfyEg+3Esji9o/E4uUbiuT9XiRMGXmuW5naNyVfx+DNzM+fHV+Czy GVv+fv+0mrqP1870m1c7rU7Rr/+GrD/P1kF86abt7/72GH+j3m57/hy63PmAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA/9+w+BNL1BAABER0vAZpBgOwnSC8Jdm3T6kFbWUToF1zhbJFMTj93AAAA AAAAAAAAAAAAAAEN62ictcWtzc3Wi2VoLW7tqUsaTu5Y0b6q40clzOk0NttLzlrtFtbrn5P7i7pa LSSbnsAOi0NroJd8tz1dto9od1gNpYIOhucDeAjQW/S0tJgsdFtPt6mNHHU2aljSmWFjRgqlL93G y+GqY0p5NmanQgEqY0rL1saO+8IPx9TGj9bPWuhoP7A1d4WNILFLnulpXOERVGpuQtbjgsAVrgR0 HP4NGBn2ekwOUD+qY0gtyVdHQhc8UWS8uZAMDVxcW2cwkf0hVtdyTWewCeKbtSPF+0mj28V4q0pf 1CrqyPabcSPMBtthJ1s7P6S7zui6OpMnNaLRUtDgH2smCVnsAOAqjpwfVUt3NvUntYYq3tuitrfR 0T1aPpdDgyyDbQtBcdDo/GxWCbodFRRvao3Nrd5/9ikM9oMBVWcmiuqJz7Qy6EZfrbW30ko6RvW8 qXFD2lz2zdHs7BNztBuZ2CtahZkM5yTbHgebm+HxOx2OW4iGx/PIHpontFw51mXH+QEo+9xHE0Y1 G84upjPOvQzMchzvMep5nkua4/1fr6H/M+s5jkvV8tyE3Dze1mzPqc1y3N0RnH5jMbO4/meU2g8f zXK87mPU8htA5KbKaTR3WU0eflS8ykv/hWW1A/uQ9TgKwB8lUfc16/M1HnNctzFR3ZuazXH8pszB z+3m9qP3PObL+XA+K7B/M9a5mSHZvWc1yfDcbNyXrJ1ynp8rxtjxNjJ3a+ZXiJOcvN6fluU4qbmM 1y9rcdBoJvUbNm5O257xPtR5uPubqTvS7Q9I2Xb+J9Jz82atrmb1Ocu5uZ0XRTcjbZygTSYCuloJ XVR5It5zP0FzQW8XbUF+6Wd+K9d0F6Vo+562uqDLRUOyM6sRI3arzNSk9zGi2XzWkwN+uts7s/P6 TBdwTaatbugHnbXpaA1Dkhto6HZDm4qvZDLqo8kVUOSJbQKHnA8rl+B5jZWaitDlOBzsVKJtaXA8 9FWysCpr1+1m5ibM01T1fYUBdDnYrlsKJuZsrw9jkJfTiILnedlbsW8q7Od8WPBu0lziYjSc9tD0 G1F8RTey9j0vr+cl9bjmYLpdrfNcaKb1cpquYtefyuIu8xVZuS1WOsKUDU9rCuqgWcodp9qvsNbX 4ywv+72fqfMLTFzqaBp/ySj5Rer/VOtfvuMdxTWqia36sFp/pyf/94qg5yNvgh5ic5pV7011c4ym q6p2ClV/6jA3qpNscxBa3l5Gcn82IZWTvoKlVc/o/q2NZWvJW+nxUCaF2Kh8Wzxs01hXw6GRxk1d AxTFq9jGNY5j26PITLIdZBeYiZF5lurdk3WV8PmeOym+QImReZbq3ZNvkSPyo6NzzpHXG58yatcv KlQ5i6nf7yxk1GNpEx1T4A8LdIGQfm2P7Sz/zsYbW/VPrHHt+/aJv9H+qtUsWmpmjj8Ma/58vd+A VHH4fk/o8rd/07jj8P0e+27Qbk1fNG/eMdYWNpLQlybaNSja05jHWE0/q4/buxIM835Ad/lh7OQ3 DO7uqju9XzMOGRShF0GXAeaoxq6uas/q41LTU+lkc3BlJRlX3koqafH4fiWPY1aqaftcZ5Wranx+ G7S+TVnHqfk7fOGq+pVh6rV4yw8dE8df0/BWf1aqD1dZ2Pta3uKpLW9zIp/1jPKM+YlAj737ipLn 4eBOzlZjcTO9rP7HcEZPm8dnzx0SPbbnzAhhtnE7f5ux2N/6bC7Hylp6rD0KlpzWNsNyFuqhF+uX kpPUxi0h3t7CI+tPbuO/iu9nPCbp+GC3yBlXIvYPZuoe9fDdw+y/E/Q3bwILfYHBNb4UFx0neWic 20D3Cv18F/PE+HE+U+o+2/KxfgwXASD7tOcqpMvOW8n/NzmknNNOe3nP6JztH+r77spR9f+KK1k5 vrhImwoMv+Ir09M9jE0j+RyMovPxP7Yn+ETTSf6t/tE16u/HBbzAsHGOXaqQq1nNHOdU/mfFf5NY 7yQf8zISXfnpyxeHKL5eTvspy7dW98/rfKfTTYlnkfQl3vQ46wnzV24P48qiW/e//m1H+t92SS9D 5HqJfISiP/7If7kph+Y/JBb1Jt/J/3cTfonBRJ37Wc6ic9w0r+N7t71/O+A/qf2P7nxXyaDSJ9Cs J3cT6j677T8Dwnhq78sFjIG6PMt3by3x55wDhHEvSuTcw9a51n3tF66h5dlP54Hv4mFf8+xOa2c+ +/Cq9wnZr4HXVtnj1GLq7PJb11XZ4vsTYWNqF0aqnZSHG8Tmv3XCxtPGw2Ox0V9I2P1RK+EdFJ5+ mTv2/K3QpmNVwcr2NJh6t3eYyVbM7FZGWrJ2kTJ/ckvOvgrP7HiPM+8kM56UfIVS9XLRs+vjLCaT /U8DsvO28nejkqfGnJFJbiKt5RfASpy5k70kodp92Wrx9XFUuzpqbXLuUfmaJHZbLr6A/1oLU/Sr 4qT/JczBUpyxnOGkgrSmeHv8608geWokn2tp+mk//LKL42iHJE1Xv4L8u70Y2qne/gxtTWG72cv/ 9orpImd9hsvkberrFV76CckDz8oer/8SlclJ1MHv0FZQOrpnm5IyzoPJCZuiLks5umknJKPP4zxy 3O/8jt56y4zttntBcW2dq7sHKW/87caPR87nLXOZ+22b0uct1zdW3RW1xLdpvzue0lxRu0zf5qP1 ufMh+DqeCx1hh9lKEdvT4B8fccpYUO083TdtmfrbYne7hVpqq/9iHRaZN5YZZdrgT1+6zR27fs9p +o+Psv7EZ33aV9G6hOik7qJSqi61rZz0M0+pe/d2p+J2lZ9RhJu9x22SneXHKeRJrJVm7jFzvHf8 eNbcf1P16J2XvnZXdJzXtVvkFkt9X+9yhxJv+sI9rt2OLsxcI1O/wrwudog0P6UgNNb3N5z9iqPL /wV1RuMxGOJcro5WMr++42JVxxalG7kWddPl3000KY2tkp9zE/8PovZVMbUB7qJ/LWzAM++o+NE7 1/pV3ppQafVnP8XKOlf61McRsoZ/nOfFmjsf21OhzJF9xOfyTx/REw/gK/9/HNT2LanPn6ZcTTyz cT3L+KePRwn/lA6+E+7dvE7Cp39a/6Yny3Zve1MbXS+fEzjj549bE+RWf2tXG1a4nv5y7esdsq/A Z77MzYbPlTn055/AqdluzspzJzU7uiifNnjfIT0sT3jL05/4RP+7qoztK2ZKq//tAwsj20kI+lA+ YvqmOKeRze4gfXhPiYF09htsbWzi+hmw2evqY4qFRYcehq42yCJ76EengcE6mc+g+O5eajG0cYTO dnPiVn/90D/sw8cUuOggaaMdJA927R9apjamPky6frWGzQ7bG2GRfdTn99T4B6HWxP63auxfwzT+ E85ND+jjo6uJ2oVxkI4CE7Kafg4WajG1so61Xv/f3oqZ5+af2OTieumjqZ2M/H/gKf3m4RW+A6fa l7r9lmenn6mEdNNRjb8nDQn7OTeYede0c0/Z7/++4StpZfRVMbfBV6QUfq4R080NT+eByzjZv2Wf BieqhP20DgYR7epjjuXIxjnoHwoRuG+T3qIHw4T0E1O6jLj1FMvH9T0EL+5hPEb7R86B0b+yp05W spPP+aajG36o63XQirjkt95vHYUOroZOw83h5TJ3n98hapuI5ye+xtVzI9qI5Y2FL6GVU+/Bjlj6 pHn42q5a5Yxyo6okxqd/jaj4C0d7jGV0Yo+BiL1scqnwJ6VnG1XNfuRjlR2Z3MlHKrmd+10cqOoE va+OVGOPvvhxyo+AEL2Ecqszux9PG28zYlkVvWC3iquW8UZZN4kmdtIeWP2p153F1Yf4JO2kqbH+ tdPXlIGuxdUxF2UC5+jGsXwMp+9pK898dWE4uBmZX3uwrQ83KQ1dlVuJzv/1A0/LylWEckRZ9zhm PPyj73OVao53/hTLH6GGHz2Kgf61csEX+KUhqf7KuXVF0ZKdKwq5TJ3Ra3rPQ4ZHYSE1euq2xRfo aDErv3/tGKMtTM8FV04c791ITXyyHv3mNjW2gZL0tW2KL+fioHe4chmKFj0lXJxF/jnL3iZGVaHR ecssQgWUlzw8QqZWQl9isOeOmoMemq2ci7umXeIoD70H/HBfVrThwEofNxn30S0kXd1xUa4Wchxt dVzAWbkHsc9VzHUXrJC9V6ireBRD1M5S4mrfjnf98hNP7Srd5O/g4e6Rvd5v+NjzkiNb9LDoSjMS dliFjS0JErmreIxmpCWllhzh9acs5XZv0kYzchepllrf2qwl7RDlflexrVotpSmv/8UY3tlO8fOZ njcOlP+MVOSqxvUY6mRF/xGGHozIerxCJ7eRjV97VySouiou0lVD4VaU+JRNH9WGucvTL22q5lOL 89X1czO62MfagWeIrB7uuiYiU/jga/gYS9PEpekq5kuL6WunMRSHCSOZmR+8fPH0KLEcZRjfEkXz GIQN/gaGgjiKt9qL/kid54GGY9liKcoExsDHyuQoU1u8rqOfrpyVo76KsufzwLTEU5RlScBwGGY7 OhYxFjNLRZTj6ugri/YSPvN4iUosT+9iFz+GRzr99rpsnTp5mbmpEWf0qubsi/uyh6/1FXKji/5p Iu59/Fa6sieFQkYiaPhUVA76rmo4v6kjmSloDvt6wnnqFz2UFvNaH00kS5xFsKKy+vxCp3M5rdLB eHWE/JE0/fYdhKMrLzfBTznOrxFtOSkT0/PVcyyd/mosBKzd/BPH6py/lfPbuscvIPETJ3ETUspC OKgar5kFqMZCvn6ZYyQxwNYiX2T6v8TUyctMRXj4NEychBefx0K46c1f90F2taqmoxdXL+MKmO1o h9/h1s97E093BfQx8K8ZApZ+C5mtKVNDSwq5ulN7xi6ujPfoRj8sC57Gab9cI+BOX3osRaCimLOr mbIv5e4XMd7AucRdRvdF+kjnr60p8jFYWN69UZT92k5af8wXD1ljHxL/1WHchNitvyQexiav0tXQ dxd6s6uaEi7WipGIqp/JRaz09XQMi7ehM/gq5uLYaKWo+a3x/UeV+px1hedrsuy6qTvcxWw+7t+p 02H09vh/vZmSqfZMo6NX8TbdVZ43PO5vLz+95X1Ul7yH/R0r83yP/RnfYw+rZclD6mrh9XO8nD6n hw+rpuUh9SlyrtIfV5XlofU1kPq3PqIfUr+XdfD6vC5iH1L+H1aePgAAAAhiGJ+/R+P/f1Paz55o Y+AQ9LvNPjqOCs6uOsVY+rwJJytXgyy9v6nAqV/J3FRfzqnJulEXLgvvc95JN9z5gAAIeD8LFY6w ylvoOetukts5s/O8NbW+e4fR6Lh8ruIehucoA8Z+yRaXs68cDT0od8hD1udHehln9zHWE+i/kclx j66PQbN25HtOfkQfp6iJ4rtrc8NxHD5agb8TPq09uzrEc9bXUN+O1Rz5tVpxc/tZ8GXQUDfjtsH1 NU5uIKOifbjm6G657iqeaoR7aem4go6PHg8c1ro7jKw0WkKz6I6J9vbVUuulubuKkN+Kjnv6dfGQ 0c0+3iUy60XQ21xiEMzul1FOm4go6J9vbkygay0917Tr4yGjmn28SmZzRaHnba6utsOp3racbgCj pn2qXU46wrXBfQXGe0W3WS+IIp7dpGugwYLjotur/Z7qe3iVTR6O326ktF39U5uIKOjx4PhHmh/Z DT0pdVTpPrRzT6+b6ryLgPK8jw6hfNY2DJ+3hwWUOHNrxqF81jYMn7iHBZQ4c2vGoXzWNgyfVw4L KHDm141C+axsGT6yHBZQ4c2vGoXzWNgyfuYcFlDhza8ahfNY2DJ6WHBZQ4c2vGoXzWNgyemhwWUO HNrxqF81jYMn1sOCyhw5teNQvmsbBk/4ocFlDhza8ahfNY2DJ/xw4LKHDm141C+axHi8LGzrC5MJ 7qRpqY1wtzova/H0cemrGs/q49PZ1sVlpQ79+WtH+Ms5q+2l3PV7LxKWOvlDz+HySK1HtorI+3pq hDGZ6uvxHT+h933FNcL09NcDEv5O7bUGaqqk+208VZ39XntSszp66slJKSL7z3WHNLXVeTjNfWd3 PWbdTnXQVK9hfr5Q6WSir3dY5ajtt6sLn/LdLDLSfy5AxhCdf21GPxKY+s2vgdJ8raHq+XwF67Ea W47a98T2O2+Dvrr8vj7DvPt7L+5h8hfuZkSoI+Rxez76Ujxkj1q8lgD5jD4sfLO9q6p5NranKBNd 1+AvO/D3mwva6qk6V7VSneSVct2svfjVW1FNSqK9axet0k25yzbqc95BWfzoVrdydvJb3FX8qeUv MzTVod98ngdofKedsMtkt7p5eOs8PtsBfdddvlhyuHyVqyXeeJ7PbfB8mdd63BH7D8Wy/QddFdjI ZibefQ6eKvslvdWnLHZ/s90f3yi7GVvNTe1dYMvfnxrmf07R+p9H6GqislvdRSUJTvJKui4FS+NV bYwNf8erTnO/3+wmhjsJdfBXsJ06av0UVeynfXOL20PT8pwdhac7wVhlpP7SanwaflcBefyywxuI i8v4n43Iwllvu4I9fj511fBOVpldPPTZSmtRKR7pioK/77Z/OQLuUXN2ctV7vaut2X9anO65PaPX +B6ONdX6KopKEp3nXzkrgVn8aq2m9f7ynX3P90MfhL30Ffw0Zng7CjlT9v8OH3e+8JYZLotn5bM8 HT4+xyeAvr+hUq6Mu2t6ayWIy3XXesiuRtdl/4yty6ToeD26nMV0FNaiUj6ig09Xs/5k8WcqcpdP V18ybt4xopIrYcHGuZ4OopKEp3nvpyVMWnxqrZ6dfCvt4Y/CeogrTp4X0uEsKOWVVphw8j09NWfG MtS4Snx66QzqcrOtdXTyt+JprjYT1noYLu+DnXyZZcxncrwlPP1NjTWolI7WiXm/7Pq/B/f7Mypy 96ersTl/GOwy0pJdcJGtCM6fHVEp3monJUxrfjVWz099Cut4vMzbnLI5/fwV/DRp4GplO+vcXtoe T9BlLDM87wthltPwnk+XyQy/81BeHh8oO/bejprV7brpusx8LBH2H19l2/FxWpkMrozz/mYq+0/C VL/Nb1+z99rIatJ309XZbJu4jXq/SYC+4v+HjXT8JUUlCU7z3+OqXApvj1mzmv1FWnLLjIY9h80E tOUsKXto32OUgtPioGK20Psvj5WWz9bPy1jlPJredX2mAvw+gdjXRlqbfxPY4fg59Z/LxVh6rZf1 t6iu+6DKbdTn6+fitRKR46UZ22W2fb1glzKnLP21XaPLOMavR7T+a9/lY1scpUUlCU7y05SpcCpf Hqt/9uh0IAAEgTvX+/q055nc9t5NjrD4H7Z8HkbbnzIfh/xXU0MfhjWn/fn4AE+jj5D/T+Xw4Y/D Gfy7v5Jn4vJOWMbnweaH/v4ux/RNTx+GM479HfU8djjlhVp/pbMTeYnhV1TxWCreBkVEPCDxtmYv 3kFx3u4bFpB9fBeohFzF++gvYwi9g9RBdBCNPBy1MHRxjUwctTa6mMaqD56C93CL+DzsF8GEauDz 0F8WEa2Dz8F82Ea+D6CC1e4JH24xkuzjXd+CUou3wH7/GLGDkh/4eMYReljf7bHwu9pjGW4t/RvT 2v6Hot0cTitwNXQrq6EbiC73cKL7lO/uawzfGqqfjsYXfqnv62vhPrsRT0FPPcQ9zB+8huaeD6+G 5qoP3UNzVwdvykNvX1lY7WS+PVrEdqxg9RDczMH7+G5cwfPcp4+vF52G5qoPPQ3NXB5+O7F3ENye nQRrfdrBUu0q2GNrPVYcPYfHgReINkp55OT+0i8QhYxnZTl7F4hTMxnm5zUxeImC5jO8nL+LxE4a eM9ROa2LxFMaqM76d9rt9EavtJ5aycpdrTu1/aTy2E5Z9rt9SMlPPJzlpF4iuFjGdlOXsXiK0ZmM 83V8YNMTYi5nvmq+C9kbaegPTju+1jFZmsp3+C2DI/Ihdk4X8KsmYZtbrxpmodkvndtY8FsGR+TC 7Jwv4VZMwza3XjTNQ7JfO7ax4LYMj20LsnC/hVkzDNrdeNM1Dsl87trHgtgyPyoXZOF/CrJmGbW6 8aZqHZL53bWPBbBkflwuycL+FWTMM2t140zUOyXzu2seC2DI/Mhdk4X8KsmYZtbrxpmodkvndtY8 FsGRvoXZOF/CrJmGbW68aZqHZL53bWPBbBkf8IXZOF/CrJmGbW68aZqHZL53bWPBbBkf8YXZOF/C rJmGbW68aZqHZL53bWPBbBkfmwuycL+FWTMM2t140zUOyXzu2seCjo8LF1PuxMvW+7jG2eZSjrPn 1aHLx6P1Eb4yRN5IzVWHTY6d997ivx/oPb1+Pn1r2r4ZBU/entfw6s3zodDb5q2U27gEcuNFd0fg Fg+Fo8gP9oLqp5Ap7/a3Vzv82/+MkeOcAjnlWUjtT+z4z973I+zHX8jnybyepl90++WHtpNjreUS OoynBWHHzked+jQcHYfQiR53PfV9hYcdEjztF+HibDkIked01jwlhy0SPO53zPC2FjEjzvy8/lLD uYked+GblbD5cSPO/5+VBf6RI87+vk/UWF3Ejzt53zl7D/fe+Xhnvu5gs1LyFFs7S0XPdBbZy7pb /RcZna1x/b/Sjv01sIE37gyy+hHqXkOrfNgsvow6l5Dq3zYLLuodS8h1b5sFl/lDqXkOrfNgsv84 dS8h1b5sFl/pDqXkOrfNgsu7h1LyHVvmwWX0odS8h1b5sFl/rDqXkOrfNgsvpw6l5Dq3yPW2He7j wsTE/XiZvJNHynj4ABD/f4Vf5X2Vnu+L3SoM1P6fP7tB6itD7OsH7KMTf9JKc12lfDPzkYjbQxiP zo8VK/r8fwcDlfuYJd7e46w/6Vc7q29RYfyybTzaWJN+4M8synJdZ7Lbp85nrPZPZVoeJEytaL// a05ef7f/M1bn/zJS8+9DvNhDvbz/efvY97effj3se9vPwR72Pe3muj3se9vO/j3se9vPwx72Pe3n gR72Pe3ngx72Pe3n4o97Hvbz8ce9j3t54UO8n8Rr6vG6twFXx8/3r6rtn/G6vt3QeHCl71PD8fB6 veM5CnU9771bfS+lB0ud1OK9PA13RcrxkH/T13ndDAs/99RY/0tP5/uL767Lei/N0OR5Ca91vGdL 2/HwWp77qvXZbondczz+h+d/c9L/Jafe5v7nIWem7XpPPfF3nkcz4X3fr/e87y/I+6+tzGN+nr73 kcZV8hWvaQMv4X69jQ37sDwp42ET4jetfVi/rRN018ax3vQ6+qM/e/4GvnkLL32e9WFv8revHqw8 XV8hWeM/C+PNWP7Pjt5/m/2vvhb19LsLvn/P+qrv4Ph+5zPM4zTV9r5zG5n828+z6HqeF6zfOg+L 73oOs4v9HK/Z5rqes83jfqbHjNRsdL2tf7P7nr+W9z/J9PqNNxm6ez7D6Pq/7f4PR9bXdv6nfv8f Z/Z7fJ8z2nHfo5nsPD7O90uYsO3/Fvn2uX+b7j/ez+N/lvvL/j7/8HxPbchx/Q+xzX2O5/x/J3Ek zVybQ7Z3UVXTmUztt0WUu7vpeb9fie1JbfxcRVD03Q/qVa9lkLDX+knWpgZlSa3LyhxNUm8kZu/q qp1o/i7zUdn0eulH7jNy/9XI5Jt6tE0d398kUvYyWXr6an97FQLT2GQsIWm8sMi66HRonSz9bkLD FVp5a/NVX/DTbR7/sPNWGtut6sPKJFdCc7jalo4ehSzmQsMXCLT2UaxtaQ9XFQniUzUx9WNouObW x4ejtbq40Fxz+Xo/A6+XN1oufurXQ0tJo7bxJz9td6Ow9HwtLo9pOcz9KQXSXGjtc9bcPkKmSZ8b Br4vX7L6+TvZxO6TU9WhCfmkDrvj1ak99k76L49Wrrj4nMybX0zPzmjnKLzelnPezkuPzr4k58uc o1aY72c+7OY+c/XObp2k5Ob/OcNOUI74+c5ecl5CrPPzl1OS4/n3uZzW7GdS5EX7+WT/w5zdYmpp nw5zdpy/nMn2s6yU5/os27vrvuRJq1wvO9rVrawrbPJaEsd18xYTYihU3Rw4I5t+36rIslpd3sNX JvikRPHLmXjLKAeZyW3yl7D3cVDhn3sXND7ncSvt818/ebDm5N6uT+0Z2JLyE8t5y5nOFlM9u5zp JzPxLxexOwidTQTnNbOaZp4lB31051852P6sFOgpO/oUydzul+udamsM8g8my+xqCqnj3K7PEP/m QpVo8/PjP6UKT17yM/tvAhSp48nv5Yz/XClTyRft07fecLznhvE88nArcnM9DGfDMvAwsoPj4n/+ gEjWfKIiHMyQImGOEFwqvQwODbZyueJKACL5qFOLLAFbF41BSU4AYkgIcjbxkKIKWT2y1crrhFfi uzrnKSqItZsBRFX5kUbgY6vFLtlCjlb+OdVuXIwRPAACAMB3ADwbeZ5AIAw4zoIE42/X/Af5P1/r CBIjCQPsZAnoTxOPp4nvJIH5I6jEQPXo8dCmbJbCeXbncr5G65LNZnDYd5yWH5LkOR/28e1Mb6ZP 9Ld3cgt3JNmC+Y089pqz+Z/n07twaqzmvb3d3/1WpximFOQOTIo5sxZHHTEgZEkSSOpwVdvm/VWe 8IZ1yJdaWVY600J+w0h5ZPlAMUPVaa1Hsn+T3zYGzNtAQ/U0zcB+xv2JcFrGpamjixZHW6xS6OTt 63f4+iGqx9FvsPJKuRokxl0vMpcl7T88zS3WUTnkMpDr0Ms9lUMp7n0MvW+9AvU0HtP71ncN3MqN V3iX4KjdeclzijL1fDS/IUZe006X6CjL2KBLolGXtf6JfuqMvZxHqtYpfaf1N2DZl7TYouZsi6FQ XU2xdjcF3KsvCV/hJeVLScQcMXotxxJcS9m19VWLouHxSLwq70pfC+Ku+qcWX9V9+tAyydu219bc kQpii/GMIYkC/nWGAM6YElhlDvu0cYeGQ55JgjUmDPRMIemq6NTCn+VX1+vVMMpLqv4Fh4hGc1ap xqmxbPEbI44qTDn0nHlWcgOFk8iWtGILeckXYiS5HJnEnKEOcqcgYlksRyx0ZFGROnM8Y1kpS5lT qDxTqSeVerUxx66r16kgfCfoKhV2j/Kp17FFH6TilXxqnYHIli9Nj/x+0amUXaboVt/fSKmqW7rT YI2K39v9xchablcPItrysHENudGE9m0X7LPjtmOrsmO6Sl3sd4lLsm9KlNvASl2He289C63vC8dd 31+XwmB3T+pLhczurZHyqp4rdLPjyXztbj+CaJP4ppWw/mlcIwMsye21f6rmD51t3Jw3uql0Uvhg BKjVu9G0xpIe7v9+XILB5ZpELoGSW72bTA+8qZtEojsCWO1O3JglVx/ptNC07895din7Gk408U0x +880849E9Ioj1z5/jVP7opEMS++j4ioPoLai8ovxgzmjFnRmVOuO0P1mjP3mrP6mvPhPqLh76pxK jwjCQM8dwTZ5pcOO/p4+HufWfFsvetTi3ON/Zrf9NTXNPZNee4UpsDYmyKg2xuCrLTTKnDqXQYLx C3b40vxDmHOUOaOeI46MjzqR6ZMkTrTPEqS53ZNFv060zykn7m2pR556J+NS+0j/Iy1WCgrD3gUg eS/WYXWYIRFouH3b/xX4Dq6tl1sWW5ELuN5VbemJM/UfsNXtVTTLd9RHvn2Gx2rSoVONRzBjS31K 5K2ccEZ3K4ubW2fP7mzLWsxfUckdXtn97LGP+wC3mCgKrIvUubu79JbfxudCg/tcXcJ7CHMI7lXC o4To3u077sHbLoUWWHZWUNof7AsV/eur13u3F3K0e63DfgsJglebXzNTXT/6bkwpJEaOE71vVPam bOtL9FxsNA2N2j9+ylIr6kxYaCXs1cFeTBKzapNWtqdW0KzapNbHohXWfToRux3q7JfARHxq3SCd VNUpNUpNk2nm0quH/lsbfbUrDq9rtUvW69deYRrw26gleamqazd8akqpIEUOE75LT2pqojjIRX1I YSEJji379NaX9Sug1UErOCE2Ou1TqWhWaapSbJBOi4we9XXDspb+rdNp1U1Sk1Sk2Uqea60CtzMO nxzqpeLZvoeynYrpX9JEqo6P8XXWgx7UdZLddL1BG9STcgRGPaR6wfU/fmtL1VaOSW2lyayiNc3S Ipb+gyX35MUpG5NXBCK73vds/28bk21vkN4taOgXNy9wA/Rt2lcqix3M2n6H9zvTtmFchbH9ibe0 tJ1g+3VX63+gIxE4aAksnnZ7iOyf0jMfp/3736J6ln33winNaX2n9bYrYfi7TLPzFdGQ/m/nCl/n vs4yvnP4crqYR3wUXgr9v+FCT79Qm4DqeFMeg/KTHorK/ljPwM+2NRTxv+GRXX+a2dQuzNlMREB/ S6zfVa1s4LPvBRU/Ws/MAFctiONecdh+P5DkcRwD3PG+F8BtgcBLZdv2l7K5O6BbZslRx+UEtU47 V+MsNrjRcH2seAk65W+QV4sh2ypvmgR3/4rgda+Wpqn2vKnVr2eMpvfO3uHaf1+vdn61osfYMo8f wAPwD30ka1vb/0PLcoG084aADYJY9qFqrHRFqgEWUq5VwuRwOBwfiPd8F7f+3k6vb/0Q5hsDd3fL YF/XY5f+iIISA7z6w/Q4H7+jtfYZ5WA++4R3xsBAM225u6Dht1urQJ9k6zEWV49+UYhkrzc7DRiz fHXPfK2RXgf9/VF8HA7/aWo5Ou31y26cmBx/9QmK/M1KDm2o14zliZziomrj8QxKgleS+15eZudh qCxHLXMmOafv01caNXQbqCVnBCbIpOjrugVNiuQJpzrcr9TVgeoUb1lVdXcKzcjh2rKgV1bY7Vk1 q1UI1m4/YrfbH9wOvv7WGLm5nrtYP5TBNYZa7KtZ9mq2XFqXS9yp8NM/K2OvLVdy0mcE/qR/67AE HB0EAAEQBpUeO0Ydn1PRR9hSHwjDFSiqwX39xDet3wapxODVjkGnJiVi0RolSCMiJVzRJDhO9hMK qeZhFY+z4Puj69LwHqtTQKMmZ4jTxsG/1Gvpo9YtbJIt33sHd317Xao2y2svIq2lY0trS5LPbq0g 2n8rU3Jf0X3CPHSweM427s4RmqWpIY4cxC3cThLu1pz6OiW24tsq0yzRl7P6Gi+GdZf72K38sttz R3h4CLojyD97E1HoFC0uyL/hlT11Lue0t322l4abFoxSMxJjYhqdKtvENMk06xpemSphFEcSi2LX ma41/q3eHW/ua28Ujjji0XxDs0SxnFowZqR0RB7hfTkTk2kKjFnQI+pHWEmiqRnTr0fWiZO+RVo/ eeohlJvzWnntGVB9lkfxqYpG1K2vyNwblEMi6LmC7tL+0vxDronAMXjTBNsCjEHVw6RlU9xLTmGn GIxxkEV9ikk0ccEZnFxfYYZ/eB2rbPPH9WvdI0TZqvEaeUJXpI6LGJiiRiOhTFGj22jVfM024lWh dDbdEJji2mBErkkcu3T/i/O5eP6nedWDxjZqnq3crEJjrUdc0sa96n8BajlIBRklloD9NEtK71L4 Czi3m9J8JWelV3LCt8Rf1twhx4xJoF2uzLTL+0qcV6Byiw/mrykVS7snLLfxa2/nYklX/AWZ5w+4 J20uHEHAUxbYCurY/4GHhoGYLa3/vNparFk+3Fx/8bIT/kylfo5x/VLK7C5u434d1yHwfi8VWEwS vJSpXcWLKraLor6mNordIaROhN/U1k6gibqVbptXR4TMvjYBWNdBrOW/dcxbbo14bdN0n5mqpcRd FfUxilZa7DXRW2V8NXQkIlMnGLITjVbqBW+y7T2E768O6yBn9ZXZ0n5sXzPLxcXHb3/w096PxK2b GprFc+vPsadWdod4eQUB7RsysLpGqmAUijpDKmbO3O+P3HKdEqeYt300eyfCWhklWHvDbANuPOdI 8khfDNZVcf2JpG0wTrbWLf6xp8LTYtNu04eOVIZpiToy2dGqZpGIO3PAR0rTr0TyPWR8JBLvVm1g 9W04hthEbFEUdCiQOtO0NEeKeeW/pFT2EfAj6C2rvucWjkjFkQuP/ftN5/klv8827cxiwfiNPOae ufAfQQS5EuqIcr5+9ijB4B/fZymlWH3/2Kpi0N7Odsj9PxY7KY/M5TpXzHFRoLr978KzIKBeQ62V auEW2Y2apFKRq3/Cds7Z9+I3Qs/MT11uffRyCcO+7B2Jcd78D4XN99HGm6vvo483d/79u3l/+Z9v T/3+De3/v5m+P/zCrp/77RhX/v8iGf++8mAf+/xXb/4Aur/BJ/vWcBZZ9+I9VfCUs2zYHqrXV2Vd RsrQa7/dYek74zvbKjvPWevSIYa+e6TV/Cl/nu1ZBOJtxBQKj3JTDjcZ6Vdcndvw2uxZ+Yr3KnrL xXvWfR4Z+SBD2lycVlRcoL5OA5vzZ+Yr4jXuHdg9fY+QPiP8bi2MbBf4STE2vb4aV5cXVxeXf4XS DVk+I3YjzV7UVZrCeFdndlOaVXEmcr5jU1/mM+jy00i22iADY/cQMoK+w2a2RlR4FdHZhbFaNWI1 VuBO1EaNMVHgK/chNGrCd8/7CiZ5nSP84ux0sE+zlMjP8O+zo6iBnWez8z/4McjGsf66Sw+EwrKp M9/O4Pq1zEXmx/R9G6mYgnz/XdPBPs7Gxw++fCZWN6eCVt83m4JWnz/h/is+GZY7kspBu69/9wG9 sDo9ZcHDiZffCT259/bXcKtrwjeRuTuOW69RJksezx1becaTzTY+N9ro2lM0qRzNKlzUhSIuNbuL aRzR6SZLEyThPFCUZTFSOfAWSiFHhUTd0dxzR6iTHGSuDuZROInihKMpipHOjaIhR4RZHDhenzJt pZpMk4TxQlGUxUjn9jZEKPCl/evUyUfDu3q38m0liZJwnjY9CuW/sEQnY3V25/ahEKPCLI4ekmSx Mk4TxQlGUxUjnwUIhR4RZHD0kyWJknCeKEmLxvA6ZtUtHM22RCjwiyOHpIfXcncs0dZT7k5xbs82 oSjKYiv4bt3PhLJaTFT9rjczdncWpHIelR8Cwf+Lm7z38m3hDShI3wVh/TVKls5nGzaFKjRoW77P 9ro7ekm0liZJwnihKMpipNB1dwd3P9zRDwiyOHpJksTJOE8UJRlMVI50i0qJXk7g7eNqiW3gefWo PWP/9Llq3ZlpOaRoihKMpipHPhoW2FHhFkcPSTJYmScJ4cep929G2iNA28M8QbQo8Isjh6SZLEyT hPFCUZTFSOfFVNP5l0dwq3dsuy2LRHNHpJkx8X3BzLScaTxQlGTfFbt6lo50q0raFHhFkcPSTNCu gsy2nGk8UJRlMVI58ZZKIUeC/jhrHNnrSTJjyGzScaTxQlGXXxLq7qUOZ1o0hR4RZHD0kyWJknCe KEoymKk13krsyu55C+O2bRZHD0kyWJknCeKEoymKkc6ZaVEKPCLI4ekmSxMk4TxqFzDRrdpmlSOf IWSjNLDvG0W0jh6SZLEyThPFCUZN3Jc+tHWluzu5+Sho8Isjh6SZLEyThPFCUZTFSOfKQiS6JaVt FtI4ekmSxMk4TxQlGUHP3R3Uoc6ds0hR4RZHGv7C6u5NpLImScJ4oSjNQu3WpaOf3rJbQo8Isjh6 SZLEyThPFCUZTFSOZ5CIUeEWQk6uzraTaSxMk4TxQlGaddyypaOfLbNoZeDR42m7curqHraTJYce yu51pPNKEoyQ6pZLRzqENIUeEWRxUc7cHcm0lkTJOE8UJRlMVI58xoiFHhFkcPSTJYmSojro7nml CijISgWlaOfNbNoUpaW5u4tpHIX8d0dLkd4HUexw7uZXDnGzq9253Qrdo0UxUlB+6uH23h3V3C/w WlaRv7V4erdetJMliQXhl067tk8t/QtqMpipHOpWlRCjwcape8AoUj1tJoliZJwnihKMpipHPnKm uvjccdqufW0W2084kmL0vE1Es0mScJ4oSjKYqRzPtEQo8Isjh6SZLEyThPFCUZTFSOfPQiFHhFkc PSTJYmScJ4oSjMZ9jbzzVCIUeEWRw9JMliZNPb7k7nm1CijKYqRz6DZEKSXpVycW2jmj0kyWNP1b cmF4pZ5tQtqMpipHPotkQo8Isjh6SZLEyThPFCUZTFSOf4qjjpLm7hVuvERZEdDXVvWkm0liZJwn ihKMpipHNAtKiFHhFkcPSTHWyXga213R3N3PFC0qOLubumRUoc/yaIhR4RZHEwuzyTbSzSZNQutR xsa4uhW/o21MYPxbs7c0KyUQo8IsjiSeooREyThPFCTdzuTumaVLBHapsvErh4X0lkrbFkcPSTJY mScJB1dHdC2o0UxUjnVrSoxa1K81bRpHD0kyWJknClorm7oVu0aF/H5NS0c+m1NVxzZo8aRZHD0l V2SyzSZaThPGHw92d0aKZFSOfUbIhR4RZHD0kyWJknCeKE085XL0zapaOfVWSiFHhFkcPSTJYmSc J4oSjKYqRzrEIhR4RZHEV8i6JyS13WNm04TxQlGUxb2Ub/NUkONuDt15VauEXkaxf82jabwN0r/D CYSduLug/hWrhvQtNs1ELeHbrlLu711I1O480oIklbbeSfuD7Pd0VqvL7bewl0Xv9NJw7ug5Je+I 08I7kvQ3fzfq/b7Tbq39B+aDXv7iSYWNkILdegWY12crZyH7h1qW5uJZJIe4s5BXlnrNJn1ndStu n7GEVMnvC5L9n3Nulk0Gqrk9BbULMRqyncLfyWVbkR/jeD0uSuLuYbV061nSKk35td3K3Ze9eLKY u1qlBkd3+DXIZhecbN8Nu3kliyFsSapklRK9IkqNLuz0KzTRZv7XkVxesJuVSaZbuw0q5Jw9bfYt pKTWurksr4dd3o1ixXiV1clBE3kK38VK8O3Fg3EhWj1vv/dHlFmHWghHcUs9m+3akR1q1i5NyV/a uXOsW//Sqa7zq4uK6mtX1/iXd3p1tjWTAyVOvXvmt8rr4r+EI712XbjrxlrTrq0+n6r7X0qxmuk1 zJ2SwfcLmJMtyEWY9z+P3F4dZTT/w+16Va1vq6E0KzXVtsQuRKXxVqHIVwdW2dYVehquZJVdHJtc 6xC5goMcqUC4uV8euPjbzXP0qyNwYdbZBc4ZHz25IRkG7m100lcouXFprimujvX8U3KDOjj2rk70 /E7t5Dti2dms54Kp7jbTra7WdcTiz1aJp7beX2jZsmmMXSWl8StfN3StvllzTsGmH4lcsWqUC39K 5rTuuzf6PVmF2gXNSV7paJ466tFztqOnt+611h0WcWlXIO4XKciuoGMXNTFLbEeN90ekZQxcs13m 1r+UXMuLWmTflqmLXH1DJSu1SgXWT2Wm2NKsXQrh4Bc60CzOkW2V1NwSLI1sLeH2k11SxkR+eDdx SzSbRg1jZJcwRS5o03frpDKLsAuedcsXULGuuI3mcJ7S6u2lUpfKXXb57UjW1Rmvt+vhX+k11P+t 3+IWq4pbZVcxdPnt3efWeza7FYjQQj611x265+rqjprbwvS6WfmAAAAAArkHf8n00VL8nE/64r17 ttNH1Ha8dRzriFirj+ra5LK6yCxVz5D6HCufgACv6tk/+p37hOfgAAAAAAAAAAAAAAAAK9+37yYh zY3YRUrLi+8hoX5CmLQ/8siOX/lnDHkI/8s2ser7JpWCgH5qN+82nvRXq8O7G/scOysfemHkIz0w 5rliV7U+2ysQNj9urGaSHqV5jgaJbPy/1G1s/MV7jYuwNLDjMSfUOE5+AAAAAAAAAr4Te/+pF4X2 A7tBtLwz0HpFOGdl0UsnAJ3A5b4xL/0ZzXt+9h2MPcmvkbFyNe2fmAAAACvlM/E3h3y3EXLftAVO fgAAr3XfO21qwUhjODfk5WufWT/+ocOM643wA4a5+AAAAAAAAAAr5HV5u8O9UtsD21l1C39A0r4+ g0t16LhHYy5HFn5gAAAAAAAAAArmFA+7hVJhsXSYpw/90xLUo6oLPnb3eN8/AAV/stD/yTjXWuw5 54wT76sfNjh0F8uln3wsany0h4Nn3wzyz8wAAAAAAAAAAAAAAAAAAAAV+rYvjjXhHxxl//R5/K2f eiVWz8wAAAFfK0ti8YuVlY+hwlh61e8E+OYZv6Lw7/IdonD7f8i8O41n5Icxv0q9JUK9Ln9wr0l5 +o0yvSxVUr0nsq9LlPrV6SrV6WYq1ekhvsNSr0uL3KvSUqvy//B0lVLPzAAAFfks/Znid7YucKeW ffW2DXPwV+Zfx/FcJ8LA+bEP5OXEq5/HdzEz7/+FSgtfBvj1Sz76Q6/lmDWCsmPrmBBsfyw3cNCW ffMTFfmnrDuiLcTOKmnZDd77ONpQvuYZEp/7PSMn7Z+yNLPzABXmxF/d1Gpv/Bsqu95m65LNZDDZ nrHq+130cN8/BXI8NnMey3vVYbM4/rHtn3noVa5+Ncv33H3LdY/7PfNt8/Bvlq+VYas/ZA5b5+f+ uwBCeZGIABSAf+uwBPGZA4ABEAK5Zmcw4Vzt9se5Gz9d+2ufjXNmW9k83l3DXPwa56+3HuPQzchy /7QiWz8wFfN8Bt64Tn4K5NT8ZfndUttth1RwnDg4LhXEu//3OHqbHe/C362ECR7A4h97OyQ01tjO KI4F1QLqByYN3/tshsFZG/gZ2QXADyvj+CmvYfhDnCRn3qrBb8/hN8j7HmPy2wJrqC3/8Nr8WGvz u3OODciF6+dcfa4BXYf1v7uS8W9Pq0QOVA6rG89irh21RePKebeq+eoqan6PlwWr+f5tpUVFP8+1 p/9u22vy7Xl/Nqfm2W1226/g4ba7XZ/zhtvs9n1vIcnbNztttt/orX1VVt/p3TT/N8vzWvTRey+W 1/Lsab5Nl8+7euI+n6tvWi/31GyqK0/1bb6a53a/JT7fb1zexqdrtNvUbS0/Pt/pW583x/Rtaj5v n2m8D2+4+nZ7j5/n23rX+um+bZ13P0fTtv7334q7/Z1Hx1saim3Vtlm1tNps64Da1Oyyvbbf564H bbzCuV21czu0rpK2VPu4+fcfN9o3R9xG892dr2VSsr8n1bwL5lqdbxLbbLeJ7sa4uo3n+02Xx03x /Ha6feUfRu63Z11G2+7FY4+jeO7xTqNF86Su8+funtP91/ybyxZ3ddclsq6P5Fpd51tPlXK9+XaV rdwst7q2v11G4rv6laZs61NaP5a4rB/0+f7Nvs7/8+z8zlfkrUbXYfD8f1fVU/RXP7oWibHYbt1q fbq3jG87rk/i2+23TtFyv/uA+H4KfXONm5r/faG4titN7UN7O6P3ayosKpz9Nh08r9vROEgt+B/g y6rIJven1cdq4uFSrirPvz9VnCo+EqPwBa4Su3b5VX5XQcAHfCYfuuLPzFfw7PvQVIn8Wqf2Fc7m CgrV9G6rU427iD28G+DWj7GlrW+tf2fabQuFaIBYZg1fFza6x9Aq3G/5A9+tVVyNcfaLRVWiBkaf Qu7+vsbm3f8luytHT4+KuDWFYf20OGJ+rdVVsYj1f8gKT6395f/atwyIWbNaa0uGJ++uwR/a6pUX iHVV9dqtH1MP/uX2KL8JXTvlM13u4snIHba92f1cN9T6Xhcfbq6i1VwFuZAWp8uXx9p3n9rqmSXh vsq+GYEYbP12ussSdPlsMYtZtDiqfhd1V2326qgmTUtUFAU6Yr9a25u6rqN5vWMRh+RaLCa/s/MA V/OZs/ayxP2u3BOFd/WWQ+axzZMtesvTC80/wVlzJ+5f4OPox+OFm7X/FmxWV+yxAD2B8v3+5guB LYYPm7rf5LYAVqcVkFXrRiK/itzBcAmvt8B74vbFE1jfDWP5jFn38fyz8wFez3VxnnFLFaqrq+v0 ux0OWq+Zq1TR7LNVd7hP9+K2TU1mH6/dpMVesz2wq9jnsbV7a07jIixncbqrQs6LHIrcWnBsA1bP 8t7pU0C3jjW29wk0HKW/QuNVg43W0DjVsHO20SpjcPlti4rd2yrzWswdpoLzoKuS1FA1NfadbsWp h+4w+kq43WayNm9fzNppdjdaCtbp6t3jZvlMZV2zZaqK17h37lp1FXKuMU4xmorZ57cOLTVsZrFt 1sRzLjQ/7pLV6ittSrUxn88sJn4ZZ5abTiNE4dWndnvCPZxlXvWSS2w0bi9lWlrhtxvHnHs6nWbj Wcpja7bVY2K+2Xur3GfmN2+t3GvrgLZrq3iTX1eI2NXCLRYrVW+EXpz/vGG5vEdtqsX9p0azeYfd U3h8Hr2pvJPZq8HrrfJbK81x9XbK7GS1NXe9tV+5tmmW0u2cbC83ncWzWsUwst1vkix/ap5+l91G crZufYiH+C/wVZYai9Vm5gvtW5XCrK/BWVsmPYrLHhHtZYYT4z/Zb7KOIfYvzAwvXseQjP/Y/LbM W32K0+dhn6zeBdmxMYjLArnXeTLditOkdhLOFtho//b2XYdlKytH5P+9ez33XrN1KuJXsn/KBTs2 LdOewYWXPQRFi1c5fYvF/2CgpVY+R0RrrJz4vpkvL+XwtTvXYZe1nzn1/ISV3stXCL/qSOwzje5M Fq+sF10RY8WGL1L/jy0rAmdrkEq/1Z87CBMV9McZ/1/JXFdl7HGrgblnqn/qywMe3Yjy/t7P+kzf T5/CneDCcGiPwI53db/GX/27K/4Wvm/+3whHH3+UBOJLsekq7/72k3u+nz+FO8GE4NEfgRzu63+M d6+yv+Fr5d6//imueAo4btfRQ7SuqWNjZVx+QsqPyLysJJTDhP0YT7zus/tB+H5hB7FOJje9T7d9 N4rGx8E48Nx+Qs6f8jOY3SOE/R6j9zhXZxkHOOFd9IM+FVymvxXpuvifcod9a9B8X5GcWvy1+j8V 6/7Mr/4nFjn9L5Nl2+vPf5F4XHev/Izmv/Ij8/86efxMr/XuODT+op90dRuginH5SyVff2wR84dP /sIIIpXH4K9sLLzgzKWymz+Mkf791j3quQpfxptf8bP0doklHH6pT9ThPVSj7qifLivR1Y0f9c47 Vw33PXcIHnPOXH6t9AcH7qP/67yyy8b0f68NnnGgZylXr/6zPbv62szttw16r23/VIGa9HVjR/7b j8Em8JWz7biyGnCpH/t3+yy8b2BYLYWfFe//+kx9gXrM7bcNeqr8I9r0da93+OvbHCVs79h14SPr 7EbvsvG9gWC2N7yifP5Kyl+pxgfXai+UmMFEevctpcn+vvNRCM/rpx7+/bRTbw77qqc3MG4c/Zfn 3VVGodn+Ody/4a/IWkrMD73z4b2MNr7Y6pbHf/rH699Oq9m3WWYNgBuqiEsQntQbh9oVy+3zdVdp fP9yv+OvcZHQ3uQz7qsjvBv3H3SGH1XDMjIaui3O4cb8xiJD66IpbKHdLktZfff+7L6sCxbvaOLl Xd/cHVLRX8j+HpbBfdg8rQsCut+NX3DDqkte5q16Xj/tGg5WbW4ZM6fKyDde9C+9XMV5eb7M+8Aw 3fC8T5gBH03ulWm78bK4NLCQi0agRX/VZX0XkA/fAE9cFk4qOFbSe/frFK636FwIWlcfe5G6sZdW Egs/MAABXg/JzT78PSCUda6w8VAr8q5gub3sfDK4bwrN2rhTXhHyUdwyzRhPLLdckcMFewD371nI YZ+T71uhlaTGVVjN/Nfmcw6f13mGd8I8lySODfoMlgn7vb4R+ZyeDTEnAVfewasZ1RrZ18CPloC7 25orIInFalJtDFjSQCNNAM/tvT+Q6iAc9Bro+lAF1kAT+qs2B9HfYZvT2YCD3m72cBD8/N378dMr VfTAoWTgobg00sd+uBD3MBJ6Ra+caxcVXxBfTi1KzhCpYVc5x+cwkAjjecbxyDRkpiUMnjEotZFl sYdh334i3FLh20w1ZfmcxZOfsiToWjEHTcEUXsCZPhK+pvTYJWOowSt3I8c/dx3BDNlZkoCXLQJR nDsfwkyvWrkYFA3nRKxX0bk4FK9MXWAH+vm36HtYCS38cnB96dYR3EAnvbEs9s4ubi7wW63S3ayC 4txwVncZXhdwRiDvsqrHkwLeepAd91RlO/Gl7U+gzvVP6iVmVTHDyO/yVgfGdmqPGnXnLsQdkk6N TRtNMuqb9JcPyG3+ieNY29BG5aUKLfn1T0lOUNWSR6ZqT1DYjNd83uWSdkpDdoqSynJNOzRzKLGo 2O9b2fdv569yt2b7t/MHjo8/u4ExUf57t/KfgYN0MCVW170L+wOARya2vtD54DU5rQv7Cwy3/PDL DelbZxo3Uq07xoyx2caTzS3n8UUaOHPdR8qLgVKKtFxLZ3iS+rbCNMis7DouRiG35m1zaalYfGId MF0apIMKNMaZQZQXrW3cnMNNwsP+xEaXv9ipOqfoPOW76iPiPYR76PjM8sZ8qNiVTEzvUnyKaVYe FRTmtMKd8uX7UIiTCrm9xi3elaYFi60y7Rlb+65p2zS3LoPe/aaZovncxqmnCPLEnr96/o3XtNr3 qYvP7UlV3qYZN21d8mMssPce+TF18FucQ0arFrf4ESs0jDnGmxOVGTTilu5PvmfZI2ZdHatsOTKJ 1EUQ02k1CGV6dKigGTrpEf0OZgKP+Uc0xf3wn4fm1X8bTnDQI26OgYMXcFua2xzS9tsO06FGJOmR 0iHp2COlR2x+1kWjWrMaZEeVZ5507FicVPTRVJSPXPrM+f5Ks2Gifq37FWlblV1TZlB9w3f8Loa3 XFrGXQ1Sz2HaXU49bvMIuxz6JBF3JFH6EXg7NHeIvJ4KPQRxB6aPYRej3UbVHEm5RCTV+ZzNq8Sj jWnFESjnEXxiK0r6s9O2r7FNlOKyvP7m5llxcK21B1xfj3DtSGLZpPv5YmzvZre5en7UUEuztLrv hole4VH2S4h13KoytHlwBf9KT7V0ylCq/gUolWxTFGmvAFHj/lfxfK/K/lkd8sDE78r+wEn8r+wT sFusVe3RKGkOuPMGVyaxDLhfcQyrzaIZYRzsn9+W6tH2QYhlx3jUMtbzKPCOoF9XRcSSGXC9ii1L s+PARbTzCDPYLefGcOONmqZdS8GYMKfnWjfLo6oxhlDKEIu5r2COLXJ3oUecu9seUi1NKJGTXe/v voyptzrS4fMqSymAOsOXPpXQaym0Sd4sz0XzP7rMo0/OdwsPEo69HEo7on1zmPFR8K6Tf8EXtZPs otaNkwysP9jbcFybfUjAkKsTlUfK26FGy4Bn7VDuX9G0TRcjqg8zsn1ZtB7q4eHctyoUhi1VipHq cSdOPDGmLOpWLsIaGdvUdQ0yCMqZEzhkjszJn6zKHhkiag6s1hlhl9vWMStsu22pmC1OK5+SRxB1 pDkmcmXg6E45aj1qNM2l0OSaLQxAi0muLUf6LYVBw45gn5i3ovxxR0xhjHHNEgdISh1ZKn6DyDuT yT9p5R5Rpz1T95SGqNsegXByqeopab+qeqpDGtIVYfkFyDlWn9EYtH9TqT3DMnumgPeNGe+eOUp5 x/o9ctMEqfGpaisLcXO0KjpS9kKPB4YpaXjkpt+dGMMWZI6Mzh2BJLE7FGfRoETJLmlO3P4ncHtH /htSYbpEyxJaUndqYM7xKR3pommiRqjvzqG00j9B4B3g5XMnlotBrC1FKsWNR8SOmR9ha7DjB+cW 61Qz6ut5aJWGQyon5kJTjAKxk7UdkmJXRKWtGnRwx/MZUmmRbTckGXi1qluUwhbyMOHYZRcDsS4j paCER3q4dyRpi5npF0KUup9hdjmVi3dF64Z/WTKNry0wqOIRii9GgWH4lhlpezItOKRrm18RLI4t FQh0j9qL6ifGW4o0MrzdcCkhlMOX82aw+ARbrYqYFS9js6VcfxiIhpDo5owRnkYNGNRhEaJcPCo1 Rhj3CIM0241EyPDyjjirRh2IHbU49T+jTkEfKcicosPiEcNbVTklJBcOJRKnJl/acowRpyp0ZiTq zljsSKNIsXl0d+iLR/A5g/sLym0GsXH8002SObSm3OMSQbUxSkKfmITjFSMUw5+cxhi2SVHOmJbc 8jpznzOkaaFHQI7lcOOR4p0JQmMPfOiKo6M1DTpEXS3KnSqYUZdJGIjzXrj+nRuDGl7h1TqFHqGX yRUO/ut/Tbjv22PJCHf30+bboZWmtQlfAhKqkJVzt6TqlMGZRiRGVMcMvtzyEqVaJXe2+GVp5LRK 1qEqnQlWzh1YvyErEozJNrJzSMYuHm0atGcRl0Z1GfM8bBYfrkTTSUYZwTU/QpqWi8gNB6zT9J8h 2BabgqdipeRl9LxHZDvBQzNnJQRtwhigxa4efaSKO0RlkfqR3B2p2iw+gRpmnbI1xLm2O3Ydwap3 CMQf+GNO5OvO6NGTB4KP1sWWkyeyd2UC4/Qo+ZHeMlC4feskuEVO+UttxVNExcad+xZW7NDpYfwE Yk0ZJI/YiYP2kejwUadtNozyPCYuonGmhR+5FQjSIuuFVPDU8pt4jJC28Vt/RGlR0qPGZJGk6TZ4 58Vxf4uWiEf4gumiVh0JXPoSurQlSyJ48A8s1BqGKiPMPhPNNWs7/A2CNSObkqeclIn2SxHnlpwz /FXo7kZhHokufxSlx9A08JH8kcyuHQoyh6R3Bqz0GnpopBmMv0ISrhc0msU06xP5sWGlEO1h/WRF jMbeoQzGzOISplHrlQsXXI8dHsI9Uoz/R/Y3J7Jeboqf3UhIhU9pTDn+DDLD69HMH+TGIpEdKj20 Z5p7iNEMyC5xslaFoleQhK1MQrHptKZpr23wIqzYFM0+FH1nxDrjVT42Kl1SbFTkD5CKaU6MifKa A2TVLj9m00yPmRJLh7RHclQwOjalEVJsT5y13ZU2ykMfQRZtyQPpNaszuEbI+ot7xUqlMGfWdgsS rR4B9hqDcn9SsPlIKCVLbdxypgC0Ea8f5SM0hKilh7W06U4Y6wth2xbTRNoNHh3d/lRoUW8pThzV Lj7gj7EXFHEXhUhFPcWHuSORXDuaHHHKl0U6JF1Q6RdkYou51rS8Ili8n7DiDLNr0iYOJJ9pe0ah txSPZL4bY4s17Z0jZF9Lrh3+Xy03lUvyOJIY48v5zpgDDrEwKMih2iUOMMYsPDozRgjQmDO8aYRG paYVkpaYYqyIL3x6pxqnKDwxozMz16MOadZPHo1hyB7xyKUjEE2jkkXniFSJU405MxZyhlDlTszE nfnLMOIij+hy58ZFkFelTmFL4cyxURzRQI5tHSLh84jrDFHaH5jYLj4xH7mn50ecMzkeyjnTanPF t4lU59S08gqRqmBadAjliOOoOhM6Yw7k6InToz0zpD3zpT6zph2szHoxR05dr2qY1TLNOoRoTqTj Vh8cjUtJBHOox6PcQ9RlUZBHamRKtpkkOuRVMmpFHVEgZQlTKmkJE8Ft1aPPMsf3OsNkSZq1iZlG wM0WzEKmbYuozjIfFKmdRxZnh4Sh+c/QZE68lD9J+s7AxeIf7DvjNJVpmkdkjREsUB2ZSmfYoLE7 Ro45JU/Up7zbtUVRoC53xU7ZS/kuOmjNjCKaJWRQldwjuTmGndIx5MGmR+tGtJk66+P9jXu0aE2S w/eIusS/2OMOjvjGGiJUZsc6ZCV7KErylk6Nhxs5cqm4iX+x5eeTVLSjlC1FOuPtaJBcPhkZ8thb OLVLappUQaL+i3I1qLejEo4dHTFwJMuJUNIREJyipclMOXMxhdDNF1NEXYmFkXdHkF4NUi8oom3E IpUXpGxRxKLTyqpe1U6VOKUdoviMUcWcUsO6Rlml9YdaQppy/HuEMYhYl/RizAGTMCdkOzwTjDUE OewYI+UwZa76qYRS7mFOOMMc6RBlTjTtB4VfKv9BXwWmHZKG3HlIcgfSciQ2JVMQxURyRdoVUiVH hyZzxyjJKjlSSWJiUdqjlkThFMOo5cmFx8Wj/KOYRtjmWSRtzTTXnNsVUc4OuWVMUpzJ+YyJGluv yp0CmgXDjkO0dCjTIxiNadEbI6M5dcf0iMadKW+Kf7avXNo9p+sZpAREVDK0nWnUtI1GOR6qJBGa Rj0aMelAZA2C4/IogoZUySmxRk0Xpp1SMOaU54zZljQWhU7ZRe15K/uQzTc/gjhjWlj2/E1vnLpK 30Fe8Q0SJMWp9Kx31CFuXvOIvRoRZunHiosXhLdQOLl09+vlhqtJCIvlfzptjYZ+HtCkJd1Y4H3f FvAWa/KP9CWEyr9J72UfKjj4so+0HHHyrdth85bWGcq+0EXH4nWFs/MBXy8FwvxaTB+Nf3cQtrHX DfDxC9aHU5FudT3B1akmZwlTQEwd8do8vzvwG37keKeQetyC9705ZJI8yeX3ENYbooy8TqtC/utY o5jQv7tv311PALy93yQ2HcE214fgHizkEmdKyWTrUdLbqfFXjU33gKYKw8CLr/5mQDS1OVf4f+51 9fmvOXNw35DMNshO7/U1h/Irx7+74Hzb36wGfqf8ExF+M+13jjn/GHHR+M/qI98Z/h8zK3Urs0JX doSvAQ44Iz72fmM5iNx3Pc/zPNYvl+mcJz8Fcv+9webbVwzOCa2L0NuIL034Ox4R/4WWTFi4XbNY Sw8cuta3D04be7AMC6Xims4Hjz3CwESx3Zjk27gmFuAc5pq3Ks+fVdoVn09evEz6pV2pWeZVdrVn Z+Yrq9Fz35+e5/pOecK5tZ9lvjeuu13kb7wbI7MZvd3NrbpxriTtUXar3cnl31NGtdTwAH0mwVJC evrWia/y7VXBSqRukVIScVllMJflff1eqVIjSkr4qssdsIZX3yCr13iKyy6kb+9aTT31397e9/n8 K91YtrjhDKF9wj1xoNq+49Hv9q/zETi3UrToSvRQla1FtKh9weRx8W1ZwMVxVtJV1Cu5i+brqLyS uANPxJCcasHzCSN6IoItcNb/XY1qRTaC4XxnVkf491v7v0W2rGKmhu3+/ul78X2Fw2DPfbVKPqGL GqXH/pW/4a7PuHZ2K3covdcXZDJLCXdJnFx+AGSHlFw8+Yc4YyJh17xznEMkswjCXlUkFHFkZ3eH vzvqsHu3kOK/31F83WyHnVKhVX59xILGQUpHNzr7ZBcTb7TadBBPudMxKqMt9lZzbJWuXuFs7RzF 8Paua/Vae1Uvb/rm4dZfd/c3KuhjVVJKna8AJr5u8l3b92MVfTkiZ0z53Z4R5R/E1x7ylwPrLiW3 Qvvzq3G077m/Bn+Itytuk91WNDzZfdCrduNLw6tIrAK3QmrVjWZ8xXLWP7LlTSrDps9TrWsdzwye ZqvF4dJoeGd6X3qiz8xXvXKUVi8SmJss/Q1ex1fyuE9LZ+178T/nwDxHYnP//XYAkypg4AAiAP/X YAnGpgUAAkAFe0yN3vTuUW2XJonSfKIpCnKog7wqXpSHIkjCPJElCXJonSfKIpCnKog7yslEORJG EeSJKEuTROk+URSFOVRB8QhEORJGEeSJKEuTROk+URSFOVRB3pCIciSMI8kSUJcmidJ8oikKcqiD 4lCIciSMI8kSUJcmidJ8oikKcqiDvaEQ5EkYR5IkoS5NE6T5RFIU5VEHxSEQ5EkYR5IkoS5NE6T5 RFIU5VEHfEIhyJIwjyRJQlyaJ0nyiKQpyqIPi0IhyJIwjyRJQlyaJ0nyiKQpyqIN0hEORJGEeSJK EuTROk+URSFOVRB31CIciSMI8kSUJcmidJ8oikKcqiDhUIhyJIwjyRJQlyaJ0nyiKQpyqIO/IRDk SRhHkiShLk0TpPlEUhTlUQcMhEORJGEeSJKEuTROk+URSFOVRB39CIciSMI8kSUJcmidJ8oikKcq iDwCEQ5EkYR5IkoS5NE6T5RFIU5VEHgUIhyJIwjyRJQlyaJ0nyiKQpyqIN2h2IiSMI8kSUJcmidJ 8oikKcqiD4xCIciSMI8kSUJcmidJ8oikKcqiDh0IhyJIwjyRJQlyaJ0nyiKQpyqIPBIRDkSRhHki ShLk0TpPlEUhTlUQeDQiHIkjCPJElCXJonSfKIpCnKog8IhEORJGEeSJKEuTROk+URSFOVRB4VCI ciSMI8kSUJcmidJ8oikKcqiDwyEQ5EkYR5IkoS5NE6T5RFIU5VEHEIRDkSRhHkiShLk0TpPlEUhT lUQfGoRDkSRhHkiShLk0TpPlEUhTlUQbxCIciSMI8kSUJcmidJ8oikKcqiD45CIciSMI8kSUJcmi dJ8oikKcqiDw6EQ5EkYR5IkoS5NE6T5RFIU5VEHx6EQ5EkYR5IkoS5NE6T5RFIU5VEHyCEQ5EkYR 5IkoS5NE6T5RFIU5VEHyKEQ5EkYR5IkoS5NE6T5RFIU5VEHiEIhyJIwjyRJQlyaJ0nyiKQpyqIPk kIhyJIwjyRJQlyaJ0nyiKQpyqIOJQiHIkjCPJElCXJonSfKIpCnKog+TQiHIkjCPJElCXJonSfKI pCnKog+UQiHIkjCPJElCXJonSfKIpCnKog+VQiHIkjCPJElCXJonSfKIpCnKog8ShEORJGEeSJKE uTROk+URSFOVRB8shEORJGEeSJKEuTROk+URSFOVRBxSEQ5EkYR5IkoS5NE6T5RFIU5VEHy6EQ5E kYR5IkoS5NE6T5RFIU5VEHFoRDkSRhHkiShLk0TpPlEUhTlUQfMIRDkSRhHkiShLk0TpPlEUhTlU QfMoRDkSRhHkiShLk0TpPlEUhTlUQfNIRDkSRhHkiShLk0TpPlEUhTlUQfNoRDkSRhHkiShLk0Tp PlEUhTjqsv6pplPDVKj2OLd5/K4B3ivGXD/Mjxr87lZ5eqL/PdmvnLlkvR3f0EIOP5YB268uFrV+ Pu7mPDdO5D+jU6VYyK8TinfuUCTP/0WV51ucysxK6gilurOa1t7K2uNNDO5Xy0mKnUkMxLyiFnrp iTl1kLDyH6zmmKS7u3Hu3t3FePWzivJbmnlzVeYsytExVoWa4paTxr+znOavnN1dWlcPTX9rRfOU JDLi5DLbyt1JX1J3X2vTrWXWIWTOrMrQTC5cpZ5et82PFs5zXJX9+7ObWJlFyZFT18dusO/1jHUQ k0a5Tr1rrvgfCA2fmCv5sVDu8/iodngNud2fGcCrcwe24x9ucMOt1yc0WgxhaTKFqOvGbgJLo4Yd /UqWxTFltJIgzvlx7NwNm2lvNE0ZuFnorh3Bt/ghDZlyKwZuBt5+hIlYZF1OZLsdMOmKCL6yQIhT tC/MQohjxSIPSONKUeG2OOLZt1TDqXg481S1TkEYRcOKRyZy7JCiLPcRzCMg0X4INlWnNHdHNk6c 4OKpUjVHRnGHFh8609Qzx7p1xUEobkuK0buP0pP0NIZGGYkWSvcrhxy/0tlx+WXDuDTHI61pJNJM 7YzJ4RmjyzNnrDNyEpUbkqj7C17hUq1LsfWQxVGFPqMWbg6k+kmFpNujOtvoR2htjuz5zwipPLNq eqVB7xtCnK+q1lUPLvr7qZ8ZUr9l2h6/jenJLf14zEocv+gU213dMMq1uCLQ/+G8kXdkwwxdoAdv WssW5+p95Vx/+0xkh6u9v5iuY3eg8gq7UMs0zKXA8+SsmJ+hpIc1Du4H6C+sm72UASGbz7dVsslr 6Cd41cD0BSlaNVyFiK+Elv+8fXDLgfEauIVn46rtcBeMQeU1dfDZTTzmrtMgrKhr5TATtqqJVuVZ /3VdoVn8FekTPaKu2qzq1XbFZ8PxSsW6QcfjmXqAVdcU/rpDrdZNLxFjrKyL85Tz+fcJtZe9ZZji +LbkQtuLMoZ47Y788U1J658Q/Lveru5vsCxMLDvr5LbCv4dyVd1UYl+F4mL2q859b+/CGgC565ql sYrEvkbQ3jj4EfiYVMcuoymsYlxqjKmZ/i0x0yjK1XsCPy0B3NnYKMv47Vq/AaMtrpEMv808A76b S9HrQEvxIcWRjr9X3ByXabrlc+THZk3LNuy3tzuRWrv5Fka5Ymn7VY1bXWdVIRTT5xUpVHHCWLTu Vhq3/7IFh9dX/7Xt4Fqw6wCTxoJ/vw1S4Fa033wYWxr3sMMrDB/uWBfuwqrwpyqjMRcci4kkMxN1 mcfdBRtp4m0WP9EiLTiFYw9zNBgd938yYzz79BP+xFvTdMSL9/lMi++fWju1tbsVkXCtvcY59+iS GncJ+SotO9npMZ20Knevuf4lTzeBduec3Xc1IUeEWRw9JMliZJwnihKMpipHOKWSiFHhFkcPSTJY mScJ4oSjKYqRz+ZCIUeEWRw9JMliZJwnihKMpipHMYhEKPCLI4ekmSxMk4TxQlGUxUjn86EQo8Is jh6SZLEyThPFCUZTFSOcWhEKPCLI4ekmSxMk4TxQlGUxUjnnUIhR4RZHD0kyWJknCeKEoymKkc88 hEKPCLI4ekmSxMk4TxQlGUxUjnn0IhR4RZHD0kyWJknCeKEoymKkcxqEQo8Isjh6SZLEyThPFCUZ TFSOegQiFHhFkcPSTJYmScJ4oSjKYqRzHIRCjwiyOHpJksTJOE8UJRlMVI56FCIUeEWRw9JMliZJ wnihKMpipHOMQiFHhFkcPSTJYmScJ4oSjKYqRz0SEQo8Isjh6SZLEyThPFCUZTFSOejQiFHhFkcP STJYmScJ4oSjKYqRz0iEQo8Isjh6SZLEyThPFCUZTFSOelQiFHhFkcPSTJYmScJ4oSjKYqRz0yEQ o8Isjh6SZLEyThPFCUZTFSOY9CIUeEWRw9JMliZJwnihKMpipHPToRCjwiyOHpJksTJOE8UJRlMV I5xqEQo8Isjh6SZLEyThPFCUZTFSOeoQiFHhFkcPSTJYmScJ4oSjKYqRz1KEQo8Isjh6SZLEyThP FCUZTFSOcchEKPCLI4jcRbn2kzCc/Du18+CtAuHkeJwTOe0VmkDp1v7rz8O+0fmnd259o8Rt+tz7 Rt0S4vKMGrxeRUQvFzmF5DLOjPCkqyslIDaDNqkbJKy2S4fhKuUsjtlBvclJ47M5DH5fJuGPcvks 9msdkstkusyWXzT4Bk8rJ5nfQPVZL7e9zGYSVs2vrL5vLZbexmVzVbKTyuX6rH2AJu8tZQG+lvgZ cvc5wEed2tlAWEPK71beXr3+Z6vKyWOzWP6qviE+sjkshmN147MZXIuPugY+wuQcLPh1feVdc90W Lxb4ZJLO5rJxLrN5fq8vmM7l3WT6zNOr/kF5Z3aZisrPK7j//231u6a8SfWL+rhBTELi6Xud9Oel 3KsYL/xvg75q2N6vuU3ctZIbVQrb5LIY9BtuFX1nAESNbtiXe0OH9Dc2uoYyXW5iTzOSzVgAr6X1 j/LZLL2Id5qxlprTM1rJPexNfBsR8WAKwLyx1/5kNPqSzas7ADZIS3c5j96LmLJHV9bzAf7v/tX3 A5vrGvqwgZLL2Fb7yuYZW+XthW9dDz/Mfni+i5vHdHy+L/NzLt0uJ4ywr+2W7MGyDhMSwE9zeTdc rALrNZitDmHWJdRG77ORtisExcXzUdXmtb7OrN66dyeSwmTy2bzOU+1rnsPijhxviJEs/UNPVn/x 3WY/PY5f2jM9XK6dbuchkslvNsjXA3/LZFZC/94yD38qukzXJZ7d5nnTD/sHyt/l80u6OMzEwb8a +T88iX0W967d1mV/qGHeZyLId/zMHvhv30B9+og8vy7x+aWbyxv3j6BvH8rmrB4/BZHNyT51f2jq 8x2asSe376uVyTJziAjL4eXz/OydcDkq8Lkd7dHC/1Dn5wz/N7c2H1c9ZRuYzNgEh90OmQ677rJJ 0uBBvgOSy+RVnAm4sescqol1kK+a8fX3PtNaeSzUmtyDcOt8ZkM3J7xSuy4FO9vzx+ZXJOVfm0xx afUpZaSJIPfE1NPu66rfQG+RNhAfyne9F2/497kMjksnYDuBHshSWczT4FYrd/uqTzEC3sBare45 n2kDcdk8vmV13XWZN9Q9MnLEOH8Sud+yOZzSvq+srjF9H+boWQV2H+TyECwr3OVuJLLY/IZLHZ59 DWXzDeLg5iSzWVzFc8s2+4oKys+L+W651TqzBmzWD1CMX6Sp4mrJFTBGyXD8hGaH00rrOH5u7Css CF0UDBfH0lcX/MvqmxLrO4/7nWT378PyrPtIh4yq5/BRWDddVmHzxJmXtdLkbCYxAtPeFyD8PhMS +cfWK70Y9YGx2+F1Yx9XQ+2Uzjljne3RqSwmJYDzOVlMlX3C79JN5CwBmq+qzfrrLEhfXZpnSXpW VnM69c4rbeDrTY/4Vwe8sP36PDPLNaRQuTMjkt4x1S7TvrMxnMk4sIa6H3NyTIWTrrMhlswkgP2L ZTVk6wH1gP8nkcflMlj7EUrwFgW01ry+3sOvUzXgbA+l4Dr7f1m9PEuwPwl158wIT8v6+w85l7Yr o6gAHxYsUP7ull5mOusYJ+mWIAy8PrC0LCmYsRyADyGYkuux2Yze+CdVXMZ1l4+5PdlYwzKjqxp6 r6n6/mPl1fG+Bd5dkbKCyFbrLb4AZao4/7HSz5jV7DSbve65j1od3UfCl0y9impakVtR185S/UuH shbtLtxYkI012wfiwilKsbN1DRbZDaLd+VZVYeY+BuRravz5YJpLWx/qFNI2fag3i1Yw+m3z9Jkn M3JWNDakx6NsVu0utf6+kJaN96EzL21jRcSOoJW7PcSOb0rF4cf8X4dOt9ZpooGoJmF6pyS3Xc1I UeEWRw9JMliZJwnihKMpipHPWrJRCjwiyOHpJksTJOE8UJRlMVI5k0IhR4RZHD0kyWJknCeKEoym Kkc5lCIUeEWRw9JMliZJwnihKMpipHOaQiFHhFkcPSTJYmScJ4oSjKYqRzm0IhR4RZHD0kyWJknC eKEoymKkc5xUzV8wTvPKSQzbi6C+YJ9txGbbufvmCfbb12jB+hwbq+KWfmK/elcE7peywTtwro2/ M7u9SttKWzNKkQpIFjGaBcO+I07b3G1szapybbBrdlWnRtpFE227NtrDZNHecVMapoDUjDXYNLrn Wp4DBFq3XNNeUpsSoNwOOy32PZdk5vOv3egVeNUZd06qBDy51zVysAP2qK+839NqVjwUJWkurh9+ RzHJu1sGrHuWg/halbtjj1YxG+faVmZa6JjP3I2Kt+RuSt2fhFYiFebb8epNKx/XD/df7y2/Mbku HHql8UwpiTnjqTLnYHcn7TyT0T+p7x8xuS4cgslGFMSc8dSZc7A7k/aeSeif1PePmNyXDkUIwoy5 CbXSOslmprVNKt/qEak0xoxlyOnaaSVwVnbTss/MAAABXlwmGd1F93Xg/5YV3jFLLHY71MKziqJL +2D3d/1bnPrhuTXesrDj7xj30q1+YWU65bc+d0TRpTUQDXhLNTRNyo6/CV08tuub7IlewW/lUkx2 JQJTSIY7+lua5SII0iivNPk9Zck4Ixkm7dcfUaKtfBqblb+b8DCJtrxlL3nBA/jq6ERoVbkqi1qS xeIDKWWawwHbIEXA8REje6TDJqXBEVvfEPlR3KYSrul3l/x4FBPJIRcfwxC2Qh1LqxbFIdW+o/eq RH/mEZxc3kG98IpIduqL9YA+Sl3WAeSpb1OYTNiWI0CYzi9CL29iUrFygbvufrVI5Wd0Uje13syX xGIr/tOT04qNQkm2UFuWGfSpzqmlgLVfWf7JLj4ghldnlFLwfN62FdysBNti5/2KaOPBVMYpSrsL N3Nbq20BvHN86nsmWWM0DbSFAe4bguqxsQjFmUM/c1kcEYysti8ZeMTGHGtY3s8JwYqwpjlyVkza 9rFnQWMnuFdRlG9WnDXyFKoFdVlIZ1OGvmBO0yfez1u9lrVMnplIE0ulKiba6lqU0Le+ggJbrANK WXb6jKeeGm+lsVHbSnZZVXwuAJWtU7TNPteW1m4gTbX07CJ2dztGpQJmnFKp1fsR6/3iWETq1inu q3tUmxOtKrprQXQuu64pSVKAcXZcNEqUA4u6Ect67UuqG9chrn7/K65/MTMLdZXY5Qys3NIZSTr0 MqV7NFrNAMo7ySGVadyiNO+MUaMZcT+5HSniwEGmREGnGq8xDLprxDBxxGsfzFn9c/ux/i2Zct9R GgP6EweyaI9smymGXVPkRpyoNTZNXHgLM77Fafmfd3XllNCUBUDr3lyBEkaQ1ZsSVWK699ZRpljQ mpKUtlKqeAuPw63ca0063/poz6NMj3kfSiEo1TjFPZWDi23QNMmShtmky08Vp6B/g2Raf7KnEKYc 6A6s0Bef9LUqMsaRtom1Ce202xw/sqmAU5Y6U601axncNPBaeUfyP6nwH1f/6EjRoCAcIAGMjB4X BbXEEzQyDCEGEwXyTBIJBOtUWHQgdITrJMIz8gRZDFOCSBEYJx3AkMIvhCCQxXsYkMV8wB6EIJ0h wsMactFsHBsuNua51KK04gNqLWYttWuD6vey33gJQAAgZQAGtp0vz/Aefx59oILBRE/SIDUqoeqX iE4DHbci4ohyodCGsCcDYh/MPgClC5DJfORMiHOB+oOyDwQ9IP+w3oPgxn0EWfISwfnDrg74P4g5 DcBYBI0RFxJDmA/KGsDvQ/iH+Q+kLMMXuCLPEJYP0B2Ad+HoB7gb0OAGO3JFxhDmw6MOyDwg9QPe B6MRGO/GHBZvjiQ+kimBb9QU8EKAHYY+jImZDOC780UaHDYo0KdkUcFPgKWQSlIRTJDswcA6B8Hh iLytKJw0PkxqK86aT4h/hKUwfALerKZymIvwEOoDzA+ALYXd6aMacThx2YTwboMjuiLjyH3w/UHZ hJPBhQ4ZCvPh7pxuwmjScKewFWGPqBgwo1BuFADsJSpIpUhXiSaivixoL8Yp8BxZAyqiLoCDYPMD bAuqyLkCH5wbh/QNsElWEWjIagPBD4AsgY1pFxgneE2rGFxxjF3bmpqQPBzPANS8WbQV21sIcoZg ip4TjKOInsaanCxJ5izdgyP2VkS+5wcj0ifLmq4iZ4oSZpPyZuHUkQkBbnnZwZhCmIkNmAmRwYRn PHCU4gX3jCpzkxBymDmX0VxxnCJqO0yBzmc2MCZoU4cOMycFeCK4+vOWmNNQFIDYPED1g98C5teW d+5XvLKjpnjynN/j0xPJyLvbcH6ZB5v906mmx+5SieNzHLRm5bvbqZsnr3qjLBo9n2rNs5YT47qd ItuPwOmzZqvcNF6n7k5U/KQc1Bn7Efu21p964cT5407ky4Mth2t8/8hnfmVGSq8e/MpvA6gzK9j3 PZNv19y/+HO0Gm/Z2XOOZn1I+02nNeR0dvJyNpx/sLLbov4896eTpZGQ/TsrnGTnVd11h245tQMp MrPec9+7ygJ7nWuncH7mP9irIyD92hw/wpiY/+zR0/Q/p+b7xdJ+Vz0ZjPYuFVrImWnL+0qWxqHi FJ5+NrlVzjXvB4HRE22a+wMubSTVKueQzgIiqfmVOb9v6tgskz/D/Gn+HQvzP+DFZ/1Bm37blrI3 qP1eO55j2eaWGbXkrp6H0HQ0/m00tVkLtnLq+/rsZwnVeJ2ncXfMVdn+y+d7f9fBVw9HOrs6Luoi GjDu/gS77upyX9JouflM/2RQz3PHKEDjUmHGwgSPiN7iGySvl42Go58qY0+SFQ2ZAf+QXrenplq0 9tYfB7CeX9yfnrLRRmhRvlSnP4cQa8G4Wfd3Fwp93lE9+5f5WkNz/tM0yxUICWa7uxUJWPd8A2Ni iYw1HKKJMQvqFDf8E3Z9bx60zDVd/1aP8NrDHyd38Cey4ynHMV5/HD48eJmN4ow7JkxZjeQNMwRO GAO8pxx/0y+OMqIM/bKFNjxaeHJEsORMBJOF/HH9RMZf9I8sW5/th/LE+7ygACf6ul6bU9RqGHVd cf4+BOZ/HzvG6Fh18N4/DxIK1u3rCpD3C66vp+i6PWdFqL3Op1XR629Bret6PqtZ012NR0TUfH6p 2PRdJN6npOnu8ZN9hen67W3c6rWmNet1MFmPtg300CQzrTlqewP8gB6h/9lD69L1es1uoE9rs9T0 cAZNqYP/2PkQ9emQH3S3wd7frYH+oTYoBUDWPHyB2Pv4fRa3px95/3Ray+M7GE990V98ZqOm1iDK EnxBNGdJd7q753pBNvX6kxHyAO3RHg+x6nq+u1hnXdUPkAF9DoU2DIkcokvyZg+7udhCT3xLLkNR dfHk8dOZManpupvRdQwZcbyXGjcL1mxzeezn5NT1t8ZAr0TCGdGDFH20rPMM4Z9m/ZCX/LQsW39N Dg26ns/I0KHLM2grqw2oKOgs2wtzPJuuuIcWEm4Ipk41pTzAdBm3GDnM5stCf9g9fInimBFLnrry L9BGuIpsjFCmtKynZlZT9pRsU74ozCdAS8Z5pQoZ6BQoZ/Uoemf4KF1e+ijG22Nwz3IL6kF1qC3F npMX6ZVJI405i9TkysozK1CJMbIlJnZE9ycEn2OyRiw8OP3SN4o8TIodCw6lkPZSdB1SsnEcTDUa Um5AmNvkSUnP2HIrZRxKONGTD7RBPErRaIlLnkyY+8ZidRdXo9wrIvIJi21nHMZDW3XkyGfDRBpg 04asNeGwDYhsw2gbUNyFSFsEh1wkFM+GiDTBpw1Ya8NgGxDZhtA2obkKkLYJDryhTPhog0wacNWG vDYBsQ2YbQNqG5CpC2CQ7AoUz4aINMGnDVhrw2AbENmG0DahuQqQtgkNcUKZ8NEGmDThqw14bANi GzDaBtQ3IVIWwSHYlCmfDRBpg04asNeGwDYhsw2gbUNyFSFsEhryhTPhog0wacNWGvDYBsQ2YbQN qG5CpC2CQ7IoUz4aINMGnDVhrw2AbENmG0DahuQqQtgkOzKFM+GiDTBpw1Ya8NgGxDZhtA2obkKk LYJDtChTPhog0wacNWGvDYBsQ2YbQNqG5CpC2CQ/WUKZ8NEGmDThqw14bANiGzDaBtQ3IVIWwSHa lCmfDRBpg04asNeGwDYhsw2gbUNyFSFsEg2KFM+GiDTBpw1Ya8NgGxDZhtA2obkKkLYJDtihTPho g0wacNWGvDYBsQ2YbQNqG5CpC2CQ7coUz4aINMA+1mGfd5QAAABP+dUrVrCC0kRhKxpPTHE+VcT/ afqPQ/jTms1PSdd1uphvA6PcdxvGpf1Jv1bXU9VrNZ1CbbqdT1PG9J9l8c2VZRZys1+FUh3kps+C /1os5/0OF+CQiqnP+dIxvcc3g/Go0lmMzu+RYut1yMEU3di3oiS1GjmXUyzXsneOpNZnTPsdXbW5 /j+HqPKoer815l/UZEqsHsfjxaVuMf2chwqpyFu+kn9x297Cfn3DlmPJ3Z+ka1dFy/Q+/h68nr7a MVDnlOThnhdU9emD/DuDluybIsXTBBZu0Ip9mk2vVz5NmC91eG6cXYaN3rUQ31BXf48z83m/mMiN OjQz2UvGjywvtdGOefVyh0NZfmJLKlkLnLZ+Yg7KNkNL9o+HVUforNrBFP/qGCnT2ZMzktryWBRF PLK9wZ9hq4s+5+cOFU/RCXY4FEn2sy3bTLJs26yps6+zsbGw4RaUzyko6Sm3qynqKWkrbOop66rp 3lZWVdTYV1TVXg3l3aq0F6al4Si6115NRUPKe7FS8e1jz4BO8tV01JV1FTU09LWVJVS0dU8gJcLF r7+Yq73FNT+1mqjf3g0e/u14bTs9JbmOZl6PRxRVoZbzKf2bOusLWyQ0adchfYVeMV1mQqvHJEGB S1j1PQryLs4r0k06Yh4eCdJU/vzSWiuonNLKn/nUJnmKj5v6+f6O73kIaA3XYk298i5H3x/vI+yZ 9jKlj5ocOFXaoTf18/699bL+zC+y0/IS7iuioZ3wRPOVYhKqOfrqP1g/KSHCqZ/F+PoGHE6xhMdB 0Ezx2h41lJyEshiGPjOg7FrqdEj/9uZQcPX7jur6TWNeMSvhvCF/g4RqtbN3qeJ1F4cnhn+gYau8 nybF6OxmUAt3DeePoncO3OVgNusriM5IDU9fe7SWYuc3evn8xCJOc7dtrlxbjs5y2DmkiJHN/rIj GQNM+STvjxQWeOTYgzI0ryXEarPvriU/0eQbyxiUESz6+z6xbPRGp7yhMSmGRPejSIjCe6zR8a5a WQebkSbYdpnlIUKN6/RsWFaVRo9ZvIoRhGsCzxXa4PDhb1nhBl2ZDgqHdh+Y5OdPCTh6ameZ53nJ Y++nqgHpPw6Tn+bBaTbn1AFEXzP4CLoCQl7i4cjZJx8luf5xMcp/X+WIOCLVpvvn+f/EmXywuTkd ul2fT/jmefvtOdRSql9bVDwaAAsLSYglFqPtaOd/F0F/fpEQ0YdAg0gJcLQN3TFwM9L+IuUvG7gQ Zu5WftL6TmuhTiyOOiX5qFG1imQr9FM7ElQlrvO9lmLjpEZNNtQiuwFvMjs6/VhdOa0U770SG02R O9Ucl/TFxM9KLcTR7qTfRkCH4++ImfVgw6o4alxP9OcGjnVm+iSIfE3IjO0FI7M1OO0LhxrjU2/W Q6wV2uDmWOGGOPAOT39gi/2kTP9pcNZwin+4E6HYzCFSYvj4SJ/wSJkc/CLhf+8Yc70TLvjfRjBn Osj4QpnikTfYi8DsvBr4gkTpEwFdkaGG8q8h1YN/IInXjiZGkyE/4wwIUdiduChmCKx4kfQDtwRO f4g2NGYGeYUcB5IFC80eQ2b0UzZi+eqKU/mIk+O3oDAfnigTwGidbJn8WkQ7P08WWYkct4stBc2x BOdKSIfmKKXpNLLz2/0aWCDPn66YRTqXNlhKmojHtLDkcZ6cuxod0dI9FeJ6Msg894Ijm55di2Wc wxn/780xd+zdbPg8uclcJvQ+bgaxn/joVFQABIDQyVxEgGIf7cZKK3GhmovZuukRJthXc9HdbUgw B20lWOE71OQnxSOmETVQhbPpxMdKRNB2YAZgqmcjneV9AYCmeFzBG0Iv0EbUi1ZG3jc72oOCLYE2 kM74ZG7XZ2fBhen9grn7x/gLsaqMrckVeR4Qrxt6fw3V7Vv85SPdBtsg/yT8pvY1/YqszGPnmOt8 VaSdJbv1ffwRBduCrf9Mez2PC9SZ9sK71+vroHtZjX+Ps1aqOHiWWkfYSb+0fyGLqX8dfdP7evf4 uuVduYde8a04L+9/YyVtc28k+Ew/wPw0vRhK51RJ+LelWah/zOV0+mIPvbl74KvWyOD5QCn75AUq LI6BQ/4EbGXrJsw7q+MKIKO7dbarVr99dS3qSq35Fq9amltaT7Nk9Kn9fwhziPtlsZMqcg8PlsVu Mr8Uhx0DGJ+/QeWvf9HyGy99IdytDK0Jn20roebhZXCn+eX/0q5WE2+B/yHvnryvuv+U22gH0u1Q 3cRcvvP/h49/7sr8bIq+TjTwO3z5/ruM6mXd8/zCNxS89Q994313XO72D/HP3S9XYr7V9lxmj3ed 3D4UWgjD37Ui2sjq3LPsYrrY3F21lXsbOT3Sp8eh6PviJKtfyCyv/YZw8rxq1bAqs7a4XP0ZPFqu slUe/tNfEi50Z24x/b6szE02aFzHRVU5CzkLJ+rtLiN4ECONsMtu8pYRsdYXj2yrHnu3YYji+d3S 5W5ssvWY2svm7KRva5isseEZHfZKsW5qruVVXGwGcjUWMlkk5KmHeAVU8aqF/6uXv4dXYGYdBR90 /2GPYEXV3+GNPeq/RursXHAIlz+17Yxq2atXrp69ZD6Ox2cGN17Axe7dGYnU5ekTWGbodxHq9G63 CF1lJlFiyXuWSIRkwdNWiDgjdfdg7X3xV0vRK5ji9+5etL46+GEeu0LsNOnbgoJdZC98YeI6ukWL M93bvcS9zCol8zasz06NT0fGH/xyyGIyg0H+sG98jF9Mj8wvgryz0Mvb6t06hcCccXz0+vYJoLOm e/iyPJ03GfMPoUbM3b1khBo6Qu905u4ycYH67XtuyF0dtjF/CkLv1MuG7Ru1es5lKLq3XilkUuDe BV62axbFVrb/qG7heUVXHRAq8wV9O/WqvOQhtk5Si9CyQavUPVgvXz8PJheXMGYxOY4z30fh/mlL tueh9fssGR8TqZdzLVG83t4jRe2GWHLCfRjdvXTdueLZiPnTCZvWu5922ew6kJxcUbXtD0sNmyN6 FXQpfOjPtBTkXvOz0G5GxeRQ7Ps5kxlMtGbp20FAZtWrZyfAojIRwzXmPV69pdHCGrhy2ZLxlrmX 613Wbn7ES+cvRmDgdXXAodQFnDob38uEJhEY6zZqlRbNmzds7wi+GrN63mXAj509ZQ0945ZX3h5r X67tuhDywcoUFCPT48QpW3DszhhU+vZmjYab08uTLYwUrQGmbI+i7cMnAzCT5nD6oBLKZb38Dt2y dtT4aXoUTTsT7mWGEzHYzcXtjsMz6LZKV+PAGRVRo9Pj7DfxS9cfHbw/TryzSut9cn+5HD8zgq7k ++Kizhm+8tkuN1CbotXyV6f3Bg8ay4gWIe5Sw+lvGcFZcHsUXy5W3A6RpXdNQrK7yY26lfBHV+EL x4N30MByNQWHY/1tzwr9YZH8MJS5VIaqHipG96qHtl2nqoen/yOMwUpB902oP+eunbH+kGIt696K XI9ppfYlzSDrHEjqKqqkHrw0XSGM7yOAqR5GUvS3KsUspdPV1SF/ek/bhjBErn2hcrgVz4bVpwso GoksjqRdYflPPX7CtG+QSgxBIt07veW8YJt26f2qqt2VqUnuMQc7zOCjMEfB4Osj7wh+gPH6h6qA 2uVSWol2/QiHcrDT7Q/0N9u2JkZGWp+lD+GP5A9FZBDqHKHR2xyu2Mjo9wuUQCw/Mg3uX6o8smLv sVAGKzco6VHaE+yYe/ZOJ8fE9QivH0uiqOxBBcTSmjQNowmaK0tW1tKZYVYRNs4K9s85wEbx8oat +iEWlRmGTvGFKfK0kIlO+wWmGTvXAhX8xCj2g6urcdhcU0vdN3ECXdyZF1Z3CHOJHh+lwtB8gYM/ tzNAPkBxoHpn2spfiN6LzPpMLZ4kwz6YoDtCcZBBvIQdar2MPXjIWmWzRI+4rVgYdpxWAD4pDwFS RyG5jD1LMCLWQtPf6IXw2wmWBmGCmEGDpODDLEz7WVJ/++9JMxL/cxHMXX4veGG/Dmir60QkZcM/ VbeyODCSNFF+Z7Y4i5+Rbwxz/S3dDpqemb0w3yZkhhLvFSrhOvVWbwTXrrNjvBYKqPwDnHo+RDo3 jxUUBxA0ua15WvXtk9rHlRZ2FM8sHtTW1HCKqo9MpR9JT1lXUVNGVWVhU01VS03h/mqLKrrq6srK 971f7bWusa+7NXVVUzTVN7Ecw5XZWFJZ1nx5T2ddXeIZz9nXbXLWN6q6amqeVwqq6mnpSrpt1RfH T5/bbbIU9PAXqdFs6mp/V2/5N1PwOP07rbOjT99fSWDypvi6t5GUdjS1FPdk1V0DOzsb5ewsbGw/ HRbqrevIGV2qzVBtqLO09908F672XzPd8Jpaqje0tL7ucva116yrpqvQezfWbK50tjU0tbU2l7ew sK3cGP3tfAMEiyfWlbaXpaq1vxnlraV9df+2NrZ2d5liLrehHfKqKz2eN6nt/0948stb1/6ne2+f 1iKZsnuxsOjr7Sx/rzVlZ2WhMoff3EzLkOisq+tqoBdzW2G67v/p7J/2/AYydGd91tlQy/8/wH7v O99Czr/arbXlNo94XYX1tbXCtaDWXb2FHWX9lJX+J0Vn/Xl6Orrd1A7rIDHS3uuBf8VL2stLSzvA 4FlwLO8R69qKV7XX81NVPa2vq6myvevrD0zNNY172ngd0d4VhGVt8heQN3ltX0rJDck5j/M+3ckK zuGTd0G9gFwOLW6YC9jYPrF6J+WV/1YfNm7S5v/Xt1PhwILdXAPq/O52t+Oi3Upz9ZwLSsFC9Bpb 19S8eWFZURj3FWy5HTbvy6Hv2nmFWXe1d8lZvH185YlVbZQEBR3YU94V7KyGRQsb+mvrxl933N7+ wgZDNZVVVbAL39NeZfg1NYJdsbrr6d6eveqvZX4176+TsL6C7Asq+1elLCpsBmfbX+P37C0tK2tf cDy/J87l97t6+xrKmmpKqrvfU9HYQH4AV7uyqhQyauVn6y+3pae9pX1u9k6yxppOyqTVW1n9+OGZ 5eVdK8p72FnAw8Ka4z2aryZiv8vnat5Zf98X/TlKTQ/39gzJXm3ysDG85s1b9D+7obMZa9nY319X fXU18ZAPsn12Km+5gNVQz3FaM1Km1qOFQKKqoq5ucgeiwe14uEC2u8YeYar4E18LdynrHl6/kKCp eVtJfzVFPfz2N5+/kXsBCmo7/W9flvj39+TW/n/dYVlVU+F+btt1RUFbR0tJW1FfWSY8B8sbotau +xgM0Zq4VAsKr8C+Nq9/v6WtGLu94TAqu9S1ej9UY57S9fyN8bW0tjf2QNhpV6PVbqfvrBTr0/sd HTvHj69RVVdVX2B93zx/UXuxjb/NZXnWF5NRUQCr96ugP3aGnWgRVF+fl3dLAttLGstaWzo/hGWd ZZU/r8fVVVMtgWV9JfBDSfV9RACqazVftrKYT4gD0dPSaruL3G329Uz9PnzPIr79+pGX9VWYn3X1 w0d1h8w5Z1NTY1w5IY/113W1Hdfp39hAE1HcwFb01T+Dz6bH/PT1Nmz9GmKq+t73edrR1NdS1G/v znlPWc8ZnrSzeUlJARr7J4Le6L8asE2xj932EBmtGu81fF+bxHyupmksbCzqnsBBv+jf331Pypm6 Pq1PoHt66uzfxvLK1sXlWM17aDPO+cZzVbZWJljR3euimrbVY97wUXo6wYOb6iA9W1dWO1+BWCef 4lbOmvQ01HWfh6XkK7J/PyX9r5SppNZ2tvX3ptnkPgM6CFWnYbhTvpH5HtQwJTrkPS3swSpP/iR8 jQEcifz1edM/kPkTj/lzsMXUGnA4QuHUEdXHbD5VWXWnqCqCNE+lgfLodARa20LjPPARs1Ehv/1c 84TMjB3xmPHc15L+vLmQleuZgdTtmHeuV/5IhLGPq4NvPjUq9oOWDGmDJD/HVhT2zNHjjKz24PkV x7fK3pcb/Iu3X7AzTesN5/eQ+CF5Fooe5T3uwfImxLggoUPCsT3jOTwZHakB75nIwgXzcYYQF77Q 8X5Z+qGp0Echef4z73Ev1hAz72Cm5SIZIXHxDh7RFCXJFmd8k7R3ucgkPkbpn+P0iNbcXqxKjLDM Ip4U7HemHBfRnkgOY3UZVWuXwc9oWD/g+6j3F7ZTHWgj1Di/idwWkOHYrud2Zmk3fe5m6UPgeTCo FYTW2jYZtRofY/A7e4h7itSNmdvI2aSHn6M2Z/F9ES28MMyMVfcTDonA+rD+kuKeomiGtRtjd3jF BN6j0ATAfSO9qHrcF/B6VcWJFJmP0acKKfc7bQ/HCaSgp0tBs64+1hXadTc1Dc+l5jsrSGSVklcH ssIyNVaBWf/p8tQag3fqLQ8Jlo5QBMbkNw/ylMe2SnPn8QLuVZvFWeWTNBt0wWd3KxC6P0QeH23k jZEiRx++Gpao3EOb8uzQh2jTPZ+vdS5LezDiC3lj2Yx332sqW9fEOdZ7LYjgqWgwJhAOWMwMNpdU 9aGVvEuztNL7MsZCd8NeUt7PDKSiosrkR54wp68mjXJd9JczDTfRcVcq1P3B7SB4jBkXE/9RX2hN IojCBb9beJb7AiZw6ZYOJDQJEzoL9s+n79lRGP7D63X7OIUSH+A64VS5nsGYKpFzVQay7dmXHKYv Ajm8NU/hvgPuwWaJYovr3XCMaKHEY0R/XFENcUfaisSPRjiOCoOG13CAbEzAw2nhuxij/aIu1FiN 5J9eq+rQJC1emYrehnCVYcKgwdQYPsLE+y1faE0iiMPrnsW59gxM4dMsHEhoEiZ0F+2h7KsHefDp s8Qz54iRMJJ4FziyLwY8UDRvGrqqNl7sM+F2xHMkUZHEHBFJkbQiYEbUi0BG2IuTI0lagqXc0LfU lN9W4DqkD+e3lSHIf0HBnkzYyrFlYIdV6youjhozYsOjZxXqolwkRKEq3JdtyQvJV6S7bYImOrEt zgF5WVkW4+Lyty3bJH6YvDcqiQ9NumLIeGLSwztCXLXBZctS3K86qssTL4lyxJEodVpZluP4iTDc tyXbTBZ2FuvYhMLlwS7YK4UzheDol25iJuFy7Jds8Fo4W7XRCYXL0l1L7Qc0va2M7kSdyccGVN+n 1yPk5Bjy5fwF3InG9yT6nRI5bZp3fxyaNh2mQgjfjdFd/izUdqXQst8oqoehiveKjpNjOUYsx2Xg XOGpmEdcvliV62Dss1QnY7Ojbq+H8o1ZfBwqNxBjxWanJBuqJIyl5Zi6/Rd+dPnGjurrUfJ+Imcc kGw7TIFy9zPLsXv6uUPy+05pITSm3UvtP/C5bLCJmOy8C/SMmV0b99cO+h7Hxs0euzjY3Vg0vH1h W1Iu4I15F2yDuVfvI5+OjfLByRf1I3BF7xHM3v6crMKrdA7OUnHnDs1ZkraEXIEbI5cyVsyLniN6 ctQVrzlrCtrd/uitsReURtyL+aAe8/2y7GrbkbCBPToGBeEBZUvkCDgizR67s1ccVz5y0ZW5ItMR zJq05W0IupIzCLuCN0VeCXa7/nSA2MeGK/cVRvqCL7wV80NjScKe2LfUFHSsi7ohtyjUpSB1gWQe OC2RIteQy4fsDkQ/5D88mRbAh2YdaeTrIC+pNNMLvrCnMUV3+wKfpKdqU7AGwd4HbB5Id6H8w74P eD9odjQ3t+rKbo07cpYB0oY36bx9cUjJI1aop4PqlXcFMeU7s+CzTWgyCbDmg6Y98KdcekymrD+A diHnh3If4Dpz3fdwD+yNPpKdmUcDBfUFK807QpGi368p7YfrDIh1IcWHVBpAMwRUylVilIWg9k+t GhJajQRuQwmvzsUia9JfnCDqNvdtI2EQdlxGcpgDLsj6yR0/wEhlHEua8lfvkhuS7rohM0xYekux T3njpcL4uJhcX0xT3rh3S/UkSjFCYvkyKfkjcLT9zwWbaQut3H4FM86F3FX9RIzsUlwrayZLjEuk rdku8UXSVs8US5xJdPDMMzMRQxUNEozxhU5Xkw2UWTGC87QwNqeX8+To+AoteVrEn2WNLc/eTlcE u8wYSi0kNscS5yxKly9Ld4uJqssNMeS5y8RM1qUfiVPRnVKyst7QREuVmst7vzYXEmwyQv5A6FFd t8gXQ3JyzORJcy0RUaosNMkS5xhh1FpYdEu5clU02EoW5mC1VlhsS71J1Y8g54gimeIJj9mGbz6u ImckdC/JkudUSsiSGhLvURCcgWHJLv54pDMypE3yhcTC8no/SXSVzOVJc/QXSVuCXfzF0lZmWJc/ dFLlyfYGmYNxZYZFnfKK3DeD0l3vYpx+FcywJc7zBExrmS3O7Lyui3dgXlZZotzZqsDduFbcl30V RdBW7zZLnpEqbl1nC3PQLVWSHvEluecSDeBWYbdniQbwK2RLvnm1gyYbd/iSqcMZ50655RIU3bhW 1Nu+YdB3A5tjrvmlqXLcl3yzqly3J0fLVIoPzFSMwP4qkZFzypGgnoKkZ0z59NHi0eII75JE4mzg O8obzxMaNeMImXHExnFXD8E4ZIN1F6UVlQvSitFC9KKz0L0jdRelFaaF6UVrUL0orVoXpG6i9KK1 6F9SjsJtxPyzFavwe5MoSE8IrOArR8uKf0Yy7c0LdUj5cpNrvjVOpO/vkOs9G9e5LHwEN8UX4wmP hIVJo0xhcfEQ4P+SLwTSK3AcSwFQwnLgLWhw1++VL+cBxMcoxYGYXFmA4VOHCImyoXrdQT5YtU4X o9BjcHl5iFXTG/L+slnvccN6J+mFXYpv4y6jdIdrS6oF23PQ5xLDdac1XcxDulp6YXP7yVS+3cpR 8BCGtvW3z9YoGJ6e0EO+BLCD2sLNZz6F7BBRZucUQSwW/RhZ5Qh3EP7sGwKZ4Ef95o2jizlSH8iQ 1rIvu8VJKuQzBDFA7CvC8hH+JLKsw7KsVXgUzAYpU7KV5EWLz7k1YogaIMLwDjFER0Xpbk1V5A0Q YJ7rjDKaVThgzovDl08MNtIhz6Uk3BBOOh9DOvNm7iCfblE6lWVysNhirvzZsiV2RITU0yqJ3PZX AYZLclD5GTOW0rGKYZJo/ohsMibO5IttymlYqlEwfT8E1fnyeBI/l4cupw0IeMoPDlz8MyHZPOvZ 8OXhnmbn9FwcqE8OqhTsPih5FHpFVRUg+NS1RHM989oh/SmIlsRGng5OHBnxrPhwzCFeQovqR5T3 koQ4iA9ESPJJWmIStERKQdmQuAMR8vqalzVTpF+eWDwzq4ogfHzxT6hRs8sQPgudiBM8aa4PEJy7 EIqk4M+mWJTtp0k8tCjYe37sXMyIV4c7DYeEPE93Yw4M7zUCSApITm0Uzcp5KHBn0eY2TRecGmrL w8CVU7h+4GnPpFXwzBFfuSF6jMYZCWx5Viz8DlcKFZmkh6WITg8SHRWEqTp4nJM9f4hImMxCiW7J X1/EhSyYZiHc/9EObR8wZOhR8vnPyo/EydzRDNjt4eF9erUaliN/Gv/+tGYHabFGQij7qy3oubcP HJCwk5nxyLuSHikhPeyK2HkEX8SHrEiF/+mE2pRyHykhRp+o5Kb0KokRyje6YeSVWJDm9yh0xC5Q TMNH4SPilwnDLJhh8knPrlTSgRmCgx6zJKRnjKN0uIc8aQMO8vFi70P0Q9fSc8iWwqZimx05Xxpf ATc58QdFhEGdWkant5zD4ZP+1gZ+dakR3lESwzJp74wnyemk+UOIKMnH9zdHWEj0Scsy5hEm5dOs JDvEEWL/8F0dUolKMv83nzI7NgducCMaqAcHmmuJh7GLeKJuM+Jh6/VYoc3BBTOZwCzdxBOM8dQd Z0tMabNsSuYJNySvGkE25nFFpo1LwWswdNsUU2Ff5TuBonbGY8p0yk6Ylp2KkmUUw53JZsM9Dx0/ gWbQgbw2RQyIV6vj4Hep0nqyzHWjN54SgpQ/zIvM+LAzQ9uKEfKINvEWjW+LU9KVxRTUMiqrgRWt zcJCIV0/IF9fPg5Pv4pus7+FjdTKiRo9vCjUeiZ8QbdJ5qzY5IvpK5gRXo5tE4bn8ZCazeI96mp8 hGtQ7JX4cZiffJ1p70+iHfO2IUhPK3URE/cQbUqNnEljlLxjWddniHeURKf2SRRheWcUDKEgfVzn Dp/MQlc4iDLnfJCzC1rvIRmIYSdocdBnIebiryYdJyR+x0eEoquZIphsuorNRS+MRMsqWvIEhaSf MEGucJTnCWVKvznnecNpE01FZfArLzKYJ1Hko8ERTQzWeTLwaKlZY150GRCvT8tGaidWwr7cRnZ8 YhjWTeeLgOvM2KVV31GfwuIbXeDa83ZPR6FNLIU6d0ofO9cIpndKOdT8JIGYj5lYjs+OIeYFB96o hnqJA4O6ZEVwu0cEkwz5KTe/vj2fHnJyMMfDsy40imyDgKIF/HETDQA2EU0FdxyAhzhz94UZxYuf InAtzNCIoRjMQbNkIfNGmXEWe3+Y0+QBoLcZkQYi3Au7sWbs0MF9ttsJmeSYDsKYZLiDEoo8yUcV qBO6jlWLB5hceksBEodBiCw5Uk0KPiZPfJskZq+6UR59KQMuXGgh45f42WF2tSWSApFdzxtsOVw5 Nd59cIq1ZPQ6qsLMvVSiHO8ZhEaVYmdaTk75V9bIUq9iM0mA3WaTyofeoa+d8pGnqDY44yHk1x/l QrrJNxCL/vvoeokl5mSpWKVMM7G+za2EXTfOfVCemD74fgD8Ic6H1TXRRL42zEkywebjOzIntiTk aqvqZCmcEjv5aDO2fAb7jkWal3MN5U9wkVscnFpF002iEpbjPj3evQ7Ezjh3kvm6+WQoBkRZ5zy5 dDchoSlaIdCio0VdgRH70cyUkgjQ1QZkD6ItcU0IYbIvVJREXcfg8WL7UiYcDlWOE1eHmTvy0adN gorkrRBrqXEduQzzBvKWhh69PL8uXQsVO9UWFPQ8vA1KpASlWCdSNnoTaf18tRxA9DD76XueXLwZ eewLmXg6LGCq5ssa3CLXJ7wRi5cQoscqI6fj+oEM/vQ4w/kydfsUYIfyZXg7FHihf4GJWQ59GZn/ Ys9v5iPMpbspSAa6wpZAV2x7v5pqjiEkK+XKYhprzgi+S81F85s4/4Ar6Up2AFfclPEAr2ZSgAr9 wp84Fe/KVRYsTzHnS6E8mKFfK+dF0Il44nljyGDxY1uSJm/5Vjht1JldyROdxD3WnPeLCvgi8r5C Hmrq99hXZEWnSM2Py6XBxcZo2LNVoy60f9+L6mtvg5DbKETDGkp+TEhNxjtHhSYlrjce3yRfKWGu YgFu8yiYU0mdN58vePiAj0fPR4vFPAJ/UQdxiAoVufPl8BydJwpM8ng5CmXKEpyHJlp8pXuMRvnq vkRim/E3JxhNxrUfG+UPEpCB+955sQHrCEoogM8HbefC5GB8ImuRRZqY9wavXIw87faKHNySs4SZ nJEp4ZJsyV8ogYoU2Sd59OTGWjYuuOhTYai3ZsiS9FHzYlFfeJQp4HoI1Gj3122S0ievfX+fR0jF Ltnv4Et5I96dfn0RR7OdSKSBDtxDyBsYrWyyAh9TrnzhLtlrg7cqjkciA/HEosSZtjjFo9Cy2RSO Njz0hR7y9I0kSR/0QjUsy8ikeSJIUzFo6xF7VJGHP40jPIkPpdyzGPLHbpCj91L5jSQJG8SEy5DM 5LSE2K+BkSKTR0ir36STNftZFF944hzaQhrqTYx5D6MiiHNdaUkyxcBlCEh6KMFlfKHCXQ+8Z6KJ mc+++dGNmMIcb8hcKxk65D0Ua8hry6Qiopmkg5XoCB6ajCn3iRGkOVJEcQliQtIffBCxcKTKSMK4 1OfrlSSPkjp7VGyTN25VHnc03Oy9E2TPRlR7yzgimB6M9I6Tsgpn6xxRM6YctD2FegUE2hwelNGJ 0fGvRKCbkD2/3zpmcuihDEplP0KHNwQN4dYWbsgpvifalE+gE5glO8LOXJXxiQbwn2sX3GmqgOl7 UhpzCMc3vMYXWiX4Jz5D5NdByuFlIm7cTiUV+n6UPdeHx89b0kefb71TyCf0nY7s+WEpM1ergH2X Mkkekv8FJLRRdAit3574iMSTK92kik3w1rfTQ6B0YoejyKJy1IN/ohJM+dxXEFMFUnduKUT5/Swv dIdwisaYoX40iIJlRB9mSfDsScTD9u9Ff3jTDb6Hyvp4G/My1dLIGndRCIXVEwSUJPDZqk4a7sv3 cNizBY6YlI970JbAXwidBDcmvnJ9Hm81HYLJhKbuShabYmIicTIEO/XQop/lIbobJLIxAdoQei+s kWuqIS4wSULXWEJ0OIJXYEHQZMlfAPRZRPiYx6iyZBr9s4jlkvUNmzh69k+LmZEK/uIObiOV57hS VosRyJ8YjFrMtNuaYLf2JoxhzKNfSyEofuJb1Sm+ZJjHz8ufk134FYjwUKzISm/k6PDkSSikzDzF Z6kPUqx6iIadAh8nLP1MQVUhSXsREMj58lhnzUPvM6+fLPmi4Xiuea/cKHNhLIk/6JRM7+flyeLr ZaNjlTMRqieZiPTNiQm3ULg1FdjKaSDydarDKSRWGRNeM1+ek80zC9LlalL8PkZ3fkwI/Y5mFyfh rUoGEqPquUXM8PyI4lkZya6WRsfPgSjmpU683C5wlsX6hx3P4HcUpPR0iFNac3F5PLVJS3Z3CO60 qK+bX7jD6Ev3/1wO5zzUganjA8EbxDs5dROyXh6nfcf1UX3kQizykl6w3FPf3x8/9KSK33C2STNM 6M0hKeJ/YbrHhiojuzRaor9mG8usoBQkpyzFnj7rZYsHseDlUDX0eaYsxXaFDDtMltBulDTiw0QF fNnHQGjQG+kvbzOlE0OG/MnJgQccwRRHy1VlqwzC1Z/9sx+21k0fVUisrVpLxhMLFqTtdCbBWCbl GBGLOh6FbdPCVsaEcC4JAJHoV0Euxya8EArTYLAWhGBGkhYblVoMUsVxp/pHhHBjNBG3yKrttHHQ Uq3hnh8af6YtICgO1yRsx6a6pNgmh2PWFyXMeEeEfHFzBMR7QqVftfc0ksqSXQQzk04vEYe1kz/S STi8yKbCSPDZRMvKjcqwWAtCOBcEkEmm/6M6HLXTirqxYLwxgY0McGPBgGbQi8+H0MCToVyzUjtq Ohv87qGUzoLzMwegDKegArZIqQmW7TtI7mpBNgfAr8UqtWHjnLIs1WgzhEf6LIMhldnr8r/nJqkP WBLluJF+sZGRxuFiSypJdWCYdaWFyCWe35OA1kILHIkiQWKibrATirXdgZZS6sgEpoNSLmlHSSVQ mKsm6wFoRgRpMyEIuyCpXCZLAWhGBBmfceTOQDIqjt4M4zkkwcZJpsMUTCtKLFapJeCSxaY7g0n0 aTMhBi+YpMfsV0K3PXVxqJrpGjJJqm2TXTkZHsc+JeQlvIekGorJvNM/V8FgZBYqgVgsBaEI142E bCqEyVgsBaEYCg1Y4sl0JFKiyhHaoFS0siyVRpZFkqBWohdLJWCsFYKwVgrJOPNlIBIhJBJhigxY LwxgY0McGPDIBkQyQSgcQGTDKBlQyxN1ioklEy7Ci/LAWAsBYC2EbsYdOEdxsILGkmsNlCe+jQjS QrSqrZiKyVCiQSMNxGglS+Li4jwkAkQkkjdVJLqwWAm92MLEaEcC4I8JAJEEzkmWMUGLBeTCpWSE n2qBUCoFQKgVArTrzMYbCQiwFiSLWqjYTi8rCwtCMBIhaC1J4WgtTMSJ0JQmtBaC0IxUWCx/47AE HBkEAAEQB/47AELBklAAFGB/47AE1hkFgAEQBGKkwCqCBWEytCMCNTL6CbKRYjSxGpt1hISMk622 nMsp7wzHJu8YSE5nWOLCUITmd05nhOZ5jsWkuvDGBjQxwZAMiGSCUJhckiR5cqyQkk48I8JBUWEh cgEgEgEiEkXKskJCMi5WkiFuhK02CwIIqMLmNCOBcEeEgEifYu5+w2pNBoDy4P9OZ720LCZPHZwe 5Rx7dGw2O70XbzUf+/O914FhxeoVcQmxWyZnQ3rR/vJpVDuDQ7SBISkrSA2x5MdDls5dXJhKn7xf xcsh6KlSKysmytFqsVJrqyQsBaEYEaEcTZJKdvyeMQtJfUrFqqCwVkysBaGQDIhkglAzwZ8NAHF3 6OSQsDVFP6VVq0VlkeMVlKK2bGoTXVJsFgLQkILlBBLIyCOIQkF1WklGk3joR2XfFBiwxgY0McGP DIBkYMBKoLFWCwIKIqBUCoFS4u8eEgEiEkEmGKCDBqqx5d4KaVElki7ygZMMoGVDLBlwzAcSGdDi gYhngz4aAOMDjQ44GQaEOPD7wcgHIhyQcmEr0K3jD6b8qQ9EfVWizSBK70PF3VzOqz90mFSoFgRg RwLhAiCMEGYrHZYC0IwI0I4DxUeUkAkQkgkwxQLwxgY0McGPDIBkQyQSgcQGTDKBlQywZcMwDAMy GaDNhnA4kM6HFAxDPAenvQFOLDjA40OOBkGhDjw+8HIByIckHJhKhygaIOVDRhywcuHMAzDmQ5oJ YJcNIGlDmwmA5wNMH3w/AH4Q50PxBMhzwc+RKlRBYAxYqBVHFBi5GDGkca1RBWCwBFRwRwxyjo40 KRwRwRwLDCh8kxEWAsMPAGIAUPRAOsK1oRiDZUg3R9UBpGKi7CzXCxXDH3XZo0GO0uWlIwPT7JGv uLE7cWVRowbpVu8erVwWI8aUjyJLfHEt77VYpJsYkuPFWMukyg3LUkU2EkEmGKSrdK1Rcp17lWA2 proO2vrNBdMmluXaxNdUmwVgi5LDFRsKwTDrSwlubxgGEwVLiRHhIBIhJBJhigxYLwxgY0McGPGB wyNP9I4MqGWCPBcGXDMAwDMhIBmgzYLQjAyIZIFQKwxYSgcQGTDKAsBeGMDOBxIZ0OKGOotVFawF oRgRoRwLgjwkAkQkhuX8ZdeZurks/3C7vNj98bAVVK4TJYEBjytDGLBuqaS+QDPAm7yhY4sFgZIB udrH3VlQyyN35ODf++9uuaIOvKIpTywXizZlJwKAHgh2QNTRwe3OJTviIwQcwUdGhgTfVFU6QbBP gy1Qu/olVEQYekUKNzSfFdoD00lRZtik8UoTTXAuCZNJ0HJw7NDGomDiUCYNeqKawifd4cDAU5sB ImxgQ0nxXaCi9ccTos3Y7POmOOnAo+FuZqxcyjcRU8cUJxKCDadSIvuhfYvJf1AmRo1FdiO1B2xT qxJi7rxMMR2ZgyOKLrxTfYEU0L41OJgURj0odoIoV27U0GJTMUnQDs57sYcF9Mpw4EY3680Hab7o 0PgwYbZHFAJRx1xE6FegCeGGm5w6Fm5OKI0ZijGhprjR9rRQQt14u9D1grikNRZzRSc6YoUcFJo9 GCgMBFTI7SoTYUQpNsK88KCnBFGHDg4d9UAmi44dFH3TlD4K8wRB2nQnwoBc3YMfNFco+NF4s2wx MnBQbMTJoaTB8BNxFakieCcmRhswGAi5Udp0XnP/vBsLyNJQUG7FdoMUT/7hJdyIwpRCHdegRNyD PwBgsdqLwSLXdeUFNLjSUFznRKMvBOPOInJxK/xF3KGecUKMgmAogmxDtik+DQprijcHoLijApOh QgxF4nj5N/uOD4+DCjH0xOC+3ozFrhnI8GWF/WiHHZufMoUlRGTgxEYCLcii2JpMCu3GiNrsDgYk eC7thnUnxhNkLyoQXDEpz34kxXelHwg6IW70o4NGZ8ahfTQXkzKTQg3Z8bOvIHz8GNbkYgZCJNCM dCmNhQk74QoIZEaC+Mu+OB21wN5WeZtp6UdPnrxe9mKCUlGcw8ZMaKUmnbZrKOJS8VnNXfeszU51 zihKmK9pQuZheylJxczetTU2ct6CaXL3Lxq0eOp2Vn6J5rqBlMwCHzqAk1dCyaXjvGFAJ3Qa6A1w mUc0FBKsZxk7eTkpMTzicbzlFeXRa51elbtr1EpK0DxkJtUNE1YPJiUZOJhlRXe4ReDKXws48FHc o0cyj5jKTzqagZPJ92vX3xco8oIBrWgmHd4kpOmSko4EcPHLuAG6XOL59c5mqFsydQIHTafob6th A7vSsWM3QNJ17OQAjJ544PPl45dN1719A9QU6vhppc+fT0+2naJkuv+56+4da54dwnzJV4TwcXpX MyymaByMKOnjKcGA9dNtHzkX6OZ+YOU9KNJgQco3vnnQwsuXDdpPO3mugdXpGFDfCtGTSUenxeJS fEIKOUPWbc3omi5rMGPB/i5Q4M6Kgnph0fC6xcvHzxu6OTu8cSKKZXys28v/nBko8nm5k4ZQzFBw pxeE5vyHlEilybmnXq23Iv8y7/zwOpHdBjLU/uTWxj4cgRSMfEWToeK4D9W/R+btaPLW4+j69Pkr hUh3XLv1R/a47jK8/IK8Q9DFb5c+K1/CTym6OM7ax8en38nejrcvwUu4pEcg9EciLpUf2YtLLdED GW0aln8hUh3+exqfWfq79Fj6Xlvh44T3x/+MnmY36TMvv1XBWZSS31kaleZIXcdXwWV+XK8HMQDB S+Pgatoyhxt2JGU3Q2QxeJcK0H+Z6uxdevQS2qsZDeu11zk0nrrMr72LjsU9vhri50Ht8RnPlzFi apP4VHcupyO/qInuSfMDMpc1DyQQ77mIDsiMTR9cwu6HpHC+0l2y+x3BHmKXA5GV3Cy9UORp0sth 24IpoXB/wT+pO3BW3m8LuUMiTvgqjwVwhzJd+FerWody3r9D1v4liHfezyG5uJCn5JzmsvuDI+3x eLWbXK2+bVbiPozLd+m/wzI5kz0jPdM9fScoP6CRPu8oncVZg5IHvsfXu18ze/k/bH9v0Mfl/pan xIdv13dAX/2/Rsn5Pzlz9py4X855crNtXjhfKNZhnNuZWYdsJyaMJ3x+YT+UqfmE/OKvu3/wOL8a +yyNTT8HKZKNf29TjrlbJcD2syn2trHd/And/u9wl4vfwJpinEl7Z+/SsI1yPvru/uEV1R+RB7GW cifkelbjdPRZGPoNgbDc11cUt7g+5Hq1PJ17j7mCNbaPRuPof+B/+uVaIC1Vx1vduMtrkS7bCHRf Vyg8RosLdRY1q0MrPZUKPLU8II0uEHKOvT3KFsbGfX7IYWKiS4bNqD37g3nRu2zFTkY/G6TsGBS4 fnxehyuN4w+G7i5gjIex1o0Y5xtzcP3/12HiOGSyOV1ysSkvfa1ntqZOyOcX7wRziitYWV73wTD5 xWMt00brhvBlu/i8dpYZiVSo+7nFmmVUPavV8hH0o2s+3lWc04oZ51NuuFa5iu+oZbvv3eUBP+z8 +Ux1nu5Sp5FXZjR9VJkpG+1gf0XLJvfwJ2z7vcCsvfwLczFtwHxVakb+54JNrhFta8KtzVs+e9Qz SjRPuXt/d5B9tuKfWpc3tuZNP7W4je7lumFc8nc8FNVMPOz1xYmR5wZwbc4xl4FNa5v57fgcl7ls Jd/tbW3BQf+ui0I7Upb2hdrMIBx4W+Hfedz554eNOAgI/f3qLYU8Wikfvqin3AJJ8Tppw0+LzrYf yoD61LK4tx4R5wUfwRstxgbv0rg82z4vT+3hITgWqlQwzgXqOAgbVod8QxZbQCuCus05dHf1rcmL YjSA35r81WkHy81f2GWyfEbgxXr/G5QaPooq3JfuOD0pnhny9CtDtAZ0qEfRpRMxoOnjqbop0x1K M56UmfXwzhaaXaaU/KB02hmlQ/qgfubQ/SQ0bw5tQA5s924QIHm0NVR6YNVAFAYfsgzwRWAQ9zn9 sIdMKLeFh8EDfYru/mcQcN4wwyxGOX/1IneX0PoGfW1P/sYpB8wcv5/1970XF/lM/jDYfMRbUdXc Se9ZGRqqjx9U/lPd4JnM4bZW0UoN4X6SB2JLykaolgzaQQqZsoG5wzZz7S//Us/r/fk3/tCVNKTf /1kUM4kO99gr28NyimU8ojxjRRH4MFRQvF4IliFlM9JmygbnDGTzweS/+ir/fk3/tCVIOCjei+0M pjQz/2nt/d5QE/fPKJe3atJRk4cPZli8npRv9o52Ohe/gT83rsjSSeKVOuSMpMrQ4vOLMJ5s1L38 Cdm/+pxXQvfwJ/KLo8r26P8O/sKOj3u99Pj/M93K9BuLWNqLOuq6O6rave/DlB/GVb8X7717lXVH sOeu5bWNdZWFlXVtXv9xab95TPPm/d1VZTbmhzO/pKL5t59P0Uu2tLb4aapr7D56R1tsVYWFQt0+ w7borOvjanM+9bd7+irujoe67fistuc/jKF6FxU7e3tvo+in3ljaWm43Vtu91vd9S/RuL2vzbfgV b7gWj2xs70b624FjvtvU77dbrd/SvqLK2tvjt6qnfUlNZPbY1WNlZXVY3yRq4l2HFVdU8gQPKSjp aakeU9Hv6q/U7XVb+l/k75+l8/dO/1/q7j8u69Omqqanqaqtp3ldTsb2N4u68LaidDyK5bcAKoVW VnU1NnT3pIENlX0djX3wdcLd3T+ly9XUVN03cpqU1Vd1VVnZ1dPv6Oqpaqssax5YVonvdnhED+qv /LqFapo6ys/O3sL6mmqXl9JUWdfWb17t7at+Wp3m65vrmH6e9gNXD7/nVPeNn62wt3lbWeTp/itK Oy+aojttudj+apsqevS5KYe0v4+6ePO9/Fdfu5APn+f3vUzdxcW1ZVV1k9FKo8pN1720q3sDy1Mp ZChkb2ttaW76ssHtfXVdpY11e+qrW1P/GdywFHlVY3TZ30dTW3+N9XW1o5w6+g9/gPN/a2e7tLC+ 1sbW8+vqngoQfxolOE1l6Srul7dqsvzbvVt279+tvNGH2tGX9X8KPFXSMfWqNT0KwK4RKioEe11P SU+73NdYWG8vIKoGEA+neXq6Wx+at3d4l3xLNE7+n6PnvLpoG972t30g7ofntkNeL6BRSUlhZ8Db O9/Rb7d3RqR29x5Y3D7MDMrWZum0J6KgkPCKk3O3qtR9H0edvCbboBYUtPxMyzXzTqVZTc6zm5R5 QTK6fmuUP/F6YNH9hivxfi7aS26/VIY5LfmJuKOlxTDe4G+Ddxnd4QzW7TB5zdQXVD8P9a4W/Pnz Pi49/x/xGZ3cn5rnGdcaL49Dwp/Em5grGE3rsZgt9F3+OEHW4Eu46su1jzKsdn9ZdvHGVihzx6A6 o5CLHq/iWyf6uzl/DB8KaO2EWK0tXfFYyZHZSRnHfIi6cn7yCyvgkSnROZvN0ftmIbcr7iA732Yi 6dN3m/4TWNiAZkSN4ltVZCHb4ja4jF4NEx/hAPBjV+Qq46GAYMhXBHF+j3I9+mp6iWevro60uJTf MKrMP6THL/plFtv8drBzR+B0C21b/hv2Z6R0DN4ZtDshXl/YUDxBv9R9nF/qRXN/1S8WzVFkPfV6 Hg0fqoqyTG6ex3lR9+NS9QUqf/EU/M+weLxVFaJXA+1b32je1yKfiTrl7F93uRWS/tvHo+319xUj wLam/nx1nZWNXV4uvT4FVQP4+jZS1NV2bLe2VVXWpu+41mn31PdGt7Xf1m8qeBS0e8+ei3e43bvf 2tLuMWNuu7vc/hbWBVwL1dbZ2L6vq+BxfvW1lVlVpU1VrAA+DK1wnsx93eU1vXfR89H3krus3u91 bbn6dy83VF6+64nbUsNwKqjd0VTedvN9aXJSmo75695UU9nZ238+ZN+j0lwTyQKixA0qPU0pfm3d PTVdc73lJflfk67IzfesuP148A0vKvzOBXQNPOqOZp4AF9Zen23u/4mbOFwKnm+shtgJbO/ndfD7 hvLV33tOXob+1Jhpp6estaioJ/A+jevK6wvXF4jxXqrLjcbz6d19DwKe1+SQ23zfk/XTEd6uopB/ IR3+PfUm3qDR4fI5L9Peb2ioqrgX2iPAtt2TbdkVJuqjm2VDNtaF1P65k8m6BnQtqJdKcoZmN8YY bhBf3P5FkpVENz/Z/DM1vMDaLA6Djb9HPDULj4uWsuP+IyEr49CePOeR/UqFXZcywQ/IIcELizK+ LWv9C4FSblofjL9Gshypg1stG/WfmEjK5b3VDnccqXfL5MlIhkXmKVpfY0X0k/CsnWFmoX6mBf9K v6HW5Cst8lWSlPlzKXJSO6VZO5psv7Cm3/eHlKn/1G1fFHAyN6X/93AqLMvkL0C9/L7he/k76Bb8 UxOEOJuDixuf8j7GxY4w7qGxOyJxZJ/6eJ3PsTFpJv92AxakligE1/CGxQJK7JDFrH3hGyZapDFB R2r7AxbW86tHFtk3BxVjEGKKhxcJOI4orctUMXBqMXF0HbQcUYYbJDFGURiixdskMUUlfIQxcwcU ZtRc5UXhuIyZKDi6p1+s47kTncnA7TAzYmhXamjTryh7v+woaTQMwM7UUEcOjRwGu6k4GPU4Ixl/ yJ5+0XM0aCzmB2ngbg4EHQFNcaMBFSpouCUKURR6DkDAnBFvCjAYTbDAc2aMzznbieDDF3cFBZmD s9ByE8DAQ8oFEUeCL1xo3NGgO+sF3GiRv2pQ0bNigrzYTwOTSZNHpouCVNHH6zQUlQHDsHxw2ChC dCYGKU0C8pKCTmCjIGgPRmEeGk4cMRXle4OB2oQnwnQdhNhMgvGEPj3fsBfNeIMdp0GnZiUFefNG wOOyFAKMhDyhR0LNiUnAMFu1B4UXhNAzCbEm97EiYCu5CiNJgRlCLd2aPjmL7nhBvThd2gijjXGj cHIPhd2Ah58V24kTw7NDzMpKBrgZAYF3BPO0A0nQmwbHlD24kMxd5odnQPAcBQBOA1BeEyaSpSIx n2zGbSUPnx1cHGbQ40EmHBMGeChjQD3WC9Bnw2Had1qGNCOxZygu8936GNFJxHGiDO7g40acdWhj LlD1SGMwpkaIl41ITwTJ9FQ7OBokfHmgvug81DGkQ40qeeAhjSSbOKAWb0a7Uo4g40qaNYONK3Os QxpEljShr1yONMzXPCk5wTJoKUohqlrhpaeivQieOBp0lf3AOzAJwW86EyMbJubNBXcig6I0lRbz JRcDAHog1x8QH1gz50vNOBhkqNGkz3gDs2CdCfChPX8I474oNBVAL0Xt+Hsa5md+hjXQcawaH7tY pEx36GNe2pBmMmpXukMbCLxhubNGI0xLx2ZhQ60oO5E+NF88LmUZhNA1CcBwFADoHgGeeKC1pQ+S gs2RpMA0DXA3CeByFED0F2zFOFJUJkJsGwToT57ca1lAMOa5wUGYtqO0+IOdKNgoQfAvGAOzRn/A BmiaCIYOzkHoUQTwNwZA88kYCKOAdBQAxB8JR2UXizmijUGYNp0Q/iikjR74YwWUm/FOCi4XNgUa Gj4W86GuFnPmi/xhOx2oTidFzlTxgnGWxETxxM9icCuuEG9KMzSaHZ2It8eR4goIpOHDg80FuzNJ oKApMiKbnvQTyhHabPQZo9NJ4jKOSsWdEVlHQk3ho1OJwo4AwQ8oUZBQFHRR4EwejPFNBeWu2JQY 0nB2oAcAYcShR5/AoIow0lAYHwoUnhZ0RRv44GjYYTmzSdBLHUg46zfI46qHHWHaOOunyOOu1/mo Y68HHZbkaI2o0AaeChjrNyNFTcWeu8FDHXjwXOaGdjo4dCTc98hjsJcJzXCU13foY7LohqKNRd5w 99DNnOegMAHagB2Ld8UXlGJRmE0DUFw0mT59BhpO9YieJY9xNeUjY1H1iPUce6M/NLg+xKnPKRsM GapGxIfvyO/CRQc93yGPqH2Cc0Ld1sEbKJn1aM/D+wNNVCho/H1Q7OjWUovLRrEY9WjXUnfCRSjL r0akD6gT4+z51JQdnIUQL3jxc8MZPXlFQzMzO8In2ryfHGysnjZRhKs6GUfTDz/01HvRspATbh40 ePJ6YbSrZc6n5vXL5Rm9GrNULpu6eNb6mZeOJRqxaimr090PnlAcXkTpSZRIdlnKvHDlq3eTBhHP T9C8eUExOETN1QsJhwTK9vAFmJ53RMkf7eeZPa5gyoJR0ZNO3044eYFTeEnwvBc7NhjdMCoxogjt 5MTq55EqYvCc7pMbOUHquqJ5dg/HQHkq4evJxpPUB7hMQH2R6DaPEMdjL0mWGuXGPCj2cXGGw+JJ QyQLUGD1pKPMCpfRPCcqZOabpMGBca5OUj3XEd9E1eClT6wp6k9ntVRj2faNHrZtwhuj188/zzHq /i8r9P7/AfmW9LlDPcMkORVf65ajyfuZky0fkdflUrlqP83wDP9ZDBbxPlLL6g73J976UuKNy7z9 Wqs87HXcV73LGLL4G5f3BnB2p92CQ0hWkdRZhLSFdPwp3IJEPjZaIySrY3dGZxCHTHH8eVG86wum KXPk9OIP91xm+gXf4Q1AXry8xksXXr+CtqMlXySy44Hx8GKwGh+rc7k4hxkLRJnwun44yyXvzD7/ N4u4s8BD0/w+KwfpG60ZFxplc/yxm7EHmBhV+nibf3j4qmjVnn5HmPn+KQH1ymW7NVcrDPjIuIV5 WqSBn6bvuAZGVI7com96338UQ4ufYLJ9jE10tQPTiERotTu49crCN0ZaJ/q9i+oTGGqQQZSPTENB GcFWstlSpWqjNqYdP7u9Ynvu8on6DSofrLiLB/6xPz19Ih/Pu9eLk7v5P0EP729oZBWbjO7nifpP 6tLRnZGH5thRvgIrx3pAu9sI/ehIVYSPACTxyom2Kz5MYvSgvaBj9cDD/kMz+8M1sgzf8gzntBxO 5DO1wcU/DClKz0NK0NcS5Q4P3u8wUjDzUKRocaEcHJAuDlwjw0oSAc6EiH5Akw6IMUE2GLDrAXh2 YY8O4BgHdhmQ8AM0HjgPzMxPFM4H8w4kPYDOh7YcUHxhogog5UKkNGCpYRH1L3JlOXDkQ5gNMDMP zBzIDo1jmin7H5FLEOjEPLlOxDSB6JQ7cU9ThoOcmptx13DZFXfHtxPT+HxlJki8YjaCmz12pF6R G2In/gC7uCr+hznxgM1pKxq27bet5Zi2qR2pYOQuSeRndDDZDc4pbh8pF3EXo2lMbSV9aXhgZfB0 J20xvLsWuMut7ixXxRUa2cmapmR5fDn1PxhDPiUzpE7zUIRuLOfzWHkYDVbcXo5N+Yi/Jj6Xp6ui pitPI76Vwv4qMJohWy+PGqsw32IJfH5c/432EqPpWhAob3v7BlxmY2JDMl5RMtqzC+0wJDMxaTvp vye1GjXM5oaijMib89dbQg55sWfMgUbEczg9SOhSIak9KeU3PhhslYe/IGpNzafFD1utwUUZIImq 1DKSiWUXZ8o3khpFObNS4/ajKqSHzf44p0Mkg+9UV8rjz4bJJGGZc0rhenmfFDZlMtUgaZ0Z8elY p1b08+up+eWhQ58aGTKHIiagNQLmp3Oit12qMdHvb8LddwMYyjLt8Hjz/x2AIt/ofAAIgDDMzWRG TNSWS9IjJbqIyZKK+sWkWVdQ2ThkRk4gr9SRLhLLvtC5vYxL1qOZZadKI+R0ieZraw+yesT5MuFe PEic+Lh/JyjqHmry8jF9+QcySTaiEFynk2FD/k0cHnn8FEqM/kh3msk9JBbtohzkSTckrkiEGaHy lpnyBihWbSn16J1hcYnflcuxcd9y+FCpWT0mAmZo4gHgqjxjOKEaQ4/Y6Lc/CaejD5yk/4OHB3lU z81RT2HUPSTqToLlp8sNlIHRYXl3xRmayJqRLUqG0s0SkswaJZVlQbST5iU02NUS8iHP8pJmbYlN WQgzaFrryBiWTnRQws9gWDtWaSmZJfMT0OffInPqEsa0mnWku+HjcCR/EQfjfKb8HrGlASyV7XG4 D4F8ojjbHC2IjB6kdd+lFjzbE8j2kGLlKTkUzU9THo0MUZjM9xIGnLtySvab+FU4225KaDIaSETi HPkSBuTBrcjzZ80QTmk/pEVzM1g+ZUn4sgjviKM8Iq/ppZPL3KKqUwz/gSOo3BaahIGYdyqM3OdU Ixbty015xK0RadyWaWXfO/KSm4RTiWdjPJND93SchZ2N+oaMEnkl8Fmf3LNL4LKbk4bo5vCI/ooh TJRJEZpSH1GFyZ9EPVJ4ORRkJiFTmjlonOunxzpFOKIsXJSKTnzVmYFXmbdGWUU10d7R1LMcE7E1 ObSJxTQKO2dlxFPG5/eWlCWB13tjKZJ4kjCaPSSJ44zAq9lJzina/v8pYyJNPzpJPKGHaN8WIp8u BHyUOYH/iN+3ZJOcU/K+SyOiKZWpR2SOxgf14B5UsXGBzKq0BYivDleQKHyCyPLQ3WXs8ZzR0TLE wnjzxIjc8TR+hJ4hz1RqM/Nt5Y7We36nBCZ6uyOjATSDPKd0bBzuRtGKxuXcaO0gGKDGhkQyYZcM 0GdDPgYdXyhoFPINEtXi1+b5hi6zRU4IFzhGmdGxpujC+TZCeeOaJfAdfM/sw44OPGOEvgSPnZw4 NGoFtM0dNEi83lkPJNE5yL84b9yI+EpJ8o1OGYG/SWozO0GgRrxMBdkOxhHifTgieWQm6R3o/2bp HLpvKYGaozj+YO1xTK8nq+jD8FQzdhloqcwRWWrsDX51axDLKTgZUb4Zlrr4ohBsCt2jv99QK80H c0ELLbveJQmocy+DbmotoXUmHby3C18vdb0zlmLDg4iy0I9iOKEYNLUuovTMeYU92WhgZztbItCv rfWLQr/hZloV/BnId5HsPkOrxZD5yVUqw1KbyF8IQ3O9h9/Lf51Rw8O4dzsiTZkFMxknxRZNognl CzckFGZSnFFEzNnvobPXLkFJ0cKMyQpYoprlO0ijHf4GJTPfopRrFHPBVXPAl4n4RM5CwhwZXz3F aQvE3P5vWwHwi5FMySj41Nd6XR0HFaTADD45d4XTFVbLb4DQQme16NoGpupP08VD8HPCPhIzpBGU m8LTsPXIjFCKkkc7jG8Pl/Z5vry0HgOJzg0frQ90SUvTp04YoB9oQypsyvviHo4kTNlxR2O/LPk5 KXYyu9hcdMr9HBIleefNLqCnrJPzZxAdyQPgv0C12p4kRFm24rSQdCuHoUUJG6SM/DiA9IQoSzWh BoRRoz9LxXPeeeWqKQqMmGJpLhax8LNFFIbhnFHNsQLkuU7hm7KHs5pQTMiFOfBi9dKZ+xA5vD6j yvMJr8kopXiXgfPXIfNL4DcK0bHSBLsTeT6y9MFePrp1gxyItjei38KcJxSw2ZpnisYXHkoYis16 Chz3RK+ySJnYs2LvxEZeM/F4W58OHmDWxHAz/OkZr2GkY4LxSKSh/FE5A0U5jtMdIfnR0phZzdLL sc4keKRjEYgFP3a5zPaSLOaBQsFbjyRgJLZu4InXks8AT7MkZ7PaSLOaokzW18qAGwKIHBXb7I1J 3DR3TQoMPmAyz0KoUwp8C5mRClO/jmM9Cqtpg+cJU7zQY8iJmTuETd97nyoc32xzfL78dvGAc33B ze78809cPbDtw94P5ZEi+YV92UpwHNzMc3Kq8WY5uxjm6m/NBzeTHN9A5vmYrQXfHN3ymHYc3ssq cZlLh5SaW4kzII/sp+8VgfI47I//+PRsoFr4oDxkUMY0ulkWaWkNehNg+hCXkgmOSN08mSaZjpCw eehc6gmnUh0yhEThHjKNJTFx2PSihT01Asue5VQkRODNkqwJg9m5Fg2qtKx/yK7kPaPcKsq/0QZh 7Z7uU9wrKf9ldYVe6VlKErKe8VlNqV1pV75WU+ArKeIqKFNiejquKvFIMw8YGweOaynkFb0q8krK fCeQU+I84U+Mrryp0VlPkOZT5Ssp8xXYFW2Kyn/6SI3iIeZgAdCYIAXCKuEASTxoisAI3gC7qCAo OkqI75XRdx3MXeAuAki6oIiICeAD5SgQSRPCBEiMEgRAV0TwR3AUfBBmEoaVBAXLtvTjbPrZzsuR VqhUM5hFV3hy5D6PtJ2k8EJB4YHwrmuO9/78/f69//z3/R2HazrGP2AhURe7b6XHvN6+A4bsThuy OfeZszhvwnDfiOG/Gc3Zm0OG/IcN2pw3QHPwM844boThvnnDZ45vDPQOG+icN9M4b6hz8TPVOG6M 4b65w3SnN6Z7Bw3THDdOcN2xz8jIDMs+VmZvmZRPnZpLbs0RuCiRvoKJb+lmYNyP9qfph/rOb5c+ xQxqzOSrp3tzcnxH0sohYO0ItpN8CqL7bsix3R9OWXj1aw8bHpGnUs84asfSFKr3eF7ni07NIPfr razESRMwMsFHsIvzZi2bNIffrrazpJjZgKPZDliNlki1/xk9HbOcL0a7tzWriTbw/VaW9wjRhUg5 1d0o3IjbQQ5JRMqyePUcmUjZld1AoRYLSvWcK5VL9Y/jNWmCnZPfyTfPJd7S0m2osESSXVj+Mzai qxTVzIXduhbR6Mr+asfxnEg36Wb8SFrImiZ4Inosp1Baz0Vy2U0/X9Lt8lm3EOeb9MWh0kHokNck CMkTAElbUVqSvPJfrH8dgu323Lm0Jd9Ok6bM29eviZjUKX5/KwXAh0uzg0YoA2uJ19hXLoT3ZRI7 SrtCI7qEVE9qL6unueruiXdyLA5RVaLwukizqGfDWRSRNnQvLGVz6X57t6kdIXJcmydGES4l9K5E 3MG6MHL0Xh3qRbfJGPUOoEXJkSxJzDlc7Jl8PDJ0qHaId+LBKJIm38KWfnIsxskl+senOpD6hLNu Gl0IjiUTvi8MkkWYQ5YTw2A3qL8gWCVLZKrsyhnRohswieoV78tMddSLF+FzPh0l3kjc8Ie+ZsLq vsi7sgjyXYyw0YPpt0v1v2D0Zd0Egu4UToPppV0/luUg7BLLjomcGjFAETVsy5t1J7JVIfJLs8Nu K5eEVtS8MteIKrlSNlku9YlkZeZOndD6WvPK42Wvxj1I5+oR0uOXUE99xWep66PB+6Q9Uh6pGT3q j0Z7qiw3aot6ShXpGC82d6PY9SnNL2Q6SzNjcg5FZIqRqj5dfB8l3GdWZN9Wvlt0v1uURna61vhG SSzciX6w6rxWjU/6w8HV9I26Gb608oy/I2SBusQu+uI3ZOUv51ZitGqwYAiVQzQfDWDeg5ciuOwJ bJZIebQ50T434RL4Xlb4IiXNejQDZg5iS8LR2RHm4UZcagbsYyG7Teo7Bo0SyQb1d0Q3IsGEIdEq PZMrnMIvs0CQ8BdjevIlSckFUd4K/lnkjbddrmFIliXoijfKR4dEbQIY7DEX8nLjWCVptFBy0w6+ iyJBzK7oBQCydgl+apO0hXoEK3KI2wSHjZgyXSzLjYBSdrUeWNxCYq7lxsBG4ljwEvzL+GXSLm13 biyYoiaJ0oioanmkzyg8kHkl3WCwYtMtN0os0NN0ZjC0R67OoaASuNIzpKzwiWQ7wrv7wtE4h26G S7FMU1pjiMKS8hk7UJfrH8aBIO/481dt80RoCbB2RDvozwyi6fy0snTZ3p5Ik+llCEdGuQ5Pc+aZ Gmv/MZo27T182QRlfeURnuQLs0BZ7MtJ6qXLs+Ty5v2cE9z6ZA3SzpRL9mx4NdCyyXKI1CV2cmPX emEdN0+bpebR8MBk0qZ+9y3cf8XH1CHRLwLcuZRKbVz+GcXHcbI0m6zwt+ltYTtXMoasGxrAlV5O nQNAY5XXvmkT/npjtCZPf1S35JjjzkkdAEg3CFsmHc5iRX9Ns+u55L/x0nkjOvHNzaUB8Q88VJLw iH3iJf+GksmJQoWulS79BIqWT+XSWNcjis8jpaewlyXF1raiHPspGfmO7RchekwfXmOkg57BmP7S HtmD6zrt+MgJbaph21tQUPXIb4ZO3pdu6GTXV2fsqXcikpcUjrekuSbQ557p0yDTU9F41Gn9UlCS yh9xIhrn21/5E9qCHBpx97SaGQvkzWe+VJt6xTevZFVhgeTJq7g+jIaDbeVJw+2a045JVqG0eN/J VqKQeOFNe1xKJ0QjkpHQJbbJlaw3JvyWjmqZefYa5H/HcJJUNluR/O3aT38V+e83n44mtdn+P4b3 8d32Pb/2vm+u2Z+O2b3Xc/gP65jCcDrv7cHgfHYZ02pdX5qyfTv9+PAnZ2A2n5/QQdsCeb7LvO1e 5PFQG+tlFbYE+9x2OOnXHvXV+68+R02usd88z86rsrHXthUN90Pzyek3XOc191aib153BrE3k+xp e8Wq8gnnRyuevVDzPZAAAv9P1NVfbJQxz+Sm5vJO3m737jd1yLj2moctXDienpbbu9nN7uyX+NnY GXt9kl3c+/gLPHTyeoZfy7FakSiz/WUS830V81hW+SoatOqH24r/BiVsvM0YOX/nLLQtk+Hvbz7L BvN0Z1UHbJHnO9cVeRgILdS/LhOEzgQT7jzOs4bXH7n3U9rOzWH9eT23Pqz13pJSiiPg6WBz1Pz3 f422b4zZr/njdNjxzPPwAAX7Rt3/0YOK0cr592qdsyC26uN8y0DDZrD1Oi3+28+buuCyVe8+4YG2 bCu53Rf08XWrYp/iHVj1lUrecqPrxERwYbyHj9KJ4MHY8v8zgxPBK5NE0jHoXX7in+SLnB20Z5ab 8qhNnOBUPtrFL5E/P1c5Bg4OzGPERwzRKYtT8931a2503FgfXM9kAAC/yeAz60oV6ici4neMeXB+ 31Q4NFUN7VN/vqpvOa/CqcHep0sXzmqMIngUUVv4jlvg3ObrUuA0TZ00HD7bQ88t7bQ+8zu20P3M 9kAAC/FTtk3P7j1DefyHTt3K36bX4pBWu1Tvp5Ju81VGb+KT27Xyybdr5Nvbx2tXM9s6O7Aljr5C HtaD/srgrRc058xlDRJ7eq38QOLul0bwPltrdatyitZ7W2aMc0VxbvUv53p6P5glxYUE9b+oVsAP T+4tytgEr3nUDXdOW+ojpRXi9n8/xP3nFcb5T4mNE5k+LgfZij93Z2NbBzjuaO2333FW07h/5XFf 2blJlLHiFz3n6jp1ovOfy/Te/nSDTr6dA3Zmit0oxoBLrbm3c9xIq8XSnXD11/dyrblw7tXEbcb3 ib5mTSk/8tzeB/jidzrZccJmsslEfZHp1ez+zq50j8LzsorXJ3PJh3/bEJ1ecffNKK14Nc9Y5Vo6 ROj4IH9eG2+ulFa0Cp0P6tI8QtOv+T7v+I+87S3q1ewgfVcVb1i59juH3Wdt7eAkonW5dATKo9M8 6VdaziBOtXD/6birV0hPc6E607btIN/7vE/d9NJK25yJ11Jga2TVo91z71INOjdZ/zZBW9Rwnxnr zu3KtWwXvmW9WrzU++t6tbTXMj1CtaaKC3SitEWSEdKK8ba5+zp1bAizdJVOrf09s6R7v77irSJZ 6meFvjY8QmyUlKK1pOsEdKK0S+To/c279yrRrz9NSdUmZJdVK7OUVrtQnW59Q5DiFxetk1bdDIHU dQrWIFOj62o/0uJ0WOpO3KkmlDT6kY1z4LlWkSplNUzlKW3cjKK13/axINrnCG3wyKtHtOa3KK1h XJ1+VfJpxbe2tXjkJ1NeKHcJT2r/TzyTaf7yRVoNdP9zcVa0rPfeo3dXDqFa5TPk0ZPdqxotx1wL crXXifTTidcGXzlNifqtrfVdLKK0YNyjW7tzPZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF/9/tir pC4k/sJw29p/Ej8/tBPOQfJo8QX8rRSjef1trbx67+x7FHzZFuInrKjHt04Mx+Qst3YqTe5peLAP kfW7S31FDwvRfkZoKjHw/k16b3Vqb6V/aFcTf0D9PxIPqG/L30EPcBLHrHEr9tMDxF9RgbmxtHcU i9xUmEnYJkmwziRfRgsRKF3dFYQPzrmc4nfoansKRAL2gXSH4mfkv23kSrdrWOFx8C6L79+oWoIH kRTQb1oQ2ptGdzqPp4g+X/FcwVTMoYmVp1Pbtbh/SpMe2sh+e6N2fYEqdNW7lXFfa9Y4k/n0XSLn J2VOoEGQqSdgmSbBNNOfSqTDDlDhINPdRzOcSvx44chz3JZz0q3MiFlnlM/zvP3WjPTrqXf7Hskv t70FIvS6SVbw2GC+L/6/D8PTc7P0TMz6vC5mJMzekp9PNDc2kxcxnvQlW7OzYF8uu+5VxYqvzuc0 pGXirqVT0qxIVJOww6FNNOzXZc4Uqacz1vjxmCHxezm7N1m0Ntlv9w+1dcLoZUR7m7L76BIshdEK MXi7D+x5NyMcya4naJxXEg4gsZ6UXM2kx0QcSN2bx6/Kaef9yriy9W9s6gLsleLsdObsxIVJOwmE KaaemvS5w5V5dq5nrfHhiSFvZLN2TPKs/FM/2dSu7ef7BC7LwaWLpFzOHuzdseOWQw8Tb4MzRYVB zpNkXYby49rsMhdlaRLKdvyVpxXFpa9+VXGYzQJi7v7l7d3ZiQqSdhiUKaafGvi5mCq457mb4n/j xmSHJezW7kOquHNXpX9v66/N2ti/Tj2t3Rvrl/pF6yujPU3sePc10KanHi/5vh9tW+Fp2FL60CRY iGB2FL/NtbvBX9WLu3Z1jT5ANcziuLZ1yzb6SjqP2ngSx01u7EhUk7CZujCg0BdgFziSrMeXzPU8 WGMIezh+1+Iapsvc/UKV/QYXAt3/R9chvy++fw1IuP2dIfc0vwR35YN/w+9pfgkVGTRlv8fhdntB kakWIho0zrkGbd35XFL9MX5j0E6r3aoQPpxXFwK5Zv/ZuqcVOc1+AXp3fmJCpJ2GMujCgz5dfFzM wae9Lmeu/Q/wUGgI9nmBbrOoiF9HoPiX7WewTd94KaUeYFffv0i6XvMC3hvZduqBT+GX3Mb2Zmdn OF+0mre82kGo3VgS20Ex3ZGbSY9sT2PMZ9icWqqQ/mri5tW+apK8xksHfUf6jssFBp5McqQqSdFY 6kwoM/Tb1/Ct9jCqK5nLv3M9kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB/8dg CQ6OAwACIAAAAAAAAAL/qPpVvu/IlW6xfHK5djzudsvElVeby9wl/URlEtxQ8sRgywq478NR4Q5s eIK4PGFdHjjnx5I6Fb9vL6/60h3tq+WI+5Ct3vRrb1eW6prcA51XFZiMwk1ViN4uryKNt6HPeGiq qhUnfRmUVxuUbmGJa5raOOLzXjlN59NzrIexIuENZCu1ncKN05XCIOMxyM4vzI3K5yUnKXSVut2u 8t1N4vLrqr1e5fq751l962/MYat47CYxGJxUzi8ZjXnY47HzXZZDs5vtMjS4av56VPx+//+xiaja D6qKieFp39BRchxNVmfNAbFU2Nej0rU4OxQFvBwwjp4qZxNBsvWyrUVIYKp07Bc+3/sops0PJ7HF TXoQ8LOh6Ast22Ko5bl/I+5t7LHoLw5q4uVb/Elm6G+FUqZFeJsYtwuwvwxIyIyozQz40g1Y+Ibo b4VSqJjG2MW4XYX4YkZEZUZoZ8aQasfEN0N8KpzRptjFuF2F+GJGRGVGaGfGkGrHxDdDfCqRhptj FuF2F+GJGRGVGaGfGkGrHxDdDfCqVU02xi3C7C/DEjIjKjNDPjSDVj4huhvhVKsabYxbhdhfhiRk RlRmhnxpBqx8Q3Q3wqlXNNsYtwuwvwxIyIyozQz40g1Y+Ibob4VRqabYxbhdhfhiRkRlRmhnxpBq x8Q3Q3wi/KIVqQL6vOK4bc1fratRvOZ3DNu5nsgAAAC/Strq3m+guvJfbzjexVHa2wg9QNv0u33w ipfptEsee0gi0PNIW2zQVdDDxbcu5HjIM+17B2Dz9Z9FN0zsZ7/B3Dd9/+0GWYTymf+niOH7/AYj l+qSLVEwenG6uJE5GDL3wM4PfMzUjrZxImYksnuOKm9Pw4SX/mirS1Q6fU76gxObqh5NKoVRi3L+ R92d7Fj0g6c0OllW+mSzWjaj7BwRVvYIsJNmFxF4GBGMGTHfDODQjTDWjaj7BwRVtMmMbZhcReBg RjBkx3wzg0I0w1o2o+wK6QaF0fy3M9kAAAAAC/TOrs32665lrtC9I+x8RB6TN8iBAqQkqsWTmolS xXjYgsqBj5SEvFjyeVIqkKkJAs65UiynooqqBfdatWPTnByqSv6315LLGLcLsL8MSMiMqM0M+NIN WPiCukE76q7N+Z7s/uZ7IAAAAAAv7jvIf/zlp7XeSa2A7xYvo/v4797Hx+7G/cj3y+Ly6PXLYnLI +v2x37I+OVh+UheTg+SgeRw/IYXj4PjYGnv4d7TO1OYyO9pP1LXr5e9z43ZUVF2/tfdziy3e9ynq j8UXeut/SC3/c72imqv3exop/vJThv7E/Utj99/XYHAe13NBGbnYTX8X9S2DqOELdFwxb+ix/S9F hbi2wc0r6lj+XlU46FTAQdm4/Xzm6YXijufK4X0xNkHPBqKLySKAnZB+PLGWGNDoWcRg+nOpDm+G JkdQGo239yNAT2YcipDWeQR35LoVcazxyO0ul1u/U3nqr31fWdb12AwWD6/DdhiMVi8b2OP7Ls+0 7X+Xbdv3P8/6d33ne9/4Hhf18PxPF8b+3j/38ny/M83zvP9D0vT9X1vX9jT/49r2/c93/P+ve9/X /Bsvh+P5Nt8vz7j6f9/V9f2/8+/8Px/L8+BRRFQ+DuYyrNebja1XK9YLC26COsTex2SzOLTH2yQt 1vuLm5SUpK3aWvDq9S98vt+v+Bd4TC4eYxMzjHmOmshN5HJZN73E53WUyuW76d8HL5jM5rN5x95G d8rPZ/QaGe9HRepo9JpdM/9nUanBLQcP39Mf/h/wv1PqiQzSLZ/NPcxGmhsEH/ohGFNjcCgtRC37 B+6U/2GP0p1/93l/96nZz2aKi2H+OFxZNufkYnTjM6Yaj2B9mlFaJt/rkO9IO49YeRow/9UbT1Bv PTFWJjtERIekLt6Iv3oCYnhNeeMnoR3XnDLaATvmjwc+T5iXeeTB+WkGm3H8RhWP9rKld2+ii7vS 9fhsmW/lg7L/1QZ6/Kgiird+CWWiaFW3Y+YSnOnnpc8VOyzy0UVTMUGxZ2SKKokr11RKolYvubPy 0+qi5Oq12F2b2JLLYJQXwYcZAd0MwPKHqDUjmdwwY8z2QAAIdX5u1v6DkmE6iesUG4lAsVL8Krej Zg+kKqkp3Yyqe6U8FrIdObIeE6dz54tbKdUNlPBxZjp5ZjwnjuhPFtZzpw4hotoZNrQvg7tLKdao ZBZdvY+Gi2s6nbXDSU7c2yGJO5YqwH6bu/yzc+GQ8/DCNemRTpe0cMu56Gg587bSEMbHa1uRhPHb q3ng2uLKMy3EHF7fL4rdQzF6g8J9FtXJ4PDueOzjiRKnsieEA7cXI6iVEkW2uZ4PjuAjFzJItls5 Qr25k18J07nzxcSh08Xs42uiLRbGUqySRaJPr21upYTzLuhPF9dmU8y2iTt3KztXgUpZlGRcSvOp KztgS8ItFo4vLKC6PBbqiJ9L+hvVNBv5dlDdWeLLtrfDwn79LMRZ48Z2+snL7DVF60rZbVlO35FU KLYg+uZlSLYNr+ycwC+E+y7bYGGkGCOnWCPBq7Onbumg22DK2W4k5hCs7Pjr0U8RaOMKVnaiTrDM yVFojnDlU6dojXsGTZFnGswzBouIOYgrOzi2JXtFseuly94pfGZKnq9sI2LKzs44xhWdo4xpWdqy n2Xbl5TQb87a9ieDs7nl7YNscVnaI562DUptj6aSvZpFQF7OOOyZJItEbZAqfnajZ5NlTrtCwfZF F9qvg6O6Fe2J96qWXq6Io4tlWTZFxRs7ZoId7ZEUqdzvvSpt0tNBz3fFTmxFg5jl6edAuNfAMYE5 5e+dXHR24rZVQ1cydNYXMhYJLsJGd+CdyhYT5XALGh8I7kTpEgc0ybRZDjNXdjaJ5emZLdiHbMG+ qTKNFJQUW6aMiVBGD/NMnIlfBz4p3wKaeID6CpZ3+d3QeQVT/mL09/Ihz5pU880T1CQ+85kRLcGv fjpjNW0JU9+ssHs8VOaCGg90yjblJT0YM7lvSDpluIXjLt3oqaD5DSMBkO49OGtGZduPUpoOeO6E 8XnqnT9ls460aLRa8d+svU8i2BNIybbm70yD9DMXcFhAXtt68MjMu3GlPCAdtvYhk8d0PsQ2edpk XpqaDd6denzLZxw/Knp2wqr/BWdryAvbb2YZBO23tQyeO3GohiXtnTxls491LKMi0Sd9wqgHbFVN Uip9FnKHHwVQNfnIee6zaTsYMHP9qY+O3GLJXXGQMdfMVLatFUOxXwfaxFstoj3/TKMi2Kqa1kP7 1NSP7nJRN7cHvZP0iSg4qimnbxBdW0HxMj9F8Es65LVcuJ8s5pF6yplWeqdP6tXQVNGVhqZ1aIgv uW+71dZbElWMjru3yaWd8M4NCNMNaNqPsHBFW6Iiwk2YXEXgYEYwZMd8M4NCNMNaNqPsHBCurnbf PVpWw6BbmeyAL+FJ2WTucle5GyyUne7Lc7lc7VZb3KyKyYKVhAJEi0WmQ5DDWm12wvVlvSYNOLeq nwN6ucfT4Djje7LeuPNrLeuPNxJ8ebxJ8cbzJr/CT5CbmT403qRVC0xvEF9CL3Be04vUGChi+qWA hF8XOWvEute71fE4Bk1a6CiolM6Ur6osb6Vqd4PjG0dLSzFP2tq+MjDDVpGfSstn9qVJ5HhxPY/H zPJcOJ8I4tWCwmNmpizJ/gB3j/ykyDBdfhscnF53zosfZ+FLdH0i15dSd4vd7lsFJXW9KxcT8b2L r5qbsjbo1kwif0COyFJDEYftG3X4OZmcJg+vxSzBOeJZhsZNMOlfyxbylHZSR/Vu+csMz3LgmOPE 9Xb8uEsUh0Y7QegM0PCGWHjsw+KPFHi5dOH+d/56puHOvTT93K5LXPhCze8Xm8SfSLS8te8haLOm mshalm2Gm3mNx00tKJ/GGyORwaybcN7XaLT0jDi0OLTH8MyUrZ0vFNSVJQ2CHkpVkMq2fG9vuFot lqgu1fhQ/5O9t49x0jDdrthFqU4pCSCS9XOPYAqbOHLZHlSBgeLTTOI9wvSh6uvEDkYIFKj+N0qP qC46jhB1SgrRbUpeLng8XhpmZxGDgj8pXrA9n6Yj5hWHnFqxgJ+bSasQtlyVi7T0rELv3HqALXuX vVIa6S8qsyremG5P9C1MPEp9pZaWHaUPNlUrviOVK7HLnI9TJy0tdZGlCUsBSj4vPUupaTo0vEve ZSRo5pz/iU0ZdXLS62Ku96uVr/RVQ7FSUrjlfjCkSaAyUvyl1XPC47B4eaWwbAmDKYNVH1g1BcGp d5L+VYoeFJ+FsMxBYZQWRNhI7hxVI310pl5vUuy1HuGXHFwWlrz1i1IuSuvV9StK3W6Sv/WqjEPI Ku/dFZbTasenDg3N3m7hw3IfpyPZEx5EnjOvS4tpHU4MpRinuh+P4rEL3iB02Bb6rDcm+EsDmKje h3WAIeVSNzqm3XD8f/s12Ro2IcyBuTlXjaE49QURx2ZVVCPEFeKPSLMUnSJEo+IvJSeI60o/IeFJ 8juCkAjxilCRoSjqsRupCzWNm2iUpqZAXjYz8CjgiKUhOTM2oO6Mri8dmaU48Mthx6ZtDk6ZeTj4 zFlJ4jfqh35n80Sd/Ud8wHXL59RwzRLx+Zqyk+Ri1Q8AzaolCZQlFqlG2H7CWpCy8oatGxpxsgm0 cfqf8y8cLnQLxygs5R0Rcijsh0UeEdgUn6T+TOPVzuzk6Rlyj4h8wiGaAo/I9Yo14j/uMB6S/zMR jKBHHD+8YSjKnQHEpFAci43pESdXLWcakSpRt+ngyjgjtijkjwCjqqxucLgzPHHZHqFIFJ/TnHiD ZHHpG7YKGVP61IRnRFJ4jpyj8i+lJ8jElIBD0pQpMHFqnG+OGpHsFGxGuKOCNywQ4l9EiOeH6mqe nSCulHZHRFHhFzKPSHZSdIyZR8RmCjarxvpCeQas4/SUOT5H5lIBDX7VIRnPlHn672CopqM9QOSi 1UjY9UO1MuZSfMv5yARiCjsjsyjaj/LHHBHiI44u/nsElzVlHK585x0RhVFHZn1nHtH7ShRDKqcn SOjKT7WNtQbGXc5PcSecVEfLmCKOjOzYhzO7KPyPHYbpD50pPkaYpAM+MpQkfcUW5qNq3/FSIyxl GxGqUM4M3JRyRJKh3RnVlJ1MoOO0GTOPCPDKPSPMYDmaYo+I2JSBxd9qcoaS/0nJ4yhOPyIv7lSQ znikAizlGv6jyRyh4fvh8Un+vOLRn6vsB0HcFHFIfvzjbh/+xcGeaUfcSf1zjmj/YnwZt2I3D9Cw JV43gFHVG9e+84gtCm3ZnUnHhGDKPSMiUnSPCKPiPKKTxGmKPyNiUnyKApAIqW7UlGdAUW4o8gca kXIo2IdMKqM67dnDLF9uA5Mt7CmRrxIjWIMi4rApwdARvdJf4dD4Y7AeeJgakYka8Yof8EyKh+BG LJrIxg6QY0W0PBdw4SWwBtoGJFpGTGINyptXQ+mtxP+xNzYxyHzRjxpRNDWjshuhkAtvCOzJaibD YdoLQMiJUdqL8MkJgfyHaDJjwh2w8YPRkuCR25PnG9wb7g7lRw2cG3H8x947oRX4kf0OG5QWsd2J YZUYYd4Hoyw8Md6MPtiLUmVSCZ674eimH79d1gnR9Ij0h6I3wDavvTPBJso8IV+IpL11C7TGy4nF 3+ouSG1rt8Q2wY0Zg3LG15L/yjfDN9o3Mj5R4g3ozQq35EeKT0QzYtor6GUNziG+G1xRQ2tDthWx 34sA8Yc6NCLCM6lE5430l1sbqhz5RMP0BvwoehNoRHCgQ9EbEb5BYja6OjHTD+y766aGfIZZd5td wCHx0OPTUxubiB5AyKH+474Z0eMPJHoDyhqx5Y24zwoh5grf5kZ8m1DzVGDemNwRugQzRvnDKDQr w3zxohPD/Q9AfQPRHBHpCtb8jRE9IPTFyHqDrB6oxA0YyY9Yd6NIosb649MaUa0ewPmGmFCNOIvg EPyeeH+BZB7IuA9oOhqBgB7Ya1LAp3E+Y2aS/1I8FDVjfMN9w1wkPqkPqofdN9kasfCP8j7xrBLp E/0o8mhNau5JL/3jWxs+bax74vA1wwo147MSC7lDdgqUG/ANENiP8ixpD7Q3ZG/WbsxUaIj4VFjf iFtHOJEfJOfGpCS/2huoN+QYIdKkPkkt2QZkbU30DebaJMG7+oEfSogl/QGxqGMiyK0TZBFCWDUR KasVs1sKwLiPuTGeJD1kTqHbqkBu4HWofoNxosqT2zQ2ZDlVRjd6l/ZzfIN+lIj9DXUkNobXhvBw Elqum3VfNsqGOFcqaYhsgJAXRMPLG4QWYdsOChzZtcN0ZtyHvDcpMX9D/tDODdKSjfqG0FAN0htq FpEoPrVPRv2C4C3G79d+0WCqIKEm/Jh/+GySX/3GzA+8ZYbsTS7+Bv9BGpjeIbvF3yzfxGkG9GvH 5D6hvhRD8xXagRvyelHAFvHBF8FEO++BObZWZRdiF2eSc6c3+SGJNzIqA84NB7YqI2Qih9YqQWaE RZNdFTDgVQSY5odYIwTIqo2FUwP7XYEJxAv9d7Hrm9D8HC3C628Uyf6xLt8Y8/sJ7OE+/fy4a6wi B3aVk1cx1zS7VCGvbifyRlCkZ6kVqJ3x1xyu0N8IdJg3144o7tMO4e4AjIYBvyk8owf4zzrC8FEm i+T2RSV7Qh0ljb3Uy7Qpi9ok2XZ0pkSH/Zmmz8qmNiUv8Akj11MedpZO5BdNn+yIgEuMMggTaU91 J6KlEoJyrUfwHiUnGpTl1ePsQmLMLq7Q9h11OjuUzc8qhE9eUC/yR8j7nmOIf/Abd/3dHfwp5+Xh WJcf0SLOJnrusB/FS5rj0nUtvb+jQx22Mgkr0yTqW57BGPcjSXnbMl+lj3oEx0fgGK2oi3GZT1qS ZQvExlkiT9tS7S/epY7SecrsKt0+bQrq+v3y/Ini8PIVHKQx/hTvgl/6I/Gfz9/P65w/xqFCe7kK rkRf8J/6xeDkSnj0n9Kd+AvBP9zRu/epS3dJb7Yd2Q77i/q8rfPEg+ka4FXlbltXtbJX/lqp38Cn HP/Eq7+EPT+xPwH7fxK7ntav//iWcpDH+E/vt/LfQ+b/11O5Db7+Gs8hPulq1TXdFGeQshA1uMy4 2DiF3Xc7xD3vDMTERFyiP/jsAQsHQQAARAEH54tnq90XCIyiZExFdKRJcVRmDbn29oXFQJkuVEuy PhoD1fzNcrRRHbuYiD87QJBliOngEv03V8RERIxDODZzPL2vzxuXIc538NV6fLwKTOk51WsOlQiI h3E8Zt4uh5NtueIiWBHxa1URUD4uUSzt5bchnRVONF7PVu0nKijjuC1qpKKPiSRrtJMWc7d6XVHt hTamVr6otsRVF+O3iT1XI3mkLSdPQclCYwrP5HO7JqpRqezrTasIk9uANq5WeqYTKmqIjSqZHhtY Qte45XPE0bzZWerKG1kpEo2eMbGlP2KW8c3nCtGr0za0URpOasmtlIvldfNabXCs9XxG10plHvKi W1NrxXymQfYbX2DnK6lUSGwCLacntwcjLCRzpcTvKlBc+u2c+HsUfK/srKwWHAt3DFcuViZNJK0I iNKjlmXbSxUpfZ8yG1HIgtkibHlIs9kgba+MlUHQEeqdIHS7bF8+QieCh6ZGaPY5hEMgeaO78UNt Rmju7JDbkZo7tcTInVU5TRk4huSKPX4pNzOj+Zz0TZI6PXqyZM6PX8xModHrkk5opxGa/dvDf5lm v3VVJLukZr90cu/0RmfdbycoeZ90uT3Z5n3TBMQ/IcuX0TxnfL9n0yRMSXHcF6X7u/NqBccrWl5Z rQuOV2a9g2olnyGQa82KD09u5NqRcHs35sWXB7OcQ1NHCNlkNqhZn3XM3mlSqIRs6tDGFwezDm1U uD2ZI2rFweydNq5Zn3Z01qiI2+qhrBcHs903my4PZANrJcHs/A2NLM+6qc+RzhyLPZXTa0XB7OjN rZcHstxtcLg9l3NrpZn7clygecnpsZ8hzPCdzyWaIh4mDT3S+36W7/z7GtwODO2vl8sdPb+I6jY+ 6G8CRbP3mSxZ38vq8D4UGjjuKf68dB6ZbC9H+32IbGWKCO6hjj+ns+h8qd4SxQiLZbjsnvUQvK++ 45kTkO9L/qm3zPe6RfICdw+1E+ssi4gtvgFcSW3MFfIcJER4+LCkCx7HxXFlt+0rrRbfJK35bc3C RuPxFZ9pv4H69aFF8invkMJoi5PuPH1i5PuPHTFyfcePtFz+xUr3T5alsW6Jfya0uXq3Kq5f6Pla IRrsBeokteuL00LXseXLNbQ/TUtfyl6WaFq3BYRZas1XS54/Dt/qGrfea5pHL0tdYbF5NRy5Mnnl bZtyuw35MrJiIhfZ9nKFaH005XFtOPoKioiw3uvpc1PID9UviG/6yOX9RPKRODr8AXj+5lG/ZH5v EeXgFjyG2eWfaSSKhs0KO5fmrli2LTWSxclprxYvS0sdRWcQW+ATVlRbQx4mzN58TmPp2P1Nb5E6 jI0We0FlP1FoXD2rFlYM2VR82Nz0JZRs2sXWZxxVbYkvuUCdrA+Jk61NU65vsUs+gbwRXNEVomxC 2CUGfoeZ7Iv0WxnnRDh3AnnizhrAwugavH3LWJX+abEI+papuZ5+X9h8Os0uB+TUTHobjI5OU7fL +tc/k8ae5a181/9Ldr7/zPZF/O4Db5rr8e0VgJ2jtpRdb5lfc+RgVj8XM7tWPH+ybQP/d3Zo/H/v l+mnsE33aWQrz+4g3vWkG+L4bQWCwjUVGnaE3Z2NOo2D6N69poWbljFdg4iUZUFfKtLBx6JnFNpg rfk2Cvwv0ao4JObp+PRdMV3+C0wcn9DS2MOpTvsC3viWYcZAd0MwPKHqDUjYj6BvBFd+RWibELYJ QXwYcZAd0MwPKHqDUjYj6BvBFTqYxtiFsEoL4MOMgO6GYHlD1BqRsR9A3givANNsQtglBfBhxkB3 QzA8oeoNSNiPoG8EV4JptiFsEoL4MOMgO6GYCdCzotNRo/0cFzPKXjmeyAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABfa0H0tG/hWypt/C Sz9kPHe/FJ5gux8p3eY8R9iVyys33U6fT6j2+F/d/ukfX4FIPtMr5tSW8FIOArmpXTaQ+3Coc5t7 hFtwxGgMY1sppI7ebpBhUtwol9ZdrTtSYGUHnCxUUVFRyt+8yUZUy+wiCSaEllO4CU8zuui05KXd Eb/f8SM6WPPV+osB1SZRN1ld4fev4MRQ2Yr6MN2To960byUzBi7c2F7xtxQwYOHDqPpv1lfvsO67 /Jkh7nC8RqFxUO5g4ZS2a94xedzEwRr97kGSJbWTx1LRCuYTJUZQOYSL/LU83Sv4jjfeV/FttFmt LhP69C2i22mzMfzrp+T/fhGsy3M9kAX+BzPKDg/98vo/s3Ej6TyczsXreF/lpWMGmbo3PNxckl/4 nqEKb6Xqa1C3WTZVDm9fp9PCd2BO7dqdqzZLyyoZBDOP6T6IrOBEtIMOz749s8u8p/neLj/ry0SS ymMGGc9729dgqh3HRVNjPQ41vJ7iTT3ird60sl5ncNFt1EyOjT3iykveEf7xdizHMZkqZdRAg5/r jnUz8mfeF1mLjEtwpsurM5lDJ93zrGkHnk0GwnN1hiNuku4cZTay3L6j/rF/Y/ua7cpvlZT39Pp9 3PlWhs3ELdW2qxR9D5VDqD5f31+zO++VUdngoot/0XwkblGVMpTC7CSxxr75aNv75VsPf4+uypMo mh522/vr5R2uC2wIlddTKO9pNcpzXHU5riyyiX9BsjrKa4sMprhi1O9edHN1r4NdDiOdyaf0tQkZ TNHrqaaqziZVpcLEVOdcWW7QoijEapXS7/vw67UtEVvCzh52kjTkfryyVNW77aLb6KxU9Ry8X6Tm vLKa16Oz3YC9KmXsUv89r16zaYfVJZnhCmyEpdCUcpTW9TQbYVmsMRoxmd0ISHmzda+CShveLhb/ 9BSXM9kX1e33H7tbyOhxUah9KpN4tNYJrYoqX6Mio1fg1LlK6pBI2dK/kTZDe63AxiOkKMqHUHzv uL9kvsiqS2RYKKRB9Muxy4mZljlxWd3RXLjRm2OXHrCXRXLkph0smBjBiSFSMqNO7GCoZeHFGURR iB0kE2hJZTt/seTqSy+yKpzZF2Kk3yHnl9kWWw2Q1GyLs2jK50pE03UberbFch3ClE2JqRodBt5W 4anMqw7D/zbKnpXZlW9S329crB+oSkVB9ulmWY4rNfgr5mqS/2hqhVYMWoquN/SZKs7wOjXij2um /v1RYl2z4/NVL40yoWcs9mNmNnyO7FS5eCxjwDMbt8dq4Vxl5ivorDdndzW/NKzVS52x8okb6mQ/ 659XIfoxLUp/ZKBTXYHKXcrA5DdkgyuXiSCpmhM41HVXYRTfabbT6em/Qn5UljYEGpmZ+H9Pnsb+ ucb8pioNT/E9dFMS6rJizC7uPFqLPMzO/e5SG24gc1tqenQ2POC2odhxgfjsmTsHkSP7CzLtl90V +6R1NwdM8kwXtoU1f9t4ab+MiN+MqkPlpB6n0LJFn3Kh1B87p0dmX+MqnPjLBRRY//GliJjoR8p2 4TDxPJFHW2DvYFScx+s77o0D324MGvFJSiZeW/5qajrazVaaQqB7340VNfOQiKMI5VE1S76386iw QZ99/lWG0SYfm0skNomNoo1vowqXfemj+dli+cb53b8P9eoOmq2w+UsFQdNyKN5Yr0haJjVUfdRU XbFKzuCMHKq5DEIR1URUHGfPTEqqyhSTMbVHcqk8qDqDIdTMYmLmV3cQFxbkGUPUbVfIRH/IVdsm +Z5tRq8Ucb4DiB51mclNqh1HNhKwaKryFoyjbf5INRth8hYInjsxq9DWKqDHzMTLH26hkal9+v6p o5flnAR4oypik5aGmrtmegdD56uNqlHbVFRu1Gd6utt5Xa01/6+JV93W1OlN6hlXnZ6Lh9XQF1m1 g1DdV6qDnoO8KlKs5klB2ihkszO3g5izCfCW8WmJYFlc+rm52sEheLzfE8Ofe5G0SVoVG9BMHm0x NGm3uG0tZYfqvg0NQgk0sllOt1ynoJkxVGF4pnx+14UZXekZv/bUtO2K9sWShtFcjK70hZ7YbYbb j81SIiZbq62vxnttTdQdNmyAVDrNlqXsGplS7yHDpEzyZrY+RrLBMqZtmmN+X9yIrcU01b/bFShy s21X+esMHdTxgfLdlxJ1O82z0HOM9/K4UXPfIrMGujWmuLWVnP6rN7z0NnYg8KzZQ6yEwkqYvlYY ztRCrBobOwfRipTSCoNf+drTeFU7Rk7LbRFKP/lf8+Eqh9536NPp2M7aycL3KY2h56opwONMW9Yk fbrBtB00NZlpDZslIbd9LBjHN39C6/g3Ffz6Wot4RCOZYpVzFUoYl7tng3OPO1ib6ZUZN5jp2OU8 Dw9e0Tynjmd3rVSwvx/2R6P0wVzW+Iaxcsx/RjEqDjtyvgvzLoVA9n8q9S6Yy8iUYqiZ5D62rRVj jKtT1PTtYi67+NVb0VXQMGk02i0sm4Y8/iGrP+DBVPvi/Km1JUH7uPaEahdKHPJVj/JpTGIQdolG iIFYYI8W9I/WqvmFebJJqU9Ron9eE1hhqwQqpLJpu1HotKuVSCEHUu6udlC5FtWrH+DKpip+GquV GRR8s1gkFSrUbmDaRRGLf1ViVvY3dG72JgyxgZJmFKlUkoHBKRtExIn8YreISVma1VRqzF45pDZr H/21vipprwo1z3UQcJw+kv1RHsSvT+IL4KLQp23vzwbYKqxPJg26bJeFXoJqHlSxKiJxTIylnMkq mVo5TlhkQxMFFEK+EXyp9r9rpqK43L5K3Vm8I8opMGvnFMN3kfBDz26Z6BqTX63rm4Tn4i4miosW kWHTlKC2VpqzCuvN26vu6SWH+ieTW8wmKD99b6ywsVZLMVaIMZQyqAbpqhm7tBWUpUzO8F5CUu6/ BzNmVDwflcHTWNaxbOHPjRJV1Ic+g0CUl8l27l62wqSmuvcp6kWG6Fz1DrYtvGc2eUvuBl9wJxlK tG3aN4WYKbY5Q/yparpLTj2DFU/VS86NMdhalVm7iv8Wt5YYM+Zv20F1qR1fSeBz8HkzfMYAUJLd cjv5U/iKn9A+fnG//EskOQDKqt0yVWKrczwUypYp/b2bFSqW2lDVeKevcKuTtSuj+Oq+gqaJrO2w 2a6qx2c9Jo3iEqiUVuFsg2t4a5uLRGizHvsP5S0Yhld0ctTKofs2OVaLjTUh9JVYWcwkKTKSoV9K CrWCqNOMrZp1joZU6741lfyanx2kdWW8qkbH+TRmolxqEtCK0v3dx0LsDl5MJg96lGac90LeFemV dul9FBu5lEV5x1smtMhZv0oXKp0jk5G9jFt1SGQoKP9FZOIX+FssfNKqtCtlYSuQ3IZ6kpXU7Zu2 VNhilzKNKzMaL8K2xEhWyhJ03uTtip7hOKm+cYDr85k3R5yst86ze9RzB5Acy8znPRrem+ZFxxVp Y1NrdGzQSRofuLyrVPH9JPZpD31txH3r7hvKPlfK8dhEwaoyhN6bi5ij9omvZQ1/SxUOpQKqqKUl 3/O9C3h1EKUKoO29XomGKPKVtZljK4luO6CssK6obDSXj0KlqUNgg3013TnhcJQsykp+lxE3rH9F D0H4RGQpWieSdMBnkeQcNYtZpBf+6m/2zvb010rtbx9zRXU7qb9IrYTdxZH20p+AWOLbq/D+tEq3 n/4ui/RUi1kZWFbxlyklEhTspYs2l+9r8GVLeVRvCQnfk1rkU3lLWmCdAyQVGmawRs/TVyL8+LXo N62wJixi7o0h/PsFZ5MRniteKJlTJD3j63KQcr5DSLh4yf8A4aGynk0As1gmr79RHZ5qkfCPKByv 1UyhGvkM2qsLVgcclPsTatT925NEsz3Ku6HJ6gGdNmPrpDv6tBu/Qks3TB9C+g3SFB5Xy+G+sTmL VBRnpYN5CI99AoHEs9mNEMcvZDxMHIJY2rdRpcyZpEcudR9QEoTngJItPeysUsa7flkqHUHy/pIw dvyugC7CiKKLL/Hk//CQZeTPoQZphHyozig4/qPlGVCbCgg9GLUQx6F1h2l/nSfUTI6bCgp+d6N+ sNPrPFlZ0+mD2aWQA5/tW27dmgJr64Moc8Y/dk933sGpY+kKloQk/FVFiRnS7hWYOJY+8EGkmPvB AXRLd6SzsBjx/QbUfWN6In7SKyS2FnFwEmL0MEMUO3HijyRCUlHvU01S8jPsLdwqa0uAmyplEplS WY/4TQ/7Mk3Sy1lwa0vJ3rqbhNzWGx2LWlJd1gnUje73db5J4LqbzJSdw62Tva1ylrzc7vRlfuHb ut1MjdZa4J+TKmLweImbPjsbjZpP/Hc9UZ4/CYjGW6zsfhWDd/dK5pXHYYPF4bH03L9PumHQX7D5 RfKnK17lZOWlrgp1Z+vx8wtK3nqeKBBPx1d74uNwYc0aXuXl+tdUcQfvNZ/4u94krzR5ST/U6ZWQ w4Pi93OVYgE4N4kl/y18ItHF96ySgyeJrFvFv1pul4kepk4Jf10vV56t1cOzmKTsywb5cKf+tPZa 9SfU3mXk2AdptFps1pj5CzWxN6PvEeWk5K6y6UDIYhMz3dEpd4vG47//jifXzzPZAAAAAAAF/xKK XjmveyUc2dfi5lzIlbsqh30xG6NO8s/br/T36uDOsh40sr6XqYhuq0T3gfn/8sQ9ewBABwA= ------_=_NextPart_001_01C92480.2901E19D-- From remko at elvandar.org Thu Oct 2 12:30:03 2008 From: remko at elvandar.org (Remko Lodder) Date: Thu Oct 2 12:30:10 2008 Subject: bin/127719: arp: Segmentation fault (core dumped) In-Reply-To: <200810021140.m92Be4Dw018958@freefall.freebsd.org> References: <200810021140.m92Be4Dw018958@freefall.freebsd.org> Message-ID: Hmm the content seems to have been obfuscated, can you perhaps place it online somewhere? or send it over to me so that I can bring it up somewhere? compressing it using tar and gzip or tar and bzip is preferred for me... Thanks remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From bms at FreeBSD.org Thu Oct 2 12:46:23 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Oct 2 12:46:29 2008 Subject: Freeing an mbuf cluster In-Reply-To: <20def4870810020216x31f9c0d8yd4776622928c412e@mail.gmail.com> References: <20def4870810020216x31f9c0d8yd4776622928c412e@mail.gmail.com> Message-ID: <48E4C29D.1020200@FreeBSD.org> Yony Yossef wrote: > Hi All, > > I'm trying to manually build an mbuf chain with clusters in various sizes. > I'm doing it using the MGETHDR and MEXTADD macros, it works fine. > Now I'm looking for the simplest way to free an mbuf cluster, since I want > to free the clusters seperately. This function will be given as a parameter > to MEXTADD. > > Is there a simple command like 'free(buf)' to free an mbuf cluster? > You don't specify if you are trying to add the external storage from a pool you manage, in which case, you're on your own. m_free() for a cluster or mbuf should just "do the right thing". Since the UMA cleanup there are destructor functions which should free the mbuf or cluster using the right pool. m_freem() works on chains, of course. cheers BMS From rea-fbsd at codelabs.ru Thu Oct 2 14:43:02 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Oct 2 14:43:14 2008 Subject: bin/127719: arp: Segmentation fault (core dumped) In-Reply-To: References: <200810021140.m92Be4Dw018958@freefall.freebsd.org> Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081002/46719bfd/attachment-0001.pgp From linimon at FreeBSD.org Fri Oct 3 14:44:31 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Oct 3 14:44:38 2008 Subject: kern/127815: [gif] [patch] if_gif does not set vlan attributes from EtherIP encapsulated 802.1 packets Message-ID: <200810031444.m93EiUEE086191@freefall.freebsd.org> Old Synopsis: if_gif does not set vlan attributes from EtherIP encapsulated 802.1 packets New Synopsis: [gif] [patch] if_gif does not set vlan attributes from EtherIP encapsulated 802.1 packets Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 3 14:44:00 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127815 From linimon at FreeBSD.org Fri Oct 3 18:07:25 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Oct 3 18:07:37 2008 Subject: kern/127826: [iwi] iwi0 driver has reduced performance and connection strength [regression] Message-ID: <200810031807.m93I7Pbb001723@freefall.freebsd.org> Old Synopsis: iwi0 driver has reduced performance and connection strength New Synopsis: [iwi] iwi0 driver has reduced performance and connection strength [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 3 18:06:52 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127826 From scottl at samsco.org Fri Oct 3 20:19:32 2008 From: scottl at samsco.org (Scott Long) Date: Fri Oct 3 20:19:39 2008 Subject: potential nasty bug in igb and ixgbe In-Reply-To: <2a41acea0810011516u77ca05b1k2df527e453dfe392@mail.gmail.com> References: <2a41acea0810011516u77ca05b1k2df527e453dfe392@mail.gmail.com> Message-ID: <20081003135625.C39726@pooker.samsco.org> I'll bite. Scott On Wed, 1 Oct 2008, Jack Vogel wrote: > Jeff Roberson uncovered an issue that might be behind any number of > possible problems. > > Our newer hardware (meaning those supported by the igb and ixgbe > drivers) overwrites the buffer address in the RX > descriptor with a variety of data in support of advanced features (see > the relevant header files for details). > > However, in the rxeof code, if you fail to get a new mbuf, and hence, > will discard, the descriptor is being left in the wb form, > meaning that the address is jibberish for the next time the engine > uses that descriptor. > > I am modifying get_buf so that it fixes the address in the descriptor > when this happens. I know when my test group has had > the igb driver under heavy load they have had some panics, right now > I'm not sure if this has been at the root of those or not. > > If you want to see how I'm changing the code just speak up :) And > thanks for finding this Jeff. > > Jack > From neff_glen at emc.com Fri Oct 3 21:46:11 2008 From: neff_glen at emc.com (Glen R. J. Neff) Date: Fri Oct 3 21:46:41 2008 Subject: IPv6 support for yp/NIS Message-ID: <1223069512.21019.24.camel@gneffpc.nas-v6.rtp.dg.com> I find myself in one hell of a conundrum. I need an NIS server that supports IPv6. I initially tried with FreeBSD but found that every piece of the yp suite supported IPv6 except ypserv. Then someone told me that NetBSD's ypserv supported it, so I gave it a try, and they're right, it does! But you know what, in the case of NetBSD, every piece of the yp suite supports IPv6 except ypbind. This is maddening! How can both of these projects have non-overlapping holes in their yp suites like this? Here's some console & sockstat output to show what I'm talking about: http://pastebin.ca/1218428 Thanks, -G -- /* * Glen R. J. Neff * RTP TSG Network Team * neff_glen@emc.com * * EMC^2 == E^2 */ From linimon at FreeBSD.org Fri Oct 3 23:33:55 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Oct 3 23:34:06 2008 Subject: kern/127834: [ixgbe] [patch] wrong error counting Message-ID: <200810032333.m93NXsOc030049@freefall.freebsd.org> Synopsis: [ixgbe] [patch] wrong error counting Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 3 23:33:42 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127834 From ivoras at freebsd.org Sat Oct 4 01:58:05 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Oct 4 01:58:12 2008 Subject: Network IO & scheduling problem? (was: Optimizing for high PPS, Intel NICs) In-Reply-To: References: Message-ID: I experimented some more with my problem and it would be pretty incredible if it weren't for the fact that I can reliably reproduce it. Excuse me if this description is overly verbose, I can't decide which information might be important. First, here's some more background on the problem: The application (not created for the purpose of being a benchmark) accepts TCP connections and assigns them into one of predefined connection groups, configured at serve startup. Each connection group is polled for network IO events by its own thread. There are no overlaps between these groups. This polling can be done by either kqueue() or poll(). The client application is a stress test application that creates 40+ parallel, long lived TCP connections and tries to saturate the server with queries (so, for example with 40 client connections and 4 connection groups on the server, each kqueue or poll list has 10 entries). For testing purposes, the server doesn't actually do any useful work so the emphasis is on network IO. The server hardware is 2x quad Xeon 5405, 8 cores total, running FreeBSD 8-CURRENT amd64 (debugging options turned off). The client system actually doesn't matter, I've tested with many systems, including desktops and laptops with different NICs. The problem is: a) When IO polling on the server is done with kqueues, one kqueue per thread / connection group, I can create up to 3 threads / connection groups without any problems. When I create 4 threads, suddenly the em1 taskq thread starts eating 100% CPU. With 3 or less threads, em taskq spends less than 1% CPU time. At this point I can push 150,000 packets in each direction. b) When polling with poll(), I can create up to 4 server threads without saturating the em taskq, but at 4 threads it starts to spend high random amounts of CPU time, from 30% to 80%. At 5 or more threads it's pinned to 100%. With 4 threads I can push 170,000 packets per direction. With 3 or less threads the em taskq seems to spike in CPU usage right at the start when clients connect and then goes to < 1% CPU time. c) It looks like the effect is much less pronounced on a 4-core machine. I don't have it now but previous tests showed em taskq at 10% with 5 threads and kqueue polling. Some things I tried: disabling TSO doesn't help, disabling PREEMPTION doesn't help, it's not an interrupt storm, the taskq thread doesn't seem to jump all over cpu cores, BUT the amount of context switches rises sharply from ~~12,000 with 3 threads to ~~65,000 with 4 threads to ~~220,000 with 5 threads. Interrupt rate varies between 1000 and 3000 (interrupt moderation by the NIC?). I'm looking for ideas that can explain all this, and also for guidance on how to instrument the kernel to find out what is happening here. Fixes would also be welcome :) From vwe at FreeBSD.org Sun Oct 5 19:05:18 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun Oct 5 19:05:24 2008 Subject: kern/126924: [an] [patch] printf -> device_printf and simplify probe Message-ID: <200810051905.m95J5Ile018989@freefall.freebsd.org> Synopsis: [an] [patch] printf -> device_printf and simplify probe Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Oct 5 19:04:54 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126924 From linimon at FreeBSD.org Mon Oct 6 04:10:08 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Oct 6 04:10:19 2008 Subject: kern/127888: [ip6] [panic] kernel trap freebsd6.3p2 Message-ID: <200810060410.m964A7qB060570@freefall.freebsd.org> Old Synopsis: kernel trap freebsd6.3p2 New Synopsis: [ip6] [panic] kernel trap freebsd6.3p2 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 6 04:09:26 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127888 From rfrench at freebsd.org Mon Oct 6 04:51:39 2008 From: rfrench at freebsd.org (Ryan French) Date: Mon Oct 6 04:52:13 2008 Subject: Getting packets MAC source address in if_ethersubr.c Message-ID: <200810061730.23641.rfrench@freebsd.org> Hi All, For my implementation of MPLS I have just about run out of time for my dissertation so at the moment I am trying to create fake routing table entries e.t.c. rather than doing this properly (I will be doing this once uni is finished and I have more free time to work on it). I now have receiving, decoding and sending of packets working, except for one small problem. When I send a packet back out the MAC address is wrong. I am looking for a way in the ether_output function in if_ethersubr.c that I can get the MAC address of the source of the packet and then just send it back to that source. If anyone knows how to do this without having to use arpresolve or anything like that (the IP address of the destination is not going to be the same as the IP destination in the packet) or without having to setup a proper routing table then it would be much appreciated. Thanks, -Ryan From rea-fbsd at codelabs.ru Mon Oct 6 05:56:29 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Oct 6 05:56:36 2008 Subject: Getting packets MAC source address in if_ethersubr.c In-Reply-To: <200810061730.23641.rfrench@freebsd.org> References: <200810061730.23641.rfrench@freebsd.org> Message-ID: Ryan, good day. Mon, Oct 06, 2008 at 05:30:23PM +1300, Ryan French wrote: > I now have receiving, > decoding and sending of packets working, except for one small problem. When I > send a packet back out the MAC address is wrong. I am looking for a way in > the ether_output function in if_ethersubr.c that I can get the MAC address of > the source of the packet and then just send it back to that source. Do you mean by 'the source of the packet' the MAC address of the incoming packet to what you're sending a reply packet? If you can somehow "remember" the MAC address of the packet you're replying to (don't know about internals of your application, so can't judge if it is feasible), you can try to look at the sys/net/if_bridge.c (bridge_enqueue at the first place and bridge_input as the example on how to manipulate the Ethernet header). These might help you, unless you're not using Ethernet as the transport. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081006/23bf38d1/attachment.pgp From julian at elischer.org Mon Oct 6 06:04:55 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 6 06:05:02 2008 Subject: Getting packets MAC source address in if_ethersubr.c In-Reply-To: <200810061730.23641.rfrench@freebsd.org> References: <200810061730.23641.rfrench@freebsd.org> Message-ID: <48E9AA84.90804@elischer.org> Ryan French wrote: > Hi All, > > For my implementation of MPLS I have just about run out of time for my > dissertation so at the moment I am trying to create fake routing table > entries e.t.c. rather than doing this properly (I will be doing this once uni > is finished and I have more free time to work on it). I now have receiving, > decoding and sending of packets working, except for one small problem. When I > send a packet back out the MAC address is wrong. I am looking for a way in > the ether_output function in if_ethersubr.c that I can get the MAC address of > the source of the packet and then just send it back to that source. If anyone > knows how to do this without having to use arpresolve or anything like that > (the IP address of the destination is not going to be the same as the IP > destination in the packet) or without having to setup a proper routing table > then it would be much appreciated. > > Thanks, > -Ryan > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" You could create a tag type that holds a layer 2 address, and attach it to the packet on ingresss, it should stay with the packet as long as it's not destroyed.. then on egress you could find it and use it.. From bugmaster at FreeBSD.org Mon Oct 6 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 6 11:08:29 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200810061106.m96B6wER035551@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127888 net [ip6] [panic] kernel trap freebsd6.3p2 o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 183 problems total. From gleb.kurtsou at gmail.com Mon Oct 6 11:48:21 2008 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Mon Oct 6 11:48:28 2008 Subject: Getting packets MAC source address in if_ethersubr.c In-Reply-To: <48E9AA84.90804@elischer.org> References: <200810061730.23641.rfrench@freebsd.org> <48E9AA84.90804@elischer.org> Message-ID: <20081006114814.GB3497@rybacik> On (06/10/2008 14:04), Julian Elischer wrote: > Ryan French wrote: > > Hi All, > > > > For my implementation of MPLS I have just about run out of time for my > > dissertation so at the moment I am trying to create fake routing table > > entries e.t.c. rather than doing this properly (I will be doing this once uni > > is finished and I have more free time to work on it). I now have receiving, > > decoding and sending of packets working, except for one small problem. When I > > send a packet back out the MAC address is wrong. I am looking for a way in > > the ether_output function in if_ethersubr.c that I can get the MAC address of > > the source of the packet and then just send it back to that source. If anyone > > knows how to do this without having to use arpresolve or anything like that > > (the IP address of the destination is not going to be the same as the IP > > destination in the packet) or without having to setup a proper routing table > > then it would be much appreciated. > > > > Thanks, > > -Ryan > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > You could create a tag type that holds a layer 2 address, and attach > it to the packet on ingresss, > > it should stay with the packet as long as it's not destroyed.. > then on egress you could find it and use it.. That's exactly what I did for Google Summer Of Code project this year http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering Ryan, you can have a look at first changesets in perforce and extract only functionality you need. From vwe at FreeBSD.org Mon Oct 6 17:44:34 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Mon Oct 6 17:44:41 2008 Subject: kern/127888: [ip6] [panic] kernel trap freebsd6.3p2 Message-ID: <200810061744.m96HiYgg070422@freefall.freebsd.org> Synopsis: [ip6] [panic] kernel trap freebsd6.3p2 State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Mon Oct 6 17:38:30 UTC 2008 State-Changed-Why: Wouter, by knowing your setup, I wildly guess it's again stf related (the instruction pointer suggests that). Again, we need to do the same procedure as we did last weekend. Please use all my information, how to load the KLD's into kgdb, get a backtrace, inspect the sourcecode and the like, the same way. The manpages to asf(8), kldstat(8) and kgdb(1) are there to help you. Please report back to the backtrace, find the faulting frame (a stf call), do a list and attach all that to the PR. Please understand I do not find much time in the weekdays to respond quickly. Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Mon Oct 6 17:38:30 UTC 2008 Responsible-Changed-Why: grab http://www.freebsd.org/cgi/query-pr.cgi?pr=127888 From vwe at FreeBSD.org Mon Oct 6 21:33:48 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Mon Oct 6 21:33:55 2008 Subject: kern/123858: [stf] [patch] stf not usable behind a NAT Message-ID: <200810062133.m96LXmkt088505@freefall.freebsd.org> Synopsis: [stf] [patch] stf not usable behind a NAT Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Mon Oct 6 21:33:23 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123858 From qj at huawei.com Tue Oct 7 11:54:11 2008 From: qj at huawei.com (=?gb2312?B?x/G9ow==?=) Date: Tue Oct 7 11:54:25 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. Message-ID: <004001c92871$fdec0a10$01000001@china.huawei.com> Hi, folks, I did kernel profiling when a single thread client sends UDP packets to a single thread server on the same machine. In the output kernel profile, the first few kernel functions that consumes the most CPU time are listed below: granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 42.4 10.88 10.88 0 100.00% __mcount [1] 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic [9] 0.7 22.80 0.19 3145852 0.00 0.00 free [47] 0.6 22.96 0.15 6292172 0.00 0.00 uma_zfree_arg [52] 0.6 23.10 0.14 5243413 0.00 0.00 generic_bzero [53] 0.5 23.23 0.14 1048581 0.00 0.00 ip_output [23] 0.5 23.36 0.13 4221855 0.00 0.00 generic_bcopy [57] 0.4 23.47 0.11 36865859 0.00 0.00 critical_enter [61] 0.4 23.57 0.10 36865859 0.00 0.00 critical_exit [62] 0.4 23.67 0.09 17937541 0.00 0.00 spinlock_enter [63] 0.4 23.76 0.09 1048582 0.00 0.00 udp_input [21] 0.3 23.85 0.09 2108904 0.00 0.00 syscall [5] 0.3 23.93 0.08 1048587 0.00 0.00 ip_input [20] 0.3 24.00 0.07 2097156 0.00 0.00 getsock [65] 0.3 24.07 0.07 1048576 0.00 0.00 udp_send [22] It is very strange that spinlock_exit consumes over 36% CPU time while it seems a very simple function. For clarity, I paste the code of spinlock_exit here: void spinlock_exit(void) { struct thread *td; td = curthread; critical_exit(); td->td_md.md_spinlock_count--; if (td->td_md.md_spinlock_count == 0) intr_restore(td->td_md.md_saved_flags); } Since critical_exit consumes only 0.4% CPU time, does this mean the rest of spinlock_exit consume ~36% CPU time? Am I missing something? Could anybody help me understand this? Many thanks. BTW, the kernel is compiled with SMP and PREEMPTION disabled. The scheduler is ULE. Best regards, Qiu Jian From koitsu at FreeBSD.org Tue Oct 7 12:13:51 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Oct 7 12:14:03 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. In-Reply-To: <004001c92871$fdec0a10$01000001@china.huawei.com> References: <004001c92871$fdec0a10$01000001@china.huawei.com> Message-ID: <20081007115748.GA48154@icarus.home.lan> On Tue, Oct 07, 2008 at 07:44:00PM +0800, ???? wrote: > Hi, folks, > > I did kernel profiling when a single thread client sends UDP packets to a > single thread server on the same machine. > > In the output kernel profile, the first few kernel functions that consumes > the most CPU time are listed below: > > granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 seconds > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 42.4 10.88 10.88 0 100.00% __mcount [1] > 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] > 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] > 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] > 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] > 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] > 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] > 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic [9] > 0.7 22.80 0.19 3145852 0.00 0.00 free [47] > 0.6 22.96 0.15 6292172 0.00 0.00 uma_zfree_arg [52] > 0.6 23.10 0.14 5243413 0.00 0.00 generic_bzero [53] > 0.5 23.23 0.14 1048581 0.00 0.00 ip_output [23] > 0.5 23.36 0.13 4221855 0.00 0.00 generic_bcopy [57] > 0.4 23.47 0.11 36865859 0.00 0.00 critical_enter [61] > 0.4 23.57 0.10 36865859 0.00 0.00 critical_exit [62] > 0.4 23.67 0.09 17937541 0.00 0.00 spinlock_enter [63] > 0.4 23.76 0.09 1048582 0.00 0.00 udp_input [21] > 0.3 23.85 0.09 2108904 0.00 0.00 syscall [5] > 0.3 23.93 0.08 1048587 0.00 0.00 ip_input [20] > 0.3 24.00 0.07 2097156 0.00 0.00 getsock [65] > 0.3 24.07 0.07 1048576 0.00 0.00 udp_send [22] > > It is very strange that spinlock_exit consumes over 36% CPU time while it > seems a very simple function. > > For clarity, I paste the code of spinlock_exit here: > > void > spinlock_exit(void) > { > struct thread *td; > > td = curthread; > critical_exit(); > td->td_md.md_spinlock_count--; > if (td->td_md.md_spinlock_count == 0) > intr_restore(td->td_md.md_saved_flags); > } > > Since critical_exit consumes only 0.4% CPU time, does this mean the rest of > spinlock_exit consume ~36% CPU time? > > Am I missing something? Could anybody help me understand this? Many thanks. > > BTW, the kernel is compiled with SMP and PREEMPTION disabled. The scheduler > is ULE. What FreeBSD version, and what build date of the kernel? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From julian at elischer.org Tue Oct 7 13:28:07 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Oct 7 13:28:14 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. In-Reply-To: <004001c92871$fdec0a10$01000001@china.huawei.com> References: <004001c92871$fdec0a10$01000001@china.huawei.com> Message-ID: <48EB63E3.60604@elischer.org> ?? wrote: > Hi, folks, [...] spinlocks disable interrupts so the profiling interrupt is held off from the moment that the spinlock is entered to the moment it is exited, and all of that time is attributed to spinlock_exit(). so that this tells you that 3% of your time is spent under spinlocks which is a lot. as others have asked, "what version"? you should look up lock profiling to see WHICH lock is teh ine in question. From ganbold at micom.mng.net Tue Oct 7 13:29:55 2008 From: ganbold at micom.mng.net (Ganbold) Date: Tue Oct 7 13:30:03 2008 Subject: ipfw port lookup table patch for review In-Reply-To: <48DA1B65.8030106@micom.mng.net> References: <48DA1B65.8030106@micom.mng.net> Message-ID: <48EB6450.9050004@micom.mng.net> Hi, I have just made the patches that use arrays for port entries. It is under the same directory: http://people.freebsd.org/~ganbold/ipfw_port_table/ Array version (each array can have IPFW_TABLES_MAX entries): http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_array_unsorted/ List version is still at: http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_list_unsorted/ thanks, Ganbold Ganbold wrote: > Hi, > > I thought it might be useful to have port lookup table similar to > existing IP lookup table > in ipfw and I have made patch for that. > > The downside of the patch so far I'm seeing is the port entries are in > linked list > (no limitation yet, memory overhead), not sorted and it uses linear > search > to match (could be slow when lot of entries). > > Just after I've made the patch I saw > http://www.freebsd.org/cgi/query-pr.cgi?pr=121807&cat= . :( > > I agree with PR's reply however for small number of port entries I > thought > this functionality is quite useful. It gives benefit like no need to > modify existing rule, > adding/deleting port entries is easy. > > I did some small tests and it seems like working. > > Patches are at: > http://people.freebsd.org/~ganbold/ipfw_port_table/ > > The output of some usage samples is at: > http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_usage_sample.txt > > > Patches can be successfully applied to CURRENT. Didn't test RELENG_7 > due to > no RELENG_7 PC :) > Please let me know your thoughts. I'm happy to discuss to improve the > patch. > Correct me if I'm doing something wrong here. > > thanks, > > Ganbold > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From jhb at freebsd.org Tue Oct 7 14:04:17 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Oct 7 14:04:24 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. In-Reply-To: <004001c92871$fdec0a10$01000001@china.huawei.com> References: <004001c92871$fdec0a10$01000001@china.huawei.com> Message-ID: <200810070938.04673.jhb@freebsd.org> On Tuesday 07 October 2008 07:44:00 am ?? wrote: > Hi, folks, > > I did kernel profiling when a single thread client sends UDP packets to a > single thread server on the same machine. > > In the output kernel profile, the first few kernel functions that consumes > the most CPU time are listed below: > > granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 seconds > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 42.4 10.88 10.88 0 100.00% __mcount [1] > 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] > 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] > 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] > 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] > 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] > 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] > 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic [9] > > It is very strange that spinlock_exit consumes over 36% CPU time while it > seems a very simple function. It's because the intr_restore() re-enables interrupts and the resulting time spent executing the handlers for any pending interrupts are attributed to spinlock_exit(). -- John Baldwin From bms at incunabulum.net Tue Oct 7 19:09:14 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue Oct 7 19:09:21 2008 Subject: How to support an Ethernet PHY without ID registers? Message-ID: <48EBB3D6.600@incunabulum.net> Hi, I have been trying to get FreeBSD onto the Freecom FSG3 Storage Gateway. It is an xScale based ARM system. Whilst the npe(4) driver appears to attach, the PHY does not. It is a Realtel RTL8305SB switch chip in dual miibus mode. Unfortunately the RTL8305SB does not have ID registers. The RTL8305SC does, but it's a totally different chip. We do have a driver in the tree for the RTL8305SC, however these chips are different enough for this to cause problems. Is there any way I could for example force ukphy(4) to attach? Note: Because there are no ID registers, mii_phy_probe_gen() WILL NOT work. It looks like I'd have to override this by hacking if_npe.c itself. Can anyone clarify? cheers BMS From linimon at FreeBSD.org Tue Oct 7 20:57:12 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Oct 7 20:57:19 2008 Subject: kern/127928: [tcp] [patch] TCP bandwidth gets squeezed every time tcp_xmit_bandwidth_limit() kicks in Message-ID: <200810072057.m97KvC03035893@freefall.freebsd.org> Old Synopsis: The TCP bandwidth gets squeezed every time tcp_xmit_bandwidth_limit() kicks in New Synopsis: [tcp] [patch] TCP bandwidth gets squeezed every time tcp_xmit_bandwidth_limit() kicks in Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 7 20:55:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127928 From sepherosa at gmail.com Wed Oct 8 04:15:23 2008 From: sepherosa at gmail.com (Sepherosa Ziehau) Date: Wed Oct 8 04:15:30 2008 Subject: How to support an Ethernet PHY without ID registers? In-Reply-To: <48EBB3D6.600@incunabulum.net> References: <48EBB3D6.600@incunabulum.net> Message-ID: On Wed, Oct 8, 2008 at 3:09 AM, Bruce M Simpson wrote: > Hi, > > I have been trying to get FreeBSD onto the Freecom FSG3 Storage Gateway. > It is an xScale based ARM system. > > Whilst the npe(4) driver appears to attach, the PHY does not. It is a > Realtel RTL8305SB switch chip in dual miibus mode. Unfortunately the > RTL8305SB does not have ID registers. The RTL8305SC does, but it's a totally Are you sure you could read from BMSR? Return invalid value from BMSR is the usual cause of miibus attaching/probing failure. For ID1/ID2 reading, you could just fake some values in npe(4)'s miibus_readreg implementation. Best Regards, sephe -- Live Free or Die From qj at huawei.com Wed Oct 8 07:13:10 2008 From: qj at huawei.com (=?gb2312?B?x/G9ow==?=) Date: Wed Oct 8 07:13:33 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. In-Reply-To: <20081007115748.GA48154@icarus.home.lan> Message-ID: <000301c92915$1cd0ae60$01000001@china.huawei.com> Forgot to meantion that the test is based on FreeBSD kernel 7.0 2000807 snapshot. The kernel was compiled with a modified version of GENERIC configuration. With SMP and PREEMPTION disabled and kernel profiling enabled. -----Original Message----- From: Jeremy Chadwick [mailto:koitsu@FreeBSD.org] Sent: Tuesday, October 07, 2008 7:58 PM To: ???? Cc: freebsd-questions@freebsd.org; freebsd-net@FreeBSD.org; freebsd-threads@freebsd.org Subject: Re: kernel profiling: spinlock_exit consumes 36% CPU time. On Tue, Oct 07, 2008 at 07:44:00PM +0800, ???? wrote: > Hi, folks, > > I did kernel profiling when a single thread client sends UDP packets > to a single thread server on the same machine. > > In the output kernel profile, the first few kernel functions that > consumes the most CPU time are listed below: > > granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 > seconds > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 42.4 10.88 10.88 0 100.00% __mcount [1] > 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] > 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] > 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] > 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] > 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] > 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] > 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic [9] > 0.7 22.80 0.19 3145852 0.00 0.00 free [47] > 0.6 22.96 0.15 6292172 0.00 0.00 uma_zfree_arg [52] > 0.6 23.10 0.14 5243413 0.00 0.00 generic_bzero [53] > 0.5 23.23 0.14 1048581 0.00 0.00 ip_output [23] > 0.5 23.36 0.13 4221855 0.00 0.00 generic_bcopy [57] > 0.4 23.47 0.11 36865859 0.00 0.00 critical_enter [61] > 0.4 23.57 0.10 36865859 0.00 0.00 critical_exit [62] > 0.4 23.67 0.09 17937541 0.00 0.00 spinlock_enter [63] > 0.4 23.76 0.09 1048582 0.00 0.00 udp_input [21] > 0.3 23.85 0.09 2108904 0.00 0.00 syscall [5] > 0.3 23.93 0.08 1048587 0.00 0.00 ip_input [20] > 0.3 24.00 0.07 2097156 0.00 0.00 getsock [65] > 0.3 24.07 0.07 1048576 0.00 0.00 udp_send [22] > > It is very strange that spinlock_exit consumes over 36% CPU time while > it seems a very simple function. > > For clarity, I paste the code of spinlock_exit here: > > void > spinlock_exit(void) > { > struct thread *td; > > td = curthread; > critical_exit(); > td->td_md.md_spinlock_count--; > if (td->td_md.md_spinlock_count == 0) > intr_restore(td->td_md.md_saved_flags); > } > > Since critical_exit consumes only 0.4% CPU time, does this mean the > rest of spinlock_exit consume ~36% CPU time? > > Am I missing something? Could anybody help me understand this? Many thanks. > > BTW, the kernel is compiled with SMP and PREEMPTION disabled. The > scheduler is ULE. What FreeBSD version, and what build date of the kernel? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jhugo at meraka.csir.co.za Wed Oct 8 13:47:45 2008 From: jhugo at meraka.csir.co.za (Johann Hugo) Date: Wed Oct 8 13:47:53 2008 Subject: "route flush" does not delete routes created with -interface option Message-ID: <200810081547.43450.jhugo@meraka.csir.co.za> Is there a way to get rid of all the routes in a routing table ? This is more or less what I do: route add 146.64.80.0/24 192.168.0.100 route add 146.141.0.0 -interface tun1 route add 146.182.0.0 -interface tun1 route add 146.230.0.0 -interface tun1 netstat -rn inet 146.64.80.0/24 192.168.0.100 UGS 0 0 sis0 146.141.0.0/16 tun1 US 0 0 tun1 146.182.0.0/16 tun1 US 0 0 tun1 146.230.0.0/16 tun1 US 0 0 tun1 If I do "route -n flush -inet" then it does not delete the routes created with a -interface option. see verbose output: route -vn flush -inet RTM_GET: Report Metrics: len 204, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.64.80.0 192.168.0.100 (255) ffff ffff ff sis0:0.0.24.c7.8b.80 192.168.0.44 RTM_DELETE: Delete Route: len 204, pid: 0, seq 2, errno 0, flags: locks: inits: sockaddrs: 146.64.80.0 192.168.0.100 (255) ffff ffff ff sis0:0.0.24.c7.8b.80 192.168.0.44 RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.141.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.182.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.230.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za uname -a FreeBSD groenwifi.cids.org.za 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #19: Tue Aug 26 13:40:13 UTC 2008 From killing at multiplay.co.uk Wed Oct 8 15:11:20 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Wed Oct 8 15:11:26 2008 Subject: EM and TSO References: <2a41acea0705161030k40831aa5o168b5bc40fcf3352@mail.gmail.com> <464B70F4.3010109@errno.com> Message-ID: <19BC920CEFA644B5896E89FFB00B81F6@multiplay.co.uk> Even on PCI-e devices this has some nasty side effects i.e. on a PFSence firewall box based on 7.0-RELEASE-p3 with TSO enabled, access via the public network to the web interface is almost impossible. Simply disabling TSO and all was good. This may not be strictly down to the HW or driver but is another reason to not enable it by default if it causes such poor performance. Regards Steve ----- Original Message ----- From: "Sam Leffler" To: "Jack Vogel" Cc: "freebsd-net" ; "FreeBSD Current" Sent: Wednesday, May 16, 2007 10:00 PM Subject: Re: EM and TSO > Jack Vogel wrote: >> I introduced a change yesterday that limited TSO to PCI Express >> adapters, I did this more for avoidance rather than a bug fix, and >> I'm not 100% sure its the right thing, so I thought I would poll >> everyone, do you have a PCI-X adapter and are using TSO without >> problems and wish to keep the support in? >> >> If no one is then I'll just leave it as is. > > It might be better to enable it by default on pci-e adapters and require > manual enable on other adapters that are capable but may not function > correctly. > > Sam > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From fazaeli at sepehrs.com Wed Oct 8 15:23:55 2008 From: fazaeli at sepehrs.com (H.fazaeli) Date: Wed Oct 8 15:24:02 2008 Subject: em(4) status Message-ID: <48ECCC0C.30208@sepehrs.com> Hi all and Jack Are the changes discussed in: http://lists.freebsd.org/pipermail/freebsd-net/2008-January/016584.html http://lists.freebsd.org/pipermail/freebsd-net/2007-August/014959.html incorporated into em(4)? If not, is there any near plans to do so? -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From jhb at freebsd.org Wed Oct 8 19:11:02 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 8 19:11:20 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. In-Reply-To: <000a01c9291a$b81fa560$01000001@china.huawei.com> References: <000a01c9291a$b81fa560$01000001@china.huawei.com> Message-ID: <200810081116.10298.jhb@freebsd.org> On Wednesday 08 October 2008 03:51:48 am ?? wrote: > Many thanks for the information. > > Could we say that interrupt handlers consumed ~36% execution time? > > Is this number too high? Is it possible that we abuse the use of critical > sections in kernel? I think whether or not it is high depends on the workload. -- John Baldwin From brde at optusnet.com.au Wed Oct 8 19:32:40 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Oct 8 19:32:53 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. In-Reply-To: <200810070938.04673.jhb@freebsd.org> References: <004001c92871$fdec0a10$01000001@china.huawei.com> <200810070938.04673.jhb@freebsd.org> Message-ID: <20081008210104.S20625@delplex.bde.org> On Tue, 7 Oct 2008, John Baldwin wrote: > On Tuesday 07 October 2008 07:44:00 am Çñ½£ wrote: >> Hi, folks, >> >> I did kernel profiling when a single thread client sends UDP packets to a >> single thread server on the same machine. >> >> In the output kernel profile, the first few kernel functions that consumes >> the most CPU time are listed below: >> >> granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 seconds >> >> % cumulative self self total >> time seconds seconds calls ms/call ms/call name >> 42.4 10.88 10.88 0 100.00% __mcount [1] >> 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] >> 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] >> 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] >> 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] >> 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] >> 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] >> 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic [9] >> >> It is very strange that spinlock_exit consumes over 36% CPU time while it >> seems a very simple function. > > It's because the intr_restore() re-enables interrupts and the resulting time > spent executing the handlers for any pending interrupts are attributed to > spinlock_exit(). This is one of many defects that are not present in high resolution kernel profiling (kgmon -B instead of kgmon -b; availaible on amd64 and i386). However, high resolution kernel profiling doesn't work right with SMP, and was completely broken by gcc-4. Ordinary profiling was less completely broken by gcc-4, and you can recover the old behaviour by turning off new optimizations (mainly -funit-at-a-time and/or -finline-functions-called-once and or all of -O2). Bruce From elias at artx.ru Thu Oct 9 21:49:26 2008 From: elias at artx.ru (Ilya Orehov) Date: Thu Oct 9 21:49:33 2008 Subject: duplicate vlan panic Message-ID: <20081009213006.GA98053@artx.ru> Hi! RELENG_7 from October,9 ( em card ) Also repeatable on another box with RELENG_7 from last Saturday. ( xl and nfe ) Boot single user or remount readonly. ifconfig vlan1 create vlan 1 vlandev xl0 ifconfig vlan2 create vlan 1 vlandev xl0 instant panic. Call stack snapshot captured as jpeg, I can send it to interested person. On 6.2-STABLE : both vlans created, no errors printed. On -current from Sep,21 "ifconfig: SIOCIFCREATE2: File exists", only first vlan created. best regards, Ilya Orehov. From edwin at mavetju.org Thu Oct 9 22:12:45 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Thu Oct 9 22:12:52 2008 Subject: duplicate vlan panic In-Reply-To: <20081009213006.GA98053@artx.ru> References: <20081009213006.GA98053@artx.ru> Message-ID: <20081009215304.GA71459@mavetju.org> On Fri, Oct 10, 2008 at 01:30:06AM +0400, Ilya Orehov wrote: > RELENG_7 from October,9 ( em card ) > Also repeatable on another box with RELENG_7 from last Saturday. ( xl and nfe ) > > Boot single user or remount readonly. > > ifconfig vlan1 create vlan 1 vlandev xl0 > ifconfig vlan2 create vlan 1 vlandev xl0 Another one, which was reported on IRC but I don't know if it was send-pr'd: ifconfig fxp0.-1 inet 1.2.3.4 Also instant panic. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From jhugo at meraka.csir.co.za Fri Oct 10 14:15:03 2008 From: jhugo at meraka.csir.co.za (Johann Hugo) Date: Fri Oct 10 14:15:18 2008 Subject: Should "route flush" delete all routes ? Message-ID: <200810101615.00557.jhugo@meraka.csir.co.za> According to the man page it looks like it: The route utility provides six commands: add Add a route. flush Remove all routes. ...... but I cannot get it to delete routes created with -interface option. -------------------------------------------------------------------------------- My setup: route add 146.64.80.0/24 192.168.0.100 route add 146.141.0.0 -interface tun1 route add 146.182.0.0 -interface tun1 netstat -rn inet 146.64.80.0/24 192.168.0.100 UGS 0 0 sis0 146.141.0.0/16 tun1 US 0 0 tun1 146.182.0.0/16 tun1 US 0 0 tun1 If I do "route -n flush -inet" then it does not delete the routes created with a -interface option. see verbose output: route -vn flush -inet RTM_GET: Report Metrics: len 204, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.64.80.0 192.168.0.100 (255) ffff ffff ff sis0:0.0.24.c7.8b.80 192.168.0.44 RTM_DELETE: Delete Route: len 204, pid: 0, seq 2, errno 0, flags: locks: inits: sockaddrs: 146.64.80.0 192.168.0.100 (255) ffff ffff ff sis0:0.0.24.c7.8b.80 192.168.0.44 RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.141.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.182.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za netstat -rn inet 146.141.0.0/16 tun1 US 0 0 tun1 146.182.0.0/16 tun1 US 0 0 tun1 uname -a FreeBSD groenwifi.cids.org.za 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #19: Tue Aug 26 13:40:13 UTC 2008 From linimon at FreeBSD.org Fri Oct 10 15:50:14 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Oct 10 15:50:20 2008 Subject: bin/128001: wpa_supplicant(8), wlan(4), and wi(4) issues Message-ID: <200810101550.m9AFoEwO075709@freefall.freebsd.org> Synopsis: wpa_supplicant(8), wlan(4), and wi(4) issues Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 10 15:50:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128001 From david at catwhisker.org Fri Oct 10 16:30:04 2008 From: david at catwhisker.org (David Wolfskill) Date: Fri Oct 10 16:30:10 2008 Subject: bin/128001: wpa_supplicant(8), wlan(4), and wi(4) issues Message-ID: <200810101630.m9AGU3YN078489@freefall.freebsd.org> The following reply was made to PR bin/128001; it has been noted by GNATS. From: David Wolfskill To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: bin/128001: wpa_supplicant(8), wlan(4), and wi(4) issues Date: Fri, 10 Oct 2008 09:22:05 -0700 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Follow-up: Here's sme additional detail, as I was a bit rushed to get to work when I filed the PR. * The NIC is a "Dell TrueMobile 1150 Series PC Card" (in a miniPCI form factor). That NIC is explicitly listed in wi(4) as supported. * On killing & re-starting wpa-supplicant, ifconfig(8) shows another "fake" association to an access point with a null SSDI, but this time, using channel 8 (vs. the use of 3 in the previously-cited example). * I have a 3rd access point (that is small enough that I'm in the habit of keeping it in my laptop bag when it's not in use). Since it, unlike the previously-cited access points, is not normally being used by other folks, I can experiment with its settings as part of testing, if that would be useful. * I also have available an iwi(4) miniPCI card for which wpa_supplicant has worked. However, I'd prefer to minimize switching the miniPCI cards back & forth, as it's a bit difficult to get the antenna lead reconnected each time, and breaking the lead is pretty easy (I've managed to accomplish this once before, much to my chagrin and annoyance). I will start poking around again to see if I can persuade wpa_cli to do something useful. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkjvgSoACgkQmprOCmdXAD0BBQCfZC61/rv75U/DI4infcbpYPGe R2QAn3q3++WmdcKMd4MYMy/Zf9SGOIM+ =pUzb -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From elias at artx.ru Fri Oct 10 18:55:10 2008 From: elias at artx.ru (Ilya Orehov) Date: Fri Oct 10 18:55:17 2008 Subject: duplicate vlan panic In-Reply-To: <20081009213006.GA98053@artx.ru> References: <20081009213006.GA98053@artx.ru> Message-ID: <20081010185508.GA3092@artx.ru> +------- Ilya Orehov, 2008-10-10 ------- | Hi! | | RELENG_7 from October,9 ( em card ) | Also repeatable on another box with RELENG_7 from last Saturday. ( xl and nfe ) | | Boot single user or remount readonly. | | ifconfig vlan1 create vlan 1 vlandev xl0 | ifconfig vlan2 create vlan 1 vlandev xl0 | | instant panic. | Now found time to repeat with serial console: %/sbin/ifconfig vlan1 create vlan 1 vlandev xl0 %/sbin/ifconfig vlan2 create vlan 1 vlandev xl0 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc3e7cc40 stack pointer = 0x28:0xe51e2a9c frame pointer = 0x28:0xe51e2b00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 60 (ifconfig) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c075e582,e51e2938,c0584d4f,c07758b3,1,...) at 0xc048b576 = db_trace_self_wrapper+0x26 kdb_backtrace(c07758b3,1,c074c5ed,e51e2944,1,...) at 0xc05ae719 = kdb_backtrace+ 0x29 panic(c074c5ed,c0776b25,c3e59a4c,1,1,...) at 0xc0584d4f = panic+0x10f trap_fatal(c39e6d98,0,1,0,0,...) at 0xc0717cb3 = trap_fatal+0x333 trap_pfault(0,0,201e2a10,0,c,...) at 0xc0717f10 = trap_pfault+0x250 trap(e51e2a5c) at 0xc0718892 = trap+0x3b2 calltrap() at 0xc06fe07b = calltrap+0x6 --- trap 0xc, eip = 0xc3e7cc40, esp = 0xe51e2a9c, ebp = 0xe51e2b00 --- vlan_unconfig_locked(c3e7f98c,0,c3e7e517,435,11,...) at 0xc3e7cc40 = vlan_unconfig_locked+0x10 vlan_unconfig(c3dd5c00,c3e7f978,10,101,1,...) at 0xc3e7cfb4 = vlan_unconfig+0x34 vlan_clone_create(c3e7f760,c3e18620,10,805d9d8,c3e7d235,...) at 0xc3e7daee = vlan_clone_create+0x25e if_clone_createif(805d9d8,c3e18620,e51e2bb4,c0578c46,c39b3800) at 0xc061e563 = if_clone_createif+0x43 if_clone_create(c3e18620,10,805d9d8,c3eadd5c,c07d6f80,...) at 0xc061ec0a = if_clone_create+0xca ifioctl(c3eab9c0,c020697c,c3e18620,c3e5ccc0,3,...) at 0xc061bfac = ifioctl+0xccsoo_ioctl(c3e627b8,c020697c,c3e18620,c39b3800,c3e5ccc0,...) at 0xc05c2a8a = soo_ioctl+0x56a kern_ioctl(c3e5ccc0,3,c020697c,c3e18620,1000001,...) at 0xc05bb955 = kern_ioctl+0x355 ioctl(c3e5ccc0,e51e2cfc,c,e51e2d38,e51e2d2c,...) at 0xc05bbab4 = ioctl+0x134 syscall(e51e2d38) at 0xc0718249 = syscall+0x319 Xint0x80_syscall() at 0xc06fe0e0 = Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2816e6f3, esp = 0xbfbfe58c, ebp = 0xbfbfe5a8 --- Uptime: 1m29s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs best regards, Ilya Orehov. From bh at izb.knu.ac.kr Sat Oct 11 00:48:38 2008 From: bh at izb.knu.ac.kr (Byung-Hee HWANG) Date: Sat Oct 11 00:48:44 2008 Subject: freebsd.org and DKIM Message-ID: <48EFF7D8.1000201@izb.knu.ac.kr> (i'm very sorry if this subject is not related to freebsd-net@) ;; Hello, my name is byunghee from South Korea. And more, i'm now maintain one port (misc/...godfather) ;; I love your policy for mailing list at freebsd.org. But, the MIME converting is dangerous at some point. Recently, somebody use DKIM [RFC 4871] to make truth over the Internet at email. I don't know you are interested in DKIM, however, i wish freebsd.org offer that other email servers can verify the DKIM signatures if that's OK with you. What do you think of that? Or any comments? Sincerely, byunghee From bms at FreeBSD.org Sat Oct 11 08:46:41 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sat Oct 11 08:46:48 2008 Subject: How to support an Ethernet PHY without ID registers? In-Reply-To: References: <48EBB3D6.600@incunabulum.net> Message-ID: <48F067EF.7010901@FreeBSD.org> Sepherosa Ziehau wrote: > Are you sure you could read from BMSR? Return invalid value from BMSR > is the usual cause of miibus attaching/probing failure. For ID1/ID2 > reading, you could just fake some values in npe(4)'s miibus_readreg > implementation. > Thanks for the tip (from you and Pyun). I had to spoof the BMSR read to get npe(4) to attach just to begin with. For whatever reason the chip doesn't seem to respond on any of the PHY IDs which the Linux folk are using (5 and 4 for npe0 (-B) and npe1 (-C) respectively). I noticed the ucLinux folk needed a similar patch to force driver attach under Linux w/the IXP: http://mailman.uclinux.org/pipermail/uclinux-dev/2005-March/031419.html The switch pretty much disappears after npe(4) attaches, I don't see any activity lights or link lights at that point. This seems to happen after any mii register access. If I frob things to allow rlswitch to attach, by using hints and hacking if_npe.c, I can get dumps of the PHY register space, but it's all ones, suggesting that it failed at xScale register level -- that would suggest the PHY IDs are *wrong*, or something else isn't right. Pyun also suggested trying to manually take the PHYs out of power-down mode. I tried that with a code snippet I sent him, but still no dice. I can't even be sure that the PHYs are being addressed right. At this point I kind of have to go, whoah, wish I had a logic analyzer and grabbers! I believe the firmware configures the switch chip in a certain VLAN configuration which isn't meant to be disrupted, although Freecom's own SnapGear-based distro apparently does the right thing. I've looked through all of their GPL materials and cannot find the driver for the switch. I suppose one thing I could try is re-flashing the box with the official Freecom firmware, and using mii-diag to dump out what Linux thinks the registers are. thanks BMS From kris at FreeBSD.org Sat Oct 11 19:12:40 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sat Oct 11 19:12:46 2008 Subject: kernel profiling: spinlock_exit consumes 36% CPU time. In-Reply-To: <000a01c9291a$b81fa560$01000001@china.huawei.com> References: <000a01c9291a$b81fa560$01000001@china.huawei.com> Message-ID: <48F0FAC6.8040307@FreeBSD.org> ?? wrote: > Many thanks for the information. > > Could we say that interrupt handlers consumed ~36% execution time? > > Is this number too high? Is it possible that we abuse the use of critical > sections in kernel? Also note that profiling itself is using ~40% of CPU. That means you need to worry about whether it is seriously skewing the results away from what they would be without profiling. If you can use hwpmc then the profiling overhead is much less. However support for modern Intel CPUs was only recently added in -CURRENT and may not have been merged to 7.x yet, so it might not be usable for you yet. If you run without profiling then top(1) will show you the CPU use of the interrupt handlers. Kris > > Looking forward to your options. Many thanks. > > Qiu Jian > > > On Tuesday 07 October 2008 07:44:00 am ?? wrote: >> Hi, folks, >> >> I did kernel profiling when a single thread client sends UDP packets >> to a single thread server on the same machine. >> >> In the output kernel profile, the first few kernel functions that >> consumes the most CPU time are listed below: >> >> granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 >> seconds >> >> % cumulative self self total >> time seconds seconds calls ms/call ms/call name >> 42.4 10.88 10.88 0 100.00% __mcount [1] >> 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] >> 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] >> 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] >> 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] >> 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] >> 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] >> 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic > [9] >> It is very strange that spinlock_exit consumes over 36% CPU time while >> it seems a very simple function. > > It's because the intr_restore() re-enables interrupts and the resulting time > spent executing the handlers for any pending interrupts are attributed to > spinlock_exit(). > > -- > John Baldwin > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > > From free.dvig at gmail.com Sun Oct 12 14:32:43 2008 From: free.dvig at gmail.com (Aleksandr Litvinov) Date: Sun Oct 12 14:32:50 2008 Subject: Realtek network driver Message-ID: <65f70ae30810120706k3580141dof58b86b13136d5df@mail.gmail.com> Hi, Let's ask. Why in cvsweb existing a two drivers for network interface realtek: rl & re? They can be united? What objective reasons prevent to make? -- -- Good Luck. -- Litvinov Alexandr. From ertr1013 at student.uu.se Sun Oct 12 15:06:18 2008 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sun Oct 12 15:06:26 2008 Subject: Realtek network driver In-Reply-To: <65f70ae30810120706k3580141dof58b86b13136d5df@mail.gmail.com> References: <65f70ae30810120706k3580141dof58b86b13136d5df@mail.gmail.com> Message-ID: <20081012145041.GA99667@owl.midgard.homeip.net> On Sun, Oct 12, 2008 at 08:06:23PM +0600, Aleksandr Litvinov wrote: > Hi, > Let's ask. Why in cvsweb existing a two drivers for network interface > realtek: rl & re? They can be united? What objective reasons prevent > to make? Realtek makes many different ethernet controllers. The rl(4) driver supports several of the older chips (10/100M capable) while re(4) supports most of the newer models (mostly gigabit capable.) These two groups of controllers are different enough to warrant different drivers. Of course one could, in theory, unite the rl and re drivers, but they do not have enough in common for this to be a good idea. -- Erik Trulsson ertr1013@student.uu.se From bugmaster at FreeBSD.org Mon Oct 13 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 13 11:08:27 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200810131106.m9DB6reJ029502@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 185 problems total. From ivoras at freebsd.org Mon Oct 13 15:25:21 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Oct 13 15:25:27 2008 Subject: VLANs and hardware options Message-ID: I have the following situation: bce0: flags=8802 metric 0 mtu 1500 options=1bb ether 00:14:5e:6d:2d:74 media: Ethernet autoselect (1000baseSX ) status: active vlan0: flags=8843 metric 0 mtu 1500 options=3 ether 00:14:5e:b3:2a:38 inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.255 media: Ethernet autoselect (1000baseSX ) status: active vlan: 250 parent interface: bce1 e.g. the network card is directly on a trunked network, and I have the vlan interface with actual IP address. My question is: since this setup mixes various network&protocol layers, are the TSO capabilities of the card used? I guess not and that only RXCSUM & TXCSUM are used (for IP-level packets). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081013/99dfec55/signature.pgp From wawa at yandex-team.ru Mon Oct 13 17:28:46 2008 From: wawa at yandex-team.ru (Vladimir Ivanov) Date: Mon Oct 13 17:28:53 2008 Subject: SMPable version of EM driver In-Reply-To: <479CAF1F.4010900@moneybookers.com> References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> <47037246.2070400@yandex-team.ru> <47040D83.9010706@delphij.net> <47200537.8070708@room52.net> <472028C0.4040004@delphij.net> <47220853.90206@yandex-team.ru> <20071214113434.GD63588@uafug.org.ua> <4762796B.3090608@yandex-team.ru> <479B5C27.2010201@moneybookers.com> <479BC043.8020007@yandex-team.ru> <479CAF1F.4010900@moneybookers.com> Message-ID: <48F38242.8020109@yandex-team.ru> Stefan Lambrev ?????: > Hi Vladimir, > [skip] > I'm unable to get this driver working under releng_7_0. It builds > without problems but panic my machine when I load it. > May be I'll wait until you have "official" version for FreeBSD 7.0 or > changes get merged into Intel's driver :) > We've published RELENG_7 revision at http://people.yandex-team.ru/~wawa/em-6.9.5-RELENG7-yandex-1.36.2.5.tar.gz WBR, -- Vladimir Ivanov Network Operations Center OOO "Yandex" t: +7 495 739-7000 f: +7 495 739-7070 @: noc@yandex.net (corporate) wawa@yandex-team.ru (personal) www: www.yandex.ru -- From glen.j.barber at gmail.com Tue Oct 14 00:22:40 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Tue Oct 14 00:22:48 2008 Subject: ifconfig, wpa_supplicant, and hidden SSIDs Message-ID: <4ad871310810131722p5dec24bco148ed703ca0f8870@mail.gmail.com> Hi everyone. I'm having an odd problem with wpa_supplicant and a hidden, unauthenticated access point. If I do 'ifconfig ndis0 scan', it brings up BSSIDs, but hidden names. I have desktopbsd-tools installed, so I tried accessing the AP using that, which I had to manually tell dbsd-nettray the SSID name for the AP in question. After doing so, I get 'Failed to connect', but '/etc/rc.d/netif restart ndis0' brings the interface back up, and reconnects. Now, to my real question: Where does SSID and AP MAC addresses get stored in the system? If I can manually (or script) the SSID name to the file, associated my MAC address of the access point, I can set this up via rc.local, and not need to load the dbsd-tools applet, which I cannot use anyway because of WPA at home. Thanks in advance. -- Glen Barber From pyunyh at gmail.com Tue Oct 14 06:37:06 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Oct 14 06:37:13 2008 Subject: VLANs and hardware options In-Reply-To: References: Message-ID: <20081014063504.GD14769@cdnetworks.co.kr> On Mon, Oct 13, 2008 at 05:26:04PM +0200, Ivan Voras wrote: > I have the following situation: > > bce0: flags=8802 metric 0 mtu 1500 > options=1bb > ether 00:14:5e:6d:2d:74 > media: Ethernet autoselect (1000baseSX ) > status: active > > vlan0: flags=8843 metric 0 mtu 1500 > options=3 > ether 00:14:5e:b3:2a:38 > inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.255 > media: Ethernet autoselect (1000baseSX ) > status: active > vlan: 250 parent interface: bce1 > > e.g. the network card is directly on a trunked network, and I have the > vlan interface with actual IP address. My question is: since this setup > mixes various network&protocol layers, are the TSO capabilities of the > card used? I guess not and that only RXCSUM & TXCSUM are used (for > IP-level packets). > Correct. I believe almost all gigabit controllers can handle TSO with VLAN tagging. Unfortunately there is no official way to inform TSO capability of parent interface to VLAN layer in FreeBSD. Just adding a new flag to if_capabilities and minor patch to vlan(4) would make TSO work on vlan interface. But I haven't had time to implement this as my working environment does not involve VLANs. -- Regards, Pyun YongHyeon From remko at FreeBSD.org Tue Oct 14 21:20:58 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Tue Oct 14 21:21:14 2008 Subject: misc/128103: SiS 190 NIC not supported Message-ID: <200810142120.m9ELKwtq060419@freefall.freebsd.org> Synopsis: SiS 190 NIC not supported Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Oct 14 21:20:58 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=128103 From sepherosa at gmail.com Wed Oct 15 01:47:58 2008 From: sepherosa at gmail.com (Sepherosa Ziehau) Date: Wed Oct 15 01:48:04 2008 Subject: How to support an Ethernet PHY without ID registers? In-Reply-To: <48F067EF.7010901@FreeBSD.org> References: <48EBB3D6.600@incunabulum.net> <48F067EF.7010901@FreeBSD.org> Message-ID: On Sat, Oct 11, 2008 at 4:46 PM, Bruce M. Simpson wrote: > Sepherosa Ziehau wrote: >> >> Are you sure you could read from BMSR? Return invalid value from BMSR >> is the usual cause of miibus attaching/probing failure. For ID1/ID2 >> reading, you could just fake some values in npe(4)'s miibus_readreg >> implementation. >> > > Thanks for the tip (from you and Pyun). I had to spoof the BMSR read to get > npe(4) to attach just to begin with. For whatever reason the chip doesn't > seem to respond on any of the PHY IDs which the Linux folk are using (5 and > 4 for npe0 (-B) and npe1 (-C) respectively). > > I noticed the ucLinux folk needed a similar patch to force driver attach > under Linux w/the IXP: > http://mailman.uclinux.org/pipermail/uclinux-dev/2005-March/031419.html > > The switch pretty much disappears after npe(4) attaches, I don't see any > activity lights or link lights at that point. This seems to happen after any > mii register access. > > If I frob things to allow rlswitch to attach, by using hints and hacking > if_npe.c, I can get dumps of the PHY register space, but it's all ones, > suggesting that it failed at xScale register level -- that would suggest the > PHY IDs are *wrong*, or something else isn't right. > > Pyun also suggested trying to manually take the PHYs out of power-down mode. > I tried that with a code snippet I sent him, but still no dice. I can't even > be sure that the PHYs are being addressed right. Realtek's 8211[BC] PHY has a "page selector" register (0x1f), BMSR and other GMII standard registers are in page0. Does the PHY you are working with has something like the "page selector"? Best Regards, sephe -- Live Free or Die From rea-fbsd at codelabs.ru Thu Oct 16 04:25:36 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Oct 16 04:25:44 2008 Subject: Bridge interface as the vlan(4) parent Message-ID: Andrew, *, good day. I had just came across the following situation: I have two VLAN-tagged links that are coming to my machine from two switches. I am running RSTP on the switches and need the machine to participate in the spanning tree formation (one switch is the root, another is the backup). Since RSTP messages are coming untagged, I need to make bridge on my physical interfaces, to enable spanning tree formation. And the bridge should be the parent device for the vlan(4) interfaces that will untag the packets. It is not possible just now to have bridge interface to be parent of vlan interface for two reasons: 1. vlan(4) won't attach to IFT_BRIDGE; this is rather easy to fix; 2. there should be a hook on the bridge path that will call vlan_input/ vlan_output; this is the harder problem, but I think that it isn't so hard, at least I have such impression after glancing at the code. Questions: may be I don't understand something and there is another way to create RSTP-aware bridge that will handle vlans? If my swithes will speak PVST, this will be easy -- one bridge per vlan instance and vlan(4) interfaces will be bridged. But I need RSTP. The second question: does anyone sees any problems apart from the mentioned two? May be I am wrong about the complexity of the second problem? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081016/0c7998a6/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Thu Oct 16 13:10:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Oct 16 13:10:14 2008 Subject: [patch] src port randomization for inet6 Message-ID: <20081016130318.J2978@maildrop.int.zabbadoz.net> Hi, so since the very early day of src port randomization ipv6 was missing that part while inet had it. Find a patch below. Please test, review and report back... http://people.freebsd.org/~bz/20081004-07-ipv6-randomport.diff /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From max at love2party.net Fri Oct 17 02:59:36 2008 From: max at love2party.net (Max Laier) Date: Fri Oct 17 02:59:42 2008 Subject: [patch] src port randomization for inet6 In-Reply-To: <20081016130318.J2978@maildrop.int.zabbadoz.net> References: <20081016130318.J2978@maildrop.int.zabbadoz.net> Message-ID: <200810170459.32822.max@love2party.net> On Thursday 16 October 2008 15:05:16 Bjoern A. Zeeb wrote: > so since the very early day of src port randomization ipv6 was missing > that part while inet had it. Find a patch below. > Please test, review and report back... > > http://people.freebsd.org/~bz/20081004-07-ipv6-randomport.diff looks good from a casual review. Which is to say that it is in line with the in_pcb.c version. However, I find the comment: /* * Simple check to ensure all ports are not used up causing * a deadlock here. */ a bit dangling and not really in line with the actual code. The same is true for the v4 version. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From tdcmystere at gmail.com Fri Oct 17 09:33:32 2008 From: tdcmystere at gmail.com (Antipov Dima) Date: Fri Oct 17 09:33:39 2008 Subject: Network configuration for KVM Message-ID: *English* Hi all sorry for my english i have little problem whis a network configuration for my freebsd used whis KVM so my probleme is simple ip of my host 91.121.156.206 ip oh my guest 91.121.234.115 from Gust i can ping any ip's but no domaines i can not ping my Guest from anywhere esolv.conf nameserver 231.186.33.99 domaine ovh.net search ovh.net on my host i have network interface wmbr0 so i add ip route add 91.121.234.115 (ip of my gust) dev vmbr0 on my guest i add a default route ip route add default 91.121.234.115 Thank you for all *French* bonjour a tous voila j ai jamais utilis? freebsd et la j en ais besoin mon soucis j arrive a pinguer depuis le guest l exterieur et l interieur depuis host impossible pourtant la route est bien mise puis depuis guest je sais pinguer que les ip pas de domaines dans mon resolv.conf nameserver 231.186.33.99 domaine ovh.net je sais que il faut rajouter search ovh.net ou remplacer domaine par search faut il faire encore qqch? et que dois je faire sur le host pour pinguer le gust? Merci d'avance From bz at FreeBSD.org Fri Oct 17 14:04:12 2008 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Fri Oct 17 14:04:18 2008 Subject: bin/116643: [patch] [request] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD Message-ID: <200810171404.m9HE4AFL007386@freefall.freebsd.org> Synopsis: [patch] [request] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD State-Changed-From-To: open->feedback State-Changed-By: bz State-Changed-When: Fri Oct 17 14:03:39 UTC 2008 State-Changed-Why: See what the submitetr thinks on staying with fstat and using sockstat. http://www.freebsd.org/cgi/query-pr.cgi?pr=116643 From bz at FreeBSD.org Fri Oct 17 14:05:02 2008 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Fri Oct 17 14:05:08 2008 Subject: bin/116643: [patch] [request] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD Message-ID: <200810171405.m9HE52Ce007475@freefall.freebsd.org> Synopsis: [patch] [request] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Fri Oct 17 14:04:47 UTC 2008 Responsible-Changed-Why: Assign to me for the follow-up. http://www.freebsd.org/cgi/query-pr.cgi?pr=116643 From brooks at FreeBSD.org Fri Oct 17 14:19:28 2008 From: brooks at FreeBSD.org (brooks@FreeBSD.org) Date: Fri Oct 17 14:19:35 2008 Subject: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics Message-ID: <200810171419.m9HEJRvB009736@freefall.freebsd.org> Synopsis: [ndis] [patch] with wep enters kdb.enter.unknown, panics Responsible-Changed-From-To: freebsd-net->thompsa Responsible-Changed-By: brooks Responsible-Changed-When: Fri Oct 17 14:17:37 UTC 2008 Responsible-Changed-Why: thompsa seems to have insight into this problem to assign it to him for now. http://www.freebsd.org/cgi/query-pr.cgi?pr=125181 From gavin at FreeBSD.org Fri Oct 17 14:30:23 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Oct 17 14:30:39 2008 Subject: kern/128143: [rl] NIC Realtek 8139 doesn't work with RAM higher than 4GB Message-ID: <200810171430.m9HEUMvj011726@freefall.freebsd.org> Synopsis: [rl] NIC Realtek 8139 doesn't work with RAM higher than 4GB State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Fri Oct 17 14:29:23 UTC 2008 State-Changed-Why: Submitter has tested patch but it makes no difference. Responsible-Changed-From-To: gavin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri Oct 17 14:29:23 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=128143 From vwe at FreeBSD.org Fri Oct 17 16:18:13 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri Oct 17 16:18:20 2008 Subject: kern/128103: [feature request] [patch] new SiS 190 NIC driver Message-ID: <200810171618.m9HGICrK021340@freefall.freebsd.org> Synopsis: [feature request] [patch] new SiS 190 NIC driver Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Fri Oct 17 16:17:38 UTC 2008 Responsible-Changed-Why: grab - will create a clean patchset as I think this shouldn't be a new driver at all. http://www.freebsd.org/cgi/query-pr.cgi?pr=128103 From gene at nttmcl.com Sat Oct 18 00:58:47 2008 From: gene at nttmcl.com (Eugene M. Kim) Date: Sat Oct 18 00:58:54 2008 Subject: Closing connection from an accept_filter(9) Message-ID: <48F93051.6040808@nttmcl.com> Hello, Is it possible to close a connection from an accept filter, for example, in order to prevent an incoming connection with a malformed request body from ever reaching the userland? Cheers, Eugene From alfred at freebsd.org Sat Oct 18 01:22:21 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Sat Oct 18 01:22:27 2008 Subject: Closing connection from an accept_filter(9) In-Reply-To: <48F93051.6040808@nttmcl.com> References: <48F93051.6040808@nttmcl.com> Message-ID: <20081018010452.GC5651@elvis.mu.org> * Eugene M. Kim [081017 17:58] wrote: > Hello, > > Is it possible to close a connection from an accept filter, for example, > in order to prevent an incoming connection with a malformed request body > from ever reaching the userland? Probably, look at what happens inside of syncache or syncookies to sockets that are on accept queue but not yet "accepted". -Alfred > > Cheers, > Eugene > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- - Alfred Perlstein From remko at FreeBSD.org Sat Oct 18 08:15:10 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat Oct 18 08:15:17 2008 Subject: kern/128181: [fxp]: Unread portion of the kernel message buffer Message-ID: <200810180815.m9I8F9h6038145@freefall.freebsd.org> Old Synopsis: Unread portion of the kernel message buffer New Synopsis: [fxp]: Unread portion of the kernel message buffer Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Oct 18 08:14:54 UTC 2008 Responsible-Changed-Why: reassign to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=128181 From fox at verio.net Sat Oct 18 09:25:46 2008 From: fox at verio.net (David DeSimone) Date: Sat Oct 18 09:25:52 2008 Subject: Closing connection from an accept_filter(9) In-Reply-To: <48F93051.6040808@nttmcl.com> References: <48F93051.6040808@nttmcl.com> Message-ID: <20081018090351.GA29876@verio.net> Eugene M. Kim wrote: > > Is it possible to close a connection from an accept filter, for > example, in order to prevent an incoming connection with a malformed > request body from ever reaching the userland? How would you propose to find out what is in the request body without first accepting the connection? -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From eugen at kuzbass.ru Sat Oct 18 09:51:40 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sat Oct 18 09:51:46 2008 Subject: SNMP High Capacity Counters Message-ID: <20081018092405.GA91929@svzserv.kemerovo.su> Hi! I've just found that ports/net-snmp (version 5.4) built WITH_MFD_REWRITES=yes supports IF-MIB, and in theory should show 64-bit ifHC* counters but it does not. It seems agent/mibgroup/if-mib/data_access/interface_sysctl.c that obtains interface statistics from the kernel. The function netsnmp_arch_interface_container_load() has the following code: /* get counters */ entry->stats.ibytes.low = ifp->ifm_data.ifi_ibytes; entry->stats.ibytes.high = 0; entry->stats.iucast.low = ifp->ifm_data.ifi_ipackets; entry->stats.iucast.high = 0; entry->stats.imcast.low = ifp->ifm_data.ifi_imcasts; entry->stats.imcast.high = 0; So, it always produce 32-bit quantities. My question is: does FreeBSD/i386 kernel maintain 64-bit counters for interface statictics these days? If yes, since what version? Eugene Grosbein From gavin at FreeBSD.org Sat Oct 18 16:55:59 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Oct 18 16:56:05 2008 Subject: conf/128030: [request] Isn't it time to enable IPsec in GENERIC? Message-ID: <200810181655.m9IGtxWk089117@freefall.freebsd.org> Synopsis: [request] Isn't it time to enable IPsec in GENERIC? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 Responsible-Changed-Why: Over to maintainer(s) for consideration http://www.freebsd.org/cgi/query-pr.cgi?pr=128030 From sam at freebsd.org Sat Oct 18 17:05:27 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Oct 18 17:05:33 2008 Subject: conf/128030: [request] Isn't it time to enable IPsec in GENERIC? In-Reply-To: <200810181655.m9IGtxWk089117@freefall.freebsd.org> References: <200810181655.m9IGtxWk089117@freefall.freebsd.org> Message-ID: <48FA1756.1080708@freebsd.org> gavin@freebsd.org wrote: > Synopsis: [request] Isn't it time to enable IPsec in GENERIC? > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: gavin > Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 > Responsible-Changed-Why: > Over to maintainer(s) for consideration > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128030 > Last I checked IPSEC added noticeable overhead. Before anyone does this you need to measure the cost of having it enabled but not used. Sam From hartmut.brandt at dlr.de Sat Oct 18 17:32:10 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Sat Oct 18 17:32:17 2008 Subject: SNMP High Capacity Counters In-Reply-To: <20081018092405.GA91929@svzserv.kemerovo.su> References: <20081018092405.GA91929@svzserv.kemerovo.su> Message-ID: <48FA1A7C.5060801@dlr.de> Eugene Grosbein wrote: > Hi! > > I've just found that ports/net-snmp (version 5.4) built > WITH_MFD_REWRITES=yes supports IF-MIB, and in theory should show 64-bit > ifHC* counters but it does not. > > It seems agent/mibgroup/if-mib/data_access/interface_sysctl.c that obtains > interface statistics from the kernel. > The function netsnmp_arch_interface_container_load() has the following code: > > /* get counters */ > entry->stats.ibytes.low = ifp->ifm_data.ifi_ibytes; > entry->stats.ibytes.high = 0; > entry->stats.iucast.low = ifp->ifm_data.ifi_ipackets; > entry->stats.iucast.high = 0; > entry->stats.imcast.low = ifp->ifm_data.ifi_imcasts; > entry->stats.imcast.high = 0; > > So, it always produce 32-bit quantities. My question is: > does FreeBSD/i386 kernel maintain 64-bit counters for interface statictics > these days? If yes, since what version? It does not, because not all architectures have atomic 64-bit increments and adds. Implementing 64-bit counters on these architectures would require some kind of locking. This was discussed in the past. You might look at the IF-MIB implementation of bsnmp (it is in the base system). It uses periodic polling to detect wraps of the 32-bit counters. The poll interval is tuned to the fastest interface in the system (given that all interfaces reported the correct speed). Note, that the netsnmp implementation is plain wrong - if the daemon does not support the HC counters it should never pretend to do. This is explicitely stated somewhere in the RFCs. harti From max at love2party.net Sat Oct 18 18:18:18 2008 From: max at love2party.net (Max Laier) Date: Sat Oct 18 18:18:30 2008 Subject: conf/128030: [request] Isn't it time to enable IPsec in GENERIC? In-Reply-To: <48FA1756.1080708@freebsd.org> References: <200810181655.m9IGtxWk089117@freefall.freebsd.org> <48FA1756.1080708@freebsd.org> Message-ID: <200810182018.13757.max@love2party.net> On Saturday 18 October 2008 19:05:26 Sam Leffler wrote: > gavin@freebsd.org wrote: > > Synopsis: [request] Isn't it time to enable IPsec in GENERIC? > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > Responsible-Changed-By: gavin > > Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 > > Responsible-Changed-Why: > > Over to maintainer(s) for consideration > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128030 > > Last I checked IPSEC added noticeable overhead. Before anyone does this > you need to measure the cost of having it enabled but not used. It should be possible to turn IPSEC into a module - maybe only loadable on boot to avoid locking issues. This would reduce the overhead to a handful of function pointer checks that should not impact performance (thanks to modern branch prediction and cache sizes). This would have to be measured as well, of course. Maybe this should go to the project page? It's a good junior kernel hacker project, I believe. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From eugen at kuzbass.ru Sat Oct 18 18:41:49 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sat Oct 18 18:41:56 2008 Subject: SNMP High Capacity Counters In-Reply-To: <48FA1A7C.5060801@dlr.de> References: <20081018092405.GA91929@svzserv.kemerovo.su> <48FA1A7C.5060801@dlr.de> Message-ID: <20081018184140.GA71679@svzserv.kemerovo.su> On Sat, Oct 18, 2008 at 07:18:52PM +0200, Hartmut Brandt wrote: > >I've just found that ports/net-snmp (version 5.4) built > >WITH_MFD_REWRITES=yes supports IF-MIB, and in theory should show 64-bit > >ifHC* counters but it does not. > > > >It seems agent/mibgroup/if-mib/data_access/interface_sysctl.c that obtains > >interface statistics from the kernel. > >The function netsnmp_arch_interface_container_load() has the following > >code: > > > > /* get counters */ > > entry->stats.ibytes.low = ifp->ifm_data.ifi_ibytes; > > entry->stats.ibytes.high = 0; > > entry->stats.iucast.low = ifp->ifm_data.ifi_ipackets; > > entry->stats.iucast.high = 0; > > entry->stats.imcast.low = ifp->ifm_data.ifi_imcasts; > > entry->stats.imcast.high = 0; > > > >So, it always produce 32-bit quantities. My question is: > >does FreeBSD/i386 kernel maintain 64-bit counters for interface statictics > >these days? If yes, since what version? > It does not, because not all architectures have atomic 64-bit increments > and adds. Implementing 64-bit counters on these architectures would > require some kind of locking. This was discussed in the past. Yes, I've read archives and saw a discussion dated 2002 or 2003. Some time has passed since than, generic CPU horsepower has changed. And I'm sure IPFW maintains 64-bit counters for FreeBSD/i386 without a problem. Yes, IPFW is additional feature and needs to be enables explicitly. I run it since 2.2.8 in every kernel and had no problems with (lots of) its 64-bit counters. Would (optionally) having another pack of them hurt? I've read someone made a path for 64-bit statictics counters in 2002. > You might look at the IF-MIB implementation of bsnmp (it is in the base > system). It uses periodic polling to detect wraps of the 32-bit > counters. The poll interval is tuned to the fastest interface in the > system (given that all interfaces reported the correct speed). > > Note, that the netsnmp implementation is plain wrong - if the daemon > does not support the HC counters it should never pretend to do. This is > explicitely stated somewhere in the RFCs. It does really support them for Linux and Solaris. They seem to have solved this problem somehow. It would be very nice to have, say, kernel option to enable the support. Just like options IPFIREWALL. Eugene Grosbein From sam at freebsd.org Sat Oct 18 20:25:24 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Oct 18 20:25:30 2008 Subject: conf/128030: [request] Isn't it time to enable IPsec in GENERIC? In-Reply-To: <200810182018.13757.max@love2party.net> References: <200810181655.m9IGtxWk089117@freefall.freebsd.org> <48FA1756.1080708@freebsd.org> <200810182018.13757.max@love2party.net> Message-ID: <48FA4633.9090500@freebsd.org> Max Laier wrote: > On Saturday 18 October 2008 19:05:26 Sam Leffler wrote: > >> gavin@freebsd.org wrote: >> >>> Synopsis: [request] Isn't it time to enable IPsec in GENERIC? >>> >>> Responsible-Changed-From-To: freebsd-bugs->freebsd-net >>> Responsible-Changed-By: gavin >>> Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 >>> Responsible-Changed-Why: >>> Over to maintainer(s) for consideration >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=128030 >>> >> Last I checked IPSEC added noticeable overhead. Before anyone does this >> you need to measure the cost of having it enabled but not used. >> > > It should be possible to turn IPSEC into a module - maybe only loadable on > boot to avoid locking issues. This would reduce the overhead to a handful of > function pointer checks that should not impact performance (thanks to modern > branch prediction and cache sizes). This would have to be measured as well, > of course. Maybe this should go to the project page? It's a good junior > kernel hacker project, I believe. > > I believe the most important issue are the SADB checks in the tx path. It used to be possible to do them cheaply by checking a single ptr value but now it's much more expensive. My memory is hazy as it's been a while. Sam From sandiegobiker at gmail.com Sat Oct 18 22:38:06 2008 From: sandiegobiker at gmail.com (Len Gross) Date: Sat Oct 18 22:38:12 2008 Subject: Timers in drivers vs userland Message-ID: <27cb3ada0810181512qeab4020g912096848212ad86@mail.gmail.com> If I place a timer directly in a driver (like Ethernet) will it be subject to less jitter and more consistency than if it were in Userland? I know FreeBSD is not "real time," but I need to be able to run a polling algorithm with about 1 ms accuracy. Thanks in advance. (Please tell me if there is a better list for this question.) -- Len From sandiegobiker at gmail.com Sun Oct 19 00:28:31 2008 From: sandiegobiker at gmail.com (Len Gross) Date: Sun Oct 19 00:28:38 2008 Subject: Timers in drivers vs userland In-Reply-To: <27cb3ada0810181512qeab4020g912096848212ad86@mail.gmail.com> References: <27cb3ada0810181512qeab4020g912096848212ad86@mail.gmail.com> Message-ID: <27cb3ada0810181728w3f41e3d0pe2fca8102b0c7206@mail.gmail.com> Slight correction; I should have said more accurate usleep, not "timer." -- Len On Sat, Oct 18, 2008 at 3:12 PM, Len Gross wrote: > If I place a timer directly in a driver (like Ethernet) will it be > subject to less jitter and more consistency than if it were in > Userland? > > I know FreeBSD is not "real time," but I need to be able to run a > polling algorithm with about 1 ms accuracy. > > Thanks in advance. > > (Please tell me if there is a better list for this question.) > > -- Len > From hartmut.brandt at dlr.de Sun Oct 19 11:17:14 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Sun Oct 19 11:17:24 2008 Subject: SNMP High Capacity Counters In-Reply-To: <20081018184140.GA71679@svzserv.kemerovo.su> References: <20081018092405.GA91929@svzserv.kemerovo.su> <48FA1A7C.5060801@dlr.de> <20081018184140.GA71679@svzserv.kemerovo.su> Message-ID: <48FB1739.8020608@dlr.de> Eugene Grosbein wrote: > On Sat, Oct 18, 2008 at 07:18:52PM +0200, Hartmut Brandt wrote: > >>> I've just found that ports/net-snmp (version 5.4) built >>> WITH_MFD_REWRITES=yes supports IF-MIB, and in theory should show 64-bit >>> ifHC* counters but it does not. >>> >>> It seems agent/mibgroup/if-mib/data_access/interface_sysctl.c that obtains >>> interface statistics from the kernel. >>> The function netsnmp_arch_interface_container_load() has the following >>> code: >>> >>> /* get counters */ >>> entry->stats.ibytes.low = ifp->ifm_data.ifi_ibytes; >>> entry->stats.ibytes.high = 0; >>> entry->stats.iucast.low = ifp->ifm_data.ifi_ipackets; >>> entry->stats.iucast.high = 0; >>> entry->stats.imcast.low = ifp->ifm_data.ifi_imcasts; >>> entry->stats.imcast.high = 0; >>> >>> So, it always produce 32-bit quantities. My question is: >>> does FreeBSD/i386 kernel maintain 64-bit counters for interface statictics >>> these days? If yes, since what version? > >> It does not, because not all architectures have atomic 64-bit increments >> and adds. Implementing 64-bit counters on these architectures would >> require some kind of locking. This was discussed in the past. > > Yes, I've read archives and saw a discussion dated 2002 or 2003. > Some time has passed since than, generic CPU horsepower has changed. > And I'm sure IPFW maintains 64-bit counters for FreeBSD/i386 > without a problem. Yes, IPFW is additional feature and needs to be enables > explicitly. I run it since 2.2.8 in every kernel and had no problems with > (lots of) its 64-bit counters. Would (optionally) having > another pack of them hurt? I've read someone made a path for 64-bit > statictics counters in 2002. The problem is not the CPU horsepower. The problem is that you update these counters on each incoming packet. No problem for desktops, but if you want to route several 100kps this may hurt. I have no idea, how IPFW does it. Perhaps it just declares the variables as 64-bit and if the value is wrong because of a race condition, then it is just wrong. With SNMP I would not like to have wrong counters - people use these counters for accounting purposes. > >> You might look at the IF-MIB implementation of bsnmp (it is in the base >> system). It uses periodic polling to detect wraps of the 32-bit >> counters. The poll interval is tuned to the fastest interface in the >> system (given that all interfaces reported the correct speed). >> >> Note, that the netsnmp implementation is plain wrong - if the daemon >> does not support the HC counters it should never pretend to do. This is >> explicitely stated somewhere in the RFCs. > > It does really support them for Linux and Solaris. > They seem to have solved this problem somehow. > It would be very nice to have, say, kernel option to enable > the support. Just like options IPFIREWALL. I remember a mail from, I think, phk (cannot find it, though) where he described a method to handle, I think, geom statistics in a lockless way. The idea was to put a generation count at the begin and the end of the data area. The consumer would copy the entire area and compare the generation counts. If they are equal, the stats are ok, if they differ, you take another turn. You need of course the right memory barriers in the code so that neither the CPU nor the compiler reorders the increments and this will cost some cycles (no idea how many). I don't know what happened to this (never looked at the geom code) but it sounds usable for interface statistics too. Would be nice, though, to have this mechansim in the sysctl handler so that userspace needs not to care about this stuff. harti From eugen at kuzbass.ru Sun Oct 19 13:22:28 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Oct 19 13:22:35 2008 Subject: SNMP High Capacity Counters In-Reply-To: <48FB1739.8020608@dlr.de> References: <20081018092405.GA91929@svzserv.kemerovo.su> <48FA1A7C.5060801@dlr.de> <20081018184140.GA71679@svzserv.kemerovo.su> <48FB1739.8020608@dlr.de> Message-ID: <20081019132220.GA97807@svzserv.kemerovo.su> On Sun, Oct 19, 2008 at 01:17:13PM +0200, Hartmut Brandt wrote: > The problem is not the CPU horsepower. The problem is that you update > these counters on each incoming packet. No problem for desktops, but if > you want to route several 100kps this may hurt. I have no idea, how IPFW > does it. Perhaps it just declares the variables as 64-bit and if the > value is wrong because of a race condition, then it is just wrong. With > SNMP I would not like to have wrong counters - people use these counters > for accounting purposes. IPFW defines its counters as u_int64_t and uses mtx_lock/mtx_unlock while updating. Basically, this means lots of locking for every packet for IPFW-enables system. I do not say we need 64 bit stats in kernel by default. Just optionally, for those that have no problem with pps but likes to have 64 bit ifHC*'s. Eugene Grosbein From yongari at FreeBSD.org Mon Oct 20 06:48:11 2008 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Mon Oct 20 06:48:18 2008 Subject: kern/128143: [rl] NIC Realtek 8139 doesn't work with RAM higher than 4GB Message-ID: <200810200648.m9K6mAKJ031531@freefall.freebsd.org> Synopsis: [rl] NIC Realtek 8139 doesn't work with RAM higher than 4GB Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Oct 20 06:46:47 UTC 2008 Responsible-Changed-Why: It looks like rl(4) requires bus_dma(9) cleanup. Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=128143 From bugmaster at FreeBSD.org Mon Oct 20 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 20 11:08:28 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200810201106.m9KB6ti7082735@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 185 problems total. From alfred at freebsd.org Mon Oct 20 17:37:40 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Oct 20 17:37:47 2008 Subject: Closing connection from an accept_filter(9) In-Reply-To: <20081018090351.GA29876@verio.net> References: <48F93051.6040808@nttmcl.com> <20081018090351.GA29876@verio.net> Message-ID: <20081020173740.GK22503@elvis.mu.org> * David DeSimone [081018 02:25] wrote: > Eugene M. Kim wrote: > > > > Is it possible to close a connection from an accept filter, for > > example, in order to prevent an incoming connection with a malformed > > request body from ever reaching the userland? > > How would you propose to find out what is in the request body without > first accepting the connection? By writing a custom accept filter! :) -Alfred From alfred at freebsd.org Mon Oct 20 17:39:38 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Oct 20 17:39:45 2008 Subject: Timers in drivers vs userland In-Reply-To: <27cb3ada0810181728w3f41e3d0pe2fca8102b0c7206@mail.gmail.com> References: <27cb3ada0810181512qeab4020g912096848212ad86@mail.gmail.com> <27cb3ada0810181728w3f41e3d0pe2fca8102b0c7206@mail.gmail.com> Message-ID: <20081020173938.GL22503@elvis.mu.org> Have you tried using rtprio? You'll have to be really careful though so as not to jam up the system using it. -Alfred * Len Gross [081018 17:28] wrote: > Slight correction; I should have said more accurate usleep, not "timer." > > -- Len > > On Sat, Oct 18, 2008 at 3:12 PM, Len Gross wrote: > > If I place a timer directly in a driver (like Ethernet) will it be > > subject to less jitter and more consistency than if it were in > > Userland? > > > > I know FreeBSD is not "real time," but I need to be able to run a > > polling algorithm with about 1 ms accuracy. > > > > Thanks in advance. > > > > (Please tell me if there is a better list for this question.) > > > > -- Len > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- - Alfred Perlstein From mav at FreeBSD.org Mon Oct 20 18:01:15 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Oct 20 18:01:21 2008 Subject: Routing table issue Message-ID: <48FCB959.1010105@FreeBSD.org> I have noticed one strange issue on recent 7-STABLE/8-CURRENT: - this works: %route add 10.0.0.0/8 192.168.3.1 add net 10.0.0.0: gateway 192.168.3.1 %route add 10.0.0.0/9 192.168.3.2 add net 10.0.0.0: gateway 192.168.3.2 - this doesn't: %route add 0.0.0.0/0 192.168.3.1 add net 0.0.0.0: gateway 192.168.3.1 %route add 0.0.0.0/1 192.168.3.2 route: writing to routing socket: File exists add net 0.0.0.0: gateway 192.168.3.2: route already in table Who wants to explain me why 0.0.0.0/0 and 0.0.0.0/1 is now the same? PS: Same test on 6.2 works fine. -- Alexander Motin From freebsd-net-request at freebsd.org Tue Oct 21 12:36:06 2008 From: freebsd-net-request at freebsd.org (freebsd-net-request@freebsd.org) Date: Tue Oct 21 13:12:08 2008 Subject: freebsd-net Digest, Vol 290, Issue 2 Message-ID: <20081021120019.EF87910656D3@hub.freebsd.org> Send freebsd-net mailing list submissions to freebsd-net@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-net or, via email, send a message with subject or body 'help' to freebsd-net-request@freebsd.org You can reach the person managing the list at freebsd-net-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-net digest..." Today's Topics: 1. Re: Closing connection from an accept_filter(9) (Alfred Perlstein) 2. Re: Timers in drivers vs userland (Alfred Perlstein) 3. Routing table issue (Alexander Motin) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Oct 2008 10:37:40 -0700 From: Alfred Perlstein Subject: Re: Closing connection from an accept_filter(9) To: freebsd-net@freebsd.org Message-ID: <20081020173740.GK22503@elvis.mu.org> Content-Type: text/plain; charset=us-ascii * David DeSimone [081018 02:25] wrote: > Eugene M. Kim wrote: > > > > Is it possible to close a connection from an accept filter, for > > example, in order to prevent an incoming connection with a malformed > > request body from ever reaching the userland? > > How would you propose to find out what is in the request body without > first accepting the connection? By writing a custom accept filter! :) -Alfred ------------------------------ Message: 2 Date: Mon, 20 Oct 2008 10:39:38 -0700 From: Alfred Perlstein Subject: Re: Timers in drivers vs userland To: Len Gross Cc: "freebsd-net@freebsd.org" Message-ID: <20081020173938.GL22503@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Have you tried using rtprio? You'll have to be really careful though so as not to jam up the system using it. -Alfred * Len Gross [081018 17:28] wrote: > Slight correction; I should have said more accurate usleep, not "timer." > > -- Len > > On Sat, Oct 18, 2008 at 3:12 PM, Len Gross wrote: > > If I place a timer directly in a driver (like Ethernet) will it be > > subject to less jitter and more consistency than if it were in > > Userland? > > > > I know FreeBSD is not "real time," but I need to be able to run a > > polling algorithm with about 1 ms accuracy. > > > > Thanks in advance. > > > > (Please tell me if there is a better list for this question.) > > > > -- Len > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- - Alfred Perlstein ------------------------------ Message: 3 Date: Mon, 20 Oct 2008 20:01:13 +0300 From: Alexander Motin Subject: Routing table issue To: freebsd-net@freebsd.org Message-ID: <48FCB959.1010105@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed I have noticed one strange issue on recent 7-STABLE/8-CURRENT: - this works: %route add 10.0.0.0/8 192.168.3.1 add net 10.0.0.0: gateway 192.168.3.1 %route add 10.0.0.0/9 192.168.3.2 add net 10.0.0.0: gateway 192.168.3.2 - this doesn't: %route add 0.0.0.0/0 192.168.3.1 add net 0.0.0.0: gateway 192.168.3.1 %route add 0.0.0.0/1 192.168.3.2 route: writing to routing socket: File exists add net 0.0.0.0: gateway 192.168.3.2: route already in table Who wants to explain me why 0.0.0.0/0 and 0.0.0.0/1 is now the same? PS: Same test on 6.2 works fine. -- Alexander Motin ------------------------------ _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" End of freebsd-net Digest, Vol 290, Issue 2 ******************************************* From dudu.meyer at gmail.com Tue Oct 21 19:12:56 2008 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Tue Oct 21 19:13:03 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command Message-ID: Hello :) Please, follow: # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask 255.255.255.0 ifconfig: can't set link-level netmask or broadcast # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3 ifconfig: ether: bad value # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 # ifconfig rl0 ether 00:02:4f:0a:ce:f3 I ask you some help, how can I accomplish both tasks with rc_ng? In /etc/rc.conf ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3" Won't allow me to do what I want. Any suggestions? I would like like to edit /etc/rc.local and any other kind of "workaround". Can rc.conf issue ifconfig twice for the same nic? Or can ifconfig accomplish this task by someway else other than issuing the command twice? Thank you. -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From dudu.meyer at gmail.com Tue Oct 21 19:17:31 2008 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Tue Oct 21 19:17:38 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command Message-ID: Hello :) Please, follow: # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask 255.255.255.0 ifconfig: can't set link-level netmask or broadcast # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3 ifconfig: ether: bad value # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 # ifconfig rl0 ether 00:02:4f:0a:ce:f3 I ask you some help, how can I accomplish both tasks with rc_ng? In /etc/rc.conf ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3" Won't allow me to do what I want. Any suggestions? I would like like to edit /etc/rc.local and any other kind of "workaround". Can rc.conf issue ifconfig twice for the same nic? Or can ifconfig accomplish this task by someway else other than issuing the command twice? Thank you. -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From vanhu at FreeBSD.org Tue Oct 21 20:41:19 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Tue Oct 21 20:41:27 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: References: Message-ID: <20081021202509.GA2736@zeninc.net> On Tue, Oct 21, 2008 at 04:48:50PM -0200, Eduardo Meyer wrote: > Hello :) Hi. > Please, follow: > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask 255.255.255.0 > ifconfig: can't set link-level netmask or broadcast > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3 > ifconfig: ether: bad value > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? In /etc/rc.conf > > ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3" > > Won't allow me to do what I want. Any suggestions? I would like like > to edit /etc/rc.local and any other kind of "workaround". Can rc.conf > issue ifconfig twice for the same nic? > > Or can ifconfig accomplish this task by someway else other than > issuing the command twice? For your information, I already filled PR bin/124004 some moths ago related to that issue. Yvan. From vanhu at FreeBSD.org Tue Oct 21 20:42:20 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Tue Oct 21 20:42:27 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: References: Message-ID: <20081021202509.GA2736@zeninc.net> On Tue, Oct 21, 2008 at 04:48:50PM -0200, Eduardo Meyer wrote: > Hello :) Hi. > Please, follow: > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask 255.255.255.0 > ifconfig: can't set link-level netmask or broadcast > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3 > ifconfig: ether: bad value > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? In /etc/rc.conf > > ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3" > > Won't allow me to do what I want. Any suggestions? I would like like > to edit /etc/rc.local and any other kind of "workaround". Can rc.conf > issue ifconfig twice for the same nic? > > Or can ifconfig accomplish this task by someway else other than > issuing the command twice? For your information, I already filled PR bin/124004 some moths ago related to that issue. Yvan. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From jhay at meraka.org.za Tue Oct 21 20:45:36 2008 From: jhay at meraka.org.za (John Hay) Date: Tue Oct 21 20:45:42 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: References: Message-ID: <20081021204532.GA83935@zibbi.meraka.csir.co.za> On Tue, Oct 21, 2008 at 04:48:50PM -0200, Eduardo Meyer wrote: > Hello :) > > Please, follow: > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask 255.255.255.0 > ifconfig: can't set link-level netmask or broadcast > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3 > ifconfig: ether: bad value > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? In /etc/rc.conf > > ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3" > > Won't allow me to do what I want. Any suggestions? I would like like > to edit /etc/rc.local and any other kind of "workaround". Can rc.conf > issue ifconfig twice for the same nic? What about: ifconfig_rl0="ether 00:02:4f:0a:ce:f3" ipv4_addrs_rl0="192.168.2.12/24" John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From jhay at meraka.org.za Tue Oct 21 20:46:32 2008 From: jhay at meraka.org.za (John Hay) Date: Tue Oct 21 20:47:02 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: References: Message-ID: <20081021204532.GA83935@zibbi.meraka.csir.co.za> On Tue, Oct 21, 2008 at 04:48:50PM -0200, Eduardo Meyer wrote: > Hello :) > > Please, follow: > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask 255.255.255.0 > ifconfig: can't set link-level netmask or broadcast > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3 > ifconfig: ether: bad value > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? In /etc/rc.conf > > ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3" > > Won't allow me to do what I want. Any suggestions? I would like like > to edit /etc/rc.local and any other kind of "workaround". Can rc.conf > issue ifconfig twice for the same nic? What about: ifconfig_rl0="ether 00:02:4f:0a:ce:f3" ipv4_addrs_rl0="192.168.2.12/24" John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From ccowart at rescomp.berkeley.edu Tue Oct 21 20:59:13 2008 From: ccowart at rescomp.berkeley.edu (Christopher Cowart) Date: Tue Oct 21 20:59:18 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: References: Message-ID: <20081021204007.GS66228@hal.rescomp.berkeley.edu> Eduardo Meyer wrote: > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? In > /etc/rc.conf Somebody might have a hint for a single ifconfig command, but you can also create the file /etc/start_if.rl0 with any additional commands to be run by rc. This will get sourced automatically by rc _before_ the value of ifconfig_rl0 in /etc/rc.conf. For example, in /etc/rc.conf, leave | ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0" And in /etc/start_if.rl0, add: | ifconfig rl0 ether 00:02:4f:0a:ce:f3 -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081021/136f6c9c/attachment.pgp From tdcmystere at gmail.com Tue Oct 21 21:25:45 2008 From: tdcmystere at gmail.com (Antipov Dima) Date: Tue Oct 21 21:25:52 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: <20081021204007.GS66228@hal.rescomp.berkeley.edu> References: <20081021204007.GS66228@hal.rescomp.berkeley.edu> Message-ID: and sysinstall not work for you? 2008/10/21 Christopher Cowart > Eduardo Meyer wrote: > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > > > I ask you some help, how can I accomplish both tasks with rc_ng? In > > /etc/rc.conf > > Somebody might have a hint for a single ifconfig command, but you can > also create the file /etc/start_if.rl0 with any additional commands to > be run by rc. This will get sourced automatically by rc _before_ the > value of ifconfig_rl0 in /etc/rc.conf. > > For example, in /etc/rc.conf, leave > > | ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0" > > And in /etc/start_if.rl0, add: > > | ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > -- > Chris Cowart > Network Technical Lead > Network & Infrastructure Services, RSSP-IT > UC Berkeley > From scrappy at hub.org Wed Oct 22 04:20:08 2008 From: scrappy at hub.org (Marc G. Fournier) Date: Wed Oct 22 04:20:16 2008 Subject: tap devices ... restricting IP? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it possible to assign an IP to a tap device, used by something like QEMU, such that someone *inside* the QEMU environment can't modify? Or, if they do modify their own IP, the network inside of QEMU will break, as the internal IP doesn't match what is attached to tap? I'm not seeing anything to that effect in the tap manual, but the part talking about 'control' seems to indicate that you can do this ... - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj+paMACgkQ4QvfyHIvDvPMRQCdH0hfp3Gp0N4bHwmAvgrNEOlh lRUAoKBA9xzk7umZ782fsODzGH9FpNpM =REoF -----END PGP SIGNATURE----- From maciej at suszko.eu Wed Oct 22 04:53:33 2008 From: maciej at suszko.eu (Maciej Suszko) Date: Wed Oct 22 04:53:45 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: References: Message-ID: <20081021220857.6877d792@suszko.eu> "Eduardo Meyer" wrote: > Hello :) > > Please, follow: > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask > 255.255.255.0 ifconfig: can't set link-level netmask or broadcast > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether > 00:02:4f:0a:ce:f3 ifconfig: ether: bad value > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? > In /etc/rc.conf > > ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether > 00:02:4f:0a:ce:f3" > > Won't allow me to do what I want. Any suggestions? I would like like > to edit /etc/rc.local and any other kind of "workaround". Can rc.conf > issue ifconfig twice for the same nic? > > Or can ifconfig accomplish this task by someway else other than > issuing the command twice? Use ifconfig_rl0_alias0 for second task. -- regards, Maciej Suszko. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081022/fe014c7d/signature.pgp From maciej at suszko.eu Wed Oct 22 04:54:46 2008 From: maciej at suszko.eu (Maciej Suszko) Date: Wed Oct 22 04:54:52 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: References: Message-ID: <20081021220857.6877d792@suszko.eu> "Eduardo Meyer" wrote: > Hello :) > > Please, follow: > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask > 255.255.255.0 ifconfig: can't set link-level netmask or broadcast > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether > 00:02:4f:0a:ce:f3 ifconfig: ether: bad value > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? > In /etc/rc.conf > > ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether > 00:02:4f:0a:ce:f3" > > Won't allow me to do what I want. Any suggestions? I would like like > to edit /etc/rc.local and any other kind of "workaround". Can rc.conf > issue ifconfig twice for the same nic? > > Or can ifconfig accomplish this task by someway else other than > issuing the command twice? Use ifconfig_rl0_alias0 for second task. -- regards, Maciej Suszko. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081022/fe014c7d/signature-0001.pgp From bakul at bitblocks.com Wed Oct 22 05:07:29 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Wed Oct 22 05:07:36 2008 Subject: tap devices ... restricting IP? In-Reply-To: Your message of "Wed, 22 Oct 2008 01:01:39 -0300." References: Message-ID: <20081022044901.E92635B29@mail.bitblocks.com> On Wed, 22 Oct 2008 01:01:39 -0300 "Marc G. Fournier" wrote: > Is it possible to assign an IP to a tap device, used by something like QEMU, > such that someone *inside* the QEMU environment can't modify? Or, if they do > modify their own IP, the network inside of QEMU will break, as the internal IP > doesn't match what is attached to tap? > > I'm not seeing anything to that effect in the tap manual, but the part talking > about 'control' seems to indicate that you can do this ... This is not something the tap driver does for you. But you can use DHCP to give the qemu machine its own IP address + setup some firewall rules so that no other IP address can be sourced from the qemu machine. From fabien.thomas at netasq.com Wed Oct 22 08:39:30 2008 From: fabien.thomas at netasq.com (Fabien Thomas) Date: Wed Oct 22 08:39:38 2008 Subject: Missing fix for fxp driver (FreeBSD 6.x) Message-ID: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c.diff?r1=1.217.2.15;r2=1.217.2.16;f=h This fix is really necessary (dealock of the interface in case of cluster shortage) and not commited in 6.x (but commited in RELENG_5 RELENG_7 and HEAD) Regards, Fabien From pluknet at gmail.com Wed Oct 22 09:20:09 2008 From: pluknet at gmail.com (pluknet) Date: Wed Oct 22 09:20:16 2008 Subject: Missing fix for fxp driver (FreeBSD 6.x) In-Reply-To: References: Message-ID: 2008/10/22 Fabien Thomas : > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c.diff?r1=1.217.2.15;r2=1.217.2.16;f=h > > This fix is really necessary (dealock of the interface in case of cluster > shortage) and not commited in 6.x (but commited in RELENG_5 RELENG_7 and > HEAD) if_fxp.c r1.239, on which you point, was committed before 6.x was branched. -- wbr, pluknet From olgaknysh at gmail.com Wed Oct 22 07:10:44 2008 From: olgaknysh at gmail.com (Olga Knysh) Date: Wed Oct 22 11:20:15 2008 Subject: Problem with Netgraph Message-ID: <9e5e0250810212340wf683dc8i68235bf6634b4614@mail.gmail.com> Hello Mr Coobs! My name is Olga Knysh. I am from Russia. I study at Lomonosov Moscow State University at Physics Department and work in the Lab of Information Technologies. I have read Mr Coobs article about Netgraph and I am trying to make a simple bridge between two netcards, which are mounted at one computer. Mr Coobs advised me to ask you. Here is a code: mkpeer xl0: tee divert left name [ID_tee]: tee0 connect xl1: tee0: upper right ngctl connect . myhook left2right After I turn the scipt on, I get a problem, I cant ping the computer, that works as a bridge. Could this be becoase of the fact, that the computer with the two cards has only one IP adress for only one card. And the information doesn't proceed to switched computer. Can You help me to solve this problem? Best regards, Olga. From fabien.thomas at netasq.com Wed Oct 22 12:47:52 2008 From: fabien.thomas at netasq.com (Fabien Thomas) Date: Wed Oct 22 12:47:59 2008 Subject: Missing fix for fxp driver (FreeBSD 6.x) In-Reply-To: References: Message-ID: <0308873F-0ED4-4590-A2F1-51A4CD402EC5@netasq.com> Sorry for the noise... I've made a mistake with my local patch vs cvsweb vs commit info that seems to fix the same problem but with another code. If i've to rewrite my initial mail: The fxp deadlock (fixed on head by this commit http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c.diff?r1=1.266;r2=1.267) can be easily reproduced and maybe can be MFC in 6.4 and 7.1 ? When the interface is in deadlock the only way to recover is to do a ifconfig up. Fabien > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c.diff?r1=1.217.2.15;r2=1.217.2.16;f=h > > This fix is really necessary (dealock of the interface in case of > cluster shortage) and not commited in 6.x (but commited in RELENG_5 > RELENG_7 and HEAD) > > Regards, > Fabien From damien.deville at netasq.com Wed Oct 22 13:06:09 2008 From: damien.deville at netasq.com (Damien Deville) Date: Wed Oct 22 13:06:15 2008 Subject: RELENG_7 crash in if_vlan In-Reply-To: <48A2FBBD.1000503@netasq.com> References: <48A2FBBD.1000503@netasq.com> Message-ID: <48FF213B.9000303@netasq.com> Hi, Is there any progress on the MFC on this bugfix http://svn.freebsd.org/viewvc/base?view=revision&revision=182413 before 7.1 being released ? The PR is available there http://www.freebsd.org/cgi/query-pr.cgi?pr=126850 Regards, Damien Damien Deville wrote: > Hi, > > On today's checkout of RELENG_7 it is possible to crash the system using > the following commands: > > ifconfig vlan0 create > ifconfig vlan0 -vlandev > > Crash is located in if_vlan.c in vlan_unconfig_locked() when > dereferencing a NULL pointer (ifv->ifv_trunk) to access parent interface > using PARENT macro. > > Damien -- Damien Deville R&D engineer damien.deville@netasq.com http://www.netasq.com NETASQ - We secure IT From dudu.meyer at gmail.com Wed Oct 22 14:03:34 2008 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Wed Oct 22 14:03:46 2008 Subject: ifconfig won't allow me to change ether address and inet address in the same command In-Reply-To: <20081021204007.GS66228@hal.rescomp.berkeley.edu> References: <20081021204007.GS66228@hal.rescomp.berkeley.edu> Message-ID: On Tue, Oct 21, 2008 at 6:40 PM, Christopher Cowart wrote: > Eduardo Meyer wrote: >> # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 >> # ifconfig rl0 ether 00:02:4f:0a:ce:f3 >> >> I ask you some help, how can I accomplish both tasks with rc_ng? In >> /etc/rc.conf > > Somebody might have a hint for a single ifconfig command, but you can > also create the file /etc/start_if.rl0 with any additional commands to > be run by rc. This will get sourced automatically by rc _before_ the > value of ifconfig_rl0 in /etc/rc.conf. > > For example, in /etc/rc.conf, leave > > | ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0" > > And in /etc/start_if.rl0, add: > > | ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > -- > Chris Cowart > Network Technical Lead > Network & Infrastructure Services, RSSP-IT > UC Berkeley > Thank you Chris, I didnt know about /etc/start_if., would do for me, however I will use ip4_addrs_if to keep things in rc.conf :) Thank you :-) -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From dschulz at gmail.com Wed Oct 22 14:12:20 2008 From: dschulz at gmail.com (Diego Schulz) Date: Wed Oct 22 14:12:27 2008 Subject: xl0: watchdog timeout Message-ID: <47dcfe400810220645h603a6dcfpbc7d2da845a0b401@mail.gmail.com> Hi all, I'm having this annoying warning every now and then, $ dmesg | grep ^xl (snip) ... xl0: watchdog timeout xl0: link state changed to DOWN xl0: link state changed to UP (snip) ... What pciconf says is: $ pciconf -v -l xl0@pci0:2:5:0: class=0x020000 card=0x100010b7 chip=0x920010b7 rev=0x74 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' class = network subclass = ethernet xl1@pci0:2:6:0: class=0x020000 card=0x100010b7 chip=0x920010b7 rev=0x74 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' class = network subclass = ethernet dmesg also shows xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xd000-0xd07f mem 0xfea40000-0xfea4007f irq 21 at device 6.0 on pci2 xlphy1: <3c905C 10/100 internal PHY> PHY 24 on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I'm running FreeBSD 7.1-PRERELEASE #2: Mon Oct 20 11:46:22 PYST 2008. My kernel configuration is in basically GENERIC, but I added the ALTQ thingy, that enables queuing capability with PF. Also, the "watchdog timeout" message first appeared running GENERIC, right away after I ended installing 7.0. I've updated kernel and world every 2-3 days since then, in the hope it will get fixed in RELENG_7 at some point in time ;) Hey.. its a 3Com! (cheap one, but 3Com at least).. should I replace the NICs for another brand/model? Any advice or suggestion will be greatly appreciated. Thanks in advance! From bz at FreeBSD.org Wed Oct 22 18:12:59 2008 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Wed Oct 22 18:13:06 2008 Subject: bin/116643: [patch] [request] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD Message-ID: <200810221812.m9MICvWN041990@freefall.freebsd.org> Synopsis: [patch] [request] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD State-Changed-From-To: feedback->open State-Changed-By: bz State-Changed-When: Wed Oct 22 18:12:03 UTC 2008 State-Changed-Why: Feedback received. Responsible-Changed-From-To: bz->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Wed Oct 22 18:12:03 UTC 2008 Responsible-Changed-Why: Assign it bck to the masses; I think this needs further discussion. http://www.freebsd.org/cgi/query-pr.cgi?pr=116643 From dschulz at gmail.com Wed Oct 22 18:14:04 2008 From: dschulz at gmail.com (Diego Schulz) Date: Wed Oct 22 18:14:13 2008 Subject: xl0: watchdog timeout Message-ID: <47dcfe400810221114t9422eaalf01b8b61caf9e4bd@mail.gmail.com> Hi all, I'm having this annoying warning every now and then, $ dmesg | grep ^xl (snip) ... xl0: watchdog timeout xl0: link state changed to DOWN xl0: link state changed to UP (snip) ... What pciconf says is: $ pciconf -v -l xl0@pci0:2:5:0: class=0x020000 card=0x100010b7 chip=0x920010b7 rev=0x74 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' class = network subclass = ethernet xl1@pci0:2:6:0: class=0x020000 card=0x100010b7 chip=0x920010b7 rev=0x74 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' class = network subclass = ethernet dmesg also shows xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xd000-0xd07f mem 0xfea40000-0xfea4007f irq 21 at device 6.0 on pci2 xlphy1: <3c905C 10/100 internal PHY> PHY 24 on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I'm running FreeBSD 7.1-PRERELEASE #2: Mon Oct 20 11:46:22 PYST 2008. My kernel configuration is in basically GENERIC, but I added the ALTQ thingy, that enables queuing capability with PF. Also, the "watchdog timeout" message first appeared running GENERIC, right away after I ended installing 7.0. I've updated kernel and world every 2-3 days since then, in the hope it will get fixed in RELENG_7 at some point in time ;) Hey.. its a 3Com! (cheap one, but 3Com at least).. should I replace the NICs for another brand/model? Any advice or suggestion will be greatly appreciated. Thanks in advance! From remko at FreeBSD.org Thu Oct 23 09:09:32 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Thu Oct 23 09:09:38 2008 Subject: bin/128295: ifconfig does not print TOE4 or TOE6 capabilities Message-ID: <200810230909.m9N99Wfa025241@freefall.freebsd.org> Synopsis: ifconfig does not print TOE4 or TOE6 capabilities Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Oct 23 09:09:32 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=128295 From kordex at gmail.com Thu Oct 23 13:30:30 2008 From: kordex at gmail.com (kordex -) Date: Thu Oct 23 13:30:38 2008 Subject: nfe driver bad performance on FreeBSD 7 Message-ID: <8b8dd87a0810230602i39bbb291h6777f41022d3f0d4@mail.gmail.com> Same issue as http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-09/msg00278.html I got HP Pavilion dv6646eo laptop with same network chip. Max throughput is 800kB/s with scp. same with generic kernel. nfe0: flags=8843 metric 0 mtu 1500 options=8 ether 00:00:00:00:00:00 inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active lilian# MAC being all zeros is not done by me. It's BIOS doing that. I wonder if that can cause things like this. No PXE Boot for me :| Should I send this to warranty for that? lilian# uname -a FreeBSD lilian.xnet.kx 7.0-RELEASE FreeBSD 7.0-RELEASE #3: Sat Sep 27 20:36:01 UTC 2008 root@lilian.xnet.kx:/usr/obj/usr/src/sys/LILIAN_KERN i386 lilian# dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #3: Sat Sep 27 20:36:01 UTC 2008 root@lilian.xnet.kx:/usr/obj/usr/src/sys/LILIAN_KERN Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-58 (1908.67-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60f81 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 real memory = 2146828288 (2047 MB) avail memory = 2095497216 (1998 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ACPI Error (dsopcode-0671): Field [I9MN] at 544 exceeds Buffer [IORT] size 464 (bits) [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xc4de7d40), AE_AML_BUFFER_LIMIT ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xc4de7d40), AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.LPC0.PMIO - AE_AML_BUFFER_LIMIT Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 cpu0: on acpi0 powernow0: on cpu0 acpi_throttle0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.3 (no driver attached) ohci0: mem 0xf2486000-0xf2486fff irq 18 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xf2488000-0xf24880ff irq 17 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered ugen0: on uhub1 nfe0: port 0x30e0-0x30e7 mem 0xf2487000-0xf2487fff irq 20 at device 6.0 on pci0 miibus0: on nfe0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: [FILTER] pcm0: mem 0xf2480000-0xf2483fff irq 21 at device 7.0 on pci0 pcm0: [ITHREAD] pcib1: at device 8.0 on pci0 pci_link0: BIOS IRQ 15 for 7.5.INTA is invalid pci_link1: BIOS IRQ 10 for 7.5.INTB is invalid pci7: on pcib1 fwohci0: <1394 Open Host Controller Interface> irq 9 at device 5.0 on pci7 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:00:00 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwip0: on firewire0 fwip0: Firewire address: 00:00:00:00:00:00:00:00 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci7: at device 5.1 (no driver attached) pci7: at device 5.2 (no driver attached) pci7: at device 5.3 (no driver attached) pci7: at device 5.4 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30f8-0x30ff,0x30ec-0x30ef,0x30f0-0x30f7,0x30e8-0x30eb,0x30d0-0x30df mem 0xf2484000-0xf2485fff irq 23 at device 10.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib2: at device 11.0 on pci0 pci1: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: at device 13.0 on pci0 pci5: on pcib4 vgapci0: port 0x4000-0x407f mem 0xce000000-0xceffffff,0xd0000000-0xdfffffff,0xcc000000-0xcdffffff irq 19 at device 0.0 on pci5 acpi_video0: on vgapci0 pcib5: at device 14.0 on pci0 pci9: on pcib5 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-72.6C) speaker0: port 0x61 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xcd800-0xcefff,0xdf000-0xdffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub0 ums0: 3 buttons and Z dir. ugen1: on uhub0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acpi_tz0: _CRT value is absurd, ignored (-72.6C) acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master UDMA33 pcm0: pcm0: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s2a KLD green_saver.ko: depends on splash - not available lilian# From sclark at netwolves.com Thu Oct 23 15:16:51 2008 From: sclark at netwolves.com (Steve Clark) Date: Thu Oct 23 15:16:58 2008 Subject: quagga 0.99.10 Message-ID: <49009059.5050304@netwolves.com> Hi, I am having a problem on FreeBSD 6.3-p5. I am using gre over vpn for ospf. When I do a tcpdump on the gre tunnel I immediately start seeing in the my ospfd log file the following: 2008/10/23 10:39:54 OSPF: *** sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 68, interface gre1, mtu 1412: Network is down 2008/10/23 10:40:04 OSPF: *** sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 68, interface gre1, mtu 1412: Network is down 2008/10/23 10:40:14 OSPF: *** sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 68, interface gre1, mtu 1412: Network is down and I lose my ospf routes in the routing table. If I exit tcpdump and do and ifconfig gre1 it shows it is up. And in fact in the tcpdump I see Hello packets from the other side. Even ospf thinks it is up date;sudo vtysh -c 'sh ip osp int gre1' Thu Oct 23 10:51:51 EDT 2008 gre1 is up ifindex 10, MTU 1412 bytes, BW 0 Kbit Internet Address 10.255.13.30/30, Peer 10.255.13.29, Area 0.0.0.2 MTU mismatch detection:disabled Router ID 10.254.150.1, Network Type POINTOPOINT, Cost: 10 Transmit Delay is 1 sec, State Point-To-Point, Priority 0 No designated router on this network No backup designated router on this network Multicast group memberships: OSPFAllRouters Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5 Hello due in 3.069s Neighbor Count is 1, Adjacent neighbor count is 0 >From log file: 2008/10/23 10:51:54 OSPF: *** sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 68, interface gre1, mtu 1412: Network is down Anyone have an idea on what is causing this? I also have this problem with 0.99.6 From spawk at acm.poly.edu Thu Oct 23 19:56:56 2008 From: spawk at acm.poly.edu (Boris Kochergin) Date: Thu Oct 23 19:57:07 2008 Subject: if_gif/if_bridge problem In-Reply-To: <20080904164949.GA76939@svzserv.kemerovo.su> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> <20080904164949.GA76939@svzserv.kemerovo.su> Message-ID: <4900D086.2000703@acm.poly.edu> Eugene Grosbein wrote: > On Thu, Sep 04, 2008 at 11:49:06AM -0400, Boris Kochergin wrote: > > >> Ahoy. I've been using the patch for a while, and, recently, when the >> load on the wireless network I needed it for has increased, I've started >> getting kernel panics that I think the patch is responsible for. The >> panics are usually foreshadowed by messages in the style of "Sep 3 >> 11:34:14 unique kernel: delayed m_pullup, m->len: 22 off: 38333 p: 97" >> in the kernel buffer. I like to think that I've eliminated the >> possibility of bad hardware by changing the motherboard, memory, and >> Ethernet controllers in the machine, and have tried both Eugene's >> original patchset and the one that was committed to 7-STABLE, with the >> same ill effects. Any ideas about what might be wrong, or shall I set >> about getting a backtrace? Thanks. >> > > Yes, you should. And I think you no more need my patches after > Andrew's fixes to gif(4). But if you need my changes to lagg(4), > you should now use version corrected to apply to recent RELENG_7: > ftp://www.kuzbass.ru/pub/freebsd/lagg-0.2.tgz > > There were no functional changes, only context changes after Anrew's commit. > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Pardon the delay, but here it is. Let me know if I can provide anything else. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc05bfb83 stack pointer = 0x28:0xe9f3f67c frame pointer = 0x28:0xe9f3f6a4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 25 (irq18: xl0) trap number = 12 panic: page fault cpuid = 1 Uptime: 20h30m4s Physical memory: 2551 MB Dumping 325 MB: 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 241 dumptid = curthread->td_tid; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 #1 0xc05583ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0558861 in panic (fmt=Could not find the frame base for "panic". ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07c033d in trap_fatal (frame=0xe9f3f63c, eva=12) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07bfee0 in trap_pfault (frame=0xe9f3f63c, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc07bf79d in trap (frame=0xe9f3f63c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc079ed4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05bfb83 in m_copym (m=0x0, off0=1500, len=20, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:538 #8 0xc065c536 in ip_fragment (ip=0xc60fabe8, m_frag=0xe9f3f7a8, mtu=1500, if_hwassist_flags=0, sw_csum=769) at /usr/src/sys/netinet/ip_output.c:726 #9 0xc065bf35 in ip_output (m=0xc60fab00, opt=0x0, ro=0xc589dd24, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:565 #10 0xc064c431 in in_gif_output (ifp=0xc58a9000, family=18, m=0xc60fab00) at /usr/src/sys/netinet/in_gif.c:228 #11 0xc06321c3 in gif_output (ifp=0xc58a9000, m=0xc60f9900, dst=0xc58b52a0, rt=0x0) at /usr/src/sys/net/if_gif.c:455 #12 0xc0631e29 in gif_start (ifp=0xc58a9000) at /usr/src/sys/net/if_gif.c:352 #13 0xc06297a9 in bridge_enqueue (sc=0xc58d6600, dst_ifp=0xc58a9000, m=0x0) at /usr/src/sys/net/if_bridge.c:1714 #14 0xc062b80e in bridge_broadcast (sc=0xc58d6600, src_if=0xc58a3400, m=0xc60f9900, runfilt=1) at /usr/src/sys/net/if_bridge.c:2394 #15 0xc062a5e4 in bridge_forward (sc=0xc58d6600, sbif=0xc56f3600, m=0xc60f9900) at /usr/src/sys/net/if_bridge.c:2018 #16 0xc062af00 in bridge_input (ifp=0xc58a3400, m=0xc614e700) at /usr/src/sys/net/if_bridge.c:2189 #17 0xc06324dd in gif_input (m=0xc614e700, af=18, ifp=0xc58a3400) at /usr/src/sys/net/if_gif.c:564 #18 0xc064c89e in in_gif_input (m=0xc614e700, off=20) at /usr/src/sys/netinet/in_gif.c:326 #19 0xc0653f85 in encap4_input (m=0xc614e700, off=20) at /usr/src/sys/netinet/ip_encap.c:191 #20 0xc065819f in ip_input (m=0xc614e700) at /usr/src/sys/netinet/ip_input.c:665 #21 0xc06346ba in netisr_dispatch (num=2, m=0xc614e700) at /usr/src/sys/net/netisr.c:185 #22 0xc0630918 in ether_demux (ifp=0xc56bc000, m=0xc614e700) at /usr/src/sys/net/if_ethersubr.c:834 #23 0xc06306e2 in ether_input (ifp=0xc56bc000, m=0xc614e700) at /usr/src/sys/net/if_ethersubr.c:692 #24 0xc0704874 in xl_rxeof (sc=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2062 #25 0xc070531e in xl_intr (arg=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2298 #26 0xc05328a0 in ithread_execute_handlers (p=0xc56ec2ac, ie=0xc55e3d00) at /usr/src/sys/kern/kern_intr.c:1036 #27 0xc0532a63 in ithread_loop (arg=0xc56f2430) at /usr/src/sys/kern/kern_intr.c:1121 #28 0xc0530b8c in fork_exit (callout=0xc05329e0 , arg=0xc56f2430, frame=0xe9f3fd38) at /usr/src/sys/kern/kern_fork.c:781 #29 0xc079edc0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 From eugen at kuzbass.ru Fri Oct 24 04:51:45 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Oct 24 04:51:52 2008 Subject: if_gif/if_bridge problem In-Reply-To: <4900D086.2000703@acm.poly.edu> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> <20080904164949.GA76939@svzserv.kemerovo.su> <4900D086.2000703@acm.poly.edu> Message-ID: <20081024042123.GA45452@svzserv.kemerovo.su> On Thu, Oct 23, 2008 at 03:29:10PM -0400, Boris Kochergin wrote: > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 > 241 dumptid = curthread->td_tid; > (kgdb) where > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 > #1 0xc05583ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0558861 in panic (fmt=Could not find the frame base for "panic". > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc07c033d in trap_fatal (frame=0xe9f3f63c, eva=12) at > /usr/src/sys/i386/i386/trap.c:899 > #4 0xc07bfee0 in trap_pfault (frame=0xe9f3f63c, usermode=0, eva=12) at > /usr/src/sys/i386/i386/trap.c:812 > #5 0xc07bf79d in trap (frame=0xe9f3f63c) at > /usr/src/sys/i386/i386/trap.c:490 > #6 0xc079ed4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc05bfb83 in m_copym (m=0x0, off0=1500, len=20, wait=1) at > /usr/src/sys/kern/uipc_mbuf.c:538 > #8 0xc065c536 in ip_fragment (ip=0xc60fabe8, m_frag=0xe9f3f7a8, > mtu=1500, if_hwassist_flags=0, sw_csum=769) at > /usr/src/sys/netinet/ip_output.c:726 > #9 0xc065bf35 in ip_output (m=0xc60fab00, opt=0x0, ro=0xc589dd24, > flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:565 > #10 0xc064c431 in in_gif_output (ifp=0xc58a9000, family=18, > m=0xc60fab00) at /usr/src/sys/netinet/in_gif.c:228 > #11 0xc06321c3 in gif_output (ifp=0xc58a9000, m=0xc60f9900, > dst=0xc58b52a0, rt=0x0) at /usr/src/sys/net/if_gif.c:455 > #12 0xc0631e29 in gif_start (ifp=0xc58a9000) at > /usr/src/sys/net/if_gif.c:352 > #13 0xc06297a9 in bridge_enqueue (sc=0xc58d6600, dst_ifp=0xc58a9000, > m=0x0) at /usr/src/sys/net/if_bridge.c:1714 > #14 0xc062b80e in bridge_broadcast (sc=0xc58d6600, src_if=0xc58a3400, > m=0xc60f9900, runfilt=1) at /usr/src/sys/net/if_bridge.c:2394 > #15 0xc062a5e4 in bridge_forward (sc=0xc58d6600, sbif=0xc56f3600, > m=0xc60f9900) at /usr/src/sys/net/if_bridge.c:2018 > #16 0xc062af00 in bridge_input (ifp=0xc58a3400, m=0xc614e700) at > /usr/src/sys/net/if_bridge.c:2189 > #17 0xc06324dd in gif_input (m=0xc614e700, af=18, ifp=0xc58a3400) at > /usr/src/sys/net/if_gif.c:564 > #18 0xc064c89e in in_gif_input (m=0xc614e700, off=20) at > /usr/src/sys/netinet/in_gif.c:326 > #19 0xc0653f85 in encap4_input (m=0xc614e700, off=20) at > /usr/src/sys/netinet/ip_encap.c:191 > #20 0xc065819f in ip_input (m=0xc614e700) at > /usr/src/sys/netinet/ip_input.c:665 > #21 0xc06346ba in netisr_dispatch (num=2, m=0xc614e700) at > /usr/src/sys/net/netisr.c:185 > #22 0xc0630918 in ether_demux (ifp=0xc56bc000, m=0xc614e700) at > /usr/src/sys/net/if_ethersubr.c:834 > #23 0xc06306e2 in ether_input (ifp=0xc56bc000, m=0xc614e700) at > /usr/src/sys/net/if_ethersubr.c:692 > #24 0xc0704874 in xl_rxeof (sc=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2062 > #25 0xc070531e in xl_intr (arg=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2298 > #26 0xc05328a0 in ithread_execute_handlers (p=0xc56ec2ac, ie=0xc55e3d00) > at /usr/src/sys/kern/kern_intr.c:1036 > #27 0xc0532a63 in ithread_loop (arg=0xc56f2430) at > /usr/src/sys/kern/kern_intr.c:1121 > #28 0xc0530b8c in fork_exit (callout=0xc05329e0 , > arg=0xc56f2430, frame=0xe9f3fd38) at /usr/src/sys/kern/kern_fork.c:781 > #29 0xc079edc0 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:205 Very nice backtrace. If your system runs without patches, you should send PR with all details included (system version, interface configuration, backtrace and how-to-repeat recipe. Please report back PR number once you get it. Eugene Grosbein From rwatson at FreeBSD.org Fri Oct 24 13:22:19 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Oct 24 13:22:31 2008 Subject: tap devices ... restricting IP? In-Reply-To: References: Message-ID: On Wed, 22 Oct 2008, Marc G. Fournier wrote: > Is it possible to assign an IP to a tap device, used by something like QEMU, > such that someone *inside* the QEMU environment can't modify? Or, if they > do modify their own IP, the network inside of QEMU will break, as the > internal IP doesn't match what is attached to tap? > > I'm not seeing anything to that effect in the tap manual, but the part > talking about 'control' seems to indicate that you can do this ... Use a firewall to prevent receiving packets over the interface from any IP other than the one you are willing to accept. Think of a tap interface as simply being a normal ethernet interface hung off a network to the VM and treat it that way in the rules -- for example, dropping IP from addresses other than the designated one when received from the tap interface. Robert N M Watson Computer Laboratory University of Cambridge From gizmen at blurp.pl Fri Oct 24 14:30:31 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Fri Oct 24 14:30:38 2008 Subject: does freebsd support so called Scalable I/O on intel NIC ? Message-ID: <200810241612.04764.gizmen@blurp.pl> Hi, i am looking for a good NIC from NIC to put on our quite busy router based on freebsd 6.3 (soon 7.x) I've found server NIC from intel and there is such a thing like scalable I/O on windows and linux. (from web page) "load balancing on multiple CPUs Increases performance on multi-processor systems by efficiently balancing network loads across CPU cores when used with Receive-Side Scaling from Microsoft or Scalable I/O on Linux*" Is such thing supported on freebsd ? And one more question. Does anybody has some data what is difference on desktop and server NIC from INTEL in pps or so. I wonder how faster could be those server NICs thanks From ivoras at freebsd.org Fri Oct 24 14:40:39 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Oct 24 14:40:47 2008 Subject: does freebsd support so called Scalable I/O on intel NIC ? In-Reply-To: <200810241612.04764.gizmen@blurp.pl> References: <200810241612.04764.gizmen@blurp.pl> Message-ID: Bartosz Giza wrote: > Hi, > > i am looking for a good NIC from NIC to put on our quite busy router based > on freebsd 6.3 (soon 7.x) > I've found server NIC from intel and there is such a thing like scalable I/O > on windows and linux. > (from web page) > > "load balancing on multiple CPUs Increases > performance on multi-processor systems by efficiently > balancing network loads across CPU cores when used > with Receive-Side Scaling from Microsoft or Scalable > I/O on Linux*" > > Is such thing supported on freebsd ? I don't think so - I've run into problems when IO handling is limited to a single CPU. There are apparently unofficial patches for this here: http://people.yandex-team.ru/~wawa/ but I haven't tried them yet. Other components of "scalable IO" are present - interrupt moderation, TSO. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081024/9bb81462/signature.pgp From if at xip.at Fri Oct 24 15:13:50 2008 From: if at xip.at (Ingo Flaschberger) Date: Fri Oct 24 15:13:57 2008 Subject: does freebsd support so called Scalable I/O on intel NIC ? In-Reply-To: References: <200810241612.04764.gizmen@blurp.pl> Message-ID: Dear Bartosz, >> i am looking for a good NIC from NIC to put on our quite busy router based >> on freebsd 6.3 (soon 7.x) >> I've found server NIC from intel and there is such a thing like scalable I/O >> on windows and linux. >> (from web page) how "loaded" is your router? Bandwith (bbs) and Packets (pps) ? Kind regards, Ingo Flaschberger From crapsh at monkeybrains.net Fri Oct 24 22:48:43 2008 From: crapsh at monkeybrains.net (Rudy) Date: Fri Oct 24 22:48:50 2008 Subject: does freebsd support so called Scalable I/O on intel NIC ? In-Reply-To: References: <200810241612.04764.gizmen@blurp.pl> Message-ID: <49024DDB.4090103@monkeybrains.net> Ingo Flaschberger wrote: > Dear Bartosz, > >>> i am looking for a good NIC from NIC to put on our quite busy router >>> based >>> on freebsd 6.3 (soon 7.x) > how "loaded" is your router? > > Bandwith (bbs) and Packets (pps) ? > > Kind regards, > Ingo Flaschberger We have a 6.3-STABLE router that has worked flawlessly with our quad port Intel card... 100 - 200Mbps with occational peaks of 500 - 600Mbps, no problem. FYI, Our newer FreeBSD 7.0 router (with a slightly newer quad Intel Pro PT card) has watchdog timeouts... a couple of 1 or 2 second outages a day. Maybe 6.3 is better... any one else seeing watchdog timeouts with their emX? How many bbs are people getting out of their boxes in production? Rudy ---------------- MonkeyBrains.net Colo, IPv4, IPv6 From kmacy at freebsd.org Fri Oct 24 23:18:03 2008 From: kmacy at freebsd.org (Kip Macy) Date: Fri Oct 24 23:18:10 2008 Subject: does freebsd support so called Scalable I/O on intel NIC ? In-Reply-To: <200810241612.04764.gizmen@blurp.pl> References: <200810241612.04764.gizmen@blurp.pl> Message-ID: <3c1674c90810241552v5fd3e58fvf6bd43ad94558b1e@mail.gmail.com> It is simply a knob to adjust on all new server network cards. You could benefit from it on a predominantly UDP workload. I believe that tcp_input is still sufficiently serialized that it would not make sense for TCP workloads. -Kip On Fri, Oct 24, 2008 at 2:12 PM, Bartosz Giza wrote: > Hi, > > i am looking for a good NIC from NIC to put on our quite busy router based > on freebsd 6.3 (soon 7.x) > I've found server NIC from intel and there is such a thing like scalable I/O > on windows and linux. > (from web page) > > "load balancing on multiple CPUs Increases > performance on multi-processor systems by efficiently > balancing network loads across CPU cores when used > with Receive-Side Scaling from Microsoft or Scalable > I/O on Linux*" > > Is such thing supported on freebsd ? > > And one more question. Does anybody has some data what is difference on > desktop and server NIC from INTEL in pps or so. > I wonder how faster could be those server NICs > > thanks > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From pyunyh at gmail.com Sat Oct 25 08:32:30 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Oct 25 08:32:37 2008 Subject: nfe driver bad performance on FreeBSD 7 In-Reply-To: <8b8dd87a0810230602i39bbb291h6777f41022d3f0d4@mail.gmail.com> References: <8b8dd87a0810230602i39bbb291h6777f41022d3f0d4@mail.gmail.com> Message-ID: <20081025083027.GD59215@cdnetworks.co.kr> On Thu, Oct 23, 2008 at 04:02:48PM +0300, kordex - wrote: > Same issue as > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-09/msg00278.html > > I got HP Pavilion dv6646eo laptop with same network chip. Max throughput is > 800kB/s with scp. same with generic kernel. > > nfe0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:00:00:00:00:00 > inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > lilian# > > MAC being all zeros is not done by me. It's BIOS doing that. I wonder if > that can cause things like this. No PXE Boot for me :| Should I send this to > warranty for that? > Don't use all zeroed ethernet address. You can assign fake ethernet address to nfe(4) with "ifconfig nfe0 ether 00:01:02:03:04:05". The problem is why nfe(4) got all zeord station address from controller. Does nve(4) also show the same ethernet address? > lilian# uname -a > FreeBSD lilian.xnet.kx 7.0-RELEASE FreeBSD 7.0-RELEASE #3: Sat Sep 27 > 20:36:01 UTC 2008 root@lilian.xnet.kx:/usr/obj/usr/src/sys/LILIAN_KERN > i386 > > > lilian# dmesg > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-RELEASE #3: Sat Sep 27 20:36:01 UTC 2008 > root@lilian.xnet.kx:/usr/obj/usr/src/sys/LILIAN_KERN > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-58 (1908.67-MHz 686-class > CPU) > Origin = "AuthenticAMD" Id = 0x60f81 Stepping = 1 > [...] > nfe0: port 0x30e0-0x30e7 mem > 0xf2487000-0xf2487fff irq 20 at device 6.0 on pci0 > miibus0: on nfe0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: [FILTER] There was one report of MCP65's poor performance but he said it happens on 1000Mbps link only. Normally poor network performance comes from speed/duplex mismatch. Does link partner also agree on resolved speed/duplex of nfe(4)? Would you show me the output of "netstat -ndI nfe0"? nfe(4) in 8-CURRENT supports hardware MAC counters and the counters give us very valuable information to diagnose driver issues. Would you try latest CURRENT and show me the output of "sysctl dev.nfe.0.stats" after some network activities? -- Regards, Pyun YongHyeon From linimon at FreeBSD.org Sat Oct 25 11:32:16 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Oct 25 11:32:24 2008 Subject: kern/128334: [request] use wpa_cli in the "WPA DHCP" situation Message-ID: <200810251132.m9PBWFfQ060093@freefall.freebsd.org> Old Synopsis: rc.d/wpa_supplicant doesn't take 'wired' driver New Synopsis: [request] use wpa_cli in the "WPA DHCP" situation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 25 11:29:27 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128334 From ck at yourserveradmin.com Sat Oct 25 19:08:51 2008 From: ck at yourserveradmin.com (CK) Date: Sat Oct 25 19:08:57 2008 Subject: mpd - lcp protocol rejects Message-ID: <490368C0.1010704@yourserveradmin.com> Hello Everyone, I'm running mpd 4.4 on 6.3-STABLE #4. Connecting with mpd to my ISP's VPN server running poptop. Everything is ok for some time, and then all of a sudden mpd starts throwing weird protocol rejects to log file and vpn connection stops working. mpd.conf: pptp: new -i ng0 pptp pptp set iface disable on-demand set iface disable proxy-arp set iface enable tcpmssfix set iface up-script /usr/local/etc/mpd4/if_up.sh set iface down-script /usr/local/etc/mpd4/if_down.sh set iface idle 0 set bundle disable multilink set bundle yes compression set bundle disable noretry set bundle enable crypt-reqd set auth authname "login_here" set link accept acfcomp protocomp set link accept chap set link keep-alive 10 60 set link max-redial 0 set link accmap 0x00000000 set ipcp yes vjcomp set ccp yes mppc set ccp yes mpp-compress set ccp no mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless open mpd.links: pptp: set phys type pptp set pptp peer [ISP's vpn serv here] set pptp enable originate set pptp disable incoming set pptp enable windowing And lots of logs: Oct 19 03:06:10 tazek mpd: [pptp] PPTP call successful Oct 19 03:06:10 tazek mpd: [pptp] link: UP event Oct 19 03:06:10 tazek mpd: [pptp] link: origination is local Oct 19 03:06:10 tazek mpd: [pptp] LCP: Up event Oct 19 03:06:10 tazek mpd: [pptp] LCP: state change Starting --> Req-Sent Oct 19 03:06:10 tazek mpd: [pptp] LCP: SendConfigReq #1 Oct 19 03:06:10 tazek mpd: ACFCOMP Oct 19 03:06:10 tazek mpd: PROTOCOMP Oct 19 03:06:10 tazek mpd: ACCMAP 0x000a0000 Oct 19 03:06:10 tazek mpd: MRU 1460 Oct 19 03:06:10 tazek mpd: MAGICNUM bc85bd60 Oct 19 03:06:10 tazek mpd: [pptp] LCP: rec'd Configure Request #1 (Req-Sent) Oct 19 03:06:10 tazek mpd: ACCMAP 0x00000000 Oct 19 03:06:10 tazek mpd: AUTHPROTO CHAP MSOFTv2 Oct 19 03:06:10 tazek mpd: MAGICNUM 0b145760 Oct 19 03:06:10 tazek mpd: PROTOCOMP Oct 19 03:06:10 tazek mpd: ACFCOMP Oct 19 03:06:10 tazek mpd: [pptp] LCP: SendConfigAck #1 Oct 19 03:06:10 tazek mpd: ACCMAP 0x00000000 Oct 19 03:06:10 tazek mpd: AUTHPROTO CHAP MSOFTv2 Oct 19 03:06:10 tazek mpd: MAGICNUM 0b145760 Oct 19 03:06:10 tazek mpd: PROTOCOMP Oct 19 03:06:10 tazek mpd: ACFCOMP Oct 19 03:06:10 tazek mpd: [pptp] LCP: state change Req-Sent --> Ack-Sent Oct 19 03:06:12 tazek mpd: [pptp] LCP: SendConfigReq #2 Oct 19 03:06:12 tazek mpd: ACFCOMP Oct 19 03:06:12 tazek mpd: PROTOCOMP Oct 19 03:06:12 tazek mpd: ACCMAP 0x000a0000 Oct 19 03:06:12 tazek mpd: MRU 1460 Oct 19 03:06:12 tazek mpd: MAGICNUM bc85bd60 Oct 19 03:06:12 tazek mpd: [pptp] LCP: rec'd Configure Ack #2 (Ack-Sent) Oct 19 03:06:12 tazek mpd: ACFCOMP Oct 19 03:06:12 tazek mpd: PROTOCOMP Oct 19 03:06:12 tazek mpd: ACCMAP 0x000a0000 Oct 19 03:06:12 tazek mpd: MRU 1460 Oct 19 03:06:12 tazek mpd: MAGICNUM bc85bd60 Oct 19 03:06:12 tazek mpd: [pptp] LCP: state change Ack-Sent --> Opened Oct 19 03:06:12 tazek mpd: [pptp] LCP: auth: peer wants CHAP, I want nothing Oct 19 03:06:12 tazek mpd: [pptp] LCP: LayerUp Oct 19 03:06:12 tazek mpd: [pptp] CHAP: rec'd CHALLENGE #19 Oct 19 03:06:12 tazek mpd: Name: "pptpd" Oct 19 03:06:12 tazek mpd: Using authname "login_here" Oct 19 03:06:12 tazek mpd: [pptp] CHAP: sending RESPONSE len:63 Oct 19 03:06:12 tazek mpd: [pptp] CHAP: rec'd SUCCESS #19 Oct 19 03:06:12 tazek mpd: MESG: S=376C81163CF8923DF663DC2D672D8802BBDAAD3B Oct 19 03:06:12 tazek mpd: [pptp] LCP: authorization successful Oct 19 03:06:12 tazek mpd: [pptp] Bundle up: 1 link, total bandwidth 64000 bps Oct 19 03:06:12 tazek mpd: [pptp] IPCP: Open event Oct 19 03:06:12 tazek mpd: [pptp] IPCP: state change Initial --> Starting Oct 19 03:06:12 tazek mpd: [pptp] IPCP: LayerStart Oct 19 03:06:12 tazek mpd: [pptp] CCP: Open event Oct 19 03:06:12 tazek mpd: [pptp] CCP: state change Initial --> Starting Oct 19 03:06:12 tazek mpd: [pptp] CCP: LayerStart Oct 19 03:06:12 tazek mpd: [pptp] IPCP: Up event Oct 19 03:06:12 tazek mpd: [pptp] IPCP: state change Starting --> Req-Sent Oct 19 03:06:12 tazek mpd: [pptp] IPCP: SendConfigReq #1 Oct 19 03:06:12 tazek mpd: IPADDR 192.168.1.2 Oct 19 03:06:12 tazek mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Oct 19 03:06:12 tazek mpd: [pptp] CCP: Up event Oct 19 03:06:12 tazek mpd: [pptp] CCP: state change Starting --> Req-Sent Oct 19 03:06:12 tazek mpd: [pptp] CCP: SendConfigReq #1 Oct 19 03:06:12 tazek mpd: MPPC Oct 19 03:06:12 tazek mpd: 0x01000041:MPPC, MPPE(128 bits), stateless Oct 19 03:06:12 tazek mpd: [pptp] IPCP: rec'd Terminate Ack #1 (Req-Sent) Oct 19 03:06:12 tazek mpd: [pptp] CCP: rec'd Configure Nak #1 (Req-Sent) Oct 19 03:06:12 tazek mpd: MPPC Oct 19 03:06:12 tazek mpd: 0x01000040:MPPE(128 bits), stateless Oct 19 03:06:12 tazek mpd: [pptp] CCP: SendConfigReq #2 Oct 19 03:06:12 tazek mpd: MPPC Oct 19 03:06:12 tazek mpd: 0x01000040:MPPE(128 bits), stateless Oct 19 03:06:12 tazek mpd: [pptp] CCP: rec'd Configure Ack #2 (Req-Sent) Oct 19 03:06:12 tazek mpd: MPPC Oct 19 03:06:12 tazek mpd: 0x01000040:MPPE(128 bits), stateless Oct 19 03:06:12 tazek mpd: [pptp] CCP: state change Req-Sent --> Ack-Rcvd Oct 19 03:06:14 tazek mpd: [pptp] IPCP: SendConfigReq #2 Oct 19 03:06:14 tazek mpd: IPADDR 192.168.1.2 Oct 19 03:06:14 tazek mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Oct 19 03:06:14 tazek mpd: [pptp] IPCP: rec'd Terminate Ack #2 (Req-Sent) Oct 19 03:06:14 tazek mpd: [pptp] CCP: state change Ack-Rcvd --> Req-Sent Oct 19 03:06:14 tazek mpd: [pptp] CCP: SendConfigReq #3 Oct 19 03:06:14 tazek mpd: MPPC Oct 19 03:06:14 tazek mpd: 0x01000040:MPPE(128 bits), stateless Oct 19 03:06:14 tazek mpd: [pptp] CCP: rec'd Configure Ack #3 (Req-Sent) Oct 19 03:06:14 tazek mpd: MPPC Oct 19 03:06:14 tazek mpd: 0x01000040:MPPE(128 bits), stateless Oct 19 03:06:14 tazek mpd: [pptp] CCP: state change Req-Sent --> Ack-Rcvd Oct 19 03:06:15 tazek mpd: [pptp] CCP: rec'd Configure Request #1 (Ack-Rcvd) Oct 19 03:06:15 tazek mpd: MPPC Oct 19 03:06:15 tazek mpd: 0x01000040:MPPE(128 bits), stateless Oct 19 03:06:15 tazek mpd: [pptp] CCP: SendConfigAck #1 Oct 19 03:06:15 tazek mpd: MPPC Oct 19 03:06:15 tazek mpd: 0x01000040:MPPE(128 bits), stateless Oct 19 03:06:15 tazek mpd: [pptp] CCP: state change Ack-Rcvd --> Opened Oct 19 03:06:15 tazek mpd: [pptp] CCP: LayerUp Oct 19 03:06:15 tazek mpd: Compress using: mppc (MPPE(128 bits), stateless) Oct 19 03:06:15 tazek mpd: Decompress using: mppc (MPPE(128 bits), stateless) Oct 19 03:06:15 tazek mpd: [pptp] IPCP: rec'd Configure Request #1 (Req-Sent) Oct 19 03:06:15 tazek mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Oct 19 03:06:15 tazek mpd: IPADDR 172.16.30.42 Oct 19 03:06:15 tazek mpd: 172.16.30.42 is OK Oct 19 03:06:15 tazek mpd: [pptp] IPCP: SendConfigAck #1 Oct 19 03:06:15 tazek mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Oct 19 03:06:15 tazek mpd: IPADDR 172.16.30.42 Oct 19 03:06:15 tazek mpd: [pptp] IPCP: state change Req-Sent --> Ack-Sent Oct 19 03:06:16 tazek mpd: [pptp] IPCP: SendConfigReq #3 Oct 19 03:06:16 tazek mpd: IPADDR 192.168.1.2 Oct 19 03:06:16 tazek mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Oct 19 03:06:16 tazek mpd: [pptp] IPCP: rec'd Configure Nak #3 (Ack-Sent) Oct 19 03:06:16 tazek mpd: IPADDR ext_ip Oct 19 03:06:16 tazek mpd: ext_ip is OK Oct 19 03:06:16 tazek mpd: [pptp] IPCP: SendConfigReq #4 Oct 19 03:06:16 tazek mpd: IPADDR ext_ip Oct 19 03:06:16 tazek mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Oct 19 03:06:16 tazek mpd: [pptp] IPCP: rec'd Configure Ack #4 (Ack-Sent) Oct 19 03:06:16 tazek mpd: IPADDR ext_ip Oct 19 03:06:16 tazek mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Oct 19 03:06:16 tazek mpd: [pptp] IPCP: state change Ack-Sent --> Opened Oct 19 03:06:16 tazek mpd: [pptp] IPCP: LayerUp Oct 19 03:06:16 tazek mpd: ext_ip -> 172.16.30.42 Oct 19 03:06:16 tazek mpd: [pptp] IFACE: Up event Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #2 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x000b was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #3 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0xf679 was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #4 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x000f was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #5 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol CRYPT was rejected Oct 19 11:10:26 tazek mpd: [pptp] ECP: protocol was rejected by peer Oct 19 11:10:26 tazek mpd: [pptp] ECP: Close event Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #6 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x009f was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #7 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x8683 was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #8 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x0073 was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #9 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x7e56 was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #10 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x56f2 was rejected Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #11 (Opened) Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x0047 was rejected No errors between up event and protocol rejects. Help... I've found this post http://lists.freebsd.org/pipermail/freebsd-stable/2003-June/001878.html but patch is for older ng_ppp.c and I do not speak C well enough to write code for kernel modules. Also, saw some other guys having same problems - but no solutions. Maybe community has something to say? Please include me in CC because I'm not subscribed to the list. Thanks From rwatson at FreeBSD.org Sun Oct 26 13:43:02 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Oct 26 13:43:09 2008 Subject: does freebsd support so called Scalable I/O on intel NIC ? In-Reply-To: <3c1674c90810241552v5fd3e58fvf6bd43ad94558b1e@mail.gmail.com> References: <200810241612.04764.gizmen@blurp.pl> <3c1674c90810241552v5fd3e58fvf6bd43ad94558b1e@mail.gmail.com> Message-ID: On Fri, 24 Oct 2008, Kip Macy wrote: > It is simply a knob to adjust on all new server network cards. You could > benefit from it on a predominantly UDP workload. I believe that tcp_input is > still sufficiently serialized that it would not make sense for TCP > workloads. In principle we can benefit on the basis that we drop the global lock fairly quickly for steady-state workloads (i.e., few SYN/FIN/RST packets), but there should be lots of contention on tcbinfo. If anyone is interested in doing some benchmarks, I have some patches that should apply fairly easily againts 8.x or 7.x as of 7.1 to move to optimistic read-locking of the global lock for steady state packets, but once in a while we have to upgrade or drop and re-acquire to get an exclusive lock when it turns out something that looked like a steady state packet did require the global lock exclusively, such as the ACK to transitioning to or from established. I've not had a chance to do much benchmarking on them, and theorize that they probably help quite a lot for lots of steady-state connections, but as connection length gets shorter the optimistic assumption becomes less true and begins to hurt performance. The long-term plan is to move to some more agressive decomposition of the tcbinfo lock, but I've not started on that yet as I'm waiting for the rwlock changes to settle, and need to evaluate the above tcbinfo rwlock patch. Robert N M Watson Computer Laboratory University of Cambridge > > -Kip > > On Fri, Oct 24, 2008 at 2:12 PM, Bartosz Giza wrote: >> Hi, >> >> i am looking for a good NIC from NIC to put on our quite busy router based >> on freebsd 6.3 (soon 7.x) >> I've found server NIC from intel and there is such a thing like scalable I/O >> on windows and linux. >> (from web page) >> >> "load balancing on multiple CPUs Increases >> performance on multi-processor systems by efficiently >> balancing network loads across CPU cores when used >> with Receive-Side Scaling from Microsoft or Scalable >> I/O on Linux*" >> >> Is such thing supported on freebsd ? >> >> And one more question. Does anybody has some data what is difference on >> desktop and server NIC from INTEL in pps or so. >> I wonder how faster could be those server NICs >> >> thanks >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From dudu.meyer at gmail.com Sun Oct 26 14:18:37 2008 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Sun Oct 26 14:18:50 2008 Subject: NAT-PT on FreeBSD (or something else)? Message-ID: Hello, I want to start a migration education to IPv6, setting up my internal network to be 100% ipv6-only. I dont want it to be dual stacked, because I intend to force my team to perform only IPv6 related tools on the internal network. However, when performing internet activity like, reading e-mail or browsing the web, its impossible to avoid IPv4 today. I want them to be able to reach IPv4 network (internet) transparently. When DNS resolve to IPv4, they will ask the gateway (ipv6, dual stacked), who will put their v6 address in the v4 network. How can I accomplish that? Is NAT-PT the only way? If so, how can I get NAT-PT on FreeBSD? Your opinion: do you think this approach can be used for end users? I mean, someone with windows vista and teredo, is already getting IPv6 address since my FreeBSD is advertising it. However they are dual stacked. I want people to be v6-only and still can visit v4 networks transparently, without technical knowledge (say, my girlfriend who is not a geek). I guess this is a migration/education strategy, which I intend to deploy, but right now I am only studying. Will faith(4) do this for me? -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From eitans at mellanox.co.il Sun Oct 26 15:25:27 2008 From: eitans at mellanox.co.il (Eitan Shefi) Date: Sun Oct 26 15:25:33 2008 Subject: I seems that the OS does use the available MTU Message-ID: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> Hi, I am using 2 hosts with FreeBSD-7.0 connected directly. When I change the MTU to a value greater then 1500, for example 3000, and then send "ping" with message size 2500, from one host to the other, the other host gets more then one ICMP packet, even thaw the message that was send is match smaller then the MTU. I tried to run this test using a different NIC, but I got the same behavior. I run: 1. On both hosts: ifconfig mtnic0 mtu 3000 2. Than on one host I run: tcpdump -i mtnic0 icmp 3. And on the other host I run: ping -s 2500 -c 1 OTHER_HOST_IP (ping to "mtnic0" on the other host) On the receiving side I get the output: [root@sw260 ~]# tcpdump -i mtnic0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on mtnic0, link-type EN10MB (Ethernet), capture size 96 bytes 13:12:45.904454 IP 11.4.12.5 > 11.4.12.6: ICMP echo request, id 22550, seq 0, length 1480 13:12:45.904463 IP 11.4.12.5 > 11.4.12.6: icmp 13:12:45.904477 IP 11.4.12.6 > 11.4.12.5: ICMP echo reply, id 22550, seq 0, length 1480 13:12:45.904480 IP 11.4.12.6 > 11.4.12.5: icmp Please help resolving this issue. Thanks, Eitan Shefi From oberman at es.net Sun Oct 26 16:17:31 2008 From: oberman at es.net (Kevin Oberman) Date: Sun Oct 26 16:17:44 2008 Subject: NAT-PT on FreeBSD (or something else)? In-Reply-To: Your message of "Sun, 26 Oct 2008 13:18:35 -0100." Message-ID: <20081026160658.7ED2345048@ptavv.es.net> > Date: Sun, 26 Oct 2008 13:18:35 -0100 > From: "Eduardo Meyer" > Sender: owner-freebsd-net@freebsd.org > > Hello, > > I want to start a migration education to IPv6, setting up my internal > network to be 100% ipv6-only. I dont want it to be dual stacked, > because I intend to force my team to perform only IPv6 related tools > on the internal network. However, when performing internet activity > like, reading e-mail or browsing the web, its impossible to avoid IPv4 > today. > > I want them to be able to reach IPv4 network (internet) transparently. > When DNS resolve to IPv4, they will ask the gateway (ipv6, dual > stacked), who will put their v6 address in the v4 network. > > How can I accomplish that? Is NAT-PT the only way? If so, how can I > get NAT-PT on FreeBSD? > > Your opinion: do you think this approach can be used for end users? I > mean, someone with windows vista and teredo, is already getting IPv6 > address since my FreeBSD is advertising it. However they are dual > stacked. I want people to be v6-only and still can visit v4 networks > transparently, without technical knowledge (say, my girlfriend who is > not a geek). > > I guess this is a migration/education strategy, which I intend to > deploy, but right now I am only studying. > > Will faith(4) do this for me? I suspect that this is simply not quite possible today, although it's close. The BEHAVE IETF working group is the place to look for the latest information on this area. I have tried a couple of solutions. The one that worked best was IVI, developed in China. It generally worked well and was fairly fast. It's big problem is embedded IPv4 addresses in things like JavaScript. This is a workable problem, but it has not been worked to this point. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081026/82639853/attachment.pgp From mav at FreeBSD.org Sun Oct 26 16:39:41 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Oct 26 16:39:48 2008 Subject: mpd - lcp protocol rejects In-Reply-To: <490368C0.1010704@yourserveradmin.com> References: <490368C0.1010704@yourserveradmin.com> Message-ID: <4904AB59.3060101@FreeBSD.org> CK wrote: > I'm running mpd 4.4 on 6.3-STABLE #4. Connecting with mpd to my ISP's > VPN server running poptop. Everything is ok for some time, and then all > of a sudden mpd starts throwing weird protocol rejects to log file and > vpn connection stops working. > > Oct 19 03:06:16 tazek mpd: [pptp] IPCP: state change Ack-Sent --> Opened > Oct 19 03:06:16 tazek mpd: [pptp] IPCP: LayerUp > Oct 19 03:06:16 tazek mpd: ext_ip -> 172.16.30.42 > Oct 19 03:06:16 tazek mpd: [pptp] IFACE: Up event > Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #2 (Opened) > Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0x000b was rejected > Oct 19 11:10:26 tazek mpd: [pptp] LCP: rec'd Protocol Reject #3 (Opened) > Oct 19 11:10:26 tazek mpd: [pptp] LCP: protocol 0xf679 was rejected > > No errors between up event and protocol rejects. Help... > > I've found this post > http://lists.freebsd.org/pipermail/freebsd-stable/2003-June/001878.html > but patch is for older ng_ppp.c and I do not speak C well enough to > write code for kernel modules. Also, saw some other guys having same > problems - but no solutions. Maybe community has something to say? That post is too old and not applicable now. IMO problem is encryption related. It looks like due to some reason sides got out of sync. It could happen due to incomplete memory errors handling withing ng_mppc node. I have made a patch to improve it. Patch is for 8-CURRENT, but I think it should apply to 6-STABLE without significant problems. Write me please about results. -- Alexander Motin -------------- next part -------------- --- ng_mppc.c.prev 2007-05-18 18:28:01.000000000 +0300 +++ ng_mppc.c 2008-10-26 19:17:38.000000000 +0200 @@ -492,17 +492,18 @@ ng_mppc_compress(node_p node, struct mbu /* Work with contiguous regions of memory. */ inlen = m->m_pkthdr.len; inbuf = malloc(inlen, M_NETGRAPH_MPPC, M_NOWAIT); - if (inbuf == NULL) { - m_freem(m); - return (ENOMEM); - } + if (inbuf == NULL) + goto err1; m_copydata(m, 0, inlen, (caddr_t)inbuf); outlen = MPPC_MAX_BLOWUP(inlen); outbuf = malloc(outlen, M_NETGRAPH_MPPC, M_NOWAIT); if (outbuf == NULL) { - m_freem(m); free(inbuf, M_NETGRAPH_MPPC); +err1: + m_freem(m); + MPPC_InitCompressionHistory(d->history); + d->flushed = 1; return (ENOMEM); } @@ -538,8 +539,13 @@ ng_mppc_compress(node_p node, struct mbu free(outbuf, M_NETGRAPH_MPPC); /* Check m_devget() result. */ - if (m == NULL) + if (m == NULL) { + if (!d->flushed) { + MPPC_InitCompressionHistory(d->history); + d->flushed = 1; + } return (ENOMEM); + } } #endif @@ -551,6 +557,18 @@ ng_mppc_compress(node_p node, struct mbu /* Set header bits */ header |= MPPC_FLAG_ENCRYPTED; + /* We must own the mbuf chain exclusively to modify it. */ + m = m_unshare(m, M_DONTWAIT); + if (m == NULL) { + if (!d->flushed) { +#ifdef NETGRAPH_MPPC_COMPRESSION + MPPC_InitCompressionHistory(d->history); +#endif + d->flushed = 1; + } + return (ENOMEM); + } + /* Update key if it's time */ if ((d->cfg.bits & MPPE_STATELESS) != 0 || (d->cc & MPPE_UPDATE_MASK) == MPPE_UPDATE_FLAG) { @@ -562,11 +580,6 @@ ng_mppc_compress(node_p node, struct mbu rc4_init(&d->rc4, d->key, KEYLEN(d->cfg.bits)); } - /* We must own the mbuf chain exclusively to modify it. */ - m = m_unshare(m, M_DONTWAIT); - if (m == NULL) - return (ENOMEM); - /* Encrypt packet */ m1 = m; while (m1) { From randy at psg.com Sun Oct 26 21:47:05 2008 From: randy at psg.com (Randy Bush) Date: Sun Oct 26 21:47:11 2008 Subject: NAT-PT on FreeBSD (or something else)? In-Reply-To: References: Message-ID: <4904E553.60806@psg.com> > I want to start a migration education to IPv6, setting up my internal > network to be 100% ipv6-only. I dont want it to be dual stacked, > because I intend to force my team to perform only IPv6 related tools > on the internal network. However, when performing internet activity > like, reading e-mail or browsing the web, its impossible to avoid IPv4 > today. sigh, for linux, http://code.google.com/p/stubl/ randy From morganw at chemikals.org Mon Oct 27 02:19:26 2008 From: morganw at chemikals.org (Wes Morgan) Date: Mon Oct 27 02:19:33 2008 Subject: NAT-PT on FreeBSD (or something else)? In-Reply-To: <4904E553.60806@psg.com> References: <4904E553.60806@psg.com> Message-ID: On Mon, 27 Oct 2008, Randy Bush wrote: >> I want to start a migration education to IPv6, setting up my internal >> network to be 100% ipv6-only. I dont want it to be dual stacked, >> because I intend to force my team to perform only IPv6 related tools >> on the internal network. However, when performing internet activity >> like, reading e-mail or browsing the web, its impossible to avoid IPv4 >> today. Can't PF do this already? From ganbold at micom.mng.net Mon Oct 27 04:04:21 2008 From: ganbold at micom.mng.net (Ganbold) Date: Mon Oct 27 04:04:28 2008 Subject: multiple IP pools in mpd5 Message-ID: <49053DC1.8060101@micom.mng.net> Hi, Is it possible to specify multiple IP pools in mpd5? Something like: set ippool add pool1 102.179.16.20 102.179.17.254 set ippool add pool1 102.179.17.1 102.179.17.254 set ipcp ranges 102.179.16.13/32 ippool pool1 Or: set ippool add pool1 102.179.16.20 102.179.17.254 set ippool add pool2 102.179.17.1 102.179.17.254 set ipcp ranges 102.179.16.13/32 ippool pool1 pool2 Which one is correct syntax? thanks, Ganbold -- The luck that is ordained for you will be coveted by others. From ganbold at micom.mng.net Mon Oct 27 07:52:50 2008 From: ganbold at micom.mng.net (Ganbold) Date: Mon Oct 27 07:52:57 2008 Subject: multiple IP pools in mpd5 In-Reply-To: <49053DC1.8060101@micom.mng.net> References: <49053DC1.8060101@micom.mng.net> Message-ID: <4905734B.1050402@micom.mng.net> Hi, Replying to myself. set ippool add pool1 102.179.16.20 102.179.17.254 set ipcp ranges 102.179.16.13/32 ippool pool1 works here :) Ganbold Ganbold wrote: > Hi, > > Is it possible to specify multiple IP pools in mpd5? > > Something like: > > set ippool add pool1 102.179.16.20 102.179.17.254 > set ippool add pool1 102.179.17.1 102.179.17.254 > > set ipcp ranges 102.179.16.13/32 ippool pool1 > > Or: > > set ippool add pool1 102.179.16.20 102.179.17.254 > set ippool add pool2 102.179.17.1 102.179.17.254 > > set ipcp ranges 102.179.16.13/32 ippool pool1 pool2 > > Which one is correct syntax? > > thanks, > > Ganbold > > > > > -- Yes, I was surprised how easy it was to cut the door off my cat. -- James D. Nicoll From bugmaster at FreeBSD.org Mon Oct 27 11:07:18 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 27 11:08:38 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200810271107.m9RB7H91002039@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 188 problems total. From r_de_sousa at yahoo.com Mon Oct 27 05:26:54 2008 From: r_de_sousa at yahoo.com (Roberto de Sousa) Date: Mon Oct 27 11:21:52 2008 Subject: NSupdate from CLI Message-ID: <184591.23555.qm@web45201.mail.sp1.yahoo.com> Hello all, Can someone direct me where to go to find out example of how to create a script using nsupdate from CLI to add host to forward and reversing zone of DNS? I am new to Unix and just installed my freeBSD box which running apache and BIND last month. Any advise or information will be highly appreciated. Thanks all. Roberto buka wainhira la hatene, buka atu hatene liu tan abracos Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail From mav at FreeBSD.org Mon Oct 27 08:24:25 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Oct 27 11:22:05 2008 Subject: multiple IP pools in mpd5 In-Reply-To: <49053DC1.8060101@micom.mng.net> References: <49053DC1.8060101@micom.mng.net> Message-ID: <49057AB6.7040701@FreeBSD.org> Hi. Ganbold wrote: > Is it possible to specify multiple IP pools in mpd5? Yes. It supports both multiple pools and multiple subnets in a pool. > Something like: > > set ippool add pool1 102.179.16.20 102.179.17.254 > set ippool add pool1 102.179.17.1 102.179.17.254 > > set ipcp ranges 102.179.16.13/32 ippool pool1 > > Or: > > set ippool add pool1 102.179.16.20 102.179.17.254 > set ippool add pool2 102.179.17.1 102.179.17.254 > > set ipcp ranges 102.179.16.13/32 ippool pool1 pool2 > > Which one is correct syntax? First one. But you have made mistake in address ranges as they are overlapping. Probably you have meant: set ippool add pool1 102.179.16.20 102.179.16.254 set ippool add pool1 102.179.17.1 102.179.17.254 set ipcp ranges 102.179.16.13/32 ippool pool1 -- Alexander Motin From dudu.meyer at gmail.com Mon Oct 27 11:27:37 2008 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Mon Oct 27 11:27:53 2008 Subject: NAT-PT on FreeBSD (or something else)? Message-ID: Hello, I want to start a migration education to IPv6, setting up my internal network to be 100% ipv6-only. I dont want it to be dual stacked, because I intend to force my team to perform only IPv6 related tools on the internal network. However, when performing internet activity like, reading e-mail or browsing the web, its impossible to avoid IPv4 today. I want them to be able to reach IPv4 network (internet) transparently. When DNS resolve to IPv4, they will ask the gateway (ipv6, dual stacked), who will put their v6 address in the v4 network. How can I accomplish that? Is NAT-PT the only way? If so, how can I get NAT-PT on FreeBSD? Your opinion: do you think this approach can be used for end users? I mean, someone with windows vista and teredo, is already getting IPv6 address since my FreeBSD is advertising it. However they are dual stacked. I want people to be v6-only and still can visit v4 networks transparently, without technical knowledge (say, my girlfriend who is not a geek). I guess this is a migration/education strategy, which I intend to deploy, but right now I am only studying. Will faith(4) do this for me? -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From randy at psg.com Mon Oct 27 11:53:07 2008 From: randy at psg.com (Randy Bush) Date: Mon Oct 27 11:53:12 2008 Subject: NAT-PT on FreeBSD (or something else)? In-Reply-To: References: Message-ID: <4904E553.60806@psg.com> > I want to start a migration education to IPv6, setting up my internal > network to be 100% ipv6-only. I dont want it to be dual stacked, > because I intend to force my team to perform only IPv6 related tools > on the internal network. However, when performing internet activity > like, reading e-mail or browsing the web, its impossible to avoid IPv4 > today. sigh, for linux, http://code.google.com/p/stubl/ randy _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From oberman at es.net Mon Oct 27 12:08:07 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Oct 27 12:08:24 2008 Subject: NAT-PT on FreeBSD (or something else)? In-Reply-To: Your message of "Sun, 26 Oct 2008 13:18:35 -0100." Message-ID: <20081026160658.7ED2345048@ptavv.es.net> > Date: Sun, 26 Oct 2008 13:18:35 -0100 > From: "Eduardo Meyer" > Sender: owner-freebsd-net@freebsd.org > > Hello, > > I want to start a migration education to IPv6, setting up my internal > network to be 100% ipv6-only. I dont want it to be dual stacked, > because I intend to force my team to perform only IPv6 related tools > on the internal network. However, when performing internet activity > like, reading e-mail or browsing the web, its impossible to avoid IPv4 > today. > > I want them to be able to reach IPv4 network (internet) transparently. > When DNS resolve to IPv4, they will ask the gateway (ipv6, dual > stacked), who will put their v6 address in the v4 network. > > How can I accomplish that? Is NAT-PT the only way? If so, how can I > get NAT-PT on FreeBSD? > > Your opinion: do you think this approach can be used for end users? I > mean, someone with windows vista and teredo, is already getting IPv6 > address since my FreeBSD is advertising it. However they are dual > stacked. I want people to be v6-only and still can visit v4 networks > transparently, without technical knowledge (say, my girlfriend who is > not a geek). > > I guess this is a migration/education strategy, which I intend to > deploy, but right now I am only studying. > > Will faith(4) do this for me? I suspect that this is simply not quite possible today, although it's close. The BEHAVE IETF working group is the place to look for the latest information on this area. I have tried a couple of solutions. The one that worked best was IVI, developed in China. It generally worked well and was fairly fast. It's big problem is embedded IPv4 addresses in things like JavaScript. This is a workable problem, but it has not been worked to this point. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081027/82639853/attachment.pgp From hlh at restart.be Mon Oct 27 13:35:18 2008 From: hlh at restart.be (Henri Hennebert) Date: Mon Oct 27 13:35:25 2008 Subject: NSupdate from CLI In-Reply-To: <184591.23555.qm@web45201.mail.sp1.yahoo.com> References: <184591.23555.qm@web45201.mail.sp1.yahoo.com> Message-ID: <4905C38C.1090704@restart.be> Roberto de Sousa wrote: > Hello all, > Can someone direct me where to go to find out example of how to create a script using nsupdate from CLI to add host to forward and reversing zone of DNS? > I am new to Unix and just installed my freeBSD box which running apache and BIND last month. > > Any advise or information will be highly appreciated. In your named.conf you have eg: zone "example.com" { type master; file "dynamic/db.example.com"; allow-update { key host1.example.com.; }; }; key "host1.example.com." { algorithm hmac-md5; secret "XXXX...XXXX=="; }; and on host1 you use this script: #!/bin/sh NSSERVER="xxx.xxx.xxx.xxx" MYNAME=host1.example.com MYADDR=$1 /usr/bin/nsupdate -y host1.example.com.:XXXX...XXXX== \ 1>/dev/null 2>&1 < > Thanks all. > > Roberto > > > buka wainhira la hatene, buka atu hatene liu tan > > abracos > > > > Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From linimon at FreeBSD.org Mon Oct 27 16:30:44 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Oct 27 16:30:56 2008 Subject: kern/128401: [dummynet] dummynet does not shape traffic with fast IO enabled Message-ID: <200810271630.m9RGUiCY081784@freefall.freebsd.org> Old Synopsis: dummynet does not shape traffic with fast io enabled New Synopsis: [dummynet] dummynet does not shape traffic with fast IO enabled Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 27 16:29:39 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128401 From oleg at FreeBSD.org Mon Oct 27 18:57:51 2008 From: oleg at FreeBSD.org (oleg@FreeBSD.org) Date: Mon Oct 27 18:57:58 2008 Subject: kern/128401: [dummynet] [patch] dummynet does not shape traffic with fast IO enabled Message-ID: <200810271857.m9RIvpYW095592@freefall.freebsd.org> Synopsis: [dummynet] [patch] dummynet does not shape traffic with fast IO enabled Responsible-Changed-From-To: freebsd-net->oleg Responsible-Changed-By: oleg Responsible-Changed-When: Mon Oct 27 18:56:54 UTC 2008 Responsible-Changed-Why: i'll look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=128401 From eitans at mellanox.co.il Mon Oct 27 21:53:40 2008 From: eitans at mellanox.co.il (Eitan Shefi) Date: Mon Oct 27 21:53:48 2008 Subject: It seems that FreeBSD-7.0 does not use the available MTU In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> Message-ID: <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> Hi, I am using 2 hosts with FreeBSD-7.0 connected directly. When I change the MTU to a value greater then 1500, for example 3000, and then send "ping" with message size 2500, from one host to the other, the other host gets more then one ICMP packet, even thaw the message that was send is match smaller then the MTU. I tried to run this test using a different NIC, but I got the same behavior. I run: 1. On both hosts: ifconfig mtnic0 mtu 3000 2. Than on one host I run: tcpdump -i mtnic0 icmp 3. And on the other host I run: ping -s 2500 -c 1 OTHER_HOST_IP (ping to "mtnic0" on the other host) On the receiving side I get the output: [root@sw260 ~]# tcpdump -i mtnic0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on mtnic0, link-type EN10MB (Ethernet), capture size 96 bytes 13:12:45.904454 IP 11.4.12.5 > 11.4.12.6: ICMP echo request, id 22550, seq 0, length 1480 13:12:45.904463 IP 11.4.12.5 > 11.4.12.6: icmp 13:12:45.904477 IP 11.4.12.6 > 11.4.12.5: ICMP echo reply, id 22550, seq 0, length 1480 13:12:45.904480 IP 11.4.12.6 > 11.4.12.5: icmp I will be happy to get any advice on how to resolve this issue. . Thanks, Eitan Shefi From vwe at FreeBSD.org Mon Oct 27 21:57:34 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Mon Oct 27 21:57:40 2008 Subject: bin/124004: ifconfig(8): Cannot assign both an IP and a MAC address to a bridge in one command Message-ID: <200810272157.m9RLvXtX033700@freefall.freebsd.org> Synopsis: ifconfig(8): Cannot assign both an IP and a MAC address to a bridge in one command State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Mon Oct 27 21:55:23 UTC 2008 State-Changed-Why: DUP of bin/123633 this issue is not just related to bridge interfaces - this seems to be an issue with the ifconfig(8) cli. Yvan, if you need to add additional information, please file a followup to bin/123633. Thanks! Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Mon Oct 27 21:55:23 UTC 2008 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=124004 From cswiger at mac.com Mon Oct 27 23:02:22 2008 From: cswiger at mac.com (Chuck Swiger) Date: Mon Oct 27 23:02:29 2008 Subject: It seems that FreeBSD-7.0 does not use the available MTU In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> Message-ID: <1AB022D4-5147-4837-82CC-99270FF45AE5@mac.com> On Oct 27, 2008, at 2:53 PM, Eitan Shefi wrote: > When I change the MTU to a value greater then 1500, for example 3000, > and then send "ping" with message size 2500, from one host to the > other, > the other host gets more then one ICMP packet, even thaw the message > that was send is match smaller then the MTU. > > I tried to run this test using a different NIC, but I got the same > behavior. You obscured the details of which NICs you actually used, so a guess would be that your hardware doesn't support jumbo frames. If your NIC isn't gigabit-speed capable, this is probably expected-- only fairly new NICs like em/bce/bge/msk have the capability. Regards, -- -Chuck From freebsd at hub.org Mon Oct 27 23:04:30 2008 From: freebsd at hub.org (Marc G. Fournier) Date: Mon Oct 27 23:04:36 2008 Subject: tap+bridge -> ethernet with an alias ... Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On my desktop here, I have a qemu-img of Win XP that is using bridging to connect to the Internet ... everything works great, even have remote desktop working so that I can login from another windows box into the VM ... and very responsive ... ... but this is on a private network where the ethernet doesn't have any aliases attached to it ... I've tried uploading the image (after changing the IP) to one of my servers with a public interface on it, but now can't seem to get networking working ... my ifconfig -a looks like: bge0: flags=8943 metric 0 mtu 1500 options=98 ether 00:14:c2:3f:2e:86 inet xxx.xxx.xxx.xxx netmask 0xffffff00 broadcast xxx.xxx.xxx.255 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet xxx.xxx.xxx.xxx netmask 0xffffffff broadcast xxx.xxx.xxx.xxx media: Ethernet 100baseTX status: active bge1: flags=8802 metric 0 mtu 1500 options=9b ether 00:14:c2:3f:2e:85 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether ce:44:c7:1b:47:40 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: bge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 200000 member: tap0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 2000000 tap0: flags=8942 metric 0 mtu 1500 ether 00:bd:96:ae:67:00 the 192.168.1.x is used for 'internal routing' ... when I startup qemu, I use: qemu winxp.img -net nic -net tap -vnc :1 and I can connect via VNC, but the IP assigned to the image isn't pingable, like it is on my desktop ... Is there something with 'pre-aliased' interfaces that can't be used with a bridge/tap device? Or have I just missed something? - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkGRKoACgkQ4QvfyHIvDvM2MQCaAoa8mt9L+80o+IQiooQ0QjDA X08An1/mJwduTU0uH7sDlRFPp06Bs2cN =2c6c -----END PGP SIGNATURE----- From r_de_sousa at yahoo.com Mon Oct 27 23:14:19 2008 From: r_de_sousa at yahoo.com (Roberto de Sousa) Date: Mon Oct 27 23:16:51 2008 Subject: NSupdate from CLI Message-ID: <723811.95360.qm@web45207.mail.sp1.yahoo.com> Hello Henri, Thank you for your kindness to help me on this.. I have generated the key and and edit my named.conf as per your instruction. I have also tried your script which work great. What i would like to find out more is that how to modify this script so that it provides flexibility without having to specify the host in the script? what i mean is that.. i could select add or delete option from CLI and able to add any host to forward & Reversing Zone of my DNS from my freeBSD CLI? Thanks again. Regards, Roberto buka wainhira la hatene, buka atu hatene liu tan abracos ________________________________ From: Henri Hennebert To: Roberto de Sousa Cc: freebsd-net@freebsd.org Sent: Tuesday, 28 October, 2008 12:35:08 AM Subject: Re: NSupdate from CLI Roberto de Sousa wrote: > Hello all, > Can someone direct me where to go to find out example of how to create a script using nsupdate from CLI to add host to forward and reversing zone of DNS? > I am new to Unix and just installed my freeBSD box which running apache and BIND last month. > > Any advise or information will be highly appreciated. In your named.conf you have eg: zone "example.com" { type master; file "dynamic/db.example.com"; allow-update { key host1.example.com.; }; }; key "host1.example.com." { algorithm hmac-md5; secret "XXXX...XXXX=="; }; and on host1 you use this script: #!/bin/sh NSSERVER="xxx.xxx.xxx.xxx" MYNAME=host1.example.com MYADDR=$1 /usr/bin/nsupdate -y host1.example.com.:XXXX...XXXX== \ 1>/dev/null 2>&1 < > Thanks all. > > Roberto > > > buka wainhira la hatene, buka atu hatene liu tan > > abracos > > > > Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail From freebsd at hub.org Mon Oct 27 23:16:43 2008 From: freebsd at hub.org (Marc G. Fournier) Date: Mon Oct 27 23:16:51 2008 Subject: tap+bridge -> ethernet with an alias ... In-Reply-To: References: Message-ID: <7962F22A78B7483E6667733E@ganymede.hub.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As an appendum, I have the following kernel modules loaded: 4 1 0xffffffffaf49c000 5066 if_bridge.ko 5 1 0xffffffffaf483000 35c5 bridgestp.ko 6 1 0xffffffffaf493000 2506 if_tap.ko same as on my desktop ... - --On Monday, October 27, 2008 19:46:02 -0300 "Marc G. Fournier" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On my desktop here, I have a qemu-img of Win XP that is using bridging to > connect to the Internet ... everything works great, even have remote desktop > working so that I can login from another windows box into the VM ... and very > responsive ... > > ... but this is on a private network where the ethernet doesn't have any > aliases attached to it ... > > I've tried uploading the image (after changing the IP) to one of my servers > with a public interface on it, but now can't seem to get networking working > ... > > my ifconfig -a looks like: > > bge0: flags=8943 metric 0 mtu > 1500 > options=98 > ether 00:14:c2:3f:2e:86 > inet xxx.xxx.xxx.xxx netmask 0xffffff00 broadcast xxx.xxx.xxx.255 > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > inet xxx.xxx.xxx.xxx netmask 0xffffffff broadcast xxx.xxx.xxx.xxx > media: Ethernet 100baseTX > status: active > bge1: flags=8802 metric 0 mtu 1500 > options=9b > ether 00:14:c2:3f:2e:85 > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > bridge0: flags=8843 metric 0 mtu 1500 > ether ce:44:c7:1b:47:40 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: bge0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 200000 > member: tap0 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 2000000 > tap0: flags=8942 metric 0 mtu > 1500 ether 00:bd:96:ae:67:00 > > the 192.168.1.x is used for 'internal routing' ... > > when I startup qemu, I use: > > qemu winxp.img -net nic -net tap -vnc :1 > > and I can connect via VNC, but the IP assigned to the image isn't pingable, > like it is on my desktop ... > > Is there something with 'pre-aliased' interfaces that can't be used with a > bridge/tap device? Or have I just missed something? > > > - -- > Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAkkGRKoACgkQ4QvfyHIvDvM2MQCaAoa8mt9L+80o+IQiooQ0QjDA > X08An1/mJwduTU0uH7sDlRFPp06Bs2cN > =2c6c > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkGS9MACgkQ4QvfyHIvDvOmOwCeJy6mKN0SOwqEhuwTa0u457/0 wwgAn1sxRa2L3MyVaAF/2WMhFm5hDh5X =DYcR -----END PGP SIGNATURE----- From bh at izb.knu.ac.kr Tue Oct 28 00:09:03 2008 From: bh at izb.knu.ac.kr (Byung-Hee HWANG) Date: Tue Oct 28 00:09:12 2008 Subject: NSupdate from CLI In-Reply-To: <184591.23555.qm@web45201.mail.sp1.yahoo.com> References: <184591.23555.qm@web45201.mail.sp1.yahoo.com> Message-ID: <49065815.1010506@izb.knu.ac.kr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roberto de Sousa wrote: > Hello all, > Can someone direct me where to go to find out example of how to create a script using nsupdate from CLI to add host to forward and reversing zone of DNS? > I am new to Unix and just installed my freeBSD box which running apache and BIND last month. > > Any advise or information will be highly appreciated. > > Thanks all. > > Roberto Roberto, this is not what you want really. However i would like to recommend for you. See ;; byunghee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkkGWBUACgkQsCouaZaxlv5tdwCgnjLg4lmjW++pqbhQDF+tOv1r Nm0AnR3NZg9unwAfxaKCXopNo5V7q5Jg =z4E4 -----END PGP SIGNATURE----- From rea-fbsd at codelabs.ru Tue Oct 28 07:53:17 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Oct 28 07:53:23 2008 Subject: It seems that FreeBSD-7.0 does not use the available MTU In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> Message-ID: Eitan, good day. Mon, Oct 27, 2008 at 11:53:26PM +0200, Eitan Shefi wrote: > I am using 2 hosts with FreeBSD-7.0 connected directly. > When I change the MTU to a value greater then 1500, for example 3000, > and then send "ping" with message size 2500, from one host to the other, > the other host gets more then one ICMP packet, even thaw the message > that was send is match smaller then the MTU. > > I tried to run this test using a different NIC, but I got the same > behavior. > > I run: > 1. On both hosts: > ifconfig mtnic0 mtu 3000 And what does 'ifconfig mtnic0 | grep mtu' says after this command? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081028/c2962631/attachment.pgp From gizmen at blurp.pl Tue Oct 28 10:35:57 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Tue Oct 28 10:36:04 2008 Subject: two NIC on 2 core system (scheduling problem) Message-ID: <200810281235.53508.gizmen@blurp.pl> Hi, i have two core system with freebsd 7.0. I have two NIC; first is em and second is bge. I wonder why system put irq processes almost always to one core. There is example: 11 root 1 171 ki31 0K 8K RUN 0 311.2H 96.19% idle: cpu0 10 root 1 171 ki31 0K 8K CPU1 1 271.4H 71.44% idle: cpu1 21 root 1 -68 - 0K 8K WAIT 1 48.8H 13.87% irq17: bge0 20 root 1 -68 - 0K 8K - 1 42.9H 11.72% em0 taskq Almost all the time irq17: bge0 and em0 taskq are on second cpu (1). I use SCHED_4BSD scheduler. How can i make system to use two cores not one for interrupt handling. On other router based on the same hardware and software i have something like that: 10 root 1 171 ki31 0K 8K RUN 1 235.4H 78.66% idle: cpu1 11 root 1 171 ki31 0K 8K RUN 0 185.2H 72.12% idle: cpu0 20 root 1 -68 - 0K 8K - 0 48.7H 23.00% em0 taskq 23 root 1 -68 - 0K 8K WAIT 0 19.2H 9.67% irq16: fxp1 21 root 1 -68 - 0K 8K WAIT 1 28.2H 8.01% irq17: bge0 I don't know why on this router system balance over two cores. One difference is that on this router i have another fxp card (3 total) Another question is why em0 taskq is eating so much cpu ? BGE interface is actually one that pushes 2 times more packets than em0 and it uses about half cpu comparing to em0. Is that not strange ? Could someone tell my why is this happening ? BGE is faster ? or maybe i can tune some From ivoras at freebsd.org Tue Oct 28 10:41:45 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 28 10:41:52 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <200810281235.53508.gizmen@blurp.pl> References: <200810281235.53508.gizmen@blurp.pl> Message-ID: <4906EC8D.7070503@freebsd.org> Bartosz Giza wrote: > Another question is why em0 taskq is eating so much cpu ? BGE interface is > actually one that pushes 2 times more packets than em0 and it uses about > half cpu comparing to em0. Is that not strange ? > Could someone tell my why is this happening ? BGE is faster ? or maybe i can > tune some I have the same problem - em0 taskq eating incredible amounts of CPU. If you find a solution, contact me! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081028/15ad1b43/signature.pgp From oleksandr at samoylyk.sumy.ua Tue Oct 28 10:55:21 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue Oct 28 10:55:33 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <200810281235.53508.gizmen@blurp.pl> References: <200810281235.53508.gizmen@blurp.pl> Message-ID: <4906ECDC.3040809@samoylyk.sumy.ua> Bartosz Giza wrote: > Hi, > > i have two core system with freebsd 7.0. I have two NIC; first is em and > second is bge. > I wonder why system put irq processes almost always to one core. > There is example: > > 11 root 1 171 ki31 0K 8K RUN 0 311.2H 96.19% idle: cpu0 > 10 root 1 171 ki31 0K 8K CPU1 1 271.4H 71.44% idle: cpu1 > 21 root 1 -68 - 0K 8K WAIT 1 48.8H 13.87% irq17: bge0 > 20 root 1 -68 - 0K 8K - 1 42.9H 11.72% em0 taskq > > Almost all the time irq17: bge0 and em0 taskq are on second cpu (1). > I use SCHED_4BSD scheduler. How can i make system to use two cores not one > for interrupt handling. In Linux it is possible to use SMP IRQ Affinity to attach IRQs to different CPUs. I wonder if there any way to do the same with FreeBSD? -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Tue Oct 28 10:55:21 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue Oct 28 10:55:33 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <4906EC8D.7070503@freebsd.org> References: <200810281235.53508.gizmen@blurp.pl> <4906EC8D.7070503@freebsd.org> Message-ID: <4906EE31.3080400@samoylyk.sumy.ua> Ivan Voras wrote: > Bartosz Giza wrote: > >> Another question is why em0 taskq is eating so much cpu ? BGE interface is >> actually one that pushes 2 times more packets than em0 and it uses about >> half cpu comparing to em0. Is that not strange ? >> Could someone tell my why is this happening ? BGE is faster ? or maybe i can >> tune some > > I have the same problem - em0 taskq eating incredible amounts of CPU. If > you find a solution, contact me! > > It could be not just a problem with em driver. Firstly, it's good to make profiling and find out what exactly eats CPU time. -- Oleksandr Samoylyk OVS-RIPE From r_de_sousa at yahoo.com Tue Oct 28 02:52:38 2008 From: r_de_sousa at yahoo.com (Roberto de Sousa) Date: Tue Oct 28 11:12:07 2008 Subject: NSupdate from CLI Message-ID: <712773.35896.qm@web45205.mail.sp1.yahoo.com> HI Byung, Thank you so much share this great link. It would be great if the nsupdate can be trigger from the web too.. however, the link did not provided the instruction on how to do that... Do you have any advise? Thanks. Roberto ________________________________ From: Byung-Hee HWANG To: Roberto de Sousa Cc: freebsd-net@freebsd.org Sent: Tuesday, 28 October, 2008 11:08:53 AM Subject: Re: NSupdate from CLI -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roberto de Sousa wrote: > Hello all, > Can someone direct me where to go to find out example of how to create a script using nsupdate from CLI to add host to forward and reversing zone of DNS? > I am new to Unix and just installed my freeBSD box which running apache and BIND last month. > > Any advise or information will be highly appreciated. > > Thanks all. > > Roberto Roberto, this is not what you want really. However i would like to recommend for you. See ;; byunghee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkkGWBUACgkQsCouaZaxlv5tdwCgnjLg4lmjW++pqbhQDF+tOv1r Nm0AnR3NZg9unwAfxaKCXopNo5V7q5Jg =z4E4 -----END PGP SIGNATURE----- Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail From lev at serebryakov.spb.ru Tue Oct 28 11:18:44 2008 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Tue Oct 28 11:18:57 2008 Subject: Intel PRO/1000 PT: Desktop (EXPI9300PT) vs Server (EXPI9400PT) editions? Message-ID: <104920145.20081028140237@serebryakov.spb.ru> Hello, Freebsd-net. Is here any real difference between two versions of this network adapter? According to documents on Intel site, only difference I can see is that server version goes with two brackets: standard and low-profile one. Everything other is same: picture, controller, specifications... And prices ARE different: $100 vs $50... -- // Black Lion AKA Lev Serebryakov From ivoras at freebsd.org Tue Oct 28 11:21:00 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 28 11:21:06 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <4906EE31.3080400@samoylyk.sumy.ua> References: <200810281235.53508.gizmen@blurp.pl> <4906EC8D.7070503@freebsd.org> <4906EE31.3080400@samoylyk.sumy.ua> Message-ID: Oleksandr Samoylyk wrote: > Ivan Voras wrote: >> Bartosz Giza wrote: >> >>> Another question is why em0 taskq is eating so much cpu ? BGE >>> interface is actually one that pushes 2 times more packets than em0 >>> and it uses about half cpu comparing to em0. Is that not strange ? >>> Could someone tell my why is this happening ? BGE is faster ? or >>> maybe i can tune some >> >> I have the same problem - em0 taskq eating incredible amounts of CPU. If >> you find a solution, contact me! >> >> > > It could be not just a problem with em driver. > Firstly, it's good to make profiling and find out what exactly eats CPU Can you give any pointers on how to profile the driver and/or the network stack? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081028/f57a9dce/signature.pgp From bartosz.giza at korbank.pl Tue Oct 28 11:25:07 2008 From: bartosz.giza at korbank.pl (Bartosz Giza) Date: Tue Oct 28 11:25:14 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <4906EE31.3080400@samoylyk.sumy.ua> References: <200810281235.53508.gizmen@blurp.pl> <4906EC8D.7070503@freebsd.org> <4906EE31.3080400@samoylyk.sumy.ua> Message-ID: <200810281309.58262.bartosz.giza@korbank.pl> Tuesday 28 of October 2008 11:49:21 Oleksandr Samoylyk napisa?(a): > Ivan Voras wrote: > > Bartosz Giza wrote: > >> Another question is why em0 taskq is eating so much cpu ? BGE > >> interface is actually one that pushes 2 times more packets than em0 > >> and it uses about half cpu comparing to em0. Is that not strange ? > >> Could someone tell my why is this happening ? BGE is faster ? or maybe > >> i can tune some > > > > I have the same problem - em0 taskq eating incredible amounts of CPU. > > If you find a solution, contact me! > > It could be not just a problem with em driver. > Firstly, it's good to make profiling and find out what exactly eats CPU > time. Yes, we should make some profiling, but it is quite hard on busy production router. When i turn on pooling on em0 card swi1: net is using about 3% of cpu. So it is quite big difference between 20% with tasq and 3% with polling. BTW: i am using em0@pci0:3:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82572EI PRO/1000 PT Desktop Adapter (Copper)' class = network subclass = ethernet I know it is desktop card but i thnik it should not use so much cpu. Besides intel card and em driver is supposed to be the best on freebsd. But from my observation bge cards are better for now. -- Pozdrawiam, Bartosz Giza, Administrator sieci Korbank sp. z o.o. From dudu at dudu.ro Tue Oct 28 11:27:55 2008 From: dudu at dudu.ro (Vlad GALU) Date: Tue Oct 28 11:28:02 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <4906EC8D.7070503@freebsd.org> References: <200810281235.53508.gizmen@blurp.pl> <4906EC8D.7070503@freebsd.org> Message-ID: On Tue, Oct 28, 2008 at 12:42 PM, Ivan Voras wrote: > Bartosz Giza wrote: > >> Another question is why em0 taskq is eating so much cpu ? BGE interface is >> actually one that pushes 2 times more packets than em0 and it uses about >> half cpu comparing to em0. Is that not strange ? >> Could someone tell my why is this happening ? BGE is faster ? or maybe i can >> tune some > > I have the same problem - em0 taskq eating incredible amounts of CPU. If > you find a solution, contact me! > > > Could this be related to the different interrupt handling models? em(4) uses FILTER, the others use ITHREAD. -- ~/.signature: no such file or directory From ivoras at freebsd.org Tue Oct 28 11:29:17 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 28 11:29:24 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <200810281309.58262.bartosz.giza@korbank.pl> References: <200810281235.53508.gizmen@blurp.pl> <4906EC8D.7070503@freebsd.org> <4906EE31.3080400@samoylyk.sumy.ua> <200810281309.58262.bartosz.giza@korbank.pl> Message-ID: Bartosz Giza wrote: > Tuesday 28 of October 2008 11:49:21 Oleksandr Samoylyk napisa?(a): >> Ivan Voras wrote: >>> Bartosz Giza wrote: >>>> Another question is why em0 taskq is eating so much cpu ? BGE >>>> interface is actually one that pushes 2 times more packets than em0 >>>> and it uses about half cpu comparing to em0. Is that not strange ? >>>> Could someone tell my why is this happening ? BGE is faster ? or maybe >>>> i can tune some >>> I have the same problem - em0 taskq eating incredible amounts of CPU. >>> If you find a solution, contact me! >> It could be not just a problem with em driver. >> Firstly, it's good to make profiling and find out what exactly eats CPU >> time. > > Yes, we should make some profiling, but it is quite hard on busy production > router. When i turn on pooling on em0 card swi1: net is using about 3% of > cpu. So it is quite big difference between 20% with tasq and 3% with > polling. Is the difference reflected in your system / idle CPU time? (i.e. does your idle time increase for ~~ 17%?) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081028/17e8b6a6/signature.pgp From gizmen at blurp.pl Tue Oct 28 11:32:55 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Tue Oct 28 11:33:02 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <4906ECDC.3040809@samoylyk.sumy.ua> References: <200810281235.53508.gizmen@blurp.pl> <4906ECDC.3040809@samoylyk.sumy.ua> Message-ID: <200810281332.52725.gizmen@blurp.pl> Tuesday 28 of October 2008 11:43:40 Oleksandr Samoylyk napisa?(a): > Bartosz Giza wrote: > > Hi, > > > > i have two core system with freebsd 7.0. I have two NIC; first is em > > and second is bge. > > I wonder why system put irq processes almost always to one core. > > There is example: > > > > 11 root 1 171 ki31 0K 8K RUN 0 311.2H 96.19% idle: > > cpu0 10 root 1 171 ki31 0K 8K CPU1 1 271.4H 71.44% > > idle: cpu1 21 root 1 -68 - 0K 8K WAIT 1 48.8H > > 13.87% irq17: bge0 20 root 1 -68 - 0K 8K - 1 > > 42.9H 11.72% em0 taskq > > > > Almost all the time irq17: bge0 and em0 taskq are on second cpu (1). > > I use SCHED_4BSD scheduler. How can i make system to use two cores not > > one for interrupt handling. > > In Linux it is possible to use SMP IRQ Affinity to attach IRQs to > different CPUs. > > I wonder if there any way to do the same with FreeBSD? AFAIK freebsd does not support such thing. But it would be really quite nice feature to have. Other thing what i think would be cool to have couple of processes which are responsible for polling (swi1:net) probably one per NIC. This would benefit from multi core systems (i think) From gizmen at blurp.pl Tue Oct 28 12:04:28 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Tue Oct 28 12:04:35 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: References: <200810281235.53508.gizmen@blurp.pl> <200810281309.58262.bartosz.giza@korbank.pl> Message-ID: <200810281404.24067.gizmen@blurp.pl> Tuesday 28 of October 2008 12:29:54 Ivan Voras napisa?(a): > Bartosz Giza wrote: > > Tuesday 28 of October 2008 11:49:21 Oleksandr Samoylyk napisa?(a): > >> Ivan Voras wrote: > >>> Bartosz Giza wrote: > >>>> Another question is why em0 taskq is eating so much cpu ? BGE > >>>> interface is actually one that pushes 2 times more packets than em0 > >>>> and it uses about half cpu comparing to em0. Is that not strange ? > >>>> Could someone tell my why is this happening ? BGE is faster ? or > >>>> maybe i can tune some > >>> > >>> I have the same problem - em0 taskq eating incredible amounts of CPU. > >>> If you find a solution, contact me! > >> > >> It could be not just a problem with em driver. > >> Firstly, it's good to make profiling and find out what exactly eats > >> CPU time. > > > > Yes, we should make some profiling, but it is quite hard on busy > > production router. When i turn on pooling on em0 card swi1: net is > > using about 3% of cpu. So it is quite big difference between 20% with > > tasq and 3% with polling. > > Is the difference reflected in your system / idle CPU time? (i.e. does > your idle time increase for ~~ 17%?) Yes exactly my idle time is increasing ~17% For now i am not using polling But i am preparing the same machine for much more bussier router and i am not sure that this router with em cards will suffice. From ndenev at gmail.com Tue Oct 28 13:43:15 2008 From: ndenev at gmail.com (Nikolay Denev) Date: Tue Oct 28 13:43:22 2008 Subject: ifconfig em0 mtu 9000 does not update the routing table Message-ID: Hello, As the subject says, I'm trying to enable jumbo frames on running machine by setting ifconfig em0 mtu 9000 by hand, but nothing changed, and I've fount that when I list the routing table with the MTU column it shows the connected routes still with MTU 1500. Is this supposed to work this way? I understand that making ifconfig touch the routing table is ugly hack, but maybe the routing code can be notified for interface changes by some other mechanism? btw, this is on 7-STABLE with if_em(4) interfaces. -- Regards, Nikolay Denev From hlh at restart.be Tue Oct 28 14:17:46 2008 From: hlh at restart.be (Henri Hennebert) Date: Tue Oct 28 14:17:53 2008 Subject: NSupdate from CLI In-Reply-To: <723811.95360.qm@web45207.mail.sp1.yahoo.com> References: <723811.95360.qm@web45207.mail.sp1.yahoo.com> Message-ID: <49071EFF.1010806@restart.be> Roberto de Sousa wrote: > Hello Henri, > Thank you for your kindness to help me on this.. I have generated the > key and and edit my named.conf as per your instruction. I have also > tried your script which work great. What i would like to find out more > is that how to modify this script so that it provides flexibility > without having to specify the host in the script? > what i mean is that.. i could select add or delete option from CLI and > able to add any host to forward & Reversing Zone of my DNS from my > freeBSD CLI? <--- clip ---> What do you thing about the attached script ? Some more check of args may be usefull ... Henri -------------- next part -------------- #!/bin/sh usage () { echo 'Usage: dnsupdate -a|-d|-u =' echo ' -a add DNS entry for ' echo ' -d delete DNS entry for ' echo ' -u update DNS entry' } NSSERVER='xxx.xxx.xxx.xxx' TSIG='host1.example.com.:XXXX...XXXX==' #------------------------- case $# in 2) ;; *) usage >&2; exit 1;; esac HOSTNAME=${2%%=*} IPADDR=${2##*=} if [ ${HOSTNAME} = $2 -o ${IPADDR} = $2 ] then usage >&2; exit 1 fi IPADDR1=${IPADDR%%.*} IPADDRX=${IPADDR#*.} IPADDR2=${IPADDRX%%.*} IPADDRX=${IPADDRX#*.} IPADDR3=${IPADDRX%%.*} IPADDR4=${IPADDRX#*.} if [ "${IPADDR1}.${IPADDR2}.${IPADDR3}.${IPADDR4}" != ${IPADDR} ] then usage >&2; exit 1 fi delete() { echo update delete ${HOSTNAME}. IN A echo update delete ${IPADDR4}.${IPADDR3}.${IPADDR2}.${IPADDR1}.in-addr.arpa. IN PTR } add() { echo update add ${HOSTNAME}. 60 IN A ${IPADDR} echo update add ${IPADDR4}.${IPADDR3}.${IPADDR2}.${IPADDR1}.in-addr.arpa. 60 IN PTR ${HOSTNAME}. } case $1 in -a|-d|-u) ;; *) usage >&2; exit 1;; esac case $1 in -a) echo server ${NSSERVER}; add; echo send;; -d) echo server ${NSSERVER}; delete; echo send;; -u) echo server ${NSSERVER}; delete; add; echo send;; esac | /usr/bin/nsupdate -y ${TSIG} 1>/dev/null From r_de_sousa at yahoo.com Tue Oct 28 14:40:40 2008 From: r_de_sousa at yahoo.com (Roberto de Sousa) Date: Tue Oct 28 14:40:47 2008 Subject: NSupdate from CLI Message-ID: <47835.95227.qm@web45215.mail.sp1.yahoo.com> Hi Henri, thanks for the help. I have this script : #!/bin/sh IPADDR=`ifconfig em0 | grep 'inet addr:[0-9]' | tr -s " " | cut -d" " -f3 | tr -d "addr:"` echo "update delete host1.customer. A" >> /etc/nsupdate echo "update delete host2.customer. CNAME" >> /etc/nsupdate echo "update add host5.customer 86400 A $IPADDR" >> /etc/nsupdate echo "update add *.customer. 38400 CNAME ns2.customer." >> /etc/nsupdate echo "show" >> /etc/nsupdate echo "send" >> /etc/nsupdate echo "" >> /etc/nsupdate /usr/bin/nsupdate -k Kmydns.com.+157+62440.private -d /etc/nsupdate However, when i tried to run it, i got there messages : root@admin# ./test2.sh server: not found zone: not found update: not found update: not found update: not found update: not found show: not found send: not found It seem that the nsupdate things still take the value from the /etc/nsupdate even i have renamed the /etc/nsupdate to /etc/old... Do you have any clue why it still referring it? i also have change the test2.sh to test3.sh and execute the script but i still got the above message. Any advise will be highly appreciated. Thank you. Roberto buka wainhira la hatene, buka atu hatene liu tan abracos ________________________________ From: Henri Hennebert To: Roberto de Sousa Cc: freebsd-net@freebsd.org Sent: Wednesday, 29 October, 2008 1:17:35 AM Subject: Re: NSupdate from CLI Roberto de Sousa wrote: > Hello Henri, > Thank you for your kindness to help me on this.. I have generated the > key and and edit my named.conf as per your instruction. I have also > tried your script which work great. What i would like to find out more > is that how to modify this script so that it provides flexibility > without having to specify the host in the script? > what i mean is that.. i could select add or delete option from CLI and > able to add any host to forward & Reversing Zone of my DNS from my > freeBSD CLI? <--- clip ---> What do you thing about the attached script ? Some more check of args may be usefull ... Henri Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail From mav at FreeBSD.org Tue Oct 28 15:12:11 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Oct 28 15:12:18 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <1225203780.00029971.1225190402@10.7.7.3> References: <1225203780.00029971.1225190402@10.7.7.3> Message-ID: <49072BC9.4010103@FreeBSD.org> Bartosz Giza wrote: > On other router based on the same hardware and software i have something > like that: > > 10 root 1 171 ki31 0K 8K RUN 1 235.4H 78.66% idle: cpu1 > 11 root 1 171 ki31 0K 8K RUN 0 185.2H 72.12% idle: cpu0 > 20 root 1 -68 - 0K 8K - 0 48.7H 23.00% em0 taskq > 23 root 1 -68 - 0K 8K WAIT 0 19.2H 9.67% irq16: fxp1 > 21 root 1 -68 - 0K 8K WAIT 1 28.2H 8.01% irq17: bge0 > > I don't know why on this router system balance over two cores. One > difference is that on this router i have another fxp card (3 total) In verbose boot messages system shows that different IRQs assigned to different APICs in round-robin fashion. So I may assume that this IRQ->CPU mapping is static. em0's taskqueue at the same time able to migrate CPUs as any usual process. > Another question is why em0 taskq is eating so much cpu ? BGE interface is > actually one that pushes 2 times more packets than em0 and it uses about > half cpu comparing to em0. Is that not strange ? > Could someone tell my why is this happening ? BGE is faster ? or maybe i can > tune some The CPU time you see there includes much more then just a card handling itself. It also includes CPU time of the most parts of network stack used to process received packet. So if you have NAT, big firewall, netgraph or any other CPU-hungry actions done with packets incoming via em0 you will see such results. Even more interesting is that if bge0 or fxp0 cards will require much CPU time to send packet, this time will also be accounted to em0 process. :) -- Alexander Motin From gizmen at blurp.pl Tue Oct 28 16:13:16 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Tue Oct 28 16:13:22 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <49072BC9.4010103@FreeBSD.org> References: <1225203780.00029971.1225190402@10.7.7.3> <49072BC9.4010103@FreeBSD.org> Message-ID: <200810281613.13719.gizmen@blurp.pl> On Tuesday 28 of October 2008 15:12:09 Alexander Motin wrote: > Bartosz Giza wrote: > > On other router based on the same hardware and software i have something > > like that: > > > > 10 root 1 171 ki31 0K 8K RUN 1 235.4H 78.66% idle: > > cpu1 11 root 1 171 ki31 0K 8K RUN 0 185.2H 72.12% idle: > > cpu0 20 root 1 -68 - 0K 8K - 0 48.7H 23.00% em0 > > taskq 23 root 1 -68 - 0K 8K WAIT 0 19.2H 9.67% > > irq16: fxp1 21 root 1 -68 - 0K 8K WAIT 1 28.2H 8.01% > > irq17: bge0 > > > > I don't know why on this router system balance over two cores. One > > difference is that on this router i have another fxp card (3 total) > > In verbose boot messages system shows that different IRQs assigned to > different APICs in round-robin fashion. So I may assume that this > IRQ->CPU mapping is static. em0's taskqueue at the same time able to > migrate CPUs as any usual process. I am not sure it is that true. When i watch top i see that sometimes irq: bge0 process switch to core 0 but most of the time is on core 1. So scheduler sometimes put this process on different core. > > Another question is why em0 taskq is eating so much cpu ? BGE interface > > is actually one that pushes 2 times more packets than em0 and it uses > > about half cpu comparing to em0. Is that not strange ? > > Could someone tell my why is this happening ? BGE is faster ? or maybe i > > can tune some > > The CPU time you see there includes much more then just a card handling > itself. It also includes CPU time of the most parts of network stack > used to process received packet. So if you have NAT, big firewall, > netgraph or any other CPU-hungry actions done with packets incoming via > em0 you will see such results. > Even more interesting is that if bge0 or fxp0 cards will require much > CPU time to send packet, this time will also be accounted to em0 process. > :) WOW that is weird. Yes i have quite big ipfw firewall and also couple of rules from pf. So you are saying that whole overhead from firewall is counted to this em taskq process. This is really strange for somebody who don't know about this. So what in case if i would have two em nic's. How would then overhead from firewalls be counted ? Splited to two taskq processes ? And another really weird thing is that if i have other card their processing are counted to tasq process of different NIC. Why is this done in such a way ? From jfvogel at gmail.com Tue Oct 28 16:41:17 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Oct 28 16:41:23 2008 Subject: ifconfig em0 mtu 9000 does not update the routing table In-Reply-To: References: Message-ID: <2a41acea0810280941g6c9846y6e0d4b8b19313e0a@mail.gmail.com> It can't change the route table when you've given it no address: IE. ifconfig em0 HOSTNAME mtu 9000 will update it just fine. Cheers, Jack On Tue, Oct 28, 2008 at 6:15 AM, Nikolay Denev wrote: > Hello, > > As the subject says, I'm trying to enable jumbo frames on running machine > by setting > ifconfig em0 mtu 9000 by hand, but nothing changed, and I've fount that > when I list > the routing table with the MTU column it shows the connected routes still > with MTU 1500. > Is this supposed to work this way? I understand that making ifconfig touch > the routing table is ugly hack, but maybe the routing code can be notified > for interface changes by some other mechanism? > > btw, this is on 7-STABLE with if_em(4) interfaces. > > -- > Regards, > Nikolay Denev > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From kordex at gmail.com Tue Oct 28 17:53:23 2008 From: kordex at gmail.com (kordex -) Date: Tue Oct 28 17:53:30 2008 Subject: nfe driver bad performance on FreeBSD 7 In-Reply-To: <20081025083027.GD59215@cdnetworks.co.kr> References: <8b8dd87a0810230602i39bbb291h6777f41022d3f0d4@mail.gmail.com> <20081025083027.GD59215@cdnetworks.co.kr> Message-ID: <8b8dd87a0810281053iccbd10we4d1687ceba0a89f@mail.gmail.com> I found the reason for bad performance. It also affected the non-free nvidia glx driver. It was options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions not set in the kernel configuration. --Mikko Kortelainen 2008/10/25 Pyun YongHyeon > On Thu, Oct 23, 2008 at 04:02:48PM +0300, kordex - wrote: > > Same issue as > > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-09/msg00278.html > > > > I got HP Pavilion dv6646eo laptop with same network chip. Max throughput > is > > 800kB/s with scp. same with generic kernel. > > > > nfe0: flags=8843 metric 0 mtu > 1500 > > options=8 > > ether 00:00:00:00:00:00 > > inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > lilian# > > > > MAC being all zeros is not done by me. It's BIOS doing that. I wonder if > > that can cause things like this. No PXE Boot for me :| Should I send > this to > > warranty for that? > > > > Don't use all zeroed ethernet address. You can assign fake ethernet > address to nfe(4) with "ifconfig nfe0 ether 00:01:02:03:04:05". > The problem is why nfe(4) got all zeord station address from > controller. Does nve(4) also show the same ethernet address? > > > lilian# uname -a > > FreeBSD lilian.xnet.kx 7.0-RELEASE FreeBSD 7.0-RELEASE #3: Sat Sep 27 > > 20:36:01 UTC 2008 root@lilian.xnet.kx > :/usr/obj/usr/src/sys/LILIAN_KERN > > i386 > > > > > > lilian# dmesg > > Copyright (c) 1992-2008 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights > reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 7.0-RELEASE #3: Sat Sep 27 20:36:01 UTC 2008 > > root@lilian.xnet.kx:/usr/obj/usr/src/sys/LILIAN_KERN > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-58 (1908.67-MHz 686-class > > CPU) > > Origin = "AuthenticAMD" Id = 0x60f81 Stepping = 1 > > > > [...] > > > nfe0: port 0x30e0-0x30e7 mem > > 0xf2487000-0xf2487fff irq 20 at device 6.0 on pci0 > > miibus0: on nfe0 > > rgephy0: PHY 1 on miibus0 > > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > nfe0: [FILTER] > > There was one report of MCP65's poor performance but he said it > happens on 1000Mbps link only. Normally poor network performance > comes from speed/duplex mismatch. Does link partner also agree on > resolved speed/duplex of nfe(4)? Would you show me the output of > "netstat -ndI nfe0"? > > nfe(4) in 8-CURRENT supports hardware MAC counters and the counters > give us very valuable information to diagnose driver issues. Would > you try latest CURRENT and show me the output of > "sysctl dev.nfe.0.stats" after some network activities? > > -- > Regards, > Pyun YongHyeon > From ndenev at gmail.com Tue Oct 28 17:54:59 2008 From: ndenev at gmail.com (Nikolay Denev) Date: Tue Oct 28 17:55:06 2008 Subject: ifconfig em0 mtu 9000 does not update the routing table In-Reply-To: <2a41acea0810280941g6c9846y6e0d4b8b19313e0a@mail.gmail.com> References: <2a41acea0810280941g6c9846y6e0d4b8b19313e0a@mail.gmail.com> Message-ID: <84671113-DA04-4EFA-8640-E9AD2F09BB34@gmail.com> On 28 Oct, 2008, at 18:41 , Jack Vogel wrote: > It can't change the route table when you've given it no address: > > IE. ifconfig em0 HOSTNAME mtu 9000 will update it just fine. > > Cheers, > > Jack > > > On Tue, Oct 28, 2008 at 6:15 AM, Nikolay Denev > wrote: > Hello, > > As the subject says, I'm trying to enable jumbo frames on running > machine by setting > ifconfig em0 mtu 9000 by hand, but nothing changed, and I've fount > that when I list > the routing table with the MTU column it shows the connected routes > still with MTU 1500. > Is this supposed to work this way? I understand that making ifconfig > touch the routing table is ugly hack, but maybe the routing code can > be notified for interface changes by some other mechanism? > > btw, this is on 7-STABLE with if_em(4) interfaces. > > -- > Regards, > Nikolay Denev > Hi Jack, Yes, I understand that, It just looked logical to me to update the existing entries (directly attached) if no address is given, so one can use the mtu knob alone. Anyways, one rarely touches the mtu alone and this not a real problem, I've just tried to enable jumbo frames on two running machines with just the ifconfig em0 mtu 9000 line and wondered why it does not work for a minute. Thanks! -- Regards, Nikolay Denev From mav at FreeBSD.org Tue Oct 28 18:10:48 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Oct 28 18:10:54 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <200810281613.13719.gizmen@blurp.pl> References: <1225203780.00029971.1225190402@10.7.7.3> <49072BC9.4010103@FreeBSD.org> <200810281613.13719.gizmen@blurp.pl> Message-ID: <490755A3.4050903@FreeBSD.org> Bartosz Giza wrote: >> The CPU time you see there includes much more then just a card handling >> itself. It also includes CPU time of the most parts of network stack >> used to process received packet. So if you have NAT, big firewall, >> netgraph or any other CPU-hungry actions done with packets incoming via >> em0 you will see such results. >> Even more interesting is that if bge0 or fxp0 cards will require much >> CPU time to send packet, this time will also be accounted to em0 process. >> :) > > WOW that is weird. Yes i have quite big ipfw firewall and also couple of rules > from pf. So you are saying that whole overhead from firewall is counted to > this em taskq process. This is really strange for somebody who don't know > about this. > So what in case if i would have two em nic's. How would then overhead from > firewalls be counted ? Splited to two taskq processes ? > And another really weird thing is that if i have other card their processing > are counted to tasq process of different NIC. Why is this done in such a way ? There is no dedicated processes in system to handle routing, firewall, netgraph, etc. Many processes would lead to multiple context switches, bigger latencies and reduced performance. Instead most parts of network stack implemented in direct call fashion. So NIC receive interrupt initiates packet handling by doing stack function call, that function calls another and so on until packet will be completely processed and transmitted or queued. There is not so many exception from this rule, for example, dummynet which schedules part of activity to the timer events. So sometimes you still can see some activity from the swi:net, dummynet or some other threads. It also tells not so much about who really consumed the CPU, but more about who initiated that CPU consumption. In case of two em NICs em0 thread will mostly show load produced by em0->em1 traffic processing and em1 - load produced by em1->em0 traffic. -- Alexander Motin From jmg at funkthat.com Tue Oct 28 21:16:28 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Tue Oct 28 21:16:34 2008 Subject: It seems that FreeBSD-7.0 does not use the available MTU In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> Message-ID: <20081028210215.GE51033@funkthat.com> Eitan Shefi wrote this message on Mon, Oct 27, 2008 at 23:53 +0200: > I am using 2 hosts with FreeBSD-7.0 connected directly. > When I change the MTU to a value greater then 1500, for example 3000, > and then send "ping" with message size 2500, from one host to the other, > the other host gets more then one ICMP packet, even thaw the message > that was send is match smaller then the MTU. > > I tried to run this test using a different NIC, but I got the same > behavior. > > I run: > 1. On both hosts: > ifconfig mtnic0 mtu 3000 > 2. Than on one host I run: > tcpdump -i mtnic0 icmp > 3. And on the other host I run: > ping -s 2500 -c 1 OTHER_HOST_IP (ping to "mtnic0" on the other > host) run netstat -rnW to see what the route's MTU is. Most likely you need to set the mtu before you configure an ip address on the interface so that the network's route is created w/ the correct MTU... either readd the network route, or change the mtu of the route for the host: route change -mtu 3000 OTHER_HOST_IP also change it on the network route so that when the host route gets flushed and recreated it will be created w/ the correct MTU... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From jmg at funkthat.com Tue Oct 28 21:23:51 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Tue Oct 28 21:23:57 2008 Subject: ifconfig em0 mtu 9000 does not update the routing table In-Reply-To: <84671113-DA04-4EFA-8640-E9AD2F09BB34@gmail.com> References: <2a41acea0810280941g6c9846y6e0d4b8b19313e0a@mail.gmail.com> <84671113-DA04-4EFA-8640-E9AD2F09BB34@gmail.com> Message-ID: <20081028212350.GF51033@funkthat.com> Nikolay Denev wrote this message on Tue, Oct 28, 2008 at 19:54 +0200: > On 28 Oct, 2008, at 18:41 , Jack Vogel wrote: > > >It can't change the route table when you've given it no address: > > > >IE. ifconfig em0 HOSTNAME mtu 9000 will update it just fine. > > > >Cheers, > > > >Jack > > > > > >On Tue, Oct 28, 2008 at 6:15 AM, Nikolay Denev > >wrote: > >Hello, > > > >As the subject says, I'm trying to enable jumbo frames on running > >machine by setting > >ifconfig em0 mtu 9000 by hand, but nothing changed, and I've fount > >that when I list > >the routing table with the MTU column it shows the connected routes > >still with MTU 1500. > >Is this supposed to work this way? I understand that making ifconfig > >touch the routing table is ugly hack, but maybe the routing code can > >be notified for interface changes by some other mechanism? > > > >btw, this is on 7-STABLE with if_em(4) interfaces. > > > >-- > >Regards, > >Nikolay Denev > > > > > Hi Jack, > > Yes, I understand that, It just looked logical to me to update the > existing entries (directly attached) if no address is given, so one > can use the mtu knob alone. > > Anyways, one rarely touches the mtu alone and this not a real problem, > I've just tried to enable jumbo frames on two running machines with > just the ifconfig em0 mtu 9000 line and wondered why it does not work > for a minute. But what happens if you are talking to a machine that doesn't have jumbo frames enabled? You'd loose communications with the machines if ifconfig auto updated... The real missing part of the puzzle is a daemon that sits around and probes neighbor's MRU size and updates each host route w/ the size that is supported by that host... /me has want to write such a daemon, but the work to do it in C is time consuming. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From freebsd at hub.org Tue Oct 28 23:57:01 2008 From: freebsd at hub.org (Marc G. Fournier) Date: Tue Oct 28 23:57:08 2008 Subject: Problem with Bridging ... and bge devices under FreeBSD 7.x? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to run a QEMU VM on top of a FreeBSD 7.x server ... I've tried the exact same setup on my desktop, using 192.168.1.x and an fxp device, and it all works perfectly, but as soon as I do this on another machine on a public IP, I'm not getting any routing, I can't even ping it from the same machine ... My first thought was that there was an issue with IP aliases already on the bge device, but tried doing the following: ifconfig bridge0 destroy ifconfig tap0 destroy ifconfig fxp0 -alias 192.168.1.101 ifconfig fxp0 alias 192.168.1.101 netmask 255.255.255.255 ifconfig bridge0 create ifconfig tap0 create ifconfig bridge0 addm fxp0 addm tap0 up on my desktop here and then starting up the qemu image, and all worked as expected, so having an alias on the interface, before or after, doesn't make a difference ... at least with the fxp device ... Using VNC to connect to the VM, I can look at the interface, and it says it is connected ... and the IP/Gateway are all set right for the network I'm on, netmask is set to 255.255.255.0, same as on the 'private network' ... Please note that when I say "it works" on my private network / desktop, I'm using it to connect to my work computer, across the Internet, via Windows RDP, and it works flawlessly ... Looking at /var/log/messages, you can see the bridge being setup: Oct 27 18:53:21 io kernel: bridge0: Ethernet address: ce:44:c7:1b:47:40 as well as the tap device: Oct 27 18:53:25 io kernel: tap0: Ethernet address: 00:bd:96:ae:67:00 Oct 27 18:53:41 io kernel: tap0: promiscuous mode enabled and the ethernet going promiscuous: Oct 26 20:53:56 ganymede kernel: fxp0: promiscuous mode enabled So, all I have left is that everything is being setup okay, but there is something I'm missing here ... something with bridge<->bge, maybe? I've even tries to compare the output of 'ifconfig -a' as far as the bridge0 and tap0 devices are concerned, and other then the mac address, they look identical also ... So, pointers to what I may be missing here? a sysctl value that I need to set for this interface? Thanks ... - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkHpscACgkQ4QvfyHIvDvPnFgCgk+6Pg+QeYO0BD9KMIkyZK2g7 JWgAn3VHq+F1OzD9M8VuYLEZDQLfFsNU =+3J/ -----END PGP SIGNATURE----- From mike at jellydonut.org Wed Oct 29 02:34:30 2008 From: mike at jellydonut.org (Michael Proto) Date: Wed Oct 29 02:34:36 2008 Subject: Problem with Bridging ... and bge devices under FreeBSD 7.x? In-Reply-To: References: Message-ID: <1de79840810281908i616a8086r474d4329de184f37@mail.gmail.com> On Tue, Oct 28, 2008 at 7:56 PM, Marc G. Fournier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I'm trying to run a QEMU VM on top of a FreeBSD 7.x server ... I've tried > the > exact same setup on my desktop, using 192.168.1.x and an fxp device, and it > all > works perfectly, but as soon as I do this on another machine on a public > IP, > I'm not getting any routing, I can't even ping it from the same machine ... > > My first thought was that there was an issue with IP aliases already on > the > bge device, but tried doing the following: > > ifconfig bridge0 destroy > ifconfig tap0 destroy > ifconfig fxp0 -alias 192.168.1.101 > ifconfig fxp0 alias 192.168.1.101 netmask 255.255.255.255 > ifconfig bridge0 create > ifconfig tap0 create > ifconfig bridge0 addm fxp0 addm tap0 up > > on my desktop here and then starting up the qemu image, and all worked as > expected, so having an alias on the interface, before or after, doesn't > make a > difference ... at least with the fxp device ... > > Using VNC to connect to the VM, I can look at the interface, and it says it > is > connected ... and the IP/Gateway are all set right for the network I'm on, > netmask is set to 255.255.255.0, same as on the 'private network' ... > > Please note that when I say "it works" on my private network / desktop, I'm > using it to connect to my work computer, across the Internet, via Windows > RDP, > and it works flawlessly ... > > Looking at /var/log/messages, you can see the bridge being setup: > > > Oct 27 18:53:21 io kernel: bridge0: Ethernet address: ce:44:c7:1b:47:40 > > as well as the tap device: > > Oct 27 18:53:25 io kernel: tap0: Ethernet address: 00:bd:96:ae:67:00 > Oct 27 18:53:41 io kernel: tap0: promiscuous mode enabled > > and the ethernet going promiscuous: > > Oct 26 20:53:56 ganymede kernel: fxp0: promiscuous mode enabled > > So, all I have left is that everything is being setup okay, but there is > something I'm missing here ... something with bridge<->bge, maybe? I've > even > tries to compare the output of 'ifconfig -a' as far as the bridge0 and tap0 > devices are concerned, and other then the mac address, they look identical > also > ... > > So, pointers to what I may be missing here? a sysctl value that I need to > set > for this interface? > > I'm having a little trouble understanding the setup you have. In your test case, is the IP of your VM 192.168.1.101? If so, then I don't think you want that IP aliased on the physical interface of your bridge. The VM NIC will answer for packets destined on your local segment, which the bridge would forward to the physical interface. If you assign the VM's IP to that physical interface, then your host would think that traffic is destined for itself and not pass it to the bridge. If I'm misunderstanding and the 192.168.1.101 alias (or whatever the equiv in your production setup) isn't being used by your VM then I would start looking at the ARP traffic crossing both the tap0, lo0, and physical interfaces. What does an 'ifconfig -a' look like on both systems? netstat -rn? Any packet filtering? -Proto From freebsd at hub.org Wed Oct 29 03:35:46 2008 From: freebsd at hub.org (Marc G. Fournier) Date: Wed Oct 29 03:35:53 2008 Subject: Problem with Bridging ... and bge devices under FreeBSD 7.x? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, October 28, 2008 22:08:18 -0400 Michael Proto wrote: > > > > On Tue, Oct 28, 2008 at 7:56 PM, Marc G. Fournier wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I'm trying to run a QEMU VM on top of a FreeBSD 7.x server ... I've tried the > exact same setup on my desktop, using 192.168.1.x and an fxp device, and it > all > works perfectly, but as soon as I do this on another machine on a public IP, > I'm not getting any routing, I can't even ping it from the same machine ... > > My first thought was that there was an issue with IP aliases already on the > bge device, but tried doing the following: > > ifconfig bridge0 destroy > ifconfig tap0 destroy > ifconfig fxp0 -alias 192.168.1.101 > ifconfig fxp0 alias 192.168.1.101 netmask 255.255.255.255 > ifconfig bridge0 create > ifconfig tap0 create > ifconfig bridge0 addm fxp0 addm tap0 up > > on my desktop here and then starting up the qemu image, and all worked as > expected, so having an alias on the interface, before or after, doesn't make a > difference ... at least with the fxp device ... > > Using VNC to connect to the VM, I can look at the interface, and it says it is > connected ... and the IP/Gateway are all set right for the network I'm on, > netmask is set to 255.255.255.0, same as on the 'private network' ... > > Please note that when I say "it works" on my private network / desktop, I'm > using it to connect to my work computer, across the Internet, via Windows RDP, > and it works flawlessly ... > > Looking at /var/log/messages, you can see the bridge being setup: > > > Oct 27 18:53:21 io kernel: bridge0: Ethernet address: ce:44:c7:1b:47:40 > > as well as the tap device: > > Oct 27 18:53:25 io kernel: tap0: Ethernet address: 00:bd:96:ae:67:00 > Oct 27 18:53:41 io kernel: tap0: promiscuous mode enabled > > and the ethernet going promiscuous: > > Oct 26 20:53:56 ganymede kernel: fxp0: promiscuous mode enabled > > So, all I have left is that everything is being setup okay, but there is > something I'm missing here ... something with bridge<->bge, maybe? I've even > tries to compare the output of 'ifconfig -a' as far as the bridge0 and tap0 > devices are concerned, and other then the mac address, they look identical > also > ... > > So, pointers to what I may be missing here? a sysctl value that I need to set > for this interface? > > > > > I'm having a little trouble understanding the setup you have. In your test > case, is the IP of your VM 192.168.1.101? If so, then I don't think you want > that IP aliased on the physical interface of your bridge. The VM NIC will > answer for packets destined on your local segment, which the bridge would > forward to the physical interface. If you assign the VM's IP to that physical > interface, then your host would think that traffic is destined for itself and > not pass it to the bridge. > > If I'm misunderstanding and the 192.168.1.101 alias (or whatever the equiv in > your production setup) isn't being used by your VM then I would start looking > at the ARP traffic crossing both the tap0, lo0, and physical interfaces. > > What does an 'ifconfig -a' look like on both systems? netstat -rn? Any packet > filtering? I always fear I'm going to send more info then I should, and generate chaos and confusion :) On my test box, the VM is set to 192.168.1.100 ... the alias I added to fxp0 was to simulate what I have on the "public server", where there is a bge0 device with n aliases attached to it ... in no case is the IP assigned to the VM actually aliased onto any interface on the network itself Now, to try and answer your other questions ... netstat -nr on the 192 server shows the IP to be at: > netstat -nr | grep 168.1.100 192.168.1.100 52:54:00:12:34:56 UHLW 1 1 fxp0 1128 which is very odd, as that MAC address is not found via ifconfig -a: > ifconfig -a | grep 52 > while arp -a also shows the 52:54 MAC, although MACs for the ifconfig -a are, in fact: > ifconfig -a | grep ether ether 00:02:b3:ee:da:3e ether 5e:d1:e6:8b:55:50 ether 00:bd:25:18:6d:00 On the server, I'm getting nothing in arp or netstat for the IP in question: io# arp -a | grep 204.213 io# netstat -nr | grep 204.213 io# I've even tried doing a ping *from* the VM (logged in with VNC) to see if it will broadcast itself out, and nothing ... I'm starting QEMU on both servers with the same options as well: qemu -m 512M -net nic -net tap winxp.img just to confirm that I'm not doing anything different for attaching to the network ... So, right now, all I can see as being "different" is bge vs fxp interfaces ... both machines are running 7.x ... - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkH2gcACgkQ4QvfyHIvDvNHUgCgtQORpycxkREQuiogWWOwydWG WfUAoOlRghz5Iy7XYWwwpOI5JgMjmBfi =3Q5f -----END PGP SIGNATURE----- From bakul at bitblocks.com Wed Oct 29 04:14:30 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Wed Oct 29 04:14:37 2008 Subject: Problem with Bridging ... and bge devices under FreeBSD 7.x? In-Reply-To: Your message of "Wed, 29 Oct 2008 00:35:35 -0300." References: Message-ID: <20081029041428.DC80C5B46@mail.bitblocks.com> On Wed, 29 Oct 2008 00:35:35 -0300 "Marc G. Fournier" wrote: > netstat -nr on the 192 server shows the IP to be at: > > > netstat -nr | grep 168.1.100 > 192.168.1.100 52:54:00:12:34:56 UHLW 1 1 fxp0 1128 > > which is very odd, as that MAC address is not found via ifconfig -a: > > > ifconfig -a | grep 52 > > > > while arp -a also shows the 52:54 MAC, although MACs for the ifconfig -a are, > > in fact: > > > ifconfig -a | grep ether > ether 00:02:b3:ee:da:3e > ether 5e:d1:e6:8b:55:50 > ether 00:bd:25:18:6d:00 The setup you get with a tap device talking to qemu is this: [host]-tap0----qemu---ed0-[VM] Each end has its own mac address. The VM's NIC (ed0 or rl0 or whatever) gets addresses like 52:54:00:12:34:56. The host will have an arp entry for it once the VM sends an arp packet. But tap0 will have an address assigned by the tap driver, something like 00:bd:xx:xx:xx. If you have two VMs running at the same time on two different machines and they both have identical MAC addresses, that could be part of your problem. But your network topolgy is still not clear. What would help is something like this: You have: machine A (runs VM A1). machine B (runs VM B1). machine C (runs windows). Can you ping from A to C? Can you ping from B to C? Can you ping from A to A1? Can you ping from B to B1? Can you ping from A1 to C? Can you ping from B1 to C? Can you ping from C to A1? Can you ping from C to B1? All of the above should work. Next you can try tcpdump on tap devices to see what is going on. If you are still stumped provide ifconfig -a output on A, B, C, A1 and B1. On windows machine you can do ipconfig/all to get at this information (IIRC). From freebsd at hub.org Wed Oct 29 04:38:54 2008 From: freebsd at hub.org (Marc G. Fournier) Date: Wed Oct 29 04:39:06 2008 Subject: Problem with Bridging ... and bge devices under FreeBSD 7.x? In-Reply-To: <20081029041428.DC80C5B46@mail.bitblocks.com> References: <20081029041428.DC80C5B46@mail.bitblocks.com> Message-ID: <7762927ECAFF08B969F9E5A0@ganymede.hub.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I only have one VM running on one server ... - --On Tuesday, October 28, 2008 21:14:28 -0700 Bakul Shah wrote: > On Wed, 29 Oct 2008 00:35:35 -0300 "Marc G. Fournier" > wrote: >> netstat -nr on the 192 server shows the IP to be at: >> >> > netstat -nr | grep 168.1.100 >> 192.168.1.100 52:54:00:12:34:56 UHLW 1 1 fxp0 1128 >> >> which is very odd, as that MAC address is not found via ifconfig -a: >> >> > ifconfig -a | grep 52 >> > >> >> while arp -a also shows the 52:54 MAC, although MACs for the ifconfig -a are, >> >> in fact: >> >> > ifconfig -a | grep ether >> ether 00:02:b3:ee:da:3e >> ether 5e:d1:e6:8b:55:50 >> ether 00:bd:25:18:6d:00 > > The setup you get with a tap device talking to qemu is this: > > [host]-tap0----qemu---ed0-[VM] > > Each end has its own mac address. The VM's NIC (ed0 or rl0 > or whatever) gets addresses like 52:54:00:12:34:56. The host > will have an arp entry for it once the VM sends an arp > packet. But tap0 will have an address assigned by the tap > driver, something like 00:bd:xx:xx:xx. > > If you have two VMs running at the same time on two different > machines and they both have identical MAC addresses, that > could be part of your problem. > > But your network topolgy is still not clear. What would help > is something like this: > > You have: > machine A (runs VM A1). > machine B (runs VM B1). > machine C (runs windows). > > Can you ping from A to C? > Can you ping from B to C? > Can you ping from A to A1? > Can you ping from B to B1? > Can you ping from A1 to C? > Can you ping from B1 to C? > Can you ping from C to A1? > Can you ping from C to B1? > > All of the above should work. Next you can try tcpdump on > tap devices to see what is going on. If you are still > stumped provide ifconfig -a output on A, B, C, A1 and B1. On > windows machine you can do ipconfig/all to get at this > information (IIRC). - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkH6M4ACgkQ4QvfyHIvDvPciwCgi3LwM74g8DPrRC4XlkNQgFD4 eRgAnj6/CUVTkrzwr8GnzawWKlbfCWBc =KgEt -----END PGP SIGNATURE----- From bakul at bitblocks.com Wed Oct 29 05:37:59 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Wed Oct 29 05:38:05 2008 Subject: Problem with Bridging ... and bge devices under FreeBSD 7.x? In-Reply-To: Your message of "Wed, 29 Oct 2008 01:38:38 -0300." <7762927ECAFF08B969F9E5A0@ganymede.hub.org> References: <20081029041428.DC80C5B46@mail.bitblocks.com> <7762927ECAFF08B969F9E5A0@ganymede.hub.org> Message-ID: <20081029053758.C638C5B46@mail.bitblocks.com> On Wed, 29 Oct 2008 01:38:38 -0300 "Marc G. Fournier" wrote: > > I only have one VM running on one server ... Ok. Here are some debugging suggestions. - /etc/sysctl.conf should have the following; net.link.tap.user_open=1 net.link.tap.up_on_open=1 run sysctl manually to set these. - if you are running qemu as user foo (and not root) you will need own tap0 foo:foo in /etc/devfs.conf and do /etc/rc.d/devfs restart. - start qemu with -monitor stdio as this will give you a command line interface to qemu. Now you can type info network to see what qemu sees. You should see something like VLAN 0 devices: tap: ifname=tap0 setup_script=/usr/local/etc/qemu-ifup rtl8139 pci macaddr=52:54:00:d2:56:03 - I no longer remember if qemu-ifup is needed but without it you may need to manually bring up tap0. - tcpdump on tap0 to see if ping packets (sent from the VM) get through. Next tcpdump on bridge0. Next tcpdump on bge0. I'd still like to see the topology and ip addresses on various interfaces. From mgb.fbsd at gmail.com Wed Oct 29 06:46:55 2008 From: mgb.fbsd at gmail.com (Mihail Balikov) Date: Wed Oct 29 06:47:26 2008 Subject: ixgbe vs mxge Message-ID: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> Hi, I would like to setup 10gbit bridge on FreeBSD7 , but I'm little bit confused which vendor to choose for the NICs. Can you send me some feed back? regards, Mihail Balikov From gizmen at blurp.pl Wed Oct 29 08:53:31 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Wed Oct 29 08:53:38 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <490755A3.4050903@FreeBSD.org> References: <1225203780.00029971.1225190402@10.7.7.3> <200810281613.13719.gizmen@blurp.pl> <490755A3.4050903@FreeBSD.org> Message-ID: <200810290953.28237.gizmen@blurp.pl> Tuesday 28 of October 2008 19:10:43 Alexander Motin napisa?(a): > Bartosz Giza wrote: > >> The CPU time you see there includes much more then just a card > >> handling itself. It also includes CPU time of the most parts of > >> network stack used to process received packet. So if you have NAT, big > >> firewall, netgraph or any other CPU-hungry actions done with packets > >> incoming via em0 you will see such results. > >> Even more interesting is that if bge0 or fxp0 cards will require much > >> CPU time to send packet, this time will also be accounted to em0 > >> process. I have checked this and you are right. When i turned off ipfw; taskq process started to use less cpu. But still what is strange why processing from other cards are counted in em0 taskq ? This is quite strange and in that way em0 taskq process is using more cpu on one of the cores. So what i think the best would be to have only em NICs because processing of the packets would be splitted to those taskq processes is that right ? > > WOW that is weird. Yes i have quite big ipfw firewall and also couple > > of rules from pf. So you are saying that whole overhead from firewall > > is counted to this em taskq process. This is really strange for > > somebody who don't know about this. > > So what in case if i would have two em nic's. How would then overhead > > from firewalls be counted ? Splited to two taskq processes ? > > And another really weird thing is that if i have other card their > > processing are counted to tasq process of different NIC. Why is this > > done in such a way ? > > There is no dedicated processes in system to handle routing, firewall, > netgraph, etc. Many processes would lead to multiple context switches, > bigger latencies and reduced performance. Instead most parts of network > stack implemented in direct call fashion. So NIC receive interrupt > initiates packet handling by doing stack function call, that function > calls another and so on until packet will be completely processed and > transmitted or queued. There is not so many exception from this rule, > for example, dummynet which schedules part of activity to the timer > events. So sometimes you still can see some activity from the swi:net, > dummynet or some other threads. It also tells not so much about who > really consumed the CPU, but more about who initiated that CPU > consumption. Ok, good to know. But how is counted firewall overhead when i would have only bge cards. They don't use taskq so i assume i would see this as system usage correct ? > In case of two em NICs em0 thread will mostly show load produced by > em0->em1 traffic processing and em1 - load produced by em1->em0 traffic. From eitans at mellanox.co.il Wed Oct 29 09:34:48 2008 From: eitans at mellanox.co.il (Eitan Shefi) Date: Wed Oct 29 09:34:54 2008 Subject: It seems that FreeBSD-7.0 does not use the available MTU In-Reply-To: <20081028210215.GE51033@funkthat.com> References: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> <20081028210215.GE51033@funkthat.com> Message-ID: <5D49E7A8952DC44FB38C38FA0D758EADD00926@mtlexch01.mtl.com> This is indeed the problem, thanks. Is this a known issue with FreeBSD-7.0 ? I do not want to hide a potential bug in the NIC driver. Eitan Shefi -----Original Message----- From: John-Mark Gurney [mailto:jmg@funkthat.com] Sent: Tuesday, October 28, 2008 11:02 PM To: Eitan Shefi Cc: freebsd-net@freebsd.org Subject: Re: It seems that FreeBSD-7.0 does not use the available MTU Eitan Shefi wrote this message on Mon, Oct 27, 2008 at 23:53 +0200: > I am using 2 hosts with FreeBSD-7.0 connected directly. > When I change the MTU to a value greater then 1500, for example 3000, > and then send "ping" with message size 2500, from one host to the > other, the other host gets more then one ICMP packet, even thaw the > message that was send is match smaller then the MTU. > > I tried to run this test using a different NIC, but I got the same > behavior. > > I run: > 1. On both hosts: > ifconfig mtnic0 mtu 3000 > 2. Than on one host I run: > tcpdump -i mtnic0 icmp > 3. And on the other host I run: > ping -s 2500 -c 1 OTHER_HOST_IP (ping to "mtnic0" on the other > host) run netstat -rnW to see what the route's MTU is. Most likely you need to set the mtu before you configure an ip address on the interface so that the network's route is created w/ the correct MTU... either readd the network route, or change the mtu of the route for the host: route change -mtu 3000 OTHER_HOST_IP also change it on the network route so that when the host route gets flushed and recreated it will be created w/ the correct MTU... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From mav at FreeBSD.org Wed Oct 29 10:36:47 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 29 10:36:54 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <200810290953.28237.gizmen@blurp.pl> References: <1225203780.00029971.1225190402@10.7.7.3> <200810281613.13719.gizmen@blurp.pl> <490755A3.4050903@FreeBSD.org> <200810290953.28237.gizmen@blurp.pl> Message-ID: <49083CBD.1000701@FreeBSD.org> Bartosz Giza wrote: > Tuesday 28 of October 2008 19:10:43 Alexander Motin napisa?(a): >> Bartosz Giza wrote: >>>> The CPU time you see there includes much more then just a card >>>> handling itself. It also includes CPU time of the most parts of >>>> network stack used to process received packet. So if you have NAT, big >>>> firewall, netgraph or any other CPU-hungry actions done with packets >>>> incoming via em0 you will see such results. >>>> Even more interesting is that if bge0 or fxp0 cards will require much >>>> CPU time to send packet, this time will also be accounted to em0 >>>> process. > > I have checked this and you are right. When i turned off ipfw; taskq process > started to use less cpu. But still what is strange why processing from > other cards are counted in em0 taskq ? What you mean by "processing from other cards"? em0 taskq counts all processing caused by packets incoming via em0 up to and including processing of their transmission by bge/fxp drivers. Same is about bge/fxp. If bge/fxp/em drivers would have separate transmission processes - you would see them, but they don't, so their CPU time accounted to the caller. > This is quite strange and in that > way em0 taskq process is using more cpu on one of the cores. So what i > think the best would be to have only em NICs because processing of the > packets would be splitted to those taskq processes is that right ? em0 processes packets in separate process named taskq, bge does it directly in interrupt handler process. There is no principal difference for you I think. > Ok, good to know. But how is counted firewall overhead when i would have > only bge cards. They don't use taskq so i assume i would see this as system > usage correct ? You would see a lot of interrupt time in this case. -- Alexander Motin From gizmen at blurp.pl Wed Oct 29 12:37:49 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Wed Oct 29 12:37:56 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <49083CBD.1000701@FreeBSD.org> References: <1225203780.00029971.1225190402@10.7.7.3> <200810290953.28237.gizmen@blurp.pl> <49083CBD.1000701@FreeBSD.org> Message-ID: <200810291337.44899.gizmen@blurp.pl> Wednesday 29 of October 2008 11:36:45 Alexander Motin napisa?(a): > Bartosz Giza wrote: > > Tuesday 28 of October 2008 19:10:43 Alexander Motin napisa?(a): > >> Bartosz Giza wrote: > >>>> The CPU time you see there includes much more then just a card > >>>> handling itself. It also includes CPU time of the most parts of > >>>> network stack used to process received packet. So if you have NAT, > >>>> big firewall, netgraph or any other CPU-hungry actions done with > >>>> packets incoming via em0 you will see such results. > >>>> Even more interesting is that if bge0 or fxp0 cards will require > >>>> much CPU time to send packet, this time will also be accounted to > >>>> em0 process. > > > > I have checked this and you are right. When i turned off ipfw; taskq > > process started to use less cpu. But still what is strange why > > processing from other cards are counted in em0 taskq ? > > What you mean by "processing from other cards"? em0 taskq counts all > processing caused by packets incoming via em0 up to and including > processing of their transmission by bge/fxp drivers. Same is about > bge/fxp. If bge/fxp/em drivers would have separate transmission > processes - you would see them, but they don't, so their CPU time > accounted to the caller. Ok now i think understand this. If packet enters via em0 all processing of packet filters(and others) way up to sending packet via other interface is counted to em0 taskq( even overhead of packet filter when packet leaves the interface) ? Basicly overhead from passing packet to packet filter twice (on in and out) > > This is quite strange and in that > > way em0 taskq process is using more cpu on one of the cores. So what i > > think the best would be to have only em NICs because processing of the > > packets would be splitted to those taskq processes is that right ? > > em0 processes packets in separate process named taskq, bge does it > directly in interrupt handler process. There is no principal difference > for you I think. So now i am lost again. If packet filtering on bge card is counted to irq17: bge0 process so i think it should use more cpu. From what you wrote there should be no difference for me if card use tasq or irq. Those processes do exactly the same thing? If that is true so why there is so much difference in cpu usage: 20 root 1 -68 - 0K 8K - 0 161:01 18.75% em0 taskq 21 root 1 -68 - 0K 8K WAIT 1 100:10 5.47% irq17: bge0 23 root 1 -68 - 0K 8K WAIT 0 75:31 2.98% irq16: fxp1 If what you wrote is true that overhead of incomming packet on bge0 should be counted to irq17: bge0 So don't understand why there is so big cpu usage on em0. From what you are saying irq17 and em0 taskq should have similar usage. Even more bge0 passes about two times more traffic than em0. I simply don't understand this. > > Ok, good to know. But how is counted firewall overhead when i would > > have only bge cards. They don't use taskq so i assume i would see this > > as system usage correct ? > > You would see a lot of interrupt time in this case. From mav at FreeBSD.org Wed Oct 29 13:34:08 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 29 14:23:23 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <200810291337.44899.gizmen@blurp.pl> References: <1225203780.00029971.1225190402@10.7.7.3> <200810290953.28237.gizmen@blurp.pl> <49083CBD.1000701@FreeBSD.org> <200810291337.44899.gizmen@blurp.pl> Message-ID: <4908664D.4090900@FreeBSD.org> Bartosz Giza wrote: > So now i am lost again. If packet filtering on bge card is counted to irq17: > bge0 process so i think it should use more cpu. > From what you wrote there should be no difference for me if card use tasq > or irq. Those processes do exactly the same thing? If that is true so why > there is so much difference in cpu usage: > > 20 root 1 -68 - 0K 8K - 0 161:01 18.75% em0 taskq > 21 root 1 -68 - 0K 8K WAIT 1 100:10 5.47% irq17: bge0 > 23 root 1 -68 - 0K 8K WAIT 0 75:31 2.98% irq16: fxp1 > > If what you wrote is true that overhead of incomming packet on bge0 should > be counted to irq17: bge0 > So don't understand why there is so big cpu usage on em0. From what you are > saying irq17 and em0 taskq should have similar usage. Even more bge0 passes > about two times more traffic than em0. I simply don't understand this. > So don't understand why there is so big cpu usage on em0. Have no idea, there are too much possibilities to answer without profiling. Different incoming packet rates, different firewall match patterns in opposite directions, different card's hardware at least. I have noticed that even different types of em cards may have twice as different CPU usage due to using different interrupt moderation techniques. > bge0 passes about two times more traffic than em0 Incoming or outgoing? Outgoing does not affect time accounting as much as incoming, because transmit interrupt handler usually does not call network stack. -- Alexander Motin From linimon at FreeBSD.org Wed Oct 29 16:03:41 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Oct 29 16:03:52 2008 Subject: kern/128448: [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be resolved (mount_nfs) Message-ID: <200810291603.m9TG3fLu018902@freefall.freebsd.org> Old Synopsis: 6.4-RC1 Boot Fails if NFS Hostname cannot be resolved (mount_nfs) New Synopsis: [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be resolved (mount_nfs) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 29 16:01:47 UTC 2008 Responsible-Changed-Why: This is really more of an NFS problem I think, but perhaps the folks on -net can weigh in here. http://www.freebsd.org/cgi/query-pr.cgi?pr=128448 From jmg at funkthat.com Wed Oct 29 17:39:09 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Wed Oct 29 17:39:15 2008 Subject: It seems that FreeBSD-7.0 does not use the available MTU In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EADD00926@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EADC72E72@mtlexch01.mtl.com> <5D49E7A8952DC44FB38C38FA0D758EADCC5FB7@mtlexch01.mtl.com> <20081028210215.GE51033@funkthat.com> <5D49E7A8952DC44FB38C38FA0D758EADD00926@mtlexch01.mtl.com> Message-ID: <20081029173907.GG51033@funkthat.com> Eitan Shefi wrote this message on Wed, Oct 29, 2008 at 11:34 +0200: > This is indeed the problem, thanks. > > Is this a known issue with FreeBSD-7.0 ? > I do not want to hide a potential bug in the NIC driver. This is a known issue since I fixed the transmit code not to munge the route's MTU so that the route's mtu field would have meaning and allow you to have hosts w/ different MTU's on the network (I've done this in production)... This is definately not a bug in the NIC driver... > -----Original Message----- > From: John-Mark Gurney [mailto:jmg@funkthat.com] > Sent: Tuesday, October 28, 2008 11:02 PM > To: Eitan Shefi > Cc: freebsd-net@freebsd.org > Subject: Re: It seems that FreeBSD-7.0 does not use the available MTU > > Eitan Shefi wrote this message on Mon, Oct 27, 2008 at 23:53 +0200: > > I am using 2 hosts with FreeBSD-7.0 connected directly. > > When I change the MTU to a value greater then 1500, for example 3000, > > and then send "ping" with message size 2500, from one host to the > > other, the other host gets more then one ICMP packet, even thaw the > > message that was send is match smaller then the MTU. > > > > I tried to run this test using a different NIC, but I got the same > > behavior. > > > > I run: > > 1. On both hosts: > > ifconfig mtnic0 mtu 3000 > > 2. Than on one host I run: > > tcpdump -i mtnic0 icmp > > 3. And on the other host I run: > > ping -s 2500 -c 1 OTHER_HOST_IP (ping to "mtnic0" on the other > > host) > > run netstat -rnW to see what the route's MTU is. Most likely you need > to set the mtu before you configure an ip address on the interface so > that the network's route is created w/ the correct MTU... > > either readd the network route, or change the mtu of the route for the > host: > route change -mtu 3000 OTHER_HOST_IP > > also change it on the network route so that when the host route gets > flushed and recreated it will be created w/ the correct MTU... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From freebsd at hub.org Wed Oct 29 23:56:28 2008 From: freebsd at hub.org (Marc G. Fournier) Date: Wed Oct 29 23:56:36 2008 Subject: Problem with Bridging ... and bge devices under FreeBSD 7.x? Message-ID: <10559F9E70D606BEE694D258@ganymede.hub.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You nailed it ... I was missing the 'tap.up_on_open=1' ... once I put that in place, it works like a charm ... Thanks ... - --On Tuesday, October 28, 2008 22:37:58 -0700 Bakul Shah wrote: > On Wed, 29 Oct 2008 01:38:38 -0300 "Marc G. Fournier" > wrote: >> >> I only have one VM running on one server ... > > Ok. > > Here are some debugging suggestions. > - /etc/sysctl.conf should have the following; > net.link.tap.user_open=1 > net.link.tap.up_on_open=1 > run sysctl manually to set these. > > - if you are running qemu as user foo (and not root) you will need > own tap0 foo:foo > in /etc/devfs.conf and do /etc/rc.d/devfs restart. > > - start qemu with -monitor stdio as this will give you a > command line interface to qemu. Now you can type > info network > to see what qemu sees. You should see something like > VLAN 0 devices: > tap: ifname=tap0 setup_script=/usr/local/etc/qemu-ifup > rtl8139 pci macaddr=52:54:00:d2:56:03 > > - I no longer remember if qemu-ifup is needed but without it > you may need to manually bring up tap0. > > - tcpdump on tap0 to see if ping packets (sent from the VM) > get through. Next tcpdump on bridge0. Next tcpdump on bge0. > > I'd still like to see the topology and ip addresses on > various interfaces. - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkI+CYACgkQ4QvfyHIvDvNuawCfQbUzADaZHkqvVRt9fwZ7H1Gm MGIAoJCUFsfUoCh2ty41nmjDGsSq0ec4 =n/85 -----END PGP SIGNATURE----- From freebsd-net at dino.sk Thu Oct 30 08:39:49 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Thu Oct 30 08:39:56 2008 Subject: re weird bug Message-ID: <200810300829.35980.freebsd-net@dino.sk> Hi, yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) and tried to build new kernel. There is again a problem with re interface. It just does not work, with following re0: port 0xc000-0xc0ff mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 re0: Chip rev. 0x34800000 re0: MAC rev. 0x00200000 re0: PHY write failed re0: PHY write failed re0: MII without any phy! device_attach: re0 attach returned 6 in dmesg. This happened already some time ago, but I did not investigate it, just reverted to older kernel and later it disappeared. Today I found there is some timing issue or racing condition - when I boot with verbose message logging, it works with expected re0: port 0xc000-0xc0ff mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 re0: MSI count : 1 re0: Chip rev. 0x34800000 re0: MAC rev. 0x00200000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:1d:92:59:f5:8b re0: [MPSAFE] re0: [FILTER] So I think some issue could be in miibus or rlphy code. I am using stripped down kernel with no interfaces, I kldload if_re (and miibus as dependency), if that matters. Has anybody an idea or patch to test? Something similar appeared recently on list, but I would like to get issue commented first (maybe with a pointer to patch). Regards, Milan From pyunyh at gmail.com Thu Oct 30 10:29:01 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 30 10:29:08 2008 Subject: re weird bug In-Reply-To: <200810300829.35980.freebsd-net@dino.sk> References: <200810300829.35980.freebsd-net@dino.sk> Message-ID: <20081030102656.GD78796@cdnetworks.co.kr> On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > Hi, > yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) and > tried to build new kernel. There is again a problem with re interface. It > just does not work, with following > > re0: port 0xc000-0xc0ff mem > 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 > re0: Chip rev. 0x34800000 > re0: MAC rev. 0x00200000 > re0: PHY write failed > re0: PHY write failed > re0: MII without any phy! > device_attach: re0 attach returned 6 > > in dmesg. This happened already some time ago, but I did not investigate it, > just reverted to older kernel and later it disappeared. Today I found there > is some timing issue or racing condition - when I boot with verbose message > logging, it works with expected > > re0: port 0xc000-0xc0ff mem > 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 > re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > re0: MSI count : 1 > re0: Chip rev. 0x34800000 > re0: MAC rev. 0x00200000 > miibus0: on re0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: bpf attached > re0: Ethernet address: 00:1d:92:59:f5:8b > re0: [MPSAFE] > re0: [FILTER] > > So I think some issue could be in miibus or rlphy code. > I am using stripped down kernel with no interfaces, I kldload if_re (and > miibus as dependency), if that matters. > Has anybody an idea or patch to test? Something similar appeared recently on > list, but I would like to get issue commented first (maybe with a pointer to > patch). > That's known issue for newer RealTek PCIe controllers. Would you please try the patch at the following URL? http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 Since it's not easy to reproduce this issue please make sure to (cold and warm) reboot several times until you can put confidence in the patch. -- Regards, Pyun YongHyeon From gizmen at blurp.pl Thu Oct 30 12:51:23 2008 From: gizmen at blurp.pl (Bartosz Giza) Date: Thu Oct 30 12:51:30 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <4908664D.4090900@FreeBSD.org> References: <1225203780.00029971.1225190402@10.7.7.3> <200810291337.44899.gizmen@blurp.pl> <4908664D.4090900@FreeBSD.org> Message-ID: <200810301351.20288.gizmen@blurp.pl> Wednesday 29 of October 2008 14:34:05 Alexander Motin napisa?(a): > Bartosz Giza wrote: > > So now i am lost again. If packet filtering on bge card is counted to > > irq17: bge0 process so i think it should use more cpu. > > From what you wrote there should be no difference for me if card use > > tasq or irq. Those processes do exactly the same thing? If that is true > > so why there is so much difference in cpu usage: > > > > 20 root 1 -68 - 0K 8K - 0 161:01 18.75% em0 > > taskq 21 root 1 -68 - 0K 8K WAIT 1 100:10 5.47% > > irq17: bge0 23 root 1 -68 - 0K 8K WAIT 0 75:31 > > 2.98% irq16: fxp1 > > > > If what you wrote is true that overhead of incomming packet on bge0 > > should be counted to irq17: bge0 > > So don't understand why there is so big cpu usage on em0. From what you > > are saying irq17 and em0 taskq should have similar usage. Even more > > bge0 passes about two times more traffic than em0. I simply don't > > understand this. > > > > So don't understand why there is so big cpu usage on em0. > > Have no idea, there are too much possibilities to answer without > profiling. Different incoming packet rates, different firewall match > patterns in opposite directions, different card's hardware at least. I > have noticed that even different types of em cards may have twice as > different CPU usage due to using different interrupt moderation > techniques. THanks for all hints that you gave me. I have found what cause this high cpu usage.... ipfw :) I have a lot of rules in ipfw and actually i have tune them up and after that em0 taskq process sterted to use less cpu(similar to bge0). It was bad firewall design Could you tell me which chipset from intel would you recommend or you know that is best from all that you tested. Once again thanks for answers :) From mav at FreeBSD.org Thu Oct 30 13:58:40 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 30 13:58:46 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: <200810301351.20288.gizmen@blurp.pl> References: <1225203780.00029971.1225190402@10.7.7.3> <200810291337.44899.gizmen@blurp.pl> <4908664D.4090900@FreeBSD.org> <200810301351.20288.gizmen@blurp.pl> Message-ID: <4909BD8E.8080402@FreeBSD.org> Bartosz Giza wrote: > Could you tell me which chipset from intel would you recommend or you know > that is best from all that you tested. I haven't investigated that specially to recommend something as most of my cards are integrated, but now I have newer systems with: em0@pci13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint and older systems with: em0@pci2:10:0: class=0x020000 card=0x12138086 chip=0x10138086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction I can't compare load directly now as load is different, but I have noticed benefits after replacing old systems with new ones. General recommendation is usual: newer is usually better. :) -- Alexander Motin From olli at lurza.secnetix.de Thu Oct 30 12:21:17 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Oct 30 12:21:23 2008 Subject: LevelOne WPC-0301 11g Wireless CardBus Message-ID: <200810301921.m9UJLEZC098455@lurza.secnetix.de> Hello, I bought a LevelOne WPC-0301 11g Wireless CardBus Adapter today. According to the box it is "v6". The ral(4) man- page mentions only v2, but that one is ancient and can't be bought anymore. So, enabling the debug sysctl gives this in dmesg: cardbus0: Expecting link target, got 0x0 cardbus0: at device 0.0 (no driver attached) cardbus0: CIS pointer is 0x102 cardbus0: CIS in BAR 0x14 cardbus0: Expecting link target, got 0x0 cardbus0: Warning: Bogus CIS ignored cardbus0: at device 0.0 (no driver attached) I tried the card in a different notebook, same thing. Anything I can do, except drop the new card in the dustbin? :-( Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead. From freebsd-net at dino.sk Thu Oct 30 14:41:52 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Thu Oct 30 14:41:58 2008 Subject: re weird bug In-Reply-To: <20081030102656.GD78796@cdnetworks.co.kr> References: <200810300829.35980.freebsd-net@dino.sk> <20081030102656.GD78796@cdnetworks.co.kr> Message-ID: <200810302241.01863.freebsd-net@dino.sk> On Thursday 30 October 2008 11:26:56 Pyun YongHyeon wrote: > On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > > Hi, > > yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) > > and tried to build new kernel. There is again a problem with re > > interface. It just does not work, with following > > > > re0: port 0xc000-0xc0ff > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > pci1 re0: Chip rev. 0x34800000 > > re0: MAC rev. 0x00200000 > > re0: PHY write failed > > re0: PHY write failed > > re0: MII without any phy! > > device_attach: re0 attach returned 6 > > > > in dmesg. This happened already some time ago, but I did not investigate > > it, just reverted to older kernel and later it disappeared. Today I > > found there is some timing issue or racing condition - when I boot with > > verbose message logging, it works with expected > > > > re0: port 0xc000-0xc0ff > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > > re0: MSI count : 1 > > re0: Chip rev. 0x34800000 > > re0: MAC rev. 0x00200000 > > miibus0: on re0 > > rlphy0: PHY 1 on miibus0 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re0: bpf attached > > re0: Ethernet address: 00:1d:92:59:f5:8b > > re0: [MPSAFE] > > re0: [FILTER] > > > > So I think some issue could be in miibus or rlphy code. > > I am using stripped down kernel with no interfaces, I kldload if_re (and > > miibus as dependency), if that matters. > > Has anybody an idea or patch to test? Something similar appeared > > recently on list, but I would like to get issue commented first (maybe > > with a pointer to patch). > > That's known issue for newer RealTek PCIe controllers. Would you > please try the patch at the following URL? > http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 > > Since it's not easy to reproduce this issue please make sure to > (cold and warm) reboot several times until you can put confidence > in the patch. I tried, but no change - with patch applied re still does not work unless I boot with verbose logging, no matter whether I boot cold or warm. Regards, Milan From pyunyh at gmail.com Thu Oct 30 18:13:28 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 30 18:13:35 2008 Subject: re weird bug In-Reply-To: <200810302241.01863.freebsd-net@dino.sk> References: <200810300829.35980.freebsd-net@dino.sk> <20081030102656.GD78796@cdnetworks.co.kr> <200810302241.01863.freebsd-net@dino.sk> Message-ID: <20081031011125.GC82781@cdnetworks.co.kr> On Thu, Oct 30, 2008 at 10:41:01PM +0100, Milan Obuch wrote: > On Thursday 30 October 2008 11:26:56 Pyun YongHyeon wrote: > > On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > > > Hi, > > > yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) > > > and tried to build new kernel. There is again a problem with re > > > interface. It just does not work, with following > > > > > > re0: port 0xc000-0xc0ff > > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > > pci1 re0: Chip rev. 0x34800000 > > > re0: MAC rev. 0x00200000 > > > re0: PHY write failed > > > re0: PHY write failed > > > re0: MII without any phy! > > > device_attach: re0 attach returned 6 > > > > > > in dmesg. This happened already some time ago, but I did not investigate > > > it, just reverted to older kernel and later it disappeared. Today I > > > found there is some timing issue or racing condition - when I boot with > > > verbose message logging, it works with expected > > > > > > re0: port 0xc000-0xc0ff > > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > > > re0: MSI count : 1 > > > re0: Chip rev. 0x34800000 > > > re0: MAC rev. 0x00200000 > > > miibus0: on re0 > > > rlphy0: PHY 1 on miibus0 > > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > re0: bpf attached > > > re0: Ethernet address: 00:1d:92:59:f5:8b > > > re0: [MPSAFE] > > > re0: [FILTER] > > > > > > So I think some issue could be in miibus or rlphy code. > > > I am using stripped down kernel with no interfaces, I kldload if_re (and > > > miibus as dependency), if that matters. > > > Has anybody an idea or patch to test? Something similar appeared > > > recently on list, but I would like to get issue commented first (maybe > > > with a pointer to patch). > > > > That's known issue for newer RealTek PCIe controllers. Would you > > please try the patch at the following URL? > > http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 > > > > Since it's not easy to reproduce this issue please make sure to > > (cold and warm) reboot several times until you can put confidence > > in the patch. > > I tried, but no change - with patch applied re still does not work unless I > boot with verbose logging, no matter whether I boot cold or warm. > Thanks for testing. If you look into patched if_re.c you can see a "#if 1" in function re_ephy_config(). How about changing it to "#if 0" to enable more aggresive reprogramming for EPHY register? -- Regards, Pyun YongHyeon From rmaglasang at infoweapons.com Thu Oct 30 20:22:22 2008 From: rmaglasang at infoweapons.com (Ronnel P. Maglasang) Date: Thu Oct 30 20:22:28 2008 Subject: rate limiting icmp behavior Message-ID: <490A7593.9010209@infoweapons.com> Hi All, Pardon if this has been posted. What is really the behavior of the system when it rate limit icmp (e.g. ICMP response)? Does it drop the excess of the outbound ICMP responses? If so, is their a way to see dropped responses from logs or other mechanism? Can this be turned-on at the inbound? Rate limit incoming ICMP request? Did someone experienced system reboots/hangup from this? I've search gnats but I coudn't find bugs related to this. Thanks, sho From bruce at cran.org.uk Thu Oct 30 20:32:05 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Oct 30 20:32:11 2008 Subject: two NIC on 2 core system (scheduling problem) In-Reply-To: References: <200810281235.53508.gizmen@blurp.pl> <4906EC8D.7070503@freebsd.org> <4906EE31.3080400@samoylyk.sumy.ua> Message-ID: <20081031041350.4e25edc7@tau.draftnet> On Tue, 28 Oct 2008 12:21:32 +0100 Ivan Voras wrote: > Oleksandr Samoylyk wrote: > > Ivan Voras wrote: > >> Bartosz Giza wrote: > >> > >>> Another question is why em0 taskq is eating so much cpu ? BGE > >>> interface is actually one that pushes 2 times more packets than > >>> em0 and it uses about half cpu comparing to em0. Is that not > >>> strange ? Could someone tell my why is this happening ? BGE is > >>> faster ? or maybe i can tune some > >> > >> I have the same problem - em0 taskq eating incredible amounts of > >> CPU. If you find a solution, contact me! > >> > >> > > > > It could be not just a problem with em driver. > > Firstly, it's good to make profiling and find out what exactly eats > > CPU > > Can you give any pointers on how to profile the driver and/or the > network stack? > From what I remember from a couple of years ago you can use hwpmc in system mode to profile the kernel if you have a supported CPU - I certainly remember seeing the output of gprof tell me the UDP checksum function was taking most of the time in a test I ran. To get started you need options HWPMC_HOOKS and device hwpmc in your kernel config (hwpmc can also be a module) - then you run pmcstat to run the test. There's lots more information at http://wiki.freebsd.org/PmcTools -- Bruce Cran From freebsd-net at dino.sk Fri Oct 31 02:30:49 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Fri Oct 31 02:30:57 2008 Subject: re weird bug In-Reply-To: <20081031011125.GC82781@cdnetworks.co.kr> References: <200810300829.35980.freebsd-net@dino.sk> <200810302241.01863.freebsd-net@dino.sk> <20081031011125.GC82781@cdnetworks.co.kr> Message-ID: <200810311029.56471.freebsd-net@dino.sk> On Friday 31 October 2008 02:11:25 Pyun YongHyeon wrote: > On Thu, Oct 30, 2008 at 10:41:01PM +0100, Milan Obuch wrote: > > On Thursday 30 October 2008 11:26:56 Pyun YongHyeon wrote: > > > On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > > > > Hi, > > > > yesterday I csup'ped my 8-current sources on my MSI Wind netbook > > > > (again) and tried to build new kernel. There is again a problem > > > > with re interface. It just does not work, with following > > > > > > > > re0: port > > > > 0xc000-0xc0ff mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq > > > > 16 at device 0.0 on pci1 re0: Chip rev. 0x34800000 > > > > re0: MAC rev. 0x00200000 > > > > re0: PHY write failed > > > > re0: PHY write failed > > > > re0: MII without any phy! > > > > device_attach: re0 attach returned 6 > > > > [ snip ] > > > > > > That's known issue for newer RealTek PCIe controllers. Would you > > > please try the patch at the following URL? > > > http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 > > > > > > Since it's not easy to reproduce this issue please make sure to > > > (cold and warm) reboot several times until you can put confidence > > > in the patch. > > > > I tried, but no change - with patch applied re still does not work > > unless I boot with verbose logging, no matter whether I boot cold or > > warm. > > Thanks for testing. If you look into patched if_re.c you can see a > "#if 1" in function re_ephy_config(). How about changing it to > "#if 0" to enable more aggresive reprogramming for EPHY register? I tried. Again, no change - rlphy not working normally, but everything works when booting with verbose logging. If there is anything else I could test, let me know. Booting with verbose logging is acceptable for me for now, so do not feel any pressure from my side. I just like to test when something will be available for test. Regards, Milan From rwatson at FreeBSD.org Fri Oct 31 05:54:38 2008 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Fri Oct 31 05:54:44 2008 Subject: kern/122082: [in_pcb] NULL pointer dereference in in_pcbdrop Message-ID: <200810311254.m9VCsbPq064275@freefall.freebsd.org> Synopsis: [in_pcb] NULL pointer dereference in in_pcbdrop State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Fri Oct 31 12:52:03 UTC 2008 State-Changed-Why: Could I ask you to confirm whether this still occurs with the most recent 7-STABLE? If so, could I then ask you to print *tw and *inp in the tcp_twclose frame, which might shed a bit more light on things. Thanks! Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: rwatson Responsible-Changed-When: Fri Oct 31 12:52:03 UTC 2008 Responsible-Changed-Why: Could I ask you to confirm whether this still occurs with the most recent 7-STABLE? If so, could I then ask you to print *tw and *inp in the tcp_twclose frame, which might shed a bit more light on things. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=122082 From kirma at cs.hut.fi Fri Oct 31 06:34:11 2008 From: kirma at cs.hut.fi (Jari Kirma) Date: Fri Oct 31 06:34:18 2008 Subject: kern/122082: [in_pcb] NULL pointer dereference in in_pcbdrop In-Reply-To: <200810311254.m9VCsbPq064275@freefall.freebsd.org> References: <200810311254.m9VCsbPq064275@freefall.freebsd.org> Message-ID: On Fri, 31 Oct 2008, rwatson@FreeBSD.org wrote: > Synopsis: [in_pcb] NULL pointer dereference in in_pcbdrop > > State-Changed-From-To: open->feedback > State-Changed-By: rwatson > State-Changed-When: Fri Oct 31 12:52:03 UTC 2008 > State-Changed-Why: > Could I ask you to confirm whether this still occurs with the most recent > 7-STABLE? If so, could I then ask you to print *tw and *inp in the > tcp_twclose frame, which might shed a bit more light on things. > > Thanks! Unfortunately I don't have this kind of spare machine to risk crashing, although I try to look at it again. Still, if I remember correctly, the system was agitated to crash very often (like over 25% of time after bootup in some 15 first minutes): linux-opera (or even linux-firefox) being used actively on a quad-core machine running relatively regular xfce desktop. When the system survived first fifteen minutes or so, it seemed to get less and less likely it would crash similarly, although it could have happened weeks after that with very similar signs: crashing a moment after browsing around, as if remote teardown of a persistent HTTP TCP socket from the remote end would trigger it. I think the Linux emulation part in this context is somehow significant. When I moved to native Firefox instead, at least similar crashes ceased to occur. Might there be some locks not being held on Linux call path in comparison to native versions? > Responsible-Changed-From-To: freebsd-net->rwatson > Responsible-Changed-By: rwatson > Responsible-Changed-When: Fri Oct 31 12:52:03 UTC 2008 > Responsible-Changed-Why: > Could I ask you to confirm whether this still occurs with the most recent > 7-STABLE? If so, could I then ask you to print *tw and *inp in the > tcp_twclose frame, which might shed a bit more light on things. > > Thanks! > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=122082 > From jay at jcornwall.me.uk Fri Oct 31 10:40:39 2008 From: jay at jcornwall.me.uk (Jay L. T. Cornwall) Date: Fri Oct 31 10:40:46 2008 Subject: gif(4) periodically fails to route packets Message-ID: <490B3F05.1030106@jcornwall.me.uk> Hi, I'm running FreeBSD 7.0-RELEASE with an IPv6 tunnel through gif(4): gif0: flags=8151 metric 0 mtu 1280 tunnel inet 82.70.152.20 --> 77.75.104.126 inet6 fe80::20d:b9ff:fe14:1d18%gif0 prefixlen 64 scopeid 0x6 inet6 2a01:348:6:13a::2 --> 2a01:348:6:13a::1 prefixlen 128 The tunnel works correctly for much of the time. Periodically, however, it appears to stop routing inbound packets (outbound remains fine) for hours at a time before beginning to work again with no intervention. I initially suspected a problem with the tunnel endpoint but I now have a packet capture providing evidence to the contrary. For a ping6 to an IP routed through the tunnel these are the packets passing over the external (IPv4) interface: 17:10:51.640317 IP 82.70.152.20 > 77.75.104.126: IP6 2a01:348:6:13a::2 > 2001:4860:0:1001::68: ICMP6, echo request, seq 0, length 16 17:10:51.691653 IP 77.75.104.126 > 82.70.152.20: IP6 2001:4860:0:1001::68 > 2a01:348:6:13a::2: ICMP6, echo reply, seq 0, length 16 17:10:52.640631 IP 82.70.152.20 > 77.75.104.126: IP6 2a01:348:6:13a::2 > 2001:4860:0:1001::68: ICMP6, echo request, seq 1, length 16 17:10:52.683821 IP 77.75.104.126 > 82.70.152.20: IP6 2001:4860:0:1001::68 > 2a01:348:6:13a::2: ICMP6, echo reply, seq 1, length 16 Looks correct. Now the same packet capture on the gif0 interface: 17:10:51.640267 IP6 2a01:348:6:13a::2 > 2001:4860:0:1001::68: ICMP6, echo request, seq 0, length 16 17:10:52.640587 IP6 2a01:348:6:13a::2 > 2001:4860:0:1001::68: ICMP6, echo request, seq 1, length 16 It appears, for reasons beyond my understanding, that the tunnel is not aware of the return packets. No firewall is enabled that could be filtering the missing packets. Shortly after the ping6 is sent my endpoint appears to be trying to find the remote endpoint: 17:10:56.639517 IP6 2a01:348:6:13a::2 > 2a01:348:6:13a::1: ICMP6, neighbor solicitation, who has 2a01:348:6:13a::1, length 24 17:10:57.639513 IP6 2a01:348:6:13a::2 > 2a01:348:6:13a::1: ICMP6, neighbor solicitation, who has 2a01:348:6:13a::1, length 24 17:10:58.639499 IP6 2a01:348:6:13a::2 > 2a01:348:6:13a::1: ICMP6, neighbor solicitation, who has 2a01:348:6:13a::1, length 24 But I am not sure if this is related as it successfully sends the ping6 outbound regardless. radvd is running on the host if that makes a difference. To my knowledge its routing table is correct: default 2a01:348:6:13a::1 UGS gif0 2a01:348:6:13a::1 link#6 UHL gif0 2a01:348:6:13a::2 link#6 UHL lo0 Am I missing something? -- Jay L. T. Cornwall http://www.jcornwall.me.uk/