From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 02:59:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 898BE4DD; Sun, 20 Jul 2014 02:59:28 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 677AB2732; Sun, 20 Jul 2014 02:59:28 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 27CD47D7; Sat, 19 Jul 2014 19:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1405825168; bh=nEIsIQsAn1lOyw4ybKvCXWe8KZEIosWxU4J4D3YJrs4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=d5kpHrXylY2FQwhkSp22As0ITTkEXt4akvxR/EH0IJyZ+IwxTC35eU2VOMCrvkEe9 I7RckblGSVseyI2aucl3cMA1+5ewj0zPhiZQln6mY2ZNmm2Oqgo1g2xWt8vBPcVYE3 3LEGwMUGnM7E/2/Fnvd3O+GaO011172EocRvOQ68= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Date: Sat, 19 Jul 2014 19:59:23 -0700 Message-ID: <20381608.Hhy3QfhrOP@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140719110652.GR28314@ivaldir.etoilebsd.net> References: <53C706C9.6090506@com.jkkn.dk> <53C973EA.5090104@freebsd.org> <20140719110652.GR28314@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3427830.U7ikdp9xGS"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Baptiste Daroussin , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 02:59:28 -0000 --nextPart3427830.U7ikdp9xGS Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote: > On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote: > > On 2014-07-18 15:07, Adrian Chadd wrote: > > > On 18 July 2014 07:34, krad wrote: > > >> that is true and I have not problem using man pages, however tha= ts not > > >> the > > >> way most of the world work and search engines arent exactly new = either. > > >> We > > >> should be trying to engage more people not less, and part of tha= t is > > >> reaching out. > > >=20 > > > Then do the port and maintain it. > > >=20 > > > The problem isn't the desire to keep things up to date, it's a la= ck of > > > people who want that _and_ are willing/able to do it _and_ are fu= nded > > > somehow. > > >=20 > > > So, please step up! We'll all love you for it. > > >=20 > > >=20 > > >=20 > > > -a > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to > > > "freebsd-current-unsubscribe@freebsd.org" > >=20 > > At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, = after > > spending some hours driving with Henning. >=20 > I tried and broke pf for month and my changes have been reverted, thi= s is > not as simple as it looks like, our code as diverge a lot in some par= t and > we do support things that openbsd does not (vimage). Sync features re= quires > us to be very careful, my priorities went elsewhere since that time, = so now > I will probably only focus on bringing features I care about, and not= the > entirely new pf. >=20 > So no do not count me as volunteer to maintain pf, I ll probably do s= ome > work but not a full sync. If anyone is looking for a really useful chunk to work on, please go ba= ck over=20 the pf history in openbsd and find where they added ipv6 fragment suppo= rt. It=20 was fairly well contained and didn't appear to be a big deal to port. = They=20 did do something with mbuf tags that I'm suspicious of though. IPv6 fragments are the biggest pain point we have on the freebsd.org cl= uster -=20 yes, we use pf and IPv6 extensively, but dns with ipv6 involved is real= ly=20 painful without fragment support. We sort-of work around it by using dedicated IPv6 address that has noth= ing but=20 the dns resolver clients and allow ipv6 fragments to it. Its not idea= l but=20 it gets over the worst problems. The other thing we had to do for usability is stop state tracking for u= dp dns=20 =2D the sheer update rate was causing collisions and state drops / resets= of=20 other connections to the point of being really hard to use. Those two tweaks - stopping heavy dns use from thrashing the state tabl= es, and=20 having a safe place to send fragments makes it quite usable for freebsd= .org. But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart3427830.U7ikdp9xGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJTyzCPAAoJEDXWlwnsgJ4ENfwIAM511S17Z8Opm8NMlbIr5kyP Iuc4Mm/BdCvCXjydSfdznyXDceWRWyJYTPByq2i+Au3PJ/m67x9gXf5pZkCbgNnn 0x5JjrLFoXorboL+F0Gp5m+bTAIu9Dkr/nRJ87+22OX/8noO3rGK4KnaNn0A69lu URRHNNwUQ5MS9f8L21pqJDICDqoNu1VvjnMNERygTKnG31who5t8id93GTqzpiZ1 c7pxCXnUPx/CZ0WiYeqY3YjOtA+KdzyJD/4QBIQcaTh3Eo3Ij1sEL6K8VOTi0k3t 6mSbZjn5VWZI08iRpKdpU0fWgUqSs3AQIzQNwxToD+5DMLp6BPKGQhk0zQKhz64= =F+xL -----END PGP SIGNATURE----- --nextPart3427830.U7ikdp9xGS-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 04:36:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 181A7174; Sun, 20 Jul 2014 04:36:26 +0000 (UTC) Received: from yoshi.brtsvcs.net (yoshi.brtsvcs.net [IPv6:2607:f2f8:a450::66]) (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 F2DF42EA7; Sun, 20 Jul 2014 04:36:25 +0000 (UTC) Received: from chombo.houseloki.net (c-73-37-112-64.hsd1.or.comcast.net [73.37.112.64]) by yoshi.brtsvcs.net (Postfix) with ESMTPSA id 997E0E603E; Sat, 19 Jul 2014 21:36:19 -0700 (PDT) Received: from [IPv6:2601:7:2280:38b:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2280:38b:baca:3aff:fe83:bd29]) by chombo.houseloki.net (Postfix) with ESMTPSA id 97842DA; Sat, 19 Jul 2014 21:36:17 -0700 (PDT) Message-ID: <53CB4736.90809@bluerosetech.com> Date: Sat, 19 Jul 2014 21:36:06 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Franco Fichtner , "Kristian K. Nielsen" Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> In-Reply-To: <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 04:36:26 -0000 On 7/18/2014 6:51 AM, Franco Fichtner wrote: >> c) We never got the new syntax from OpenBSD 4.7's pf - at the time a long discussion on the pf-mailing list flamed the new syntax saying it would cause FreeBSD administrators too much headache. Today on the list it seems everyone wants it - so would we rather stay on a dead branch than keep up with the main stream? > > I'd say many people are comfortable with an old state of pf (silent > majority), but that shouldn't keep us from catching up with newer > features (and of course bugfixes). Never mistake silence for consent. The vast majority of people don't know pf is outdated and broken on FreeBSD because they don't know what they're missing and likely aren't using IPv6 yet. The moment you turn on IPv6 and restart a validating unbound, you run full-speed into pf's broken behaviour. Make an EDNS0-enabled query for a signed zone and you'll get a fragmented UDP packet that will never make it through unless you tell pf to allow all fragments unconditionally. They'll simply think something is wrong with unbound, turn off EDNS0 and/or validation, hurt peformance and/or security in the process, and never realize their firewall is doing literally the worst possible thing it could do. All because over half a decade ago some folks got all butthurt over a config file format change. From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 04:38:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1527232A; Sun, 20 Jul 2014 04:38:52 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 B98A22ECA; Sun, 20 Jul 2014 04:38:51 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id q108so4398430qgd.37 for ; Sat, 19 Jul 2014 21:38: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=MmBoV/zQV53yYq8JccL/45Y65Nk5q9hE2N7cW9pS4/U=; b=eTNk4XPIYvPP9/hlA7+YEgqZb+6aoGlbszlRyIPySsElqB6qSj7Pe3BAiRbpUJQjuw gjQllHCOC+/mdTiQ9ynuRDjqDW7BgK5mG8OOs//ZDLTHgFoNUTj/9g/aDF2vv639x+OB Ockgi3OjbD8htGiuJxyQieOAyk2jS17F2q0qFCbZWu1gjFMAiBHviXfZ9HGt0U8fdf5W Iwlv83UO3d6R8/9RWAH0Phv24Ht0evKUyoYYB4hYiQgx8PtKDIv8RTxrhzJpMYyRRgbT Zc54anvUoUbM1BiPG6jrHz4cDlVBQBgpSxltEz4WDdmC7Fs13bS5Df1UeRoxIxD8uTSU UBxg== MIME-Version: 1.0 X-Received: by 10.224.223.135 with SMTP id ik7mr26732949qab.26.1405831130363; Sat, 19 Jul 2014 21:38:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sat, 19 Jul 2014 21:38:50 -0700 (PDT) In-Reply-To: <53CB4736.90809@bluerosetech.com> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> Date: Sat, 19 Jul 2014 21:38:50 -0700 X-Google-Sender-Auth: abMzYNWNs45dzFVFfgHUd50HS10 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Adrian Chadd To: Darren Pilgrim Content-Type: text/plain; charset=UTF-8 Cc: "Kristian K. Nielsen" , Franco Fichtner , freebsd-current , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 04:38:52 -0000 On 19 July 2014 21:36, Darren Pilgrim wrote: > On 7/18/2014 6:51 AM, Franco Fichtner wrote: >>> >>> c) We never got the new syntax from OpenBSD 4.7's pf - at the time a long >>> discussion on the pf-mailing list flamed the new syntax saying it would >>> cause FreeBSD administrators too much headache. Today on the list it seems >>> everyone wants it - so would we rather stay on a dead branch than keep up >>> with the main stream? >> >> >> I'd say many people are comfortable with an old state of pf (silent >> majority), but that shouldn't keep us from catching up with newer >> features (and of course bugfixes). > > > Never mistake silence for consent. > > The vast majority of people don't know pf is outdated and broken on FreeBSD > because they don't know what they're missing and likely aren't using IPv6 > yet. The moment you turn on IPv6 and restart a validating unbound, you run > full-speed into pf's broken behaviour. Make an EDNS0-enabled query for a > signed zone and you'll get a fragmented UDP packet that will never make it > through unless you tell pf to allow all fragments unconditionally. They'll > simply think something is wrong with unbound, turn off EDNS0 and/or > validation, hurt peformance and/or security in the process, and never > realize their firewall is doing literally the worst possible thing it could > do. > > All because over half a decade ago some folks got all butthurt over a config > file format change. if someone wants to port the up to date pf and can fix whatever performance / parallelism issues creep up, then go for it. -a From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 11:15:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F337EA60 for ; Sun, 20 Jul 2014 11:15:15 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EBB52A27 for ; Sun, 20 Jul 2014 11:15:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X8p54-0005wb-Pm for freebsd-current@freebsd.org; Sun, 20 Jul 2014 13:15:02 +0200 Received: from 92.54.176.20 ([92.54.176.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Jul 2014 13:15:02 +0200 Received: from kevin.bowling by 92.54.176.20 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Jul 2014 13:15:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Kevin Bowling Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? Date: Sun, 20 Jul 2014 04:08:13 -0700 Lines: 74 Message-ID: References: <53C920EA.7050604@freebsd.org> <53C9812D.90703@mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 92.54.176.20 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <53C9812D.90703@mu.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 11:15:16 -0000 On 7/18/2014 1:18 PM, Alfred Perlstein wrote: > > On 7/18/14, 6:28 AM, Allan Jude wrote: >> On 2014-07-17 16:12, Adrian Chadd wrote: >>> On 17 July 2014 13:03, Alberto Mijares wrote: >>>> On Thu, Jul 17, 2014 at 2:58 PM, Adrian Chadd >>>> wrote: >>>>> Hi! >>>>> >>>>> 3) The binary packages need to work out of the box >>>>> 4) .. which means, when you do things like pkg install apache, it >>>>> can't just be installed and not be enabled, because that's a bit of a >>>>> problem; >>>> >>>> No. Please NEVER do that! The user must be able to edit the files and >>>> start the service by himself. >>> Cool, so what's the single line command needed to type in to start a >>> given package service? >>> >>> >>> >>> -a >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >> We could make 'service apache22 enable' >> >> which can run: sysrc -f /etc/rc.conf apache22_enable="YES" >> >> and 'service apache22 disable' >> >> that can use sysrc -x >> >> And then ports can individually extend the functionality if they require. >> > I like this a lot. > > That said, if other distros are setting up apache in 2 steps and we > require 3 then we require 50% MORE STEPs! > > Or they require 33% LESS steps than us. > > Just to put it into perspective. Should FreeBSD be 50% more difficult > or time consuming to configure? > > -Alfred Yes. As someone who works on a large fleet of Ubuntu systems, the worst thing dpkg does is auto-start services and it even auto-restarts them on updates in some cases. * Starting a service is a security risk. Especially before it has been configured, either manually or with tools. This is potentially true even with "sane defaults" - for instance, the pkg may be installed from an image/media and need to be updated from an internet repo because the image has aged. * Mandatory (re)starting of a service may happen before all deps are upgraded/installed, requiring multiple pointless and time consuming restarts. * Likewise, starting a service before the manual or CM policy hits can cause all sorts of problems, difficulties, and again even security implications. The way of doing things for large infrastructure is using some type of config management or orchestration tool like Puppet, Chef, Salt, Ansible, cfengine. This is even the case for small deployments for the types of users Craig was talking about in the initial post. Regards, Kevin From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 11:18:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FEC1BA1; Sun, 20 Jul 2014 11:18:55 +0000 (UTC) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 0125D2A55; Sun, 20 Jul 2014 11:18:54 +0000 (UTC) Received: by mail-yk0-f170.google.com with SMTP id 9so2317764ykp.15 for ; Sun, 20 Jul 2014 04:18:54 -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=DGDxaH07iHwhjdykKVXkqGajWuvmtuma03S9Y9fm4bE=; b=Mba0ZZo3LhfcmNQULjf8CnY46pnQW+/83Ga2RqWP1MjVSycCwO1f8aJWtsXFZV7cF0 VlNGco4yG9cDbnrU1E+n4XhDH0eMbqHOljbrHURtH170BGAFGQ3HlSExEc2rDLMRucFm jvVxiem87EWMbjvVIB/FbPxvv8oJtdLPZV6B0uFQfHSONhKgPK5p+Dq2Gvprm6mMx3Va WrQeAMQm6CPrxcalg3dwC2VHx4YcLSnrwqprsnXWPo+6I+ykqR8IilDroyeMDysuxyUx M2h07fxVqbR0e2gny189R5ngef2r7Rn8Wr7Inu6+5LMIyS0d38UWRpidSkvqA6CwzYUN exzg== MIME-Version: 1.0 X-Received: by 10.236.108.147 with SMTP id q19mr28114649yhg.27.1405855134154; Sun, 20 Jul 2014 04:18:54 -0700 (PDT) Received: by 10.170.132.80 with HTTP; Sun, 20 Jul 2014 04:18:54 -0700 (PDT) In-Reply-To: <53CA2D39.6000204@sasktel.net> References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> Date: Sun, 20 Jul 2014 12:18:54 +0100 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: krad To: Stephen Hurd X-Mailman-Approved-At: Sun, 20 Jul 2014 12:00:40 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Mailing List , =?UTF-8?B?R2Vycml0IEvDvGhu?= , freebsd-current@freebsd.org, Gleb Smirnoff , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 11:18:55 -0000 all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream On 19 July 2014 09:32, Stephen Hurd wrote: > krad wrote: > > that is true and I have not problem using man pages, however thats not > the > > way most of the world work and search engines arent exactly new either. > We > > should be trying to engage more people not less, and part of that is > > reaching out. > > One of FreeBSD's historic strengths has been the handbook and generally > good quality documentation. There is no way that the FreeBSD project > can ensure that all Google results for everyone in the world are FreeBSD > related "good" documentation, but it can ensure that the documentation > included with FreeBSD is accurate and usable, and it can ensure that the > FreeBSD documentation is available via the internet. > > Aside from blindly following whatever generates the most Google results > (an obviously broken solution), what exactly can the FreeBSD project do > to ensure that when someone "Googles" a problem they will end up with a > correct FreeBSD solution? > From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 12:39:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 391CFA7; Sun, 20 Jul 2014 12:39:23 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (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 DCE1D205A; Sun, 20 Jul 2014 12:39:22 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 0B20A6A6004; Sun, 20 Jul 2014 14:39:19 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s6KCdIVR073823; Sun, 20 Jul 2014 14:39:18 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s6KCdGLL072493; Sun, 20 Jul 2014 14:39:16 +0200 (CEST) (envelope-from lars) Date: Sun, 20 Jul 2014 14:39:16 +0200 From: Lars Engels To: krad Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140720123916.GV96250@e-new.0x20.net> Mail-Followup-To: Lars Engels , krad , Stephen Hurd , FreeBSD Mailing List , Gerrit =?utf-8?B?S8O8aG4=?= , freebsd-current@freebsd.org, Gleb Smirnoff , Matt Bettinger References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AMNVzrRY61gDOMe/" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, Stephen Hurd , Gleb Smirnoff , Gerrit =?utf-8?B?S8O8aG4=?= , FreeBSD Mailing List , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 12:39:23 -0000 --AMNVzrRY61gDOMe/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: > all of that is true, but you are missing the point. Having two versions of > pf on the bsd's at the user level, is a bad thing. It confuses people, > which puts them off. Its a classic case of divide an conquer for other > platforms. I really like the idea of the openpf version, that has been > mentioned in this thread. It would be awesome if it ended up as a supported > linux thing as well, so the world could be rid of iptables. However i guess > thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. --AMNVzrRY61gDOMe/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJTy7h0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tcUAH/jgTS6/mNxC710EzLKEHGOfi qpAn3FG+f6MylvzE8/8LLf0mpbuGKxQYptaBlQoTjl0JCWdTIzmto/kWnWoyEtLP MmTtvDN3OfRv813KKgG83OpZ/4N39+zWCcco5Z/kCE9iF5AZPcVWHTxGsq6zBdFm nlKChzlYPSrSCaqldj2zRtf4N+JuOdoOYh3Mp9+CzdbmHtKOPq4/uwgyR0MfCQzK GpbatNbcXR5syjOMMzZVktOfbpNU3IjHFMCDo5IGy5ZB7gTBZdS7zALfMm0+34Vb EEyEFOx/1KbcSTbgKvdLf3JTYEeiFsb2lY8JL6XOH92IK/tWCGVpUK+4H2UgjIw= =xaNd -----END PGP SIGNATURE----- --AMNVzrRY61gDOMe/-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 14:04:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBA20B36; Sun, 20 Jul 2014 14:04:04 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2A5A2630; Sun, 20 Jul 2014 14:04:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=900LGaysOB2Y78iPGwks4OhbRxCvIzb8vQzUlwyExnY=; b=mSw4lN8GRSG6L+0WPBH6gu+bAHzhZAPQ2/KJvZpcYQlUgqnLQdY7IpW1m2Sus0wyG0sLtnsLFBDeKMZsr60v8R9RIu9UDBbxrOyTrfJxklS3qO3si9TbS9L2sxG5qjCw0C1aJFKWV0eYgyigjxEh0PZb5eKSJN1UEJe8E2WuTJE=; Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]:39578 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X8ric-000ANz-35; Sun, 20 Jul 2014 09:04:04 -0500 Date: Sun, 20 Jul 2014 09:03:50 -0500 From: Larry Rosenman To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: [ZFS][PANIC] Solaris Assert/zio.c:2548 Message-ID: <20140720140350.GA8498@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 14:04:05 -0000 Got the following panic overnight (I think while a nightly rsync was running): Dump header from device /dev/gpt/swap0 Architecture: amd64 Architecture Version: 2 Dump Length: 8122101760B (7745 MB) Blocksize: 512 Dumptime: Sun Jul 20 03:22:18 2014 Hostname: borg.lerctr.org Magic: FreeBSD Kernel Dump Version String: FreeBSD 11.0-CURRENT #50 r268894M: Sat Jul 19 18:06:08 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER Panic String: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 Dump Parity: 763150733 Bounds: 5 Dump Status: good borg.lerctr.org dumped core - see /var/crash/vmcore.5 Sun Jul 20 03:28:12 CDT 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #50 r268894M: Sat Jul 19 18:06:08 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c49f930 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c49f9e0 vpanic() at vpanic+0x126/frame 0xfffffe100c49fa20 panic() at panic+0x43/frame 0xfffffe100c49fa80 assfail() at assfail+0x1d/frame 0xfffffe100c49fa90 zio_vdev_io_assess() at zio_vdev_io_assess+0x2ed/frame 0xfffffe100c49fac0 zio_execute() at zio_execute+0x1e9/frame 0xfffffe100c49fb20 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe100c49fb80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe100c49fbb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c49fbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c49fbf0 --- trap 0, rip = 0, rsp = 0xfffffe100c49fcb0, rbp = 0 --- Uptime: 8h57m17s (ada2:ahcich2:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: Command timeout (ada2:ahcich2:0:0:0): Error 5, Retries exhausted (ada2:ahcich2:0:0:0): Synchronize cache failed Dumping 7745 out of 64463 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkms.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ether.ko.symbols Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff80a055f7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:445 #2 0xffffffff80a05b35 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:744 #3 0xffffffff80a05b83 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:673 #4 0xffffffff8032d05d in assfail (a=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 #5 0xffffffff8040ad6d in zio_vdev_io_assess (ziop=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2874 #6 0xffffffff80405dd9 in zio_execute (zio=0xfffff809e449b730) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1416 #7 0xffffffff80a4de60 in taskqueue_run_locked (queue=0xfffff8002255e800) at /usr/src/sys/kern/subr_taskqueue.c:356 #8 0xffffffff80a4e8db in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:623 #9 0xffffffff809d3cc4 in fork_exit ( callout=0xffffffff80a4e840 , arg=0xfffff80022611470, frame=0xfffffe100c49fc00) at /usr/src/sys/kern/kern_fork.c:977 #10 0xffffffff80df5afe in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #11 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) vmcore is available. I re-ran the rsync, and no panic. Ideas? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 14:22:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E3C31AD for ; Sun, 20 Jul 2014 14:22:39 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 146DD280F for ; Sun, 20 Jul 2014 14:22:38 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id bs8so2861010wib.14 for ; Sun, 20 Jul 2014 07:22:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=H9+aICbJ8FU9+xCwiNofIKUU6ScXHgU2aW6uSMDRWFc=; b=Lfbfm+3dmIAoiZia8X6vgRowEar6LHCInwpM23jYwqO2vBcw7iBVTL13RvRQg6qDRn R1bgbMyW/hxsE1uEuHugSlTMum0c0xl71WDwx5N6ZCMmrU5ba277f3eTetIRN6JZDCHy QPxyXod97IJbV5nhJXf6taZ+ccbH6EkO9ekm7EjtTNcSWtzmq/apdFscwzcjmQdSh9tn LnHKs/4V0rQFDkW1TPc/CjYuPmIjm44IyLFGds8pdtq/iKOSWNl6JOgFjle6pDxp+4lF x8Xg4NnG+kKKKgkghl4yxOw0kLd1uJdkHheUuFzpFl5efYA30gGukeyw5mKhm5dQk38W PZUQ== X-Gm-Message-State: ALoCoQnkbSd+6/80NP26GaIVXNpPoD57KDp1DWTqIFrtQz1hZYTRpiGYRaPsCt82iCASAACxuRIF X-Received: by 10.194.189.50 with SMTP id gf18mr13870619wjc.13.1405865766565; Sun, 20 Jul 2014 07:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.91.233 with HTTP; Sun, 20 Jul 2014 07:15:36 -0700 (PDT) In-Reply-To: <20140720123916.GV96250@e-new.0x20.net> References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> From: Maxim Khitrov Date: Sun, 20 Jul 2014 10:15:36 -0400 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? To: FreeBSD Mailing List , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 14:22:39 -0000 On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels wrote: > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: >> all of that is true, but you are missing the point. Having two versions of >> pf on the bsd's at the user level, is a bad thing. It confuses people, >> which puts them off. Its a classic case of divide an conquer for other >> platforms. I really like the idea of the openpf version, that has been >> mentioned in this thread. It would be awesome if it ended up as a supported >> linux thing as well, so the world could be rid of iptables. However i guess >> thats just an unrealistic dream > > And you don't seem to get the point that _someone_ has to do the work. > No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 14:31:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCAA28A5; Sun, 20 Jul 2014 14:31:46 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::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 467702926; Sun, 20 Jul 2014 14:31:46 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id p10so6500942wes.2 for ; Sun, 20 Jul 2014 07:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vxM8Jpa2WdBDQFVHOvEWjyEqGRcI1E8PIBFd3cZhIQ8=; b=to9Vy911tTvRm4QjwLHLWipq9PQi8JvQq69dQQuS6Hay3dem7nlNNU8pBM583lWSsU 4CeXjchMtrZSHk7IkeJ6jRVW7pI66fpC6ug6i6AZ3Kz8DnEQgvmI+1MLtCepzm0Tp4Hu Jg4dgfc82vHv6q9MeMCwpIwpdFogKbc5u4ATJVyboAXd1Zg51xVyqV6gU/2Kp3FWbaXP IM9DlPWB1cgffVgavjwUUfQqdEVRcP/d/egOtJrkAAPu0RbQoJl/RRrnXMz6ixktCvFE KBhMmhVn574rcxqKm/CERvA0l+1th21wYs4M7pdrVpRkUzd8wk6SjHte/eOCiFKPls2x +ZZA== X-Received: by 10.194.158.226 with SMTP id wx2mr13807163wjb.107.1405866704516; Sun, 20 Jul 2014 07:31:44 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n8sm30625852wia.19.2014.07.20.07.31.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jul 2014 07:31:43 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 20 Jul 2014 16:31:41 +0200 From: Baptiste Daroussin To: Maxim Khitrov Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140720143140.GF26778@ivaldir.etoilebsd.net> References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vKFfOv5t3oGVpiF+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 14:31:47 -0000 --vKFfOv5t3oGVpiF+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 20, 2014 at 10:15:36AM -0400, Maxim Khitrov wrote: > On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels wrote: > > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: > >> all of that is true, but you are missing the point. Having two version= s of > >> pf on the bsd's at the user level, is a bad thing. It confuses people, > >> which puts them off. Its a classic case of divide an conquer for other > >> platforms. I really like the idea of the openpf version, that has been > >> mentioned in this thread. It would be awesome if it ended up as a supp= orted > >> linux thing as well, so the world could be rid of iptables. However i = guess > >> thats just an unrealistic dream > > > > And you don't seem to get the point that _someone_ has to do the work. > > No one has stepped up so far, so nothing is going to change. >=20 > Gleb believes that the majority of FreeBSD users don't want the > updated syntax, among other changes, from the more recent pf versions. > Developers who share his opinion are not going to volunteer to do the > work. This discussion is about showing this belief to be wrong, which > is the first step in the process. >=20 > In my opinion, the way forward is to forget (at least temporarily) the > SMP changes, bring pf in sync with OpenBSD, put a policy in place to > follow their releases as closely as possible, and then try to > reintroduce all the SMP work. I think the latter has to be done > upstream, otherwise it'll always be a story of diverging codebases. > Furthermore, if FreeBSD developers were willing to spend some time > improving pf performance on OpenBSD, then Henning and other OpenBSD > developers might be more receptive to changes that make the porting > process easier. smp is not the only change we did, if you forget about it you will also get= into other co plication to sync from openbsd Bapt --vKFfOv5t3oGVpiF+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPL0swACgkQ8kTtMUmk6EwBswCgqZUTDayXXQbDxMeRDeluVpFF lNcAn2Dpf2owQxkY4LO9vrXANQ9luA+u =I8MY -----END PGP SIGNATURE----- --vKFfOv5t3oGVpiF+-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 13:39:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B7A3976; Sun, 20 Jul 2014 13:39:32 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC3FF2461; Sun, 20 Jul 2014 13:39:31 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3hGRxr0V2lz1DRn; Sun, 20 Jul 2014 09:39:28 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3hGRxm4Qzcz1Bmx; Sun, 20 Jul 2014 09:39:24 -0400 (EDT) Message-ID: <201407200939020335.0017641F@smtp.24cl.home> In-Reply-To: <53CB4736.90809@bluerosetech.com> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Sun, 20 Jul 2014 09:39:02 -0400 From: "Mike." To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Sun, 20 Jul 2014 15:32:29 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 13:39:32 -0000 On 7/19/2014 at 9:36 PM Darren Pilgrim wrote: |On 7/18/2014 6:51 AM, Franco Fichtner wrote: | [snip] | | |All because over half a decade ago some folks got all butthurt over a |config file format change. ============= I'm juggling two formats for specifying NIC configurations in rc.conf, one on a 8.4 server and another on some 10.0 servers. I've also been through pf.conf syntax changes in the past, and I expect to be subject to pf.con syntax changes in the future. Did I have to do some extra work to accomodate those changes? Yes. Was it worth the effort? Absolutely. Not only am I handling the handling of two NIC configuration syntaxes OK, I look forward to when I can bring the 8.4 server up to 10.x for, among other things, imo the better syntax of the networking configuration in 10.x. imho, the root problem here is that an effort to implement a single feature improvement (multi-threading) has caused the FreeBSD version of pf to apparently reach a near-unmaintainable position in the FreeBSD community because improvements from OpenBSD can no longer be ported over easily. FreeBSD's pf has been put in a virtual isolation chamber due to the multi-threaded enhancement. Was it worth it? From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 15:38:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ED0E339; Sun, 20 Jul 2014 15:38:33 +0000 (UTC) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) by mx1.freebsd.org (Postfix) with ESMTP id E01E32ECE; Sun, 20 Jul 2014 15:38:32 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 1B025A5A6189; Sun, 20 Jul 2014 17:38:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRaN-ieantYU; Sun, 20 Jul 2014 17:38:25 +0200 (CEST) Received: from [192.168.0.11] (95-91-220-47-dynip.superkabel.de [95.91.220.47]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id BBB93A5A6169; Sun, 20 Jul 2014 17:38:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Franco Fichtner In-Reply-To: <201407200939020335.0017641F@smtp.24cl.home> Date: Sun, 20 Jul 2014 17:38:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> To: "Mike." X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 15:38:33 -0000 On 20 Jul 2014, at 15:39, Mike. wrote: > imho, the root problem here is that an effort to implement a single > feature improvement (multi-threading) has caused the FreeBSD version > of pf to apparently reach a near-unmaintainable position in the > FreeBSD community because improvements from OpenBSD can no longer be > ported over easily. FreeBSD's pf has been put in a virtual > isolation chamber due to the multi-threaded enhancement. > > Was it worth it? Yes. This happened *three times* in BSD land now. How much more proof does it take to make that clear? FWIW, I'm still volunteering, but I think the direction this discussion is going is that there is no clear direction, which makes this a tad less effective than it could be. ;) Cheers, Franco From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 16:08:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F4B32CC; Sun, 20 Jul 2014 16:08:30 +0000 (UTC) Received: from mail-out.smeets.im (mail-out.smeets.im [5.9.17.157]) (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 A222E2190; Sun, 20 Jul 2014 16:08:29 +0000 (UTC) Received: from mail.smeets.im (mail.smeets.im [IPv6:2a01:4f8:160:918a::25:3]) by mail-out.smeets.im (Postfix) with ESMTP id 9534A102; Sun, 20 Jul 2014 18:08:19 +0200 (CEST) Received: from amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) by mail.smeets.im (Postfix) with ESMTP id B6EFB892BE; Sun, 20 Jul 2014 18:08:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.im Received: from mail.smeets.im ([IPv6:2a01:4f8:160:918a::25:3]) by amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) (amavisd-new, port 10025) with ESMTP id 8wP71vdvbJaS; Sun, 20 Jul 2014 18:08:18 +0200 (CEST) Received: from nibbler-wlan.home.lan (unknown [IPv6:2001:4dd0:fd65:d00d:b0ad:5d65:8fad:53ad]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smeets.im (Postfix) with ESMTPSA id C1A75892A7; Sun, 20 Jul 2014 18:08:17 +0200 (CEST) Message-ID: <53CBE970.7040904@smeets.im> Date: Sun, 20 Jul 2014 18:08:16 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Larry Rosenman , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 References: <20140720140350.GA8498@borg.lerctr.org> In-Reply-To: <20140720140350.GA8498@borg.lerctr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AgcRWoGoSWFWI2mOpumx6aIf7NdNBOb4A" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 16:08:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AgcRWoGoSWFWI2mOpumx6aIf7NdNBOb4A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20/07/14 16:03, Larry Rosenman wrote: > Panic String: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), > file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, > line: 2874 >=20 > Unread portion of the kernel message buffer: panic: solaris assert: > !(zio->io_flags & ZIO_FLAG_DELEGATED), file: > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: > 2874 cpuid =3D 7 KDB: stack backtrace: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe100c49f930 kdb_backtrace() > at kdb_backtrace+0x39/frame 0xfffffe100c49f9e0 vpanic() at > vpanic+0x126/frame 0xfffffe100c49fa20 panic() at panic+0x43/frame > 0xfffffe100c49fa80 assfail() at assfail+0x1d/frame > 0xfffffe100c49fa90 zio_vdev_io_assess() at > zio_vdev_io_assess+0x2ed/frame 0xfffffe100c49fac0 zio_execute() at > zio_execute+0x1e9/frame 0xfffffe100c49fb20 taskqueue_run_locked() at > taskqueue_run_locked+0xf0/frame 0xfffffe100c49fb80=20 > taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame > 0xfffffe100c49fbb0 fork_exit() at fork_exit+0x84/frame > 0xfffffe100c49fbf0 fork_trampoline() at fork_trampoline+0xe/frame > 0xfffffe100c49fbf0 --- trap 0, rip =3D 0, rsp =3D 0xfffffe100c49fcb0, r= bp > =3D 0 --- Uptime: 8h57m17s (ada2:ahcich2:0:0:0): FLUSHCACHE48. ACB: ea > 00 00 00 00 40 00 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: Same here, running poudriere the box panics reproducibly within 2-5 secon= ds. panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zio.c, line: 2874 cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00002e97f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00002e98a0 vpanic() at vpanic+0x126/frame 0xfffffe00002e98e0 panic() at panic+0x43/frame 0xfffffe00002e9940 assfail() at assfail+0x1d/frame 0xfffffe00002e9950 zio_vdev_io_assess() at zio_vdev_io_assess+0x2e8/frame 0xfffffe00002e9980= zio_execute() at zio_execute+0x1e9/frame 0xfffffe00002e99e0 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe00002e9= a40 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe00002e9a70 fork_exit() at fork_exit+0x84/frame 0xfffffe00002e9ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002e9ab0 --- trap 0, rip =3D 0, rsp =3D 0xfffffe00002e9b70, rbp =3D 0 --- KDB: enter: panic [ thread pid 0 tid 100422 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why Florian --AgcRWoGoSWFWI2mOpumx6aIf7NdNBOb4A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTy+lwAAoJEOcFPfn/hvB2m1gP/jGaEsE8fYSEDzsR3mrkCcvj ufua/sWSJ0mh7NuLmBHilxEibeqqWIeodken6aZ/OghDWkIK4S2vVox8e9dA/arL h/LxdpmL1Px3jwUQIyQnySj4vw+4e+l32mipwQ2Dy24PMixkwnHhx7PafkHigAeW Dvtx2O1DSRw+ohWYYlsabFlhnWwORd5dPFB9T0h55px/j2pP5zEiDs9hNgA5eI87 Ez4pq5oW9i6i/HbqfBtNwd57bCSn/ezgcLZF3JMntICh42AOoxNIy+2xkTkfTeRL 8FFQKeaEYaDHDuAMLEGLPzzJRmjETs5O2lhKmYwo76JUtjgUmU7+VyrBm1tgGKqI q4zIqiCLX2fkXIeP86LsUCG614RH4mkNF2yIFwNwXuPmYhUJqaqxsFVrUGSGLEVk WxguymQ6PtSfSpfdH85pPCJdb+PyRqt/mkYGVz9ec/X4wsEKqCcX1jNCQ7TTm0yV Zag3SLE1Hq+9/WKddZyN+JcnHJEYD+xBhfM5J3gclpq02LPYo66jOV2gP4X3tkPb hhVolX+AjZ+ytMaTB0tg0uh8Z3qPRlG3K940YnlCwsOrtzi5n7bMz976h4MbshuV CkyzB3OefWiQMTLxTdR/xTCjOAFS2e8nO4xyPaUG9rTVqe/A0yA99JmI9+YDntNE 7kgMr9/XRLZn7zVsTzw0 =gSTb -----END PGP SIGNATURE----- --AgcRWoGoSWFWI2mOpumx6aIf7NdNBOb4A-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 16:31:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A37A9C53; Sun, 20 Jul 2014 16:31:04 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E91223E8; Sun, 20 Jul 2014 16:31:04 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3hGWlm6bnzz1DRn; Sun, 20 Jul 2014 12:31:00 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3hGWll0r1pz1Bn8; Sun, 20 Jul 2014 12:30:59 -0400 (EDT) Message-ID: <201407201230590265.00B479C4@smtp.24cl.home> In-Reply-To: <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Sun, 20 Jul 2014 12:30:59 -0400 From: "Mike." To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Sun, 20 Jul 2014 17:12:05 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 16:31:04 -0000 On 7/20/2014 at 5:38 PM Franco Fichtner wrote: |On 20 Jul 2014, at 15:39, Mike. wrote: | |> imho, the root problem here is that an effort to implement a single |> feature improvement (multi-threading) has caused the FreeBSD version |> of pf to apparently reach a near-unmaintainable position in the |> FreeBSD community because improvements from OpenBSD can no longer be |> ported over easily. FreeBSD's pf has been put in a virtual |> isolation chamber due to the multi-threaded enhancement. |> |> Was it worth it? | |Yes. This happened *three times* in BSD land now. How much more |proof does it take to make that clear? |[snip] ============= In this instance, more proof would consist of pf development not wallowing in inactivity. imo, tactical changes were implemented in pf without the strategic negative consequences affecting the decision process guiding the implementation of those tactical features. And that's backwards. Strategies direct tactics, not vice versa. From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 17:20:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC7EFE84 for ; Sun, 20 Jul 2014 17:20:13 +0000 (UTC) Received: from st11p00mm-asmtp004.mac.com (st11p00mm-asmtp004.mac.com [17.172.81.3]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 935DA27F4 for ; Sun, 20 Jul 2014 17:20:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from andersbo-mac.local (ti0025a400-5325.bb.online.no [85.167.91.221]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0N9000BPSQP32G20@st11p00mm-asmtp004.mac.com> for freebsd-current@freebsd.org; Sun, 20 Jul 2014 16:19:57 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-07-20_02:2014-07-18,2014-07-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=15 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407200217 Message-id: <53CBEC26.7080404@icloud.com> Date: Sun, 20 Jul 2014 18:19:50 +0200 From: Anders Bolt-Evensen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: freebsd-current@freebsd.org Subject: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 17:20:14 -0000 Hello, everyone! Last week, I created a custom ISO from the latest -CURRENT sources which contained an EFI image that is bootable on my MacBook Pro. Both installation and booting from this new FreeBSD 11 EFI system goes without any problems. However, I've also installed X11 and GNOME to get a graphical environment to work with, and that's when my problem occurs. This computer has an Intel HD 3000 card as well as an AMD Radeon Mobility HD 6770M card. The problem is that every time I start up X, using the Intel driver, the screen freezes with a cursor in the top left corner of the screen. In other words, the X windowing system does not show up at all. Pressing i.e. alt+F2 to switch away from this screen does not work. When I try to use the radeon driver, X exits because of BIOS errors (since I do not use BIOS when in EFI mode), as can be seen from the output of "dmesg -a" from a verbose boot (at the time dmesg -a was run, I had commented out the line with the intel driver to force it to use the radeon driver instead, since the intel driver caused the screen to freeze). The vesa driver does not work either. My Mac is using EFI 1.10. I hope you guys can help out on the screen freezing issue when I start X.org. It is worth mentioning that even if the screen freezes when X is starting, the computer is still fully able to run other commands. Thanks in advance and a great and happy summer to you all. Output from "uname -a" FreeBSD andersbo-mac.local 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r268745: Wed Jul 16 14:41:59 CEST 2014 root@andersbo-mac.local:/usr/obj/usr/src/sys/ANDERSBO-MAC amd64 Output from dmesg -a: Table 'FACP' at 0x8ad8c000 Table 'HPET' at 0x8ad8b000 Table 'APIC' at 0x8ad8a000 APIC: Found table at 0x8ad8a000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 3: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 4: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 1 ACPI ID 5: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 6: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 7: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 7 ACPI ID 8: enabled SMP: Added CPU 7 (AP) Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r268745: Wed Jul 16 14:41:59 CEST 2014 root@andersbo-mac.local:/usr/obj/usr/src/sys/ANDERSBO-MAC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "efifb". Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81aa3000. Preloaded elf obj module "/boot/kernel/linux.ko" at 0xffffffff81aa5b98. Preloaded elf obj module "/boot/kernel/sem.ko" at 0xffffffff81aa6500. Calibrating TSC clock ... TSC clock: 2394611200 Hz CPU: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz (2394.61-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 Features=0xbfebfbff Features2=0x1fbae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 10466885632 (9982 MB) Physical memory chunk(s): 0x0000000000010000 - 0x000000000008afff, 503808 bytes (123 pages) 0x0000000000090000 - 0x000000000009ffff, 65536 bytes (16 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000001ad5000 - 0x000000001fffffff, 508735488 bytes (124203 pages) 0x0000000020200000 - 0x000000003fffffff, 534773760 bytes (130560 pages) 0x0000000040200000 - 0x000000008ad33fff, 1253261312 bytes (305972 pages) 0x000000008ad5f000 - 0x000000008ad6ffff, 69632 bytes (17 pages) 0x000000008ad8f000 - 0x000000008ae5dfff, 847872 bytes (207 pages) 0x000000008ae8f000 - 0x000000008aed7fff, 299008 bytes (73 pages) 0x000000008aeff000 - 0x000000008afa2fff, 671744 bytes (164 pages) 0x0000000100000000 - 0x000000025ff4bfff, 5904842752 bytes (1441612 pages) avail memory = 8151646208 (7774 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 5 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 6 APIC: CPU 4 has ACPI ID 3 APIC: CPU 5 has ACPI ID 7 APIC: CPU 6 has ACPI ID 4 APIC: CPU 7 has ACPI ID 8 lapic0: CMCI unmasked x86bios: IVT 0x000000-0x0004ff at 0xfffff80000000000 x86bios: SSEG 0x08a000-0x08afff at 0xfffffe01e955b000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffff800000a0000 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ACPI: RSDP 0x8ad8e014 00024 (v02 APPLE ) ACPI: XSDT 0x8ad8e1c0 0009C (v01 APPLE Apple00 00000047 01000013) ACPI: FACP 0x8ad8c000 000F4 (v04 APPLE Apple00 00000047 Loki 0000005F) ACPI: DSDT 0x8ad80000 06F12 (v01 APPLE MacBookP 00080001 INTL 20061109) ACPI: FACS 0x8ad3e000 00040 ACPI: HPET 0x8ad8b000 00038 (v01 APPLE Apple00 00000001 Loki 0000005F) ACPI: APIC 0x8ad8a000 000BC (v02 APPLE Apple00 00000001 Loki 0000005F) ACPI: SBST 0x8ad88000 00030 (v01 APPLE Apple00 00000001 Loki 0000005F) ACPI: ECDT 0x8ad87000 00053 (v01 APPLE Apple00 00000001 Loki 0000005F) ACPI: SSDT 0x8ad7c000 0020D (v01 APPLE SataOdd 00001000 INTL 20061109) ACPI: SSDT 0x8ad7b000 00024 (v01 APPLE SmcDppt 00001000 INTL 20061109) ACPI: SSDT 0x8ad7a000 0061A (v01 APPLE UsbExcd 00001000 INTL 20061109) ACPI: SSDT 0x8ad76000 00159 (v02 APPLE IGHda 00001000 INTL 20061109) ACPI: SSDT 0x8ad74000 00032 (v01 APPLE SsdtS3 00001000 INTL 20061109) ACPI: SSDT 0x8ad73000 005CC (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0x8ad72000 009B1 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: SSDT 0x8ad71000 00315 (v01 PmRef Cpu0Tst 00003000 INTL 20061109) ACPI: SSDT 0x8ad70000 0037A (v01 PmRef ApTst 00003000 INTL 20061109) ACPI: MCFG 0x8ad89000 0003C (v01 APPLE Apple00 00000001 Loki 0000005F) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic4: Routing NMI -> LINT1 lapic4: LINT1 trigger: edge lapic4: LINT1 polarity: high lapic6: Routing NMI -> LINT1 lapic6: LINT1 trigger: edge lapic6: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic5: Routing NMI -> LINT1 lapic5: LINT1 trigger: edge lapic5: LINT1 polarity: high lapic7: Routing NMI -> LINT1 lapic7: LINT1 trigger: edge lapic7: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 Hardware, Intel Secure Key RNG: RDRAND is not present Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present Falling back to random adaptor random: initialized nfslock: pseudo-device kbd0 at kbdmux0 mem: module_register_init: MOD_LOAD (vesa, 0xffffffff80e284a0, 0) error 19 io: VMBUS: load null: hptnr: R750/DC7280 controller driver v1.0 hpt27xx: RocketRAID 27xx controller driver v1.1 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0x8ad3a818 00781 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00781 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 2 cpu1: on acpi0 ACPI: SSDT 0x8ad3bc18 003A4 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 003A4 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0x8ad39d98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 4 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 6 cpu3: on acpi0 cpu4: Processor \134_PR_.CPU4 (ACPI ID 5) -> APIC ID 1 cpu4: on acpi0 cpu5: Processor \134_PR_.CPU5 (ACPI ID 6) -> APIC ID 3 cpu5: on acpi0 cpu6: Processor \134_PR_.CPU6 (ACPI ID 7) -> APIC ID 5 cpu6: on acpi0 cpu7: Processor \134_PR_.CPU7 (ACPI ID 8) -> APIC ID 7 cpu7: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 5 range 0-0xff pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xc0000-0xc3fff pcib0: decoding 3 range 0xc4000-0xc7fff pcib0: decoding 3 range 0xc8000-0xcbfff pcib0: decoding 3 range 0xcc000-0xcffff pcib0: decoding 3 range 0xd0000-0xd3fff pcib0: decoding 3 range 0xd4000-0xd7fff pcib0: decoding 3 range 0xd8000-0xdbfff pcib0: decoding 3 range 0xdc000-0xdffff pcib0: decoding 3 range 0xe0000-0xe3fff pcib0: decoding 3 range 0xe4000-0xe7fff pcib0: decoding 3 range 0xe8000-0xebfff pcib0: decoding 3 range 0xec000-0xeffff pcib0: decoding 3 range 0xf0000-0xfffff pcib0: decoding 3 range 0x8fa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0101, revid=0x09 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D3 current D0 MSI supports 1 message secbus=1, subbus=1 found-> vendor=0x8086, dev=0x0105, revid=0x09 domain=0, bus=0, slot=1, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D3 current D0 MSI supports 1 message secbus=5, subbus=155 found-> vendor=0x8086, dev=0x0126, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xb0000000, size 22, enabled pcib0: allocated type 3 (0xb0000000-0xb03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xa0000000, size 28, enabled pcib0: allocated type 3 (0xa0000000-0xafffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xb0907100, size 4, enabled pcib0: allocated type 3 (0xb0907100-0xb090710f) for rid 10 of pci0:0:22:0 found-> vendor=0x8086, dev=0x1c2c, revid=0x05 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 map[20]: type I/O Port, range 32, base 0x3120, size 5, enabled pcib0: allocated type 4 (0x3120-0x313f) for rid 20 of pci0:0:26:0 found-> vendor=0x8086, dev=0x1c2d, revid=0x05 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xb0906c00, size 10, enabled pcib0: allocated type 3 (0xb0906c00-0xb0906fff) for rid 10 of pci0:0:26:7 found-> vendor=0x8086, dev=0x1c20, revid=0x05 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xb0900000, size 14, memory disabled pcib0: allocated type 3 (0xb0900000-0xb0903fff) for rid 10 of pci0:0:27:0 found-> vendor=0x8086, dev=0x1c10, revid=0xb5 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=2, subbus=2 found-> vendor=0x8086, dev=0x1c12, revid=0xb5 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=3, subbus=3 found-> vendor=0x8086, dev=0x1c14, revid=0xb5 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=4, subbus=4 found-> vendor=0x8086, dev=0x1c16, revid=0xb5 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=156, subbus=204 found-> vendor=0x8086, dev=0x1c27, revid=0x05 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 map[20]: type I/O Port, range 32, base 0x30c0, size 5, enabled pcib0: allocated type 4 (0x30c0-0x30df) for rid 20 of pci0:0:29:0 found-> vendor=0x8086, dev=0x1c26, revid=0x05 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xb0906800, size 10, enabled pcib0: allocated type 3 (0xb0906800-0xb0906bff) for rid 10 of pci0:0:29:7 found-> vendor=0x8086, dev=0x1c49, revid=0x05 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x05 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x3148, size 3, enabled pcib0: allocated type 4 (0x3148-0x314f) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x315c, size 2, enabled pcib0: allocated type 4 (0x315c-0x315f) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x3140, size 3, enabled pcib0: allocated type 4 (0x3140-0x3147) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x3158, size 2, enabled pcib0: allocated type 4 (0x3158-0x315b) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xb0906000, size 11, enabled pcib0: allocated type 3 (0xb0906000-0xb09067ff) for rid 24 of pci0:0:31:2 found-> vendor=0x8086, dev=0x1c22, revid=0x05 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=255 map[10]: type Memory, range 64, base 0xb0907000, size 8, memory disabled pcib0: allocated type 3 (0xb0907000-0xb09070ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, port disabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib1: at device 1.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xb0800000-0xb08fffff) for rid 20 of pcib1 pcib0: allocated type 3 (0x90000000-0x9fffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xb0800000-0xb08fffff pcib1: prefetched decode 0x90000000-0x9fffffff pci1: on pcib1 pcib1: allocated bus range (1-1) for rid 0 of pci1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x6740, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0x90000000, size 28, enabled pcib1: allocated prefetch range (0x90000000-0x9fffffff) for rid 10 of pci0:1:0:0 map[18]: type Memory, range 64, base 0xb0800000, size 17, enabled pcib1: allocated memory range (0xb0800000-0xb081ffff) for rid 18 of pci0:1:0:0 map[20]: type I/O Port, range 32, base 0x2000, size 8, enabled pcib1: allocated I/O port range (0x2000-0x20ff) for rid 20 of pci0:1:0:0 found-> vendor=0x1002, dev=0xaa90, revid=0x00 domain=0, bus=1, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xb0840000, size 14, memory disabled pcib1: allocated memory range (0xb0840000-0xb0843fff) for rid 10 of pci0:1:0:1 vgapci0: port 0x2000-0x20ff mem 0x90000000-0x9fffffff,0xb0800000-0xb081ffff at device 0.0 on pci1 vgapci0: Boot video device hdac0: mem 0xb0840000-0xb0843fff at device 0.1 on pci1 hdac0: PCI card vendor: 0x0000, device: 0xaa90 hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 1, ISS 0, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib2: at device 1.1 on pci0 pcib0: allocated type 4 (0x4000-0x4fff) for rid 1c of pcib2 pcib0: allocated type 3 (0xb0a00000-0xb4efffff) for rid 20 of pcib2 pcib0: allocated type 3 (0xb9000000-0xbcffffff) for rid 24 of pcib2 pcib2: domain 0 pcib2: secondary bus 5 pcib2: subordinate bus 155 pcib2: I/O decode 0x4000-0x4fff pcib2: memory decode 0xb0a00000-0xb4efffff pcib2: prefetched decode 0xb9000000-0xbcffffff pci5: on pcib2 pcib2: allocated bus range (5-5) for rid 0 of pci5 pci5: domain=0, physical bus=5 vgapci1: port 0x3000-0x303f mem 0xb0000000-0xb03fffff,0xa0000000-0xafffffff at device 2.0 on pci0 agp0: on vgapci1 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: 00000000 agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 pci0: at device 22.0 (no driver attached) uhci0: port 0x3120-0x313f at device 26.0 on pci0 pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 60 uhci0: LegSup = 0x2400 usbus0 on uhci0 uhci0: usbpf: Attached ehci0: mem 0xb0906c00-0xb0906fff at device 26.7 on pci0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci0 ehci0: usbpf: Attached hdac1: mem 0xb0900000-0xb0903fff at device 27.0 on pci0 hdac1: PCI card vendor: 0x8086, device: 0x7270 hdac1: HDA Driver Revision: 20120126_0002 hdac1: Config options: on=0x00000000 off=0x00000000 hdac1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 hdac1: using IRQ 265 for MSI hdac1: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib3: at device 28.0 on pci0 pcib0: allocated type 3 (0xb0700000-0xb07fffff) for rid 20 of pcib3 pcib0: allocated type 3 (0xb0400000-0xb04fffff) for rid 24 of pcib3 pcib3: domain 0 pcib3: secondary bus 2 pcib3: subordinate bus 2 pcib3: memory decode 0xb0700000-0xb07fffff pcib3: prefetched decode 0xb0400000-0xb04fffff pci2: on pcib3 pcib3: allocated bus range (2-2) for rid 0 of pci2 pci2: domain=0, physical bus=2 found-> vendor=0x14e4, dev=0x16b4, revid=0x10 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 6 messages in map 0x18 map[10]: type Prefetchable Memory, range 64, base 0xb0400000, size 16, memory disabled pcib3: allocated prefetch range (0xb0400000-0xb040ffff) for rid 10 of pci0:2:0:0 map[18]: type Prefetchable Memory, range 64, base 0xb0410000, size 16, enabled pcib3: allocated prefetch range (0xb0410000-0xb041ffff) for rid 18 of pci0:2:0:0 bge0: mem 0xb0400000-0xb040ffff,0xb0410000-0xb041ffff at device 0.0 on pci2 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 266 to local APIC 0 vector 63 bge0: using IRQ 266 for MSI bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 4 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: 3c:07:54:62:13:42 pcib4: at device 28.1 on pci0 pcib0: allocated type 3 (0xb0600000-0xb06fffff) for rid 20 of pcib4 pcib4: domain 0 pcib4: secondary bus 3 pcib4: subordinate bus 3 pcib4: memory decode 0xb0600000-0xb06fffff pci3: on pcib4 pcib4: allocated bus range (3-3) for rid 0 of pci3 pci3: domain=0, physical bus=3 found-> vendor=0x14e4, dev=0x4331, revid=0x02 domain=0, bus=3, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0018, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xb0600000, size 14, enabled pcib4: allocated memory range (0xb0600000-0xb0603fff) for rid 10 of pci0:3:0:0 pci3: at device 0.0 (no driver attached) pcib5: at device 28.2 on pci0 pcib0: allocated type 3 (0xb0500000-0xb05fffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 4 pcib5: subordinate bus 4 pcib5: memory decode 0xb0500000-0xb05fffff pci4: on pcib5 pcib5: allocated bus range (4-4) for rid 0 of pci4 pci4: domain=0, physical bus=4 found-> vendor=0x11c1, dev=0x5901, revid=0x08 domain=0, bus=4, slot=0, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xb0500000, size 12, enabled pcib5: allocated memory range (0xb0500000-0xb0500fff) for rid 10 of pci0:4:0:0 pci4: at device 0.0 (no driver attached) pcib6: at device 28.3 on pci0 pcib0: allocated type 4 (0x5000-0x5fff) for rid 1c of pcib6 pcib0: allocated type 3 (0xb4f00000-0xb8ffffff) for rid 20 of pcib6 pcib0: allocated type 3 (0xbd000000-0xc0ffffff) for rid 24 of pcib6 pcib6: domain 0 pcib6: secondary bus 156 pcib6: subordinate bus 204 pcib6: I/O decode 0x5000-0x5fff pcib6: memory decode 0xb4f00000-0xb8ffffff pcib6: prefetched decode 0xbd000000-0xc0ffffff pci156: on pcib6 pcib6: allocated bus range (156-156) for rid 0 of pci156 pci156: domain=0, physical bus=156 found-> vendor=0x168c, dev=0x0024, revid=0x01 domain=0, bus=156, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D3 current D0 MSI supports 1 message MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xb4f00000, size 16, memory disabled pcib6: allocated memory range (0xb4f00000-0xb4f0ffff) for rid 10 of pci0:156:0:0 ath0: mem 0xb4f00000-0xb4f0ffff at device 0.0 on pci156 pcib6: matched entry for 156.0.INTA pcib6: slot 0 INTA hardwired to IRQ 19 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 64 ath0: [HT] enabling HT modes ath0: [HT] RTS aggregates limited to 8 KiB ath0: [HT] 2 RX streams; 2 TX streams ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: 11ng MCS 40MHz: ath0: MCS 0-7: 13.5Mbps - 135Mbps ath0: MCS 8-15: 27Mbps - 270Mbps ath0: 11ng MCS 40MHz SGI: ath0: MCS 0-7: 15Mbps - 150Mbps ath0: MCS 8-15: 30Mbps - 300Mbps ath0: AR5418 mac 12.10 RF2122 phy 8.1 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00f0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search uhci1: port 0x30c0-0x30df at device 29.0 on pci0 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 uhci1: LegSup = 0x2400 usbus2 on uhci1 uhci1: usbpf: Attached ehci1: mem 0xb0906800-0xb0906bff at device 29.7 on pci0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 65 usbus3: EHCI version 1.0 usbus3 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3148-0x314f,0x315c-0x315f,0x3140-0x3147,0x3158-0x315b,0x3060-0x307f mem 0xb0906000-0xb09067ff at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 267 to local APIC 0 vector 66 ahci0: using IRQ 267 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: at channel 1 on ahci0 ahcich1: Caps: ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED pci0: at device 31.3 (no driver attached) battery0: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 ACPI: Enabled 4 GPEs in block 00 to 3F acpi0: wakeup code va 0xfffffe0233013000 pa 0x80000 ex_isa_identify() ahc_isa_identify 0: ioport 0xc00 alloc failed ahc_isa_identify 1: ioport 0x1c00 alloc failed ahc_isa_identify 2: ioport 0x2c00 alloc failed ahc_isa_identify 3: ioport 0x3c00 alloc failed ahc_isa_identify 4: ioport 0x4c00 alloc failed ahc_isa_identify 5: ioport 0x5c00 alloc failed ahc_isa_identify 6: ioport 0x6c00 alloc failed ahc_isa_identify 7: ioport 0x7c00 alloc failed ahc_isa_identify 8: ioport 0x8c00 alloc failed ahc_isa_identify 9: ioport 0x9c00 alloc failed ahc_isa_identify 10: ioport 0xac00 alloc failed ahc_isa_identify 11: ioport 0xbc00 alloc failed ahc_isa_identify 12: ioport 0xcc00 alloc failed ahc_isa_identify 13: ioport 0xdc00 alloc failed ahc_isa_identify 14: ioport 0xec00 alloc failed pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xc0000-0xc07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc0800-0xc0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc1000-0xc17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc1800-0xc1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc2000-0xc27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc2800-0xc2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc3000-0xc37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc3800-0xc3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc4000-0xc47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc4800-0xc4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc5000-0xc57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc5800-0xc5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc6000-0xc67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc6800-0xc6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc7000-0xc77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc7800-0xc7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc8000-0xc87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc8800-0xc8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xc9000-0xc97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xc9800-0xc9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xca000-0xca7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xca800-0xcafff) for rid 0 of orm0 pcib0: allocated type 3 (0xcb000-0xcb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xcb800-0xcbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xcc000-0xcc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xcc800-0xccfff) for rid 0 of orm0 pcib0: allocated type 3 (0xcd000-0xcd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xcd800-0xcdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xce000-0xce7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xce800-0xcefff) for rid 0 of orm0 pcib0: allocated type 3 (0xcf000-0xcf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xcf800-0xcffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 0 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 0 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 0 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 0 of orm0 pcib0: allocated type 3 (0xe0000-0xe07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe0800-0xe0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe1000-0xe17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe1800-0xe1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe2000-0xe27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe2800-0xe2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe3000-0xe37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe3800-0xe3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe4000-0xe47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe4800-0xe4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe5000-0xe57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe5800-0xe5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe6000-0xe67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe6800-0xe6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe7000-0xe77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe7800-0xe7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe8000-0xe87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe8800-0xe8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xe9000-0xe97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe9800-0xe9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xea000-0xea7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xea800-0xeafff) for rid 0 of orm0 pcib0: allocated type 3 (0xeb000-0xeb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xeb800-0xebfff) for rid 0 of orm0 pcib0: allocated type 3 (0xec000-0xec7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xec800-0xecfff) for rid 0 of orm0 pcib0: allocated type 3 (0xed000-0xed7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xed800-0xedfff) for rid 0 of orm0 pcib0: allocated type 3 (0xee000-0xee7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xee800-0xeefff) for rid 0 of orm0 pcib0: allocated type 3 (0xef000-0xef7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xef800-0xeffff) for rid 0 of orm0 pcib0: allocated type 3 (0xf0000-0xf07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf0800-0xf0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf1000-0xf17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf1800-0xf1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf2000-0xf27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf2800-0xf2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf3000-0xf37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf3800-0xf3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf4000-0xf47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf4800-0xf4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf5000-0xf57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf5800-0xf5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf6000-0xf67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf6800-0xf6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf7000-0xf77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf7800-0xf7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf8000-0xf87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf8800-0xf8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xf9000-0xf97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xf9800-0xf9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xfa000-0xfa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xfa800-0xfafff) for rid 0 of orm0 pcib0: allocated type 3 (0xfb000-0xfb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xfb800-0xfbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xfc000-0xfc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xfc800-0xfcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xfd000-0xfd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xfd800-0xfdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xfe000-0xfe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xfe800-0xfefff) for rid 0 of orm0 pcib0: allocated type 3 (0xff000-0xff7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xff800-0xfffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0 failed to probe on isa0 vga0 failed to probe on isa0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbdc0: AT keyboard controller not found atkbdc0 failed to probe at port 0x60,0x64 on isa0 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0 failed to probe at irq 7 on isa0 pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 uart0 failed to probe at port 0x3f8-0x3ff irq 4 on isa0 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 uart1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 49887739 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining Linux ELF exec handler installed tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 lo0: bpf attached hptnr: no controller detected. hpt27xx: no controller detected. hptrr: no controller detected. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x00aa0100 hdaa0: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 3 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 3 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: 1 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=3 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 3 traced to DAC 2 hdaa0: Association 0 (1) trace succeeded hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Tracing input monitor hdaa0: Tracing other input monitors hdaa0: Tracing beeper hdaa0: Pin sense: nid=3 sense=0x7fffffff (disconnected, ELD valid) hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 3 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000005 AC3 PCM pcm0: PCM cap: 0x00020070 16 bits, 32 44 48 KHz pcm0: DAC: 2 pcm0: pcm0: nid=3 [pin: Digital-out (Jack)] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: pcm0: Mixer "vol" -> "none": child=0x00000010 pcm0: Mixer "pcm": parent="vol" pcm0: Soft PCM mixer ENABLED pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (disconnected) hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x106b2700 hdaa1: NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: GPIO0: disabled hdaa1: GPIO1: disabled hdaa1: GPIO2: output state=0 hdaa1: GPIO3: disabled hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 9 002b4050 5 0 Headphones Jack Combo 0x00 Green 0 hdaa1: 10 90100141 4 1 Speaker Fixed Unknown Internal Unknown 1 hdaa1: 11 90100140 4 0 Speaker Fixed Unknown Internal Unknown 1 hdaa1: 12 008b3020 2 0 Line-in Jack Combo 0x00 Blue 0 hdaa1: 13 90a00110 1 0 Mic Fixed Unknown Internal Unknown 1 hdaa1: 14 400000f0 15 0 Line-out None Unknown 0x00 Unknown 0 hdaa1: 15 00cbe030 3 0 SPDIF-in Jack Combo 0x00 White 0 hdaa1: 16 004be060 6 0 SPDIF-out Jack Combo 0x00 White 0 hdaa1: 18 400000f0 15 0 Line-out None Unknown 0x00 Unknown 0 hdaa1: 21 400000f0 15 0 Line-out None Unknown 0x00 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 9 002b4050 5 0 Headphones Jack Combo 0x00 Green 0 hdaa1: 10 90100141 4 1 Speaker Fixed Unknown Internal Unknown 1 hdaa1: 11 90100140 4 0 Speaker Fixed Unknown Internal Unknown 1 hdaa1: 12 008b3020 2 0 Line-in Jack Combo 0x00 Blue 0 hdaa1: 13 90a00110 1 0 Mic Fixed Unknown Internal Unknown 1 hdaa1: 14 400000f0 15 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa1: 15 00cbe030 3 0 SPDIF-in Jack Combo 0x00 White 0 hdaa1: 16 004be060 6 0 SPDIF-out Jack Combo 0x00 White 0 hdaa1: 18 400000f0 15 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa1: 21 400000f0 15 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa1: 6 associations found: hdaa1: Association 0 (1) in: hdaa1: Pin nid=13 seq=0 hdaa1: Association 1 (2) in: hdaa1: Pin nid=12 seq=0 hdaa1: Association 2 (3) in: hdaa1: Pin nid=15 seq=0 hdaa1: Association 3 (4) out: hdaa1: Pin nid=11 seq=0 hdaa1: Pin nid=10 seq=1 hdaa1: Association 4 (5) out: hdaa1: Pin nid=9 seq=0 hdaa1: Association 5 (6) out: hdaa1: Pin nid=16 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Unable to trace pin 13 to ADC 5, undo traces hdaa1: Pin 13 traced to ADC 6 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 12 traced to ADC 5 hdaa1: Association 1 (2) trace succeeded hdaa1: Tracing association 2 (3) hdaa1: Pin 15 traced to ADC 7 hdaa1: Association 2 (3) trace succeeded hdaa1: Tracing association 3 (4) hdaa1: Pin 11 traced to DAC 4 hdaa1: Pin 10 traced to DAC 3 hdaa1: Association 3 (4) trace succeeded hdaa1: Tracing association 4 (5) hdaa1: Pin 9 traced to DAC 2 hdaa1: Association 4 (5) trace succeeded hdaa1: Tracing association 5 (6) hdaa1: Pin 16 traced to DAC 8 hdaa1: Association 5 (6) trace succeeded hdaa1: Looking for additional ADC for association 0 (1) hdaa1: Looking for additional ADC for association 1 (2) hdaa1: Looking for additional ADC for association 2 (3) hdaa1: Looking for additional DAC for association 3 (4) hdaa1: Looking for additional DAC for association 4 (5) hdaa1: Looking for additional DAC for association 5 (6) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing nid 12 to out hdaa1: Tracing nid 13 to out hdaa1: Tracing nid 15 to out hdaa1: Tracing beeper hdaa1: GPIO commit hdaa1: GPIO0: disabled hdaa1: GPIO1: output state=1 hdaa1: GPIO2: output state=0 hdaa1: GPIO3: output state=1 hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm1: at nid 11,10 and 13 on hdaa1 pcm1: Playback: pcm1: Stream cap: 0x00000003 FLOAT32 PCM pcm1: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm1: DAC: 4 3 pcm1: pcm1: nid=11 [pin: Speaker (Fixed)] pcm1: + <- nid=4 [audio output] [src: pcm] pcm1: pcm1: nid=10 [pin: Speaker (Fixed)] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000003 FLOAT32 PCM pcm1: PCM cap: 0x001e01f5 16 20 24 32 bits, 8 16 32 44 48 88 96 KHz pcm1: ADC: 6 pcm1: pcm1: nid=6 [audio input] pcm1: + <- nid=13 [pin: Mic (Fixed)] [src: monitor] pcm1: pcm1: Master Volume (OSS: vol): -57/6dB pcm1: +- ctl 2 (nid 3 out): -57/6dB (128 steps) + mute pcm1: +- ctl 3 (nid 4 out): -57/6dB (128 steps) + mute pcm1: pcm1: PCM Volume (OSS: pcm): -57/6dB pcm1: +- ctl 2 (nid 3 out): -57/6dB (128 steps) + mute pcm1: +- ctl 3 (nid 4 out): -57/6dB (128 steps) + mute pcm1: pcm1: Microphone2 Volume (OSS: monitor): 0/30dB pcm1: +- ctl 5 (nid 6 in 0): -51/12dB (64 steps) + mute pcm1: +- ctl 7 (nid 13 out): 0/30dB (4 steps) pcm1: pcm1: Recording Level (OSS: rec): -51/12dB pcm1: +- ctl 5 (nid 6 in 0): -51/12dB (64 steps) + mute pcm1: +- ctl 7 (nid 13 out): 0/30dB (4 steps) pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "rec": pcm1: Mixer "monitor": pcm1: Playback channel set is: Front Left, Front Right, Front Center, Low Frequency Effects, pcm1: Playback channel matrix is: 2.0 (unknown) pcm1: Automatically set rec source to: monitor pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (unknown) pcm2: at nid 9 and 12 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000003 FLOAT32 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=9 [pin: Headphones (Green Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Record: pcm2: Stream cap: 0x00000003 FLOAT32 PCM pcm2: PCM cap: 0x001e01f5 16 20 24 32 bits, 8 16 32 44 48 88 96 KHz pcm2: ADC: 5 pcm2: pcm2: nid=5 [audio input] pcm2: + <- nid=12 [pin: Line-in (Blue Jack)] [src: line] pcm2: pcm2: Master Volume (OSS: vol): -57/6dB pcm2: +- ctl 1 (nid 2 out): -57/6dB (128 steps) + mute pcm2: pcm2: PCM Volume (OSS: pcm): -57/6dB pcm2: +- ctl 1 (nid 2 out): -57/6dB (128 steps) + mute pcm2: pcm2: Line-in Volume (OSS: line): 0/30dB pcm2: +- ctl 4 (nid 5 in 0): -51/12dB (64 steps) + mute pcm2: +- ctl 6 (nid 12 out): 0/30dB (4 steps) pcm2: pcm2: Recording Level (OSS: rec): -51/12dB pcm2: +- ctl 4 (nid 5 in 0): -51/12dB (64 steps) + mute pcm2: +- ctl 6 (nid 12 out): 0/30dB (4 steps) pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Mixer "line": pcm2: Mixer "rec": pcm2: Playback channel set is: Front Left, Front Right, pcm2: Playback channel matrix is: 2.0 (disconnected) pcm2: Recording channel set is: Front Left, Front Right, pcm2: Recording channel matrix is: 2.0 (disconnected) pcm3: at nid 16 and 15 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000007 AC3 FLOAT32 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 8 pcm3: pcm3: nid=16 [pin: SPDIF-out (White Jack)] pcm3: + <- nid=8 [audio output] [src: pcm] pcm3: pcm3: Record: pcm3: Stream cap: 0x00000007 AC3 FLOAT32 PCM pcm3: PCM cap: 0x001e0570 16 20 24 32 bits, 32 44 48 96 192 KHz pcm3: ADC: 7 pcm3: pcm3: nid=7 [audio input] pcm3: + <- nid=15 [pin: SPDIF-in (White Jack)] [src: dig1] pcm3: pcm3: Mixer "vol" -> "none": child=0x00000010 pcm3: Mixer "pcm": parent="vol" pcm3: Soft PCM mixer ENABLED pcm3: Playback channel set is: Front Left, Front Right, pcm3: Playback channel matrix is: 2.0 (unknown) pcm3: Recording channel set is: Front Left, Front Right, pcm3: Recording channel matrix is: 2.0 (disconnected) random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found ahcich0: AHCI reset: device ready after 0ms ahcich1: AHCI reset... ahcich1: SATA connect time=100us status=00000133 ahcich1: AHCI reset: device found ahcich1: AHCI reset: device ready after 0ms uhub0: 2 ports with 2 removable, self powered (aprobe0:ahcich0:0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 00 40 00 00 00 00 05 00 (aprobe0:ahcich0:0:0:0): CAM status: ATA Status Error (aprobe0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (aprobe0:ahcich0:0:0:0): RES: 51 04 00 00 00 40 00 00 00 05 00 (aprobe0:ahcich0:0:0:0): Retrying command (aprobe0:ahcich0:0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 00 40 00 00 00 00 05 00 (aprobe0:ahcich0:0:0:0): CAM status: ATA Status Error (aprobe0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (aprobe0:ahcich0:0:0:0): RES: 51 04 00 00 00 40 00 00 00 05 00 (aprobe0:ahcich0:0:0:0): Error 5, Retries exhausted uhub2: 2 ports with 2 removable, self powered pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number 132609427ACE pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 pass1: ATA-9 SATA 3.x device pass1: Serial Number 0000000013040927EA4E pass1: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) pass1: Command Queueing enabled pass2 at ahciem0 bus 0 scbus2 target 0 lun 0 pass2: SEMB S-E-S 2.00 device ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: GEOM: new disk ada0 ada0: Serial Number 132609427ACE ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 915715MB (1875385008 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-9 SATA 3.x device ada1: Serial Number 0000000013040927EA4E ada1: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) ada1: Command Queueing enabled ada1: 244198MB (500118192 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 GEOM: ada0: enabling Boot Camp GEOM: new disk ada1 battery0: battery initialization start GEOM: diskid/DISK-132609427ACE: enabling Boot Camp Netvsc initializing... done! lapic2: CMCI unmasked lapic3: CMCI unmasked lapic5: CMCI unmasked lapic4: CMCI unmasked lapic7: CMCI unmasked lapic6: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #4 Launched! cpu4 AP: ID: 0x04000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #6 Launched! cpu6 AP: ID: 0x06000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #5 Launched! cpu5 AP: ID: 0x05000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #7 Launched! cpu7 AP: ID: 0x07000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 acpi_acad0: acline initialization start system power profile changed to 'economy' acpi_acad0: Off Line acpi_acad0: acline initialization done, tried 1 times ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 2 vector 48 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 3 vector 48 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 4 vector 48 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 5 vector 48 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 49 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 49 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 49 msi: Assigning MSI-X IRQ 260 to local APIC 4 vector 49 msi: Assigning MSI-X IRQ 261 to local APIC 5 vector 49 msi: Assigning MSI-X IRQ 262 to local APIC 6 vector 48 msi: Assigning MSI-X IRQ 263 to local APIC 7 vector 48 msi: Assigning MSI IRQ 264 to local APIC 6 vector 49 msi: Assigning MSI IRQ 265 to local APIC 7 vector 49 msi: Assigning MSI IRQ 267 to local APIC 1 vector 50 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1197305600 Hz quality 1000 Root mount waiting for: usbus3 usbus1 battery0: battery initialization done, tried 1 times uhub1: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 usbus1 uhub3: 8 ports with 8 removable, self powered ugen1.2: at usbus1 uhub4: on usbus1 uhub4: MTT enabled Root mount waiting for: usbus3 usbus1 uhub4: 4 ports with 2 removable, self powered ugen3.2: at usbus3 uhub5: on usbus3 uhub5: MTT enabled Root mount waiting for: usbus3 usbus1 ugen1.3: at usbus1 uhub6: on usbus1 uhub5: 3 ports with 2 removable, self powered uhub6: 3 ports with 0 removable, self powered ugen3.3: at usbus3 Root mount waiting for: usbus3 usbus1 ugen1.4: at usbus1 ukbd0: on usbus1 kbd: new array size 4 kbd1 at ukbd0 kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 Root mount waiting for: usbus3 usbus1 ugen1.5: at usbus1 ugen3.4: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0: Attached to scbus3 GEOM: new disk da0 pass3 at umass-sim0 bus 0 scbus3 target 0 lun 0 pass3: Removable Direct Access SCSI-6 device pass3: Serial Number 4C530006060403119302 pass3: 40.000MB/s transfers da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-6 device da0: Serial Number 4C530006060403119302 da0: 40.000MB/s transfers da0: 30532MB (62530624 512 byte sectors: 255H 63S/T 3892C) da0: quirks=0x2 da0: Delete methods: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL not supported. ugen1.6: at usbus1 ugen1.7: at usbus1 ukbd1: on usbus1 kbd2 at ukbd1 kbd2: ukbd1, generic (0), config:0x0, flags:0x3d0000 Root mount waiting for: usbus1 ugen1.8: at usbus1 Root mount waiting for: usbus1 ugen1.9: at usbus1 Trying to mount root from ufs:/dev/ada1p2 [rw]... start_init: trying /sbin/init Setting hostuuid: ff0a3492-0ab8-11e4-89e9-3c0754621342. Setting hostid: 0xe47ab155. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: /dev/ada1p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada1p2: clean, 34271889 free (45281 frags, 4278326 blocks, 0.1% fragmentation) Mounting local file systems:. Writing entropy file:. Setting hostname: andersbo-mac.local. wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: 00:22:b0:be:65:46 Starting wpa_supplicant. Starting dhclient. wlan0: no link ..... got link DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 ugen1.8: at usbus1 (disconnected) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 10.0.0.138 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 10.0.0.138 bound to 10.0.0.75 -- renewal in 43200 seconds. ugen1.8: at usbus1 Starting Network: lo0 bge0 ath0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 bge0: flags=8802 metric 0 mtu 1500 options=c019b ether 3c:07:54:62:13:42 nd6 options=29 media: Ethernet autoselect ath0: flags=8843 metric 0 mtu 2290 ether 00:22:b0:be:65:46 nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: associated Starting devd. Starting Network: bge0. bge0: flags=8802 metric 0 mtu 1500 options=c019b ether 3c:07:54:62:13:42 nd6 options=29 media: Ethernet autoselect uhid0: on usbus3 uhid1: on usbus1 Configuring keyboard: keymap. ums0: on usbus1 ums0: 3 buttons and [XY] coordinates ID=2 ums1: on usbus1 ums1: 3 buttons and [XY] coordinates ID=2 ubt0: on usbus1 Starting ums0 moused. Starting ums1 moused. WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() ugen1.4: at usbus1 (disconnected) ukbd0: at uhub6, port 1, addr 4 (disconnected) ugen1.5: at usbus1 (disconnected) ums0: at uhub6, port 2, addr 5 (disconnected) Configuring keyboard: keymap. moused not running? (check /var/run/moused.ums0.pid). Starting pflogd: pflog0: bpf attached Starting pflog. Jul 18 17:36:53 pflogd[679]: [priv]: msg PRIV_OPEN_LOG received /etc/rc: WARNING: /etc/pf.conf is not readable. add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/gcc47 /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/qt4 /usr/local/llvm33/lib 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files. Starting syslogd. No core dumps found. Starting casperd. Clearing /tmp (X related). Starting svnserve. Jul 18 17:36:53 andersbo-mac svnserve.bin: sql_select option missing Jul 18 17:36:53 andersbo-mac svnserve.bin: auxpropfunc error no mechanism available svnserve: Root path '/var/svn/repos' does not exist or is not a directory. /etc/rc: WARNING: failed to start svnserve Starting cupsd. /etc/rc: WARNING: /usr/local/etc/smb.conf is not readable. Updating motd:. Mounting late file systems:. Starting ntpd. Starting powerd. Starting mysql. /etc/rc: WARNING: /usr/local/www/proxy is not a directory. /etc/rc: WARNING: failed precmd routine for htcacheclean Starting default mousedmoused: unable to open /dev/psm0: No such file or directory . Starting dbus. Starting hald. Configuring syscons: keymap blanktime. Starting gdm. Starting ffserver. Starting avahi-daemon. Starting avahi-dnsconfd. Performing sanity check on sshd configuration. ffserver version 2.2.4 Copyright (c) 2000-2014 the FFmpeg developers built on Jul 15 2014 19:48:16 with FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 configuration: --enable-libaacplus --disable-indev=alsa --disable-outdev=alsa --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libass --disable-libcdio --disable-libcelt --disable-libfaac --disable-libfdk-aac --enable-ffserver --enable-fontconfig --enable-libfreetype --enable-frei0r --enable-gnutls --disable-libgsm --enable-iconv --disable-indev=jack --disable-libmp3lame --disable-libbluray --disable-libv4l2 --disable-indev=v4l2 --disable-outdev=v4l2 --disable-libmodplug --disable-openal --disable-indev=openal --enable-libopencv --enable-libopenjpeg --disable-libopus --disable-libpulse --disable-indev=pulse --disable-outdev=pulse --disable-librtmp --enable-libschroedinger --disable-libspeex --enable-libtheora --disable-vaapi --disable-vdpau --enable-libvorbis --disable-libvo-aacenc --disable-libvo-amrwbenc --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --prefix=/usr/local --mandir=/usr/local/man --datadir=/usr/local/share/ffmpeg --enable-shared --enable-gpl --enable-postproc --enable-avfilter --enable-avresample --enable-pthreads --enable-memalign-hack --disable-libstagefright-h264 --disable-libutvideo --disable-libsoxr --cc=cc --extra-cflags='-msse -I/usr/local/include/vorbis -I/usr/local/include' --extra-ldflags='-L/usr/local/lib ' --extra-libs=-pthread --disable-debug --disable-ffplay --disable-outdev=sdl --enable-nonfree Starting sshd. libavutil 52. 66.100 / 52. 66.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 33.100 / 55. 33.100 libavdevice 55. 10.100 / 55. 10.100 libavfilter 4. 2.100 / 4. 2.100 libavresample 1. 2. 0 / 1. 2. 0 libswscale 2. 5.102 / 2. 5.102 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Fri Jul 18 17:36:56 2014 FFserver started. Performing sanity check on apache24 configuration: httpd: Syntax error on line 154 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_dnssd.so into server: /usr/local/libexec/apache24/mod_dnssd.so: Undefined symbol "unixd_setup_child" Starting apache24. httpd: Syntax error on line 154 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_dnssd.so into server: /usr/local/libexec/apache24/mod_dnssd.so: Undefined symbol "unixd_setup_child" /etc/rc: WARNING: failed to start apache24 Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Starting inetd. Starting background file system checks in 60 seconds. Fri Jul 18 17:36:56 CEST 2014 info: [drm] Initialized drm 1.1.0 20060810 drmn1: on vgapci1 vgapci1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 268 to local APIC 2 vector 50 vgapci1: using IRQ 268 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xa0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0x0 iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0x0 iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0x0 iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0x0 iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0x0 iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0x0 iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0x0 iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off drmn1: taking over the fictitious range 0xa0000000-0xb0000000 fbd1 on drmn1 VT: Replacing driver "efifb" with new "fb". info: [drm] Initialized i915 1.6.0 20080730 info: [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync) error: [drm:pid0:intel_lvds_enable] *ERROR* timed out waiting for panel to power off drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 269 to local APIC 3 vector 50 vgapci0: using IRQ 269 for MSI info: [drm] MSI enabled 1 message(s) can't re-use a leaf (debug)! can't re-use a leaf (notyet)! can't re-use a leaf (vblank_offdelay)! can't re-use a leaf (timestamp_precision)! info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (TURKS 0x1002:0x6740 0x106B:0x00F9). info: [drm] register mmio base: 0xB0800000 info: [drm] register mmio size: 131072 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:0:2:0, vendor=8086, device=0126 info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_atrm_get_bios: Get ACPI handle for "ATRM" info: [drm] radeon_atrm_get_bios: Failed to get "ATRM" handle: AE_NOT_FOUND info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0x90000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff80090000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0xFFFD info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) info: [drm] radeon_read_bios: Incorrect BIOS signature: 0xFFFF info: [drm] ni_read_disabled_bios: ===> Try disabled BIOS (ni)... info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) info: [drm] radeon_read_bios: Incorrect BIOS signature: 0xFFFF error: [drm:pid1363:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM drmn0: error: Fatal error during GPU init info: [drm] radeon: finishing device. [TTM] Memory type 2 has not been initialized device_attach: drmn0 attach returned 22 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 269 to local APIC 4 vector 50 vgapci0: using IRQ 269 for MSI info: [drm] MSI enabled 1 message(s) can't re-use a leaf (debug)! can't re-use a leaf (notyet)! can't re-use a leaf (vblank_offdelay)! can't re-use a leaf (timestamp_precision)! info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (TURKS 0x1002:0x6740 0x106B:0x00F9). info: [drm] register mmio base: 0xB0800000 info: [drm] register mmio size: 131072 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:0:2:0, vendor=8086, device=0126 info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_atrm_get_bios: Get ACPI handle for "ATRM" info: [drm] radeon_atrm_get_bios: Failed to get "ATRM" handle: AE_NOT_FOUND info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0x90000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff80090000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0xFFFD info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) info: [drm] radeon_read_bios: Incorrect BIOS signature: 0xFFFF info: [drm] ni_read_disabled_bios: ===> Try disabled BIOS (ni)... info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) info: [drm] radeon_read_bios: Incorrect BIOS signature: 0xFFFF error: [drm:pid1363:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM drmn0: error: Fatal error during GPU init info: [drm] radeon: finishing device. [TTM] Memory type 2 has not been initialized device_attach: drmn0 attach returned 22 From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 17:41:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FAFE52E; Sun, 20 Jul 2014 17:41:44 +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 2552A2A20; Sun, 20 Jul 2014 17:41:44 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id f51so4671185qge.32 for ; Sun, 20 Jul 2014 10:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=5EfLr72leaFUWVVnmlnrdgolJC/XAVrKYN1/thLF+5Y=; b=AJyvi20Py8kyGyqOnVXTdC7a3gBImEqOFH1O8hwAAbSe+PBj+ec7W84aB7iN7f3/6x EcsJC4o8+juEy5AarHsX6hnnWnqWwUG+yaY2sWqgOIf2uJwGH7fJ8elHONZDYsPaC7lK akWriI21SxBGTxzyqG2IlWBe5HEULZgeghFJQzJZrBOSFxpwxj824pk3JruMtBZAWtrw 1Bk2qzMLIngCkjd7b7xJuQbDHWKYOmb++0taYWYlJkC/rVUZ/yA5CBRVaTajZ1gUz4m9 zOeS8sTd2vF9RRmHnYBrnmQ6+jRkucQd4nP4XlXbf0sw6Az49goFlDRqfurcQNdzW93c QUdg== X-Received: by 10.224.120.68 with SMTP id c4mr32978794qar.17.1405878100735; Sun, 20 Jul 2014 10:41:40 -0700 (PDT) Received: from kan ([2601:6:6780:780:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id w15sm5535761qay.34.2014.07.20.10.41.39 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 20 Jul 2014 10:41:39 -0700 (PDT) Date: Sun, 20 Jul 2014 13:41:33 -0400 From: Alexander Kabaev To: Maxim Khitrov Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140720134133.1d30f725@kan> In-Reply-To: References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/++vyFsvIt9zzPRWKWP8QWOz"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org, FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 17:41:44 -0000 --Sig_/++vyFsvIt9zzPRWKWP8QWOz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 20 Jul 2014 10:15:36 -0400 Maxim Khitrov wrote: > On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels > wrote: > > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: > >> all of that is true, but you are missing the point. Having two > >> versions of pf on the bsd's at the user level, is a bad thing. It > >> confuses people, which puts them off. Its a classic case of divide > >> an conquer for other platforms. I really like the idea of the > >> openpf version, that has been mentioned in this thread. It would > >> be awesome if it ended up as a supported linux thing as well, so > >> the world could be rid of iptables. However i guess thats just an > >> unrealistic dream > > > > And you don't seem to get the point that _someone_ has to do the > > work. No one has stepped up so far, so nothing is going to change. >=20 > Gleb believes that the majority of FreeBSD users don't want the > updated syntax, among other changes, from the more recent pf versions. > Developers who share his opinion are not going to volunteer to do the > work. This discussion is about showing this belief to be wrong, which > is the first step in the process. >=20 > In my opinion, the way forward is to forget (at least temporarily) the > SMP changes, bring pf in sync with OpenBSD, put a policy in place to > follow their releases as closely as possible, and then try to > reintroduce all the SMP work. I think the latter has to be done > upstream, otherwise it'll always be a story of diverging codebases. > Furthermore, if FreeBSD developers were willing to spend some time > improving pf performance on OpenBSD, then Henning and other OpenBSD > developers might be more receptive to changes that make the porting > process easier. I am one person whose opinion Gleb got completely right - I could not care less about new syntax nor about how close or how far are we from OpenBSD, as long as pf works for my purposes and it does. This far into the thread and somebody has yet to provide a comprehensive list of the benefits that we allegedly miss, or to come up with the real benchmark result to substantiate the performance claims. Focusing on disproving anything Gleb might be believing in on the matter, while an interesting undertaking, does nothing to give you new pf you supposedly want. Doing the work and bringing it all the way to will completeness for commit - does.=20 It was stated repeatedly by multiple people that FreeBSD's network stack is way too different from OpenBSD, we support features OpenBSD doesn't and vice versa, vimage is a good example, which throws a giant wrench into the plan of following OpenBSD 'as closely as possible', even as the expense of throwing away all of the SMP work done in pf to date. --=20 Alexander Kabaev --Sig_/++vyFsvIt9zzPRWKWP8QWOz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iD8DBQFTy/9SQ6z1jMm+XZYRAn0GAKDXvnHXIr64YIDshctzEfJSgV0k6gCeKgJy 7C0eBgBVqfRkkMiSxw4rP6U= =yly+ -----END PGP SIGNATURE----- --Sig_/++vyFsvIt9zzPRWKWP8QWOz-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 19:14:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6B24972; Sun, 20 Jul 2014 19:14:39 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c: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 0588A2246; Sun, 20 Jul 2014 19:14:38 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q58so6634039wes.21 for ; Sun, 20 Jul 2014 12:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=HPaFv6TI2Ejx9fCGNN9VufSCyTkdujnY7LDyoTLrqvU=; b=jr3zza6ALEFxztiX6lwZmPBOosizTep5ih9x95EVczdUSWRrgDlNuVHU3IEx3ASUk2 MoP073mJKwXGObuO4mWuQXkcUNiw5D3G98h5t/k+kkf89Dg2ZCZVQiMJ9TSAAXDbkNJW oHQgkEyPHD6s7LW03poT5o+5+89g6XTT/jGTJAR5zgGK7h6iPipGO4zOxuqRjXE7yxp7 apW4Eitt34XVDiDhiNsq8PT6F0OCtjxNbG5mrsgAhFSYxbD4nJFu4Is1kgNNe3qI+j3U w8i7AjFdjhWcpw2Zf/wWQ6W8Y83d/UK89qvzmil7+oO45jBVwLyRNoJdm54h7CHeYmUG swfA== X-Received: by 10.194.243.200 with SMTP id xa8mr15596419wjc.97.1405883677067; Sun, 20 Jul 2014 12:14:37 -0700 (PDT) Received: from srvbsdfenssv.interne.associated-bears.org (LCaen-151-92-21-48.w217-128.abo.wanadoo.fr. [217.128.200.48]) by mx.google.com with ESMTPSA id l8sm31759661wje.15.2014.07.20.12.14.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jul 2014 12:14:36 -0700 (PDT) Sender: Eric Masson Received: from srvbsdfenssv.interne.associated-bears.org (localhost [127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id AEB08CF4D3; Sun, 20 Jul 2014 21:14:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at interne.associated-bears.org Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (srvbsdfenssv.interne.associated-bears.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb0n0Jvaj4rc; Sun, 20 Jul 2014 21:14:32 +0200 (CEST) Received: by srvbsdfenssv.interne.associated-bears.org (Postfix, from userid 1001) id A1596CF129; Sun, 20 Jul 2014 21:14:32 +0200 (CEST) From: Eric Masson To: krad Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: (krad's message of "Sun, 20 Jul 2014 12:18:54 +0100") References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) X-Operating-System: FreeBSD 9.2-RELEASE-p8 amd64 Date: Sun, 20 Jul 2014 21:14:31 +0200 Message-ID: <86fvhvrgfc.fsf@srvbsdfenssv.interne.associated-bears.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, Stephen Hurd , Gleb Smirnoff , Gerrit =?iso-8859-1?Q?K=FChn?= , FreeBSD Mailing List , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:14:40 -0000 krad writes: Hi, > I really like the idea of the openpf version, that has been mentioned > in this thread. It would be nice but as it's been written in this thread, Open & Free internals are quite different beasts, goals are different on both platforms, so I doubt OpenPF will exist in the future. > It would be awesome if it ended up as a supported linux thing as well, > so the world could be rid of iptables. Linux world will get rid of iptables one of these days, nftables inclusion in mainline is a clear signal. I don't really like linux firewalling engines but projects like OpenWRT and Luci hide the command line hell in most cases, so I'm slowly retiring FreeBSD/pf handcrafted appliances in favor of OpenWRT boxes. Éric Masson -- Bonjour je sais qu il existe un prog pour faire des cartes bancaires puis je l avoir par mail pas pour en fabriquer mais par curiosite merci a tous -+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 19:19:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AF26C7E; Sun, 20 Jul 2014 19:19:03 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id CD712227D; Sun, 20 Jul 2014 19:19:02 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 1B26920E7088D; Sun, 20 Jul 2014 19:19:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 1CFC620E7088A; Sun, 20 Jul 2014 19:18:57 +0000 (UTC) Message-ID: <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> From: "Steven Hartland" To: "Larry Rosenman" , , References: <20140720140350.GA8498@borg.lerctr.org> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Sun, 20 Jul 2014 20:18:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:19:03 -0000 Can you provide the details of the zio which caused the panic? Also does any of your pools support trim? Regards Steve ----- Original Message ----- From: "Larry Rosenman" To: ; Sent: Sunday, July 20, 2014 3:03 PM Subject: [ZFS][PANIC] Solaris Assert/zio.c:2548 > Got the following panic overnight (I think while a nightly rsync was running): > > Dump header from device /dev/gpt/swap0 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 8122101760B (7745 MB) > Blocksize: 512 > Dumptime: Sun Jul 20 03:22:18 2014 > Hostname: borg.lerctr.org > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 11.0-CURRENT #50 r268894M: Sat Jul 19 18:06:08 CDT 2014 > root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER > Panic String: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 > Dump Parity: 763150733 > Bounds: 5 > Dump Status: good > > > borg.lerctr.org dumped core - see /var/crash/vmcore.5 > > Sun Jul 20 03:28:12 CDT 2014 > > FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #50 r268894M: Sat Jul 19 18:06:08 CDT 2014 > root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > > panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 > cpuid = 7 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c49f930 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c49f9e0 > vpanic() at vpanic+0x126/frame 0xfffffe100c49fa20 > panic() at panic+0x43/frame 0xfffffe100c49fa80 > assfail() at assfail+0x1d/frame 0xfffffe100c49fa90 > zio_vdev_io_assess() at zio_vdev_io_assess+0x2ed/frame 0xfffffe100c49fac0 > zio_execute() at zio_execute+0x1e9/frame 0xfffffe100c49fb20 > taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe100c49fb80 > taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe100c49fbb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe100c49fbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c49fbf0 > --- trap 0, rip = 0, rsp = 0xfffffe100c49fcb0, rbp = 0 --- > Uptime: 8h57m17s > (ada2:ahcich2:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 > (ada2:ahcich2:0:0:0): CAM status: Command timeout > (ada2:ahcich2:0:0:0): Error 5, Retries exhausted > (ada2:ahcich2:0:0:0): Synchronize cache failed > Dumping 7745 out of 64463 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. > Loaded symbols for /boot/kernel/if_lagg.ko.symbols > Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols > Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_spicds.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. > Loaded symbols for /boot/kernel/ichsmb.ko.symbols > Reading symbols from /boot/kernel/smbus.ko.symbols...done. > Loaded symbols for /boot/kernel/smbus.ko.symbols > Reading symbols from /boot/kernel/ichwd.ko.symbols...done. > Loaded symbols for /boot/kernel/ichwd.ko.symbols > Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. > Loaded symbols for /boot/kernel/cpuctl.ko.symbols > Reading symbols from /boot/kernel/crypto.ko.symbols...done. > Loaded symbols for /boot/kernel/crypto.ko.symbols > Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. > Loaded symbols for /boot/kernel/cryptodev.ko.symbols > Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. > Loaded symbols for /boot/kernel/dtraceall.ko.symbols > Reading symbols from /boot/kernel/profile.ko.symbols...done. > Loaded symbols for /boot/kernel/profile.ko.symbols > Reading symbols from /boot/kernel/cyclic.ko.symbols...done. > Loaded symbols for /boot/kernel/cyclic.ko.symbols > Reading symbols from /boot/kernel/dtrace.ko.symbols...done. > Loaded symbols for /boot/kernel/dtrace.ko.symbols > Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols > Reading symbols from /boot/kernel/systrace.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace.ko.symbols > Reading symbols from /boot/kernel/sdt.ko.symbols...done. > Loaded symbols for /boot/kernel/sdt.ko.symbols > Reading symbols from /boot/kernel/lockstat.ko.symbols...done. > Loaded symbols for /boot/kernel/lockstat.ko.symbols > Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. > Loaded symbols for /boot/kernel/fasttrap.ko.symbols > Reading symbols from /boot/kernel/fbt.ko.symbols...done. > Loaded symbols for /boot/kernel/fbt.ko.symbols > Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. > Loaded symbols for /boot/kernel/dtnfscl.ko.symbols > Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. > Loaded symbols for /boot/kernel/dtmalloc.ko.symbols > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > Reading symbols from /boot/kernel/ipmi.ko.symbols...done. > Loaded symbols for /boot/kernel/ipmi.ko.symbols > Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. > Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols > Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. > Loaded symbols for /boot/kernel/radeonkms.ko.symbols > Reading symbols from /boot/kernel/iicbb.ko.symbols...done. > Loaded symbols for /boot/kernel/iicbb.ko.symbols > Reading symbols from /boot/kernel/iicbus.ko.symbols...done. > Loaded symbols for /boot/kernel/iicbus.ko.symbols > Reading symbols from /boot/kernel/iic.ko.symbols...done. > Loaded symbols for /boot/kernel/iic.ko.symbols > Reading symbols from /boot/kernel/drm2.ko.symbols...done. > Loaded symbols for /boot/kernel/drm2.ko.symbols > Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. > Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > Loaded symbols for /boot/kernel/linprocfs.ko.symbols > Reading symbols from /boot/kernel/uhid.ko.symbols...done. > Loaded symbols for /boot/kernel/uhid.ko.symbols > Reading symbols from /boot/modules/vboxnetflt.ko...done. > Loaded symbols for /boot/modules/vboxnetflt.ko > Reading symbols from /boot/kernel/netgraph.ko.symbols...done. > Loaded symbols for /boot/kernel/netgraph.ko.symbols > Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. > Loaded symbols for /boot/kernel/ng_ether.ko.symbols > Reading symbols from /boot/modules/vboxnetadp.ko...done. > Loaded symbols for /boot/modules/vboxnetadp.ko > #0 doadump (textdump=1) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=1) at pcpu.h:219 > #1 0xffffffff80a055f7 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:445 > #2 0xffffffff80a05b35 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:744 > #3 0xffffffff80a05b83 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:673 > #4 0xffffffff8032d05d in assfail (a=, > f=, l=) > at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 > #5 0xffffffff8040ad6d in zio_vdev_io_assess (ziop=) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2874 > #6 0xffffffff80405dd9 in zio_execute (zio=0xfffff809e449b730) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1416 > #7 0xffffffff80a4de60 in taskqueue_run_locked (queue=0xfffff8002255e800) > at /usr/src/sys/kern/subr_taskqueue.c:356 > #8 0xffffffff80a4e8db in taskqueue_thread_loop (arg=) > at /usr/src/sys/kern/subr_taskqueue.c:623 > #9 0xffffffff809d3cc4 in fork_exit ( > callout=0xffffffff80a4e840 , > arg=0xfffff80022611470, frame=0xfffffe100c49fc00) > at /usr/src/sys/kern/kern_fork.c:977 > #10 0xffffffff80df5afe in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:605 > #11 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) > > > vmcore is available. > > I re-ran the rsync, and no panic. > > Ideas? > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 19:20:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57826E31; Sun, 20 Jul 2014 19:20:48 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26093229E; Sun, 20 Jul 2014 19:20:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=j+F8ia0fTQnOBTnG4StOjA8CP63GfrH5fyR/MZ123Lc=; b=Kvp29JuEuw8tBqnk5IX7UXxQ+KVUxh7+yr904Rw0zLgkG6OgdM1uFtedMuO/6JNZXCa8L2iE2glM+nHZCkR3Efhr8xEN74ih8HReExcuWmEg/rfFRb18ALfxX6R8wR+EBmSUt+GKj+afQwtRcCQUoiTITx4+oBPYDnHKojOCoOo=; Received: from localhost.lerctr.org ([127.0.0.1]:27329 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X8wf6-000Exd-AJ; Sun, 20 Jul 2014 14:20:46 -0500 Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 20 Jul 2014 14:20:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 20 Jul 2014 14:20:44 -0500 From: Larry Rosenman To: Steven Hartland Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 In-Reply-To: <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> Message-ID: <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:20:48 -0000 On 2014-07-20 14:18, Steven Hartland wrote: > Can you provide the details of the zio which caused the panic? > > Also does any of your pools support trim? No, on the trim. Can you walk me through getting the zio you need? > > Regards > Steve > > ----- Original Message ----- From: "Larry Rosenman" > To: ; > Sent: Sunday, July 20, 2014 3:03 PM > Subject: [ZFS][PANIC] Solaris Assert/zio.c:2548 > > >> Got the following panic overnight (I think while a nightly rsync was >> running): >> >> Dump header from device /dev/gpt/swap0 >> Architecture: amd64 >> Architecture Version: 2 >> Dump Length: 8122101760B (7745 MB) >> Blocksize: 512 >> Dumptime: Sun Jul 20 03:22:18 2014 >> Hostname: borg.lerctr.org >> Magic: FreeBSD Kernel Dump >> Version String: FreeBSD 11.0-CURRENT #50 r268894M: Sat Jul 19 >> 18:06:08 CDT 2014 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER >> Panic String: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), >> file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, >> line: 2874 >> Dump Parity: 763150733 >> Bounds: 5 >> Dump Status: good >> >> >> borg.lerctr.org dumped core - see /var/crash/vmcore.5 >> >> Sun Jul 20 03:28:12 CDT 2014 >> >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #50 >> r268894M: Sat Jul 19 18:06:08 CDT 2014 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >> >> panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: >> 2874 >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: >> 2874 >> cpuid = 7 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe100c49f930 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c49f9e0 >> vpanic() at vpanic+0x126/frame 0xfffffe100c49fa20 >> panic() at panic+0x43/frame 0xfffffe100c49fa80 >> assfail() at assfail+0x1d/frame 0xfffffe100c49fa90 >> zio_vdev_io_assess() at zio_vdev_io_assess+0x2ed/frame >> 0xfffffe100c49fac0 >> zio_execute() at zio_execute+0x1e9/frame 0xfffffe100c49fb20 >> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >> 0xfffffe100c49fb80 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame >> 0xfffffe100c49fbb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe100c49fbf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c49fbf0 >> --- trap 0, rip = 0, rsp = 0xfffffe100c49fcb0, rbp = 0 --- >> Uptime: 8h57m17s >> (ada2:ahcich2:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 >> 00 00 >> (ada2:ahcich2:0:0:0): CAM status: Command timeout >> (ada2:ahcich2:0:0:0): Error 5, Retries exhausted >> (ada2:ahcich2:0:0:0): Synchronize cache failed >> Dumping 7745 out of 64463 >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >> >> Reading symbols from /boot/kernel/linux.ko.symbols...done. >> Loaded symbols for /boot/kernel/linux.ko.symbols >> Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. >> Loaded symbols for /boot/kernel/if_lagg.ko.symbols >> Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. >> Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols >> Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. >> Loaded symbols for /boot/kernel/snd_spicds.ko.symbols >> Reading symbols from /boot/kernel/coretemp.ko.symbols...done. >> Loaded symbols for /boot/kernel/coretemp.ko.symbols >> Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. >> Loaded symbols for /boot/kernel/ichsmb.ko.symbols >> Reading symbols from /boot/kernel/smbus.ko.symbols...done. >> Loaded symbols for /boot/kernel/smbus.ko.symbols >> Reading symbols from /boot/kernel/ichwd.ko.symbols...done. >> Loaded symbols for /boot/kernel/ichwd.ko.symbols >> Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. >> Loaded symbols for /boot/kernel/cpuctl.ko.symbols >> Reading symbols from /boot/kernel/crypto.ko.symbols...done. >> Loaded symbols for /boot/kernel/crypto.ko.symbols >> Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. >> Loaded symbols for /boot/kernel/cryptodev.ko.symbols >> Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. >> Loaded symbols for /boot/kernel/dtraceall.ko.symbols >> Reading symbols from /boot/kernel/profile.ko.symbols...done. >> Loaded symbols for /boot/kernel/profile.ko.symbols >> Reading symbols from /boot/kernel/cyclic.ko.symbols...done. >> Loaded symbols for /boot/kernel/cyclic.ko.symbols >> Reading symbols from /boot/kernel/dtrace.ko.symbols...done. >> Loaded symbols for /boot/kernel/dtrace.ko.symbols >> Reading symbols from >> /boot/kernel/systrace_freebsd32.ko.symbols...done. >> Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols >> Reading symbols from /boot/kernel/systrace.ko.symbols...done. >> Loaded symbols for /boot/kernel/systrace.ko.symbols >> Reading symbols from /boot/kernel/sdt.ko.symbols...done. >> Loaded symbols for /boot/kernel/sdt.ko.symbols >> Reading symbols from /boot/kernel/lockstat.ko.symbols...done. >> Loaded symbols for /boot/kernel/lockstat.ko.symbols >> Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. >> Loaded symbols for /boot/kernel/fasttrap.ko.symbols >> Reading symbols from /boot/kernel/fbt.ko.symbols...done. >> Loaded symbols for /boot/kernel/fbt.ko.symbols >> Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. >> Loaded symbols for /boot/kernel/dtnfscl.ko.symbols >> Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. >> Loaded symbols for /boot/kernel/dtmalloc.ko.symbols >> Reading symbols from /boot/modules/vboxdrv.ko...done. >> Loaded symbols for /boot/modules/vboxdrv.ko >> Reading symbols from /boot/kernel/ipmi.ko.symbols...done. >> Loaded symbols for /boot/kernel/ipmi.ko.symbols >> Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. >> Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols >> Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. >> Loaded symbols for /boot/kernel/radeonkms.ko.symbols >> Reading symbols from /boot/kernel/iicbb.ko.symbols...done. >> Loaded symbols for /boot/kernel/iicbb.ko.symbols >> Reading symbols from /boot/kernel/iicbus.ko.symbols...done. >> Loaded symbols for /boot/kernel/iicbus.ko.symbols >> Reading symbols from /boot/kernel/iic.ko.symbols...done. >> Loaded symbols for /boot/kernel/iic.ko.symbols >> Reading symbols from /boot/kernel/drm2.ko.symbols...done. >> Loaded symbols for /boot/kernel/drm2.ko.symbols >> Reading symbols from >> /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. >> Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols >> Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. >> Loaded symbols for /boot/kernel/fdescfs.ko.symbols >> Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. >> Loaded symbols for /boot/kernel/linprocfs.ko.symbols >> Reading symbols from /boot/kernel/uhid.ko.symbols...done. >> Loaded symbols for /boot/kernel/uhid.ko.symbols >> Reading symbols from /boot/modules/vboxnetflt.ko...done. >> Loaded symbols for /boot/modules/vboxnetflt.ko >> Reading symbols from /boot/kernel/netgraph.ko.symbols...done. >> Loaded symbols for /boot/kernel/netgraph.ko.symbols >> Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. >> Loaded symbols for /boot/kernel/ng_ether.ko.symbols >> Reading symbols from /boot/modules/vboxnetadp.ko...done. >> Loaded symbols for /boot/modules/vboxnetadp.ko >> #0 doadump (textdump=1) at pcpu.h:219 >> 219 pcpu.h: No such file or directory. >> in pcpu.h >> (kgdb) #0 doadump (textdump=1) at pcpu.h:219 >> #1 0xffffffff80a055f7 in kern_reboot (howto=260) >> at /usr/src/sys/kern/kern_shutdown.c:445 >> #2 0xffffffff80a05b35 in vpanic (fmt=, >> ap=) at /usr/src/sys/kern/kern_shutdown.c:744 >> #3 0xffffffff80a05b83 in panic (fmt=0x0) >> at /usr/src/sys/kern/kern_shutdown.c:673 >> #4 0xffffffff8032d05d in assfail (a=, >> f=, l=) >> at >> /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 >> #5 0xffffffff8040ad6d in zio_vdev_io_assess (ziop=> out>) >> at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2874 >> #6 0xffffffff80405dd9 in zio_execute (zio=0xfffff809e449b730) >> at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1416 >> #7 0xffffffff80a4de60 in taskqueue_run_locked >> (queue=0xfffff8002255e800) >> at /usr/src/sys/kern/subr_taskqueue.c:356 >> #8 0xffffffff80a4e8db in taskqueue_thread_loop (arg=> out>) >> at /usr/src/sys/kern/subr_taskqueue.c:623 >> #9 0xffffffff809d3cc4 in fork_exit ( >> callout=0xffffffff80a4e840 , >> arg=0xfffff80022611470, frame=0xfffffe100c49fc00) >> at /usr/src/sys/kern/kern_fork.c:977 >> #10 0xffffffff80df5afe in fork_trampoline () >> at /usr/src/sys/amd64/amd64/exception.S:605 >> #11 0x0000000000000000 in ?? () >> Current language: auto; currently minimal >> (kgdb) >> >> >> vmcore is available. >> >> I re-ran the rsync, and no panic. >> >> Ideas? >> >> >> -- Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >> US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 19:25:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9C56262; Sun, 20 Jul 2014 19:25:38 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9BA2336; Sun, 20 Jul 2014 19:25:38 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id BD9A420E7088C; Sun, 20 Jul 2014 19:25:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id D58C420E7088A; Sun, 20 Jul 2014 19:25:33 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Larry Rosenman" References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Sun, 20 Jul 2014 20:25:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:25:38 -0000 Something like following should allow you to get the zio details assuming the compile has optimised it out: cd /var/crash kgdb /boot/kernel/kernel /var/crash/vmcore.5 kgdb> frame 5 kgdb> print zio Regards Steve ----- Original Message ----- From: "Larry Rosenman" To: "Steven Hartland" Cc: ; Sent: Sunday, July 20, 2014 8:20 PM Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 > On 2014-07-20 14:18, Steven Hartland wrote: >> Can you provide the details of the zio which caused the panic? >> >> Also does any of your pools support trim? > > No, on the trim. Can you walk me through getting the zio you need? From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 18:43:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3735CB7A; Sun, 20 Jul 2014 18:43:03 +0000 (UTC) Received: from mail2.nber.org (mail2.nber.org [198.71.6.79]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8DD2FA0; Sun, 20 Jul 2014 18:43:01 +0000 (UTC) Received: from nber7.nber.org (nber7.nber.org [198.71.6.41]) by mail2.nber.org (8.14.8/8.14.5) with ESMTP id s6KIZQtY029556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2014 14:35:26 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Sun, 20 Jul 2014 14:35:26 -0400 (EDT) From: Daniel Feenberg To: Lars Engels Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: <20140720123916.GV96250@e-new.0x20.net> Message-ID: References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> User-Agent: Alpine 2.11 (LRH 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20140401 #7726142, check: 20140720 clean X-Mailman-Approved-At: Sun, 20 Jul 2014 21:19:58 +0000 Cc: krad , Stephen Hurd , freebsd-current@freebsd.org, Gleb Smirnoff , =?ISO-8859-15?Q?Gerrit_K=FChn?= , FreeBSD Mailing List , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 18:43:03 -0000 On Sun, 20 Jul 2014, Lars Engels wrote: > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: >> all of that is true, but you are missing the point. Having two versions of >> pf on the bsd's at the user level, is a bad thing. It confuses people, >> which puts them off. Its a classic case of divide an conquer for other >> platforms. I really like the idea of the openpf version, that has been >> mentioned in this thread. It would be awesome if it ended up as a supported >> linux thing as well, so the world could be rid of iptables. However i guess >> thats just an unrealistic dream > > And you don't seem to get the point that _someone_ has to do the work. > No one has stepped up so far, so nothing is going to change. > No one with authority has yet said that "If an updated pf were available, would be welcomed". Rather they have said "An updated pf would not be suitable, as it would be incompatible with existing configuration files". If the latter is indeed the case, there is little incentive for anyone to go to the effort of porting the newer pf. After all, the reward for the work is chiefly in glory, and if there is to be no glory, the work is unlikely to be done. I do not have a horse in this race. Daniel Feenberg NBER From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 21:40:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40B81F50; Sun, 20 Jul 2014 21:40:58 +0000 (UTC) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "orthanc.ca CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F41782F2B; Sun, 20 Jul 2014 21:40:57 +0000 (UTC) Received: from [192.168.42.6] (d66-183-221-35.bchsia.telus.net [66.183.221.35]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s6KLegEY060584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2014 14:40:52 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_4B12DBBC-CA02-4A2A-B034-04B4192E48D3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Lyndon Nerenberg In-Reply-To: Date: Sun, 20 Jul 2014 14:40:37 -0700 Message-Id: References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> To: Daniel Feenberg X-Mailer: Apple Mail (2.1878.6) X-Spam-Status: No, score=0.4 required=5.0 tests=RDNS_DYNAMIC autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on orthanc.ca Cc: FreeBSD current , FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 21:40:58 -0000 --Apple-Mail=_4B12DBBC-CA02-4A2A-B034-04B4192E48D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 20, 2014, at 11:35 AM, Daniel Feenberg wrote: > Rather they have said "An updated pf would not be > suitable, as it would be incompatible with existing configuration = files". A major FreeBSD version increment is allowed to break that level of = backwards compatibility. Nothing prevents this from being incorporated = into 11.x. The only real concern would be removing existing core functionality as = part of the update. For that you want to provide at least one major = release cycle for people up migrate. Comparing pf on my current OpenBSD = machines vs. the FreeBSD 10.x pf, that doesn't seem to be an issue. --lyndon --Apple-Mail=_4B12DBBC-CA02-4A2A-B034-04B4192E48D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTzDdVAAoJEG8PnXiV/JnUP7wP/iaHgRf29cfR4bHHATs4HR8J WW2BSKp4/SyoA7oMYvOnN8QF/IA3x30NRI93VBtxwUZbFbEETvKtb/Y2/E0kZVB4 UcC8PyZ8lr+kQQY+1voAAp6dvI0Fm6KEojitYEuPo6GXSjyhYJcz+3TlfBjFZT8r qP6XQJD4gb3tXlfdO9Qzcvyvaa2YCCF9qp8SmeM4ynYhTr0G0geT2rKnegm8hvXw 2JglUiisAIregxf6gnabxKoPj0pNiWCnTkKJxWUeA45j4Gz123Q7fnd0YTUl3L3w tMQg+Dt0U3cq9+ACr0Hpw5rRjtgEnkXZdvgK8fCx88wdts0VRJUdkP9JX0bi5SpV X5Tr5EC8QalkWDsZRc/lWwL/xH21F/heifqbasgpVyzcIARxCKqZuMbQaMwICZd3 wGIlt5GV4kjdOGLeqFxM7A7m/qinmhDBVfi3yhqVfOdfCYuDF4fcQ6QhhI9YZm9R KmJsaejKguBFOTjQu3sVopmBlxXTvS8I+TV44ih1zKZ7kNX8zKJSAO2JYwxVi0jD ZIafvDBTNZOrtz6QGGJh0f1SmplfajapYYlg6wPXjqhdeRLzGZH0/EfBFdFofuKe 38DC4aoUkyO7reeLECL6U1HvCLoGUmLqIt+uQviaxIkcNTxUZjaBQ0Zjz+0SwC1d eETuZZRLPOQTsZW0Fb8s =Wq6E -----END PGP SIGNATURE----- --Apple-Mail=_4B12DBBC-CA02-4A2A-B034-04B4192E48D3-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 21:46:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C274C21E; Sun, 20 Jul 2014 21:46:29 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 78C5E2F6E; Sun, 20 Jul 2014 21:46:29 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X8yw9-000NXE-8d; Sun, 20 Jul 2014 23:46:29 +0200 Date: Sun, 20 Jul 2014 23:46:29 +0200 From: Kurt Jaeger To: Daniel Feenberg Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140720214629.GF197@home.opsec.eu> References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org, FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 21:46:29 -0000 Hi! > > And you don't seem to get the point that _someone_ has to do the work. > > No one has stepped up so far, so nothing is going to change. Franco Fichtner said he's interested in doing it. He probably needs funding. > No one with authority has yet said that "If an updated pf were available, > would be welcomed". Which person or group would you view as "authority" in this case ? -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 22:01:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2AD17C0; Sun, 20 Jul 2014 22:01:02 +0000 (UTC) Received: from mail101c7.megamailservers.com (mail731.megamailservers.com [69.49.98.41]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A101D209E; Sun, 20 Jul 2014 22:01:00 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from [192.168.0.33] (ip70-187-145-241.oc.oc.cox.net [70.187.145.241]) (authenticated bits=0) by mail101c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id s6KLfTfu028326; Sun, 20 Jul 2014 17:41:32 -0400 Message-ID: <53CC3789.8060902@sasktel.net> Date: Sun, 20 Jul 2014 14:41:29 -0700 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: krad Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> In-Reply-To: X-Enigmail-Version: 1.6.1_pre20140112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A02020A.53CC378C.011E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.1 cv=McNV5fPf c=1 sm=1 tr=0 a=qWhSLQ/2FgUpSQgLv9E1tw==:117 a=qWhSLQ/2FgUpSQgLv9E1tw==:17 a=kviXuzpPAAAA:8 a=BDKbP5mgAAAA:8 a=zNQZm9IoAq8A:10 a=cQ5pcHtl6RgA:10 a=YxfxW3ofkq8A:10 a=IkcTkHD0fZMA:10 a=uhPMnebkAAAA:8 a=ULDmNEh5usy-Y3qWiaUA:9 a=QEXdDO2ut3YA:10 Cc: FreeBSD Mailing List , =?UTF-8?B?R2Vycml0?= =?UTF-8?B?IEvDvGhu?= , freebsd-current@freebsd.org, Gleb Smirnoff , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:01:02 -0000 krad wrote: > all of that is true, but you are missing the point. Having two > versions of pf on the bsd's at the user level, is a bad thing. It > confuses people, which puts them off. Its a classic case of divide an > conquer for other platforms. I really like the idea of the openpf > version, that has been mentioned in this thread. It would be awesome > if it ended up as a supported linux thing as well, so the world could > be rid of iptables. However i guess thats just an unrealistic dream No, the point was that matching OpenBSDs pf syntax for the sake of the Google results isn't a valid reason to change it. I'm not saying there aren't any valid reasons, just that useless search results isn't one of them. As for my opinion of the rule format changing, I'm fine with it as long as it happens on a major version release (ie: 11.0) and is documented. If I want to use the old pf, I'll use an old FreeBSD. From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 22:30:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7800E54B; Sun, 20 Jul 2014 22:30:29 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 202042349; Sun, 20 Jul 2014 22:30:29 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id z60so4781416qgd.13 for ; Sun, 20 Jul 2014 15:30:27 -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=x/p1YSxT0p6R/MUN1QDy7merCrTa1TDx3hY9G4OuZ7g=; b=OtkpczV3826nRpeikjMd7CIj5v+6IkN8gjeI0wjVM2+WPHo0DmtjJCBUhdEInOlLgA Cz8vUHEGxnwRggUpSKIXxKrBypI3SR7ixFBETT96KXu6SwErAVNhTZe7atgQmBSMmfFA B4wkIvLsxd0JBlFW8YvST5QoqUWWA7GpduKwSlbGPkKW5rLJCLN94PndRFZVPfflIXrK pyFMiIvkzk9MOqGFPQVJWRUrnYZUSIdIYX8Wo4ZOQsM5fd7EjwXFlg/KuTWTKJPo/7Jr JcKiYqfy0OSAffY3dfAGc0ZB5Ui5eTO9IjLetVCmzSAAFWlAObOpikjk0DfCiR6UdanE SsHQ== MIME-Version: 1.0 X-Received: by 10.140.93.161 with SMTP id d30mr32070930qge.53.1405895427608; Sun, 20 Jul 2014 15:30:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 20 Jul 2014 15:30:27 -0700 (PDT) In-Reply-To: References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> <20140720214629.GF197@home.opsec.eu> Date: Sun, 20 Jul 2014 15:30:27 -0700 X-Google-Sender-Auth: q4dOmS9WWAphPWLQZu-qGK70R-s Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Adrian Chadd To: Daniel Feenberg Content-Type: text/plain; charset=UTF-8 Cc: Kurt Jaeger , FreeBSD Mailing List , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:30:29 -0000 Noone needs to say "you can do X." You can just fork freebsd in whatever form you want, update to the latest github and work to eventually get it included. Or you could treat it as an entirely external-from-system plugin module that you compile up - the packet filter hooks API lets you do this relatively nicely nowdays. There's multiple ways to do this. No-one needs to ask permission. Someone just has to do it. So if you want to do it, say so, and please feel free to canvas for donations / funding / whatever you need to keep up whatever you need to get it done. You don't need permission. Don't worry about how to get it into the tree when you're done. Just do it. -a On 20 July 2014 15:26, Daniel Feenberg wrote: > > > On Sun, 20 Jul 2014, Kurt Jaeger wrote: > >> Hi! >> >>>> And you don't seem to get the point that _someone_ has to do the work. >>>> No one has stepped up so far, so nothing is going to change. >> >> >> Franco Fichtner said he's interested in doing it. He probably >> needs funding. >> >>> No one with authority has yet said that "If an updated pf were available, >>> would be welcomed". >> >> >> Which person or group would you view as "authority" in this case ? >> > > I am not privy to the inner workings of the project, but surely a > decision of this importance would come to the attention of the > core team, who are listed at: > > http://www.freebsd.org/administration.html#t-core > > A port of OpenBSD PF may be quite impractical or undesirable- I have no > idea. However, if all potential contributions are viewed as criticism to be > refuted, it will damage the ability of the project to attract contributors. > Rather than telling a potential contributor that their efforts will never be > included in the official distribution it would be more supportive of the > project to say that a port of PF would be welcome as a port, but might have > difficulty displacing current offering. That doesn't promise anything, but > encourages involvement, if indeed involvement is desired. > > Daniel Feenberg > > >> -- >> pi@opsec.eu +49 171 3101372 6 years to >> go ! >> > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 23:21:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92FC2CC; Sun, 20 Jul 2014 23:21:44 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 55B4F285E; Sun, 20 Jul 2014 23:21:44 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 8DBB420E7088D; Sun, 20 Jul 2014 23:21:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,TO_EQ_FM_DIRECT_MX autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 063D220E7088A; Sun, 20 Jul 2014 23:21:37 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Steven Hartland" , "Larry Rosenman" References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Mon, 21 Jul 2014 00:21:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:21:44 -0000 Can you try reverting r265321 and see if you still see the same crash? Regards Steve From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 23:22:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA74A32C; Sun, 20 Jul 2014 23:22:58 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B98152876; Sun, 20 Jul 2014 23:22:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=ifuzjFA2nV/8eSTNn0SSPdd3dmGiTvffF34t/bziZb4=; b=IBkaZf1t3OsancoGorRVjvFyjFY7M3hyZQ7GxNnlfmJUF8B50LH1TSbY+hXSgKeUGeFhEW6HLFH5RCcPvlBVqigDXoVYJC12/F0+tXQpIrwmgrvwykHw9GcJFc8YDK786LlhTxj9MPvEehdgrg5c2shSJBiKKB4iZOEQMYXpNZk=; Received: from localhost.lerctr.org ([127.0.0.1]:41943 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X90RU-000ILb-AS; Sun, 20 Jul 2014 18:22:57 -0500 Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 20 Jul 2014 18:22:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 20 Jul 2014 18:22:56 -0500 From: Larry Rosenman To: Steven Hartland Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 In-Reply-To: References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> Message-ID: <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:22:59 -0000 On 2014-07-20 18:21, Steven Hartland wrote: > Can you try reverting r265321 and see if you still see the > same crash? > > Regards > Steve I'll do the revert, but it's been a ONE TIME hit. There was a followup to mine with a reproducible poudriere crash like mine. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 23:27:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D717515; Sun, 20 Jul 2014 23:27:31 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::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 0316628A9; Sun, 20 Jul 2014 23:27:30 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so6395493oag.13 for ; Sun, 20 Jul 2014 16:27:30 -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=uYl+FsumPs9QUu1rP8bkpanu3czI3AK6HVC/roYC9AY=; b=QE8FIpFcNE47riSHr7hA3BH8ZeDf42Sldjp0k848j2o2gWUWAb+RrpYBKY2vc37ym5 vlPWTv/HiPaZOD6/lABnZgySZzaYlUCLtyTl152WobY+fc/2S9AeluZfa7Tzsqky7w+0 r8yZWA85T55YUB0gc0k2rBhWjLm8DN05x9J4r4THx1s3C+E2fl5Ch9tdtE0oVAJesz1w 0CT5kzi0lHMxh8f4mmf13x2gu5wJhX5beY0dXoqx0JvFN8aP24Tewywdw8vmnbsRTQ5g 71ibH63INX7/1iDUDQmPbMTsbDJdwqTZPqSeEvRJtQ0fOpq6LCYdU4XaGII6vOVKsyVw XKdQ== MIME-Version: 1.0 X-Received: by 10.182.133.69 with SMTP id pa5mr32046504obb.2.1405898850177; Sun, 20 Jul 2014 16:27:30 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Sun, 20 Jul 2014 16:27:30 -0700 (PDT) In-Reply-To: <20140720134133.1d30f725@kan> References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> <20140720134133.1d30f725@kan> Date: Mon, 21 Jul 2014 01:27:30 +0200 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Andreas Nilsson To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Maxim Khitrov , Current FreeBSD , FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:27:31 -0000 On Sun, Jul 20, 2014 at 7:41 PM, Alexander Kabaev wrote: > On Sun, 20 Jul 2014 10:15:36 -0400 > Maxim Khitrov wrote: > > > On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels > > wrote: > > > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: > > >> all of that is true, but you are missing the point. Having two > > >> versions of pf on the bsd's at the user level, is a bad thing. It > > >> confuses people, which puts them off. Its a classic case of divide > > >> an conquer for other platforms. I really like the idea of the > > >> openpf version, that has been mentioned in this thread. It would > > >> be awesome if it ended up as a supported linux thing as well, so > > >> the world could be rid of iptables. However i guess thats just an > > >> unrealistic dream > > > > > > And you don't seem to get the point that _someone_ has to do the > > > work. No one has stepped up so far, so nothing is going to change. > > > > Gleb believes that the majority of FreeBSD users don't want the > > updated syntax, among other changes, from the more recent pf versions. > > Developers who share his opinion are not going to volunteer to do the > > work. This discussion is about showing this belief to be wrong, which > > is the first step in the process. > > > > In my opinion, the way forward is to forget (at least temporarily) the > > SMP changes, bring pf in sync with OpenBSD, put a policy in place to > > follow their releases as closely as possible, and then try to > > reintroduce all the SMP work. I think the latter has to be done > > upstream, otherwise it'll always be a story of diverging codebases. > > Furthermore, if FreeBSD developers were willing to spend some time > > improving pf performance on OpenBSD, then Henning and other OpenBSD > > developers might be more receptive to changes that make the porting > > process easier. > > I am one person whose opinion Gleb got completely right - I could not > care less about new syntax nor about how close or how far are we from > OpenBSD, as long as pf works for my purposes and it does. This far > into the thread and somebody has yet to provide a comprehensive list of > the benefits that we allegedly miss, or to come up with the real > benchmark result to substantiate the performance claims. > > Focusing on disproving anything Gleb might be believing in on the > matter, while an interesting undertaking, does nothing to give you new > pf you supposedly want. Doing the work and bringing it all the way to > will completeness for commit - does. > > It was stated repeatedly by multiple people that FreeBSD's network > stack is way too different from OpenBSD, we support features > OpenBSD doesn't and vice versa, vimage is a good example, which throws a > giant wrench into the plan of following OpenBSD 'as closely as > possible', even as the expense of throwing away all of the SMP work > done in pf to date. > I like vimage, don't get me wrong, but it also seems to have lost traction. If vimage is the only thing holding a pf import back there ought to be some discussion about which is a priority. Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. /A From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 23:46:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E70FC95; Sun, 20 Jul 2014 23:46:17 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 40BA52A4B; Sun, 20 Jul 2014 23:46:17 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 9724D20E7088C; Sun, 20 Jul 2014 23:46:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id AA41E20E7088A; Sun, 20 Jul 2014 23:46:12 +0000 (UTC) Message-ID: <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> From: "Steven Hartland" To: "Larry Rosenman" , "Florian Smeets" References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Mon, 21 Jul 2014 00:46:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:46:17 -0000 ----- Original Message ----- From: "Larry Rosenman" To: "Steven Hartland" Cc: ; Sent: Monday, July 21, 2014 12:22 AM Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 > On 2014-07-20 18:21, Steven Hartland wrote: >> Can you try reverting r265321 and see if you still see the >> same crash? >> >> Regards >> Steve > I'll do the revert, but it's been a ONE TIME hit. > > There was a followup to mine with a reproducible poudriere crash like > mine. If you don't have a reproducable senario I'd hold off. Florian, is yours reproducable and can you send me a pretty print of the crashing zio? Regards Steve From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 23:57:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDDF5EC6; Sun, 20 Jul 2014 23:57:03 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB4E92B0B; Sun, 20 Jul 2014 23:57:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=mkvfKueoyVuyV3ppJLNRUPazFMEvYSDzpNXr6zgICds=; b=j7KyO3CBDfasQsSxW27gNDWw7gDngfDqD5pwc0DP9miD2jiPzSYy+Tx1Ns8KV+OoK4zx8f3LnlrDQpkKIBxU8scWD8AgZEO0Ap32Od2MIceXSvkOwxvdOASDsdsPWF5B/eGgaMTha06fGQOgZad70FL0CP8+m+EI6E3nHbWY6AY=; Received: from localhost.lerctr.org ([127.0.0.1]:47982 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X90yP-000IoD-Iv; Sun, 20 Jul 2014 18:56:58 -0500 Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 20 Jul 2014 18:56:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 20 Jul 2014 18:56:57 -0500 From: Larry Rosenman To: Steven Hartland Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 In-Reply-To: <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> Message-ID: <4992c5f5097b32dfd1dfbe7cd573cfa0@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:57:04 -0000 On 2014-07-20 18:46, Steven Hartland wrote: > ----- Original Message ----- From: "Larry Rosenman" > To: "Steven Hartland" > Cc: ; > Sent: Monday, July 21, 2014 12:22 AM > Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 > > >> On 2014-07-20 18:21, Steven Hartland wrote: >>> Can you try reverting r265321 and see if you still see the >>> same crash? >>> >>> Regards >>> Steve >> I'll do the revert, but it's been a ONE TIME hit. >> >> There was a followup to mine with a reproducible poudriere crash like >> mine. > > If you don't have a reproducable senario I'd hold off. > > Florian, is yours reproducable and can you send me > a pretty print of the crashing zio? > > Regards > Steve running on the reverted kernel. We'll see if it stays up, crashes or what. Haven't seen the crash again regardless. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 23:57:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A34AC2; Sun, 20 Jul 2014 23:57:46 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 164FC2B1A; Sun, 20 Jul 2014 23:57:46 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 75B5420E7088D; Sun, 20 Jul 2014 23:57:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 511C020E7088A; Sun, 20 Jul 2014 23:57:41 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Dan Mack" References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Mon, 21 Jul 2014 00:57:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:57:46 -0000 ----- Original Message ----- From: "Dan Mack" > I think I may have hit the same problem; I'm going to stay connected > to the console and see if it happens again; this is what I see > currently with the back-trace: > > db> bt > Tracing pid 0 tid 100070 td 0xfffff8000e088920 > kdb_enter() at kdb_enter+0x3e/frame 0xfffffe085ef1d980 > vpanic() at vpanic+0x146/frame 0xfffffe085ef1d9c0 > panic() at panic+0x43/frame 0xfffffe085ef1da20 > deadlkres() at deadlkres+0x35c/frame 0xfffffe085ef1da70 > fork_exit() at fork_exit+0x84/frame 0xfffffe085ef1dab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe085ef1dab0 > --- trap 0, rip = 0, rsp = 0xfffffe085ef1db70, rbp = 0 --- > > I just updated to I think 268921 earlier today and this is the first > time I've had a panic (HEAD-268921 that is) > > I'll try to get some more data if I can get it back up and running. That doesn't look like a related trace tbh. Regards Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 00:01:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 328D23A4; Mon, 21 Jul 2014 00:01:47 +0000 (UTC) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) by mx1.freebsd.org (Postfix) with ESMTP id 0A22C2BCF; Mon, 21 Jul 2014 00:01:46 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) by borg.macktronics.com (Postfix) with ESMTP id 1D0D613C; Sun, 20 Jul 2014 18:53:18 -0500 (CDT) Date: Sun, 20 Jul 2014 18:53:18 -0500 (CDT) From: Dan Mack To: Steven Hartland Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 In-Reply-To: <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> Message-ID: References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> 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-fs@freebsd.org, freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:01:47 -0000 On Mon, 21 Jul 2014, Steven Hartland wrote: > ----- Original Message ----- From: "Larry Rosenman" > To: "Steven Hartland" > Cc: ; > Sent: Monday, July 21, 2014 12:22 AM > Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 > > >> On 2014-07-20 18:21, Steven Hartland wrote: >>> Can you try reverting r265321 and see if you still see the >>> same crash? >>> >>> Regards >>> Steve >> I'll do the revert, but it's been a ONE TIME hit. >> >> There was a followup to mine with a reproducible poudriere crash like mine. > > If you don't have a reproducable senario I'd hold off. > > Florian, is yours reproducable and can you send me > a pretty print of the crashing zio? > > Regards > Steve I think I may have hit the same problem; I'm going to stay connected to the console and see if it happens again; this is what I see currently with the back-trace: db> bt Tracing pid 0 tid 100070 td 0xfffff8000e088920 kdb_enter() at kdb_enter+0x3e/frame 0xfffffe085ef1d980 vpanic() at vpanic+0x146/frame 0xfffffe085ef1d9c0 panic() at panic+0x43/frame 0xfffffe085ef1da20 deadlkres() at deadlkres+0x35c/frame 0xfffffe085ef1da70 fork_exit() at fork_exit+0x84/frame 0xfffffe085ef1dab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe085ef1dab0 --- trap 0, rip = 0, rsp = 0xfffffe085ef1db70, rbp = 0 --- I just updated to I think 268921 earlier today and this is the first time I've had a panic (HEAD-268921 that is) I'll try to get some more data if I can get it back up and running. dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 00:12:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08B8660F; Mon, 21 Jul 2014 00:12:36 +0000 (UTC) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) by mx1.freebsd.org (Postfix) with ESMTP id D2FB42C8F; Mon, 21 Jul 2014 00:12:35 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) by borg.macktronics.com (Postfix) with ESMTP id 343DB145; Sun, 20 Jul 2014 19:12:35 -0500 (CDT) Date: Sun, 20 Jul 2014 19:12:35 -0500 (CDT) From: Dan Mack To: Steven Hartland Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 In-Reply-To: Message-ID: References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> 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-fs@freebsd.org, freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:12:36 -0000 On Mon, 21 Jul 2014, Steven Hartland wrote: > > ----- Original Message ----- From: "Dan Mack" > >> I think I may have hit the same problem; I'm going to stay connected >> to the console and see if it happens again; this is what I see >> currently with the back-trace: >> >> db> bt >> Tracing pid 0 tid 100070 td 0xfffff8000e088920 >> kdb_enter() at kdb_enter+0x3e/frame 0xfffffe085ef1d980 >> vpanic() at vpanic+0x146/frame 0xfffffe085ef1d9c0 >> panic() at panic+0x43/frame 0xfffffe085ef1da20 >> deadlkres() at deadlkres+0x35c/frame 0xfffffe085ef1da70 >> fork_exit() at fork_exit+0x84/frame 0xfffffe085ef1dab0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe085ef1dab0 >> --- trap 0, rip = 0, rsp = 0xfffffe085ef1db70, rbp = 0 --- >> >> I just updated to I think 268921 earlier today and this is the first >> time I've had a panic (HEAD-268921 that is) >> >> I'll try to get some more data if I can get it back up and running. > > That doesn't look like a related trace tbh. > > Regards > Steve Awesome, something else perhaps :-) Thanks, dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 01:29:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DC832D8; Mon, 21 Jul 2014 01:29:33 +0000 (UTC) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2370921D4; Mon, 21 Jul 2014 01:29:32 +0000 (UTC) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) by borg.macktronics.com (Postfix) with ESMTP id 65747149; Sun, 20 Jul 2014 20:29:31 -0500 (CDT) Date: Sun, 20 Jul 2014 20:29:31 -0500 (CDT) From: Dan Mack To: Steven Hartland Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 In-Reply-To: Message-ID: References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> 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-fs@freebsd.org, freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:29:33 -0000 On Mon, 21 Jul 2014, Steven Hartland wrote: >> I just updated to I think 268921 earlier today and this is the first >> time I've had a panic (HEAD-268921 that is) >> >> I'll try to get some more data if I can get it back up and running. > > That doesn't look like a related trace tbh. > > Regards > Steve After rebooting with a dumpdev; I got this : kbd2 at ukbd0 Trying to mount root from zfs:tank []... panic: deadlkres: possible deadlock detected for 0xfffff8000e089000, blocked for 1801216 ticks cpuid = 6 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085ef1d8d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe085ef1d980 vpanic() at vpanic+0x126/frame 0xfffffe085ef1d9c0 panic() at panic+0x43/frame 0xfffffe085ef1da20 deadlkres() at deadlkres+0x35c/frame 0xfffffe085ef1da70 fork_exit() at fork_exit+0x84/frame 0xfffffe085ef1dab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe085ef1dab0 --- trap 0, rip = 0, rsp = 0xfffffe085ef1db70, rbp = 0 --- KDB: enter: panic [ thread pid 0 tid 100070 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why I cannot seem to get past this yet so I'm open to suggestions. I'm still at the db> prompt if you'd like me to attempt to collect more info. dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 22:26:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAB4641C; Sun, 20 Jul 2014 22:26:07 +0000 (UTC) Received: from mail2.nber.org (mail2.nber.org [198.71.6.79]) by mx1.freebsd.org (Postfix) with ESMTP id 50A0A2308; Sun, 20 Jul 2014 22:26:06 +0000 (UTC) Received: from sas1.nber.org (sas1.nber.org [198.71.6.185]) by mail2.nber.org (8.14.8/8.14.5) with ESMTP id s6KMQ4tX000221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2014 18:26:04 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Sun, 20 Jul 2014 18:26:04 -0400 (EDT) From: Daniel Feenberg To: Kurt Jaeger Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: <20140720214629.GF197@home.opsec.eu> Message-ID: References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> <20140720214629.GF197@home.opsec.eu> User-Agent: Alpine 2.11 (LRH 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20140401 #7726142, check: 20140720 clean X-Mailman-Approved-At: Mon, 21 Jul 2014 02:03:59 +0000 Cc: freebsd-current@freebsd.org, FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:26:07 -0000 On Sun, 20 Jul 2014, Kurt Jaeger wrote: > Hi! > >>> And you don't seem to get the point that _someone_ has to do the work. >>> No one has stepped up so far, so nothing is going to change. > > Franco Fichtner said he's interested in doing it. He probably > needs funding. > >> No one with authority has yet said that "If an updated pf were available, >> would be welcomed". > > Which person or group would you view as "authority" in this case ? > I am not privy to the inner workings of the project, but surely a decision of this importance would come to the attention of the core team, who are listed at: http://www.freebsd.org/administration.html#t-core A port of OpenBSD PF may be quite impractical or undesirable- I have no idea. However, if all potential contributions are viewed as criticism to be refuted, it will damage the ability of the project to attract contributors. Rather than telling a potential contributor that their efforts will never be included in the official distribution it would be more supportive of the project to say that a port of PF would be welcome as a port, but might have difficulty displacing current offering. That doesn't promise anything, but encourages involvement, if indeed involvement is desired. Daniel Feenberg > -- > pi@opsec.eu +49 171 3101372 6 years to go ! > From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 02:49:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B89412B9; Mon, 21 Jul 2014 02:49:59 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 78B1C286C; Mon, 21 Jul 2014 02:49:59 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id D99AE20E7088D; Mon, 21 Jul 2014 02:49:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id AB18B20E7088A; Mon, 21 Jul 2014 02:49:46 +0000 (UTC) Message-ID: <7A0E2BBBB44F4977B847749706605223@multiplay.co.uk> From: "Steven Hartland" To: "Dan Mack" References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Mon, 21 Jul 2014 03:49:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 02:49:59 -0000 ----- Original Message ----- From: "Dan Mack" To: "Steven Hartland" Cc: ; ; "Larry Rosenman" Sent: Monday, July 21, 2014 2:29 AM Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 > On Mon, 21 Jul 2014, Steven Hartland wrote: > >>> I just updated to I think 268921 earlier today and this is the first >>> time I've had a panic (HEAD-268921 that is) >>> >>> I'll try to get some more data if I can get it back up and running. >> >> That doesn't look like a related trace tbh. >> >> Regards >> Steve > > After rebooting with a dumpdev; I got this : > > kbd2 at ukbd0 > Trying to mount root from zfs:tank []... > panic: deadlkres: possible deadlock detected for 0xfffff8000e089000, blocked for 1801216 ticks > > cpuid = 6 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085ef1d8d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe085ef1d980 > vpanic() at vpanic+0x126/frame 0xfffffe085ef1d9c0 > panic() at panic+0x43/frame 0xfffffe085ef1da20 > deadlkres() at deadlkres+0x35c/frame 0xfffffe085ef1da70 > fork_exit() at fork_exit+0x84/frame 0xfffffe085ef1dab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe085ef1dab0 > --- trap 0, rip = 0, rsp = 0xfffffe085ef1db70, rbp = 0 --- > KDB: enter: panic > [ thread pid 0 tid 100070 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > I cannot seem to get past this yet so I'm open to suggestions. I'm > still at the db> prompt if you'd like me to attempt to collect more > info. For some reason the deadlock detector is triggering, not sure why. I'd recommend starting a new thread to discuss this as it doesn't appear to be related to this thread. The only thing I could suggest is disabling it to see if it truely is a deadlock or if something is being really slow. vfs.zfs.deadman_enabled=0 If this is new then it would be good for you to try and identify which of the changes introduced it, so do a binary chop on versions back to your last known good. Regards Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 02:55:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F66F492; Mon, 21 Jul 2014 02:55:03 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id AE05D2916; Mon, 21 Jul 2014 02:55:02 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id F3F8A20E7088C; Mon, 21 Jul 2014 02:55:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 4849C20E7088A; Mon, 21 Jul 2014 02:54:57 +0000 (UTC) Message-ID: <24B81F5E7779408AAA0F2D6CA3B16CED@multiplay.co.uk> From: "Steven Hartland" To: "Dan Mack" References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Mon, 21 Jul 2014 03:54:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 02:55:03 -0000 ----- Original Message ----- From: "Dan Mack" To: "Steven Hartland" Cc: ; ; "Larry Rosenman" Sent: Monday, July 21, 2014 2:29 AM Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 > On Mon, 21 Jul 2014, Steven Hartland wrote: > >>> I just updated to I think 268921 earlier today and this is the first >>> time I've had a panic (HEAD-268921 that is) >>> >>> I'll try to get some more data if I can get it back up and running. >> >> That doesn't look like a related trace tbh. >> >> Regards >> Steve > > After rebooting with a dumpdev; I got this : > > kbd2 at ukbd0 > Trying to mount root from zfs:tank []... > panic: deadlkres: possible deadlock detected for 0xfffff8000e089000, blocked for 1801216 ticks > > cpuid = 6 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085ef1d8d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe085ef1d980 > vpanic() at vpanic+0x126/frame 0xfffffe085ef1d9c0 > panic() at panic+0x43/frame 0xfffffe085ef1da20 > deadlkres() at deadlkres+0x35c/frame 0xfffffe085ef1da70 > fork_exit() at fork_exit+0x84/frame 0xfffffe085ef1dab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe085ef1dab0 > --- trap 0, rip = 0, rsp = 0xfffffe085ef1db70, rbp = 0 --- > KDB: enter: panic > [ thread pid 0 tid 100070 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > I cannot seem to get past this yet so I'm open to suggestions. I'm > still at the db> prompt if you'd like me to attempt to collect more > info. Just spotted an interesting message on a recent commit which may be relavent: > URL: http://svnweb.freebsd.org/changeset/base/268855 > This specific commit makes boot hang just before mounting the root > dataset for me when vfs.zfs.vdev.cache.size tunable is set. Unsetting > this tunable or reverting this commit (currently running r268933 minus > r268855) fixes the boot for me. > > Please let me know if I can provide any more information. > > - Nikolai Lifanov The current code disables vdev caching by default so this will only occur if manually enabled. The code details the reason for this as:- * TODO: Note that with the current ZFS code, it turns out that the * vdev cache is not helpful, and in some cases actually harmful. It * is better if we disable this. Once some time has passed, we should * actually remove this to simplify the code. For now we just disable * it by setting the zfs_vdev_cache_size to zero. Note that Solaris 11 * has made these same changes. Regards Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 03:16:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EC49A79; Mon, 21 Jul 2014 03:16:29 +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 3F5912BAF; Mon, 21 Jul 2014 03:16:28 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-250-191.lns20.per2.internode.on.net [121.45.250.191]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s6L3Fq9r086717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2014 20:15:56 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53CC85E2.1030606@freebsd.org> Date: Mon, 21 Jul 2014 11:15:46 +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: Darren Pilgrim , Franco Fichtner , "Kristian K. Nielsen" Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> In-Reply-To: <53CB4736.90809@bluerosetech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:16:29 -0000 On 7/20/14, 12:36 PM, Darren Pilgrim wrote: > > > The vast majority of people don't know pf is outdated and broken on > FreeBSD because they don't know what they're missing and likely > aren't using IPv6 yet. s/IPv6/pf/ Most people I talk to just use ipfw and couldn't care whether pf lives or dies. They have simple requirements and almost any filter would suffice. I haven't found anything I'd want to use pf for that ipfw doesn't allow me to do. There are things pf does that ipfw doesn't... I just never want them.. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 03:24:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74878CDD; Mon, 21 Jul 2014 03:24:13 +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 3F2622C72; Mon, 21 Jul 2014 03:24:12 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-250-191.lns20.per2.internode.on.net [121.45.250.191]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s6L3O83U086773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2014 20:24:10 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53CC87D2.1000601@freebsd.org> Date: Mon, 21 Jul 2014 11:24:02 +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: Andreas Nilsson , Alexander Kabaev Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> <20140720134133.1d30f725@kan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Khitrov , Current FreeBSD , FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:24:13 -0000 On 7/21/14, 7:27 AM, Andreas Nilsson wrote: > On Sun, Jul 20, 2014 at 7:41 PM, Alexander Kabaev wrote: > >> On Sun, 20 Jul 2014 10:15:36 -0400 >> Maxim Khitrov wrote: >> >>> On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels >>> wrote: >>>> On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: >>>>> all of that is true, but you are missing the point. Having two >>>>> versions of pf on the bsd's at the user level, is a bad thing. It >>>>> confuses people, which puts them off. Its a classic case of divide >>>>> an conquer for other platforms. I really like the idea of the >>>>> openpf version, that has been mentioned in this thread. It would >>>>> be awesome if it ended up as a supported linux thing as well, so >>>>> the world could be rid of iptables. However i guess thats just an >>>>> unrealistic dream >>>> And you don't seem to get the point that _someone_ has to do the >>>> work. No one has stepped up so far, so nothing is going to change. >>> Gleb believes that the majority of FreeBSD users don't want the >>> updated syntax, among other changes, from the more recent pf versions. >>> Developers who share his opinion are not going to volunteer to do the >>> work. This discussion is about showing this belief to be wrong, which >>> is the first step in the process. >>> >>> In my opinion, the way forward is to forget (at least temporarily) the >>> SMP changes, bring pf in sync with OpenBSD, put a policy in place to >>> follow their releases as closely as possible, and then try to >>> reintroduce all the SMP work. I think the latter has to be done >>> upstream, otherwise it'll always be a story of diverging codebases. >>> Furthermore, if FreeBSD developers were willing to spend some time >>> improving pf performance on OpenBSD, then Henning and other OpenBSD >>> developers might be more receptive to changes that make the porting >>> process easier. >> I am one person whose opinion Gleb got completely right - I could not >> care less about new syntax nor about how close or how far are we from >> OpenBSD, as long as pf works for my purposes and it does. This far >> into the thread and somebody has yet to provide a comprehensive list of >> the benefits that we allegedly miss, or to come up with the real >> benchmark result to substantiate the performance claims. >> >> Focusing on disproving anything Gleb might be believing in on the >> matter, while an interesting undertaking, does nothing to give you new >> pf you supposedly want. Doing the work and bringing it all the way to >> will completeness for commit - does. >> >> It was stated repeatedly by multiple people that FreeBSD's network >> stack is way too different from OpenBSD, we support features >> OpenBSD doesn't and vice versa, vimage is a good example, which throws a >> giant wrench into the plan of following OpenBSD 'as closely as >> possible', even as the expense of throwing away all of the SMP work >> done in pf to date. >> > I like vimage, don't get me wrong, but it also seems to have lost traction. > If vimage is the only thing holding a pf import back there ought to be some > discussion about which is a priority. As one involved with Vimage, I get feedback all the time that lets me know it's in really heavy use in some pretty interesting commercial situations. It HAS lst some traction in terms of added work, but that's because it's solid enough for people to use. In the situations where it's being used, it's a game changer and rhe conversation goes something like: "hey vimage and pf don't work together.. guess that makes the firewall decision easy.. use ipfw" > > Also, the openbsd stack has some essential features missing in freebsd, > like mpls and md5 auth for bgp sessions. > > /A > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 05:24:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5C141A5; Mon, 21 Jul 2014 05:24:34 +0000 (UTC) Received: from mail-out.smeets.im (mail-out.smeets.im [IPv6:2a01:4f8:160:918a::25:11]) (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 7E1732546; Mon, 21 Jul 2014 05:24:34 +0000 (UTC) Received: from mail.smeets.im (mail.smeets.im [IPv6:2a01:4f8:160:918a::25:3]) by mail-out.smeets.im (Postfix) with ESMTP id 3C74918B; Mon, 21 Jul 2014 07:24:32 +0200 (CEST) Received: from amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) by mail.smeets.im (Postfix) with ESMTP id B9C0D892BD; Mon, 21 Jul 2014 07:24:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.im Received: from mail.smeets.im ([IPv6:2a01:4f8:160:918a::25:3]) by amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) (amavisd-new, port 10025) with ESMTP id KmrFO1qGupFZ; Mon, 21 Jul 2014 07:24:31 +0200 (CEST) Received: from nibbler-osx.local (unknown [IPv6:2001:4dd0:fd65:d00d:fdfe:c788:e9be:e820]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smeets.im (Postfix) with ESMTPSA id C5FD7892A7; Mon, 21 Jul 2014 07:24:30 +0200 (CEST) Message-ID: <53CCA40B.10503@smeets.im> Date: Mon, 21 Jul 2014 07:24:27 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Hartland , Larry Rosenman Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> In-Reply-To: <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rp9sFLx0TfVQoplMJscgoqQj9Iqaw3u1w" Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 05:24:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rp9sFLx0TfVQoplMJscgoqQj9Iqaw3u1w Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21/07/14 01:46, Steven Hartland wrote: > ----- Original Message ----- From: "Larry Rosenman" > To: "Steven Hartland" > Cc: ; > Sent: Monday, July 21, 2014 12:22 AM > Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 >=20 >=20 >> On 2014-07-20 18:21, Steven Hartland wrote: >>> Can you try reverting r265321 and see if you still see the >>> same crash? >>> >>> Regards >>> Steve >> I'll do the revert, but it's been a ONE TIME hit. >> >> There was a followup to mine with a reproducible poudriere crash like >> mine. >=20 > If you don't have a reproducable senario I'd hold off. >=20 > Florian, is yours reproducable and can you send me > a pretty print of the crashing zio? >=20 My backtrace looks a little different. panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zio.c, line: 2874 cpuid =3D 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00002e97f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00002e98a0 vpanic() at vpanic+0x126/frame 0xfffffe00002e98e0 panic() at panic+0x43/frame 0xfffffe00002e9940 assfail() at assfail+0x1d/frame 0xfffffe00002e9950 zio_vdev_io_assess() at zio_vdev_io_assess+0x2e8/frame 0xfffffe00002e9980= zio_execute() at zio_execute+0x1e9/frame 0xfffffe00002e99e0 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe00002e9= a40 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe00002e9a70 fork_exit() at fork_exit+0x84/frame 0xfffffe00002e9ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002e9ab0 --- trap 0, rip =3D 0, rsp =3D 0xfffffe00002e9b70, rbp =3D 0 --- KDB: enter: panic (kgdb) where #0 doadump (textdump=3D-2125462752) at pcpu.h:219 #1 0xffffffff80347655 in db_fncall (dummy1=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:578 #2 0xffffffff8034733d in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff803470b4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff80349a90 in db_trap (type=3D, code=3D0= ) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff80944159 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80d1e532 in trap (frame=3D0xfffffe00002e97d0) at /usr/src/sys/amd64/amd64/trap.c:542 #7 0xffffffff80d01202 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff809438be in kdb_enter (why=3D0xffffffff80f9ce38 "panic", msg=3D) at cpufunc.h:63 #9 0xffffffff8090bb66 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:737 #10 0xffffffff8090bbd3 in panic (fmt=3D0xffffffff815a59a0 "\004") at /usr/src/sys/kern/kern_shutdown.c:673 #11 0xffffffff81fb821d in assfail (a=3D, ---Type to continue, or q to quit--- f=3D, l=3D) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81= #12 0xffffffff81eca848 in zio_vdev_io_assess (ziop=3D) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zio.c:2874 #13 0xffffffff81ec58b9 in zio_execute (zio=3D0xfffff801a8abc398) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zio.c:1416 #14 0xffffffff80954150 in taskqueue_run_locked (queue=3D0xfffff80009249b0= 0) at /usr/src/sys/kern/subr_taskqueue.c:356 #15 0xffffffff80954c1b in taskqueue_thread_loop (arg=3D) at /usr/src/sys/kern/subr_taskqueue.c:623 #16 0xffffffff808d9834 in fork_exit ( callout=3D0xffffffff80954b80 , arg=3D0xfffff80003dfeed0, frame=3D0xfffffe00002e9ac0) at /usr/src/sys/kern/kern_fork.c:977 #17 0xffffffff80d0173e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #18 0x0000000000000000 in ?? () (kgdb) frame 12 #12 0xffffffff81eca848 in zio_vdev_io_assess (ziop=3D) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zio.c:2874 2874 ASSERT(!(zio->io_flags & ZIO_FLAG_DELEGATED)); (kgdb) print zio $3 =3D (zio_t *) 0xfffff801a8abc398 (kgdb) print *zio $4 =3D {io_bookmark =3D {zb_objset =3D 4339, zb_object =3D 327827, zb_lev= el =3D 0, zb_blkid =3D 0}, io_prop =3D {zp_checksum =3D ZIO_CHECKSUM_INHERIT, zp_compress =3D ZIO_COMPRESS_INHERIT, zp_type =3D DMU_OT_NONE, zp_level =3D 0 '\0', zp_copies =3D 0 '\0', zp_dedup =3D 0, zp_dedup_v= erify =3D 0, zp_nopwrite =3D 0}, io_type =3D ZIO_TYPE_WRITE, io_child_type =3D ZIO_CHILD_VDEV, io_cmd =3D 0, io_priority =3D ZIO_PRIORITY_ASYNC_WRITE, io_reexecute =3D 0 '\0', io_state =3D "\001", io_txg =3D 1312558, io_spa =3D 0xfffffe00022e6000,= io_bp =3D 0xfffffe000a94a640, io_bp_override =3D 0x0, io_bp_copy =3D {blk_dva =3D {{ dva_word =3D {1, 58754170}}, {dva_word =3D {1, 69614673}}, {dva_w= ord =3D {0, 0}}}, blk_prop =3D 9229009297394892802, blk_pad =3D {0, 0}, blk_phys_birth =3D 0, blk_birth =3D 1312558, blk_fill =3D 1, blk_cksu= m =3D { zc_word =3D {72684358009, 6982033287555, 350329209490535, 12175142665158025}}}, io_parent_list =3D {list_size =3D 48, list_offset =3D 16, list_head =3D {list_next =3D 0xfffff800092e7520, list_prev =3D 0xfffff800092e7520}}, io_child_list =3D {list_size =3D= 48, list_offset =3D 32, list_head =3D {list_next =3D 0xfffff801a8abc4b8, list_prev =3D 0xfffff801a8abc4b8}}, io_walk_link =3D 0x0, io_logical =3D 0xfffff801a8cb7730, io_transform_stack =3D 0x0, io_ready= =3D 0, io_physdone =3D 0xffffffff81e34ee0 , io_done =3D 0xffffffff81ea7ea0 , io_private =3D 0xfffff80027266d18, io_prev_space_delta =3D 0, io_bp_ori= g =3D { blk_dva =3D {{dva_word =3D {1, 58754170}}, {dva_word =3D {1, 69614673= }}, { ---Type to continue, or q to quit--- dva_word =3D {0, 0}}}, blk_prop =3D 9229009297394892802, blk_pad = =3D {0, 0}, blk_phys_birth =3D 0, blk_birth =3D 1312558, blk_fill =3D 1, blk_cksu= m =3D { zc_word =3D {72684358009, 6982033287555, 350329209490535, 12175142665158025}}}, io_data =3D 0xfffff8017b0b3000, io_orig_data =3D 0xfffff8017b0b3000, io_size =3D 512, io_orig_size =3D = 512, io_vd =3D 0xfffff8000935f800, io_vsd =3D 0x0, io_vsd_ops =3D 0x0, io_offset =3D 30086329344, io_timestamp =3D 76492632312, io_queue_node = =3D { avl_child =3D {0x0, 0x0}, avl_pcb =3D 18446735284737973505}, io_flags =3D 269224064, io_stage =3D ZIO_STAGE_VDEV_IO_ASSESS, io_pipeline =3D 3014656, io_orig_flags =3D 524416, io_orig_stage =3D ZIO_STAGE_READY, io_orig_pipeline =3D 3014656, io_err= or =3D 0, io_child_error =3D {0, 0, 0, 0}, io_children =3D {{0, 0}, {0, 0}, {0, 0= }, {0, 0}}, io_child_count =3D 0, io_phys_children =3D 0, io_parent_count = =3D 1, io_stall =3D 0x0, io_gang_leader =3D 0x0, io_gang_tree =3D 0x0, io_executor =3D 0xfffff80009265490, io_waiter =3D 0x0, io_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81f763a5 "zio->io_lock", lo_flags =3D 4096000= 0, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, io_cv =3D { cv_description =3D 0xffffffff81f763b3 "zio->io_cv", cv_waiters =3D 0}= , io_cksum_report =3D 0x0, io_ena =3D 0, io_tqent =3D {tqent_task =3D {ta= _link =3D { stqe_next =3D 0x0}, ta_pending =3D 0, ta_priority =3D 0, ta_func =3D 0xffffffff81e1dd60 , ta_context =3D 0xfffff801a8abc6d8}, tqent_func =3D 0xffffffff81ec56d0 , ---Type to continue, or q to quit--- tqent_arg =3D 0xfffff801a8abc398}, io_trim_node =3D {avl_child =3D {0= x0, 0x0}, avl_pcb =3D 0}, io_trim_link =3D {list_next =3D 0x0, list_prev =3D 0x= 0}} I'm not an expert with kgdb. If you need anything else let me know what you need. Florian --rp9sFLx0TfVQoplMJscgoqQj9Iqaw3u1w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzKQMAAoJEOcFPfn/hvB2+QIQAN0ut0ahLdyhD527Ecz3fskG YGZ/hW8R6pKPBTv9ZceXfAwgH5uJ4cF2yqXL9Mrj+hYQqcltDPhSwyyHXwIrkLig 4RrajKRBGF4ybYEZYzTwnYTUVCvv8EtmAeZm1Q1N3vQ5FAEw7cwNZzCEumZawMue ZmbVI+id1LvqALORBuX3HH3HcEB8QeJ2rWJboP+n9+ttxuPJMv69K6HPwxVEgRQ+ MIY0P+BVLRLX9Q5/Hl8q4YDJwlL3NB74jlNT46wyHcfLVWxc5FlGILXwsW0IlGbl ybEPQHlhgutSibQsuUY8bbxkhR4Xn+NISIv8tG6eH5aLE8OHDIyWiBvOoHm7HEfl hXdkA1UAoX5QzrhMmlvMnWoH72SPwlOh/1cpHb4FnfY5APcWkaURDCflx1CuXATQ fYaGHkrHHoT5K+h+ADwu4+W6nrx8rAC3f2vNjJrgvz3kwSsLVUBBIpoHy5pkwfkA bm8+iNhwBXyV6cs4Fyv8OsEAyN7EUd/7kxIeBoj5ogxcPUN1oiA+FXruMMx+wdTA vMSKIOV51NhSaFsppUwy+uQaLI3FZWvMshC1DVHDR12DX0i86F3X0MHyu3QUZqcz TFIoywoF2LtVYuzYCoewfyyCBOe3/1LkXCoRt9uxhzMOwOv9HVs8WQ0pbUN5RcY7 UY7ZUh0QMItMtlILk/c4 =d1HU -----END PGP SIGNATURE----- --rp9sFLx0TfVQoplMJscgoqQj9Iqaw3u1w-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 05:42:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A75A486; Mon, 21 Jul 2014 05:42:47 +0000 (UTC) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::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 D717926B9; Mon, 21 Jul 2014 05:42:46 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id i7so6765925oag.32 for ; Sun, 20 Jul 2014 22:42:46 -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=yZxGbpBs6EKrl6Tqm2c8nk+uzlkB4SVIzksNuW0BuBw=; b=lpbETty60UourIjyN0+j51O/pQc09G7xBUzIPxdJ2y4Xz7F160AABc1T1g2nNjaWCn bcFUVKdL6muIe+OrvEaxC8665lDf8B30L1GTnJvLAG955mM6jvFkGKmeM4WVbM3m3DEa 82E1GwOcVx1mpYxq3qN4UjgbNBT1VTLMZhByA7rWKctMWMwB38P1ohuXFRBaXvT2lITh huThNJ6F2Bkb4sy1s6YJTGhJjQJlBo2pyg8DMwPnwDEfXGP8c3pqRMvQyUE7t3gybkAa aSCZTzF1ykdd6H2cRBczZMWfQwTMlCFQRgEgRxZBdWts8Z6zz5oV7OFhELRZZUW1vckw HMtA== MIME-Version: 1.0 X-Received: by 10.60.176.10 with SMTP id ce10mr33540987oec.8.1405921366137; Sun, 20 Jul 2014 22:42:46 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Sun, 20 Jul 2014 22:42:46 -0700 (PDT) In-Reply-To: <53CC87D2.1000601@freebsd.org> References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> <20140720134133.1d30f725@kan> <53CC87D2.1000601@freebsd.org> Date: Mon, 21 Jul 2014 07:42:46 +0200 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Andreas Nilsson To: Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Maxim Khitrov , Current FreeBSD , FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 05:42:47 -0000 On Mon, Jul 21, 2014 at 5:24 AM, Julian Elischer wrote: > On 7/21/14, 7:27 AM, Andreas Nilsson wrote: > >> On Sun, Jul 20, 2014 at 7:41 PM, Alexander Kabaev >> wrote: >> >> On Sun, 20 Jul 2014 10:15:36 -0400 >>> Maxim Khitrov wrote: >>> >>> On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels >>>> wrote: >>>> >>>>> On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: >>>>> >>>>>> all of that is true, but you are missing the point. Having two >>>>>> versions of pf on the bsd's at the user level, is a bad thing. It >>>>>> confuses people, which puts them off. Its a classic case of divide >>>>>> an conquer for other platforms. I really like the idea of the >>>>>> openpf version, that has been mentioned in this thread. It would >>>>>> be awesome if it ended up as a supported linux thing as well, so >>>>>> the world could be rid of iptables. However i guess thats just an >>>>>> unrealistic dream >>>>>> >>>>> And you don't seem to get the point that _someone_ has to do the >>>>> work. No one has stepped up so far, so nothing is going to change. >>>>> >>>> Gleb believes that the majority of FreeBSD users don't want the >>>> updated syntax, among other changes, from the more recent pf versions. >>>> Developers who share his opinion are not going to volunteer to do the >>>> work. This discussion is about showing this belief to be wrong, which >>>> is the first step in the process. >>>> >>>> In my opinion, the way forward is to forget (at least temporarily) the >>>> SMP changes, bring pf in sync with OpenBSD, put a policy in place to >>>> follow their releases as closely as possible, and then try to >>>> reintroduce all the SMP work. I think the latter has to be done >>>> upstream, otherwise it'll always be a story of diverging codebases. >>>> Furthermore, if FreeBSD developers were willing to spend some time >>>> improving pf performance on OpenBSD, then Henning and other OpenBSD >>>> developers might be more receptive to changes that make the porting >>>> process easier. >>>> >>> I am one person whose opinion Gleb got completely right - I could not >>> care less about new syntax nor about how close or how far are we from >>> OpenBSD, as long as pf works for my purposes and it does. This far >>> into the thread and somebody has yet to provide a comprehensive list of >>> the benefits that we allegedly miss, or to come up with the real >>> benchmark result to substantiate the performance claims. >>> >>> Focusing on disproving anything Gleb might be believing in on the >>> matter, while an interesting undertaking, does nothing to give you new >>> pf you supposedly want. Doing the work and bringing it all the way to >>> will completeness for commit - does. >>> >>> It was stated repeatedly by multiple people that FreeBSD's network >>> stack is way too different from OpenBSD, we support features >>> OpenBSD doesn't and vice versa, vimage is a good example, which throws a >>> giant wrench into the plan of following OpenBSD 'as closely as >>> possible', even as the expense of throwing away all of the SMP work >>> done in pf to date. >>> >>> I like vimage, don't get me wrong, but it also seems to have lost >> traction. >> If vimage is the only thing holding a pf import back there ought to be >> some >> discussion about which is a priority. >> > As one involved with Vimage, I get feedback all the time that lets me know > it's in really heavy use in some pretty interesting commercial situations. > It HAS lst some traction in terms of added work, but that's because it's > solid enough for people to use. > In the situations where it's being used, it's a game changer and rhe > conversation goes something like: > > "hey vimage and pf don't work together.. guess that makes the firewall > decision easy.. use ipfw" > > Good to know! > >> Also, the openbsd stack has some essential features missing in freebsd, >> like mpls and md5 auth for bgp sessions. >> >> /A >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> >> > From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 05:44:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 791C762C; Mon, 21 Jul 2014 05:44:25 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::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 346BE26DE; Mon, 21 Jul 2014 05:44:25 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id g18so6646527oah.37 for ; Sun, 20 Jul 2014 22:44:24 -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=b+L3Pde+2p5x0v0UjX45Tc99rHgHH4cWZvS9nPvqaog=; b=TCjR2WwQ4HBCIQyCUjmdESvnic+dz8ioYDpDS/mc2B40VZ8jxTKCMp0XPnoR0vlnSD hzGT2TmKst3BpzlzZsgimO9K6Xcwiw/xBlMX65flwwtLzYnWftRHvo+KStwoZXJYeLyw 4KEHhzIZpmaOW+j0YqWJcjc17viWJBLu6adTy6wtW+ThMiWNsViPbOvEd6FioQAPeQ2i jS4RXGKEswsSLmOC4BEG6r/hXUTCnvqH7TFTN8V8ERKbws1oyEKz9nkDxhyG2NeDT77X 67WVW8k9Qjni/7ga08m9P/oHK1bfrHxB/fdV9UVw4Zfkk4ANxe871192wBpuq/2/qHu2 ImUg== MIME-Version: 1.0 X-Received: by 10.182.116.161 with SMTP id jx1mr33664789obb.50.1405921464548; Sun, 20 Jul 2014 22:44:24 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Sun, 20 Jul 2014 22:44:24 -0700 (PDT) In-Reply-To: <20140721.074105.74747815.sthaug@nethelp.no> References: <20140720134133.1d30f725@kan> <20140721.074105.74747815.sthaug@nethelp.no> Date: Mon, 21 Jul 2014 07:44:24 +0200 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Andreas Nilsson To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Maxim Khitrov , Current FreeBSD , Mailinglists FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 05:44:25 -0000 On Mon, Jul 21, 2014 at 7:41 AM, wrote: > > Also, the openbsd stack has some essential features missing in freebsd, > > like mpls and md5 auth for bgp sessions. > > I use MD5 auth for BGP sessions every day (and have been doing so for > several releases). One could definitely wish for better integration - > having to specify MD5 key both in /etc/ipsec.conf and in the Quagga > bgpd config is not nice. But it works. > As far as I know you can only send out correctly authed stuff but not validate incoming. Has that changed? /Andreas > > MPLS would be nice - but is not a high priority. That's what I use > Juniper and Cisco routers for. For MPLS to be of any use I'd also need > a working IS-IS implementation, and I believe Quagga isn't quite there > yet. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 05:49:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8FE3960 for ; Mon, 21 Jul 2014 05:49:05 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id E6552271F for ; Mon, 21 Jul 2014 05:49:04 +0000 (UTC) Received: (qmail 4924 invoked from network); 21 Jul 2014 05:42:20 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Jul 2014 05:42:20 -0000 Date: Mon, 21 Jul 2014 07:41:05 +0200 (CEST) Message-Id: <20140721.074105.74747815.sthaug@nethelp.no> To: andrnils@gmail.com Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: sthaug@nethelp.no In-Reply-To: References: <20140720134133.1d30f725@kan> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: max@mxcrypt.com, freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 05:49:05 -0000 > Also, the openbsd stack has some essential features missing in freebsd, > like mpls and md5 auth for bgp sessions. I use MD5 auth for BGP sessions every day (and have been doing so for several releases). One could definitely wish for better integration - having to specify MD5 key both in /etc/ipsec.conf and in the Quagga bgpd config is not nice. But it works. MPLS would be nice - but is not a high priority. That's what I use Juniper and Cisco routers for. For MPLS to be of any use I'd also need a working IS-IS implementation, and I believe Quagga isn't quite there yet. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 06:57:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A52D557D for ; Mon, 21 Jul 2014 06:57:34 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id DFCE82C6D for ; Mon, 21 Jul 2014 06:57:32 +0000 (UTC) Received: (qmail 7080 invoked from network); 21 Jul 2014 06:57:31 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Jul 2014 06:57:31 -0000 Date: Mon, 21 Jul 2014 08:56:16 +0200 (CEST) Message-Id: <20140721.085616.74744313.sthaug@nethelp.no> To: andrnils@gmail.com Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: sthaug@nethelp.no In-Reply-To: References: <20140721.074105.74747815.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: max@mxcrypt.com, freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 06:57:34 -0000 > > > Also, the openbsd stack has some essential features missing in freebsd, > > > like mpls and md5 auth for bgp sessions. > > > > I use MD5 auth for BGP sessions every day (and have been doing so for > > several releases). One could definitely wish for better integration - > > having to specify MD5 key both in /etc/ipsec.conf and in the Quagga > > bgpd config is not nice. But it works. > > > As far as I know you can only send out correctly authed stuff but not > validate incoming. Has that changed? Have a look at tcp_signature_verify(), called from tcp_input.c. Added in r221023, see http://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?view=log Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- Revision 221023 - (view) (download) (annotate) - [select for diffs] Modified Mon Apr 25 17:13:40 2011 UTC (3 years, 2 months ago) by attilio File length: 106717 byte(s) Diff to previous 220560 Add the possibility to verify MD5 hash of incoming TCP packets. As long as this is a costy function, even when compiled in (along with the option TCP_SIGNATURE), it can be disabled via the net.inet.tcp.signature_verify_input sysctl. Sponsored by: Sandvine Incorporated Reviewed by: emaste, bz MFC after: 2 weeks From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 07:59:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B41F33A; Mon, 21 Jul 2014 07:59:00 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCFE1225B; Mon, 21 Jul 2014 07:58:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=lB1XuBgFw4VawDjxBGgpFG8vYzm8EAilOi5ZVNMHhYI=; b=cSUmACnK7aZXlOv4XZpFeiSh1N8g0QBoZmHZyxUqZpQybsRtRZHKhtCLWK1p3LiZcvamx4wM91HbbCGH3RHS4jl2z2xSg0zzkUqsE2pLbULTW8zSNgBgZY0Lx5Bh8m1PafgVB79yMhkmX2B9x8XkD/xYusKbHle1gzB92Kw2YCU=; Received: from localhost.lerctr.org ([127.0.0.1]:14264 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X98Un-000ONY-Ck; Mon, 21 Jul 2014 02:58:55 -0500 Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Mon, 21 Jul 2014 02:58:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 21 Jul 2014 02:58:53 -0500 From: Larry Rosenman To: Florian Smeets Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 In-Reply-To: <53CCA40B.10503@smeets.im> References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> <53CCA40B.10503@smeets.im> Message-ID: <79dfedb5b7110aebecb35b08d2a5454d@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 07:59:00 -0000 On 2014-07-21 00:24, Florian Smeets wrote: > On 21/07/14 01:46, Steven Hartland wrote: >> ----- Original Message ----- From: "Larry Rosenman" >> To: "Steven Hartland" >> Cc: ; >> Sent: Monday, July 21, 2014 12:22 AM >> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 >> >> >>> On 2014-07-20 18:21, Steven Hartland wrote: >>>> Can you try reverting r265321 and see if you still see the >>>> same crash? >>>> >>>> Regards >>>> Steve >>> I'll do the revert, but it's been a ONE TIME hit. >>> >>> There was a followup to mine with a reproducible poudriere crash like >>> mine. >> >> If you don't have a reproducable senario I'd hold off. >> >> Florian, is yours reproducable and can you send me >> a pretty print of the crashing zio? >> > can you set print pretty on and then reprint the zio? That makes it "pretty" for Steve. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 08:18:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F687C7E; Mon, 21 Jul 2014 08:18:03 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E85FA24BF; Mon, 21 Jul 2014 08:18:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=lsF2G+XBCWJBtGgs4bzYs4Zfv+6nvdUZqW9i1iwKN9A=; b=ew80WyL0E4Qzlrgrq46MNJR3mkzr41UFlcnFYgoRzjJlvPpbKWD8h2l+y8iKUUgrEARgT5j3te42UYLtU0x6Sx+YjwiaWqEh0i4FAcbGF9zRFuTjnmj+0zia/IxJpFCzWLn7iCWmQyv/KT/xOC6kbr/ZvTv6cVJfcOgvIIZ1zjc=; Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]:43040 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X98nI-000Ojv-8A; Mon, 21 Jul 2014 03:18:02 -0500 Date: Mon, 21 Jul 2014 03:17:48 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: [PANIC][vboxdrv] use afer free/iprtheap Message-ID: <20140721081748.GA1365@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 08:18:03 -0000 Got the following panic this morning.... borg.lerctr.org dumped core - see /var/crash/vmcore.5 Sun Jul 20 03:28:12 CDT 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #50 r268894M: Sat Jul 19 18:06:08 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 2874 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c49f930 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c49f9e0 vpanic() at vpanic+0x126/frame 0xfffffe100c49fa20 panic() at panic+0x43/frame 0xfffffe100c49fa80 assfail() at assfail+0x1d/frame 0xfffffe100c49fa90 zio_vdev_io_assess() at zio_vdev_io_assess+0x2ed/frame 0xfffffe100c49fac0 zio_execute() at zio_execute+0x1e9/frame 0xfffffe100c49fb20 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe100c49fb80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe100c49fbb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c49fbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c49fbf0 --- trap 0, rip = 0, rsp = 0xfffffe100c49fcb0, rbp = 0 --- Uptime: 8h57m17s (ada2:ahcich2:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: Command timeout (ada2:ahcich2:0:0:0): Error 5, Retries exhausted (ada2:ahcich2:0:0:0): Synchronize cache failed Dumping 7745 out of 64463 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkms.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ether.ko.symbols Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff80a055f7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:445 #2 0xffffffff80a05b35 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:744 #3 0xffffffff80a05b83 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:673 #4 0xffffffff8032d05d in assfail (a=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 #5 0xffffffff8040ad6d in zio_vdev_io_assess (ziop=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2874 #6 0xffffffff80405dd9 in zio_execute (zio=0xfffff809e449b730) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1416 #7 0xffffffff80a4de60 in taskqueue_run_locked (queue=0xfffff8002255e800) at /usr/src/sys/kern/subr_taskqueue.c:356 #8 0xffffffff80a4e8db in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:623 #9 0xffffffff809d3cc4 in fork_exit ( callout=0xffffffff80a4e840 , arg=0xfffff80022611470, frame=0xfffffe100c49fc00) at /usr/src/sys/kern/kern_fork.c:977 #10 0xffffffff80df5afe in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #11 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) Ideas? virtualbox-ose-4.3.12_1 A general-purpose full virtualizer for x86 hardware virtualbox-ose-kmod-4.3.12 VirtualBox kernel module for FreeBSD -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 08:20:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD2FBE61; Mon, 21 Jul 2014 08:20:55 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B062324F5; Mon, 21 Jul 2014 08:20:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=G5pxcuhK285keeFtVNTZsky+9rjt1icstSAUsn/zMeM=; b=gPUqch0PeYAW3CCQO8KhGfP36BTPmcmssPdYSp1YQckTt10Sm5H81c8daFwSTWeORHoND0ZzvSpWD63bJXYgDeYkbLBI1+ntZOLkPnc/xGGMARLkVhU8WUmosmWq3TSPzQ8D5bmx4x1Pb/mRMXj94VjCNyUtzx/tCY1wt9kjmeQ=; Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]:43785 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X98q4-000Olv-UU; Mon, 21 Jul 2014 03:20:55 -0500 Date: Mon, 21 Jul 2014 03:20:41 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: [PANIC][vboxdrv] use afer free/iprtheap Message-ID: <20140721082041.GB1365@borg.lerctr.org> References: <20140721081748.GA1365@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140721081748.GA1365@borg.lerctr.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 08:20:55 -0000 Ignore previous, here's the right core: borg.lerctr.org dumped core - see /var/crash/vmcore.6 Mon Jul 21 03:13:37 CDT 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #54 r268932M: Sun Jul 20 19:26:23 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: Most recently used by iprtheap GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Memory modified after free 0xfffff8056da02d00(120) val=e69eedef @ 0xfffff8056da02d10 panic: Most recently used by iprtheap cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c947360 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c947410 vpanic() at vpanic+0x126/frame 0xfffffe100c947450 panic() at panic+0x43/frame 0xfffffe100c9474b0 mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfffffe100c9474e0 uma_zalloc_arg() at uma_zalloc_arg+0x4d1/frame 0xfffffe100c947550 malloc() at malloc+0x194/frame 0xfffffe100c9475a0 rtR0MemAllocEx() at rtR0MemAllocEx+0xd2/frame 0xfffffe100c947600 RTMemAllocZTag() at RTMemAllocZTag+0x14/frame 0xfffffe100c947620 rtR0MemObjNew() at rtR0MemObjNew+0x2f/frame 0xfffffe100c947650 rtR0MemObjFreeBSDAllocPhysPages() at rtR0MemObjFreeBSDAllocPhysPages+0x31/frame 0xfffffe100c9476a0 rtR0MemObjNativeAllocPhysNC() at rtR0MemObjNativeAllocPhysNC+0x2e/frame 0xfffffe100c9476c0 g_aUnits() at g_aUnits+0x58d9/frame 0xfffffe100c947720 g_aUnits() at g_aUnits+0x266a/frame 0xfffffe100c9477a0 g_aUnits() at g_aUnits+0x1f9f/frame 0xfffffe100c947820 g_aUnits() at 0xffffffff83257c35/frame 0xfffffe100c947870 g_aUnits() at 0xffffffff8325a0de/frame 0xfffffe100c9478b0 g_aUnits() at 0xffffffff83259c23/frame 0xfffffe100c9478f0 supdrvIOCtlInnerUnrestricted() at supdrvIOCtlInnerUnrestricted+0x5a1/frame 0xfffffe100c947970 VBoxDrvFreeBSDIOCtl() at VBoxDrvFreeBSDIOCtl+0x1e6/frame 0xfffffe100c9479d0 devfs_ioctl_f() at devfs_ioctl_f+0xfb/frame 0xfffffe100c947a30 kern_ioctl() at kern_ioctl+0x22b/frame 0xfffffe100c947a90 sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe100c947ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe100c947bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe100c947bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80128f5ca, rsp = 0x7fffff8a5c58, rbp = 0x7fffff8a5c60 --- Uptime: 7h12m25s Dumping 7915 out of 64463 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkms.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ether.ko.symbols Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff80a055d7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:445 #2 0xffffffff80a05b15 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:744 #3 0xffffffff80a05b63 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:673 #4 0xffffffff80c83aaa in mtrash_ctor (mem=, size=, arg=, flags=) at /usr/src/sys/vm/uma_dbg.c:138 #5 0xffffffff80c7fbe1 in uma_zalloc_arg (zone=0xfffff80ffffc9680, udata=0x0, flags=257) at /usr/src/sys/vm/uma_core.c:2164 #6 0xffffffff809ed0b4 in malloc (size=, mtp=0xffffffff81fd3b70, flags=) at uma.h:336 #7 0xffffffff81fc2232 in rtR0MemAllocEx () from /boot/modules/vboxdrv.ko #8 0xffffffff81fc0904 in RTMemAllocZTag () from /boot/modules/vboxdrv.ko #9 0xffffffff81fc0d3f in rtR0MemObjNew () from /boot/modules/vboxdrv.ko #10 0xffffffff81fc27b1 in rtR0MemObjFreeBSDAllocPhysPages () from /boot/modules/vboxdrv.ko #11 0xffffffff81fc28ae in rtR0MemObjNativeAllocPhysNC () from /boot/modules/vboxdrv.ko #12 0xffffffff83242799 in ?? () #13 0xfffffe0559b32010 in ?? () #14 0x000000780000002b in ?? () #15 0xfffffe100977d7c8 in ?? () #16 0xffffffff8324287e in ?? () #17 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) virtualbox-ose-4.3.12_1 A general-purpose full virtualizer for x86 hardware virtualbox-ose-kmod-4.3.12 VirtualBox kernel module for FreeBSD Ideas? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 11:12:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04C1EB84; Mon, 21 Jul 2014 11:12:45 +0000 (UTC) Received: from forward3l.mail.yandex.net (forward3l.mail.yandex.net [IPv6:2a02:6b8:0:1819::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 897C02648; Mon, 21 Jul 2014 11:12:44 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward3l.mail.yandex.net (Yandex) with ESMTP id C6F8B150130E; Mon, 21 Jul 2014 15:12:31 +0400 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id 4BF78BE00E6; Mon, 21 Jul 2014 15:12:31 +0400 (MSK) Received: from 84.201.164.118-vpn.dhcp.yndx.net (84.201.164.118-vpn.dhcp.yndx.net [84.201.164.118]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id kWMeRnPJdx-CUAistTi; Mon, 21 Jul 2014 15:12:30 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: b3d5f938-c5fb-4ff8-869d-f993f1bf0cd4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1405941150; bh=RmwkCOjc2PH5D+lAaTSej4qGKSBMXDe3QVsifjEMKyI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=VdnU+tqEZ1xOmHabsno4spENqa9zYojw67jiSQ2DHoZyVPAOszDqA1CQq+92+RPYE qeYhfmGHxT8XvJ6bbVRg/ukTwa1v8kGrrDxb78bRt2s6+v6TJTLM5sCx2GsSDJClLz svDTKffDzjW39RQYK6VogytEN7zHz6Iqw+fS+skw= Authentication-Results: smtp19.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53CCF596.1070302@yandex.ru> Date: Mon, 21 Jul 2014 15:12:22 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Maxim Khitrov , FreeBSD Mailing List , freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <20140720123916.GV96250@e-new.0x20.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 11:12:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.07.2014 18:15, Maxim Khitrov wrote: > In my opinion, the way forward is to forget (at least temporarily) the > SMP changes, bring pf in sync with OpenBSD, put a policy in place to > follow their releases as closely as possible, and then try to > reintroduce all the SMP work. I think the latter has to be done > upstream, otherwise it'll always be a story of diverging codebases. > Furthermore, if FreeBSD developers were willing to spend some time > improving pf performance on OpenBSD, then Henning and other OpenBSD > developers might be more receptive to changes that make the porting > process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) --=20 WBR, Andrey V. Elsukov --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L 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.22 (FreeBSD) iQEcBAEBAgAGBQJTzPWbAAoJEAHF6gQQyKF6URMIAImzr/5fuPhtMn6ucHQN/iXS c9J4cuB3IBWrK0UhaNPloPk9sXthIeNqFg0rX7QXu2QGTkkxYvJo50LkdIoftokG jgozS5QZFg7ojcWBxts0LNAAo/keSv28gmDQgDQSimb5VX/Nj6dwlYjb3XW9iyGc Gd8FWMJz04Pi0iUGkTeFUOuVlBMmT0ktbSfiKsj0LHRmMmTvPYtoC7h2g1Q4Ukte xskOpj3vAH0eAdhlIGpCr7yZkKFzIIDwZAyj8gyBijT2NjxOE7HOWyTJplleO1wE IgcO2ta54ctsFHnmulCqEMKJV1F94DIh1bPWuEdqbo9ePjY9NKzqgda6nzDSR+I= =Xfip -----END PGP SIGNATURE----- --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 11:46:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98B57EB1; Mon, 21 Jul 2014 11:46:30 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003: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 53FB72A59; Mon, 21 Jul 2014 11:46:30 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id m1so7133741oag.35 for ; Mon, 21 Jul 2014 04:46:29 -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=zqKf21w9w3Z9QtqUIV4Z7vrpVa4Lziz1tFh1jQpWEW0=; b=Y2ZdQZnx9LFYJ5uzFrphCSFBThMHQ6J7ZHJdqA7qz1l8RgPHKQVBf5r14Mzr2gdUKW 16xK+5+swhQPLMlH87rwZzVr9MYDS0ANqcKV0uLSFe+5QjZDs2Kv9jaluyFHS4zTB+Sd 8bPGfqQda/5U3SXesUsAVCtN3fGihvZGZM3rfoxvXfNh7NawU3XKzMeNg+/yqdh3wsOD DxBTKS4ZTZgShzdVHzsLcX3Qa+sDNpMmnHS87knBgz7DmcMzSTnBkct5K6uy1KcG9TQW vIbSB5bo/drSqL5BmGsKwB2K2ZDV8s2YsaYWN/AlDwUBjVnAU4de71AevlabtJO4jfCF sPig== MIME-Version: 1.0 X-Received: by 10.182.133.69 with SMTP id pa5mr37089163obb.2.1405943188848; Mon, 21 Jul 2014 04:46:28 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Mon, 21 Jul 2014 04:46:28 -0700 (PDT) In-Reply-To: <20140721.085616.74744313.sthaug@nethelp.no> References: <20140721.074105.74747815.sthaug@nethelp.no> <20140721.085616.74744313.sthaug@nethelp.no> Date: Mon, 21 Jul 2014 13:46:28 +0200 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Andreas Nilsson To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Maxim Khitrov , Current FreeBSD , Mailinglists FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 11:46:30 -0000 On Mon, Jul 21, 2014 at 8:56 AM, wrote: > > > > Also, the openbsd stack has some essential features missing in > freebsd, > > > > like mpls and md5 auth for bgp sessions. > > > > > > I use MD5 auth for BGP sessions every day (and have been doing so for > > > several releases). One could definitely wish for better integration - > > > having to specify MD5 key both in /etc/ipsec.conf and in the Quagga > > > bgpd config is not nice. But it works. > > > > > As far as I know you can only send out correctly authed stuff but not > > validate incoming. Has that changed? > > Have a look at tcp_signature_verify(), called from tcp_input.c. Added > in r221023, see > > http://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?view=log > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > ---------------------------------------------------------------------- > > Revision 221023 - (view) (download) (annotate) - [select for diffs] > Modified Mon Apr 25 17:13:40 2011 UTC (3 years, 2 months ago) by attilio > File length: 106717 byte(s) > Diff to previous 220560 > Add the possibility to verify MD5 hash of incoming TCP packets. > As long as this is a costy function, even when compiled in (along with > the option TCP_SIGNATURE), it can be disabled via the > net.inet.tcp.signature_verify_input sysctl. > > Sponsored by: Sandvine Incorporated > Reviewed by: emaste, bz > MFC after: 2 weeks > > I stand corrected. Excellent news ( for me, that is) :) Best regards Andeas From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 13:57:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D56BD19; Mon, 21 Jul 2014 13:57:28 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::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 075E228A2; Mon, 21 Jul 2014 13:57:28 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id g10so7650807pdj.26 for ; Mon, 21 Jul 2014 06:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=QWhriY2swMIFWukwl+YjrIzSn8u5N8ueYINmR9/mlB0=; b=x0GjTOcswsA+/Cq13VQtwYYJOv5Hnbr255Q9tVfciXh3xEqZaLpqmeQ7TIjkbBpKtp F0irptp9ODCLegD4GdjS3zV+MNPe03Fln8t3YPqpCVuA6HFrSjFejAdgN6YjwL1l1c27 rAAsZavswNglM5mzZP1j7notDnLndWie6w487iPBBsXOblySuIwZyjjLmWtK96Mgclju wI8KzyyIEaEl49mmr29+EKcPQsCpdRCmU1Ip9/8nZGm/ZR25xYfVwnGhamU8+uH7dltj G2vUf63wsojGoILg0ocarYLio1Of6k1gN1MT6M5gCQHIiuum5VQ3CcgZbfELcB+lwf0U X/ww== X-Received: by 10.70.128.227 with SMTP id nr3mr2359761pdb.156.1405951047050; Mon, 21 Jul 2014 06:57:27 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id av2sm14318796pbc.16.2014.07.21.06.57.24 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Jul 2014 06:57:26 -0700 (PDT) From: "bycn82" To: "'Andreas Nilsson'" , References: <20140721.074105.74747815.sthaug@nethelp.no> <20140721.085616.74744313.sthaug@nethelp.no> In-Reply-To: Subject: RE: Future of pf / firewall in FreeBSD ? - does it have one ? Date: Mon, 21 Jul 2014 21:57:21 +0800 Message-ID: <002601cfa4eb$b4554270$1cffc750$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/50tpYfGwpMKNeBPkSOvXVI/2jQIrBaeAAroD+/YB+jKkdAEPYalNmoqQtWA= Content-Language: en-us Cc: 'Maxim Khitrov' , 'Current FreeBSD' , 'Mailinglists FreeBSD' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:57:28 -0000 There is no doubt that PF is a really good firewall, But we should = noticed that there is an ipfw which is originally from FreeBSD while PF = is from OpenBSD. If there is a requirement that PF can meet but ipfw cannot, then I think = it is better to improve the ipfw. But if you just like the PF style, = then I think choose OpenBSD is the better solution. Actually OpenBSD is = another really good operating system.=20 Like myself, I like CentOS and ipfw, so no choice :) > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Andreas Nilsson > Sent: 21 July, 2014 19:46 > To: sthaug@nethelp.no > Cc: Maxim Khitrov; Current FreeBSD; Mailinglists FreeBSD > Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? >=20 > On Mon, Jul 21, 2014 at 8:56 AM, wrote: >=20 > > > > > Also, the openbsd stack has some essential features missing in > > freebsd, > > > > > like mpls and md5 auth for bgp sessions. > > > > > > > > I use MD5 auth for BGP sessions every day (and have been doing = so > > > > for several releases). One could definitely wish for better > > > > integration - having to specify MD5 key both in /etc/ipsec.conf > > > > and in the Quagga bgpd config is not nice. But it works. > > > > > > > As far as I know you can only send out correctly authed stuff but > > > not validate incoming. Has that changed? > > > > Have a look at tcp_signature_verify(), called from tcp_input.c. = Added > > in r221023, see > > > > = http://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?view=3Dlog > > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > > > = ---------------------------------------------------------------------- > > > > Revision 221023 - (view) (download) (annotate) - [select for diffs] > > Modified Mon Apr 25 17:13:40 2011 UTC (3 years, 2 months ago) by > > attilio File length: 106717 byte(s) Diff to previous 220560 Add the > > possibility to verify MD5 hash of incoming TCP packets. > > As long as this is a costy function, even when compiled in (along = with > > the option TCP_SIGNATURE), it can be disabled via the > > net.inet.tcp.signature_verify_input sysctl. > > > > Sponsored by: Sandvine Incorporated > > Reviewed by: emaste, bz > > MFC after: 2 weeks > > > > I stand corrected. Excellent news ( for me, that is) :) >=20 > Best regards > Andeas > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 18:07:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F8B5B74; Mon, 21 Jul 2014 18:07:19 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (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 C3E7722F2; Mon, 21 Jul 2014 18:07:18 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 0B66D6A6017; Mon, 21 Jul 2014 20:07:15 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s6LI7E2w012621; Mon, 21 Jul 2014 20:07:14 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s6LI7E11011400; Mon, 21 Jul 2014 20:07:14 +0200 (CEST) (envelope-from lars) Date: Mon, 21 Jul 2014 20:07:14 +0200 From: Lars Engels To: Adrian Chadd Subject: Re: [PATCHES] Extend service(8) and rc(8) was: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? Message-ID: <20140721180714.GJ96250@e-new.0x20.net> Mail-Followup-To: Lars Engels , Adrian Chadd , freebsd-current Current , freebsd-rc@freebsd.org, bapt@freebsd.org References: <53C82EC4.8060304@gmail.com> <20140718142835.GF96250@e-new.0x20.net> <20140719160809.GU96250@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Or+E1gVcyGxE6cpa" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: bapt@freebsd.org, freebsd-current Current , freebsd-rc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:07:19 -0000 --Or+E1gVcyGxE6cpa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 19, 2014 at 12:56:42PM -0700, Adrian Chadd wrote: > Hi! >=20 > I like it! It's a useful command line API. >=20 > Eventually people will realise there needs to be a more formal method > for describing/controlling the underlying framework, but I leave that > up to bapt to figure out and .. well, push people to do. :) >=20 > Thanks! >=20 >=20 >=20 > -a >=20 [CC trimmed] I added a -s flag to allow the usage of /etc/rc.conf.d/$script for use with puppet, etc. https://phabric.freebsd.org/D451 --Or+E1gVcyGxE6cpa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJTzVbSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tTfoH/0Y2M1serEnPfrGgXbLI/qWk YkG3IK5ipcqCFh+khDEuFuax7VRjMqZLJMGZUPuRwaRed2T7ah9MFViY0xPxMJ/z bIVTAgjanbPYTG37d4c1DiROIa8IMyLftjgW0a91UwaVD830yy+xYyUQNCTvqyV5 r30kYBgQKIzSZ6XKgLqjKBBYXecoWSbv8IOyr6UMjp/v3qHdVNEcJXVjLtalKPb3 16vIRAJMS02uPqDO08sjSksLv5ffS4mubzu07QeB3VDEYBgMj60005/q23970B4Z hbDkn5G4tp0cPI+Xrr6F6sVOdpCShmNRal7cCyIyRifLpi3LEImKdwO9JH2658w= =G4r8 -----END PGP SIGNATURE----- --Or+E1gVcyGxE6cpa-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 20:30:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52068172 for ; Mon, 21 Jul 2014 20:30:07 +0000 (UTC) Received: from caprica.ketralnis.com (caprica.ketralnis.com [184.73.185.184]) (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 2809C201F for ; Mon, 21 Jul 2014 20:30:06 +0000 (UTC) Received: from [10.0.15.252] (108-60-121-46.static.wiline.com [108.60.121.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dking) by caprica.ketralnis.com (Postfix) with ESMTPSA id 4ABDE1BACDF; Mon, 21 Jul 2014 13:11:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C498E68B-29FF-4171-8057-E6A8EE70AFF5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI From: David King In-Reply-To: <53CBEC26.7080404@icloud.com> Date: Mon, 21 Jul 2014 13:11:22 -0700 Message-Id: <2AE1EED7-8E9C-47EC-8AED-CDF446260E94@ketralnis.com> References: <53CBEC26.7080404@icloud.com> To: Anders Bolt-Evensen X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:30:07 -0000 --Apple-Mail=_C498E68B-29FF-4171-8057-E6A8EE70AFF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Last week, I created a custom ISO from the latest -CURRENT sources = which contained an EFI image that is bootable on my MacBook Pro. > Both installation and booting from this new FreeBSD 11 EFI system goes = without any problems. Somewhat off-topic, but can you detail how you did this? I've been at = this unsuccessfully. Did you just do this = ? --Apple-Mail=_C498E68B-29FF-4171-8057-E6A8EE70AFF5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTzXPrAAoJEFrLaEb73SmzzNEP+gIRldK4SpBQB1g6ZFa9YF2f tWDCpL81WsEqwwA3Ocfo4YCMM+A1Mg0f5JIzaCJu+2xgPuvGtijL79JaqCX+e4cp qJON6vPF++bDxzeHg1rrML/3V2D0MA+ybOnlXE9ebtNebWt6FxpwH+Fy7vXxZgnF osHNK3cRjvAX0UjbSY8960zBs1ZuGvh4OIRYh94tz8Q2TAlM8oz2kd/e6odAPt85 +rpchD3VwA2+W0WSi+ELvFN6tGlqZduIKxWXtcV320WPl/6pHPlS91NwmPp++/LH OewwvD63Fzgqx5vvgDQqWWVzR7Rh1XAa5pSAJvATfibS4wvkKriFUDIRXLOdZyRs w/Ff07Kx6fBauh/xWlm2Ij5as+WRhm5OyaWHeICgsF9rclzy1ajB6Gfu6s0b0O2X Kn0dfDnilltgptK0QdVsKnwFlc0RCp02gwen38iXXO1DvaKhgxIo9aIWAs0wIDi+ MDF5VmLl9gCx13fwgvnvie2fh7awXt5l/+ian3R3boPPurlTi09TVRDpu5X9PdVJ F8xkhmxTx/cVSHvFkf68jiXw/LlZ8GZtxyZ/ycETy0c2Y+WFttyPW+JdSWob/zwT xZ3sS1jzAvO7nHp9s4vSEPWlZAeLtdWdH6nhMvMrhvjFg1cSrpKaBDv5fgeNXCAO 0FFVB7UzUZS59jyu7Xsh =A2L0 -----END PGP SIGNATURE----- --Apple-Mail=_C498E68B-29FF-4171-8057-E6A8EE70AFF5-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 21:48:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC6A5A91; Mon, 21 Jul 2014 21:48:57 +0000 (UTC) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) by mx1.freebsd.org (Postfix) with ESMTP id 67104282B; Mon, 21 Jul 2014 21:48:56 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 836B7A5A616B; Mon, 21 Jul 2014 23:48:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIawy4D6KVv1; Mon, 21 Jul 2014 23:48:49 +0200 (CEST) Received: from [192.168.0.11] (95-91-254-222-dynip.superkabel.de [95.91.254.222]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 059E0A5A6169; Mon, 21 Jul 2014 23:48:48 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Franco Fichtner In-Reply-To: <53CC85E2.1030606@freebsd.org> Date: Mon, 21 Jul 2014 23:48:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <53CC85E2.1030606@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1878.6) Cc: "Kristian K. Nielsen" , freebsd-current@freebsd.org, Darren Pilgrim , freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:48:57 -0000 Hi Julian, On 21 Jul 2014, at 05:15, Julian Elischer wrote: > Most people I talk to just use ipfw and couldn't care whether pf lives = or dies. They have simple requirements and almost any filter would = suffice. I haven't found anything I'd want to use pf for that ipfw = doesn't allow me to do. There are things pf does that ipfw doesn't... I = just never want them.. this is quite insightful. The gist of this discussion and the apparent lack of upgrades to pf(4) seem to indicate that: (a) other packet filters do the required jobs equally or better or performance doesn't matter at all. (b) for more progressive setups and requirements, FreeBSD servers may as well be complemented with commercial firewalls, hand-rolled or non-FreeBSD solutions Is that somewhat accurate, or is there more to the story? Cheers, Franco= From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 22:35:07 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 089A83E9 for ; Mon, 21 Jul 2014 22:35:07 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 9E2022C4D for ; Mon, 21 Jul 2014 22:35:06 +0000 (UTC) X-AuditID: 1209190d-f79c06d000002f07-56-53cd95931cbf Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B7.83.12039.3959DC35; Mon, 21 Jul 2014 18:34:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s6LMYwWR032683 for ; Mon, 21 Jul 2014 18:34:59 -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 s6LMYvZI001765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Jul 2014 18:34:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6LMYu64025112; Mon, 21 Jul 2014 18:34:56 -0400 (EDT) Date: Mon, 21 Jul 2014 18:34:56 -0400 (EDT) From: Benjamin Kaduk To: current@freebsd.org Subject: clang assertion failure+coredump in clang 3.4.1 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixG6nojt56tlgg45D0hYTrvxgcmD0mPFp PksAYxSXTUpqTmZZapG+XQJXxqOZ/1kLnrNWXGy/zNTA+Iqli5GTQ0LARGJzaxcrhC0mceHe erYuRi4OIYHZTBL9u56xQjinGSXOPD/LDuHcYZK4ObmLGcJpYJTY/nUZG0g/i4C2xMdNjWBz 2QRUJGa+2QgWFxEQl/i9s4cRxBYWsJDo238VqJmDg1fAUeJnhxhIWFRAR2L1/ilgrbwCghIn Zz4Bs5kFLCX+rf3FOoGRbxaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0 UlNKNzGCwolTkncH47uDSocYBTgYlXh4LeTPBguxJpYVV+YeYpTkYFIS5X0+CSjEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhPdLM1CONyWxsiq1KB8mJc3BoiTO+9baKlhIID2xJDU7NbUgtQgm K8PBoSTBGz0FqFGwKDU9tSItM6cEIc3EwQkynAdouDlIDW9xQWJucWY6RP4Uoy7Hov0vu5mE WPLy81KlxHlVQYoEQIoySvPg5sDSwCtGcaC3hHnjQKp4gCkEbtIroCVMQEuKMk+DLClJREhJ NTCGz8n/M23yndvxC41Vfj7R4nv0ssEwnmfjTAatK+wBMwXWKnIm1E5xUpvG9yFrtueKNz1O rMHHTzzbvdv58Y0zd/3m1F4xD7IrrZ7F3WnXuc5mI+dUMSV3zd1cC2+XlGsKb/mx/MmUvsQe n7rA/9XNBt33ypLfBxfOq9ed/XHZt+wJzXt+tlxUYinOSDTUYi4qTgQALW/qxN4CAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:35:07 -0000 Building some out-of-tree software with a rather long set of compiler flags, I can reliably get our clang to crash. The system is current as of r267362 (June 11), with clang reporting itself as FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd11.0 (freefall's clang crashes as well.) Unfortunately, I don't have debug symbols around for that clang binary. If someone does have a clang with debug symbols handy, I'd be interested in seeing the backtrace. The processed source file and invocation shell script may be found at: http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.c (1.1M) http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.sh Thanks, Ben From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 23:12:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E9C8378 for ; Mon, 21 Jul 2014 23:12:58 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 74C0E2F8B for ; Mon, 21 Jul 2014 23:12:57 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 847B02A40C for ; Mon, 21 Jul 2014 23:12:50 +0000 (UTC) Message-ID: <53CD9E79.2060201@freebsd.org> Date: Mon, 21 Jul 2014 19:12:57 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <20140721.074105.74747815.sthaug@nethelp.no> <20140721.085616.74744313.sthaug@nethelp.no> <002601cfa4eb$b4554270$1cffc750$@gmail.com> In-Reply-To: <002601cfa4eb$b4554270$1cffc750$@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xUDRlQDDH6xi727ijkBBNQEHuJgM2LNO2" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 23:12:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xUDRlQDDH6xi727ijkBBNQEHuJgM2LNO2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-21 09:57, bycn82 wrote: > There is no doubt that PF is a really good firewall, But we should noti= ced that there is an ipfw which is originally from FreeBSD while PF is fr= om OpenBSD. >=20 > If there is a requirement that PF can meet but ipfw cannot, then I thin= k it is better to improve the ipfw. But if you just like the PF style, th= en I think choose OpenBSD is the better solution. Actually OpenBSD is ano= ther really good operating system.=20 >=20 > Like myself, I like CentOS and ipfw, so no choice :) >=20 >=20 The only thing I've really found lacking in IPFW is the NAT implementation. Specifically, when trying to do port-forwarding. All of the rules have to go in the single 'ipfw nat' rule, and it makes it cumbersome to manage. --=20 Allan Jude --xUDRlQDDH6xi727ijkBBNQEHuJgM2LNO2 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTzZ58AAoJEJrBFpNRJZKf8uIP/3uC9OWrHJ/IBLEcDRjqFUzs a6vT3EiqtcmGBdpgBfnL9E2XdAGkxNG3ZeUIYatG+QkBrctpG25+0+O+z3Da5SZB MgD+nxnET/ygBOKzr1D3uZ8T6nubVdDy7A4/luFwi7yJc8CJwx9pNQZwNDuaEHnL sHkzUJfEyiymZOYmWY4IntZyakYVPAb9ViwL3drWl+jR04MfyVJJ8ZwWzQBk91F7 OzYIO1lg7ibG2UvDnA2itCYqKiL8P6w4tPwdmBdQVeVzb8IbJuQ9qjXIwLTaPm4z PTj4AjNI1BkRmhUDDp4KTth0KflKHPnPokVOlqu6Vy5Rv++3OnfjD8xJKrTjKaNR fgTyoCVBsD964DN0t4ljplN2h5kL4GWeYHIE1YgWNM+Eghgq1m+bOCWah/FEUzK4 ea2V5Jy+7RZQnsFYTQnH7Psav3oFydS03aQ1xdICvvkQQxqzWPEM0VUDYo9ywJIo DhIBbtey9nlRtvzKNEjxcXgrHBDLsYt7+C/yuEIptB0KSBBNxvNDOtNch+1W8hN5 v6b0+IGv/FLWYlkpN/AEtyvsSIRsoM2mHRaA4DQi58RYEg896rNqwkKBiLN+jwW5 gO5wsEDNaCANFnBcaYnMWjAmVZ3UqoYAA7Jh5ho20ljiv7KN75+wVUhLyjurVN+J IZ8jMAslUGDexP9vbKh6 =avBf -----END PGP SIGNATURE----- --xUDRlQDDH6xi727ijkBBNQEHuJgM2LNO2-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 04:15:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF0B0C21 for ; Tue, 22 Jul 2014 04:15:56 +0000 (UTC) Received: from nm46-vm10.bullet.mail.bf1.yahoo.com (nm46-vm10.bullet.mail.bf1.yahoo.com [216.109.114.203]) (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 930AF2696 for ; Tue, 22 Jul 2014 04:15:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1406002549; bh=SXbcofh9XL4S9ymEEaRDvHAkgkprFIRlAyjlxdGKgmE=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id:Date:To:Mime-Version:X-Mailer; b=r0L5T/prJ3Q/l89RvC0RmHLelrrgmWQJU/VpH64KTxYd+ybvStTEqgaI2xKnbzctGdY7QEUfiSuyeuH7Tsd5VNgZ9Ck8hX0BqKEoTd7nJOQ0zkmBX4CgoAV1c0hPe+xCIMnQ2NuoqnKU664BAR9Jk/8k5S5o/zoXzKCFsoR0+8jq2N4/fYdBj2WzvuqMzCUwtjhryCoPzrCGcI0Lj4lFfIZK3FEbodb0i1XnaQswiFT4lndH3sVyqWUCL9ajsMH8OXRNIJf2cMYNeaMT4Nk2obefsXLW0OwtAqJv5xdWCxr4SpksRNVnbnKwvsb8FVtol4Qi4kiaJtI7kKDtEmlb0Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=TFTm6Ks2exU5pDST/h5KW+QjtiLAO97E5N924MViLyesnByUZ36JD0Y27H4Fxqovj3mfLSwxIKAgDU0OWoZUvzbo7UFS5KxX32knnEMHFaVQDN6miAANbSK7L5IiihBLihgPabVQXcZziIMlzdEiApD6s8aSepBA1llFw/elYKw56nwmbfyE2vRRgkdC9VdImOnZi1M4M4h/NrJKwBf38ZRQlIgX3eru9NjH9YFbMNq3gQHU+4nrkOkAqhjcyziDtMr1wg/noUCpz11f2nypXW1HgOEjcl2O84QaolagfsAWztM6o9hsStBBC30K6EOZn6vQ7XY+xvtE72tS5sbHUQ==; Received: from [98.139.215.142] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2014 04:15:49 -0000 Received: from [68.142.230.65] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2014 04:15:49 -0000 Received: from [127.0.0.1] by smtp222.mail.bf1.yahoo.com with NNFMP; 22 Jul 2014 04:15:49 -0000 X-Yahoo-Newman-Id: 220646.67114.bm@smtp222.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DRZdfdUVM1lojDnPE1OQk_yrwwYT67lGDMzcbQq0EOzXmkl mSIYMIMlMyhYlwJSSy6VhzFTchICLrrfrsN4OaTJ2Z75uqKSDzs4ZNSPEXMl mfOsinu46PZMzmjYRz2LgRCQYs5yKEi.QdE2abgBo_LfM.cKhYJmfr79BGNm 6cU.Ly3Y1wLqpSFtln2DqM8oagAaHWe72Q4T6WDCWBT__IYmJvFnskk0UXlA 7zhQr7tvx094I63RGXGHO5JmtALDBDcj_G2R9BAyS5rL3tRJBrdqWveVV7dV 0bgOTjLMpkHwXNLKAHU5zRtB8qOMdtMWcbTMkE21gaCFsSumxDiYlTMapjQi zWGUHGO_C4Pbg8T_wLSIqg.mp1KDmYtZe_wlWHiEf3MVfSqEj4KMswiLWb3x Gk4xVRVpy2QOXk4VpOWTfPeJnl0mWvbIdPyuA_fUDMyoUuMPR..lWVHTxzMJ I46mZYSTr9PK_dxP9UW8uEORyBevnz433t0BbiqPLa4EHv0JMfXo6CS5PVOE MQocr5TV1xgdrQ1tftbeSVhhpvoEbDCiNwnNlnY9zi1cHEh0h4RciAe5Y.GP K5XkMmZ0pLO_y9pOBV90cO5t5YdkEbjE5_kNZq0echkMf7g-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf From: Pedro Giffuni Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: NPF (was Re: Future of pf / firewall in FreeBSD ? - does it have one ?) Message-Id: Date: Mon, 21 Jul 2014 23:15:47 -0500 To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 04:15:57 -0000 FWIW, and while I still wonder why we need three packet filters =85 There is yet another firewall implementation in NetBSD: http://www.netbsd.org/~rmind/npf/ It seems to be more portable, it is thought with SMP-friendliness in = mind and according to a EuroBSDCon talk ports for FreeBSD and Illumos = were being considered. Good to have more options =85 I think. Pedro.=20 From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 05:02:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C6F06F5; Tue, 22 Jul 2014 05:02:32 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 67EF72A47; Tue, 22 Jul 2014 05:02:32 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id bj1so11110125pad.25 for ; Mon, 21 Jul 2014 22:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=VbsV4FOr4jLhRlKe48QH2hLNi2xecU6aJdO5sUZy6eE=; b=pjdd0KPHLZd1VeC46Furi/4s+9NJkrBU1xurfrRLWtmsghTUfD8El2Xm2yonL7ZLET PEY4ATvgxJkQWstsS4Q5+4BMUzPDdzd92fz9WRK6HrgwrasLmtSvZlt2r3FsV59TJoAh wSOiTETid6eWSWggKrWahboU+BczD1N+KtmKM8VW6ppqzHggXom3Mf3ybmgQUKsgJzkq s/onD0pNSLdxZYY03DiMYvrWnUw7Let+cNvAwCiz30q/k7wW5T24TGpHXaHdmUcos9PZ Pi7/S/1xu/DrHlGteuvt0o9hrKxvlrPdaRDk8rz3g7jCtoERLBS/G79y1RAu9CtvYL3f 26NQ== X-Received: by 10.68.94.130 with SMTP id dc2mr13733790pbb.113.1406005351491; Mon, 21 Jul 2014 22:02:31 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id qp12sm21476221pdb.82.2014.07.21.22.02.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Jul 2014 22:02:30 -0700 (PDT) From: "bycn82" To: "'Allan Jude'" , References: <20140721.074105.74747815.sthaug@nethelp.no> <20140721.085616.74744313.sthaug@nethelp.no> <002601cfa4eb$b4554270$1cffc750$@gmail.com> <53CD9E79.2060201@freebsd.org> In-Reply-To: <53CD9E79.2060201@freebsd.org> Subject: RE: Future of pf / firewall in FreeBSD ? - does it have one ? Date: Tue, 22 Jul 2014 13:02:26 +0800 Message-ID: <002e01cfa56a$23ef3770$6bcda650$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/50tpYfGwpMKNeBPkSOvXVI/2jQIrBaeAAroD+/YB+jKkdAEPYalNAYsix1gB0e/oQZpwoOLg Content-Language: en-us X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 05:02:32 -0000 i thought the nat in ipfw is as elegant as in iptables :) but it is good to know that because different opinion actually is a = chance to improve. and why not share with us why the ipfw nat is cumbersome or how to be = not cumbersome. > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Allan Jude > Sent: 22 July, 2014 7:13 > To: freebsd-current@freebsd.org > Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? >=20 > On 2014-07-21 09:57, bycn82 wrote: > > There is no doubt that PF is a really good firewall, But we should > noticed that there is an ipfw which is originally from FreeBSD while = PF > is from OpenBSD. > > > > If there is a requirement that PF can meet but ipfw cannot, then I > think it is better to improve the ipfw. But if you just like the PF > style, then I think choose OpenBSD is the better solution. Actually > OpenBSD is another really good operating system. > > > > Like myself, I like CentOS and ipfw, so no choice :) > > > > >=20 > The only thing I've really found lacking in IPFW is the NAT > implementation. Specifically, when trying to do port-forwarding. All = of > the rules have to go in the single 'ipfw nat' rule, and it makes it > cumbersome to manage. >=20 >=20 > -- > Allan Jude From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 09:01:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82679B00; Tue, 22 Jul 2014 09:01:32 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 646FB2DB5; Tue, 22 Jul 2014 09:01:31 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id EFC4F20C28; Tue, 22 Jul 2014 02:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1406019685; bh=E6El0jzCY+2R5XIxs+O3ctese7mggqNYm/SwU3b6MdE=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=aD9DOk/AejvqxjM8HXEqs2LJXmK1nBA90mE1vZAFPiCgrxc3lQRmliMf9u40sxsAk wk6vCyV+k1PXw0oi3PPuxG2lXXItfhM5A9nbQlnKHNiobzNS+3C9R9s7npTH0tbeIu gPC4Esz5gv1fjXj/8bj4ZT15+frsAu//b+LBZcHY= Message-ID: <53CE2863.6070804@delphij.net> Date: Tue, 22 Jul 2014 02:01:23 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Florian Smeets , Steven Hartland , Larry Rosenman Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> <53CCA40B.10503@smeets.im> In-Reply-To: <53CCA40B.10503@smeets.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 09:01:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I think this is my stupid. Feeling ashamed. Please try r268980+ and report back if it's fixed or not, thanks! Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTzihjAAoJEJW2GBstM+ns2esP/3zfORqtE11QeveWI8wBzHav Pl4A3V8kgi8FHP8m33gim1yAERpqf2+WgYuAjUNloFrFD9JCslnnoGtk9yiaOH2N Y7SJMYfvYkZ50upGE+fJKAcpH3QxLuEpSIlaFMkvA9oXtAiZEJ+BYBJh8VFWFXIs +bnqY0Mba7T574oqw8KcEysdYYDqSVd4/M/HBUdDTWT0/ZgeStJZw9MKPiSYFJcK PvV9dglPZ08L+Ra7cqu/EtC93p9IxVtfqxMlNkhMeVkQt+0jMKzHgDZ0dg9j7AVn SA9e+YvE9Sg2riE6XT2iF9B8Z4vDFf5/8CGtpBpKrB4861bcctdgJ3LIJBdDsz9N lOCjWXc4Amv8GVpTKPKaAGxeGPeN52Drqd2pD1ljLLENJsBZ3WOdMjt/R4VhpLVl 9LuXNFZ8oQy/PqVxHhYWYOOuqcFQnexB/5Qdmic3grIC/fwELbQwEK+34md5q4iJ pvy34RzzZrA1pVRfBM2oQ0TnABrdA7+bsb44DLvkPHmVGxPPZdN7QUfVzIrbCNe9 apBkLk/Qx2kOtpuAe6xBxhaOZEAJ9Q26Souew1HOYDSAusyCETB5+tfp1hl7R0ic xdL4YjSq9FPKOyYATCBh8/F0f2hVPC3mB2SmDz9PvI1+POWHae1tpeSCGonoc3A+ DCOLXRPNLbyZyrxTUtXG =NzT+ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 15:45:11 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86643F09 for ; Tue, 22 Jul 2014 15:45:11 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 6891E243A for ; Tue, 22 Jul 2014 15:45:11 +0000 (UTC) Received: from [192.168.200.205] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 34D7F193A3A for ; Tue, 22 Jul 2014 15:45:09 +0000 (UTC) Subject: libstand modification From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-current Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jul 2014 08:45:07 -0700 Message-ID: <1406043907.1063.27.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:45:11 -0000 https://phabric.freebsd.org/D443 the 64bit version of userboot has been screaming about bit shifting operators for a while now. The short explanation, amd64 sizeof(long) != i386 sizeof(long). The long explanation is in the phabric diff and comments. I see no reason to not commit this, but thought I'd throw it here for your commentary. sean From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 17:17:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F08682E; Tue, 22 Jul 2014 17:17:14 +0000 (UTC) Received: from mail-out.smeets.im (mail-out.smeets.im [IPv6:2a01:4f8:160:918a::25:11]) (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 C63872DF2; Tue, 22 Jul 2014 17:17:13 +0000 (UTC) Received: from mail.smeets.im (mail.smeets.im [IPv6:2a01:4f8:160:918a::25:3]) by mail-out.smeets.im (Postfix) with ESMTP id 794F52E3; Tue, 22 Jul 2014 19:17:11 +0200 (CEST) Received: from amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) by mail.smeets.im (Postfix) with ESMTP id 94062892A6; Tue, 22 Jul 2014 19:17:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.im Received: from mail.smeets.im ([IPv6:2a01:4f8:160:918a::25:3]) by amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) (amavisd-new, port 10025) with ESMTP id XwP8E9IN_h3g; Tue, 22 Jul 2014 19:17:10 +0200 (CEST) Received: from nibbler-wlan.home.lan (unknown [IPv6:2001:4dd0:fd65:d00d:80b2:e702:7dad:6da2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smeets.im (Postfix) with ESMTPSA id 0718A8928B; Tue, 22 Jul 2014 19:17:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=smeets.im; s=default; t=1406049430; bh=qgI0D2vjYgwQmsJadUr4U1iyHCOTVABaj/k07hjjF1w=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=4QEVdmU9w/zduoYw+4RPD231Q3YnBJ4DTUWEEXarjQMwnDmraDo80VGhBIUzKmlAR CjX7TOHzVwVqHBnngg2XfiGws3pyAGGzHX4L8gEvsoymShsbkb1KeGHyTu3FA/ejlZ OGK3Dm5L61yqhabaVBuKYQxxVgcz6QnpYRHEx7EI= Message-ID: <53CE9C8F.6040609@smeets.im> Date: Tue, 22 Jul 2014 19:17:03 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Larry Rosenman , freebsd-fs@freebsd.org, Steven Hartland Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 References: <20140720140350.GA8498@borg.lerctr.org> In-Reply-To: <20140720140350.GA8498@borg.lerctr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3PTfihOS3p7SB7AkC9VroxOWxd5JlU3r4" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:17:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3PTfihOS3p7SB7AkC9VroxOWxd5JlU3r4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20/07/14 16:03, Larry Rosenman wrote: >=20 > panic: solaris assert: !(zio->io_flags & ZIO_FLAG_DELEGATED), file: > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: > 2874 >=20 This was fixed by r268980. Florian --3PTfihOS3p7SB7AkC9VroxOWxd5JlU3r4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzpyUAAoJEOcFPfn/hvB2A8IQAOOI3f9sATLFbtKQdsTnURNh 8INu8rnoOY+tTw7MaaGfLBBDxdDqV1hEbZapRo5KqGozbmCUNJSCCA+rlIXw2vNr bUl4ApIiKZTQaiHlMu0mILYjD9cajw7dTQcO457T2ItOUjU8xltROlHKX/QNHGkd 7b3aj0ZX8+aAfCfGkRIrvx9ffkppucAHnK5AqdhQaM+Nk/oZ+9fVIuUDuIF6WxoD wewS41TAIbU9NihXCDNT79jmL7tSh6fkN4Nn3lG+XWn8ijJvrq7isteVcopxctci sL0DSj+oZ5maWyoM8nxGyVJ7ioL8uQiw4D3pUfQnwTsJaUJCYFT4Uk0sHm9iwXOt 1gzxByr0dYwsXEIaGgNfi17jRAmp13mGS3YteA2jUM+pUwe0Rvj3YTNKPacNaOSd Lq9CBpQKBJDEhI3w1Yt/7jnxo/goXByfHqfvek3LX12AZdBpGpkOdtNjigjhJPrN 5miT55pNq9An8tb/NTJGvM9HKDFIF4h0oqGrzIfXBtFcaK/TLNu2RMro0k0IcK53 ApM0sBUjtvjd39NgHTugwBxk90IkuPt5TuaYM6jOkmSZ+ZYBq/a3PF5wF6W1rTeZ 1qa/2tcAvNbCmbp9DOCqiv1mY226MwFsklfjzdmd3mmnzT7ytxKlckI//+qbk6Bi CPtqT52WXX7sBz4EOs9L =cNYC -----END PGP SIGNATURE----- --3PTfihOS3p7SB7AkC9VroxOWxd5JlU3r4-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 17:53:01 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CDC8BB5 for ; Tue, 22 Jul 2014 17:53:01 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4D9832192 for ; Tue, 22 Jul 2014 17:53:00 +0000 (UTC) Received: from [192.168.200.205] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 3CFDC193A3A for ; Tue, 22 Jul 2014 17:52:59 +0000 (UTC) Subject: sys/boot unbuildable From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-current Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jul 2014 10:52:58 -0700 Message-ID: <1406051578.1063.33.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:53:01 -0000 I can't quite see what the difference in building sys/i386/loader and sys/i386/zfsloader is outside of the obvious zfs loader support flag. But, loader will build, and zfsloader will not. Clang will give me a nice error that tells me how I could fix this, but since loader builds fine I suspect something buildsystem related is occuring here? cc -O2 -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../ficl -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../common -I. -Wall -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/.. -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../btx/lib -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -std=gnu99 -Qunused-arguments -DLOADER_PREFER_AMD64 -c /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../loader/main.c /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../loader/main.c:38:10: error: 'machine/bootinfo.h' file not found with include; use "quotes" instead #include ^~~~~~~~~~~~~~~~~~~~ "machine/bootinfo.h" 1 error generated. *** Error code 1 Stop. make: stopped in /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 18:55:45 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8454634 for ; Tue, 22 Jul 2014 18:55:45 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 73E082808 for ; Tue, 22 Jul 2014 18:55:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::2086:61ad:9e0a:a6e6] (unknown [IPv6:2001:7b8:3a7:0:2086:61ad:9e0a:a6e6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7B16C5C44; Tue, 22 Jul 2014 20:55:41 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_08F327A9-57DC-458C-AC89-225F88AA0AEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: clang assertion failure+coredump in clang 3.4.1 From: Dimitry Andric In-Reply-To: Date: Tue, 22 Jul 2014 20:55:27 +0200 Message-Id: <8B11DC31-9BAC-4C46-89C7-8F13ABCCD07D@FreeBSD.org> References: To: Benjamin Kaduk X-Mailer: Apple Mail (2.1878.6) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:55:45 -0000 --Apple-Mail=_08F327A9-57DC-458C-AC89-225F88AA0AEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Jul 2014, at 00:34, Benjamin Kaduk wrote: > Building some out-of-tree software with a rather long set of compiler = flags, I can reliably get our clang to crash. > The system is current as of r267362 (June 11), with clang reporting = itself as FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final = 208032) 20140512 > Target: x86_64-unknown-freebsd11.0 > (freefall's clang crashes as well.) >=20 > Unfortunately, I don't have debug symbols around for that clang = binary. > If someone does have a clang with debug symbols handy, I'd be = interested in seeing the backtrace. >=20 > The processed source file and invocation shell script may be found at: > http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.c (1.1M) > http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.sh Hi Ben, I was able to reproduce the assertion, even with clang trunk. It is apparently caused by the implementation of the -Wconsumed warning, which is enabled in your case because you had used -Weverything. I have reported an upstream bug with a reduced test case here: http://llvm.org/PR20402 Meanwhile, you can work around the assertion by adding -Wno-consumed to your compilation flags. -Dimitry --Apple-Mail=_08F327A9-57DC-458C-AC89-225F88AA0AEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlPOs6oACgkQsF6jCi4glqN+uwCg9X2ufyvW0ECzd9iaAYVQVsKQ h+UAoM5WYdLcw6sY5pXiey7CSbnc6giy =T0aB -----END PGP SIGNATURE----- --Apple-Mail=_08F327A9-57DC-458C-AC89-225F88AA0AEC-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 19:06:03 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B2FBE4; Tue, 22 Jul 2014 19:06:03 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 2B1DF2927; Tue, 22 Jul 2014 19:06:02 +0000 (UTC) X-AuditID: 1209190d-f79c06d000002f07-27-53ceb619e14e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id EE.15.12039.916BEC35; Tue, 22 Jul 2014 15:06:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s6MJ60Lq011004; Tue, 22 Jul 2014 15:06:00 -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 s6MJ5wNv011675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Jul 2014 15:06:00 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6MJ5wpQ029211; Tue, 22 Jul 2014 15:05:58 -0400 (EDT) Date: Tue, 22 Jul 2014 15:05:58 -0400 (EDT) From: Benjamin Kaduk To: Dimitry Andric Subject: Re: clang assertion failure+coredump in clang 3.4.1 In-Reply-To: <8B11DC31-9BAC-4C46-89C7-8F13ABCCD07D@FreeBSD.org> Message-ID: References: <8B11DC31-9BAC-4C46-89C7-8F13ABCCD07D@FreeBSD.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixG6nriu57Vywwby1fBYTrvxgsljStY/R gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZz2cHFCzlq+j9KtHAeIa7i5GDQ0LAROL4CY0uRk4g U0ziwr31bF2MXBxCArOZJLrW/oRyNjJKvPl/hh3COcQkcWzyQSingVHi7PN9zCD9LALaEm/6 dzOB2GwCKhIz32xkA7FFgOyPz9rZQNYxC4hLvOxXAgkLC9hIdOz9BVbOKWAv8e/mX0YQm1fA UeLl44NgrUICJRKn1m9gB7FFBXQkVu+fwgJRIyhxcuYTMJtZwFLi3J/rbBMYBWchSc1CklrA yLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10gvN7NELzWldBMjKDQ5JXl3ML47qHSIUYCDUYmH t6DmXLAQa2JZcWXuIUZJDiYlUd66tUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzRrUA53pTE yqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IE75stQI2CRanpqRVpmTklCGkm Dk6Q4TxAw8FqeIsLEnOLM9Mh8qcYFaXEeblBEgIgiYzSPLheWOp4xSgO9Iowr+hWoCoeYNqB 634FNJgJaHBR5mmQwSWJCCmpBkanpRt0n86qvn3sWsv3s2kl/ye8X8tYcaCSa961SOfVUS7y M8P2vbHmW33vUnxedejnfxcnMfNLX7ORq8wM4rxfZLh28zX2Gzv6+lWdjgZtOrLhRrhLbeHs oy5lS0U2qId0F8qXdIVvkDOQmac9I/3k9p6ODUuOd7Q7sN2tdp3p37fb8/eq1GtKLMUZiYZa zEXFiQCA4e+k+AIAAA== Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:06:03 -0000 Hi Dimitry, On Tue, 22 Jul 2014, Dimitry Andric wrote: > On 22 Jul 2014, at 00:34, Benjamin Kaduk wrote: >> Building some out-of-tree software with a rather long set of compiler flags, I can reliably get our clang to crash. >> The system is current as of r267362 (June 11), with clang reporting itself as FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >> Target: x86_64-unknown-freebsd11.0 >> (freefall's clang crashes as well.) >> >> Unfortunately, I don't have debug symbols around for that clang binary. >> If someone does have a clang with debug symbols handy, I'd be interested in seeing the backtrace. >> >> The processed source file and invocation shell script may be found at: >> http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.c (1.1M) >> http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.sh > > Hi Ben, > > I was able to reproduce the assertion, even with clang trunk. It is > apparently caused by the implementation of the -Wconsumed warning, which > is enabled in your case because you had used -Weverything. > > I have reported an upstream bug with a reduced test case here: > > http://llvm.org/PR20402 Thank you very much! I was planning to try to reproduce on clang trunk and reduce the test case, but I think you are much more practiced at doing so than I am ;) > Meanwhile, you can work around the assertion by adding -Wno-consumed to > your compilation flags. I will do so, thanks. As you may have guessed from the compiler command line, I'm enabled -Weverything for development and am disabling the pieces that cause annoyance and/or too much spew. The openafs build system interacts in an exciting way with bsd.kmod.mk, passing through my -Weverything and also taking the kernel's -Werror... -Ben From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 21:07:46 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34EEA542 for ; Tue, 22 Jul 2014 21:07:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 02567266E for ; Tue, 22 Jul 2014 21:07:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s6ML7jlY020040 for ; Tue, 22 Jul 2014 21:07:45 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s6ML7jUe020038 for current@FreeBSD.org; Tue, 22 Jul 2014 21:07:45 GMT (envelope-from bdrewery) Received: (qmail 57737 invoked from network); 22 Jul 2014 16:07:44 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@67.182.131.225) by sweb.xzibition.com with ESMTPA; 22 Jul 2014 16:07:44 -0500 Message-ID: <53CED29F.1090809@FreeBSD.org> Date: Tue, 22 Jul 2014 14:07:43 -0700 From: Bryan Drewery Organization: FreeBSD 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: current@FreeBSD.org Subject: Re: r268621: panic: shadowed tmpfs v_object References: <53CED27C.4080306@FreeBSD.org> In-Reply-To: <53CED27C.4080306@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:07:46 -0000 Meant to send to current@, moving there. On 7/22/14, 2:07 PM, Bryan Drewery wrote: > On r268621: > >> panic: shadowed tmpfs v_object 0xfffff807a7f96600 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe1247d67390 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 >> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 >> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 >> vm_object_deallocate() at vm_object_deallocate+0x236/frame >> 0xfffffe1247d67550 >> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 >> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 >> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 >> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 >> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 >> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 >> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0 >> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 >> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 >> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 >> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 >> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 >> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = >> 0x7fffffffe238, rbp = 0x7fffffffe710 --- >> Uptime: 6d4h0m3s >> >> Dump failed. Partition too small. > > Unfortunately I have no dump to debug. > -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 21:26:54 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ED49F2C for ; Tue, 22 Jul 2014 21:26:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 E96952883 for ; Tue, 22 Jul 2014 21:26:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s6MLQrKb027698 for ; Tue, 22 Jul 2014 21:26:53 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s6MLQr1j027697 for current@FreeBSD.org; Tue, 22 Jul 2014 21:26:53 GMT (envelope-from bdrewery) Received: (qmail 53567 invoked from network); 22 Jul 2014 16:26:49 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@67.182.131.225) by sweb.xzibition.com with ESMTPA; 22 Jul 2014 16:26:49 -0500 Message-ID: <53CED718.2090108@FreeBSD.org> Date: Tue, 22 Jul 2014 14:26:48 -0700 From: Bryan Drewery Organization: FreeBSD 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: current@FreeBSD.org Subject: Re: r268621: panic: shadowed tmpfs v_object [with dump] References: <53CED27C.4080306@FreeBSD.org> <53CED29F.1090809@FreeBSD.org> In-Reply-To: <53CED29F.1090809@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:26:54 -0000 On 7/22/14, 2:07 PM, Bryan Drewery wrote: > Meant to send to current@, moving there. > > On 7/22/14, 2:07 PM, Bryan Drewery wrote: >> On r268621: >> >>> panic: shadowed tmpfs v_object 0xfffff807a7f96600 >>> cpuid = 0 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe1247d67390 >>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 >>> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 >>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 >>> vm_object_deallocate() at vm_object_deallocate+0x236/frame >>> 0xfffffe1247d67550 >>> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 >>> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 >>> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 >>> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 >>> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 >>> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 >>> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0 >>> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 >>> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 >>> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 >>> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 >>> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 >>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 >>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 >>> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = >>> 0x7fffffffe238, rbp = 0x7fffffffe710 --- >>> Uptime: 6d4h0m3s >>> >>> Dump failed. Partition too small. >> >> Unfortunately I have no dump to debug. >> > Running poudriere again after boot hit the issue right away: > (kgdb) bt > #0 doadump (textdump=1) at pcpu.h:219 > #1 0xffffffff809122a7 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:445 > #2 0xffffffff809127e5 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744 > #3 0xffffffff80912679 in kassert_panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:632 > #4 0xffffffff80ba7996 in vm_object_deallocate (object= optimized out>) at /usr/src/sys/vm/vm_object.c:562 > #5 0xffffffff820a75a8 in tmpfs_free_node (tmp=0xfffff800b5155980, > node=0xfffff802716ba740) at > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335 > #6 0xffffffff820a363d in tmpfs_reclaim (v=) at > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276 > #7 0xffffffff80e48717 in VOP_RECLAIM_APV (vop=, > a=) at vnode_if.c:2017 > #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at vnode_if.h:830 > #9 0xffffffff809c18be in vrecycle (vp=0xfffff802716b61d8) at > /usr/src/sys/kern/vfs_subr.c:2655 > #10 0xffffffff820a61cc in tmpfs_inactive (v=) at > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242 > #11 0xffffffff80e485b7 in VOP_INACTIVE_APV (vop=, > a=) at vnode_if.c:1951 > #12 0xffffffff809bfd36 in vinactive (vp=0xfffff802716b61d8, > td=0xfffff80187e29920) at vnode_if.h:807 > #13 0xffffffff809c012a in vputx (vp=0xfffff802716b61d8, func=2) at > /usr/src/sys/kern/vfs_subr.c:2267 > #14 0xffffffff820a47c5 in tmpfs_rename (v=) at > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023 > #15 0xffffffff80e47d3c in VOP_RENAME_APV (vop=, > a=) at vnode_if.c:1544 > #16 0xffffffff809cc77f in kern_renameat (td=, > oldfd=, old=, newfd= optimized out>, new=, > pathseg=) at vnode_if.h:636 > #17 0xffffffff80d280fa in amd64_syscall (td=0xfffff80187e29920, > traced=0) at subr_syscall.c:133 > #18 0xffffffff80d0a64b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:407 > (kgdb) p *(vm_object_t)0xfffff8027169f500 > $1 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm object", > lo_flags = 90374144, lo_data = 0, lo_witness = 0xfffffe00006e7680}, > rw_lock = 18446735284191271200}, object_list = { > tqe_next = 0xfffff8027169f400, tqe_prev = 0xfffff8027169f620}, > shadow_head = {lh_first = 0xfffff801b8489e00}, shadow_list = {le_next > = 0x0, le_prev = 0x0}, memq = {tqh_first = 0xfffff811d966bc08, > tqh_last = 0xfffff811d966bc18}, rtree = {rt_root = > 18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1, > ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001', > flags = 528, pg_color = 0, paging_in_progress = 0, > resident_page_count = 1, backing_object = 0x0, backing_object_offset = > 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { > lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, handle > = 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp = > {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, > dev = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last = > 0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0x0, charge = 0} > (kgdb) frame 8 > #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at vnode_if.h:830 > 830 return (VOP_RECLAIM_APV(vp->v_op, &a)); > (kgdb) p *vp > $2 = {v_tag = 0xffffffff820abf96 "tmpfs", v_op = 0xffffffff820ac938, > v_data = 0x0, v_mount = 0xfffff8004733a000, v_nmntvnodes = {tqe_next = > 0xfffff802716b6000, tqe_prev = 0xfffff802716b63d0}, v_un = { > vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = > 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = > {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, > tqh_last = 0xfffff802716b6228}, v_cache_dd = 0x0, v_lock = > {lock_object = {lo_name = 0xffffffff820abf96 "tmpfs", lo_flags = > 116588544, lo_data = 0, lo_witness = 0xfffffe0000711980}, > lk_lock = 18446735284191271200, lk_exslpfail = 0, lk_timo = 51, > lk_pri = 96}, v_interlock = {lock_object = {lo_name = > 0xffffffff80fafc26 "vnode interlock", lo_flags = 16973824, lo_data = 0, > lo_witness = 0xfffffe00006e7500}, mtx_lock = 4}, v_vnlock = > 0xfffff802716b6240, v_actfreelist = {tqe_next = 0xfffff80271898588, > tqe_prev = 0xfffff8004733a078}, v_bufobj = {bo_lock = { > lock_object = {lo_name = 0xffffffff80fb8084 "bufobj interlock", > lo_flags = 86179840, lo_data = 0, lo_witness = 0xfffffe00006ef380}, > rw_lock = 1}, bo_ops = 0xffffffff814942a0, bo_object = 0x0, > bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = > 0xfffff802716b61d8, __bo_vnode = 0xfffff802716b61d8, bo_clean = {bv_hd > = {tqh_first = 0x0, tqh_last = 0xfffff802716b62f8}, bv_root = { > pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = > 0x0, tqh_last = 0xfffff802716b6318}, bv_root = {pt_root = 0}, bv_cnt = > 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 4096}, > v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = > {tqh_first = 0x0, tqh_last = 0xfffff802716b6360}, rl_currdep = 0x0}, > v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, > v_holdcnt = 2, v_usecount = 0, v_iflag = 2688, v_vflag = 0, > v_writecount = 0, v_hash = 40987489, v_type = VREG} > (kgdb) info locals > mp = (struct mount *) 0xfffff8004733a000 > fromnd = {ni_dirp = 0x801006080
, > ni_segflg = UIO_USERSPACE, ni_rightsneeded = {cr_rights = > {144115188142965760, 288230376151711744}}, > ni_startdir = 0xfffff802716b63b0, ni_rootdir = 0xfffff8026b01a760, > ni_topdir = 0xfffff8026b01a760, ni_dirfd = -100, ni_strictrelative = > 0, ni_filecaps = {fc_rights = {cr_rights = {0, 0}}, > fc_ioctls = 0x0, fc_nioctls = -1, fc_fcntls = 0}, ni_vp = > 0xfffff80271898588, ni_dvp = 0xfffff802716b63b0, ni_pathlen = 1, > ni_next = 0xfffff80061ea501f "", ni_loopcnt = 0, ni_cnd = {cn_nameiop = 2, > cn_flags = 67148812, cn_thread = 0xfffff80187e29920, cn_cred = > 0xfffff80038911800, cn_lkflags = 524288, cn_pnbuf = 0xfffff80061ea5000 > "/var/run/ld-elf.so.hints.HTjP6A", > cn_nameptr = 0xfffff80061ea5009 "ld-elf.so.hints.HTjP6A", > cn_namelen = 22, cn_consume = 0}} > tond = {ni_dirp = 0x403e66
, ni_segflg > = UIO_USERSPACE, ni_rightsneeded = {cr_rights = {144115188080051200, > 288230376151711744}}, ni_startdir = 0xfffff802716b63b0, > ni_rootdir = 0xfffff8026b01a760, ni_topdir = 0xfffff8026b01a760, > ni_dirfd = -100, ni_strictrelative = 0, ni_filecaps = {fc_rights = > {cr_rights = {0, 0}}, fc_ioctls = 0x0, fc_nioctls = -1, > fc_fcntls = 0}, ni_vp = 0xfffff802716b61d8, ni_dvp = > 0xfffff802716b63b0, ni_pathlen = 1, ni_next = 0xfffff80038d69418 "", > ni_loopcnt = 0, ni_cnd = {cn_nameiop = 3, cn_flags = 134257708, > cn_thread = 0xfffff80187e29920, cn_cred = 0xfffff80038911800, > cn_lkflags = 524288, cn_pnbuf = 0xfffff80038d69400 > "/var/run/ld-elf.so.hints", cn_nameptr = 0xfffff80038d69409 > "ld-elf.so.hints", > cn_namelen = 15, cn_consume = 0}} > rights = {cr_rights = {144115188080051200, 288230376151711744}} > mp = (struct mount *) 0xfffff8004733a000 > error = > fvp = > tvp = > tdvp = > (kgdb) p *mp > $9 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80f8fcec "struct > mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = > 0xfffffe00006e7a00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = { > tqe_next = 0xfffff80038fa9cc0, tqe_prev = 0xfffff80187b74ce8}, > mnt_op = 0xffffffff820ace60, mnt_vfc = 0xffffffff820acf80, > mnt_vnodecovered = 0xfffff801b853e760, mnt_syncer = 0xfffff8026b01a588, > mnt_ref = 13206, mnt_nvnodelist = {tqh_first = 0xfffff8026b01a760, > tqh_last = 0xfffff802718985a8}, mnt_nvnodelistsize = 13205, > mnt_activevnodelist = {tqh_first = 0xfffff802716b61d8, > tqh_last = 0xfffff8026b01a648}, mnt_activevnodelistsize = 730, > mnt_writeopcount = 1, mnt_kern_flag = 0, mnt_flag = 4096, mnt_opt = > 0xfffff8000e59cc30, mnt_optnew = 0xfffff8001b9ea050, > mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = > 135, f_flags = 4096, f_bsize = 4096, f_iosize = 4096, f_blocks = > 1835008, f_bfree = 1738991, f_bavail = 1738991, f_files = 25690112, > f_ffree = 25676911, f_syncwrites = 0, f_asyncwrites = 0, > f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, > 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {-2029977843, > 135}}, f_charspare = '\0' , f_fstypename = > "tmpfs\000\000\000\000\000\000\000\000\000\000", f_mntfromname = > "tmpfs", '\0' , > f_mntonname = "/poudriere/data/.m/exp-10amd64-commit-test/01", > '\0' }, mnt_cred = 0xfffff80047478700, mnt_data = > 0xfffff800b5155980, mnt_time = 0, mnt_iosize_max = 65536, > mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 1147308587, > mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = > 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = { > lock_object = {lo_name = 0xffffffff80f8fd0f "explock", lo_flags = > 108199936, lo_data = 0, lo_witness = 0xfffffe000070ef80}, lk_lock = 1, > lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, > mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers = > {tqh_first = 0x0, tqh_last = 0xfffff8004733a320}} -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 21:54:00 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB7F8CD for ; Tue, 22 Jul 2014 21:54:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 DFE0B2B2E for ; Tue, 22 Jul 2014 21:53:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s6MLrxYD037985 for ; Tue, 22 Jul 2014 21:53:59 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s6MLrx4X037984 for current@FreeBSD.org; Tue, 22 Jul 2014 21:53:59 GMT (envelope-from bdrewery) Received: (qmail 32910 invoked from network); 22 Jul 2014 16:53:57 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@67.182.131.225) by sweb.xzibition.com with ESMTPA; 22 Jul 2014 16:53:57 -0500 Message-ID: <53CEDD74.9070804@FreeBSD.org> Date: Tue, 22 Jul 2014 14:53:56 -0700 From: Bryan Drewery Organization: FreeBSD 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: current@FreeBSD.org Subject: Re: r268621: panic: shadowed tmpfs v_object [with dump] References: <53CED27C.4080306@FreeBSD.org> <53CED29F.1090809@FreeBSD.org> <53CED718.2090108@FreeBSD.org> In-Reply-To: <53CED718.2090108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:54:00 -0000 On 7/22/14, 2:26 PM, Bryan Drewery wrote: > On 7/22/14, 2:07 PM, Bryan Drewery wrote: >> Meant to send to current@, moving there. >> >> On 7/22/14, 2:07 PM, Bryan Drewery wrote: >>> On r268621: >>> >>>> panic: shadowed tmpfs v_object 0xfffff807a7f96600 >>>> cpuid = 0 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xfffffe1247d67390 >>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 >>>> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 >>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 >>>> vm_object_deallocate() at vm_object_deallocate+0x236/frame >>>> 0xfffffe1247d67550 >>>> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 >>>> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 >>>> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 >>>> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 >>>> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 >>>> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 >>>> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0 >>>> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 >>>> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 >>>> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 >>>> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 >>>> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 >>>> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = >>>> 0x7fffffffe238, rbp = 0x7fffffffe710 --- >>>> Uptime: 6d4h0m3s >>>> >>>> Dump failed. Partition too small. >>> >>> Unfortunately I have no dump to debug. >>> >> > Running poudriere again after boot hit the issue right away: > > >> (kgdb) bt >> #0 doadump (textdump=1) at pcpu.h:219 >> #1 0xffffffff809122a7 in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:445 >> #2 0xffffffff809127e5 in vpanic (fmt=, ap=> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744 >> #3 0xffffffff80912679 in kassert_panic (fmt=) at >> /usr/src/sys/kern/kern_shutdown.c:632 >> #4 0xffffffff80ba7996 in vm_object_deallocate (object=> optimized out>) at /usr/src/sys/vm/vm_object.c:562 >> #5 0xffffffff820a75a8 in tmpfs_free_node (tmp=0xfffff800b5155980, >> node=0xfffff802716ba740) at >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335 >> #6 0xffffffff820a363d in tmpfs_reclaim (v=) at >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276 >> #7 0xffffffff80e48717 in VOP_RECLAIM_APV (vop=, >> a=) at vnode_if.c:2017 >> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at >> vnode_if.h:830 >> #9 0xffffffff809c18be in vrecycle (vp=0xfffff802716b61d8) at >> /usr/src/sys/kern/vfs_subr.c:2655 >> #10 0xffffffff820a61cc in tmpfs_inactive (v=) at >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242 >> #11 0xffffffff80e485b7 in VOP_INACTIVE_APV (vop=, >> a=) at vnode_if.c:1951 >> #12 0xffffffff809bfd36 in vinactive (vp=0xfffff802716b61d8, >> td=0xfffff80187e29920) at vnode_if.h:807 >> #13 0xffffffff809c012a in vputx (vp=0xfffff802716b61d8, func=2) at >> /usr/src/sys/kern/vfs_subr.c:2267 >> #14 0xffffffff820a47c5 in tmpfs_rename (v=) at >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023 >> #15 0xffffffff80e47d3c in VOP_RENAME_APV (vop=, >> a=) at vnode_if.c:1544 >> #16 0xffffffff809cc77f in kern_renameat (td=, >> oldfd=, old=, newfd=> optimized out>, new=, >> pathseg=) at vnode_if.h:636 >> #17 0xffffffff80d280fa in amd64_syscall (td=0xfffff80187e29920, >> traced=0) at subr_syscall.c:133 >> #18 0xffffffff80d0a64b in Xfast_syscall () at >> /usr/src/sys/amd64/amd64/exception.S:407 >> (kgdb) p *(vm_object_t)0xfffff8027169f500 >> $1 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm object", >> lo_flags = 90374144, lo_data = 0, lo_witness = 0xfffffe00006e7680}, >> rw_lock = 18446735284191271200}, object_list = { >> tqe_next = 0xfffff8027169f400, tqe_prev = 0xfffff8027169f620}, >> shadow_head = {lh_first = 0xfffff801b8489e00}, shadow_list = {le_next >> = 0x0, le_prev = 0x0}, memq = {tqh_first = 0xfffff811d966bc08, >> tqh_last = 0xfffff811d966bc18}, rtree = {rt_root = >> 18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1, >> ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001', >> flags = 528, pg_color = 0, paging_in_progress = 0, >> resident_page_count = 1, backing_object = 0x0, backing_object_offset = >> 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { >> lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, handle >> = 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp = >> {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, >> dev = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last = >> 0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0x0, charge = 0} >> (kgdb) frame 8 >> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at >> vnode_if.h:830 >> 830 return (VOP_RECLAIM_APV(vp->v_op, &a)); >> (kgdb) p *vp >> $2 = {v_tag = 0xffffffff820abf96 "tmpfs", v_op = 0xffffffff820ac938, >> v_data = 0x0, v_mount = 0xfffff8004733a000, v_nmntvnodes = {tqe_next = >> 0xfffff802716b6000, tqe_prev = 0xfffff802716b63d0}, v_un = { >> vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = >> 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = >> {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, >> tqh_last = 0xfffff802716b6228}, v_cache_dd = 0x0, v_lock = >> {lock_object = {lo_name = 0xffffffff820abf96 "tmpfs", lo_flags = >> 116588544, lo_data = 0, lo_witness = 0xfffffe0000711980}, >> lk_lock = 18446735284191271200, lk_exslpfail = 0, lk_timo = 51, >> lk_pri = 96}, v_interlock = {lock_object = {lo_name = >> 0xffffffff80fafc26 "vnode interlock", lo_flags = 16973824, lo_data = 0, >> lo_witness = 0xfffffe00006e7500}, mtx_lock = 4}, v_vnlock = >> 0xfffff802716b6240, v_actfreelist = {tqe_next = 0xfffff80271898588, >> tqe_prev = 0xfffff8004733a078}, v_bufobj = {bo_lock = { >> lock_object = {lo_name = 0xffffffff80fb8084 "bufobj interlock", >> lo_flags = 86179840, lo_data = 0, lo_witness = 0xfffffe00006ef380}, >> rw_lock = 1}, bo_ops = 0xffffffff814942a0, bo_object = 0x0, >> bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = >> 0xfffff802716b61d8, __bo_vnode = 0xfffff802716b61d8, bo_clean = {bv_hd >> = {tqh_first = 0x0, tqh_last = 0xfffff802716b62f8}, bv_root = { >> pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = >> 0x0, tqh_last = 0xfffff802716b6318}, bv_root = {pt_root = 0}, bv_cnt = >> 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 4096}, >> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = >> {tqh_first = 0x0, tqh_last = 0xfffff802716b6360}, rl_currdep = 0x0}, >> v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, >> v_holdcnt = 2, v_usecount = 0, v_iflag = 2688, v_vflag = 0, >> v_writecount = 0, v_hash = 40987489, v_type = VREG} >> (kgdb) info locals >> mp = (struct mount *) 0xfffff8004733a000 >> fromnd = {ni_dirp = 0x801006080
, >> ni_segflg = UIO_USERSPACE, ni_rightsneeded = {cr_rights = >> {144115188142965760, 288230376151711744}}, >> ni_startdir = 0xfffff802716b63b0, ni_rootdir = 0xfffff8026b01a760, >> ni_topdir = 0xfffff8026b01a760, ni_dirfd = -100, ni_strictrelative = >> 0, ni_filecaps = {fc_rights = {cr_rights = {0, 0}}, >> fc_ioctls = 0x0, fc_nioctls = -1, fc_fcntls = 0}, ni_vp = >> 0xfffff80271898588, ni_dvp = 0xfffff802716b63b0, ni_pathlen = 1, >> ni_next = 0xfffff80061ea501f "", ni_loopcnt = 0, ni_cnd = {cn_nameiop >> = 2, >> cn_flags = 67148812, cn_thread = 0xfffff80187e29920, cn_cred = >> 0xfffff80038911800, cn_lkflags = 524288, cn_pnbuf = 0xfffff80061ea5000 >> "/var/run/ld-elf.so.hints.HTjP6A", >> cn_nameptr = 0xfffff80061ea5009 "ld-elf.so.hints.HTjP6A", >> cn_namelen = 22, cn_consume = 0}} >> tond = {ni_dirp = 0x403e66
, ni_segflg >> = UIO_USERSPACE, ni_rightsneeded = {cr_rights = {144115188080051200, >> 288230376151711744}}, ni_startdir = 0xfffff802716b63b0, >> ni_rootdir = 0xfffff8026b01a760, ni_topdir = 0xfffff8026b01a760, >> ni_dirfd = -100, ni_strictrelative = 0, ni_filecaps = {fc_rights = >> {cr_rights = {0, 0}}, fc_ioctls = 0x0, fc_nioctls = -1, >> fc_fcntls = 0}, ni_vp = 0xfffff802716b61d8, ni_dvp = >> 0xfffff802716b63b0, ni_pathlen = 1, ni_next = 0xfffff80038d69418 "", >> ni_loopcnt = 0, ni_cnd = {cn_nameiop = 3, cn_flags = 134257708, >> cn_thread = 0xfffff80187e29920, cn_cred = 0xfffff80038911800, >> cn_lkflags = 524288, cn_pnbuf = 0xfffff80038d69400 >> "/var/run/ld-elf.so.hints", cn_nameptr = 0xfffff80038d69409 >> "ld-elf.so.hints", >> cn_namelen = 15, cn_consume = 0}} >> rights = {cr_rights = {144115188080051200, 288230376151711744}} >> mp = (struct mount *) 0xfffff8004733a000 >> error = >> fvp = >> tvp = >> tdvp = >> (kgdb) p *mp >> $9 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80f8fcec "struct >> mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = >> 0xfffffe00006e7a00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = { >> tqe_next = 0xfffff80038fa9cc0, tqe_prev = 0xfffff80187b74ce8}, >> mnt_op = 0xffffffff820ace60, mnt_vfc = 0xffffffff820acf80, >> mnt_vnodecovered = 0xfffff801b853e760, mnt_syncer = 0xfffff8026b01a588, >> mnt_ref = 13206, mnt_nvnodelist = {tqh_first = 0xfffff8026b01a760, >> tqh_last = 0xfffff802718985a8}, mnt_nvnodelistsize = 13205, >> mnt_activevnodelist = {tqh_first = 0xfffff802716b61d8, >> tqh_last = 0xfffff8026b01a648}, mnt_activevnodelistsize = 730, >> mnt_writeopcount = 1, mnt_kern_flag = 0, mnt_flag = 4096, mnt_opt = >> 0xfffff8000e59cc30, mnt_optnew = 0xfffff8001b9ea050, >> mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = >> 135, f_flags = 4096, f_bsize = 4096, f_iosize = 4096, f_blocks = >> 1835008, f_bfree = 1738991, f_bavail = 1738991, f_files = 25690112, >> f_ffree = 25676911, f_syncwrites = 0, f_asyncwrites = 0, >> f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {-2029977843, >> 135}}, f_charspare = '\0' , f_fstypename = >> "tmpfs\000\000\000\000\000\000\000\000\000\000", f_mntfromname = >> "tmpfs", '\0' , >> f_mntonname = "/poudriere/data/.m/exp-10amd64-commit-test/01", >> '\0' }, mnt_cred = 0xfffff80047478700, mnt_data = >> 0xfffff800b5155980, mnt_time = 0, mnt_iosize_max = 65536, >> mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 1147308587, >> mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = >> 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = { >> lock_object = {lo_name = 0xffffffff80f8fd0f "explock", lo_flags = >> 108199936, lo_data = 0, lo_witness = 0xfffffe000070ef80}, lk_lock = 1, >> lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, >> mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers = >> {tqh_first = 0x0, tqh_last = 0xfffff8004733a320}} > Shadowed object: > (kgdb) p *$1->shadow_head->lh_first > $3 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm object", lo_flags = 90374144, lo_data = 0, lo_witness = 0xfffffe00006e7680}, rw_lock = 1}, object_list = {tqe_next = 0xfffff801b8b3ae00, > tqe_prev = 0xfffff802717bb120}, shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xfffff8027169f530}, memq = {tqh_first = 0xfffff811da2c75f8, tqh_last = 0xfffff811da2c7608}, > rtree = {rt_root = 18446735354291320313, rt_flags = 0 '\0'}, size = 1, generation = 1, ref_count = 1, shadow_count = 0, memattr = 6 '\006', type = 0 '\0', flags = 12288, pg_color = 1598, > paging_in_progress = 0, resident_page_count = 1, backing_object = 0xfffff8027169f500, backing_object_offset = 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {lh_first = 0x0}, cache = { > rt_root = 0, rt_flags = 0 '\0'}, handle = 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = { > sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0xfffff80038911800, charge = 4096} -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 12:48:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F0BDCE9 for ; Wed, 23 Jul 2014 12:48:37 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 DEEEE2714 for ; Wed, 23 Jul 2014 12:48:36 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id F168320DC4 for ; Wed, 23 Jul 2014 08:40:39 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 23 Jul 2014 08:40:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=XEqajaAdxI3rVVGyd1H4qX 0CwsM=; b=Q8aARzNiQTmcQoDN8nn65QuOAU4bBFy+j/25kbGtHlplQTl9lMbD+F GiV170J6l9YY+0cEeufIzl96sz3KM3gcJcy7SXyAE1oa+VN4IAla9nrSzP9aHYGr s7D35VvnHzE5lXtDy2mExxQPeaS4Oq/xNzd/ktxC3O0x8h9adl/Ac= X-Sasl-enc: pEvCfFtN8k+NnUJeN62epOq3Mc6pkvCLlwDJa07t1peQ 1406119239 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A99E6801AE for ; Wed, 23 Jul 2014 08:40:39 -0400 (EDT) Message-ID: <53CFAD48.1090902@freebsd.org> Date: Wed, 23 Jul 2014 22:40:40 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <20140718110645.GN87212@FreeBSD.org> <20140718151255.b3e677d9.gerrit.kuehn@aei.mpg.de> <53CA2D39.6000204@sasktel.net> <86fvhvrgfc.fsf@srvbsdfenssv.interne.associated-bears.org> In-Reply-To: <86fvhvrgfc.fsf@srvbsdfenssv.interne.associated-bears.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:48:37 -0000 On 21/07/2014 5:14 AM, Eric Masson wrote: > krad writes: > > Hi, > >> I really like the idea of the openpf version, that has been mentioned >> in this thread. > It would be nice but as it's been written in this thread, Open & Free > internals are quite different beasts, goals are different on both > platforms, so I doubt OpenPF will exist in the future. > >> It would be awesome if it ended up as a supported linux thing as well, >> so the world could be rid of iptables. > Linux world will get rid of iptables one of these days, nftables > inclusion in mainline is a clear signal. > And the design behind nftables is similar to that of NetBSD's npf. Darren From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 14:11:36 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 055265B6; Wed, 23 Jul 2014 14:11:36 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 53BBC2FA6; Wed, 23 Jul 2014 14:11:35 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6NEBMND064312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 17:11:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6NEBMND064312 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6NEBMtU064311; Wed, 23 Jul 2014 17:11:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Jul 2014 17:11:22 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: r268621: panic: shadowed tmpfs v_object [with dump] Message-ID: <20140723141122.GG93733@kib.kiev.ua> References: <53CED27C.4080306@FreeBSD.org> <53CED29F.1090809@FreeBSD.org> <53CED718.2090108@FreeBSD.org> <53CEDD74.9070804@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pZNecdF2o6CbdTLS" Content-Disposition: inline In-Reply-To: <53CEDD74.9070804@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:11:36 -0000 --pZNecdF2o6CbdTLS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote: > On 7/22/14, 2:26 PM, Bryan Drewery wrote: > > On 7/22/14, 2:07 PM, Bryan Drewery wrote: > >> Meant to send to current@, moving there. > >> > >> On 7/22/14, 2:07 PM, Bryan Drewery wrote: > >>> On r268621: > >>> > >>>> panic: shadowed tmpfs v_object 0xfffff807a7f96600 > >>>> cpuid =3D 0 > >>>> KDB: stack backtrace: > >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >>>> 0xfffffe1247d67390 > >>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 > >>>> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 > >>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 > >>>> vm_object_deallocate() at vm_object_deallocate+0x236/frame > >>>> 0xfffffe1247d67550 > >>>> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 > >>>> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 > >>>> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 > >>>> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 > >>>> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 > >>>> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 > >>>> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0 > >>>> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 > >>>> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 > >>>> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 > >>>> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 > >>>> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 > >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 > >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 > >>>> --- syscall (128, FreeBSD ELF64, sys_rename), rip =3D 0x80088b74a, r= sp =3D > >>>> 0x7fffffffe238, rbp =3D 0x7fffffffe710 --- > >>>> Uptime: 6d4h0m3s > >>>> > >>>> Dump failed. Partition too small. > >>> > >>> Unfortunately I have no dump to debug. > >>> > >> > > Running poudriere again after boot hit the issue right away: > > > > > >> (kgdb) bt > >> #0 doadump (textdump=3D1) at pcpu.h:219 > >> #1 0xffffffff809122a7 in kern_reboot (howto=3D260) at > >> /usr/src/sys/kern/kern_shutdown.c:445 > >> #2 0xffffffff809127e5 in vpanic (fmt=3D, ap=3D >> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744 > >> #3 0xffffffff80912679 in kassert_panic (fmt=3D) = at > >> /usr/src/sys/kern/kern_shutdown.c:632 > >> #4 0xffffffff80ba7996 in vm_object_deallocate (object=3D >> optimized out>) at /usr/src/sys/vm/vm_object.c:562 > >> #5 0xffffffff820a75a8 in tmpfs_free_node (tmp=3D0xfffff800b5155980, > >> node=3D0xfffff802716ba740) at > >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335 > >> #6 0xffffffff820a363d in tmpfs_reclaim (v=3D) at > >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276 > >> #7 0xffffffff80e48717 in VOP_RECLAIM_APV (vop=3D, > >> a=3D) at vnode_if.c:2017 > >> #8 0xffffffff809c1381 in vgonel (vp=3D0xfffff802716b61d8) at > >> vnode_if.h:830 > >> #9 0xffffffff809c18be in vrecycle (vp=3D0xfffff802716b61d8) at > >> /usr/src/sys/kern/vfs_subr.c:2655 > >> #10 0xffffffff820a61cc in tmpfs_inactive (v=3D) at > >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242 > >> #11 0xffffffff80e485b7 in VOP_INACTIVE_APV (vop=3D, > >> a=3D) at vnode_if.c:1951 > >> #12 0xffffffff809bfd36 in vinactive (vp=3D0xfffff802716b61d8, > >> td=3D0xfffff80187e29920) at vnode_if.h:807 > >> #13 0xffffffff809c012a in vputx (vp=3D0xfffff802716b61d8, func=3D2) at > >> /usr/src/sys/kern/vfs_subr.c:2267 > >> #14 0xffffffff820a47c5 in tmpfs_rename (v=3D) at > >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023 > >> #15 0xffffffff80e47d3c in VOP_RENAME_APV (vop=3D, > >> a=3D) at vnode_if.c:1544 > >> #16 0xffffffff809cc77f in kern_renameat (td=3D, > >> oldfd=3D, old=3D, newfd=3D >> optimized out>, new=3D, > >> pathseg=3D) at vnode_if.h:636 > >> #17 0xffffffff80d280fa in amd64_syscall (td=3D0xfffff80187e29920, > >> traced=3D0) at subr_syscall.c:133 > >> #18 0xffffffff80d0a64b in Xfast_syscall () at > >> /usr/src/sys/amd64/amd64/exception.S:407 > >> (kgdb) p *(vm_object_t)0xfffff8027169f500 > >> $1 =3D {lock =3D {lock_object =3D {lo_name =3D 0xffffffff80fe89f6 "vm = object", > >> lo_flags =3D 90374144, lo_data =3D 0, lo_witness =3D 0xfffffe00006e768= 0}, > >> rw_lock =3D 18446735284191271200}, object_list =3D { > >> tqe_next =3D 0xfffff8027169f400, tqe_prev =3D 0xfffff8027169f620}, > >> shadow_head =3D {lh_first =3D 0xfffff801b8489e00}, shadow_list =3D {le= _next > >> =3D 0x0, le_prev =3D 0x0}, memq =3D {tqh_first =3D 0xfffff811d966bc08, > >> tqh_last =3D 0xfffff811d966bc18}, rtree =3D {rt_root =3D > >> 18446735354278362121, rt_flags =3D 0 '\0'}, size =3D 1, generation =3D= 1, > >> ref_count =3D 1, shadow_count =3D 1, memattr =3D 6 '\006', type =3D 1 = '\001', > >> flags =3D 528, pg_color =3D 0, paging_in_progress =3D 0, > >> resident_page_count =3D 1, backing_object =3D 0x0, backing_object_offs= et =3D > >> 0, pager_object_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, rvq =3D= { > >> lh_first =3D 0x0}, cache =3D {rt_root =3D 0, rt_flags =3D 0 '\0'},= handle > >> =3D 0x0, un_pager =3D {vnp =3D {vnp_size =3D 0, writemappings =3D 0}, = devp =3D > >> {devp_pglist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, ops =3D 0x0, > >> dev =3D 0x0}, sgp =3D {sgp_pglist =3D {tqh_first =3D 0x0, tqh_la= st =3D > >> 0x0}}, swp =3D {swp_tmpfs =3D 0x0, swp_bcount =3D 0}}, cred =3D 0x0, c= harge =3D 0} > >> (kgdb) frame 8 > >> #8 0xffffffff809c1381 in vgonel (vp=3D0xfffff802716b61d8) at > >> vnode_if.h:830 > >> 830 return (VOP_RECLAIM_APV(vp->v_op, &a)); > >> (kgdb) p *vp > >> $2 =3D {v_tag =3D 0xffffffff820abf96 "tmpfs", v_op =3D 0xffffffff820ac= 938, > >> v_data =3D 0x0, v_mount =3D 0xfffff8004733a000, v_nmntvnodes =3D {tqe_= next =3D > >> 0xfffff802716b6000, tqe_prev =3D 0xfffff802716b63d0}, v_un =3D { > >> vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo = =3D > >> 0x0}, v_hashlist =3D {le_next =3D 0x0, le_prev =3D 0x0}, v_cache_src = =3D > >> {lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0x0, > >> tqh_last =3D 0xfffff802716b6228}, v_cache_dd =3D 0x0, v_lock =3D > >> {lock_object =3D {lo_name =3D 0xffffffff820abf96 "tmpfs", lo_flags =3D > >> 116588544, lo_data =3D 0, lo_witness =3D 0xfffffe0000711980}, > >> lk_lock =3D 18446735284191271200, lk_exslpfail =3D 0, lk_timo =3D = 51, > >> lk_pri =3D 96}, v_interlock =3D {lock_object =3D {lo_name =3D > >> 0xffffffff80fafc26 "vnode interlock", lo_flags =3D 16973824, lo_data = =3D 0, > >> lo_witness =3D 0xfffffe00006e7500}, mtx_lock =3D 4}, v_vnlock =3D > >> 0xfffff802716b6240, v_actfreelist =3D {tqe_next =3D 0xfffff80271898588, > >> tqe_prev =3D 0xfffff8004733a078}, v_bufobj =3D {bo_lock =3D { > >> lock_object =3D {lo_name =3D 0xffffffff80fb8084 "bufobj interloc= k", > >> lo_flags =3D 86179840, lo_data =3D 0, lo_witness =3D 0xfffffe00006ef38= 0}, > >> rw_lock =3D 1}, bo_ops =3D 0xffffffff814942a0, bo_object =3D 0x0, > >> bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0x0}, bo_private =3D > >> 0xfffff802716b61d8, __bo_vnode =3D 0xfffff802716b61d8, bo_clean =3D {b= v_hd > >> =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff802716b62f8}, bv_root =3D { > >> pt_root =3D 0}, bv_cnt =3D 0}, bo_dirty =3D {bv_hd =3D {tqh_fi= rst =3D > >> 0x0, tqh_last =3D 0xfffff802716b6318}, bv_root =3D {pt_root =3D 0}, bv= _cnt =3D > >> 0}, bo_numoutput =3D 0, bo_flag =3D 0, bo_bsize =3D 4096}, > >> v_pollinfo =3D 0x0, v_label =3D 0x0, v_lockf =3D 0x0, v_rl =3D {rl_w= aiters =3D > >> {tqh_first =3D 0x0, tqh_last =3D 0xfffff802716b6360}, rl_currdep =3D 0= x0}, > >> v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, > >> v_holdcnt =3D 2, v_usecount =3D 0, v_iflag =3D 2688, v_vflag =3D 0, > >> v_writecount =3D 0, v_hash =3D 40987489, v_type =3D VREG} > >> (kgdb) info locals > >> mp =3D (struct mount *) 0xfffff8004733a000 > >> fromnd =3D {ni_dirp =3D 0x801006080
, > >> ni_segflg =3D UIO_USERSPACE, ni_rightsneeded =3D {cr_rights =3D > >> {144115188142965760, 288230376151711744}}, > >> ni_startdir =3D 0xfffff802716b63b0, ni_rootdir =3D 0xfffff8026b01a76= 0, > >> ni_topdir =3D 0xfffff8026b01a760, ni_dirfd =3D -100, ni_strictrelative= =3D > >> 0, ni_filecaps =3D {fc_rights =3D {cr_rights =3D {0, 0}}, > >> fc_ioctls =3D 0x0, fc_nioctls =3D -1, fc_fcntls =3D 0}, ni_vp =3D > >> 0xfffff80271898588, ni_dvp =3D 0xfffff802716b63b0, ni_pathlen =3D 1, > >> ni_next =3D 0xfffff80061ea501f "", ni_loopcnt =3D 0, ni_cnd =3D {cn_na= meiop > >> =3D 2, > >> cn_flags =3D 67148812, cn_thread =3D 0xfffff80187e29920, cn_cred = =3D > >> 0xfffff80038911800, cn_lkflags =3D 524288, cn_pnbuf =3D 0xfffff80061ea= 5000 > >> "/var/run/ld-elf.so.hints.HTjP6A", > >> cn_nameptr =3D 0xfffff80061ea5009 "ld-elf.so.hints.HTjP6A", > >> cn_namelen =3D 22, cn_consume =3D 0}} > >> tond =3D {ni_dirp =3D 0x403e66
, ni_se= gflg > >> =3D UIO_USERSPACE, ni_rightsneeded =3D {cr_rights =3D {144115188080051= 200, > >> 288230376151711744}}, ni_startdir =3D 0xfffff802716b63b0, > >> ni_rootdir =3D 0xfffff8026b01a760, ni_topdir =3D 0xfffff8026b01a760, > >> ni_dirfd =3D -100, ni_strictrelative =3D 0, ni_filecaps =3D {fc_rights= =3D > >> {cr_rights =3D {0, 0}}, fc_ioctls =3D 0x0, fc_nioctls =3D -1, > >> fc_fcntls =3D 0}, ni_vp =3D 0xfffff802716b61d8, ni_dvp =3D > >> 0xfffff802716b63b0, ni_pathlen =3D 1, ni_next =3D 0xfffff80038d69418 "= ", > >> ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 3, cn_flags =3D 134257708, > >> cn_thread =3D 0xfffff80187e29920, cn_cred =3D 0xfffff80038911800, > >> cn_lkflags =3D 524288, cn_pnbuf =3D 0xfffff80038d69400 > >> "/var/run/ld-elf.so.hints", cn_nameptr =3D 0xfffff80038d69409 > >> "ld-elf.so.hints", > >> cn_namelen =3D 15, cn_consume =3D 0}} > >> rights =3D {cr_rights =3D {144115188080051200, 288230376151711744}} > >> mp =3D (struct mount *) 0xfffff8004733a000 > >> error =3D > >> fvp =3D > >> tvp =3D > >> tdvp =3D > >> (kgdb) p *mp > >> $9 =3D {mnt_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff80f8fcec "= struct > >> mount mtx", lo_flags =3D 16973824, lo_data =3D 0, lo_witness =3D > >> 0xfffffe00006e7a00}, mtx_lock =3D 4}, mnt_gen =3D 1, mnt_list =3D { > >> tqe_next =3D 0xfffff80038fa9cc0, tqe_prev =3D 0xfffff80187b74ce8}, > >> mnt_op =3D 0xffffffff820ace60, mnt_vfc =3D 0xffffffff820acf80, > >> mnt_vnodecovered =3D 0xfffff801b853e760, mnt_syncer =3D 0xfffff8026b01= a588, > >> mnt_ref =3D 13206, mnt_nvnodelist =3D {tqh_first =3D 0xfffff8026b01a= 760, > >> tqh_last =3D 0xfffff802718985a8}, mnt_nvnodelistsize =3D 13205, > >> mnt_activevnodelist =3D {tqh_first =3D 0xfffff802716b61d8, > >> tqh_last =3D 0xfffff8026b01a648}, mnt_activevnodelistsize =3D 730, > >> mnt_writeopcount =3D 1, mnt_kern_flag =3D 0, mnt_flag =3D 4096, mnt_op= t =3D > >> 0xfffff8000e59cc30, mnt_optnew =3D 0xfffff8001b9ea050, > >> mnt_maxsymlinklen =3D 0, mnt_stat =3D {f_version =3D 537068824, f_ty= pe =3D > >> 135, f_flags =3D 4096, f_bsize =3D 4096, f_iosize =3D 4096, f_blocks = =3D > >> 1835008, f_bfree =3D 1738991, f_bavail =3D 1738991, f_files =3D 256901= 12, > >> f_ffree =3D 25676911, f_syncwrites =3D 0, f_asyncwrites =3D 0, > >> f_syncreads =3D 0, f_asyncreads =3D 0, f_spare =3D {0, 0, 0, 0, 0, 0, = 0, 0, > >> 0, 0}, f_namemax =3D 255, f_owner =3D 0, f_fsid =3D {val =3D {-2029977= 843, > >> 135}}, f_charspare =3D '\0' , f_fstypename = =3D > >> "tmpfs\000\000\000\000\000\000\000\000\000\000", f_mntfromname =3D > >> "tmpfs", '\0' , > >> f_mntonname =3D "/poudriere/data/.m/exp-10amd64-commit-test/01", > >> '\0' }, mnt_cred =3D 0xfffff80047478700, mnt_data =3D > >> 0xfffff800b5155980, mnt_time =3D 0, mnt_iosize_max =3D 65536, > >> mnt_export =3D 0x0, mnt_label =3D 0x0, mnt_hashseed =3D 1147308587, > >> mnt_lockref =3D 0, mnt_secondary_writes =3D 0, mnt_secondary_accwrites= =3D > >> 0, mnt_susp_owner =3D 0x0, mnt_gjprovider =3D 0x0, mnt_explock =3D { > >> lock_object =3D {lo_name =3D 0xffffffff80f8fd0f "explock", lo_flag= s =3D > >> 108199936, lo_data =3D 0, lo_witness =3D 0xfffffe000070ef80}, lk_lock = =3D 1, > >> lk_exslpfail =3D 0, lk_timo =3D 0, lk_pri =3D 96}, > >> mnt_upper_link =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, mnt_uppers = =3D > >> {tqh_first =3D 0x0, tqh_last =3D 0xfffff8004733a320}} > > >=20 > Shadowed object: >=20 > > (kgdb) p *$1->shadow_head->lh_first > > $3 =3D {lock =3D {lock_object =3D {lo_name =3D 0xffffffff80fe89f6 "vm o= bject", lo_flags =3D 90374144, lo_data =3D 0, lo_witness =3D 0xfffffe00006e= 7680}, rw_lock =3D 1}, object_list =3D {tqe_next =3D 0xfffff801b8b3ae00, > > tqe_prev =3D 0xfffff802717bb120}, shadow_head =3D {lh_first =3D 0x0= }, shadow_list =3D {le_next =3D 0x0, le_prev =3D 0xfffff8027169f530}, memq = =3D {tqh_first =3D 0xfffff811da2c75f8, tqh_last =3D 0xfffff811da2c7608}, > > rtree =3D {rt_root =3D 18446735354291320313, rt_flags =3D 0 '\0'}, si= ze =3D 1, generation =3D 1, ref_count =3D 1, shadow_count =3D 0, memattr = =3D 6 '\006', type =3D 0 '\0', flags =3D 12288, pg_color =3D 1598, > > paging_in_progress =3D 0, resident_page_count =3D 1, backing_object = =3D 0xfffff8027169f500, backing_object_offset =3D 0, pager_object_list =3D = {tqe_next =3D 0x0, tqe_prev =3D 0x0}, rvq =3D {lh_first =3D 0x0}, cache =3D= { > > rt_root =3D 0, rt_flags =3D 0 '\0'}, handle =3D 0x0, un_pager =3D {= vnp =3D {vnp_size =3D 0, writemappings =3D 0}, devp =3D {devp_pglist =3D {t= qh_first =3D 0x0, tqh_last =3D 0x0}, ops =3D 0x0, dev =3D 0x0}, sgp =3D { > > sgp_pglist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}}, swp =3D {s= wp_tmpfs =3D 0x0, swp_bcount =3D 0}}, cred =3D 0xfffff80038911800, charge = =3D 4096} >=20 Try this diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 1b97bdf..bb01f00 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -559,8 +559,6 @@ vm_object_deallocate(vm_object_t object) (object->handle =3D=3D NULL) && (object->type =3D=3D OBJT_DEFAULT || object->type =3D=3D OBJT_SWAP)) { - KASSERT((object->flags & OBJ_TMPFS_NODE) =3D=3D 0, - ("shadowed tmpfs v_object %p", object)); vm_object_t robject; =20 robject =3D LIST_FIRST(&object->shadow_head); @@ -568,6 +566,8 @@ vm_object_deallocate(vm_object_t object) ("vm_object_deallocate: ref_count: %d, shadow_count: %d", object->ref_count, object->shadow_count)); + KASSERT((robject->flags & OBJ_TMPFS_NODE) =3D=3D 0, + ("shadowed tmpfs v_object %p", object)); if (!VM_OBJECT_TRYWLOCK(robject)) { /* * Avoid a potential deadlock. @@ -637,6 +637,8 @@ retry: doterm: temp =3D object->backing_object; if (temp !=3D NULL) { + KASSERT((object->flags & OBJ_TMPFS_NODE) =3D=3D 0, + ("shadowed tmpfs v_object 2 %p", object)); VM_OBJECT_WLOCK(temp); LIST_REMOVE(object, shadow_list); temp->shadow_count--; --pZNecdF2o6CbdTLS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTz8KKAAoJEJDCuSvBvK1BvugP+wR3VKgEftuq+LpUthzIVkqd HmDeWO9HFd84I1ewg3z+Am0nJvkbVKULSw6uGEu6oHVIS6q+rU8zj2iYTU5N0VtX bzL5yXtX+UR2pLpPCJGSHLfqim8RIDPdWD+ZR2Dt028BUtD8Y1v7ejwIMqD8ZvSt i36ZyD/WfGW3+5RvXkm60xGxgaA5xcjM6qwBQQGLgoLjXmwf3i6VB2wFVvs53ppS C7zdCXG4FsO/8YMDNAsf3EtZaFG4QV7wIWHlm9Inys6fCs203URzSPPNl5trRIO7 bffq3YJMTgJoa1K/zp1URIEE4VRWxb8j0fxMgak+xjp3y0WNC/Jv022DJ56UYdfN o18O6e9oLRiTa2k5ELThBOUxuaEjyZ5dZ43zuyScxGq84HLy64ZjTq0n24Kh0CjB 8Embnkth/lsV/RczQ7eVTwe/Y8Io4o+vPYUYYAXPwywJjVc/A5P9H1CTbEl3ovQq 0ZL5+WzE4vsmy36vs6TYL8ir5H3mGQb/coK52kqDPrqS+Z8uGzs6+Tmo9f/T+pmp Q4lIi/4OsePYhpdzl6+oIZmn4YL0JK+iF65pG+mnJvYpdo3xFVeuaHPLAA02kYe5 BnUyI5lyexTc2TTn2h43zoSfyaN5s8W51BVpPvPefcklfJfDFKwVj+BpEVBvNxg4 rRS5jcJgY6gLAa3CQ3gL =EOQL -----END PGP SIGNATURE----- --pZNecdF2o6CbdTLS-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 14:43:03 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B4DE86A; Wed, 23 Jul 2014 14:43:03 +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 C022B242F; Wed, 23 Jul 2014 14:43:02 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so1278743wgh.11 for ; Wed, 23 Jul 2014 07:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=hZ8bXliNls61+4eeVd2h49dA4PpNguga302kcxAoRmM=; b=ai7LElPPLqIEDcxv+1eBM2biK2ocLJtOqREfEZOm0+wTM5PDvDomhavBN9Zu21VAdr gw21XT1hgHmPoOf/iunRvrSplzwTHSna/o2Q9UoFkKo/oGaHNZpJGeMmdHELiS2dQfJx wPebuxmu8KmWlF0wtc2uDdjwqE3WnfNaBLe/6QkOCoK+lqu4l+r6OmIfRsWGNEJ4Dw90 QbJ+BgcIqYb2VhM+9Ck/y5JNqCLIiXvu5oiAB6RPdeYJ0X0YrRCW6diSQ3+uwr34vAuQ a098qXcoSwSRIozvh754X5qIaNF83DR5Pns5XmHNh1/luEX+awo+JQChjY774y6B3n4n ukmA== X-Received: by 10.180.21.235 with SMTP id y11mr3519771wie.75.1406126579303; Wed, 23 Jul 2014 07:42:59 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fu7sm9993824wib.2.2014.07.23.07.42.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jul 2014 07:42:53 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 23 Jul 2014 16:42:51 +0200 From: Baptiste Daroussin To: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org Subject: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140723144249.GD69907@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vni90+aGYgRvsTuO" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:43:03 -0000 --vni90+aGYgRvsTuO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I'm very please to announce the release of pkg 1.3.0 This version is the result of almost 9 month of hard work Here are the statistics for the version: - 373 files changed, 66973 insertions(+), 38512 deletions(-) - 29 different contributors Please not that for the first time I'm not the main contributor, and I would like to particularly thanks Vsevold Stakhov for all the hard work he has do= ne to allow us to get this release out. I would like also to give a special thank= s to Andrej Zverev for the tons of hours spending on testing and cleaning the bug tracker! So much has happened that it is hard to summarize so I'll try to highlight = the major points: - New solver, now pkg has a real SAT solver able to automatically handle conflicts and dynamically discover them. (yes pkg set -o is deprecated no= w) - pkg install now able to install local files as well and resolve their dependencies from the remote repositories - Lots of parts of the code has been sandboxed - Lots of rework to improve portability - Package installation process has been reworked to be safer and handle pro= perly the schg flags - Important modification of the locking system for finer grain locks - Massive usage of libucl - Simplification of the API - Lots of improvements on the UI to provide a better user experience. - Lots of improvements in multi repository mode - pkg audit code has been moved into the library - pkg -o A=3DB that will overwrite configuration file from cli - The ui now support long options - The unicity of a package is not anymore origin - Tons of bug fixes - Tons of behaviours fixes - Way more! Thank you to all contributors: Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, Bryan Drewery, Dag-Erling Sm=F8rgrav, Dmitry Marakasov, Elvira Khabirova, J= amie Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, Matthew Seaman, Maximilian Ga=DF, Michael Gehring, Michael Gmelin, Nicolas = Szalay, Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, Vsevolod Stakhov, Xin Li, coctic Regards, Bapt on behalf of the pkg@ --vni90+aGYgRvsTuO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPPyekACgkQ8kTtMUmk6ExikACfcdA+TEaFQ/jmst/Wr6Z4jIVZ AucAnim6B1X29+QrimPhsoGO3awMWT0T =ib/R -----END PGP SIGNATURE----- --vni90+aGYgRvsTuO-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 16:13:03 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0E0993 for ; Wed, 23 Jul 2014 16:13:03 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 8B9EB2E0F for ; Wed, 23 Jul 2014 16:13:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s6NGD35B017551 for ; Wed, 23 Jul 2014 16:13:03 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s6NGD3Lb017550 for current@FreeBSD.org; Wed, 23 Jul 2014 16:13:03 GMT (envelope-from bdrewery) Received: (qmail 92371 invoked from network); 23 Jul 2014 11:13:00 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@67.182.131.225) by sweb.xzibition.com with ESMTPA; 23 Jul 2014 11:13:00 -0500 Message-ID: <53CFDF0B.1080904@FreeBSD.org> Date: Wed, 23 Jul 2014 09:12:59 -0700 From: Bryan Drewery Organization: FreeBSD 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: Konstantin Belousov Subject: Re: r268621: panic: shadowed tmpfs v_object [with dump] References: <53CED27C.4080306@FreeBSD.org> <53CED29F.1090809@FreeBSD.org> <53CED718.2090108@FreeBSD.org> <53CEDD74.9070804@FreeBSD.org> <20140723141122.GG93733@kib.kiev.ua> In-Reply-To: <20140723141122.GG93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:13:03 -0000 On 7/23/14, 7:11 AM, Konstantin Belousov wrote: > On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote: >> On 7/22/14, 2:26 PM, Bryan Drewery wrote: >>> On 7/22/14, 2:07 PM, Bryan Drewery wrote: >>>> Meant to send to current@, moving there. >>>> >>>> On 7/22/14, 2:07 PM, Bryan Drewery wrote: >>>>> On r268621: >>>>> >>>>>> panic: shadowed tmpfs v_object 0xfffff807a7f96600 >>>>>> cpuid = 0 >>>>>> KDB: stack backtrace: >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>>>> 0xfffffe1247d67390 >>>>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 >>>>>> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 >>>>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 >>>>>> vm_object_deallocate() at vm_object_deallocate+0x236/frame >>>>>> 0xfffffe1247d67550 >>>>>> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 >>>>>> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 >>>>>> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 >>>>>> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 >>>>>> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 >>>>>> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 >>>>>> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0 >>>>>> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 >>>>>> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 >>>>>> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 >>>>>> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 >>>>>> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 >>>>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 >>>>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 >>>>>> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = >>>>>> 0x7fffffffe238, rbp = 0x7fffffffe710 --- >>>>>> Uptime: 6d4h0m3s >>>>>> >>>>>> Dump failed. Partition too small. >>>>> >>>>> Unfortunately I have no dump to debug. >>>>> >>>> >>> Running poudriere again after boot hit the issue right away: >>> >>> >>>> (kgdb) bt >>>> #0 doadump (textdump=1) at pcpu.h:219 >>>> #1 0xffffffff809122a7 in kern_reboot (howto=260) at >>>> /usr/src/sys/kern/kern_shutdown.c:445 >>>> #2 0xffffffff809127e5 in vpanic (fmt=, ap=>>> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744 >>>> #3 0xffffffff80912679 in kassert_panic (fmt=) at >>>> /usr/src/sys/kern/kern_shutdown.c:632 >>>> #4 0xffffffff80ba7996 in vm_object_deallocate (object=>>> optimized out>) at /usr/src/sys/vm/vm_object.c:562 >>>> #5 0xffffffff820a75a8 in tmpfs_free_node (tmp=0xfffff800b5155980, >>>> node=0xfffff802716ba740) at >>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335 >>>> #6 0xffffffff820a363d in tmpfs_reclaim (v=) at >>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276 >>>> #7 0xffffffff80e48717 in VOP_RECLAIM_APV (vop=, >>>> a=) at vnode_if.c:2017 >>>> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at >>>> vnode_if.h:830 >>>> #9 0xffffffff809c18be in vrecycle (vp=0xfffff802716b61d8) at >>>> /usr/src/sys/kern/vfs_subr.c:2655 >>>> #10 0xffffffff820a61cc in tmpfs_inactive (v=) at >>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242 >>>> #11 0xffffffff80e485b7 in VOP_INACTIVE_APV (vop=, >>>> a=) at vnode_if.c:1951 >>>> #12 0xffffffff809bfd36 in vinactive (vp=0xfffff802716b61d8, >>>> td=0xfffff80187e29920) at vnode_if.h:807 >>>> #13 0xffffffff809c012a in vputx (vp=0xfffff802716b61d8, func=2) at >>>> /usr/src/sys/kern/vfs_subr.c:2267 >>>> #14 0xffffffff820a47c5 in tmpfs_rename (v=) at >>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023 >>>> #15 0xffffffff80e47d3c in VOP_RENAME_APV (vop=, >>>> a=) at vnode_if.c:1544 >>>> #16 0xffffffff809cc77f in kern_renameat (td=, >>>> oldfd=, old=, newfd=>>> optimized out>, new=, >>>> pathseg=) at vnode_if.h:636 >>>> #17 0xffffffff80d280fa in amd64_syscall (td=0xfffff80187e29920, >>>> traced=0) at subr_syscall.c:133 >>>> #18 0xffffffff80d0a64b in Xfast_syscall () at >>>> /usr/src/sys/amd64/amd64/exception.S:407 >>>> (kgdb) p *(vm_object_t)0xfffff8027169f500 >>>> $1 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm object", >>>> lo_flags = 90374144, lo_data = 0, lo_witness = 0xfffffe00006e7680}, >>>> rw_lock = 18446735284191271200}, object_list = { >>>> tqe_next = 0xfffff8027169f400, tqe_prev = 0xfffff8027169f620}, >>>> shadow_head = {lh_first = 0xfffff801b8489e00}, shadow_list = {le_next >>>> = 0x0, le_prev = 0x0}, memq = {tqh_first = 0xfffff811d966bc08, >>>> tqh_last = 0xfffff811d966bc18}, rtree = {rt_root = >>>> 18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1, >>>> ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001', >>>> flags = 528, pg_color = 0, paging_in_progress = 0, >>>> resident_page_count = 1, backing_object = 0x0, backing_object_offset = >>>> 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { >>>> lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, handle >>>> = 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp = >>>> {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, >>>> dev = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last = >>>> 0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0x0, charge = 0} >>>> (kgdb) frame 8 >>>> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at >>>> vnode_if.h:830 >>>> 830 return (VOP_RECLAIM_APV(vp->v_op, &a)); >>>> (kgdb) p *vp >>>> $2 = {v_tag = 0xffffffff820abf96 "tmpfs", v_op = 0xffffffff820ac938, >>>> v_data = 0x0, v_mount = 0xfffff8004733a000, v_nmntvnodes = {tqe_next = >>>> 0xfffff802716b6000, tqe_prev = 0xfffff802716b63d0}, v_un = { >>>> vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = >>>> 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = >>>> {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, >>>> tqh_last = 0xfffff802716b6228}, v_cache_dd = 0x0, v_lock = >>>> {lock_object = {lo_name = 0xffffffff820abf96 "tmpfs", lo_flags = >>>> 116588544, lo_data = 0, lo_witness = 0xfffffe0000711980}, >>>> lk_lock = 18446735284191271200, lk_exslpfail = 0, lk_timo = 51, >>>> lk_pri = 96}, v_interlock = {lock_object = {lo_name = >>>> 0xffffffff80fafc26 "vnode interlock", lo_flags = 16973824, lo_data = 0, >>>> lo_witness = 0xfffffe00006e7500}, mtx_lock = 4}, v_vnlock = >>>> 0xfffff802716b6240, v_actfreelist = {tqe_next = 0xfffff80271898588, >>>> tqe_prev = 0xfffff8004733a078}, v_bufobj = {bo_lock = { >>>> lock_object = {lo_name = 0xffffffff80fb8084 "bufobj interlock", >>>> lo_flags = 86179840, lo_data = 0, lo_witness = 0xfffffe00006ef380}, >>>> rw_lock = 1}, bo_ops = 0xffffffff814942a0, bo_object = 0x0, >>>> bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = >>>> 0xfffff802716b61d8, __bo_vnode = 0xfffff802716b61d8, bo_clean = {bv_hd >>>> = {tqh_first = 0x0, tqh_last = 0xfffff802716b62f8}, bv_root = { >>>> pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = >>>> 0x0, tqh_last = 0xfffff802716b6318}, bv_root = {pt_root = 0}, bv_cnt = >>>> 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 4096}, >>>> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = >>>> {tqh_first = 0x0, tqh_last = 0xfffff802716b6360}, rl_currdep = 0x0}, >>>> v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, >>>> v_holdcnt = 2, v_usecount = 0, v_iflag = 2688, v_vflag = 0, >>>> v_writecount = 0, v_hash = 40987489, v_type = VREG} >>>> (kgdb) info locals >>>> mp = (struct mount *) 0xfffff8004733a000 >>>> fromnd = {ni_dirp = 0x801006080
, >>>> ni_segflg = UIO_USERSPACE, ni_rightsneeded = {cr_rights = >>>> {144115188142965760, 288230376151711744}}, >>>> ni_startdir = 0xfffff802716b63b0, ni_rootdir = 0xfffff8026b01a760, >>>> ni_topdir = 0xfffff8026b01a760, ni_dirfd = -100, ni_strictrelative = >>>> 0, ni_filecaps = {fc_rights = {cr_rights = {0, 0}}, >>>> fc_ioctls = 0x0, fc_nioctls = -1, fc_fcntls = 0}, ni_vp = >>>> 0xfffff80271898588, ni_dvp = 0xfffff802716b63b0, ni_pathlen = 1, >>>> ni_next = 0xfffff80061ea501f "", ni_loopcnt = 0, ni_cnd = {cn_nameiop >>>> = 2, >>>> cn_flags = 67148812, cn_thread = 0xfffff80187e29920, cn_cred = >>>> 0xfffff80038911800, cn_lkflags = 524288, cn_pnbuf = 0xfffff80061ea5000 >>>> "/var/run/ld-elf.so.hints.HTjP6A", >>>> cn_nameptr = 0xfffff80061ea5009 "ld-elf.so.hints.HTjP6A", >>>> cn_namelen = 22, cn_consume = 0}} >>>> tond = {ni_dirp = 0x403e66
, ni_segflg >>>> = UIO_USERSPACE, ni_rightsneeded = {cr_rights = {144115188080051200, >>>> 288230376151711744}}, ni_startdir = 0xfffff802716b63b0, >>>> ni_rootdir = 0xfffff8026b01a760, ni_topdir = 0xfffff8026b01a760, >>>> ni_dirfd = -100, ni_strictrelative = 0, ni_filecaps = {fc_rights = >>>> {cr_rights = {0, 0}}, fc_ioctls = 0x0, fc_nioctls = -1, >>>> fc_fcntls = 0}, ni_vp = 0xfffff802716b61d8, ni_dvp = >>>> 0xfffff802716b63b0, ni_pathlen = 1, ni_next = 0xfffff80038d69418 "", >>>> ni_loopcnt = 0, ni_cnd = {cn_nameiop = 3, cn_flags = 134257708, >>>> cn_thread = 0xfffff80187e29920, cn_cred = 0xfffff80038911800, >>>> cn_lkflags = 524288, cn_pnbuf = 0xfffff80038d69400 >>>> "/var/run/ld-elf.so.hints", cn_nameptr = 0xfffff80038d69409 >>>> "ld-elf.so.hints", >>>> cn_namelen = 15, cn_consume = 0}} >>>> rights = {cr_rights = {144115188080051200, 288230376151711744}} >>>> mp = (struct mount *) 0xfffff8004733a000 >>>> error = >>>> fvp = >>>> tvp = >>>> tdvp = >>>> (kgdb) p *mp >>>> $9 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80f8fcec "struct >>>> mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = >>>> 0xfffffe00006e7a00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = { >>>> tqe_next = 0xfffff80038fa9cc0, tqe_prev = 0xfffff80187b74ce8}, >>>> mnt_op = 0xffffffff820ace60, mnt_vfc = 0xffffffff820acf80, >>>> mnt_vnodecovered = 0xfffff801b853e760, mnt_syncer = 0xfffff8026b01a588, >>>> mnt_ref = 13206, mnt_nvnodelist = {tqh_first = 0xfffff8026b01a760, >>>> tqh_last = 0xfffff802718985a8}, mnt_nvnodelistsize = 13205, >>>> mnt_activevnodelist = {tqh_first = 0xfffff802716b61d8, >>>> tqh_last = 0xfffff8026b01a648}, mnt_activevnodelistsize = 730, >>>> mnt_writeopcount = 1, mnt_kern_flag = 0, mnt_flag = 4096, mnt_opt = >>>> 0xfffff8000e59cc30, mnt_optnew = 0xfffff8001b9ea050, >>>> mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = >>>> 135, f_flags = 4096, f_bsize = 4096, f_iosize = 4096, f_blocks = >>>> 1835008, f_bfree = 1738991, f_bavail = 1738991, f_files = 25690112, >>>> f_ffree = 25676911, f_syncwrites = 0, f_asyncwrites = 0, >>>> f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, >>>> 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {-2029977843, >>>> 135}}, f_charspare = '\0' , f_fstypename = >>>> "tmpfs\000\000\000\000\000\000\000\000\000\000", f_mntfromname = >>>> "tmpfs", '\0' , >>>> f_mntonname = "/poudriere/data/.m/exp-10amd64-commit-test/01", >>>> '\0' }, mnt_cred = 0xfffff80047478700, mnt_data = >>>> 0xfffff800b5155980, mnt_time = 0, mnt_iosize_max = 65536, >>>> mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 1147308587, >>>> mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = >>>> 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = { >>>> lock_object = {lo_name = 0xffffffff80f8fd0f "explock", lo_flags = >>>> 108199936, lo_data = 0, lo_witness = 0xfffffe000070ef80}, lk_lock = 1, >>>> lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, >>>> mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers = >>>> {tqh_first = 0x0, tqh_last = 0xfffff8004733a320}} >>> >> >> Shadowed object: >> >>> (kgdb) p *$1->shadow_head->lh_first >>> $3 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm object", lo_flags = 90374144, lo_data = 0, lo_witness = 0xfffffe00006e7680}, rw_lock = 1}, object_list = {tqe_next = 0xfffff801b8b3ae00, >>> tqe_prev = 0xfffff802717bb120}, shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xfffff8027169f530}, memq = {tqh_first = 0xfffff811da2c75f8, tqh_last = 0xfffff811da2c7608}, >>> rtree = {rt_root = 18446735354291320313, rt_flags = 0 '\0'}, size = 1, generation = 1, ref_count = 1, shadow_count = 0, memattr = 6 '\006', type = 0 '\0', flags = 12288, pg_color = 1598, >>> paging_in_progress = 0, resident_page_count = 1, backing_object = 0xfffff8027169f500, backing_object_offset = 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {lh_first = 0x0}, cache = { >>> rt_root = 0, rt_flags = 0 '\0'}, handle = 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = { >>> sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0xfffff80038911800, charge = 4096} >> > > Try this > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 1b97bdf..bb01f00 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -559,8 +559,6 @@ vm_object_deallocate(vm_object_t object) > (object->handle == NULL) && > (object->type == OBJT_DEFAULT || > object->type == OBJT_SWAP)) { > - KASSERT((object->flags & OBJ_TMPFS_NODE) == 0, > - ("shadowed tmpfs v_object %p", object)); > vm_object_t robject; > > robject = LIST_FIRST(&object->shadow_head); > @@ -568,6 +566,8 @@ vm_object_deallocate(vm_object_t object) > ("vm_object_deallocate: ref_count: %d, shadow_count: %d", > object->ref_count, > object->shadow_count)); > + KASSERT((robject->flags & OBJ_TMPFS_NODE) == 0, > + ("shadowed tmpfs v_object %p", object)); > if (!VM_OBJECT_TRYWLOCK(robject)) { > /* > * Avoid a potential deadlock. > @@ -637,6 +637,8 @@ retry: > doterm: > temp = object->backing_object; > if (temp != NULL) { > + KASSERT((object->flags & OBJ_TMPFS_NODE) == 0, > + ("shadowed tmpfs v_object 2 %p", object)); > VM_OBJECT_WLOCK(temp); > LIST_REMOVE(object, shadow_list); > temp->shadow_count--; > Yup this avoids the panic. Thanks! -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 18:38:55 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 457DAF97; Wed, 23 Jul 2014 18:38:55 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 0B7792C37; Wed, 23 Jul 2014 18:38:55 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kx10so2246239pab.34 for ; Wed, 23 Jul 2014 11:38: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=fdpQ5OYsr4wrOPctsXCSDcXxz9pOUiym2ftIlQ2ZQkg=; b=egTLJlkI4L+5pYG/jY4O+cSQaJUXnMVX0w1vzDWboFtRBDwotCPO/JcdTtfcbPi2sL eC8V9rm5rZQjOL/899fNE/iBbKfSiTFGFFn4vvaigtgATsGZSXUOy/JFk2OJq7rLnk6J hcgB7Uwy/oTswMMcdMC/jX/MMreuo/TonNdjUsgP60QfxdsmqYhhVCKg7WJJZaa8Z1pC qEXITandoaUKBVmY5psz1VgNYhZBZ4VpLsQvffm5HaRpK/YNCFK2wqtTDoF6QU9Z0fLE GNNPdIKTUcO3NcdMws/H47035g/TCbH0vpCbZtf8kBcTTOBX1uEvbMz64WTrAyx1+xOZ SBPA== MIME-Version: 1.0 X-Received: by 10.70.34.228 with SMTP id c4mr4401394pdj.76.1406140734553; Wed, 23 Jul 2014 11:38:54 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.88.227 with HTTP; Wed, 23 Jul 2014 11:38:54 -0700 (PDT) In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> Date: Wed, 23 Jul 2014 11:38:54 -0700 X-Google-Sender-Auth: ptzte3N3-EyAPal4OTKO7I2n1us Message-ID: Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! From: Kevin Oberman To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "ports@FreeBSD.org" , FreeBSD Stable ML , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:38:55 -0000 On Wed, Jul 23, 2014 at 7:42 AM, Baptiste Daroussin wrote: > Hi all, > > I'm very please to announce the release of pkg 1.3.0 > This version is the result of almost 9 month of hard work > > Here are the statistics for the version: > - 373 files changed, 66973 insertions(+), 38512 deletions(-) > - 29 different contributors > > Please not that for the first time I'm not the main contributor, and I > would > like to particularly thanks Vsevold Stakhov for all the hard work he has > done to > allow us to get this release out. I would like also to give a special > thanks to > Andrej Zverev for the tons of hours spending on testing and cleaning the > bug > tracker! > > So much has happened that it is hard to summarize so I'll try to highligh= t > the > major points: > - New solver, now pkg has a real SAT solver able to automatically handle > conflicts and dynamically discover them. (yes pkg set -o is deprecated > now) > - pkg install now able to install local files as well and resolve their > dependencies from the remote repositories > - Lots of parts of the code has been sandboxed > - Lots of rework to improve portability > - Package installation process has been reworked to be safer and handle > properly > the schg flags > - Important modification of the locking system for finer grain locks > - Massive usage of libucl > - Simplification of the API > - Lots of improvements on the UI to provide a better user experience. > - Lots of improvements in multi repository mode > - pkg audit code has been moved into the library > - pkg -o A=3DB that will overwrite configuration file from cli > - The ui now support long options > - The unicity of a package is not anymore origin > - Tons of bug fixes > - Tons of behaviours fixes > - Way more! > > Thank you to all contributors: > Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davi= s, > Bryan Drewery, Dag-Erling Sm=C3=B8rgrav, Dmitry Marakasov, Elvira Khabiro= va, > Jamie > Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnol= d, > Matthew Seaman, Maximilian Ga=C3=9F, Michael Gehring, Michael Gmelin, Nic= olas > Szalay, > Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. > Putrya, > Vsevolod Stakhov, Xin Li, coctic > > Regards, > Bapt on behalf of the pkg@ > Really, really great news! Congrats to Bapt and all of the contributors, large and small, for doing the work to make this happen. The real, live, provable solver is something that was desperately needed. Thaqt is followed closely with multi-repository mode. All of the rest is great, too. I think one bullet was a bit mangled in French->English translation, though. What does "The unicity of a package is not anymore origin" mean? I have a couple of guesses, but I am not really sure. Ithink the best translations would be "The unicity of a package is no longer the origin", but I am unsure of "unicity". "Uniqueness"? That would make sense, but I am not quite sure that is what was meant. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 19:05:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3472A91F for ; Wed, 23 Jul 2014 19:05:13 +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 D47352EC5 for ; Wed, 23 Jul 2014 19:05:12 +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 s6NJ51p8093938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 23 Jul 2014 20:05:02 +0100 (BST) (envelope-from matthew@FreeBSD.org) Authentication-Results: lucid-nonsense.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk s6NJ51p8093938 Authentication-Results: smtp.infracaninophile.co.uk/s6NJ51p8093938; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral Message-ID: <53D00755.5020800@FreeBSD.org> Date: Wed, 23 Jul 2014 20:04:53 +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-current@freebsd.org Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gKD1MvVEWGSHH3Cp5oeOw8vs250t2HDb0" 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-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:05:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gKD1MvVEWGSHH3Cp5oeOw8vs250t2HDb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23/07/2014 19:38, Kevin Oberman wrote: > I think one bullet was a bit mangled in French->English translation, > though. What does "The unicity of a package is not anymore origin" mean= ? I > have a couple of guesses, but I am not really sure. Ithink the best > translations would be "The unicity of a package is no longer the origin= ", > but I am unsure of "unicity". "Uniqueness"? That would make sense, but = I am The unique key in the main 'packages' table in local.sqlite has been changed from just the package origin to a combination of the package origin and the package name. In essence, this means we can generate and handle several different packages from the same origin in the ports. Or in other words: *sub-packages*. While "unicity" is a legitimate English word, and it actually does mean pretty much exactly what Bapt wanted to express here, it isn't the way a native speaker would describe the concept. However I feel disinclined to criticize because I'd not have a hope of getting anywhere near the right way of saying that in French. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --gKD1MvVEWGSHH3Cp5oeOw8vs250t2HDb0 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) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJT0AddXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATOlYP/Rc5I8ppthnzX6N7XnKOxRnK hy2MCKVOYk98gGeeCIs6pL/ox1TvDLsECDBHgUkSXtfRL/LMYtezEti9W8PpiPLo gbEnT1naYMrF5LRutYWsZuo2/+RMgJQW7VqiXWv4zUHasnDq4b4AemX++ZNarrNA 75c6tzOVt5zb9zg/rkyXEn99Ih+e80TgO48i0W70gSvhV20qN1bou+VR7mp/HdOH OF7akV68Zr0KiEu0PTle8lWyshdCwwWQWs1pJxKu64n5ywEbzRmphx93TUb+ItPm +aZiR3RplPZAk7Fduk5H+AeFsYbkONafpNYP3Ax1er5ThzEBWWlDXKJZPXKDirq3 3t8V17vqsti0FTqBduo1NJJSdP5clz9SnCtayz2B+mqwXC7uEYFLdBHomS/vLtfH YmOPbSsNoP4X85egpH+S4kNgULLJM4BZYCN80HspYi2qVDWAZWDBlMveM6TueTMB wJzd10+Xkloo1d0w4sl1HSP90um9cy3emDgj8rc/ajnVYPStSYsCF1MpOSMhozUj AtrkSsbnFz0z2eZ+9+oOMRPI62c/xQ0c5LmYAhMuOSNGvsuCeVUjHFiqDUYOHjwu yRQuyiPnngNtE2DWJWm3U1bjYh2j2tWv4XaquzeTf0I8mm4OOfupEBGyxBxWhTLZ /9Zf7B/FCYkgz9F3fPge =VaMM -----END PGP SIGNATURE----- --gKD1MvVEWGSHH3Cp5oeOw8vs250t2HDb0-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 19:26:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39543203; Wed, 23 Jul 2014 19:26:35 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 09F4D20D1; Wed, 23 Jul 2014 19:26:35 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lf10so2308279pab.15 for ; Wed, 23 Jul 2014 12:26: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=JDcw4UXnUuLoZBtmeu9lpHgcyR8mVZXNoPlib4is1Ic=; b=rjs2MPT+ACcxh+eJqaKwFvh+jhRQdyMSRrp/4nkSN12a2HBpWsIWMNVsVoaMjZV0dy BSqVsJvME6HMuUSPgNe0ey7qyWMHpFtZlf+aLxPdT5lYfDRJ5roMxbeW+Qm2zgw3wCJO BVhjkvAU8YF78/DLAQ8oGf2FRViTVkgRTfaPYdPMQfA7LSjtlqL1j3lqyG4ziadIxkaX OYTrM8mEHSESRt+OYTL0VM6OLUzqe/Dfi+dZkMphX55LL8BjZydGTOX9Mz6nj4P2DoCN kfdGLJuUuOoKDdSQ0dvV3Xl0m1xm7PsP8AIypVI5J7iUJgasS8hR7upk0yMEMWj2gS1t 2N6Q== MIME-Version: 1.0 X-Received: by 10.68.143.100 with SMTP id sd4mr4737043pbb.76.1406143594550; Wed, 23 Jul 2014 12:26:34 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.88.227 with HTTP; Wed, 23 Jul 2014 12:26:34 -0700 (PDT) In-Reply-To: <53D00755.5020800@FreeBSD.org> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <53D00755.5020800@FreeBSD.org> Date: Wed, 23 Jul 2014 12:26:34 -0700 X-Google-Sender-Auth: WlOM4PK7SQh3vEiWeAP7wklpmcc Message-ID: Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! From: Kevin Oberman To: Matthew Seaman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:26:35 -0000 On Wed, Jul 23, 2014 at 12:04 PM, Matthew Seaman wrote: > On 23/07/2014 19:38, Kevin Oberman wrote: > > I think one bullet was a bit mangled in French->English translation, > > though. What does "The unicity of a package is not anymore origin" mean? > I > > have a couple of guesses, but I am not really sure. Ithink the best > > translations would be "The unicity of a package is no longer the origin", > > but I am unsure of "unicity". "Uniqueness"? That would make sense, but I > am > > The unique key in the main 'packages' table in local.sqlite has been > changed from just the package origin to a combination of the package > origin and the package name. > > In essence, this means we can generate and handle several different > packages from the same origin in the ports. Or in other words: > *sub-packages*. > > While "unicity" is a legitimate English word, and it actually does mean > pretty much exactly what Bapt wanted to express here, it isn't the way a > native speaker would describe the concept. However I feel disinclined > to criticize because I'd not have a hope of getting anywhere near the > right way of saying that in French. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. > PGP: http://www.infracaninophile.co.uk/pgpkey > Thanks! No criticism intended. I just was not sure I understood the point. You (and others) have cleared that up. Thanks! After carefully re-reading the definition of "unicity" as "the quality of the unique", I agree that ti is exactly the word Bapt wanted. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 19:33:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93A2C544; Wed, 23 Jul 2014 19:33:33 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id 40AF22181; Wed, 23 Jul 2014 19:33:33 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=W0/jygPWOP4vNGB1giqMd6hViTlTWopR5z2gXdBWnF4= c=1 sm=1 a=cQ5pcHtl6RgA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=QQ1ygdTaH2DBou8bubUA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 23 Jul 2014 13:33:32 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 578739BEA; Wed, 23 Jul 2014 12:33:32 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6NGLVZ8025718; Wed, 23 Jul 2014 09:21:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6NGJBQF025702; Wed, 23 Jul 2014 09:19:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407231619.s6NGJBQF025702@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Adrian Chadd Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message from Adrian Chadd of "Fri, 18 Jul 2014 12:07:19 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 2014 09:18:51 -0700 Cc: freebsd-current , krad , Gleb Smirnoff , =?UTF-8?B?R2Vycml0IEvDvGhu?= , FreeBSD Mailing List , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:33:33 -0000 In message , Adrian Chadd writes: > On 18 July 2014 07:34, krad wrote: > > that is true and I have not problem using man pages, however thats not the > > way most of the world work and search engines arent exactly new either. We > > should be trying to engage more people not less, and part of that is > > reaching out. > > Then do the port and maintain it. > > The problem isn't the desire to keep things up to date, it's a lack of > people who want that _and_ are willing/able to do it _and_ are funded > somehow. Funding is the issue. Sure, some of us maintain software because a personal need however without funding one has to fit maintaining software into whatever time is left. For those of us who do this without funding you manage to squeeze in an hour here or there. > So, please step up! We'll all love you for it. Many hands make light work. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 19:33:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADE64638; Wed, 23 Jul 2014 19:33:36 +0000 (UTC) Received: from smtp-out-05.shaw.ca (smtp-out-05.shaw.ca [64.59.134.13]) by mx1.freebsd.org (Postfix) with ESMTP id 694472182; Wed, 23 Jul 2014 19:33:36 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=/MiPqmMwFv6ha2ZBybe0ZU9m+O5sXPp7gEUgHVyRzyY= c=1 sm=1 a=cQ5pcHtl6RgA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=5o0Kwa6bAAAA:8 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=lYoFMBppS0s2PdiZhjwA:9 a=CjuIK1q_8ugA:10 a=fgf5PR_cwQYA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-05.shaw.ca with ESMTP; 23 Jul 2014 13:33:34 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 7317E9BED; Wed, 23 Jul 2014 12:33:34 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6NFh82X025373; Wed, 23 Jul 2014 08:43:08 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6NFgX4M025370; Wed, 23 Jul 2014 08:42:48 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407231542.s6NFgX4M025370@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Peter Wemm Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message from Peter Wemm of "Sat, 19 Jul 2014 19:59:23 -0700." <20381608.Hhy3QfhrOP@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 2014 08:42:23 -0700 Cc: Baptiste Daroussin , freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:33:36 -0000 In message <20381608.Hhy3QfhrOP@overcee.wemm.org>, Peter Wemm writes: > On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote: > > On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote: > > > On 2014-07-18 15:07, Adrian Chadd wrote: > > > > On 18 July 2014 07:34, krad wrote: > > > >> that is true and I have not problem using man pages, however tha= > ts not > > > >> the > > > >> way most of the world work and search engines arent exactly new = > either. > > > >> We > > > >> should be trying to engage more people not less, and part of tha= > t is > > > >> reaching out. > > > >=20 > > > > Then do the port and maintain it. > > > >=20 > > > > The problem isn't the desire to keep things up to date, it's a la= > ck of > > > > people who want that _and_ are willing/able to do it _and_ are fu= > nded > > > > somehow. > > > >=20 > > > > So, please step up! We'll all love you for it. > > > >=20 > > > >=20 > > > >=20 > > > > -a > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to > > > > "freebsd-current-unsubscribe@freebsd.org" > > >=20 > > > At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, = > after > > > spending some hours driving with Henning. > >=20 > > I tried and broke pf for month and my changes have been reverted, thi= > s is > > not as simple as it looks like, our code as diverge a lot in some par= > t and > > we do support things that openbsd does not (vimage). Sync features re= > quires > > us to be very careful, my priorities went elsewhere since that time, = > so now > > I will probably only focus on bringing features I care about, and not= > the > > entirely new pf. > >=20 > > So no do not count me as volunteer to maintain pf, I ll probably do s= > ome > > work but not a full sync. > > If anyone is looking for a really useful chunk to work on, please go ba= > ck over=20 > the pf history in openbsd and find where they added ipv6 fragment suppo= > rt. It=20 > was fairly well contained and didn't appear to be a big deal to port. = > They=20 > did do something with mbuf tags that I'm suspicious of though. > > IPv6 fragments are the biggest pain point we have on the freebsd.org cl= > uster -=20 > yes, we use pf and IPv6 extensively, but dns with ipv6 involved is real= > ly=20 > painful without fragment support. > > We sort-of work around it by using dedicated IPv6 address that has noth= > ing but=20 > the dns resolver clients and allow ipv6 fragments to it. Its not idea= > l but=20 > it gets over the worst problems. > > The other thing we had to do for usability is stop state tracking for u= > dp dns=20 > =2D the sheer update rate was causing collisions and state drops / resets= > of=20 > other connections to the point of being really hard to use. > > Those two tweaks - stopping heavy dns use from thrashing the state tabl= > es, and=20 > having a safe place to send fragments makes it quite usable for freebsd= > .org. > > But, lack of ipv6 fragment processing still causes ongoing pain. That'= > s our=20 > #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 19:59:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C982252B; Wed, 23 Jul 2014 19:59:34 +0000 (UTC) Received: from smtp-out-05.shaw.ca (smtp-out-05.shaw.ca [64.59.134.13]) by mx1.freebsd.org (Postfix) with ESMTP id 8C58F23E9; Wed, 23 Jul 2014 19:59:34 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=/MiPqmMwFv6ha2ZBybe0ZU9m+O5sXPp7gEUgHVyRzyY= c=1 sm=1 a=cQ5pcHtl6RgA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=vaJtXVxTAAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=lO9lM-zxv49cNtxdN1AA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=Uj3LN2fX6ISbhkOz:21 a=w_Mmgyt-bqWFDcGS:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-05.shaw.ca with ESMTP; 23 Jul 2014 13:59:33 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id D35B79BE8; Wed, 23 Jul 2014 12:59:32 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6NJxVSO090905; Wed, 23 Jul 2014 12:59:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6NJxUb6090902; Wed, 23 Jul 2014 12:59:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407231959.s6NJxUb6090902@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: "Andrey V. Elsukov" Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message from "Andrey V. Elsukov" of "Mon, 21 Jul 2014 15:12:22 +0400." <53CCF596.1070302@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 2014 12:59:30 -0700 Cc: Maxim Khitrov , freebsd-current@freebsd.org, FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:59:35 -0000 In message <53CCF596.1070302@yandex.ru>, "Andrey V. Elsukov" writes: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > On 20.07.2014 18:15, Maxim Khitrov wrote: > > In my opinion, the way forward is to forget (at least temporarily) the > > SMP changes, bring pf in sync with OpenBSD, put a policy in place to > > follow their releases as closely as possible, and then try to > > reintroduce all the SMP work. I think the latter has to be done > > upstream, otherwise it'll always be a story of diverging codebases. > > Furthermore, if FreeBSD developers were willing to spend some time > > improving pf performance on OpenBSD, then Henning and other OpenBSD > > developers might be more receptive to changes that make the porting > > process easier. > > Even if you just drop current PF from FreeBSD, there is nobody, who want > to port new PF from OpenBSD. And this is not easy task, as you may > think. Gleb has worked on rewriting PF more than half year. So, return > back all improvements after import will be hard enough and, again, > nobody want to do it. :) One way or another something needs to be done and agreed it would be a lot of work. Our options are, a) Import OpenBSD pf thereby throwing away our current investment in pf. All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would be all for naught. We do get a new pf though. Won't be a quality port though. Personally, not my #1 option. b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we do save the work we put into our pf. Once again a lot of work. We'd be introducing incompatibility. c) Do nothing. It goes without saying that pf would suffer rot and eventually we would need to do something. d) Yank pf from tree. An option but probably not a great one. We do have two other packet filters in the kernel (ipfw and ipfilter) however they are different beasts with different capabilities. I think the reason we have the packet filters we do have is for the capabilities they bring to the table. I for one have run more than one in the same kernel because each has different capabilities. e) We could add capability to pf on a piecemeal basis. Option (b) but as time permits. Remember, people have jobs and commitments. Funding would help address this. f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more compatible with our IP stack? Could this be an option? Anything we do should work with VIMAGE and be able to handle nat66 as well. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:08:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33AC392F; Wed, 23 Jul 2014 20:08:12 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id DEF7A24D4; Wed, 23 Jul 2014 20:08:11 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=W0/jygPWOP4vNGB1giqMd6hViTlTWopR5z2gXdBWnF4= c=1 sm=1 a=cQ5pcHtl6RgA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=RJp7PVBWAAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=r83zQBVX6GhAEvYNhSoA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 23 Jul 2014 14:08:10 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 925929BE8; Wed, 23 Jul 2014 13:08:10 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6NK897a091257; Wed, 23 Jul 2014 13:08:09 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6NK87MX091253; Wed, 23 Jul 2014 13:08:07 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407232008.s6NK87MX091253@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Daniel Feenberg Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message from Daniel Feenberg of "Sun, 20 Jul 2014 14:35:26 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 2014 13:08:05 -0700 Cc: krad , Lars Engels , freebsd-current@freebsd.org, Stephen Hurd , Gleb Smirnoff , =?ISO-8859-15?Q?Gerrit_K=FChn?= , FreeBSD Mailing List , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:08:12 -0000 In message , Daniel Feenberg writes: > > > On Sun, 20 Jul 2014, Lars Engels wrote: > > > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: > >> all of that is true, but you are missing the point. Having two versions of > >> pf on the bsd's at the user level, is a bad thing. It confuses people, > >> which puts them off. Its a classic case of divide an conquer for other > >> platforms. I really like the idea of the openpf version, that has been > >> mentioned in this thread. It would be awesome if it ended up as a supporte > d > >> linux thing as well, so the world could be rid of iptables. However i gues > s > >> thats just an unrealistic dream > > > > And you don't seem to get the point that _someone_ has to do the work. > > No one has stepped up so far, so nothing is going to change. > > > > No one with authority has yet said that "If an updated pf were available, > would be welcomed". Rather they have said "An updated pf would not be > suitable, as it would be incompatible with existing configuration files". > If the latter is indeed the case, there is little incentive for anyone > to go to the effort of porting the newer pf. After all, the reward for > the work is chiefly in glory, and if there is to be no glory, the work > is unlikely to be done. I disagree. One does not do this for the glory. One does this because the nail hurts enough to do something about it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:18:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86A9A102 for ; Wed, 23 Jul 2014 20:18:56 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2251525E3 for ; Wed, 23 Jul 2014 20:18:55 +0000 (UTC) Received: from [192.168.0.143] ([95.91.231.240]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lcjgd-1Wlkj42Oox-00kBxV; Wed, 23 Jul 2014 22:18:53 +0200 Message-ID: <53D018AD.4080800@gmx.de> Date: Wed, 23 Jul 2014 22:18:53 +0200 From: Lokadamus User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Anders Bolt-Evensen , freebsd-current@freebsd.org Subject: Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI References: <53CBEC26.7080404@icloud.com> In-Reply-To: <53CBEC26.7080404@icloud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HAxCUccS/j9XLGr7CnxUB6vicDfsUi5aiqHV/qLXTymRNkpY++H Ul/Wc9NMXw9QJfkQ2IhLvlsTmBKY6g+RBLilp5AAdenmP7sFDuwO2cxgr6FK1c4spN0eSel nT4j0vR1KaabSW9Ugv5GImdo7d4FU7PibE/o00rTIZIHC7c0x0W/5Vs1By19/iAEiEH4chl boGCXBiOOnUfawCgjXDRA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:18:56 -0000 Am 20.07.2014 18:19, schrieb Anders Bolt-Evensen: > Hello, everyone! > Last week, I created a custom ISO from the latest -CURRENT sources > which contained an EFI image that is bootable on my MacBook Pro. > Both installation and booting from this new FreeBSD 11 EFI system goes > without any problems. > However, I've also installed X11 and GNOME to get a graphical > environment to work with, and that's when my problem occurs. > > This computer has an Intel HD 3000 card as well as an AMD Radeon > Mobility HD 6770M card. > > The problem is that every time I start up X, using the Intel driver, > the screen freezes with a cursor in the top left corner of the screen. > In other words, the X windowing system does not show up at all. > Pressing i.e. alt+F2 to switch away from this screen does not work. > > .... > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off > drmn1: taking over the fictitious range 0xa0000000-0xb0000000 > fbd1 on drmn1 > VT: Replacing driver "efifb" with new "fb". > info: [drm] Initialized i915 1.6.0 20080730 1.6.0 20080730 looks old for me. Have a look at https://wiki.freebsd.org/Graphics section "Installing KMS Ports" Hope it helps Regards From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:39:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F374E8C8 for ; Wed, 23 Jul 2014 20:39:26 +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 AB45627FC for ; Wed, 23 Jul 2014 20:39:26 +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 7E95B25D3897; Wed, 23 Jul 2014 20:39:23 +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 3FF9BC24020; Wed, 23 Jul 2014 20:39:22 +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 6SP563jOq0T3; Wed, 23 Jul 2014 20:39:20 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:84e6:ae89:68a6:d418] (unknown [IPv6:fde9:577b:c1a9:4410:84e6:ae89:68a6:d418]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 7B46ABFDDA0; Wed, 23 Jul 2014 20:39:18 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: "Bjoern A. Zeeb" In-Reply-To: <201407231542.s6NFgX4M025370@slippy.cwsent.com> Date: Wed, 23 Jul 2014 20:38:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <50E4E363-B2C0-4ED7-A0C4-2D7C69FF15B2@lists.zabbadoz.net> References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:39:27 -0000 On 23 Jul 2014, at 15:42 , Cy Schubert wrote: > Taking this discussion slightly sideways but touching on this thread a=20= > little, each of our packet filters will need nat66 support too. Pf = doesn't=20 > support it for sure. I've been told that ipfw may and I suspect = ipfilter=20 > doesn't as it was on Darren's todo list from 2009. our pf does support IPv6 prefix rewriting quite nicely and has for = years. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:40:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E269F9EC for ; Wed, 23 Jul 2014 20:40:52 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id BA6152810 for ; Wed, 23 Jul 2014 20:40:52 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C02E22AB17 for ; Wed, 23 Jul 2014 20:40:44 +0000 (UTC) Message-ID: <53D01DDD.8000806@freebsd.org> Date: Wed, 23 Jul 2014 16:41:01 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> <50E4E363-B2C0-4ED7-A0C4-2D7C69FF15B2@lists.zabbadoz.net> In-Reply-To: <50E4E363-B2C0-4ED7-A0C4-2D7C69FF15B2@lists.zabbadoz.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cJwmkE94vk3BjoX0RuEFnQx8sfem5efNC" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:40:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cJwmkE94vk3BjoX0RuEFnQx8sfem5efNC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-07-23 16:38, Bjoern A. Zeeb wrote: > On 23 Jul 2014, at 15:42 , Cy Schubert wrote= : >=20 >> Taking this discussion slightly sideways but touching on this thread a= =20 >> little, each of our packet filters will need nat66 support too. Pf doe= sn't=20 >> support it for sure. I've been told that ipfw may and I suspect ipfilt= er=20 >> doesn't as it was on Darren's todo list from 2009. >=20 > our pf does support IPv6 prefix rewriting quite nicely and has for year= s. >=20 > =97=20 > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 198= 3 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Bjoern: What IPv6 stuff does our pf not do well? --=20 Allan Jude --cJwmkE94vk3BjoX0RuEFnQx8sfem5efNC 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0B3gAAoJEJrBFpNRJZKfRZsP/3TS7cJ4HgMXqR+RckBImoFr uu9j8nR9dgAbptM3/H5GaHa7qdLZvBF+RfKH/zetplp/LHsSlPKgvFOc4RMZut6v Q7TrO2INNMQfEJexRXBFS9z3m1EvHYAqvr3WakaaOLNg9lmpQ3yTYght6BF9tP6V N8JxWmw1FTQ3MkfrxSf4NtkTC9pystSt3BqEdKa9qdpw1ZOE0eoiEfOgN85tZ0gn JcrBX5F0D8lCDVF7tGu/ZMwXTp1eTj0wl/WZwM3fXNWYBsOeiz1xFDiodpkiQ41A LYmX0Gr6kCkRTjUXiUmQYElMHzXZtgW8nHL4kjJLkSaoXNMkAqJTIFQbjdzigC1I 3uSgYLKmKlpuw/9KaH15r4DnzR0nu08DreQvHmNGT1J3uHHKuC3ab9wKUm46yqhl RmdJ1EJ+U2T8QZchOc/ZH9tctUgqxkTq7ttjtBwi3Ovi/55iJwAIulP9cPXqFN1h 2zX0NZLEawRMfT1B1nJmtBfm2m+XpNYmF6Rybq4XguMhZS4f9SdK6lmdgJDt6Zff pgASs1nDAvqduAo24t6Ki/0g9r0dVorlFsRnikXQ9YJxinHYdCtjoGSxNQeI8qYo mHaB1MCrlKeTFRerEuDhwFmQHvutNb7vtAbBVbFGaX62cevGv4wu50PW9DSFWk3H AUGjREbujluuH0s0i6R3 =qyXD -----END PGP SIGNATURE----- --cJwmkE94vk3BjoX0RuEFnQx8sfem5efNC-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:42:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51346B9D for ; Wed, 23 Jul 2014 20:42:58 +0000 (UTC) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtp003.mac.com [17.172.81.2]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F5BF28A1 for ; Wed, 23 Jul 2014 20:42:57 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from andersbo-mac.local (ti0025a400-5325.bb.online.no [85.167.91.221]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0N9600IXZK39BA40@st11p00mm-asmtp003.mac.com> for freebsd-current@freebsd.org; Wed, 23 Jul 2014 19:42:49 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-07-23_07:2014-07-23,2014-07-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407230235 Message-id: <53D01035.3000302@icloud.com> Date: Wed, 23 Jul 2014 21:42:45 +0200 From: Anders Bolt-Evensen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: David King Subject: Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI References: <53CBEC26.7080404@icloud.com> <2AE1EED7-8E9C-47EC-8AED-CDF446260E94@ketralnis.com> In-reply-to: <2AE1EED7-8E9C-47EC-8AED-CDF446260E94@ketralnis.com> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:42:58 -0000 What I did was: Install subversion either from ports or via pkg install Get the newest source code from FreeBSD by running the command svn checkout svn://svn.freebsd.org/base/head /usr/src (or whatever directory you might choose, I used /usr/src) Then I ran make buildworld from the new /usr/src directory. When make buildworld had completed, I cd-ed to /usr/src/release and ran sh ./generate-release.sh (this basically creates a chroot-ed environment, installs some tools, builds kernel and world and creates an ISO in /scratch/R/FreeBSD-something-disc1.iso). When the shell script generate-release.sh had completed, I ran the command mdconfig -a -t vnode -f /scratch/R/release/FreeBSD-something-disk1.iso -u 1 && mount -t cd9660 /dev/md1 /mnt. Then I created a new directory, /root/freebsd_generic_installer, copied the contents of /mnt/ to the new /root/freebsd_generic_installer directory and unmounted /mnt. The following commands are taken from https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI: > dd if=/dev/zero of=efiboot.img bs=4k count=100 > mdconfig -a -t vnode -f efiboot.img > newfs_msdos -F 12 -m 0xf8 -L "FREEBSD_EFI" /dev/md0 > mount -t msdosfs /dev/md0 /mnt > mkdir -p /mnt/efi/boot > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi > umount /mnt > mdconfig -d -u 0 Finally I created the new custom ISO by running the following command: makefs -t cd9660 -o bootimage='i386;efiboot.img' -o no-emul-boot -o rockridge -o label=“FREEBSD_UEFI_INSTALL" -o publisher="test" discname.iso /root/freebsd_generic_installer/ For the above example to work, please make sure that /root/freebsd_generic_installer/etc/fstab has the following entry: /dev/iso9660/FREEBSD_UEFI_INSTALL / cd9660 ro 0 0, otherwise, the boot of the install DVD will stop with a mount error. This is how I got the EFI FreeBSD installer to boot. On 21/07/14 22:11, David King wrote: >> Last week, I created a custom ISO from the latest -CURRENT sources which contained an EFI image that is bootable on my MacBook Pro. >> Both installation and booting from this new FreeBSD 11 EFI system goes without any problems. > Somewhat off-topic, but can you detail how you did this? I've been at this unsuccessfully. Did you just do this ? From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:59:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2EAE1B0; Wed, 23 Jul 2014 20:59:48 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (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 7560629A5; Wed, 23 Jul 2014 20:59:48 +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 DB01C25D3871; Wed, 23 Jul 2014 20:59:44 +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 0EDB0C23E85; Wed, 23 Jul 2014 20:59:44 +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 D0mrCKRinba8; Wed, 23 Jul 2014 20:59:42 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:84e6:ae89:68a6:d418] (unknown [IPv6:fde9:577b:c1a9:4410:84e6:ae89:68a6:d418]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5BEE6C23E65; Wed, 23 Jul 2014 20:59:40 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: "Bjoern A. Zeeb" In-Reply-To: <53D01DDD.8000806@freebsd.org> Date: Wed, 23 Jul 2014 20:59:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> <50E4E363-B2C0-4ED7-A0C4-2D7C69FF15B2@lists.zabbadoz.net> <53D01DDD.8000806@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:59:48 -0000 On 23 Jul 2014, at 20:41 , Allan Jude wrote: > On 2014-07-23 16:38, Bjoern A. Zeeb wrote: >> On 23 Jul 2014, at 15:42 , Cy Schubert = wrote: >>=20 >>> Taking this discussion slightly sideways but touching on this thread = a=20 >>> little, each of our packet filters will need nat66 support too. Pf = doesn't=20 >>> support it for sure. I've been told that ipfw may and I suspect = ipfilter=20 >>> doesn't as it was on Darren's todo list from 2009. >>=20 >> our pf does support IPv6 prefix rewriting quite nicely and has for = years. >=20 > Bjoern: What IPv6 stuff does our pf not do well? I think the most pressing, as Peter said, is fragment handling, though a = good fraction of major content providers seems to do mss clamping to a = min IPv6 mtu on IPv6 and drop fragments at the edge (not much different = to IPv4, which makes you wonder?). Whoever is clever will think of = how many different queueing and fragment handling implementations we = need in the kernel, and how often we have to do it on an end node that = might also run a firewall, pick one we have, turn it into a library = thing, apply it to all places, and then add the latest IETF suggestions = on top of it. There was (is?) another case that in certain situations with certain pf = options IPv6/ULP packets would not pass or get corrupted. I think no = one who experienced it never tracked it down to the code but I am sure = there are PRs for this; best bet is that not all header sizes are equal = and length/offsets into IPv6 packets are different to IPv4, especially = when you scrub. Apart from that my knowledge of pf is diminishing. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 21:14:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C04B4640; Wed, 23 Jul 2014 21:14:04 +0000 (UTC) Received: from relay.mailchannels.net (ar-005-i202.relay.mailchannels.net [162.253.144.84]) by mx1.freebsd.org (Postfix) with ESMTP id F074D2B11; Wed, 23 Jul 2014 21:14:03 +0000 (UTC) X-Sender-Id: _forwarded-from|107.201.34.133 Received: from mail-24.name-services.com (unknown [10.204.17.9]) by relay.mailchannels.net (Postfix) with ESMTPA id A14DE101029; Wed, 23 Jul 2014 21:05:43 +0000 (UTC) X-Sender-Id: _forwarded-from|107.201.34.133 Received: from mail-24.name-services.com (mail-24.name-services.com [10.253.92.5]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:2500 (trex/5.2.12); Wed, 23 Jul 2014 21:05:44 GMT X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|107.201.34.133 X-MailChannels-Auth-Id: demandmedia Received: from [10.0.10.1] (107-201-34-133.lightspeed.bcvloh.sbcglobal.net [107.201.34.133]) by mail-24.name-services.com with SMTP; Wed, 23 Jul 2014 14:05:36 -0700 Message-ID: <53D0239D.1050906@a1poweruser.com> Date: Wed, 23 Jul 2014 17:05:33 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Cy Schubert Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <201407231959.s6NJxUb6090902@slippy.cwsent.com> In-Reply-To: <201407231959.s6NJxUb6090902@slippy.cwsent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Khitrov , "Andrey V. Elsukov" , FreeBSD Mailing List , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:14:04 -0000 Cy Schubert wrote: > In message <53CCF596.1070302@yandex.ru>, "Andrey V. Elsukov" writes: >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> >> On 20.07.2014 18:15, Maxim Khitrov wrote: >>> In my opinion, the way forward is to forget (at least temporarily) the >>> SMP changes, bring pf in sync with OpenBSD, put a policy in place to >>> follow their releases as closely as possible, and then try to >>> reintroduce all the SMP work. I think the latter has to be done >>> upstream, otherwise it'll always be a story of diverging codebases. >>> Furthermore, if FreeBSD developers were willing to spend some time >>> improving pf performance on OpenBSD, then Henning and other OpenBSD >>> developers might be more receptive to changes that make the porting >>> process easier. >> Even if you just drop current PF from FreeBSD, there is nobody, who want >> to port new PF from OpenBSD. And this is not easy task, as you may >> think. Gleb has worked on rewriting PF more than half year. So, return >> back all improvements after import will be hard enough and, again, >> nobody want to do it. :) > > One way or another something needs to be done and agreed it would be a lot > of work. Our options are, > > a) Import OpenBSD pf thereby throwing away our current investment in pf. > All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would > be all for naught. We do get a new pf though. Won't be a quality port > though. Personally, not my #1 option. > > b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we > do save the work we put into our pf. Once again a lot of work. We'd be > introducing incompatibility. > > c) Do nothing. It goes without saying that pf would suffer rot and > eventually we would need to do something. > > d) Yank pf from tree. An option but probably not a great one. We do have > two other packet filters in the kernel (ipfw and ipfilter) however they are > different beasts with different capabilities. I think the reason we have > the packet filters we do have is for the capabilities they bring to the > table. I for one have run more than one in the same kernel because each has > different capabilities. > > e) We could add capability to pf on a piecemeal basis. Option (b) but as > time permits. Remember, people have jobs and commitments. Funding would > help address this. > > f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more > compatible with our IP stack? Could this be an option? > > Anything we do should work with VIMAGE and be able to handle nat66 as well. > > Hello Cy; Finally a voice I recognize. If I remember correctly you stepped up to the plate earlier this year and did for ipfilter the same kind of things this thread is talking about for pf. IE; apply upstream maintenance and convert to FreeBSD standards. I think your work was a BSD fork of Darrow's ipfilter which from this point on all upstream maintenance must be hand merged into the BSD fork. I am a long time ipfilter user and thank you for your dedication and work ethics getting the updated ipfilter into 10.0 and 9.3 so quickly. So as someone who has been there and done that already you have unique experience to really know the size of the task in hours to accomplish a pf upgrade. Could you list the tasks and hours it took you to perform the ipfilter upgrade so readers can have a real insight into what they are asking for? I agree with your option "e" above, but I would re-word it this way. Using the pf fork we already have in place, hand merge upstream differences in piecemeal chunks as time permits. The openbsd new syntax being the first chunk, closely followed by VIMAGE awareness. When it comes to someone volunteering to do the work, many of us would step up, but the fact is only a very very few people have the coding and kernel knowledge to even consider doing this. From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:56:51 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66A53E6F; Wed, 23 Jul 2014 20:56:51 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::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 BCAD72988; Wed, 23 Jul 2014 20:56:50 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x48so1799528wes.5 for ; Wed, 23 Jul 2014 13:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2D8vYzYf6hSQZam35j3wSlKqaVS9pD82EnHA90osGEM=; b=FiakQsMiDqfJzExfwnX28pxPD+gSULdMga/KsDMM4P6XI058c31q7NwgjsSf0J1ZAp iur7gXDAJ0a6BxjsM4HrDzZboNe6/61cptsfeBNlkgX1yFhtdYQuwmlrGraxFKaABlfk mWLthBj+fcxXMwFpZFqHc7Fu8qYjQNZ0jN6ZjjQ77606/SSTyFLL3qlzXYbQGsxmZ5wy KS0MYUQyTVuph1MiZISMHiVeMmil5IzX8AjJU4cPxDNyhlHvFILGebYETRG7/XSqYtFQ +SM7IkXGN4vsrCj1pexRQapWQOT+T25AV7f5jHNPDuV+kKERC3SUSV/MjNlYrauKx+mJ XkTQ== X-Received: by 10.194.221.6 with SMTP id qa6mr5383868wjc.39.1406149008627; Wed, 23 Jul 2014 13:56:48 -0700 (PDT) Received: from [192.168.0.20] (178-83-152-199.dynamic.hispeed.ch. [178.83.152.199]) by mx.google.com with ESMTPSA id pj6sm9354556wjb.21.2014.07.23.13.56.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:56:47 -0700 (PDT) From: Mattia Rossi X-Google-Original-From: Mattia Rossi Message-ID: <53D0218E.3080204@gmail.com> Date: Wed, 23 Jul 2014 22:56:46 +0200 Reply-To: mattia.rossi.mate@gmail.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bryan Drewery , Konstantin Belousov Subject: Re: r268621: panic: shadowed tmpfs v_object [with dump] References: <53CED27C.4080306@FreeBSD.org> <53CED29F.1090809@FreeBSD.org> <53CED718.2090108@FreeBSD.org> <53CEDD74.9070804@FreeBSD.org> <20140723141122.GG93733@kib.kiev.ua> <53CFDF0B.1080904@FreeBSD.org> In-Reply-To: <53CFDF0B.1080904@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 23 Jul 2014 21:14:07 +0000 Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:56:51 -0000 Got the same panic, is this fix getting committed? Or has it already been committed? Mat On 23/07/14 18:12, Bryan Drewery wrote: > On 7/23/14, 7:11 AM, Konstantin Belousov wrote: >> On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote: >>> On 7/22/14, 2:26 PM, Bryan Drewery wrote: >>>> On 7/22/14, 2:07 PM, Bryan Drewery wrote: >>>>> Meant to send to current@, moving there. >>>>> >>>>> On 7/22/14, 2:07 PM, Bryan Drewery wrote: >>>>>> On r268621: >>>>>> >>>>>>> panic: shadowed tmpfs v_object 0xfffff807a7f96600 >>>>>>> cpuid = 0 >>>>>>> KDB: stack backtrace: >>>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>>>>> 0xfffffe1247d67390 >>>>>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 >>>>>>> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 >>>>>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 >>>>>>> vm_object_deallocate() at vm_object_deallocate+0x236/frame >>>>>>> 0xfffffe1247d67550 >>>>>>> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 >>>>>>> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 >>>>>>> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 >>>>>>> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 >>>>>>> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 >>>>>>> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 >>>>>>> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame >>>>>>> 0xfffffe1247d676e0 >>>>>>> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 >>>>>>> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 >>>>>>> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 >>>>>>> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 >>>>>>> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 >>>>>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 >>>>>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 >>>>>>> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, >>>>>>> rsp = >>>>>>> 0x7fffffffe238, rbp = 0x7fffffffe710 --- >>>>>>> Uptime: 6d4h0m3s >>>>>>> >>>>>>> Dump failed. Partition too small. >>>>>> >>>>>> Unfortunately I have no dump to debug. >>>>>> >>>>> >>>> Running poudriere again after boot hit the issue right away: >>>> >>>> >>>>> (kgdb) bt >>>>> #0 doadump (textdump=1) at pcpu.h:219 >>>>> #1 0xffffffff809122a7 in kern_reboot (howto=260) at >>>>> /usr/src/sys/kern/kern_shutdown.c:445 >>>>> #2 0xffffffff809127e5 in vpanic (fmt=, >>>>> ap=>>>> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744 >>>>> #3 0xffffffff80912679 in kassert_panic (fmt=>>>> out>) at >>>>> /usr/src/sys/kern/kern_shutdown.c:632 >>>>> #4 0xffffffff80ba7996 in vm_object_deallocate (object=>>>> optimized out>) at /usr/src/sys/vm/vm_object.c:562 >>>>> #5 0xffffffff820a75a8 in tmpfs_free_node (tmp=0xfffff800b5155980, >>>>> node=0xfffff802716ba740) at >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335 >>>>> #6 0xffffffff820a363d in tmpfs_reclaim (v=) at >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276 >>>>> #7 0xffffffff80e48717 in VOP_RECLAIM_APV (vop=, >>>>> a=) at vnode_if.c:2017 >>>>> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at >>>>> vnode_if.h:830 >>>>> #9 0xffffffff809c18be in vrecycle (vp=0xfffff802716b61d8) at >>>>> /usr/src/sys/kern/vfs_subr.c:2655 >>>>> #10 0xffffffff820a61cc in tmpfs_inactive (v=) at >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242 >>>>> #11 0xffffffff80e485b7 in VOP_INACTIVE_APV (vop=>>>> out>, >>>>> a=) at vnode_if.c:1951 >>>>> #12 0xffffffff809bfd36 in vinactive (vp=0xfffff802716b61d8, >>>>> td=0xfffff80187e29920) at vnode_if.h:807 >>>>> #13 0xffffffff809c012a in vputx (vp=0xfffff802716b61d8, func=2) at >>>>> /usr/src/sys/kern/vfs_subr.c:2267 >>>>> #14 0xffffffff820a47c5 in tmpfs_rename (v=) at >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023 >>>>> #15 0xffffffff80e47d3c in VOP_RENAME_APV (vop=, >>>>> a=) at vnode_if.c:1544 >>>>> #16 0xffffffff809cc77f in kern_renameat (td=, >>>>> oldfd=, old=, newfd=>>>> optimized out>, new=, >>>>> pathseg=) at vnode_if.h:636 >>>>> #17 0xffffffff80d280fa in amd64_syscall (td=0xfffff80187e29920, >>>>> traced=0) at subr_syscall.c:133 >>>>> #18 0xffffffff80d0a64b in Xfast_syscall () at >>>>> /usr/src/sys/amd64/amd64/exception.S:407 >>>>> (kgdb) p *(vm_object_t)0xfffff8027169f500 >>>>> $1 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm >>>>> object", >>>>> lo_flags = 90374144, lo_data = 0, lo_witness = 0xfffffe00006e7680}, >>>>> rw_lock = 18446735284191271200}, object_list = { >>>>> tqe_next = 0xfffff8027169f400, tqe_prev = 0xfffff8027169f620}, >>>>> shadow_head = {lh_first = 0xfffff801b8489e00}, shadow_list = {le_next >>>>> = 0x0, le_prev = 0x0}, memq = {tqh_first = 0xfffff811d966bc08, >>>>> tqh_last = 0xfffff811d966bc18}, rtree = {rt_root = >>>>> 18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1, >>>>> ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001', >>>>> flags = 528, pg_color = 0, paging_in_progress = 0, >>>>> resident_page_count = 1, backing_object = 0x0, >>>>> backing_object_offset = >>>>> 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { >>>>> lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, >>>>> handle >>>>> = 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp = >>>>> {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, >>>>> dev = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last = >>>>> 0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0x0, >>>>> charge = 0} >>>>> (kgdb) frame 8 >>>>> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at >>>>> vnode_if.h:830 >>>>> 830 return (VOP_RECLAIM_APV(vp->v_op, &a)); >>>>> (kgdb) p *vp >>>>> $2 = {v_tag = 0xffffffff820abf96 "tmpfs", v_op = 0xffffffff820ac938, >>>>> v_data = 0x0, v_mount = 0xfffff8004733a000, v_nmntvnodes = >>>>> {tqe_next = >>>>> 0xfffff802716b6000, tqe_prev = 0xfffff802716b63d0}, v_un = { >>>>> vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = >>>>> 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = >>>>> {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, >>>>> tqh_last = 0xfffff802716b6228}, v_cache_dd = 0x0, v_lock = >>>>> {lock_object = {lo_name = 0xffffffff820abf96 "tmpfs", lo_flags = >>>>> 116588544, lo_data = 0, lo_witness = 0xfffffe0000711980}, >>>>> lk_lock = 18446735284191271200, lk_exslpfail = 0, lk_timo = 51, >>>>> lk_pri = 96}, v_interlock = {lock_object = {lo_name = >>>>> 0xffffffff80fafc26 "vnode interlock", lo_flags = 16973824, lo_data >>>>> = 0, >>>>> lo_witness = 0xfffffe00006e7500}, mtx_lock = 4}, v_vnlock = >>>>> 0xfffff802716b6240, v_actfreelist = {tqe_next = 0xfffff80271898588, >>>>> tqe_prev = 0xfffff8004733a078}, v_bufobj = {bo_lock = { >>>>> lock_object = {lo_name = 0xffffffff80fb8084 "bufobj >>>>> interlock", >>>>> lo_flags = 86179840, lo_data = 0, lo_witness = 0xfffffe00006ef380}, >>>>> rw_lock = 1}, bo_ops = 0xffffffff814942a0, bo_object = 0x0, >>>>> bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = >>>>> 0xfffff802716b61d8, __bo_vnode = 0xfffff802716b61d8, bo_clean = >>>>> {bv_hd >>>>> = {tqh_first = 0x0, tqh_last = 0xfffff802716b62f8}, bv_root = { >>>>> pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = >>>>> 0x0, tqh_last = 0xfffff802716b6318}, bv_root = {pt_root = 0}, >>>>> bv_cnt = >>>>> 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 4096}, >>>>> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = >>>>> {rl_waiters = >>>>> {tqh_first = 0x0, tqh_last = 0xfffff802716b6360}, rl_currdep = 0x0}, >>>>> v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, >>>>> v_holdcnt = 2, v_usecount = 0, v_iflag = 2688, v_vflag = 0, >>>>> v_writecount = 0, v_hash = 40987489, v_type = VREG} >>>>> (kgdb) info locals >>>>> mp = (struct mount *) 0xfffff8004733a000 >>>>> fromnd = {ni_dirp = 0x801006080
, >>>>> ni_segflg = UIO_USERSPACE, ni_rightsneeded = {cr_rights = >>>>> {144115188142965760, 288230376151711744}}, >>>>> ni_startdir = 0xfffff802716b63b0, ni_rootdir = 0xfffff8026b01a760, >>>>> ni_topdir = 0xfffff8026b01a760, ni_dirfd = -100, ni_strictrelative = >>>>> 0, ni_filecaps = {fc_rights = {cr_rights = {0, 0}}, >>>>> fc_ioctls = 0x0, fc_nioctls = -1, fc_fcntls = 0}, ni_vp = >>>>> 0xfffff80271898588, ni_dvp = 0xfffff802716b63b0, ni_pathlen = 1, >>>>> ni_next = 0xfffff80061ea501f "", ni_loopcnt = 0, ni_cnd = {cn_nameiop >>>>> = 2, >>>>> cn_flags = 67148812, cn_thread = 0xfffff80187e29920, cn_cred = >>>>> 0xfffff80038911800, cn_lkflags = 524288, cn_pnbuf = >>>>> 0xfffff80061ea5000 >>>>> "/var/run/ld-elf.so.hints.HTjP6A", >>>>> cn_nameptr = 0xfffff80061ea5009 "ld-elf.so.hints.HTjP6A", >>>>> cn_namelen = 22, cn_consume = 0}} >>>>> tond = {ni_dirp = 0x403e66
, >>>>> ni_segflg >>>>> = UIO_USERSPACE, ni_rightsneeded = {cr_rights = {144115188080051200, >>>>> 288230376151711744}}, ni_startdir = 0xfffff802716b63b0, >>>>> ni_rootdir = 0xfffff8026b01a760, ni_topdir = 0xfffff8026b01a760, >>>>> ni_dirfd = -100, ni_strictrelative = 0, ni_filecaps = {fc_rights = >>>>> {cr_rights = {0, 0}}, fc_ioctls = 0x0, fc_nioctls = -1, >>>>> fc_fcntls = 0}, ni_vp = 0xfffff802716b61d8, ni_dvp = >>>>> 0xfffff802716b63b0, ni_pathlen = 1, ni_next = 0xfffff80038d69418 "", >>>>> ni_loopcnt = 0, ni_cnd = {cn_nameiop = 3, cn_flags = 134257708, >>>>> cn_thread = 0xfffff80187e29920, cn_cred = 0xfffff80038911800, >>>>> cn_lkflags = 524288, cn_pnbuf = 0xfffff80038d69400 >>>>> "/var/run/ld-elf.so.hints", cn_nameptr = 0xfffff80038d69409 >>>>> "ld-elf.so.hints", >>>>> cn_namelen = 15, cn_consume = 0}} >>>>> rights = {cr_rights = {144115188080051200, 288230376151711744}} >>>>> mp = (struct mount *) 0xfffff8004733a000 >>>>> error = >>>>> fvp = >>>>> tvp = >>>>> tdvp = >>>>> (kgdb) p *mp >>>>> $9 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80f8fcec "struct >>>>> mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = >>>>> 0xfffffe00006e7a00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = { >>>>> tqe_next = 0xfffff80038fa9cc0, tqe_prev = 0xfffff80187b74ce8}, >>>>> mnt_op = 0xffffffff820ace60, mnt_vfc = 0xffffffff820acf80, >>>>> mnt_vnodecovered = 0xfffff801b853e760, mnt_syncer = >>>>> 0xfffff8026b01a588, >>>>> mnt_ref = 13206, mnt_nvnodelist = {tqh_first = 0xfffff8026b01a760, >>>>> tqh_last = 0xfffff802718985a8}, mnt_nvnodelistsize = 13205, >>>>> mnt_activevnodelist = {tqh_first = 0xfffff802716b61d8, >>>>> tqh_last = 0xfffff8026b01a648}, mnt_activevnodelistsize = 730, >>>>> mnt_writeopcount = 1, mnt_kern_flag = 0, mnt_flag = 4096, mnt_opt = >>>>> 0xfffff8000e59cc30, mnt_optnew = 0xfffff8001b9ea050, >>>>> mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = >>>>> 135, f_flags = 4096, f_bsize = 4096, f_iosize = 4096, f_blocks = >>>>> 1835008, f_bfree = 1738991, f_bavail = 1738991, f_files = 25690112, >>>>> f_ffree = 25676911, f_syncwrites = 0, f_asyncwrites = 0, >>>>> f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, >>>>> 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {-2029977843, >>>>> 135}}, f_charspare = '\0' , f_fstypename = >>>>> "tmpfs\000\000\000\000\000\000\000\000\000\000", f_mntfromname = >>>>> "tmpfs", '\0' , >>>>> f_mntonname = "/poudriere/data/.m/exp-10amd64-commit-test/01", >>>>> '\0' }, mnt_cred = 0xfffff80047478700, mnt_data = >>>>> 0xfffff800b5155980, mnt_time = 0, mnt_iosize_max = 65536, >>>>> mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 1147308587, >>>>> mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = >>>>> 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = { >>>>> lock_object = {lo_name = 0xffffffff80f8fd0f "explock", >>>>> lo_flags = >>>>> 108199936, lo_data = 0, lo_witness = 0xfffffe000070ef80}, lk_lock >>>>> = 1, >>>>> lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, >>>>> mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers = >>>>> {tqh_first = 0x0, tqh_last = 0xfffff8004733a320}} >>>> >>> >>> Shadowed object: >>> >>>> (kgdb) p *$1->shadow_head->lh_first >>>> $3 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm >>>> object", lo_flags = 90374144, lo_data = 0, lo_witness = >>>> 0xfffffe00006e7680}, rw_lock = 1}, object_list = {tqe_next = >>>> 0xfffff801b8b3ae00, >>>> tqe_prev = 0xfffff802717bb120}, shadow_head = {lh_first = >>>> 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xfffff8027169f530}, >>>> memq = {tqh_first = 0xfffff811da2c75f8, tqh_last = >>>> 0xfffff811da2c7608}, >>>> rtree = {rt_root = 18446735354291320313, rt_flags = 0 '\0'}, >>>> size = 1, generation = 1, ref_count = 1, shadow_count = 0, memattr >>>> = 6 '\006', type = 0 '\0', flags = 12288, pg_color = 1598, >>>> paging_in_progress = 0, resident_page_count = 1, backing_object >>>> = 0xfffff8027169f500, backing_object_offset = 0, pager_object_list >>>> = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {lh_first = 0x0}, cache = { >>>> rt_root = 0, rt_flags = 0 '\0'}, handle = 0x0, un_pager = {vnp >>>> = {vnp_size = 0, writemappings = 0}, devp = {devp_pglist = >>>> {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = { >>>> sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = >>>> {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0xfffff80038911800, >>>> charge = 4096} >>> >> >> Try this >> >> diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c >> index 1b97bdf..bb01f00 100644 >> --- a/sys/vm/vm_object.c >> +++ b/sys/vm/vm_object.c >> @@ -559,8 +559,6 @@ vm_object_deallocate(vm_object_t object) >> (object->handle == NULL) && >> (object->type == OBJT_DEFAULT || >> object->type == OBJT_SWAP)) { >> - KASSERT((object->flags & OBJ_TMPFS_NODE) == 0, >> - ("shadowed tmpfs v_object %p", object)); >> vm_object_t robject; >> >> robject = LIST_FIRST(&object->shadow_head); >> @@ -568,6 +566,8 @@ vm_object_deallocate(vm_object_t object) >> ("vm_object_deallocate: ref_count: %d, >> shadow_count: %d", >> object->ref_count, >> object->shadow_count)); >> + KASSERT((robject->flags & OBJ_TMPFS_NODE) == 0, >> + ("shadowed tmpfs v_object %p", object)); >> if (!VM_OBJECT_TRYWLOCK(robject)) { >> /* >> * Avoid a potential deadlock. >> @@ -637,6 +637,8 @@ retry: >> doterm: >> temp = object->backing_object; >> if (temp != NULL) { >> + KASSERT((object->flags & OBJ_TMPFS_NODE) == 0, >> + ("shadowed tmpfs v_object 2 %p", object)); >> VM_OBJECT_WLOCK(temp); >> LIST_REMOVE(object, shadow_list); >> temp->shadow_count--; >> > > Yup this avoids the panic. > > Thanks! > From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 23:31:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE22F4F3; Wed, 23 Jul 2014 23:31:42 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ADF6C2767; Wed, 23 Jul 2014 23:31:42 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6NNVfkE085893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 16:31:41 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6NNVeVf085892; Wed, 23 Jul 2014 16:31:40 -0700 (PDT) (envelope-from jmg) Date: Wed, 23 Jul 2014 16:31:40 -0700 From: John-Mark Gurney To: Rick Macklem Subject: Re: [RFC] Allow m_dup() to use JUMBO clusters Message-ID: <20140723233139.GR43962@funkthat.com> Mail-Followup-To: Rick Macklem , Hans Petter Selasky , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20140708005234.GJ45513@funkthat.com> <1065824414.8871880.1404850207148.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1065824414.8871880.1404850207148.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 23 Jul 2014 16:31:41 -0700 (PDT) Cc: Hans Petter Selasky , freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:31:43 -0000 Rick Macklem wrote this message on Tue, Jul 08, 2014 at 16:10 -0400: > I tried: > m = m_getjcl(M_NOWAIT..M_JUMPAGESIZE); > if (m == NULL) > m = getjcl(M_WAITOK..MCLBYTES); > when I was experimenting with MJUMPAGESIZE clusters for NFS and what happened > was the thread looped in the first m_getjcl() instead of returning NULL. > It is about 12 layers of function calls deep and most fail/return NULL, but > somewhere one of them decides to "try again". I didn't locate the location > of that and don't know if it would be safe to change it so that m_getjcl() > returns NULL for this case. So, I took a quick look at this, and I see a weird issue... In mb_ctor_mbuf in kern_mbuf.c, the how argument is passed to m_init instead of flags... how and flags SHOULD be the same, but it could be that uma could change how to something else and we are loosing _NOWAIT.. Also, m_getjcl is calling two different uma_zalloc_arg's, know which one would be useful... You should be able to verify this w/ dtrace pretty easily in your case.. Brief call path: m_getjcl -> uma_zalloc_arg -> mb_ctor_mbuf -> m_init -> m_pkthdr_init -> mac_mbuf_init -> m_tag_get or mac_mbuf_tag_init... I didn't trace it down beyond mac_mbuf_init.. Verifying that mac_mbuf_init still has M_NOWAIT would be good... -- 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-current@FreeBSD.ORG Thu Jul 24 08:48:44 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CF38919; Thu, 24 Jul 2014 08:48:44 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BEB625D0; Thu, 24 Jul 2014 08:48:43 +0000 (UTC) Received: from [192.168.0.7] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s6O8i2xu077662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 08:47:00 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! From: David Chisnall In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> Date: Thu, 24 Jul 2014 09:43:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140723144249.GD69907@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1878.6) Cc: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 08:48:44 -0000 Great news! I've been running the 1.3 prereleases for a while, and aside from one = hiccup in the early alphas, it's been a very pleasant experience. Thanks to all involved, David On 23 Jul 2014, at 15:42, Baptiste Daroussin wrote: > Hi all, >=20 > I'm very please to announce the release of pkg 1.3.0 > This version is the result of almost 9 month of hard work >=20 > Here are the statistics for the version: > - 373 files changed, 66973 insertions(+), 38512 deletions(-) > - 29 different contributors >=20 > Please not that for the first time I'm not the main contributor, and I = would > like to particularly thanks Vsevold Stakhov for all the hard work he = has done to > allow us to get this release out. I would like also to give a special = thanks to > Andrej Zverev for the tons of hours spending on testing and cleaning = the bug > tracker! >=20 > So much has happened that it is hard to summarize so I'll try to = highlight the > major points: > - New solver, now pkg has a real SAT solver able to automatically = handle > conflicts and dynamically discover them. (yes pkg set -o is = deprecated now) > - pkg install now able to install local files as well and resolve = their > dependencies from the remote repositories > - Lots of parts of the code has been sandboxed > - Lots of rework to improve portability > - Package installation process has been reworked to be safer and = handle properly > the schg flags > - Important modification of the locking system for finer grain locks > - Massive usage of libucl > - Simplification of the API > - Lots of improvements on the UI to provide a better user experience. > - Lots of improvements in multi repository mode > - pkg audit code has been moved into the library > - pkg -o A=3DB that will overwrite configuration file from cli > - The ui now support long options > - The unicity of a package is not anymore origin > - Tons of bug fixes > - Tons of behaviours fixes > - Way more! >=20 > Thank you to all contributors: > Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad = Davis, > Bryan Drewery, Dag-Erling Sm=F8rgrav, Dmitry Marakasov, Elvira = Khabirova, Jamie > Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu = Arnold, > Matthew Seaman, Maximilian Ga=DF, Michael Gehring, Michael Gmelin, = Nicolas Szalay, > Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. = Putrya, > Vsevolod Stakhov, Xin Li, coctic >=20 > Regards, > Bapt on behalf of the pkg@ From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 17:33:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF864E37; Thu, 24 Jul 2014 17:33:53 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 821882863; Thu, 24 Jul 2014 17:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=eJHyhypCjIR+hcRFcjlZEwwDMnZvYqDxx3KsjBXNAVI=; b=P7++1gyOyJQCEYCQ0sNqHLCl8pWsHp8XMse94h2cnrHYRTByIkFPO4hAMCm3zMDHjKMTyQ3absP5C3wIv4wlCf/n8tuJMMu9weeVAtc7H7WZvWGGmo3N86MYyZo+gLabAa3qzwC2FNE07XbSsmWxwEnYi39OuV4Dvgx537DEaZk=; Received: from localhost.lerctr.org ([127.0.0.1]:63418 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAMtr-000GSA-2f; Thu, 24 Jul 2014 12:33:52 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 12:33:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 12:33:50 -0500 From: Larry Rosenman To: freebsd-fs@freebsd.org, Freebsd current Subject: zfs send/recv: STILL invalid Backup Stream X-Priority: 1 (Highest) Message-ID: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:33:53 -0000 TRYING to use zfs send/recv between a 10-STABLE and an 11-CURRENT system, and receive the non-descript "invalid backup stream". borg.lerctr.org /home/ler $ sudo bin/backup-TBH-ZFS-initial.sh Password: receiving full stream of zroot@2014-07-24 into zroot/backups/TBH@2014-07-24 received 41.7KB stream in 300 seconds (142B/sec) receiving full stream of zroot/usr@2014-07-24 into zroot/backups/TBH/usr@2014-07-24 received 41.7KB stream in 1 seconds (41.7KB/sec) receiving full stream of zroot/usr/local@2014-07-24 into zroot/backups/TBH/usr/local@2014-07-24 received 2.81GB stream in 1116 seconds (2.58MB/sec) receiving full stream of zroot/usr/src@2014-07-24 into zroot/backups/TBH/usr/src@2014-07-24 cannot receive new filesystem stream: invalid backup stream borg.lerctr.org /home/ler $ cat bin/backup-TBH-ZFS-initial.sh #!/bin/sh DATE=`date "+%Y-%m-%d"` #DATE2=2013-03-24 #DATE2=`date -v "-1d" "+%Y-%m-%d"` # snap the source ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} # zfs copy the source to here. ssh root@tbh.lerctr.org "zfs send -R -D zroot@${DATE} | \ ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH\"" # make sure we NEVER allow the backup stuff to automount. /sbin/zfs list -H -t filesystem -r zroot/backups/TBH| \ awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh borg.lerctr.org /home/ler $ This has been happening for YEARS and I can't seem to interest anyone in fixing it. How can we get to the bottom of this? borg.lerctr.org /home/ler $ uname -a FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 r268982M: Tue Jul 22 10:14:59 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 borg.lerctr.org /home/ler $ ssh tbh uname -a FreeBSD thebighonker.lerctr.org 10.0-STABLE FreeBSD 10.0-STABLE #39 r269019M: Wed Jul 23 11:44:35 CDT 2014 root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/GENERIC amd64 borg.lerctr.org /home/ler $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 17:38:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E138B186 for ; Thu, 24 Jul 2014 17:38:00 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id A1A5828A8 for ; Thu, 24 Jul 2014 17:38:00 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C8F102C451 for ; Thu, 24 Jul 2014 17:37:58 +0000 (UTC) Message-ID: <53D1448C.40908@freebsd.org> Date: Thu, 24 Jul 2014 13:38:20 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zfs send/recv: STILL invalid Backup Stream References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> In-Reply-To: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="onGXlbDDQmSsE6c7p32TBCccxd0ED6Sqx" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:38:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --onGXlbDDQmSsE6c7p32TBCccxd0ED6Sqx Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-24 13:33, Larry Rosenman wrote: > TRYING to use zfs send/recv between a 10-STABLE and an 11-CURRENT > system, and receive the non-descript > "invalid backup stream". >=20 > borg.lerctr.org /home/ler $ sudo bin/backup-TBH-ZFS-initial.sh > Password: > receiving full stream of zroot@2014-07-24 into zroot/backups/TBH@2014-0= 7-24 > received 41.7KB stream in 300 seconds (142B/sec) > receiving full stream of zroot/usr@2014-07-24 into > zroot/backups/TBH/usr@2014-07-24 > received 41.7KB stream in 1 seconds (41.7KB/sec) > receiving full stream of zroot/usr/local@2014-07-24 into > zroot/backups/TBH/usr/local@2014-07-24 > received 2.81GB stream in 1116 seconds (2.58MB/sec) > receiving full stream of zroot/usr/src@2014-07-24 into > zroot/backups/TBH/usr/src@2014-07-24 > cannot receive new filesystem stream: invalid backup stream > borg.lerctr.org /home/ler $ cat bin/backup-TBH-ZFS-initial.sh > #!/bin/sh > DATE=3D`date "+%Y-%m-%d"` > #DATE2=3D2013-03-24 > #DATE2=3D`date -v "-1d" "+%Y-%m-%d"` > # snap the source > ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} > # zfs copy the source to here. > ssh root@tbh.lerctr.org "zfs send -R -D zroot@${DATE} | \ > ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH\"" > # make sure we NEVER allow the backup stuff to automount. > /sbin/zfs list -H -t filesystem -r zroot/backups/TBH| \ > awk '{printf "/sbin/zfs set canmount=3Dnoauto %s\n",$1}' | sh > borg.lerctr.org /home/ler $ >=20 > This has been happening for YEARS and I can't seem to interest anyone i= n > fixing it. >=20 > How can we get to the bottom of this? >=20 > borg.lerctr.org /home/ler $ uname -a > FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 r268982M:= > Tue Jul 22 10:14:59 CDT 2014 =20 > root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > borg.lerctr.org /home/ler $ ssh tbh uname -a > FreeBSD thebighonker.lerctr.org 10.0-STABLE FreeBSD 10.0-STABLE #39 > r269019M: Wed Jul 23 11:44:35 CDT 2014 =20 > root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/GENERIC amd64 > borg.lerctr.org /home/ler $ >=20 Try adding -v to the 'zfs send' and see if it gives you more detail. Can you also try this script for the replication: http://github.com/allanjude/zxfer --=20 Allan Jude --onGXlbDDQmSsE6c7p32TBCccxd0ED6Sqx 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0USPAAoJEJrBFpNRJZKfvnsP/ijWQlG578gegPIY3N5e4Ut2 ZnIERSpvKXmhSjB0FiaTbQMiYGRgs1cZCLzVqhANjKRBRAT9n9OgyuYjPpOhsuHv 6DOJJ3sC66PoayKMML9mrPDac0aFm1Yz5c5JBl/6r3veTqzYh6Ex0rnqyDK/nFPk Bzu1m6YyGLi4jt6wVGnYNB+rKMIWszJQu+KDzvd+nm7NfyPVkVdNsIfpgI178Q07 caJK9CIgIPVpVZ7CJQ0N3QU/pn/8eA5sh7VAibQv5tyNPVEkic7N8oE02w8VJuZy 5F4oQmSZReoP0aMwYB8FE0NIyCpISIcpkDu1cvMer0IpvBFnAixpto3tOmelnIri RCqAK70sVNKqtyDO671/OgJECYo2cWR51BjUeFQql+Hl0aoo207Mn/YuNagMDp0n 9lIVPOmhn0Wy76oplEP13mnJWsbH51HLtuprA5pIbA+04laXghf6tFZLOPSunqY4 duFdrhLVlH54iVkR5n2SA9qmCUqUAcSRtxt6QwZySkHuG7UGLn1J/WicTHQqtO2a qwFOlEn2zhIZh3zSscXWZEqEmABOKYV0erzBD8ZurMdDEblDrhJY6oC1PSY45OVP L9rlfFAYQDEAex1tx8yRNLskzX6TZfqtVYGhd7Na2pKAXqt/lgz2UrKa1dNnuKNI 23NhWgNTudyAYTsPFJPc =fS7y -----END PGP SIGNATURE----- --onGXlbDDQmSsE6c7p32TBCccxd0ED6Sqx-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 17:43:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 815B73E8; Thu, 24 Jul 2014 17:43:04 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 536412955; Thu, 24 Jul 2014 17:43:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=QTuVNbiiO/NZzU8A8SZ4Jw6ZFexL6HmGNnGxdVRqyIc=; b=VOFdOOLCvg2xrRnAqTT22lQcHpogb/aV5tohOFbDFDfCMC5VYy/k9Re6wJ7QFcbpa8Tci44/oS+P6kC8Nawap0b7hjeTtV17LmDmaNxvhVmA4BMKHHq2tzx935boAYcgZSGZBz/T7J009XlNvcFIGaiXF30VtN0rktConbx4YnA=; Received: from localhost.lerctr.org ([127.0.0.1]:26447 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAN2j-000GcH-AY; Thu, 24 Jul 2014 12:43:03 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 12:43:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 12:43:01 -0500 From: Larry Rosenman To: Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <53D1448C.40908@freebsd.org> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:43:04 -0000 On 2014-07-24 12:38, Allan Jude wrote: > On 2014-07-24 13:33, Larry Rosenman wrote: >> TRYING to use zfs send/recv between a 10-STABLE and an 11-CURRENT >> system, and receive the non-descript >> "invalid backup stream". >> >> borg.lerctr.org /home/ler $ sudo bin/backup-TBH-ZFS-initial.sh >> Password: >> receiving full stream of zroot@2014-07-24 into >> zroot/backups/TBH@2014-07-24 >> received 41.7KB stream in 300 seconds (142B/sec) >> receiving full stream of zroot/usr@2014-07-24 into >> zroot/backups/TBH/usr@2014-07-24 >> received 41.7KB stream in 1 seconds (41.7KB/sec) >> receiving full stream of zroot/usr/local@2014-07-24 into >> zroot/backups/TBH/usr/local@2014-07-24 >> received 2.81GB stream in 1116 seconds (2.58MB/sec) >> receiving full stream of zroot/usr/src@2014-07-24 into >> zroot/backups/TBH/usr/src@2014-07-24 >> cannot receive new filesystem stream: invalid backup stream >> borg.lerctr.org /home/ler $ cat bin/backup-TBH-ZFS-initial.sh >> #!/bin/sh >> DATE=`date "+%Y-%m-%d"` >> #DATE2=2013-03-24 >> #DATE2=`date -v "-1d" "+%Y-%m-%d"` >> # snap the source >> ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} >> # zfs copy the source to here. >> ssh root@tbh.lerctr.org "zfs send -R -D zroot@${DATE} | \ >> ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH\"" >> # make sure we NEVER allow the backup stuff to automount. >> /sbin/zfs list -H -t filesystem -r zroot/backups/TBH| \ >> awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh >> borg.lerctr.org /home/ler $ >> >> This has been happening for YEARS and I can't seem to interest anyone >> in >> fixing it. >> >> How can we get to the bottom of this? >> >> borg.lerctr.org /home/ler $ uname -a >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 >> r268982M: >> Tue Jul 22 10:14:59 CDT 2014 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >> borg.lerctr.org /home/ler $ ssh tbh uname -a >> FreeBSD thebighonker.lerctr.org 10.0-STABLE FreeBSD 10.0-STABLE #39 >> r269019M: Wed Jul 23 11:44:35 CDT 2014 >> root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/GENERIC amd64 >> borg.lerctr.org /home/ler $ >> > > Try adding -v to the 'zfs send' and see if it gives you more detail. > > Can you also try this script for the replication: > > http://github.com/allanjude/zxfer I've done that in the past and nothing, but I will try again. I will also look at zxfer.... :) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 18:25:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D58C916C; Thu, 24 Jul 2014 18:25:21 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4D6E2D23; Thu, 24 Jul 2014 18:25:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=iyZmSjZ19dk3Zw9M1BwVpgSoQMLU1DbqhGW666oWCc0=; b=CcrSxzmn7nCFZtWGuF7dHvluzt3RRlyjbibg6gdBL6J9j1q5E1NRq3qKKPu7SeTyT4RAynAgONX+9A6rgTGZ9Ec9oqLt5dJ+ZazpJgXf7MxqcvmnICmCecONmR5KHiGOKziAHAddT/xxrxhDl7j21EQjoDWSlF4crKifMNJieiE=; Received: from localhost.lerctr.org ([127.0.0.1]:47248 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XANhe-000HN6-PM; Thu, 24 Jul 2014 13:25:20 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 13:25:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 13:25:18 -0500 From: Larry Rosenman To: Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:25:21 -0000 On 2014-07-24 12:43, Larry Rosenman wrote: > On 2014-07-24 12:38, Allan Jude wrote: >> On 2014-07-24 13:33, Larry Rosenman wrote: >>> TRYING to use zfs send/recv between a 10-STABLE and an 11-CURRENT >>> system, and receive the non-descript >>> "invalid backup stream". >>> >>> borg.lerctr.org /home/ler $ sudo bin/backup-TBH-ZFS-initial.sh >>> Password: >>> receiving full stream of zroot@2014-07-24 into >>> zroot/backups/TBH@2014-07-24 >>> received 41.7KB stream in 300 seconds (142B/sec) >>> receiving full stream of zroot/usr@2014-07-24 into >>> zroot/backups/TBH/usr@2014-07-24 >>> received 41.7KB stream in 1 seconds (41.7KB/sec) >>> receiving full stream of zroot/usr/local@2014-07-24 into >>> zroot/backups/TBH/usr/local@2014-07-24 >>> received 2.81GB stream in 1116 seconds (2.58MB/sec) >>> receiving full stream of zroot/usr/src@2014-07-24 into >>> zroot/backups/TBH/usr/src@2014-07-24 >>> cannot receive new filesystem stream: invalid backup stream >>> borg.lerctr.org /home/ler $ cat bin/backup-TBH-ZFS-initial.sh >>> #!/bin/sh >>> DATE=`date "+%Y-%m-%d"` >>> #DATE2=2013-03-24 >>> #DATE2=`date -v "-1d" "+%Y-%m-%d"` >>> # snap the source >>> ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} >>> # zfs copy the source to here. >>> ssh root@tbh.lerctr.org "zfs send -R -D zroot@${DATE} | \ >>> ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH\"" >>> # make sure we NEVER allow the backup stuff to automount. >>> /sbin/zfs list -H -t filesystem -r zroot/backups/TBH| \ >>> awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh >>> borg.lerctr.org /home/ler $ >>> >>> This has been happening for YEARS and I can't seem to interest anyone >>> in >>> fixing it. >>> >>> How can we get to the bottom of this? >>> >>> borg.lerctr.org /home/ler $ uname -a >>> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 >>> r268982M: >>> Tue Jul 22 10:14:59 CDT 2014 >>> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >>> borg.lerctr.org /home/ler $ ssh tbh uname -a >>> FreeBSD thebighonker.lerctr.org 10.0-STABLE FreeBSD 10.0-STABLE #39 >>> r269019M: Wed Jul 23 11:44:35 CDT 2014 >>> root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/GENERIC amd64 >>> borg.lerctr.org /home/ler $ >>> >> >> Try adding -v to the 'zfs send' and see if it gives you more detail. >> >> Can you also try this script for the replication: >> >> http://github.com/allanjude/zxfer > I've done that in the past and nothing, but I will try again. > > I will also look at zxfer.... :) with the -v, no more info, just what looks like normal messages.... 13:23:55 3.68G zroot/usr/src@2014-07-24 13:23:56 3.68G zroot/usr/src@2014-07-24 13:23:57 3.68G zroot/usr/src@2014-07-24 13:23:58 3.68G zroot/usr/src@2014-07-24 13:23:59 3.68G zroot/usr/src@2014-07-24 13:24:00 3.69G zroot/usr/src@2014-07-24 13:24:01 3.69G zroot/usr/src@2014-07-24 13:24:02 3.69G zroot/usr/src@2014-07-24 13:24:03 3.69G zroot/usr/src@2014-07-24 13:24:04 3.69G zroot/usr/src@2014-07-24 13:24:05 3.70G zroot/usr/src@2014-07-24 13:24:06 3.70G zroot/usr/src@2014-07-24 13:24:07 3.70G zroot/usr/src@2014-07-24 13:24:08 3.70G zroot/usr/src@2014-07-24 13:24:09 3.70G zroot/usr/src@2014-07-24 13:24:10 3.71G zroot/usr/src@2014-07-24 13:24:11 3.71G zroot/usr/src@2014-07-24 cannot receive new filesystem stream: invalid backup stream borg.lerctr.org /home/ler/bin $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 18:33:59 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A84534D6; Thu, 24 Jul 2014 18:33:57 +0000 (UTC) Date: Thu, 24 Jul 2014 14:33:53 -0400 From: Glen Barber To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140724183353.GL1065@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: quoted-printable X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:33:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FreeBSD Project Quarterly Status Report: April - June 2014 This report covers FreeBSD-related projects between April and June 2014. This is the second of four reports planned for 2014. The second quarter of 2014 was a very busy and productive time for the FreeBSD Project. A new FreeBSD Core Team was elected, the FreeBSD Ports Management Team branched the second quarterly "stable" branch, the FreeBSD Release Engineering Team was in the process of finalizing the FreeBSD 9.3-RELEASE cycle, and many exciting new features have been added to FreeBSD. Thanks to all the reporters for the excellent work! This report contains 24 entries and we hope you enjoy reading it. The deadline for submissions covering the period from July to September 2014 is October 7th, 2014. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Port Management Team * FreeBSD Release Engineering Team Projects * Chelsio iSCSI Offload Support * CUSE4BSD * FreeBSD and Summer of Code 2014 * New Automounter * pkg(8) * QEMU bsd-user-Enabled Ports Building * RPC/NFS and CTL/iSCSI Performance Optimizations * ZFSguru Kernel * PostgreSQL Performance Improvements * Running FreeBSD as an Application on Top of the Fiasco.OC Microkernel * SDIO Driver * TMPFS Stability * UEFI Boot * Updated vt(4) System Console Architectures * FreeBSD/arm64 Ports * FreeBSD Python Ports * KDE/FreeBSD * The Graphics Stack on FreeBSD Documentation * Quarterly Status Reports Miscellaneous * FreeBSD Host Support for OpenStack and OpenContrail * The FreeBSD Foundation __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. Topics for core this quarter have included some far-reaching policy reviews and some significant changes to the project development methodology. In May, a new release policy was published and presented at the BSDCan developer conference by John Baldwin. The idea is that each major release branch (for example, 10.X) is guaranteed to be supported for at least five years, but individual point releases on each branch, like 10.0-RELEASE, will be issued at regular intervals and only the latest point release will be supported. Another significant change did not receive approval. When the change to the Bylaws reforming the core team election process was put to the vote of all FreeBSD developers, it failed to reach a quorum. June saw the culmination of a long running project to replace the project's bug tracking system. As of June 3, the FreeBSD project has switched to Bugzilla as its bug tracking system. All of the history of GNATS PRs has been preserved, so there is no need to re-open old tickets. Work is still going on to replicate some of the integration tweaks that had been applied to GNATS, but all necessary functionality has been implemented and the project is already seeing the benefits of the new capabilities brought by Bugzilla. An election to select core members for the next two year term of office took place during this period. We would like to thank retiring members of core for their years of service. The new core team provides continuity with previous core teams: about half are incumbents from the previous team, and several former core team members have returned after a hiatus. Core now includes two members of the FreeBSD Foundation board and one other Foundation staff member, aiding greater coordination at the top level of the project. At the same time the core-secretary role was passed on to a new volunteer. Other activities included providing consultation on licensing terms for software within the FreeBSD source tree, and oversight of changes to the membership of postmaster and clusteradm. Three new src commit bits were issued during this quarter, and one was taken into safekeeping. __________________________________________________________________ FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: FreeBSD Port Management Team The ports tree slowly approaches the 25,000 ports threshold, while the PR count is slightly below 1800. In Q2 we added three new committers, took in one commit bit for safekeeping, and reinstated one commit bit. In May, Thomas Abthorpe was replaced by Frederic Culot as portmgr secretary, and Steve Wills became a member of the portmgr team. Commencing July 1, the third intake of portmgr-lurkers started active duty on portmgr for a four month duration. The next two candidates are William Grzybowski and Nicola Vitale. This quarter also saw the release of the second quarterly branch, namely 2014Q2. This branch was not only built for 10 (as 2014Q1) but for 9 as well (both i386 and amd64). Open tasks: 1. As previously noted, many PRs continue to languish, we would like to see committers dedicate themselves to closing as many as possible. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/9.3R/schedule.html URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, and announcing code freezes and maintaining the respective branches, among other things. In early May, the FreeBSD 9.3-RELEASE cycle entered the code slush phase. The FreeBSD 9.3-RELEASE cycle is nearing the final phases, and 9.3-RC3 builds will be starting soon. 9.3-RC3 is planned to be the final release candidate for this release cycle, and at the time of this writing, 9.3-RELEASE should be available on schedule. Work is ongoing to integrate support for embedded architectures into the release build process. At this time, support exists for a number of ARM kernels, in particular the Raspberry Pi, BeagleBone, and WandBoard. Additionally, work is in progress to produce virtual machine images as part of the release cycle, supporting various cloud services such as Microsoft Azure, Amazon EC2, and Google Compute Engine. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Chelsio iSCSI Offload Support Contact: Sreenivasa Honnur Building on the new in-kernel iSCSI target and initiator stack released in FreeBSD 10.0, Chelsio Communications has begun developing an offload interface to take advantage of the hardware offload capabilities of Chelsio T4 and T5 10 and 40 gigabit Ethernet adapters. The code currently implements a working prototype of offload for the initiator side, and target side offload should begin shortly. The code will be released under the BSD license and is expected to be completed later in the year and be committed to FreeBSD-HEAD, and will likely ship in a FreeBSD release in early 2015. Open tasks: 1. Complete testing and debugging of the initiator offload. 2. Start development of target offload. 3. Create hardware-independent offload APIs, based on experiences with target and initiator proof-of-concept implementations. __________________________________________________________________ CUSE4BSD URL: http://svnweb.freebsd.org/changeset/base/266581 Contact: Hans Petter Selasky The so-called CUSE4BSD has been imported into the base system of FreeBSD-11. CUSE is short for character device in userspace. The CUSE library is a wrapper for the devfs(8) kernel functionality which is exposed through /dev/cuse. In order to function, the CUSE kernel code must either be enabled in the kernel configuration file or loaded separately as a module. Follow the commit message link to get more information. __________________________________________________________________ FreeBSD and Summer of Code 2014 URL: http://gsoc.FreeBSD.org URL: https://wiki.freebsd.org/SummerOfCode2014 Contact: Gavin Atkinson Contact: Glen Barber Contact: Wojciech Koszek FreeBSD received 39 project proposals this year, many of which were of a very high standard. After a difficult selection process narrowing these down into the slots we had been allocated, a total of 16 projects were selected to participate in Google Summer of Code 2014 with FreeBSD. The projects selected span a wide range of areas within FreeBSD, covering both the base system and ports infrastructure, userland and kernel. We have students working on firewall optimisation, ports packaging tools, embedded systems, debugging infrastructure, improved Unicode support, enhancements to the loader and to the installer, and several other areas of work. We are just over halfway through the allocated time this year, and are very much looking forward to integrating code produced by these projects into FreeBSD. This is the tenth time FreeBSD has taken part in Google's Summer of Code, and we are grateful to Google to have accepted us as a participating organisation. __________________________________________________________________ New Automounter Contact: Edward Tomasz Napieral/a Deficiencies in the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. The project is at the early testing stage. A patch will be released as part of a broader call for testing after additional review on some critical components (in particular, the autofs filesystem). After fixing reported problems, the code will be committed to FreeBSD 11-CURRENT. It is expected to ship in the FreeBSD 10.2 release. This project is sponsored by The FreeBSD Foundation . Open tasks: 1. Fix bad interaction with fts(3). 2. Debug a problem with Kerberos NFS mounts. __________________________________________________________________ pkg(8) URL: https://github.com/freebsd/pkg URL: https://github.com/freebsd/pkg/issues Contact: Baptiste Daroussin Contact: Bryan Drewery Contact: Matthew Seaman Contact: Vsevolod Stakhov Contact: The pkg mailing list pkg(8) is the new package management tool for FreeBSD. It is now the only supported package management tool for FreeBSD releases from 10.0-RELEASE, including the upcoming 9.3-RELEASE. pkg(8) is available on all currently supported releases. Support for the legacy pkg_tools is due to be discontinued at the beginning of September 2014. The release of pkg(8) 1.3 is imminent. This includes major improvements in the dependency solver. Now we can: * Switch versions of, for example, Perl or PHP and resolve all the conflicts with packages that depend on them automatically. No more need to manually switch package origins. * Deal more gracefully with complex upgrade or install scenarios. * Sandbox operations dealing with freshly downloaded data until it can be verified as trustworthy by checking the package signature. * Deal with provides-and-requires style of dependencies, so for example we can say "this package needs to use a web server" and allow that dependency to be fulfilled by apache or nginx or any other alternative that provides web-server functionality. Beyond the next release, we have work in progress on allowing ranges of versions in dependency rules and handling a selection of "foreign" package repositories, such as CPAN or CTAN or PyPi. There are plans to use pkg(8) to package up the base system. Along with other benefits, this will allow writing a universal installer: download one installer image and from there install any available version of FreeBSD, including snapshots. We are also intending to use pkg(8) within the ports tree at package-build time to handle fulfilling build dependencies. This opens the possibility of installing build-dependencies by downloading binary packages, which means you can install a package with customized options with the minimum amount of time spent compiling anything else. Open tasks: 1. We are sorely lacking a comprehensive testing setup. Integrating automated regression testing into the development cycle is becoming an imperative. 2. We need testers who can run development versions of pkg in as many distinct types of use-cases as possible, and report feedback from their experiences to the freebsd-pkg@freebsd.org mailing list or our issues list on github. __________________________________________________________________ QEMU bsd-user-Enabled Ports Building URL: https://wiki.freebsd.org/QemuUserModeHowTo URL: http://dirty.ysv.freebsd.org/ URL: https://github.com/seanbruno/qemu-bsd-user Contact: Stacey Son Contact: Juergen Lock Contact: Sean Bruno The ports-mgmt/poudriere-devel port is capable of building ports via an emulator. Configuration of the miscellaneous binary image activator is required prior to a poudriere-devel run. ARMV6, MIPS32 and MIPS64 packages can be produced via full emulation. There are several packages that block a full run of builds. They can be viewed on the "Status of ports building" link. To build packages via emulation, on current or latest stable/10: Clone the github repository, and switch to the bsd-user branch. Then run: ./configure --static \ --target-list=3D"arm-bsd-user i386-bsd-user \ mips-bsd-user mips64-bsd-user mips64el-bsd-user \ mipsel-bsd-user ppc-bsd-user ppc64-bsd-user sparc-bsd-user \ sparc64-bsd-user x86_64-bsd-user" gmake; gmake install Then set up the binmiscctl tools to do some evil hackery to redirect execution of armv6 binaries to qemu: binmiscctl add armv6 --interpreter \ "/usr/local/bin/qemu-arm" --magic \ "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02 \ \x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff \ \xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled Install poudriere-devel from ports. It knows how to set up things. Create a poudriere jail to do all the magic: poudriere jail -c -j 11armv632 -m svn -a armv6 \ -v head Now run poudriere against that jail to build all the ports: poudriere bulk -j 11armv632 -a Nullfs mount the ports tree into the jail: mkdir /usr/local/poudriere/jails/11armv632/usr/ports mount -t nullfs /usr/ports /usr/local/poudriere/jails/11armv632/usr/ports To chroot into the jail: mount -t devfs devfs /usr/local/poudriere/jails/11armv632/dev chroot /usr/local/poudriere/jails/11armv632/ Open tasks: 1. PPC on AMD64 emulation. This is a work in progress as there appear to be some serious issues running the bsd-user binary on big-endian hardware. Justin Hibbits is working on this. 2. SPARC64 on AMD64 emulation is non-functional and instantly segfaults. We are looking for someone to poke at the bits here. 3. External Toolchain, XDEV support. There is partial support for using an AMD64 toolchain that can output binaries for other architecture (e.g., using an AMD64 toolchain to build MIPS64 packages). We are currently tracking a linking issue with ports-mgmt/pkg. Thanks to Warner Losh, Baptiste Daroussin, Dimitry Andric for poking at bits in here to make the XDEV target useful. 4. Signal handling. The MIPS/ARMV6 target stills display a failure that manifests itself when building devel/p5-Sys-SigAction. 5. Massive documentation update needed. These modifications actually allow chrooting into a MIPS or ARMv6 environment and using native toolchains and libraries to prototype software for a target platform. __________________________________________________________________ RPC/NFS and CTL/iSCSI Performance Optimizations Contact: Alexander Motin The FreeBSD RPC stack, used as a base for its NFS server, received multiple optimizations to improve performance and SMP scalability. Algorithmic optimizations reduced processing overhead, while improved locking allowed it to scale up to at least 40 processor cores without significant lock congestion. Combined with some other kernel optimizations, the peak NFS request rate increased by many times, reaching up to 600K requests per second on modern hardware. The CAM Target Layer (CTL), used as the base for the new kernel iSCSI server, also received a series of locking optimizations which allowed its peak request rate to increase from ~200K to ~600K IOPS with the potential of reaching a rate of 1M requests per second. That rate is sufficient to completely saturate 2x10Gbit Ethernet links with 4KB requests. For comparison, the port of net/istgt (user-level iSCSI server) on the same hardware with an equivalent configuration showed only 100K IOPS. There is also ongoing work on improving CTL functionality. It was already made to support three of four VMware VAAI storage acceleration primitives (net/istgt supports 2), while the goal is to reach full VAAI support during next months. With all these improvements, and earlier improvements in CAM, GEOM, ZFS, and a number of other kernel areas coming soon, FreeBSD 10.1 may become the fastest storage release ever. ;) These projects are sponsored by iXsystems, Inc. __________________________________________________________________ ZFSguru URL: http://zfsguru.com URL: http://zfsguru.com/news/stateoftheproject/2014 Contact: Jason Edwards ZFSguru is a multifunctional server appliance with a strong emphasis on storage. ZFSguru began as simple web-interface frontend to ZFS, but has since grown into a FreeBSD derivative with its own infrastructure. The scope of the project has also grown with the inclusion of add-on packages that add functionality beyond the traditional NAS functionality found in similar product like FreeNAS and NAS4Free. ZFSguru aims to be a true multifunctional server appliance that is extremely easy to setup and can unite both novice and more experienced users in a single user interface. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. Where development in the first quarter of this year brought drag-and-drop permissions for Samba and NFS, development in the second quarter focused on strengthening the infrastructure of the project. A new library and toolkit solution dubbed 'Mesa' is in the works, providing a cleaner foundation to the project. A new master server providing secure remote services is being setup, to be located in a high-speed datacenter. But most importantly, a new system build infrastructure has shown great progress and will soon be able to provide automated system builds to our users. This not only improves the frequency of system releases but also frees much developer time to be spent on different areas of the project. Furthermore, a new website and forum is being worked on, replacing the old-fashioned website that offers only limited functionality. The new website will be linked to the server database, providing real-time updates about the project. In addition, a new platform for collaborative development is in the works. A service addon has been created for the GitLab project, which is a drop-in replacement of the popular GitHub website. The choice was made to host our own solution and not rely on GitHub itself. In retrospect this appears to be a good decision. The recent development where GitHub removed projects after DCMA takedowns being sent is incompatible with the philosophy of free-flow-of-information, which the ZFSguru project is a strong proponent of. By hosting our own solution, we have avoided any dependency on third party projects. It is expected that after the infrastructure of the project has been revamped, work on the web-interface itself can continue. New functionality such as GuruDB and Service Bulletins provide a tighter connection between the server infrastructure and the web-interface. The Migration Manager is one of the last remaining features still missing in the web-interface. This functionality provides an easy way to upgrade the current system by performing a new clean installation, but migrate all relevant configuration to the new installation. It also allows to backup all system configuration in a single file to be stored on a different machine should things go awry. A longer version of this status report giving a wider perspective on the project can be found at the stateoftheproject link. __________________________________________________________________ PostgreSQL Performance Improvements URL: https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf Contact: Konstantin Belousov Analysis of the performance of the latest 9.3 version of PostgreSQL on FreeBSD-CURRENT has been performed. The issues which prevented good scalability on a 40-core machine were determined, and changes prototyped which solve the bottlenecks. The URL above provides a paper which contains a detailed explanation of the issues and solutions, together with a graph demonstrating the effects on scalability. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Running FreeBSD as an Application on Top of the Fiasco.OC Microkernel URL: http://en.wikipedia.org/wiki/L4_microkernel_family URL: https://wiki.freebsd.org/201407DevSummit/BSDUserspace Contact: Ilya Bakulin Fiasco.OC belongs to the L4 microkernel family. A microkernel provides a bare minimum of services to the applications running on top of it, unlike traditional kernels that incorporate complex code like IP stacks and device drivers. This allows a dramatic decrease in the amount of code running in the privileged mode of the CPU, achieving higher security while still providing an acceptable level of performance. Running an operating system kernel on top of the microkernel allows leveraging any software that was developed for that operating system. The OS kernel runs in user-mode side-by-side with other microkernel applications such as real-time components. Multiple OSes, each with their userland applications, can even be run in parallel, thus allowing construction of products where processing of corporate data is strictly separated from the processing of private data. The project aims to create a port of FreeBSD to the Fiasco.OC microkernel, a high performance L4 microkernel developed by TU Dresden. Existing ports of OpenBSD and Linux are used as a reference. This will allow the use of unique FreeBSD features like ZFS in L4-based projects. Open tasks: 1. Finish opensourcing the port of L4OpenBSD/amd64 made by genua mbh. This is a work in progress. 2. Publish the sources of the L4FreeBSD port that is largely based on the L4OpenBSD code. 3. Improve the port, the first task being adopting the pmap(9) module to work with L4 microkernel memory allocation services. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/mmccam Contact: Ilya Bakulin SDIO is an interface designed as an extension of the existing SD card standard, which allows the connecting of different peripherals to a host with a standard SD controller. Peripherals currently sold on the general market include WLAN/BT modules, cameras, fingerprint readers, and barcode scanners. Additionally, SDIO is used to connect some peripherals in products like Chromebooks and Wandboards. A prototype of the driver for the Marvell SDIO WLAN/BT (Avastar 88W8787) module is also being developed, using the existing Linux driver as the reference. SDIO card detection and initialization already work. Most necessary bus methods are implemented and tested. The WiFi driver is able to load firmware onto the card and initialize it. A rewrite of the MMC stack as a transport layer for the CAM framework is in progress. This will allow utilization of the well-tested CAM locking model and debug features. Open tasks: 1. SDIO stack: finish CAM migration. The initialization of the MMC/SD card is implemented in the XPT layer, but cannot be tested with real hardware because of the lack of any device drivers that implement peripheral drivers and SIMs for CAM MMC. The plan is to use a modified version of the BeagleBone Black SDHCI controller driver for the SIM and a modified version of mmcsd(4) as a peripheral driver. 2. Marvell SDIO WiFi: connect to the FreeBSD network stack, write the code to implement required functions (such as sending/receiving data, network scanning and so on). __________________________________________________________________ TMPFS Stability Contact: Konstantin Belousov Contact: Peter Holm Extensive testing of tmpfs(5) using the stress2 kernel test suite was done. The issues found were debugged and fixed. Most of the problems are related to bugs in the interaction of the vnode and node lifetime, culminating in e.g., unmount races and dotdot lookup bugs. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI URL: http://www.freebsd.org/snapshots/ Contact: Ed Maste Contact: Nathan Whitehorn The Unified Extensible Firmware Interface (UEFI) provides boot- and run-time services for x86 and other computers. For the x86 architecture it replaces the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops. Ed and Nathan completed a number of integration tasks over the past three months. Nathan added a first-stage loader, boot1.efi, to support chain-loading the rest of the system from a UFS filesystem. This allows the UEFI boot process to proceed in a similar fashion as with BIOS boot. Nathan also added UEFI support to the FreeBSD installer and release image creation script. The EFI framebuffer requires the vt(4) system console -- a framebuffer driver is not implemented for the legacy syscons(4) console. Ed added automatic vt(4) selection to the UEFI boot path. Snapshots are now built as dual-mode images, and should boot via both BIOS and UEFI. Our plan is to merge the UEFI and vt(4) work to stable/10 to appear in FreeBSD 10.1-RELEASE. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Document manual installation, including dual-boot configurations. 2. Implement boot1.efi for ZFS file systems. 3. Add support for UEFI variables stored in non-volatile memory (NVRAM). 4. Debug boot failures with certain UEFI firmware implementations. 5. Support secure boot. __________________________________________________________________ Updated vt(4) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten Contact: Warren Block The vt(4) (aka Newcons) project provides a replacement for the legacy syscons system console. It brings a number of improvements, including better integration with graphics modes and broader character set support. Since the last report, vt(4) gained the ability to make early driver selection. vt(4) selects the best successfully-probed driver before most other kernel subsystems are initialized. Also, to facilitate migration from syscons(4) to vt(4), multiple virtual terminal subsystems in the kernel are now supported. It is controlled by a small module with just one kernel environment variable. Users can select the virtual terminal system to use by setting kern.vty=3Dsc or kern.vty=3Dvt. The GENERIC kernel configuration for the amd64 and i386 platforms now includes both syscons(4) and vt(4) by default. This configuration is also planned to be in FreeBSD 10.1-RELEASE. The project finally received a man page, so now vt(4) is not only the project name, but also a link to its documentation. Great thanks to Warren Block for that. Major highlights: * Unicode support. * Double-width character support for CJK characters. * xterm(1)-like terminal emulation. * Support for Kernel Mode Setting (KMS) drivers (i915kms, radeonkms). * Support for different fonts per terminal window. * Simplified drivers. Brief status of supported architectures and hardware: * amd64 (VGA/i915kms/radeonkms) -- works. * ARM framebuffer -- works. * i386 (VGA/i915kms/radeonkms) -- works. * IA64 -- untested. * MIPS -- untested. * PPC and PPC64 -- work, but without X.Org yet. * SPARC -- works on certain hardware (e.g., Ultra 5). * vesa(4) -- in progress. * i386/amd64 nVidia driver -- not supported. VGA should be used (VESA planned). * Xbox framebuffer driver -- will be deleted as unused. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Implement the remaining features supported by vidcontrol(1). 2. Write manual pages for vt(4) drivers and kernel interfaces. 3. Support direct handling of keyboard by the kbd device (without kbdmux(4)). 4. CJK fonts. (This is in progress). 5. Address performance issues on some architectures. 6. Switch to vt(4) by default. 7. Convert keyboard maps for use with vt(4). 8. Implement compatibility mode to be able to use single-byte charsets/key-codes in vt(4). __________________________________________________________________ FreeBSD/arm64 URL: http://svnweb.freebsd.org/base/projects/arm64/ Contact: Andrew Turner Arm64 is the name of the in-progress port of FreeBSD to the ARMv8 CPU when it is in AArch64 mode. Until recently, all ARM CPU designs were 32-bit only. With the introduction of the ARMv8 architecture, ARM has added a new 64-bit mode. This new mode has been named AArch64. Booting FreeBSD on the ARM Foundation Model has made a lot of progress since the last status report. An initial pmap implementation has been written. With this, FreeBSD is able to enter the Machine Independent boot code. The required autoconf functions have been added allowing FreeBSD to start scheduling tasks. Finally the cpu_switch and copystr functions were added. With these two, FreeBSD will boot to the mountroot prompt. Work has started on supporting exceptions, including interrupts. This will allow more developers to start working on device drivers. Open tasks: 1. Finish exception and interrupt handling 2. Read the Device Tree or ACPI tables from UEFI 3. Test on real hardware __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team We are pleased to announce the availability of conflict-free Python package support across different Python versions based on the USES=3Duniquefiles feature recently introduced to the Ports framework. A Python package can be marked as buildable and installable in parallel for different Python versions at the same time on the same host. The package building tools, however, do not support this feature yet and the Python team will work closely with portmgr and the pkg developers to enable support on a global ports and packages scale. In May and June a huge clean-up operation took place to remove the last bits and pieces targeting easy_install. In the beginning of July we committed the final changes to remove easy_install support completely from the ports framework. This greatly simplifies the infrastructure and allows us to modernize and maintain it with less effort. We added Python 3.4, removed Python 3.1 after its end of life, updated the setuptools ports to version 5.1 and PyPy's development version to 2.3.1. The latest Python 2.7.8 and an updated setuptools will hit the tree shortly. Our upstreaming effort continues to produce good outcomes for simplifying maintenance and reducing complexity. Looking forward, one of the top priorities is to comply with the USES framework in the foreseeable future and to roll out a consistent maintainer policy for integrating new Python-related ports into the tree. Open tasks: 1. Migrate bsd.python.mk to the Uses framework. 2. Develop a high-level and lightweight Python Ports Policy. 3. Add support for granular dependencies (for example >=3D1.0,<2.0). 4. See what adding pip (Python Package Index) support will require. 5. Add default QA targets and functions for Python ports (TEST_DEPENDS, regression-test, etc.) 6. More tasks can be found on the team's wiki page (see links). 7. To get involved, come and say "hi" on IRC and let us know what you are interested in! __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE/FreeBSD Team The KDE/FreeBSD team has continued to improve the experience of KDE software and Qt under FreeBSD. During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC: 4.12.5; Workspace: 4.11.9 As a result -- according to PortScout -- kde@ has 526 ports (up from 526), of which 84.63% are up-to-date (down from 98.86%). iXsystems Inc. continues to provide a machine for the team to build packages and to test updates. iXsystems Inc. has been providing the KDE/FreeBSD team with support for quite a long time and we are very grateful for that. As usual, the team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. It would be especially useful to have more helping hands on tasks such as getting rid of the dependency on the defunct HAL project and providing integration with KDE's Bluedevil Bluetooth interface. Open tasks: 1. Updating out-of-date ports, see PortScout for a list 2. Removing the dependency on HAL __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://lists.freebsd.org/pipermail/freebsd-announce/2014-July/00157= 0.ht ml URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: FreeBSD Graphics team We were generally short on time this quarter. We made less progress than expected on all fronts. The alternate pkg(8) repository, built with WITH_NEW_XORG, is now available. This alleviates the need for users to rebuild their ports with WITH_NEW_XORG. See the announcement, linked above for further information. Thanks to a contribution from Jan Kokem=C3=BCller, Radeon 32bit ioctls a= re now working on 64bit hosts. This was tested successfully with Wine and StarCraft II on FreeBSD 9.x and 11. This required modifications to emulators/i386-wine-devel so that it works with WITH_NEW_XORG, and the creation of a new port, libtxc_dxtn, to support the texture compression used by StarCraft II. We have not yet had the time to polish everything, so this still requires manual steps. The DRM generic code update is ready, but it breaks the current i915 driver. Therefore, the i915 driver must be updated before anything is committed. Compared to the previous status report, OpenCL test programs are running fine now, thanks to upgrades and fixes to libc++ and Clang. The relevant ports are still not ready to hit the ports tree, unfortunately. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Quarterly Status Reports Contact: Quarterly Status Report Team These quarterly status reports help the FreeBSD community stay up-to-date with the happenings in and around the project. Updates from FreeBSD teams, new features being developed in- or out-of-tree, products derived from FreeBSD, and FreeBSD events are all welcome additions to the status reports. The Monthly team has been busy since the last report, with longtime organizer G=C3=A1bor P=C3=A1li having stepped down from the team -- than= k you G=C3=A1bor for all your hard work! This has left something of a void in = the preparation of this report, for which the call for items was issued quite late. To help fill the void, Warren Block and Benjamin Kaduk have been added to the monthly@ team, joining Glen Barber, Gavin Atkinson, Ed Maste, and the rest of the team in preparing this report. Special thanks to Glen for doing most of the work while simultaneously getting 9.3-RELEASE out the door! The next cycle is sooner than you think! The deadline for submitting entries for the Q3 report is October 7th, 2014. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Submit reports for Q42014 to monthly@FreeBSD.org! __________________________________________________________________ FreeBSD Host Support for OpenStack and OpenContrail URL: http://www.openstack.org URL: http://www.opencontrail.org URL: https://github.com/Semihalf/openstack-devstack URL: https://github.com/Semihalf/openstack-nova URL: https://github.com/Semihalf/contrail-vrouter URL: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node Contact: Grzegorz Bernacki Contact: Michal Dubiel Contact: Dominik Ermel Contact: Rafal Jaworowski OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources in a datacenter. OpenContrail is a network virtualization (SDN) solution comprising network controller, virtual router, and analytics engine, which can be integrated with cloud orchestration systems like OpenStack or CloudStack. The goal of this work is to enable FreeBSD as a fully supported compute host for OpenStack using OpenContrail virtualized networking. The main areas of development are: * Libvirt hypervisor driver for bhyve. * Support for bhyve (via libvirt compute driver) and the overall FreeBSD platform in nova-compute. * OpenContrail vRouter (forwarding plane kernel module) port to FreeBSD. * OpenContrail Agent (network controller node) port to FreeBSD. * Integration and performance optimizations. Since the last report the following items have been completed, which allow for a working demo of an OpenStack compute node on a FreeBSD host using OpenContrail for network virtualization: * Port of the OpenContrail vRouter kernel module for FreeBSD (MPLS over GRE mode only) * Port of the OpenContrail Agent for FreeBSD * FreeBSD version of a Devstack installation/configuration script with support for the OpenContrail solution (Compute node components only) A demo was presented at the DevSummit during BSDCan2014 in Ottawa. Also, a meetup regarding the subject was organized in Krakow, Poland. Work on this project is sponsored by Juniper Networks. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project. We published our third issue of the FreeBSD Journal. We have over 2700 subscriptions so far. We continued working on the digital edition, which will allow subscribers to read the magazine in different web browsers, including those than run on FreeBSD. This will be available for the July/August issue of the Journal. We hired Anne Dickison, on a freelance basis, as our new marketing director, to help us promote the Foundation and Project. The annual board meeting was held in Ottawa, Canada, in May. Directors and officers were elected, and we did some long-term planning. We worked on our vision, core values, project road mapping, and our near-term goals. We also met with the core team to discuss roles and responsibilities, project roadmapping, and what we can do to help the Project more. We were a Gold+ sponsor for BSDCan, May 16-17 and provided 7 travel grants for developers to attend the conference. We also were the sponsor for both the developer and vendor summits. Justin Gibbs gave a FreeBSD presentation at a FreeBSD user's internal technology summit. Company visits like this help users understand the Project structure better and gives us a chance to communicate what FreeBSD people are working on as well as learn what different companies are doing with FreeBSD, as well as what they'd like to see supported. We can then help facilitate collaboration between the companies and FreeBSD developers. We were represented at Great Wide Open, April 2-3 (greatwideopen.org), Texas LinuxFest, June 13-14 (texaslinuxfest.org), and SouthEast LinuxFest, June 20-22 (southeastlinuxfest.org). Hardware was purchased to support an upgrade at Sentex. A new high-capacity 1Gbps switch was deployed to allow for more systems to be added to the test lab. The main file server and development box was upgraded to allow more users in the lab simultaneously. We purchased hardware, including package builders, and a larger server to allow NYI to be a full replica of all Project systems, comparable to what is in place at Yahoo Inc. and ISC. We worked with our lawyer to create an NDA between the Foundation and individuals for third party NDAs. This allows developers who need access to proprietary documents, to go through the Foundation, via an NDA for access. FreeBSD Foundation Systems Administrator and Release Engineer, Glen Barber, continued work on producing regularly-updated FreeBSD/arm snapshots for embedded devices, such as the Raspberry Pi, ZedBoard, and BeagleBone. In addition to producing weekly development snapshots from the head/ and stable/ branches, with feedback and help from Ed Maste, Glen finished work to produce release images that will, by default, provide debugging files for userland and kernel available on the FreeBSD Project FTP mirrors. Note that the debugging files will not be included on the bootonly.iso, disc1.iso, or dvd1.iso images due to the size of the resulting images. Foundation staff member Konstantin Belousov completed an investigation into poor performance of PostgreSQL on FreeBSD. This uncovered scalability problems in the FreeBSD kernel, and changes to address these issues are in progress. Some previously completed Foundation-sponsored projects received enhancements or additional work. The ARM superpages project was completed last year, but is now enabled by default in FreeBSD-CURRENT. Many stability fixes and enhancements have been committed to the in-kernel iSCSI stack. The iSCSI project was released in FreeBSD 10.0. Many stability fixes and enhancements have been committed and will be included in FreeBSD 10.1. Work continues on the Foundation-sponsored autofs automount daemon, UEFI boot support, the updated vt(4) system video console, virtual machine images, and the Intel graphics driver update. Foundation-sponsored work resulted in 226 commits to FreeBSD over the April to June period. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJT0VGRAAoJELls3eqvi17QF0UP/iPhYcVNJ2WUJS3rZ9MPCPHj EfN3DLsOMCO54YWEIUnQqZTR0ist9HjUaSbyLfTIM9j4xmwvz2Z6JWiMvg8Ui8QC 6EuLjLOKvlwaj4F9/OMu5mrOpYeXtwZOS5KgeYN+yq9sBXV3mzMe8yhzIT6zTGNM akRhbVqJiQRKnwF4T15PML/AJ9ihrfYqz3j3veocelWDyuEG2LOpJQj1zfUXX2f8 YdCDSi/6bNmNoh95Nf7+F7Uj+R7EvYHZ5SdvO9eUk/ET/J4x/JAXcxwms/ars2wX LsJjVZS9vLVCvb82HADb6tWAUCi02hHy0vUxxKj2E9u113Nq2Ecws2kSdnaIEfJp jFUE3y5/VWnCKOGXgF3T4iB20M+i/nqOQStnY33fq5Dr36LlHvVpLNCF9XjRs+IN p6O8aDOnl8etil+Z2w6IWeth/D6la8a2+4xEP3/l/d9VHParchoKUcA44RFM/k8D MNz/+fQurkaLZXEQUlr9oB/QRuZ6t54pT/rD1Nu40/kvnoS+Ss8JdN1VzcdBe5b1 hehkxxZ1/GmxSp2YcdeQVfK86YE+323izsa4fBjvx/6z+Zo3C2dIV2mgBuoz1mQd U5G/a1DOcVHGqBO7xUVlgwEr1c2pTARmRBEU5rkehibqkznG5QFfj83k3j3Mvx0N P9kkcHSgEgy40srydzLq =3D3eLh -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 18:43:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5A41251; Thu, 24 Jul 2014 18:43:57 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28AB429FC; Thu, 24 Jul 2014 18:43:57 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 6e206dd1; Thu, 24 Jul 2014 13:43:48 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:sender; s= blargle2; bh=TxRJSl326xASH+wccfK5gqXCgn0=; b=EsMxt5PW2Ze+gomW+FO PhAlkylDfiXsmPlloRPHdRLkyGWbBzAUsBR2AxNKRZcEDuu9q3yuQfUT7rZgMm7n TfGmn3u1itojjhaOqpFy5H/rZb/j2LWRik2NZaE0SZBCsWTGShoWPyDX367nw+/N lydPYhyeatQeH36jWE2zQKMF7HxmH4xjWz2M2n8rVr8JPbkRtpjSofR8VkDNbHf8 NBnBhcr5v/LtNW8/LxhsnI7QNtjldliG6a8hBui0bLdSpZjgnLGlGPPehDJsL5qV OpxpAB+rPMkq0M0YmNzSjuPCCK9kWhMnuyZBFwTU3z/vLgBLMPEpUvKNg9kwfeKD Pkw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:sender; q= dns; s=blargle2; b=fmj3zVZUkalxz/O+Ym5CHDJUAd3yuohhBjcLIm8sU1yXe BVkNiOasRjrVmeepJ8bl4XJHsusEdrqUITnJaDvgc9i2hZ2eWdVYLCv9bs5DYeQ/ zBms2SJ6bGs3RogTRQD8thhvPUd5pu9iGSMz7Y1ps4JIPODBnFUdprCgm3MMS1gi x6aI0VsDHwSJBfAcImS6Pa2Swcg4ICAVFs5qLliWJQqVWh6e2444EYG6AAKVylOt 0EYdR5yaBa3r3CFU20myGQ3KuOy3PdzWcdM3V9nWwXkd2WD4zvNP9u+INaFS2iov Fh0BsAzIV1hAsZUhvbKs+6MsOUcJzun8GjgxzKQgQ== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 7cb42f64; Thu, 24 Jul 2014 13:43:48 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1406227427-78987-78985/5/4; Thu, 24 Jul 2014 18:43:47 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Mark Felder In-Reply-To: Date: Thu, 24 Jul 2014 13:43:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <81B6EE28-692E-4AB4-A4EB-CC6338182D75@FreeBSD.org> References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> <50E4E363-B2C0-4ED7-A0C4-2D7C69FF15B2@lists.zabbadoz.net> <53D01DDD.8000806@freebsd.org> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1971.5) Sender: feld@feld.me Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:43:57 -0000 > On Jul 23, 2014, at 15:59, Bjoern A. Zeeb wrote: >=20 > There was (is?) another case that in certain situations with certain = pf options IPv6/ULP packets would not pass or get corrupted. I think no = one who experienced it never tracked it down to the code but I am sure = there are PRs for this; best bet is that not all header sizes are equal = and length/offsets into IPv6 packets are different to IPv4, especially = when you scrub. >=20 scrub reassemble tcp breaks all ipv6 tcp traffic since FreeBSD 9.0. = Well, not entirely "breaks" but things seem to be going at a rate of a = poor dialup connection. This is similar to what I've experienced with pf = + tso on Xen. Related? Possibly! I'd hazard a guess the reassembling of = tcp on IPv6 is breaking checksums? Upstream pf from OpenBSD has removed this feature entirely and (I = believe) reworked their scrubbing, but I don't know the details. I can = confirm that when reassemble tcp existed on OpenBSD it never broke = traffic for me. Synproxy and IPv6 was also broken last I knew. I can't remember the = symptoms, but it was probably "nothing works". I recall synproxy has = always been one of those "you're gonna shoot your eye out kid" features, = but some people have used it successfully. From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 18:44:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A0A8362 for ; Thu, 24 Jul 2014 18:44:51 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3131A2A14 for ; Thu, 24 Jul 2014 18:44:51 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3F6B92C706 for ; Thu, 24 Jul 2014 18:44:50 +0000 (UTC) Message-ID: <53D15438.6040105@freebsd.org> Date: Thu, 24 Jul 2014 14:45:12 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zfs send/recv: STILL invalid Backup Stream References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6mtk50ScExqxoOGmKbKvkRr531j6j2waI" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:44:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6mtk50ScExqxoOGmKbKvkRr531j6j2waI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-24 14:25, Larry Rosenman wrote: > On 2014-07-24 12:43, Larry Rosenman wrote: >> On 2014-07-24 12:38, Allan Jude wrote: >>> On 2014-07-24 13:33, Larry Rosenman wrote: >>>> TRYING to use zfs send/recv between a 10-STABLE and an 11-CURRENT >>>> system, and receive the non-descript >>>> "invalid backup stream". >>>> >>>> borg.lerctr.org /home/ler $ sudo bin/backup-TBH-ZFS-initial.sh >>>> Password: >>>> receiving full stream of zroot@2014-07-24 into >>>> zroot/backups/TBH@2014-07-24 >>>> received 41.7KB stream in 300 seconds (142B/sec) >>>> receiving full stream of zroot/usr@2014-07-24 into >>>> zroot/backups/TBH/usr@2014-07-24 >>>> received 41.7KB stream in 1 seconds (41.7KB/sec) >>>> receiving full stream of zroot/usr/local@2014-07-24 into >>>> zroot/backups/TBH/usr/local@2014-07-24 >>>> received 2.81GB stream in 1116 seconds (2.58MB/sec) >>>> receiving full stream of zroot/usr/src@2014-07-24 into >>>> zroot/backups/TBH/usr/src@2014-07-24 >>>> cannot receive new filesystem stream: invalid backup stream >>>> borg.lerctr.org /home/ler $ cat bin/backup-TBH-ZFS-initial.sh >>>> #!/bin/sh >>>> DATE=3D`date "+%Y-%m-%d"` >>>> #DATE2=3D2013-03-24 >>>> #DATE2=3D`date -v "-1d" "+%Y-%m-%d"` >>>> # snap the source >>>> ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} >>>> # zfs copy the source to here. >>>> ssh root@tbh.lerctr.org "zfs send -R -D zroot@${DATE} | \ >>>> ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH\""= >>>> # make sure we NEVER allow the backup stuff to automount. >>>> /sbin/zfs list -H -t filesystem -r zroot/backups/TBH| \ >>>> awk '{printf "/sbin/zfs set canmount=3Dnoauto %s\n",$1}' | sh >>>> borg.lerctr.org /home/ler $ >>>> >>>> This has been happening for YEARS and I can't seem to interest >>>> anyone in >>>> fixing it. >>>> >>>> How can we get to the bottom of this? >>>> >>>> borg.lerctr.org /home/ler $ uname -a >>>> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 r26898= 2M: >>>> Tue Jul 22 10:14:59 CDT 2014 >>>> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >>>> borg.lerctr.org /home/ler $ ssh tbh uname -a >>>> FreeBSD thebighonker.lerctr.org 10.0-STABLE FreeBSD 10.0-STABLE #39 >>>> r269019M: Wed Jul 23 11:44:35 CDT 2014 >>>> root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/GENERIC amd64 >>>> borg.lerctr.org /home/ler $ >>>> >>> >>> Try adding -v to the 'zfs send' and see if it gives you more detail. >>> >>> Can you also try this script for the replication: >>> >>> http://github.com/allanjude/zxfer >> I've done that in the past and nothing, but I will try again. >> >> I will also look at zxfer.... :) >=20 >=20 > with the -v, no more info, just what looks like normal messages.... >=20 > 13:23:55 3.68G zroot/usr/src@2014-07-24 > 13:23:56 3.68G zroot/usr/src@2014-07-24 > 13:23:57 3.68G zroot/usr/src@2014-07-24 > 13:23:58 3.68G zroot/usr/src@2014-07-24 > 13:23:59 3.68G zroot/usr/src@2014-07-24 > 13:24:00 3.69G zroot/usr/src@2014-07-24 > 13:24:01 3.69G zroot/usr/src@2014-07-24 > 13:24:02 3.69G zroot/usr/src@2014-07-24 > 13:24:03 3.69G zroot/usr/src@2014-07-24 > 13:24:04 3.69G zroot/usr/src@2014-07-24 > 13:24:05 3.70G zroot/usr/src@2014-07-24 > 13:24:06 3.70G zroot/usr/src@2014-07-24 > 13:24:07 3.70G zroot/usr/src@2014-07-24 > 13:24:08 3.70G zroot/usr/src@2014-07-24 > 13:24:09 3.70G zroot/usr/src@2014-07-24 > 13:24:10 3.71G zroot/usr/src@2014-07-24 > 13:24:11 3.71G zroot/usr/src@2014-07-24 > cannot receive new filesystem stream: invalid backup stream > borg.lerctr.org /home/ler/bin $ I notice you are doing a deduplicated stream. Does it work without deduplication (zfs send -D)? --=20 Allan Jude --6mtk50ScExqxoOGmKbKvkRr531j6j2waI 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0VQ7AAoJEJrBFpNRJZKfiZkQAKJtwU+05G2nlINbejwhsS5y upu1ewh/dumEjv+Sa06o2N6QwYE2pcNZGqewgZ5ZA2NOyS4Pr14NEVBkJzbzcqai 1F/EhAOyFb0fCo1k9qwua1E3JOs9fuJD/CdAc/1dR50/fUbgZ53y5pyGlytJHgkC 5HXzKHbh2zjIzYji6B4HbhxWmCeaM7Nd12s1SItegKQkpLYYCuJ9g30v0F5pd8mb Sz4MyrGBjKET8eBIq4KaDqhAl2c26eNo3N0AhcO54EjoBDYbN4NkZiIQsNB5xMbn zyok1EhguNdLl6zM1EN+1FWlcscTozQFuMd0vEbNmSE2xYa2s9Q6PjpWUI3Jlv6T oF3a1uS/s5bQjczgCHjVVodnJ27BNZsM9Pi1QLFGlyKQ9TT7WNiUKo3dWjj5A1rd sJiyGL7NN6Tc7V2dIeAasLJxhK90OgWZHVUz1d/ZF9QaKmll/btz921Iqu5eJ7nW gew+REhpMZqt4T+fJKZzXW4/XfUh3py4cnxvZlTUF0937aU+ZFaMsCdj++JDlCK4 /FPODb71PVl24LKuqnlBLg7ZWRllWJ93jqdPEEZVGx5DkW47LPuvpdqmzFqLKNy/ od43BrohJQwVnxjClq13efP9J5VmK50ECa4ongCDm4GsZJlCQK9Ogqp53l2vMFWm 3Z6+naQj+I+KAN+PrjsB =8cjN -----END PGP SIGNATURE----- --6mtk50ScExqxoOGmKbKvkRr531j6j2waI-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 18:46:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41D1848A; Thu, 24 Jul 2014 18:46:26 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 107C92A37; Thu, 24 Jul 2014 18:46:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=CKplyrXSnxOQ8eYWV5hIc4WxW1JzBSOm3KqymhXNLow=; b=t2yZCQ3kXYCdNw19kCMuqsQ4mCV4P+DjSl3QcCmb4DAhJE9oKDz0g8UXGU7uZXHEZoKXopXXJpjY56OH6xkvxYl3w9NqhRaaSDYN2AS/PuUftpenluNmrjLdnj/qIEGTR+owYfYb+VhgTltOmQouOouA6Dw2lKH1lfU9DZguFbI=; Received: from localhost.lerctr.org ([127.0.0.1]:45581 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAO23-000HlW-Eh; Thu, 24 Jul 2014 13:46:25 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 13:46:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 13:46:23 -0500 From: Larry Rosenman To: Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <53D15438.6040105@freebsd.org> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> Message-ID: <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:46:26 -0000 On 2014-07-24 13:45, Allan Jude wrote: > On 2014-07-24 14:25, Larry Rosenman wrote: >> On 2014-07-24 12:43, Larry Rosenman wrote: >>> On 2014-07-24 12:38, Allan Jude wrote: >>>> On 2014-07-24 13:33, Larry Rosenman wrote: >>>>> TRYING to use zfs send/recv between a 10-STABLE and an 11-CURRENT >>>>> system, and receive the non-descript >>>>> "invalid backup stream". >>>>> >>>>> borg.lerctr.org /home/ler $ sudo bin/backup-TBH-ZFS-initial.sh >>>>> Password: >>>>> receiving full stream of zroot@2014-07-24 into >>>>> zroot/backups/TBH@2014-07-24 >>>>> received 41.7KB stream in 300 seconds (142B/sec) >>>>> receiving full stream of zroot/usr@2014-07-24 into >>>>> zroot/backups/TBH/usr@2014-07-24 >>>>> received 41.7KB stream in 1 seconds (41.7KB/sec) >>>>> receiving full stream of zroot/usr/local@2014-07-24 into >>>>> zroot/backups/TBH/usr/local@2014-07-24 >>>>> received 2.81GB stream in 1116 seconds (2.58MB/sec) >>>>> receiving full stream of zroot/usr/src@2014-07-24 into >>>>> zroot/backups/TBH/usr/src@2014-07-24 >>>>> cannot receive new filesystem stream: invalid backup stream >>>>> borg.lerctr.org /home/ler $ cat bin/backup-TBH-ZFS-initial.sh >>>>> #!/bin/sh >>>>> DATE=`date "+%Y-%m-%d"` >>>>> #DATE2=2013-03-24 >>>>> #DATE2=`date -v "-1d" "+%Y-%m-%d"` >>>>> # snap the source >>>>> ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} >>>>> # zfs copy the source to here. >>>>> ssh root@tbh.lerctr.org "zfs send -R -D zroot@${DATE} | \ >>>>> ssh home.lerctr.org \"zfs recv -F -u -v -d >>>>> zroot/backups/TBH\"" >>>>> # make sure we NEVER allow the backup stuff to automount. >>>>> /sbin/zfs list -H -t filesystem -r zroot/backups/TBH| \ >>>>> awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh >>>>> borg.lerctr.org /home/ler $ >>>>> >>>>> This has been happening for YEARS and I can't seem to interest >>>>> anyone in >>>>> fixing it. >>>>> >>>>> How can we get to the bottom of this? >>>>> >>>>> borg.lerctr.org /home/ler $ uname -a >>>>> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 >>>>> r268982M: >>>>> Tue Jul 22 10:14:59 CDT 2014 >>>>> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >>>>> borg.lerctr.org /home/ler $ ssh tbh uname -a >>>>> FreeBSD thebighonker.lerctr.org 10.0-STABLE FreeBSD 10.0-STABLE #39 >>>>> r269019M: Wed Jul 23 11:44:35 CDT 2014 >>>>> root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/GENERIC amd64 >>>>> borg.lerctr.org /home/ler $ >>>>> >>>> >>>> Try adding -v to the 'zfs send' and see if it gives you more detail. >>>> >>>> Can you also try this script for the replication: >>>> >>>> http://github.com/allanjude/zxfer >>> I've done that in the past and nothing, but I will try again. >>> >>> I will also look at zxfer.... :) >> >> >> with the -v, no more info, just what looks like normal messages.... >> >> 13:23:55 3.68G zroot/usr/src@2014-07-24 >> 13:23:56 3.68G zroot/usr/src@2014-07-24 >> 13:23:57 3.68G zroot/usr/src@2014-07-24 >> 13:23:58 3.68G zroot/usr/src@2014-07-24 >> 13:23:59 3.68G zroot/usr/src@2014-07-24 >> 13:24:00 3.69G zroot/usr/src@2014-07-24 >> 13:24:01 3.69G zroot/usr/src@2014-07-24 >> 13:24:02 3.69G zroot/usr/src@2014-07-24 >> 13:24:03 3.69G zroot/usr/src@2014-07-24 >> 13:24:04 3.69G zroot/usr/src@2014-07-24 >> 13:24:05 3.70G zroot/usr/src@2014-07-24 >> 13:24:06 3.70G zroot/usr/src@2014-07-24 >> 13:24:07 3.70G zroot/usr/src@2014-07-24 >> 13:24:08 3.70G zroot/usr/src@2014-07-24 >> 13:24:09 3.70G zroot/usr/src@2014-07-24 >> 13:24:10 3.71G zroot/usr/src@2014-07-24 >> 13:24:11 3.71G zroot/usr/src@2014-07-24 >> cannot receive new filesystem stream: invalid backup stream >> borg.lerctr.org /home/ler/bin $ > > I notice you are doing a deduplicated stream. Does it work without > deduplication (zfs send -D)? I will try that after this zxfer test I'm running finishes, but IIRC it doesn't matter.. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 18:48:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4B75628; Thu, 24 Jul 2014 18:48:43 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51B262A5E; Thu, 24 Jul 2014 18:48:43 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id d0cc3911; Thu, 24 Jul 2014 13:48:42 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:sender; s= blargle2; bh=GbZwzKKktnjIYDnqMY7PFIspQ8U=; b=yhg8lN/5UvM55vkemsD j/9N3SExI0+M5BZQPgy6z7hDy4txTY6bHvBxPdalt9FhQnrnnMo6CvfvE6YAdW4x 1zlJ58/Ti03gi3GBPPHXiHEX11AMEnNu3KeoGj0veg0/CkS10cLPdqmWgPUEgkNw 8kRirrACstl3r38xxb0rYKMv7bVIA0fft6tlq9e6Ct9+VZoGvNGuh/0KTV3KtoBk MMbSz3R3RBVIj5ThA2dGLrpsG+7SuKX+ZyobvzObj2T2j9fkr7F/nr53gD56AhWC cQG6UDWONaSB7fOdzIkL3rGcy6HGcvjx08bnUtulEZt4Qdb7XNEMlH3V5CHaGrML OIQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:sender; q= dns; s=blargle2; b=S30hXj/rS2K1lEDj2dZnaf+R8p659W7X1tHFlBrLWViAV 5xc4rWKOsFbLSlZ9ZhfXq/iBDsuCldbjIUtXf9fBgt0HGHvOSFkWKHRQrJb3go3C e4nsi9yhlXckU2zK3QWCzi9bEyaYXhYnJXvyKsOOjdYMhuT5u/9SjAfXussNXwiv mA9fC5orQMj1vZ3Vj5gzs5XhLk4hY+G6TJ51xvoN4BYaSwsRFNgVPp0vAkVyUCZq H/GwOIkLevGE7ZVWu/6sUmIHsx+U3KXwgnsGgNg3GxQS+vY+Usadovkd6jX7RcjC 0Z8LhSFfhlId7eU7bZoJIsgmE/Bh5o58wub2kuDwA== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id beecd638; Thu, 24 Jul 2014 13:48:42 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1406227721-78987-78985/5/5; Thu, 24 Jul 2014 18:48:41 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Mark Felder In-Reply-To: <81B6EE28-692E-4AB4-A4EB-CC6338182D75@FreeBSD.org> Date: Thu, 24 Jul 2014 13:48:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <48A2CC93-8A68-4C71-8AD3-43EDABE444CD@FreeBSD.org> References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> <50E4E363-B2C0-4ED7-A0C4-2D7C69FF15B2@lists.zabbadoz.net> <53D01DDD.8000806@freebsd.org> <81B6EE28-692E-4AB4-A4EB-CC6338182D75@FreeBSD.org> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1971.5) Sender: feld@feld.me Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:48:43 -0000 > On Jul 24, 2014, at 13:43, Mark Felder wrote: >=20 > Upstream pf from OpenBSD has removed this feature entirely and (I = believe) reworked their scrubbing, but I don't know the details. I can = confirm that when reassemble tcp existed on OpenBSD it never broke = traffic for me. >=20 I'm wrong; reassemble tcp still exists upstream. I must be thinking of = something else that has since been removed but exists in our version. Oh = well. From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 19:31:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFB393AB; Thu, 24 Jul 2014 19:31:44 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 862B02FEE; Thu, 24 Jul 2014 19:31:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=fA8lbrwLz19Cc2q0fi4rw+VGDXRwWbN59v12GZwbaS4=; b=mRdHx59Krj5Jkb4MTiXdmFG9Du4MBX6A8c56fwuh6z8Y/FAbeFhcdUdIeSuWYtUbG+7qIOL9C9eyL7KJh+aufGMrzMxTA4kO8AueHPBRY3Ue2xoKYvCefzDdRAYvBqxmg/+zkxqAVq15Q3fwpmoKXQbataA2Sls/Z+il4bh4O0w=; Received: from localhost.lerctr.org ([127.0.0.1]:41287 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAOjt-000IaR-O9; Thu, 24 Jul 2014 14:31:43 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 14:31:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 14:31:41 -0500 From: Larry Rosenman To: Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:31:44 -0000 On 2014-07-24 13:46, Larry Rosenman wrote: >> I notice you are doing a deduplicated stream. Does it work without >> deduplication (zfs send -D)? > I will try that after this zxfer test I'm running finishes, but IIRC > it doesn't matter.. borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O root@tbh.lerctr.org -R zroot zroot/backups/TBH Creating recursive snapshot zroot@zxfer_26699_20140724135840. Checking grandfather status of all snapshots marked for deletion... Grandfather check passed. Sending zroot@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot. Sending zroot/ROOT@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot/ROOT. Sending zroot/ROOT/default@zxfer_23699_20140724134435 to zroot/backups/TBH/zroot/ROOT/default. Sending zroot/ROOT/default@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot/ROOT/default. (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.) Sending zroot/home@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot/home. Write failed: Cannot allocate memory cannot receive new filesystem stream: invalid backup stream Error when zfs send/receiving. borg.lerctr.org /home/ler # well that's different....... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 19:54:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D11D4D41; Thu, 24 Jul 2014 19:54:03 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 815AC21B1; Thu, 24 Jul 2014 19:54:03 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hK4491d6rzLm; Thu, 24 Jul 2014 21:54:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1406231636; x=1408823637; bh=n6J CFmYBR1SbStk/Ok+l23JXcR1ITa2xt0mIGz9Avvs=; b=TAcIAQ/x8lZfyKqZqGX /gIaMMLe/fE55fGtjWMM6AqpFGnJVv8h4LHuP99+Ph8XrLtQh+U13PGK7QVSHilh j+8+1muD4Z/qXhcm6Yp0IlOAZL4eXSYpFqAuxU7u1ClVOmGNw6PHlIGwbEkEAJSp F1dUER2Wn8ICoDvbGSgg+0oo= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id ZXWpu2G07fmD; Thu, 24 Jul 2014 21:53:56 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Thu, 24 Jul 2014 21:53:56 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hK4441CPjzlH; Thu, 24 Jul 2014 21:53:56 +0200 (CEST) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 21:53:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 21:53:56 +0200 From: Mark Martinec To: Larry Rosenman Subject: Re: zfs send/recv: STILL invalid Backup Stream Organization: J. Stefan Institute In-Reply-To: References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> Message-ID: <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 Cc: Freebsd fs , freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:54:03 -0000 2014-07-24 21:31, Larry Rosenman wrote: > borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O > root@tbh.lerctr.org -R zroot zroot/backups/TBH > Creating recursive snapshot zroot@zxfer_26699_20140724135840. > Checking grandfather status of all snapshots marked for deletion... > Grandfather check passed. > Sending zroot@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot. > Sending zroot/ROOT@zxfer_26699_20140724135840 to > zroot/backups/TBH/zroot/ROOT. > Sending zroot/ROOT/default@zxfer_23699_20140724134435 to > zroot/backups/TBH/zroot/ROOT/default. > Sending zroot/ROOT/default@zxfer_26699_20140724135840 to > zroot/backups/TBH/zroot/ROOT/default. > (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.) > Sending zroot/home@zxfer_26699_20140724135840 to > zroot/backups/TBH/zroot/home. > Write failed: Cannot allocate memory ==================================== > cannot receive new filesystem stream: invalid backup stream > Error when zfs send/receiving. > borg.lerctr.org /home/ler # > > well that's different....... Sounds familiar, check my posting of today and links therein: http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html Mark From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 19:58:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6F37A7; Thu, 24 Jul 2014 19:58:00 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9414921E0; Thu, 24 Jul 2014 19:58:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=p8LjRnc0lqNt6ko4/sznoKQzD98gBIpyID5xA5trqJM=; b=iWx/ukxIO4S0bsU2Plc4NswOY7bur9AnMQbpdv2oGmALhLk96svufBh20UDgq5plTH6JV4hpzGbhk7vgBfG/Y/dXi5eDICJO7DiRyXhEOBvR502968rGAmk2Gf37yzORiUqxOqtxTfFiR7XsS9u7dfNIq6+scvLdN4mT/mhb4K8=; Received: from localhost.lerctr.org ([127.0.0.1]:23406 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAP9K-000J6m-2I; Thu, 24 Jul 2014 14:57:59 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 14:57:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 14:57:57 -0500 From: Larry Rosenman To: Mark Martinec Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:58:01 -0000 On 2014-07-24 14:53, Mark Martinec wrote: > 2014-07-24 21:31, Larry Rosenman wrote: >> borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O >> root@tbh.lerctr.org -R zroot zroot/backups/TBH >> Creating recursive snapshot zroot@zxfer_26699_20140724135840. >> Checking grandfather status of all snapshots marked for deletion... >> Grandfather check passed. >> Sending zroot@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot. >> Sending zroot/ROOT@zxfer_26699_20140724135840 to >> zroot/backups/TBH/zroot/ROOT. >> Sending zroot/ROOT/default@zxfer_23699_20140724134435 to >> zroot/backups/TBH/zroot/ROOT/default. >> Sending zroot/ROOT/default@zxfer_26699_20140724135840 to >> zroot/backups/TBH/zroot/ROOT/default. >> (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.) >> Sending zroot/home@zxfer_26699_20140724135840 to >> zroot/backups/TBH/zroot/home. > >> Write failed: Cannot allocate memory > ==================================== > >> cannot receive new filesystem stream: invalid backup stream >> Error when zfs send/receiving. >> borg.lerctr.org /home/ler # >> >> well that's different....... > > Sounds familiar, check my posting of today and links therein: > > http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html > > Mark I'm not using netgraph to the best of my knowledge.... and the only fails on the SENDING host are: 8 Bucket: 64, 0, 41, 3555, 257774, 11, 0 12 Bucket: 96, 0, 96, 2569, 123653, 0, 0 16 Bucket: 128, 0, 17195, 506, 215573, 0, 0 32 Bucket: 256, 0, 340, 4670, 900638, 50, 0 64 Bucket: 512, 0, 10691, 365, 546888,185232, 0 128 Bucket: 1024, 0, 3563, 905, 348419, 0, 0 256 Bucket: 2048, 0, 2872, 162, 249995,59834, 0 vmem btag: 56, 0, 192811, 51500, 502264,1723, 0 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 20:07:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D74B3DF for ; Thu, 24 Jul 2014 20:07:21 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 51E7022D0 for ; Thu, 24 Jul 2014 20:07:20 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 951FE2C8D6 for ; Thu, 24 Jul 2014 20:07:18 +0000 (UTC) Message-ID: <53D1678C.4000007@freebsd.org> Date: Thu, 24 Jul 2014 16:07:40 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zfs send/recv: STILL invalid Backup Stream References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e0Xlq1IfcbqKLu49LDATHoaS9adO8j7L3" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:07:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e0Xlq1IfcbqKLu49LDATHoaS9adO8j7L3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-24 15:57, Larry Rosenman wrote: > On 2014-07-24 14:53, Mark Martinec wrote: >> 2014-07-24 21:31, Larry Rosenman wrote: >>> borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O >>> root@tbh.lerctr.org -R zroot zroot/backups/TBH >>> Creating recursive snapshot zroot@zxfer_26699_20140724135840. >>> Checking grandfather status of all snapshots marked for deletion... >>> Grandfather check passed. >>> Sending zroot@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot. >>> Sending zroot/ROOT@zxfer_26699_20140724135840 to >>> zroot/backups/TBH/zroot/ROOT. >>> Sending zroot/ROOT/default@zxfer_23699_20140724134435 to >>> zroot/backups/TBH/zroot/ROOT/default. >>> Sending zroot/ROOT/default@zxfer_26699_20140724135840 to >>> zroot/backups/TBH/zroot/ROOT/default. >>> (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.) >>> Sending zroot/home@zxfer_26699_20140724135840 to >>> zroot/backups/TBH/zroot/home. >> >>> Write failed: Cannot allocate memory >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> cannot receive new filesystem stream: invalid backup stream >>> Error when zfs send/receiving. >>> borg.lerctr.org /home/ler # >>> >>> well that's different....... >> >> Sounds familiar, check my posting of today and links therein: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html= >> >> Mark > I'm not using netgraph to the best of my knowledge.... > and the only fails on the SENDING host are: > 8 Bucket: 64, 0, 41, 3555, 257774, 11, = 0 > 12 Bucket: 96, 0, 96, 2569, 123653, 0, = 0 > 16 Bucket: 128, 0, 17195, 506, 215573, 0, = 0 > 32 Bucket: 256, 0, 340, 4670, 900638, 50, = 0 > 64 Bucket: 512, 0, 10691, 365, 546888,185232, = 0 > 128 Bucket: 1024, 0, 3563, 905, 348419, 0, = 0 > 256 Bucket: 2048, 0, 2872, 162, 249995,59834, = 0 > vmem btag: 56, 0, 192811, 51500, 502264,1723, = 0 >=20 >=20 I regularly use zxfer to transfer 500+ GiB datasets over the internet. This week I actually replicated a 2.1 TiB dataset with zxfer without issu= e. I wonder which thing is running out of memory. Is there a delay while it is 'running out of memory', or does it fail immediately? Does running top while it is working on running out of memory reveal anything? I would expect to use up a lot of memory while doing deduplication, but not otherwise. Note: I most often use openssh-portable rather than base ssh for replication, as I enable the nonecipher to reduce CPU usage, and adjust the TcpRcvBuf upwards to actually saturate a gigabit over the internet. --=20 Allan Jude --e0Xlq1IfcbqKLu49LDATHoaS9adO8j7L3 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0WePAAoJEJrBFpNRJZKfh/gQAIU1hqAVh+MNeGJcdGxOmX80 XAUom/xeG0VFHH5WGmMJa/wq2ouYg0jhTTZ5eOsK4ecnCQzRODGomBZd+OBXSThm KXsREXz2wgOWQV+kfjD38bE5mDUExyguFwRCn79RGNmeALCIDslRfQjMmuRLV4G/ VK74ykzSyIT0llEnKa/j/JFYaETGJONv4ouF3odBEPIrHQ3/TJ/wRqbrnPhs8ooO 1fJrZpUh4qeOmRdWbHeTg6MrI4HlKZV8JIP3S0+BLCFQu/a0nygfUw+XYAsUAala if/ByCnSaapoq3++MkcM/pTEbHrgpAeNJOD9lCvZVcnN5W0HE5jNz8vMazODiqXR pbQIf2lYJXfS1tZfigUDeyzYuB4kJcekn47lzCQ5L7dM+fx+rguitsOIkGRYdKf+ LrsMtjCcs3pIWYY7eA108IdOKC4P5PQ9kVLrXZZgYvcTWUNr9dqr4CovHCciXHM1 RLiTDk8bYMQYZiEDX7wJ9b72O7u/W/y72tVc17JMfkGgzkBV0UawsSbCAAx+KFWg SlM7jUe4WgSpvP7u+wMmVWqUi+aXiOhes6TvjLe8jXm/FTpCGhevxrGYmZ5SgQfy 2VAyNZYzgsPXBUHserbV8ASDW2tzAI82CPGsJsGmyqp89DXYv1lhHy2/fb2POLpA t2cBceh9/hQWJVbZBG/m =z/m5 -----END PGP SIGNATURE----- --e0Xlq1IfcbqKLu49LDATHoaS9adO8j7L3-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 20:11:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD0EB650; Thu, 24 Jul 2014 20:11:44 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A82282376; Thu, 24 Jul 2014 20:11:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=3UiDi1+aocOnaMg1FHQjMIAViSgjux9q+dCNC03jEkg=; b=Qnh4MutrKnlLnOjNmdIc5Yi2bRiUvBTAjG3VOwFXHZrC/7f5lKdCz0tj5E32IEsDucuvCrkusC0rIohhWIR8tlWcacBEncyA7Sv1RyMRpGDqEfFdjP5ujyHTqT9S94Ti5m46+J9zn+yVCRwAWRllxZvMe3ckRBvMZRmSHgPQ5LE=; Received: from localhost.lerctr.org ([127.0.0.1]:30108 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAPMR-000JLE-MY; Thu, 24 Jul 2014 15:11:43 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 15:11:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 15:11:31 -0500 From: Larry Rosenman To: Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <53D1678C.4000007@freebsd.org> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <53D1678C.4000007@freebsd.org> Message-ID: <6e382c7d7efc8b4ddc3b770985eac1e0@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , Mark Martinec , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:11:45 -0000 On 2014-07-24 15:07, Allan Jude wrote: > On 2014-07-24 15:57, Larry Rosenman wrote: >> On 2014-07-24 14:53, Mark Martinec wrote: >>> 2014-07-24 21:31, Larry Rosenman wrote: >>>> borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O >>>> root@tbh.lerctr.org -R zroot zroot/backups/TBH >>>> Creating recursive snapshot zroot@zxfer_26699_20140724135840. >>>> Checking grandfather status of all snapshots marked for deletion... >>>> Grandfather check passed. >>>> Sending zroot@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot. >>>> Sending zroot/ROOT@zxfer_26699_20140724135840 to >>>> zroot/backups/TBH/zroot/ROOT. >>>> Sending zroot/ROOT/default@zxfer_23699_20140724134435 to >>>> zroot/backups/TBH/zroot/ROOT/default. >>>> Sending zroot/ROOT/default@zxfer_26699_20140724135840 to >>>> zroot/backups/TBH/zroot/ROOT/default. >>>> (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.) >>>> Sending zroot/home@zxfer_26699_20140724135840 to >>>> zroot/backups/TBH/zroot/home. >>> >>>> Write failed: Cannot allocate memory >>> ==================================== >>> >>>> cannot receive new filesystem stream: invalid backup stream >>>> Error when zfs send/receiving. >>>> borg.lerctr.org /home/ler # >>>> >>>> well that's different....... >>> >>> Sounds familiar, check my posting of today and links therein: >>> >>> >>> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html >>> >>> Mark >> I'm not using netgraph to the best of my knowledge.... >> and the only fails on the SENDING host are: >> 8 Bucket: 64, 0, 41, 3555, 257774, 11, >> 0 >> 12 Bucket: 96, 0, 96, 2569, 123653, 0, >> 0 >> 16 Bucket: 128, 0, 17195, 506, 215573, 0, >> 0 >> 32 Bucket: 256, 0, 340, 4670, 900638, 50, >> 0 >> 64 Bucket: 512, 0, 10691, 365, 546888,185232, >> 0 >> 128 Bucket: 1024, 0, 3563, 905, 348419, 0, >> 0 >> 256 Bucket: 2048, 0, 2872, 162, 249995,59834, >> 0 >> vmem btag: 56, 0, 192811, 51500, 502264,1723, >> 0 >> >> > > I regularly use zxfer to transfer 500+ GiB datasets over the internet. > This week I actually replicated a 2.1 TiB dataset with zxfer without > issue. > > I wonder which thing is running out of memory. Is there a delay while > it > is 'running out of memory', or does it fail immediately? Does running > top while it is working on running out of memory reveal anything? > > I would expect to use up a lot of memory while doing deduplication, but > not otherwise. > > Note: I most often use openssh-portable rather than base ssh for > replication, as I enable the nonecipher to reduce CPU usage, and adjust > the TcpRcvBuf upwards to actually saturate a gigabit over the internet. I wasn't watching exactly what it was doing, but the sending box has 16G and 18G Swap and swap has NOT been touched. last pid: 74288; load averages: 4.70, 5.61, 5.91 up 1+03:14:18 15:10:44 115 processes: 3 running, 112 sleeping CPU: 0.6% user, 33.3% nice, 0.6% system, 0.1% interrupt, 65.4% idle Mem: 847M Active, 761M Inact, 14G Wired, 4616K Cache, 357M Free ARC: 12G Total, 6028M MFU, 5281M MRU, 3152K Anon, 120M Header, 688M Other Swap: 18G Total, 18G Free so I have zero idea where to go here. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 20:26:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17CF1D53; Thu, 24 Jul 2014 20:26:21 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id BB60E24B4; Thu, 24 Jul 2014 20:26:20 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hK4nS0zKrzTv; Thu, 24 Jul 2014 22:26:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1406233575; x=1408825576; bh=tpv 5Wj26lIjjF/uPaYuPQ98QNsx5mWc+3hLxzwesSlk=; b=SYd+WlLExOX8Q+n5TrZ ZsiHUeircXkqEHRMg/m7vfyev+Fnv4EKQ3OqJAYqfhD93pKeAHVXEEndz4h7w2cG yhYgBX4mvuya0hOVHIegLMzN4OKfj3XAVzo/+KlXAM7DuPQOByYuNCZG+kOEcWGJ wzJlWhTK2IIM3fjbL4pdPtZ0= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id NdrahVGRa37c; Thu, 24 Jul 2014 22:26:15 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Thu, 24 Jul 2014 22:26:15 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hK4nM6j1Nzrc; Thu, 24 Jul 2014 22:26:15 +0200 (CEST) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 22:26:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 22:26:15 +0200 From: Mark Martinec To: Larry Rosenman Subject: Re: zfs send/recv: STILL invalid Backup Stream Organization: J. Stefan Institute In-Reply-To: References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> Message-ID: <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:26:21 -0000 2014-07-24 21:57, Larry Rosenman wrote: >>>> Sending zroot/home@zxfer_26699_20140724135840 to >>>> zroot/backups/TBH/zroot/home. >>> Write failed: Cannot allocate memory >> ==================================== >>> cannot receive new filesystem stream: invalid backup stream >>> Error when zfs send/receiving. >>> borg.lerctr.org /home/ler # >>> >>> well that's different....... >> >> Sounds familiar, check my posting of today and links therein: >> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html > I'm not using netgraph to the best of my knowledge.... Check to make sure: vmstat -z | fgrep NetGraph > and the only fails on the SENDING host are: > 8 Bucket: 64, 0, 41, 3555, 257774, 11, > 0 > 12 Bucket: 96, 0, 96, 2569, 123653, 0, > 0 > 16 Bucket: 128, 0, 17195, 506, 215573, 0, > 0 > 32 Bucket: 256, 0, 340, 4670, 900638, 50, > 0 > 64 Bucket: 512, 0, 10691, 365, 546888,185232, > 0 > 128 Bucket: 1024, 0, 3563, 905, 348419, 0, > 0 > 256 Bucket: 2048, 0, 2872, 162, 249995,59834, > 0 > vmem btag: 56, 0, 192811, 51500, 502264,1723, > 0 Adam Vande More gave other suggestions on that thread from 2011: http://lists.freebsd.org/pipermail/freebsd-emulation/2011-July/008971.html Mark From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 20:44:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0442D3DC; Thu, 24 Jul 2014 20:44:34 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C07E9263A; Thu, 24 Jul 2014 20:44:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=X7iovG7EY1z554Rg8rDnBUceBOBfe6ToLZ15UYx5urg=; b=lUbMmsdTAOhyyia723zHWzi7NABSO9JOT+6KQ05Ws3YX1YEgA1oP4u4NK3AWTebA+dv8N5YglnMlAw4XgcR/5NBWoxH6Vz/G2jhiAfWMpCkb1o4RR28wX5d5HIaj53A7La8iiSchLPzkIggvu/8cqqJaS0BOXbsXOLxaL2NBMgU=; Received: from localhost.lerctr.org ([127.0.0.1]:56175 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAPsL-000JqL-Nz; Thu, 24 Jul 2014 15:44:32 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 15:44:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 15:44:29 -0500 From: Larry Rosenman To: Mark Martinec Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:44:34 -0000 On 2014-07-24 15:26, Mark Martinec wrote: > 2014-07-24 21:57, Larry Rosenman wrote: > >>>>> Sending zroot/home@zxfer_26699_20140724135840 to >>>>> zroot/backups/TBH/zroot/home. >>>> Write failed: Cannot allocate memory >>> ==================================== >>>> cannot receive new filesystem stream: invalid backup stream >>>> Error when zfs send/receiving. >>>> borg.lerctr.org /home/ler # >>>> >>>> well that's different....... >>> >>> Sounds familiar, check my posting of today and links therein: >>> >>> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html > >> I'm not using netgraph to the best of my knowledge.... > > Check to make sure: > vmstat -z | fgrep NetGraph > >> and the only fails on the SENDING host are: >> 8 Bucket: 64, 0, 41, 3555, 257774, 11, >> 0 >> 12 Bucket: 96, 0, 96, 2569, 123653, 0, >> 0 >> 16 Bucket: 128, 0, 17195, 506, 215573, 0, >> 0 >> 32 Bucket: 256, 0, 340, 4670, 900638, 50, >> 0 >> 64 Bucket: 512, 0, 10691, 365, 546888,185232, >> 0 >> 128 Bucket: 1024, 0, 3563, 905, 348419, 0, >> 0 >> 256 Bucket: 2048, 0, 2872, 162, 249995,59834, >> 0 >> vmem btag: 56, 0, 192811, 51500, 502264,1723, >> 0 > > > Adam Vande More gave other suggestions on that thread from 2011: > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2011-July/008971.html > > > Mark thebighonker.lerctr.org /home/ler $ vmstat -z|fgrep NetGraph thebighonker.lerctr.org /home/ler $ This on physical hardware, FWIW. thebighonker.lerctr.org /home/ler $ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 202, 8, 202, 0, 0 UMA Zones: 1664, 0, 202, 0, 202, 0, 0 UMA Slabs: 80, 0, 361152, 38448, 1561588, 0, 0 UMA RCntSlabs: 88, 0, 4360, 5, 4360, 0, 0 UMA Hash: 256, 0, 8, 82, 82, 0, 0 4 Bucket: 32, 0, 4816, 33684, 2974043, 0, 0 6 Bucket: 48, 0, 6118, 2514, 624434, 0, 0 8 Bucket: 64, 0, 161, 3435, 265443, 11, 0 12 Bucket: 96, 0, 177, 2488, 130226, 0, 0 16 Bucket: 128, 0, 20301, 531, 224788, 0, 0 32 Bucket: 256, 0, 433, 4577, 945047, 50, 0 64 Bucket: 512, 0, 11137, 575, 579209,211292, 0 128 Bucket: 1024, 0, 3509, 959, 369839, 0, 0 256 Bucket: 2048, 0, 2847, 187, 269044,59834, 0 vmem btag: 56, 0, 209393, 34918, 557576,1723, 0 VM OBJECT: 256, 0, 91384, 791, 3480613, 0, 0 RADIX NODE: 144, 0, 227133, 37683,16029821, 0, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 10, 269, 10, 0, 0 MAP ENTRY: 128, 0, 12666, 23604, 9357932, 0, 0 VMSPACE: 448, 0, 108, 306, 75357, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 368, 0, 368, 0, 0 16: 16, 0, 267839, 2488,45160196, 0, 0 32: 32, 0, 148139, 1486,39174301, 0, 0 64: 64, 0, 291630, 504078,40379996, 0, 0 128: 128, 0, 182409, 35490,63455920, 0, 0 256: 256, 0, 89368, 230912,35841036, 0, 0 512: 512, 0, 741, 3987,24215854, 0, 0 1024: 1024, 0, 1371, 1385, 1726440, 0, 0 2048: 2048, 0, 277, 417,10240207, 0, 0 4096: 4096, 0, 38306, 17186, 913638, 0, 0 SLEEPQUEUE: 80, 0, 613, 658, 613, 0, 0 64 pcpu: 8, 0, 1884, 1188, 1884, 0, 0 Files: 80, 0, 829, 1571, 4279893, 0, 0 rl_entry: 40, 0, 209, 1891, 209, 0, 0 TURNSTILE: 136, 0, 613, 307, 613, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 131, 121, 76219, 0, 0 THREAD: 1168, 0, 519, 93, 2039, 0, 0 cpuset: 72, 0, 270, 280, 426, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 6519810, 4081, 3256, 4910227, 0, 0 mbuf: 256, 6519810, 1052, 3251,93444045, 0, 0 mbuf_cluster: 2048, 1018718, 7337, 13, 7337, 0, 0 mbuf_jumbo_page: 4096, 509359, 12, 673,15015378, 0, 0 mbuf_jumbo_9k: 9216, 150921, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 84893, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 2510, 85094, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 0, 1600,29986631, 0, 0 ttyinq: 160, 0, 180, 570, 2100, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 ttyoutq: 256, 0, 95, 640, 1093, 0, 0 ata_request: 336, 0, 0, 242, 33344, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 1, 3070, 194184, 0, 0 taskq_zone: 48, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 109527, 66161, 2663226, 0, 0 VNODEPOLL: 112, 0, 8, 762, 10, 0, 0 BUF TRIE: 144, 0, 0, 105354, 0, 0, 0 S VFS Cache: 108, 0, 114973, 60552, 2293717, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 468, 145536, 800279, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 156,23968745, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 0, 0, 0, 0, 0 Mountpoints: 816, 0, 11, 19, 11, 0, 0 range_seg_cache: 64, 0, 58377, 7157, 3500156, 0, 0 zio_cache: 920, 0, 1, 42591,104595517, 0, 0 zio_link_cache: 48, 0, 0, 44073,72482492, 0, 0 zio_buf_512: 512, 0, 552060, 193836, 1557459, 0, 0 zio_data_buf_512: 512, 0, 114904, 2056, 526943, 0, 0 zio_buf_1024: 1024, 0, 4246, 58, 56140, 0, 0 zio_data_buf_1024: 1024, 0, 51117, 1255, 211875, 0, 0 zio_buf_1536: 1536, 0, 1957, 59, 72179, 0, 0 zio_data_buf_1536: 1536, 0, 22199, 719, 127817, 0, 0 zio_buf_2048: 2048, 0, 691, 43, 217643, 0, 0 zio_data_buf_2048: 2048, 0, 13419, 1147, 87149, 0, 0 zio_buf_2560: 2560, 0, 455, 20, 16265, 0, 0 zio_data_buf_2560: 2560, 0, 9335, 493, 73967, 0, 0 zio_buf_3072: 3072, 0, 245, 16, 4658, 0, 0 zio_data_buf_3072: 3072, 0, 6940, 512, 53932, 0, 0 zio_buf_3584: 3584, 0, 248, 10, 38558, 0, 0 zio_data_buf_3584: 3584, 0, 5076, 352, 43162, 0, 0 zio_buf_4096: 4096, 0, 464, 729,14217630, 0, 0 zio_data_buf_4096: 4096, 0, 3857, 288, 41192, 0, 0 zio_buf_5120: 5120, 0, 167, 9, 6442, 0, 0 zio_data_buf_5120: 5120, 0, 6025, 461, 51297, 0, 0 zio_buf_6144: 6144, 0, 115, 6, 3196, 0, 0 zio_data_buf_6144: 6144, 0, 4453, 309, 38753, 0, 0 zio_buf_7168: 7168, 0, 85, 12, 36945, 0, 0 zio_data_buf_7168: 7168, 0, 3373, 273, 29007, 0, 0 zio_buf_8192: 8192, 0, 44, 39, 1373975, 0, 0 zio_data_buf_8192: 8192, 0, 2543, 205, 28736, 0, 0 zio_buf_10240: 10240, 0, 66, 7, 2534, 0, 0 zio_data_buf_10240: 10240, 0, 3986, 275, 39568, 0, 0 zio_buf_12288: 12288, 0, 71, 15, 654156, 0, 0 zio_data_buf_12288: 12288, 0, 2937, 209, 37077, 0, 0 zio_buf_14336: 14336, 0, 32, 9, 3164, 0, 0 zio_data_buf_14336: 14336, 0, 2236, 194, 23959, 0, 0 zio_buf_16384: 16384, 0, 72627, 226, 2784131, 0, 0 zio_data_buf_16384: 16384, 0, 1778, 155, 22372, 0, 0 zio_buf_20480: 20480, 0, 210, 14, 598092, 0, 0 zio_data_buf_20480: 20480, 0, 2724, 216, 29228, 0, 0 zio_buf_24576: 24576, 0, 18, 14, 270172, 0, 0 zio_data_buf_24576: 24576, 0, 2101, 173, 21241, 0, 0 zio_buf_28672: 28672, 0, 10, 54, 503029, 0, 0 zio_data_buf_28672: 28672, 0, 1406, 113, 18667, 0, 0 zio_buf_32768: 32768, 0, 10, 11, 77998, 0, 0 zio_data_buf_32768: 32768, 0, 1088, 96, 14116, 0, 0 zio_buf_36864: 36864, 0, 6, 11, 79009, 0, 0 zio_data_buf_36864: 36864, 0, 871, 87, 10066, 0, 0 zio_buf_40960: 40960, 0, 8, 10, 80622, 0, 0 zio_data_buf_40960: 40960, 0, 785, 57, 8149, 0, 0 zio_buf_45056: 45056, 0, 50, 10, 70143, 0, 0 zio_data_buf_45056: 45056, 0, 659, 61, 6889, 0, 0 zio_buf_49152: 49152, 0, 190, 9, 73508, 0, 0 zio_data_buf_49152: 49152, 0, 512, 42, 8420, 0, 0 zio_buf_53248: 53248, 0, 25, 10, 99339, 0, 0 zio_data_buf_53248: 53248, 0, 465, 30, 4838, 0, 0 zio_buf_57344: 57344, 0, 2, 15, 95818, 0, 0 zio_data_buf_57344: 57344, 0, 337, 33, 4753, 0, 0 zio_buf_61440: 61440, 0, 1, 23, 98972, 0, 0 zio_data_buf_61440: 61440, 0, 294, 33, 3792, 0, 0 zio_buf_65536: 65536, 0, 1, 9, 114664, 0, 0 zio_data_buf_65536: 65536, 0, 291, 29, 5152, 0, 0 zio_buf_69632: 69632, 0, 2, 10, 90765, 0, 0 zio_data_buf_69632: 69632, 0, 291, 22, 3555, 0, 0 zio_buf_73728: 73728, 0, 1, 12, 87316, 0, 0 zio_data_buf_73728: 73728, 0, 219, 23, 3361, 0, 0 zio_buf_77824: 77824, 0, 2, 9, 101758, 0, 0 zio_data_buf_77824: 77824, 0, 196, 25, 2907, 0, 0 zio_buf_81920: 81920, 0, 0, 15, 129645, 0, 0 zio_data_buf_81920: 81920, 0, 187, 18, 3578, 0, 0 zio_buf_86016: 86016, 0, 1, 7, 99241, 0, 0 zio_data_buf_86016: 86016, 0, 180, 22, 26051, 0, 0 zio_buf_90112: 90112, 0, 1, 12, 51491, 0, 0 zio_data_buf_90112: 90112, 0, 163, 18, 2438, 0, 0 zio_buf_94208: 94208, 0, 0, 9, 51043, 0, 0 zio_data_buf_94208: 94208, 0, 149, 12, 2288, 0, 0 zio_buf_98304: 98304, 0, 2, 8, 50322, 0, 0 zio_data_buf_98304: 98304, 0, 170, 25, 3002, 0, 0 zio_buf_102400: 102400, 0, 2, 10, 44642, 0, 0 zio_data_buf_102400: 102400, 0, 145, 19, 2017, 0, 0 zio_buf_106496: 106496, 0, 0, 15, 161697, 0, 0 zio_data_buf_106496: 106496, 0, 161, 16, 1944, 0, 0 zio_buf_110592: 110592, 0, 0, 19, 146777, 0, 0 zio_data_buf_110592: 110592, 0, 97, 15, 1636, 0, 0 zio_buf_114688: 114688, 0, 2, 8, 51698, 0, 0 zio_data_buf_114688: 114688, 0, 115, 20, 2691, 0, 0 zio_buf_118784: 118784, 0, 0, 8, 62915, 0, 0 zio_data_buf_118784: 118784, 0, 96, 11, 1440, 0, 0 zio_buf_122880: 122880, 0, 0, 12, 85924, 0, 0 zio_data_buf_122880: 122880, 0, 73, 17, 1510, 0, 0 zio_buf_126976: 126976, 0, 1, 11, 86133, 0, 0 zio_data_buf_126976: 126976, 0, 80, 9, 1351, 0, 0 zio_buf_131072: 131072, 0, 43, 43, 548063, 0, 0 zio_data_buf_131072: 131072, 0, 67545, 2, 646567, 0, 0 lz4_ctx: 16384, 0, 0, 16, 2249605, 0, 0 sa_cache: 80, 0, 109455, 66445, 2663034, 0, 0 dnode_t: 744, 0, 501793, 259152, 873895, 0, 0 dmu_buf_impl_t: 224, 0, 635273, 343604, 3042828, 0, 0 arc_buf_hdr_t: 216, 0, 643049, 141229, 3158205, 0, 0 arc_buf_t: 72, 0, 481443, 119872, 3705908, 0, 0 zil_lwb_cache: 192, 0, 8, 5072, 66838, 0, 0 zfs_znode_cache: 368, 0, 109455, 66105, 2663034, 0, 0 pipe: 744, 0, 113, 177, 66135, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 237, 2528, 8311580, 0, 0 itimer: 352, 0, 1, 32, 1, 0, 0 KNOTE: 128, 0, 376, 1391,17307485, 0, 0 socket: 696, 523340, 258, 302, 668458, 0, 0 unpcb: 240, 523344, 151, 649, 130961, 0, 0 ipq: 56, 31879, 0, 2059, 317, 0, 0 udp_inpcb: 392, 523340, 19, 421, 469503, 0, 0 udpcb: 16, 523586, 19, 2993, 469503, 0, 0 tcp_inpcb: 392, 523340, 100, 370, 67983, 0, 0 tcpcb: 1024, 523340, 78, 234, 67983, 0, 0 tcptw: 88, 27810, 22, 1013, 22066, 0, 0 syncache: 160, 15375, 0, 675, 45270, 0, 0 hostcache: 136, 15370, 255, 499, 3892, 0, 0 tcpreass: 40, 63700, 0, 2600, 7616, 0, 0 sackhole: 32, 0, 0, 1875, 7184, 0, 0 sctp_ep: 1408, 523340, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 1328, 8, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400000, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 392, 523340, 0, 0, 0, 0, 0 ripcb: 392, 523340, 2, 58, 3, 0, 0 rtentry: 200, 0, 32, 408, 34, 0, 0 selfd: 56, 0, 333, 2223,29658712, 0, 0 SWAPMETA: 288, 2037438, 0, 0, 0, 0, 0 thebighonker.lerctr.org /home/ler -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 23:36:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 047964C3; Thu, 24 Jul 2014 23:36:40 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C31FF25E0; Thu, 24 Jul 2014 23:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=hJ9dgIsT4SfrtS9XLlYHJuoes1PStJQO7tvSbPNv6Wk=; b=jqkJL2SbanAAlHxV2V903jTeZWhYy24TZptFuRZljycLZTau5Id7hLrcr+z5BTxFXbpqKlWOsNle3/ZIepx/URXlPR61HyKzmub0C8q6extvqff1l4B18KkuuR7BUUgqvJEpbC1AxRsFY0mqP+/YaT0b+/suWens1C/5ygpMjn0=; Received: from localhost.lerctr.org ([127.0.0.1]:57714 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XASYs-000M9l-KU; Thu, 24 Jul 2014 18:36:37 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 18:36:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 18:36:34 -0500 From: Larry Rosenman To: Mark Martinec , Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:36:40 -0000 On 2014-07-24 15:44, Larry Rosenman wrote: > On 2014-07-24 15:26, Mark Martinec wrote: >> 2014-07-24 21:57, Larry Rosenman wrote: >> >>>>>> Sending zroot/home@zxfer_26699_20140724135840 to >>>>>> zroot/backups/TBH/zroot/home. >>>>> Write failed: Cannot allocate memory >>>> ==================================== >>>>> cannot receive new filesystem stream: invalid backup stream >>>>> Error when zfs send/receiving. >>>>> borg.lerctr.org /home/ler # >>>>> >>>>> well that's different....... >>>> >>>> Sounds familiar, check my posting of today and links therein: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html >> >>> I'm not using netgraph to the best of my knowledge.... >> >> Check to make sure: >> vmstat -z | fgrep NetGraph >> >>> and the only fails on the SENDING host are: >>> 8 Bucket: 64, 0, 41, 3555, 257774, 11, >>> 0 >>> 12 Bucket: 96, 0, 96, 2569, 123653, 0, >>> 0 >>> 16 Bucket: 128, 0, 17195, 506, 215573, 0, >>> 0 >>> 32 Bucket: 256, 0, 340, 4670, 900638, 50, >>> 0 >>> 64 Bucket: 512, 0, 10691, 365, >>> 546888,185232, >>> 0 >>> 128 Bucket: 1024, 0, 3563, 905, 348419, 0, >>> 0 >>> 256 Bucket: 2048, 0, 2872, 162, 249995,59834, >>> 0 >>> vmem btag: 56, 0, 192811, 51500, 502264,1723, >>> 0 >> >> >> Adam Vande More gave other suggestions on that thread from 2011: >> >> >> http://lists.freebsd.org/pipermail/freebsd-emulation/2011-July/008971.html >> >> >> Mark > > > thebighonker.lerctr.org /home/ler $ vmstat -z|fgrep NetGraph > thebighonker.lerctr.org /home/ler $ > > This on physical hardware, FWIW. > > thebighonker.lerctr.org /home/ler $ vmstat -z > ITEM SIZE LIMIT USED FREE REQ FAIL > SLEEP > > UMA Kegs: 384, 0, 202, 8, 202, 0, > 0 > UMA Zones: 1664, 0, 202, 0, 202, 0, > 0 > UMA Slabs: 80, 0, 361152, 38448, 1561588, 0, > 0 > UMA RCntSlabs: 88, 0, 4360, 5, 4360, 0, > 0 > UMA Hash: 256, 0, 8, 82, 82, 0, > 0 > 4 Bucket: 32, 0, 4816, 33684, 2974043, 0, > 0 > 6 Bucket: 48, 0, 6118, 2514, 624434, 0, > 0 > 8 Bucket: 64, 0, 161, 3435, 265443, 11, > 0 > 12 Bucket: 96, 0, 177, 2488, 130226, 0, > 0 > 16 Bucket: 128, 0, 20301, 531, 224788, 0, > 0 > 32 Bucket: 256, 0, 433, 4577, 945047, 50, > 0 > 64 Bucket: 512, 0, 11137, 575, 579209,211292, > 0 > 128 Bucket: 1024, 0, 3509, 959, 369839, 0, > 0 > 256 Bucket: 2048, 0, 2847, 187, 269044,59834, > 0 > vmem btag: 56, 0, 209393, 34918, 557576,1723, > 0 > VM OBJECT: 256, 0, 91384, 791, 3480613, 0, > 0 > RADIX NODE: 144, 0, 227133, 37683,16029821, 0, > 0 > MAP: 240, 0, 3, 61, 3, 0, > 0 > KMAP ENTRY: 128, 0, 10, 269, 10, 0, > 0 > MAP ENTRY: 128, 0, 12666, 23604, 9357932, 0, > 0 > VMSPACE: 448, 0, 108, 306, 75357, 0, > 0 > fakepg: 104, 0, 0, 0, 0, 0, > 0 > mt_zone: 4112, 0, 368, 0, 368, 0, > 0 > 16: 16, 0, 267839, 2488,45160196, 0, > 0 > 32: 32, 0, 148139, 1486,39174301, 0, > 0 > 64: 64, 0, 291630, 504078,40379996, 0, > 0 > 128: 128, 0, 182409, 35490,63455920, 0, > 0 > 256: 256, 0, 89368, 230912,35841036, 0, > 0 > 512: 512, 0, 741, 3987,24215854, 0, > 0 > 1024: 1024, 0, 1371, 1385, 1726440, 0, > 0 > 2048: 2048, 0, 277, 417,10240207, 0, > 0 > 4096: 4096, 0, 38306, 17186, 913638, 0, > 0 > SLEEPQUEUE: 80, 0, 613, 658, 613, 0, > 0 > 64 pcpu: 8, 0, 1884, 1188, 1884, 0, > 0 > Files: 80, 0, 829, 1571, 4279893, 0, > 0 > rl_entry: 40, 0, 209, 1891, 209, 0, > 0 > TURNSTILE: 136, 0, 613, 307, 613, 0, > 0 > umtx pi: 96, 0, 0, 0, 0, 0, > 0 > MAC labels: 40, 0, 0, 0, 0, 0, > 0 > PROC: 1208, 0, 131, 121, 76219, 0, > 0 > THREAD: 1168, 0, 519, 93, 2039, 0, > 0 > cpuset: 72, 0, 270, 280, 426, 0, > 0 > cyclic_id_cache: 64, 0, 0, 0, 0, 0, > 0 > audit_record: 1248, 0, 0, 0, 0, 0, > 0 > mbuf_packet: 256, 6519810, 4081, 3256, 4910227, 0, > 0 > mbuf: 256, 6519810, 1052, 3251,93444045, 0, > 0 > mbuf_cluster: 2048, 1018718, 7337, 13, 7337, 0, > 0 > mbuf_jumbo_page: 4096, 509359, 12, 673,15015378, 0, > 0 > mbuf_jumbo_9k: 9216, 150921, 0, 0, 0, 0, > 0 > mbuf_jumbo_16k: 16384, 84893, 0, 0, 0, 0, > 0 > mbuf_ext_refcnt: 4, 0, 0, 2510, 85094, 0, > 0 > dtrace_state_cache: 4096, 0, 0, 0, 0, 0, > 0 > g_bio: 248, 0, 0, 1600,29986631, 0, > 0 > ttyinq: 160, 0, 180, 570, 2100, 0, > 0 > DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, > 0 > ttyoutq: 256, 0, 95, 640, 1093, 0, > 0 > ata_request: 336, 0, 0, 242, 33344, 0, > 0 > vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, > 0 > cryptop: 88, 0, 0, 0, 0, 0, > 0 > cryptodesc: 72, 0, 0, 0, 0, 0, > 0 > FPU_save_area: 512, 0, 0, 0, 0, 0, > 0 > taskq_zone: 48, 0, 1, 3070, 194184, 0, > 0 > taskq_zone: 48, 0, 0, 0, 0, 0, > 0 > VNODE: 472, 0, 109527, 66161, 2663226, 0, > 0 > VNODEPOLL: 112, 0, 8, 762, 10, 0, > 0 > BUF TRIE: 144, 0, 0, 105354, 0, 0, > 0 > S VFS Cache: 108, 0, 114973, 60552, 2293717, 0, > 0 > STS VFS Cache: 148, 0, 0, 0, 0, 0, > 0 > L VFS Cache: 328, 0, 468, 145536, 800279, 0, > 0 > LTS VFS Cache: 368, 0, 0, 0, 0, 0, > 0 > NAMEI: 1024, 0, 0, 156,23968745, 0, > 0 > DIRHASH: 1024, 0, 0, 0, 0, 0, > 0 > NCLNODE: 528, 0, 0, 0, 0, 0, > 0 > Mountpoints: 816, 0, 11, 19, 11, 0, > 0 > range_seg_cache: 64, 0, 58377, 7157, 3500156, 0, > 0 > zio_cache: 920, 0, 1, 42591,104595517, 0, > 0 > zio_link_cache: 48, 0, 0, 44073,72482492, 0, > 0 > zio_buf_512: 512, 0, 552060, 193836, 1557459, 0, > 0 > zio_data_buf_512: 512, 0, 114904, 2056, 526943, 0, > 0 > zio_buf_1024: 1024, 0, 4246, 58, 56140, 0, > 0 > zio_data_buf_1024: 1024, 0, 51117, 1255, 211875, 0, > 0 > zio_buf_1536: 1536, 0, 1957, 59, 72179, 0, > 0 > zio_data_buf_1536: 1536, 0, 22199, 719, 127817, 0, > 0 > zio_buf_2048: 2048, 0, 691, 43, 217643, 0, > 0 > zio_data_buf_2048: 2048, 0, 13419, 1147, 87149, 0, > 0 > zio_buf_2560: 2560, 0, 455, 20, 16265, 0, > 0 > zio_data_buf_2560: 2560, 0, 9335, 493, 73967, 0, > 0 > zio_buf_3072: 3072, 0, 245, 16, 4658, 0, > 0 > zio_data_buf_3072: 3072, 0, 6940, 512, 53932, 0, > 0 > zio_buf_3584: 3584, 0, 248, 10, 38558, 0, > 0 > zio_data_buf_3584: 3584, 0, 5076, 352, 43162, 0, > 0 > zio_buf_4096: 4096, 0, 464, 729,14217630, 0, > 0 > zio_data_buf_4096: 4096, 0, 3857, 288, 41192, 0, > 0 > zio_buf_5120: 5120, 0, 167, 9, 6442, 0, > 0 > zio_data_buf_5120: 5120, 0, 6025, 461, 51297, 0, > 0 > zio_buf_6144: 6144, 0, 115, 6, 3196, 0, > 0 > zio_data_buf_6144: 6144, 0, 4453, 309, 38753, 0, > 0 > zio_buf_7168: 7168, 0, 85, 12, 36945, 0, > 0 > zio_data_buf_7168: 7168, 0, 3373, 273, 29007, 0, > 0 > zio_buf_8192: 8192, 0, 44, 39, 1373975, 0, > 0 > zio_data_buf_8192: 8192, 0, 2543, 205, 28736, 0, > 0 > zio_buf_10240: 10240, 0, 66, 7, 2534, 0, > 0 > zio_data_buf_10240: 10240, 0, 3986, 275, 39568, 0, > 0 > zio_buf_12288: 12288, 0, 71, 15, 654156, 0, > 0 > zio_data_buf_12288: 12288, 0, 2937, 209, 37077, 0, > 0 > zio_buf_14336: 14336, 0, 32, 9, 3164, 0, > 0 > zio_data_buf_14336: 14336, 0, 2236, 194, 23959, 0, > 0 > zio_buf_16384: 16384, 0, 72627, 226, 2784131, 0, > 0 > zio_data_buf_16384: 16384, 0, 1778, 155, 22372, 0, > 0 > zio_buf_20480: 20480, 0, 210, 14, 598092, 0, > 0 > zio_data_buf_20480: 20480, 0, 2724, 216, 29228, 0, > 0 > zio_buf_24576: 24576, 0, 18, 14, 270172, 0, > 0 > zio_data_buf_24576: 24576, 0, 2101, 173, 21241, 0, > 0 > zio_buf_28672: 28672, 0, 10, 54, 503029, 0, > 0 > zio_data_buf_28672: 28672, 0, 1406, 113, 18667, 0, > 0 > zio_buf_32768: 32768, 0, 10, 11, 77998, 0, > 0 > zio_data_buf_32768: 32768, 0, 1088, 96, 14116, 0, > 0 > zio_buf_36864: 36864, 0, 6, 11, 79009, 0, > 0 > zio_data_buf_36864: 36864, 0, 871, 87, 10066, 0, > 0 > zio_buf_40960: 40960, 0, 8, 10, 80622, 0, > 0 > zio_data_buf_40960: 40960, 0, 785, 57, 8149, 0, > 0 > zio_buf_45056: 45056, 0, 50, 10, 70143, 0, > 0 > zio_data_buf_45056: 45056, 0, 659, 61, 6889, 0, > 0 > zio_buf_49152: 49152, 0, 190, 9, 73508, 0, > 0 > zio_data_buf_49152: 49152, 0, 512, 42, 8420, 0, > 0 > zio_buf_53248: 53248, 0, 25, 10, 99339, 0, > 0 > zio_data_buf_53248: 53248, 0, 465, 30, 4838, 0, > 0 > zio_buf_57344: 57344, 0, 2, 15, 95818, 0, > 0 > zio_data_buf_57344: 57344, 0, 337, 33, 4753, 0, > 0 > zio_buf_61440: 61440, 0, 1, 23, 98972, 0, > 0 > zio_data_buf_61440: 61440, 0, 294, 33, 3792, 0, > 0 > zio_buf_65536: 65536, 0, 1, 9, 114664, 0, > 0 > zio_data_buf_65536: 65536, 0, 291, 29, 5152, 0, > 0 > zio_buf_69632: 69632, 0, 2, 10, 90765, 0, > 0 > zio_data_buf_69632: 69632, 0, 291, 22, 3555, 0, > 0 > zio_buf_73728: 73728, 0, 1, 12, 87316, 0, > 0 > zio_data_buf_73728: 73728, 0, 219, 23, 3361, 0, > 0 > zio_buf_77824: 77824, 0, 2, 9, 101758, 0, > 0 > zio_data_buf_77824: 77824, 0, 196, 25, 2907, 0, > 0 > zio_buf_81920: 81920, 0, 0, 15, 129645, 0, > 0 > zio_data_buf_81920: 81920, 0, 187, 18, 3578, 0, > 0 > zio_buf_86016: 86016, 0, 1, 7, 99241, 0, > 0 > zio_data_buf_86016: 86016, 0, 180, 22, 26051, 0, > 0 > zio_buf_90112: 90112, 0, 1, 12, 51491, 0, > 0 > zio_data_buf_90112: 90112, 0, 163, 18, 2438, 0, > 0 > zio_buf_94208: 94208, 0, 0, 9, 51043, 0, > 0 > zio_data_buf_94208: 94208, 0, 149, 12, 2288, 0, > 0 > zio_buf_98304: 98304, 0, 2, 8, 50322, 0, > 0 > zio_data_buf_98304: 98304, 0, 170, 25, 3002, 0, > 0 > zio_buf_102400: 102400, 0, 2, 10, 44642, 0, > 0 > zio_data_buf_102400: 102400, 0, 145, 19, 2017, 0, > 0 > zio_buf_106496: 106496, 0, 0, 15, 161697, 0, > 0 > zio_data_buf_106496: 106496, 0, 161, 16, 1944, 0, > 0 > zio_buf_110592: 110592, 0, 0, 19, 146777, 0, > 0 > zio_data_buf_110592: 110592, 0, 97, 15, 1636, 0, > 0 > zio_buf_114688: 114688, 0, 2, 8, 51698, 0, > 0 > zio_data_buf_114688: 114688, 0, 115, 20, 2691, 0, > 0 > zio_buf_118784: 118784, 0, 0, 8, 62915, 0, > 0 > zio_data_buf_118784: 118784, 0, 96, 11, 1440, 0, > 0 > zio_buf_122880: 122880, 0, 0, 12, 85924, 0, > 0 > zio_data_buf_122880: 122880, 0, 73, 17, 1510, 0, > 0 > zio_buf_126976: 126976, 0, 1, 11, 86133, 0, > 0 > zio_data_buf_126976: 126976, 0, 80, 9, 1351, 0, > 0 > zio_buf_131072: 131072, 0, 43, 43, 548063, 0, > 0 > zio_data_buf_131072: 131072, 0, 67545, 2, 646567, 0, > 0 > lz4_ctx: 16384, 0, 0, 16, 2249605, 0, > 0 > sa_cache: 80, 0, 109455, 66445, 2663034, 0, > 0 > dnode_t: 744, 0, 501793, 259152, 873895, 0, > 0 > dmu_buf_impl_t: 224, 0, 635273, 343604, 3042828, 0, > 0 > arc_buf_hdr_t: 216, 0, 643049, 141229, 3158205, 0, > 0 > arc_buf_t: 72, 0, 481443, 119872, 3705908, 0, > 0 > zil_lwb_cache: 192, 0, 8, 5072, 66838, 0, > 0 > zfs_znode_cache: 368, 0, 109455, 66105, 2663034, 0, > 0 > pipe: 744, 0, 113, 177, 66135, 0, > 0 > procdesc: 128, 0, 0, 0, 0, 0, > 0 > ksiginfo: 112, 0, 237, 2528, 8311580, 0, > 0 > itimer: 352, 0, 1, 32, 1, 0, > 0 > KNOTE: 128, 0, 376, 1391,17307485, 0, > 0 > socket: 696, 523340, 258, 302, 668458, 0, > 0 > unpcb: 240, 523344, 151, 649, 130961, 0, > 0 > ipq: 56, 31879, 0, 2059, 317, 0, > 0 > udp_inpcb: 392, 523340, 19, 421, 469503, 0, > 0 > udpcb: 16, 523586, 19, 2993, 469503, 0, > 0 > tcp_inpcb: 392, 523340, 100, 370, 67983, 0, > 0 > tcpcb: 1024, 523340, 78, 234, 67983, 0, > 0 > tcptw: 88, 27810, 22, 1013, 22066, 0, > 0 > syncache: 160, 15375, 0, 675, 45270, 0, > 0 > hostcache: 136, 15370, 255, 499, 3892, 0, > 0 > tcpreass: 40, 63700, 0, 2600, 7616, 0, > 0 > sackhole: 32, 0, 0, 1875, 7184, 0, > 0 > sctp_ep: 1408, 523340, 0, 0, 0, 0, > 0 > sctp_asoc: 2352, 40000, 0, 0, 0, 0, > 0 > sctp_laddr: 48, 80012, 0, 1328, 8, 0, > 0 > sctp_raddr: 728, 80000, 0, 0, 0, 0, > 0 > sctp_chunk: 136, 400026, 0, 0, 0, 0, > 0 > sctp_readq: 104, 400026, 0, 0, 0, 0, > 0 > sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, > 0 > sctp_asconf: 40, 400000, 0, 0, 0, 0, > 0 > sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, > 0 > udplite_inpcb: 392, 523340, 0, 0, 0, 0, > 0 > ripcb: 392, 523340, 2, 58, 3, 0, > 0 > rtentry: 200, 0, 32, 408, 34, 0, > 0 > selfd: 56, 0, 333, 2223,29658712, 0, > 0 > SWAPMETA: 288, 2037438, 0, 0, 0, 0, > 0 > > thebighonker.lerctr.org /home/ler and I ran the script again.... It got further: 18:20:52 25.1G zroot/home@zxfer_26699_20140724135840 18:20:53 25.1G zroot/home@zxfer_26699_20140724135840 18:20:54 25.1G zroot/home@zxfer_26699_20140724135840 18:20:55 25.1G zroot/home@zxfer_26699_20140724135840 18:20:56 25.1G zroot/home@zxfer_26699_20140724135840 18:20:57 25.1G zroot/home@zxfer_26699_20140724135840 18:20:58 25.1G zroot/home@zxfer_26699_20140724135840 Connection to home.lerctr.org closed by remote host. warning: cannot send 'zroot/home@zxfer_26699_20140724135840': Broken pipe TIME SENT SNAPSHOT warning: cannot send 'zroot/home@2014-07-24': Broken pipe cannot open 'zroot/backups/TBH2/home': dataset does not exist borg.lerctr.org /home/ler/bin # BUT we still fail. #!/bin/sh DATE=`date "+%Y-%m-%d"` #DATE2=2013-03-24 #DATE2=`date -v "-1d" "+%Y-%m-%d"` # snap the source ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} # zfs copy the source to here. ssh root@tbh.lerctr.org "zfs send -v -R zroot@${DATE} | \ ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH2\"" # make sure we NEVER allow the backup stuff to automount. /sbin/zfs list -H -t filesystem -r zroot/backups/TBH2| \ awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh borg.lerctr.org /home/ler/bin # this was to a FRESH zroot/backups/TBH2 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 23:56:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDD6D910 for ; Thu, 24 Jul 2014 23:56:10 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id B0C0927E8 for ; Thu, 24 Jul 2014 23:56:10 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 87F5B2CC18 for ; Thu, 24 Jul 2014 23:56:04 +0000 (UTC) Message-ID: <53D19D2E.30908@freebsd.org> Date: Thu, 24 Jul 2014 19:56:30 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zfs send/recv: STILL invalid Backup Stream References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <53D1678C.4000007@freebsd.org> <6e382c7d7efc8b4ddc3b770985eac1e0@thebighonker.lerctr.org> In-Reply-To: <6e382c7d7efc8b4ddc3b770985eac1e0@thebighonker.lerctr.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rV4TUiNK3Hrv04cCwBD3XIjxGtjW4e5TW" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:56:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rV4TUiNK3Hrv04cCwBD3XIjxGtjW4e5TW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-24 16:11, Larry Rosenman wrote: > On 2014-07-24 15:07, Allan Jude wrote: >> On 2014-07-24 15:57, Larry Rosenman wrote: >>> On 2014-07-24 14:53, Mark Martinec wrote: >>>> 2014-07-24 21:31, Larry Rosenman wrote: >>>>> borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O >>>>> root@tbh.lerctr.org -R zroot zroot/backups/TBH >>>>> Creating recursive snapshot zroot@zxfer_26699_20140724135840. >>>>> Checking grandfather status of all snapshots marked for deletion...= >>>>> Grandfather check passed. >>>>> Sending zroot@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot= =2E >>>>> Sending zroot/ROOT@zxfer_26699_20140724135840 to >>>>> zroot/backups/TBH/zroot/ROOT. >>>>> Sending zroot/ROOT/default@zxfer_23699_20140724134435 to >>>>> zroot/backups/TBH/zroot/ROOT/default. >>>>> Sending zroot/ROOT/default@zxfer_26699_20140724135840 to >>>>> zroot/backups/TBH/zroot/ROOT/default. >>>>> (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.) >>>>> Sending zroot/home@zxfer_26699_20140724135840 to >>>>> zroot/backups/TBH/zroot/home. >>>> >>>>> Write failed: Cannot allocate memory >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>>> cannot receive new filesystem stream: invalid backup stream >>>>> Error when zfs send/receiving. >>>>> borg.lerctr.org /home/ler # >>>>> >>>>> well that's different....... >>>> >>>> Sounds familiar, check my posting of today and links therein: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.ht= ml >>>> >>>> Mark >>> I'm not using netgraph to the best of my knowledge.... >>> and the only fails on the SENDING host are: >>> 8 Bucket: 64, 0, 41, 3555, 257774, 11, = 0 >>> 12 Bucket: 96, 0, 96, 2569, 123653, 0, = 0 >>> 16 Bucket: 128, 0, 17195, 506, 215573, 0, = 0 >>> 32 Bucket: 256, 0, 340, 4670, 900638, 50, = 0 >>> 64 Bucket: 512, 0, 10691, 365,=20 >>> 546888,185232, 0 >>> 128 Bucket: 1024, 0, 3563, 905, 348419, 0, = 0 >>> 256 Bucket: 2048, 0, 2872, 162,=20 >>> 249995,59834, 0 >>> vmem btag: 56, 0, 192811, 51500, 502264,1723, = 0 >>> >>> >> >> I regularly use zxfer to transfer 500+ GiB datasets over the internet.= >> This week I actually replicated a 2.1 TiB dataset with zxfer without >> issue. >> >> I wonder which thing is running out of memory. Is there a delay while = it >> is 'running out of memory', or does it fail immediately? Does running >> top while it is working on running out of memory reveal anything? >> >> I would expect to use up a lot of memory while doing deduplication, bu= t >> not otherwise. >> >> Note: I most often use openssh-portable rather than base ssh for >> replication, as I enable the nonecipher to reduce CPU usage, and adjus= t >> the TcpRcvBuf upwards to actually saturate a gigabit over the internet= =2E >=20 > I wasn't watching exactly what it was doing, but the sending box has 16= G > and 18G Swap and swap > has NOT been touched. >=20 > last pid: 74288; load averages: 4.70, 5.61, 5.91 up 1+03:14:18=20 > 15:10:44 > 115 processes: 3 running, 112 sleeping > CPU: 0.6% user, 33.3% nice, 0.6% system, 0.1% interrupt, 65.4% idle > Mem: 847M Active, 761M Inact, 14G Wired, 4616K Cache, 357M Free > ARC: 12G Total, 6028M MFU, 5281M MRU, 3152K Anon, 120M Header, 688M Oth= er > Swap: 18G Total, 18G Free >=20 > so I have zero idea where to go here. >=20 >=20 Most ZFS memory usage is 'wired' and so cannot be swapped, so lack of swap activity isn't a good indicator. --=20 Allan Jude --rV4TUiNK3Hrv04cCwBD3XIjxGtjW4e5TW 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0Z0uAAoJEJrBFpNRJZKflhEP/1ZzsIUWVbBbMf/aKKVcWfKO mnHWGaNt0aVueau/+QUq1L5P2AKyY5/CVXV1mwFP3dGSJZxz0kyUINSPI08ijtig CrZODJcXXo+nwWW7nxG64bwlkzDgag+zmhxwyUCSyMMoo+bUrsDrq8mN64kEaU2G IZcaHSdFeELtHnv8fD2qHFLJdiMGqMGiCEVHc8NlEeq2QvVwBhRc/70HzxhX82hR YZtUZ0AWH/0G8W8EZwAW4LTFc1GMtwwWJGpV432XcVDhYI9E4kYON/qrGxmlSmGN OORrEILQMcfQpxrI/zUtV8+YmcOlywz8K63OjtSKc/GYa5eBLEUsY+5HCpNqIzif nQ7xJUE8bs9Msb8EiwnB0yU1j9MvCxBL33awhWUw4FrMncm+0FCeMrcnWNPTgzys bPQ/gB8itWx4PxAt6/dIfZjDd0HqV7Y1ugqDh7z7b0GtRQ1w4R6i6MspvcARnES2 RA2jfU7kScFpAafXevJmLTeBOa90ieQ+SW6rmw5VRO0qocB0snn8RMqtyxehCN0T 4KfpoigZTJOKN7L9G7bt3ch6ElpFfd1y/5IiAru/5urD1nnU0l78V/doPSiuSM1/ 1JS9RMIIJX9RtU9LGkH1azOxj9fMMYvcc5r8W0vKpzdmETmKxjo0pcYPaJpHG6za f6OAGZmYh4u0FCgOV68W =JL+o -----END PGP SIGNATURE----- --rV4TUiNK3Hrv04cCwBD3XIjxGtjW4e5TW-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 00:14:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 628FEC02; Fri, 25 Jul 2014 00:14:58 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DC43297C; Fri, 25 Jul 2014 00:14:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=OedzOxbOdOFj8MAAxLs83LQ08UAnf1TeElzsDgCcRIg=; b=MEefljKxkiU5n2suxSzILA3xMQUxvLW/TMMY6KOOP5eKo066/KHz4MpWqrwj3Ehk+I+L6HD+aUGNP8j3bsQzgylLqPHvCQX+WW9SBbYNYAz27uhy5qZO4I5qHlM/269/rbMH/g+X0YMOscp/PZIul7392avV3jcP6Pilfdw4N0c=; Received: from localhost.lerctr.org ([127.0.0.1]:11322 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAT9z-000MZl-Ec; Thu, 24 Jul 2014 19:14:57 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 19:14:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 19:14:55 -0500 From: Larry Rosenman To: Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <53D19D2E.30908@freebsd.org> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <53D1678C.4000007@freebsd.org> <6e382c7d7efc8b4ddc3b770985eac1e0@thebighonker.lerctr.org> <53D19D2E.30908@freebsd.org> Message-ID: <817703f97e49979abe0dfeeba7dafeef@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:14:58 -0000 On 2014-07-24 18:56, Allan Jude wrote: > On 2014-07-24 16:11, Larry Rosenman wrote: >> On 2014-07-24 15:07, Allan Jude wrote: >>> On 2014-07-24 15:57, Larry Rosenman wrote: >>>> On 2014-07-24 14:53, Mark Martinec wrote: >>>>> 2014-07-24 21:31, Larry Rosenman wrote: >>>>>> borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O >>>>>> root@tbh.lerctr.org -R zroot zroot/backups/TBH >>>>>> Creating recursive snapshot zroot@zxfer_26699_20140724135840. >>>>>> Checking grandfather status of all snapshots marked for >>>>>> deletion... >>>>>> Grandfather check passed. >>>>>> Sending zroot@zxfer_26699_20140724135840 to >>>>>> zroot/backups/TBH/zroot. >>>>>> Sending zroot/ROOT@zxfer_26699_20140724135840 to >>>>>> zroot/backups/TBH/zroot/ROOT. >>>>>> Sending zroot/ROOT/default@zxfer_23699_20140724134435 to >>>>>> zroot/backups/TBH/zroot/ROOT/default. >>>>>> Sending zroot/ROOT/default@zxfer_26699_20140724135840 to >>>>>> zroot/backups/TBH/zroot/ROOT/default. >>>>>> (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.) >>>>>> Sending zroot/home@zxfer_26699_20140724135840 to >>>>>> zroot/backups/TBH/zroot/home. >>>>> >>>>>> Write failed: Cannot allocate memory >>>>> ==================================== >>>>> >>>>>> cannot receive new filesystem stream: invalid backup stream >>>>>> Error when zfs send/receiving. >>>>>> borg.lerctr.org /home/ler # >>>>>> >>>>>> well that's different....... >>>>> >>>>> Sounds familiar, check my posting of today and links therein: >>>>> >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html >>>>> >>>>> Mark >>>> I'm not using netgraph to the best of my knowledge.... >>>> and the only fails on the SENDING host are: >>>> 8 Bucket: 64, 0, 41, 3555, 257774, 11, >>>> 0 >>>> 12 Bucket: 96, 0, 96, 2569, 123653, 0, >>>> 0 >>>> 16 Bucket: 128, 0, 17195, 506, 215573, 0, >>>> 0 >>>> 32 Bucket: 256, 0, 340, 4670, 900638, 50, >>>> 0 >>>> 64 Bucket: 512, 0, 10691, 365, >>>> 546888,185232, 0 >>>> 128 Bucket: 1024, 0, 3563, 905, 348419, 0, >>>> 0 >>>> 256 Bucket: 2048, 0, 2872, 162, >>>> 249995,59834, 0 >>>> vmem btag: 56, 0, 192811, 51500, 502264,1723, >>>> 0 >>>> >>>> >>> >>> I regularly use zxfer to transfer 500+ GiB datasets over the >>> internet. >>> This week I actually replicated a 2.1 TiB dataset with zxfer without >>> issue. >>> >>> I wonder which thing is running out of memory. Is there a delay while >>> it >>> is 'running out of memory', or does it fail immediately? Does running >>> top while it is working on running out of memory reveal anything? >>> >>> I would expect to use up a lot of memory while doing deduplication, >>> but >>> not otherwise. >>> >>> Note: I most often use openssh-portable rather than base ssh for >>> replication, as I enable the nonecipher to reduce CPU usage, and >>> adjust >>> the TcpRcvBuf upwards to actually saturate a gigabit over the >>> internet. >> >> I wasn't watching exactly what it was doing, but the sending box has >> 16G >> and 18G Swap and swap >> has NOT been touched. >> >> last pid: 74288; load averages: 4.70, 5.61, 5.91 up 1+03:14:18 >> 15:10:44 >> 115 processes: 3 running, 112 sleeping >> CPU: 0.6% user, 33.3% nice, 0.6% system, 0.1% interrupt, 65.4% idle >> Mem: 847M Active, 761M Inact, 14G Wired, 4616K Cache, 357M Free >> ARC: 12G Total, 6028M MFU, 5281M MRU, 3152K Anon, 120M Header, 688M >> Other >> Swap: 18G Total, 18G Free >> >> so I have zero idea where to go here. >> >> > > Most ZFS memory usage is 'wired' and so cannot be swapped, so lack of > swap activity isn't a good indicator. I would expect ZFS to give up ARC when it needed memory and couldn't get it.... I also am running Karl Denninger's Arc patch that makes the arc MUCH more responsive to freeing ARC when the system needs memory. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 00:46:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D601252A; Fri, 25 Jul 2014 00:46:50 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 80A662C16; Fri, 25 Jul 2014 00:46:50 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hKBZ04mW6z1BN; Fri, 25 Jul 2014 02:46:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1406249205; x=1408841206; bh=saE KP6W/ydxAlua2Y9xQH66Q4LNfRKZjXaDbEI/MHuA=; b=On38cpScwQG6cgFcImQ qu/g3y5PDRa4p1rDmWx8M2s+4RtB97sSY7XIiFxIGQUXAQKtvu+aKgZPQ02pFOqG oKc+B04m35hd9+dIAH6LG3FUN4UvzbxhddICPnvSnSKiYOEQ94PwXdSn4HHEgD7h Mh3nEbHjEolLSDPMSmNuGvWk= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id l2rf58skVqRZ; Fri, 25 Jul 2014 02:46:45 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Fri, 25 Jul 2014 02:46:44 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hKBYw1chnz1Kr; Fri, 25 Jul 2014 02:46:44 +0200 (CEST) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Fri, 25 Jul 2014 02:46:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Jul 2014 02:46:44 +0200 From: Mark Martinec To: Larry Rosenman Subject: Re: zfs send/recv: STILL invalid Backup Stream Organization: J. Stefan Institute In-Reply-To: References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:46:50 -0000 2014-07-25 01:36 Larry Rosenman wrote: > #!/bin/sh > DATE=`date "+%Y-%m-%d"` > #DATE2=2013-03-24 > #DATE2=`date -v "-1d" "+%Y-%m-%d"` > # snap the source > ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} > # zfs copy the source to here. > ssh root@tbh.lerctr.org "zfs send -v -R zroot@${DATE} | \ > ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH2\"" Btw, this double-ssh looks awkward, why not just: ssh root@tbh.lerctr.org "zfs send ..." | zfs recv ... or better yet: ssh root@tbh.lerctr.org "zfs send ..." | mbuffer -m 16M | zfs recv ... (The misc/mbuffer compensates for bursty zfs reads and writes. A note to myself: I should suggest to Allan to add mbuffer in a pipe as used in sysutils/zxfer, instead of patching zxfer for our local use :) Mark From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 00:56:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E52B4761 for ; Fri, 25 Jul 2014 00:56:07 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id A5CA02CC5 for ; Fri, 25 Jul 2014 00:56:07 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 605482CCED for ; Fri, 25 Jul 2014 00:56:06 +0000 (UTC) Message-ID: <53D1AB3D.1060205@freebsd.org> Date: Thu, 24 Jul 2014 20:56:29 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zfs send/recv: STILL invalid Backup Stream References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W6c0Q6Vkipw36nWHsmIo2Tanq3SbPfTVI" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:56:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W6c0Q6Vkipw36nWHsmIo2Tanq3SbPfTVI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-24 20:46, Mark Martinec wrote: > 2014-07-25 01:36 Larry Rosenman wrote: >=20 >> #!/bin/sh >> DATE=3D`date "+%Y-%m-%d"` >> #DATE2=3D2013-03-24 >> #DATE2=3D`date -v "-1d" "+%Y-%m-%d"` >> # snap the source >> ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} >> # zfs copy the source to here. >> ssh root@tbh.lerctr.org "zfs send -v -R zroot@${DATE} | \ >> ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH2\"" >=20 > Btw, this double-ssh looks awkward, why not just: >=20 > ssh root@tbh.lerctr.org "zfs send ..." | zfs recv ... >=20 > or better yet: >=20 > ssh root@tbh.lerctr.org "zfs send ..." | mbuffer -m 16M | zfs recv ..= =2E >=20 > (The misc/mbuffer compensates for bursty zfs reads and writes. > A note to myself: I should suggest to Allan to add mbuffer > in a pipe as used in sysutils/zxfer, instead of patching zxfer > for our local use :) >=20 > Mark > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" zxfer can already do this, with the -D option I actually use misc/clpbar and get a progress bar as well -D 'bar -s %%size%% -bl 1m -bs 128m' or in your case: -D 'mbuffer -m 16M' --=20 Allan Jude --W6c0Q6Vkipw36nWHsmIo2Tanq3SbPfTVI 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0atAAAoJEJrBFpNRJZKfB5IP/2HV/y+hjqtkB+lLCXPQVazM xLJAlMUMB+TbyLLbmJyHYjRiAa3U5Z6P+s99Zk7qxiseDNc6VsJHQh1Y4XP3paQ/ 6qR+uGuoGei7Q+nws9I143cwtghsU5HPiR7toq/9zYHy490D/0sZy/HhNq5lgflN pOmQRowCyWbTY0I2urjuw4CBbWnYZphIxpvZNZ85ELqxZxpSO9NeDzsJVEsCaaCi 2qhaFn40TIQlO2kRoa3J/brzJwUY+DOuAO4qoEC6A9dHW+6ZfIVNW5XSkDVSKhu3 IviYf7RIi8V6D138EnXDw6Nqw4eZ42q6cHD2aO2m50y3PqQ8AAqQLqiOclii001I rycnj6dclOmBMFS1Wfh6zPRwHb+N3p+M+m1PMJJ+bkwvYl+3xsoMm+mYojTsIyLE LwHJP8wZa8j8xtpZPREOzMyOggpB2pZGVhkoWhkgwfyGhhX176hjTIblu0a/sh/z vmR8qbfETrfgbe1wO6O903tVSU4drCKd69fQ1LJ9AYwmI6iE4fTW8okH0F5cZTm4 XcAky4IAA1/IPh4hMqVDR+k1kla05q3K22l5WJOf7FUZ7bea+4OrMvYIXqoh5ctS 3IoDgTyxEpGi5z2C/htRi/lCmaErArUvz9Dho4SYFtDqUE5yMWvb3s++8y8hg6mc vRXtHRF7mUePxjf1aemO =ZzW5 -----END PGP SIGNATURE----- --W6c0Q6Vkipw36nWHsmIo2Tanq3SbPfTVI-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 03:42:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B408CB11; Fri, 25 Jul 2014 03:42:04 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D1E82B00; Fri, 25 Jul 2014 03:42:04 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 1471365D; Thu, 24 Jul 2014 20:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1406259724; bh=RFXkQFhwYGC630bSR4OUCowUxREFPMuNLY35uLH6GsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SDLNisqdmHd3/2vp5BzDirAqv53BvrTZg6VW9rD90b1eEPXikyAAUHDUK7JWlGO9Y Tzu4w32R1/AzHhnxWQ7Jgayr2OxPXh4WMd52U/Mxd0TWhUumYcPCAh93HUlI9LIqou VWy/zRD9TCTlUWRCA3vzETKkU9aJ2AUsKVw1y+fI= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Date: Thu, 24 Jul 2014 20:41:59 -0700 Message-ID: <13225341.zrHnT6Xi7E@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> <53D01DDD.8000806@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1803975.B8PWlyEuu6"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: "Bjoern A. Zeeb" , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 03:42:04 -0000 --nextPart1803975.B8PWlyEuu6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Wednesday 23 July 2014 20:59:19 Bjoern A. Zeeb wrote: > On 23 Jul 2014, at 20:41 , Allan Jude wrote: > > On 2014-07-23 16:38, Bjoern A. Zeeb wrote: > >> On 23 Jul 2014, at 15:42 , Cy Schubert = wrote: > >>> Taking this discussion slightly sideways but touching on this thr= ead a > >>> little, each of our packet filters will need nat66 support too. P= f > >>> doesn't > >>> support it for sure. I've been told that ipfw may and I suspect i= pfilter > >>> doesn't as it was on Darren's todo list from 2009. > >>=20 > >> our pf does support IPv6 prefix rewriting quite nicely and has for= years. > >=20 > > Bjoern: What IPv6 stuff does our pf not do well? >=20 > I think the most pressing, as Peter said, is fragment handling, thoug= h a > good fraction of major content providers seems to do mss clamping to = a min > IPv6 mtu on IPv6 and drop fragments at the edge (not much different t= o > IPv4, which makes you wonder?). Whoever is clever will think of ho= w many > different queueing and fragment handling implementations we need in t= he > kernel, and how often we have to do it on an end node that might also= run a > firewall, pick one we have, turn it into a library thing, apply it t= o all > places, and then add the latest IETF suggestions on top of it. Correct. There is code in the openbsd cvs history where they added it while the=20= internal APIs looked similar enough to ours. It's simpler than ipv4=20= reassembly - taking advantage of things like overlapping fragments not = being=20 allowed. I'm almost desperate enough to take a shot at it myself, but mbufs and = I do=20 not get along. Nobody wants code I've touched to be in the tree if mbu= fs are=20 involved. The initial commits.. first the supporting changes: (refactor code for reuse) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff= ?r1=3D1.128&r2=3D1.129 (add ipv6 defrag/refrag) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff= ?r1=3D1.129&r2=3D1.130 Then they added the code to defragment/refragment: (pf_test6 defrag/refrag) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=3D= 1.729&r2=3D1.730 The catch is that they fixed a lot of edge cases so one needs to follow= the=20 history forward a bit to make sure it it's covered. The other problem = is our=20 codebase is even older than when this was added so some looking at olde= r=20 commits is required. In the time since the feature was added, they have refactored it a few = times=20 and merged the two code paths for ipv4 and ipv6. It bears no resemblan= ce to=20 what we have in our tree. The killer reason why this is a problem that needs to be solved.. IPv6 = +=20 DNSSEC exercises this code a lot. Performance isn't a factor - it's basic functionality that's at stake. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart1803975.B8PWlyEuu6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJT0dILAAoJEDXWlwnsgJ4EAHQH/iMghRDgsUtmVXFbDXbq7hK/ U2DMMFOp61HYHNgDLDfPpXnTfF8iC6T0yqndLk0n9V8Lxxf+Vwfb2Q8sEBeoIWRb t7fy6Au9DXB/4zCvm+Ux2m7f2p0pfSkUVVps2J55y8tcxXeYFjT5ngHdGIlHFd7s vSOsLfRpwYiMat17S/9GJCNxjYMQvrFSRo+2PNye3MYTTcqnICun92RshTGHWXvr oGhEdBp0h9FHTj2lB0x5jHhoBzZxZM0GzYZPno/FjBfSG/s70+cOxvvzWTmB6W4j swDMSthmxzq1Rc0Bp6N0HQb3In0K/UAprvho99rn4d1ow9DfEw8rfn5xjUKq8KM= =+cIU -----END PGP SIGNATURE----- --nextPart1803975.B8PWlyEuu6-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 04:43:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0E9FA3A; Fri, 25 Jul 2014 04:43:17 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 978732FD7; Fri, 25 Jul 2014 04:43:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Ie+AdQPg5R1l/u9a7a+Pxk+x7qwupq/UOFfWXLW5iZI=; b=Xx7CAFPA3VJCpY45vOlypNGfQRkQp8CkgofxoWDHQvjVEsHjIu79PQw2l/564cSq4j6V9+q3a7UfA5XX4a49bm9d2uXv/a4PeYc7BnRIyHi52nbpP/cdQ/iAW+fKRi+Zb3No4ISe6YRp71SwNkhnwXO10w7MYqiPwndKZv2yrtM=; Received: from localhost.lerctr.org ([127.0.0.1]:10110 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAXLa-000PSa-Qu; Thu, 24 Jul 2014 23:43:14 -0500 Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 23:43:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 23:43:10 -0500 From: Larry Rosenman To: Allan Jude , Mark Martinec Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <53D1AB3D.1060205@freebsd.org> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> <53D1AB3D.1060205@freebsd.org> Message-ID: <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:43:18 -0000 On 2014-07-24 19:56, Allan Jude wrote: > On 2014-07-24 20:46, Mark Martinec wrote: >> 2014-07-25 01:36 Larry Rosenman wrote: >> >>> #!/bin/sh >>> DATE=`date "+%Y-%m-%d"` >>> #DATE2=2013-03-24 >>> #DATE2=`date -v "-1d" "+%Y-%m-%d"` >>> # snap the source >>> ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} >>> # zfs copy the source to here. >>> ssh root@tbh.lerctr.org "zfs send -v -R zroot@${DATE} | \ >>> ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH2\"" >> >> Btw, this double-ssh looks awkward, why not just: >> >> ssh root@tbh.lerctr.org "zfs send ..." | zfs recv ... >> >> or better yet: >> >> ssh root@tbh.lerctr.org "zfs send ..." | mbuffer -m 16M | zfs recv >> ... >> >> (The misc/mbuffer compensates for bursty zfs reads and writes. >> A note to myself: I should suggest to Allan to add mbuffer >> in a pipe as used in sysutils/zxfer, instead of patching zxfer >> for our local use :) >> >> Mark >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > zxfer can already do this, with the -D option > I actually use misc/clpbar and get a progress bar as well > > -D 'bar -s %%size%% -bl 1m -bs 128m' > > or in your case: -D 'mbuffer -m 16M' Ok, I did the mbuffer trick, and the SEND side is where the memory issue is: borg.lerctr.org /home/ler/bin $ tail zfs-send.log 23:28:12 15.7G zroot/home@2014-07-24_22:56 23:28:13 15.7G zroot/home@2014-07-24_22:56 23:28:14 15.7G zroot/home@2014-07-24_22:56 23:28:15 15.7G zroot/home@2014-07-24_22:56 23:28:16 15.7G zroot/home@2014-07-24_22:56 23:28:17 15.7G zroot/home@2014-07-24_22:56 23:28:18 15.7G zroot/home@2014-07-24_22:56 23:28:19 15.7G zroot/home@2014-07-24_22:56 23:28:20 15.8G zroot/home@2014-07-24_22:56 Write failed: Cannot allocate memory borg.lerctr.org /home/ler/bin $ borg.lerctr.org /home/ler/bin $ tail zfs-recv.log cannot receive new filesystem stream: invalid backup stream borg.lerctr.org /home/ler/bin $ borg.lerctr.org /home/ler/bin $ cat backup-TBH-ZFS-initial.sh #!/bin/sh DATE=`date "+%Y-%m-%d_%H:%M"` #DATE2=2013-03-24 #DATE2=`date -v "-1d" "+%Y-%m-%d"` # snap the source ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} # zfs copy the source to here. ssh root@tbh.lerctr.org 2>zfs-send.log "zfs send -v -R zroot@${DATE} " | \ mbuffer -m 16M 2>mbuffer.log | \ zfs recv -F -u -v -d zroot/backups/TBH3 2>zfs-recv.log # make sure we NEVER allow the backup stuff to automount. /sbin/zfs list -H -t filesystem -r zroot/backups/TBH3| \ awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh borg.lerctr.org /home/ler/bin $ borg.lerctr.org /home/ler/bin $ ssh tbh vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 202, 8, 202, 0, 0 UMA Zones: 1664, 0, 202, 0, 202, 0, 0 UMA Slabs: 80, 0, 363320, 44080, 2348572, 0, 0 UMA RCntSlabs: 88, 0, 4484, 16, 4484, 0, 0 UMA Hash: 256, 0, 7, 83, 82, 0, 0 4 Bucket: 32, 0, 1911, 36589, 5255345, 0, 0 6 Bucket: 48, 0, 9406, 3542, 878903, 0, 0 8 Bucket: 64, 0, 42, 3554, 298443, 11, 0 12 Bucket: 96, 0, 93, 2572, 166067, 0, 0 16 Bucket: 128, 0, 30447, 987, 301403, 0, 0 32 Bucket: 256, 0, 352, 4658, 1157489, 50, 0 64 Bucket: 512, 0, 13669, 995, 1113780,268080, 0 128 Bucket: 1024, 0, 3646, 822, 524977, 0, 0 256 Bucket: 2048, 0, 3648, 114, 482627,59834, 0 vmem btag: 56, 0, 208448, 49779, 758362,1821, 0 VM OBJECT: 256, 0, 98960, 1570, 4440323, 0, 0 RADIX NODE: 144, 0, 235166, 29650,22669417, 0, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 10, 269, 10, 0, 0 MAP ENTRY: 128, 0, 11828, 24442,12463199, 0, 0 VMSPACE: 448, 0, 103, 311, 96786, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 368, 0, 368, 0, 0 16: 16, 0, 264961, 9382,56032463, 0, 0 32: 32, 0, 155626, 2874,55177821, 0, 0 64: 64, 0, 123597, 672111,53838666, 0, 0 128: 128, 0, 159107, 58792,82084329, 0, 0 256: 256, 0, 97004, 223276,48661927, 0, 0 512: 512, 0, 737, 3991,33323191, 0, 0 1024: 1024, 0, 1367, 1389, 2330023, 0, 0 2048: 2048, 0, 271, 449,16353342, 0, 0 4096: 4096, 0, 28044, 27448, 997566, 0, 0 SLEEPQUEUE: 80, 0, 613, 658, 613, 0, 0 64 pcpu: 8, 0, 1884, 1188, 1884, 0, 0 Files: 80, 0, 861, 1639, 5410116, 0, 0 rl_entry: 40, 0, 211, 1889, 211, 0, 0 TURNSTILE: 136, 0, 613, 307, 613, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 138, 114, 97778, 0, 0 THREAD: 1168, 0, 517, 95, 2429, 0, 0 cpuset: 72, 0, 270, 280, 426, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 6519810, 4080, 3257, 9746764, 0, 0 mbuf: 256, 6519810, 1025, 3278,259201769, 0, 0 mbuf_cluster: 2048, 1018718, 7337, 13, 7337, 0, 0 mbuf_jumbo_page: 4096, 509359, 0, 809,45525783, 0, 0 mbuf_jumbo_9k: 9216, 150921, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 84893, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 2510, 116647, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 0, 1680,48127406, 0, 0 ttyinq: 160, 0, 120, 630, 2460, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 ttyoutq: 256, 0, 64, 671, 1279, 0, 0 ata_request: 336, 0, 0, 242, 42892, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 3071, 250215, 0, 0 taskq_zone: 48, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 113296, 62392, 2709794, 0, 0 VNODEPOLL: 112, 0, 355, 660, 357, 0, 0 BUF TRIE: 144, 0, 0, 105354, 0, 0, 0 S VFS Cache: 108, 0, 118644, 56881, 2428046, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 1110, 144894, 804385, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 172,30294048, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 0, 0, 0, 0, 0 Mountpoints: 816, 0, 11, 19, 11, 0, 0 range_seg_cache: 64, 0, 59688, 6094, 4438296, 0, 0 zio_cache: 920, 0, 1, 42591,138793685, 0, 0 zio_link_cache: 48, 0, 0, 44073,97697152, 0, 0 zio_buf_512: 512, 0, 411934, 265850, 1785999, 0, 0 zio_data_buf_512: 512, 0, 154726, 20594, 797483, 0, 0 zio_buf_1024: 1024, 0, 3061, 175, 74166, 0, 0 zio_data_buf_1024: 1024, 0, 69831, 9029, 333451, 0, 0 zio_buf_1536: 1536, 0, 1372, 96, 93985, 0, 0 zio_data_buf_1536: 1536, 0, 29821, 3103, 190819, 0, 0 zio_buf_2048: 2048, 0, 523, 47, 281620, 0, 0 zio_data_buf_2048: 2048, 0, 17707, 2389, 128398, 0, 0 zio_buf_2560: 2560, 0, 390, 28, 22269, 0, 0 zio_data_buf_2560: 2560, 0, 12713, 28, 108546, 0, 0 zio_buf_3072: 3072, 0, 182, 22, 7255, 0, 0 zio_data_buf_3072: 3072, 0, 8798, 34, 79372, 0, 0 zio_buf_3584: 3584, 0, 206, 11, 50516, 0, 0 zio_data_buf_3584: 3584, 0, 6275, 11, 64145, 0, 0 zio_buf_4096: 4096, 0, 1552, 416,18817937, 0, 0 zio_data_buf_4096: 4096, 0, 4625, 6, 59910, 0, 0 zio_buf_5120: 5120, 0, 133, 9, 8048, 0, 0 zio_data_buf_5120: 5120, 0, 6326, 11, 77387, 0, 0 zio_buf_6144: 6144, 0, 86, 11, 4503, 0, 0 zio_data_buf_6144: 6144, 0, 4632, 13, 58064, 0, 0 zio_buf_7168: 7168, 0, 61, 13, 48012, 0, 0 zio_data_buf_7168: 7168, 0, 3090, 13, 44010, 0, 0 zio_buf_8192: 8192, 0, 24, 29, 1857848, 0, 0 zio_data_buf_8192: 8192, 0, 2418, 11, 42210, 0, 0 zio_buf_10240: 10240, 0, 49, 7, 3311, 0, 0 zio_data_buf_10240: 10240, 0, 3611, 15, 59310, 0, 0 zio_buf_12288: 12288, 0, 44, 14, 999494, 0, 0 zio_data_buf_12288: 12288, 0, 2340, 13, 53847, 0, 0 zio_buf_14336: 14336, 0, 23, 10, 4184, 0, 0 zio_data_buf_14336: 14336, 0, 1852, 15, 36058, 0, 0 zio_buf_16384: 16384, 0, 72595, 164, 3891311, 0, 0 zio_data_buf_16384: 16384, 0, 1707, 11, 33236, 0, 0 zio_buf_20480: 20480, 0, 201, 261, 832993, 0, 0 zio_data_buf_20480: 20480, 0, 1932, 12, 43873, 0, 0 zio_buf_24576: 24576, 0, 16, 11, 365481, 0, 0 zio_data_buf_24576: 24576, 0, 1852, 13, 31773, 0, 0 zio_buf_28672: 28672, 0, 9, 25, 731759, 0, 0 zio_data_buf_28672: 28672, 0, 1169, 10, 27692, 0, 0 zio_buf_32768: 32768, 0, 9, 14, 112680, 0, 0 zio_data_buf_32768: 32768, 0, 962, 13, 20775, 0, 0 zio_buf_36864: 36864, 0, 5, 14, 112387, 0, 0 zio_data_buf_36864: 36864, 0, 701, 13, 15139, 0, 0 zio_buf_40960: 40960, 0, 4, 11, 115602, 0, 0 zio_data_buf_40960: 40960, 0, 720, 10, 12360, 0, 0 zio_buf_45056: 45056, 0, 48, 12, 102919, 0, 0 zio_data_buf_45056: 45056, 0, 434, 14, 10533, 0, 0 zio_buf_49152: 49152, 0, 188, 12, 113099, 0, 0 zio_data_buf_49152: 49152, 0, 373, 10, 11797, 0, 0 zio_buf_53248: 53248, 0, 24, 13, 157215, 0, 0 zio_data_buf_53248: 53248, 0, 347, 15, 7265, 0, 0 zio_buf_57344: 57344, 0, 1, 11, 154125, 0, 0 zio_data_buf_57344: 57344, 0, 274, 14, 7110, 0, 0 zio_buf_61440: 61440, 0, 2, 10, 163599, 0, 0 zio_data_buf_61440: 61440, 0, 180, 11, 5565, 0, 0 zio_buf_65536: 65536, 0, 1, 11, 186705, 0, 0 zio_data_buf_65536: 65536, 0, 213, 11, 7273, 0, 0 zio_buf_69632: 69632, 0, 2, 14, 145850, 0, 0 zio_data_buf_69632: 69632, 0, 176, 8, 5232, 0, 0 zio_buf_73728: 73728, 0, 1, 13, 136031, 0, 0 zio_data_buf_73728: 73728, 0, 127, 12, 4816, 0, 0 zio_buf_77824: 77824, 0, 1, 22, 162862, 0, 0 zio_data_buf_77824: 77824, 0, 136, 14, 4207, 0, 0 zio_buf_81920: 81920, 0, 0, 149, 195810, 0, 0 zio_data_buf_81920: 81920, 0, 99, 15, 4936, 0, 0 zio_buf_86016: 86016, 0, 1, 216, 150971, 0, 0 zio_data_buf_86016: 86016, 0, 103, 14, 33989, 0, 0 zio_buf_90112: 90112, 0, 1, 120, 75823, 0, 0 zio_data_buf_90112: 90112, 0, 145, 11, 3517, 0, 0 zio_buf_94208: 94208, 0, 0, 20, 72296, 0, 0 zio_data_buf_94208: 94208, 0, 149, 11, 3315, 0, 0 zio_buf_98304: 98304, 0, 0, 19, 68257, 0, 0 zio_data_buf_98304: 98304, 0, 79, 11, 4092, 0, 0 zio_buf_102400: 102400, 0, 1, 19, 62463, 0, 0 zio_data_buf_102400: 102400, 0, 92, 12, 2940, 0, 0 zio_buf_106496: 106496, 0, 0, 15, 203444, 0, 0 zio_data_buf_106496: 106496, 0, 62, 14, 2869, 0, 0 zio_buf_110592: 110592, 0, 0, 10, 184072, 0, 0 zio_data_buf_110592: 110592, 0, 152, 12, 2463, 0, 0 zio_buf_114688: 114688, 0, 1, 12, 65538, 0, 0 zio_data_buf_114688: 114688, 0, 115, 15, 3609, 0, 0 zio_buf_118784: 118784, 0, 0, 13, 73524, 0, 0 zio_data_buf_118784: 118784, 0, 57, 12, 2092, 0, 0 zio_buf_122880: 122880, 0, 0, 23, 101816, 0, 0 zio_data_buf_122880: 122880, 0, 46, 15, 2131, 0, 0 zio_buf_126976: 126976, 0, 0, 13, 99774, 0, 0 zio_data_buf_126976: 126976, 0, 46, 15, 1927, 0, 0 zio_buf_131072: 131072, 0, 21, 97, 715685, 0, 0 zio_data_buf_131072: 131072, 0, 64623, 8, 1133068, 0, 0 lz4_ctx: 16384, 0, 0, 38, 2874956, 0, 0 sa_cache: 80, 0, 113220, 62680, 2719738, 0, 0 dnode_t: 744, 0, 369347, 391598, 903612, 0, 0 dmu_buf_impl_t: 224, 0, 459185, 519692, 3494852, 0, 0 arc_buf_hdr_t: 216, 0, 697777, 122573, 4738762, 0, 0 arc_buf_t: 72, 0, 541440, 121695, 5738782, 0, 0 zil_lwb_cache: 192, 0, 7, 5073, 90526, 0, 0 zfs_znode_cache: 368, 0, 113220, 62340, 2709584, 0, 0 pipe: 744, 0, 113, 177, 84427, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 1133, 2507,10649838, 0, 0 itimer: 352, 0, 1, 32, 1, 0, 0 KNOTE: 128, 0, 379, 1388,26313314, 0, 0 socket: 696, 523340, 243, 317, 827216, 0, 0 unpcb: 240, 523344, 152, 648, 171731, 0, 0 ipq: 56, 31879, 0, 2059, 385, 0, 0 udp_inpcb: 392, 523340, 19, 421, 567701, 0, 0 udpcb: 16, 523586, 19, 2993, 567701, 0, 0 tcp_inpcb: 392, 523340, 73, 457, 87773, 0, 0 tcpcb: 1024, 523340, 67, 245, 87773, 0, 0 tcptw: 88, 27810, 6, 1254, 29354, 0, 0 syncache: 160, 15375, 0, 800, 57377, 0, 0 hostcache: 136, 15370, 134, 620, 4951, 0, 0 tcpreass: 40, 63700, 0, 3100, 13421, 0, 0 sackhole: 32, 0, 0, 2125, 18903, 0, 0 sctp_ep: 1408, 523340, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 1328, 8, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400000, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 392, 523340, 0, 0, 0, 0, 0 ripcb: 392, 523340, 2, 58, 3, 0, 0 rtentry: 200, 0, 32, 408, 34, 0, 0 selfd: 56, 0, 356, 2200,137062686, 0, 0 SWAPMETA: 288, 2037438, 0, 0, 0, 0, 0 borg.lerctr.org /home/ler/bin $ last pid: 97813; load averages: 7.79, 8.41, 8.24 up 1+11:45:45 23:42:11 118 processes: 7 running, 109 sleeping, 2 stopped Mem: 982M Active, 1172M Inact, 13G Wired, 148M Cache, 637M Free ARC: 11G Total, 4394M MFU, 5813M MRU, 1029K Anon, 181M Header, 469M Other Swap: 18G Total, 18G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 97782 boinc 1 155 i31 91992K 26008K CPU1 1 0:40 100.00% wcgrid_f 96977 boinc 1 155 i31 375M 165M STOP 4 11:30 61.87% wcgrid_c 89981 boinc 1 155 i31 99308K 63248K CPU5 5 91:25 51.76% wcgrid_f 92270 boinc 1 155 i31 98M 64556K CPU3 3 62:55 50.88% wcgrid_f 92269 boinc 1 155 i31 99372K 63324K CPU4 4 63:49 50.20% wcgrid_f 92271 boinc 1 155 i31 99340K 63288K CPU0 0 64:00 48.19% wcgrid_f 89772 boinc 1 155 i31 99888K 63832K CPU7 7 92:52 41.36% wcgrid_f 89781 boinc 1 155 i31 99732K 63588K nanslp 5 94:54 38.18% wcgrid_f 85619 root 1 52 0 181M 97232K select 3 2:56 21.19% perl5 97806 root 1 28 0 44600K 8028K kqread 0 0:00 0.78% indexer- 837 clamav 3 20 0 486M 399M uwait 5 12:42 0.20% clamd 70563 boinc 2 155 i31 101M 51436K nanslp 7 202:02 0.00% setiatho 68437 boinc 2 155 i31 105M 52516K nanslp 3 185:45 0.00% setiatho 83114 boinc 2 155 i31 105M 51880K nanslp 4 103:15 0.00% setiatho 85300 boinc 2 155 i31 101M 51460K nanslp 4 78:55 0.00% setiatho 86148 boinc 2 155 i31 105M 51492K nanslp 3 71:54 0.00% setiatho 87150 boinc 2 155 i31 95112K 46940K nanslp 4 30:37 0.00% setiatho 87451 boinc 2 155 i31 95112K 46224K nanslp 3 28:07 0.00% setiatho borg.lerctr.org /home/ler/bin $ Where to now? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 05:36:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29F3E71D for ; Fri, 25 Jul 2014 05:36:03 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 A6F3623D9 for ; Fri, 25 Jul 2014 05:36:02 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id f8so498760wiw.3 for ; Thu, 24 Jul 2014 22:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=bkbQxfc3gVtOZrFiksPaNFWF08Bc5rwN+R/7Fl4hPsI=; b=n6myKJ4TMRAzSI5Jz8nzP7N6NBCYbXvQ5Ek5uo5Yu18gk+KYylx2IjCosbgYLk+2is DxqGwvEJcCltYDBOcQwqueT7mpwuh2bs4GguMTIvK01wvFjIBvG607NVKDFpHQMIjIqV fpRMF46D93n3NjkG9eest9uuIISsLbuVrhQ77cxQ60Mq5OTn6AGa3ZX5Mt1ne2aiR2XE vYB4dkDVe5SBVbXIY0Sc+yC+A9RlOxXUBpbP5vtV0b2SDKckM+cyUf7yv7YXIO6s/Dz3 gRo0I99OLNUnzWk2HOKnmIckOwyimuMk1OPaudUB4J+Yj3DHPdo2kQJlvr8+WUSXab7h F36A== X-Received: by 10.180.87.199 with SMTP id ba7mr1840534wib.49.1406266560815; Thu, 24 Jul 2014 22:36:00 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id fw4sm1472427wib.19.2014.07.24.22.35.58 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 24 Jul 2014 22:35:59 -0700 (PDT) Date: Fri, 25 Jul 2014 08:36:07 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Subject: Re: r268621: panic: shadowed tmpfs v_object [with dump] Message-ID: <20140725083607.4d943e63@laptop.minsk.domain> In-Reply-To: <53D0218E.3080204@gmail.com> References: <53CED27C.4080306@FreeBSD.org> <53CED29F.1090809@FreeBSD.org> <53CED718.2090108@FreeBSD.org> <53CEDD74.9070804@FreeBSD.org> <20140723141122.GG93733@kib.kiev.ua> <53CFDF0B.1080904@FreeBSD.org> <53D0218E.3080204@gmail.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mattia.rossi.mate@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 05:36:03 -0000 On Wed, 23 Jul 2014 22:56:46 +0200 Mattia Rossi wrote: > Got the same panic, is this fix getting committed? Or has it already > been committed? r269053 > > Mat > > On 23/07/14 18:12, Bryan Drewery wrote: > > On 7/23/14, 7:11 AM, Konstantin Belousov wrote: > >> On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote: > >>> On 7/22/14, 2:26 PM, Bryan Drewery wrote: > >>>> On 7/22/14, 2:07 PM, Bryan Drewery wrote: > >>>>> Meant to send to current@, moving there. > >>>>> > >>>>> On 7/22/14, 2:07 PM, Bryan Drewery wrote: > >>>>>> On r268621: > >>>>>> > >>>>>>> panic: shadowed tmpfs v_object 0xfffff807a7f96600 > >>>>>>> cpuid = 0 > >>>>>>> KDB: stack backtrace: > >>>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >>>>>>> 0xfffffe1247d67390 > >>>>>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 > >>>>>>> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 > >>>>>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 > >>>>>>> vm_object_deallocate() at vm_object_deallocate+0x236/frame > >>>>>>> 0xfffffe1247d67550 > >>>>>>> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 > >>>>>>> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 > >>>>>>> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 > >>>>>>> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 > >>>>>>> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 > >>>>>>> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 > >>>>>>> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame > >>>>>>> 0xfffffe1247d676e0 > >>>>>>> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 > >>>>>>> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 > >>>>>>> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 > >>>>>>> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 > >>>>>>> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 > >>>>>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 > >>>>>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 > >>>>>>> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, > >>>>>>> rsp = > >>>>>>> 0x7fffffffe238, rbp = 0x7fffffffe710 --- > >>>>>>> Uptime: 6d4h0m3s > >>>>>>> > >>>>>>> Dump failed. Partition too small. > >>>>>> > >>>>>> Unfortunately I have no dump to debug. > >>>>>> > >>>>> > >>>> Running poudriere again after boot hit the issue right away: > >>>> > >>>> > >>>>> (kgdb) bt > >>>>> #0 doadump (textdump=1) at pcpu.h:219 > >>>>> #1 0xffffffff809122a7 in kern_reboot (howto=260) at > >>>>> /usr/src/sys/kern/kern_shutdown.c:445 > >>>>> #2 0xffffffff809127e5 in vpanic (fmt=, > >>>>> ap= >>>>> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744 > >>>>> #3 0xffffffff80912679 in kassert_panic (fmt= >>>>> out>) at > >>>>> /usr/src/sys/kern/kern_shutdown.c:632 > >>>>> #4 0xffffffff80ba7996 in vm_object_deallocate (object= >>>>> optimized out>) at /usr/src/sys/vm/vm_object.c:562 > >>>>> #5 0xffffffff820a75a8 in tmpfs_free_node (tmp=0xfffff800b5155980, > >>>>> node=0xfffff802716ba740) at > >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335 > >>>>> #6 0xffffffff820a363d in tmpfs_reclaim (v=) at > >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276 > >>>>> #7 0xffffffff80e48717 in VOP_RECLAIM_APV (vop=, > >>>>> a=) at vnode_if.c:2017 > >>>>> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at > >>>>> vnode_if.h:830 > >>>>> #9 0xffffffff809c18be in vrecycle (vp=0xfffff802716b61d8) at > >>>>> /usr/src/sys/kern/vfs_subr.c:2655 > >>>>> #10 0xffffffff820a61cc in tmpfs_inactive (v=) at > >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242 > >>>>> #11 0xffffffff80e485b7 in VOP_INACTIVE_APV (vop= >>>>> out>, > >>>>> a=) at vnode_if.c:1951 > >>>>> #12 0xffffffff809bfd36 in vinactive (vp=0xfffff802716b61d8, > >>>>> td=0xfffff80187e29920) at vnode_if.h:807 > >>>>> #13 0xffffffff809c012a in vputx (vp=0xfffff802716b61d8, func=2) at > >>>>> /usr/src/sys/kern/vfs_subr.c:2267 > >>>>> #14 0xffffffff820a47c5 in tmpfs_rename (v=) at > >>>>> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023 > >>>>> #15 0xffffffff80e47d3c in VOP_RENAME_APV (vop=, > >>>>> a=) at vnode_if.c:1544 > >>>>> #16 0xffffffff809cc77f in kern_renameat (td=, > >>>>> oldfd=, old=, newfd= >>>>> optimized out>, new=, > >>>>> pathseg=) at vnode_if.h:636 > >>>>> #17 0xffffffff80d280fa in amd64_syscall (td=0xfffff80187e29920, > >>>>> traced=0) at subr_syscall.c:133 > >>>>> #18 0xffffffff80d0a64b in Xfast_syscall () at > >>>>> /usr/src/sys/amd64/amd64/exception.S:407 > >>>>> (kgdb) p *(vm_object_t)0xfffff8027169f500 > >>>>> $1 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm > >>>>> object", > >>>>> lo_flags = 90374144, lo_data = 0, lo_witness = 0xfffffe00006e7680}, > >>>>> rw_lock = 18446735284191271200}, object_list = { > >>>>> tqe_next = 0xfffff8027169f400, tqe_prev = 0xfffff8027169f620}, > >>>>> shadow_head = {lh_first = 0xfffff801b8489e00}, shadow_list = {le_next > >>>>> = 0x0, le_prev = 0x0}, memq = {tqh_first = 0xfffff811d966bc08, > >>>>> tqh_last = 0xfffff811d966bc18}, rtree = {rt_root = > >>>>> 18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1, > >>>>> ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001', > >>>>> flags = 528, pg_color = 0, paging_in_progress = 0, > >>>>> resident_page_count = 1, backing_object = 0x0, > >>>>> backing_object_offset = > >>>>> 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { > >>>>> lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, > >>>>> handle > >>>>> = 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp = > >>>>> {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, > >>>>> dev = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last = > >>>>> 0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0x0, > >>>>> charge = 0} > >>>>> (kgdb) frame 8 > >>>>> #8 0xffffffff809c1381 in vgonel (vp=0xfffff802716b61d8) at > >>>>> vnode_if.h:830 > >>>>> 830 return (VOP_RECLAIM_APV(vp->v_op, &a)); > >>>>> (kgdb) p *vp > >>>>> $2 = {v_tag = 0xffffffff820abf96 "tmpfs", v_op = 0xffffffff820ac938, > >>>>> v_data = 0x0, v_mount = 0xfffff8004733a000, v_nmntvnodes = > >>>>> {tqe_next = > >>>>> 0xfffff802716b6000, tqe_prev = 0xfffff802716b63d0}, v_un = { > >>>>> vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = > >>>>> 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = > >>>>> {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, > >>>>> tqh_last = 0xfffff802716b6228}, v_cache_dd = 0x0, v_lock = > >>>>> {lock_object = {lo_name = 0xffffffff820abf96 "tmpfs", lo_flags = > >>>>> 116588544, lo_data = 0, lo_witness = 0xfffffe0000711980}, > >>>>> lk_lock = 18446735284191271200, lk_exslpfail = 0, lk_timo = 51, > >>>>> lk_pri = 96}, v_interlock = {lock_object = {lo_name = > >>>>> 0xffffffff80fafc26 "vnode interlock", lo_flags = 16973824, lo_data > >>>>> = 0, > >>>>> lo_witness = 0xfffffe00006e7500}, mtx_lock = 4}, v_vnlock = > >>>>> 0xfffff802716b6240, v_actfreelist = {tqe_next = 0xfffff80271898588, > >>>>> tqe_prev = 0xfffff8004733a078}, v_bufobj = {bo_lock = { > >>>>> lock_object = {lo_name = 0xffffffff80fb8084 "bufobj > >>>>> interlock", > >>>>> lo_flags = 86179840, lo_data = 0, lo_witness = 0xfffffe00006ef380}, > >>>>> rw_lock = 1}, bo_ops = 0xffffffff814942a0, bo_object = 0x0, > >>>>> bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = > >>>>> 0xfffff802716b61d8, __bo_vnode = 0xfffff802716b61d8, bo_clean = > >>>>> {bv_hd > >>>>> = {tqh_first = 0x0, tqh_last = 0xfffff802716b62f8}, bv_root = { > >>>>> pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = > >>>>> 0x0, tqh_last = 0xfffff802716b6318}, bv_root = {pt_root = 0}, > >>>>> bv_cnt = > >>>>> 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 4096}, > >>>>> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = > >>>>> {rl_waiters = > >>>>> {tqh_first = 0x0, tqh_last = 0xfffff802716b6360}, rl_currdep = 0x0}, > >>>>> v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, > >>>>> v_holdcnt = 2, v_usecount = 0, v_iflag = 2688, v_vflag = 0, > >>>>> v_writecount = 0, v_hash = 40987489, v_type = VREG} > >>>>> (kgdb) info locals > >>>>> mp = (struct mount *) 0xfffff8004733a000 > >>>>> fromnd = {ni_dirp = 0x801006080
, > >>>>> ni_segflg = UIO_USERSPACE, ni_rightsneeded = {cr_rights = > >>>>> {144115188142965760, 288230376151711744}}, > >>>>> ni_startdir = 0xfffff802716b63b0, ni_rootdir = 0xfffff8026b01a760, > >>>>> ni_topdir = 0xfffff8026b01a760, ni_dirfd = -100, ni_strictrelative = > >>>>> 0, ni_filecaps = {fc_rights = {cr_rights = {0, 0}}, > >>>>> fc_ioctls = 0x0, fc_nioctls = -1, fc_fcntls = 0}, ni_vp = > >>>>> 0xfffff80271898588, ni_dvp = 0xfffff802716b63b0, ni_pathlen = 1, > >>>>> ni_next = 0xfffff80061ea501f "", ni_loopcnt = 0, ni_cnd = {cn_nameiop > >>>>> = 2, > >>>>> cn_flags = 67148812, cn_thread = 0xfffff80187e29920, cn_cred = > >>>>> 0xfffff80038911800, cn_lkflags = 524288, cn_pnbuf = > >>>>> 0xfffff80061ea5000 > >>>>> "/var/run/ld-elf.so.hints.HTjP6A", > >>>>> cn_nameptr = 0xfffff80061ea5009 "ld-elf.so.hints.HTjP6A", > >>>>> cn_namelen = 22, cn_consume = 0}} > >>>>> tond = {ni_dirp = 0x403e66
, > >>>>> ni_segflg > >>>>> = UIO_USERSPACE, ni_rightsneeded = {cr_rights = {144115188080051200, > >>>>> 288230376151711744}}, ni_startdir = 0xfffff802716b63b0, > >>>>> ni_rootdir = 0xfffff8026b01a760, ni_topdir = 0xfffff8026b01a760, > >>>>> ni_dirfd = -100, ni_strictrelative = 0, ni_filecaps = {fc_rights = > >>>>> {cr_rights = {0, 0}}, fc_ioctls = 0x0, fc_nioctls = -1, > >>>>> fc_fcntls = 0}, ni_vp = 0xfffff802716b61d8, ni_dvp = > >>>>> 0xfffff802716b63b0, ni_pathlen = 1, ni_next = 0xfffff80038d69418 "", > >>>>> ni_loopcnt = 0, ni_cnd = {cn_nameiop = 3, cn_flags = 134257708, > >>>>> cn_thread = 0xfffff80187e29920, cn_cred = 0xfffff80038911800, > >>>>> cn_lkflags = 524288, cn_pnbuf = 0xfffff80038d69400 > >>>>> "/var/run/ld-elf.so.hints", cn_nameptr = 0xfffff80038d69409 > >>>>> "ld-elf.so.hints", > >>>>> cn_namelen = 15, cn_consume = 0}} > >>>>> rights = {cr_rights = {144115188080051200, 288230376151711744}} > >>>>> mp = (struct mount *) 0xfffff8004733a000 > >>>>> error = > >>>>> fvp = > >>>>> tvp = > >>>>> tdvp = > >>>>> (kgdb) p *mp > >>>>> $9 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80f8fcec "struct > >>>>> mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = > >>>>> 0xfffffe00006e7a00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = { > >>>>> tqe_next = 0xfffff80038fa9cc0, tqe_prev = 0xfffff80187b74ce8}, > >>>>> mnt_op = 0xffffffff820ace60, mnt_vfc = 0xffffffff820acf80, > >>>>> mnt_vnodecovered = 0xfffff801b853e760, mnt_syncer = > >>>>> 0xfffff8026b01a588, > >>>>> mnt_ref = 13206, mnt_nvnodelist = {tqh_first = 0xfffff8026b01a760, > >>>>> tqh_last = 0xfffff802718985a8}, mnt_nvnodelistsize = 13205, > >>>>> mnt_activevnodelist = {tqh_first = 0xfffff802716b61d8, > >>>>> tqh_last = 0xfffff8026b01a648}, mnt_activevnodelistsize = 730, > >>>>> mnt_writeopcount = 1, mnt_kern_flag = 0, mnt_flag = 4096, mnt_opt = > >>>>> 0xfffff8000e59cc30, mnt_optnew = 0xfffff8001b9ea050, > >>>>> mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = > >>>>> 135, f_flags = 4096, f_bsize = 4096, f_iosize = 4096, f_blocks = > >>>>> 1835008, f_bfree = 1738991, f_bavail = 1738991, f_files = 25690112, > >>>>> f_ffree = 25676911, f_syncwrites = 0, f_asyncwrites = 0, > >>>>> f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, > >>>>> 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {-2029977843, > >>>>> 135}}, f_charspare = '\0' , f_fstypename = > >>>>> "tmpfs\000\000\000\000\000\000\000\000\000\000", f_mntfromname = > >>>>> "tmpfs", '\0' , > >>>>> f_mntonname = "/poudriere/data/.m/exp-10amd64-commit-test/01", > >>>>> '\0' }, mnt_cred = 0xfffff80047478700, mnt_data = > >>>>> 0xfffff800b5155980, mnt_time = 0, mnt_iosize_max = 65536, > >>>>> mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 1147308587, > >>>>> mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = > >>>>> 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = { > >>>>> lock_object = {lo_name = 0xffffffff80f8fd0f "explock", > >>>>> lo_flags = > >>>>> 108199936, lo_data = 0, lo_witness = 0xfffffe000070ef80}, lk_lock > >>>>> = 1, > >>>>> lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, > >>>>> mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers = > >>>>> {tqh_first = 0x0, tqh_last = 0xfffff8004733a320}} > >>>> > >>> > >>> Shadowed object: > >>> > >>>> (kgdb) p *$1->shadow_head->lh_first > >>>> $3 = {lock = {lock_object = {lo_name = 0xffffffff80fe89f6 "vm > >>>> object", lo_flags = 90374144, lo_data = 0, lo_witness = > >>>> 0xfffffe00006e7680}, rw_lock = 1}, object_list = {tqe_next = > >>>> 0xfffff801b8b3ae00, > >>>> tqe_prev = 0xfffff802717bb120}, shadow_head = {lh_first = > >>>> 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xfffff8027169f530}, > >>>> memq = {tqh_first = 0xfffff811da2c75f8, tqh_last = > >>>> 0xfffff811da2c7608}, > >>>> rtree = {rt_root = 18446735354291320313, rt_flags = 0 '\0'}, > >>>> size = 1, generation = 1, ref_count = 1, shadow_count = 0, memattr > >>>> = 6 '\006', type = 0 '\0', flags = 12288, pg_color = 1598, > >>>> paging_in_progress = 0, resident_page_count = 1, backing_object > >>>> = 0xfffff8027169f500, backing_object_offset = 0, pager_object_list > >>>> = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {lh_first = 0x0}, cache = { > >>>> rt_root = 0, rt_flags = 0 '\0'}, handle = 0x0, un_pager = {vnp > >>>> = {vnp_size = 0, writemappings = 0}, devp = {devp_pglist = > >>>> {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = { > >>>> sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = > >>>> {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0xfffff80038911800, > >>>> charge = 4096} > >>> > >> > >> Try this > >> > >> diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > >> index 1b97bdf..bb01f00 100644 > >> --- a/sys/vm/vm_object.c > >> +++ b/sys/vm/vm_object.c > >> @@ -559,8 +559,6 @@ vm_object_deallocate(vm_object_t object) > >> (object->handle == NULL) && > >> (object->type == OBJT_DEFAULT || > >> object->type == OBJT_SWAP)) { > >> - KASSERT((object->flags & OBJ_TMPFS_NODE) == 0, > >> - ("shadowed tmpfs v_object %p", object)); > >> vm_object_t robject; > >> > >> robject = LIST_FIRST(&object->shadow_head); > >> @@ -568,6 +566,8 @@ vm_object_deallocate(vm_object_t object) > >> ("vm_object_deallocate: ref_count: %d, > >> shadow_count: %d", > >> object->ref_count, > >> object->shadow_count)); > >> + KASSERT((robject->flags & OBJ_TMPFS_NODE) == 0, > >> + ("shadowed tmpfs v_object %p", object)); > >> if (!VM_OBJECT_TRYWLOCK(robject)) { > >> /* > >> * Avoid a potential deadlock. > >> @@ -637,6 +637,8 @@ retry: > >> doterm: > >> temp = object->backing_object; > >> if (temp != NULL) { > >> + KASSERT((object->flags & OBJ_TMPFS_NODE) == 0, > >> + ("shadowed tmpfs v_object 2 %p", object)); > >> VM_OBJECT_WLOCK(temp); > >> LIST_REMOVE(object, shadow_list); > >> temp->shadow_count--; > >> > > > > Yup this avoids the panic. > > > > Thanks! > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 05:56:30 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65A89AB8; Fri, 25 Jul 2014 05:56:30 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32328256A; Fri, 25 Jul 2014 05:56:30 +0000 (UTC) Received: from [157.181.98.237] ([157.181.98.237]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0M4nHf-1WIAno1PUz-00z1cA; Fri, 25 Jul 2014 07:51:17 +0200 Message-ID: <53D1F00F.7060301@gmx.com> Date: Fri, 25 Jul 2014 07:50:07 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Baptiste Daroussin , ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bt6LSGsDi2AUKtA4gcQcem+K1R0YUwUAjkNzT5ejivR0DAWjjS6 CTK2JtoPiLwU8wHjYbyzAGDXknlsZ2z0+SAv0EvRMZdrbzHhGC0rKtbaujs77Ggd9gbaPU0 KQzpaCXAd0UFHZt2iBPvBIZrhd+si0k3tRLT4kz//MZKYYcbx1ACpVmQR52nMD3WK0QHd/W ol69y60UIgYY1KxuyTRMA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 05:56:30 -0000 Baptiste Daroussin wrote, On 07/23/2014 16:42: > So much has happened that it is hard to summarize so I'll try to highlight the > major points: > - New solver, now pkg has a real SAT solver able to automatically handle > conflicts and dynamically discover them. (yes pkg set -o is deprecated now) Does pkg/Pkg/PKG/pkgng/PkgNg/PKGNG/whatever now downgrade/revert packages when removing an alternative repository, such as FreeBSD_new_xorg? (Previously, it didn't: I was required to manually remove and (re)install all X11-related packages.) From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 06:56:45 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEB99BED; Fri, 25 Jul 2014 06:56:45 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 185C12B6C; Fri, 25 Jul 2014 06:56:45 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 0B69EB84D; Fri, 25 Jul 2014 08:56:42 +0200 (SAST) Date: Fri, 25 Jul 2014 08:56:41 +0200 From: John Hay To: Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140725065641.GA88239@zibbi.meraka.csir.co.za> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 06:56:46 -0000 On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: > Hi all, > > I'm very please to announce the release of pkg 1.3.0 > This version is the result of almost 9 month of hard work > ... > Thank you to all contributors: > Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, > Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie > Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, > Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, > Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, > Vsevolod Stakhov, Xin Li, coctic > > Regards, > Bapt on behalf of the pkg@ Version 1.3 does better on armeb. It does not crash while installing itself, but still complains and get the architecture wrong: ################ root@cambria-build:/usr/ports/ports-mgmt/pkg # make install ===> Installing for pkg-1.3.0 ===> Checking if ports-mgmt/pkg already installed pkg-static: failed to find the version elf note ===> Registering installation for pkg-1.3.0 pkg-static: failed to find the version elf note pkg-static: failed to find the version elf note If you are upgrading from the old package format, first run: # pkg2ng root@cambria-build:/usr/ports/ports-mgmt/pkg # pkg info pkg pkg: failed to find the version elf note pkg-1.3.0 Name : pkg Version : 1.3.0 Installed on : Fri Jul 25 06:36:42 UTC 2014 Origin : ports-mgmt/pkg Architecture :  ¸ Prefix : /usr/local Categories : ports-mgmt Licenses : BSD2CLAUSE Maintainer : portmgr@FreeBSD.org WWW : http://wiki.freebsd.org/pkgng Comment : Package manager Flat size : 7.14MiB Description : Package management tool WWW: http://wiki.freebsd.org/pkgng root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -a FreeBSD cambria-build 11.0-CURRENT FreeBSD 11.0-CURRENT #13 r269057M: Thu Jul 24 15:54:38 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/CAMBRIA arm root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -p armeb root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -m arm root@cambria-build:/usr/ports/ports-mgmt/pkg ################### On the previous pkg, I used a small crow-bar patch (attached) then it did install properly and its architecture looked like this: ################### % pkg info pkg pkg-1.2.7_3 Name : pkg Version : 1.2.7_3 Installed on : Thu Jul 17 15:15:05 SAST 2014 Origin : ports-mgmt/pkg Architecture : freebsd:11:arm:32:eb:eabi:softfp Prefix : /usr/local Categories : ports-mgmt Licenses : BSD2CLAUSE Maintainer : portmgr@FreeBSD.org WWW : http://wiki.freebsd.org/pkgng Comment : Package manager Shared Libs required: libpkg.so.1 Flat size : 6.48MiB Description : Package management tool WWW: http://wiki.freebsd.org/pkgng ################### Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za --- libpkg/pkg_elf.c.orig 2014-03-15 13:15:46.000000000 +0000 +++ libpkg/pkg_elf.c 2014-06-23 17:41:35.000000000 +0000 @@ -636,6 +636,12 @@ int ret = EPKG_OK; int i; const char *arch, *abi, *endian_corres_str, *wordsize_corres_str, *fpu; + const char *path; + char localname[] = "freebsd"; + + path = getenv("ABI_FILE"); + if (path == NULL) + path = _PATH_BSHELL; if (elf_version(EV_CURRENT) == EV_NONE) { pkg_emit_error("ELF library initialization failed: %s", @@ -643,7 +649,7 @@ return (EPKG_FATAL); } - if ((fd = open(_PATH_BSHELL, O_RDONLY)) < 0) { + if ((fd = open(path, O_RDONLY)) < 0) { pkg_emit_errno("open", _PATH_BSHELL); snprintf(dest, sz, "%s", "unknown"); return (EPKG_FATAL); @@ -687,6 +693,7 @@ break; src += note.n_namesz + note.n_descsz; } +#if 0 if ((uintptr_t)src >= ((uintptr_t)data->d_buf + data->d_size)) { ret = EPKG_FATAL; pkg_emit_error("failed to find the version elf note"); @@ -698,7 +705,10 @@ version = be32dec(src); else version = le32dec(src); - +#else + osname = localname; + version = 11 * 100000; +#endif for (i = 0; osname[i] != '\0'; i++) osname[i] = (char)tolower(osname[i]); From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 09:19:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11DDCEF6 for ; Fri, 25 Jul 2014 09:19:52 +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 98D3D281F for ; Fri, 25 Jul 2014 09:19:51 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id bs8so625948wib.15 for ; Fri, 25 Jul 2014 02:19:49 -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:content-transfer-encoding; bh=lmkdrjNiGyGFcg8RprkHRmAe3CYRneY2AVIKsyO37q4=; b=CdcHsnDgE+pimhkFNid5buDbqEXn/Ju2oiV0Sl+hLJg6rMtDAcoGN17OHyMNwBv5Ir Y6qpFVP1fluhieNx0pQbyb++eVuYmtkzU1zpgIfXplJdqd4Ia4nNpROLOq9U1q8hfnch Q6qo0EOPfDZvXZQqHLgPVXmTp3OIkBtouDD/YFG+EKUMeb+l0iGxUzFdLkiI70ep0okl O2hjWqnklYBTiQtSp1Z7623gTkUceGyQaYnyeClV/YhFa6WWIVsgXZRY6yVTOPK0p3Vi 9SfxMjEE8XHcJgqPaLtVZeTXKEZaw4MRKU2qyMyWgqA4ESqjCplGPCHZx1AHzWsGnicX NDrw== X-Received: by 10.180.105.68 with SMTP id gk4mr3433861wib.24.1406279989787; Fri, 25 Jul 2014 02:19:49 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:4d2:64da:12a7:1e1c? ([2001:1620:ff0:c51:4d2:64da:12a7:1e1c]) by mx.google.com with ESMTPSA id o2sm3558735wij.24.2014.07.25.02.19.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 02:19:49 -0700 (PDT) Message-ID: <53D22134.9050409@gmail.com> Date: Fri, 25 Jul 2014 11:19:48 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Sergey V. Dyatko" , freebsd-current@freebsd.org Subject: Re: r268621: panic: shadowed tmpfs v_object [with dump] References: <53CED27C.4080306@FreeBSD.org> <53CED29F.1090809@FreeBSD.org> <53CED718.2090108@FreeBSD.org> <53CEDD74.9070804@FreeBSD.org> <20140723141122.GG93733@kib.kiev.ua> <53CFDF0B.1080904@FreeBSD.org> <53D0218E.3080204@gmail.com> <20140725083607.4d943e63@laptop.minsk.domain> In-Reply-To: <20140725083607.4d943e63@laptop.minsk.domain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:19:52 -0000 >> Got the same panic, is this fix getting committed? Or has it already >> been committed? > r269053 Thanks, confirming that it fixes the panic as well :-) From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 09:58:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DD3AB6E; Fri, 25 Jul 2014 09:58:56 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id B5A882C1D; Fri, 25 Jul 2014 09:58:55 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hKQq157tZzRG; Fri, 25 Jul 2014 11:58:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1406282329; x=1408874330; bh=iQG sxwTE3CG9DTK8vqPZl69YvnECUv5Skg+aJftyidM=; b=DlBaoJr/B8gAx6igCH9 S1swqgdELa8n2Xyiiam14FPGDGeyz48b0MgRsmtYpaVrvP7B5GjLcBzxKV1Vpl4f fn4cwsopo9d1B7c4hKgIA0QYAw2vAVHps6BJs9IJpT1/MGsfDFjNkXSnaWtuHof4 yO1kbChdSLB7OwpQqBiQyT+s= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id gmjTzVhItnlS; Fri, 25 Jul 2014 11:58:49 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Fri, 25 Jul 2014 11:58:48 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hKQpw2cQ8z5W; Fri, 25 Jul 2014 11:58:48 +0200 (CEST) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Fri, 25 Jul 2014 11:58:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Jul 2014 11:58:48 +0200 From: Mark Martinec To: Larry Rosenman Subject: Re: zfs send/recv: STILL invalid Backup Stream Organization: J. Stefan Institute In-Reply-To: <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> References: <62315eb454a95db636b7764aad3c0f9b@thebighonker.lerctr.org> <53D1448C.40908@freebsd.org> <53D15438.6040105@freebsd.org> <0a9cd451c3b4304d2b9d899fcb3decc3@thebighonker.lerctr.org> <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> <53D1AB3D.1060205@freebsd.org> <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> Message-ID: <60845088153247fa31c50c9f52ef72cb@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:58:56 -0000 > On 2014-07-24 19:56, Allan Jude wrote: >>> or better yet: >>> ssh root@tbh.lerctr.org "zfs send ..." | mbuffer -m 16M | zfs recv >>> ... >>> (The misc/mbuffer compensates for bursty zfs reads and writes. >>> A note to myself: I should suggest to Allan to add mbuffer >>> in a pipe as used in sysutils/zxfer, instead of patching zxfer >>> for our local use :) >> >> zxfer can already do this, with the -D option >> I actually use misc/clpbar and get a progress bar as well >> >> -D 'bar -s %%size%% -bl 1m -bs 128m' >> >> or in your case: -D 'mbuffer -m 16M' Thank you Allan! It shows it's been a while since the last time I inspected the guts of zxfer. 2014-07-25 06:43 Larry Rosenman wrote: > Ok, I did the mbuffer trick, and the SEND side is where the memory > issue is: > borg.lerctr.org /home/ler/bin $ tail zfs-send.log > 23:28:12 15.7G zroot/home@2014-07-24_22:56 > 23:28:13 15.7G zroot/home@2014-07-24_22:56 > 23:28:14 15.7G zroot/home@2014-07-24_22:56 > 23:28:15 15.7G zroot/home@2014-07-24_22:56 > 23:28:16 15.7G zroot/home@2014-07-24_22:56 > 23:28:17 15.7G zroot/home@2014-07-24_22:56 > 23:28:18 15.7G zroot/home@2014-07-24_22:56 > 23:28:19 15.7G zroot/home@2014-07-24_22:56 > 23:28:20 15.8G zroot/home@2014-07-24_22:56 > Write failed: Cannot allocate memory > borg.lerctr.org /home/ler/bin $ Good information. So the "Write failed: Cannot allocate memory" on the send side is what is causing the "invalid backup stream" on the receiving side. > borg.lerctr.org /home/ler/bin $ tail zfs-recv.log > cannot receive new filesystem stream: invalid backup stream > borg.lerctr.org /home/ler/bin $ > > borg.lerctr.org /home/ler/bin $ cat backup-TBH-ZFS-initial.sh > #!/bin/sh > DATE=`date "+%Y-%m-%d_%H:%M"` > #DATE2=2013-03-24 > #DATE2=`date -v "-1d" "+%Y-%m-%d"` > # snap the source > ssh root@tbh.lerctr.org zfs snapshot -r zroot@${DATE} > # zfs copy the source to here. > ssh root@tbh.lerctr.org 2>zfs-send.log "zfs send -v -R zroot@${DATE} " > | \ > mbuffer -m 16M 2>mbuffer.log | \ > zfs recv -F -u -v -d zroot/backups/TBH3 2>zfs-recv.log > # make sure we NEVER allow the backup stuff to automount. > /sbin/zfs list -H -t filesystem -r zroot/backups/TBH3| \ > awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh > borg.lerctr.org /home/ler/bin $ > > borg.lerctr.org /home/ler/bin $ ssh tbh vmstat -z > ITEM SIZE LIMIT USED FREE REQ FAIL > SLEEP [...] > Where to now? Don't know, I'd guess some network-related memory limit is being hit on the sending site. Why not try to decouple the 'zfs send' from a network copy and ssh: Login to a remote side, do a 'zfs send' to some local temporary file there, then feed that file to ssh and send it over to a home host, where it can be piped into some simple program like md5 or 'wc -c' instead of a zfs recv. Mark From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 10:05:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00B08E59 for ; Fri, 25 Jul 2014 10:05:00 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6ACE2CFE for ; Fri, 25 Jul 2014 10:05:00 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XAcN1-0007Qx-H3 for freebsd-current@freebsd.org; Fri, 25 Jul 2014 03:04:59 -0700 Date: Fri, 25 Jul 2014 03:04:59 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1406282699515-5931653.post@n5.nabble.com> Subject: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 10:05:01 -0000 Hello. Several questions for 11-Current: * I keep getting .core (gedit.core, midori.core, etc) files being created either in /home/myuser or in the folder I run the command in on terminal emulator (for example if I'm in ~/mydocs on terminal and run "$ gedit filename", that folder gets a gedit.core file). Any way to stop this? * I noticed the system now does a dhcp lookup during boot, while in the past it did not do so (I have static IP defined in rc.conf). Any reason for this change, and how can I disable it (already have dhclient_enable="NO" in rc.conf) * Are there any tweaks (sysctl or such) for fastest possible shutdown for "poweroff"? * I have a kernel with all witness/debug code disabled, and the zfs root is on a Sata3-SSD. The boot process seems a little slow to me and I'm curious as to possible reasons. Other than disabling debug, what else can I do to speed-up boot process (CPU: AMD Phenom II X4 B60 3415.38-MHz K8-class) Thanks and Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 11:19:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B14155F1 for ; Fri, 25 Jul 2014 11:19:30 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92E602421 for ; Fri, 25 Jul 2014 11:19:30 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XAdX7-0002mw-Il for freebsd-current@freebsd.org; Fri, 25 Jul 2014 04:19:29 -0700 Date: Fri, 25 Jul 2014 04:19:29 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1406287169575-5931665.post@n5.nabble.com> In-Reply-To: <1406282699515-5931653.post@n5.nabble.com> References: <1406282699515-5931653.post@n5.nabble.com> Subject: Re: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:19:30 -0000 > Damian Weber wrote: >is there >ifconfig_em0="DHCP" >or anything like that in your rc.conf? No, network related rc.conf entries: network_interfaces="lo0 re0 re1" ifconfig_lo0="inet 127.0.0.1/24" ifconfig_re0="inet 192.168.1.10/24" ifconfig_re1="inet 192.168.2.1/24" gateway_enable="YES" defaultrouter="192.168.1.1" dhclient_enable="NO" Thanks & regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931665.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 12:04:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4C279A1 for ; Fri, 25 Jul 2014 12:04:28 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C66FC28EA for ; Fri, 25 Jul 2014 12:04:28 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XAeEd-000502-Rj for freebsd-current@freebsd.org; Fri, 25 Jul 2014 05:04:27 -0700 Date: Fri, 25 Jul 2014 05:04:27 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1406289867854-5931678.post@n5.nabble.com> In-Reply-To: <1406287169575-5931665.post@n5.nabble.com> References: <1406282699515-5931653.post@n5.nabble.com> <1406287169575-5931665.post@n5.nabble.com> Subject: Re: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:04:29 -0000 Kurt Jaeger wrote: > Can you check whether one of your ethernet-ports has a double life > as IPMI port and that one sends out the DHCP ? No such setup. This is my workstation, with wake-on-lan and pxe-boot disabled in bios. Checking boot messages provides a little more insight - Its not one but *both* NIC's that look for DHCP. Also, this is before root gets mounted, so what's in rc.conf is irrelevant: Sending DHCP Discover packet from interface re0 (mac#) Sending DHCP Discover packet from interface re1 (mac#) Received DHCP Offer packet on re0 from 192.168.1.1 (accepted) Received DHCP Offer packet on re0 from 192.168.1.1 (ignored) Received DHCP Offer packet on re0 from 192.168.1.1 (ignored) Sending DHCP Request packet from interface re0 (mac#) Received DHCP Ack packet on re0 from 192.168.1.1 (accepted) DHCP timeout for interface re1 re0 at 192.168.1.11 server 192.168.1.1 subnet mask 255.255.255.0 router 192.168.1.1 Adjusted interface re0 Shutdown interface re1 Trying to mount root from zfs:bsd []... I compile and use the same kernel for both host and pxe-booted diskless clients. So my kernel config file has options NFSCL # Network Filesystem Client options NFS_ROOT # NFS usable as /, requires NFSCL options BOOTP # Needed for non-btx PXE options BOOTP_NFSROOT # Needed for non-btx PXE It's probably what's causing this behavior. Kernel must receive IP before it can try and mount an NFS volume as root. However, I would have assumed that the "vfs.root.mountfrom=" setting in loader.conf would be read before such attempt... ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931678.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 13:49:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96FC0B2C; Fri, 25 Jul 2014 13:49:41 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 638A32334; Fri, 25 Jul 2014 13:49:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=6ENH9mUVv1yygVqRx6MS8w1GgLeLPrgpqCCZzpfIDEc=; b=ccCvOuHzn8KxreNmQ4OY7FIaOZR0xft5XJa+ahIZ2kiSvdU0PZUnH968/tOdB0NDTYCk7I1K+Cpx16Lz2djwigkPVJsVAstQo1pADv87QD/HxG5z1isjZlg4MW3SLpb34RT1+78NRMim4ySFgXCWIcrm8Uzy5WQPDyt3ZMrYvfQ=; Received: from localhost.lerctr.org ([127.0.0.1]:34152 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAfsR-0005EQ-9h; Fri, 25 Jul 2014 08:49:40 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 25 Jul 2014 08:49:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Jul 2014 08:49:39 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org, Freebsd fs Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <20140725134125.GA19293@thebighonker.lerctr.org> References: <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> <53D1AB3D.1060205@freebsd.org> <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> <60845088153247fa31c50c9f52ef72cb@mailbox.ijs.si> <20140725134125.GA19293@thebighonker.lerctr.org> Message-ID: <258d3f814c0d0a1159608d9cf09d65ad@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Mark Martinec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:49:41 -0000 On 2014-07-25 08:41, Larry Rosenman wrote: > On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote: >> Don't know, I'd guess some network-related memory limit is being hit >> on the sending site. >> >> Why not try to decouple the 'zfs send' from a network copy and ssh: >> Login to a remote side, do a 'zfs send' to some local temporary file >> there, then feed that file to ssh and send it over to a home host, >> where it can be piped into some simple program like md5 or 'wc -c' >> instead of a zfs recv. >> > I think I've done that, but it sort of defeats the purpose, as the > stream > becomes a big file on disk. > > I'd like to get some help chasing what parameter(s) need to be fixed > here. > sysctl output and other things at: http://www.lerctr.org/~ler/FreeBSD/ > Can I get some ideas on: > 1) what MIGHT need tweaking > 2) would (k|d)trace help? > 3) what else could we find out what's being told no memory? I *CAN* give SSH/Root/etc access to BOTH boxes on request. What else do you need? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 14:02:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13039301 for ; Fri, 25 Jul 2014 14:02:55 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id C792424E3 for ; Fri, 25 Jul 2014 14:02:54 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5C4B92CB07 for ; Fri, 25 Jul 2014 14:02:53 +0000 (UTC) Message-ID: <53D263A6.5010907@freebsd.org> Date: Fri, 25 Jul 2014 10:03:18 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zfs send/recv: STILL invalid Backup Stream References: <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> <53D1AB3D.1060205@freebsd.org> <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> <60845088153247fa31c50c9f52ef72cb@mailbox.ijs.si> <20140725134125.GA19293@thebighonker.lerctr.org> <258d3f814c0d0a1159608d9cf09d65ad@thebighonker.lerctr.org> In-Reply-To: <258d3f814c0d0a1159608d9cf09d65ad@thebighonker.lerctr.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8FG2H3H8JKklewtonBMTs8W4HaNKU5sPQ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:02:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8FG2H3H8JKklewtonBMTs8W4HaNKU5sPQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-25 09:49, Larry Rosenman wrote: > On 2014-07-25 08:41, Larry Rosenman wrote: >> On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote: >>> Don't know, I'd guess some network-related memory limit is being hit >>> on the sending site. >>> >>> Why not try to decouple the 'zfs send' from a network copy and ssh: >>> Login to a remote side, do a 'zfs send' to some local temporary file >>> there, then feed that file to ssh and send it over to a home host, >>> where it can be piped into some simple program like md5 or 'wc -c' >>> instead of a zfs recv. >>> >> I think I've done that, but it sort of defeats the purpose, as the str= eam >> becomes a big file on disk. >> >> I'd like to get some help chasing what parameter(s) need to be fixed >> here. >> > sysctl output and other things at: >=20 > http://www.lerctr.org/~ler/FreeBSD/ >=20 >=20 >> Can I get some ideas on: >> 1) what MIGHT need tweaking >> 2) would (k|d)trace help? >> 3) what else could we find out what's being told no memory? >=20 > I *CAN* give SSH/Root/etc access to BOTH boxes on request. >=20 > What else do you need? >=20 >=20 Try just ssh into the 'source' host, and do: zfs send -v -R zroot@${DATE} > /dev/null and see if it actually finishes, or if it runs out of memory again. --=20 Allan Jude --8FG2H3H8JKklewtonBMTs8W4HaNKU5sPQ 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0mOqAAoJEJrBFpNRJZKfl5QP/3cw+c1nrXuiB98NndG7pnDN 4TLJfsOFI0/DdM2bUSMQKnw32q7Q8Ozspm5p8t8NwCopGzp7CL4PIxH8V9tMnYw4 txc6l0HD+6CHO0/hAqhbeQAJZWc+LLCYPJO7tsYdvQbcvqyQc8zi+gcaqxWl2E3V l889mNQ6l8ycOX9aBVkb33xk/QiSKPvS3ssqW0jKvj4gRhdyEr8sT2iqXowH/7CA r5ADNdB20GqVcJMTeKpO8eN462xbHBrfNSZ0d3PO0arDIJYdjy+nl+AL2eyHmrxe kXfO2pkNQ8Ale3ws4MJMY9OFPI6Mk4AfZEoUPZwxfzQJiKkg4uIDeV0Y4nMvRVG1 qtY4xvJipHSKA24Ml9zaYeoxccurzWtVlmlTzF0CNjPJr+Xyl2ROBWyg/qPf8d7A xFglCFs13LzAOMhD3qqq/ne/dF7Ec1SBxFVvt8IpG+qgHwHPz/8a/yF9gqpEpCAi 8Ltf42AZJ7MvFwzavIhx8nQ6iTihwXepDg7nv7RODl++frjNhlDPh9BXvZaCmOKA f4cJDH8ULA1pK2gBnADd5MY9CwkRlrCy3RQgWds+KpkmhDXqbSzlmb7emJh2Dh8g zpTJ5HxJeYRQUHHpKa2AySkMfSklY38CXkAT6C1NlnnnBDtiZhyx0/WAXzkaQYam pgFTRoCIXbTux0h16t4R =GUy2 -----END PGP SIGNATURE----- --8FG2H3H8JKklewtonBMTs8W4HaNKU5sPQ-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 14:25:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D07C7D68; Fri, 25 Jul 2014 14:25:02 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B02D276F; Fri, 25 Jul 2014 14:25:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=mRYBlUEmymsa5DztnNC3VdSB98M8ptMmMf7yXLHpIvU=; b=GIXle22RcDfJoOAO7nTQ/lA6s1F9+MvCvCIvwqmDqLd6WWCdzLxGkggh1Kl/spu7tcFDSTA5fn3zPTfxuhFj7zYXYXPyAoZq2JLnCPcM7NbMRUKUnqJ6D+xsjj3LR5cCHm0jHT0qrcPv63juo+6o1oda6v0+sCfsqUP6f3WhFJ4=; Received: from localhost.lerctr.org ([127.0.0.1]:51560 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAgQb-0006aM-Ez; Fri, 25 Jul 2014 09:25:01 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 25 Jul 2014 09:24:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Jul 2014 09:24:27 -0500 From: Larry Rosenman To: Allan Jude Subject: Re: zfs send/recv: STILL invalid Backup Stream In-Reply-To: <53D263A6.5010907@freebsd.org> References: <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> <53D1AB3D.1060205@freebsd.org> <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> <60845088153247fa31c50c9f52ef72cb@mailbox.ijs.si> <20140725134125.GA19293@thebighonker.lerctr.org> <258d3f814c0d0a1159608d9cf09d65ad@thebighonker.lerctr.org> <53D263A6.5010907@freebsd.org> Message-ID: <7d0d742431172d4d2e36a68d209a4597@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.1 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: Freebsd fs , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:25:03 -0000 On 2014-07-25 09:03, Allan Jude wrote: > On 2014-07-25 09:49, Larry Rosenman wrote: >> On 2014-07-25 08:41, Larry Rosenman wrote: >>> On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote: >>>> Don't know, I'd guess some network-related memory limit is being hit >>>> on the sending site. >>>> >>>> Why not try to decouple the 'zfs send' from a network copy and ssh: >>>> Login to a remote side, do a 'zfs send' to some local temporary file >>>> there, then feed that file to ssh and send it over to a home host, >>>> where it can be piped into some simple program like md5 or 'wc -c' >>>> instead of a zfs recv. >>>> >>> I think I've done that, but it sort of defeats the purpose, as the >>> stream >>> becomes a big file on disk. >>> >>> I'd like to get some help chasing what parameter(s) need to be fixed >>> here. >>> >> sysctl output and other things at: >> >> http://www.lerctr.org/~ler/FreeBSD/ >> >> >>> Can I get some ideas on: >>> 1) what MIGHT need tweaking >>> 2) would (k|d)trace help? >>> 3) what else could we find out what's being told no memory? >> >> I *CAN* give SSH/Root/etc access to BOTH boxes on request. >> >> What else do you need? >> >> > > Try just ssh into the 'source' host, and do: > zfs send -v -R zroot@${DATE} > /dev/null > > and see if it actually finishes, or if it runs out of memory again. that, of course, worked fine :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 14:37:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9212819D for ; Fri, 25 Jul 2014 14:37:08 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 5572F2883 for ; Fri, 25 Jul 2014 14:37:08 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XAgcM-000Fda-Ea for freebsd-current@freebsd.org; Fri, 25 Jul 2014 16:37:06 +0200 Message-ID: <53D26B8D.9020005@dumbbell.fr> Date: Fri, 25 Jul 2014 16:37:01 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI References: <53CBEC26.7080404@icloud.com> <53D018AD.4080800@gmx.de> In-Reply-To: <53D018AD.4080800@gmx.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hidMmdnOtAMg6i7p1bwsfGWDt6Ra1SrGA" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:37:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hidMmdnOtAMg6i7p1bwsfGWDt6Ra1SrGA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 23.07.2014 22:18, Lokadamus wrote: > Am 20.07.2014 18:19, schrieb Anders Bolt-Evensen: >> info: [drm] Initialized i915 1.6.0 20080730 > 1.6.0 20080730 looks old for me. > Have a look at https://wiki.freebsd.org/Graphics section "Installing KM= S > Ports" 1.6.0 is the version of the kernel driver, not xf86-video-intel. He is using the latest version available in FreeBSD. --=20 Jean-S=E9bastien P=E9dron --hidMmdnOtAMg6i7p1bwsfGWDt6Ra1SrGA 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0muRAAoJEDnpl2Gl/ZTMyL8P/jwF0OoX7KeSKU8rAsib7gW7 rR7vqi4IIVJNKdEsRgM2/lnsIh/oCECE8s7NoSZrubuGKhGj0I6CEfjUzeZQyi+K 2501jYZke9PkBEpa0pMdjjcY2QFd65WAMQOMEbgrR12D8lxvIecER+OGzcGHYdJf 6uemJhqTJWmihUeHd30C10Q++a4PnPv4b6QVsCERD2vDJVoBpkroBFY+SZ69dQaD zk3d/mAzK3b0xl+FbXk8UaNKQn2TVc9wFItgZ7hay5VE57YDrgiCYetbS5iAF632 M7cDKET6PPe2B2J0cq2RPZEU0jKJ8Eec3QcycJuhlfHgDdX+e7iL1Sp3Y2/oH998 EdRVkDDDoTYpWZT7vnMx+1S7ismle/g5GmEuQ7Ja2gmhSC9g5uRfAT+lgQYA8Zpl B/kTXcKctsyJGTsj69RBh7W9gXhZ1LOdSEKiVgFajtEhuKCDPklzybUkju0V5hKy 8o/pn4WqOTtBiJU52QCZ/9uLd5Wu1NarxtlGXzrHLUZN2Rf8MHpx4OzTi9ZtNvJi iG6Y39wyhdAbd2OtKuPpnZxadzPPFBf88N7TyrtIEm1N2Uk07QoFCayWSXPabAt9 uo/Bmghel41+XIvFgV6ZuFgx82CTDm8Wz+V1+XLXJzN/pKXtZkW+kytwrbKG7zlj KNur2fhoWTNATfDAiU0u =q0S2 -----END PGP SIGNATURE----- --hidMmdnOtAMg6i7p1bwsfGWDt6Ra1SrGA-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 14:45:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BB013BA for ; Fri, 25 Jul 2014 14:45:54 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 2F1AC295C for ; Fri, 25 Jul 2014 14:45:54 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XAgkq-000FhA-DK for freebsd-current@freebsd.org; Fri, 25 Jul 2014 16:45:52 +0200 Message-ID: <53D26D9F.6050100@dumbbell.fr> Date: Fri, 25 Jul 2014 16:45:51 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI References: <53CBEC26.7080404@icloud.com> In-Reply-To: <53CBEC26.7080404@icloud.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aILGmLbHflhN8V8M11Pbvuo6UIs0qKtGp" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:45:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aILGmLbHflhN8V8M11Pbvuo6UIs0qKtGp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.07.2014 18:19, Anders Bolt-Evensen wrote: > Hello, everyone! Hi! > When I try to use the radeon driver, X exits because of BIOS errors > (since I do not use BIOS when in EFI mode), as can be seen from the > output of "dmesg -a" from a verbose boot (at the time dmesg -a was run,= > I had commented out the line with the intel driver to force it to use > the radeon driver instead, since the intel driver caused the screen to > freeze). I can't comment on the Intel driver behavior, but I never tested the Radeon driver with UEFI yet. The BIOS errors you see mean that the driver failed to locate the Video BIOS. There no relation with the System BIOS or, in your case, UEFI. > info: [drm] radeon_acpi_vfct_bios: =3D=3D=3D> Try VFCT... > info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table > info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_F= OUND Those calls to get the "VFCT" ACPI table should succeed in an UEFI context. But as I said, this was never tested. > error: [drm:pid1363:radeon_get_bios] *ERROR* Unable to locate a BIOS RO= M > drmn0: error: Fatal error during GPU init > info: [drm] radeon: finishing device. > [TTM] Memory type 2 has not been initialized > device_attach: drmn0 attach returned 22 And here, without the Video BIOS, the driver misses too much information and abort the initialization of the card. I currently have no suggestion to make to debug and fix this situation. I need to study a bit what should be going on before. My laptop, which has UEFI available, doesn't boot FreeBSD for now (it fails to probe the system memory). I'll get back to you as soon as I can work on this. --=20 Jean-S=E9bastien P=E9dron --aILGmLbHflhN8V8M11Pbvuo6UIs0qKtGp 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT0m2gAAoJEDnpl2Gl/ZTMqJEP/3bf1QvBim6OU9j4uiWcplYw GjxUbwZR/vBo02tKl1RYuNP7ZdgpGxezSA73+jjwBv1oavQCwRLADJ18XYtPB0v1 d5YsaFHuAv64KolzWPQ9VPhKv292Yat1nqKaNCBOYVodwSnyY0bmaPzEh1QU1pk/ rae8SVnUsvFcbHPanjx9czr2DjxqJOdM/cF3QNj6LaF6gV0xNh7JrWkTb8qb1qyL k5MgqrlImuxzkgqoFsf2FcaOhRKDAmdyBAPN6nFutgn1d+jR/Zo1pXK0byCKQWMS 667uFnlaEq4LZWETHPNQ5VZyOj3uPHHQsPKdQSZ14WO3K2K/6Apc6F0DpPVsQGNw XRCD6sHvUeLQduCozScanuQtWZHSTwbVtYD+s7HQOmvETelc1p+8X5zEaHhcVeco 38KKMzQDcMJLfthSE5gG/7dGSyUl2OqGWb3ia1LBURwZHGqc/1nxu9JOv0t/sRbq o+CwS8kGhb6KXvZ9Z5yBQktYHyXej27dKLy+niTpN6+1nPpKoIdmrj7Xvh8hpPvf ub/7yn9XZWVZ8SWNvOLGBVndXH3+qsz92kLLWnlcUSXWJQW6Kv2R+pRBQyMvDa2a BVC4mHU0zz0/dkiw7sSqWIJkUU29z1367OJtNenPHR9+WKm0RnGfrDQe82xAgeCB xBPVQpg3sFaJMyySqO50 =I89z -----END PGP SIGNATURE----- --aILGmLbHflhN8V8M11Pbvuo6UIs0qKtGp-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 13:42:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08DDA21F; Fri, 25 Jul 2014 13:42:01 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85AB922A9; Fri, 25 Jul 2014 13:42:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=E5weJL052z47kqJELFthnwgG7wQCq1NgLd3e6WhqVHk=; b=cTgmAEMfST4/SiFngbv4WToLp/tZ7A+0obMTTAkEBgtG3w1GrE/tAe5WBRz6Tqm11doqgk3Kffa+Ev/jYXudJb7THnZWyyi7IQf89/ayoPSCXEREinHCeL6PNizALcAdzHKZOk9nMmqj5veHLyWXUlr6JSdhjvz6zQrAZWOU+GE=; Received: from thebighonker.lerctr.org ([192.147.25.65]:32493) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XAfkV-00053T-2k; Fri, 25 Jul 2014 08:41:56 -0500 Date: Fri, 25 Jul 2014 08:41:25 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org, Freebsd fs Subject: Re: zfs send/recv: STILL invalid Backup Stream Message-ID: <20140725134125.GA19293@thebighonker.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org, Freebsd fs , Mark Martinec References: <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> <53D1AB3D.1060205@freebsd.org> <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> <60845088153247fa31c50c9f52ef72cb@mailbox.ijs.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60845088153247fa31c50c9f52ef72cb@mailbox.ijs.si> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-Mailman-Approved-At: Fri, 25 Jul 2014 15:35:59 +0000 Cc: Mark Martinec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:42:01 -0000 On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote: > Don't know, I'd guess some network-related memory limit is being hit > on the sending site. > > Why not try to decouple the 'zfs send' from a network copy and ssh: > Login to a remote side, do a 'zfs send' to some local temporary file > there, then feed that file to ssh and send it over to a home host, > where it can be piped into some simple program like md5 or 'wc -c' > instead of a zfs recv. > I think I've done that, but it sort of defeats the purpose, as the stream becomes a big file on disk. I'd like to get some help chasing what parameter(s) need to be fixed here. Full sysctl -a (from LONG after the failure). kern.ostype: FreeBSD kern.osrelease: 10.0-STABLE kern.osrevision: 199506 kern.version: FreeBSD 10.0-STABLE #39 r269019M: Wed Jul 23 11:44:35 CDT 2014 root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/GENERIC kern.maxvnodes: 350155 kern.maxproc: 21748 kern.maxfiles: 523339 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: thebighonker.lerctr.org kern.hostid: 3151778009 kern.clockrate: { hz = 1000, tick = 1000, profhz = 8128, stathz = 127 } kern.posix1version: 200112 kern.ngroups: 1023 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1406134586, usec = 684885 } Wed Jul 23 11:56:26 2014 kern.domainname: kern.osreldate: 1000711 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 470997 kern.maxprocperuid: 19573 kern.ipc.maxsockbuf: 2097152 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 92 kern.ipc.maxmbufmem: 8345339904 kern.ipc.nmbclusters: 1018718 kern.ipc.nmbjumbop: 509359 kern.ipc.nmbjumbo9: 452763 kern.ipc.nmbjumbo16: 339572 kern.ipc.nmbufs: 6519810 kern.ipc.maxpipekva: 267948032 kern.ipc.pipekva: 1835008 kern.ipc.pipefragretry: 0 kern.ipc.pipeallocfail: 0 kern.ipc.piperesizefail: 0 kern.ipc.piperesizeallowed: 1 kern.ipc.msgmax: 16384 kern.ipc.msgmni: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgtql: 40 kern.ipc.msgssz: 8 kern.ipc.msgseg: 2048 kern.ipc.semmni: 50 kern.ipc.semmns: 340 kern.ipc.semmnu: 150 kern.ipc.semmsl: 340 kern.ipc.semopm: 100 kern.ipc.semume: 50 kern.ipc.semusz: 632 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 536870912 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 131072 kern.ipc.shm_use_phys: 0 kern.ipc.shm_allow_removed: 1 kern.ipc.soacceptqueue: 128 kern.ipc.numopensockets: 247 kern.ipc.maxsockets: 523340 kern.ipc.sendfile.readahead: 1 kern.dummy: 0 kern.ps_strings: 140737488351200 kern.usrstack: 140737488351232 kern.logsigexit: 1 kern.iov_max: 1024 kern.hostuuid: b74ca469-74a4-11e3-8eb3-00237d9e6e8a kern.cam.sort_io_queues: 1 kern.cam.boot_delay: 0 kern.cam.num_doneqs: 2 kern.cam.dflags: 0 kern.cam.debug_delay: 0 kern.cam.pmp.retry_count: 1 kern.cam.pmp.default_timeout: 30 kern.cam.pmp.hide_special: 1 kern.cam.cam_srch_hi: 0 kern.cam.scsi_delay: 5000 kern.cam.cd.poll_period: 3 kern.cam.cd.retry_count: 4 kern.cam.cd.timeout: 30000 kern.cam.cd.0.minimum_cmd_size: 6 kern.cam.ada.legacy_aliases: 1 kern.cam.ada.retry_count: 4 kern.cam.ada.default_timeout: 30 kern.cam.ada.send_ordered: 1 kern.cam.ada.spindown_shutdown: 1 kern.cam.ada.spindown_suspend: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.write_cache: 1 kern.cam.da.poll_period: 3 kern.cam.da.retry_count: 4 kern.cam.da.default_timeout: 60 kern.cam.da.send_ordered: 1 kern.cam.da.0.delete_method: NONE kern.cam.da.0.delete_max: 131072 kern.cam.da.0.minimum_cmd_size: 6 kern.cam.da.0.sort_io_queue: -1 kern.cam.da.0.error_inject: 0 kern.cam.da.2.delete_method: NONE kern.cam.da.2.delete_max: 131072 kern.cam.da.2.minimum_cmd_size: 6 kern.cam.da.2.sort_io_queue: -1 kern.cam.da.2.error_inject: 0 kern.cam.da.4.delete_method: NONE kern.cam.da.4.delete_max: 131072 kern.cam.da.4.minimum_cmd_size: 6 kern.cam.da.4.sort_io_queue: -1 kern.cam.da.4.error_inject: 0 kern.cam.da.1.delete_method: NONE kern.cam.da.1.delete_max: 131072 kern.cam.da.1.minimum_cmd_size: 6 kern.cam.da.1.sort_io_queue: -1 kern.cam.da.1.error_inject: 0 kern.cam.da.3.delete_method: NONE kern.cam.da.3.delete_max: 131072 kern.cam.da.3.minimum_cmd_size: 6 kern.cam.da.3.sort_io_queue: -1 kern.cam.da.3.error_inject: 0 kern.cam.da.5.delete_method: NONE kern.cam.da.5.delete_max: 131072 kern.cam.da.5.minimum_cmd_size: 6 kern.cam.da.5.sort_io_queue: -1 kern.cam.da.5.error_inject: 0 kern.cam.enc.emulate_array_devices: 1 kern.random.adaptors: dummy,yarrow kern.random.active_adaptor: yarrow kern.random.live_entropy_sources: kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 96 kern.random.yarrow.slowthresh: 128 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 1 kern.vt.enable_altgr: 1 kern.vt.debug: 0 kern.vt.deadtimer: 15 kern.vt.suspendswitch: 1 kern.disks: da5 da4 da3 da2 da1 da0 cd0 kern.geom.dev.delete_max_sectors: 262144 kern.geom.disk.cd0.led: kern.geom.disk.da0.led: kern.geom.disk.da1.led: kern.geom.disk.da2.led: kern.geom.disk.da3.led: kern.geom.disk.da4.led: kern.geom.disk.da5.led: kern.geom.transient_maps: 1 kern.geom.transient_map_retries: 10 kern.geom.transient_map_hard_failures: 0 kern.geom.transient_map_soft_failures: 0 kern.geom.inflight_transient_maps: 0 kern.geom.confxml: FD RAID MD LABEL da5p3 3 r1w1e2 r1w1e1 gptid/f7a4d13a-74a3-11e3-8040-00237d9e6e8a 143558337536 512 0 3221767168 0 143558337536 280387378 0 0 da5p2 3 r1w1e1 r1w1e0 gpt/swap5 3221225472 512 0 541696 0 3221225472 6291456 0 0 da5p1 3 r0w0e0 r0w0e0 gptid/f76af2cc-74a3-11e3-8040-00237d9e6e8a 524288 512 0 17408 0 524288 1024 0 0 da5p1 3 r0w0e0 r0w0e0 gpt/gptboot5 524288 512 0 17408 0 524288 1024 0 0 da4p3 3 r1w1e2 r1w1e1 gptid/f7043103-74a3-11e3-8040-00237d9e6e8a 143558337536 512 0 3221767168 0 143558337536 280387378 0 0 da4p2 3 r1w1e1 r1w1e0 gpt/swap4 3221225472 512 0 541696 0 3221225472 6291456 0 0 da4p1 3 r0w0e0 r0w0e0 gptid/f6c16edb-74a3-11e3-8040-00237d9e6e8a 524288 512 0 17408 0 524288 1024 0 0 da4p1 3 r0w0e0 r0w0e0 gpt/gptboot4 524288 512 0 17408 0 524288 1024 0 0 da3p3 3 r1w1e2 r1w1e1 gptid/f6600fef-74a3-11e3-8040-00237d9e6e8a 143558337536 512 0 3221767168 0 143558337536 280387378 0 0 da3p2 3 r1w1e1 r1w1e0 gpt/swap3 3221225472 512 0 541696 0 3221225472 6291456 0 0 da3p1 3 r0w0e0 r0w0e0 gptid/f623a95d-74a3-11e3-8040-00237d9e6e8a 524288 512 0 17408 0 524288 1024 0 0 da3p1 3 r0w0e0 r0w0e0 gpt/gptboot3 524288 512 0 17408 0 524288 1024 0 0 da2p3 3 r1w1e2 r1w1e1 gptid/f5bd173e-74a3-11e3-8040-00237d9e6e8a 143558337536 512 0 3221767168 0 143558337536 280387378 0 0 da2p2 3 r1w1e1 r1w1e0 gpt/swap2 3221225472 512 0 541696 0 3221225472 6291456 0 0 da2p1 3 r0w0e0 r0w0e0 gptid/f57bb25e-74a3-11e3-8040-00237d9e6e8a 524288 512 0 17408 0 524288 1024 0 0 da2p1 3 r0w0e0 r0w0e0 gpt/gptboot2 524288 512 0 17408 0 524288 1024 0 0 da1p3 3 r1w1e2 r1w1e1 gptid/f52330df-74a3-11e3-8040-00237d9e6e8a 143558337536 512 0 3221767168 0 143558337536 280387378 0 0 da1p2 3 r1w1e1 r1w1e0 gpt/swap1 3221225472 512 0 541696 0 3221225472 6291456 0 0 da1p1 3 r0w0e0 r0w0e0 gptid/f4dbf3c8-74a3-11e3-8040-00237d9e6e8a 524288 512 0 17408 0 524288 1024 0 0 da1p1 3 r0w0e0 r0w0e0 gpt/gptboot1 524288 512 0 17408 0 524288 1024 0 0 da0p3 3 r1w1e2 r1w1e1 gptid/f471cf71-74a3-11e3-8040-00237d9e6e8a 143558337536 512 0 3221767168 0 143558337536 280387378 0 0 da0p2 3 r1w1e1 r1w1e0 gpt/swap0 3221225472 512 0 541696 0 3221225472 6291456 0 0 da0p1 3 r0w0e0 r0w0e0 gptid/f4308ed8-74a3-11e3-8040-00237d9e6e8a 524288 512 0 17408 0 524288 1024 0 0 da0p1 3 r0w0e0 r0w0e0 gpt/gptboot0 524288 512 0 17408 0 524288 1024 0 0 SWAP swap 4 r1w1e0 r1w1e0 r1w1e0 r1w1e0 r1w1e0 r1w1e0 PART da5 2 GPT 128 34 286679891 63 255 OK false r2w2e5 r1w1e2 da5p3 143558337536 512 0 3221767168 6292514 286679891 3 freebsd-zfs 3221767168 143558337536 516e7cba-6ecf-11d6-8ff8-00022d09712b f7a4d13a-74a3-11e3-8040-00237d9e6e8a r1w1e1 da5p2 3221225472 512 0 541696 1058 6292513 2 freebsd-swap 541696 3221225472 516e7cb5-6ecf-11d6-8ff8-00022d09712b f7859ccb-74a3-11e3-8040-00237d9e6e8a r0w0e0 da5p1 524288 512 0 17408 34 1057 1 freebsd-boot 17408 524288 83bd6b9d-7f41-11dc-be0b-001560b84f0f f76af2cc-74a3-11e3-8040-00237d9e6e8a da4 2 GPT 128 34 286679891 63 255 OK false r2w2e5 r1w1e2 da4p3 143558337536 512 0 3221767168 6292514 286679891 3 freebsd-zfs 3221767168 143558337536 516e7cba-6ecf-11d6-8ff8-00022d09712b f7043103-74a3-11e3-8040-00237d9e6e8a r1w1e1 da4p2 3221225472 512 0 541696 1058 6292513 2 freebsd-swap 541696 3221225472 516e7cb5-6ecf-11d6-8ff8-00022d09712b f6dfc4d9-74a3-11e3-8040-00237d9e6e8a r0w0e0 da4p1 524288 512 0 17408 34 1057 1 freebsd-boot 17408 524288 83bd6b9d-7f41-11dc-be0b-001560b84f0f f6c16edb-74a3-11e3-8040-00237d9e6e8a da3 2 GPT 128 34 286679891 63 255 OK false r2w2e5 r1w1e2 da3p3 143558337536 512 0 3221767168 6292514 286679891 3 freebsd-zfs 3221767168 143558337536 516e7cba-6ecf-11d6-8ff8-00022d09712b f6600fef-74a3-11e3-8040-00237d9e6e8a r1w1e1 da3p2 3221225472 512 0 541696 1058 6292513 2 freebsd-swap 541696 3221225472 516e7cb5-6ecf-11d6-8ff8-00022d09712b f640232f-74a3-11e3-8040-00237d9e6e8a r0w0e0 da3p1 524288 512 0 17408 34 1057 1 freebsd-boot 17408 524288 83bd6b9d-7f41-11dc-be0b-001560b84f0f f623a95d-74a3-11e3-8040-00237d9e6e8a da2 2 GPT 128 34 286679891 63 255 OK false r2w2e5 r1w1e2 da2p3 143558337536 512 0 3221767168 6292514 286679891 3 freebsd-zfs 3221767168 143558337536 516e7cba-6ecf-11d6-8ff8-00022d09712b f5bd173e-74a3-11e3-8040-00237d9e6e8a r1w1e1 da2p2 3221225472 512 0 541696 1058 6292513 2 freebsd-swap 541696 3221225472 516e7cb5-6ecf-11d6-8ff8-00022d09712b f59a0a61-74a3-11e3-8040-00237d9e6e8a r0w0e0 da2p1 524288 512 0 17408 34 1057 1 freebsd-boot 17408 524288 83bd6b9d-7f41-11dc-be0b-001560b84f0f f57bb25e-74a3-11e3-8040-00237d9e6e8a da1 2 GPT 128 34 286679891 63 255 OK false r2w2e5 r1w1e2 da1p3 143558337536 512 0 3221767168 6292514 286679891 3 freebsd-zfs 3221767168 143558337536 516e7cba-6ecf-11d6-8ff8-00022d09712b f52330df-74a3-11e3-8040-00237d9e6e8a r1w1e1 da1p2 3221225472 512 0 541696 1058 6292513 2 freebsd-swap 541696 3221225472 516e7cb5-6ecf-11d6-8ff8-00022d09712b f4fd9ed9-74a3-11e3-8040-00237d9e6e8a r0w0e0 da1p1 524288 512 0 17408 34 1057 1 freebsd-boot 17408 524288 83bd6b9d-7f41-11dc-be0b-001560b84f0f f4dbf3c8-74a3-11e3-8040-00237d9e6e8a da0 2 GPT 128 34 286679891 63 255 OK false r2w2e5 r1w1e2 da0p3 143558337536 512 0 3221767168 6292514 286679891 3 freebsd-zfs 3221767168 143558337536 516e7cba-6ecf-11d6-8ff8-00022d09712b f471cf71-74a3-11e3-8040-00237d9e6e8a r1w1e1 da0p2 3221225472 512 0 541696 1058 6292513 2 freebsd-swap 541696 3221225472 516e7cb5-6ecf-11d6-8ff8-00022d09712b f44d1866-74a3-11e3-8040-00237d9e6e8a r0w0e0 da0p1 524288 512 0 17408 34 1057 1 freebsd-boot 17408 524288 83bd6b9d-7f41-11dc-be0b-001560b84f0f f4308ed8-74a3-11e3-8040-00237d9e6e8a VFS DISK da5 1 r2w2e5 da5 146780121600 512 0 0 255 63 PH8BMQ3157 600508b100103135372020202020000d HP RAID 0 da4 1 r2w2e5 da4 146780121600 512 0 0 255 63 PH8BMQ3157 600508b100103135372020202020000c HP RAID 0 da3 1 r2w2e5 da3 146780121600 512 0 0 255 63 PH8BMQ3157 600508b100103135372020202020000b HP RAID 0 da2 1 r2w2e5 da2 146780121600 512 0 0 255 63 PH8BMQ3157 600508b100103135372020202020000a HP RAID 0 da1 1 r2w2e5 da1 146780121600 512 0 0 255 63 PH8BMQ3157 600508b1001031353720202020200009 HP RAID 0 da0 1 r2w2e5 da0 146780121600 512 0 0 255 63 PH8BMQ3157 600508b1001031353720202020200008 HP RAID 0 cd0 1 r0w0e0 cd0 0 2048 0 0 0 0 TEAC DV-28E-V DEV gptid/f7a4d13a-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/swap5 4 r0w0e0 gptid/f76af2cc-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/gptboot5 4 r0w0e0 gptid/f7043103-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/swap4 4 r0w0e0 gptid/f6c16edb-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/gptboot4 4 r0w0e0 gptid/f6600fef-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/swap3 4 r0w0e0 gptid/f623a95d-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/gptboot3 4 r0w0e0 gptid/f5bd173e-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/swap2 4 r0w0e0 gptid/f57bb25e-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/gptboot2 4 r0w0e0 gptid/f52330df-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/swap1 4 r0w0e0 gptid/f4dbf3c8-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/gptboot1 4 r0w0e0 gptid/f471cf71-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/swap0 4 r0w0e0 gptid/f4308ed8-74a3-11e3-8040-00237d9e6e8a 4 r0w0e0 gpt/gptboot0 4 r0w0e0 da5p3 3 r0w0e0 da5p2 3 r0w0e0 da5p1 3 r0w0e0 da4p3 3 r0w0e0 da4p2 3 r0w0e0 da4p1 3 r0w0e0 da3p3 3 r0w0e0 da3p2 3 r0w0e0 da3p1 3 r0w0e0 da2p3 3 r0w0e0 da2p2 3 r0w0e0 da2p1 3 r0w0e0 da1p3 3 r0w0e0 da1p2 3 r0w0e0 da1p1 3 r0w0e0 da0p3 3 r0w0e0 da0p2 3 r0w0e0 da0p1 3 r0w0e0 da5 2 r0w0e0 da4 2 r0w0e0 da3 2 r0w0e0 da2 2 r0w0e0 da1 2 r0w0e0 da0 2 r0w0e0 cd0 2 r0w0e0 ZFS::VDEV zfs::vdev 4 r1w1e1 r1w1e1 r1w1e1 r1w1e1 r1w1e1 r1w1e1 ZFS::ZVOL kern.geom.confdot: digraph geom { z0xfffff8000e08f100 [shape=box,label="LABEL\nda5p3\nr#3"]; z0xfffff8000e09c400 [label="r1w1e2"]; z0xfffff8000e09c400 -> z0xfffff8000e0b4c00; z0xfffff8000e08f100 -> z0xfffff8000e09c400; z0xfffff8000e08f000 [shape=hexagon,label="gptid/f7a4d13a-74a3-11e3-8040-00237d9e6e8a\nr1w1e1\nerr#0"]; z0xfffff8000e08f000 -> z0xfffff8000e08f100; z0xfffff8000e0b4800 [shape=box,label="LABEL\nda5p2\nr#3"]; z0xfffff8000e09c600 [label="r1w1e1"]; z0xfffff8000e09c600 -> z0xfffff8000e0b4e00; z0xfffff8000e0b4800 -> z0xfffff8000e09c600; z0xfffff8000af3d600 [shape=hexagon,label="gpt/swap5\nr1w1e0\nerr#0"]; z0xfffff8000af3d600 -> z0xfffff8000e0b4800; z0xfffff8000e062c00 [shape=box,label="LABEL\nda5p1\nr#3"]; z0xfffff8000e070600 [label="r0w0e0"]; z0xfffff8000e070600 -> z0xfffff8000e0b5100; z0xfffff8000e062c00 -> z0xfffff8000e070600; z0xfffff8000e062b00 [shape=hexagon,label="gptid/f76af2cc-74a3-11e3-8040-00237d9e6e8a\nr0w0e0\nerr#0"]; z0xfffff8000e062b00 -> z0xfffff8000e062c00; z0xfffff8000e063000 [shape=box,label="LABEL\nda5p1\nr#3"]; z0xfffff8000e070680 [label="r0w0e0"]; z0xfffff8000e070680 -> z0xfffff8000e0b5100; z0xfffff8000e063000 -> z0xfffff8000e070680; z0xfffff8000e062e00 [shape=hexagon,label="gpt/gptboot5\nr0w0e0\nerr#0"]; z0xfffff8000e062e00 -> z0xfffff8000e063000; z0xfffff8000e08f800 [shape=box,label="LABEL\nda4p3\nr#3"]; z0xfffff8000e09c700 [label="r1w1e2"]; z0xfffff8000e09c700 -> z0xfffff8000e090500; z0xfffff8000e08f800 -> z0xfffff8000e09c700; z0xfffff8000e08f700 [shape=hexagon,label="gptid/f7043103-74a3-11e3-8040-00237d9e6e8a\nr1w1e1\nerr#0"]; z0xfffff8000e08f700 -> z0xfffff8000e08f800; z0xfffff8000e090200 [shape=box,label="LABEL\nda4p2\nr#3"]; z0xfffff8000e09c900 [label="r1w1e1"]; z0xfffff8000e09c900 -> z0xfffff8000e090700; z0xfffff8000e090200 -> z0xfffff8000e09c900; z0xfffff8000e090100 [shape=hexagon,label="gpt/swap4\nr1w1e0\nerr#0"]; z0xfffff8000e090100 -> z0xfffff8000e090200; z0xfffff8000ae21e00 [shape=box,label="LABEL\nda4p1\nr#3"]; z0xfffff8000e088580 [label="r0w0e0"]; z0xfffff8000e088580 -> z0xfffff8000e090900; z0xfffff8000ae21e00 -> z0xfffff8000e088580; z0xfffff8000e07d300 [shape=hexagon,label="gptid/f6c16edb-74a3-11e3-8040-00237d9e6e8a\nr0w0e0\nerr#0"]; z0xfffff8000e07d300 -> z0xfffff8000ae21e00; z0xfffff8000af3b700 [shape=box,label="LABEL\nda4p1\nr#3"]; z0xfffff8000e088600 [label="r0w0e0"]; z0xfffff8000e088600 -> z0xfffff8000e090900; z0xfffff8000af3b700 -> z0xfffff8000e088600; z0xfffff8000af3b500 [shape=hexagon,label="gpt/gptboot4\nr0w0e0\nerr#0"]; z0xfffff8000af3b500 -> z0xfffff8000af3b700; z0xfffff8000e0a2400 [shape=box,label="LABEL\nda3p3\nr#3"]; z0xfffff8000e0ad380 [label="r1w1e2"]; z0xfffff8000e0ad380 -> z0xfffff8000e0b5700; z0xfffff8000e0a2400 -> z0xfffff8000e0ad380; z0xfffff8000e0a2300 [shape=hexagon,label="gptid/f6600fef-74a3-11e3-8040-00237d9e6e8a\nr1w1e1\nerr#0"]; z0xfffff8000e0a2300 -> z0xfffff8000e0a2400; z0xfffff8000e0a2d00 [shape=box,label="LABEL\nda3p2\nr#3"]; z0xfffff8000e0ad580 [label="r1w1e1"]; z0xfffff8000e0ad580 -> z0xfffff8000e0b5900; z0xfffff8000e0a2d00 -> z0xfffff8000e0ad580; z0xfffff8000e0a2c00 [shape=hexagon,label="gpt/swap3\nr1w1e0\nerr#0"]; z0xfffff8000e0a2c00 -> z0xfffff8000e0a2d00; z0xfffff8000e073400 [shape=box,label="LABEL\nda3p1\nr#3"]; z0xfffff8000e052180 [label="r0w0e0"]; z0xfffff8000e052180 -> z0xfffff8000e0b5b00; z0xfffff8000e073400 -> z0xfffff8000e052180; z0xfffff8000e073300 [shape=hexagon,label="gptid/f623a95d-74a3-11e3-8040-00237d9e6e8a\nr0w0e0\nerr#0"]; z0xfffff8000e073300 -> z0xfffff8000e073400; z0xfffff8000e073700 [shape=box,label="LABEL\nda3p1\nr#3"]; z0xfffff8000e052200 [label="r0w0e0"]; z0xfffff8000e052200 -> z0xfffff8000e0b5b00; z0xfffff8000e073700 -> z0xfffff8000e052200; z0xfffff8000e073600 [shape=hexagon,label="gpt/gptboot3\nr0w0e0\nerr#0"]; z0xfffff8000e073600 -> z0xfffff8000e073700; z0xfffff8000e0c6c00 [shape=box,label="LABEL\nda2p3\nr#3"]; z0xfffff8000e0d2080 [label="r1w1e2"]; z0xfffff8000e0d2080 -> z0xfffff8000e0c7800; z0xfffff8000e0c6c00 -> z0xfffff8000e0d2080; z0xfffff8000e0c6b00 [shape=hexagon,label="gptid/f5bd173e-74a3-11e3-8040-00237d9e6e8a\nr1w1e1\nerr#0"]; z0xfffff8000e0c6b00 -> z0xfffff8000e0c6c00; z0xfffff8000e0b4900 [shape=box,label="LABEL\nda2p2\nr#3"]; z0xfffff8000e0d2280 [label="r1w1e1"]; z0xfffff8000e0d2280 -> z0xfffff8000e0c7a00; z0xfffff8000e0b4900 -> z0xfffff8000e0d2280; z0xfffff8000e0c7500 [shape=hexagon,label="gpt/swap2\nr1w1e0\nerr#0"]; z0xfffff8000e0c7500 -> z0xfffff8000e0b4900; z0xfffff800073fa100 [shape=box,label="LABEL\nda2p1\nr#3"]; z0xfffff8000ae83900 [label="r0w0e0"]; z0xfffff8000ae83900 -> z0xfffff8000e0c7c00; z0xfffff800073fa100 -> z0xfffff8000ae83900; z0xfffff80003f61e00 [shape=hexagon,label="gptid/f57bb25e-74a3-11e3-8040-00237d9e6e8a\nr0w0e0\nerr#0"]; z0xfffff80003f61e00 -> z0xfffff800073fa100; z0xfffff800073fa900 [shape=box,label="LABEL\nda2p1\nr#3"]; z0xfffff8000ae83980 [label="r0w0e0"]; z0xfffff8000ae83980 -> z0xfffff8000e0c7c00; z0xfffff800073fa900 -> z0xfffff8000ae83980; z0xfffff800073fa800 [shape=hexagon,label="gpt/gptboot2\nr0w0e0\nerr#0"]; z0xfffff800073fa800 -> z0xfffff800073fa900; z0xfffff8000e07d600 [shape=box,label="LABEL\nda1p3\nr#3"]; z0xfffff8000e088700 [label="r1w1e2"]; z0xfffff8000e088700 -> z0xfffff8000ae21c00; z0xfffff8000e07d600 -> z0xfffff8000e088700; z0xfffff8000e07d500 [shape=hexagon,label="gptid/f52330df-74a3-11e3-8040-00237d9e6e8a\nr1w1e1\nerr#0"]; z0xfffff8000e07d500 -> z0xfffff8000e07d600; z0xfffff800098a5700 [shape=box,label="LABEL\nda1p2\nr#3"]; z0xfffff8000ae81580 [label="r1w1e1"]; z0xfffff8000ae81580 -> z0xfffff8000ae21800; z0xfffff800098a5700 -> z0xfffff8000ae81580; z0xfffff800098a5900 [shape=hexagon,label="gpt/swap1\nr1w1e0\nerr#0"]; z0xfffff800098a5900 -> z0xfffff800098a5700; z0xfffff8000afcc300 [shape=box,label="LABEL\nda1p1\nr#3"]; z0xfffff8000e052300 [label="r0w0e0"]; z0xfffff8000e052300 -> z0xfffff8000afcd600; z0xfffff8000afcc300 -> z0xfffff8000e052300; z0xfffff8000e073900 [shape=hexagon,label="gptid/f4dbf3c8-74a3-11e3-8040-00237d9e6e8a\nr0w0e0\nerr#0"]; z0xfffff8000e073900 -> z0xfffff8000afcc300; z0xfffff8000afccb00 [shape=box,label="LABEL\nda1p1\nr#3"]; z0xfffff8000e052380 [label="r0w0e0"]; z0xfffff8000e052380 -> z0xfffff8000afcd600; z0xfffff8000afccb00 -> z0xfffff8000e052380; z0xfffff8000afcc900 [shape=hexagon,label="gpt/gptboot1\nr0w0e0\nerr#0"]; z0xfffff8000afcc900 -> z0xfffff8000afccb00; z0xfffff8000e073c00 [shape=box,label="LABEL\nda0p3\nr#3"]; z0xfffff8000e052480 [label="r1w1e2"]; z0xfffff8000e052480 -> z0xfffff8000afcc100; z0xfffff8000e073c00 -> z0xfffff8000e052480; z0xfffff8000e073b00 [shape=hexagon,label="gptid/f471cf71-74a3-11e3-8040-00237d9e6e8a\nr1w1e1\nerr#0"]; z0xfffff8000e073b00 -> z0xfffff8000e073c00; z0xfffff8000e074600 [shape=box,label="LABEL\nda0p2\nr#3"]; z0xfffff8000e052680 [label="r1w1e1"]; z0xfffff8000e052680 -> z0xfffff8000af3e900; z0xfffff8000e074600 -> z0xfffff8000e052680; z0xfffff8000e074500 [shape=hexagon,label="gpt/swap0\nr1w1e0\nerr#0"]; z0xfffff8000e074500 -> z0xfffff8000e074600; z0xfffff8000e0a3100 [shape=box,label="LABEL\nda0p1\nr#3"]; z0xfffff8000e0ad680 [label="r0w0e0"]; z0xfffff8000e0ad680 -> z0xfffff8000af3eb00; z0xfffff8000e0a3100 -> z0xfffff8000e0ad680; z0xfffff8000e0a3000 [shape=hexagon,label="gptid/f4308ed8-74a3-11e3-8040-00237d9e6e8a\nr0w0e0\nerr#0"]; z0xfffff8000e0a3000 -> z0xfffff8000e0a3100; z0xfffff8000afca100 [shape=box,label="LABEL\nda0p1\nr#3"]; z0xfffff8000e0ad700 [label="r0w0e0"]; z0xfffff8000e0ad700 -> z0xfffff8000af3eb00; z0xfffff8000afca100 -> z0xfffff8000e0ad700; z0xfffff8000e0a3300 [shape=hexagon,label="gpt/gptboot0\nr0w0e0\nerr#0"]; z0xfffff8000e0a3300 -> z0xfffff8000afca100; z0xfffff8000af3cc00 [shape=box,label="SWAP\nswap\nr#4"]; z0xfffff8000e09ab80 [label="r1w1e0"]; z0xfffff8000e09ab80 -> z0xfffff8000af3d600; z0xfffff8000af3cc00 -> z0xfffff8000e09ab80; z0xfffff8000e09b080 [label="r1w1e0"]; z0xfffff8000e09b080 -> z0xfffff8000e090100; z0xfffff8000af3cc00 -> z0xfffff8000e09b080; z0xfffff8000e09b500 [label="r1w1e0"]; z0xfffff8000e09b500 -> z0xfffff8000e0a2c00; z0xfffff8000af3cc00 -> z0xfffff8000e09b500; z0xfffff8000e09b980 [label="r1w1e0"]; z0xfffff8000e09b980 -> z0xfffff8000e0c7500; z0xfffff8000af3cc00 -> z0xfffff8000e09b980; z0xfffff8000e09be00 [label="r1w1e0"]; z0xfffff8000e09be00 -> z0xfffff800098a5900; z0xfffff8000af3cc00 -> z0xfffff8000e09be00; z0xfffff8000ebd2580 [label="r1w1e0"]; z0xfffff8000ebd2580 -> z0xfffff8000e074500; z0xfffff8000af3cc00 -> z0xfffff8000ebd2580; z0xfffff8000ae1e300 [shape=box,label="PART\nda5\nr#2"]; z0xfffff8000e0c1980 [label="r2w2e5"]; z0xfffff8000e0c1980 -> z0xfffff8000ae1e700; z0xfffff8000ae1e300 -> z0xfffff8000e0c1980; z0xfffff8000e0b4c00 [shape=hexagon,label="da5p3\nr1w1e2\nerr#0"]; z0xfffff8000e0b4c00 -> z0xfffff8000ae1e300; z0xfffff8000e0b4e00 [shape=hexagon,label="da5p2\nr1w1e1\nerr#0"]; z0xfffff8000e0b4e00 -> z0xfffff8000ae1e300; z0xfffff8000e0b5100 [shape=hexagon,label="da5p1\nr0w0e0\nerr#0"]; z0xfffff8000e0b5100 -> z0xfffff8000ae1e300; z0xfffff800098a5c00 [shape=box,label="PART\nda4\nr#2"]; z0xfffff8000e0c1a00 [label="r2w2e5"]; z0xfffff8000e0c1a00 -> z0xfffff8000ae1e100; z0xfffff800098a5c00 -> z0xfffff8000e0c1a00; z0xfffff8000e090500 [shape=hexagon,label="da4p3\nr1w1e2\nerr#0"]; z0xfffff8000e090500 -> z0xfffff800098a5c00; z0xfffff8000e090700 [shape=hexagon,label="da4p2\nr1w1e1\nerr#0"]; z0xfffff8000e090700 -> z0xfffff800098a5c00; z0xfffff8000e090900 [shape=hexagon,label="da4p1\nr0w0e0\nerr#0"]; z0xfffff8000e090900 -> z0xfffff800098a5c00; z0xfffff8000af3e800 [shape=box,label="PART\nda3\nr#2"]; z0xfffff8000e0d2300 [label="r2w2e5"]; z0xfffff8000e0d2300 -> z0xfffff800098a5a00; z0xfffff8000af3e800 -> z0xfffff8000e0d2300; z0xfffff8000e0b5700 [shape=hexagon,label="da3p3\nr1w1e2\nerr#0"]; z0xfffff8000e0b5700 -> z0xfffff8000af3e800; z0xfffff8000e0b5900 [shape=hexagon,label="da3p2\nr1w1e1\nerr#0"]; z0xfffff8000e0b5900 -> z0xfffff8000af3e800; z0xfffff8000e0b5b00 [shape=hexagon,label="da3p1\nr0w0e0\nerr#0"]; z0xfffff8000e0b5b00 -> z0xfffff8000af3e800; z0xfffff8000af3e200 [shape=box,label="PART\nda2\nr#2"]; z0xfffff800098cde80 [label="r2w2e5"]; z0xfffff800098cde80 -> z0xfffff8000af3e600; z0xfffff8000af3e200 -> z0xfffff800098cde80; z0xfffff8000e0c7800 [shape=hexagon,label="da2p3\nr1w1e2\nerr#0"]; z0xfffff8000e0c7800 -> z0xfffff8000af3e200; z0xfffff8000e0c7a00 [shape=hexagon,label="da2p2\nr1w1e1\nerr#0"]; z0xfffff8000e0c7a00 -> z0xfffff8000af3e200; z0xfffff8000e0c7c00 [shape=hexagon,label="da2p1\nr0w0e0\nerr#0"]; z0xfffff8000e0c7c00 -> z0xfffff8000af3e200; z0xfffff8000af3db00 [shape=box,label="PART\nda1\nr#2"]; z0xfffff800098cdb80 [label="r2w2e5"]; z0xfffff800098cdb80 -> z0xfffff8000af3e000; z0xfffff8000af3db00 -> z0xfffff800098cdb80; z0xfffff8000ae21c00 [shape=hexagon,label="da1p3\nr1w1e2\nerr#0"]; z0xfffff8000ae21c00 -> z0xfffff8000af3db00; z0xfffff8000ae21800 [shape=hexagon,label="da1p2\nr1w1e1\nerr#0"]; z0xfffff8000ae21800 -> z0xfffff8000af3db00; z0xfffff8000afcd600 [shape=hexagon,label="da1p1\nr0w0e0\nerr#0"]; z0xfffff8000afcd600 -> z0xfffff8000af3db00; z0xfffff8000af3d500 [shape=box,label="PART\nda0\nr#2"]; z0xfffff800098cd700 [label="r2w2e5"]; z0xfffff800098cd700 -> z0xfffff8000af3d900; z0xfffff8000af3d500 -> z0xfffff800098cd700; z0xfffff8000afcc100 [shape=hexagon,label="da0p3\nr1w1e2\nerr#0"]; z0xfffff8000afcc100 -> z0xfffff8000af3d500; z0xfffff8000af3e900 [shape=hexagon,label="da0p2\nr1w1e1\nerr#0"]; z0xfffff8000af3e900 -> z0xfffff8000af3d500; z0xfffff8000af3eb00 [shape=hexagon,label="da0p1\nr0w0e0\nerr#0"]; z0xfffff8000af3eb00 -> z0xfffff8000af3d500; z0xfffff8000ae1e500 [shape=box,label="DISK\nda5\nr#1"]; z0xfffff8000ae1e700 [shape=hexagon,label="da5\nr2w2e5\nerr#0"]; z0xfffff8000ae1e700 -> z0xfffff8000ae1e500; z0xfffff800098a5e00 [shape=box,label="DISK\nda4\nr#1"]; z0xfffff8000ae1e100 [shape=hexagon,label="da4\nr2w2e5\nerr#0"]; z0xfffff8000ae1e100 -> z0xfffff800098a5e00; z0xfffff800098a5800 [shape=box,label="DISK\nda3\nr#1"]; z0xfffff800098a5a00 [shape=hexagon,label="da3\nr2w2e5\nerr#0"]; z0xfffff800098a5a00 -> z0xfffff800098a5800; z0xfffff8000af3e400 [shape=box,label="DISK\nda2\nr#1"]; z0xfffff8000af3e600 [shape=hexagon,label="da2\nr2w2e5\nerr#0"]; z0xfffff8000af3e600 -> z0xfffff8000af3e400; z0xfffff8000af3dd00 [shape=box,label="DISK\nda1\nr#1"]; z0xfffff8000af3e000 [shape=hexagon,label="da1\nr2w2e5\nerr#0"]; z0xfffff8000af3e000 -> z0xfffff8000af3dd00; z0xfffff8000af3d700 [shape=box,label="DISK\nda0\nr#1"]; z0xfffff8000af3d900 [shape=hexagon,label="da0\nr2w2e5\nerr#0"]; z0xfffff8000af3d900 -> z0xfffff8000af3d700; z0xfffff8000af3d100 [shape=box,label="DISK\ncd0\nr#1"]; z0xfffff8000af3d300 [shape=hexagon,label="cd0\nr0w0e0\nerr#0"]; z0xfffff8000af3d300 -> z0xfffff8000af3d100; z0xfffff8000e08f200 [shape=box,label="DEV\ngptid/f7a4d13a-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09a580 [label="r0w0e0"]; z0xfffff8000e09a580 -> z0xfffff8000e08f000; z0xfffff8000e08f200 -> z0xfffff8000e09a580; z0xfffff8000e062a00 [shape=box,label="DEV\ngpt/swap5\nr#4"]; z0xfffff8000e09a780 [label="r0w0e0"]; z0xfffff8000e09a780 -> z0xfffff8000af3d600; z0xfffff8000e062a00 -> z0xfffff8000e09a780; z0xfffff8000e062d00 [shape=box,label="DEV\ngptid/f76af2cc-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09a880 [label="r0w0e0"]; z0xfffff8000e09a880 -> z0xfffff8000e062b00; z0xfffff8000e062d00 -> z0xfffff8000e09a880; z0xfffff8000e08f600 [shape=box,label="DEV\ngpt/gptboot5\nr#4"]; z0xfffff8000e09a900 [label="r0w0e0"]; z0xfffff8000e09a900 -> z0xfffff8000e062e00; z0xfffff8000e08f600 -> z0xfffff8000e09a900; z0xfffff8000e08f900 [shape=box,label="DEV\ngptid/f7043103-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09aa00 [label="r0w0e0"]; z0xfffff8000e09aa00 -> z0xfffff8000e08f700; z0xfffff8000e08f900 -> z0xfffff8000e09aa00; z0xfffff8000e07d200 [shape=box,label="DEV\ngpt/swap4\nr#4"]; z0xfffff8000e09ac00 [label="r0w0e0"]; z0xfffff8000e09ac00 -> z0xfffff8000e090100; z0xfffff8000e07d200 -> z0xfffff8000e09ac00; z0xfffff8000af3b300 [shape=box,label="DEV\ngptid/f6c16edb-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09ad00 [label="r0w0e0"]; z0xfffff8000e09ad00 -> z0xfffff8000e07d300; z0xfffff8000af3b300 -> z0xfffff8000e09ad00; z0xfffff8000e0a2200 [shape=box,label="DEV\ngpt/gptboot4\nr#4"]; z0xfffff8000e09ad80 [label="r0w0e0"]; z0xfffff8000e09ad80 -> z0xfffff8000af3b500; z0xfffff8000e0a2200 -> z0xfffff8000e09ad80; z0xfffff8000e0a2500 [shape=box,label="DEV\ngptid/f6600fef-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09ae80 [label="r0w0e0"]; z0xfffff8000e09ae80 -> z0xfffff8000e0a2300; z0xfffff8000e0a2500 -> z0xfffff8000e09ae80; z0xfffff8000e073200 [shape=box,label="DEV\ngpt/swap3\nr#4"]; z0xfffff8000e09b100 [label="r0w0e0"]; z0xfffff8000e09b100 -> z0xfffff8000e0a2c00; z0xfffff8000e073200 -> z0xfffff8000e09b100; z0xfffff8000e073500 [shape=box,label="DEV\ngptid/f623a95d-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09b200 [label="r0w0e0"]; z0xfffff8000e09b200 -> z0xfffff8000e073300; z0xfffff8000e073500 -> z0xfffff8000e09b200; z0xfffff8000e0c6a00 [shape=box,label="DEV\ngpt/gptboot3\nr#4"]; z0xfffff8000e09b280 [label="r0w0e0"]; z0xfffff8000e09b280 -> z0xfffff8000e073600; z0xfffff8000e0c6a00 -> z0xfffff8000e09b280; z0xfffff8000e0c6d00 [shape=box,label="DEV\ngptid/f5bd173e-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09b380 [label="r0w0e0"]; z0xfffff8000e09b380 -> z0xfffff8000e0c6b00; z0xfffff8000e0c6d00 -> z0xfffff8000e09b380; z0xfffff8000afcbd00 [shape=box,label="DEV\ngpt/swap2\nr#4"]; z0xfffff8000e09b580 [label="r0w0e0"]; z0xfffff8000e09b580 -> z0xfffff8000e0c7500; z0xfffff8000afcbd00 -> z0xfffff8000e09b580; z0xfffff800073fa500 [shape=box,label="DEV\ngptid/f57bb25e-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09b680 [label="r0w0e0"]; z0xfffff8000e09b680 -> z0xfffff80003f61e00; z0xfffff800073fa500 -> z0xfffff8000e09b680; z0xfffff8000e064900 [shape=box,label="DEV\ngpt/gptboot2\nr#4"]; z0xfffff8000e09b700 [label="r0w0e0"]; z0xfffff8000e09b700 -> z0xfffff800073fa800; z0xfffff8000e064900 -> z0xfffff8000e09b700; z0xfffff8000e07d700 [shape=box,label="DEV\ngptid/f52330df-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09b800 [label="r0w0e0"]; z0xfffff8000e09b800 -> z0xfffff8000e07d500; z0xfffff8000e07d700 -> z0xfffff8000e09b800; z0xfffff8000af3e700 [shape=box,label="DEV\ngpt/swap1\nr#4"]; z0xfffff8000e09ba00 [label="r0w0e0"]; z0xfffff8000e09ba00 -> z0xfffff800098a5900; z0xfffff8000af3e700 -> z0xfffff8000e09ba00; z0xfffff8000afcc700 [shape=box,label="DEV\ngptid/f4dbf3c8-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09bb00 [label="r0w0e0"]; z0xfffff8000e09bb00 -> z0xfffff8000e073900; z0xfffff8000afcc700 -> z0xfffff8000e09bb00; z0xfffff8000af3de00 [shape=box,label="DEV\ngpt/gptboot1\nr#4"]; z0xfffff8000e09bb80 [label="r0w0e0"]; z0xfffff8000e09bb80 -> z0xfffff8000afcc900; z0xfffff8000af3de00 -> z0xfffff8000e09bb80; z0xfffff8000e073d00 [shape=box,label="DEV\ngptid/f471cf71-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09bc80 [label="r0w0e0"]; z0xfffff8000e09bc80 -> z0xfffff8000e073b00; z0xfffff8000e073d00 -> z0xfffff8000e09bc80; z0xfffff8000e065100 [shape=box,label="DEV\ngpt/swap0\nr#4"]; z0xfffff8000e09be80 [label="r0w0e0"]; z0xfffff8000e09be80 -> z0xfffff8000e074500; z0xfffff8000e065100 -> z0xfffff8000e09be80; z0xfffff8000e0a3200 [shape=box,label="DEV\ngptid/f4308ed8-74a3-11e3-8040-00237d9e6e8a\nr#4"]; z0xfffff8000e09c000 [label="r0w0e0"]; z0xfffff8000e09c000 -> z0xfffff8000e0a3000; z0xfffff8000e0a3200 -> z0xfffff8000e09c000; z0xfffff8000e065500 [shape=box,label="DEV\ngpt/gptboot0\nr#4"]; z0xfffff8000e09c080 [label="r0w0e0"]; z0xfffff8000e09c080 -> z0xfffff8000e0a3300; z0xfffff8000e065500 -> z0xfffff8000e09c080; z0xfffff8000e0b4d00 [shape=box,label="DEV\nda5p3\nr#3"]; z0xfffff8000e09c500 [label="r0w0e0"]; z0xfffff8000e09c500 -> z0xfffff8000e0b4c00; z0xfffff8000e0b4d00 -> z0xfffff8000e09c500; z0xfffff8000e0b5000 [shape=box,label="DEV\nda5p2\nr#3"]; z0xfffff8000e070580 [label="r0w0e0"]; z0xfffff8000e070580 -> z0xfffff8000e0b4e00; z0xfffff8000e0b5000 -> z0xfffff8000e070580; z0xfffff8000af3d800 [shape=box,label="DEV\nda5p1\nr#3"]; z0xfffff8000e09c680 [label="r0w0e0"]; z0xfffff8000e09c680 -> z0xfffff8000e0b5100; z0xfffff8000af3d800 -> z0xfffff8000e09c680; z0xfffff8000e090600 [shape=box,label="DEV\nda4p3\nr#3"]; z0xfffff8000e09c800 [label="r0w0e0"]; z0xfffff8000e09c800 -> z0xfffff8000e090500; z0xfffff8000e090600 -> z0xfffff8000e09c800; z0xfffff8000e090800 [shape=box,label="DEV\nda4p2\nr#3"]; z0xfffff8000e088500 [label="r0w0e0"]; z0xfffff8000e088500 -> z0xfffff8000e090700; z0xfffff8000e090800 -> z0xfffff8000e088500; z0xfffff8000e074800 [shape=box,label="DEV\nda4p1\nr#3"]; z0xfffff8000e0ad300 [label="r0w0e0"]; z0xfffff8000e0ad300 -> z0xfffff8000e090900; z0xfffff8000e074800 -> z0xfffff8000e0ad300; z0xfffff8000e0b5800 [shape=box,label="DEV\nda3p3\nr#3"]; z0xfffff8000e0ad480 [label="r0w0e0"]; z0xfffff8000e0ad480 -> z0xfffff8000e0b5700; z0xfffff8000e0b5800 -> z0xfffff8000e0ad480; z0xfffff8000e0b5a00 [shape=box,label="DEV\nda3p2\nr#3"]; z0xfffff8000e052100 [label="r0w0e0"]; z0xfffff8000e052100 -> z0xfffff8000e0b5900; z0xfffff8000e0b5a00 -> z0xfffff8000e052100; z0xfffff8000af3d000 [shape=box,label="DEV\nda3p1\nr#3"]; z0xfffff8000e0d2000 [label="r0w0e0"]; z0xfffff8000e0d2000 -> z0xfffff8000e0b5b00; z0xfffff8000af3d000 -> z0xfffff8000e0d2000; z0xfffff8000e0c7900 [shape=box,label="DEV\nda2p3\nr#3"]; z0xfffff8000e0d2180 [label="r0w0e0"]; z0xfffff8000e0d2180 -> z0xfffff8000e0c7800; z0xfffff8000e0c7900 -> z0xfffff8000e0d2180; z0xfffff8000e0c7b00 [shape=box,label="DEV\nda2p2\nr#3"]; z0xfffff8000ae83880 [label="r0w0e0"]; z0xfffff8000ae83880 -> z0xfffff8000e0c7a00; z0xfffff8000e0c7b00 -> z0xfffff8000ae83880; z0xfffff8000e07db00 [shape=box,label="DEV\nda2p1\nr#3"]; z0xfffff8000e088680 [label="r0w0e0"]; z0xfffff8000e088680 -> z0xfffff8000e0c7c00; z0xfffff8000e07db00 -> z0xfffff8000e088680; z0xfffff8000ae21a00 [shape=box,label="DEV\nda1p3\nr#3"]; z0xfffff8000e070700 [label="r0w0e0"]; z0xfffff8000e070700 -> z0xfffff8000ae21c00; z0xfffff8000ae21a00 -> z0xfffff8000e070700; z0xfffff8000afcd800 [shape=box,label="DEV\nda1p2\nr#3"]; z0xfffff8000e052280 [label="r0w0e0"]; z0xfffff8000e052280 -> z0xfffff8000ae21800; z0xfffff8000afcd800 -> z0xfffff8000e052280; z0xfffff8000afccd00 [shape=box,label="DEV\nda1p1\nr#3"]; z0xfffff8000e052400 [label="r0w0e0"]; z0xfffff8000e052400 -> z0xfffff8000afcd600; z0xfffff8000afccd00 -> z0xfffff8000e052400; z0xfffff8000afcbe00 [shape=box,label="DEV\nda0p3\nr#3"]; z0xfffff8000e052580 [label="r0w0e0"]; z0xfffff8000e052580 -> z0xfffff8000afcc100; z0xfffff8000afcbe00 -> z0xfffff8000e052580; z0xfffff8000af3ea00 [shape=box,label="DEV\nda0p2\nr#3"]; z0xfffff8000e0ad600 [label="r0w0e0"]; z0xfffff8000e0ad600 -> z0xfffff8000af3e900; z0xfffff8000af3ea00 -> z0xfffff8000e0ad600; z0xfffff8000afca000 [shape=box,label="DEV\nda0p1\nr#3"]; z0xfffff8000e0ad780 [label="r0w0e0"]; z0xfffff8000e0ad780 -> z0xfffff8000af3eb00; z0xfffff8000afca000 -> z0xfffff8000e0ad780; z0xfffff8000e0b4a00 [shape=box,label="DEV\nda5\nr#2"]; z0xfffff8000e070780 [label="r0w0e0"]; z0xfffff8000e070780 -> z0xfffff8000ae1e700; z0xfffff8000e0b4a00 -> z0xfffff8000e070780; z0xfffff8000e090300 [shape=box,label="DEV\nda4\nr#2"]; z0xfffff8000ae81500 [label="r0w0e0"]; z0xfffff8000ae81500 -> z0xfffff8000ae1e100; z0xfffff8000e090300 -> z0xfffff8000ae81500; z0xfffff8000e0b5500 [shape=box,label="DEV\nda3\nr#2"]; z0xfffff8000e088800 [label="r0w0e0"]; z0xfffff8000e088800 -> z0xfffff800098a5a00; z0xfffff8000e0b5500 -> z0xfffff8000e088800; z0xfffff8000e0c7600 [shape=box,label="DEV\nda2\nr#2"]; z0xfffff8000e052700 [label="r0w0e0"]; z0xfffff8000e052700 -> z0xfffff8000af3e600; z0xfffff8000e0c7600 -> z0xfffff8000e052700; z0xfffff8000af3b100 [shape=box,label="DEV\nda1\nr#2"]; z0xfffff800098cdd80 [label="r0w0e0"]; z0xfffff800098cdd80 -> z0xfffff8000af3e000; z0xfffff8000af3b100 -> z0xfffff800098cdd80; z0xfffff8000afcc500 [shape=box,label="DEV\nda0\nr#2"]; z0xfffff800098cda80 [label="r0w0e0"]; z0xfffff800098cda80 -> z0xfffff8000af3d900; z0xfffff8000afcc500 -> z0xfffff800098cda80; z0xfffff8000af3cb00 [shape=box,label="DEV\ncd0\nr#2"]; z0xfffff8000ae80480 [label="r0w0e0"]; z0xfffff8000ae80480 -> z0xfffff8000af3d300; z0xfffff8000af3cb00 -> z0xfffff8000ae80480; z0xfffff8000ebd1600 [shape=box,label="ZFS::VDEV\nzfs::vdev\nr#4"]; z0xfffff8000e0bf400 [label="r1w1e1"]; z0xfffff8000e0bf400 -> z0xfffff8000e08f000; z0xfffff8000ebd1600 -> z0xfffff8000e0bf400; z0xfffff8000e0bf380 [label="r1w1e1"]; z0xfffff8000e0bf380 -> z0xfffff8000e08f700; z0xfffff8000ebd1600 -> z0xfffff8000e0bf380; z0xfffff8000e0bf300 [label="r1w1e1"]; z0xfffff8000e0bf300 -> z0xfffff8000e0a2300; z0xfffff8000ebd1600 -> z0xfffff8000e0bf300; z0xfffff8000e0bea00 [label="r1w1e1"]; z0xfffff8000e0bea00 -> z0xfffff8000e0c6b00; z0xfffff8000ebd1600 -> z0xfffff8000e0bea00; z0xfffff8000e0be980 [label="r1w1e1"]; z0xfffff8000e0be980 -> z0xfffff8000e07d500; z0xfffff8000ebd1600 -> z0xfffff8000e0be980; z0xfffff8000e050f00 [label="r1w1e1"]; z0xfffff8000e050f00 -> z0xfffff8000e073b00; z0xfffff8000ebd1600 -> z0xfffff8000e050f00; } kern.geom.conftxt: 0 DISK da5 146780121600 512 hd 255 sc 63 1 PART da5p3 143558337536 512 i 3 o 3221767168 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/f7a4d13a-74a3-11e3-8040-00237d9e6e8a 143558337536 512 i 0 o 0 1 PART da5p2 3221225472 512 i 2 o 541696 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL gpt/swap5 3221225472 512 i 0 o 0 1 PART da5p1 524288 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/f76af2cc-74a3-11e3-8040-00237d9e6e8a 524288 512 i 0 o 0 2 LABEL gpt/gptboot5 524288 512 i 0 o 0 0 DISK da4 146780121600 512 hd 255 sc 63 1 PART da4p3 143558337536 512 i 3 o 3221767168 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/f7043103-74a3-11e3-8040-00237d9e6e8a 143558337536 512 i 0 o 0 1 PART da4p2 3221225472 512 i 2 o 541696 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL gpt/swap4 3221225472 512 i 0 o 0 1 PART da4p1 524288 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/f6c16edb-74a3-11e3-8040-00237d9e6e8a 524288 512 i 0 o 0 2 LABEL gpt/gptboot4 524288 512 i 0 o 0 0 DISK da3 146780121600 512 hd 255 sc 63 1 PART da3p3 143558337536 512 i 3 o 3221767168 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/f6600fef-74a3-11e3-8040-00237d9e6e8a 143558337536 512 i 0 o 0 1 PART da3p2 3221225472 512 i 2 o 541696 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL gpt/swap3 3221225472 512 i 0 o 0 1 PART da3p1 524288 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/f623a95d-74a3-11e3-8040-00237d9e6e8a 524288 512 i 0 o 0 2 LABEL gpt/gptboot3 524288 512 i 0 o 0 0 DISK da2 146780121600 512 hd 255 sc 63 1 PART da2p3 143558337536 512 i 3 o 3221767168 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/f5bd173e-74a3-11e3-8040-00237d9e6e8a 143558337536 512 i 0 o 0 1 PART da2p2 3221225472 512 i 2 o 541696 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL gpt/swap2 3221225472 512 i 0 o 0 1 PART da2p1 524288 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/f57bb25e-74a3-11e3-8040-00237d9e6e8a 524288 512 i 0 o 0 2 LABEL gpt/gptboot2 524288 512 i 0 o 0 0 DISK da1 146780121600 512 hd 255 sc 63 1 PART da1p3 143558337536 512 i 3 o 3221767168 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/f52330df-74a3-11e3-8040-00237d9e6e8a 143558337536 512 i 0 o 0 1 PART da1p2 3221225472 512 i 2 o 541696 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL gpt/swap1 3221225472 512 i 0 o 0 1 PART da1p1 524288 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/f4dbf3c8-74a3-11e3-8040-00237d9e6e8a 524288 512 i 0 o 0 2 LABEL gpt/gptboot1 524288 512 i 0 o 0 0 DISK da0 146780121600 512 hd 255 sc 63 1 PART da0p3 143558337536 512 i 3 o 3221767168 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/f471cf71-74a3-11e3-8040-00237d9e6e8a 143558337536 512 i 0 o 0 1 PART da0p2 3221225472 512 i 2 o 541696 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL gpt/swap0 3221225472 512 i 0 o 0 1 PART da0p1 524288 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/f4308ed8-74a3-11e3-8040-00237d9e6e8a 524288 512 i 0 o 0 2 LABEL gpt/gptboot0 524288 512 i 0 o 0 0 DISK cd0 0 2048 hd 0 sc 0 kern.geom.debugflags: 0 kern.geom.notaste: 0 kern.geom.collectstats: 1 kern.geom.label.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.gpt.enable: 1 kern.geom.label.gptid.enable: 1 kern.geom.label.disk_ident.enable: 1 kern.geom.part.check_integrity: 1 kern.geom.raid.enable: 1 kern.geom.raid.aggressive_spare: 0 kern.geom.raid.debug: 0 kern.geom.raid.read_err_thresh: 10 kern.geom.raid.start_timeout: 30 kern.geom.raid.clean_time: 5 kern.geom.raid.disconnect_on_failure: 1 kern.geom.raid.name_format: 0 kern.geom.raid.idle_threshold: 1000000 kern.geom.raid.legacy_aliases: 1 kern.geom.raid.ddf.enable: 1 kern.geom.raid.intel.enable: 1 kern.geom.raid.jmicron.enable: 1 kern.geom.raid.nvidia.enable: 1 kern.geom.raid.promise.enable: 1 kern.geom.raid.sii.enable: 1 kern.geom.raid.concat.enable: 1 kern.geom.raid.raid0.enable: 1 kern.geom.raid.raid1.rebuild_slab_size: 1048576 kern.geom.raid.raid1.rebuild_fair_io: 20 kern.geom.raid.raid1.rebuild_cluster_idle: 100 kern.geom.raid.raid1.rebuild_meta_update: 1024 kern.geom.raid.raid1.enable: 1 kern.geom.raid.raid1e.rebuild_slab_size: 1048576 kern.geom.raid.raid1e.rebuild_fair_io: 20 kern.geom.raid.raid1e.rebuild_cluster_idle: 100 kern.geom.raid.raid1e.rebuild_meta_update: 1024 kern.geom.raid.raid1e.enable: 1 kern.geom.raid.raid5.enable: 1 kern.elf64.fallback_brand: -1 kern.elf64.nxstack: 1 kern.elf32.fallback_brand: 3 kern.elf32.nxstack: 1 kern.elf32.read_exec: 0 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init kern.init_shutdown_timeout: 120 kern.acct_suspend: 2 kern.acct_resume: 4 kern.acct_chkfreq: 15 kern.acct_configured: 0 kern.acct_suspended: 0 kern.cp_time: 1675366 79749892 1625346 183298 80230472 kern.cp_times: 261018 10493266 193063 19759 9465974 250977 9766695 183941 4359 10227070 259278 9748209 186754 4824 10233977 247299 9754175 186131 4971 10240466 157494 9919544 229828 17361 10108815 161377 10215089 218165 49537 9788874 155482 10040127 217898 76396 9943139 182441 9812787 209566 6091 10222157 kern.console: ttyv0,/ttyv0,uart,ttyv0, kern.consmute: 0 kern.consmsgbuf_size: 8192 kern.constty_wakeups_per_second: 5 kern.vty: sc kern.openfiles: 849 kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 166676115 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 350 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 340 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 340 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.choice: LAPIC(400) HPET(350) HPET1(340) HPET2(340) i8254(100) RTC(0) kern.eventtimer.singlemul: 2 kern.eventtimer.idletick: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.periodic: 0 kern.kq_calloutmax: 4096 kern.stackprot: 7 kern.ps_arg_cache_limit: 256 kern.disallow_high_osrel: 0 kern.lastpid: 19289 kern.randompid: 0 kern.ktrace.genio_size: 4096 kern.ktrace.request_pool: 100 kern.module_path: /boot/kernel;/boot/modules kern.malloc_count: 368 kern.ident: GENERIC kern.compiler_version: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 kern.maxusers: 1358 kern.supported_archs: amd64 i386 kern.conftxt: options CONFIG_AUTOGENERATED ident GENERIC machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options XENHVM options USB_DEBUG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ACPI_DMAR options SMP options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options PROCDESC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device mpr device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device vt device vt_vga device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device padlock_rng device rdrand_rng device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_via8233 device mmc device mmcsd device sdhci device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device hyperv device xenpci device vmx kern.features.scbus: 1 kern.features.compat_freebsd_32bit: 1 kern.features.ata_cam: 1 kern.features.nfscl: 1 kern.features.nfsd: 1 kern.features.geom_label: 1 kern.features.geom_part_bsd: 1 kern.features.geom_part_ebr: 1 kern.features.geom_part_ebr_compat: 1 kern.features.geom_part_gpt: 1 kern.features.geom_part_mbr: 1 kern.features.kposix_priority_scheduling: 1 kern.features.kdtrace_hooks: 1 kern.features.ktrace: 1 kern.features.compat_freebsd4: 1 kern.features.compat_freebsd5: 1 kern.features.compat_freebsd6: 1 kern.features.compat_freebsd7: 1 kern.features.hwpmc_hooks: 1 kern.features.stack: 1 kern.features.security_capability_mode: 1 kern.features.security_capabilities: 1 kern.features.process_descriptors: 1 kern.features.sysv_msg: 1 kern.features.sysv_sem: 1 kern.features.sysv_shm: 1 kern.features.posix_shm: 1 kern.features.inet: 1 kern.features.inet6: 1 kern.features.audit: 1 kern.features.security_mac: 1 kern.features.ffs_snapshot: 1 kern.features.softupdates: 1 kern.features.ufs_acl: 1 kern.features.ufs_gjournal: 1 kern.features.ufs_quota: 1 kern.features.ufs_quota64: 1 kern.features.linuxulator_v4l: 1 kern.features.linuxulator_v4l2: 1 kern.pid_max: 99999 kern.fallback_elf_brand: -1 kern.hwpmc.softevents: 16 kern.hwpmc.callchaindepth: 16 kern.hwpmc.hashsize: 1024 kern.hwpmc.nsamples: 1024 kern.hwpmc.mtxpoolsize: 2048 kern.hwpmc.logbuffersize: 4 kern.hwpmc.nbuffers: 1024 kern.kstack_pages: 4 kern.panic_reboot_wait_time: 15 kern.sync_on_panic: 0 kern.shutdown.show_busybufs: 0 kern.shutdown.poweroff_delay: 5000 kern.shutdown.kproc_shutdown_wait: 60 kern.shutdown.dumpdevname: gpt/swap0 kern.forcesigexit: 1 kern.sigqueue.max_pending_per_proc: 128 kern.sigqueue.preallocate: 1024 kern.sigqueue.overflow: 2183567 kern.sigqueue.alloc_fail: 0 kern.sugid_coredump: 0 kern.capmode_coredump: 0 kern.coredump: 1 kern.nodump_coredump: 0 kern.corefile: %N.core kern.fscale: 2048 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 24876 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1590263785 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 8349275 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 1680884271 kern.timecounter.tc.TSC.frequency: 2500140705 kern.timecounter.tc.TSC.quality: -1000 kern.timecounter.stepwarnings: 0 kern.timecounter.alloweddeviation: 5 kern.timecounter.hardware: HPET kern.timecounter.choice: TSC(-1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000) kern.timecounter.tick: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.smp_tsc: 0 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.tsc_shift: 1 kern.threads.max_threads_per_proc: 1500 kern.threads.max_threads_hits: 0 kern.ncallout: 18508 kern.callout_stat: 0 kern.sched.cpusetsize: 8 kern.sched.preemption: 1 kern.sched.name: ULE kern.sched.quantum: 94488 kern.sched.slice: 12 kern.sched.interact: 30 kern.sched.preempt_thresh: 80 kern.sched.static_boost: 152 kern.sched.idlespins: 10000 kern.sched.idlespinthresh: 157 kern.sched.affinity: 1 kern.sched.balance: 1 kern.sched.balance_interval: 127 kern.sched.steal_idle: 1 kern.sched.steal_thresh: 2 kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7 0, 1, 2, 3 4, 5, 6, 7 kern.ccpu: 0 kern.devstat.numdevs: 14 kern.devstat.generation: 570 kern.devstat.version: 6 kern.hintmode: 0 kern.kobj_methodcount: 232 kern.log_wakeups_per_second: 5 kern.msgbuf_show_timestamp: 0 kern.hz: 1000 kern.nbuf: 105332 kern.nswbuf: 256 kern.msgbufsize: 98304 kern.maxswzone: 0 kern.maxbcache: 0 kern.bio_transient_maxcnt: 1024 kern.maxtsiz: 134217728 kern.dfldsiz: 34359738368 kern.maxdsiz: 34359738368 kern.dflssiz: 8388608 kern.maxssiz: 536870912 kern.sgrowsiz: 131072 kern.vm_guest: none kern.log_console_output: 1 kern.log_console_add_linefeed: 0 kern.always_console_output: 0 kern.msgbuf: d[92200]: login_getclass: unknown class 'root' <118>Jul 24 21:29:44 thebighonker sshd[92200]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:44 thebighonker sshd[92200]: login_getclass: unknown class 'root' <118>Jul 24 21:29:44 thebighonker sshd[92206]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:29:45 thebighonker sshd[92207]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:45 thebighonker sshd[92207]: login_getclass: unknown class 'root' <118>Jul 24 21:29:45 thebighonker sshd[92207]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:45 thebighonker sshd[92207]: login_getclass: unknown class 'root' <118>Jul 24 21:29:45 thebighonker sshd[92207]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:45 thebighonker sshd[92207]: login_getclass: unknown class 'root' <118>Jul 24 21:29:46 thebighonker sshd[92207]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:46 thebighonker sshd[92207]: login_getclass: unknown class 'root' <118>Jul 24 21:29:46 thebighonker sshd[92207]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:46 thebighonker sshd[92207]: login_getclass: unknown class 'root' <118>Jul 24 21:29:46 thebighonker sshd[92207]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:46 thebighonker sshd[92207]: login_getclass: unknown class 'root' <118>Jul 24 21:29:46 thebighonker sshd[92207]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:46 thebighonker sshd[92207]: login_getclass: unknown class 'root' <118>Jul 24 21:29:46 thebighonker sshd[92208]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:29:47 thebighonker sshd[92209]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:47 thebighonker sshd[92209]: login_getclass: unknown class 'root' <118>Jul 24 21:29:47 thebighonker sshd[92209]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:47 thebighonker sshd[92209]: login_getclass: unknown class 'root' <118>Jul 24 21:29:47 thebighonker sshd[92209]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:47 thebighonker sshd[92209]: login_getclass: unknown class 'root' <118>Jul 24 21:29:47 thebighonker sshd[92209]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:47 thebighonker sshd[92209]: login_getclass: unknown class 'root' <118>Jul 24 21:29:48 thebighonker sshd[92209]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:48 thebighonker sshd[92209]: login_getclass: unknown class 'root' <118>Jul 24 21:29:48 thebighonker sshd[92209]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:48 thebighonker sshd[92209]: login_getclass: unknown class 'root' <118>Jul 24 21:29:48 thebighonker sshd[92209]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:48 thebighonker sshd[92209]: login_getclass: unknown class 'root' <118>Jul 24 21:29:48 thebighonker sshd[92210]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:29:49 thebighonker sshd[92211]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:49 thebighonker sshd[92211]: login_getclass: unknown class 'root' <118>Jul 24 21:29:49 thebighonker sshd[92211]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:49 thebighonker sshd[92211]: login_getclass: unknown class 'root' <118>Jul 24 21:29:49 thebighonker sshd[92211]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:49 thebighonker sshd[92211]: login_getclass: unknown class 'root' <118>Jul 24 21:29:49 thebighonker sshd[92211]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:49 thebighonker sshd[92211]: login_getclass: unknown class 'root' <118>Jul 24 21:29:49 thebighonker sshd[92211]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:49 thebighonker sshd[92211]: login_getclass: unknown class 'root' <118>Jul 24 21:29:49 thebighonker sshd[92211]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:49 thebighonker sshd[92211]: login_getclass: unknown class 'root' <118>Jul 24 21:29:50 thebighonker sshd[92211]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:50 thebighonker sshd[92211]: login_getclass: unknown class 'root' <118>Jul 24 21:29:50 thebighonker sshd[92213]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:29:51 thebighonker sshd[92214]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:51 thebighonker sshd[92214]: login_getclass: unknown class 'root' <118>Jul 24 21:29:51 thebighonker sshd[92214]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:51 thebighonker sshd[92214]: login_getclass: unknown class 'root' <118>Jul 24 21:29:51 thebighonker sshd[92214]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:51 thebighonker sshd[92214]: login_getclass: unknown class 'root' <118>Jul 24 21:29:51 thebighonker sshd[92214]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:51 thebighonker sshd[92214]: login_getclass: unknown class 'root' <118>Jul 24 21:29:51 thebighonker sshd[92214]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:51 thebighonker sshd[92214]: login_getclass: unknown class 'root' <118>Jul 24 21:29:51 thebighonker sshd[92214]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:51 thebighonker sshd[92214]: login_getclass: unknown class 'root' <118>Jul 24 21:29:52 thebighonker sshd[92214]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:52 thebighonker sshd[92214]: login_getclass: unknown class 'root' <118>Jul 24 21:29:52 thebighonker sshd[92216]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:29:53 thebighonker sshd[92217]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:53 thebighonker sshd[92217]: login_getclass: unknown class 'root' <118>Jul 24 21:29:53 thebighonker sshd[92217]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:53 thebighonker sshd[92217]: login_getclass: unknown class 'root' <118>Jul 24 21:29:53 thebighonker sshd[92217]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:53 thebighonker sshd[92217]: login_getclass: unknown class 'root' <118>Jul 24 21:29:54 thebighonker sshd[92217]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:54 thebighonker sshd[92217]: login_getclass: unknown class 'root' <118>Jul 24 21:29:54 thebighonker sshd[92217]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:54 thebighonker sshd[92217]: login_getclass: unknown class 'root' <118>Jul 24 21:29:54 thebighonker sshd[92217]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:54 thebighonker sshd[92217]: login_getclass: unknown class 'root' <118>Jul 24 21:29:54 thebighonker sshd[92217]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:54 thebighonker sshd[92217]: login_getclass: unknown class 'root' <118>Jul 24 21:29:54 thebighonker sshd[92225]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:29:56 thebighonker sshd[92226]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:56 thebighonker sshd[92226]: login_getclass: unknown class 'root' <118>Jul 24 21:29:56 thebighonker sshd[92226]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:56 thebighonker sshd[92226]: login_getclass: unknown class 'root' <118>Jul 24 21:29:56 thebighonker sshd[92226]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:56 thebighonker sshd[92226]: login_getclass: unknown class 'root' <118>Jul 24 21:29:56 thebighonker sshd[92226]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:56 thebighonker sshd[92226]: login_getclass: unknown class 'root' <118>Jul 24 21:29:56 thebighonker sshd[92226]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:56 thebighonker sshd[92226]: login_getclass: unknown class 'root' <118>Jul 24 21:29:56 thebighonker sshd[92226]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:56 thebighonker sshd[92226]: login_getclass: unknown class 'root' <118>Jul 24 21:29:56 thebighonker sshd[92226]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:56 thebighonker sshd[92226]: login_getclass: unknown class 'root' <118>Jul 24 21:29:57 thebighonker sshd[92227]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:29:57 thebighonker sshd[92228]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:57 thebighonker sshd[92228]: login_getclass: unknown class 'root' <118>Jul 24 21:29:58 thebighonker sshd[92228]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:58 thebighonker sshd[92228]: login_getclass: unknown class 'root' <118>Jul 24 21:29:58 thebighonker sshd[92228]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:58 thebighonker sshd[92228]: login_getclass: unknown class 'root' <118>Jul 24 21:29:58 thebighonker sshd[92228]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:58 thebighonker sshd[92228]: login_getclass: unknown class 'root' <118>Jul 24 21:29:58 thebighonker sshd[92228]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:58 thebighonker sshd[92228]: login_getclass: unknown class 'root' <118>Jul 24 21:29:58 thebighonker sshd[92228]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:58 thebighonker sshd[92228]: login_getclass: unknown class 'root' <118>Jul 24 21:29:58 thebighonker sshd[92228]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:29:58 thebighonker sshd[92228]: login_getclass: unknown class 'root' <118>Jul 24 21:29:59 thebighonker sshd[92234]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:00 thebighonker sshd[92235]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:00 thebighonker sshd[92235]: login_getclass: unknown class 'root' <118>Jul 24 21:30:00 thebighonker sshd[92235]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:00 thebighonker sshd[92235]: login_getclass: unknown class 'root' <118>Jul 24 21:30:00 thebighonker sshd[92235]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:00 thebighonker sshd[92235]: login_getclass: unknown class 'root' <118>Jul 24 21:30:00 thebighonker sshd[92235]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:00 thebighonker sshd[92235]: login_getclass: unknown class 'root' <118>Jul 24 21:30:00 thebighonker sshd[92235]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:00 thebighonker sshd[92235]: login_getclass: unknown class 'root' <118>Jul 24 21:30:00 thebighonker sshd[92235]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:00 thebighonker sshd[92235]: login_getclass: unknown class 'root' <118>Jul 24 21:30:00 thebighonker sshd[92235]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:00 thebighonker sshd[92235]: login_getclass: unknown class 'root' <118>Jul 24 21:30:01 thebighonker sshd[92257]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:03 thebighonker sshd[92260]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:03 thebighonker sshd[92260]: login_getclass: unknown class 'root' <118>Jul 24 21:30:03 thebighonker sshd[92260]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:03 thebighonker sshd[92260]: login_getclass: unknown class 'root' <118>Jul 24 21:30:03 thebighonker sshd[92260]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:03 thebighonker sshd[92260]: login_getclass: unknown class 'root' <118>Jul 24 21:30:04 thebighonker sshd[92260]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:04 thebighonker sshd[92260]: login_getclass: unknown class 'root' <118>Jul 24 21:30:04 thebighonker sshd[92260]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:04 thebighonker sshd[92260]: login_getclass: unknown class 'root' <118>Jul 24 21:30:04 thebighonker sshd[92260]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:04 thebighonker sshd[92260]: login_getclass: unknown class 'root' <118>Jul 24 21:30:05 thebighonker sshd[92260]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:05 thebighonker sshd[92260]: login_getclass: unknown class 'root' <118>Jul 24 21:30:05 thebighonker sshd[92262]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:07 thebighonker sshd[92263]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:07 thebighonker sshd[92263]: login_getclass: unknown class 'root' <118>Jul 24 21:30:08 thebighonker sshd[92263]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:08 thebighonker sshd[92263]: login_getclass: unknown class 'root' <118>Jul 24 21:30:08 thebighonker sshd[92263]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:08 thebighonker sshd[92263]: login_getclass: unknown class 'root' <118>Jul 24 21:30:08 thebighonker sshd[92263]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:08 thebighonker sshd[92263]: login_getclass: unknown class 'root' <118>Jul 24 21:30:08 thebighonker sshd[92263]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:08 thebighonker sshd[92263]: login_getclass: unknown class 'root' <118>Jul 24 21:30:08 thebighonker sshd[92263]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:08 thebighonker sshd[92263]: login_getclass: unknown class 'root' <118>Jul 24 21:30:08 thebighonker sshd[92263]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:08 thebighonker sshd[92263]: login_getclass: unknown class 'root' <118>Jul 24 21:30:08 thebighonker sshd[92265]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:09 thebighonker sshd[92266]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:09 thebighonker sshd[92266]: login_getclass: unknown class 'root' <118>Jul 24 21:30:09 thebighonker sshd[92266]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:09 thebighonker sshd[92266]: login_getclass: unknown class 'root' <118>Jul 24 21:30:09 thebighonker sshd[92266]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:09 thebighonker sshd[92266]: login_getclass: unknown class 'root' <118>Jul 24 21:30:09 thebighonker sshd[92266]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:09 thebighonker sshd[92266]: login_getclass: unknown class 'root' <118>Jul 24 21:30:09 thebighonker sshd[92266]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:09 thebighonker sshd[92266]: login_getclass: unknown class 'root' <118>Jul 24 21:30:10 thebighonker sshd[92266]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:10 thebighonker sshd[92266]: login_getclass: unknown class 'root' <118>Jul 24 21:30:10 thebighonker sshd[92266]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:10 thebighonker sshd[92266]: login_getclass: unknown class 'root' <118>Jul 24 21:30:10 thebighonker sshd[92267]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:11 thebighonker sshd[92268]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:11 thebighonker sshd[92268]: login_getclass: unknown class 'root' <118>Jul 24 21:30:11 thebighonker sshd[92268]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:11 thebighonker sshd[92268]: login_getclass: unknown class 'root' <118>Jul 24 21:30:11 thebighonker sshd[92268]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:11 thebighonker sshd[92268]: login_getclass: unknown class 'root' <118>Jul 24 21:30:11 thebighonker sshd[92268]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:11 thebighonker sshd[92268]: login_getclass: unknown class 'root' <118>Jul 24 21:30:11 thebighonker sshd[92268]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:11 thebighonker sshd[92268]: login_getclass: unknown class 'root' <118>Jul 24 21:30:11 thebighonker sshd[92268]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:11 thebighonker sshd[92268]: login_getclass: unknown class 'root' <118>Jul 24 21:30:11 thebighonker sshd[92268]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:11 thebighonker sshd[92268]: login_getclass: unknown class 'root' <118>Jul 24 21:30:12 thebighonker sshd[92278]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:13 thebighonker sshd[92279]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:13 thebighonker sshd[92279]: login_getclass: unknown class 'root' <118>Jul 24 21:30:13 thebighonker sshd[92279]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:13 thebighonker sshd[92279]: login_getclass: unknown class 'root' <118>Jul 24 21:30:13 thebighonker sshd[92279]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:13 thebighonker sshd[92279]: login_getclass: unknown class 'root' <118>Jul 24 21:30:13 thebighonker sshd[92279]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:13 thebighonker sshd[92279]: login_getclass: unknown class 'root' <118>Jul 24 21:30:13 thebighonker sshd[92279]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:13 thebighonker sshd[92279]: login_getclass: unknown class 'root' <118>Jul 24 21:30:13 thebighonker sshd[92279]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:13 thebighonker sshd[92279]: login_getclass: unknown class 'root' <118>Jul 24 21:30:13 thebighonker sshd[92279]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:13 thebighonker sshd[92279]: login_getclass: unknown class 'root' <118>Jul 24 21:30:13 thebighonker sshd[92280]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:14 thebighonker sshd[92281]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:14 thebighonker sshd[92281]: login_getclass: unknown class 'root' <118>Jul 24 21:30:14 thebighonker sshd[92281]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:14 thebighonker sshd[92281]: login_getclass: unknown class 'root' <118>Jul 24 21:30:14 thebighonker sshd[92281]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:14 thebighonker sshd[92281]: login_getclass: unknown class 'root' <118>Jul 24 21:30:14 thebighonker sshd[92281]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:14 thebighonker sshd[92281]: login_getclass: unknown class 'root' <118>Jul 24 21:30:14 thebighonker sshd[92281]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:14 thebighonker sshd[92281]: login_getclass: unknown class 'root' <118>Jul 24 21:30:15 thebighonker sshd[92281]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:15 thebighonker sshd[92281]: login_getclass: unknown class 'root' <118>Jul 24 21:30:15 thebighonker sshd[92281]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:15 thebighonker sshd[92281]: login_getclass: unknown class 'root' <118>Jul 24 21:30:15 thebighonker sshd[92284]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:16 thebighonker sshd[92285]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:16 thebighonker sshd[92285]: login_getclass: unknown class 'root' <118>Jul 24 21:30:16 thebighonker sshd[92285]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:16 thebighonker sshd[92285]: login_getclass: unknown class 'root' <118>Jul 24 21:30:16 thebighonker sshd[92285]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:16 thebighonker sshd[92285]: login_getclass: unknown class 'root' <118>Jul 24 21:30:16 thebighonker sshd[92285]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:16 thebighonker sshd[92285]: login_getclass: unknown class 'root' <118>Jul 24 21:30:16 thebighonker sshd[92285]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:16 thebighonker sshd[92285]: login_getclass: unknown class 'root' <118>Jul 24 21:30:16 thebighonker sshd[92285]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:16 thebighonker sshd[92285]: login_getclass: unknown class 'root' <118>Jul 24 21:30:17 thebighonker sshd[92285]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:17 thebighonker sshd[92285]: login_getclass: unknown class 'root' <118>Jul 24 21:30:17 thebighonker sshd[92286]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:18 thebighonker sshd[92287]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:18 thebighonker sshd[92287]: login_getclass: unknown class 'root' <118>Jul 24 21:30:18 thebighonker sshd[92287]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:18 thebighonker sshd[92287]: login_getclass: unknown class 'root' <118>Jul 24 21:30:18 thebighonker sshd[92287]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:18 thebighonker sshd[92287]: login_getclass: unknown class 'root' <118>Jul 24 21:30:18 thebighonker sshd[92287]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:18 thebighonker sshd[92287]: login_getclass: unknown class 'root' <118>Jul 24 21:30:18 thebighonker sshd[92287]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:18 thebighonker sshd[92287]: login_getclass: unknown class 'root' <118>Jul 24 21:30:18 thebighonker sshd[92287]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:18 thebighonker sshd[92287]: login_getclass: unknown class 'root' <118>Jul 24 21:30:19 thebighonker sshd[92287]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:19 thebighonker sshd[92287]: login_getclass: unknown class 'root' <118>Jul 24 21:30:19 thebighonker sshd[92288]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:20 thebighonker sshd[92289]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:20 thebighonker sshd[92289]: login_getclass: unknown class 'root' <118>Jul 24 21:30:20 thebighonker sshd[92289]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:20 thebighonker sshd[92289]: login_getclass: unknown class 'root' <118>Jul 24 21:30:20 thebighonker sshd[92289]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:20 thebighonker sshd[92289]: login_getclass: unknown class 'root' <118>Jul 24 21:30:20 thebighonker sshd[92289]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:20 thebighonker sshd[92289]: login_getclass: unknown class 'root' <118>Jul 24 21:30:20 thebighonker sshd[92289]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:20 thebighonker sshd[92289]: login_getclass: unknown class 'root' <118>Jul 24 21:30:20 thebighonker sshd[92289]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:20 thebighonker sshd[92289]: login_getclass: unknown class 'root' <118>Jul 24 21:30:21 thebighonker sshd[92289]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:21 thebighonker sshd[92289]: login_getclass: unknown class 'root' <118>Jul 24 21:30:22 thebighonker sshd[92290]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:22 thebighonker sshd[92291]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:22 thebighonker sshd[92291]: login_getclass: unknown class 'root' <118>Jul 24 21:30:22 thebighonker sshd[92291]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:22 thebighonker sshd[92291]: login_getclass: unknown class 'root' <118>Jul 24 21:30:23 thebighonker sshd[92291]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:23 thebighonker sshd[92291]: login_getclass: unknown class 'root' <118>Jul 24 21:30:23 thebighonker sshd[92291]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:23 thebighonker sshd[92291]: login_getclass: unknown class 'root' <118>Jul 24 21:30:23 thebighonker sshd[92291]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:23 thebighonker sshd[92291]: login_getclass: unknown class 'root' <118>Jul 24 21:30:23 thebighonker sshd[92291]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:23 thebighonker sshd[92291]: login_getclass: unknown class 'root' <118>Jul 24 21:30:23 thebighonker sshd[92291]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:23 thebighonker sshd[92291]: login_getclass: unknown class 'root' <118>Jul 24 21:30:23 thebighonker sshd[92293]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:24 thebighonker sshd[92294]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:24 thebighonker sshd[92294]: login_getclass: unknown class 'root' <118>Jul 24 21:30:25 thebighonker sshd[92294]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:25 thebighonker sshd[92294]: login_getclass: unknown class 'root' <118>Jul 24 21:30:25 thebighonker sshd[92294]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:25 thebighonker sshd[92294]: login_getclass: unknown class 'root' <118>Jul 24 21:30:25 thebighonker sshd[92294]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:25 thebighonker sshd[92294]: login_getclass: unknown class 'root' <118>Jul 24 21:30:25 thebighonker sshd[92294]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:25 thebighonker sshd[92294]: login_getclass: unknown class 'root' <118>Jul 24 21:30:25 thebighonker sshd[92294]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:25 thebighonker sshd[92294]: login_getclass: unknown class 'root' <118>Jul 24 21:30:25 thebighonker sshd[92294]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:25 thebighonker sshd[92294]: login_getclass: unknown class 'root' <118>Jul 24 21:30:26 thebighonker sshd[92295]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:26 thebighonker sshd[92296]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:26 thebighonker sshd[92296]: login_getclass: unknown class 'root' <118>Jul 24 21:30:27 thebighonker sshd[92296]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:27 thebighonker sshd[92296]: login_getclass: unknown class 'root' <118>Jul 24 21:30:27 thebighonker sshd[92296]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:27 thebighonker sshd[92296]: login_getclass: unknown class 'root' <118>Jul 24 21:30:27 thebighonker sshd[92296]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:27 thebighonker sshd[92296]: login_getclass: unknown class 'root' <118>Jul 24 21:30:27 thebighonker sshd[92296]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:27 thebighonker sshd[92296]: login_getclass: unknown class 'root' <118>Jul 24 21:30:27 thebighonker sshd[92296]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:27 thebighonker sshd[92296]: login_getclass: unknown class 'root' <118>Jul 24 21:30:27 thebighonker sshd[92296]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:27 thebighonker sshd[92296]: login_getclass: unknown class 'root' <118>Jul 24 21:30:27 thebighonker sshd[92297]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:28 thebighonker sshd[92298]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:28 thebighonker sshd[92298]: login_getclass: unknown class 'root' <118>Jul 24 21:30:28 thebighonker sshd[92298]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:28 thebighonker sshd[92298]: login_getclass: unknown class 'root' <118>Jul 24 21:30:28 thebighonker sshd[92298]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:28 thebighonker sshd[92298]: login_getclass: unknown class 'root' <118>Jul 24 21:30:28 thebighonker sshd[92298]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:28 thebighonker sshd[92298]: login_getclass: unknown class 'root' <118>Jul 24 21:30:28 thebighonker sshd[92298]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:28 thebighonker sshd[92298]: login_getclass: unknown class 'root' <118>Jul 24 21:30:28 thebighonker sshd[92298]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:28 thebighonker sshd[92298]: login_getclass: unknown class 'root' <118>Jul 24 21:30:29 thebighonker sshd[92298]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:29 thebighonker sshd[92298]: login_getclass: unknown class 'root' <118>Jul 24 21:30:29 thebighonker sshd[92299]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:30 thebighonker sshd[92300]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:30 thebighonker sshd[92300]: login_getclass: unknown class 'root' <118>Jul 24 21:30:30 thebighonker sshd[92300]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:30 thebighonker sshd[92300]: login_getclass: unknown class 'root' <118>Jul 24 21:30:30 thebighonker sshd[92300]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:30 thebighonker sshd[92300]: login_getclass: unknown class 'root' <118>Jul 24 21:30:30 thebighonker sshd[92300]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:30 thebighonker sshd[92300]: login_getclass: unknown class 'root' <118>Jul 24 21:30:30 thebighonker sshd[92300]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:30 thebighonker sshd[92300]: login_getclass: unknown class 'root' <118>Jul 24 21:30:30 thebighonker sshd[92300]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:30 thebighonker sshd[92300]: login_getclass: unknown class 'root' <118>Jul 24 21:30:30 thebighonker sshd[92300]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:30 thebighonker sshd[92300]: login_getclass: unknown class 'root' <118>Jul 24 21:30:30 thebighonker sshd[92301]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:31 thebighonker sshd[92302]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:31 thebighonker sshd[92302]: login_getclass: unknown class 'root' <118>Jul 24 21:30:31 thebighonker sshd[92302]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:31 thebighonker sshd[92302]: login_getclass: unknown class 'root' <118>Jul 24 21:30:31 thebighonker sshd[92302]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:31 thebighonker sshd[92302]: login_getclass: unknown class 'root' <118>Jul 24 21:30:32 thebighonker sshd[92302]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:32 thebighonker sshd[92302]: login_getclass: unknown class 'root' <118>Jul 24 21:30:32 thebighonker sshd[92302]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:32 thebighonker sshd[92302]: login_getclass: unknown class 'root' <118>Jul 24 21:30:32 thebighonker sshd[92302]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:32 thebighonker sshd[92302]: login_getclass: unknown class 'root' <118>Jul 24 21:30:32 thebighonker sshd[92302]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:32 thebighonker sshd[92302]: login_getclass: unknown class 'root' <118>Jul 24 21:30:32 thebighonker sshd[92304]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:34 thebighonker sshd[92305]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:34 thebighonker sshd[92305]: login_getclass: unknown class 'root' <118>Jul 24 21:30:34 thebighonker sshd[92305]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:34 thebighonker sshd[92305]: login_getclass: unknown class 'root' <118>Jul 24 21:30:34 thebighonker sshd[92305]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:34 thebighonker sshd[92305]: login_getclass: unknown class 'root' <118>Jul 24 21:30:34 thebighonker sshd[92305]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:34 thebighonker sshd[92305]: login_getclass: unknown class 'root' <118>Jul 24 21:30:34 thebighonker sshd[92305]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:34 thebighonker sshd[92305]: login_getclass: unknown class 'root' <118>Jul 24 21:30:34 thebighonker sshd[92305]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:34 thebighonker sshd[92305]: login_getclass: unknown class 'root' <118>Jul 24 21:30:34 thebighonker sshd[92305]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:34 thebighonker sshd[92305]: login_getclass: unknown class 'root' <118>Jul 24 21:30:35 thebighonker sshd[92306]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:35 thebighonker sshd[92307]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:35 thebighonker sshd[92307]: login_getclass: unknown class 'root' <118>Jul 24 21:30:36 thebighonker sshd[92307]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:36 thebighonker sshd[92307]: login_getclass: unknown class 'root' <118>Jul 24 21:30:36 thebighonker sshd[92307]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:36 thebighonker sshd[92307]: login_getclass: unknown class 'root' <118>Jul 24 21:30:36 thebighonker sshd[92307]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:36 thebighonker sshd[92307]: login_getclass: unknown class 'root' <118>Jul 24 21:30:36 thebighonker sshd[92307]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:36 thebighonker sshd[92307]: login_getclass: unknown class 'root' <118>Jul 24 21:30:36 thebighonker sshd[92307]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:36 thebighonker sshd[92307]: login_getclass: unknown class 'root' <118>Jul 24 21:30:36 thebighonker sshd[92307]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:36 thebighonker sshd[92307]: login_getclass: unknown class 'root' <118>Jul 24 21:30:37 thebighonker sshd[92308]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:38 thebighonker sshd[92309]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:38 thebighonker sshd[92309]: login_getclass: unknown class 'root' <118>Jul 24 21:30:38 thebighonker sshd[92309]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:38 thebighonker sshd[92309]: login_getclass: unknown class 'root' <118>Jul 24 21:30:38 thebighonker sshd[92309]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:38 thebighonker sshd[92309]: login_getclass: unknown class 'root' <118>Jul 24 21:30:38 thebighonker sshd[92309]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:38 thebighonker sshd[92309]: login_getclass: unknown class 'root' <118>Jul 24 21:30:38 thebighonker sshd[92309]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:38 thebighonker sshd[92309]: login_getclass: unknown class 'root' <118>Jul 24 21:30:38 thebighonker sshd[92309]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:38 thebighonker sshd[92309]: login_getclass: unknown class 'root' <118>Jul 24 21:30:39 thebighonker sshd[92309]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:39 thebighonker sshd[92309]: login_getclass: unknown class 'root' <118>Jul 24 21:30:39 thebighonker sshd[92310]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:40 thebighonker sshd[92311]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:40 thebighonker sshd[92311]: login_getclass: unknown class 'root' <118>Jul 24 21:30:40 thebighonker sshd[92311]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:40 thebighonker sshd[92311]: login_getclass: unknown class 'root' <118>Jul 24 21:30:40 thebighonker sshd[92311]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:40 thebighonker sshd[92311]: login_getclass: unknown class 'root' <118>Jul 24 21:30:41 thebighonker sshd[92311]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:41 thebighonker sshd[92311]: login_getclass: unknown class 'root' <118>Jul 24 21:30:41 thebighonker sshd[92311]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:41 thebighonker sshd[92311]: login_getclass: unknown class 'root' <118>Jul 24 21:30:41 thebighonker sshd[92311]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:41 thebighonker sshd[92311]: login_getclass: unknown class 'root' <118>Jul 24 21:30:41 thebighonker sshd[92311]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:41 thebighonker sshd[92311]: login_getclass: unknown class 'root' <118>Jul 24 21:30:41 thebighonker sshd[92313]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:42 thebighonker sshd[92314]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:42 thebighonker sshd[92314]: login_getclass: unknown class 'root' <118>Jul 24 21:30:42 thebighonker sshd[92314]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:42 thebighonker sshd[92314]: login_getclass: unknown class 'root' <118>Jul 24 21:30:42 thebighonker sshd[92314]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:42 thebighonker sshd[92314]: login_getclass: unknown class 'root' <118>Jul 24 21:30:42 thebighonker sshd[92314]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:42 thebighonker sshd[92314]: login_getclass: unknown class 'root' <118>Jul 24 21:30:43 thebighonker sshd[92314]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:43 thebighonker sshd[92314]: login_getclass: unknown class 'root' <118>Jul 24 21:30:43 thebighonker sshd[92314]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:43 thebighonker sshd[92314]: login_getclass: unknown class 'root' <118>Jul 24 21:30:43 thebighonker sshd[92314]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:43 thebighonker sshd[92314]: login_getclass: unknown class 'root' <118>Jul 24 21:30:43 thebighonker sshd[92317]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:44 thebighonker sshd[92318]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:44 thebighonker sshd[92318]: login_getclass: unknown class 'root' <118>Jul 24 21:30:44 thebighonker sshd[92318]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:44 thebighonker sshd[92318]: login_getclass: unknown class 'root' <118>Jul 24 21:30:44 thebighonker sshd[92318]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:44 thebighonker sshd[92318]: login_getclass: unknown class 'root' <118>Jul 24 21:30:44 thebighonker sshd[92318]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:44 thebighonker sshd[92318]: login_getclass: unknown class 'root' <118>Jul 24 21:30:44 thebighonker sshd[92318]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:44 thebighonker sshd[92318]: login_getclass: unknown class 'root' <118>Jul 24 21:30:44 thebighonker sshd[92318]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:44 thebighonker sshd[92318]: login_getclass: unknown class 'root' <118>Jul 24 21:30:45 thebighonker sshd[92318]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:45 thebighonker sshd[92318]: login_getclass: unknown class 'root' <118>Jul 24 21:30:45 thebighonker sshd[92322]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:46 thebighonker sshd[92323]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:46 thebighonker sshd[92323]: login_getclass: unknown class 'root' <118>Jul 24 21:30:47 thebighonker sshd[92323]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:47 thebighonker sshd[92323]: login_getclass: unknown class 'root' <118>Jul 24 21:30:47 thebighonker sshd[92323]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:47 thebighonker sshd[92323]: login_getclass: unknown class 'root' <118>Jul 24 21:30:47 thebighonker sshd[92323]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:47 thebighonker sshd[92323]: login_getclass: unknown class 'root' <118>Jul 24 21:30:47 thebighonker sshd[92323]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:47 thebighonker sshd[92323]: login_getclass: unknown class 'root' <118>Jul 24 21:30:48 thebighonker sshd[92323]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:48 thebighonker sshd[92323]: login_getclass: unknown class 'root' <118>Jul 24 21:30:48 thebighonker sshd[92323]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:48 thebighonker sshd[92323]: login_getclass: unknown class 'root' <118>Jul 24 21:30:48 thebighonker sshd[92324]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:50 thebighonker sshd[92326]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:50 thebighonker sshd[92326]: login_getclass: unknown class 'root' <118>Jul 24 21:30:50 thebighonker sshd[92326]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:50 thebighonker sshd[92326]: login_getclass: unknown class 'root' <118>Jul 24 21:30:50 thebighonker sshd[92326]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:50 thebighonker sshd[92326]: login_getclass: unknown class 'root' <118>Jul 24 21:30:50 thebighonker sshd[92326]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:50 thebighonker sshd[92326]: login_getclass: unknown class 'root' <118>Jul 24 21:30:51 thebighonker sshd[92326]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:51 thebighonker sshd[92326]: login_getclass: unknown class 'root' <118>Jul 24 21:30:51 thebighonker sshd[92326]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:51 thebighonker sshd[92326]: login_getclass: unknown class 'root' <118>Jul 24 21:30:51 thebighonker sshd[92326]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:51 thebighonker sshd[92326]: login_getclass: unknown class 'root' <118>Jul 24 21:30:52 thebighonker sshd[92327]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:53 thebighonker sshd[92328]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:53 thebighonker sshd[92328]: login_getclass: unknown class 'root' <118>Jul 24 21:30:53 thebighonker sshd[92328]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:53 thebighonker sshd[92328]: login_getclass: unknown class 'root' <118>Jul 24 21:30:53 thebighonker sshd[92328]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:53 thebighonker sshd[92328]: login_getclass: unknown class 'root' <118>Jul 24 21:30:53 thebighonker sshd[92328]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:53 thebighonker sshd[92328]: login_getclass: unknown class 'root' <118>Jul 24 21:30:54 thebighonker sshd[92328]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:54 thebighonker sshd[92328]: login_getclass: unknown class 'root' <118>Jul 24 21:30:54 thebighonker sshd[92328]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:54 thebighonker sshd[92328]: login_getclass: unknown class 'root' <118>Jul 24 21:30:54 thebighonker sshd[92328]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:54 thebighonker sshd[92328]: login_getclass: unknown class 'root' <118>Jul 24 21:30:55 thebighonker sshd[92329]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:55 thebighonker sshd[92330]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:55 thebighonker sshd[92330]: login_getclass: unknown class 'root' <118>Jul 24 21:30:56 thebighonker sshd[92330]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:56 thebighonker sshd[92330]: login_getclass: unknown class 'root' <118>Jul 24 21:30:56 thebighonker sshd[92330]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:56 thebighonker sshd[92330]: login_getclass: unknown class 'root' <118>Jul 24 21:30:56 thebighonker sshd[92330]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:56 thebighonker sshd[92330]: login_getclass: unknown class 'root' <118>Jul 24 21:30:56 thebighonker sshd[92330]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:56 thebighonker sshd[92330]: login_getclass: unknown class 'root' <118>Jul 24 21:30:56 thebighonker sshd[92330]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:56 thebighonker sshd[92330]: login_getclass: unknown class 'root' <118>Jul 24 21:30:57 thebighonker sshd[92330]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:57 thebighonker sshd[92330]: login_getclass: unknown class 'root' <118>Jul 24 21:30:57 thebighonker sshd[92331]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:30:58 thebighonker sshd[92332]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:58 thebighonker sshd[92332]: login_getclass: unknown class 'root' <118>Jul 24 21:30:58 thebighonker sshd[92332]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:58 thebighonker sshd[92332]: login_getclass: unknown class 'root' <118>Jul 24 21:30:58 thebighonker sshd[92332]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:58 thebighonker sshd[92332]: login_getclass: unknown class 'root' <118>Jul 24 21:30:58 thebighonker sshd[92332]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:58 thebighonker sshd[92332]: login_getclass: unknown class 'root' <118>Jul 24 21:30:58 thebighonker sshd[92332]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:58 thebighonker sshd[92332]: login_getclass: unknown class 'root' <118>Jul 24 21:30:58 thebighonker sshd[92332]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:58 thebighonker sshd[92332]: login_getclass: unknown class 'root' <118>Jul 24 21:30:59 thebighonker sshd[92332]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:30:59 thebighonker sshd[92332]: login_getclass: unknown class 'root' <118>Jul 24 21:30:59 thebighonker sshd[92335]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:31:00 thebighonker sshd[92340]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:00 thebighonker sshd[92340]: login_getclass: unknown class 'root' <118>Jul 24 21:31:00 thebighonker sshd[92340]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:00 thebighonker sshd[92340]: login_getclass: unknown class 'root' <118>Jul 24 21:31:00 thebighonker sshd[92340]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:00 thebighonker sshd[92340]: login_getclass: unknown class 'root' <118>Jul 24 21:31:00 thebighonker sshd[92340]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:00 thebighonker sshd[92340]: login_getclass: unknown class 'root' <118>Jul 24 21:31:00 thebighonker sshd[92340]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:00 thebighonker sshd[92340]: login_getclass: unknown class 'root' <118>Jul 24 21:31:01 thebighonker sshd[92340]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:01 thebighonker sshd[92340]: login_getclass: unknown class 'root' <118>Jul 24 21:31:01 thebighonker sshd[92340]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:01 thebighonker sshd[92340]: login_getclass: unknown class 'root' <118>Jul 24 21:31:01 thebighonker sshd[92341]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:31:02 thebighonker sshd[92342]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:02 thebighonker sshd[92342]: login_getclass: unknown class 'root' <118>Jul 24 21:31:02 thebighonker sshd[92342]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:02 thebighonker sshd[92342]: login_getclass: unknown class 'root' <118>Jul 24 21:31:02 thebighonker sshd[92342]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:02 thebighonker sshd[92342]: login_getclass: unknown class 'root' <118>Jul 24 21:31:02 thebighonker sshd[92342]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:02 thebighonker sshd[92342]: login_getclass: unknown class 'root' <118>Jul 24 21:31:02 thebighonker sshd[92342]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:02 thebighonker sshd[92342]: login_getclass: unknown class 'root' <118>Jul 24 21:31:02 thebighonker sshd[92342]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:02 thebighonker sshd[92342]: login_getclass: unknown class 'root' <118>Jul 24 21:31:03 thebighonker sshd[92342]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:03 thebighonker sshd[92342]: login_getclass: unknown class 'root' <118>Jul 24 21:31:03 thebighonker sshd[92348]: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(unassigned.psychz.net, AF_INET) failed <118>Jul 24 21:31:04 thebighonker sshd[92349]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:04 thebighonker sshd[92349]: login_getclass: unknown class 'root' <118>Jul 24 21:31:04 thebighonker sshd[92349]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:04 thebighonker sshd[92349]: login_getclass: unknown class 'root' <118>Jul 24 21:31:04 thebighonker sshd[92349]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:04 thebighonker sshd[92349]: login_getclass: unknown class 'root' <118>Jul 24 21:31:04 thebighonker sshd[92349]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:04 thebighonker sshd[92349]: login_getclass: unknown class 'root' <118>Jul 24 21:31:04 thebighonker sshd[92349]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:04 thebighonker sshd[92349]: login_getclass: unknown class 'root' <118>Jul 24 21:31:04 thebighonker sshd[92349]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:04 thebighonker sshd[92349]: login_getclass: unknown class 'root' <118>Jul 24 21:31:04 thebighonker sshd[92349]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode <118>Jul 24 21:31:04 thebighonker sshd[92349]: login_getclass: unknown class 'root' <118>Jul 24 22:44:59 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:44:59 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:44:59 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:44:59 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:44:59 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:45:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:45:13 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:45:16 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-101-232.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:46:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:46:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:46:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:46:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:46:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:47:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:47:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:47:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:47:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:47:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:47:21 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:47:24 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:48:05 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:48:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:48:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:48:12 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:48:12 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-98-88.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:28 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:29 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:29 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 22:59:31 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:11:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:11:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:11:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:11:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 24 23:11:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-2.pools.spcsdns.net, AF_INET) failed <118>Jul 25 02:08:34 thebighonker sshd[3018]: fatal: Write failed: Broken pipe [preauth] <118>Jul 25 04:02:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:21 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:25 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:28 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:32 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:02:32 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:03:15 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:03:15 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:03:15 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:03:15 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:03:15 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:03:27 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:03:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-3-58.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:09:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:09:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:09:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:09:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:09:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:10:45 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:10:48 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:10:56 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:10:56 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:10:56 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:10:56 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:11:37 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:12:41 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:12:42 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:12:55 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:13:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:13:14 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:13:18 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:14:05 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:14:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:14:50 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:14:56 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-23.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:20 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:18:20 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:20:58 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:21:41 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 04:24:36 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <6>pid 9998 (wcgrid_mcm1_7.32_i6), uid 1055: exited on signal 11 (core dumped) <6>pid 9999 (wcgrid_mcm1_7.32_i6), uid 1055: exited on signal 11 (core dumped) <118>Jul 25 05:17:37 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 05:46:46 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-35.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:40 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:55 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:35:57 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-176.pools.spcsdns.net, AF_INET) failed <6>pid 13916 (wcgrid_mcm1_7.32_i6), uid 1055: exited on signal 11 (core dumped) <6>pid 13917 (wcgrid_mcm1_7.32_i6), uid 1055: exited on signal 11 (core dumped) <6>pid 13920 (wcgrid_mcm1_7.32_i6), uid 1055: exited on signal 11 (core dumped) <118>Jul 25 06:39:14 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:39:14 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:39:14 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:39:14 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:39:14 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:39:45 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:39:46 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:40:00 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:40:02 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:40:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:40:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:40:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:41:03 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:41:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:41:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:41:04 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:41:05 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-71.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:45:11 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-99-8.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:45:11 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-99-8.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:45:11 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-99-8.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:45:11 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-99-8.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:45:11 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-99-8.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:45:23 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-99-8.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:45:24 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-99-8.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:51:47 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:51:51 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:52:17 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:52:17 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:52:17 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:52:17 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 06:52:17 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:04:24 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-187.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:04:25 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-96-187.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:06:43 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:06:56 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:06:57 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-100-252.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:22 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:22 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:22 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:22 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:09:22 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:06 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:06 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:06 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:06 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:06 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:39 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:41 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:48 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:48 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:48 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:48 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:10:48 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:11:32 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:11:32 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:11:33 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:11:33 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:11:33 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:19:52 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:38:15 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:52:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:52:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:52:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:52:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:52:09 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:52:27 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:52:30 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:01 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:01 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:01 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:01 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:01 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:08 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:22 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:23 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:55:25 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-121-152.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:56:50 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:56:50 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:56:50 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:56:50 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:56:50 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:57:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:57:12 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:57:14 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:57:15 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:57:16 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:58:02 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:58:02 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:58:02 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:58:02 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:58:02 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:58:17 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:58:18 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:10 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:26 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:27 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:27 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:27 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 07:59:27 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:00:18 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:00:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:00:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:00:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:00:19 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:00:37 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:00:38 thebighonker tcpwrap: warning: /etc/hosts.allow, line 74: can't verify hostname: getaddrinfo(66-87-120-160.pools.spcsdns.net, AF_INET) failed <118>Jul 25 08:04:57 thebighonker sshd[17807]: warning: /etc/hosts.allow, line 74: host name/address mismatch: 202.170.136.247 != user.nova.net.cn kern.msgbuf_clear: 0 kern.smp.maxid: 7 kern.smp.maxcpus: 64 kern.smp.active: 1 kern.smp.disabled: 0 kern.smp.cpus: 8 kern.smp.topology: 0 kern.smp.forward_signal_enabled: 1 kern.tty_inq_flush_secure: 1 kern.tty_nin: 6403 kern.tty_nout: 2423588 kern.filedelay: 30 kern.dirdelay: 29 kern.metadelay: 28 kern.minvnodes: 87538 kern.chroot_allow_open_directories: 1 kern.userasymcrypto: 1 kern.cryptodevallowsoft: 0 kern.dtrace.dof_maxsize: 8388608 kern.dtrace.helper_actions_max: 128 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 3 Disk Wait: 0 Page Wait: 0 Sleep: 120) Virtual Memory: (Total: 7098928K Active: 6770504K) Real Memory: (Total: 12554680K Active: 1579692K) Shared Virtual Memory: (Total: 374668K Active: 148632K) Shared Real Memory: (Total: 206812K Active: 131080K) Free Memory: 652136K vm.loadavg: { 5.41 5.80 6.07 } vm.v_free_min: 25728 vm.v_free_target: 86847 vm.v_free_reserved: 5355 vm.v_inactive_target: 130270 vm.v_cache_min: 0 vm.v_cache_max: 0 vm.v_pageout_free_min: 34 vm.swap_enabled: 1 vm.md_malloc_wait: 0 vm.kmem_size: 16690679808 vm.kmem_size_min: 0 vm.kmem_size_max: 1319413950874 vm.kmem_size_scale: 1 vm.kmem_map_size: 11065069568 vm.kmem_map_free: 5625610240 vm.swap_total: 19327352832 vm.swap_reserved: 44248530944 vm.overcommit: 0 vm.swzone: 586781568 vm.swap_maxpages: 65197952 vm.swap_async_max: 4 vm.dmmax: 32 vm.nswapdev: 6 vm.zone_count: 204 vm.zone_warnings: 1 vm.kstack_cache_size: 128 vm.kstacks: 515 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 vm.exec_map_entries: 16 vm.min_kernel_address: 18446741874686296064 vm.max_kernel_address: 18446744073709547520 vm.v_free_severe: 15541 vm.stats.sys.v_swtch: 510325476 vm.stats.sys.v_trap: 513335839 vm.stats.sys.v_syscall: 2174649482 vm.stats.sys.v_intr: 106111565 vm.stats.sys.v_soft: 19228202 vm.stats.vm.v_vm_faults: 307498916 vm.stats.vm.v_io_faults: 33081 vm.stats.vm.v_cow_faults: 13684600 vm.stats.vm.v_cow_optim: 35258 vm.stats.vm.v_zfod: 288086834 vm.stats.vm.v_ozfod: 41534 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_vnodein: 33423 vm.stats.vm.v_vnodeout: 18739 vm.stats.vm.v_vnodepgsin: 425596 vm.stats.vm.v_vnodepgsout: 36534 vm.stats.vm.v_intrans: 1033 vm.stats.vm.v_reactivated: 78626 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_pdpages: 65636758 vm.stats.vm.v_tcached: 309063 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_pfree: 87016027 vm.stats.vm.v_tfree: 346735024 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_page_count: 4074873 vm.stats.vm.v_free_reserved: 5355 vm.stats.vm.v_free_target: 86847 vm.stats.vm.v_free_min: 25728 vm.stats.vm.v_free_count: 161016 vm.stats.vm.v_wire_count: 3359450 vm.stats.vm.v_active_count: 188550 vm.stats.vm.v_inactive_target: 130270 vm.stats.vm.v_inactive_count: 363521 vm.stats.vm.v_cache_count: 2018 vm.stats.vm.v_cache_min: 0 vm.stats.vm.v_cache_max: 0 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_forks: 107834 vm.stats.vm.v_vforks: 9268 vm.stats.vm.v_rforks: 2017 vm.stats.vm.v_kthreads: 24 vm.stats.vm.v_forkpages: 7386644 vm.stats.vm.v_vforkpages: 338230 vm.stats.vm.v_rforkpages: 5992659 vm.stats.vm.v_kthreadpages: 0 vm.stats.misc.zero_page_count: 9371 vm.stats.misc.cnt_prezero: 0 vm.stats.object.collapses: 635183 vm.stats.object.bypasses: 112683 vm.old_mlock: 0 vm.old_msync: 0 vm.boot_pages: 64 vm.tryrelock_restart: 18 vm.pageout_wakeup_thresh: 28292 vm.max_launder: 32 vm.pageout_update_period: 600 vm.lowmem_period: 0 vm.swap_idle_enabled: 0 vm.defer_swapspace_pageouts: 0 vm.disable_swapspace_pageouts: 0 vm.pageout_lock_miss: 0 vm.max_wired: 1340804 vm.phys_free: DOMAIN 0: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 0 | 0 | 0 9 ( 2048K) | 0 | 0 | 0 8 ( 1024K) | 1 | 0 | 0 7 ( 512K) | 5 | 0 | 0 6 ( 256K) | 31 | 0 | 0 5 ( 128K) | 210 | 0 | 0 4 ( 64K) | 950 | 0 | 104 3 ( 32K) | 1741 | 4 | 6 2 ( 16K) | 9539 | 171 | 442 1 ( 8K) | 1261 | 2647 | 57 0 ( 4K) | 0 | 10078 | 126 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 0 | 0 | 0 9 ( 2048K) | 0 | 0 | 0 8 ( 1024K) | 0 | 0 | 0 7 ( 512K) | 0 | 0 | 0 6 ( 256K) | 1 | 0 | 0 5 ( 128K) | 1 | 0 | 0 4 ( 64K) | 3 | 1 | 0 3 ( 32K) | 5 | 0 | 0 2 ( 16K) | 4 | 0 | 0 1 ( 8K) | 5 | 0 | 0 0 ( 4K) | 15 | 0 | 0 vm.phys_segs: SEGMENT 0: start: 0x10000 end: 0x9c000 domain: 0 free list: 0xffffffff815925b8 SEGMENT 1: start: 0x100000 end: 0x200000 domain: 0 free list: 0xffffffff815925b8 SEGMENT 2: start: 0x1d74000 end: 0xcfe44000 domain: 0 free list: 0xffffffff81592210 SEGMENT 3: start: 0xcfe4c000 end: 0xcfe4d000 domain: 0 free list: 0xffffffff81592210 SEGMENT 4: start: 0x100000000 end: 0x414b1c000 domain: 0 free list: 0xffffffff81592210 vm.ndomains: 1 vm.reserv.broken: 83 vm.reserv.freed: 182633 vm.reserv.partpopq: LEVEL SIZE NUMBER -1: 254316K, 1022 vm.reserv.reclaimed: 5943 vm.idlezero_enable: 0 vm.pmap.pat_works: 1 vm.pmap.pg_ps_enabled: 1 vm.pmap.pcid_enabled: 0 vm.pmap.invpcid_works: 0 vm.pmap.pcid_save_cnt: 0 vm.pmap.pde.demotions: 113019 vm.pmap.pde.mappings: 0 vm.pmap.pde.p_failures: 74794 vm.pmap.pde.promotions: 121108 vm.pmap.pdpe.demotions: 0 vm.kvm_size: 2199023251456 vm.kvm_free: 2180067094528 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 26955776 vfs.ufs.dirhash_mem: 0 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_lowmemcount: 0 vfs.ufs.dirhash_reclaimage: 60 vfs.ufs.rename_restarts: 0 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.bufpackets: 4 vfs.nfs.reconnects: 0 vfs.nfs.nfs3_jukebox_delay: 10 vfs.nfs.skip_wcc_data_onerr: 1 vfs.nfs.realign_test: 0 vfs.nfs.realign_count: 0 vfs.nfs.callback_addr: vfs.nfs.debuglevel: 0 vfs.nfs.access_cache_timeout: 60 vfs.nfs.prime_access_cache: 0 vfs.nfs.commit_on_close: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.nfs_keep_dirty_on_error: 0 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.iodmaxidle: 120 vfs.nfs.iodmin: 0 vfs.nfs.iodmax: 20 vfs.nfs.defect: 0 vfs.devfs.generation: 282 vfs.devfs.rule_depth: 1 vfs.zfs.arc_max: 15616937984 vfs.zfs.arc_min: 1952117248 vfs.zfs.arc_freepages: 86847 vfs.zfs.arc_freepage_percent: 0 vfs.zfs.arc_shrink_needed: 0 vfs.zfs.arc_meta_used: 2431042656 vfs.zfs.arc_meta_limit: 3904234496 vfs.zfs.l2arc_write_max: 8388608 vfs.zfs.l2arc_write_boost: 8388608 vfs.zfs.l2arc_headroom: 2 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_feed_min_ms: 200 vfs.zfs.l2arc_noprefetch: 1 vfs.zfs.l2arc_feed_again: 1 vfs.zfs.l2arc_norw: 1 vfs.zfs.anon_size: 1376256 vfs.zfs.anon_metadata_lsize: 0 vfs.zfs.anon_data_lsize: 0 vfs.zfs.mru_size: 4896226304 vfs.zfs.mru_metadata_lsize: 61626368 vfs.zfs.mru_data_lsize: 4422528000 vfs.zfs.mru_ghost_size: 7108034048 vfs.zfs.mru_ghost_metadata_lsize: 94201856 vfs.zfs.mru_ghost_data_lsize: 7013832192 vfs.zfs.mfu_size: 5751376896 vfs.zfs.mfu_metadata_lsize: 671098880 vfs.zfs.mfu_data_lsize: 4925076480 vfs.zfs.mfu_ghost_size: 4891616256 vfs.zfs.mfu_ghost_metadata_lsize: 111141376 vfs.zfs.mfu_ghost_data_lsize: 4780474880 vfs.zfs.l2c_only_size: 0 vfs.zfs.dedup.prefetch: 1 vfs.zfs.nopwrite_enabled: 1 vfs.zfs.mdcomp_disable: 0 vfs.zfs.prefetch_disable: 0 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.top_maxinflight: 32 vfs.zfs.resilver_delay: 2 vfs.zfs.scrub_delay: 4 vfs.zfs.scan_idle: 50 vfs.zfs.scan_min_time_ms: 1000 vfs.zfs.free_min_time_ms: 1000 vfs.zfs.resilver_min_time_ms: 3000 vfs.zfs.no_scrub_io: 0 vfs.zfs.no_scrub_prefetch: 0 vfs.zfs.metaslab.gang_bang: 131073 vfs.zfs.metaslab.debug_load: 0 vfs.zfs.metaslab.debug_unload: 0 vfs.zfs.metaslab.df_alloc_threshold: 131072 vfs.zfs.metaslab.df_free_pct: 4 vfs.zfs.metaslab.min_alloc_size: 10485760 vfs.zfs.metaslab.load_pct: 50 vfs.zfs.metaslab.unload_delay: 8 vfs.zfs.metaslab.preload_limit: 3 vfs.zfs.metaslab.preload_enabled: 1 vfs.zfs.metaslab.weight_factor_enable: 0 vfs.zfs.condense_pct: 200 vfs.zfs.mg_noalloc_threshold: 0 vfs.zfs.write_to_degraded: 0 vfs.zfs.check_hostid: 1 vfs.zfs.recover: 0 vfs.zfs.deadman_synctime_ms: 1000000 vfs.zfs.deadman_checktime_ms: 5000 vfs.zfs.deadman_enabled: 1 vfs.zfs.spa_asize_inflation: 24 vfs.zfs.txg.timeout: 5 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.cache.size: 0 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.trim_on_init: 1 vfs.zfs.vdev.max_active: 1000 vfs.zfs.vdev.sync_read_min_active: 10 vfs.zfs.vdev.sync_read_max_active: 10 vfs.zfs.vdev.sync_write_min_active: 10 vfs.zfs.vdev.sync_write_max_active: 10 vfs.zfs.vdev.async_read_min_active: 1 vfs.zfs.vdev.async_read_max_active: 3 vfs.zfs.vdev.async_write_min_active: 1 vfs.zfs.vdev.async_write_max_active: 10 vfs.zfs.vdev.scrub_min_active: 1 vfs.zfs.vdev.scrub_max_active: 2 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.read_gap_limit: 32768 vfs.zfs.vdev.write_gap_limit: 4096 vfs.zfs.vdev.bio_flush_disable: 0 vfs.zfs.vdev.bio_delete_disable: 0 vfs.zfs.vdev.trim_max_bytes: 2147483648 vfs.zfs.vdev.trim_max_pending: 64 vfs.zfs.max_auto_ashift: 13 vfs.zfs.min_auto_ashift: 9 vfs.zfs.zil_replay_disable: 0 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zio.use_uma: 1 vfs.zfs.zio.exclude_metadata: 0 vfs.zfs.sync_pass_deferred_free: 2 vfs.zfs.sync_pass_dont_compress: 5 vfs.zfs.sync_pass_rewrite: 2 vfs.zfs.snapshot_list_prefetch: 0 vfs.zfs.super_owner: 1 vfs.zfs.debug: 0 vfs.zfs.version.ioctl: 4 vfs.zfs.version.acl: 1 vfs.zfs.version.spa: 5000 vfs.zfs.version.zpl: 5 vfs.zfs.vol.mode: 1 vfs.zfs.trim.enabled: 1 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.max_interval: 1 vfs.nfsd.disable_checkutf8: 0 vfs.nfsd.nfs_privport: 0 vfs.nfsd.server_min_nfsvers: 2 vfs.nfsd.server_max_nfsvers: 4 vfs.nfsd.async: 0 vfs.nfsd.mirrormnt: 1 vfs.nfsd.commit_blks: 0 vfs.nfsd.commit_miss: 0 vfs.nfsd.issue_delegations: 0 vfs.nfsd.enable_locallocks: 0 vfs.nfsd.enable_stringtouid: 0 vfs.nfsd.tcphighwater: 0 vfs.nfsd.udphighwater: 500 vfs.nfsd.tcpcachetimeo: 43200 vfs.nfsd.cachetcp: 1 vfs.nfsd.minthreads: 1 vfs.nfsd.maxthreads: 1 vfs.nfsd.threads: 0 vfs.nfsd.groups: 1 vfs.nfsd.request_space_used: 0 vfs.nfsd.request_space_used_highest: 0 vfs.nfsd.request_space_high: 47185920 vfs.nfsd.request_space_low: 31457280 vfs.nfsd.request_space_throttled: 0 vfs.nfsd.request_space_throttle_count: 0 vfs.nfsd.fha.enable: 1 vfs.nfsd.fha.bin_shift: 22 vfs.nfsd.fha.max_nfsds_per_fh: 8 vfs.nfsd.fha.max_reqs_per_nfsd: 0 vfs.nfsd.fha.fhe_stats: No file handle entries. vfs.pfs.trace: 0 vfs.pfs.vncache.entries: 0 vfs.pfs.vncache.maxentries: 0 vfs.pfs.vncache.hits: 0 vfs.pfs.vncache.misses: 0 vfs.acl_nfs4_old_semantics: 0 vfs.vmiodirenable: 1 vfs.runningbufspace: 0 vfs.bufspace: 0 vfs.unmapped_bufspace: 0 vfs.maxbufspace: 1725759488 vfs.bufmallocspace: 0 vfs.maxmallocbufspace: 86255206 vfs.lobufspace: 1725038592 vfs.hibufspace: 1725104128 vfs.bufreusecnt: 0 vfs.buffreekvacnt: 0 vfs.bufdefragcnt: 0 vfs.lorunningspace: 11206656 vfs.hirunningspace: 16777216 vfs.dirtybufferflushes: 0 vfs.bdwriteskip: 0 vfs.altbufferflushes: 0 vfs.recursiveflushes: 0 vfs.numdirtybuffers: 0 vfs.lodirtybuffers: 13176 vfs.hidirtybuffers: 26353 vfs.dirtybufthresh: 23717 vfs.numfreebuffers: 105332 vfs.lofreebuffers: 5856 vfs.hifreebuffers: 11712 vfs.getnewbufcalls: 0 vfs.getnewbufrestarts: 0 vfs.mappingrestarts: 0 vfs.flushbufqtarget: 100 vfs.notbufdflushes: 0 vfs.barrierwrites: 0 vfs.unmapped_buf_allowed: 1 vfs.flushwithdeps: 0 vfs.ncnegfactor: 16 vfs.ncsizefactor: 2 vfs.cache.numneg: 7305 vfs.cache.numcache: 117915 vfs.cache.numcalls: 161605491 vfs.cache.dothits: 541341 vfs.cache.dotdothits: 577737 vfs.cache.numchecks: 167575412 vfs.cache.nummiss: 6036744 vfs.cache.nummisszap: 62418 vfs.cache.numposzaps: 349173 vfs.cache.numposhits: 150643401 vfs.cache.numnegzaps: 74135 vfs.cache.numneghits: 3316283 vfs.cache.numupgrades: 5651 vfs.cache.numfullpathcalls: 718238 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathfail2: 80 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfound: 718166 vfs.write_behind: 1 vfs.read_max: 64 vfs.read_min: 1 vfs.typenumhash: 1 vfs.lookup_shared: 1 vfs.usermount: 1 vfs.numvnodes: 111777 vfs.wantfreevnodes: 87538 vfs.freevnodes: 83901 vfs.vlru_allow_cache_src: 0 vfs.reassignbufcalls: 0 vfs.timestamp_precision: 0 vfs.worklist_len: 0 vfs.ffs.doasyncfree: 1 vfs.ffs.doreallocblks: 1 vfs.ffs.compute_summary_at_mount: 0 net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.maxdgram: 2048 net.local.dgram.recvspace: 4096 net.local.seqpacket.maxseqpacket: 8192 net.local.seqpacket.recvspace: 8192 net.local.inflight: 0 net.local.deferred: 0 net.local.recycled: 0 net.local.taskcount: 138 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomtime: 45 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 256 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.no_same_prefix: 0 net.inet.ip.random_id_period: 8192 net.inet.ip.random_id_collisions: 0 net.inet.ip.random_id_total: 0 net.inet.ip.mcast.maxgrpsrc: 512 net.inet.ip.mcast.maxsocksrc: 128 net.inet.ip.mcast.loop: 1 net.inet.ip.fastforwarding: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.random_id: 0 net.inet.ip.check_interface: 0 net.inet.ip.fragpackets: 0 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.maxfragpackets: 31834 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.icmplim_output: 1 net.inet.icmp.maskfake: 0 net.inet.icmp.log_redirect: 0 net.inet.icmp.reply_src: net.inet.icmp.reply_from_interface: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.bmcastecho: 0 net.inet.icmp.drop_redirect: 0 net.inet.igmp.recvifkludge: 1 net.inet.igmp.sendra: 1 net.inet.igmp.sendlocal: 1 net.inet.igmp.v1enable: 1 net.inet.igmp.v2enable: 1 net.inet.igmp.legacysupp: 0 net.inet.igmp.default_version: 3 net.inet.igmp.gsrdelay: 10 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 536 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1220 net.inet.tcp.cc.algorithm: newreno net.inet.tcp.cc.available: newreno net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.count: 168 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.rfc3042: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.experimental.initcwnd10: 1 net.inet.tcp.rfc3465: 1 net.inet.tcp.abc_l_var: 2 net.inet.tcp.ecn.enable: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.tso: 1 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_max: 2097152 net.inet.tcp.reass.maxsegments: 63700 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.overflows: 25 net.inet.tcp.sack.enable: 1 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.minmss: 216 net.inet.tcp.log_debug: 0 net.inet.tcp.tcbhashsize: 131072 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 74 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.soreceive_stream: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15375 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.msl: 30000 net.inet.tcp.rexmit_min: 30 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.always_keepalive: 1 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.keepcnt: 8 net.inet.tcp.rexmit_drop_options: 0 net.inet.tcp.per_cpu_timers: 0 net.inet.tcp.timer_race: 0 net.inet.tcp.maxtcptw: 27767 net.inet.tcp.nolocaltimewait: 0 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.sctp.sendspace: 1864135 net.inet.sctp.recvspace: 1864135 net.inet.sctp.auto_asconf: 1 net.inet.sctp.ecn_enable: 1 net.inet.sctp.strict_sacks: 1 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.maxburst: 4 net.inet.sctp.fr_maxburst: 4 net.inet.sctp.maxchunks: 127339 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.min_split_point: 2904 net.inet.sctp.chunkscale: 10 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.sack_freq: 2 net.inet.sctp.sys_resource: 1000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.rto_max: 60000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.path_pf_threshold: 65535 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.incoming_streams: 2048 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.nr_sack_on_off: 0 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.auth_disable: 0 net.inet.sctp.nat_friendly: 1 net.inet.sctp.abc_l_var: 2 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.strict_data_order: 0 net.inet.sctp.min_residual: 1452 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.log_level: 0 net.inet.sctp.default_cc_module: 0 net.inet.sctp.default_ss_module: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.mobility_base: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.nat_friendly_init: 0 net.inet.sctp.vtag_time_wait: 60 net.inet.sctp.buffer_splitting: 0 net.inet.sctp.initial_cwnd: 3 net.inet.sctp.rttvar_bw: 4 net.inet.sctp.rttvar_rtt: 5 net.inet.sctp.rttvar_eqret: 0 net.inet.sctp.rttvar_steady_step: 20 net.inet.sctp.use_dcccecn: 1 net.inet.sctp.blackhole: 0 net.inet.sctp.diag_info_code: 0 net.inet.raw.maxdgram: 9216 net.inet.raw.recvspace: 9216 net.inet.accf.unloadable: 0 net.link.generic.system.ifcount: 4 net.link.ether.inet.max_age: 1200 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.wait: 20 net.link.ether.inet.maxhold: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.allow_multicast: 0 net.link.ether.inet.max_log_per_second: 1 net.link.vlan.soft_pad: 0 net.link.gif.max_nesting: 1 net.link.gif.parallel_tunnels: 0 net.link.ifqmaxlen: 50 net.link.log_link_state_change: 1 net.link.tun.devfs_cloning: 1 net.link.lagg.failover_rx_all: 0 net.link.lagg.default_use_flowid: 1 net.link.lagg.default_flowid_shift: 16 net.link.lagg.lacp.debug: 0 net.link.lagg.0.use_flowid: 1 net.link.lagg.0.flowid_shift: 16 net.link.lagg.0.count: 2 net.link.lagg.0.active: 2 net.link.lagg.0.flapping: 0 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 254679 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 0 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 254679 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.no_radr: 0 net.inet6.ip6.norbit_raif: 0 net.inet6.ip6.rfc6204w3: 0 net.inet6.ip6.mcast.maxgrpsrc: 512 net.inet6.ip6.mcast.maxsocksrc: 128 net.inet6.ip6.mcast.loop: 1 net.inet6.ip6.deembed_scopeid: 1 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.inet6.icmp6.nd6_maxqueuelen: 1 net.inet6.icmp6.nodeinfo_oldmcprefix: 1 net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 net.inet6.icmp6.nd6_gctimer: 86400 net.inet6.mld.gsrdelay: 10 net.inet6.mld.v1enable: 1 net.inet6.mld.use_allow: 1 net.bpf.maxinsns: 512 net.bpf.zerocopy_enable: 0 net.bpf.optimize_writers: 0 net.bpf.bufsize: 4096 net.bpf.maxbufsize: 524288 net.ifdescr_maxlen: 1024 net.isr.dispatch: direct net.isr.maxthreads: 1 net.isr.bindthreads: 0 net.isr.maxqlimit: 10240 net.isr.defaultqlimit: 256 net.isr.maxprot: 16 net.isr.numthreads: 1 net.raw.sendspace: 8192 net.raw.recvspace: 8192 net.fibs: 1 net.add_addr_allfibs: 1 net.my_fibnum: 0 net.route.netisr_maxqlen: 256 net.wlan.nol_timeout: 1800 net.wlan.cac_timeout: 60 net.wlan.debug: 0 net.wlan.ampdu_age: 500 net.wlan.recv_bar: 1 net.wlan.addba_timeout: 250 net.wlan.addba_backoff: 10000 net.wlan.addba_maxtries: 3 net.wlan.hwmp.targetonly: 0 net.wlan.hwmp.pathlifetime: 5000 net.wlan.hwmp.maxpreq_retries: 3 net.wlan.hwmp.net_diameter_traversal_time: 512 net.wlan.hwmp.roottimeout: 5000 net.wlan.hwmp.rootint: 2000 net.wlan.hwmp.rannint: 1000 net.wlan.hwmp.rootconfint: 2000 net.wlan.hwmp.inact: 5000 net.wlan.mesh.gateint: 10000 net.wlan.mesh.retrytimeout: 40 net.wlan.mesh.holdingtimeout: 40 net.wlan.mesh.confirmtimeout: 40 net.wlan.mesh.backofftimeout: 5000 net.wlan.mesh.maxretries: 2 net.wlan.mesh.maxholding: 2 debug.acpi.max_tasks: 256 debug.acpi.max_threads: 3 debug.acpi.acpi_ca_version: 20130823 debug.acpi.enable_debug_objects: 0 debug.acpi.interpreter_slack: 1 debug.acpi.reset_clock: 1 debug.acpi.suspend_bounce: 0 debug.acpi.cpu_unordered: 0 debug.acpi.ec.burst: 0 debug.acpi.ec.polled: 0 debug.acpi.ec.timeout: 750 debug.acpi.batt.batt_sleep_ms: 0 debug.acpi.resume_beep: 0 debug.ipw: 0 debug.iwi: 0 debug.mddebug: 0 debug.wpi: 0 debug.elf64_legacy_coredump: 0 debug.elf32_legacy_coredump: 0 debug.boothowto: 0 debug.bootverbose: 0 debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 debug.fail_point.sysctl_running: off debug.fail_point.buf_pressure: off debug.fail_point.nlm_deny_grant: off debug.sizeof.cdev: 288 debug.sizeof.cdev_priv: 376 debug.sizeof.g_class: 176 debug.sizeof.g_geom: 176 debug.sizeof.g_provider: 136 debug.sizeof.g_consumer: 96 debug.sizeof.g_bioq: 56 debug.sizeof.vnode: 472 debug.sizeof.proc: 1208 debug.sizeof.bio: 248 debug.sizeof.buf: 600 debug.sizeof.kinfo_proc: 1088 debug.sizeof.devstat: 288 debug.sizeof.namecache: 72 debug.sizeof.znode: 368 debug.adaptive_machine_arch: 1 debug.osd: 0 debug.rwlock.retry: 10 debug.rwlock.loops: 10000 debug.debugger_on_panic: 1 debug.trace_on_panic: 1 debug.ncores: 5 debug.sx.retries: 10 debug.sx.loops: 10000 debug.umtx.umtx_pi_allocated: 0 debug.clocktime: 0 debug.kdb.available: debug.kdb.current: debug.kdb.enter: 0 debug.kdb.panic: 0 debug.kdb.trap: 0 debug.kdb.trap_code: 0 debug.kdb.break_to_debugger: 0 debug.kdb.alt_break_to_debugger: 0 debug.rman_debug: 0 debug.iosize_max_clamp: 1 debug.devfs_iosize_max_clamp: 1 debug.nchash: 524287 debug.numneg: 7305 debug.numcache: 117915 debug.numcachehv: 22824 debug.vfscache: 1 debug.disablecwd: 0 debug.disablefullpath: 0 debug.rush_requests: 0 debug.vnlru_nowhere: 0 debug.vn_io_fault_enable: 1 debug.vn_io_faults: 0 debug.if_tun_debug: 0 debug.nlm_debug: 0 debug.fsckcmds: 0 debug.dopersistence: 0 debug.snapdebug: 0 debug.collectsnapstats: 0 debug.softdep.total.pagedep: 0 debug.softdep.total.inodedep: 0 debug.softdep.total.bmsafemap: 0 debug.softdep.total.newblk: 0 debug.softdep.total.allocdirect: 0 debug.softdep.total.indirdep: 0 debug.softdep.total.allocindir: 0 debug.softdep.total.freefrag: 0 debug.softdep.total.freeblks: 0 debug.softdep.total.freefile: 0 debug.softdep.total.diradd: 0 debug.softdep.total.mkdir: 0 debug.softdep.total.dirrem: 0 debug.softdep.total.newdirblk: 0 debug.softdep.total.freework: 0 debug.softdep.total.freedep: 0 debug.softdep.total.jaddref: 0 debug.softdep.total.jremref: 0 debug.softdep.total.jmvref: 0 debug.softdep.total.jnewblk: 0 debug.softdep.total.jfreeblk: 0 debug.softdep.total.jfreefrag: 0 debug.softdep.total.jseg: 0 debug.softdep.total.jsegdep: 0 debug.softdep.total.sbdep: 0 debug.softdep.total.jtrunc: 0 debug.softdep.total.jfsync: 0 debug.softdep.highuse.pagedep: 0 debug.softdep.highuse.inodedep: 0 debug.softdep.highuse.bmsafemap: 0 debug.softdep.highuse.newblk: 0 debug.softdep.highuse.allocdirect: 0 debug.softdep.highuse.indirdep: 0 debug.softdep.highuse.allocindir: 0 debug.softdep.highuse.freefrag: 0 debug.softdep.highuse.freeblks: 0 debug.softdep.highuse.freefile: 0 debug.softdep.highuse.diradd: 0 debug.softdep.highuse.mkdir: 0 debug.softdep.highuse.dirrem: 0 debug.softdep.highuse.newdirblk: 0 debug.softdep.highuse.freework: 0 debug.softdep.highuse.freedep: 0 debug.softdep.highuse.jaddref: 0 debug.softdep.highuse.jremref: 0 debug.softdep.highuse.jmvref: 0 debug.softdep.highuse.jnewblk: 0 debug.softdep.highuse.jfreeblk: 0 debug.softdep.highuse.jfreefrag: 0 debug.softdep.highuse.jseg: 0 debug.softdep.highuse.jsegdep: 0 debug.softdep.highuse.sbdep: 0 debug.softdep.highuse.jtrunc: 0 debug.softdep.highuse.jfsync: 0 debug.softdep.current.pagedep: 0 debug.softdep.current.inodedep: 0 debug.softdep.current.bmsafemap: 0 debug.softdep.current.newblk: 0 debug.softdep.current.allocdirect: 0 debug.softdep.current.indirdep: 0 debug.softdep.current.allocindir: 0 debug.softdep.current.freefrag: 0 debug.softdep.current.freeblks: 0 debug.softdep.current.freefile: 0 debug.softdep.current.diradd: 0 debug.softdep.current.mkdir: 0 debug.softdep.current.dirrem: 0 debug.softdep.current.newdirblk: 0 debug.softdep.current.freework: 0 debug.softdep.current.freedep: 0 debug.softdep.current.jaddref: 0 debug.softdep.current.jremref: 0 debug.softdep.current.jmvref: 0 debug.softdep.current.jnewblk: 0 debug.softdep.current.jfreeblk: 0 debug.softdep.current.jfreefrag: 0 debug.softdep.current.jseg: 0 debug.softdep.current.jsegdep: 0 debug.softdep.current.sbdep: 0 debug.softdep.current.jtrunc: 0 debug.softdep.current.jfsync: 0 debug.softdep.write.pagedep: 0 debug.softdep.write.inodedep: 0 debug.softdep.write.bmsafemap: 0 debug.softdep.write.newblk: 0 debug.softdep.write.allocdirect: 0 debug.softdep.write.indirdep: 0 debug.softdep.write.allocindir: 0 debug.softdep.write.freefrag: 0 debug.softdep.write.freeblks: 0 debug.softdep.write.freefile: 0 debug.softdep.write.diradd: 0 debug.softdep.write.mkdir: 0 debug.softdep.write.dirrem: 0 debug.softdep.write.newdirblk: 0 debug.softdep.write.freework: 0 debug.softdep.write.freedep: 0 debug.softdep.write.jaddref: 0 debug.softdep.write.jremref: 0 debug.softdep.write.jmvref: 0 debug.softdep.write.jnewblk: 0 debug.softdep.write.jfreeblk: 0 debug.softdep.write.jfreefrag: 0 debug.softdep.write.jseg: 0 debug.softdep.write.jsegdep: 0 debug.softdep.write.sbdep: 0 debug.softdep.write.jtrunc: 0 debug.softdep.write.jfsync: 0 debug.softdep.max_softdeps: 1400620 debug.softdep.tickdelay: 2 debug.softdep.maxindirdeps: 50 debug.softdep.softdep_mounts: 0 debug.softdep.worklist_push: 0 debug.softdep.blk_limit_push: 0 debug.softdep.ino_limit_push: 0 debug.softdep.blk_limit_hit: 0 debug.softdep.ino_limit_hit: 0 debug.softdep.sync_limit_hit: 0 debug.softdep.indir_blk_ptrs: 0 debug.softdep.inode_bitmap: 0 debug.softdep.direct_blk_ptrs: 0 debug.softdep.dir_entry: 0 debug.softdep.jaddref_rollback: 0 debug.softdep.jnewblk_rollback: 0 debug.softdep.journal_low: 0 debug.softdep.journal_min: 0 debug.softdep.journal_wait: 0 debug.softdep.jwait_filepage: 0 debug.softdep.jwait_freeblks: 0 debug.softdep.jwait_inode: 0 debug.softdep.jwait_newblk: 0 debug.softdep.cleanup_blkrequests: 0 debug.softdep.cleanup_inorequests: 0 debug.softdep.cleanup_high_delay: 0 debug.softdep.cleanup_retries: 0 debug.softdep.cleanup_failures: 0 debug.softdep.flushcache: 0 debug.softdep.emptyjblocks: 0 debug.bigcgs: 0 debug.dobkgrdwrite: 1 debug.dircheck: 0 debug.psm.loglevel: 0 debug.psm.hz: 20 debug.psm.errsecs: 2 debug.psm.errusecs: 0 debug.psm.secs: 0 debug.psm.usecs: 500000 debug.psm.pkterrthresh: 2 debug.vesa.shadow_rom: 0 debug.fdc.fifo: 8 debug.fdc.debugflags: 0 debug.fdc.retries: 10 debug.fdc.spec1: 175 debug.fdc.spec2: 16 debug.fdc.settle: 0 debug.x86bios.call: 0 debug.x86bios.int: 0 debug.hwpstate_verbose: 0 debug.minidump: 1 debug.zfs_flags: 0 debug.crypto_timing: 0 debug.dtrace.verbose_ioctl: 0 debug.dtrace.debug: 0 debug.dtrace.providers: dtrace linuxulator32 opencrypto mac_framework mac sctp udp tcp ip vfs io sched callout_execute sdt proc priv xbb dtmalloc nfscl fbt syscall lockstat profile syscall hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz hw.ncpu: 8 hw.byteorder: 1234 hw.physmem: 17148788736 hw.usermem: 3388481536 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: amd64 hw.realmem: 17179869184 hw.aac.enable_msi: 1 hw.amr.force_sg32: 0 hw.an.an_dump: off hw.an.an_cache_mode: dbm hw.an.an_cache_mcastonly: 0 hw.an.an_cache_iponly: 1 hw.ata.ata_dma_check_80pin: 1 hw.ath.longcal: 30 hw.ath.shortcal: 100 hw.ath.resetcal: 1200 hw.ath.anical: 100 hw.ath.rxbuf: 512 hw.ath.txbuf: 512 hw.ath.txbuf_mgmt: 32 hw.ath.bstuck: 4 hw.bce.verbose: 1 hw.bce.tso_enable: 1 hw.bce.msi_enable: 1 hw.bce.rx_pages: 2 hw.bce.tx_pages: 2 hw.bce.hdr_split: 1 hw.bce.strict_rx_mtu: 0 hw.bce.tx_quick_cons_trip_int: 20 hw.bce.tx_quick_cons_trip: 20 hw.bce.tx_ticks_int: 80 hw.bce.tx_ticks: 80 hw.bce.rx_quick_cons_trip_int: 6 hw.bce.rx_quick_cons_trip: 6 hw.bce.rx_ticks_int: 18 hw.bce.rx_ticks: 18 hw.bge.allow_asf: 1 hw.cardbus.debug: 0 hw.cardbus.cis_debug: 0 hw.cs.ignore_checksum_failure: 0 hw.cs.recv_delay: 570 hw.em.tx_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_abs_int_delay: 66 hw.em.rx_abs_int_delay: 66 hw.em.rxd: 1024 hw.em.txd: 1024 hw.em.smart_pwr_down: 0 hw.em.sbp: 0 hw.em.enable_msix: 1 hw.em.rx_process_limit: 100 hw.em.eee_setting: 1 hw.igb.rxd: 1024 hw.igb.txd: 1024 hw.igb.enable_aim: 1 hw.igb.enable_msix: 1 hw.igb.max_interrupt_rate: 8000 hw.igb.buf_ring_size: 4096 hw.igb.header_split: 0 hw.igb.num_queues: 0 hw.igb.rx_process_limit: 100 hw.ix.enable_aim: 1 hw.ix.max_interrupt_rate: 31250 hw.ix.rx_process_limit: 256 hw.ix.tx_process_limit: 256 hw.ix.enable_msix: 1 hw.ix.num_queues: 0 hw.ix.txd: 2048 hw.ix.rxd: 2048 hw.malo.txcoalesce: 8 hw.malo.rxbuf: 256 hw.malo.rxquota: 256 hw.malo.txbuf: 256 hw.malo.pci.msi_disable: 0 hw.mfi.event_locale: 65535 hw.mfi.event_class: 0 hw.mfi.max_cmds: 128 hw.mfi.detect_jbod_change: 1 hw.mfi.polled_cmd_timeout: 60 hw.mfi.cmd_timeout: 30 hw.mfi.msi: 1 hw.mmc.debug: 0 hw.mwl.rxdesc: 256 hw.mwl.rxbuf: 640 hw.mwl.txbuf: 256 hw.mwl.txcoalesce: 8 hw.mwl.rxquota: 640 hw.mwl.rxdmalow: 3 hw.pccard.debug: 0 hw.pccard.cis_debug: 0 hw.cbb.start_memory: 2281701376 hw.cbb.start_16_io: 256 hw.cbb.start_32_io: 4096 hw.cbb.debug: 0 hw.pcic.intr_mask: 57016 hw.pcic.pd6722_vsense: 1 hw.pci.enable_io_modes: 1 hw.pci.realloc_bars: 0 hw.pci.do_power_nodriver: 0 hw.pci.do_power_resume: 1 hw.pci.do_power_suspend: 1 hw.pci.enable_msi: 1 hw.pci.enable_msix: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.usb_early_takeover: 1 hw.pci.clear_bars: 0 hw.pci.clear_pcib: 0 hw.pci.default_vgapci_unit: 0 hw.pci.mcfg: 1 hw.pci.host_mem_start: 2147483648 hw.sdhci.debug: 0 hw.sdhci_pci.debug: 0 hw.snd.report_soft_formats: 1 hw.snd.report_soft_matrix: 1 hw.snd.latency: 5 hw.snd.latency_profile: 1 hw.snd.vpc_autoreset: 1 hw.snd.vpc_0db: 45 hw.snd.vpc_reset: 0 hw.snd.compat_linux_mmap: 0 hw.snd.feeder_eq_presets: PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000 hw.snd.feeder_eq_exact_rate: 0 hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97 hw.snd.feeder_rate_polyphase_max: 183040 hw.snd.feeder_rate_min: 1 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_quality: 1 hw.snd.vpc_mixer_bypass: 1 hw.snd.verbose: 0 hw.snd.default_auto: -1 hw.snd.version: 2009061500/amd64 hw.snd.default_unit: -1 hw.snd.maxautovchans: 16 hw.midi.stat.verbose: 0 hw.midi.debug: 0 hw.midi.dumpraw: 0 hw.midi.instroff: 0 hw.midi.seq.debug: 0 hw.syscons.saver.keybonly: 1 hw.syscons.bell: 1 hw.syscons.kbd_reboot: 1 hw.syscons.kbd_debug: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.broken_txfifo: 0 hw.usb.ehci.debug: 0 hw.usb.ehci.no_hs: 0 hw.usb.ehci.iaadbug: 0 hw.usb.ehci.lostintrbug: 0 hw.usb.ohci.debug: 0 hw.usb.uhci.debug: 0 hw.usb.uhci.loop: 0 hw.usb.xhci.streams: 0 hw.usb.xhci.debug: 0 hw.usb.xhci.xhci_port_route: 0 hw.usb.xhci.use_polling: 0 hw.usb.ctrl.debug: 0 hw.usb.no_boot_wait: 0 hw.usb.no_suspend_wait: 0 hw.usb.no_shutdown_wait: 0 hw.usb.umass.debug: 0 hw.usb.umass.throttle: 0 hw.usb.debug: 0 hw.usb.timings.port_reset_delay: 50 hw.usb.timings.port_root_reset_delay: 250 hw.usb.timings.port_reset_recovery: 250 hw.usb.timings.port_powerup_delay: 300 hw.usb.timings.port_resume_delay: 40 hw.usb.timings.set_address_settle: 10 hw.usb.timings.resume_delay: 250 hw.usb.timings.resume_wait: 50 hw.usb.timings.resume_recovery: 50 hw.usb.timings.extra_power_up_time: 20 hw.usb.dev.debug: 0 hw.usb.template: 0 hw.usb.usb_lang_id: 9 hw.usb.usb_lang_mask: 255 hw.usb.ugen.debug: 0 hw.usb.uhub.debug: 0 hw.usb.power_timeout: 30 hw.usb.proc.debug: 0 hw.usb.no_cs_fail: 0 hw.usb.full_ddesc: 0 hw.usb.ukbd.debug: 0 hw.usb.ukbd.no_leds: 0 hw.usb.ukbd.pollrate: 0 hw.usb.ums.debug: 0 hw.usb.ucom.debug: 0 hw.usb.ucom.cons_unit: -1 hw.usb.ucom.cons_subunit: 0 hw.usb.ucom.cons_baud: 9600 hw.usb.uplcom.debug: 0 hw.watchdog.wd_last_u: 0 hw.watchdog.wd_last_u_secs: 0 hw.wi.txerate: 0 hw.wi.debug: 0 hw.xe.debug: 0 hw.intr_storm_threshold: 1000 hw.availpages: 4186716 hw.pagesizes: 4096 2097152 0 hw.bus.devctl_disable: 0 hw.bus.devctl_queue: 1000 hw.clockrate: 2500 hw.instruction_sse: 1 hw.via_feature_rng: 0 hw.via_feature_xcrypt: 0 hw.psm.tap_enabled: -1 hw.psm.tap_threshold: 25 hw.psm.tap_timeout: 125000 hw.bxe.debug: 0 hw.bxe.interrupt_mode: 2 hw.bxe.queue_count: 4 hw.bxe.max_rx_bufs: 0 hw.bxe.hc_rx_ticks: 25 hw.bxe.hc_tx_ticks: 50 hw.bxe.rx_budget: -1 hw.bxe.max_aggregation_size: 0 hw.bxe.mrrs: -1 hw.bxe.autogreeen: 0 hw.bxe.udp_rss: 0 hw.kbd.keymap_restrict_change: 0 hw.dmar.tbl_pagecnt: 0 hw.dmar.match_verbose: 0 hw.busdma.total_bpages: 2439 hw.busdma.zone0.total_bpages: 1024 hw.busdma.zone0.free_bpages: 1024 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffffff hw.busdma.zone0.alignment: 4096 hw.busdma.zone1.total_bpages: 1415 hw.busdma.zone1.free_bpages: 1415 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 10397 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 4096 hw.apic.enable_extint: 0 hw.mca.enabled: 1 hw.mca.amd10h_L1TP: 1 hw.mca.erratum383: 0 hw.mca.count: 0 hw.mca.interval: 3600 hw.mca.force_scan: 0 hw.ipmi.on: 1 hw.acpi.supported_sleep_state: S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S4 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: NONE hw.acpi.suspend_state: NONE hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 8.3C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 9.8C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 31.3C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 60 machdep.acpi_timer_freq: 3579545 machdep.enable_panic_key: 0 machdep.rtc_save_period: 1800 machdep.adjkerntz: 18000 machdep.wall_cmos_clock: 1 machdep.disable_rtc_set: 0 machdep.disable_mtrrs: 0 machdep.idle_mwait: 1 machdep.idle_available: spin, mwait, hlt, acpi machdep.idle: acpi machdep.nkpt: 24 machdep.max_ldt_segment: 1024 machdep.kdb_on_nmi: 1 machdep.panic_on_nmi: 1 machdep.prot_fault_translation: 0 machdep.uprintf_signal: 0 machdep.acpi_root: 1003264 machdep.i8254_freq: 1193182 machdep.disable_tsc: 0 machdep.disable_tsc_calibration: 0 machdep.tsc_freq: 2500140705 user.cs_path: user.bc_base_max: 0 user.bc_dim_max: 0 user.bc_scale_max: 0 user.bc_string_max: 0 user.coll_weights_max: 0 user.expr_nest_max: 0 user.line_max: 0 user.re_dup_max: 0 user.posix2_version: 0 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 0 user.tzname_max: 0 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 200112 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 200112 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 0 p1003_1b.fsync: 200112 p1003_1b.shared_memory_objects: 200112 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 compat.ia32.maxdsiz: 536870912 compat.ia32.maxssiz: 67108864 compat.ia32.maxvmem: 0 compat.linux.osname: Linux compat.linux.osrelease: 2.6.16 compat.linux.oss_version: 198144 compat.linux32.maxdsiz: 536870912 compat.linux32.maxssiz: 67108864 compat.linux32.maxvmem: 0 security.jail.jailed: 0 security.jail.vnet: 0 security.jail.jail_max_af_ips: 255 security.jail.set_hostname_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.sysvipc_allowed: 0 security.jail.allow_raw_sockets: 0 security.jail.chflags_allowed: 0 security.jail.mount_allowed: 0 security.jail.mount_devfs_allowed: 0 security.jail.mount_nullfs_allowed: 0 security.jail.mount_procfs_allowed: 0 security.jail.mount_tmpfs_allowed: 0 security.jail.mount_zfs_allowed: 0 security.jail.enforce_statfs: 2 security.jail.devfs_ruleset: 0 security.jail.param.jid: 0 security.jail.param.parent: 0 security.jail.param.name: 256 security.jail.param.path: 1024 security.jail.param.securelevel: 0 security.jail.param.enforce_statfs: 0 security.jail.param.devfs_ruleset: 0 security.jail.param.persist: 0 security.jail.param.dying: 0 security.jail.param.children.cur: 0 security.jail.param.children.max: 0 security.jail.param.host.: 0 security.jail.param.host.hostname: 256 security.jail.param.host.domainname: 256 security.jail.param.host.hostuuid: 64 security.jail.param.host.hostid: 0 security.jail.param.cpuset.id: 0 security.jail.param.ip4.: 0 security.jail.param.ip4.saddrsel: 0 security.jail.param.ip6.: 0 security.jail.param.ip6.saddrsel: 0 security.jail.param.allow.set_hostname: 0 security.jail.param.allow.sysvipc: 0 security.jail.param.allow.raw_sockets: 0 security.jail.param.allow.chflags: 0 security.jail.param.allow.quotas: 0 security.jail.param.allow.socket_af: 0 security.jail.param.allow.mount.: 0 security.jail.param.allow.mount.devfs: 0 security.jail.param.allow.mount.nullfs: 0 security.jail.param.allow.mount.procfs: 0 security.jail.param.allow.mount.tmpfs: 0 security.jail.param.allow.mount.zfs: 0 security.jail.param.linux.: 0 security.jail.param.linux.osname: 65 security.jail.param.linux.osrelease: 65 security.jail.param.linux.oss_version: 0 security.bsd.map_at_zero: 0 security.bsd.suser_enabled: 1 security.bsd.unprivileged_mlock: 1 security.bsd.see_other_uids: 1 security.bsd.see_other_gids: 1 security.bsd.conservative_signals: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.unprivileged_idprio: 0 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_uid: 0 security.bsd.hardlink_check_gid: 0 security.bsd.unprivileged_get_quota: 0 security.bsd.stack_guard_page: 0 security.bsd.unprivileged_syspmcs: 0 security.mac.version: 4 security.mac.max_slots: 4 security.mac.labeled: 0 security.mac.mmap_revocation: 1 security.mac.mmap_revocation_via_cow: 0 dev.xen.balloon.current: 0 dev.xen.balloon.target: 0 dev.xen.balloon.driver_pages: 0 dev.xen.balloon.hard_limit: 0 dev.xen.balloon.low_mem: 0 dev.xen.balloon.high_mem: 0 dev.xen.xsd_port: 0 dev.xen.xsd_kva: 0 dev.nexus.%parent: dev.nexus.0.%desc: dev.nexus.0.%driver: nexus dev.nexus.0.%location: dev.nexus.0.%pnpinfo: dev.nexus.0.%parent: root0 dev.ram.%parent: dev.ram.0.%desc: System RAM dev.ram.0.%driver: ram dev.ram.0.%location: dev.ram.0.%pnpinfo: dev.ram.0.%parent: nexus0 dev.cryptosoft.%parent: dev.cryptosoft.0.%desc: software crypto dev.cryptosoft.0.%driver: cryptosoft dev.cryptosoft.0.%location: dev.cryptosoft.0.%pnpinfo: dev.cryptosoft.0.%parent: nexus0 dev.acpi.%parent: dev.acpi.0.%desc: HP ProLiant dev.acpi.0.%driver: acpi dev.acpi.0.%location: dev.acpi.0.%pnpinfo: dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.%parent: dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.IBRG.MOMB dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=0 dev.acpi_sysresource.0.%parent: acpi0 dev.cpu.%parent: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2500 dev.cpu.0.freq_levels: 2500/-1 2187/-1 1875/-1 1562/-1 1250/-1 937/-1 625/-1 312/-1 dev.cpu.0.cx_supported: C1/1/1 C2/3/17 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 9138us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1/1 C2/3/17 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% last 9170us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.cx_supported: C1/1/1 C2/3/17 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% 0.00% last 13113us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.cx_supported: C1/1/1 C2/3/17 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% 0.00% last 24us dev.cpu.4.%desc: ACPI CPU dev.cpu.4.%driver: cpu dev.cpu.4.%location: handle=\_PR_.CPU4 dev.cpu.4.%pnpinfo: _HID=none _UID=0 dev.cpu.4.%parent: acpi0 dev.cpu.4.cx_supported: C1/1/1 C2/3/17 dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_usage: 100.00% 0.00% last 12898us dev.cpu.5.%desc: ACPI CPU dev.cpu.5.%driver: cpu dev.cpu.5.%location: handle=\_PR_.CPU5 dev.cpu.5.%pnpinfo: _HID=none _UID=0 dev.cpu.5.%parent: acpi0 dev.cpu.5.cx_supported: C1/1/1 C2/3/17 dev.cpu.5.cx_lowest: C1 dev.cpu.5.cx_usage: 100.00% 0.00% last 10093us dev.cpu.6.%desc: ACPI CPU dev.cpu.6.%driver: cpu dev.cpu.6.%location: handle=\_PR_.CPU6 dev.cpu.6.%pnpinfo: _HID=none _UID=0 dev.cpu.6.%parent: acpi0 dev.cpu.6.cx_supported: C1/1/1 C2/3/17 dev.cpu.6.cx_lowest: C1 dev.cpu.6.cx_usage: 100.00% 0.00% last 5339us dev.cpu.7.%desc: ACPI CPU dev.cpu.7.%driver: cpu dev.cpu.7.%location: handle=\_PR_.CPU7 dev.cpu.7.%pnpinfo: _HID=none _UID=0 dev.cpu.7.%parent: acpi0 dev.cpu.7.cx_supported: C1/1/1 C2/3/17 dev.cpu.7.cx_lowest: C1 dev.cpu.7.cx_usage: 100.00% 0.00% last 18731us dev.attimer.%parent: dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.IBRG.TIME dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.hpet.%parent: dev.hpet.0.%desc: High Precision Event Timer dev.hpet.0.%driver: hpet dev.hpet.0.%location: handle=\_SB_.PCI0.IBRG.HPET dev.hpet.0.%pnpinfo: _HID=PNP0103 _UID=0 dev.hpet.0.%parent: acpi0 dev.acpi_timer.%parent: dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.pci_link.%parent: dev.pci_link.0.%desc: ACPI PCI Link LNKA dev.pci_link.0.%driver: pci_link dev.pci_link.0.%location: handle=\_SB_.LNKA dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%desc: ACPI PCI Link LNKB dev.pci_link.1.%driver: pci_link dev.pci_link.1.%location: handle=\_SB_.LNKB dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%desc: ACPI PCI Link LNKC dev.pci_link.2.%driver: pci_link dev.pci_link.2.%location: handle=\_SB_.LNKC dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%desc: ACPI PCI Link LNKD dev.pci_link.3.%driver: pci_link dev.pci_link.3.%location: handle=\_SB_.LNKD dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%desc: ACPI PCI Link LNKE dev.pci_link.4.%driver: pci_link dev.pci_link.4.%location: handle=\_SB_.LNKE dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%desc: ACPI PCI Link LNKF dev.pci_link.5.%driver: pci_link dev.pci_link.5.%location: handle=\_SB_.LNKF dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%desc: ACPI PCI Link LNKG dev.pci_link.6.%driver: pci_link dev.pci_link.6.%location: handle=\_SB_.LNKG dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%desc: ACPI PCI Link LNKH dev.pci_link.7.%driver: pci_link dev.pci_link.7.%location: handle=\_SB_.LNKH dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 dev.pci_link.7.%parent: acpi0 dev.pcib.%parent: dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A03 _UID=0 dev.pcib.0.%parent: acpi0 dev.pcib.0.wake: 0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=2 function=0 handle=\_SB_.PCI0.PT02 dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x25e2 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.1.%parent: pci0 dev.pcib.1.domain: 0 dev.pcib.1.pribus: 0 dev.pcib.1.secbus: 9 dev.pcib.1.subbus: 18 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=0 function=0 handle=\_SB_.PCI0.PT02.IPE4 dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x3500 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.2.%parent: pci9 dev.pcib.2.domain: 0 dev.pcib.2.pribus: 9 dev.pcib.2.secbus: 10 dev.pcib.2.subbus: 15 dev.pcib.3.%desc: ACPI PCI-PCI bridge dev.pcib.3.%driver: pcib dev.pcib.3.%location: slot=0 function=0 handle=\_SB_.PCI0.PT02.IPE4.IPE1 dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x3510 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.3.%parent: pci10 dev.pcib.3.domain: 0 dev.pcib.3.pribus: 10 dev.pcib.3.secbus: 11 dev.pcib.3.subbus: 13 dev.pcib.4.%desc: PCI-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: slot=1 function=0 dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x3514 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.4.%parent: pci10 dev.pcib.4.domain: 0 dev.pcib.4.pribus: 10 dev.pcib.4.secbus: 14 dev.pcib.4.subbus: 14 dev.pcib.5.%desc: PCI-PCI bridge dev.pcib.5.%driver: pcib dev.pcib.5.%location: slot=2 function=0 dev.pcib.5.%pnpinfo: vendor=0x8086 device=0x3518 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.5.%parent: pci10 dev.pcib.5.domain: 0 dev.pcib.5.pribus: 10 dev.pcib.5.secbus: 15 dev.pcib.5.subbus: 15 dev.pcib.6.%desc: ACPI PCI-PCI bridge dev.pcib.6.%driver: pcib dev.pcib.6.%location: slot=0 function=3 handle=\_SB_.PCI0.PT02.P2P2 dev.pcib.6.%pnpinfo: vendor=0x8086 device=0x350c subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.6.%parent: pci9 dev.pcib.6.domain: 0 dev.pcib.6.pribus: 9 dev.pcib.6.secbus: 16 dev.pcib.6.subbus: 18 dev.pcib.7.%desc: ACPI PCI-PCI bridge dev.pcib.7.%driver: pcib dev.pcib.7.%location: slot=3 function=0 handle=\_SB_.PCI0.PT03 dev.pcib.7.%pnpinfo: vendor=0x8086 device=0x25e3 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.7.%parent: pci0 dev.pcib.7.domain: 0 dev.pcib.7.pribus: 0 dev.pcib.7.secbus: 6 dev.pcib.7.subbus: 8 dev.pcib.8.%desc: ACPI PCI-PCI bridge dev.pcib.8.%driver: pcib dev.pcib.8.%location: slot=4 function=0 handle=\_SB_.PCI0.PT04 dev.pcib.8.%pnpinfo: vendor=0x8086 device=0x25f8 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.8.%parent: pci0 dev.pcib.8.domain: 0 dev.pcib.8.pribus: 0 dev.pcib.8.secbus: 19 dev.pcib.8.subbus: 21 dev.pcib.9.%desc: PCI-PCI bridge dev.pcib.9.%driver: pcib dev.pcib.9.%location: slot=5 function=0 dev.pcib.9.%pnpinfo: vendor=0x8086 device=0x25e5 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.9.%parent: pci0 dev.pcib.9.domain: 0 dev.pcib.9.pribus: 0 dev.pcib.9.secbus: 22 dev.pcib.9.subbus: 22 dev.pcib.10.%desc: ACPI PCI-PCI bridge dev.pcib.10.%driver: pcib dev.pcib.10.%location: slot=6 function=0 handle=\_SB_.PCI0.PT06 dev.pcib.10.%pnpinfo: vendor=0x8086 device=0x25e6 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.10.%parent: pci0 dev.pcib.10.domain: 0 dev.pcib.10.pribus: 0 dev.pcib.10.secbus: 2 dev.pcib.10.subbus: 3 dev.pcib.11.%desc: ACPI PCI-PCI bridge dev.pcib.11.%driver: pcib dev.pcib.11.%location: slot=0 function=0 handle=\_SB_.PCI0.PT06.NB01 dev.pcib.11.%pnpinfo: vendor=0x1166 device=0x0103 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.11.%parent: pci2 dev.pcib.11.domain: 0 dev.pcib.11.pribus: 2 dev.pcib.11.secbus: 3 dev.pcib.11.subbus: 3 dev.pcib.12.%desc: ACPI PCI-PCI bridge dev.pcib.12.%driver: pcib dev.pcib.12.%location: slot=7 function=0 handle=\_SB_.PCI0.PT07 dev.pcib.12.%pnpinfo: vendor=0x8086 device=0x25e7 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.12.%parent: pci0 dev.pcib.12.domain: 0 dev.pcib.12.pribus: 0 dev.pcib.12.secbus: 4 dev.pcib.12.subbus: 5 dev.pcib.13.%desc: ACPI PCI-PCI bridge dev.pcib.13.%driver: pcib dev.pcib.13.%location: slot=0 function=0 handle=\_SB_.PCI0.PT07.NB02 dev.pcib.13.%pnpinfo: vendor=0x1166 device=0x0103 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.13.%parent: pci4 dev.pcib.13.domain: 0 dev.pcib.13.pribus: 4 dev.pcib.13.secbus: 5 dev.pcib.13.subbus: 5 dev.pcib.14.%desc: ACPI PCI-PCI bridge dev.pcib.14.%driver: pcib dev.pcib.14.%location: slot=30 function=0 handle=\_SB_.PCI0.IP2P dev.pcib.14.%pnpinfo: vendor=0x8086 device=0x244e subvendor=0x103c subdevice=0x31fe class=0x060401 dev.pcib.14.%parent: pci0 dev.pcib.14.domain: 0 dev.pcib.14.pribus: 0 dev.pcib.14.secbus: 1 dev.pcib.14.subbus: 1 dev.pci.%parent: dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%location: dev.pci.0.%pnpinfo: dev.pci.0.%parent: pcib0 dev.pci.0.wake: 0 dev.pci.9.%desc: ACPI PCI bus dev.pci.9.%driver: pci dev.pci.9.%location: dev.pci.9.%pnpinfo: dev.pci.9.%parent: pcib1 dev.pci.10.%desc: ACPI PCI bus dev.pci.10.%driver: pci dev.pci.10.%location: dev.pci.10.%pnpinfo: dev.pci.10.%parent: pcib2 dev.pci.11.%desc: ACPI PCI bus dev.pci.11.%driver: pci dev.pci.11.%location: dev.pci.11.%pnpinfo: dev.pci.11.%parent: pcib3 dev.pci.14.%desc: PCI bus dev.pci.14.%driver: pci dev.pci.14.%location: dev.pci.14.%pnpinfo: dev.pci.14.%parent: pcib4 dev.pci.15.%desc: PCI bus dev.pci.15.%driver: pci dev.pci.15.%location: dev.pci.15.%pnpinfo: dev.pci.15.%parent: pcib5 dev.pci.16.%desc: ACPI PCI bus dev.pci.16.%driver: pci dev.pci.16.%location: dev.pci.16.%pnpinfo: dev.pci.16.%parent: pcib6 dev.pci.6.%desc: ACPI PCI bus dev.pci.6.%driver: pci dev.pci.6.%location: dev.pci.6.%pnpinfo: dev.pci.6.%parent: pcib7 dev.pci.19.%desc: ACPI PCI bus dev.pci.19.%driver: pci dev.pci.19.%location: dev.pci.19.%pnpinfo: dev.pci.19.%parent: pcib8 dev.pci.22.%desc: PCI bus dev.pci.22.%driver: pci dev.pci.22.%location: dev.pci.22.%pnpinfo: dev.pci.22.%parent: pcib9 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%location: dev.pci.2.%pnpinfo: dev.pci.2.%parent: pcib10 dev.pci.3.%desc: ACPI PCI bus dev.pci.3.%driver: pci dev.pci.3.%location: dev.pci.3.%pnpinfo: dev.pci.3.%parent: pcib11 dev.pci.4.%desc: ACPI PCI bus dev.pci.4.%driver: pci dev.pci.4.%location: dev.pci.4.%pnpinfo: dev.pci.4.%parent: pcib12 dev.pci.5.%desc: ACPI PCI bus dev.pci.5.%driver: pci dev.pci.5.%location: dev.pci.5.%pnpinfo: dev.pci.5.%parent: pcib13 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%location: dev.pci.1.%pnpinfo: dev.pci.1.%parent: pcib14 dev.hostb.%parent: dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=0 function=0 dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x25d8 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.0.%parent: pci0 dev.hostb.1.%desc: Host to PCI bridge dev.hostb.1.%driver: hostb dev.hostb.1.%location: slot=16 function=0 dev.hostb.1.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.1.%parent: pci0 dev.hostb.2.%desc: Host to PCI bridge dev.hostb.2.%driver: hostb dev.hostb.2.%location: slot=16 function=1 handle=\_SB_.PCI0.CFG0 dev.hostb.2.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.2.%parent: pci0 dev.hostb.3.%desc: Host to PCI bridge dev.hostb.3.%driver: hostb dev.hostb.3.%location: slot=16 function=2 dev.hostb.3.%pnpinfo: vendor=0x8086 device=0x25f0 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.3.%parent: pci0 dev.hostb.4.%desc: Host to PCI bridge dev.hostb.4.%driver: hostb dev.hostb.4.%location: slot=17 function=0 dev.hostb.4.%pnpinfo: vendor=0x8086 device=0x25f1 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.4.%parent: pci0 dev.hostb.5.%desc: Host to PCI bridge dev.hostb.5.%driver: hostb dev.hostb.5.%location: slot=19 function=0 dev.hostb.5.%pnpinfo: vendor=0x8086 device=0x25f3 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.5.%parent: pci0 dev.hostb.6.%desc: Host to PCI bridge dev.hostb.6.%driver: hostb dev.hostb.6.%location: slot=21 function=0 dev.hostb.6.%pnpinfo: vendor=0x8086 device=0x25f5 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.6.%parent: pci0 dev.hostb.7.%desc: Host to PCI bridge dev.hostb.7.%driver: hostb dev.hostb.7.%location: slot=22 function=0 dev.hostb.7.%pnpinfo: vendor=0x8086 device=0x25f6 subvendor=0x103c subdevice=0x31fd class=0x060000 dev.hostb.7.%parent: pci0 dev.ciss.%parent: dev.ciss.0.%desc: HP Smart Array P400i dev.ciss.0.%driver: ciss dev.ciss.0.%location: slot=0 function=0 dev.ciss.0.%pnpinfo: vendor=0x103c device=0x3230 subvendor=0x103c subdevice=0x3235 class=0x010400 dev.ciss.0.%parent: pci6 dev.ciss.0.soft_reset: 0 dev.bce.%parent: dev.bce.0.%desc: HP NC373i Multifunction Gigabit Server Adapter (B2) dev.bce.0.%driver: bce dev.bce.0.%location: slot=0 function=0 dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x164c subvendor=0x103c subdevice=0x7038 class=0x020000 dev.bce.0.%parent: pci3 dev.bce.0.l2fhdr_error_count: 0 dev.bce.0.mbuf_alloc_failed_count: 201 dev.bce.0.mbuf_frag_count: 207 dev.bce.0.dma_map_addr_rx_failed_count: 0 dev.bce.0.dma_map_addr_tx_failed_count: 0 dev.bce.0.unexpected_attention_count: 0 dev.bce.0.stat_IfHcInOctets: 2277358024 dev.bce.0.stat_IfHCInBadOctets: 1278432 dev.bce.0.stat_IfHCOutOctets: 63981414158 dev.bce.0.stat_IfHCOutBadOctets: 0 dev.bce.0.stat_IfHCInUcastPkts: 27336477 dev.bce.0.stat_IfHCInMulticastPkts: 922 dev.bce.0.stat_IfHCInBroadcastPkts: 190372 dev.bce.0.stat_IfHCOutUcastPkts: 47820956 dev.bce.0.stat_IfHCOutMulticastPkts: 5 dev.bce.0.stat_IfHCOutBroadcastPkts: 1 dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.0.stat_Dot3StatsFCSErrors: 0 dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.0.stat_Dot3StatsLateCollisions: 0 dev.bce.0.stat_EtherStatsCollisions: 0 dev.bce.0.stat_EtherStatsFragments: 0 dev.bce.0.stat_EtherStatsJabbers: 0 dev.bce.0.stat_EtherStatsUndersizePkts: 0 dev.bce.0.stat_EtherStatsOversizePkts: 0 dev.bce.0.stat_EtherStatsPktsRx64Octets: 1022043 dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 24978056 dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 1333800 dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 39850 dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 52295 dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 101727 dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 dev.bce.0.stat_EtherStatsPktsTx64Octets: 46522 dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 1456745 dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 2273188 dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 929003 dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 2292647 dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 40822857 dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 dev.bce.0.stat_XonPauseFramesReceived: 0 dev.bce.0.stat_XoffPauseFramesReceived: 0 dev.bce.0.stat_OutXonSent: 0 dev.bce.0.stat_OutXoffSent: 0 dev.bce.0.stat_FlowControlDone: 0 dev.bce.0.stat_MacControlFramesReceived: 0 dev.bce.0.stat_XoffStateEntered: 0 dev.bce.0.stat_IfInFramesL2FilterDiscards: 3167 dev.bce.0.stat_IfInRuleCheckerDiscards: 0 dev.bce.0.stat_IfInFTQDiscards: 0 dev.bce.0.stat_IfInMBUFDiscards: 0 dev.bce.0.stat_IfInRuleCheckerP4Hit: 191293 dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.0.stat_CatchupInFTQDiscards: 0 dev.bce.0.stat_CatchupInMBUFDiscards: 0 dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 dev.bce.0.com_no_buffers: 0 dev.bce.1.%desc: HP NC373i Multifunction Gigabit Server Adapter (B2) dev.bce.1.%driver: bce dev.bce.1.%location: slot=0 function=0 dev.bce.1.%pnpinfo: vendor=0x14e4 device=0x164c subvendor=0x103c subdevice=0x7038 class=0x020000 dev.bce.1.%parent: pci5 dev.bce.1.l2fhdr_error_count: 0 dev.bce.1.mbuf_alloc_failed_count: 62 dev.bce.1.mbuf_frag_count: 63 dev.bce.1.dma_map_addr_rx_failed_count: 0 dev.bce.1.dma_map_addr_tx_failed_count: 0 dev.bce.1.unexpected_attention_count: 0 dev.bce.1.stat_IfHcInOctets: 3098977792 dev.bce.1.stat_IfHCInBadOctets: 1278866 dev.bce.1.stat_IfHCOutOctets: 111245491475 dev.bce.1.stat_IfHCOutBadOctets: 0 dev.bce.1.stat_IfHCInUcastPkts: 39648145 dev.bce.1.stat_IfHCInMulticastPkts: 922 dev.bce.1.stat_IfHCInBroadcastPkts: 190372 dev.bce.1.stat_IfHCOutUcastPkts: 78809756 dev.bce.1.stat_IfHCOutMulticastPkts: 0 dev.bce.1.stat_IfHCOutBroadcastPkts: 0 dev.bce.1.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.1.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.1.stat_Dot3StatsFCSErrors: 0 dev.bce.1.stat_Dot3StatsAlignmentErrors: 0 dev.bce.1.stat_Dot3StatsSingleCollisionFrames: 0 dev.bce.1.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.1.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.1.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.1.stat_Dot3StatsLateCollisions: 0 dev.bce.1.stat_EtherStatsCollisions: 0 dev.bce.1.stat_EtherStatsFragments: 0 dev.bce.1.stat_EtherStatsJabbers: 0 dev.bce.1.stat_EtherStatsUndersizePkts: 0 dev.bce.1.stat_EtherStatsOversizePkts: 0 dev.bce.1.stat_EtherStatsPktsRx64Octets: 1763213 dev.bce.1.stat_EtherStatsPktsRx65Octetsto127Octets: 36785937 dev.bce.1.stat_EtherStatsPktsRx128Octetsto255Octets: 1121050 dev.bce.1.stat_EtherStatsPktsRx256Octetsto511Octets: 36478 dev.bce.1.stat_EtherStatsPktsRx512Octetsto1023Octets: 48486 dev.bce.1.stat_EtherStatsPktsRx1024Octetsto1522Octets: 84275 dev.bce.1.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 dev.bce.1.stat_EtherStatsPktsTx64Octets: 37872 dev.bce.1.stat_EtherStatsPktsTx65Octetsto127Octets: 1359859 dev.bce.1.stat_EtherStatsPktsTx128Octetsto255Octets: 1511410 dev.bce.1.stat_EtherStatsPktsTx256Octetsto511Octets: 1523182 dev.bce.1.stat_EtherStatsPktsTx512Octetsto1023Octets: 2635770 dev.bce.1.stat_EtherStatsPktsTx1024Octetsto1522Octets: 71741663 dev.bce.1.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 dev.bce.1.stat_XonPauseFramesReceived: 0 dev.bce.1.stat_XoffPauseFramesReceived: 0 dev.bce.1.stat_OutXonSent: 0 dev.bce.1.stat_OutXoffSent: 0 dev.bce.1.stat_FlowControlDone: 0 dev.bce.1.stat_MacControlFramesReceived: 0 dev.bce.1.stat_XoffStateEntered: 0 dev.bce.1.stat_IfInFramesL2FilterDiscards: 3172 dev.bce.1.stat_IfInRuleCheckerDiscards: 0 dev.bce.1.stat_IfInFTQDiscards: 0 dev.bce.1.stat_IfInMBUFDiscards: 0 dev.bce.1.stat_IfInRuleCheckerP4Hit: 191294 dev.bce.1.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.1.stat_CatchupInFTQDiscards: 0 dev.bce.1.stat_CatchupInMBUFDiscards: 0 dev.bce.1.stat_CatchupInRuleCheckerP4Hit: 0 dev.bce.1.com_no_buffers: 0 dev.miibus.%parent: dev.miibus.0.%desc: MII bus dev.miibus.0.%driver: miibus dev.miibus.0.%location: dev.miibus.0.%pnpinfo: dev.miibus.0.%parent: bce0 dev.miibus.1.%desc: MII bus dev.miibus.1.%driver: miibus dev.miibus.1.%location: dev.miibus.1.%pnpinfo: dev.miibus.1.%parent: bce1 dev.brgphy.%parent: dev.brgphy.0.%desc: BCM5708C 1000BASE-T media interface dev.brgphy.0.%driver: brgphy dev.brgphy.0.%location: phyno=1 dev.brgphy.0.%pnpinfo: oui=0x1018 model=0x36 rev=0x6 dev.brgphy.0.%parent: miibus0 dev.brgphy.1.%desc: BCM5708C 1000BASE-T media interface dev.brgphy.1.%driver: brgphy dev.brgphy.1.%location: phyno=1 dev.brgphy.1.%pnpinfo: oui=0x1018 model=0x36 rev=0x6 dev.brgphy.1.%parent: miibus1 dev.uhci.%parent: dev.uhci.0.%desc: Intel 631XESB/632XESB/3100 USB controller USB-1 dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=29 function=0 dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x2688 subvendor=0x103c subdevice=0x31fe class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.1.%desc: Intel 631XESB/632XESB/3100 USB controller USB-2 dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=29 function=1 dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x2689 subvendor=0x103c subdevice=0x31fe class=0x0c0300 dev.uhci.1.%parent: pci0 dev.uhci.2.%desc: Intel 631XESB/632XESB/3100 USB controller USB-3 dev.uhci.2.%driver: uhci dev.uhci.2.%location: slot=29 function=2 dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x268a subvendor=0x103c subdevice=0x31fe class=0x0c0300 dev.uhci.2.%parent: pci0 dev.uhci.3.%desc: Intel 631XESB/632XESB/3100 USB controller USB-4 dev.uhci.3.%driver: uhci dev.uhci.3.%location: slot=29 function=3 dev.uhci.3.%pnpinfo: vendor=0x8086 device=0x268b subvendor=0x103c subdevice=0x31fe class=0x0c0300 dev.uhci.3.%parent: pci0 dev.uhci.4.%desc: UHCI (generic) USB controller dev.uhci.4.%driver: uhci dev.uhci.4.%location: slot=4 function=4 dev.uhci.4.%pnpinfo: vendor=0x103c device=0x3300 subvendor=0x103c subdevice=0x3305 class=0x0c0300 dev.uhci.4.%parent: pci1 dev.usbus.%parent: dev.usbus.0.%desc: dev.usbus.0.%driver: usbus dev.usbus.0.%location: dev.usbus.0.%pnpinfo: dev.usbus.0.%parent: uhci0 dev.usbus.1.%desc: dev.usbus.1.%driver: usbus dev.usbus.1.%location: dev.usbus.1.%pnpinfo: dev.usbus.1.%parent: uhci1 dev.usbus.2.%desc: dev.usbus.2.%driver: usbus dev.usbus.2.%location: dev.usbus.2.%pnpinfo: dev.usbus.2.%parent: uhci2 dev.usbus.3.%desc: dev.usbus.3.%driver: usbus dev.usbus.3.%location: dev.usbus.3.%pnpinfo: dev.usbus.3.%parent: uhci3 dev.usbus.4.%desc: dev.usbus.4.%driver: usbus dev.usbus.4.%location: dev.usbus.4.%pnpinfo: dev.usbus.4.%parent: ehci0 dev.usbus.5.%desc: dev.usbus.5.%driver: usbus dev.usbus.5.%location: dev.usbus.5.%pnpinfo: dev.usbus.5.%parent: uhci4 dev.ehci.%parent: dev.ehci.0.%desc: Intel 63XXESB USB 2.0 controller dev.ehci.0.%driver: ehci dev.ehci.0.%location: slot=29 function=7 dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x268c subvendor=0x103c subdevice=0x31fe class=0x0c0320 dev.ehci.0.%parent: pci0 dev.vgapci.%parent: dev.vgapci.0.%desc: VGA-compatible display dev.vgapci.0.%driver: vgapci dev.vgapci.0.%location: slot=3 function=0 dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x515e subvendor=0x103c subdevice=0x31fb class=0x030000 dev.vgapci.0.%parent: pci1 dev.ipmi.%parent: dev.ipmi.0.%desc: IPMI System Interface dev.ipmi.0.%driver: ipmi dev.ipmi.0.%location: slot=4 function=6 dev.ipmi.0.%pnpinfo: vendor=0x103c device=0x3302 subvendor=0x103c subdevice=0x3305 class=0x0c0701 dev.ipmi.0.%parent: pci1 dev.isab.%parent: dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.IBRG dev.isab.0.%pnpinfo: vendor=0x8086 device=0x2670 subvendor=0x0000 subdevice=0x0000 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.%parent: dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%location: dev.isa.0.%pnpinfo: dev.isa.0.%parent: isab0 dev.atapci.%parent: dev.atapci.0.%desc: Intel 63XXESB2 UDMA100 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=31 function=1 dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x269e subvendor=0x103c subdevice=0x31fe class=0x01018a dev.atapci.0.%parent: pci0 dev.ata.%parent: dev.ata.0.%desc: ATA channel dev.ata.0.%driver: ata dev.ata.0.%location: channel=0 dev.ata.0.%pnpinfo: dev.ata.0.%parent: atapci0 dev.acpi_tz.%parent: dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THM0 dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 dev.atdma.%parent: dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.IBRG.DMA0 dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.atkbdc.%parent: dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%location: handle=\_SB_.PCI0.IBRG.KBD_ dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 dev.atkbdc.0.%parent: acpi0 dev.atkbd.%parent: dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%location: dev.atkbd.0.%pnpinfo: dev.atkbd.0.%parent: atkbdc0 dev.psmcpnp.%parent: dev.psmcpnp.0.%desc: PS/2 mouse port dev.psmcpnp.0.%driver: psmcpnp dev.psmcpnp.0.%location: handle=\_SB_.PCI0.IBRG.PS2M dev.psmcpnp.0.%pnpinfo: _HID=PNP0F13 _UID=0 dev.psmcpnp.0.%parent: acpi0 dev.psm.%parent: dev.psm.0.%desc: PS/2 Mouse dev.psm.0.%driver: psm dev.psm.0.%location: dev.psm.0.%pnpinfo: dev.psm.0.%parent: atkbdc0 dev.uart.%parent: dev.uart.0.%desc: 16550 or compatible dev.uart.0.%driver: uart dev.uart.0.%location: handle=\_SB_.PCI0.IBRG.S417.COMA dev.uart.0.%pnpinfo: _HID=PNP0501 _UID=0 dev.uart.0.%parent: acpi0 dev.uart.1.%desc: Non-standard ns8250 class UART with FIFOs dev.uart.1.%driver: uart dev.uart.1.%location: dev.uart.1.%pnpinfo: dev.uart.1.%parent: isa0 dev.apic.%parent: dev.apic.0.%desc: APIC resources dev.apic.0.%driver: apic dev.apic.0.%location: dev.apic.0.%pnpinfo: dev.apic.0.%parent: nexus0 dev.orm.%parent: dev.orm.0.%desc: ISA Option ROMs dev.orm.0.%driver: orm dev.orm.0.%location: dev.orm.0.%pnpinfo: dev.orm.0.%parent: isa0 dev.sc.%parent: dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%location: dev.sc.0.%pnpinfo: dev.sc.0.%parent: isa0 dev.vga.%parent: dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%location: dev.vga.0.%pnpinfo: dev.vga.0.%parent: isa0 dev.atrtc.%parent: dev.atrtc.0.%desc: AT realtime clock dev.atrtc.0.%driver: atrtc dev.atrtc.0.%location: dev.atrtc.0.%pnpinfo: dev.atrtc.0.%parent: isa0 dev.est.%parent: dev.p4tcc.%parent: dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%location: dev.p4tcc.0.%pnpinfo: dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%driver: p4tcc dev.p4tcc.1.%location: dev.p4tcc.1.%pnpinfo: dev.p4tcc.1.%parent: cpu1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.2.%desc: CPU Frequency Thermal Control dev.p4tcc.2.%driver: p4tcc dev.p4tcc.2.%location: dev.p4tcc.2.%pnpinfo: dev.p4tcc.2.%parent: cpu2 dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.3.%desc: CPU Frequency Thermal Control dev.p4tcc.3.%driver: p4tcc dev.p4tcc.3.%location: dev.p4tcc.3.%pnpinfo: dev.p4tcc.3.%parent: cpu3 dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.4.%desc: CPU Frequency Thermal Control dev.p4tcc.4.%driver: p4tcc dev.p4tcc.4.%location: dev.p4tcc.4.%pnpinfo: dev.p4tcc.4.%parent: cpu4 dev.p4tcc.4.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.5.%desc: CPU Frequency Thermal Control dev.p4tcc.5.%driver: p4tcc dev.p4tcc.5.%location: dev.p4tcc.5.%pnpinfo: dev.p4tcc.5.%parent: cpu5 dev.p4tcc.5.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.6.%desc: CPU Frequency Thermal Control dev.p4tcc.6.%driver: p4tcc dev.p4tcc.6.%location: dev.p4tcc.6.%pnpinfo: dev.p4tcc.6.%parent: cpu6 dev.p4tcc.6.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.7.%desc: CPU Frequency Thermal Control dev.p4tcc.7.%driver: p4tcc dev.p4tcc.7.%location: dev.p4tcc.7.%pnpinfo: dev.p4tcc.7.%parent: cpu7 dev.p4tcc.7.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.%parent: dev.cpufreq.0.%desc: dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%location: dev.cpufreq.0.%pnpinfo: dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%desc: dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%location: dev.cpufreq.1.%pnpinfo: dev.cpufreq.1.%parent: cpu1 dev.cpufreq.2.%desc: dev.cpufreq.2.%driver: cpufreq dev.cpufreq.2.%location: dev.cpufreq.2.%pnpinfo: dev.cpufreq.2.%parent: cpu2 dev.cpufreq.3.%desc: dev.cpufreq.3.%driver: cpufreq dev.cpufreq.3.%location: dev.cpufreq.3.%pnpinfo: dev.cpufreq.3.%parent: cpu3 dev.cpufreq.4.%desc: dev.cpufreq.4.%driver: cpufreq dev.cpufreq.4.%location: dev.cpufreq.4.%pnpinfo: dev.cpufreq.4.%parent: cpu4 dev.cpufreq.5.%desc: dev.cpufreq.5.%driver: cpufreq dev.cpufreq.5.%location: dev.cpufreq.5.%pnpinfo: dev.cpufreq.5.%parent: cpu5 dev.cpufreq.6.%desc: dev.cpufreq.6.%driver: cpufreq dev.cpufreq.6.%location: dev.cpufreq.6.%pnpinfo: dev.cpufreq.6.%parent: cpu6 dev.cpufreq.7.%desc: dev.cpufreq.7.%driver: cpufreq dev.cpufreq.7.%location: dev.cpufreq.7.%pnpinfo: dev.cpufreq.7.%parent: cpu7 dev.uhub.%parent: dev.uhub.0.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%location: dev.uhub.0.%pnpinfo: dev.uhub.0.%parent: usbus1 dev.uhub.1.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%location: dev.uhub.1.%pnpinfo: dev.uhub.1.%parent: usbus0 dev.uhub.2.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%location: dev.uhub.2.%pnpinfo: dev.uhub.2.%parent: usbus4 dev.uhub.3.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.3.%driver: uhub dev.uhub.3.%location: dev.uhub.3.%pnpinfo: dev.uhub.3.%parent: usbus3 dev.uhub.4.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.4.%driver: uhub dev.uhub.4.%location: dev.uhub.4.%pnpinfo: dev.uhub.4.%parent: usbus2 dev.uhub.5.%desc: 0x103c UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.5.%driver: uhub dev.uhub.5.%location: dev.uhub.5.%pnpinfo: dev.uhub.5.%parent: usbus5 dev.ukbd.%parent: dev.ukbd.0.%desc: Virtual Keyboard dev.ukbd.0.%driver: ukbd dev.ukbd.0.%location: bus=0 hubaddr=1 port=1 devaddr=2 interface=0 dev.ukbd.0.%pnpinfo: vendor=0x03f0 product=0x1027 devclass=0x00 devsubclass=0x00 sernum="" release=0x0002 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 dev.ukbd.0.%parent: uhub1 dev.ums.%parent: dev.ums.0.%desc: Virtual Mouse dev.ums.0.%driver: ums dev.ums.0.%location: bus=0 hubaddr=1 port=1 devaddr=2 interface=1 dev.ums.0.%pnpinfo: vendor=0x03f0 product=0x1027 devclass=0x00 devsubclass=0x00 sernum="" release=0x0002 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 dev.ums.0.%parent: uhub1 dev.ums.0.parseinfo: i1: X:r0, p8, s8; Y:r0, p16, s8; B1:r0, p0, s1; B2:r0, p1, s1; B3:r0, p2, s1; dev.uplcom.%parent: dev.uplcom.0.%desc: Prolific Technology Inc. USB-Serial Controller D, class 0/0, rev 1.10/4.00, addr 2 dev.uplcom.0.%driver: uplcom dev.uplcom.0.%location: bus=1 hubaddr=1 port=1 devaddr=2 interface=0 dev.uplcom.0.%pnpinfo: vendor=0x067b product=0x2303 devclass=0x00 devsubclass=0x00 sernum="" release=0x0400 mode=host intclass=0xff intsubclass=0x00 intprotocol=0x00 ttyname=U0 ttyports=1 dev.uplcom.0.%parent: uhub0 dev.uplcom.0.ttyname: U0 dev.uplcom.0.ttyports: 1 hptmv.status: RocketRAID 18xx SATA Controller driver Version v1.16 kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 109 kstat.zfs.misc.zio_trim.failed: 0 kstat.zfs.misc.xuio_stats.onloan_read_buf: 0 kstat.zfs.misc.xuio_stats.onloan_write_buf: 0 kstat.zfs.misc.xuio_stats.read_buf_copied: 0 kstat.zfs.misc.xuio_stats.read_buf_nocopy: 0 kstat.zfs.misc.xuio_stats.write_buf_copied: 0 kstat.zfs.misc.xuio_stats.write_buf_nocopy: 269861 kstat.zfs.misc.zfetchstats.hits: 138270999 kstat.zfs.misc.zfetchstats.misses: 33608242 kstat.zfs.misc.zfetchstats.colinear_hits: 12496 kstat.zfs.misc.zfetchstats.colinear_misses: 33595758 kstat.zfs.misc.zfetchstats.stride_hits: 135331775 kstat.zfs.misc.zfetchstats.stride_misses: 51809 kstat.zfs.misc.zfetchstats.reclaim_successes: 485007 kstat.zfs.misc.zfetchstats.reclaim_failures: 33110775 kstat.zfs.misc.zfetchstats.streams_resets: 2057 kstat.zfs.misc.zfetchstats.streams_noresets: 2939172 kstat.zfs.misc.zfetchstats.bogus_streams: 0 kstat.zfs.misc.zcompstats.attempts: 4525377 kstat.zfs.misc.zcompstats.empty: 70427 kstat.zfs.misc.zcompstats.skipped_insufficient_gain: 212315 kstat.zfs.misc.arcstats.hits: 71628686 kstat.zfs.misc.arcstats.misses: 5374019 kstat.zfs.misc.arcstats.demand_data_hits: 45721762 kstat.zfs.misc.arcstats.demand_data_misses: 204017 kstat.zfs.misc.arcstats.demand_metadata_hits: 23807762 kstat.zfs.misc.arcstats.demand_metadata_misses: 459411 kstat.zfs.misc.arcstats.prefetch_data_hits: 1068568 kstat.zfs.misc.arcstats.prefetch_data_misses: 4439809 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 1030594 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 270782 kstat.zfs.misc.arcstats.mru_hits: 7898276 kstat.zfs.misc.arcstats.mru_ghost_hits: 70775 kstat.zfs.misc.arcstats.mfu_hits: 62189559 kstat.zfs.misc.arcstats.mfu_ghost_hits: 539415 kstat.zfs.misc.arcstats.allocated: 6917433 kstat.zfs.misc.arcstats.deleted: 4576446 kstat.zfs.misc.arcstats.stolen: 1802887 kstat.zfs.misc.arcstats.recycle_miss: 144327 kstat.zfs.misc.arcstats.mutex_miss: 350 kstat.zfs.misc.arcstats.evict_skip: 55338 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 197708696064 kstat.zfs.misc.arcstats.evict_l2_ineligible: 150685407744 kstat.zfs.misc.arcstats.hash_elements: 413749 kstat.zfs.misc.arcstats.hash_elements_max: 820251 kstat.zfs.misc.arcstats.hash_collisions: 6971217 kstat.zfs.misc.arcstats.hash_chains: 95225 kstat.zfs.misc.arcstats.hash_chain_max: 20 kstat.zfs.misc.arcstats.p: 8060231540 kstat.zfs.misc.arcstats.c: 12006640591 kstat.zfs.misc.arcstats.c_min: 1952117248 kstat.zfs.misc.arcstats.c_max: 15616937984 kstat.zfs.misc.arcstats.size: 11779040864 kstat.zfs.misc.arcstats.hdr_size: 106454016 kstat.zfs.misc.arcstats.data_size: 10649110528 kstat.zfs.misc.arcstats.other_size: 1023476320 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_asize: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.l2_compress_successes: 0 kstat.zfs.misc.arcstats.l2_compress_zeros: 0 kstat.zfs.misc.arcstats.l2_compress_failures: 0 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 3033782 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.arcstats.duplicate_buffers: 0 kstat.zfs.misc.arcstats.duplicate_buffers_size: 0 kstat.zfs.misc.arcstats.duplicate_reads: 2 kstat.zfs.misc.vdev_cache_stats.delegations: 0 kstat.zfs.misc.vdev_cache_stats.hits: 0 kstat.zfs.misc.vdev_cache_stats.misses: 0 Can I get some ideas on: 1) what MIGHT need tweaking 2) would (k|d)trace help? 3) what else could we find out what's being told no memory? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:04:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6212AB20; Fri, 25 Jul 2014 16:04:04 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id E16032159; Fri, 25 Jul 2014 16:04:03 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hKZwK37dSz1Fl; Fri, 25 Jul 2014 18:04:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1406304237; x=1408896238; bh=5tU xIkHU41RaDcB2wIFMAbcYiWVzkkWlF3LWCpOJ/hY=; b=o92OJgw8PAAXl0G6p5X rHDOoT2rKFMDC+uF9/FL1NaVqKfGCbKn/3HMhDC6pyScpxgRdwXnt5vk5lw9gg7i MC4yUCrc9oUkXNwwndWr97+r4gtsgL37kIzA3BOlp1ngOJgffYC3Hvg6l8eYEUY/ SSe4+A9/V85B91FMOvCLu33Y= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id Ao8VxMVqEYjR; Fri, 25 Jul 2014 18:03:57 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Fri, 25 Jul 2014 18:03:57 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hKZwF2rQCzVN; Fri, 25 Jul 2014 18:03:57 +0200 (CEST) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Fri, 25 Jul 2014 18:03:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Jul 2014 18:03:57 +0200 From: Mark Martinec To: freebsd-current@freebsd.org, Freebsd fs Subject: Re: zfs send/recv: STILL invalid Backup Stream Organization: J. Stefan Institute In-Reply-To: <20140725134125.GA19293@thebighonker.lerctr.org> References: <3d2aac84d962a703fbf56a864ba5f19c@mailbox.ijs.si> <9eef3e7e964cb33fd163cc2f9300f326@mailbox.ijs.si> <53D1AB3D.1060205@freebsd.org> <33c478c3120c21d6cb9c325cc1119cf8@thebighonker.lerctr.org> <60845088153247fa31c50c9f52ef72cb@mailbox.ijs.si> <20140725134125.GA19293@thebighonker.lerctr.org> Message-ID: <2f191a3e72b9d94a15128de806f8d1c8@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:04:04 -0000 2014-07-25 15:41, Larry Rosenman wrote: > On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote: >> Don't know, I'd guess some network-related memory limit is being hit >> on the sending site. >> >> Why not try to decouple the 'zfs send' from a network copy and ssh: >> Login to a remote side, do a 'zfs send' to some local temporary file >> there, then feed that file to ssh and send it over to a home host, >> where it can be piped into some simple program like md5 or 'wc -c' >> instead of a zfs recv. >> > I think I've done that, but it sort of defeats the purpose, Does it? If you are lucky it would fail again, but this time you'd know if it was a zfs or a network problem. > as the stream becomes a big file on disk. If it's an incremental stream and you have sufficient free space available, than it's all fine and you should try that. If storage is a problem you may try piping /dev/zero or /dev/random through ssh to feed a remote consumer, simulating a huge stream, and hope that it will eventually fail. > I'd like to get some help chasing what parameter(s) need to be fixed > here. [...] > Can I get some ideas on: > 1) what MIGHT need tweaking > 2) would (k|d)trace help? > 3) what else could we find out what's being told no memory? Sorry, not deep enough into fs or network to be able to tell. My guess it that it's a networking issue (not zfs), and not directly related to virtual memory or swap or ARC management. > To: freebsd-current@freebsd.org, Freebsd fs If you'd be able to demonstrate that this is unrelated to zfs, then the freebsd-net@freebsd.org mailing list would perhaps be a suitable place to continue this thread. Mark From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:16:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9569DE5E for ; Fri, 25 Jul 2014 16:16:31 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (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 539D22277 for ; Fri, 25 Jul 2014 16:16:30 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XAhsA-000L3B-Qc; Fri, 25 Jul 2014 15:57:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6PFvTYg001274; Fri, 25 Jul 2014 09:57:29 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+SFTR9z3Md4pn/sBkUsfR+ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Several minor annoyances on Current From: Ian Lepore To: Beeblebrox In-Reply-To: <1406289867854-5931678.post@n5.nabble.com> References: <1406282699515-5931653.post@n5.nabble.com> <1406287169575-5931665.post@n5.nabble.com> <1406289867854-5931678.post@n5.nabble.com> Content-Type: multipart/mixed; boundary="=-TBR0ovB1JJcy/N8kArLS" Date: Fri, 25 Jul 2014 09:57:28 -0600 Message-ID: <1406303848.56408.16.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:16:31 -0000 --=-TBR0ovB1JJcy/N8kArLS Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2014-07-25 at 05:04 -0700, Beeblebrox wrote: > Kurt Jaeger wrote: > > > Can you check whether one of your ethernet-ports has a double life > > as IPMI port and that one sends out the DHCP ? > > No such setup. This is my workstation, with wake-on-lan and pxe-boot > disabled in bios. > Checking boot messages provides a little more insight - Its not one but > *both* NIC's that look for DHCP. Also, this is before root gets mounted, so > what's in rc.conf is irrelevant: > > Sending DHCP Discover packet from interface re0 (mac#) > Sending DHCP Discover packet from interface re1 (mac#) > Received DHCP Offer packet on re0 from 192.168.1.1 (accepted) > Received DHCP Offer packet on re0 from 192.168.1.1 (ignored) > Received DHCP Offer packet on re0 from 192.168.1.1 (ignored) > Sending DHCP Request packet from interface re0 (mac#) > Received DHCP Ack packet on re0 from 192.168.1.1 (accepted) > DHCP timeout for interface re1 > re0 at 192.168.1.11 server 192.168.1.1 > subnet mask 255.255.255.0 router 192.168.1.1 > Adjusted interface re0 > Shutdown interface re1 > Trying to mount root from zfs:bsd []... > > I compile and use the same kernel for both host and pxe-booted diskless > clients. So my kernel config file has > options NFSCL # Network Filesystem Client > options NFS_ROOT # NFS usable as /, requires NFSCL > options BOOTP # Needed for non-btx PXE > options BOOTP_NFSROOT # Needed for non-btx PXE > It's probably what's causing this behavior. Kernel must receive IP before it > can try and mount an NFS volume as root. However, I would have assumed that > the "vfs.root.mountfrom=" setting in loader.conf would be read before such > attempt... > I made changes last year that allowed vfs.root.mountfrom to unconditionally override any path provided by the bootp/dhcp server. While it overrides the server-provided path, it doesn't prevent contacting the server (the override may be for a different nfs path). See http://svnweb.freebsd.org/base?view=revision&revision=253847 for details. I didn't consider at the time that someone might want to avoid doing any bootp configuration at all, but in retrospect I can think of several good reasons to turn off bootp on a per-boot basis. The attached patch provides a knob for that, I'll commit it if there are no objections. -- Ian --=-TBR0ovB1JJcy/N8kArLS Content-Disposition: inline; filename="bootp_disable.diff" Content-Type: text/x-patch; name="bootp_disable.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/nfs/bootp_subr.c =================================================================== --- sys/nfs/bootp_subr.c (revision 268986) +++ sys/nfs/bootp_subr.c (working copy) @@ -1551,8 +1551,11 @@ bootpc_init(void) struct nfsv3_diskless *nd; struct thread *td; int timeout; - int delay; + int delay, disable; + if (TUNABLE_INT_FETCH("vfs.nfs.bootp_disable", &disable) && disable) + return; + timeout = BOOTP_IFACE_WAIT_TIMEOUT * hz; delay = hz / 10; --=-TBR0ovB1JJcy/N8kArLS-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:36:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5751B370 for ; Fri, 25 Jul 2014 16:36:24 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3689F2425 for ; Fri, 25 Jul 2014 16:36:23 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XAiTm-0000Gs-KP for freebsd-current@freebsd.org; Fri, 25 Jul 2014 09:36:22 -0700 Date: Fri, 25 Jul 2014 09:36:22 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20140725193552.0a814f1c@rsbsd.rsb> In-Reply-To: <1406303848.56408.16.camel@revolution.hippie.lan> References: <1406282699515-5931653.post@n5.nabble.com> <1406287169575-5931665.post@n5.nabble.com> <1406289867854-5931678.post@n5.nabble.com> <1406303848.56408.16.camel@revolution.hippie.lan> Subject: Re: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:36:24 -0000 > ... in retrospect I can think of > several good reasons to turn off bootp on a per-boot basis. The > attached patch provides a knob for that, I'll commit it if there are > no objections. Thanks - a knob in /boot/loader.conf as vfs.nfs.bootp_disable="YES" should do nicely. Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931753.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:41:11 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCBD95EF for ; Fri, 25 Jul 2014 16:41:10 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FFC72477 for ; Fri, 25 Jul 2014 16:41:10 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 1D66514E10FA for ; Fri, 25 Jul 2014 20:40:59 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id CE3287E0D0D for ; Fri, 25 Jul 2014 20:40:58 +0400 (MSK) Received: from 93.91.10.59.tel.ru (93.91.10.59.tel.ru [93.91.10.59]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id SuUdGD4iqu-ewsqIS26; Fri, 25 Jul 2014 20:40:58 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 97494440-bdd8-4b87-9b69-536fa8f0791f Message-ID: <53D28899.3080704@passap.ru> Date: Fri, 25 Jul 2014 20:40:57 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: [make xdev, libatf]: error: cstdarg: No such file or directory X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:41:11 -0000 Hi All! Here are errors I get with sources at r269089. ----- % uname -a FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r269019: Wed Jul 23 23:24:47 SAMT 2014 bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 % sudo make -C /usr/src TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev [...] ===> lib/atf (obj,depend,all,install) ===> lib/atf/libatf-c (obj) ===> lib/atf/libatf-c++ (obj) ===> lib/atf/libatf-c (depend) ===> lib/atf/libatf-c++ (depend) rm -f .depend CC='cc -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ -B//usr/armv6-fr eebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a -DHAVE_CONFIG_H -DATF_A RCH='"arm"' -DATF_BUILD_CC='"cc -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' -DATF_BUILD_CFLAGS=' "-O -pipe "' -DATF_BUILD_CPP='"cpp -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/ar mv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' -DATF_BUILD_CPPF LAGS='""' -DATF_BUILD_CXX='"c++ -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' -DATF_BUILD_CXXFLAGS ='"-O -pipe "' -DATF_CONFDIR='"/etc/atf"' -DATF_C_TESTS_BASE='"/usr/tests/lib/atf/libatf-c"' -DATF_INCLUDEDIR='"/usr/include" ' -DATF_LIBDIR='"/usr/lib"' -DATF_LIBEXECDIR='"/usr/libexec"' -DATF_MACHINE='"armv6"' -DATF_M4='"/usr/bin/m4"' -DATF_PKGDATADI R='"/usr/share/atf"' -DATF_SHELL='"/bin/sh"' -DATF_WORKDIR='"/tmp"' -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../li batf-c -I. -DHAVE_CONFIG_H /usr/src/contrib/atf/atf-c++/detail/application.cpp /usr/src/contrib/atf/atf-c++/build.cpp / usr/src/contrib/atf/atf-c++/check.cpp /usr/src/contrib/atf/atf-c++/config.cpp /usr/src/contrib/atf/atf-c++/detail/env.cpp /usr /src/contrib/atf/atf-c++/detail/exceptions.cpp /usr/src/contrib/atf/atf-c++/detail/fs.cpp /usr/src/contrib/atf/atf-c++/detail/ process.cpp /usr/src/contrib/atf/atf-c++/tests.cpp /usr/src/contrib/atf/atf-c++/detail/text.cpp /usr/src/contrib/atf/atf-c++/u tils.cpp /usr/src/contrib/atf/atf-c++/detail/application.cpp:38:19: error: cstdarg: No such file or directory /usr/src/contrib/atf/atf-c++/detail/application.cpp:39:18: error: cstdio: No such file or directory /usr/src/contrib/atf/atf-c++/detail/application.cpp:40:19: error: cstdlib: No such file or directory [...] ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:51:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 076A49A7 for ; Fri, 25 Jul 2014 16:51:48 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 9B4A425F0 for ; Fri, 25 Jul 2014 16:51:47 +0000 (UTC) X-AuditID: 1209190d-f79c06d000002f07-ae-53d28b1be46c 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 6D.69.12039.B1B82D35; Fri, 25 Jul 2014 12:51:39 -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 s6PGpdT8024362; Fri, 25 Jul 2014 12:51:39 -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 s6PGpaxV022140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Jul 2014 12:51:38 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6PGpaF0002973; Fri, 25 Jul 2014 12:51:36 -0400 (EDT) Date: Fri, 25 Jul 2014 12:51:35 -0400 (EDT) From: Benjamin Kaduk To: Beeblebrox Subject: Re: Several minor annoyances on Current In-Reply-To: <1406282699515-5931653.post@n5.nabble.com> Message-ID: References: <1406282699515-5931653.post@n5.nabble.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrCvdfSnY4MgaG4s5bz4wWaw/t4HJ gcnjcJO0x4xP81kCmKK4bFJSczLLUov07RK4Mg5t9yrYyVLx6fIc9gbGw8xdjJwcEgImEpNe nWeDsMUkLtxbD2RzcQgJzGaSmD7rL5SzkVFi48cvjBDOISaJs0duM0E4DYwSE7/9YgTpZxHQ ljjfuY0JxGYTUJGY+WYj2FwRAVWJ589OgNnMAvIS/69cBqrh4BAWMJB40WQOEuYUMJdo2N8M NoZXwFGiuXsCWLmQgJnExCu7wUaKCuhIrN4/hQWiRlDi5MwnLBAjLSXO/bnONoFRcBaS1Cwk qQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCw1SSdwfju4NKhxgFOBiV eHgDqi4FC7EmlhVX5h5ilORgUhLl7WoBCvEl5adUZiQWZ8QXleakFh9ilOBgVhLh/QuS401J rKxKLcqHSUlzsCiJ8761tgoWEkhPLEnNTk0tSC2CycpwcChJ8HZ0AjUKFqWmp1akZeaUIKSZ ODhBhvMADS8CqeEtLkjMLc5Mh8ifYtTlWLT/ZTeTEEtefl6qlDjvyQ6gIgGQoozSPLg5sPTy ilEc6C1h3hkgo3iAqQlu0iugJUxAS14lnAdZUpKIkJJqYIx8/e1m0xd2docDef8Ed94sujZr 2mO5RTLOM9zVtmz9uH6Hx322OZcPOzzyvurabHLym0h/zndRhu7f7VP+tpWc9H3Vmx/44Oet BXf+l6h2GJUyGed0HH/920rFKSvcazfvz/Mxj01KPX/tF0nuk10far2wNVH3svnmmj8KAUe3 Ke9kU36SUqjEUpyRaKjFXFScCAC6oTj3CgMAAA== Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:51:48 -0000 On Fri, 25 Jul 2014, Beeblebrox wrote: > Hello. Several questions for 11-Current: > > * I keep getting .core (gedit.core, midori.core, etc) files being > created either in /home/myuser or in the folder I run the command in on > terminal emulator (for example if I'm in ~/mydocs on terminal and run "$ > gedit filename", that folder gets a gedit.core file). Any way to stop this? This seems like a job for ulimit. Though, I would be more curious about why your applications are crashing so as to generate core files in the first place. -Ben From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 17:24:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69276FA5 for ; Fri, 25 Jul 2014 17:24:16 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4912328D9 for ; Fri, 25 Jul 2014 17:24:16 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XAjE7-0005Hi-F9 for freebsd-current@freebsd.org; Fri, 25 Jul 2014 10:24:15 -0700 Date: Fri, 25 Jul 2014 10:24:15 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20140725202341.684d51d6@rsbsd.rsb> In-Reply-To: References: <1406282699515-5931653.post@n5.nabble.com> Subject: Re: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:24:16 -0000 Hi > This seems like a job for ulimit. Damien pointed that out as: ulimit -c 0 > Though, I would be more curious about why your applications are > crashing so as to generate core files in the first place. Well, this MAJOR annoyance lies somewhere between Radeon-KMS and gnome3's g= raphics/cairo. This started some 3 months back and I can only get some leve= l of normalcy when I build cairo using "with_debug=3D1". Very strange. Also= , a number of apps just flat-out refuse to start; most notably mozilla's fi= refox & seamonkey. Monsieur P=C3=A9dron is aware of the problem, although a= s stated it's been over 3 months. While I'm on a roll :P One major peeve is that installed apps fail to create an icon in the deskto= p menu structure. I know that a) maintainer must set DESKTOP_ENTRIES in the Makefile OR b) users can add appname.desktop in /usr/local/share/applications/ but as a dreamer, I know there has to be a better solution other than badge= ring maintainers or slogging through the task of adding menu shortcut items= ? ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-= minor-annoyances-on-Current-tp5931653p5931761.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 17:55:16 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4FE5507 for ; Fri, 25 Jul 2014 17:55:16 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 B4C2D2B3E for ; Fri, 25 Jul 2014 17:55:15 +0000 (UTC) Received: from [192.168.200.205] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 437B4193A3A for ; Fri, 25 Jul 2014 17:55:09 +0000 (UTC) Subject: Re: sys/boot unbuildable [solved] From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-current In-Reply-To: <1406051578.1063.33.camel@bruno> References: <1406051578.1063.33.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Jul 2014 10:55:08 -0700 Message-ID: <1406310908.1080.4.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:55:16 -0000 On Tue, 2014-07-22 at 10:52 -0700, Sean Bruno wrote: > I can't quite see what the difference in building sys/i386/loader and > sys/i386/zfsloader is outside of the obvious zfs loader support flag. > This is now fixed in head. Thanks to Simon for the bmake assist. sean > But, loader will build, and zfsloader will not. Clang will give me a > nice error that tells me how I could fix this, but since loader builds > fine I suspect something buildsystem related is occuring here? > > cc -O2 -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../ficl > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../ficl/i386 > -DLOADER_GZIP_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT > -DLOADER_MBR_SUPPORT > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../common -I. > -Wall -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/.. > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../btx/lib > -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -msoft-float -m32 -std=gnu99 -Qunused-arguments > -DLOADER_PREFER_AMD64 > -c /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../loader/main.c > /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../loader/main.c:38:10: error: 'machine/bootinfo.h' file not found with include; use "quotes" instead > #include > ^~~~~~~~~~~~~~~~~~~~ > "machine/bootinfo.h" > 1 error generated. > *** Error code 1 > > Stop. > make: stopped in /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 17:55:33 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 771D7609 for ; Fri, 25 Jul 2014 17:55:33 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 57EA82B51 for ; Fri, 25 Jul 2014 17:55:33 +0000 (UTC) Received: from [192.168.200.205] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id AA303193A3A for ; Fri, 25 Jul 2014 17:55:32 +0000 (UTC) Subject: Re: libstand modification [committed] From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-current In-Reply-To: <1406043907.1063.27.camel@bruno> References: <1406043907.1063.27.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Jul 2014 10:55:32 -0700 Message-ID: <1406310932.1080.5.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:55:33 -0000 On Tue, 2014-07-22 at 08:45 -0700, Sean Bruno wrote: > https://phabric.freebsd.org/D443 > > the 64bit version of userboot has been screaming about bit shifting > operators for a while now. > > The short explanation, amd64 sizeof(long) != i386 sizeof(long). > > The long explanation is in the phabric diff and comments. > > I see no reason to not commit this, but thought I'd throw it here for > your commentary. > > sean This is now in head. sean From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 18:00:02 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D701C7A4 for ; Fri, 25 Jul 2014 18:00:02 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 A1A842B94 for ; Fri, 25 Jul 2014 18:00:02 +0000 (UTC) Received: from [192.168.200.205] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id E1DF5193A3A; Fri, 25 Jul 2014 18:00:01 +0000 (UTC) Subject: Re: [make xdev, libatf]: error: cstdarg: No such file or directory From: Sean Bruno Reply-To: sbruno@freebsd.org To: Boris Samorodov In-Reply-To: <53D28899.3080704@passap.ru> References: <53D28899.3080704@passap.ru> Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Jul 2014 11:00:01 -0700 Message-ID: <1406311201.1080.7.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:00:03 -0000 On Fri, 2014-07-25 at 20:40 +0400, Boris Samorodov wrote: > Hi All! > > Here are errors I get with sources at r269089. > I am at 269090. make xdev TARGET=mips TARGET_ARCH=mips64 just finished for me. At this point, drop the rest of the options from the build as dim, bsdimp and sjg have fixed most of the issues requiring that. There is a fatal depend bug of some kind occuring if /usr/obj/ has builds in it. Try removing /usr/obj/* and then build again. sean > ----- > % uname -a > FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r269019: Wed > Jul 23 23:24:47 SAMT 2014 > bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 > > % sudo make -C /usr/src TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 > WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 > WITHOUT_CLANG_IS_CC=1 xdev > [...] > ===> lib/atf (obj,depend,all,install) > ===> lib/atf/libatf-c (obj) > ===> lib/atf/libatf-c++ (obj) > ===> lib/atf/libatf-c (depend) > ===> lib/atf/libatf-c++ (depend) > rm -f .depend > CC='cc -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ > -B//usr/armv6-fr > eebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin > -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a -DHAVE_CONFIG_H > -DATF_A > RCH='"arm"' -DATF_BUILD_CC='"cc -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- > freebsd/ -B//usr/armv6-freebsd/usr/libexec > -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' > -DATF_BUILD_CFLAGS=' > "-O -pipe "' -DATF_BUILD_CPP='"cpp -isystem > //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib > --sysroot=//usr/ar > mv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec > -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' > -DATF_BUILD_CPPF > LAGS='""' -DATF_BUILD_CXX='"c++ -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- > freebsd/ -B//usr/armv6-freebsd/usr/libexec > -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' > -DATF_BUILD_CXXFLAGS > ='"-O -pipe "' -DATF_CONFDIR='"/etc/atf"' > -DATF_C_TESTS_BASE='"/usr/tests/lib/atf/libatf-c"' > -DATF_INCLUDEDIR='"/usr/include" > ' -DATF_LIBDIR='"/usr/lib"' -DATF_LIBEXECDIR='"/usr/libexec"' > -DATF_MACHINE='"armv6"' -DATF_M4='"/usr/bin/m4"' -DATF_PKGDATADI > R='"/usr/share/atf"' -DATF_SHELL='"/bin/sh"' -DATF_WORKDIR='"/tmp"' > -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../li > batf-c -I. -DHAVE_CONFIG_H > /usr/src/contrib/atf/atf-c++/detail/application.cpp > /usr/src/contrib/atf/atf-c++/build.cpp / > usr/src/contrib/atf/atf-c++/check.cpp > /usr/src/contrib/atf/atf-c++/config.cpp > /usr/src/contrib/atf/atf-c++/detail/env.cpp /usr > /src/contrib/atf/atf-c++/detail/exceptions.cpp > /usr/src/contrib/atf/atf-c++/detail/fs.cpp > /usr/src/contrib/atf/atf-c++/detail/ > process.cpp /usr/src/contrib/atf/atf-c++/tests.cpp > /usr/src/contrib/atf/atf-c++/detail/text.cpp /usr/src/contrib/atf/atf-c++/u > tils.cpp > /usr/src/contrib/atf/atf-c++/detail/application.cpp:38:19: error: > cstdarg: No such file or directory > /usr/src/contrib/atf/atf-c++/detail/application.cpp:39:18: error: > cstdio: No such file or directory > /usr/src/contrib/atf/atf-c++/detail/application.cpp:40:19: error: > cstdlib: No such file or directory > [...] > ----- > From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 18:51:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6BD93EC for ; Fri, 25 Jul 2014 18:51:53 +0000 (UTC) Received: from mail119c7.megamailservers.com (mail733.megamailservers.com [69.49.98.43]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88C27214F for ; Fri, 25 Jul 2014 18:51:52 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from [192.168.0.33] (ip72-194-65-37.oc.oc.cox.net [72.194.65.37]) (authenticated bits=0) by mail119c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id s6PIpf75014676; Fri, 25 Jul 2014 14:51:43 -0400 Message-ID: <53D2A73D.3010404@sasktel.net> Date: Fri, 25 Jul 2014 11:51:41 -0700 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Beeblebrox , freebsd-current@freebsd.org Subject: Re: Several minor annoyances on Current References: <1406282699515-5931653.post@n5.nabble.com> In-Reply-To: <1406282699515-5931653.post@n5.nabble.com> X-Enigmail-Version: 1.6.1_pre20140112 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A020202.53D2A73F.01C8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.1 cv=P/oD2Ewu c=1 sm=1 tr=0 a=Z5AWCFQ5VKA4phzWx86Kmg==:117 a=Z5AWCFQ5VKA4phzWx86Kmg==:17 a=kviXuzpPAAAA:8 a=BDKbP5mgAAAA:8 a=J0_EhWaTXrIA:10 a=a3Y91TBt1CEA:10 a=YxfxW3ofkq8A:10 a=8nJEP1OIZ-IA:10 a=uhPMnebkAAAA:8 a=GFFKh49_5I6V3xPwj4sA:9 a=wPNLvfGTeEIA:10 a=7jNfuqQ1KrQA:10 a=uOumoMf9eJMA:10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:51:53 -0000 Beeblebrox wrote: > Hello. Several questions for 11-Current: > > * I keep getting .core (gedit.core, midori.core, etc) files being > created either in /home/myuser or in the folder I run the command in on > terminal emulator (for example if I'm in ~/mydocs on terminal and run "$ > gedit filename", that folder gets a gedit.core file). Any way to stop this? I use this in /etc/sysctl.conf: kern.corefile=/tmp/cores/%N.core (You need to create the directory manually) From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 19:03:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B368C996 for ; Fri, 25 Jul 2014 19:03:17 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92797228A for ; Fri, 25 Jul 2014 19:03:16 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XAklv-0006Pg-HA for freebsd-current@freebsd.org; Fri, 25 Jul 2014 12:03:15 -0700 Date: Fri, 25 Jul 2014 12:03:15 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20140725220234.0e4eae5b@rsbsd.rsb> In-Reply-To: <53D2A73D.3010404@sasktel.net> References: <1406282699515-5931653.post@n5.nabble.com> <53D2A73D.3010404@sasktel.net> Subject: Re: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:03:17 -0000 Hi > I use this in /etc/sysctl.conf: > kern.corefile=/tmp/cores/%N.core In rc.conf I have clear_tmp_enable="YES" I would have used tmpfs for /tmp but my zpool/tmp is on an SSD which gives about the same result as f Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2B2BD3B; Fri, 25 Jul 2014 19:14:01 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 0BF212376; Fri, 25 Jul 2014 19:14:00 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id s7so3784642lbd.0 for ; Fri, 25 Jul 2014 12:13:58 -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=Op3BEIvZgmP+rAaNIHVNwxPEToy9fRiUKMNIk/l87as=; b=Bw/vpL35wFAEp333Y4fWH3yFHAWDUAciGZcyhn/i+lxiUz0OObPOrydXeL3mSajtLi usbEKvwndHJ19iT91CUm6t17iYjJW7McN4bT3BO+/E4g9DHfPKJsmJuh162OnQH4hSFR ydW/1oq3raC2MiZcMcMmr33b9NqUGygTKWkKN8KaKuc/mqC+I9MGpLn/CwKW/3tv+Lcs m6fuHdHI6Ju9XYopQbXkGy4Aww2DvRYgtc9Q9l4yMS1DX4Uh7wgeXXbTbSx4N/SlaOmI ODbIPTMVHvA9esifKARP4WoXQJD9RmDcu4/JHsSBgQTfc+cjyHqq91zp/LutyZOkjOKn n3ow== MIME-Version: 1.0 X-Received: by 10.112.16.199 with SMTP id i7mr17874599lbd.5.1406315638490; Fri, 25 Jul 2014 12:13:58 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.225.34 with HTTP; Fri, 25 Jul 2014 12:13:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Jul 2014 12:13:58 -0700 X-Google-Sender-Auth: q519awezHA1b9WBVwpJhrhpj8IU Message-ID: Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? From: Craig Rodrigues To: freebsd-current Current , ports , freebsd-doc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:14:02 -0000 On Thu, Jul 17, 2014 at 11:25 AM, Craig Rodrigues wrote: > > For (2), encouraging people to move away from Linux to FreeBSD > on the server, may be something where we can get more wins. > I think we can do this by having more HOWTO articles on > the FreeBSD web page that explain the following: > > > (1) We need a HOWTO article that explains for each command using apt > or yum for installing packages, > how can I do the same thing using "pkg". > Even if we have a web page with a table, contrasting the > apt/yum commands, and pkg commands, that would be super > useful. > > A lot of folks have moved away from FreeBSD, purely because > they are sick of pkg_add. We need to explain to folks that > we have something better, that is quite competitive to > apt/yum, and it is easy to use. > > (2) We need a HOWTO article that explains how to set up > a FreeBSD environment with some of the major cloud providers, > i.e. Amazon, Rackspace, Microsoft Azure, etc. > > > > Hi, While I appreciate the enthusiasm of the responses to this e-mail thread, especially the patches to service(8), I feel that my original e-mail was hijacked into the weeds, and none of the questions that I asked were answered. :) So, I am assuming that no one is working on the HOWTO's that I mentioned in my original e-mail. :) In the latest edition of BSDNow ( http://www.bsdnow.tv/episodes/2014_07_23-des_challenge_iv ), they refer to a blog article where someone who was used to Linux posted their experience setting up FreeBSD: http://thiagoperrotta.wordpress.com/2014/07/20/here-be-dragons-freebsd-overview-part-i/ http://thiagoperrotta.wordpress.com/2014/07/21/here-be-packages-freebsd-overview-part-ii/ The Part II article goes in-depth into installing packages, and the user had a positive experience with using pkg, which is great. What I'd like to see is an article on freebsd.org either on the wiki or in the handbook, which compares using apt, yum, rpm, whatever to pkg. Is anyone interested in working on an article like this? I don't have the bandwidth right now. -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 19:42:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 655D53C8; Fri, 25 Jul 2014 19:42:41 +0000 (UTC) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2054C262E; Fri, 25 Jul 2014 19:42:40 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=PyywdG1hhzAAEaY8aZXFLtMUnlqk6chnja1kir+Tqrg= c=1 sm=1 a=cQ5pcHtl6RgA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=TQf1RjA6AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=qUHAj0C30p8RyJ7GzysA:9 a=CjuIK1q_8ugA:10 a=XYlxyNO1GmcA:10 a=nLNdtIfjiDMA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=hkJOn7fyG5ZauHrd:21 a=q2OYaSsIqhtQz_Cg:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by idcmail-mo2no.shaw.ca with ESMTP; 25 Jul 2014 13:42:33 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id B6E28A4AF; Fri, 25 Jul 2014 12:42:32 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6PJCVZL003786; Fri, 25 Jul 2014 12:12:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6PHr1Pd099607; Fri, 25 Jul 2014 10:53:02 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407251753.s6PHr1Pd099607@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Fbsd8 Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message from Fbsd8 of "Wed, 23 Jul 2014 17:05:33 -0400." <53D0239D.1050906@a1poweruser.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 2014 10:52:48 -0700 Cc: Maxim Khitrov , "Andrey V. Elsukov" , FreeBSD Mailing List , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:42:41 -0000 Sorry for the late reply. It's a busy time right now. In message <53D0239D.1050906@a1poweruser.com>, Fbsd8 writes: > Cy Schubert wrote: > >> On 20.07.2014 18:15, Maxim Khitrov wrote: > >>> In my opinion, the way forward is to forget (at least temporarily) the > >>> SMP changes, bring pf in sync with OpenBSD, put a policy in place to > >>> follow their releases as closely as possible, and then try to > >>> reintroduce all the SMP work. I think the latter has to be done > >>> upstream, otherwise it'll always be a story of diverging codebases. > >>> Furthermore, if FreeBSD developers were willing to spend some time > >>> improving pf performance on OpenBSD, then Henning and other OpenBSD > >>> developers might be more receptive to changes that make the porting > >>> process easier. > >> Even if you just drop current PF from FreeBSD, there is nobody, who want > >> to port new PF from OpenBSD. And this is not easy task, as you may > >> think. Gleb has worked on rewriting PF more than half year. So, return > >> back all improvements after import will be hard enough and, again, > >> nobody want to do it. :) > > > > One way or another something needs to be done and agreed it would be a lot > > of work. Our options are, > > > > a) Import OpenBSD pf thereby throwing away our current investment in pf. > > All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would > > > be all for naught. We do get a new pf though. Won't be a quality port > > though. Personally, not my #1 option. > > > > b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we > > > do save the work we put into our pf. Once again a lot of work. We'd be > > introducing incompatibility. > > > > c) Do nothing. It goes without saying that pf would suffer rot and > > eventually we would need to do something. > > > > d) Yank pf from tree. An option but probably not a great one. We do have > > two other packet filters in the kernel (ipfw and ipfilter) however they are > > > different beasts with different capabilities. I think the reason we have > > the packet filters we do have is for the capabilities they bring to the > > table. I for one have run more than one in the same kernel because each has > > > different capabilities. > > > > e) We could add capability to pf on a piecemeal basis. Option (b) but as > > time permits. Remember, people have jobs and commitments. Funding would > > help address this. > > > > f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more > > compatible with our IP stack? Could this be an option? > > > > Anything we do should work with VIMAGE and be able to handle nat66 as well. > > > > > > Hello Cy; > Finally a voice I recognize. If I remember correctly you stepped up to > the plate earlier this year and did for ipfilter the same kind of things Last autumn. > this thread is talking about for pf. IE; apply upstream maintenance and > convert to FreeBSD standards. I think your work was a BSD fork of > Darrow's ipfilter which from this point on all upstream maintenance must > be hand merged into the BSD fork. I am a long time ipfilter user and Actually we did not fork ipfilter. It's simply included into our tree, with a few modifications. > thank you for your dedication and work ethics getting the updated > ipfilter into 10.0 and 9.3 so quickly. You're welcome. I too am a long time ipfilter user (Solaris and FreeBSD). > > So as someone who has been there and done that already you have unique > experience to really know the size of the task in hours to accomplish a > pf upgrade. Could you list the tasks and hours it took you to perform > the ipfilter upgrade so readers can have a real insight into what they > are asking for? The experience is not unique. Every developer pretty much follows the same process when importing code into the tree. As for tasks, the ipfilter import was relatively simple compared to some others. Remember, ipfilter was designed to be run on any of the BSDs, SunOS, Solaris, and HP/UX, IRIX, and Tru64 UNIX. That made upgrading from 4.1.28 to 5.1.2 simpler than pf which is written only for OpenBSD and its stack. > > I agree with your option "e" above, but I would re-word it this way. > Using the pf fork we already have in place, hand merge upstream > differences in piecemeal chunks as time permits. The openbsd new syntax > being the first chunk, closely followed by VIMAGE awareness. Personally I would choose option "e" because of $JOB and $FAMILY commitments. Adding the new OpenBSD syntax may be more difficult than we might think. The new syntax may be related to a new internal structure of pf. If the new pf is a rewrite (ipfilter 5.1.2 was a rewrite of large chunks of code), then you have no option but to do a wholesale import and retrofit our mods back into it, if they would even fit at all. I think the first task for anyone taking this on would be to familiarize oneself with the current pf code in FreeBSD and what was done to make it fit and to enhance it, then familiarize oneself with the new pf to get a feel for what work would be involved. > > When it comes to someone volunteering to do the work, many of us would > step up, but the fact is only a very very few people have the coding and > kernel knowledge to even consider doing this. Understanding the FreeBSD kernel helps but if a person doesn't have intimate knowledge of the FreeBSD kernel, you can always learn. There are some good books out there to help along the way. The Design and Implementation of the FreeBSD Kernel and Writing FreeBSD Device Drivers are two good examples. Of course having intimate knowledge is better but having worked on other kernels and understanding the nature of the beast goes a long way to working on any systems programming project, not just FreeBSD. If you understand how kernels generally operate you're more than half way there to volunteering and help out -- submit code and someone more senior on the project can take it from there and help out with the effort. (Once again, many hands make light work.) I don't think people should feel afraid of systems programming (kernel programming). The reason Linux gets so much more traction in any particular area of development is because they have many more people working on it. I would like to see more people pitch in and help out. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 19:43:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 569CD4EF; Fri, 25 Jul 2014 19:43:41 +0000 (UTC) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id ED8A2263E; Fri, 25 Jul 2014 19:43:40 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=BkBxTXsSVzyY7C2joSQK+JNK4mJr1It1Skr7Xe8+Jh8= c=1 sm=1 a=7V3fggXvsmQA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=8nJEP1OIZ-IA:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=1KmhjRZRDwvG-PhjtxoA:9 a=wPNLvfGTeEIA:10 a=RgXXd5XzHKoA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 25 Jul 2014 13:42:32 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 110F1A46C; Fri, 25 Jul 2014 12:42:32 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6PJCVZN003786; Fri, 25 Jul 2014 12:12:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6PHK8YX095747; Fri, 25 Jul 2014 10:20:08 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407251720.s6PHK8YX095747@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: trasz@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 In-Reply-To: Message from Glen Barber of "Thu, 24 Jul 2014 14:33:53 -0400." <20140724183353.GL1065@hub.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jul 2014 10:19:55 -0700 Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:43:41 -0000 In message <20140724183353.GL1065=40hub.FreeBSD.org>, Glen Barber writes:= > New Automounter >=20 > Contact: Edward Tomasz Napieral/a >=20 > Deficiencies in the current automounter, amd(8), are a recurring > problem reported by many FreeBSD users. A new automounter is being > developed to address these concerns. >=20 > The automounter is a cleanroom implementation of functionality > available in most other Unix systems, using proper kernel support > implemented via an autofs filesystem. The automounter supports a > standard map format, and will integrate with the Lightweight Directo= ry > Access Protocol (LDAP) service. Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd = currently integrates with NIS as well. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 21:05:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 904AB398; Fri, 25 Jul 2014 21:05:36 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 409D32D71; Fri, 25 Jul 2014 21:05:35 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6PL5WJx086772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jul 2014 15:05:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6PL5W5J086769; Fri, 25 Jul 2014 15:05:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 25 Jul 2014 15:05:32 -0600 (MDT) From: Warren Block To: Craig Rodrigues Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 25 Jul 2014 15:05:32 -0600 (MDT) Cc: freebsd-doc@freebsd.org, freebsd-current Current , ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:05:36 -0000 On Fri, 25 Jul 2014, Craig Rodrigues wrote: > What I'd like to see is an article on freebsd.org either on the wiki > or in the handbook, which compares using apt, yum, rpm, whatever > to pkg. Is anyone interested in working on an article like this? > I don't have the bandwidth right now. A person to write that article needs detailed knowledge of pkg and the Linux package systems. I don't have that, but would be willing to help you develop an outline for the article. Having a design like that makes it easier to write when time and resources are available. Writing "an article" is hard. Writing a small section on how deleting packages is different between pkg and, say, apt, is much easier. The scope is known. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 21:12:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 236DF7AF; Fri, 25 Jul 2014 21:12:58 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c: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 3D2432E4A; Fri, 25 Jul 2014 21:12:57 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q58so4743405wes.18 for ; Fri, 25 Jul 2014 14:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=5CixpQx38wT7/cblhEdhEC7smrirlwRu2Ll1zdl9o+w=; b=DV0Jki0iD3c0brggRxNDicviEHnc0t1iYZJ/SAyY1ocoJHWv/iFz2F8A9wWAmkVsUp j3LYaUtrLbgTHyyXKcib3PJUpQDG9+4lBJ6GqHNfEOJMnxqTIjHZyYr0SgeqUgyJXrw7 pQCNABtN5jvBAmSUR2mw7VGa1RvMYq6cWm33WtoU9iebJrKezgM82QEsJsk6CfpWX3wl iNOkJU2SLl9loTDTzGpgo4f+H7pZjdfTUk1x3kxGdkkZR+mez0uRRHZfby6+7PfGW8aC 59F4CbE6IQvRks6c/1KbTIetNwTi6ovUeoHhqJxsaa/7zRdd3DHiCPRHg2Qk9Ttxcnr9 6PLQ== X-Received: by 10.180.221.172 with SMTP id qf12mr8791812wic.54.1406322775536; Fri, 25 Jul 2014 14:12:55 -0700 (PDT) Received: from brick.home (cmu49.neoplus.adsl.tpnet.pl. [83.31.148.49]) by mx.google.com with ESMTPSA id u10sm10363103wix.14.2014.07.25.14.12.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 14:12:54 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 25 Jul 2014 23:12:49 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Cy Schubert Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140725211249.GA3933@brick.home> Mail-Followup-To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <20140724183353.GL1065@hub.FreeBSD.org> <201407251720.s6PHK8YX095747@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407251720.s6PHK8YX095747@slippy.cwsent.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:12:58 -0000 On 0725T1019, Cy Schubert wrote: > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > New Automounter > > > > Contact: Edward Tomasz Napieral/a > > > > Deficiencies in the current automounter, amd(8), are a recurring > > problem reported by many FreeBSD users. A new automounter is being > > developed to address these concerns. > > > > The automounter is a cleanroom implementation of functionality > > available in most other Unix systems, using proper kernel support > > implemented via an autofs filesystem. The automounter supports a > > standard map format, and will integrate with the Lightweight Directory > > Access Protocol (LDAP) service. > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > currently integrates with NIS as well. It's just a matter of testing, apart from a trivial shell script. Would you be able to help me with this? From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 21:26:11 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E79CC78 for ; Fri, 25 Jul 2014 21:26:11 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::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 4BF262F6A for ; Fri, 25 Jul 2014 21:26:11 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s6PLQ5hO086890; Fri, 25 Jul 2014 17:26:05 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s6PLQ5G2086889; Fri, 25 Jul 2014 17:26:05 -0400 (EDT) (envelope-from wollman) Date: Fri, 25 Jul 2014 17:26:05 -0400 (EDT) From: Garrett Wollman Message-Id: <201407252126.s6PLQ5G2086889@hergotha.csail.mit.edu> To: wblock@wonkity.com Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? References: Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 25 Jul 2014 17:26:05 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-Mailman-Approved-At: Fri, 25 Jul 2014 22:46:19 +0000 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:26:11 -0000 In article you write: >Writing "an article" is hard. Writing a small section on how deleting >packages is different between pkg and, say, apt, is much easier. The >scope is known. Indeed, it's pretty trivial. I think the sort of article Craig was looking for was more on the order of apt command pkg command apt-get update pkg update (*1) ... ... (*1) Explanation of differences between how apt behaves and how pkg behaves. The set of common apt operations is pretty well-known, and most of them have direct pkg(8) equivalents. -GAWollman From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 23:34:23 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E68B5E9 for ; Fri, 25 Jul 2014 23:34:23 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 246972B04 for ; Fri, 25 Jul 2014 23:34:22 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id c11so3869412lbj.37 for ; Fri, 25 Jul 2014 16:34:21 -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=jkBqIXkzk+ZEpV/STP187OipEsjD2sbvjCWKDf2LlyM=; b=mEU6r2gtRrkFHaBqMkKIFc8pDhJkYuK8dOPs3FLsc//MucBc7QF4GUofgjdrsnGolr P4LUauSWNQCOU9LTPvV7bG2jETF24rYlRJssA5NZ2R/GBH0cfKnJ/TSd+Sp7I34rBgH5 2LpFFKGJfTsAEVUptcE6L41ez53tl2WtL8/2SZeXTk+N9sIvF+yi2KGxa3S2zLVY6wAU P1gWoCfemsjunq2mvvUsmxnDk9AbD/wl27bXhsA6+Xj8D8tedb6K3k3U8blD34OMWnW/ reFshVyjV+hq5uEdtptYe2Der7nzSeJnTuAKU3p0qs3mtSuIFNE/pjwQVOY8671Wb3+x JH8g== MIME-Version: 1.0 X-Received: by 10.153.7.101 with SMTP id db5mr16442773lad.46.1406331260933; Fri, 25 Jul 2014 16:34:20 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.225.34 with HTTP; Fri, 25 Jul 2014 16:34:20 -0700 (PDT) In-Reply-To: <201407252126.s6PLQ5G2086889@hergotha.csail.mit.edu> References: <201407252126.s6PLQ5G2086889@hergotha.csail.mit.edu> Date: Fri, 25 Jul 2014 16:34:20 -0700 X-Google-Sender-Auth: SiZnutR6zpShzJYY54ecx2T0QF0 Message-ID: Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? From: Craig Rodrigues To: Garrett Wollman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Warren Block , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 23:34:23 -0000 On Fri, Jul 25, 2014 at 2:26 PM, Garrett Wollman < wollman@hergotha.csail.mit.edu> wrote: > In article you write: > > >Writing "an article" is hard. Writing a small section on how deleting > >packages is different between pkg and, say, apt, is much easier. The > >scope is known. > > Indeed, it's pretty trivial. > > I think the sort of article Craig was looking for was more on the > order of > > apt command pkg command > apt-get update pkg update (*1) > ... ... > > (*1) Explanation of differences between how apt behaves and how pkg > behaves. > > The set of common apt operations is pretty well-known, and most of > them have direct pkg(8) equivalents. > Hi, Garrett is describing exactly what I am looking for. I'm not looking for a complicated article explaining the internal differences between apt and pkg. Very few people have the interest or patience to read that. Providing a simple table contrasting the basic apt/yum/rpm/pkg commands for installing/upgrading/deleting packages is mostly what is needed. We need to show people that installing packages on FreeBSD is not like the "bad old pkg_add days" which people have bad memories of. We need to show that pkg is as good as what people are used to on modern Linux distributions. I have less experience with OS X, but if we can show people that pkg is as good as (or better than) MacPorts or Homebrew for installing third-party packages, that would be great as well, but focusing on Linux first would be good. -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 00:03:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A16CDD6; Sat, 26 Jul 2014 00:03:19 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ECD5B2D55; Sat, 26 Jul 2014 00:03:18 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6Q03H5K030342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jul 2014 18:03:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6Q03Gd1030339; Fri, 25 Jul 2014 18:03:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 25 Jul 2014 18:03:16 -0600 (MDT) From: Warren Block To: Craig Rodrigues Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? In-Reply-To: Message-ID: References: <201407252126.s6PLQ5G2086889@hergotha.csail.mit.edu> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 25 Jul 2014 18:03:17 -0600 (MDT) Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Garrett Wollman , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 00:03:19 -0000 On Fri, 25 Jul 2014, Craig Rodrigues wrote: > > > > On Fri, Jul 25, 2014 at 2:26 PM, Garrett Wollman wrote: > In article you write: > > >Writing "an article" is hard.  Writing a small section on how deleting > >packages is different between pkg and, say, apt, is much easier.  The > >scope is known. > > Indeed, it's pretty trivial. > > I think the sort of article Craig was looking for was more on the > order of > >         apt command             pkg command >         apt-get update          pkg update (*1) >         ...                     ... > > (*1) Explanation of differences between how apt behaves and how pkg > behaves. > > The set of common apt operations is pretty well-known, and most of > them have direct pkg(8) equivalents. > > > > Garrett is describing exactly what I am looking for. > > I'm not looking for a complicated article explaining the internal > differences between apt and pkg.  Very few people have the > interest or patience to read that. > > Providing a simple table contrasting the basic apt/yum/rpm/pkg commands > for installing/upgrading/deleting packages is mostly what is needed. This gave me a flashback to the last time somebody said "Oh, I just want a simple little program." :) > We need to show people that installing packages on FreeBSD is > not like the "bad old pkg_add days" which people have bad memories of.  We need to show that pkg is as good as what people are used to on modern Linux > distributions. The wiki should be ideal for this. Start a table, fill in what you can, and others can fill in the other parts. From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 02:46:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14CE5616; Sat, 26 Jul 2014 02:46:43 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id BA50328C9; Sat, 26 Jul 2014 02:46:41 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=UbGOdjJMTOnDdlSKs4VLEv47Nwxh2hlhayjdFxkzNJk= c=1 sm=1 a=7V3fggXvsmQA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=jn4Z1P99xdyqle8XhOAA:9 a=CjuIK1q_8ugA:10 a=RgXXd5XzHKoA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 25 Jul 2014 20:46:34 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id A52EBA56F; Fri, 25 Jul 2014 19:46:34 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6Q2kXdV013283; Fri, 25 Jul 2014 19:46:33 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6Q2kX7n013280; Fri, 25 Jul 2014 19:46:33 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 In-Reply-To: Message from Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= of "Fri, 25 Jul 2014 23:12:49 +0200." <20140725211249.GA3933@brick.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 2014 19:46:33 -0700 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 02:46:43 -0000 In message <20140725211249.GA3933@brick.home>, Edward Tomasz =?utf-8?Q?Napiera= C5=82a?= writes: > On 0725T1019, Cy Schubert wrote: > > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > > New Automounter > > > > > > Contact: Edward Tomasz Napieral/a > > > > > > Deficiencies in the current automounter, amd(8), are a recurring > > > problem reported by many FreeBSD users. A new automounter is being > > > developed to address these concerns. > > > > > > The automounter is a cleanroom implementation of functionality > > > available in most other Unix systems, using proper kernel support > > > implemented via an autofs filesystem. The automounter supports a > > > standard map format, and will integrate with the Lightweight Directory > > > Access Protocol (LDAP) service. > > > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > > currently integrates with NIS as well. > > It's just a matter of testing, apart from a trivial shell script. > Would you be able to help me with this? > Sure! Just point me in the direction of the patches. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 06:02:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7443CF9A for ; Sat, 26 Jul 2014 06:02:19 +0000 (UTC) Received: from nm7-vm10.access.bullet.mail.bf1.yahoo.com (nm7-vm10.access.bullet.mail.bf1.yahoo.com [216.109.114.169]) (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 E0184295D for ; Sat, 26 Jul 2014 06:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1406354407; bh=p5Dd/IgZineo61xS8gSKw2zaxlIg0O/HEMotlz4JTCI=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject; b=VifLdwobv6DpTAgR1qWGqP2t4rHLgt2FjlaPMOqMo51iMWW7ZuBFLv6tghqQRflU6RYOw7XJJBlIwC+FUtO5oBTl9xUZMUz+jLdV+SaW8nwlFFx/bnC+IUKZ4moU5VpU1rrAB/Lt6IvGYTxrUfH5L+rqW8ytjoxgpSBUiKRVbc5K1lG/FxOVKrhFFWnGZwMglCQ15iIBGi0QRsSz5uBtbnRQAkIkl1uWpSfVkunMuqEjkB+InhCtRCnEx+EmuNAV6dV3AZJ/16KP+eh2Ny895Fs5cyJCJZ+0C/bIFanBkUpJxROFH2dXA1OLsFgFywdsE9BWS1jKfqJTBLf6iocHMQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=bellsouth.net; b=iMdngjROdVmU+W38A8YSWN3+NrQz02X89Z3BrhXyBYcmH2kNWAoLwAAYbZCGV7xtayXf0kpy4+dTTseb/HsqENUCx98sqpJFFQBjIq955ZwGmvQy9xKoRx25EDQEyr9a4uJSUc6XFH/9D3zsfJyx2h5yOI/005idf99yPyr9nbDDZm/QK67p9zrBj3jfizpuLZ5pKZWmifxjLkj7HfU6LL5WIPRB//AuhiLfOAYhbYQKY1laqRsBLKAsUP2JvVBmosLPOXpOWWAuzSOsN2FJeQGaLYhASwr1dsbQXCb3iLPxKOCmEBTN5nMDui0kiRRpt/SQCOakKqCsCtj4X1ukaw==; Received: from [66.196.81.164] by nm7.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2014 06:00:07 -0000 Received: from [98.139.221.156] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2014 06:00:07 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.bf1.yahoo.com with NNFMP; 26 Jul 2014 06:00:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1406354407; bh=p5Dd/IgZineo61xS8gSKw2zaxlIg0O/HEMotlz4JTCI=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject; b=SMLkYzkDkTzLoCHf9++1C6c7Z9/7OAZ7iGEFAg6PUov8+JIJDdhSf7UgB+DlUpYAL6fSbxiyI5Qe5kab3xj7QsI88YqTRtdaoHNMVN+7UNmGH2x2Tet6lV8ikSCY8lXPecf4U17wyJiHSBJo9VvesIPzSaYnjYKxfVuAx761Waw= X-Yahoo-Newman-Id: 750149.45684.bm@smtp116.sbc.mail.bf1.yahoo.com Message-ID: <750149.45684.bm@smtp116.sbc.mail.bf1.yahoo.com> Date: Sat, 26 Jul 2014 06:00:07 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nuE2iYAVM1lQLEFq2ZISu3D4u3gcW.mc1G3WV.XhYLE6Ecj KVAb9X7JkDdW.62lkshlJDhZlPGdSvg958CGLZpbSUelMrMNVEZMijvHnVVi je20qfyXqyWcPQ12g0rpLz9pxdjqugdkHc78SCEGxT1iW3aPsGDgkKsdpDJX epjMd9wseX2JQPV6FtOwni_N2YsxvnHZVuclVdIonIqHcjSlI8Wf0g0LZkSw WvJoR4vzf_PyzG4apKj.EmwHEa409zdfIG19R0mdyybpovB43wI0LqManZbo 0sm79C0KnuIhAyE9pHCObjfZpQ3Hqzzd2ZGanejMS9u.rUtoTQNBH8NMxN4e cq0z9XCvACIx6YlzvdFILgOjMW6jE8HkbXuFZuDorf5dqPwchjJA9l_apL1U UpphRVQq3L7caJ.Byfx5W0lU8JIlfqLf56FaZSqwzrlJq0e_0YCajH97cknj e1rMAB0JF6VQwXp1bXq6TJ05vcncIfMXFJd2zt6sU_SPJVfpXvgE5WvU1ECA Uzg4WvpsHV7dRVxmRh.VZ4SAGps3YttrUHtQsylYpwaAh7KjqtvTaOnzF3dn cXqenfX1i6O4fQ6TPjiB3cMH3ixAYJGMxq9v0GrrrGzyKBNxDmBMpTEw- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Unreadable DVD in FreeBSD and NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:02:19 -0000 I have a DVD, a data DVD rather than movie or music, from Seagate Business Storage 2-bay NAS, that is mountable with mount_cd9660 but not readable in FreeBSD and NetBSD, using current amd64 versions of FreeBSD and NetBSD. ls /cdrom showed nothing; ls -al /cdrom showed total 6 dr-xr-xr-x 2 root wheel 2048 Nov 1 2012 . drwxr-xr-x 26 root wheel 1024 Jul 25 03:31 .. df showed Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/gpt/WD2G04 121863804 52278052 59836648 47% / devfs 1 1 0 100% /dev /dev/gpt/WD2G05 142191228 8022016 122793916 6% /home /dev/cd0 1832610 1832610 0 100% /cdrom so it looked like something was there. Mounted under Linux (System Rescue CD 4.3.0), main directory showed autorun.inf Rally Driver Installation Instructions Resources Seagate EULA Seagate NAS Backup Seagate NAS Discovery Seagate NAS Discovery Install Package Seagate Privacy Policy Setup.exe Windows Driver Haiku R1Alpha4 (haiku-os.org) was also able to show these directories and read the DVD. Is there any way I can read this DVD in FreeBSD or NetBSD, or is this a deficiency or bug in FreeBSD and NetBSD? I tried mount -t udf (no good) and "mount_cd9660 -be /dev/cd0 /cdrom" (same result as without -be). What more details could I give? Tom From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 06:04:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3D7119D for ; Sat, 26 Jul 2014 06:04:51 +0000 (UTC) Received: from forward1l.mail.yandex.net (forward1l.mail.yandex.net [84.201.143.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B5C12996 for ; Sat, 26 Jul 2014 06:04:51 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 872221520F97; Sat, 26 Jul 2014 10:04:47 +0400 (MSK) Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id 2E7C81B60059; Sat, 26 Jul 2014 10:04:47 +0400 (MSK) Received: from unknown (unknown [178.76.214.146]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id OWJdZKHS88-4koS3vJe; Sat, 26 Jul 2014 10:04:46 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 6de8aeba-3647-4cfe-88c8-09a394a0ad56 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1406354686; bh=2mJFAG5CwagP/TLYRTlYZeESz4Bl4UWm/Of3NEbNvdw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sHbh9AE0AMjnWPmdUKRsk8Xhw5TpUwHiZGi4vIfI5W1Yrc1pvM9juBtE/dIUQac9i WUKTh32KGGd3ihb5zLLk9coIFiap9ETrXH92DPMndaILC8RAlqqY8RMvRZSWUn6xul TmrkWDR5QjPS4j6LTzcG+IEcOCD7OX2+FuHmEgbk= Authentication-Results: smtp8.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53D344F2.9010501@yandex.ru> Date: Sat, 26 Jul 2014 10:04:34 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Thomas Mueller , freebsd-current@freebsd.org Subject: Re: Unreadable DVD in FreeBSD and NetBSD References: <750149.45684.bm@smtp116.sbc.mail.bf1.yahoo.com> In-Reply-To: <750149.45684.bm@smtp116.sbc.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:04:51 -0000 Thomas Mueller wrote on 26.07.2014 10:00: > I have a DVD, a data DVD rather than movie or music, from Seagate Business Storage 2-bay NAS, that is mountable with mount_cd9660 but not readable in FreeBSD and NetBSD, using current amd64 versions of FreeBSD and NetBSD. > > ls /cdrom showed nothing; ls -al /cdrom showed > > total 6 > dr-xr-xr-x 2 root wheel 2048 Nov 1 2012 . > drwxr-xr-x 26 root wheel 1024 Jul 25 03:31 .. > > df showed > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/gpt/WD2G04 121863804 52278052 59836648 47% / > devfs 1 1 0 100% /dev > /dev/gpt/WD2G05 142191228 8022016 122793916 6% /home > /dev/cd0 1832610 1832610 0 100% /cdrom > > so it looked like something was there. > > Mounted under Linux (System Rescue CD 4.3.0), main directory showed > > autorun.inf > Rally Driver Installation Instructions > Resources > Seagate EULA > Seagate NAS Backup > Seagate NAS Discovery > Seagate NAS Discovery Install Package > Seagate Privacy Policy > Setup.exe > Windows Driver > > Haiku R1Alpha4 (haiku-os.org) was also able to show these directories and read the DVD. > > Is there any way I can read this DVD in FreeBSD or NetBSD, or is this a deficiency or bug in FreeBSD and NetBSD? > > I tried mount -t udf (no good) and "mount_cd9660 -be /dev/cd0 /cdrom" (same result as without -be). > > What more details could I give? > > Tom You need to install sysutils/udfclient. Your cd is in UDF format, that isn't covered by standard mount_udf. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 06:35:12 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D86455A1; Sat, 26 Jul 2014 06:35:12 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (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 8B5902B8F; Sat, 26 Jul 2014 06:35:12 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XAvZO-000GTG-Oc; Sat, 26 Jul 2014 09:35:02 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 From: Daniel Braniss In-Reply-To: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> Date: Sat, 26 Jul 2014 09:40:04 +0300 Content-Transfer-Encoding: 7bit Message-Id: <53C46240-10B2-453C-A077-8C151A4B391C@cs.huji.ac.il> References: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1878.6) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:35:12 -0000 On Jul 26, 2014, at 5:46 AM, Cy Schubert wrote: > In message <20140725211249.GA3933@brick.home>, Edward Tomasz > =?utf-8?Q?Napiera= > C5=82a?= writes: >> On 0725T1019, Cy Schubert wrote: >>> In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: >>>> New Automounter >>>> >>>> Contact: Edward Tomasz Napieral/a >>>> >>>> Deficiencies in the current automounter, amd(8), are a recurring >>>> problem reported by many FreeBSD users. A new automounter is being >>>> developed to address these concerns. >>>> >>>> The automounter is a cleanroom implementation of functionality >>>> available in most other Unix systems, using proper kernel support >>>> implemented via an autofs filesystem. The automounter supports a >>>> standard map format, and will integrate with the Lightweight Directory >>>> Access Protocol (LDAP) service. >>> >>> Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd >>> currently integrates with NIS as well. >> and hesiod? i can help with the testing danny >> It's just a matter of testing, apart from a trivial shell script. >> Would you be able to help me with this? >> > > > Sure! Just point me in the direction of the patches. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 07:27:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A8B5499 for ; Sat, 26 Jul 2014 07:27:34 +0000 (UTC) Received: from nm13-vm4.access.bullet.mail.bf1.yahoo.com (nm13-vm4.access.bullet.mail.bf1.yahoo.com [216.109.115.4]) (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 DCE712F74 for ; Sat, 26 Jul 2014 07:27:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1406359517; bh=LsCWsUp8w0PUh7QZVoxECoEQjSISiYUTUCX/g6A9hgQ=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:CC:Subject; b=qFesVsnK8c/FdaqP0QZ160j17Af1+uRLmy4xbLMLPQu1EGr+aEdqKr8Om4MCXl8E2xXgLQvXGKjE+64saxlksAtjX7xckaq0h7FHw61hRsQE39mli1ucbrfnCG6ygqYJlwawNUCowS5Ckrdjvx8lyXSANQ5H3QzqXmn3rAdeQ+0D3epJc3OW47zbDY8oNjvPFUQP1xhcTxIcTGgNGXFaJxnP1scBj6kjYjtdwohNbdHMKQLiAgILDnYhDXV5OlmIf3ufVYVtyJEw8oGOkUpwoLhshwXKVYIP1RS7TWZz8qe15i4eI+g0lTOeOCFHeja6OhLG5I3C1okQ5qW8hA0mhw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=bellsouth.net; b=LAugVkxFXVd5MOtqUlpF9uVqMow4eSkiMg+UShLUsi14kaCcfGPQ9XPyuVX4DbP5JyMis1Rzt5Wf2lU/fmCupJIdCYPj4F6fGpRo/1Jh1/k8+emiyL9j0B63+RrkCPcaMYYXHFATUkRpoe3MlM1gWM/hy/Qdwf5EhObddVETdOrRecV2BuUmo9valdKQHIBChnARQu+Sp32cMDIEblI+xhf2UpCl9MTwv80ixMGKsaO/A9Yor5n/lD0pQuJam8Hb/lIZ0cZd9nLae7nxJDazVLijm9bqidPK6N1t6BFJAc5tLpMWnkYl4mwP2bcCxl7ZSFBHxtZg88ifIwX3IVEQAg==; Received: from [66.196.81.159] by nm13.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2014 07:25:17 -0000 Received: from [98.139.221.158] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2014 07:25:17 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.bf1.yahoo.com with NNFMP; 26 Jul 2014 07:25:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1406359517; bh=LsCWsUp8w0PUh7QZVoxECoEQjSISiYUTUCX/g6A9hgQ=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:CC:Subject; b=IC6ObkzBkaxfw6juYnDv2xpw5dW8ZaWZg5kBQAx2Vfi8gkWMN0o9hRaArp5U3HX7vJzGguicFp+l0ubn2/9yXSuRVx3z2xn1ijYRBd1LWUFkTYWXSgUnp/IgSp3rxjXwEJNd4U494KKiqKc+WJX9YVhChKTCLYh5rLXyCYSHhgI= X-Yahoo-Newman-Id: 727229.38964.bm@smtp118.sbc.mail.bf1.yahoo.com Message-ID: <727229.38964.bm@smtp118.sbc.mail.bf1.yahoo.com> Date: Sat, 26 Jul 2014 07:25:17 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 89Se9RgVM1mWZyC5K4hVgChZiPLKbxTqFBmDXX5CTp8FzWs 6p2.ABHG961hUTXkvW7EhUKqiDskh1mzkgvZmaoF11Zn7vi_FUM.Kj5GmON2 f.7Ctz2g7C3rZi5b8j8keGsxSbB0XYrO13aTW1bEuYNFqYhJotmv1fy4wr.. ZQwWhJWzRjpESHRPw4bAr.CjhsVneZeJdfiTqwYekDy50zdLlkUjelZYj7Ry iUssH0YJ6KZgd494QYu_VHHWudSkhpIY2wRxdiquD5hjsgnSWWru1.Sq7Y3x xg74M.vAK1t2_mrQkmvlwnjleSaD.W0DBFJs40lS4cRRNXWRJ1WQPp.hIm2h VMkjQ4lBmPM4BPUggJfInjncxrNm.8u5700TwfFgg7M53vhA.rc1Ofs4y.oz f0BDLjtdi92oAM1W.rhnUIFhRmtFTjgZTCDXFN20NGqXyRRDyaB.BWsW39XZ 7IJM8Uk42tHw6QhFjwXWIns2fP94JfM5961AHRRMtQGmCUu.2FdFzxcgjdCF 0msh0ZoiRSmpXkPFncmpLnYbhp8pljYRG6T7NSK21p1B8g553rET3aw-- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: Unreadable DVD in FreeBSD and NetBSD Cc: freebsd-ports@Wfreebsd.org, avg@icyb.net.ua X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 07:27:34 -0000 > You need to install sysutils/udfclient. Your cd is in UDF format, that isn't > covered by standard mount_udf. -- > Regards, > Ruslan I just tried and failed, got error messages but still got fusefs-libs which could prove useful: cc -O2 -pipe -fno-strict-aliasing -I/usr/local/include -D_FILE_OFFSET_BITS=64 -DNEEDS_ISPRINT -DNO_INT_FMTIO -DNO_DIRENT_NAMLEN -DSCSI -DUSCSI_FREEBSD_CAM -DPACKAGE_NAME=\"udfclient\" -DPACKAGE_TARNAME=\"udfclient\" -DPACKAGE_VERSION=\"0.7.5\" -DPACKAGE_STRING=\"udfclient\ 0.7.5\" -DPACKAGE_BUGREPORT=\"reinoud@NetBSD.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_ENDIAN_H=1 -DHAVE_MACHINE_ENDIAN_H=1 -DHAVE_STRUCT_STAT_ST_ATIMESPEC=1 -DHAVE_STRUCT_STAT_ST_BIRTHTIMESPEC=1 -DHAVE_CAMLIB_H=1 -I. -c udfclientfs.c In file included from udfclientfs.c:58: In file included from ./udf.h:175: ./uio.h:69:53: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int uiomove(void *buf, size_t amount, struct uio *uio); ^ In file included from udfclientfs.c:58: ./udf.h:499:98: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int udf_read_file_part_uio(struct udf_node *udf_node, char *what, int cachehints, struct uio *data_uio); ^ ./udf.h:500:99: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int udf_write_file_part_uio(struct udf_node *udf_node, char *what, int cachehints, struct uio *data_uio); ^ ./udf.h:503:59: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int udf_readdir(struct udf_node *udf_node, struct uio *result_uio, int *eof_res /* int *cookies, int ncookies */); ^ udfclientfs.c:147:43: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] error = udf_lookup_name_in_dir(dir_node, name, strlen(name), &udf_icbptr, fid, &found); ^~~~ ./udf.h:505:69: note: passing argument to parameter 'name' here extern int udf_lookup_name_in_dir(struct udf_node *dir_node, char *name, int namelen, struct long_ad *icb_loc, struct fileid_desc *fid, int *found); ^ udfclientfs.c:520:13: error: variable has incomplete type 'struct uio' struct uio file_uio; ^ udfclientfs.c:520:9: note: forward declaration of 'struct uio' struct uio file_uio; ^ udfclientfs.c:560:13: error: variable has incomplete type 'struct uio' struct uio file_uio; ^ udfclientfs.c:560:9: note: forward declaration of 'struct uio' struct uio file_uio; ^ udfclientfs.c:621:13: error: variable has incomplete type 'struct uio' struct uio dir_uio; ^ udfclientfs.c:621:9: note: forward declaration of 'struct uio' struct uio dir_uio; ^ 5 warnings and 3 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/ports/sysutils/udfclient/work11/UDFclient.0.7.5 *** Error code 1 Stop. make[1]: stopped in /usr/ports/sysutils/udfclient *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/udfclient ===>>> make failed for sysutils/udfclient ===>>> Aborting update ===>>> Killing background jobs Terminated ===>>> There are messages from installed ports to display, but first take a moment to review the error messages above. Then press Enter when ready to proceed. ===>>> pkg-message for pkg-1.3.0 If you are upgrading from the old package format, first run: # pkg2ng ===>>> pkg-message for fusefs-libs-2.9.3_2 Install the fuse kernel module to use this port. ===>>> Done displaying pkg-message files ===>>> The following actions were performed: Upgrade of pkg-1.2.7_3 to pkg-1.3.0 Installation of sysutils/fusefs-libs (fusefs-libs-2.9.3_2) ===>>> You can restart from the point of failure with this command line: portmaster sysutils/udfclient ===>>> Exiting Tom From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 09:03:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AC995BB for ; Sat, 26 Jul 2014 09:03:11 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B0BA26DB for ; Sat, 26 Jul 2014 09:03:10 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XAxsj-0007dU-CD for freebsd-current@freebsd.org; Sat, 26 Jul 2014 02:03:09 -0700 Date: Sat, 26 Jul 2014 02:03:09 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20140726120247.3b763085@rsbsd.rsb> In-Reply-To: <53D2A73D.3010404@sasktel.net> References: <1406282699515-5931653.post@n5.nabble.com> <53D2A73D.3010404@sasktel.net> Subject: Re: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 09:03:11 -0000 @ Ian: I added your code and rebuilt the kernel. /boot/loader.conf also has vfs.nfs.bootp_disable="YES" Previously described problem persists. SEPARATE KBD_KEYMAP ISSUE: The keymap for keyboard fails to be set from rc.conf with keymap="fr.iso.kbd" Boot message shows this but there is no record of the message in log files/dmesg: "Configuring syscons: keymapkbdcontrol: keymap file "fr.iso.kbd" not found: No such file or directory" Keymap gets set when I change rc.conf entry to: keymap="/usr/share/syscons/keymaps/fr.iso.kbd" ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931938.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 10:48:11 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8034BB57; Sat, 26 Jul 2014 10:48:11 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12D6F2F0D; Sat, 26 Jul 2014 10:48:10 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 5C8381A40F9B; Sat, 26 Jul 2014 14:48:07 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id E0049134013C; Sat, 26 Jul 2014 14:48:06 +0400 (MSK) Received: from 93.91.10.59.tel.ru (93.91.10.59.tel.ru [93.91.10.59]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ISDRm7kPaQ-m6WaBjmS; Sat, 26 Jul 2014 14:48:06 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 7710cf11-035f-4c95-9c2b-f4e4b9bf1d4f Message-ID: <53D38766.9090407@passap.ru> Date: Sat, 26 Jul 2014 14:48:06 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sbruno@freebsd.org Subject: Re: [make xdev, libatf]: error: cstdarg: No such file or directory References: <53D28899.3080704@passap.ru> <1406311201.1080.7.camel@bruno> In-Reply-To: <1406311201.1080.7.camel@bruno> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 10:48:11 -0000 Hi Sean, All, Sean, thanks for your help. 25.07.2014 22:00, Sean Bruno пишет: > On Fri, 2014-07-25 at 20:40 +0400, Boris Samorodov wrote: >> >> Here are errors I get with sources at r269089. >> > I am at 269090. make xdev TARGET=mips TARGET_ARCH=mips64 just finished > for me. At this point, drop the rest of the options from the build as > dim, bsdimp and sjg have fixed most of the issues requiring that. Uboot (at least the version supported by crochet) needs gcc to build. > There is a fatal depend bug of some kind occuring if /usr/obj/ has > builds in it. Try removing /usr/obj/* and then build again. That didn't help, the same error. And a discussion at arm@ ML shows that there are problems with xdev gcc build at recent HEAD. >> ----- >> % uname -a >> FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r269019: Wed >> Jul 23 23:24:47 SAMT 2014 >> bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 >> >> % sudo make -C /usr/src TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 >> WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 >> WITHOUT_CLANG_IS_CC=1 xdev >> [...] >> ===> lib/atf (obj,depend,all,install) >> ===> lib/atf/libatf-c (obj) >> ===> lib/atf/libatf-c++ (obj) >> ===> lib/atf/libatf-c (depend) >> ===> lib/atf/libatf-c++ (depend) >> rm -f .depend >> CC='cc -isystem //usr/armv6-freebsd/usr/include >> -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ >> -B//usr/armv6-fr >> eebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin >> -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a -DHAVE_CONFIG_H >> -DATF_A >> RCH='"arm"' -DATF_BUILD_CC='"cc -isystem //usr/armv6-freebsd/usr/include >> -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- >> freebsd/ -B//usr/armv6-freebsd/usr/libexec >> -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' >> -DATF_BUILD_CFLAGS=' >> "-O -pipe "' -DATF_BUILD_CPP='"cpp -isystem >> //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib >> --sysroot=//usr/ar >> mv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec >> -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' >> -DATF_BUILD_CPPF >> LAGS='""' -DATF_BUILD_CXX='"c++ -isystem //usr/armv6-freebsd/usr/include >> -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- >> freebsd/ -B//usr/armv6-freebsd/usr/libexec >> -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' >> -DATF_BUILD_CXXFLAGS >> ='"-O -pipe "' -DATF_CONFDIR='"/etc/atf"' >> -DATF_C_TESTS_BASE='"/usr/tests/lib/atf/libatf-c"' >> -DATF_INCLUDEDIR='"/usr/include" >> ' -DATF_LIBDIR='"/usr/lib"' -DATF_LIBEXECDIR='"/usr/libexec"' >> -DATF_MACHINE='"armv6"' -DATF_M4='"/usr/bin/m4"' -DATF_PKGDATADI >> R='"/usr/share/atf"' -DATF_SHELL='"/bin/sh"' -DATF_WORKDIR='"/tmp"' >> -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../li >> batf-c -I. -DHAVE_CONFIG_H >> /usr/src/contrib/atf/atf-c++/detail/application.cpp >> /usr/src/contrib/atf/atf-c++/build.cpp / >> usr/src/contrib/atf/atf-c++/check.cpp >> /usr/src/contrib/atf/atf-c++/config.cpp >> /usr/src/contrib/atf/atf-c++/detail/env.cpp /usr >> /src/contrib/atf/atf-c++/detail/exceptions.cpp >> /usr/src/contrib/atf/atf-c++/detail/fs.cpp >> /usr/src/contrib/atf/atf-c++/detail/ >> process.cpp /usr/src/contrib/atf/atf-c++/tests.cpp >> /usr/src/contrib/atf/atf-c++/detail/text.cpp /usr/src/contrib/atf/atf-c++/u >> tils.cpp >> /usr/src/contrib/atf/atf-c++/detail/application.cpp:38:19: error: >> cstdarg: No such file or directory >> /usr/src/contrib/atf/atf-c++/detail/application.cpp:39:18: error: >> cstdio: No such file or directory >> /usr/src/contrib/atf/atf-c++/detail/application.cpp:40:19: error: >> cstdlib: No such file or directory >> [...] >> ----- >> > > -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 11:24:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 897A514F for ; Sat, 26 Jul 2014 11:24:18 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (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 431482220 for ; Sat, 26 Jul 2014 11:24:17 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id E105A6A6004; Sat, 26 Jul 2014 13:24:14 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s6QBOElO040517; Sat, 26 Jul 2014 13:24:14 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s6QBOEgr039638; Sat, 26 Jul 2014 13:24:14 +0200 (CEST) (envelope-from lars) Date: Sat, 26 Jul 2014 13:24:14 +0200 From: Lars Engels To: Beeblebrox Subject: Re: Several minor annoyances on Current Message-ID: <20140726112414.GG10844@e-new.0x20.net> Mail-Followup-To: Lars Engels , Beeblebrox , freebsd-current@freebsd.org References: <1406282699515-5931653.post@n5.nabble.com> <53D2A73D.3010404@sasktel.net> <20140726120247.3b763085@rsbsd.rsb> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tvOENZuN7d6HfOWU" Content-Disposition: inline In-Reply-To: <20140726120247.3b763085@rsbsd.rsb> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 11:24:18 -0000 --tvOENZuN7d6HfOWU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 26, 2014 at 02:03:09AM -0700, Beeblebrox wrote: > @ Ian: > I added your code and rebuilt the kernel. > /boot/loader.conf also has vfs.nfs.bootp_disable=3D"YES" > Previously described problem persists. >=20 > SEPARATE KBD_KEYMAP ISSUE: > The keymap for keyboard fails to be set from rc.conf with > keymap=3D"fr.iso.kbd" > Boot message shows this but there is no record of the message in log > files/dmesg: "Configuring syscons: keymapkbdcontrol: keymap file > "fr.iso.kbd" not found: No such file or directory" > Keymap gets set when I change rc.conf entry to: keymap=3D"/usr/share/sysc= ons/keymaps/fr.iso.kbd" Yes, I also stumbled upon this. Usually the following worked: # kbdcontrol -l german.iso # kbdcontrol -l german.iso.kbd # kbdcontrol -l /usr/share/syscons/keymaps/german.iso.kbd In the last few months on HEAD only the latest invocation works. --tvOENZuN7d6HfOWU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJT04/dXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tg/0H/A4L6GOdYkykAQt0KUUkwsD3 7MVccVsKqoSYqQaYMliiphYHGZGRiTrmnfLQg9i98b557Bz870SZzazo/VltvbV1 ZPsvBgkFUzbfWeNr4rdMo0RhFMkuLbOz2M7SzukVrFkvO7fkAf5fKThtAXaWtAc7 H7WHJaAJKThbM30OUauFdpPtiVql3cnJSQq6oSR/WoHR16iiYr/kWLddbFuOBj90 89EYo4FnRgdQPapATJRBcOHop3/WB6uF3SkClpS8RP0gntc9svBYNq3FGVZw9Cdt J5J0P/A3I7wANDBEpR4lNbSelHit4KhJTlRrY1yxZew8gjYiznGQXCIqglv0tXw= =2PA6 -----END PGP SIGNATURE----- --tvOENZuN7d6HfOWU-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 11:49:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F9E07BF for ; Sat, 26 Jul 2014 11:49:57 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 0BEF323F4 for ; Sat, 26 Jul 2014 11:49:56 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway1.nyi.internal (Postfix) with ESMTP id 4AFBC21BB6 for ; Sat, 26 Jul 2014 07:49:54 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 26 Jul 2014 07:49:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=RJLKNiNwSxnEDe/ACcP00Qk5BS0=; b=K3kWnuWC8cIZt7OTlWlPPJS8q0Rd mD/opAAm3YI3D6vzufTl4rtop/bJmK072yX4F0lVR4xcbFokJ+to/8Ptf8moF9NH Ps9c7UjkS4gtdE+1fK+HX5zKqeG5wcFp7WsmLdylMySFo/dJdrB67WMmkEd2ummS JqH2sdEKfCi0fwM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=RJLKNiNwSxnEDe/ACcP00Q k5BS0=; b=T2YiD5fKR8dGb3b9w2my6dPE7wF1T6+nOv/F7iBThc1/O/gjEKtwus 07XR1UiC1F3PHqQ0Ze0NDF/aAz6lIo/Bg6nwP5gvsJfcOKU0zRmW5YHZ2QUYTTM0 pTCcgtVYAXsI80H7fpD6XGKpGeYkx+K4zZCR34hHb0H7GUvkE8Q2E= X-Sasl-enc: cLlg/mJQXz3MYIj8JRZkB7bRZkSzReDNeBrkCZ9pTbwi 1406375393 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id A0AD7C00003 for ; Sat, 26 Jul 2014 07:49:53 -0400 (EDT) Message-ID: <53D395E4.1070006@fastmail.net> Date: Sat, 26 Jul 2014 21:49:56 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> In-Reply-To: <201407231542.s6NFgX4M025370@slippy.cwsent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 26 Jul 2014 12:22:27 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 11:49:57 -0000 On 24/07/2014 1:42 AM, Cy Schubert wrote: >>> >>> But, lack of ipv6 fragment processing still causes ongoing pain. That'= >>> s our=20 >>> #1 wish list item for the cluster. > Taking this discussion slightly sideways but touching on this thread a > little, each of our packet filters will need nat66 support too. Pf doesn't > support it for sure. I've been told that ipfw may and I suspect ipfilter > doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Darren From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 13:18:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 330E5C9E; Sat, 26 Jul 2014 13:18:44 +0000 (UTC) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E57BF2B23; Sat, 26 Jul 2014 13:18:43 +0000 (UTC) Received: from fwd11.aul.t-online.de (fwd11.aul.t-online.de [172.20.27.152]) by mailout02.t-online.de (Postfix) with SMTP id 14E584072D4; Sat, 26 Jul 2014 15:18:41 +0200 (CEST) Received: from [192.168.119.33] (b7TwoMZZghdKCBKQE1ztfsWs4npKtrdJpilnk1ZhpO7Dy77XiyC6pe39bjeRTgDweU@[84.154.101.219]) by fwd11.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XB1rr-1f0BpA0; Sat, 26 Jul 2014 15:18:31 +0200 Message-ID: <53D3AAA3.4030506@freebsd.org> Date: Sat, 26 Jul 2014 15:18:27 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Lars Engels , Beeblebrox Subject: Re: Several minor annoyances on Current References: <1406282699515-5931653.post@n5.nabble.com> <53D2A73D.3010404@sasktel.net> <20140726120247.3b763085@rsbsd.rsb> <20140726112414.GG10844@e-new.0x20.net> In-Reply-To: <20140726112414.GG10844@e-new.0x20.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: b7TwoMZZghdKCBKQE1ztfsWs4npKtrdJpilnk1ZhpO7Dy77XiyC6pe39bjeRTgDweU X-TOI-MSGID: 610d8f50-43ab-448f-8348-e633e556946a Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:18:44 -0000 Am 26.07.2014 um 13:24 schrieb Lars Engels: > On Sat, Jul 26, 2014 at 02:03:09AM -0700, Beeblebrox wrote: >> @ Ian: I added your code and rebuilt the kernel. >> /boot/loader.conf also has vfs.nfs.bootp_disable="YES" Previously >> described problem persists. >> >> SEPARATE KBD_KEYMAP ISSUE: The keymap for keyboard fails to be >> set from rc.conf with keymap="fr.iso.kbd" Boot message shows this >> but there is no record of the message in log files/dmesg: >> "Configuring syscons: keymapkbdcontrol: keymap file "fr.iso.kbd" >> not found: No such file or directory" Keymap gets set when I >> change rc.conf entry to: >> keymap="/usr/share/syscons/keymaps/fr.iso.kbd" > > Yes, I also stumbled upon this. Usually the following worked: > > # kbdcontrol -l german.iso # kbdcontrol -l german.iso.kbd # > kbdcontrol -l /usr/share/syscons/keymaps/german.iso.kbd > > In the last few months on HEAD only the latest invocation works. Please retry with kbdcontrol as of SVN revision 269120. With this change, "kbdcontrol -l" looks at up to 4 places for keyboard map definitions: 1) Under the path found in the environment variable KEYMAP_PATH 2) Under the full path name specified as parameter to -l 3) Under the newcons-specific path (/usr/share/vt/keymaps) (***) 4) Under the old path used for syscons (/usr/share/syscons/keymaps) (***) Only if using newcons as reported by sysctl kern.vty For newcons, there was no case 4), it only looked into vt/keymaps. But many keymaps are identical for syscons and newcons and only a few have been converted and placed into /usr/share/vt/keymaps. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 13:22:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55E13E38; Sat, 26 Jul 2014 13:22:34 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::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 6CAA62BCC; Sat, 26 Jul 2014 13:22:33 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id x48so5409334wes.17 for ; Sat, 26 Jul 2014 06:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ppqEkfihE/lsMCuo50Sgpd699uh+4aTfKFl3ghjoKt4=; b=j4ofrRrx64wzHS8Z537Am5wndOylhAYctYQSuV/fVSdDqGt6E4ousT11cxBew0OE7B 4owAUxv9glPztU3Ee3pUmml2vtcJh6NMhK3OGNigm14iq3MSA5U7Jv3bHX7q/arR6tBk XVaZ11to0R+xLt+VCDdfHqvErtW3hDsof3jEPxdg55Tl92ih2GIbLizh/g2uNBErkSb0 V8iCIpikD32VTP4kmxaFZI3D3hlLMSjpq2EbQ6Qn7cFv3SeKgRs9s4aT0uLH3JR+/4gh nIIlWp/MmB3DFdEeaoYGcb+ivYe24Sag83VVu/JpboGZjk5fuYDmtqQ3ymy/MZMvtbzA hq3g== X-Received: by 10.194.2.132 with SMTP id 4mr30720137wju.49.1406380950875; Sat, 26 Jul 2014 06:22:30 -0700 (PDT) Received: from brick.home (cmu49.neoplus.adsl.tpnet.pl. [83.31.148.49]) by mx.google.com with ESMTPSA id wd7sm33644582wjc.36.2014.07.26.06.22.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jul 2014 06:22:30 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 26 Jul 2014 15:22:27 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Cy Schubert Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140726132227.GA6812@brick.home> Mail-Followup-To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <20140725211249.GA3933@brick.home> <201407260246.s6Q2kX7n013280@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:22:34 -0000 On 0725T1946, Cy Schubert wrote: > In message <20140725211249.GA3933@brick.home>, Edward Tomasz > =?utf-8?Q?Napiera= > C5=82a?= writes: > > On 0725T1019, Cy Schubert wrote: > > > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > > > New Automounter > > > > > > > > Contact: Edward Tomasz Napieral/a > > > > > > > > Deficiencies in the current automounter, amd(8), are a recurring > > > > problem reported by many FreeBSD users. A new automounter is being > > > > developed to address these concerns. > > > > > > > > The automounter is a cleanroom implementation of functionality > > > > available in most other Unix systems, using proper kernel support > > > > implemented via an autofs filesystem. The automounter supports a > > > > standard map format, and will integrate with the Lightweight Directory > > > > Access Protocol (LDAP) service. > > > > > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > > > currently integrates with NIS as well. > > > > It's just a matter of testing, apart from a trivial shell script. > > Would you be able to help me with this? > > > > > Sure! Just point me in the direction of the patches. So, the autofs branch is here: https://github.com/trasz/autofs. Directory services integration is done by external executable, which is usually a shell script. There is an LDAP example, at etc/autofs/include_ldap. Script to integrate with other services (which would be include_nis or include_hesiod) needs to do the same - retrieve the map named at the command line and output it to stdout, in a proper format. From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 13:23:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE14B1BA; Sat, 26 Jul 2014 13:23:53 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (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 3D4222BF2; Sat, 26 Jul 2014 13:23:53 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 3DC3C6A6004; Sat, 26 Jul 2014 15:23:50 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s6QDNo1U014906; Sat, 26 Jul 2014 15:23:50 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s6QDNnqo014788; Sat, 26 Jul 2014 15:23:49 +0200 (CEST) (envelope-from lars) Date: Sat, 26 Jul 2014 15:23:49 +0200 From: Lars Engels To: Stefan Esser Subject: Re: Several minor annoyances on Current Message-ID: <20140726132349.GH10844@e-new.0x20.net> Mail-Followup-To: Lars Engels , Stefan Esser , Beeblebrox , freebsd-current@freebsd.org References: <1406282699515-5931653.post@n5.nabble.com> <53D2A73D.3010404@sasktel.net> <20140726120247.3b763085@rsbsd.rsb> <20140726112414.GG10844@e-new.0x20.net> <53D3AAA3.4030506@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vtJ+CqYNzKB4ukR4" Content-Disposition: inline In-Reply-To: <53D3AAA3.4030506@freebsd.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:23:53 -0000 --vtJ+CqYNzKB4ukR4 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 26, 2014 at 03:18:27PM +0200, Stefan Esser wrote: > Am 26.07.2014 um 13:24 schrieb Lars Engels: > > On Sat, Jul 26, 2014 at 02:03:09AM -0700, Beeblebrox wrote: > >> @ Ian: I added your code and rebuilt the kernel.=20 > >> /boot/loader.conf also has vfs.nfs.bootp_disable=3D"YES" Previously > >> described problem persists. > >>=20 > >> SEPARATE KBD_KEYMAP ISSUE: The keymap for keyboard fails to be > >> set from rc.conf with keymap=3D"fr.iso.kbd" Boot message shows this > >> but there is no record of the message in log files/dmesg: > >> "Configuring syscons: keymapkbdcontrol: keymap file "fr.iso.kbd" > >> not found: No such file or directory" Keymap gets set when I > >> change rc.conf entry to: > >> keymap=3D"/usr/share/syscons/keymaps/fr.iso.kbd" > >=20 > > Yes, I also stumbled upon this. Usually the following worked: > >=20 > > # kbdcontrol -l german.iso # kbdcontrol -l german.iso.kbd # > > kbdcontrol -l /usr/share/syscons/keymaps/german.iso.kbd > >=20 > > In the last few months on HEAD only the latest invocation works. >=20 > Please retry with kbdcontrol as of SVN revision 269120. >=20 > With this change, "kbdcontrol -l" looks at up to 4 places for > keyboard map definitions: >=20 > 1) Under the path found in the environment variable KEYMAP_PATH > 2) Under the full path name specified as parameter to -l > 3) Under the newcons-specific path (/usr/share/vt/keymaps) (***) > 4) Under the old path used for syscons (/usr/share/syscons/keymaps) >=20 > (***) Only if using newcons as reported by sysctl kern.vty >=20 > For newcons, there was no case 4), it only looked into vt/keymaps. > But many keymaps are identical for syscons and newcons and only a > few have been converted and placed into /usr/share/vt/keymaps. >=20 > Regards, STefan Thanks, that revision works for me. --vtJ+CqYNzKB4ukR4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJT06vlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tizwIAJVV6GNRPnkHHe12MeEkgXNq iopLaol5WUMbj8RHSEt1zjjRUci+OVSqXd7B7kW6rHFVue7iGJRWAOME4BWGS32g aYijMll1oORDvpXldYMUCDOjSQMwtA80gFv26Ye6N9PRlXXuI32MR5TRhuoJHSaw nymo9QGKkKhTSdf8XjNqOQlG9IJ6eoUM9mjE9InH59BLCls6Z27zfo2bOZiYW2Ps xHOBdRhmdEEkGh+BCdgJQTPmDMEBZJFtobNtpTQkPwE7YsPcGMuGLBClrg+LVu35 DY87GenGaCCWrGLsn0fnVRtf+fGoMPCl+3sA00TphpN0p1gPmyMfSt0ZfcfzhLE= =tRua -----END PGP SIGNATURE----- --vtJ+CqYNzKB4ukR4-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 13:59:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A819B34 for ; Sat, 26 Jul 2014 13:59:24 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 5E5452E4D for ; Sat, 26 Jul 2014 13:59:23 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XB2VJ-000O3a-Dg; Sat, 26 Jul 2014 13:59:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6QDxGJT003424; Sat, 26 Jul 2014 07:59:16 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX191WO/N64I1re9yFMqesvlf X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Several minor annoyances on Current From: Ian Lepore To: Beeblebrox In-Reply-To: <20140726120247.3b763085@rsbsd.rsb> References: <1406282699515-5931653.post@n5.nabble.com> <53D2A73D.3010404@sasktel.net> <20140726120247.3b763085@rsbsd.rsb> Content-Type: text/plain; charset="us-ascii" Date: Sat, 26 Jul 2014 07:59:15 -0600 Message-ID: <1406383155.56408.20.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:59:24 -0000 On Sat, 2014-07-26 at 02:03 -0700, Beeblebrox wrote: > @ Ian: > I added your code and rebuilt the kernel. > /boot/loader.conf also has vfs.nfs.bootp_disable="YES" > Previously described problem persists. > It needs to be set to =1, not =YES. -- Ian > SEPARATE KBD_KEYMAP ISSUE: > The keymap for keyboard fails to be set from rc.conf with > keymap="fr.iso.kbd" > Boot message shows this but there is no record of the message in log files/dmesg: "Configuring syscons: keymapkbdcontrol: keymap file "fr.iso.kbd" not found: No such file or directory" > Keymap gets set when I change rc.conf entry to: keymap="/usr/share/syscons/keymaps/fr.iso.kbd" > > > > > > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931938.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 15:28:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3179C4F; Sat, 26 Jul 2014 15:28:07 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 737522512; Sat, 26 Jul 2014 15:28:07 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 4fc7a4b6; Sat, 26 Jul 2014 10:27:56 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to:sender; s=blargle2; bh=hxRad wc/Za9tV2P5xplJ0z9AfH0=; b=yUUcwSG6TzR+ZWgCFlVc7UTMBi4ccki7TnR/Q hX5zSMB0vEN+RHvcTemDCvqzZayU8p2xvsC6HkeAYCMmTc6Wdak1ZeTsjfMS8VwS DZHTumflyZoXUO9//PAt48nGVav22NbDNiu1DPjEWtwaQUxqO9jSY7Z2z1T4ELab ddRkFEBEYELmrFFg37yB2+rbac0xsMdIpaBxCfbRQoMyz5F9asQ4EwLzH2Dh4F2/ 5UlTKNQQj3ri2c19hB/SKoZc1KT2ljiZv3qIY+I2/nexe0kEDbMCEbE7UovYPXgy rAcMLKLbMk/PjPL7zln/hqs22UfqH5IAV2sXHt+XO2jOgWQeQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to:sender; q=dns; s=blargle2; b= UdQJBEzrjHC3BxKM0q/iGRRXXSSaXLcjOGJ/HPKagg6b3mTvW9EnJU09kzWMoQAJ VGK1kbZ71KKpylzW29MFQaUc+ybtXAugygji3I8TdbNIijX6gG2n3ZJ3lyU2ndhS kDknNh0x0qm/NjjGLE/PM2mdGpgoMDZzjngzxQiu12KGF3KdC/e3+0yO8UJgoc6K IwklQPrNc177SRSeSI2d3vhiioKUE02SUYPbKaMLTkcSs6VGYIHZtHgB+RrEARY+ IKXdHHbe+DIo+wUArUK2C+5ko7KIgJo7Ts5f034zJaca3qPO6mg2lGYee4fo2etJ yGm+ncaxwwe15vjPYJzrQA== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id b91505e7; Sat, 26 Jul 2014 10:27:56 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1406388474-78988-78985/5/2; Sat, 26 Jul 2014 15:27:54 +0000 References: <53C706C9.6090506@com.jkkn.dk> Mime-Version: 1.0 (1.0) In-Reply-To: <53C706C9.6090506@com.jkkn.dk> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Mark Felder Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Date: Sat, 26 Jul 2014 10:27:51 -0500 To: "Kristian K. Nielsen" Sender: feld@feld.me Cc: freebsd-current@freebsd.org, freebsd-questions@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 15:28:07 -0000 We've already heard of Henning offering to help port a new pf but the = olive branch has been extended even further. He responded to some = comments of mine on twitter: @HenningBrauer: @rhymebyter @feldpos I offered help/advice to whomever = seriously attempts to update pf in @dragonflybsd AND @freebsd. @HenningBrauer: @feldpos it takes someone in freebsd/netbsd/dragonfly to = update their ancient pf versions, then code can flow bidirectional Technical hurdles aside, that sounds like the beginning of an OpenPf to = me... From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 17:46:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB1B87EC; Sat, 26 Jul 2014 17:46:53 +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 5A8142085; Sat, 26 Jul 2014 17:46:53 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id f51so6594111qge.4 for ; Sat, 26 Jul 2014 10:46:52 -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=viFMfSu3xL0bTFa8U3C3BEbmu6BVglOxecAYkuGk1mE=; b=DU4ZFOWndCgW/oskVSH1MHmRJnT2yItI2wJCxg9456SFfibHMbBQBk4h59PUkHdxKd MvxgURExfBEgJ2xQ0Fbm8iH7cdpj5yGx3WChiZae1e6OM+jBJHeAobtNEKctFUTf1/2J vyz9+Mcw3LM0BRPDdDJWHNir1aOyC8sXQFR9SMARZUAK4Q86XxJliFTXRHhBgdW+l7gQ n+OWP9fgGFqUoBvIisyonOdEA02Ec8Zq1ANx5PNKBz13pja/hnzU8fIZukT9aNKAP/99 qdPrEVakmhWzvsJe+oUvVtXQGu+gITC6e5U4y21sejLm4QW/RInp3XMPL65uy/m4D6Fd 5GdQ== MIME-Version: 1.0 X-Received: by 10.224.55.131 with SMTP id u3mr40337971qag.98.1406396812546; Sat, 26 Jul 2014 10:46:52 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sat, 26 Jul 2014 10:46:52 -0700 (PDT) In-Reply-To: References: <53C706C9.6090506@com.jkkn.dk> Date: Sat, 26 Jul 2014 10:46:52 -0700 X-Google-Sender-Auth: V2--pUwN4_YN38yAhwN4fgKo044 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Adrian Chadd To: Mark Felder Content-Type: text/plain; charset=UTF-8 Cc: "Kristian K. Nielsen" , freebsd-current , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 17:46:53 -0000 The flow in both directions has to include: * better locking / parallelism * virtualised forwarding support (ie, vimage) If he's happy to include some stubs for that, then sure. I think both dfbsd and freebsd can use the same pf. -a On 26 July 2014 08:27, Mark Felder wrote: > We've already heard of Henning offering to help port a new pf but the olive branch has been extended even further. He responded to some comments of mine on twitter: > > @HenningBrauer: @rhymebyter @feldpos I offered help/advice to whomever seriously attempts to update pf in @dragonflybsd AND @freebsd. > > @HenningBrauer: @feldpos it takes someone in freebsd/netbsd/dragonfly to update their ancient pf versions, then code can flow bidirectional > > Technical hurdles aside, that sounds like the beginning of an OpenPf to me... > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 18:43:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07206A66 for ; Sat, 26 Jul 2014 18:43:43 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id C7DB62544 for ; Sat, 26 Jul 2014 18:43:42 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=6dlcsJ/IGOduaTWa2Dbsml466mjAwLXxxnCzM8r9qRI= c=1 sm=1 a=cQ5pcHtl6RgA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=s6FIl2w8AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=8maHDl6W-6XO_h7xEEEA:9 a=CjuIK1q_8ugA:10 a=cGv0LpZPy6cA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 26 Jul 2014 12:43:41 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 17C589EC3; Sat, 26 Jul 2014 11:43:41 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6QIheGk008600; Sat, 26 Jul 2014 11:43:40 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6QIhcx4008597; Sat, 26 Jul 2014 11:43:39 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407261843.s6QIhcx4008597@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Darren Reed Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message from Darren Reed of "Sat, 26 Jul 2014 21:49:56 +1000." <53D395E4.1070006@fastmail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 2014 11:43:38 -0700 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 18:43:43 -0000 In message <53D395E4.1070006@fastmail.net>, Darren Reed writes: > On 24/07/2014 1:42 AM, Cy Schubert wrote: > >>> > >>> But, lack of ipv6 fragment processing still causes ongoing pain. That'= > >>> s our=20 > >>> #1 wish list item for the cluster. > > Taking this discussion slightly sideways but touching on this thread a > > little, each of our packet filters will need nat66 support too. Pf doesn't > > support it for sure. I've been told that ipfw may and I suspect ipfilter > > doesn't as it was on Darren's todo list from 2009. > > ipfiler 5 handles fragments for ipv6. Switching gears and leaving the discussion of ipv6 fragments to mention nat66. A lot of people have been talking about nat66. I could be wrong but I don't think it can handle nat66. I need to do some testing to verify this. I remember reading on sourceforge that it was on your todo list. It doesn't look like it was checked off as being completed. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 18:45:50 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFB6AC49; Sat, 26 Jul 2014 18:45:50 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8702B256B; Sat, 26 Jul 2014 18:45:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 2CC4738091; Sat, 26 Jul 2014 13:39:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id t1OloxZAZnDP; Sat, 26 Jul 2014 13:39:49 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 9252538090; Sat, 26 Jul 2014 13:39:48 -0500 (CDT) Message-ID: <53D3F5F2.7090403@freebsd.org> Date: Sat, 26 Jul 2014 11:39:46 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Hay , Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> In-Reply-To: <20140725065641.GA88239@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 18:45:51 -0000 On 07/24/14 23:56, John Hay wrote: > On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: >> Hi all, >> >> I'm very please to announce the release of pkg 1.3.0 >> This version is the result of almost 9 month of hard work >> > ... >> Thank you to all contributors: >> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, >> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie >> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, >> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, >> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, >> Vsevolod Stakhov, Xin Li, coctic >> >> Regards, >> Bapt on behalf of the pkg@ > Version 1.3 does better on armeb. It does not crash while installing > itself, but still complains and get the architecture wrong: > > [snip] Would it make sense to get the architecture from the kernel, with a manual override for cross-installs? It seems like that would prevent cases like this permanently. -Nathan From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 19:19:04 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 500AA851; Sat, 26 Jul 2014 19:19:04 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id E48642875; Sat, 26 Jul 2014 19:19:03 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id EED5FB843; Sat, 26 Jul 2014 21:19:00 +0200 (SAST) Date: Sat, 26 Jul 2014 21:19:00 +0200 From: John Hay To: Nathan Whitehorn Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140726191900.GA85979@zibbi.meraka.csir.co.za> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> <53D3F5F2.7090403@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D3F5F2.7090403@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, Baptiste Daroussin , stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 19:19:04 -0000 On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote: > On 07/24/14 23:56, John Hay wrote: > > On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: > >> Hi all, > >> > >> I'm very please to announce the release of pkg 1.3.0 > >> This version is the result of almost 9 month of hard work > >> > > ... > >> Thank you to all contributors: > >> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, > >> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie > >> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, > >> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, > >> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, > >> Vsevolod Stakhov, Xin Li, coctic > >> > >> Regards, > >> Bapt on behalf of the pkg@ > > Version 1.3 does better on armeb. It does not crash while installing > > itself, but still complains and get the architecture wrong: > > > > > [snip] > > Would it make sense to get the architecture from the kernel, with a > manual override for cross-installs? It seems like that would prevent > cases like this permanently. If a file has to be checked, what about the same mechanism that file (libmagic) use? It seems to get it right: root@cambria-build # file /bin/sh /bin/sh: ELF 32-bit MSB executable, ARM, EABI4 version 1 (SYSV), dynamically linked (uses shared libs), FreeBSD-style, for FreeBSD 11.0 (1100028), stripped John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 19:40:18 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 594C336A; Sat, 26 Jul 2014 19:40:18 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 7274C2A82; Sat, 26 Jul 2014 19:40:17 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ho1so2528820wib.10 for ; Sat, 26 Jul 2014 12:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=aDNauzxtFJfrdZNfJUuTSeKxdBBowdUzkLJQRVAPb1s=; b=Xi3LJ7612mrzu3ytepL8aSxCj01wCaqDjjAdf41vwjtsAzPaFx+1llpwfwoSDW80Ap d3FoHT2JPFgZiphdLi8KhqWSXHOCEWDoXA0L3BflZsWj74+dXwMMSgsWihf/9L3l9Smk zJePN0GRBdaB3+KxXIXMmWnAzSN4H9Y0/WNtSSfJEeznFrYbOLYxOlQUJXlkPJNpEQuo nJbDN8keHDDJuintMoD7tOVZYxIzdJq6hVDEvq+hPgSnljfUmi3gkPaV6Da8EgQzrGoU xyf1hNZ6bJZaqgBhBf4lOPwqvJ+IpRy6mZqZiomH4Vg/WIgZ83kdKJ+J0EVIL8EkvGGf yAgQ== X-Received: by 10.194.219.225 with SMTP id pr1mr33664817wjc.34.1406403615658; Sat, 26 Jul 2014 12:40:15 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fr4sm10658483wic.16.2014.07.26.12.40.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jul 2014 12:40:14 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 26 Jul 2014 21:40:11 +0200 From: Baptiste Daroussin To: Nathan Whitehorn Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140726194011.GB50802@ivaldir.etoilebsd.net> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> <53D3F5F2.7090403@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <53D3F5F2.7090403@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: John Hay , ports@freebsd.org, stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 19:40:18 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote: > On 07/24/14 23:56, John Hay wrote: > > On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: > >> Hi all, > >> > >> I'm very please to announce the release of pkg 1.3.0 > >> This version is the result of almost 9 month of hard work > >> > > ... > >> Thank you to all contributors: > >> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad D= avis, > >> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova= , Jamie > >> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Ar= nold, > >> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicol= as Szalay, > >> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. P= utrya, > >> Vsevolod Stakhov, Xin Li, coctic > >> > >> Regards, > >> Bapt on behalf of the pkg@ > > Version 1.3 does better on armeb. It does not crash while installing > > itself, but still complains and get the architecture wrong: > > > > > [snip] >=20 > Would it make sense to get the architecture from the kernel, with a=20 > manual override for cross-installs? It seems like that would prevent=20 > cases like this permanently. > -Nathan THis will be completely rework including the patch you already sent me for = pkg 1.4.0. regards, Bapt --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPUBBsACgkQ8kTtMUmk6ExOEQCcDZhSiyS/lasjgb9WecyZnzXO zHEAn2LImuQLrs6GKxPu2HyKhdcNmDtP =nQ3m -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 19:53:03 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79CBDA22; Sat, 26 Jul 2014 19:53:03 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id BFE1B2C22; Sat, 26 Jul 2014 19:53:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 03C3F38091; Sat, 26 Jul 2014 14:53:02 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id N_6-j6VzmHBp; Sat, 26 Jul 2014 14:53:01 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 6747738090; Sat, 26 Jul 2014 14:53:01 -0500 (CDT) Message-ID: <53D4071C.60607@freebsd.org> Date: Sat, 26 Jul 2014 12:53:00 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> <53D3F5F2.7090403@freebsd.org> <20140726194011.GB50802@ivaldir.etoilebsd.net> In-Reply-To: <20140726194011.GB50802@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Hay , ports@freebsd.org, stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 19:53:03 -0000 On 07/26/14 12:40, Baptiste Daroussin wrote: > On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote: >> On 07/24/14 23:56, John Hay wrote: >>> On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: >>>> Hi all, >>>> >>>> I'm very please to announce the release of pkg 1.3.0 >>>> This version is the result of almost 9 month of hard work >>>> >>> ... >>>> Thank you to all contributors: >>>> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, >>>> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie >>>> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, >>>> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, >>>> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, >>>> Vsevolod Stakhov, Xin Li, coctic >>>> >>>> Regards, >>>> Bapt on behalf of the pkg@ >>> Version 1.3 does better on armeb. It does not crash while installing >>> itself, but still complains and get the architecture wrong: >>> >>> >> [snip] >> >> Would it make sense to get the architecture from the kernel, with a >> manual override for cross-installs? It seems like that would prevent >> cases like this permanently. >> -Nathan > THis will be completely rework including the patch you already sent me for pkg > 1.4.0. > > regards, > Bapt Oh sure. I'm not suggesting this be done now, or even close to now. Adding in another case for armeb to the existing ELF logic is a far easier solution that fixes the immediate issue. Just musing about longer term. -Nathan