From owner-freebsd-stable@FreeBSD.ORG Sun Sep 7 02:16:54 2014 Return-Path: Delivered-To: stable@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 D31B533B for ; Sun, 7 Sep 2014 02:16:54 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 AFC7610F4 for ; Sun, 7 Sep 2014 02:16:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s872GsXG020197 for ; Sun, 7 Sep 2014 02:16:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193389] [panic] ufs_dirbad: /: bad dir Date: Sun, 07 Sep 2014 02:16:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 02:16:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193389 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian@freebsd.org --- Comment #1 from Adrian Chadd --- Have you run a full fsck on the filesystem? -a -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Sun Sep 7 05:05:03 2014 Return-Path: Delivered-To: freebsd-stable@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 69ED3E7B for ; Sun, 7 Sep 2014 05:05:03 +0000 (UTC) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by mx1.freebsd.org (Postfix) with ESMTP id 020221008 for ; Sun, 7 Sep 2014 05:05:01 +0000 (UTC) Received: from ppp118-210-249-247.lns20.adl6.internode.on.net (HELO leader.local) ([118.210.249.247]) by ipmail07.adl2.internode.on.net with ESMTP; 07 Sep 2014 14:35:00 +0930 Message-ID: <540BE76D.6020802@ShaneWare.Biz> Date: Sun, 07 Sep 2014 14:34:45 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Zoran Kolic Subject: Re: update to pkg 1.3.7 References: <20140906050944.GA4460@knossos> <540AB7EB.5050602@ShaneWare.Biz> <20140906122659.GA677@faust.sbb.rs> In-Reply-To: <20140906122659.GA677@faust.sbb.rs> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 05:05:03 -0000 On 06/09/2014 21:56, Zoran Kolic wrote: >> There was an issue found which is resolved in 1.3.7 >> pkg check -Ba is also needed to fix the db >> >> For binary package users: >> # pkg install ports-mgmt/pkg >> # pkg update -f >> # pkg check -Ba >> # pkg upgrade > > Ah! I misunderstood check part! Thanks! > Do I need to use last command (pkg upgrade) if I > want to install anything, without upgrading whole > system? > Best regards > > Zoran No you don't have to but probably should. The first three steps setup pkg 1.3.7, the fourth upgrades installed ports and could be changed to individual installs if you wish. Most would argue strongly that you **should** update all pkg's at this point as the new packages made using pkg 1.3.7 will have updated pkg info related to the fix in 1.3.7 and the pkg check step. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Sun Sep 7 14:41:01 2014 Return-Path: Delivered-To: freebsd-stable@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 8540F275 for ; Sun, 7 Sep 2014 14:41:01 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 43ED11E01 for ; Sun, 7 Sep 2014 14:41:01 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3616D153A8C; Sun, 7 Sep 2014 16:40:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsc2WRh5ziYF; Sun, 7 Sep 2014 16:40:45 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id A84881534C4; Sun, 7 Sep 2014 16:27:48 +0200 (CEST) Message-ID: <540C6B64.7030309@digiware.nl> Date: Sun, 07 Sep 2014 16:27:48 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Shane Ambler , Zoran Kolic Subject: Re: update to pkg 1.3.7 References: <20140906050944.GA4460@knossos> <540AB7EB.5050602@ShaneWare.Biz> <20140906122659.GA677@faust.sbb.rs> <540BE76D.6020802@ShaneWare.Biz> In-Reply-To: <540BE76D.6020802@ShaneWare.Biz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 14:41:01 -0000 On 7-9-2014 7:04, Shane Ambler wrote: > On 06/09/2014 21:56, Zoran Kolic wrote: >>> There was an issue found which is resolved in 1.3.7 >>> pkg check -Ba is also needed to fix the db >>> >>> For binary package users: >>> # pkg install ports-mgmt/pkg >>> # pkg update -f >>> # pkg check -Ba >>> # pkg upgrade >> >> Ah! I misunderstood check part! Thanks! >> Do I need to use last command (pkg upgrade) if I >> want to install anything, without upgrading whole >> system? >> Best regards >> >> Zoran > > No you don't have to but probably should. The first three steps setup > pkg 1.3.7, the fourth upgrades installed ports and could be changed to > individual installs if you wish. > > Most would argue strongly that you **should** update all pkg's at this > point as the new packages made using pkg 1.3.7 will have updated pkg > info related to the fix in 1.3.7 and the pkg check step. > Why not put the above explanation in the post-install as extra explanation for those that do not read the UPGRADING notices?? Even better would perhaps be that pkg reports this itself when run without an updated and checked database. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Sep 7 14:53:44 2014 Return-Path: Delivered-To: freebsd-stable@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 84B884B0 for ; Sun, 7 Sep 2014 14:53:44 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e: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 56E4B1EE5 for ; Sun, 7 Sep 2014 14:53:44 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id kx10so1403591pab.3 for ; Sun, 07 Sep 2014 07:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cDE2Ac9thH7HIezfS0l2IyTjVi3nt3XlCnfoR4eva04=; b=RwACfe/oZFPOvm8cc3crLl8RdHiJXNZk5pPooCEyQdqvCWTuQoShGOR3JMLf80Pf8o 70Y/uVgKrfuVkD5doyzflPeTSkDzYAiy/ZE4fY1WwG9if9i3SpkqBSJvJ4RSeEogsOsb Og+wm9WrGt3CNvdMHOG3HNTaqEZaaw8T4oV8j0AeF5/LoIX+JGwfJmahO0ILTagO4CNJ ISE/N/8XP2Tz0bd6rjtz3H0fBLKnTf6Sp1to9InfeGUvWEDf7dj5FNWLHF7MJgxx3etw 25eg6uMNpHTl9YMNpqIr222gz7F4KPWLFjlhvsYcmMzzB9dyu9DYL19zwGyuiWFpMLY/ e8Lw== X-Received: by 10.70.131.199 with SMTP id oo7mr38986488pdb.95.1410101623525; Sun, 07 Sep 2014 07:53:43 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id ah2sm7054114pad.10.2014.09.07.07.53.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Sep 2014 07:53:43 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <540C7171.3070806@FreeBSD.org> Date: Mon, 08 Sep 2014 00:53:37 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: Needs triage .. References: <20140906221516.Q58647@sola.nimnet.asn.au> <20140906125502.GA1892@elch.exwg.net> <20140906230043.H58647@sola.nimnet.asn.au> <540B0C87.9070005@FreeBSD.org> <20140907004047.F58647@sola.nimnet.asn.au> In-Reply-To: <20140907004047.F58647@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 14:53:44 -0000 On 7/09/2014 12:49 AM, Ian Smith wrote: > On Sat, 6 Sep 2014 23:30:47 +1000, Kubilay Kocak wrote: > > On 6/09/2014 11:23 PM, Ian Smith wrote: > > > On Sat, 6 Sep 2014 14:55:03 +0200, Christoph Moench-Tegeder wrote: > > > > ## Ian Smith (smithi@nimnet.asn.au): > > > > > > > > > Are these just getting auto-assigned to stable@? Can anyone play? :) > > > > > > > > The submitter explicitly adds stable@ to the bug's Cc list. > > > > > > Yes, and this submitter hasn't posted in the dozen lists I take, since > > > May anyway. This may save someone having to assign a bug, but perhaps > > > one shouldn't earn the 'mayCC' bit until some N>0 have been assigned? > > > > > > > But anyways, looking at the amount of panics he reports, most of which > > > > happen on rather trivial actions (as far as I can tell from my sampling > > > > of reports), this looks like bad hardware. > > > > If anyone with a hat could tell the sasamotikomi? > > > > > > I'm more concerned about process (vs PRs) and bulk spam potential than > > > the reporting methods of any one submitter; bugzilla is overall cool. > > > > > > cheers, Ian > > > > Ian, > > > > Please create an issue report assigned to bugmeister, with 'keyword: > > feature' describing the issue, and thoughts on different ways you can > > think of a mechanism potentially working. > > > > -- > > Kubilay > > for Bugmeister > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193396 > > No further ideas to hand beyond what I suggested above, sorry. > > cheers, Ian > That's perfect, thank you Ian Koobs for Bugmeister From owner-freebsd-stable@FreeBSD.ORG Sun Sep 7 23:57:06 2014 Return-Path: Delivered-To: freebsd-stable@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 0EDFD3A4 for ; Sun, 7 Sep 2014 23:57:06 +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 CFCD51D27 for ; Sun, 7 Sep 2014 23:57:05 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id n16so10071944oag.4 for ; Sun, 07 Sep 2014 16:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YZI/+fh9Fi1V2yuUyshH9cPs7HehI6YacwHv7yPY8Kk=; b=I2TAqY4o+9UXzYpKa103B2jgM1bhKp9JqpW0tatgVsjnBPbRRzyuLJsNDGjq/mHWhk GuwN3WWBbgEyMKJy4QeXxTKj+BlDHeDPep4h9JoW/v1gySFlHoRISc6hzu2BlUDKXwRs A3GlhMwzgFI2cjFTbLbeSMlZjSSnBP2uocgv1gFS6jHuPKBmh4ReirGlg3ar1TDFel0j tuR9MHZ0gsvol7rWC4NrI74LmZpDOlSGOueD8S/MIc4gAYLTLjOfJzKHCDJjJdB0M8Da eneGcZnkNLtmYvkEeuh+X4YhPwZeKVwFxWO/1Xgrn7F/we7Yb6kYqEk1vuIGmO3mE1PO YojQ== MIME-Version: 1.0 X-Received: by 10.60.133.46 with SMTP id oz14mr28552989oeb.23.1410134225049; Sun, 07 Sep 2014 16:57:05 -0700 (PDT) Received: by 10.76.72.105 with HTTP; Sun, 7 Sep 2014 16:57:05 -0700 (PDT) Date: Mon, 8 Sep 2014 01:57:05 +0200 Message-ID: Subject: Unable to build stable From: Geir Svalland To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 23:57:06 -0000 Hello. uname -a FreeBSD ymer.thorshammare.org 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 06:34:23 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 I'm unable to make buildworld on todays stable revision 271241 due to the following error message : -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp -o SemaLookup.o /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp:4410:55: error: source file is not valid UTF-8 TmpRes.setLookupName(QRI->getCorrectionAsIdetifierInfo()); ^ /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp:4410:37: error: no member named 'getCorrectionAsIde' in 'clang::TypoCorrection'; did you mean 'getCorrectionRange'? TmpRes.setLookupName(QRI->getCorrectionAsIdetifierInfo()); ^~~~~~~~~~~~~~~~~~ getCorrectionRange /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include/clang/Sema/TypoCorrection.h:207:15: note: 'getCorrectionRange' declared here SourceRange getCorrectionRange() const { ^ /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp:4410:56: error: expected ')' TmpRes.setLookupName(QRI->getCorrectionAsIdetifierInfo()); ^ /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp:4410:31: note: to match this '(' TmpRes.setLookupName(QRI->getCorrectionAsIdetifierInfo()); ^ 3 errors generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/lib/clang/libclangsema *** Error code 1 Stop. make[3]: stopped in /usr/src/lib/clang *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src any hints on how to proceed ? Best regards Hasse From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 05:42:21 2014 Return-Path: Delivered-To: freebsd-stable@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 4E1A6568 for ; Mon, 8 Sep 2014 05:42:21 +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 0A3EF181E for ; Mon, 8 Sep 2014 05:42:21 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::dd52:a15d:3286:3b83] (unknown [IPv6:2001:7b8:3a7:0:dd52:a15d:3286:3b83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 69510B803; Mon, 8 Sep 2014 07:42:14 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8CA19674-51B0-4188-B91E-08D44B0BEC57"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Unable to build stable From: Dimitry Andric In-Reply-To: Date: Mon, 8 Sep 2014 07:41:53 +0200 Message-Id: References: To: Geir Svalland X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 05:42:21 -0000 --Apple-Mail=_8CA19674-51B0-4188-B91E-08D44B0BEC57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 08 Sep 2014, at 01:57, Geir Svalland wrote: > uname -a > FreeBSD ymer.thorshammare.org 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 = #0: > Tue Jul 8 06:34:23 UTC 2014 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > i386 >=20 >=20 > I'm unable to make buildworld on todays stable revision 271241 > due to the following error message : >=20 > -fno-exceptions -fno-rtti -c > = /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema= /SemaLookup.cpp > -o SemaLookup.o > = /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema= /SemaLookup.cpp:4410:55: > error: source file is not valid UTF-8 > = TmpRes.setLookupName(QRI->getCorrectionAsIdetifierInfo()); > ^ That line should read: TmpRes.setLookupName(QRI->getCorrectionAsIdentifierInfo()); So either your source checkout is corrupt, or your hardware flips bits = randomly. -Dimitry --Apple-Mail=_8CA19674-51B0-4188-B91E-08D44B0BEC57 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) iEYEARECAAYFAlQNQbMACgkQsF6jCi4glqNphgCcDURPesZknsI3Fu+3zAqu6HM9 G/wAoJB3RhgdY7jlTff8YS5n3i9w1vjW =BjVi -----END PGP SIGNATURE----- --Apple-Mail=_8CA19674-51B0-4188-B91E-08D44B0BEC57-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 07:51:04 2014 Return-Path: Delivered-To: freebsd-stable@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 7BC42DDF; Mon, 8 Sep 2014 07:51:04 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 3917D134D; Mon, 8 Sep 2014 07:51:04 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wn1so10369477obc.7 for ; Mon, 08 Sep 2014 00:51:03 -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=e50Pe+a2LSFTB3xwV+u8+TUpIRLp4D3GUgb+oTKiUu8=; b=UYX2HGRXCUYd6aez/AgDh5RZiGEyHeIzKYgax4zsq3L+LTXY+CU627xVeYTxtG0cz/ v52tpRk76RzjS/lu/aj9zsBNCmh/b6w7hgN+9QX9iwl6UAXzPJ2jF+YML99i7vzYPU+f PFga+GDGtIiWpTIK7Kb+SwMPN4b3e6hhyTUvrQEeBGDVWe6Hu44p1Dru2LOaNNgDTr/p nrVAnOSxBe8InTLzsYepm2oiWHW+/Vii4KAQzC3aWuoSYmEyEJi7ILj5nJGEILHDr3uH pUfgsGh9TP3wxn2QvR0kdDK6C19kh445X35gQn7eAYzkq2G5pl0dESSuCSloqUCFJOXW rzTg== MIME-Version: 1.0 X-Received: by 10.60.34.98 with SMTP id y2mr31625068oei.9.1410162663499; Mon, 08 Sep 2014 00:51:03 -0700 (PDT) Received: by 10.76.72.105 with HTTP; Mon, 8 Sep 2014 00:51:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Sep 2014 09:51:03 +0200 Message-ID: Subject: Re: Unable to build stable From: Geir Svalland To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 07:51:04 -0000 Thank you for your answer. So I'll wipe /usr/src and do a new "checkout / buildworld" as a first step. /hasse 2014-09-08 7:41 GMT+02:00 Dimitry Andric : > On 08 Sep 2014, at 01:57, Geir Svalland wrote: > > uname -a > > FreeBSD ymer.thorshammare.org 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 > #0: > > Tue Jul 8 06:34:23 UTC 2014 > > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > > i386 > > > > > > I'm unable to make buildworld on todays stable revision 271241 > > due to the following error message : > > > > -fno-exceptions -fno-rtti -c > > > /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp > > -o SemaLookup.o > > > /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp:4410:55: > > error: source file is not valid UTF-8 > > TmpRes.setLookupName(QRI->getCorrectionAsIdetifierInfo()); > > ^ > > That line should read: > > TmpRes.setLookupName(QRI->getCorrectionAsIdentifierInfo()); > > So either your source checkout is corrupt, or your hardware flips bits > randomly. > > -Dimitry > > -- m.v.h Geir Svalland g.svalland@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 16:44:19 2014 Return-Path: Delivered-To: stable@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 72B56BDD for ; Mon, 8 Sep 2014 16:44:19 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 5A94A18B3 for ; Mon, 8 Sep 2014 16:44:19 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s88GiJJj036899 for ; Mon, 8 Sep 2014 16:44:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193363] [panic] panic at reboot Date: Mon, 08 Sep 2014 16:44:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:44:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193363 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #1 from John Baldwin --- Can you do 'gdb /boot/kernel.old9.1/kernel' and then 'l *0xc0aae65'? Also, can you provide more details about your system (e.g. do you have an ed(4) or xl(4) NIC)? A non-verbose dmesg would be a good start. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 16:49:49 2014 Return-Path: Delivered-To: stable@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 342AFFC6 for ; Mon, 8 Sep 2014 16:49:49 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 1C1EB192C for ; Mon, 8 Sep 2014 16:49:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s88GnmxM039638 for ; Mon, 8 Sep 2014 16:49:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Mon, 08 Sep 2014 16:49:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:49:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #5 from John Baldwin --- In all these crashes, the root bug is a NULL pointer dereference (probably) at drm_ioctl+0x2ca. Can you provide the kgdb backtrace from a single core.txt file? It would be good to see what source line corresponds to that address. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 16:50:49 2014 Return-Path: Delivered-To: stable@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 DE1ED175 for ; Mon, 8 Sep 2014 16:50:49 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 C627619D4 for ; Mon, 8 Sep 2014 16:50:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s88GonAG042604 for ; Mon, 8 Sep 2014 16:50:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193364] [panic] ffs_blkfree_cg: freeing free block Date: Mon, 08 Sep 2014 16:50:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:50:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193364 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #2 from John Baldwin --- Your filesystem is probably corrupted from an earlier crash. Run fsck in single user mode. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 16:51:05 2014 Return-Path: Delivered-To: stable@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 7B1132AF for ; Mon, 8 Sep 2014 16:51:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 633F019ED for ; Mon, 8 Sep 2014 16:51:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s88Gp5pK043960 for ; Mon, 8 Sep 2014 16:51:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193364] [panic] ffs_blkfree_cg: freeing free block Date: Mon, 08 Sep 2014 16:51:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:51:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193364 --- Comment #3 from John Baldwin --- *** Bug 193365 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 16:51:05 2014 Return-Path: Delivered-To: stable@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 11D122AB for ; Mon, 8 Sep 2014 16:51:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 EDD8719E6 for ; Mon, 8 Sep 2014 16:51:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s88Gp46F043882 for ; Mon, 8 Sep 2014 16:51:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193365] [panic] handle_written_inodeblock: Invalid link count Date: Mon, 08 Sep 2014 16:51:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:51:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193365 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |Issue Resolved CC| |jhb@FreeBSD.org Resolution|--- |DUPLICATE --- Comment #3 from John Baldwin --- *** This bug has been marked as a duplicate of bug 193364 *** -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 16:55:32 2014 Return-Path: Delivered-To: stable@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 4DEF05A6 for ; Mon, 8 Sep 2014 16:55:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 35C2D1A5C for ; Mon, 8 Sep 2014 16:55:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s88GtWKK072768 for ; Mon, 8 Sep 2014 16:55:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193360] [panic] [syscons] random syscons panic Date: Mon, 08 Sep 2014 16:55:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:55:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193360 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #2 from John Baldwin --- For these and the other various PRs you opened recently, you need to remove the 'grep 0x' from the 'nm -n' output. That removes most of the useful symbols and isn't helpful. In addition, far more useful would be to get stack traces, especially if you have core.txt.N files, the kgdb stack trace in that file would be the first thing needed to look at any of these. As I mentioned on another bug, a dmesg from this machine wouldn't hurt either, but I doubt that either ed(4) or xl(4) is relevant. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 8 19:43:25 2014 Return-Path: Delivered-To: freebsd-stable@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 F3716DEC for ; Mon, 8 Sep 2014 19:43:24 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE3521058 for ; Mon, 8 Sep 2014 19:43:24 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so18450476iec.12 for ; Mon, 08 Sep 2014 12:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=paNAG5pj0UJM/XLfT1O7iC8wfSaH34n6bkwJ5k4EitM=; b=iWVZz+PiPy18KuYJ+aDeegcx7NM+7WvynUDfWD3T5R1PA5VBF2EmCqUkAd5cj4Uota 4n+WIth/RCt7BNhLSmzpGNumHLM8yDAmFOsIVBjpG9xKrWCAVTcnSiAqeG/2pwc3Qdfr f7R7n6aFXYp7ZsLntBVzm9bntNdBDfiya7K60UmWnjQW+/gOGSZCfcmX+QsbfyS1lMDo sMZVx0FsveLGc+WsZgkBPyHX/OiG+H0495s34fIuCEpH8QH8QRsk+Rm99DIT2cSBupd7 NpkWHuW6q/UEvGxdeD4Vf5UXctTGcezD236wQs4MmSe9Yjg6fxCAEbURv/NsuV0KraLS x5jw== X-Received: by 10.50.41.8 with SMTP id b8mr25130033igl.11.1410205404137; Mon, 08 Sep 2014 12:43:24 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.1 with HTTP; Mon, 8 Sep 2014 12:43:03 -0700 (PDT) In-Reply-To: <20140906100236.a63aa268ab5b92abc45da2e4@mail.neosystem.cz> References: <20140903204605.GA16445@dft-labs.eu> <5408402B.20704@FreeBSD.org> <5408897F.2040107@dumbbell.fr> <20140906100236.a63aa268ab5b92abc45da2e4@mail.neosystem.cz> From: Ed Maste Date: Mon, 8 Sep 2014 15:43:03 -0400 X-Google-Sender-Auth: yhilPNHHINE_019IwJJsJGR7Xs4 Message-ID: Subject: Re: Anyone else seeing lockup on boot with r271042? To: Daniel Bilik Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 19:43:25 -0000 On 6 September 2014 04:02, Daniel Bilik wrote: > On Fri, 5 Sep 2014 07:57:51 -0600 (MDT) > Warren Block wrote: > >> As of r271160, startup does not have a problem with devd. Only tested >> once, though. > > I can confirm that bunch of recent commits (most probably the mega MFC of > vt(4) from emaste@) fixed the problem, and 10-STABLE boots fine for me now. > Thank you Ed. :) Thank you for checking - very glad to hear it's working for you now. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 04:11:59 2014 Return-Path: Delivered-To: freebsd-stable@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 48096D89; Tue, 9 Sep 2014 04:11:59 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::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 0C895989; Tue, 9 Sep 2014 04:11:59 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id v10so8141090pde.19 for ; Mon, 08 Sep 2014 21:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=333mhcI224ESWFlvuSUc6dSd6Cokuhik3c/J+zywhtY=; b=CeQFTwEjFjgyHu0aLCv+8DbYBSR6kPMQMlbi6k4WK2M3+D3Ll5xpk1PhIiSfM+nqif ziv2iSnx9Z0IgkoclKqzVWZwY+yuY8yGrjj5IAA3klj8k5eJ8tN67OLZihod9jwZnhy1 TrnvpWT1Xgq1X6Pz+bUrq/bbYEbMtgfPwnFDL/zza6X8PDfks2b/FKQj9Rvj+HCY3223 7CGqhtnNjWcCIojAuR64Gs13MBO2qBiu0h8oB2NwW9d9GkGCNAejLVb33bd/CjUmCj9f RZwECWvLvlHQEq+43BPM+drw/8EcW70GYdzVZi3Zxxt5yUIJHzxgFSi5fCeI2SrRca9l MK6Q== X-Received: by 10.69.27.71 with SMTP id je7mr8791554pbd.155.1410235918538; Mon, 08 Sep 2014 21:11:58 -0700 (PDT) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id td4sm10900064pab.19.2014.09.08.21.11.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 21:11:57 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_264B747A-585A-4378-84B2-7419B4F8C816"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svn commit: r271298 - in stable/10: . etc/mtree libexec/atf libexec/atf/atf-check libexec/atf/atf-sh share/mk tools/build/mk usr.bin From: yaneurabeya@gmail.com In-Reply-To: <201409090400.s8940Vwv099647@svn.freebsd.org> Date: Mon, 8 Sep 2014 21:11:57 -0700 Message-Id: <22676884-CC9A-4DF1-8D3C-F30B6661238E@gmail.com> References: <201409090400.s8940Vwv099647@svn.freebsd.org> To: Garrett Cooper X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 04:11:59 -0000 --Apple-Mail=_264B747A-585A-4378-84B2-7419B4F8C816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 8, 2014, at 21:00, Garrett Cooper wrote: > Author: ngie > Date: Tue Sep 9 04:00:30 2014 > New Revision: 271298 > URL: http://svnweb.freebsd.org/changeset/base/271298 >=20 > Log: > MFC r267176, r267181, r268445 (ATF-related commits): >=20 > Phabric: https://reviews.freebsd.org/D706 > Approved by: rpaulo (mentor) > Approved by: re (gjb) > Reviewed by: jmmv > Sponsored by: EMC / Isilon Storage Division Hello all! If you are running stable/10 with MK_TESTS =3D=3D yes after this = point, please be sure to run a complete buildworld without -DNO_CLEAN = and run make delete-old, or you might run into false positives with test = cases/suites that use atf-sh. Thank you! -Garrett --Apple-Mail=_264B747A-585A-4378-84B2-7419B4F8C816 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUDn4NAAoJEMZr5QU6S73ebPUH/3jLvgfws4oohzmPsiH1yVX+ RpDZcKIihDACMoobPDUoUVdMKAx70nXrLE3tsCcMqKIitHf7RhTy0YckDdU1zjVj XwK1svZ0T9n0BN9ZXffIFRN5b1Ecp4ca7iFVTomQPJ+rQrn8qYbRqLyzGwJUL8/f 3GoLGkr/6sxIogyMYyvfXVRmEjVsBoyAAmGdZRXw59xrpbuYAANXaEX2GacBflbu oG41lierB5jwM8Wk4g9yfkQurzV7Pj5pwEauOovOF4U5mNnDuvJ8kUp+i4cdoPK5 zbFMjcEOJQMRqJrBdwdBhZrw0mzDWkllx7t5LXeWACemVAH4id0IY6gvvDcycn8= =Uv5b -----END PGP SIGNATURE----- --Apple-Mail=_264B747A-585A-4378-84B2-7419B4F8C816-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 09:04:54 2014 Return-Path: Delivered-To: freebsd-stable@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 32478C87; Tue, 9 Sep 2014 09:04:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 13AD583F; Tue, 9 Sep 2014 09:04:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6DB8889; Tue, 9 Sep 2014 09:04:54 +0000 (UTC) Date: Tue, 9 Sep 2014 09:04:54 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org Message-ID: <1978535074.3.1410253494423.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #731 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 09:04:54 -0000 See ------------------------------------------ Started by user rodrigc Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace java.io.IOException: remote file operation failed: at hudson.remoting.Channel@7f30f143:jenkins-10.freebsd.org at hudson.FilePath.act(FilePath.java:918) at hudson.FilePath.act(FilePath.java:895) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:848) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:786) at hudson.model.AbstractProject.checkout(AbstractProject.java:1254) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.remoting.Channel.call(Channel.java:748) at hudson.FilePath.act(FilePath.java:911) ... 11 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class sun.nio.ch.FileChannelImpl at java.io.RandomAccessFile.getChannel(RandomAccessFile.java:273) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFile.(SqlJetFile.java:181) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileSystem.open(SqlJetFileSystem.java:193) at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.open(SqlJetPager.java:395) at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.open(SqlJetBtree.java:325) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.open(SqlJetEngine.java:195) at org.tmatesoft.sqljet.core.table.SqlJetDb.open(SqlJetDb.java:127) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.open(SVNSqlJetDb.java:114) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.openDb(SVNWCDb.java:3585) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1462) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.detectWcGeneration(SvnOperationFactory.java:1643) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.getImplementation(SvnOperationFactory.java:1307) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1227) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2423) at hudson.scm.subversion.UpdateUpdater$TaskImpl.parseSvnInfo(UpdateUpdater.java:125) at hudson.scm.subversion.UpdateUpdater$TaskImpl.getSvnCommandToUse(UpdateUpdater.java:87) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:130) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:908) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:889) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2492) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 10:10:37 2014 Return-Path: Delivered-To: freebsd-stable@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 E3773B7A for ; Tue, 9 Sep 2014 10:10:36 +0000 (UTC) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 69377E08 for ; Tue, 9 Sep 2014 10:10:36 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id b17so18999653lan.22 for ; Tue, 09 Sep 2014 03:10:28 -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:date:message-id:subject:from:to :content-type; bh=iW1HauEdehlCFUsYwCebQVKTfRLItDWkYE9L3geQwoo=; b=AWn2+KsSR8cvAaU32OgnQgUDpyAaORhCJfN2kE4p5leoLIua6N2oIT3BVD37i6I9sh UnJLgINT4fy8PSDZto4eXNmFefcOHIFd1oD9BAMmfpy9Qw/LKTIV/Z73VHHBofo5LpIp vUnibW6xY140eWUXc2erE7ry7XfBUbEnhrPsQUDe8UGx5TW2PeNua1A5Z72PXQ927jdA 0hMtRu63YfYLoJmVlONank/mYoJNLNljyyD7OukHt8g3/dHTTetU3nLhv065GEbSt1MO 8tKxPv+SOvePzJELRM5DxdeZIzVUvc5nBw3ppzlfbSVKg3zAc1XoELfN+Kz03AsEqBk9 dFCg== X-Gm-Message-State: ALoCoQlQkOghFyIzRMjf5MFUTNXluHk/o6UYIH5gytRdMxZ51Vj66wYMR/t5vU+VvMWV6SWRWO+A MIME-Version: 1.0 X-Received: by 10.112.156.138 with SMTP id we10mr17808596lbb.68.1410257127249; Tue, 09 Sep 2014 03:05:27 -0700 (PDT) Received: by 10.112.219.106 with HTTP; Tue, 9 Sep 2014 03:05:27 -0700 (PDT) Date: Tue, 9 Sep 2014 12:05:27 +0200 Message-ID: Subject: 8.4 - libgcrypt won't build, complains about xgetbv missing from assembler From: Damien Fleuriot To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 10:10:37 -0000 Hello list, I'm hitting this peculiar problem on 8.4-STABLE where /usr/ports/security/libgcrypt/ won't build and complains about xgetbv , per : == /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -D_THREAD_SAFE -I/usr/local/include -pipe -g -std=gnu89 -fvisibility=hidden -Wall -MT hwf-x86.lo -MD -MP -MF .deps/hwf-x86.Tpo -c -o hwf-x86.lo hwf-x86.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -D_THREAD_SAFE -I/usr/local/include -pipe -g -std=gnu89 -fvisibility=hidden -Wall -MT hwf-x86.lo -MD -MP -MF .deps/hwf-x86.Tpo -c hwf-x86.c -fPIC -DPIC -o .libs/hwf-x86.o hwf-x86.c:150: warning: 'get_xgetbv' defined but not used {standard input}: Assembler messages: {standard input}:106: Error: no such instruction: `xgetbv' *** Error code 1 Stop in /usr/ports/security/libgcrypt/work/libgcrypt-1.6.1/src. *** Error code 1 == Googling around suggests the problem might stem from /usr/bin/as as reports version : == GNU assembler 2.15 [FreeBSD] 2004-05-23 == 10-STABLE compiles security/libgcrypt just fine, with /usr/bin/as version 2.17.50 The ports tree is up to date as of today. Is anyone able to reproduce the problem on 8.4 ? From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 11:06:46 2014 Return-Path: Delivered-To: freebsd-stable@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 F3F1B9A4 for ; Tue, 9 Sep 2014 11:06:45 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 7C34F836 for ; Tue, 9 Sep 2014 11:06:44 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id v6so2570761lbi.41 for ; Tue, 09 Sep 2014 04:06:42 -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:date :message-id:subject:from:to:content-type; bh=lopBPcQdVazu//Ji8iqOjU6JJL2M9/AONxM834ePIrg=; b=f5qt+dnLOJ4NMI5PSN24ZEA+xJlKqYrX5FsLvIgKkeLV++MWYzFggCnVNHKyV2tUlQ zs4ZlA7a0bHm8GuIxq1OK2horW40s4uPyiE0rIAAhRG9HvAsrn/QK2mHb3Ox5uTO/ZjF C8QVQC/4IRDaWo+WTJxWd6pd/+Jzuo1n5AwTva+Y2y5sXW91d7+CAHPvWdciafYVzld2 TA0QwvtHRcyMiKwxkXQ2IQKLreWRw/jwy2M9ifmUKbQ2IL0/nA9kaBlL15w/YKO5F/IZ dq23EIupHIWLesEq0QEeuXavcYM1+LEs4RstVw/8BlKTurpXxi/sNu9xLQOuukljnkx+ ZMFQ== X-Gm-Message-State: ALoCoQms3vE+8wmI/zSoAIRsecAyDkiCFlbkBi2sWmTzVHF9Awzx+od46rdP1FAxyc4Wa0pNdMnl MIME-Version: 1.0 X-Received: by 10.152.10.41 with SMTP id f9mr35510865lab.25.1410260802660; Tue, 09 Sep 2014 04:06:42 -0700 (PDT) Received: by 10.112.219.106 with HTTP; Tue, 9 Sep 2014 04:06:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Sep 2014 13:06:42 +0200 Message-ID: Subject: Re: 8.4 - libgcrypt won't build, complains about xgetbv missing from assembler From: Damien Fleuriot To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 11:06:46 -0000 For what it's worth, managed to solve the problem by : - changing CPU type from KVM (it's a virtual machine) to Host (Xeon) - rebuilding kernel-toolchain - rebuilding kernel - rebuilding world - reinstalling kernel + world - rebuilding port On 9 September 2014 12:05, Damien Fleuriot wrote: > Hello list, > > > > I'm hitting this peculiar problem on 8.4-STABLE where > /usr/ports/security/libgcrypt/ won't build and complains about xgetbv , per > : > > == > /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I.. -D_THREAD_SAFE -I/usr/local/include -pipe -g -std=gnu89 > -fvisibility=hidden -Wall -MT hwf-x86.lo -MD -MP -MF .deps/hwf-x86.Tpo -c > -o hwf-x86.lo hwf-x86.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -D_THREAD_SAFE > -I/usr/local/include -pipe -g -std=gnu89 -fvisibility=hidden -Wall -MT > hwf-x86.lo -MD -MP -MF .deps/hwf-x86.Tpo -c hwf-x86.c -fPIC -DPIC -o > .libs/hwf-x86.o > hwf-x86.c:150: warning: 'get_xgetbv' defined but not used > {standard input}: Assembler messages: > {standard input}:106: Error: no such instruction: `xgetbv' > *** Error code 1 > Stop in /usr/ports/security/libgcrypt/work/libgcrypt-1.6.1/src. > *** Error code 1 > == > > > Googling around suggests the problem might stem from /usr/bin/as > > as reports version : > == > GNU assembler 2.15 [FreeBSD] 2004-05-23 > == > > > 10-STABLE compiles security/libgcrypt just fine, with /usr/bin/as version > 2.17.50 > > The ports tree is up to date as of today. > > > Is anyone able to reproduce the problem on 8.4 ? > > From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 11:07:13 2014 Return-Path: Delivered-To: freebsd-stable@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 03067ACC; Tue, 9 Sep 2014 11:07:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E67CB881; Tue, 9 Sep 2014 11:07:12 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3D997188; Tue, 9 Sep 2014 11:07:13 +0000 (UTC) Date: Tue, 9 Sep 2014 11:07:13 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org Message-ID: <1434533796.7.1410260833229.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1978535074.3.1410253494423.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1978535074.3.1410253494423.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #732 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 11:07:13 -0000 See From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 11:23:09 2014 Return-Path: Delivered-To: freebsd-stable@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 93E32EA6 for ; Tue, 9 Sep 2014 11:23:09 +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 216CDAF1 for ; Tue, 9 Sep 2014 11:23:08 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id s89BN1Jm082400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 9 Sep 2014 12:23:02 +0100 (BST) (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk s89BN1Jm082400 Authentication-Results: smtp.infracaninophile.co.uk/s89BN1Jm082400; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <540EE30E.7060305@freebsd.org> Date: Tue, 09 Sep 2014 12:22:54 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: 10.1-PRERELEASE -- mirrored swap ? Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fFXEhgOSontNPvJjD7wrC2ONuM37P8sjd" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no 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-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 11:23:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fFXEhgOSontNPvJjD7wrC2ONuM37P8sjd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I needed to install 10.1-PRERELEASE on some new hardware as we'd fluffed the timing slightly and bought kit with an LSI SAS 3004 HBA, which 10.0 doesn't support. Anyhow, I was gratified to see the option to 'Mirror Swap' in the installer, as that's something we'd always want to do. However, on this server, we installed onto a RAIDZ1 of 6 drives, resulting in: root@log-1:~ # swapinfo Device 1K-blocks Used Avail Capacity /dev/mirror/swap 2097148 0 2097148 0% root@log-1:~ # gmirror status Name Status Components mirror/swap COMPLETE da0p2 (ACTIVE) da1p2 (ACTIVE) da2p2 (ACTIVE) da3p2 (ACTIVE) da4p2 (ACTIVE) da5p2 (ACTIVE) Huh? A 6-way mirror seems pretty daft here. I'd have expected 3 swap devices each comprised of a 2-way mirror. Cheers, Matthew --fFXEhgOSontNPvJjD7wrC2ONuM37P8sjd 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 iQJ8BAEBCgBmBQJUDuMVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnOpoP/R1OBNPcpsGPYC0X1qzHqZt9 BY/j0RiEyxG+4dUR4geazQhQ5/uza9m8CK7fpCkFgXCKh5Y4eyM5OzVaiE3NNZzu QUJ33HrP39GJRqFzSUt1E1FwRw11remDrMcRdTH7H/bNmcRkc2fkCWwYQ3fmVpYb dSw69XT1RkSJvUwh2akN+iWdLCRBnU4ju14+0zJ/1/eosJLuNzR3CGZzCJ9fE578 1d44hz4sq0a+nIjIgqu4YTqugrOPRBKhv+VWKEmz0YZNsJV7Q7Q45TPbG4eOWRmn k4MZmYpoJfq2vUf2Ak2LVBm2xGs2DwAPWE79/XiIqGTaCYwlrbcTCngzYyJvXPzI wQePCQa2JcO7xgjzBYMSL3ppOWRiU5jgnxFIDy8CujkR2GQHrRTVb3uVV3O5P0nN qtsMfdPiqjKHRTKuiCT9vtmciHEunesbVSN9nj+93OOgw/b51k3R9WbtqQQ8A+7q qJA/Gmkm8Gjjx02E5HYwZlnbFg8CGkr3QAJrjR4CbvOneBG4/+g2Ij428cnE6hcP KDOZI1IXKoZYjaed9fyZlCdfOq5ypearpSt1Fxg4bGbLMxIG7sH/hpyuJoa2Z3KJ ZeMBS5O9V3JhqEpiLOwWkgaIxTcswFXuTDDbv26USrpqaCEPVVC3uUNbchqNGteF 0RfMddZizZrxl1cVP2aH =dHuy -----END PGP SIGNATURE----- --fFXEhgOSontNPvJjD7wrC2ONuM37P8sjd-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 15:09:58 2014 Return-Path: Delivered-To: freebsd-stable@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 70CB0C4E for ; Tue, 9 Sep 2014 15:09:58 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 3CEED8C8 for ; Tue, 9 Sep 2014 15:09:57 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBN0065Q3FNY300@st11p09mm-asmtp001.mac.com> for freebsd-stable@freebsd.org; Tue, 09 Sep 2014 15:09:27 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-09_05:2014-09-09,2014-09-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=21 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409090132 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Subject: Re: ZFS on root booting broken somewhere after r270020 From: Kimmo Paasiala In-reply-to: Date: Tue, 09 Sep 2014 18:09:22 +0300 Content-transfer-encoding: quoted-printable Message-id: <7643523D-3839-42FC-A9CB-EAF3E6B028DB@icloud.com> References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> To: "freebsd-stable@freebsd.org" X-Mailer: Apple Mail (2.1973.6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 15:09:58 -0000 > On 9.9.2014, at 17.23, Kimmo Paasiala wrote: >=20 >=20 >> On 19.8.2014, at 10.46, Konstantin Belousov = wrote: >>=20 >> On Tue, Aug 19, 2014 at 10:32:08AM +0300, Kimmo Paasiala wrote: >>>=20 >>> On 19.8.2014, at 10.10, Konstantin Belousov = wrote: >>>=20 >>>> On Tue, Aug 19, 2014 at 07:40:46AM +0300, Kimmo Paasiala wrote: >>>>>=20 >>>>> On 18.8.2014, at 8.54, Kimmo Paasiala wrote: >>>>>=20 >>>>>>=20 >>>>>> On 18.8.2014, at 2.32, Kimmo Paasiala = wrote: >>>>>>=20 >>>>>>> System is: >>>>>>>=20 >>>>>>> FreeBSD freebsd10.rdnzl.info 10.0-STABLE FreeBSD 10.0-STABLE #2 = r270020: Fri Aug 15 20:38:59 EEST 2014 = kimmo@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >>>>>>>=20 >>>>>>> This version still works fine. The one that didn?t work was = r270097. The kernel boots but gets stuck at the line: >>>>>>>=20 >>>>>>> Trying to mount root from zfs:pool/ROOT/default [] >>>>>>>=20 >>>>>>> I tried pressing enter at this point but got a panic, I don?t = have a screenshot of the panic at the moment. >>>>>>>=20 >>>>>>> Could this problem be related the this commit? : >>>>>>>=20 >>>>>>> = http://svnweb.freebsd.org/base?view=3Drevision&sortby=3Drev&sortdir=3Ddown= &revision=3D270095 >>>>>>>=20 >>>>>>> -Kimmo >>>>>>=20 >>>>>> Trying to bisect this I backed to r270050 and that version still = works. More to come. >>>>>>=20 >>>>>> -Kimmo >>>>>=20 >>>>> Version r270094 still works but commit r270095 definitely does = break booting from ZFS on root on my system. The error message I see on = the console is ?Mounting from failed with error 5? = and I?m given the mountroot prompt. I don?t see the ZFS pool among the = listed GEOM devices on the mountroot prompt. >>>>>=20 >>>>> Adding the committer of r270095 (kib@) to this discussion. >>>>=20 >>>> I have no idea about ZFS, but the fact that things, which are = lower-level >>>> than ZFS filesystem itself are missing, suggests that the issue is = unrelated. >>>> At the very least, start with providing the verbose boot dmesg for = successful >>>> and failed boots. >>>=20 >>> This looks like to be unrelated to ZFS as you?re saying. I just = remembered that I?m loading fuse.ko in my /boot/loader.conf. I commented = that one out and what do you know? The system boots fine with the = r270095 kernel. >>>=20 >>> Very very strange?=20 >> This probably indicates KBI mismatch. >>=20 >> Is your fuse.ko installed from the kernel build ? >> Still, I think the verbose dmesg is the start to look. >>=20 >>>=20 >>> Thanks for the input anyway, >>>=20 >>> -Kimmo >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 > Hi it=E2=80=99s me again. Something that was committed in stable/10 = after r271213 up to and including r271288 broke ZFS on Root booting in = exactly the same way again. I know the problem is no longer related to = extra kernel modules loaded in /boot/loader.conf because I=E2=80=99m = loading only the required zfs.ko and opensolaris.ko modules. Also, the = new vt(4) console that I=E2=80=99m using is not the culprit because the = same thing happens with kern.vty set to =E2=80=9Csc=E2=80=9D. >=20 > -Kimmo Verbose dmesg logs from both versions at pastebin if anyone wants to = take a look: r271213 (the one that still works): http://pastebin.com/A6rAkDpB r271288 (the one where booting from ZFS is now broken): = http://pastebin.com/sq6FnVr0 Both are with the sc console, the new vt console doesn=E2=80=99t quite = work at mountroot console for me. Running diff(1) on those I didn=E2=80=99t spot any obvious differences = except in some memory addresses that is to be expected. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 15:24:02 2014 Return-Path: Delivered-To: freebsd-stable@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 C33855B2 for ; Tue, 9 Sep 2014 15:24:02 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 8FD15AEF for ; Tue, 9 Sep 2014 15:24:02 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBN00LXS1AEJH90@st11p09mm-asmtp001.mac.com> for freebsd-stable@freebsd.org; Tue, 09 Sep 2014 14:23:05 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-09_05:2014-09-09,2014-09-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=21 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409090129 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Subject: Re: ZFS on root booting broken somewhere after r270020 From: Kimmo Paasiala In-reply-to: <20140819074643.GU2737@kib.kiev.ua> Date: Tue, 09 Sep 2014 17:23:01 +0300 Content-transfer-encoding: quoted-printable Message-id: References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> To: "freebsd-stable@freebsd.org" X-Mailer: Apple Mail (2.1973.6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 15:24:02 -0000 > On 19.8.2014, at 10.46, Konstantin Belousov = wrote: >=20 > On Tue, Aug 19, 2014 at 10:32:08AM +0300, Kimmo Paasiala wrote: >>=20 >> On 19.8.2014, at 10.10, Konstantin Belousov = wrote: >>=20 >>> On Tue, Aug 19, 2014 at 07:40:46AM +0300, Kimmo Paasiala wrote: >>>>=20 >>>> On 18.8.2014, at 8.54, Kimmo Paasiala wrote: >>>>=20 >>>>>=20 >>>>> On 18.8.2014, at 2.32, Kimmo Paasiala wrote: >>>>>=20 >>>>>> System is: >>>>>>=20 >>>>>> FreeBSD freebsd10.rdnzl.info 10.0-STABLE FreeBSD 10.0-STABLE #2 = r270020: Fri Aug 15 20:38:59 EEST 2014 = kimmo@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >>>>>>=20 >>>>>> This version still works fine. The one that didn?t work was = r270097. The kernel boots but gets stuck at the line: >>>>>>=20 >>>>>> Trying to mount root from zfs:pool/ROOT/default [] >>>>>>=20 >>>>>> I tried pressing enter at this point but got a panic, I don?t = have a screenshot of the panic at the moment. >>>>>>=20 >>>>>> Could this problem be related the this commit? : >>>>>>=20 >>>>>> = http://svnweb.freebsd.org/base?view=3Drevision&sortby=3Drev&sortdir=3Ddown= &revision=3D270095 >>>>>>=20 >>>>>> -Kimmo >>>>>=20 >>>>> Trying to bisect this I backed to r270050 and that version still = works. More to come. >>>>>=20 >>>>> -Kimmo >>>>=20 >>>> Version r270094 still works but commit r270095 definitely does = break booting from ZFS on root on my system. The error message I see on = the console is ?Mounting from failed with error 5? = and I?m given the mountroot prompt. I don?t see the ZFS pool among the = listed GEOM devices on the mountroot prompt. >>>>=20 >>>> Adding the committer of r270095 (kib@) to this discussion. >>>=20 >>> I have no idea about ZFS, but the fact that things, which are = lower-level >>> than ZFS filesystem itself are missing, suggests that the issue is = unrelated. >>> At the very least, start with providing the verbose boot dmesg for = successful >>> and failed boots. >>=20 >> This looks like to be unrelated to ZFS as you?re saying. I just = remembered that I?m loading fuse.ko in my /boot/loader.conf. I commented = that one out and what do you know? The system boots fine with the = r270095 kernel. >>=20 >> Very very strange?=20 > This probably indicates KBI mismatch. >=20 > Is your fuse.ko installed from the kernel build ? > Still, I think the verbose dmesg is the start to look. >=20 >>=20 >> Thanks for the input anyway, >>=20 >> -Kimmo >>=20 >>=20 >>=20 >=20 >=20 Hi it=E2=80=99s me again. Something that was committed in stable/10 = after r271213 up to and including r271288 broke ZFS on Root booting in = exactly the same way again. I know the problem is no longer related to = extra kernel modules loaded in /boot/loader.conf because I=E2=80=99m = loading only the required zfs.ko and opensolaris.ko modules. Also, the = new vt(4) console that I=E2=80=99m using is not the culprit because the = same thing happens with kern.vty set to =E2=80=9Csc=E2=80=9D. -Kimmo=20= From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 15:53:16 2014 Return-Path: Delivered-To: freebsd-stable@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 B7197229 for ; Tue, 9 Sep 2014 15:53:16 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 767DEE84 for ; Tue, 9 Sep 2014 15:53:16 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 965F720E7088E; Tue, 9 Sep 2014 15:53:13 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 95AC420E7088B; Tue, 9 Sep 2014 15:53:11 +0000 (UTC) Message-ID: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> From: "Steven Hartland" To: "Kimmo Paasiala" , References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> Subject: Re: ZFS on root booting broken somewhere after r270020 Date: Tue, 9 Sep 2014 16:53:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit 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-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 15:53:16 -0000 ----- Original Message ----- From: "Kimmo Paasiala" > Hi it’s me again. Something that was committed in stable/10 after r271213 up to > and including r271288 broke ZFS on Root booting in exactly the same way again. > I know the problem is no longer related to extra kernel modules loaded in > /boot/loader.conf because I’m loading only the required zfs.ko and opensolaris.ko > modules. Also, the new vt(4) console that I’m using is not the culprit because the > same thing happens with kern.vty set to “sc”. I've just updated my stable/10 box to r271316 and no problems booting from a ZFS root. So first things first what error are you seeing? Next what is you're: * Hardware * Pool layout Regards Steve From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 16:03:51 2014 Return-Path: Delivered-To: freebsd-stable@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 050C8A42 for ; Tue, 9 Sep 2014 16:03:51 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 C45D2FC7 for ; Tue, 9 Sep 2014 16:03:50 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBN003YT5XE7OB0@st11p09mm-asmtp001.mac.com> for freebsd-stable@freebsd.org; Tue, 09 Sep 2014 16:03:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-09_06:2014-09-09,2014-09-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409090133 Subject: Re: ZFS on root booting broken somewhere after r270020 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Content-type: text/plain; charset=utf-8 From: Kimmo Paasiala X-Priority: 3 In-reply-to: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> Date: Tue, 09 Sep 2014 19:03:13 +0300 Content-transfer-encoding: quoted-printable Message-id: References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1973.6) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:03:51 -0000 > On 9.9.2014, at 18.53, Steven Hartland = wrote: >=20 > ----- Original Message ----- From: "Kimmo Paasiala" = >> Hi it=E2=80=99s me again. Something that was committed in stable/10 = after r271213 up to >> and including r271288 broke ZFS on Root booting in exactly the same = way again. >> I know the problem is no longer related to extra kernel modules = loaded in >> /boot/loader.conf because I=E2=80=99m loading only the required = zfs.ko and opensolaris.ko >> modules. Also, the new vt(4) console that I=E2=80=99m using is not = the culprit because the >> same thing happens with kern.vty set to =E2=80=9Csc=E2=80=9D. >=20 > I've just updated my stable/10 box to r271316 and no problems booting = from a ZFS root. >=20 > So first things first what error are you seeing? >=20 > Next what is you're: > * Hardware > * Pool layout >=20 > Regards > Steve=20 The error is the same as before: =E2=80=A2 Mounting from zfs:rdnzltank/ROOT/default failed with = error 5. Followed by the mountroot prompt and I get only these devices to choose = from, no sign of the ZFS pool: =E2=80=A2 mountroot> =E2=80=A2 List of GEOM managed disk devices: =E2=80=A2 gpt/fb10disk1 gpt/fb10swap1 = diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 = diskid/DISK-S13UJDWS301624p1 ada0p3 ada0p2 ada0p1 = diskid/DISK-S13UJDWS301624 ada0 Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: http://www.gigabyte.com/products/product-page.aspx?pid=3D3343#ov 4GBs of RAM. One 750GB Samsung HD753LJ 3.5=E2=80=9D SATA HD on the Intel = SATA controller. Pool layout: pool: rdnzltank state: ONLINE scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 09:27:48 = 2014 config: NAME STATE READ WRITE CKSUM rdnzltank ONLINE 0 0 0 gpt/fb10disk1 ONLINE 0 0 0 errors: No known data errors Output of =E2=80=98gpart show=E2=80=99: freebsd10 ~ % gpart show =20 =3D> 34 1465146988 ada0 GPT (699G) 34 2014 - free - (1.0M) 2048 1024 1 freebsd-boot (512K) 3072 1024 - free - (512K) 4096 16777216 2 freebsd-swap (8.0G) 16781312 1448365710 3 freebsd-zfs (691G) HTH, -Kimmo= From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 18:56:37 2014 Return-Path: Delivered-To: freebsd-stable@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 50148EBD for ; Tue, 9 Sep 2014 18:56:37 +0000 (UTC) Received: from smtp2.bway.net (smtp2.v6.bway.net [IPv6:2607:d300:1::28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2585279D for ; Tue, 9 Sep 2014 18:56:37 +0000 (UTC) Received: from [10.3.2.41] (foon.sporktines.com [96.57.144.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp2.bway.net (Postfix) with ESMTPSA id EAAF09586F for ; Tue, 9 Sep 2014 14:56:27 -0400 (EDT) From: Charles Sprickman Content-Type: multipart/signed; boundary="Apple-Mail=_D096E7B8-A858-432A-AFB2-C76D78FC9104"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: VMware and 8.4 known issues? Message-Id: Date: Tue, 9 Sep 2014 14:56:25 -0400 To: freebsd-stable Stable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 18:56:37 -0000 --Apple-Mail=_D096E7B8-A858-432A-AFB2-C76D78FC9104 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, I have about a dozen FreeBSD 8.4 VMs running on a pair of ESXi (5.0.0, build 469512) boxes. Generally, I have not had any problems with this configuration. However one particular VM, which is running the same kernel and same VMware settings as the other VMs has paniced twice in the past few months. I do not have a core dump, but both times a message regading the CD-ROM device was logged shortly before the panic: Sep 9 08:50:56 shellvm kernel: ata1: WARNING - READ_TOC read data overrun 18>12 Prior to the panic, the only thing Ive observed via my normal nagios checks was that snmp and other network services became unavailable and ping times to the host became very erratic, jumping from a few ms to 800ms+. After the panic, the VM is locked up hard and consuming copious amounts of CPU. Looking around I see two things of note: https://communities.vmware.com/message/1876880 (suggests it=92s an issue with FreeBSDs CD-ROM handling) = http://freebsd.1045724.n5.nabble.com/Re-kern-150186-parallels-panic-Parall= els-Desktop-CDROM-disconnected-leads-to-panic-eventually-td4114484.html (also suggests CD issues) This thread also ends with Ivan Voras stating "I'd say it's 'well known' - at least the panic also happens on VMWare, and has been happening for many years. Ill try the suggested fix of completely removing the CD-ROM device (its currently in the device list, but is not connected), but Im curious if theres any reference Ive missed regarding known VMware issues and/or best practices. Ill be sure to grab a console screenshot if it happens again, I have little hope of getting a dump though, as it seems the whole IO system is locked up. Thanks, Charles -- Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet www.bway.net spork@bway.net - 212.982.9800 --Apple-Mail=_D096E7B8-A858-432A-AFB2-C76D78FC9104 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUD01ZAAoJEMfwH0dqLIp2xLsIAIS0tmoV4a3DfckFLlgii0Br T+MVgR8Ec2gi6pzmOoCW63yJIZpTm5qXlnxRhUa+TfPHybKcVqatXUChR6szYzyj /d09V/jOzNwjvCT6/0aoUKAM6JRAZq0uyRVF6g6JGgLt397wUha0/x1E86ha4U6I GxfbaZYT8menwcuWCQVDtl4tOzofaOP3iOrqW7z188glViT5BHa+lRdBECcdJUcI TJ4Yn3z4owA06xIbt3T6p3uXzKX+iZBGMVvkSX6AbnXkRT3WG5a2OKNhvwkNBncU WX7Xo7Zk9PBjpAge8y33rQS1pTjo7Eur70nWr8L0XhxCCyiTeBzKLlbjBvCMeWM= =tvkH -----END PGP SIGNATURE----- --Apple-Mail=_D096E7B8-A858-432A-AFB2-C76D78FC9104-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 22:22:13 2014 Return-Path: Delivered-To: freebsd-stable@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 2A7FF3E0 for ; Tue, 9 Sep 2014 22:22:13 +0000 (UTC) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (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 D760D110 for ; Tue, 9 Sep 2014 22:22:12 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id c9so18276874qcz.39 for ; Tue, 09 Sep 2014 15:22:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1Gv9fitv/hz9e6DIlO4EbIN+w587M2GSMJgDejMWFfY=; b=c14q+AMiA9q8tpuyezkNGxlJXMPHyUs8bhwXE/3Q9bxPGvjq1MPPdJjh1hpPKrFyHy eVq/Krk0/+2bi1Q+F2BPPr0HxZiWUVAyP5X/x+s3Ej7HW1Pk5rUpKQFA8A1MV5rxD9Yg 0/PlJgqoYXTJvhrnbd2mqK6SsO5YokjcWEmoylN7X/5R/VPbzkWcroPO1gE7UQRieUey xOWKXuMHGK2BPIQQQssMpKm4//U1X9W+YftBkrQ6xRNULOqm0dca93BK3kfPDKOJPpdW jLyBWEqFzaqsJp1zmMP4Ai5nPV+0kYIylHtue6at+hBi+oCo7Pj7QlRqKb5EYsBz46OZ CSmw== X-Gm-Message-State: ALoCoQm6P3Bqs+oYmvM4WNqG5FyvyGnVPZdOP8xBvRtoyCDopAmofrgb70W5WWQ6A6dSZJqGky0g X-Received: by 10.224.92.83 with SMTP id q19mr53533995qam.29.1410301324670; Tue, 09 Sep 2014 15:22:04 -0700 (PDT) Received: from [97.62.85.214] (214.sub-97-62-85.myvzw.com. [97.62.85.214]) by mx.google.com with ESMTPSA id i110sm10907244qgf.29.2014.09.09.15.21.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 15:22:03 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Mark Saad Subject: Re: VMware and 8.4 known issues? Date: Tue, 9 Sep 2014 18:12:50 -0400 To: Charles Sprickman Cc: freebsd-stable Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 22:22:13 -0000 > On Sep 9, 2014, at 2:56 PM, Charles Sprickman wrote: >=20 > Hello, >=20 > I have about a dozen FreeBSD 8.4 VMs running on a pair of ESXi > (5.0.0, build 469512) boxes. Generally, I have not had any problems > with this configuration. However one particular VM, which is > running the same kernel and same VMware settings as the other VMs > has paniced twice in the past few months. >=20 > I do not have a core dump, but both times a message regading the > CD-ROM device was logged shortly before the panic: >=20 > Sep 9 08:50:56 shellvm kernel: ata1: WARNING - READ_TOC read data > overrun 18>12 >=20 > Prior to the panic, the only thing Ive observed via my normal nagios > checks was that snmp and other network services became unavailable > and ping times to the host became very erratic, jumping from a few > ms to 800ms+. After the panic, the VM is locked up hard and > consuming copious amounts of CPU. >=20 > Looking around I see two things of note: >=20 > https://communities.vmware.com/message/1876880 (suggests it=E2=80=99s an > issue with FreeBSDs CD-ROM handling) >=20 > http://freebsd.1045724.n5.nabble.com/Re-kern-150186-parallels-panic-Parall= els-Desktop-CDROM-disconnected-leads-to-panic-eventually-td4114484.html > (also suggests CD issues) >=20 I dropped the CDROM as it's also caused a weird issues were sysinstall would= not find any daN devices if both were present . This was only an issue when= using sysinstall to jumpstart a box.=20 > This thread also ends with Ivan Voras stating "I'd say it's 'well > known' - at least the panic also happens on VMWare, and has been > happening for many years. >=20 > Ill try the suggested fix of completely removing the CD-ROM device > (its currently in the device list, but is not connected), but Im > curious if theres any reference Ive missed regarding known VMware > issues and/or best practices. Ill be sure to grab a console > screenshot if it happens again, I have little hope of getting a dump > though, as it seems the whole IO system is locked up. >=20 > Thanks, >=20 > Charles >=20 Also try to set the event timer to acpi-fast or acpi-safe . It's a sysctl na= med something like kern.timecounter.choice . There is a buggy emulated hpet i= n some versions on esxi that kill the clock on FreeBSD and Linux . There is a= kb on how to fix the issue dr Linux boxes circa 2011 .=20 =20 -- Mark saad | mark.saad@longcount.org=20 > -- Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best > Internet www.bway.net spork@bway.net - 212.982.9800 >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Sep 9 22:50:00 2014 Return-Path: Delivered-To: freebsd-stable@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 1FDE8E73 for ; Tue, 9 Sep 2014 22:50:00 +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 CC22D36E for ; Tue, 9 Sep 2014 22:49:59 +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 9EB4325D37C3; Tue, 9 Sep 2014 22:49:57 +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 99CF5C77036; Tue, 9 Sep 2014 22:49:56 +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 zUi04453q6xq; Tue, 9 Sep 2014 22:49:55 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3] (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5C896C77035; Tue, 9 Sep 2014 22:49:53 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VMware and 8.4 known issues? From: "Bjoern A. Zeeb" In-Reply-To: Date: Tue, 9 Sep 2014 22:50:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <89955644-02C2-4C4B-A4DD-AE5C6B308DA4@lists.zabbadoz.net> References: To: Charles Sprickman X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 22:50:00 -0000 On 09 Sep 2014, at 18:56 , Charles Sprickman wrote: Hi, > I have about a dozen FreeBSD 8.4 VMs running on a pair of ESXi > (5.0.0, build 469512) boxes. Generally, I have not had any problems > with this configuration. However one particular VM, which is > running the same kernel and same VMware settings as the other VMs > has paniced twice in the past few months. >=20 > I do not have a core dump, but both times a message regading the > CD-ROM device was logged shortly before the panic: >=20 > Sep 9 08:50:56 shellvm kernel: ata1: WARNING - READ_TOC read data > overrun 18>12 I remember those from 2010. Not been running freebsd 8 in a long time. The best workaround I found back then was indeed to remove CDROM (and = for that matter also did the floppy;-) as much as possible from VMware. = I cannot remember if that was good enough to get entirely rid of it = anymore ( I think some devices maybe floppy still showed up ) but I have = never seen this after going to 9 and 10 certainly. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 06:47:15 2014 Return-Path: Delivered-To: freebsd-stable@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 A79E5A6C for ; Wed, 10 Sep 2014 06:47:15 +0000 (UTC) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 303E1FD1 for ; Wed, 10 Sep 2014 06:47:14 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloKALDzD1Q7p/kP/2dsb2JhbABZg2BXgnyuOQaZCoh0eIQtBAsBOQoCDycCBRYLAgsDAgECAQlCDQgBAYg9mGGOIIEUlTcEgSiEUIxRgVMFhhqRSEuQaYkLgWcegW5agk8BAQE Received: from eth4368.nsw.adsl.internode.on.net (HELO fish.ish.com.au) ([59.167.249.15]) by ipmail06.adl6.internode.on.net with ESMTP; 10 Sep 2014 16:16:35 +0930 Received: from ip-136.ish.com.au ([203.29.62.136]:53339) by fish.ish.com.au with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1XRbfh-0005qp-07 for freebsd-stable@freebsd.org; Wed, 10 Sep 2014 16:46:29 +1000 Message-ID: <540FF3C4.6010305@ish.com.au> Date: Wed, 10 Sep 2014 16:46:28 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: freebsd-stable Subject: getting to 4K disk blocks in ZFS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 06:47:15 -0000 As we all know, it is important to ensure that modern disks are set up properly with the correct block size. Everything is good if all the disks and the pool are "ashift=9" (512 byte blocks). But as soon as one new drive requires 4k blocks, performance drops through the floor of the enture pool. In order to upgrade there appear to be two separate things that must be done for a ZFS pool. 1. Create partitions on 4K boundaries. This is simple with the "-a 4k" option in gpart, and it isn't hard to remove disks one at a time from a pool, reformat them on the right boundaries and put them back. Hopefully you've left a few spare bytes on the disk to ensure that your partition doesn't get smaller when you reinsert it to the pool. 2. Create a brand new pool which has ashift=12 and zfs send|receive all the data over. I guess I don't understand enough about zpool to know why the pool itself has a block size, since I understood ZFS to have variable stripe widths. The problem with step 2 is that you need to have enough hard disks spare to create a whole new pool and throw away the old disks. Plus a disk controller with lots of spare ports. Plus the ability to take the system offline for hours or days while the migration happens. One way to reduce this slightly is to create a new pool with reduced redundancy. For example, create a RAIDZ2 with two fake disks, then offline those disks. So, given how much this problem sucks (it is extremely easy to add a 4K disk by mistake as a replacement for a failed disk), and how painful the workaround is... will ZFS ever gain the ability to change block size for the pool? Or is this so deep in the internals of ZFS it is as likely as being able to dynamically add disks to an existing zvol in the "never going to happen" basket? And secondly, is it also bad to have ashift 9 disks inside a ashift 12 pool? That is, do we need to replace all our disks in one go and forever keep big sticky labels on each disk so we never mix them? Thanks for any advice Ari Maniatis -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 06:51:08 2014 Return-Path: Delivered-To: freebsd-stable@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 2FF77D16 for ; Wed, 10 Sep 2014 06:51:08 +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 0F0E810E for ; Wed, 10 Sep 2014 06:51:07 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 09E16385; Tue, 9 Sep 2014 23:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1410331867; bh=d0hSeuFaIlqOihB5PD04ctY+QUKC+dT1w2yDXH7/vlM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=q5GnnD4NJSEpTEp6ZHyqAkQI6E3Fkmi1ahWuXTTVBoglA8FD1VhdaIeXdZJvzAe3N wlTtv08puwVSLxzhm38mB3dVcQ9nor2vOAe2gJmqRqnlQOzeKyfF1+nMFwxzCE7r8W DKPE5UHJgNm0dwgrS9dpVwbrP2eArTBsUZ/AUXwA= From: Peter Wemm To: freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS Date: Tue, 09 Sep 2014 23:51:01 -0700 Message-ID: <6384455.xLarv7m8fO@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <540FF3C4.6010305@ish.com.au> References: <540FF3C4.6010305@ish.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1622072.FDWEii6vFl"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 06:51:08 -0000 --nextPart1622072.FDWEii6vFl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Wednesday, September 10, 2014 04:46:28 PM Aristedes Maniatis wrote: > As we all know, it is important to ensure that modern disks are set u= p > properly with the correct block size. Everything is good if all the d= isks > and the pool are "ashift=3D9" (512 byte blocks). But as soon as one n= ew drive > requires 4k blocks, performance drops through the floor of the enture= pool. [..] > And secondly, is it also bad to have ashift 9 disks inside a ashift 1= 2 pool? > That is, do we need to replace all our disks in one go and forever ke= ep big > sticky labels on each disk so we never mix them? For what its worth, in the freebsd.org cluster we automatically align=20= everything to a minimum of 4k, no matter what the actual drive is. We set: sysctl vfs.zfs.min_auto_ashift=3D12 (this saves a lot of messing around with gnop etc) and ensure all the gpt slices are 4k or better aligned. =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 --nextPart1622072.FDWEii6vFl 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 iQEcBAABAgAGBQJUD/TaAAoJEDXWlwnsgJ4EQQMIAKq8KMWaXMqm1Wwhc4rfCl7x FgSiNZpvHu6fIhbwhEQCdsDwoq2igztanzemMh50Kz5TV9FBLs99ol20q1FKiKxv 385emfODj5uODDCiQTBnwjtk6yP/z2aOs7YWutFBgaM2Ar22oDEONgquwof+8hSj 4lIO8eOjb0yovI4EtOC0h79aOSSGsptRjAQGUQO4NeolLIyY5ZmVV+/mlKMQGL3c KW5VNWxOOC9ZV9rtwtjLn2TeZfS5a6kaeYzr3fB6SGhDQStQrMyWLisp+g/Tqafa SUoIxFInZL8tZ/d+YlELsd/aRniHcfKsiGYDESrzeXT3Bgwv4vw75PTFd89t58A= =WOXD -----END PGP SIGNATURE----- --nextPart1622072.FDWEii6vFl-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 07:49:00 2014 Return-Path: Delivered-To: freebsd-stable@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 48284700; Wed, 10 Sep 2014 07:49:00 +0000 (UTC) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) (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 E6B8D93A; Wed, 10 Sep 2014 07:48:59 +0000 (UTC) Received: from fwd25.aul.t-online.de (fwd25.aul.t-online.de [172.20.26.130]) by mailout03.t-online.de (Postfix) with SMTP id 150E24C22D3; Wed, 10 Sep 2014 09:48:51 +0200 (CEST) Received: from [192.168.119.33] (GEv2caZUZhI+C+mWtNt4nAOI30F3CN4awDVdkbirYOoEm4ucofZ4PN1kXQr2gK3QJn@[84.154.101.219]) by fwd25.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XRcdz-1BwEKm0; Wed, 10 Sep 2014 09:48:47 +0200 Message-ID: <54100258.2000505@freebsd.org> Date: Wed, 10 Sep 2014 09:48:40 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Aristedes Maniatis , freebsd-stable Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> In-Reply-To: <540FF3C4.6010305@ish.com.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: GEv2caZUZhI+C+mWtNt4nAOI30F3CN4awDVdkbirYOoEm4ucofZ4PN1kXQr2gK3QJn X-TOI-MSGID: c752d117-a266-4cd7-9208-0e74d53ce8b6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 07:49:00 -0000 Am 10.09.2014 um 08:46 schrieb Aristedes Maniatis: > As we all know, it is important to ensure that modern disks are set > up properly with the correct block size. Everything is good if all > the disks and the pool are "ashift=9" (512 byte blocks). But as soon > as one new drive requires 4k blocks, performance drops through the > floor of the enture pool. > > > In order to upgrade there appear to be two separate things that must > be done for a ZFS pool. > > 1. Create partitions on 4K boundaries. This is simple with the > "-a 4k" option in gpart, and it isn't hard to remove disks one at a > time from a pool, reformat them on the right boundaries and put them > back. Hopefully you've left a few spare bytes on the disk to ensure > that your partition doesn't get smaller when you reinsert it to the > pool. > > 2. Create a brand new pool which has ashift=12 and zfs send|receive > all the data over. > > > I guess I don't understand enough about zpool to know why the pool > itself has a block size, since I understood ZFS to have variable > stripe widths. I'm not a ZFS internals expert, just a long time user, but I'll try to answer your questions. ZFS is based on a copy-on-write paradigm, which ensures, that no data is ever overwritten in place. All writes go to new blank blocks, and only after the last reference to an "old" block is lost (when no TXG or snapshot has references to it), is the old block freed and put back on the free block map. ZFS uses variable block sizes by breaking down large blocks to smaller fragments as suitable for the data to be stored. The largest block to be used is configurable (128 KByte by default) and the smallest fragment is the sector size (i.e. 512 or 4096 bytes), as configured by "ashift". The problem with 4K sector disks that report 512 byte sectors is, that ZFS still assumes, that no data is overwritten in place, while the disk drive does it behind the curtains. ZFS thinks it can atomically write 512 bytes, but the drive reads 4K, places the 512 bytes of data within that 4K physical sector in the drive's cache, and then writes back the 4K of data in one go. The cost is not only the latency of this read-modify-write sequence, but also that an elementary ZFS assumption is violated: Data that is in other (logical) 512 byte sectors of the physical 4 KByte sector can be lost, if that write operation fails, resulting in loss of data in those files that happen to share the physical sector with the one that received the write operation. This may never hit you, but ZFS is built on the assumption, that it cannot happen at all, which is no longer true with 4KB drives that are used with ashift=9. > The problem with step 2 is that you need to have enough hard disks > spare to create a whole new pool and throw away the old disks. Plus > a disk controller with lots of spare ports. Plus the ability to take > the system offline for hours or days while the migration happens. > > One way to reduce this slightly is to create a new pool with reduced > redundancy. For example, create a RAIDZ2 with two fake disks, then > off-line those disks. Both methods are dangerous! Studies have found, that the risk of another disk failure during resilvering is substantial. That was the reason for higher RAIDZ redundancy groups (raidz2, raidz3). With 1) you have to copy the data multiple times and the load could lead to loss of one of the source drives (and since you are in the process of overwriting the drive that provided redundancy, you loose your pool that way). The copying to a degraded pool that you describe in 2) is a possibility (and I've done it, once). You should make sure, that all source data is still available until a successful resilvering of the "new" pool with the fake disks replaced. You could do this by moving the redundant disks from the old pool the new pool (i.e. degrading the old pool, after all data has been copied, to use the redundant drives to complete the new pool). But this assumes, that the technologies of the drives match - I'll soon go from 4*2TB to 3*4TB (raidz1 in both cases), since I had 2 of the 2TB drives fail over the course of last year (replaced under warranty). > So, given how much this problem sucks (it is extremely easy to add > a 4K disk by mistake as a replacement for a failed disk), and how > painful the workaround is... will ZFS ever gain the ability to change > block size for the pool? Or is this so deep in the internals of ZFS > it is as likely as being able to dynamically add disks to an existing > zvol in the "never going to happen" basket? You can add a 4 KB physical drive that emulates 512 byte sectors (nearly all drives do) to an ashift=9 ZFS pool, but performance will suffer and you'll be violating a ZFS assumption as explained above. > And secondly, is it also bad to have ashift 9 disks inside a ashift > 12 pool? That is, do we need to replace all our disks in one go and > forever keep big sticky labels on each disk so we never mix them? The ashift parameter is per pool, not per disk. You can have a drive with emulated 512 byte sectors in an ashift=9 pool, but you cannot change the ashift value of a pool after creation. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 11:03:11 2014 Return-Path: Delivered-To: freebsd-stable@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 B6B8E484 for ; Wed, 10 Sep 2014 11:03:11 +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 7765B1EF2 for ; Wed, 10 Sep 2014 11:03:11 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XRfg5-000C1H-4b for freebsd-stable@freebsd.org; Wed, 10 Sep 2014 13:03:09 +0200 Message-ID: <54102FE8.7060301@dumbbell.fr> Date: Wed, 10 Sep 2014 13:03:04 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Is it possible to get xf86-video-ati-7.2 added to the new_xorg pkg repository ? References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J5Joq2bof2QfikTKUrBpb5tx3VRpdo8wP" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 11:03:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J5Joq2bof2QfikTKUrBpb5tx3VRpdo8wP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02.08.2014 00:03, Pete French wrote: > After the help I got a few eeks ago I have been using this quite > happily with new_xorg, using the patch for ports I was sent and buildin= g > by hand. But it wold be nie to get it added to the new_xorg repository = so > that I could just use biary packages - preseumably this affects all ATI= > usrs trying to use that repository actually ? A fix for this bug for finally committed in the ports tree (r367808). Thank you for your patience :) --=20 Jean-S=E9bastien P=E9dron --J5Joq2bof2QfikTKUrBpb5tx3VRpdo8wP 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 iQJ8BAEBCgBmBQJUEC/sXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMO34P/AoWRjQpqwQ8u01kgsXbchZT 2vlVfXB+DEdjljom30KEE8ipL7GiaE7LEQ//8dTOEdBkckCSwHrt2G+hZWIEJWwZ Y6WVv1Oy7rm/7EoAfcjTnJGiACdCgg9ehY1lZ/BbzVnrSjsKArsMCoLw06PipT7u GLnZA7IvDiIGGkQVyMcqFeG0K2LUYHbjGE2fT7hyPLL3uVul0Y63+wKZkavS2y49 p7ISmqD1aYc2Ge8xv0B7CQIR0h0V1mtL2UKV92SJVEio6I+8c3MnY79DMJQn+lno aZNqv6Qh58ZkphH9V4opv3GX77dsxm5MBiTndnp1vm1v2Dy9NQPuzU31CjRNVr7N VhEUc/ZUjxuL2bOL0vsmya1OWXX02tpvWCb0fWQ/U2bU3gpmllxzv68UQDlnJNvn ZdmI43JKx/uX7QQkrNLtJsP640xsPrROf3+O1FSeXT0OlP5GK8LElVFo1JljLIhW /7f0ZiKiGPqDRA/9lBkVtIyq7ofRa6ARiU4Swo+glB6aWL4L5y/wQJAsWjtNGww8 GKhVAsgVtT24lQw9Bt7lE5NBZ5FCL9x/Jsc3WmgdTl+xZP2TQm4zgeYtPOpqGClC NIqhq/AjE1iYVBGVetk7CmFaE8XYDmYUh3iWlb+JR+D7238zrFW5ELxlzuzOtb1w 7RIvKwm6Ot9vi+YP/Ni0 =A1cR -----END PGP SIGNATURE----- --J5Joq2bof2QfikTKUrBpb5tx3VRpdo8wP-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 15:41:59 2014 Return-Path: Delivered-To: freebsd-stable@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 1607B4E8 for ; Wed, 10 Sep 2014 15:41:59 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C97FF14C2 for ; Wed, 10 Sep 2014 15:41:58 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8AFfs7D021753 for ; Wed, 10 Sep 2014 11:41:54 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <54107156.4080605@sentex.net> Date: Wed, 10 Sep 2014 11:42:14 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: cross build for RELENG8 on RELENG10 now fails Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 15:41:59 -0000 When I upgraded our cross build server to RELENG10 from 9, I lost the ability to build RELENG_8 images. Is there some magic that needs to be done in order to make this work on RELENG_10 ? it dies at ===> gnu/usr.bin/cvs/contrib (depend) ===> gnu/usr.bin/cvs/cvsbug (depend) ===> gnu/usr.bin/cvs/doc (depend) ===> gnu/usr.bin/dc (depend) rm -f .depend mkdep -f .depend -a -I/crossbuilds/src/8/gnu/usr.bin/dc/../bc -I/crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/h -DHAVE_CONFIG_H /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/array.c /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/dc.c /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/eval.c /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/misc.c /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/numeric.c /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/stack.c /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/string.c /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/lib/number.c echo dc: /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libc.a /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libm.a >> .depend ===> gnu/usr.bin/dc/doc (depend) ===> gnu/usr.bin/dialog (depend) rm -f .depend mkdep -f .depend -a /crossbuilds/src/8/gnu/usr.bin/dialog/dialog.c echo dialog: /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libc.a /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libdialog.a /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libncurses.a >> .depend ===> gnu/usr.bin/dialog/TESTS (depend) ===> gnu/usr.bin/diff (depend) patch -s -b .orig -o context.c < /crossbuilds/src/8/gnu/usr.bin/diff/context.c.diff /crossbuilds/src/8/gnu/usr.bin/diff/../../../contrib/diff/src/context.c I can't seem to find a patch in there anywhere. *** Error code 2 Stop in /crossbuilds/src/8/gnu/usr.bin/diff. *** Error code 1 Stop in /crossbuilds/src/8/gnu/usr.bin. *** Error code 1 Stop in /crossbuilds/src/8/gnu. *** Error code 1 Stop in /crossbuilds/src/8. *** Error code 1 Stop in /crossbuilds/src/8. *** Error code 1 Stop. make: stopped in /crossbuilds/src/8 Another error I noticed is that make -j1 fails right away if the obj directory does not exist. This used to work 0(backup3)# setenv MAKEOBJDIRPREFIX /crossbuilds/obj/8amd64 0(backup3)# rm -R /crossbuilds/obj/8amd64 0(backup3)# make -j1 buildworld A failure has been detected in another branch of the parallel make make[1]: stopped in /crossbuilds/src/8 *** [upgrade_checks] Error code 2 make: stopped in /crossbuilds/src/8 1 error make: stopped in /crossbuilds/src/8 2(backup3)# ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 15:58:59 2014 Return-Path: Delivered-To: freebsd-stable@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 DE0B997 for ; Wed, 10 Sep 2014 15:58:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6BE9170A for ; Wed, 10 Sep 2014 15:58:59 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 306EBB91C; Wed, 10 Sep 2014 11:58:58 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: cross build for RELENG8 on RELENG10 now fails Date: Wed, 10 Sep 2014 11:52:09 -0400 Message-ID: <5978109.GnR6la40iO@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <54107156.4080605@sentex.net> References: <54107156.4080605@sentex.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 10 Sep 2014 11:58:58 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 15:59:00 -0000 On Wednesday, September 10, 2014 11:42:14 AM Mike Tancsa wrote: > When I upgraded our cross build server to RELENG10 from 9, I lost the > ability to build RELENG_8 images. Is there some magic that needs to be > done in order to make this work on RELENG_10 ? I punted on building 8 on 10 when I ran into this (I know use bhyve vms running 8 to test MFCs to 8 since I can boot-test them as well as build-test them). I don't think there are any known workarounds. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 16:11:45 2014 Return-Path: Delivered-To: freebsd-stable@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 CF48EDCC for ; Wed, 10 Sep 2014 16:11:45 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::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 5D2C91925 for ; Wed, 10 Sep 2014 16:11:45 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s8AGBZOg012886; Wed, 10 Sep 2014 09:11:39 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201409101611.s8AGBZOg012886@gw.catspoiler.org> Date: Wed, 10 Sep 2014 09:11:35 -0700 (PDT) From: Don Lewis Subject: Re: cross build for RELENG8 on RELENG10 now fails To: mike@sentex.net In-Reply-To: <54107156.4080605@sentex.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 16:11:45 -0000 On 10 Sep, Mike Tancsa wrote: > When I upgraded our cross build server to RELENG10 from 9, I lost the > ability to build RELENG_8 images. Is there some magic that needs to be > done in order to make this work on RELENG_10 ? > > it dies at > > ===> gnu/usr.bin/cvs/contrib (depend) > ===> gnu/usr.bin/cvs/cvsbug (depend) > ===> gnu/usr.bin/cvs/doc (depend) > ===> gnu/usr.bin/dc (depend) > rm -f .depend > mkdep -f .depend -a -I/crossbuilds/src/8/gnu/usr.bin/dc/../bc > -I/crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/h > -DHAVE_CONFIG_H > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/array.c > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/dc.c > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/eval.c > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/misc.c > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/numeric.c > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/stack.c > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/string.c > /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/lib/number.c > echo dc: /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libc.a > /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libm.a >> .depend > ===> gnu/usr.bin/dc/doc (depend) > ===> gnu/usr.bin/dialog (depend) > rm -f .depend > mkdep -f .depend -a /crossbuilds/src/8/gnu/usr.bin/dialog/dialog.c > echo dialog: > /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libc.a > /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libdialog.a > /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libncurses.a >> > .depend > ===> gnu/usr.bin/dialog/TESTS (depend) > ===> gnu/usr.bin/diff (depend) > patch -s -b .orig -o context.c < > /crossbuilds/src/8/gnu/usr.bin/diff/context.c.diff > /crossbuilds/src/8/gnu/usr.bin/diff/../../../contrib/diff/src/context.c > I can't seem to find a patch in there anywhere. > *** Error code 2 I ran into this same problem. The BSD patch in 10 interprets the -b option differently than the GNU patch in 8 and 9. I worked around this by tweaking the Makefiles for diff, diff3, and sdiff to get rid of the -b .orig arguments to patch, since that should be the default anyway. I was cross building i386 on an amd64 host and ran into another problem with the cross version of lint (actually lint1) core dumping. So far I haven't been able to track down the cause of that. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 16:17:12 2014 Return-Path: Delivered-To: freebsd-stable@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 E01DA28D for ; Wed, 10 Sep 2014 16:17:12 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::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 6913519BA for ; Wed, 10 Sep 2014 16:17:12 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s8AGH310012895; Wed, 10 Sep 2014 09:17:07 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201409101617.s8AGH310012895@gw.catspoiler.org> Date: Wed, 10 Sep 2014 09:17:03 -0700 (PDT) From: Don Lewis Subject: Re: cross build for RELENG8 on RELENG10 now fails To: mike@sentex.net In-Reply-To: <201409101611.s8AGBZOg012886@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 16:17:13 -0000 On 10 Sep, To: mike@sentex.net wrote: > On 10 Sep, Mike Tancsa wrote: >> When I upgraded our cross build server to RELENG10 from 9, I lost the >> ability to build RELENG_8 images. Is there some magic that needs to be >> done in order to make this work on RELENG_10 ? >> >> it dies at >> >> ===> gnu/usr.bin/cvs/contrib (depend) >> ===> gnu/usr.bin/cvs/cvsbug (depend) >> ===> gnu/usr.bin/cvs/doc (depend) >> ===> gnu/usr.bin/dc (depend) >> rm -f .depend >> mkdep -f .depend -a -I/crossbuilds/src/8/gnu/usr.bin/dc/../bc >> -I/crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/h >> -DHAVE_CONFIG_H >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/array.c >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/dc.c >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/eval.c >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/misc.c >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/numeric.c >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/stack.c >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/dc/string.c >> /crossbuilds/src/8/gnu/usr.bin/dc/../../../contrib/bc/lib/number.c >> echo dc: /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libc.a >> /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libm.a >> .depend >> ===> gnu/usr.bin/dc/doc (depend) >> ===> gnu/usr.bin/dialog (depend) >> rm -f .depend >> mkdep -f .depend -a /crossbuilds/src/8/gnu/usr.bin/dialog/dialog.c >> echo dialog: >> /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libc.a >> /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libdialog.a >> /crossbuilds/obj/8amd64/crossbuilds/src/8/tmp/usr/lib/libncurses.a >> >> .depend >> ===> gnu/usr.bin/dialog/TESTS (depend) >> ===> gnu/usr.bin/diff (depend) >> patch -s -b .orig -o context.c < >> /crossbuilds/src/8/gnu/usr.bin/diff/context.c.diff >> /crossbuilds/src/8/gnu/usr.bin/diff/../../../contrib/diff/src/context.c >> I can't seem to find a patch in there anywhere. >> *** Error code 2 > > I ran into this same problem. The BSD patch in 10 interprets the -b > option differently than the GNU patch in 8 and 9. I worked around this > by tweaking the Makefiles for diff, diff3, and sdiff to get rid of the > -b .orig arguments to patch, since that should be the default anyway. > > I was cross building i386 on an amd64 host and ran into another problem > with the cross version of lint (actually lint1) core dumping. So far I > haven't been able to track down the cause of that. I also had to make lex a bootstrap too. My patches are in this message: From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 17:35:55 2014 Return-Path: Delivered-To: freebsd-stable@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 D5F4F3B9; Wed, 10 Sep 2014 17:35:55 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BAD431C; Wed, 10 Sep 2014 17:35:55 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8AHZpBk055447; Wed, 10 Sep 2014 13:35:51 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <54108C0A.9000107@sentex.net> Date: Wed, 10 Sep 2014 13:36:10 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Don Lewis Subject: Re: cross build for RELENG8 on RELENG10 now fails References: <201409101617.s8AGH310012895@gw.catspoiler.org> In-Reply-To: <201409101617.s8AGH310012895@gw.catspoiler.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 17:35:55 -0000 On 9/10/2014 12:17 PM, Don Lewis wrote: > > I also had to make lex a bootstrap too. My patches are in this > message: > Thanks Don and jhb. I think I will just fire up a bhyve instance on this box for the purpose of building RELENG_8 images then. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 18:31:06 2014 Return-Path: Delivered-To: freebsd-stable@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 667E6C80 for ; Wed, 10 Sep 2014 18:31:06 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1572BADE for ; Wed, 10 Sep 2014 18:31:05 +0000 (UTC) Received: from [10.219.131.39] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8AIRnfH066991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 10 Sep 2014 13:27:50 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <54109820.1030905@tundraware.com> Date: Wed, 10 Sep 2014 13:27:44 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: 10-STABLE Buildworld Failing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Wed, 10 Sep 2014 13:27:50 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8AIRnfH066991 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 18:31:06 -0000 As of some recent SVN pulls (date unsure), we are seeing the problem below. Any thoughts or help most welcome: cc -O2 -pipe -I/usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/include -I/usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion -I/usr/src /usr.bin/svn/svn/.. -I/usr/src/usr.bin/svn/svn/../lib/libapr -I/usr/src/usr.bin/svn/svn/../../../contrib/apr/include/arch/unix -I/usr/src/usr.bin/svn/svn/../../../ contrib/apr/include -I/usr/src/usr.bin/svn/svn/../lib/libapr_util -I/usr/src/usr.bin/svn/svn/../../../contrib/apr-util/include/private -I/usr/src/usr.bin/svn/svn/. ./../../contrib/apr-util/include -I. -DHAS_ORGANIZATION_NAME -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int - Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/util.c --- svnlite.1 --- sed -E 's,(^| |B|`)svn,\1svnlite,g' /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/svn.1 > /usr/obj/usr/src/usr.bin/svn/svn/svnlite.1 --- svnlite.1.gz --- gzip -cn svnlite.1 > svnlite.1.gz --- util.o --- /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/util.c:416:7: error: expected ')' ORGANIZATION_NAME ^ ./freebsd-organization.h:1:27: note: expanded from macro 'ORGANIZATION_NAME' #define ORGANIZATION_NAME TundraWare Inc. ^ /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/util.c:414:27: note: to match this '(' svn_stringbuf_appendcstr(default_msg, "Sponsored by:\t" ^ 1 error generated. *** [util.o] Error code 1 -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 18:38:39 2014 Return-Path: Delivered-To: freebsd-stable@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 D2B2BD2 for ; Wed, 10 Sep 2014 18:38:39 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::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 6DD05B64 for ; Wed, 10 Sep 2014 18:38:39 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id u57so5339493wes.36 for ; Wed, 10 Sep 2014 11:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IdNrC9KBFlYma/oANBJowtg9auB4JJyGnpe37QdXbL4=; b=cylHEOHxcrEO0QcbxfqmipI32QhOb3XbRyXlW4aQ94Unhn3uiYcabYey/iw4Zj7Qgl kKvUI9BeaFrvEOQ5Q/VF3aKC3lMQqivS39V99lLGUcyf65ic5kvJvzj/Mnei6wozu6ff xAHEZa+LiJgme1D8qF55osmgYQ2KFrdgS565M22xk1TFPUrSQeXBteTvE/B95VSgihE7 CRdvPgU3hn8w07BkHcSd1utajKfpIx99j+ebRRMz3bJsnJhzgQ8Dzh0CRrAjZMnoyRuQ oDNS3ZfnnPJ9nRLu0/lisOuletiM3aSbkryBj3FYveSwCk+mekKkMcykmA61VKNXJewL 4Axg== MIME-Version: 1.0 X-Received: by 10.194.71.11 with SMTP id q11mr50072206wju.33.1410374316857; Wed, 10 Sep 2014 11:38:36 -0700 (PDT) Received: by 10.217.2.18 with HTTP; Wed, 10 Sep 2014 11:38:36 -0700 (PDT) In-Reply-To: <54109820.1030905@tundraware.com> References: <54109820.1030905@tundraware.com> Date: Wed, 10 Sep 2014 14:38:36 -0400 Message-ID: Subject: Re: 10-STABLE Buildworld Failing From: Brandon Allbery To: Tim Daneliuk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 18:38:39 -0000 On Wed, Sep 10, 2014 at 2:27 PM, Tim Daneliuk wrote: > #define ORGANIZATION_NAME TundraWare Inc. > Aren't there some string quotes missing from around that string? Also, given your domain, I think that's locally introduced.... -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 18:46:37 2014 Return-Path: Delivered-To: freebsd-stable@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 D4DC33B1 for ; Wed, 10 Sep 2014 18:46:37 +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 A97CAC4C for ; Wed, 10 Sep 2014 18:46:37 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XRmua-0008g5-4n; Wed, 10 Sep 2014 18:46:36 +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 s8AIkYWZ026780; Wed, 10 Sep 2014 12:46:34 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19zzryl38wf2Ogc/w6g2/Eu X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: 10-STABLE Buildworld Failing From: Ian Lepore To: Tim Daneliuk In-Reply-To: <54109820.1030905@tundraware.com> References: <54109820.1030905@tundraware.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Sep 2014 12:46:33 -0600 Message-ID: <1410374793.1150.425.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 18:46:37 -0000 On Wed, 2014-09-10 at 13:27 -0500, Tim Daneliuk wrote: > As of some recent SVN pulls (date unsure), we are seeing the problem below. > Any thoughts or help most welcome: > > > cc -O2 -pipe > -I/usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/include > -I/usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion -I/usr/src > /usr.bin/svn/svn/.. -I/usr/src/usr.bin/svn/svn/../lib/libapr > -I/usr/src/usr.bin/svn/svn/../../../contrib/apr/include/arch/unix > -I/usr/src/usr.bin/svn/svn/../../../ > contrib/apr/include -I/usr/src/usr.bin/svn/svn/../lib/libapr_util > -I/usr/src/usr.bin/svn/svn/../../../contrib/apr-util/include/private > -I/usr/src/usr.bin/svn/svn/. > ./../../contrib/apr-util/include -I. -DHAS_ORGANIZATION_NAME -std=gnu99 > -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int - > Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch > -Wno-switch-enum > -Wno-knr-promoted-parameter -Wno-parentheses -c > /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/util.c > --- svnlite.1 --- > sed -E 's,(^| |B|`)svn,\1svnlite,g' > /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/svn.1 > > /usr/obj/usr/src/usr.bin/svn/svn/svnlite.1 > --- svnlite.1.gz --- > gzip -cn svnlite.1 > svnlite.1.gz > --- util.o --- > /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/util.c:416:7: error: > expected ')' > ORGANIZATION_NAME > ^ > ./freebsd-organization.h:1:27: note: expanded from macro 'ORGANIZATION_NAME' > #define ORGANIZATION_NAME TundraWare Inc. > ^ > /usr/src/usr.bin/svn/svn/../../../contrib/subversion/subversion/svn/util.c:414:27: > note: to match this '(' > svn_stringbuf_appendcstr(default_msg, "Sponsored by:\t" > ^ > 1 error generated. > *** [util.o] Error code 1 > > It looks like you've set ORGANIZATION=TundraWare Inc. in make.conf or the build environment. If you include quotes it should work fine. Depending on where you set it, you may need to escape them or use outer single quotes to protect a set of inner double quotes, like one of: ORGANIZATION=\"TundraWare Inc.\" ORGANIZATION='"TundraWare Inc."' -- Ian From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 18:47:16 2014 Return-Path: Delivered-To: freebsd-stable@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 9274E4D2 for ; Wed, 10 Sep 2014 18:47:16 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 552B2C65 for ; Wed, 10 Sep 2014 18:47:16 +0000 (UTC) Received: from [10.219.131.39] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8AIl6oK067450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 10 Sep 2014 13:47:07 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <54109CA5.7050807@tundraware.com> Date: Wed, 10 Sep 2014 13:47:01 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brandon Allbery Subject: Re: 10-STABLE Buildworld Failing References: <54109820.1030905@tundraware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Wed, 10 Sep 2014 13:47:07 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8AIl6oK067450 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 18:47:16 -0000 On 09/10/2014 01:38 PM, Brandon Allbery wrote: > On Wed, Sep 10, 2014 at 2:27 PM, Tim Daneliuk wrote: > >> #define ORGANIZATION_NAME TundraWare Inc. >> > > Aren't there some string quotes missing from around that string? Also, > given your domain, I think that's locally introduced.... > The error indicates that there is a missing paren in a function call. Also, this exact same configuration has compiled flawlessly for over a decade since FBSD 2.x Something new has been introduced. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 18:51:52 2014 Return-Path: Delivered-To: freebsd-stable@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 8BFF4640 for ; Wed, 10 Sep 2014 18:51:52 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 1BDBBD1F for ; Wed, 10 Sep 2014 18:51:51 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hi2so6843722wib.4 for ; Wed, 10 Sep 2014 11:51:50 -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=354N/xf5o3uxEsCDso1qSz3raVIz+N8IsIm3IgbdVcU=; b=sAOXIk0kxRj7Ev9pRUW2AMAcNMpK4Jm01HGTHcp9fXR+z+qQRkmcf1dtg16WQgEZ5P Io4gHS24mUs9P22riTUdbS/BVK3+d4Wrw0qJADmqgLbziHzh54tbKmy0M80QMSZfutMv CpR+EmZmf3EpKCA61V+uhyB9XoMWZQ4kDMfS4ksRTgY1xWLuE1RREXlZ/B9gm2irFE2D 7g8E6gL7XfO6eMjrfcb2Q3UZXsiYzAgLQIduJcnMb5tq0KPdyh+wxl7EHrwxGZIQrWvP 44JtBJi6AeOYKq+hfyDJ2KFN/WSHRTj6+WwBFUmKxFUrRVLN6VB9qLN6K+0idGYChGUV ugIg== MIME-Version: 1.0 X-Received: by 10.194.71.11 with SMTP id q11mr50137776wju.33.1410375110197; Wed, 10 Sep 2014 11:51:50 -0700 (PDT) Received: by 10.217.2.18 with HTTP; Wed, 10 Sep 2014 11:51:50 -0700 (PDT) In-Reply-To: <54109CA5.7050807@tundraware.com> References: <54109820.1030905@tundraware.com> <54109CA5.7050807@tundraware.com> Date: Wed, 10 Sep 2014 14:51:50 -0400 Message-ID: Subject: Re: 10-STABLE Buildworld Failing From: Brandon Allbery To: Tim Daneliuk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 18:51:52 -0000 On Wed, Sep 10, 2014 at 2:47 PM, Tim Daneliuk wrote: > 0On 09/10/2014 01:38 PM, Brandon Allbery wrote: > >> On Wed, Sep 10, 2014 at 2:27 PM, Tim Daneliuk >> wrote: >> >> #define ORGANIZATION_NAME TundraWare Inc. >>> >>> >> Aren't there some string quotes missing from around that string? Also, >> given your domain, I think that's locally introduced.... >> >> > The error indicates that there is a missing paren in a function call. > Yes, because when it expands that non-string in a context requiring a string, it's getting something that is a syntax error, and its attempt to recover makes it think that you missed a closing ). But what really happened is it got: svn_stringbuf_appendcstr(default_msg, "Sponsored by:\t" TundraWare Inc. ) and that is not valid C. It's expecting a C string literal, not plain text. > Also, this exact same configuration has compiled flawlessly for over > a decade since FBSD 2.x Something new has been introduced. Likely that it's actually using your syntax error now instead of it just sitting in a file unreferenced. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 19:26:41 2014 Return-Path: Delivered-To: freebsd-stable@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 EECB85A8 for ; Wed, 10 Sep 2014 19:26:40 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 BBB8DE2 for ; Wed, 10 Sep 2014 19:26:40 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBP00JXRA01GZ20@st11p09mm-asmtp001.mac.com> for freebsd-stable@freebsd.org; Wed, 10 Sep 2014 19:26:29 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-10_04:2014-09-09,2014-09-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=52 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409100160 Subject: Re: ZFS on root booting broken somewhere after r270020 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Content-type: text/plain; charset=utf-8 From: Kimmo Paasiala X-Priority: 3 In-reply-to: Date: Wed, 10 Sep 2014 22:26:24 +0300 Content-transfer-encoding: quoted-printable Message-id: <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1973.6) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:26:41 -0000 > On 9.9.2014, at 19.03, Kimmo Paasiala wrote: >=20 >=20 >> On 9.9.2014, at 18.53, Steven Hartland = wrote: >>=20 >> ----- Original Message ----- From: "Kimmo Paasiala" = >>> Hi it=E2=80=99s me again. Something that was committed in stable/10 = after r271213 up to >>> and including r271288 broke ZFS on Root booting in exactly the same = way again. >>> I know the problem is no longer related to extra kernel modules = loaded in >>> /boot/loader.conf because I=E2=80=99m loading only the required = zfs.ko and opensolaris.ko >>> modules. Also, the new vt(4) console that I=E2=80=99m using is not = the culprit because the >>> same thing happens with kern.vty set to =E2=80=9Csc=E2=80=9D. >>=20 >> I've just updated my stable/10 box to r271316 and no problems booting = from a ZFS root. >>=20 >> So first things first what error are you seeing? >>=20 >> Next what is you're: >> * Hardware >> * Pool layout >>=20 >> Regards >> Steve=20 >=20 > The error is the same as before: >=20 > =E2=80=A2 Mounting from zfs:rdnzltank/ROOT/default failed with = error 5. >=20 > Followed by the mountroot prompt and I get only these devices to = choose from, no sign of the ZFS pool: >=20 > =E2=80=A2 mountroot> > =E2=80=A2 List of GEOM managed disk devices: > =E2=80=A2 gpt/fb10disk1 gpt/fb10swap1 = diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 = diskid/DISK-S13UJDWS301624p1 ada0p3 ada0p2 ada0p1 = diskid/DISK-S13UJDWS301624 ada0 >=20 > Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: >=20 > http://www.gigabyte.com/products/product-page.aspx?pid=3D3343#ov >=20 > 4GBs of RAM. One 750GB Samsung HD753LJ 3.5=E2=80=9D SATA HD on the = Intel SATA controller. >=20 > Pool layout: >=20 > pool: rdnzltank > state: ONLINE > scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 09:27:48 = 2014 > config: >=20 > NAME STATE READ WRITE CKSUM > rdnzltank ONLINE 0 0 0 > gpt/fb10disk1 ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > Output of =E2=80=98gpart show=E2=80=99: >=20 > freebsd10 ~ % gpart show =20 > =3D> 34 1465146988 ada0 GPT (699G) > 34 2014 - free - (1.0M) > 2048 1024 1 freebsd-boot (512K) > 3072 1024 - free - (512K) > 4096 16777216 2 freebsd-swap (8.0G) > 16781312 1448365710 3 freebsd-zfs (691G) >=20 >=20 > HTH, >=20 > -Kimmo More information. This version still works: FreeBSD freebsd10.rdnzl.info 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 = r271237: Wed Sep 10 11:00:15 EEST 2014 = root@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 The next higher version r271238 breaks booting for me. The commit in = question is this one: = http://svnweb.freebsd.org/base?view=3Drevision&sortby=3Drev&sortdir=3Ddown= &revision=3D271238 -Kimmo From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 22:36:56 2014 Return-Path: Delivered-To: freebsd-stable@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 EB14F565 for ; Wed, 10 Sep 2014 22:36:55 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 83E667A2 for ; Wed, 10 Sep 2014 22:36:55 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 033DA20E7088D; Wed, 10 Sep 2014 22:36:53 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 583B020E7088B; Wed, 10 Sep 2014 22:36:51 +0000 (UTC) Message-ID: <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> From: "Steven Hartland" To: "Kimmo Paasiala" References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> Subject: Re: ZFS on root booting broken somewhere after r270020 Date: Wed, 10 Sep 2014 23:36:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 22:36:56 -0000 ----- Original Message ----- From: "Kimmo Paasiala" To: "Steven Hartland" Cc: Sent: Wednesday, September 10, 2014 8:26 PM Subject: Re: ZFS on root booting broken somewhere after r270020 > >> On 9.9.2014, at 19.03, Kimmo Paasiala wrote: >> >> >>> On 9.9.2014, at 18.53, Steven Hartland wrote: >>> >>> ----- Original Message ----- From: "Kimmo Paasiala" >>>> Hi it’s me again. Something that was committed in stable/10 after r271213 up to >>>> and including r271288 broke ZFS on Root booting in exactly the same way again. >>>> I know the problem is no longer related to extra kernel modules loaded in >>>> /boot/loader.conf because I’m loading only the required zfs.ko and opensolaris.ko >>>> modules. Also, the new vt(4) console that I’m using is not the culprit because the >>>> same thing happens with kern.vty set to “sc”. >>> >>> I've just updated my stable/10 box to r271316 and no problems booting from a ZFS root. >>> >>> So first things first what error are you seeing? >>> >>> Next what is you're: >>> * Hardware >>> * Pool layout >>> >>> Regards >>> Steve >> >> The error is the same as before: >> >> • Mounting from zfs:rdnzltank/ROOT/default failed with error 5. >> >> Followed by the mountroot prompt and I get only these devices to choose from, no sign of the ZFS pool: >> >> • mountroot> >> • List of GEOM managed disk devices: >> • gpt/fb10disk1 gpt/fb10swap1 diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 diskid/DISK-S13UJDWS301624p1 ada0p3 >> ada0p2 ada0p1 diskid/DISK-S13UJDWS301624 ada0 >> >> Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: >> >> http://www.gigabyte.com/products/product-page.aspx?pid=3343#ov >> >> 4GBs of RAM. One 750GB Samsung HD753LJ 3.5” SATA HD on the Intel SATA controller. >> >> Pool layout: >> >> pool: rdnzltank >> state: ONLINE >> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 09:27:48 2014 >> config: >> >> NAME STATE READ WRITE CKSUM >> rdnzltank ONLINE 0 0 0 >> gpt/fb10disk1 ONLINE 0 0 0 >> >> errors: No known data errors >> >> Output of ‘gpart show’: >> >> freebsd10 ~ % gpart show >> => 34 1465146988 ada0 GPT (699G) >> 34 2014 - free - (1.0M) >> 2048 1024 1 freebsd-boot (512K) >> 3072 1024 - free - (512K) >> 4096 16777216 2 freebsd-swap (8.0G) >> 16781312 1448365710 3 freebsd-zfs (691G) >> >> >> HTH, >> >> -Kimmo > > > More information. This version still works: > > FreeBSD freebsd10.rdnzl.info 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271237: Wed Sep 10 11:00:15 EEST 2014 > root@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 > > The next higher version r271238 breaks booting for me. The commit in question is this one: > > http://svnweb.freebsd.org/base?view=revision&sortby=rev&sortdir=down&revision=271238 Investigating, had no reports of issues while this has been in head. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 22:46:59 2014 Return-Path: Delivered-To: freebsd-stable@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 B2674857 for ; Wed, 10 Sep 2014 22:46:59 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 78603882 for ; Wed, 10 Sep 2014 22:46:59 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8AMklTE062732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 10 Sep 2014 17:46:47 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <5410D4D7.8060906@tundraware.com> Date: Wed, 10 Sep 2014 17:46:47 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: 10-STABLE Buildworld Failing References: <54109820.1030905@tundraware.com> <54109CA5.7050807@tundraware.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Wed, 10 Sep 2014 17:46:47 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8AMklTE062732 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 22:46:59 -0000 On 09/10/2014 01:51 PM, Brandon Allbery wrote: >> Also, this exact same configuration has compiled flawlessly for over >> >a decade since FBSD 2.x Something new has been introduced. > > Likely that it's actually using your syntax error now instead of it just > sitting in a file unreferenced. Well something has definitely changed of late. Not only do I now have to cleanup the env variable with proper quoting, building kernels now fails with -j8 with a complaint about another branch of the parallel make failing. Dropping it to -j4 seems to fix it but ... still a bit strange. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 23:30:17 2014 Return-Path: Delivered-To: freebsd-stable@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 C7828E0D; Wed, 10 Sep 2014 23:30:17 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id A4B9EBC3; Wed, 10 Sep 2014 23:30:17 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 10 Sep 2014 16:34:13 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s8ANU96g059476; Wed, 10 Sep 2014 16:30:09 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s8ANU9a6059475; Wed, 10 Sep 2014 16:30:09 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 10 Sep 2014 16:30:09 -0700 From: Doug Ambrisko To: John Baldwin Subject: Re: cross build for RELENG8 on RELENG10 now fails Message-ID: <20140910233009.GA56050@ambrisko.com> References: <54107156.4080605@sentex.net> <5978109.GnR6la40iO@ralph.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5978109.GnR6la40iO@ralph.baldwin.cx> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:30:17 -0000 On Wed, Sep 10, 2014 at 11:52:09AM -0400, John Baldwin wrote: | On Wednesday, September 10, 2014 11:42:14 AM Mike Tancsa wrote: | > When I upgraded our cross build server to RELENG10 from 9, I lost the | > ability to build RELENG_8 images. Is there some magic that needs to be | > done in order to make this work on RELENG_10 ? | | I punted on building 8 on 10 when I ran into this (I know use bhyve vms | running 8 to test MFCs to 8 since I can boot-test them as well as build-test | them). I don't think there are any known workarounds. We've been building older releases via chroot and setting environment variables. I have some local hacks to set the uname etc info. in a jail via sysctl in the jail. Doug A. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 23:41:14 2014 Return-Path: Delivered-To: freebsd-stable@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 B82A0FF1 for ; Wed, 10 Sep 2014 23:41:14 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 69C60D1B for ; Wed, 10 Sep 2014 23:41:13 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id CD0C120E7088D; Wed, 10 Sep 2014 23:41:11 +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,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 E37F420E7088B; Wed, 10 Sep 2014 23:41:09 +0000 (UTC) Message-ID: <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , "Kimmo Paasiala" References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> Subject: Re: ZFS on root booting broken somewhere after r270020 Date: Thu, 11 Sep 2014 00:41:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit 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-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:41:14 -0000 ----- Original Message ----- From: "Steven Hartland" To: "Kimmo Paasiala" Cc: Sent: Wednesday, September 10, 2014 11:36 PM Subject: Re: ZFS on root booting broken somewhere after r270020 > > ----- Original Message ----- > From: "Kimmo Paasiala" > To: "Steven Hartland" > Cc: > Sent: Wednesday, September 10, 2014 8:26 PM > Subject: Re: ZFS on root booting broken somewhere after r270020 > > >> >>> On 9.9.2014, at 19.03, Kimmo Paasiala wrote: >>> >>> >>>> On 9.9.2014, at 18.53, Steven Hartland wrote: >>>> >>>> ----- Original Message ----- From: "Kimmo Paasiala" >>>>> Hi it’s me again. Something that was committed in stable/10 after r271213 up to >>>>> and including r271288 broke ZFS on Root booting in exactly the same way again. >>>>> I know the problem is no longer related to extra kernel modules loaded in >>>>> /boot/loader.conf because I’m loading only the required zfs.ko and opensolaris.ko >>>>> modules. Also, the new vt(4) console that I’m using is not the culprit because the >>>>> same thing happens with kern.vty set to “sc”. >>>> >>>> I've just updated my stable/10 box to r271316 and no problems booting from a ZFS root. >>>> >>>> So first things first what error are you seeing? >>>> >>>> Next what is you're: >>>> * Hardware >>>> * Pool layout >>>> >>>> Regards >>>> Steve >>> >>> The error is the same as before: >>> >>> • Mounting from zfs:rdnzltank/ROOT/default failed with error 5. >>> >>> Followed by the mountroot prompt and I get only these devices to choose from, no sign of the ZFS pool: >>> >>> • mountroot> >>> • List of GEOM managed disk devices: >>> • gpt/fb10disk1 gpt/fb10swap1 diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 diskid/DISK-S13UJDWS301624p1 ada0p3 >>> ada0p2 ada0p1 diskid/DISK-S13UJDWS301624 ada0 >>> >>> Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: >>> >>> http://www.gigabyte.com/products/product-page.aspx?pid=3343#ov >>> >>> 4GBs of RAM. One 750GB Samsung HD753LJ 3.5” SATA HD on the Intel SATA controller. >>> >>> Pool layout: >>> >>> pool: rdnzltank >>> state: ONLINE >>> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 09:27:48 2014 >>> config: >>> >>> NAME STATE READ WRITE CKSUM >>> rdnzltank ONLINE 0 0 0 >>> gpt/fb10disk1 ONLINE 0 0 0 >>> >>> errors: No known data errors >>> >>> Output of ‘gpart show’: >>> >>> freebsd10 ~ % gpart show >>> => 34 1465146988 ada0 GPT (699G) >>> 34 2014 - free - (1.0M) >>> 2048 1024 1 freebsd-boot (512K) >>> 3072 1024 - free - (512K) >>> 4096 16777216 2 freebsd-swap (8.0G) >>> 16781312 1448365710 3 freebsd-zfs (691G) >>> >>> >>> HTH, >>> >>> -Kimmo >> >> >> More information. This version still works: >> >> FreeBSD freebsd10.rdnzl.info 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271237: Wed Sep 10 11:00:15 EEST 2014 >> root@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >> >> The next higher version r271238 breaks booting for me. The commit in question is this one: >> >> http://svnweb.freebsd.org/base?view=revision&sortby=rev&sortdir=down&revision=271238 > > Investigating, had no reports of issues while this has been in head. I've just installed a stable/10 kernel, specifically: 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #11 r271316M and booted fine from a mirrored root without issue: config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 gpart show ada0 ada2 => 34 250069613 ada0 GPT (119G) 34 128 1 freebsd-boot (64K) 162 8388608 2 freebsd-swap (4.0G) 8388770 241680877 3 freebsd-zfs (115G) => 40 586072288 ada2 GPT (279G) 40 128 1 freebsd-boot (64K) 168 8388608 2 freebsd-swap (4.0G) 8388776 577683552 3 freebsd-zfs (275G) I then detached the second disk so the machine had just: config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 Rebooted and again all fine no issues I've also got a raidz1 box on the same kernel it too is fine. => 34 500118125 ada0 GPT (238G) 34 128 1 freebsd-boot (64K) 162 500117997 2 freebsd-zfs (238G) ... So its seems like there's something odd about your environment, especially given you've had a similar issue before. So the questions: 1. What does zpool get all report? 2. What does /boot/loader.conf have in it? 3. What does zdb -C rdnzltank report? 4. What does /etc/rc.conf have in it? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Wed Sep 10 23:44:21 2014 Return-Path: Delivered-To: freebsd-stable@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 E64BC198; Wed, 10 Sep 2014 23:44:20 +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 C3D9AD43; Wed, 10 Sep 2014 23:44:20 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 1C124676; Wed, 10 Sep 2014 16:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1410392654; bh=TJJGXrxhvN79kk1XLpyxr7u33uMwa+/YzTy0L3EjKQ4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=TobK72BU8suFxj3M14ercvBgS8fkBiWeAtsygBJBaBNyi91M+WaAJGEoC4wWgqCzf 5DMPO1ttItbufM7L2K01FLBc5u2Gln8cdQ+5MDfryU69jfPtLWkg8KMhOLw+Kno4pB IVrZObmLwi5D0gqJ8jxw8zod+5Hth6b38AFkYv6s= From: Peter Wemm To: freebsd-stable@freebsd.org Subject: Re: cross build for RELENG8 on RELENG10 now fails Date: Wed, 10 Sep 2014 16:44:08 -0700 Message-ID: <9468585.hm97Wx3h1R@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140910233009.GA56050@ambrisko.com> References: <54107156.4080605@sentex.net> <5978109.GnR6la40iO@ralph.baldwin.cx> <20140910233009.GA56050@ambrisko.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4238276.VlYqiCrO8P"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:44:21 -0000 --nextPart4238276.VlYqiCrO8P Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Wednesday, September 10, 2014 04:30:09 PM Doug Ambrisko wrote: > On Wed, Sep 10, 2014 at 11:52:09AM -0400, John Baldwin wrote: > | On Wednesday, September 10, 2014 11:42:14 AM Mike Tancsa wrote: > | > When I upgraded our cross build server to RELENG10 from 9, I lost= the > | > ability to build RELENG_8 images. Is there some magic that needs= to be > | > done in order to make this work on RELENG_10 ? > |=20 > | I punted on building 8 on 10 when I ran into this (I know use bhyve= vms > | running 8 to test MFCs to 8 since I can boot-test them as well as > | build-test them). I don't think there are any known workarounds. >=20 > We've been building older releases via chroot and setting environment= > variables. I have some local hacks to set the uname etc info. in > a jail via sysctl in the jail. This is the only "officially" supported cross-branch mode we supported,= aside=20 from=20the N -> N+1 path. It's how we build everything at work, and how we build in the freebsd.o= rg=20 cluster. It's way faster than a VM and generally no hassle. For the freebsd.org cluster: fetch 8.4-REL base.* -> build stage 1 -> svn checkout -> buildworld fro= m 8.4- REL to 8-stable -> installworld in a clean chroot -> roll tarballs. fetch 9.3-REL base.txz -> build stage 1 -> svn checkout -> buildworld f= rom=20 9.3-REL to 9-stable -> installworld in a clean chroot -> roll tarballs.= .. and so on. For 11.x we use a ftp.freebsd.org/snapshots build. At work, we go much, much further. We even build 4-stable, 6-stable an= d 7- stable on 11.x hosts this way. (Why? we modify libc.so.4 to run bette= r on=20 10.x/11.x and copy it from the 4.x build environment into the compat ar= ea on=20 later releases during the build process) But we *never* cross build from head. Too many moving targets, harder = to=20 reproduce a specific build, etc. We used to have this written down somewhere. The supported upgrade pat= h used=20 to be explicitly documented as N.0 -> N-stable-> N+1.0, ie: 5-stable -> 6.0 -> 6-stable -> 7.0 -> 7-stable -> 8.0 -> 8-stable etc, = and=20 never in reverse. =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 --nextPart4238276.VlYqiCrO8P 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 iQEcBAABAgAGBQJUEOJNAAoJEDXWlwnsgJ4EKnkH/2UwdWBFE7OjTQB3V3YXkLGH hUB1qinoLm4z5vQwnuL17SlKA0kP1S84lTgSJ5VxcdN8Z/bioxD0WVRLy3wZ5r7X Sq8oaIDX487BX5Da5zN0MMNPc4IGpK82LxPxdWuUEJ4t2pU2oYh4/42D2Y0FZDMN lMA/9aMfA+YPF4N3CIFo9fleUEFttshB7jSfuNO2D/vAFP1KhyGDNmotuHaZ+t1G vOF2WTUPwVesUiNRqXZV5KcBGi4ObVjkju41hpVQ8L8D63WhZz1ZKwv9Ub0z5sSP CKcc52BMyqZVl1/X4B1sGkR41Eck7K1xm1hULrVqw+vQAC8BrBYrUCTEiZxPvQQ= =OOYS -----END PGP SIGNATURE----- --nextPart4238276.VlYqiCrO8P-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 00:04:31 2014 Return-Path: Delivered-To: freebsd-stable@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 915D146E for ; Thu, 11 Sep 2014 00:04:31 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 5C06EEB8 for ; Thu, 11 Sep 2014 00:04:30 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBP00FCXMV4RT00@st11p09mm-asmtp001.mac.com> for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 00:04:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-10_04:2014-09-09,2014-09-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=52 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409110000 Subject: Re: ZFS on root booting broken somewhere after r270020 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Content-type: text/plain; charset=utf-8 From: Kimmo Paasiala X-Priority: 3 In-reply-to: <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> Date: Thu, 11 Sep 2014 03:04:15 +0300 Content-transfer-encoding: quoted-printable Message-id: References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1973.6) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:04:31 -0000 > On 11.9.2014, at 2.41, Steven Hartland = wrote: >=20 >=20 > ----- Original Message ----- From: "Steven Hartland" = > To: "Kimmo Paasiala" > Cc: > Sent: Wednesday, September 10, 2014 11:36 PM > Subject: Re: ZFS on root booting broken somewhere after r270020 >=20 >=20 >>=20 >> ----- Original Message ----- From: "Kimmo Paasiala" = >> To: "Steven Hartland" >> Cc: >> Sent: Wednesday, September 10, 2014 8:26 PM >> Subject: Re: ZFS on root booting broken somewhere after r270020 >>=20 >>=20 >>>=20 >>>> On 9.9.2014, at 19.03, Kimmo Paasiala wrote: >>>>=20 >>>>=20 >>>>> On 9.9.2014, at 18.53, Steven Hartland = wrote: >>>>>=20 >>>>> ----- Original Message ----- From: "Kimmo Paasiala" = >>>>>> Hi it=E2=80=99s me again. Something that was committed in = stable/10 after r271213 up to >>>>>> and including r271288 broke ZFS on Root booting in exactly the = same way again. >>>>>> I know the problem is no longer related to extra kernel modules = loaded in >>>>>> /boot/loader.conf because I=E2=80=99m loading only the required = zfs.ko and opensolaris.ko >>>>>> modules. Also, the new vt(4) console that I=E2=80=99m using is = not the culprit because the >>>>>> same thing happens with kern.vty set to =E2=80=9Csc=E2=80=9D. >>>>>=20 >>>>> I've just updated my stable/10 box to r271316 and no problems = booting from a ZFS root. >>>>>=20 >>>>> So first things first what error are you seeing? >>>>>=20 >>>>> Next what is you're: >>>>> * Hardware >>>>> * Pool layout >>>>>=20 >>>>> Regards >>>>> Steve >>>>=20 >>>> The error is the same as before: >>>>=20 >>>> =E2=80=A2 Mounting from zfs:rdnzltank/ROOT/default failed with = error 5. >>>>=20 >>>> Followed by the mountroot prompt and I get only these devices to = choose from, no sign of the ZFS pool: >>>>=20 >>>> =E2=80=A2 mountroot> >>>> =E2=80=A2 List of GEOM managed disk devices: >>>> =E2=80=A2 gpt/fb10disk1 gpt/fb10swap1 = diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 = diskid/DISK-S13UJDWS301624p1 ada0p3 ada0p2 ada0p1 = diskid/DISK-S13UJDWS301624 ada0 >>>>=20 >>>> Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: >>>>=20 >>>> http://www.gigabyte.com/products/product-page.aspx?pid=3D3343#ov >>>>=20 >>>> 4GBs of RAM. One 750GB Samsung HD753LJ 3.5=E2=80=9D SATA HD on the = Intel SATA controller. >>>>=20 >>>> Pool layout: >>>>=20 >>>> pool: rdnzltank >>>> state: ONLINE >>>> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 09:27:48 = 2014 >>>> config: >>>>=20 >>>> NAME STATE READ WRITE CKSUM >>>> rdnzltank ONLINE 0 0 0 >>>> gpt/fb10disk1 ONLINE 0 0 0 >>>>=20 >>>> errors: No known data errors >>>>=20 >>>> Output of =E2=80=98gpart show=E2=80=99: >>>>=20 >>>> freebsd10 ~ % gpart show >>>> =3D> 34 1465146988 ada0 GPT (699G) >>>> 34 2014 - free - (1.0M) >>>> 2048 1024 1 freebsd-boot (512K) >>>> 3072 1024 - free - (512K) >>>> 4096 16777216 2 freebsd-swap (8.0G) >>>> 16781312 1448365710 3 freebsd-zfs (691G) >>>>=20 >>>>=20 >>>> HTH, >>>>=20 >>>> -Kimmo >>>=20 >>>=20 >>> More information. This version still works: >>>=20 >>> FreeBSD freebsd10.rdnzl.info 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE = #0 r271237: Wed Sep 10 11:00:15 EEST 2014 = root@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >>>=20 >>> The next higher version r271238 breaks booting for me. The commit in = question is this one: >>>=20 >>> = http://svnweb.freebsd.org/base?view=3Drevision&sortby=3Drev&sortdir=3Ddown= &revision=3D271238 >>=20 >> Investigating, had no reports of issues while this has been in head. >=20 > I've just installed a stable/10 kernel, specifically: > 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #11 r271316M >=20 > and booted fine from a mirrored root without issue: > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > ada0p3 ONLINE 0 0 0 > ada2p3 ONLINE 0 0 0 >=20 > gpart show ada0 ada2 > =3D> 34 250069613 ada0 GPT (119G) > 34 128 1 freebsd-boot (64K) > 162 8388608 2 freebsd-swap (4.0G) > 8388770 241680877 3 freebsd-zfs (115G) >=20 > =3D> 40 586072288 ada2 GPT (279G) > 40 128 1 freebsd-boot (64K) > 168 8388608 2 freebsd-swap (4.0G) > 8388776 577683552 3 freebsd-zfs (275G) >=20 > I then detached the second disk so the machine had just: > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > ada0p3 ONLINE 0 0 0 >=20 > Rebooted and again all fine no issues >=20 > I've also got a raidz1 box on the same kernel it too is fine. >=20 > =3D> 34 500118125 ada0 GPT (238G) > 34 128 1 freebsd-boot (64K) > 162 500117997 2 freebsd-zfs (238G) > ... >=20 > So its seems like there's something odd about your environment, = especially > given you've had a similar issue before. >=20 > So the questions: > 1. What does zpool get all report? > 2. What does /boot/loader.conf have in it? > 3. What does zdb -C rdnzltank report? > 4. What does /etc/rc.conf have in it? >=20 > Regards > Steve=20 Here goes: freebsd10 ~ % zpool get all rdnzltank=20 NAME PROPERTY VALUE = SOURCE rdnzltank size 688G = - rdnzltank capacity 9% = - rdnzltank altroot - = default rdnzltank health ONLINE = - rdnzltank guid 5382786142589818227 = default rdnzltank version - = default rdnzltank bootfs rdnzltank/ROOT/default = local rdnzltank delegation on = default rdnzltank autoreplace off = default rdnzltank cachefile - = default rdnzltank failmode wait = default rdnzltank listsnapshots off = default rdnzltank autoexpand off = default rdnzltank dedupditto 0 = default rdnzltank dedupratio 1.00x = - rdnzltank free 622G = - rdnzltank allocated 66.2G = - rdnzltank readonly off = - rdnzltank comment - = default rdnzltank expandsize 0 = - rdnzltank freeing 0 = default rdnzltank fragmentation 20% = - rdnzltank leaked 0 = default rdnzltank feature@async_destroy enabled = local rdnzltank feature@empty_bpobj active = local rdnzltank feature@lz4_compress active = local rdnzltank feature@multi_vdev_crash_dump enabled = local rdnzltank feature@spacemap_histogram active = local rdnzltank feature@enabled_txg active = local rdnzltank feature@hole_birth active = local rdnzltank feature@extensible_dataset enabled = local rdnzltank feature@embedded_data active = local rdnzltank feature@bookmarks enabled = local rdnzltank feature@filesystem_limits enabled = local freebsd10 ~ % cat /boot/loader.conf =20 kern.geom.label.gptid.enable=3D0 hw.usb.no_pf=3D1 kern.cam.ada.legacy_aliases=3D0 zfs_load=3D"YES" vfs.zfs.prefetch_disable=3D0 kern.vty=3Dvt I have already tried without the gptid and legacy_aliases options, no = difference. The prefetch_disable was at the default setting 1 when the = problem appeared. The hw.usb.no_pf setting shouldn=E2=80=99t have an = effect but I can test it once I can reboot the machine again. I=E2=80=99m = attaching a second disk at the moment to make a mirror of the pool. The = kern.vty setting didn=E2=80=99t make a difference. The next is now with the second disk being resilvered, gpt/fb10disk2 is = the new disk: MOS Configuration: version: 5000 name: 'rdnzltank' state: 0 txg: 1634460 pool_guid: 5382786142589818227 hostid: 852094392 hostname: 'freebsd10.rdnzl.info' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 5382786142589818227 children[0]: type: 'mirror' id: 0 guid: 6268049119730836293 whole_disk: 0 metaslab_array: 34 metaslab_shift: 32 ashift: 9 asize: 741558452224 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 1732695434302750511 path: '/dev/gpt/fb10disk1' phys_path: '/dev/gpt/fb10disk1' whole_disk: 1 DTL: 98 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 15812067837864729710 path: '/dev/gpt/fb10disk2' phys_path: '/dev/gpt/fb10disk2' whole_disk: 1 DTL: 526 create_txg: 4 resilver_txg: 1634424 features_for_read: com.delphix:hole_birth com.delphix:embedded_data I don=E2=80=99t think have anything in /etc/rc.conf that would have an = effect at the time when kernel tries to mount the root filesystem but = here it is: hostname=3D"freebsd10.rdnzl.info" keymap=3D"fi.kbd" #cloned_interfaces=3D"lo1" #ifconfig_vtnet0=3D"SYNCDHCP" ifconfig_re0=3D"inet 10.71.14.12/24" #ifconfig_re0_alias0=3D"inet 10.71.14.112/24" defaultrouter=3D"10.71.14.1" #gateway_enable=3D"YES" ipv6_activate_all_interfaces=3D"YES" #ifconfig_vtnet0_ipv6=3D"accept_rtadv" ifconfig_re0_ipv6=3D"inet6 2001:14b8:100:ZZZZ::XXXX/64" ipv6_defaultrouter=3D"2001:14b8:100:ZZZZ::1"=20 #ipv6_gateway_enable=3D"YES" #pf_enable=3D"YES" #pflog_enable=3D"YES" #pflog_flags=3D"-d 10 -s 256" zfs_enable=3D"YES" #devfs_load_rulesets=3DYES sshd_enable=3D"YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev=3D"AUTO" clear_tmp_enable=3D"YES" sendmail_enable=3D"NO" sendmail_submit_enable=3D"NO" sendmail_outbound_enable=3D"NO" sendmail_msp_queue_enable=3D"NO" rpcbind_enable=3D"YES" nfs_server_enable=3D"YES" mountd_enable=3D"YES" #nfsv4_server_enable=3D"YES" #nfsuserd_enable=3D"YES" #mountd_flags=3D"-r" ntpd_enable=3D"YES" ntpd_sync_on_start=3D"YES" jail_enable=3D"YES" jail_list=3D"buildstable10amd64 buildreleng100i386" #ntpdate_enable=3D"YES" #ntpdate_hosts=3D"10.71.14.1" nginx_enable=3D"YES" #mdnsresponderposix_enable=3D"YES" mdnsresponderposix_flags=3D"-f /usr/local/etc/mDNSResponder.conf" #openntpd_enable=3D"YES" #avahi_daemon_enable=3D"YES" #dbus_enable=3D"YES" mdnsd_enable=3D"YES" smartd_enable=3D"YES" dma_flushq_enable=3D=E2=80=9CYES=E2=80=9D -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 00:51:58 2014 Return-Path: Delivered-To: freebsd-stable@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 B0E22A29 for ; Thu, 11 Sep 2014 00:51:58 +0000 (UTC) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 439A5314 for ; Thu, 11 Sep 2014 00:51:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAD3wEFQ7p/kP/2dsb2JhbABgg2DSbgGBJ3iEBAEFMgFFDwILDgoJFg8JAwIBAgEJPAYBDAgBAYg9v2cEhXiJWIRMBZV5iGKKSYkRgWcegW6DKQEBAQ Received: from eth4368.nsw.adsl.internode.on.net (HELO fish.ish.com.au) ([59.167.249.15]) by ipmail04.adl6.internode.on.net with ESMTP; 11 Sep 2014 10:15:42 +0930 Received: from ip-136.ish.com.au ([203.29.62.136]:56286) by fish.ish.com.au with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1XRsW3-0000Zv-0Y; Thu, 11 Sep 2014 10:45:39 +1000 Message-ID: <5410F0B4.9040808@ish.com.au> Date: Thu, 11 Sep 2014 10:45:40 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Stefan Esser , freebsd-stable Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> In-Reply-To: <54100258.2000505@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:51:58 -0000 Thanks Stefan and Peter for the highly informative posts. On 10/09/2014 5:48pm, Stefan Esser wrote: > ZFS uses variable block sizes by breaking down large blocks to smaller > fragments as suitable for the data to be stored. The largest block to > be used is configurable (128 KByte by default) and the smallest fragment > is the sector size (i.e. 512 or 4096 bytes), as configured by "ashift". So this means that the ZFS developers would need to effectively (re)fragment the entire pool if they wanted to develop a way to increase the ashift size. This sounds like something that isn't going to be solved in the near future (less than three years) if it is a similar technical problem to inserting another disk into an existing vdev. And that means that as it becomes harder to buy older 512 byte disks, everyone with a ZFS pool is going to be stuck with managing quite a lot of downtime as they upgrade. And even more pain if they boot off that pool. On 10/09/2014 4:51pm, Peter Wemm wrote: > For what its worth, in the freebsd.org cluster we automatically align > everything to a minimum of 4k, no matter what the actual drive is. > > We set: sysctl vfs.zfs.min_auto_ashift=12 > (this saves a lot of messing around with gnop etc) > > and ensure all the gpt slices are 4k or better aligned. Should the FreeBSD project change this minimum in the next release? There seems to be no downside and a huge amount of pain for people who stumble along with the defaults not knowing what a mess they are creating to solve later. Cheers Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 00:52:19 2014 Return-Path: Delivered-To: freebsd-stable@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 290C0B12 for ; Thu, 11 Sep 2014 00:52:19 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9405931D for ; Thu, 11 Sep 2014 00:52:18 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 3097E20E7088E; Thu, 11 Sep 2014 00:52: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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 3BAF620E7088B; Thu, 11 Sep 2014 00:52:13 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Kimmo Paasiala" References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> Subject: Re: ZFS on root booting broken somewhere after r270020 Date: Thu, 11 Sep 2014 01:52:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:52:19 -0000 ----- Original Message ----- From: "Kimmo Paasiala" To: "Steven Hartland" Cc: Sent: Thursday, September 11, 2014 1:04 AM Subject: Re: ZFS on root booting broken somewhere after r270020 > On 11.9.2014, at 2.41, Steven Hartland wrote: > > > ----- Original Message ----- From: "Steven Hartland" > To: "Kimmo Paasiala" > Cc: > Sent: Wednesday, September 10, 2014 11:36 PM > Subject: Re: ZFS on root booting broken somewhere after r270020 > > >> >> ----- Original Message ----- From: "Kimmo Paasiala" >> To: "Steven Hartland" >> Cc: >> Sent: Wednesday, September 10, 2014 8:26 PM >> Subject: Re: ZFS on root booting broken somewhere after r270020 >> >> >>> >>>> On 9.9.2014, at 19.03, Kimmo Paasiala wrote: >>>> >>>> >>>>> On 9.9.2014, at 18.53, Steven Hartland wrote: >>>>> >>>>> ----- Original Message ----- From: "Kimmo Paasiala" >>>>>> Hi it’s me again. Something that was committed in stable/10 after r271213 up to >>>>>> and including r271288 broke ZFS on Root booting in exactly the same way again. >>>>>> I know the problem is no longer related to extra kernel modules loaded in >>>>>> /boot/loader.conf because I’m loading only the required zfs.ko and opensolaris.ko >>>>>> modules. Also, the new vt(4) console that I’m using is not the culprit because the >>>>>> same thing happens with kern.vty set to “sc”. >>>>> >>>>> I've just updated my stable/10 box to r271316 and no problems booting from a ZFS root. >>>>> >>>>> So first things first what error are you seeing? >>>>> >>>>> Next what is you're: >>>>> * Hardware >>>>> * Pool layout >>>>> >>>>> Regards >>>>> Steve >>>> >>>> The error is the same as before: >>>> >>>> • Mounting from zfs:rdnzltank/ROOT/default failed with error 5. >>>> >>>> Followed by the mountroot prompt and I get only these devices to choose from, no sign of the ZFS pool: >>>> >>>> • mountroot> >>>> • List of GEOM managed disk devices: >>>> • gpt/fb10disk1 gpt/fb10swap1 diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 diskid/DISK-S13UJDWS301624p1 ada0p3 >>>> ada0p2 ada0p1 diskid/DISK-S13UJDWS301624 ada0 >>>> >>>> Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: >>>> >>>> http://www.gigabyte.com/products/product-page.aspx?pid=3343#ov >>>> >>>> 4GBs of RAM. One 750GB Samsung HD753LJ 3.5” SATA HD on the Intel SATA controller. >>>> >>>> Pool layout: >>>> >>>> pool: rdnzltank >>>> state: ONLINE >>>> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 09:27:48 2014 >>>> config: >>>> >>>> NAME STATE READ WRITE CKSUM >>>> rdnzltank ONLINE 0 0 0 >>>> gpt/fb10disk1 ONLINE 0 0 0 >>>> >>>> errors: No known data errors >>>> >>>> Output of ‘gpart show’: >>>> >>>> freebsd10 ~ % gpart show >>>> => 34 1465146988 ada0 GPT (699G) >>>> 34 2014 - free - (1.0M) >>>> 2048 1024 1 freebsd-boot (512K) >>>> 3072 1024 - free - (512K) >>>> 4096 16777216 2 freebsd-swap (8.0G) >>>> 16781312 1448365710 3 freebsd-zfs (691G) >>>> >>>> >>>> HTH, >>>> >>>> -Kimmo >>> >>> >>> More information. This version still works: >>> >>> FreeBSD freebsd10.rdnzl.info 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271237: Wed Sep 10 11:00:15 EEST 2014 >>> root@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> The next higher version r271238 breaks booting for me. The commit in question is this one: >>> >>> http://svnweb.freebsd.org/base?view=revision&sortby=rev&sortdir=down&revision=271238 >> >> Investigating, had no reports of issues while this has been in head. > > I've just installed a stable/10 kernel, specifically: > 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #11 r271316M > > and booted fine from a mirrored root without issue: > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > ada0p3 ONLINE 0 0 0 > ada2p3 ONLINE 0 0 0 > > gpart show ada0 ada2 > => 34 250069613 ada0 GPT (119G) > 34 128 1 freebsd-boot (64K) > 162 8388608 2 freebsd-swap (4.0G) > 8388770 241680877 3 freebsd-zfs (115G) > > => 40 586072288 ada2 GPT (279G) > 40 128 1 freebsd-boot (64K) > 168 8388608 2 freebsd-swap (4.0G) > 8388776 577683552 3 freebsd-zfs (275G) > > I then detached the second disk so the machine had just: > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > ada0p3 ONLINE 0 0 0 > > Rebooted and again all fine no issues > > I've also got a raidz1 box on the same kernel it too is fine. > > => 34 500118125 ada0 GPT (238G) > 34 128 1 freebsd-boot (64K) > 162 500117997 2 freebsd-zfs (238G) > ... > > So its seems like there's something odd about your environment, especially > given you've had a similar issue before. > > So the questions: > 1. What does zpool get all report? > 2. What does /boot/loader.conf have in it? > 3. What does zdb -C rdnzltank report? > 4. What does /etc/rc.conf have in it? > > Regards > Steve Here goes: snip... The next is now with the second disk being resilvered, gpt/fb10disk2 is the new disk: MOS Configuration: version: 5000 name: 'rdnzltank' state: 0 txg: 1634460 pool_guid: 5382786142589818227 hostid: 852094392 hostname: 'freebsd10.rdnzl.info' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 5382786142589818227 children[0]: type: 'mirror' id: 0 guid: 6268049119730836293 whole_disk: 0 metaslab_array: 34 metaslab_shift: 32 ashift: 9 asize: 741558452224 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 1732695434302750511 path: '/dev/gpt/fb10disk1' phys_path: '/dev/gpt/fb10disk1' whole_disk: 1 DTL: 98 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 15812067837864729710 path: '/dev/gpt/fb10disk2' phys_path: '/dev/gpt/fb10disk2' whole_disk: 1 DTL: 526 create_txg: 4 resilver_txg: 1634424 features_for_read: com.delphix:hole_birth com.delphix:embedded_data Ok this could show your problem ^^ In a previous post your said >>>> pool: rdnzltank >>>> state: ONLINE >>>> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 09:27:48 2014 >>>> config: >>>> >>>> NAME STATE READ WRITE CKSUM >>>> rdnzltank ONLINE 0 0 0 >>>> gpt/fb10disk1 ONLINE 0 0 0 But zdb thinks your pool is a mirror which I believe indicates that your pool's real config is out of sync with the cache file. Now this shouldn't cause an issue as it should just try all devices in order until it succeeds but there may be an issue there somewhere. Could you:- 1. backup your cache file cp /boot/zfs/zpool.cache /boot/zfs/zpool.cache.old 2. regenerate your cache file zpool set cachefile=/boot/zfs/zpool.cache tank 3. rerun the zdb command and let us know the output zdb -C rdnzltank I'm hoping that it should show: ... vdev_tree: type: 'root' id: 0 guid: 5382786142589818227 children[0]: type: 'disk' .. 4. If it does show type 'disk' try rebooting with the new kernel. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 00:55:30 2014 Return-Path: Delivered-To: freebsd-stable@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 15D12C34 for ; Thu, 11 Sep 2014 00:55:30 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 D2AB4349 for ; Thu, 11 Sep 2014 00:55:29 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBP00H1YP8DVL30@st11p09mm-asmtp001.mac.com> for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 00:55:28 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-10_04:2014-09-09,2014-09-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=52 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409110002 Subject: Re: ZFS on root booting broken somewhere after r270020 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Content-type: text/plain; charset=utf-8 From: Kimmo Paasiala X-Priority: 3 In-reply-to: Date: Thu, 11 Sep 2014 03:55:23 +0300 Content-transfer-encoding: quoted-printable Message-id: References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1973.6) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:55:30 -0000 > On 11.9.2014, at 3.52, Steven Hartland = wrote: >=20 >=20 > ----- Original Message ----- From: "Kimmo Paasiala" = > To: "Steven Hartland" > Cc: > Sent: Thursday, September 11, 2014 1:04 AM > Subject: Re: ZFS on root booting broken somewhere after r270020 >=20 >=20 >=20 >> On 11.9.2014, at 2.41, Steven Hartland = wrote: >>=20 >>=20 >> ----- Original Message ----- From: "Steven Hartland" = >> To: "Kimmo Paasiala" >> Cc: >> Sent: Wednesday, September 10, 2014 11:36 PM >> Subject: Re: ZFS on root booting broken somewhere after r270020 >>=20 >>=20 >>>=20 >>> ----- Original Message ----- From: "Kimmo Paasiala" = >>> To: "Steven Hartland" >>> Cc: >>> Sent: Wednesday, September 10, 2014 8:26 PM >>> Subject: Re: ZFS on root booting broken somewhere after r270020 >>>=20 >>>=20 >>>>=20 >>>>> On 9.9.2014, at 19.03, Kimmo Paasiala wrote: >>>>>=20 >>>>>=20 >>>>>> On 9.9.2014, at 18.53, Steven Hartland = wrote: >>>>>>=20 >>>>>> ----- Original Message ----- From: "Kimmo Paasiala" = >>>>>>> Hi it=E2=80=99s me again. Something that was committed in = stable/10 after r271213 up to >>>>>>> and including r271288 broke ZFS on Root booting in exactly the = same way again. >>>>>>> I know the problem is no longer related to extra kernel modules = loaded in >>>>>>> /boot/loader.conf because I=E2=80=99m loading only the required = zfs.ko and opensolaris.ko >>>>>>> modules. Also, the new vt(4) console that I=E2=80=99m using is = not the culprit because the >>>>>>> same thing happens with kern.vty set to =E2=80=9Csc=E2=80=9D. >>>>>>=20 >>>>>> I've just updated my stable/10 box to r271316 and no problems = booting from a ZFS root. >>>>>>=20 >>>>>> So first things first what error are you seeing? >>>>>>=20 >>>>>> Next what is you're: >>>>>> * Hardware >>>>>> * Pool layout >>>>>>=20 >>>>>> Regards >>>>>> Steve >>>>>=20 >>>>> The error is the same as before: >>>>>=20 >>>>> =E2=80=A2 Mounting from zfs:rdnzltank/ROOT/default failed with = error 5. >>>>>=20 >>>>> Followed by the mountroot prompt and I get only these devices to = choose from, no sign of the ZFS pool: >>>>>=20 >>>>> =E2=80=A2 mountroot> >>>>> =E2=80=A2 List of GEOM managed disk devices: >>>>> =E2=80=A2 gpt/fb10disk1 gpt/fb10swap1 = diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 = diskid/DISK-S13UJDWS301624p1 ada0p3 ada0p2 ada0p1 = diskid/DISK-S13UJDWS301624 ada0 >>>>>=20 >>>>> Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: >>>>>=20 >>>>> http://www.gigabyte.com/products/product-page.aspx?pid=3D3343#ov >>>>>=20 >>>>> 4GBs of RAM. One 750GB Samsung HD753LJ 3.5=E2=80=9D SATA HD on the = Intel SATA controller. >>>>>=20 >>>>> Pool layout: >>>>>=20 >>>>> pool: rdnzltank >>>>> state: ONLINE >>>>> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 = 09:27:48 2014 >>>>> config: >>>>>=20 >>>>> NAME STATE READ WRITE CKSUM >>>>> rdnzltank ONLINE 0 0 0 >>>>> gpt/fb10disk1 ONLINE 0 0 0 >>>>>=20 >>>>> errors: No known data errors >>>>>=20 >>>>> Output of =E2=80=98gpart show=E2=80=99: >>>>>=20 >>>>> freebsd10 ~ % gpart show >>>>> =3D> 34 1465146988 ada0 GPT (699G) >>>>> 34 2014 - free - (1.0M) >>>>> 2048 1024 1 freebsd-boot (512K) >>>>> 3072 1024 - free - (512K) >>>>> 4096 16777216 2 freebsd-swap (8.0G) >>>>> 16781312 1448365710 3 freebsd-zfs (691G) >>>>>=20 >>>>>=20 >>>>> HTH, >>>>>=20 >>>>> -Kimmo >>>>=20 >>>>=20 >>>> More information. This version still works: >>>>=20 >>>> FreeBSD freebsd10.rdnzl.info 10.1-PRERELEASE FreeBSD = 10.1-PRERELEASE #0 r271237: Wed Sep 10 11:00:15 EEST 2014 = root@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >>>>=20 >>>> The next higher version r271238 breaks booting for me. The commit = in question is this one: >>>>=20 >>>> = http://svnweb.freebsd.org/base?view=3Drevision&sortby=3Drev&sortdir=3Ddown= &revision=3D271238 >>>=20 >>> Investigating, had no reports of issues while this has been in head. >>=20 >> I've just installed a stable/10 kernel, specifically: >> 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #11 r271316M >>=20 >> and booted fine from a mirrored root without issue: >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> ada0p3 ONLINE 0 0 0 >> ada2p3 ONLINE 0 0 0 >>=20 >> gpart show ada0 ada2 >> =3D> 34 250069613 ada0 GPT (119G) >> 34 128 1 freebsd-boot (64K) >> 162 8388608 2 freebsd-swap (4.0G) >> 8388770 241680877 3 freebsd-zfs (115G) >>=20 >> =3D> 40 586072288 ada2 GPT (279G) >> 40 128 1 freebsd-boot (64K) >> 168 8388608 2 freebsd-swap (4.0G) >> 8388776 577683552 3 freebsd-zfs (275G) >>=20 >> I then detached the second disk so the machine had just: >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> ada0p3 ONLINE 0 0 0 >>=20 >> Rebooted and again all fine no issues >>=20 >> I've also got a raidz1 box on the same kernel it too is fine. >>=20 >> =3D> 34 500118125 ada0 GPT (238G) >> 34 128 1 freebsd-boot (64K) >> 162 500117997 2 freebsd-zfs (238G) >> ... >>=20 >> So its seems like there's something odd about your environment, = especially >> given you've had a similar issue before. >>=20 >> So the questions: >> 1. What does zpool get all report? >> 2. What does /boot/loader.conf have in it? >> 3. What does zdb -C rdnzltank report? >> 4. What does /etc/rc.conf have in it? >>=20 >> Regards >> Steve >=20 > Here goes: > snip... >=20 > The next is now with the second disk being resilvered, gpt/fb10disk2 = is the new disk: >=20 > MOS Configuration: > version: 5000 > name: 'rdnzltank' > state: 0 > txg: 1634460 > pool_guid: 5382786142589818227 > hostid: 852094392 > hostname: 'freebsd10.rdnzl.info' > vdev_children: 1 > vdev_tree: > type: 'root' > id: 0 > guid: 5382786142589818227 > children[0]: > type: 'mirror' > id: 0 > guid: 6268049119730836293 > whole_disk: 0 > metaslab_array: 34 > metaslab_shift: 32 > ashift: 9 > asize: 741558452224 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 1732695434302750511 > path: '/dev/gpt/fb10disk1' > phys_path: '/dev/gpt/fb10disk1' > whole_disk: 1 > DTL: 98 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 15812067837864729710 > path: '/dev/gpt/fb10disk2' > phys_path: '/dev/gpt/fb10disk2' > whole_disk: 1 > DTL: 526 > create_txg: 4 > resilver_txg: 1634424 > features_for_read: > com.delphix:hole_birth > com.delphix:embedded_data >=20 > Ok this could show your problem ^^ >=20 > In a previous post your said >>>>> pool: rdnzltank >>>>> state: ONLINE >>>>> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 = 09:27:48 2014 >>>>> config: >>>>>=20 >>>>> NAME STATE READ WRITE CKSUM >>>>> rdnzltank ONLINE 0 0 0 >>>>> gpt/fb10disk1 ONLINE 0 0 0 >=20 > But zdb thinks your pool is a mirror which I believe indicates that = your pool's real > config is out of sync with the cache file. >=20 > Now this shouldn't cause an issue as it should just try all devices in = order until it > succeeds but there may be an issue there somewhere. >=20 > Could you:- > 1. backup your cache file > cp /boot/zfs/zpool.cache /boot/zfs/zpool.cache.old > 2. regenerate your cache file > zpool set cachefile=3D/boot/zfs/zpool.cache tank > 3. rerun the zdb command and let us know the output > zdb -C rdnzltank > I'm hoping that it should show: > ... > vdev_tree: > type: 'root' > id: 0 > guid: 5382786142589818227 > children[0]: > type: 'disk' > .. > 4. If it does show type 'disk' try rebooting with the new kernel. >=20 > Regards > Steve=20 Yes, as I said I=E2=80=99m right now trying to see if the pool would = work as a mirror with the newer kernel that somehow broke booting for = me. I=E2=80=99m in the middle of a resilver that keeps restarting for = some odd reason every 15 minutes=E2=80=A6 -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 01:18:50 2014 Return-Path: Delivered-To: freebsd-stable@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 E8DACFE0 for ; Thu, 11 Sep 2014 01:18:50 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 B25696DF for ; Thu, 11 Sep 2014 01:18:50 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBP00NV0NJ21H40@st11p09mm-asmtp002.mac.com> for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 00:18:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-10_04:2014-09-09,2014-09-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=52 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409110002 Subject: Re: ZFS on root booting broken somewhere after r270020 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Content-type: text/plain; charset=utf-8 From: Kimmo Paasiala X-Priority: 3 In-reply-to: Date: Thu, 11 Sep 2014 03:18:37 +0300 Content-transfer-encoding: quoted-printable Message-id: References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1973.6) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 01:18:51 -0000 > On 11.9.2014, at 3.04, Kimmo Paasiala wrote: >=20 >=20 >> On 11.9.2014, at 2.41, Steven Hartland = wrote: >>=20 >>=20 >> ----- Original Message ----- From: "Steven Hartland" = >> To: "Kimmo Paasiala" >> Cc: >> Sent: Wednesday, September 10, 2014 11:36 PM >> Subject: Re: ZFS on root booting broken somewhere after r270020 >>=20 >>=20 >>>=20 >>> ----- Original Message ----- From: "Kimmo Paasiala" = >>> To: "Steven Hartland" >>> Cc: >>> Sent: Wednesday, September 10, 2014 8:26 PM >>> Subject: Re: ZFS on root booting broken somewhere after r270020 >>>=20 >>>=20 >>>>=20 >>>>> On 9.9.2014, at 19.03, Kimmo Paasiala wrote: >>>>>=20 >>>>>=20 >>>>>> On 9.9.2014, at 18.53, Steven Hartland = wrote: >>>>>>=20 >>>>>> ----- Original Message ----- From: "Kimmo Paasiala" = >>>>>>> Hi it=E2=80=99s me again. Something that was committed in = stable/10 after r271213 up to >>>>>>> and including r271288 broke ZFS on Root booting in exactly the = same way again. >>>>>>> I know the problem is no longer related to extra kernel modules = loaded in >>>>>>> /boot/loader.conf because I=E2=80=99m loading only the required = zfs.ko and opensolaris.ko >>>>>>> modules. Also, the new vt(4) console that I=E2=80=99m using is = not the culprit because the >>>>>>> same thing happens with kern.vty set to =E2=80=9Csc=E2=80=9D. >>>>>>=20 >>>>>> I've just updated my stable/10 box to r271316 and no problems = booting from a ZFS root. >>>>>>=20 >>>>>> So first things first what error are you seeing? >>>>>>=20 >>>>>> Next what is you're: >>>>>> * Hardware >>>>>> * Pool layout >>>>>>=20 >>>>>> Regards >>>>>> Steve >>>>>=20 >>>>> The error is the same as before: >>>>>=20 >>>>> =E2=80=A2 Mounting from zfs:rdnzltank/ROOT/default failed with = error 5. >>>>>=20 >>>>> Followed by the mountroot prompt and I get only these devices to = choose from, no sign of the ZFS pool: >>>>>=20 >>>>> =E2=80=A2 mountroot> >>>>> =E2=80=A2 List of GEOM managed disk devices: >>>>> =E2=80=A2 gpt/fb10disk1 gpt/fb10swap1 = diskid/DISK-S13UJDWS301624p3 diskid/DISK-S13UJDWS301624p2 = diskid/DISK-S13UJDWS301624p1 ada0p3 ada0p2 ada0p1 = diskid/DISK-S13UJDWS301624 ada0 >>>>>=20 >>>>> Hardware is a Gigabyte GA-D510UD Mini-ITX motherboard: >>>>>=20 >>>>> http://www.gigabyte.com/products/product-page.aspx?pid=3D3343#ov >>>>>=20 >>>>> 4GBs of RAM. One 750GB Samsung HD753LJ 3.5=E2=80=9D SATA HD on the = Intel SATA controller. >>>>>=20 >>>>> Pool layout: >>>>>=20 >>>>> pool: rdnzltank >>>>> state: ONLINE >>>>> scan: scrub repaired 0 in 1h7m with 0 errors on Wed Aug 20 = 09:27:48 2014 >>>>> config: >>>>>=20 >>>>> NAME STATE READ WRITE CKSUM >>>>> rdnzltank ONLINE 0 0 0 >>>>> gpt/fb10disk1 ONLINE 0 0 0 >>>>>=20 >>>>> errors: No known data errors >>>>>=20 >>>>> Output of =E2=80=98gpart show=E2=80=99: >>>>>=20 >>>>> freebsd10 ~ % gpart show >>>>> =3D> 34 1465146988 ada0 GPT (699G) >>>>> 34 2014 - free - (1.0M) >>>>> 2048 1024 1 freebsd-boot (512K) >>>>> 3072 1024 - free - (512K) >>>>> 4096 16777216 2 freebsd-swap (8.0G) >>>>> 16781312 1448365710 3 freebsd-zfs (691G) >>>>>=20 >>>>>=20 >>>>> HTH, >>>>>=20 >>>>> -Kimmo >>>>=20 >>>>=20 >>>> More information. This version still works: >>>>=20 >>>> FreeBSD freebsd10.rdnzl.info 10.1-PRERELEASE FreeBSD = 10.1-PRERELEASE #0 r271237: Wed Sep 10 11:00:15 EEST 2014 = root@buildstable10amd64.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >>>>=20 >>>> The next higher version r271238 breaks booting for me. The commit = in question is this one: >>>>=20 >>>> = http://svnweb.freebsd.org/base?view=3Drevision&sortby=3Drev&sortdir=3Ddown= &revision=3D271238 >>>=20 >>> Investigating, had no reports of issues while this has been in head. >>=20 >> I've just installed a stable/10 kernel, specifically: >> 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #11 r271316M >>=20 >> and booted fine from a mirrored root without issue: >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> ada0p3 ONLINE 0 0 0 >> ada2p3 ONLINE 0 0 0 >>=20 >> gpart show ada0 ada2 >> =3D> 34 250069613 ada0 GPT (119G) >> 34 128 1 freebsd-boot (64K) >> 162 8388608 2 freebsd-swap (4.0G) >> 8388770 241680877 3 freebsd-zfs (115G) >>=20 >> =3D> 40 586072288 ada2 GPT (279G) >> 40 128 1 freebsd-boot (64K) >> 168 8388608 2 freebsd-swap (4.0G) >> 8388776 577683552 3 freebsd-zfs (275G) >>=20 >> I then detached the second disk so the machine had just: >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> ada0p3 ONLINE 0 0 0 >>=20 >> Rebooted and again all fine no issues >>=20 >> I've also got a raidz1 box on the same kernel it too is fine. >>=20 >> =3D> 34 500118125 ada0 GPT (238G) >> 34 128 1 freebsd-boot (64K) >> 162 500117997 2 freebsd-zfs (238G) >> ... >>=20 >> So its seems like there's something odd about your environment, = especially >> given you've had a similar issue before. >>=20 >> So the questions: >> 1. What does zpool get all report? >> 2. What does /boot/loader.conf have in it? >> 3. What does zdb -C rdnzltank report? >> 4. What does /etc/rc.conf have in it? >>=20 >> Regards >> Steve=20 >=20 > Here goes: >=20 > freebsd10 ~ % zpool get all rdnzltank=20 > NAME PROPERTY VALUE = SOURCE > rdnzltank size 688G = - > rdnzltank capacity 9% = - > rdnzltank altroot - = default > rdnzltank health ONLINE = - > rdnzltank guid 5382786142589818227 = default > rdnzltank version - = default > rdnzltank bootfs rdnzltank/ROOT/default = local > rdnzltank delegation on = default > rdnzltank autoreplace off = default > rdnzltank cachefile - = default > rdnzltank failmode wait = default > rdnzltank listsnapshots off = default > rdnzltank autoexpand off = default > rdnzltank dedupditto 0 = default > rdnzltank dedupratio 1.00x = - > rdnzltank free 622G = - > rdnzltank allocated 66.2G = - > rdnzltank readonly off = - > rdnzltank comment - = default > rdnzltank expandsize 0 = - > rdnzltank freeing 0 = default > rdnzltank fragmentation 20% = - > rdnzltank leaked 0 = default > rdnzltank feature@async_destroy enabled = local > rdnzltank feature@empty_bpobj active = local > rdnzltank feature@lz4_compress active = local > rdnzltank feature@multi_vdev_crash_dump enabled = local > rdnzltank feature@spacemap_histogram active = local > rdnzltank feature@enabled_txg active = local > rdnzltank feature@hole_birth active = local > rdnzltank feature@extensible_dataset enabled = local > rdnzltank feature@embedded_data active = local > rdnzltank feature@bookmarks enabled = local > rdnzltank feature@filesystem_limits enabled = local >=20 > freebsd10 ~ % cat /boot/loader.conf =20 >=20 > kern.geom.label.gptid.enable=3D0 > hw.usb.no_pf=3D1 > kern.cam.ada.legacy_aliases=3D0 > zfs_load=3D"YES" > vfs.zfs.prefetch_disable=3D0 > kern.vty=3Dvt >=20 > I have already tried without the gptid and legacy_aliases options, no = difference. The prefetch_disable was at the default setting 1 when the = problem appeared. The hw.usb.no_pf setting shouldn=E2=80=99t have an = effect but I can test it once I can reboot the machine again. I=E2=80=99m = attaching a second disk at the moment to make a mirror of the pool. The = kern.vty setting didn=E2=80=99t make a difference. >=20 > The next is now with the second disk being resilvered, gpt/fb10disk2 = is the new disk: >=20 > MOS Configuration: > version: 5000 > name: 'rdnzltank' > state: 0 > txg: 1634460 > pool_guid: 5382786142589818227 > hostid: 852094392 > hostname: 'freebsd10.rdnzl.info' > vdev_children: 1 > vdev_tree: > type: 'root' > id: 0 > guid: 5382786142589818227 > children[0]: > type: 'mirror' > id: 0 > guid: 6268049119730836293 > whole_disk: 0 > metaslab_array: 34 > metaslab_shift: 32 > ashift: 9 > asize: 741558452224 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 1732695434302750511 > path: '/dev/gpt/fb10disk1' > phys_path: '/dev/gpt/fb10disk1' > whole_disk: 1 > DTL: 98 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 15812067837864729710 > path: '/dev/gpt/fb10disk2' > phys_path: '/dev/gpt/fb10disk2' > whole_disk: 1 > DTL: 526 > create_txg: 4 > resilver_txg: 1634424 > features_for_read: > com.delphix:hole_birth > com.delphix:embedded_data >=20 > I don=E2=80=99t think have anything in /etc/rc.conf that would have an = effect at the time when kernel tries to mount the root filesystem but = here it is: >=20 > hostname=3D"freebsd10.rdnzl.info" > keymap=3D"fi.kbd" >=20 > #cloned_interfaces=3D"lo1" > #ifconfig_vtnet0=3D"SYNCDHCP" > ifconfig_re0=3D"inet 10.71.14.12/24" > #ifconfig_re0_alias0=3D"inet 10.71.14.112/24" > defaultrouter=3D"10.71.14.1" > #gateway_enable=3D"YES" >=20 > ipv6_activate_all_interfaces=3D"YES" > #ifconfig_vtnet0_ipv6=3D"accept_rtadv" > ifconfig_re0_ipv6=3D"inet6 2001:14b8:100:ZZZZ::XXXX/64" > ipv6_defaultrouter=3D"2001:14b8:100:ZZZZ::1"=20 > #ipv6_gateway_enable=3D"YES" >=20 > #pf_enable=3D"YES" > #pflog_enable=3D"YES" > #pflog_flags=3D"-d 10 -s 256" >=20 > zfs_enable=3D"YES" >=20 > #devfs_load_rulesets=3DYES >=20 > sshd_enable=3D"YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" >=20 > clear_tmp_enable=3D"YES" >=20 > sendmail_enable=3D"NO" > sendmail_submit_enable=3D"NO" > sendmail_outbound_enable=3D"NO" > sendmail_msp_queue_enable=3D"NO" >=20 > rpcbind_enable=3D"YES" > nfs_server_enable=3D"YES" > mountd_enable=3D"YES" >=20 > #nfsv4_server_enable=3D"YES" > #nfsuserd_enable=3D"YES" > #mountd_flags=3D"-r" >=20 > ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" >=20 > jail_enable=3D"YES" > jail_list=3D"buildstable10amd64 buildreleng100i386" >=20 > #ntpdate_enable=3D"YES" > #ntpdate_hosts=3D"10.71.14.1" >=20 > nginx_enable=3D"YES" >=20 >=20 > #mdnsresponderposix_enable=3D"YES" > mdnsresponderposix_flags=3D"-f /usr/local/etc/mDNSResponder.conf" >=20 >=20 > #openntpd_enable=3D"YES" >=20 > #avahi_daemon_enable=3D"YES" > #dbus_enable=3D"YES" > mdnsd_enable=3D"YES" >=20 > smartd_enable=3D"YES" >=20 > dma_flushq_enable=3D=E2=80=9CYES=E2=80=9D >=20 > -Kimmo >=20 Just a thought. Is my problem related to the use of GPT labeled = partitions in my pool configuration? Your testing shows just "raw" = devices like ada0p3 etc. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 01:20:47 2014 Return-Path: Delivered-To: freebsd-stable@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 815ED1A7 for ; Thu, 11 Sep 2014 01:20:47 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) (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 1B292758 for ; Thu, 11 Sep 2014 01:20:46 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) by dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s8B18I1J002866 for ; Thu, 11 Sep 2014 02:08:18 +0100 (BST) (envelope-from jamie@dyslexicfish.net) Received: (from jamie@localhost) by dyslexicfish.net (8.14.5/8.14.5/Submit) id s8B18I6b002865 for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 02:08:18 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201409110108.s8B18I6b002865@dyslexicfish.net> Date: Thu, 11 Sep 2014 02:08:18 +0100 To: freebsd-stable@freebsd.org Subject: Re: 10-STABLE Buildworld Failing References: <54109820.1030905@tundraware.com> <54109CA5.7050807@tundraware.com> <5410D4D7.8060906@tundraware.com> In-Reply-To: <5410D4D7.8060906@tundraware.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (dyslexicfish.net [91.109.5.35]); Thu, 11 Sep 2014 02:08:19 +0100 (BST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 01:20:47 -0000 Tim Daneliuk wrote: > Well something has definitely changed of late. Not only do I now have > to cleanup the env variable with proper quoting, You say that as if it's a bad thing! From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 01:22:09 2014 Return-Path: Delivered-To: freebsd-stable@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 4A7AB299; Thu, 11 Sep 2014 01:22:09 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0E44B7ED; Thu, 11 Sep 2014 01:22:08 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 52DF220E7088E; Thu, 11 Sep 2014 01:22:08 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 86FDD20E7088B; Thu, 11 Sep 2014 01:22:06 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Aristedes Maniatis" , "Stefan Esser" , "freebsd-stable" References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> <5410F0B4.9040808@ish.com.au> Subject: Re: getting to 4K disk blocks in ZFS Date: Thu, 11 Sep 2014 02:22:14 +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-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 01:22:09 -0000 ----- Original Message ----- From: "Aristedes Maniatis" To: "Stefan Esser" ; "freebsd-stable" Sent: Thursday, September 11, 2014 1:45 AM Subject: Re: getting to 4K disk blocks in ZFS > Thanks Stefan and Peter for the highly informative posts. > > On 10/09/2014 5:48pm, Stefan Esser wrote: >> ZFS uses variable block sizes by breaking down large blocks to smaller >> fragments as suitable for the data to be stored. The largest block to >> be used is configurable (128 KByte by default) and the smallest fragment >> is the sector size (i.e. 512 or 4096 bytes), as configured by "ashift". > > So this means that the ZFS developers would need to effectively (re)fragment the entire pool if they wanted to develop a way to > increase the ashift size. This sounds like something that isn't going to be solved in the near future (less than three years) if > it is a similar technical problem to inserting another disk into an existing vdev. > > And that means that as it becomes harder to buy older 512 byte disks, everyone with a ZFS pool is going to be stuck with managing > quite a lot of downtime as they upgrade. And even more pain if they boot off that pool. > > > On 10/09/2014 4:51pm, Peter Wemm wrote: >> For what its worth, in the freebsd.org cluster we automatically align >> everything to a minimum of 4k, no matter what the actual drive is. >> >> We set: sysctl vfs.zfs.min_auto_ashift=12 >> (this saves a lot of messing around with gnop etc) >> >> and ensure all the gpt slices are 4k or better aligned. > > Should the FreeBSD project change this minimum in the next release? > There seems to be no downside and a huge amount of pain for people > who stumble along with the defaults not knowing what a mess they are > creating to solve later. The downside is wasted space which can be significant and hence when I last suggested just this it was unfortunately rejected. We still maintain a local patch to our source tree which does just this because, as you've mentioned, we don't want the pain so its easier to just run everything as 4k. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 01:25:36 2014 Return-Path: Delivered-To: freebsd-stable@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 68D083C6 for ; Thu, 11 Sep 2014 01:25:36 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2324F819 for ; Thu, 11 Sep 2014 01:25:35 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 4CCB020E7088E; Thu, 11 Sep 2014 01:25:35 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 8006B20E7088B; Thu, 11 Sep 2014 01:25:32 +0000 (UTC) Message-ID: <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> From: "Steven Hartland" To: "Kimmo Paasiala" References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> Subject: Re: ZFS on root booting broken somewhere after r270020 Date: Thu, 11 Sep 2014 02:25:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; 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 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 01:25:36 -0000 ----- Original Message ----- From: "Kimmo Paasiala" snip... > Just a thought. Is my problem related to the use of GPT labeled partitions > in my pool configuration? Your testing shows just "raw" devices like ada0p3 etc. That "should" have no impact on anything, we disable gptids and diskid's as we don't like them adding an extra layer for lookups when admins are working with the machines. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 02:26:43 2014 Return-Path: Delivered-To: freebsd-stable@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 658EB948 for ; Thu, 11 Sep 2014 02:26:43 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28E7BCBD for ; Thu, 11 Sep 2014 02:26:42 +0000 (UTC) Received: from [192.168.2.123] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by webmail2.jnielsen.net (8.14.9/8.14.9) with ESMTP id s8B2QbxC010931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Sep 2014 20:26:40 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105] claimed to be [192.168.2.123] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: getting to 4K disk blocks in ZFS From: John Nielsen X-Mailer: iPhone Mail (11D257) In-Reply-To: <540FF3C4.6010305@ish.com.au> Date: Wed, 10 Sep 2014 20:26:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <540FF3C4.6010305@ish.com.au> To: Aristedes Maniatis Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 02:26:43 -0000 > On Sep 10, 2014, at 12:46 AM, Aristedes Maniatis wrote: >=20 > As we all know, it is important to ensure that modern disks are set up pro= perly with the correct block size. Everything is good if all the disks and t= he pool are "ashift=3D9" (512 byte blocks). But as soon as one new drive req= uires 4k blocks, performance drops through the floor of the enture pool. >=20 >=20 > In order to upgrade there appear to be two separate things that must be do= ne for a ZFS pool. >=20 > 1. Create partitions on 4K boundaries. This is simple with the "-a 4k" opt= ion in gpart, and it isn't hard to remove disks one at a time from a pool, r= eformat them on the right boundaries and put them back. Hopefully you've lef= t a few spare bytes on the disk to ensure that your partition doesn't get sm= aller when you reinsert it to the pool. >=20 > 2. Create a brand new pool which has ashift=3D12 and zfs send|receive all t= he data over. >=20 >=20 > I guess I don't understand enough about zpool to know why the pool itself h= as a block size, since I understood ZFS to have variable stripe widths. >=20 > The problem with step 2 is that you need to have enough hard disks spare t= o create a whole new pool and throw away the old disks. Plus a disk controll= er with lots of spare ports. Plus the ability to take the system offline for= hours or days while the migration happens. >=20 > One way to reduce this slightly is to create a new pool with reduced redun= dancy. For example, create a RAIDZ2 with two fake disks, then offline those d= isks. Lots of good info in other responses, I just wanted to address this part of y= our message. It should be a given that good backups are a requirement before you start an= y of this. _Especially_ if you have to destroy the old pool in order to prov= ide redundancy for the new pool. I have done this ashift conversion and it was a bit of a nail-biting experie= nce as you've anticipated. The one suggestion I have for improving on the ab= ove is to use snapshots to minimize the downtime. Get an initial clone of th= e pool during off-peak hours (if any), then you only need to take the system= down to send a "final" differential snapshot. JN= From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 03:15:27 2014 Return-Path: Delivered-To: freebsd-stable@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 0A8F6212 for ; Thu, 11 Sep 2014 03:15:27 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) (using TLSv1 with cipher DES-CBC3-SHA (112/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 C84CC1B4 for ; Thu, 11 Sep 2014 03:15:26 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBP0001IVPFTGA0@st11p09mm-asmtp001.mac.com> for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 03:15:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-11_01:2014-09-09,2014-09-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409110026 Subject: Re: ZFS on root booting broken somewhere after r270020 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Content-type: text/plain; charset=utf-8 From: Kimmo Paasiala X-Priority: 3 In-reply-to: <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> Date: Thu, 11 Sep 2014 06:15:14 +0300 Content-transfer-encoding: quoted-printable Message-id: <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1973.6) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 03:15:27 -0000 > On 11.9.2014, at 4.25, Steven Hartland = wrote: >=20 > ----- Original Message ----- From: "Kimmo Paasiala" = >=20 > snip... >=20 >> Just a thought. Is my problem related to the use of GPT labeled = partitions >> in my pool configuration? Your testing shows just "raw" devices like = ada0p3 etc. >=20 > That "should" have no impact on anything, we disable gptids and = diskid's as we > don't like them adding an extra layer for lookups when admins are = working with > the machines. >=20 > Regards > Steve I recreated the pool on the second disk as another single disk pool, = performed zfs send -R =E2=80=A6 | zfs receive -F =E2=80=A6 It works now just fine with the kernel that didn=E2=80=99t work with old = pool so there must have been something seriously broken with the old = pool. I also noticed the old pool kept repeatedly restarting the = resilver operations when I tried to expand it into a mirror. Case closed for now. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 03:23:19 2014 Return-Path: Delivered-To: freebsd-stable@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 DCA406DF for ; Thu, 11 Sep 2014 03:23:19 +0000 (UTC) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id AAA7229C for ; Thu, 11 Sep 2014 03:23:18 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 351501F462 for ; Wed, 10 Sep 2014 23:23:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8CDsLyWHSRn for ; Wed, 10 Sep 2014 23:23:12 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <5411159F.6060608@egr.msu.edu> Date: Wed, 10 Sep 2014 23:23:11 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ZFS on root booting broken somewhere after r270020 References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> In-Reply-To: <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 03:23:19 -0000 On 09/10/2014 23:15, Kimmo Paasiala wrote: > >> On 11.9.2014, at 4.25, Steven Hartland wrote: >> >> ----- Original Message ----- From: "Kimmo Paasiala" >> >> snip... >> >>> Just a thought. Is my problem related to the use of GPT labeled partitions >>> in my pool configuration? Your testing shows just "raw" devices like ada0p3 etc. >> >> That "should" have no impact on anything, we disable gptids and diskid's as we >> don't like them adding an extra layer for lookups when admins are working with >> the machines. >> >> Regards >> Steve > > I recreated the pool on the second disk as another single disk pool, performed zfs send -R … | zfs receive -F … > > It works now just fine with the kernel that didn’t work with old pool so there must have been something seriously broken with the old pool. I also noticed the old pool kept repeatedly restarting the resilver operations when I tried to expand it into a mirror. > > Case closed for now. > > -Kimmo > > Were you running a newer kernel with an older format zpool? I heard ixsystems had customers doing that and ran into corruption when they tried to modify the zpool in some way (expand? I don't remember). http://www.bsdnow.tv/episodes/2014_07_09-zfs_war_stories From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 03:23:47 2014 Return-Path: Delivered-To: stable@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 2CDC47EA for ; Thu, 11 Sep 2014 03:23:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 112662CC for ; Thu, 11 Sep 2014 03:23:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8B3NkK3011719 for ; Thu, 11 Sep 2014 03:23:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193363] [panic] panic at reboot Date: Thu, 11 Sep 2014 03:23:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 03:23:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193363 --- Comment #2 from sasamotikomi@gmail.com --- Created attachment 147207 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147207&action=edit dmesg -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 03:24:22 2014 Return-Path: Delivered-To: stable@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 76F6292F for ; Thu, 11 Sep 2014 03:24:22 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 5EAB02EC for ; Thu, 11 Sep 2014 03:24:22 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8B3OMbi018048 for ; Thu, 11 Sep 2014 03:24:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193363] [panic] panic at reboot Date: Thu, 11 Sep 2014 03:24:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 03:24:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193363 --- Comment #3 from sasamotikomi@gmail.com --- (In reply to John Baldwin from comment #1) > Can you do 'gdb /boot/kernel.old9.1/kernel' and then 'l *0xc0aae65'? l *0xc0aae65 No symbol table is loaded. Use the "file" command I think, I do it wrong... >Also, can you provide more details about your system (e.g. do you have an ed(4) or > xl(4) NIC)? A non-verbose dmesg would be a good start. No, I haven't ed(4) or xl(4). I add dmesg as attachments. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 03:40:39 2014 Return-Path: Delivered-To: stable@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 C354EC14 for ; Thu, 11 Sep 2014 03:40:39 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 AA9C9649 for ; Thu, 11 Sep 2014 03:40:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8B3edb2041574 for ; Thu, 11 Sep 2014 03:40:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Thu, 11 Sep 2014 03:40:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 03:40:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 --- Comment #6 from sasamotikomi@gmail.com --- (In reply to John Baldwin from comment #5) > In all these crashes, the root bug is a NULL pointer dereference (probably) > at drm_ioctl+0x2ca. Can you provide the kgdb backtrace from a single > core.txt file? It would be good to see what source line corresponds to that > address. I still have old GENERIC kernel (/boot/kernel.old.9.1/kernel) how to do that? I new for kernel debugging. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 03:48:48 2014 Return-Path: Delivered-To: stable@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 72C8EE32 for ; Thu, 11 Sep 2014 03:48:48 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 5A186697 for ; Thu, 11 Sep 2014 03:48:48 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8B3mmKG048143 for ; Thu, 11 Sep 2014 03:48:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193364] [panic] ffs_blkfree_cg: freeing free block Date: Thu, 11 Sep 2014 03:48:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 03:48:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193364 --- Comment #4 from sasamotikomi@gmail.com --- (In reply to John Baldwin from comment #2) > Your filesystem is probably corrupted from an earlier crash. Run fsck in > single user mode. I already do that but. That I just update xorg # pkg upgrade xorg I got similar panic again. I again run fsck without journals fsck in single user mode. Update. "All" ok, I successfully update. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 06:08:42 2014 Return-Path: Delivered-To: stable@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 C1631C86 for ; Thu, 11 Sep 2014 06:08:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 A8BF11FF for ; Thu, 11 Sep 2014 06:08:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8B68gTK081115 for ; Thu, 11 Sep 2014 06:08:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193389] [panic] ufs_dirbad: /: bad dir Date: Thu, 11 Sep 2014 06:08:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:08:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193389 --- Comment #2 from sasamotikomi@gmail.com --- (In reply to Adrian Chadd from comment #1) > Have you run a full fsck on the filesystem? > > > > -a Yes as in single user mode without journal, also I got this panic again, when update my pkg. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 06:25:43 2014 Return-Path: Delivered-To: freebsd-stable@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 8D358F5; Thu, 11 Sep 2014 06:25:43 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A14413C6; Thu, 11 Sep 2014 06:25:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA01467; Thu, 11 Sep 2014 09:25:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XRxp4-0000v1-6V; Thu, 11 Sep 2014 09:25:38 +0300 Message-ID: <54114029.3060507@FreeBSD.org> Date: Thu, 11 Sep 2014 09:24:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steven Hartland , Aristedes Maniatis , freebsd-stable Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> <5410F0B4.9040808@ish.com.au> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:25:43 -0000 On 11/09/2014 04:22, Steven Hartland wrote: > > ----- Original Message ----- From: "Aristedes Maniatis" >> Should the FreeBSD project change this minimum in the next release? >> There seems to be no downside and a huge amount of pain for people >> who stumble along with the defaults not knowing what a mess they are >> creating to solve later. > > The downside is wasted space which can be significant and hence when > I last suggested just this it was unfortunately rejected. > > We still maintain a local patch to our source tree which does just > this because, as you've mentioned, we don't want the pain so its > easier to just run everything as 4k. Another downside is 1/4th of uberblocks, 32 vs 128. Also, automatic sector size detection works great for me and I've never had a need to manually tweak ashift. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 06:33:14 2014 Return-Path: Delivered-To: freebsd-stable@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 D3648244 for ; Thu, 11 Sep 2014 06:33:14 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D837660 for ; Thu, 11 Sep 2014 06:33:13 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s8B6X2aC034085 for ; Thu, 11 Sep 2014 01:33:02 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Thu Sep 11 01:33:02 2014 Message-ID: <54114217.9040403@denninger.net> Date: Thu, 11 Sep 2014 01:32:55 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> <5410F0B4.9040808@ish.com.au> <54114029.3060507@FreeBSD.org> In-Reply-To: <54114029.3060507@FreeBSD.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050807010805000508040107" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:33:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050807010805000508040107 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 9/11/2014 1:24 AM, Andriy Gapon wrote: > On 11/09/2014 04:22, Steven Hartland wrote: >> ----- Original Message ----- From: "Aristedes Maniatis" >>> Should the FreeBSD project change this minimum in the next release? >>> There seems to be no downside and a huge amount of pain for people >>> who stumble along with the defaults not knowing what a mess they are >>> creating to solve later. >> The downside is wasted space which can be significant and hence when >> I last suggested just this it was unfortunately rejected. >> >> We still maintain a local patch to our source tree which does just >> this because, as you've mentioned, we don't want the pain so its >> easier to just run everything as 4k. > > Another downside is 1/4th of uberblocks, 32 vs 128. > Also, automatic sector size detection works great for me and I've never= had a > need to manually tweak ashift. > It works great until you start replacing older disks with new, larger=20 ones and find out that the new ones are 4k where the old ones were not...= =2E. IMHO at this point in time it's worth considering a 4k default. -- Karl --------------ms050807010805000508040107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTEwNjMyNTVaMCMGCSqGSIb3DQEJBDEW BBSGr85Bc6yoBK3wRF/4WAjXUEzBzTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAcybxWCNHCK/ECs4el2aXUEFwcM4I +CzN1NgBd0aR41EZh8l2vWrySgWXPu1LZ4P7IJ7zBePlhSYFmgZ5Dgzdv93Tv8uEURUW8HJZ qGjgArlzs0hziNrWkM6DFqmK76/Cuj5rL47I+Ejp6VJMUeoQI6/cTJDZsWVWl/HRMhCIJqzB hxd11/hTMvVkMLaPtEej6zibWGPIA3CTX8m7CnRQUm/mFaQ/6xcKwr3mOPPOzVB6uG3Zskm9 polqdgcYmIIHZ3rS/0n5lsP1WPdbJP7YLfHwdDJZEkw6BZvQSD2wB1looZGDFv4hoHyivsOl 3Qgb0xrWPZ43YIqs94gEPgLEleUwlyCj3OrRL7noCLpy1VvzbFh9BiuAny2FHUByAGsiwMMu mbD2qK0Mrmj+pG6S3+pxul7uteViUx6Tvlsu+1ntLABGgEdTYvkfWc6xXCfjRZprwPOcSd8t 6e+EBgEOu1M+5acdVu1pWCyM4uO/7MvzWmZffjzH9qVzRz54SdkrIuu3pfyR7X7V/30UI1Ze xCD9/j7hgunOLbEaAPK1rdcGbsOvEzX9JJDeb45lfxBbh/lEwSD5DdLgiU5nBJ63yvTvDwwD +8+RqPlACZVFlBM1oucc0YlDipiS0SIHMVLcU9n2R6g14s4OS8A2E6yMkOPFynEA1exdaHJK 9tMCCZMAAAAAAAA= --------------ms050807010805000508040107-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 06:47:47 2014 Return-Path: Delivered-To: freebsd-stable@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 72DF13EA for ; Thu, 11 Sep 2014 06:47:47 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D63CB791 for ; Thu, 11 Sep 2014 06:47:46 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s8B6lehb001044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 11 Sep 2014 16:47:40 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1410418060; bh=+8HnHo4q7FLriEKapdIDpxNCgMoay1OusWqpUTVGKus=; h=Date:From:To:Subject; b=TUlG4AFJriXA84anumbKEhfgwNQRO/IdDlob+RYTnxttY67UK/G65/DVr1tNWmzyk Q4i96X2bnl1qxxZfjGHMmCluVLgw6h5F+UCagUWHLM+uzdrrRe3VcsZabnSAj68GbO F/01t85SIqDSx281/pMbFzZhkCOqnGB4SuOI/KBw= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s8B6lWbV001043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 11 Sep 2014 16:47:35 +1000 (AEST) Date: Thu, 11 Sep 2014 16:47:31 +1000 From: John Marshall To: freebsd-stable@freebsd.org Subject: 10.1 kernel device config for drm2 and kms drivers Message-ID: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:47:47 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I cannot find any kernel device configuration statements for drm2 or KMS (e.g. i915kms) drivers in any of the NOTES files in 10-STABLE. Presumably configurtation statements for these ought to be available for use in kernel configuration files for 10.1-RELEASE? At present, the only way I have found to pick them up (short of hacking sys/conf/files or building all modules) is by specifying the module in make.conf and then adding the load_ directive to loader.conf. MODULES_OVERRIDE=3D drm2 --=20 John Marshall --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQRRYMACgkQw/tAaKKahKIBkwCfeTQYKTGwBth0N/FRqW7R0qle DNUAnj+0GB8OX0uew8xJ2pZ5M8zJIWXG =hmer -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 07:12:09 2014 Return-Path: Delivered-To: freebsd-stable@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 EBCC1972; Thu, 11 Sep 2014 07:12:09 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 5F6079D3; Thu, 11 Sep 2014 07:12:09 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id z12so5260529wgg.16 for ; Thu, 11 Sep 2014 00:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=an7+BsqrrPp3muilUAn7cTZIq3Ndqw82wMHVIBk3CjQ=; b=fEqoKuacfWkiQ0Voxqt0VR+geyQc2+j9pvmj3uV634lWMSIoBY1xVDsljfgbbl5JGC 1ya/ggunxGx+M94qPoQQNnt5NBQM6Efs+T1dCvikrGNLM2xQ7/r2LV2vY4CZpcY1QcF6 emNzCYs2TPW9WhLlpV2n8eNBiOSGJ5TPJICkQO05psi8C6DGsDMqM0iIhaYULclNAWju kICarCrA8MD/nEWeJU/+8UWa8Mh0Io8Z5l27OPDZf2Z3qGkjmt0mAb/8i2l5Hz8ZqUad 1vcbINzckERXOSYSBxQJi9sYx/B+K52qbsl94wIqbRjTNIlByKlUhjnVwwltcuhxUpHn FP2A== X-Received: by 10.194.209.205 with SMTP id mo13mr653607wjc.122.1410419527617; Thu, 11 Sep 2014 00:12:07 -0700 (PDT) Received: from [192.168.1.145] ([193.173.55.180]) by mx.google.com with ESMTPSA id bj7sm123531wjc.33.2014.09.11.00.12.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Sep 2014 00:12:07 -0700 (PDT) Message-ID: <54114B46.3020407@gmail.com> Date: Thu, 11 Sep 2014 09:12:06 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Stefan Esser , freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> In-Reply-To: <54100258.2000505@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 07:12:10 -0000 Op 10-09-14 om 09:48 schreef Stefan Esser: > Am 10.09.2014 um 08:46 schrieb Aristedes Maniatis: >> As we all know, it is important to ensure that modern disks are set >> up properly with the correct block size. Everything is good if all >> the disks and the pool are "ashift=9" (512 byte blocks). But as soon >> as one new drive requires 4k blocks, performance drops through the >> floor of the enture pool. >> >> >> In order to upgrade there appear to be two separate things that must >> be done for a ZFS pool. >> >> 1. Create partitions on 4K boundaries. This is simple with the >> "-a 4k" option in gpart, and it isn't hard to remove disks one at a >> time from a pool, reformat them on the right boundaries and put them >> back. Hopefully you've left a few spare bytes on the disk to ensure >> that your partition doesn't get smaller when you reinsert it to the >> pool. >> >> 2. Create a brand new pool which has ashift=12 and zfs send|receive >> all the data over. >> >> >> I guess I don't understand enough about zpool to know why the pool >> itself has a block size, since I understood ZFS to have variable >> stripe widths. > I'm not a ZFS internals expert, just a long time user, but I'll try to > answer your questions. > > ZFS is based on a copy-on-write paradigm, which ensures, that no data > is ever overwritten in place. All writes go to new blank blocks, and > only after the last reference to an "old" block is lost (when no TXG > or snapshot has references to it), is the old block freed and put back > on the free block map. > > ZFS uses variable block sizes by breaking down large blocks to smaller > fragments as suitable for the data to be stored. The largest block to > be used is configurable (128 KByte by default) and the smallest fragment > is the sector size (i.e. 512 or 4096 bytes), as configured by "ashift". > > The problem with 4K sector disks that report 512 byte sectors is, that > ZFS still assumes, that no data is overwritten in place, while the disk > drive does it behind the curtains. ZFS thinks it can atomically write > 512 bytes, but the drive reads 4K, places the 512 bytes of data within > that 4K physical sector in the drive's cache, and then writes back the > 4K of data in one go. > > The cost is not only the latency of this read-modify-write sequence, > but also that an elementary ZFS assumption is violated: Data that is > in other (logical) 512 byte sectors of the physical 4 KByte sector > can be lost, if that write operation fails, resulting in loss of data > in those files that happen to share the physical sector with the one > that received the write operation. > > This may never hit you, but ZFS is built on the assumption, that it > cannot happen at all, which is no longer true with 4KB drives that > are used with ashift=9. > >> The problem with step 2 is that you need to have enough hard disks >> spare to create a whole new pool and throw away the old disks. Plus >> a disk controller with lots of spare ports. Plus the ability to take >> the system offline for hours or days while the migration happens. >> >> One way to reduce this slightly is to create a new pool with reduced >> redundancy. For example, create a RAIDZ2 with two fake disks, then >> off-line those disks. > Both methods are dangerous! Studies have found, that the risk of > another disk failure during resilvering is substantial. That was > the reason for higher RAIDZ redundancy groups (raidz2, raidz3). > > With 1) you have to copy the data multiple times and the load > could lead to loss of one of the source drives (and since you > are in the process of overwriting the drive that provided > redundancy, you loose your pool that way). > > The copying to a degraded pool that you describe in 2) is a > possibility (and I've done it, once). You should make sure, that > all source data is still available until a successful resilvering > of the "new" pool with the fake disks replaced. You could do this > by moving the redundant disks from the old pool the new pool (i.e. > degrading the old pool, after all data has been copied, to use the > redundant drives to complete the new pool). But this assumes, that > the technologies of the drives match - I'll soon go from 4*2TB to > 3*4TB (raidz1 in both cases), since I had 2 of the 2TB drives fail > over the course of last year (replaced under warranty). > >> So, given how much this problem sucks (it is extremely easy to add >> a 4K disk by mistake as a replacement for a failed disk), and how >> painful the workaround is... will ZFS ever gain the ability to change >> block size for the pool? Or is this so deep in the internals of ZFS >> it is as likely as being able to dynamically add disks to an existing >> zvol in the "never going to happen" basket? > You can add a 4 KB physical drive that emulates 512 byte sectors > (nearly all drives do) to an ashift=9 ZFS pool, but performance > will suffer and you'll be violating a ZFS assumption as explained > above. > >> And secondly, is it also bad to have ashift 9 disks inside a ashift >> 12 pool? That is, do we need to replace all our disks in one go and >> forever keep big sticky labels on each disk so we never mix them? > The ashift parameter is per pool, not per disk. You can have a > drive with emulated 512 byte sectors in an ashift=9 pool, but > you cannot change the ashift value of a pool after creation. The ashift parameter is per vdev, not per pool. > Regards, STefan > _______________________________________________ > 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-stable@FreeBSD.ORG Thu Sep 11 08:01:38 2014 Return-Path: Delivered-To: freebsd-stable@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 0119D592 for ; Thu, 11 Sep 2014 08:01:37 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id CE2CEDF8 for ; Thu, 11 Sep 2014 08:01:36 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 7927145088; Thu, 11 Sep 2014 07:23:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 7927145088 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1410420236; bh=nrxDZC6KsaoQ+UgBTmRRfdQ1D0YkwHSx83k57VNGpG8=; h=Date:From:To:Subject:References:In-Reply-To; b=xWS2hMG+qIHTZOsdmAaDvVc0y9zUrL1xyukafPSykDt34EFezyJcJoOmQ3nFWjzus oDUR+VGWI99ebD58tcjEtOmwU81wO2W0dyQf1NqMpOnoQSwChha1ptb4pHKqKF1Kez auUeXoL6BhTNzgSrqE6qWczJTTgS5X9KT5o4eBeU= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id D28A3153E0; Thu, 11 Sep 2014 08:23:54 +0100 (BST) Date: Thu, 11 Sep 2014 08:23:54 +0100 From: Ben Morrow To: karl@denninger.net, freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS Message-ID: <20140911072351.GA50786@anubis.morrow.me.uk> Mail-Followup-To: karl@denninger.net, freebsd-stable@freebsd.org References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> <5410F0B4.9040808@ish.com.au> <54114029.3060507@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54114217.9040403@denninger.net> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:01:38 -0000 Quoth Karl Denninger : > On 9/11/2014 1:24 AM, Andriy Gapon wrote: > > On 11/09/2014 04:22, Steven Hartland wrote: > >> ----- Original Message ----- From: "Aristedes Maniatis" > >>> Should the FreeBSD project change this minimum in the next release? > >>> There seems to be no downside and a huge amount of pain for people > >>> who stumble along with the defaults not knowing what a mess they are > >>> creating to solve later. > >> > >> The downside is wasted space which can be significant and hence when > >> I last suggested just this it was unfortunately rejected. > >> > >> We still maintain a local patch to our source tree which does just > >> this because, as you've mentioned, we don't want the pain so its > >> easier to just run everything as 4k. > > > > Another downside is 1/4th of uberblocks, 32 vs 128. Also, automatic > > sector size detection works great for me and I've never had a need > > to manually tweak ashift. > > > It works great until you start replacing older disks with new, larger > ones and find out that the new ones are 4k where the old ones were not..... Is there any way (short of building a new pool) to get a reasonable idea of how much extra space a given pool would use if converted? Ben From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 08:28:32 2014 Return-Path: Delivered-To: freebsd-stable@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 868E6B7D for ; Thu, 11 Sep 2014 08:28:32 +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 48A24A0 for ; Thu, 11 Sep 2014 08:28:32 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XRzjy-0005Ux-7z for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 10:28:30 +0200 Message-ID: <54115D2A.5020802@FreeBSD.org> Date: Thu, 11 Sep 2014 10:28:26 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> In-Reply-To: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UBixFs1u3XPQ5jU4it4KbBDe4wcM3k028" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:28:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UBixFs1u3XPQ5jU4it4KbBDe4wcM3k028 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11.09.2014 08:47, John Marshall wrote: > I cannot find any kernel device configuration statements for drm2 or KM= S > (e.g. i915kms) drivers in any of the NOTES files in 10-STABLE. > Presumably configurtation statements for these ought to be available fo= r > use in kernel configuration files for 10.1-RELEASE? Currently, building DRM drivers into the kernel isn't supported. I guess it's mostly a lack of time and demand. Please file a PR about this so that I keep that in mind. If you have some time and can prepare a patch, that would help too :) > At present, the only way I have found to pick them up (short of hacking= > sys/conf/files or building all modules) is by specifying the module in > make.conf and then adding the load_ directive to loader.conf. You can also use the following line in your rc.conf: kld_list=3D"i915kms" The GPU will be initialized a bit later compared to load_i915kms=3D"yes",= but the kernel will be loaded faster. Thank you! --=20 Jean-S=C3=A9bastien P=C3=A9dron --UBixFs1u3XPQ5jU4it4KbBDe4wcM3k028 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 iQJ8BAEBCgBmBQJUEV0uXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMJ7UQAM6o5kD9zB1FM00HdW2blNfO V85LwJrIQqErvwv6ge8KCW6DKZF4C+5iiaOYH1Y9iEqmlf9voNXYah4aFFUs6Mkn XtAVh8ps1Y53Aq+IAfrNhA0HdDGgBtyV0XLoRIAy90y0/wOh6gZCTzmavxRLPuD3 eEwo7XE1BrkUaqLnbHatlA5yKvfmHEpKf6QmjDZ5ykOFmPfJOWsogpQIge8HPO4N LTOHjVmiP4iJy5cJlBfnfnfphR16HaZdfq3sgl0SvUVlaG5AmDejGqNhP3UDvXc7 BFcfTQLC+mdZOin3zqXowvw9tZ0IMU7Kiu6ODdhsLktmk7g99GWfAp66YoBwRnYU OFkN51xv95qeZ9NoUztYG4EcyghCSFqdcCoF4wYR/bj+5hTLcUII9ttopN67lV7z mfWD40jME7q6Nl32Ay8q4Ztpq4L4erZBhA99aXdLsf02uoDUawus1lxGm0wZeLVN wl53ATnVLhRseMPdUzLOwjwRjW0MutKCX6KsiPyysH735tN1rNs/Vb+buQo0KjDG AiF7SgafwbWhHGwwZM4m6Fph9nSyQeoEwBK5LvA46OncxIUEHHwL4FmMi4wSg6lY 2edrYfauwpVLbO3mnFFHSawKzgx+0gvjXkUr1dJsPuo7zAGrTwF+CUHS2SUxdmcN cSUIhiUxAvRQH3hKukRG =WFhL -----END PGP SIGNATURE----- --UBixFs1u3XPQ5jU4it4KbBDe4wcM3k028-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 08:31:37 2014 Return-Path: Delivered-To: freebsd-stable@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 8EC12CA7 for ; Thu, 11 Sep 2014 08:31:37 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 57C5F153 for ; Thu, 11 Sep 2014 08:31:37 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 0183645087 for ; Thu, 11 Sep 2014 07:12:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 0183645087 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1410419560; bh=ADrYwbcUeW2ZvLCEpvdJLQTha4QDGw7Ky2nuIMkl5x8=; h=Date:From:To:Subject:References:In-Reply-To; b=R8k16yGDN17L7cvsKr+u1QRpgoZqRYkRcx6roOLHft9bzLpwtsBEOyICDKFEfUscX hK5DoK6OiTQKvWmiehLKD3R0D4BVmE1w97VYs3HFfibU3X7SHSDibIWY76e8LGAYIv 8am73fMtjrm2OKwucnUCDL3K4hWBbCyOtOGMGQXc= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 2335A153D9; Thu, 11 Sep 2014 08:12:37 +0100 (BST) Date: Thu, 11 Sep 2014 08:12:37 +0100 From: Ben Morrow To: freebsd-stable@freebsd.org Subject: Snapshots that won't delete [was: Re: ZFS on root booting...] Message-ID: <20140911071233.GA50585@anubis.morrow.me.uk> Mail-Followup-To: freebsd-stable@freebsd.org References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5411159F.6060608@egr.msu.edu> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:31:37 -0000 Quoth Adam McDougall : > > Were you running a newer kernel with an older format zpool? I heard > ixsystems had customers doing that and ran into corruption when they > tried to modify the zpool in some way (expand? I don't remember). > http://www.bsdnow.tv/episodes/2014_07_09-zfs_war_stories Oh! Might this be what's causing a problem I've been meaning to ask about? My desktop at home is running (a patched, but not anywhere to do with ZFS) 10-STABLE from a while ago, with a zpool that was created under 8.2-R and is still at version 15. I have been deliberately not upgrading it, because I saw no reason to and it seemed safer to leave things as they were. Recently, though, my dump script has started having occasional problems with snapshots that won't delete. Pending further investigation I have been renaming them to allow the recursive delete to succeed, and (so far) rebooting has always made it possible to get rid of them. /home/mauzo% sudo zfs destroy zroot/DATA/R@broken-dump-20140906 cannot destroy snapshot zroot/DATA/R@broken-dump-20140906: dataset is busy /home/mauzo% mount | grep @ /home/mauzo% zfs list -o name,origin | grep broken-dump /home/mauzo% zfs list -o name,userrefs zroot/DATA/R@broken-dump-20140906 NAME USERREFS zroot/DATA/R@broken-dump-20140906 0 /home/mauzo% zfs holds zroot/DATA/R@broken-dump-20140906 NAME TAG TIMESTAMP /home/mauzo% Presumably this is indicative of some sort of serious problem with either the pool or the filesystem, and the only permanent solution is to rebuild the whole thing? ZFS doesn't seem to have a fsck-equivalent for the ZFS layer. I've run a scrub, and it found no problems. I was about to upgrade the machine to the latest 10-STABLE, but I can put that off if anyone thinks this is worth investigating. Once I reboot I'm fairly sure the current stuck snapshots will fix themselves, and of course I can't be sure when this will happen again. [Also: it would be really nice to have an alias for 'zfs destroy' that will only destroy snapshots. When running something like 'zfs destroy -r zroot/DATA@whatever' I find I have to check at least three times that I have definitely put that @ in the right place before pressing Return. *Especially* when I'm doing it because I'm running a dump, and it's just fallen over because it can't delete a snapshot.] Ben From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 08:46:33 2014 Return-Path: Delivered-To: freebsd-stable@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 02B17FAD; Thu, 11 Sep 2014 08:46:33 +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 97E15273; Thu, 11 Sep 2014 08:46:32 +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 s8B8kOJ6078964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2014 11:46:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8B8kOJ6078964 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8B8kOeZ078963; Thu, 11 Sep 2014 11:46:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Sep 2014 11:46:24 +0300 From: Konstantin Belousov To: Jean-S??bastien P??dron Subject: Re: 10.1 kernel device config for drm2 and kms drivers Message-ID: <20140911084624.GK2737@kib.kiev.ua> References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5587ow7Bqi7FXI0s" Content-Disposition: inline In-Reply-To: <54115D2A.5020802@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: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:46:33 -0000 --5587ow7Bqi7FXI0s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 11, 2014 at 10:28:26AM +0200, Jean-S??bastien P??dron wrote: > On 11.09.2014 08:47, John Marshall wrote: > > I cannot find any kernel device configuration statements for drm2 or KMS > > (e.g. i915kms) drivers in any of the NOTES files in 10-STABLE. > > Presumably configurtation statements for these ought to be available for > > use in kernel configuration files for 10.1-RELEASE? >=20 > Currently, building DRM drivers into the kernel isn't supported. I guess > it's mostly a lack of time and demand. I did not added file list to the static kernel config due to display becoming blank after the driver initialization, which is very early for the syscons setup. Might be, since vt is functional, this may be reconsidered. Driver initialization was never tested when loaded from loader, I have no idea how i915 starts up with interrupts still disabled. >=20 > Please file a PR about this so that I keep that in mind. If you have > some time and can prepare a patch, that would help too :) >=20 > > At present, the only way I have found to pick them up (short of hacking > > sys/conf/files or building all modules) is by specifying the module in > > make.conf and then adding the load_ directive to loader.conf. >=20 > You can also use the following line in your rc.conf: > kld_list=3D"i915kms" >=20 > The GPU will be initialized a bit later compared to load_i915kms=3D"yes", > but the kernel will be loaded faster. >=20 > Thank you! >=20 > --=20 > Jean-S??bastien P??dron >=20 --5587ow7Bqi7FXI0s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUEWFfAAoJEJDCuSvBvK1B/0wP/jLw/xA7WevZcNjSHGbvNX/9 jO2dcppMxQUVUeoCCxMtx9xgSoC3UlcXuDSXQi4+IxQZ0RNmGUIUwjRd0SsueSE9 /Mu9KY5yNgMLjDuRlDMquTDw4f03lz9w0wPl5GOHUerJ7dFkmsxc1u8qq6HhX3Am 9cyg3SSDlBeUFlXAl/HhlpNzuMQSKLZjt/hYi985SCFjQ0zhyC2nz/OU5FZxszHc e6u6ZDXZh/UfH1jkPaWZiIn0RO0J8GopyH/E1pEV3iloxvbJzVA04xMkk5g6ycCY 7zImrPbylDc7LRhHGzJ4l7+OeMCm+svPhbHdYoz/XcmwB/hvkV6APWwpqGLJNe20 KeT/2Ac/0+Dy12UCm48apFrxGAOQ1j8H6zEM1xXmKKtPw0iy2eAuHOpu8HzN18AR KMRVz8/N996X5VLhF7wKUTn83MwCqoCPWoOfgphMvE1Id05ULaDBkg+aUbdDOQeM ulIIpoJAk+eK+GpnmDQV6uaGSoytFUXuTzZKhSGQ+iOlF4cp/Bg/ok7D/8aIRnpF OECOFSMt7bnGJqeKbokhpbfO3NTM4CyMv691LChnAoh4iai6fi569XF4RpHTL6Oz dqfrhAZ1NSv3FLsrzupFD04pZYhUvWIUWZz4iKBndk9p/Z/gGTlhflr7LDSGKwzo 9rGzSENWamO3zMHISTDk =1OWY -----END PGP SIGNATURE----- --5587ow7Bqi7FXI0s-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 09:06:08 2014 Return-Path: Delivered-To: freebsd-stable@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 E0C01762; Thu, 11 Sep 2014 09:06:08 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 A6658678; Thu, 11 Sep 2014 09:06:08 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XS0KJ-000NSw-OK; Thu, 11 Sep 2014 09:06:03 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XS0KJ-000Hhc-Lu; Thu, 11 Sep 2014 10:06:03 +0100 Date: Thu, 11 Sep 2014 10:06:03 +0100 To: se@freebsd.org, freebsd-stable@freebsd.org, ari@ish.com.au Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> In-Reply-To: <54100258.2000505@freebsd.org> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Pete French X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 09:06:09 -0000 > This may never hit you, but ZFS is built on the assumption, that it > cannot happen at all, which is no longer true with 4KB drives that > are used with ashift=9. Have just been reading this thread, and as people are suggesting moving ashift from 9 to 12, doesnt using use 512B drives with ahift=12 also violate this ? Or is it smart enough ot know that the underlying sectors are separate ? -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 09:17:34 2014 Return-Path: Delivered-To: freebsd-stable@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 D4BEBA5F for ; Thu, 11 Sep 2014 09:17:34 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 9C9347BB for ; Thu, 11 Sep 2014 09:17:34 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XS0VQ-000OId-NW; Thu, 11 Sep 2014 09:17:32 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XS0VQ-000HsK-Kf; Thu, 11 Sep 2014 10:17:32 +0100 To: freebsd-stable@freebsd.org, jean-sebastien.pedron@dumbbell.fr Subject: Re: Is it possible to get xf86-video-ati-7.2 added to the new_xorg pkg repository ? In-Reply-To: <54102FE8.7060301@dumbbell.fr> Message-Id: From: Pete French Date: Thu, 11 Sep 2014 10:17:32 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 09:17:34 -0000 > A fix for this bug for finally committed in the ports tree (r367808). > > Thank you for your patience :) Thanks, I can see it there now ;) This will therefore preseukabky eng up in the new_xorg pkg repository automaticly in due course then ? -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 09:52:10 2014 Return-Path: Delivered-To: freebsd-stable@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 CC316345 for ; Thu, 11 Sep 2014 09:52:10 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 39F97B5B for ; Thu, 11 Sep 2014 09:52:10 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s8B9q1WV007907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 11 Sep 2014 19:52:01 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1410429122; bh=FQenigsF/xm/k3cz93Ff+zp5rpLjxXj2UhhkRrIk9f4=; h=Date:From:To:Subject:References:In-Reply-To; b=o875i7B4sCeiI/XAlm76RSxY3ohHtL8PaYiRRTDXKeRTdT6zaxtCfEBkNdt315Mhm /tjfTgv4331sIsxlV0sr9x9S2G1eyXqtEZxTlmBZK8oLLR7RSvjgaZ0/lFjL+w6WHH 3nNVWKDQrP2RnPZTFniSrkIAnjGw6CCMk4jF7LYs= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s8B9ps5c007896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 11 Sep 2014 19:51:58 +1000 (AEST) Date: Thu, 11 Sep 2014 19:51:54 +1000 From: John Marshall To: freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers Message-ID: <20140911095154.GA18182@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20140911084624.GK2737@kib.kiev.ua> OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 09:52:11 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 11 Sep 2014, 11:46 +0300, Konstantin Belousov wrote: > On Thu, Sep 11, 2014 at 10:28:26AM +0200, Jean-S??bastien P??dron wrote: > > On 11.09.2014 08:47, John Marshall wrote: > > > I cannot find any kernel device configuration statements for drm2 or = KMS > > > (e.g. i915kms) drivers in any of the NOTES files in 10-STABLE. > > > Presumably configurtation statements for these ought to be available = for > > > use in kernel configuration files for 10.1-RELEASE? > >=20 > > Currently, building DRM drivers into the kernel isn't supported. I guess > > it's mostly a lack of time and demand. > I did not added file list to the static kernel config due to display > becoming blank after the driver initialization, which is very early > for the syscons setup. Might be, since vt is functional, this may > be reconsidered. That's fair enough if the drivers are deemed to be not yet production-ready. I am guessing that NEW_XORG will be delivered as default for 10.1-RELEASE just like it was for 9.3-RELEASE, so lots more desktop users (unless they explicitly disable NEW_XORG) will find themselves using these drivers. > Driver initialization was never tested when loaded from loader, I > have no idea how i915 starts up with interrupts still disabled. The console display goes blank for several seconds and then comes to life with the smaller font and the backlog of dmesg output displayed. Perhaps I am doing all the wrong things. I just assumed these new drivers were functional replacements for drm and i915drm which could be included in a custom kernel. --=20 John Marshall --huq684BweRXVnRxX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQRcLoACgkQw/tAaKKahKLalACgjmWKcO4HYSapfjWikn0Qqlt1 +K4An33psjsle/HhTn8xw4ayhBp777LN =USOE -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 10:23:45 2014 Return-Path: Delivered-To: freebsd-stable@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 4FD98813; Thu, 11 Sep 2014 10:23:45 +0000 (UTC) Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) (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 10F3FE4A; Thu, 11 Sep 2014 10:23:44 +0000 (UTC) Received: from fwd41.aul.t-online.de (fwd41.aul.t-online.de [172.20.27.139]) by mailout05.t-online.de (Postfix) with SMTP id 458342F3EE8; Thu, 11 Sep 2014 12:15:12 +0200 (CEST) Received: from [192.168.119.33] (Z2Y7HEZSQhTTO-cHNDhxYwOHGdpJcP7ySyv-wKzQihgWZ6EcXFMuZOsPZBFMn5XwAr@[84.154.101.219]) by fwd41.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XS1PB-02Mq7E0; Thu, 11 Sep 2014 12:15:09 +0200 Message-ID: <54117624.7020907@freebsd.org> Date: Thu, 11 Sep 2014 12:15:00 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Pete French , freebsd-stable@freebsd.org, ari@ish.com.au Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: Z2Y7HEZSQhTTO-cHNDhxYwOHGdpJcP7ySyv-wKzQihgWZ6EcXFMuZOsPZBFMn5XwAr X-TOI-MSGID: 8e61d911-2878-458c-8f90-c4c2339b0d0b X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 10:23:45 -0000 Am 11.09.2014 um 11:06 schrieb Pete French: >> This may never hit you, but ZFS is built on the assumption, that it >> cannot happen at all, which is no longer true with 4KB drives that >> are used with ashift=9. > > Have just been reading this thread, and as people are suggesting > moving ashift from 9 to 12, doesnt using use 512B drives with > ahift=12 also violate this ? Or is it smart enough ot know that > the underlying sectors are separate ? There is no problem, if ashift covers more than 1 sector, except that you waste some space. If ashift=12 is used with 512 byte sectors, then all writes will be to 8 consecutive sectors. There is no read-modify-write as in the opposite case (ashift=9 with 4K sectors). But the amount of wasted space can be quite substantial. I have read reports of some 8% less usable space with ashift=12 compared to ashift=9, for an empty ZFS file system. And with lots of small files, this will become worse, once the file system is filled. With RAIDZ, the effective allocation unit is not the minimum size block (as determined by ashift), but that value multiplied by the number of data drives without parity (e.g. 2*512 / 2*4K for a 3 drive raidz1, 4*512 / 4*4K for a 5 drive raidz1). This leads to an effective smallest allocation unit of 16 KByte on a 5 drive raidz1 with ashift=12, vs. 2 KByte with ashift=9. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 10:46:54 2014 Return-Path: Delivered-To: freebsd-stable@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 42B7EF52; Thu, 11 Sep 2014 10:46:54 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 0A019E0; Thu, 11 Sep 2014 10:46:54 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XS1tq-0005Nc-Fg; Thu, 11 Sep 2014 10:46:50 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XS1tq-000IW6-DB; Thu, 11 Sep 2014 11:46:50 +0100 To: ari@ish.com.au, freebsd-stable@freebsd.org, petefrench@ingresso.co.uk, se@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS In-Reply-To: <54117624.7020907@freebsd.org> Message-Id: From: Pete French Date: Thu, 11 Sep 2014 11:46:50 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 10:46:54 -0000 > There is no problem, if ashift covers more than 1 sector, except > that you waste some space. If ashift=12 is used with 512 byte > sectors, then all writes will be to 8 consecutive sectors. There > is no read-modify-write as in the opposite case (ashift=9 with 4K > sectors). But what if one of those 8 writes fails ? ZFS understands that part of a write can fail then ? or does it think of it as 8 separate writes ? > But the amount of wasted space can be quite substantial. I have > read reports of some 8% less usable space with ashift=12 compared > to ashift=9, for an empty ZFS file system. And with lots of small > files, this will become worse, once the file system is filled. Yes, I have migrated a lot of filesystems over to 4k, and there is quite a lot of extra space taken up by the same amount of data - even wth lz4 compression enabled, which I do on most systems. However the extra performance is well worth it. Only reason I am asking is that I am thinking of migrating a zpool which only has one 4k drive in it, plsy 3 512byte ones. Just want to make sure that it is not a bad idea to do this. -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 12:33:05 2014 Return-Path: Delivered-To: freebsd-stable@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 0EEB8897 for ; Thu, 11 Sep 2014 12:33:05 +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 C3CC1274 for ; Thu, 11 Sep 2014 12:33:04 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XS3Yd-0006zY-0M for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 14:33:03 +0200 Message-ID: <54119677.8090607@dumbbell.fr> Date: Thu, 11 Sep 2014 14:32:55 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> In-Reply-To: <20140911084624.GK2737@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5U63SKrv4VBV4Rkp1ewVuOGiPNju4cmUg" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:33:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5U63SKrv4VBV4Rkp1ewVuOGiPNju4cmUg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11.09.2014 10:46, Konstantin Belousov wrote: > I did not added file list to the static kernel config due to display > becoming blank after the driver initialization, which is very early > for the syscons setup. You're right, I totally forgot the problem with syscons... That makes perfect sense :) > Driver initialization was never tested when loaded from loader, I > have no idea how i915 starts up with interrupts still disabled. After the addition of vt(4), several users started to load i915kms and radeonkms from the loader and this works for them. --=20 Jean-S=E9bastien P=E9dron --5U63SKrv4VBV4Rkp1ewVuOGiPNju4cmUg 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 iQJ8BAEBCgBmBQJUEZZ+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMOCgP/jyIqFWQ3I/h2jYeWLQwSt5P VWYd2dMm0AILn6bfhUvu6yyzO65VP5fW6Jeibn4SEjpS1dEd0VqE4VYMadvWTGzn hpoiVCLGMvmbgG7TCnmA5b00mOHldgEnJSIwBo/vjTZ7m/gUCDltD8PlheE2UWBK 8o95tgrMJe2k2tqRehdb5XGOYxcB/65aJ/O1hG32PanStaQjSG8R1finG1mUqleO mvHDvXWKXxZ95BBhSkzhFW9x1+EtplhZMdyTHFnXesDv8BiWUGCnFBa9E56cAC7+ fe217+Wo2nU5x6Ck8sHAL0a5nDxay074uObcBzLWt5gmuH2a27NUKw1DGOPEl/RI +Yhi3ePYA3nOT9ST9bicv3G6s8z8qu4as2fCZUWJaYT6NwKbl0UM/dRzrZTXodQ8 YvGJ0qouwXn+bh1bVPvnt8aNM/6+2AI+i/NuNToFnO9hqNC1cpqdpInjQyt4GQQl r06W1cObE0srK2gcaYf5XiK+QqkSZXd388mtcM1gzxjY8vFBpRaAGlmxV4Ane6ZD KNjP/YufvJFIgcuDB7odGs6l/4PPc6bimBxEtxxGOKuBLVsM5fDUaWR/kTMgunJr 3plDsmN3ukAdvJog7vvAtwKLlUC/gCo5f8llLlwzQHD4eHOvpDzddUZHVRxqalYQ cetOZlSNrUzInW6b0+5O =Wvku -----END PGP SIGNATURE----- --5U63SKrv4VBV4Rkp1ewVuOGiPNju4cmUg-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 12:34:36 2014 Return-Path: Delivered-To: freebsd-stable@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 B2094B1B for ; Thu, 11 Sep 2014 12:34:36 +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 732F52B6 for ; Thu, 11 Sep 2014 12:34:36 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XS3a6-0006zv-OQ for freebsd-stable@freebsd.org; Thu, 11 Sep 2014 14:34:34 +0200 Message-ID: <541196DA.9050501@dumbbell.fr> Date: Thu, 11 Sep 2014 14:34:34 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Is it possible to get xf86-video-ati-7.2 added to the new_xorg pkg repository ? References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7aNO2EAFCFUNO7FI9EFCjbMkgOededtlE" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:34:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7aNO2EAFCFUNO7FI9EFCjbMkgOededtlE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11.09.2014 11:17, Pete French wrote: > This will therefore preseukabky eng up in the new_xorg pkg repository > automaticly in due course then ? Yes, it'll be part of the next build, next Wednesday. --=20 Jean-S=E9bastien P=E9dron --7aNO2EAFCFUNO7FI9EFCjbMkgOededtlE 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 iQJ8BAEBCgBmBQJUEZbaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMjlQP/36ygj55GmiYTFhevmbbuCWI EiFACwzUcv7tvyQn4wTQpfZ4/6NoCcgdUklTWLrTWZ9DR/F2+aCS/AG+q0AjyBX6 rr1SuER1/wxSvqIv4YW7F8TVSb9Io7ll/1eibuw5X2ztHIaRLyggQsC5WPKiDz8+ b0EVr7nZE2Jc/qCrUZasf88KUr0Qn0XKVaG/Buaa2cF8CTiVRYQLJEaXi1wX8kUR ZMVVwDHZQLOp3+0R3bpZ2AVFQB51ywt+mrKy5g5zbGDCJF3PIgoznV4iQr9jNQmz 034WVzf4PILA1NhOVOQEbCCMpq+FmAvBnpqknsXG/JkCOxH38QnjyVdpu9vMfNIw lnuMiR95NPCLOTgZhCBzyU5Bkr06+VVKXgAuCNIMp6CHysPSCSk8kBzBYBut8LlM C1OGzUCqAyGmr+k8mNY6QwG/kHm251bS9L2pvfgwryOCcdxunhwKdQ9zTLlWJN0w ZUMNTY6Igg2Yd0zFlsPsBDSVqWBTSr8U6qIg/N/6do6AUGgdrCvGkLaOvJmnGtHe KriVnFNOKIrTSGjKXtr0b+hNXnn8OkUsMTb1pf9SAOi9KaGjALEa9DMT0ngUjCET U1gq9vdKqNR76z2mDesT45h7N4Z2HD8CKG5NftU3gPAOjzXth5+Rdyplv1C79Wrd +4LC91G3VPRS9rp+ldLZ =00Xt -----END PGP SIGNATURE----- --7aNO2EAFCFUNO7FI9EFCjbMkgOededtlE-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 13:30:42 2014 Return-Path: Delivered-To: freebsd-stable@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 9470C169 for ; Thu, 11 Sep 2014 13:30:42 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B935BBB for ; Thu, 11 Sep 2014 13:30:41 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s8BDUTZO006774 for ; Thu, 11 Sep 2014 08:30:29 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Thu Sep 11 08:30:29 2014 Message-ID: <5411A3EE.4040202@denninger.net> Date: Thu, 11 Sep 2014 08:30:22 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030001000802070007020408" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 13:30:42 -0000 This is a cryptographically signed message in MIME format. --------------ms030001000802070007020408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 9/11/2014 4:06 AM, Pete French wrote: >> This may never hit you, but ZFS is built on the assumption, that it >> cannot happen at all, which is no longer true with 4KB drives that >> are used with ashift=3D9. > Have just been reading this thread, and as people are suggesting > moving ashift from 9 to 12, doesnt using use 512B drives with > ahift=3D12 also violate this ? Or is it smart enough ot know that > the underlying sectors are separate ? > No, because in order for the "write" (as ZFS sees it) to succeed all of=20 them must succeed. The problem comes when the *drive* (or controller) does a=20 read-replace-write, because ZFS is unaware of the underlying act and=20 "silent" corruption can thus (at least theoretically) happen. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms030001000802070007020408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTExMzMwMjJaMCMGCSqGSIb3DQEJBDEW BBQQUUg8MuFmGWyQzjUqaT5vcMEiKjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAPFTlvZyoC5rTy3uOgywknoe7+nzT kh7E3y1tY1j5EWlehsggWCsYaclRrSgGKAlsxjaAmFm2Kz+CruhncHS0ZUTDPjObUUdM8fsj urX94zIAE3ugRNKP3d+KVUv1GB9KG7NBSH/WfgiCXwmgFjf1koyNIEgeLTme5AYiYj+ALcfd b3sQaddqnMJMk4Ko/NMQh0zikkRB9w1CaSERHWyLH2gY8P0NJXP9sCPKId4gANf2FiMeDhzU K98/gMKhCHsngXauetCTDbGZQRuQJfsTS2fqPqfyJwez5yU0aZRE5wUp8LJQuqtXyCcwbKtI mCNogi77teBYkDq4mnRXmR9l2GFpRynG4VUBjQ8fb9eoPuYolj1a/GleD2taTi8nrrWI3VSS 5S38dSPKlIgDDmpcxmfQgwoGcEEZg7kyIcCg/Yg2pTndcZtXvnhU8ZObxV8uywCxcbj0K4VD CzswW+93eA/3FcYeNj/Az2iIIJUcoutKZedujk5e58C4RDn5m5eBtFRcMGMeqSs7nnB4CVwn HF708wjKE9WiFWBYZgkTOWBtZJaIhIfPdpmcDKL2DfojbU3NxtYN1FZm0FU0FcKtAQcigJS/ 2RWmYP/5/mwCcXsbHBPpRKIoLnWhNy3PKEL65IWCbleKYljHMtzSccC/k9qaBExtz9u8vYV6 wa+8bP4AAAAAAAA= --------------ms030001000802070007020408-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 14:18:30 2014 Return-Path: Delivered-To: freebsd-stable@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 B1494999 for ; Thu, 11 Sep 2014 14:18:30 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 741EB1B0 for ; Thu, 11 Sep 2014 14:18:30 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8BEIK1b004117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 11 Sep 2014 09:18:20 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <5411AF2C.6080002@tundraware.com> Date: Thu, 11 Sep 2014 09:18:20 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10-STABLE Buildworld Failing References: <54109820.1030905@tundraware.com> <54109CA5.7050807@tundraware.com> <5410D4D7.8060906@tundraware.com> <201409110108.s8B18I6b002865@dyslexicfish.net> In-Reply-To: <201409110108.s8B18I6b002865@dyslexicfish.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Thu, 11 Sep 2014 09:18:20 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8BEIK1b004117 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:18:30 -0000 On 09/10/2014 08:08 PM, Jamie Landeg-Jones wrote: > Tim Daneliuk wrote: > >> Well something has definitely changed of late. Not only do I now have >> to cleanup the env variable with proper quoting, > > You say that as if it's a bad thing! Well, no, it's not a bad thing. What is a bad thing is unexplained sudden changes in system behavior. In this case the inability to use parallelized makes for buildworld and kernels (I used to use -j8, now no parallelization level works reliably) is more than tripling compliation time. ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 15:15:58 2014 Return-Path: Delivered-To: freebsd-stable@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 11967E33 for ; Thu, 11 Sep 2014 15:15:58 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D07CFA95 for ; Thu, 11 Sep 2014 15:15:57 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wn1so14592060obc.30 for ; Thu, 11 Sep 2014 08:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8PRwfc412ez9sGrWOe0f+60o3j/oMwKtBs1coLTkT3Q=; b=tUmEroXAVaLAZbcYpYfr18xxAyPm0gCZv9PAPXcTtK2bnNe+NeOsaefBjRPIDcwan8 GXn4vFWtKiEKhuOacOdFqEgGxgaNV7jvMrsPGIT7YXtPDh9kcUqfk1G8LF199OiKWvcV 3m3hF1rZiwlOe6SjKd4KY35ZWZr2HHfiTDTSl1X5Rb4K5zxbEa7clCdNrJGu604Ykf37 iBDzhtFk0pzxxryO+/1lNGV4Ymxq9+Ybjwqt3peNXHc4+cQl2iw1TmgFFfla15W9OdMH mbrnP6ks6rA3QWmefZD91ozFQ7OSflU10tkYnJXFZdAAsCU0x3Q5rGsxpQWQd3mitIly 7nqA== MIME-Version: 1.0 X-Received: by 10.60.130.170 with SMTP id of10mr2061177oeb.10.1410448557024; Thu, 11 Sep 2014 08:15:57 -0700 (PDT) Received: by 10.202.199.11 with HTTP; Thu, 11 Sep 2014 08:15:56 -0700 (PDT) Date: Thu, 11 Sep 2014 08:15:56 -0700 Message-ID: Subject: Using CARP with multiple IP aliases (FBSD 10.0) From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:15:58 -0000 Good morning, Just looking for some clarification around the proper use of CARP on interfaces with multiple IPs. I've been using the new CARP on FreeBSD 10.0 with great success on a pair of systems with lots of vlans across 3 physical NIC ports. However, those systems only have a single IP per vlan. The ifconfig lines are very simple, and everything just works the way I expect it to, failing back and forth between the two systems as needed. I'm now trying to get CARP working on a second pair of systems, and running into issues with one of the physical interfaces. I think I might be doing the ifconfig commands wrong, but the ifconfig(8) and carp(4) man pages aren't very clear on this usage. Are all of the carp-related parameters required for every IP alias added to an interface? Or are the pass/advbase/advskew only needed once per interface, and you just pass the vhid to each IP alias? Currently, I'm doing the former and having issues with both boxes claiming to be master for that one interface. Which is correct: ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass ifconfig igb0 inet 1.2.3.5/32 vhid 30 pass mypass alias ifconfig igb0 inet 1.2.3.6/32 vhid 30 pass mypass alias ifconfig igb0 inet 1.2.3.7/32 vhid 30 pass mypass alias ifconfig igb0 inet 1.2.3.8/32 vhid 30 pass mypass alias OR ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass ifconfig igb0 inet 1.2.3.5/32 vhid 30 alias ifconfig igb0 inet 1.2.3.6/32 vhid 30 alias ifconfig igb0 inet 1.2.3.7/32 vhid 30 alias ifconfig igb0 inet 1.2.3.8/32 vhid 30 alias Neither the ifconfig nor the carp man pages show examples with multiple IPs configured within the same vhid. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 15:54:36 2014 Return-Path: Delivered-To: freebsd-stable@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 5166F17B for ; Thu, 11 Sep 2014 15:54:36 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 138A5EF5 for ; Thu, 11 Sep 2014 15:54:35 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 95FC420E7088D; Thu, 11 Sep 2014 15:54:28 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 39B0020E7088B; Thu, 11 Sep 2014 15:54:27 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Freddie Cash" , "FreeBSD Stable" References: Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) Date: Thu, 11 Sep 2014 16:54:35 +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-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:54:36 -0000 ----- Original Message ----- From: "Freddie Cash" To: "FreeBSD Stable" Sent: Thursday, September 11, 2014 4:15 PM Subject: Using CARP with multiple IP aliases (FBSD 10.0) > Good morning, > > Just looking for some clarification around the proper use of CARP on > interfaces with multiple IPs. > > I've been using the new CARP on FreeBSD 10.0 with great success on a pair > of systems with lots of vlans across 3 physical NIC ports. However, those > systems only have a single IP per vlan. The ifconfig lines are very > simple, and everything just works the way I expect it to, failing back and > forth between the two systems as needed. > > I'm now trying to get CARP working on a second pair of systems, and running > into issues with one of the physical interfaces. I think I might be doing > the ifconfig commands wrong, but the ifconfig(8) and carp(4) man pages > aren't very clear on this usage. > > Are all of the carp-related parameters required for every IP alias added to > an interface? Or are the pass/advbase/advskew only needed once per > interface, and you just pass the vhid to each IP alias? > > Currently, I'm doing the former and having issues with both boxes claiming > to be master for that one interface. > > Which is correct: > > ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass > ifconfig igb0 inet 1.2.3.5/32 vhid 30 pass mypass alias > ifconfig igb0 inet 1.2.3.6/32 vhid 30 pass mypass alias > ifconfig igb0 inet 1.2.3.7/32 vhid 30 pass mypass alias > ifconfig igb0 inet 1.2.3.8/32 vhid 30 pass mypass alias > > OR > > ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass > ifconfig igb0 inet 1.2.3.5/32 vhid 30 alias > ifconfig igb0 inet 1.2.3.6/32 vhid 30 alias > ifconfig igb0 inet 1.2.3.7/32 vhid 30 alias > ifconfig igb0 inet 1.2.3.8/32 vhid 30 alias > > Neither the ifconfig nor the carp man pages show examples with multiple IPs > configured within the same vhid. I believe you need a seperate vhid per IP assuming you want each to fail over to another machine when it goes down e.g. ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass ifconfig igb0 inet 1.2.3.5/32 vhid 31 pass mypass alias ifconfig igb0 inet 1.2.3.6/32 vhid 32 pass mypass alias ifconfig igb0 inet 1.2.3.7/32 vhid 33 pass mypass alias ifconfig igb0 inet 1.2.3.8/32 vhid 34 pass mypass alias Regards Steve From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 16:24:53 2014 Return-Path: Delivered-To: freebsd-stable@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 524478E2 for ; Thu, 11 Sep 2014 16:24:53 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 169ED26E for ; Thu, 11 Sep 2014 16:24:53 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id m8so383323obr.4 for ; Thu, 11 Sep 2014 09:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bRSgO5lnvNjdWkhUZWV8TNlVdOvDaQSNIpOQMZ8tMT0=; b=tpyBYLQ/ki7d9m5l8ujSuLjO/OqY6uE9v1x3hCFLv58hCeAF6Sy/Np0OUmtnZqKYIV DxumkyGluvtq+BNUFFYjxRgK4Dg9Fur08hcoasMVp1AXQOcJQc/A4L2K1kiR4PTGOclN 8mcT0bQrVMnXlcM/5rRuWrfThdgN4dl6C5gHyRB5FXLys6Sn3H6+v5XzlYF9oieKE4My o4pESQGVixnS0UdIcORDik8MP/uFtlHGRo1a89uFEIw/ooPzVSSrmkiVqu70EWE95Jzy hHXphl8jjEKToIKWE4TORGp5mUSDDk2L0HlbEpuKj32X1Q+E89tAZVELW0rAxQTl/0RZ 2bYg== MIME-Version: 1.0 X-Received: by 10.182.236.65 with SMTP id us1mr2489543obc.38.1410452692317; Thu, 11 Sep 2014 09:24:52 -0700 (PDT) Received: by 10.202.199.11 with HTTP; Thu, 11 Sep 2014 09:24:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Sep 2014 09:24:52 -0700 Message-ID: Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) From: Freddie Cash To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:24:53 -0000 On Thu, Sep 11, 2014 at 8:54 AM, Steven Hartland wrote: > > I believe you need a seperate vhid per IP assuming you want each to fail > over > to another machine when it goes down e.g. > ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass > ifconfig igb0 inet 1.2.3.5/32 vhid 31 pass mypass alias > ifconfig igb0 inet 1.2.3.6/32 vhid 32 pass mypass alias > ifconfig igb0 inet 1.2.3.7/32 vhid 33 pass mypass alias ifconfig igb0 inet 1.2.3.8/32 vhid 34 pass mypass alias > =E2=80=8BThat's what I'm trying to avoid. :) And everything appears to ge= t added to the interf=E2=80=8B ace correctly: [fcash@myhost ~]$ ifconfig igb0 igb0: flags=3D8943 metric 0 mtu 1500 options=3Dbb ether a0:36:9f:34:90:f7 inet x.y.z.130 netmask 0xffffffff broadcast x.y.z.130 vhid 30 inet6 fe80::a236:9fff:fe45:80e8%igb0 prefixlen 64 scopeid 0x2 inet x.y.z.251 netmask 0xffffff80 broadcast x.y.z.255 inet x.y.z.134 netmask 0xffffffff broadcast x.y.z.134 vhid 30 inet x.y.z.175 netmask 0xffffffff broadcast x.y.z.175 vhid 30 inet x.y.z.131 netmask 0xffffffff broadcast x.y.z.131 vhid 30 inet x.y.z.132 netmask 0xffffffff broadcast x.y.z.132 vhid 30 inet x.y.z.133 netmask 0xffffffff broadcast x.y.z.133 vhid 30 inet x.y.z.135 netmask 0xffffffff broadcast x.y.z.135 vhid 30 inet x.y.z.136 netmask 0xffffffff broadcast x.y.z.136 vhid 30 inet x.y.z.137 netmask 0xffffffff broadcast x.y.z.137 vhid 30 inet x.y.z.138 netmask 0xffffffff broadcast x.y.z.138 vhid 30 inet x.y.z.140 netmask 0xffffffff broadcast x.y.z.140 vhid 30 inet x.y.z.223 netmask 0xffffffff broadcast x.y.z.223 vhid 30 inet x.y.z.141 netmask 0xffffffff broadcast x.y.z.141 vhid 30 inet x.y.z.142 netmask 0xffffffff broadcast x.y.z.142 vhid 30 inet x.y.z.144 netmask 0xffffffff broadcast x.y.z.144 vhid 30 inet x.y.z.145 netmask 0xffffffff broadcast x.y.z.145 vhid 30 inet x.y.z.146 netmask 0xffffffff broadcast x.y.z.146 vhid 30 inet x.y.z.150 netmask 0xffffffff broadcast x.y.z.150 vhid 30 inet x.y.z.154 netmask 0xffffffff broadcast x.y.z.154 vhid 30 inet x.y.z.159 netmask 0xffffffff broadcast x.y.z.159 vhid 30 inet x.y.z.160 netmask 0xffffffff broadcast x.y.z.160 vhid 30 inet x.y.z.161 netmask 0xffffffff broadcast x.y.z.161 vhid 30 inet x.y.z.162 netmask 0xffffffff broadcast x.y.z.162 vhid 30 inet x.y.z.163 netmask 0xffffffff broadcast x.y.z.163 vhid 30 inet x.y.z.164 netmask 0xffffffff broadcast x.y.z.164 vhid 30 inet x.y.z.165 netmask 0xffffffff broadcast x.y.z.165 vhid 30 inet x.y.z.166 netmask 0xffffffff broadcast x.y.z.166 vhid 30 inet x.y.z.169 netmask 0xffffffff broadcast x.y.z.169 vhid 30 inet x.y.z.171 netmask 0xffffffff broadcast x.y.z.171 vhid 30 inet x.y.z.172 netmask 0xffffffff broadcast x.y.z.172 vhid 30 inet x.y.z.177 netmask 0xffffffff broadcast x.y.z.177 vhid 30 inet x.y.z.178 netmask 0xffffffff broadcast x.y.z.178 vhid 30 inet x.y.z.179 netmask 0xffffffff broadcast x.y.z.179 vhid 30 inet x.y.z.181 netmask 0xffffffff broadcast x.y.z.181 vhid 30 inet x.y.z.188 netmask 0xffffffff broadcast x.y.z.188 vhid 30 inet x.y.z.189 netmask 0xffffffff broadcast x.y.z.189 vhid 30 inet x.y.z.190 netmask 0xffffffff broadcast x.y.z.190 vhid 30 inet x.y.z.191 netmask 0xffffffff broadcast x.y.z.191 vhid 30 inet x.y.z.192 netmask 0xffffffff broadcast x.y.z.192 vhid 30 inet x.y.z.193 netmask 0xffffffff broadcast x.y.z.193 vhid 30 inet x.y.z.194 netmask 0xffffffff broadcast x.y.z.194 vhid 30 inet x.y.z.195 netmask 0xffffffff broadcast x.y.z.195 vhid 30 inet x.y.z.196 netmask 0xffffffff broadcast x.y.z.196 vhid 30 inet x.y.z.197 netmask 0xffffffff broadcast x.y.z.197 vhid 30 inet x.y.z.198 netmask 0xffffffff broadcast x.y.z.198 vhid 30 inet x.y.z.199 netmask 0xffffffff broadcast x.y.z.199 vhid 30 inet x.y.z.200 netmask 0xffffffff broadcast x.y.z.200 vhid 30 inet x.y.z.201 netmask 0xffffffff broadcast x.y.z.201 vhid 30 inet x.y.z.202 netmask 0xffffffff broadcast x.y.z.202 vhid 30 inet x.y.z.222 netmask 0xffffffff broadcast x.y.z.222 vhid 30 inet x.y.z.204 netmask 0xffffffff broadcast x.y.z.204 vhid 30 inet x.y.z.207 netmask 0xffffffff broadcast x.y.z.207 vhid 30 inet x.y.z.208 netmask 0xffffffff broadcast x.y.z.208 vhid 30 inet x.y.z.209 netmask 0xffffffff broadcast x.y.z.209 vhid 30 inet x.y.z.210 netmask 0xffffffff broadcast x.y.z.210 vhid 30 inet x.y.z.215 netmask 0xffffffff broadcast x.y.z.215 vhid 30 inet x.y.z.212 netmask 0xffffffff broadcast x.y.z.212 vhid 30 inet x.y.z.213 netmask 0xffffffff broadcast x.y.z.213 vhid 30 inet x.y.z.205 netmask 0xffffffff broadcast x.y.z.205 vhid 30 inet x.y.z.206 netmask 0xffffffff broadcast x.y.z.206 vhid 30 inet x.y.z.211 netmask 0xffffffff broadcast x.y.z.211 vhid 30 inet x.y.z.214 netmask 0xffffffff broadcast x.y.z.214 vhid 30 inet x.y.z.216 netmask 0xffffffff broadcast x.y.z.216 vhid 30 inet x.y.z.217 netmask 0xffffffff broadcast x.y.z.217 vhid 30 inet x.y.z.219 netmask 0xffffffff broadcast x.y.z.219 vhid 30 inet x.y.z.220 netmask 0xffffffff broadcast x.y.z.220 vhid 30 inet x.y.z.227 netmask 0xffffffff broadcast x.y.z.227 vhid 30 inet x.y.z.228 netmask 0xffffffff broadcast x.y.z.228 vhid 30 inet x.y.z.182 netmask 0xffffffff broadcast x.y.z.182 vhid 30 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active carp: MASTER vhid 30 advbase 1 advskew 1=E2=80=8B =E2=80=8B =E2=80=8BAnd the documentation I read a long time ago hinted that the above= is a valid configuration. I'm just not sure if I'm adding the IPs to the vhid correctly. Are all the parameters needed on every ifconfig invocation, or only the first one? Are the pass/advskew set per vhid, or per IP? If I need to use a separate vhid per IP I can. Just need confirmation that that is how it works. :)=E2=80=8B --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 16:34:51 2014 Return-Path: Delivered-To: freebsd-stable@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 C600DC4E for ; Thu, 11 Sep 2014 16:34:51 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 87EB839A for ; Thu, 11 Sep 2014 16:34:51 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 84CB220E7088D; Thu, 11 Sep 2014 16:34: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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 0473520E7088B; Thu, 11 Sep 2014 16:34:48 +0000 (UTC) Message-ID: <7925563B043E419996CD7FEE8C7DFDB6@multiplay.co.uk> From: "Steven Hartland" To: "Freddie Cash" References: Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) Date: Thu, 11 Sep 2014 17:34:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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 Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:34:51 -0000 ----- Original Message ----- From: "Freddie Cash" To: "Steven Hartland" Cc: "FreeBSD Stable" Sent: Thursday, September 11, 2014 5:24 PM Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) > On Thu, Sep 11, 2014 at 8:54 AM, Steven Hartland > wrote: > >> >> I believe you need a seperate vhid per IP assuming you want each to fail >> over >> to another machine when it goes down e.g. >> ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass >> ifconfig igb0 inet 1.2.3.5/32 vhid 31 pass mypass alias >> ifconfig igb0 inet 1.2.3.6/32 vhid 32 pass mypass alias >> ifconfig igb0 inet 1.2.3.7/32 vhid 33 pass mypass alias > > ifconfig igb0 inet 1.2.3.8/32 vhid 34 pass mypass alias >> > > ​That's what I'm trying to avoid. :) And everything appears to get added > to the interf> > ace correctly: I can't say I've used it in that way and I'm not sure how carp decides how to fail over when it has multiple IP's available. I can confirm you don't need all the params when adding an IP to vhid. so you can for example configure the vhid and then add the IP's or do as you have done and configure it on the first IP. Best thing to do is try it and see. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 16:36:30 2014 Return-Path: Delivered-To: freebsd-stable@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 DB2DED56 for ; Thu, 11 Sep 2014 16:36:30 +0000 (UTC) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94E863CD for ; Thu, 11 Sep 2014 16:36:30 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id CA3599DD03E; Thu, 11 Sep 2014 18:28:44 +0200 (CEST) Subject: Re: getting to 4K disk blocks in ZFS Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="utf8"; X-Pgp-Agent: GPGMail (null) From: Borja Marcos In-Reply-To: <54114217.9040403@denninger.net> Date: Thu, 11 Sep 2014 18:28:36 +0200 Content-Transfer-Encoding: 8bit Message-Id: <68A42E6F-A089-4A3C-A394-C73162B86308@sarenet.es> References: <540FF3C4.6010305@ish.com.au> <54100258.2000505@freebsd.org> <5410F0B4.9040808@ish.com.au> <54114029.3060507@FreeBSD.org> <54114217.9040403@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:36:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 11, 2014, at 8:32 AM, Karl Denninger wrote: It works great until you start replacing older disks with new, larger ones and find out that the new ones are 4k where the old ones were not..... Yes, I agree. The problem is, it can become a time bomb especially for small, modest installations. You build a small server (and maybe you don't have the resources for a full migration readily available) and, one day, two years in the future, one of the disks breaks. You buy a new one, replace, and your performance gets worse. Or, anyway, the timebombs are already in place. As far as I know most new disks sold nowadays are "advanced format". Borja. -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEUEARECAAYFAlQRzbsACgkQULpVo4XWgJ+8RwCfeYowXbeKzs1W2j1ClOux+6wo W5gAl2okA16O2Z9YK8Z/ufwKT1hYpqw= =an3n -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 16:46:46 2014 Return-Path: Delivered-To: freebsd-stable@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 2BD079B for ; Thu, 11 Sep 2014 16:46: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 DA9596AF for ; Thu, 11 Sep 2014 16:46:45 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id E32F420E7088D; Thu, 11 Sep 2014 16:46:44 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 975E220E7088B; Thu, 11 Sep 2014 16:46:43 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Kimmo Paasiala" References: <51AD1F36-1089-481F-8784-8BD8E6EF020F@icloud.com> <71DEB316-3CDD-4403-A397-BCE684725ABD@icloud.com> <25886C53-39C1-47A8-95F7-494FA6E7ABA2@icloud.com> <20140819071045.GS2737@kib.kiev.ua> <99FB0662-1954-4ECB-939B-06D0AA49C1A1@icloud.com> <20140819074643.GU2737@kib.kiev.ua> <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> Subject: Re: ZFS on root booting broken somewhere after r270020 Date: Thu, 11 Sep 2014 17:46:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:46:46 -0000 ----- Original Message ----- From: "Kimmo Paasiala" > I recreated the pool on the second disk as another single disk pool, performed > zfs send -R … | zfs receive -F … > > It works now just fine with the kernel that didn’t work with old pool so there must > have been something seriously broken with the old pool. I also noticed the old pool > kept repeatedly restarting the resilver operations when I tried to expand it into a mirror. > > Case closed for now. Thanks for that Kimmo. For reference I've also tested booting mirrors, including with each disk of the mirror removed and all works as expected. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 17:05:15 2014 Return-Path: Delivered-To: freebsd-stable@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 CDDD0760 for ; Thu, 11 Sep 2014 17:05:15 +0000 (UTC) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9378F8EA for ; Thu, 11 Sep 2014 17:05:15 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id e131so5756142oig.10 for ; Thu, 11 Sep 2014 10:05:14 -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=bWwvRzKHgTrtROA9l+D2AlKNsmMO9SRsaDHqlzaOhIM=; b=z7hgUyYMr3LT/Zn8GnULvIQRz3ZURzL0Vctad/HMCNkz56t3WCPDI+0UX9ygqtkEYO bJ8t32cw3Hhp3gE5Q7kAZ7IqhMfsb3vrCRD6Qe+W3QGZA0Eh9hUG/lJUtkpfpc44g9dJ pNdD7xqrE0E5XltvxOxZ9tA/yoG1ag0ZxLpyDRgDHY+5QzJnvpudKqyAnO9FJRoMrx9O SA4SHIaU1X3TVMItsVvSVkm48PrJ448aUIJBqemLG9VO0FZdJ/q0cTu+eaQXd6SmS4fr bDpYsiKDczOJ+WUYLnIe+lYRo0M4JeBXJr5AqkNPZmDKsBsar6UqUuSw0SVU4mVw2Tzq oTjg== MIME-Version: 1.0 X-Received: by 10.60.130.170 with SMTP id of10mr2802762oeb.10.1410455114393; Thu, 11 Sep 2014 10:05:14 -0700 (PDT) Received: by 10.202.199.11 with HTTP; Thu, 11 Sep 2014 10:05:14 -0700 (PDT) In-Reply-To: <7925563B043E419996CD7FEE8C7DFDB6@multiplay.co.uk> References: <7925563B043E419996CD7FEE8C7DFDB6@multiplay.co.uk> Date: Thu, 11 Sep 2014 10:05:14 -0700 Message-ID: Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) From: Freddie Cash To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 17:05:16 -0000 On Thu, Sep 11, 2014 at 9:34 AM, Steven Hartland wrote: > I can't say I've used it in that way and I'm not sure how carp decides ho= w > to fail over when it has multiple IP's available. > =E2=80=8BI'm hoping, and my testing appears to corroborate, that it fails b= ased on the interface state, and all IPs transfer over at once (CARP systctl set to fail everything at once if any one interface state changes).=E2=80=8B > I can confirm you don't need all the params when adding an IP to vhid. > so you can for example configure the vhid and then add the IP's or do > as you have done and configure it on the first IP. > =E2=80=8BThat's good to hear. Will simplify things a bit.=E2=80=8B > Best thing to do is try it and see. > =E2=80=8BThat's scheduled for tomorrow morning. :) I'll try it first with= only setting pass/advskew on the vhid once, and just adding the alias IPs to the vhid. If that doesn't fix things, then I'll try with a separate vhid per IP. The reason I was asking about this is that I have a pair of systems in place now (sys1 and sys2, with sys1 configured with advskew 1 to make it always master) where everything works wonderfully for between 5 and 15 minutes. If I down an interface on sys1, or physically remove a cable from sys1, everything fails over to sys2 and traffic continues normally.=E2=80=8B =E2=80=8B If I bring the interface back up on sys1, then everything fails = back over to sys1 and traffic continues. After 5-15 minutes, though, igb0 on both boxes switches to master state. :( igb1, igb2, and igb3 on sys2 all stay in backup state. And then traffic slows to a crawl as the upstream switch gets confused and sends packets=E2=80=8B randomly between the two hosts. Manually changing state to backup on igb0 on sys2 fixes things for about 3 seconds, and then it switches back to master. Once this happens, tcpdump on both systems only shows VRRPv2 packets from sys1, nothing from sys2.=E2=80=8B I have to reboot sys2 in order to get th= ings working again. As I said, this is the first time I've used CARP with multiple shared IPs on an interface (NAT firewall), so I may be doing things "wrong" or non-optimally. :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 17:39:24 2014 Return-Path: Delivered-To: freebsd-stable@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 C1637270 for ; Thu, 11 Sep 2014 17:39:24 +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 9F9CABE2 for ; Thu, 11 Sep 2014 17:39:24 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 10703920; Thu, 11 Sep 2014 10:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1410457164; bh=vSqqdHTJ1cKuz5WdKmO0yVDUPpt9pZvuPqceY/uokAI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=c2EXVNJQJMCkVAZYAYIGXP9DhQI3vxv8LhGqsIqQEVXL0CPFA0rws70k4VW/zvGmY BA+tInsbxb1HPg1gjOeMAkHTYfr44pWqkZcmG9fH1/08By5wkDERlcxzpPKih7vqYv ogdS68hNUKokyW+shMPNANiQgop42fqP+Kk5iHg8= From: Peter Wemm To: freebsd-stable@freebsd.org Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) Date: Thu, 11 Sep 2014 10:39:19 -0700 Message-ID: <2401599.spj3ijL0cc@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <7925563B043E419996CD7FEE8C7DFDB6@multiplay.co.uk> References: <7925563B043E419996CD7FEE8C7DFDB6@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2430500.8OADSZRLu4"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 17:39:24 -0000 --nextPart2430500.8OADSZRLu4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday, September 11, 2014 05:34:57 PM Steven Hartland wrote: > ----- Original Message ----- > From: "Freddie Cash" > To: "Steven Hartland" > Cc: "FreeBSD Stable" > Sent: Thursday, September 11, 2014 5:24 PM > Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) >=20 > > On Thu, Sep 11, 2014 at 8:54 AM, Steven Hartland > >=20 > > wrote: > >> I believe you need a seperate vhid per IP assuming you want each t= o fail > >> over > >> to another machine when it goes down e.g. > >> ifconfig igb0 inet 1.2.3.4/24 vhid 30 pass mypass > >> ifconfig igb0 inet 1.2.3.5/32 vhid 31 pass mypass alias > >> ifconfig igb0 inet 1.2.3.6/32 vhid 32 pass mypass alias > >> ifconfig igb0 inet 1.2.3.7/32 vhid 33 pass mypass alias > >=20 > > ifconfig igb0 inet 1.2.3.8/32 vhid 34 pass mypass alias > >=20 > >=20 > > =E2=80=8BThat's what I'm trying to avoid. :) And everything appea= rs to get added > > to the interf> >=20 > > ace correctly: > I can't say I've used it in that way and I'm not sure how carp decide= s how > to fail over when it has multiple IP's available. >=20 > I can confirm you don't need all the params when adding an IP to vhid= . > so you can for example configure the vhid and then add the IP's or do= > as you have done and configure it on the first IP. This is the method we use extensively in the freebsd.org cluster. eg: = the=20 routers have public IP addresses, private RFC1918, IPv6 etc addresses, = all on=20 the same vhid for each interface. * One vhid presence, with multiple aliases on the same vhid. * Configure vhid params once, aliases attached without params. carp state checking uses link local addresses to communicate. Having multiple IP's per vhid means they change master->backup state as= a=20 group, not individually and that's what we wanted for things like route= r=20 default gateways. =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 --nextPart2430500.8OADSZRLu4 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 iQEcBAABAgAGBQJUEd5LAAoJEDXWlwnsgJ4EdIsIAL8a6qOpAosw6YoI0brMN2vU /ymChZSw7NGRYk/PunMAQwCKBGZSQlMImX44l8r5ST0D0I//nFyFi0fA9zCfK0P7 s46IMRuGC4Pd3Mvo4XrLAxxWBwHBqR8QrgNV+WlBxbLoDJ5rlN1VWA9pzVUuUmwD DSijMDO+MppGzX2cLq01082Hg7mAL3VNsSbEZJePALlqEFw15yqyYBImyvm9vEHc F8RIbl7GcmI617/Zxe+nb/OdnymZAJruW2JEXxN+xJvWkhAG6UzoC6RXgFRHq9ZG +vvULVn+rVg0jkTVUNYdhMc6sIEwNJgCJFEsWDXSHmxQXcmxQgycMPXJPPy8T1s= =ybvm -----END PGP SIGNATURE----- --nextPart2430500.8OADSZRLu4-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 17:49:15 2014 Return-Path: Delivered-To: freebsd-stable@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 EE0E1561; Thu, 11 Sep 2014 17:49:14 +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 CC92DCEF; Thu, 11 Sep 2014 17:49:14 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 266AC92A; Thu, 11 Sep 2014 10:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1410457754; bh=3Y6W4uBOmSGtd2GM+ksawxl8f+ezjDKg9sFgv4Sas8w=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=u/OdMNNJXFx0qI7X8PRWzdk6VWNgbru4FOqTCXTFVeY4rO7upHIZbjY17Yd6sfi81 H2o09Nj8vXQDC4XcLMnpaNjqFjkmcQ2MXKWs5aZ7arCdRVaedur1btG2kQbY6XY6x+ 45ktcqvYEvzpJTxVO5rOl4+vsy0f5RsjTxXCL78s= From: Peter Wemm To: freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS Date: Thu, 11 Sep 2014 10:49:13 -0700 Message-ID: <2128347.Ah5i0RTCvp@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <54114029.3060507@FreeBSD.org> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3478197.1yL048MhCC"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: freebsd-stable , Steven Hartland , Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 17:49:15 -0000 --nextPart3478197.1yL048MhCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Thursday, September 11, 2014 09:24:41 AM Andriy Gapon wrote: > On 11/09/2014 04:22, Steven Hartland wrote: > > ----- Original Message ----- From: "Aristedes Maniatis" > >=20 > >> Should the FreeBSD project change this minimum in the next release= ? > >> There seems to be no downside and a huge amount of pain for people= > >> who stumble along with the defaults not knowing what a mess they a= re > >> creating to solve later. > >=20 > > The downside is wasted space which can be significant and hence whe= n > > I last suggested just this it was unfortunately rejected. > >=20 > > We still maintain a local patch to our source tree which does just > > this because, as you've mentioned, we don't want the pain so its > > easier to just run everything as 4k. >=20 > Another downside is 1/4th of uberblocks, 32 vs 128. > Also, automatic sector size detection works great for me and I've nev= er had > a need to manually tweak ashift. Unfortunately, I have. Same drive connected two different ways: da12 at mps1 bus 0 scbus1 target 11 lun 0 da12: Fixed Direct Access SCSI-6 device=20 da12: 600.000MB/s transfers da12: Command Queueing enabled da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=3D0x1<4K> The 4k flag is missing when it's on the sas controller. The Ident stri= ngs are=20 changed. This came up elsewhere recently. =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 --nextPart3478197.1yL048MhCC 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 iQEcBAABAgAGBQJUEeCZAAoJEDXWlwnsgJ4ErUUH/R5qBwI0Yfb3BYNK/Sx5jiqr 7+9pMVEOHAWkj/rPt/2lC6GniQse+sH5I31ArAvx0FGvMWrMWld+yzgQ7QKNjmSQ NK56/cWgt04x3YOwJFcnh2+ul5qUjGc43pnHb7TVdhJaisZvAQOc05DPKEnAG2zg UsKetK4e2ykT9RaHcZeXHSUVt55+1QUk5TfV/l+NB4is8ApPi9IyrLRXkjEq97yX fwpY7RTMf8M4ic1zcE5RHMq55KDylcsXF4E3K/eoWwTpmQunzOt9EbgVmjh8KkDK fWusPCitnOrDYXEV7V44wIntkgpzfwoCMChqo1aap7kdd08xgrx2YGUeIcOMiAE= =X7vO -----END PGP SIGNATURE----- --nextPart3478197.1yL048MhCC-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 18:04:46 2014 Return-Path: Delivered-To: freebsd-stable@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 7C270FBC for ; Thu, 11 Sep 2014 18:04:46 +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 42446EEF for ; Thu, 11 Sep 2014 18:04:46 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id g18so962136oah.35 for ; Thu, 11 Sep 2014 11:04:45 -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=hJpgbhGGxAr59O3MICsuS+7qHCQicQz8jKu7F3Ebcjo=; b=QcDjNsLQiSrqmMZ3R7NT67KBHIu2PPjE7hdJNWftDIMHzLnNd5vMHFRRQRiTEZIPmZ K6X2y1ItSAYf6Q/+qwboHtK18Z6ko//qRG/tEHry/AGDdfOLin3QvDMKJI8zIMgy1PHC oXB5b6yCwa7FmaMW0vnbQM2puX7hyp7BQTNl/JiyRbqNPBeTdypmtU9X4X6FYcgR8Dje Ol/AgXzmb+pjsih83lXpXnlb56iy5zOnJqBVmHBQSLAlwMIFpthM6jl5Wevss6rsQPZJ yg48UqLPxxeKsB+ZmotLd7JyaF2grhKiFeaxtSTUNv3ximLQ/O7LwhxLLqb5RhROQIXZ Da0A== MIME-Version: 1.0 X-Received: by 10.182.153.68 with SMTP id ve4mr3033036obb.60.1410458685567; Thu, 11 Sep 2014 11:04:45 -0700 (PDT) Received: by 10.202.199.11 with HTTP; Thu, 11 Sep 2014 11:04:45 -0700 (PDT) In-Reply-To: <2401599.spj3ijL0cc@overcee.wemm.org> References: <7925563B043E419996CD7FEE8C7DFDB6@multiplay.co.uk> <2401599.spj3ijL0cc@overcee.wemm.org> Date: Thu, 11 Sep 2014 11:04:45 -0700 Message-ID: Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) From: Freddie Cash To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Steven Hartland , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:04:46 -0000 On Thu, Sep 11, 2014 at 10:39 AM, Peter Wemm wrote: > This is the method we use extensively in the freebsd.org cluster. eg: th= e > routers have public IP addresses, private RFC1918, IPv6 etc addresses, al= l > on > the same vhid for each interface. > > * One vhid presence, with multiple aliases on the same vhid. > * Configure vhid params once, aliases attached without params. > > carp state checking uses link local addresses to communicate. > > Having multiple IP's per vhid means they change master->backup state as a > group, not individually and that's what we wanted for things like router > default gateways. > =E2=80=8BExcellent. Thanks for the confirmation. =E2=80=8BI'll be testing the updated configuration tomorrow morning (set al= l vhid params in rc.conf.local, and only set vhid number in firewall scripts when adding IPs). --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 21:14:37 2014 Return-Path: Delivered-To: freebsd-stable@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 25C5B1BB for ; Thu, 11 Sep 2014 21:14:37 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id F40DA6DF for ; Thu, 11 Sep 2014 21:14:36 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id C599B45087 for ; Thu, 11 Sep 2014 21:14:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk C599B45087 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1410470075; bh=WJ0K2zcwj5+hy/yqcZY8ZF7t65SYr5tgZ9g9NfZbGcU=; h=Date:From:To:Subject:References:In-Reply-To; b=wHiQj+OlGvp8Rk8kHsFuR/c9nvf8vKeLnlUtzIiYN/OTYY3C+XZbbURNKIuhX9IIJ N2hiwoCMN7bJ8BaRzh8FQaaIdEa8wJ1n2E6z0dM/vJQfmAF8n2mdemN1KhTLjGLZxx /D7hcJ1/SMLr+QHL/8h0xMpBAHtOSdLvHz2pS3M4= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id EDFD61412F; Thu, 11 Sep 2014 22:14:31 +0100 (BST) Date: Thu, 11 Sep 2014 22:14:31 +0100 From: Ben Morrow To: freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers Message-ID: <20140911211428.GA6247@anubis.morrow.me.uk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54119677.8090607@dumbbell.fr> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 21:14:37 -0000 Quoth =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= : > On 11.09.2014 10:46, Konstantin Belousov wrote: > > > Driver initialization was never tested when loaded from loader, I > > have no idea how i915 starts up with interrupts still disabled. > > After the addition of vt(4), several users started to load i915kms and > radeonkms from the loader and this works for them. I didn't realise it was possible to load radeonkms after boot. Presumably if you do that you lose even more of the boot messages when the new console loads? Currently it appears to lose everything that was above the top of the screen when the new driver loaded; it would be better (if possible) if it were to keep the scrollback as well. Ben From owner-freebsd-stable@FreeBSD.ORG Thu Sep 11 23:32:16 2014 Return-Path: Delivered-To: freebsd-stable@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 AB9F276E; Thu, 11 Sep 2014 23:32:16 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 6B9DB685; Thu, 11 Sep 2014 23:32:15 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 14B671534C4; Fri, 12 Sep 2014 01:32:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrxxrplX4k8e; Fri, 12 Sep 2014 01:32:01 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 61D30153448; Fri, 12 Sep 2014 01:32:01 +0200 (CEST) Message-ID: <541230F1.3060402@digiware.nl> Date: Fri, 12 Sep 2014 01:32:01 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Peter Wemm , freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> In-Reply-To: <2128347.Ah5i0RTCvp@overcee.wemm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Steven Hartland , Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:32:16 -0000 On 11-9-2014 19:49, Peter Wemm wrote: >> Another downside is 1/4th of uberblocks, 32 vs 128. >> Also, automatic sector size detection works great for me and I've never had >> a need to manually tweak ashift. > > Unfortunately, I have. Same drive connected two different ways: > > da12 at mps1 bus 0 scbus1 target 11 lun 0 > da12: Fixed Direct Access SCSI-6 device > da12: 600.000MB/s transfers > da12: Command Queueing enabled > da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) > > ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 > ada1: ATA-8 SATA 3.x device > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) > ada1: quirks=0x1<4K> > > The 4k flag is missing when it's on the sas controller. The Ident strings are > changed. > > This came up elsewhere recently. I reported the same fact for the new set of WD REDs I installed. Seems that ada and da have different quirks tables... So disks on SATA connectors on the motherboard are diagnosed as being 4Kb. The disks on my twa don't get the quirk and are considered 512b --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 05:18:09 2014 Return-Path: Delivered-To: freebsd-stable@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 348F87D6 for ; Fri, 12 Sep 2014 05:18:09 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id B029591A for ; Fri, 12 Sep 2014 05:18:08 +0000 (UTC) Received: from ppp118-210-249-247.lns20.adl6.internode.on.net (HELO leader.local) ([118.210.249.247]) by ipmail05.adl6.internode.on.net with ESMTP; 12 Sep 2014 14:42:57 +0930 Message-ID: <541280D8.9090500@ShaneWare.Biz> Date: Fri, 12 Sep 2014 14:42:56 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> In-Reply-To: <20140911071233.GA50585@anubis.morrow.me.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 05:18:09 -0000 On 11/09/2014 16:42, Ben Morrow wrote: > Quoth Adam McDougall : >> >> Were you running a newer kernel with an older format zpool? I heard >> ixsystems had customers doing that and ran into corruption when they >> tried to modify the zpool in some way (expand? I don't remember). >> http://www.bsdnow.tv/episodes/2014_07_09-zfs_war_stories > > Oh! Might this be what's causing a problem I've been meaning to ask > about? > > My desktop at home is running (a patched, but not anywhere to do with > ZFS) 10-STABLE from a while ago, with a zpool that was created under > 8.2-R and is still at version 15. I have been deliberately not upgrading > it, because I saw no reason to and it seemed safer to leave things as > they were. > > Recently, though, my dump script has started having occasional problems > with snapshots that won't delete. Pending further investigation I have > been renaming them to allow the recursive delete to succeed, and (so > far) rebooting has always made it possible to get rid of them. I have seen that issue with 9.2 and at least one other person mentioned it as well. I currently have a snapshot that I accessed at least 3 weeks ago and renamed to keep rotations working and have not accessed since, it still won't delete as it is busy. I can only delete these snapshots after a reboot. The only cause I know is accessing the snapshot. I can simply ls .zfs/snapshot/daily.01/somefolder to prevent it being deleted. With a manual zfs destroy I get "dataset is busy" and have not found a way to find any process that has hold of it. It seems that some aging of the snapshot needs to happen. Testing a rotate, access, rotate keeps working ok, but access last nights snapshot and then rotate and it blocks. I'm fairly sure that I was running 9.1 when I created this zpool and then later upgraded to 9.2. zpool upgrade says "This system supports ZFS pool feature flags" and "Pool 'zrpleader' already has all supported features enabled". -- FreeBSD - the place to B...Serving Data Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 06:35:15 2014 Return-Path: Delivered-To: freebsd-stable@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 F17D88CD for ; Fri, 12 Sep 2014 06:35:15 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4E7F99 for ; Fri, 12 Sep 2014 06:35:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA21879; Fri, 12 Sep 2014 09:35:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XSKRs-0005Jl-Tm; Fri, 12 Sep 2014 09:35:12 +0300 Message-ID: <541293D0.4080907@FreeBSD.org> Date: Fri, 12 Sep 2014 09:33:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Shane Ambler , freebsd-stable@FreeBSD.org Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> <541280D8.9090500@ShaneWare.Biz> In-Reply-To: <541280D8.9090500@ShaneWare.Biz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 06:35:16 -0000 On 12/09/2014 08:12, Shane Ambler wrote: > On 11/09/2014 16:42, Ben Morrow wrote: >> Quoth Adam McDougall : >>> >>> Were you running a newer kernel with an older format zpool? I heard >>> ixsystems had customers doing that and ran into corruption when they >>> tried to modify the zpool in some way (expand? I don't remember). >>> http://www.bsdnow.tv/episodes/2014_07_09-zfs_war_stories >> >> Oh! Might this be what's causing a problem I've been meaning to ask >> about? >> >> My desktop at home is running (a patched, but not anywhere to do with >> ZFS) 10-STABLE from a while ago, with a zpool that was created under >> 8.2-R and is still at version 15. I have been deliberately not upgrading >> it, because I saw no reason to and it seemed safer to leave things as >> they were. >> >> Recently, though, my dump script has started having occasional problems >> with snapshots that won't delete. Pending further investigation I have >> been renaming them to allow the recursive delete to succeed, and (so >> far) rebooting has always made it possible to get rid of them. > > I have seen that issue with 9.2 and at least one other person mentioned > it as well. I currently have a snapshot that I accessed at least 3 weeks > ago and renamed to keep rotations working and have not accessed since, > it still won't delete as it is busy. I can only delete these snapshots > after a reboot. > > The only cause I know is accessing the snapshot. > I can simply ls .zfs/snapshot/daily.01/somefolder to prevent it being > deleted. With a manual zfs destroy I get "dataset is busy" and have not > found a way to find any process that has hold of it. Look for it in `mount` output. > It seems that some aging of the snapshot needs to happen. Testing a > rotate, access, rotate keeps working ok, but access last nights > snapshot and then rotate and it blocks. > > I'm fairly sure that I was running 9.1 when I created this zpool and > then later upgraded to 9.2. zpool upgrade says "This system supports > ZFS pool feature flags" and "Pool 'zrpleader' already has all supported > features enabled". > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 07:14:04 2014 Return-Path: Delivered-To: freebsd-stable@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 F26BDED2 for ; Fri, 12 Sep 2014 07:14:03 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2C283E2 for ; Fri, 12 Sep 2014 07:14:03 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kx10so613969pab.24 for ; Fri, 12 Sep 2014 00:14:03 -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=Y56uSAqPHEjsnkfrsEyZ2Ge6Xg3SSz7SRud7awLSbew=; b=okFOUTn3aqRMIa1OZULIHXrQCGFQ/jKYYq4i4kz84nL5eQUHZyVOIkXT2Tu7nf1lnr k69icm5apjDMuswOJ2nwC/nV9ncto/cm1yiAAbjU6q+7ND3CXsBkfC+RHYQgT9bAid8k ERJXXGtwUO6cgdcYll2FHQsljdwi6INAeUMm3y5gSqHq22tt7JfhlLZO3VxvzuF5pepJ dV6ptNODPKvaa21eTLdHE0TsH4/ewQI7/A4T0GkSf0zsj1OvEF38VUYktLeuNeg1wZlC u0b9763HDBhdHr+mnb89WHGnfOmph4JDpqnoDwJ1GhuFQPOnXmJiNNvQkdmALiVfmZ85 lJbA== MIME-Version: 1.0 X-Received: by 10.68.109.5 with SMTP id ho5mr9154596pbb.13.1410506043235; Fri, 12 Sep 2014 00:14:03 -0700 (PDT) Received: by 10.70.128.142 with HTTP; Fri, 12 Sep 2014 00:14:03 -0700 (PDT) In-Reply-To: <541280D8.9090500@ShaneWare.Biz> References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> <541280D8.9090500@ShaneWare.Biz> Date: Fri, 12 Sep 2014 02:14:03 -0500 Message-ID: Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] From: Adam Vande More To: Shane Ambler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 07:14:04 -0000 On Fri, Sep 12, 2014 at 12:12 AM, Shane Ambler wrote: > On 11/09/2014 16:42, Ben Morrow wrote: > > Quoth Adam McDougall : > >> > >> Were you running a newer kernel with an older format zpool? I heard > >> ixsystems had customers doing that and ran into corruption when they > >> tried to modify the zpool in some way (expand? I don't remember). > >> http://www.bsdnow.tv/episodes/2014_07_09-zfs_war_stories > > > > Oh! Might this be what's causing a problem I've been meaning to ask > > about? > > > > My desktop at home is running (a patched, but not anywhere to do with > > ZFS) 10-STABLE from a while ago, with a zpool that was created under > > 8.2-R and is still at version 15. I have been deliberately not upgrading > > it, because I saw no reason to and it seemed safer to leave things as > > they were. > > > > Recently, though, my dump script has started having occasional problems > > with snapshots that won't delete. Pending further investigation I have > > been renaming them to allow the recursive delete to succeed, and (so > > far) rebooting has always made it possible to get rid of them. > > I have seen that issue with 9.2 and at least one other person mentioned > it as well. I currently have a snapshot that I accessed at least 3 weeks > ago and renamed to keep rotations working and have not accessed since, > it still won't delete as it is busy. I can only delete these snapshots > after a reboot. > > The only cause I know is accessing the snapshot. > I can simply ls .zfs/snapshot/daily.01/somefolder to prevent it being > deleted. With a manual zfs destroy I get "dataset is busy" and have not > found a way to find any process that has hold of it. What exactly have you tried and what were the results? -- Adam From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 08:17:15 2014 Return-Path: Delivered-To: freebsd-stable@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 56506C8A; Fri, 12 Sep 2014 08:17:15 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 189EEB71; Fri, 12 Sep 2014 08:17:14 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 7584020E7088D; Fri, 12 Sep 2014 08:17:12 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 16C3C20E7088B; Fri, 12 Sep 2014 08:17:11 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Willem Jan Withagen" , "Peter Wemm" , References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> Subject: Re: getting to 4K disk blocks in ZFS Date: Fri, 12 Sep 2014 09:17:19 +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 Cc: Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:17:15 -0000 ----- Original Message ----- From: "Willem Jan Withagen" > On 11-9-2014 19:49, Peter Wemm wrote: >>> Another downside is 1/4th of uberblocks, 32 vs 128. >>> Also, automatic sector size detection works great for me and I've never had >>> a need to manually tweak ashift. >> >> Unfortunately, I have. Same drive connected two different ways: >> >> da12 at mps1 bus 0 scbus1 target 11 lun 0 >> da12: Fixed Direct Access SCSI-6 device >> da12: 600.000MB/s transfers >> da12: Command Queueing enabled >> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >> >> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >> ada1: ATA-8 SATA 3.x device >> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> ada1: Command Queueing enabled >> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >> ada1: quirks=0x1<4K> >> >> The 4k flag is missing when it's on the sas controller. The Ident strings are >> changed. >> >> This came up elsewhere recently. > > I reported the same fact for the new set of WD REDs I installed. > Seems that ada and da have different quirks tables... > So disks on SATA connectors on the motherboard are diagnosed as being 4Kb. > The disks on my twa don't get the quirk and are considered 512b LMK the ident strings and I'll look to update the quirks tables. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 08:19:00 2014 Return-Path: Delivered-To: freebsd-stable@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 9E586D9C for ; Fri, 12 Sep 2014 08:19:00 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 52A3BB8E for ; Fri, 12 Sep 2014 08:18:57 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 7EB2220E70890; Fri, 12 Sep 2014 08:18:56 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 BF96920E7088D; Fri, 12 Sep 2014 08:18:54 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Shane Ambler" , References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> <541280D8.9090500@ShaneWare.Biz> Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] Date: Fri, 12 Sep 2014 09:19:03 +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-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:19:00 -0000 Is there a hold on the snapshot? ----- Original Message ----- From: "Shane Ambler" > On 11/09/2014 16:42, Ben Morrow wrote: >> Quoth Adam McDougall : >>> >>> Were you running a newer kernel with an older format zpool? I heard >>> ixsystems had customers doing that and ran into corruption when they >>> tried to modify the zpool in some way (expand? I don't remember). >>> http://www.bsdnow.tv/episodes/2014_07_09-zfs_war_stories >> >> Oh! Might this be what's causing a problem I've been meaning to ask >> about? >> >> My desktop at home is running (a patched, but not anywhere to do with >> ZFS) 10-STABLE from a while ago, with a zpool that was created under >> 8.2-R and is still at version 15. I have been deliberately not upgrading >> it, because I saw no reason to and it seemed safer to leave things as >> they were. >> >> Recently, though, my dump script has started having occasional problems >> with snapshots that won't delete. Pending further investigation I have >> been renaming them to allow the recursive delete to succeed, and (so >> far) rebooting has always made it possible to get rid of them. > > I have seen that issue with 9.2 and at least one other person mentioned > it as well. I currently have a snapshot that I accessed at least 3 weeks > ago and renamed to keep rotations working and have not accessed since, > it still won't delete as it is busy. I can only delete these snapshots > after a reboot. > > The only cause I know is accessing the snapshot. > I can simply ls .zfs/snapshot/daily.01/somefolder to prevent it being > deleted. With a manual zfs destroy I get "dataset is busy" and have not > found a way to find any process that has hold of it. > > It seems that some aging of the snapshot needs to happen. Testing a > rotate, access, rotate keeps working ok, but access last nights > snapshot and then rotate and it blocks. > > I'm fairly sure that I was running 9.1 when I created this zpool and > then later upgraded to 9.2. zpool upgrade says "This system supports > ZFS pool feature flags" and "Pool 'zrpleader' already has all supported > features enabled". > > -- > FreeBSD - the place to B...Serving Data > > Shane Ambler > > _______________________________________________ > 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-stable@FreeBSD.ORG Fri Sep 12 08:29:19 2014 Return-Path: Delivered-To: freebsd-stable@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 6CD10129; Fri, 12 Sep 2014 08:29:19 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 F0915C92; Fri, 12 Sep 2014 08:29:18 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id C92C6153A8B; Fri, 12 Sep 2014 10:29:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNSXwcJpcxyM; Fri, 12 Sep 2014 10:29:12 +0200 (CEST) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 12D3E153A8A; Fri, 12 Sep 2014 10:29:12 +0200 (CEST) Message-ID: <5412AED7.9040903@digiware.nl> Date: Fri, 12 Sep 2014 10:29:11 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Hartland , Peter Wemm , freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:29:19 -0000 On 12-9-2014 10:17, Steven Hartland wrote: > > ----- Original Message ----- From: "Willem Jan Withagen" > > >> On 11-9-2014 19:49, Peter Wemm wrote: >>>> Another downside is 1/4th of uberblocks, 32 vs 128. >>>> Also, automatic sector size detection works great for me and I've >>>> never had >>>> a need to manually tweak ashift. >>> >>> Unfortunately, I have. Same drive connected two different ways: >>> >>> da12 at mps1 bus 0 scbus1 target 11 lun 0 >>> da12: Fixed Direct Access SCSI-6 device >>> da12: 600.000MB/s transfers >>> da12: Command Queueing enabled >>> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>> >>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >>> ada1: ATA-8 SATA 3.x device >>> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >>> ada1: Command Queueing enabled >>> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >>> ada1: quirks=0x1<4K> >>> >>> The 4k flag is missing when it's on the sas controller. The Ident >>> strings are changed. >>> >>> This came up elsewhere recently. >> >> I reported the same fact for the new set of WD REDs I installed. >> Seems that ada and da have different quirks tables... >> So disks on SATA connectors on the motherboard are diagnosed as being >> 4Kb. >> The disks on my twa don't get the quirk and are considered 512b > > LMK the ident strings and I'll look to update the quirks tables. Hi Steven, Well actually IMHO the quirk tables should be "joined". Because it is nowadays very simple to get a sata device on a scsi-device (da??) be it USB, or a controller that make the world look like /dev/da?? Like the twa I have. I guess the other way scis devices turning up under ATA would not be common. That said, it will not be so simple, otherwise somebody(tm) would have done so already? the WD RED under ata: ada4 at ahcich10 bus 0 scbus11 target 0 lun 0 ada4: ATA-9 SATA 3.x device ada4: Serial Number WD-WMC1T4089783 ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> under twa da0 at arcmsr0 bus 0 scbus8 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: Serial Number WD-WMC1T4081674 da0: 250.000MB/s transfers (125.000MHz, offset 32, 16bit) da0: Command Queueing enabled da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da0: Delete methods: --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 08:52:23 2014 Return-Path: Delivered-To: freebsd-stable@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 92F3FA69; Fri, 12 Sep 2014 08:52:23 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC9BFCC; Fri, 12 Sep 2014 08:52:22 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id F3F6420E7088F; Fri, 12 Sep 2014 08:52:21 +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.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,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 542F220E7088B; Fri, 12 Sep 2014 08:52:20 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Willem Jan Withagen" , "Peter Wemm" , References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <5412AED7.9040903@digiware.nl> Subject: Re: getting to 4K disk blocks in ZFS Date: Fri, 12 Sep 2014 09:52:19 +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 Cc: Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:52:23 -0000 ----- Original Message ----- From: "Willem Jan Withagen" To: "Steven Hartland" ; "Peter Wemm" ; Cc: "Andriy Gapon" ; "Aristedes Maniatis" Sent: Friday, September 12, 2014 9:29 AM Subject: Re: getting to 4K disk blocks in ZFS > On 12-9-2014 10:17, Steven Hartland wrote: >> >> ----- Original Message ----- From: "Willem Jan Withagen" >> >> >>> On 11-9-2014 19:49, Peter Wemm wrote: >>>>> Another downside is 1/4th of uberblocks, 32 vs 128. >>>>> Also, automatic sector size detection works great for me and I've >>>>> never had >>>>> a need to manually tweak ashift. >>>> >>>> Unfortunately, I have. Same drive connected two different ways: >>>> >>>> da12 at mps1 bus 0 scbus1 target 11 lun 0 >>>> da12: Fixed Direct Access SCSI-6 device >>>> da12: 600.000MB/s transfers >>>> da12: Command Queueing enabled >>>> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>>> >>>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >>>> ada1: ATA-8 SATA 3.x device >>>> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >>>> ada1: Command Queueing enabled >>>> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >>>> ada1: quirks=0x1<4K> >>>> >>>> The 4k flag is missing when it's on the sas controller. The Ident >>>> strings are changed. >>>> >>>> This came up elsewhere recently. >>> >>> I reported the same fact for the new set of WD REDs I installed. >>> Seems that ada and da have different quirks tables... >>> So disks on SATA connectors on the motherboard are diagnosed as being >>> 4Kb. >>> The disks on my twa don't get the quirk and are considered 512b >> >> LMK the ident strings and I'll look to update the quirks tables. > > Hi Steven, > > Well actually IMHO the quirk tables should be "joined". > Because it is nowadays very simple to get a sata device on a scsi-device > (da??) be it USB, or a controller that make the world look like > /dev/da?? Like the twa I have. > I guess the other way scis devices turning up under ATA would not be common. You can't unfortunately as they report differently as you've found. > That said, it will not be so simple, otherwise somebody(tm) would have > done so already? > > the WD RED under ata: > ada4 at ahcich10 bus 0 scbus11 target 0 lun 0 > ada4: ATA-9 SATA 3.x device > ada4: Serial Number WD-WMC1T4089783 > ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada4: Command Queueing enabled > ada4: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) > ada4: quirks=0x1<4K> > > under twa > da0 at arcmsr0 bus 0 scbus8 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: Serial Number WD-WMC1T4081674 > da0: 250.000MB/s transfers (125.000MHz, offset 32, 16bit) > da0: Command Queueing enabled > da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) > da0: Delete methods: Looks like there are entries which should match already there: { /* WDC Caviar Green Advanced Format (4k) drives */ { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "WDC WD????RX*", "*" }, /*quirks*/DA_Q_4K }, { /* WDC Caviar Green Advanced Format (4k) drives */ { T_DIRECT, SIP_MEDIA_FIXED, "WDC WD??", "??RX*", "*" }, /*quirks*/DA_Q_4K }, What does camcontrol identify and camcontrol inquiry report? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 08:53:58 2014 Return-Path: Delivered-To: freebsd-stable@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 0E323B9A for ; Fri, 12 Sep 2014 08:53:58 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 A0B9FFF6 for ; Fri, 12 Sep 2014 08:53:57 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id em10so196592wid.0 for ; Fri, 12 Sep 2014 01:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JaFZP+cW2mjsF6RWAf4iGNAEhZJVy4wefWHOURF1Lg0=; b=l2aXNc4Kdy0CECEQMkpdAuycAX4roAU48t+QaLcg7q1SWv5dwKtfs5qSfYG4yVHFgY OkKOM+iiO71uA7AbQgiHGQNIxlhNnC3wF9qnuNmEI+zFztnLGKkNwXUUiuQIg8vVCWXr XQ/cwGmiJXETXtAGjys5laZvDwmqYOvASgKt8Ei5ESuAP0d9sMj4kixHLQ4gU9R0xrPa i77Gi+cWP0HYKqBDw/jogiDgOISBeFFA0RzGKrxGMd0zct8YL7+/VHds8j8c/LpG+UUg XaCTidhhOMU+On0vOt5mOUmdUlcVxjaGCebpRcmGoOyTLLDZJWc6ccDirBBe0uWjeXwI 11zQ== MIME-Version: 1.0 X-Received: by 10.194.179.73 with SMTP id de9mr8922304wjc.87.1410512035353; Fri, 12 Sep 2014 01:53:55 -0700 (PDT) Received: by 10.194.165.40 with HTTP; Fri, 12 Sep 2014 01:53:55 -0700 (PDT) Date: Fri, 12 Sep 2014 10:53:55 +0200 Message-ID: Subject: pkg info and dependencies (openssl related) From: Cristiano Deana To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:53:58 -0000 Hi, in a 9.x box I installed openssl from ports to have 1.x version. Now I upgraded to 10-STABLE, so I'd prefer use openssl from base. first problem: changing USE_OPENSSL_PORT to #USE_OPENSSL_PORT if I have openssl installed recompiling ports needed openssl they linked against the ports version, not the base version. If I specify USE_OPENSSL_BASE I can't recompile (eg nginx) because openssl port is installed. So, what I should do is deinstalling all dep ports, delete openssl, then reinstalling them. Or I should force the recompiling against base openssl. second problem: if I wanna know which ports depend from openssl i got: pkg info -r openssl openssl-1.0.1_15: p5-Net-SSLeay-1.65 ettercap-0.8.0_2,1 p5-libwww-6.08 p5-XML-TreePP-0.42 p5-XML-FeedPP-0.43 p5-SOAP-Lite-0.716 p5-Net-HTTP-6.07 p5-Apache-DBI-1.12 p5-Net-SSLGlue-1.053 p5-Mail-IMAPClient-3.35 otrs-3.3.7 dokuwiki-20140505_3 postfix-2.11.1_4,1 apache22-2.2.29 php5-openssl-5.4.32 php5-snmp-5.4.32 p5-Crypt-SSLeay-0.72 nginx-1.6.1_1,2 but, if I try to delete it, I got a different list, why? # pkg delete openssl Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 23 packages (of 0 packages in the universe): Installed packages to be REMOVED: openssl-1.0.1_15 p5-Net-SSLeay-1.65 (depends on openssl-1.0.1_15) p5-libwww-6.08 (depends on openssl-1.0.1_15) p5-XML-TreePP-0.42 (depends on openssl-1.0.1_15) p5-XML-FeedPP-0.43 (depends on openssl-1.0.1_15) otrs-3.3.7 (depends on openssl-1.0.1_15) p5-SOAP-Lite-0.716 (depends on openssl-1.0.1_15) p5-Net-HTTP-6.07 (depends on openssl-1.0.1_15) p5-LWP-Protocol-https-6.06 (depends on openssl-1.0.1_15) p5-Crypt-SSLeay-0.72 (depends on openssl-1.0.1_15) p5-Net-SSLGlue-1.053 (depends on openssl-1.0.1_15) p5-Mail-IMAPClient-3.35 (depends on openssl-1.0.1_15) p5-IO-Socket-SSL-1.998 (depends on openssl-1.0.1_15) ettercap-0.8.0_2,1 (depends on openssl-1.0.1_15) p5-Apache-DBI-1.12 (depends on openssl-1.0.1_15) dokuwiki-20140505_3 (depends on openssl-1.0.1_15) postfix-2.11.1_4,1 (depends on openssl-1.0.1_15) apache22-2.2.29 (depends on openssl-1.0.1_15) ap22-mod_perl2-2.0.8_2,3 (depends on openssl-1.0.1_15) mod_php5-5.4.32,1 (depends on openssl-1.0.1_15) php5-openssl-5.4.32 (depends on openssl-1.0.1_15) php5-snmp-5.4.32 (depends on openssl-1.0.1_15) nginx-1.6.1_1,2 (depends on openssl-1.0.1_15) Thank you -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 09:12:01 2014 Return-Path: Delivered-To: freebsd-stable@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 49A0913C; Fri, 12 Sep 2014 09:12:01 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 CE3902B2; Fri, 12 Sep 2014 09:12:00 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3924A1534C4; Fri, 12 Sep 2014 11:11:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_1t8BpJb-75; Fri, 12 Sep 2014 11:11:35 +0200 (CEST) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id E4EA71534D2; Fri, 12 Sep 2014 11:11:35 +0200 (CEST) Message-ID: <5412B8C7.3000803@digiware.nl> Date: Fri, 12 Sep 2014 11:11:35 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Hartland , Peter Wemm , freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <5412AED7.9040903@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:12:01 -0000 On 12-9-2014 10:52, Steven Hartland wrote: > > ----- Original Message ----- From: "Willem Jan Withagen" > To: "Steven Hartland" ; "Peter Wemm" > ; > Cc: "Andriy Gapon" ; "Aristedes Maniatis" > Sent: Friday, September 12, 2014 9:29 AM > Subject: Re: getting to 4K disk blocks in ZFS > > >> On 12-9-2014 10:17, Steven Hartland wrote: >>> >>> ----- Original Message ----- From: "Willem Jan Withagen" >>> >>> >>> >>>> On 11-9-2014 19:49, Peter Wemm wrote: >>>>>> Another downside is 1/4th of uberblocks, 32 vs 128. >>>>>> Also, automatic sector size detection works great for me and I've >>>>>> never had >>>>>> a need to manually tweak ashift. >>>>> >>>>> Unfortunately, I have. Same drive connected two different ways: >>>>> >>>>> da12 at mps1 bus 0 scbus1 target 11 lun 0 >>>>> da12: Fixed Direct Access SCSI-6 device >>>>> da12: 600.000MB/s transfers >>>>> da12: Command Queueing enabled >>>>> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>>>> >>>>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >>>>> ada1: ATA-8 SATA 3.x device >>>>> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >>>>> ada1: Command Queueing enabled >>>>> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >>>>> ada1: quirks=0x1<4K> >>>>> >>>>> The 4k flag is missing when it's on the sas controller. The Ident >>>>> strings are changed. >>>>> >>>>> This came up elsewhere recently. >>>> >>>> I reported the same fact for the new set of WD REDs I installed. >>>> Seems that ada and da have different quirks tables... >>>> So disks on SATA connectors on the motherboard are diagnosed as being >>>> 4Kb. >>>> The disks on my twa don't get the quirk and are considered 512b >>> >>> LMK the ident strings and I'll look to update the quirks tables. >> >> Hi Steven, >> >> Well actually IMHO the quirk tables should be "joined". >> Because it is nowadays very simple to get a sata device on a scsi-device >> (da??) be it USB, or a controller that make the world look like >> /dev/da?? Like the twa I have. >> I guess the other way scis devices turning up under ATA would not be >> common. > > You can't unfortunately as they report differently as you've found. > >> That said, it will not be so simple, otherwise somebody(tm) would have >> done so already? >> >> the WD RED under ata: >> ada4 at ahcich10 bus 0 scbus11 target 0 lun 0 >> ada4: ATA-9 SATA 3.x device >> ada4: Serial Number WD-WMC1T4089783 >> ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada4: Command Queueing enabled >> ada4: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) >> ada4: quirks=0x1<4K> >> >> under twa >> da0 at arcmsr0 bus 0 scbus8 target 0 lun 0 >> da0: Fixed Direct Access SCSI-5 device >> da0: Serial Number WD-WMC1T4081674 >> da0: 250.000MB/s transfers (125.000MHz, offset 32, 16bit) >> da0: Command Queueing enabled >> da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) >> da0: Delete methods: > > Looks like there are entries which should match already there: > > { > /* WDC Caviar Green Advanced Format (4k) drives */ > { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "WDC WD????RX*", "*" }, > /*quirks*/DA_Q_4K > }, > { > /* WDC Caviar Green Advanced Format (4k) drives */ > { T_DIRECT, SIP_MEDIA_FIXED, "WDC WD??", "??RX*", "*" }, > /*quirks*/DA_Q_4K > }, > > What does camcontrol identify and camcontrol inquiry report? What I understood from my previous discussion is that these entries are specific ATA but are not tested on da-type devices. This is on a relativly recent 9.3. --WjW [~wjw] root@zfs.digiware.nl# uname -a FreeBSD zfs.digiware.nl 9.3-STABLE FreeBSD 9.3-STABLE #298 r270246M: Thu Aug 21 12:37:58 CEST 2014 root@zfs.digiware.nl:/usr/obj/usr/srcs/src9/src/sys/ZFS amd64 [~wjw] root@zfs.digiware.nl# camcontrol inquiry /dev/da0 pass3: Fixed Direct Access SCSI-5 device pass3: Serial Number WD-WMC1T4081674 pass3: 250.000MB/s transfers (125.000MHz, offset 32, 16bit), Command Queueing Enabled [~wjw] root@zfs.digiware.nl# camcontrol identify /dev/ada4 pass14: ATA-9 SATA 3.x device pass14: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model WDC WD30EFRX-68AX9N0 firmware revision 80.00A80 serial number WD-WMC1T4089783 WWN 50014ee6ae226f02 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 5860533168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 5860533168/5860533168 HPA - Security no From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 14:09:38 2014 Return-Path: Delivered-To: stable@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 012033F4 for ; Fri, 12 Sep 2014 14:09:37 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B0E15E2 for ; Fri, 12 Sep 2014 14:09:37 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8CE9Wrm002597; Fri, 12 Sep 2014 10:09:32 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5412FEAB.1050707@sentex.net> Date: Fri, 12 Sep 2014 10:09:47 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Jack Vogel Subject: Re: svn commit: r267935 - head/sys/dev/e1000 References: <201406262133.s5QLXXP8029811@svn.freebsd.org> <20140804212220.GC48614@rancor.immure.com> <20140805130144.GF40246@rancor.immure.com> <53E51D62.9000507@sentex.net> <53E52762.7040300@sentex.net> <53E536AC.9060304@sentex.net> <53E572B6.1090908@sentex.net> In-Reply-To: <53E572B6.1090908@sentex.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 14:09:38 -0000 On 8/8/2014 9:00 PM, Mike Tancsa wrote: > > Aug 8 18:23:58 zoo kernel: em0: Watchdog timeout -- resetting > Aug 8 18:23:58 zoo kernel: em0: Queue(0) tdh = 158, hw tdt = 118 > Aug 8 18:23:58 zoo kernel: em0: TX(0) desc avail = 31,Next TX to Clean > = 149 > Aug 8 18:23:58 zoo kernel: em0: link state changed to DOWN > Aug 8 18:24:02 zoo kernel: em0: link state changed to UP > Aug 8 18:24:06 zoo kernel: newnfs server > 192.168.x.x:/zbackup1/zoobackup: is alive again > Aug 8 18:24:07 zoo last message repeated 19 times FYI, I just ran into this bug on another box, with an onboard em nic, so I dont think its a one off hardware issue. AMD64, FreeBSD 10.0-STABLE #4 r270560: This is on an Intel MB S1200BTL ( S1200BT.86B.02.00.0035.030220120927) Unfortunately, this is also a production box so its difficult to test. I am going to see if I can find a similar MB to test against. # pciconf -lvcb em1 em1@pci0:2:0:0: class=0x020000 card=0x35788086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xc2300000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled bar [1c] = type Memory, range 32, base 0xc2320000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[a0] = MSI-X supports 5 messages Table in map 0x1c[0x0], PBA in map 0x1c[0x2000] ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001e67ffff4931b8 Sep 12 09:31:17 hast-a kernel: em1: Watchdog timeout -- resetting Sep 12 09:31:17 hast-a kernel: em1: Queue(0) tdh = 174, hw tdt = 128 Sep 12 09:31:17 hast-a kernel: em1: TX(0) desc avail = 31,Next TX to Clean = 159 Sep 12 09:31:17 hast-a kernel: em1: link state changed to DOWN Sep 12 09:31:17 hast-a kernel: vlan5: link state changed to DOWN Sep 12 09:31:20 hast-a kernel: em1: link state changed to UP Sep 12 09:31:20 hast-a kernel: vlan5: link state changed to UP dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.4.2 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.RP05.GBE2 dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x3578 class=0x020000 dev.em.1.%parent: pci2 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.fc: 3 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.itr: 488 dev.em.1.rx_processing_limit: 100 dev.em.1.eee_control: 1 dev.em.1.link_irq: 0 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 2 dev.em.1.device_control: 1074790984 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 35 dev.em.1.queue0.txd_tail: 35 dev.em.1.queue0.tx_irq: 0 dev.em.1.queue0.no_desc_avail: 6 dev.em.1.queue0.rxd_head: 4 dev.em.1.queue0.rxd_tail: 3 dev.em.1.queue0.rx_irq: 0 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 0 dev.em.1.mac_stats.recv_no_buff: 0 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 1695862162 dev.em.1.mac_stats.good_pkts_recvd: 1695862162 dev.em.1.mac_stats.bcast_pkts_recvd: 235092 dev.em.1.mac_stats.mcast_pkts_recvd: 11373 dev.em.1.mac_stats.rx_frames_64: 167700 dev.em.1.mac_stats.rx_frames_65_127: 1640908832 dev.em.1.mac_stats.rx_frames_128_255: 53712726 dev.em.1.mac_stats.rx_frames_256_511: 26150 dev.em.1.mac_stats.rx_frames_512_1023: 69118 dev.em.1.mac_stats.rx_frames_1024_1522: 977636 dev.em.1.mac_stats.good_octets_recvd: 131684743469 dev.em.1.mac_stats.good_octets_txd: 4643270636718 dev.em.1.mac_stats.total_pkts_txd: 3220545297 dev.em.1.mac_stats.good_pkts_txd: 3220545297 dev.em.1.mac_stats.bcast_pkts_txd: 2038 dev.em.1.mac_stats.mcast_pkts_txd: 2 dev.em.1.mac_stats.tx_frames_64: 2192 dev.em.1.mac_stats.tx_frames_65_127: 57674879 dev.em.1.mac_stats.tx_frames_128_255: 66706189 dev.em.1.mac_stats.tx_frames_256_511: 4031061 dev.em.1.mac_stats.tx_frames_512_1023: 136967178 dev.em.1.mac_stats.tx_frames_1024_1522: 2955163798 dev.em.1.mac_stats.tso_txd: 250622342 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 420159909 dev.em.1.interrupts.rx_pkt_timer: 193315 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 9886 dev.em.1.interrupts.tx_abs_timer: 15943 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 dev.em.1.wake: 0 -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 14:33:41 2014 Return-Path: Delivered-To: freebsd-stable@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 ABB1FD0D for ; Fri, 12 Sep 2014 14:33:41 +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 700048F6 for ; Fri, 12 Sep 2014 14:33:41 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id g18so549951oah.35 for ; Fri, 12 Sep 2014 07:33:40 -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=VBxYBh1w1/gVHKCRbScEAqTgXq9iOMxNhqN4Ay3YPfM=; b=SffVGPOvdF89uUd0AczzikifzCGcbE0w9XSlRBbffV3+jBQslKGAKg/lRiWWLpuTkO StopsERs8vO30wXhffUoNkjTA/Popy1ph+jW/IQPbqSGbvPkN++zereUyCB/mzHFp8nv lGJdHULcUSC2cS+39hpabxMEaBHGq3X/RfdTFoKyBQIlS6ZTTCQqq/rpyNeJ/4V8qlE6 8xNQngusIKjuWxFg5FlpvTSiByjwzIWPUs49FuRBbEHk7XzDI1cy1s6+yhvF8tWzyNWA Mrd8r6HKz/bqZN+AQ4ztYRahApKAj4yEECGLz/kU4trFP2RmYWVfOvgv90eKZfYTdf7q UzKA== MIME-Version: 1.0 X-Received: by 10.182.153.68 with SMTP id ve4mr8907054obb.60.1410532419179; Fri, 12 Sep 2014 07:33:39 -0700 (PDT) Received: by 10.202.199.11 with HTTP; Fri, 12 Sep 2014 07:33:39 -0700 (PDT) In-Reply-To: References: <7925563B043E419996CD7FEE8C7DFDB6@multiplay.co.uk> <2401599.spj3ijL0cc@overcee.wemm.org> Date: Fri, 12 Sep 2014 07:33:39 -0700 Message-ID: Subject: Re: Using CARP with multiple IP aliases (FBSD 10.0) From: Freddie Cash To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Steven Hartland , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 14:33:41 -0000 On Thu, Sep 11, 2014 at 11:04 AM, Freddie Cash wrote: > On Thu, Sep 11, 2014 at 10:39 AM, Peter Wemm wrote: > >> This is the method we use extensively in the freebsd.org cluster. eg: >> the >> routers have public IP addresses, private RFC1918, IPv6 etc addresses, >> all on >> the same vhid for each interface. >> >> * One vhid presence, with multiple aliases on the same vhid. >> * Configure vhid params once, aliases attached without params. >> >> carp state checking uses link local addresses to communicate. >> >> Having multiple IP's per vhid means they change master->backup state as = a >> group, not individually and that's what we wanted for things like router >> default gateways. >> > > =E2=80=8BExcellent. Thanks for the confirmation. > > =E2=80=8BI'll be testing the updated configuration tomorrow morning (set = all vhid > params in rc.conf.local, and only set vhid number in firewall scripts whe= n > adding IPs). > =E2=80=8B > =E2=80=8BEverything is working correctly now. :) /etc/rc.conf.local configures all the carp-related options. And the firewall scripts now only set the vhid when adding the IP to the interface, nothing else. Seems I also had a typo in one of my scripts that wasn't adding one of the IPs to the vhid on sys2, so the IP list on both systems wasn't identical, which could also be part of the reason they were both MASTER at the same time.=E2=80=8B Now, igb0 on each system is showing the correct CARP status (MASTER on sys1, BACKUP on sys2). And, downing any of the 4 interfaces on sys1 correctly sets all interfaces on sys2 to MASTER. Thanks for all the help, and for pointing me in the right direction. :D --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 16:06:00 2014 Return-Path: Delivered-To: stable@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 167E3198 for ; Fri, 12 Sep 2014 16:06:00 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C87B630E for ; Fri, 12 Sep 2014 16:05:59 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8CG5wJs023751; Fri, 12 Sep 2014 12:05:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <541319F5.1020502@sentex.net> Date: Fri, 12 Sep 2014 12:06:13 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Jack Vogel Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) References: <201406262133.s5QLXXP8029811@svn.freebsd.org> <20140804212220.GC48614@rancor.immure.com> <20140805130144.GF40246@rancor.immure.com> <53E51D62.9000507@sentex.net> <53E52762.7040300@sentex.net> <53E536AC.9060304@sentex.net> <53E572B6.1090908@sentex.net> <5412FEAB.1050707@sentex.net> In-Reply-To: <5412FEAB.1050707@sentex.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 16:06:00 -0000 On 9/12/2014 10:09 AM, Mike Tancsa wrote: > > FYI, I just ran into this bug on another box, with an onboard em nic, so > I dont think its a one off hardware issue. AMD64, FreeBSD 10.0-STABLE > #4 r270560: > This is on an Intel MB S1200BTL ( S1200BT.86B.02.00.0035.030220120927) > > Unfortunately, this is also a production box so its difficult to test. I > am going to see if I can find a similar MB to test against. I found another board I can test with. It takes a bit of random traffic to wedge, but I can lock up the NIC to the point where I have to down and up it When the NIC is wedged, sending sysctl -w em.1.debug=1 shows Sep 12 11:05:05 backup3 kernel: Interface is RUNNING and ACTIVE Sep 12 11:05:05 backup3 kernel: em1: hw tdh = 414, hw tdt = 980 Sep 12 11:05:05 backup3 kernel: em1: hw rdh = 768, hw rdt = 767 Sep 12 11:05:05 backup3 kernel: em1: Tx Queue Status = 1 Sep 12 11:05:05 backup3 kernel: em1: TX descriptors avail = 449 Sep 12 11:05:05 backup3 kernel: em1: Tx Descriptors avail failure = 3 Sep 12 11:05:05 backup3 kernel: em1: RX discarded packets = 0 Sep 12 11:05:05 backup3 kernel: em1: RX Next to Check = 768 Sep 12 11:05:05 backup3 kernel: em1: RX Next to Refresh = 767 em1: flags=8843 metric 0 mtu 1500 options=4219b ether 00:15:17:ed:68:a4 inet 1.1.1.2 netmask 0xffffff00 broadcast 1.1.1.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active The network traffic involves sending a lot of traffic via NFS. I found that if I disable TSO on the nic, it seems to fix the problem, or at least makes its hard to reproduce. With tso enabled, it took perhaps 30-120 seconds for the problem to manifest. Both on my test and production box, I have not run into the problem in the past 45min. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 17:23:43 2014 Return-Path: Delivered-To: freebsd-stable@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 34AC9773; Fri, 12 Sep 2014 17:23:43 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D461FE5E; Fri, 12 Sep 2014 17:23:42 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8CHNGCA035683; Fri, 12 Sep 2014 13:23:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <54132C13.6060605@sentex.net> Date: Fri, 12 Sep 2014 13:23:31 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Steven Hartland , Willem Jan Withagen , Peter Wemm , freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 17:23:43 -0000 On 9/12/2014 4:17 AM, Steven Hartland wrote: >> >> I reported the same fact for the new set of WD REDs I installed. >> Seems that ada and da have different quirks tables... >> So disks on SATA connectors on the motherboard are diagnosed as being >> 4Kb. >> The disks on my twa don't get the quirk and are considered 512b > > LMK the ident strings and I'll look to update the quirks tables. How does it work for controllers like mfi ? The disks come up as mfisyspd# They are supposedly 4K drives (when attached to ada). If I set vfs.zfs.min_auto_ashift=12 will it "fix" the problem ? === START OF INFORMATION SECTION === Model Family: Samsung based SSDs Device Model: Samsung SSD 840 PRO Series Serial Number: S1ANNSAF225154J LU WWN Device Id: 5 002538 5a01d79fd Firmware Version: DXM05B0Q User Capacity: 128,035,676,160 bytes [128 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Fri Sep 12 09:17:42 2014 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled # mfiutil show drives mfi0 Physical Drives: 8 ( 119G) JBOD SATA E1:S1 9 ( 119G) JBOD SATA E1:S0 10 ( 119G) JBOD SATA E1:S3 11 ( 119G) JBOD SATA E1:S2 ---Mik3 -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 17:43:21 2014 Return-Path: Delivered-To: stable@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 16D7D90 for ; Fri, 12 Sep 2014 17:43:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 F2311E1 for ; Fri, 12 Sep 2014 17:43:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8CHhKhf045481 for ; Fri, 12 Sep 2014 17:43:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Fri, 12 Sep 2014 17:43:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 17:43:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 --- Comment #7 from John Baldwin --- Do you have core.txt.N files in /var/crash? They will contain the kgdb backtrace if so. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 17:45:33 2014 Return-Path: Delivered-To: stable@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 B93501F6 for ; Fri, 12 Sep 2014 17:45:33 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 A0F2B10C for ; Fri, 12 Sep 2014 17:45:33 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8CHjXiS046557 for ; Fri, 12 Sep 2014 17:45:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193363] [panic] panic at reboot Date: Fri, 12 Sep 2014 17:45:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 17:45:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193363 --- Comment #4 from John Baldwin --- Ok, I guess the 9.1 kernel did not ship with debug symbols. You can do 'nm -n /boot/kernel.old9.1/kernel | grep c0aae' which might narrow things down some. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 20:18:53 2014 Return-Path: Delivered-To: freebsd-stable@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 C424A1F8; Fri, 12 Sep 2014 20:18:53 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 84B65257; Fri, 12 Sep 2014 20:18:53 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id A348620E7088F; Fri, 12 Sep 2014 20:18:52 +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,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 D968720E7088B; Fri, 12 Sep 2014 20:18:50 +0000 (UTC) Message-ID: <1319C84209BE4390AD5D7FAD8170BEB0@multiplay.co.uk> From: "Steven Hartland" To: "Mike Tancsa" , "Willem Jan Withagen" , "Peter Wemm" , References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <54132C13.6060605@sentex.net> Subject: Re: getting to 4K disk blocks in ZFS Date: Fri, 12 Sep 2014 21:18:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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: Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 20:18:53 -0000 ----- Original Message ----- From: "Mike Tancsa" To: "Steven Hartland" ; "Willem Jan Withagen" ; "Peter Wemm" ; Cc: "Andriy Gapon" ; "Aristedes Maniatis" Sent: Friday, September 12, 2014 6:23 PM Subject: Re: getting to 4K disk blocks in ZFS > On 9/12/2014 4:17 AM, Steven Hartland wrote: >>> >>> I reported the same fact for the new set of WD REDs I installed. >>> Seems that ada and da have different quirks tables... >>> So disks on SATA connectors on the motherboard are diagnosed as being >>> 4Kb. >>> The disks on my twa don't get the quirk and are considered 512b >> >> LMK the ident strings and I'll look to update the quirks tables. > > How does it work for controllers like mfi ? The disks come up as mfisyspd# > > They are supposedly 4K drives (when attached to ada). If I set vfs.zfs.min_auto_ashift=12 will it "fix" the problem ? > > === START OF INFORMATION SECTION === > Model Family: Samsung based SSDs > Device Model: Samsung SSD 840 PRO Series > Serial Number: S1ANNSAF225154J > LU WWN Device Id: 5 002538 5a01d79fd > Firmware Version: DXM05B0Q > User Capacity: 128,035,676,160 bytes [128 GB] > Sector Size: 512 bytes logical/physical > Rotation Rate: Solid State Device > Device is: In smartctl database [for details use: -P show] > ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c > SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) > Local Time is: Fri Sep 12 09:17:42 2014 EDT > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > # mfiutil show drives > mfi0 Physical Drives: > 8 ( 119G) JBOD SATA E1:S1 > 9 ( 119G) JBOD SATA E1:S0 > 10 ( 119G) JBOD SATA E1:S3 > 11 ( 119G) JBOD SATA E1:S2 Quirks are only valid for CAM supported drivers, any RAID which don't use CAM will bypass this. If you set min_auto_ashift=12 you will ensure that new pools created will use a min of 4k blocks. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 21:00:35 2014 Return-Path: Delivered-To: stable@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 49E1656A for ; Fri, 12 Sep 2014 21:00:35 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C5E198B6 for ; Fri, 12 Sep 2014 21:00:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAJtdE1SDaFve/2dsb2JhbABcA4NgVwSCeMV1CoZ6VAGBJ3iEBAEBBAEBASAmBRgICxsHEQICDRkCKQEJJgYIBwQBHASIIQ2nS5VwAReBLI1QAQEbJBAHEYInQRKBQQWGH49lhAGEYpNgg30hLweBCDmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,515,1406606400"; d="scan'208";a="153776252" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Sep 2014 17:00:27 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A2508B3F14; Fri, 12 Sep 2014 17:00:27 -0400 (EDT) Date: Fri, 12 Sep 2014 17:00:27 -0400 (EDT) From: Rick Macklem To: Mike Tancsa Message-ID: <932734062.35704765.1410555627658.JavaMail.root@uoguelph.ca> In-Reply-To: <541319F5.1020502@sentex.net> Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: stable@freebsd.org, Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 21:00:35 -0000 Mike Tansca wrote: > On 9/12/2014 10:09 AM, Mike Tancsa wrote: > > > > FYI, I just ran into this bug on another box, with an onboard em > > nic, so > > I dont think its a one off hardware issue. AMD64, FreeBSD > > 10.0-STABLE > > #4 r270560: > > This is on an Intel MB S1200BTL ( > > S1200BT.86B.02.00.0035.030220120927) > > > > Unfortunately, this is also a production box so its difficult to > > test. I > > am going to see if I can find a similar MB to test against. > > > I found another board I can test with. It takes a bit of random > traffic > to wedge, but I can lock up the NIC to the point where I have to down > and up it > > When the NIC is wedged, sending sysctl -w em.1.debug=1 shows > > > Sep 12 11:05:05 backup3 kernel: Interface is RUNNING and ACTIVE > Sep 12 11:05:05 backup3 kernel: em1: hw tdh = 414, hw tdt = 980 > Sep 12 11:05:05 backup3 kernel: em1: hw rdh = 768, hw rdt = 767 > Sep 12 11:05:05 backup3 kernel: em1: Tx Queue Status = 1 > Sep 12 11:05:05 backup3 kernel: em1: TX descriptors avail = 449 > Sep 12 11:05:05 backup3 kernel: em1: Tx Descriptors avail failure = 3 > Sep 12 11:05:05 backup3 kernel: em1: RX discarded packets = 0 > Sep 12 11:05:05 backup3 kernel: em1: RX Next to Check = 768 > Sep 12 11:05:05 backup3 kernel: em1: RX Next to Refresh = 767 > > em1: flags=8843 metric 0 mtu > 1500 > > options=4219b > ether 00:15:17:ed:68:a4 > inet 1.1.1.2 netmask 0xffffff00 broadcast 1.1.1.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > The network traffic involves sending a lot of traffic via NFS. I > found > that if I disable TSO on the nic, it seems to fix the problem, or at > least makes its hard to reproduce. With tso enabled, it took perhaps > 30-120 seconds for the problem to manifest. Both on my test and > production box, I have not run into the problem in the past 45min. > To get NFS (which generates 35 mbuf lists for transmission) to work with TSO enabled, you need both r264630 (which reduces the default size of if_hw_tsomax slightly) and r268726 (which fixes the retry: case for if_em.c). Neither of these patches (the above rNNN are for head) are in 10.0. So, either run with TSO disabled or reduce the rsize, wsize of all NFS mounts to 32768 (which reduces the # of mbufs in a transmit list to 19). rick ps: For 10.0, 9.2 and earlier, you need to disable TSO for any network interface that supports less than 35 transmit fragments. (Transmit fragments are variously called *TXSEG*, or *SCAT* or similar in the .h file for the device driver.) > ---Mike > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > _______________________________________________ > 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-stable@FreeBSD.ORG Fri Sep 12 21:13:10 2014 Return-Path: Delivered-To: stable@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 1C595B96; Fri, 12 Sep 2014 21:13:10 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D52AFA6D; Fri, 12 Sep 2014 21:13:09 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8CLD5Su069261; Fri, 12 Sep 2014 17:13:05 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <541361EF.4030107@sentex.net> Date: Fri, 12 Sep 2014 17:13:19 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Rick Macklem Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) References: <932734062.35704765.1410555627658.JavaMail.root@uoguelph.ca> In-Reply-To: <932734062.35704765.1410555627658.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: stable@freebsd.org, Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 21:13:10 -0000 On 9/12/2014 5:00 PM, Rick Macklem wrote: > > So, either run with TSO disabled or reduce the rsize, wsize of all NFS > mounts to 32768 (which reduces the # of mbufs in a transmit list to 19). Thanks! Perhaps this should be in the errata notice for 10.1 ? root@backup3:/usr/home/mdtancsa # mount -orsize=32768,wsize=32768 1.1.1.1:/mfitest /mnt Testing with tso enabled. So far so good! I am not able to wedge the NIC ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 22:35:19 2014 Return-Path: Delivered-To: stable@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 792DA9A1; Fri, 12 Sep 2014 22:35:18 +0000 (UTC) Date: Fri, 12 Sep 2014 18:35:15 -0400 From: Glen Barber To: Mike Tancsa Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) Message-ID: <20140912223515.GS1198@hub.FreeBSD.org> References: <932734062.35704765.1410555627658.JavaMail.root@uoguelph.ca> <541361EF.4030107@sentex.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MhP8cYafZlTESjGT" Content-Disposition: inline In-Reply-To: <541361EF.4030107@sentex.net> 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: stable@freebsd.org, Rick Macklem , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 22:35:19 -0000 --MhP8cYafZlTESjGT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 12, 2014 at 05:13:19PM -0400, Mike Tancsa wrote: > On 9/12/2014 5:00 PM, Rick Macklem wrote: > > > >So, either run with TSO disabled or reduce the rsize, wsize of all NFS > >mounts to 32768 (which reduces the # of mbufs in a transmit list to 19). >=20 > Thanks! Perhaps this should be in the errata notice for 10.1 ? >=20 =20 We'll add it. Thanks. Glen --MhP8cYafZlTESjGT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUE3UjAAoJELls3eqvi17QhkcQAIISXnwId2texaDXfvub6WtS UGJmhr5XJclL1AZYrF9Hz2G/LLfc5VlPpGum8oEH/Jviy2dJkF+t5fjXWrMK989w mnx0aHt7/8SRtyEijJ/9VrpSM+VSH6Xb1Zk1MnT71Fi7Pw8maemv41lpXvNfH2v6 Xpez0qcZGhhsGB+h5Cqb7XWppNmr0iSUXpl3lSeJc06kCAEP7oc+3+yjSqV5f+EO S4V3ueJeqNM2LJ3kD9IdPa7MIkGRX4pRuf2WMGS0hyaAJUI5GYfiXfDsYs/a7F6a Yv9eOf50nEf+i1lZ+42M93NQvUyLx+7MPStTsi8dOPXGtWux66dDlrlUwoHAKTrU KkHGluu6ezNkm5AIYlpKmowYLVzxRtVzOa/2jk5+9JeVsXL/ksiPMqitntBh68Pa R4yyx1X+hBbLwqYPSS2vwAxIRYg0HQCjRNdbLvppU65mNqfcFCt8Wmct4mrN0YlE wdGMXsz/pf0H+6zLB6G6m9RXB8ODcJLrZQx3as8KVbNWpXDEyHop7GziVEx4HDVA 1Ll8EUn51X+bqn9KbZ3DihV89GB0y2+i2+PoLlTis7PL7Xr7LAprNhEeBN2Zo2UG BOTWx7zRJ4SxCYTIL8g7Rc3B325qqcjIag332N7if/jSkm4ij1Td7FQyYvVSdyIt jbwUYfevQwG9XkURvpFx =1f6o -----END PGP SIGNATURE----- --MhP8cYafZlTESjGT-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 23:16:43 2014 Return-Path: Delivered-To: stable@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 9C619D00; Fri, 12 Sep 2014 23:16:43 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 52645975; Fri, 12 Sep 2014 23:16:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAIB+E1SDaFve/2dsb2JhbABfhDuCeMosgyEBgSB4hAMBAQEDASNWBRYOCgICDRkCWQaITQinN5V1AReBLI1tNAeCeYFTBZo3hAmUB4N9IYF3gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,515,1406606400"; d="scan'208";a="153792643" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Sep 2014 19:16:42 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3FB27B3EE4; Fri, 12 Sep 2014 19:16:42 -0400 (EDT) Date: Fri, 12 Sep 2014 19:16:42 -0400 (EDT) From: Rick Macklem To: Glen Barber Message-ID: <1808222501.35730810.1410563802251.JavaMail.root@uoguelph.ca> In-Reply-To: <20140912223515.GS1198@hub.FreeBSD.org> Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: stable@freebsd.org, Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 23:16:43 -0000 Glen Barber wrote: > On Fri, Sep 12, 2014 at 05:13:19PM -0400, Mike Tancsa wrote: > > On 9/12/2014 5:00 PM, Rick Macklem wrote: > > > > > >So, either run with TSO disabled or reduce the rsize, wsize of all > > >NFS > > >mounts to 32768 (which reduces the # of mbufs in a transmit list > > >to 19). > > > > Thanks! Perhaps this should be in the errata notice for 10.1 ? > > > > We'll add it. > The patches are in 10.1. I thought his report said 10.0 in the message. If Mike is running a recent stable/10 or releng/10.1, then it has been patched for this and NFS should work with TSO enabled. If it doesn't, then something else is broken. rick > Thanks. > > Glen > > From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 23:33:46 2014 Return-Path: Delivered-To: freebsd-stable@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 21B9A219; Fri, 12 Sep 2014 23:33:46 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id CDBAFAF2; Fri, 12 Sep 2014 23:33:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAqCE1SDaFve/2dsb2JhbABfhDuCeM1QgSF4hAUoVhsOCgICDRkCX4hRpzCVXwEXgSyNSiM0gn+BUwWyR4N6IYE2QYECAQEB X-IronPort-AV: E=Sophos;i="5.04,515,1406606400"; d="scan'208";a="153794015" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Sep 2014 19:33:45 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0EB1BB4058; Fri, 12 Sep 2014 19:33:45 -0400 (EDT) Date: Fri, 12 Sep 2014 19:33:45 -0400 (EDT) From: Rick Macklem To: Glen Barber Message-ID: <1109209778.35732953.1410564825048.JavaMail.root@uoguelph.ca> Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 23:33:46 -0000 I wrote: > The patches are in 10.1. I thought his report said 10.0 in the message. > > If Mike is running a recent stable/10 or releng/10.1, then it has been > patched for this and NFS should work with TSO enabled. If it doesn't, > then something else is broken. Oops, I looked and I see Mike was testing r270560 (which would have both the patches). I don't have an explanation why TSO and 64K rsize, wsize would cause a hang, but does appear it will exist in 10.1 unless it gets resolved. Mike, one difference is that, even with the patches the driver will be copying the transmit mbuf list via m_defrag() to 32 MCLBYTE clusters when using 64K rsize, wsize. If you can reproduce the hang, you might want to look at how many mbuf clusters are allocated. If you've hit the limit, then I think that would explain it. rick From owner-freebsd-stable@FreeBSD.ORG Sat Sep 13 00:52:45 2014 Return-Path: Delivered-To: freebsd-stable@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 06B64D82; Sat, 13 Sep 2014 00:52:45 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D1F951AA; Sat, 13 Sep 2014 00:52:44 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8D0qeud089983; Fri, 12 Sep 2014 20:52:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <54139566.7050202@sentex.net> Date: Fri, 12 Sep 2014 20:52:54 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Rick Macklem , Glen Barber Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) References: <1109209778.35732953.1410564825048.JavaMail.root@uoguelph.ca> In-Reply-To: <1109209778.35732953.1410564825048.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 00:52:45 -0000 On 9/12/2014 7:33 PM, Rick Macklem wrote: > I wrote: >> The patches are in 10.1. I thought his report said 10.0 in the message. >> >> If Mike is running a recent stable/10 or releng/10.1, then it has been >> patched for this and NFS should work with TSO enabled. If it doesn't, >> then something else is broken. > Oops, I looked and I see Mike was testing r270560 (which would have both > the patches). I don't have an explanation why TSO and 64K rsize, wsize > would cause a hang, but does appear it will exist in 10.1 unless it > gets resolved. > > Mike, one difference is that, even with the patches the driver will be > copying the transmit mbuf list via m_defrag() to 32 MCLBYTE clusters > when using 64K rsize, wsize. > If you can reproduce the hang, you might want to look at how many mbuf > clusters are allocated. If you've hit the limit, then I think that > would explain it. I have been running the test for a few hrs now and no lockups of the nic, so doing the nfs mount with -orsize=32768,wsize=32768 certainly seems to work around the lockup. How do I check the mbuf clusters ? root@backup3:/usr/home/mdtancsa # vmstat -z | grep -i clu mbuf_cluster: 2048, 760054, 4444, 370, 3088708, 0, 0 root@backup3:/usr/home/mdtancsa # root@backup3:/usr/home/mdtancsa # netstat -m 3322/4028/7350 mbufs in use (current/cache/total) 2826/1988/4814/760054 mbuf clusters in use (current/cache/total/max) 2430/1618 mbuf+clusters out of packet secondary zone in use (current/cache) 0/4/4/380026 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/112600 9k jumbo clusters in use (current/cache/total/max) 0/0/0/63337 16k jumbo clusters in use (current/cache/total/max) 6482K/4999K/11481K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile root@backup3:/usr/home/mdtancsa # Interface is RUNNING and ACTIVE em1: hw tdh = 343, hw tdt = 838 em1: hw rdh = 512, hw rdt = 511 em1: Tx Queue Status = 1 em1: TX descriptors avail = 516 em1: Tx Descriptors avail failure = 1 em1: RX discarded packets = 0 em1: RX Next to Check = 512 em1: RX Next to Refresh = 511 I just tested on the other em nic and I can wedge it as well, so its not limited to one particular type of em nic. em0: Watchdog timeout -- resetting em0: Queue(0) tdh = 349, hw tdt = 176 em0: TX(0) desc avail = 173,Next TX to Clean = 349 em0: link state changed to DOWN em0: link state changed to UP so it does not seem limited to just certain em nics em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82578DM Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xb1a00000, size 131072, enabled bar [14] = type Memory, range 32, base 0xb1a25000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x2040, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP I can lock things up fairly quickly by running these 2 scripts across an nfs mount. #!/bin/sh while true do dd if=/dev/urandom ibs=64k count=1000 | pbzip2 -c -p3 > /mnt/test.bz2 dd if=/dev/urandom ibs=63k count=1000 | pbzip2 -c -p3 > /mnt/test.bz2 dd if=/dev/urandom ibs=66k count=1000 | pbzip2 -c -p3 > /mnt/test.bz2 done root@backup3:/usr/home/mdtancsa # cat i3 #!/bin/sh while true do dd if=/dev/zero of=/mnt/test2 bs=128k count=2000 sleep 10 done ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Sep 13 04:14:55 2014 Return-Path: Delivered-To: freebsd-stable@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 41724761; Sat, 13 Sep 2014 04:14:55 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id 99CF4403; Sat, 13 Sep 2014 04:14:53 +0000 (UTC) Received: from ppp118-210-249-247.lns20.adl6.internode.on.net (HELO leader.local) ([118.210.249.247]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Sep 2014 13:44:52 +0930 Message-ID: <5413C4BA.7080302@ShaneWare.Biz> Date: Sat, 13 Sep 2014 13:44:50 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andriy Gapon , freebsd-stable@FreeBSD.org, amvandemore@gmail.com, killing@multiplay.co.uk Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> <541280D8.9090500@ShaneWare.Biz> <541293D0.4080907@FreeBSD.org> In-Reply-To: <541293D0.4080907@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 04:14:55 -0000 On 12/09/2014 16:03, Andriy Gapon wrote: > On 12/09/2014 08:12, Shane Ambler wrote: >> On 11/09/2014 16:42, Ben Morrow wrote: >>> Recently, though, my dump script has started having occasional problems >>> with snapshots that won't delete. Pending further investigation I have >>> been renaming them to allow the recursive delete to succeed, and (so >>> far) rebooting has always made it possible to get rid of them. >> >> I have seen that issue with 9.2 and at least one other person mentioned >> it as well. I currently have a snapshot that I accessed at least 3 weeks >> ago and renamed to keep rotations working and have not accessed since, >> it still won't delete as it is busy. I can only delete these snapshots >> after a reboot. >> >> The only cause I know is accessing the snapshot. >> I can simply ls .zfs/snapshot/daily.01/somefolder to prevent it being >> deleted. With a manual zfs destroy I get "dataset is busy" and have not >> found a way to find any process that has hold of it. > > Look for it in `mount` output. There is no entry in mount or df for the snapshot The zfs mounted property is only yes for real filesystems - all snapshots show as '-' On 12/09/2014 16:44, Adam Vande More wrote: > > What exactly have you tried and what were the results? zfs rename works zfs destroy fails both before and after rename with 'cannot destroy snapshot zrpleader/home/shane@daily.bad: dataset is busy' I can't find anything with fstat or lsof to indicate a process has anything open within the snapshot path. I haven't done a lot of digging for info so don't think I've tried anything else yet. On 12/09/2014 17:49, Steven Hartland wrote: > > Is there a hold on the snapshot? Don't know how to tell that. The first time I encountered this I think I sent xfe to the snapshot dir and opened a video with vlc. The one I have from a few weeks ago I did cp ~/.zfs/snapshot/daily.01/folder/file ~/folder/ from a terminal as a normal user. The original snapshots were created with zfs snapshot -r zrpleader@daily.01 I have manually destroyed each of the individual filesystem snapshots that I could and have two bad snapshots remaining, one from a few weeks ago and one from a few days ago. Both of these I can not access now. ls .zfs/snapshot/daily.bad says 'ls: .zfs/snapshot/daily.bad: Device busy' -- FreeBSD - the place to B...Serving Data Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Sat Sep 13 12:08:37 2014 Return-Path: Delivered-To: freebsd-stable@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 ABCF4C09; Sat, 13 Sep 2014 12:08:37 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB53AB; Sat, 13 Sep 2014 12:08:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAG4zFFSDaFve/2dsb2JhbABcA4NgVwSCeMYZCoZ6VAGBH3iEAwEBAQMBAQEBICYFGAgLBRYHEQICDRkCKQEJJgYIBwQBHASIFQgNpkiVSgEXgSyNSQEGAQEIEyQQBxGCJkESgUEFhh+EKYs8hAGEYpNggWcegXUhLwd/AQgXIoECAQEB X-IronPort-AV: E=Sophos;i="5.04,517,1406606400"; d="scan'208";a="153841900" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 13 Sep 2014 08:08:28 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 17E48B4044; Sat, 13 Sep 2014 08:08:28 -0400 (EDT) Date: Sat, 13 Sep 2014 08:08:28 -0400 (EDT) From: Rick Macklem To: Mike Tancsa Message-ID: <1472615261.35797393.1410610108085.JavaMail.root@uoguelph.ca> In-Reply-To: <54139566.7050202@sentex.net> Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Glen Barber , freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 12:08:37 -0000 Mike Tancsa wrote: > On 9/12/2014 7:33 PM, Rick Macklem wrote: > > I wrote: > >> The patches are in 10.1. I thought his report said 10.0 in the > >> message. > >> > >> If Mike is running a recent stable/10 or releng/10.1, then it has > >> been > >> patched for this and NFS should work with TSO enabled. If it > >> doesn't, > >> then something else is broken. > > Oops, I looked and I see Mike was testing r270560 (which would have > > both > > the patches). I don't have an explanation why TSO and 64K rsize, > > wsize > > would cause a hang, but does appear it will exist in 10.1 unless it > > gets resolved. > > > > Mike, one difference is that, even with the patches the driver will > > be > > copying the transmit mbuf list via m_defrag() to 32 MCLBYTE > > clusters > > when using 64K rsize, wsize. > > If you can reproduce the hang, you might want to look at how many > > mbuf > > clusters are allocated. If you've hit the limit, then I think that > > would explain it. > > > I have been running the test for a few hrs now and no lockups of the > nic, so doing the nfs mount with -orsize=32768,wsize=32768 certainly > seems to work around the lockup. How do I check the mbuf clusters ? > > root@backup3:/usr/home/mdtancsa # vmstat -z | grep -i clu > mbuf_cluster: 2048, 760054, 4444, 370, 3088708, 0, > 0 > root@backup3:/usr/home/mdtancsa # > root@backup3:/usr/home/mdtancsa # netstat -m > 3322/4028/7350 mbufs in use (current/cache/total) > 2826/1988/4814/760054 mbuf clusters in use (current/cache/total/max) This was all I was thinking of. It certainly doesn't look like a problem. If the 64K rsize, wsize test is about the same, I'd say you aren't running out of mbuf clusters. > 2430/1618 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/4/4/380026 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/112600 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/63337 16k jumbo clusters in use (current/cache/total/max) > 6482K/4999K/11481K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > root@backup3:/usr/home/mdtancsa # > > Interface is RUNNING and ACTIVE > em1: hw tdh = 343, hw tdt = 838 > em1: hw rdh = 512, hw rdt = 511 > em1: Tx Queue Status = 1 > em1: TX descriptors avail = 516 > em1: Tx Descriptors avail failure = 1 I don't know anything about the hardware, but this looks suspicious to me? Hopefully someone familiar with the hardware can help, rick > em1: RX discarded packets = 0 > em1: RX Next to Check = 512 > em1: RX Next to Refresh = 511 > > > I just tested on the other em nic and I can wedge it as well, so its > not > limited to one particular type of em nic. > > > em0: Watchdog timeout -- resetting > em0: Queue(0) tdh = 349, hw tdt = 176 > em0: TX(0) desc avail = 173,Next TX to Clean = 349 > em0: link state changed to DOWN > em0: link state changed to UP > > so it does not seem limited to just certain em nics > > em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 > chip=0x10ef8086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82578DM Gigabit Network Connection' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xb1a00000, size > 131072, > enabled > bar [14] = type Memory, range 32, base 0xb1a25000, size 4096, > enabled > bar [18] = type I/O Port, range 32, base 0x2040, size 32, > enabled > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > message > cap 13[e0] = PCI Advanced Features: FLR TP > > > I can lock things up fairly quickly by running these 2 scripts across > an > nfs mount. > > #!/bin/sh > > while true > do > dd if=/dev/urandom ibs=64k count=1000 | pbzip2 -c -p3 > > /mnt/test.bz2 > dd if=/dev/urandom ibs=63k count=1000 | pbzip2 -c -p3 > > /mnt/test.bz2 > dd if=/dev/urandom ibs=66k count=1000 | pbzip2 -c -p3 > > /mnt/test.bz2 > done > root@backup3:/usr/home/mdtancsa # cat i3 > #!/bin/sh > > while true > do > dd if=/dev/zero of=/mnt/test2 bs=128k count=2000 > sleep 10 > done > > > ---Mike > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > _______________________________________________ > 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-stable@FreeBSD.ORG Sat Sep 13 16:12:05 2014 Return-Path: Delivered-To: freebsd-stable@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 3E12B890 for ; Sat, 13 Sep 2014 16:12:05 +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 F252AA3C for ; Sat, 13 Sep 2014 16:12:04 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XSpvf-0002Zw-82 for freebsd-stable@freebsd.org; Sat, 13 Sep 2014 18:12:03 +0200 Message-ID: <54146CCF.7020107@FreeBSD.org> Date: Sat, 13 Sep 2014 18:11:59 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> <20140911211428.GA6247@anubis.morrow.me.uk> In-Reply-To: <20140911211428.GA6247@anubis.morrow.me.uk> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6cfhPgdJa3VD3NG2wBOenEK444coaMKth" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 16:12:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6cfhPgdJa3VD3NG2wBOenEK444coaMKth Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11.09.2014 23:14, Ben Morrow wrote: > I didn't realise it was possible to load radeonkms after boot. > Presumably if you do that you lose even more of the boot messages when > the new console loads? Currently it appears to lose everything that was= > above the top of the screen when the new driver loaded; it would be > better (if possible) if it were to keep the scrollback as well. When a KMS driver is loaded, the history buffer of vt(4) grows and the current data is preserved. Therefore you should not lose any data. One caveat is that the cursor is put at the top of the screen, so the previous content is off-screen. Another issue is that the history size (hard-coded) is admittedly very small. But data should be there. Could you please describe your problem in more details? --=20 Jean-S=E9bastien P=E9dron --6cfhPgdJa3VD3NG2wBOenEK444coaMKth 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 iQJ8BAEBCgBmBQJUFGzTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMFi4QALjQZLhITrGDfkFf5pOpUBN0 6W+w4XP+xouzyOxpzWUZh2SmvVzAhv87GqMveh6EZh+TP6fzZJIO4UY+nV6jsonm sDmEhJDmmYr0FfZQLLa/pfZUWHCBffd4Rc7gOuDKkmllimBFlz2OnugZ2hA+TeHQ IIdZ+sr0vZn9W6RSv0ij2wxttOgZb2v96koQsXKMLzxDK3L0ucJWjxBKLEf4dCq/ cecOe+1/Ph9dlv4uvA1OQT006jcC1RbwFbn+UAiOaapz9U9Lw9nwuPuiQHl2tPky vWPE5I0+GqNF9sYlw3PTaRQXbB3Ll4TAJevdOF9grSfgW2qiJc6PIhY3rsqQPrIo 738aNORCCuxxiexTTLphpQ+IxQ3KGhsl3y4d3OloQS+BjU2NimbaGy7DeVKr2HCK ygoHYwM501rqSrRIGtZDupeWGmB8pTV8QZGrgDfSRJZ93wfE/TDsq8lRny+Bb+7+ UdKVSZC4CJ5fCom2WK7yzMqkgF88K8o8UDFJ849IosqQk6DdnumubrPNvCFn7N9P u7hpArlqAheD/xQjzfiTy7Uaa9MU0lrI9/grvq6g9z8sBWKAZQuBQifzzF2qdVmh B6H2IR9MHtLFN5Mqo361AZpzTambZq2Ii6Ec6ATQG8XCiCjmrxsPyggPJi1Kwkzp i4Mzoc4QzMm2XTrDybyp =CTI/ -----END PGP SIGNATURE----- --6cfhPgdJa3VD3NG2wBOenEK444coaMKth-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 13 16:37:55 2014 Return-Path: Delivered-To: stable@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 E6622E8B for ; Sat, 13 Sep 2014 16:37:55 +0000 (UTC) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [213.184.43.8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFFFC39 for ; Sat, 13 Sep 2014 16:37:55 +0000 (UTC) Received: from kuller.raad.tartu.ee (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 1EE853986F for ; Sat, 13 Sep 2014 19:29:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by kuller.raad.tartu.ee (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TQOjby9SZBUf for ; Sat, 13 Sep 2014 19:25:55 +0300 (EEST) Received: by kuller.raad.tartu.ee (Postfix, from userid 80) id 9E43D39876; Sat, 13 Sep 2014 19:25:54 +0300 (EEST) Received: from 176.192.196.88.dyn.estpak.ee (176.192.196.88.dyn.estpak.ee [88.196.192.176]) by webmail.raad.tartu.ee (Horde Framework) with HTTP; Sat, 13 Sep 2014 19:25:54 +0300 Message-ID: <20140913192554.188840nzwrt6v42s@webmail.raad.tartu.ee> Date: Sat, 13 Sep 2014 19:25:54 +0300 From: Toomas Aas To: stable@freebsd.org Subject: Failed to attach fbd device: 6 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 88.196.192.176 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 16:37:56 -0000 I just updated my 10-STABLE amd64 machine from r268926 to r271474. My PC has ATI Radeon X1300/X1550 video adapter and I am using radeonkms (loaded from loader.conf) One message in dmesg.boot which wasnt't there before the update caught my eye error: [drm:pid0:drm_fb_helper_single_fb_probe] *ERROR* Failed to attach fbd device: 6 Other than this error message, I am not seeing any ill effects. I'm just curious if something could be done to fix this. Full dmesg: http://www.raad.tartu.ee/~toomas/dmesg.boot Cheers! -- Toomas Aas From owner-freebsd-stable@FreeBSD.ORG Sat Sep 13 20:42:21 2014 Return-Path: Delivered-To: freebsd-stable@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 89F1AC97; Sat, 13 Sep 2014 20:42:21 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 6219486D; Sat, 13 Sep 2014 20:42:20 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 6EBF745087; Sat, 13 Sep 2014 20:42:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 6EBF745087 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1410640934; bh=G+eF+9ANPZM2D6VGugzxTYN9jKGwO+tsxtmVDFrLOqI=; h=Date:From:To:Subject:References:In-Reply-To; b=uaVali5U4bWeGQ05KtWLDd75hqnip/kBKy0wzrzmUyWnnPdLaAFqDE4fv+QBkNr3f wRCRJBPUcIRmpswhp/i/SM9w2+7I14tF8uMvImgYXhbi5VOqxPr639WuajOL8OkkQ9 pwCowzNFWQbT/e6gW6IMF3R8W8m8JEj4PTOpuNfY= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 3410A1517B; Sat, 13 Sep 2014 21:42:12 +0100 (BST) Date: Sat, 13 Sep 2014 21:42:12 +0100 From: Ben Morrow To: dumbbell@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: 10.1 kernel device config for drm2 and kms drivers Message-ID: <20140913204209.GA18072@anubis.morrow.me.uk> Mail-Followup-To: dumbbell@FreeBSD.org, freebsd-stable@freebsd.org References: <20140911064731.GA15930@rwpc15.gfn.riverwillow.net.au> <54115D2A.5020802@FreeBSD.org> <20140911084624.GK2737@kib.kiev.ua> <20140911211428.GA6247@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54146CCF.7020107@FreeBSD.org> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 20:42:21 -0000 Quoth =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= : > On 11.09.2014 23:14, Ben Morrow wrote: > > I didn't realise it was possible to load radeonkms after boot. > > Presumably if you do that you lose even more of the boot messages when > > the new console loads? Currently it appears to lose everything that was > > above the top of the screen when the new driver loaded; it would be > > better (if possible) if it were to keep the scrollback as well. > > When a KMS driver is loaded, the history buffer of vt(4) grows and the > current data is preserved. Therefore you should not lose any data. > > One caveat is that the cursor is put at the top of the screen, so the > previous content is off-screen. Another issue is that the history size > (hard-coded) is admittedly very small. But data should be there. > > Could you please describe your problem in more details? Previously, with syscons, I could usually scroll back after boot had finished and the login: prompt appeared and get all the way up to the start of the kernel messages (the Copyright line). Now, with vt, and loading radeonkms from rc.conf rather than loader.conf, if I switch to the console, I can: scroll up through 8 screens of kernel and userland console messages until I come to a screen which has info: [drm] Initialised drm 1.1.0 20060810 in approximately the middle; then I can scroll up one more screen only, which takes me to somewhere in the middle of probing the USB ports. Looking at dmesg suggests there should be 3 or 4 more screens of messages above that. Obviously I can't be certain without trying more things that this isn't just because the rest has gone off the top of the buffer, but ISTR when I was first changing the machine over to vt that when I didn't load radeonkms and stayed with vt_vga I could still scroll all the way up. I may be misremembering, and/or making assumptions based on the fact the end of the scrollback is about a screenful above drm loading; I can do more experiments next time I reboot the machine if that would be helpful. Ben From owner-freebsd-stable@FreeBSD.ORG Sat Sep 13 21:20:43 2014 Return-Path: Delivered-To: freebsd-stable@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 B7E21C11; Sat, 13 Sep 2014 21:20:43 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8C6B16; Sat, 13 Sep 2014 21:20:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAK60FFSDaFve/2dsb2JhbABfhDuCeM4KgR94hAUoVhsYAgINeohRpxOVNoEsjUojNIRSBbJHg3ohgTZBgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,519,1406606400"; d="scan'208";a="153898247" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 13 Sep 2014 17:06:48 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3412DB4050; Sat, 13 Sep 2014 17:06:48 -0400 (EDT) Date: Sat, 13 Sep 2014 17:06:48 -0400 (EDT) From: Rick Macklem To: Mike Tancsa Message-ID: <1737288805.35881978.1410642408202.JavaMail.root@uoguelph.ca> Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Glen Barber , freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 21:20:43 -0000 Mike Tansca wrote: > On 9/12/2014 7:33 PM, Rick Macklem wrote: > > I wrote: > >> The patches are in 10.1. I thought his report said 10.0 in the message. > >> > >> If Mike is running a recent stable/10 or releng/10.1, then it has been > >> patched for this and NFS should work with TSO enabled. If it doesn't, > >> then something else is broken. > > Oops, I looked and I see Mike was testing r270560 (which would have both > > the patches). I don't have an explanation why TSO and 64K rsize, wsize > > would cause a hang, but does appear it will exist in 10.1 unless it > > gets resolved. > > > > Mike, one difference is that, even with the patches the driver will be > > copying the transmit mbuf list via m_defrag() to 32 MCLBYTE clusters > > when using 64K rsize, wsize. > > If you can reproduce the hang, you might want to look at how many mbuf > > clusters are allocated. If you've hit the limit, then I think that > > would explain it. > > I have been running the test for a few hrs now and no lockups of the > nic, so doing the nfs mount with -orsize=32768,wsize=32768 certainly ? seems to work around the lockup. How do I check the mbuf clusters ? Btw, in the past when reducing the rsize,wsize has fixed a problem that isn't fixed by disabling TSO, it has been a problem w.r.t. receiving a burst of ethernet packets. I believe this may be a problem with either the receive ring size or interrupt latency (testers have reported cases where changing the way the device driver uses interrupts have fixed the problem so that it worked with 64K rsize, wsize). I have no familiarity with this hardware/driver so I can't suggest anything specific to try except maybe how interrupts are handled, if the driver has a sysctl for that. rick