From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 01:19:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2EABE3B; Sun, 20 Jan 2013 01:19:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5548D6; Sun, 20 Jan 2013 01:19:20 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id 12so314680wgh.5 for ; Sat, 19 Jan 2013 17:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cFL1Dk1pfQ0JphC5i1PazcBCwHHiC7WhvlRebxOBzRc=; b=h71duRcmXHAomb8LnPXBC/8TQj3BpAWR6H6tGAAIHrjzUBEyIPnkZzEa883rQXQprw zgOfpcHc0UQw+NhjezbFu4VyASm0suPWG3Y5t9Bo8CfUfUxB6wP/55ackyopcqh+RFFv jAvLbWTtcsz7lnUkuqs6E1UtPRw6e07dOnYzHM+lDmmRV6O5e2BfECXMPiv0OL12Q3mb wo8EX8R0L4Os2rBENvvhF8wQka175DtEPDysy6Hz4W9fLfNdTmWYdhtAp8+Y/yPGUBwn JibLbGG6xcXFFspPZz/h1JlFIEeF4+5ZifURXp3Q9d0uIUF1iLN2064FXdoZm+1CiN4X Sj+g== MIME-Version: 1.0 X-Received: by 10.194.179.34 with SMTP id dd2mr20487599wjc.1.1358644759573; Sat, 19 Jan 2013 17:19:19 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 19 Jan 2013 17:19:19 -0800 (PST) In-Reply-To: <201301191114.29959.jhb@freebsd.org> References: <1358610450.75691.YahooMailClassic@web121604.mail.ne1.yahoo.com> <201301191114.29959.jhb@freebsd.org> Date: Sat, 19 Jan 2013 17:19:19 -0800 X-Google-Sender-Auth: FGQOffy1vRYn6jXY-k8kC661zOE Message-ID: Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Barney Cordoba , Luigi Rizzo , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jan 2013 01:19:21 -0000 On 19 January 2013 08:14, John Baldwin wrote: > However, I did describe an alternate setup where you can fix this. Part of > the key is to get various NICs to share a single logical queue of tasks. You > could simulate this now by having all the deferred tasks share a single > taskqueue with a pool of tasks, but that will still not fully cooperate with > ithreads. To do that you have to get the interrupt handlers themselves into > the shared taskqueue. Some changes I have in a p4 branch allow you to do that > by letting interrupt handlers reschedule themselves (avoiding the need for a > separate task and preventing the task from running concurrently with the > interrupt handler) and providing some (but not yet all) of the framework to > allow multiple devices to share a single work queue backed by a shared pool of > threads. How would that work when I want to pin devices to specific cores? We at ${WORK} developed/acquired/etc a company that makes network processors that are highly threaded, where you want to pin specific things to specific CPUs. If you just push network device handling to a pool of threads without allowing for pinning, you'll end up with some very, very poor behaviour. Windows, for example, complains loudly (read: BSODs saying your driver is buggy) if your tasklets take too much CPU to run without preempting. So at ${WORK}, we do yield RX processing after a (fair) while. Maybe we do want a way to allow the RX taskqueue to yield itself in a way that (a) let's us re-schedule it, and (b) tells the taskqueue to actually yield after this point and let other things have a go. Barney - yes I think processing 100 packets each time through the loop, on a gige interface, is a bit silly. My point was specifically about how to avoid livelock without introducing artificial delays in waiting for the next mitigated interrupt to occur (because you don't necessarily get another interrupt when you re-enable things, depending upon what the hardware is doing / how buggy your driver is.) Ideally you'd set some hard limit on how much CPU time the task takes before it yields, so you specifically avoid livelock under DoS conditions. Actually, one thing I did at a previous job, many years ago now, was to do weighted random / tail dropping of frames in the driver RX handling itself, rather than having it go up to the stack and take all the extra CPU to process things. Again, my suggestion is how to avoid livelock under highly stressful conditions, rather than just going down the path of polling (for example.) Adrian From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 01:48:30 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A96896C6; Sun, 20 Jan 2013 01:48:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 84E239C8; Sun, 20 Jan 2013 01:48:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0K1mULq062944; Sun, 20 Jan 2013 01:48:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0K1mUpe062940; Sun, 20 Jan 2013 01:48:30 GMT (envelope-from linimon) Date: Sun, 20 Jan 2013 01:48:30 GMT Message-Id: <201301200148.r0K1mUpe062940@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/175236: [epair] [gif] epair and gif Devices On Bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jan 2013 01:48:30 -0000 Old Synopsis: epair and gif Devices On Bridge New Synopsis: [epair] [gif] epair and gif Devices On Bridge Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 20 01:48:18 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=175236 From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 01:54:16 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E360861; Sun, 20 Jan 2013 01:54:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 79B689FA; Sun, 20 Jan 2013 01:54:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0K1sGQq065054; Sun, 20 Jan 2013 01:54:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0K1sGWB065050; Sun, 20 Jan 2013 01:54:16 GMT (envelope-from linimon) Date: Sun, 20 Jan 2013 01:54:16 GMT Message-Id: <201301200154.r0K1sGWB065050@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174958: [net] [patch] rnh_walktree_from makes unreasonable assumptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jan 2013 01:54:16 -0000 Old Synopsis: [patch] rnh_walktree_from makes unreasonable assumptions New Synopsis: [net] [patch] rnh_walktree_from makes unreasonable assumptions Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 20 01:53:40 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174958 From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 01:54:30 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 372D1939; Sun, 20 Jan 2013 01:54:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 131F4A00; Sun, 20 Jan 2013 01:54:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0K1sTCx065100; Sun, 20 Jan 2013 01:54:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0K1sTlE065096; Sun, 20 Jan 2013 01:54:29 GMT (envelope-from linimon) Date: Sun, 20 Jan 2013 01:54:29 GMT Message-Id: <201301200154.r0K1sTlE065096@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174959: [net] [patch] rnh_walktree_from visits spurious nodes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jan 2013 01:54:30 -0000 Old Synopsis: [patch] rnh_walktree_from visits spurious nodes New Synopsis: [net] [patch] rnh_walktree_from visits spurious nodes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 20 01:54:19 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174959 From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 01:57:15 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63EE2AD0; Sun, 20 Jan 2013 01:57:15 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3D225A35; Sun, 20 Jan 2013 01:57:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0K1vFTj065328; Sun, 20 Jan 2013 01:57:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0K1vFHa065324; Sun, 20 Jan 2013 01:57:15 GMT (envelope-from linimon) Date: Sun, 20 Jan 2013 01:57:15 GMT Message-Id: <201301200157.r0K1vFHa065324@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174897: [route] Interface routes are broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jan 2013 01:57:15 -0000 Old Synopsis: Interface routes are broken New Synopsis: [route] Interface routes are broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 20 01:56:52 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174897 From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 04:30:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D2D980D for ; Sun, 20 Jan 2013 04:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7F5FA3 for ; Sun, 20 Jan 2013 04:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0K4U1lK093892 for ; Sun, 20 Jan 2013 04:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0K4U1A4093891; Sun, 20 Jan 2013 04:30:01 GMT (envelope-from gnats) Date: Sun, 20 Jan 2013 04:30:01 GMT Message-Id: <201301200430.r0K4U1A4093891@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 04:30:01 -0000 The following reply was made to PR kern/172113; it has been noted by GNATS. From: John Baldwin To: bug-followup@FreeBSD.org, egrosbein@rdtc.ru Cc: jfv@FreeBSD.org, George Neville-Neil Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Date: Sat, 19 Jan 2013 23:26:17 -0500 I was able to finally reproduce this panic today. It seems to require a server configured for PXE but that receives no DHCP reply (and possibly with the requisite SuperMicro X8 board). I was able to prevent the panic with a subset of the referenced patch by only adding the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of igb_msix_que(). The rest of the patch was unnecessary. I also added some debugging to print out the ICR, EICR, IMS, and EIMS registers in this case. It does look like the hardware is sending an interrupt that is not enabled in the interrupt mask (specifically LSC). In fact, the 82576 datasheet specifically mentions masking LSC until initialization is complete to avoid spurious interrupts during boot and AFAICT igb(4) does this since e1000_reset_hw() clears the interrupt mask via writes to IMC and doesn't re-enable interrupts until igb_init_locked() is invoked via 'ifconfig up'. Here is my debug output: SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! stray irq0 igb0: interrupt on que 0: icr 0x1000004 eicr 0 ims 0 eims 0x80000000 Hmmm. Nothing clears EIMS. After some more debugging, I determined that e1000_reset_hw() always turns this bit in EIMS on, even if it is off before e1000_reset_hw() is called(!). I added explicit calls to igb_disable_intr() to clear EIMS after each call to e1000_reset_hw(). This removes the 'stray irq0', but I still get a spurious interrupt during boot (albeit with eims 0). I can use the IFF_DRV_RUNNING hack for now, but I think the real fix is something else. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 10:24:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59B82398; Sun, 20 Jan 2013 10:24:50 +0000 (UTC) (envelope-from kubito@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D048A89; Sun, 20 Jan 2013 10:24:49 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so2284027dad.41 for ; Sun, 20 Jan 2013 02:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=if2OB6e137w9ZMBuv7R+RnjXkCME7Fzv2E/i/+pZlGU=; b=a1HK39Syb893r1SHgf9E++E/J4u/pQ4RTFYrcVPUY1O7XTW7xMhM0hEXJq+ZyBQATM ec56ptoRjBKbBtw0ZMHV+lcOBsCMjK1POlZt0VM7Bh5FeZxaZmqZS8XxqvMw2Mfpzdge iNWoRJImJf2qERTlOMq57CorOm3xUP+YakMbG70T+iEximCCmkA7J5YGPAaEWUQo4VXO QinnLR3v1QqeyzWoBqAiEGcUFk79mqvPWNenwEObUEDWpGjSL31FwhUR7eQNUo9pyTwg a8P+tc2jVRchgybpdCFPEmovjTF+3Yuot8FzljaWWFSI6oDVolmErHbST2pnIzDCqFzL 9biQ== X-Received: by 10.69.0.74 with SMTP id aw10mr20945644pbd.87.1358677489719; Sun, 20 Jan 2013 02:24:49 -0800 (PST) Received: from rachacuca.gmail.com (li113-135.members.linode.com. [69.164.198.135]) by mx.google.com with ESMTPS id ou3sm6551549pbb.46.2013.01.20.02.24.47 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 20 Jan 2013 02:24:48 -0800 (PST) Sender: Raphael Kubo da Costa From: Raphael Kubo da Costa To: glebius@FreeBSD.org Subject: Re: kern/174707: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) References: <201301200734.r0K7YH4w027535@freefall.freebsd.org> Date: Sun, 20 Jan 2013 08:24:36 -0200 In-Reply-To: <201301200734.r0K7YH4w027535@freefall.freebsd.org> (glebius@freebsd.org's message of "Sun, 20 Jan 2013 07:34:17 GMT") Message-ID: <83wqv8nod7.fsf@FreeBSD.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jan 2013 10:24:50 -0000 glebius@FreeBSD.org writes: > Synopsis: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) > > Responsible-Changed-From-To: glebius->rakuco > Responsible-Changed-By: glebius > Responsible-Changed-When: Sun Jan 20 07:33:56 UTC 2013 > Responsible-Changed-Why: > Let Raphael handle the MFC. hselasky@ has already MFC'ed this to 9 a while ago. Do you think it is safe enough to MFC to 8 and 7? From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 10:45:29 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C8BB8712; Sun, 20 Jan 2013 10:45:29 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 98E09BE1; Sun, 20 Jan 2013 10:45:28 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r0KAjQaF027267; Sun, 20 Jan 2013 14:45:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r0KAjQLv027266; Sun, 20 Jan 2013 14:45:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 20 Jan 2013 14:45:26 +0400 From: Gleb Smirnoff To: Raphael Kubo da Costa Subject: Re: kern/174707: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) Message-ID: <20130120104526.GI14114@glebius.int.ru> References: <201301200734.r0K7YH4w027535@freefall.freebsd.org> <83wqv8nod7.fsf@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <83wqv8nod7.fsf@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jan 2013 10:45:29 -0000 On Sun, Jan 20, 2013 at 08:24:36AM -0200, Raphael Kubo da Costa wrote: R> glebius@FreeBSD.org writes: R> R> > Synopsis: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) R> > R> > Responsible-Changed-From-To: glebius->rakuco R> > Responsible-Changed-By: glebius R> > Responsible-Changed-When: Sun Jan 20 07:33:56 UTC 2013 R> > Responsible-Changed-Why: R> > Let Raphael handle the MFC. R> R> hselasky@ has already MFC'ed this to 9 a while ago. Do you think it is R> safe enough to MFC to 8 and 7? You and Hans decide. The PR can be closed since fix already reached a stable branch. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 04:02:30 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44D88634 for ; Mon, 21 Jan 2013 04:02:30 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id CF5B6809 for ; Mon, 21 Jan 2013 04:02:29 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id b15so2600627eek.39 for ; Sun, 20 Jan 2013 20:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=JUtjVDocRouGdWt4Ny8PHh7OuaawCZlCkU5DEnRzsII=; b=qqZkAOs767iCA6qpWSSDwan+5hPfy+IUz/r+V3HQQhkK29RzRZuTvw5msoFbeOSrLu qV5DM+hCK+hiqDuQNTPgsGENJvMvdph4C3uFBICJNmcmWnbQ1BoW1ldb9SVNPiHCnwfd rFQXHUzgbosqJwvK+iuJiM6InNAkFI9Ibz391GGmSAxKPyUFnsiIZFN6RLtms+fPRBna mpUgoOExnYnV35iTglm6BX8tKqdZ2Cxt0AVLFEOREjo2Xhn0VKkb5xHbr5h525XAINkR 6cPARTJ2iJgYShmvXpt16FuftGBHVWOCMiBdMo3FIQHLAQ7nc7ovYQ5E+ScJt1Gx0Ygr eDgw== MIME-Version: 1.0 X-Received: by 10.14.177.1 with SMTP id c1mr55711470eem.8.1358740943238; Sun, 20 Jan 2013 20:02:23 -0800 (PST) Received: by 10.223.101.77 with HTTP; Sun, 20 Jan 2013 20:02:23 -0800 (PST) Date: Sun, 20 Jan 2013 20:02:23 -0800 Message-ID: Subject: Avoiding duplicate ACKs in TCP From: Vijay Singh To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jan 2013 04:02:30 -0000 All. I am working on an in-kernel application using socket upcalls. I see a lot of TCP DUP ACKs due the call to tcp_usr_rvcd(). However if I avoid this in the upcall using the MSG_SOCALLBCK flag to soreceive() the throughput of the test goes down due to missing window updates. I am wondering if there is a way to avoid this, perhaps by sending the window update based on data read by the application. -vijay From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 11:06:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65CC0C92 for ; Mon, 21 Jan 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 570BB727 for ; Mon, 21 Jan 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0LB6nIW054146 for ; Mon, 21 Jan 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0LB6mUX054144 for freebsd-net@FreeBSD.org; Mon, 21 Jan 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Jan 2013 11:06:48 GMT Message-Id: <201301211106.r0LB6mUX054144@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jan 2013 11:06:49 -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/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu 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 kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n 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 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 bin/150224 net ppp(8) does not reassign static IP after kill -KILL co 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/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/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load 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 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 kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi 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/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length 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 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 f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg 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/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f 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/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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 p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) 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/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/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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p 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 bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i 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/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i 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/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/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 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 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/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/132277 net [crypto] [ipsec] poor performance using cryptodevice f 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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm 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/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f 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 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 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 p kern/127360 net [socket] TOE socket options missing from sosetopt() 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection 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/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 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/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/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 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 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 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 o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands 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/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks 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/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] 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/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 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 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 kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i 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/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 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/68889 net [panic] m_copym, length > size of mbuf chain 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 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o 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/31940 net ip queue length too short for >500kpps 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 f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 440 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 16:53:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2D61F41 for ; Mon, 21 Jan 2013 16:53:55 +0000 (UTC) (envelope-from krichy@cflinux.hu) Received: from pi.nmdps.net (pi.nmdps.net [IPv6:2a01:be00:10:201:0:80:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id AA664EC9 for ; Mon, 21 Jan 2013 16:53:54 +0000 (UTC) Received: from [84.224.77.205] (netacc-gpn-4-77-205.pool.telenor.hu [84.224.77.205]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id 80F1A30F for ; Mon, 21 Jan 2013 17:53:50 +0100 (CET) To: freebsd-net@freebsd.org From: "=?utf-8?B?a3JpY2h5QGNmbGludXguaHU=?=" Subject: =?utf-8?B?VG92w6FiYsOtdMOhczogW0lwc2VjLXRvb2xzLXVzZXJzXSBmcmVlYnNkICYgbGludXgg?= =?utf-8?B?c2V0dXAgcXVlc3Rpb24=?= Date: Mon, 21 Jan 2013 17:53:49 +0100 MIME-Version: 1.0 Message-Id: <20130121165355.E2D61F41@hub.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jan 2013 16:53:55 -0000 CgpLw7xsZHZlIGF6IMOpbiBIVEMtbXLFkWwKCi0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t CmtlemTDqXM6ICJSaWNoYXJkIEtvamVkemluc3preSIgPGtyaWNoeUBjZmxpbnV4Lmh1PgpCZWZl amV6w6lzOiA8aXBzZWMtdG9vbHMtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0PgpUw6FyZ3k6 IFtJcHNlYy10b29scy11c2Vyc10gZnJlZWJzZCAmIGxpbnV4IHNldHVwIHF1ZXN0aW9uCkTDoXR1 bTogSCwgamFuLiAyMSwgMjAxMyAxNzowOAoKCkRlYXIgdXNlcnMsCgpJJ3ZlIGEgd29ya2luZyB0 dW5uZWwgc2V0dXAgYmV0d2VlbiB0d28gbGludXggaG9zdHMuCgpPbmUgZW5kIChBKSBoYXMgYSBm aXggYWRkcmVzcywgd2hpbGUgdGhlIG90aGVyIChCKSBoYXMgYSBkeW5hbWljIG9uZS4gCkEgaXMg bXkgc2VydmVyLCBCIGlzIG15IGhvbWUgcm91dGVyLiBCZWhpbmQgQiwgSSd2ZSBhIHByaXZhdGUg bmV0d29yay4gCldoYXQgSSd2ZSBzZXR1cCBpcyB0aGF0IG15IHByaXZhdGUgbmV0d29yayByZWFj aGVzIEEgdGhyb3VnaCBhbiBJUFNFQyAKdHVubmVsLgoKVGhlIGRpYWdyYW06CgpBIC0geyBJTlRF Uk5FVCB9IC0gQiAtIHsgbG9jYWwgbmV0d29yayB9CgpTbywgaW4gbXkgaG9tZSByb3V0ZXIsIHdo ZW4gaXQgYWNxdWlyZXMgYW4gSVAgYWRkcmVzcywgc3VjaCBzY3JpcHQgcnVucyAKKEEgaXMgdGhl IHNlcnZlcidzIGFkZHJlc3MsIEIgaXMgdGhlIGR5bmFtaWMgYWRkcmVzcyk6CgojIGVjaG8gInNw ZGFkZCAxMC4wLjAuMC8yNCBBIGFueSAtUCBvdXQgaXBzZWMgZXNwL3R1bm5lbC9CLUEvcmVxdWly ZTsiIHwgCnNldGtleSAtYwojIGVjaG8gInNwZGFkZCBBIDEwLjAuMC4wLzI0IGFueSAtUCBpbiBp cHNlYyBlc3AvdHVubmVsL0EtQi9yZXF1aXJlOyIgfCAKc2V0a2V5IC1jCgpNeSByYWNvb24gY29u ZmlnIGhhcyBvbmx5IGFuIGFub255bW91cyByZW1vdGUgc2VjdGlvbi4gVGhlIHNlcnZlciBoYXMg b25lIAphbHNvLCBidXQgaXQgaGFzIGdlbmVyYXRlX3BvbGljeSBzZXQgdG8gb24uIFRoZXJlZm9y ZSwgd2hlbiBhIHBhY2tldCAKaW5pdGlhdGVzIHRoZSB0dW5uZWwsIHRoZSBzZXJ2ZXIgc2V0cyB1 cCBjb3JyZWN0IHR1bm5lbHMvcG9saWNpZXMsIGFuZCAKZXZlcnl0aGluZyB3b3JrcyBmaW5lLgoK Tm93LCBJJ3ZlIGRlY2lkZWQgdG8gc3dpdGMgdG8gZnJlZWJzZCBvbiBzZXJ2ZXIgc2lkZSwgYW5k IHRoZSBzYW1lIApjb25maWd1cmF0aW9uIG9uIHRoZSBzZXJ2ZXIgc2ltcGx5IGRvZXMgbm90IHdv cmsuIEl0IGluc3RhbGxzIHRoZSAKcG9saWNpZXMsIGFuZCB0aGUgdHVubmVscywgYnV0IGl0IHNl ZW1zLCB0aGF0IHdoZW4gYSByZXBseSBwYWNrZXQgaXMgCmxlYXZpbmcgdGhlIHNlcnZlciwgaXQg dHJpZXMgdG8gaW5pdGlhdGUgYSBuZXcgdHVubmVsLiBJZiBJJ3ZlICJwYXNzaXZlIApvbiIgb24g bXkgc2VydmVyJ3MgcmVtb3RlIHNlY3Rpb24sIHRoZW4gSSd2ZSB0aGUgZm9sbG93aW5nIGVycm9y OgoKSmFuIDIxIDE2OjA2OjExIHBpIHJhY29vbjogRVJST1I6IG5vIGNvbmZpZ3VyYXRpb24gZm91 bmQgZm9yIEIuCkphbiAyMSAxNjowNjoxMSBwaSByYWNvb246IEVSUk9SOiBmYWlsZWQgdG8gYmVn aW4gaXBzZWMgc2EgbmVnb3RpY2F0aW9uLgoKSWYgSSBkaXNhYmxlIHBhc3NpdmUgbW9kZSwgdGhl biByYWNvb24gdHJpZXMgdG8gZXN0YWJsaXNoIGFub3RoZXIgdHVubmVsLCAKYnV0IGZvciBzb21l IHJlYXNvbiBpdCBkb2VzIG5vdCBzdWNjZWVkIGFsc28uIEJ1dCBJIHRoaW5rLCBhcyBpbiBsaW51 eCAKaXQgc2hvdWxkIHdvcmsgd2l0aCBwYXNzaXZlIG9uLgoKRnJlZUJTRCBpcyA5LjEtUkVMRUFT RSwgdGhlIGxpbnV4IHNpZGUgaXMgYSBsaW51eCAzLjUuNC4KCnJhY29vbiBvbiBsaW51eCBpczoK IyByYWNvb24gLVYKQCgjKWlwc2VjLXRvb2xzIDAuOC4wIChodHRwOi8vaXBzZWMtdG9vbHMuc291 cmNlZm9yZ2UubmV0KQoKQ29tcGlsZWQgd2l0aDoKLSBPcGVuU1NMIDEuMC4wZSA2IFNlcCAyMDEx IChodHRwOi8vd3d3Lm9wZW5zc2wub3JnLykKLSBEZWFkIFBlZXIgRGV0ZWN0aW9uCi0gSUtFIGZy YWdtZW50YXRpb24KLSBOQVQgVHJhdmVyc2FsCi0gTW9ub3RvbmljIGNsb2NrCgoKcmFjb29uIG9u IGZyZWVic2QgaXM6CiMgcmFjb29uIC1WCkAoIylpcHNlYy10b29scyAwLjguMCAoaHR0cDovL2lw c2VjLXRvb2xzLnNvdXJjZWZvcmdlLm5ldCkKCkNvbXBpbGVkIHdpdGg6Ci0gT3BlblNTTCAwLjku OHggMTAgTWF5IDIwMTIgKGh0dHA6Ly93d3cub3BlbnNzbC5vcmcvKQotIERlYWQgUGVlciBEZXRl Y3Rpb24KLSBJS0UgZnJhZ21lbnRhdGlvbgotIEh5YnJpZCBhdXRoZW50aWNhdGlvbgotIE1vbm90 b25pYyBjbG9jawoKClVuZm9ydHVuYXRlbHkgSSd2ZSBubyBpZGVhLgoKQmVmb3JlIHRoZSBmaXJz dCBwYWNrZXQsIG9uIHRoZSBzZXJ2ZXI6CiMgc2V0a2V5IC1ECk5vIFNBRCBlbnRyaWVzLgoKQWZ0 ZXIgYW4gaWNtcCBwYWNrZXQgc2VudCBmcm9tIG15IHByaXZhdGUgbmV0d29yayB0byBBOgojIHNl dGtleSAtRApBIEIKIAllc3AgbW9kZT10dW5uZWwgc3BpPTc2ODU5OTk4KDB4MDQ5NGNhNWUpIHJl cWlkPTAoMHgwMDAwMDAwMCkKIAlFOiByaWpuZGFlbC1jYmMgIDFjODBiODBkIGIwMDZlM2EzIDc3 MmMyYTliIDVjNDc1MjEzCiAJQTogaG1hYy1tZDUgIGQ0M2ZmMjljIDAzNGM4OTZhIGZiMmU3ZDFj IDk1ZjczZmY1CiAJc2VxPTB4MDAwMDAwMDAgcmVwbGF5PTQgZmxhZ3M9MHgwMDAwMDAwMCBzdGF0 ZT1tYXR1cmUKIAljcmVhdGVkOiBKYW4gMjEgMTc6MDM6MzkgMjAxMwljdXJyZW50OiBKYW4gMjEg MTc6MDU6NTQgMjAxMwogCWRpZmY6IDEzNShzKQloYXJkOiAxNDQwMChzKQlzb2Z0OiAxMTUyMChz KQogCWxhc3Q6ICAgICAgICAgICAgICAgICAgICAgCWhhcmQ6IDAocykJc29mdDogMChzKQogCWN1 cnJlbnQ6IDAoYnl0ZXMpCWhhcmQ6IDAoYnl0ZXMpCXNvZnQ6IDAoYnl0ZXMpCiAJYWxsb2NhdGVk OiAwCWhhcmQ6IDAJc29mdDogMAogCXNhZGJfc2VxPTEgcGlkPTkzMDkxIHJlZmNudD0xCkIgQQog CWVzcCBtb2RlPXR1bm5lbCBzcGk9MTQ0NzkwMDAwKDB4MDhhMTUxZjApIHJlcWlkPTAoMHgwMDAw MDAwMCkKIAlFOiByaWpuZGFlbC1jYmMgIDhiZDU5YzI5IDk4MDBkMTBmIDhmOWQ3ZTg0IGE3MjBh YTljCiAJQTogaG1hYy1tZDUgIDE4ODA3MGUyIGEzMjIwNzcyIDc4ZWZjYjA2IDM0NTdkYjYyCiAJ c2VxPTB4MDAwMDAwMzcgcmVwbGF5PTQgZmxhZ3M9MHgwMDAwMDAwMCBzdGF0ZT1tYXR1cmUKIAlj cmVhdGVkOiBKYW4gMjEgMTc6MDM6MzkgMjAxMwljdXJyZW50OiBKYW4gMjEgMTc6MDU6NTQgMjAx MwogCWRpZmY6IDEzNShzKQloYXJkOiAxNDQwMChzKQlzb2Z0OiAxMTUyMChzKQogCWxhc3Q6IEph biAyMSAxNzowNDo1MCAyMDEzCWhhcmQ6IDAocykJc29mdDogMChzKQogCWN1cnJlbnQ6IDU3MjAo Ynl0ZXMpCWhhcmQ6IDAoYnl0ZXMpCXNvZnQ6IDAoYnl0ZXMpCiAJYWxsb2NhdGVkOiA1NQloYXJk OiAwCXNvZnQ6IDAKIAlzYWRiX3NlcT0wIHBpZD05MzA5MSByZWZjbnQ9MQojIHNldGtleSAtRFAK MTAuMC4wLjAvMjRbYW55XSBBW2FueV0gYW55CiAJaW4gaXBzZWMKIAllc3AvdHVubmVsL0ItQS9y ZXF1aXJlCiAJY3JlYXRlZDogSmFuIDIxIDE3OjAzOjM5IDIwMTMgIGxhc3R1c2VkOiBKYW4gMjEg MTc6MDM6MzkgMjAxMwogCWxpZmV0aW1lOiAxNDQwMChzKSB2YWxpZHRpbWU6IDAocykKIAlzcGlk PTI1IHNlcT0xIHBpZD01MjMyCiAJcmVmY250PTEKQVthbnldIDEwLjAuMC4wLzI0W2FueV0gYW55 CiAJb3V0IGlwc2VjCiAJZXNwL3R1bm5lbC9BLUIvcmVxdWlyZQogCWNyZWF0ZWQ6IEphbiAyMSAx NzowMzozOSAyMDEzICBsYXN0dXNlZDogSmFuIDIxIDE3OjA0OjUwIDIwMTMKIAlsaWZldGltZTog MTQ0MDAocykgdmFsaWR0aW1lOiAwKHMpCiAJc3BpZD0yNiBzZXE9MCBwaWQ9NTIzMgogCXJlZmNu dD0xCgpFdmVyeXRoaW5nIHNlZW1zIGZpbmUsIGFzIHdlbGwgaXQgaXMgaW4gbGludXgsIGhvd2V3 ZXIsIHRoZSBhdHRhY2hlZCBsb2cgCnNob3dzIHRoYXQgdGhlIGtlcm5lbCBvciByYWNvb24gZG9l cyBub3QgdHJ5IHRvIHVzZSB0aGUgbmV3IHR1bm5lbCwgCmluc3RlYWQgaXQgd2FudHMgYW5vdGhl ciBvbmUuCgpJcyBpdCBhIGJ1ZyBpbiBmcmVlYnNkLCBvciBhIGZlYXR1cmUgaW4gbGludXg/IERv IHNvbWVib2R5IGhhdmUgZXhwZXJpZW5jZSAKd2l0aCBzdWNoIGEgc2V0dXA/CgpUaGFua3MgaW4g YWR2YW5jZSwKS29qZWR6aW5zemt5IFJpY2hhcmQ= From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 19:30:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59F3CB5A for ; Mon, 21 Jan 2013 19:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3258A910 for ; Mon, 21 Jan 2013 19:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0LJU1aG057382 for ; Mon, 21 Jan 2013 19:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0LJU1jl057381; Mon, 21 Jan 2013 19:30:01 GMT (envelope-from gnats) Date: Mon, 21 Jan 2013 19:30:01 GMT Message-Id: <201301211930.r0LJU1jl057381@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: George Neville-Neil Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: George Neville-Neil List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 19:30:01 -0000 The following reply was made to PR kern/172113; it has been noted by GNATS. From: George Neville-Neil To: John Baldwin Cc: bug-followup@FreeBSD.org, egrosbein@rdtc.ru, jfv@FreeBSD.org Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Date: Mon, 21 Jan 2013 14:25:00 -0500 On Jan 19, 2013, at 23:26 , John Baldwin wrote: > I was able to finally reproduce this panic today. It seems to require > a server configured for PXE but that receives no DHCP reply (and > possibly with the requisite SuperMicro X8 board). I was able to > prevent the panic with a subset of the referenced patch by only adding > the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of > igb_msix_que(). The rest of the patch was unnecessary. I also added > some debugging to print out the ICR, EICR, IMS, and EIMS registers in > this case. It does look like the hardware is sending an interrupt = that > is not enabled in the interrupt mask (specifically LSC). In fact, the > 82576 datasheet specifically mentions masking LSC until initialization > is complete to avoid spurious interrupts during boot and AFAICT igb(4) > does this since e1000_reset_hw() clears the interrupt mask via writes > to IMC and doesn't re-enable interrupts until igb_init_locked() is > invoked via 'ifconfig up'. Here is my debug output: >=20 > SMP: AP CPU #6 Launched! > SMP: AP CPU #4 Launched! > stray irq0 > igb0: interrupt on que 0: icr 0x1000004 eicr 0 > ims 0 eims 0x80000000 >=20 > Hmmm. Nothing clears EIMS. After some more debugging, I determined > that e1000_reset_hw() always turns this bit in EIMS on, even if it is > off before e1000_reset_hw() is called(!). I added explicit calls to > igb_disable_intr() to clear EIMS after each call to e1000_reset_hw(). > This removes the 'stray irq0', but I still get a spurious interrupt > during boot (albeit with eims 0). I can use the IFF_DRV_RUNNING hack > for now, but I think the real fix is something else. >=20 I think Jack will have to chime in on this one. Do you think it's all = SM X8 boards or just the one we happen to have? I wonder if Jack or Jeffrey (the = testing guy he works with) have access to the right board. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 19:57:09 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C402CF71; Mon, 21 Jan 2013 19:57:09 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9B4A16; Mon, 21 Jan 2013 19:57:09 +0000 (UTC) Received: from outgoing.leidinger.net (p57A388D2.dip.t-dialin.net [87.163.136.210]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B834784409A; Mon, 21 Jan 2013 20:56:59 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id 1C8AC4938; Mon, 21 Jan 2013 20:56:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1358798217; bh=P7Cy1PCJ8dnxT6seLRGcNRbr3qRSIvBs260ZjOyC4M4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZFVgpygVM2bdWsezMXFlQrEkJMIwTfSOynipMY7IWQcb717w7I1qqxWGIr2czMNew yb85vflkWT9q+9V0YyaFQPjRGk93+lA6Qj8hg/iOBBFegsBSi8i5Rsz+nI8cMdMPUs h5fUqmRe6XvQfbGeSwa3nZBgfJvqNzFH4FlT2Kamy3bjn54AzUMnBY57OFbOZ5vweN S/s6yz+7l1GausNgj8mtcaqpAc7Mo6P4k0yyV+Q1E5uSId0dDZpKoZHsXof20amBNb yisaFMPMsqp3y+hwR7/1YJGfwRNz0ov6nH7ANA9UakfXwetuHOfguBHW5m6HvyvqpN wNCY0x0OelWvw== Date: Mon, 21 Jan 2013 20:55:22 +0100 From: Alexander Leidinger To: John Baldwin Subject: Re: [PATCH] Properly handle Linux TCP socket options Message-ID: <20130121205522.00006f38@unknown> In-Reply-To: <201301191126.13257.jhb@freebsd.org> References: <201301191126.13257.jhb@freebsd.org> X-Mailer: Claws Mail 3.8.0cvs30 (GTK+ 2.24.10; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B834784409A.A260F X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.121, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.23, DKIM_SIGNED 0.10, T_DKIM_INVALID 0.01, T_FRT_STOCK2 0.01, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1359403020.53432@QDO5VQ/jkXV9JDceHFgSgQ X-EBL-Spam-Status: No Cc: emulation@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jan 2013 19:57:09 -0000 On Sat, 19 Jan 2013 11:26:13 -0500 John Baldwin wrote: > The current setsockopt() wrapper for the Linux ABI claims that Linux > and FreeBSD use the same values for TCP socket options. This is true > for TCP_NODELAY and TCP_MAXSEG but not for any other options. This > patch adds a mapping routine for TCP options similar to that used for > other socket option levels. I believe this mapping to be correct in > terms of which FreeBSD options have the same semantics as Linux > options based on comparing code in the two kernels, but I'm not 100% > certain about TCP_MD5SIG since the Linux code that it maps to is not > as clear (it calls some function pointer and it is not clear if it is > accepting a simple boolean value similar to FreeBSD's). What about a message for unknown options? > Also, almost all of the socket stuff in the linux.h headers appears > to be identical and at least some of it are in MI headers in Linux > (such as the TCP options). It seems to me that a lot of that should > move into linux_socket.h instead. Yes, at least for the newly added ones (I haven't looked at the other ones). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 20:30:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A41B09C0 for ; Mon, 21 Jan 2013 20:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 86689B5E for ; Mon, 21 Jan 2013 20:30:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0LKU3k3068338 for ; Mon, 21 Jan 2013 20:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0LKU3wi068337; Mon, 21 Jan 2013 20:30:03 GMT (envelope-from gnats) Date: Mon, 21 Jan 2013 20:30:03 GMT Message-Id: <201301212030.r0LKU3wi068337@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Jack Vogel Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jan 2013 20:30:03 -0000 The following reply was made to PR kern/172113; it has been noted by GNATS. From: Jack Vogel To: George Neville-Neil Cc: John Baldwin , bug-followup@freebsd.org, egrosbein@rdtc.ru, jfv@freebsd.org Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Date: Mon, 21 Jan 2013 12:28:40 -0800 --f46d04339ce484676004d3d24e43 Content-Type: text/plain; charset=ISO-8859-1 Well, do you have a more complete designation of the motherboard? We can look into it, although if the one check stops the problem it may be a low priority. Jack On Mon, Jan 21, 2013 at 11:25 AM, George Neville-Neil wrote: > > On Jan 19, 2013, at 23:26 , John Baldwin wrote: > > > I was able to finally reproduce this panic today. It seems to require > > a server configured for PXE but that receives no DHCP reply (and > > possibly with the requisite SuperMicro X8 board). I was able to > > prevent the panic with a subset of the referenced patch by only adding > > the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of > > igb_msix_que(). The rest of the patch was unnecessary. I also added > > some debugging to print out the ICR, EICR, IMS, and EIMS registers in > > this case. It does look like the hardware is sending an interrupt that > > is not enabled in the interrupt mask (specifically LSC). In fact, the > > 82576 datasheet specifically mentions masking LSC until initialization > > is complete to avoid spurious interrupts during boot and AFAICT igb(4) > > does this since e1000_reset_hw() clears the interrupt mask via writes > > to IMC and doesn't re-enable interrupts until igb_init_locked() is > > invoked via 'ifconfig up'. Here is my debug output: > > > > SMP: AP CPU #6 Launched! > > SMP: AP CPU #4 Launched! > > stray irq0 > > igb0: interrupt on que 0: icr 0x1000004 eicr 0 > > ims 0 eims 0x80000000 > > > > Hmmm. Nothing clears EIMS. After some more debugging, I determined > > that e1000_reset_hw() always turns this bit in EIMS on, even if it is > > off before e1000_reset_hw() is called(!). I added explicit calls to > > igb_disable_intr() to clear EIMS after each call to e1000_reset_hw(). > > This removes the 'stray irq0', but I still get a spurious interrupt > > during boot (albeit with eims 0). I can use the IFF_DRV_RUNNING hack > > for now, but I think the real fix is something else. > > > > I think Jack will have to chime in on this one. Do you think it's all SM > X8 boards > or just the one we happen to have? I wonder if Jack or Jeffrey (the > testing guy he works > with) have access to the right board. > > Best, > George > > > --f46d04339ce484676004d3d24e43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, do you have a more complete designation of the motherboard? We canlook into it, although if the one check stops the problem it may be a low = priority.

Jack


On Mon, Jan 21,= 2013 at 11:25 AM, George Neville-Neil <gnn@freebsd.org> wrote= :

On Jan 19, 2013, at 23:26 , John Baldwin <jhb@FreeBSD.org> wrote:

> I was able to finally reproduce this panic today. =A0It seems to requi= re
> a server configured for PXE but that receives no DHCP reply (and
> possibly with the requisite SuperMicro X8 board). =A0I was able to
> prevent the panic with a subset of the referenced patch by only adding=
> the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of=
> igb_msix_que(). =A0The rest of the patch was unnecessary. =A0I also ad= ded
> some debugging to print out the ICR, EICR, IMS, and EIMS registers in<= br> > this case. =A0It does look like the hardware is sending an interrupt t= hat
> is not enabled in the interrupt mask (specifically LSC). =A0In fact, t= he
> 82576 datasheet specifically mentions masking LSC until initialization=
> is complete to avoid spurious interrupts during boot and AFAICT igb(4)=
> does this since e1000_reset_hw() clears the interrupt mask via writes<= br> > to IMC and doesn't re-enable interrupts until igb_init_locked() is=
> invoked via 'ifconfig up'. =A0Here is my debug output:
>
> SMP: AP CPU #6 Launched!
> SMP: AP CPU #4 Launched!
> stray irq0
> igb0: interrupt on que 0: icr 0x1000004 eicr 0
> =A0 =A0 ims 0 eims 0x80000000
>
> Hmmm. =A0 Nothing clears EIMS. =A0After some more debugging, I determi= ned
> that e1000_reset_hw() always turns this bit in EIMS on, even if it is<= br> > off before e1000_reset_hw() is called(!). =A0I added explicit calls to=
> igb_disable_intr() to clear EIMS after each call to e1000_reset_hw().<= br> > This removes the 'stray irq0', but I still get a spurious inte= rrupt
> during boot (albeit with eims 0). =A0I can use the IFF_DRV_RUNNING hac= k
> for now, but I think the real fix is something else.
>

I think Jack will have to chime in on this one. =A0Do you think it's al= l SM X8 boards
or just the one we happen to have? =A0I wonder if Jack or Jeffrey (the test= ing guy he works
with) have access to the right board.

Best,
George



--f46d04339ce484676004d3d24e43-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 05:40:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 067CD263 for ; Tue, 22 Jan 2013 05:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EADB83EB for ; Tue, 22 Jan 2013 05:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0M5e1nJ076983 for ; Tue, 22 Jan 2013 05:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0M5e1qs076982; Tue, 22 Jan 2013 05:40:01 GMT (envelope-from gnats) Date: Tue, 22 Jan 2013 05:40:01 GMT Message-Id: <201301220540.r0M5e1qs076982@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Eugene Grosbein Subject: Re: kern/162558: [dummynet] [panic] seldom dummynet panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Eugene Grosbein List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 05:40:02 -0000 The following reply was made to PR kern/162558; it has been noted by GNATS. From: Eugene Grosbein To: bug-followup@FreeBSD.ORG Cc: Luigi Rizzo Subject: Re: kern/162558: [dummynet] [panic] seldom dummynet panics Date: Tue, 22 Jan 2013 12:33:51 +0700 Hi! The same problem had repeated 20 January with FreeBSD 8.3-STABLE built from late October 2012 sources. This time I've got nice crashdump with backtrace. That's with net.isr.bindthreads=1, net.isr.direct=1 and net.isr.direct_force=1. Full crashinfo, kernel.debug and crashdump are available here: http://www.grosbein.net/freebsd/crash/20130120/core.0.txt http://www.grosbein.net/freebsd/crash/20130120/kernel.debug.xz (8.4M) http://www.grosbein.net/freebsd/crash/20130120/vmcore.0.xz From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 08:57:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 962F9E5C; Tue, 22 Jan 2013 08:57:32 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5E633FF1; Tue, 22 Jan 2013 08:57:32 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 3CC5E7E824; Tue, 22 Jan 2013 19:57:24 +1100 (EST) Message-ID: <50FE5473.7000807@freebsd.org> Date: Tue, 22 Jan 2013 19:57:23 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks References: <201301141550.13577.jhb@freebsd.org> <50F5181D.6020508@freebsd.org> <201301151416.07231.jhb@freebsd.org> In-Reply-To: <201301151416.07231.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 08:57:32 -0000 On 01/16/13 06:16, John Baldwin wrote: > On Tuesday, January 15, 2013 3:49:33 am Lawrence Stewart wrote: >> On 01/15/13 07:50, John Baldwin wrote: >>> The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are >>> currently defined as hex values that are individual bits. However, socket >>> options are never masked together, they are used as a simple enumeration of >>> discrete values. Using a bitmask forces us to run out of bits and makes it >>> harder for vendors to try to use a high range of values for local custom >>> options (hoping that they never conflict with a new option value added in >>> stock FreeBSD). >> >> Yup. Should we be explicitly #defining the boundary between "bits >> reserved for FreeBSD" and "bits for private vendor use"? > > Oh, we could if you wanted. I'm using 0x1000 locally for both TCP and UDP, > but those are completely arbitrary values. Saner ones might be 0x8000000 if > we want to do that explicitly. We could perhaps just say that is true for all > socket option levels (that is, just define one SO_VENDOR constant or some such > but say it applies to all levels)? A single SO_VENDOR applied to all levels sounds good to me. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 10:53:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75621627 for ; Tue, 22 Jan 2013 10:53:21 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id E2DC38FD for ; Tue, 22 Jan 2013 10:53:20 +0000 (UTC) Received: from ken (ken.zen.inc [192.168.1.4]) by smtp.zeninc.net (smtpd) with ESMTP id 778FF27988B for ; Tue, 22 Jan 2013 11:44:20 +0100 (CET) Received: by ken (Postfix, from userid 1000) id 4EAF7404D; Tue, 22 Jan 2013 11:44:20 +0100 (CET) Date: Tue, 22 Jan 2013 11:44:20 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question Message-ID: <20130122104420.GA3111@zeninc.net> References: <20130121165355.E2D61F41@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130121165355.E2D61F41@hub.freebsd.org> User-Agent: All mail clients suck. This one just sucks less. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 10:53:21 -0000 Hi. On Mon, Jan 21, 2013 at 05:53:49PM +0100, krichy@cflinux.hu wrote: > Dear users, > > I've a working tunnel setup between two linux hosts. > > One end (A) has a fix address, while the other (B) has a dynamic one. > A is my server, B is my home router. Behind B, I've a private network. > What I've setup is that my private network reaches A through an IPSEC > tunnel. [....] > Now, I've decided to switc to freebsd on server side, and the same > configuration on the server simply does not work. It installs the > policies, and the tunnels, but it seems, that when a reply packet is > leaving the server, it tries to initiate a new tunnel. If I've "passive > on" on my server's remote section, then I've the following error: > > Jan 21 16:06:11 pi racoon: ERROR: no configuration found for B. > Jan 21 16:06:11 pi racoon: ERROR: failed to begin ipsec sa negotication. > > If I disable passive mode, then racoon tries to establish another tunnel, > but for some reason it does not succeed also. But I think, as in linux > it should work with passive on. > > FreeBSD is 9.1-RELEASE, the linux side is a linux 3.5.4. > > racoon on linux is: > # racoon -V > @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) > > Compiled with: > - OpenSSL 1.0.0e 6 Sep 2011 (http://www.openssl.org/) > - Dead Peer Detection > - IKE fragmentation > - NAT Traversal > - Monotonic clock > > > racoon on freebsd is: > # racoon -V > @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) > > Compiled with: > - OpenSSL 0.9.8x 10 May 2012 (http://www.openssl.org/) > - Dead Peer Detection > - IKE fragmentation > - Hybrid authentication > - Monotonic clock You have NAT-T compiled/enabled on Linux side, but not on FreeBSD side (probably because it is not activated as a kernel option). If you have "something that does NAT" on the wire between A and B, it is probably the origin of your problem. However, as it seems that there is only "Internet" between A and B, I'll suppose that the issue is somewhere else... > Unfortunately I've no idea. > > Before the first packet, on the server: > # setkey -D > No SAD entries. > > After an icmp packet sent from my private network to A: > # setkey -D > A B > esp mode=tunnel spi=76859998(0x0494ca5e) reqid=0(0x00000000) > E: rijndael-cbc 1c80b80d b006e3a3 772c2a9b 5c475213 > A: hmac-md5 d43ff29c 034c896a fb2e7d1c 95f73ff5 > seq=0x00000000 replay=4 flags=0x00000000 state=mature > created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 > diff: 135(s) hard: 14400(s) soft: 11520(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=1 pid=93091 refcnt=1 > B A > esp mode=tunnel spi=144790000(0x08a151f0) reqid=0(0x00000000) > E: rijndael-cbc 8bd59c29 9800d10f 8f9d7e84 a720aa9c > A: hmac-md5 188070e2 a3220772 78efcb06 3457db62 > seq=0x00000037 replay=4 flags=0x00000000 state=mature > created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 > diff: 135(s) hard: 14400(s) soft: 11520(s) > last: Jan 21 17:04:50 2013 hard: 0(s) soft: 0(s) > current: 5720(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 55 hard: 0 soft: 0 > sadb_seq=0 pid=93091 refcnt=1 > # setkey -DP > 10.0.0.0/24[any] A[any] any > in ipsec > esp/tunnel/B-A/require > created: Jan 21 17:03:39 2013 lastused: Jan 21 17:03:39 2013 > lifetime: 14400(s) validtime: 0(s) > spid=25 seq=1 pid=5232 > refcnt=1 > A[any] 10.0.0.0/24[any] any > out ipsec > esp/tunnel/A-B/require > created: Jan 21 17:03:39 2013 lastused: Jan 21 17:04:50 2013 > lifetime: 14400(s) validtime: 0(s) > spid=26 seq=0 pid=5232 > refcnt=1 > > Everything seems fine, as well it is in linux, howewer, the attached log > shows that the kernel or racoon does not try to use the new tunnel, > instead it wants another one. Looks good..... Could you run racoon (on server's side) in debug mode (-dd) and send the few lines that talk about trying to negociate a new tunnel ? (Be careful, such racoon's debug contains sensitive informations) What I'd like to have is the profil of the tunnel that kernel asks for negociation. Also, can you confirm that your setkey -DP output is the whole full output ? > Is it a bug in freebsd, or a feature in linux? Do somebody have experience > with such a setup? Afaik, none of them, I use such setup and it works.... The only difference in my configuration is that I have a network behind both peers, but it should also work in your case. Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 12:53:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 79BA1C9E; Tue, 22 Jan 2013 12:53:07 +0000 (UTC) (envelope-from krichy@cflinux.hu) Received: from pi.nmdps.net (pi.nmdps.net [IPv6:2a01:be00:10:201:0:80:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC1A144; Tue, 22 Jan 2013 12:53:06 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id 7396E2C9; Tue, 22 Jan 2013 13:53:05 +0100 (CET) Date: Tue, 22 Jan 2013 13:53:05 +0100 (CET) From: Richard Kojedzinszky X-X-Sender: krichy@pi.nmdps.net To: VANHULLEBUS Yvan Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question In-Reply-To: <20130122104420.GA3111@zeninc.net> Message-ID: References: <20130121165355.E2D61F41@hub.freebsd.org> <20130122104420.GA3111@zeninc.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2628712688-1682217377-1358859185=:48971" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 12:53:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2628712688-1682217377-1358859185=:48971 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Dear Yvan, I've recompiled racoon with NATT, but as you've said, only pure Internet is between A and B without NAT, and thus it did not solve my problem. I've attached racoon's output from # racoon -ddd -F on the freebsd's side. I can confirm, that setkey -D and -DP's output were full, so only the two entries existed for the SA's and policices. I've tried a simple road-warrior setup, with transport mode, thus only traffic between A and B was protected, but that worked. My server's racoon.conf is simple: -- path certificate "/usr/local/etc/racoon/certs"; remote anonymous { exchange_mode main,aggressive; # nat_traversal off; certificate_type x509 "A.crt "A.key"; ca_type x509 "ca.crt"; my_identifier asn1dn; peers_identifier asn1dn; proposal_check strict ; lifetime time 24 hour; proposal { encryption_algorithm aes256; hash_algorithm sha1; authentication_method rsasig; dh_group 2; } generate_policy on ; passive on ; dpd_delay 60; } sainfo anonymous { lifetime time 4 hour; encryption_algorithm aes128 ; authentication_algorithm hmac_md5 ; compression_algorithm deflate; } log debug ; -- And the client's is the same except the generate_policy and passive statements. Thanks in advance, Kojedzinszky Richard On Tue, 22 Jan 2013, VANHULLEBUS Yvan wrote: > Hi. > > > On Mon, Jan 21, 2013 at 05:53:49PM +0100, krichy@cflinux.hu wrote: >> Dear users, >> >> I've a working tunnel setup between two linux hosts. >> >> One end (A) has a fix address, while the other (B) has a dynamic one. >> A is my server, B is my home router. Behind B, I've a private network. >> What I've setup is that my private network reaches A through an IPSEC >> tunnel. > [....] >> Now, I've decided to switc to freebsd on server side, and the same >> configuration on the server simply does not work. It installs the >> policies, and the tunnels, but it seems, that when a reply packet is >> leaving the server, it tries to initiate a new tunnel. If I've "passive >> on" on my server's remote section, then I've the following error: >> >> Jan 21 16:06:11 pi racoon: ERROR: no configuration found for B. >> Jan 21 16:06:11 pi racoon: ERROR: failed to begin ipsec sa negotication. >> >> If I disable passive mode, then racoon tries to establish another tunnel, >> but for some reason it does not succeed also. But I think, as in linux >> it should work with passive on. >> >> FreeBSD is 9.1-RELEASE, the linux side is a linux 3.5.4. >> >> racoon on linux is: >> # racoon -V >> @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) >> >> Compiled with: >> - OpenSSL 1.0.0e 6 Sep 2011 (http://www.openssl.org/) >> - Dead Peer Detection >> - IKE fragmentation >> - NAT Traversal >> - Monotonic clock >> >> >> racoon on freebsd is: >> # racoon -V >> @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) >> >> Compiled with: >> - OpenSSL 0.9.8x 10 May 2012 (http://www.openssl.org/) >> - Dead Peer Detection >> - IKE fragmentation >> - Hybrid authentication >> - Monotonic clock > > You have NAT-T compiled/enabled on Linux side, but not on FreeBSD side > (probably because it is not activated as a kernel option). > If you have "something that does NAT" on the wire between A and B, it > is probably the origin of your problem. > > However, as it seems that there is only "Internet" between A and B, > I'll suppose that the issue is somewhere else... > > >> Unfortunately I've no idea. >> >> Before the first packet, on the server: >> # setkey -D >> No SAD entries. >> >> After an icmp packet sent from my private network to A: >> # setkey -D >> A B >> esp mode=tunnel spi=76859998(0x0494ca5e) reqid=0(0x00000000) >> E: rijndael-cbc 1c80b80d b006e3a3 772c2a9b 5c475213 >> A: hmac-md5 d43ff29c 034c896a fb2e7d1c 95f73ff5 >> seq=0x00000000 replay=4 flags=0x00000000 state=mature >> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 >> diff: 135(s) hard: 14400(s) soft: 11520(s) >> last: hard: 0(s) soft: 0(s) >> current: 0(bytes) hard: 0(bytes) soft: 0(bytes) >> allocated: 0 hard: 0 soft: 0 >> sadb_seq=1 pid=93091 refcnt=1 >> B A >> esp mode=tunnel spi=144790000(0x08a151f0) reqid=0(0x00000000) >> E: rijndael-cbc 8bd59c29 9800d10f 8f9d7e84 a720aa9c >> A: hmac-md5 188070e2 a3220772 78efcb06 3457db62 >> seq=0x00000037 replay=4 flags=0x00000000 state=mature >> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 >> diff: 135(s) hard: 14400(s) soft: 11520(s) >> last: Jan 21 17:04:50 2013 hard: 0(s) soft: 0(s) >> current: 5720(bytes) hard: 0(bytes) soft: 0(bytes) >> allocated: 55 hard: 0 soft: 0 >> sadb_seq=0 pid=93091 refcnt=1 >> # setkey -DP >> 10.0.0.0/24[any] A[any] any >> in ipsec >> esp/tunnel/B-A/require >> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:03:39 2013 >> lifetime: 14400(s) validtime: 0(s) >> spid=25 seq=1 pid=5232 >> refcnt=1 >> A[any] 10.0.0.0/24[any] any >> out ipsec >> esp/tunnel/A-B/require >> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:04:50 2013 >> lifetime: 14400(s) validtime: 0(s) >> spid=26 seq=0 pid=5232 >> refcnt=1 >> >> Everything seems fine, as well it is in linux, howewer, the attached log >> shows that the kernel or racoon does not try to use the new tunnel, >> instead it wants another one. > > Looks good..... > > Could you run racoon (on server's side) in debug mode (-dd) and send > the few lines that talk about trying to negociate a new tunnel ? > (Be careful, such racoon's debug contains sensitive informations) > > What I'd like to have is the profil of the tunnel that kernel asks for > negociation. > > Also, can you confirm that your setkey -DP output is the whole full > output ? Yes, it was the full. > > >> Is it a bug in freebsd, or a feature in linux? Do somebody have experience >> with such a setup? > > Afaik, none of them, I use such setup and it works.... > The only difference in my configuration is that I have a network > behind both peers, but it should also work in your case. > > > Yvan. > _______________________________________________ > 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" > --2628712688-1682217377-1358859185=:48971 Content-Type: APPLICATION/octet-stream; name=racoon.log.xz Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=racoon.log.xz /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4VaIUUtdACMbykZnH1HQkF1KBKbt DweILXGBywRq20Zmg6WfzmCeJALszhBQY2mIcH7rJpZqVrSC7/g4JwzibUpQ cYaNVjPsUszFr/QuLxFVb5UN1V9I+KlpNwC4dizwYyrp3Ty0aKwiZnyQwrte X3Z5izrW2Hk0TZy+KPNosSVuUqPltIVIiRSIXIrVYjHs5MxrKF0QzORJ7uQD IzMHuD2ucMC9ueTOJJnjUxQLep8BoMwp21lPPLvdSH/T7fHDBkBLOVvkGHlx Xfjt4YZHh1FjZMzOUDk7+F0cbYc8W/kBvwj1610GbnfXK8TX3YJWNgFSL0rs 1j+eNdbc48g9BpW4mNiwIiH6k4eXiqEvlDDep9mcHU4YsvfD5f9N6nOqmUGk UVzd9Fn+1ED2t5jKiXc/hGYyG/hvWUL0fkwzi3/W6lx64pwRBCZQn76/Stwt 1E2NnA+Ie08ctsegDszPUafo7FJHm6bjpA3vyZoIglcCWgMqdbUcPiKKGMEi +epsTt6e2bRTueHJXRH3m8MDopVfyFMNgM7VDYOfkjd+uHudH36P5fWuxMkX CUeDMwsW2E6HZtIxVPS7VL0kFqks/MX6A5LD6cB7EE2XaUZ2PvQ00OuUZMd6 r/pcYGMFzYmNKyuqiYU2CtR1t/wiRlN8jzmdOBSG04wCkmQlMkc+svzkARbW 62vv6qdFxJBqO5E9hPlawN3M7z4SquSb7K1OLNQ9BiixRjPTgskUBWud+4AY aYjD39C05YoMo+3Cr8j0r0aQ/lT915XBnfUBjoaxNYuhDcgHHIA+7CNk3O1C rgRRwYV7P4IBV5aZQzLDaVNa5XM8UAelRi1xISzGdA+klvVqXO2beAA5ybDu kvRodKCk58dLtBbcuYHekU1VmdhXMHfbNeTn1vXmk3pvkzfVjUsKD7vL4cjT m3aT0gpqaQ/bKNGhEjJlflzEioTdhczvSWRZBVulNK5NnP1o+8YAe0HRP2P+ OgYwBIpHr2yYozcq6G9kyfmZDnAWk3MozeX06aNpzHwzx2DH0h2bZJ+yS0QJ wL6bMmlBNFUGZw5ZZyi2zZ+wQbmnOQ+E3AlcE0XSW2M39KeoB093e7O2YVIZ 5WsGvxM/j/vueY5iJ59mbRfMFqE7yxfqCeZwpXNWvvrrAKdcsZkJK8NOBGa+ mOXQYUQdUeTlm7egIv+LtQjyWWAtMUaJEUXpSOOTkCfhoYiS053Ci2XMYhm/ TfPlHX3Qgc9S1F6iZTDWbdr/U2jQbroBDanBLCuoxgNAhTqPYlq5SGXvxIje ztbvhii2ruX/+cKLg87OXlYRJNNf8dLrIIiQ5SEpo2bo/yPgc7DbbDxuEdZ8 EBnnWRJohzyh/HbSPlI03AWlYiYZ5+MQmod6SMFrc1qwTVUu5TMFACFEA8jY WwQCOgIBFaVo6B2nK0UoGQV9ZqpomuVSQtztPlgtPL+wcR6JQZL3Dt3ebOJs SdayjQVdVxxFe9FOd9khXRj3Buc+KAqR9EvKHCMtQkE3YnW1+wWJiPPDJMdI GfLpN5/vim+8JZwO+v/79DKsvyEbg5U6XVc+SBX/Rss6QAFZGR6rbx2mjOdL epM/srx/g0t7KYXC52hmfHNp8RucUo6Td8g9qPu17X//edG6V02T6Yl9I3Kv Cc9bvGbEc/0yirz71NJGkXrklBPn77MiyPqGWTC2ZECvTkoLuAMkOOum7CYN BxGCjRivBzE7mrXC610rK5KZdrNOqTUGYTciTpNXNrFufJPQSkk781hizs3s BaTK9qeEODDcDYe64UGBYWsjnGp2jgIPy+L98y1yPgJ21Jmm7rzFNLC2BogB f5c0zvYvrD+UXQE2Dh2fYhQz/ZWakg1TjHcpBkrixy62Rx/BnRSna19d+GIY Q1EHer709u2MQchO0UW9uhQAIwfNUcTCeXrKcn7KwFOM7C5UGeeasCqA4RVh xyhPCqQghbwWYYGr3WkGlJNLraKOn0l3pc1dxMKHcG+f1Cc1QSGIHWi1+EXE jKwDHhP7ACl8RmYlAtF7iKrfbgnLdeU3p+anMEezm4GkURagv7Q+ukgq7/oi 3u1uCZgRQKB4vIN5kkyEqYlMu5/OA14UxwhqEm5J/EfjugchYoVfs2ur8ZSN Nc4uLCggkVywd9TGEZ1aUo4VeWSSb1n0Kf4Z8RIqEFxH0BzWvGUvDB7xVmTW JFOMtM27qDX/fQIVRhOYKc2ykYg+xjpuichCO4Mx4+cCzjuzv+I8Fv9jfaTe Y/EmAFDfS0sRzQYsAitsyo6O2EFTBOe8XFhkgywEGTJhKrV6c64GqxzgTDy9 cIWhXkkuuunQwXLj8r6gKfkf1NsfKJRmiuTGndWtDM+sd5MC0ntPLnxpRf6C v160mTMSe8eB6Qdm4OG9wqT1SF8HwNzyw1KeO0men97wkGShKLZ1PcuyiDkW 3u8OfYmsDMLZWwLXHUXKkTTTudxa7jRG9uW3S7JmWDmhaOscHKd5iEZWmtwN QOwxEAvTQn7q75D7J4sibiK1T7m6fkx1d2OGUeEwAUWqLU7Sf2fzxBjXuTpo jdpqvnU0Q3gxzizxiAZyaDMazsBVQ2gaw/ISsG/Hws0ddk0VizktZiCNJ6r8 rSa7I93NWS39dktj1Ld/NvqBt6GnGzjRQbv+7zkRIrH10m51bk3fC3VPJtlI TY+kfyWHJa46I+CF4TQ/cKzHsCG5LjUhFadTh7GZ4SZzJmsqdw8cHfbTN1PX +wrf2wr2z3bRMF9ioZWMkO0AYeH2kgpDpc5hGk9Hn97cfklFbMz23PPO9Lec TImYj48uttcgFJdXyPb8z5OqfyX1fucfCoPpRzOOmtOhazloUhIv/e2647K1 6ajakpti0T7w9+mlGLGoLU4/scCnKhr2q7wj8jSwMO8fhILlF7OK+Gf72rS3 6pj9Yx7nHHxMj0ouP3NRVC7db/yH3ovoiPmvVdIadLnsoNoUgqxIRz03Xej8 N8EcBFGl+shp2iWF7l7yCazma1hi/CASQfvplGGGUUMOFVanFp9yMRZXtkSH GQ1hAcMy3ZaT04jJNjxspaAhha8xt5BnAgEKDQ+jbafPesPXS+vLXoGL55PS LsBe/6dJXBUY0YV+9uWLNOqIrdbhvXSuz+AwHoxulbDlazdj35wlSBvR8p5M TZq+fk17FM3XjCxVtYLSdzlIXfipTYw8N9xdazoxP0f7ZnkjxdUJfihwuREl HPLZf6AHz4gqWeJVPklvQOcXWKLo9j4S8RNUxE6L466hV19xG+DswWlRqnjg QN6nJPmzGjJPYRGgHOLyzw0uk56ktUPRHYCa1Yovz5M6TdQflhqHeZ9Pmpt2 euVf6U4L8LZoNWeNLH/YZakhadSGcRHB2rHKPJRmiLfg7bxkk+EJSRNrkr2k xTKFSQzywXVR7udlN+1uVSuGgOeYrF4/aTK3+kv3Hmy7Sh9Ks7g/Qs6hrsCJ Q1wGgS7h1pE/WKtw6DR2YU5K8t7js2bhx4GJGIgVV60FKo+H6ZgXmn9Lrk4u bS4Wx88Rip+HmStV/eyZsvojk5LO0Hocel9Igq9V2CXljUfdQimQbo6K3asu qX7Zr+dVSE88U0qfnQ6/fauoNuIGiGdre/29et64INP6eRsVqbW6aCx8ccv6 Uu+lS8EcTTHWCOa33WVnIoGrXrRkKS9wiKCpqY/tlStVXJez4l3GSbARaSAo jpGzK5+231krSouqUQ5blnVPr49VT9y0J32lswHPckea68ectPY2rQCqohFh d9KQrZd4zh5n3+cPyqvA1tDz0I7qfHeb688S/oLbMXFvabQJ/a7f4jKTljoZ R/2RRHRYsscgken9/mZCi7mgzSDnswOax1pBWsnfxARzODjA2OCx7sXKKlRT nH4tnJsRzcNqj057zqihL8dqtudY3Ss/Ei/EQFAIGryo6/2kGde6ub/e2jiJ nrk5NrMjh4TJFNfMnFqIaCslC3OmLFMi+i92BbJ74teLL5no4ZCPfbn9oBKR LQNCbvb/HP+ejfUrJEQD66UBCv5iG0hhLr8r9xfZmZuXVrCX+i5cMYovwLXS 48m9Zg+MJd5JljB0qufTfvw7kIbqqfyhO7MbZp69NzUgYKUEMRcNCusAirkg Ue2dA0Z5RyzPuvftsHZnGmyL1wRAAggXWnhspsYBpGlRggh0hbOPltQqB4jr UP5jeZG02wWluJE3jn/211Xpr88Fwpkveoo3kFY2n6ou7bxVZm4nqUUUI5Rz 8UgleplMAEbaO5hHDHASe7s9sMZ1nB8UTVTiEwMz4YUHMtz+x3Whgzu77e2l I2OKRsiXnOQY45viTKhGQ4a9rchiEU6LtreHgpfacy40eiv6PTWv0mUnUHST w5B6CRjCQh1sUi4DdRMc1f/PweT5yi5ApHs5Koe4s2iwyS6Nx2c/T/13Hiw/ GrjWM4dyAk517Hp52tNNkXE3PeQ23OeTPUcyIErc+BNm3Dw3u3Rb7wYgWZkp lJOFgDCncXpybwdNeZvg0jUKTSPvW/wSIAsEg3QcOVZPZMjkrdb91RXZvST4 S3uWWu/SsYJ9ZDx8Xow44UOlnzFdItRA98DIBGu6uc4BiT1E8PKUZpxXsszS sv7oyWYk+0fr1zxyECUYnwOxDIbiZA91EaiiPI/jsWnRXuX1+IPMYJCwoyew xo0epHOQcbFe7bbxkHAkadSruPb/wY7YDw8Ufbb+1K40GshFswHYCRYFqZOm OhVeiZa9+6ll+GEtkuxYG/OD2TUZ9LKB1LCsbG0Wd9x9mdHeFyveTBSw46/M 5M2Wl5AtRy/hbqPOjtY1v0b5x23lcKY+8QyHLDrQa7qSShg3oUV/zD8KIFTg aEnzr2XBmb68ZM6VDO5qoYVn3AaW74iEnnfY8M+zaeTDkXQ3wk7IyXkFj46m hwHG7w+TElnI0WOutaQVtqp/DvNQqPc4dPopZoY0Q3v7Vk+pN1oUhyrDtJCQ sA3NHDc/K/y8LUfY6w/m7QGSfD+p3Kswn2RFWRjk/oXH+ztVh7UMauue2Cbf IsA3mNh6H5Qt4xyVQ6Py04ZvTTNedvW6Ewr1QS5DZLOdwUGFRyjJizpIbHps hHi5K9ZfSztH3bALcg0opw5jsrCjs/I9glUu7gXabqG33O0KP8dQqVZ2QmTZ WJk0Nk5RRrKbdPnF3AMeVtDIIzm/DCsFoWnLciFsHGjvbe8ulrCj8qP5fyXQ GyGBcUZHuTkPEW29i7djodcOWwQK4OYfigatd+vQRnpicvxHeirZFmsUCyhs JfLH+m/auqqFSwFjFuam1Plsa4rfc30qUohtWeHqLrcWOeTaFOhZnR8rWGz9 /bRpBIJanVY8KhM+Wdi+tfad+t0if9zXVq3dvvzrToygLDqnPNUOhG5huEvI jgD2QVWf/VbzF3BXVAOloacN4vKvaWicuPch4dFEBaj8udIR1PknGDARlDV5 xgygBLIlLt4a913gWkayYOhJ6NwBN4EqSDyq8+ZGtE5krJECFgDZtiRmQ/kt qdaiJEv/fJBYMBW5pIz8LJGIr7k2JLcfMdcRcgrLUHzfLij4J/PG5VqWqIYn bg4O/YV7aU5C3RDZMFixG/pzQWzL9+ogS8SbuVuQcspO2jB79i3o+HfWe/wI AGTeRWTPlk26HD+oxilrlBvEbKbku3Sj5W9+WZHBgmPEHCow3/ztID+oBHNI Wv+7fdws+qM/IAMVei1630Cuxw7RlB+JJkPKS/vwmIvQENNGWonOylSvNlaU VGc0+PCcSJ/UwqhMcRL2jAli0FeG5TfWR/nFyQoFKF1pv45NaLdQwUFZW7q1 XHhdFSmsUJXYVpfUraktHwQ9akbm6dM3bWXFMRueMVqo4o/B4Bjt5gWtQKiY Sm3lZwWJsoGjUH2nFLs4i/P0lidjB4TW1qeZUnOajTFvhjzBekDVUx8+kqek NnxSE3VM52EZgkAdKnNpEz7wZHvCjswTQMNhTiarA6bjB6X7ZsjdsB+M67Kh E7F8cOsgfYLPKyR+4DXh9Gu11AFfCM/tR6AHYiWmtuaFAxZT0A37n06JdGEr HinR/Z3NuZlQDN9ry1lt8/kqO73nvia3r97a+3Q6spOdi7Iu/2qp/M4txmXH 1VM6kYFjR2I+0qtn+8kYTU7a8JRFZd0ZKmoPUv8wAxZg+lJ9xgurmUUNVv/j U9IMLBClp0CTUmokySKEe47fiG/x/+2RSwLcVx9nwpwfU/DLm/ENBqncPB5F zeXrKaMc36FKcbPkKYc+YZpSxxrUPfInmJ9BiKmH4LtjRVE277kFt3njEK8V wKZmD0YrEnr7aU9CEGemAyKOvsl0BQCdV/cnW/NfM/VRo6tC2ELbNnrCmNa4 l1npHGci3177G8hdFZ7iWFQIaOeClCaaebapT5wwDc9aD+Ft3D7xh0MvuQwo 414KlKBz8FMQSpLGkM/0sLNrP+WGX/+dSsb5qYQTPPrp8dj3t9D1E4zVvwnt 2mARYEvKh4ATq7i74IdHBGbgTuF04lN/tvEWXg3X7hU7t02TUxRqZqoyMYQg YSoDM2FTemMyu8rzRDgtiiV/h6KnJmy46WUjix3CbDRBxbkFtmAKb1RnmxS+ o4wr6X7SzQ3ilkYGL9qY2q10kfWYMCfxqp44Gs6C0BVccpDx10flGB1Jk2rH bL+aAU1Z/LtGBiepL1Ctab4Txn/GfsttiJM70Vb1dLcMRzGv1xG9vuGfODb0 7uRg3AY6G/rWCL4fxLJ9SJw9nNH5WmTAMAZ70AP+Iaq3fgrXv9hXsagzHpeC z78bDMrIrwSWagPgbXLEZf/odVMsWXlavmNUs8UZdpbnDefPJXTyX887vpL0 z+r5Fi6gHX5Rf/FtUo3QtaEb8B+jOx1e+xWv/lUBlToiyQ6WXbRWZ+cnD/0s WeED59jRPVlSC59PWboATcPRvcfV6TKvfs9y1LSg4I3C8l5wlnxQLo+DWker 8I5PdEoLOIZXn5/O1UGgc4rBeDvKyGDCpTk9Q9O8i0ZXQHW1O2iiILYID77+ XBmGUiESj9SJmKBzUa4eQ38+wvJkNCH0m2MLS4hfgr2NB7En7PVGMshQA5Wi 8i9LRX/MZg7OXXmCJzHP+J1qS3poPT0XrPUz5dTmc2WIfVCc76G9YgRgnAca uYEIWikjJ83pwGNtClSmaDJZfdscbKHHbjmdQKkaP+xEt3COm1Y3xjJ1Ddpj W9A6HCysK3w4WhsM3MNWv+o2FcXVpZmytzlGEnsy0HaraNubTznunw0eubhQ WBwFv0+VpTZQuRgEZYelkY8tQuzReiwT1ahBg0TROZt1ydea5eLnWs/3v+97 LAZ31HxOPB41zSLm5JyBd60JzPNwe/eZoDPpZUalIk4oAW2+CA5f7JdJaSq0 vDfg9BTHo64qHmHcnzqwPHA4dlph45T96C7WANOncOsfG/OO4OVsSbb0e9gj OCnUHsHZsKqUt8x8PAMDiwGi1UK00buPpugnBWsaP27pI2SKFSHZyPbKgD2J hyDXI7OqcWb8okkIhMHvd8sP/D+/u3Thspw0runY08RJImjFFlUwYbu14Ez8 XjIVYnJqDPRI2F1i505kCTLc9wZ57YaveDtfiRBN/q9Rp20HF/R+Jt+3o5h0 h2YkT2iWrvYhLphdO/7VZNFyHXu18Zz+ygyN6htpVZcOa2TIN7oQujeSSGV9 d07VKQBCajsUZ5sU21Rg4+zGskwNiiiqcJs6O8oZIE47t4vnYbLWpSC4oBgx +6BMLc38HlXgDwo7ckFRuyBLBvLurPvAHn0PXP5e1tFmf25yF7jVvUs9j3sd 8zfhfFg+YHgQEYdjpi6cG/sgQDf5tleKImQu/oU0EJiUzAzkDlyOiamG7e+7 48io6d2erAiU4kudWFa6qyROJlxS7Ek9hAV+ud8ZffQEEmyWeKcHX+3F6JIP Q3V6RhNXZEGIUD2ujhitjV6YuGPBQAgv2kWrj8WFn6L5rgnkrCNbMqSHw2Kc 44oLmOXifS9g9i/l2p4NQD+NVAkYMI+NaTrcicdXCPnnhiyVdnlqPLTKps0X PHw8SDtpcWNCS+VEfyQNlqg8ZQebJhtnzi3fZLcByZMqNzoe4k2+EpoKk+1k 4q+vLJylGobhN4jBoUaq+nExFu3LbB1oVKBFMmvVWP1qVhuNY5QRmiYDYCYq OoyJ+oyNn9Jg5MzHzG82nR0J44JM2s9qLsLyYP+lbz0HnpVLJbObF+DemmCo gBu4Ux60pPlC3tSL/Nhzl2szDK2lhuIJmDbTWxUCIpLx3EwpuOPyvZPywAGe aiv9gCnaYA6A7+jOz6BRrOaCQKYkyw/AKGGx+HAac7kS9qNC0gf6MzF2DECL m9gUxS78wUUMnw10V+2XbU3yn/QAV3wRxxTmG2tXTwCLiUr5k35udCi8JDln xPj7fULJiVwr+QEK4aT/v6+9mPl23gqpX+09w58tzUf7xHHytMw9rfmp4Z+S IgWf5RjcutSSiOxDIGXxNHMSE+LkUD4qMbwnWFjMJqn07dFiHntB6XedTQE0 ivepITL3OnmTnTIsd0UedCTumR5aPSDm9lNWSzDCVJgliR16X81ijxi0FSp/ vKsGx5nUjmjXMuIB1hcwiFUioy5OTXmnrYz7u2mGF7CzKfYY5b00PjuxwdGj DTsl6Gm8Lhm6zVmMKm3SGU8bIkQr6HPnyZm63ie7WaRSgq8q3ja8zdMzrNGQ 91eOAdnBhI1yzjHYtmckX0C9Mizhs5kkGzRfsVlhHmae9dTEnGbz1dsiy40P Gq7o5TThonVR6+As5S7gmgthdA3vdAsQ4KrRlXnj5KjFYZWvoIWzjAP0xfUT aDuIbkADvn8dAzD+WBntF5JvwUnnJRrmFSDzqeFNEV9DL/agJN9csYEgvMMj RVY2ZX5H4pwawT1JwvywOmXS57EqgxG38b+YXjgUzokWUW/poLlLkKyMwNVO pGu+P9p96xQCsjqLgchlJGrFMNnGpCJSt32pvj1LPNiwHeDzIiZJdxHi5v8D 77NJCsszH5HA7V6OwtYh906Yafhygl2VdttWsWaw9uzp9TGnG4uddtQqMqUm EVkYWtSaPWlLotw4DByv59uOMK8RsEOVPZN0s12JP35G72guvvEu3MqmAfPD M0pdZi0xUQ2kuxJXYQHsoyd9KY7WmMfXixcjlb8ILUt2t2ALo1t0ERRb20+Y Sa+ULaPIdn07YJrLodyNtkhw9IpPk7+sH6KmTqUxIZ4o+RpwwjYS7DnrMdSz VkdaD/EerAcJ22GL1b3bo62n0+zAbNK+LTxZ+6ddx6R37e31qub6xg4Xa92V mx8bYla9HETe2/1ZeSYRUxkg8MndlgmRT1cGlqZLQ3Cb5uEZnv8L4cKCAepn VZfe2Rq9R9tIaBRnHxrYaSj3g2Gnl2SuIMaazh5r09PV0qKSdMzW5aPP7Xtm jqOKFGwmOW4oyFNmiQ5rBLNa2/0B6AHoNjO+q83Bx9584wunDxZnY/HA6CgO gqnV3mK5miw8hFv/JBCViaYOx+bxSwbNiP1Q5bLhhHOp2gJXNtq19QyMlBJO mma+4OsyrB9Ra9EuDLkwTcKiWF2Qckj04lZKS6Ax8MK8LvM+qLlMgxy9xCtb yUGsxSwA+A5yBBdIp0HDJHSAV/fBGrQHarYQhhMMmRmYmtZhR/R7OPSFu/JY 2aJuuQ5oecpqShMrzrON5oDFV9cBAPqaTi1WjHGJEYraijoJ0jl4wBzX/yIk iQ5I8VKh5n4jzPc2uQWB1IMat9h4zymxajI37jHZWn31BzpUKzE+8T3KccFY NUVCfdKaXvM2aidZnojOFgmvbrqirZDwjKYPe50dEBnfHI58/hUQpRTU7vPc KmiksYrJEyI+2HPWbcMeGYxpJqKOi9LOfeLr1rnsnyWrRE0AOmTx/wqPeh6T aAe7MPLgPNd7bKMDeAUYePqXTKldg8YlbfySonlb+OlSMBHzn2KxUIakghhM PfTiYyJkH+HrOc6yjST+OocPUAe1vmxNPp96FQ+DvgtKD76negMj2otaVTiq KwQNal/AICm7gqPESUfPViqTdbxqLXhp42bHC4H6XN5F+zw325eLMKrOnTcT RRpAt4skxHM28dlvvfaz6Jq9CMGv2xw242eR7aHPtI1waXTXbO/2YO/yE4s/ b6k9I8ZmR+BrZ/RQ6AckJlc3Us/2GWaicYVgftXqpg9eE9LCPVhbuSS+IytP taoZeFGSmRCyZKqD8ISNROqHsyYzASKPQVYT6WLCLSnWIcsFS5ZhwakNzBdk VqAgnl1FH7dec7wj6gQWzytis8AFYMoIPVXH1OPMib35LW6OJAuRhhtbn20+ 3AGo9laglGyEapVWCdPrRmu2sg/Yry8eONik0ABgNAWjBy1Q2VWfFieSwuP6 aCj7bPX88HY7BNuLbCnYkPa12pi08Pe+LSDd8vmpTINjsP7CKQLRszzoNefv I00Yu8xwGfKJmj2A+aW24YxNKtzHYjMeprbWsJkZpC6ihwgIPeb28I+CoBrw s+jYoerSzAGfTwnAvgBaF5a8WYWWo9maQ8SsZlyHTgCXFXVDgZfvAQ/Sny4S a4DvEMZ0MboCd6dFavzFYh5h8q9TfheQunPWL2+I6rti+n2Azyz1oA1phscj EANv5Mxoj0QDi2/ZPPWOsfK1VZ8u/4jQVdVEqIS+hWsbNEfSGVnhOWXTbECF LIiGF+YR0UHu8K/CmJ1WNjeSxgkLIVabRKr13+aoPM222kZg0EYHdkwgCpHf 2q9GR5KsgcDDakqvvErPByCeEeddDES8EnOvXs1q+rrnZp8+dS37Cm2L0Tsz 2A6pM+4DMa0Q8TeiHLBp366n7GmY8UAAKocKxbwxcjLpOXfoOBg7zJq3iPD2 8MvRu5iU5RzdjIOCoFfRHyBEzzBx1uQqKsSDhz4SWf8PGsmbpeBBAUkSibnF 22m0D4cLP+RbWCTPM49k3Ykg91zjfmnZBPXzTBG+mMA3ZG7mTiIT9weUAd2H Y5v+haNZC80A/Dx+x21Cnsb8P9A19CLn0EwHXNx+OKNMUvAFoot3A1Sjr3Dt xBTZKHsulPECehW1smgfgF+E2uLzbwpR4tJ6/Zwu2vA1YnjPoPoBpBb2ZPel fO7coDIa6owgkUFBMV4ajXS/bvD/XUcT9IhvkdYWVPYBaSX87yyIXKV93luY tZ/OHrvE14I0cHSoTAzca0T16nBrWZgokaN1Qg3DTtZw1NqfbMdvFzqT0NgV upRRRtOQZ5xLtGYxrUaqS22/uA9niZ7wPPisiQtg2LnkUvQMDIrFx0GfZMQf huf8oNws98u8nRsoSd/8a3n7eC9B+JINpY/Kow4Td67GLyQ4YEjII8hgBWUA LoFCBPcxfxpuXHb9oewM+NYRvr64JH1uuJhNA+YRX/GANdx8HfeXejvTEAve /gZBGlw9X6zv9NL/5eOvQUPHozOL9LCyO7gtzZs44OWsyOTxB29kusiRPn/J JPWMBNHlPA+cv7OBqgaWQau8eo59ChT6J6sqrBgsU+C7WOoKfCklEYUGx4gK YiE/4RVWpeJ75qWIyDeQ4m5fNMzk6EonxNQFuXq71jOtVggq9lkCHUcf2TjS PtBSKPIvj94MSvkm9eSrDrLZZqCkhF2Tt21aesKUCViybKt1zgNRciDYnYSZ Seah1D5ev7mqDHYLT6WnId49yFmvsg0ckR+fUMzj5AAHCdK8HPkFIt8oqbYy B8rQMIvEcfOcjrvwmieRDA4MkHBkKVOL0RrD/tQDrUFRTj0Ek0ntSJHWuSZ2 ipq9u/vEJM5T6SgZxpoCagPIJOeGkA0uvHbVbVB09FbwRHNm2A5B61FBwJ9d dZdgaRMwZJzBOf8naAchqGWmi3XVWv50YgtcEcxRMwTteVWjXT2LcXlI6B8i X/dwtZ95FAM8WegYGXQpvo3MlyBQhT9Mdj2cE2f0VcqZYxLl4zSt+T4GLcVh vqToafkA2Req2tOAJCjyEIBIwt3qtuyIhUvcrTFuY2lutUPH/IL7Wcqj3BaU +EwHjsBrzfbv/S0weMXNE17Wh48hnWuoj4ZZ6v+8DL9b4pwOA9UlLSv+Edah 1UcQJEqQon87IgdbAAyYNJNXZn/yNPE8cSRj97kHUBxOGV7r2jn7flt7ABi6 kgqrc7mTRyMN/CK2SnxgeJMhsofWkkiwRnqd6FiOdGLRF6O6oeDmk4/VYxkF jjFNK73SKKJnpWbuWrIQjdWQOBVVbZAjqfwv/PBx/2vjl8s5duWZoD6luF2i yLkf5y1HWclO9DZgNaAxkU9qYsKKpQmaKh0OEkzCwqAaARzCETg4hcEJ4EGS 0Ir1VEvqXbSR1BcjfSo53eBzIDNfOysoK47pbJJS/Y21SDbpUzPn2UgH8lgf 3ftOU+UpHzMz+9sZ/7w5BXSSujnOi6Nsmng13H0ir6nxwoXNehSmtVjK5Pst 2q4ko+QEkWWOg3yUJEcUoHhNMzP6MLW/gh/z0OJcJ8ilCwwWvROmQCIAWMzz 9S9jQ08aSRjDmjWz0Xma62mQz19FmYIpbEwqaylD9Ebc+1g/NSnhALKbtI7L /KQNBIHQW2D/68Nr3JrplAymLCL3SUQCz68pfVeVTI6laJX4Gs9AmWkatbOV mXrdKe1G7vZeHIzNa3zcnM4bZd6cNLRJQWASL7O5zG+bwwjoZyz4hUTX0H3x 5nq00gX1WEvkmF5Tvp7c2FIk38x+VdH4ch3GUeT9Xh7vRSx8u4qgnA3XInkI uIWJGcgyrSgnYP3RnwogobFdJk2Lrq87m+X2tNYiPM5u46PGPjfk3DXOT35p xmPgaPDubGKqDVt3zCWXeYUHxP/NhoXSJe0UfaijY5B6K+QGGzIbRplTBj5V /v7M+mPLbQ9zkguaPszw3mA9K32w9icphWXLr6LaXgdCnBQ/ql67xPyuX+Hr KCnp7RzwFhIDWK0IMRgWZV1Q2PkyJ1w0Ez1r6kRDV5WKV/iBHcuAx6TUoYJ+ R/HDsbdptQ9VCRNi/WO+Z8zuIiGeEyu73+UlUMOQG8uVu4IF+dPvKGUgsrdF Y9fBB8F07fBh5TiW8IgURyBD2dzlegQt/737twaW4YJuYKhPJwGuxa4pI0Fm LueYE4uBhRfNMoClYrD4i1P7VHM2st70uDUKX+uR+M8wPeMI6TYXKJ5we5/T PZr3O2EyWS3KntZGImTThwM5N181IKfn/yGaACgzDXGx705UVYmiboO8Fd7o 3NQo8NFRBWa8dVZY3mFiHDhgBDAaW+/inDeYLRdBm6W9xaunDaKFFReUFY4W QPHzUMnVbPLaJ6H/8RP7HVY5BbbxRr6OvuOuU4EWhDbcLGKEW0lBfO8wMsCB 7EEJnxBhvJ6t2b+/ixX2pCN92jWrn3+dsdvgveWWLF/jMGSbJ1OOk2lXBNX9 m5hxxK4wdLXgN28KLaiBNSOPql1VTGRgV3aY0ichmSasMHwCBlkKjZa9MhfC TlY75dXag8dhrImhag9od6O6zdf5LiVu/anOgPOCU3dRCl9aUvoHrINgVE7s ZFx9GqgHuLhvES6gU3D1lwCV526NiyxO/dNuFTmthx7Y3p2Kq6N977MdNaxF 8qO5D0EWR51DSMch8QfxggHCSLXxebYXVEFUaoQuXkoPzLe7dP9VSsFHPLPn 64z4KAbPbgrlh59tdxcVLLRZeOKgIQAqTUfu1reaDsExldFf2YoV7N+TYbUD +o1XoU9GGQq0uUNAQqdHq1i0KOV1jYTSpxn7Z0NqUIY5UJ/+O3eaXEVLpFZS LNfGjFMWSki28YT+Zryc0/mxxCl1hToGQlDl2Qpc481DpvFrZ58NEwJgZcPS KNvBeyBRurQx36E962+KnH7ypYuPXWvF/fR2kOxDLd42k0Ljkq0xRp4vbrnb CynLcPpKcA9eN95858dqREwi7wgyoHdFeHW/SnN6OWcef/rlb38AJIjhD61Y OQJsOAdxMqcr27cjcjkWX04q5lrEefBYAIcq9d6aIYULtDkzYWeoZmXqCQ6s zJ17S/vItSNzylRNQcJiL76AQyqdvMkv49gfNQpkFm5YbzMhkIpo3W9J2IGW WV54GBTjSjeLkSV1fWsdnr7896ZXUgc5XsoQW8xQWV7q1hFKB264kRJqJ0Jz KnD5ZX/rshmvDhWRAtbzWy15PC9QBdFRReY7NuSldmQhxx2SEQH0QyQuLurU fIV56KYzcyqIbjLn2SSqiZr0Q8cYoKX0Dg37fn1wZXFxkzUVtA4xX8DW2xGa 1wujN2qmzZvePrvOZq3JydVt5EKPKcTowFf3dKEfZ7QQP3nxDDcISGSzBcEO McThk6SO/A0OCCr8nD3g9J2QiPNRKarNgQHyLxLxYQw5T79ikhE3Rn2H6nql CPQ65v8u/USEe8HnCaQs4Nznma7wjq8lzU6ZavamjfIKCH0xZVgPi0WopyLo qLefZnY8UOw15eMptFpkh+G+zCRGH8OwG4wwU5aKDDCVKKx2H641QnZfzsfh mho4w7kYC6acj2A6XFS7tTIwN55HM26TKnhFeq+9z6XGK3q4GIX2Vmaq506I 0LL3AscI5ONkpYp5a6ix2yqqflibk8I0+kbPeBHZiRYwzXJTUI95/ZbeHN/x 4nFUjlSpkKAsxgoo55Has2G57YlbHU8xo+6p1v98Be5DP2lR/9WHMkzUByZr Dz/zlSxyOpVkCynfLuux+2NB+MIALutX1yvPlKuJAyJMbiZMnGzQmThpZB4T taRZn4mdTlrJy2kpsaVTHCTe7KHRRXkQhre6GVsU/9v1MvQuj1sAItGmp4nS qkIDOrymjCkATanbCv1RrZzUKxp5Q0KCDd9tEmF1U1If2Hgfo4LOFaOGUjhr GkuH2yNlgUBuEdLA5X5HTXxaNclOjXMmKKlWqgWypY/gaox3ZAwE3NDgwIMK eBZPYbf2EDb5UPGiYRTXI7pkmC9slxFaQUtcfuWfAp44JIUHW4oJ8kHtAIdX G5E1dpbXFcL6128NL3C+y72h9YPZqQanzDkhF12Q+qGmUS7msXFxeakv4kFE liNP78asfTlUhIQlqfZlnPCG8pYN7VXVkU3EVEZCSnt/8gqpvvsCOhvGaGCD XLFGFMYtoVhkRtfiHuG4Ur4AzdTF0n2OhVE+hlNAfF0afkelnbjxZOIQsJvJ oAn7/WYJQU0xIjCZvggCtegaZr0VZNXSfaYo6RWJgZe7OGsxnm6chlHPYWe1 ifgbAo514IuUWkvAPIfE5+pDMyOJl14gbMWCq0WR1bIA893Ux7VrcA6gvn+n K91c5UVSruEHLj2h7/FrwbKGEYIhRlWpgJffWw03ATuV8hMDo6JEU/I6JBsn V64jhNf+iC+s7YKhVshBF9zwkuL59UVtbAaTZnsQX6NPw64G6vHq6jz8e3nR WzxQOI0ENfsKw/nSQbUrlbZyVJdImic3vnhnwlQML1heefOZaYAb0DfUOyez 20ZchnXWOvvu/bEEWbvu+oMEyRcOfQR4SteGKdOHq5bCINpb8Ob54vf4LifM zDBJfmPX27x/okAB4MKvvJj4XPRHktP2P+sxzCpqNCkcbQPRE8xC52Li98aq X7aRwht4NNl4zYursWzkVz8xF+In73fU3XNgCAhsm08jfaP6RmjXpo9QeSNK 3vJG/CiGa/sJ16tby/H8ddEE0WYzLUy58YYt75KdMzF/PDpn9y1CblXeR1+L sQso3rUImDPfJZmnAWEPxp/Rs1EEtR80rHOEp/QMP4/iI586BmNZiORRMaJi 93bsIDSZKcxFED0wV7tTRun1UvThafzLBDsk/CjyRUgIlM6KTcViTpBGvmVe 5KcimgcAe0iBrh8VoOiUSumNlVLPJkqEXEP+SjAVMC9jntZK3OXaf5+AucSh 51n+yL3+HITS8hXnM+KRjKtwRLsJ+kg8wEID3+vd4HpKNmtm+dZpRIkPGNMP vGUXIB2rrYSsz+8aXLc7AN/cM/nJTADT5U9L5yb3+FbtsNM0ezYBOkpbDctB RtdfTm4KOBTSX8klq+YS1qX8LrlEdmN25/+7vhZaI45sbj2ANbGqhlYaJ6DW Q84xbr/H7WurgO6yJdnN1+HJfgEOx+9g+Vq9UMpxdG3wz9c4GbUrD/pH45Uz rMJtmJUj47ivCfa5a+vfgY+ZVfhuQGYB1I9rEKf4gpwzkOeQ7PyPwZduWxmb tKh5D5n4oDw1hN6O0Q329+bv/NlpBebONz69RzXgPRyNV+fTa0lp9FMVFBOo T/R97M6lPxkn/NR7d+beVxN9ZyNyaA3//Yk8+w/SAwVQ4BbRxFHhoZt0xP0N jS9B2FKLZSE5t7gsi/ILAO+hL+3+nerKeUxAgNXRmog5H+en0Sf2vxEVXZ5r UklES1upj4DCj2xzP4EXJmTsuT6EZyWLSCaTNiDekN9wY2FrOrtPwjzF56yX B0BO4Z2mej44xqDPgBZw3TYuSdBaAF2SJnLPwWXQWuGhwBvp21oRP0ssjWSM 6p7m5pEogVK7N/k05Rdm9WnDDZ4wp57TybPtbSkUjoI+bXteD8JJ+SgCXcGK gIqhXrvqgqPxZypdYR0e693qTT2F1pbuOz4N3HxDwwoIYwyZd0+3DC/Pfbcy VOXOv+I0mQ22smEV6TQWf1VFdQ1qxejXZKHTcuOirrhpCvG71laXVkz95ANI jNxBAsgMxekVTOXbwF0rYdxQ0vLM4vgEVKEgPeG6pNO7uHQpWb1BuMqZWkS+ glf7/XszmIGz6nSNyUpKR8zhPfmhNSZ6KmZ6495RSHEvY1vMsIxYkOKv280b Frwb2SxuBFISVHjbL6gYjf6CKbGnMsSpQrbDcRm9TgkV5CmY2zdaCQ/VHKPw fyY3giA2JgBjfg9WiGm8XT/EbjDqmRTLY/cmwdjzJddb23d155G2vUGsrM4I Kmd7itzu7tBTG7sNbBnDAJL4Knw4ETKjlTyZS5y4zr2pljUmc3IZQ3upEecF oVthHY7P+eT++oAr41xLddIUjilveZGXpHmCNiq5cm8Ult+01CEgPSunccFq 6HYGoLsryRjewPkXkpu8/5doKQJEBWDJbQ2zqn3YfGzongOqh6V+Fjh/LICn j/ofA8kHF04F1QAJCp58NPigpZomgdYq8alfnatEfu3PRaWMdS0pEDuzxJb8 +9utsWVnnvDvxGJu6MCaw/jWlBhCfwxUmm48tOLRCavhr03A5vzNZM9AOyB+ 2b/QbsvxAlUpOOaHp6cHs7RvKGIaoA2WmQpbsS/G64FC9z9nBdfrAg361747 OxbmFH0Ge0DApBAYvOOJ+h9smZsmRC4V3o4rJWczG2DHl52zGWWnuRPeVPZK /9v4lYsy2a8FARrzcK5QFbt4z9ox2EWk5UpIj9Fqpn0wJZ07mZjBQrR7po/0 tU7BVz94H+JK4yNaqpP5CTeypurXBOcbOxsXpmaQMY6cMLjui/qxPqkmDcoS OErqcFHgBhio1TCgHkQ+vLppuCirHwZbm4jwhfPcBnpaKkQRp9Niwp/4ZC3y pzRZUsYSvNYAIchzlGPR4YJQnxqLho5/HCbq98zjacBfUMLcEzSRRHeY46mw XE+0IQFlHOVTbVM8A9GEa6maShX/3eNIJRYTLcS2ILQifeVkm7yhmrT3Qndw AsEX2wQSa4CXbB9Ki0T3gJWlTcZvnwrZ5n6zj0zWVqijy/6eaW1v9AroZA3K HQZo+PbUJziOH0HYmZAqOE5HmWlj+ftTQJg8+hkuR00hNgM1R35c2WIZZO9j ZWmyOoA4ecXHgcnKN9Doq+gd8+BEwmjexYqz6c92KroWWvUwkq2/W26omga7 3HC8ZpidqQwO6Ms5WI7/YYq8MsIENrEUlWmvMpWthaH0JvVhMhMQjGdYHwf+ dTBW7Yw/tqz4BJq1DyqzinDARGXL21nof80hCNy8YhpOw6xjqYpLmrZFsqzk VoozAgeg9E8yXpNVChdX7P+Av69MgCZihD2pW+/8H+9KujonOelV+uHPoQug Fg7olWdCJV3B2TODWOpNpflE65fZgRylzroisR7U4BDSWA4M+0j8ccJN6kqD OoXE3E+0AE9VyYykcVGi7my+nPZW5GPGDt3JDVins6C8XyunYEyRR5hRZRuZ WXN2bm4Ib3L9B4zKN4GQj8U7t330T72pdoyE/JslET6y7wuzyaoaw6RN7No1 bjUjbKD50Kaj0tubLd/iKRhtuD746kfMZF8hY9zdMakm811WvEL1fI9BwmNj p8bzp86hpxixQ2+pmvuWZW/paSxH1VdEkX1cuQUYBtt4Sy2/ZVRNzmhBxqe7 so8PGgUp/bxXz6C7lYG5pf1kX+qh/Lk/gecYCErAAJ368jSRX0GdCEkaCPmd xh0FBWaylcFCLzbmR63erNIdfqO57zxJADqe2kkO/OSxkJex3rzwXxh7C8rk zKszPjoPsHFzBbTv2JbF81qD1U657rI8uRncacVyIA1El13+Kvt7QkUy87WT nSKqY2S2k8qrYLa7j5H73h5TkPLAp5CkL4hp3ZZMHLmhkrozG7IHPZ4mTG1J 0A9jSELB0PHqfl5kw5OxQns6rtoyoUPf/gL6SEI87Kg3KrgDhPuyuPqTB9a0 rzLdvs1lTjg96n4xDI5AoJhvDmPah0Esn5Y782OtKgWlTMrI8heFVtz1f5M7 GaPZvc5y7qOYjHK/l546i7/3cn9lLfx15HPwhS1XOJiD9zayy1uQcb8rC051 zMe/3TbQ8d80fbi399BMRisjSJ3UoWuNBeOf+E6Eh7wkjLSB6G/96Fldxsu9 pKSvse3WjAD9u6EBT4GIv8o43zPg7Go312/fVPI8bvtoioypUsmxORrjlUCk o0s/5UCg/5JNAMSNGAUIAp+XkCuVpf0xwzYwemKClbDmEZlaoQHUpXdjNrxD 6DCvnl/8l0Y4/1v0MUUjQjEN0iwOPZvhwblvpU0u86lSt4p/RV6D42B3GL5O FKCa7/PksMpASDlL+7UKEOxZ6H/ghrRHXymWqhS71McVY9uGRRtdezRPJI1F C8Bo196V1ghwM+x2vbL/10SGSbOEzVHEblNFUwTnoxo4sVmAUOrm2qkdn5kB x4TS1uowmkhuD6/ZUrHCk/3O6XGSXFezhPAqor2RuM4mfiIhxQEQZfQyk2K3 qOFr/i0uNxEKtP+T9Z3jnD7DhkkfwJnoN6gzLvvGqM7T7gtok1ZoXGmp38Xq FliW0w1UGEOF+BxiguWr69JxE1lmtVyFAJj1XkHeL56Ff+NFYEiagYaYHWHy wJX5MXfvNAc9ARuyIeflB5VQmnWQZ1O/1fqSv86O8O4Bm1RJlVv3kurcBedk vUP4OELoCeGrobN+Kk4TEqKt1oWEbjPqOaEvhPfPAPVmNJs+tZ0lWylC5HwS yEOYiHbQtRVG/A89Gp9Muzh23CCXhX5Lyo3/xmoQFxfwXZceoHf3Vs5VQzwQ rJvWYBthoV6YDYYIk2u7A5yGtUs/ccrsxZDzvZdDeobXarixurnBOM+mVpLC AB4k8L/EUxKI5v4IvanCGdTgszFS1WFaeZ+S+w9yj/BykvwmoIrhJhhq0Hkt Kf0kjPDm1J0Dg5oI4C+5HGDNLhWxT1p6tyjsbA1pO+d4kCnH+KgkJHTPlgig bgic4iWNmwdNNKfHmuR4YCnyt5/aWjPFrxSVLsbr2DB/wrtgNICkF1lYqCXd NSZR8Ke1EC3gEfA4SJ9grH1VN6duMxeySdBvUbP1aQmWyutdrH0U41knBy+Z XkH3c7bIhuW2RgWMKtGpDVP9fZaQ6pxEuh19UNVqJLS63T8Fv980SBJK9xHz +lCZPCcyKu7w5bBsublppY6rgwiAhqULsQLhaNTVJwaT7iWediiEZo81ZQC7 Gv95KWVNWebyvC+6aT+qJ1m1KdAilevz4XQpnPhijpjsjUMjLXSZl+7+iCtj tzYZszKliU7PxzLMDVN3XUFJ29uKf35OZSwiEcbkMltbVt7eXAJzzN6d+/+9 DgZwVxTd2Qwws6frW3fIOyH3BM2W7SPwSOxPSlZT2uSpbdbPAy61YGvSiZDJ hk/2vTt3zaE1ZZtZmeQ2z5M881TFataKqkANr8zrVAevb167xWcuAVhNbjth jaTIvhPUuGPMf4CarjAj5atejoOx8AOLg6k/MiDcQ7aueiY+oshRWSm2sHwO CF2V6KMuGsiCANX7GnXa/gEKhFy5agNzi5PulIRF4vTC8LgU/H1ORxlEv/qz mSH0cDF+J4l7+tIXmvagMVpLeL/XqOYdNtQm4eGS1a88jQCpKUSFMDEbKKwB IDU/9E5MzdS8J852dTLUld7xgOIfgBhj8WLR0YaLgUh0oXk+ee2bfr8czBUP l+2rDDRqXIQVU8J64KJdODeiwKu/hokJ8QEMpQ5U+oVUUitPPAiK9Sp07ht2 GURuaWiDmwQg6DbXSmj/TlGGHXkXVMc3fLGcihPzi/RxQtvGiUvR29JVmBw/ Rgu/EsMHuzRzgg4ZkNp0uU4tcYTpfoCI/CRe9lqENj+nRwWZ4GHPkSqiA7fE Mikq5ONPIF+u74U06TwUmFagi0FSkwflcVyJTcvXjh6t6KTV1YRWX9x3DSdP quDMIjyLOQlQAPbN1g6HGXnH2xKodIPOnumTnn05BsWUc5XqU9F2i3Sx/ELe dZloLbQF4V3Yzns7Zxr6P5rRXO7e+Eopiq0/CHNoitElQiDnms6lILJTUan1 HFso90Pf/+RPXTuf2qH4Zi6fpujr3ZhtEOtIIMybSryXmsz+uDFfyW5hww9y V5Mi4H5jUbbY/iQhvBGxIcKEXCHTNUO0sol2M0YoMl61LfRFc6sKXc/yR6AZ gBir6yveShnpm3nSmPHR2z7njD/wDprgwmfNHFfnXRm70nUurakS1/38C/mZ JsZ5O/9mAH+awl0ymAJkgxXPLVtpcVJG5pLumTq2HdZsIvjwol3dRosmk2uw mcjqRQYSlGiRdIT51OeHn6vhQ4NjKpHl0lUkU0mjQsuSzGi2O+N2Fae4sqeA 5iHHzBRGe97BCKY/f6MFeA8eauT92bVLVoQZIRvjSGIsA05mN9B6CUo9fcWs b3bQqToV2BYJRj3kLY8Og3aAgTtrKBXTCKHUopsCk0ZssSikVMHj6fNgRHq/ mDbn2lLqddmkefjdLWxIuC8ujD0KhQ84EdXaVDmOb2xRZD2gPB+Py2qkphGy uuAOx8iapWkRtZvjDwz6IEuB1EfUtDbuObg5iUP9X6Vm23g2pWHUKz9FwkHU v8B6D0UDnOi/fMy68qnlU30Q4N4649FHAt3YiwNQO456HPFd5jKEubclQo5U +CzQh935tHuFo39aqpCv7CI84fjCR01O5VSILVZ+Qv+hW+oiRSL2QbJjkhUr k6U16uApWZWEX0EF4eHXiArp8nWZIzyBgbxaLIYLXoxVf3WZZwYUz6ARFClb /y491I+FFIRpxF0kx6xqgi6EEDCytnmtaiDWYtJGvpsFCIlOVUOJ8qkJrLz5 NLfqIV7KwEzhP0phm7ln3eEbpnEv5+OR9XM/eE31TGXo/7ndAjQzLz2Ag15t XbXs7lJ9P126Lak78Q4lNBmLNZIvoQwLByTytmDll06Jn+duSEq/xRTd+1p2 m8alkD9GBVgUnlUEpQFuJtvnDQdHnVSY2/YbYqt+VpqGQTpbt5pWnJ5DTAys WRk1IicZnZhb5HlFc+ulblac1wr6PHe9s+VetINU8H5HFDKgjb2/SF0RV+sC l7GFfDcRCU9lgnVz+Xv4b5lywlETtLsCX0FArod4VdtC6nKknQ9PQCRLX5Jf 54jQP0N7fyY6+F7exwvcvxjnY5JqKIhtr0Q2i1aBt+y9zwUYld1611pcgjvb KlnftlzzGg4CxjXSfIMeSOS7jAAa1DCSY1nNOhQaMPUj/aFZTsXifJQi3Hnl 33oObH/MjRlyM3ObdRhGz7aXB7aZbRN9LXU8kObASHaVGCnfqiak2sgGJF4p pkut+MKFICWFjO+v+CrUsAeB3wgBhNuE5ERCAsV4Et9c+H4RrShsV6Rlxn32 1/sJJZHxzLeoTHM6jCx0kIu6WWzi9cKB1I1BhdFHX6qc8JmU2FVGyCA9vBcX 2QwB2X5XIEgv2l1nTW3bzannEo47OU+yVQRyn96EdG2gHB1iGEaqkXj5EmM+ bhuCYKrnVd/9ROgHke8Vf2tPybDqs5Y/vIZA6DPDoaTci2GuBmeHDmbFVKq7 kB15QdBe7TQ+rXWzm44j7x7TJ3+PonSsnCt9q9VTjA1hRQKYFVGzlf02q7SX x8ahk8DYgE2f7ONHlZ9wHT1RPaXH11mOBv6zIG2w/SxTOfG3xqjKzkkjpfv7 hchQi/s25J0xvUyU29jmt3uRrEmSWpiEYsSmTDR6b+7iGxhlPm5ZmT4uIypL k8H+pMsjkidH8sdiLkRPFlDWejK3YWGWstAMfxdIdvjvQNnaOUnZV2v9bCvc XPGuF5kSv7s8IiUVcX9E8xV3Oo5ty1w5oendBwW+3w1vhrCH3L048yb/rf4W RdADatqmZayLrvkTQx89NgYT2O2VFiABZcJj+IwBni5Uw6Jtu8wJBkdU/mGm dWuwyk0qmEQcJJNfT5cDatoG+1c+w4YTGdM4LJP9GRpkMorEZD3g3+n9GSlk CE1p8S0tq+evEkGOIUjzEjdeAE6OOPQQZCwzM/O36e9/ZZO7tsyQ07NCYdoa tZwXSxxI0Djldb4viUKsHDe8uVy3xhxNbgmMWfM6MLOPD9X9vxfEJxcYZalV ua73ucNPUZkRoVaA3w8g0OJIWRLm+vsBm7OEdZrFvDYo2Kr2iVeEjkJ9woGd zdaXmodDMOgV/rru2x7NxWsFcDaQe4M6/yWYy9Puo6T6HUUwYSOgVvhC+73a kovSTnnrOUQ2iLAFmWmcahoNC+8nHBuncBrWOIHm6zn/Fl94wagjL+h3DfA1 lNxIUBaX9tupmTLPN4UrcwL020E41XjlfvZAwh3v5jMkSEREwaEoGiYr+4eB sHbbl8EfsEheRwb9bOqQkTxWhPPZzyvl/ihWW/Dgxoba/MuQfvRknel3EYyS bzSDXKyokpamI60033htEbUgtOlwCsiZ9G8N4QNs3f+T0Iv4RnRW/1YZQ9a8 HO29AtQM8oh48F0t19OSEv8A+nSMv60X8SFxnzsjC0yzA4qsCVnk/TTMJ2fG 0bWDz/W0kt1QabWX3jp5ZM+0EdkLL+sKoBSjcXQHcKbnD9FO8DtEQyUzWqtc macdF7knGIFXB+zEkYD5g1zV30cp+qaoD0yhn9Iwyj5mFDN98TizS4U3uMpw vc4bnuKkN+dM641ElZaRL6CYK4Xm4mcPSira4IiW3fsOuFlMUJTPFt/UMW4W C91kn0Hi0Zqz+sOTQoD7ENavM0qmsNuIwYahXqnmO2xy3izg5pw4yv53t34l Iomr6Xv3bdFpru4defHa50KKoF1qV3VKfxeSI/ZhEs0eoWYlwVrerd7Dkma8 J8KZtMdLUkS69EUoFTT4qas+raTph/qCn+kOyxRfxTNqOCAWer3Gy3JHm5hv 8ufiR0IZ5rrtF1A4CTd3VEWC4u3ELTSueB192Um25KnP7dGLeRUivQp8fmLY siRqPRaQOYakia9Etr3XvwmyK/gfDUxxyXBMXvYW/o16/QwO+uxSTk35J5kF oU5S2iLoDGCY+f9jajT1x1FaA/oUzolPgEwNK7xfsWMgYUlDbexgM0wYtZEN fcmiRxosqxDcbTBBFa7qxey94WTx8qdQKp+WBsJjhmGSeiNnpCR1uRCYLZu1 hlgRhbJgt2s5uKKpE5bEa7OarjypVqjLIpKdwQM+2RzGMYbBlqDur8Jq1DMJ fvuAXumjkuwMVfZrU05QtLQjHwRge2GwSyw54xAGN7waX4dsXzXq5+WdyyST PrCRiwyDFIWjXfiHlkrtiJTeBt+4LfdoRxTMbvIIDeWvLUzaCuw+8Wh4ZZXM VFEprj/Wr5BQEG8LP2BWd8V6NWhUCAM/r5nr4tamX+FsFaXi3KJwNkYcE0+X IJTKqnTdKCGc1GODYthcPbMsi987+sao2YxxefMGBT5b5QKc8hf/tGozAkGT DPDFjDgP422n0Be47Y1qu+9d/H8f9ILr51gvVUyFtZlnBVreIowTbuhX91nW RUoL1YCZ9jFGnBHqKpwOQdMkNj3wAvBchaeuh7dgGdqcmL02tGCZXP9jGlsA xEdlUE+nxWm6QNPaWgiMFB1DPJFogfGn61D0E/Sgk9Pr09VICcU+6mqdDZqr Kw/7mQgWPA/P+gybZ1bPmY1LPJPpSEbvofj2+uNGL1a3wEpVPFqtVXkDpWGL qWa3Ldr2uFmHtRF1cKAyeam2HDO76pnSSHphGUD57rKFWZUVWOdRgkc3p3Gp juIt4qU8lQjaX1Te2beBfo699BxGWmd0WwlSN/FjIiHDQION5GlTIl1Ay3Mk sGOMXapJJP/1TGf440BLeqL9Cfwef3tpdODmQhkd1kR8FMEN0JewMHLwyhCO igrv7WGrVpsWei56aSiIJQIERmDhiVl/3LHqPdOxKM9wA7YLCvcl9bGVzOde z+zSGpsc5dFwAFrziwh9iiXu7gXsOJd3XoBpVLjonMnPqWFzX8bfsWQ0Z10D aSVEwZ3SdYq/avXy1i+ESThQlsqQEF31xrDadz6zqje9id799MdakR11KY8d XvYXVa9pRCxCePi3pyMNSLedzAKOIIDN/dqxWqCatRotSKGGozL+6zlT41FE TP3sZkeEIzAz9y69nB7ZK5SRGl5wFVBYUbMWvDkDVw5OIWerPfJ1GIZbx2wU vibJ/ltq7GeuWOiMM5YW0+FxD+HWkyNN3/KKEKQJtqRZGUCxlQDuHO2Z6jOs 5Xncpi/sR5ODPgrShnaAHcGSaq5HesLoSvoReLqT77k0/SVLLzd/1uL9jtDO iZWXHGuk6E5Dii4hZRfUWQv7QBzR7amqMz+0BnSGxNI8FroYpCFg9Ab8syxY jzVWfR5aExV0ruwttn1tbijOxQVS/ghXqPEdEzBGw6sFjzl9fwvXfLij5hmL +hQEyyaGkDS0mosVpnoLa1pnqDkQHFW9fBMZ6u20eRp8XrB9vsY2z9QN8O9Y 4v9/Inc5aNYMLqFFVPrBiDO5epGTTL3bVsBJRRk6GNOnW1dNroMO5Sqi504h XZKg7thNqH6odO9KHYvR5H6XFl3DfOugIhHgA+zspJF2PZwcRfY+I9KqIXhW 0uaPWLGYSdQ+NPcMIiQedkseBqT1I3xzTWQUxVhFIuqzJLrByXArquBTY1/b +2R9YkxyPUh9e/7dnSqv6Y596/zCalSPb67plQPJ4y852fk6Augfo/1gKF5C V0xvhHyy5i0qpTMUAjZFISdnD0QUNiyD9HhnGGO/tz3D5wj+nFJg7dN2jjat wlp22b2el1KTqrernf68h6pBPdia6nMuMNQuU89EnGCKqGTmAShu+k6lJvI4 e/t1qSEqfjUJYXYQnms1Kml3l2YhU0tDfDY8Ioc+7G1JLNREw+Kv7Biv7HKA jvy4h0C9DswW1op33NakJ99LuPtQG6+vgIl9DKOkxRQYKS2Rekld3ChLRD9U 4Y4Hq187DOSyICCxL14O+ODF9nOjkKM+tzVUdvTAl3YUBhylL6Z/17Kb1D0L CpSdu28NpraEYsxbOJ7vRX4TWeFiLycxUQUOHtXZYDwFb1cm9ALWZfpAwFVu 8yl1SXR4Ngc+mrmoI4asvFq7mtY1CHuLg20rpdB4O5tWPJL+L4XkZTHPNsRW kO9yuq17SuqWoUVOWVUu0BcZ2CO4Sy71ldQphQFLv+fs7fHW+op4ZkG7O4Gu 2Tkr9p47GWt6c3HzTmsxTxDYuJUw1vQrSJHdQAowCmmvv3RIVCPDDJpAXb9e EXOE2Jg7DryhipgWuYVmoPPupztu+h+RuBxzRWDAsftjobawmGNHooOivcXs 1P0A/vwtxlXt/L8392CbRmraqZPCZfgfgBLAmzlwWJGYhZlFrcJiy3Z0Wvf4 pmGx0wcGbNKI+6V748jZ9GbpeBJcUobBAm+mJ8HLJxIOvJOlYN4d6zGbgS18 yZ6KXEyCivVKJx4dPreRS+jlmg1FLSyLKCmhp91oaFGr5L0D04dEEKJIXaAT Sf1p7XmpsN+8XLG34mi7Vs3XPWRwHHFkOWDHHGdu3CKoQdKj+4RqoD56F4n+ REEQMTvp1E6z3DhnAfNBVbejmyBABJdGEUT01H2pQJL5Si+k2lDjhiJMa1xA G7IrDqnU0JgNjs6UF+luzsHqXS9Li11pJ/wVcMwyZRndg/yYidhsr/VEBrne 2TbbWihmueqR/bI7vyYOyluD5Sri50ZTokL+JaFRWjxBg2c2w8ybQcMz71jb QClyVWVjIJ5DYntO9RogJxFJU4bnSOOxvqRP6E6cXkrb98CZcqIuxdmSII/y wZP/M2yxrJhcR3dPbiq7NhD/ysgGgPeE4U8WVLip6QIJ6d9pYC0+eG+73O3R I4HqRJ7+chJPCu/H6+lukK5kWuowZ0dm4Ok3kLkwq18v+ZifZEoUx4EsljRQ 1WuGKKIIXD6J7fNMB1Ji+hV7LCFmGuv67D5/BdEy2Rth/R0VOII+oSFXdUkT v49GQOGYALqHPIT2nJhICbYWZsZWbw5L/g/MP4jExkn0SJ9AmUJzo1s1R46I h+iwg51KZpxTUuegkEXG8m6N29wGUjuacvEYavKqQOfNThL/wXguI6kwkAan 6mu1evDFwL8J0LB0pF1wYH3J/ZnPAEEMBUMurel4wgA03KBpYh21iT75UCTE 8TFr3h757sIUDBQTLeulct3ders2EZU5/ZLEcU4FrFJIL/pbGiwjvIdn4Kmj C3J/0cX/ptGInFlsqVg3CEf5DzaySyOzBvKXByUMzIkIHGRjIfrdr5IsPIor jrSbtJzLuQBXdXLCBENb2WHg6QOrV7Ke7wNtx9ozkOgTt9x36t4nazI687fH CtpkskbyciWn+ZKV3Q018QAlQAEbT9IfcYehZMm1E+6CCssPMeY6+6KRLwi2 UnxdjFJHfTxTZaELr3HexqHyO1KiYZjZ2nrGgiPqKqpqpEUh/1S5WkGYX5b6 +TkZ9SvMjBbMIWvQIEc4HlgQpKpwwd6p69zH5Wi398e7SzFKKg/WSKUJPgDU 7OYLs7fdeKbK10rnbbz1zOhS+ZyZ76L+JuQv3q9Hc137kDqNee27LLw3Cafr z9IA4Cw1urkRi2+OgtStuxHymP5s+Yreaxvc3GUhOwvaJqg2DdLr1Aq/YSZ9 7ga16rsE0CbiouuBmUafsxrabL7zc5VSEfeBdQg5HB7T8l4loMSyjQynpA5S uYRubTFBRtzSPp5MYGcL4hUEp+cHMVCX2aQdX6rtSQU9E1r+d68OMQhPALte c5RaseMh+22af2ByyYjTDAD5RNEJ1xYFvLblBifIZB7T/cuhlkZ6nOaZb0BX b72mFJJc9+fbCfydyFKWDXkHlspxCe0XJEVYjBuYKySvncn0ANLtPT6qsbFJ eU7U2wNcNRe/GlUcG+3L+ysYyjRX6hNFOsTu89G7+MTnvnwXmX7cKd/XwYuQ 4vC7zHFt1DnRlyliVCLRk1i7caqYNYk1GY2mXGS95XBFOhdQMR0lmWibQbB8 iH+FIAG+9ABPW9jAKriTPAg8nCbTi13DCSnBS5VTsP8bm0FeF2l6gVQ2gvz0 La75Ob06LVTCoz9NkP9njUaX39J7wCdJfy3fiWuR/OQ7UFJ15/jXXEHbDOqU Ok936UFSWIX0JjNknw0kO7Md9zzPY5uko7ZROXipV59160dCi0I/290E+Jyg LTTuK2emr3JgORsAoGpBZlJ0rKGPJd3mjGhzT87sU0mQeUtD1YqwAbQ/u5J4 v7N26fithAAAVDipnIZeg3gAAeeiAYmtBVBCaP+xxGf7AgAAAAAEWVo= --2628712688-1682217377-1358859185=:48971-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 15:43:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA0BAE33 for ; Tue, 22 Jan 2013 15:43:53 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id A26CCE63 for ; Tue, 22 Jan 2013 15:43:53 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,515,1355126400"; d="scan'208";a="5840208" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 22 Jan 2013 07:43:46 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0MFhkgP012952 for ; Tue, 22 Jan 2013 07:43:46 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0328.009; Tue, 22 Jan 2013 07:43:46 -0800 From: "Eggert, Lars" To: "freebsd-net@freebsd.org" Subject: Data Center Bridging? Thread-Topic: Data Center Bridging? Thread-Index: AQHN+LdDgifA/mtK/UqYvtRGZs2iTA== Date: Tue, 22 Jan 2013 15:43:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <534BA229F27EC34CA2945A6A22A57D53@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 15:43:53 -0000 Hi, on Linux, various NICs (e.g., ixgbe) support Data Center Bridging. Is this = also available under FreeBSD? Do *any* NICs support DCB under FreeBSD? Thanks, Lars= From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 16:32:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0D93ED7 for ; Tue, 22 Jan 2013 16:32:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 893E2186 for ; Tue, 22 Jan 2013 16:32:35 +0000 (UTC) Received: from jre-mbp-2.int.fusionio.com ([216.51.42.66]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r0MGWIPW073427 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Jan 2013 08:32:28 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50FEBF0C.6050307@freebsd.org> Date: Tue, 22 Jan 2013 09:32:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: Data Center Bridging? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 16:32:35 -0000 On 1/22/13 8:43 AM, Eggert, Lars wrote: > Hi, > > on Linux, various NICs (e.g., ixgbe) support Data Center Bridging. Is this also available under FreeBSD? Do *any* NICs support DCB under FreeBSD? > > Thanks, > Lars > _______________________________________________ > 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" > that really depends on what you want to do given a freebsd command line and a kernel with the right options I could probably bridge two networks in about 15 minutes. (I have done it in the past). if DCB is a specific protocol then we may need to do some work to support it. as I've not heard of it. From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 16:40:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1B1D23E for ; Tue, 22 Jan 2013 16:40:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A75EC206 for ; Tue, 22 Jan 2013 16:40:49 +0000 (UTC) Received: from jre-mbp-2.int.fusionio.com ([216.51.42.66]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r0MGems9073460 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Jan 2013 08:40:48 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50FEC109.5080601@freebsd.org> Date: Tue, 22 Jan 2013 09:40:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: Data Center Bridging? References: <50FEBF0C.6050307@freebsd.org> In-Reply-To: <50FEBF0C.6050307@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "Vogel, Jack" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 16:40:49 -0000 On 1/22/13 9:32 AM, Julian Elischer wrote: > On 1/22/13 8:43 AM, Eggert, Lars wrote: >> Hi, >> >> on Linux, various NICs (e.g., ixgbe) support Data Center Bridging. >> Is this also available under FreeBSD? Do *any* NICs support DCB >> under FreeBSD? >> >> Thanks, >> Lars >> _______________________________________________ >> 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" >> > that really depends on what you want to do > given a freebsd command line and a kernel with the right options I > could probably bridge two networks in about 15 minutes. > (I have done it in the past). > if DCB is a specific protocol then we may need to do some work to > support it. as I've not heard of it. google to the answer. I have not seen any support for that. I would check with the driver writers from intel and/or broadcom etc. (they should be here somewhere). Jack? > > > _______________________________________________ > 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 Jan 22 16:57:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9809B60D for ; Tue, 22 Jan 2013 16:57:04 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 35B372FE for ; Tue, 22 Jan 2013 16:57:03 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h16so7443665oag.5 for ; Tue, 22 Jan 2013 08:57:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=SVunTNh3eNKzmxtCjb3Iwjotp8e5JF6y2QCqCqQ0oiU=; b=bJvmJT1ngvVjP9OgxoTqBN4n+DR4bsoHdVnAXwUZOBWah/v2S/0GCj4unL9p5ltpO4 MXmnn1BhwrjDmjY/++ATVMJjtkD1bA9QjtLppnwe37OnJAYsApQLwoR1unY/BMM0SdhV 1OOOIJ9xoHbMTWUXO1kKkz2zdsmH++ZbqsYneAECEb9NtSuvmOVja+QFhN4SBwDI0tsB YhpAfmnQzPCoZUN01LA1u2uGyYB/O7AMLuJYXlFB8F7LZ10awOoi8JStrO9lqhC41LSn l2VEW2m5WkIJkznlR33SjBE96YRf6m3brciHfofpcuXBf8Oj+N/4A9sfv4lHSO2c7uPn JeAA== X-Received: by 10.182.78.228 with SMTP id e4mr17365339obx.77.1358873822966; Tue, 22 Jan 2013 08:57:02 -0800 (PST) Received: from [172.21.0.61] (24-155-177-88.dyn.grandenetworks.net. [24.155.177.88]) by mx.google.com with ESMTPS id go17sm13373935obc.15.2013.01.22.08.57.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jan 2013 08:57:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Data Center Bridging? From: Jim Thompson In-Reply-To: <50FEBF0C.6050307@freebsd.org> Date: Tue, 22 Jan 2013 10:57:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9A51F061-46CD-450C-ABE4-C1E29AB816F6@netgate.com> References: <50FEBF0C.6050307@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmLmEzS/nhrGLjFat04lB+u3GIaAjVeAJsqCsNY8CmrBml9oPjiwk38PUTTIr3iu3uBRTjr Cc: "freebsd-net@freebsd.org" , "Eggert, Lars" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 16:57:04 -0000 On Jan 22, 2013, at 10:32 AM, Julian Elischer = wrote: > On 1/22/13 8:43 AM, Eggert, Lars wrote: >> Hi, >>=20 >> on Linux, various NICs (e.g., ixgbe) support Data Center Bridging. Is = this also available under FreeBSD? Do *any* NICs support DCB under = FreeBSD? >>=20 >> Thanks, >> Lars >> _______________________________________________ >> 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 > that really depends on what you want to do > given a freebsd command line and a kernel with the right options I = could probably bridge two networks in about 15 minutes. > (I have done it in the past). > if DCB is a specific protocol then we may need to do some work to = support it. as I've not heard of it. DCB is yet another attempt to 'fix' Ethernet, by eliminating queue = overflow and providing bandwidth allocation on individual links. It was intended to be mostly about storage. Linux uses lldpad and dcbtool to manage the settings. Jim From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 17:14:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DFBA83CE; Tue, 22 Jan 2013 17:14:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD6016A5; Tue, 22 Jan 2013 17:14:58 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 349B1B96B; Tue, 22 Jan 2013 12:14:58 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Date: Tue, 22 Jan 2013 12:12:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <1358610450.75691.YahooMailClassic@web121604.mail.ne1.yahoo.com> <201301191114.29959.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301221212.16628.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Jan 2013 12:14:58 -0500 (EST) Cc: Barney Cordoba , Luigi Rizzo , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 17:14:58 -0000 On Saturday, January 19, 2013 8:19:19 pm Adrian Chadd wrote: > On 19 January 2013 08:14, John Baldwin wrote: > > > However, I did describe an alternate setup where you can fix this. Part of > > the key is to get various NICs to share a single logical queue of tasks. You > > could simulate this now by having all the deferred tasks share a single > > taskqueue with a pool of tasks, but that will still not fully cooperate with > > ithreads. To do that you have to get the interrupt handlers themselves into > > the shared taskqueue. Some changes I have in a p4 branch allow you to do that > > by letting interrupt handlers reschedule themselves (avoiding the need for a > > separate task and preventing the task from running concurrently with the > > interrupt handler) and providing some (but not yet all) of the framework to > > allow multiple devices to share a single work queue backed by a shared pool of > > threads. > > How would that work when I want to pin devices to specific cores? Note that the setup allows you to bind things however you want. By default it uses the current model (each IRQ uses a dedicated queue with a single thread). The idea is to provide the flexbility so that you can glue things together in whatever way makes the most sense. In a router that tends to get into livelock using a shared queue may make more sense. However, you are not forced to use that for other workloads where it does not. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 17:15:00 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 137D7410; Tue, 22 Jan 2013 17:15:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E59F76A8; Tue, 22 Jan 2013 17:14:59 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 63E2AB953; Tue, 22 Jan 2013 12:14:59 -0500 (EST) From: John Baldwin To: Alexander Leidinger Subject: Re: [PATCH] Properly handle Linux TCP socket options Date: Tue, 22 Jan 2013 12:14:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301191126.13257.jhb@freebsd.org> <20130121205522.00006f38@unknown> In-Reply-To: <20130121205522.00006f38@unknown> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301221214.15173.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Jan 2013 12:14:59 -0500 (EST) Cc: emulation@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 17:15:00 -0000 On Monday, January 21, 2013 2:55:22 pm Alexander Leidinger wrote: > On Sat, 19 Jan 2013 11:26:13 -0500 John Baldwin wrote: > > > The current setsockopt() wrapper for the Linux ABI claims that Linux > > and FreeBSD use the same values for TCP socket options. This is true > > for TCP_NODELAY and TCP_MAXSEG but not for any other options. This > > patch adds a mapping routine for TCP options similar to that used for > > other socket option levels. I believe this mapping to be correct in > > terms of which FreeBSD options have the same semantics as Linux > > options based on comparing code in the two kernels, but I'm not 100% > > certain about TCP_MD5SIG since the Linux code that it maps to is not > > as clear (it calls some function pointer and it is not clear if it is > > accepting a simple boolean value similar to FreeBSD's). > > What about a message for unknown options? We do not do that now for any options (socket level or otherwise). You could easily add that in linux_setsockopt(), but that should be a separate commit. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 17:20:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 50180D9D for ; Tue, 22 Jan 2013 17:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 21702757 for ; Tue, 22 Jan 2013 17:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0MHK1Zd009746 for ; Tue, 22 Jan 2013 17:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0MHK12i009745; Tue, 22 Jan 2013 17:20:01 GMT (envelope-from gnats) Date: Tue, 22 Jan 2013 17:20:01 GMT Message-Id: <201301221720.r0MHK12i009745@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:20:01 -0000 The following reply was made to PR kern/172113; it has been noted by GNATS. From: John Baldwin To: Jack Vogel Cc: "George Neville-Neil" , bug-followup@freebsd.org, egrosbein@rdtc.ru, jfv@freebsd.org Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Date: Tue, 22 Jan 2013 12:09:32 -0500 On Monday, January 21, 2013 3:28:40 pm Jack Vogel wrote: > Well, do you have a more complete designation of the motherboard? We can > look into it, although if the one check stops the problem it may be a low > priority. It is a SuperMicro X8DTU-F. > Jack > > > On Mon, Jan 21, 2013 at 11:25 AM, George Neville-Neil wrote: > > > > > On Jan 19, 2013, at 23:26 , John Baldwin wrote: > > > > > I was able to finally reproduce this panic today. It seems to require > > > a server configured for PXE but that receives no DHCP reply (and > > > possibly with the requisite SuperMicro X8 board). I was able to > > > prevent the panic with a subset of the referenced patch by only adding > > > the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of > > > igb_msix_que(). The rest of the patch was unnecessary. I also added > > > some debugging to print out the ICR, EICR, IMS, and EIMS registers in > > > this case. It does look like the hardware is sending an interrupt that > > > is not enabled in the interrupt mask (specifically LSC). In fact, the > > > 82576 datasheet specifically mentions masking LSC until initialization > > > is complete to avoid spurious interrupts during boot and AFAICT igb(4) > > > does this since e1000_reset_hw() clears the interrupt mask via writes > > > to IMC and doesn't re-enable interrupts until igb_init_locked() is > > > invoked via 'ifconfig up'. Here is my debug output: > > > > > > SMP: AP CPU #6 Launched! > > > SMP: AP CPU #4 Launched! > > > stray irq0 > > > igb0: interrupt on que 0: icr 0x1000004 eicr 0 > > > ims 0 eims 0x80000000 > > > > > > Hmmm. Nothing clears EIMS. After some more debugging, I determined > > > that e1000_reset_hw() always turns this bit in EIMS on, even if it is > > > off before e1000_reset_hw() is called(!). I added explicit calls to > > > igb_disable_intr() to clear EIMS after each call to e1000_reset_hw(). > > > This removes the 'stray irq0', but I still get a spurious interrupt > > > during boot (albeit with eims 0). I can use the IFF_DRV_RUNNING hack > > > for now, but I think the real fix is something else. > > > > > > > I think Jack will have to chime in on this one. Do you think it's all SM > > X8 boards > > or just the one we happen to have? I wonder if Jack or Jeffrey (the > > testing guy he works > > with) have access to the right board. > > > > Best, > > George > > > > > > > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 18:23:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51B103B2; Tue, 22 Jan 2013 18:23:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id C96A1B07; Tue, 22 Jan 2013 18:23:47 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id l6so5793051vcl.17 for ; Tue, 22 Jan 2013 10:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gENbzfDuBMio3O/WLAHMhcg4Lh2hykhU0tf6W8KHl6Q=; b=r8bYrBnQ8LyTdE/6I0+7nrbji5hc4RN+jAWjum9qrl54sqmRr6BeiM58fZgPkY6bKM v0ZXtKaxhx5LZWpHlb+0CjjkCoPjVrbKRlxB236fb2Kjb34BVpdV31RSpgj/A+bB5/dm Q0xkBvkQMPvhg7ysH1F4aV5YP7k/GWEFuAY5v8xGG9qDxdCPxMSOGWSVniS/WqPE/Rs5 e/rNZ7VQxGbe69J/1cwQHmCk0Spbrmsp3RSmGx9FURCInc+/y99xy/zBPRkyLMeNK5+P j89eFEXlM7gYgoAyPXg06cB6qh/5BN6ohhhkmGUWq7gKqp63XhJ9jkQn9et1GH8Ze1hL 3L5A== MIME-Version: 1.0 X-Received: by 10.220.219.204 with SMTP id hv12mr24158536vcb.71.1358879020979; Tue, 22 Jan 2013 10:23:40 -0800 (PST) Received: by 10.220.25.13 with HTTP; Tue, 22 Jan 2013 10:23:40 -0800 (PST) In-Reply-To: <50FEC109.5080601@freebsd.org> References: <50FEBF0C.6050307@freebsd.org> <50FEC109.5080601@freebsd.org> Date: Tue, 22 Jan 2013 10:23:40 -0800 Message-ID: Subject: Re: Data Center Bridging? From: Jack Vogel To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "Eggert, Lars" , "Vogel, Jack" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 18:23:48 -0000 On Tue, Jan 22, 2013 at 8:40 AM, Julian Elischer wrote: > On 1/22/13 9:32 AM, Julian Elischer wrote: > >> On 1/22/13 8:43 AM, Eggert, Lars wrote: >> >>> Hi, >>> >>> on Linux, various NICs (e.g., ixgbe) support Data Center Bridging. Is >>> this also available under FreeBSD? Do *any* NICs support DCB under FreeBSD? >>> >>> Thanks, >>> Lars >>> ______________________________**_________________ >>> 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 >>> " >>> >>> that really depends on what you want to do >> given a freebsd command line and a kernel with the right options I could >> probably bridge two networks in about 15 minutes. >> (I have done it in the past). >> if DCB is a specific protocol then we may need to do some work to support >> it. as I've not heard of it. >> > > google to the answer. > I have not seen any support for that. > I would check with the driver writers from intel and/or broadcom etc. > (they should be here somewhere). > Jack? > > I have never implemented this in the FreeBSD drivers primarily because the motivation for it say, in Linux, was to handle multiple traffic classes, for instance FCOE or iSCSI, but FreeBSD has not had these features to implement this for. Give me a reason to do it, and I can see about adding it :) Jack From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 18:24:00 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1CA4F43B; Tue, 22 Jan 2013 18:24:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 844AEB0A; Tue, 22 Jan 2013 18:23:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0MINmdD036579; Tue, 22 Jan 2013 20:23:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0MINmdD036579 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0MINmlf036578; Tue, 22 Jan 2013 20:23:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Jan 2013 20:23:48 +0200 From: Konstantin Belousov To: Oliver Fromme Subject: Re: Processes' FIBs Message-ID: <20130122182348.GA36551@kib.kiev.ua> References: <201201171221.q0HCLRsh034506@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <201201171221.q0HCLRsh034506@lurza.secnetix.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-net@FreeBSD.ORG, gibbs@freebsd.org, Oliver Fromme , freebsd-hackers@FreeBSD.ORG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 18:24:00 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2012 at 01:21:27PM +0100, Oliver Fromme wrote: > Kostik Belousov wrote: > > The patch misses compat32 bits and breaks compat32 ps/top. >=20 > Right, thank you for pointing it out! I missed it because > I only have i386 for testing. >=20 > I've created new patch sets for releng8 and current. These > include compat32 support and an entry for the manual page. >=20 > Would someone with amd64 please test the compat32 part? > I've been using this code on i386 for a few days without > any problems. >=20 > I've attached the patch for current below. Both patch sets > are also available from this URL: > http://www.secnetix.de/olli/tmp/ki_fibnum/ >=20 > Testing is easy: Apply the patch, rebuild bin/ps and kernel. > Make sure that your kernel config has "options ROUTETABLES=3D16" > so multiple FIBs are supported. Reboot. Open a shell with > setfib, e.g. "setfib 3 /bin/sh" (no root required), type > "ps -ax -o user,pid,fib,command" or something similar, and > verify that the shell process and its children are listed > with the correct FIB. When testing on amd64, use both the > native ps and an i386 binary. >=20 > Thank you very much! >=20 > Best regards > Oliver >=20 > --- sys/sys/user.h.orig 2011-11-07 22:13:19.000000000 +0100 > +++ sys/sys/user.h 2012-01-17 11:33:59.000000000 +0100 > @@ -83,7 +83,7 @@ > * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and > * function kvm_proclist in lib/libkvm/kvm_proc.c . > */ > -#define KI_NSPARE_INT 9 > +#define KI_NSPARE_INT 8 > #define KI_NSPARE_LONG 12 > #define KI_NSPARE_PTR 6 > =20 > @@ -186,6 +186,7 @@ > */ > char ki_sparestrings[50]; /* spare string space */ > int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ > + int ki_fibnum; /* Default FIB number */ > u_int ki_cr_flags; /* Credential flags */ > int ki_jid; /* Process jail ID */ > int ki_numthreads; /* XXXKSE number of threads in total */ > --- sys/kern/kern_proc.c.orig 2012-01-15 19:47:24.000000000 +0100 > +++ sys/kern/kern_proc.c 2012-01-17 12:52:36.000000000 +0100 > @@ -836,6 +836,7 @@ > kp->ki_swtime =3D (ticks - p->p_swtick) / hz; > kp->ki_pid =3D p->p_pid; > kp->ki_nice =3D p->p_nice; > + kp->ki_fibnum =3D p->p_fibnum; > kp->ki_start =3D p->p_stats->p_start; > timevaladd(&kp->ki_start, &boottime); > PROC_SLOCK(p); > @@ -1121,6 +1122,7 @@ > bcopy(ki->ki_comm, ki32->ki_comm, COMMLEN + 1); > bcopy(ki->ki_emul, ki32->ki_emul, KI_EMULNAMELEN + 1); > bcopy(ki->ki_loginclass, ki32->ki_loginclass, LOGINCLASSLEN + 1); > + CP(*ki, *ki32, ki_fibnum); > CP(*ki, *ki32, ki_cr_flags); > CP(*ki, *ki32, ki_jid); > CP(*ki, *ki32, ki_numthreads); > --- sys/compat/freebsd32/freebsd32.h.orig 2011-11-11 08:17:00.000000000 += 0100 > +++ sys/compat/freebsd32/freebsd32.h 2012-01-17 11:34:00.000000000 +0100 > @@ -319,6 +319,7 @@ > char ki_loginclass[LOGINCLASSLEN+1]; > char ki_sparestrings[50]; > int ki_spareints[KI_NSPARE_INT]; > + int ki_fibnum; > u_int ki_cr_flags; > int ki_jid; > int ki_numthreads; > --- bin/ps/keyword.c.orig 2011-09-29 08:31:42.000000000 +0200 > +++ bin/ps/keyword.c 2012-01-17 12:54:49.000000000 +0100 > @@ -85,6 +85,7 @@ > {"etimes", "ELAPSED", NULL, USER, elapseds, 0, CHAR, NULL, 0}, > {"euid", "", "uid", 0, NULL, 0, CHAR, NULL, 0}, > {"f", "F", NULL, 0, kvar, KOFF(ki_flag), INT, "x", 0}, > + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, > {"flags", "", "f", 0, NULL, 0, CHAR, NULL, 0}, > {"gid", "GID", NULL, 0, kvar, KOFF(ki_groups), UINT, UIDFMT, 0}, > {"group", "GROUP", NULL, LJUST, egroupname, 0, CHAR, NULL, 0}, > --- bin/ps/ps.1.orig 2011-11-22 22:53:06.000000000 +0100 > +++ bin/ps/ps.1 2012-01-17 12:56:17.000000000 +0100 > @@ -29,7 +29,7 @@ > .\" @(#)ps.1 8.3 (Berkeley) 4/18/94 > .\" $FreeBSD: src/bin/ps/ps.1,v 1.112 2011/11/22 21:53:06 trociny Exp $ > .\" > -.Dd November 22, 2011 > +.Dd January 17, 2012 > .Dt PS 1 > .Os > .Sh NAME > @@ -506,6 +506,9 @@ > minutes:seconds. > .It Cm etimes > elapsed running time, in decimal integer seconds > +.It Cm fib > +default FIB number, see > +.Xr setfib 1 > .It Cm flags > the process flags, in hexadecimal (alias > .Cm f ) Just reviving the recent thread after the ping. The patch looks fine to me, and is still not committed. --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/tkzAAoJEJDCuSvBvK1Bi80P/28DJbyfmQzf9WL8B7bvqkW2 Pw8rsP2jSi23RbOkczbDI1g2CuKUeb6eLJfq7ubAuu+nwnvR4Ue3lY09ntGGGK2G sKbBTH9hMjaAX41Z7zkRDQg/058S00Zd3znaQBQMJJncty3MRg76OhttFP83OENX XEm3HWid9YoNc1zOlMw3fTCDPntuCpZQ3RFUr2Ps0nwEeolYLMZ3+aWYxlDy9Mtj Aw2/wI8rFArTVd9ZF0vd3bdqYkMqmarJr/8VAyIf6nIbaAR0FD5mqkQxzqwLY62k WTBP0tHhY5ZpHjY84S5FFPVE+ecShjWs3FmS1aTVFyk+90UtOyBMSZb3th0AZmCQ PclVx3jgp9ViZNgqgav/nC26GeTKqMxcv8bQYFrJswIxWTZZ1Djm0DcOrglDuPB1 blYiZTmhTHtEa4nfnlbOEXISiWS0iYQoczRZNfZOzX+1+d2L2cc+skVkun7hVUDx SjHyTqIq+BHl9SJ5gFpZldqO7geAc6mDOlUd/L7VSt97FPGp+CY6ErLzC2I14NM3 9sBrfEUmx9qUcI1udTf/b9SMeoPmSPE/DM0ma+bejeg9Yu+xsaDhMe4zE7vaToAG U9lZmRIqGdRR3WeZkDz5pEpk81c96TVkOqA7UBwdzlVi0uEh2JYmJ+piLgyzgYAR vew7p39yNKtXWuXUiNdJ =dxsd -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 18:49:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DAD22F97 for ; Tue, 22 Jan 2013 18:49:47 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by mx1.freebsd.org (Postfix) with ESMTP id AE556DB8 for ; Tue, 22 Jan 2013 18:49:47 +0000 (UTC) Received: by mail-da0-f50.google.com with SMTP id h15so3360051dan.37 for ; Tue, 22 Jan 2013 10:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gtvoWZD6dy3dVThoOqlIovo9ce76UMfcTAKBVDD2yMs=; b=1EUpSug8JnHVAgVja2x2yrhCYIwkXgDfdzk0UVbwXaew/NhcoBG34yL7JoPSwoFwjY xaHVKJofszbwRgRBvk88EqH6Qe/9qOJv0t1dbwAdp+J6tFVXedjokIkvkNyhOgc7mC5S dLJjrjwYN2oZgA72iiQhk0oxZ67pCCN2Z6KlDwTLjMvhyuO1QRMZXU1FHJTAPzVLPsrP YzAKgNJ1yaKb4TLpSqbMdBClk2B11uIvogceOME1EyhPNniAWVCY/Dshl1FSzTNCSHDN xHapvJASuYf3pvxoFgHDWzksYBVik224w4Z0M9xfe1IbibwrQOkwRNJEEUYGVM6SuIsK wccA== X-Received: by 10.68.135.133 with SMTP id ps5mr60143229pbb.132.1358880581018; Tue, 22 Jan 2013 10:49:41 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id rq7sm11177705pbc.69.2013.01.22.10.49.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jan 2013 10:49:39 -0800 (PST) Message-ID: <50FEDF3A.60806@gmail.com> Date: Tue, 22 Jan 2013 10:49:30 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130115 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: Data Center Bridging? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 18:49:47 -0000 On 01/22/13 07:43, Eggert, Lars wrote: > Hi, > > on Linux, various NICs (e.g., ixgbe) support Data Center Bridging. Is this also available under FreeBSD? Do *any* NICs support DCB under FreeBSD? cxgbe(4) hardware supports DCB/DCBX, but I haven't looked at what it would take to add driver + OS support. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 20:11:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 936BAC7C for ; Tue, 22 Jan 2013 20:11:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3EFAC10E for ; Tue, 22 Jan 2013 20:11:10 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8572EB96E for ; Tue, 22 Jan 2013 15:11:08 -0500 (EST) From: John Baldwin To: net@freebsd.org Subject: [PATCH] Add a new TCP_IGNOREIDLE socket option Date: Tue, 22 Jan 2013 15:11:02 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301221511.02496.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Jan 2013 15:11:09 -0500 (EST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 20:11:10 -0000 As I mentioned in an earlier thread, I recently had to debug an issue we were seeing across a link with a high bandwidth-delay product (both high bandwidth and high RTT). Our specific use case was to use a TCP connection to reliably forward a latency-sensitive datagram stream across a WAN connection. We would often see spikes in the latency of individual datagrams. I eventually tracked this down to the connection entering slow start when it would transmit data after being idle. The data stream was quite bursty and would often attempt to transmit a burst of data after being idle for far longer than a retransmit timeout. In 7.x we had worked around this in the past by disabling RFC 3390 and jacking the slow start window size up via a sysctl. On 8.x this no longer worked. The solution I came up with was to add a new socket option to disable idle handling completely. That is, when an idle connection restarts with this new option enabled, it keeps its current congestion window and doesn't enter slow start. There are only a few cases where such an option is useful, but if anyone else thinks this might be useful I'd be happy to add the option to FreeBSD. Index: share/man/man4/tcp.4 =================================================================== --- share/man/man4/tcp.4 (revision 245742) +++ share/man/man4/tcp.4 (working copy) @@ -205,6 +205,18 @@ in the .Sx MIB Variables section further down. +.It Dv TCP_IGNOREIDLE +If a TCP connection is idle for more than one retransmit timeout, +it enters slow start when new data is available to transmit. +This avoids flooding the network with a full window of traffic at line rate. +It also allows the connection to adjust to changes to network conditions +that occurred while the connection was idle. A connection that sends +bursts of data separated by large idle periods can be permamently stuck in +slow start as a result. +The boolean option +.Dv TCP_IGNOREIDLE +disables the idle connection handling allowing connections to maintain the +existing congestion window when restarting after an idle period. .It Dv TCP_NODELAY Under most circumstances, .Tn TCP Index: sys/netinet/tcp_var.h =================================================================== --- sys/netinet/tcp_var.h (revision 245742) +++ sys/netinet/tcp_var.h (working copy) @@ -230,6 +230,7 @@ #define TF_NEEDFIN 0x000800 /* send FIN (implicit state) */ #define TF_NOPUSH 0x001000 /* don't push */ #define TF_PREVVALID 0x002000 /* saved values for bad rxmit valid */ +#define TF_IGNOREIDLE 0x004000 /* connection is never idle */ #define TF_MORETOCOME 0x010000 /* More data to be appended to sock */ #define TF_LQ_OVERFLOW 0x020000 /* listen queue overflow */ #define TF_LASTIDLE 0x040000 /* connection was previously idle */ Index: sys/netinet/tcp_output.c =================================================================== --- sys/netinet/tcp_output.c (revision 245742) +++ sys/netinet/tcp_output.c (working copy) @@ -206,7 +206,8 @@ * to send, then transmit; otherwise, investigate further. */ idle = (tp->t_flags & TF_LASTIDLE) || (tp->snd_max == tp->snd_una); - if (idle && ticks - tp->t_rcvtime >= tp->t_rxtcur) + if (!(tp->t_flags & TF_IGNOREIDLE) && + idle && ticks - tp->t_rcvtime >= tp->t_rxtcur) cc_after_idle(tp); tp->t_flags &= ~TF_LASTIDLE; if (idle) { Index: sys/netinet/tcp.h =================================================================== --- sys/netinet/tcp.h (revision 245823) +++ sys/netinet/tcp.h (working copy) @@ -156,6 +156,7 @@ #define TCP_NODELAY 1 /* don't delay send to coalesce packets */ #if __BSD_VISIBLE #define TCP_MAXSEG 2 /* set maximum segment size */ +#define TCP_IGNOREIDLE 3 /* disable idle connection handling */ #define TCP_NOPUSH 4 /* don't push last block of write */ #define TCP_NOOPT 8 /* don't use TCP options */ #define TCP_MD5SIG 16 /* use MD5 digests (RFC2385) */ Index: sys/netinet/tcp_usrreq.c =================================================================== --- sys/netinet/tcp_usrreq.c (revision 245742) +++ sys/netinet/tcp_usrreq.c (working copy) @@ -1354,6 +1354,7 @@ case TCP_NODELAY: case TCP_NOOPT: + case TCP_IGNOREIDLE: INP_WUNLOCK(inp); error = sooptcopyin(sopt, &optval, sizeof optval, sizeof optval); @@ -1368,6 +1369,9 @@ case TCP_NOOPT: opt = TF_NOOPT; break; + case TCP_IGNOREIDLE: + opt = TF_IGNOREIDLE; + break; default: opt = 0; /* dead code to fool gcc */ break; @@ -1578,6 +1582,11 @@ INP_WUNLOCK(inp); error = sooptcopyout(sopt, buf, TCP_CA_NAME_MAX); break; + case TCP_IGNOREIDLE: + optval = tp->t_flags & TF_IGNOREIDLE; + INP_WUNLOCK(inp); + error = sooptcopyout(sopt, &optval, sizeof optval); + break; default: INP_WUNLOCK(inp); error = ENOPROTOOPT; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 20:35:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8423BFA2; Tue, 22 Jan 2013 20:35:44 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 73D58210; Tue, 22 Jan 2013 20:35:44 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 95D541A3D83; Tue, 22 Jan 2013 12:35:41 -0800 (PST) Message-ID: <50FEF81C.1070002@mu.org> Date: Tue, 22 Jan 2013 12:35:40 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> In-Reply-To: <201301221511.02496.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 20:35:44 -0000 On 1/22/13 12:11 PM, John Baldwin wrote: > As I mentioned in an earlier thread, I recently had to debug an issue we were > seeing across a link with a high bandwidth-delay product (both high bandwidth > and high RTT). Our specific use case was to use a TCP connection to reliably > forward a latency-sensitive datagram stream across a WAN connection. We would > often see spikes in the latency of individual datagrams. I eventually tracked > this down to the connection entering slow start when it would transmit data > after being idle. The data stream was quite bursty and would often attempt to > transmit a burst of data after being idle for far longer than a retransmit > timeout. > > In 7.x we had worked around this in the past by disabling RFC 3390 and jacking > the slow start window size up via a sysctl. On 8.x this no longer worked. > The solution I came up with was to add a new socket option to disable idle > handling completely. That is, when an idle connection restarts with this new > option enabled, it keeps its current congestion window and doesn't enter slow > start. > > There are only a few cases where such an option is useful, but if anyone else > thinks this might be useful I'd be happy to add the option to FreeBSD. This looks good, but it almost sounds like a bug for TCP to be doing this anyhow. Why would one want this behavior? Wouldn't it make sense to keep the window large until there was a problem rather than unconditionally chop it down? I almost think TCP is afraid that you might wind up swapping out a 10gig interface for a modem? I'm just not getting it. (probably simple oversight on my part). What do you think about also making this a sysctl for global on/off by default? -Alfred > > Index: share/man/man4/tcp.4 > =================================================================== > --- share/man/man4/tcp.4 (revision 245742) > +++ share/man/man4/tcp.4 (working copy) > @@ -205,6 +205,18 @@ > in the > .Sx MIB Variables > section further down. > +.It Dv TCP_IGNOREIDLE > +If a TCP connection is idle for more than one retransmit timeout, > +it enters slow start when new data is available to transmit. > +This avoids flooding the network with a full window of traffic at line rate. > +It also allows the connection to adjust to changes to network conditions > +that occurred while the connection was idle. A connection that sends > +bursts of data separated by large idle periods can be permamently stuck in > +slow start as a result. > +The boolean option > +.Dv TCP_IGNOREIDLE > +disables the idle connection handling allowing connections to maintain the > +existing congestion window when restarting after an idle period. > .It Dv TCP_NODELAY > Under most circumstances, > .Tn TCP > Index: sys/netinet/tcp_var.h > =================================================================== > --- sys/netinet/tcp_var.h (revision 245742) > +++ sys/netinet/tcp_var.h (working copy) > @@ -230,6 +230,7 @@ > #define TF_NEEDFIN 0x000800 /* send FIN (implicit state) */ > #define TF_NOPUSH 0x001000 /* don't push */ > #define TF_PREVVALID 0x002000 /* saved values for bad rxmit valid */ > +#define TF_IGNOREIDLE 0x004000 /* connection is never idle */ > #define TF_MORETOCOME 0x010000 /* More data to be appended to sock */ > #define TF_LQ_OVERFLOW 0x020000 /* listen queue overflow */ > #define TF_LASTIDLE 0x040000 /* connection was previously idle */ > Index: sys/netinet/tcp_output.c > =================================================================== > --- sys/netinet/tcp_output.c (revision 245742) > +++ sys/netinet/tcp_output.c (working copy) > @@ -206,7 +206,8 @@ > * to send, then transmit; otherwise, investigate further. > */ > idle = (tp->t_flags & TF_LASTIDLE) || (tp->snd_max == tp->snd_una); > - if (idle && ticks - tp->t_rcvtime >= tp->t_rxtcur) > + if (!(tp->t_flags & TF_IGNOREIDLE) && > + idle && ticks - tp->t_rcvtime >= tp->t_rxtcur) > cc_after_idle(tp); > tp->t_flags &= ~TF_LASTIDLE; > if (idle) { > Index: sys/netinet/tcp.h > =================================================================== > --- sys/netinet/tcp.h (revision 245823) > +++ sys/netinet/tcp.h (working copy) > @@ -156,6 +156,7 @@ > #define TCP_NODELAY 1 /* don't delay send to coalesce packets */ > #if __BSD_VISIBLE > #define TCP_MAXSEG 2 /* set maximum segment size */ > +#define TCP_IGNOREIDLE 3 /* disable idle connection handling */ > #define TCP_NOPUSH 4 /* don't push last block of write */ > #define TCP_NOOPT 8 /* don't use TCP options */ > #define TCP_MD5SIG 16 /* use MD5 digests (RFC2385) */ > Index: sys/netinet/tcp_usrreq.c > =================================================================== > --- sys/netinet/tcp_usrreq.c (revision 245742) > +++ sys/netinet/tcp_usrreq.c (working copy) > @@ -1354,6 +1354,7 @@ > > case TCP_NODELAY: > case TCP_NOOPT: > + case TCP_IGNOREIDLE: > INP_WUNLOCK(inp); > error = sooptcopyin(sopt, &optval, sizeof optval, > sizeof optval); > @@ -1368,6 +1369,9 @@ > case TCP_NOOPT: > opt = TF_NOOPT; > break; > + case TCP_IGNOREIDLE: > + opt = TF_IGNOREIDLE; > + break; > default: > opt = 0; /* dead code to fool gcc */ > break; > @@ -1578,6 +1582,11 @@ > INP_WUNLOCK(inp); > error = sooptcopyout(sopt, buf, TCP_CA_NAME_MAX); > break; > + case TCP_IGNOREIDLE: > + optval = tp->t_flags & TF_IGNOREIDLE; > + INP_WUNLOCK(inp); > + error = sooptcopyout(sopt, &optval, sizeof optval); > + break; > default: > INP_WUNLOCK(inp); > error = ENOPROTOOPT; > From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 20:56:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF34898E for ; Tue, 22 Jan 2013 20:56:58 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront3.g2host.com [208.42.184.241]) by mx1.freebsd.org (Postfix) with ESMTP id 517F62D1 for ; Tue, 22 Jan 2013 20:56:57 +0000 (UTC) Received: from [173.17.248.27] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 94767322 for freebsd-net@freebsd.org; Tue, 22 Jan 2013 14:46:51 -0600 Message-ID: <50FEFAB8.1070006@visi.com> Date: Tue, 22 Jan 2013 14:46:48 -0600 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Cas driver fails to load first time after boot. X-Is-From-Me: yes Content-Type: multipart/mixed; boundary="------------030400010508050204050003" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 20:56:59 -0000 This is a multi-part message in MIME format. --------------030400010508050204050003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've got a Dell R200 which I'm trying to build into a gateway with a Sun QGE (501-6738-10). The cas driver fails to load the first time I try to load it but succeeds the second time. Is this a problem with the card, the driver, my karma? Initially, tried to install FreeBSD-9.1- Release but booting the installation DVD hangs after failing to attach cas0. I was able to successfully install FreeBSD-8.3-Release which apparently does not have the cas driver built into the installer kernel. The first time I try to load the cas module after booting results in the following output: # kldload -v if_cas Loaded if_cas, id=2 with the following logged to /var/log/messages: Jan 22 13:48:27 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 22 13:48:27 lucid kernel: cas0: attaching PHYs failed Jan 22 13:48:27 lucid kernel: cas0: could not be attached Jan 22 13:48:27 lucid kernel: device_attach: cas0 attach returned 6 Jan 22 13:48:27 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 22 13:48:27 lucid kernel: cas1: attaching PHYs failed Jan 22 13:48:28 lucid kernel: cas1: could not be attached Jan 22 13:48:28 lucid kernel: device_attach: cas1 attach returned 6 Jan 22 13:48:28 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 22 13:48:28 lucid kernel: miibus2: on cas2 Jan 22 13:48:28 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 22 13:48:28 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master,auto, auto-flow Jan 22 13:48:28 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 22 13:48:28 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 22 13:48:28 lucid kernel: cas2: [FILTER] Jan 22 13:48:28 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 22 13:48:28 lucid kernel: cas3: attaching PHYs failed Jan 22 13:48:28 lucid kernel: cas3: could not be attached Jan 22 13:48:28 lucid kernel: device_attach: cas3 attach returned 6 If I unload the cas driver, I get the following in /var/log/messages: Jan 22 14:03:42 lucid kernel: nsgphy0: detached Jan 22 14:03:42 lucid kernel: miibus2: detached Jan 22 14:03:42 lucid kernel: cas2: detached Jan 22 14:03:42 lucid kernel: pci4: at device 2.0 (no driver attached) The second time I try to load the cas kernel module after booting results in the following output: # kldload -v if_cas Loaded if_cas, id=2 and the following logged to /var/log/messages: Jan 22 14:04:33 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 22 14:04:33 lucid kernel: miibus2: on cas0 Jan 22 14:04:33 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 22 14:04:33 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master,auto, auto-flow Jan 22 14:04:33 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:04:33 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 22 14:04:33 lucid kernel: cas0: [FILTER] Jan 22 14:04:33 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 22 14:04:33 lucid kernel: miibus3: on cas1 Jan 22 14:04:33 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 22 14:04:33 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master,auto, auto-flow Jan 22 14:04:33 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:04:33 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 22 14:04:33 lucid kernel: cas1: [FILTER] Jan 22 14:04:33 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 22 14:04:33 lucid kernel: miibus4: on cas2 Jan 22 14:04:33 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 22 14:04:33 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master,auto, auto-flow Jan 22 14:04:33 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:04:33 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 22 14:04:33 lucid kernel: cas2: [FILTER] Jan 22 14:04:33 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 22 14:04:33 lucid kernel: miibus5: on cas3 Jan 22 14:04:33 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 22 14:04:33 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master,auto, auto-flow Jan 22 14:04:33 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:04:33 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 22 14:04:33 lucid kernel: cas3: [FILTER] The following are attached: /var/run/dmesg.boot dmesg output after the second attempt to load the cas driver. /var/log/messages after the second attemp to load the cas driver. -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 --------------030400010508050204050003 Content-Type: text/plain; charset=us-ascii; name="dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4099231744 (3909 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 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 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 2.0 on pci3 pci4: on pcib4 pci4: at device 0.0 (no driver attached) pci4: at device 1.0 (no driver attached) pci4: at device 2.0 (no driver attached) pci4: at device 3.0 (no driver attached) pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:19:b9:fa:82:51 bge0: [ITHREAD] pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:19:b9:fa:82:52 bge1: [ITHREAD] uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib7: at device 30.0 on pci0 pci7: on pcib7 vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: at channel 0 on atapci0 ata2: [ITHREAD] ata3: at channel 1 on atapci0 ata3: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x7f irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 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: 480Mbps High Speed USB v2.0 ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s 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 acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 uhub4: on usbus3 uhub4: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ad4s1a --------------030400010508050204050003 Content-Type: text/plain; charset=us-ascii; name="dmesg.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4099231744 (3909 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 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 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 2.0 on pci3 pci4: on pcib4 pci4: at device 0.0 (no driver attached) pci4: at device 1.0 (no driver attached) pci4: at device 2.0 (no driver attached) pci4: at device 3.0 (no driver attached) pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:19:b9:fa:82:51 bge0: [ITHREAD] pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:19:b9:fa:82:52 bge1: [ITHREAD] uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib7: at device 30.0 on pci0 pci7: on pcib7 vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: at channel 0 on atapci0 ata2: [ITHREAD] ata3: at channel 1 on atapci0 ata3: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x7f irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 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: 480Mbps High Speed USB v2.0 ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s 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 acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 uhub4: on usbus3 uhub4: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ad4s1a bge0: link state changed to UP cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 miibus2: on cas0 nsgphy0: PHY 1 on miibus2 nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas0: 16kB RX FIFO, 9kB TX FIFO cas0: Ethernet address: 00:14:4f:25:ca:10 cas0: [FILTER] cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 miibus3: on cas1 nsgphy1: PHY 1 on miibus3 nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas1: 16kB RX FIFO, 9kB TX FIFO cas1: Ethernet address: 00:14:4f:25:ca:11 cas1: [FILTER] cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 miibus4: on cas2 nsgphy2: PHY 1 on miibus4 nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas2: 16kB RX FIFO, 9kB TX FIFO cas2: Ethernet address: 00:14:4f:25:ca:12 cas2: [FILTER] cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 miibus5: on cas3 nsgphy3: PHY 1 on miibus5 nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas3: 16kB RX FIFO, 9kB TX FIFO cas3: Ethernet address: 00:14:4f:25:ca:13 cas3: [FILTER] nsgphy0: detached miibus2: detached cas0: detached pci4: at device 0.0 (no driver attached) nsgphy1: detached miibus3: detached cas1: detached pci4: at device 1.0 (no driver attached) nsgphy2: detached miibus4: detached cas2: detached pci4: at device 2.0 (no driver attached) nsgphy3: detached miibus5: detached cas3: detached pci4: at device 3.0 (no driver attached) cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 miibus2: on cas0 nsgphy0: PHY 1 on miibus2 nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas0: 16kB RX FIFO, 9kB TX FIFO cas0: Ethernet address: 00:14:4f:25:ca:10 cas0: [FILTER] cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 miibus3: on cas1 nsgphy1: PHY 1 on miibus3 nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas1: 16kB RX FIFO, 9kB TX FIFO cas1: Ethernet address: 00:14:4f:25:ca:11 cas1: [FILTER] cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 miibus4: on cas2 nsgphy2: PHY 1 on miibus4 nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas2: 16kB RX FIFO, 9kB TX FIFO cas2: Ethernet address: 00:14:4f:25:ca:12 cas2: [FILTER] cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 miibus5: on cas3 nsgphy3: PHY 1 on miibus5 nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas3: 16kB RX FIFO, 9kB TX FIFO cas3: Ethernet address: 00:14:4f:25:ca:13 cas3: [FILTER] --------------030400010508050204050003 Content-Type: text/plain; charset=us-ascii; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages" Jan 22 14:09:35 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 22 14:09:35 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 22 14:09:35 lucid kernel: The Regents of the University of California. All rights reserved. Jan 22 14:09:35 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 22 14:09:35 lucid kernel: FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012 Jan 22 14:09:35 lucid kernel: root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Jan 22 14:09:35 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 22 14:09:35 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 22 14:09:35 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 22 14:09:35 lucid kernel: Features=0xbfebfbff Jan 22 14:09:35 lucid kernel: Features2=0xe3bd Jan 22 14:09:35 lucid kernel: AMD Features=0x20100800 Jan 22 14:09:35 lucid kernel: AMD Features2=0x1 Jan 22 14:09:35 lucid kernel: TSC: P-state invariant Jan 22 14:09:35 lucid kernel: real memory = 4294967296 (4096 MB) Jan 22 14:09:35 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 22 14:09:35 lucid kernel: ACPI APIC Table: Jan 22 14:09:35 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 22 14:09:35 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 22 14:09:35 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 22 14:09:35 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 22 14:09:35 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 22 14:09:35 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 22 14:09:35 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 22 14:09:35 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 22 14:09:35 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 22 14:09:35 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 22 14:09:35 lucid kernel: kbd1 at kbdmux0 Jan 22 14:09:35 lucid kernel: acpi0: on motherboard Jan 22 14:09:35 lucid kernel: acpi0: [ITHREAD] Jan 22 14:09:35 lucid kernel: acpi0: Power Button (fixed) Jan 22 14:09:35 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 22 14:09:35 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 22 14:09:35 lucid kernel: cpu0: on acpi0 Jan 22 14:09:35 lucid kernel: cpu1: on acpi0 Jan 22 14:09:35 lucid kernel: cpu2: on acpi0 Jan 22 14:09:35 lucid kernel: cpu3: on acpi0 Jan 22 14:09:35 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 22 14:09:35 lucid kernel: pci0: on pcib0 Jan 22 14:09:35 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 22 14:09:35 lucid kernel: pci1: on pcib1 Jan 22 14:09:35 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 22 14:09:35 lucid kernel: pci2: on pcib2 Jan 22 14:09:35 lucid kernel: pcib3: at device 0.0 on pci2 Jan 22 14:09:35 lucid kernel: pci3: on pcib3 Jan 22 14:09:35 lucid kernel: pcib4: at device 2.0 on pci3 Jan 22 14:09:35 lucid kernel: pci4: on pcib4 Jan 22 14:09:35 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 22 14:09:35 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 22 14:09:35 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 22 14:09:35 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 22 14:09:35 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 22 14:09:35 lucid kernel: pci5: on pcib5 Jan 22 14:09:35 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 22 14:09:35 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 22 14:09:35 lucid kernel: miibus0: on bge0 Jan 22 14:09:35 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 22 14:09:35 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:09:35 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 22 14:09:35 lucid kernel: bge0: [ITHREAD] Jan 22 14:09:35 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 22 14:09:35 lucid kernel: pci6: on pcib6 Jan 22 14:09:35 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 22 14:09:35 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 22 14:09:35 lucid kernel: miibus1: on bge1 Jan 22 14:09:35 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 22 14:09:35 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:09:35 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 22 14:09:35 lucid kernel: bge1: [ITHREAD] Jan 22 14:09:35 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 22 14:09:35 lucid kernel: uhci0: [ITHREAD] Jan 22 14:09:35 lucid kernel: usbus0: on uhci0 Jan 22 14:09:35 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 22 14:09:35 lucid kernel: uhci1: [ITHREAD] Jan 22 14:09:35 lucid kernel: usbus1: on uhci1 Jan 22 14:09:35 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 22 14:09:35 lucid kernel: uhci2: [ITHREAD] Jan 22 14:09:35 lucid kernel: usbus2: on uhci2 Jan 22 14:09:35 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 22 14:09:35 lucid kernel: ehci0: [ITHREAD] Jan 22 14:09:35 lucid kernel: usbus3: EHCI version 1.0 Jan 22 14:09:35 lucid kernel: usbus3: on ehci0 Jan 22 14:09:35 lucid kernel: pcib7: at device 30.0 on pci0 Jan 22 14:09:35 lucid kernel: pci7: on pcib7 Jan 22 14:09:35 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 22 14:09:35 lucid kernel: isab0: at device 31.0 on pci0 Jan 22 14:09:35 lucid kernel: isa0: on isab0 Jan 22 14:09:35 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 22 14:09:35 lucid kernel: atapci0: [ITHREAD] Jan 22 14:09:35 lucid kernel: ata2: at channel 0 on atapci0 Jan 22 14:09:35 lucid kernel: ata2: [ITHREAD] Jan 22 14:09:35 lucid kernel: ata3: at channel 1 on atapci0 Jan 22 14:09:35 lucid kernel: ata3: [ITHREAD] Jan 22 14:09:35 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 22 14:09:35 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 22 14:09:35 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 22 14:09:35 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 22 14:09:35 lucid kernel: fdc0: does not respond Jan 22 14:09:35 lucid kernel: device_attach: fdc0 attach returned 6 Jan 22 14:09:35 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 22 14:09:35 lucid kernel: uart0: [FILTER] Jan 22 14:09:35 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 22 14:09:35 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 22 14:09:35 lucid kernel: kbd0 at atkbd0 Jan 22 14:09:35 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 22 14:09:35 lucid kernel: atkbd0: [ITHREAD] Jan 22 14:09:35 lucid kernel: psm0: irq 12 on atkbdc0 Jan 22 14:09:35 lucid kernel: psm0: [GIANT-LOCKED] Jan 22 14:09:35 lucid kernel: psm0: [ITHREAD] Jan 22 14:09:35 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 22 14:09:35 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 22 14:09:35 lucid kernel: sc0: at flags 0x100 on isa0 Jan 22 14:09:35 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 22 14:09:35 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 22 14:09:35 lucid kernel: ppc0: cannot reserve I/O port range Jan 22 14:09:35 lucid kernel: est0: on cpu0 Jan 22 14:09:35 lucid kernel: p4tcc0: on cpu0 Jan 22 14:09:35 lucid kernel: est1: on cpu1 Jan 22 14:09:35 lucid kernel: p4tcc1: on cpu1 Jan 22 14:09:35 lucid kernel: est2: on cpu2 Jan 22 14:09:35 lucid kernel: p4tcc2: on cpu2 Jan 22 14:09:35 lucid kernel: est3: on cpu3 Jan 22 14:09:35 lucid kernel: p4tcc3: on cpu3 Jan 22 14:09:35 lucid kernel: Timecounters tick every 1.000 msec Jan 22 14:09:35 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 22 14:09:35 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 22 14:09:35 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 22 14:09:35 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 22 14:09:35 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 22 14:09:35 lucid kernel: ugen0.1: at usbus0 Jan 22 14:09:35 lucid kernel: uhub0: on usbus0 Jan 22 14:09:35 lucid kernel: ugen1.1: at usbus1 Jan 22 14:09:35 lucid kernel: uhub1: on usbus1 Jan 22 14:09:35 lucid kernel: ugen2.1: at usbus2 Jan 22 14:09:35 lucid kernel: uhub2: on usbus2 Jan 22 14:09:35 lucid kernel: ugen3.1: at usbus3 Jan 22 14:09:35 lucid kernel: uhub3: on usbus3 Jan 22 14:09:35 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 22 14:09:35 lucid kernel: SMP: AP CPU #3 Launched! Jan 22 14:09:35 lucid kernel: SMP: AP CPU #1 Launched! Jan 22 14:09:35 lucid kernel: SMP: AP CPU #2 Launched! Jan 22 14:09:35 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 22 14:09:35 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 22 14:09:35 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 22 14:09:35 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 22 14:09:35 lucid kernel: Root mount waiting for: usbus3 Jan 22 14:09:35 lucid kernel: Root mount waiting for: usbus3 Jan 22 14:09:35 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 22 14:09:35 lucid kernel: Root mount waiting for: usbus3 Jan 22 14:09:35 lucid kernel: ugen3.2: at usbus3 Jan 22 14:09:35 lucid kernel: uhub4: on usbus3 Jan 22 14:09:35 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 22 14:09:35 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 22 14:09:37 lucid kernel: bge0: link state changed to UP Jan 22 14:10:09 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 22 14:10:09 lucid kernel: miibus2: on cas0 Jan 22 14:10:09 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 22 14:10:09 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:10:09 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:10:09 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 22 14:10:09 lucid kernel: cas0: [FILTER] Jan 22 14:10:09 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 22 14:10:09 lucid kernel: miibus3: on cas1 Jan 22 14:10:09 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 22 14:10:09 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:10:09 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:10:09 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 22 14:10:09 lucid kernel: cas1: [FILTER] Jan 22 14:10:09 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 22 14:10:09 lucid kernel: miibus4: on cas2 Jan 22 14:10:09 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 22 14:10:09 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:10:09 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:10:09 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 22 14:10:09 lucid kernel: cas2: [FILTER] Jan 22 14:10:09 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 22 14:10:09 lucid kernel: miibus5: on cas3 Jan 22 14:10:09 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 22 14:10:09 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:10:09 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:10:09 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 22 14:10:09 lucid kernel: cas3: [FILTER] Jan 22 14:16:14 lucid kernel: nsgphy0: detached Jan 22 14:16:14 lucid kernel: miibus2: detached Jan 22 14:16:14 lucid kernel: cas0: detached Jan 22 14:16:14 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 22 14:16:14 lucid kernel: nsgphy1: detached Jan 22 14:16:14 lucid kernel: miibus3: detached Jan 22 14:16:14 lucid kernel: cas1: detached Jan 22 14:16:14 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 22 14:16:14 lucid kernel: nsgphy2: detached Jan 22 14:16:14 lucid kernel: miibus4: detached Jan 22 14:16:14 lucid kernel: cas2: detached Jan 22 14:16:14 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 22 14:16:14 lucid kernel: nsgphy3: detached Jan 22 14:16:14 lucid kernel: miibus5: detached Jan 22 14:16:14 lucid kernel: cas3: detached Jan 22 14:16:14 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 22 14:17:02 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 22 14:17:02 lucid kernel: miibus2: on cas0 Jan 22 14:17:02 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 22 14:17:02 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:17:02 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:17:02 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 22 14:17:02 lucid kernel: cas0: [FILTER] Jan 22 14:17:02 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 22 14:17:02 lucid kernel: miibus3: on cas1 Jan 22 14:17:02 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 22 14:17:02 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:17:02 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:17:02 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 22 14:17:02 lucid kernel: cas1: [FILTER] Jan 22 14:17:02 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 22 14:17:02 lucid kernel: miibus4: on cas2 Jan 22 14:17:02 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 22 14:17:02 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:17:02 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:17:02 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 22 14:17:02 lucid kernel: cas2: [FILTER] Jan 22 14:17:02 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 22 14:17:02 lucid kernel: miibus5: on cas3 Jan 22 14:17:02 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 22 14:17:02 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 22 14:17:02 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:17:02 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 22 14:17:02 lucid kernel: cas3: [FILTER] --------------030400010508050204050003-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 21:31:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A38594BB for ; Tue, 22 Jan 2013 21:31:51 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by mx1.freebsd.org (Postfix) with ESMTP id BA4186B4 for ; Tue, 22 Jan 2013 21:31:47 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUP8FQvq0tcRF+vtoGWZNvpfrshn/G7/B@postini.com; Tue, 22 Jan 2013 13:31:51 PST Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 22 Jan 2013 13:30:25 -0800 Date: Tue, 22 Jan 2013 16:30:20 -0500 From: Steve Kiernan To: Peter Jeremy Subject: Re: [JNPR] Proposal for changes to network device drivers and network stack (RFC) Message-ID: <20130122163020.61ca7908@stevek-ubuntu> In-Reply-To: <20130119235624.GB30633@server.rulingia.com> References: <20130119235624.GB30633@server.rulingia.com> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ldP4lK=1LGjJcZRSslWOk97"; protocol="application/pgp-signature" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 21:31:51 -0000 --Sig_/ldP4lK=1LGjJcZRSslWOk97 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 20 Jan 2013 10:56:24 +1100 Peter Jeremy wrote: > On 2013-Jan-17 14:38:06 -0500, "Stephen J. Kiernan" = wrote: > >The patch also includes moving zlib.[ch] and zlibutil.h out of net and=20 > >into sys/libkern (for the .c) and sys/sys (for the .h). >=20 > Good. >=20 > >It really doesn't make much sense for that code to live in net,=20 > >especially when so many things which are not the network stack utilize=20 > >it. >=20 > One thing that currently doesn't is ZFS - which has its own copy. It > would be nice if ZFS could use the common copy. I'll take a look at that. >=20 > >Is that going to be a problem? Should simple stubs be added in the=20 > >original locations in net/ to include the one in sys/ now? >=20 > IMHO, no. zlib wasn't an advertised API so nothing outside the base > OS should be using it. If you've moved all the kernel code to use > the new location, that should be enough. Okay, then I won't worry about adding ones. Thanks. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net --Sig_/ldP4lK=1LGjJcZRSslWOk97 Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlD/BOwACgkQZSuJlLuTi6hQ1gCgyKMWbZjLY2GLSEiivTU/P3Zi VD4AoKHHKce7sB+mjDkuAHnXTSRA0oWc =+Flx -----END PGP SIGNATURE----- --Sig_/ldP4lK=1LGjJcZRSslWOk97-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 21:37:56 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 594D25D8 for ; Tue, 22 Jan 2013 21:37:56 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A66B66F2 for ; Tue, 22 Jan 2013 21:37:55 +0000 (UTC) Received: (qmail 21710 invoked from network); 22 Jan 2013 22:59:19 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Jan 2013 22:59:19 -0000 Message-ID: <50FF06AD.402@networx.ch> Date: Tue, 22 Jan 2013 22:37:49 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FEF81C.1070002@mu.org> In-Reply-To: <50FEF81C.1070002@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 21:37:56 -0000 On 22.01.2013 21:35, Alfred Perlstein wrote: > On 1/22/13 12:11 PM, John Baldwin wrote: >> As I mentioned in an earlier thread, I recently had to debug an issue we were >> seeing across a link with a high bandwidth-delay product (both high bandwidth >> and high RTT). Our specific use case was to use a TCP connection to reliably >> forward a latency-sensitive datagram stream across a WAN connection. We would >> often see spikes in the latency of individual datagrams. I eventually tracked >> this down to the connection entering slow start when it would transmit data >> after being idle. The data stream was quite bursty and would often attempt to >> transmit a burst of data after being idle for far longer than a retransmit >> timeout. >> >> In 7.x we had worked around this in the past by disabling RFC 3390 and jacking >> the slow start window size up via a sysctl. On 8.x this no longer worked. >> The solution I came up with was to add a new socket option to disable idle >> handling completely. That is, when an idle connection restarts with this new >> option enabled, it keeps its current congestion window and doesn't enter slow >> start. >> >> There are only a few cases where such an option is useful, but if anyone else >> thinks this might be useful I'd be happy to add the option to FreeBSD. > > This looks good, but it almost sounds like a bug for TCP to be doing this anyhow. It's not a bug. It's by design. It's required by the RFC. > Why would one want this behavior? Network conditions change all the time. Traffic and congestion comes and goes. Connections can go idle for milliseconds to minutes to hours. Whenever "enough" time has passed network capacity probing has to start anew. > Wouldn't it make sense to keep the window large until there was a problem rather than > unconditionally chop it down? I almost think TCP is afraid that you might wind up swapping out a > 10gig interface for a modem? I'm just not getting it. (probably simple oversight on my part). The very real fear is congestion meltdown. That is the reason we ended up with TCP's AIMD mechanism in the first place. If everybody were to blast into the network anyone will suffer. The bufferbloat issue identified recently makes things even worse. > What do you think about also making this a sysctl for global on/off by default? Please don't. The correct fix is either a) to use the initial window as the restart window (up to 10 MSS nowadays); b) to use a decay mechanism based on the time since the last network condition probe. Even the latter must decay to initCWND within at most 1MSL. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 21:57:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EBA06C73; Tue, 22 Jan 2013 21:57:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AE0638D4; Tue, 22 Jan 2013 21:57:35 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 52337B953; Tue, 22 Jan 2013 16:57:34 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks Date: Tue, 22 Jan 2013 15:28:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141550.13577.jhb@freebsd.org> <201301151416.07231.jhb@freebsd.org> <50FE5473.7000807@freebsd.org> In-Reply-To: <50FE5473.7000807@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301221528.18388.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Jan 2013 16:57:34 -0500 (EST) Cc: Lawrence Stewart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 21:57:36 -0000 On Tuesday, January 22, 2013 3:57:23 am Lawrence Stewart wrote: > On 01/16/13 06:16, John Baldwin wrote: > > On Tuesday, January 15, 2013 3:49:33 am Lawrence Stewart wrote: > >> On 01/15/13 07:50, John Baldwin wrote: > >>> The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are > >>> currently defined as hex values that are individual bits. However, socket > >>> options are never masked together, they are used as a simple enumeration of > >>> discrete values. Using a bitmask forces us to run out of bits and makes it > >>> harder for vendors to try to use a high range of values for local custom > >>> options (hoping that they never conflict with a new option value added in > >>> stock FreeBSD). > >> > >> Yup. Should we be explicitly #defining the boundary between "bits > >> reserved for FreeBSD" and "bits for private vendor use"? > > > > Oh, we could if you wanted. I'm using 0x1000 locally for both TCP and UDP, > > but those are completely arbitrary values. Saner ones might be 0x8000000 if > > we want to do that explicitly. We could perhaps just say that is true for all > > socket option levels (that is, just define one SO_VENDOR constant or some such > > but say it applies to all levels)? > > A single SO_VENDOR applied to all levels sounds good to me. Ok, how about this for wording: Index: sys/socket.h =================================================================== --- socket.h (revision 245742) +++ socket.h (working copy) @@ -143,6 +143,15 @@ typedef __uid_t uid_t; #endif /* + * Space reserved for new socket options added by third-party vendors. + * This range applies to all socket option levels. New socket options + * in FreeBSD should always use an option value less than SO_VENDOR. + */ +#if __BSD_VISIBLE +#define SO_VENDOR 0x80000000 +#endif + +/* * Structure used for manipulating linger option. */ struct linger { -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 21:57:36 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D15A5C77 for ; Tue, 22 Jan 2013 21:57:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B06A88D6 for ; Tue, 22 Jan 2013 21:57:36 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 11B17B95B; Tue, 22 Jan 2013 16:57:36 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Date: Tue, 22 Jan 2013 16:12:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301221511.02496.jhb@freebsd.org> <50FEF81C.1070002@mu.org> In-Reply-To: <50FEF81C.1070002@mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301221612.57067.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Jan 2013 16:57:36 -0500 (EST) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jan 2013 21:57:36 -0000 On Tuesday, January 22, 2013 3:35:40 pm Alfred Perlstein wrote: > On 1/22/13 12:11 PM, John Baldwin wrote: > > As I mentioned in an earlier thread, I recently had to debug an issue we were > > seeing across a link with a high bandwidth-delay product (both high bandwidth > > and high RTT). Our specific use case was to use a TCP connection to reliably > > forward a latency-sensitive datagram stream across a WAN connection. We would > > often see spikes in the latency of individual datagrams. I eventually tracked > > this down to the connection entering slow start when it would transmit data > > after being idle. The data stream was quite bursty and would often attempt to > > transmit a burst of data after being idle for far longer than a retransmit > > timeout. > > > > In 7.x we had worked around this in the past by disabling RFC 3390 and jacking > > the slow start window size up via a sysctl. On 8.x this no longer worked. > > The solution I came up with was to add a new socket option to disable idle > > handling completely. That is, when an idle connection restarts with this new > > option enabled, it keeps its current congestion window and doesn't enter slow > > start. > > > > There are only a few cases where such an option is useful, but if anyone else > > thinks this might be useful I'd be happy to add the option to FreeBSD. > > This looks good, but it almost sounds like a bug for TCP to be doing > this anyhow. > > Why would one want this behavior? > > Wouldn't it make sense to keep the window large until there was a > problem rather than unconditionally chop it down? I almost think TCP is > afraid that you might wind up swapping out a 10gig interface for a > modem? I'm just not getting it. (probably simple oversight on my part). > > What do you think about also making this a sysctl for global on/off by > default? No, I think this is the proper default and RFC 5681 makes this a SHOULD. The burst at line rate argument is a very good one. Normally if you have a stream of data your data rate is clocked by the arrival of return ACKs (once you have filled the window), and slow starts keeps you throttled at the beginning from flooding the pipe. However, if your connection becomes idle then you will accumulate a large number of ACKs and be able to "spend" them all at once when you get a burst of data to send. This burst can then use a higher effective bandwidth than the normal flow of traffic and could overwhelm a switch. Also, for the cases where this is most useful (high RTT), it is not at all unimaginable for network conditions to change dramatically. In my use case we have dedicated lines and control what goes across them so we don't have to worry about that, but the general use case certainly needs to take that into account. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 06:05:00 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7729109 for ; Wed, 23 Jan 2013 06:05:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2B840ACC for ; Wed, 23 Jan 2013 06:04:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 337897302C; Wed, 23 Jan 2013 07:04:28 +0100 (CET) Date: Wed, 23 Jan 2013 07:04:28 +0100 From: Luigi Rizzo To: net@freebsd.org Subject: [luigi@FreeBSD.org: svn commit: r245836 - head/sys/dev/netmap] Message-ID: <20130123060428.GC50751@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 06:05:00 -0000 this new netmap feature might be of interest cheers luigi ----- Forwarded message from Luigi Rizzo ----- Date: Wed, 23 Jan 2013 05:37:46 +0000 (UTC) From: Luigi Rizzo Subject: svn commit: r245836 - head/sys/dev/netmap To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: luigi Date: Wed Jan 23 05:37:45 2013 New Revision: 245836 URL: http://svnweb.freebsd.org/changeset/base/245836 Log: Add support for transparent mode while in netmap. By setting dev.netmap.fwd=1 (or enabling the feature with a per-ring flag), packets are forwarded between the NIC and the host stack unless the netmap client clears the NS_FORWARD flag on the individual descriptors. This feature greatly simplifies applications where some traffic (think of ARP, control traffic, ssh sessions...) must be processed by the host stack, whereas the bulk is handled by the netmap process which simply (un)marks packets that should not be forwarded. The default is chosen so that now a netmap receiver operates in a mode very similar to bpf. Of course there is no free lunch: traffic to/from the host stack still operates at OS speed (or less, as there is one extra copy in one direction). HOWEVER, since traffic goes to the user process before being reinjected, and reinjection occurs in a user context, you get some form of livelock protection for free. Modified: head/sys/dev/netmap/netmap.c Modified: head/sys/dev/netmap/netmap.c ============================================================================== --- head/sys/dev/netmap/netmap.c Wed Jan 23 03:51:47 2013 (r245835) +++ head/sys/dev/netmap/netmap.c Wed Jan 23 05:37:45 2013 (r245836) @@ -120,10 +120,12 @@ SYSCTL_INT(_dev_netmap, OID_AUTO, no_pen int netmap_drop = 0; /* debugging */ int netmap_flags = 0; /* debug flags */ +int netmap_fwd = 0; /* force transparent mode */ int netmap_copy = 0; /* debugging, copy content */ SYSCTL_INT(_dev_netmap, OID_AUTO, drop, CTLFLAG_RW, &netmap_drop, 0 , ""); SYSCTL_INT(_dev_netmap, OID_AUTO, flags, CTLFLAG_RW, &netmap_flags, 0 , ""); +SYSCTL_INT(_dev_netmap, OID_AUTO, fwd, CTLFLAG_RW, &netmap_fwd, 0 , ""); SYSCTL_INT(_dev_netmap, OID_AUTO, copy, CTLFLAG_RW, &netmap_copy, 0 , ""); #ifdef NM_BRIDGE /* support for netmap bridge */ @@ -647,63 +649,170 @@ netmap_open(struct cdev *dev, int oflags /* * Handlers for synchronization of the queues from/to the host. - * - * netmap_sync_to_host() passes packets up. We are called from a - * system call in user process context, and the only contention - * can be among multiple user threads erroneously calling - * this routine concurrently. In principle we should not even - * need to lock. + * Netmap has two operating modes: + * - in the default mode, the rings connected to the host stack are + * just another ring pair managed by userspace; + * - in transparent mode (XXX to be defined) incoming packets + * (from the host or the NIC) are marked as NS_FORWARD upon + * arrival, and the user application has a chance to reset the + * flag for packets that should be dropped. + * On the RXSYNC or poll(), packets in RX rings between + * kring->nr_kcur and ring->cur with NS_FORWARD still set are moved + * to the other side. + * The transfer NIC --> host is relatively easy, just encapsulate + * into mbufs and we are done. The host --> NIC side is slightly + * harder because there might not be room in the tx ring so it + * might take a while before releasing the buffer. + */ + +/* + * pass a chain of buffers to the host stack as coming from 'dst' */ static void -netmap_sync_to_host(struct netmap_adapter *na) +netmap_send_up(struct ifnet *dst, struct mbuf *head) { - struct netmap_kring *kring = &na->tx_rings[na->num_tx_rings]; - struct netmap_ring *ring = kring->ring; - struct mbuf *head = NULL, *tail = NULL, *m; - u_int k, n, lim = kring->nkr_num_slots - 1; + struct mbuf *m; - k = ring->cur; - if (k > lim) { - netmap_ring_reinit(kring); - return; + /* send packets up, outside the lock */ + while ((m = head) != NULL) { + head = head->m_nextpkt; + m->m_nextpkt = NULL; + if (netmap_verbose & NM_VERB_HOST) + D("sending up pkt %p size %d", m, MBUF_LEN(m)); + NM_SEND_UP(dst, m); } - // na->nm_lock(na->ifp, NETMAP_CORE_LOCK, 0); +} - /* Take packets from hwcur to cur and pass them up. +struct mbq { + struct mbuf *head; + struct mbuf *tail; + int count; +}; + +/* + * put a copy of the buffers marked NS_FORWARD into an mbuf chain. + * Run from hwcur to cur - reserved + */ +static void +netmap_grab_packets(struct netmap_kring *kring, struct mbq *q, int force) +{ + /* Take packets from hwcur to cur-reserved and pass them up. * In case of no buffers we give up. At the end of the loop, * the queue is drained in all cases. + * XXX handle reserved */ + int k = kring->ring->cur - kring->ring->reserved; + u_int n, lim = kring->nkr_num_slots - 1; + struct mbuf *m, *tail = q->tail; + + if (k < 0) + k = k + kring->nkr_num_slots; for (n = kring->nr_hwcur; n != k;) { - struct netmap_slot *slot = &ring->slot[n]; + struct netmap_slot *slot = &kring->ring->slot[n]; n = (n == lim) ? 0 : n + 1; + if ((slot->flags & NS_FORWARD) == 0 && !force) + continue; if (slot->len < 14 || slot->len > NETMAP_BUF_SIZE) { D("bad pkt at %d len %d", n, slot->len); continue; } - m = m_devget(NMB(slot), slot->len, 0, na->ifp, NULL); + slot->flags &= ~NS_FORWARD; // XXX needed ? + m = m_devget(NMB(slot), slot->len, 0, kring->na->ifp, NULL); if (m == NULL) break; if (tail) tail->m_nextpkt = m; else - head = m; + q->head = m; tail = m; + q->count++; m->m_nextpkt = NULL; } + q->tail = tail; +} + +/* + * called under main lock to send packets from the host to the NIC + * The host ring has packets from nr_hwcur to (cur - reserved) + * to be sent down. We scan the tx rings, which have just been + * flushed so nr_hwcur == cur. Pushing packets down means + * increment cur and decrement avail. + * XXX to be verified + */ +static void +netmap_sw_to_nic(struct netmap_adapter *na) +{ + struct netmap_kring *kring = &na->rx_rings[na->num_rx_rings]; + struct netmap_kring *k1 = &na->tx_rings[0]; + int i, howmany, src_lim, dst_lim; + + howmany = kring->nr_hwavail; /* XXX otherwise cur - reserved - nr_hwcur */ + + src_lim = kring->nkr_num_slots; + for (i = 0; howmany > 0 && i < na->num_tx_rings; i++, k1++) { + ND("%d packets left to ring %d (space %d)", howmany, i, k1->nr_hwavail); + dst_lim = k1->nkr_num_slots; + while (howmany > 0 && k1->ring->avail > 0) { + struct netmap_slot *src, *dst, tmp; + src = &kring->ring->slot[kring->nr_hwcur]; + dst = &k1->ring->slot[k1->ring->cur]; + tmp = *src; + src->buf_idx = dst->buf_idx; + src->flags = NS_BUF_CHANGED; + + dst->buf_idx = tmp.buf_idx; + dst->len = tmp.len; + dst->flags = NS_BUF_CHANGED; + ND("out len %d buf %d from %d to %d", + dst->len, dst->buf_idx, + kring->nr_hwcur, k1->ring->cur); + + if (++kring->nr_hwcur >= src_lim) + kring->nr_hwcur = 0; + howmany--; + kring->nr_hwavail--; + if (++k1->ring->cur >= dst_lim) + k1->ring->cur = 0; + k1->ring->avail--; + } + kring->ring->cur = kring->nr_hwcur; // XXX + k1++; + } +} + +/* + * netmap_sync_to_host() passes packets up. We are called from a + * system call in user process context, and the only contention + * can be among multiple user threads erroneously calling + * this routine concurrently. + */ +static void +netmap_sync_to_host(struct netmap_adapter *na) +{ + struct netmap_kring *kring = &na->tx_rings[na->num_tx_rings]; + struct netmap_ring *ring = kring->ring; + u_int k, lim = kring->nkr_num_slots - 1; + struct mbq q = { NULL, NULL }; + + k = ring->cur; + if (k > lim) { + netmap_ring_reinit(kring); + return; + } + // na->nm_lock(na->ifp, NETMAP_CORE_LOCK, 0); + + /* Take packets from hwcur to cur and pass them up. + * In case of no buffers we give up. At the end of the loop, + * the queue is drained in all cases. + */ + netmap_grab_packets(kring, &q, 1); kring->nr_hwcur = k; kring->nr_hwavail = ring->avail = lim; // na->nm_lock(na->ifp, NETMAP_CORE_UNLOCK, 0); - /* send packets up, outside the lock */ - while ((m = head) != NULL) { - head = head->m_nextpkt; - m->m_nextpkt = NULL; - if (netmap_verbose & NM_VERB_HOST) - D("sending up pkt %p size %d", m, MBUF_LEN(m)); - NM_SEND_UP(na->ifp, m); - } + netmap_send_up(na->ifp, q.head); } /* @@ -1236,7 +1345,8 @@ netmap_poll(struct cdev *dev, int events struct ifnet *ifp; struct netmap_kring *kring; u_int core_lock, i, check_all, want_tx, want_rx, revents = 0; - u_int lim_tx, lim_rx; + u_int lim_tx, lim_rx, host_forwarded = 0; + struct mbq q = { NULL, NULL, 0 }; enum {NO_CL, NEED_CL, LOCKED_CL }; /* see below */ void *pwait = dev; /* linux compatibility */ @@ -1284,6 +1394,17 @@ netmap_poll(struct cdev *dev, int events return (revents); } + /* if we are in transparent mode, check also the host rx ring */ + kring = &na->rx_rings[lim_rx]; + if ( (priv->np_qlast == NETMAP_HW_RING) // XXX check_all + && want_rx + && (netmap_fwd || kring->ring->flags & NR_FORWARD) ) { + if (kring->ring->avail == 0) + netmap_sync_from_host(na, td, dev); + if (kring->ring->avail > 0) + revents |= want_rx; + } + /* * check_all is set if the card has more than one queue and * the client is polling all of them. If true, we sleep on @@ -1359,6 +1480,7 @@ netmap_poll(struct cdev *dev, int events * to avoid that the tx rings stall). */ if (priv->np_txpoll || want_tx) { +flush_tx: for (i = priv->np_qfirst; i < lim_tx; i++) { kring = &na->tx_rings[i]; /* @@ -1411,6 +1533,11 @@ netmap_poll(struct cdev *dev, int events } if (na->separate_locks) na->nm_lock(ifp, NETMAP_RX_LOCK, i); + if (netmap_fwd ||kring->ring->flags & NR_FORWARD) { + ND(10, "forwarding some buffers up %d to %d", + kring->nr_hwcur, kring->ring->cur); + netmap_grab_packets(kring, &q, netmap_fwd); + } if (na->nm_rxsync(ifp, i, 0 /* no lock */)) revents |= POLLERR; @@ -1433,8 +1560,28 @@ netmap_poll(struct cdev *dev, int events if (want_rx) selrecord(td, &na->rx_si); } + + /* forward host to the netmap ring */ + kring = &na->rx_rings[lim_rx]; + if (kring->nr_hwavail > 0) + ND("host rx %d has %d packets", lim_rx, kring->nr_hwavail); + if ( (priv->np_qlast == NETMAP_HW_RING) // XXX check_all + && (netmap_fwd || kring->ring->flags & NR_FORWARD) + && kring->nr_hwavail > 0 && !host_forwarded) { + if (core_lock == NEED_CL) { + na->nm_lock(ifp, NETMAP_CORE_LOCK, 0); + core_lock = LOCKED_CL; + } + netmap_sw_to_nic(na); + host_forwarded = 1; /* prevent another pass */ + want_rx = 0; + goto flush_tx; + } + if (core_lock == LOCKED_CL) na->nm_lock(ifp, NETMAP_CORE_UNLOCK, 0); + if (q.head) + netmap_send_up(na->ifp, q.head); return (revents); } @@ -1586,7 +1733,8 @@ netmap_start(struct ifnet *ifp, struct m goto done; /* no space */ } if (len > NETMAP_BUF_SIZE) { - D("drop packet size %d > %d", len, NETMAP_BUF_SIZE); + D("%s from_host, drop packet size %d > %d", ifp->if_xname, + len, NETMAP_BUF_SIZE); goto done; /* too long for us */ } @@ -1597,6 +1745,7 @@ netmap_start(struct ifnet *ifp, struct m slot = &kring->ring->slot[i]; m_copydata(m, 0, len, NMB(slot)); slot->len = len; + slot->flags = kring->nkr_slot_flags; kring->nr_hwavail++; if (netmap_verbose & NM_VERB_HOST) D("wake up host ring %s %d", na->ifp->if_xname, na->num_rx_rings); ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 06:33:34 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7FFB0425; Wed, 23 Jan 2013 06:33:34 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2DFA6C2A; Wed, 23 Jan 2013 06:33:33 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so4118483vbi.4 for ; Tue, 22 Jan 2013 22:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kwr6/PGApsHCXXmRDWQcA3vxJbk95jK8KHGP7HZRH68=; b=Nw16kpaqpL6PzKYoIndvwWJS9aNm/WGnKbYT0x35BENkaJk+cGSj5NMLywh7a6s4jE rLrFfg6lpIPVPUZHXyryLVgwy0Z5+SoeAfGOv0XLH/DVg7lJF53WlzyKXlVfquGRQIq/ 4k44oYiKzqdJXQLwEquPBSdO1fmCjfNOiUaPXex66aG0MVUM1X2FMnXswlYkrXIZtO2m by5qrMub/QKYpCclk+WyXJx7i/tsU6i5CSmTDwpA95uZR6Dz6LMOQlf6ekqghhJnP8Ys T73feuUn8ilenpGDP1ZWoZTlOLJrgA7bomNoy+itSkUtcnTllmsFI86qAMZGXRJJBB5g C2Ug== MIME-Version: 1.0 X-Received: by 10.220.230.199 with SMTP id jn7mr252449vcb.4.1358922807609; Tue, 22 Jan 2013 22:33:27 -0800 (PST) Received: by 10.58.213.34 with HTTP; Tue, 22 Jan 2013 22:33:27 -0800 (PST) In-Reply-To: <201301221511.02496.jhb@freebsd.org> References: <201301221511.02496.jhb@freebsd.org> Date: Wed, 23 Jan 2013 14:33:27 +0800 Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Sepherosa Ziehau To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 06:33:34 -0000 On Wed, Jan 23, 2013 at 4:11 AM, John Baldwin wrote: > As I mentioned in an earlier thread, I recently had to debug an issue we were > seeing across a link with a high bandwidth-delay product (both high bandwidth > and high RTT). Our specific use case was to use a TCP connection to reliably > forward a latency-sensitive datagram stream across a WAN connection. We would > often see spikes in the latency of individual datagrams. I eventually tracked > this down to the connection entering slow start when it would transmit data > after being idle. The data stream was quite bursty and would often attempt to > transmit a burst of data after being idle for far longer than a retransmit > timeout. > > In 7.x we had worked around this in the past by disabling RFC 3390 and jacking > the slow start window size up via a sysctl. On 8.x this no longer worked. > The solution I came up with was to add a new socket option to disable idle > handling completely. That is, when an idle connection restarts with this new > option enabled, it keeps its current congestion window and doesn't enter slow > start. > > There are only a few cases where such an option is useful, but if anyone else > thinks this might be useful I'd be happy to add the option to FreeBSD. I think what you need is the RFC2861, however, you probably should ignore the "application-limited period" part of RFC2861. Best Regards, sephe > > Index: share/man/man4/tcp.4 > =================================================================== > --- share/man/man4/tcp.4 (revision 245742) > +++ share/man/man4/tcp.4 (working copy) > @@ -205,6 +205,18 @@ > in the > .Sx MIB Variables > section further down. > +.It Dv TCP_IGNOREIDLE > +If a TCP connection is idle for more than one retransmit timeout, > +it enters slow start when new data is available to transmit. > +This avoids flooding the network with a full window of traffic at line rate. > +It also allows the connection to adjust to changes to network conditions > +that occurred while the connection was idle. A connection that sends > +bursts of data separated by large idle periods can be permamently stuck in > +slow start as a result. > +The boolean option > +.Dv TCP_IGNOREIDLE > +disables the idle connection handling allowing connections to maintain the > +existing congestion window when restarting after an idle period. > .It Dv TCP_NODELAY > Under most circumstances, > .Tn TCP > Index: sys/netinet/tcp_var.h > =================================================================== > --- sys/netinet/tcp_var.h (revision 245742) > +++ sys/netinet/tcp_var.h (working copy) > @@ -230,6 +230,7 @@ > #define TF_NEEDFIN 0x000800 /* send FIN (implicit state) */ > #define TF_NOPUSH 0x001000 /* don't push */ > #define TF_PREVVALID 0x002000 /* saved values for bad rxmit valid */ > +#define TF_IGNOREIDLE 0x004000 /* connection is never idle */ > #define TF_MORETOCOME 0x010000 /* More data to be appended to sock */ > #define TF_LQ_OVERFLOW 0x020000 /* listen queue overflow */ > #define TF_LASTIDLE 0x040000 /* connection was previously idle */ > Index: sys/netinet/tcp_output.c > =================================================================== > --- sys/netinet/tcp_output.c (revision 245742) > +++ sys/netinet/tcp_output.c (working copy) > @@ -206,7 +206,8 @@ > * to send, then transmit; otherwise, investigate further. > */ > idle = (tp->t_flags & TF_LASTIDLE) || (tp->snd_max == tp->snd_una); > - if (idle && ticks - tp->t_rcvtime >= tp->t_rxtcur) > + if (!(tp->t_flags & TF_IGNOREIDLE) && > + idle && ticks - tp->t_rcvtime >= tp->t_rxtcur) > cc_after_idle(tp); > tp->t_flags &= ~TF_LASTIDLE; > if (idle) { > Index: sys/netinet/tcp.h > =================================================================== > --- sys/netinet/tcp.h (revision 245823) > +++ sys/netinet/tcp.h (working copy) > @@ -156,6 +156,7 @@ > #define TCP_NODELAY 1 /* don't delay send to coalesce packets */ > #if __BSD_VISIBLE > #define TCP_MAXSEG 2 /* set maximum segment size */ > +#define TCP_IGNOREIDLE 3 /* disable idle connection handling */ > #define TCP_NOPUSH 4 /* don't push last block of write */ > #define TCP_NOOPT 8 /* don't use TCP options */ > #define TCP_MD5SIG 16 /* use MD5 digests (RFC2385) */ > Index: sys/netinet/tcp_usrreq.c > =================================================================== > --- sys/netinet/tcp_usrreq.c (revision 245742) > +++ sys/netinet/tcp_usrreq.c (working copy) > @@ -1354,6 +1354,7 @@ > > case TCP_NODELAY: > case TCP_NOOPT: > + case TCP_IGNOREIDLE: > INP_WUNLOCK(inp); > error = sooptcopyin(sopt, &optval, sizeof optval, > sizeof optval); > @@ -1368,6 +1369,9 @@ > case TCP_NOOPT: > opt = TF_NOOPT; > break; > + case TCP_IGNOREIDLE: > + opt = TF_IGNOREIDLE; > + break; > default: > opt = 0; /* dead code to fool gcc */ > break; > @@ -1578,6 +1582,11 @@ > INP_WUNLOCK(inp); > error = sooptcopyout(sopt, buf, TCP_CA_NAME_MAX); > break; > + case TCP_IGNOREIDLE: > + optval = tp->t_flags & TF_IGNOREIDLE; > + INP_WUNLOCK(inp); > + error = sooptcopyout(sopt, &optval, sizeof optval); > + break; > default: > INP_WUNLOCK(inp); > error = ENOPROTOOPT; > > -- > John Baldwin > _______________________________________________ > 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" -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 07:00:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 34C6282C for ; Wed, 23 Jan 2013 07:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8CED6C for ; Wed, 23 Jan 2013 07:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0N701vZ066896 for ; Wed, 23 Jan 2013 07:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0N701sO066895; Wed, 23 Jan 2013 07:00:01 GMT (envelope-from gnats) Date: Wed, 23 Jan 2013 07:00:01 GMT Message-Id: <201301230700.r0N701sO066895@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Emanuel Haupt Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is terminated X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Emanuel Haupt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 07:00:02 -0000 The following reply was made to PR kern/173475; it has been noted by GNATS. From: Emanuel Haupt To: bug-followup@FreeBSD.org, IZ-FreeBSD0701@hs-karlsruhe.de Cc: Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is terminated Date: Wed, 23 Jan 2013 07:59:07 +0100 Could you please try the following vpnc patch? It tries to work around this deadlock situation: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175067 However, the underlying problem with if_tun should be looked at separately in this PR. Emanuel From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 07:13:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A1C4949; Wed, 23 Jan 2013 07:13:47 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id E02CEDC5; Wed, 23 Jan 2013 07:13:46 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id c10so12907276ieb.39 for ; Tue, 22 Jan 2013 23:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=6e4oof9oSCeLO6+QqPSB8by6IUF2ZEaUxDxvhNNxtS8=; b=judkUsR1FeqwcO2WhJHimbSD5OpuAwHqZzRs/x3v0xasOg7dR4SMAjvMHNUJk6IJHF tD5gSvcGed7RwXT060GDe68EgCk/RimF1Po3I7wF4fa5W9c62Iwy0PFkf2i8pOX3g+Qq RypK5+Vw7qQN7APKOQlVcSvEVIUbe0ohRaUopj6mIuVExouXAl3GfBGORTifBZjpJ2bM N6O0qy14icSrIaTFMeokEHSZK5Sq+ube0HMwoIk6px82kN9Ap9w8/Ob0ZEIoes4mGC+Y 71Tr1nUKwYNCdqPQjifVJh1qsGxRpG17vG1mDEmXt6m9A6aE4ed95+DKYG0GOVgV/2ho B1Rw== MIME-Version: 1.0 X-Received: by 10.42.21.84 with SMTP id j20mr238376icb.19.1358925226398; Tue, 22 Jan 2013 23:13:46 -0800 (PST) Received: by 10.43.112.194 with HTTP; Tue, 22 Jan 2013 23:13:46 -0800 (PST) Date: Tue, 22 Jan 2013 23:13:46 -0800 Message-ID: Subject: e1000 serdes link flap From: Neel Natu To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: jfv@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 07:13:47 -0000 Hi, I am running into a problem in head with the e1000 link state detection logic attached to a 82571EB serdes controller. The symptom is that the link state keeps flapping between "up" and "down". After I enabled the debug output in 'e1000_check_for_serdes_link_82571()' this is what I see: e1000_check_for_serdes_link_82571 ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 FORCED_UP -> AN_PROG em6: link state changed to DOWN e1000_check_for_serdes_link_82571 ctrl = 0x4c0201, status = 0x803a4, rxcw = 0x44000000 AN_PROG -> FORCED_UP em6: link state changed to UP e1000_check_for_serdes_link_82571 ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 FORCED_UP -> AN_PROG em6: link state changed to DOWN The problem goes away if I apply the following patch to bring the link state detection logic in line with the e1000e driver in Linux: Index: e1000_82571.c =================================================================== --- e1000_82571.c (revision 245766) +++ e1000_82571.c (working copy) @@ -1712,10 +1712,8 @@ * auto-negotiation in the TXCW register and disable * forced link in the Device Control register in an * attempt to auto-negotiate with our link partner. - * If the partner code word is null, stop forcing - * and restart auto negotiation. */ - if ((rxcw & E1000_RXCW_C) || !(rxcw & E1000_RXCW_CW)) { + if ((rxcw & E1000_RXCW_C) != 0) { /* Enable autoneg, and unforce link up */ E1000_WRITE_REG(hw, E1000_TXCW, mac->txcw); E1000_WRITE_REG(hw, E1000_CTRL, I am not sure why the !(rxcw & E1000_RXCW_CW) check was added and the e1000 SDM does not have any more information. Jack, can you take a look at the patch and commit if it looks alright? best Neel From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 12:34:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 208A4930 for ; Wed, 23 Jan 2013 12:34:24 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id F22E3EB5 for ; Wed, 23 Jan 2013 12:34:23 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,521,1355126400"; d="scan'208";a="10723880" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 23 Jan 2013 04:34:17 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0NCYGRW001269; Wed, 23 Jan 2013 04:34:16 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Wed, 23 Jan 2013 04:34:16 -0800 From: "Eggert, Lars" To: "freebsd-net@freebsd.org" Subject: Re: Data Center Bridging? Thread-Topic: Data Center Bridging? Thread-Index: AQHN+LdDgifA/mtK/UqYvtRGZs2iTJhWNxkAgAEpfYA= Date: Wed, 23 Jan 2013 12:34:15 +0000 Message-ID: References: <50FEDF3A.60806@gmail.com> In-Reply-To: <50FEDF3A.60806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Vogel, Jack" , Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 12:34:24 -0000 Hi, On Jan 22, 2013, at 19:23, Jack Vogel wrote: > I have never implemented this in the FreeBSD drivers primarily because th= e > motivation for it say, in Linux, > was to handle multiple traffic classes, for instance FCOE or iSCSI, but > FreeBSD has not had these features > to implement this for. Give me a reason to do it, and I can see about > adding it :) well, my motivation for asking was that I'll soon have some students invest= igate various options for low-latency reliable communication over a private= fabric. DCB is one candidate. On Jan 22, 2013, at 19:49, Navdeep Parhar wrote: > cxgbe(4) hardware supports DCB/DCBX, but I haven't looked at what it > would take to add driver + OS support. Driver support for either Intel or Chelsio NICs would be great! Lars= From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 16:32:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 934E5A77; Wed, 23 Jan 2013 16:32:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 63A42EEA; Wed, 23 Jan 2013 16:32:37 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C4B3AB911; Wed, 23 Jan 2013 11:32:36 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Date: Wed, 23 Jan 2013 11:15:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301221511.02496.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201301231115.06393.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 23 Jan 2013 11:32:36 -0500 (EST) Cc: Sepherosa Ziehau , Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 16:32:37 -0000 On Wednesday, January 23, 2013 1:33:27 am Sepherosa Ziehau wrote: > On Wed, Jan 23, 2013 at 4:11 AM, John Baldwin wrote: > > As I mentioned in an earlier thread, I recently had to debug an issue w= e were > > seeing across a link with a high bandwidth-delay product (both high ban= dwidth > > and high RTT). Our specific use case was to use a TCP connection to re= liably > > forward a latency-sensitive datagram stream across a WAN connection. W= e would > > often see spikes in the latency of individual datagrams. I eventually = tracked > > this down to the connection entering slow start when it would transmit = data > > after being idle. The data stream was quite bursty and would often att= empt to > > transmit a burst of data after being idle for far longer than a retrans= mit > > timeout. > > > > In 7.x we had worked around this in the past by disabling RFC 3390 and = jacking > > the slow start window size up via a sysctl. On 8.x this no longer work= ed. > > The solution I came up with was to add a new socket option to disable i= dle > > handling completely. That is, when an idle connection restarts with th= is new > > option enabled, it keeps its current congestion window and doesn't ente= r slow > > start. > > > > There are only a few cases where such an option is useful, but if anyon= e else > > thinks this might be useful I'd be happy to add the option to FreeBSD. >=20 > I think what you need is the RFC2861, however, you probably should > ignore the "application-limited period" part of RFC2861. Hummm. It appears btw, that Linux uses RFC 2861, but has a global knob to disable it due to applictions having problems. When it is disabled, it doesn't decay the congestion window at all during idle handling. That i= s, it appears to act the same as if TCP_IGNOREIDLE were enabled. =46rom http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html: tcp_slow_start_after_idle (Boolean; default: enabled; since Linux 2.= 6.18) If enabled, provide RFC 2861 behavior and time out the conges= tion window after an idle period. An idle period is defined as th= e current RTO (retransmission timeout). If disabled, the congestion wi= ndow will not be timed out after an idle period. Also, in this thread on tcp-m it appears no one on that list realizes that there are any implementations which follow the "SHOULD" in RFC 2581 for idle handling (which is what we do currently): http://www.ietf.org/mail-archive/web/tcpm/current/msg02864.html So if we were to implement RFC 2861, the new socket option would be equival= ent to setting Linux's 'tcp_slow_start_after_idle' to false, but on a per-socket basis rather than globally. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 16:32:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AFDA0A79; Wed, 23 Jan 2013 16:32:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8998DEEB; Wed, 23 Jan 2013 16:32:39 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B892EB922; Wed, 23 Jan 2013 11:32:38 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org, Emanuel Haupt Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is terminated Date: Wed, 23 Jan 2013 11:17:53 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301230700.r0N701sO066895@freefall.freebsd.org> In-Reply-To: <201301230700.r0N701sO066895@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301231117.53522.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 23 Jan 2013 11:32:38 -0500 (EST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 16:32:39 -0000 On Wednesday, January 23, 2013 2:00:01 am Emanuel Haupt wrote: > The following reply was made to PR kern/173475; it has been noted by GNATS. > > From: Emanuel Haupt > To: bug-followup@FreeBSD.org, IZ-FreeBSD0701@hs-karlsruhe.de > Cc: > Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is > terminated > Date: Wed, 23 Jan 2013 07:59:07 +0100 > > Could you please try the following vpnc patch? It tries to work around > this deadlock situation: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175067 > > However, the underlying problem with if_tun should be looked at > separately in this PR. This is not a bug in tun, it is a bug in vpnc. (I also see this with openconnect). The problem in the case of openconnect is that the process calls vpnc-script while is still holds an open file descriptor on /dev/tunX. The calling processes need to be fixed to close /dev/tunX before calling the script, or they need to handle destroying of the tunX interfaces themselves rather than letting the script do it. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 22:58:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BCFE62CD; Wed, 23 Jan 2013 22:58:46 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mx1.freebsd.org (Postfix) with ESMTP id 77B03751; Wed, 23 Jan 2013 22:58:46 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id un3so8869423obb.21 for ; Wed, 23 Jan 2013 14:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+DhsW/3Zr9W7CBzfIKjSIoneLYDSxq511dO0DdDL9f0=; b=p4aRe86rSr8/nj/GiGC9g2fknELAGx2FPU28bsMyGaKnOGv4CHfFtqttqn9ztCuD+U M8FYuzBKs/D5kju+qGm7tKt1b7nYyaO/vI2oG8kHaa/r1uBtzhTBDgizmXlfD2pufqPU wvfQn9Gcb7/d5589ZC3nhbol4/zVj08nyDmqz66A2DAuxHQw3S89WQYhMQdQNHa1jiXL HYp7WU0wPvH235RZzhUOKeMbTPp8R94TRRapkZYCDVyhMt/sSZFrH4dFs4bs1DIPBwl4 5ZxcrAs0ija4wA4xJjLQ2TPseL58jDEM6iujgAcMLa20/YDN9qQkYxC5xcaZwAR/9qKR oxvQ== MIME-Version: 1.0 X-Received: by 10.182.182.101 with SMTP id ed5mr2443990obc.23.1358981920550; Wed, 23 Jan 2013 14:58:40 -0800 (PST) Received: by 10.76.128.68 with HTTP; Wed, 23 Jan 2013 14:58:40 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Jan 2013 17:58:40 -0500 Message-ID: Subject: Re: e1000 serdes link flap From: Ryan Stone To: Neel Natu Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jack F Vogel , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 22:58:46 -0000 On Wed, Jan 23, 2013 at 2:13 AM, Neel Natu wrote: > Hi, > > I am running into a problem in head with the e1000 link state > detection logic attached to a 82571EB serdes controller. > > The symptom is that the link state keeps flapping between "up" and "down". > > After I enabled the debug output in > 'e1000_check_for_serdes_link_82571()' this is what I see: > > e1000_check_for_serdes_link_82571 > ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 > FORCED_UP -> AN_PROG > em6: link state changed to DOWN > e1000_check_for_serdes_link_82571 > ctrl = 0x4c0201, status = 0x803a4, rxcw = 0x44000000 > AN_PROG -> FORCED_UP > em6: link state changed to UP > e1000_check_for_serdes_link_82571 > ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 > FORCED_UP -> AN_PROG > em6: link state changed to DOWN > > > The problem goes away if I apply the following patch to bring the link > state detection logic in line with the e1000e driver in Linux: > > Index: e1000_82571.c > =================================================================== > --- e1000_82571.c (revision 245766) > +++ e1000_82571.c (working copy) > @@ -1712,10 +1712,8 @@ > * auto-negotiation in the TXCW register and > disable > * forced link in the Device Control register in an > * attempt to auto-negotiate with our link partner. > - * If the partner code word is null, stop forcing > - * and restart auto negotiation. > */ > - if ((rxcw & E1000_RXCW_C) || !(rxcw & > E1000_RXCW_CW)) { > + if ((rxcw & E1000_RXCW_C) != 0) { > /* Enable autoneg, and unforce link up */ > E1000_WRITE_REG(hw, E1000_TXCW, mac->txcw); > E1000_WRITE_REG(hw, E1000_CTRL, > > I am not sure why the !(rxcw & E1000_RXCW_CW) check was added and the > e1000 SDM does not have any more information. > > Jack, can you take a look at the patch and commit if it looks alright? > I have this change applied internally. I thought that it was something funny in my environment, so I never tried to push it upstream. Sorry for costing you time in having to debug this. :( From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 02:31:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E88C5952; Thu, 24 Jan 2013 02:31:31 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6E48AEF8; Thu, 24 Jan 2013 02:31:30 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id l6so7172023vcl.31 for ; Wed, 23 Jan 2013 18:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cwZCwzUPr0Re0TVUaoUG6IsFbwqsG/mIbyx0HSxP0Hs=; b=OZclqy0taVfmrDJfnlDaKDeBbYhQgrDCZnj1a8zxfVPAtC3KL1+wT3v3aTh+76cZI9 4OO+5IgwyGhWKQZMXS8s6FIMfR8U+DAHg5ik4/JCK9aXXs4VnecoLc3b1ZtoZASRNbbW dGdvu4iMqW9MgrNkMLVjnb/V0oqm8IquyfLqKXYddrvajdHPhfbyxiPwD9rkDCC4v4XG 6D1KL544OD84CztFlrqNEtm/rcg0kBSnLCbdVGy78gdvB4qAY9Wfn0qNENKjUlW3pFjA Gotko7Q7SGpn17Ou0jDi2hEYRNSsBBN/54I1PiwuSqdNO98CTlMs1k9DRrZovBpIiQc5 ISRA== MIME-Version: 1.0 X-Received: by 10.52.90.18 with SMTP id bs18mr290391vdb.89.1358994690416; Wed, 23 Jan 2013 18:31:30 -0800 (PST) Received: by 10.58.213.34 with HTTP; Wed, 23 Jan 2013 18:31:30 -0800 (PST) In-Reply-To: <201301231115.06393.jhb@freebsd.org> References: <201301221511.02496.jhb@freebsd.org> <201301231115.06393.jhb@freebsd.org> Date: Thu, 24 Jan 2013 10:31:30 +0800 Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Sepherosa Ziehau To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 02:31:32 -0000 On Thu, Jan 24, 2013 at 12:15 AM, John Baldwin wrote: > On Wednesday, January 23, 2013 1:33:27 am Sepherosa Ziehau wrote: >> On Wed, Jan 23, 2013 at 4:11 AM, John Baldwin wrote: >> > As I mentioned in an earlier thread, I recently had to debug an issue we were >> > seeing across a link with a high bandwidth-delay product (both high bandwidth >> > and high RTT). Our specific use case was to use a TCP connection to reliably >> > forward a latency-sensitive datagram stream across a WAN connection. We would >> > often see spikes in the latency of individual datagrams. I eventually tracked >> > this down to the connection entering slow start when it would transmit data >> > after being idle. The data stream was quite bursty and would often attempt to >> > transmit a burst of data after being idle for far longer than a retransmit >> > timeout. >> > >> > In 7.x we had worked around this in the past by disabling RFC 3390 and jacking >> > the slow start window size up via a sysctl. On 8.x this no longer worked. >> > The solution I came up with was to add a new socket option to disable idle >> > handling completely. That is, when an idle connection restarts with this new >> > option enabled, it keeps its current congestion window and doesn't enter slow >> > start. >> > >> > There are only a few cases where such an option is useful, but if anyone else >> > thinks this might be useful I'd be happy to add the option to FreeBSD. >> >> I think what you need is the RFC2861, however, you probably should >> ignore the "application-limited period" part of RFC2861. > > Hummm. It appears btw, that Linux uses RFC 2861, but has a global knob to > disable it due to applictions having problems. When it is disabled, > it doesn't decay the congestion window at all during idle handling. That is, > it appears to act the same as if TCP_IGNOREIDLE were enabled. > > From http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html: > > tcp_slow_start_after_idle (Boolean; default: enabled; since Linux 2.6.18) > If enabled, provide RFC 2861 behavior and time out the congestion > window after an idle period. An idle period is defined as the current > RTO (retransmission timeout). If disabled, the congestion window will > not be timed out after an idle period. > > Also, in this thread on tcp-m it appears no one on that list realizes that > there are any implementations which follow the "SHOULD" in RFC 2581 for idle > handling (which is what we do currently): Nah, I don't think the idle detection in FreeBSD follows the RFC2581/RFC5681 4.1 (the paragraph before the "SHOULD"). IMHO, that's probably why the author in the following email requestioned about the implementation of "SHOULD" in RFC2581/RFC5681. > > http://www.ietf.org/mail-archive/web/tcpm/current/msg02864.html > > So if we were to implement RFC 2861, the new socket option would be equivalent > to setting Linux's 'tcp_slow_start_after_idle' to false, but on a per-socket > basis rather than globally. Agree, per-socket option could be useful than global sysctls under certain situation. However, in addition to the per-socket option, could global sysctl nodes to disable idle_restart/idle_cwv help too? Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 08:03:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05C90A0D for ; Thu, 24 Jan 2013 08:03:45 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5EAD33 for ; Thu, 24 Jan 2013 08:03:44 +0000 (UTC) Received: (qmail 97248 invoked from network); 24 Jan 2013 09:24:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2013 09:24:46 -0000 Message-ID: <5100EAD3.2090006@networx.ch> Date: Thu, 24 Jan 2013 09:03:31 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sepherosa Ziehau Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <201301231115.06393.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Bjoern Zeeb , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 08:03:45 -0000 On 24.01.2013 03:31, Sepherosa Ziehau wrote: > On Thu, Jan 24, 2013 at 12:15 AM, John Baldwin wrote: >> On Wednesday, January 23, 2013 1:33:27 am Sepherosa Ziehau wrote: >>> On Wed, Jan 23, 2013 at 4:11 AM, John Baldwin wrote: >>>> As I mentioned in an earlier thread, I recently had to debug an issue we were >>>> seeing across a link with a high bandwidth-delay product (both high bandwidth >>>> and high RTT). Our specific use case was to use a TCP connection to reliably >>>> forward a latency-sensitive datagram stream across a WAN connection. We would >>>> often see spikes in the latency of individual datagrams. I eventually tracked >>>> this down to the connection entering slow start when it would transmit data >>>> after being idle. The data stream was quite bursty and would often attempt to >>>> transmit a burst of data after being idle for far longer than a retransmit >>>> timeout. >>>> >>>> In 7.x we had worked around this in the past by disabling RFC 3390 and jacking >>>> the slow start window size up via a sysctl. On 8.x this no longer worked. >>>> The solution I came up with was to add a new socket option to disable idle >>>> handling completely. That is, when an idle connection restarts with this new >>>> option enabled, it keeps its current congestion window and doesn't enter slow >>>> start. >>>> >>>> There are only a few cases where such an option is useful, but if anyone else >>>> thinks this might be useful I'd be happy to add the option to FreeBSD. >>> >>> I think what you need is the RFC2861, however, you probably should >>> ignore the "application-limited period" part of RFC2861. >> >> Hummm. It appears btw, that Linux uses RFC 2861, but has a global knob to >> disable it due to applictions having problems. When it is disabled, >> it doesn't decay the congestion window at all during idle handling. That is, >> it appears to act the same as if TCP_IGNOREIDLE were enabled. >> >> From http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html: >> >> tcp_slow_start_after_idle (Boolean; default: enabled; since Linux 2.6.18) >> If enabled, provide RFC 2861 behavior and time out the congestion >> window after an idle period. An idle period is defined as the current >> RTO (retransmission timeout). If disabled, the congestion window will >> not be timed out after an idle period. >> >> Also, in this thread on tcp-m it appears no one on that list realizes that >> there are any implementations which follow the "SHOULD" in RFC 2581 for idle >> handling (which is what we do currently): > > Nah, I don't think the idle detection in FreeBSD follows the > RFC2581/RFC5681 4.1 (the paragraph before the "SHOULD"). IMHO, that's > probably why the author in the following email requestioned about the > implementation of "SHOULD" in RFC2581/RFC5681. > >> >> http://www.ietf.org/mail-archive/web/tcpm/current/msg02864.html >> >> So if we were to implement RFC 2861, the new socket option would be equivalent >> to setting Linux's 'tcp_slow_start_after_idle' to false, but on a per-socket >> basis rather than globally. > > Agree, per-socket option could be useful than global sysctls under > certain situation. However, in addition to the per-socket option, > could global sysctl nodes to disable idle_restart/idle_cwv help too? No. This is far too dangerous once it makes it into some tuning guide. The threat of congestion breakdown is real. The Internet, or any packet network, can only survive in the long term if almost all follow the rules and self-constrain to remain fair to the others. What would happen if nobody would respect the traffic lights anymore? Besides that bursting into unknown network conditions is very likely to result in burst losses as well. TCP isn't good at recovering from it. In the end you most likely come out ahead if you decay the restartCWND. We have two cases primarily: a) long distance, medium to high RTT, and wildly varying bandwidth (a.k.a. the Internet); b) short distance, low RTT and mostly plenty of bandwidth (a.k.a. Datacenter). The former absolutely definately requires a decayed restartCWND. The latter less so but even there bursting at 10Gig TSO assisted wirespeed isn't going to end too happy more often than not. Since this seems to be a burning issue I'll come up with a patch in the next days to add a decaying restartCWND that'll be fair and allow a very quick ramp up if no loss occurs. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 13:02:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C0A64B2B; Thu, 24 Jan 2013 13:02:42 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 702256F0; Thu, 24 Jan 2013 13:02:42 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id BE0A27E84A; Fri, 25 Jan 2013 00:02:34 +1100 (EST) Message-ID: <510130EA.4020700@freebsd.org> Date: Fri, 25 Jan 2013 00:02:34 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks References: <201301141550.13577.jhb@freebsd.org> <201301151416.07231.jhb@freebsd.org> <50FE5473.7000807@freebsd.org> <201301221528.18388.jhb@freebsd.org> In-Reply-To: <201301221528.18388.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 13:02:42 -0000 On 01/23/13 07:28, John Baldwin wrote: > On Tuesday, January 22, 2013 3:57:23 am Lawrence Stewart wrote: >> On 01/16/13 06:16, John Baldwin wrote: >>> On Tuesday, January 15, 2013 3:49:33 am Lawrence Stewart wrote: >>>> On 01/15/13 07:50, John Baldwin wrote: >>>>> The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are >>>>> currently defined as hex values that are individual bits. However, socket >>>>> options are never masked together, they are used as a simple enumeration of >>>>> discrete values. Using a bitmask forces us to run out of bits and makes it >>>>> harder for vendors to try to use a high range of values for local custom >>>>> options (hoping that they never conflict with a new option value added in >>>>> stock FreeBSD). >>>> >>>> Yup. Should we be explicitly #defining the boundary between "bits >>>> reserved for FreeBSD" and "bits for private vendor use"? >>> >>> Oh, we could if you wanted. I'm using 0x1000 locally for both TCP and UDP, >>> but those are completely arbitrary values. Saner ones might be 0x8000000 if >>> we want to do that explicitly. We could perhaps just say that is true for all >>> socket option levels (that is, just define one SO_VENDOR constant or some such >>> but say it applies to all levels)? >> >> A single SO_VENDOR applied to all levels sounds good to me. > > Ok, how about this for wording: > > Index: sys/socket.h > =================================================================== > --- socket.h (revision 245742) > +++ socket.h (working copy) > @@ -143,6 +143,15 @@ typedef __uid_t uid_t; > #endif > > /* > + * Space reserved for new socket options added by third-party vendors. > + * This range applies to all socket option levels. New socket options > + * in FreeBSD should always use an option value less than SO_VENDOR. > + */ > +#if __BSD_VISIBLE > +#define SO_VENDOR 0x80000000 > +#endif > + > +/* > * Structure used for manipulating linger option. > */ > struct linger { Two thumbs up from me. We might also want to #define TCP_VENDOR SO_VENDOR /* FreeBSD TCP socket options must be numerically less than this. */ and so on in each file that defines option levels to provide some hint to people that SO_VENDOR exists? Maybe we don't need the define and just need to put the one line comment at the end of each set of options in each file where a particular level's options are specified. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 13:28:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D931815C; Thu, 24 Jan 2013 13:28:36 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 6009E832; Thu, 24 Jan 2013 13:28:36 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id DD3BA7E88D; Fri, 25 Jan 2013 00:28:34 +1100 (EST) Message-ID: <51013702.8040707@freebsd.org> Date: Fri, 25 Jan 2013 00:28:34 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Some questions about the new TCP congestion control code References: <201301141604.29864.jhb@freebsd.org> <50F5137F.1060207@freebsd.org> <201301151427.50932.jhb@freebsd.org> In-Reply-To: <201301151427.50932.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 13:28:36 -0000 On 01/16/13 06:27, John Baldwin wrote: > On Tuesday, January 15, 2013 3:29:51 am Lawrence Stewart wrote: >> Hi John, >> >> On 01/15/13 08:04, John Baldwin wrote: >>> I was looking at TCP congestion control at work recently and noticed a few >> >> Poor you ;) >> >>> "odd" things in the current code. First, there is this chunk of code in >>> cc_ack_received() in tcp_input.c: >>> >>> static void inline >>> cc_ack_received(struct tcpcb *tp, struct tcphdr *th, uint16_t type) >>> { >>> INP_WLOCK_ASSERT(tp->t_inpcb); >>> >>> tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th); >>> if (tp->snd_cwnd == min(tp->snd_cwnd, tp->snd_wnd)) >>> tp->ccv->flags |= CCF_CWND_LIMITED; >>> else >>> tp->ccv->flags &= ~CCF_CWND_LIMITED; >>> >>> >>> Due to hysterical raisins, snd_cwnd and snd_wnd are u_long values, not >>> integers, so the call to min() results in truncation on 64-bit hosts. >> >> Good catch, but I don't think it matters in practice as neither snd_cwnd >> or snd_wnd will grow past the 32-bit boundary. > > I have a psyhcotic case using cc_cubic where it seems to grow without bound, > though that is a bug in and of itself (and this change did not fix that > issue). I ended up not using cc_cubic (more below) and haven't been able > to track down the root cause of the delay. I can probably provide a test case > to reproduce this if you are interested. hmm I'd certainly be interested in hearing more about this issue with cubic. If you think a test case is easy to come up with, please shoot it through to me when you have the chance. >>> It should probably be ulmin() instead. However, this line seems to be a really >>> obfuscated way to just write: >>> >>> if (tp->snd_cwnd <= tp->snd_wnd) >> >> You are correct, though I'd argue the meaning of the existing code as >> written is clearer compared to your suggested change. >> >>> If that is correct, I would vote for changing this to use the much simpler >>> logic. >> >> Agreed. While I find the existing code slightly clearer in meaning, it's >> not significant enough to warrant keeping it as is when your suggested >> change is simpler, fixes a bug and achieves the same thing. Happy for >> you to change it or I can do it if you prefer. > > I'll leave that to you, thanks. Committed as r245783. >>> Secondly, in the particular case I was investigating at work (restart of an >>> idle connnection), the newreno congestion control code in 8.x and later uses a >>> different algorithm than in 7. Specifically, in 7 TCP would reuse the same >>> logic used for an initial cwnd (honoring ss_fltsz). In 8 this no longer >>> happens (instead, 2 is hardcoded). A guess at a possible fix might look >>> something like this: >>> >>> Index: cc_newreno.c >>> =================================================================== >>> --- cc_newreno.c (revision 243660) >>> +++ cc_newreno.c (working copy) >>> @@ -169,8 +169,21 @@ newreno_after_idle(struct cc_var *ccv) >>> if (V_tcp_do_rfc3390) >>> rw = min(4 * CCV(ccv, t_maxseg), >>> max(2 * CCV(ccv, t_maxseg), 4380)); >>> +#if 1 >>> else >>> rw = CCV(ccv, t_maxseg) * 2; >>> +#else >>> + /* XXX: This is missing a lot of stuff that used to be in 7. */ >>> +#ifdef INET6 >>> + else if ((isipv6 ? in6_localaddr(&CCV(ccv, t_inpcb->in6p_faddr)) : >>> + in_localaddr(CCV(ccv, t_inpcb->inp_faddr)))) >>> +#else >>> + else if (in_localaddr(CCV(ccv, t_inpcb->inp_faddr))) >>> +#endif >>> + rw = V_ss_fltsz_local * CCV(ccv, t_maxseg); >>> + else >>> + rw = V_ss_fltsz * CCV(ccv, t_maxseg); >>> +#endif >>> >>> CCV(ccv, snd_cwnd) = min(rw, CCV(ccv, snd_cwnd)); >>> } >>> >>> (But using the #else clause instead of the current #if 1 code). Was this >>> change in 8 intentional? >> >> It was. Unlike connection initialisation which still honours ss_fltsz in >> cc_conn_init(), restarting an idle connection based on ss_fltsz seemed >> particularly dubious and as such was omitted from the refactored code. >> >> The ultimate goal was to remove the ss_fltsz hack completely and >> implement a smarter mechanism, but that hasn't quite happened yet. The >> removal of ss_fltsz from 10.x without providing a replacement mechanism >> is not ideal and should probably be addressed. >> >> I'm guessing you're not using rfc3390 because you want to override the >> initial window based on specific local knowledge of the path between >> sender and receiver? > > Correct, in 7.x we had cranked ss_fltsz up to a really high number to prevent > the congestion window from collapsing when the connection was idle. We have > a bit of a unique workload in that we are using TCP to reliably forward a > latency-sensitive datagram stream across a WAN connection with high bandwidth > and high RTT. Most of congestion control seems tuned to bulk transfers rather > than this sort of use case. The solution we have settled on here is to add a > new TCP socket option to disable idle handling so that when an idle connection > restarts it keeps its prior congestion window. I'll respond to this in detail in the other thread. > One other thing I noticed which is may or may not be odd during this, is that > if you have a connection with TCP_NODELAY enabled and you fill your cwnd and > then you get an ACK back for an earlier small segment (less than MSS), TCP > will not send out a "short" segment for the amount of window space released. > Instead, it will wait until a full MSS of space is available before sending > a packet. I'm not sure if that is the correct behavior with TCP_NODELAY or > if we should send "short" segments in that case. We try fairly hard not to send runt segments irrespective of NODELAY, but I would be happy to see that change. I'm not aware of any "correct behaviour" we have to adhere to - I think it would be perfectly reasonable to have a sysctl set the lowest number of bytes we'd be willing to send a runt segment for and then key off TCP_NODELAY as to whether we try hard to send an MSS worth or send as soon as we have the min number of bytes worth of window available. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 13:29:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6DCE71F4 for ; Thu, 24 Jan 2013 13:29:21 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by mx1.freebsd.org (Postfix) with ESMTP id 40783843 for ; Thu, 24 Jan 2013 13:29:21 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id lz20so3975513obb.2 for ; Thu, 24 Jan 2013 05:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=bifir+Q8QhgsQsByTBNcun19Q+F8wi6qLNBf1eNC8Kc=; b=eDEKq5h/GGxI7f9QQ3hehAVs+7o1SoyhO6dDUXU+Bmq6DWjpST5r0RMs2L+oHbhu1g D2zVDu4E/7bsfXTZXQ8WFQ+YZAPUyNHdKHXhlZB5fkmHhxqyL4PnTbm9q4LKgtx9FTB6 eqxf3zIb3OjGM/ri0TNPYSJfuRRfmM3wYpA729B/iCl9CFM6U+lpPtkKeE6r3AmL9ei9 onTD5dneoMGSEtTB/ftGn1lud/N/GjzvGUXukJ+UabtSYVYug+Zy7D8EYMgAV9y8g+iU VL3zI7hZ/4ja2awkUlvNdhJhvEcgSKV+JUUFUHrUuxongp4RvpzJluKcdre8J+NgR355 oo/w== X-Received: by 10.50.154.229 with SMTP id vr5mr1132271igb.49.1359034160512; Thu, 24 Jan 2013 05:29:20 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.64.38.65 with HTTP; Thu, 24 Jan 2013 05:29:00 -0800 (PST) From: h bagade Date: Thu, 24 Jan 2013 16:59:00 +0330 X-Google-Sender-Auth: 6SmqMIlJRaQ5kBvaaiI_U3Nvsrw Message-ID: Subject: how to completely makes an interface down? To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 13:29:21 -0000 Hi all, I'm searching for a method or configuration which when I make the interface down, the led goes off. Currently the led still remains on when I shutdowns the interface! Is there any way to do this? From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 14:12:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D40368C for ; Thu, 24 Jan 2013 14:12:40 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 88E4F9CE for ; Thu, 24 Jan 2013 14:12:39 +0000 (UTC) Received: (qmail 3496 invoked from network); 24 Jan 2013 15:33:44 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2013 15:33:44 -0000 Message-ID: <51014150.50101@networx.ch> Date: Thu, 24 Jan 2013 15:12:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: Some questions about the new TCP congestion control code References: <201301141604.29864.jhb@freebsd.org> <50F5137F.1060207@freebsd.org> <201301151427.50932.jhb@freebsd.org> <51013702.8040707@freebsd.org> In-Reply-To: <51013702.8040707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 14:12:40 -0000 On 24.01.2013 14:28, Lawrence Stewart wrote: > On 01/16/13 06:27, John Baldwin wrote: >> One other thing I noticed which is may or may not be odd during this, is that >> if you have a connection with TCP_NODELAY enabled and you fill your cwnd and >> then you get an ACK back for an earlier small segment (less than MSS), TCP >> will not send out a "short" segment for the amount of window space released. >> Instead, it will wait until a full MSS of space is available before sending >> a packet. I'm not sure if that is the correct behavior with TCP_NODELAY or >> if we should send "short" segments in that case. > > We try fairly hard not to send runt segments irrespective of NODELAY, > but I would be happy to see that change. I'm not aware of any "correct > behaviour" we have to adhere to - I think it would be perfectly > reasonable to have a sysctl set the lowest number of bytes we'd be > willing to send a runt segment for and then key off TCP_NODELAY as to > whether we try hard to send an MSS worth or send as soon as we have the > min number of bytes worth of window available. This is classic silly window syndrome prevention applied to the CWND. Sending a small segment when the window opens just a bit isn't going to help much and mostly clogs the network. This is actually a side effect of ABC (appropriate byte counting) where not the ACK's are counted but the bytes ACK'ed. Disabling ABC will solve this problem. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 15:09:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 54B291D5 for ; Thu, 24 Jan 2013 15:09:13 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C7D9AE03 for ; Thu, 24 Jan 2013 15:09:12 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r0OF94d2029512; Thu, 24 Jan 2013 16:09:04 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0OF94Ls029511; Thu, 24 Jan 2013 16:09:04 +0100 (CET) (envelope-from marius) Date: Thu, 24 Jan 2013 16:09:04 +0100 From: Marius Strobl To: Paul Keusemann Subject: Re: Cas driver fails to load first time after boot. Message-ID: <20130124150904.GA27559@alchemy.franken.de> References: <50FEFAB8.1070006@visi.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <50FEFAB8.1070006@visi.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 15:09:13 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: > Hi, > > I've got a Dell R200 which I'm trying to build into a gateway with a Sun > QGE (501-6738-10). The cas driver fails to load the first time I try to > load it but succeeds the second time. Is this a problem with the card, > the driver, my karma? Wrong phase of the moon, apparently :) The MII setup of these chips is a bit tricky and I'm not sure whether I've hit all code paths during development of the driver. I certainly didn't test with a 501-6738, these have been reported as working before, though. It also doesn't make much sense that attaching the devices succeeds on the second attempt. Could you please use a if_cas.ko built with the attached patch and report the debug output for one of the interfaces in both the working and the non-working case? Marius --5vNYLRcllDrimb99 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="if_cas.c.diff" Index: if_cas.c =================================================================== --- if_cas.c (revision 245046) +++ if_cas.c (working copy) @@ -332,6 +332,8 @@ cas_attach(struct cas_softc *sc) */ error = ENXIO; v = CAS_READ_4(sc, CAS_MIF_CONF); +device_printf(sc->sc_dev, "MIF=0x%x PCFG=0x%x\n", v, +CAS_READ_4(sc, CAS_SATURN_PCFG)); if ((v & CAS_MIF_CONF_MDI1) != 0) { v |= CAS_MIF_CONF_PHY_SELECT; CAS_WRITE_4(sc, CAS_MIF_CONF, v); @@ -347,6 +349,8 @@ cas_attach(struct cas_softc *sc) error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp, cas_mediachange, cas_mediastatus, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, MIIF_DOPAUSE); +if (error == 0) +device_printf(sc->sc_dev, "external PHY\n"); } /* * Fall back on an internal PHY if no external PHY was found. @@ -367,6 +371,8 @@ cas_attach(struct cas_softc *sc) error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp, cas_mediachange, cas_mediastatus, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, MIIF_DOPAUSE); +if (error == 0) +device_printf(sc->sc_dev, "internal PHY\n"); } } else { /* --5vNYLRcllDrimb99-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 17:23:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4DB0E675 for ; Thu, 24 Jan 2013 17:23:57 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-ia0-x22a.google.com (ia-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 157D28A9 for ; Thu, 24 Jan 2013 17:23:57 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id k20so5162819iak.15 for ; Thu, 24 Jan 2013 09:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=UsWZZbFLBzmwzaDaFv/CZyJXYQXSfvyo4eAcshDO9Cs=; b=DamPZ3DSXByd/15xkHA9xSdBwtJ4Os2HhmeW5nqh+9mROqf1c+BoIVxau+Ry/WaSml L2YzFA7RJJ8LyD/g7rbcrs8CP80D3qZqEKUUw51+AIovO0r4HoJqGXvcIq9a3KjL9WSZ DRIE4DYBPli2qUSalB+xkR/9P8+7VgE+rG/+IHKraUuq4hjep/FSffBzF4+1ekGJJc7B P3IPWt2zURxsJDyRQSuzwvyBjSvP/1iDtkZxjiKn1tSW1NKdRE/FyzjU5TMjXFZaF8Tm ssv5qk9D22DRt5axEZAxnzu9zW0mitJ8QI4m0DDhTjTEGKcOvEwGcyGaaT4xyiVC4jfR LEcg== MIME-Version: 1.0 X-Received: by 10.50.222.228 with SMTP id qp4mr1905913igc.87.1359048236133; Thu, 24 Jan 2013 09:23:56 -0800 (PST) Received: by 10.64.53.100 with HTTP; Thu, 24 Jan 2013 09:23:55 -0800 (PST) Date: Thu, 24 Jan 2013 12:23:55 -0500 Message-ID: Subject: Block ACK in Ralink RT2860 From: Ramanujan Seshadri To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 17:23:57 -0000 Hi all, I am trying to read the contents of block ack's in a Ralink RT2860 driver. Can you please help me to know which function i should be looking into ? Thanks ram From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 17:26:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E541373F for ; Thu, 24 Jan 2013 17:26:47 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id B0AF68D1 for ; Thu, 24 Jan 2013 17:26:47 +0000 (UTC) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) by mbox1.develooper.com (Postfix) with ESMTP id 46986175A67 for ; Thu, 24 Jan 2013 09:26:47 -0800 (PST) Received: (qmail 15738 invoked from network); 24 Jan 2013 17:26:47 -0000 Received: from cpe-76-172-28-38.socal.res.rr.com (HELO embla.bn.dev) (ask@mail.dev@76.172.28.38) by smtp.develooper.com with ESMTPA; 24 Jan 2013 17:26:47 -0000 From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Carp configuration errors Message-Id: <0154442B-C0E9-4731-A85E-1A44F3ED1F47@develooper.com> Date: Thu, 24 Jan 2013 09:26:46 -0800 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 17:26:48 -0000 Hello, After upgrading to 9.1 it seems like carp doesn't pay attention to = advskew anymore. I have two boxes each setup with carp0 and carp1; the = intention is that in regular operation proxy1 is master for carp0 and = proxy2 for carp1. However, whichever box comes up second is BACKUP for = both. To make IPv6 CARP work I am using the patch from = http://www.freebsd.org/cgi/query-pr.cgi?pr=3D127050 I don't know if it is related, but when booting I see a lot of messages = like ifa_del_loopback_route: deletion failed ifa_add_loopback_route: insertion failed ifa_del_loopback_route: deletion failed ifa_add_loopback_route: insertion failed ifa_del_loopback_route: deletion failed ifa_add_loopback_route: insertion failed ifa_del_loopback_route: deletion failed ifa_add_loopback_route: insertion failed in dmesg. I am including my rc.conf files for each host below. Any hints or = suggestions will be appreciated. Ask # proxy1 sshd_enable=3D"YES" ntpd_enable=3D"YES" ntpd_flags=3D"-p /var/run/ntpd.pid -f /etc/ntp/ntpd.drift -g" hostname=3D"proxy1.dev" ifconfig_vr0=3D"inet 10.0.100.31/24" ifconfig_vr2=3D"inet 207.171.7.31/24" ifconfig_vr2_ipv6=3D"inet6 2607:f238:3::1:1/64" ifconfig_carp0=3D"vhid 40 advskew 50 pass y4t8gwtgjkq4g 207.171.7.40" ipv4_addrs_carp0=3D"207.171.7.41-49/24" ifconfig_carp0_ipv6=3D"inet6 2607:f238:3::1:41/64" ifconfig_carp0_alias0=3D"inet6 2607:f238:3::1:40/64" ifconfig_carp0_alias1=3D"inet6 2607:f238:3::1:42/64" ifconfig_carp0_alias2=3D"inet6 2607:f238:3::1:43/64" ifconfig_carp0_alias3=3D"inet6 2607:f238:3::1:44/64" ifconfig_carp0_alias4=3D"inet6 2607:f238:3::1:45/64" ifconfig_carp0_alias5=3D"inet6 2607:f238:3::1:46/64" ifconfig_carp0_alias6=3D"inet6 2607:f238:3::1:47/64" ifconfig_carp0_alias7=3D"inet6 2607:f238:3::1:48/64" ifconfig_carp0_alias8=3D"inet6 2607:f238:3::1:49/64" ifconfig_carp1=3D"vhid 50 advskew 250 pass hsjrthvruwybwt 207.171.7.50" ipv4_addrs_carp1=3D"207.171.7.51-59/24" ifconfig_carp1_ipv6=3D"inet6 2607:f238:3::1:51/64" ifconfig_carp1_alias0=3D"inet6 2607:f238:3::1:50/64" ifconfig_carp1_alias1=3D"inet6 2607:f238:3::1:52/64" ifconfig_carp1_alias2=3D"inet6 2607:f238:3::1:53/64" ifconfig_carp1_alias3=3D"inet6 2607:f238:3::1:54/64" ifconfig_carp1_alias4=3D"inet6 2607:f238:3::1:55/64" ifconfig_carp1_alias5=3D"inet6 2607:f238:3::1:56/64" ifconfig_carp1_alias6=3D"inet6 2607:f238:3::1:57/64" ifconfig_carp1_alias7=3D"inet6 2607:f238:3::1:58/64" ifconfig_carp1_alias8=3D"inet6 2607:f238:3::1:59/64" ifconfig_vr1=3D"down" defaultrouter=3D"207.171.7.1" ipv6_defaultrouter=3D"2607:F238:3::1" ifconfig_lo0_alias0=3D"inet 127.0.0.2" ifconfig_lo0_alias1=3D"inet 127.0.0.3" cloned_interfaces=3D"carp0 carp1" static_routes=3D"${static_routes} vpn" route_vpn=3D"-net 10.0.0.0/16 10.0.100.1" pf_enable=3D"NO" pflog_enable=3D"NO" haproxy_enable=3D"YES" haproxy_config=3D"/etc/haproxy.conf" ####### # proxy2 sshd_enable=3D"YES" ntpd_enable=3D"YES" ntpd_flags=3D"-p /var/run/ntpd.pid -f /etc/ntp/ntpd.drift -g" hostname=3D"proxy2.dev" ifconfig_vr0=3D"inet 10.0.100.32/24" ifconfig_vr2=3D"inet 207.171.7.32/24" ifconfig_vr2_ipv6=3D"inet6 2607:f238:3::1:2/64" ifconfig_carp0=3D"vhid 40 advskew 150 pass y4t8gwtgjkq4g 207.171.7.40" ipv4_addrs_carp0=3D"207.171.7.41-49/24" ifconfig_carp0_ipv6=3D"inet6 2607:f238:3::1:41/64" ifconfig_carp0_alias0=3D"inet6 2607:f238:3::1:40/64" ifconfig_carp0_alias1=3D"inet6 2607:f238:3::1:42/64" ifconfig_carp0_alias2=3D"inet6 2607:f238:3::1:43/64" ifconfig_carp0_alias3=3D"inet6 2607:f238:3::1:44/64" ifconfig_carp0_alias4=3D"inet6 2607:f238:3::1:45/64" ifconfig_carp0_alias5=3D"inet6 2607:f238:3::1:46/64" ifconfig_carp0_alias6=3D"inet6 2607:f238:3::1:47/64" ifconfig_carp0_alias7=3D"inet6 2607:f238:3::1:48/64" ifconfig_carp0_alias8=3D"inet6 2607:f238:3::1:49/64" ifconfig_carp1=3D"vhid 50 advskew 100 pass hsjrthvruwybwt 207.171.7.50" ipv4_addrs_carp1=3D"207.171.7.51-59/24" ifconfig_carp1_ipv6=3D"inet6 2607:f238:3::1:51/64" ifconfig_carp1_alias0=3D"inet6 2607:f238:3::1:50/64" ifconfig_carp1_alias1=3D"inet6 2607:f238:3::1:52/64" ifconfig_carp1_alias2=3D"inet6 2607:f238:3::1:53/64" ifconfig_carp1_alias3=3D"inet6 2607:f238:3::1:54/64" ifconfig_carp1_alias4=3D"inet6 2607:f238:3::1:55/64" ifconfig_carp1_alias5=3D"inet6 2607:f238:3::1:56/64" ifconfig_carp1_alias6=3D"inet6 2607:f238:3::1:57/64" ifconfig_carp1_alias7=3D"inet6 2607:f238:3::1:58/64" ifconfig_carp1_alias8=3D"inet6 2607:f238:3::1:59/64" ifconfig_vr1=3D"down" defaultrouter=3D"207.171.7.1" ipv6_defaultrouter=3D"2607:F238:3::1" ifconfig_lo0_alias0=3D"inet 127.0.0.2" ifconfig_lo0_alias1=3D"inet 127.0.0.3" cloned_interfaces=3D"carp0 carp1" static_routes=3D"${static_routes} vpn" route_vpn=3D"-net 10.0.0.0/16 10.0.100.1" pf_enable=3D"NO" pflog_enable=3D"NO" haproxy_enable=3D"YES" haproxy_config=3D"/etc/haproxy.conf" svscan_enable=3D"NO" svscan_servicedir=3D"/etc/svscan" From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 17:26:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 92DAA742 for ; Thu, 24 Jan 2013 17:26:52 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE788D2 for ; Thu, 24 Jan 2013 17:26:52 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rr4so3734795pbb.41 for ; Thu, 24 Jan 2013 09:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y6NLsI6uCSR2tdK7PuTyU4sshSfGhbMfTJ4lKosb7oE=; b=jNb0yVMBHegmTdaHt7wsAM4pWS70e8IZUe+0n38WVCTk6CcI3iYOuBMtVrGrZvUPoh 1MzIVBQaJCePLYT5HaqT0TEYsKBu+XsXSQ04zte/csehaGvbaQmGG4cT2ETCKe+axDgJ Jspf0IpgouCqKbXVZlmgJL2lVS1doP1hTiT2sJqhk2JhynX6WnGE16izupitEtNDMKz8 kCfeQDsZVVBCePZc9yIdKIHTGySKYW6f9X6Lvgv4CyqYnNxyQlm8vuXOTTXyqwxGM5mh dN+gXgZz1sirFfdmiGOvdYqv8uCUvndF/CkzK0YbuPg0Hm4O3cJGrQCCmYgJa03xbCVY Gx8w== MIME-Version: 1.0 X-Received: by 10.66.73.138 with SMTP id l10mr6486100pav.44.1359048411985; Thu, 24 Jan 2013 09:26:51 -0800 (PST) Received: by 10.67.2.65 with HTTP; Thu, 24 Jan 2013 09:26:51 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Jan 2013 09:26:51 -0800 Message-ID: Subject: Re: how to completely makes an interface down? From: Kevin Oberman To: h bagade Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 17:26:52 -0000 On Thu, Jan 24, 2013 at 5:29 AM, h bagade wrote: > Hi all, > > I'm searching for a method or configuration which when I make the interface > down, the led goes off. Currently the led still remains on when I shutdowns > the interface! Is there any way to do this? Depends on the interface, but on many devices the only way to turn off the LED is to unplug the cable or turn off the device in the other end. The LED is lit by the power on the receive pair and the LED will remain on even if the system is turned off and the power cord pulled as the remote end is really lighting the LED. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 18:39:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FFC62E9 for ; Thu, 24 Jan 2013 18:39:55 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront4.g2host.com [208.42.184.242]) by mx1.freebsd.org (Postfix) with ESMTP id 99891D84 for ; Thu, 24 Jan 2013 18:39:53 +0000 (UTC) Received: from [173.17.248.27] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 94419042; Thu, 24 Jan 2013 12:39:47 -0600 Message-ID: <51017FF0.5080001@visi.com> Date: Thu, 24 Jan 2013 12:39:44 -0600 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Cas driver fails to load first time after boot. References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> In-Reply-To: <20130124150904.GA27559@alchemy.franken.de> X-Is-From-Me: yes Content-Type: multipart/mixed; boundary="------------010304030601040705070206" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 18:39:55 -0000 This is a multi-part message in MIME format. --------------010304030601040705070206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/24/13 09:09, Marius Strobl wrote: > On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: >> Hi, >> >> I've got a Dell R200 which I'm trying to build into a gateway with a Sun >> QGE (501-6738-10). The cas driver fails to load the first time I try to >> load it but succeeds the second time. Is this a problem with the card, >> the driver, my karma? > Wrong phase of the moon, apparently :) > The MII setup of these chips is a bit tricky and I'm not sure whether > I've hit all code paths during development of the driver. I certainly > didn't test with a 501-6738, these have been reported as working before, > though. It also doesn't make much sense that attaching the devices > succeeds on the second attempt. Could you please use a if_cas.ko built > with the attached patch and report the debug output for one of the > interfaces in both the working and the non-working case? I would love to give you output from the working and non-working case but apparently the phase of the moon has changed, I can't get it to fail now. The messages output from the working case is attached. Let me know if there's anything else I can do. > Marius > -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 --------------010304030601040705070206 Content-Type: text/plain; charset=us-ascii; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages" Jan 24 11:00:01 lucid newsyslog[2087]: logfile turned over due to size>100K Jan 24 11:47:39 lucid shutdown: reboot by toor: Jan 24 11:47:41 lucid syslogd: exiting on signal 15 Jan 24 11:48:51 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 24 11:48:51 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 24 11:48:51 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 24 11:48:51 lucid kernel: The Regents of the University of California. All rights reserved. Jan 24 11:48:51 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 24 11:48:51 lucid kernel: FreeBSD 8.3-RELEASE #0: Thu Jan 24 11:15:13 CST 2013 Jan 24 11:48:51 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 24 11:48:51 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 24 11:48:51 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 24 11:48:51 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 24 11:48:51 lucid kernel: Features=0xbfebfbff Jan 24 11:48:51 lucid kernel: Features2=0xe3bd Jan 24 11:48:51 lucid kernel: AMD Features=0x20100800 Jan 24 11:48:51 lucid kernel: AMD Features2=0x1 Jan 24 11:48:51 lucid kernel: TSC: P-state invariant Jan 24 11:48:51 lucid kernel: real memory = 4294967296 (4096 MB) Jan 24 11:48:51 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 24 11:48:51 lucid kernel: ACPI APIC Table: Jan 24 11:48:51 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 24 11:48:51 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 24 11:48:51 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 24 11:48:51 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 24 11:48:51 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 24 11:48:51 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 24 11:48:51 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 24 11:48:51 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 24 11:48:51 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 24 11:48:51 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 24 11:48:51 lucid kernel: kbd1 at kbdmux0 Jan 24 11:48:51 lucid kernel: acpi0: on motherboard Jan 24 11:48:51 lucid kernel: acpi0: [ITHREAD] Jan 24 11:48:51 lucid kernel: acpi0: Power Button (fixed) Jan 24 11:48:51 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 24 11:48:51 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 24 11:48:51 lucid kernel: cpu0: on acpi0 Jan 24 11:48:51 lucid kernel: cpu1: on acpi0 Jan 24 11:48:51 lucid kernel: cpu2: on acpi0 Jan 24 11:48:51 lucid kernel: cpu3: on acpi0 Jan 24 11:48:51 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 24 11:48:51 lucid kernel: pci0: on pcib0 Jan 24 11:48:51 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 24 11:48:51 lucid kernel: pci1: on pcib1 Jan 24 11:48:51 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 24 11:48:51 lucid kernel: pci2: on pcib2 Jan 24 11:48:51 lucid kernel: pcib3: at device 0.0 on pci2 Jan 24 11:48:51 lucid kernel: pci3: on pcib3 Jan 24 11:48:51 lucid kernel: pcib4: at device 2.0 on pci3 Jan 24 11:48:51 lucid kernel: pci4: on pcib4 Jan 24 11:48:51 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 11:48:51 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 24 11:48:51 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 11:48:51 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 24 11:48:51 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 24 11:48:51 lucid kernel: pci5: on pcib5 Jan 24 11:48:51 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 24 11:48:51 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 11:48:51 lucid kernel: miibus0: on bge0 Jan 24 11:48:51 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 24 11:48:51 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:48:51 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 24 11:48:51 lucid kernel: bge0: [ITHREAD] Jan 24 11:48:51 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 24 11:48:51 lucid kernel: pci6: on pcib6 Jan 24 11:48:51 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 24 11:48:51 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 11:48:51 lucid kernel: miibus1: on bge1 Jan 24 11:48:51 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 24 11:48:51 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:48:51 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 24 11:48:51 lucid kernel: bge1: [ITHREAD] Jan 24 11:48:51 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 24 11:48:51 lucid kernel: uhci0: [ITHREAD] Jan 24 11:48:51 lucid kernel: usbus0: on uhci0 Jan 24 11:48:51 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 24 11:48:51 lucid kernel: uhci1: [ITHREAD] Jan 24 11:48:51 lucid kernel: usbus1: on uhci1 Jan 24 11:48:51 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 24 11:48:51 lucid kernel: uhci2: [ITHREAD] Jan 24 11:48:51 lucid kernel: usbus2: on uhci2 Jan 24 11:48:51 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 24 11:48:51 lucid kernel: ehci0: [ITHREAD] Jan 24 11:48:51 lucid kernel: usbus3: EHCI version 1.0 Jan 24 11:48:51 lucid kernel: usbus3: on ehci0 Jan 24 11:48:51 lucid kernel: pcib7: at device 30.0 on pci0 Jan 24 11:48:51 lucid kernel: pci7: on pcib7 Jan 24 11:48:51 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 24 11:48:51 lucid kernel: isab0: at device 31.0 on pci0 Jan 24 11:48:51 lucid kernel: isa0: on isab0 Jan 24 11:48:51 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 24 11:48:51 lucid kernel: atapci0: [ITHREAD] Jan 24 11:48:51 lucid kernel: ata2: at channel 0 on atapci0 Jan 24 11:48:51 lucid kernel: ata2: [ITHREAD] Jan 24 11:48:51 lucid kernel: ata3: at channel 1 on atapci0 Jan 24 11:48:51 lucid kernel: ata3: [ITHREAD] Jan 24 11:48:51 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 24 11:48:51 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 24 11:48:51 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 24 11:48:51 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 24 11:48:51 lucid kernel: fdc0: does not respond Jan 24 11:48:51 lucid kernel: device_attach: fdc0 attach returned 6 Jan 24 11:48:51 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 24 11:48:51 lucid kernel: uart0: [FILTER] Jan 24 11:48:51 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 24 11:48:51 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 24 11:48:51 lucid kernel: kbd0 at atkbd0 Jan 24 11:48:51 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 24 11:48:51 lucid kernel: atkbd0: [ITHREAD] Jan 24 11:48:51 lucid kernel: psm0: irq 12 on atkbdc0 Jan 24 11:48:51 lucid kernel: psm0: [GIANT-LOCKED] Jan 24 11:48:51 lucid kernel: psm0: [ITHREAD] Jan 24 11:48:51 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 24 11:48:51 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 24 11:48:51 lucid kernel: sc0: at flags 0x100 on isa0 Jan 24 11:48:51 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 24 11:48:51 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 24 11:48:51 lucid kernel: ppc0: cannot reserve I/O port range Jan 24 11:48:51 lucid kernel: est0: on cpu0 Jan 24 11:48:51 lucid kernel: p4tcc0: on cpu0 Jan 24 11:48:51 lucid kernel: est1: on cpu1 Jan 24 11:48:51 lucid kernel: p4tcc1: on cpu1 Jan 24 11:48:51 lucid kernel: est2: on cpu2 Jan 24 11:48:51 lucid kernel: p4tcc2: on cpu2 Jan 24 11:48:51 lucid kernel: est3: on cpu3 Jan 24 11:48:51 lucid kernel: p4tcc3: on cpu3 Jan 24 11:48:51 lucid kernel: Timecounters tick every 1.000 msec Jan 24 11:48:51 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 24 11:48:51 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 24 11:48:51 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 24 11:48:51 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 24 11:48:51 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 24 11:48:51 lucid kernel: ugen0.1: at usbus0 Jan 24 11:48:51 lucid kernel: uhub0: on usbus0 Jan 24 11:48:51 lucid kernel: ugen1.1: at usbus1 Jan 24 11:48:51 lucid kernel: uhub1: on usbus1 Jan 24 11:48:51 lucid kernel: ugen2.1: at usbus2 Jan 24 11:48:51 lucid kernel: uhub2: on usbus2 Jan 24 11:48:51 lucid kernel: ugen3.1: at usbus3 Jan 24 11:48:51 lucid kernel: uhub3: on usbus3 Jan 24 11:48:51 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 24 11:48:51 lucid kernel: SMP: AP CPU #2 Launched! Jan 24 11:48:51 lucid kernel: SMP: AP CPU #1 Launched! Jan 24 11:48:51 lucid kernel: SMP: AP CPU #3 Launched! Jan 24 11:48:51 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 24 11:48:51 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 24 11:48:51 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 24 11:48:51 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 24 11:48:51 lucid kernel: Root mount waiting for: usbus3 Jan 24 11:48:51 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 24 11:48:51 lucid kernel: Root mount waiting for: usbus3 Jan 24 11:48:51 lucid kernel: ugen3.2: at usbus3 Jan 24 11:48:51 lucid kernel: uhub4: on usbus3 Jan 24 11:48:51 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 24 11:48:51 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 24 11:48:53 lucid kernel: bge0: link state changed to UP Jan 24 11:55:17 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 24 11:55:17 lucid kernel: cas0: MIF=0x100 PCFG=0x1f Jan 24 11:55:17 lucid kernel: miibus2: on cas0 Jan 24 11:55:17 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 24 11:55:17 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:55:17 lucid kernel: cas0: internal PHY Jan 24 11:55:17 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:55:17 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 24 11:55:17 lucid kernel: cas0: [FILTER] Jan 24 11:55:17 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 24 11:55:17 lucid kernel: cas1: MIF=0x100 PCFG=0x1f Jan 24 11:55:17 lucid kernel: miibus3: on cas1 Jan 24 11:55:17 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 24 11:55:17 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:55:17 lucid kernel: cas1: internal PHY Jan 24 11:55:17 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:55:17 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 24 11:55:17 lucid kernel: cas1: [FILTER] Jan 24 11:55:17 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 24 11:55:17 lucid kernel: cas2: MIF=0x100 PCFG=0x1f Jan 24 11:55:17 lucid kernel: miibus4: on cas2 Jan 24 11:55:17 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 24 11:55:17 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:55:17 lucid kernel: cas2: internal PHY Jan 24 11:55:17 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:55:17 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 24 11:55:17 lucid kernel: cas2: [FILTER] Jan 24 11:55:17 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 24 11:55:17 lucid kernel: cas3: MIF=0x100 PCFG=0x1f Jan 24 11:55:17 lucid kernel: miibus5: on cas3 Jan 24 11:55:17 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 24 11:55:17 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:55:17 lucid kernel: cas3: internal PHY Jan 24 11:55:17 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:55:17 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 24 11:55:17 lucid kernel: cas3: [FILTER] Jan 24 11:58:46 lucid kernel: nsgphy0: detached Jan 24 11:58:46 lucid kernel: miibus2: detached Jan 24 11:58:46 lucid kernel: cas0: detached Jan 24 11:58:46 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 11:58:46 lucid kernel: nsgphy1: detached Jan 24 11:58:46 lucid kernel: miibus3: detached Jan 24 11:58:46 lucid kernel: cas1: detached Jan 24 11:58:46 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 24 11:58:46 lucid kernel: nsgphy2: detached Jan 24 11:58:46 lucid kernel: miibus4: detached Jan 24 11:58:46 lucid kernel: cas2: detached Jan 24 11:58:46 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 11:58:46 lucid kernel: nsgphy3: detached Jan 24 11:58:46 lucid kernel: miibus5: detached Jan 24 11:58:46 lucid kernel: cas3: detached Jan 24 11:58:46 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 24 11:59:11 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 24 11:59:11 lucid kernel: cas0: MIF=0x100 PCFG=0x1f Jan 24 11:59:11 lucid kernel: miibus2: on cas0 Jan 24 11:59:11 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 24 11:59:11 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:59:11 lucid kernel: cas0: internal PHY Jan 24 11:59:11 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:59:11 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 24 11:59:11 lucid kernel: cas0: [FILTER] Jan 24 11:59:11 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 24 11:59:11 lucid kernel: cas1: MIF=0x100 PCFG=0x1f Jan 24 11:59:11 lucid kernel: miibus3: on cas1 Jan 24 11:59:11 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 24 11:59:11 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:59:11 lucid kernel: cas1: internal PHY Jan 24 11:59:11 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:59:11 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 24 11:59:11 lucid kernel: cas1: [FILTER] Jan 24 11:59:11 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 24 11:59:11 lucid kernel: cas2: MIF=0x100 PCFG=0x1f Jan 24 11:59:11 lucid kernel: miibus4: on cas2 Jan 24 11:59:11 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 24 11:59:11 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:59:11 lucid kernel: cas2: internal PHY Jan 24 11:59:11 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:59:11 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 24 11:59:11 lucid kernel: cas2: [FILTER] Jan 24 11:59:11 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 24 11:59:11 lucid kernel: cas3: MIF=0x100 PCFG=0x1f Jan 24 11:59:11 lucid kernel: miibus5: on cas3 Jan 24 11:59:11 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 24 11:59:11 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 11:59:11 lucid kernel: cas3: internal PHY Jan 24 11:59:11 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 24 11:59:11 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 24 11:59:11 lucid kernel: cas3: [FILTER] Jan 24 12:04:59 lucid shutdown: reboot by toor: Jan 24 12:05:01 lucid syslogd: exiting on signal 15 Jan 24 12:06:20 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 24 12:06:20 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 24 12:06:20 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 24 12:06:20 lucid kernel: The Regents of the University of California. All rights reserved. Jan 24 12:06:20 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 24 12:06:20 lucid kernel: FreeBSD 8.3-RELEASE #0: Thu Jan 24 11:15:13 CST 2013 Jan 24 12:06:20 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 24 12:06:20 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 24 12:06:20 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 24 12:06:20 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 24 12:06:20 lucid kernel: Features=0xbfebfbff Jan 24 12:06:20 lucid kernel: Features2=0xe3bd Jan 24 12:06:20 lucid kernel: AMD Features=0x20100800 Jan 24 12:06:20 lucid kernel: AMD Features2=0x1 Jan 24 12:06:20 lucid kernel: TSC: P-state invariant Jan 24 12:06:20 lucid kernel: real memory = 4294967296 (4096 MB) Jan 24 12:06:20 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 24 12:06:20 lucid kernel: ACPI APIC Table: Jan 24 12:06:20 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 24 12:06:20 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 24 12:06:20 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 24 12:06:20 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 24 12:06:20 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 24 12:06:20 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 24 12:06:20 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 24 12:06:20 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 24 12:06:20 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 24 12:06:20 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 24 12:06:20 lucid kernel: kbd1 at kbdmux0 Jan 24 12:06:20 lucid kernel: acpi0: on motherboard Jan 24 12:06:20 lucid kernel: acpi0: [ITHREAD] Jan 24 12:06:20 lucid kernel: acpi0: Power Button (fixed) Jan 24 12:06:20 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 24 12:06:20 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 24 12:06:20 lucid kernel: cpu0: on acpi0 Jan 24 12:06:20 lucid kernel: cpu1: on acpi0 Jan 24 12:06:20 lucid kernel: cpu2: on acpi0 Jan 24 12:06:20 lucid kernel: cpu3: on acpi0 Jan 24 12:06:20 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 24 12:06:20 lucid kernel: pci0: on pcib0 Jan 24 12:06:20 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 24 12:06:20 lucid kernel: pci1: on pcib1 Jan 24 12:06:20 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 24 12:06:20 lucid kernel: pci2: on pcib2 Jan 24 12:06:20 lucid kernel: pcib3: at device 0.0 on pci2 Jan 24 12:06:20 lucid kernel: pci3: on pcib3 Jan 24 12:06:20 lucid kernel: pcib4: at device 2.0 on pci3 Jan 24 12:06:20 lucid kernel: pci4: on pcib4 Jan 24 12:06:20 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 12:06:20 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 24 12:06:20 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 12:06:20 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 24 12:06:20 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 24 12:06:20 lucid kernel: pci5: on pcib5 Jan 24 12:06:20 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 24 12:06:20 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 12:06:20 lucid kernel: miibus0: on bge0 Jan 24 12:06:20 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 24 12:06:20 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:06:20 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 24 12:06:20 lucid kernel: bge0: [ITHREAD] Jan 24 12:06:20 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 24 12:06:20 lucid kernel: pci6: on pcib6 Jan 24 12:06:20 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 24 12:06:20 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 12:06:20 lucid kernel: miibus1: on bge1 Jan 24 12:06:20 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 24 12:06:20 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:06:20 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 24 12:06:20 lucid kernel: bge1: [ITHREAD] Jan 24 12:06:20 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 24 12:06:20 lucid kernel: uhci0: [ITHREAD] Jan 24 12:06:20 lucid kernel: usbus0: on uhci0 Jan 24 12:06:20 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 24 12:06:20 lucid kernel: uhci1: [ITHREAD] Jan 24 12:06:20 lucid kernel: usbus1: on uhci1 Jan 24 12:06:20 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 24 12:06:20 lucid kernel: uhci2: [ITHREAD] Jan 24 12:06:20 lucid kernel: usbus2: on uhci2 Jan 24 12:06:20 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 24 12:06:20 lucid kernel: ehci0: [ITHREAD] Jan 24 12:06:20 lucid kernel: usbus3: EHCI version 1.0 Jan 24 12:06:20 lucid kernel: usbus3: on ehci0 Jan 24 12:06:20 lucid kernel: pcib7: at device 30.0 on pci0 Jan 24 12:06:20 lucid kernel: pci7: on pcib7 Jan 24 12:06:20 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 24 12:06:20 lucid kernel: isab0: at device 31.0 on pci0 Jan 24 12:06:20 lucid kernel: isa0: on isab0 Jan 24 12:06:20 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 24 12:06:20 lucid kernel: atapci0: [ITHREAD] Jan 24 12:06:20 lucid kernel: ata2: at channel 0 on atapci0 Jan 24 12:06:20 lucid kernel: ata2: [ITHREAD] Jan 24 12:06:20 lucid kernel: ata3: at channel 1 on atapci0 Jan 24 12:06:20 lucid kernel: ata3: [ITHREAD] Jan 24 12:06:20 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 24 12:06:20 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 24 12:06:20 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 24 12:06:20 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 24 12:06:20 lucid kernel: fdc0: does not respond Jan 24 12:06:20 lucid kernel: device_attach: fdc0 attach returned 6 Jan 24 12:06:20 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 24 12:06:20 lucid kernel: uart0: [FILTER] Jan 24 12:06:20 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 24 12:06:20 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 24 12:06:20 lucid kernel: kbd0 at atkbd0 Jan 24 12:06:20 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 24 12:06:20 lucid kernel: atkbd0: [ITHREAD] Jan 24 12:06:20 lucid kernel: psm0: irq 12 on atkbdc0 Jan 24 12:06:20 lucid kernel: psm0: [GIANT-LOCKED] Jan 24 12:06:20 lucid kernel: psm0: [ITHREAD] Jan 24 12:06:20 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 24 12:06:20 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 24 12:06:20 lucid kernel: sc0: at flags 0x100 on isa0 Jan 24 12:06:20 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 24 12:06:20 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 24 12:06:20 lucid kernel: ppc0: cannot reserve I/O port range Jan 24 12:06:20 lucid kernel: est0: on cpu0 Jan 24 12:06:20 lucid kernel: p4tcc0: on cpu0 Jan 24 12:06:20 lucid kernel: est1: on cpu1 Jan 24 12:06:20 lucid kernel: p4tcc1: on cpu1 Jan 24 12:06:20 lucid kernel: est2: on cpu2 Jan 24 12:06:20 lucid kernel: p4tcc2: on cpu2 Jan 24 12:06:20 lucid kernel: est3: on cpu3 Jan 24 12:06:20 lucid kernel: p4tcc3: on cpu3 Jan 24 12:06:20 lucid kernel: Timecounters tick every 1.000 msec Jan 24 12:06:20 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 24 12:06:20 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 24 12:06:20 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 24 12:06:20 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 24 12:06:20 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 24 12:06:20 lucid kernel: ugen0.1: at usbus0 Jan 24 12:06:20 lucid kernel: uhub0: on usbus0 Jan 24 12:06:20 lucid kernel: ugen1.1: at usbus1 Jan 24 12:06:20 lucid kernel: uhub1: on usbus1 Jan 24 12:06:20 lucid kernel: ugen2.1: at usbus2 Jan 24 12:06:20 lucid kernel: uhub2: on usbus2 Jan 24 12:06:20 lucid kernel: ugen3.1: at usbus3 Jan 24 12:06:20 lucid kernel: uhub3: on usbus3 Jan 24 12:06:20 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 24 12:06:20 lucid kernel: SMP: AP CPU #2 Launched! Jan 24 12:06:20 lucid kernel: SMP: AP CPU #1 Launched! Jan 24 12:06:20 lucid kernel: SMP: AP CPU #3 Launched! Jan 24 12:06:20 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 24 12:06:20 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 24 12:06:20 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 24 12:06:20 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 24 12:06:20 lucid kernel: Root mount waiting for: usbus3 Jan 24 12:06:20 lucid kernel: Root mount waiting for: usbus3 Jan 24 12:06:20 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 24 12:06:20 lucid kernel: Root mount waiting for: usbus3 Jan 24 12:06:20 lucid kernel: ugen3.2: at usbus3 Jan 24 12:06:20 lucid kernel: uhub4: on usbus3 Jan 24 12:06:20 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 24 12:06:20 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 24 12:06:22 lucid kernel: bge0: link state changed to UP Jan 24 12:22:21 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 24 12:22:21 lucid kernel: cas0: MIF=0x100 PCFG=0x1f Jan 24 12:22:21 lucid kernel: miibus2: on cas0 Jan 24 12:22:21 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 24 12:22:21 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:21 lucid kernel: cas0: internal PHY Jan 24 12:22:21 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:21 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 24 12:22:21 lucid kernel: cas0: [FILTER] Jan 24 12:22:21 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 24 12:22:21 lucid kernel: cas1: MIF=0x100 PCFG=0x1f Jan 24 12:22:21 lucid kernel: miibus3: on cas1 Jan 24 12:22:21 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 24 12:22:21 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:21 lucid kernel: cas1: internal PHY Jan 24 12:22:21 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:21 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 24 12:22:21 lucid kernel: cas1: [FILTER] Jan 24 12:22:21 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 24 12:22:21 lucid kernel: cas2: MIF=0x100 PCFG=0x1f Jan 24 12:22:21 lucid kernel: miibus4: on cas2 Jan 24 12:22:21 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 24 12:22:21 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:21 lucid kernel: cas2: internal PHY Jan 24 12:22:21 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:21 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 24 12:22:21 lucid kernel: cas2: [FILTER] Jan 24 12:22:21 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 24 12:22:21 lucid kernel: cas3: MIF=0x100 PCFG=0x1f Jan 24 12:22:21 lucid kernel: miibus5: on cas3 Jan 24 12:22:21 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 24 12:22:21 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:21 lucid kernel: cas3: internal PHY Jan 24 12:22:21 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:21 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 24 12:22:21 lucid kernel: cas3: [FILTER] Jan 24 12:22:36 lucid kernel: nsgphy0: detached Jan 24 12:22:36 lucid kernel: miibus2: detached Jan 24 12:22:36 lucid kernel: cas0: detached Jan 24 12:22:36 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 12:22:36 lucid kernel: nsgphy1: detached Jan 24 12:22:36 lucid kernel: miibus3: detached Jan 24 12:22:36 lucid kernel: cas1: detached Jan 24 12:22:36 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 24 12:22:36 lucid kernel: nsgphy2: detached Jan 24 12:22:36 lucid kernel: miibus4: detached Jan 24 12:22:36 lucid kernel: cas2: detached Jan 24 12:22:36 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 12:22:36 lucid kernel: nsgphy3: detached Jan 24 12:22:36 lucid kernel: miibus5: detached Jan 24 12:22:36 lucid kernel: cas3: detached Jan 24 12:22:36 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 24 12:22:52 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 24 12:22:52 lucid kernel: cas0: MIF=0x100 PCFG=0x1f Jan 24 12:22:52 lucid kernel: miibus2: on cas0 Jan 24 12:22:52 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 24 12:22:52 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:52 lucid kernel: cas0: internal PHY Jan 24 12:22:52 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:52 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 24 12:22:52 lucid kernel: cas0: [FILTER] Jan 24 12:22:52 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 24 12:22:52 lucid kernel: cas1: MIF=0x100 PCFG=0x1f Jan 24 12:22:52 lucid kernel: miibus3: on cas1 Jan 24 12:22:52 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 24 12:22:52 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:52 lucid kernel: cas1: internal PHY Jan 24 12:22:52 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:52 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 24 12:22:52 lucid kernel: cas1: [FILTER] Jan 24 12:22:52 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 24 12:22:52 lucid kernel: cas2: MIF=0x100 PCFG=0x1f Jan 24 12:22:52 lucid kernel: miibus4: on cas2 Jan 24 12:22:52 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 24 12:22:52 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:52 lucid kernel: cas2: internal PHY Jan 24 12:22:52 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:52 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 24 12:22:52 lucid kernel: cas2: [FILTER] Jan 24 12:22:52 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 24 12:22:52 lucid kernel: cas3: MIF=0x100 PCFG=0x1f Jan 24 12:22:52 lucid kernel: miibus5: on cas3 Jan 24 12:22:52 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 24 12:22:52 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:22:52 lucid kernel: cas3: internal PHY Jan 24 12:22:52 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:22:52 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 24 12:22:52 lucid kernel: cas3: [FILTER] Jan 24 12:26:01 lucid shutdown: reboot by toor: Jan 24 12:26:03 lucid syslogd: exiting on signal 15 Jan 24 12:27:15 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 24 12:27:15 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 24 12:27:15 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 24 12:27:15 lucid kernel: The Regents of the University of California. All rights reserved. Jan 24 12:27:15 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 24 12:27:15 lucid kernel: FreeBSD 8.3-RELEASE #0: Thu Jan 24 11:15:13 CST 2013 Jan 24 12:27:15 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 24 12:27:15 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 24 12:27:15 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.43-MHz K8-class CPU) Jan 24 12:27:15 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 24 12:27:15 lucid kernel: Features=0xbfebfbff Jan 24 12:27:15 lucid kernel: Features2=0xe3bd Jan 24 12:27:15 lucid kernel: AMD Features=0x20100800 Jan 24 12:27:15 lucid kernel: AMD Features2=0x1 Jan 24 12:27:15 lucid kernel: TSC: P-state invariant Jan 24 12:27:15 lucid kernel: real memory = 4294967296 (4096 MB) Jan 24 12:27:15 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 24 12:27:15 lucid kernel: ACPI APIC Table: Jan 24 12:27:15 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 24 12:27:15 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 24 12:27:15 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 24 12:27:15 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 24 12:27:15 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 24 12:27:15 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 24 12:27:15 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 24 12:27:15 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 24 12:27:15 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 24 12:27:15 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 24 12:27:15 lucid kernel: kbd1 at kbdmux0 Jan 24 12:27:15 lucid kernel: acpi0: on motherboard Jan 24 12:27:15 lucid kernel: acpi0: [ITHREAD] Jan 24 12:27:15 lucid kernel: acpi0: Power Button (fixed) Jan 24 12:27:15 lucid kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 Jan 24 12:27:15 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 24 12:27:15 lucid kernel: cpu0: on acpi0 Jan 24 12:27:15 lucid kernel: cpu1: on acpi0 Jan 24 12:27:15 lucid kernel: cpu2: on acpi0 Jan 24 12:27:15 lucid kernel: cpu3: on acpi0 Jan 24 12:27:15 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 24 12:27:15 lucid kernel: pci0: on pcib0 Jan 24 12:27:15 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 24 12:27:15 lucid kernel: pci1: on pcib1 Jan 24 12:27:15 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 24 12:27:15 lucid kernel: pci2: on pcib2 Jan 24 12:27:15 lucid kernel: pcib3: at device 0.0 on pci2 Jan 24 12:27:15 lucid kernel: pci3: on pcib3 Jan 24 12:27:15 lucid kernel: pcib4: at device 2.0 on pci3 Jan 24 12:27:15 lucid kernel: pci4: on pcib4 Jan 24 12:27:15 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 12:27:15 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 24 12:27:15 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 12:27:15 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 24 12:27:15 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 24 12:27:15 lucid kernel: pci5: on pcib5 Jan 24 12:27:15 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 24 12:27:15 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 12:27:15 lucid kernel: miibus0: on bge0 Jan 24 12:27:15 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 24 12:27:15 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:27:15 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 24 12:27:15 lucid kernel: bge0: [ITHREAD] Jan 24 12:27:15 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 24 12:27:15 lucid kernel: pci6: on pcib6 Jan 24 12:27:15 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 24 12:27:15 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 12:27:15 lucid kernel: miibus1: on bge1 Jan 24 12:27:15 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 24 12:27:15 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:27:15 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 24 12:27:15 lucid kernel: bge1: [ITHREAD] Jan 24 12:27:15 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 24 12:27:15 lucid kernel: uhci0: [ITHREAD] Jan 24 12:27:15 lucid kernel: usbus0: on uhci0 Jan 24 12:27:15 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 24 12:27:15 lucid kernel: uhci1: [ITHREAD] Jan 24 12:27:15 lucid kernel: usbus1: on uhci1 Jan 24 12:27:15 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 24 12:27:15 lucid kernel: uhci2: [ITHREAD] Jan 24 12:27:15 lucid kernel: usbus2: on uhci2 Jan 24 12:27:15 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 24 12:27:15 lucid kernel: ehci0: [ITHREAD] Jan 24 12:27:15 lucid kernel: usbus3: EHCI version 1.0 Jan 24 12:27:15 lucid kernel: usbus3: on ehci0 Jan 24 12:27:15 lucid kernel: pcib7: at device 30.0 on pci0 Jan 24 12:27:15 lucid kernel: pci7: on pcib7 Jan 24 12:27:15 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 24 12:27:15 lucid kernel: isab0: at device 31.0 on pci0 Jan 24 12:27:15 lucid kernel: isa0: on isab0 Jan 24 12:27:15 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 24 12:27:15 lucid kernel: atapci0: [ITHREAD] Jan 24 12:27:15 lucid kernel: ata2: at channel 0 on atapci0 Jan 24 12:27:15 lucid kernel: ata2: [ITHREAD] Jan 24 12:27:15 lucid kernel: ata3: at channel 1 on atapci0 Jan 24 12:27:15 lucid kernel: ata3: [ITHREAD] Jan 24 12:27:15 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 24 12:27:15 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 24 12:27:15 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 24 12:27:15 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 24 12:27:15 lucid kernel: fdc0: does not respond Jan 24 12:27:15 lucid kernel: device_attach: fdc0 attach returned 6 Jan 24 12:27:15 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 24 12:27:15 lucid kernel: uart0: [FILTER] Jan 24 12:27:15 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 24 12:27:15 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 24 12:27:15 lucid kernel: kbd0 at atkbd0 Jan 24 12:27:15 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 24 12:27:15 lucid kernel: atkbd0: [ITHREAD] Jan 24 12:27:15 lucid kernel: psm0: irq 12 on atkbdc0 Jan 24 12:27:15 lucid kernel: psm0: [GIANT-LOCKED] Jan 24 12:27:15 lucid kernel: psm0: [ITHREAD] Jan 24 12:27:15 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 24 12:27:15 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 24 12:27:15 lucid kernel: sc0: at flags 0x100 on isa0 Jan 24 12:27:15 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 24 12:27:15 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 24 12:27:15 lucid kernel: ppc0: cannot reserve I/O port range Jan 24 12:27:15 lucid kernel: est0: on cpu0 Jan 24 12:27:15 lucid kernel: p4tcc0: on cpu0 Jan 24 12:27:15 lucid kernel: est1: on cpu1 Jan 24 12:27:15 lucid kernel: p4tcc1: on cpu1 Jan 24 12:27:15 lucid kernel: est2: on cpu2 Jan 24 12:27:15 lucid kernel: p4tcc2: on cpu2 Jan 24 12:27:15 lucid kernel: est3: on cpu3 Jan 24 12:27:15 lucid kernel: p4tcc3: on cpu3 Jan 24 12:27:15 lucid kernel: Timecounters tick every 1.000 msec Jan 24 12:27:15 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 24 12:27:15 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 24 12:27:15 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 24 12:27:15 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 24 12:27:15 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 24 12:27:15 lucid kernel: ugen0.1: at usbus0 Jan 24 12:27:15 lucid kernel: uhub0: on usbus0 Jan 24 12:27:15 lucid kernel: ugen1.1: at usbus1 Jan 24 12:27:15 lucid kernel: uhub1: on usbus1 Jan 24 12:27:15 lucid kernel: ugen2.1: at usbus2 Jan 24 12:27:15 lucid kernel: uhub2: on usbus2 Jan 24 12:27:15 lucid kernel: ugen3.1: at usbus3 Jan 24 12:27:15 lucid kernel: uhub3: on usbus3 Jan 24 12:27:15 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 24 12:27:15 lucid kernel: SMP: AP CPU #3 Launched! Jan 24 12:27:15 lucid kernel: SMP: AP CPU #1 Launched! Jan 24 12:27:15 lucid kernel: SMP: AP CPU #2 Launched! Jan 24 12:27:15 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 24 12:27:15 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 24 12:27:15 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 24 12:27:15 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 24 12:27:15 lucid kernel: Root mount waiting for: usbus3 Jan 24 12:27:15 lucid kernel: Root mount waiting for: usbus3 Jan 24 12:27:15 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 24 12:27:15 lucid kernel: Root mount waiting for: usbus3 Jan 24 12:27:15 lucid kernel: ugen3.2: at usbus3 Jan 24 12:27:15 lucid kernel: uhub4: on usbus3 Jan 24 12:27:15 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 24 12:27:15 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 24 12:27:17 lucid kernel: bge0: link state changed to UP Jan 24 12:28:14 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 24 12:28:14 lucid kernel: cas0: MIF=0x100 PCFG=0x1f Jan 24 12:28:14 lucid kernel: miibus2: on cas0 Jan 24 12:28:14 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 24 12:28:14 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:28:14 lucid kernel: cas0: internal PHY Jan 24 12:28:14 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:28:14 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 24 12:28:14 lucid kernel: cas0: [FILTER] Jan 24 12:28:14 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 24 12:28:14 lucid kernel: cas1: MIF=0x100 PCFG=0x1f Jan 24 12:28:14 lucid kernel: miibus3: on cas1 Jan 24 12:28:14 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 24 12:28:14 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:28:14 lucid kernel: cas1: internal PHY Jan 24 12:28:14 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:28:14 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 24 12:28:14 lucid kernel: cas1: [FILTER] Jan 24 12:28:14 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 24 12:28:14 lucid kernel: cas2: MIF=0x100 PCFG=0x1f Jan 24 12:28:14 lucid kernel: miibus4: on cas2 Jan 24 12:28:14 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 24 12:28:14 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:28:14 lucid kernel: cas2: internal PHY Jan 24 12:28:14 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:28:14 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 24 12:28:14 lucid kernel: cas2: [FILTER] Jan 24 12:28:14 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 24 12:28:14 lucid kernel: cas3: MIF=0x100 PCFG=0x1f Jan 24 12:28:14 lucid kernel: miibus5: on cas3 Jan 24 12:28:14 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 24 12:28:14 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 12:28:14 lucid kernel: cas3: internal PHY Jan 24 12:28:14 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 24 12:28:14 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 24 12:28:14 lucid kernel: cas3: [FILTER] Jan 24 12:28:29 lucid kernel: nsgphy0: detached Jan 24 12:28:29 lucid kernel: miibus2: detached Jan 24 12:28:29 lucid kernel: cas0: detached Jan 24 12:28:29 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 12:28:29 lucid kernel: nsgphy1: detached Jan 24 12:28:29 lucid kernel: miibus3: detached Jan 24 12:28:29 lucid kernel: cas1: detached Jan 24 12:28:29 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 24 12:28:29 lucid kernel: nsgphy2: detached Jan 24 12:28:29 lucid kernel: miibus4: detached Jan 24 12:28:29 lucid kernel: cas2: detached Jan 24 12:28:29 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 12:28:29 lucid kernel: nsgphy3: detached Jan 24 12:28:29 lucid kernel: miibus5: detached Jan 24 12:28:29 lucid kernel: cas3: detached Jan 24 12:28:29 lucid kernel: pci4: at device 3.0 (no driver attached) --------------010304030601040705070206-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 19:51:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE28AB45 for ; Thu, 24 Jan 2013 19:51:02 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9B11311A for ; Thu, 24 Jan 2013 19:51:02 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0OJouv4029881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2013 11:50:56 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0OJouOl029880; Thu, 24 Jan 2013 11:50:56 -0800 (PST) (envelope-from jmg) Date: Thu, 24 Jan 2013 11:50:56 -0800 From: John-Mark Gurney To: h bagade Subject: Re: how to completely makes an interface down? Message-ID: <20130124195056.GB1410@funkthat.com> Mail-Followup-To: h bagade , freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 24 Jan 2013 11:50:56 -0800 (PST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 19:51:02 -0000 h bagade wrote this message on Thu, Jan 24, 2013 at 16:59 +0330: > I'm searching for a method or configuration which when I make the interface > down, the led goes off. Currently the led still remains on when I shutdowns > the interface! Is there any way to do this? Not all ethernet drivers disable the PHY when you down the interface... You can try to use: ifconfig media none to shutdown the PHY, but the em driver on 9.1 doesn't have it, but re (7.2-R and -current) and msk (-current) seems to have it... Also, why do you want the led to go off? Remeber, the led is just an indication if there is a link established, not what will happen to the packets that are received... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 19:52:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4142BC06; Thu, 24 Jan 2013 19:52:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E432513A; Thu, 24 Jan 2013 19:52:35 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4B881B95E; Thu, 24 Jan 2013 14:52:35 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Date: Thu, 24 Jan 2013 11:14:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301221511.02496.jhb@freebsd.org> <5100EAD3.2090006@networx.ch> In-Reply-To: <5100EAD3.2090006@networx.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301241114.40734.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 24 Jan 2013 14:52:35 -0500 (EST) Cc: Sepherosa Ziehau , Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 19:52:36 -0000 On Thursday, January 24, 2013 3:03:31 am Andre Oppermann wrote: > On 24.01.2013 03:31, Sepherosa Ziehau wrote: > > On Thu, Jan 24, 2013 at 12:15 AM, John Baldwin wrote: > >> On Wednesday, January 23, 2013 1:33:27 am Sepherosa Ziehau wrote: > >>> On Wed, Jan 23, 2013 at 4:11 AM, John Baldwin wrote: > >>>> As I mentioned in an earlier thread, I recently had to debug an issue we were > >>>> seeing across a link with a high bandwidth-delay product (both high bandwidth > >>>> and high RTT). Our specific use case was to use a TCP connection to reliably > >>>> forward a latency-sensitive datagram stream across a WAN connection. We would > >>>> often see spikes in the latency of individual datagrams. I eventually tracked > >>>> this down to the connection entering slow start when it would transmit data > >>>> after being idle. The data stream was quite bursty and would often attempt to > >>>> transmit a burst of data after being idle for far longer than a retransmit > >>>> timeout. > >>>> > >>>> In 7.x we had worked around this in the past by disabling RFC 3390 and jacking > >>>> the slow start window size up via a sysctl. On 8.x this no longer worked. > >>>> The solution I came up with was to add a new socket option to disable idle > >>>> handling completely. That is, when an idle connection restarts with this new > >>>> option enabled, it keeps its current congestion window and doesn't enter slow > >>>> start. > >>>> > >>>> There are only a few cases where such an option is useful, but if anyone else > >>>> thinks this might be useful I'd be happy to add the option to FreeBSD. > >>> > >>> I think what you need is the RFC2861, however, you probably should > >>> ignore the "application-limited period" part of RFC2861. > >> > >> Hummm. It appears btw, that Linux uses RFC 2861, but has a global knob to > >> disable it due to applictions having problems. When it is disabled, > >> it doesn't decay the congestion window at all during idle handling. That is, > >> it appears to act the same as if TCP_IGNOREIDLE were enabled. > >> > >> From http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html: > >> > >> tcp_slow_start_after_idle (Boolean; default: enabled; since Linux 2.6.18) > >> If enabled, provide RFC 2861 behavior and time out the congestion > >> window after an idle period. An idle period is defined as the current > >> RTO (retransmission timeout). If disabled, the congestion window will > >> not be timed out after an idle period. > >> > >> Also, in this thread on tcp-m it appears no one on that list realizes that > >> there are any implementations which follow the "SHOULD" in RFC 2581 for idle > >> handling (which is what we do currently): > > > > Nah, I don't think the idle detection in FreeBSD follows the > > RFC2581/RFC5681 4.1 (the paragraph before the "SHOULD"). IMHO, that's > > probably why the author in the following email requestioned about the > > implementation of "SHOULD" in RFC2581/RFC5681. > > > >> > >> http://www.ietf.org/mail-archive/web/tcpm/current/msg02864.html > >> > >> So if we were to implement RFC 2861, the new socket option would be equivalent > >> to setting Linux's 'tcp_slow_start_after_idle' to false, but on a per-socket > >> basis rather than globally. > > > > Agree, per-socket option could be useful than global sysctls under > > certain situation. However, in addition to the per-socket option, > > could global sysctl nodes to disable idle_restart/idle_cwv help too? > > No. This is far too dangerous once it makes it into some tuning guide. > The threat of congestion breakdown is real. The Internet, or any packet > network, can only survive in the long term if almost all follow the rules > and self-constrain to remain fair to the others. What would happen if > nobody would respect the traffic lights anymore? The problem with this argument is Linux has already had this as a tunable option for years and the Internet hasn't melted as a result. > Besides that bursting into unknown network conditions is very likely to > result in burst losses as well. TCP isn't good at recovering from it. > In the end you most likely come out ahead if you decay the restartCWND. > > We have two cases primarily: a) long distance, medium to high RTT, and > wildly varying bandwidth (a.k.a. the Internet); b) short distance, low > RTT and mostly plenty of bandwidth (a.k.a. Datacenter). The former > absolutely definately requires a decayed restartCWND. The latter less > so but even there bursting at 10Gig TSO assisted wirespeed isn't going > to end too happy more often than not. You forgot my case: c) dedicated long distance links with high bandwidth. > Since this seems to be a burning issue I'll come up with a patch in the > next days to add a decaying restartCWND that'll be fair and allow a very > quick ramp up if no loss occurs. I think this could be useful. OTOH, I still think the TCP_IGNOREIDLE option is useful both with and without a decaying restartCWND? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 21:10:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B1C0F34; Thu, 24 Jan 2013 21:10:58 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1E7743; Thu, 24 Jan 2013 21:10:58 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (207.110.29.135.ptr.us.xo.net [207.110.29.135]) by elvis.mu.org (Postfix) with ESMTPSA id EAF521A3C77; Thu, 24 Jan 2013 13:10:51 -0800 (PST) Message-ID: <5101A35B.2060104@mu.org> Date: Thu, 24 Jan 2013 16:10:51 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <5100EAD3.2090006@networx.ch> <201301241114.40734.jhb@freebsd.org> In-Reply-To: <201301241114.40734.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net@freebsd.org, Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 21:10:58 -0000 On 1/24/13 11:14 AM, John Baldwin wrote: > On Thursday, January 24, 2013 3:03:31 am Andre Oppermann wrote: >> On 24.01.2013 03:31, Sepherosa Ziehau wrote: >>> On Thu, Jan 24, 2013 at 12:15 AM, John Baldwin wrote: >>>> On Wednesday, January 23, 2013 1:33:27 am Sepherosa Ziehau wrote: >>>>> On Wed, Jan 23, 2013 at 4:11 AM, John Baldwin wrote: >>>>>> As I mentioned in an earlier thread, I recently had to debug an issue we were >>>>>> seeing across a link with a high bandwidth-delay product (both high bandwidth >>>>>> and high RTT). Our specific use case was to use a TCP connection to reliably >>>>>> forward a latency-sensitive datagram stream across a WAN connection. We would >>>>>> often see spikes in the latency of individual datagrams. I eventually tracked >>>>>> this down to the connection entering slow start when it would transmit data >>>>>> after being idle. The data stream was quite bursty and would often attempt to >>>>>> transmit a burst of data after being idle for far longer than a retransmit >>>>>> timeout. >>>>>> >>>>>> In 7.x we had worked around this in the past by disabling RFC 3390 and jacking >>>>>> the slow start window size up via a sysctl. On 8.x this no longer worked. >>>>>> The solution I came up with was to add a new socket option to disable idle >>>>>> handling completely. That is, when an idle connection restarts with this new >>>>>> option enabled, it keeps its current congestion window and doesn't enter slow >>>>>> start. >>>>>> >>>>>> There are only a few cases where such an option is useful, but if anyone else >>>>>> thinks this might be useful I'd be happy to add the option to FreeBSD. >>>>> I think what you need is the RFC2861, however, you probably should >>>>> ignore the "application-limited period" part of RFC2861. >>>> Hummm. It appears btw, that Linux uses RFC 2861, but has a global knob to >>>> disable it due to applictions having problems. When it is disabled, >>>> it doesn't decay the congestion window at all during idle handling. That is, >>>> it appears to act the same as if TCP_IGNOREIDLE were enabled. >>>> >>>> From http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html: >>>> >>>> tcp_slow_start_after_idle (Boolean; default: enabled; since Linux 2.6.18) >>>> If enabled, provide RFC 2861 behavior and time out the congestion >>>> window after an idle period. An idle period is defined as the current >>>> RTO (retransmission timeout). If disabled, the congestion window will >>>> not be timed out after an idle period. >>>> >>>> Also, in this thread on tcp-m it appears no one on that list realizes that >>>> there are any implementations which follow the "SHOULD" in RFC 2581 for idle >>>> handling (which is what we do currently): >>> Nah, I don't think the idle detection in FreeBSD follows the >>> RFC2581/RFC5681 4.1 (the paragraph before the "SHOULD"). IMHO, that's >>> probably why the author in the following email requestioned about the >>> implementation of "SHOULD" in RFC2581/RFC5681. >>> >>>> http://www.ietf.org/mail-archive/web/tcpm/current/msg02864.html >>>> >>>> So if we were to implement RFC 2861, the new socket option would be equivalent >>>> to setting Linux's 'tcp_slow_start_after_idle' to false, but on a per-socket >>>> basis rather than globally. >>> Agree, per-socket option could be useful than global sysctls under >>> certain situation. However, in addition to the per-socket option, >>> could global sysctl nodes to disable idle_restart/idle_cwv help too? >> No. This is far too dangerous once it makes it into some tuning guide. >> The threat of congestion breakdown is real. The Internet, or any packet >> network, can only survive in the long term if almost all follow the rules >> and self-constrain to remain fair to the others. What would happen if >> nobody would respect the traffic lights anymore? > The problem with this argument is Linux has already had this as a tunable > option for years and the Internet hasn't melted as a result. > >> Besides that bursting into unknown network conditions is very likely to >> result in burst losses as well. TCP isn't good at recovering from it. >> In the end you most likely come out ahead if you decay the restartCWND. >> >> We have two cases primarily: a) long distance, medium to high RTT, and >> wildly varying bandwidth (a.k.a. the Internet); b) short distance, low >> RTT and mostly plenty of bandwidth (a.k.a. Datacenter). The former >> absolutely definately requires a decayed restartCWND. The latter less >> so but even there bursting at 10Gig TSO assisted wirespeed isn't going >> to end too happy more often than not. > You forgot my case: c) dedicated long distance links with high bandwidth. > >> Since this seems to be a burning issue I'll come up with a patch in the >> next days to add a decaying restartCWND that'll be fair and allow a very >> quick ramp up if no loss occurs. > I think this could be useful. OTOH, I still think the TCP_IGNOREIDLE option > is useful both with and without a decaying restartCWND? > Linux seems to be doing just fine with it for what seems to be a long while. Can we get this committed? -Alfred From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 21:22:20 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F3C72D6; Thu, 24 Jan 2013 21:22:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BF89B7DA; Thu, 24 Jan 2013 21:22:19 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0OLMCUx094635; Thu, 24 Jan 2013 23:22:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0OLMCUx094635 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0OLMCx5094634; Thu, 24 Jan 2013 23:22:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jan 2013 23:22:12 +0200 From: Konstantin Belousov To: Christian Gusenbauer Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Message-ID: <20130124212212.GM2522@kib.kiev.ua> References: <201301241805.57623.c47g@gmx.at> <201301241950.49455.c47g@gmx.at> <20130124193709.GL2522@kib.kiev.ua> <201301242150.52238.c47g@gmx.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RS1722//baS0C3Tp" Content-Disposition: inline In-Reply-To: <201301242150.52238.c47g@gmx.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 21:22:20 -0000 --RS1722//baS0C3Tp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 24, 2013 at 09:50:52PM +0100, Christian Gusenbauer wrote: > On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: > > On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote: > > > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > > > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wr= ote: > > > > > > Hi! > > > > > >=20 > > > > > > I'm using 9.1 stable svn revision 245605 and I get the panic be= low > > > > > > if I execute the following commands (as single user): > > > > > >=20 > > > > > > # swapon -a > > > > > > # dumpon /dev/ada0s3b > > > > > > # mount -u / > > > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > > > # mount -t nfs -o rsize=3D32768 data:/multimedia /mnt > > > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > >=20 > > > > > > then the system panics almost immediately. I'll attach the stack > > > > > > trace. > > > > > >=20 > > > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit networ= k, > > > > > > maybe that's the cause for the panic, because the bcopy (see st= ack > > > > > > frame #15) fails. > > > > > >=20 > > > > > > Any clues? > > > > >=20 > > > > > I tried a similar operation with the nfs mount of rsize=3D32768 a= nd mtu > > > > > 6144, but the machine runs HEAD and em instead of age. I was unab= le > > > > > to reproduce the panic on the copy of the 5GB file from nfs mount. > > >=20 > > > Hmmm, I did a quick test. If I do not change the MTU, so just configu= ring > > > age0 with > > >=20 > > > # ifconfig age0 inet 192.168.2.2 up > > >=20 > > > then I can copy all files from the mounted directory without any > > > problems, too. So it's probably age0 related? > >=20 > > From your backtrace and the buffer printout, I see somewhat strange thi= ng. > > The buffer data address is 0xffffff8171418000, while kernel faulted > > at the attempt to write at 0xffffff8171413000, which is is lower then > > the buffer data pointer, at the attempt to bcopy to the buffer. > >=20 > > The other data suggests that there were no overflow of the data from the > > server response. So it might be that mbuf_len(mp) returned negative num= ber > > ? I am not sure is it possible at all. > >=20 > > Try this debugging patch, please. You need to add INVARIANTS etc to the > > kernel config. > >=20 > > diff --git a/sys/fs/nfs/nfs_commonsubs.c b/sys/fs/nfs/nfs_commonsubs.c > > index efc0786..9a6bda5 100644 > > --- a/sys/fs/nfs/nfs_commonsubs.c > > +++ b/sys/fs/nfs/nfs_commonsubs.c > > @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio > > *uiop, int siz) } > > mbufcp =3D NFSMTOD(mp, caddr_t); > > len =3D mbuf_len(mp); > > + KASSERT(len > 0, ("len %d", len)); > > } > > xfer =3D (left > len) ? len : left; > > #ifdef notdef > > @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio > > *uiop, int siz) uiop->uio_resid -=3D xfer; > > } > > if (uiop->uio_iov->iov_len <=3D siz) { > > + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", > > + uiop->uio_iovcnt)); > > uiop->uio_iovcnt--; > > uiop->uio_iov++; > > } else { > >=20 > > I thought that server have returned too long response, but it seems to > > be not the case from your data. Still, I think the patch below might be > > due. > >=20 > > diff --git a/sys/fs/nfsclient/nfs_clrpcops.c > > b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 100644 > > --- a/sys/fs/nfsclient/nfs_clrpcops.c > > +++ b/sys/fs/nfsclient/nfs_clrpcops.c > > @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio *uiop, stru= ct > > ucred *cred, NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED); > > eof =3D fxdr_unsigned(int, *tl); > > } > > - NFSM_STRSIZ(retlen, rsize); > > + NFSM_STRSIZ(retlen, len); > > error =3D nfsm_mbufuio(nd, uiop, retlen); > > if (error) > > goto nfsmout; >=20 > I applied your patches and now I get a >=20 > panic: len -4 > cpuid =3D 1 > KDB: enter: panic > Dumping 377 out of 6116 MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..= 94% >=20 This means that the age driver either produced corrupted mbuf chain, or filled wrong negative value into the mbuf len field. I am quite certain that the issue is in the driver. I added the net@ to Cc:, hopefully you could get help there. >=20 > #0 doadump (textdump=3D0) > at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 > 265 if (textdump && textdump_pending) { > (kgdb) #0 doadump (textdump=3D0) > at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 > #1 0xffffffff802a7490 in db_dump (dummy=3D, > dummy2=3D, dummy3=3D, > dummy4=3D) > at /spare/tmp/src-stable9/sys/ddb/db_command.c:538 > #2 0xffffffff802a6a7e in db_command (last_cmdp=3D0xffffffff808ca140, > cmd_table=3D, dopager=3D1) > at /spare/tmp/src-stable9/sys/ddb/db_command.c:449 > #3 0xffffffff802a6cd0 in db_command_loop () > at /spare/tmp/src-stable9/sys/ddb/db_command.c:502 > #4 0xffffffff802a8e29 in db_trap (type=3D, > code=3D) > at /spare/tmp/src-stable9/sys/ddb/db_main.c:231 > #5 0xffffffff803bf548 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffff81b2= ba1080) > at /spare/tmp/src-stable9/sys/kern/subr_kdb.c:649 > #6 0xffffffff80594c28 in trap (frame=3D0xffffff81b2ba1080) > at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:579 > #7 0xffffffff8057e06f in calltrap () > at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228 > #8 0xffffffff803beffb in kdb_enter (why=3D0xffffffff8060ebcf "panic", > msg=3D0x80
) at cpufunc.h:63 > #9 0xffffffff80389391 in panic (fmt=3D) > at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:627 > #10 0xffffffff81e5bab2 in nfsm_mbufuio (nd=3D0xffffff81b2ba1340, uiop=3D0= x7cf, > siz=3D18) > at /spare/tmp/src-stable9/sys/modules/nfscommon/../../fs/nfs/nfs_comm= onsubs.c:202 > #11 0xffffffff81e195c1 in nfsrpc_read (vp=3D0xfffffe0006c94dc8, > uiop=3D0xffffff81b2ba15c0, cred=3D, > p=3D0xfffffe0006aa6490, nap=3D0xffffff81b2ba14a0, > attrflagp=3D0xffffff81b2ba156c, stuff=3D0x0) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= rpcops.c:1343 > #12 0xffffffff81e3bd80 in ncl_readrpc (vp=3D0xfffffe0006c94dc8, > uiop=3D0xffffff81b2ba15c0, cred=3D) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= vnops.c:1366 > #13 0xffffffff81e3086b in ncl_doio (vp=3D0xfffffe0006c94dc8, > bp=3D0xffffff816f8f4120, cr=3D0xfffffe0002d58e00, td=3D0xfffffe0006aa= 6490, > called_from_strategy=3D0) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= bio.c:1605 > #14 0xffffffff81e3254f in ncl_bioread (vp=3D0xfffffe0006c94dc8, > uio=3D0xffffff81b2ba1ad0, ioflag=3D, > cred=3D0xfffffe0002d58e00) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= bio.c:541 > #15 0xffffffff80434ae8 in vn_read (fp=3D0xfffffe0006abda50, > uio=3D0xffffff81b2ba1ad0, active_cred=3D, > flags=3D, td=3D) at vnode_i= f.h:384 > #16 0xffffffff8043206e in vn_io_fault (fp=3D0xfffffe0006abda50, > uio=3D0xffffff81b2ba1ad0, active_cred=3D0xfffffe0002d58e00, flags=3D0, > td=3D0xfffffe0006aa6490) at /spare/tmp/src-stable9/sys/kern/vfs_vnops= =2Ec:903 > #17 0xffffffff803d7ac1 in dofileread (td=3D0xfffffe0006aa6490, fd=3D3, > fp=3D0xfffffe0006abda50, auio=3D0xffffff81b2ba1ad0, > offset=3D, flags=3D0) at file.h:287 > #18 0xffffffff803d7e1c in kern_readv (td=3D0xfffffe0006aa6490, fd=3D3, > auio=3D0xffffff81b2ba1ad0) > at /spare/tmp/src-stable9/sys/kern/sys_generic.c:250 > #19 0xffffffff803d7f34 in sys_read (td=3D, > uap=3D) > at /spare/tmp/src-stable9/sys/kern/sys_generic.c:166 > #20 0xffffffff80593cb3 in amd64_syscall (td=3D0xfffffe0006aa6490, traced= =3D0) > at subr_syscall.c:135 > #21 0xffffffff8057e357 in Xfast_syscall () > at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:387 > #22 0x00000008009245fc in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) --RS1722//baS0C3Tp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAaYEAAoJEJDCuSvBvK1B9dwP/109z+fMvI1HtV7JEV64d/TO DXy6Kicq6vVIhWmIpmWnWITbrt2IOIhTpqaw3m5F9jDMP9p1MvTnOuyuJ8bB77Kx ZOMg59gQUaJmfWpR2yPOMOSAw1OAbgPkke3gX+Tn4NEyUrS3p32AR9+tN79QE/Tj ZrPJ8weZ/8A5f76ZfaQMbbrOohvnYc5kHMs9avwc2/x2hiLMNHBC0k/c5ZPAZ9mx o8FH/4HeAcPdUjyobKKVohoJyv1DeQqwOvw086fz2gNhz7uIdVRQE2kI9QytEyz4 T+lHaTMG0QYkWZ2bYK9kkpwpBBGp7pBcP4flRnHExr5WNQk7BHKVYtqhgy3M4r7J heH4lsUnujDKQtIjxALfYH37BUE9oKuca5g3sYDHwL0tTQg0Hh/Bh1ZkD/dLTqO+ Ju5+NmRl18sdQ/jRZlbD/ljTor86YugGpWt6EZnRjMnEgsstKqwhJW+zukzIhgYU NcGSAZL7dhaZXkrzQ2SXPb/n74llmu3Nhhpgavvyfz72FtB2A8g9b8bPTCUeDVfn pzrN4RFAaoXAf9F9Jd0VQhlPIunWNJ7LPYKfu7MjZ2F+Gc5q38qwIrCWr8l9j2R1 oP2Sw3P2rxfsdhXpyqiTUkigXtlrC3SmeV/KzCstSaJghHXTURzUxdSiU5M2GV/v IzHs0gCb02hj3bXW9Lz1 =NsNv -----END PGP SIGNATURE----- --RS1722//baS0C3Tp-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 21:50:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3E6278D6 for ; Thu, 24 Jan 2013 21:50:20 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id CA75D910 for ; Thu, 24 Jan 2013 21:50:19 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r0OLoIeD030826; Thu, 24 Jan 2013 22:50:18 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0OLoHEp030825; Thu, 24 Jan 2013 22:50:17 +0100 (CET) (envelope-from marius) Date: Thu, 24 Jan 2013 22:50:17 +0100 From: Marius Strobl To: Paul Keusemann Subject: Re: Cas driver fails to load first time after boot. Message-ID: <20130124215017.GS85306@alchemy.franken.de> References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> <51017FF0.5080001@visi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51017FF0.5080001@visi.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 21:50:20 -0000 On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: > > On 01/24/13 09:09, Marius Strobl wrote: > > On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: > >> Hi, > >> > >> I've got a Dell R200 which I'm trying to build into a gateway with a Sun > >> QGE (501-6738-10). The cas driver fails to load the first time I try to > >> load it but succeeds the second time. Is this a problem with the card, > >> the driver, my karma? > > Wrong phase of the moon, apparently :) > > The MII setup of these chips is a bit tricky and I'm not sure whether > > I've hit all code paths during development of the driver. I certainly > > didn't test with a 501-6738, these have been reported as working before, > > though. It also doesn't make much sense that attaching the devices > > succeeds on the second attempt. Could you please use a if_cas.ko built > > with the attached patch and report the debug output for one of the > > interfaces in both the working and the non-working case? > > I would love to give you output from the working and non-working case > but apparently the phase of the moon has changed, I can't get it to fail > now. The messages output from the working case is attached. > Thanks but unfortunately this doesn't make any sense either. In general, printf()s cause deays which can be relevant. In the locations I've put them they hardly can make such a difference though. If you haven't already done so, could you please power off the machine before doing the test with the patched module? Is the problem still gone if you revert to the original module? Marius From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 22:13:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 108A6188 for ; Thu, 24 Jan 2013 22:13:46 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by mx1.freebsd.org (Postfix) with SMTP id 553A6A32 for ; Thu, 24 Jan 2013 22:13:45 +0000 (UTC) Received: from [98.139.212.148] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2013 22:13:44 -0000 Received: from [98.139.211.201] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2013 22:13:44 -0000 Received: from [127.0.0.1] by smtp210.mail.bf1.yahoo.com with NNFMP; 24 Jan 2013 22:13:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1359065624; bh=7eoTJtYGwDer91NRm4x9OVI52hE4SbqEiYFHFW9yxQk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:X-Received:Received:Date:Message-ID:Subject:From:To:Content-Type; b=1d7SODHT28hE5MlMSW1Qez+b/0x2Qcsc0Vyyl+wkNS/RLOQb8L9qwhpn6/xdDXRdzffyOjQS5anqnGvvDEGIB4VnNhQRyIsQkWI5fhLE1lOpUdij89Kz6tVggEFI1e/0xTeEju/Or5ymC4XAS6mw1298OSYf/QUjPmAJu/djmM4= X-Yahoo-Newman-Id: 726245.44251.bm@smtp210.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OHfJ.QgVM1lZ3NSK0eorHClYrE7DNkt9iaXUE3jRRzs2BOy z9jEKvw3_d3QCV6CDwBiYH2ZUCXiJK4QD3H3VUsxTPgr6RaczVMAGGkZtH2V kpEl_JwsL50pMcA.HQ2MGuj.pJ6iBC3V.Y0oids4vkY3ARipPAc.2k0b7tXp H2wJ7.KCJ6mhdLS54fMgecK5Kx4DInjxaEVcv1jjeBxhkdRIIQ9dC_NGkG32 lRq3Szq7BCaVj2LZckIcp8J5rSOdtLe9D18DGtO_X8jqBGzDp3PpI7aWyM51 8jslbqQpE.3GUZ9b2gVRax_yousfw9a7.1XlPFsVaIa6qb3GdiWqGxNjTfGg S1SQOLaiFjeep8kcixuKZvwFmd_3gODFLaCciOS2ppIgFOAf0xuDgKbv7V2D IiYABY.qIYjYzZrVOrKvSGuJcC6yeozk5c5XuB8QQ9rdA.2Lfnte_9dBVE1. 4yZVwlL03eArtzHbCrHUsHtemWrzeN5YCMhld_6dNGXxVoF2puFfwe6I2F0v RSBonRTfbU8BKGommN5guHvw1PSguwRvea90zHwMsyoEsvB46ow.Pbg-- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-ve0-f182.google.com (moonlightakkiy@209.85.128.182 with plain) by smtp210.mail.bf1.yahoo.com with SMTP; 24 Jan 2013 14:13:44 -0800 PST Received: by mail-ve0-f182.google.com with SMTP id pb11so1797537veb.27 for ; Thu, 24 Jan 2013 14:13:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.149.82 with SMTP id s18mr3833174vcv.14.1359065624301; Thu, 24 Jan 2013 14:13:44 -0800 (PST) Received: by 10.58.182.72 with HTTP; Thu, 24 Jan 2013 14:13:44 -0800 (PST) Date: Thu, 24 Jan 2013 15:13:44 -0700 Message-ID: Subject: Re: Block ACK in Ralink RT2860 From: PseudoCylon To: Ramanujan Seshadri , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 22:13:46 -0000 > Message: 6 > Date: Thu, 24 Jan 2013 12:23:55 -0500 > From: Ramanujan Seshadri > To: freebsd-net@freebsd.org > Subject: Block ACK in Ralink RT2860 > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > I am trying to read the contents of block ack's in a Ralink RT2860 driver. > Can you please help me to know which function i should be looking into ? At default, all BA packets are dropped by h/w. Clear RT2860_DROP_BA flag at http://fxr.watson.org/fxr/source/dev/ral/rt2860.c#L3559 Then, the diver should receive BA packets, and you can read them. AK From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 23:27:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 931D9117; Thu, 24 Jan 2013 23:27:53 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7EFDFC; Thu, 24 Jan 2013 23:27:53 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 832DA7E820; Fri, 25 Jan 2013 10:27:51 +1100 (EST) Message-ID: <5101C377.7010907@freebsd.org> Date: Fri, 25 Jan 2013 10:27:51 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: Some questions about the new TCP congestion control code References: <201301141604.29864.jhb@freebsd.org> <50F5137F.1060207@freebsd.org> <201301151427.50932.jhb@freebsd.org> <51013702.8040707@freebsd.org> <51014150.50101@networx.ch> In-Reply-To: <51014150.50101@networx.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org, John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 23:27:53 -0000 On 01/25/13 01:12, Andre Oppermann wrote: > On 24.01.2013 14:28, Lawrence Stewart wrote: >> On 01/16/13 06:27, John Baldwin wrote: >>> One other thing I noticed which is may or may not be odd during this, >>> is that >>> if you have a connection with TCP_NODELAY enabled and you fill your >>> cwnd and >>> then you get an ACK back for an earlier small segment (less than >>> MSS), TCP >>> will not send out a "short" segment for the amount of window space >>> released. >>> Instead, it will wait until a full MSS of space is available before >>> sending >>> a packet. I'm not sure if that is the correct behavior with >>> TCP_NODELAY or >>> if we should send "short" segments in that case. >> >> We try fairly hard not to send runt segments irrespective of NODELAY, >> but I would be happy to see that change. I'm not aware of any "correct >> behaviour" we have to adhere to - I think it would be perfectly >> reasonable to have a sysctl set the lowest number of bytes we'd be >> willing to send a runt segment for and then key off TCP_NODELAY as to >> whether we try hard to send an MSS worth or send as soon as we have the >> min number of bytes worth of window available. > > This is classic silly window syndrome prevention applied to the CWND. Yes, but I think we could provide knobs to relax the behaviour where the latency vs header/payload overhead tradeoff swings in favour of latency. I guess, John, I should first ask if you know why you were only getting such small ACKs back? Were you sending full MSS segments in the first place or doing some sort of PUSH to try and expedite getting some smaller chunk of data to the other end which triggered a small segment and corresponding small ACK? > Sending a small segment when the window opens just a bit isn't going to help > much and I wouldn't be game to make such a blanket statement - that very much depends on the situation. I think John's use case is relevant and we currently aren't very helpful towards it. > mostly clogs the network. How so? We're not in the 80's any more. If I pay for X MBps of service, I expect to be able to use it in any way I choose. Packet size is irrelevant, but there are obvious efficiencies to be gained by maximising the amount of payload in each segment. > This is actually a side effect of ABC (appropriate byte counting) where not > the ACK's are counted but the bytes ACK'ed. Disabling ABC will solve this > problem. I don't follow. How is what John described above related to ABC? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 23:48:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5585B3F4; Thu, 24 Jan 2013 23:48:15 +0000 (UTC) (envelope-from krichy@cflinux.hu) Received: from pi.nmdps.net (pi.nmdps.net [IPv6:2a01:be00:10:201:0:80:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B984FE9C; Thu, 24 Jan 2013 23:48:14 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id 3202C265; Fri, 25 Jan 2013 00:48:05 +0100 (CET) Date: Fri, 25 Jan 2013 00:48:04 +0100 (CET) From: Richard Kojedzinszky X-X-Sender: krichy@pi.nmdps.net To: VANHULLEBUS Yvan Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question In-Reply-To: Message-ID: References: <20130121165355.E2D61F41@hub.freebsd.org> <20130122104420.GA3111@zeninc.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jan 2013 23:48:15 -0000 Dear Yvan, I've found a strange line in racoon's output: Either family (2 - 2), types (4 - 1) of ID from initiator differ or matching sainfo has no id_i defined for the peer. Not filling iph2->sa_src and iph2->sa_dst. This is missing in linux's instance. Could this be a clue for my problem? Thanks in advance, Kojedzinszky Richard On Tue, 22 Jan 2013, Richard Kojedzinszky wrote: > Dear Yvan, > > I've recompiled racoon with NATT, but as you've said, only pure Internet is > between A and B without NAT, and thus it did not solve my problem. > > I've attached racoon's output from > # racoon -ddd -F > on the freebsd's side. > > I can confirm, that setkey -D and -DP's output were full, so only the two > entries existed for the SA's and policices. > > I've tried a simple road-warrior setup, with transport mode, thus only > traffic between A and B was protected, but that worked. > My server's racoon.conf is simple: > -- > path certificate "/usr/local/etc/racoon/certs"; > > remote anonymous { > exchange_mode main,aggressive; > # nat_traversal off; > > certificate_type x509 "A.crt "A.key"; > ca_type x509 "ca.crt"; > my_identifier asn1dn; > peers_identifier asn1dn; > proposal_check strict ; > > lifetime time 24 hour; > > proposal { > encryption_algorithm aes256; > hash_algorithm sha1; > authentication_method rsasig; > dh_group 2; > } > > generate_policy on ; > passive on ; > > dpd_delay 60; > } > > sainfo anonymous { > lifetime time 4 hour; > > encryption_algorithm aes128 ; > authentication_algorithm hmac_md5 ; > compression_algorithm deflate; > } > > log debug ; > -- > > And the client's is the same except the generate_policy and passive > statements. > > Thanks in advance, > > Kojedzinszky Richard > > On Tue, 22 Jan 2013, VANHULLEBUS Yvan wrote: > >> Hi. >> >> >> On Mon, Jan 21, 2013 at 05:53:49PM +0100, krichy@cflinux.hu wrote: >>> Dear users, >>> >>> I've a working tunnel setup between two linux hosts. >>> >>> One end (A) has a fix address, while the other (B) has a dynamic one. >>> A is my server, B is my home router. Behind B, I've a private network. >>> What I've setup is that my private network reaches A through an IPSEC >>> tunnel. >> [....] >>> Now, I've decided to switc to freebsd on server side, and the same >>> configuration on the server simply does not work. It installs the >>> policies, and the tunnels, but it seems, that when a reply packet is >>> leaving the server, it tries to initiate a new tunnel. If I've "passive >>> on" on my server's remote section, then I've the following error: >>> >>> Jan 21 16:06:11 pi racoon: ERROR: no configuration found for B. >>> Jan 21 16:06:11 pi racoon: ERROR: failed to begin ipsec sa negotication. >>> >>> If I disable passive mode, then racoon tries to establish another tunnel, >>> but for some reason it does not succeed also. But I think, as in linux >>> it should work with passive on. >>> >>> FreeBSD is 9.1-RELEASE, the linux side is a linux 3.5.4. >>> >>> racoon on linux is: >>> # racoon -V >>> @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) >>> >>> Compiled with: >>> - OpenSSL 1.0.0e 6 Sep 2011 (http://www.openssl.org/) >>> - Dead Peer Detection >>> - IKE fragmentation >>> - NAT Traversal >>> - Monotonic clock >>> >>> >>> racoon on freebsd is: >>> # racoon -V >>> @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) >>> >>> Compiled with: >>> - OpenSSL 0.9.8x 10 May 2012 (http://www.openssl.org/) >>> - Dead Peer Detection >>> - IKE fragmentation >>> - Hybrid authentication >>> - Monotonic clock >> >> You have NAT-T compiled/enabled on Linux side, but not on FreeBSD side >> (probably because it is not activated as a kernel option). >> If you have "something that does NAT" on the wire between A and B, it >> is probably the origin of your problem. >> >> However, as it seems that there is only "Internet" between A and B, >> I'll suppose that the issue is somewhere else... >> >> >>> Unfortunately I've no idea. >>> >>> Before the first packet, on the server: >>> # setkey -D >>> No SAD entries. >>> >>> After an icmp packet sent from my private network to A: >>> # setkey -D >>> A B >>> esp mode=tunnel spi=76859998(0x0494ca5e) reqid=0(0x00000000) >>> E: rijndael-cbc 1c80b80d b006e3a3 772c2a9b 5c475213 >>> A: hmac-md5 d43ff29c 034c896a fb2e7d1c 95f73ff5 >>> seq=0x00000000 replay=4 flags=0x00000000 state=mature >>> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 >>> diff: 135(s) hard: 14400(s) soft: 11520(s) >>> last: hard: 0(s) soft: 0(s) >>> current: 0(bytes) hard: 0(bytes) soft: 0(bytes) >>> allocated: 0 hard: 0 soft: 0 >>> sadb_seq=1 pid=93091 refcnt=1 >>> B A >>> esp mode=tunnel spi=144790000(0x08a151f0) reqid=0(0x00000000) >>> E: rijndael-cbc 8bd59c29 9800d10f 8f9d7e84 a720aa9c >>> A: hmac-md5 188070e2 a3220772 78efcb06 3457db62 >>> seq=0x00000037 replay=4 flags=0x00000000 state=mature >>> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 >>> diff: 135(s) hard: 14400(s) soft: 11520(s) >>> last: Jan 21 17:04:50 2013 hard: 0(s) soft: 0(s) >>> current: 5720(bytes) hard: 0(bytes) soft: 0(bytes) >>> allocated: 55 hard: 0 soft: 0 >>> sadb_seq=0 pid=93091 refcnt=1 >>> # setkey -DP >>> 10.0.0.0/24[any] A[any] any >>> in ipsec >>> esp/tunnel/B-A/require >>> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:03:39 2013 >>> lifetime: 14400(s) validtime: 0(s) >>> spid=25 seq=1 pid=5232 >>> refcnt=1 >>> A[any] 10.0.0.0/24[any] any >>> out ipsec >>> esp/tunnel/A-B/require >>> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:04:50 2013 >>> lifetime: 14400(s) validtime: 0(s) >>> spid=26 seq=0 pid=5232 >>> refcnt=1 >>> >>> Everything seems fine, as well it is in linux, howewer, the attached log >>> shows that the kernel or racoon does not try to use the new tunnel, >>> instead it wants another one. >> >> Looks good..... >> >> Could you run racoon (on server's side) in debug mode (-dd) and send >> the few lines that talk about trying to negociate a new tunnel ? >> (Be careful, such racoon's debug contains sensitive informations) >> >> What I'd like to have is the profil of the tunnel that kernel asks for >> negociation. >> >> Also, can you confirm that your setkey -DP output is the whole full >> output ? > Yes, it was the full. >> >> >>> Is it a bug in freebsd, or a feature in linux? Do somebody have experience >>> with such a setup? >> >> Afaik, none of them, I use such setup and it works.... >> The only difference in my configuration is that I have a network >> behind both peers, but it should also work in your case. >> >> >> Yvan. >> _______________________________________________ >> 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 Fri Jan 25 00:19:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1165F945 for ; Fri, 25 Jan 2013 00:19:13 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 93A28FC6 for ; Fri, 25 Jan 2013 00:19:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0P0J5gI087289; Thu, 24 Jan 2013 17:19:05 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0P0J5ma087286; Thu, 24 Jan 2013 17:19:05 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 24 Jan 2013 17:19:05 -0700 (MST) From: Warren Block To: h bagade Subject: Re: how to completely makes an interface down? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 24 Jan 2013 17:19:06 -0700 (MST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 00:19:13 -0000 On Thu, 24 Jan 2013, h bagade wrote: > I'm searching for a method or configuration which when I make the interface > down, the led goes off. Currently the led still remains on when I shutdowns > the interface! Is there any way to do this? em(4) mentions controlling the card LEDs. I have not tried it, though. From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 02:48:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05F6FFDE for ; Fri, 25 Jan 2013 02:48:24 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront3.g2host.com [208.42.184.241]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3C86F9 for ; Fri, 25 Jan 2013 02:48:22 +0000 (UTC) Received: from [173.17.248.27] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 95128254; Thu, 24 Jan 2013 20:48:16 -0600 Message-ID: <5101F264.7030206@visi.com> Date: Thu, 24 Jan 2013 20:48:04 -0600 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Cas driver fails to load first time after boot. References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> <51017FF0.5080001@visi.com> <20130124215017.GS85306@alchemy.franken.de> In-Reply-To: <20130124215017.GS85306@alchemy.franken.de> X-Is-From-Me: yes Content-Type: multipart/mixed; boundary="------------050702010903090304000103" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 02:48:24 -0000 This is a multi-part message in MIME format. --------------050702010903090304000103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/24/13 15:50, Marius Strobl wrote: > On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: >> On 01/24/13 09:09, Marius Strobl wrote: >>> On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: >>>> Hi, >>>> >>>> I've got a Dell R200 which I'm trying to build into a gateway with a Sun >>>> QGE (501-6738-10). The cas driver fails to load the first time I try to >>>> load it but succeeds the second time. Is this a problem with the card, >>>> the driver, my karma? >>> Wrong phase of the moon, apparently :) >>> The MII setup of these chips is a bit tricky and I'm not sure whether >>> I've hit all code paths during development of the driver. I certainly >>> didn't test with a 501-6738, these have been reported as working before, >>> though. It also doesn't make much sense that attaching the devices >>> succeeds on the second attempt. Could you please use a if_cas.ko built >>> with the attached patch and report the debug output for one of the >>> interfaces in both the working and the non-working case? >> I would love to give you output from the working and non-working case >> but apparently the phase of the moon has changed, I can't get it to fail >> now. The messages output from the working case is attached. >> > Thanks but unfortunately this doesn't make any sense either. In general, > printf()s cause deays which can be relevant. In the locations I've put > them they hardly can make such a difference though. > If you haven't already done so, could you please power off the machine > before doing the test with the patched module? Is the problem still gone > if you revert to the original module? OK, power-cycling makes a difference. The driver fails to attach all of the devices after power-cycling most of the time if not all of the time. The number of devices attached varies, the attached message file fragment is from my last test. Three of the devices were attached on the first load attempt and all four of them on the second attempt. In the interest of full disclosure, I did build a new kernel but it is just a copy of GENERIC. This is a > > Marius > > -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 --------------050702010903090304000103 Content-Type: text/plain; charset=us-ascii; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages" Jan 24 20:32:32 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 24 20:32:32 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 24 20:32:32 lucid kernel: The Regents of the University of California. All rights reserved. Jan 24 20:32:32 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 24 20:32:32 lucid kernel: FreeBSD 8.3-RELEASE #0: Thu Jan 24 11:15:13 CST 2013 Jan 24 20:32:32 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 24 20:32:32 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 24 20:32:32 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 24 20:32:32 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 24 20:32:32 lucid kernel: Features=0xbfebfbff Jan 24 20:32:32 lucid kernel: Features2=0xe3bd Jan 24 20:32:32 lucid kernel: AMD Features=0x20100800 Jan 24 20:32:32 lucid kernel: AMD Features2=0x1 Jan 24 20:32:32 lucid kernel: TSC: P-state invariant Jan 24 20:32:32 lucid kernel: real memory = 4294967296 (4096 MB) Jan 24 20:32:32 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 24 20:32:32 lucid kernel: ACPI APIC Table: Jan 24 20:32:32 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 24 20:32:32 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 24 20:32:32 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 24 20:32:32 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 24 20:32:32 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 24 20:32:32 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 24 20:32:32 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 24 20:32:32 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 24 20:32:32 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 24 20:32:32 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 24 20:32:32 lucid kernel: kbd1 at kbdmux0 Jan 24 20:32:32 lucid kernel: acpi0: on motherboard Jan 24 20:32:32 lucid kernel: acpi0: [ITHREAD] Jan 24 20:32:32 lucid kernel: acpi0: Power Button (fixed) Jan 24 20:32:32 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 24 20:32:32 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 24 20:32:32 lucid kernel: cpu0: on acpi0 Jan 24 20:32:32 lucid kernel: cpu1: on acpi0 Jan 24 20:32:32 lucid kernel: cpu2: on acpi0 Jan 24 20:32:32 lucid kernel: cpu3: on acpi0 Jan 24 20:32:32 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 24 20:32:32 lucid kernel: pci0: on pcib0 Jan 24 20:32:32 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 24 20:32:32 lucid kernel: pci1: on pcib1 Jan 24 20:32:32 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 24 20:32:32 lucid kernel: pci2: on pcib2 Jan 24 20:32:32 lucid kernel: pcib3: at device 0.0 on pci2 Jan 24 20:32:32 lucid kernel: pci3: on pcib3 Jan 24 20:32:32 lucid kernel: pcib4: at device 2.0 on pci3 Jan 24 20:32:32 lucid kernel: pci4: on pcib4 Jan 24 20:32:32 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 20:32:32 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 24 20:32:32 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 20:32:32 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 24 20:32:32 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 24 20:32:32 lucid kernel: pci5: on pcib5 Jan 24 20:32:32 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 24 20:32:32 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 20:32:32 lucid kernel: miibus0: on bge0 Jan 24 20:32:32 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 24 20:32:32 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:32:32 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 24 20:32:32 lucid kernel: bge0: [ITHREAD] Jan 24 20:32:32 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 24 20:32:32 lucid kernel: pci6: on pcib6 Jan 24 20:32:32 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 24 20:32:32 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 24 20:32:32 lucid kernel: miibus1: on bge1 Jan 24 20:32:32 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 24 20:32:32 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:32:32 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 24 20:32:32 lucid kernel: bge1: [ITHREAD] Jan 24 20:32:32 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 24 20:32:32 lucid kernel: uhci0: [ITHREAD] Jan 24 20:32:32 lucid kernel: usbus0: on uhci0 Jan 24 20:32:32 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 24 20:32:32 lucid kernel: uhci1: [ITHREAD] Jan 24 20:32:32 lucid kernel: usbus1: on uhci1 Jan 24 20:32:32 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 24 20:32:32 lucid kernel: uhci2: [ITHREAD] Jan 24 20:32:32 lucid kernel: usbus2: on uhci2 Jan 24 20:32:32 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 24 20:32:32 lucid kernel: ehci0: [ITHREAD] Jan 24 20:32:32 lucid kernel: usbus3: EHCI version 1.0 Jan 24 20:32:32 lucid kernel: usbus3: on ehci0 Jan 24 20:32:32 lucid kernel: pcib7: at device 30.0 on pci0 Jan 24 20:32:32 lucid kernel: pci7: on pcib7 Jan 24 20:32:32 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 24 20:32:32 lucid kernel: isab0: at device 31.0 on pci0 Jan 24 20:32:32 lucid kernel: isa0: on isab0 Jan 24 20:32:32 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 24 20:32:32 lucid kernel: atapci0: [ITHREAD] Jan 24 20:32:32 lucid kernel: ata2: at channel 0 on atapci0 Jan 24 20:32:32 lucid kernel: ata2: [ITHREAD] Jan 24 20:32:32 lucid kernel: ata3: at channel 1 on atapci0 Jan 24 20:32:32 lucid kernel: ata3: [ITHREAD] Jan 24 20:32:32 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 24 20:32:32 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 24 20:32:32 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 24 20:32:32 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 24 20:32:32 lucid kernel: fdc0: does not respond Jan 24 20:32:32 lucid kernel: device_attach: fdc0 attach returned 6 Jan 24 20:32:32 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 24 20:32:32 lucid kernel: uart0: [FILTER] Jan 24 20:32:32 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 24 20:32:32 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 24 20:32:32 lucid kernel: kbd0 at atkbd0 Jan 24 20:32:32 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 24 20:32:32 lucid kernel: atkbd0: [ITHREAD] Jan 24 20:32:32 lucid kernel: psm0: irq 12 on atkbdc0 Jan 24 20:32:32 lucid kernel: psm0: [GIANT-LOCKED] Jan 24 20:32:32 lucid kernel: psm0: [ITHREAD] Jan 24 20:32:32 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 24 20:32:32 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 24 20:32:32 lucid kernel: sc0: at flags 0x100 on isa0 Jan 24 20:32:32 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 24 20:32:32 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 24 20:32:32 lucid kernel: ppc0: cannot reserve I/O port range Jan 24 20:32:32 lucid kernel: est0: on cpu0 Jan 24 20:32:32 lucid kernel: p4tcc0: on cpu0 Jan 24 20:32:32 lucid kernel: est1: on cpu1 Jan 24 20:32:32 lucid kernel: p4tcc1: on cpu1 Jan 24 20:32:32 lucid kernel: est2: on cpu2 Jan 24 20:32:32 lucid kernel: p4tcc2: on cpu2 Jan 24 20:32:32 lucid kernel: est3: on cpu3 Jan 24 20:32:32 lucid kernel: p4tcc3: on cpu3 Jan 24 20:32:32 lucid kernel: Timecounters tick every 1.000 msec Jan 24 20:32:32 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 24 20:32:32 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 24 20:32:32 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 24 20:32:32 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 24 20:32:32 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 24 20:32:32 lucid kernel: ugen0.1: at usbus0 Jan 24 20:32:32 lucid kernel: uhub0: on usbus0 Jan 24 20:32:32 lucid kernel: ugen1.1: at usbus1 Jan 24 20:32:32 lucid kernel: uhub1: on usbus1 Jan 24 20:32:32 lucid kernel: ugen2.1: at usbus2 Jan 24 20:32:32 lucid kernel: uhub2: on usbus2 Jan 24 20:32:32 lucid kernel: ugen3.1: at usbus3 Jan 24 20:32:32 lucid kernel: uhub3: on usbus3 Jan 24 20:32:32 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 24 20:32:32 lucid kernel: SMP: AP CPU #2 Launched! Jan 24 20:32:32 lucid kernel: SMP: AP CPU #1 Launched! Jan 24 20:32:32 lucid kernel: SMP: AP CPU #3 Launched! Jan 24 20:32:32 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 24 20:32:32 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 24 20:32:32 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 24 20:32:32 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 24 20:32:32 lucid kernel: Root mount waiting for: usbus3 Jan 24 20:32:32 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 24 20:32:32 lucid kernel: Root mount waiting for: usbus3 Jan 24 20:32:32 lucid kernel: ugen3.2: at usbus3 Jan 24 20:32:32 lucid kernel: uhub4: on usbus3 Jan 24 20:32:32 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 24 20:32:32 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 24 20:32:34 lucid kernel: bge0: link state changed to UP Jan 24 20:32:41 lucid login: ROOT LOGIN (toor) ON ttyv0 Jan 24 20:32:47 lucid login: ROOT LOGIN (toor) ON ttyv1 Jan 24 20:33:07 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 24 20:33:07 lucid kernel: cas0: MIF=0x100 PCFG=0x1f Jan 24 20:33:07 lucid kernel: miibus2: on cas0 Jan 24 20:33:07 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 24 20:33:07 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:33:07 lucid kernel: cas0: internal PHY Jan 24 20:33:07 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 24 20:33:07 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 24 20:33:07 lucid kernel: cas0: [FILTER] Jan 24 20:33:07 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 24 20:33:07 lucid kernel: cas1: MIF=0x100 PCFG=0x1f Jan 24 20:33:07 lucid kernel: cas1: attaching PHYs failed Jan 24 20:33:07 lucid kernel: cas1: could not be attached Jan 24 20:33:07 lucid kernel: device_attach: cas1 attach returned 6 Jan 24 20:33:07 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 24 20:33:07 lucid kernel: cas2: MIF=0x100 PCFG=0x1f Jan 24 20:33:07 lucid kernel: miibus3: on cas2 Jan 24 20:33:07 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 24 20:33:07 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:33:07 lucid kernel: cas2: internal PHY Jan 24 20:33:07 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 24 20:33:07 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 24 20:33:07 lucid kernel: cas2: [FILTER] Jan 24 20:33:07 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 24 20:33:07 lucid kernel: cas3: MIF=0x100 PCFG=0x1f Jan 24 20:33:07 lucid kernel: miibus4: on cas3 Jan 24 20:33:07 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 24 20:33:07 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:33:07 lucid kernel: cas3: internal PHY Jan 24 20:33:07 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 24 20:33:07 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 24 20:33:07 lucid kernel: cas3: [FILTER] Jan 24 20:33:23 lucid kernel: nsgphy0: detached Jan 24 20:33:23 lucid kernel: miibus2: detached Jan 24 20:33:23 lucid kernel: cas0: detached Jan 24 20:33:23 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 24 20:33:23 lucid kernel: nsgphy1: detached Jan 24 20:33:23 lucid kernel: miibus3: detached Jan 24 20:33:23 lucid kernel: cas2: detached Jan 24 20:33:23 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 24 20:33:23 lucid kernel: nsgphy2: detached Jan 24 20:33:23 lucid kernel: miibus4: detached Jan 24 20:33:23 lucid kernel: cas3: detached Jan 24 20:33:23 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 24 20:33:38 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 24 20:33:38 lucid kernel: cas0: MIF=0x100 PCFG=0x1f Jan 24 20:33:38 lucid kernel: miibus2: on cas0 Jan 24 20:33:38 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 24 20:33:38 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:33:38 lucid kernel: cas0: internal PHY Jan 24 20:33:38 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 24 20:33:38 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 24 20:33:38 lucid kernel: cas0: [FILTER] Jan 24 20:33:38 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 24 20:33:38 lucid kernel: cas1: MIF=0x100 PCFG=0x1f Jan 24 20:33:38 lucid kernel: miibus3: on cas1 Jan 24 20:33:38 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 24 20:33:38 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:33:38 lucid kernel: cas1: internal PHY Jan 24 20:33:38 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 24 20:33:38 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 24 20:33:38 lucid kernel: cas1: [FILTER] Jan 24 20:33:38 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 24 20:33:38 lucid kernel: cas2: MIF=0x100 PCFG=0x1f Jan 24 20:33:38 lucid kernel: miibus4: on cas2 Jan 24 20:33:38 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 24 20:33:38 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:33:38 lucid kernel: cas2: internal PHY Jan 24 20:33:38 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 24 20:33:38 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 24 20:33:38 lucid kernel: cas2: [FILTER] Jan 24 20:33:38 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 24 20:33:38 lucid kernel: cas3: MIF=0x100 PCFG=0x1f Jan 24 20:33:38 lucid kernel: miibus5: on cas3 Jan 24 20:33:38 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 24 20:33:38 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 24 20:33:38 lucid kernel: cas3: internal PHY Jan 24 20:33:38 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 24 20:33:38 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 24 20:33:38 lucid kernel: cas3: [FILTER] --------------050702010903090304000103 Content-Type: text/plain; charset=us-ascii; name="dmesg.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-RELEASE #0: Thu Jan 24 11:15:13 CST 2013 toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4099231744 (3909 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 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 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 2.0 on pci3 pci4: on pcib4 pci4: at device 0.0 (no driver attached) pci4: at device 1.0 (no driver attached) pci4: at device 2.0 (no driver attached) pci4: at device 3.0 (no driver attached) pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:19:b9:fa:82:51 bge0: [ITHREAD] pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:19:b9:fa:82:52 bge1: [ITHREAD] uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib7: at device 30.0 on pci0 pci7: on pcib7 vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: at channel 0 on atapci0 ata2: [ITHREAD] ata3: at channel 1 on atapci0 ata3: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x7f irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 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: 480Mbps High Speed USB v2.0 ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s 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 acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 uhub4: on usbus3 uhub4: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ad4s1a bge0: link state changed to UP cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 cas0: MIF=0x100 PCFG=0x1f miibus2: on cas0 nsgphy0: PHY 1 on miibus2 nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas0: internal PHY cas0: 16kB RX FIFO, 9kB TX FIFO cas0: Ethernet address: 00:14:4f:25:ca:10 cas0: [FILTER] cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 cas1: MIF=0x100 PCFG=0x1f cas1: attaching PHYs failed cas1: could not be attached device_attach: cas1 attach returned 6 cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 cas2: MIF=0x100 PCFG=0x1f miibus3: on cas2 nsgphy1: PHY 1 on miibus3 nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas2: internal PHY cas2: 16kB RX FIFO, 9kB TX FIFO cas2: Ethernet address: 00:14:4f:25:ca:12 cas2: [FILTER] cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 cas3: MIF=0x100 PCFG=0x1f miibus4: on cas3 nsgphy2: PHY 1 on miibus4 nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas3: internal PHY cas3: 16kB RX FIFO, 9kB TX FIFO cas3: Ethernet address: 00:14:4f:25:ca:13 cas3: [FILTER] nsgphy0: detached miibus2: detached cas0: detached pci4: at device 0.0 (no driver attached) nsgphy1: detached miibus3: detached cas2: detached pci4: at device 2.0 (no driver attached) nsgphy2: detached miibus4: detached cas3: detached pci4: at device 3.0 (no driver attached) cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 cas0: MIF=0x100 PCFG=0x1f miibus2: on cas0 nsgphy0: PHY 1 on miibus2 nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas0: internal PHY cas0: 16kB RX FIFO, 9kB TX FIFO cas0: Ethernet address: 00:14:4f:25:ca:10 cas0: [FILTER] cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 cas1: MIF=0x100 PCFG=0x1f miibus3: on cas1 nsgphy1: PHY 1 on miibus3 nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas1: internal PHY cas1: 16kB RX FIFO, 9kB TX FIFO cas1: Ethernet address: 00:14:4f:25:ca:11 cas1: [FILTER] cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 cas2: MIF=0x100 PCFG=0x1f miibus4: on cas2 nsgphy2: PHY 1 on miibus4 nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas2: internal PHY cas2: 16kB RX FIFO, 9kB TX FIFO cas2: Ethernet address: 00:14:4f:25:ca:12 cas2: [FILTER] cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 cas3: MIF=0x100 PCFG=0x1f miibus5: on cas3 nsgphy3: PHY 1 on miibus5 nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas3: internal PHY cas3: 16kB RX FIFO, 9kB TX FIFO cas3: Ethernet address: 00:14:4f:25:ca:13 cas3: [FILTER] --------------050702010903090304000103-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 09:25:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8674698B for ; Fri, 25 Jan 2013 09:25:07 +0000 (UTC) (envelope-from NShafiev@AZEDUNET.AZ) Received: from smtp-gw1.aznet.org (smtp-gw1.aznet.org [82.194.4.141]) by mx1.freebsd.org (Postfix) with ESMTP id F1AB894D for ; Fri, 25 Jan 2013 09:25:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGAHtOAlFSwgDB/2dsb2JhbABEg2WCYbAiiAFzgkgVQDYCBRYLAgsDAgECAVgIAQGIGpxUjlWSWIEjjHKCFoETA4hbkwmKcIJ9 X-IronPort-AV: E=Sophos;i="4.84,506,1355083200"; d="scan'208";a="19128" Received: from mail.azedunet.az (HELO 2K8FPE01.AZEDUNET.COM) ([82.194.0.193]) by smtp-gw1.aznet.org with ESMTP; 25 Jan 2013 13:23:55 +0400 Received: from naim.azedunet.com (10.201.10.15) by 2k8fpe01.AZEDUNET.COM (10.201.1.4) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 25 Jan 2013 13:23:55 +0400 Message-ID: <51024F2B.6000502@azedunet.com> Date: Fri, 25 Jan 2013 13:23:55 +0400 From: Naim Shafiev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Choosing the hardware which can proceed up to 10g speed Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 09:25:07 -0000 Hello. I am looking for x86-64 based hardware , which can proceed up to near 10 gigabit speed in my tasks. My tasks are: 0. Can minimal proceed around 600 kpps . The packet average size is around 600 1. Can be applicable in caching tasks(like caching youtube) 2. Can do a Level 7 parsing( to run snort , finding some text , and etc) Also i want to use the netmap framework with libpcap . I am sorry if there don't discussing the network perfomance and hardware choosing topics, but i cannot find more good place except this. From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 10:13:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2A7F4810 for ; Fri, 25 Jan 2013 10:13:25 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id D9E00BE6 for ; Fri, 25 Jan 2013 10:13:24 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TygHs-0003lU-13 for freebsd-net@freebsd.org; Fri, 25 Jan 2013 11:13:32 +0100 Received: from office-nat.spylog.net ([193.169.234.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2013 11:13:32 +0100 Received: from citrin by office-nat.spylog.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2013 11:13:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Anton Yuzhaninov Subject: Re: Carp configuration errors Date: Fri, 25 Jan 2013 10:13:01 +0000 (UTC) Organization: Vega Lines: 12 Sender: Anton Yuzhaninov Message-ID: References: <0154442B-C0E9-4731-A85E-1A44F3ED1F47@develooper.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: office-nat.spylog.net X-Comment-To: Ask Bj?rn Hansen User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (FreeBSD/10.0-CURRENT (i386)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 10:13:25 -0000 On Thu, 24 Jan 2013 21:26:46, Ask Bj?rn Hansen wrote: ABrH> After upgrading to 9.1 it seems like carp doesn't pay attention to advskew anymore. I have two boxes each setup with carp0 and carp1; the intention is that in regular operation proxy1 is master for carp0 and proxy2 for carp1. However, whichever box comes up second is BACKUP for both. 1. Do your have sysctl net.inet.carp.preempt=1 ? With preempt=0 box comes up second should be in backup state. 2. For carp problem troubleshooting it is useful temporary increase carp logs verbosity: sysctl net.inet.carp.log=2 -- Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 13:13:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BEDD754A for ; Fri, 25 Jan 2013 13:13:53 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5D1958 for ; Fri, 25 Jan 2013 13:13:52 +0000 (UTC) Received: from ken (ken.zen.inc [192.168.1.4]) by smtp.zeninc.net (smtpd) with ESMTP id 53E4A27988B; Fri, 25 Jan 2013 14:13:45 +0100 (CET) Received: by ken (Postfix, from userid 1000) id 15C6F40E3; Fri, 25 Jan 2013 14:13:45 +0100 (CET) Date: Fri, 25 Jan 2013 14:13:45 +0100 From: VANHULLEBUS Yvan To: Richard Kojedzinszky Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question Message-ID: <20130125131344.GA3356@zeninc.net> References: <20130121165355.E2D61F41@hub.freebsd.org> <20130122104420.GA3111@zeninc.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 13:13:53 -0000 On Fri, Jan 25, 2013 at 12:48:04AM +0100, Richard Kojedzinszky wrote: > Dear Yvan, > > I've found a strange line in racoon's output: > > Either family (2 - 2), types (4 - 1) of ID from initiator differ or > matching sainfo has no id_i defined for the peer. Not filling > iph2->sa_src and iph2->sa_dst. > > This is missing in linux's instance. Could this be a clue for my problem? It may be related... Looks like one of the peers considers A as a single IP (IPSECDOI_ID_IPV4_ADDR == 1), where the other considers it as the network "A/32" (IPSECDOI_ID_IPV4_ADDR_SUBNET == 4). The most strange thing is that the same setup works with two Linux, so it may be related to something in kernel side, sent to racoon via PFKey.... However, that should not change anything when IPsec stack searches for an SPD then an SA: A will always be matched there, either as an IP or as a /32 subnet... I'll have a look ASAP at the debug you sent in your other mail, hope there will be interesting informations there.... Yvan. > Thanks in advance, > > Kojedzinszky Richard > > On Tue, 22 Jan 2013, Richard Kojedzinszky wrote: > > >Dear Yvan, > > > >I've recompiled racoon with NATT, but as you've said, only pure > >Internet is between A and B without NAT, and thus it did not solve > >my problem. > > > >I've attached racoon's output from > ># racoon -ddd -F > >on the freebsd's side. > > > >I can confirm, that setkey -D and -DP's output were full, so only > >the two entries existed for the SA's and policices. > > > >I've tried a simple road-warrior setup, with transport mode, thus > >only traffic between A and B was protected, but that worked. > >My server's racoon.conf is simple: > >-- > >path certificate "/usr/local/etc/racoon/certs"; > > > >remote anonymous { > > exchange_mode main,aggressive; > ># nat_traversal off; > > > > certificate_type x509 "A.crt "A.key"; > > ca_type x509 "ca.crt"; > > my_identifier asn1dn; > > peers_identifier asn1dn; > > proposal_check strict ; > > > > lifetime time 24 hour; > > > > proposal { > > encryption_algorithm aes256; > > hash_algorithm sha1; > > authentication_method rsasig; > > dh_group 2; > > } > > > > generate_policy on ; > > passive on ; > > > > dpd_delay 60; > >} > > > >sainfo anonymous { > > lifetime time 4 hour; > > > > encryption_algorithm aes128 ; > > authentication_algorithm hmac_md5 ; > > compression_algorithm deflate; > >} > > > >log debug ; > >-- > > > >And the client's is the same except the generate_policy and > >passive statements. > > > >Thanks in advance, > > > >Kojedzinszky Richard > > > >On Tue, 22 Jan 2013, VANHULLEBUS Yvan wrote: > > > >>Hi. > >> > >> > >>On Mon, Jan 21, 2013 at 05:53:49PM +0100, krichy@cflinux.hu wrote: > >>>Dear users, > >>> > >>>I've a working tunnel setup between two linux hosts. > >>> > >>>One end (A) has a fix address, while the other (B) has a dynamic one. > >>>A is my server, B is my home router. Behind B, I've a private network. > >>>What I've setup is that my private network reaches A through an IPSEC > >>>tunnel. > >>[....] > >>>Now, I've decided to switc to freebsd on server side, and the same > >>>configuration on the server simply does not work. It installs the > >>>policies, and the tunnels, but it seems, that when a reply packet is > >>>leaving the server, it tries to initiate a new tunnel. If I've "passive > >>>on" on my server's remote section, then I've the following error: > >>> > >>>Jan 21 16:06:11 pi racoon: ERROR: no configuration found for B. > >>>Jan 21 16:06:11 pi racoon: ERROR: failed to begin ipsec sa negotication. > >>> > >>>If I disable passive mode, then racoon tries to establish another tunnel, > >>>but for some reason it does not succeed also. But I think, as in linux > >>>it should work with passive on. > >>> > >>>FreeBSD is 9.1-RELEASE, the linux side is a linux 3.5.4. > >>> > >>>racoon on linux is: > >>># racoon -V > >>>@(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) > >>> > >>>Compiled with: > >>>- OpenSSL 1.0.0e 6 Sep 2011 (http://www.openssl.org/) > >>>- Dead Peer Detection > >>>- IKE fragmentation > >>>- NAT Traversal > >>>- Monotonic clock > >>> > >>> > >>>racoon on freebsd is: > >>># racoon -V > >>>@(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) > >>> > >>>Compiled with: > >>>- OpenSSL 0.9.8x 10 May 2012 (http://www.openssl.org/) > >>>- Dead Peer Detection > >>>- IKE fragmentation > >>>- Hybrid authentication > >>>- Monotonic clock > >> > >>You have NAT-T compiled/enabled on Linux side, but not on FreeBSD side > >>(probably because it is not activated as a kernel option). > >>If you have "something that does NAT" on the wire between A and B, it > >>is probably the origin of your problem. > >> > >>However, as it seems that there is only "Internet" between A and B, > >>I'll suppose that the issue is somewhere else... > >> > >> > >>>Unfortunately I've no idea. > >>> > >>>Before the first packet, on the server: > >>># setkey -D > >>>No SAD entries. > >>> > >>>After an icmp packet sent from my private network to A: > >>># setkey -D > >>>A B > >>> esp mode=tunnel spi=76859998(0x0494ca5e) reqid=0(0x00000000) > >>> E: rijndael-cbc 1c80b80d b006e3a3 772c2a9b 5c475213 > >>> A: hmac-md5 d43ff29c 034c896a fb2e7d1c 95f73ff5 > >>> seq=0x00000000 replay=4 flags=0x00000000 state=mature > >>> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 > >>> diff: 135(s) hard: 14400(s) soft: 11520(s) > >>> last: hard: 0(s) soft: 0(s) > >>> current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > >>> allocated: 0 hard: 0 soft: 0 > >>> sadb_seq=1 pid=93091 refcnt=1 > >>>B A > >>> esp mode=tunnel spi=144790000(0x08a151f0) reqid=0(0x00000000) > >>> E: rijndael-cbc 8bd59c29 9800d10f 8f9d7e84 a720aa9c > >>> A: hmac-md5 188070e2 a3220772 78efcb06 3457db62 > >>> seq=0x00000037 replay=4 flags=0x00000000 state=mature > >>> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 > >>> diff: 135(s) hard: 14400(s) soft: 11520(s) > >>> last: Jan 21 17:04:50 2013 hard: 0(s) soft: 0(s) > >>> current: 5720(bytes) hard: 0(bytes) soft: 0(bytes) > >>> allocated: 55 hard: 0 soft: 0 > >>> sadb_seq=0 pid=93091 refcnt=1 > >>># setkey -DP > >>>10.0.0.0/24[any] A[any] any > >>> in ipsec > >>> esp/tunnel/B-A/require > >>> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:03:39 2013 > >>> lifetime: 14400(s) validtime: 0(s) > >>> spid=25 seq=1 pid=5232 > >>> refcnt=1 > >>>A[any] 10.0.0.0/24[any] any > >>> out ipsec > >>> esp/tunnel/A-B/require > >>> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:04:50 2013 > >>> lifetime: 14400(s) validtime: 0(s) > >>> spid=26 seq=0 pid=5232 > >>> refcnt=1 > >>> > >>>Everything seems fine, as well it is in linux, howewer, the attached log > >>>shows that the kernel or racoon does not try to use the new tunnel, > >>>instead it wants another one. > >> > >>Looks good..... > >> > >>Could you run racoon (on server's side) in debug mode (-dd) and send > >>the few lines that talk about trying to negociate a new tunnel ? > >>(Be careful, such racoon's debug contains sensitive informations) > >> > >>What I'd like to have is the profil of the tunnel that kernel asks for > >>negociation. > >> > >>Also, can you confirm that your setkey -DP output is the whole full > >>output ? > >Yes, it was the full. > >> > >> > >>>Is it a bug in freebsd, or a feature in linux? Do somebody have experience > >>>with such a setup? > >> > >>Afaik, none of them, I use such setup and it works.... > >>The only difference in my configuration is that I have a network > >>behind both peers, but it should also work in your case. > >> > >> > >>Yvan. > >>_______________________________________________ > >>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 Fri Jan 25 15:37:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 585625F5; Fri, 25 Jan 2013 15:37:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 402733CD; Fri, 25 Jan 2013 15:37:43 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 52C18B98F; Fri, 25 Jan 2013 10:37:42 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Some questions about the new TCP congestion control code Date: Fri, 25 Jan 2013 09:00:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141604.29864.jhb@freebsd.org> <51014150.50101@networx.ch> <5101C377.7010907@freebsd.org> In-Reply-To: <5101C377.7010907@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301250900.38871.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 25 Jan 2013 10:37:42 -0500 (EST) Cc: Lawrence Stewart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 15:37:44 -0000 On Thursday, January 24, 2013 6:27:51 pm Lawrence Stewart wrote: > On 01/25/13 01:12, Andre Oppermann wrote: > > On 24.01.2013 14:28, Lawrence Stewart wrote: > >> On 01/16/13 06:27, John Baldwin wrote: > >>> One other thing I noticed which is may or may not be odd during this, > >>> is that > >>> if you have a connection with TCP_NODELAY enabled and you fill your > >>> cwnd and > >>> then you get an ACK back for an earlier small segment (less than > >>> MSS), TCP > >>> will not send out a "short" segment for the amount of window space > >>> released. > >>> Instead, it will wait until a full MSS of space is available before > >>> sending > >>> a packet. I'm not sure if that is the correct behavior with > >>> TCP_NODELAY or > >>> if we should send "short" segments in that case. > >> > >> We try fairly hard not to send runt segments irrespective of NODELAY, > >> but I would be happy to see that change. I'm not aware of any "correct > >> behaviour" we have to adhere to - I think it would be perfectly > >> reasonable to have a sysctl set the lowest number of bytes we'd be > >> willing to send a runt segment for and then key off TCP_NODELAY as to > >> whether we try hard to send an MSS worth or send as soon as we have the > >> min number of bytes worth of window available. > > > > This is classic silly window syndrome prevention applied to the CWND. > > Yes, but I think we could provide knobs to relax the behaviour where the > latency vs header/payload overhead tradeoff swings in favour of latency. > > I guess, John, I should first ask if you know why you were only getting > such small ACKs back? Were you sending full MSS segments in the first > place or doing some sort of PUSH to try and expedite getting some > smaller chunk of data to the other end which triggered a small segment > and corresponding small ACK? In general we only send very small segments as we have TCP_NODELAY on and are effectively using this to forward small datagrams. Thus, in the usual case we have a lot of small segments (much smaller than MSS). When we fill the congestion window, the stack starts waiting for a full MSS and that requires several ACKs from the earlier small segments. > > Sending a small segment when the window opens just a bit isn't going to help > > much and > > I wouldn't be game to make such a blanket statement - that very much > depends on the situation. I think John's use case is relevant and we > currently aren't very helpful towards it. I think in the case of TCP_NODELAY, the user is explicitly asking for lower latency. Think about the "typical" use case for TCP_NODELAY of a shell session. If you manage to build up a cwnd of backlog you'd rather have the oldest characters get out to the remote machine as soon as possible rather than waiting for enough ACKs to build up a full MSS. However, there might also be cases where it's useful to fall back to throttling to full MSS in this case. If you were to implement my suggestion and the local sender started spamming a bunch of data, you could be stuck permamently sending small frames if you always responded to each sub-MSS ACK with an equivalently-sized frame. It may be that in the case of filling your cwnd, this is the more common case and that the better fix for my use case is to have a more accurate cwnd (and thus the TCP_IGNOREIDLE change). I have no idea what other stacks do in this regard. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 16:19:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9EE68A93 for ; Fri, 25 Jan 2013 16:19:24 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1AE873 for ; Fri, 25 Jan 2013 16:19:23 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r0PGJG5a034518; Fri, 25 Jan 2013 17:19:17 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0PGJGD0034517; Fri, 25 Jan 2013 17:19:16 +0100 (CET) (envelope-from marius) Date: Fri, 25 Jan 2013 17:19:16 +0100 From: Marius Strobl To: Paul Keusemann Subject: Re: Cas driver fails to load first time after boot. Message-ID: <20130125161916.GV85306@alchemy.franken.de> References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> <51017FF0.5080001@visi.com> <20130124215017.GS85306@alchemy.franken.de> <5101F264.7030206@visi.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mJm6k4Vb/yFcL9ZU" Content-Disposition: inline In-Reply-To: <5101F264.7030206@visi.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 16:19:24 -0000 --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote: > > On 01/24/13 15:50, Marius Strobl wrote: > > On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: > >> On 01/24/13 09:09, Marius Strobl wrote: > >>> On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: > >>>> Hi, > >>>> > >>>> I've got a Dell R200 which I'm trying to build into a gateway with a Sun > >>>> QGE (501-6738-10). The cas driver fails to load the first time I try to > >>>> load it but succeeds the second time. Is this a problem with the card, > >>>> the driver, my karma? > >>> Wrong phase of the moon, apparently :) > >>> The MII setup of these chips is a bit tricky and I'm not sure whether > >>> I've hit all code paths during development of the driver. I certainly > >>> didn't test with a 501-6738, these have been reported as working before, > >>> though. It also doesn't make much sense that attaching the devices > >>> succeeds on the second attempt. Could you please use a if_cas.ko built > >>> with the attached patch and report the debug output for one of the > >>> interfaces in both the working and the non-working case? > >> I would love to give you output from the working and non-working case > >> but apparently the phase of the moon has changed, I can't get it to fail > >> now. The messages output from the working case is attached. > >> > > Thanks but unfortunately this doesn't make any sense either. In general, > > printf()s cause deays which can be relevant. In the locations I've put > > them they hardly can make such a difference though. > > If you haven't already done so, could you please power off the machine > > before doing the test with the patched module? Is the problem still gone > > if you revert to the original module? > > OK, power-cycling makes a difference. The driver fails to attach all of > the devices after power-cycling most of the time if not all of the > time. The number of devices attached varies, the attached message file > fragment is from my last test. Three of the devices were attached on > the first load attempt and all four of them on the second attempt. Okay, so we now at least have a way to reproduce the problem. Unfortunately, it's still unclear what's the exact cause of it. At least the problem is not what I suspected and hoped it most likely is. Could you please test how things behave after a power-cycle with the attached patche (after reverting the previous one). Marius --mJm6k4Vb/yFcL9ZU Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="if_cas.c.diff" Index: if_cas.c =================================================================== --- if_cas.c (revision 245046) +++ if_cas.c (working copy) @@ -214,8 +214,12 @@ cas_attach(struct cas_softc *sc) error = ENXIO; goto fail_ifnet; } - taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq", + error = taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq", device_get_nameunit(sc->sc_dev)); + if (error != 0) { + device_printf(sc->sc_dev, "could not start threads\n"); + goto fail_taskq; + } /* Make sure the chip is stopped. */ cas_reset(sc); @@ -339,10 +343,13 @@ cas_attach(struct cas_softc *sc) BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE); /* Enable/unfreeze the GMII pins of Saturn. */ if (sc->sc_variant == CAS_SATURN) { - CAS_WRITE_4(sc, CAS_SATURN_PCFG, 0); + CAS_WRITE_4(sc, CAS_SATURN_PCFG, + CAS_READ_4(sc, CAS_SATURN_PCFG) & + ~CAS_SATURN_PCFG_FSI); CAS_BARRIER(sc, CAS_SATURN_PCFG, 4, BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE); + DELAY(10000); } error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp, cas_mediachange, cas_mediastatus, BMSR_DEFCAPMASK, @@ -359,10 +366,12 @@ cas_attach(struct cas_softc *sc) /* Freeze the GMII pins of Saturn for saving power. */ if (sc->sc_variant == CAS_SATURN) { CAS_WRITE_4(sc, CAS_SATURN_PCFG, + CAS_READ_4(sc, CAS_SATURN_PCFG) | CAS_SATURN_PCFG_FSI); CAS_BARRIER(sc, CAS_SATURN_PCFG, 4, BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE); + DELAY(10000); } error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp, cas_mediachange, cas_mediastatus, BMSR_DEFCAPMASK, @@ -2865,7 +2874,7 @@ cas_pci_attach(device_t dev) goto fail; } i = 0; - if (lma > 1 && pci_get_slot(dev) < sizeof(enaddr) / sizeof(*enaddr)) + if (lma > 1 && pci_get_slot(dev) < nitems(enaddr)) i = pci_get_slot(dev); memcpy(sc->sc_enaddr, enaddr[i], ETHER_ADDR_LEN); @@ -2874,7 +2883,7 @@ cas_pci_attach(device_t dev) goto fail; } i = 0; - if (phy > 1 && pci_get_slot(dev) < sizeof(pcs) / sizeof(*pcs)) + if (phy > 1 && pci_get_slot(dev) < nitems(pcs)) i = pci_get_slot(dev); if (pcs[i] != 0) sc->sc_flags |= CAS_SERDES; --mJm6k4Vb/yFcL9ZU-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 17:08:15 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA9D5BE6 for ; Fri, 25 Jan 2013 17:08:15 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id 55498A97 for ; Fri, 25 Jan 2013 17:08:15 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MfTEr-1UMkSH0OnT-00P45Z for ; Fri, 25 Jan 2013 18:08:10 +0100 Received: (qmail invoked by alias); 25 Jan 2013 17:08:09 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp002) with SMTP; 25 Jan 2013 18:08:09 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+SgGJw7OqSOBofPCJSqsUzVxGRuVjDIRHBRhzPYn 8VStME5O41LgsX From: Christian Gusenbauer To: pyunyh@gmail.com Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Date: Fri, 25 Jan 2013 18:09:50 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301241805.57623.c47g@gmx.at> <20130125043043.GA1429@michelle.cdnetworks.com> <20130125045048.GB1429@michelle.cdnetworks.com> In-Reply-To: <20130125045048.GB1429@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301251809.50929.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, Konstantin Belousov , net@freebsd.org, John Baldwin , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 17:08:15 -0000 On Friday 25 January 2013 05:50:48 YongHyeon PYUN wrote: > On Fri, Jan 25, 2013 at 01:30:43PM +0900, YongHyeon PYUN wrote: > > On Thu, Jan 24, 2013 at 05:21:50PM -0500, John Baldwin wrote: > > > On Thursday, January 24, 2013 4:22:12 pm Konstantin Belousov wrote: > > > > On Thu, Jan 24, 2013 at 09:50:52PM +0100, Christian Gusenbauer wrote: > > > > > On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: > > > > > > On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote: > > > > > > > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > > > > > > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > > > > > > > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > I'm using 9.1 stable svn revision 245605 and I get the > > > > > > > > > > panic below if I execute the following commands (as > > > > > > > > > > single user): > > > > > > > > > > > > > > > > > > > > # swapon -a > > > > > > > > > > # dumpon /dev/ada0s3b > > > > > > > > > > # mount -u / > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > > > > > > > # mount -t nfs -o rsize=32768 data:/multimedia /mnt > > > > > > > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > > > > > > > > > > > > > > > > then the system panics almost immediately. I'll attach > > > > > > > > > > the stack trace. > > > > > > > > > > > > > > > > > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit > > > > > > > > > > network, maybe that's the cause for the panic, because > > > > > > > > > > the bcopy (see stack frame #15) fails. > > > > > > > > > > > > > > > > > > > > Any clues? > > > > > > > > > > > > > > > > > > I tried a similar operation with the nfs mount of > > > > > > > > > rsize=32768 and mtu 6144, but the machine runs HEAD and em > > > > > > > > > instead of age. I was unable to reproduce the panic on the > > > > > > > > > copy of the 5GB file from nfs mount. > > > > > > > > > > > > > > Hmmm, I did a quick test. If I do not change the MTU, so just > > > > > > > configuring age0 with > > > > > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 up > > > > > > > > > > > > > > then I can copy all files from the mounted directory without > > > > > > > any problems, too. So it's probably age0 related? > > > > > > > > > > > > From your backtrace and the buffer printout, I see somewhat > > > > > > strange thing. The buffer data address is 0xffffff8171418000, > > > > > > while kernel faulted at the attempt to write at > > > > > > 0xffffff8171413000, which is is lower then the buffer data > > > > > > pointer, at the attempt to bcopy to the buffer. > > > > > > > > > > > > The other data suggests that there were no overflow of the data > > > > > > from the server response. So it might be that mbuf_len(mp) > > > > > > returned negative number ? I am not sure is it possible at all. > > > > > > > > > > > > Try this debugging patch, please. You need to add INVARIANTS etc > > > > > > to the kernel config. > > > > > > > > > > > > diff --git a/sys/fs/nfs/nfs_commonsubs.c > > > > > > b/sys/fs/nfs/nfs_commonsubs.c index efc0786..9a6bda5 100644 > > > > > > --- a/sys/fs/nfs/nfs_commonsubs.c > > > > > > +++ b/sys/fs/nfs/nfs_commonsubs.c > > > > > > @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, > > > > > > struct uio *uiop, int siz) } > > > > > > > > > > > > mbufcp = NFSMTOD(mp, caddr_t); > > > > > > len = mbuf_len(mp); > > > > > > > > > > > > + KASSERT(len > 0, ("len %d", len)); > > > > > > > > > > > > } > > > > > > xfer = (left > len) ? len : left; > > > > > > > > > > > > #ifdef notdef > > > > > > > > > > > > @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, > > > > > > struct uio *uiop, int siz) uiop->uio_resid -= xfer; > > > > > > > > > > > > } > > > > > > if (uiop->uio_iov->iov_len <= siz) { > > > > > > > > > > > > + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", > > > > > > + uiop->uio_iovcnt)); > > > > > > > > > > > > uiop->uio_iovcnt--; > > > > > > uiop->uio_iov++; > > > > > > > > > > > > } else { > > > > > > > > > > > > I thought that server have returned too long response, but it > > > > > > seems to be not the case from your data. Still, I think the > > > > > > patch below might be due. > > > > > > > > > > > > diff --git a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 100644 > > > > > > --- a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > +++ b/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio > > > > > > *uiop, struct ucred *cred, NFSM_DISSECT(tl, u_int32_t *, > > > > > > NFSX_UNSIGNED); > > > > > > > > > > > > eof = fxdr_unsigned(int, *tl); > > > > > > > > > > > > } > > > > > > > > > > > > - NFSM_STRSIZ(retlen, rsize); > > > > > > + NFSM_STRSIZ(retlen, len); > > > > > > > > > > > > error = nfsm_mbufuio(nd, uiop, retlen); > > > > > > if (error) > > > > > > > > > > > > goto nfsmout; > > > > > > > > > > I applied your patches and now I get a > > > > > > > > > > panic: len -4 > > > > > cpuid = 1 > > > > > KDB: enter: panic > > > > > Dumping 377 out of 6116 > > > > > MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..94% > > > > > > > > This means that the age driver either produced corrupted mbuf chain, > > > > or filled wrong negative value into the mbuf len field. I am quite > > > > certain that the issue is in the driver. > > > > > > > > I added the net@ to Cc:, hopefully you could get help there. > > > > > > And I've cc'd Pyun who has written most of this driver and is likely > > > the one most familiar with its handling of jumbo frames. > > > > Try attached one and let me know how it goes. > > Note, I don't have age(4) anymore so it wasn't tested at all. > > Sorry, ignore previous patch and use this one(age.diff2) instead. Thanks for the patch! I ignored the first and applied only the second one, but unfortunately that did not change anything. I still get the "panic: len -4" :-(. Ciao, Christian. From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 17:33:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7461FDE for ; Fri, 25 Jan 2013 17:33:51 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id B706DBE7 for ; Fri, 25 Jan 2013 17:33:51 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h16so735001oag.5 for ; Fri, 25 Jan 2013 09:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=eRbF9wHtNXFBtm8xhf3nBLgYwr+3ZUJB237stotg0M8=; b=wmbbA4YKwEyakSAq513fOT/xR5to3y+wJfpj9NdEZu+Iflm89X+2ZjmYN5xooUmI7L ySlb3I6CkGMlOKSlgUc9PR6ddD8O624MyLxm3mJrQjNtuo8DjCyK0PkqEsmXxhECGjqF bGJDQqlQbHh3j+x5XixxhkSBwZ+zh+LVjxCj/U8r7MlnepqKrpi4OV3FmGv+qp4rRTed sdXZ9rIWXgJ8UZS26BRe1Q1iDii0e/nwr3lif8l1ze9YW0fao37AnxRRYneuj0Yk/hf+ AwRMsougAwjLr56brTM2jySYhNDuhQYJMv64sL1aGgOGWaEQPWeWKjADGBiKyFFcCddJ nLww== X-Received: by 10.182.118.106 with SMTP id kl10mr5143176obb.10.1359135224859; Fri, 25 Jan 2013 09:33:44 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.76.153.3 with HTTP; Fri, 25 Jan 2013 09:33:24 -0800 (PST) In-Reply-To: <20130124195056.GB1410@funkthat.com> References: <20130124195056.GB1410@funkthat.com> From: h bagade Date: Fri, 25 Jan 2013 21:03:24 +0330 X-Google-Sender-Auth: DXsRJ7w7DMYc0bc490MWazbtQ9Q Message-ID: Subject: Re: how to completely makes an interface down? To: John-Mark Gurney , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 17:33:52 -0000 On Thu, Jan 24, 2013 at 11:20 PM, John-Mark Gurney wrote: > h bagade wrote this message on Thu, Jan 24, 2013 at 16:59 +0330: > > I'm searching for a method or configuration which when I make the > interface > > down, the led goes off. Currently the led still remains on when I > shutdowns > > the interface! Is there any way to do this? > > Not all ethernet drivers disable the PHY when you down the interface... > You can try to use: > ifconfig media none > > to shutdown the PHY, but the em driver on 9.1 doesn't have it, but re > (7.2-R and -current) and msk (-current) seems to have it... > > Also, why do you want the led to go off? Remeber, the led is just an > indication if there is a link established, not what will happen to the > packets that are received... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > Thanks for your comments. What I wanna to do is informing the other end that the interface is down and also be able to find out that the other neighbors are also down or not! So firstly, I need to find a way to make the led go off like when the cable is not connected. Then I also need to know how to find out the other end is going off! From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 17:38:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2236F1AC for ; Fri, 25 Jan 2013 17:38:35 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (dauterive.egr.msu.edu [35.9.37.168]) by mx1.freebsd.org (Postfix) with ESMTP id E8E89C20 for ; Fri, 25 Jan 2013 17:38:34 +0000 (UTC) Received: from dauterive (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id E9CFA2EE80 for ; Fri, 25 Jan 2013 12:38:27 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by dauterive (dauterive.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrgimKwpEeE1 for ; Fri, 25 Jan 2013 12:38:27 -0500 (EST) Received: from EGR authenticated sender Message-ID: <5102C313.8060503@egr.msu.edu> Date: Fri, 25 Jan 2013 12:38:27 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130115 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: how to completely makes an interface down? References: <20130124195056.GB1410@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 17:38:35 -0000 On 01/25/13 12:33, h bagade wrote: > On Thu, Jan 24, 2013 at 11:20 PM, John-Mark Gurney wrote: > >> h bagade wrote this message on Thu, Jan 24, 2013 at 16:59 +0330: >>> I'm searching for a method or configuration which when I make the >> interface >>> down, the led goes off. Currently the led still remains on when I >> shutdowns >>> the interface! Is there any way to do this? >> >> Not all ethernet drivers disable the PHY when you down the interface... >> You can try to use: >> ifconfig media none >> >> to shutdown the PHY, but the em driver on 9.1 doesn't have it, but re >> (7.2-R and -current) and msk (-current) seems to have it... >> >> Also, why do you want the led to go off? Remeber, the led is just an >> indication if there is a link established, not what will happen to the >> packets that are received... >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." >> > > Thanks for your comments. What I wanna to do is informing the other end > that the interface is down and also be able to find out that the other > neighbors are also down or not! > So firstly, I need to find a way to make the led go off like when the cable > is not connected. Then I also need to know how to find out the other end is > going off! > _______________________________________________ > 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 use LACP on that link The state of LACP can indicate to both sides whether the other end is working. See if_lagg From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 19:15:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4B9ED83E for ; Fri, 25 Jan 2013 19:15:08 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront4.g2host.com [208.42.184.242]) by mx1.freebsd.org (Postfix) with ESMTP id 3F240210 for ; Fri, 25 Jan 2013 19:15:06 +0000 (UTC) Received: from [173.17.248.27] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 94576414; Fri, 25 Jan 2013 13:14:57 -0600 Message-ID: <5102D9AB.9010405@visi.com> Date: Fri, 25 Jan 2013 13:14:51 -0600 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Cas driver fails to load first time after boot. References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> <51017FF0.5080001@visi.com> <20130124215017.GS85306@alchemy.franken.de> <5101F264.7030206@visi.com> <20130125161916.GV85306@alchemy.franken.de> In-Reply-To: <20130125161916.GV85306@alchemy.franken.de> X-Is-From-Me: yes Content-Type: multipart/mixed; boundary="------------020606070600000405070109" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 19:15:08 -0000 This is a multi-part message in MIME format. --------------020606070600000405070109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/25/13 10:19, Marius Strobl wrote: > On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote: >> On 01/24/13 15:50, Marius Strobl wrote: >>> On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: >>>> On 01/24/13 09:09, Marius Strobl wrote: >>>>> On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: >>>>>> Hi, >>>>>> >>>>>> I've got a Dell R200 which I'm trying to build into a gateway with a Sun >>>>>> QGE (501-6738-10). The cas driver fails to load the first time I try to >>>>>> load it but succeeds the second time. Is this a problem with the card, >>>>>> the driver, my karma? >>>>> Wrong phase of the moon, apparently :) >>>>> The MII setup of these chips is a bit tricky and I'm not sure whether >>>>> I've hit all code paths during development of the driver. I certainly >>>>> didn't test with a 501-6738, these have been reported as working before, >>>>> though. It also doesn't make much sense that attaching the devices >>>>> succeeds on the second attempt. Could you please use a if_cas.ko built >>>>> with the attached patch and report the debug output for one of the >>>>> interfaces in both the working and the non-working case? >>>> I would love to give you output from the working and non-working case >>>> but apparently the phase of the moon has changed, I can't get it to fail >>>> now. The messages output from the working case is attached. >>>> >>> Thanks but unfortunately this doesn't make any sense either. In general, >>> printf()s cause deays which can be relevant. In the locations I've put >>> them they hardly can make such a difference though. >>> If you haven't already done so, could you please power off the machine >>> before doing the test with the patched module? Is the problem still gone >>> if you revert to the original module? >> OK, power-cycling makes a difference. The driver fails to attach all of >> the devices after power-cycling most of the time if not all of the >> time. The number of devices attached varies, the attached message file >> fragment is from my last test. Three of the devices were attached on >> the first load attempt and all four of them on the second attempt. > Okay, so we now at least have a way to reproduce the problem. > Unfortunately, it's still unclear what's the exact cause of it. At > least the problem is not what I suspected and hoped it most likely is. > Could you please test how things behave after a power-cycle with the > attached patche (after reverting the previous one). The patched driver fails to compile with the following error message: cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/LUCID/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/LUCID -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/cas/../../dev/cas/if_cas.c cc1: warnings being treated as errors /usr/src/sys/modules/cas/../../dev/cas/if_cas.c: In function 'cas_pci_attach': /usr/src/sys/modules/cas/../../dev/cas/if_cas.c:2883: warning: implicit declaration of function 'nitems' /usr/src/sys/modules/cas/../../dev/cas/if_cas.c:2883: warning: nested extern declaration of 'nitems' *** Error code 1 Stop in /usr/src/sys/modules/cas. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 I found the following defintion of nitems in the iwn and usb/wlan drivers: #define nitems(_a) (sizeof((_a)) / sizeof((_a)[0])) so I added it to if_cas.c and rebuilt without errors. This looks like like it fixed the problem. I ran three tests from power-up to loading the driver and the driver loaded successfully all three times. I then added if_cas_load="YES" to /boot/loader.conf and did two more successful reboots from power-up. Will this driver work on FreeBSD 9.1? I've attached a copy of /var/log/messages and the dmesg, ifconfi -a and kldstat -v output along with the modified driver source. Let me know if there's anything else you'd like me to test. Paul > > Marius > -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 --------------020606070600000405070109 Content-Type: text/plain; charset=us-ascii; name="dmesg.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-RELEASE #2: Fri Jan 25 11:16:50 CST 2013 toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4099166208 (3909 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 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 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 2.0 on pci3 pci4: on pcib4 cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 miibus0: on cas0 nsgphy0: PHY 1 on miibus0 nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas0: 16kB RX FIFO, 9kB TX FIFO cas0: Ethernet address: 00:14:4f:25:ca:10 cas0: [FILTER] cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 miibus1: on cas1 nsgphy1: PHY 1 on miibus1 nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas1: 16kB RX FIFO, 9kB TX FIFO cas1: Ethernet address: 00:14:4f:25:ca:11 cas1: [FILTER] cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 miibus2: on cas2 nsgphy2: PHY 1 on miibus2 nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas2: 16kB RX FIFO, 9kB TX FIFO cas2: Ethernet address: 00:14:4f:25:ca:12 cas2: [FILTER] cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 miibus3: on cas3 nsgphy3: PHY 1 on miibus3 nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas3: 16kB RX FIFO, 9kB TX FIFO cas3: Ethernet address: 00:14:4f:25:ca:13 cas3: [FILTER] pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus4: on bge0 brgphy0: PHY 1 on miibus4 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:19:b9:fa:82:51 bge0: [ITHREAD] pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus5: on bge1 brgphy1: PHY 1 on miibus5 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:19:b9:fa:82:52 bge1: [ITHREAD] uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib7: at device 30.0 on pci0 pci7: on pcib7 vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: at channel 0 on atapci0 ata2: [ITHREAD] ata3: at channel 1 on atapci0 ata3: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x7f irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 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: 480Mbps High Speed USB v2.0 ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s 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 acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 uhub4: on usbus3 uhub4: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ad4s1a bge0: link state changed to UP --------------020606070600000405070109 Content-Type: text/plain; charset=us-ascii; name="ifconfig.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ifconfig.out" cas0: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:10 media: Ethernet autoselect cas1: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:11 media: Ethernet autoselect cas2: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:12 media: Ethernet autoselect cas3: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:13 media: Ethernet autoselect bge0: flags=8843 metric 0 mtu 1500 options=8009b ether 00:19:b9:fa:82:51 inet 172.16.175.221 netmask 0xffffff00 broadcast 172.16.175.255 media: Ethernet autoselect (1000baseT ) status: active bge1: flags=8802 metric 0 mtu 1500 options=8009b ether 00:19:b9:fa:82:52 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 --------------020606070600000405070109 Content-Type: text/plain; charset=us-ascii; name="kldstat.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kldstat.out" Id Refs Address Size Name 1 7 0xffffffff80100000 e56d68 kernel (/boot/kernel/kernel) Contains modules: Id Name 89 ataraid 347 if_lo 358 newreno 408 elf32 335 shell 334 elf64 320 pseudofs 359 mld 357 igmp 349 if_vlan 344 if_faith 348 if_tun 287 uether 346 if_gif 339 sysvmsg 342 sem 340 sysvsem 341 sysvshm 369 krpc 365 nfslockd 360 nfs_common 364 nfssvc 363 nfsserver 333 cd9660 317 devfs 319 procfs 362 nfs 370 ufs 318 msdosfs 3 cam 59 ata 10 ada 7 probe 9 ch 329 g_part_mbr 328 g_part_gpt 327 g_part_ebr 326 g_part_bsd 14 ses 4 xpt 13 sa 12 pass 8 cd 5 aprobe 6 pmp 11 da 111 miibus/pnphy 425 root/nexus 424 nexus/ram 423 isa/sysresource 209 pci/isab 208 pci/ignore_pci 207 pci/hostb 206 pci/fixup_pci 205 pci/cbb 110 miibus/dcphy 109 pci/dc 422 nexus/qpi 421 qpi/pcib 420 isa/atdma 419 acpi/atdma 418 legacy/isa 204 isa/cbb 108 dc/miibus 417 isa/attimer 416 acpi/attimer 415 isa/atrtc 414 acpi/atrtc 413 cpu/p4tcc 107 pccard/cs 412 cpu/hwpstate 106 isa/cs 31 pci/acpi_pcib 411 cpu/est 410 cpu/powernow 58 pci/an 105 cpu/ichss 203 pcic/pccard 202 cbb/pccard 201 null 200 pci/nge 199 nge/miibus 57 pccard/an 407 isa/vga 406 vgapci/vgapm 104 pci/ciss 405 isa/sc 404 vgapm/scpm 56 isa/an 403 pci/isci 402 scrndr-vga 401 scterm-scteken 198 pci/mskc 197 mskc/msk 196 msk/miibus 400 pci/nfe 399 nfe/miibus 30 acpi/acpi_pcib 398 pci/hptrr 397 pci/hptmv 396 pccard/fdc 395 isa/fdc 394 acpi/fdc 393 fdc/fd 392 io 55 pci/amr 391 isa/ed 54 amr/amrd 193 pci/mpt 390 atkbdc/psm 389 isa/psmcpnp 388 acpi/psmcpnp 17 pci/aacch 387 isa/atkbdc 386 acpi/atkbdc 385 atkbdc/atkbd 384 pci/arcmsr 383 hostb/agp_via 382 hostb/agp_intel 381 vgapci/agp_i810 380 hostb/agp_amd64 24 acpi/acpi_ec 103 cbb/cardbus 379 legacy/pcib 378 isa/pcibus_pnp 102 pci/bt 101 isa/bt 190 pci/mps 100 pci/bge 189 pci/mly 188 pci/mlx 187 mlx/mlxd 186 miibus/xmphy 185 miibus/ukphy 184 miibus/truephy 183 miibus/tlphy 377 nexus/legacy 376 legacy/cpu 182 miibus/tdkphy 181 miibus/smcphy 375 pci/ioapic 374 nexus/apic 180 miibus/ruephy 373 acpi/fpupnp 179 miibus/rlphy 178 miibus/rgephy 177 miibus/rdcphy 176 miibus/qsphy 175 miibus/pnaphy 174 miibus/nsphyter 173 miibus/nsphy 172 miibus/nsgphy 372 root/nexus_acpi 171 miibus/mlphy 170 miibus/lxtphy 169 miibus/jmphy 168 miibus/ip1000phy 167 miibus/inphy 166 miibus/icsphy 165 miibus/gentbi 164 miibus/xlphy 163 miibus/e1000phy 162 miibus/ciphy 161 miibus/brgphy 160 miibus/bmtphy 159 miibus/axphy 158 miibus/atphy 157 miibus/amphy 156 miibus/acphy 155 mfi/mfid 154 pci/mfi 99 bge/miibus 16 aac/aacd 98 pci/bfe 97 bfe/miibus 96 pci/bce 336 cpu/cpufreq 153 mem 95 bce/miibus 53 pci/ale 52 ale/miibus 151 pci/lge 150 lge/miibus 23 acpi/cpu 149 pci/le 29 acpi/acpi_pci_link 148 kbdmux 51 pci/alc 50 alc/miibus 147 pci/jme 146 jme/miibus 145 pci/ixv 332 isa/orm 49 ahc 331 isab/isa 330 eisab/isa 48 ahd 47 pci/ahd 46 pci/ahc_pci 45 isa/ahc_isa 44 pccard/aic 368 pci/rl 367 cardbus/rl 366 rl/miibus 144 pci/ixgbe 19 nexus/acpi 28 pcib/acpi_pci 15 aac/aacp 43 pci/age 94 pci/ath 42 age/miibus 41 pci/ae 40 ae/miibus 27 acpi/acpi_lid 143 pci/isp 142 pci/ips 141 ips/ipsd 93 ata/ast 140 pci/iir 361 nfslock 39 pci/adw 139 pci/ida 138 ida/idad 137 pci/hptiop 136 pci/fxp 135 fxp/miibus 92 ata/afd 38 pci/adv 134 firewire/fwip 91 ata/acd 37 acpi/acpi_timer 90 ad/subdisk 36 cpu/acpi_throttle 133 firewire/fwe 132 pci/fwohci 88 ata/ad 316 pci/xl 315 xl/miibus 314 pccard/xe 313 pci/wi 312 pccard/wi 311 pci/wb 310 wb/miibus 309 watchdog 308 pci/vx 307 pci/vr 306 vr/miibus 87 pci/ata_via 305 pci/vge 304 vge/miibus 86 pci/ata_sis 303 uhub/ums 85 pci/ata_sii 131 fwohci/firewire 302 uhub/ukbd 301 uhub/uhid 130 pccard/fe 129 exca 128 pccard/ex 127 isa/ex 300 uhub/uvscom 299 uhub/uvisor 298 uhub/uslcom 297 uhub/uplcom 296 uhub/ulpt 295 uhub/uipaq 294 uhub/uftdi 293 uhub/ubsa 292 uhub/uark 291 uhub/zyd 290 uhub/ural 126 pci/esp 289 uhub/uath 288 uhub/rum 286 uhub/udav 285 udav/miibus 284 uhub/rue 283 rue/miibus 282 uhub/kue 281 uhub/cue 280 uhub/cdce 279 uhub/axe 278 axe/miibus 277 uhub/aue 276 aue/miibus 125 pccard/ep 124 isa/ep 84 pci/ata_serverworks 275 usbus/uhub 274 uhub/uhub 123 pci/et 122 et/miibus 83 pci/ata_promise 35 acpi/acpi_tz 82 pci/ata_nvidia 81 pci/ata_netcell 121 pci/igb 80 pci/ata_national 79 pci/ata_micron 78 pci/ata_marvell 273 uhub/usb_linux 272 uhub/urio 77 pci/ata_jmicron 271 uhub/umass 76 pci/ata_ite 75 pci/ata_intel 270 ohci/usbus 269 uhci/usbus 268 ehci/usbus 267 xhci/usbus 266 at91_udp/usbus 265 musbotg/usbus 264 uss820/usbus 263 pci/uhci 74 pci/ata_highpoint 73 pci/ata_cyrix 262 pci/ohci 120 pci/lem 261 pci/ehci 72 pci/ata_cypress 71 pci/ata_cenatek 26 acpi/acpi_isab 70 pci/ata_ati 69 pci/ata_amd 260 puc/uart 259 pci/uart 258 pccard/uart 257 isa/uart 256 acpi/uart 68 pci/ata_adaptec 255 pci/txp 254 pci/tx 253 tx/miibus 67 pci/ata_ali 66 pci/ata_acard 65 pci/ata_ahci 252 pci/tws 64 atapci/ata_ahci_ata 119 pci/em 251 pci/twe 250 twe/twed 22 acpi/acpi_cmbat 63 pci/atapci 249 pci/twa 248 pci/trm 247 pci/tl 246 tl/miibus 245 pci/ti 62 atapci/ata 244 pci/sym 243 pci/stge 242 stge/miibus 241 pci/ste 240 ste/miibus 239 pccard/sn 238 isa/sn 61 isa/ata 237 pci/skc 236 skc/sk 235 sk/miibus 234 pci/sis 233 sis/miibus 232 pci/sge 231 sge/miibus 230 pci/sf 229 sf/miibus 60 pccard/ata 34 acpi/acpi_smbat 33 acpi/acpi_sysresource 25 acpi/acpi_hpet 228 pci/re 227 re/miibus 21 acpi/acpi_button 226 random 225 pci/ral 224 pci/puc 223 pccard/puc 18 pci/aac 222 puc/ppc 221 pci/ppc 220 isa/ppc 219 acpi/ppc 218 ppbus/ppi 32 cpu/acpi_perf 217 ppc/ppbus 216 ppbus/lpt 118 pci/ed 215 ppbus/plip 214 pci/pcn 213 pcn/miibus 117 pccard/ed 212 pci/vgapci 211 pci/pcib 210 pcib/pci 116 ed/miibus 115 pci/dpt 114 pci/de 113 dcons 20 acpi/acpi_acad 112 firewire/dcons_crom 194 mpt_raid 192 mpt_cam 195 mpt_user 355 wlan_ratectl_none 337 rootbus 325 g_part 322 g_disk 338 firmware 354 wlan 353 wlan_wep 371 g_class 352 wlan_tkip 351 wlan_ccmp 321 g_dev 350 wlan_amrr 191 mpt_core 324 g_label 323 g_vfs 356 wlan_sta 152 g_md 343 ether 345 if_firewire 409 x86bios 2 1 0xffffffff80f57000 cdc0 if_cas.ko (/boot/kernel/if_cas.ko) Contains modules: Id Name 2 pci/cas 1 cas/miibus --------------020606070600000405070109 Content-Type: text/plain; charset=us-ascii; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages" Jan 25 11:00:01 lucid newsyslog[24712]: logfile turned over due to size>100K Jan 25 11:32:15 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 25 11:32:15 lucid kernel: miibus2: on cas0 Jan 25 11:32:15 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 25 11:32:15 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:32:15 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:32:15 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 25 11:32:15 lucid kernel: cas0: [FILTER] Jan 25 11:32:15 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 25 11:32:15 lucid kernel: miibus3: on cas1 Jan 25 11:32:15 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 25 11:32:15 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:32:15 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:32:15 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 25 11:32:15 lucid kernel: cas1: [FILTER] Jan 25 11:32:15 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 25 11:32:15 lucid kernel: miibus4: on cas2 Jan 25 11:32:15 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 25 11:32:15 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:32:15 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:32:15 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 25 11:32:15 lucid kernel: cas2: [FILTER] Jan 25 11:32:15 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 25 11:32:15 lucid kernel: miibus5: on cas3 Jan 25 11:32:15 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 25 11:32:15 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:32:15 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:32:15 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 25 11:32:15 lucid kernel: cas3: [FILTER] Jan 25 11:32:59 lucid login: ROOT LOGIN (toor) ON ttyv0 Jan 25 11:33:03 lucid shutdown: power-down by toor: Jan 25 11:33:05 lucid syslogd: exiting on signal 15 Jan 25 11:35:54 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 25 11:35:54 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 25 11:35:54 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 25 11:35:54 lucid kernel: The Regents of the University of California. All rights reserved. Jan 25 11:35:54 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 25 11:35:54 lucid kernel: FreeBSD 8.3-RELEASE #2: Fri Jan 25 11:16:50 CST 2013 Jan 25 11:35:54 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 25 11:35:54 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 25 11:35:54 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 25 11:35:54 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 25 11:35:54 lucid kernel: Features=0xbfebfbff Jan 25 11:35:54 lucid kernel: Features2=0xe3bd Jan 25 11:35:54 lucid kernel: AMD Features=0x20100800 Jan 25 11:35:54 lucid kernel: AMD Features2=0x1 Jan 25 11:35:54 lucid kernel: TSC: P-state invariant Jan 25 11:35:54 lucid kernel: real memory = 4294967296 (4096 MB) Jan 25 11:35:54 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 25 11:35:54 lucid kernel: ACPI APIC Table: Jan 25 11:35:54 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 25 11:35:54 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 25 11:35:54 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 25 11:35:54 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 25 11:35:54 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 25 11:35:54 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 25 11:35:54 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 25 11:35:54 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 25 11:35:54 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 25 11:35:54 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 25 11:35:54 lucid kernel: kbd1 at kbdmux0 Jan 25 11:35:54 lucid kernel: acpi0: on motherboard Jan 25 11:35:54 lucid kernel: acpi0: [ITHREAD] Jan 25 11:35:54 lucid kernel: acpi0: Power Button (fixed) Jan 25 11:35:54 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 25 11:35:54 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 25 11:35:54 lucid kernel: cpu0: on acpi0 Jan 25 11:35:54 lucid kernel: cpu1: on acpi0 Jan 25 11:35:54 lucid kernel: cpu2: on acpi0 Jan 25 11:35:54 lucid kernel: cpu3: on acpi0 Jan 25 11:35:54 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 25 11:35:54 lucid kernel: pci0: on pcib0 Jan 25 11:35:54 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 25 11:35:54 lucid kernel: pci1: on pcib1 Jan 25 11:35:54 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 25 11:35:54 lucid kernel: pci2: on pcib2 Jan 25 11:35:54 lucid kernel: pcib3: at device 0.0 on pci2 Jan 25 11:35:54 lucid kernel: pci3: on pcib3 Jan 25 11:35:54 lucid kernel: pcib4: at device 2.0 on pci3 Jan 25 11:35:54 lucid kernel: pci4: on pcib4 Jan 25 11:35:54 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 25 11:35:54 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 25 11:35:54 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 25 11:35:54 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 25 11:35:54 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 25 11:35:54 lucid kernel: pci5: on pcib5 Jan 25 11:35:54 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 25 11:35:54 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 11:35:54 lucid kernel: miibus0: on bge0 Jan 25 11:35:54 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 25 11:35:54 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:35:54 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 25 11:35:54 lucid kernel: bge0: [ITHREAD] Jan 25 11:35:54 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 25 11:35:54 lucid kernel: pci6: on pcib6 Jan 25 11:35:54 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 25 11:35:54 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 11:35:54 lucid kernel: miibus1: on bge1 Jan 25 11:35:54 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 25 11:35:54 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:35:54 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 25 11:35:54 lucid kernel: bge1: [ITHREAD] Jan 25 11:35:54 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 25 11:35:54 lucid kernel: uhci0: [ITHREAD] Jan 25 11:35:54 lucid kernel: usbus0: on uhci0 Jan 25 11:35:54 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 25 11:35:54 lucid kernel: uhci1: [ITHREAD] Jan 25 11:35:54 lucid kernel: usbus1: on uhci1 Jan 25 11:35:54 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 25 11:35:54 lucid kernel: uhci2: [ITHREAD] Jan 25 11:35:54 lucid kernel: usbus2: on uhci2 Jan 25 11:35:54 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 25 11:35:54 lucid kernel: ehci0: [ITHREAD] Jan 25 11:35:54 lucid kernel: usbus3: EHCI version 1.0 Jan 25 11:35:54 lucid kernel: usbus3: on ehci0 Jan 25 11:35:54 lucid kernel: pcib7: at device 30.0 on pci0 Jan 25 11:35:54 lucid kernel: pci7: on pcib7 Jan 25 11:35:54 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 25 11:35:54 lucid kernel: isab0: at device 31.0 on pci0 Jan 25 11:35:54 lucid kernel: isa0: on isab0 Jan 25 11:35:54 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 25 11:35:54 lucid kernel: atapci0: [ITHREAD] Jan 25 11:35:54 lucid kernel: ata2: at channel 0 on atapci0 Jan 25 11:35:54 lucid kernel: ata2: [ITHREAD] Jan 25 11:35:54 lucid kernel: ata3: at channel 1 on atapci0 Jan 25 11:35:54 lucid kernel: ata3: [ITHREAD] Jan 25 11:35:54 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 25 11:35:54 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 25 11:35:54 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 25 11:35:54 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 25 11:35:54 lucid kernel: fdc0: does not respond Jan 25 11:35:54 lucid kernel: device_attach: fdc0 attach returned 6 Jan 25 11:35:54 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 25 11:35:54 lucid kernel: uart0: [FILTER] Jan 25 11:35:54 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 25 11:35:54 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 25 11:35:54 lucid kernel: kbd0 at atkbd0 Jan 25 11:35:54 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 25 11:35:54 lucid kernel: atkbd0: [ITHREAD] Jan 25 11:35:54 lucid kernel: psm0: irq 12 on atkbdc0 Jan 25 11:35:54 lucid kernel: psm0: [GIANT-LOCKED] Jan 25 11:35:54 lucid kernel: psm0: [ITHREAD] Jan 25 11:35:54 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 25 11:35:54 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 25 11:35:54 lucid kernel: sc0: at flags 0x100 on isa0 Jan 25 11:35:54 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 25 11:35:54 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 25 11:35:54 lucid kernel: ppc0: cannot reserve I/O port range Jan 25 11:35:54 lucid kernel: est0: on cpu0 Jan 25 11:35:54 lucid kernel: p4tcc0: on cpu0 Jan 25 11:35:54 lucid kernel: est1: on cpu1 Jan 25 11:35:54 lucid kernel: p4tcc1: on cpu1 Jan 25 11:35:54 lucid kernel: est2: on cpu2 Jan 25 11:35:54 lucid kernel: p4tcc2: on cpu2 Jan 25 11:35:54 lucid kernel: est3: on cpu3 Jan 25 11:35:54 lucid kernel: p4tcc3: on cpu3 Jan 25 11:35:54 lucid kernel: Timecounters tick every 1.000 msec Jan 25 11:35:54 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 25 11:35:54 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 25 11:35:54 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 25 11:35:54 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 25 11:35:54 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 25 11:35:54 lucid kernel: ugen0.1: at usbus0 Jan 25 11:35:54 lucid kernel: uhub0: on usbus0 Jan 25 11:35:54 lucid kernel: ugen1.1: at usbus1 Jan 25 11:35:54 lucid kernel: uhub1: on usbus1 Jan 25 11:35:54 lucid kernel: ugen2.1: at usbus2 Jan 25 11:35:54 lucid kernel: uhub2: on usbus2 Jan 25 11:35:54 lucid kernel: ugen3.1: at usbus3 Jan 25 11:35:54 lucid kernel: uhub3: on usbus3 Jan 25 11:35:54 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 25 11:35:54 lucid kernel: SMP: AP CPU #3 Launched! Jan 25 11:35:54 lucid kernel: SMP: AP CPU #1 Launched! Jan 25 11:35:54 lucid kernel: SMP: AP CPU #2 Launched! Jan 25 11:35:54 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 25 11:35:54 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 25 11:35:54 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 25 11:35:54 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 25 11:35:54 lucid kernel: Root mount waiting for: usbus3 Jan 25 11:35:54 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 25 11:35:54 lucid kernel: Root mount waiting for: usbus3 Jan 25 11:35:54 lucid kernel: ugen3.2: at usbus3 Jan 25 11:35:54 lucid kernel: uhub4: on usbus3 Jan 25 11:35:54 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 25 11:35:54 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 25 11:35:56 lucid kernel: bge0: link state changed to UP Jan 25 11:38:02 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 25 11:38:02 lucid kernel: miibus2: on cas0 Jan 25 11:38:02 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 25 11:38:02 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:38:02 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:38:02 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 25 11:38:02 lucid kernel: cas0: [FILTER] Jan 25 11:38:02 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 25 11:38:02 lucid kernel: miibus3: on cas1 Jan 25 11:38:02 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 25 11:38:02 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:38:02 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:38:02 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 25 11:38:02 lucid kernel: cas1: [FILTER] Jan 25 11:38:02 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 25 11:38:02 lucid kernel: miibus4: on cas2 Jan 25 11:38:02 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 25 11:38:02 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:38:02 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:38:02 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 25 11:38:02 lucid kernel: cas2: [FILTER] Jan 25 11:38:02 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 25 11:38:02 lucid kernel: miibus5: on cas3 Jan 25 11:38:02 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 25 11:38:02 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:38:02 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:38:02 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 25 11:38:02 lucid kernel: cas3: [FILTER] Jan 25 11:40:08 lucid shutdown: power-down by toor: Jan 25 11:40:11 lucid syslogd: exiting on signal 15 Jan 25 11:43:49 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 25 11:43:49 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 25 11:43:49 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 25 11:43:49 lucid kernel: The Regents of the University of California. All rights reserved. Jan 25 11:43:49 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 25 11:43:49 lucid kernel: FreeBSD 8.3-RELEASE #2: Fri Jan 25 11:16:50 CST 2013 Jan 25 11:43:49 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 25 11:43:49 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 25 11:43:49 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 25 11:43:49 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 25 11:43:49 lucid kernel: Features=0xbfebfbff Jan 25 11:43:49 lucid kernel: Features2=0xe3bd Jan 25 11:43:49 lucid kernel: AMD Features=0x20100800 Jan 25 11:43:49 lucid kernel: AMD Features2=0x1 Jan 25 11:43:49 lucid kernel: TSC: P-state invariant Jan 25 11:43:49 lucid kernel: real memory = 4294967296 (4096 MB) Jan 25 11:43:49 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 25 11:43:49 lucid kernel: ACPI APIC Table: Jan 25 11:43:49 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 25 11:43:49 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 25 11:43:49 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 25 11:43:49 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 25 11:43:49 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 25 11:43:49 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 25 11:43:49 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 25 11:43:49 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 25 11:43:49 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 25 11:43:49 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 25 11:43:49 lucid kernel: kbd1 at kbdmux0 Jan 25 11:43:49 lucid kernel: acpi0: on motherboard Jan 25 11:43:49 lucid kernel: acpi0: [ITHREAD] Jan 25 11:43:49 lucid kernel: acpi0: Power Button (fixed) Jan 25 11:43:49 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 25 11:43:49 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 25 11:43:49 lucid kernel: cpu0: on acpi0 Jan 25 11:43:49 lucid kernel: cpu1: on acpi0 Jan 25 11:43:49 lucid kernel: cpu2: on acpi0 Jan 25 11:43:49 lucid kernel: cpu3: on acpi0 Jan 25 11:43:49 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 25 11:43:49 lucid kernel: pci0: on pcib0 Jan 25 11:43:49 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 25 11:43:49 lucid kernel: pci1: on pcib1 Jan 25 11:43:49 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 25 11:43:49 lucid kernel: pci2: on pcib2 Jan 25 11:43:49 lucid kernel: pcib3: at device 0.0 on pci2 Jan 25 11:43:49 lucid kernel: pci3: on pcib3 Jan 25 11:43:49 lucid kernel: pcib4: at device 2.0 on pci3 Jan 25 11:43:49 lucid kernel: pci4: on pcib4 Jan 25 11:43:49 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 25 11:43:49 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 25 11:43:49 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 25 11:43:49 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 25 11:43:49 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 25 11:43:49 lucid kernel: pci5: on pcib5 Jan 25 11:43:49 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 25 11:43:49 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 11:43:49 lucid kernel: miibus0: on bge0 Jan 25 11:43:49 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 25 11:43:49 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:43:49 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 25 11:43:49 lucid kernel: bge0: [ITHREAD] Jan 25 11:43:49 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 25 11:43:49 lucid kernel: pci6: on pcib6 Jan 25 11:43:49 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 25 11:43:49 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 11:43:49 lucid kernel: miibus1: on bge1 Jan 25 11:43:49 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 25 11:43:49 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:43:49 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 25 11:43:49 lucid kernel: bge1: [ITHREAD] Jan 25 11:43:49 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 25 11:43:49 lucid kernel: uhci0: [ITHREAD] Jan 25 11:43:49 lucid kernel: usbus0: on uhci0 Jan 25 11:43:49 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 25 11:43:49 lucid kernel: uhci1: [ITHREAD] Jan 25 11:43:49 lucid kernel: usbus1: on uhci1 Jan 25 11:43:49 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 25 11:43:49 lucid kernel: uhci2: [ITHREAD] Jan 25 11:43:49 lucid kernel: usbus2: on uhci2 Jan 25 11:43:49 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 25 11:43:49 lucid kernel: ehci0: [ITHREAD] Jan 25 11:43:49 lucid kernel: usbus3: EHCI version 1.0 Jan 25 11:43:49 lucid kernel: usbus3: on ehci0 Jan 25 11:43:49 lucid kernel: pcib7: at device 30.0 on pci0 Jan 25 11:43:49 lucid kernel: pci7: on pcib7 Jan 25 11:43:49 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 25 11:43:49 lucid kernel: isab0: at device 31.0 on pci0 Jan 25 11:43:49 lucid kernel: isa0: on isab0 Jan 25 11:43:49 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 25 11:43:49 lucid kernel: atapci0: [ITHREAD] Jan 25 11:43:49 lucid kernel: ata2: at channel 0 on atapci0 Jan 25 11:43:49 lucid kernel: ata2: [ITHREAD] Jan 25 11:43:49 lucid kernel: ata3: at channel 1 on atapci0 Jan 25 11:43:49 lucid kernel: ata3: [ITHREAD] Jan 25 11:43:49 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 25 11:43:49 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 25 11:43:49 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 25 11:43:49 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 25 11:43:49 lucid kernel: fdc0: does not respond Jan 25 11:43:49 lucid kernel: device_attach: fdc0 attach returned 6 Jan 25 11:43:49 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 25 11:43:49 lucid kernel: uart0: [FILTER] Jan 25 11:43:49 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 25 11:43:49 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 25 11:43:49 lucid kernel: kbd0 at atkbd0 Jan 25 11:43:49 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 25 11:43:49 lucid kernel: atkbd0: [ITHREAD] Jan 25 11:43:49 lucid kernel: psm0: irq 12 on atkbdc0 Jan 25 11:43:49 lucid kernel: psm0: [GIANT-LOCKED] Jan 25 11:43:49 lucid kernel: psm0: [ITHREAD] Jan 25 11:43:49 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 25 11:43:49 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 25 11:43:49 lucid kernel: sc0: at flags 0x100 on isa0 Jan 25 11:43:49 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 25 11:43:49 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 25 11:43:49 lucid kernel: ppc0: cannot reserve I/O port range Jan 25 11:43:49 lucid kernel: est0: on cpu0 Jan 25 11:43:49 lucid kernel: p4tcc0: on cpu0 Jan 25 11:43:49 lucid kernel: est1: on cpu1 Jan 25 11:43:49 lucid kernel: p4tcc1: on cpu1 Jan 25 11:43:49 lucid kernel: est2: on cpu2 Jan 25 11:43:49 lucid kernel: p4tcc2: on cpu2 Jan 25 11:43:49 lucid kernel: est3: on cpu3 Jan 25 11:43:49 lucid kernel: p4tcc3: on cpu3 Jan 25 11:43:49 lucid kernel: Timecounters tick every 1.000 msec Jan 25 11:43:49 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 25 11:43:49 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 25 11:43:49 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 25 11:43:49 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 25 11:43:49 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 25 11:43:49 lucid kernel: ugen0.1: at usbus0 Jan 25 11:43:49 lucid kernel: uhub0: on usbus0 Jan 25 11:43:49 lucid kernel: ugen1.1: at usbus1 Jan 25 11:43:49 lucid kernel: uhub1: on usbus1 Jan 25 11:43:49 lucid kernel: ugen2.1: at usbus2 Jan 25 11:43:49 lucid kernel: uhub2: on usbus2 Jan 25 11:43:49 lucid kernel: ugen3.1: at usbus3 Jan 25 11:43:49 lucid kernel: uhub3: on usbus3 Jan 25 11:43:49 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 25 11:43:49 lucid kernel: SMP: AP CPU #3 Launched! Jan 25 11:43:49 lucid kernel: SMP: AP CPU #1 Launched! Jan 25 11:43:49 lucid kernel: SMP: AP CPU #2 Launched! Jan 25 11:43:49 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 25 11:43:49 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 25 11:43:49 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 25 11:43:49 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 25 11:43:49 lucid kernel: Root mount waiting for: usbus3 Jan 25 11:43:49 lucid kernel: Root mount waiting for: usbus3 Jan 25 11:43:49 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 25 11:43:49 lucid kernel: Root mount waiting for: usbus3 Jan 25 11:43:49 lucid kernel: ugen3.2: at usbus3 Jan 25 11:43:49 lucid kernel: uhub4: on usbus3 Jan 25 11:43:49 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 25 11:43:49 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 25 11:43:51 lucid kernel: bge0: link state changed to UP Jan 25 11:47:41 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 25 11:47:41 lucid kernel: miibus2: on cas0 Jan 25 11:47:41 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 25 11:47:41 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:47:41 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:47:41 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 25 11:47:41 lucid kernel: cas0: [FILTER] Jan 25 11:47:41 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 25 11:47:41 lucid kernel: miibus3: on cas1 Jan 25 11:47:41 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 25 11:47:41 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:47:41 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:47:41 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 25 11:47:41 lucid kernel: cas1: [FILTER] Jan 25 11:47:41 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 25 11:47:41 lucid kernel: miibus4: on cas2 Jan 25 11:47:41 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 25 11:47:41 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:47:41 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:47:41 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 25 11:47:41 lucid kernel: cas2: [FILTER] Jan 25 11:47:41 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 25 11:47:41 lucid kernel: miibus5: on cas3 Jan 25 11:47:41 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 25 11:47:41 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 11:47:41 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 25 11:47:41 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 25 11:47:41 lucid kernel: cas3: [FILTER] Jan 25 11:47:55 lucid shutdown: power-down by toor: Jan 25 11:47:57 lucid syslogd: exiting on signal 15 Jan 25 12:50:49 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 25 12:50:49 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 25 12:50:49 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 25 12:50:49 lucid kernel: The Regents of the University of California. All rights reserved. Jan 25 12:50:49 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 25 12:50:49 lucid kernel: FreeBSD 8.3-RELEASE #2: Fri Jan 25 11:16:50 CST 2013 Jan 25 12:50:49 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 25 12:50:49 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 25 12:50:49 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 25 12:50:49 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 25 12:50:49 lucid kernel: Features=0xbfebfbff Jan 25 12:50:49 lucid kernel: Features2=0xe3bd Jan 25 12:50:49 lucid kernel: AMD Features=0x20100800 Jan 25 12:50:49 lucid kernel: AMD Features2=0x1 Jan 25 12:50:49 lucid kernel: TSC: P-state invariant Jan 25 12:50:49 lucid kernel: real memory = 4294967296 (4096 MB) Jan 25 12:50:49 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 25 12:50:49 lucid kernel: ACPI APIC Table: Jan 25 12:50:49 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 25 12:50:49 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 25 12:50:49 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 25 12:50:49 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 25 12:50:49 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 25 12:50:49 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 25 12:50:49 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 25 12:50:49 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 25 12:50:49 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 25 12:50:49 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 25 12:50:49 lucid kernel: kbd1 at kbdmux0 Jan 25 12:50:49 lucid kernel: acpi0: on motherboard Jan 25 12:50:49 lucid kernel: acpi0: [ITHREAD] Jan 25 12:50:49 lucid kernel: acpi0: Power Button (fixed) Jan 25 12:50:49 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 25 12:50:49 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 25 12:50:49 lucid kernel: cpu0: on acpi0 Jan 25 12:50:49 lucid kernel: cpu1: on acpi0 Jan 25 12:50:49 lucid kernel: cpu2: on acpi0 Jan 25 12:50:49 lucid kernel: cpu3: on acpi0 Jan 25 12:50:49 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 25 12:50:49 lucid kernel: pci0: on pcib0 Jan 25 12:50:49 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 25 12:50:49 lucid kernel: pci1: on pcib1 Jan 25 12:50:49 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 25 12:50:49 lucid kernel: pci2: on pcib2 Jan 25 12:50:49 lucid kernel: pcib3: at device 0.0 on pci2 Jan 25 12:50:49 lucid kernel: pci3: on pcib3 Jan 25 12:50:49 lucid kernel: pcib4: at device 2.0 on pci3 Jan 25 12:50:49 lucid kernel: pci4: on pcib4 Jan 25 12:50:49 lucid kernel: pci4: at device 0.0 (no driver attached) Jan 25 12:50:49 lucid kernel: pci4: at device 1.0 (no driver attached) Jan 25 12:50:49 lucid kernel: pci4: at device 2.0 (no driver attached) Jan 25 12:50:49 lucid kernel: pci4: at device 3.0 (no driver attached) Jan 25 12:50:49 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 25 12:50:49 lucid kernel: pci5: on pcib5 Jan 25 12:50:49 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 25 12:50:49 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 12:50:49 lucid kernel: miibus0: on bge0 Jan 25 12:50:49 lucid kernel: brgphy0: PHY 1 on miibus0 Jan 25 12:50:49 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 12:50:49 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 25 12:50:49 lucid kernel: bge0: [ITHREAD] Jan 25 12:50:49 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 25 12:50:49 lucid kernel: pci6: on pcib6 Jan 25 12:50:49 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 25 12:50:49 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 12:50:49 lucid kernel: miibus1: on bge1 Jan 25 12:50:49 lucid kernel: brgphy1: PHY 1 on miibus1 Jan 25 12:50:49 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 12:50:49 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 25 12:50:49 lucid kernel: bge1: [ITHREAD] Jan 25 12:50:49 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 25 12:50:49 lucid kernel: uhci0: [ITHREAD] Jan 25 12:50:49 lucid kernel: usbus0: on uhci0 Jan 25 12:50:49 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 25 12:50:49 lucid kernel: uhci1: [ITHREAD] Jan 25 12:50:49 lucid kernel: usbus1: on uhci1 Jan 25 12:50:49 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 25 12:50:49 lucid kernel: uhci2: [ITHREAD] Jan 25 12:50:49 lucid kernel: usbus2: on uhci2 Jan 25 12:50:49 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 25 12:50:49 lucid kernel: ehci0: [ITHREAD] Jan 25 12:50:49 lucid kernel: usbus3: EHCI version 1.0 Jan 25 12:50:49 lucid kernel: usbus3: on ehci0 Jan 25 12:50:49 lucid kernel: pcib7: at device 30.0 on pci0 Jan 25 12:50:49 lucid kernel: pci7: on pcib7 Jan 25 12:50:49 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 25 12:50:49 lucid kernel: isab0: at device 31.0 on pci0 Jan 25 12:50:49 lucid kernel: isa0: on isab0 Jan 25 12:50:49 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 25 12:50:49 lucid kernel: atapci0: [ITHREAD] Jan 25 12:50:49 lucid kernel: ata2: at channel 0 on atapci0 Jan 25 12:50:49 lucid kernel: ata2: [ITHREAD] Jan 25 12:50:49 lucid kernel: ata3: at channel 1 on atapci0 Jan 25 12:50:49 lucid kernel: ata3: [ITHREAD] Jan 25 12:50:49 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 25 12:50:49 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 25 12:50:49 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 25 12:50:49 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 25 12:50:49 lucid kernel: fdc0: does not respond Jan 25 12:50:49 lucid kernel: device_attach: fdc0 attach returned 6 Jan 25 12:50:49 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 25 12:50:49 lucid kernel: uart0: [FILTER] Jan 25 12:50:49 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 25 12:50:49 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 25 12:50:49 lucid kernel: kbd0 at atkbd0 Jan 25 12:50:49 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 25 12:50:49 lucid kernel: atkbd0: [ITHREAD] Jan 25 12:50:49 lucid kernel: psm0: irq 12 on atkbdc0 Jan 25 12:50:49 lucid kernel: psm0: [GIANT-LOCKED] Jan 25 12:50:49 lucid kernel: psm0: [ITHREAD] Jan 25 12:50:49 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 25 12:50:49 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 25 12:50:49 lucid kernel: sc0: at flags 0x100 on isa0 Jan 25 12:50:49 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 25 12:50:49 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 25 12:50:49 lucid kernel: ppc0: cannot reserve I/O port range Jan 25 12:50:49 lucid kernel: est0: on cpu0 Jan 25 12:50:49 lucid kernel: p4tcc0: on cpu0 Jan 25 12:50:49 lucid kernel: est1: on cpu1 Jan 25 12:50:49 lucid kernel: p4tcc1: on cpu1 Jan 25 12:50:49 lucid kernel: est2: on cpu2 Jan 25 12:50:49 lucid kernel: p4tcc2: on cpu2 Jan 25 12:50:49 lucid kernel: est3: on cpu3 Jan 25 12:50:49 lucid kernel: p4tcc3: on cpu3 Jan 25 12:50:49 lucid kernel: Timecounters tick every 1.000 msec Jan 25 12:50:49 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 25 12:50:49 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 25 12:50:49 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 25 12:50:49 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 25 12:50:49 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 25 12:50:49 lucid kernel: ugen0.1: at usbus0 Jan 25 12:50:49 lucid kernel: uhub0: on usbus0 Jan 25 12:50:49 lucid kernel: ugen1.1: at usbus1 Jan 25 12:50:49 lucid kernel: uhub1: on usbus1 Jan 25 12:50:49 lucid kernel: ugen2.1: at usbus2 Jan 25 12:50:49 lucid kernel: uhub2: on usbus2 Jan 25 12:50:49 lucid kernel: ugen3.1: at usbus3 Jan 25 12:50:49 lucid kernel: uhub3: on usbus3 Jan 25 12:50:49 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 25 12:50:49 lucid kernel: SMP: AP CPU #3 Launched! Jan 25 12:50:49 lucid kernel: SMP: AP CPU #1 Launched! Jan 25 12:50:49 lucid kernel: SMP: AP CPU #2 Launched! Jan 25 12:50:49 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 25 12:50:49 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 25 12:50:49 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 25 12:50:49 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 25 12:50:49 lucid kernel: Root mount waiting for: usbus3 Jan 25 12:50:49 lucid kernel: Root mount waiting for: usbus3 Jan 25 12:50:49 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 25 12:50:49 lucid kernel: Root mount waiting for: usbus3 Jan 25 12:50:49 lucid kernel: ugen3.2: at usbus3 Jan 25 12:50:49 lucid kernel: uhub4: on usbus3 Jan 25 12:50:49 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 25 12:50:49 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 25 12:50:51 lucid kernel: bge0: link state changed to UP Jan 25 12:59:40 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 25 12:59:40 lucid kernel: miibus2: on cas0 Jan 25 12:59:40 lucid kernel: nsgphy0: PHY 1 on miibus2 Jan 25 12:59:40 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 12:59:40 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 25 12:59:40 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 25 12:59:40 lucid kernel: cas0: [FILTER] Jan 25 12:59:40 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 25 12:59:40 lucid kernel: miibus3: on cas1 Jan 25 12:59:40 lucid kernel: nsgphy1: PHY 1 on miibus3 Jan 25 12:59:40 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 12:59:40 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 25 12:59:40 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 25 12:59:40 lucid kernel: cas1: [FILTER] Jan 25 12:59:40 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 25 12:59:40 lucid kernel: miibus4: on cas2 Jan 25 12:59:40 lucid kernel: nsgphy2: PHY 1 on miibus4 Jan 25 12:59:40 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 12:59:40 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 25 12:59:40 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 25 12:59:40 lucid kernel: cas2: [FILTER] Jan 25 12:59:40 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 25 12:59:40 lucid kernel: miibus5: on cas3 Jan 25 12:59:40 lucid kernel: nsgphy3: PHY 1 on miibus5 Jan 25 12:59:40 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 12:59:40 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 25 12:59:40 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 25 12:59:40 lucid kernel: cas3: [FILTER] Jan 25 13:03:31 lucid shutdown: power-down by toor: Jan 25 13:03:34 lucid syslogd: exiting on signal 15 Jan 25 13:05:18 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 25 13:05:18 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 25 13:05:18 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 25 13:05:18 lucid kernel: The Regents of the University of California. All rights reserved. Jan 25 13:05:18 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 25 13:05:18 lucid kernel: FreeBSD 8.3-RELEASE #2: Fri Jan 25 11:16:50 CST 2013 Jan 25 13:05:18 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 25 13:05:18 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 25 13:05:18 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 25 13:05:18 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 25 13:05:18 lucid kernel: Features=0xbfebfbff Jan 25 13:05:18 lucid kernel: Features2=0xe3bd Jan 25 13:05:18 lucid kernel: AMD Features=0x20100800 Jan 25 13:05:18 lucid kernel: AMD Features2=0x1 Jan 25 13:05:18 lucid kernel: TSC: P-state invariant Jan 25 13:05:18 lucid kernel: real memory = 4294967296 (4096 MB) Jan 25 13:05:18 lucid kernel: avail memory = 4099166208 (3909 MB) Jan 25 13:05:18 lucid kernel: ACPI APIC Table: Jan 25 13:05:18 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 25 13:05:18 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 25 13:05:18 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 25 13:05:18 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 25 13:05:18 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 25 13:05:18 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 25 13:05:18 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 25 13:05:18 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 25 13:05:18 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 25 13:05:18 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 25 13:05:18 lucid kernel: kbd1 at kbdmux0 Jan 25 13:05:18 lucid kernel: acpi0: on motherboard Jan 25 13:05:18 lucid kernel: acpi0: [ITHREAD] Jan 25 13:05:18 lucid kernel: acpi0: Power Button (fixed) Jan 25 13:05:18 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 25 13:05:18 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 25 13:05:18 lucid kernel: cpu0: on acpi0 Jan 25 13:05:18 lucid kernel: cpu1: on acpi0 Jan 25 13:05:18 lucid kernel: cpu2: on acpi0 Jan 25 13:05:18 lucid kernel: cpu3: on acpi0 Jan 25 13:05:18 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 25 13:05:18 lucid kernel: pci0: on pcib0 Jan 25 13:05:18 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 25 13:05:18 lucid kernel: pci1: on pcib1 Jan 25 13:05:18 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 25 13:05:18 lucid kernel: pci2: on pcib2 Jan 25 13:05:18 lucid kernel: pcib3: at device 0.0 on pci2 Jan 25 13:05:18 lucid kernel: pci3: on pcib3 Jan 25 13:05:18 lucid kernel: pcib4: at device 2.0 on pci3 Jan 25 13:05:18 lucid kernel: pci4: on pcib4 Jan 25 13:05:18 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 25 13:05:18 lucid kernel: miibus0: on cas0 Jan 25 13:05:18 lucid kernel: nsgphy0: PHY 1 on miibus0 Jan 25 13:05:18 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:05:18 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:05:18 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 25 13:05:18 lucid kernel: cas0: [FILTER] Jan 25 13:05:18 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 25 13:05:18 lucid kernel: miibus1: on cas1 Jan 25 13:05:18 lucid kernel: nsgphy1: PHY 1 on miibus1 Jan 25 13:05:18 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:05:18 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:05:18 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 25 13:05:18 lucid kernel: cas1: [FILTER] Jan 25 13:05:18 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 25 13:05:18 lucid kernel: miibus2: on cas2 Jan 25 13:05:18 lucid kernel: nsgphy2: PHY 1 on miibus2 Jan 25 13:05:18 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:05:18 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:05:18 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 25 13:05:18 lucid kernel: cas2: [FILTER] Jan 25 13:05:18 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 25 13:05:18 lucid kernel: miibus3: on cas3 Jan 25 13:05:18 lucid kernel: nsgphy3: PHY 1 on miibus3 Jan 25 13:05:18 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:05:18 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:05:18 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 25 13:05:18 lucid kernel: cas3: [FILTER] Jan 25 13:05:18 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 25 13:05:18 lucid kernel: pci5: on pcib5 Jan 25 13:05:18 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 25 13:05:18 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 13:05:18 lucid kernel: miibus4: on bge0 Jan 25 13:05:18 lucid kernel: brgphy0: PHY 1 on miibus4 Jan 25 13:05:18 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:05:18 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 25 13:05:18 lucid kernel: bge0: [ITHREAD] Jan 25 13:05:18 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 25 13:05:18 lucid kernel: pci6: on pcib6 Jan 25 13:05:18 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 25 13:05:18 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 13:05:18 lucid kernel: miibus5: on bge1 Jan 25 13:05:18 lucid kernel: brgphy1: PHY 1 on miibus5 Jan 25 13:05:18 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:05:18 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 25 13:05:18 lucid kernel: bge1: [ITHREAD] Jan 25 13:05:18 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 25 13:05:18 lucid kernel: uhci0: [ITHREAD] Jan 25 13:05:18 lucid kernel: usbus0: on uhci0 Jan 25 13:05:18 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 25 13:05:18 lucid kernel: uhci1: [ITHREAD] Jan 25 13:05:18 lucid kernel: usbus1: on uhci1 Jan 25 13:05:18 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 25 13:05:18 lucid kernel: uhci2: [ITHREAD] Jan 25 13:05:18 lucid kernel: usbus2: on uhci2 Jan 25 13:05:18 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 25 13:05:18 lucid kernel: ehci0: [ITHREAD] Jan 25 13:05:18 lucid kernel: usbus3: EHCI version 1.0 Jan 25 13:05:18 lucid kernel: usbus3: on ehci0 Jan 25 13:05:18 lucid kernel: pcib7: at device 30.0 on pci0 Jan 25 13:05:18 lucid kernel: pci7: on pcib7 Jan 25 13:05:18 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 25 13:05:18 lucid kernel: isab0: at device 31.0 on pci0 Jan 25 13:05:18 lucid kernel: isa0: on isab0 Jan 25 13:05:18 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 25 13:05:18 lucid kernel: atapci0: [ITHREAD] Jan 25 13:05:18 lucid kernel: ata2: at channel 0 on atapci0 Jan 25 13:05:18 lucid kernel: ata2: [ITHREAD] Jan 25 13:05:18 lucid kernel: ata3: at channel 1 on atapci0 Jan 25 13:05:18 lucid kernel: ata3: [ITHREAD] Jan 25 13:05:18 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 25 13:05:18 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 25 13:05:18 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 25 13:05:18 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 25 13:05:18 lucid kernel: fdc0: does not respond Jan 25 13:05:18 lucid kernel: device_attach: fdc0 attach returned 6 Jan 25 13:05:18 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 25 13:05:18 lucid kernel: uart0: [FILTER] Jan 25 13:05:18 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 25 13:05:18 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 25 13:05:18 lucid kernel: kbd0 at atkbd0 Jan 25 13:05:18 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 25 13:05:18 lucid kernel: atkbd0: [ITHREAD] Jan 25 13:05:18 lucid kernel: psm0: irq 12 on atkbdc0 Jan 25 13:05:18 lucid kernel: psm0: [GIANT-LOCKED] Jan 25 13:05:18 lucid kernel: psm0: [ITHREAD] Jan 25 13:05:18 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 25 13:05:18 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 25 13:05:18 lucid kernel: sc0: at flags 0x100 on isa0 Jan 25 13:05:18 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 25 13:05:18 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 25 13:05:18 lucid kernel: ppc0: cannot reserve I/O port range Jan 25 13:05:18 lucid kernel: est0: on cpu0 Jan 25 13:05:18 lucid kernel: p4tcc0: on cpu0 Jan 25 13:05:18 lucid kernel: est1: on cpu1 Jan 25 13:05:18 lucid kernel: p4tcc1: on cpu1 Jan 25 13:05:18 lucid kernel: est2: on cpu2 Jan 25 13:05:18 lucid kernel: p4tcc2: on cpu2 Jan 25 13:05:18 lucid kernel: est3: on cpu3 Jan 25 13:05:18 lucid kernel: p4tcc3: on cpu3 Jan 25 13:05:18 lucid kernel: Timecounters tick every 1.000 msec Jan 25 13:05:18 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 25 13:05:18 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 25 13:05:18 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 25 13:05:18 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 25 13:05:18 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 25 13:05:18 lucid kernel: ugen0.1: at usbus0 Jan 25 13:05:18 lucid kernel: uhub0: on usbus0 Jan 25 13:05:18 lucid kernel: ugen1.1: at usbus1 Jan 25 13:05:18 lucid kernel: uhub1: on usbus1 Jan 25 13:05:18 lucid kernel: ugen2.1: at usbus2 Jan 25 13:05:18 lucid kernel: uhub2: on usbus2 Jan 25 13:05:18 lucid kernel: ugen3.1: at usbus3 Jan 25 13:05:18 lucid kernel: uhub3: on usbus3 Jan 25 13:05:18 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 25 13:05:18 lucid kernel: SMP: AP CPU #3 Launched! Jan 25 13:05:18 lucid kernel: SMP: AP CPU #1 Launched! Jan 25 13:05:18 lucid kernel: SMP: AP CPU #2 Launched! Jan 25 13:05:18 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 25 13:05:18 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 25 13:05:18 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 25 13:05:18 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 25 13:05:18 lucid kernel: Root mount waiting for: usbus3 Jan 25 13:05:18 lucid kernel: Root mount waiting for: usbus3 Jan 25 13:05:18 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 25 13:05:18 lucid kernel: Root mount waiting for: usbus3 Jan 25 13:05:18 lucid kernel: ugen3.2: at usbus3 Jan 25 13:05:18 lucid kernel: uhub4: on usbus3 Jan 25 13:05:18 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 25 13:05:18 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 25 13:05:19 lucid kernel: bge0: link state changed to UP Jan 25 13:06:50 lucid shutdown: power-down by toor: Jan 25 13:06:53 lucid syslogd: exiting on signal 15 Jan 25 13:08:44 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 25 13:08:44 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 25 13:08:44 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 25 13:08:44 lucid kernel: The Regents of the University of California. All rights reserved. Jan 25 13:08:44 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 25 13:08:44 lucid kernel: FreeBSD 8.3-RELEASE #2: Fri Jan 25 11:16:50 CST 2013 Jan 25 13:08:44 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 25 13:08:44 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 25 13:08:44 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 25 13:08:44 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 25 13:08:44 lucid kernel: Features=0xbfebfbff Jan 25 13:08:44 lucid kernel: Features2=0xe3bd Jan 25 13:08:44 lucid kernel: AMD Features=0x20100800 Jan 25 13:08:44 lucid kernel: AMD Features2=0x1 Jan 25 13:08:44 lucid kernel: TSC: P-state invariant Jan 25 13:08:44 lucid kernel: real memory = 4294967296 (4096 MB) Jan 25 13:08:44 lucid kernel: avail memory = 4099166208 (3909 MB) Jan 25 13:08:44 lucid kernel: ACPI APIC Table: Jan 25 13:08:44 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 25 13:08:44 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 25 13:08:44 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 25 13:08:44 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 25 13:08:44 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 25 13:08:44 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 25 13:08:44 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 25 13:08:44 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 25 13:08:44 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 25 13:08:44 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 25 13:08:44 lucid kernel: kbd1 at kbdmux0 Jan 25 13:08:44 lucid kernel: acpi0: on motherboard Jan 25 13:08:44 lucid kernel: acpi0: [ITHREAD] Jan 25 13:08:44 lucid kernel: acpi0: Power Button (fixed) Jan 25 13:08:44 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jan 25 13:08:44 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 25 13:08:44 lucid kernel: cpu0: on acpi0 Jan 25 13:08:44 lucid kernel: cpu1: on acpi0 Jan 25 13:08:44 lucid kernel: cpu2: on acpi0 Jan 25 13:08:44 lucid kernel: cpu3: on acpi0 Jan 25 13:08:44 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 25 13:08:44 lucid kernel: pci0: on pcib0 Jan 25 13:08:44 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 25 13:08:44 lucid kernel: pci1: on pcib1 Jan 25 13:08:44 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 25 13:08:44 lucid kernel: pci2: on pcib2 Jan 25 13:08:44 lucid kernel: pcib3: at device 0.0 on pci2 Jan 25 13:08:44 lucid kernel: pci3: on pcib3 Jan 25 13:08:44 lucid kernel: pcib4: at device 2.0 on pci3 Jan 25 13:08:44 lucid kernel: pci4: on pcib4 Jan 25 13:08:44 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 25 13:08:44 lucid kernel: miibus0: on cas0 Jan 25 13:08:44 lucid kernel: nsgphy0: PHY 1 on miibus0 Jan 25 13:08:44 lucid kernel: nsgphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:08:44 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:08:44 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 25 13:08:44 lucid kernel: cas0: [FILTER] Jan 25 13:08:44 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 25 13:08:44 lucid kernel: miibus1: on cas1 Jan 25 13:08:44 lucid kernel: nsgphy1: PHY 1 on miibus1 Jan 25 13:08:44 lucid kernel: nsgphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:08:44 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:08:44 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 25 13:08:44 lucid kernel: cas1: [FILTER] Jan 25 13:08:44 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 25 13:08:44 lucid kernel: miibus2: on cas2 Jan 25 13:08:44 lucid kernel: nsgphy2: PHY 1 on miibus2 Jan 25 13:08:44 lucid kernel: nsgphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:08:44 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:08:44 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 25 13:08:44 lucid kernel: cas2: [FILTER] Jan 25 13:08:44 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 25 13:08:44 lucid kernel: miibus3: on cas3 Jan 25 13:08:44 lucid kernel: nsgphy3: PHY 1 on miibus3 Jan 25 13:08:44 lucid kernel: nsgphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:08:44 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 25 13:08:44 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 25 13:08:44 lucid kernel: cas3: [FILTER] Jan 25 13:08:44 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 25 13:08:44 lucid kernel: pci5: on pcib5 Jan 25 13:08:44 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 25 13:08:44 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 13:08:44 lucid kernel: miibus4: on bge0 Jan 25 13:08:44 lucid kernel: brgphy0: PHY 1 on miibus4 Jan 25 13:08:44 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:08:44 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 25 13:08:44 lucid kernel: bge0: [ITHREAD] Jan 25 13:08:44 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 25 13:08:44 lucid kernel: pci6: on pcib6 Jan 25 13:08:44 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 25 13:08:44 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 25 13:08:44 lucid kernel: miibus5: on bge1 Jan 25 13:08:44 lucid kernel: brgphy1: PHY 1 on miibus5 Jan 25 13:08:44 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 25 13:08:44 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 25 13:08:44 lucid kernel: bge1: [ITHREAD] Jan 25 13:08:44 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 25 13:08:44 lucid kernel: uhci0: [ITHREAD] Jan 25 13:08:44 lucid kernel: usbus0: on uhci0 Jan 25 13:08:44 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 25 13:08:44 lucid kernel: uhci1: [ITHREAD] Jan 25 13:08:44 lucid kernel: usbus1: on uhci1 Jan 25 13:08:44 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 25 13:08:44 lucid kernel: uhci2: [ITHREAD] Jan 25 13:08:44 lucid kernel: usbus2: on uhci2 Jan 25 13:08:44 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 25 13:08:44 lucid kernel: ehci0: [ITHREAD] Jan 25 13:08:44 lucid kernel: usbus3: EHCI version 1.0 Jan 25 13:08:44 lucid kernel: usbus3: on ehci0 Jan 25 13:08:44 lucid kernel: pcib7: at device 30.0 on pci0 Jan 25 13:08:44 lucid kernel: pci7: on pcib7 Jan 25 13:08:44 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 25 13:08:44 lucid kernel: isab0: at device 31.0 on pci0 Jan 25 13:08:44 lucid kernel: isa0: on isab0 Jan 25 13:08:44 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 25 13:08:44 lucid kernel: atapci0: [ITHREAD] Jan 25 13:08:44 lucid kernel: ata2: at channel 0 on atapci0 Jan 25 13:08:44 lucid kernel: ata2: [ITHREAD] Jan 25 13:08:44 lucid kernel: ata3: at channel 1 on atapci0 Jan 25 13:08:44 lucid kernel: ata3: [ITHREAD] Jan 25 13:08:44 lucid kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 25 13:08:44 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jan 25 13:08:44 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 25 13:08:44 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 25 13:08:44 lucid kernel: fdc0: does not respond Jan 25 13:08:44 lucid kernel: device_attach: fdc0 attach returned 6 Jan 25 13:08:44 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 25 13:08:44 lucid kernel: uart0: [FILTER] Jan 25 13:08:44 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 25 13:08:44 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 25 13:08:44 lucid kernel: kbd0 at atkbd0 Jan 25 13:08:44 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 25 13:08:44 lucid kernel: atkbd0: [ITHREAD] Jan 25 13:08:44 lucid kernel: psm0: irq 12 on atkbdc0 Jan 25 13:08:44 lucid kernel: psm0: [GIANT-LOCKED] Jan 25 13:08:44 lucid kernel: psm0: [ITHREAD] Jan 25 13:08:44 lucid kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 25 13:08:44 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 25 13:08:44 lucid kernel: sc0: at flags 0x100 on isa0 Jan 25 13:08:44 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 25 13:08:44 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 25 13:08:44 lucid kernel: ppc0: cannot reserve I/O port range Jan 25 13:08:44 lucid kernel: est0: on cpu0 Jan 25 13:08:44 lucid kernel: p4tcc0: on cpu0 Jan 25 13:08:44 lucid kernel: est1: on cpu1 Jan 25 13:08:44 lucid kernel: p4tcc1: on cpu1 Jan 25 13:08:44 lucid kernel: est2: on cpu2 Jan 25 13:08:44 lucid kernel: p4tcc2: on cpu2 Jan 25 13:08:44 lucid kernel: est3: on cpu3 Jan 25 13:08:44 lucid kernel: p4tcc3: on cpu3 Jan 25 13:08:44 lucid kernel: Timecounters tick every 1.000 msec Jan 25 13:08:44 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 25 13:08:44 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 25 13:08:44 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 25 13:08:44 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 25 13:08:44 lucid kernel: ad4: 76293MB at ata2-master UDMA100 SATA 3Gb/s Jan 25 13:08:44 lucid kernel: ugen0.1: at usbus0 Jan 25 13:08:44 lucid kernel: uhub0: on usbus0 Jan 25 13:08:44 lucid kernel: ugen1.1: at usbus1 Jan 25 13:08:44 lucid kernel: uhub1: on usbus1 Jan 25 13:08:44 lucid kernel: ugen2.1: at usbus2 Jan 25 13:08:44 lucid kernel: uhub2: on usbus2 Jan 25 13:08:44 lucid kernel: ugen3.1: at usbus3 Jan 25 13:08:44 lucid kernel: uhub3: on usbus3 Jan 25 13:08:44 lucid kernel: acd0: DVDROM at ata2-slave UDMA33 SATA 1.5Gb/s Jan 25 13:08:44 lucid kernel: SMP: AP CPU #2 Launched! Jan 25 13:08:44 lucid kernel: SMP: AP CPU #1 Launched! Jan 25 13:08:44 lucid kernel: SMP: AP CPU #3 Launched! Jan 25 13:08:44 lucid kernel: Root mount waiting for: usbus3 usbus2 usbus1 usbus0 Jan 25 13:08:44 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 25 13:08:44 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 25 13:08:44 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 25 13:08:44 lucid kernel: Root mount waiting for: usbus3 Jan 25 13:08:44 lucid kernel: Root mount waiting for: usbus3 Jan 25 13:08:44 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 25 13:08:44 lucid kernel: Root mount waiting for: usbus3 Jan 25 13:08:44 lucid kernel: ugen3.2: at usbus3 Jan 25 13:08:44 lucid kernel: uhub4: on usbus3 Jan 25 13:08:44 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 25 13:08:44 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a Jan 25 13:08:45 lucid kernel: bge0: link state changed to UP --------------020606070600000405070109-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 23:34:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B19615F for ; Fri, 25 Jan 2013 23:34:14 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D7D36BD for ; Fri, 25 Jan 2013 23:34:13 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r0PNY9nv039606; Sat, 26 Jan 2013 00:34:10 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0PNY94G039605; Sat, 26 Jan 2013 00:34:09 +0100 (CET) (envelope-from marius) Date: Sat, 26 Jan 2013 00:34:09 +0100 From: Marius Strobl To: Paul Keusemann Subject: Re: Cas driver fails to load first time after boot. Message-ID: <20130125233409.GZ85306@alchemy.franken.de> References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> <51017FF0.5080001@visi.com> <20130124215017.GS85306@alchemy.franken.de> <5101F264.7030206@visi.com> <20130125161916.GV85306@alchemy.franken.de> <5102D9AB.9010405@visi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5102D9AB.9010405@visi.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jan 2013 23:34:14 -0000 On Fri, Jan 25, 2013 at 01:14:51PM -0600, Paul Keusemann wrote: > > On 01/25/13 10:19, Marius Strobl wrote: > > On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote: > >> On 01/24/13 15:50, Marius Strobl wrote: > >>> On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: > >>>> On 01/24/13 09:09, Marius Strobl wrote: > >>>>> On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I've got a Dell R200 which I'm trying to build into a gateway with a Sun > >>>>>> QGE (501-6738-10). The cas driver fails to load the first time I try to > >>>>>> load it but succeeds the second time. Is this a problem with the card, > >>>>>> the driver, my karma? > >>>>> Wrong phase of the moon, apparently :) > >>>>> The MII setup of these chips is a bit tricky and I'm not sure whether > >>>>> I've hit all code paths during development of the driver. I certainly > >>>>> didn't test with a 501-6738, these have been reported as working before, > >>>>> though. It also doesn't make much sense that attaching the devices > >>>>> succeeds on the second attempt. Could you please use a if_cas.ko built > >>>>> with the attached patch and report the debug output for one of the > >>>>> interfaces in both the working and the non-working case? > >>>> I would love to give you output from the working and non-working case > >>>> but apparently the phase of the moon has changed, I can't get it to fail > >>>> now. The messages output from the working case is attached. > >>>> > >>> Thanks but unfortunately this doesn't make any sense either. In general, > >>> printf()s cause deays which can be relevant. In the locations I've put > >>> them they hardly can make such a difference though. > >>> If you haven't already done so, could you please power off the machine > >>> before doing the test with the patched module? Is the problem still gone > >>> if you revert to the original module? > >> OK, power-cycling makes a difference. The driver fails to attach all of > >> the devices after power-cycling most of the time if not all of the > >> time. The number of devices attached varies, the attached message file > >> fragment is from my last test. Three of the devices were attached on > >> the first load attempt and all four of them on the second attempt. > > Okay, so we now at least have a way to reproduce the problem. > > Unfortunately, it's still unclear what's the exact cause of it. At > > least the problem is not what I suspected and hoped it most likely is. > > Could you please test how things behave after a power-cycle with the > > attached patche (after reverting the previous one). > > The patched driver fails to compile with the following error message: > <...> > > I found the following defintion of nitems in the iwn and usb/wlan drivers: > > #define nitems(_a) (sizeof((_a)) / sizeof((_a)[0])) > > so I added it to if_cas.c and rebuilt without errors. > Sorry, I didn't think of 8.3 not having nitems(), yet. Actually, this part of the patch is orthogonal to your problem and just a change I had in that tree. > This looks like like it fixed the problem. I ran three tests from > power-up to loading the driver and the driver loaded successfully all > three times. I then added if_cas_load="YES" to /boot/loader.conf and > did two more successful reboots from power-up. Great! Thanks a lot for testing! > > Will this driver work on FreeBSD 9.1? > Yes, the patch should also solve the problem in 9.1. I suspect the hang you are seeing there isn't specific to cas(4) but rather a general regression that came in with the VIMAGE changes. Now, if a network device driver fails to attach during boot and tries to clean up by detaching and freeing the interface part at that stage again this causes problems. I already talked to bz@ about this and what I remember from his reply this is an ordering issue that is at least very hard to fix. Marius From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 06:34:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB980FE3 for ; Sat, 26 Jan 2013 06:34:51 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3BC19B for ; Sat, 26 Jan 2013 06:34:51 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id c14so283836ieb.14 for ; Fri, 25 Jan 2013 22:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fUGPL0OEh79sCSoAy5OYuFnUUvoCwgDFqCAxSyYaZaI=; b=TOr1qFNyHBODTIxc7VDuGFQIKFRPrx9RLQDht0vOpKfXTrSUgqqTvHAF3JDEY7HdWB IyykvqZvudVB2KRc+OQ6wU9WkoeycsgcXM/GQmycIPpNUpQq8k87igYKCEkVk58ny45O HyTupHeXPpd5okFMDz8YpZDgzFfcRbWAgJL3Z+07FkIzziB9AZDkqy/h2NfsIG0t6Yqw otP4oBi7UtfBo103KtPEKOI3SSDTmoPJZuhAeh0UaH8SMP/5814p9HCQgrv+f3yVh2+E M8BFXhX+omHeKob/V6XhBbvzHdwRkT5rHjFj8cNjR+oCu3JgZQ9cgrPaYH6Haw1kiJW/ rK4A== X-Received: by 10.50.149.131 with SMTP id ua3mr679580igb.5.1359182091111; Fri, 25 Jan 2013 22:34:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.38.65 with HTTP; Fri, 25 Jan 2013 22:34:29 -0800 (PST) In-Reply-To: References: From: Sara Khanchi Date: Sat, 26 Jan 2013 10:04:29 +0330 Message-ID: Subject: Re: how to completely makes an interface down? To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jan 2013 06:34:51 -0000 I've tried # echo f2 > /dev/led/em0 to make the em0 falshes but it doesn't work! Is there anybody who have the experience of working with led(4)? On Fri, Jan 25, 2013 at 3:49 AM, Warren Block wrote: > On Thu, 24 Jan 2013, h bagade wrote: > > I'm searching for a method or configuration which when I make the >> interface >> down, the led goes off. Currently the led still remains on when I >> shutdowns >> the interface! Is there any way to do this? >> > > em(4) mentions controlling the card LEDs. I have not tried it, though. > From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 07:15:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 596EE327 for ; Sat, 26 Jan 2013 07:15:45 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-ia0-x229.google.com (ia-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id F102E253 for ; Sat, 26 Jan 2013 07:15:44 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so1885774iaf.0 for ; Fri, 25 Jan 2013 23:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=neAY+C7DWDzZUZtreLcQptXp10MP4UwRJR6lD95LH8E=; b=UD9TjwygPoLzulAZXk9z7GNjuhKYhkNmyLbnOofYv6KERXiKJRgRF76W91LBJ1NDGC OZ1Hi11lMrF+YGw8E0gV4bhgWGU/LJvdT0GgyeNz9CfqD+e8PK/Gvtmxb1cn8knNGpLu 1WUcAriI7F+1qeGen5531GxpgeFanS7GcGMKkWXaUmkegihM1k88/1vCRKm1EyX88Vyo bgF5CDQz9X3fXIt7jiu7Q3NPH1+kOZx+LqjZUHGZRMJgP6+uHtsZTtjjn9BiAaPgedyq lohrpAT9HUUO9qbU+kDbzeJ6KGKtn3MpErAEtTo6p4PkMqxiaRxLSwGJLxUht2heFwpV 9zUg== X-Received: by 10.50.1.203 with SMTP id 11mr650665igo.63.1359184544448; Fri, 25 Jan 2013 23:15:44 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.64.38.65 with HTTP; Fri, 25 Jan 2013 23:15:24 -0800 (PST) In-Reply-To: <20130124195056.GB1410@funkthat.com> References: <20130124195056.GB1410@funkthat.com> From: h bagade Date: Sat, 26 Jan 2013 10:45:24 +0330 X-Google-Sender-Auth: 8JOOutbgbo8XAIZ0qVao0ycZFbE Message-ID: Subject: Re: how to completely makes an interface down? To: John-Mark Gurney , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jan 2013 07:15:45 -0000 On Thu, Jan 24, 2013 at 11:20 PM, John-Mark Gurney wrote: > h bagade wrote this message on Thu, Jan 24, 2013 at 16:59 +0330: > > I'm searching for a method or configuration which when I make the > interface > > down, the led goes off. Currently the led still remains on when I > shutdowns > > the interface! Is there any way to do this? > > Not all ethernet drivers disable the PHY when you down the interface... > You can try to use: > ifconfig media none > > to shutdown the PHY, but the em driver on 9.1 doesn't have it, but re > (7.2-R and -current) and msk (-current) seems to have it... > > Also, why do you want the led to go off? Remeber, the led is just an > indication if there is a link established, not what will happen to the > packets that are received... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > I've tried the command on freebsd 8.2 with em card but doesn't work as you mentioned. I need such an operation to disable the connection and yes, not the led but the link establishment itself. Is there a way to have this option on em and igb drivers on freebsd 8.2? From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 07:33:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C6F851D for ; Sat, 26 Jan 2013 07:33:32 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4112AB for ; Sat, 26 Jan 2013 07:33:31 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id fy27so829421vcb.35 for ; Fri, 25 Jan 2013 23:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DzWlTeDGAPU5/I4VMKLi5S/3Qxh9dqGCM/b8u65Vvmg=; b=qZ5m+tyEOcIL9s3nKzY+0z43pqJRCPt5XWZQrxknrIh5RlxN9LH40mV1a2G7bxh+B4 xJf0ddJhCbj+SE1r87Sf5GNcPVQ9n/373YWe8hNuDoi2UAiFZz5zhqoiicUspphnNaN3 d81BfP/UTIxNNrtjX9bobeFqzp7KYMbBXdgcj3v5XE2VB5dbpuVcL1f4WCezoB+JgyZm dv0p0hLccOaOxyhAj/LUagFNOBGF1h4U4n695PXdFyMzn2cmBjQnJ6VRpy2P8mbiWTio Upi10N4OBmuYR+wtd/342W3jxe/PWEnVnUaPBmmNOVHVXrZNq0XewGRvG18jSd1+jt/6 ge0g== MIME-Version: 1.0 X-Received: by 10.221.11.205 with SMTP id pf13mr8600053vcb.70.1359185609800; Fri, 25 Jan 2013 23:33:29 -0800 (PST) Received: by 10.220.25.13 with HTTP; Fri, 25 Jan 2013 23:33:29 -0800 (PST) In-Reply-To: References: <20130124195056.GB1410@funkthat.com> Date: Fri, 25 Jan 2013 23:33:29 -0800 Message-ID: Subject: Re: how to completely makes an interface down? From: Jack Vogel To: h bagade Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jan 2013 07:33:32 -0000 On Fri, Jan 25, 2013 at 11:15 PM, h bagade wrote: > On Thu, Jan 24, 2013 at 11:20 PM, John-Mark Gurney > wrote: > > > h bagade wrote this message on Thu, Jan 24, 2013 at 16:59 +0330: > > > I'm searching for a method or configuration which when I make the > > interface > > > down, the led goes off. Currently the led still remains on when I > > shutdowns > > > the interface! Is there any way to do this? > > > > Not all ethernet drivers disable the PHY when you down the interface... > > You can try to use: > > ifconfig media none > > > > to shutdown the PHY, but the em driver on 9.1 doesn't have it, but re > > (7.2-R and -current) and msk (-current) seems to have it... > > > > Also, why do you want the led to go off? Remeber, the led is just an > > indication if there is a link established, not what will happen to the > > packets that are received... > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > > > I've tried the command on freebsd 8.2 with em card but doesn't work as you > mentioned. > I need such an operation to disable the connection and yes, not the led but > the link establishment itself. Is there a way to have this option on em and > igb drivers on freebsd 8.2? > _______________________________________________ > Since you have not answered the question John-Mark asked, why should there be a command for something that doesn't need to be done :) You want to make sure the connection is "down", unload the driver, that'll make the hardware pretty non-functional :) Jack From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 13:06:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 24169E52 for ; Sat, 26 Jan 2013 13:06:09 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mx1.freebsd.org (Postfix) with ESMTP id D3F2FEB0 for ; Sat, 26 Jan 2013 13:06:08 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wc18so119743obb.36 for ; Sat, 26 Jan 2013 05:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=eoUl6zP7yNpFNPz3jCoWzc0aeuQnOTbRtUe6LIx/UJY=; b=yFjTshyXXj0C+LjANDqqmznp+8zXT70z2IQtey2Ls+2XrnHoAF2T0NC41/XzerDI4t 9EFdfQo/ynZM8jbAUWbUpNtGMiZLDTfM6sxUOooHhI+PvWZmzJhEnrKrsRFxvpbsNR/F zXD19RMoohGcnWtueSTWuIIHaSXgKs8iaHP8I3ZujMHerrXhYjmCLDkolNm54uNSupp2 HhjNpWTavwImZAGKO26v05DkAACmQFOd2w+jv/uhu/k0I+puQoIL31vRQ96A3UXY45HM 5eT9TK8Qwzxjez5HvkzsxHHoPtROZIutk+GPkMSdasCJN5apJYCPalQCYvukBMMcoGmO Y/NQ== X-Received: by 10.60.29.226 with SMTP id n2mr6814837oeh.132.1359205562337; Sat, 26 Jan 2013 05:06:02 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.76.153.3 with HTTP; Sat, 26 Jan 2013 05:05:42 -0800 (PST) In-Reply-To: References: <20130124195056.GB1410@funkthat.com> From: h bagade Date: Sat, 26 Jan 2013 16:35:42 +0330 X-Google-Sender-Auth: Syc76uwhE_09_5-IQcjUhnuFFVI Message-ID: Subject: Re: how to completely makes an interface down? To: John-Mark Gurney Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jan 2013 13:06:09 -0000 On Sat, Jan 26, 2013 at 11:03 AM, Jack Vogel wrote: > > > On Fri, Jan 25, 2013 at 11:15 PM, h bagade wrote: > >> On Thu, Jan 24, 2013 at 11:20 PM, John-Mark Gurney >> wrote: >> >> > h bagade wrote this message on Thu, Jan 24, 2013 at 16:59 +0330: >> > > I'm searching for a method or configuration which when I make the >> > interface >> > > down, the led goes off. Currently the led still remains on when I >> > shutdowns >> > > the interface! Is there any way to do this? >> > >> > Not all ethernet drivers disable the PHY when you down the interface... >> > You can try to use: >> > ifconfig media none >> > >> > to shutdown the PHY, but the em driver on 9.1 doesn't have it, but re >> > (7.2-R and -current) and msk (-current) seems to have it... >> > >> > Also, why do you want the led to go off? Remeber, the led is just an >> > indication if there is a link established, not what will happen to the >> > packets that are received... >> > >> > -- >> > John-Mark Gurney Voice: +1 415 225 5579 >> > >> > "All that I will do, has been done, All that I have, has not." >> > >> >> I've tried the command on freebsd 8.2 with em card but doesn't work as you >> mentioned. >> I need such an operation to disable the connection and yes, not the led >> but >> the link establishment itself. Is there a way to have this option on em >> and >> igb drivers on freebsd 8.2? >> _______________________________________________ >> > > > Since you have not answered the question John-Mark asked, why should there > be > a command for something that doesn't need to be done :) > > You want to make sure the connection is "down", unload the driver, that'll > make > the hardware pretty non-functional :) > > Jack > > I've found a patch which is going to do what I really want: http://lists.freebsd.org/pipermail/freebsd-net/2010-December/027196.html but when I apply it on my freebsd 8.2 with em cards, nothing happens! not even sysctl "dev.em.X.down_disables_link", which is supposed to be added after applying patch, exists! what wrong with what I've done? From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 14:53:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05BE4522 for ; Sat, 26 Jan 2013 14:53:15 +0000 (UTC) (envelope-from prvs=731db969c=daved@tamu.edu) Received: from os-mail-5.cis.tamu.edu (os-mail-5.tamu.edu [165.91.22.20]) by mx1.freebsd.org (Postfix) with ESMTP id BCB4325C for ; Sat, 26 Jan 2013 14:53:14 +0000 (UTC) X-TAMU-Auth-ID: daved X-TAMU-SenderIP: 71.113.227.163 X-HAT: SG None, P $RELAY, L incoming_auth X-SRBS: None X-EXTLoop1: 71.113.227.163 X-IronPort-AV: E=Sophos;i="4.84,544,1355119200"; d="p7s'?scan'208";a="32830979" Subject: Re: how to completely makes an interface down? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_E87EC58A-5BFE-4A28-9A12-27188693868F"; protocol="application/pkcs7-signature"; micalg=sha1 From: Dave Duchscher In-Reply-To: Date: Sat, 26 Jan 2013 08:52:05 -0600 Message-Id: <6D4FA861-037E-48EA-BE87-70808FB28D82@tamu.edu> References: <20130124195056.GB1410@funkthat.com> To: h bagade X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jan 2013 14:53:15 -0000 --Apple-Mail=_E87EC58A-5BFE-4A28-9A12-27188693868F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jan 26, 2013, at 7:05 AM, h bagade wrote: > I've found a patch which is going to do what I really want: > http://lists.freebsd.org/pipermail/freebsd-net/2010-December/027196.html > > but when I apply it on my freebsd 8.2 with em cards, nothing happens! not > even sysctl "dev.em.X.down_disables_link", which is supposed to be added > after applying patch, exists! what wrong with what I've done? Not sure. I would make sure that your new kernel is the kernel that is being used. We use a different kernel configuration file so that a simple uname command tells us that the right kernel is installed. We use that patch here with 8.3 and it works as advertised. I do wish there was a way to drop the link of the port without kernel mods. Understandably with the out of band management protocols, the internal interfaces really like to keep link alive so you can connect to the system's management console, do wake on lan, etc. -- DaveD --Apple-Mail=_E87EC58A-5BFE-4A28-9A12-27188693868F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2DCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIE6jCCA9KgAwIBAgIQJ5o/CcavxpGv2uo3G++mbzANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTAyMTEwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMGQxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlJbnRlcm5ldDIxETAPBgNVBAsTCEluQ29tbW9uMS4wLAYDVQQDEyVJ bkNvbW1vbiBTdGFuZGFyZCBBc3N1cmFuY2UgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA0+AVAnv5doLp/pGW8/AeIWi1DWEwvgmXZt0dI6f7H4Z4OuaXasfBpH+JTbOe WbM4Cx85ImsCKBK/KZbRNfSVKmwGmBwZZFymfkVuIGuRuHQPPFPIgxlrEaPHLIUFHofUy6AIBQYu Zok9eKeDk1S32Bfq0+59ZtQ03onKGf03ytCD3lFo2Fr1dOvdggJa+iDOqs9AK9PInoXpgTOb1vFP kUXZjTMpHF0HmoXp/8kSskwMQirtMPTX3Jm1zwuA6nnepyNin7XplqLWshpF0NgTHZJ59ISBPbYV j+5vLBrG7F2sk48LR006OwnV3gYiOhGVkG9Oex9yLieRMz6IV8K/CQIDAQABo4IBSzCCAUcwHwYD VR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOjXvZaq3dAI76Eznl5ZmDwS t5uRMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0g ADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYB BQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AA7ttuA4nzpoogHB8ITlJu78gdLXjMkbJEOgybGF5p/k4CrRRN7yoHCtiBgoSJYTEkdJ+co5o1fX zVOFTbf3Lx/Zq1N6aQdOyEK/4uxeO3v0PrKkSZaRFnv5T2peQnIx0dNDoTkFiT7LtdHpPhHGhHXO Nb/1Leiiq/WkAU5wHCZlqxbDvTLmKRAva2qySNZwBgb1KOhUfswQxWmuEekF6zs4wWJa0B4Y6VxN U/j1KuHdkjWE+iWPH8cjWRr4oiWlVmLi3jis1N8zV2IBOCpRKjtMuUewcenJIcFhjtJjrbpJKyIA rDY1EEgOXsHsHbHbYl6TA+rlUEjvUashivtgxcIwggVYMIIEQKADAgECAhEAkBk77adN1ykDnrpD b/1TqDANBgkqhkiG9w0BAQUFADBkMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSW50ZXJuZXQyMREw DwYDVQQLEwhJbkNvbW1vbjEuMCwGA1UEAxMlSW5Db21tb24gU3RhbmRhcmQgQXNzdXJhbmNlIENs aWVudCBDQTAeFw0xMTA3MjIwMDAwMDBaFw0xNjA3MjEyMzU5NTlaMHgxETAPBgNVBAoTCFRBTVUt RU5DMR0wGwYDVQQJFBRUZXhhcyBBJk0gVW5pdmVyc2l0eTELMAkGA1UEBhMCVVMxGDAWBgNVBAMT D0RhdmlkIER1Y2hzY2hlcjEdMBsGCSqGSIb3DQEJARYOZGF2ZWRAdGFtdS5lZHUwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCE2CTSrO/PJr+XWeE/zAwd5QkIBbNg77hAImBmFsq9iiIi JY9zAbrXA0XHbUKh/tR1nTcJgg9B6vr/gbIAakO2seJVXwYOFrmSlZDF+7uI+8ugQNAstDzH98DI JJlH2qGMKFkukgCvtyga6wcaafxxXdktNoPlP4JHaUv3FfO9d7pAYORxH9wsvTX/kdbKXjMSSF9C K2zeGBWXobi9HalRHXjeVGyvtigk/TkF6Y6XwPzuqvMuAUR2F0gGTepUaMppfHVSFCdo0L3myu9b JJY0VvjsQLgbgtIeYTGw9FHpAvUD+NvBUm2IP09NVMvPyCGkfX3ROTiTgO82yfCmBSDRAgMBAAGj ggHvMIIB6zAfBgNVHSMEGDAWgBTo172Wqt3QCO+hM55eWZg8ErebkTAdBgNVHQ4EFgQUMrJ3IU0V oDB9a0RtN20wvYam0eUwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYI KwYBBQUHAwQGCCsGAQUFBwMCMGoGA1UdIARjMGEwXwYNKwYBBAGuIwEEAwMAATBOMEwGCCsGAQUF BwIBFkBodHRwczovL3d3dy5pbmNvbW1vbi5vcmcvY2VydC9yZXBvc2l0b3J5L2Nwc19zdGFuZGFy ZF9jbGllbnQucGRmME4GA1UdHwRHMEUwQ6BBoD+GPWh0dHA6Ly9jcmwuaW5jb21tb24ub3JnL0lu Q29tbW9uU3RhbmRhcmRBc3N1cmFuY2VDbGllbnRDQS5jcmwwgYAGCCsGAQUFBwEBBHQwcjBKBggr BgEFBQcwAoY+aHR0cDovL2NlcnQuaW5jb21tb24ub3JnL0luQ29tbW9uU3RhbmRhcmRBc3N1cmFu Y2VDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmluY29tbW9uLm9yZzAtBgNV HREEJjAkgQ5kYXZlZEB0YW11LmVkdYESZGF2ZWRAbmV0LnRhbXUuZWR1MA0GCSqGSIb3DQEBBQUA A4IBAQAi5uRmXDzXPU/OmCpkk5Qpf0sLynUMVrOMi8UXyVJO2ZzSL5jtPW2brDKAZGPjvn8waZ2W fbxQ9+uRBcAAdYy02YAa06Y3FPIA2TXqI1gGJoZvNsQED9ltJ4MWXb/XKsY/GKNcPh5dZcAMWrvE xWN2/FomudJMOTY+FVwgMr2DMWckTWzsr70wW1Hf1OEBI0x4bd8vHfd4rthl2BJ8JL1mUqxTFW+v Y8X47m7IXZA0wnCUPUJOGoDz5izC5mGnwyDwOK5QqAzJyZba3P1h0a1OoCXb4Dsq+N4xrGUQi0Ld v3s+xybTPnW4gmeea4PM8XyJ4tyBKBMBIe9hP4Bp3Zs0MYIDGTCCAxUCAQEweTBkMQswCQYDVQQG EwJVUzESMBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNvbW1vbjEuMCwGA1UEAxMlSW5D b21tb24gU3RhbmRhcmQgQXNzdXJhbmNlIENsaWVudCBDQQIRAJAZO+2nTdcpA566Q2/9U6gwCQYF Kw4DAhoFAKCCAXUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw MTI2MTQ1MjA1WjAjBgkqhkiG9w0BCQQxFgQUIF0w2bJ3nDR32gs2pGtMf6NgY6wwgYgGCSsGAQQB gjcQBDF7MHkwZDELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUludGVybmV0MjERMA8GA1UECxMISW5D b21tb24xLjAsBgNVBAMTJUluQ29tbW9uIFN0YW5kYXJkIEFzc3VyYW5jZSBDbGllbnQgQ0ECEQCQ GTvtp03XKQOeukNv/VOoMIGKBgsqhkiG9w0BCRACCzF7oHkwZDELMAkGA1UEBhMCVVMxEjAQBgNV BAoTCUludGVybmV0MjERMA8GA1UECxMISW5Db21tb24xLjAsBgNVBAMTJUluQ29tbW9uIFN0YW5k YXJkIEFzc3VyYW5jZSBDbGllbnQgQ0ECEQCQGTvtp03XKQOeukNv/VOoMA0GCSqGSIb3DQEBAQUA BIIBAD2JttuO2ETU6Cvls+qwRJ/jXifFl5+sCrFYDpT6NZUXqRKwE51rSQ5r6XZPPkcwlrEaIH5N GhGI+RNCVipJ2lsZVQjPExz8TJEXvwMs5pQFVS4G0jQ6zapQ/10znCsE5AysjzXTztbRenhg/NTy qF5LDvtKSHnxiB0AVE8zm/rc6gU85FK/XtetRBv/cpXqdNvbjc+9t8rPvRRffp6OKXvkkZ5Na27h yhuMPb8az5wDHVwR6U7OKXHFuDxrIHqQnREPr/MsrwewBCgD12d7uvv11X+rz9ZB3kqdjeKthP/6 P1LkHvobEHhghfDAx3fiFbB7ncgyfHMvEaYLjnLut8QAAAAAAAA= --Apple-Mail=_E87EC58A-5BFE-4A28-9A12-27188693868F--