From owner-freebsd-net@FreeBSD.ORG Sun Dec 19 10:40:11 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D197106566B for ; Sun, 19 Dec 2010 10:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0518FC16 for ; Sun, 19 Dec 2010 10:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJAeAoq011083 for ; Sun, 19 Dec 2010 10:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJAeAYC011082; Sun, 19 Dec 2010 10:40:10 GMT (envelope-from gnats) Date: Sun, 19 Dec 2010 10:40:10 GMT Message-Id: <201012191040.oBJAeAYC011082@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/138427: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 10:40:11 -0000 The following reply was made to PR kern/138427; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138427: commit references a PR Date: Sun, 19 Dec 2010 10:36:11 +0000 (UTC) Author: bschmidt Date: Sun Dec 19 10:36:06 2010 New Revision: 216557 URL: http://svn.freebsd.org/changeset/base/216557 Log: Fix panic trying to use monitor mode. The iwn_cmd() calls issued by iwn_config() want to msleep() on the mutex. PR: kern/138427 Submitted by: Henry Hu MFC after: 3 days Modified: head/sys/dev/wpi/if_wpi.c Modified: head/sys/dev/wpi/if_wpi.c ============================================================================== --- head/sys/dev/wpi/if_wpi.c Sun Dec 19 09:18:14 2010 (r216556) +++ head/sys/dev/wpi/if_wpi.c Sun Dec 19 10:36:06 2010 (r216557) @@ -3561,7 +3561,9 @@ wpi_set_channel(struct ieee80211com *ic) * are already taken care of by their respective firmware commands. */ if (ic->ic_opmode == IEEE80211_M_MONITOR) { + WPI_LOCK(sc); error = wpi_config(sc); + WPI_UNLOCK(sc); if (error != 0) device_printf(sc->sc_dev, "error %d settting channel\n", error); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Dec 19 10:41:12 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D4E1065672; Sun, 19 Dec 2010 10:41:12 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4BBC78FC13; Sun, 19 Dec 2010 10:41:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJAfCeq019456; Sun, 19 Dec 2010 10:41:12 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJAfCMn019436; Sun, 19 Dec 2010 10:41:12 GMT (envelope-from bschmidt) Date: Sun, 19 Dec 2010 10:41:12 GMT Message-Id: <201012191041.oBJAfCMn019436@freefall.freebsd.org> To: gautham@lisphacker.org, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/143595: [wpi] [panic] Creating virtual interface over wpi0 in monitor mode causes crash X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 10:41:12 -0000 Synopsis: [wpi] [panic] Creating virtual interface over wpi0 in monitor mode causes crash State-Changed-From-To: open->feedback State-Changed-By: bschmidt State-Changed-When: Sun Dec 19 10:39:37 UTC 2010 State-Changed-Why: Can you verify that the patch from kern/138427 fixes the issue? Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Sun Dec 19 10:39:37 UTC 2010 Responsible-Changed-Why: Over to me. http://www.freebsd.org/cgi/query-pr.cgi?pr=143595 From owner-freebsd-net@FreeBSD.ORG Sun Dec 19 10:42:15 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFE361065695; Sun, 19 Dec 2010 10:42:15 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A50398FC19; Sun, 19 Dec 2010 10:42:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJAgFDs020229; Sun, 19 Dec 2010 10:42:15 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJAgFMu020225; Sun, 19 Dec 2010 10:42:15 GMT (envelope-from bschmidt) Date: Sun, 19 Dec 2010 10:42:15 GMT Message-Id: <201012191042.oBJAgFMu020225@freefall.freebsd.org> To: marcin.nowak@simplusnet.pl, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set monitor wlanmode on Intel 3945 ABG (wpi driver) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 10:42:15 -0000 Synopsis: [wpi] [panic] Kernel panic after trying set monitor wlanmode on Intel 3945 ABG (wpi driver) State-Changed-From-To: open->closed State-Changed-By: bschmidt State-Changed-When: Sun Dec 19 10:41:31 UTC 2010 State-Changed-Why: Patch confirmed and comitted, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=138427 From owner-freebsd-net@FreeBSD.ORG Sun Dec 19 11:00:27 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E8E106566C for ; Sun, 19 Dec 2010 11:00:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 41FCF8FC08 for ; Sun, 19 Dec 2010 11:00:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJB0QQo032667 for ; Sun, 19 Dec 2010 11:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJB0QgV032641; Sun, 19 Dec 2010 11:00:26 GMT (envelope-from gnats) Date: Sun, 19 Dec 2010 11:00:26 GMT Message-Id: <201012191100.oBJB0QgV032641@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 11:00:27 -0000 The following reply was made to PR kern/143874; it has been noted by GNATS. From: Bernhard Schmidt To: oliver.solaris@gmail.com Cc: bug-followup@freebsd.org Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource Date: Sun, 19 Dec 2010 11:49:27 +0100 On Sunday 12 September 2010 05:30:10 oliver.solaris@gmail.com wrote: > I have the same issue with a Toshiba Satellite P105: > > Sep 11 21:46:13 kernel: wpi0: irq 17 > at device 0.0 on pci3 > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res 3 failed > (0, 0xfffff fff). > Sep 11 21:46:13 kernel: wpi0: could not allocate memory resource > Sep 11 21:46:13 kernel: device_attach: wpi0 attach returned 6 > > Please let me know if I can help out to track this issue down. Is this still an issue on a recent stable/8 or 8.2-BETA1? -- Bernhard From owner-freebsd-net@FreeBSD.ORG Sun Dec 19 11:40:07 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15F6106566C for ; Sun, 19 Dec 2010 11:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C57938FC1F for ; Sun, 19 Dec 2010 11:40:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJBe7fE078961 for ; Sun, 19 Dec 2010 11:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJBe7LS078960; Sun, 19 Dec 2010 11:40:07 GMT (envelope-from gnats) Date: Sun, 19 Dec 2010 11:40:07 GMT Message-Id: <201012191140.oBJBe7LS078960@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/142907: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 11:40:08 -0000 The following reply was made to PR kern/142907; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/142907: commit references a PR Date: Sun, 19 Dec 2010 11:37:53 +0000 (UTC) Author: bschmidt Date: Sun Dec 19 11:37:44 2010 New Revision: 216559 URL: http://svn.freebsd.org/changeset/base/216559 Log: Update firmware for wpi(4) from version 2.14.4 to 15.32.2.9. PR: kern/142907 Submitted by: Craig Butler MFC after: 2 weeks Added: head/sys/contrib/dev/wpi/iwlwifi-3945-15.32.2.9.fw.uu Deleted: head/sys/contrib/dev/wpi/iwlwifi-3945-2.14.4.fw.uu Modified: head/sys/conf/files head/sys/contrib/dev/wpi/LICENSE head/sys/modules/wpifw/Makefile Modified: head/sys/conf/files ============================================================================== --- head/sys/conf/files Sun Dec 19 11:14:34 2010 (r216558) +++ head/sys/conf/files Sun Dec 19 11:37:44 2010 (r216559) @@ -1886,7 +1886,7 @@ dev/wi/if_wi_pccard.c optional wi pccar dev/wi/if_wi_pci.c optional wi pci dev/wl/if_wl.c optional wl isa wpifw.c optional wpifw \ - compile-with "${AWK} -f $S/tools/fw_stub.awk wpi.fw:wpifw:2144 -mwpi -c${.TARGET}" \ + compile-with "${AWK} -f $S/tools/fw_stub.awk wpi.fw:wpifw:153229 -mwpi -c${.TARGET}" \ no-implicit-rule before-depend local \ clean "wpifw.c" wpifw.fwo optional wpifw \ @@ -1895,8 +1895,8 @@ wpifw.fwo optional wpifw \ no-implicit-rule \ clean "wpifw.fwo" wpi.fw optional wpifw \ - dependency "$S/contrib/dev/wpi/iwlwifi-3945-2.14.4.fw.uu" \ - compile-with "uudecode -o ${.TARGET} $S/contrib/dev/wpi/iwlwifi-3945-2.14.4.fw.uu" \ + dependency "$S/contrib/dev/wpi/iwlwifi-3945-15.32.2.9.fw.uu" \ + compile-with "uudecode -o ${.TARGET} $S/contrib/dev/wpi/iwlwifi-3945-15.32.2.9.fw.uu" \ no-obj no-implicit-rule \ clean "wpi.fw" dev/xe/if_xe.c optional xe Modified: head/sys/contrib/dev/wpi/LICENSE ============================================================================== --- head/sys/contrib/dev/wpi/LICENSE Sun Dec 19 11:14:34 2010 (r216558) +++ head/sys/contrib/dev/wpi/LICENSE Sun Dec 19 11:37:44 2010 (r216559) @@ -1,4 +1,4 @@ -Copyright (c) 2006, Intel Corporation. +Copyright (c) 2006-2009, Intel Corporation. All rights reserved. Redistribution. Redistribution and use in binary form, without Added: head/sys/contrib/dev/wpi/iwlwifi-3945-15.32.2.9.fw.uu ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/contrib/dev/wpi/iwlwifi-3945-15.32.2.9.fw.uu Sun Dec 19 11:37:44 2010 (r216559) @@ -0,0 +1,2636 @@ +begin-base64 644 iwlwifi-3945.ucode +CQIgD0g8AQAAgAAAcAoAAACAAACEAwAAICCADwAAQABpIAAAaSBAAGkgAABpIEAAICCADwAA6ABp +IAAAaSBAAGkgAABpIEAAICCADwAADAJpIAAAaSBAAGkgAABKIAAASiEAAEoiAABKIwAASiQAAEol +AABKJgAASicAAEogABBKIQAQSiIAEEojABBKJAAQSiUAEEomABBKJwAQSiAAIEohACBKIgAgSiMA +IEokACBKJQAgSiYAIEonACBKIAAwSiEAMAokgD+AAACAQSycMEAsnDBCJBw0CiKAP4AA6EkKIwA3 +BgkAAEomAHBpIEAASiYAcEomAHBKJgBwSiYAcEIIAAAgIECHAAAAAAAAAAAAAAAAAAAAABLIz3Kg +AMgfDhoYgBPIDxoYgBTIEBoYgBUSATYayCR4ERoYgOB+4HjxwOHFz3WgAMgfExUAlv24ANoR8s9x +gAAcAACBguAL9ADYnbgTHRiQQKEgIIAPAAAAABYVAJbPcYAAnAUEIICP3lcEgAGhC/IvKQEAz3CA +AORK8CBAAEB44P/xBQAA4HgQ2BIaGDAA2Ju4ExoYMADYFBoYMADYj7gVGhgw4H7geBLInrgSGhgw +E8iNuJu4ExoYMBXIBSCAD14EAAAVGhgwZ9jpBSAA0dnxwHXY3g0gAIohBAKSCwAACgkAAB4JAAAD +2c9wnwDY/y6g63CKIQQEz3KAAAA//tuuDiAAmHHRwOB+4HjhxPwcCL9qJIAQ4cRqJMAQ4cT8HMi+ +/BxIvuHA4cHhwuHD/BwIsfwcSLH8HIix/BzIsfwcCLL8HEiy/ByIsvwcyLLhxfHAz3WgAMgfGRUB +llYNIAB72Iog/w8ZHRiQz3AAAAgM3gtAAAQgvo8AAAAPz3KAAAA/63AE9HDZE9sE8HTZBdseDiAA +mHHRwMHFBBQLNAQUCjQEFAk0BBQINAQUBzQEFAY0BBQFNAQUBDTBw8HCwcHBwMHERSx+EAomQH7B +xGskgBTBxGskwBDBxGskgBDBxJ90wcQgIICH8cB22MYMIAC+2QYPQACWDs//0cDgfuB48cBo2K4M +IADF2c9wgACcBfIN7/8AGAAHaSCAAW8hPwD+8eB48cBq2IoMIADZ2QDYjbgyCKAA8hoYsNHA4H7g +ePHAagyAABDZz3CgAMgfEhhYgNHA4H7gePHApgsAAM9wgACgBSCAG8gkeC8oAQBOIEEDz3CgABQE +KqDPcKAAmAM7oB2A2RpYsPYaGLDYEo2wnOUB3gvy63CKIcQCz3KAABU/yXMKDSAAmHW6D2AA8hqY +s7kDAADgeAbY2RoYsAHYlrihB2AA8hoYsOB48cAuCwAAz3EDAEANz3CgAKggIKAVyAQgvo9eBAAA +GfJEIMBLz3GgANAbOIEFeQYmwngAAAAgBSJ+gBP0z3GAAGgq2BEAAAHg2BkAAAnwz3GAAGgq1BEA +AAHg1BkAAM93gADgS6GHz3aAAGRLgOUN9OtwiiGFBs9ygAAVPwHbZgwgAEokAAAvLUET8CZAE0B4 +z3CgACwg0YDPdYAAnCsChQImARAAhTBwSffCpQjYtgwgACOFANgDpQSlz3KAAKQFAIICJgEQ13EM +AACAxfcBh8Cil7gBpwDZj7nPcKAA0BszoLUCAADgePHAz3GAAKAFIIH2CiAAfNjrcNTZz3KAABU/ +ANveCyAAmHPRwOB+4HjxwB4KAAAIdYTgKHYD8obljPfrcIohBgLPcoAAFT8oc7ILIABKJAAAz3OA +AORKANiRuBsSAjYcEgE2TiVPE7h4En2A5vV7DfTPdgAAWAPAo0V4GxoYMKR5HBpYMAvwz3YAALAG +wKMleBwaGDCkehsamDAVAgAA4HjxwNIIwAUQ2c9woADIHxIYWIDRwOB+4Hjhxc9wAAB0s89ygADk +SgCiz3EAALQEIaLPcAAAJAMCoiOiz3AAAATUBKLPcAAAQAMFos9wAABUowaiz3AAALgDB6LPcAAA +sAYIoimiz3AAAFgDCqILogyiDaIuos9wAADMAw+iENgG8BUiDAAgpAHgn+C8989wAABEBhyiz3AA +AAADH6JP2BG4GxoYMADYlrgcGhgwANjPdYAA4EvPcoAAZEsA24y7YaUF8BUiDAAgpAHgoOC79wDY +C/DPcYAADAkWeWGBIIEB4BUiQQBgoZHgtffBxeB+4HjxwFEhQMcr8s9wgABoBgCAg+AN8utwiiFG +Cc9ygAAVPyhzSgogAEokAADGDEAFE8iKIf8PvbgTGhgwz3CAAAAAABAdAM9wgAAEAACAayDAAs9w +oADIHxkYWIAA2Z25z3CgAMgfExhYgNHA4H7PcIAAoAUggBzIJHgvKAEARQHgAE4gQAPgfuB4/ByI +tvwcSLb8HAi2/BzItfwciLX8HEi1/BwItfwcyLT8HIi0/BxItPwcCLT8HMiz/ByIs/wcSLPgfuB4 +BNw43TXw4HgE3DTdM/DgeATcMN0x8OB4BNws3S/w4HgE3CjdLfDgeATcJN0r8OB4BNwg3Snw4HgE +3BzdJ/DgeATcGN0l8OB4BNwU3SPw4HgE3BDdIfDgeATcDN0f8OB4BNwI3Rzw4HgE3ATdGfA0FBow +MBQZMCwUGDAoFBcwJBQWMCAUFTAcFBQwGBQTMBQUEjAQFBEwDBQQMALHAcawJE0zsCQfM+B+8cBK +D+//QShDAc9ygADIIvAiwwBTIAIBESOAgAHeHvQA3c9yoACwH9iiz3OAALAKQ4PPdqAALCDKhvJq +9H9/Z8enBqcopwHijCIIgEOjhvcCg6OjAeACo1kHz/8A2c9woAAsICqgK6AB2c9woACwHzag4H7x +wMoOz/8odkh3GnPPdYAAlAkghQoiACGK4QohQCFZ90QpPgcAJUweIg7gAAGkQIVEKj4HACVBHgKh +HBlABMOh5KEUGQAEGBmABAHiQKXZBs//4HjxwOHFCHWYcQDZz3CgANAPNaDPcaAAuD8SEQCGiLgS +GRiAEhEBhn3YxP+weLIJIACIcQHw8cBKDu//UyDCBSh1aHYKIAAhUyXDNVMmzzWT5lMnwTUD9BPY +AvAF2Jh3uHXT/8lwCnHn/3kGz//hxUhzL3pAKgECRXlAKQIEJXqI4whxkfcE8AEZkgBhu1MhfoD7 +9UErjQDBu4Al/58EGZAA/PWA4wbygCP/jwEZkgD99cHF4H7Pcp8A2P8SojOiANiYuBGi4H7gePHA +ocEocz8SATcAHIQwAhxEMAHhj7k/GlwwRGvscUChAMJAoSK7BfBAoQTgYbuB40CAPPcA289woADQ +Dw4YmIAI2Ahx6v/PcIAAnCtjoKHA0cDgf2Sg4HjxwOHFqMEA2I+4PxocMADdfRpCM89wAQAgD0DA +QcVCxQHaz3CAAMxGAIhjwg0cAjAOHEQzz3CAALAKRMDPcIAAlAlFwM9w8En5dEbAR8KLcCDZ1v8I +2Ahxz//PcIAAnCujoKSgG9h8GgIwcQXv/6jA8cDhxetw2BKEsEHZz3KAACw/lg7v/wDbUQXP//HA +A9oA289xoADUBxUZmIDPcaAA0A8OGRiACNgIcbv/z3CAAJwrY6DRwOB/ZKDgePHAqgzv/whyA90A +3s9woADQDxIYWIMRGJiDGNsAH8BAAtt8GsIwHxIDNgAfwEAb23wawjA/EgM3AeM/GtwwAB+AQPYS +ArYAH4BAAB+EQwAfQEDPcqAAyB+MEgEAAB9AQJASAADb/89woADUBxYYWIMI2ADZmbmZ/2kgQACZ +BM//z3GgAMgf2BkAANwRAADgfvHAA9oA289xoADUBxUZmIDPcaAAZAukGQIACNgIcYv/z3CAAJwr +Y6DRwOB/ZKDgePHAA9oA289xoADUBxUZmIDPcaAAVAu0GQQACNgIcX//z3CAAJwrY6DRwOB/ZKDg +ePHA4cUD2gDbz3GgANQHFRmYgM9xoADQDw4ZGIAI2M91gACcKySFA6VBhQHhMHIkpQX3CHFt/2Ol +ZKX1A8//4HjxwATYAB8AQAPZANvPcKAA1AcVGFiA9snPcaAA0A8OGRiACNgIcWH/z3CAAJwrY6DR +wOB/ZKDgeIDhCHJB8kAhwwPDuY/hegAtACS7zHDwJkxwgAA4PwB8IIAEGlAAIIAEGlAAIIAEGlAA +IIAEGlAAIIAEGlAAIIAEGlAAIIAEGlAAIIAEGlAAIIAEGlAAIIAEGlAAIIAEGlAAIIAEGlAAIIAE +GlAAIIAEGlAAIIAEGlAAIICAI/+PBBpQAM714H9IcOB4ABYCQAhxQKEAFgJAQaEAFgJAQqEAFgJA +Q6EAFgJARKEAFgJARaEAFgJARqEAFgJAR6EAFgJASKEAFgJASaEAFgJASqEAFgJAS6EAFgBA4H8M +oeB4gOLgfGNqwbqD4uEgzQciu/AmjHCAAHg/AHxAgAQZkAAE4ECABBmQAATgQIAEGZAABOBAgIAj +/48E4OEgwQcEGZAA7fGA4uB8QCLDA8O6j+LhIM0HJLvwJoxwgACIPwB8QIgBGZIAAeBAiAEZkgAB +4ECIARmSAAHgQIgBGZIAAeBAiAEZkgAB4ECIARmSAAHgQIgBGZIAAeBAiAEZkgAB4ECIARmSAAHg +QIgBGZIAAeBAiAEZkgAB4ECIARmSAAHgQIgBGZIAAeBAiAEZkgAB4ECIARmSAAHgQIiAI/+PAeDh +IMEHARmSALzx4HjxwOHFKHUiuYv/wb2B5Q7yguUI8oPlDfQAFoFAARhSAAAWgUABGFIAABaBQCCo +vQHP/+B4CHIA2AbwABYDQQHgAhrUABBx4CDOB/nxCHIA2AbwABaDQAHgARrSABBx4CDOB/nx4cUo +cgDbEPCggAHjABhAU6GAABhAU6KAABhAU6OAABhAUxDgQSoBAXBxMPcA2wfwIIAB4wAYQFAE4FMi +wQAiuXBxOPcA2QfwYIgB4QAYwlAB4FMiQwAwczj3wcXgfuB4ANrPcZ8A2P8SoVGhFIHgfvHAogjv +//hwKHXYcrhziHMZ2Ae4z3YAACwJYH4A2cnYBLhgfqhxz3AAAJgMYH7occ9wAACcDGB+CNnPcAAA +pAxgfshxz3CfANj/rKAZ2Ae4YH5ocbkAz//ZEgG2FSJBMNoRAYYwcOAgxQfgfyJ44HjxwDIIz/8A +3c9zAAAEDal2BvBouWhwk/4g4wHmhuZX9s9yoADUBxoamIMYGliDFSKBM9oRAYYA2BcaWIAUGhiA +iOE9ZSf3CHHm8VUAz//geAhzRGnscECg9hICtkCgQSmCAAXwIKAE42G6geIggzz36QLv/yhw4Hjx +wLoPr/8IcgTYz3WgABQECqUN8AmFz3agAJgDCSIDAB6GeGDT/x6mYnqA4vT1+QeP/+B4ocHxwAhy +CNsAH8BAAB+AQChwp/7RwOB/ocDgePHAag+P/womAJAodQv063CKIcwDz3KAACw/Adv+CO//mHGA +5Qv063CKIQwEz3KAACw/AdvmCO//mHEBjYDgDPTrcIohjAXPcoAALD8B284I7/+YcQQmvp8AAPAA +A/Tgvgj0RCYOHM9wgACwBSS+BvDdfs9wgADQIyCN1HhFIcEAIKghjVEHr/8hqOB48cDhxQS4ACCN +D4AA2CgAhem4DPLrcIohzArPcoAALD8A224I7/+Yc6aNgOUL9OtwiiFMC89ygAAsPwDbUgjv/5hz +BCW+nwAA8AAE9OC9CfREJQAcJLhDcLQQgIAF8L19Q3WkFYCQ7QaP/+B4KHJZAO//ANnxwGYOj/8I +dljMKHcQuM91gABoKmYOIAYApYDgAvIA3/TY7HEAocChKsjguATyAIWBuAClAN7PcKAAyB+oEAIA +z3CAAOQqgOdYoCvyAIWAuAClz3CAAOQq7oDJcAXwQKEEHZATAeC74ECFu/fPcKAA0A8OGJiAwKUI +2CII7/8Icc9wgACcK8OgxKDPcIAA5CruoM9wgACEMcqwzrAX8MlwBPBAoQTlAeC74ECFu/fPcKAA +0A8OGJiACNjiD6//CHHPcIAAnCvDoMSgBQaP/+B4/BwItPHAGnDPcYAAZEuAEQAAocGuuIAZAADP +coAAxAUgggFpAKKmD6//SNjPcIAAqAUAgIDgD/Sd2AAcBDA/zAIcBDAB4I+4PxocMADACnG4/0oO +gAChwNHABBQQNOB+ANjQ8fHA4cWhwQAWDUD2yVMlARCv/+G9z3GAAKgFBPIB2APwANgAoYUFr/+h +wOB48cAGDY//Fg6v/wDfz3EBACAPKg+v/wTYz3CgALQP/KDPdaAAwC8Thc92oACwH5C4E6WqDM// +gNnPcKAA1AccGFiAz3CgANQLPKDPcMABsAAUpgnYz3GgACwgDqEPoVDYFqHKDqAA6XDeCIAEfgxA +BYohBADPcKAAyBwpoCoPj//PcIAAIAAAgIDgBfITheC4/vMThbK4s7iQuJG4E6WCDQAAygpAB1YJ +AAfPcKAAxCdAGNiDQhjYgwLYwBoYsAjYeg6v/wHZQgzAAEYOwAFuCUACiglAAqoJQAKCDkACsg/A +BjoJAAaKD8AE/ggABZoLQAVqDQAAw9gauBWmz3EDAEANz3CgAKggIKDPcAHgAEDPdaAA0BsVpQfY +F6UG2BalANiauBSmCgmAAwDYkrgVps9woAAsIPGgA9gSuBSmANiPuBWmANiWuBylz3CAACAAAICA +4ATyNgmgBwHYWgyAB6oMgAeCDIAHBQSP//HAmguP/89wgACIBgCAgOAADgIG5M3guCHyANmMuc9w +oADQGzOgz3KgACwgLoJ7zGO4CCEAAAyiAdnPcKAAsB80oM9wgADoS/MaGLDPcIAAkEw5AiAA9xoY +sO24YfKuCQAD5M3vuF3yBNjyGhiwz3KgALAfGKIg2BSiwNgYuM9xoADQGxChz3OgACwgDYOA4BT0 +DoN7Eg0304MD8LhgEHZ+9wDfjb/zoQIgjwPto2Lf9KLzg9F38vPPcIAAiAYAgIDgdA0CBj0Dj/9R +IIDHPAkCA/LJ7LgW8sTJz3GgABQECqHPcaAAmAMboTYJoAHZGhiwzcnZEgG2DyBAAM0aGLDkEgG3 +5LlA9Oa5gAECAEQhPoquAQEAUSMAw3gBAgDyyQQgvo8DAehT0SChx8/1INjPcaAAsB8UoQTYGKHP +cKAALCANgIDgBPQQ2BShL9ieuM9xoADQGxChz3BeBADAE6EiCYADz3AAAIQOz3GfANj/EqHPcIAA +SEAEgBOhANiYuBGhnPHlEgG36bkb8ihwqbgQeeUaHLAgyNkSArYPIIAAIBoYMENydBKCAPfJFSKM +MNccGJDzyRUigjD0GhiA57k38qe5xcnlGlywFSIBMNcRAYYVIgAw9BAAhvMaWLD3GhiwxBIBts9w +oAAUBCqgz3CgAJgDO6DPcAAAhA7Pcp8A2P8Sos9wgABIQPAgQAATogDYmLgRogoIoAHZGliwzcnZ +EgG2DyBAAM0aGLAY8FMhfoAM8vfJ8xIBtvMaGLDiD2AB9xpYsAzw6LkK8ofNcg5gACASgbAQ2PIa +GLDlzeu4vgbB/yHI9hINtvYaGLDPcIAAhE3GCAAB5c32Glizq7ifBu//5RocsJYPQAGTBs//47nP +coAAaCoK8oDZqBIAAOQaXLAB4KgaAAAL8IohBACkEgAA5BpcsAHgpBoAAOe5EPTouUr06blS9O65 +0SMiw04Gwf8Q2c9woACwHzSgKvDPcYAAEAgAgQHgAKHPcYAACAgAgYPgDPQC2AChz3GAAGRLgBEA +AI+4gBkAAJoJgAPlzeO4F/IG2c9woACwHzigz3GgACwgDIEtgQrgEHFH9wTY7wXv//IaGLAC2OQa +HLCk8fPJjBAAAPC4ANgN8iIOQAMA2Ja4CfC2CKADiiAEAEYJgAPv8aIJgAPk8QIOYAMB2ADYkLj5 +8fHAIgiP/wh2AN0b8OCO/H+I543363CKIYYLz3KAAJhAKHO2Ca//SiQAACGOz3CAANAj9HggqCKO +AeUhqATmiOWm9wDdHPDgjkQnDxxEv4TnjPfrcIohxg7PcoAAmEAoc3YJr/9KJAAAIY7PcIAArAX0 +eCSoIo4B5SWoBOaE5aX3CQCP//HABNnPcKAAFAQqoM9woACYAx2A2RpYsPYaGLDYy5zgzCCCjwAA +kQAD8gAWAEDtzc9xnwDY/xChiiBGBBoIr//2EgG20cDgf9jL4HjxwO3/z3GAANgk8CEAAEB40cDg +fvHAz3KAAFgrgeAQ9CoSATYryAKipMohogyqpcrAuQ2qWMwJsjCqFfABgioaGDACgisaGDAMiqQa +AjANiqUaAjAJklgaHDDaDu//QCIABdHA4H7gePHA4cXPdYAAWCvPcIAApEBAJQEVvgyv/zDasg7v +/0AlABVBB0//4HgD2gDZz3CgANAPWqDgf+8aQjDgePHArg5v/7DZAN7PcIAAaFzUqM91gAAYVyoI +7/+pcM9ygAB4WMlwCvAWIgEAIpEUJQwQWBxEEAHgh+C49s93gAB4Ss91gADYK+lwJG1KDK//Btoi +zkAlgRI+DK//BtrpcEAlARQyDK//BtrPcoAAsCvPcIAA6EukGIAAz3WAAJBMpB2AEADZEfCEKQIK +ACGDf4AAqE2kG4AAACGDf4AA+E6kG4AAAeGC4bD2oMqE4BL0iiAPCrIOb/+KIVIKWMwqEgI2D3m6 +CiAJUyIAALIPQAgryOW4BfIqyOe4FAuBByvI5bgK8ooghw5+Dm//iiESD4YIAAS+/wHY9BoCMM9w +AAD//5gdABCUHQAQiiAEADEaGDAFBm//IBqYM+B48cDhxY4NoAAA3ZIPgAGpcQ7wiiIIBBRpx3CA +ANgoQKCisIoi/w9CoEOgAeGZ4bP3lgoAArIKAALSCgACfgpAAwHYLg8gCADZcgrABdYLQAgiDUAH +eggABKIIwATaCcAETgrgCADYbglABM4aWLN6DyACzRpYswYMgAMqDIAH+gwABYkFT//geIDgyiBi +ABN4wbjPcQAAJIXPcqAADCQ+os9xoACIJAGhB9mMuS6iEKLgfuB48cDeDG//ANukEoIw5BKBMB7w +ACLAMDwQgIAe3UR4Ly8BEAIlzhNDdlAWjpAAIswwpByCkyR4LygBAAJ9Q3VQFYCQACLMMKwcApAB +44jjo/cA2KUSgzDuEoIwGPAAIgEwRBGBgAAiDDBkeS8pQQBOIY0HQ3VYFYGQtBxCkER5ACIMMLgc +QpAB4ITgqve5BE//8cBODE//CHYqyOG4C/LrcIohyQXPcoAA1ED/2+YNb/+YcSrIBSaNHxAAAAAE +IIEP7////yoaWDDwvjXaz3CgAMgcSaAA3hbyz3AAADCFz3KgAAwkHqLPc6AAiCTBo0PYCLgOotCi +z3AAAAiUHqLBo+29FfJM2HEaHDAxyKm4MRoYMALYNxoYMArYWxocMBDYWhocMBTYcBocMOW5BfIE +2O4aAjAD8O4agjPkvSvy5LlbzAryCdp7GpwwJOBdGhwwAtgJ8BTaexqcMCjgXRocMAHY9RoCMFrM +z3OAAKwFYItYYHhgXBocMBDYz3OgALAfFaPPcKAALCBOoE+giiAHDBSjBCW+nwEAAwB08uC5z3CA +AOQ+MRIENkCIPPLPd6AAsB8A25y7dKfgugTyZNsD8ADb4bpmoAnyh7pAqEGAQ6BCgESgBfCnukCo +w6DEoFsSAjdazHganDBCeHkaHDCA2Iy4LxoYMAXYCbg0Ghgw4rmIcAfyhCB/DYUgUA0F8IQgbwVF +IEAFMRoYMDMamDMj8M9zoACwHwDfnL/1o6e6QKjDoMSgxqBazHkanDN4GhwwEdgIuC8aGDCIcIQg +bwVFIEAFMRoYMDMamDMD2Aq4NBoYMPC5B/KKIBADMBoYMAzYBvCKIBACMBoYMAjYNRoYMOK9B/JE +IQABU/8qEgE2BCW+nwAAgg8o8ue5BCGADwAAAA8J8owgBIAD9ALaFfAB2hPwgOAN8utwiiEPBs9y +gADUQP/bzgtv/5hxKhIBNs9wgAD8B0CAXNuMu89woAAMJG6gUKD0vc9zoADsJwDfHvL0uc9ygACo +MRLyL8iEuC8aGDA0yIS4NBoYMM9wAwAO4gejA9jiGgIAEN8I8M9wAAAO4gej4hqCA+ujMcg2Gtgz +CHKEIj8MMhqYMM9yoADIHAiiMNrPcKAAwC9SoDMSAjbPcKAAyBxGoC/I7LkLozDIANpFIEACBqPP +cKAA0BuNugLy4LnMo1GgDYOkEoEw5BpCMOW5KHAI8ihyhCL8D0945BqCMOO5BfKkuOQaAjAZ/6US +grAI2I24OhoYMCrIthKBsEQgvoLmGkIw5RqCMAXy5xpCMAPw5xqCMP+9EPLPcQAAVVXPcKAAyBw6 +oAHaWaDPcaAAiCRPoRjYEaFZAU//8cDuCG//Is6qDW//C9leCOAIAN0ryOW4A/IB3gLwqXbPd4AA +0AWA5hnyAIeA4Azy63CKIUUPz3KAANRAANtmCm//mHGuCUAAiiBJBloJb/+KIcYAKgygBADYwKd5 +/s9woADQD7WgAdhS/oDm8ArB/2X+tg2gBMlwKhICNs9wgADOBwCQUyIDAHBwWBIBNwj0z3CAAMwH +AJAwcBDyBCKDDwgAAABTIgAAfgpgB2hyfgtAB4Dg/fMF8IDmUA2CCIog/w/4/s9xACAAPM9woADI +Hy6gMg1AAc9wgACcXwaAgeAH8hXIBSCAD14EAAAM8M9wgADILAKAEbgFIIEPAAQAABXIJXgVGhgw +5gwAAgTYwBoYsM9wgAAgAACAgOAL8h4PAAeA5gfyvgyABgDYMg2gBghxSgxP/yEAT//gePHAsf9e +Cg//0cDgfgDaz3CgANAPVaDPcaAA7CdLoQnYBqEB2M9xoACIJA+hHtgRoQLYDQRv/8AaGLDgePHA +dg8P/wAWjkAAFoFAABYPQc91gABYKwmV8XAE9BCN0XAN8utwiiHTDM9ygADUQChz+ghv/0okAABA +JQAV/gtv/wzZ73nJcEAlAhWaCeAIANuyC0//z3CAAMwHIJAJlRBxDfTPcIAAzgcgkBCNEHEF9OYO +r/9AJQAVZQcP/+B48cDmDg//CHXZEhG23tiiDy//qXFKIwAgIMgPI1MjCyDAhAHaC/IA2JG4uHjP +caAAyB8VGRiA7QEAAM9woAAUBKqgCYDM4NkaWLNL989xoAAUBCgZQATNASAA2RpYtAAiTzN0F48Q +A9mELwIaL3AAII4PgACoTRUizDPXHJiTx3CAAPhOFSLMM/QcGJDPcKAAFAQioESgABYBQBYizDPJ +HFiQDg8v/97Yngtv/8lwz3CgAJgDPoBVJtIXoB5AEPMamLMoFhAQz3CgACwgEYAKcYwh/48e4Cvy +InjXcACAAABAAAYAyg4v/+LY88nPcYAAsCukGEAAh9mQuYwYQAAWIs8zyRcAlvYaGLDCCyADAdgA +2JG4uHjPcaAA0BscoZjxzskFIMAEzhoYsAPZz3CgABQEI6AA2SSg2RpYtM9xoAAUBCgZQAQB2JK4 +yXGaDmAAKnLPcIAAeFgAgEQgAoQi9BQSACDguAXyiiEFBALwTNmcFgAROGAEIIEPAADg/wQgvo8A +AADgBfL/2Qi5AvADuQqORXnDuCV4FiLMM5UcHJCcFgARFiLMM5QcHJDPcIAAGFe0eADZMKggyM4S +AbYFIMAECyHAhCAaGDAh8s9woACwHxuAz3GgACwgUYEmDWADAiCBIAh24NjGDS//yXHPcQAAKCLJ +cADaCgvgAxPbz3GAAEBK9nkAocGhANiRuLh4z3GgANAbE6Hf2JYNL/+pcR0FD//xwNIMD//OEgK2 +BPAQIoIDgOIA2RHyLymBAE4hjgcAIo0zdBWNEM9xgABASrZ5IYEQce71AdmB4Qvy63CKIUYHz3KA +AOFAANs+Di//mHPZEg+2z3CgANQHGhiYgxUiQTPXEQGG2RqYs/MaWLAqgR4NL//i2M9xoAAsIDGB +Dg0v/+LY88nPcYAAsCukGEAAh9mQuYwYQAAWIk0zyRUAlvYaGLAGCiADAdjOyc9xoADQGxAggAPO +GhiwIMgQIIADIBoYMADYkbjYeByhz3CgANQHGhjYg2UEL//ZGtiz8cD2Cy//AdkIdsK4Q3AEEIOA +BCaAHwAAAP9DuAAizTDPcoAAeFhAgsO+RCICBMV6hxqcsCASAjZ0FY0QESLAgMcaWLBJ8hUiQjPX +EgKGz3aAABhXgOB0fgv0AtnHGliwQdkMucYaWLAA2TCuN/AWIkwzlBQBlxBxSPcC2ccaWLDPcRYA +ABDw8RYiTDOVFAGXhxpcsDCOAeEvfzCuLhKBAPFxOgAKAAXZxxpYsBfwLymBAE4hgwcA2Q8hwQAm +egAizTCA4HQVjRAU8hYiTDOUFAGXEHGa94Di6/XEGtiwxRpYs4YaHLAqynUDL/8gGgKwAtnHGliw +QdkMucYaWLDPdoAAGFd0frLxAtnHGliwz3EWAAAQ8/HgePHAvgoP//pwGnEA3gQhvo8AAPAAKHAE +9OC4GPREIAAsXGjuygQgAQQ6Ys9wgAAIQPQglQDPcIAAOED0IJIAhSGBAF0SFjcQ8Bx4z3GAAMg/ +9CEVAM9xgAD4P/QhEgBcEhY3QNnPcIAA5D4AiOe4BPKFuTB5z3CAANgoAIDluAXyRSEABAPwRSEA +Ai8hCCCGzYDgEPIC2c9woACwHzigz3CgACwgDIAAIJMESiRAIQbwSiRAIEojACDJd8l1UvDPcKAA +LCAwgHJxrAAlAAHlLyOIBCpwCnGuC+AAHtr4uEf0A9jPcqAA1AcNooUnBxIAGMRTABhEVSTIgb4A +GABQSswA3wAYBFAiyAHZABgAUEbMANsAGARQJMiMuwAYAFBKzAAYBFAA2AAYBFAAGMRVDKLPcqAA +sB81os9xoADQG3OhBNk0os9yoAAsIDAagAWuD2AAi79RIwDDBPRRIIDH/POSdV4Hxf+Cvgbw+7gD +8oO+AvCAvpEBL//JcOB48cBiCS//mHIQccYADgACednJANoPIgIAIMhGeHgSDjcV8C8qAQBOIo0H +ANoPIkIDACJPM3QXjxBGeBYizDOUFAKX2mIwckQABQCA4Ov18xICthqS6LgF8gGC47g59CASg7AE +I76PAADwAAT04Lsh9EQjDQzuykS9ZHi4YM9zgAA4QPQjAwAb8PPJxRrYs34YhACHu+Ua3LDPcYAA +aCq8EQAAxBpYswHgvBkAABHwfHvPcIAA+D/0IMMAMHNJ94ogBAHlGhywhxocsX4axAD9AA//4HgB +2c9woACwHzigz3CgACwgCoDgfghzOGDTu9O5cHE4uET3AiNCAArwz3KAADRfRYIB4CJ6emIPeBi4 +4H9FeOB4z3Pw/wAABCDCACR7UHMI9BBxE/cQcQr04H8A2AIjgADXcACAAABE9+B/AdhietdyAIAA +AHr34H+KIP8P8cAOCA//osEacCh2z3CgAMgftYCBwG4N4AOLcYDgJPIAwIDgGvJTJcIU/9gYuAHB +BH0keLFwkvexcBD0FOLTuVBxzPfrcJDZz3KAAO5AiiMLAHYJL/+YcYDmCPIAhgDBMHAE9AHYCPAK +cAHB1v+A4Hr2ANj9B+/+osDgePHA4cUIc0h1z3CgAMgfFYB5YcP/qXHc//UHz/7xwHoPz/4IdgDd +z3CAADRf13YlAACA5YBH9wTw4n4B5dF3vvcJ8MlwHghgA+lxCHUMfwImTh6MJQSQi/frcCzZz3KA +AO5AANvmCC//mHNALQAWkQfv/sV4AdvPcqAAsB94os9yoAAsIEqCgOAE8iJ6EHIE9+B/ANjgf2hw +8cCgyoXgDvTPcAEAoIZ6D8//z3EAACAoANoaD6ADC9vRwOB+z3GAAGRLgBEAAI644H+AGQAA4Hjx +wFILD/9pIEAA0cDgfuB48cC6Du/+ANnMcAjwQIAVIkww2hyYkAHhhuG69qCAwIBqDg//z3CgANQH +HBhYg89woADQDx0YmIMKCw//6QbP/vHAdg7v/gLZosEyCy//i3AhwM9xgAAEQRx4wbgNYQYUgDDP +c4AAuFiA4Aj0ANkPIUEDAIMmeBnwu3rBagLiBRSBMBUjjwOA4RUjjgAE9ArYAKcH8ADCOGBhukej +IKcApgCDDyBAAwCjANnPdaAAvDdkHUCQAdkJ8PAjQgAVJUwQRByAkAHhiOG490QdAJB2Cg//TQbv +/qLAgODgfQDZz3KAALhYKHAG8BUiDAAgpAHgiOC8989woAC8N2QYQIDgfvHAug3P/gAWDUAM3ga9 +x3WAAOAjqXBmCi//yXEG8ADYFSWMEwCkAeaQ5rv3FgoP//UFz/7xwHoNz/4IdRcBIAA6cS8oQQNO +II4H2tgiDu/+yXHPcQAAhA7PcJ8A2P8yoM9wgABIQPAggQPPcJ8A2P8zoADZmLkxoM9woADUBxoY +mIPPcAEBAAAAKJADAN8+yA8njxMLIMCD2RqYsyTyzskLIMCDE/IAIoEzdBGBAM9wgABASjZ4AIAP +eBIOoAMT2c7JECCAA84aGLAA2JG42HjPcaAAyB8eGRiAIMgQIIADIBoYMNnJANkPIQEAz3CgANQH +GRAAhoDgEfTPcKAAwC+lEACGCyBAgAny6dj+Cy//BLgEIAAEEnAZ8trYUg3v/oohGgzPcaAA1AcZ +EQGGQg3v/trYz3GgAMAvpREBhjIN7/7a2DoKIAEqcO4J4ALJcOZ9gOXuBsL/BNrPcQAAhA7PcJ8A +2P8yoM9wgABIQCSAz3CfANj/M6AA2Zi5MaDPcKAA1AcaGJiAhQTv/tkamLDxwOHF9hINtgAWAkEA +FgFBRCLAC4K5pP/2GlizlggP/30Ez/7xwP4Lz/7ZEhC22RoYsM9yAACEDs9xnwDY/1Khz3GAAEhA +8CECAM9xnwDY/1OhANqYulGhz3egANQHGh8YkADeDyYOEM91AQEAABh9GRcBlgDYBfAAFgJAAeBB +KYIAEHI69wDYBPAAFoJAAeBTIUIAEHI7989woADAL6UQAIYLIICD5vPp2NIKL/8EuKR4sXDe9c9x +AACEDs9wnwDY/zKgz3CAAEhA8CABBM9wnwDY/zOgANmYuTGgGh8YlKUD7/7ZGhi08cDPcIAAhDH6 +D+/+BdnPcYAAZEuAEQAAl7iAGQAArg/P/tHA4H7gePHACgvv/hDZsMHSD+/+i3Ajx5nnEBQNMYv3 +63CKIZIJz3KAAAhBAduiDO/+mHcgwOC4FG/HcIAA2Cg6cCL0AcACwelyMg0gAUAhwyGA4BpwJ/IA +2Yu5Fm/HcIAAWFCA5yCwBPIwsATw4g9AAQ0UgDBFIMABDRwCMIog/w9NwBHwAIDpuEogQCAL8utw +iiFTAc9ygAAIQQpzMgzv/ph3TCAAoGwBIQANFJIwDcEMwgARACAkeiZ4BXpRIgCgABmAIFLy67ov +8rZvx3WAAFhQhMBAJQEY5g/v/gjahMCpcd4P7/4I2oDnQPQQFAAxhCDzDxAcBDAA3hTwtW6EwAAl +gR+AAJhWtg/v/gjax3WAAJhWAJVALgESJXgAtQHmhOau9yLw7r0G9LZvx3WAAFhQEfCA5wr0hCUM +ECi9Bb3HdYAAmFYH8DZvz3CAAHhQPWCEwKlxag/v/gjaAJXruATyANiLuAC1USJAoAXyOBQBMQQZ +RCBRIoCgBvI6FIEwBhlCIFEiAKEX8j0UgzBAIQAifHoaYuC7IIoI8kEpAAGFIQMMIKoG8EUhwAMA +qihwPg9gAcO4USLAoC7yL8E+FAIxYg9gAelwBCCOjwAAgAAIdQzy63CKIZQMz3KAAAhBAdvuCu/+ +mHWA5gTyBNgT8C/CQCEBIlx4OGDguiCIB/LDuQS9JX2gqAbwhCEDDPzxAtgacCDA4LgG9AARASCp +uQAZQCAI2AAfAED2yQAfAEDWDO/+CnA1Ae/+sMDxwNIIz/6kwUoiQCCBwJYN7/5KcQDYEvAAwADZ +BLjHcIAA2CgisIohCAQgoIoh/w8ioCOgQCFAICHBEHF2AC4AOnCCwF4N7/4C2QLAA8H+CyABi3IE +IIAELyAHgFpw7PMAwc9zgAAABvRpQIMA2A8gQAAGIgGACiCAL4AA4Cggowb0gOIE8kIOoAQg2ADe +iOaIB8b/ACDAI81gUyXAEI/gEA5CARxtD3iP4AgOQgEB5u/xCNgAHwBA9skAHwBADgzv/kpwaQDv +/qTA4HjxwBoKAAGaDM/+0cDgfuB4z3GAAHhYz3CAABRB3QXv/kDa4HjhxZAQAQBWIIIDRCG+gocQ +gwAZ8nx4Q3A8EI2ApMrjuaR4LygBAE4gjQdDdVAVgJAQqgfyQrtDc6ATg4AJ8BGqFPBEIwAMRLhD +cEQQg4ClyuC5ZHgvKAEATiCDB0NzWBOAgBGqAvIQqsHF4H7xwFMgAoA8AAEABCC+jwAA8AAwAAIA +A7kceBUiADDgEACGFuEFKT4ACiDADjcSATYB4Dh4eRIBNzhgNQAgABB4t+AeAAsAFSKCMNISAIYD +uQUpPgAKIMAOAeAQeAjwiuAE9BNpEHgE8AK5MHjRwOB+8cD6Do/+KHfguFUhzgdN8kGH4roJ8s9x +IAAAICWmQNiWuAOmEPDhugjyz3EgAAAQJaZA2AOmCPAA2AWmANiWuAOmANnZEgO2z3CAAChX9CDA +AIDgVifNEx708boE8gmVh7gJteS6VieAE5pwCfIJj89xgADeKAS4CWGKcALwKI83qCiPACOAD4AA +GFcwGEIAJYYU8M9wgABIV2pgVieUE4cfghAK8ADZJaYA2Ja4A6ZWJ80TVieUEyoSAjbgulryz3CA +AOQ+AIjnuAzy88kBgOy4CPSRuQOGJaaFuJW4A6YXFIMgQCcAHwQjvo8AAPAAGnAE9OC7DvRbzIC5 +MhgEIDQYBCADhiWmgbiRuAOmFfBaEgM347p5sAvyW8xFIYECNBgEIAOGJaaBuAOmBfA0GMQggbkl +pvIN7//pcCWGRCF+ghEUgiAd8kQiAwzuykS7RHhIlRtjRXgItc9wgAAYQPQg0wDPcIAACED0IMAA +FPBaEgM3QCcQH24fxBDZ8Vx6z3CAANg/9CCTAM9wgADIP/QggABLj1pwwrrPcIAAcEBIYLhwMBgE +IM9wgAB4QPAggAAFeSWm4Lkhh4QhAQAe8hcUgiDuyphyRHhJlUEogwAFegIu1XAAAMAAgOFJtQzy +RCQBDES5OGDPcYAAKED0IQAAGPBKcBbwcBIVN4DhinAJ8heIz3GAAOg/HHj0IQAACPAQiM9xgADI +Pxx49CEAADpwAJcAIEEBMHlqDe//FxSAIAAgQgUBh+O4QbUE8gQdRBQF8ADZIrU6cQQggI8AAAAP +I4YS9CrIz3OAABA8BCCADwAAgA8nuPAjAABAKAMEZXgleAOmCPAluEAoAwRleAV5I6YlhvW5inAT +8nGI7Ll2qAiVBrUAHYQUB/IU2AW1OhjEJBTwDtgFtQDYDfA3iDaoCZUglwa1MBAAIThgBbUA2AC1 +WnB6cDoYBCAAI4AkGmIAIkAEdQSv/hK18cA2DI/+z3CAAOAIAIiA4BH0CgoACIDgDfSKIEcE0gyv +/gDZkNmQufPJIwIgAIwYQADPcIAA4wgAiIDgG/Llzea4CvLPcIAABAYAgAOAIJAveQfwz3CgAHQD +mBCBAIwhAoAJ9IoMr/6KIIcEkdmQudzxz3CgANAbEIAA2wQgvo+AQAAA8xIBtlYhwgMV8gaS5rgT +8hHYGLiMGQAAz3CAAGgqlBABAAHhlBhAAEIMr/7d2JsBAADPcKAA0A91oDbIz3WgAMQni7gVpQaS +z3OAAKgx4biGEY4AEvJEJg4cRL7PcIAAsAXUeMCIQC4AFEUggAIRpcCriiBMAhDw3H7PcIAA0CPU +eMCIQC4AFEUggAIRpcCriiBIAhClBpLluNEhosMc8s9zoACoIGGDEpJ4YM9zgADkPmGLEHNQ9wnY +GLiMGQAAz3GAAGgqmBEAAAHg+wAgAJgZAADyyea47gACAJARDQD6vVUhwwdY9KqBz3agACwg8YaM +Jf+fC/Kif9d3AIAAAEX3h9iQuASjX/Cpic93gADYKLh1BL2lZwQlvp8AAAADG/LpvQXyi9iQuASj +TfCI2JC4BKOgyoTgR/TPcoAAtAgAgs9xgADACA8gQAEAogCBAeAAoTnwBCC+jwAAQRAN8ooPQAPz +EgG2VSHDB5QZAACcEQIBCvAQhgLfz3WgALAf+KWshlKSumIQcsb3BdgYuIwZAADlzea4F/QAkYDa +CSIBAM9woADUBxkQAIYwcE33A9gYuASjz3GAAGgqoBEAAAHgoBkAAFUCj/7gePHA5gmv/ghyAdmB +4ADdIPTPdqAA1AcxpgPbcqbzyVUgzweQEAAABCC+jwAAgAYH8s9woADMFyEY2IAFh+i4B/LPcKAA +zBe0GMAAsaZRIIDC/vUwyM92oADsJ4C4BqY2yM9zoACIJAumL6MY2BGjz3OgAMgcguIxyAf0SIOE +IgMARXgIowPwCKOnoy/Iz3KAwAAAC6bPcKAA0BtQoDPIBqPPcKAA0A81oKUBj/7xwDoJr/6KIBIN +z3EAABgN4gmP/s91gADcBQeFgOAO8utwz3EAABoNz3KAAFRBANu+Cq/+SiQAAADfjr/PcKAADCTv +oDGAAdogtUHeCL7PoDGAIbXPcYAAqDFhiWGlY4lipc9zAAAC0m6g/9twoM9zAAAZkG6gANuMu3Cg +0tsIu26gCNtwoO6gz3MAAP//cKDOoHCgKsjPc6AA7CfguEelB/LPcEMACgEHo0PYBvDPcEEACgEH +o0HYAanPcB0ACgMHox3YA6nPcaAAiCRPoQDYEaHRAI/+4HgQ2gAfgED2EgK2CHEAH4BAQIEAH4BA +QYEAH4BAAoGRBI/+4HjhxQvbDLsA2kh1C/B8e1t6cHBQeoT2YngQeIC6AeWM5bb2gOAD8gHiUHqD +4ECxBPaA4AT0ANgD8IDYwcXgfuB48cDqD0/+ocEacCh1WnLPcKAAyB9IEACGOnN6cFEgwKGEIwMg +A/Ko/wjwAdjPcaAAiCQPoQbYEaFRIwDD/vM0yM9xoADsJwuhRCCAoJpwz3agAAwkRCAPJh7yRCUB +HES5z3AAAAKCHqbPcIAAsAU0eCGIz3CgAIgkIaAFv0QgASEIuQHaj7pepuV5pXkhoAraA9kU8Lx5 +z3AAAArSDqbPcIAA0CM0eAGIC78QpgHYj7gOpvCmBdoA2TLIRXgFIMAEz3KgAMgfSBoYgEYaWIAD +2c9woADUByygLaDlzeu4EfIhyPYSELb2Ghiwz3CAAIRNq//lzfYaGLSruOUaHLDPcYAAaCqQEQAA +AeCQGQAAz3CAAIwGAICA4Afyz3KAACQtBYIicAWiTCQAoDXyAtiPuB6mz3egAIgkBB+AFEAqwSCU +5TB4DvIH9orlE/QAHEQwFPC35Qjy7uUL9Itxmf8P8Bx4CvAbeBB4i3GW/wbwz3AAAP//ABwEMADY +ANmPuT6mABQBMYK4IacD2Y+5PqYBpw3wANiPuA6mDL0FJYAUEKYB2I+4DqaAv/CmlQZv/qHA4cXh +xvK4BfKGEgK3DPABgee4BPJZkQjw2cnPcoAAeFgWekWSz3OgALAf24PzyZQQDQDTvgkmTROYGEAD +mBEOAIDiySaCEAPYELgVo89xoAAsIBOBoWgIJk0TAn2woQDYkLgUo8HGwcXgf0hw8cDaDU/+5RIN +t/MSAbapcIQgPwLlGhywANh+GQQAAYHuuHsSETcE9KC9sH1TJX6QlgIBAM9ygABoKrgSAAAB4Lga +AABoEQ8Bz3CgAJgDA+fegAQnjx8AAPz/+GZCDa/+BOD3EgG28xICtqAZAABhgu+7z3OAANwFFvIF +gwHgBaMBkoDgWgAsAADbALEJggGhMLgIqQmCKLgJqQmCOLjCuAupHvBGg0znAeJGo89yoAAUBEmC +UHcA21P3z3KgAJgDHqIAFgJAQKEAFgJAQaEAFgBAAqHPcKAAmAPeoAHbgOMa9OK94gEBAM9yoADI +H6QSAQDzybASAgCcEAMBQntcEAIBACNABIQiwgd6C2//qXO3AQAA9xICtmGC57sE8uS9pgEBAPMS +AbYBge64ViKIA0PyhxGAAMuKFxgCEMK+z3GAAHBAyWFVIsUHmHFsGkQAz3GAAHhA8CGOAwQgvo8A +APAAkBqAA1YixwNEIwYCBPTguD70gL4UHYAD7hKFMEwmAIAEJQ4AEh+EA0EujxACLtBzAADAAADZ +NvLmuzDZBHlEuRby2WEvec9zgAAoQPQjTgAIcT7w5LsI8gmKz3GAAN4oBLgIYbnxCIq38UNxtBGB +gEQhAwxEuwQlTgDbY297z3aAAAhA9CbOECTwAN8SH8QDgb4UHYADcBIQN0wmAIDpcQT0KHYW8Oa7 +HHkJ8i95z3OAAOg/9CNOAAhxCvBDcawRgYDPdoAAyD88e/QmzhAQGEIQQJIEH4QDACSBACYMr/8w +efcSArYCcHoaBAB8EgEBehIAAThg8xIPtpwaBADPcaAAyB+wEQMAnBcAEWJ4eBIONyJwnBICARtm +W2OkEQEAcHtwcVYnxBNS9+K9HfJcFwIRBCKCDwAAn//mCW//qXPlzYm45RocsA/w2mIGHIQAz3GA +AGgqvBEAAOUaXLMB4LwZAAB1A0/+4HjxwBYLT/7PdqAALCDwhnOGhOAV9PMSAbblzW4RAgHkuFYh +wQMG8gGRYngCJwMQBfBjkQKRG2OhkULwgeAj9PMSDbblzUAlBB9wFQIR5Lh4EgE3CfI6FAABInhi +eAInAxAK8HgVABF6FQMROGB4YHwVAxEbY3gVABEZYToUDQFCfR/wguAZ9PMSDbblzXAVAhHkuFYl +zRN4EgE3CPIAlSJ4YngCJwMQBvABlWKVOGAbY6CVQn0F8ADbaHJodWhx5c3huPUSjzAI8vPJbhAC +AeJ6OmIH8IDj4noD8nvMGmIThl1lAn0E2M9xoACwHxihDYaxcA/3CtgVoQDYDaZNpgDajbrPcKAA +0BtToAjYFKFxAm/+cHjPcIAAnF8mgIHhANgD9ADYjLgD2c9yoADUBy2ihSACDQ1xALHzyRuQALHz +yQ6A4LgA2wbyJMgAoUrMBfAAofPJHpAAsfPJEIAAofPJRBAAAQCxbKLgfuB48cCqCW/+CdgMuM9x +oAAMJA+hEYEvJgjwANou8irIz3MAAAWQ4LgN8s9wAAAEkA+hUYFvoRGBD3gQuBpiD/BvoRGBz3IA +AAaQT6FRgQQggA8AAAD/KLgIuhpiBCKAD4AAAAA3uCy6geDFIoEP//8A8IAiBADPdYAA3AVhhc92 +oADsJ0ArAASFIIQCB6Zve89wgACoMWGoYoUXukArDwSFJ4wS56Zve2OoANiOuA6hAJUQoUHYCLgO +oQGVEKEA2Aelz3GAAIRNAoFFeEkBb/4CofHA1ghP/gh2GnHPcAAAECcGDSABANnPdaAALCARhTOF +InjzEgK2BPDlvjn0z3GgANQHLIGA4QXyUSMAw/bz88mEEAAB57gJ8s9wgADcBQeAgeDgDsH/USBA +wgX0USMAw0byhNnzyZG5jBhAAAHdqXCh/YogCADkGhywz3GAAIRNAoHWuAKhz3GAAGgqxBEAAAHg +xBkAAKlwN/BRIYDDyPMxhVYiwwOcEg4BAnkifs9xoACoICGB2WHPdoAA5D7hjjB3bAfm/wDeBpPn +uAjyz3CAANwFB4CB4FgOwf/PcYAAhE0Cgda4AqEC2A/wANiC/QTZz3CgALAfNaA0hTB5GgwgAQpw +ANg1AE/+4HjxwPPJhBAAAee4CfLPcIAA3AUHgIHgEA7B/wHYc/3PcYAAaCqcEQAAAeCcGQAA2cnH +cIAAGFcoEIEAAeEoGEIAKBCBAM9wgADkPgKIMHBF9oogCAAP8OXN5rgF8kYOQAIH8APZz3CgANQH +ExhYgIogEADRwOB/8hoYsOB48cDhxfPJVSDCB5AQAADhuATyXBIBNwTwXRIBNwOCl//huAh1B/LY +///Y4g8v/qlxPfDlzea4BfLuDUACB/AD2c9woADUBxMYWIAg2OQaHLDPcYAAaCqsEQAAAeCsGQAA +88mHEIEAQJCGGEIAihABAYQYRABsEAEBWWGCGEQAkBABAHgQAgGsua25tbmQGEAAdhABATpinBAB +AUJ5nBhEAADZeBhEAHYYRAAhBw/+4HjPcIAAnF8mgIHhANgD9ADYjLiFIAMBA9nPc6AA1ActowAY +BFDzyQDaG5AAGARQ88kQgAAYAFDzyUQQAAEAGARQTKPgfvHAXg4v/phyCHXluNEhosMX8s9woACo +IAGAz3KAAOQ+QYp4YBByTffPcYAAaCqYEQAAAeCYGQAACdgYuGDwAtjPdqAAsB8Yps9yoAAsIOyC +gudN9wyiAdgUpgDajLrPcKAA0BtToAbwGKbsgoLnPvfmvRLyBCC+z4BAAAAM8s9xgABoKpQRAAAB +4JQZAAAR2Bi4NvDPcqAA0A8A2BWiNsjPdqAAxCeLuBWm4b3PcoAAqDET8kQhAAxEuM93gACwBRR/ +4I9ALwAURSCAAhGm4KqKIEwCD/A8eM93gADQIxR/4I9ALwAURSCAAhGm4KqKIEgCEKapcIhyWv0A +2MkFD/7xwF4ND/7zyZAQAQBqEAIB4LmHEIEAAd0M8u7KwN4keCK4Gn4ocLoNb/9IcdhgEPA3yADe +DyYOEHASDzcB4lB6KHCeDW//SHH4YMJ4EHgA2pm6z3GgANAbU6HPc6AALCC1o1EjAMT/8zODz3Kg +ALAfuKKqg0uDIni5YLFxQvcB4gAYQFAAGIBQ5c3muAbyqgtAAqYLQAIO8AAWAUAAFgBA88nPcaAA +1AdoEAABaLgPofPJaBABAWi5DQUv/mgYRADxwM9wgACcXwaAgeAA2gT0ANqMuvPJGpBFeA1xALHz +yRuQALHzyQ6AAKHzyR6QALHzyRCAAKHzyUQQAAEAsfMSArYakkQgAAOE4AzyEoIAofPJTBAAAQCx +88lQEAABALHzEgO2iiAMAFqTRHiMIAyAB/QVgwCh88lYEAABALHzEgK2GpKEIAIDjCACggT0XBIA +AQCx8xICtpASAADmuAfyAYLwuJwOwv8O8BiCAKHzEgK2kBIAAAQgvo8AAAADBPIZggCh8xIBtpAR +AADouAjyQCEADWoRAQEeDIAA0cDgfvHAwgsv/lUhwweQEQ4AQCEND+C+ViHCAwnyW8yAvhm1CZLF +o4G4CbIF8FrMgb4ZtcWjAYEEIICPAAAAD2mSDvQJic92gADYKAS4AGbluATyhLsG8IO7BPAluAV7 +hxGAAGmyhhkCAACROJVmsjhgBbIA2ACyHbXPcKAAFAQJgLTgTfflzc9xgADcBYQgdw3lGhywA4EB +4AOhPPDPdaAAmAPehffJoBABAD6lZghP/h6F9xICtqAaAADepc9woADIH6gQAABhglUiwQfxu6qC +B/KEEgMBh7uEGsQAjCX/nwHbB/KieNdwAIAAAEP3ANsJis9ygADYKAS4AGIEIL6PAAAAAwPyANuA +4wTyBYGauAWhHQMP/ghx2RIDts9wgACYV1kgggP0IsIAQLHZEgO2WSDCAmpi8xIDtkKpSItDqdkS +ArbwIIAAAaGMEwIAUHpCofLJBCCADwIAQQDXcAIAAAAD9Ii6QqHyyQQgvo8AAEEQA/KJukKh2ckQ +uEV44H8CofHAPgov/ghy2RIOtgDdz3OAABhXFCOPA/MSAbagtwGB7rgD9Ki332MgH0ITz3CAAJBX +1Hi0sCgfQhPPcIAAeFjWeOKQz3CAAFRX1HjusNV7gBtAAwGBBCCADwQAACDXcAAAACAI9BqR6rgG +9HbMEOB2Ghww5c3muAfypBEAACGAYHlIcBbwA9nPcKAA1AcSGFiAENgAHwBA9skAHwBAAIIAHwBA +AYIAHwBAAoK+DA/+9hIBtkIKL/7Z2O0BD/7gePHAegkv/oHZF7nPcKAA0BswoOXN8xIBtua4VSHC +BxLyz3CAAMQrCqIocK4OIAIN2cnYBgov/gDZ8snzEgG2IPDkzQPf4LjPdaAAFAQB3sxwG/LPc4AA +sCtqouKlxKUAgPYaGLBqDi/+KHDPcKAAmAMegPMSAbagGQAA8snZEgK27glP/xvw4qXEpQCAz3OA +ABhX9hoYsEmCz3CgAJgDXqDZEgK2QCMABPQggACA4Af0hxGAAFtjMBsCAPPJAdmMGEAAigxP//MS +A7aMEwAABCC+jwEBAAAu8vy4BfS+Dm//ANjzyVUgwQeMEAAA8LgN8oogCADkGhywJIH62M91AACw +B2MBAADlzea4BfJGDwACB/AD2c9woADUBxMYWICKIBAA8hoYsPPJjBABAPvY6PHtzc92nwDY/xCm +hBMAAYYTgQCCEwIBnBMDAQ789hIBts91AACwB2B9ztjZEgG2ANogyA8iQgBGeCAaGDDPcAAAhA4S +ps9wgABIQPAgQAATpgDYmLgRpvLJBCC+jwAAARAZ8vMSAbZn/PMSAbaA4EGBCvLnuuXNBfJFIIAE +AvCBuOUaHLABge64BfLlzYC45RocsPISAbZgfczY88mkEAAAAIBAePPJkBAAAPW4CgEBAG/88hIB +tmB91tjzyZAQAgBFIgEE7LqQGEAAIPJgfc3YAdga/fMSAbYbsV3988nZEgK2dhABAXgQAAHPc4AA +GFc4YFV7gBMBADhggBsAAAD+8hIBttDYF/BgfdHYAtgL/fMSAbYbsSb+8xIBtogRAABwEQEBlP3h +uAjy1v3yEgG2/NhAfZsCAADzydkSAbbPcoAAGFc1eoASAQB4EAABOGCAGgAA0thgfQDZ8xIDtooT +AAFsEwEBhBsEAACTOGCCGwQAhBMAAYcTgQCCEwIBehMDARz+CHbP2GB9yXH4vhXy5c3muATyjg0A +AgjwA9nPcKAA1AcTGFiAiiAQAPIaGLD92Mlxv/HzyZAQAADkuAf0K/zyEgG2YH3b2PMSAbaQEQAA +BCC+jwAAgAYF8uIJgAAR8Oi4BPK6CoAADfBoEQEBz3CgANQHL6DPcaAAyBwA2Aeh8xIBtpARAQBg +fdPYz3CAANgrIJBEIQADhOAG9AQhvo8AAKAAB/QE2MT88xIBthuxYP7zyaQQAQAjgWgQAAFAeQh2 +1Nhgfclx8xICttnJfBIPAXoSAwHPcYAAGFcVeYARAAD7YxtjBCa+nwIIAACAGcAAKPKMGoAD8gtv +/wHY8L4J8oogCADkGhywiiBEABPw5c3muAXyigwAAgfwA9nPcKAA1AcTGFiAiiAQAPIaGLCKIIQA +YH3Jcfu+xA2C/w8BAADlzea4B/QD2c9woADUBxUYWIABguO4DPKQEgAA4LgF8l0SEDcG8FwSEDcE +8G4SEAHlzVMgfoAE8ue4BPLpuAzy8hIBtmB91djyyfcSAbbZEgK2X/7PcIAAhE2i/s9wAAAQJ2YJ +4AAA2c9woAAsIDGAE4ACefPJmHBWIMIDihAAAUQgAwgD8OW7Q/TPcKAA1AcMgIDgBPJRIwDD9/NR +IEDCBPRRIwDDTfIA2pC6VSTBB1EgQMKMHIAACPID2BC4BKGKIAQAYH0A2d4Kb/8B2PPJhBAAAee4 +CfLPcIAA3AUHgIHgAAuB/89xgACETQKB1rgCoYogCADkGhywz3GAAGgqwBEAAAHgwBkAAOEEz/1R +IYDDvfPPcKAALCARgHKSIngCe89woACoIAGAeGDPc4AA5D7hixB3Vgfm/wDbWPAEFAAA47gp8tfY +YH0A2bIM4AGA2PISArYEIoIPAgABCNdyAgAAAOUSAbcF9P24A/KDuQLwo7nlGlywCNjkGhywz3GA +AGgqrBEAAAHgrBkAAPPJiBAAACfwENjkGhyw5c2juOUaHLAGkue4CPLPcIAA3AUHgIHgLAqB/89w +gACETWT+9hIBtmB92NjzyQGA7rgK9NnJAdoAIIEPgAAYV2gZggAA2Apxs/zhuAh2B/L0/P7YfwTv +/8lxz3CgACwgcYDZEgG2huEF8s9wgACcX3Wg88lYkNdyAAAAgAP0AtpYsM93gADILMGHAocEJgQQ +ANgPIEAACyQAgAjya6cA2Y/mKacC9Cqnz3GAAJxfzoHFeA6hz3CAAAwt8CCAAFKBeGACIIMA/7sC +9BKh5c3juPISAbYQ8mB919jPcIAAkE3zEgG2BYiHGQIA8snZEgK27gsP//ISAbbbA+//3NjgePHA +L9ieuM9xoADQGxChz3BeAABAE6HCCcABENnPcKAAsB80oNHA4H7xwLoK7/0D2M92oAAUBAOmz3Wg +AJgD/oUKIIApABYRQAAWAEFAIBIOWgov/kAnAB4epQAQACEIcYQhAgOMIQKCA/QB2QLwANmEIAwA +jCAMgAP0AdgC8ADYByB+gMAioiBAIsAgBCCADwAA/P/+pSmGEHG/9w4KL/74YB6lA9gCptrY/grv +/SpxjQLP/fHALgrP/a3BCHbiuADdEPLZyUoiACAPIhIgz3EBAQAAACkRABkBIABKIEAgz3GgANQH +AdgUGRiAA9gTGRiAABYBQAAWAUEAHEQwABYBQQIcRDAAFgBAQcAEIJAPAAAAQFp1xf86dWzwABYA +QEQmjhb2GhiwFg/v/YtwAcDhvgQgkA8AAABACvLkvgX0jt2QvTHwht2QvS/wgOcF8ozdkL0p8AkU +gDAEuMdwgADYKCCABCG+jwAAAAMJ8um5BPKL3ZC9GPCI3ZC9FPAikAoUgDARIQCABPKN3ZC9DPDP +cKAAyB+oEAAACsEwcMX3h92QvQHegOcD9IDmHPKf/xDYAB8AQPbJAB8AQADYAB8EQAAfAkAiwAAf +AkAA2AAfAECweNkSDbYQvQV9Pgzv/alwCPAD2c9woADUBxMYWIAKJwCUlPVEJv6SCfLPcKAA1AcZ +EACGgOCK9eG+CfLPcKAAwC+lEAGGCyGAhIDz6dgiCC/+BLgEIEAEMnDwBsL/DQHv/a3A4HjxwLII +z/3zEgK2AN+KEgEBz3OgACwgRCEOCDGDc4MCIdAAkBIBAOm56XUT8iGC7rkJ9IwgAoBG9zoLYADp +cAPwAd0B2c9woADMFxYYWIAB2M9xoADUBxOhA9gQoRDwgOUM8hILYAAB2IDgCPKD4MongR8DAIQA +AN2A5gz0USDAwu/1USBAwsongh8DAIQAOPBRIYDD9PPPcKAALCAxgPPJAiEBBJwQAAEieM9xoACo +ICGBOGDPcYAA5D5BiRBywAfm/wDe2cnPc4AAaCrHcIAAGFcoEIIAAeIoGIIAnBMCAAHinBuAACgQ +ggACiVBwRvbPdwEIigAE8AnfGL8ZAO/96XDgePHA4cWjwYt1qXBA/fPJpBAAACGAYHmpcBEA7/2j +wOB48cCWD6/9LNrPdYAAGFfPcYAAyFciDe/9qXDZEgO2ANoUJc4Q8xIBtkC2AYHuuAP0SLZ+ZSAe +ghDPcIAAkFd0eFSwKB6CEM9wgAB4WHZ4wpDPcIAAVFd0eM6wdX2AHYAQAYEEIIAPBAAAINdwAAAA +IAj0GpHquAb0dswQ4HYaHDCBB4/98cDPcIAAyFfPcYAAGFemDO/9LNrzEgG2AYEEIIAPBAAAINdw +AAAAIAj0GpHquAb0dsxwuHYaHDDRwOB+8cDSDo/92cnPcYAAuFf0IQIAzHEAkfMSA7ZFeBqzAJFA +Iw0PG7MAgVqTDqMAkUQiDgMeswCBz3eAAJBNEKMAkYTmRBsEAAf0ENgXtQDexaci8ADYi7gFpxjY +F7UAgRKjAJEIteCRAYPtuOq1BfJ2zMO/5XgKtYjmGNgO9Eh2hCYMEIwmDJAI9B7YF7XAgdWjwJHO +tYQiAgOMIgKCBvRCaFB4V7VAkQPwANrhuFC1A/JAkUCTAnqQEwAABCC+jwAAAANWtQfyAIFouhij +AIFWtRmjaQaP/eB48cD+Da/9ANjPc4AA2FgG8AHgCHKHukepn+AWIwEAuvbA2AepgN3PdoAA/AWg +rs9wgADYWalxsg+v/alyLQav/aGu4HiiwUEoAQIHeTC4J3jGuOB/osDgeKLB8cCeDY/9CHVods9z +gAD8BYDiRcEH9AGLgOAA3yHy4aupcPL/mHAAi+a4UyBPAQPyAN8V8M9wgADYWPZ4J4igoCCrFBQB +MUaoIrAAJIEPgADYWUCJR6jgqeCuAd8M3KsFr/3pcOB4osHxwAhyDMj0uELBBvLPcIAA/AUBiBvw +SHDb/89xgADYWQlhCBQDMQLwJ4jnuQ70z3CAANhYNngggFBx9/UikDBz9fUGiAPwgNjRwOB/osDx +wOoMj/0IdSh2meBId4v263CV2c9ygABfQQHbgg6v/Zh1BL3HdYAA2ChHjYwiw48D9ADYDfDPcIAA +2FgWIIEAIIEgpieNNngCkAC3AdgFBY/94HiiwfHAkgyv/QhzRcGYcrX/x3CAANhZFBQPMQPwB24g +iOe5IPTPdYAA2FgWJU4QQIZwcvb1QpZQd/L15o7Pc4AA/AWA5wP0gNpBqwAcwANHjjZ9QKgAi4e5 +B60gqwHYA/AA2AzcmwSP/fHAKgyv/QHZocHqCO/9i3AgxQEUgTAadc9wgABYWoDlIKAE8oTlzPfr +cGXZz3KAAGxDAduuDa/9CiQABADeNvAAFg1Ar32D5cr363Bp2c9ygABsQwHbjg2v/Zh18m31f8d3 +gABYWgRvigjv/QXZz3CAAFhaIICB4QGHBPSF4BXygeEE9I3gEfKF4QT0kOAN8oDgC/LrcHPZz3KA +AGxDAdtCDa/9mHUB5hJ2mAfF/w4Iz/3dA6/9ocDxwHYLr/2A2M92oADIH0keGJAAFgFAz3egAMwX +HR9YkAAWDUCA5Qv063CW2c9ygABsQwHb9gyv/Zh1Fx9Yk1oeWJMD2CAfGJAB2FkeGJCA2EoeGJCu +D4/9hQOP/Q97SLgPeM9ygABsQfQiAABAKAECSLgFeTB59CLAAOB/J3jgePHA7gqP/aXBCHYCiyh1 +GnBkwACLABIHATpwERwCMAISBAEEEgUBBJIGEgYBEBQBMRlwOGAQeDlwIJXPdwAA4FNgfyd44HAv +JwgAAZVgfwcgwAGAcC8iCBAClWB/ByCAAqBwLyMIEAOVYH8HIMACwHAvJQgABJVgfwcgQAEBcC8k +CAAFlWB/ByAAAQAgQQJGlTB5J3pceA+6RXgAIMIBUHhnlQAchDBneBx6D7gFegAigAIQegIcBDBc +eA+6RXhhcBB6BBwEMFx4D7oFeqByUHgGHIQwHHoPuAV6ACIAARB6CBwEMFx4D7pFeBlhMHgKHEQw +KnHGuYW5QCkCAgUiQQQgtiCVJ3gceAi4BSAABAG2AMABpgHAAqYCwAOmMQKv/aXA4HjxwNIJr/2Y +c6XBCHcodgDdBCOAD/8AAAAYugV6b3gIuP/bCLsEJMEAKLkleAV6F/D0J0ATR3hEwBAUADGf/0Ao +AQQleBIUATEUJEwzJ3hEwBAUATEB5SC0CHKI5ar3UyTBBSCmoJcH2AbwUH0UJgwQQLRhuLt7T730 +JAIwpXtwe4HgemIz9wQigA8AAAD/ELgFeSCmpQGv/aXA4HjxwDIJr/0ocg8SjjAIdQMSDzYmvmCR +178EI4APAAAAD0EoBAJTI4AAg+AQ4R30kHZiihj0EMoQcw30z3OAAPRJqXAE4n//DMiYuAwaGDAN +2lvwC8iRuJK4CxoYMADYXPALyJG4+vGF4EQjAgIq9PDNgOJCKBACG/TPcIAAWFoCvtV+HmYhhpDh +7PUAgIXgDPLrcIohBwTPcoAAbEP/204Kr/2YcUAmARID8JB22vUocKlxUyBCIOlzq/8MyJm4x/GA +4gry7LsE8g3aA/AF2pB2DvLI8QK+1X7HdoAAWFpBhoXiQCYBEgTyjeK89QzIlrgMGhgwAIEFf+Cl +AYEBpQKBAqUDgQOlA+LPcKAAzBcPGJiAAdiBAI/98cAeCK/9CHGkwc91oADIH4DYSR0YkM9yoACU +EwDYG6ID3892oAAQFOOmi3Cv/4DgBvSA2EodGJAA2BvwAdkrpgDAz3KgANAPB6YBwAimAsAJpgPA +CqbkpgDYAqYdzBYaGIAApgTYRx0YkOWmKHAZAK/9pMDxwKoPT/0D3s9yoADMF4gagAPqaQi/z3Og +AEgX8BvEA+CQBCePH///j8fwG8QD4YD7ouSQ8BvEA+OA+6LokPAbxAOEGoADxYDbosyQ8BuEA86Q +BCaOH///DwDwG4QDwJCEJgwQjCYMkADdB/TIgNuiUpDwG4QAQJDnugbyFJDDuPAbBAAA2AXw8BtE +AwHgTiECCFx6EHI693kHT/3xwA4Pb/0IcQ8SgjCkwQCQJroEIIAPAAAAD0i4EHIA3QfyC8iRuAkB +IAALGhgwQNrPcKAAyB9JGJiADMjPc6AAzBeXuAwaGDAI2B4aHDAdzELaaLiAG0ADIN26o1ajHBIC +Nx0aHDDYckJ9DRICN7B9umJsulmjR4FQo0aBUKNFgVCjJIEEEgI3MKPDuvYSAbcIuhC5JXr4EgG3 +9xIOtxC5JX4SEoEwExKNMAi5pXkREo0wDBKPMBC9pXkQEo0wCL8YvaV5DRKNMEUiRQDlfQUlhB8A +AQAAhSJBBg9/GL/lfQQggA8AAAD/CLileAHdkBtAA0QbAAESozGjMqPRo9KjRBtAAVKjCNjPcaAA +yB9HGRiA+M/IcZT/HczPcaAA0A8WGRiADMiXuAwaGDCpcEkGb/2kwPHA4cV2aMdzgABYUC1yoIID +Glgz7HGgoR0SDTdkvR0aXDMMEg02470M8oDgCfQPyia4BbgAIIMPgACYVgLwIOOgk+u9BvILyJG4 +CxoYMBjwUyW+kBTyD8rluA/yAIIEGhgwAKEdzGS4HRocMACT4bgB2Af0BPDhvQHYA/IA2IDgCPIA +k+C4aHAD8k3/AvCQ/8EFT/3xwD4NT/06cPPJz3WgABQEwYUgkGoQAAE44UQggAA4YBpw2GDeDK/9 +aLhMIUCgCHcR9CCFMHbK99nJFSIAMNoQAIbCeBlhA/DCeRJxQ/cA2Bfw7qXzyQeADaWqDK/9BG8O +pfPJwn8IgA2lz3CgAJgDHoDCePFwhPcD2APwAdghBU/94HihwY3gQMEE9BDZA/AH2QIUADGMIMOP +CvQAFAAxMHAG9oPghPYB2APwANjgf6HA4HjxwJIMb/2A2M91oADIH0kdGJDzEg+2ocGQFwAQ57hV +J8EXJPJLj892oADMFyO6wLoDugXiA9ggHhiQFxYDlkhwaHHk/4Dg+PXzEg+2z3GgABAUA4dleBge +GJALj4QgAwAYuGV4GKcW8EOHz3CgAMwXGBiYgAWB6rjPcaAAEBQJ8guP17qEIAMAGLhFeBinDdoB +3s9zoACUE9ujA9gDoQPiXKPLoUSHSKFFh0mhRodKoQShANpBoWgXAhFeo2gXAhHPc6AA1AcE4k+j +Rx2Yk5AXAhDpugL0BaEhBG/9ocDgePHAsgtv/UDZz3CgAMgfSRhYgM92oADMFwHYgB4AEPPJINom +gC2mJYAtpiSALaYjgC2mQtk0plimaBABAc9yoADUByDhN6ZoEAEBCOEvolwQAgFAEAEBw7oIuhC5 +RBADASV6QhABARC7ZXlmEIMAZxCNAAi7ZX1lEIMAYBCPABC7ZX1kEIMACL8Yu2V9YRCDAEUiRQDl +ewUjjw8AAQAAmHJoEAABhSRBBg96GLplegQggA8AAAD/CLgFegHYkB4AEO6mT6aupq+mLqYvpjge +QBE8HgARAtnPcKAAyB9HGFiAOQNP/QDYC/AA24u7NWgAIYIPgACYVmCyAeCE4OAgxgf08eB4gNjP +coAAWFoAogDZB/AA2xJpFXhYYGGgAeGE4eAgxgf38eB48cCOCm/9ANiPuM91gAAUXM92gACsWhi1 +yXAGDK/9iiEGAADZC/BBaQUigw8AAACAFiZAEMMY3ABIcYPhtfeA2I+4F7UA2c9wgAAABiCgz3CA +AKxapQJv/dwYXADxwDIKT/2P4Ah1FPIXbc92gACsWthgrguv/YDZz3GAABRcGJG2fo+4wx4cEI+9 +uLFtAk/98cDuCU/9WnAacc9wgACsWswQAAc6cue4D34E8oDeKfDPdYAArFrWfcMVDxfvvwv063Bm +2c9ygAB4QwTbcgtv/Zh3wxUBF89wgACsWswYXAAA2sMdnBDPcYAAqFzWeYgZgoSJGQKEwB2cEMEd +XBTdAW/9yXDxwHYJb/0ocwh2UyLSAMO5PHjHcIAA2Ci0bgjgqGDAuwK7enjDuBpwz3OAAKxaFiMT +AMATDSeP4EIqEQFh8s9ygACoXBZ6iBKAgNFwBfSJEoCAMHAK8utwiNnPcoAAeEMB29oKb/2YdsET +AScCIUAgUyDBAsDhcgAFAD/aAiGAIMu4QnmJIQEA4LnBGxwgDvJAKMAhtHgA2wAggg+AAKxaYLJh +uQHlxb0A2hbwQCjAIVMlQxEUIM4AAeUA2893gACsWv5mYLZTJU4R1HgB5R9nYLcB4j14UHAq98W9 +CW3FuMAbXCMD8LhhxbhAKMIhFHrHcoAArFoAkg8ggAQAstEAb/0KcPHAhghP/VEgwMb/87YKQACA +4ATyANhx8C11IIUkyPsaWLBAlTBw+BqcsAn0SsxQcAX0DMiUuAwaGDAocA4Lr//8EgG2CHErGgIw +BCCDjwAAgAAMEgI2CvILyJG6lLiVuAsaGDAMGpgwwIXPcIAAIFzKoB3M6LpquB0aHDAAhQ0aGDAo +8iy+gONTJsAQB/ILyJS4lbgLGhgwFPAdeMdwgADYKAS5COAoYMC+Ar7aeMO4j+AI8s9xgAAUXBmx +lNgD8NTYdg5gABB41g2v/gDYFPCOutoPIAAMGpgwagogAPvJC8hEIH6FXAsCAADZz3CAAEhQIaAB +2P0HD/3gePHAhg8P/c9xgAAUXLmRz3aAAKxatn7AFgQXwRYDF/nJDXIAovTNALLPcIAAIFwKgACi +O5FEuQIhwADLuOu4JPIOIIEPAAAAEIkhAQAwewDYB/D/3+Ci4KLgouCiAeD7axB3OfcA2AXw/9/g +ogHgUyGPAPx/EHc69+C5ANgK8v/ZILII8IkgAQAQeMEeXBAA2w4ggQ8AAEAAAiHBgAAgAwFTI08B +wB7cE0AtxhEN8uC7C/IUJsMDz3WAAKxac2UB52Cy8H9huQAmgw+AAKxa/H8A3RvwUycOEfAjjgMB +58CiUycOEfAjjgMB58CiUycOEfAjjgMB58CiUycOEfAjjgMB58CiAeVBKc4AsXYk9wDdBvDwI44D +AefAogHlUyGOAC8lggNTJwQRsHWIdrP34Lnbfgby8CMBAQHmILKA4BDy4L4O8hQmgQMA3wAhjQ+A +AKxa4LXgsgHmYbgQeN1+ANke8KCiUyYPERUjzwOgpwHmoKJTJg8RFSPPA6CnAeagolMmDxEVI88D +oKcB5qCiUyYPERUjzwOgpwHmAeG7aDB1wgft/wDdCfAA3+CiFSNBAOChAeYB5VMgjwD8f7F3UyYB +ETT34Lg7eQXyANgAsjR7ALMdBg/94HjPcIAASFA9B2/9ENnhxc9xgAA0X4DgJYEn8s9yoAAsIHSC +QCiNAg7McHt4YAoSAze7Y/USjTCiewgjAwACewkhwQAA2427z3CgANAbc6AtomLZz3CgALAfNKAk +EgE2z3CAAEhQI6DBxeB+4HjxwEINL/2YcM91gABIUCGFDMihuSGl+HDuuAoSCDcH8vHNACACEFB6 +AvAJcvXKUSDAxgJ6UHoF9FEggMb+9QDbjbvPcKAA0BtxoM9woADEJxeABNvPcKAAsB94oM9zoAAs +IBSDDhION+2D2GAfZ/DNLyXIA9hwhCDOC4wgCorgtQ708c2A4Az0JBIPNvnJEHcG9EoSDzf0zRB3 +C/LIcIQgwwuMIAOJCvRRJwCFBvL0ygIgAhBQegTwsHLE9oG5IaXhuR3yFIMA2Y25z3egANAbM6fZ +YDB5CSGBADB5AiJPAO2jYt/PcaAAsB/0oTSDEHHq9QOFDB0AEQKlsQQP/eB48cBCDA/9z3OgACwg +NIMOzBlhC8hEIH6FMHkw8uC4A/IA2eK4BPIMEgI3BPAKEgI39crPdaAAsB8CegTYGKXPdoAASFAB +huG4UHoG8gCW4objpgXwDYM4YBB4CCCAAADejb7PcKAA0BvToAkhgQAweSJ6TaNi2BSlMQQP/fQS +gjBZYTB5QWkQckT2IngQeAPwAtjPcaAALCAMoQHZz3CgALAfNKAA2Yy5z3CgANAbM6DgfuB44H7g +ePHAigsP/QzIz3KAADhN4LgZ8s92gABUTQCOYo4A2RDwpG70JU8Qz3WgAMQnMR3YkzMVDZYUIkwA +pLQB4TBwMvcY8M92gABsTQCOYo4A2RDwpG70JU8Qz3WgAMQnIR3YkyMVDZYUIkwApLQB4TBwMvfg +uAfyAeAA2RQiDAAktBt4AKpxAy/9YaoD2gDZz3CgADAQQqDvGkIwAdnPcKAAtA88oOB+8cDqCi/9 +BdgA3Qu4qXHF/wzI4LgEAQEAC8jguPwAAQDPcQMAQA3PcKAAqCAgoM9ygADEBSCCAWkAouIML/1I +2BcAAADo/ybYCiQAcOB4qCBAAeB44HiE5c4ABgAEIL7PgEAAAAP0AeUC8ADdUSMAwyf0z3CgALAf +G4DTuIrgQgAOAFEggMcG8lEhQMSaAAEAUSBAxtEhYsSuB8H/z3EAAAGBz3CgAMQnMRhYgDMQAIZE +IMAEg+CQB8L/bwAAACoPz/9nAAAAUSDAxSbZA/QB5gLwAN5RIwDDFgACAAokQHDgeKggQAHgeOB4 +MwAAAM9woAC0D7ygCiRAcOB4qCAAAeB44HgD2c9woAAwECKg7xpCM4og/w8N8ADehOZF91EggMem +B8H/BCCAT4AAAAApAg/94HjxwLYJL/0S2ADez3WgALQP3KUKJABw4HioIAAB4HjgeAPZz3CgADAQ +IqAB2BylC8jvGoIzgLgLGhgwlg7P/+UBD/3geOHFz3AAAANBz3KgAMQnIRoYgCMSAYYA289wAAAB +gSEaGIAjEg2GMHnvvWhwAvQB2CEawjDPc4AAOE0iq0QlARxEueK9IBpCMAPyAdkC8ADZDhpcMIHZ +CLkhGliAIxIChlB5TLkeGkIwy7rguQ0anDAC9AHYwcXgfvHA4cUIcgXbANjPdaAAsB91pc9zoAAs +IAyjAiJAAAyjANuMu89woADQG3OgBNgUpVEggMYE9P4M7/9IcDEBD/3hxeHGANnPcAAAA0HPdaAA +xCcxHRiQMxUClqHYCLgxHRiQMxUAlg4aXDAluMG4guARGlwwAvQI2c9wAAACgTEdGJAzFQOWgdgI +uDEdGJAzFQCWcH4QeEi+lOYeGoIzG/IF9ormGfRDuA3wt+YO8u7mE/REKP4CL3BDuOe7EH4E8mG4 +EH4A2AvwRCj+Ai9wRLj58UK49/EB2ADez3MAAAGBMR3YkDMVA5bkuw0anDMD8gHY4bsC9AHYaHWE +JQEQIRpCMyJ6z3GAADhNQqlEIwMDQrvBxsHF4H8gGsIw8cALyC8mCPAE9FEgwMb/8wPaANnPcKAA +tA9YoM9woADUCzCg5M3juAzygNjkGhyw5c2EIH8N5RocsIogRQoP8OW4EPKKIAQA5BocsOXNhCB/ +DeUaHLCKIIUKOggv/QDZ0cDgfgsSATZEIT6FD/LiuQPyANgC8AHYJLlSIQEAwLk5YSV44H+FIBwA +8M0EIb6PMAAAAAQggA8AAABAIfKA4APaDPJBKYAEUiAAAMC4CriAIAwARSDCAEEpQAVSIAAAwLgG +uAV6QSkABVIgAADAuAe4RXgxucC5DLngfyV4gODD2TfyDBIBNve5EPJRIkDC/vVRIgDCiiHLAAXy +A9oLuibwANqLuiTwBCG+j8ADAAAA2g3yUSKAwP71USIAwAXyA9oLugPwANqLuva5BPKKIccADvD4 +uQXyiiHPAAjw+bkE8ooh1wAE8Ioh3wBFeSvKGLjgfyV44HjxwOHFCHI/zADdAeCPuD8aHDCpcQTw +AB9AQwHhHsxCuDBwO/YLyM9zoADQDwQgvo/AAAAABPQOG5iAGfDscUChC8j2uBDyz3KgAMgfjBIA +AAChkBIAAAChC8j3uIQSAAAD8gChDcgOGxiACNhKCC/9CHHPcIAAnCujoKSgDMj/uB70z3CAAM4H +AJDPcYAAzAeKIj4AgeAgkQj0ACGAD4AAYCT/GIKADPDPcIAAmDozIEEAACGAD4AAcCRAqD0Gz/zx +wMINz/xRIMDGSPIEIIBPADAAANdwABAAABX0AdnPcIAA4QggqM9wgADIBSCABoEB4Aahz3GAAAAI +AIEB4AChLPBRIADHC8gP9IK4CxoYMM9wgADIBQCAI4AB4SOgHg7v/IogRQlRIEDHC8gW8oS4CxoY +MM9wgADIBQCAJIAB4SSg+g3v/IoghQkLyOO4BvIMyK64DBoYMAsSATYvJkjwBPSpASAAANgMEgI2 +57pa9APaz3CgANQLUaDguQDdKvLPcIAAyAUAgCKAAeEioK4N7/yKIEUIDczPcQAASGWO4Fb2DMjg +uBT0z3cAAAFDz3agAMQnIB7YkwfYIh4YkBYLz/8gHtiTIh5YkyDwQHke8OS5BvLPcQAASGX68c9w +oAAwECGAANgF8AARAlAB4EEpggAQcjr3ANgE8AARglAB4FMhQgAQcjv3KP8LyEQgfoUwCML/z3CA +AEhQ7wAgAKGg5Lky8gDdz3GgANAPGBlYg1EgAMT+9f26BPIXEQGGBPAdEgE3ANgF8AAfQEMB4EEp +ggAQcjr3ANgE8AAfQkMB4FMhQgAQcjv3agrP/wvIRCB+hdAPgv/PcIAASFChoADdCv8u8P26BvJR +IIDE/vUZ8ADZB/AAEQBQAeEAHwBAHcxCuDBwOPYA2gXwAIgB4gAfAkAdzFMgQQBQcS1wN/YAEQBQ +DRoYMPn+C8hEIH6FdA+C/wDdz3CAAEhQoaAM/0n/wNvPcaAAyB9JGdiAA9rPcKAAEBRQoM9woABs +GEWgRxlYg0oZ2IAB2OEDz/xRIADHz3CAAMgFIIAK8gHaz3CAAOEIQKgGgQHgBqEJ8AvIgrgLGhgw +A4EB4AOhUSBAx+B8C8iEuAsaGDAEgQHg4H8EofHAKgvv/ADZ8M3PcqAA1AtEIBEDN6ID2BGiMKLO +C+/8iiAEDB3MPhIONuRoz3CgADAQoYAgyAZ+GPAvKIEDTiCBBwDYDyBAAAsgAIgacAXy7guv/Shw +BiYOFIQlPx+if89woAAwEKGAgOYQ8lUlQBbxcEz3ANhBLYEQEHG+B87/ABEBUAHg+fHPdYAAaCqI +FQAQAeCIHQAQANgF8AARgVAB4BB3PPf7yUoNj/9RIMDG/vPD/wvI5LgE8roLT/0X8OK4FfRMIQCh +EfIMEgE29bkG9IQVABAB4IQdABD0uQfyAdnPcIAAJAYgoAvIRCB+hQAOgv/PcYAASFAA2AGhl/6J +As/88cAuCu/8AdnPc4AAOE3Ai89woADQDxEYWIAqEgI277oA3Qr08M1EID6DbydDEATyqXEK8AvI +z3cAgAAClrgLGhgwDNnyugjyBOELyDB5l7gLGhgwDcxAJgIWWGBkuDhgA+AEIIAPAAD8/+xxAKEf +yAV/4KEAgwChAYMAoQDYCPBAIwIC8CICAEChAeBBLoIQEHI491jMALEqEgI24LoE8gHbA/AA2wzI +4LgE8gLeA/AA3iHKxXtEuO26BXsD8gjaAvAA2iDKZXoEuEV4ALGgqR7KAKkNzGS4ALG9Ac/84Hjx +wEoJz/wIds9wgACcXyaASiAAIIHhyiCBLwAAABBRIMDG//MD2c9woADQDzGgyXGEIQMPjCEChR8S +BTcL9CDMHhKGMAUgQAEhEg83mNoB2SfwKhKGMM9zgADUBc9wgADkPowmA5EUEg83BvQE40AgAgQE +8EAgAgMAg1MgAQAvIAMAAKMAEgcAqHBTJwMAtWuleC8lwhEfu6V7YKIO2oDhQPIQeMhxTgqv/ulz ++LgA3T70jCYDkfHNEPQUEgE3MHDE9gIgTQCwfc9wgADIBSCADoEB4A6hEPBAJwEVEHFF9gIgzQOw +fc9wgADIBSCADYEB4A2hBSCAIwAYBFAAGERT+8mMJgKVABgAUPjNABgEULgIgf/PcaAA1AcA2Ayh +CPCKIEQM4gjv/ADZAN3PcaAALCBTgb9nAieAEATbz3KgALAfeKJtgRB4EHMZ9/vJz3OAAEhQA6MK +2BWiANgNofUSgzAKzGJ4uGANoQDZjbnPcKAA0BszoAjYFKKMJgOVBPQKzAbwjCYDkQT0IswA2bP9 +5M3juAPygNgN8OW4BPKKIAQACfCMJgORBPQA2I64A/AE2P0Hr/zkGhyw4HjxwOHFocEIdVEgwMb+ +83H+gOAE8gDYSvAAEQBQgeX7GhiwABEAUfgaHLAdzGa4HRocMAARAFANGhgwG/TU2IL/+8n8EgG2 +FgoP/+e4KxoCMAryC8iUuJW4CxoYMAzIkbgMGhgwSg0v/gDYB9ge8PHNABwEMBTM8RocsAzIjrgM +Ghgwzv37yc4Jj/8LyEQgfoXACoL/ANnPcIAASFAhoAAUADHxGhywAdhhB6/8ocDgePHA4cUA3Uf+ +gOAF8vEAIACpcC1xAIHPcqAALCD7GhiwAJEE2/gaHLAdzGa4HRocMACBDRoYMDSCDsw4YM9xoACw +H3ihTYIMEgE2GmLouVB6EfIKzFBwSfbPcYAASFAjgfvJEHEn9I4KwASA4BPyDBIBNuC5Hsor8kQg +AAxcaCHKgOAD8gTiz3CAAAhA9CCAACPwxNhA/4oghAwCD6/8ANleDC/+ANjPcKAA0A8RGFiDJfDP +cIAAyAUAgCuAAeEroNoOr/yKIEUL0/EceM9ygADIP/QiAADxGhywjrkMGlgwiv37yb4Ij/8LyEQg +foW0CYL/z3CAAEhQoaAB2F0Gj/zxwOYNj/zlzVMgfoAE9PnJkgiP/1EgwMb+8wDZjbnPcKAA0Bsx +oM9woADEJxeA/f0KJQCQBfKiDs/+ANhK8AARAFANGhgwDMjouDvy5M3PdoAAaCrjuCnyENjkGhyw +A9nPcKAA1AcSGFiAsBYAEAHgsB4AEOXNUyB+gAnyi7jlGhyw9skhGhgwHfDPcKAALCAUgNnJAdoA +IIEPgAAYV2gZggAI3Q/wMg7P/oAWARAB4YAeQBDmDa/8iiDFCQPwGg7P/gzIjrgMGhgwUP1FJUAQ +gQWP/PHADMiOuAwaGDD5ycIPT/9RIMDG/vPO/YDgBPIA2CnwABEAUA0aGDAMyOi4H/LkzeW4z3CA +AGgqEvJA2OQaHLDPcYAA5CoNgQDaAeANodnJz3GAABhXFHlAqQnwP4AB4T+gZg2v/IogBQoz/QHY +0cDgfuB48cBRIMDG//O0/YDgA/IA2CrwABECUPsamLAAEQNRHcz4GtywZrgdGhwwABEAUA0aGDAk +yFBwCfRKzHBwBfQMyJS4DBoYMBYPb/9IcAvIRCB+hQgIgv8A2c9wgABIUCGgGP0B2NHA4H7xwDYM +j/wIdQDYz3GgANAPFaFc2Iy4z3agAMQnIB4YkCIeWJMB2BWhTtgKJABw4HioIAAB4HjgeM9wAAAB +gSEeGJAjFgCWQSiOASS4wbixcM9+DfLrcM9xAAC/DM9ygACHQwDbgg2v/JhxOQSv/Mlw8cDGC6/8 +TiCCAAK6VnoAIo0PgACIIz5lIIVEjkJ5IKVyD8//IIUErjhgCQSv/ACl8cCKC6/8XNjPdoAAhCPg +loy4ANnPdaAAxCchHRiQIxUQls9wAAAi0iEdGJAjFRGWz3AAACLSIB0YkCIdWJBOIMAgwbhTJwER +4v9TIEAgUycBEeD/z3AAACLSIB0YkCIdWJQAlgHgEHmg4QC2xPYBloC4AbbPcYAAZEuAEQAAmLhp +A6/8gBkAAPHAAguP/M9wgADOByCQz3CAAMwHgeGgkAb0z3CAAJskrWAe8M92gACYOjMmQBOA4Ez2 +63DPcQAA1QzPcoAAh0MF234Mr/yYdc9wgADMBwCQMyYBEM9wgACsJC1gz3agAMQnz3AAACbSIR4Y +kCMWAJYPeBB1GnAJ8s9wAAAm0iAeGJAiHliTz3AAACLSIR4YkCMWEZbPd6AA0A8A2BWnz3AAACLS +IB4YkADYIh4YkAHYFadO2AokAHDgeKggQAHgeOB4z3AAAAGBIR4YkCMWAZbPcAAAFEEmuSEeGJAj +FgKWz3AAACLSIB4YkCIeWJQSdS95DfIA2BWnz3AAACbSIB4YkCIeGJQB2BWnOGKieK3hBuDE9mq9 +BfCK4UT2CuWvfc9xgADOB2CRz3GAAMwHgeNAkQ/0ACKBD4AAYCT/GQKAACKAD4AAnCT/GEKDEPDP +cYAAmDozIYIAACKBD4AArCSgqQAigQ+AAHAkAKkMyJ+48QGv/AwaGDDxwIYJr/xB2QHfAN3PcJ8A +2P8uoAsaWDMMGlgzHhpcMysaQjPPcIAAOE2hoKCgMNnPcKAAsB81oFEhQMTPcIAAaCoNGlgzF/JW +IAECz3CAAMgFIKBbzAwa2DMKGhwwXcwiGhwwiiCEDgwaHDCKIEQLEfAkaM9wgADIBSCgWswKGhww +XMwiGhwwccwMGhwwiiCEC7oJr/wA2c9wgADIBSCAAIEB4AChAYEB4AGhoMqD4CAaXDMI9CvI5bgG +8gzIhLgMGhgwExpcM89wgADOB0CQz3CAAMwHgeIgkAj0z3CAAF8kMyBAAAzwz3CAAJg6MyBBAM9w +gABwJDMgQACAIAIAz3GAADhNArH62MYMb/8A2UohQCAadwDegOcL8s9woAAsIBOAkuDF994Mb/8A +30wgAKAI8oDmBvLSDG//SiAAIFEgwMdJ8oDmR/TPcIAA5AcggM9wgADsB/AgQACI4JL3z3GAAAgI +AIGD4Az0AtgAoc9xgABkS4ARAACPuIAZAAAMyMC4QChBBAQhgE8CAAAAMHDKISIg78oB4A957xoC +MM9woADQDxCAEHEE9AHeFfAyDk//C8hEIH6FmAtC/89wgABIUKGgz3CAAMgFIIAA3giBAeAIoYDm +BvQEIL7PAMAAAC/yTCEAoCvyUSMAw030USBAxpLzgOaQ8wHZz3CgANQLMKD0EoEwCswieBB+DMjg +uGb0HxpcMw4OT/8LGhgwUSCAxg4SAjc+9M9woAAsIDSAWWEweZoLb//JcDjw5M3juAvygNjkGhyw +5c2EIH8N5RocsArw5bgE8oogBAD18QDYj7jkGhywz3CAAMgFIIABgWG4AaEHgQHgB6HkEgG3iiCF +B3nwXg1P/wvIRCB+hcAKQv/PcIAASFChoIMCYACKIMUHyXD6DW//SHEeEocwz3KAAMg/LyHBAQAi +QDCsEICAKhoCMBx49CIAABQaHDDPcIAA6D/0IEAAMPACDk//CxoYMMlwug1v/wDZHhKHMO7KRCcB +DES5ACJCMLQSgoAqGoIwRCIDDES7BHpFIo4AemLPc4AACED0I4IAHxqcMxQanDAEIMABIBocMBlh +z3CAAChA9CBAACEaHDAqyM9xgAAQPAQggA8AAIAPJ7jwIQEAH8wleB8aHDANzI7gmHBP9gvIgLgL +GhgwagiP/w0SATeKIAUI1g5P/D0DQAAtdiCW8BpcsACWOnEZcPEaHLBTIX6AhCEDLEQhEgMJ8gsS +AjYKIYAfAAD/Dw7bTfBKcIjgT/QY2ihwhCAMAIwgDIAcGpwwCPQe2gzIHBqcMI+4DBoYMChwhCAC +A4wgAoIK9AJqEHocGhwwDMiQuAwaGDAocIQgwgeMIAKGBvQMyJu4DBoYMATiUHtRIYChCiGAHwAA +/w/KIcIQ7rkE8gjjcHsJcgPYDrhEeAPfDr8QdwsSAjYL8gQggB8AAP+/13AAAACAwAAMAIG6CxqY +MFrwhOALEgI2MPQQ2BwaHDAMyM9zgABgQJG4DBoYMEIpACHDuFEhwKEyIwkAO/ID2w67jCECqAom +gA8AAADHBCDFEATyKXMJ8AwlgI8AAADAKXMv8gbwDCWAjwAAAMAa9IG6CxqYMCXwCiGAHwAA/w9M +IgCgF/QY2BwaHDAD2A64BCAFEAomgA8AAACDHNvl8QQggB8AAP+/13AAAACAyfbg8YG6CxqYMEom +AAAO2wshgIGl9YhwcHCD9jFww/aAugbw13AAADAJxPaFugsamDBEIv6IFvJEIr6IzCdigwXygLoL +Gpgw4LrqBgIAQiQAAh0aHDAMyI642wMgAAwaGDCEIQMPjCEDhawMgf5AhiLI+RqYsCCWUHD0Glyw +CPRGzDBwBvQMyIi4DBoYMEwiAKF+AQIAjCECpHYBAQDPcKAAMBAAgOi4B/ILyEUgAAYLGhgwHRpc +M9IOoAAqcBpwgOAA3iPyDcxCIIEDHRpcMGS4SSAABBwaHDCiCa//At7wzQAfBEDxzQAfBED5yQAf +AED0zQAfBEDPcKAA1AuwoAzIh7gMGhgw8BIBt1YMb/yKIMQLDMjouB3yIMrPcYAA8AcVefwRAoAA +2wHi/BmAgM9xgAA4TQIRwQAII0IAz3GAAOgHFXn8EQCAWGD8GQCAKnCMIAOAJfIP9owgAoAl8owg +AogW8owgAowj9F4Mj/8FfijwjCADhBHyjCADiATyjCADjBf0ig6P/wV+HPCKC6//CnAFfhbwMg2P +/wV+EvD+DY//BX4O8IIKD/8Ffgrwyg9v/wDe8BIBt6YLb/yKIIUI4L4Z8uG+F/INzI7gz/b7yexx +AKH4zYwhAqAAsQf0z3CAAKxaZxAABgChSgtP/zoMT//jvtQHAQDzyc9ygACETaQQAAAhgGB5SHDB +BwAAz3CgANQLGIDU4Fz3z3GfANj/EIGQuBChEIGwuBChz3CAAMgFIIAFgQHgBaELyEUgAAYLGhgw +ogxP/+sFIACKIMUIDcwcEgE3ZLgieB0aHDDkzeO4GfIMyM9xAAgAASR4EHER9BDY5BocsM9wgACE +Te4PD/7ZyQHaACCBD4AAGFdoGYIA6g9P//DN7HIAsvHNALL5yQCi9M0AsgCG+xoYsACiAJb4Ghyw +ALL7ySQSAzYacBBzDBIBNhX0ShIDN/jNEHMP9PDNlLmEIM4LjCAKigwaWDAH9Jq5DBpYMPkSELbP +cxAEAAEEIcAAEHMq9ACG/RoYsACiAJb8GhywALIAlv4aHLAAsgCWBBocMACy8M3muAf0BMzluAX0 +DMiFuAfwDcyMIASARfYMyJG4DBoYMATMcg0P/YMBIAArGkIzTCIAoRH06LkEGlwzCfLkzeO4Ad9n +9IW5DBpYMGPwK8hEII8AX/ANzKjgRfaRuQwaWDD5yeC4K8gM8oO55LgMGlgwBfKRuQwaWDDiuAzy +CfDjuAXykbkMGlgw6LkE8pO5DBpYMACG/RoYsACiAJb8GhywALIkyP0SAbYQcQr0Ssz8EgG3EHEG +9AzIlbgMGhgwAJb+GhywALIMyO+4CfIAhgAaGDAAogCWAhocMACyDMjwuAfyAJYEGhwwALID8AQa +XDN+CoAACHcMyOi4C/IEzOW4CfSWDEAEgOAF9AwSATab8YDnBfRGDU//lQUAACDKz3GAAPAHFXn8 +EQOAANoB4/wZwIDPcYAAOE0CEcEACCJDAM9xgADoBxV5/BEAgBtjDMj0uPwZwIAF8isaQjNIcAjw ++8n8EgG26gqP/isaAjDnuBHyC8iUuJW4CxoYMAzIkbgMGhgwiiAFCboIb/wA2Q3wBLgAIIEPgADY +KECBIMqEIvwDBLhFeAChz3CgANQLsKAMyAhxh7nluAwaWDAl8lEggMYh9ADZjbnPcKAA0BsxoM9w +oADEJxeAUSDAxv/zBCCATwAwAADXcAAQAAAqAgIATg5v/9TYiiDEDEYIb/wA2QHYAvAA2AwSAjbx +ujpwBPTwze64CPQdzM9xoADUCxWhEfAryo4Jz/6A4AwSAjYJ9AvIkbqUuAsaGDAMGpgw7PHruhPy +TCEAoAXyWg2v/QLY8BIBt+4PL/yKIEQOHcxTEgE3jgyAAAzwA9nPcKAA1As3oEwhAKAE8i4Nr/0C +2AwSAzYFI4IPACAAAAQjvo8BAAABDBqYMB/yK8qMIAKAuHAb8gTMQC0FAVMgwQA9eQAhjw+AANgo +COcyJ0ERwLgCuBl5w7mP4QfyBSOCDwAwAAAMGpgw5boOAQIAz3AABAABBHpQcDv0USCAxv71ANmN +uc9woADQGzGgz3CgAMQnF4AKEgE38c04YPUSgTDPcqAALCAieDSCBNsieM9xoACwH3ihbYJRIMDG +//MEIIFPADAAANdxABAAAG/0z3eAAEhQEHOcACYADB8AFA2iYtnPcKAAsB80oETw8ggv/wpw8M2E +IAMPjCACgDH0z3CgACwgFICK4FYADQDPcYAAWCvPcIAAzAcAkEmREHIa9M9wgADOBwCQMIkQcRT0 +USDAxv7zz3eAALgFAI+A4Ab0TgqP/wHYAK8L8MoKj/+grwfwUSDAxv7zvgqP/1EgwMb/8wQggE8A +MAAA13AAEAAAHfTSDQ//OvBMIQCgOPRRIMDG/vMA2Y25z3CgANAbMaDPcKAAxCcXgAQggE8AMAAA +13AAEAAABfK2Dw//lQIAACIMb//U2IogBA0aDi/8ANnwze64EfIMyPe4BfJRIkDC//UJ8AQgvo/A +AwAABfJRIoDA/vVWC6/9ANgMyPy4DvIrygQSATf+EgK3ngvP/v4SAbfSDS/8iiBEDZ4ND/8B2s9x +gADhCECpz3GAAMgFQIEmggHhJqLPcoAAAAggggHhIKIMEgE29LkN8s9ygAAkBgHZIKIH8BYPD/+A +4PQBAgBRIIDECHf49c9xoADIHKehwNgKoQCGDRoYMDIOL//pcIoghA1iDS/86XEMEg42z3AQBAAB +xHjXcBAEAAF09OTNBCC+jwAAgAEM8uXNhCB/DeUaHLCKIMUKWwav/wDZxRIBthUiQDDXEACG8xoY +sMfJ4bgN8hUiQTD0EQCG9xoYsMbJ8hoYsIogxA3n8YbNz3GgACwgEKEA2ZC5z3CgALAfNKCHzSAS +gbBKCQ/9iiAEDtYML/wA2cfJ4rg0AQEAxBIBttkSDbYA2s3JDyJCAEV4zRoYsM92oADUBxoeWJDz +yY/bjBjAAMXJ2RpYsBYiADDJEACG9hoYsCDIRnggGhgwANiRuDh4z3GgANAbHKGSCSAAANjZGliz +Gh5Yk4ogBQud8fASA7docIQgAw+MIAKFEPTovg7y5M3nuAryENjkGhywz3CAAIRNSgkP/lLw674K +8ooghA4uDC/8ANn6C4AASPDPcoAAiCwBgs9xgACcX+i+CaEt8s92gADILOmGBMwFf+mmw7gA3w8n +DxANhgsgwIMN8gHYDKYEI4CPAAAAIAqmA/IB2ALwANgEoea7FPQDhgQgwIMQ8qiiToZFeA6mz3Cg +ACwgEYADoQbwz3CgACwgEYABoe27BPIB2APwANgCoaDKhOAE9LILIAVocC0DD/zxwM9wgABsTWYM +b/wY2c9wgABUTVoMb/wY2dHA4H7geADZmrnPcKAA0BszoM9wgAB4WAaQz3GgAMgcG3g6gYC4BHnP +cIAAsFgAiDhgz3GgAKggAqHgfuB44cUA2s9zgAAYVxQjAQBAsUixACCND4AANFdErc9xgACQVxR5 +VLFMrc9xgAB4WBZ5opHPcYAAVFcUea6xAd0AIIEPgABsV7SpFXvBxeB/gBuAAOB4/BwItPHAGnDZ +EgG2z3CAABhXNHgRiIDgD/LzyQGABCCADwQAACDXcAAAACAF9HbMEOB2GhwwSgpP/tnJ3P/zyQHZ +jBhAAKQQAAAkgGB5CnDZyQDZDyEBAD7ICyBAgAbyIMgmeCAaGDDRwAQUEDTgfvHAvgkv/LhwKHAE +Ib6PAADwAJhzA/TguAr0RCABDCS5Q3HEEY6AANmOuQfwHXlDcbwRjoAA2UAtjQHHdYAA4CMVJYMT +4otQdxr3Q4vRchjyESSAgBUlgxBIdvnzoIuI4gUlgx8AAACAANiI9wUlgx8AAACgANiOuCd4ZXip +AQ/88cDPcKAAmAMegPIIb/w44M9xoAAUBA6hDYGLuA2h0cDgfuB48cAOCQ/8z3egAIggAN0F8BOh +BOcB5YflaAEKAITl/POG5congR+gALAgAN4+yA8mThMLIICDbfIA2JG4AChSA87JzRIBtiR4CyCA +g1fyACJAM3QQgADPcYAAQEo6cBZ5GnHh2G4JL/whgQAQACAVIlE0D3i6CeAAE9nOEgG20ngEec4a +WLDXEQGmIBICNiqBCyKAg8whgo//////L/LPc6AALCBxgx7jInvXcwCAAABF90R4IBoYMCHwz3Cg +ALAfG4DPcqAALCBRgl4IYABCeTpw4Nj+CC/8KnHPcQAAKCIqcADaQg6gABPbABgAIM7JBBhAJMV4 +zhoYsCDIz3GgANAbCyCAg0pwhPUcoYPxYIfPcIAAGFfPcYAAeFgUIEIDgOO2eSH0uGBoEIMAguMJ +9FgSAwHDkXt7gLvEewTwgeME9GKRWBrEAADbaBjCAM9woADIH1oQAIZYEg4BBH5wGoQDCIkG8HAS +DgFwdgiJRPfYYAXwcBrEAHhgAKeXBs//ANjpB+/7zRoYsOB48cCOD8/757jZEgG28xIDts91gACQ +TUAjDgfPcoAAGFc0ehGK8IoO8kFo047irQWFQ60QeAO1z3dBAIMAAdgQ8EFv0o4Drc9wgAC4V/Qg +QABCrQO1ANjPdyEAggBQdkb346WVB+/76XAA3s9ygAA4Vyliw6UB4S96JK2HE4EAdpNU/++4Ba0G +8sStYN8Yv+rxAN+dv+bx4HjxwOXN5rgF8sINAAAH8APZz3CgANQHExhYgNnJz3KAAJBNYZLPcYAA +GFcUIQwAaLRkihlhIBnCAGWKMBnCAGOSz3GAAJBXFHl0sfMSA7aMEwAAI4IleNHA4H+MGwAA4Hjh +xQQgvo9gAAAA8xICtgDd2cnPcYAAGFcbYRR5BPIakuq4DPLkzee4HOIO8lOKAYkQcgf0oakD8KCx +AdgN8AHgAakK8FKKAIkQcgT0oKn38QHgAKkC2MHF4H9oGwIA4HjxwDYOz/vPdYAAWCsCheW4C/Tr +cDrZz3KAAJJDKHPOD+/7SiQAAAAWAUAhpQAWAUAipQAWgUAsrQAWgECGCi/8Da0KDkACgOAc9K4P +gASA4Bj0KhINNqYOb/wC2ADez3egANAP1acqyIIJr/yneKIMAATAyeK4BfK+Cs/+AvDVpx0Gz/vx +wOHFz3WAAHhYqXBqDC/8EtkA2AnwFiUCECiKgeHE9mG5KKoB4ITgt/YOlRq1D5Ubtc9wgACUWCSI +z3CAALBYIKgA2B21AIXguATyA9gD8AHYD6XqCQ/80QXP+/HATg3v+wTZpMESCi/8i3AAwOG4OnBT +8gDdPhpYM87JHBpYM4DgIBpYMwvy63Cw2c9ygACSQ6lz0g7v+5h1zRpYswQhgC8AAAAvQSgQAgXe +KvCKIhAA2HrPcKAAsB9VoADYkbjYeM9yoADQGxyiPsgAIowzJXh0HEITAeWC5T4aGDDL9+twv9nP +coAAkkPpc3oO7/uYdYTmBfLJcJ4K7/vpcWG+gOaL9gDZDyGBAwshAIQB38/1AN/v8VEhAKAQ8gDY +krjPcaAAsB8VoQHCz3CgACwgUaAD2BK4FKFRIYCgGvLPdoAAkkMA3RTwgsCpYD7IACJMMxEgQIAE +HEKQCfTrcOLZyXIB2wIO7/uYdQHliOWu9s4ID/yVBO/7pMDgePHAK8jluAzy63CKIQQAz3KAAJJD +AdvWDe/7mHHPcIAANF/aCC/8BdmGD4AAlggP/NHA4H7xwM9wgACcK74IL/wC2YIID/zRwOB+4Hjx +wO4Lz/sKJgCQKHUD8oDlC/TrcHDZz3KAAJ9DAduCDe/7SiQAAM9xgAAEBsChoqEDhikE7/sBoc9x +gAAEBuB/A6HgePHAqgvP+wh1AICA4AfyAYWA4AXyAoWA4Ar063Ci2c9ygACfQwHbNg3v+5hxz3ag +AMgfGhYAloHgBfJ+D8ADgOAM8oogzgIaDO/7pdkBhYDZIqAChUB4FfAAhSGF2P8CheX/AdgaHhiQ +ANnPcIAAeFgPgJG5GHkayCZ4GhoYMJkDz/vgePHAIgvP+892gAAEBgh1CPAgiGG9ABhCUAHgAaYB +hlMgfoD49YDlAN+F9td1AAAwCYr263Dt2c9ygACfQwDbmgzv+5hzAYbSCS/8qXHPcKAA1AfsoAGG +USBAwh1loaYA2Moggg8DAIQAIQPP+89xgAAEBiOB4H8goAhzKHLPcIAABAYggACBAID2GhiwAYFo +cXkAL/wCuuB48cCKCu/7BtrPd4AABAYAh89xgAC4V6OA2cnPdgAA4Az0IQEAAJUlePMSAbYasQGV +G7EEbWB+OOHzEgG2QCWAEkDhYH4G2vMSArbPc4AAkE0akkQgAAOE4EAiAQ8G9ADYBaMQ2BexMPAY +2BexANiLuAWjQCUAFFYiQQJgfgba8xICtmuVAYJAIgEP7bhQGsQABfJ2zMO7ZXgKsRqShCAMAIwg +DIAQ9EAlABZVIkEFYH4G2vMSArZqEgABQCIBDwbgahoEABqShCACA4wgAoIH9BeRAuAXsQqKAvAA +2GCHELEBg1eRAJBCeBaxBYMFAu/7AafgePHAmgnv+wDaAN3PcaAAyB8aGViDz3GAAHhYL4GRujh6 +GhIBNs92gAAEBkV5GhpYMCKGTg/v+wzaAIYjgACRq7gAsQOGQHigpqKmvQHv+6Om4H7geM9wgAAE +BgCAI4AAkYu44H8AseB44H7geM9ygAAEBiGCBBEABOB/IaIA2s9woADIHxoYmIAA2c9wgAB4WA+A +kbkYeRrIJXgaGhgwz3GAABhXHYmA4AXydswQ4HYaHDBGsU6xz3CAADRXSqjPcIAAkFdasIogTwuF +Ae/7iiEGDuB48cDPcYAAWCshgeO5D/LPcoAA3ig0aCliBCG+jwAA8AAF9OC5A/K3ywPwwgkP/NHA +4H7geOHFQIFggFBzAd3AfVBzAdtBgAGBwiPOABByAdnAeRByAdjCIA4AgOUF8oDhA/IA2ArwgOAF +9IDhBfKA4wPyAdgC8ALYwcXgfvHARgjP+wh2KHdIdev/gOAP8oHgEfKC4Bn0QIchh2CGwYYCIsKA +AyGBA0ClA/AA2SClIaUL8CCGQYbAh2GHAiGBgwMiwgAgpUGlZQDP++B4CHIG8AJ5x3IAAQAAz3CA +ADRfBYAwcLj3UyLDBDBzhffgfwIiQADHcgABAABYYOB/InjgeAhyB/BieQIigg8AAQAAz3CAADRf +ZYAwc7b3UyLABDhgcHAE9+B/WGECIoAPAAEAAGJ44H84YOB48cCGD4/7CHUacU4IIAABgKCFELlB +LQAUOGA+CCAACnEQubB4OGAyCCAAQCiBIr0Hr/socFMgwgTTuVBxhPfgfwIhgADPcIAANF8FgDhg +4H9CeOB4CiJAgEohAAAkAAIA/QAAAAoiQIBKIQAA8AABAKQAJAAvJgDwSiYAcJAABQBCIP6DSiZA +AFwADQBCIP6BSiQAcSQADQBCIP6ASiTAcBwADQBCIH6ASiSAcBQADQAVACAASiRAcC8gAwAvIAMA +LyADAC8gAwCoIAADACAAgAEhQQACIb6AwCCGAcIhhgAgIMAHCiYA8EolAAgYAAEAFAAEAC8gAIBC +JUUA/Afj/8AgA4DFB+//CiRAcREAIABKIAAQSiBAEA4iQgAvIAsSziBFgEomQABKJAB4qCAAAwAg +AIABIUEAAiG+gMAghgHCIYYASicAAEIg/pDOIMIBRCB+kM4hwgEgIMAHLyCCD/////8hIMAHSiEA +APHAHg6P+ysSDTbwEgK35b3Pc4AAsENEIg4DBfJAIwEGA/BAIwEEoMpCKg8CCGHBv4LnDBIBNgT0 +9LkG9IDnBfT1uQPyibmA5gf0hCIDDEEqDwHvYwPwAN/pcvZ4G2MgE48A4L8D8vO5BfLhvwXy6bkD +9ADbE/DivwHbEfL1uQ/0478A2wvy/cmMIP+PB/T8zddwAAD//wP0AdvmvwLyANvxze+4A/KuuQLw +jrmA4wwaWDAR8vW5IPKMIgKABvLQ4gTyjCIDhBj0i7mRuQwaWDAS8IjmBPTgvQ7yB/AEJb6fAACC +AAPyAtsG8IwiAoAE9Oa9+/WRBa/7aHDgeES4w7jPcYAAOCwJYeC5BfIMyOi4C/ThuQvyoMqB4ATy +guAH9AzI6LgD8uB/AdjnuQPy4H8A2CvI4bjhIMEHANjgfwLYBvAAEQFQZLgAH0BAg+A79wbwABGB +UGG4AB9CQIDg4Hz58eB48cC+DI/7CHaD4Ch11vdTJX6QFPLrcIohjQrPcoAAKEQA204Or/uYcwjw +ABEAUGS+AB8AQAQdEBCD5jn3CPAAEYBQYb4AHwJAAR0SEIDm+fXZBI/78cBWDI/7CHcacYLgANlF +9yhyKHYK8AARglAAEY5QAB+CQAAfgkMC2QAmQJAcASEAWnDxcBQBDQCE4uIAAQAN9oPiBAECAIHm +7gACAM9xgAB/XAHYDPCF4gzypeLoAAIAg+Zr9APYz3GAAHxc0P9T8KDKhOBKIwAgYfKE5roABQDP +dYAAaFwE2EAlARPI/26NQSjAIGhyoLoCIJEAwLtxrRBybgAtABAdwhQrbipwEHFeAA4AgOAJ8mG4 +tP8AEYFQAB9CQALwL41TIIIgANgPIIAAJHgPehCtELqKIIcNQgyv+0V5EI3PcZ8A2P+A4BCBA/Kf +uALw3rgQoRCBnrgQoRCBvrgQoQxuAiBABALwDG6e/0pxSiMAIBHwhuYN9M9xgACAXAbYov/PcYAA +SFABgYK4AaHv8UojQCBMIwCgBvQodwfwyXDm8QInQBCP/2EDr/vpcPHADguP+wh1GnGKIEcNvguv ++4ohhw+M5c/3z3GAAGhcDNiO/2y9BvCpcApxoP8CfYDl/PUD8Klwf/85A4/74HjxwNYKj/uC4Ah1 +1PfPdoAAaFwC2EAmgRSA/wmWjCAQgGK9CPSF5Qb0qXAA2ZD/An2pcHH/DQOP+/HAkgqP+xpw8BIN +tzpxhCUDHM9wgABoXBYM7/sg2YwlApAE8tDlB/QKcCpxqXLX/wbwjCUDlAT0CnDk/7UCj/vxwE4K +j/sdzM92oAAsIAHgEHkeysYK7/yrwQhzANmQuc9woADQGzOgAdgVplEjAMT+8wHYz3GgALAfGKFE +FhEQCoZCwAuGQ8C7gc9wgABoXCCAVIY7Y3piQMIBgDByQcBD9wHgQcCLcILBhMeqCe//6XLPcoAA +NF9lghpwBMEUaxBxzfckkk4K7//pcAhxRMAJ8AIhwAAIcQLwKHBwcTv3RMAKcIHgC/S+Ce//qXAI +dzi4QS0BFiJ4CvCC4Ab03gnv/6lwCHcD8Kl3ANhMIACgWnAH8qDKhODMIKGgA/QA2ALwAdiB4Dv0 +6XB+Ce//A9kIdwDAz3GAAGhcIIED4DBwQMBF9wHBAeFBwQDZkLnPcqAA0BszogHZNaZRIwDE//Mx +hs9ygAAkBgIhQQQjos9xoACwH/uhCqYBwAHZC6bPcIAAiAggqIogBw7PdgAAsAfCCa/7iiEPDg/w +iiAHDs92AACwB64Jr/uKIQ8Pz3GAAIgIANgAqQDBYH6KIMcNAcFgfoogxw2KIMcNYH7pcQLBYH6K +IMcNA8Fgfoogxw2KIMcNYH6pcUwiAKA58gDfz3CAAGQGAIgI8AAkzDMYrBKKAefvf4wgw48L8lVo +x3KAAIhcIIJBLQMWOLlwce7zAN4b8AAkkDMYEJAgz3GgALAfQChNIcd1gACIXACFO4EmDSAAAeYI +cUKFAIVges9+I4VeCWAACnDxdqX2kQCv+6vA8cDhxSvI5bhY8gHddf/PcIAAIAAAgIDgEfLPcIAA +lAcAgM9xgACEByCB8giv/BhggOAF8ooNYAOpcM9wgAA0X6egoMqE4CLyz3CAAGhcV4jPcYAAWCsJ +kVBwBfIBgeC4CvTPcYAAJAYCgQHgAqEA2A6hCvDPcYAAaCqMEQAAAeCMGQAACgqAAM9xgAAkBgGB +gOAM8gDYAaHPcYAA2AcAgaK4AKEaDIADz3GAAGRLgBEAAI64gBkAAPkHT/vgfuB48cB6D0/7K8jl +uGTyz3WAAGhcFI2B4BX0BNguCaADAdnPcIAAzgcAkM9xgADMBw94IJH2DuAEL3kA2BStNfDWjYDm +M/LPd4AA6wgAj2G40XAY8lIPwAQBbs9xAQD0Nhi4AdpODyAABNvPcYAA6ggAqc9xgADMByCRug9v ++4oghwbPcIAAzgcgkM9wgADoCCCoz3CAAMwHIJDPcIAA6QggqMCvANgWrTWNgOEL8s9wgADOBwCQ +mg7gBA94ANgVrc9wgABIUAGA4rgE8g6VDglP/gDZz3CAAEhQIaDwzYQgAwyMIAKAIPQB2c9wgACB +CCCo/g1P/M9xgACECAChiiBHDTIPb/uKIYwGz3CgAMgfqBABAM9wgADkCCCgiv/wzSoPQAQG8Iwg +A4TUDsH/tQZP+89xgAAkBgWBgeDgfc9woADIHxWA4H8Ioc9ygAAkBgWCgeDgfc9woADIHzWAKaII +gji5OLgCec9ygABcBgSKOGDgfwSqz3CAAGRLgBAAAM9xgAAkBi8qAQAMgYDg4H0FgYHg4H2R4uB8 +z3CgAMgfFYAKoQHY4H8MoeHFz3CAAGRLgBAAAM9xgAAkBi8qAQAMgYHgGPQFgYHgFPSR4hLyz3Cg +AMgfdYAA2muhCoE4uzi4AnvPdYAAXAYFjUyheGAFrcHF4H7xwOHFz3WAACQGJIUYuAQhgQ8A/wAA +OGDPcQAAmJuWIAgAANpuCyAAD9uMIMOPBqUM9OtwiiGSCM9ygAAoRP/b+g5v+0okAAC1BU/78cA+ +DU/7z3WAACQGBYWA4DD0ANgIpQmlCqULpQylAqUNpQ6lz3aAAFwGBK4FrgSlB6UHrooghw66DW/7 +iiGRCqDKg+AU9AaOSSAABQeuB46B4Az263CKIVELz3KAAChEAduODm/7mHEHjtP/AdgFpTkFT/vx +wOHFANnPdYAAJAYlpSilKaUqpSulLKUipS2lz3CAAFwGJKglqAaFLqWMIMOPJ6UH8g94pg0gAA/Z +/9gGpQEFT/vgePHAfgxP+z4OIASkwQ99iiDHDyoNb/uKIVQIgeWUDsH/z3aAACQGJIbPd4AAXAYH +hji5OLgCeS96JY8EjzhgD3hQcAcXkBCE9gDdBfACIg0Ar31ihoDjDfSA5cv2AIaA4Af0Doa4YA6m +DYa4YAfwsXMG9w2GAiXBEDhgDaYGjy6GMHAF9wHYGnAG8AJylOIB2MIgDACA4Bnyogxv+4ogCAAO +hkLFQMANhhDZQcAChkPAi3AaDm/7otoEhgemANgCpgSvBa8Aps9xgABkS4ARAACxuIAZAAAKcIn/ +CQRv+6TA8cAAFgBAz3GAACQGPhkCAD4RgABJIAAFPxkCAD8RgACB4Az263CKIVYAz3KAAChEAdsm +DW/7mHH2D0/70cDgfs9xgABkS4ARAACRuIAZAADPcKAAyB8VgM9xgAAkBgSh/9jgfwah4HjhxUEo +DQZBKQMG07ixc1MhwgSG97FzBvQQcsT3gCMEAM9xgACIXLARAQaie2x5QnjBxeB/J3DgePHAAgtv ++whyheGYccT2/QAgAP/YABaBcIAAZgbPc4AAZAaF4YIACgDPdoAAhF4A2QLwAeGF4dQABgAUJk0Q +hRWPEIDn9/UB2IUdAhCEHYIQz3agACQgAt3Pd4AAiFwVagBnNn4AphXIOH2leBUaGDDPdoAAiFy4 +FgAWpXi4HhgQz3CgAMgfFRhYgwAWjXCAAGYGkHVC9kOrABaAcIAAZgYB4AKrMfCji89wgACIXAW9 +HWUxjf/e0a3PdoAAhF40foQeghAC3vVq52DPcKAAJCA2eOCgFcg4fsV4FRoYMM9wgACIXLgQDwZM +JECBxX+4GNgDz3CgAMgfFRiYgwP0Q6sD8BONA6sveGECT/vxwOYJT/tacBpxz3CAAGQGAYh6cowg +w486cwX0BwIgAP/Zz3GAAIhcsBEBBlMiwCQQcV73iiAHDc91AACwB2B9SnGKIAcNYH0KcYogBw1g +fWpxiiAHDWB9KnHrcL/Zz3KAADxEANtGC2/7mHPPcIAAZAagiIomww8I2c9woACwHzigz3CgACwg +CIBKJUAAmHBKcYv/jCXDnwh3IvLPcKAA0BsTgM9xgACIXLgRAQYkeKlxCfAA2SGmUY4C2Vh5Jngy +jtVpx3aAAIhcgOAE8owhw4/y9YhwIIZ5/wGmUSMAoCPyz3aAAIRemBaAEIwgw48K8ohwz3GAAIhc +pBEBBnD/8XDT989wgABkBgGIz3GAAIhcmB4CEKMZ2AOkGZgEmR7CFJoeQhRRI0CgJPLPdoAAhF6o +FoAQjCDDjwvyiHDPcYAAiFyoEQEGXf/xcNL3z3CAAGQGAYjPcYAAiFyoHgIQpxnYA6gZmASpHsIU +qh5CFKhyCfAifxKISiUAAAHi2HUIdYwlw58J8hVtx3CAAIhcIYDxcfD3z3CAAGQGAYg1aMdxgACI +XAAZgAThoQgZAAQQGcIEDBlABE95T//PcYAAZAYhiVVpx3KAAIhcEapyirKqyHCMIMOPE6oI8gW4 +ACCCD4AAiFwyqowlw58J8gW9x3WAAIhcM60BheJ4AaX/3VVrACKAD4AAiFxMJQCAs6gF8s9wgABk +BiCoz3CAAGQGYagdAG/7KHDxwNIPL/uYcQjdz3GgALAfuKHPcaAALCAogUEoDQZBKQ4G07nTuDBw +3WXL9892gACIXLAWDhbZYQJ5AeUC8AJ5QC0AFiV4iHFk//UHD/vgePHAfg8v+wDZz3CAAGQGQIj/ +3al2KHMt8BVqx3CAAIhcgOET9PCI4b8P8qCAz3GAAIhcqBlYA89xgAAoX6OA5ammqUh1AdmA4xL0 +8IjgvxDywIDPc4AAiFykG5gDz3OAAAxfw4Dxq9KrSHYB21KIgOED8oDjBPSMIsOP0PXPcIAADF/Q +qM9wgAAoX10HL/ukqPHA3g4P+xpxz3eAAGQGz3WAAIhcwI8G8AW+QCWBFM5hEHYF8owmw5/49Ywm +w58M9OtwiiFIDM9ygAA8RADbZghv+5hxFW64YCOAEnF6cAzy63CKIYgMz3KAADxEANtGCG/7mHEj +j0AlgBRVaTIgkAASE4AgExOSIIwgw486cA3yQClBIblhExmCBAGBBBMCIFhgAaEU8NFxEvQRE4Ag +jCDDjwz063CKIUkBz3KAADxEANvyDy/7mHMDH4IUjCLDrwfyQCpBIblhEhlCBAPwAB9CFCGP/9oS +G0IgExuCIAW5uWHTqcGvo/8RE4EgjCHDjzvyE2nHcKAAJCAC2jh6z3OAAIReCnaMJsOfNHsf9ADZ +hRtCAP/ZhBtCAADZIKAVyFJ5JHgVGhgwz3OAAIhcuBMABgR5z3CgAMgfFRiYgAKPuBtYAGG4Aq8P +8AW+3WUxrSCFhBsCBCCgz3CgAMgfFRiYgAMfAhTRBS/7AdjxwHYND/sodzpyGnMKIgAhz3GAAGQG +z3aAAIhcoIkG8AW9QCaBFK1hEHUF8owlw5/49Ywlw58M9OtwiiEKCM9ygAA8RADb8g4v+5hxBb2+ +ZgOG8XAE9CKGEnEM8utwiiGKCM9ygAA8RADbzg4v+5hxCB6AFF0FL/sMHkAU4cUA2s91gACIXEhw +BfAB4BKpc6lQqTVoaWiT4Llhuff/3bKpc6nPcIAAZAagqEGoz3CAAAxfsKjPcIAAKF+kqM9wgACI +XMHF4H+4GJgA4HjxwM9wgAAIX0IOb/sK2QDZz3CAAGQG0cDgfyKo8cDWD0ACJgwAA9HA4H7gePHA +igwv+wDYmbjPdqAAsB8UpgDZkLnPcKAA0BszoAHfz3GgACwg9aFRIwDE/vPPdYAAiFyrFQAWCqGs +FQAWC6HPcIAAhGBcEACHrhUBFgq4UyHCBBBysB0YENb35gwv+4ogBw2KIAcN2gwv+7AVARbrcIoh +RQ7PcoAAPEQA28INL/uYc7AVABYZpq4VABYbpn/YFqa8/9D/FciKIj8ARHgVGhgwuBUAFj/ZRHi4 +HRgQz3CgANAbM6CxHdgTANiyHRgQzP8tBA/78cDPcIAATETPcYAANF+eCW/7FNrJ/9HA4H7gePHA +ogsP+89woADQGxOAz3GAAIhcuBENBgQlDZAL9OtwiiHQBM9ygAA8RADbLg0v+5hxz3CgALAfG4BB +KBAGANlI8ACOlOCM9utwiiEQBs9ygAA8RADbBg0v+5hxAI7Pd4AAiFwFuABnz3GgALAfO4H//Qhx +AI4FuPhgQoAAgEB6AI5AJwETVWhBYQz/z3CgANAbs4DPcIAAiFy4EAAGCnIEfc9woACwHxuAOLhQ +cADZB/SA5cf1gOHF9U0DD/sAjowgw4/38wW4AGc4uFBwBvLPdoAAZAbv8QHZ/PHxwM9ygACIXLES +AQbPcP8P//+A4RDyz3GAAIRemBGBAIwhw48I8s9woADIHxWApBIBBtj90cDgfuHF4cYIcs92gACI +XLEWAxbPdYAAhF6A4wDYC/KoFYMQjCPDjwXyqBYAFgCiAdiqFYIQwcbBxeB/QKHgePHAVgoP+892 +gACIXLEWABaKJf8fgOCpcgP0AN8k8M9woADIH1QQBADPcIAAKF8EiIwgw48D9ADfDfCoFg8WiHDp +cbf9BCC+jwD/AAAIdQPyAN3PcIAADF8QiIwgw4+KIv8PBPQA3g7wpBYOFohwyXGr/QQgvo8A/wAA +CHIC8gDaFNgAHwBA9skAHwBAAB9AQwAfgEAAH8BD6gwv+8lwIQIP++B48cCyCQ/7g+AR8oLgD/LP +c4AAqDECi89yoADEJ4C4QCgBBIUhiAIxogKrz3GgALAfHYHPdYAA9F4epc92oAAsIACGz3KAAHBf +AKIChs93oADQGwGiBIYCogaGA6IA2Jm4FKEA2JC4E6cB2lWmUSMAxP7zWKEbgRilCoYbpQuGHKXP +cIAAnF8HgITgBPKB4BD0z3GgAMAvgBEAAJ+4gBkAAIARAQDGCS/7iiCJCBGGGaUWh2kBL/sapfHA +8ggP+89wgACcXweAhOAA3wXygeDpdRP0z3KgAMAvgBIBAIASAAAwcP7zgBINAIogCQbevQXlegkv ++6lxz3CAAPReG4AAIFADz3CAAPRecBARABJ1wCFtIM9wgAD0XjWAz3CgALAfOaDPcIAA9F4YgJYI +b/+pcVDZz3agACwgNqYA2pm6z3GgALAfVKEA2pC6z3GgANAbU6EB2TWmUSMAxP/zz3GgALAfG6Eo +HgAULB5AFAPZz3CgALAfNqAA2ZK5NaDPcIAA9F4ZgAPZuGARphK5z3CgALAfNKDPcoAArCyhogjZ +z3CgALAfOKAohggaAAQjor4IL/uKIIkPz3CAAJxfB4CE4Cnyz3CgAMAvF4D/uCP0z3CgALAf/aDg +puKm5KbmpnzZNqA/2c9woADQGzOgz3CAAPRePoDPcKAAsB89oM9xgABwXwCBAKYBgQKmAoEEpgOB +BqbPcIAAZAbAiM9wgAD0Xh2AAN+guC8gCCDpdQbwEY4B4A8nDxDSjowmw59A8oXlfAAKAAW+x3aA +AIhcAIb/2xi7z3KgALAfW4IEIMEAZHoB5TByr30m9M9xoACwHzuB07jTuQLhMHC+B87/EY4A2QHg +DyEBAM9woADQGxOAL3kEIAAEJHgwcM/z63CKIdQDz3KAADxEANu+CC/7mHPF8SJ613IAgAAAdgfF +/89woADQG/ygRQfP+gDaQKHPc4AAiFyxEwMGgOMD9OB/SHDPcoAAhF6oEoIAz3P/D///YKAC8FKK +jCLDjxHyBbrHcoAAiFxwiuG79/NjgoHj8/NggmCgA4IAoeB/AdjgfwLY4HjxwJYOz/qgEoMwhOMo +9M9yoADIH3WC/9oYumR6QKAD22Chz3WAAIhcsRUDFoDjFvLPdoAAhF6oFoMQjCPDjw7yqBUNFgQl +gx8A/wAAUHMG9KCgqhaAEAChAdgV8IHiEvTPcqAAyB+oEgIAz3OAAJxfdYNietdyTgAAIMT3y/8D +8OD+gQbP+uB48cDhxaLBz3CgAMgftYCLcIHBz3KAAJxfYg/v/04SggCA4BHyguAR8qlwqgqv/wDB +z3GAADRfJYEDuTV5NHkQcUf3ANgJ8M9w/w///wXwmSAEC0ggAAAtBu/6osDxwK4Nz/qgyoTgC/Tr +cDDZz3KAAGBEANtKD+/6mHHPdYAAaFwtjc92AACwB4DhBfIMjTBwifZgfooghw2KIIcNYH4sjVrw +z3CgAMgfNYDPd4AAgF8mp2B+iiAHDSyNTY3Pc4AANF8IkySnUHBFpw32SLPPcoAA1F8A2BaqAdrP +cIAAnF9MoFCNz3CAAJxfRKARjYDgANoI8oDhBvQryOK4AvIB2s9wgACcX0KgiiAJBmB+JofPcIAA +nF8CgIDgBfIA2Ji4AvAA2ESHBXrPcIAAnF8EgIDgBfIA2ZC5AvAA2YogCQZgfkV5z3GAAGRLgBEA +AJq4gBkAAB0Fz/rxwLYM7/qKIAcNYg3v+tTZsg2AAM92gACcX4TgCHEH8ojhDYYT9IHgEfTPcKAA +yB+oEAAAANoDps9wgACAXwaAQqbTuJYgSQwJpg2GgeAD9ATZAN3iDqAAqXCE4AP0raYT8AKGgOAJ +8oogiQf+DO/69dkF2AfwiiDJBvIM7/r62QLYwg8AAJ0Ez/rgePHAGgzP+gomAJAacTpyDPTrcIoh +RAjPcoAAYEQA274N7/qYc89woADIHxWAYb5acNO4jCAXhxi+SfeA5gf0z3WAAIBfBYUeZgfwguB6 +AA4Az3WAAIBf/9gYuM9xgAA0X893AAAEnQQiAiBMIACgBYE59FYiggxeZgQmgR8A/wAAx3EAAQAA +OGAacJkgSSwAHUIUz3EAAJyvyXAC2mB/AdsBrQIdQhTPcQAA+LAKcALaYH8B2wOtiiCJDSYM7/rJ +cYogiQ078IDmC/TrcIohRAzPcoAAYEQA2wIN7/qYcWG+uPGAIgwIXmYEJoEfAP8AAMdxAAEAADhg +GnCZIEksAtgErc9xAAD4rslwAtpgfwLbBa0C2Aatz3EAADCwCnAC2mB/AtsHrUEoACYEtYogCQ6u +C+/6yXGKIAkOpgvv+gpxNQPP+vHA3grP+s9wgACcX04QgADPdoAAgF+A4CCOCPSC4Qb0BIaA4PAA +AgCA4RbyAY7KC6//AdmA4Av063Bp2c9ygABgRADbUgzv+phziiDJDU4L7/ohjgKOgOAV8gOOmguv +/wHZgOAK9Otwc9nPcoAAYEQA2yYM7/qYc4ogyQ0eC+/6I44Ghs9xoADIHzWBOLg4uRpxEHEod9Yn +JRikhh1lBYYfZ7F3TffrcIHZz3KAAGBEANvmC+/6mHEFhgPwHWWxd3734n2vfbFwSvfrcIfZz3KA +AGBEANvCC+/6mHEEjoLgEPQAIEAjJJYPeBBxCvQB2AOmANgArv/ZIa4CriOuDPAA2AOmz3CAADRf +R4CpcADZAeJr/y0Cz/rxwOHFiiAJBnoK7/qi2aDKhOAL9Otwo9nPcoAAYEQA214L7/qYcc9xgABk +S4ARAADPdYAAnF+6uIAZAAAChYDgDPLPcIAAiCwBgAmlz3CgAMgfqBAAAAGlz3CAADRfB4CB4CP0 +z3CAAGgGAICG4AbyheAE8ojgBPQo/xXwBIWA4ADZEfLPcKAAyB+oEAAAIqUDpc9wgACAXwaA07iW +IEkMCaUA2ASlkf+ZAc/68cAeCc/6CHegyoTgC/TrcIohRAHPcoAAYEQA27YK7/qYcc9wgACcXwqA +gOA08s92gACAXwqOguAu8oDnC/TrcIohxALPcoAAYEQA24YK7/qYc89woADIH7WAYb8YvwQljR8A +/wAAgCUGFALYCq7PcQAAdK74ZQLasg5v/xHbC66KIAkNUgnv+vlliiAJDUoJ7/orjvEAz/rxwOHF +iiBJDTYJ7/qKIQUJz3GgAMgfNYEmCe/6iiBJDaDKhOAA3Qz063CKIQUKz3KAAGBEqXMGCu/6mHHP +cYAAgF+qqf/YC6nPcIAANF+noM9xgACILAiBhOBE9wHgCKHPcIAAaAYAgILgC/SKIMkHzgjv+ooh +hQ2eCyAABtiBAM/64HjxwAYI7/qKIEkOsgjv+oohRgzPcaAAyB81gaII7/qKIEkOoMqE4ADeC/Tr +cIohRg3PcoAAYETJc34J7/qYcc9wgABoBgCAz3WAAJxfguAV8oXgE/KG4BHyiOAP8gyFgeAL8utw +iiGGDs9ygABgRADbRgnv+phziiDJB0II7/qKIQYPEgsgAAbYAdgNpc9xgACAX8Sp/9gFqc9wgAA0 +X9UHr/rHoPHAVg+P+jpwoMoacYTgAN0L9OtwiiHFD89ygABgRKlz8gjv+phxiiDJDe4Pr/qKIUYA +z3GgAMgfNYHeD6/6iiDJDc9xgACAX//YAanPcIAAnF8MgIHgoKkF9CpwCnHA/xfwjCAGpFX3z3CA +ADRfp6DPcIAAaAYAgILgC/SKIMkHlg+v+oohhgRmCiAABtgpB4/64HjxwM4Or/qKIAkPeg+v+ooh +RwPPcaAAyB81gWoPr/qKIAkPz3CAAGgGAIDPdoAAnF+G4ADdEPKI4A7yDIaB4Azy63CKIUcEz3KA +AGBEqXMyCO/6mHWgyoTgC/TrcIohhwTPcoAAYEQA2xYI7/qYcQ2GgeAM8utwiiHHBM9ygABgRADb +/g+v+phxz3GAAIBfpqn/2Aepz3CAADRfp6CKIAkI4g6v+oohhwayCSAAB9h+CkAAz3GAAGRLgBEA +AK2mmrh5Bq/6gBkAAPHA+g2P+jpwGnGKIEkPrg6v+oohBgcA3c9xoADIHzWBmg6v+oogSQ/PcYAA +gF+iqf/YA6nPcYAAZEuAEQAAmriAGQAAz3CAAJxfLICB4Qj0DYCB4AT0KnAKcbj//QWP+vHAog2P ++sDJhOAH9CvI5bgD8gHYAvAA2M9xgACcXwqhAN2loYDgraFu8qDKhOBs8s92gACAXwSOguAy9AOG +geAljhf0z3MAAPiuCiSADwAAnK8ocALZzg9v/wHaAtgljgCuIa72Da/6iiCJDhXw7g2v+oogSQ4F +jj4Ob/8C2YDgC/TrcIohiATPcoAAYESpc8YOr/qYdaSu/9gFrgaOguAy9AOGgeAnjhf0z3MAADCw +CiSADwAA+LAocALZZg9v/wHaAtgnjgKuI66jpo4Nr/qKIIkOFfCGDa/6iiBJDgeO1g1v/wLZgOAL +9OtwiiHIDM9ygABgRADbXg6v+phzpq7/2AeuBQWP+vHAz3CAAEgsz3GAAIBfdgrv+hzaz3GAAGRL +gBEAALq40cDgf4AZAADxwHIMj/rPdYAAvCwJZc93gABoBoPhAKdG8s92gACcX4LgDPQmhoHhCPSK +IEkI/gyv+gDZCNgAp4LgFfQC2AamANnPcKAA0A81oBXIBCCAD6H7//8VGhgwFciPuBUaGDAi8All +geEL9M9wgADILACA4LgF9ADYBqYC8CamwMniuATy8giP/QfwANnPcKAA0A81oKDKhOAG9JIKgAOA +4AT0VgjAAjUEj/rxwOHFANmbuc9woADIHxMYWIDPdYAAaAYAhYngivfrcMLZz3KAAMBEANtWDa/6 +mHEghc9wgABkLPAgQABAeAUEj/rgePHAz3CgAMAvF4D8uAvyiiCKAi4Mr/qKIc4FPghAAO4JQADR +wOB+4HjxwOHFz3WAAJxfz3CAAGhEqXE2Ce/6SNoA2c9wgACILCigz3CAAGgGIKDPcKAAyB+oEAAA +oQOv+hKl4HjxwOHF8P/PdYAAnF/PcIAAsERWJUES9gjv+gzaANjPcaAAwC+AGQAAz3CQAZABxBkA +AM9wgAD0X34M7/qw2QfZz3CAAHBgLaDPcKAAyB+oEAAASQOv+hKlANnPcIAANF/gfyeg8cDCCo/6 +wMmE4Af0K8jluAPyAdkC8ADZz3CAAJxf4gqgACqgmgugAAh2CHXPcIAAJF8oiIwhw4+KIP8PGfLP +cYAAaAYggYLhE/JuDI//jCADgsX3WSBABgLwANjPcYAA5D4mgRBxRPcieAPwANjXcAAAfBUB2MIg +DgCA5gXygOUD8oDgA/QA2ALwAdihAo/68cAyCo/6z3aAANRfFI7PdYAAnF+A4Av263D02c9ygADA +RADbvguv+phzwMmB4Av063D12c9ygADARADbpguv+phzFI6C4A30ANgUrs9xgABkS4ARAACtuIAZ +AAAu8MX/gOAs8gqFANmA4C6lBPKgyoTgE/TPcoAAyCwuoi+iENgJoiqiJaWKIMkGXgqv+oohxAMC +2BHwAdgFpc9zAADkwwbZvg3gAwhyiiCJBjoKr/qKIQQGAdhC/+UBj/rxwOHFoMqE4Av063CKIQQJ +z3KAAMBEANsOC6/6mHECCkAACHWk/4HgA/SA5QvyLgjP/oogSQb2Ca/6iiFEDgDYMP+pAY/64Hjx +wC4Jr/qKIEkL2gmv+ipoKhICNuC6AN4D8gHYAvDJcAQigg8IAAAAOgugAlgSATc2DIACgOD+86YM +L/uKIP8Pz3WAAJxfCoWA4M6lBPKgyoTgBPQE2ATwfglAAFILYAAA2YDgF/QHhYPgDfSKIEkGcgmv ++oohygoA2BD/BdgHpQnwiiDJBl4Jr/qKIUoMAtgK/wkBj/rgePHAiiAJCkYJr/qKIUcLjg9P/89w +gACcXyeAg+EF2gPyR6DyC+AABdjPcYAA9F8FgQHgBaHPcQDnAQDPcKAAwC83oADZm7nPcKAAyB8T +GFiAwMmE4AryiiBJBvIIr/qKIQgCANjv/gvwiiBJB94Ir/qKIcgDBNjr/rz/0cDgfuB48cDhxRYP +T//aCQ//z3WAAJxfggvgAAeFz3CgAMAvF4DguBPyz3CAAIBfCoiA4A30z3KAAIgsCIKE4Ef3KoWB +4QP0AeAIos9wgACsLEIPgADPcoAAxAUgggFpAKLqCa/6SNimDgAAgeAc8gDZm7nPcKAAyB8TGFiA +wMmE4AryiiBJBkoIr/qKIUkDANjF/grwiiBJBzYIr/osaATYwf6T/+kHT/rxwGoPT/oIdxpxiiCJ +CBoIr/qKIQYHDCCArwAAGBUM9+twiiFGB89ygADARADb9giv+phzz3WAAJxfCoWA4BLyoMqE4A7y +BYWC4Azy63CKIYYHz3KAAMBEANvKCK/6mHHGCC//56XPcaAAyB81gboPb/qKIIkIz3agAMAvN4aq +D2/6iiCJCD4Or/pU2OS4C/IC2c9wgABsBiCgWNgGCa/6QNkKcAYNoAAnhReGgOAL8s9wgABsBgCA +4bgF9Ij/QQAAAIPnD/TPcIAAbAYAgOG4CfIUhuG4//MUhoUgDAAUpgTwE4aIuBOmJtgKJABw4Hio +IAAB4HjgeGYOz//RBk/68cBqDm/6ANmhwc9wDwBAQkDAz3WAAJxfBIWA4Ajyz3CgAMgfqBAAACSl +A6XuDgAATg8gABpwCHG6CGAACnCA4Ez0z3CAAMgsCYDkuADfDPTrcIohRQbPcoAAwETpc8YPb/qY +cc9xAIIBAM9woADALzegz3aAAJwrI4aA4QfyJgiv+gjY46bkpijwKgvP/4DgJPIChYDgDPLrcIoh +hQvPcoAAwEQA234Pb/qYc9IMYACLcAolAJAS8tIK4AMA2IogCQdmDm/6iiEGADYJ7/8D2KlwMg7v +/wDB9QVv+qHA4HjxwJINT/o2DgAAlg4gAAh1CHECCGAAqXCE4An0iiAJBiYOb/qKIQsBLvDPcKAA +LCAxgM9woACwHxuAz3WAAJxfQYVCeYwhH4QA3sv3z3GAADRfJYHTuIIhHwQQcQT3AoWA4BL0iiAJ +Bt4Nb/qKIcsEwqWKIMkG0g1v+oohiwWiCO//Ath5BU/68cDhxaDKhOAL9OtwiiGLCM9ygADARADb +og5v+phxlg0AAPYNIAAIdQhxYg8gAKlwTQVP+vHAoMqE4Az063CKIUsMz3KAAMBEANtyDm/6mHFi +DQAAgOAP8pYLj/6KIAkIXg1v+oohSw8uCO//B9g+CUAA0cDgfuB48cDhxaDKhOAL9OtwiiHMDM9y +gADARADbKg5v+phxHg0AAH4NIAAIdQhx6g4gAKlwRCB+gTX0z3GAAMgsCYHkuBPyDIGA4BHyAtnP +cIAAnF8moIogyQbyDG/6iiHNAMIPr/8C2B3wz3CgAMgfqBAAAECBq4HkunCBAiBCA2J4CfLXcAAA +AFDH9wHYDKED8AkiAgDXcgAAAFDD9xDYCaFpBE/64HjxwA4Ob/sA2IogCQeWDG/6iiEGBGYPr/8D +2ALYz3GAAJxfBaHAyYTgBvQryOW4BPIB2APwANgKoc9xDwBAQkIM7/8D2NHA4H7xwKYLT/qiwc9w +gABoRDmAQMHPdoAAnF8lhhqAg+FBwCXygOEj8qDKhOAh8oHhAN0K9FoKj/7PcIAAGFcdiIDgpaYV +8oogCQYSDG/6iiEMBwPYBaYNhq6m8CQCMM9zAACcwwDYbg+gAwzZqQNv+qLAz3GAAGwGANoY8ADY +nLjPc6AAwC8XoxWD6rgVgwnyqrgVoxWD4LgK8gGBoLgS8Iq4FaMVg+C4DPKA4unzANmbuc9woADI +HxMYWIDgfgGBgLgBoQHa8vHgePHALgqv+lTY4bjPcYAAbAYBgQTygbgD8KG40cDgfwGh8cAv2DYN +b/sW2bIOb/sE2NHA4H7xwOHFiiAKA1YLb/q52c91gABsBgCF4bgO9AOFUiCAAAOl2gmv+lTYRCAB +AQOFEHH59e//wMmE4BT0z3GAAFgrAoGluMIMIAMCoc4Mz/pyC8/6Ggvv+gLYAg7v+oog/w8VyADZ +BCCAD6H7//8VGhgwFciPuBUaGDDPcKAA0A81oM9wXgQAAM9xoADIHxUZGIAv2BIZGIAA2I24ExkY +gADYnrgSGRiAz3EAAFQFz3CAAORKJaDPcaAAuD8SEQCGiLgSGRiAAIXhuPQNwv9RAk/68cCKIEoD +igpv+vHZ7gtv+wHYwMmE4HAMAfrPcQAAQAPPcIAA5Eo2DmACJaDAyeK4BPKmDg/9B/AA2c9woADQ +DzWgz3GAAGRLgBEAAL240cDgf4AZAADgePHA4cWhwc91gABsBoogygImCm/6IYUChSGFMHAc8sDJ +hOBAwQP0hLlAwYtwBNmaC2/6odoBhYDgBfIChYDgnA7B/yGFgOEH9AKFgOAD8tf/IYUipYDhCvLP +cYAAZEuAEQAAnbiAGQAAjQFv+qHA4HjxwHf/jP/j/89wgABsBgGAgODKIGIA0cDgfuB48cBGCK/6 +VNjkuAfyAtnPcIAAbAYgoNHA4H7gePHAiiCKA4oJb/oA2YT/9v97/9L/0cDgfvHAz3EAggEAz3Cg +AMAvN6ACCK/6JNhEIAECz3CAAGwGAYCA4AjygOEH9Hf/6P+qDM//A/Df/9HA4H7gePHAANmcuc9w +oADALzigUf9m/73/0cDgfvHA4cUAFgBAz3WAAGwG6gxv+gClAIXhuAPya/8V8OC4E/SeD2/6VNjh +uAv063BI2c9ygADURAHb5glv+phxAYWBuAGlqv+dAE/64HjPcYAAyCzPcIAA4ES1BW/6EdrgePHA +4cXPdYAAyCwHhYwgw48H8g94Cgkv/xLZ/9gHpQCF4bgg8uC4CPIFhYDgBPIGhYDgC/TrcFrZz3KA +ACRFANt+CW/6mHElhQaFSghv+zhgz3EAAHDCAtrmD+/+EtsHpSEAT/rxwOHFz3WAAMgsqXBeDG/6 +B9kChQQgvo////D/CvLrcDrZz3KAACRFANsyCW/6mHEAheS4BvIDhQ2lANgDpQTw/9gNpdb/7gtP ++tUHD/rgePHAVg8v+gDZz3aAAMgsQIbihi/dCyDAw+Z9wLoC8gHZz3CAAJxfboALI8CDBfIJhuS4 +A/SBuQsgQMMG9AsjQIMA2APyBNiA4gX0hOAH8oDhBfSA4gTyhOAC9ATZYQcv+ihw4HjxwPIOD/rP +dYAAnF8EhYDgCPTPcIAAyCwKgIDgANsD8gHbz3GAAMgs4IGgylMnAhCE4ADeBPIryOW4BPQA2Cbw +CoGA4AL0z6GA4gDeC/KA4wnyCYHkuAfy5L8a8gGBj+AD9MlwAvAI2C6BgOEN9IDiA/SA4wn0geYH +8s9xgADUXzSJguEC9ATY0QYP+g+BAeCE4A+hRPcBgY/g5/PPcKAAyB+oEAAAA6UB3t/xz3GAAMgs +AIEv21MgAIAigc9ygACcXyZ7BPQugoDhFfSA4AbyDoILIMCAD/QwgoDhBPQFgoLgB/KB4Qf0EYKC +4AP04H8B2OB/ANjgePHA9g0P+hpwKHVId+r/geAz9M92gACcXwCGgOAt9M9wgABoBgCAguAK9Iog +SQiGDi/6iiHFDFYJr/8I2M9xgADILIDlANoF8kqhTKEG8AGBj+BJoQL0SqHPcKAAyB+oEAAARKYQ +oQHYDNkKcghzmHVaCKADuHflBQ/64HjxwOHFhOAIdQ701g9P/4ogSQYmDi/6iiEEA/YIr/8A2ATd +VvCE4Sr0oMqE4Av063CKIcQEz3KAACRFANv2Di/6mHEryOW4DPTrcIohBAXPcoAAJEUA294OL/qY +cYogCQjWDS/6iiGEBaYIr/8H2HIJz/9uD0//1vFTJX6QE/LPcIAAaAYAgILgA/KE4CD0iiBJCKYN +L/qKIQQKdgiv/wjYFvCI4RP0z3GAAMgsAIHkuAX0AYGP4ADZAvIB2c9yAADUwgHdqXCw/wLwAN0p +BS/6qXDgeM9wgACcXwaAgeAI9M9wgADILAmA5LgE8uB/AdjgfwDY8cCKDA/6z3CgAMgfqBAPAM92 +gADILAuGpYYCJwEQMHWF9waGHWUifQvwz3IAANTCAdgA2Zf/BYYXJw8Q66b/2AemAIbhuA3yygwv ++6lwz3EAAHDCAtpqDO/+EtsHppUED/rgeOB+4HjxwCIML/oI2c92gACILNoIb/rJcCCGz3WAANRf +4LnPd4AAnF8M8gHYFK3PcoAAZEuAEgAAjbiAGgAAB/AUjYHgA/QC2BSt4bkD8gHYAvAA2BetBCGA +DwDAAAA+uIPgFa0L9OtwTNnPcoAALEUA22oNL/qYcSCG4rkD8gHYAvAA2OO5Fq0E8gTYjLgF8M9w +AABEFhSnIobPcIAADC0goM9zoADIH6gTAgAShwIiAQD/uQL0UqeoEwAA9g8v+gOnzQMP+uB48cDh +xc9wgABoBgCAh+AA3Q3ygOAL8utwiiGEBc9ygAA5Ralz7gwv+ph1z3CAAJxfpaCKIEkG4gsv+ooh +RAmyDm//ANiRAw/68cAWCw/6z3CAACwsAoDPd4AAnF/nuADdFfSKIMkGsgsv+oohBAEC3n4Ob//J +cMWnz3GAAMgsrqGvoRDYCaGqoQvwpaeKIEkGhgsv+oohRANWDm//qXApAw/64HjxwL4KD/rPdoAA +nF8ghiV4AKYQhoDgocEF9AHYEKYFhhGm5g8v/otwAMHPcAAA5MMQccoggg8AAJzDzCBCgAfyz3AA +ANTCMHAD9FoJT/4A3coMb/+ips92gACAXwqOguAI9AuOagvv/hHZqq7/2Auuz3WAAMgsB4WMIMOP +B/IPeE4L7/4S2f/YB6WKIEkG5gov+nPZtg1v/wDYkQIv+qHAz3KAAJxfIIIGeSCiANgQogWCAQLv +/xGi8cDPcYAAnF8qgYDhA/QC2Cfwz3GAANRfNYmA4RTygeEN8oLhFvLrcPfZz3KAADlFANuGCy/6 +mHES8NdwAAAAIM73BvDXcAIAAFjE9wHYCfDXcAAAGBXE9wTYA/AA2NHA4H7gePHAngkP+s9wgADI +LCCAz3KAAJxfCoKA4MC5SPLPcIAAgF8EiILgQvKgyoTgPvIMgoHgPPKA4Tr0z3CAAIBfBoDPcaAA +yB/1gTi4OL8Qd9YnJRjPcYAAgF+kgR1lz3CAADRfyJD+ZrF2S/frcIohxQHPcoAAOUUA29oKL/qY +c89wgACAXwWAA/AdZbF2fvf4YA4gQAMB2eYML/8C2oogCQ62CS/6iiGFBV0BD/rxwO4ID/oIds9w +DwBAQgCmz3CAAJxfCoDPd4AAgF+A4AoXkBAI9M9wDwBAQrH//wAgAAh1yP/PcIAAJF8IiIwgw48K +9EwgQKAG8qDKhOAE8iCGFPCWCg//CHHXcP8P//8Apgz063Cg2c9ygAA5RQDbNgov+phx7vGgyoTg +DfTPcIAA5D5GgDByRPcCIYAAA/AA2ACmzPHPcKAAyB9VgM9wgACILGiADODwIMAA07rPc4AANF9l +g2G4DHsAIkAOmCBJDEggDQCxcQP3KHUU8AqPguAP9IogCQbSCC/6t9kLjyYJ7/4R2QDYCq//2Auv +oKZKIEAgz3CAAOQ+JoCxcUX3AiVAEALwANgApnr/CiUAkA3yTCBAoAv0z3CAAIgsKIAM4LYOL//w +IEAAKQAv+qlw8cDCD8/5oMrPcoAAnF+E4BD0z3CAADRfB4CA4AX0KoKA4QDYS/QggoDhANhH9Ebw +z3CgAMgfqBANADKC6YICJUAQP7hHIEEAA4IeZxB2SPexdgDbSvexcMj3B/CxcAX3sXYA20L3AdvC +goDmEvIBgh9nEHdH97F3SvexcADeCfcG8LFwAN4F97F3g/cB3sKigOMA2BPygOER8s9xgAA0XyeB +gOEE9CqCgOEJ9IDmANgF9CCCgOED9AHYcQfP+eB48cACD+/5JNhODi/6Ad9EIA4Cz3CgAMAvpRAA +hsW4v+DPcAAAxAwyDi/6wH8H2Ri5JHgQcQDdEPTp2B4OL/oEuM9x//8AACR4EHEG9FEgQMQC8gHd +UyBBQc9woADIHxoQAIaA4ADaCfLPcIAAaAYAgIHgA/IB2oDmANgL9IDnCfKA5QfygOEF9IDiA/QB +2N0Gz/ngePHAcg7v+TPYz3GgAMgfShkYgDDYz3WgAMAvEqUM2EoZGIAg3gokgHPgeKggQAHgeOB4 +E4WTuBOlCiSAc+B4qCBAAeB44HgThbG4E6UQ2AokAHDgeKggAAHgeOB4E4WwuBOlfQbP+eB44cXP +c4AAqDHPcaAA7CeB4ADaBvKC4ATyg+AL9KCLhCU/H0AtABRFIIACB6GgqwnYBqEB2M9zoACIJA+j +/9gRo0+jiiC/DxGjS6HPcAAACiMHoc9zgADEMc9wAAAKiwehz3CAABgyW6gMi0erobhAKAIEBSKC +DwAADihHocHF4H8Mq+B48cCGDc/5CHWD4Sh2C/TrcIohEA/PcoAAOUUA2xoP7/mYcc9xoADAL4Hm +F/TPcIAAnF9UgM9wgAAQAECgQn0FJYAfAIAAAJQZAABZJYAcn7iMGQAACfBCJc0dBSWAHwCAAACU +GQAAQiWAHJ+4hBkAAFklwByfuJAZAACpcIIgRgefuIgZAABtBc/54HjxwPIMz/nPdwAATA7PcAAA +xAxAfwfZGLkkeBBx+PVRIEDE9vMD2GB/CrjPdoAAqGAAplMggQcD2PIO7/kKuDHYBrgA3eYO7/mp +cRnYB7jeDu/5qXHPcAAABAxAfwGmz3AAAAgMQH8CpmHYYH8FuAOmz3AAACQMQH8Eps9wAAAoDEB/ +BaYz2GB/BrgGpgnwEm1gf5YgBAAVJkwTB6QB5ZDlt/cd2GB/B7jPcYAABGEAoc9wAACEDmB/AN3P +cYAABGEBoc9wAACIDkB/z3GAAARhAqHPcAAAjA5Af89xgAAEYQOh6dhgfwS4z3GAAARhBKEY8BVt +YH+WIAYI0m3Ufsd2gAAEYQWmQC3QEApwYH+WIAQKBqYKcGB/lSBJBAemAeWG5an3z3KgALwtMYLP +cIAABGE3oDSCz3OAAIBhOKA1gjmgN4I6oDiCO6A2gjygOoI9oDuCPqA5gj+gHoLPcaAAOC4BowCB +AqMBgQOjAoEEoxyCBaMDgQajBIEHowWBCKMGgQmjHYLRA+/5CqPxwF4Lz/lacCh1OnIac89wAACI +Ds9x//+lBc92AAAsCWB+iHdv2AW4YH4KcbvYBLhgfulxz3AAALQLYH5Kcc9wAAC4C2B+KnHPcJ8A +2P+roM9wAADoDQHZYH6OuV0Dz/nxwAYLz/nPdaAAyBwohc9wgACcXyugrgvv+YogCQaA2kmlz3Cg +AMwXFxABhs9wgAC8BSCgSqXPcIAAAAAAGEAHaiDAAsK4z3GAAAQAAKHPcIAACAAAGIAGwMnPcYAA +DAAAoc91oADQGzQVEBANhc93gAD8f764DaVn/89woAC8NzcQDoY4EAOGz3CAAHwGAIDPcYAAfAYB +4AChAKcA2J64EaXJcADZl7kKJIAPgIESML4JL/oA2hGF/rj/889wAADEDJ4JD/oH2Ri5JHgQcfj1 +GdgHuGoM7/kA2QDYnrgRpTQdABQA2ACnANiduBGlJtgKJABw4HioIEAB4HjgeAAmgB8AAPx/z3GA +APx/BNoKJIAPAAEAAI4O7/8A22/Yz3FAgAIAGgzv+QW4EYX9uP/zz3CAAHwGAIAghzBwrAfC/ykC +z/nxwMIJz/kacCh2WNjuC+/5AdmSDe/5KNj+D6/+yXCmC+//yXDPdaAAKDCD5gzyguYK8s9wMgAF +ABalCnAKDO//yXEG8M9wMgAACBalDgvP/4HmBvKC5gTyg+YE9GIOz/9CDe/5BdgF8FMgfsEe9M9w +AADEDKYID/oH2Ri5JHgQcfT16diWCC/6BLjPcf//AAAkeBBx6vXPcKAAOC4HgMW4v+AA2eL1A/AB +2YDhBfLPcKAArC8T8M9wAAAcDF4ID/ruuPv1iiAIAM9xoACsLxehGYGruKy4GaEocDiAgeaLuTig +OICKuTigBfKC5gPyg+YE9DiAibk4oIPmB/KC5gXyiiEQADagEtkYuT6gIKU9gB6AJHgwcAzy63CK +IdMJz3KAADlFANtWCu/5mHHD2Bq4z3GgAMgfD6GQ2A+h6QDP+fHAhgjP+Qh1z3CgAMAv14CKIAkG +Kgnv+clxz3KAAHBgDYLPcYAA9F8B4MK4DaJHJkAQwLgG4AGtz3CAAJxfZ4BTJgQQFSHAAOCAhOMB +5+Cg7YIDhQS/uHc/Zw+nAoUOpwAlgA+AABBgdKjhjfWoAYUE9FkggAUBpc9zgACcX2eDgeMF9IIg +GgABpU2C/74EujpiDaIK8gCBbyJDAAHgAKHPcKAAwC9XoPm+C/IHgQDaAeAHoZm6z3CgAMAvV6D8 +vgryANqcus9woADAL1egCIEB4AihTCQAgAnyAdrPcKAAwC9XoAaBAeAGoc9ygABoKtASAQABhThg +9Qev+dAaAADxwM9xoADALxOBkLgToROB4Lj/8xOBkbgToROBsrizuBOhINgKJABw4HioIEAB4Hjg +eAHZz3CgAMgfSRhYgAPYCiQAcOB4qCBAAeB44HjRwOB+4HjxwDYPj/kIdoHgLgAiAADdz3GgAMgf +SBENhgrYShkYgDXYSRkYgAbYCiQAcOB4qCBAAeB44HiqD0ABgeYG9M9woADIH0kYWINZB4/58cDh +xc9yAwBADc9xoACoIEChANmauc91oACwHzSlz3EB4ABAz3KgANAbNaLPcYAANF8qgYHgNqII8oLg +BvKD4ATykNgUpSXwcg7P+YDZz3CgANQHHBhYgM9woADQDx0YWIDAyc9xwAGQAYTgyiGBD8AhkD2K +IgQAz3CgAMgcSaAJ2s9woAAsIE6gT6A0pdEGj/ngePHATg6P+c92gACoYM93AAAsCQDdCvASbUAm +ARfwIUEDYH+WIAQAAeWQ5bf3z3AAAAQMIYZgfwDdz3AAAAgMIoZAf89wAAAkDCSGQH/PcAAAKAwl +hkB/YdgjhmB/Bbgz2CaGYH8GuAPYIIZgfwq4HdjPcYAABGEggWB/B7jPcAAAhA7PcYAABGEhgUB/ +z3AAAIgOz3GAAARhIoFAf89wAACMDs9xgAAEYSOBQH/p2M9xgAAEYSSBYH8EuBnwFW3SbdR+x3aA +AARhJYZgf5YgBghALdAQCnAmhmB/liAECgpwJ4Zgf5UgSQQB5YblqPfPc4AABGE6g89woAC8LTeg +O4PPdYAAgGE4oDyDz3KgADguNqA9gzqgPoM7oD+DOaAhhT6gIoUgoiOFIaIkhSKiJYU8oCaFI6In +hSSiKIUloimFJqIqhT2gOIM0oDmDNaA/2SeiN4MxoF0Fj/ngePHA4cWA2s91oADIH0kdmJDPcIAA +vAUAgM9xoADMFxcZGIAD2CAZGIBKHZiQnv+KIUQNz3CAAJxfSR1YkDEFr/kroOB48cDhxQDYz3Wg +AIgkD6URpX4I7/kF2AHYD6UY2BGlMMhFIEECz3CgAOwnJqD9BI/58cCCDI/5CHXPdqAArC8YhgDf +srgYpg3YCiQAcOB4qCBAAeB44HjPcaAAyB9IEQCGCthKGRiANdhJGRiABtgKJABw4HioIAAB4Hjg +eMDJhOAR9ITlD/LPcYAAqDEAiYG4QCgCBEUigwLPcqAAxCdxogCpz3CAAJxfB4CD4BTyz3GgACgw +5qELgd64C6EHgd64B6EIgd64CKEKgd64CqEJgd64CaEYhoPlqbiquKu4GKY+AAEAguU6AAEAiiAQ +ABemiiAFDwokAHDgeKggQAHgeOB4z3KAAKgxAorPc6AAxCeguEAoAQSFIYgCMaMCqoTlB/KF5QXy +HIb/uDQAAQAZhou4GaYZhqy4GaYX2AokAHDgeKggQAHgeOB4GYYEIL6PAABgAPv1iiAIABam0gvP +/yIM7/8A2GoM7/+pcByG/7gI9IXlBvKE5QTyRg7P/w7wA9iGCu/5CrgFIIEPAIAAAAPYVg2v+Qq4 +ag7P/1zYSg2v+QHZ6g6v+QrYHIb5uAbyCNg2Da/5AtlhA4/54H7geOB+4HjxwBINwAB+CsAAIg4A +ANHA4H7gePHA4cUA3aoIIACpcLYL4ACpcKIPAACKCsAAz3CAACgGMQOv+aCg4HjxwM9xgACABgCB +13AAgAAABPRiDcAADPAAgddwAEAAAAb0zg2AAYDgLA3CANHA4H7xwIYKj/nPdYAAgAaA4RTyAKUB +hYDgHvTPcYAAZEuAEQAAlLiAGQAAog9v/wjYAdgBpRDwAN7Apc9xgABkS4ARAAC0uIAZAAAiCK// +CNjBpaECj/nxwM9ygABkS4DggBIBAAnyk7mAGkAAYg9v/4DYB/CzuYAaQADyD2//gNjRwOB+4Hjx +wPIJr/kC2aLBug6v+YtwAxSAMILgjPbrcIohBA7PcoAAQ0UA244Lr/mYcQMUkDACFIAwz3WAAKQG +CK2EKAYoz3eAAIQvACdAHlpwoBCAgIDgCiFALhXyABQAMe4J7/lmuAHZz3CAAIgGM7D/2Amtz3CA +AKwGrgnv+QTZXfAA2c9wgACIBjOwCR0CFAAhjS+AAIgti3CpcQoPr/kC2kAlABIAFAEx6g+v+Wa5 +AoXPcYAANF8lgdO4EHEM9+twiiFFBM9ygABDRQDb6gqv+ZhzAN4c8IQuBhgvcFknARMJYYHhE/TP +cYAAkC0BYQKFMHAL9OtwiiHFBc9ygABDRQDbsgqv+ZhzAeaC5qb39gsgAwpwz3CAAKwGCgnv+QTZ +AdmgGkKgACGBL4AA/C4JgYC4CaEB2Kf/GQGv+aLAz3GAAIgGAqHPcYAAZEuAEQAAkriAGQAA8QVv +/4ogBADxwKIIj/kAFg1AguWhwY3363CKIdIIz3KAAENFKHM6Cq/5SiQAAEDFi3CeCO/5BNmELQYY +L3cAJ44fgACEL6EWgJCMIMOPCPJuCW/+B9n/2KEeApDPcYAAcDA2gc9wgACILbFxDvKgFoCQgOAh +8otwBNl6Cq/5mdoA2KAeApAZ8B9nZhcAFoG4Zh8YEM9wgACIBjSAgOEB2gTyQ6AE2AjwANkwoCqg *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Dec 19 11:40:59 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93C14106566C; Sun, 19 Dec 2010 11:40:59 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 69D5F8FC1B; Sun, 19 Dec 2010 11:40:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJBex4p086280; Sun, 19 Dec 2010 11:40:59 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJBexuP086266; Sun, 19 Dec 2010 11:40:59 GMT (envelope-from bschmidt) Date: Sun, 19 Dec 2010 11:40:59 GMT Message-Id: <201012191140.oBJBexuP086266@freefall.freebsd.org> To: craig001@lerwick.hopto.org, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/142907: [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect firmware issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 11:40:59 -0000 Synopsis: [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect firmware issue State-Changed-From-To: open->closed State-Changed-By: bschmidt State-Changed-When: Sun Dec 19 11:40:20 UTC 2010 State-Changed-Why: Committed, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=142907 From owner-freebsd-net@FreeBSD.ORG Sun Dec 19 17:10:11 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76308106566B for ; Sun, 19 Dec 2010 17:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6318FC12 for ; Sun, 19 Dec 2010 17:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJHABs5030478 for ; Sun, 19 Dec 2010 17:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJHABlC030477; Sun, 19 Dec 2010 17:10:11 GMT (envelope-from gnats) Date: Sun, 19 Dec 2010 17:10:11 GMT Message-Id: <201012191710.oBJHABlC030477@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Oliver Ebert Cc: Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oliver Ebert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 17:10:11 -0000 The following reply was made to PR kern/143874; it has been noted by GNATS. From: Oliver Ebert To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource Date: Sun, 19 Dec 2010 10:39:47 -0600 On Sun, 19 Dec 2010 11:49:27 +0100 Bernhard Schmidt wrote: > On Sunday 12 September 2010 05:30:10 oliver.solaris@gmail.com wrote: > > I have the same issue with a Toshiba Satellite P105: > > > > Sep 11 21:46:13 kernel: wpi0: irq > > 17 at device 0.0 on pci3 > > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res 3 failed > > (0, 0xfffff fff). > > Sep 11 21:46:13 kernel: wpi0: could not allocate memory resource > > Sep 11 21:46:13 kernel: device_attach: wpi0 attach returned 6 > > > > Please let me know if I can help out to track this issue down. > > Is this still an issue on a recent stable/8 or 8.2-BETA1? > With 8.1 it is but I didn't had a chance to check with 8.2 beta. From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 06:11:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B04551065693 for ; Mon, 20 Dec 2010 06:11:00 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id C4FE38FC1F for ; Mon, 20 Dec 2010 06:10:59 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 46FA639824; Mon, 20 Dec 2010 08:10:57 +0200 (SAST) Date: Mon, 20 Dec 2010 08:10:57 +0200 From: John Hay To: freebsd-net@freebsd.org Message-ID: <20101220061057.GA36160@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: IFT_L2VLAN and IPv6 link-local addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 06:11:00 -0000 Hi, I see that on FreeBSD-8 if you use IPv6 inside vlans, the local part of the address (bottom 64 bits) is based on the MAC address of the first ethernet interface on the system. It was not like this in my old -7, machine, so I looked around a bit. It looks like it is because vlans were changed to report their type as IFT_L2VLAN. So I made this patch to the IPv6 code that fix it for me: Index: sys/netinet6/in6_ifattach.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v retrieving revision 1.74.2.3 diff -u -U 5 -r1.74.2.3 in6_ifattach.c --- sys/netinet6/in6_ifattach.c 6 May 2010 06:44:19 -0000 1.74.2.3 +++ sys/netinet6/in6_ifattach.c 15 Dec 2010 18:33:45 -0000 @@ -265,10 +265,11 @@ addrlen = sdl->sdl_alen; /* get EUI64 */ switch (ifp->if_type) { case IFT_ETHER: + case IFT_L2VLAN: case IFT_FDDI: case IFT_ISO88025: case IFT_ATM: case IFT_IEEE1394: #ifdef IFT_IEEE80211 Anything against me committing it? Am I missing something? Should it be sorted differently? Should it also be merged? John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 08:43:51 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B1FC106566C; Mon, 20 Dec 2010 08:43:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 419C48FC19; Mon, 20 Dec 2010 08:43:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBK8hpZI068884; Mon, 20 Dec 2010 08:43:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBK8hpBu068880; Mon, 20 Dec 2010 08:43:51 GMT (envelope-from linimon) Date: Mon, 20 Dec 2010 08:43:51 GMT Message-Id: <201012200843.oBK8hpBu068880@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153244: [em] em(4) fails to send UDP to port 0xffff X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 08:43:51 -0000 Old Synopsis: em(4) failes to send UDP to port 0xffff New Synopsis: [em] em(4) fails to send UDP to port 0xffff Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 20 08:43:36 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153244 From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 11:07:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAED510656C8 for ; Mon, 20 Dec 2010 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96E698FC18 for ; Mon, 20 Dec 2010 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKB712C024601 for ; Mon, 20 Dec 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKB700P024599 for freebsd-net@FreeBSD.org; Mon, 20 Dec 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Dec 2010 11:07:00 GMT Message-Id: <201012201107.oBKB700P024599@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:07:01 -0000 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/153255 net 8.2-PRERELEASE repeatable kernel panic under heavy net o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o bin/152716 net hostapd(8) fails to authenticate after 2010-11-03 upda o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152411 net [re] network card works only on 1000M o kern/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] encapsulate vlan in ng_ether before output to i o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/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 bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues 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] arp: Segmentation fault (core dumped) 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/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy 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/126475 net [ath] [panic] ath pcmcia card inevitably panics under 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 [inet] [patch] 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 o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee 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 kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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 f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge 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/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw 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/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 bin/121359 net [patch] [security] ppp(8): fix local stack overflow in 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/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 [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of 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/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. 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/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/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [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/111457 net [ral] ral(4) freeze 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/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to 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 o kern/105945 net Address can disappear from network interface 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] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap 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/100709 net [libc] getaddrinfo(3) should return TTL info 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/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf 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 f kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i 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/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation 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/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong 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/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 368 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 11:19:22 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 101551065679; Mon, 20 Dec 2010 11:19:22 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DA4948FC1B; Mon, 20 Dec 2010 11:19:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKBJLQI038618; Mon, 20 Dec 2010 11:19:21 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKBJLpQ038614; Mon, 20 Dec 2010 11:19:21 GMT (envelope-from bschmidt) Date: Mon, 20 Dec 2010 11:19:21 GMT Message-Id: <201012201119.oBKBJLpQ038614@freefall.freebsd.org> To: steven@uplinklabs.net, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/139079: [wpi] Failure to attach wpi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:19:22 -0000 Synopsis: [wpi] Failure to attach wpi(4) State-Changed-From-To: open->feedback State-Changed-By: bschmidt State-Changed-When: Mon Dec 20 11:17:13 UTC 2010 State-Changed-Why: Can you retry this with a recent 8.2-BETA or stable/8? There have been quite a few changes regarding PCI-bridge resources. Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Mon Dec 20 11:17:13 UTC 2010 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=139079 From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 11:25:09 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC981065670; Mon, 20 Dec 2010 11:25:09 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8556D8FC21; Mon, 20 Dec 2010 11:25:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKBP93U048033; Mon, 20 Dec 2010 11:25:09 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKBP9rK048029; Mon, 20 Dec 2010 11:25:09 GMT (envelope-from bschmidt) Date: Mon, 20 Dec 2010 11:25:09 GMT Message-Id: <201012201125.oBKBP9rK048029@freefall.freebsd.org> To: ivan@serezhkin.com, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/121872: [wpi] driver fails to attach on a fujitsu-siemens s7110 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:25:09 -0000 Synopsis: [wpi] driver fails to attach on a fujitsu-siemens s7110 State-Changed-From-To: open->feedback State-Changed-By: bschmidt State-Changed-When: Mon Dec 20 11:23:23 UTC 2010 State-Changed-Why: Can you retry this with a recent 7.4-BETA, 8.2-BETA or stable/8? There have been quite a few changes regarding PCI-bridge resources. Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Mon Dec 20 11:23:23 UTC 2010 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=121872 From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 11:36:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C771F106566B for ; Mon, 20 Dec 2010 11:36:57 +0000 (UTC) (envelope-from patrick.ale@gmail.com) Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com [209.85.161.49]) by mx1.freebsd.org (Postfix) with ESMTP id 56F458FC18 for ; Mon, 20 Dec 2010 11:36:56 +0000 (UTC) Received: by fxm19 with SMTP id 19so2546435fxm.36 for ; Mon, 20 Dec 2010 03:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y9tqyCNtO3f/E5OPyQ++gS4vjMIcCMrGCZnRNygMdWk=; b=XaTvgPM0SPdZxdBX4oIR6ShQVywRg+uWR70dvO86rLh8+na6UCu8dmPbgvJPFEt2+3 w4/N5SKduuYth3nZ8Ds0j7XJBL368hh2j+zIHCzyH0h5EMUdozk4zmOf8I+Fe7PEPqcC FQ3N0WhqC3z4WA1Dz6oWfCqh0gQu3vcHtjlbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y8gEqJxBsqZ797Z577xMLhnsYj70npZvnxSZZou6dSTkbTGtz2ZsjizJLUWYdNfyhe bYJC0RZW4Gd5JL6mjGgDlnxeaNKARYL8K49TUlG4JR9QMUFq8n580Pzh9OJuC8o19GAy aDHsi56EnLkmDP/rJgoO9l0FnSP9wbGd2cEQA= MIME-Version: 1.0 Received: by 10.223.81.76 with SMTP id w12mr2706043fak.26.1292843184384; Mon, 20 Dec 2010 03:06:24 -0800 (PST) Received: by 10.223.113.17 with HTTP; Mon, 20 Dec 2010 03:06:24 -0800 (PST) In-Reply-To: <201012191710.oBJHABlC030477@freefall.freebsd.org> References: <201012191710.oBJHABlC030477@freefall.freebsd.org> Date: Mon, 20 Dec 2010 12:06:24 +0100 Message-ID: From: Patrick Ale To: Oliver Ebert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:36:58 -0000 Hi, Not sure if this is useful information for you but here goes: I have exactly the same problem on my Acer Aspire laptop with the same network card but then under Solaris 10 and Opensolaris, both 64 bit. The only way for me to get rid of this error and get the card working is to reduce my memory from 4GB to <=3D 3GB. I got told it has to do with the PCI to PCI-X bridge masquarading some memory addresses.. I am not a kernel/driver/code guru but I thought one of you might get some pointers out of this.. Patrick On Sun, Dec 19, 2010 at 6:10 PM, Oliver Ebert wr= ote: > The following reply was made to PR kern/143874; it has been noted by GNAT= S. > > From: Oliver Ebert > To: Bernhard Schmidt > Cc: bug-followup@freebsd.org > Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not > =A0allocate memory resource > Date: Sun, 19 Dec 2010 10:39:47 -0600 > > =A0On Sun, 19 Dec 2010 11:49:27 +0100 > =A0Bernhard Schmidt wrote: > > =A0> On Sunday 12 September 2010 05:30:10 oliver.solaris@gmail.com wrote: > =A0> > I have the same issue with a Toshiba Satellite P105: > =A0> > > =A0> > Sep 11 21:46:13 =A0kernel: wpi0: i= rq > =A0> > 17 at device 0.0 on pci3 > =A0> > Sep 11 21:46:13 =A0kernel: wpi0: Driver Revision 20071127 > =A0> > Sep 11 21:46:13 =A0kernel: wpi0: 0x1000 bytes of rid 0x10 res 3 fa= iled > =A0> > (0, 0xfffff fff). > =A0> > Sep 11 21:46:13 =A0kernel: wpi0: could not allocate memory resourc= e > =A0> > Sep 11 21:46:13 =A0kernel: device_attach: wpi0 attach returned 6 > =A0> > > =A0> > Please let me know if I can help out to track this issue down. > =A0> > =A0> Is this still an issue on a recent stable/8 or 8.2-BETA1? > =A0> > > =A0With 8.1 it is but I didn't had a chance to check with 8.2 beta. > _______________________________________________ > 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 owner-freebsd-net@FreeBSD.ORG Mon Dec 20 11:41:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203A21065674 for ; Mon, 20 Dec 2010 11:41:33 +0000 (UTC) (envelope-from admin@shtorm.com) Received: from ns.shtorm.com (ns.shtorm.com [195.62.14.3]) by mx1.freebsd.org (Postfix) with ESMTP id D21A68FC0C for ; Mon, 20 Dec 2010 11:41:32 +0000 (UTC) Received: from [10.66.6.77] (unknown [10.66.6.77]) by ns.shtorm.com (Postfix) with ESMTP id CB8201A0AD1; Mon, 20 Dec 2010 13:23:07 +0200 (EET) From: Shtorm To: Eugene Grosbein In-Reply-To: <4D0CFEFF.3000902@rdtc.ru> References: <4D0CFEFF.3000902@rdtc.ru> Content-Type: text/plain; charset="UTF-8" Date: Mon, 20 Dec 2010 13:21:35 +0200 Message-ID: <1292844095.1917.136.camel@stormi> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:41:33 -0000 On Sun, 2010-12-19 at 00:35 +0600, Eugene Grosbein wrote: > Hi! > > I've loaded router using two lagg interfaces in LACP mode. > lagg0 has IP address and two ports (em0 and em1) and carry untagged frames. > lagg1 has no IP address and has two ports (igb0 and igb1) and carry > about 1000 dot-q vlans with lots of hosts in each vlan. > > For lagg1, lagg distributes outgoing traffic over two ports just fine. > For lagg0 (untagged ethernet segment with only 2 MAC addresses) > less than 0.07% (54Mbit/s max) of traffic goes to em0 > and over 99.92% goes to em1, that's bad. > > That's general traffic of several thousands of customers surfing the web, > using torrents etc. I've glanced over lagg/lacp sources if src/sys/net/ > and found nothing suspicious, it should extract and use srcIP/dstIP for hash. > > How do I debug this problem? > > 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" I had this problem with igb driver, and I found, that lagg selects outgoing interface based on packet header flowid field if M_FLOWID field is set. And in the igb driver code flowid is set as #if __FreeBSD_version >= 800000 <------><------><------>rxr->fmp->m_pkthdr.flowid = que->msix; <------><------><------>rxr->fmp->m_flags |= M_FLOWID; #endif The same thing in em driver with MULTIQUEUE That does not give enough number of flows to balance traffic well, so I commented check in if_lagg.c lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) { <------>struct lagg_lb *lb = (struct lagg_lb *)sc->sc_psc; <------>struct lagg_port *lp = NULL; <------>uint32_t p = 0; //<---->if (m->m_flags & M_FLOWID) //<----><------>p = m->m_pkthdr.flowid; //<---->else and with this change I have much better load distribution across interfaces. Hope it helps. From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 11:54:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 552D0106564A for ; Mon, 20 Dec 2010 11:54:56 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f48.google.com (mail-bw0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id DD2518FC08 for ; Mon, 20 Dec 2010 11:54:55 +0000 (UTC) Received: by bwz8 with SMTP id 8so2800808bwz.7 for ; Mon, 20 Dec 2010 03:54:54 -0800 (PST) Received: by 10.204.101.83 with SMTP id b19mr3415347bko.199.1292846094435; Mon, 20 Dec 2010 03:54:54 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-065-216-210.pools.arcor-ip.net [88.65.216.210]) by mx.google.com with ESMTPS id d27sm3522786bkw.2.2010.12.20.03.54.52 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Dec 2010 03:54:53 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Patrick Ale Date: Mon, 20 Dec 2010 12:53:30 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: <201012191710.oBJHABlC030477@freefall.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012201253.30310.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org, Oliver Ebert Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:54:56 -0000 On Monday 20 December 2010 12:06:24 Patrick Ale wrote: > Hi, > > Not sure if this is useful information for you but here goes: > I have exactly the same problem on my Acer Aspire laptop with the same > network card but then under Solaris 10 and Opensolaris, both 64 bit. > > The only way for me to get rid of this error and get the card working > is to reduce my memory from 4GB to <= 3GB. > I got told it has to do with the PCI to PCI-X bridge masquarading some > memory addresses.. > > I am not a kernel/driver/code guru but I thought one of you might get > some pointers out of this.. There have been a few changes to PCI bridge code lately which might well fix that issue. If anyone could give a recent stable/8 or 8.2-BETA a shot, I'd really appreciate that. > On Sun, Dec 19, 2010 at 6:10 PM, Oliver Ebert wrote: > > The following reply was made to PR kern/143874; it has been noted by > > GNATS. > > > > From: Oliver Ebert > > To: Bernhard Schmidt > > Cc: bug-followup@freebsd.org > > Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not > > allocate memory resource > > Date: Sun, 19 Dec 2010 10:39:47 -0600 > > > > On Sun, 19 Dec 2010 11:49:27 +0100 > > Bernhard Schmidt wrote: > > > > > On Sunday 12 September 2010 05:30:10 oliver.solaris@gmail.com wrote: > > > > I have the same issue with a Toshiba Satellite P105: > > > > > > > > Sep 11 21:46:13 kernel: wpi0: irq > > > > 17 at device 0.0 on pci3 > > > > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > > > > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res 3 failed > > > > (0, 0xfffff fff). > > > > Sep 11 21:46:13 kernel: wpi0: could not allocate memory resource > > > > Sep 11 21:46:13 kernel: device_attach: wpi0 attach returned 6 > > > > > > > > Please let me know if I can help out to track this issue down. > > > > > > Is this still an issue on a recent stable/8 or 8.2-BETA1? > > > > > > > With 8.1 it is but I didn't had a chance to check with 8.2 beta. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 12:40:11 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FC551065675 for ; Mon, 20 Dec 2010 12:40:11 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD0C8FC18 for ; Mon, 20 Dec 2010 12:40:08 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBKCe5iG023683; Mon, 20 Dec 2010 18:40:05 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D0F4EA0.5020205@rdtc.ru> Date: Mon, 20 Dec 2010 18:40:00 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Shtorm References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> In-Reply-To: <1292844095.1917.136.camel@stormi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 12:40:11 -0000 On 20.12.2010 17:21, Shtorm wrote: > I had this problem with igb driver, and I found, that lagg selects > outgoing interface based on packet header flowid field if M_FLOWID field > is set. And in the igb driver code flowid is set as > > #if __FreeBSD_version >= 800000 > <------><------><------>rxr->fmp->m_pkthdr.flowid = que->msix; > <------><------><------>rxr->fmp->m_flags |= M_FLOWID; > #endif > > The same thing in em driver with MULTIQUEUE > > That does not give enough number of flows to balance traffic well, so I > commented check in if_lagg.c > > lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) > { > <------>struct lagg_lb *lb = (struct lagg_lb *)sc->sc_psc; > <------>struct lagg_port *lp = NULL; > <------>uint32_t p = 0; > > //<---->if (m->m_flags & M_FLOWID) > //<----><------>p = m->m_pkthdr.flowid; > //<---->else > > and with this change I have much better load distribution across interfaces. > > Hope it helps. Thanks, I'll try. I have em interfaces on lagg0 where problem is. From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 13:34:31 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09BE21065698; Mon, 20 Dec 2010 13:34:31 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D347D8FC08; Mon, 20 Dec 2010 13:34:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKDYURh090312; Mon, 20 Dec 2010 13:34:30 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKDYUdu090307; Mon, 20 Dec 2010 13:34:30 GMT (envelope-from bschmidt) Date: Mon, 20 Dec 2010 13:34:30 GMT Message-Id: <201012201334.oBKDYUdu090307@freefall.freebsd.org> To: nakal@web.de, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/123256: [wpi] panic: blockable sleep lock with wpi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 13:34:31 -0000 Synopsis: [wpi] panic: blockable sleep lock with wpi(4) State-Changed-From-To: open->feedback State-Changed-By: bschmidt State-Changed-When: Mon Dec 20 13:33:04 UTC 2010 State-Changed-Why: Is that still an issue on a recent stable/7 setup? I'm, not able to reproduce this. Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Mon Dec 20 13:33:04 UTC 2010 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=123256 From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 13:36:24 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326FC1065670; Mon, 20 Dec 2010 13:36:24 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 080FC8FC08; Mon, 20 Dec 2010 13:36:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKDaN3k090562; Mon, 20 Dec 2010 13:36:23 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKDaNf8090558; Mon, 20 Dec 2010 13:36:23 GMT (envelope-from bschmidt) Date: Mon, 20 Dec 2010 13:36:23 GMT Message-Id: <201012201336.oBKDaNf8090558@freefall.freebsd.org> To: figyshki@gmail.com, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/127102: [wpi] Intel 3945ABG low throughput X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 13:36:24 -0000 Synopsis: [wpi] Intel 3945ABG low throughput State-Changed-From-To: open->feedback State-Changed-By: bschmidt State-Changed-When: Mon Dec 20 13:35:50 UTC 2010 State-Changed-Why: Is that still an issue on a recent stable/7 setup? Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Mon Dec 20 13:35:50 UTC 2010 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=127102 From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 14:20:12 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB94F106564A for ; Mon, 20 Dec 2010 14:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9F34C8FC1D for ; Mon, 20 Dec 2010 14:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKEKCTR034046 for ; Mon, 20 Dec 2010 14:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKEKCdE034045; Mon, 20 Dec 2010 14:20:12 GMT (envelope-from gnats) Date: Mon, 20 Dec 2010 14:20:12 GMT Message-Id: <201012201420.oBKEKCdE034045@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 14:20:12 -0000 The following reply was made to PR kern/144987; it has been noted by GNATS. From: Bernhard Schmidt To: bug-followup@freebsd.org, gabrielquadros@hotmail.com Cc: Subject: Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic Date: Mon, 20 Dec 2010 15:10:02 +0100 Hi, The issue here is that you've tried to use wlaninject with a VAP in sta mode. As soon as wlaninject tries to set up the interface, net80211 will start to do a scan which means constant channel switches until it finds something to associate. wlaninject itself is not aware of that and happily injects frames no matter what the current channel state is, as the above trace shows, you hit a point where no channel is set between 2 scan interations. wlaninject is supposed to be used with VAPs in ahdemo mode and wpi(4) does not support that mode. Therefore I tend to close this PR. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 14:59:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EABB1065672 for ; Mon, 20 Dec 2010 14:59:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 247948FC2D for ; Mon, 20 Dec 2010 14:59:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C97E546B17; Mon, 20 Dec 2010 09:59:09 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E745E8A029; Mon, 20 Dec 2010 09:59:08 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 20 Dec 2010 08:07:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101220061057.GA36160@zibbi.meraka.csir.co.za> In-Reply-To: <20101220061057.GA36160@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012200807.57670.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 20 Dec 2010 09:59:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: IFT_L2VLAN and IPv6 link-local addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 14:59:10 -0000 On Monday, December 20, 2010 1:10:57 am John Hay wrote: > Hi, > > I see that on FreeBSD-8 if you use IPv6 inside vlans, the local part of > the address (bottom 64 bits) is based on the MAC address of the first > ethernet interface on the system. It was not like this in my old -7, > machine, so I looked around a bit. It looks like it is because vlans were > changed to report their type as IFT_L2VLAN. So I made this patch to the > IPv6 code that fix it for me: > > Index: sys/netinet6/in6_ifattach.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v > retrieving revision 1.74.2.3 > diff -u -U 5 -r1.74.2.3 in6_ifattach.c > --- sys/netinet6/in6_ifattach.c 6 May 2010 06:44:19 -0000 1.74.2.3 > +++ sys/netinet6/in6_ifattach.c 15 Dec 2010 18:33:45 -0000 > @@ -265,10 +265,11 @@ > addrlen = sdl->sdl_alen; > > /* get EUI64 */ > switch (ifp->if_type) { > case IFT_ETHER: > + case IFT_L2VLAN: > case IFT_FDDI: > case IFT_ISO88025: > case IFT_ATM: > case IFT_IEEE1394: > #ifdef IFT_IEEE80211 > > Anything against me committing it? Am I missing something? Should it be > sorted differently? Should it also be merged? This looks correct. Please fix and MFC. I haven't merged the kernel changes to change the type of IFT_ for vlan's yet as I was worried about applications such as this needing to be updated (such as dhcpd for example). I had thought that I had not merged the kernel change to 8 though, that it was just in 9? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 15:20:54 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCA02106566B; Mon, 20 Dec 2010 15:20:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A4D418FC29; Mon, 20 Dec 2010 15:20:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKFKsVn003483; Mon, 20 Dec 2010 15:20:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKFKsFg003472; Mon, 20 Dec 2010 15:20:54 GMT (envelope-from linimon) Date: Mon, 20 Dec 2010 15:20:54 GMT Message-Id: <201012201520.oBKFKsFg003472@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153308: [em] em interface use 100% cpu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 15:20:54 -0000 Old Synopsis: em interface use 100% cpu New Synopsis: [em] em interface use 100% cpu Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 20 15:20:39 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153308 From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 15:56:09 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29BE9106566B; Mon, 20 Dec 2010 15:56:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 237288FC15; Mon, 20 Dec 2010 15:56:07 +0000 (UTC) Received: from alph.d.allbsd.org (p3165-ipbf2308funabasi.chiba.ocn.ne.jp [114.148.246.165]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id oBKFtmAw073545; Tue, 21 Dec 2010 00:55:58 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id oBKFtkuj028897; Tue, 21 Dec 2010 00:55:48 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 21 Dec 2010 00:54:58 +0900 (JST) Message-Id: <20101221.005458.144703395.hrs@allbsd.org> To: jhay@FreeBSD.org From: Hiroki Sato In-Reply-To: <201012200807.57670.jhb@freebsd.org> References: <20101220061057.GA36160@zibbi.meraka.csir.co.za> <201012200807.57670.jhb@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Dec_21_00_54_58_2010_817)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 21 Dec 2010 00:56:02 +0900 (JST) X-Spam-Status: No, score=-98.2 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, FORGED_RCVD_IP, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org, jhb@FreeBSD.org Subject: Re: IFT_L2VLAN and IPv6 link-local addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 15:56:09 -0000 ----Security_Multipart(Tue_Dec_21_00_54_58_2010_817)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Baldwin wrote in <201012200807.57670.jhb@freebsd.org>: jh> On Monday, December 20, 2010 1:10:57 am John Hay wrote: jh> > Hi, jh> > jh> > I see that on FreeBSD-8 if you use IPv6 inside vlans, the local part of jh> > the address (bottom 64 bits) is based on the MAC address of the first jh> > ethernet interface on the system. It was not like this in my old -7, jh> > machine, so I looked around a bit. It looks like it is because vlans were jh> > changed to report their type as IFT_L2VLAN. So I made this patch to the jh> > IPv6 code that fix it for me: jh> > jh> > Index: sys/netinet6/in6_ifattach.c jh> > =================================================================== jh> > RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v jh> > retrieving revision 1.74.2.3 jh> > diff -u -U 5 -r1.74.2.3 in6_ifattach.c jh> > --- sys/netinet6/in6_ifattach.c 6 May 2010 06:44:19 -0000 1.74.2.3 jh> > +++ sys/netinet6/in6_ifattach.c 15 Dec 2010 18:33:45 -0000 jh> > @@ -265,10 +265,11 @@ jh> > addrlen = sdl->sdl_alen; jh> > jh> > /* get EUI64 */ jh> > switch (ifp->if_type) { jh> > case IFT_ETHER: jh> > + case IFT_L2VLAN: jh> > case IFT_FDDI: jh> > case IFT_ISO88025: jh> > case IFT_ATM: jh> > case IFT_IEEE1394: jh> > #ifdef IFT_IEEE80211 jh> > jh> > Anything against me committing it? Am I missing something? Should it be jh> > sorted differently? Should it also be merged? jh> jh> This looks correct. Please fix and MFC. I haven't merged the kernel changes jh> to change the type of IFT_ for vlan's yet as I was worried about applications jh> such as this needing to be updated (such as dhcpd for example). I had thought jh> that I had not merged the kernel change to 8 though, that it was just in 9? Agreed with the fix, but I think both 7.X and 8.X pick the first IF's address anyway. Which log message did you get, "borrow interface identifier from..." or "...got interface identifier from itself" when net.inet6.icmp6.nd6_debug=1 on 7.X and 8.X, respectively? -- Hiroki ----Security_Multipart(Tue_Dec_21_00_54_58_2010_817)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAk0PfFIACgkQTyzT2CeTzy1h4wCeJaHEMhyf3i+yNxZa7Gc7lyhS 4y0AoLBQk5pOySS60nEVIEppIeSaUY8o =ki4p -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Dec_21_00_54_58_2010_817)---- From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 16:39:40 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D53D51065670 for ; Mon, 20 Dec 2010 16:39:40 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 371078FC17 for ; Mon, 20 Dec 2010 16:39:39 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBKGdagG024961 for ; Mon, 20 Dec 2010 22:39:37 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D0F86C3.9020808@rdtc.ru> Date: Mon, 20 Dec 2010 22:39:31 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: igb+lagg: poor input performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 16:39:40 -0000 Hi! I observe some kind of undetected bottle-neck with input traffic processing when traffic goes in through both ports of dual-port 82576-based card grouped to lagg1 (lacp mode). Ports are connected to Cisco 7606 and there are over 800 vlans created on top of lagg1. No output errors or buffer overflows at Cisco side. Cisco distributes traffic over ports just fine. Vlans carry PPPoE frames, I use mpd55 for PPPoE. As number of connected users grows, input traffic and pps grow up to 126Kpps and 560Mbps on lagg1 for 1500 active PPPoE links. Then mrtg draws nearly horizontal lines despite of growing users number. There is no congestion on uplink (lagg0). This system has 4-core Xeon E5507 at 2.27Ghz, hyper-threading disabled. All cores are nearly evenly loaded at level 60-65% only (almost interrupts). Horizontal lines are seen for distinct processor core's load, input traffic for lagg1 and pps for lagg1. I expect much more input traffic. I use 8.2-PRERELEASE/amd64 with latest igb(8) driver version 2.0.7. It has 4G RAM, over 3GB are free. sysctl net.inet.ip.intr_queue_drops shows zero value. /boot/loader.conf: vm.kmem_size=3G # for igb(4) hw.igb.rxd=4096 hw.igb.txd=4096 # for lagg(4) net.link.ifqmaxlen=10240 # for rtsock net.route.netisr_maxqlen=4096 # for ??? net.isr.defaultqlimit=4096 /etc/sysctl.conf: # netisr input queue size net.inet.ip.intr_queue_maxlen=10240 net.inet.ip.fastforwarding=1 net.inet.ip.dummynet.pipe_slot_limit=1000 net.inet.ip.dummynet.io_fast=1 net.isr.direct=0 net.isr.direct_force=0 dev.igb.0.rx_processing_limit=4096 dev.igb.1.rx_processing_limit=4096 kern.ipc.nmbclusters=100000 kern.ipc.nmbjumbop=100000 kern.ipc.maxsockbuf=83886080 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 Where should I dig first? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 17:10:16 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 274C61065670; Mon, 20 Dec 2010 17:10:16 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF2E8FC15; Mon, 20 Dec 2010 17:10:15 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id AB5CC39824; Mon, 20 Dec 2010 19:10:12 +0200 (SAST) Date: Mon, 20 Dec 2010 19:10:12 +0200 From: John Hay To: Hiroki Sato Message-ID: <20101220171012.GB86149@zibbi.meraka.csir.co.za> References: <20101220061057.GA36160@zibbi.meraka.csir.co.za> <201012200807.57670.jhb@freebsd.org> <20101221.005458.144703395.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101221.005458.144703395.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i Cc: jhay@FreeBSD.org, jhb@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: IFT_L2VLAN and IPv6 link-local addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 17:10:16 -0000 Hi Hiroki, On Tue, Dec 21, 2010 at 12:54:58AM +0900, Hiroki Sato wrote: > John Baldwin wrote > in <201012200807.57670.jhb@freebsd.org>: > > jh> On Monday, December 20, 2010 1:10:57 am John Hay wrote: > jh> > Hi, > jh> > > jh> > I see that on FreeBSD-8 if you use IPv6 inside vlans, the local part of > jh> > the address (bottom 64 bits) is based on the MAC address of the first > jh> > ethernet interface on the system. It was not like this in my old -7, > jh> > machine, so I looked around a bit. It looks like it is because vlans were > jh> > changed to report their type as IFT_L2VLAN. So I made this patch to the > jh> > IPv6 code that fix it for me: > jh> > > jh> > Index: sys/netinet6/in6_ifattach.c > jh> > =================================================================== > jh> > RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v > jh> > retrieving revision 1.74.2.3 > jh> > diff -u -U 5 -r1.74.2.3 in6_ifattach.c > jh> > --- sys/netinet6/in6_ifattach.c 6 May 2010 06:44:19 -0000 1.74.2.3 > jh> > +++ sys/netinet6/in6_ifattach.c 15 Dec 2010 18:33:45 -0000 > jh> > @@ -265,10 +265,11 @@ > jh> > addrlen = sdl->sdl_alen; > jh> > > jh> > /* get EUI64 */ > jh> > switch (ifp->if_type) { > jh> > case IFT_ETHER: > jh> > + case IFT_L2VLAN: > jh> > case IFT_FDDI: > jh> > case IFT_ISO88025: > jh> > case IFT_ATM: > jh> > case IFT_IEEE1394: > jh> > #ifdef IFT_IEEE80211 > jh> > > jh> > Anything against me committing it? Am I missing something? Should it be > jh> > sorted differently? Should it also be merged? > jh> > jh> This looks correct. Please fix and MFC. I haven't merged the kernel changes > jh> to change the type of IFT_ for vlan's yet as I was worried about applications > jh> such as this needing to be updated (such as dhcpd for example). I had thought > jh> that I had not merged the kernel change to 8 though, that it was just in 9? > > Agreed with the fix, but I think both 7.X and 8.X pick the first IF's > address anyway. Which log message did you get, "borrow interface > identifier from..." or "...got interface identifier from itself" > when net.inet6.icmp6.nd6_debug=1 on 7.X and 8.X, respectively? You are correct. I forgot that in the 7.x network layout, the ipv6 networks were not in vlans. I just tried it on my old 7.2-PRE box: sysctl net.inet6.icmp6.nd6_debug=1 ifconfig vlan0 create vlandev em2 vlan 1200 ifconfig vlan0 up ifconfig vlan0 vlan0: flags=8843 metric 0 mtu 1500 options=3 ether 00:11:43:dc:fd:78 inet6 fe80::21b:21ff:fe13:2650%vlan0 prefixlen 64 tentative scopeid 0x6 media: Ethernet autoselect (1000baseTX ) status: active vlan: 1200 parent interface: em2 The last part of dmesg: vlan0: borrow interface identifier from em0 vlan0: ifid: 02:1b:21:ff:fe:13:26:50 vlan0: starting DAD for fe80:6::21b:21ff:fe13:2650 vlan0: DAD complete for fe80:6::21b:21ff:fe13:2650 - no duplicates found I also had a better look at if_vlan.c. John's IFT_L2VLAN changes has not been merged, as he remembered. :-) The line ifp->if_type = IFT_L2VLAN; has been there for a long time and his changes only change sdl->sdl_type in any case. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 18:10:14 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A21110656E0 for ; Mon, 20 Dec 2010 18:10:14 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id EB1D38FC08 for ; Mon, 20 Dec 2010 18:10:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id B278813DF5F for ; Mon, 20 Dec 2010 20:53:34 +0300 (MSK) Date: Mon, 20 Dec 2010 20:53:27 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <12810339411.20101220205327@serebryakov.spb.ru> To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: E4500 spend one core to saturate 1Gbit/s link with TCP -- is it nornal? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 18:10:14 -0000 Hello, Freebsd-net. I have file server with Core2Duo E4500 CPU and Intel gigabit adapter (82566DM). FreeBSD 8-STABLE (8.2-PRERELEASE #1: Fri Dec 3 2010) and samba35-3.5.6 are installed. This server could serve about 110MiB/s to one client over CIFS, but one core of CPU is completely busy in such situation: about 60% of CPU is occuped by "ketnel" and 35-40% occuped bu "smbd" accroding to "top -S" ouput. Is it normal, that 2.2GHz core is needed to saturate 1Gib link with only one client (and one TCP connction), or I have something misconfigured? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 19:42:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 214181065695 for ; Mon, 20 Dec 2010 19:42:50 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2C08FC16 for ; Mon, 20 Dec 2010 19:42:49 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBKJgkSO025485; Tue, 21 Dec 2010 01:42:46 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D0FB1B1.7070703@rdtc.ru> Date: Tue, 21 Dec 2010 01:42:41 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Lev Serebryakov References: <12810339411.20101220205327@serebryakov.spb.ru> In-Reply-To: <12810339411.20101220205327@serebryakov.spb.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: E4500 spend one core to saturate 1Gbit/s link with TCP -- is it nornal? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 19:42:50 -0000 On 20.12.2010 23:53, Lev Serebryakov wrote: > I have file server with Core2Duo E4500 CPU and Intel gigabit adapter > (82566DM). > > FreeBSD 8-STABLE (8.2-PRERELEASE #1: Fri Dec 3 2010) and > samba35-3.5.6 are installed. > > This server could serve about 110MiB/s to one client over CIFS, but > one core of CPU is completely busy in such situation: about 60% of CPU > is occuped by "ketnel" and 35-40% occuped bu "smbd" accroding to "top > -S" ouput. > > Is it normal, that 2.2GHz core is needed to saturate 1Gib link with > only one client (and one TCP connction), or I have something > misconfigured? Compare with ftpd that uses sendfile() kernel function. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 20:40:12 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CA7106564A for ; Mon, 20 Dec 2010 20:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E5C3D8FC0C for ; Mon, 20 Dec 2010 20:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKKeB8A042208 for ; Mon, 20 Dec 2010 20:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKKeBl2042206; Mon, 20 Dec 2010 20:40:11 GMT (envelope-from gnats) Date: Mon, 20 Dec 2010 20:40:11 GMT Message-Id: <201012202040.oBKKeBl2042206@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jack Vogel Cc: Subject: Re: misc/153308: em interface use 100% cpu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Vogel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:40:12 -0000 The following reply was made to PR kern/153308; it has been noted by GNATS. From: Jack Vogel To: Yusuf Ozbilgin Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/153308: em interface use 100% cpu Date: Mon, 20 Dec 2010 12:09:43 -0800 --20cf305644b1d0fc980497dd19d4 Content-Type: text/plain; charset=ISO-8859-1 So, use current code, this is ancient, its actually a 82575 which is now supported by the igb driver rather than em. Try the prerelease code for 8.2 or 7.4. Should also point out that the bug is mistitled, natd uses 100%, it does not follow its em, although that might be a likely suspect, it could be an internal natd bug too afterall... Jack On Mon, Dec 20, 2010 at 6:25 AM, Yusuf Ozbilgin wrote: > > >Number: 153308 > >Category: misc > >Synopsis: em interface use 100% cpu > >Confidential: no > >Severity: serious > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Mon Dec 20 14:30:11 UTC 2010 > >Closed-Date: > >Last-Modified: > >Originator: Yusuf Ozbilgin > >Release: Freebsd 7.3 > >Organization: > Gunes Bilg. A.S > >Environment: > FreeBSD firewall.test.local 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #0: Wed > Sep 22 17:41:32 EEST 2010 root@firewall.test.local:/usr/obj/usr/src/sys/GATEWAY-FW > i386 > >Description: > After installing freebsd as a gateway, natd use 100% cpu without any > network load, I am using em interfaces. I updated kernel and recompiled but > nothing changed. > > > > em0@pci0:1:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > 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 max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > top > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1592 root 1 112 0 3348K 1316K RUN 0 0:38 85.09% natd > 1899 postfix 1 4 0 24600K 21336K kqread 0 0:06 0.00% qmgr > 1762 root 1 44 0 39132K 36772K select 0 0:03 0.00% perl > > > > >How-To-Repeat: > Always > >Fix: > > > >Release-Note: > >Audit-Trail: > >Unformatted: > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" > --20cf305644b1d0fc980497dd19d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, use current code, this is ancient, its actually a 82575 which is now su= pported
by the igb driver rather than em. Try the prerelease code for 8.= 2 or 7.4.

Should also point out that the bug is mistitled, natd uses= 100%, it does not
follow its em, although that might be a likely suspect, it could be an inte= rnal
natd bug too afterall...

Jack


On Mon, Dec 20, 2010 at 6:25 AM, Yusuf Ozbilgin &= lt;yusuf@gunes.net> wrote:=

>Number: =A0 =A0 =A0 =A0 153308
>Category: =A0 =A0 =A0 misc
>Synopsis: =A0 =A0 =A0 em interface use 100% cpu
>Confidential: =A0 no
>Severity: =A0 =A0 =A0 serious
>Priority: =A0 =A0 =A0 high
>Responsible: =A0 =A0freebsd-bugs
>State: =A0 =A0 =A0 =A0 =A0open
>Quarter:
>Keywords:
>Date-Required:
>Class: =A0 =A0 =A0 =A0 =A0sw-bug
>Submitter-Id: =A0 current-users
>Arrival-Date: =A0 Mon Dec 20 14:30:11 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: =A0 =A0 Yusuf Ozbilgin
>Release: =A0 =A0 =A0 =A0Freebsd 7.3
>Organization:
Gunes Bilg. A.S
>Environment:
FreeBSD firewall.test.local 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #0: Wed S= ep 22 17:41:32 EEST 2010 =A0 =A0 root@firewall.test.local:/usr/obj/usr/src/= sys/GATEWAY-FW =A0i386
>Description:
After installing freebsd as a gateway, natd use 100% cpu without any networ= k load, I am using em interfaces. I updated kernel and recompiled but nothi= ng changed.



em0@pci0:1:0:0: class=3D0x020000 card=3D0x00008086 chip=3D0x10d38086 rev=3D= 0x00 hdr=3D0x00
=A0 =A0vendor =A0 =A0 =3D 'Intel Corporation'
=A0 =A0class =A0 =A0 =A0=3D network
=A0 =A0subclass =A0 =3D ethernet
=A0 =A0cap 01[c8] =3D powerspec 2 =A0supports D0 D3 =A0current D0
=A0 =A0cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 messag= e
=A0 =A0cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1)=
=A0 =A0cap 11[a0] =3D MSI-X supports 5 messages in map 0x1c

top

=A0PID USERNAME =A0 =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0 TI= ME =A0 WCPU COMMAND
=A01592 root =A0 =A0 =A0 =A0 =A01 112 =A0 =A00 =A03348K =A01316K RUN =A0 = =A0 0 =A0 0:38 85.09% natd
=A01899 postfix =A0 =A0 =A0 1 =A0 4 =A0 =A00 24600K 21336K kqread =A00 =A0 = 0:06 =A00.00% qmgr
=A01762 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 39132K 36772K select =A00 = =A0 0:03 =A00.00% perl



>How-To-Repeat:
Always
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs@freebsd.org ma= iling list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"

--20cf305644b1d0fc980497dd19d4-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 20:42:49 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B66CA106566C for ; Mon, 20 Dec 2010 20:42:49 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 730D38FC15 for ; Mon, 20 Dec 2010 20:42:49 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 3AD9313DF5F; Mon, 20 Dec 2010 23:42:48 +0300 (MSK) Date: Mon, 20 Dec 2010 23:42:41 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1715104467.20101220234241@serebryakov.spb.ru> To: freebsd-net@FreeBSD.org In-Reply-To: <12810339411.20101220205327@serebryakov.spb.ru> References: <12810339411.20101220205327@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@FreeBSD.org Subject: Re: E4500 spend one core to saturate 1Gbit/s link with TCP -- is it nornal? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:42:49 -0000 Hello, Freebsd-net. You wrote 20 =E4=E5=EA=E0=E1=F0=FF 2010 =E3., 20:53:27: > I have file server with Core2Duo E4500 CPU and Intel gigabit adapter > (82566DM). > FreeBSD 8-STABLE (8.2-PRERELEASE #1: Fri Dec 3 2010) and > samba35-3.5.6 are installed. > This server could serve about 110MiB/s to one client over CIFS, but > one core of CPU is completely busy in such situation: about 60% of CPU > is occuped by "ketnel" and 35-40% occuped bu "smbd" accroding to "top > -S" ouput. > Is it normal, that 2.2GHz core is needed to saturate 1Gib link with > only one client (and one TCP connction), or I have something > misconfigured? Ok, pressing "H" in "top" shows, that all this CPU goes to "{em0 tasq}" thread. And, yes, I have all rxd/trd and other tunables set to recommended high values. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon Dec 20 20:45:01 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C37A10656B4 for ; Mon, 20 Dec 2010 20:45:01 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 150B48FC15 for ; Mon, 20 Dec 2010 20:45:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 4CA1C13DF5F; Mon, 20 Dec 2010 23:45:00 +0300 (MSK) Date: Mon, 20 Dec 2010 23:44:53 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1647893939.20101220234453@serebryakov.spb.ru> To: Eugene Grosbein In-Reply-To: <4D0FB1B1.7070703@rdtc.ru> References: <12810339411.20101220205327@serebryakov.spb.ru> <4D0FB1B1.7070703@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: E4500 spend one core to saturate 1Gbit/s link with TCP -- is it nornal? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:45:01 -0000 Hello, Eugene. You wrote 20 =E4=E5=EA=E0=E1=F0=FF 2010 =E3., 22:42:41: >> Is it normal, that 2.2GHz core is needed to saturate 1Gib link with >> only one client (and one TCP connction), or I have something >> misconfigured? > Compare with ftpd that uses sendfile() kernel function. simple "iperf" shows almost same load (slightly less, but it shows slightly less speed, about 800Mbit). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 06:19:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A924A106564A for ; Tue, 21 Dec 2010 06:19:56 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 0510F8FC25 for ; Tue, 21 Dec 2010 06:19:55 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBL6Jpiv029175; Tue, 21 Dec 2010 12:19:52 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D104702.40208@rdtc.ru> Date: Tue, 21 Dec 2010 12:19:46 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Lev Serebryakov References: <12810339411.20101220205327@serebryakov.spb.ru> <4D0FB1B1.7070703@rdtc.ru> <1647893939.20101220234453@serebryakov.spb.ru> In-Reply-To: <1647893939.20101220234453@serebryakov.spb.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: E4500 spend one core to saturate 1Gbit/s link with TCP -- is it nornal? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 06:19:56 -0000 On 21.12.2010 02:44, Lev Serebryakov wrote: > Hello, Eugene. > You wrote 20 ÄÅËÁÂÒÑ 2010 Ç., 22:42:41: > >>> Is it normal, that 2.2GHz core is needed to saturate 1Gib link with >>> only one client (and one TCP connction), or I have something >>> misconfigured? >> Compare with ftpd that uses sendfile() kernel function. > simple "iperf" shows almost same load (slightly less, but it shows > slightly less speed, about 800Mbit). > iperf is bad tool IMHO, it abuses gettimeofday() system call and wastes too much CPU time. Compare with ftpd that uses sendfile() kernel function. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 07:32:25 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3218E10656A5 for ; Tue, 21 Dec 2010 07:32:25 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 9173D8FC2A for ; Tue, 21 Dec 2010 07:32:24 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBL7WLBc029819; Tue, 21 Dec 2010 13:32:21 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D105800.2070808@rdtc.ru> Date: Tue, 21 Dec 2010 13:32:16 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Shtorm References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> In-Reply-To: <1292844095.1917.136.camel@stormi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 07:32:25 -0000 On 20.12.2010 17:21, Shtorm wrote: > I had this problem with igb driver, and I found, that lagg selects > outgoing interface based on packet header flowid field if M_FLOWID field > is set. And in the igb driver code flowid is set as > > #if __FreeBSD_version >= 800000 > <------><------><------>rxr->fmp->m_pkthdr.flowid = que->msix; > <------><------><------>rxr->fmp->m_flags |= M_FLOWID; > #endif > > The same thing in em driver with MULTIQUEUE > > That does not give enough number of flows to balance traffic well, so I > commented check in if_lagg.c > > lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) > { > <------>struct lagg_lb *lb = (struct lagg_lb *)sc->sc_psc; > <------>struct lagg_port *lp = NULL; > <------>uint32_t p = 0; > > //<---->if (m->m_flags & M_FLOWID) > //<----><------>p = m->m_pkthdr.flowid; > //<---->else > > and with this change I have much better load distribution across interfaces. > > Hope it helps. > I've made new sysctl net.link.lagg.use_flows to enable/disable this code in run time and disabled it. No change. --- if_lagg.c.orig 2010-12-20 22:53:21.000000000 +0600 +++ if_lagg.c 2010-12-20 22:57:50.000000000 +0600 @@ -168,6 +168,11 @@ &lagg_failover_rx_all, 0, "Accept input from any interface in a failover lagg"); +static int lagg_use_flows = 1; +SYSCTL_INT(_net_link_lagg, OID_AUTO, use_flows, CTLFLAG_RW, + &lagg_use_flows, 1, + "Use flows for load sharing"); + static int lagg_modevent(module_t mod, int type, void *data) { @@ -1666,7 +1671,7 @@ struct lagg_port *lp = NULL; uint32_t p = 0; - if (m->m_flags & M_FLOWID) + if (lagg_use_flows && (m->m_flags & M_FLOWID)) p = m->m_pkthdr.flowid; else p = lagg_hashmbuf(m, lb->lb_key); From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 07:41:27 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56761106564A for ; Tue, 21 Dec 2010 07:41:27 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id B50798FC1D for ; Tue, 21 Dec 2010 07:41:26 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBL7fPn6029855; Tue, 21 Dec 2010 13:41:25 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D105A20.306@rdtc.ru> Date: Tue, 21 Dec 2010 13:41:20 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Shtorm References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D105800.2070808@rdtc.ru> In-Reply-To: <4D105800.2070808@rdtc.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 07:41:27 -0000 On 21.12.2010 13:32, Eugene Grosbein wrote: >> I had this problem with igb driver, and I found, that lagg selects >> outgoing interface based on packet header flowid field if M_FLOWID field >> is set. And in the igb driver code flowid is set as >> >> #if __FreeBSD_version >= 800000 >> <------><------><------>rxr->fmp->m_pkthdr.flowid = que->msix; >> <------><------><------>rxr->fmp->m_flags |= M_FLOWID; >> #endif >> >> The same thing in em driver with MULTIQUEUE >> >> That does not give enough number of flows to balance traffic well, so I >> commented check in if_lagg.c >> >> lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) >> { >> <------>struct lagg_lb *lb = (struct lagg_lb *)sc->sc_psc; >> <------>struct lagg_port *lp = NULL; >> <------>uint32_t p = 0; >> >> //<---->if (m->m_flags & M_FLOWID) >> //<----><------>p = m->m_pkthdr.flowid; >> //<---->else >> >> and with this change I have much better load distribution across interfaces. >> >> Hope it helps. >> > > I've made new sysctl net.link.lagg.use_flows to enable/disable > this code in run time and disabled it. No change. > > --- if_lagg.c.orig 2010-12-20 22:53:21.000000000 +0600 > +++ if_lagg.c 2010-12-20 22:57:50.000000000 +0600 I've just found LACP mode does not use code in place I've patched. Instead, I should make the change to lacp_select_tx_port() into ieee8023ad_lacp.c. Sorry for noise, I'll try again. From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 09:52:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94691065696 for ; Tue, 21 Dec 2010 09:52:13 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 656058FC08 for ; Tue, 21 Dec 2010 09:52:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 69AC913DF5F; Tue, 21 Dec 2010 12:52:12 +0300 (MSK) Date: Tue, 21 Dec 2010 12:52:05 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1983605521.20101221125205@serebryakov.spb.ru> To: Eugene Grosbein In-Reply-To: <4D104702.40208@rdtc.ru> References: <12810339411.20101220205327@serebryakov.spb.ru> <4D0FB1B1.7070703@rdtc.ru> <1647893939.20101220234453@serebryakov.spb.ru> <4D104702.40208@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: E4500 spend one core to saturate 1Gbit/s link with TCP -- is it nornal? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 09:52:13 -0000 Hello, Eugene. You wrote 21 =C4=C5=CB=C1=C2=D2=D1 2010 =C7., 9:19:46: >>>> Is it normal, that 2.2GHz core is needed to saturate 1Gib link with >>>> only one client (and one TCP connction), or I have something >>>> misconfigured? >>> Compare with ftpd that uses sendfile() kernel function. >> simple "iperf" shows almost same load (slightly less, but it shows >> slightly less speed, about 800Mbit). >>=20 > iperf is bad tool IMHO, it abuses gettimeofday() system call and wastes t= oo much CPU time. > Compare with ftpd that uses sendfile() kernel function. system ftpd twice slower (or I can not find good FTP client for Windowsn -- I've tried FAR, wget/cygwin and "native" ftp), but load is significally less. On the other hand, when I rebuilt kernelk wit DEVICE_POLLING and turned polling on, load decrease to 10-15% of one core in case of samba :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 10:39:26 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D47B106566B for ; Tue, 21 Dec 2010 10:39:26 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 81DA88FC0C for ; Tue, 21 Dec 2010 10:39:25 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBLAdN13031561; Tue, 21 Dec 2010 16:39:23 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D1083D6.6010707@rdtc.ru> Date: Tue, 21 Dec 2010 16:39:18 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Shtorm References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> In-Reply-To: <1292844095.1917.136.camel@stormi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 10:39:26 -0000 On 20.12.2010 17:21, Shtorm wrote: > On Sun, 2010-12-19 at 00:35 +0600, Eugene Grosbein wrote: >> Hi! >> >> I've loaded router using two lagg interfaces in LACP mode. >> lagg0 has IP address and two ports (em0 and em1) and carry untagged frames. >> lagg1 has no IP address and has two ports (igb0 and igb1) and carry >> about 1000 dot-q vlans with lots of hosts in each vlan. >> >> For lagg1, lagg distributes outgoing traffic over two ports just fine. >> For lagg0 (untagged ethernet segment with only 2 MAC addresses) >> less than 0.07% (54Mbit/s max) of traffic goes to em0 >> and over 99.92% goes to em1, that's bad. >> >> That's general traffic of several thousands of customers surfing the web, >> using torrents etc. I've glanced over lagg/lacp sources if src/sys/net/ >> and found nothing suspicious, it should extract and use srcIP/dstIP for hash. >> >> How do I debug this problem? >> >> 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" > > I had this problem with igb driver, and I found, that lagg selects > outgoing interface based on packet header flowid field if M_FLOWID field > is set. And in the igb driver code flowid is set as > > #if __FreeBSD_version >= 800000 > <------><------><------>rxr->fmp->m_pkthdr.flowid = que->msix; > <------><------><------>rxr->fmp->m_flags |= M_FLOWID; > #endif > > The same thing in em driver with MULTIQUEUE > > That does not give enough number of flows to balance traffic well, so I > commented check in if_lagg.c > > lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) > { > <------>struct lagg_lb *lb = (struct lagg_lb *)sc->sc_psc; > <------>struct lagg_port *lp = NULL; > <------>uint32_t p = 0; > > //<---->if (m->m_flags & M_FLOWID) > //<----><------>p = m->m_pkthdr.flowid; > //<---->else > > and with this change I have much better load distribution across interfaces. > > Hope it helps. You are perfectly right. By disabling flow usage I've obtained load sharing close to even (final patch follows). Two questions: 1. Is it a bug or design problem? 2. Will I get problems like packet reordering by permanently disabling usage of these flows in lagg(4)? --- if_lagg.c.orig 2010-12-20 22:53:21.000000000 +0600 +++ if_lagg.c 2010-12-21 13:37:20.000000000 +0600 @@ -168,6 +168,11 @@ &lagg_failover_rx_all, 0, "Accept input from any interface in a failover lagg"); +int lagg_use_flows = 1; +SYSCTL_INT(_net_link_lagg, OID_AUTO, use_flows, CTLFLAG_RW, + &lagg_use_flows, 1, + "Use flows for load sharing"); + static int lagg_modevent(module_t mod, int type, void *data) { @@ -1666,7 +1671,7 @@ struct lagg_port *lp = NULL; uint32_t p = 0; - if (m->m_flags & M_FLOWID) + if (lagg_use_flows && (m->m_flags & M_FLOWID)) p = m->m_pkthdr.flowid; else p = lagg_hashmbuf(m, lb->lb_key); --- if_lagg.h.orig 2010-12-21 16:34:35.000000000 +0600 +++ if_lagg.h 2010-12-21 16:35:27.000000000 +0600 @@ -242,6 +242,8 @@ int lagg_enqueue(struct ifnet *, struct mbuf *); uint32_t lagg_hashmbuf(struct mbuf *, uint32_t); +extern int lagg_use_flows; + #endif /* _KERNEL */ #endif /* _NET_LAGG_H */ --- ieee8023ad_lacp.c.orig 2010-12-21 16:36:09.000000000 +0600 +++ ieee8023ad_lacp.c 2010-12-21 16:35:58.000000000 +0600 @@ -812,7 +812,7 @@ return (NULL); } - if (m->m_flags & M_FLOWID) + if (lagg_use_flows && (m->m_flags & M_FLOWID)) hash = m->m_pkthdr.flowid; else hash = lagg_hashmbuf(m, lsc->lsc_hashkey); Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 11:57:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C630E1065670 for ; Tue, 21 Dec 2010 11:57:33 +0000 (UTC) (envelope-from hedayati.mo@gmail.com) Received: from mail-ww0-f68.google.com (mail-ww0-f68.google.com [74.125.82.68]) by mx1.freebsd.org (Postfix) with ESMTP id 60A8D8FC19 for ; Tue, 21 Dec 2010 11:57:32 +0000 (UTC) Received: by wwj40 with SMTP id 40so1458061wwj.7 for ; Tue, 21 Dec 2010 03:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=AtiqQBG8nFgmp/NF3SeCbasfepWKXiWfi+etaEpbEoo=; b=lJRGZcixYi83nr7p2rpEyBc+Dr2XxvmLKG+4JM07RlkAPYK1jzeKmx2k0L1jvfOOew o7brzSKNipgiGcR6Za3FqJM3CNnP5NVPcb9t3Bm57p6lwRJZZLaFIrGVl1rzrLAMoNrE dxRohZM+hYHgJq3DVJtRTZQZoFgebhvBpSJ4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=NGnpinRxHoJ2t/dmVmeKBNcQu+1E22+GfDRH/dtuMZLF6vyW9wbcrjp2OgI3wF5/dA OCbiFXGoeZ3CM/fZ5gXJb7XuWQT5b2fQbVO6scqsYUPzgyFNrLdn2wbzvIwTrlGDMbKn tVoMZfCGRfXEBt7ZcOLTIZRP2b9nydYs3odKU= Received: by 10.227.159.68 with SMTP id i4mr3355294wbx.176.1292931611680; Tue, 21 Dec 2010 03:40:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.202 with HTTP; Tue, 21 Dec 2010 03:39:26 -0800 (PST) From: Mohammad Hedayati Date: Tue, 21 Dec 2010 15:09:26 +0330 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: SOCK_STREAM socket in kernel space X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 11:57:33 -0000 I'm about to use a char device for a kind of distributed processing, so I've coded the open function as follows. The problem is that soaccept returns 0 without populating the raddr. I've checked netstat, everything seems to be fine, the socket is created, bound and the state is LISTENING. Even the remote is connection is ESTABLISHED. But, it cannot receive anything. it says that socket (sock variable) is not connected. int open(struct cdev *dev, int flag, int otyp, struct thread *td) { uprintf("in open...\n"); int error = -1; socktd = td; error = socreate(AF_INET, &sock, SOCK_STREAM, IPPROTO_TCP, td->td_proc->p_ucred, socktd); if(error != 0) return error; sockaddr.sin_len = sizeof(struct sockaddr_in); sockaddr.sin_family = AF_INET; sockaddr.sin_port = htons(1234); sockaddr.sin_addr.s_addr = INADDR_ANY; error = sobind(sock, (struct sockaddr *)&sockaddr, socktd); uprintf("sobind error = %d\n", error); error = solisten(sock, 5, socktd); uprintf("solisten error = %d\n", error); error = soaccept(sock, (struct sockaddr **)&raddr); uprintf("soaccept error = %d, ip=%s\n", error, inet_ntoa(raddr->sin_addr)); uprintf("out open...\n"); return(error); } int read(struct cdev *dev, struct uio *uio, int ioflag) { int error = 0; error = soreceive(sock, (struct sockaddr **)&raddr, uio, NULL, NULL, NULL); return(error); } From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 12:55:46 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61A101065672 for ; Tue, 21 Dec 2010 12:55:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 33D858FC1C for ; Tue, 21 Dec 2010 12:55:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C438F46B52; Tue, 21 Dec 2010 07:55:45 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 02E1A8A009; Tue, 21 Dec 2010 07:55:45 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Tue, 21 Dec 2010 07:53:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201012210753.43916.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 21 Dec 2010 07:55:45 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Mohammad Hedayati Subject: Re: SOCK_STREAM socket in kernel space X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 12:55:46 -0000 On Tuesday, December 21, 2010 6:39:26 am Mohammad Hedayati wrote: > I'm about to use a char device for a kind of distributed processing, > so I've coded the open function as follows. The problem is that > soaccept returns 0 without populating the raddr. I've checked netstat, > everything seems to be fine, the socket is created, bound and the > state is LISTENING. Even the remote is connection is ESTABLISHED. But, > it cannot receive anything. it says that socket (sock variable) is > not connected. Yes, you are calling soaccept() on the wrong socket. You need to wait for a connection and dequeue the socket that connected and then call soaccept() on that new socket. Look at kern_accept() in sys/kern/uipc_syscalls.c. I wonder though if you wouldn't rather be calling soconnect instead? Do you really need to listen for new connections? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 13:27:45 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6A0A1065672 for ; Tue, 21 Dec 2010 13:27:44 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48ABB8FC1C for ; Tue, 21 Dec 2010 13:27:43 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 948A774000C; Tue, 21 Dec 2010 14:09:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: <4D1083D6.6010707@rdtc.ru> Date: Tue, 21 Dec 2010 14:11:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1082) Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 13:27:45 -0000 >>> Hi! >>>=20 >>> I've loaded router using two lagg interfaces in LACP mode. >>> lagg0 has IP address and two ports (em0 and em1) and carry untagged = frames. >>> lagg1 has no IP address and has two ports (igb0 and igb1) and carry >>> about 1000 dot-q vlans with lots of hosts in each vlan. >>>=20 >>> For lagg1, lagg distributes outgoing traffic over two ports just = fine. >>> For lagg0 (untagged ethernet segment with only 2 MAC addresses) >>> less than 0.07% (54Mbit/s max) of traffic goes to em0 >>> and over 99.92% goes to em1, that's bad. >>>=20 >>> That's general traffic of several thousands of customers surfing the = web, >>> using torrents etc. I've glanced over lagg/lacp sources if = src/sys/net/ >>> and found nothing suspicious, it should extract and use srcIP/dstIP = for hash. >>>=20 >>> How do I debug this problem? >>>=20 >>> 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" >>=20 >> I had this problem with igb driver, and I found, that lagg selects >> outgoing interface based on packet header flowid field if M_FLOWID = field >> is set. And in the igb driver code flowid is set as=20 >>=20 >> #if __FreeBSD_version >=3D 800000 >> <------><------><------>rxr->fmp->m_pkthdr.flowid =3D que->msix; >> <------><------><------>rxr->fmp->m_flags |=3D M_FLOWID; >> #endif >>=20 >> The same thing in em driver with MULTIQUEUE=20 >>=20 >> That does not give enough number of flows to balance traffic well, so = I >> commented check in if_lagg.c >>=20 >> lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) >> { >> <------>struct lagg_lb *lb =3D (struct lagg_lb *)sc->sc_psc; >> <------>struct lagg_port *lp =3D NULL; >> <------>uint32_t p =3D 0; >>=20 >> //<---->if (m->m_flags & M_FLOWID) >> //<----><------>p =3D m->m_pkthdr.flowid; >> //<---->else >>=20 >> and with this change I have much better load distribution across = interfaces. >>=20 >> Hope it helps. >=20 > You are perfectly right. By disabling flow usage I've obtained load = sharing > close to even (final patch follows). Two questions: >=20 > 1. Is it a bug or design problem? How many queues have you with igb? If it's one it will explain why the = flowid is bad for load balancing with lagg. The problem is that flowid is good if the number of queue is =3D or a = multiple of the number of lagg ports. > 2. Will I get problems like packet reordering by permanently disabling > usage of these flows in lagg(4)? >=20 > --- if_lagg.c.orig 2010-12-20 22:53:21.000000000 +0600 > +++ if_lagg.c 2010-12-21 13:37:20.000000000 +0600 > @@ -168,6 +168,11 @@ > &lagg_failover_rx_all, 0, > "Accept input from any interface in a failover lagg"); >=20 > +int lagg_use_flows =3D 1; > +SYSCTL_INT(_net_link_lagg, OID_AUTO, use_flows, CTLFLAG_RW, > + &lagg_use_flows, 1, > + "Use flows for load sharing"); > + > static int > lagg_modevent(module_t mod, int type, void *data) > { > @@ -1666,7 +1671,7 @@ > struct lagg_port *lp =3D NULL; > uint32_t p =3D 0; >=20 > - if (m->m_flags & M_FLOWID) > + if (lagg_use_flows && (m->m_flags & M_FLOWID)) > p =3D m->m_pkthdr.flowid; > else > p =3D lagg_hashmbuf(m, lb->lb_key); > --- if_lagg.h.orig 2010-12-21 16:34:35.000000000 +0600 > +++ if_lagg.h 2010-12-21 16:35:27.000000000 +0600 > @@ -242,6 +242,8 @@ > int lagg_enqueue(struct ifnet *, struct mbuf *); > uint32_t lagg_hashmbuf(struct mbuf *, uint32_t); >=20 > +extern int lagg_use_flows; > + > #endif /* _KERNEL */ >=20 > #endif /* _NET_LAGG_H */ > --- ieee8023ad_lacp.c.orig 2010-12-21 16:36:09.000000000 +0600 > +++ ieee8023ad_lacp.c 2010-12-21 16:35:58.000000000 +0600 > @@ -812,7 +812,7 @@ > return (NULL); > } >=20 > - if (m->m_flags & M_FLOWID) > + if (lagg_use_flows && (m->m_flags & M_FLOWID)) > hash =3D m->m_pkthdr.flowid; > else > hash =3D lagg_hashmbuf(m, lsc->lsc_hashkey); >=20 > 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" From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 14:11:30 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90A91106566C for ; Tue, 21 Dec 2010 14:11:30 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id F3AE88FC1D for ; Tue, 21 Dec 2010 14:11:29 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oBLE0KOY002079; Tue, 21 Dec 2010 20:00:21 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D10B2F4.1060404@rdtc.ru> Date: Tue, 21 Dec 2010 20:00:20 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Fabien Thomas References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> In-Reply-To: <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 14:11:30 -0000 On 21.12.2010 19:11, Fabien Thomas wrote: >>> I had this problem with igb driver, and I found, that lagg selects >>> outgoing interface based on packet header flowid field if M_FLOWID field >>> is set. And in the igb driver code flowid is set as >>> >>> #if __FreeBSD_version >= 800000 >>> <------><------><------>rxr->fmp->m_pkthdr.flowid = que->msix; >>> <------><------><------>rxr->fmp->m_flags |= M_FLOWID; >>> #endif >>> >>> The same thing in em driver with MULTIQUEUE >>> >>> That does not give enough number of flows to balance traffic well, so I >>> commented check in if_lagg.c >>> >>> lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) >>> { >>> <------>struct lagg_lb *lb = (struct lagg_lb *)sc->sc_psc; >>> <------>struct lagg_port *lp = NULL; >>> <------>uint32_t p = 0; >>> >>> //<---->if (m->m_flags & M_FLOWID) >>> //<----><------>p = m->m_pkthdr.flowid; >>> //<---->else >>> >>> and with this change I have much better load distribution across interfaces. >>> >>> Hope it helps. >> >> You are perfectly right. By disabling flow usage I've obtained load sharing >> close to even (final patch follows). Two questions: >> >> 1. Is it a bug or design problem? > > How many queues have you with igb? If it's one it will explain why the flowid is bad for load balancing with lagg. How do I know? I've read igb(4) manual page and found no words about queues within igb, nor I have any knowledge about them. > The problem is that flowid is good if the number of queue is = or a multiple of the number of lagg ports. Now I see, thanks. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 14:41:59 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B08841065674 for ; Tue, 21 Dec 2010 14:41:59 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA4B8FC0C for ; Tue, 21 Dec 2010 14:41:58 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 96C6B740008; Tue, 21 Dec 2010 15:39:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: <4D10B2F4.1060404@rdtc.ru> Date: Tue, 21 Dec 2010 15:41:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> <4D10B2F4.1060404@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1082) Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 14:41:59 -0000 On Dec 21, 2010, at 3:00 PM, Eugene Grosbein wrote: > On 21.12.2010 19:11, Fabien Thomas wrote: >=20 >>>> I had this problem with igb driver, and I found, that lagg selects >>>> outgoing interface based on packet header flowid field if M_FLOWID = field >>>> is set. And in the igb driver code flowid is set as=20 >>>>=20 >>>> #if __FreeBSD_version >=3D 800000 >>>> <------><------><------>rxr->fmp->m_pkthdr.flowid =3D que->msix; >>>> <------><------><------>rxr->fmp->m_flags |=3D M_FLOWID; >>>> #endif >>>>=20 >>>> The same thing in em driver with MULTIQUEUE=20 >>>>=20 >>>> That does not give enough number of flows to balance traffic well, = so I >>>> commented check in if_lagg.c >>>>=20 >>>> lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) >>>> { >>>> <------>struct lagg_lb *lb =3D (struct lagg_lb *)sc->sc_psc; >>>> <------>struct lagg_port *lp =3D NULL; >>>> <------>uint32_t p =3D 0; >>>>=20 >>>> //<---->if (m->m_flags & M_FLOWID) >>>> //<----><------>p =3D m->m_pkthdr.flowid; >>>> //<---->else >>>>=20 >>>> and with this change I have much better load distribution across = interfaces. >>>>=20 >>>> Hope it helps. >>>=20 >>> You are perfectly right. By disabling flow usage I've obtained load = sharing >>> close to even (final patch follows). Two questions: >>>=20 >>> 1. Is it a bug or design problem? >>=20 >> How many queues have you with igb? If it's one it will explain why = the flowid is bad for load balancing with lagg. >=20 > How do I know? I've read igb(4) manual page and found no words vmstat -i will show the queue (intr for the queue) normally it's the = number of CPU available. > about queues within igb, nor I have any knowledge about them. >=20 >> The problem is that flowid is good if the number of queue is =3D or a = multiple of the number of lagg ports. >=20 > Now I see, thanks. >=20 > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 14:48:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632DC106566B for ; Tue, 21 Dec 2010 14:48:33 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9D88FC0C for ; Tue, 21 Dec 2010 14:48:31 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oBLEmUvs002180; Tue, 21 Dec 2010 20:48:30 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D10BE3E.6030506@rdtc.ru> Date: Tue, 21 Dec 2010 20:48:30 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Fabien Thomas References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> <4D10B2F4.1060404@rdtc.ru> <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> In-Reply-To: <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 14:48:33 -0000 On 21.12.2010 20:41, Fabien Thomas wrote: >>>> 1. Is it a bug or design problem? >>> >>> How many queues have you with igb? If it's one it will explain why the flowid is bad for load balancing with lagg. >> >> How do I know? I've read igb(4) manual page and found no words > vmstat -i will show the queue (intr for the queue) normally it's the number of CPU available. # vmstat -i interrupt total rate irq5: uart2 8 0 irq18: ehci0 uhci5+ 2 0 irq19: uhci2 uhci4+ 2182 0 irq23: uhci3 ehci1 124 0 cpu0: timer 39576224 1993 irq256: em0:rx 0 115571349 5822 irq257: em0:tx 0 136632905 6883 irq259: em1:rx 0 115829181 5835 irq260: em1:tx 0 138838991 6994 irq262: igb0:que 0 157354922 7927 irq263: igb0:que 1 577369 29 irq264: igb0:que 2 280207 14 irq265: igb0:que 3 241826 12 irq266: igb0:link 2 0 irq267: igb1:que 0 164620363 8293 irq268: igb1:que 1 238678 12 irq269: igb1:que 2 248478 12 irq270: igb1:que 3 762453 38 irq271: igb1:link 3 0 cpu2: timer 39576052 1993 cpu3: timer 39576095 1993 cpu1: timer 39575913 1993 Total 989503327 49849 It seems I have four queues per igb card but only one of them works? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 15:24:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C06D01065679 for ; Tue, 21 Dec 2010 15:24:23 +0000 (UTC) (envelope-from hedayati.mo@gmail.com) Received: from mail-wy0-f196.google.com (mail-wy0-f196.google.com [74.125.82.196]) by mx1.freebsd.org (Postfix) with ESMTP id 548F98FC22 for ; Tue, 21 Dec 2010 15:24:22 +0000 (UTC) Received: by wyb40 with SMTP id 40so1524401wyb.7 for ; Tue, 21 Dec 2010 07:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=YLbat6/4ndC+aIT5vu1xno9Z5oVFSgu8/GRRBqOAC0Q=; b=EoPpVaFQLrHLPWFNlt1ICHes1l+qgoI06fS3LCwlgmTxzlKwQ35Efnxaqg/lSEtIol 2n3MKfuOs9nvVKP02IEjoNdV4WYB2MwJnPt4r9oIjRl4VR0r+GMpf+OHHjRA5zER1723 fS3/Yw0M98TmTj1wQpvToJHAQP7tqKm1edjnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=PVFvhUR3BzLFcjPUvHmmChCsyrRARx1XHZQOS+tW7kGQwfqTOq+b3PPQ2IjBS518Q5 THaARCWnQYmqVBK4q2XTRxx4QwncBghrpZp52uuig7i2rP8OW+kXBhWY4+bfegZ5nhAM frZiFxxG/p68nxBTswtyfwVk1NDYxCJ2kliOg= Received: by 10.227.146.145 with SMTP id h17mr3469655wbv.60.1292945062098; Tue, 21 Dec 2010 07:24:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.202 with HTTP; Tue, 21 Dec 2010 07:23:42 -0800 (PST) In-Reply-To: <201012210753.43916.jhb@freebsd.org> References: <201012210753.43916.jhb@freebsd.org> From: Mohammad Hedayati Date: Tue, 21 Dec 2010 18:53:42 +0330 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: SOCK_STREAM socket in kernel space X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 15:24:23 -0000 On Tue, Dec 21, 2010 at 4:23 PM, John Baldwin wrote: > On Tuesday, December 21, 2010 6:39:26 am Mohammad Hedayati wrote: >> I'm about to use a char device for a kind of distributed processing, >> so I've coded the open function as follows. The problem is that >> soaccept returns 0 without populating the raddr. I've checked netstat, >> everything seems to be fine, the socket is created, bound and the >> state is LISTENING. Even the remote is connection is ESTABLISHED. But, >> it cannot receive anything. it says that socket =C2=A0(sock variable) is >> not connected. > > Yes, you are calling soaccept() on the wrong socket. =C2=A0You need to wa= it for a > connection and dequeue the socket that connected and then call soaccept()= on > that new socket. =C2=A0Look at kern_accept() in sys/kern/uipc_syscalls.c. > > I wonder though if you wouldn't rather be calling soconnect instead? =C2= =A0Do you > really need to listen for new connections? > > -- > John Baldwin > Thanks, I have corrected it as follows. It now works fine. int open(struct cdev *dev, int flag, int otyp, struct thread *td) { uprintf("in open...\n"); =09 int error =3D -1;=09 socktd =3D td; =09 error =3D socreate(AF_INET, &sock, SOCK_STREAM, IPPROTO_TCP, td->td_proc->p_ucred, socktd); if(error !=3D 0) return error; =09 sockaddr.sin_len =3D sizeof(struct sockaddr_in); sockaddr.sin_family =3D AF_INET; sockaddr.sin_port =3D htons(1234); sockaddr.sin_addr.s_addr =3D INADDR_ANY; error =3D sobind(sock, (struct sockaddr *)&sockaddr, socktd); uprintf("sobind error =3D %d\n", error); =09 error =3D solisten(sock, 5, socktd); uprintf("solisten error =3D %d\n", error); =09 /* Accepting the connection */=09 ACCEPT_LOCK(); // Block, waiting for connection ... while (TAILQ_EMPTY(&sock->so_comp) && sock->so_error =3D=3D 0) { // Check if the connection is already aborted? if (sock->so_rcv.sb_state & SBS_CANTRCVMORE) { sock->so_error =3D ECONNABORTED; error =3D sock->so_error; sock->so_error =3D 0; ACCEPT_UNLOCK(); return(error); } error =3D msleep(&sock->so_timeo, &accept_mtx, PSOCK | PCATCH, "accept", = 0); if (error) { ACCEPT_UNLOCK(); return(error); } } rsock =3D TAILQ_FIRST(&sock->so_comp); SOCK_LOCK(rsock); soref(rsock); TAILQ_REMOVE(&sock->so_comp, rsock, so_list); sock->so_qlen--; rsock->so_state |=3D (sock->so_state & SS_NBIO); rsock->so_qstate &=3D ~SQ_COMP; rsock->so_head =3D NULL; SOCK_UNLOCK(rsock); ACCEPT_UNLOCK();=09 error =3D soaccept(rsock, (struct sockaddr **)&raddr); uprintf("soaccept error =3D %d, ip=3D%s\n", error, inet_ntoa(raddr->sin_ad= dr)); =09 uprintf("out open...\n"); =09 return(error); } From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 15:57:43 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE826106564A; Tue, 21 Dec 2010 15:57:43 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 295388FC0A; Tue, 21 Dec 2010 15:57:42 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 88EEB74001B; Tue, 21 Dec 2010 16:55:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: <4D10BE3E.6030506@rdtc.ru> Date: Tue, 21 Dec 2010 16:57:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> <4D10B2F4.1060404@rdtc.ru> <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> <4D10BE3E.6030506@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1082) Cc: Jack F Vogel , net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 15:57:43 -0000 On Dec 21, 2010, at 3:48 PM, Eugene Grosbein wrote: > On 21.12.2010 20:41, Fabien Thomas wrote: >=20 >>>>> 1. Is it a bug or design problem? >>>>=20 >>>> How many queues have you with igb? If it's one it will explain why = the flowid is bad for load balancing with lagg. >>>=20 >>> How do I know? I've read igb(4) manual page and found no words >> vmstat -i will show the queue (intr for the queue) normally it's the = number of CPU available. >=20 > # vmstat -i > interrupt total rate > irq5: uart2 8 0 > irq18: ehci0 uhci5+ 2 0 > irq19: uhci2 uhci4+ 2182 0 > irq23: uhci3 ehci1 124 0 > cpu0: timer 39576224 1993 > irq256: em0:rx 0 115571349 5822 > irq257: em0:tx 0 136632905 6883 > irq259: em1:rx 0 115829181 5835 > irq260: em1:tx 0 138838991 6994 > irq262: igb0:que 0 157354922 7927 > irq263: igb0:que 1 577369 29 > irq264: igb0:que 2 280207 14 > irq265: igb0:que 3 241826 12 > irq266: igb0:link 2 0 > irq267: igb1:que 0 164620363 8293 > irq268: igb1:que 1 238678 12 > irq269: igb1:que 2 248478 12 > irq270: igb1:que 3 762453 38 > irq271: igb1:link 3 0 > cpu2: timer 39576052 1993 > cpu3: timer 39576095 1993 > cpu1: timer 39575913 1993 > Total 989503327 49849 >=20 > It seems I have four queues per igb card but only one of them works? Yes. Jack will certainly confirm but it seems that RSS hash does not seems to = take vlan in account and default to queue0 ? >=20 > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Dec 21 16:14:36 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D85C106566B for ; Tue, 21 Dec 2010 16:14:36 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 60C138FC1B for ; Tue, 21 Dec 2010 16:14:34 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oBLGEVDW002410; Tue, 21 Dec 2010 22:14:32 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D10D267.4060201@rdtc.ru> Date: Tue, 21 Dec 2010 22:14:31 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Fabien Thomas References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> <4D10B2F4.1060404@rdtc.ru> <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> <4D10BE3E.6030506@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Jack F Vogel , net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 16:14:36 -0000 On 21.12.2010 21:57, Fabien Thomas wrote: >>>>>> 1. Is it a bug or design problem? >>>>> >>>>> How many queues have you with igb? If it's one it will explain why the flowid is bad for load balancing with lagg. >>>> >>>> How do I know? I've read igb(4) manual page and found no words >>> vmstat -i will show the queue (intr for the queue) normally it's the number of CPU available. >> >> # vmstat -i >> interrupt total rate >> irq5: uart2 8 0 >> irq18: ehci0 uhci5+ 2 0 >> irq19: uhci2 uhci4+ 2182 0 >> irq23: uhci3 ehci1 124 0 >> cpu0: timer 39576224 1993 >> irq256: em0:rx 0 115571349 5822 >> irq257: em0:tx 0 136632905 6883 >> irq259: em1:rx 0 115829181 5835 >> irq260: em1:tx 0 138838991 6994 >> irq262: igb0:que 0 157354922 7927 >> irq263: igb0:que 1 577369 29 >> irq264: igb0:que 2 280207 14 >> irq265: igb0:que 3 241826 12 >> irq266: igb0:link 2 0 >> irq267: igb1:que 0 164620363 8293 >> irq268: igb1:que 1 238678 12 >> irq269: igb1:que 2 248478 12 >> irq270: igb1:que 3 762453 38 >> irq271: igb1:link 3 0 >> cpu2: timer 39576052 1993 >> cpu3: timer 39576095 1993 >> cpu1: timer 39575913 1993 >> Total 989503327 49849 >> >> It seems I have four queues per igb card but only one of them works? > > Yes. > > Jack will certainly confirm but it seems that RSS hash does not seems to take vlan in account and default to queue0 ? Perhaps, this is the reason I cannot achieve even 133Kpps at igb0+igb1 grouped to lagg1 ?.. mrtg shows horizontal line for pps graph after input load reaches 560Mbps for lagg1, and traffic does not grow more too. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Dec 22 08:43:12 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633F41065673; Wed, 22 Dec 2010 08:43:12 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 390458FC08; Wed, 22 Dec 2010 08:43:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBM8hCXc032739; Wed, 22 Dec 2010 08:43:12 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBM8hCNa032735; Wed, 22 Dec 2010 08:43:12 GMT (envelope-from bschmidt) Date: Wed, 22 Dec 2010 08:43:12 GMT Message-Id: <201012220843.oBM8hCNa032735@freefall.freebsd.org> To: kitambi@epicsol.org, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/128917: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 08:43:12 -0000 Synopsis: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic State-Changed-From-To: open->feedback State-Changed-By: bschmidt State-Changed-When: Wed Dec 22 08:42:16 UTC 2010 State-Changed-Why: Is that still an issue on a recent release? Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Wed Dec 22 08:42:16 UTC 2010 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=128917 From owner-freebsd-net@FreeBSD.ORG Wed Dec 22 08:45:34 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CF4410656BF; Wed, 22 Dec 2010 08:45:34 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 633B98FC12; Wed, 22 Dec 2010 08:45:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBM8jYBR032968; Wed, 22 Dec 2010 08:45:34 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBM8jYWr032963; Wed, 22 Dec 2010 08:45:34 GMT (envelope-from bschmidt) Date: Wed, 22 Dec 2010 08:45:34 GMT Message-Id: <201012220845.oBM8jYWr032963@freefall.freebsd.org> To: cperciva@freebsd.org, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/133613: [wpi] [panic] kernel panic in wpi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 08:45:34 -0000 Synopsis: [wpi] [panic] kernel panic in wpi(4) State-Changed-From-To: open->closed State-Changed-By: bschmidt State-Changed-When: Wed Dec 22 08:43:48 UTC 2010 State-Changed-Why: After talking to cpercia who no longer has access to the AP and this PR being a duplicate of kern/128917, close it. Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Wed Dec 22 08:43:48 UTC 2010 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=133613 From owner-freebsd-net@FreeBSD.ORG Wed Dec 22 09:10:11 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 292A41065673 for ; Wed, 22 Dec 2010 09:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F12AF8FC12 for ; Wed, 22 Dec 2010 09:10:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBM9AAFW056153 for ; Wed, 22 Dec 2010 09:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBM9AASq056152; Wed, 22 Dec 2010 09:10:10 GMT (envelope-from gnats) Date: Wed, 22 Dec 2010 09:10:10 GMT Message-Id: <201012220910.oBM9AASq056152@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 09:10:11 -0000 The following reply was made to PR kern/144987; it has been noted by GNATS. From: Bernhard Schmidt To: bug-followup@freebsd.org, gabrielquadros@hotmail.com Cc: Julian Elischer Subject: Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic Date: Wed, 22 Dec 2010 09:58:34 +0100 On Monday 20 December 2010 15:10:02 Bernhard Schmidt wrote: > Hi, > > The issue here is that you've tried to use wlaninject with a VAP in sta > mode. As soon as wlaninject tries to set up the interface, net80211 will > start to do a scan which means constant channel switches until it finds > something to associate. wlaninject itself is not aware of that and happily > injects frames no matter what the current channel state is, as the above > trace shows, you hit a point where no channel is set between 2 scan > interations. > > wlaninject is supposed to be used with VAPs in ahdemo mode and wpi(4) does > not support that mode. Therefore I tend to close this PR. Looking closer I might have been a bit wrong. There are several issue here.. One being that ni_chan is used in the TX path which should and can actually be replaced by ic_curchan. This will fix the panic reported above, though, this does no longer obscure other issues. For examples, we are allowed to pass in frames of arbitrary length, extremely short frames will be discarded early due to an overflow checking the length (the message to long error). But, if the length is just long enough to reach the driver it might still be shorter then the header for a 802.11 frame. This will result in another panic() in m_copydata() as we try to copy over the header to firmware.. I'll try to find a useful solution for that. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Wed Dec 22 15:00:31 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B8371065673 for ; Wed, 22 Dec 2010 15:00:31 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B81D8FC15 for ; Wed, 22 Dec 2010 15:00:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBMF0Vxa032759 for ; Wed, 22 Dec 2010 15:00:31 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBMF0VPi032733; Wed, 22 Dec 2010 15:00:31 GMT (envelope-from gnats) Date: Wed, 22 Dec 2010 15:00:31 GMT Message-Id: <201012221500.oBMF0VPi032733@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: misc/153308: em interface use 100% cpu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:00:31 -0000 The following reply was made to PR kern/153308; it has been noted by GNATS. From: Gleb Smirnoff To: Yusuf Ozbilgin Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/153308: em interface use 100% cpu Date: Wed, 22 Dec 2010 17:31:12 +0300 On Mon, Dec 20, 2010 at 02:25:29PM +0000, Yusuf Ozbilgin wrote: Y> >Synopsis: em interface use 100% cpu ... Y> em0@pci0:1:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 hdr=0x00 Y> vendor = 'Intel Corporation' Y> class = network Y> subclass = ethernet Y> cap 01[c8] = powerspec 2 supports D0 D3 current D0 Y> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message Y> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) Y> cap 11[a0] = MSI-X supports 5 messages in map 0x1c Y> Y> top Y> Y> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND Y> 1592 root 1 112 0 3348K 1316K RUN 0 0:38 85.09% natd Y> 1899 postfix 1 4 0 24600K 21336K kqread 0 0:06 0.00% qmgr Y> 1762 root 1 44 0 39132K 36772K select 0 0:03 0.00% perl This doesn't seem related to em(4). Do you mind if I change synopsis of PR to "natd consumes 100% CPU"? Have you tried same setup on 8-STABLE? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Dec 22 17:55:16 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0649106566B for ; Wed, 22 Dec 2010 17:55:16 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 16E158FC0C for ; Wed, 22 Dec 2010 17:55:15 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBMHtDi9040223; Wed, 22 Dec 2010 23:55:14 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D123B7C.1070104@rdtc.ru> Date: Wed, 22 Dec 2010 23:55:08 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Fabien Thomas References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> <4D10B2F4.1060404@rdtc.ru> <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> <4D10BE3E.6030506@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jack F Vogel , net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:55:16 -0000 On 21.12.2010 21:57, Fabien Thomas wrote: >> irq262: igb0:que 0 157354922 7927 >> irq263: igb0:que 1 577369 29 >> irq264: igb0:que 2 280207 14 >> irq265: igb0:que 3 241826 12 >> irq266: igb0:link 2 0 >> irq267: igb1:que 0 164620363 8293 >> irq268: igb1:que 1 238678 12 >> irq269: igb1:que 2 248478 12 >> irq270: igb1:que 3 762453 38 >> irq271: igb1:link 3 0 >> cpu2: timer 39576052 1993 >> cpu3: timer 39576095 1993 >> cpu1: timer 39575913 1993 >> Total 989503327 49849 >> >> It seems I have four queues per igb card but only one of them works? > > Yes. > > Jack will certainly confirm but it seems that RSS hash does not seems to take vlan in account and default to queue0 ? I've just read "Microsoft Receive-Side Scaling" documentation, http://download.microsoft.com/download/5/d/6/5d6eaf2b-7ddf-476b-93dc-7cf0072878e6/ndis_rss.doc RSS defines that hash function may take IP and optionally port numbers only, not vlan tags. In case of PPPoE-only traffic this card's ability to classify traffic voids. Then, unpatched lagg fails to share load over outgoing interface ports. It seems, we really need sysctl disabling lagg's use of flows, don't we? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 01:48:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AAEF106564A for ; Thu, 23 Dec 2010 01:48:05 +0000 (UTC) (envelope-from oliver.solaris@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7FA8FC1B for ; Thu, 23 Dec 2010 01:48:04 +0000 (UTC) Received: by ywp6 with SMTP id 6so2704709ywp.13 for ; Wed, 22 Dec 2010 17:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=JlPiG5JtAdwDFlgPmF9WYCc6A/bxBhjK9Ukx0FrTR+g=; b=wUvYoSrEH3GTDNJlThDEowh8yi6n2m8SxuEY4RE3NqrQb8THnNFfdsKi19KGCH6kBJ dd0WtqbWSHaDwIuUgZofdu50vokd5D7Bwylspqo6g4/8P+8J2DMN6Q6/UraX3WgUvg53 nVukjF4JQ3EUmjVlw1iWBl6VCYDVJUFmrGg3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=xMZbd1TgpfA+u2ZoUwyDuXI+n0mbOLkUE4apZAVfj2nrJ6/IdzvN56cjcaNRHYcV1A 3/n1GU0vxcP4v8QE9Zg0low40jnbOnPg6k8pmVPYXWhLi5gbrkEPyh/T+upz+3jNUTog 9VbTnUIhyucEcRkjxUmKOaYv+5hAC0Wk/6R68= Received: by 10.236.105.244 with SMTP id k80mr54031yhg.60.1293067388768; Wed, 22 Dec 2010 17:23:08 -0800 (PST) Received: from galactica.olibert-net.de (24-183-51-30.dhcp.mdsn.wi.charter.com [24.183.51.30]) by mx.google.com with ESMTPS id j63sm3990460yha.18.2010.12.22.17.23.05 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Dec 2010 17:23:06 -0800 (PST) Date: Wed, 22 Dec 2010 19:23:04 -0600 From: Oliver Ebert To: Bernhard Schmidt Message-ID: <20101222192304.581b7cd0@galactica.olibert-net.de> In-Reply-To: <201012201253.30310.bschmidt@freebsd.org> References: <201012191710.oBJHABlC030477@freefall.freebsd.org> <201012201253.30310.bschmidt@freebsd.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Patrick Ale Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 01:48:05 -0000 On Mon, 20 Dec 2010 12:53:30 +0100 Bernhard Schmidt wrote: > On Monday 20 December 2010 12:06:24 Patrick Ale wrote: > > Hi, > > > > Not sure if this is useful information for you but here goes: > > I have exactly the same problem on my Acer Aspire laptop with the > > same network card but then under Solaris 10 and Opensolaris, both > > 64 bit. > > > > The only way for me to get rid of this error and get the card > > working is to reduce my memory from 4GB to <= 3GB. > > I got told it has to do with the PCI to PCI-X bridge masquarading > > some memory addresses.. > > > > I am not a kernel/driver/code guru but I thought one of you might > > get some pointers out of this.. > > There have been a few changes to PCI bridge code lately which might > well fix that issue. If anyone could give a recent stable/8 or > 8.2-BETA a shot, I'd really appreciate that. > > > On Sun, Dec 19, 2010 at 6:10 PM, Oliver Ebert > > > wrote: > > > The following reply was made to PR kern/143874; it has been noted > > > by GNATS. > > > > > > From: Oliver Ebert > > > To: Bernhard Schmidt > > > Cc: bug-followup@freebsd.org > > > Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 > > > could not allocate memory resource > > > Date: Sun, 19 Dec 2010 10:39:47 -0600 > > > > > > On Sun, 19 Dec 2010 11:49:27 +0100 > > > Bernhard Schmidt wrote: > > > > > > > On Sunday 12 September 2010 05:30:10 oliver.solaris@gmail.com > > > > wrote: > > > > > I have the same issue with a Toshiba Satellite P105: > > > > > > > > > > Sep 11 21:46:13 kernel: wpi0: > > > > 3945ABG> irq 17 at device 0.0 on pci3 > > > > > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > > > > > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res > > > > > 3 failed (0, 0xfffff fff). > > > > > Sep 11 21:46:13 kernel: wpi0: could not allocate memory > > > > > resource Sep 11 21:46:13 kernel: device_attach: wpi0 attach > > > > > returned 6 > > > > > > > > > > Please let me know if I can help out to track this issue > > > > > down. > > > > > > > > Is this still an issue on a recent stable/8 or 8.2-BETA1? > > > > > > > 8.2-PRERELEASE > > > With 8.1 it is but I didn't had a chance to check with 8.2 beta. > I just upgraded to 8.2-PRERELEASE and it seems that the issue is still persistent: Now wlan0 device shows up. The device is available when booting with ACPI disabled. From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 08:53:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81A2F106566C for ; Thu, 23 Dec 2010 08:53:10 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 11BA28FC0A for ; Thu, 23 Dec 2010 08:53:09 +0000 (UTC) Received: by bwz12 with SMTP id 12so213191bwz.13 for ; Thu, 23 Dec 2010 00:53:08 -0800 (PST) Received: by 10.204.63.2 with SMTP id z2mr6959373bkh.66.1293094388608; Thu, 23 Dec 2010 00:53:08 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-067-198-164.pools.arcor-ip.net [88.67.198.164]) by mx.google.com with ESMTPS id b6sm4568211bkb.10.2010.12.23.00.53.05 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 00:53:06 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Oliver Ebert Date: Thu, 23 Dec 2010 09:51:36 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: <201012191710.oBJHABlC030477@freefall.freebsd.org> <201012201253.30310.bschmidt@freebsd.org> <20101222192304.581b7cd0@galactica.olibert-net.de> In-Reply-To: <20101222192304.581b7cd0@galactica.olibert-net.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012230951.36855.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org, Patrick Ale Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 08:53:10 -0000 On Thursday 23 December 2010 02:23:04 Oliver Ebert wrote: > On Mon, 20 Dec 2010 12:53:30 +0100 > > Bernhard Schmidt wrote: > > On Monday 20 December 2010 12:06:24 Patrick Ale wrote: > > > Hi, > > > > > > Not sure if this is useful information for you but here goes: > > > I have exactly the same problem on my Acer Aspire laptop with the > > > same network card but then under Solaris 10 and Opensolaris, both > > > 64 bit. > > > > > > The only way for me to get rid of this error and get the card > > > working is to reduce my memory from 4GB to <= 3GB. > > > I got told it has to do with the PCI to PCI-X bridge masquarading > > > some memory addresses.. > > > > > > I am not a kernel/driver/code guru but I thought one of you might > > > get some pointers out of this.. > > > > There have been a few changes to PCI bridge code lately which might > > well fix that issue. If anyone could give a recent stable/8 or > > 8.2-BETA a shot, I'd really appreciate that. > > > > > On Sun, Dec 19, 2010 at 6:10 PM, Oliver Ebert > > > > > > > wrote: > > > > The following reply was made to PR kern/143874; it has been noted > > > > by GNATS. > > > > > > > > From: Oliver Ebert > > > > To: Bernhard Schmidt > > > > Cc: bug-followup@freebsd.org > > > > Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 > > > > could not allocate memory resource > > > > Date: Sun, 19 Dec 2010 10:39:47 -0600 > > > > > > > > On Sun, 19 Dec 2010 11:49:27 +0100 > > > > > > > > Bernhard Schmidt wrote: > > > > > On Sunday 12 September 2010 05:30:10 oliver.solaris@gmail.com > > > > > > > > > > wrote: > > > > > > I have the same issue with a Toshiba Satellite P105: > > > > > > > > > > > > Sep 11 21:46:13 kernel: wpi0: > > > > > 3945ABG> irq 17 at device 0.0 on pci3 > > > > > > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > > > > > > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res > > > > > > 3 failed (0, 0xfffff fff). > > > > > > Sep 11 21:46:13 kernel: wpi0: could not allocate memory > > > > > > resource Sep 11 21:46:13 kernel: device_attach: wpi0 attach > > > > > > returned 6 > > > > > > > > > > > > Please let me know if I can help out to track this issue > > > > > > down. > > > > > > > > > > Is this still an issue on a recent stable/8 or 8.2-BETA1? > > > > > > > > 8.2-PRERELEASE > > > > > > > > With 8.1 it is but I didn't had a chance to check with 8.2 beta. > > I just upgraded to 8.2-PRERELEASE and it seems that the issue is still > persistent: Now wlan0 device shows up. > > The device is available when booting with ACPI disabled. Still same error message? -- Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 09:30:26 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645BB106564A; Thu, 23 Dec 2010 09:30:26 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id A803D8FC12; Thu, 23 Dec 2010 09:30:25 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 5C137740007; Thu, 23 Dec 2010 10:28:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: <4D123B7C.1070104@rdtc.ru> Date: Thu, 23 Dec 2010 10:30:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> <4D10B2F4.1060404@rdtc.ru> <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> <4D10BE3E.6030506@rdtc.ru> <4D123B7C.1070104@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1082) Cc: Jack F Vogel , net@freebsd.org Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 09:30:26 -0000 On Dec 22, 2010, at 6:55 PM, Eugene Grosbein wrote: > On 21.12.2010 21:57, Fabien Thomas wrote: >=20 >>> irq262: igb0:que 0 157354922 7927 >>> irq263: igb0:que 1 577369 29 >>> irq264: igb0:que 2 280207 14 >>> irq265: igb0:que 3 241826 12 >>> irq266: igb0:link 2 0 >>> irq267: igb1:que 0 164620363 8293 >>> irq268: igb1:que 1 238678 12 >>> irq269: igb1:que 2 248478 12 >>> irq270: igb1:que 3 762453 38 >>> irq271: igb1:link 3 0 >>> cpu2: timer 39576052 1993 >>> cpu3: timer 39576095 1993 >>> cpu1: timer 39575913 1993 >>> Total 989503327 49849 >>>=20 >>> It seems I have four queues per igb card but only one of them works? >>=20 >> Yes. >>=20 >> Jack will certainly confirm but it seems that RSS hash does not seems = to take vlan in account and default to queue0 ? >=20 > I've just read "Microsoft Receive-Side Scaling" documentation, > = http://download.microsoft.com/download/5/d/6/5d6eaf2b-7ddf-476b-93dc-7cf00= 72878e6/ndis_rss.doc >=20 > RSS defines that hash function may take IP and optionally port numbers = only, not vlan tags. > In case of PPPoE-only traffic this card's ability to classify traffic = voids. > Then, unpatched lagg fails to share load over outgoing interface = ports. >=20 > It seems, we really need sysctl disabling lagg's use of flows, don't = we? Yes I think that it is necessary to be able to disable it because he = cant be always optimal. One improvement to the queue count would be to hash the queue id before = the modulo. >=20 > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 14:17:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3E1F106566C for ; Thu, 23 Dec 2010 14:17:55 +0000 (UTC) (envelope-from hedayati.mo@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE5A8FC21 for ; Thu, 23 Dec 2010 14:17:55 +0000 (UTC) Received: by wyf19 with SMTP id 19so6055651wyf.13 for ; Thu, 23 Dec 2010 06:17:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=94DCEgJvhMg8RFpARCSDUYVNMGVwr0YuYULuoAGl51o=; b=j4YdNJAz/bvWEZZ1R4pdmyGDUH3HvYuU7Ni9xVj38X7pYE7/O6yEx+HXbpVwupL/cb JSaGg5eleqoH5i2h5WehekBceZ7/ORkI4Hr2rMYnYxJ0NoX0MQEcG4M3ulTvM0wDDHhY 5/DifgnibE/veq9ZqYvGaKeOJrdzjtqdn+V9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=WCSpAU2r2ILTgdGJS7BQr023sCXURbnfYEMYg5T+HccSrnp383EMI4NKewzckPOUdb 9FIlUikJumDWwiBZZuqfGWChx6jG7EhqFuXb2hUazrIhju9C6c+peA/J0aCDjU3aZPyM DSJ301PqC1UEkdvueEawNXAByL00bMnPHNfnY= Received: by 10.227.132.200 with SMTP id c8mr5037748wbt.31.1293113874611; Thu, 23 Dec 2010 06:17:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.202 with HTTP; Thu, 23 Dec 2010 06:17:14 -0800 (PST) From: Mohammad Hedayati Date: Thu, 23 Dec 2010 17:47:14 +0330 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: stream socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 14:17:56 -0000 Suppose we've created a stream socket between two nodes. What happens if you write large chunks of data into the socket but the other pair doesn't read that for presumably long time?! Does the connection fail or data is missed?! From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 15:00:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3DDA10656A5 for ; Thu, 23 Dec 2010 15:00:19 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 692518FC1F for ; Thu, 23 Dec 2010 15:00:16 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id oBNF0GOH019189 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 23 Dec 2010 16:00:16 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id oBNF0GHs007563; Thu, 23 Dec 2010 16:00:16 +0100 (MET) Date: Thu, 23 Dec 2010 16:00:16 +0100 From: Daniel Hartmeier To: Mohammad Hedayati Message-ID: <20101223150016.GA10213@insomnia.benzedrine.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: stream socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 15:00:19 -0000 On Thu, Dec 23, 2010 at 05:47:14PM +0330, Mohammad Hedayati wrote: > Suppose we've created a stream socket between two nodes. What happens > if you write large chunks of data into the socket but the other pair > doesn't read that for presumably long time?! Does the connection fail > or data is missed?! TCP includes flow control, through the advertised receive window[1]. When the peer stops reading, its receive buffer will fill up, closing the receive window, until it reaches zero. At that point, the sender's TCP/IP stack cannot send any further segments. The sender has a send buffer (setsockopt(SO_SNDBUF), net.inet.tcp.sendbuf_max), and the sender process will be able to write until that is full. At that point, further writes will either block or fail with EAGAIN. No data is missed, assuming the sender process correctly handles this case (or simply blocks). As long as the receiver is acknowledging but keeps a zero sized window, the connection remains open, there is no timeout. HTH, Daniel [1] http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control [2] http://www.faqs.org/rfcs/rfc1122.html, 4.2.2.17 Probing Zero Windows From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 17:05:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9219106564A; Thu, 23 Dec 2010 17:05:20 +0000 (UTC) (envelope-from oliver.solaris@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84B9A8FC0C; Thu, 23 Dec 2010 17:05:20 +0000 (UTC) Received: by vws9 with SMTP id 9so2561903vws.13 for ; Thu, 23 Dec 2010 09:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=lwSazzi39DxawFs+6QPZdAsFFxzgCWGQjNSHjX4e5/o=; b=jDOTnBkJn5ODoKEEa/DWBbsNCBDSTm1chLZuwxMi02e3iN8dMdQRN+1kCCj/Fo70uJ xRkvyezJkruZzUXJ024JMLjlpO31fatRhjvPIW/kK3g4iXOeTRenF4Uxsu23rRJXHWyR 5bGLVV5FlnZ531k3OfzgJZ96WHZmXqJ/wgW7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=KR0BTJJXmTBaFJ9X6GVQ5gSzRBkiidbksRkmB/dSdunMSxWUbDdap74jrxmYfI/a// jqZPZWHyAL48i5na8wS41sZ9gzjXMlqFCiRJDrRBV5zkXTKidh7g35cDYNj0tvinnyb7 R3nEunb8Lm0F8Es7KvpyZpbv0tMUjOVSKGoMk= Received: by 10.220.97.143 with SMTP id l15mr2129809vcn.222.1293123919480; Thu, 23 Dec 2010 09:05:19 -0800 (PST) Received: from galactica.olibert-net.de (24-183-51-30.dhcp.mdsn.wi.charter.com [24.183.51.30]) by mx.google.com with ESMTPS id r7sm2895745vbx.9.2010.12.23.09.05.16 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 09:05:17 -0800 (PST) Date: Thu, 23 Dec 2010 11:05:15 -0600 From: Oliver Ebert To: Bernhard Schmidt Message-ID: <20101223110515.60b4b887@galactica.olibert-net.de> In-Reply-To: <201012230951.36855.bschmidt@freebsd.org> References: <201012191710.oBJHABlC030477@freefall.freebsd.org> <201012201253.30310.bschmidt@freebsd.org> <20101222192304.581b7cd0@galactica.olibert-net.de> <201012230951.36855.bschmidt@freebsd.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Patrick Ale Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 17:05:21 -0000 On Thu, 23 Dec 2010 09:51:36 +0100 Bernhard Schmidt wrote: > On Thursday 23 December 2010 02:23:04 Oliver Ebert wrote: > > On Mon, 20 Dec 2010 12:53:30 +0100 > > > > Bernhard Schmidt wrote: > > > On Monday 20 December 2010 12:06:24 Patrick Ale wrote: > > > > Hi, > > > > > > > > Not sure if this is useful information for you but here goes: > > > > I have exactly the same problem on my Acer Aspire laptop with > > > > the same network card but then under Solaris 10 and > > > > Opensolaris, both 64 bit. > > > > > > > > The only way for me to get rid of this error and get the card > > > > working is to reduce my memory from 4GB to <= 3GB. > > > > I got told it has to do with the PCI to PCI-X bridge > > > > masquarading some memory addresses.. > > > > > > > > I am not a kernel/driver/code guru but I thought one of you > > > > might get some pointers out of this.. > > > > > > There have been a few changes to PCI bridge code lately which > > > might well fix that issue. If anyone could give a recent stable/8 > > > or 8.2-BETA a shot, I'd really appreciate that. > > > > > > > On Sun, Dec 19, 2010 at 6:10 PM, Oliver Ebert > > > > > > > > > > wrote: > > > > > The following reply was made to PR kern/143874; it has been > > > > > noted by GNATS. > > > > > > > > > > From: Oliver Ebert > > > > > To: Bernhard Schmidt > > > > > Cc: bug-followup@freebsd.org > > > > > Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 > > > > > could not allocate memory resource > > > > > Date: Sun, 19 Dec 2010 10:39:47 -0600 > > > > > > > > > > On Sun, 19 Dec 2010 11:49:27 +0100 > > > > > > > > > > Bernhard Schmidt wrote: > > > > > > On Sunday 12 September 2010 05:30:10 > > > > > > oliver.solaris@gmail.com > > > > > > > > > > > > wrote: > > > > > > > I have the same issue with a Toshiba Satellite P105: > > > > > > > > > > > > > > Sep 11 21:46:13 kernel: wpi0: > > > > > > 3945ABG> irq 17 at device 0.0 on pci3 > > > > > > > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > > > > > > > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 > > > > > > > res 3 failed (0, 0xfffff fff). > > > > > > > Sep 11 21:46:13 kernel: wpi0: could not allocate memory > > > > > > > resource Sep 11 21:46:13 kernel: device_attach: wpi0 > > > > > > > attach returned 6 > > > > > > > > > > > > > > Please let me know if I can help out to track this issue > > > > > > > down. > > > > > > > > > > > > Is this still an issue on a recent stable/8 or 8.2-BETA1? > > > > > > > > > > 8.2-PRERELEASE > > > > > > > > > > With 8.1 it is but I didn't had a chance to check with 8.2 > > > > > beta. > > > > I just upgraded to 8.2-PRERELEASE and it seems that the issue is > > still persistent: Now wlan0 device shows up. > > > > The device is available when booting with ACPI disabled. > > Still same error message? > Yes, I just took a look to the messages: Dec 23 06:36:50 kernel: wpi0: irq 17 at device 0.0 on pci3 Dec 23 06:36:50 kernel: wpi0: Driver Revision 20071127 Dec 23 06:36:50 kernel: pcib2: wpi0 requested unsupported memory range 0-0xffff ffff (decoding 0-0, 0-0) Dec 23 06:36:50 kernel: wpi0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xfffff fff). Dec 23 06:36:50 kernel: wpi0: could not allocate memory resource Dec 23 06:36:50 kernel: device_attach: wpi0 attach returned 6 $ kldstat Id Refs Address Size Name 1 32 0xc0400000 bd9960 kernel 2 1 0xc0fda000 e760 if_wpi.ko 3 1 0xc0fe9000 1c260 snd_hda.ko 4 2 0xc1006000 566f4 sound.ko 5 1 0xc1066000 2ecb0 vboxdrv.ko 6 1 0xc636c000 8000 linprocfs.ko 7 1 0xc6374000 26000 linux.ko 8 1 0xc6606000 9000 i915.ko 9 1 0xc661f000 14000 drm.ko Please let me know if you need more information. Thanks, Oliver From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 18:30:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0CE9106566B for ; Thu, 23 Dec 2010 18:30:38 +0000 (UTC) (envelope-from hedayati.mo@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF3E8FC17 for ; Thu, 23 Dec 2010 18:30:37 +0000 (UTC) Received: by wwf26 with SMTP id 26so6122010wwf.31 for ; Thu, 23 Dec 2010 10:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=UR9rJu8LyhE+C46DmZESqcJR7rzyZVn37oM6rKkJv0A=; b=tqsBJb5nvDY9qkPnhdpCjaXruSsXAhGnzpGwQYCPAKOKytAojHHDKMPYu6bYitE2nO qnspXOB46er2gK0/bwkatV5C8kU0IQaU6il2JT8h/yx1tDys84owbBrN7eFzVs4ftFXD 0OVfzIuy9fSH1BCa7nnaiKZfgKa8fnNfWSmuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=JUcIhJfC2wLV+1/I6JuSMzCoL0/ipE6mg1dIEeOfoqzovs3i+Fgh0yeaidzP2mxMYG NxtRz2ioHnKe+neDuQfkymh74jEfYFKOLNbthwQhc9qQULaOpNTeSfxAbzlP8DN1UQxF NwlTi7FSXTs9+8EKmHVh9R/qc5aJYXxvUZB8w= Received: by 10.227.176.134 with SMTP id be6mr5175896wbb.147.1293129037114; Thu, 23 Dec 2010 10:30:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.202 with HTTP; Thu, 23 Dec 2010 10:29:57 -0800 (PST) From: Mohammad Hedayati Date: Thu, 23 Dec 2010 21:59:57 +0330 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Inappropriate ioctl for device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 18:30:38 -0000 I'm writing a simple char device. So far everything went so good (read/write), but here I'm going to add support for ioctl. int ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct thread *td) { int error = 0; uprintf("Here...\n"); return(error); } and I'm calling it here: len = ioctl(cd, 0, ""); perror("ioctl"); but when runnig it says: ioctl: Inappropriate ioctl for device where's the problem? From owner-freebsd-net@FreeBSD.ORG Thu Dec 23 18:49:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BABC106564A for ; Thu, 23 Dec 2010 18:49:07 +0000 (UTC) (envelope-from sathler90@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D897B8FC12 for ; Thu, 23 Dec 2010 18:49:06 +0000 (UTC) Received: by bwz12 with SMTP id 12so623864bwz.13 for ; Thu, 23 Dec 2010 10:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=LZtj3MSgI2ibFKLRtobPUMUDdj68wPv2s4riIMo1TUo=; b=RPnsKTLvRi9EB5EUmlZpu2oXmeHlwEVBJHX2jF3aEQ5n117DD95bGjJzgNMA0Z/0Cv 50Q7BTzSZrlUcQRf2WbIX0p0ll//+H6E037Hs1kVONSvGI/INcoyMAugtzhzmxSdy858 Qf7+LQHFzyr6y7YvYrUEXzc5gnh4nv4F2+7fA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=LcVA2Q7BK8UYUGKNVBz8Z4JT4/qsh6N0tFlh+tu8B6agnx6VBAqmb5mFT6TJuvvyHJ 5/H8byNwDkJDHPYvt3o0DX6+2SysOAo1KeAF898wRMBAPLL+K76gvtFMkVv186XkBoRo 434sLj1Xm+uXTaLM4bzUn6U14anul03UYJvl8= MIME-Version: 1.0 Received: by 10.204.72.130 with SMTP id m2mr169821bkj.15.1293128275573; Thu, 23 Dec 2010 10:17:55 -0800 (PST) Received: by 10.204.123.146 with HTTP; Thu, 23 Dec 2010 10:17:55 -0800 (PST) Date: Thu, 23 Dec 2010 16:17:55 -0200 Message-ID: From: Eduardo To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: bce - status: no carrier - on Dell R900 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 18:49:07 -0000 Hi Folks, I have a dell R900 - it came with a quad card =A0Broadcom NetXtreme II BCM5708 and =A0I installed the 8.1 release amd64. The bce connected to a switch foundry says 'no carrier', another bce connected to a router (juniper) works fine. I found some old threads about the bce driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D118238 and http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2007-11/msg00211.html Below are boot messages regarding bce. Any ideas on what I should try =A0? ( just now tried the 8.2 prerelease 0 - no luck) thanks, -Ed. module_register: module bce/miibus already exists! Module bce/miibus failed to register: 17 module_register: module pci/bce already exists! Module pci/bce failed to register: 17 bce0: mem 0xd6000000-0xd7ffffff irq 18 at device 0.0 on pci11 miibus0: on bce0 bce0: Ethernet address: 00:26:b9:35:08:dc bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (ipms 1.6.0) bce1: mem 0xd8000000-0xd9ffffff irq 19 at device 0.0 on pci9 miibus1: on bce1 bce1: Ethernet address: 00:26:b9:35:08:da bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (ipms 1.6.0) bce2: mem 0xda000000-0xdbffffff irq 37 at device 0.0 on pci7 miibus2: on bce2 bce2: Ethernet address: 00:26:b9:35:08:d8 bce2: [ITHREAD] bce2: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (UMP 1.1.9) bce3: mem 0xdc000000-0xddffffff irq 38 at device 0.0 on pci5 miibus3: on bce3 bce3: Ethernet address: 00:26:b9:35:08:d6 bce3: [ITHREAD] bce3: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (UMP 1.1.9) bce0: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00002006= ) bce1: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00002006= ) bce2: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00004006= ) bce3: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00004006= ) and full dmesg: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =A0 =A0 =A0 =A0The Regents of the University of California. All rights rese= rved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 =A0 =A0root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 module_register: module bce/miibus already exists! Module bce/miibus failed to register: 17 module_register: module pci/bce already exists! Module pci/bce failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 E7440 =A0@ 2.40GHz (2398.69-M= Hz K8-class CPU) =A0Origin =3D "GenuineIntel" =A0Id =3D 0x106d1 =A0Family =3D 6 =A0Model =3D= 1d =A0Stepping =3D 1 =A0Features=3D0xbfebfbff =A0Features2=3D0xce3bd =A0AMD Features=3D0x20100800 =A0AMD Features2=3D0x1 =A0TSC: P-state invariant real memory =A0=3D 68719476736 (65536 MB) avail memory =3D 66333831168 (63260 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 4 package(s) x 4 core(s) cpu0 (BSP): APIC ID: =A00 cpu1 (AP): APIC ID: =A01 cpu2 (AP): APIC ID: =A02 cpu3 (AP): APIC ID: =A03 cpu4 (AP): APIC ID: =A08 cpu5 (AP): APIC ID: =A09 cpu6 (AP): APIC ID: 10 cpu7 (AP): APIC ID: 11 cpu8 (AP): APIC ID: 16 cpu9 (AP): APIC ID: 17 cpu10 (AP): APIC ID: 18 cpu11 (AP): APIC ID: 19 cpu12 (AP): APIC ID: 24 cpu13 (AP): APIC ID: 25 cpu14 (AP): APIC ID: 26 cpu15 (AP): APIC ID: 27 ioapic0: Changing APIC ID to 6 ioapic1: Changing APIC ID to 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning for \\_PR_.CPU0._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu0: invalid _CST state count (3 !=3D 2) cpu1: on acpi0 ACPI Warning for \\_PR_.CPU1._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu1: invalid _CST state count (3 !=3D 2) cpu2: on acpi0 ACPI Warning for \\_PR_.CPU2._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu2: invalid _CST state count (3 !=3D 2) cpu3: on acpi0 ACPI Warning for \\_PR_.CPU3._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu3: invalid _CST state count (3 !=3D 2) cpu4: on acpi0 ACPI Warning for \\_PR_.CPU4._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu4: invalid _CST state count (3 !=3D 2) cpu5: on acpi0 ACPI Warning for \\_PR_.CPU5._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu5: invalid _CST state count (3 !=3D 2) cpu6: on acpi0 ACPI Warning for \\_PR_.CPU6._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu6: invalid _CST state count (3 !=3D 2) cpu7: on acpi0 ACPI Warning for \\_PR_.CPU7._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu7: invalid _CST state count (3 !=3D 2) --More--(byte 3522) cpu13 (AP): APIC ID: 25 cpu14 (AP): APIC ID: 26 cpu15 (AP): APIC ID: 27 ioapic0: Changing APIC ID to 6 ioapic1: Changing APIC ID to 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning for \\_PR_.CPU0._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu0: invalid _CST state count (3 !=3D 2) cpu1: on acpi0 ACPI Warning for \\_PR_.CPU1._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu1: invalid _CST state count (3 !=3D 2) cpu2: on acpi0 ACPI Warning for \\_PR_.CPU2._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu2: invalid _CST state count (3 !=3D 2) cpu3: on acpi0 ACPI Warning for \\_PR_.CPU3._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu3: invalid _CST state count (3 !=3D 2) cpu4: on acpi0 ACPI Warning for \\_PR_.CPU4._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu4: invalid _CST state count (3 !=3D 2) cpu5: on acpi0 ACPI Warning for \\_PR_.CPU5._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu5: invalid _CST state count (3 !=3D 2) cpu6: on acpi0 ACPI Warning for \\_PR_.CPU6._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu6: invalid _CST state count (3 !=3D 2) cpu7: on acpi0 ACPI Warning for \\_PR_.CPU7._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu7: invalid _CST state count (3 !=3D 2) cpu8: on acpi0 ACPI Warning for \\_PR_.CPU8._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu8: invalid _CST state count (3 !=3D 2) cpu9: on acpi0 ACPI Warning for \\_PR_.CPU9._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu9: invalid _CST state count (3 !=3D 2) cpu10: on acpi0 ACPI Warning for \\_PR_.CP10._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu10: invalid _CST state count (3 !=3D 2) cpu11: on acpi0 ACPI Warning for \\_PR_.CP11._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu11: invalid _CST state count (3 !=3D 2) cpu12: on acpi0 ACPI Warning for \\_PR_.CP12._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu12: invalid _CST state count (3 !=3D 2) cpu13: on acpi0 ACPI Warning for \\_PR_.CP13._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu13: invalid _CST state count (3 !=3D 2) cpu14: on acpi0 ACPI Warning for \\_PR_.CP14._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu14: invalid _CST state count (3 !=3D 2) cpu15: on acpi0 ACPI Warning for \\_PR_.CP15._CST: Return Package is too small - found 3 elements, expected 3 (20100331/nspredef-787) cpu15: invalid _CST state count (3 !=3D 2) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 36 at device 1.0 on pci0 pci20: on pcib1 pcib2: irq 17 at device 2.0 on pci0 pci22: on pcib2 pcib3: irq 17 at device 0.0 on pci22 pci23: on pcib3 pcib4: irq 17 at device 0.0 on pci23 pci25: on pcib4 mfi0: port 0xec00-0xecff mem 0xde380000-0xde3bffff,0xde3c0000-0xde3fffff irq 17 at device 0.0 on pci25 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 6684 (345318197s/0x0020/info) - Shutdown command received from host mfi0: 6685 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/1f0c/1028) mfi0: 6686 (boot + 3s/0x0020/info) - Firmware version 1.22.02-0612 mfi0: 6687 (boot + 23s/0x0008/info) - Battery Present mfi0: 6688 (boot + 23s/0x0020/info) - Controller hardware revision ID (0x0) mfi0: 6689 (boot + 23s/0x0020/info) - Package version 6.2.0-0013 mfi0: 6690 (boot + 23s/0x0020/info) - Board Revision mfi0: 6691 (boot + 48s/0x0004/info) - Enclosure PD 20(c None/p0) communication restored mfi0: 6692 (boot + 49s/0x0002/info) - Inserted: Encl PD 20 mfi0: 6693 (boot + 49s/0x0002/info) - Inserted: PD 20(c None/p0) Info: enclPd=3D20, scsiType=3Dd, portMap=3D09, sasAddr=3D5002609049922a00,0000000000000000 mfi0: 6694 (boot + 49s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 6695 (boot + 49s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=3D20, scsiType=3D0, portMap=3D00, sasAddr=3D5000c50010012dd1,0000000000000000 mfi0: 6696 (boot + 49s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 6697 (boot + 49s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=3D20, scsiType=3D0, portMap=3D01, sasAddr=3D5000c50010018bc1,0000000000000000 mfi0: 6698 (boot + 49s/0x0002/info) - Inserted: PD 02(e0x20/s2) mfi0: 6699 (boot + 49s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=3D20, scsiType=3D0, portMap=3D02, sasAddr=3D5000c50010012dad,0000000000000000 mfi0: 6700 (boot + 49s/0x0002/info) - Inserted: PD 03(e0x20/s3) mfi0: 6701 (boot + 49s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: enclPd=3D20, scsiType=3D0, portMap=3D03, sasAddr=3D5000c50010012da9,0000000000000000 mfi0: 6702 (boot + 49s/0x0002/info) - Inserted: PD 04(e0x20/s4) mfi0: 6703 (boot + 49s/0x0002/info) - Inserted: PD 04(e0x20/s4) Info: enclPd=3D20, scsiType=3D0, portMap=3D04, sasAddr=3D5000c50010012e3d,0000000000000000 mfi0: 6704 (345318253s/0x0020/info) - Time established as 12/10/10 17:44:13; (50 seconds since power on) mfi0: 6705 (345318291s/0x0008/info) - Battery temperature is normal mfi0: [ITHREAD] pcib5: irq 18 at device 1.0 on pci23 pci24: on pcib5 pcib6: at device 0.3 on pci22 pci26: on pcib6 pcib7: irq 37 at device 3.0 on pci0 pci1: on pcib7 pcib8: at device 0.0 on pci1 pci2: on pcib8 pcib9: at device 1.0 on pci2 pci3: on pcib9 pcib10: at device 2.0 on pci2 pci10: on pcib10 pcib11: at device 0.0 on pci10 pci11: on pcib11 bce0: mem 0xd6000000-0xd7ffffff irq 18 at device 0.0 on pci11 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:26:b9:35:08:dc bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (ipms 1.6.0) pcib12: at device 3.0 on pci2 pci8: on pcib12 pcib13: at device 0.0 on pci8 pci9: on pcib13 bce1: mem 0xd8000000-0xd9ffffff irq 19 at device 0.0 on pci9 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:26:b9:35:08:da bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (ipms 1.6.0) pcib14: at device 4.0 on pci2 pci6: on pcib14 pcib15: at device 0.0 on pci6 pci7: on pcib15 bce2: mem 0xda000000-0xdbffffff irq 37 at device 0.0 on pci7 miibus2: on bce2 brgphy2: PHY 1 on miibus2 brgphy2: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce2: Ethernet address: 00:26:b9:35:08:d8 bce2: [ITHREAD] bce2: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (UMP 1.1.9) pcib16: at device 5.0 on pci2 pci4: on pcib16 pcib17: at device 0.0 on pci4 pci5: on pcib17 bce3: mem 0xdc000000-0xddffffff irq 38 at device 0.0 on pci5 miibus3: on bce3 brgphy3: PHY 1 on miibus3 brgphy3: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce3: Ethernet address: 00:26:b9:35:08:d6 bce3: [ITHREAD] bce3: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Flags (MSI|MFW); MFW (UMP 1.1.9) pcib18: irq 32 at device 4.0 on pci0 pci12: on pcib18 pcib19: at device 0.0 on pci12 pci13: on pcib19 pcib20: at device 2.0 on pci13 pci15: on pcib20 pcib21: at device 4.0 on pci13 pci14: on pcib21 pcib22: irq 33 at device 6.0 on pci0 pci16: on pcib22 pcib23: at device 0.0 on pci16 pci17: on pcib23 pcib24: at device 2.0 on pci17 pci19: on pcib24 pcib25: at device 4.0 on pci17 pci18: on pcib25 pcib26: at device 28.0 on pci0 pci21: on pcib26 uhci0: port 0xcc80-0xcc9f irq 20 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xcca0-0xccbf irq 20 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xccc0-0xccdf irq 20 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0xcce0-0xccff irq 20 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xde0ffc00-0xde0fffff irq 21 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib27: at device 30.0 on pci0 pci27: on pcib27 vgapci0: port 0xdc00-0xdcff mem 0xc8000000-0xcfffffff,0xde4f0000-0xde4fffff irq 17 at device 12.0 on pci27 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atrtc0: port 0x70-0x7f irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcbfff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est1 attach returned 6 p4tcc1: on cpu1 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est2 attach returned 6 p4tcc2: on cpu2 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est3 attach returned 6 p4tcc3: on cpu3 est4: on cpu4 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est4 attach returned 6 p4tcc4: on cpu4 est5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est5 attach returned 6 p4tcc5: on cpu5 est6: on cpu6 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est6 attach returned 6 p4tcc6: on cpu6 est7: on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est7 attach returned 6 p4tcc7: on cpu7 est8: on cpu8 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est8 attach returned 6 p4tcc8: on cpu8 est9: on cpu9 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est9 attach returned 6 p4tcc9: on cpu9 est10: on cpu10 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est10 attach returned 6 p4tcc10: on cpu10 est11: on cpu11 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est11 attach returned 6 p4tcc11: on cpu11 est12: on cpu12 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est12 attach returned 6 p4tcc12: on cpu12 est13: on cpu13 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est13 attach returned 6 p4tcc13: on cpu13 est14: on cpu14 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est14 attach returned 6 p4tcc14: on cpu14 est15: on cpu15 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 91e091e0800091e device_attach: est15 attach returned 6 p4tcc15: on cpu15 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered bce0: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00002006= ) bce1: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00002006= ) bce2: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00004006= ) bce3: bce_pulse(): Bootcode lost the driver pulse! (bc_state =3D 0x00004006= ) acd0: DVDROM at ata0-master UDMA33 SATA mfi0: 6706 (345318291s/0x0008/info) - Current capacity of the battery is above threshold mfid0: on mfi0 mfid0: 953344MB (1952448512 sectors) RAID volume 'root' is optimal mfid1: on mfi0 mfid1: 953344MB (1952448512 sectors) RAID volume 'storage' is optimal mfid2: on mfi0 mfid2: 953344MB (1952448512 sectors) RAID volume 'ports' is optimal SMP: AP CPU #1 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #5 Launched! Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered ugen4.2: at usbus4 uhub5: on usbus4 uhub5: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 ugen4.3: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 ums0: on usbus4 ums0: 3 buttons and [Z] coordinates ID=3D0 ugen4.4: at usbus4 uhub6: on usbus4 Root mount waiting for: usbus4 uhub6: 2 ports with 2 removable, self powered ugen1.2: at usbus1 ukbd1: on usbus1 kbd3 at ukbd1 uhid0: on usbus1 ugen4.5: at usbus4 uhub7: on usbus4 uhub7: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/mfid0s1a bce1: link state changed to UP mfi0: 6707 (345318356s/0x0008/info) - Battery started charging mfi0: 6708 (345318421s/0x0008/info) - Battery charge complete From owner-freebsd-net@FreeBSD.ORG Fri Dec 24 01:08:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE6DF106566B for ; Fri, 24 Dec 2010 01:08:35 +0000 (UTC) (envelope-from szander@swin.edu.au) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8A4EB8FC0A for ; Fri, 24 Dec 2010 01:08:35 +0000 (UTC) Received: from [136.186.229.101] (szander-laptop.caia.swin.edu.au [136.186.229.101]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id oBO0IJwX018072 for ; Fri, 24 Dec 2010 11:18:19 +1100 Message-ID: <4D13E6CC.7080503@swin.edu.au> Date: Fri, 24 Dec 2010 11:18:20 +1100 From: Sebastian Zander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPFW extension for traffic classification based on statistical properties X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 01:08:36 -0000 Hi all, We believe this may be of some interest to list members, and apologise in advance for any duplicates you may receive. We are pleased to announce DIFFUSE v0.1, our first release of a system enabling FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE v0.1, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) techniques to assign flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify classes of applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. DIFFUSE v0.1 contains an example classifier model for identifying real-time first person shooter game traffic. In the next release we will include a classifier model to detect Skype traffic. The project site (http://caia.swin.edu.au/urp/diffuse) contains a more comprehensive introduction, including application examples, links to related work and documentation describing the design of our software. DIFFUSE v0.1 is a set of patches for FreeBSD-CURRENT, and can be obtained directly from http://caia.swin.edu.au/urp/diffuse/downloads.html The software was developed as part of the DIFFUSE research project at Swinburne University's Centre for Advanced Internet Architectures. The project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. We welcome your feedback and hope you enjoy playing with the code and tools. Cheers, Sebastian Zander and Grenville Armitage http://caia.swin.edu.au From owner-freebsd-net@FreeBSD.ORG Fri Dec 24 05:22:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C004106566B for ; Fri, 24 Dec 2010 05:22:33 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 72B778FC0C for ; Fri, 24 Dec 2010 05:22:31 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBO5MRX2051920; Fri, 24 Dec 2010 11:22:28 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D142E0E.1050506@rdtc.ru> Date: Fri, 24 Dec 2010 11:22:22 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Sebastian Zander References: <4D13E6CC.7080503@swin.edu.au> In-Reply-To: <4D13E6CC.7080503@swin.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPFW extension for traffic classification based on statistical properties X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 05:22:33 -0000 On 24.12.2010 06:18, Sebastian Zander wrote: > Hi all, > > We believe this may be of some interest to list members, and > apologise in advance for any duplicates you may receive. > > We are pleased to announce DIFFUSE v0.1, our first release of a > system enabling FreeBSD's IPFW firewall subsystem to classify IP > traffic based on statistical traffic properties. > > With DIFFUSE v0.1, IPFW computes statistics (such as packet lengths > or inter-packet time intervals) for observed flows, and uses > ML (machine learning) techniques to assign flows into classes. > In addition to traditional packet inspection rules, IPFW rules > may now also be expressed in terms of traffic statistics > or classes identified by ML classification. This can be helpful > when direct packet inspection is problematic (perhaps for administrative > reasons, or because port numbers do not reliably identify classes of > applications). > > DIFFUSE also enables one instance of IPFW to send flow information > and classes to other IPFW instances, which then can act on such > traffic (e.g. prioritise, accept, deny, etc) according to its class. > This allows for distributed architectures, where classification at > one location in your network is used to control fire-walling or > rate-shaping actions at other locations. > > DIFFUSE v0.1 contains an example classifier model for identifying > real-time first person shooter game traffic. In the next release we > will include a classifier model to detect Skype traffic. > > The project site (http://caia.swin.edu.au/urp/diffuse) contains a more > comprehensive introduction, including application examples, links to > related work and documentation describing the design of our software. > > DIFFUSE v0.1 is a set of patches for FreeBSD-CURRENT, and can be > obtained directly from > http://caia.swin.edu.au/urp/diffuse/downloads.html > > The software was developed as part of the DIFFUSE research project at > Swinburne University's Centre for Advanced Internet Architectures. The > project has been made possible in part by a grant from the Cisco > University Research Program Fund at Community Foundation Silicon Valley. > > We welcome your feedback and hope you enjoy playing with the code and > tools. > > Cheers, > > Sebastian Zander and Grenville Armitage > > http://caia.swin.edu.au It would be nice to provide patches for RELENG_8 to get broader testing. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Dec 24 15:44:03 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB394106566B for ; Fri, 24 Dec 2010 15:44:03 +0000 (UTC) (envelope-from admin@shtorm.com) Received: from ns.shtorm.com (ns.shtorm.com [195.62.14.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2E5B08FC08 for ; Fri, 24 Dec 2010 15:44:02 +0000 (UTC) Received: from [10.66.6.77] (unknown [10.66.6.77]) by ns.shtorm.com (Postfix) with ESMTP id B26811A0AD1; Fri, 24 Dec 2010 17:43:33 +0200 (EET) From: Shtorm To: Eugene Grosbein In-Reply-To: <4D1083D6.6010707@rdtc.ru> References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Dec 2010 17:41:38 +0200 Message-ID: <1293205298.1917.191.camel@stormi> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: net Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 15:44:03 -0000 On Tue, 2010-12-21 at 16:39 +0600, Eugene Grosbein wrote: > On 20.12.2010 17:21, Shtorm wrote: > > On Sun, 2010-12-19 at 00:35 +0600, Eugene Grosbein wrote: > >> Hi! > >> > >> I've loaded router using two lagg interfaces in LACP mode. > >> lagg0 has IP address and two ports (em0 and em1) and carry untagged frames. > >> lagg1 has no IP address and has two ports (igb0 and igb1) and carry > >> about 1000 dot-q vlans with lots of hosts in each vlan. > >> > >> For lagg1, lagg distributes outgoing traffic over two ports just fine. > >> For lagg0 (untagged ethernet segment with only 2 MAC addresses) > >> less than 0.07% (54Mbit/s max) of traffic goes to em0 > >> and over 99.92% goes to em1, that's bad. > >> > >> That's general traffic of several thousands of customers surfing the web, > >> using torrents etc. I've glanced over lagg/lacp sources if src/sys/net/ > >> and found nothing suspicious, it should extract and use srcIP/dstIP for hash. > >> > >> How do I debug this problem? > >> > >> 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" > > > > I had this problem with igb driver, and I found, that lagg selects > > outgoing interface based on packet header flowid field if M_FLOWID field > > is set. And in the igb driver code flowid is set as > > > > #if __FreeBSD_version >= 800000 > > <------><------><------>rxr->fmp->m_pkthdr.flowid = que->msix; > > <------><------><------>rxr->fmp->m_flags |= M_FLOWID; > > #endif > > > > The same thing in em driver with MULTIQUEUE > > > > That does not give enough number of flows to balance traffic well, so I > > commented check in if_lagg.c > > > > lagg_lb_start(struct lagg_softc *sc, struct mbuf *m) > > { > > <------>struct lagg_lb *lb = (struct lagg_lb *)sc->sc_psc; > > <------>struct lagg_port *lp = NULL; > > <------>uint32_t p = 0; > > > > //<---->if (m->m_flags & M_FLOWID) > > //<----><------>p = m->m_pkthdr.flowid; > > //<---->else > > > > and with this change I have much better load distribution across interfaces. > > > > Hope it helps. > > You are perfectly right. By disabling flow usage I've obtained load sharing > close to even (final patch follows). Two questions: > > 1. Is it a bug or design problem? > 2. Will I get problems like packet reordering by permanently disabling > usage of these flows in lagg(4)? > > --- if_lagg.c.orig 2010-12-20 22:53:21.000000000 +0600 > +++ if_lagg.c 2010-12-21 13:37:20.000000000 +0600 > @@ -168,6 +168,11 @@ > &lagg_failover_rx_all, 0, > "Accept input from any interface in a failover lagg"); > > +int lagg_use_flows = 1; > +SYSCTL_INT(_net_link_lagg, OID_AUTO, use_flows, CTLFLAG_RW, > + &lagg_use_flows, 1, > + "Use flows for load sharing"); > + > static int > lagg_modevent(module_t mod, int type, void *data) > { > @@ -1666,7 +1671,7 @@ > struct lagg_port *lp = NULL; > uint32_t p = 0; > > - if (m->m_flags & M_FLOWID) > + if (lagg_use_flows && (m->m_flags & M_FLOWID)) > p = m->m_pkthdr.flowid; > else > p = lagg_hashmbuf(m, lb->lb_key); > --- if_lagg.h.orig 2010-12-21 16:34:35.000000000 +0600 > +++ if_lagg.h 2010-12-21 16:35:27.000000000 +0600 > @@ -242,6 +242,8 @@ > int lagg_enqueue(struct ifnet *, struct mbuf *); > uint32_t lagg_hashmbuf(struct mbuf *, uint32_t); > > +extern int lagg_use_flows; > + > #endif /* _KERNEL */ > > #endif /* _NET_LAGG_H */ > --- ieee8023ad_lacp.c.orig 2010-12-21 16:36:09.000000000 +0600 > +++ ieee8023ad_lacp.c 2010-12-21 16:35:58.000000000 +0600 > @@ -812,7 +812,7 @@ > return (NULL); > } > > - if (m->m_flags & M_FLOWID) > + if (lagg_use_flows && (m->m_flags & M_FLOWID)) > hash = m->m_pkthdr.flowid; > else > hash = lagg_hashmbuf(m, lsc->lsc_hashkey); > > 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" Can you please look at the different and maybe more generic solution for the lagg and flowid problem? In if_ethersubr.c in function ether_input I addeded this code m->m_flags |= M_FLOWID; m->m_pkthdr.flowid = eh->ether_dhost[0] + eh->ether_dhost[1] + eh->ether_dhost[2] + eh->ether_dhost[3] + eh->ether_dhost[4] + eh->ether_dhost[5]; m->m_pkthdr.flowid += eh->ether_shost[0] + eh->ether_shost[1] + eh->ether_shost[2] + eh->ether_shost[3] + eh->ether_shost[4] + eh->ether_shost[5]; and in function ether_demux I addeded this case ETHERTYPE_IP: if ((m = ip_fastforward(m)) == NULL) return; isr = NETISR_IP; struct ipheader { u_char offset [12]; //ip header fields not actually needed u_char src [4]; //ip src u_char dst [4]; //ip dst } __packed __aligned(4); if (m->m_pkthdr.len < sizeof(struct ipheader)) { //ip header and mbuf stuff stolen from ip_fastforward if_printf(ifp, "flowid math: discard frame with too small header\n"); goto discard; } if (m->m_len < sizeof (struct ipheader) && (m = m_pullup(m, sizeof (struct ipheader))) == NULL) { if_printf(ifp, "flowid math: discard frame at pullup\n"); return;> /* mbuf already free'd */ } struct ipheader *ip; ip = mtod(m, struct ipheader *); m->m_pkthdr.flowid += ip->src[0] + ip->src[1] + ip->src[2] + ip->src[3]; m->m_pkthdr.flowid += ip->dst[0] + ip->dst[1] + ip->dst[2] + ip->dst[3]; // if_printf(ifp, "Calculated flow id %d\n", m->m_pkthdr.flowid); break; case ETHERTYPE_ARP: Sorry, I have no idea how to create nice diff, maybe point to small howto will help :) Probably this code should be wrapped by sysctl check, so it can be enabled or disabled for l2 and l3 info, but I do not know how to do this. In case we calculate flowid early at ethernet input, we not only solve lagg load distribution but also different flows can be processed with different netisr threads when fastforwarding disabled. I know about wasting some cpu on this, but for example, for the router with 4 cores and two em cards top looks like this: last pid: 84129; load averages: 0.06, 0.12, 0.09 up 9+14:21:30 17:30:50 175 processes: 6 running, 145 sleeping, 24 waiting CPU 0: 2.3% user, 0.0% nice, 3.9% system, 27.9% interrupt, 65.9% idle CPU 1: 1.6% user, 0.0% nice, 1.6% system, 26.4% interrupt, 70.5% idle CPU 2: 3.1% user, 0.0% nice, 1.6% system, 34.1% interrupt, 61.2% idle CPU 3: 0.8% user, 0.0% nice, 1.5% system, 30.0% interrupt, 67.7% idle Mem: 175M Active, 38M Inact, 262M Wired, 108K Cache, 60M Buf, 1497M Free Swap: # netstat -I em0 -w 1 input (em0) output packets errs idrops bytes packets errs bytes colls 46381 0 0 49430586 36616 0 21480310 0 45753 0 0 47685283 36941 0 22789381 0 46167 0 0 48173940 37736 0 23442515 0 46608 0 0 49172207 37705 0 23199023 0 50114 0 0 53050475 39719 0 23409046 0 47786 0 0 49826567 37621 0 23658505 0 ^C # This box is all in one router - ppoe server with nat and dummynet shaping, and with my changes it can nat, shape and forward up to 100 kpps in each direction with 30% idle on all cores. Thanks a lot. Yuriy. From owner-freebsd-net@FreeBSD.ORG Fri Dec 24 16:51:14 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF3EE10656A5 for ; Fri, 24 Dec 2010 16:51:14 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 33F6C8FC08 for ; Fri, 24 Dec 2010 16:51:13 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oBOGpAro002498; Fri, 24 Dec 2010 22:51:10 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D14CF7E.8020902@rdtc.ru> Date: Fri, 24 Dec 2010 22:51:10 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Shtorm References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <1293205298.1917.191.camel@stormi> In-Reply-To: <1293205298.1917.191.camel@stormi> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: net Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 16:51:15 -0000 On 24.12.2010 21:41, Shtorm wrote: > Sorry, I have no idea how to create nice diff, maybe point to small > howto will help :) Copy original file as "file.c.orig" and put your changes to "file.c" then do "diff -u file.c.orig file.c > file.c.diff" then repost file.c.diff contents. From owner-freebsd-net@FreeBSD.ORG Fri Dec 24 23:07:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D34E11065670; Fri, 24 Dec 2010 23:07:06 +0000 (UTC) (envelope-from jan.koum@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2928FC19; Fri, 24 Dec 2010 23:07:06 +0000 (UTC) Received: by qyk36 with SMTP id 36so7081293qyk.13 for ; Fri, 24 Dec 2010 15:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=G1X9KC6+eWILcy89mcqm160Y48i5NdZMuAMIZADu/iE=; b=haekRCHNecGttakH3E6lVHx9lsnLOMLwE4KACToQ85ZxaNN6YycnAjgpoPhzxKTavW hR8/yC3GZGu1xgyUKTwijUj4DBtJADj0H+XBk/yeubrX9RHsMs8I2HQWjNq9Q2wcJem6 hteBNSf3pEFq3B1nFn58jsgox/nvnpd+mEQV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=F0kX7Kw+m7+VmlegUp+dH4Zgx0FMy6Hro9VZMRugOluJZYaEXsGqrDri/ISXex/zfJ KDkySJarvdrqNQmvBEtpw/fyK7ztFDERNZpyI6LRyJ6UrJS0t/3lq/yuikDzXxnyWLG+ oauSzNKGUeKAKuiTz4omH48RoGb3dP4UHqI/o= MIME-Version: 1.0 Received: by 10.229.187.199 with SMTP id cx7mr8506328qcb.132.1293230671009; Fri, 24 Dec 2010 14:44:31 -0800 (PST) Sender: jan.koum@gmail.com Received: by 10.229.241.211 with HTTP; Fri, 24 Dec 2010 14:44:30 -0800 (PST) In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> Date: Fri, 24 Dec 2010 14:44:30 -0800 X-Google-Sender-Auth: 38AsrF8lzP7uUU_DiMZZxLWiSKo Message-ID: From: Jan Koum To: Ivan Voras , Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Jack Vogel , Sean Bruno , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 23:07:06 -0000 hi Ivan and Mike, wanted to follow up and see if you found a solid long-term solution to this bug. we are still seeing this problem in our 8.2 environment with ASPM already disabled. here is what we have: 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: em0@pci0:3:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet em1@pci0:4:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet em2@pci0:5:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet em3@pci0:6:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet 2. ASPM is already disabled in the BIOS 3. when em1 interface locks up, sysctl debug says: Interface is NOT RUNNING and INACTIVE em1: hw tdh = 0, hw tdt = 0 em1: hw rdh = 0, hw rdt = 0 em1: Tx Queue Status = 0 em1: TX descriptors avail = 110 em1: Tx Descriptors avail failure = 319 em1: RX discarded packets = 0 em1: RX Next to Check = 80 em1: RX Next to Refresh = 80 4. doing "ifconfig em1 down; sleep1; ifconfig em1 up" resolves the issue and removes OACTIVE flag from em1. 5. we are running 8.2-PRERELEASE from December 19th: % grep '$FreeBSD' /usr/src/sys/dev/e1000/if_em.c /*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.18 2010/12/14 19:59:39 jfv Exp $*/ dmesg output is: em1: port 0xcc00-0xcc1f mem 0xfb4e0000-0xfb4fffff,0xfb4dc000-0xfb4dffff irq 17 at device 0.0 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfb4e0000 em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfb4dc000 em1: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 259 to local APIC 0 vector 53 msi: routing MSI-X IRQ 260 to local APIC 0 vector 54 msi: routing MSI-X IRQ 261 to local APIC 0 vector 55 em1: using IRQs 259-261 for MSI-X em1: Using MSIX interrupts with 3 vectors em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: bpf attached em1: Ethernet address: 00:25:90:0e:25:e9 aside from running cronjob every minute to check for dead interface and reset it, is there anything else we can try? thanks. On Tue, Nov 23, 2010 at 10:36 AM, Jack Vogel wrote: > 82574 is supposed to be em, not igb :) Its always had this kind of > 'in-between' > status, it was targeted as a 'client' or consumer part, but it has MSIX > which > make it almost like 8257[56]. > > Mike, there are some further 82574 changes to shared code that I'm looking > into today. > > Jack > > > On Tue, Nov 23, 2010 at 10:17 AM, Mike Tancsa wrote: > > > On 11/23/2010 12:39 PM, Sean Bruno wrote: > > > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > > >> It looks like I'm unfortunate enough to have to deploy on a machine > > >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, > which > > > igb0@pci0:5:0:0: class=0x020000 card=0x8975152d chip=0x10c98086 > > > > Strange, the 82574 attaches as em for me, not igb > > > > em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > 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 max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected > > ecap 0003[140] = Serial 1 001517ffffed68a4 > > > > Normally, its msix, but I had disabled that hoping it would fix the > problem > > > > em1: port 0x2000-0x201f mem > > 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at dev > > ice 0.0 on pci10 > > em1: Using an MSI interrupt > > em1: [FILTER] > > em1: Ethernet address: 00:15:17:ed:68:a4 > > > > > > ---Mike > > _______________________________________________ > > 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-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org > " > From owner-freebsd-net@FreeBSD.ORG Fri Dec 24 23:21:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CB71106564A; Fri, 24 Dec 2010 23:21:11 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE7598FC0A; Fri, 24 Dec 2010 23:21:10 +0000 (UTC) Received: by qwj9 with SMTP id 9so7138305qwj.13 for ; Fri, 24 Dec 2010 15:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=hL+ACW00U2D5STmjwAGOtnAKP21h3hqvQzQ/jfjjFtM=; b=mEfN1vvUjHHc1gymt5Nzi33tUujDu7XmioVC9JPbkhVZU6TGGLr25SiuTI0jDzCnYt JH/Zz1CWxhkR0TpAxqgmZb6PQGr5fh0QUwKAqEDzuMBfhPRTFM7mSyvtIliU8LSLyubp R3z4hc1dDGfdTpDBbN0L3Crmn50HINbplDAJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=XGv217BbMA0SQH3G1ACAMyOWPPu7rDpyRsZDibONTjRWosfGtrzpK1QWdbo+IAGwaC QFyx0h5rxIrjXVcvbGgLVqobH9WTy8CErw3bA8m/HOlmFiqhUnWaRnumnmjgCedTE9Hu fwS7Q1a+EJrHrNXY1Tbi5mzb+Nq9L1KkMkIiA= Received: by 10.229.246.79 with SMTP id lx15mr8919094qcb.25.1293232869620; Fri, 24 Dec 2010 15:21:09 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.44.70 with HTTP; Fri, 24 Dec 2010 15:20:29 -0800 (PST) In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> From: Ivan Voras Date: Sat, 25 Dec 2010 00:20:29 +0100 X-Google-Sender-Auth: pChvIQdtL9ObqcF2JY0tCu4zJ6A Message-ID: To: Jan Koum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Jack Vogel , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 23:21:11 -0000 On 24 December 2010 23:44, Jan Koum wrote: > > hi Ivan and Mike, > wanted to follow up and see if you found a solid long-term solution to th= is > bug.=C2=A0we are still seeing this problem in our 8.2 environment with AS= PM > already disabled. =C2=A0here is what we have: Hi, The patches Jack made when this discussion was ongoing helped both me and AFAIK Mike also. The machine I had which exhibited these problems now works fine and stable. The patches should have been MFCed, but just in case - try the version from 9-current. During testing, I've also found that the BIOS setting "Remap PCI memory" or "Remap device memory" or something like that (I can't look it up now) also helps if disabled. Mike AFAIK didn't have this setting in his machine's BIOS. From owner-freebsd-net@FreeBSD.ORG Sat Dec 25 02:19:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75CF7106566C; Sat, 25 Dec 2010 02:19:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 07F878FC0C; Sat, 25 Dec 2010 02:19:28 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:5570:ff31:c40c:8eac] ([IPv6:2607:f3e0:0:4:5570:ff31:c40c:8eac]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oBP2JQmh036316 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 24 Dec 2010 21:19:26 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D1554A7.5000507@sentex.net> Date: Fri, 24 Dec 2010 21:19:19 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jan Koum References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Sean Bruno , Jack Vogel , Ivan Voras , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 02:19:29 -0000 On 12/24/2010 5:44 PM, Jan Koum wrote: > hi Ivan and Mike, > > wanted to follow up and see if you found a solid long-term solution to this > bug. we are still seeing this problem in our 8.2 environment with ASPM > already disabled. here is what we have: Hmmm, With the latest version of the driver in RELENG_8 (its the same as in HEAD) I havent seen the problem. However, I would only see it once per week prior to that. The odd thing is that it would happen during a slightly lower than normal backup load, but almost always at the same time (early sunday AM). Not sure what would trigger it exactly. If it happened again, I was going to enable port mirroring on the switchport and capture the traffic, hoping some "special" pattern would enable the issue. Do you have IPMI enabled on the NIC ? I tried to turn it off on my MB, but there is no clear way to do this. It 'seems' to be off, but not sure if it really is. One thing I noticed was that when the NIC was hung, it still was able to receive and process IPMI commands from an external host. ---Mike > > 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: > > em0@pci0:3:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > em1@pci0:4:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > em2@pci0:5:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > em3@pci0:6:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > > 2. ASPM is already disabled in the BIOS > > 3. when em1 interface locks up, sysctl debug says: > > Interface is NOT RUNNING > and INACTIVE > em1: hw tdh = 0, hw tdt = 0 > em1: hw rdh = 0, hw rdt = 0 > em1: Tx Queue Status = 0 > em1: TX descriptors avail = 110 > em1: Tx Descriptors avail failure = 319 > em1: RX discarded packets = 0 > em1: RX Next to Check = 80 > em1: RX Next to Refresh = 80 > > 4. doing "ifconfig em1 down; sleep1; ifconfig em1 up" resolves the issue and > removes OACTIVE flag from em1. > > 5. we are running 8.2-PRERELEASE from December 19th: > % grep '$FreeBSD' /usr/src/sys/dev/e1000/if_em.c > /*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.18 2010/12/14 19:59:39 jfv > Exp $*/ > > dmesg output is: > > em1: port 0xcc00-0xcc1f mem > 0xfb4e0000-0xfb4fffff,0xfb4dc000-0xfb4dffff irq 17 at device 0.0 on pci4 > em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfb4e0000 > em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfb4dc000 > em1: attempting to allocate 3 MSI-X vectors (5 supported) > msi: routing MSI-X IRQ 259 to local APIC 0 vector 53 > msi: routing MSI-X IRQ 260 to local APIC 0 vector 54 > msi: routing MSI-X IRQ 261 to local APIC 0 vector 55 > em1: using IRQs 259-261 for MSI-X > em1: Using MSIX interrupts with 3 vectors > em1: [MPSAFE] > em1: [ITHREAD] > em1: [MPSAFE] > em1: [ITHREAD] > em1: [MPSAFE] > em1: [ITHREAD] > em1: bpf attached > em1: Ethernet address: 00:25:90:0e:25:e9 > > aside from running cronjob every minute to check for dead interface and > reset it, is there anything else we can try? > > thanks. > > > On Tue, Nov 23, 2010 at 10:36 AM, Jack Vogel wrote: > >> 82574 is supposed to be em, not igb :) Its always had this kind of >> 'in-between' >> status, it was targeted as a 'client' or consumer part, but it has MSIX >> which >> make it almost like 8257[56]. >> >> Mike, there are some further 82574 changes to shared code that I'm looking >> into today. >> >> Jack >> >> >> On Tue, Nov 23, 2010 at 10:17 AM, Mike Tancsa wrote: >> >>> On 11/23/2010 12:39 PM, Sean Bruno wrote: >>>> On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: >>>>> It looks like I'm unfortunate enough to have to deploy on a machine >>>>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, >> which >>>> igb0@pci0:5:0:0: class=0x020000 card=0x8975152d chip=0x10c98086 >>> >>> Strange, the 82574 attaches as em for me, not igb >>> >>> em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 >>> rev=0x00 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >>> 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 max data 128(256) link x1(x1) >>> cap 11[a0] = MSI-X supports 5 messages in map 0x1c >>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected >>> ecap 0003[140] = Serial 1 001517ffffed68a4 >>> >>> Normally, its msix, but I had disabled that hoping it would fix the >> problem >>> >>> em1: port 0x2000-0x201f mem >>> 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at dev >>> ice 0.0 on pci10 >>> em1: Using an MSI interrupt >>> em1: [FILTER] >>> em1: Ethernet address: 00:15:17:ed:68:a4 >>> >>> >>> ---Mike >>> _______________________________________________ >>> 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-hardware@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware >> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org >> " >> > From owner-freebsd-net@FreeBSD.ORG Sat Dec 25 19:44:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3FF0106564A for ; Sat, 25 Dec 2010 19:44:24 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4B68FC12 for ; Sat, 25 Dec 2010 19:44:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PWa2Q-00044L-O5 for freebsd-net@freebsd.org; Sat, 25 Dec 2010 20:44:22 +0100 Received: from 109.227.31.204 ([109.227.31.204]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Dec 2010 20:44:22 +0100 Received: from ivoras by 109.227.31.204 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Dec 2010 20:44:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sat, 25 Dec 2010 20:44:14 +0100 Lines: 24 Message-ID: References: <4D13E6CC.7080503@swin.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.227.31.204 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 In-Reply-To: <4D13E6CC.7080503@swin.edu.au> Subject: Re: IPFW extension for traffic classification based on statistical properties X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 19:44:24 -0000 On 24.12.2010 1:18, Sebastian Zander wrote: > With DIFFUSE v0.1, IPFW computes statistics (such as packet lengths > or inter-packet time intervals) for observed flows, and uses > ML (machine learning) techniques to assign flows into classes. > In addition to traditional packet inspection rules, IPFW rules > may now also be expressed in terms of traffic statistics > or classes identified by ML classification. This can be helpful > when direct packet inspection is problematic (perhaps for administrative > reasons, or because port numbers do not reliably identify classes of > applications). How successful (accurate) can something like this be? For example, if there is torrent traffic on a network, it will (probably) be a mixture of slow and fast connections which have different latencies due to, among others, geographical distribution. If you introduce e.g. web traffic on the one side and ssh sessions, IM sessions and similar "interactive" traffic, do you have any results showing you can correctly classify and prioritize the interactive traffic (meaning ssh and IM, not bittorrent and web)? (I'm not asking specifically for DIFFUSE but mostly about the general approach). From owner-freebsd-net@FreeBSD.ORG Sat Dec 25 19:52:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BAC21065670 for ; Sat, 25 Dec 2010 19:52:51 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B46218FC0C for ; Sat, 25 Dec 2010 19:52:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PWaAa-0007S7-Cs for freebsd-net@freebsd.org; Sat, 25 Dec 2010 20:52:48 +0100 Received: from 212.15.189.9 ([212.15.189.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Dec 2010 20:52:48 +0100 Received: from ivoras by 212.15.189.9 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Dec 2010 20:52:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sat, 25 Dec 2010 20:52:30 +0100 Lines: 9 Message-ID: References: <4D0CFEFF.3000902@rdtc.ru> <1292844095.1917.136.camel@stormi> <4D1083D6.6010707@rdtc.ru> <84530C06-AC2E-4E2B-BFD4-693902BB0FA6@netasq.com> <4D10B2F4.1060404@rdtc.ru> <90F64F73-F9A8-4FD6-9303-2FC0D3424751@netasq.com> <4D10BE3E.6030506@rdtc.ru> <4D123B7C.1070104@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 212.15.189.9 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 In-Reply-To: <4D123B7C.1070104@rdtc.ru> Subject: Re: lagg/lacp poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 19:52:51 -0000 On 22.12.2010 18:55, Eugene Grosbein wrote: > It seems, we really need sysctl disabling lagg's use of flows, don't we? If no developer is willing to work on it right now, you should probably create a PR with your patch so it doesn't get lost. Also, a patch describing the sysctl in the lagg(4) man page would probably get it committed faster :)