From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 01:12:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F07479C0 for ; Sun, 12 Oct 2014 01:12:35 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id D32C2F42 for ; Sun, 12 Oct 2014 01:12:35 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5A6613ADE4 for ; Sat, 11 Oct 2014 18:05:07 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: A couple of trivial BIND (dynamic update) questions Date: Sat, 11 Oct 2014 18:05:07 -0700 Message-ID: <22652.1413075907@server1.tristatelogic.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 01:12:36 -0000 I've just been messing around with the nsupdate program, which, as I'm sure you all know, is part of the BIND 9 package. For now, I'm just using in in "local" mode, i.e. invoking it with the -l option. I did managed to get it to perform a dynamic update, but I encountered a cople of slight, and perhaps FreeBSD-specific oddities along the way. I want to ask about those. Firstly, various online sources, and the nsupdate man page itself say that the name server should create a file called: /var/run/named/session.key when the server is started up with at least one "update-policy local;" clause within one of the zone {} clauses within the named.conf file. On my FreeBSD system howver, this file was instead created over here: /var/named/var/run/named/session.key So, um, how come? The default location wasn't good enough? I saw that the pid file, which typically (on other systems) would have appeared within the /var/run/named directory also, was a symlink pointing over to /var/named/var/run/named/pid, so in order to make the nsupdate utility work I just followed suit and created a symlink called /var/run/named/session.key and pointed it over to the actual key file, /var/named/var/run/named/session.key. I hope that was the Right Thing To Do. If not, somebody please tell me. The more troublesome problem however is that at first, my dynamic updates were failing with SERVFAIL errors, and I couldn't figure out why until I looked at the tail of /var/log/messages. Apparently, BIND wants to write a ".jnl" (journal?) file in the same directory as the one that contains the actual zone file for the zone being dynamically updated. On FreeBSD, and for my master zones, that would be the directory /var/named/etc/namedb/master. Unfortunately, that directory is owned by root/wheel (with permissions set to 0755) which rendered it unwritable by named, which is apparently run under the user ID "bind" (and, I am guessing, with the GID set to the "bind" group). As soon as I changed the permissions on /var/named/etc/namedb/master to 0777, sure enough my dynamic updates started to work. But of course, I _do not_ want to leave it like that. I just set it that way for a quicky temporary test. So, um, what is the Right Solution here? Do I need to re-jigger the permissions on /var/named/etc/namedb/master to 0775 and then add user-ID "bind" to the wheel group in /etc/groups? Something tells me that I can't have been the first person to have ever encountered the above two problems. And it appears like they may perhaps both be FreeBSD-specific, which is why I'm asking about them here, rather than on the bind-users mailing list. From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 05:55:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86569D60 for ; Sun, 12 Oct 2014 05:55:27 +0000 (UTC) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43F299AD for ; Sun, 12 Oct 2014 05:55:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=Ji1x2PvyrreYoQl+ZVCGe3d/gAWVgAEvdRv9Zm15A3c=; b=UwPXueYZkg+7Nn7mELgaYSaLwLbsQ4YID31KUNjbjEu7l6jGMyOIjHWiF9ccnp4c7Aj207T42TTbgCi0k3musdeq+f21YzwTlZOEbVBDP+3Dhm5CTWnmr9kmWBsts86sHl77mRJfGksTUf4kwffMBigd8UAK7dTT5r4BChts5qM=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1XdC7d-000AVz-L9 for freebsd-net@freebsd.org; Sun, 12 Oct 2014 08:55:13 +0300 Date: Sun, 12 Oct 2014 08:55:13 +0300 From: wishmaster Subject: Re[2]: Enabling VIMAGE by default for FreeBSD 11? To: "Alexander V. Chernikov" X-Mailer: mail.ukr.net 5.0 Message-Id: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> In-Reply-To: References: MIME-Version: 1.0 Received: from artemrts@ukr.net by frv34.fwdcdn.com; Sun, 12 Oct 2014 08:55:13 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: Craig Rodrigues , freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 05:55:27 -0000 --- Original message --- From: "Alexander V. Chernikov" Date: 11 October 2014, 23:20:39 > > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > > > Hi, > > > > What action items are left to enable VIMAGE by default for FreeBSD 11? > Are there any tests results showing performance implications on different network-related workloads? https://wiki.freebsd.org/NetworkingPerformanceProject Last item: "Add VNET to any of the above as well." > > > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > > > -- > > Craig > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 06:15:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8652D362; Sun, 12 Oct 2014 06:15:15 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A49C9B37; Sun, 12 Oct 2014 06:15:14 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so6547221wgg.8 for ; Sat, 11 Oct 2014 23:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yuM3YANeOSYfANJH9xy9ZMXAVOHEfnV+xZntt4/8xyA=; b=Fdb6VLhq9d/vNyrV2n+l7gC01f7f3JJMHwkD8GiwficlCbOVY51MIDBaOtWxjaoc43 yPCrxLKOs1e2oBMJ+nTkOYJcz8smlkUEBlksnq01aVSagxpSSw93zAKhni4mBjN9EJuU CifGZcWKqoBU0zn7qDzXBDnPWa50k1TbL/ZFgVPQnz7+2GDc01V8rbVROItEcqAwQcnv VYq4BkjF/JLqr3F1S8KqqI+QfmEltTUTzgH30YKyQXFRyIPokugDarkTzdCaswDqUGYJ 1Xqp0owMZI0ABuuTVFJ2AklDGP7r48LzzyYF55NhWb01vCrzFF9s0M05eYwqZVK4+Smf CKjA== MIME-Version: 1.0 X-Received: by 10.194.62.166 with SMTP id z6mr14171300wjr.44.1413094512897; Sat, 11 Oct 2014 23:15:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 11 Oct 2014 23:15:12 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Oct 2014 23:15:12 -0700 X-Google-Sender-Auth: 98kzrz934N203Ay7Eqdltu6Ktzw Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Adrian Chadd To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 06:15:15 -0000 ... is it enabled by default on pcbsd? -a From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 06:53:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9286D978; Sun, 12 Oct 2014 06:53:53 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ADC5E37; Sun, 12 Oct 2014 06:53:52 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ge10so5252634lab.10 for ; Sat, 11 Oct 2014 23:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MaKELVZA7nA5UTWJn7ltTITgODFi/8iVV3LxQWtvkYI=; b=xnwewU0W8QfS4R57M50NwCg/aFtLC5lll8oNTTr48KF+Rq498X7mEe6e82UkB6nNnZ Mo0MmuHB2LzmTq+gJ1oobdz8AWLdOW6b+U8I2qz9DfGx4t7Qtw9z0U1rMMc/PRZ/7ed9 MBJGTWbsDHXq20aV9qCOJ6L7mWths4qiBya3ZW62xZI8Y+BL3bL2tQHb2RLATQiNrpyL N2X6j+MzdznEOoK9pwd4VWXxOQE6aOnYVstW1pIJx67ZMoil04uVpsm/zhiIG6WNCjSu r2a/yETjgkcILKtQqDPsnxfBT2q0M6VsM5rYC6chEp68o+ihJbzgNrEYfGO/FiYB5PSI HSdQ== MIME-Version: 1.0 X-Received: by 10.152.87.101 with SMTP id w5mr631202laz.88.1413096830547; Sat, 11 Oct 2014 23:53:50 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Sat, 11 Oct 2014 23:53:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Oct 2014 23:53:50 -0700 X-Google-Sender-Auth: gFSB8faSPS9sNfJLU8Y-m9ZTnLM Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 06:53:53 -0000 On Sat, Oct 11, 2014 at 11:15 PM, Adrian Chadd wrote: > ... is it enabled by default on pcbsd? > > > -a > It was enabled in PCBSD here: https://github.com/trueos/trueos/commit/3108bbe003bc38339fbd4a26542b184b2ccb271a -- Craig From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 08:56:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 694F6E17 for ; Sun, 12 Oct 2014 08:56:58 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 08E64AC2 for ; Sun, 12 Oct 2014 08:56:57 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id s9C8ujAE051076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 12 Oct 2014 09:56:45 +0100 (BST) (envelope-from matthew@FreeBSD.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk s9C8ujAE051076 Authentication-Results: smtp.infracaninophile.co.uk/s9C8ujAE051076; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral Message-ID: <543A4244.1000401@FreeBSD.org> Date: Sun, 12 Oct 2014 09:56:36 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: A couple of trivial BIND (dynamic update) questions References: <22652.1413075907@server1.tristatelogic.com> In-Reply-To: <22652.1413075907@server1.tristatelogic.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2DdWvssD6r1pTeEiQ72Ce8wfGtL1Fhg1u" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 08:56:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2DdWvssD6r1pTeEiQ72Ce8wfGtL1Fhg1u Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/10/2014 02:05, Ronald F. Guilmette wrote: > Firstly, various online sources, and the nsupdate man page itself > say that the name server should create a file called: >=20 > /var/run/named/session.key >=20 > when the server is started up with at least one "update-policy local;" > clause within one of the zone {} clauses within the named.conf file. > On my FreeBSD system howver, this file was instead created over here: >=20 > /var/named/var/run/named/session.key >=20 > So, um, how come? The default location wasn't good enough? You're running chrooted to /var/named. All paths will have /var/named tacked onto the front. > The more troublesome problem however is that at first, my dynamic > updates were failing with SERVFAIL errors, and I couldn't figure > out why until I looked at the tail of /var/log/messages. Apparently, > BIND wants to write a ".jnl" (journal?) file in the same directory as > the one that contains the actual zone file for the zone being dynamical= ly > updated. On FreeBSD, and for my master zones, that would be the > directory /var/named/etc/namedb/master. Unfortunately, that directory > is owned by root/wheel (with permissions set to 0755) which rendered > it unwritable by named, which is apparently run under the user ID > "bind" (and, I am guessing, with the GID set to the "bind" group). >=20 > As soon as I changed the permissions on /var/named/etc/namedb/master > to 0777, sure enough my dynamic updates started to work. But of > course, I _do not_ want to leave it like that. I just set it that > way for a quicky temporary test. >=20 > So, um, what is the Right Solution here? Do I need to re-jigger > the permissions on /var/named/etc/namedb/master to 0775 and then > add user-ID "bind" to the wheel group in /etc/groups? /var/named/etc/namedb/master is for zones where the data is managed by means other than dynamic update. If you're using dynamic update, then create a new directory /ver/named/etc/namedb/dynamic and make it mode 755 but owned by the bind UID and GID (similar to the slave directory). Use that for storing the data for all your dynamic update zones. Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --2DdWvssD6r1pTeEiQ72Ce8wfGtL1Fhg1u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iQJ8BAEBCgBmBQJUOkJMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATiWAP/RnStEasE7av8WZu+ZnSqN2a zSngv3h8df/vA6lUH25u7vNQSU1fxOPdJk0H3OzJ/SWjfP9rNa26fCBDI28xppfr Ele4LZZKZsnxugDuhx0elzv/NC+nypxx1oJWUBlLuWwPdet/exLsp0qrQ5980h1h h4yyDkR4wnO2obuHBBUR7VXSyusIt49CKCIXf2tdRGY6HFnXwz/h7kLGD6JJEtTP FSdg3vLALqKUjRSsxjJMBqrzADHfmLMy+GXFiv+SX6mE0eHiHB7fw+mpW1Uhvpka oarf8R5ARMThJptcC/rhbHVLThvLC/AG/8V9Mvu6qhqZ8pc7WJkHvzZkkcm1nSkr BZdEbJZ7fk7q9WwpaQELjf3zpLAc3L2xpZpJ4GdOYczJLnWjN/sn9odCrjPaLDDc 3Exqge22kloyRQgnChiXbnfrP922Ni2VDXlP0NfYOpfChaFUCev5N0P2K0zX8v5L x2jb5yhqAkmW3kzzW9xkl2aUA8PQmWcGoi6Otuz3Zsy/RWfU5KsfChfq1qHZwZig iyHboQ4AmPp9M6OIbYKEn4tLv3MRBznH5Hu4dxFd+TdCCrh6gxMYLqnYGI7yFnDz Noln9JLLQ86y/4l2kuVngstahUE3guZYtcZ8dAvPunPVOvIhiYylUeTV/9gEVlMS QLclncqC822KrP2AhQSF =pHpL -----END PGP SIGNATURE----- --2DdWvssD6r1pTeEiQ72Ce8wfGtL1Fhg1u-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 09:15:21 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE5B84B6 for ; Sun, 12 Oct 2014 09:15:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5788D0E for ; Sun, 12 Oct 2014 09:15:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9C9FL1K056977 for ; Sun, 12 Oct 2014 09:15:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Sun, 12 Oct 2014 09:15:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 09:15:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 11:28:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 078E059E for ; Sun, 12 Oct 2014 11:28:10 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0370A89 for ; Sun, 12 Oct 2014 11:28:09 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id q107so5670396qgd.4 for ; Sun, 12 Oct 2014 04:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TnN3BnHnRkLGTFQqNir8XHX2DGLdyA6NjVUbPodbl3Q=; b=gvoya1CiWxbOFXxAWcu9P6gmJLJo39aCaVkHLEZ/bQpmGVSxtTOjAg8HwSgfOoWdt9 fe/JHlUc7PIBN6XvqKO6TxpFM35pSveOfgsWB+alVMBFSRv6Mha8DWQlJNBdt5rHqO9m otpBDEKNXhnonsnS5FrNCHuNZl2pimasFVH6Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TnN3BnHnRkLGTFQqNir8XHX2DGLdyA6NjVUbPodbl3Q=; b=FGMvsivKaQDUrnWS2ag1dVAQtC5D2ozwTlFInozm17Ej7rLTzBxMcwcAI5L4KfVtid +uiIbyq+0M158bMb8FN5wGI5yKiBAsNiBnIYgJUB49HHkPfmFL8eo246MrzaMfElDg+h bgc4xIvLj3V9P68kivIIqij9MWwQQnDFJuF8lhl5pfPv36v3DfRXXAHNGh5dFTDAQ50Q hFy9xP5/l9/o8BzNjopQiekqfRK6m7g+fdgRvSYCtd4AN6vita5un47msdkp7370b2Rm R0N35GiGwG1Gb4FpJtxuTbjOTV0ztX/zCJYopRXhguTSOEnsfsT9F1ZT2w1+fMYNEYSZ Cdww== X-Gm-Message-State: ALoCoQmZ7PlU4KlhrI5uB1RQ1l9qp3vzCerAmoq5Ov22b0BMyn0dGscDN+LMWzS21pNYWdMX2IHL X-Received: by 10.224.115.14 with SMTP id g14mr29783488qaq.23.1413113288661; Sun, 12 Oct 2014 04:28:08 -0700 (PDT) Received: from [100.100.27.104] (149.sub-70-194-161.myvzw.com. [70.194.161.149]) by mx.google.com with ESMTPSA id y9sm9841604qaf.15.2014.10.12.04.28.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 04:28:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Jason Hellenthal X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Sun, 12 Oct 2014 06:28:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> References: To: Adrian Chadd Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 11:28:10 -0000 Should also add here that for those using PF as a firewall that VIMAGE enabl= ed kernels don't play to well together.... Unless you like looking at cores a= ll day. --=20 Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal@DataIX.net JJH48-ARIN On Oct 12, 2014, at 01:15, Adrian Chadd wrote: ... is it enabled by default on pcbsd? -a _______________________________________________ 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 Sun Oct 12 13:35:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 543CFCAE; Sun, 12 Oct 2014 13:35:47 +0000 (UTC) Received: from mail.iXsystems.com (mail.ixsystems.com [12.229.62.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F4CC958; Sun, 12 Oct 2014 13:35:46 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 63CAB816A0; Sun, 12 Oct 2014 06:35:45 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 40967-06; Sun, 12 Oct 2014 06:35:45 -0700 (PDT) Received: from [192.168.0.247] (75-130-56-30.static.kgpt.tn.charter.com [75.130.56.30]) by mail.iXsystems.com (Postfix) with ESMTPA id 8C95F81699; Sun, 12 Oct 2014 06:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1413120945; bh=1XN4/kK7/ZrYtHGJ6m+BhegSaXVbttH5VZrBeMWlr1I=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=DtfMztocFUPz5sBIH+7Inf0NCxDYrTOVV6YHLFsjCLbqz3dn4Kob9aCZQwLPpQZPt cn5iYKQq6pTB3D8WxxxrHGgSg9Hpir/BrpHCsvLY0hqEfPquHVDS7VtDX00p2FE5r7 qBH7ABYY69ZAIpkmopmU/OEdnFqv8WGN1H0zIsgI= In-Reply-To: References: User-Agent: Blue for Android MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Kris Moore Date: Sun, 12 Oct 2014 09:35:41 -0400 To: Adrian Chadd Message-ID: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 13:35:47 -0000 It was for a while in 9.2, but we removed it from 10.0 and later due to stability issues we kept getting reports about. Haven't tried it since then, dont know if those issues are fixed. On Oct 12, 2014, 2:15 AM, at 2:15 AM, Adrian Chadd wrote: >... is it enabled by default on pcbsd? > > >-a >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 16:26:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 679B74E6; Sun, 12 Oct 2014 16:26:13 +0000 (UTC) Received: from mail1.yamagi.org (yugo.yamagi.org [212.48.122.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29143A84; Sun, 12 Oct 2014 16:26:12 +0000 (UTC) Received: from p579a689b.dip0.t-ipconnect.de ([87.154.104.155] helo=happy.home.yamagi.org) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XdLy0-000CFL-VD; Sun, 12 Oct 2014 18:26:03 +0200 Date: Sun, 12 Oct 2014 18:25:51 +0200 From: Yamagi Burmeister To: rodrigc@FreeBSD.org Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-Id: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> In-Reply-To: References: X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 16:26:13 -0000 Hello, it's been a while since I tested VIMAGE, but at the last time somewhere in 10-CURRENT some UMA memory leaks were left when destroying vnets. They weren't showstoppers for most workloads, but pretty anoying... Have those been fixed? Regards, Yamagi On Sat, 11 Oct 2014 10:58:13 -0700 Craig Rodrigues wrote: > Hi, > > What action items are left to enable VIMAGE by default for FreeBSD 11? > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > -- > Craig > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 16:39:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CADC3884; Sun, 12 Oct 2014 16:39:18 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7E1B9A; Sun, 12 Oct 2014 16:39:18 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C60AA25D3871; Sun, 12 Oct 2014 16:39:14 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BE68EC77059; Sun, 12 Oct 2014 16:39:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id TV1S1_2Nz-Kn; Sun, 12 Oct 2014 16:39:12 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:9939:1d52:4fd1:db6c] (unknown [IPv6:fde9:577b:c1a9:4410:9939:1d52:4fd1:db6c]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0B5A5C77058; Sun, 12 Oct 2014 16:39:10 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: "Bjoern A. Zeeb" In-Reply-To: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> Date: Sun, 12 Oct 2014 16:38:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> To: Yamagi Burmeister X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , freebsd-virtualization@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 16:39:18 -0000 On 12 Oct 2014, at 16:25 , Yamagi Burmeister wrote: > Hello, > it's been a while since I tested VIMAGE, but at the last time = somewhere > in 10-CURRENT some UMA memory leaks were left when destroying vnets.=20= > They weren't showstoppers for most workloads, but pretty anoying... > Have those been fixed? No, an old perforce branch of mine had all but the last TCP ones fixed. = The code is still there. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 17:59:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4852F5E for ; Sun, 12 Oct 2014 17:59:57 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 9AFD1374 for ; Sun, 12 Oct 2014 17:59:56 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 1168B3AF26 for ; Sun, 12 Oct 2014 10:59:56 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: Re: A couple of trivial BIND (dynamic update) questions In-Reply-To: <543A4244.1000401@FreeBSD.org> Date: Sun, 12 Oct 2014 10:59:56 -0700 Message-ID: <28907.1413136796@server1.tristatelogic.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 17:59:57 -0000 In message <543A4244.1000401@FreeBSD.org>, Matthew Seaman wrote: >On 12/10/2014 02:05, Ronald F. Guilmette wrote: >... >> /var/named/var/run/named/session.key >> >> So, um, how come? The default location wasn't good enough? > >You're running chrooted to /var/named. All paths will have /var/named >tacked onto the front. Ah! OK. It makes sense now. >> So, um, what is the Right Solution here? Do I need to re-jigger >> the permissions on /var/named/etc/namedb/master to 0775 and then >> add user-ID "bind" to the wheel group in /etc/groups? > >/var/named/etc/namedb/master is for zones where the data is managed by >means other than dynamic update. > >If you're using dynamic update, then create a new directory >/ver/named/etc/namedb/dynamic and make it mode 755 but owned by the bind >UID and GID (similar to the slave directory). Use that for storing the >data for all your dynamic update zones. OK, thanks much. I will certainly do that. (In fact, that is so obviously the correct solution that I am a bit embarassed that I didn't just think of it myself.) From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 18:19:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F45C60B; Sun, 12 Oct 2014 18:19:07 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F73078F; Sun, 12 Oct 2014 18:19:06 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so5386377lbv.38 for ; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Iz/g02UBahml6Zro5OlZ6eWinLs6mAACAv5SZ7kExBY=; b=ML552fr5KeFuR9cxoFOkSvbMBm3yj19sGmTuuqDfCyv5bvG7bOmyB1HXuE6TdFNpao 59bKm7sXRkJ1q3R1ggrFwu6ammcYUHTKPST6u2waYgCmttJ8KjOtFQIPaDkR6XU6p+F4 eamGMoZF8cTvkQtLnBhEwBiUC1ozQxGH+KS7XVp4ncFdmkfyXuAGalbgN05jEvBr/Q2N +JAONub+9k8nRmhqKY/szJPGh8hVWBbeKmLFW7Uwbdw75AuOE0yzGHoihYkEpaRJK5wT 5kcSMIReq7KvbbK4FIOI8w6hJZgimT22PBu6PNtL9Pf3sn5vyuJtDhYR6p4SFoOy0FPG D8ww== MIME-Version: 1.0 X-Received: by 10.112.134.101 with SMTP id pj5mr18677030lbb.47.1413137944439; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) Received: by 10.112.131.66 with HTTP; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) In-Reply-To: <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> Date: Sun, 12 Oct 2014 11:19:04 -0700 X-Google-Sender-Auth: R9wUGkoMF7wsEm2gDKpiDuYGbBo Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 18:19:07 -0000 On Oct 12, 2014 9:39 AM, "Bjoern A. Zeeb" wrote: > > No, an old perforce branch of mine had all but the last TCP ones fixed. The code is still there. > Can you provide a pointer to your Perforce branch? -- Craig From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 20:05:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D2C5906; Sun, 12 Oct 2014 20:05:09 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468FA14B; Sun, 12 Oct 2014 20:05:08 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so7286100wgh.23 for ; Sun, 12 Oct 2014 13:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=KjDtT6A8FufmmTeZbeopSewaOm9stQITH9bnmaobN8s=; b=EdLYUkSOaTSQBI2mfcd+rrn1nKqlkar7ed4J2Plw3XcRyc2Gl5lGeMQtcDza0tb02Y +7+V48GCHkc3pYmAZT7WR9D3S+oI40TpDBwRuxiD2MseL+jGPAKpbdBS/JsGitttsTcG 635zbIhqb6zBASHhciBQP+zJHiB3hE6Ufv1k5qriAPntQ2Q1q233cijzZPAjMbDPLyyI hrWYRdmoTKS9dzpPqZKkDgwpumb8BAjm53rEJepOxSugUIJufjQSppDAaAfU3ixCyvNf aOcDabm0l5EaGr37p2dT79423MLM69j0JaOrf7owu/NEjCnj7UUnBgB4qWyfIMjrOPSo /DVw== X-Received: by 10.180.77.169 with SMTP id t9mr3322115wiw.58.1413144305553; Sun, 12 Oct 2014 13:05:05 -0700 (PDT) Received: from ?IPv6:2001:470:1f15:59b:4940:ce63:f97a:a6d7? ([2001:470:1f15:59b:4940:ce63:f97a:a6d7]) by mx.google.com with ESMTPSA id l10sm9857466wif.20.2014.10.12.13.05.04 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 13:05:05 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> References: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Miguel Clara Date: Sun, 12 Oct 2014 20:44:29 +0100 To: Jason Hellenthal , Adrian Chadd Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 20:05:09 -0000 For me pf is working pretty nice on the host, it's only on the jails that it can creates all kinds of trouble , but on the host I've not seen issues so far, in both freebsd 9 and 10. Have not tested in current though. On 12 October 2014 12:28:06 WEST, Jason Hellenthal wrote: >Should also add here that for those using PF as a firewall that VIMAGE >enabled kernels don't play to well together.... Unless you like looking >at cores all day. > >-- > Jason Hellenthal > Mobile: +1 (616) 953-0176 > jhellenthal@DataIX.net > JJH48-ARIN > >On Oct 12, 2014, at 01:15, Adrian Chadd wrote: > >... is it enabled by default on pcbsd? > > >-a >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >_______________________________________________ >freebsd-virtualization@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >To unsubscribe, send any mail to >"freebsd-virtualization-unsubscribe@freebsd.org" -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 20:07:27 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87E86ABC for ; Sun, 12 Oct 2014 20:07:27 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EDD0173 for ; Sun, 12 Oct 2014 20:07:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9CK7Rek084805 for ; Sun, 12 Oct 2014 20:07:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Sun, 12 Oct 2014 20:07:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 20:07:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian@freebsd.org --- Comment #2 from Adrian Chadd --- Hi! Does he/Isilon have a patch to fix/address this? -adrian -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 20:15:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7F2EBFB; Sun, 12 Oct 2014 20:15:48 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEB8C236; Sun, 12 Oct 2014 20:15:47 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so5491287lbv.10 for ; Sun, 12 Oct 2014 13:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Fp1ks4Gl+ffEc/EOZiNyxds9uUWHnfiPJ9kCo8T9by0=; b=RCwjUKAIDjSPCu/qi4CdFX6VpW5fo9CTX42Ic3yS+S3g/qAxbvoz0+nVrSIxA6Ey8G aqbyczGTNRWlVt+ijZchpkppuvQNmSR5Z7CsS45Qr+r7m2dWAhWxVtRySV2l/UZqmys3 al+zWTeYBEI9f0qga8JBHveM7cNXIDsh5EbDgMUZ0hTcSXNMteW2/m9mK76q6naDuKiS WyVM13oYzupaxbmbYw2vhoJpHlYPzG8IgfbANTOhmPqW7DiHMDlpmBLT8mvF4WXUc3XY ImXyCpLB1Hz+1VMwnNpyp24nIB+v3PN2BiMfj6sUwyFOSpgqBZ/l/1rG7SkluxSFQDPj JMYA== MIME-Version: 1.0 X-Received: by 10.152.3.167 with SMTP id d7mr19410521lad.17.1413144945940; Sun, 12 Oct 2014 13:15:45 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Sun, 12 Oct 2014 13:15:45 -0700 (PDT) In-Reply-To: <543A7504.5090700@freebsd.org> References: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> <543A7504.5090700@freebsd.org> Date: Sun, 12 Oct 2014 13:15:45 -0700 X-Google-Sender-Auth: SKTMp6GZE4Dqu8ggKLvWR4bFRxY Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 20:15:49 -0000 On Sun, Oct 12, 2014 at 5:33 AM, Allan Jude wrote: > On 2014-10-12 07:28, Jason Hellenthal wrote: > > Should also add here that for those using PF as a firewall that VIMAGE > enabled kernels don't play to well together.... Unless you like looking at > cores all day. > > > > There have been patches to address this. I know Martin mm@freebsd.org > had something, I was talking to him about it at AsiaBSDCon this spring. > > pf patches for vnet have been committed to this branch: https://svnweb.freebsd.org/base/projects/pf/head/ Some of the patches have been merged to HEAD such as this: https://svnweb.freebsd.org/base?view=revision&revision=264689 -- Craig From owner-freebsd-net@FreeBSD.ORG Sun Oct 12 21:00:28 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 679DFB96 for ; Sun, 12 Oct 2014 21:00:28 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C6CA902 for ; Sun, 12 Oct 2014 21:00:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9CL0SnJ033264 for ; Sun, 12 Oct 2014 21:00:28 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201410122100.s9CL0SnJ033264@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 12 Oct 2014 21:00:28 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Oct 2014 21:00:28 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ----------------+-----------+------------------------------------------------- Needs MFC | 183659 | [tcp] TCP stack lock contention with short-live 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 01:08:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29CE1DAA; Mon, 13 Oct 2014 01:08:02 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D1ECD1AA; Mon, 13 Oct 2014 01:08:01 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8C44825D3A92; Mon, 13 Oct 2014 01:07:58 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A6085C7706D; Mon, 13 Oct 2014 01:07:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 4CNMJSQqcO71; Mon, 13 Oct 2014 01:07:56 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:5130:92a9:98c8:e33] (unknown [IPv6:fde9:577b:c1a9:4410:5130:92a9:98c8:e33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 52AF8C77057; Mon, 13 Oct 2014 01:07:55 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: "Bjoern A. Zeeb" In-Reply-To: Date: Mon, 13 Oct 2014 01:07:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 01:08:02 -0000 On 12 Oct 2014, at 18:19 , Craig Rodrigues wrote: > On Oct 12, 2014 9:39 AM, "Bjoern A. Zeeb" = > wrote: >>=20 >> No, an old perforce branch of mine had all but the last TCP ones = fixed. > The code is still there. >>=20 >=20 > Can you provide a pointer to your Perforce branch? //depot/user/bz/vimage/src/=85 Also if people are seriously thinking about virtualising pf we need to = import the openbsd/apple pf fix from a few years ago because otherwise = people in virtualised stacks with a /dev/pf can do ugly things. I = think it=92s been this one: = http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 /bz =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 04:21:19 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2D92198 for ; Mon, 13 Oct 2014 04:21:19 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 899227FB for ; Mon, 13 Oct 2014 04:21:19 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9D4LJHX056703 for ; Mon, 13 Oct 2014 04:21:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Mon, 13 Oct 2014 04:21:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 04:21:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #3 from Garrett Cooper --- (In reply to Adrian Chadd from comment #2) > Hi! > > Does he/Isilon have a patch to fix/address this? We don't yet. This was a recently discovered issue on a driver that isn't available in HEAD yet... -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 05:35:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72812E0B; Mon, 13 Oct 2014 05:35:31 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F99FE6D; Mon, 13 Oct 2014 05:35:30 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-237-201.lns20.per1.internode.on.net [121.45.237.201]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9D5ZFMZ023499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 12 Oct 2014 22:35:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <543B648D.6020403@freebsd.org> Date: Mon, 13 Oct 2014 13:35:09 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: wishmaster , "Alexander V. Chernikov" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> In-Reply-To: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 05:35:31 -0000 On 10/12/14, 1:55 PM, wishmaster wrote: > > > --- Original message --- > From: "Alexander V. Chernikov" > Date: 11 October 2014, 23:20:39 > > > >> On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: >> >>> Hi, >>> >>> What action items are left to enable VIMAGE by default for FreeBSD 11? >> Are there any tests results showing performance implications on different network-related workloads? the last time we teste things vnet made things faster. if you spread 100 sessions over N vnets and had 100 sessions on one system, then there are 1/N as many locking collisions as each vnet is its own locking domain. Julian From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 08:00:11 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B217A66 for ; Mon, 13 Oct 2014 08:00:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F177E15 for ; Mon, 13 Oct 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9D80BIJ037927 for ; Mon, 13 Oct 2014 08:00:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201410130800.s9D80BIJ037927@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 13 Oct 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 08:00:11 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 183659: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-net@FreeBSD.org Status: Needs MFC Resolution: Summary: [tcp] TCP stack lock contention with short-lived connections From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 08:35:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E57F3439; Mon, 13 Oct 2014 08:35:47 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B73623E; Mon, 13 Oct 2014 08:35:47 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9D8ZZZT041611; Mon, 13 Oct 2014 10:35:35 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id ABB9F3037; Mon, 13 Oct 2014 10:35:34 +0200 (CEST) Message-ID: <543B8ED5.6040206@omnilan.de> Date: Mon, 13 Oct 2014 10:35:33 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Julian Elischer Subject: Re: Deleting IPv4 iface-routes from extra FIBs References: <53569ABA.60007@omnilan.de> <535771F3.4070007@freebsd.org> In-Reply-To: <535771F3.4070007@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6230EC5227E68E506CAFA445" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Mon, 13 Oct 2014 10:35:35 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: "freebsd-net@freebsd.org" , FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 08:35:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6230EC5227E68E506CAFA445 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Julian Elischer's Nachricht vom 23.04.2014 09:55 (localti= me): > On 4/23/14, 4:38 AM, Nikolay Denev wrote: >> On Tue, Apr 22, 2014 at 5:37 PM, Harald Schmalzbauer >> wrote: >>> Hello, >>> >>> here, http://svnweb.freebsd.org/base?view=3Drevision&revision=3D24889= 5 >>> interface route protection was added (so the following problem arose >>> with 9.2). >>> >>> Unfortunately, in my case, I must be able to delete these routes; >>> not in >>> the default FIB, but in jail's fibs, because: >>> =C2=B7 Host is multihomed with multiple nics in different subnets. >>> =C2=B7 Jail's IP (no vnet) is from a different subnet than host's >>> default-router subnet =E2=80=93 jail has no ip in the range of host's= >>> default-router!!! >>> =C2=B7 FIB used by jail contains valid default-router. >>> >>> Problem: >>> If iface-routes exist in jail's FIB, answer-packets take the >>> iface-shortcut, not trespassing the router (default gateway); hence >>> 3way-handshake never finishes and firewall terminates (half-opened) T= CP >>> sessions. >>> >>> Workarround: >>> =C2=B7 Abuse packet filter doing some kind of route-to=E2=80=A6 >>> =C2=B7 Revert r248895, to be able to delete v4-iface-routes (inet6-ro= utes >>> can >>> be deleted without any hack) >>> >>> Desired solution: >>> =C2=B7 Allow deletion of v4-iface-routes if FIB!=3D0. >>> >>> Unfortunately my C skills don't allow me to implement this myself :-(= >>> I can't even follow the code, I guess that was originally considered,= >>> but possibly doesn't work bacause of a simple bug?!? I took the lazy >>> way >>> and simply reverted r248895 instead of trying to understand >>> rtrequest1_fib(). I wish I had the time to learn=E2=80=A6 >>> >>> Thanks for any help, >>> >>> -Harry >>> >> Hi, >> >> As it was suggested before as immediate workaround you can set >> net.add_addr_allfibs=3D0 so that the interface routes are added only i= n >> the default FIB. > > yes, we made two behaviours. > Add interface routes to all active FIBS or only add them to the first > fib and let the user populate other fibs as needed. > It appears you want the second behaviour, so I suggest you use that > option and set up all your routes manually. Hello, last time I had the iface-route problem, I just reverted r248895 (for 9.3). There was inconsitent behaviour with v6 iface routes and net.add_addr_allfibs=3D0. Now I checked with 10.1 ans it seems net.add_addr_allfibs=3D0 doesn't wor= k any more: netstat -f inet -nr Routing tables Internet: Destination Gateway Flags Netif Expire default 172.21.32.1 UGS egn 127.0.0.1 link#2 UH lo0 172.21.32.0/19 link#1 U egn 172.21.35.1 link#1 UHS lo0 netstat -F 1 -f inet -nr Routing tables (fib: 1) Internet: Destination Gateway Flags Netif Expire 127.0.0.1 link#2 UH lo0 172.21.32.0/19 link#1 U egn 'sysctl net.add_addr_allfibs' net.add_addr_allfibs: 0 Shouldn't the routing table for fib1 stay empty? Can't remember the result when I testet that with 9.3 :-( Thanks, -Harry --------------enig6230EC5227E68E506CAFA445 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ7jtYACgkQLDqVQ9VXb8gJHQCfQKViwDAMUH8tgn4hfo0G93k3 mhUAoKjj8OX/wKIwfyQmvAwCWEfJdOja =zn/y -----END PGP SIGNATURE----- --------------enig6230EC5227E68E506CAFA445-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 08:43:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38DDB600; Mon, 13 Oct 2014 08:43:58 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBC9F33B; Mon, 13 Oct 2014 08:43:57 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XdXEm-000EED-6I; Mon, 13 Oct 2014 08:28:00 +0400 Message-ID: <543B9075.2000102@FreeBSD.org> Date: Mon, 13 Oct 2014 12:42:29 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Harald Schmalzbauer , Julian Elischer Subject: Re: Deleting IPv4 iface-routes from extra FIBs References: <53569ABA.60007@omnilan.de> <535771F3.4070007@freebsd.org> <543B8ED5.6040206@omnilan.de> In-Reply-To: <543B8ED5.6040206@omnilan.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 08:43:58 -0000 On 13.10.2014 12:35, Harald Schmalzbauer wrote: > Bezüglich Julian Elischer's Nachricht vom 23.04.2014 09:55 (localtime): >> On 4/23/14, 4:38 AM, Nikolay Denev wrote: >>> On Tue, Apr 22, 2014 at 5:37 PM, Harald Schmalzbauer >>> wrote: >>>> Hello, >>>> >>>> here, http://svnweb.freebsd.org/base?view=revision&revision=248895 >>>> interface route protection was added (so the following problem arose >>>> with 9.2). >>>> >>>> Unfortunately, in my case, I must be able to delete these routes; >>>> not in >>>> the default FIB, but in jail's fibs, because: >>>> · Host is multihomed with multiple nics in different subnets. >>>> · Jail's IP (no vnet) is from a different subnet than host's >>>> default-router subnet – jail has no ip in the range of host's >>>> default-router!!! >>>> · FIB used by jail contains valid default-router. >>>> >>>> Problem: >>>> If iface-routes exist in jail's FIB, answer-packets take the >>>> iface-shortcut, not trespassing the router (default gateway); hence >>>> 3way-handshake never finishes and firewall terminates (half-opened) TCP >>>> sessions. >>>> >>>> Workarround: >>>> · Abuse packet filter doing some kind of route-to… >>>> · Revert r248895, to be able to delete v4-iface-routes (inet6-routes >>>> can >>>> be deleted without any hack) >>>> >>>> Desired solution: >>>> · Allow deletion of v4-iface-routes if FIB!=0. >>>> >>>> Unfortunately my C skills don't allow me to implement this myself :-( >>>> I can't even follow the code, I guess that was originally considered, >>>> but possibly doesn't work bacause of a simple bug?!? I took the lazy >>>> way >>>> and simply reverted r248895 instead of trying to understand >>>> rtrequest1_fib(). I wish I had the time to learn… >>>> >>>> Thanks for any help, >>>> >>>> -Harry >>>> >>> Hi, >>> >>> As it was suggested before as immediate workaround you can set >>> net.add_addr_allfibs=0 so that the interface routes are added only in >>> the default FIB. >> yes, we made two behaviours. >> Add interface routes to all active FIBS or only add them to the first >> fib and let the user populate other fibs as needed. >> It appears you want the second behaviour, so I suggest you use that >> option and set up all your routes manually. > Hello, > > last time I had the iface-route problem, I just reverted r248895 (for > 9.3). There was inconsitent behaviour with v6 iface routes and > net.add_addr_allfibs=0. > Now I checked with 10.1 ans it seems net.add_addr_allfibs=0 doesn't work > any more: > netstat -f inet -nr > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 172.21.32.1 UGS egn > 127.0.0.1 link#2 UH lo0 > 172.21.32.0/19 link#1 U egn > 172.21.35.1 link#1 UHS lo0 > > netstat -F 1 -f inet -nr > Routing tables (fib: 1) > > Internet: > Destination Gateway Flags Netif Expire > 127.0.0.1 link#2 UH lo0 > 172.21.32.0/19 link#1 U egn > > 'sysctl net.add_addr_allfibs' > net.add_addr_allfibs: 0 Are you sure net.add_addr_allfibs was applied before interface address added? Can you check recent 10-STABLE code? It might have more fixes related to allfibs. > > Shouldn't the routing table for fib1 stay empty? Can't remember the > result when I testet that with 9.3 :-( Yes, it should. We're slowly moving to this direction > > Thanks, > > -Harry > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 09:16:39 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DD38C11; Mon, 13 Oct 2014 09:16:39 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D120D84E; Mon, 13 Oct 2014 09:16:38 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9D9GaZp042023; Mon, 13 Oct 2014 11:16:36 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 24CB63046; Mon, 13 Oct 2014 11:16:36 +0200 (CEST) Message-ID: <543B9873.3040605@omnilan.de> Date: Mon, 13 Oct 2014 11:16:35 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: Deleting IPv4 iface-routes from extra FIBs References: <53569ABA.60007@omnilan.de> <535771F3.4070007@freebsd.org> <543B8ED5.6040206@omnilan.de> <543B9075.2000102@FreeBSD.org> In-Reply-To: <543B9075.2000102@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDFEC5242399331AD23FB8855" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 13 Oct 2014 11:16:36 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: "freebsd-net@freebsd.org" , FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 09:16:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDFEC5242399331AD23FB8855 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Alexander V. Chernikov's Nachricht vom 13.10.2014 10:42 (localtime): > On 13.10.2014 12:35, Harald Schmalzbauer wrote: >> Bez=C3=BCglich Julian Elischer's Nachricht vom 23.04.2014 09:55 >> (localtime): =2E.. >>> yes, we made two behaviours. >>> Add interface routes to all active FIBS or only add them to the first= >>> fib and let the user populate other fibs as needed. >>> It appears you want the second behaviour, so I suggest you use that >>> option and set up all your routes manually. >> Hello, >> >> last time I had the iface-route problem, I just reverted r248895 (for >> 9.3). There was inconsitent behaviour with v6 iface routes and >> net.add_addr_allfibs=3D0. >> Now I checked with 10.1 ans it seems net.add_addr_allfibs=3D0 doesn't = work >> any more: >> netstat -f inet -nr >> Routing tables >> >> Internet: >> Destination Gateway Flags Netif Expire >> default 172.21.32.1 UGS egn >> 127.0.0.1 link#2 UH lo0 >> 172.21.32.0/19 link#1 U egn >> 172.21.35.1 link#1 UHS lo0 >> >> netstat -F 1 -f inet -nr >> Routing tables (fib: 1) >> >> Internet: >> Destination Gateway Flags Netif Expire >> 127.0.0.1 link#2 UH lo0 >> 172.21.32.0/19 link#1 U egn >> >> 'sysctl net.add_addr_allfibs' >> net.add_addr_allfibs: 0 > Are you sure net.add_addr_allfibs was applied before interface address > added? Sorry, I messed it up. Forgot that on my production systems (where I tested), / is read-only with /etc as union-mount. Adding net.add_addr_allfibs=3D0 to the correct sysctl.conf made the inet routing table stay empty. But unfortunately not the inet6 routing table :-( So I still need to delete iface routes for my jail setups, hence need to revert r248895. For those having similar problems, here's how I currently solve my jail setups: jail.conf: jail { allow.set_hostname; =2E.. exec.fib =3D 1; exec.prestart =3D "/bin/sh /.JAIL$name/etc/rc.jails_fibprepare -f= 1 -i inop"; interface =3D inop; =2E.. =E2=80=93=E2=80=93=E2=80=93 rc.jails_fibprepare : #!/bin/sh # format FIB for JAIL usage (remove all but own interface routes) # Does only work if on FreeBSD-9.2 if r248895 was reverted, since deleting iface routes is prohibited by default. # TODO: extend jail (8) and jail.conf for routing parameters and delete this ugly hack! # TODO: Do it the other way, not deleleting, but adding if "sysctl net.add_addr_allfibs=3D0". # Last edited: 20140605.0 _help(){ echo "Usage: rc.jails_fibprepare -f FIBNUM -i IFACENAME [-4 defaultrouterIPv4] [-6 defaultrouterIPv6] [-h]" if [ "X$1" !=3D "X" ]; then if [ "$1" =3D "-h" ]; then echo "Prepare routing tabel of specified FIB for jail usage." echo "This removes all iface routes not belonging to own interface"= echo "and sets default route(s) if specified or automatically, if" echo "iface used is the same where fib 0 has set the default gatewa= y." echo " -f: FIBNUM is the number of the fib whose routing table will be altered." echo " -i: IFACENAME is the name of the interface we have our IP on." echo " -4: IP (v4) of the defaultrouter." echo " -6: IP (v6) of the defaultrouter." echo " -h: This help" echo else echo "ERROR:" echo " $1" echo exit 1 fi else echo "Type \"rc.jails_fibprepare -h\" for more help." exit 1 fi exit 0 } _find_unwanted_destinations(){ # first, generate complete destination lists (separate for v4+v6) dest4list=3D`setfib ${fibnum} netstat -f inet -nr | grep -E '^[[:print:]]+(%[[:alnum:].]+|[[:digit:]])[[:blank:]]+U[[:print:]]+$' | cut -s -d ' ' -f 1` dest6list=3D`setfib ${fibnum} netstat -f inet6 -nr | grep -E '^[[:print:]]+(%[[:alnum:].]+|[[:digit:]])[[:blank:]]+U[[:print:]]+$' | cut -s -d ' ' -f 1` # Create lists with wanted destinations (separate for v4+v6) for ifn in ${ifnames}; do link=3D`setfib ${fibnum} netstat -I ${ifn} | sed -n -E 's/^[[:print:]]+<[lL](ink#[[:digit:]]{1,2})>[[:print:]]+$/l\1/p'` dest4wanted=3D"`setfib ${fibnum} netstat -f inet -nr | grep -E '^[^[:blank:]]+[[:blank:]]+'"${link}"'[[:blank:]]+.*$' | cut -s -d ' ' -f 1` ${dest4wanted:-}" dest6wanted=3D"`setfib ${fibnum} netstat -f inet6 -nr | grep -E '^[^[:blank:]]+[[:blank:]]+'"${link}"'[[:blank:]]+.*$' | cut -s -d ' ' -f 1` ${dest6wanted:-}" done # remove wanted destinations from v4 list for dest in ${dest4wanted}; do dest4list=3D"`echo ${dest4list} | sed -E 's,'"${dest}"' *,,'`" done # remove wanted destinations from v6 list for dest in ${dest6wanted}; do dest6list=3D"`echo ${dest6list} | sed -E 's,'"${dest}"' *,,'`" done } _clean_fib(){ _find_unwanted_destinations || return 1 # extract default gateway IPv4 if it's on one of our interfaces and none is set already for ifn in ${ifnames}; do if [ "X${dv4gw}" =3D "X" ]; then dv4gw=3D"`netstat -f inet -nr | sed -n -E 's/^default[[:print:]]+[[:blank:]]([^[:blank:]]+[.:][^[:blank:]]+)[[:prin= t:]]+[^[:blank:]]+[[:blank:]]+'"${ifn}"'$/\1/p'`" fi done # extract default gateway IPv6 if it's on one of our interfaces and none is set already for ifn in ${ifnames}; do if [ "X${dv6gw}" =3D "X" ]; then dv6gw=3D"`netstat -f inet6 -nr | sed -n -E 's/^default[[:print:]]+[[:blank:]]([^[:blank:]]+[.:][^[:blank:]]+)[[:prin= t:]]+[^[:blank:]]+[[:blank:]]+'"${ifn}"'$/\1/p'`" fi done # remove v4 destinations for dest in ${dest4list}; do route -q delete -net -inet ${dest} -fib ${fibnum} || return 1 done # remove v6 destinations for dest in ${dest6list}; do route -q delete -net -inet6 ${dest} -fib ${fibnum} || return 1 done # Set v4 defaultrouter if [ "X${dv4gw}" !=3D "X" ]; then route -q add -net -inet default ${dv4gw} -fib ${fibnum} || return 1 fi # Set v6 defaultrouter if [ "X${dv6gw}" !=3D "X" ]; then route -q add -net -inet6 default ${dv6gw} -fib ${fibnum} || return 1 fi } if [ $# -gt 8 ]; then _help "Too many arguments!" else if [ $# -lt 4 ]; then _help "At least \"-f FIBUM\" and \"-i IFACENAME\" is required!" else if ! expr $# % 2 >/dev/null; then while [ $# -gt 0 ]; do case "$1" in -f) if ! setfib ${2} true; then _help "FIBNUM too high!" else fibnum=3D$2 fi ;; -i) if ! ifconfig ${2} >/dev/null 2>&1; then _help "No such interface: \"$2\"" else ifnames=3D"$2 ${ifnames:-}" fi ;; -4) dv4gw=3D"$2";; -6) dv6gw=3D"$2";; -h|*) _help "$1" esac shift 2 done _clean_fib && exit 0 else _help "Wrong number of arguments ($#), only even numbers can be valid!" fi fi fi exit 1 =E2=80=93=E2=80=93=E2=80=93 r248895-revert patch against 10.1: --- src/sys/net/if.c 2014-10-06 12:56:27.000000000 +0200 +++ src/sys/net/if.c 2014-10-13 10:47:51.000000000 +0200 @@ -1371,8 +1371,7 @@ return (0); =20 err =3D rtrequest_fib(RTM_DELETE, rt_key(rt), rt->rt_gateway, - rt_mask(rt), - rt->rt_flags|RTF_RNH_LOCKED|RTF_PINNED, + rt_mask(rt), rt->rt_flags|RTF_RNH_LOCKED, (struct rtentry **) NULL, rt->rt_fibnum); if (err) { log(LOG_WARNING, "if_rtdel: error %d\n", err); --- src/sys/net/route.c 2014-10-06 12:56:27.000000000 +0200 +++ src/sys/net/route.c 2014-10-13 10:47:51.000000000 +0200 @@ -1210,14 +1210,6 @@ error =3D 0; } #endif - if ((flags & RTF_PINNED) =3D=3D 0) { - /* Check if target route can be deleted */ - rt =3D (struct rtentry *)rnh->rnh_lookup(dst, - netmask, rnh); - if ((rt !=3D NULL) && (rt->rt_flags & RTF_PINNED)) - senderr(EADDRINUSE); - } - /* * Remove the item from the tree and return it. * Complain if it is not there and do no more processing. @@ -1521,7 +1513,6 @@ int didwork =3D 0; int a_failure =3D 0; static struct sockaddr_dl null_sdl =3D {sizeof(null_sdl), AF_LINK}; - struct radix_node_head *rnh; =20 if (flags & RTF_HOST) { dst =3D ifa->ifa_dstaddr; @@ -1580,6 +1571,7 @@ */ for ( fibnum =3D startfib; fibnum <=3D endfib; fibnum++) { if (cmd =3D=3D RTM_DELETE) { + struct radix_node_head *rnh; struct radix_node *rn; /* * Look up an rtentry that is in the routing tree and @@ -1626,8 +1618,7 @@ */ bzero((caddr_t)&info, sizeof(info)); info.rti_ifa =3D ifa; - info.rti_flags =3D flags | - (ifa->ifa_flags & ~IFA_RTSELF) | RTF_PINNED; + info.rti_flags =3D flags | (ifa->ifa_flags & ~IFA_RTSELF); info.rti_info[RTAX_DST] =3D dst; /* * doing this for compatibility reasons @@ -1639,33 +1630,6 @@ info.rti_info[RTAX_GATEWAY] =3D ifa->ifa_addr; info.rti_info[RTAX_NETMASK] =3D netmask; error =3D rtrequest1_fib(cmd, &info, &rt, fibnum); - - if ((error =3D=3D EEXIST) && (cmd =3D=3D RTM_ADD)) { - /* - * Interface route addition failed. - * Atomically delete current prefix generating - * RTM_DELETE message, and retry adding - * interface prefix. - */ - rnh =3D rt_tables_get_rnh(fibnum, dst->sa_family); - RADIX_NODE_HEAD_LOCK(rnh); - - /* Delete old prefix */ - info.rti_ifa =3D NULL; - info.rti_flags =3D RTF_RNH_LOCKED; - - error =3D rtrequest1_fib(RTM_DELETE, &info, NULL, fibnum); - if (error =3D=3D 0) { - info.rti_ifa =3D ifa; - info.rti_flags =3D flags | RTF_RNH_LOCKED | - (ifa->ifa_flags & ~IFA_RTSELF) | RTF_PINNED; - error =3D rtrequest1_fib(cmd, &info, &rt, fibnum); - } - - RADIX_NODE_HEAD_UNLOCK(rnh); - } - - if (error =3D=3D 0 && rt !=3D NULL) { /* * notify any listening routing agents of the change --- src/sys/net/route.h 2014-10-06 12:56:27.000000000 +0200 +++ src/sys/net/route.h 2014-10-13 10:43:59.000000000 +0200 @@ -148,7 +148,7 @@ /* 0x20000 unused, was RTF_WASCLONED */ #define RTF_PROTO3 0x40000 /* protocol specific routing flag *= / /* 0x80000 unused */ -#define RTF_PINNED 0x100000 /* route is immutable */ +#define RTF_PINNED 0x100000 /* future use (route is immutable, startintg with r248895) */ #define RTF_LOCAL 0x200000 /* route represents a local address= */ #define RTF_BROADCAST 0x400000 /* route represents a bcast address */ #define RTF_MULTICAST 0x800000 /* route represents a mcast address */ --------------enigDFEC5242399331AD23FB8855 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ7mHMACgkQLDqVQ9VXb8gOegCfXiznyHCmkyRMosVBO5uIUlzB 2yQAoKWEezWtKKwXzoBveGim6cb/E6y8 =10vS -----END PGP SIGNATURE----- --------------enigDFEC5242399331AD23FB8855-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 09:22:46 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADAA1EB1; Mon, 13 Oct 2014 09:22:46 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DD9D925; Mon, 13 Oct 2014 09:22:46 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XdXqK-000FRi-Bp; Mon, 13 Oct 2014 09:06:48 +0400 Message-ID: <543B998D.2020003@FreeBSD.org> Date: Mon, 13 Oct 2014 13:21:17 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: Deleting IPv4 iface-routes from extra FIBs References: <53569ABA.60007@omnilan.de> <535771F3.4070007@freebsd.org> <543B8ED5.6040206@omnilan.de> <543B9075.2000102@FreeBSD.org> <543B9873.3040605@omnilan.de> In-Reply-To: <543B9873.3040605@omnilan.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 09:22:46 -0000 On 13.10.2014 13:16, Harald Schmalzbauer wrote: > Bezüglich Alexander V. Chernikov's Nachricht vom 13.10.2014 10:42 > (localtime): >> On 13.10.2014 12:35, Harald Schmalzbauer wrote: >>> Bezüglich Julian Elischer's Nachricht vom 23.04.2014 09:55 >>> (localtime): > ... >>>> yes, we made two behaviours. >>>> Add interface routes to all active FIBS or only add them to the first >>>> fib and let the user populate other fibs as needed. >>>> It appears you want the second behaviour, so I suggest you use that >>>> option and set up all your routes manually. >>> Hello, >>> >>> last time I had the iface-route problem, I just reverted r248895 (for >>> 9.3). There was inconsitent behaviour with v6 iface routes and >>> net.add_addr_allfibs=0. >>> Now I checked with 10.1 ans it seems net.add_addr_allfibs=0 doesn't work >>> any more: >>> netstat -f inet -nr >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Netif Expire >>> default 172.21.32.1 UGS egn >>> 127.0.0.1 link#2 UH lo0 >>> 172.21.32.0/19 link#1 U egn >>> 172.21.35.1 link#1 UHS lo0 >>> >>> netstat -F 1 -f inet -nr >>> Routing tables (fib: 1) >>> >>> Internet: >>> Destination Gateway Flags Netif Expire >>> 127.0.0.1 link#2 UH lo0 >>> 172.21.32.0/19 link#1 U egn >>> >>> 'sysctl net.add_addr_allfibs' >>> net.add_addr_allfibs: 0 >> Are you sure net.add_addr_allfibs was applied before interface address >> added? > Sorry, I messed it up. Forgot that on my production systems (where I > tested), / is read-only with /etc as union-mount. > Adding net.add_addr_allfibs=0 to the correct sysctl.conf made the inet > routing table stay empty. > > But unfortunately not the inet6 routing table :-( > So I still need to delete iface routes for my jail setups, hence need to > revert r248895. Hm. If the problem happens with inet6 routes only, why do you need to revert r248895 ? > > Strage thing is that 'rcorder' shows nothing iface related before > mountcritlocal, where I resource /etc/rc.d, so the > 'net.add_addr_allfibs' in my union-mounted sysctl.conf should work!?! > But that's my homemade problem ;-) /> > > For those having similar problems, here's how I currently solve my jail > setups: > > jail.conf: > > jail { > allow.set_hostname; > ... > exec.fib = 1; > exec.prestart = "/bin/sh /.JAIL$name/etc/rc.jails_fibprepare -f > 1 -i inop"; > interface = inop; > ... > > ––– > rc.jails_fibprepare : > > #!/bin/sh > # format FIB for JAIL usage (remove all but own interface routes) > # Does only work if on FreeBSD-9.2 if r248895 was reverted, since > deleting iface routes is prohibited by default. > # TODO: extend jail (8) and jail.conf for routing parameters and delete > this ugly hack! > # TODO: Do it the other way, not deleleting, but adding if "sysctl > net.add_addr_allfibs=0". > # Last edited: 20140605.0 > > > _help(){ > echo "Usage: rc.jails_fibprepare -f FIBNUM -i IFACENAME [-4 > defaultrouterIPv4] [-6 defaultrouterIPv6] [-h]" > if [ "X$1" != "X" ]; then > if [ "$1" = "-h" ]; then > echo "Prepare routing tabel of specified FIB for jail usage." > echo "This removes all iface routes not belonging to own interface" > echo "and sets default route(s) if specified or automatically, if" > echo "iface used is the same where fib 0 has set the default gateway." > echo " -f: FIBNUM is the number of the fib whose routing > table will be altered." > echo " -i: IFACENAME is the name of the interface we have > our IP on." > echo " -4: IP (v4) of the defaultrouter." > echo " -6: IP (v6) of the defaultrouter." > echo " -h: This help" > echo > else > echo "ERROR:" > echo " $1" > echo > exit 1 > fi > else > echo "Type \"rc.jails_fibprepare -h\" for more help." > exit 1 > fi > exit 0 > } > > _find_unwanted_destinations(){ > # first, generate complete destination lists (separate for v4+v6) > dest4list=`setfib ${fibnum} netstat -f inet -nr | grep -E > '^[[:print:]]+(%[[:alnum:].]+|[[:digit:]])[[:blank:]]+U[[:print:]]+$' | > cut -s -d ' ' -f 1` > dest6list=`setfib ${fibnum} netstat -f inet6 -nr | grep -E > '^[[:print:]]+(%[[:alnum:].]+|[[:digit:]])[[:blank:]]+U[[:print:]]+$' | > cut -s -d ' ' -f 1` > # Create lists with wanted destinations (separate for v4+v6) > for ifn in ${ifnames}; do > link=`setfib ${fibnum} netstat -I ${ifn} | sed -n -E > 's/^[[:print:]]+<[lL](ink#[[:digit:]]{1,2})>[[:print:]]+$/l\1/p'` > dest4wanted="`setfib ${fibnum} netstat -f inet -nr | grep -E > '^[^[:blank:]]+[[:blank:]]+'"${link}"'[[:blank:]]+.*$' | cut -s -d '' > -f 1` ${dest4wanted:-}" > dest6wanted="`setfib ${fibnum} netstat -f inet6 -nr | grep -E > '^[^[:blank:]]+[[:blank:]]+'"${link}"'[[:blank:]]+.*$' | cut -s -d '' > -f 1` ${dest6wanted:-}" > done > # remove wanted destinations from v4 list > for dest in ${dest4wanted}; do > dest4list="`echo ${dest4list} | sed -E 's,'"${dest}"' *,,'`" > done > # remove wanted destinations from v6 list > for dest in ${dest6wanted}; do > dest6list="`echo ${dest6list} | sed -E 's,'"${dest}"' *,,'`" > done > } > > _clean_fib(){ > _find_unwanted_destinations || return 1 > # extract default gateway IPv4 if it's on one of our interfaces and > none is set already > for ifn in ${ifnames}; do > if [ "X${dv4gw}" = "X" ]; then > dv4gw="`netstat -f inet -nr | sed -n -E > 's/^default[[:print:]]+[[:blank:]]([^[:blank:]]+[.:][^[:blank:]]+)[[:print:]]+[^[:blank:]]+[[:blank:]]+'"${ifn}"'$/\1/p'`" > fi > done > # extract default gateway IPv6 if it's on one of our interfaces and > none is set already > for ifn in ${ifnames}; do > if [ "X${dv6gw}" = "X" ]; then > dv6gw="`netstat -f inet6 -nr | sed -n -E > 's/^default[[:print:]]+[[:blank:]]([^[:blank:]]+[.:][^[:blank:]]+)[[:print:]]+[^[:blank:]]+[[:blank:]]+'"${ifn}"'$/\1/p'`" > fi > done > # remove v4 destinations > for dest in ${dest4list}; do > route -q delete -net -inet ${dest} -fib ${fibnum} || return 1 > done > # remove v6 destinations > for dest in ${dest6list}; do > route -q delete -net -inet6 ${dest} -fib ${fibnum} || return 1 > done > # Set v4 defaultrouter > if [ "X${dv4gw}" != "X" ]; then > route -q add -net -inet default ${dv4gw} -fib ${fibnum} || return 1 > fi > # Set v6 defaultrouter > if [ "X${dv6gw}" != "X" ]; then > route -q add -net -inet6 default ${dv6gw} -fib ${fibnum} || return 1 > fi > } > > if [ $# -gt 8 ]; then > _help "Too many arguments!" > else > if [ $# -lt 4 ]; then > _help "At least \"-f FIBUM\" and \"-i IFACENAME\" is required!" > else > if ! expr $# % 2 >/dev/null; then > while [ $# -gt 0 ]; do > case "$1" in > -f) if ! setfib ${2} true; then > _help "FIBNUM too high!" > else > fibnum=$2 > fi > ;; > -i) if ! ifconfig ${2} >/dev/null 2>&1; then > _help "No such interface: \"$2\"" > else > ifnames="$2 ${ifnames:-}" > fi > ;; > -4) dv4gw="$2";; > -6) dv6gw="$2";; > -h|*) _help "$1" > esac > shift 2 > done > _clean_fib && exit 0 > else > _help "Wrong number of arguments ($#), only even numbers can be > valid!" > fi > fi > fi > exit 1 > > ––– > r248895-revert patch against 10.1: > > --- src/sys/net/if.c 2014-10-06 12:56:27.000000000 +0200 > +++ src/sys/net/if.c 2014-10-13 10:47:51.000000000 +0200 > @@ -1371,8 +1371,7 @@ > return (0); > > err = rtrequest_fib(RTM_DELETE, rt_key(rt), rt->rt_gateway, > - rt_mask(rt), > - rt->rt_flags|RTF_RNH_LOCKED|RTF_PINNED, > + rt_mask(rt), rt->rt_flags|RTF_RNH_LOCKED, > (struct rtentry **) NULL, rt->rt_fibnum); > if (err) { > log(LOG_WARNING, "if_rtdel: error %d\n", err); > --- src/sys/net/route.c 2014-10-06 12:56:27.000000000 +0200 > +++ src/sys/net/route.c 2014-10-13 10:47:51.000000000 +0200 > @@ -1210,14 +1210,6 @@ > error = 0; > } > #endif > - if ((flags & RTF_PINNED) == 0) { > - /* Check if target route can be deleted */ > - rt = (struct rtentry *)rnh->rnh_lookup(dst, > - netmask, rnh); > - if ((rt != NULL) && (rt->rt_flags & RTF_PINNED)) > - senderr(EADDRINUSE); > - } > - > /* > * Remove the item from the tree and return it. > * Complain if it is not there and do no more processing. > @@ -1521,7 +1513,6 @@ > int didwork = 0; > int a_failure = 0; > static struct sockaddr_dl null_sdl = {sizeof(null_sdl), AF_LINK}; > - struct radix_node_head *rnh; > > if (flags & RTF_HOST) { > dst = ifa->ifa_dstaddr; > @@ -1580,6 +1571,7 @@ > */ > for ( fibnum = startfib; fibnum <= endfib; fibnum++) { > if (cmd == RTM_DELETE) { > + struct radix_node_head *rnh; > struct radix_node *rn; > /* > * Look up an rtentry that is in the routing tree and > @@ -1626,8 +1618,7 @@ > */ > bzero((caddr_t)&info, sizeof(info)); > info.rti_ifa = ifa; > - info.rti_flags = flags | > - (ifa->ifa_flags & ~IFA_RTSELF) | RTF_PINNED; > + info.rti_flags = flags | (ifa->ifa_flags & ~IFA_RTSELF); > info.rti_info[RTAX_DST] = dst; > /* > * doing this for compatibility reasons > @@ -1639,33 +1630,6 @@ > info.rti_info[RTAX_GATEWAY] = ifa->ifa_addr; > info.rti_info[RTAX_NETMASK] = netmask; > error = rtrequest1_fib(cmd, &info, &rt, fibnum); > - > - if ((error == EEXIST) && (cmd == RTM_ADD)) { > - /* > - * Interface route addition failed. > - * Atomically delete current prefix generating > - * RTM_DELETE message, and retry adding > - * interface prefix. > - */ > - rnh = rt_tables_get_rnh(fibnum, dst->sa_family); > - RADIX_NODE_HEAD_LOCK(rnh); > - > - /* Delete old prefix */ > - info.rti_ifa = NULL; > - info.rti_flags = RTF_RNH_LOCKED; > - > - error = rtrequest1_fib(RTM_DELETE, &info, NULL, fibnum); > - if (error == 0) { > - info.rti_ifa = ifa; > - info.rti_flags = flags | RTF_RNH_LOCKED | > - (ifa->ifa_flags & ~IFA_RTSELF) | RTF_PINNED; > - error = rtrequest1_fib(cmd, &info, &rt, fibnum); > - } > - > - RADIX_NODE_HEAD_UNLOCK(rnh); > - } > - > - > if (error == 0 && rt != NULL) { > /* > * notify any listening routing agents of the change > --- src/sys/net/route.h 2014-10-06 12:56:27.000000000 +0200 > +++ src/sys/net/route.h 2014-10-13 10:43:59.000000000 +0200 > @@ -148,7 +148,7 @@ > /* 0x20000 unused, was RTF_WASCLONED */ > #define RTF_PROTO3 0x40000 /* protocol specific routing flag */ > /* 0x80000 unused */ > -#define RTF_PINNED 0x100000 /* route is immutable */ > +#define RTF_PINNED 0x100000 /* future use (route is immutable, > startintg with r248895) */ > #define RTF_LOCAL 0x200000 /* route represents a local address */ > #define RTF_BROADCAST 0x400000 /* route represents a bcast > address */ > #define RTF_MULTICAST 0x800000 /* route represents a mcast > address */ > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 09:42:12 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8DC82F8; Mon, 13 Oct 2014 09:42:12 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E557AE1; Mon, 13 Oct 2014 09:42:12 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9D9gAhu042272; Mon, 13 Oct 2014 11:42:10 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A81DA3053; Mon, 13 Oct 2014 11:42:09 +0200 (CEST) Message-ID: <543B9E70.9060609@omnilan.de> Date: Mon, 13 Oct 2014 11:42:08 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: Deleting IPv4 iface-routes from extra FIBs References: <53569ABA.60007@omnilan.de> <535771F3.4070007@freebsd.org> <543B8ED5.6040206@omnilan.de> <543B9075.2000102@FreeBSD.org> <543B9873.3040605@omnilan.de> <543B998D.2020003@FreeBSD.org> In-Reply-To: <543B998D.2020003@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81B20D416B47109DFDD66864" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 13 Oct 2014 11:42:10 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: "freebsd-net@freebsd.org" , FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 09:42:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81B20D416B47109DFDD66864 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Alexander V. Chernikov's Nachricht vom 13.10.2014 11:21 (localtime): > On 13.10.2014 13:16, Harald Schmalzbauer wrote: >> Bez=C3=BCglich Alexander V. Chernikov's Nachricht vom 13.10.2014 10:= 42 >> (localtime): >>> On 13.10.2014 12:35, Harald Schmalzbauer wrote: >>>> Bez=C3=BCglich Julian Elischer's Nachricht vom 23.04.2014 09:55 >>>> (localtime): >> ... >>>>> yes, we made two behaviours. >>>>> Add interface routes to all active FIBS or only add them to the fir= st >>>>> fib and let the user populate other fibs as needed. >>>>> It appears you want the second behaviour, so I suggest you use that= >>>>> option and set up all your routes manually. >>>> Hello, >>>> >>>> last time I had the iface-route problem, I just reverted r248895 (fo= r >>>> 9.3). There was inconsitent behaviour with v6 iface routes and >>>> net.add_addr_allfibs=3D0. >>>> Now I checked with 10.1 ans it seems net.add_addr_allfibs=3D0 doesn'= t >>>> work >>>> any more: >>>> netstat -f inet -nr >>>> Routing tables >>>> >>>> Internet: >>>> Destination Gateway Flags Netif Expire >>>> default 172.21.32.1 UGS egn >>>> 127.0.0.1 link#2 UH lo0 >>>> 172.21.32.0/19 link#1 U egn >>>> 172.21.35.1 link#1 UHS lo0 >>>> >>>> netstat -F 1 -f inet -nr >>>> Routing tables (fib: 1) >>>> >>>> Internet: >>>> Destination Gateway Flags Netif Expire >>>> 127.0.0.1 link#2 UH lo0 >>>> 172.21.32.0/19 link#1 U egn >>>> >>>> 'sysctl net.add_addr_allfibs' >>>> net.add_addr_allfibs: 0 >>> Are you sure net.add_addr_allfibs was applied before interface addres= s >>> added? >> Sorry, I messed it up. Forgot that on my production systems (where I >> tested), / is read-only with /etc as union-mount. >> Adding net.add_addr_allfibs=3D0 to the correct sysctl.conf made the in= et >> routing table stay empty. >> >> But unfortunately not the inet6 routing table :-( >> So I still need to delete iface routes for my jail setups, hence need = to >> revert r248895. > Hm. If the problem happens with inet6 routes only, why do you need to > revert r248895 ?=20 For consistency. Either I populate own iface-routes for both, inet and inet6, or I clean both. The latter is what my script has been doing for some time (I think I wrote it when I tested 9.1-RC), so for me it's much less effort to make my script working by reverting r248895 instead of adding another one which cares about inet (v4) only (for the moment). Probably net.add_addr_allfibs will also influence inet6 routing as well in the future, then I'll redo my rc.jails_fibprepare. Thanks, -Harry --------------enig81B20D416B47109DFDD66864 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQ7nnEACgkQLDqVQ9VXb8h86gCgr59GmiQsbjteXxN5zlvKL6cU CZsAoKEz0GhkZNIR5a5iqi1Q88+QwFPy =8eck -----END PGP SIGNATURE----- --------------enig81B20D416B47109DFDD66864-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 11:47:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AABD9999; Mon, 13 Oct 2014 11:47:40 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67FE2870; Mon, 13 Oct 2014 11:47:40 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xda6X-000IyI-LG; Mon, 13 Oct 2014 11:31:41 +0400 Message-ID: <543BBB83.6010309@FreeBSD.org> Date: Mon, 13 Oct 2014 15:46:11 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Elischer , wishmaster Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> <543B648D.6020403@freebsd.org> In-Reply-To: <543B648D.6020403@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 11:47:40 -0000 On 13.10.2014 09:35, Julian Elischer wrote: > On 10/12/14, 1:55 PM, wishmaster wrote: >> >> --- Original message --- >> From: "Alexander V. Chernikov" >> Date: 11 October 2014, 23:20:39 >> >> >>> On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: >>> >>>> Hi, >>>> >>>> What action items are left to enable VIMAGE by default for FreeBSD 11? >>> Are there any tests results showing performance implications on >>> different network-related workloads? > > the last time we teste things vnet made things faster. > > if you spread 100 sessions over N vnets and had 100 sessions on one > system, > then there are 1/N as many locking collisions as each vnet is its own > locking domain. Sure. I'm mostly concerned about performance impact on non-virtualized workloads (e.g. web server or firewall workload types). > > Julian > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 15:23:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7602D109; Mon, 13 Oct 2014 15:23:58 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B06D518C; Mon, 13 Oct 2014 15:23:57 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id n3so7736713wiv.15 for ; Mon, 13 Oct 2014 08:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=US0Th29h9nJaK8mgK2lxpU+314KEeLr15OP9LiBzylE=; b=FOkT+adxgLpmP1at8zFh2S+mU/ugHTsfXBexvKQZ/COhoF/uaXOPnTtwTS/oA9Wlnf yTf3DiVm30v2zuydUS+vhxa8s4Fu1ESbumQW1Qj91pxLaSfH+GI8eoNKi8f31wi7lgEb oyt55TEZz9bYQg9BwyA6KSWqQVb6re8vQQTfQLJWlld6wdY251GS6NUNdnd+GoJKmPwt cxBHvbjpeDqmPqESlNzyJpUklTE45XyWa76xeQkRt1ic3Dc8NCSTyT4Dd8cD1WCO8Dyf ekcX2bs7U7DiSA7iPBNyQ36jBvCntCWlMf3K9xcUhWRlU34+TGTLNYFD4HnNzYvOwh1Y dmsQ== MIME-Version: 1.0 X-Received: by 10.180.72.45 with SMTP id a13mr1498776wiv.50.1413213835679; Mon, 13 Oct 2014 08:23:55 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.220.227 with HTTP; Mon, 13 Oct 2014 08:23:55 -0700 (PDT) In-Reply-To: <543B9873.3040605@omnilan.de> References: <53569ABA.60007@omnilan.de> <535771F3.4070007@freebsd.org> <543B8ED5.6040206@omnilan.de> <543B9075.2000102@FreeBSD.org> <543B9873.3040605@omnilan.de> Date: Mon, 13 Oct 2014 09:23:55 -0600 X-Google-Sender-Auth: 5fxoXsJaLCIZPcoeGnhdg96ydaI Message-ID: Subject: Re: Deleting IPv4 iface-routes from extra FIBs From: Alan Somers To: Harald Schmalzbauer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "Alexander V. Chernikov" , FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 15:23:58 -0000 On Mon, Oct 13, 2014 at 3:16 AM, Harald Schmalzbauer wrote: > Bez=C3=BCglich Alexander V. Chernikov's Nachricht vom 13.10.2014 10:42 > (localtime): >> On 13.10.2014 12:35, Harald Schmalzbauer wrote: >>> Bez=C3=BCglich Julian Elischer's Nachricht vom 23.04.2014 09:55 >>> (localtime): > ... >>>> yes, we made two behaviours. >>>> Add interface routes to all active FIBS or only add them to the first >>>> fib and let the user populate other fibs as needed. >>>> It appears you want the second behaviour, so I suggest you use that >>>> option and set up all your routes manually. >>> Hello, >>> >>> last time I had the iface-route problem, I just reverted r248895 (for >>> 9.3). There was inconsitent behaviour with v6 iface routes and >>> net.add_addr_allfibs=3D0. >>> Now I checked with 10.1 ans it seems net.add_addr_allfibs=3D0 doesn't w= ork >>> any more: >>> netstat -f inet -nr >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Netif Expire >>> default 172.21.32.1 UGS egn >>> 127.0.0.1 link#2 UH lo0 >>> 172.21.32.0/19 link#1 U egn >>> 172.21.35.1 link#1 UHS lo0 >>> >>> netstat -F 1 -f inet -nr >>> Routing tables (fib: 1) >>> >>> Internet: >>> Destination Gateway Flags Netif Expire >>> 127.0.0.1 link#2 UH lo0 >>> 172.21.32.0/19 link#1 U egn >>> >>> 'sysctl net.add_addr_allfibs' >>> net.add_addr_allfibs: 0 >> Are you sure net.add_addr_allfibs was applied before interface address >> added? > > Sorry, I messed it up. Forgot that on my production systems (where I > tested), / is read-only with /etc as union-mount. > Adding net.add_addr_allfibs=3D0 to the correct sysctl.conf made the inet > routing table stay empty. > > But unfortunately not the inet6 routing table :-( > So I still need to delete iface routes for my jail setups, hence need to > revert r248895. What do your ipv6 routing tables look like when the sysctl is set correctly and 248895 is in place? > > Strage thing is that 'rcorder' shows nothing iface related before > mountcritlocal, where I resource /etc/rc.d, so the > 'net.add_addr_allfibs' in my union-mounted sysctl.conf should work!?! > But that's my homemade problem ;-) /> > > For those having similar problems, here's how I currently solve my jail > setups: > > jail.conf: > > jail { > allow.set_hostname; > ... > exec.fib =3D 1; > exec.prestart =3D "/bin/sh /.JAIL$name/etc/rc.jails_fibprepare -f > 1 -i inop"; > interface =3D inop; > ... > > =E2=80=93=E2=80=93=E2=80=93 > rc.jails_fibprepare : > > #!/bin/sh > # format FIB for JAIL usage (remove all but own interface routes) > # Does only work if on FreeBSD-9.2 if r248895 was reverted, since > deleting iface routes is prohibited by default. > # TODO: extend jail (8) and jail.conf for routing parameters and delete > this ugly hack! > # TODO: Do it the other way, not deleleting, but adding if "sysctl > net.add_addr_allfibs=3D0". > # Last edited: 20140605.0 > > > _help(){ > echo "Usage: rc.jails_fibprepare -f FIBNUM -i IFACENAME [-4 > defaultrouterIPv4] [-6 defaultrouterIPv6] [-h]" > if [ "X$1" !=3D "X" ]; then > if [ "$1" =3D "-h" ]; then > echo "Prepare routing tabel of specified FIB for jail usage." > echo "This removes all iface routes not belonging to own interface" > echo "and sets default route(s) if specified or automatically, if" > echo "iface used is the same where fib 0 has set the default gatewa= y." > echo " -f: FIBNUM is the number of the fib whose routing > table will be altered." > echo " -i: IFACENAME is the name of the interface we have > our IP on." > echo " -4: IP (v4) of the defaultrouter." > echo " -6: IP (v6) of the defaultrouter." > echo " -h: This help" > echo > else > echo "ERROR:" > echo " $1" > echo > exit 1 > fi > else > echo "Type \"rc.jails_fibprepare -h\" for more help." > exit 1 > fi > exit 0 > } > > _find_unwanted_destinations(){ > # first, generate complete destination lists (separate for v4+v6) > dest4list=3D`setfib ${fibnum} netstat -f inet -nr | grep -E > '^[[:print:]]+(%[[:alnum:].]+|[[:digit:]])[[:blank:]]+U[[:print:]]+$' | > cut -s -d ' ' -f 1` > dest6list=3D`setfib ${fibnum} netstat -f inet6 -nr | grep -E > '^[[:print:]]+(%[[:alnum:].]+|[[:digit:]])[[:blank:]]+U[[:print:]]+$' | > cut -s -d ' ' -f 1` > # Create lists with wanted destinations (separate for v4+v6) > for ifn in ${ifnames}; do > link=3D`setfib ${fibnum} netstat -I ${ifn} | sed -n -E > 's/^[[:print:]]+<[lL](ink#[[:digit:]]{1,2})>[[:print:]]+$/l\1/p'` > dest4wanted=3D"`setfib ${fibnum} netstat -f inet -nr | grep -E > '^[^[:blank:]]+[[:blank:]]+'"${link}"'[[:blank:]]+.*$' | cut -s -d ' ' > -f 1` ${dest4wanted:-}" > dest6wanted=3D"`setfib ${fibnum} netstat -f inet6 -nr | grep -E > '^[^[:blank:]]+[[:blank:]]+'"${link}"'[[:blank:]]+.*$' | cut -s -d ' ' > -f 1` ${dest6wanted:-}" > done > # remove wanted destinations from v4 list > for dest in ${dest4wanted}; do > dest4list=3D"`echo ${dest4list} | sed -E 's,'"${dest}"' *,,'`" > done > # remove wanted destinations from v6 list > for dest in ${dest6wanted}; do > dest6list=3D"`echo ${dest6list} | sed -E 's,'"${dest}"' *,,'`" > done > } > > _clean_fib(){ > _find_unwanted_destinations || return 1 > # extract default gateway IPv4 if it's on one of our interfaces and > none is set already > for ifn in ${ifnames}; do > if [ "X${dv4gw}" =3D "X" ]; then > dv4gw=3D"`netstat -f inet -nr | sed -n -E > 's/^default[[:print:]]+[[:blank:]]([^[:blank:]]+[.:][^[:blank:]]+)[[:prin= t:]]+[^[:blank:]]+[[:blank:]]+'"${ifn}"'$/\1/p'`" > fi > done > # extract default gateway IPv6 if it's on one of our interfaces and > none is set already > for ifn in ${ifnames}; do > if [ "X${dv6gw}" =3D "X" ]; then > dv6gw=3D"`netstat -f inet6 -nr | sed -n -E > 's/^default[[:print:]]+[[:blank:]]([^[:blank:]]+[.:][^[:blank:]]+)[[:prin= t:]]+[^[:blank:]]+[[:blank:]]+'"${ifn}"'$/\1/p'`" > fi > done > # remove v4 destinations > for dest in ${dest4list}; do > route -q delete -net -inet ${dest} -fib ${fibnum} || return 1 > done > # remove v6 destinations > for dest in ${dest6list}; do > route -q delete -net -inet6 ${dest} -fib ${fibnum} || return 1 > done > # Set v4 defaultrouter > if [ "X${dv4gw}" !=3D "X" ]; then > route -q add -net -inet default ${dv4gw} -fib ${fibnum} || return 1 > fi > # Set v6 defaultrouter > if [ "X${dv6gw}" !=3D "X" ]; then > route -q add -net -inet6 default ${dv6gw} -fib ${fibnum} || return 1 > fi > } > > if [ $# -gt 8 ]; then > _help "Too many arguments!" > else > if [ $# -lt 4 ]; then > _help "At least \"-f FIBUM\" and \"-i IFACENAME\" is required!" > else > if ! expr $# % 2 >/dev/null; then > while [ $# -gt 0 ]; do > case "$1" in > -f) if ! setfib ${2} true; then > _help "FIBNUM too high!" > else > fibnum=3D$2 > fi > ;; > -i) if ! ifconfig ${2} >/dev/null 2>&1; then > _help "No such interface: \"$2\"" > else > ifnames=3D"$2 ${ifnames:-}" > fi > ;; > -4) dv4gw=3D"$2";; > -6) dv6gw=3D"$2";; > -h|*) _help "$1" > esac > shift 2 > done > _clean_fib && exit 0 > else > _help "Wrong number of arguments ($#), only even numbers can be > valid!" > fi > fi > fi > exit 1 > > =E2=80=93=E2=80=93=E2=80=93 > r248895-revert patch against 10.1: > > --- src/sys/net/if.c 2014-10-06 12:56:27.000000000 +0200 > +++ src/sys/net/if.c 2014-10-13 10:47:51.000000000 +0200 > @@ -1371,8 +1371,7 @@ > return (0); > > err =3D rtrequest_fib(RTM_DELETE, rt_key(rt), rt->rt_gateway, > - rt_mask(rt), > - rt->rt_flags|RTF_RNH_LOCKED|RTF_PINNED, > + rt_mask(rt), rt->rt_flags|RTF_RNH_LOCKED, > (struct rtentry **) NULL, rt->rt_fibnum); > if (err) { > log(LOG_WARNING, "if_rtdel: error %d\n", err); > --- src/sys/net/route.c 2014-10-06 12:56:27.000000000 +0200 > +++ src/sys/net/route.c 2014-10-13 10:47:51.000000000 +0200 > @@ -1210,14 +1210,6 @@ > error =3D 0; > } > #endif > - if ((flags & RTF_PINNED) =3D=3D 0) { > - /* Check if target route can be deleted */ > - rt =3D (struct rtentry *)rnh->rnh_lookup(dst, > - netmask, rnh); > - if ((rt !=3D NULL) && (rt->rt_flags & RTF_PINNED)) > - senderr(EADDRINUSE); > - } > - > /* > * Remove the item from the tree and return it. > * Complain if it is not there and do no more processing. > @@ -1521,7 +1513,6 @@ > int didwork =3D 0; > int a_failure =3D 0; > static struct sockaddr_dl null_sdl =3D {sizeof(null_sdl), AF_LINK}; > - struct radix_node_head *rnh; > > if (flags & RTF_HOST) { > dst =3D ifa->ifa_dstaddr; > @@ -1580,6 +1571,7 @@ > */ > for ( fibnum =3D startfib; fibnum <=3D endfib; fibnum++) { > if (cmd =3D=3D RTM_DELETE) { > + struct radix_node_head *rnh; > struct radix_node *rn; > /* > * Look up an rtentry that is in the routing tree and > @@ -1626,8 +1618,7 @@ > */ > bzero((caddr_t)&info, sizeof(info)); > info.rti_ifa =3D ifa; > - info.rti_flags =3D flags | > - (ifa->ifa_flags & ~IFA_RTSELF) | RTF_PINNED; > + info.rti_flags =3D flags | (ifa->ifa_flags & ~IFA_RTSELF); > info.rti_info[RTAX_DST] =3D dst; > /* > * doing this for compatibility reasons > @@ -1639,33 +1630,6 @@ > info.rti_info[RTAX_GATEWAY] =3D ifa->ifa_addr; > info.rti_info[RTAX_NETMASK] =3D netmask; > error =3D rtrequest1_fib(cmd, &info, &rt, fibnum); > - > - if ((error =3D=3D EEXIST) && (cmd =3D=3D RTM_ADD)) { > - /* > - * Interface route addition failed. > - * Atomically delete current prefix generating > - * RTM_DELETE message, and retry adding > - * interface prefix. > - */ > - rnh =3D rt_tables_get_rnh(fibnum, dst->sa_family); > - RADIX_NODE_HEAD_LOCK(rnh); > - > - /* Delete old prefix */ > - info.rti_ifa =3D NULL; > - info.rti_flags =3D RTF_RNH_LOCKED; > - > - error =3D rtrequest1_fib(RTM_DELETE, &info, NULL, fibnum); > - if (error =3D=3D 0) { > - info.rti_ifa =3D ifa; > - info.rti_flags =3D flags | RTF_RNH_LOCKED | > - (ifa->ifa_flags & ~IFA_RTSELF) | RTF_PINNED; > - error =3D rtrequest1_fib(cmd, &info, &rt, fibnum); > - } > - > - RADIX_NODE_HEAD_UNLOCK(rnh); > - } > - > - > if (error =3D=3D 0 && rt !=3D NULL) { > /* > * notify any listening routing agents of the change > --- src/sys/net/route.h 2014-10-06 12:56:27.000000000 +0200 > +++ src/sys/net/route.h 2014-10-13 10:43:59.000000000 +0200 > @@ -148,7 +148,7 @@ > /* 0x20000 unused, was RTF_WASCLONED */ > #define RTF_PROTO3 0x40000 /* protocol specific routing flag *= / > /* 0x80000 unused */ > -#define RTF_PINNED 0x100000 /* route is immutable */ > +#define RTF_PINNED 0x100000 /* future use (route is immutable, > startintg with r248895) */ > #define RTF_LOCAL 0x200000 /* route represents a local address= */ > #define RTF_BROADCAST 0x400000 /* route represents a bcast > address */ > #define RTF_MULTICAST 0x800000 /* route represents a mcast > address */ > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 20:57:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09E17910 for ; Mon, 13 Oct 2014 20:57:05 +0000 (UTC) Received: from nm44.bullet.mail.ne1.yahoo.com (nm44.bullet.mail.ne1.yahoo.com [98.138.120.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A086EE08 for ; Mon, 13 Oct 2014 20:57:04 +0000 (UTC) Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 13 Oct 2014 20:57:03 -0000 Received: from [98.138.100.112] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 13 Oct 2014 20:51:48 -0000 Received: from [98.138.89.193] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 13 Oct 2014 20:51:48 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 13 Oct 2014 20:51:48 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 4746.29761.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 37016 invoked by uid 60001); 13 Oct 2014 20:51:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1413233507; bh=6eW1GM8AyYm1bLc5OY6e96ImdAIaBMzmVcoXz1G79mo=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=L6Vo7b5V+Dzt77K5mOozDxwR4Hu+MU4hT9MoWSvOKwhAhzHqILUfKMTo2PAJzwS0WsgMcDwXFN5x8nU414i7bfwArKUfZQw+ySJya2PLr+Uz8LznjttCq7pHGYxhrIwV24ucRVamQeDkrDCXRfw+1kF0jB/DddPUBD8eahlm7D0= X-YMail-OSG: oEEg6T4VM1kzYjIi4dE_FdilJL7N4hlProXNzo0Vr.qKAOt qcBc06yQDZKlpfYYB8vnxlPoxHIRa5h.Ys3fq.hvEorUOMrnlUP_8HSbpGTZ 5Fp1WsYBvoG9Cw4lMjlM5UlVlWFH3fQaHL.ig9wLOoV2yQqooECchCCPD72H U_pI2.drATnIl3RcmJw43.g_4x9uzxKppYtKOZ2XZQkgztUoNlrhI1FWVQAl nbeHQEtvO9kA7SLanWiiGB1gKEZNVjE5Ctcw9aGMu5BdOKNuSYCIsjn3Rs3D NsIYX9ef0ofhMzL9cUZrtI8fPBTogjbTWNUodWkCZSUGhYfxVsvwR1T7Oz8S LROFi5snMnqS3VWvFNlGYfpTEPje97RKiPqjlDtgJYKm91hgLqIjydLLJb.v NcwbHQN4HW7pyLZF2PvNKKKMaajR1QqHWjmjzV5CZ7UCwWfNmy37tzr_IPOf 1KIaz5R4IMPIz0khTxHQsaKO9MZJvLe..QktC7bx9YAGqV0D2qU0aSZPvfCx QAAr5pMg- Received: from [31.170.158.197] by web121806.mail.ne1.yahoo.com via HTTP; Mon, 13 Oct 2014 13:51:47 PDT X-Rocket-MIMEInfo: 002.001, SSBoYXZlIGEgdHJvdWJsZSB3aGlsZSBjb21waWxlIG5ldG1hcC1pcGZ3LgptYWtlIE5FVE1BUF9JTkM9Li9zeXMKQnVpbGRpbmcgdXNlcnNwYWNlIC4uLgpnbWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvcm9vdC9uZXRtYXAtaXBmdy9pcGZ3JwooY2QgLi4vb2JqczsgZ21ha2UgLWYgLi4vTWFrZWZpbGUua2lwZncgaW5jbHVkZV9lKQpnbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvcm9vdC9uZXRtYXAtaXBmdy9vYmpzJwpCdWlsZGluZyAvcm9vdC9uZXRtYXAtaXBmdy9vYmpzLy4uL29ianMvaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 Message-ID: <1413233507.12196.YahooMailNeo@web121806.mail.ne1.yahoo.com> Date: Mon, 13 Oct 2014 13:51:47 -0700 From: Roman Shevchenko Reply-To: Roman Shevchenko Subject: netmap-ipfw To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 20:57:05 -0000 I have a trouble while compile netmap-ipfw. make NETMAP_INC=./sys Building userspace ... gmake[1]: Entering directory `/root/netmap-ipfw/ipfw' (cd ../objs; gmake -f ../Makefile.kipfw include_e) gmake[2]: Entering directory `/root/netmap-ipfw/objs' Building /root/netmap-ipfw/objs/../objs/include_e ... gmake[2]: Leaving directory `/root/netmap-ipfw/objs' CC ipfw2.c CC dummynet.c CC main.c CC ipv6.c CC altq.c CC ../extra/glue.c LD ipfw gmake[1]: Leaving directory `/root/netmap-ipfw/ipfw' Building datapath ... gmake[1]: Entering directory `/root/netmap-ipfw/objs' CC ../sys/netpfil/ipfw/ip_fw2.c CC ../sys/netpfil/ipfw/ip_fw_pfil.c CC ../sys/netpfil/ipfw/ip_fw_sockopt.c CC ../sys/netpfil/ipfw/ip_fw_dynamic.c CC ../sys/netpfil/ipfw/ip_fw_table.c CC ../sys/netpfil/ipfw/ip_fw_log.c CC ../sys/netpfil/ipfw/ip_dummynet.c CC ../sys/netpfil/ipfw/ip_dn_io.c CC ../sys/netpfil/ipfw/ip_dn_glue.c CC ../sys/netpfil/ipfw/dn_heap.c CC ../sys/netpfil/ipfw/dn_sched_fifo.c CC ../sys/netpfil/ipfw/dn_sched_wf2q.c CC ../sys/netpfil/ipfw/dn_sched_rr.c CC ../sys/netpfil/ipfw/dn_sched_qfq.c CC ../sys/netpfil/ipfw/dn_sched_prio.c CC ../sys/net/radix.c CC ../sys/netinet/in_cksum.c CC ../extra/ipfw2_mod.c CC ../extra/missing.c CC ../extra/session.c CC ../extra/netmap_io.c ../extra/netmap_io.c: In function 'netmap_fwd': ../extra/netmap_io.c:93: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:93: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:94: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:94: error: dereferencing pointer to incomplete type cc1: warnings being treated as errors ../extra/netmap_io.c:97: warning: implicit declaration of function 'nm_ring_empty' ../extra/netmap_io.c:118: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:118: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:122: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:123: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:123: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:127: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:128: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:128: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:128: error: 'NS_BUF_CHANGED' undeclared (first use in this function) ../extra/netmap_io.c:128: error: (Each undeclared identifier is reported only once ../extra/netmap_io.c:128: error: for each function it appears in.) ../extra/netmap_io.c:129: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:129: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:130: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:132: warning: implicit declaration of function 'nm_pkt_copy' ../extra/netmap_io.c:132: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:132: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:132: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:133: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:133: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:133: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:134: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:137: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:137: error: 'NS_INDIRECT' undeclared (first use in this function) ../extra/netmap_io.c:143: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:145: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:145: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:145: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:146: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:152: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:152: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:152: warning: implicit declaration of function 'nm_ring_next' ../extra/netmap_io.c:152: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:157: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:157: error: 'NIOCTXSYNC' undeclared (first use in this function) ../extra/netmap_io.c: In function 'netmap_read': ../extra/netmap_io.c:221: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:221: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:222: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:222: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:222: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:227: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:227: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:238: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:239: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:240: error: invalid use of undefined type 'struct netmap_slot' ../extra/netmap_io.c:241: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:242: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:242: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:244: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:249: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:249: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:254: error: dereferencing pointer to incomplete type ../extra/netmap_io.c: In function 'netmap_add_port': ../extra/netmap_io.c:317: warning: implicit declaration of function 'calloc' ../extra/netmap_io.c:317: warning: incompatible implicit declaration of built-in function 'calloc' ../extra/netmap_io.c:318: warning: implicit declaration of function 'nm_open' ../extra/netmap_io.c:318: warning: assignment makes pointer from integer without a cast ../extra/netmap_io.c:325: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:327: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:339: error: dereferencing pointer to incomplete type ../extra/netmap_io.c:339: error: dereferencing pointer to incomplete type gmake[1]: *** [netmap_io.o] Error 1 gmake[1]: Leaving directory `/root/netmap-ipfw/objs' gmake: *** [kipfw] Error 2 My system is FreeBSD 9.2 Does it have any solution? From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 21:04:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 877E0B7A for ; Mon, 13 Oct 2014 21:04:56 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BFC5EE0 for ; Mon, 13 Oct 2014 21:04:55 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id h11so4919246wiw.7 for ; Mon, 13 Oct 2014 14:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l95XKO9PkRgBqrTtdazZ1pUcAibNO4wkJnxuEKg/0hU=; b=sLOC0giRO8YJsuEa2vk5xWdfNyfU/qrsdh7s21yP0mk1TGJM4/ZDFp6d3FnjeGw54B 1wmkw9U4Uv3sgbHtAFV1GvfTHIchWTKGlkjK94kP2BD41CgJb82af/r5c/UeL4UJcU41 JCBKRdQ6UCM5V7QsnI5/ciCWhB9yyryZIjo9sfsoKSraOL4MhDSMQgjalXIRrMcdVQHY uut7FOpSrtDG8OdleaWZ3ZMRNU3hbsVfe8YFiMeqO9jk073xPvh5zw2querJ7yuC6aXI b41ZgIhwtxT+VW4DCJfy5rqlrRPBr2qN3vrucwWZiDzSwqBRkzJJMxvEwolYI6lYZytB b0rg== MIME-Version: 1.0 X-Received: by 10.180.38.34 with SMTP id d2mr1297906wik.55.1413234294245; Mon, 13 Oct 2014 14:04:54 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Mon, 13 Oct 2014 14:04:54 -0700 (PDT) In-Reply-To: <1413233507.12196.YahooMailNeo@web121806.mail.ne1.yahoo.com> References: <1413233507.12196.YahooMailNeo@web121806.mail.ne1.yahoo.com> Date: Mon, 13 Oct 2014 23:04:54 +0200 X-Google-Sender-Auth: vkKzHBkr7WKYwtC49i3DOgaC-Og Message-ID: Subject: Re: netmap-ipfw From: Luigi Rizzo To: Roman Shevchenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 21:04:56 -0000 On Mon, Oct 13, 2014 at 10:51 PM, Roman Shevchenko via freebsd-net < freebsd-net@freebsd.org> wrote: > I have a trouble while compile netmap-ipfw. > make NETMAP_INC=3D./sys > Building userspace ... > gmake[1]: Entering directory `/root/netmap-ipfw/ipfw' > (cd ../objs; gmake -f ../Makefile.kipfw include_e) > gmake[2]: Entering directory `/root/netmap-ipfw/objs' > Building /root/netmap-ipfw/objs/../objs/include_e ... > gmake[2]: Leaving directory `/root/netmap-ipfw/objs' > CC ipfw2.c > CC dummynet.c > CC main.c > CC ipv6.c > CC altq.c > CC ../extra/glue.c > LD ipfw > gmake[1]: Leaving directory `/root/netmap-ipfw/ipfw' > Building datapath ... > gmake[1]: Entering directory `/root/netmap-ipfw/objs' > CC ../sys/netpfil/ipfw/ip_fw2.c > CC ../sys/netpfil/ipfw/ip_fw_pfil.c > CC ../sys/netpfil/ipfw/ip_fw_sockopt.c > CC ../sys/netpfil/ipfw/ip_fw_dynamic.c > CC ../sys/netpfil/ipfw/ip_fw_table.c > CC ../sys/netpfil/ipfw/ip_fw_log.c > CC ../sys/netpfil/ipfw/ip_dummynet.c > CC ../sys/netpfil/ipfw/ip_dn_io.c > CC ../sys/netpfil/ipfw/ip_dn_glue.c > CC ../sys/netpfil/ipfw/dn_heap.c > CC ../sys/netpfil/ipfw/dn_sched_fifo.c > CC ../sys/netpfil/ipfw/dn_sched_wf2q.c > CC ../sys/netpfil/ipfw/dn_sched_rr.c > CC ../sys/netpfil/ipfw/dn_sched_qfq.c > CC ../sys/netpfil/ipfw/dn_sched_prio.c > CC ../sys/net/radix.c > CC ../sys/netinet/in_cksum.c > CC ../extra/ipfw2_mod.c > CC ../extra/missing.c > CC ../extra/session.c > CC ../extra/netmap_io.c > ../extra/netmap_io.c: In function 'netmap_fwd': > ../extra/netmap_io.c:93: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:93: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:94: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:94: error: dereferencing pointer to incomplete type > cc1: warnings being treated as errors > ../extra/netmap_io.c:97: warning: implicit declaration of function > 'nm_ring_empty' > ../extra/netmap_io.c:118: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:118: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:122: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:123: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:123: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:127: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:128: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:128: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:128: error: 'NS_BUF_CHANGED' undeclared (first use i= n > this function) > ../extra/netmap_io.c:128: error: (Each undeclared identifier is reported > only once > ../extra/netmap_io.c:128: error: for each function it appears in.) > ../extra/netmap_io.c:129: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:129: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:130: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:132: warning: implicit declaration of function > 'nm_pkt_copy' > ../extra/netmap_io.c:132: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:132: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:132: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:133: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:133: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:133: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:134: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:136: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:137: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:137: error: 'NS_INDIRECT' undeclared (first use in > this function) > ../extra/netmap_io.c:143: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:145: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:145: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:145: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:146: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:152: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:152: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:152: warning: implicit declaration of function > 'nm_ring_next' > ../extra/netmap_io.c:152: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:157: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:157: error: 'NIOCTXSYNC' undeclared (first use in > this function) > ../extra/netmap_io.c: In function 'netmap_read': > ../extra/netmap_io.c:221: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:221: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:222: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:222: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:222: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:227: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:227: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:238: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:239: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:240: error: invalid use of undefined type 'struct > netmap_slot' > ../extra/netmap_io.c:241: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:242: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:242: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:244: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:249: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:249: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:254: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c: In function 'netmap_add_port': > ../extra/netmap_io.c:317: warning: implicit declaration of function > 'calloc' > ../extra/netmap_io.c:317: warning: incompatible implicit declaration of > built-in function 'calloc' > ../extra/netmap_io.c:318: warning: implicit declaration of function > 'nm_open' > ../extra/netmap_io.c:318: warning: assignment makes pointer from integer > without a cast > ../extra/netmap_io.c:325: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:327: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:339: error: dereferencing pointer to incomplete type > ../extra/netmap_io.c:339: error: dereferencing pointer to incomplete type > gmake[1]: *** [netmap_io.o] Error 1 > gmake[1]: Leaving directory `/root/netmap-ipfw/objs' > gmake: *** [kipfw] Error 2 > > My system is FreeBSD 9.2 > Does it have any solution? > =E2=80=8Byes, you need to backport the netmap code from HEAD or stable/10, and then point NETMAP_INC to /usr/src/sys/ (netmap applications would still compile provided you have the right headers, but then they would fail at runtime if you don't have a matching kernel version) cheers luigi =E2=80=8B > _______________________________________________ > 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 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Oct 13 22:30:55 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 365689C5; Mon, 13 Oct 2014 22:30:55 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9148DA00; Mon, 13 Oct 2014 22:30:54 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x13so9694349wgg.30 for ; Mon, 13 Oct 2014 15:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yNW2IzjEXw2GOqFP1+6ldI8TdghfExZgsSW4wMYwvAg=; b=cMffUNiKUuuYbMj69VJwrFlGIupnk6quAy9HMovyMZ5zEdLz+oJ4istkIAguF20dV7 ccnR/7rjOJDOtQihwjhAcXXafxyvOho+9Cf2sMoC2mh0V0/x6EGaZXx+J88PyhlfzA06 lP/FrahPnJU9zkASKpOxZhD+J9qyvlrTqkMVhIMjFzwbmAlTVaHxXphudEqisJUDv4oF WAm+00I9BZKbHenvXoZPlJxq98ND0kx4Zc8t+wXiLNM6gqYh6wIh+HYUlGfM83k6eeko YDC/taiGrZ/NpDyMcoJSYw5iQ0WNPLlmdkZsjJZCEjdi5NXjOo7k9JJFVRMsgPEv7AdE 2ldQ== MIME-Version: 1.0 X-Received: by 10.181.27.161 with SMTP id jh1mr1529783wid.75.1413239452673; Mon, 13 Oct 2014 15:30:52 -0700 (PDT) Received: by 10.217.67.201 with HTTP; Mon, 13 Oct 2014 15:30:52 -0700 (PDT) In-Reply-To: References: <1410203348.1343.1.camel@bruno> <2077446.sYcZo9xEXb@ralph.baldwin.cx> <3567780.Mf6fMnzmYG@ralph.baldwin.cx> Date: Mon, 13 Oct 2014 15:30:52 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Oct 2014 22:30:55 -0000 On Fri, Oct 10, 2014 at 11:19 PM, Jason Wolfe wrote: > On Fri, Oct 10, 2014 at 8:53 AM, John Baldwin wrote: > >> On Thursday, October 09, 2014 02:31:32 PM Jason Wolfe wrote: >> > On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote: >> > > My only other thought is if a direct timeout routine ran for a long >> time. >> > > >> > > I just committed a change to current that can let you capture KTR >> traces >> > > of >> > > callout routines for use with schedgraph (r272757). Unfortunately, >> > > enabling KTR_SCHED can be slow. If you are up for trying it, I do >> think >> > > that >> > > building a kernel with KTR and KTR_SCHED enabled >> (KTR_COMPILE=KTR_SCHED >> > > and >> > > KTR_MASK=KTR_SCHED) with the kernel part of the commit I referenced >> above >> > > applied is the best bet to figure out why it is spinning so long. If >> you >> > > can >> > > try that (and if it doesn't slow things down too much) and get a panic >> > > with >> > > those options enabled, then capture the output of >> > > 'ktrdump -e /path/to/kernel -m /var/crash/vmcore.X -ct', we can use >> > > Src/tools/sched/schedgraph.py to look at that output to get a picture >> of >> > > what >> > > was going on just prior to the crash. >> > > >> > > -- >> > > John Baldwin >> > >> > As luck would have it.. caught one of the boxes with the new KTR >> > code/options after only an hour. Crashed in the same way w tid 100003 >> and >> > looking the same in callout_process >> > >> > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid >> > 100003) too long >> > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid >> > 100003) too long >> > >> > #4 0xffffffff8070d6fa in callout_process (now=7915682202423) at >> > /usr/src/sys/kern/kern_ >> > timeout.c:490 >> > >> > The ktrdump oddly only seems to have the last 702, though >> debug.ktr.entries >> > is set to 1024. It appears the buffer may also start after 100003 had >> > already hung? I've bumped debug.ktr.entries up in case we don't have >> > enough history here. >> > >> > http://nitrology.com/ktrdump-spinlock.txt >> >> Hmm, schedgraph.py chokes on this, but it's a bit interesting. It seems >> that >> in this time sample, CPUs 1, 2, 4, and 5 were constantly running ixgbe >> interrupt handlers. No actual thread state changes are logged (which is >> why >> schedgraph choked). >> >> Try setting the sysctl 'net.inet.tcp.per_cpu_timers' to 1 and see if that >> makes a difference. I'm guessing they are all contending on the default >> callout lock which is causing your headache. >> >> -- >> John Baldwin >> > > net.inet.tcp.per_cpu_timers=1 triggered some other fun :) Saw this same > panic across a handful of machines: > > panic: tcp_setpersist: retransmit pending > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe1f9e9ab800 > panic() at panic+0x155/frame 0xfffffe1f9e9ab880 > tcp_setpersist() at tcp_setpersist+0xa3/frame 0xfffffe1f9e9ab8b0 > tcp_timer_persist() at tcp_timer_persist+0x176/frame 0xfffffe1f9e9ab8e0 > softclock_call_cc() at softclock_call_cc+0x1ce/frame 0xfffffe1f9e9ab9e0 > softclock() at softclock+0x44/frame 0xfffffe1f9e9aba00 > intr_event_execute_handlers() at intr_event_execute_handlers+0x83/frame > 0xfffffe1f9e9aba30 > ithread_loop() at ithread_loop+0x96/frame 0xfffffe1f9e9aba70 > fork_exit() at fork_exit+0x71/frame 0xfffffe1f9e9abab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe1f9e9abab0 > --- trap 0, rip = 0, rsp = 0xfffffe1f9e9abb70, rbp = 0 --- > > (kgdb) up 3 > #3 0xffffffff808467d3 in tcp_setpersist (tp=) at > /usr/src/sys/netinet/tcp_output.c:1619 > 1619 panic("tcp_setpersist: retransmit pending"); > (kgdb) list > 1614 int t = ((tp->t_srtt >> 2) + tp->t_rttvar) >> 1; > 1615 int tt; > 1616 > 1617 tp->t_flags &= ~TF_PREVVALID; > 1618 if (tcp_timer_active(tp, TT_REXMT)) > 1619 panic("tcp_setpersist: retransmit pending"); > 1620 /* > 1621 * Start/restart persistance timer. > 1622 */ > 1623 TCPT_RANGESET(tt, t * tcp_backoff[tp->t_rxtshift], > > I have debug.ktr.entries set to 204800 on the machines compiled with KTR > options, maybe a bit more history can provide some extra context. > > Jason > Picked up a KTR dump with 52k entries spin lock 0xffffffff81262d00 (callout) held by 0xfffff81074dde000 (tid 100289) too long (kgdb) tid 100289 [Switching to thread 241 (Thread 100289)]#0 0xffffffff80a71dc8 in cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 1432 savectx(&stoppcbs[cpu]); (kgdb) bt #0 0xffffffff80a71dc8 in cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 #1 0xffffffff80a71d8f in ipi_nmi_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1417 #2 0xffffffff80a8038a in trap (frame=0xffffffff811ef130) at /usr/src/sys/amd64/amd64/trap.c:190 #3 0xffffffff80a67ae3 in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:505 #4 0xffffffff8070d6fe in callout_process (now=1461472573876317) at /usr/src/sys/kern/kern_timeout.c:490 http://nitrology.com/ktrdump-spinlock2.txt Jason From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 06:20:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA05296A; Tue, 14 Oct 2014 06:20:24 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05B89C01; Tue, 14 Oct 2014 06:20:23 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id u10so7451351lbd.20 for ; Mon, 13 Oct 2014 23:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h/00Fi3hbfn+R5Vh5uhuiiNM3cR5WItIfJ800ZEMzuo=; b=lyZr0c7qG2IAmLY5iLBcLYQEom948wzLDISQcJXOGwRKu9vE8FdZRrKsv1uP2xt+h6 ePpTEW9amgduszHze3IsWdUqNm4/n0JzcXKhx2IF/JULHKlxlRz9EqQvEqXGS/XgCnXb 7h5xjGSKMKtnR34H69CivHaSnbI3hbsrMxHMjLjABVpRl9TfIHOlY/w4taid6gEx+6eZ 5IND8NplU+rFDTg67Rqw12oRD3Xr3xPLImh1pgOegwN8u+1pkMfIz4/7ZL7oRiZ3cIUf 3nI7FWXZrK/lCZcg4FCPEtRBpGFdVQ3XMSI4wv1QQC8pfdtiFyfDqAGhGfV3Utwvhv5i VNzg== MIME-Version: 1.0 X-Received: by 10.152.198.166 with SMTP id jd6mr2969525lac.81.1413267621921; Mon, 13 Oct 2014 23:20:21 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Mon, 13 Oct 2014 23:20:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 23:20:21 -0700 X-Google-Sender-Auth: VxNfv0aztQ3UC_s85B6VuD95lHI Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 06:20:25 -0000 On Sat, Oct 11, 2014 at 1:20 PM, Alexander V. Chernikov wrote: > > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > > > Hi, > > > > What action items are left to enable VIMAGE by default for FreeBSD 11? > Are there any tests results showing performance implications on different > network-related workloads? > > Alexander, Do you have a testbed where you could run a quick network test for non-virtualized workload: -> CURRENT without VIMAGE in kernel config -> CURRENT with VIMAGE in kernel config and provide some results ? -- Craig From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 09:45:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65C2E20F; Tue, 14 Oct 2014 09:45:08 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27C6A16A; Tue, 14 Oct 2014 09:45:08 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id fp1so7117858pdb.25 for ; Tue, 14 Oct 2014 02:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8UYiVK9NGcyN9eSODq9bZl1VNKe0w+VQ3TrvF7xHFE0=; b=dHMQFzEk9eK8VvwzpB2BoK93rkgE4PWsj/QCC5TfFLHKJGm9JkVkxgsJA+Zi3nCUvE z/t6G8nmkBjRRbKOZlmF1AIy8MuL2lfg0Yzaz6x477fhh9JTtoHhxTnIt2/XidL7eHAx yVqMQFo7TENzzrxihIOqaY/4nfwNtov7cbRy1HGVaC1FTltBJVjM4ZQK33BUBfekGRFJ UQYrQIb4/2dC96UAC+ackI4Y/bA2JM0VwOsHKAWl/Slvc0VKQl6xFLQNEGrICWbSRvq0 ThpEsfNgOzdiBRvb2W4RIBSjTVRoDOofeXNItqGi3l4UjvfWX2EL35I5CxAyQS66hH5h 649w== X-Received: by 10.68.248.40 with SMTP id yj8mr4333419pbc.58.1413279907665; Tue, 14 Oct 2014 02:45:07 -0700 (PDT) Received: from kmatoMacBook-Pro.local ([221.234.44.207]) by mx.google.com with ESMTPSA id ah2sm13795472pad.10.2014.10.14.02.45.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Oct 2014 02:45:07 -0700 (PDT) Message-ID: <543CF09D.8060307@gmail.com> Date: Tue, 14 Oct 2014 17:45:01 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Bjoern A. Zeeb" , Yamagi Burmeister Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> In-Reply-To: <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , FreeBSD Net , freebsd-virtualization@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 09:45:08 -0000 在 14-10-13 0:38, Bjoern A. Zeeb 写é“: > > On 12 Oct 2014, at 16:25 , Yamagi Burmeister wrote: > >> Hello, >> it's been a while since I tested VIMAGE, but at the last time somewhere >> in 10-CURRENT some UMA memory leaks were left when destroying vnets. >> They weren't showstoppers for most workloads, but pretty anoying... >> Have those been fixed? > > No, an old perforce branch of mine had all but the last TCP ones fixed. The code is still there. > Did you mean it's still leaked with TCP services, eg. HTTP ? Simon From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 12:54:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA2A7568; Tue, 14 Oct 2014 12:54:16 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC38F9B6; Tue, 14 Oct 2014 12:54:15 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi2so10033270wib.3 for ; Tue, 14 Oct 2014 05:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=moxtoELEe9C5snqJDIprkADyEPWkKD1WmGdefwrABMI=; b=hp5f75mvRhaaCFaVyhSX1l6VpxVHKJbRilkHZZok40Gdx9dxLbtGzVohS4KAmW9HrJ /YA92j0uR1+PTC8hPkSBNchfxOIHKypsmbC0OqbTmLI6PyYq/VfwJIK+gn/sy8DfDD3j M3eQ/AecaaTGpWDXfmJl5m64ynBi1ygx8ehMQvgSygv6WRBiKdpr6jSLamQV+wUu8EZ6 CNpBHwWCFm3OEbDCPY8u5mrGzDRWlkPRo16q+qWHw6Lf95TpK08IccpTP0cC2jSEwPtF IzwyaSYVGEuhJReFQczMXzezLt+p60OvXviLdJB8uhqG+96Eb3kH0tLIQRaAorZh1Hs+ aUww== X-Received: by 10.194.189.82 with SMTP id gg18mr2425936wjc.115.1413291254023; Tue, 14 Oct 2014 05:54:14 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.164.73 with HTTP; Tue, 14 Oct 2014 05:53:53 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 14 Oct 2014 14:53:53 +0200 X-Google-Sender-Auth: BFIwsLFn_vSaWlnJG5ku-1t8pRQ Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? To: Craig Rodrigues Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , "Alexander V. Chernikov" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 12:54:16 -0000 On Tue, Oct 14, 2014 at 8:20 AM, Craig Rodrigues wrote: > On Sat, Oct 11, 2014 at 1:20 PM, Alexander V. Chernikov > wrote: > > > > > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > > > > > Hi, > > > > > > What action items are left to enable VIMAGE by default for FreeBSD 11? > > Are there any tests results showing performance implications on different > > network-related workloads? > > > > > Alexander, > > Do you have a testbed where you could run a quick network test for > non-virtualized workload: > -> CURRENT without VIMAGE in kernel config > -> CURRENT with VIMAGE in kernel config > > and provide some results ? > I can use my forwarding/firewalling 10Giga lab for testing VIMAGE impact. Here are my ministat results (smallest packet size, value in packet-per-second, about 2000 flows). => I didn't see lot's of performance impact with VIMAGE option added in kernel. Forwarding difference : x forwarding.r272978-VIMAGE + forwarding.r272978 +----------------------------------------------------------------------+ |x +x x ++ + x x +| | |_____________________M__A________________________| | | |____________M____A________________| | +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1929165 1998339 1963904 1966801.4 27506.256 + 5 1953943 2005868 1971503 1976523 19087.721 No difference proven at 95.0% confidence ipfw-statefull difference: x ipfw-statefull.r272978-VIMAGE + ipfw-statefull.r272978 +----------------------------------------------------------------------+ | x x * * + x+ +| ||_________MA__________| | | |_______________M_______A_______________________| | +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1490042 1531750 1503590 1505175 16403.596 + 5 1502719 1589778 1517320 1529871.8 35404.181 No difference proven at 95.0% confidence pf-statefull difference: x pf-statefull.r272978-VIMAGE + pf-statefull.r272978 +----------------------------------------------------------------------+ |x + + x x *+ x +| | |__________________A____M_____________| | | |____________________A_M_________________| | +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1315594 1341130 1334215 1331310 9769.922 + 5 1324108 1351078 1336257 1335044.2 10562.448 No difference proven at 95.0% confidence Regards From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 15:42:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46729506; Tue, 14 Oct 2014 15:42:38 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AED0FDD2; Tue, 14 Oct 2014 15:42:37 +0000 (UTC) X-AuditID: 12074425-f79e46d000002583-55-543d4465f49c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D7.DE.09603.5644D345; Tue, 14 Oct 2014 11:42:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9EFgSRv013806; Tue, 14 Oct 2014 11:42:29 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9EFgQ0f013460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Oct 2014 11:42:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9EFgPni016119; Tue, 14 Oct 2014 11:42:25 -0400 (EDT) Date: Tue, 14 Oct 2014 11:42:25 -0400 (EDT) From: Benjamin Kaduk To: =?ISO-8859-15?Q?Olivier_Cochard-Labb=E9?= Subject: Re: Enabling VIMAGE by default for FreeBSD 11? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrJvmYhti8J7TYvb0aUwWH3a0M1nM uvmVyeLZ1mYWBxaPaV9yPGZ8ms8SwBTFZZOSmpNZllqkb5fAlbH13F7mgu1sFZcmNbI0MK5l 7WLk5JAQMJGYtucgO4QtJnHh3nq2LkYuDiGB2UwSe5dfYIRwNjJK/GiYAtYhJHCISeJ/QwSE 3cAo0XSdD8RmEdCWOLtwCyOIzSagIjHzzUY2EFtEwEniy4957CCDmAXWM0o8b9wOlhAWMJeY 0v8SbCinQKDEgoOLwM7gFXCUWHntDtQZ3UwS628/AysSFdCRWL1/CgtEkaDEyZlPgGwOoKmB EjunaE5gFJyFJDMLIQMSZhbQlXiz6iAThK0tcf9mG9sCRpZVjLIpuVW6uYmZOcWpybrFyYl5 ealFuhZ6uZkleqkppZsYQYHO7qK6g3HCIaVDjAIcjEo8vAWRNiFCrIllxZW5hxglOZiURHlL jG1DhPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwKnAA5XhTEiurUovyYVLSHCxK4rybfvCFCAmk J5akZqemFqQWwWRlODiUJHgDnIEaBYtS01Mr0jJzShDSTBycIMN5gIZLgdTwFhck5hZnpkPk TzHqcrQ0ve1lEmLJy89LlRLnPeUEVCQAUpRRmgc3B5agXjGKA70lzCsDMooHmNzgJr0CWsIE tOR1sTXIkpJEhJRUA+NJbv9JC0o2dG86USdeuOrdE6sFUcHXLa1yzfhdCyWvLrtRbRJ5fp5z 2uYjstcbxMqFzT+Ja8dZMWx/md1rfzDkTuxXtsS3Wr3f1x31U1QWfK8wxcWk79GORr9JTwTX eyf+rImV6HhW0SL1TeSkSZtx8QbbOgn7/fZm7145n/qvGv9U+vdOSyWW4oxEQy3mouJEAB7O B8wrAwAA Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 15:42:38 -0000 On Tue, 14 Oct 2014, Olivier Cochard-Labb=E9 wrote: > I can use my forwarding/firewalling 10Giga lab for testing VIMAGE impact. > Here are my ministat results (smallest packet size, value in > packet-per-second, about 2000 flows). > =3D> I didn't see lot's of performance impact with VIMAGE option added in > kernel. Surely we would also want to test on some "low-end" networks as well ... we still have some 10/half networks here (luckily, nowhere that I frequent). -Ben From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 18:17:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B910829E for ; Tue, 14 Oct 2014 18:17:51 +0000 (UTC) Received: from eastrmfepo101.cox.net (eastrmfepo101.cox.net [68.230.241.213]) by mx1.freebsd.org (Postfix) with ESMTP id 60F1FF2 for ; Tue, 14 Oct 2014 18:17:51 +0000 (UTC) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo101.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20141014181750.FTVU5255.eastrmfepo101.cox.net@eastrmimpo210> for ; Tue, 14 Oct 2014 14:17:50 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo210 with cox id 36Hp1p00K41obj4016Hp1S; Tue, 14 Oct 2014 14:17:49 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020205.543D68CE.0025,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=aZC/a2Ut c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=9cW_t1CCXrUA:10 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=kviXuzpPAAAA:8 a=6I5d2MoRAAAA:8 a=M50rKQ7feiKH07HconkA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <543D68BF.40707@cox.net> Date: Tue, 14 Oct 2014 14:17:35 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1wLg1p00d2X408g01wLiUx> In-Reply-To: <1wLg1p00d2X408g01wLiUx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 18:17:51 -0000 Alexander V. Chernikov wrote: > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > >> Hi, >> >> What action items are left to enable VIMAGE by default for FreeBSD 11? > Are there any tests results showing performance implications on different network-related workloads? >> Not everyone uses bhyve, so VIMAGE is quite useful when using jails. >> >> -- >> Craig >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > i know little about chroot jails or 7 ring processor levels but let me ask rhetorically ... do you mean VIMAGE allows a jail to use an iface device for many IPs or even MAC? i thought that was already the case all cards can "listen" - it's only a headers trick per say. but do you mean a chroot can have access to an iface (which there are pkg for setting up if i remember)? but if a jail is allowed to use an iface why not allocate it - meaning: what is the purpose of middleman vimage connecting device to jail unless there is a strict filter inbetween (ie, strippign headers, or even controlling what iface/routes are alllowed)? i can't see what it's for, but much less making it mandatorily injected upon all jailsm, except maybe it may BREAK existing jails by allowing net access where there is NOT supposed to be any / assumed not to be any if they old programmers didn't want anyone compiling software who logged in: they'd insure there was no compiler. if they didn't want typing at a terminal: they'd take away the keyboard right? From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 19:45:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8D7BE6A for ; Tue, 14 Oct 2014 19:45:11 +0000 (UTC) Received: from eastrmfepi101.cox.net (eastrmfepi101.cox.net [68.230.241.197]) by mx1.freebsd.org (Postfix) with ESMTP id 7809DC82 for ; Tue, 14 Oct 2014 19:45:11 +0000 (UTC) Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo103.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20141014183002.PVWI31158.eastrmfepo103.cox.net@eastrmimpo109> for ; Tue, 14 Oct 2014 14:30:02 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo109 with cox id 36W11p00R41obj4016W2Vc; Tue, 14 Oct 2014 14:30:02 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020203.543D6BAA.0111,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=Y70mRGiN c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=9cW_t1CCXrUA:10 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=kviXuzpPAAAA:8 a=6I5d2MoRAAAA:8 a=DZU4-uSclzPVfhO6uPUA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <543D6B9B.2010505@cox.net> Date: Tue, 14 Oct 2014 14:29:47 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1wLg1p00d2X408g01wLiUx> In-Reply-To: <1wLg1p00d2X408g01wLiUx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 19:45:11 -0000 Alexander V. Chernikov wrote: > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > >> Hi, >> >> What action items are left to enable VIMAGE by default for FreeBSD 11? well the next step is to make it a dependancy so that free bsd won't install without it, and to inject it in many binaries that insure it's "in use". like ssh ! the key is: 98 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C just change anything you don't like in any jails being upgraded and tada you may get what's protected! can i have some? From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 20:01:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40AB144A; Tue, 14 Oct 2014 20:01:26 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63C6CE53; Tue, 14 Oct 2014 20:01:25 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gi9so9076321lab.21 for ; Tue, 14 Oct 2014 13:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8tt9U4er2WE7Elavzxa0XSEoZRYieb2Qu/2tRGI0ULI=; b=JCSaUQSUGpht5kA+AQ3s49tM0q3Tm4pY8HA4f8ygkKps37sPbC5cCRgEfYIAcU4bON vzM3frRcYFcm7ArmfmuYcejjPuhTGfGcJyPokQTimSftlnPXWPr8+flh3ea/qAGHcZzH gOJ19KtC/VHyFg7cdFJNRjwpjtaCjE/OZu6+5WXB/r9inv65VcjPVX08rY7B4LVfAyK1 ibWCLjqUS8V7xpjnvJdbOa77fBene+h/dr61Xu5/Pee/41DcDjklO0DekT8BBDkg4X/v Tp7Pwoj3A4Q3bjtJqqP8cpt1wNRjcJpz2qddENUlrGUNnqmUniozEKO0ewRJLR/jATU7 lTKA== MIME-Version: 1.0 X-Received: by 10.152.7.7 with SMTP id f7mr7525494laa.57.1413316883303; Tue, 14 Oct 2014 13:01:23 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Tue, 14 Oct 2014 13:01:23 -0700 (PDT) In-Reply-To: <543D68BF.40707@cox.net> References: <543D68BF.40707@cox.net> Date: Tue, 14 Oct 2014 13:01:23 -0700 X-Google-Sender-Auth: NI0wY57cHsYYMZeRPLTEHjeB-yE Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: johnandsara2@cox.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 20:01:26 -0000 On Tue, Oct 14, 2014 at 11:17 AM, John D. Hendrickson and Sara Darnell < johnandsara2@cox.net> wrote: > do you mean VIMAGE allows a jail to use an iface device for many IPs or > even MAC? i thought that was already the case all cards can "listen" - > it's only a headers trick per say. > > Search for VIMAGE here: https://www.freebsd.org/cgi/man.cgi?query=jail That gives a pretty good description of what VIMAGE and jails can do. -- Craig From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 21:27:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D37F8E2 for ; Tue, 14 Oct 2014 21:27:15 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 720F498A for ; Tue, 14 Oct 2014 21:27:15 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq14so8596406pab.40 for ; Tue, 14 Oct 2014 14:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type; bh=CuXw0poUl+JZ5BzI03CX91KFqJmDYSsgcczIPExS4R0=; b=iEuhpueqeFb/ZCFl/uALxcVtj6+oSTLzlXK1wULz/02GX09DNrj1n841M8Eb8B+txv 6yoU3Kfkd/NIBnrvVx2X+uupkD6ESBbOyusRSe+yb3T0cUg2/LHzHsjsr95v3QCwvICv g0X18xUOJzpqmQyxihWTXAgpQegqr0N1zUQI3xJMUVz9rvy5O5TSwSKWzkVu28jE2Cor 7RJ0xmKxLjTEMQzz9zPsZl6mkv2hzle81DixNzeoKRtlwvWlItS8eawifNHObQZj6TB8 MOwk149XrjNDuCUKPvtiRjkSgpCmnyPsH3lQN4yn5xXoglY8vbqsjH4evlEJPVD61dnk oa3Q== X-Received: by 10.68.57.232 with SMTP id l8mr7563821pbq.113.1413322035011; Tue, 14 Oct 2014 14:27:15 -0700 (PDT) Received: from Andreys-MacBook-Pro.local (cpe-75-84-223-30.socal.res.rr.com. [75.84.223.30]) by mx.google.com with ESMTPSA id nd6sm15083393pbc.28.2014.10.14.14.27.13 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 14 Oct 2014 14:27:13 -0700 (PDT) Date: Tue, 14 Oct 2014 14:27:11 -0700 From: Andrey Cherkashin To: freebsd-net@freebsd.org Message-ID: Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support X-Mailer: Airmail (249) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 21:27:15 -0000 Just wanted to say that with that patch it works on 10.1 with E2200. =5B =C2=A03=5D =C2=A00.0-10.0 sec =C2=A01.07 GBytes =C2=A0 923 Mbits/sec --=C2=A0 Andrey Cherkashin Sent with Airmail From owner-freebsd-net@FreeBSD.ORG Tue Oct 14 22:57:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6390EAFD for ; Tue, 14 Oct 2014 22:57:33 +0000 (UTC) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCAD338E for ; Tue, 14 Oct 2014 22:57:32 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 20115 invoked from network); 14 Oct 2014 23:57:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1413323849; bh=chgSaRG3P868xzU72GFUSFR8iF9GH4HRRvezqjA2alg=; h=From:To:Subject; b=JLcEODiQcVgCA+jqLHBnmrX7ORQfKUqy75a1KIXiGZolxpRhr497xOhw2I0W2f0sR 5Rv4/x/rRtSFdgi0RNoRz252vPRs2bfvQQtwL3UOfmlpKZSJCE69Vqh0L7qBSEGh4w gYU9xZx5L1S4rOYbOdcxJLXDZzyH6A78/kBui830= Received: from 250-210-250-178.ftth.cust.kwaoo.net (HELO [10.0.5.13]) (marek_sal@[178.250.210.250]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES128-SHA encrypted SMTP for ; 14 Oct 2014 23:57:29 +0200 Message-ID: <543D9C48.3010907@wp.pl> Date: Tue, 14 Oct 2014 23:57:28 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Multicast routing, IGMP, IPTV doubts.. Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [8aOU] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 14 Oct 2014 22:57:33 -0000 Hi all, My home router is small FreeBSD 10 box, with 3 ethernet ports, I use pf as a firewall. My ISP provides FTTH, that ends at my home with a small box called CPE. The CPE contains 4 ethernet ports. On one port I have Internet access, on the other there is IPTV (that's based on udp/multicast) The IPTV works well - when I connect directly my PC to IPTV ethernet socket - I can watch TV. But I would like to have both Internet and IPTV on my desktop at the same time. I've downloaded the igmpproxy package, set up config: quickleave # IPTV interface phyint re2 upstream ratelimit 0 threshold 1 altnet 10.0.0.0/8 altnet 192.168.0.0/16 # LAN interface , bridge0 as it's re0+wlan0 phyint bridge0 downstream ratelimit 0 threshold 1 # Internet access interface phyint re1 disabled I've also loaded the ip_mroute module into kernel: 10 1 0xffffffff81aa7000 cd91 ip_mroute.ko And enabled UDP traffic in PF: IPTV="re2" int_if="bridge0" # IPTV pass in on $IPTV inet proto udp from any to any pass on {$int_if, $IPTV} proto igmp allow-opts Unfortunately after starting igmpproxy: # igmpproxy -d -vv igmpproxy.conf the igmpproxy starts but can't build routing table: Current routing table (Age active routes): ----------------------------------------------------- No routes in table... ----------------------------------------------------- received packet from 10.66.255.248 shorter (32 bytes) than hdr+data length (24+32) received packet from 10.66.255.248 shorter (32 bytes) than hdr+data length (24+32) received packet from 10.66.255.248 shorter (32 bytes) than hdr+data length (24+32) Do you have any idea how should I configure my box to be able to route the IPTV traffic? Regards, Marek -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 00:12:31 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCE38597 for ; Wed, 15 Oct 2014 00:12:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B389DCB8 for ; Wed, 15 Oct 2014 00:12:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9F0CV5Q025328 for ; Wed, 15 Oct 2014 00:12:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Wed, 15 Oct 2014 00:12:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: priority Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 00:12:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 Garrett Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |Normal --- Comment #4 from Garrett Cooper --- (In reply to Garrett Cooper from comment #3) > We don't yet. This was a recently discovered issue on a driver that isn't > available in HEAD yet... Note: This bug is only harmful if you modify any of the structures that comprise `struct mbuf` as the observation hasn't been violated on FreeBSD CURRENT [yet]. Isilon runs into this issue because we add additional fields to track mbufs. Status update: Isilon is waiting for a fix from upstream (Intel); we will work with Intel to get the fix tested and pushed into FreeBSD. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 00:14:15 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF79C6C9 for ; Wed, 15 Oct 2014 00:14:15 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 960C6CDD for ; Wed, 15 Oct 2014 00:14:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9F0EF4r085765 for ; Wed, 15 Oct 2014 00:14:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Wed, 15 Oct 2014 00:14:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 00:14:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #5 from Garrett Cooper --- (In reply to Garrett Cooper from comment #4) > `struct mbuf` as the observation hasn't been violated on FreeBSD CURRENT "as the observation hasn't" -> "; the conditions for the optimization to work haven't" -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 01:15:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D892CC21; Wed, 15 Oct 2014 01:15:37 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03668216; Wed, 15 Oct 2014 01:15:36 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so195630lam.4 for ; Tue, 14 Oct 2014 18:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gniovpb+640oYP5W/LcbtRBqtR9VtdhkpmPtjdPwTEU=; b=Rf3FZ1T8YUMZH+V51uRylLjjSNGAJcdH6tdYaiSEF+cAjcBSsyZUTL0l5GruJ/c5hA YB2AcH/IsYODLio6REdovx8uPRMYRlDQsinoDtjGeSH5E595fxHtGUOwbqdEdLBR+5U8 EiQbTEYtU/zIMN4BLmtL7MTYlDi/XT99LIt5YpD6IMrxc7N0kD1IWcy4Fl/PUmoF2lg0 T+bIpJV6mnBBMBm6ZHYlPtZpTcbpUVqPYYBiYhowWnkax/+tx0Jo0Saou9j7EjL9pZ4n xBLuKplcACY9Q8z5PPT1La5iOH+5prBZk7fJB6gRSgzt9JsTOJfElniae68n27YJWpoD 20Mw== MIME-Version: 1.0 X-Received: by 10.112.148.161 with SMTP id tt1mr8952985lbb.67.1413335734862; Tue, 14 Oct 2014 18:15:34 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Tue, 14 Oct 2014 18:15:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Oct 2014 18:15:34 -0700 X-Google-Sender-Auth: S6xN5BH9lpD1Wapt7RT8nXx-0ik Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , "Alexander V. Chernikov" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 01:15:38 -0000 On Tue, Oct 14, 2014 at 5:53 AM, Olivier Cochard-Labb=E9 wrote: > > I can use my forwarding/firewalling 10Giga lab for testing VIMAGE impact. > > Thank you for doing the test and providing the results. You put some good work into making those graphs and explaining the results! -- Craig From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 09:20:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0268A2FA for ; Wed, 15 Oct 2014 09:20:53 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 906218A9 for ; Wed, 15 Oct 2014 09:20:52 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi2so12357683wib.9 for ; Wed, 15 Oct 2014 02:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=8kOSMbIVzJ+yQEdQNx12Kzg1dlZqJmd/iOvHh/aOEVQ=; b=x5FtQdrSKWQtvyEoK3XD1EZXoH6ZBR/egOCi9uMq7nl1BcXsiqyhcL2pd5T8AoVA+G rbAHiWm0m1eyvd5wBSnnSkA1NoUiEi6Av2EIH1Z4QqEYIPPYhcslN8eH+qRi3YXpRIb6 tq5Gmvcjzu2uzSI/cYpPDloPL7OZq0sU7YSv2Oi3prr0/ZoCgscM7JX9/oIN1OlHNVST 6RpTAAj82B+R3vuOetg38eoa+PPmvcvjKIG7d0/UzFevz9tE0B4QrPui8xXx4RCQrq5j Glhb2GYPNad06HOk85w95dEdDj3/KxWzBC4TCK5IIKZ/GeugBEpCbUbDN9Q2TT+nXRCU wA+A== X-Received: by 10.194.189.82 with SMTP id gg18mr1558213wjc.115.1413364850933; Wed, 15 Oct 2014 02:20:50 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.164.73 with HTTP; Wed, 15 Oct 2014 02:20:30 -0700 (PDT) In-Reply-To: <543D9C48.3010907@wp.pl> References: <543D9C48.3010907@wp.pl> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 15 Oct 2014 11:20:30 +0200 X-Google-Sender-Auth: m1q9pFxv5NX00emCb6sP-MlmAfc Message-ID: Subject: Re: Multicast routing, IGMP, IPTV doubts.. To: Marek Salwerowicz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 09:20:53 -0000 On Tue, Oct 14, 2014 at 11:57 PM, Marek Salwerowicz wrote: > > Unfortunately after starting igmpproxy: > > # igmpproxy -d -vv igmpproxy.conf > > the igmpproxy starts but can't build routing table: > Current routing table (Age active routes): > ----------------------------------------------------- > No routes in table... > ----------------------------------------------------- > received packet from 10.66.255.248 shorter (32 bytes) than hdr+data length > (24+32) > received packet from 10.66.255.248 shorter (32 bytes) than hdr+data length > (24+32) > received packet from 10.66.255.248 shorter (32 bytes) than hdr+data length > (24+32) > > > Do you have any idea how should I configure my box to be able to route the > IPTV traffic? > Oops... this ports wasn't adapted to SOCK_RAW changes brings in FreeBSD 10. I will try to fix it. Regards, From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 09:41:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 069299F7 for ; Wed, 15 Oct 2014 09:41:43 +0000 (UTC) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61CAAB3D for ; Wed, 15 Oct 2014 09:41:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id BA4D6B61D497; Wed, 15 Oct 2014 11:41:33 +0200 (CEST) Date: Wed, 15 Oct 2014 11:41:33 +0200 (CEST) From: elof2@sentor.se To: John-Mark Gurney Subject: Re: Unable to kill a non-zombie process with -9 In-Reply-To: <20141009222926.GC1852@funkthat.com> Message-ID: References: <20141009222926.GC1852@funkthat.com> 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 , snort-devel mailinglist X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 09:41:43 -0000 Hi! Today the problem reoccurred. I've now debugged the problem a little furter. I'm starting snort (as root). <<>> Oct 15 08:46:59 snort[22646]: Initializing daemon mode Oct 15 08:46:59 snort[22648]: Daemon initialized, signaled parent pid: 22646 Oct 15 08:46:59 snort[22648]: Reload thread starting... Oct 15 08:46:59 snort[22648]: Reload thread started, thread 0x8146e8800 (22648) End of log. Error! Nothing more happens with the snort process! Normally it should continue and log these lines as well: snort[nnn]: Decoding Ethernet snort[nnn]: Checking PID path... snort[nnn]: PID path stat checked out ok, PID path set to /var/run/ snort[nnn]: Writing PID "7627" to file "/var/run//snort_mon0.pid" snort[nnn]: Chroot directory = /usr/foobar/log snort[nnn]: Set gid to 100 snort[nnn]: Set uid to 100 snort[nnn]: snort[nnn]: --== Initialization Complete ==-- snort[nnn]: Commencing packet processing (pid=nnn) When looking at this half-started snort process with 'ps', it looks like this: ps faxulwwj 22648 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 The process is still owned by root, so just as the missing log lines are saying, it has not yet performed any change of uid/gid. So there seem to be two questions. Q1) What happens between "Reload thread started, thread 0x8146e8800 (22648)" and "Decoding Ethernet"? Apparently something goes wrong here on FreeBSD 10.0. (this problem does not always occur, sometimes snort start just fine) Q2) When the process has frozen in this half-started state, it can't be killed even with a -9. Why? John-Mark asked me for some debugging info. Here it is: I now run 'kill 22648' on the above semi-started process: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 new root 22648 52.3 1.1 488552 179344 - Rs 8:46AM 53:36.48 /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 No change. kill -9 22648 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 new root 22648 37.7 1.1 488552 179344 - Ts 8:46AM 53:50.87 /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 Less CPU-usage and STAT changed to "Ts". kill -CONT 22648 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 new root 22648 0.0 1.1 488552 179344 - Ts 8:46AM 53:50.88 /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 No change except cpu is down to 0. I now start 'kgdb' info threads I found two threads for snort, doing a bt for both of them: 372 Thread 100602 (PID=22648: snort) sched_switch (td=0xfffff802c061f490, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1962 371 Thread 100598 (PID=22648: snort) sched_switch (td=0xfffff80221857000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1962 thread 372 [Switching to thread 372 (Thread 100602)]#0 sched_switch (td=0xfffff802c061f490, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1962 1962 in /usr/src/sys/kern/sched_ule.c bt #0 sched_switch (td=0xfffff802c061f490, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1962 #1 0xffffffff808b8c1e in mi_switch (flags=266, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:494 #2 0xffffffff808c04b0 in thread_suspend_switch (td=0xfffff802c061f490) at /usr/src/sys/kern/kern_thread.c:883 #3 0xffffffff808c0276 in thread_single (mode=1) at /usr/src/sys/kern/kern_thread.c:713 #4 0xffffffff8087c1bb in exit1 (td=0xfffff802c061f490, rv=9) at /usr/src/sys/kern/kern_exit.c:180 #5 0xffffffff808b2faf in sigexit (td=, sig=) at /usr/src/sys/kern/kern_sig.c:2935 #6 0xffffffff808b3669 in postsig (sig=) at /usr/src/sys/kern/kern_sig.c:2822 #7 0xffffffff808f6f57 in ast (framep=) at /usr/src/sys/kern/subr_trap.c:271 #8 0xffffffff80c75870 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:416 #9 0x0000000801d6f19a in ?? () Previous frame inner to this frame (corrupt stack?) thread 371 [Switching to thread 371 (Thread 100598)]#0 sched_switch (td=0xfffff80221857000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1962 1962 in /usr/src/sys/kern/sched_ule.c bt #0 sched_switch (td=0xfffff80221857000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1962 #1 0xffffffff808b8c1e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:494 #2 0xffffffff808f2e3a in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0xffffffff80864aad in _cv_wait (cvp=0xffffffff8147a500, lock=0xffffffff8147a480) at /usr/src/sys/kern/kern_condvar.c:139 #4 0xffffffff808fb05f in vmem_xalloc (vm=0xffffffff8147a480, size0=, align=, phase=0, nocross=, minaddr=0, maxaddr=18446735286768857088, flags=8194, addrp=) at /usr/src/sys/kern/subr_vmem.c:1196 #5 0xffffffff808fae6b in vmem_alloc (vm=0x0, size=0, flags=, addrp=0xfffffe0466e1d6e8) at /usr/src/sys/kern/subr_vmem.c:1082 #6 0xffffffff80b0fa58 in kmem_malloc (vmem=0xffffffff8147a480, size=2139729920, flags=2) at /usr/src/sys/vm/vm_kern.c:314 #7 0xffffffff80b08dfb in uma_large_malloc (size=, wait=2) at /usr/src/sys/vm/uma_core.c:1006 #8 0xffffffff80898cf3 in malloc (size=2139729920, mtp=0xffffffff813a0450, flags=0) at /usr/src/sys/kern/kern_malloc.c:520 #9 0xffffffff8096307b in bpf_buffer_ioctl_sblen (d=0xfffff80159ea9000, i=) at /usr/src/sys/net/bpf_buffer.c:183 #10 0xffffffff80960a3c in bpfioctl (dev=0x0, cmd=, addr=0xfffff801fbd06b40 "", flags=0, td=0xfffff80221857000) at /usr/src/sys/net/bpf.c:408 #11 0xffffffff807ac1df in devfs_ioctl_f (fp=0xfffff8002b3d9d20, com=3221504614, data=0xfffff801fbd06b40, cred=, td=0xfffff80221857000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #12 0xffffffff808fdfae in kern_ioctl (td=0xfffff80221857000, fd=, com=0) at file.h:319 #13 0xffffffff808fdd2f in sys_ioctl (td=0xfffff80221857000, uap=0xfffffe0466e1da40) at /usr/src/sys/kern/sys_generic.c:702 #14 0xffffffff80c8f117 in amd64_syscall (td=0xfffff80221857000, traced=0) at subr_syscall.c:134 #15 0xffffffff80c7580b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #16 0x0000000801d8f08a in ?? () Previous frame inner to this frame (corrupt stack?) Let me know if I can debug this any further. /Elof On Thu, 9 Oct 2014, John-Mark Gurney wrote: > elof2@sentor.se wrote this message on Wed, Oct 08, 2014 at 13:30 +0200: >> >> I guess this is a bug report for FreeBSD 10.0. >> >> >> >> Sometimes I can't kill my snort process on FreeBSD 10.0. >> It won't die, even with kill -9. >> >> I'm not talking about a zombie process. Snort is a process that should >> die normally. >> I've run snort on over 100 nodes since FreeBSD v6.x and I've never seen >> this behavior until now in FreeBSD 10.0. >> >> >> Example: >> >> #ps faxuw >> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME >> COMMAND >> root 49222 53.4 2.2 492648 183012 - Rs 11:46AM 7:05.59 >> /usr/local/bin/snort -q -D -c snort.conf >> root 47937 0.0 2.2 488552 182864 - Ts 10:56AM 29:35.98 >> /usr/local/bin/snort -q -D -c snort.conf > > What is the MWCHAN? add l to the ps command... > >> The pid 47937 has been killed (repeatedly) with -9. >> Its status is "Ts" meaning it is Stopped. > > have you tried to kill -CONT to resume it? > >> But it won't actually die and disappear. The only way to get rid of it >> seem to be to reboot the machine. :-( >> >> (pid 49222 is the new process that was started after 47937 was killed) >> >> >> The problem doesn't happen all the time and I haven't found any patterns >> as to when it does. :-( >> If I restart snort once every day, it fails to die approximately 2-4 times >> per month. >> Even though the problem doesn't happen on every kill, it is a definately a >> recurring event. > > Can you run kgdb on the machine? (yes, it works on a live machine), use > info threads to find the thread id, and then use thread to > switch to it, and run bt to get a back trace... > >> I began to see it on a heavily loaded 10GE sensor, so I thought it could >> have something to do with the ix driver, or the heavy load. >> But now another FreeBSD 10.0-sensor had the exact same problem, and this >> sensor don't have any 10GE NICs. In fact, this sensor has been running >> just fine with both FreeBSD 9.1 and 9.3 for the past years. Snort has >> always terminated correctly! After I reinstalled this machine with FreeBSD >> 10.0 last friday, snort has then terminated correctly every day until >> today, when it failed with the above pid 47937. (this sensor use the 'em' >> driver, not 'ixgbe') >> >> I'm running snort with the same configuration, settings, version, daq, >> libs, etc on 10.0 as I do on 9.3. >> None of the 9.3 sensors have this problem, so it has to be something new >> in FreeBSD 10.0. > > -- > 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 Wed Oct 15 10:18:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 412FC2BA for ; Wed, 15 Oct 2014 10:18:08 +0000 (UTC) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF31AEC6 for ; Wed, 15 Oct 2014 10:18:07 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 2201 invoked from network); 15 Oct 2014 12:11:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1413367883; bh=PwbBnZd+H5s7MtX2qLnVRDrKw8kjJVFXD2svVkIyN4A=; h=From:To:CC:Subject; b=WhL9f+cKTIHrjRVTbTjNJkXvoG4tyJF8hwxRTQIn75AcG0n5bpEKfdSUa0Jwq4sqw Lg3rxtPhKrtFzqmpaTMl3B8UwRakz8qKqC7xGisAYPRvTAohB5gPlyyYlXMUvJOcUB uGbsPQuLw9+Rrgww5zBX8yIzlosBYiZxl/SGtdOY= Received: from pb-d-128-141-237-74.cern.ch (HELO [128.141.237.74]) (marek_sal@[128.141.237.74]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES128-SHA encrypted SMTP for ; 15 Oct 2014 12:11:23 +0200 Message-ID: <543E4847.8070204@wp.pl> Date: Wed, 15 Oct 2014 12:11:19 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: =?windows-1252?Q?Olivier_Cochard-Labb=E9?= Subject: Re: Multicast routing, IGMP, IPTV doubts.. References: <543D9C48.3010907@wp.pl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [UYPk] Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 10:18:08 -0000 W dniu 2014-10-15 o 11:20, Olivier Cochard-Labbé pisze: > Oops... this ports wasn't adapted to SOCK_RAW changes brings in FreeBSD 10. > I will try to fix it. I would be grateful ;-) Let me know if I can help in any way in debugging ? Cheers Marek -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 15:36:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4F1FBFB for ; Wed, 15 Oct 2014 15:36:05 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 769CB850 for ; Wed, 15 Oct 2014 15:36:05 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id s9FFTnF9040120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Oct 2014 16:29:49 +0100 (BST) (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 15 Oct 2014 16:29:49 +0100 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Wed, 15 Oct 2014 16:29:49 +0100 From: Matt Churchyard To: "freebsd-net@freebsd.org" Subject: Carp stuck in INIT Thread-Topic: Carp stuck in INIT Thread-Index: Ac/oisnIy7pzRtICQlegI7PCf1AzEw== Date: Wed, 15 Oct 2014 15:29:48 +0000 Message-ID: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 15:36:06 -0000 Hello, I've just been providing help on the forums to a user trying to get carp to= work with a /30 network, where only 1 address is available. Two FreeBSD routers with one of the addresses in the /30 taken by the upstr= eam ISP. Looking through the carp manpage, which seems to show an example of carp ad= dresses being used as the primary address on an interface (whereas I believ= e it had to be an alias before), I came up with the following example (with= preempt enabled in /etc/sysctl.conf): ifconfig_em0=3D"vhid 10 pass mypass 192.168.0.100/24" defaultrouter=3D"192.168.0.10" However, on boot, I got the following messages, and carp would stick foreve= r in INIT mode. (May not be word for word, written from memory) em0: promiscuous mode enabled carp: demoted by 240 to 240 (interface down) I had to down/up the interface to get it to correctly jump into master or b= ackup mode This seems to have been fixed by changing rc.conf as follows (note the up k= eyword) With this on master and backup, everything seems to work perfectly ifconfig_em0=3D"vhid 10 pass mypass 192.168.0.100/24 up" In comparison to the above messages, which were from the master booting up,= I now see the following: em0: promiscuous mode enabled carp: VHID 10@em0: INIT -> BACKUP carp: VHID 10@em0: BACKUP -> MASTER (preempting a slower master) Is this something that's known to be required, is there a problem, or is it= just because I'm testing with virtualbox? The examples on the carp man page don't use the up keyword. (By the way I realise my tests don't use a /30 network like the one I was o= riginally trying the help with, I was more interested in testing the use of= carp as the only address on a machine. If it works with a single /24 carp = address, I'd expect it to work with a single /30 carp address) Regards, Matt Churchyard From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 15:58:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E9D3484 for ; Wed, 15 Oct 2014 15:58:34 +0000 (UTC) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 382C7A9E for ; Wed, 15 Oct 2014 15:58:34 +0000 (UTC) Received: by mail-oi0-f54.google.com with SMTP id v63so1197782oia.27 for ; Wed, 15 Oct 2014 08:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=x/f+JAY4cHQqWOqcJZNomjHlZFhh/2BQh+axEHScclk=; b=dPUU5quR+pTEkwpZzrkdTcZGF010uttouGrNeb6BORhVr5grOejuzNRcS2tyHsNDVU U+uryhLtStYxhBKERMZBUKPbUEWYPKhgb4gP6v3s+j5MNAQn7UM+pkhysOu/Y7CUe4b6 UeHkyBN32mSqOTtM018YNIxMOaSRhN7NlN6H2HK+ifPgt9W0kPxII7CQGkiejvLwaAJ1 6Aql0EaFHWGyJS8qPBHu9DevMA2TYQyV1zsP0rSTwiDkj8bPbbseuUUbsOkMctMzOQtV 4yLZDNenJO/FV11ezxKi5duZQl/O6QdyGGixXvfhGDkMsZ5UysAJ3OVdgJGf+xVxcqc+ 5P7Q== MIME-Version: 1.0 X-Received: by 10.60.130.226 with SMTP id oh2mr11751338oeb.10.1413388713611; Wed, 15 Oct 2014 08:58:33 -0700 (PDT) Received: by 10.202.104.195 with HTTP; Wed, 15 Oct 2014 08:58:33 -0700 (PDT) Received: by 10.202.104.195 with HTTP; Wed, 15 Oct 2014 08:58:33 -0700 (PDT) In-Reply-To: References: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com> Date: Wed, 15 Oct 2014 08:58:33 -0700 Message-ID: Subject: Fwd: Re: Carp stuck in INIT From: Freddie Cash To: freebsd-net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 15:58:34 -0000 Forgot to include the list. ---------- Forwarded message ---------- From: "Freddie Cash" Date: Oct 15, 2014 8:57 AM Subject: Re: Carp stuck in INIT To: "Matt Churchyard" Cc: You don't need the "up" keyword, and it definitely works with a /30 and a single IP. I use that at work. But the order of options does matter (IP first, CARP stuff second). Requires FreeBSD 10 and the new CARP code. Might work on pre-10, but I never got it to work. The following is from our core fibre router: ifconfig_em0=3D"inet 142.24.243.161/30 vhid 30 pass mypass30 -lro -tso -vlanhwtso" defaultrouter=3D"142.24.243.162=E2=80=9D The slave box is the same, but with "advskew 128" added after the pass config. From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 16:46:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50763E19 for ; Wed, 15 Oct 2014 16:46:47 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EED9DF73 for ; Wed, 15 Oct 2014 16:46:46 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id s9FGkUDZ035798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 17:46:30 +0100 (BST) (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 15 Oct 2014 17:46:12 +0100 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Wed, 15 Oct 2014 17:46:12 +0100 From: Matt Churchyard To: Freddie Cash , "freebsd-net@freebsd.org" Subject: Re: Carp stuck in INIT Thread-Topic: Carp stuck in INIT Thread-Index: Ac/oisnIy7pzRtICQlegI7PCf1AzE///+zoAgAAeP+k= Date: Wed, 15 Oct 2014 16:46:11 +0000 Message-ID: <1C4FB5A0-E106-46CE-B458-21030E32CAD3@userve.net> References: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 16:46:47 -0000 Thanks for the reply I tried moving the IP address to the beginning of the ifconfig line but it = still seems to show the same error on boot and refuses to leave INIT mode. = This isn't critical as I'm just playing around with it at the moment. I'm using virtualbox to test with and a few 10.0-RELEASE vm's I've had kick= ing around for a while. I might replace them with 10.1-RC2 tomorrow and see= if I get the same thing. Matt On 15 Oct 2014, at 16:58, Freddie Cash > wrote: You don't need the "up" keyword, and it definitely works with a /30 and a s= ingle IP. I use that at work. But the order of options does matter (IP firs= t, CARP stuff second). Requires FreeBSD 10 and the new CARP code. Might work on pre-10, but I neve= r got it to work. The following is from our core fibre router: ifconfig_em0=3D"inet 142.24.243.161/30 vhid 30 pa= ss mypass30 -lro -tso -vlanhwtso" defaultrouter=3D"142.24.243.162" The slave box is the same, but with "advskew 128" added after the pass conf= ig. From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 21:48:02 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88DB9E41 for ; Wed, 15 Oct 2014 21:48:02 +0000 (UTC) Received: from bltmmd1-smtp2.cyberpointllc.com (bltmmd1-smtp2.cyberpointllc.com [199.167.112.22]) by mx1.freebsd.org (Postfix) with ESMTP id 1B736767 for ; Wed, 15 Oct 2014 21:48:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cyberpointllc.com; i=@cyberpointllc.com; q=dns/txt; s=bltmmd1; t=1413409683; x=1444945683; h=from:to:subject:date:message-id:mime-version; bh=T1vOCYmcw2U0IuKixvfyxXN72pZOA4grFVOKiQnsaUE=; b=ejxM71dFHscfXpR4yFxTTtHGLlm7gti2qTWuNNhSvOGmvewDAAMucowG x/2mfKmtLxaxhJKNeMv7Z7VSlEVdd6BdRvXA+WcPeJKyXlC1u1IkKn4rg a1AxK7alqCElqYTcciefZv9UA6ZUdU31xNMxRVgcEVCy/j4JoUFCxs6zl jPl3GHJSZdeTMHCEPZtWmhjKnJiSBuyCbQTWC/5do0zAL6mifQGB9BWw9 wcbio4xXG66+2Sghs8z1XlB0DqkUQ/dDftAbqAJtIKu7dUhCmGZ/ebYuj nBs+oU2kKaG/C4bMIg4JxL1PVjjj8tt62tq3Pe6nDf179VRZhgNLWstUe Q==; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEFAKjqPlQKAhAq/2dsb2JhbABbgkiBdct0iAKBCQEBcQuECYELAQxEMCcEIdE1AQsBH4JhjQsRAYUiBZF/ggyBUIkpg0aNJod1gXs5gQIBAQE X-IPAS-Result: AuEFAKjqPlQKAhAq/2dsb2JhbABbgkiBdct0iAKBCQEBcQuECYELAQxEMCcEIdE1AQsBH4JhjQsRAYUiBZF/ggyBUIkpg0aNJod1gXs5gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,727,1406592000"; d="p7s'?scan'208,217";a="1012729" Received: from bltmmd1-exch1.cyberpointllc.com ([10.2.16.42]) by bltmmd1-smtp2.cyberpointllc.com with ESMTP; 15 Oct 2014 21:46:52 +0000 Received: from BLTMMD1-EXCH1.cyberpointllc.com ([::1]) by bltmmd1-exch1.cyberpointllc.com ([::1]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 17:46:51 -0400 From: "Miller, Zachary" To: "net@freebsd.org" Subject: Open vSwitch FreeBSD/libpcap port Thread-Topic: Open vSwitch FreeBSD/libpcap port Thread-Index: AQHP6MGHTF6qbXXX/kCc6AAoLN8AkQ== Date: Wed, 15 Oct 2014 21:46:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.2.8.55] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3496240010_2245402" MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 21:48:02 -0000 --B_3496240010_2245402 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I saw on the website that there was an outdated port of OVS to use libpcap and FreeBSD. Due to the packet capture card that I am using I need to compile OVS to use libpcap. Is anyone aware of any more recent efforts to port more recent versions of OVS to use libpcap? Thanks, Zachary Miller If you believe you received this e-mail in error, please notify the sender immediately, delete the e-mail from your computer and do not copy or disclose it to anyone else. The information in this email constitutes the proprietary information of Cyber Point International, LLC (DBA CyberPoint), and should be accessed only by the individual to whom it is addressed. The information in this email and any attachments may not be used, copied or disclosed without the consent of CyberPoint. CyberPoint is not responsible for any damages caused by your unauthorized use of the materials in this email. --B_3496240010_2245402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR2gYJKoZIhvcNAQcCoIIRyzCCEccCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg+PMIIFfjCCBGagAwIBAgIQB1VuxV/xrUriXbQdLzk+aDANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTQw NjAyMDAwMDAwWhcNMTcwNjAyMTIwMDAwWjCBmjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1E MRIwEAYDVQQHEwlCYWx0aW1vcmUxJzAlBgNVBAoTHkN5YmVyIFBvaW50IEludGVybmF0aW9u YWwsIExMQzEXMBUGA1UEAxMOWmFjaGFyeSBNaWxsZXIxKDAmBgkqhkiG9w0BCQEWGXptaWxs ZXJAY3liZXJwb2ludGxsYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ tbmYU3drMIYbq/tZp8ejoYNq8YWPhRKROy9/G16tqtAGBekJxpx3tWa4zYrs6XFQHpD47exD LkEtlvzv42F1ebTjzUOtkWoas+49gCYP4sxoUgEsNXYDvjNWIi+favn5vPjuuTuMi8wqkBAC DikA2EBRxebG4j1MnXxfrbISkRcjl63MvDSRkU75+UnD6K1XemabBWFO4FpAqDJgA3QF68yD TNhAce2/s9TipHQE5skiOCS+roAdyULbjICwX6/RyUAt6zvBhXJ6Gl58K5KyrkCJkcS9aJ0U PjGQyUc7uvo5izCPmbwslILvBdKmkryF9ZZG4XCyp6wc8dX6yYD3AgMBAAGjggHyMIIB7jAf BgNVHSMEGDAWgBTnAiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUtY9093T9iUxQQ8V/ 25Thg0M5czUwDAYDVR0TAQH/BAIwADAkBgNVHREEHTAbgRl6bWlsbGVyQGN5YmVycG9pbnRs bGMuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw QwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRp Z2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2Vy dC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2gO6A5hjdodHRwOi8vY3Js NC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMHkGCCsGAQUF BwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUF BzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElE Q0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQAchrxMc0nrfgphDLvtThaWmlLELL0Cx4oPDCGY LX0HIrQnCVI89MuMHjfiY0h8OiltDc6jtgcP9UiZrt1JpwurI2OPrlPioDI/U2LRjyQgFoP9 zdFTQO61E8mSghDXDUkAn4rxneuuGwV+wuQTGbQxdYkKL0UKzO1tqf6//vXdMMtxylFOjBlC lRLLbKwvJEBOi8KyvStX0J1yjn9fB8qqGVgU/qVahz9dVw+4mbUkLqjJ6Utyqj9V/rLhb/xI AkpQoJa7ZqNLRGX2JeBvqVFFqkc7B5kehN7NsRQxwAm1JJpsUdTS6f4MJ7CwcjwKn3F16NE4 D6KdIwtllxN0032wMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0B AQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0Ew HhcNMTMxMTA1MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtE aWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlY H0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSa pgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0m qwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69Tv fuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4 MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYDVR0fBHoweDA6 oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdp Y2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBm ACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBl AHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQ AGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAg AGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBh AHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1Ud DgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd 823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGH MlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7Lr Jf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkI UwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlU mTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447fISpQVwTAYKI11SSeZjcJ Sc/V+GWz4OJuwjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEF BQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4X DTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoT DERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGln aUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoM gxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxH zaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCO kDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFG hvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAO BgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGL p6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEF BQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mz XeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7d YvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/ H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggIPMIIC CwIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBD QQIQB1VuxV/xrUriXbQdLzk+aDANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCC 1j1YDE060spntjijVAufFU47mdb1pYN+tm8svIlwbjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMTUyMTQ2NDlaMA0GCSqGSIb3DQEBAQUABIIBAIFX 4pyiErz33Td+AW0brCTD4/69h29cLPgwXzzqYajEZTyQ8Q6bVxXogD5SrKnK37t+gML/usPA PesTeqZuDpH5JqV7wZrv8k1aZcrBK+GVP+uckrsTcjwpG9W+a2wno2Dxl1PGmb0oVwXNvLS0 86Fee6mQDoBFckTPF22i7b/yHOUF8AAM+VQcTLc1vt+Ou+DsGh7PY5UJhE240ox+7+G5vII1 Cy+kWaL9sIceoDa+dhaTw9W2XHXeDloHZh/tmb+2/ZPEin3eGsEwc7qdntCiE7zqNIGuliTY +KHdfs4hQJSh8ZU6+CzQLVGyremKZB3MMlxMfTcRbt762hl4L/k= --B_3496240010_2245402-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 15 23:27:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2028BA3; Wed, 15 Oct 2014 23:27:32 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6DB714A; Wed, 15 Oct 2014 23:27:31 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so1852020lbi.39 for ; Wed, 15 Oct 2014 16:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d4b2jMm9SpLjoA6gpED3G3vldzmQo0SaRzksE1y7e6Y=; b=axxpx7FuBnHJZM2+4jb3COn7ajrVkSDH8z/js4IoKyelBrH21VEvPylnprLCqrDgld 2DqDKMNyX7fVviaNdJEaPxHDHOvGZNs8JxIYzGfCNIE3GlkMLGyn4v5WRJypuchqfp+E MZ5fBdWKLBe49jNdT5ZKY5tuM4CR70vrlsAqBphEoEzn3Gci1vQL0Ttqd8VSgq5Zxhuc fhZjdITWMgxTBQ0zNzSX9UdlNJ1W7Q1JkjZsEaBNHB6NwX/Z1jsCDhYqtwEXjPMT8kDi /5mWwwh+7fMRDUrMUEGK0TBUzVVOQc0r7oh7MPbSIMK/Yt2fb5o2Fq6y8Dk94/c3Bgc8 +2Zg== MIME-Version: 1.0 X-Received: by 10.112.137.39 with SMTP id qf7mr15488772lbb.47.1413415648835; Wed, 15 Oct 2014 16:27:28 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Wed, 15 Oct 2014 16:27:28 -0700 (PDT) In-Reply-To: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> Date: Wed, 15 Oct 2014 16:27:28 -0700 X-Google-Sender-Auth: h0R44h0CX15g2yxKw8riua0GXPA Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Kris Moore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Adrian Chadd , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Oct 2014 23:27:33 -0000 On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > It was for a while in 9.2, but we removed it from 10.0 and later due to > stability issues we kept getting reports about. Haven't tried it since > then, dont know if those issues are fixed. > I fixed some of the problems with VIMAGE that I encountered with Bluetooth: https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html Hiroo Onoo submitted this patch, which I committed to fix problems with VIMAGE encountered with removable USB Ethernet: https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html Martin Matuska committed this fix for PF: https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html So a lot of the stability problems with VIMAGE which were in PC-BSD 9.2 and FreeBSD 9.x have been slowly been fixed. -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 00:26:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76909C69; Thu, 16 Oct 2014 00:26:58 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97536935; Thu, 16 Oct 2014 00:26:57 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id a1so2583588wgh.9 for ; Wed, 15 Oct 2014 17:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q1uT6/T3MN4pKfArjEXd92O0dhNJey2H2BDNFXVdq4A=; b=X/JeB6B6SJ/3gjg8rsQpbJLXvMY+zElhBtuWz3wtZPdQlBzHkAdc9bq5H2WV3QygvK O2SKkgZbk7pZXA4JWVZExKaJ/nEUrfJ7dSGlGeMpVuo0O035u8dvzkgk31tjSux3gQQO YnO+GAUbsAZTTbtyFpNizqB+ALsjknE73usWs6SftXEw86rAtAUz4FJLJnvK1/eBDeBs 9EOledRqHT02AoaNWQH3LT1TACkcaN0xt9hroEjDyjOxzHO/UkDbJeNni6V1y/CVz1pB mN4F+Uo7gaGW2tT6GQ95KeBLEG7xRLwVKECg7rRfLet+ndOZej54FWVoWAjjFofjknh5 PQlg== MIME-Version: 1.0 X-Received: by 10.194.239.164 with SMTP id vt4mr6395071wjc.131.1413419215912; Wed, 15 Oct 2014 17:26:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 15 Oct 2014 17:26:55 -0700 (PDT) In-Reply-To: References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> Date: Wed, 15 Oct 2014 17:26:55 -0700 X-Google-Sender-Auth: SMVKhLB6kkJhpz-trxxSTgEfVc4 Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Adrian Chadd To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , freebsd-arch , "freebsd-virtualization@freebsd.org" , Kris Moore X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 00:26:58 -0000 Something that just popped up here in local hacking is ensuring that all the vnet state is correctly torn down _after_ the system has finished with things that reference it. For example, having the vnet state torn out from underneath say, active TCP timers that haven't yet been cleaned up. Is that fixed or not a problem in -HEAD? -a From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 07:58:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7851E606 for ; Thu, 16 Oct 2014 07:58:51 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E300A8EC for ; Thu, 16 Oct 2014 07:58:50 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so2423551lam.18 for ; Thu, 16 Oct 2014 00:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=lDp3jPNB13hRo1cL8g7vKGXZcmiV3BUOiHbYSPNlPAk=; b=SDeZcIzIHNUYfTR19qJLWyjEz80prKdi5A9Klp5Ahh8CWnPCMVEp5phJ7APRhFAs84 Dm8RHwXJZwWw8Hgk0mTf+kjTsENXMtQsTRFYJplQmWfwfKyyJFYeY1vm9ycxk/cvr2ee 9sdw/TqrVHP3ruT7cLDoMNZ9VOQMgCkIkQZZWIf37ZxuVzc9h42N9yfSwNsETVl93CrN Bzf2SOhrq4iqbLUADq+hBplDRwGr+BMiFFkNWq0UQIuVYOfMmFecTkaxGXr2fyHJ7prV YaKLcGgC4WXLTD2lQGUv9hHm/LbgbuyZFrUI5oMw6t92gH0cGGD/TrUCKW+PuDLIijHM ATZQ== X-Received: by 10.152.179.69 with SMTP id de5mr17773795lac.63.1413446328698; Thu, 16 Oct 2014 00:58:48 -0700 (PDT) Received: from [10.99.0.3] ([213.188.107.182]) by mx.google.com with ESMTPSA id jp17sm7508475lab.18.2014.10.16.00.58.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Oct 2014 00:58:48 -0700 (PDT) Message-ID: <543F7AC7.1020603@gmail.com> Date: Thu, 16 Oct 2014 09:59:03 +0200 From: Sascha User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Matt Churchyard , Freddie Cash , "freebsd-net@freebsd.org" Subject: Re: Carp stuck in INIT References: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com>, <1C4FB5A0-E106-46CE-B458-21030E32CAD3@userve.net> In-Reply-To: <1C4FB5A0-E106-46CE-B458-21030E32CAD3@userve.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 07:58:51 -0000 Hi Matt, I think I'm the user you try to help in the forum ;-). I had the same problem like you when doing the first tests with carp. The alias must be a /32 as subnet declaration. I didn't read properly the examples in the manual and Handbook. So I configured CARP as usual in FreeBSD 9. The first tries were with subnet mask from the relevant network (for example /24). This leads me into the same problem. When booting up the machine, some interfaces stuck in INIT state. A Workaround was to put them first down and then up again with ifconfig. But my router has also enabled PF and is doing Traffic Filtering. The next problem came very fast. When reloading the pf.conf traffic was blocked on all interfaces. Then I discovered in the manual all examples have a /32 subnet mask. After changing the machine boots up properly and all interfaces are in MASTER state. Also reloading pf.conf was working. Maybe you can try this: ifconfig_em0="inet vhid 10 pass mypass alias 192.168.0.100/32" On my first testing machine the configuration looks like this: ifconfig_vlan60="inet 192.168.60.253/24" ifconfig_vlan60_alias0="inet vhid 3 pass xxxxxxxx alias 192.168.60.1/32 vlan 60 vlandev lagg0" The system shows a warning message during boot when I leave the inet keyword in carp interface configuration. I believe the manual is maybe incomplete. Alls examples are without inet keyword. Maybe the warnings are wrong and could be ignored. For me it worked also with the warning but I get a bit nervous on those messages. @Freddie I had a internet connection like you with a /30 Subnet from my ISP. My interface is configured like this |ifconfig_igb0_alias0="vhid 100 advskew 0 pass Test alias x.x.67.2/32"| But then I get confused about setting up a default route Details can be found here: https://forums.freebsd.org/viewtopic.php?f=7&t=48443 But it seems that you configured your interface different like described in the manual. I'm a bit surprised that this configuration is working. regards Sascha Am 15.10.2014 um 18:46 schrieb Matt Churchyard: > Thanks for the reply > > I tried moving the IP address to the beginning of the ifconfig line but it still seems to show the same error on boot and refuses to leave INIT mode. This isn't critical as I'm just playing around with it at the moment. > > I'm using virtualbox to test with and a few 10.0-RELEASE vm's I've had kicking around for a while. I might replace them with 10.1-RC2 tomorrow and see if I get the same thing. > > Matt > > On 15 Oct 2014, at 16:58, Freddie Cash > wrote: > > > You don't need the "up" keyword, and it definitely works with a /30 and a single IP. I use that at work. But the order of options does matter (IP first, CARP stuff second). > > Requires FreeBSD 10 and the new CARP code. Might work on pre-10, but I never got it to work. > > The following is from our core fibre router: > > ifconfig_em0="inet 142.24.243.161/30 vhid 30 pass mypass30 -lro -tso -vlanhwtso" > defaultrouter="142.24.243.162" > > The slave box is the same, but with "advskew 128" added after the pass config. > _______________________________________________ > 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 Thu Oct 16 08:19:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B34D2E90 for ; Thu, 16 Oct 2014 08:19:38 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3245DBDD for ; Thu, 16 Oct 2014 08:19:37 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id s9G8JONS069311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 09:19:24 +0100 (BST) (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 16 Oct 2014 09:19:00 +0100 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Thu, 16 Oct 2014 09:19:00 +0100 From: Matt Churchyard To: Sascha , "freebsd-net@freebsd.org" Subject: RE: Carp stuck in INIT Thread-Topic: Carp stuck in INIT Thread-Index: Ac/oisnIy7pzRtICQlegI7PCf1AzE///+zoAgAAeP+mAAO5KgP//7YbA Date: Thu, 16 Oct 2014 08:18:59 +0000 Message-ID: References: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com>, <1C4FB5A0-E106-46CE-B458-21030E32CAD3@userve.net> <543F7AC7.1020603@gmail.com> In-Reply-To: <543F7AC7.1020603@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 08:19:38 -0000 HI Sascha, This example is wrong: ifconfig_em0=3D"inet vhid 10 pass mypass alias 192.168.0.100/32" As discussed in the forum (not sure if you saw the last couple of messages = before forum was taken down), if the carp address is the primary address on= the interface, it needs to use the real mask. In my case during testing th= at was a /24, but for you it should be /30. (Also the 'inet' keyword should proceed the IP address, I suspect that ifco= nfig line would be rejected entirely) There is no need at all for you to use /32! /32 is only used when the addre= ss is an alias and you already have an address configured on the interface = that is part of the same network. In your case, you are only assigning the = carp address to your interface, so you need to use /30 in the carp ifconfig= line (See Freddie's example). As confirmed by Freddie, this configuration definitely works when using a /= 30 mask, so you should have no problem configuring your systems as in Fredd= ie's example (or my example on the forum although I tested with a /24 mask = instead of /30). These configs definitely work. I still get my issue of being stuck in INIT mode on boot even after reorder= ing the options and adding the 'inet' keyword (unless I add 'up'). That cou= ld be a weird virtualbox issue though. As mentioned I'm going to try a more= recent version of FreeBSD. Note: All this applies to FreeBSD 10. I'm not even sure carp on a /30 netwo= rk is possible in earlier versions that use the old carp system. (And confi= guration of the old carp is quite different) Regards, Matt Churchyard -- Hi Matt, I think I'm the user you try to help in the forum ;-). I had the same problem like you when doing the first tests with carp. The a= lias must be a /32 as subnet declaration. I didn't read properly the exampl= es in the manual and Handbook. So I configured CARP as usual in FreeBSD 9. = The first tries were with subnet mask from the relevant network (for exampl= e /24). This leads me into the same problem. When booting up the machine, s= ome interfaces stuck in INIT state. A Workaround was to put them first down= and then up again with ifconfig. But my router has also enabled PF and is = doing Traffic Filtering. The next problem came very fast. When reloading th= e pf.conf traffic was blocked on all interfaces. Then I discovered in the m= anual all examples have a /32 subnet mask. After changing the machine boots= up properly and all interfaces are in MASTER state. Also reloading pf.conf= was working. Maybe you can try this: ifconfig_em0=3D"inet vhid 10 pass mypass alias 192.168.0.100/32" On my first testing machine the configuration looks like this: ifconfig_vlan60=3D"inet 192.168.60.253/24" ifconfig_vlan60_alias0=3D"inet vhid 3 pass xxxxxxxx alias 192.168.60.1/32 v= lan 60 vlandev lagg0" The system shows a warning message during boot when I leave the inet keywor= d in carp interface configuration. I believe the manual is maybe incomplete= . Alls examples are without inet keyword. Maybe the warnings are wrong and = could be ignored. For me it worked also with the warning but I get a bit ne= rvous on those messages. @Freddie I had a internet connection like you with a /30 Subnet from my ISP. My interface is configured like this ifconfig_igb0_alias0=3D"vhid 100 advskew 0 pass Test alias x.x.67.2/32" But then I get confused about setting up a default route Details can be found here: https://forums.freebsd.org/viewtopic.php?f=3D7&t=3D48443 But it seems that you configured your interface different like described in= the manual. I'm a bit surprised that this configuration is working. regards Sascha Am 15.10.2014 um 18:46 schrieb Matt Churchyard: Thanks for the reply I tried moving the IP address to the beginning of the ifconfig line but it = still seems to show the same error on boot and refuses to leave INIT mode. = This isn't critical as I'm just playing around with it at the moment. I'm using virtualbox to test with and a few 10.0-RELEASE vm's I've had kick= ing around for a while. I might replace them with 10.1-RC2 tomorrow and see= if I get the same thing. Matt On 15 Oct 2014, at 16:58, Freddie Cash > wrote: You don't need the "up" keyword, and it definitely works with a /30 and a s= ingle IP. I use that at work. But the order of options does matter (IP firs= t, CARP stuff second). Requires FreeBSD 10 and the new CARP code. Might work on pre-10, but I neve= r got it to work. The following is from our core fibre router: ifconfig_em0=3D"inet 142.24.243.161/30 vhid 30 pass mypass30 -lro -tso -vlanhwtso" defaultrouter=3D"142.24.243.162" The slave box is the same, but with "advskew 128" added after the pass conf= ig. _______________________________________________ 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 Thu Oct 16 08:52:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B516E85; Thu, 16 Oct 2014 08:52:02 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CD367FC9; Thu, 16 Oct 2014 08:52:01 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D7A2BC506; Thu, 16 Oct 2014 08:52:00 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 772C250BE; Thu, 16 Oct 2014 10:52:02 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Bjoern A. Zeeb" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> Date: Thu, 16 Oct 2014 10:52:02 +0200 In-Reply-To: <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> (Bjoern A. Zeeb's message of "Mon, 13 Oct 2014 01:07:55 +0000") Message-ID: <86d29so0r1.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Craig Rodrigues , freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 08:52:02 -0000 "Bjoern A. Zeeb" writes: > Also if people are seriously thinking about virtualising pf we need to > import the openbsd/apple pf fix from a few years ago because otherwise > people in virtualised stacks with a /dev/pf can do ugly things. I > think it=E2=80=99s been this one: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 There are other serious issues with our current pf (checksum corruption) which I think can only be resolved by importing a newer version. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 09:24:41 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7398EC0 for ; Thu, 16 Oct 2014 09:24:41 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 402A55FC for ; Thu, 16 Oct 2014 09:24:41 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id w7so2477735lbi.36 for ; Thu, 16 Oct 2014 02:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ps6kBSE2Ia6pnERWcQH0hBkjxGNegwQy/4OOCaEUzaE=; b=Ak2NS/wkpcPWWHg6I1jXxXBygICY71n/VUkZrG472WUQcC95RilAzG/8CAqYN9/fVi DnqAUepnZd0MMnQsgVt+9qDitfwQhjwzrNoS3SWj+EBev+qwCOXT/BmGvwGADG6AaxWN Q3ZBNOzWOhG0L6ct8ER8ZiSvtwSH2JWOB1X3m6q+SS1Q0/DkQ0cUqBCdPV7PkFuzprE7 PHwUcjFJ9cgAVd0Q6mPfHaiqT+8zWlUUokP3kU5bHeSkt37u5q0/6wY3BFlNXEriwNmp i3aalN4EmcIGEw9Mxd8EFKws8aGdIKb5XECgZnd46rjL8XbaPQ4g8d8bOGpDRF2q9RYQ w6RA== X-Received: by 10.112.169.106 with SMTP id ad10mr108024lbc.13.1413451479112; Thu, 16 Oct 2014 02:24:39 -0700 (PDT) Received: from [10.99.0.3] ([213.188.107.182]) by mx.google.com with ESMTPSA id pm3sm7572473lbb.15.2014.10.16.02.24.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Oct 2014 02:24:38 -0700 (PDT) Message-ID: <543F8EE5.5020405@gmail.com> Date: Thu, 16 Oct 2014 11:24:53 +0200 From: Sascha User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Matt Churchyard , "freebsd-net@freebsd.org" Subject: Re: Carp stuck in INIT References: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com>, <1C4FB5A0-E106-46CE-B458-21030E32CAD3@userve.net> <543F7AC7.1020603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 09:24:42 -0000 Hi Matt thanks a lot for the help! Unfortunately the Forum was down before I could read the replies. But what you said makes sense and now it is clearly for me. The new Setup is working great and now the routing table looks good. I also identified my mistake on the test machine and now I knew why I get stuck in INIT state. You're right. A /30 Subnet is only possible with CARP in Freebsd 10. Earlier versions couldn't handle that. Back to you're problem. Did you try to add something like this to rc.conf: ifconfig_em0="up" ifconfig_em0="vhid 10 pass mypass 192.168.0.100/24" defaultrouter="192.168.0.10" Did you check if advertisements are sent from the interface after booting tcpdump -npi em0 -T carp Regards Sascha > HI Sascha, > > This example is wrong: > > ifconfig_em0="inet vhid 10 pass mypass alias 192.168.0.100/32" > > As discussed in the forum (not sure if you saw the last couple of > messages before forum was taken down), if the carp address is the > primary address on the interface, it needs to use the real mask. In my > case during testing that was a /24, but for you it should be /30. > > (Also the ‘inet’ keyword should proceed the IP address, I suspect that > ifconfig line would be rejected entirely) > > There is no need at all for you to use /32! /32 is only used when the > address is an alias and you already have an address configured on the > interface that is part of the same network. In your case, you are only > assigning the carp address to your interface, so you need to use /30 > in the carp ifconfig line (See Freddie’s example). > > As confirmed by Freddie, this configuration definitely works when > using a /30 mask, so you should have no problem configuring your > systems as in Freddie’s example (or my example on the forum although I > tested with a /24 mask instead of /30). These configs definitely work. > > I still get my issue of being stuck in INIT mode on boot even after > reordering the options and adding the ‘inet’ keyword (unless I add > ‘up’). That could be a weird virtualbox issue though. As mentioned I’m > going to try a more recent version of FreeBSD. > > Note: All this applies to FreeBSD 10. I’m not even sure carp on a /30 > network is possible in earlier versions that use the old carp system. > (And configuration of the old carp is quite different) > > Regards, > > Matt Churchyard > > -- > > Hi Matt, > > I think I'm the user you try to help in the forum ;-). > > I had the same problem like you when doing the first tests with carp. > The alias must be a /32 as subnet declaration. I didn't read properly > the examples in the manual and Handbook. So I configured CARP as usual > in FreeBSD 9. The first tries were with subnet mask from the relevant > network (for example /24). This leads me into the same problem. When > booting up the machine, some interfaces stuck in INIT state. A > Workaround was to put them first down and then up again with ifconfig. > But my router has also enabled PF and is doing Traffic Filtering. The > next problem came very fast. When reloading the pf.conf traffic was > blocked on all interfaces. Then I discovered in the manual all > examples have a /32 subnet mask. After changing the machine boots up > properly and all interfaces are in MASTER state. Also reloading > pf.conf was working. > > Maybe you can try this: > > ifconfig_em0="inet vhid 10 pass mypass alias 192.168.0.100/32" > > > On my first testing machine the configuration looks like this: > > ifconfig_vlan60="inet 192.168.60.253/24" > ifconfig_vlan60_alias0="inet vhid 3 pass xxxxxxxx alias 192.168.60.1/32 vlan 60 vlandev lagg0" > > > The system shows a warning message during boot when I leave the inet > keyword in carp interface configuration. I believe the manual is maybe > incomplete. Alls examples are without inet keyword. Maybe the warnings > are wrong and could be ignored. For me it worked also with the warning > but I get a bit nervous on those messages. > > @Freddie > > I had a internet connection like you with a /30 Subnet from my ISP. > My interface is configured like this > > |ifconfig_igb0_alias0="vhid 100 advskew 0 pass Test alias x.x.67.2/32"| > > But then I get confused about setting up a default route > Details can be found here: > https://forums.freebsd.org/viewtopic.php?f=7&t=48443 > > But it seems that you configured your interface different like > described in the manual. I'm a bit surprised that this configuration > is working. > > regards > Sascha > > > Am 15.10.2014 um 18:46 schrieb Matt Churchyard: > > Thanks for the reply > > > > I tried moving the IP address to the beginning of the ifconfig line but it still seems to show the same error on boot and refuses to leave INIT mode. This isn't critical as I'm just playing around with it at the moment. > > > > I'm using virtualbox to test with and a few 10.0-RELEASE vm's I've had kicking around for a while. I might replace them with 10.1-RC2 tomorrow and see if I get the same thing. > > > > Matt > > > > On 15 Oct 2014, at 16:58, Freddie Cash > wrote: > > > > > > You don't need the "up" keyword, and it definitely works with a /30 and a single IP. I use that at work. But the order of options does matter (IP first, CARP stuff second). > > > > Requires FreeBSD 10 and the new CARP code. Might work on pre-10, but I never got it to work. > > > > The following is from our core fibre router: > > > > ifconfig_em0="inet 142.24.243.161/30 vhid 30 pass mypass30 -lro -tso -vlanhwtso" > > defaultrouter="142.24.243.162" > > > > The slave box is the same, but with "advskew 128" added after the pass config. > > _______________________________________________ > > 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 Thu Oct 16 09:41:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A36FE31F for ; Thu, 16 Oct 2014 09:41:37 +0000 (UTC) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C477827 for ; Thu, 16 Oct 2014 09:41:37 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id u20so2369843oif.14 for ; Thu, 16 Oct 2014 02:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EGKR722EVvLJmUwXuCdK8pzfOKsvwxLXs2v0qD9NfAU=; b=YKQABR9SH+P2QxDdjeTSBpCd6YMre+P+y+dghn+sPERWQN9lQtd6y0vm4rjOrv3Im3 0TxXAKFVs+EZyl/gL640oXjkW8Ur/nlLJlH5aEmd8YFhy4WK6dLoPniO/12mIJisAaoN zRbtk7IDqnydGW4YYG6Qmc9D8se9D3ftniEBO9mp2jhJ9QUTDnz5UMxz5GOeO6pVScZP 2BpuckR6WbNdXK/idaLm6fnbR04HCUdFc/8R5LBc8wjUuMbzo2EzeuGb/qxZ80WSM92F hnFZXdkZqTNRrH4hYh9jtpz09jZGtMjrx0qeRJJMtTUXSgtIBjwSqldK9G1UtLK0GH+b djOw== MIME-Version: 1.0 X-Received: by 10.60.52.229 with SMTP id w5mr69929oeo.85.1413452496812; Thu, 16 Oct 2014 02:41:36 -0700 (PDT) Received: by 10.202.104.195 with HTTP; Thu, 16 Oct 2014 02:41:36 -0700 (PDT) Received: by 10.202.104.195 with HTTP; Thu, 16 Oct 2014 02:41:36 -0700 (PDT) In-Reply-To: <543F7AC7.1020603@gmail.com> References: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com> <1C4FB5A0-E106-46CE-B458-21030E32CAD3@userve.net> <543F7AC7.1020603@gmail.com> Date: Thu, 16 Oct 2014 02:41:36 -0700 Message-ID: Subject: Re: Carp stuck in INIT From: Freddie Cash To: Sascha Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net , Matt Churchyard X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 09:41:37 -0000 FreeBSD 9 and FreeBSD 10 have very different implementations of CARP, and they are configured differently. On 9, you need to have an IP configured on the interface before you configure the shared IP, and the subnet of the shared IP is used to determine the interface to use. And there's carpX pseudo-interface created. This requires at least 3 IPs in a subnet to work correctly. On 10, CARP configuration is done directly on an interface via ifconfig and is added directly to the specified IP. You only need 1 IP for this to work correctly. There's no longer carpX pseudo-interfaces to deal with. Highly recommend using 10+ if you're using carp. From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 09:41:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7D2E3A9 for ; Thu, 16 Oct 2014 09:41:44 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F08782B for ; Thu, 16 Oct 2014 09:41:44 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id s9G9fXDq062270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 10:41:33 +0100 (BST) (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 16 Oct 2014 10:41:32 +0100 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Thu, 16 Oct 2014 10:41:32 +0100 From: Matt Churchyard To: Sascha , "freebsd-net@freebsd.org" Subject: RE: Carp stuck in INIT Thread-Topic: Carp stuck in INIT Thread-Index: Ac/oisnIy7pzRtICQlegI7PCf1AzE///+zoAgAAeP+mAAO5KgP//7YbAgAAqdYD//+vfgA== Date: Thu, 16 Oct 2014 09:41:31 +0000 Message-ID: References: <102a877d8483473bbd4a5c701c23aaa7@SERVER.ad.usd-group.com>, <1C4FB5A0-E106-46CE-B458-21030E32CAD3@userve.net> <543F7AC7.1020603@gmail.com> <543F8EE5.5020405@gmail.com> In-Reply-To: <543F8EE5.5020405@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 09:41:45 -0000 ifconfig_em0=3D"up" ifconfig_em0=3D"vhid 10 pass mypass 192.168.0.100/24" The problem with that is that rc.conf is basically just a list of variables= , so the second ifconfig_em0 entry will overwrite the first one. I'm not too bothered about my 'up' problem at the moment. I actually have n= o current requirement for carp, I was just doing some testing to see how it= worked. As I said I'll try again with 10.1 and if it's still the same I may get mor= e involved with trying to find out exactly what's going on and whether it's= a bug or not. Regards, Matt From: Sascha [mailto:kinzenator@gmail.com] Sent: 16 October 2014 10:25 To: Matt Churchyard; freebsd-net@freebsd.org Subject: Re: Carp stuck in INIT Hi Matt thanks a lot for the help! Unfortunately the Forum was down before I could read the replies. But what = you said makes sense and now it is clearly for me. The new Setup is working great and now the routing table looks good. I also= identified my mistake on the test machine and now I knew why I get stuck i= n INIT state. You're right. A /30 Subnet is only possible with CARP in Freebsd 10. Earlie= r versions couldn't handle that. Back to you're problem. Did you try to add something like this to rc.conf: ifconfig_em0=3D"up" ifconfig_em0=3D"vhid 10 pass mypass 192.168.0.100/24" defaultrouter=3D"192.168.0.10" Did you check if advertisements are sent from the interface after booting tcpdump -npi em0 -T carp Regards Sascha HI Sascha, This example is wrong: ifconfig_em0=3D"inet vhid 10 pass mypass alias 192.168.0.100/32" As discussed in the forum (not sure if you saw the last couple of messages = before forum was taken down), if the carp address is the primary address on= the interface, it needs to use the real mask. In my case during testing th= at was a /24, but for you it should be /30. (Also the 'inet' keyword should proceed the IP address, I suspect that ifco= nfig line would be rejected entirely) There is no need at all for you to use /32! /32 is only used when the addre= ss is an alias and you already have an address configured on the interface = that is part of the same network. In your case, you are only assigning the = carp address to your interface, so you need to use /30 in the carp ifconfig= line (See Freddie's example). As confirmed by Freddie, this configuration definitely works when using a /= 30 mask, so you should have no problem configuring your systems as in Fredd= ie's example (or my example on the forum although I tested with a /24 mask = instead of /30). These configs definitely work. I still get my issue of being stuck in INIT mode on boot even after reorder= ing the options and adding the 'inet' keyword (unless I add 'up'). That cou= ld be a weird virtualbox issue though. As mentioned I'm going to try a more= recent version of FreeBSD. Note: All this applies to FreeBSD 10. I'm not even sure carp on a /30 netwo= rk is possible in earlier versions that use the old carp system. (And confi= guration of the old carp is quite different) Regards, Matt Churchyard -- Hi Matt, I think I'm the user you try to help in the forum ;-). I had the same problem like you when doing the first tests with carp. The a= lias must be a /32 as subnet declaration. I didn't read properly the exampl= es in the manual and Handbook. So I configured CARP as usual in FreeBSD 9. = The first tries were with subnet mask from the relevant network (for exampl= e /24). This leads me into the same problem. When booting up the machine, s= ome interfaces stuck in INIT state. A Workaround was to put them first down= and then up again with ifconfig. But my router has also enabled PF and is = doing Traffic Filtering. The next problem came very fast. When reloading th= e pf.conf traffic was blocked on all interfaces. Then I discovered in the m= anual all examples have a /32 subnet mask. After changing the machine boots= up properly and all interfaces are in MASTER state. Also reloading pf.conf= was working. Maybe you can try this: ifconfig_em0=3D"inet vhid 10 pass mypass alias 192.168.0.100/32" On my first testing machine the configuration looks like this: ifconfig_vlan60=3D"inet 192.168.60.253/24" ifconfig_vlan60_alias0=3D"inet vhid 3 pass xxxxxxxx alias 192.168.60.1/32 v= lan 60 vlandev lagg0" The system shows a warning message during boot when I leave the inet keywor= d in carp interface configuration. I believe the manual is maybe incomplete= . Alls examples are without inet keyword. Maybe the warnings are wrong and = could be ignored. For me it worked also with the warning but I get a bit ne= rvous on those messages. @Freddie I had a internet connection like you with a /30 Subnet from my ISP. My interface is configured like this ifconfig_igb0_alias0=3D"vhid 100 advskew 0 pass Test alias x.x.67.2/32" But then I get confused about setting up a default route Details can be found here: https://forums.freebsd.org/viewtopic.php?f=3D7&t=3D48443 But it seems that you configured your interface different like described in= the manual. I'm a bit surprised that this configuration is working. regards Sascha Am 15.10.2014 um 18:46 schrieb Matt Churchyard: Thanks for the reply I tried moving the IP address to the beginning of the ifconfig line but it = still seems to show the same error on boot and refuses to leave INIT mode. = This isn't critical as I'm just playing around with it at the moment. I'm using virtualbox to test with and a few 10.0-RELEASE vm's I've had kick= ing around for a while. I might replace them with 10.1-RC2 tomorrow and see= if I get the same thing. Matt On 15 Oct 2014, at 16:58, Freddie Cash > wrote: You don't need the "up" keyword, and it definitely works with a /30 and a s= ingle IP. I use that at work. But the order of options does matter (IP firs= t, CARP stuff second). Requires FreeBSD 10 and the new CARP code. Might work on pre-10, but I neve= r got it to work. The following is from our core fibre router: ifconfig_em0=3D"inet 142.24.243.161/30 vhid 30 pass mypass30 -lro -tso -vlanhwtso" defaultrouter=3D"142.24.243.162" The slave box is the same, but with "advskew 128" added after the pass conf= ig. _______________________________________________ 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 Thu Oct 16 10:55:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC00BF0B for ; Thu, 16 Oct 2014 10:55:30 +0000 (UTC) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F77E77 for ; Thu, 16 Oct 2014 10:55:29 +0000 (UTC) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id s9GAt7Gt077688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 11:55:07 +0100 (BST) (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 16 Oct 2014 11:54:31 +0100 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0516.029; Thu, 16 Oct 2014 11:54:31 +0100 From: Matt Churchyard To: Freddie Cash , "freebsd-net@freebsd.org" Subject: RE: Carp stuck in INIT (10.1-RC2) Thread-Topic: Carp stuck in INIT (10.1-RC2) Thread-Index: Ac/pLkONiRz77cC8TFWNAx8HzkX7Rg== Date: Thu, 16 Oct 2014 10:54:30 +0000 Message-ID: <5e92f0b5fa434eb8ba34ce11ddc6d3b3@SERVER.ad.usd-group.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 10:55:30 -0000 SGkgRnJlZGRpZSwNCg0KSSBoYXZlIHRlc3RlZCBvbiAxMC4xLVJDMiBhbmQgSeKAmW0gc2VlaW5n IGV4YWN0bHkgdGhlIHNhbWUgaXNzdWUuIEkgYW0gcnVubmluZyBhIFdpbmRvd3MgOC4xIG1hY2hp bmUgd2l0aCBhIDEwLjEtUkMyIGkzODYgVk0gaW4gVmlydHVhbGJveCwgY29uZmlndXJlZCB0byBi cmlkZ2UgdG8gbXkgSW50ZWwgbmV0d29yayBhZGFwdGVyLiAoSeKAmWQgcmF0aGVyIHVzZSBhbWQ2 NCBidXQgdW5mb3J0dW5hdGVseSBpdCBhcHBlYXJzIHRoYXQgYWx0aG91Z2ggbXkgT1MgaXMgNjRi aXQsIGl04oCZcyBvbGQgaGFyZHdhcmUgYW5kIGJvdGggVmlydHVhbGJveCAmIFZNd2FyZSBwbGF5 ZXIgcmVmdXNlIDY0Yml0IFZNcykNCg0KVGhpcyBpcyB0aGUgZXhhY3QgY29uZmlnIEkgaGF2ZSBp biAvZXRjL3JjLmNvbmYgKGp1c3QgYSBzaW5nbGUgVk0gYXQgdGhlIG1vbWVudCkNCg0KaWZjb25m aWdfZW0wPeKAnWluZXQgMTkyLjE2OC4wLjEwMC8yNCB2aGlkIDEwIHBhc3MgbXlwYXNz4oCdDQpk ZWZhdWx0cm91dGVyPeKAnTE5Mi4xNjguMC4xMOKAnQ0KDQpJZiBJIHJlYm9vdCB3aXRoIHRoaXMg Y29uZmlnLCB0aGUgZm9sbG93aW5nIHBvcHMgdXAgZHVyaW5nIGJvb3Q6DQoNClNldHRpbmcgaG9z dG5hbWU6IGNhcnAxLnRlc3QNCmVtMDogcHJvbWlzY3VvdXMgbW9kZSBlbmFibGVkDQpjYXJwOiBk ZW1vdGVkIGJ5IDI0MCB0byAyNDAgKGludGVyZmFjZSBkb3duKQ0KU3RhcnRpbmcgTmV0d29yazog bG8wIGVtMA0KDQpJZmNvbmZpZyBzaG93cyB0aGUgZm9sbG93aW5nIGFuZCBuZXZlciBjaGFuZ2Vz IGZyb20gSU5JVA0KDQplbTA6IGZsYWdzPTg5NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsUFJPTUlT QyxTSU1QTEVYLE1VTFRJQ0FSVD4NCiAgICAgICAgICAgICAgICBvcHRpb25zPTliPFJYQ1NVTSxU WENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0+DQogICAgICAgICAgICAg ICAgaW5ldCAxOTIuMTY4LjAuMTAwIG5ldG1hc2sgMHhmZmZmZmYwMCBicm9hZGNhc3QgMTkyLjE2 OC4wLjI1NSB2aGlkIDEwDQogICAgICAgICAgICAgICAgLi4uDQogICAgICAgICAgICAgICAgY2Fy cDogSU5JVCB2aGlkIDEwIGFkdmJhc2UgMSBhZHZza2V3IDANCg0KdGNwZHVtcCBzaG93cyBubyB0 cmFmZmljIGF0IGFsbA0KDQpJZiBJIGFkZCB0aGUg4oCYdXDigJkgb3B0aW9uIG9uIHRoZSBlbmQg b2YgdGhlIHJjLmNvbmYgZW50cnksIGl0IGFsbCB3b3JrcyBwZXJmZWN0bHkNCkkgc2VlIHRoZSBm b2xsb3dpbmcgZHVyaW5nIGJvb3QNCg0KU2V0dGluZyBob3N0bmFtZTogY2FycDEudGVzdA0KZW0w OiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQNCmNhcnA6IFZISUQgMTBAZW0wOiBJTklUIC0+IEJB Q0tVUA0KU3RhcnRpbmcgTmV0d29yazogbG8wIGVtMA0KLi4ubG8wICYgZW0wIGNvbmZpZ3VyYXRp b24gb3V0cHV0IChzYW1lIGFzIGlmY29uZmlnKS4uLg0KY2FycDogVkhJRCAxMDplbTA6IEJBQ0tV UCAtPiBNQVNURVIgKG1hc3RlciBkb3duKQ0KDQpBbmQgdGNwZHVtcCBzaG93cyBDQVJQdjIgYW5u b3VuY2VtZW50cyBldmVyeSBzZWNvbmQuDQoNCkkgY2FuIG9ubHkgYXNzdW1lIHRoaXMgaXMgc29t ZXRoaW5nIHRvIGRvIHdpdGggcnVubmluZyBvbiBWaXJ0dWFsYm94IGlmIGl0IHdvcmtzIGZvciB5 b3UgKGFuZCBJIGd1ZXNzIG51bWVyb3VzIG90aGVyIHVzZXJzKS4gSXQganVzdCBzZWVtcyBzdHJh bmdlIHRoYXQgaWYgSSBmb3JjZSB0aGUgaW50ZXJmYWNlIHVwLCBpdOKAmXMgYWJzb2x1dGVseSBw ZXJmZWN0LiBDaGFuY2VzIGFyZSwgaWYgSSBldmVyIHVzZSBjYXJwIGluIHByb2R1Y3Rpb24gb24g cmVhbCBtYWNoaW5lcywgaXQgbWF5IGp1c3Qgd29yayBidXQgd2hhdCBJ4oCZbSBzZWVpbmcgaW4g VmlydHVhbGJveCBkb2VzbuKAmXQgc2VlbSByaWdodC4NCg0KUmVnYXJkcywNCk1hdHQNCg0KRnJv bTogRnJlZGRpZSBDYXNoIFttYWlsdG86Zmp3Y2FzaEBnbWFpbC5jb21dDQpTZW50OiAxNSBPY3Rv YmVyIDIwMTQgMTY6NTgNClRvOiBNYXR0IENodXJjaHlhcmQNClN1YmplY3Q6IFJlOiBDYXJwIHN0 dWNrIGluIElOSVQNCg0KDQpZb3UgZG9uJ3QgbmVlZCB0aGUgInVwIiBrZXl3b3JkLCBhbmQgaXQg ZGVmaW5pdGVseSB3b3JrcyB3aXRoIGEgLzMwIGFuZCBhIHNpbmdsZSBJUC4gSSB1c2UgdGhhdCBh dCB3b3JrLiBCdXQgdGhlIG9yZGVyIG9mIG9wdGlvbnMgZG9lcyBtYXR0ZXIgKElQIGZpcnN0LCBD QVJQIHN0dWZmIHNlY29uZCkuDQoNClJlcXVpcmVzIEZyZWVCU0QgMTAgYW5kIHRoZSBuZXcgQ0FS UCBjb2RlLiBNaWdodCB3b3JrIG9uIHByZS0xMCwgYnV0IEkgbmV2ZXIgZ290IGl0IHRvIHdvcmsu DQoNClRoZSBmb2xsb3dpbmcgaXMgZnJvbSBvdXIgY29yZSBmaWJyZSByb3V0ZXI6DQoNCmlmY29u ZmlnX2VtMD0iaW5ldCAxNDIuMjQuMjQzLjE2MS8zMDxodHRwOi8vMTQyLjI0LjI0My4xNjEvMzA+ IHZoaWQgMzAgcGFzcyBteXBhc3MzMCAtbHJvIC10c28gLXZsYW5od3RzbyINCmRlZmF1bHRyb3V0 ZXI9IjE0Mi4yNC4yNDMuMTYy4oCdDQoNClRoZSBzbGF2ZSBib3ggaXMgdGhlIHNhbWUsIGJ1dCB3 aXRoICJhZHZza2V3IDEyOCIgYWRkZWQgYWZ0ZXIgdGhlIHBhc3MgY29uZmlnLg0K From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 14:31:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D09CDB76; Thu, 16 Oct 2014 14:31:12 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FD1BD3E; Thu, 16 Oct 2014 14:31:12 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A831E25D3871; Thu, 16 Oct 2014 14:31:09 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 94283C770AE; Thu, 16 Oct 2014 14:31:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id dgJ5OerVOLoh; Thu, 16 Oct 2014 14:31:07 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3DF70C77071; Thu, 16 Oct 2014 14:31:05 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: "Bjoern A. Zeeb" In-Reply-To: <86d29so0r1.fsf@nine.des.no> Date: Thu, 16 Oct 2014 14:31:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> <86d29so0r1.fsf@nine.des.no> To: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 14:31:12 -0000 On 16 Oct 2014, at 08:52 , Dag-Erling Sm=F8rgrav wrote: > "Bjoern A. Zeeb" writes: >> Also if people are seriously thinking about virtualising pf we need = to >> import the openbsd/apple pf fix from a few years ago because = otherwise >> people in virtualised stacks with a /dev/pf can do ugly things. I >> think it=92s been this one: >> http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 >=20 > There are other serious issues with our current pf (checksum = corruption) > which I think can only be resolved by importing a newer version. Sorry, but you lost context. I was talking about security implications = in VIMAGE context, not about random bugs. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 17:05:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F6EB66E; Thu, 16 Oct 2014 17:05:03 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50480103; Thu, 16 Oct 2014 17:05:02 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id s18so3254148lam.37 for ; Thu, 16 Oct 2014 10:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=uBVHkwgVhM/09SM/W1erL0Ng1ruv7pW1JuRa7CN5rxU=; b=jHVGFrV2cZmBhXjBFqhlwshW+ojAQRQguiLW+84g0+bpOeG4X1bFCsCFdJuzprWut4 UyR0dN58N1V1ACKKZMYMVZ7iifihYcOZb/0+PbNTGSu3EyHqPk7O+NVrqS1x2+rphn6t ThoYErJydrymAJbvu52hQHPH5ysOglYl1QMFYidux7/+cR+6EAdJYxl6Cc/QjR4LdQzH Uvih41hmf6bqVwzmZb/yJ8V4wvh0gWJwgy+gzfg5bU4akPTEF4vhsYdkJ1N9Qean7QX9 OlxHoY4aRrKH3bOEbv71xbIs9nh8FDb5KFXqmQzypiYhZcCAHTuzh2/Fs78ZVjRCzGfS iW/w== MIME-Version: 1.0 X-Received: by 10.112.221.226 with SMTP id qh2mr3053717lbc.5.1413479100133; Thu, 16 Oct 2014 10:05:00 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Thu, 16 Oct 2014 10:05:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 10:05:00 -0700 X-Google-Sender-Auth: 6h1wnbx8zJOMVrJ5RGefmCREkss Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 17:05:03 -0000 On Sat, Oct 11, 2014 at 10:58 AM, Craig Rodrigues wrote: > Hi, > > What action items are left to enable VIMAGE by default for FreeBSD 11? > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > Based on the discussion in this thread, I started writing down a list of action items before enabling VIMAGE by default: https://wiki.freebsd.org/VIMAGE/TODO Does that look reasonable? -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 17:39:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE748C08; Thu, 16 Oct 2014 17:39:12 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8C560F; Thu, 16 Oct 2014 17:39:12 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5DF36CDCC; Thu, 16 Oct 2014 17:39:10 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 28A94513E; Thu, 16 Oct 2014 19:39:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Bjoern A. Zeeb" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> <86d29so0r1.fsf@nine.des.no> Date: Thu, 16 Oct 2014 19:39:11 +0200 In-Reply-To: (Bjoern A. Zeeb's message of "Thu, 16 Oct 2014 14:31:02 +0000") Message-ID: <8638anzzgg.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 17:39:12 -0000 "Bjoern A. Zeeb" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > There are other serious issues with our current pf (checksum > > corruption) which I think can only be resolved by importing a newer > > version. > Sorry, but you lost context. I was talking about security > implications in VIMAGE context, not about random bugs. I realize that, but you're talking about patching our current pf, and I think that's a waste of time; we should import a newer version instead (which I assume already has those patches). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 17:49:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C7B6E0D for ; Thu, 16 Oct 2014 17:49:03 +0000 (UTC) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDE1D760 for ; Thu, 16 Oct 2014 17:49:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=poffVHFriwbO4eGAJ4/WSif1xv21ZW8AU7KbES3HJ64=; b=pvUl91nvZVCB4XTf3D9iCf0TF4hcE9m+bav7dTW5+lI4L+0Yyf3Z3CR4yqdvHBcoxpnFY7SC6cv3ILABlODXo2b1vxXMTFbtq3IEtcqqzm385f3U7hdq98vnFZfT9PMU5TDF+BB4vW9kWWgZYIv76bz6Va9jke34pJxMvu1UchE=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1XepAN-000Exx-Vw for freebsd-net@freebsd.org; Thu, 16 Oct 2014 20:48:47 +0300 Date: Thu, 16 Oct 2014 20:48:47 +0300 From: wishmaster Subject: Re[2]: Enabling VIMAGE by default for FreeBSD 11? To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= X-Mailer: mail.ukr.net 5.0 Message-Id: <1413481493.455723594.213mta8m@frv34.fwdcdn.com> In-Reply-To: <8638anzzgg.fsf@nine.des.no> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> <86d29so0r1.fsf@nine.des.no> <8638anzzgg.fsf@nine.des.no> MIME-Version: 1.0 Received: from artemrts@ukr.net by frv34.fwdcdn.com; Thu, 16 Oct 2014 20:48:47 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: "Bjoern A. Zeeb" , freebsd-arch , freebsd-virtualization@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 17:49:03 -0000 --- Original message --- From: "Dag-Erling Smørgrav" Date: 16 October 2014, 20:39:22 > "Bjoern A. Zeeb" writes: > > Dag-Erling Smørgrav writes: > > > There are other serious issues with our current pf (checksum > > > corruption) which I think can only be resolved by importing a newer > > > version. > > Sorry, but you lost context. I was talking about security > > implications in VIMAGE context, not about random bugs. > > I realize that, but you're talking about patching our current pf, and I > think that's a waste of time; we should import a newer version instead > (which I assume already has those patches). > Forget about importing new version of PF from OS, which doesn't has virtualized inet stack. Cheers, w From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 19:23:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8628C1 for ; Thu, 16 Oct 2014 19:23:40 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD0B91BC for ; Thu, 16 Oct 2014 19:23:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 961AAB9A8; Thu, 16 Oct 2014 15:23:39 -0400 (EDT) From: John Baldwin To: Jason Wolfe Subject: Re: ixgbe(4) spin lock held too long Date: Thu, 16 Oct 2014 15:23:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1410203348.1343.1.camel@bruno> <3567780.Mf6fMnzmYG@ralph.baldwin.cx> In-Reply-To: MIME-Version: 1.0 Message-Id: <201410161523.32415.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 16 Oct 2014 15:23:39 -0400 (EDT) Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 19:23:41 -0000 On Saturday, October 11, 2014 2:19:19 am Jason Wolfe wrote: > On Fri, Oct 10, 2014 at 8:53 AM, John Baldwin wrote: > > > On Thursday, October 09, 2014 02:31:32 PM Jason Wolfe wrote: > > > On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote: > > > > My only other thought is if a direct timeout routine ran for a long > > time. > > > > > > > > I just committed a change to current that can let you capture KTR > > traces > > > > of > > > > callout routines for use with schedgraph (r272757). Unfortunately, > > > > enabling KTR_SCHED can be slow. If you are up for trying it, I do > > think > > > > that > > > > building a kernel with KTR and KTR_SCHED enabled (KTR_COMPILE=KTR_SCHED > > > > and > > > > KTR_MASK=KTR_SCHED) with the kernel part of the commit I referenced > > above > > > > applied is the best bet to figure out why it is spinning so long. If > > you > > > > can > > > > try that (and if it doesn't slow things down too much) and get a panic > > > > with > > > > those options enabled, then capture the output of > > > > 'ktrdump -e /path/to/kernel -m /var/crash/vmcore.X -ct', we can use > > > > Src/tools/sched/schedgraph.py to look at that output to get a picture > > of > > > > what > > > > was going on just prior to the crash. > > > > > > > > -- > > > > John Baldwin > > > > > > As luck would have it.. caught one of the boxes with the new KTR > > > code/options after only an hour. Crashed in the same way w tid 100003 > > and > > > looking the same in callout_process > > > > > > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid > > > 100003) too long > > > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid > > > 100003) too long > > > > > > #4 0xffffffff8070d6fa in callout_process (now=7915682202423) at > > > /usr/src/sys/kern/kern_ > > > timeout.c:490 > > > > > > The ktrdump oddly only seems to have the last 702, though > > debug.ktr.entries > > > is set to 1024. It appears the buffer may also start after 100003 had > > > already hung? I've bumped debug.ktr.entries up in case we don't have > > > enough history here. > > > > > > http://nitrology.com/ktrdump-spinlock.txt > > > > Hmm, schedgraph.py chokes on this, but it's a bit interesting. It seems > > that > > in this time sample, CPUs 1, 2, 4, and 5 were constantly running ixgbe > > interrupt handlers. No actual thread state changes are logged (which is > > why > > schedgraph choked). > > > > Try setting the sysctl 'net.inet.tcp.per_cpu_timers' to 1 and see if that > > makes a difference. I'm guessing they are all contending on the default > > callout lock which is causing your headache. > > > > -- > > John Baldwin > > > > net.inet.tcp.per_cpu_timers=1 triggered some other fun :) Saw this same > panic across a handful of machines: > > panic: tcp_setpersist: retransmit pending > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe1f9e9ab800 > panic() at panic+0x155/frame 0xfffffe1f9e9ab880 > tcp_setpersist() at tcp_setpersist+0xa3/frame 0xfffffe1f9e9ab8b0 > tcp_timer_persist() at tcp_timer_persist+0x176/frame 0xfffffe1f9e9ab8e0 > softclock_call_cc() at softclock_call_cc+0x1ce/frame 0xfffffe1f9e9ab9e0 > softclock() at softclock+0x44/frame 0xfffffe1f9e9aba00 > intr_event_execute_handlers() at intr_event_execute_handlers+0x83/frame > 0xfffffe1f9e9aba30 > ithread_loop() at ithread_loop+0x96/frame 0xfffffe1f9e9aba70 > fork_exit() at fork_exit+0x71/frame 0xfffffe1f9e9abab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe1f9e9abab0 > --- trap 0, rip = 0, rsp = 0xfffffe1f9e9abb70, rbp = 0 --- > > (kgdb) up 3 > #3 0xffffffff808467d3 in tcp_setpersist (tp=) at > /usr/src/sys/netinet/tcp_output.c:1619 > 1619 panic("tcp_setpersist: retransmit pending"); > (kgdb) list > 1614 int t = ((tp->t_srtt >> 2) + tp->t_rttvar) >> 1; > 1615 int tt; > 1616 > 1617 tp->t_flags &= ~TF_PREVVALID; > 1618 if (tcp_timer_active(tp, TT_REXMT)) > 1619 panic("tcp_setpersist: retransmit pending"); > 1620 /* > 1621 * Start/restart persistance timer. > 1622 */ > 1623 TCPT_RANGESET(tt, t * tcp_backoff[tp->t_rxtshift], > > I have debug.ktr.entries set to 204800 on the machines compiled with KTR > options, maybe a bit more history can provide some extra context. I looked at the other trace and I don't think it disagrees with my previous theory. I do have more KTR patches to log when we spin on locks which would really confirm this, but I haven't tested those fully on HEAD yet. However, I'd rather spend time debugging this panic. I think I added that assertion myself. The root problem is that the persist and retransmit timers share state, so only one should ever be active at a time. In this case, the persist timer has fired and is rescheduling itself, but some other thread has scheduled the retransmit timer to fire. The bug is probably in that other thread. It should either not scheduled the retransmit timer, or it should first cancel the persist timer. A new assertion should be able to find this. Note, this is definitely going to panic, but one panic is probably enough to find this. Index: tcp_timer.c =================================================================== --- tcp_timer.c (revision 272718) +++ tcp_timer.c (working copy) @@ -713,10 +713,14 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ case TT_REXMT: t_callout = &tp->t_timers->tt_rexmt; f_callout = tcp_timer_rexmt; + if (callout_active(&tp->t_timers->tt_persist)) + panic("scheduling retransmit with persist active"); break; case TT_PERSIST: t_callout = &tp->t_timers->tt_persist; f_callout = tcp_timer_persist; + if (callout_active(&tp->t_timers->tt_rexmt)) + panic("scheduling persist with retransmit active"); break; case TT_KEEP: t_callout = &tp->t_timers->tt_keep; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 20:03:03 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EAFEF66 for ; Thu, 16 Oct 2014 20:03:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 571BD84A for ; Thu, 16 Oct 2014 20:03:03 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9GK33Qj019347 for ; Thu, 16 Oct 2014 20:03:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27 Date: Thu, 16 Oct 2014 20:03:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 20:03:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #2 from Eric Joyner --- I'll re-submit a core code patch; John Baldwin made valid comments about some parts of it. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 21:19:08 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3456D89 for ; Thu, 16 Oct 2014 21:19:08 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAAF9115 for ; Thu, 16 Oct 2014 21:19:08 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9GLJ8Rn051479 for ; Thu, 16 Oct 2014 21:19:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Thu, 16 Oct 2014 21:19:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 21:19:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #6 from Eric Joyner --- Does that mean only the sizes of struct m_hdr and struct m_pkthdr change, or do you change MSIZE as well? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 21:29:42 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD4D023D for ; Thu, 16 Oct 2014 21:29:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4AD022C for ; Thu, 16 Oct 2014 21:29:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9GLTgwN061826 for ; Thu, 16 Oct 2014 21:29:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Thu, 16 Oct 2014 21:29:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 21:29:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #7 from Garrett Cooper --- (In reply to Eric Joyner from comment #6) > Does that mean only the sizes of struct m_hdr and struct m_pkthdr change, or > do you change MSIZE as well? The size of struct m_ext and struct m_hdr is larger than stock FreeBSD, with certain compile-time options. However, you can technically tweak MSIZE though so it's less than 160, which would also reproduce the situation. That scenario seems kind of silly though. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 21:37:30 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDB01375 for ; Thu, 16 Oct 2014 21:37:30 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4A54332 for ; Thu, 16 Oct 2014 21:37:30 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9GLbUgH098045 for ; Thu, 16 Oct 2014 21:37:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Thu, 16 Oct 2014 21:37:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 21:37:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #8 from Eric Joyner --- So it sounds like we may just need to change IXGBE_RX_COPY_LEN from a fixed value of 160 to something that's calculated based on the length of struct m_hdr and struct m_pkthdr combined. I think they got 160 by adding together the size of the two header structs (88 in FreeBSD amd64), adding some number (8) to make that size divisible by 32 (96 % 32 == 0), and then subtracted that from MSIZE (256) to get IXGBE_RX_COPY_LEN (160), while keeping the padding added as IXGBE_RX_COPY_ALIGN. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 23:33:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0888A7D1; Thu, 16 Oct 2014 23:33:42 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F384CE0; Thu, 16 Oct 2014 23:33:40 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id p9so3614448lbv.21 for ; Thu, 16 Oct 2014 16:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ftsk/FZ3M8utYXN6LOmwgsdC6mf1618VGi2lsTOshuc=; b=TMtXCXrMMCuE4uRCRZ2m/Xlyu42MIzP+u9ms4Orso+U1UVq4GvN/r7hilnWVbVucAu YzhQuBJfoKxFaCariADo3qm+t2+7/rzllJQWjZcs7UcDmw9Riag3SYqezAoE1ZizjMRi +hkkMOuzN/0F+l7/60nkfuJ4M8OyP029GjJgrLrvOTZWaNzqTQURZIf0WLXjo3Q6rgzE RI2s561sbqJsckLQfQgOwKiHLuYECAZrciANtRTMsFWB3wBox+uuqmnlbd2aMGle/LxU Nrrkmt7AEzEcsWoleUkTQqC6rddPvhtaLSnVpL4+1Dr9aohTbCpYp8Gn9DZOnaVT350a N/7w== MIME-Version: 1.0 X-Received: by 10.112.148.161 with SMTP id tt1mr4861879lbb.67.1413502418889; Thu, 16 Oct 2014 16:33:38 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Thu, 16 Oct 2014 16:33:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 16:33:38 -0700 X-Google-Sender-Auth: XqKkRDMJt4Q0fnyIXupkWRvX1-Y Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 23:33:42 -0000 On Sat, Oct 11, 2014 at 11:15 PM, Adrian Chadd wrote: > ... is it enabled by default on pcbsd? > Kris has answered the question about pcbsd and VIMAGE. As an additional datapoint, I would like to point out that VIMAGE has been enabled in FreeNAS for some time: https://github.com/freenas/freenas/blob/master/build/nanobsd-cfg/FREENAS.amd64 -- Craig From owner-freebsd-net@FreeBSD.ORG Thu Oct 16 23:41:02 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BBBF98B for ; Thu, 16 Oct 2014 23:41:02 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E65CD1A2 for ; Thu, 16 Oct 2014 23:41:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9GNf1eB064051 for ; Thu, 16 Oct 2014 23:41:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Thu, 16 Oct 2014 23:41:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Oct 2014 23:41:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #9 from Eric Joyner --- You could try replacing the two lines in ixgbe.h with these: #define IXGBE_RX_COPY_HDR (sizeof(struct m_hdr) + sizeof(struct pkthdr)) #define IXGBE_RX_COPY_HDR_PADDED ((((IXGBE_RX_COPY_HDR - 1) / 32) + 1) * 32) #define IXGBE_RX_COPY_LEN (MSIZE - IXGBE_RX_COPY_HDR_PADDED) #define IXGBE_RX_COPY_ALIGN (IXGBE_RX_COPY_HDR_PADDED - IXGBE_RX_COPY_HDR) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 05:43:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A7ECD18; Fri, 17 Oct 2014 05:43:16 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64B56698; Fri, 17 Oct 2014 05:43:16 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id fp1so147869pdb.35 for ; Thu, 16 Oct 2014 22:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:cc:mime-version :content-type; bh=RtUvPqQ96GgG9CKn3kosaimt6nlkFKIv3cKoP8g+w10=; b=ZLE1j3xrr/Ck6Nq30yEanYF71Nk24RgmUofNhMwstvdoGFb9urNq2/zdgl9MVZ0+Ao tp8f0zOzZvvK8iUGJkcrOXlmHbfIpFOKY3KW4caT91TehFBG5Q8YfCjf6pV7HX4E/NiE 1uzUF2y/T+jR32qm3RQkvRMZSLYYTYEJ/nxyh7NXXjJzmMjekR5hCxyW3IKraO1Z5L4g KAgqB5VqnUFmE1a2l/ztX/Z19oYmoeqBdYdjHYb1FyQfW+LIN+Lrhwz3kuQiRkA+Hn8F kUvkBgglQXfIlIzYimI6vxv8/Lp2ryz0wQNw5A/4SkV7+Le+rrC52u3+xLJN2PTgqyu8 Raiw== X-Received: by 10.66.102.105 with SMTP id fn9mr5929824pab.127.1413524595493; Thu, 16 Oct 2014 22:43:15 -0700 (PDT) Received: from ?IPv6:2602:306:c40e:720:ac6c:8a23:419a:6c00? ([2602:306:c40e:720:ac6c:8a23:419a:6c00]) by mx.google.com with ESMTPSA id c2sm393588pdl.14.2014.10.16.22.43.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 22:43:14 -0700 (PDT) Date: Thu, 16 Oct 2014 22:43:09 -0700 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-ID: Importance: normal From: "vijju.singh" To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , "Bjoern A. Zeeb" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 05:43:16 -0000 V2UndmUgc2VlbiBpc3N1ZXMgd2l0aCB2bmV0IGRlbGV0ZSBjYXVzaW5nIHN0YWxlIHBvaW50ZXJz IGluIG1idWZzIHJlZmVyZW5jaW5nIHRoZSBwZXItdm5ldCBsb29wYmFjayBpbnRlcmZhY2UgKGRl bGV0ZWQgd2l0aCB0aGUgdm5ldCkuCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR0FMQVhZIFPCrjQs IGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUKCjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogRGFnLUVybGluZyBTbcO4cmdyYXYgPGRlc0BkZXMu bm8+IDwvZGl2PjxkaXY+RGF0ZToxMC8xNi8yMDE0ICAxMDozOSBBTSAgKEdNVC0wODowMCkgPC9k aXY+PGRpdj5UbzogIkJqb2VybiBBLiBaZWViIiA8YnplZWItbGlzdHNAbGlzdHMuemFiYmFkb3ou bmV0PiA8L2Rpdj48ZGl2PkNjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyxmcmVlYnNkLXZpcnR1 YWxpemF0aW9uQGZyZWVic2Qub3JnLGZyZWVic2QtYXJjaCA8ZnJlZWJzZC1hcmNoQGZyZWVic2Qu b3JnPiA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBFbmFibGluZyBWSU1BR0UgYnkgZGVmYXVsdCBm b3IgRnJlZUJTRCAxMT8gPC9kaXY+PGRpdj4KPC9kaXY+IkJqb2VybiBBLiBaZWViIiA8YnplZWIt bGlzdHNAbGlzdHMuemFiYmFkb3oubmV0PiB3cml0ZXM6Cj4gRGFnLUVybGluZyBTbcO4cmdyYXYg PGRlc0BkZXMubm8+IHdyaXRlczoKPiA+IFRoZXJlIGFyZSBvdGhlciBzZXJpb3VzIGlzc3VlcyB3 aXRoIG91ciBjdXJyZW50IHBmIChjaGVja3N1bQo+ID4gY29ycnVwdGlvbikgd2hpY2ggSSB0aGlu ayBjYW4gb25seSBiZSByZXNvbHZlZCBieSBpbXBvcnRpbmcgYSBuZXdlcgo+ID4gdmVyc2lvbi4K PiBTb3JyeSwgYnV0IHlvdSBsb3N0IGNvbnRleHQuICBJIHdhcyB0YWxraW5nIGFib3V0IHNlY3Vy aXR5Cj4gaW1wbGljYXRpb25zIGluIFZJTUFHRSBjb250ZXh0LCBub3QgYWJvdXQgcmFuZG9tIGJ1 Z3MuCgpJIHJlYWxpemUgdGhhdCwgYnV0IHlvdSdyZSB0YWxraW5nIGFib3V0IHBhdGNoaW5nIG91 ciBjdXJyZW50IHBmLCBhbmQgSQp0aGluayB0aGF0J3MgYSB3YXN0ZSBvZiB0aW1lOyB3ZSBzaG91 bGQgaW1wb3J0IGEgbmV3ZXIgdmVyc2lvbiBpbnN0ZWFkCih3aGljaCBJIGFzc3VtZSBhbHJlYWR5 IGhhcyB0aG9zZSBwYXRjaGVzKS4KCkRFUwotLSAKRGFnLUVybGluZyBTbcO4cmdyYXYgLSBkZXNA ZGVzLm5vCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmZy ZWVic2QtYXJjaEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmZyZWVic2Qu b3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcmNoClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFu eSBtYWlsIHRvICJmcmVlYnNkLWFyY2gtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmci From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 05:48:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90C33EC9; Fri, 17 Oct 2014 05:48:49 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 61A976C5; Fri, 17 Oct 2014 05:48:48 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9H5mXa7042100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 22:48:37 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5440ADAB.6080308@freebsd.org> Date: Fri, 17 Oct 2014 13:48:27 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "vijju.singh" , =?UTF-8?B?RGFnLUVybGluZyBTbcO4?= =?UTF-8?B?cmdyYXY=?= , "Bjoern A. Zeeb" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 05:48:49 -0000 On 10/17/14, 1:43 PM, vijju.singh wrote: > We've seen issues with vnet delete causing stale pointers in mbufs referencing the per-vnet loopback interface (deleted with the vnet). you can also see this sort of problem with removable devices. e.g. USB network interfaces, so it's not unique to vnet. > > Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone > >
-------- Original message --------
From: Dag-Erling Smørgrav
Date:10/16/2014 10:39 AM (GMT-08:00)
To: "Bjoern A. Zeeb"
Cc: freebsd-net@freebsd.org,freebsd-virtualization@freebsd.org,freebsd-arch
Subject: Re: Enabling VIMAGE by default for FreeBSD 11?
>
"Bjoern A. Zeeb" writes: >> Dag-Erling Smørgrav writes: >>> There are other serious issues with our current pf (checksum >>> corruption) which I think can only be resolved by importing a newer >>> version. >> Sorry, but you lost context. I was talking about security >> implications in VIMAGE context, not about random bugs. > I realize that, but you're talking about patching our current pf, and I > think that's a waste of time; we should import a newer version instead > (which I assume already has those patches). > > DES From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 06:19:00 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C054230F for ; Fri, 17 Oct 2014 06:19:00 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8D92970 for ; Fri, 17 Oct 2014 06:19:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9H6J0ac069505 for ; Fri, 17 Oct 2014 06:19:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 164763] [vnet] Memory leak in VNET Date: Fri, 17 Oct 2014 06:19:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 06:19:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=164763 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rodrigc@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #5 from Craig Rodrigues --- Bjoern gave a link to his Perforce repo here: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040075.html It would be good to merge these memory leak fixes into FreeBSD HEAD -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 06:37:25 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA1D560A for ; Fri, 17 Oct 2014 06:37:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A23DBB0D for ; Fri, 17 Oct 2014 06:37:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9H6bPGA018800 for ; Fri, 17 Oct 2014 06:37:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191468] [vimage] options VIMAGE - kernel panic, crashes during system boot Date: Fri, 17 Oct 2014 06:37:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 06:37:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191468 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rodrigc@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 06:40:31 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CBA16FC for ; Fri, 17 Oct 2014 06:40:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74DA9B27 for ; Fri, 17 Oct 2014 06:40:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9H6eVgh023321 for ; Fri, 17 Oct 2014 06:40:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 184149] [vimage] IPv6 link-local collisions on epair[n]b devices Date: Fri, 17 Oct 2014 06:40:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 06:40:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184149 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rodrigc@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 11:37:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33C55BE6; Fri, 17 Oct 2014 11:37:48 +0000 (UTC) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B21A7B22; Fri, 17 Oct 2014 11:37:47 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.9/8.14.9/ALCHEMY.FRANKEN.DE) with ESMTP id s9HBbcxK016782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Oct 2014 13:37:38 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.9/8.14.9/Submit) id s9HBbbb6016781; Fri, 17 Oct 2014 13:37:37 +0200 (CEST) (envelope-from marius) Date: Fri, 17 Oct 2014 13:37:37 +0200 From: Marius Strobl To: Craig Rodrigues Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-ID: <20141017113737.GA16736@alchemy.franken.de> References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Fri, 17 Oct 2014 13:37:38 +0200 (CEST) Cc: FreeBSD Net , Adrian Chadd , freebsd-arch , "freebsd-virtualization@freebsd.org" , Kris Moore X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 11:37:48 -0000 On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: > On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > > > > It was for a while in 9.2, but we removed it from 10.0 and later due to > > stability issues we kept getting reports about. Haven't tried it since > > then, dont know if those issues are fixed. > > > > I fixed some of the problems with VIMAGE that I encountered with Bluetooth: > > https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html ... which still lacks a proper implementation that doesn't constitute a gross layering violation in generic bus code. > > Hiroo Onoo submitted this patch, which I committed to fix problems with > VIMAGE encountered with removable USB Ethernet: > > https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html > > Martin Matuska committed this fix for PF: > https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html > > So a lot of the stability problems with VIMAGE which were in PC-BSD 9.2 and > FreeBSD 9.x have been slowly been fixed. Marius From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 11:52:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24BA51B9; Fri, 17 Oct 2014 11:52:35 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6C42CDF; Fri, 17 Oct 2014 11:52:33 +0000 (UTC) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 17 Oct 2014 13:51:21 +0200 Date: Fri, 17 Oct 2014 13:51:42 +0200 From: Marko Zec To: Marius Strobl Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-ID: <20141017135142.3f5a713c@x23> In-Reply-To: <20141017113737.GA16736@alchemy.franken.de> References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> <20141017113737.GA16736@alchemy.franken.de> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] Cc: Craig Rodrigues , Adrian Chadd , "freebsd-virtualization@freebsd.org" , FreeBSD Net , freebsd-arch , Kris Moore X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 11:52:35 -0000 On Fri, 17 Oct 2014 13:37:37 +0200 Marius Strobl wrote: > On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: > > On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > > > > > > > It was for a while in 9.2, but we removed it from 10.0 and later > > > due to stability issues we kept getting reports about. Haven't > > > tried it since then, dont know if those issues are fixed. > > > > > > > I fixed some of the problems with VIMAGE that I encountered with > > Bluetooth: > > > > https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html > > ... which still lacks a proper implementation that doesn't constitute > a gross layering violation in generic bus code. By all means please go ahead and propose a layering-clean alternative, not as ugly and intrusive as this part which I assume bodes you eyes: - return (device_attach(dev)); + + CURVNET_SET_QUIET(vnet0); + error = device_attach(dev); + CURVNET_RESTORE(); + return error; Marko > > > > Hiroo Onoo submitted this patch, which I committed to fix problems > > with VIMAGE encountered with removable USB Ethernet: > > > > https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html > > > > Martin Matuska committed this fix for PF: > > https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html > > > > So a lot of the stability problems with VIMAGE which were in PC-BSD > > 9.2 and FreeBSD 9.x have been slowly been fixed. > > Marius > > _______________________________________________ > 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 Oct 17 16:55:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B55B19B3 for ; Fri, 17 Oct 2014 16:55:33 +0000 (UTC) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77DE1B9 for ; Fri, 17 Oct 2014 16:55:33 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from bpb8.clarehall.cam.ac.uk ([131.111.224.154]:58604 helo=[192.168.0.2]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:mpg39) (TLSv1:AES128-SHA:128) id 1XfAoN-00039w-rx (Exim 4.82_3-c0e5623) for freebsd-net@freebsd.org (return-path ); Fri, 17 Oct 2014 17:55:31 +0100 From: "Matthew P. Grosvenor" Subject: Netmap: head vs cur vs tail? Message-Id: <9C6995C3-2B7A-4769-A658-DCF1C1B23B60@cl.cam.ac.uk> Date: Fri, 17 Oct 2014 17:55:26 +0100 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Sender: "M.P. Grosvenor" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 16:55:33 -0000 Hi all, I=92m trying to understand how to use the netmap framework, specifically = how the head, tail and current =93pointers=94 interact with each other.=20= Looking in man NETMAP(4) = (http://www.freebsd.org/cgi/man.cgi?query=3Dnetmap&sektion=3D4) under = data structures, struct netmap_ring it says: " contains the index = of he current read or write slot (cur), =93. In the example code, the = following pattern is used:=20 i =3D ring->cur; ... ring->cur =3D NETMAP_RING_NEXT(ring, i); However, in the example that ships with the netmap source = (https://code.google.com/p/netmap/source/browse/examples/bridge.c#72 & = https://code.google.com/p/netmap/source/browse/examples/pkt-gen.c#660) = the following pattern is used:=20 j =3D rxring->cur;=20 while(=85){ j =3D nm_ring_next(rxring, j); =85 } rxring->head =3D rxring->cur =3D j; So the obvious question is, what is the relationship between head and = current? Do I believe the man page (and man page example) that head is = not necessary, or do I believe the example code that head is necessary = and should be set to the same value as current? And if so, what is the = point of head? And why is it updated outside of the loop in both of the = examples?=20 At a high level, I=92m looking for a better understanding of what head, = tail and current mean and how they affect the processing of rings.=20 Cheers, Matt From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 17:27:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3094219A for ; Fri, 17 Oct 2014 17:27:57 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2D885EE for ; Fri, 17 Oct 2014 17:27:56 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id d1so1849150wiv.12 for ; Fri, 17 Oct 2014 10:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k9c5oyr6EaAqobHLBAVhYVeL3Q7w6cUjXWjI7rSDPW8=; b=teabLT2Dm0fgqChjvemOQNKUW+nDeWgtvHwTGg5gWxgnA0CgLfPYTF1Cvng1uw1qtN 9le2iIFsnLFQ8e6B7iBijUHKRQe+b2fcbMLu7uhgWb4+ILzfHxdwUmt4e7xR9cwyU6mB A7Hf93SyUKGsmRbzsQ20qWoQ0xNA9DLC3HXA9BAlfXdx/wtKh3EifJTxkM9KIVB9x9WG Fpil84cBqMeoan5PvRzS5M3s68uj+sFVc+Rb4E5RD3UoMa+VOCOGDmSsPP2QLOfE8USm httIywdnWWok196Hl0e/RE7W+YGcRnjE9IMocNVlHcs16/tQRKg3BKTPPsKKgsPK+J/K 8rvw== MIME-Version: 1.0 X-Received: by 10.180.38.34 with SMTP id d2mr312756wik.55.1413566874791; Fri, 17 Oct 2014 10:27:54 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Fri, 17 Oct 2014 10:27:54 -0700 (PDT) In-Reply-To: <9C6995C3-2B7A-4769-A658-DCF1C1B23B60@cl.cam.ac.uk> References: <9C6995C3-2B7A-4769-A658-DCF1C1B23B60@cl.cam.ac.uk> Date: Fri, 17 Oct 2014 10:27:54 -0700 X-Google-Sender-Auth: nXCZAUmXjXOK4MQCWOR7NgYt5u0 Message-ID: Subject: Re: Netmap: head vs cur vs tail? From: Luigi Rizzo To: "Matthew P. Grosvenor" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 17:27:57 -0000 On Fri, Oct 17, 2014 at 9:55 AM, Matthew P. Grosvenor < matthew.grosvenor@cl.cam.ac.uk> wrote: > Hi all, > I=E2=80=99m trying to understand how to use the netmap framework, specifi= cally how > the head, tail and current =E2=80=9Cpointers=E2=80=9D interact with each = other. > > Looking in man NETMAP(4) ( > http://www.freebsd.org/cgi/man.cgi?query=3Dnetmap&sektion=3D4) under data > structures, struct netmap_ring it says: " contains the index of he > current read or write slot (cur), =E2=80=9C. In the example code, the fol= lowing > pattern is used: > =E2=80=8Bthe default netmap manpage at the above URL is the old one, please use the one for 10-stable or 11-current http://www.freebsd.org/cgi/man.cgi =E2=80=8B?=E2=80=8B query=3Dnetmap&manpath=3DFreeBSD+10.0-stable =E2=80=8Bwhich=E2=80=8B explains in more detail the role of the three pointers (with some ascii graphics too). Feel free to ask for more details if the page is not clear cheers luigi > i =3D ring->cur; > ... > ring->cur =3D NETMAP_RING_NEXT(ring, i); > > However, in the example that ships with the netmap source ( > https://code.google.com/p/netmap/source/browse/examples/bridge.c#72 & > https://code.google.com/p/netmap/source/browse/examples/pkt-gen.c#660) > the following pattern is used: > > j =3D rxring->cur; > while(=E2=80=A6){ > j =3D nm_ring_next(rxring, j); > =E2=80=A6 > } > rxring->head =3D rxring->cur =3D j; > > So the obvious question is, what is the relationship between head and > current? Do I believe the man page (and man page example) that head is no= t > necessary, or do I believe the example code that head is necessary and > should be set to the same value as current? And if so, what is the point = of > head? And why is it updated outside of the loop in both of the examples? > > At a high level, I=E2=80=99m looking for a better understanding of what h= ead, tail > and current mean and how they affect the processing of rings. > > > Cheers, > Matt > > _______________________________________________ > 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 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 18:28:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DE78EC0 for ; Fri, 17 Oct 2014 18:28:34 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E58ECBC4 for ; Fri, 17 Oct 2014 18:28:33 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id i17so1029811qcy.2 for ; Fri, 17 Oct 2014 11:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QRwDxspfMaQIGKgWho3LdBOz8jfitOAeIfSMqQvgqn4=; b=Xo3swDipjCiAMfWyxCmQ+E9lKlODlaVyPuXs2tPPA2q7E3YXxtJQggBdrW7InUF/fA ay0DNdQOGFrzpZXJ2XynxKQByrTkidPcRuF4o0xI/oTsN0e42ZL0zJcjCG5cHhwEjslT OsYDLWsxy13W2NuFUxGLJxpoi/GEfr6tVn+MwP1Y0g1fER+PnsVMoIgeB7qt10UEyCd5 c+XVR9wAPCKeisF8g7DX1NV0gsnIDvzI218NbO+zcCGFBu6ZbEf4ELauoV7Ef81wn9PV NXEWz2meswKEafH3OpAwNiTxsnFUxunWma8H+AZGsYDcSlAI3vr/c/HrcG5dWPkDqQfA kCnQ== MIME-Version: 1.0 X-Received: by 10.140.83.203 with SMTP id j69mr13953448qgd.89.1413570512987; Fri, 17 Oct 2014 11:28:32 -0700 (PDT) Received: by 10.140.48.105 with HTTP; Fri, 17 Oct 2014 11:28:32 -0700 (PDT) Date: Fri, 17 Oct 2014 11:28:32 -0700 Message-ID: Subject: IPv6 stacks responds to all node link local multicast NS From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 18:28:34 -0000 This probably is more of a compliance issue (or may be not as the NS receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 does not talk about it). The neighbor solicitation message format says this: http://tools.ietf.org/html/rfc4861#page-22 Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address. Is it safe to assume that this is a MUST? If yes, nd6_ns_input right now only checks if the destination is a multicast or not (the check is more strict for DAD NS packets) and therefore allows all node link local multicast address resolution NS packets and process them completely (creates neighbor cache, responds with NA etc). The fix is simple, however I wanted to know if there was some reason to have it like this in the first place?: */** ** Attaching target link-layer address to the NA?* ** (RFC 2461 7.2.4)* **** * NS IP dst is unicast/anycast MUST NOT add* ** NS IP dst is solicited-node multicast MUST add** ** ** In implementation, we add target link-layer address by default.* ** We do not add one in MUST NOT cases.** */* if (!IN6_IS_ADDR_MULTICAST (&daddr6)) tlladdr = 0; else tlladdr = 1; From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 20:28:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E39B2F06; Fri, 17 Oct 2014 20:28:35 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95FFEA0C; Fri, 17 Oct 2014 20:28:35 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9HKSGKP045196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Oct 2014 13:28:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54417BD8.30603@freebsd.org> Date: Sat, 18 Oct 2014 04:28:08 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marko Zec , Marius Strobl Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> <20141017113737.GA16736@alchemy.franken.de> <20141017135142.3f5a713c@x23> In-Reply-To: <20141017135142.3f5a713c@x23> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , Adrian Chadd , "freebsd-virtualization@freebsd.org" , FreeBSD Net , freebsd-arch , Kris Moore X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 20:28:36 -0000 On 10/17/14, 7:51 PM, Marko Zec wrote: > On Fri, 17 Oct 2014 13:37:37 +0200 > Marius Strobl wrote: > >> On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: >>> On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: >>> >>>> It was for a while in 9.2, but we removed it from 10.0 and later >>>> due to stability issues we kept getting reports about. Haven't >>>> tried it since then, dont know if those issues are fixed. >>>> >>> I fixed some of the problems with VIMAGE that I encountered with >>> Bluetooth: >>> >>> https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html >> ... which still lacks a proper implementation that doesn't constitute >> a gross layering violation in generic bus code. > By all means please go ahead and propose a layering-clean alternative, > not as ugly and intrusive as this part which I assume bodes you eyes: > > - return (device_attach(dev)); > + > + CURVNET_SET_QUIET(vnet0); > + error = device_attach(dev); > + CURVNET_RESTORE(); > + return error; > > Marko > I think he means the entire bluetooth implementation, which is done from within netgraph. >>> Hiroo Onoo submitted this patch, which I committed to fix problems >>> with VIMAGE encountered with removable USB Ethernet: >>> >>> https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html >>> >>> Martin Matuska committed this fix for PF: >>> https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html >>> >>> So a lot of the stability problems with VIMAGE which were in PC-BSD >>> 9.2 and FreeBSD 9.x have been slowly been fixed. >> Marius >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 21:42:06 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86A2A547 for ; Fri, 17 Oct 2014 21:42:06 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CF60194 for ; Fri, 17 Oct 2014 21:42:06 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9HLg6kj077491 for ; Fri, 17 Oct 2014 21:42:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Fri, 17 Oct 2014 21:42:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 21:42:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #10 from Garrett Cooper --- (In reply to Eric Joyner from comment #8) > So it sounds like we may just need to change IXGBE_RX_COPY_LEN from a fixed > value of 160 to something that's calculated based on the length of struct > m_hdr and struct m_pkthdr combined. > > I think they got 160 by adding together the size of the two header structs > (88 in FreeBSD amd64), adding some number (8) to make that size divisible by > 32 (96 % 32 == 0), and then subtracted that from MSIZE (256) to get > IXGBE_RX_COPY_LEN (160), while keeping the padding added as > IXGBE_RX_COPY_ALIGN. A couple questions then: - What architectures is this driver supported on? - Is this optimization only valid for amd64? - Why 32? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 23:20:00 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BB41614 for ; Fri, 17 Oct 2014 23:20:00 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 126FCC1F for ; Fri, 17 Oct 2014 23:20:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9HNJxCF084766 for ; Fri, 17 Oct 2014 23:19:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189404] [msk] msk0:watch dog time out Date: Fri, 17 Oct 2014 23:20:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 23:20:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189404 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|amd64 |kern Assignee|freebsd-amd64@FreeBSD.org |freebsd-net@FreeBSD.org Summary|msk0:watch dog time out |[msk] msk0:watch dog time | |out --- Comment #1 from Mark Linimon --- Reclassify. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 23:26:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5906D737 for ; Fri, 17 Oct 2014 23:26:13 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16975D06 for ; Fri, 17 Oct 2014 23:26:13 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id le20so1343061vcb.12 for ; Fri, 17 Oct 2014 16:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Dihv2lgae3p6RqvrpktgTtuDTK0qACUz0cJM4wy5CU=; b=CvaAkPPjmnCKFxvJfl+Io/KIg+iFPQZoY+qRiRLpq4gZXfUg2wGosEap9KvBM6+k/8 GKSW0c/FJFsYuhTnYjd9I5onCj+SvBgmbaoHxrCN55SB7Ta8NMBLmDJeZV3M0QXAy3j4 dR5CzwtY+Rr9Tp98tbJ04APagC73l4iJghLDLDEnqGeu2G9gwYRUcC8SkgFSaOGvpENO 1Ls99yKSZnGjpmyp5xGOhpcqKsedehkgANjkbTZ362J7mgQYr/AmEUNh8fT/MFspTPhG ThoTLSmgIMRDN7rTmeu6Wm3njOf2eZgSu9uFHKi9GrrU8JsmdAxRuca922B9WJH7jcir cMyw== MIME-Version: 1.0 X-Received: by 10.221.46.4 with SMTP id um4mr9957382vcb.23.1413588372065; Fri, 17 Oct 2014 16:26:12 -0700 (PDT) Received: by 10.220.238.14 with HTTP; Fri, 17 Oct 2014 16:26:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Oct 2014 19:26:12 -0400 Message-ID: Subject: Re: IPv6 stacks responds to all node link local multicast NS From: Zaphod Beeblebrox To: prabhakar lakhera Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Oct 2014 23:26:13 -0000 Urm ... question: is NS how, then, a client should be getting an IP over PPP? I have an l2tp server configured with mpd ... and I've noticed that mpd will allow me to turn on ipv6, but it won't assign addresses like ipv4. On Fri, Oct 17, 2014 at 2:28 PM, prabhakar lakhera < prabhakar.lakhera@gmail.com> wrote: > This probably is more of a compliance issue (or may be not as the NS > receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 > does > not talk about it). > > The neighbor solicitation message format says this: > > http://tools.ietf.org/html/rfc4861#page-22 > > > Destination Address > Either the solicited-node multicast address > corresponding to the target address, or the target > address. > > > Is it safe to assume that this is a MUST? > If yes, nd6_ns_input right now only checks if the destination is a > multicast or not (the check is more strict for DAD NS packets) and > therefore allows all node link local multicast address resolution NS > packets and process them completely (creates neighbor cache, responds > with NA etc). > > The fix is simple, however I wanted to know if there was some reason > to have it like this in the first place?: > > */** > ** Attaching target link-layer address to the NA?* > ** (RFC 2461 7.2.4)* > **** * NS IP dst is unicast/anycast MUST NOT add* > ** NS IP dst is solicited-node multicast MUST add** ** > ** In implementation, we add target link-layer address by default.* > ** We do not add one in MUST NOT cases.** */* > if (!IN6_IS_ADDR_MULTICAST > < > http://fxr.watson.org/fxr/source/netinet6/ident?v=FREEBSD10;im=bigexcerpts;i=IN6_IS_ADDR_MULTICAST > >(&daddr6)) > tlladdr = 0; > else > tlladdr = 1; > _______________________________________________ > 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 Sat Oct 18 00:02:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E793B1FC; Sat, 18 Oct 2014 00:02:42 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 598AF181; Sat, 18 Oct 2014 00:02:42 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id k14so1895192wgh.31 for ; Fri, 17 Oct 2014 17:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:date:to:cc:subject:message-id:mime-version:content-type; bh=YBLOKdX+tbxOuxY6H7z2/0gOI80qC7j0D0YO7O+kf2A=; b=yOqae6RZ9EezJNeOSGGbZ05+RcvjeG9LCMoXQoMwIEyxYA+e5JKxSDD62R3pdZjXoD Pms//YBR5jXBDSFl5BH/tJVS411O+r4m7ptXkS4NXSZxcRalHt8Mv/cwaLL+wNfrxDWm hfNvC5GkO9+MuQGZoi6Mf3UxXlsNraYGjlLvQBuD2XFCLoYZ7TG7lZthW5ht7C8hFXuN jLEYa/4j4Ghlo5QfBvrZR5tzcOzgOHpswiLuw37lnarHIENhzpMwCG2ghx9tmNHuLKpl vJe02mtea5zMtnkLBngs/vBotJL2i7EFBZHATtMFTVtWccLKHFwESkl2Q5TlfJtJ5L+f JZvg== X-Received: by 10.180.74.4 with SMTP id p4mr2444743wiv.20.1413590560261; Fri, 17 Oct 2014 17:02:40 -0700 (PDT) Received: from localhost (citronna.de. [62.210.205.189]) by mx.google.com with ESMTPSA id t16sm480849wjr.44.2014.10.17.17.02.37 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 17:02:39 -0700 (PDT) Sender: Nicolas Braud-Santoni From: Nicolas Braud-Santoni X-Google-Original-From: Nicolas Braud-Santoni Date: Sat, 18 Oct 2014 02:02:27 +0200 To: freebsd-net@freebsd.org Subject: Adding IP_PEERCRED? Message-ID: <20141018020227.68b9a335@braud-santoni.eu> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/yK9yFxL/VONyD27aMUnHDyp"; protocol="application/pgp-signature" Cc: david@madore.org, bapt@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 00:02:43 -0000 --Sig_/yK9yFxL/VONyD27aMUnHDyp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I would like to enquire about the possibility of adding an IP_PEERCRED socket option to ip(4) which would be similar to LOCAL_PEERCRED for unix(4). Such a option, when requested via getsockopt(2) on a not-connectionless IP = (v4 or v6) socket, would either - return credentials of the remote side (as a xucred structure) in the case of a loopback (non-cross-jail) socket; - fail (with EINVAL?). The intended use-case of such a functionnality would be for processes to provide services only to a given user, instead of the local host, while using IP sockets. For instance, an SSH client could use this feature to provide port forwards for a given user, instead of providing it to all users. While bapt@ thought at first glance that it might be a good idea, neither of us know whether it would be reasonable to implement. Any though on this? Best, Nicolas PS: Credit for this idea should go to David Madore (in CC), who blogged about it (in French): http://www.madore.org/~david/weblog/d.2014-10-16.2234.html --Sig_/yK9yFxL/VONyD27aMUnHDyp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUQa4XAAoJEPv4tP2UoeSeuO4P/1yVB1fyF4tKgfZt1pND5xu/ ff8vN86uE7Bqj9d4heucZLSjbF3rmBXJpaqB1xSXW1LNuodsPMbyiV8NgMHzxhVP 7b+i/lejrAo9PdkB5X1MhbTJvaAZVaTwZIo6/oIAe8rZJykKeRP4Dt9eZ/TgHJ+2 Ol2VbmIenwrVwWG21ewLWX55DNPIh0gMWCIr0DDyNZnkFaObfS8fh3KQ6m+ftzEN 3qJ9nZSQF4YrRXoD4lbT9aI6HS5LbPzjFRFNkGhUpMwayEhaYEdZSaZl+3VzmYnd sU1Npm4FO06XBZBb0xCzlokNj+by0eBQ33/SyKuAZNYUggPeHxQM9O+6C4kcrbVN pZTVxFKh43sb3N8sVfzbxCudecPaXangAoBXvNouZxk7JSn66SNebxzVNC00pntk hZT+KhiCewCah6TKzDlBs3L3WsBmBvt+YL9cfNS12vDgbrsJlcREsLogmZNykZmN 6+B9v66Nmqp56rlG6HgthG4N+CSxjL7Jorwx/9kcmQMkvRFQYrKAXd97Y5QzHYfa FAZcCDMTA5/zK8XNmmX9JwfXpIc0hGJxfazQYbCQboBlQifKlQz2YUTXmadVM/AL mkg1ytDe0hGB1ySa2EmmqlLLCClCxN7nSXIAZfDiVV6WTIj6ixOshA2+OkN3t1rt pSLHeMbNTTY2KDYkaYnp =tZiO -----END PGP SIGNATURE----- --Sig_/yK9yFxL/VONyD27aMUnHDyp-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 00:15:59 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 282833E0 for ; Sat, 18 Oct 2014 00:15:59 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EBB126B for ; Sat, 18 Oct 2014 00:15:59 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9I0FwKi071618 for ; Sat, 18 Oct 2014 00:15:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Sat, 18 Oct 2014 00:15:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 00:15:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #11 from Garrett Cooper --- (In reply to Garrett Cooper from comment #10) ... > - What architectures is this driver supported on? What I was really driving at with this question is "What architectures does Intel support this driver on?" -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 02:00:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDE13EE3; Sat, 18 Oct 2014 02:00:39 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6533ECBA; Sat, 18 Oct 2014 02:00:39 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so1974540wgg.3 for ; Fri, 17 Oct 2014 19:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=09FgOEsufLf/V7not3RW6aIJtGYMeseSUPSW7fRjh3c=; b=whCUIZrdNRE7TJCBxoJBc2gADxGkF/9owBfuo5MKZtu8clQPpwE+LlwewCGkQsvoU2 2w7/Wdne9AM6gXGCtNthhw6HL5sj8j/hQ5z1f1OO/z6/mx5dLin7UxbK6oqSoEQfsaQX FqOMizHt5qI8r7/hNVT8OD7whsjIFNa2e4R0tZp0IOR1GpQRHXePE7H8uhxC8Yljtr1O Nhnz4L1QKE2UGURsTumgJdc26aDUzIIznMv6dR3J4yrC++Atatc95DNXaAvP59pN4Prx boSlSpDG4hKMCZBpQZAiacSUNXLdtiedUdM38K/ekAVTzADGDyJ1y5Vq08ZUj42USPzw 4MVw== MIME-Version: 1.0 X-Received: by 10.181.27.197 with SMTP id ji5mr2893426wid.26.1413597637504; Fri, 17 Oct 2014 19:00:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 17 Oct 2014 19:00:37 -0700 (PDT) In-Reply-To: <20141018020227.68b9a335@braud-santoni.eu> References: <20141018020227.68b9a335@braud-santoni.eu> Date: Fri, 17 Oct 2014 19:00:37 -0700 X-Google-Sender-Auth: XOCvksg4FEqJEKZAJ2DxlJDB7fA Message-ID: Subject: Re: Adding IP_PEERCRED? From: Adrian Chadd To: Nicolas Braud-Santoni Content-Type: text/plain; charset=UTF-8 Cc: david@madore.org, FreeBSD Net , Baptiste Daroussin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 02:00:40 -0000 Sure! Put together a patch and let's review it. -a On 17 October 2014 17:02, Nicolas Braud-Santoni wrote: > Hello, > > I would like to enquire about the possibility of adding an IP_PEERCRED > socket option to ip(4) which would be similar to LOCAL_PEERCRED for > unix(4). > > Such a option, when requested via getsockopt(2) on a not-connectionless IP (v4 or v6) socket, would either > - return credentials of the remote side (as a xucred structure) in the > case of a loopback (non-cross-jail) socket; > - fail (with EINVAL?). > > > The intended use-case of such a functionnality would be for processes > to provide services only to a given user, instead of the local host, > while using IP sockets. > For instance, an SSH client could use this feature to provide port > forwards for a given user, instead of providing it to all users. > > While bapt@ thought at first glance that it might be a good idea, > neither of us know whether it would be reasonable to implement. > Any though on this? > > > Best, > > Nicolas > > PS: Credit for this idea should go to David Madore (in CC), who blogged > about it (in French): > http://www.madore.org/~david/weblog/d.2014-10-16.2234.html From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 05:39:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83615292 for ; Sat, 18 Oct 2014 05:39:59 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4551E7 for ; Sat, 18 Oct 2014 05:39:58 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9I5dbRH006313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Oct 2014 14:39:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9I5dZxJ027004; Sat, 18 Oct 2014 14:39:37 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 18 Oct 2014 14:39:19 +0900 (JST) Message-Id: <20141018.143919.1930138986692891609.hrs@allbsd.org> To: prabhakar.lakhera@gmail.com Subject: Re: IPv6 stacks responds to all node link local multicast NS From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Oct_18_14_39_19_2014_503)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sat, 18 Oct 2014 14:39:52 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 05:39:59 -0000 ----Security_Multipart(Sat_Oct_18_14_39_19_2014_503)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit prabhakar lakhera wrote in : pr> This probably is more of a compliance issue (or may be not as the NS pr> receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 does pr> not talk about it). pr> pr> The neighbor solicitation message format says this: pr> pr> http://tools.ietf.org/html/rfc4861#page-22 pr> pr> pr> Destination Address pr> Either the solicited-node multicast address pr> corresponding to the target address, or the target pr> address. pr> pr> pr> Is it safe to assume that this is a MUST? pr> If yes, nd6_ns_input right now only checks if the destination is a pr> multicast or not (the check is more strict for DAD NS packets) and pr> therefore allows all node link local multicast address resolution NS pr> packets and process them completely (creates neighbor cache, responds pr> with NA etc). What is the problem when accepting NS messages to ff02::1? -- Hiroki ----Security_Multipart(Sat_Oct_18_14_39_19_2014_503)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlRB/QcACgkQTyzT2CeTzy05zgCfX7tp1YrsWIoqhmlsFh6RMWxQ Sy4AnRvygNCEvFSxPu38aPZFFBiDdNoj =cslZ -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Oct_18_14_39_19_2014_503)---- From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 06:32:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A593262C; Sat, 18 Oct 2014 06:32:14 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF1F58A1; Sat, 18 Oct 2014 06:32:13 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hi2so2724384wib.8 for ; Fri, 17 Oct 2014 23:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/gqZjIbdPA5XTumcCvXb6qOTGdTVR72ptU1ltu+YG90=; b=E77vhtrAlQisrBZOvToIL45sjfAb96tl67nb4Dv1oSY/RFpgxWRjcB8M2s24wsoLZh vOg1CHG6/VsPrihxk+CTn8PQarc+1CAN7Ay8uOQ/ZzXkkt+dDPBeNhpw6kNMfryN6FFr j4O1LegC7aSjtNcV0SaXhKxpQX00YIShNsuaW/T1ugjtzrOeWN0wZs/kYQPpzn15IpLs 8zB724wm0qhQB0TgyIfNPA7PxniNQakV7JZUVDmq6F5LVDcABNbtIx2LkOSBi3qevS2S J3srxb427+kNJzbA4Y30fRbTpmF3uU/92sZe1jGuGR1VQDjdk59wbQlv/FDMcBJHHDzu cuMg== MIME-Version: 1.0 X-Received: by 10.180.208.101 with SMTP id md5mr4074063wic.9.1413613931908; Fri, 17 Oct 2014 23:32:11 -0700 (PDT) Received: by 10.217.67.201 with HTTP; Fri, 17 Oct 2014 23:32:11 -0700 (PDT) In-Reply-To: <201410161523.32415.jhb@freebsd.org> References: <1410203348.1343.1.camel@bruno> <3567780.Mf6fMnzmYG@ralph.baldwin.cx> <201410161523.32415.jhb@freebsd.org> Date: Fri, 17 Oct 2014 23:32:11 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 06:32:14 -0000 On Thu, Oct 16, 2014 at 12:23 PM, John Baldwin wrote: > > > I looked at the other trace and I don't think it disagrees with my previous > theory. I do have more KTR patches to log when we spin on locks which would > really confirm this, but I haven't tested those fully on HEAD yet. > > However, I'd rather spend time debugging this panic. I think I added that > assertion myself. > > The root problem is that the persist and retransmit timers share state, > so only one should ever be active at a time. In this case, the persist > timer has fired and is rescheduling itself, but some other thread has > scheduled the retransmit timer to fire. The bug is probably in that other > thread. It should either not scheduled the retransmit timer, or it should > first cancel the persist timer. > > A new assertion should be able to find this. Note, this is definitely going > to panic, but one panic is probably enough to find this. > > Index: tcp_timer.c > =================================================================== > --- tcp_timer.c (revision 272718) > +++ tcp_timer.c (working copy) > @@ -713,10 +713,14 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ > case TT_REXMT: > t_callout = &tp->t_timers->tt_rexmt; > f_callout = tcp_timer_rexmt; > + if (callout_active(&tp->t_timers->tt_persist)) > + panic("scheduling retransmit with persist active"); > break; > case TT_PERSIST: > t_callout = &tp->t_timers->tt_persist; > f_callout = tcp_timer_persist; > + if (callout_active(&tp->t_timers->tt_rexmt)) > + panic("scheduling persist with retransmit active"); > break; > case TT_KEEP: > t_callout = &tp->t_timers->tt_keep; > > -- > John Baldwin Producing 10G of random traffic against a server with this assertion added took about 2 hours to panic, so if it turns out we need anything further it should be pretty quick. #1 0xffffffff806facb1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff806fb014 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff8084edba in tcp_timer_activate (tp=0x0, timer_type=, delta=0) at /usr/src/sys/netinet/tcp_timer.c:695 #4 0xffffffff80841bad in tcp_do_segment (m=0xfffff80019898d00, th=0xfffff80019898d82, so=0xfffff8026cafaae0, tp=, drop_hdrlen=, tlen=0, iptos=, ti_locked=-2047) at /usr/src/sys/netinet/tcp_input.c:2821 #5 0xffffffff8083f748 in tcp_input (m=, off0=) at /usr/src/sys/netinet/tcp_input.c:1388 #6 0xffffffff807dc707 in ip_input (m=0xfffff80019898d00) at /usr/src/sys/netinet/ip_input.c:734 #7 0xffffffff807b8a61 in netisr_dispatch_src (proto=, source=, m=0x0) at /usr/src/sys/net/netisr.c:972 #8 0xffffffff807b1f06 in ether_demux (ifp=, m=0xfffff80019898d00) at /usr/src/sys/net/if_ethersubr.c:851 #9 0xffffffff807b2b99 in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:646 #10 0xffffffff807b8a61 in netisr_dispatch_src (proto=, source=, m=0x0) at /usr/src/sys/net/netisr.c:972 #11 0xffffffff80843f68 in tcp_lro_flush (lc=0xfffff8000e6f7188, le=0xfffff80019335380) at /usr/src/sys/netinet/tcp_lro.c:301 #12 0xffffffff80844563 in tcp_lro_rx (lc=0x0, m=, csum=) at /usr/src/sys/netinet/tcp_lro.c:515 #13 0xffffffff804a6622 in ixgbe_rxeof (que=0xfffff8000e702068) at /usr/src/sys/dev/ixgbe/ixgbe.c:4356 #14 0xffffffff804a6cd9 in ixgbe_msix_que (arg=0xfffff8000e702068) at /usr/src/sys/dev/ixgbe/ixgbe.c:1523 #15 0xffffffff806d16f3 in intr_event_execute_handlers (p=, ie=0xfffff8000e6fcb00) at /usr/src/sys/kern/kern_intr.c:1263 ---Type to continue, or q to quit--- #16 0xffffffff806d2056 in ithread_loop (arg=0xfffff8000e719ac0) at /usr/src/sys/kern/kern_intr.c:1276 #17 0xffffffff806cf481 in fork_exit (callout=0xffffffff806d1fc0 , arg=0xfffff8000e719ac0, frame=0xfffffe0f9558cac0) at /usr/src/sys/kern/kern_fork.c:996 #4 list 2816 * timer and remember to restart (more output or persist). 2817 * If there is more data to be acked, restart retransmit 2818 * timer, using current (possibly backed-off) value. 2819 */ 2820 if (th->th_ack == tp->snd_max) { 2821 tcp_timer_activate(tp, TT_REXMT, 0); 2822 needoutput = 1; 2823 } else if (!tcp_timer_active(tp, TT_PERSIST)) 2824 tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur); #5 list 1383 /* 1384 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or later 1385 * state. tcp_do_segment() always consumes the mbuf chain, unlocks 1386 * the inpcb, and unlocks pcbinfo. 1387 */ 1388 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, ti_locked); 1389 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); 1390 return; 1391 1392 dropwithreset: I believe you just wanted to spot the tcp_do_segment culprit here, but just in case the KTR traces provide any insight.. index cpu timestamp trace ------ --- ---------------- ----- 262 1 5346219888944675 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"running", attributes: prio:8 261 1 5346219888944167 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"idle", attributes: prio:255 260 1 5346219888942623 KTRGRAPH group:"load", id:"CPU 1 load", counter:1, attributes: none 259 1 5346219888942223 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 tid 100061" 258 1 5346219888941935 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, linkedto:"idle: cpu1 tid 100004" 257 4 5346219888867655 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 256 4 5346219888866671 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 255 4 5346219888866427 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 254 4 5346219888866075 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 253 3 5346219888839020 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 252 4 5346219888838543 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 251 3 5346219888837884 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 250 3 5346219888837504 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 249 4 5346219888836847 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 248 3 5346219888834744 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 247 3 5346219888833740 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 246 3 5346219888833532 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 245 4 5346219888833383 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 244 4 5346219888831951 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 243 4 5346219888831427 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 242 4 5346219888830775 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 241 3 5346219888805468 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 240 3 5346219888804072 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 239 4 5346219888802939 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 238 4 5346219888802067 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 237 4 5346219888801835 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 236 2 5346219888779438 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 235 2 5346219888778694 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 234 2 5346219888778466 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 233 2 5346219888750994 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 232 2 5346219888749690 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 231 4 5346219888747775 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 230 4 5346219888746907 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 229 4 5346219888746683 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 228 3 5346219888722124 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 227 3 5346219888721356 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 226 3 5346219888721132 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 225 3 5346219888693496 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 224 3 5346219888692108 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 223 4 5346219888690959 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 222 4 5346219888690151 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 221 4 5346219888689835 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 220 3 5346219888664956 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 219 3 5346219888664188 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 218 3 5346219888663956 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 217 3 5346219888636448 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 216 3 5346219888635052 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 215 4 5346219888634055 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 214 4 5346219888633175 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 213 4 5346219888632887 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 212 2 5346219888605666 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 211 2 5346219888604894 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 210 2 5346219888604670 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 209 2 5346219888579382 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 208 2 5346219888578102 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 207 4 5346219888576151 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 206 4 5346219888575307 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 205 4 5346219888575075 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 204 3 5346219888547276 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 203 3 5346219888546492 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 202 3 5346219888546256 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 201 3 5346219888518516 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 200 3 5346219888517144 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 199 4 5346219888515955 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 198 4 5346219888515051 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 197 4 5346219888514763 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 196 3 5346219888471648 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 195 3 5346219888470864 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 194 3 5346219888470608 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 193 3 5346219888444416 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 192 3 5346219888443180 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 191 4 5346219888442191 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 190 4 5346219888441299 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 189 4 5346219888441051 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 188 2 5346219888412126 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 187 2 5346219888411186 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 186 2 5346219888410734 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 185 3 5346219888406268 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 184 3 5346219888405416 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 183 3 5346219888405132 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 182 2 5346219888383370 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 181 2 5346219888382134 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 180 4 5346219888380347 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 179 4 5346219888379675 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 178 4 5346219888379363 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 177 3 5346219888377836 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 176 3 5346219888376464 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 175 4 5346219888375403 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 174 4 5346219888374439 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 173 4 5346219888374215 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 172 3 5346219888322428 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 171 3 5346219888321656 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 170 3 5346219888321352 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 169 3 5346219888293052 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 168 3 5346219888291828 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 167 4 5346219888290659 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 166 4 5346219888289723 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 165 4 5346219888289491 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 164 3 5346219888238840 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 163 3 5346219888237796 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 162 3 5346219888237356 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 161 2 5346219888224558 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 160 2 5346219888223782 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 159 2 5346219888223538 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 158 2 5346219888197174 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 157 2 5346219888195814 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 156 4 5346219888193983 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 155 4 5346219888193331 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 154 4 5346219888193051 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 153 3 5346219888191528 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 152 3 5346219888190324 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 151 4 5346219888189243 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 150 4 5346219888188227 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 149 4 5346219888187943 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 148 3 5346219888117040 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 147 3 5346219888116276 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 146 3 5346219888115840 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 145 1 5346219888098159 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"running", attributes: prio:255 144 1 5346219888097579 KTRGRAPH group:"load", id:"CPU 1 load", counter:0, attributes: none 143 1 5346219888097171 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"iwait", attributes: prio:8, wmesg:"(null)", lockname:"(null)" 142 3 5346219888088152 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 141 3 5346219888086860 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 140 4 5346219888084999 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 139 4 5346219888084087 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 138 4 5346219888083843 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 137 5 5346219888072781 KTRGRAPH group:"thread", id:"idle: cpu5 tid 100008", state:"running", attributes: prio:255 136 5 5346219888072481 KTRGRAPH group:"load", id:"CPU 5 load", counter:0, attributes: none 135 5 5346219888072285 KTRGRAPH group:"thread", id:"ix0 que tid 100062", state:"sleep", attributes: prio:8, wmesg:"-", lockname:"(null)" 134 5 5346219888069689 KTRGRAPH group:"thread", id:"ix0 que tid 100062", state:"running", attributes: prio:8 133 5 5346219888068753 KTRGRAPH group:"thread", id:"idle: cpu5 tid 100008", state:"idle", attributes: prio:255 132 5 5346219888067957 KTRGRAPH group:"thread", id:"idle: cpu5 tid 100008", point:"statclock", attributes: prio:255, stathz:127 131 1 5346219888062719 KTRGRAPH group:"load", id:"CPU 5 load", counter:1, attributes: none 130 1 5346219888061083 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"ix0 que tid 100062" 129 1 5346219888060811 KTRGRAPH group:"thread", id:"ix0 que tid 100062", state:"runq add", attributes: prio:8, linkedto:"irq279: ix0:que 1 tid 100061" 128 4 5346219888029723 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 127 4 5346219888028295 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 126 1 5346219888026515 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 125 1 5346219888025739 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"EP tid 100276" 124 1 5346219888025603 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"irq279: ix0:que 1 tid 100061" 123 1 5346219887987103 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"running", attributes: prio:8 122 1 5346219887986611 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"idle", attributes: prio:255 121 1 5346219887984967 KTRGRAPH group:"load", id:"CPU 1 load", counter:1, attributes: none 120 1 5346219887984507 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 tid 100061" 119 1 5346219887984307 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, linkedto:"idle: cpu1 tid 100004" 118 4 5346219887875887 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 117 4 5346219887874835 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 116 4 5346219887874551 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 115 4 5346219887874139 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 114 3 5346219887848752 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 113 4 5346219887847859 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 112 3 5346219887847580 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 111 3 5346219887847228 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 110 4 5346219887846167 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 109 3 5346219887844428 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 108 3 5346219887843660 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 107 3 5346219887843448 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 106 4 5346219887823135 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 105 4 5346219887821983 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 104 4 5346219887821675 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 103 4 5346219887821231 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 102 3 5346219887817840 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 101 3 5346219887816548 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 100 4 5346219887815395 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 99 4 5346219887814459 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 98 4 5346219887814199 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 97 3 5346219887757636 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 96 4 5346219887757263 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 95 3 5346219887756492 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 94 3 5346219887756104 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 93 4 5346219887755543 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 92 3 5346219887753420 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 91 3 5346219887752476 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 90 3 5346219887752252 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 89 4 5346219887752095 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 88 4 5346219887750663 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 87 4 5346219887750331 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 86 4 5346219887749791 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 85 3 5346219887728324 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 84 3 5346219887727048 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 83 4 5346219887726095 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 82 4 5346219887725167 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 81 4 5346219887724943 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 80 3 5346219887706048 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 79 3 5346219887705260 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 78 3 5346219887705012 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 77 3 5346219887677908 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 76 3 5346219887676408 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 75 4 5346219887675275 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 74 4 5346219887674339 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 73 4 5346219887674067 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 72 3 5346219887643688 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 71 3 5346219887642916 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 70 3 5346219887642648 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 69 3 5346219887615124 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 68 3 5346219887613600 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 67 4 5346219887612439 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 66 4 5346219887611651 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 65 4 5346219887611375 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 64 3 5346219887606948 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 63 3 5346219887606148 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 62 3 5346219887605876 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 61 3 5346219887578020 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 60 3 5346219887576736 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 59 4 5346219887575719 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 58 4 5346219887574663 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 57 4 5346219887574391 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 56 3 5346219887514636 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 55 3 5346219887513536 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 54 3 5346219887513152 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 53 4 5346219887493515 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 52 4 5346219887491871 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 51 3 5346219887489976 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 50 3 5346219887488968 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 49 3 5346219887488688 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 48 4 5346219887488403 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 47 4 5346219887486827 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 46 4 5346219887486411 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 45 4 5346219887485835 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 44 3 5346219887440704 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 43 3 5346219887439212 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 42 4 5346219887438063 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 41 4 5346219887437079 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 40 4 5346219887436799 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 39 2 5346219887370146 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 38 2 5346219887369366 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 37 2 5346219887369102 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 36 2 5346219887340378 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 35 2 5346219887338874 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 34 4 5346219887336903 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 33 4 5346219887335995 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 32 4 5346219887335727 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 31 3 5346219887298672 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 30 3 5346219887297652 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 29 3 5346219887297304 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 28 3 5346219887229996 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 27 3 5346219887228528 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 26 4 5346219887227515 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 25 4 5346219887226503 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 24 4 5346219887226247 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 23 2 5346219887153494 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 22 2 5346219887152702 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 21 2 5346219887152226 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 20 1 5346219887147171 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"running", attributes: prio:255 19 1 5346219887146583 KTRGRAPH group:"load", id:"CPU 1 load", counter:0, attributes: none 18 1 5346219887146179 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"iwait", attributes: prio:8, wmesg:"(null)", lockname:"(null)" 17 2 5346219887125262 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 16 2 5346219887124054 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 15 4 5346219887122139 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 14 4 5346219887121247 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 13 4 5346219887121067 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 12 4 5346219887070771 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 11 4 5346219887069227 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 10 1 5346219887067479 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 9 1 5346219887066659 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"EP tid 100276" 8 1 5346219887066495 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"irq279: ix0:que 1 tid 100061" 7 1 5346219887029563 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"running", attributes: prio:8 6 1 5346219887029143 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"idle", attributes: prio:255 5 1 5346219887027871 KTRGRAPH group:"load", id:"CPU 1 load", counter:1, attributes: none 4 1 5346219887027399 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 tid 100061" 3 1 5346219887027163 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, linkedto:"idle: cpu1 tid 100004" 2 4 5346219886977607 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 1 4 5346219886976619 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 0 4 5346219886976335 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" Jason From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 06:32:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E2F862A; Sat, 18 Oct 2014 06:32:14 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E2208A3; Sat, 18 Oct 2014 06:32:14 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id i138so1554003oig.23 for ; Fri, 17 Oct 2014 23:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/gqZjIbdPA5XTumcCvXb6qOTGdTVR72ptU1ltu+YG90=; b=Q3UwQlIqCHTqi2L5yJ65vsjXQpprEKVsmqIKSVazX9VqycgoArZna4kW6dOSVUqyN8 5NtEdH57U8mguWQyJq7wVdBXAShUq3GC6wGwwRTdxvMGkzPXZW40fIIz7gAWRz3OavoY L8tIC+BF1iuZ6l9k+BF2pj0/3e+F8gaCFvhT6PWeHbbWwF85Y0r6SQjIrtsra0ZfKcrA omdbjZgdLAHGfa5/fFMqOqPlHVs69uD8/LSdV7kMG2M868/+AIUfPbL+30WAZLaK1oH3 XLl/y3t+NgNM0vZeU7Gt7QY/bmRaZ+QoRkfXzDmHSLQRyxPPltBNVqXSGvzDGwEaTL1n lEdA== MIME-Version: 1.0 X-Received: by 10.202.211.133 with SMTP id k127mr555994oig.53.1413613933583; Fri, 17 Oct 2014 23:32:13 -0700 (PDT) Received: by 10.202.200.196 with HTTP; Fri, 17 Oct 2014 23:32:13 -0700 (PDT) In-Reply-To: <201410161523.32415.jhb@freebsd.org> References: <1410203348.1343.1.camel@bruno> <3567780.Mf6fMnzmYG@ralph.baldwin.cx> <201410161523.32415.jhb@freebsd.org> Date: Fri, 17 Oct 2014 23:32:13 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 06:32:14 -0000 On Thu, Oct 16, 2014 at 12:23 PM, John Baldwin wrote: > > > I looked at the other trace and I don't think it disagrees with my previous > theory. I do have more KTR patches to log when we spin on locks which would > really confirm this, but I haven't tested those fully on HEAD yet. > > However, I'd rather spend time debugging this panic. I think I added that > assertion myself. > > The root problem is that the persist and retransmit timers share state, > so only one should ever be active at a time. In this case, the persist > timer has fired and is rescheduling itself, but some other thread has > scheduled the retransmit timer to fire. The bug is probably in that other > thread. It should either not scheduled the retransmit timer, or it should > first cancel the persist timer. > > A new assertion should be able to find this. Note, this is definitely going > to panic, but one panic is probably enough to find this. > > Index: tcp_timer.c > =================================================================== > --- tcp_timer.c (revision 272718) > +++ tcp_timer.c (working copy) > @@ -713,10 +713,14 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ > case TT_REXMT: > t_callout = &tp->t_timers->tt_rexmt; > f_callout = tcp_timer_rexmt; > + if (callout_active(&tp->t_timers->tt_persist)) > + panic("scheduling retransmit with persist active"); > break; > case TT_PERSIST: > t_callout = &tp->t_timers->tt_persist; > f_callout = tcp_timer_persist; > + if (callout_active(&tp->t_timers->tt_rexmt)) > + panic("scheduling persist with retransmit active"); > break; > case TT_KEEP: > t_callout = &tp->t_timers->tt_keep; > > -- > John Baldwin Producing 10G of random traffic against a server with this assertion added took about 2 hours to panic, so if it turns out we need anything further it should be pretty quick. #1 0xffffffff806facb1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff806fb014 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff8084edba in tcp_timer_activate (tp=0x0, timer_type=, delta=0) at /usr/src/sys/netinet/tcp_timer.c:695 #4 0xffffffff80841bad in tcp_do_segment (m=0xfffff80019898d00, th=0xfffff80019898d82, so=0xfffff8026cafaae0, tp=, drop_hdrlen=, tlen=0, iptos=, ti_locked=-2047) at /usr/src/sys/netinet/tcp_input.c:2821 #5 0xffffffff8083f748 in tcp_input (m=, off0=) at /usr/src/sys/netinet/tcp_input.c:1388 #6 0xffffffff807dc707 in ip_input (m=0xfffff80019898d00) at /usr/src/sys/netinet/ip_input.c:734 #7 0xffffffff807b8a61 in netisr_dispatch_src (proto=, source=, m=0x0) at /usr/src/sys/net/netisr.c:972 #8 0xffffffff807b1f06 in ether_demux (ifp=, m=0xfffff80019898d00) at /usr/src/sys/net/if_ethersubr.c:851 #9 0xffffffff807b2b99 in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:646 #10 0xffffffff807b8a61 in netisr_dispatch_src (proto=, source=, m=0x0) at /usr/src/sys/net/netisr.c:972 #11 0xffffffff80843f68 in tcp_lro_flush (lc=0xfffff8000e6f7188, le=0xfffff80019335380) at /usr/src/sys/netinet/tcp_lro.c:301 #12 0xffffffff80844563 in tcp_lro_rx (lc=0x0, m=, csum=) at /usr/src/sys/netinet/tcp_lro.c:515 #13 0xffffffff804a6622 in ixgbe_rxeof (que=0xfffff8000e702068) at /usr/src/sys/dev/ixgbe/ixgbe.c:4356 #14 0xffffffff804a6cd9 in ixgbe_msix_que (arg=0xfffff8000e702068) at /usr/src/sys/dev/ixgbe/ixgbe.c:1523 #15 0xffffffff806d16f3 in intr_event_execute_handlers (p=, ie=0xfffff8000e6fcb00) at /usr/src/sys/kern/kern_intr.c:1263 ---Type to continue, or q to quit--- #16 0xffffffff806d2056 in ithread_loop (arg=0xfffff8000e719ac0) at /usr/src/sys/kern/kern_intr.c:1276 #17 0xffffffff806cf481 in fork_exit (callout=0xffffffff806d1fc0 , arg=0xfffff8000e719ac0, frame=0xfffffe0f9558cac0) at /usr/src/sys/kern/kern_fork.c:996 #4 list 2816 * timer and remember to restart (more output or persist). 2817 * If there is more data to be acked, restart retransmit 2818 * timer, using current (possibly backed-off) value. 2819 */ 2820 if (th->th_ack == tp->snd_max) { 2821 tcp_timer_activate(tp, TT_REXMT, 0); 2822 needoutput = 1; 2823 } else if (!tcp_timer_active(tp, TT_PERSIST)) 2824 tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur); #5 list 1383 /* 1384 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or later 1385 * state. tcp_do_segment() always consumes the mbuf chain, unlocks 1386 * the inpcb, and unlocks pcbinfo. 1387 */ 1388 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, ti_locked); 1389 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); 1390 return; 1391 1392 dropwithreset: I believe you just wanted to spot the tcp_do_segment culprit here, but just in case the KTR traces provide any insight.. index cpu timestamp trace ------ --- ---------------- ----- 262 1 5346219888944675 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"running", attributes: prio:8 261 1 5346219888944167 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"idle", attributes: prio:255 260 1 5346219888942623 KTRGRAPH group:"load", id:"CPU 1 load", counter:1, attributes: none 259 1 5346219888942223 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 tid 100061" 258 1 5346219888941935 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, linkedto:"idle: cpu1 tid 100004" 257 4 5346219888867655 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 256 4 5346219888866671 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 255 4 5346219888866427 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 254 4 5346219888866075 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 253 3 5346219888839020 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 252 4 5346219888838543 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 251 3 5346219888837884 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 250 3 5346219888837504 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 249 4 5346219888836847 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 248 3 5346219888834744 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 247 3 5346219888833740 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 246 3 5346219888833532 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 245 4 5346219888833383 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 244 4 5346219888831951 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 243 4 5346219888831427 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 242 4 5346219888830775 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 241 3 5346219888805468 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 240 3 5346219888804072 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 239 4 5346219888802939 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 238 4 5346219888802067 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 237 4 5346219888801835 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 236 2 5346219888779438 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 235 2 5346219888778694 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 234 2 5346219888778466 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 233 2 5346219888750994 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 232 2 5346219888749690 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 231 4 5346219888747775 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 230 4 5346219888746907 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 229 4 5346219888746683 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 228 3 5346219888722124 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 227 3 5346219888721356 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 226 3 5346219888721132 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 225 3 5346219888693496 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 224 3 5346219888692108 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 223 4 5346219888690959 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 222 4 5346219888690151 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 221 4 5346219888689835 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 220 3 5346219888664956 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 219 3 5346219888664188 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 218 3 5346219888663956 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 217 3 5346219888636448 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 216 3 5346219888635052 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 215 4 5346219888634055 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 214 4 5346219888633175 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 213 4 5346219888632887 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 212 2 5346219888605666 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 211 2 5346219888604894 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 210 2 5346219888604670 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 209 2 5346219888579382 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 208 2 5346219888578102 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 207 4 5346219888576151 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 206 4 5346219888575307 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 205 4 5346219888575075 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 204 3 5346219888547276 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 203 3 5346219888546492 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 202 3 5346219888546256 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 201 3 5346219888518516 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 200 3 5346219888517144 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 199 4 5346219888515955 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 198 4 5346219888515051 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 197 4 5346219888514763 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 196 3 5346219888471648 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 195 3 5346219888470864 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 194 3 5346219888470608 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 193 3 5346219888444416 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 192 3 5346219888443180 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 191 4 5346219888442191 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 190 4 5346219888441299 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 189 4 5346219888441051 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 188 2 5346219888412126 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 187 2 5346219888411186 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 186 2 5346219888410734 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 185 3 5346219888406268 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 184 3 5346219888405416 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 183 3 5346219888405132 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 182 2 5346219888383370 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 181 2 5346219888382134 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 180 4 5346219888380347 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 179 4 5346219888379675 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 178 4 5346219888379363 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 177 3 5346219888377836 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 176 3 5346219888376464 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 175 4 5346219888375403 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 174 4 5346219888374439 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 173 4 5346219888374215 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 172 3 5346219888322428 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 171 3 5346219888321656 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 170 3 5346219888321352 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 169 3 5346219888293052 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 168 3 5346219888291828 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 167 4 5346219888290659 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 166 4 5346219888289723 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 165 4 5346219888289491 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 164 3 5346219888238840 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 163 3 5346219888237796 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 162 3 5346219888237356 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 161 2 5346219888224558 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 160 2 5346219888223782 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 159 2 5346219888223538 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 158 2 5346219888197174 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 157 2 5346219888195814 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 156 4 5346219888193983 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 155 4 5346219888193331 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 154 4 5346219888193051 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 153 3 5346219888191528 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 152 3 5346219888190324 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 151 4 5346219888189243 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 150 4 5346219888188227 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 149 4 5346219888187943 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 148 3 5346219888117040 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 147 3 5346219888116276 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 146 3 5346219888115840 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 145 1 5346219888098159 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"running", attributes: prio:255 144 1 5346219888097579 KTRGRAPH group:"load", id:"CPU 1 load", counter:0, attributes: none 143 1 5346219888097171 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"iwait", attributes: prio:8, wmesg:"(null)", lockname:"(null)" 142 3 5346219888088152 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 141 3 5346219888086860 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 140 4 5346219888084999 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 139 4 5346219888084087 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 138 4 5346219888083843 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 137 5 5346219888072781 KTRGRAPH group:"thread", id:"idle: cpu5 tid 100008", state:"running", attributes: prio:255 136 5 5346219888072481 KTRGRAPH group:"load", id:"CPU 5 load", counter:0, attributes: none 135 5 5346219888072285 KTRGRAPH group:"thread", id:"ix0 que tid 100062", state:"sleep", attributes: prio:8, wmesg:"-", lockname:"(null)" 134 5 5346219888069689 KTRGRAPH group:"thread", id:"ix0 que tid 100062", state:"running", attributes: prio:8 133 5 5346219888068753 KTRGRAPH group:"thread", id:"idle: cpu5 tid 100008", state:"idle", attributes: prio:255 132 5 5346219888067957 KTRGRAPH group:"thread", id:"idle: cpu5 tid 100008", point:"statclock", attributes: prio:255, stathz:127 131 1 5346219888062719 KTRGRAPH group:"load", id:"CPU 5 load", counter:1, attributes: none 130 1 5346219888061083 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"ix0 que tid 100062" 129 1 5346219888060811 KTRGRAPH group:"thread", id:"ix0 que tid 100062", state:"runq add", attributes: prio:8, linkedto:"irq279: ix0:que 1 tid 100061" 128 4 5346219888029723 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 127 4 5346219888028295 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 126 1 5346219888026515 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 125 1 5346219888025739 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"EP tid 100276" 124 1 5346219888025603 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"irq279: ix0:que 1 tid 100061" 123 1 5346219887987103 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"running", attributes: prio:8 122 1 5346219887986611 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"idle", attributes: prio:255 121 1 5346219887984967 KTRGRAPH group:"load", id:"CPU 1 load", counter:1, attributes: none 120 1 5346219887984507 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 tid 100061" 119 1 5346219887984307 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, linkedto:"idle: cpu1 tid 100004" 118 4 5346219887875887 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 117 4 5346219887874835 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 116 4 5346219887874551 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 115 4 5346219887874139 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 114 3 5346219887848752 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 113 4 5346219887847859 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 112 3 5346219887847580 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 111 3 5346219887847228 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 110 4 5346219887846167 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 109 3 5346219887844428 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 108 3 5346219887843660 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 107 3 5346219887843448 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 106 4 5346219887823135 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 105 4 5346219887821983 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 104 4 5346219887821675 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 103 4 5346219887821231 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 102 3 5346219887817840 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 101 3 5346219887816548 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 100 4 5346219887815395 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 99 4 5346219887814459 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 98 4 5346219887814199 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 97 3 5346219887757636 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 96 4 5346219887757263 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 95 3 5346219887756492 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 94 3 5346219887756104 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 93 4 5346219887755543 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 92 3 5346219887753420 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 91 3 5346219887752476 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 90 3 5346219887752252 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 89 4 5346219887752095 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 88 4 5346219887750663 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 87 4 5346219887750331 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 86 4 5346219887749791 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 85 3 5346219887728324 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 84 3 5346219887727048 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 83 4 5346219887726095 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 82 4 5346219887725167 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 81 4 5346219887724943 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 80 3 5346219887706048 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 79 3 5346219887705260 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 78 3 5346219887705012 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 77 3 5346219887677908 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 76 3 5346219887676408 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 75 4 5346219887675275 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 74 4 5346219887674339 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 73 4 5346219887674067 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 72 3 5346219887643688 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 71 3 5346219887642916 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 70 3 5346219887642648 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 69 3 5346219887615124 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 68 3 5346219887613600 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 67 4 5346219887612439 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 66 4 5346219887611651 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 65 4 5346219887611375 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 64 3 5346219887606948 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 63 3 5346219887606148 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 62 3 5346219887605876 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 61 3 5346219887578020 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 60 3 5346219887576736 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 59 4 5346219887575719 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 58 4 5346219887574663 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 57 4 5346219887574391 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 56 3 5346219887514636 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 55 3 5346219887513536 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 54 3 5346219887513152 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 53 4 5346219887493515 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 52 4 5346219887491871 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 51 3 5346219887489976 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 50 3 5346219887488968 KTRGRAPH group:"thread", id:"dfetch tid 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" 49 3 5346219887488688 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid 100281" 48 4 5346219887488403 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 47 4 5346219887486827 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 46 4 5346219887486411 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" 45 4 5346219887485835 KTRGRAPH group:"thread", id:"EP tid 100276", point:"prio", attributes: prio:201, new prio:152, linkedto:"EP tid 100276" 44 3 5346219887440704 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 43 3 5346219887439212 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 42 4 5346219887438063 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 41 4 5346219887437079 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 40 4 5346219887436799 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 39 2 5346219887370146 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 38 2 5346219887369366 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 37 2 5346219887369102 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 36 2 5346219887340378 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 35 2 5346219887338874 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 34 4 5346219887336903 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 33 4 5346219887335995 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 32 4 5346219887335727 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 31 3 5346219887298672 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"running", attributes: prio:255 30 3 5346219887297652 KTRGRAPH group:"load", id:"CPU 3 load", counter:0, attributes: none 29 3 5346219887297304 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", lockname:"(null)" 28 3 5346219887229996 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"running", attributes: prio:139 27 3 5346219887228528 KTRGRAPH group:"thread", id:"idle: cpu3 tid 100006", state:"idle", attributes: prio:255 26 4 5346219887227515 KTRGRAPH group:"load", id:"CPU 3 load", counter:1, attributes: none 25 4 5346219887226503 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" 24 4 5346219887226247 KTRGRAPH group:"thread", id:"dfetch tid 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid 100276" 23 2 5346219887153494 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"running", attributes: prio:255 22 2 5346219887152702 KTRGRAPH group:"load", id:"CPU 2 load", counter:0, attributes: none 21 2 5346219887152226 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", lockname:"(null)" 20 1 5346219887147171 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"running", attributes: prio:255 19 1 5346219887146583 KTRGRAPH group:"load", id:"CPU 1 load", counter:0, attributes: none 18 1 5346219887146179 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"iwait", attributes: prio:8, wmesg:"(null)", lockname:"(null)" 17 2 5346219887125262 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"running", attributes: prio:123 16 2 5346219887124054 KTRGRAPH group:"thread", id:"idle: cpu2 tid 100005", state:"idle", attributes: prio:255 15 4 5346219887122139 KTRGRAPH group:"load", id:"CPU 2 load", counter:1, attributes: none 14 4 5346219887121247 KTRGRAPH group:"thread", id:"EP tid 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" 13 4 5346219887121067 KTRGRAPH group:"thread", id:"dfetch tid 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid 100276" 12 4 5346219887070771 KTRGRAPH group:"thread", id:"EP tid 100276", state:"running", attributes: prio:152 11 4 5346219887069227 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"idle", attributes: prio:255 10 1 5346219887067479 KTRGRAPH group:"load", id:"CPU 4 load", counter:1, attributes: none 9 1 5346219887066659 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"EP tid 100276" 8 1 5346219887066495 KTRGRAPH group:"thread", id:"EP tid 100276", state:"runq add", attributes: prio:152, linkedto:"irq279: ix0:que 1 tid 100061" 7 1 5346219887029563 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"running", attributes: prio:8 6 1 5346219887029143 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", state:"idle", attributes: prio:255 5 1 5346219887027871 KTRGRAPH group:"load", id:"CPU 1 load", counter:1, attributes: none 4 1 5346219887027399 KTRGRAPH group:"thread", id:"idle: cpu1 tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 tid 100061" 3 1 5346219887027163 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, linkedto:"idle: cpu1 tid 100004" 2 4 5346219886977607 KTRGRAPH group:"thread", id:"idle: cpu4 tid 100007", state:"running", attributes: prio:255 1 4 5346219886976619 KTRGRAPH group:"load", id:"CPU 4 load", counter:0, attributes: none 0 4 5346219886976335 KTRGRAPH group:"thread", id:"EP tid 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", lockname:"(null)" Jason From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 06:43:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C539C874; Sat, 18 Oct 2014 06:43:27 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88558981; Sat, 18 Oct 2014 06:43:27 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tp5so2071182ieb.0 for ; Fri, 17 Oct 2014 23:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=D1+5Zm0l+3whQY2VK7Ij+U8F3twJQkh7Kf1xS3c/3Ts=; b=hFkP/RHQ201YFyFnXEjrUwpnwmszBetKTDJpWYYzPin4QFwEWKl0cgwot3vneuC08o LaAaHnRi2k/557lmzGVv3QkB+5mrv8xYxqD8uzg7tkjeyF54cWQM9eBzNYIUAGedVAvC 4pHPBpoPxy+wyw93GrOZsX3nRGe5S/T2NVt6Y/rEcsd0EUBM3K5V1RVIZGg9mY6djIek MPlhuVeDcGETMxlO4gYgPTLftp98bMyAbJUotJrf7EDBV80qAhMP5/UneZAMPLjlEW5W eu8Z0ojWkb8H4RTmQiVuJ7iYpkQ79MlKUhcSy+cu3nz7HzjKxHZwnI8dEIZy8+/3IkVI Qdlw== MIME-Version: 1.0 X-Received: by 10.43.140.132 with SMTP id ja4mr14619618icc.40.1413614606670; Fri, 17 Oct 2014 23:43:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.50.83.66 with HTTP; Fri, 17 Oct 2014 23:43:26 -0700 (PDT) In-Reply-To: References: <1410203348.1343.1.camel@bruno> <3567780.Mf6fMnzmYG@ralph.baldwin.cx> <201410161523.32415.jhb@freebsd.org> Date: Fri, 17 Oct 2014 23:43:26 -0700 X-Google-Sender-Auth: a4lYjbz50VAqAvycD0ttDi6r0cg Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Adrian Chadd To: Jason Wolfe Content-Type: text/plain; charset=UTF-8 Cc: Sean Bruno , FreeBSD Net , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 06:43:27 -0000 Hm, is this the bug that was just fixed in -HEAD? I saw this similar bug on -HEAD with lots of quick connections and reused ports. It ended up deferencing a NULL tcp timer pointer from the inpcb. Is that what the code in your tree is doing? -a On 17 October 2014 23:32, Jason Wolfe wrote: > On Thu, Oct 16, 2014 at 12:23 PM, John Baldwin wrote: >> >> >> I looked at the other trace and I don't think it disagrees with my previous >> theory. I do have more KTR patches to log when we spin on locks which would >> really confirm this, but I haven't tested those fully on HEAD yet. >> >> However, I'd rather spend time debugging this panic. I think I added that >> assertion myself. >> >> The root problem is that the persist and retransmit timers share state, >> so only one should ever be active at a time. In this case, the persist >> timer has fired and is rescheduling itself, but some other thread has >> scheduled the retransmit timer to fire. The bug is probably in that other >> thread. It should either not scheduled the retransmit timer, or it should >> first cancel the persist timer. >> >> A new assertion should be able to find this. Note, this is definitely going >> to panic, but one panic is probably enough to find this. >> >> Index: tcp_timer.c >> =================================================================== >> --- tcp_timer.c (revision 272718) >> +++ tcp_timer.c (working copy) >> @@ -713,10 +713,14 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ >> case TT_REXMT: >> t_callout = &tp->t_timers->tt_rexmt; >> f_callout = tcp_timer_rexmt; >> + if (callout_active(&tp->t_timers->tt_persist)) >> + panic("scheduling retransmit with persist active"); >> break; >> case TT_PERSIST: >> t_callout = &tp->t_timers->tt_persist; >> f_callout = tcp_timer_persist; >> + if (callout_active(&tp->t_timers->tt_rexmt)) >> + panic("scheduling persist with retransmit active"); >> break; >> case TT_KEEP: >> t_callout = &tp->t_timers->tt_keep; >> >> -- >> John Baldwin > > > Producing 10G of random traffic against a server with this assertion > added took about 2 hours to panic, so if it turns out we need anything > further it should be pretty quick. > > #1 0xffffffff806facb1 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:452 > #2 0xffffffff806fb014 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:759 > #3 0xffffffff8084edba in tcp_timer_activate (tp=0x0, > timer_type=, delta=0) > at /usr/src/sys/netinet/tcp_timer.c:695 > #4 0xffffffff80841bad in tcp_do_segment (m=0xfffff80019898d00, > th=0xfffff80019898d82, so=0xfffff8026cafaae0, > tp=, drop_hdrlen=, > tlen=0, iptos=, ti_locked=-2047) > at /usr/src/sys/netinet/tcp_input.c:2821 > #5 0xffffffff8083f748 in tcp_input (m=, > off0=) at /usr/src/sys/netinet/tcp_input.c:1388 > #6 0xffffffff807dc707 in ip_input (m=0xfffff80019898d00) at > /usr/src/sys/netinet/ip_input.c:734 > #7 0xffffffff807b8a61 in netisr_dispatch_src (proto= out>, source=, m=0x0) > at /usr/src/sys/net/netisr.c:972 > #8 0xffffffff807b1f06 in ether_demux (ifp=, > m=0xfffff80019898d00) at /usr/src/sys/net/if_ethersubr.c:851 > #9 0xffffffff807b2b99 in ether_nh_input (m=) at > /usr/src/sys/net/if_ethersubr.c:646 > #10 0xffffffff807b8a61 in netisr_dispatch_src (proto= out>, source=, m=0x0) > at /usr/src/sys/net/netisr.c:972 > #11 0xffffffff80843f68 in tcp_lro_flush (lc=0xfffff8000e6f7188, > le=0xfffff80019335380) at /usr/src/sys/netinet/tcp_lro.c:301 > #12 0xffffffff80844563 in tcp_lro_rx (lc=0x0, m=, > csum=) > at /usr/src/sys/netinet/tcp_lro.c:515 > #13 0xffffffff804a6622 in ixgbe_rxeof (que=0xfffff8000e702068) at > /usr/src/sys/dev/ixgbe/ixgbe.c:4356 > #14 0xffffffff804a6cd9 in ixgbe_msix_que (arg=0xfffff8000e702068) at > /usr/src/sys/dev/ixgbe/ixgbe.c:1523 > #15 0xffffffff806d16f3 in intr_event_execute_handlers (p= optimized out>, ie=0xfffff8000e6fcb00) > at /usr/src/sys/kern/kern_intr.c:1263 > ---Type to continue, or q to quit--- > #16 0xffffffff806d2056 in ithread_loop (arg=0xfffff8000e719ac0) at > /usr/src/sys/kern/kern_intr.c:1276 > #17 0xffffffff806cf481 in fork_exit (callout=0xffffffff806d1fc0 > , arg=0xfffff8000e719ac0, frame=0xfffffe0f9558cac0) > at /usr/src/sys/kern/kern_fork.c:996 > > #4 list > 2816 * timer and remember to restart (more output > or persist). > 2817 * If there is more data to be acked, restart retransmit > 2818 * timer, using current (possibly backed-off) value. > 2819 */ > 2820 if (th->th_ack == tp->snd_max) { > 2821 tcp_timer_activate(tp, TT_REXMT, 0); > 2822 needoutput = 1; > 2823 } else if (!tcp_timer_active(tp, TT_PERSIST)) > 2824 tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur); > > #5 list > 1383 /* > 1384 * Segment belongs to a connection in SYN_SENT, > ESTABLISHED or later > 1385 * state. tcp_do_segment() always consumes the mbuf > chain, unlocks > 1386 * the inpcb, and unlocks pcbinfo. > 1387 */ > 1388 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, > iptos, ti_locked); > 1389 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > 1390 return; > 1391 > 1392 dropwithreset: > > I believe you just wanted to spot the tcp_do_segment culprit here, but > just in case the KTR traces provide any insight.. > > index cpu timestamp trace > ------ --- ---------------- ----- > 262 1 5346219888944675 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"running", attributes: prio:8 > 261 1 5346219888944167 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", state:"idle", attributes: prio:255 > 260 1 5346219888942623 KTRGRAPH group:"load", id:"CPU 1 load", > counter:1, attributes: none > 259 1 5346219888942223 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 > tid 100061" > 258 1 5346219888941935 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, > linkedto:"idle: cpu1 tid 100004" > 257 4 5346219888867655 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"running", attributes: prio:255 > 256 4 5346219888866671 KTRGRAPH group:"load", id:"CPU 4 load", > counter:0, attributes: none > 255 4 5346219888866427 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", > lockname:"(null)" > 254 4 5346219888866075 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"prio", attributes: prio:201, new prio:152, > linkedto:"EP tid 100276" > 253 3 5346219888839020 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 252 4 5346219888838543 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"running", attributes: prio:152 > 251 3 5346219888837884 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 250 3 5346219888837504 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 249 4 5346219888836847 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"idle", attributes: prio:255 > 248 3 5346219888834744 KTRGRAPH group:"load", id:"CPU 4 load", > counter:1, attributes: none > 247 3 5346219888833740 KTRGRAPH group:"thread", id:"dfetch tid > 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" > 246 3 5346219888833532 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid > 100281" > 245 4 5346219888833383 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"running", attributes: prio:255 > 244 4 5346219888831951 KTRGRAPH group:"load", id:"CPU 4 load", > counter:0, attributes: none > 243 4 5346219888831427 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", > lockname:"(null)" > 242 4 5346219888830775 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"prio", attributes: prio:201, new prio:152, > linkedto:"EP tid 100276" > 241 3 5346219888805468 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 240 3 5346219888804072 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 239 4 5346219888802939 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 238 4 5346219888802067 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 237 4 5346219888801835 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 236 2 5346219888779438 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"running", attributes: prio:255 > 235 2 5346219888778694 KTRGRAPH group:"load", id:"CPU 2 load", > counter:0, attributes: none > 234 2 5346219888778466 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", > lockname:"(null)" > 233 2 5346219888750994 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"running", attributes: prio:123 > 232 2 5346219888749690 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"idle", attributes: prio:255 > 231 4 5346219888747775 KTRGRAPH group:"load", id:"CPU 2 load", > counter:1, attributes: none > 230 4 5346219888746907 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" > 229 4 5346219888746683 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid > 100276" > 228 3 5346219888722124 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 227 3 5346219888721356 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 226 3 5346219888721132 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 225 3 5346219888693496 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 224 3 5346219888692108 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 223 4 5346219888690959 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 222 4 5346219888690151 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 221 4 5346219888689835 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 220 3 5346219888664956 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 219 3 5346219888664188 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 218 3 5346219888663956 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 217 3 5346219888636448 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 216 3 5346219888635052 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 215 4 5346219888634055 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 214 4 5346219888633175 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 213 4 5346219888632887 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 212 2 5346219888605666 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"running", attributes: prio:255 > 211 2 5346219888604894 KTRGRAPH group:"load", id:"CPU 2 load", > counter:0, attributes: none > 210 2 5346219888604670 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", > lockname:"(null)" > 209 2 5346219888579382 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"running", attributes: prio:123 > 208 2 5346219888578102 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"idle", attributes: prio:255 > 207 4 5346219888576151 KTRGRAPH group:"load", id:"CPU 2 load", > counter:1, attributes: none > 206 4 5346219888575307 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" > 205 4 5346219888575075 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid > 100276" > 204 3 5346219888547276 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 203 3 5346219888546492 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 202 3 5346219888546256 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 201 3 5346219888518516 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 200 3 5346219888517144 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 199 4 5346219888515955 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 198 4 5346219888515051 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 197 4 5346219888514763 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 196 3 5346219888471648 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 195 3 5346219888470864 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 194 3 5346219888470608 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 193 3 5346219888444416 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 192 3 5346219888443180 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 191 4 5346219888442191 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 190 4 5346219888441299 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 189 4 5346219888441051 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 188 2 5346219888412126 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"running", attributes: prio:255 > 187 2 5346219888411186 KTRGRAPH group:"load", id:"CPU 2 load", > counter:0, attributes: none > 186 2 5346219888410734 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", > lockname:"(null)" > 185 3 5346219888406268 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 184 3 5346219888405416 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 183 3 5346219888405132 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 182 2 5346219888383370 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"running", attributes: prio:123 > 181 2 5346219888382134 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"idle", attributes: prio:255 > 180 4 5346219888380347 KTRGRAPH group:"load", id:"CPU 2 load", > counter:1, attributes: none > 179 4 5346219888379675 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" > 178 4 5346219888379363 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid > 100276" > 177 3 5346219888377836 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 176 3 5346219888376464 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 175 4 5346219888375403 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 174 4 5346219888374439 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 173 4 5346219888374215 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 172 3 5346219888322428 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 171 3 5346219888321656 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 170 3 5346219888321352 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 169 3 5346219888293052 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 168 3 5346219888291828 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 167 4 5346219888290659 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 166 4 5346219888289723 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 165 4 5346219888289491 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 164 3 5346219888238840 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 163 3 5346219888237796 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 162 3 5346219888237356 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 161 2 5346219888224558 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"running", attributes: prio:255 > 160 2 5346219888223782 KTRGRAPH group:"load", id:"CPU 2 load", > counter:0, attributes: none > 159 2 5346219888223538 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", > lockname:"(null)" > 158 2 5346219888197174 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"running", attributes: prio:123 > 157 2 5346219888195814 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"idle", attributes: prio:255 > 156 4 5346219888193983 KTRGRAPH group:"load", id:"CPU 2 load", > counter:1, attributes: none > 155 4 5346219888193331 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" > 154 4 5346219888193051 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid > 100276" > 153 3 5346219888191528 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 152 3 5346219888190324 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 151 4 5346219888189243 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 150 4 5346219888188227 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 149 4 5346219888187943 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 148 3 5346219888117040 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 147 3 5346219888116276 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 146 3 5346219888115840 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 145 1 5346219888098159 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", state:"running", attributes: prio:255 > 144 1 5346219888097579 KTRGRAPH group:"load", id:"CPU 1 load", > counter:0, attributes: none > 143 1 5346219888097171 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"iwait", attributes: prio:8, > wmesg:"(null)", lockname:"(null)" > 142 3 5346219888088152 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 141 3 5346219888086860 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 140 4 5346219888084999 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 139 4 5346219888084087 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 138 4 5346219888083843 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 137 5 5346219888072781 KTRGRAPH group:"thread", id:"idle: cpu5 > tid 100008", state:"running", attributes: prio:255 > 136 5 5346219888072481 KTRGRAPH group:"load", id:"CPU 5 load", > counter:0, attributes: none > 135 5 5346219888072285 KTRGRAPH group:"thread", id:"ix0 que tid > 100062", state:"sleep", attributes: prio:8, wmesg:"-", > lockname:"(null)" > 134 5 5346219888069689 KTRGRAPH group:"thread", id:"ix0 que tid > 100062", state:"running", attributes: prio:8 > 133 5 5346219888068753 KTRGRAPH group:"thread", id:"idle: cpu5 > tid 100008", state:"idle", attributes: prio:255 > 132 5 5346219888067957 KTRGRAPH group:"thread", id:"idle: cpu5 > tid 100008", point:"statclock", attributes: prio:255, stathz:127 > 131 1 5346219888062719 KTRGRAPH group:"load", id:"CPU 5 load", > counter:1, attributes: none > 130 1 5346219888061083 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"ix0 que > tid 100062" > 129 1 5346219888060811 KTRGRAPH group:"thread", id:"ix0 que tid > 100062", state:"runq add", attributes: prio:8, linkedto:"irq279: > ix0:que 1 tid 100061" > 128 4 5346219888029723 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"running", attributes: prio:152 > 127 4 5346219888028295 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"idle", attributes: prio:255 > 126 1 5346219888026515 KTRGRAPH group:"load", id:"CPU 4 load", > counter:1, attributes: none > 125 1 5346219888025739 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"EP tid > 100276" > 124 1 5346219888025603 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"runq add", attributes: prio:152, linkedto:"irq279: > ix0:que 1 tid 100061" > 123 1 5346219887987103 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"running", attributes: prio:8 > 122 1 5346219887986611 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", state:"idle", attributes: prio:255 > 121 1 5346219887984967 KTRGRAPH group:"load", id:"CPU 1 load", > counter:1, attributes: none > 120 1 5346219887984507 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 > tid 100061" > 119 1 5346219887984307 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, > linkedto:"idle: cpu1 tid 100004" > 118 4 5346219887875887 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"running", attributes: prio:255 > 117 4 5346219887874835 KTRGRAPH group:"load", id:"CPU 4 load", > counter:0, attributes: none > 116 4 5346219887874551 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", > lockname:"(null)" > 115 4 5346219887874139 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"prio", attributes: prio:201, new prio:152, > linkedto:"EP tid 100276" > 114 3 5346219887848752 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 113 4 5346219887847859 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"running", attributes: prio:152 > 112 3 5346219887847580 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 111 3 5346219887847228 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 110 4 5346219887846167 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"idle", attributes: prio:255 > 109 3 5346219887844428 KTRGRAPH group:"load", id:"CPU 4 load", > counter:1, attributes: none > 108 3 5346219887843660 KTRGRAPH group:"thread", id:"dfetch tid > 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" > 107 3 5346219887843448 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid > 100281" > 106 4 5346219887823135 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"running", attributes: prio:255 > 105 4 5346219887821983 KTRGRAPH group:"load", id:"CPU 4 load", > counter:0, attributes: none > 104 4 5346219887821675 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", > lockname:"(null)" > 103 4 5346219887821231 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"prio", attributes: prio:201, new prio:152, > linkedto:"EP tid 100276" > 102 3 5346219887817840 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 101 3 5346219887816548 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 100 4 5346219887815395 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 99 4 5346219887814459 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 98 4 5346219887814199 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 97 3 5346219887757636 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 96 4 5346219887757263 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"running", attributes: prio:152 > 95 3 5346219887756492 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 94 3 5346219887756104 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 93 4 5346219887755543 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"idle", attributes: prio:255 > 92 3 5346219887753420 KTRGRAPH group:"load", id:"CPU 4 load", > counter:1, attributes: none > 91 3 5346219887752476 KTRGRAPH group:"thread", id:"dfetch tid > 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" > 90 3 5346219887752252 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid > 100281" > 89 4 5346219887752095 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"running", attributes: prio:255 > 88 4 5346219887750663 KTRGRAPH group:"load", id:"CPU 4 load", > counter:0, attributes: none > 87 4 5346219887750331 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", > lockname:"(null)" > 86 4 5346219887749791 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"prio", attributes: prio:201, new prio:152, > linkedto:"EP tid 100276" > 85 3 5346219887728324 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 84 3 5346219887727048 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 83 4 5346219887726095 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 82 4 5346219887725167 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 81 4 5346219887724943 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 80 3 5346219887706048 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 79 3 5346219887705260 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 78 3 5346219887705012 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 77 3 5346219887677908 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 76 3 5346219887676408 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 75 4 5346219887675275 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 74 4 5346219887674339 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 73 4 5346219887674067 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 72 3 5346219887643688 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 71 3 5346219887642916 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 70 3 5346219887642648 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 69 3 5346219887615124 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 68 3 5346219887613600 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 67 4 5346219887612439 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 66 4 5346219887611651 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 65 4 5346219887611375 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 64 3 5346219887606948 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 63 3 5346219887606148 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 62 3 5346219887605876 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 61 3 5346219887578020 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 60 3 5346219887576736 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 59 4 5346219887575719 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 58 4 5346219887574663 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 57 4 5346219887574391 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 56 3 5346219887514636 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 55 3 5346219887513536 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 54 3 5346219887513152 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 53 4 5346219887493515 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"running", attributes: prio:152 > 52 4 5346219887491871 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"idle", attributes: prio:255 > 51 3 5346219887489976 KTRGRAPH group:"load", id:"CPU 4 load", > counter:1, attributes: none > 50 3 5346219887488968 KTRGRAPH group:"thread", id:"dfetch tid > 100281", point:"wokeup", attributes: linkedto:"EP tid 100276" > 49 3 5346219887488688 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"runq add", attributes: prio:152, linkedto:"dfetch tid > 100281" > 48 4 5346219887488403 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"running", attributes: prio:255 > 47 4 5346219887486827 KTRGRAPH group:"load", id:"CPU 4 load", > counter:0, attributes: none > 46 4 5346219887486411 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", > lockname:"(null)" > 45 4 5346219887485835 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"prio", attributes: prio:201, new prio:152, > linkedto:"EP tid 100276" > 44 3 5346219887440704 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 43 3 5346219887439212 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 42 4 5346219887438063 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 41 4 5346219887437079 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 40 4 5346219887436799 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 39 2 5346219887370146 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"running", attributes: prio:255 > 38 2 5346219887369366 KTRGRAPH group:"load", id:"CPU 2 load", > counter:0, attributes: none > 37 2 5346219887369102 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", > lockname:"(null)" > 36 2 5346219887340378 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"running", attributes: prio:123 > 35 2 5346219887338874 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"idle", attributes: prio:255 > 34 4 5346219887336903 KTRGRAPH group:"load", id:"CPU 2 load", > counter:1, attributes: none > 33 4 5346219887335995 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" > 32 4 5346219887335727 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid > 100276" > 31 3 5346219887298672 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"running", attributes: prio:255 > 30 3 5346219887297652 KTRGRAPH group:"load", id:"CPU 3 load", > counter:0, attributes: none > 29 3 5346219887297304 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"sleep", attributes: prio:139, wmesg:"sbwait", > lockname:"(null)" > 28 3 5346219887229996 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"running", attributes: prio:139 > 27 3 5346219887228528 KTRGRAPH group:"thread", id:"idle: cpu3 > tid 100006", state:"idle", attributes: prio:255 > 26 4 5346219887227515 KTRGRAPH group:"load", id:"CPU 3 load", > counter:1, attributes: none > 25 4 5346219887226503 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100281" > 24 4 5346219887226247 KTRGRAPH group:"thread", id:"dfetch tid > 100281", state:"runq add", attributes: prio:139, linkedto:"EP tid > 100276" > 23 2 5346219887153494 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"running", attributes: prio:255 > 22 2 5346219887152702 KTRGRAPH group:"load", id:"CPU 2 load", > counter:0, attributes: none > 21 2 5346219887152226 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"sleep", attributes: prio:123, wmesg:"sbwait", > lockname:"(null)" > 20 1 5346219887147171 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", state:"running", attributes: prio:255 > 19 1 5346219887146583 KTRGRAPH group:"load", id:"CPU 1 load", > counter:0, attributes: none > 18 1 5346219887146179 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"iwait", attributes: prio:8, > wmesg:"(null)", lockname:"(null)" > 17 2 5346219887125262 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"running", attributes: prio:123 > 16 2 5346219887124054 KTRGRAPH group:"thread", id:"idle: cpu2 > tid 100005", state:"idle", attributes: prio:255 > 15 4 5346219887122139 KTRGRAPH group:"load", id:"CPU 2 load", > counter:1, attributes: none > 14 4 5346219887121247 KTRGRAPH group:"thread", id:"EP tid > 100276", point:"wokeup", attributes: linkedto:"dfetch tid 100283" > 13 4 5346219887121067 KTRGRAPH group:"thread", id:"dfetch tid > 100283", state:"runq add", attributes: prio:123, linkedto:"EP tid > 100276" > 12 4 5346219887070771 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"running", attributes: prio:152 > 11 4 5346219887069227 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"idle", attributes: prio:255 > 10 1 5346219887067479 KTRGRAPH group:"load", id:"CPU 4 load", > counter:1, attributes: none > 9 1 5346219887066659 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", point:"wokeup", attributes: linkedto:"EP tid > 100276" > 8 1 5346219887066495 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"runq add", attributes: prio:152, linkedto:"irq279: > ix0:que 1 tid 100061" > 7 1 5346219887029563 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"running", attributes: prio:8 > 6 1 5346219887029143 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", state:"idle", attributes: prio:255 > 5 1 5346219887027871 KTRGRAPH group:"load", id:"CPU 1 load", > counter:1, attributes: none > 4 1 5346219887027399 KTRGRAPH group:"thread", id:"idle: cpu1 > tid 100004", point:"wokeup", attributes: linkedto:"irq279: ix0:que 1 > tid 100061" > 3 1 5346219887027163 KTRGRAPH group:"thread", id:"irq279: > ix0:que 1 tid 100061", state:"runq add", attributes: prio:8, > linkedto:"idle: cpu1 tid 100004" > 2 4 5346219886977607 KTRGRAPH group:"thread", id:"idle: cpu4 > tid 100007", state:"running", attributes: prio:255 > 1 4 5346219886976619 KTRGRAPH group:"load", id:"CPU 4 load", > counter:0, attributes: none > 0 4 5346219886976335 KTRGRAPH group:"thread", id:"EP tid > 100276", state:"sleep", attributes: prio:152, wmesg:"kqread", > lockname:"(null)" > > Jason > _______________________________________________ > 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 Sat Oct 18 06:59:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09BC8BE2 for ; Sat, 18 Oct 2014 06:59:03 +0000 (UTC) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC970A7F for ; Sat, 18 Oct 2014 06:59:02 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from bpb8.clarehall.cam.ac.uk ([131.111.224.154]:56088 helo=[192.168.0.5]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:mpg39) (TLSv1:DHE-RSA-AES256-SHA:256) id 1XfNye-0006CJ-Ee (Exim 4.82_3-c0e5623) (return-path ); Sat, 18 Oct 2014 07:59:00 +0100 Mime-Version: 1.0 (1.0) Subject: Re: Netmap: head vs cur vs tail? From: "Matthew P. Grosvenor" X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Sat, 18 Oct 2014 07:58:57 +0100 Message-Id: <986ECDB1-3D76-4930-9C08-A2661F573431@cl.cam.ac.uk> References: <9C6995C3-2B7A-4769-A658-DCF1C1B23B60@cl.cam.ac.uk> To: Luigi Rizzo Sender: "M.P. Grosvenor" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 06:59:03 -0000 Thanks! This has tons more info. I'll have a read.=20 ----------- Sent from my phone, sorry about the typos.=20 > On 17 Oct 2014, at 18:27, Luigi Rizzo wrote: >=20 >=20 >=20 >> On Fri, Oct 17, 2014 at 9:55 AM, Matthew P. Grosvenor wrote: >> Hi all, >> I=E2=80=99m trying to understand how to use the netmap framework, specifi= cally how the head, tail and current =E2=80=9Cpointers=E2=80=9D interact wit= h each other. >>=20 >> Looking in man NETMAP(4) (http://www.freebsd.org/cgi/man.cgi?query=3Dnetm= ap&sektion=3D4) under data structures, struct netmap_ring it says: " cont= ains the index of he current read or write slot (cur), =E2=80=9C. In the exa= mple code, the following pattern is used: >=20 > =E2=80=8Bthe default netmap manpage at the above URL is the old one, > please use the one for 10-stable or 11-current=20 >=20 > http://www.freebsd.org/cgi/man.cgi=E2=80=8B?=E2=80=8Bquery=3Dnetmap&manpat= h=3DFreeBSD+10.0-stable >=20 > =E2=80=8Bwhich=E2=80=8B explains in more detail the role > of the three pointers (with some ascii graphics too). >=20 > Feel free to ask for more details if the page is not clear >=20 > cheers > luigi >=20 >>=20 >> i =3D ring->cur; >> ... >> ring->cur =3D NETMAP_RING_NEXT(ring, i); >>=20 >> However, in the example that ships with the netmap source (https://code.g= oogle.com/p/netmap/source/browse/examples/bridge.c#72 & https://code.google.= com/p/netmap/source/browse/examples/pkt-gen.c#660) the following pattern is u= sed: >>=20 >> j =3D rxring->cur; >> while(=E2=80=A6){ >> j =3D nm_ring_next(rxring, j); >> =E2=80=A6 >> } >> rxring->head =3D rxring->cur =3D j; >>=20 >> So the obvious question is, what is the relationship between head and cur= rent? Do I believe the man page (and man page example) that head is not nece= ssary, or do I believe the example code that head is necessary and should be= set to the same value as current? And if so, what is the point of head? And= why is it updated outside of the loop in both of the examples? >>=20 >> At a high level, I=E2=80=99m looking for a better understanding of what h= ead, tail and current mean and how they affect the processing of rings. >=20 > =20 >> Cheers, >> Matt >>=20 >> _______________________________________________ >> 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 >=20 >=20 > --=20 > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 11:56:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8F44AE2 for ; Sat, 18 Oct 2014 11:56:49 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90DB96C4 for ; Sat, 18 Oct 2014 11:56:49 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F1603B93C; Sat, 18 Oct 2014 07:56:47 -0400 (EDT) From: John Baldwin To: Jason Wolfe Subject: Re: ixgbe(4) spin lock held too long Date: Sat, 18 Oct 2014 07:42:58 -0400 Message-ID: <1569387.ZCJSvuukWl@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <1410203348.1343.1.camel@bruno> <201410161523.32415.jhb@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 18 Oct 2014 07:56:48 -0400 (EDT) Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 11:56:49 -0000 On Friday, October 17, 2014 11:32:13 PM Jason Wolfe wrote: > Producing 10G of random traffic against a server with this assertion > added took about 2 hours to panic, so if it turns out we need anything > further it should be pretty quick. > > #4 list > 2816 * timer and remember to restart (more output or persist). > 2817 * If there is more data to be acked, restart retransmit > 2818 * timer, using current (possibly backed-off) value. > 2819 */ > 2820 if (th->th_ack == tp->snd_max) { > 2821 tcp_timer_activate(tp, TT_REXMT, 0); > 2822 needoutput = 1; > 2823 } else if (!tcp_timer_active(tp, TT_PERSIST)) > 2824 tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur); Bah, this is just a bug in my assertion. Rather than having a separate tcp_timer_deactivate() routine, a delta of 0 passed to tcp_timer_activate() means "stop the timer". My assertions were incorrect and need to exclude the stop case. Here is an updated patch (or you can just fix yours locally): Index: tcp_timer.c =================================================================== --- tcp_timer.c (revision 273219) +++ tcp_timer.c (working copy) @@ -869,10 +869,16 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ case TT_REXMT: t_callout = &tp->t_timers->tt_rexmt; f_callout = tcp_timer_rexmt; + if (callout_active(&tp->t_timers->tt_persist) && + delta != 0) + panic("scheduling retransmit with persist active"); break; case TT_PERSIST: t_callout = &tp->t_timers->tt_persist; f_callout = tcp_timer_persist; + if (callout_active(&tp->t_timers->tt_rexmt) && + delta != 0) + panic("scheduling persist with retransmit active"); break; case TT_KEEP: t_callout = &tp->t_timers->tt_keep; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 11:56:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3EB2AE4; Sat, 18 Oct 2014 11:56:49 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC84E6C5; Sat, 18 Oct 2014 11:56:49 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF1C7B941; Sat, 18 Oct 2014 07:56:48 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: ixgbe(4) spin lock held too long Date: Sat, 18 Oct 2014 07:35:44 -0400 Message-ID: <4003470.qylyPxsqMt@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <1410203348.1343.1.camel@bruno> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 18 Oct 2014 07:56:48 -0400 (EDT) Cc: Sean Bruno , FreeBSD Net , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 11:56:50 -0000 On Friday, October 17, 2014 11:43:26 PM Adrian Chadd wrote: > Hm, is this the bug that was just fixed in -HEAD? > > I saw this similar bug on -HEAD with lots of quick connections and > reused ports. It ended up deferencing a NULL tcp timer pointer from > the inpcb. Is that what the code in your tree is doing? This is not a NULL tcp timer pointer. Instead, the retransmit timer is being armed while the persist timer is still armed. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 16:30:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BE0DF19; Sat, 18 Oct 2014 16:30:33 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BBE3F61; Sat, 18 Oct 2014 16:30:33 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so1826330qgf.21 for ; Sat, 18 Oct 2014 09:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZsSaUqgtCKJOwzAEu4ZBnzoUQAegJqCXyj2HjPbl5jQ=; b=c2d+RIozjugD6eoKNcOx0pBjRRlrkpAYgAcclqliRC86fgKaY5UqHeSbnTpASk4edE qQ0uSAgylr775b2mOrYMJESO6wPOyFhq99OwMcHJtODC/IdquiaAxeP7aboT4Z401RpV /W+B5Gle8OHZ6v02kzNSx928JPqDJxx4tIJkz22+cQQ2lzBIfcX2wm5k/rmUJHrgQP7w uea29QF0Ib7QRzimVbQZsDuoDcnDqvZ1zwX/tCs1gQzgbzFZXRoy88naLRC0peZA11wJ fdd3aDaCKztMK3upOwrS5XfXe76WdUizNuZG1IBNsQf+NvIeH0ruhFrhdUoULPEtuCQe C3UA== MIME-Version: 1.0 X-Received: by 10.140.23.116 with SMTP id 107mr20236707qgo.73.1413649832215; Sat, 18 Oct 2014 09:30:32 -0700 (PDT) Received: by 10.140.37.6 with HTTP; Sat, 18 Oct 2014 09:30:32 -0700 (PDT) In-Reply-To: <20141018.143919.1930138986692891609.hrs@allbsd.org> References: <20141018.143919.1930138986692891609.hrs@allbsd.org> Date: Sat, 18 Oct 2014 09:30:32 -0700 Message-ID: Subject: Re: IPv6 stacks responds to all node link local multicast NS From: prabhakar lakhera To: Hiroki Sato Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 16:30:33 -0000 Like I said before, it is not per RFC. It is trivial to derive solicited node multicast address from the target IP, so If someone were to launch a flood attack to poison cache entry for X host by sending Address resolution request for all other local hosts in the network, with NS's source IP=X's IP and with source link layer info=attacker's MAC, computing sol node multicast for each target will make it only slightly costly, so I am not sure if security could be of concern here. The other concern is if it can be a compliance issue given the NS packet format described by the RFC. Also the comment in the code suggests what RFC says but the check is more liberal. Also why it is different for DAD NS vs Neighbor resolution NS. On Friday, October 17, 2014, Hiroki Sato wrote: > prabhakar lakhera > wrote > in >: > > pr> This probably is more of a compliance issue (or may be not as the NS > pr> receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 > does > pr> not talk about it). > pr> > pr> The neighbor solicitation message format says this: > pr> > pr> http://tools.ietf.org/html/rfc4861#page-22 > pr> > pr> > pr> Destination Address > pr> Either the solicited-node multicast address > pr> corresponding to the target address, or the target > pr> address. > pr> > pr> > pr> Is it safe to assume that this is a MUST? > pr> If yes, nd6_ns_input right now only checks if the destination is a > pr> multicast or not (the check is more strict for DAD NS packets) and > pr> therefore allows all node link local multicast address resolution NS > pr> packets and process them completely (creates neighbor cache, responds > pr> with NA etc). > > What is the problem when accepting NS messages to ff02::1? > > -- Hiroki >