From owner-freebsd-stable@freebsd.org Sun Jun 25 00:55:11 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BD24DA8C33 for ; Sun, 25 Jun 2017 00:55:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (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 1CC627DDF3 for ; Sun, 25 Jun 2017 00:55:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5091 invoked from network); 25 Jun 2017 00:56:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Jun 2017 00:56:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 24 Jun 2017 20:55:08 -0400 (EDT) Received: (qmail 22288 invoked from network); 25 Jun 2017 00:55:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Jun 2017 00:55:08 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AEB10EC86E7; Sat, 24 Jun 2017 17:55:07 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work Message-Id: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> Date: Sat, 24 Jun 2017 17:55:07 -0700 Cc: Pedro Giffuni , Gerald Pfeifer To: re@FreeBSD.org, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Jun 2017 00:55:11 -0000 The following is based mostly on an extraction from a private exchange in which a question was asked and my answer was unsettling: incompatibilities within the 11.* family. I would not normally send to re but doing so was explicitly mentioned. Hopefully this example is reasonable for doing that. Aspect #0: what is broken currently (and in the future?) within the 11.* family? lang/gcc* packages built on release/11.0.1/ to not work fully on stable/11/ or on the drafts of release/11.1.0/ . (I leave releng/11.*/'s implicit.) -r313194 in head and was describied with: > Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >=20 > The types are for the byte offset and page index in vm object. They > are similar to off_t, which is defined as 64bit MI integer. Using MI > definitions will allow to provide consistent MD values of vm > object-related maximum sizes. The known issue is the generation of header dependencies in the lang/gcc* builds on release/11.0.1/ that when used on stable/11/ or release/11.0.1/ generate reports like: = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:266:9: error: '__vm_ooffset_t' does not name a type typedef __vm_ooffset_t vm_ooffset_t; ^ = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:268:9: error: '__vm_pindex_t' does not name a type typedef __vm_pindex_t vm_pindex_t; ^ *** [CoinFactorization2.lo] Error code 1 Unfortunately UPDATING was not updated for head/'s -r313194 (2017-Feb-4) --nor for stable/11/'s -r313574 (2017-Feb-11), the MFC. (No MFC was made to stable/10/ or to release/10.3.0 as far as I found.) (These changes predate the INO64 issue in head/ . Head ends up with more issues than I'm dealing with here.) Aspect #1: what 11.* version builds the pre-built packages targeting 11.* and the apparent consequences (given the vm_ooffset_t and vm_pindex_t changes and the lang/gcc* build behavior) This is the unsettling part for pre-built packages: incompatibilities within the 11.* family for the lang/gcc* packages. = http://portsmon.freebsd.org/portoverview.py?category=3D%3Bamng&portname=3D= gcc5&wildcard=3D shows categories for builds for 8.4 9.3 10.1 10.3 11.0 head (Nothing for stable/*/ .) But the 10.3 rows show no package builds. I would guess that they start once 10.1 stops (approximately). So it may be that 11.1 will not get package builds until 11.0 stops (approximately). If so unless lang/gcc* are changed to bootstrap differently they will configure to match release/11.0.1/ and will not be compatible with the vm_ooffset_t and vm_pindex_t changes in stable/11/ and release/11.1.0/ . But as I understand updating how the lang/gcc* builds work to remove such dependencies is under investigation. I do not know any timing relative to release/11.1.0/ if my understanding is right. Until then (if I was right): Unless there are separate packages made for targeting release/11.0.1/ vs. release/11.1.0/ it is not obvious when lang/gcc* packages will be generally compatible with various folks choices about what to install as the system version within the release/11.*/ and stable/11/ family. This would likely be true even if they were built on release/11.1.0/ : then release/11.0.1/ likely would have compatibility problems. The ABI versioning does not cover the specific issues involved based on how vm_ooffset_t and vm_pindex_t were changed and what the lang/gcc* builds do relative to such changes. Yet there is incompatibility for some fairly-significant-usage ports. Aspect #2: stable/10/ and release/10.4.0/ Just covered for completeness: I do not see a MFC of -r313194 to stable/10/ : its sys/sys/types.h dates back to 2015-Oct-10. So it looks like 10.x has a permanent difference in this area: 10.x continues to get separate lang/gcc* package builds from 11.x and later. No problem for this context as far as I know. Note: To simplify I choose to not be explicit about what authors wrote what original text. If that becomes an issue, it is correctable. Blame me for any errors in the above. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sun Jun 25 09:28:47 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 441EDD8D207 for ; Sun, 25 Jun 2017 09:28:47 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AE7FC64E66 for ; Sun, 25 Jun 2017 09:28:45 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from [192.168.1.14] ([92.156.1.54]) by mwinf5d31 with ME id cxUc1v00819unZo03xUcxe; Sun, 25 Jun 2017 11:28:37 +0200 X-ME-Helo: [192.168.1.14] X-ME-Date: Sun, 25 Jun 2017 11:28:37 +0200 X-ME-IP: 92.156.1.54 Subject: Re: FreeBSD 11.1-BETA3 Now Available To: freebsd-stable@freebsd.org References: <20170624162135.GD69426@FreeBSD.org> From: David Marec Message-ID: <0519f9e6-3058-943d-0a30-6df13045cb55@davenulle.org> Date: Sun, 25 Jun 2017 11:28:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170624162135.GD69426@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Jun 2017 09:28:47 -0000 Le 24.06.2017 à 18:21, Glen Barber a écrit : > > A list of changes since 11.1-RELEASE are available in the stable/11 > release notes: > > https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html > > Please note, the release notes page is not yet complete, and will be > updated on an ongoing basis as the 11.1-RELEASE cycle progresses. > There is a mismatch between the description and the related commit, General Network Changes topic: > The TCP stack has been changed to use the estimated RTT instead of > timestamps for receive buffer auto resizing. > [r317386] r317386 fixed an outbound issue within 'lib/libutil/humanize_number.c' and does not sounds related to the TCP Stack. -- David Marec From owner-freebsd-stable@freebsd.org Mon Jun 26 12:16:48 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECE84DA909B for ; Mon, 26 Jun 2017 12:16:48 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from host202-129-static.10-188-b.business.telecomitalia.it (host202-129-static.10-188-b.business.telecomitalia.it [188.10.129.202]) by mx1.freebsd.org (Postfix) with ESMTP id A5F487649B; Mon, 26 Jun 2017 12:16:48 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from [192.168.0.60] (maurizio-pc [192.168.0.60]) by host202-129-static.10-188-b.business.telecomitalia.it (Postfix) with ESMTP id 69F6B13C26F; Mon, 26 Jun 2017 14:16:40 +0200 (CEST) From: Maurizio Vairani Subject: In FreeBSD 11.1-BETA2/BETA3 VirtualBox bridged network doesn't work To: FreeBSD stable , vbox@freebsd.org Message-ID: <7c8f070d-b63b-b8ef-6d61-3bed29f1f437@cloverinformatica.it> Date: Mon, 26 Jun 2017 14:16:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jun 2017 12:16:49 -0000 Upgrading from 11.0-RELEASE-p9 to FreeBSD 11.1-BETA2 and now to 11.2-BETA3, the VirtualBox bridged network doesn't work. -- Regards Maurizio From owner-freebsd-stable@freebsd.org Mon Jun 26 14:10:44 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6BADD883B7; Mon, 26 Jun 2017 14:10:44 +0000 (UTC) (envelope-from papowell@astart.com) Received: from astart2.astart.com (wsip-72-214-30-30.sd.sd.cox.net [72.214.30.30]) (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 77D877AD24; Mon, 26 Jun 2017 14:10:43 +0000 (UTC) (envelope-from papowell@astart.com) Received: from laptop_103.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.9/8.14.9) with ESMTP id v5QE0j8X082701; Mon, 26 Jun 2017 07:00:46 -0700 (PDT) (envelope-from papowell@astart.com) Reply-To: papowell@astart.com Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> To: freebsd-ports@freebsd.org Cc: Gerald Pfeifer , Dimitry Andric , Konstantin Belousov , freebsd-stable@freebsd.org, Jung-uk Kim , "papowell@astart.com" , Ian Cameron From: Patrick Powell Organization: Astart Technologies Message-ID: <9b7cf494-1a81-4151-92fe-4a3305b17cb1@astart.com> Date: Mon, 26 Jun 2017 07:00:45 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jun 2017 14:10:44 -0000 I have reported this problem - see email to freebsd-stable Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition Here is part of the discussion: On Sat, 29 Apr 2017, Dimitry Andric wrote: > This is because gcc's fixincludes process makes copies of certain system > headers (in this case, /usr/include/sys/types.h) with slight > modifications. Then, it places the directory containing the modified > headers at the front of the include search path. So far so good. > > Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t > change, the header in gcc's own preferred directory might not match the > definitions which are expected, leading to compilation errors. >> If the port/package is builts from scratch, does this trigger the >> problem? > Yes, basically you need to rebuild all gcc ports from scratch, whenever > you update any system header that matches gcc's list of files it wants > to modify. That, or run the fixinc.sh script in ./libexec/gcc/$TARGETTRIPLET/$VERSION/install-tools/fixinc.sh. The proposed patch would help with that, but still require a manual run, hence my original question. On Sun, 30 Apr 2017, Konstantin Belousov wrote: > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. > > The change blocks any future changes to the type that might occur in the > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. Okay, thanks for your feedback. > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. This is what I figured, too, and plan on giving a try. It probably warrants an -exp run to be on the safe side. On Sun, 30 Apr 2017, Dimitry Andric wrote: > I agree, it would be best to avoid storing any copies of system headers > completely. > > Maybe the port can have an option FIX_INCLUDES, which defaults to off? > I am not sure if there is anybody that really wants these 'fixed' > headers, though. There are two infrastructure improvements for the (current) GCC ports (orthogonal to a few simpler things I've been simplifying today in older ports) that I'd like to conclude first, otherwise there'll be too many balls in the air. (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218475 is the last hold-off on the first of them, in case anyone can give this a try. It is on my list to pursue directly afterwards, then. (Luckily this only hits with most -CURRENT versions of FreeBSD and older packages only.) Gerald On 06/24/17 17:55, Mark Millard wrote: > The following is based mostly on an extraction from a > private exchange in which a question was asked and my > answer was unsettling: incompatibilities within the > 11.* family. I would not normally send to re but doing > so was explicitly mentioned. Hopefully this example is > reasonable for doing that. > > > Aspect #0: what is broken currently (and in the future?) > within the 11.* family? > > lang/gcc* packages built on release/11.0.1/ to not work > fully on stable/11/ or on the drafts of > release/11.1.0/ . (I leave releng/11.*/'s implicit.) > > -r313194 in head and was describied with: > >> Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >> >> The types are for the byte offset and page index in vm object. They >> are similar to off_t, which is defined as 64bit MI integer. Using MI >> definitions will allow to provide consistent MD values of vm >> object-related maximum sizes. > The known issue is the generation of header dependencies > in the lang/gcc* builds on release/11.0.1/ that when > used on stable/11/ or release/11.0.1/ generate reports > like: > > /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a type > typedef __vm_ooffset_t vm_ooffset_t; > ^ > /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a type > typedef __vm_pindex_t vm_pindex_t; > ^ > *** [CoinFactorization2.lo] Error code 1 > > Unfortunately UPDATING was not updated > for head/'s -r313194 (2017-Feb-4) --nor for > stable/11/'s -r313574 (2017-Feb-11), the MFC. > (No MFC was made to stable/10/ or to > release/10.3.0 as far as I found.) > > (These changes predate the INO64 issue in head/ . > Head ends up with more issues than I'm dealing > with here.) > > > Aspect #1: what 11.* version builds the pre-built packages > targeting 11.* and the apparent consequences > (given the vm_ooffset_t and vm_pindex_t changes > and the lang/gcc* build behavior) > > This is the unsettling part for pre-built > packages: incompatibilities within the 11.* > family for the lang/gcc* packages. > > http://portsmon.freebsd.org/portoverview.py?category=%3Bamng&portname=gcc5&wildcard= > > shows categories for builds for > > 8.4 > 9.3 > 10.1 > 10.3 > 11.0 > head > > (Nothing for stable/*/ .) > > But the 10.3 rows show no package > builds. I would guess that they > start once 10.1 stops > (approximately). > > So it may be that 11.1 will not > get package builds until 11.0 > stops (approximately). > > If so unless lang/gcc* are changed > to bootstrap differently they will > configure to match release/11.0.1/ > and will not be compatible with the > vm_ooffset_t and vm_pindex_t changes > in stable/11/ and release/11.1.0/ . > > But as I understand updating how the > lang/gcc* builds work to remove such > dependencies is under investigation. > I do not know any timing relative to > release/11.1.0/ if my understanding > is right. > > Until then (if I was right): > > Unless there are separate packages made for > targeting release/11.0.1/ vs. release/11.1.0/ > it is not obvious when lang/gcc* packages > will be generally compatible with various > folks choices about what to install as the > system version within the release/11.*/ > and stable/11/ family. This would likely > be true even if they were built on > release/11.1.0/ : then release/11.0.1/ > likely would have compatibility problems. > > The ABI versioning does not cover the specific > issues involved based on how vm_ooffset_t and > vm_pindex_t were changed and what the > lang/gcc* builds do relative to such changes. > Yet there is incompatibility for some > fairly-significant-usage ports. > > > Aspect #2: stable/10/ and release/10.4.0/ > > Just covered for completeness: > > I do not see a MFC of -r313194 to stable/10/ : > its sys/sys/types.h dates back to 2015-Oct-10. > So it looks like 10.x has a permanent difference > in this area: 10.x continues to get separate > lang/gcc* package builds from 11.x and later. > No problem for this context as far as I know. > > > > > Note: To simplify I choose to not be explicit > about what authors wrote what original text. > If that becomes an issue, it is correctable. > > Blame me for any errors in the above. > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com From owner-freebsd-stable@freebsd.org Mon Jun 26 14:36:58 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51198D88D90; Mon, 26 Jun 2017 14:36:58 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0191F7BAFF; Mon, 26 Jun 2017 14:36:58 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-ua0-x22d.google.com with SMTP id 70so2052976uau.0; Mon, 26 Jun 2017 07:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eLJC3DaMFhxev2U7RyM84p6FOR/QOX+FGgwQi+EeruU=; b=KIw+jUmHLosjac+4f1585lcBf/vh2n4jd/cx53THr0r9fvbpVlcg7qT2m+jn7+g/LQ xs2xdT4W9V0gppJ1IibMP3PZF/XLsqGTqwmWcaAtKia4lVZwwCoJQHRN4Y3rbzTfYcH4 t+0unczepOnoysXrvPDhaokUd1UwcS/UQvN9cdMNF7EQC3tWLMUSOSFlMcrnCCaUva55 WRHWEE4bu43kaPbEfbloyfQoblxwcFvmcDEutdEn1lg9whX1fWLVx0LDBSqwcm3Nhy14 0NQOhCs3iL/bf8OJEpLDWcjLNNTNGdQnPJi3UEzYB6ZcIG3zh6WnfY4yESJ9wX3/XVcI NvxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=eLJC3DaMFhxev2U7RyM84p6FOR/QOX+FGgwQi+EeruU=; b=sgaQTH8xPHtOpHPTichr92U/r/PDrtkDUSXYMwr4xxTCTMofW0DXwscmIOeJD82Tou eA/oTaNe9HHdOhgoQNz21GE5iKM/7cj+ouCgiK1cG9CYgLQU/pV3au2yCapTdgR7htpC FJRqJa9yUGUpZ7FFTFMg3RHAlVKzyDW6ocGCG2TxAiNt5C2rTuYyjFHIry6dJ4UeznMo LaHziBxJsSY+8yRtV4sX3CQE6YTqEG0zAYeX5g1+/8q+wS8LKw2VZYRJgCmJPOs3oCr8 ZPt98l4MV+QxkGgYYOfWMCH7q7+vdCwWErdv7JT2wey9mqBcaXA4WB2pwh0bs4ryIFkz Z/rg== X-Gm-Message-State: AKS2vOxjH++hfxctLZ0UHccv5kfKVoPPdfWrZ48jw2iv9tIrV0p0qu5C ixrg0kYNIsN37rtK7GXXO/cISAMfL1Vw X-Received: by 10.176.77.155 with SMTP id s27mr246693uag.75.1498487816823; Mon, 26 Jun 2017 07:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.239 with HTTP; Mon, 26 Jun 2017 07:36:56 -0700 (PDT) Reply-To: araujo@freebsd.org In-Reply-To: References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> From: Marcelo Araujo Date: Mon, 26 Jun 2017 22:36:56 +0800 Message-ID: Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) To: Guido Falsi Cc: Warner Losh , FreeBSD FS , Glen Barber , FreeBSD-STABLE Mailing List , Jonathan Chen , Peter Blok Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jun 2017 14:36:58 -0000 2017-06-23 4:02 GMT+08:00 Guido Falsi : > On 06/22/17 19:06, Guido Falsi wrote: > >> On 06/22/17 18:38, Warner Losh wrote: >> > > I'll followup as soon as I have easier use case to reproduce it. I first >> need to revert to an image affected by the problem. >> > > I have made a few more tests. > > I am able to trigger this bug easily by running gpart. > > I'm testing on a PCEngines APU2 board with SD memory card. > > # gpart set -a active -i 1 mmcsd0 > active set on mmcsd0s1 > # fsck_ffs -n /dev/mmcsd0s1a > ** /dev/mmcsd0s1a (NO WRITE) > ** Last Mounted on /mnt > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > Segmentation fault > # shutdown -r now > /sbin/shutdown: Device not configured > > also, if I open another shell I can't perform many other operations which > are not failing in the previous root shell: > > > tail /var/log/messages > /usr/bin/tail: Device not configured. > > > BTW while testing this multiple times I also had the root shell segfault > while browsing history, so it should be quite easy to reproduce on your > side too. running the gpart set command triggers it every time, with > slightly different bu always disruptive symptoms. > > There is a chance it only shows with these embedded systems storage > controllers though. > > -- > Guido Falsi > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Hi, Could you guys test this patch: https://reviews.freebsd.org/D11365? Would it solve the issue? Best, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-stable@freebsd.org Mon Jun 26 16:57:17 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE65AD8C037 for ; Mon, 26 Jun 2017 16:57:17 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EF1B804B1 for ; Mon, 26 Jun 2017 16:57:17 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-wm0-x232.google.com with SMTP id b184so3295057wme.1 for ; Mon, 26 Jun 2017 09:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eY7YZKSeGt2ouVe3Ng6rinev0V5B4TsKrNP1B7Ifez8=; b=BcvnLAsj1B0lXk8MaHpefFxXgX5kd+1LXU/3MhLUzwaTu8jI3UUiZQdZ01OvRTUiWx fPgb++3hAQnI5Gt0w+YGD4LfWaytTec0BCNd94F4FzP2INir7IHvI+Ci1jm4PauelB3M /VxpWzLgEhi3UFuk/dsnXNHlSvuAzl486WT1f2SgXoTFKUFZExz4wwMnSNLNzZWaUnKy DAFb6tUd6RoK/1KnKXx8tM7c+r0+h6tioHyYqING4i1PalMs4PtOl8ndn7IBW4+6T2vA fPmsVHw7fCRu1fB1RYNIkyx9Q6O584RnfSGRN2SAwT9S6wt3XnGlZi5E8qWh83EhNcrQ 0QWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eY7YZKSeGt2ouVe3Ng6rinev0V5B4TsKrNP1B7Ifez8=; b=ldaQgPHclyezTHqKnpJ01cROD9adLR7B6/hUnJwqHW8QhTGDpn7TcJk7ew7LdYPIf7 8yeJDgkM811EzikdX7H3vN5sypoMBoH57Sjh3n6DpPSrcel1/QKQEvS+0wdkzWSvLVmN aHZkj5GKdBH0/53U26WrtKACJg8n8wj1smz8UzxmhzPwtRZo/hDxRio6J0z2chKxc9K3 yghgLW5p8pTj6LsEmaxBnx0khaacni3xsP6fwBPP39+wfQupkF1soxQ3VFzz+Wa89WB9 KcxJ/WLjDg8wTUib3Lq1oVBl20qBH1st1H8+ajw3O6KQX/U2siLA3WpthkCxagLBHS0s 6oTg== X-Gm-Message-State: AKS2vOwnMsFLTTydKgPCxhUpJMKP8cBhAwNk1A48QaVVrwOBaRnDT9Ck BRznetFTxngFGk89v/YURUIS4wW4jRyw2uc= X-Received: by 10.80.163.210 with SMTP id t18mr775234edb.158.1498496235556; Mon, 26 Jun 2017 09:57:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.178.134 with HTTP; Mon, 26 Jun 2017 09:57:15 -0700 (PDT) X-Originating-IP: [38.104.68.66] From: Mark Saad Date: Mon, 26 Jun 2017 12:57:15 -0400 Message-ID: Subject: Dell r630 UEFI Boot Issues on 11.1-BETA1 To: FreeBSD-Stable ML Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jun 2017 16:57:17 -0000 All I ran in to this issue on stable/11 today . I feel like I saw this in the past but I can't track it down. This is a new install on a brand new Dell r630 fitted with 2x e5-2699v4 cpus . Fresh install of 11.0-RELEASE amd64 install . The install is a ZFS pool on a ssd. I checked out svn stable/11 and built and installed world. The subsequent reboot died with what appears to be an issue with the ZFS EFI loader. I uploaded a screen shot to imgur . http://imgur.com/t9clwXL The Text is a follows Start @ 0xffffffff80302000 ... EFI framebuffer information: addr, size 0x90000000, 0x300000 dimensions 1024 x 768 stride 1024 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 bi_load_efi_data: GetMemoryMap error 5 _ Any one have any ideas here ? -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@freebsd.org Mon Jun 26 18:11:31 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B352D8D83E; Mon, 26 Jun 2017 18:11:31 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from smtpq6.tb.mail.iss.as9143.net (smtpq6.tb.mail.iss.as9143.net [212.54.42.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF311826D6; Mon, 26 Jun 2017 18:11:30 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from [212.54.42.134] (helo=smtp10.tb.mail.iss.as9143.net) by smtpq6.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dPYTp-000621-EP; Mon, 26 Jun 2017 20:11:21 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp10.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dPYTp-0001hU-Ab; Mon, 26 Jun 2017 20:11:21 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id A364D21B; Mon, 26 Jun 2017 20:11:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1S9-VQDCGRA; Mon, 26 Jun 2017 20:11:18 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 81F0F211; Mon, 26 Jun 2017 20:11:18 +0200 (CEST) From: Peter Blok Message-Id: <2D4D4BE2-1D05-43EF-8964-6478EE612175@bsd4all.org> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) Date: Mon, 26 Jun 2017 20:11:17 +0200 In-Reply-To: Cc: Guido Falsi , Warner Losh , FreeBSD FS , Glen Barber , FreeBSD-STABLE Mailing List , Jonathan Chen To: araujo@freebsd.org References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=S5Wp+MkP c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=LWSFodeU3zMA:10 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=j90g3uC65GxMD2nljHgA:9 a=QEXdDO2ut3YA:10 a=vUPWEWiMAAAA:8 a=ERGEnrLWe0TpccyqpOEA:9 a=H4FIEKXvFUr3Javy:21 a=_W_S_7VecoQA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=IjZwj45LgO3ly-622nXo:22 a=s3Yi14Of9AgBIP63TAoC:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jun 2017 18:11:31 -0000 Marcelo, This fix solved the problem for RPI-1B. I=E2=80=99ll do some more = testing on other RPI and nanobsd variants. Peter > On 26 Jun 2017, at 16:36, Marcelo Araujo = wrote: >=20 >=20 >=20 > 2017-06-23 4:02 GMT+08:00 Guido Falsi >: > On 06/22/17 19:06, Guido Falsi wrote: > On 06/22/17 18:38, Warner Losh wrote: >=20 > I'll followup as soon as I have easier use case to reproduce it. I = first need to revert to an image affected by the problem. >=20 > I have made a few more tests. >=20 > I am able to trigger this bug easily by running gpart. >=20 > I'm testing on a PCEngines APU2 board with SD memory card. >=20 > # gpart set -a active -i 1 mmcsd0 > active set on mmcsd0s1 > # fsck_ffs -n /dev/mmcsd0s1a > ** /dev/mmcsd0s1a (NO WRITE) > ** Last Mounted on /mnt > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > Segmentation fault > # shutdown -r now > /sbin/shutdown: Device not configured >=20 > also, if I open another shell I can't perform many other operations = which are not failing in the previous root shell: >=20 > > tail /var/log/messages > /usr/bin/tail: Device not configured. >=20 >=20 > BTW while testing this multiple times I also had the root shell = segfault while browsing history, so it should be quite easy to reproduce = on your side too. running the gpart set command triggers it every time, = with slightly different bu always disruptive symptoms. >=20 > There is a chance it only shows with these embedded systems storage = controllers though. >=20 > --=20 > Guido Falsi > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs = > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org = " >=20 >=20 > Hi, >=20 > Could you guys test this patch: https://reviews.freebsd.org/D11365 = ? > Would it solve the issue? >=20 > Best, > --=20 >=20 > --=20 > Marcelo Araujo (__) > araujo@FreeBSD.org \\\'',) > http://www.FreeBSD.org \/ \ ^ > Power To Server. .\. /_) From owner-freebsd-stable@freebsd.org Mon Jun 26 19:12:31 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29D94D8EBEB for ; Mon, 26 Jun 2017 19:12:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 D7E22849C8 for ; Mon, 26 Jun 2017 19:12:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6336 invoked from network); 26 Jun 2017 19:05:49 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Jun 2017 19:05:49 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 26 Jun 2017 15:05:49 -0400 (EDT) Received: (qmail 11654 invoked from network); 26 Jun 2017 19:05:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jun 2017 19:05:48 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0DF63EC86E7; Mon, 26 Jun 2017 12:05:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work From: Mark Millard In-Reply-To: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> Date: Mon, 26 Jun 2017 12:05:47 -0700 Cc: FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni , Gerald Pfeifer Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> To: papowell@astart.com X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jun 2017 19:12:31 -0000 Top post on one point. . . Patrick Powell papowell at astart.com wrote on Mon Jun 26 14:10:44 UTC = 2017 (He was quoting Gerald. I was also part of some earlier discussions.) > (Luckily this only hits with most -CURRENT versions of FreeBSD and > older packages only.) >=20 > Gerald Unfortunately this part is false if it is about the vm_ooffset_t and vm_pindex_t issue: stable/11/ and release/11.1.0/ also have the vm_ooffset_t and vm_pindex_t issue vs. lang/gcc* packages built by release/11.0.1/ . The issue is not limited to head (12) at this point: Installing a gcc* package built by release/11.0.1/ fails now for stable/11/ and the drafs oft release/11.1.0/ . Anyone progressing to one of those has to build the lang/gcc* of interest from source under the newer system context. (Mixing source builds and package builds is discouraged as I understand.) I'm not claiming which specific handling needs to be made. But the vm_ooffset_t and vm_pindex_t changes did not even make the UPDATING notes. Right now things look to have the worst combination for lang/gcc* when release/11.1.0/ becomes official: lang/gcc* 's break without notification or suggestion of a workaround. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jun-24, at 5:55 PM, Mark Millard wrote: The following is based mostly on an extraction from a private exchange in which a question was asked and my answer was unsettling: incompatibilities within the 11.* family. I would not normally send to re but doing so was explicitly mentioned. Hopefully this example is reasonable for doing that. Aspect #0: what is broken currently (and in the future?) within the 11.* family? lang/gcc* packages built on release/11.0.1/ to not work fully on stable/11/ or on the drafts of release/11.1.0/ . (I leave releng/11.*/'s implicit.) -r313194 in head and was describied with: > Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >=20 > The types are for the byte offset and page index in vm object. They > are similar to off_t, which is defined as 64bit MI integer. Using MI > definitions will allow to provide consistent MD values of vm > object-related maximum sizes. The known issue is the generation of header dependencies in the lang/gcc* builds on release/11.0.1/ that when used on stable/11/ or release/11.0.1/ generate reports like: = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:266:9: error: '__vm_ooffset_t' does not name a type typedef __vm_ooffset_t vm_ooffset_t; ^ = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:268:9: error: '__vm_pindex_t' does not name a type typedef __vm_pindex_t vm_pindex_t; ^ *** [CoinFactorization2.lo] Error code 1 Unfortunately UPDATING was not updated for head/'s -r313194 (2017-Feb-4) --nor for stable/11/'s -r313574 (2017-Feb-11), the MFC. (No MFC was made to stable/10/ or to release/10.3.0 as far as I found.) (These changes predate the INO64 issue in head/ . Head ends up with more issues than I'm dealing with here.) Aspect #1: what 11.* version builds the pre-built packages targeting 11.* and the apparent consequences (given the vm_ooffset_t and vm_pindex_t changes and the lang/gcc* build behavior) This is the unsettling part for pre-built packages: incompatibilities within the 11.* family for the lang/gcc* packages. = http://portsmon.freebsd.org/portoverview.py?category=3D%3Bamng&portname=3D= gcc5&wildcard=3D shows categories for builds for 8.4 9.3 10.1 10.3 11.0 head (Nothing for stable/*/ .) But the 10.3 rows show no package builds. I would guess that they start once 10.1 stops (approximately). So it may be that 11.1 will not get package builds until 11.0 stops (approximately). If so unless lang/gcc* are changed to bootstrap differently they will configure to match release/11.0.1/ and will not be compatible with the vm_ooffset_t and vm_pindex_t changes in stable/11/ and release/11.1.0/ . But as I understand updating how the lang/gcc* builds work to remove such dependencies is under investigation. I do not know any timing relative to release/11.1.0/ if my understanding is right. Until then (if I was right): Unless there are separate packages made for targeting release/11.0.1/ vs. release/11.1.0/ it is not obvious when lang/gcc* packages will be generally compatible with various folks choices about what to install as the system version within the release/11.*/ and stable/11/ family. This would likely be true even if they were built on release/11.1.0/ : then release/11.0.1/ likely would have compatibility problems. The ABI versioning does not cover the specific issues involved based on how vm_ooffset_t and vm_pindex_t were changed and what the lang/gcc* builds do relative to such changes. Yet there is incompatibility for some fairly-significant-usage ports. Aspect #2: stable/10/ and release/10.4.0/ Just covered for completeness: I do not see a MFC of -r313194 to stable/10/ : its sys/sys/types.h dates back to 2015-Oct-10. So it looks like 10.x has a permanent difference in this area: 10.x continues to get separate lang/gcc* package builds from 11.x and later. No problem for this context as far as I know. Note: To simplify I choose to not be explicit about what authors wrote what original text. If that becomes an issue, it is correctable. Blame me for any errors in the above. =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Mon Jun 26 20:18:46 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 061AED90AE0; Mon, 26 Jun 2017 20:18:46 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 B824C64168; Mon, 26 Jun 2017 20:18:45 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3wxL3l3PYPzb57; Mon, 26 Jun 2017 22:18:43 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id vhSOYniRzazE; Mon, 26 Jun 2017 22:18:41 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Mon, 26 Jun 2017 22:18:41 +0200 (CEST) Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) To: araujo@freebsd.org Cc: FreeBSD-STABLE Mailing List , FreeBSD FS , Glen Barber , Jonathan Chen , Peter Blok References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> From: Guido Falsi Message-ID: <5a869fee-c79c-cfd8-6b02-f1b8b2507c2a@FreeBSD.org> Date: Mon, 26 Jun 2017 22:18:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 26 Jun 2017 20:18:46 -0000 On 06/26/17 16:36, Marcelo Araujo wrote: > Hi, > > Could you guys test this patch: https://reviews.freebsd.org/D11365? > Would it solve the issue? > Hi, I confirm the patch fixes the problem for me. Thanks! -- Guido Falsi From owner-freebsd-stable@freebsd.org Tue Jun 27 01:26:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 432EAD973E0; Tue, 27 Jun 2017 01:26:13 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E77627291F; Tue, 27 Jun 2017 01:26:12 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-ua0-x230.google.com with SMTP id g40so10518808uaa.3; Mon, 26 Jun 2017 18:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hdd2Gh1nrQBvvgjCGK3WmfWoOEJCRE9ZcLLER2Wgx78=; b=DR/LlAuubqnRWe0eZfD6cZCgB8ejjWhUeb7gs7Yw/1YgrSbwlkBTSvSlT/AGTraMHu nlql/u2REANLYBpyAT/DikXvgSOnI9uiVl370BteauAYmryUcFHo42Y+FAwdsEWSOX3Q DCh/pczaZoxCPvLU9EZ57xqZLqrdqleCmNEnf1hjEdInGrAqBFOoR+e3v34l5pknnAWd OSsoJeynBLEGOflYABNxDnQXu0zRaAtW59hbCd2ikiwufl+IuiLbuX1QZ3KQ1nrFJ3Uk wiztEHaV5FLADCRD03Y/HPA23zQG1kNS8IWn5wDLn5umA5Mt2jBpxNicwRtWoHMYE3VZ BanQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=hdd2Gh1nrQBvvgjCGK3WmfWoOEJCRE9ZcLLER2Wgx78=; b=CfEcuFUxt2z3vrGfko8Y1WQPoFmb8cEbW7Zxby3XQAfAxm87c80DWCmhK0hGxB4BBC 6p8w57Lhp7/dCJI1bJgT4IB8KPxD9RRlR50kDwrygjZht3fj20ItIZ+Wa18dAHfnCCT7 6Yz2/fL6NKzREkKuZ9bBs9/cI1drRNJ9iC05dKLWz90GIaXYZ1Q4LbRkzfnVG+pLleqo OGeOFTXP+QwKv653WgqL1au3w4sYbOdeJm8k3N/AJp1kk2mnidjZvT5JAGAuDzv+4lbn Egmb1vNOlwnb95Xyp4aJP9YhsJ2AdjZOvy9b6w2RbeJgCLx4q0fP4viIxgRjMPfJvaGm 8Myg== X-Gm-Message-State: AKS2vOzKjTCs05E5bFGPIymvcx4bLS/2pqnCcZizQqKayBhMzGxym6Mr lWC88qiCVhugKTbFGgpRw2KJ58LW9pxR X-Received: by 10.176.77.155 with SMTP id s27mr1448542uag.75.1498526771505; Mon, 26 Jun 2017 18:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.239 with HTTP; Mon, 26 Jun 2017 18:26:11 -0700 (PDT) Reply-To: araujo@freebsd.org In-Reply-To: <5a869fee-c79c-cfd8-6b02-f1b8b2507c2a@FreeBSD.org> References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> <5a869fee-c79c-cfd8-6b02-f1b8b2507c2a@FreeBSD.org> From: Marcelo Araujo Date: Tue, 27 Jun 2017 09:26:11 +0800 Message-ID: Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) To: Guido Falsi Cc: FreeBSD-STABLE Mailing List , FreeBSD FS , Glen Barber , Jonathan Chen , Peter Blok Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jun 2017 01:26:13 -0000 2017-06-27 4:18 GMT+08:00 Guido Falsi : > On 06/26/17 16:36, Marcelo Araujo wrote: > > Hi, >> >> Could you guys test this patch: https://reviews.freebsd.org/D11365? >> Would it solve the issue? >> >> > Hi, > > I confirm the patch fixes the problem for me. > > Thanks! > > -- > Guido Falsi > Thanks all for the test, very appreciated! I just committed it: r320390 with MFC for 3 days. Also thanks trasz@ to point me out to this thread that I was not aware of. Best, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-stable@freebsd.org Tue Jun 27 12:26:45 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB418DA951A for ; Tue, 27 Jun 2017 12:26:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9008641CD for ; Tue, 27 Jun 2017 12:26:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5RCQhc0032363 for ; Tue, 27 Jun 2017 12:26:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Tue, 27 Jun 2017 12:26:43 +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: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 27 Jun 2017 12:26:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 --- Comment #34 from Cassiano Peixoto --- (In reply to Mateusz Guzik from comment #26) Dear Mateusz, Please, Can you confirm if it has been fixed in last STABLE? I've seen some commits but i'm no sure. Thanks. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Wed Jun 28 10:23:49 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23DA5D9E408; Wed, 28 Jun 2017 10:23:49 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E558373560; Wed, 28 Jun 2017 10:23:48 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (localhost [127.0.0.1]) by ainaz.pair.com (Postfix) with ESMTP id 686653F56A; Wed, 28 Jun 2017 06:23:41 -0400 (EDT) Received: from [192.168.1.109] (unknown [202.188.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 811703F569; Wed, 28 Jun 2017 06:23:24 -0400 (EDT) Date: Wed, 28 Jun 2017 18:21:59 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work To: Mark Millard ,papowell@astart.com CC: FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni , Gerald Pfeifer From: Gerald Pfeifer Message-ID: <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 28 Jun 2017 10:23:49 -0000 Hi everyone, I am testing a patch for gcc5-devel right now that will disable fixinclude= s (or rather its fixed files) being packaged=2E Should that work fine for you, I will push this back to gcc5 the following= days=2E That said, the change that triggered this is what I would expect on CURREN= T, not STABLE (and hence hoped we'd have more time for this change)=2E My Internet connectivity right now is only slightly above pigeon speed, so= sorry for any delays=2E Gerald From owner-freebsd-stable@freebsd.org Wed Jun 28 14:45:36 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BADCDA3A5C for ; Wed, 28 Jun 2017 14:45:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-23.reflexion.net [208.70.210.23]) (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 E73497BDBA for ; Wed, 28 Jun 2017 14:45:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14927 invoked from network); 28 Jun 2017 14:38:54 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Jun 2017 14:38:54 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 28 Jun 2017 10:38:54 -0400 (EDT) Received: (qmail 25256 invoked from network); 28 Jun 2017 14:38:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Jun 2017 14:38:54 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8936BEC9004; Wed, 28 Jun 2017 07:38:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work From: Mark Millard In-Reply-To: <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> Date: Wed, 28 Jun 2017 07:38:52 -0700 Cc: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 28 Jun 2017 14:45:36 -0000 On 2017-Jun-28, at 3:21 AM, Gerald Pfeifer wrote: > I am testing a patch for gcc5-devel right now that will disable = fixincludes (or rather its fixed files) being packaged. >=20 > Should that work fine for you, I will push this back to gcc5 the = following days. >=20 > That said, the change that triggered this is what I would expect on = CURRENT, not STABLE (and hence hoped we'd have more time for this = change). >=20 > My Internet connectivity right now is only slightly above pigeon = speed, so sorry for any delays. Thanks! Some notes: A primary test is building lang/gcc5-devel under release/11.0.1 and then using it under stable/11 or some draft of release/11.1.0 . It looks like the the lang/gcc5-devel build still creates and uses the headers that go in include-fixed/ but that they are removed from $(STAGEDIR}${TARGLIB} 's tree before installation or packaging. So, if I understand right, lang/gcc5-devel itself still does use the adjusted headers to produce its own materials but when lang/gcc5-devel is used later it does not. Definitely something to be testing since it is a mix overall. Is some form of exp-like run needed that tries to force use of a release/11.0.1 built lang/gcc5-devel (-r444563) to build other things under, say, stable/11 or some draft of release/11.1.0 ? Is this odd combination even possible currently? A normal exp-run on release/11.0.1 without a system version switch being involved also seems appropriate. The same could be said of an exp-run based on a release/11.1.0 draft for both building lang/gcc5-devel and using it to build other things. I had hoped that the Linux =46rom Scratch technique of doing: sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in (or an equivalent) before gcc/Makefile.in is used would allow lang/gcc5-devel to use the same headers in its build that the installed compiler would then use to produce other code --by avoiding generating most of the adjusted files in the first place. But I guess that did not work out. Eventually most of the lang/gcc* 's will need whatever technique is used. Some, such as lang/gcc6-aux, need more done because of binary bootstrap materials being downloaded and used and so the build of lang/gcc6-aux gets the problem and fails before staging happens: the binary-bootstrap materials need to avoid the adjusted headers that they currently contain. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Thu Jun 29 08:24:33 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 611BCD968FF for ; Thu, 29 Jun 2017 08:24:33 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 097AF7ADF2 for ; Thu, 29 Jun 2017 08:24:32 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v5T8OTmT023676; Thu, 29 Jun 2017 10:24:29 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id E3AC9FF1; Thu, 29 Jun 2017 10:24:28 +0200 (CEST) Message-ID: <5954B93C.8060101@omnilan.de> Date: Thu, 29 Jun 2017 10:24:28 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Toomas Soome CC: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <591B2523.6040101@omnilan.de> <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> <591B284B.6070204@omnilan.de> In-Reply-To: <591B284B.6070204@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 29 Jun 2017 10:24:29 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 08:24:33 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 18:26 (localtime): > B … >>>> The issue is, that current UEFI implementation is using 64MB staging >>>> memory for loading the kernel and modules and files. When the boot is >>>> called, the relocation code will put the bits from staging area into the >>>> final places. The BIOS version does not need such staging area, and that >>>> will explain the difference. >>>> >>>> I actually have different implementation to address the same problem, >>>> but thats for illumos case, and will need some work to make it usable >>>> for freebsd; the idea is actually simple - allocate staging area per >>>> loaded file and relocate the bits into the place by component, not as >>>> continuous large chunk (this would also allow to avoid the mines like >>>> planted by hyperv;), but right now there is no very quick real solution >>>> other than just build efi loader with larger staging size. >>> Ic, thanks for the explanation. >>> While not aware about the purpose of the staging area nor the >>> consequences of enlarging it, do you think it's feasable increasing it >>> to 768Mib? >>> >>> At least now I have an idea baout the issue and an explanation why >>> reducing md_imgae to 100MB hasn't helped – still more than 64... >>> >>> Any quick hint where to define the staging area size highly appreciated, >>> fi there are no hard objections against a 768MB size. >>> >>> -harry >> The problem is that before UEFI Boot Services are not switched off, the memory is managed (and owned) by the firmware, > Hmm, I've been expecting something like that (owend by firmware) ;-) > > So I'll stay with CSM for now, and will happily be an early adopter if > you need someone to try anything (-stable mergable). Toomas, thanks for your help so far! I'm just curious if there's news on this. Was there a decision made whether kernel should be utilized to relocate the MD image modules or the loader should be extended to handle (x-)large staging areas? I'd like to switch back to UEFI booting for various reasons (most priority has consistency), but can't since it breaks md-rootfs with that machine (the other run ESXi still). If there's anything to test, please let me know. Thanks, -harry From owner-freebsd-stable@freebsd.org Thu Jun 29 08:39:59 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2961DD96F4A for ; Thu, 29 Jun 2017 08:39:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE1167B698 for ; Thu, 29 Jun 2017 08:39:58 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OSA00800VTLO300@st13p35im-asmtp002.me.com> for freebsd-stable@freebsd.org; Thu, 29 Jun 2017 08:39:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1498725578; bh=IowHEC/GkSaJLdQYYgVkQTgyo79PJK4phq8dkrrlY+U=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=CEsb4VgeVeA4ofbkJWl0jbiKlMIL0Z5TOahxdipLJam12sWo8kB27pqcHkpQhBvDB 3Q5FaFErcKrB1SpH1JDr8/sEhe1Unaq8Uda/k70cKaMD5KxQp8TmPCmKIyqC7AwNVH 3eNE1HK8hWeKbsvoxHk6GAgkeDlLgMpIWw9C9mQbfjfDQ9/5U6zBAUHmnP6bKZUCLk rh3k5AOX1Y9jKeRs0VZMeCBXBKpAF94M8iniDNTbnPEqe/I4JkfzlNuiepVen49cue 7+oLsnPtaHeTXdODykeR6zwQdjZ/J6Td+cf/ThY7y8i46sWhyjL/8E8GTc3zdcRDmg 99xtUhCnjg39w== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OSA00NOGW1Y7Q20@st13p35im-asmtp002.me.com>; Thu, 29 Jun 2017 08:39:38 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-29_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706290140 From: Toomas Soome Message-id: <72722005-6EDF-44EC-A4A7-4E3CB2B0F0BD@me.com> MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? Date: Thu, 29 Jun 2017 11:39:33 +0300 In-reply-to: <5954B93C.8060101@omnilan.de> Cc: freebsd-stable@freebsd.org To: Harry Schmalzbauer References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <591B2523.6040101@omnilan.de> <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> <591B284B.6070204@omnilan.de> <5954B93C.8060101@omnilan.de> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 08:39:59 -0000 > On 29. juuni 2017, at 11:24, Harry Schmalzbauer = wrote: >=20 > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 18:26 = (localtime): >> B > =E2=80=A6 >>>>> The issue is, that current UEFI implementation is using 64MB = staging >>>>> memory for loading the kernel and modules and files. When the boot = is >>>>> called, the relocation code will put the bits from staging area = into the >>>>> final places. The BIOS version does not need such staging area, = and that >>>>> will explain the difference. >>>>>=20 >>>>> I actually have different implementation to address the same = problem, >>>>> but thats for illumos case, and will need some work to make it = usable >>>>> for freebsd; the idea is actually simple - allocate staging area = per >>>>> loaded file and relocate the bits into the place by component, not = as >>>>> continuous large chunk (this would also allow to avoid the mines = like >>>>> planted by hyperv;), but right now there is no very quick real = solution >>>>> other than just build efi loader with larger staging size. >>>> Ic, thanks for the explanation. >>>> While not aware about the purpose of the staging area nor the >>>> consequences of enlarging it, do you think it's feasable increasing = it >>>> to 768Mib? >>>>=20 >>>> At least now I have an idea baout the issue and an explanation why >>>> reducing md_imgae to 100MB hasn't helped =E2=80=93 still more than = 64... >>>>=20 >>>> Any quick hint where to define the staging area size highly = appreciated, >>>> fi there are no hard objections against a 768MB size. >>>>=20 >>>> -harry >>> The problem is that before UEFI Boot Services are not switched off, = the memory is managed (and owned) by the firmware, >> Hmm, I've been expecting something like that (owend by firmware) ;-) >>=20 >> So I'll stay with CSM for now, and will happily be an early adopter = if >> you need someone to try anything (-stable mergable). >=20 > Toomas, thanks for your help so far! I'm just curious if there's news = on > this. > Was there a decision made whether kernel should be utilized to = relocate > the MD image modules or the loader should be extended to handle > (x-)large staging areas? >=20 > I'd like to switch back to UEFI booting for various reasons (most > priority has consistency), but can't since it breaks md-rootfs with = that > machine (the other run ESXi still). >=20 > If there's anything to test, please let me know. >=20 > Thanks, >=20 > -harry There has not been too much activities about this topic, except some = discussions. But it is quite clear that this change has to be handled by = the loader in first place - as we need to get the data in safe location; = now of course there is secondary part as well - it may be that kernel = would need some work as well, depending on how the md image(s) are to be = handled in relation to memory maps. rgds, toomas= From owner-freebsd-stable@freebsd.org Thu Jun 29 10:10:59 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16C8DD98D60; Thu, 29 Jun 2017 10:10:59 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2A0C7E4FB; Thu, 29 Jun 2017 10:10:58 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (localhost [127.0.0.1]) by ainaz.pair.com (Postfix) with ESMTP id A7BCB3F4D9; Thu, 29 Jun 2017 06:10:56 -0400 (EDT) Received: from [192.168.1.102] (unknown [202.188.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id D30993F4D5; Thu, 29 Jun 2017 06:10:37 -0400 (EDT) Date: Thu, 29 Jun 2017 18:10:16 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work To: Mark Millard CC: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni From: Gerald Pfeifer Message-ID: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 10:10:59 -0000 Am 28=2E Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard : >A primary test is building lang/gcc5-devel under release/11=2E0=2E1 >and then using it under stable/11 or some draft of release/11=2E1=2E0 =2E Thank you, Mark=2E Let me know how it went=2E In the meantime I'll prepare= the change for gcc5 itself=2E >It looks like the the lang/gcc5-devel build still creates and >uses the headers that go in include-fixed/ but that they are >removed from $(STAGEDIR}${TARGLIB} 's tree before installation >or packaging=2E > >So, if I understand right, lang/gcc5-devel itself still does use >the adjusted headers to produce its own materials but when >lang/gcc5-devel is used later it does not=2E Definitely >something to be testing since it is a mix overall=2E I am not worried about that since that should not cause any binary incompa= tibilities (ABI)=2E The problem we encountered was about source code and AP= I in a wide sense of that term=2E >Is some form of exp-like run needed that tries to force use >of a release/11=2E0=2E1 built lang/gcc5-devel (-r444563) to build >other things under, say, stable/11 or some draft of >release/11=2E1=2E0 ? Is this odd combination even possible >currently? I am not aware of it, and while originally I was thinking to request an -e= xp run (after the GCC version update which is dragging due to broken ports)= , time is not on our side and the change should be low risk=2E > [altermative approach] But I guess that did not work out=2E Not with my current level of connectivity and my notebook a dead brick on = top of that=2E And my preference is to still build, but stow away (unless e= xplicitly requested to keep)=2E >Eventually most of the lang/gcc* 's will need whatever >technique is used=2E Yes, agreed=2E Version 5 is most important since it's the default; then 6;= 4=2Ex is for retro computing fans ;-), so 7 will then be next=2E Gerald From owner-freebsd-stable@freebsd.org Thu Jun 29 10:56:02 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91B30D99C37 for ; Thu, 29 Jun 2017 10:56:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 3EF297FBE3 for ; Thu, 29 Jun 2017 10:56:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22666 invoked from network); 29 Jun 2017 10:56:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 10:56:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 06:56:00 -0400 (EDT) Received: (qmail 18968 invoked from network); 29 Jun 2017 10:56:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 10:56:00 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A1C33EC7B46; Thu, 29 Jun 2017 03:55:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work From: Mark Millard In-Reply-To: Date: Thu, 29 Jun 2017 03:55:59 -0700 Cc: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 10:56:02 -0000 On 2017-Jun-29, at 3:10 AM, Gerald Pfeifer = wrote: > Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard : >> A primary test is building lang/gcc5-devel under release/11.0.1 >> and then using it under stable/11 or some draft of release/11.1.0 . >=20 > Thank you, Mark. Let me know how it went. In the meantime I'll prepare = the change for gcc5 itself. I'm not currently set up to run more than head on any of amd64, powerpc64, powerpc, aarch64, or armv6/7 (which are all I target). And I'm in the middle of attempting a fairly large jump to head -r320458 on those. (powerpc 32-bit and 64-bit just failed for libc++ time-usage compiling now that 32-bit has 64-bit time_t, including in world32/lib32 contexts for powerpc64.) It will likely be a while before I manage to have a 11.x context (without losing my head contexts), much less examples from all "my" 5 TARGET_ARCH's. (Given past wchar_t type handling problems (e.g.) for gcc targeting powerpc family members I think it should be checked.) I'll have to find and set up disks: I do not even have such handy/ready at the moment. [I got into this area by being asked questions, not by my direct use of release/11.0.1 , stable/11 , or a draft of release/11.1.0 .] I'll let you know when I have some test results but others may get some before I do. > . . . >> Eventually most of the lang/gcc* 's will need whatever >> technique is used. >=20 > Yes, agreed. Version 5 is most important since it's the default; then = 6; 4.x is for retro computing fans ;-), so 7 will then be next. [In my normal/head environment I'm switching to lang/gcc7-devel for gcc (from lang/gcc6 ) but I'm odd that way.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Thu Jun 29 11:37:35 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61E04D9AB67 for ; Thu, 29 Jun 2017 11:37:35 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C731181084 for ; Thu, 29 Jun 2017 11:37:34 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (net206-94.perm.ertelecom.ru [46.146.206.94] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id v5TBbQ7R045690 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 29 Jun 2017 16:37:27 +0500 (YEKT) (envelope-from emz@norma.perm.ru) To: freebsd-stable@freebsd.org From: "Eugene M. Zheganin" Subject: redundant zfs pool, system traps and tonns of corrupted files Message-ID: Date: Thu, 29 Jun 2017 16:37:26 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [1.50 / 25.00] RBL_SPAMHAUS_PBL(2.00)[94.206.146.46.zen.spamhaus.org : 127.0.0.10] HFILTER_HOSTNAME_UNKNOWN(2.50)[] BAYES_HAM(-3.00)[99.99%] DMARC_NA(0.00)[norma.perm.ru] MIME_GOOD(-0.10)[text/plain] R_DKIM_NA(0.00)[] R_SPF_SOFTFAIL(0.00)[~all] RCPT_COUNT_1(0.00)[] MID_RHS_MATCH_FROM(0.00)[] RECEIVED_SPAMHAUS(0.00)[94.206.146.46.zen.spamhaus.org] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_HAS_DN(0.00)[] TO_DN_NONE(0.00)[] FROM_EQ_ENVFROM(0.00)[] RCVD_COUNT_1(0.00)[] ONCE_RECEIVED(0.10)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 2.11 X-Rspamd-Queue-ID: v5TBbQ7R045690 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 11:37:35 -0000 Hi. Say I'm having a server that traps more and more often (different panics: zfs panics, GPFs, fatal traps while in kernel mode etc), and then I realize it has tonns of permanent errors on all of it's pools that scrub is unable to heal. Does this situation mean it's a bad memory case ? Unfortunately I switched the hardware to an identical server prior to encountering zpools have errors, so I'm not use when did they appear. Right now I'm about to run a memtest on an old hardware. So, whadda you say - does it point at the memory as the root problem ? Thanks. Eugene. From owner-freebsd-stable@freebsd.org Thu Jun 29 12:04:24 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F715D9BE51 for ; Thu, 29 Jun 2017 12:04:24 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B2D7F8208F for ; Thu, 29 Jun 2017 12:04:23 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (net206-94.perm.ertelecom.ru [46.146.206.94] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id v5TC4GG0046862 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 29 Jun 2017 17:04:17 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Subject: Re: redundant zfs pool, system traps and tonns of corrupted files To: freebsd-stable@freebsd.org References: From: "Eugene M. Zheganin" Message-ID: <3c4044c5-9016-80ce-1302-2546c76f0dd4@norma.perm.ru> Date: Thu, 29 Jun 2017 17:04:16 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [1.50 / 25.00] BAYES_HAM(-3.00)[100.00%] RBL_SPAMHAUS_PBL(2.00)[94.206.146.46.zen.spamhaus.org : 127.0.0.10] HFILTER_HOSTNAME_UNKNOWN(2.50)[] DMARC_NA(0.00)[norma.perm.ru] MIME_GOOD(-0.10)[text/plain] R_DKIM_NA(0.00)[] R_SPF_SOFTFAIL(0.00)[~all] RCPT_COUNT_1(0.00)[] MID_RHS_MATCH_FROM(0.00)[] RECEIVED_SPAMHAUS(0.00)[94.206.146.46.zen.spamhaus.org] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_HAS_DN(0.00)[] TO_DN_NONE(0.00)[] FROM_EQ_ENVFROM(0.00)[] RCVD_COUNT_1(0.00)[] ONCE_RECEIVED(0.10)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 3.26 X-Rspamd-Queue-ID: v5TC4GG0046862 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 12:04:24 -0000 Hi, On 29.06.2017 16:37, Eugene M. Zheganin wrote: > Hi. > > > Say I'm having a server that traps more and more often (different > panics: zfs panics, GPFs, fatal traps while in kernel mode etc), and > then I realize it has tonns of permanent errors on all of it's pools > that scrub is unable to heal. Does this situation mean it's a bad > memory case ? Unfortunately I switched the hardware to an identical > server prior to encountering zpools have errors, so I'm not use when > did they appear. Right now I'm about to run a memtest on an old hardware. > > > So, whadda you say - does it point at the memory as the root problem ? > I'm also not quite getting the situation when I have errors on a vdev level, but 0 errors on a lower device layer (could someone please explain this): pool: esx state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: resilvered 3,74G in 0h5m with 0 errors on Tue Dec 27 05:14:32 2016 config: NAME STATE READ WRITE CKSUM esx ONLINE 0 0 99,0K raidz1-0 ONLINE 0 0 113K da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 2 da3 ONLINE 0 0 0 da5 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 84,7K da12 ONLINE 0 0 0 da13 ONLINE 0 0 1 da14 ONLINE 0 0 0 da15 ONLINE 0 0 0 da16 ONLINE 0 0 0 errors: 25 data errors, use '-v' for a list pool: gamestop state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub in progress since Thu Jun 29 12:30:21 2017 1,67T scanned out of 4,58T at 1002M/s, 0h50m to go 0 repaired, 36,44% done config: NAME STATE READ WRITE CKSUM gamestop ONLINE 0 0 1 raidz1-0 ONLINE 0 0 2 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da11 ONLINE 0 0 0 errors: 10 data errors, use '-v' for a list P.S. This is a FreeBSD 11.1-BETA2 r320056M (M stands for CTL_MAX_PORTS = 1024), with ECC memory. Thanks. Eugene. From owner-freebsd-stable@freebsd.org Thu Jun 29 13:43:12 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D57DD9DD96 for ; Thu, 29 Jun 2017 13:43:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EEFD284FB5 for ; Thu, 29 Jun 2017 13:43:11 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22d.google.com with SMTP id 63so37104368ywr.0 for ; Thu, 29 Jun 2017 06:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+fVen5vSStjH8h2Kxr6QLOZWR4QSfV9Nn/9aQ9K3pNc=; b=AeH0DdNa8gevJ4BfmRXyQxv9mx/0HuwbJC3HL+2pTxfSnZfK3d5L8lApFGf/PsmW0T S0s3Qh+YuLZVasMVx34WyE8shS8ija2mTAyTzNku8Uc74NqxApWXCvfchcuHwkjEB0zA eZ9NvtZ5TUDKsIwZTLtREbjlhCduyc262vN7IH2MKM2In+gsrjYJrJh+SYlbA4SlIcYp SuGrcxf86RCVkDyfmCzo7LG0bbyvgnVXQBJyEBDSFDkZYhtzQ1fi5qOh27HfSO0wg33P O6/JdtEX24BRzzyk/JK20w/7XXI0dVsVwGbub22aWe55U/E+gPKfGTGkvkGc8/a5JdFE 30WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+fVen5vSStjH8h2Kxr6QLOZWR4QSfV9Nn/9aQ9K3pNc=; b=VhktcWd0UiatgGEToSVqA7pzfymipx9vxNRAzVg2ZsLkkYYd5Mr2fGq9m5IRDSf0wc bDIrq+lQht1Cg/Ley8QV9TkAQW+i2rbw9Pp8Loe+PFLpf1bZDyYRWwQT12tpS0SpGTcg s72qmXXBRxRbsyMhpZTGvd1FG58yvMF1gIX8PbJbTnG2vTRBOLlnplOczWetvBy8UUO9 KPVebW3RMzQOKSfBlikDiUbECXuYK/6t7dqGYSelzNOrETyjBMI69eLCoOLN5Ex/8wE6 TLikehfWyMjP8Vz41lBEJWZk/evI5I/mvAWucwTkV+SNNKoo7xcmhMpRj50eNfENOfCt sP8A== X-Gm-Message-State: AKS2vOwNSN7HmDW44fbucRSa9caByhyU3IurhHDFN/UIzQ6r41Rs7rTX XiMN2orGN0rDaf8GOmfGfbONyl5qew== X-Received: by 10.13.235.202 with SMTP id u193mr11873912ywe.222.1498743791037; Thu, 29 Jun 2017 06:43:11 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Thu, 29 Jun 2017 06:43:10 -0700 (PDT) In-Reply-To: <3c4044c5-9016-80ce-1302-2546c76f0dd4@norma.perm.ru> References: <3c4044c5-9016-80ce-1302-2546c76f0dd4@norma.perm.ru> From: Alan Somers Date: Thu, 29 Jun 2017 07:43:10 -0600 X-Google-Sender-Auth: 1FLpjBFdaEvg9Cw2Nuoul8NeriI Message-ID: Subject: Re: redundant zfs pool, system traps and tonns of corrupted files To: "Eugene M. Zheganin" Cc: FreeBSD Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 13:43:12 -0000 On Thu, Jun 29, 2017 at 6:04 AM, Eugene M. Zheganin wrote: > Hi, > > On 29.06.2017 16:37, Eugene M. Zheganin wrote: >> >> Hi. >> >> >> Say I'm having a server that traps more and more often (different panics: >> zfs panics, GPFs, fatal traps while in kernel mode etc), and then I realize >> it has tonns of permanent errors on all of it's pools that scrub is unable >> to heal. Does this situation mean it's a bad memory case ? Unfortunately I >> switched the hardware to an identical server prior to encountering zpools >> have errors, so I'm not use when did they appear. Right now I'm about to run >> a memtest on an old hardware. >> >> >> So, whadda you say - does it point at the memory as the root problem ? Certainly a good guess. >> > > I'm also not quite getting the situation when I have errors on a vdev level, > but 0 errors on a lower device layer (could someone please explain this): ZFS checksums whole records at a time. On RAIDZ, each record is spread over multiple disks, usually the entire RAID stripe. So when ZFS detects a checksum error on a record stored in RAIDZ, it doesn't know which individual disk was actually responsible. Instead, it blames the RAIDZ vdev. That's why you have thousands of checksum errors on your raidz vdevs. The few checksum errors you have on individual disks might have come from the labels or uberblocks, which are not raided. -Alan From owner-freebsd-stable@freebsd.org Thu Jun 29 14:00:12 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8647D9E0ED for ; Thu, 29 Jun 2017 14:00:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF4A2866 for ; Thu, 29 Jun 2017 14:00:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5TE0CVW027398 for ; Thu, 29 Jun 2017 14:00:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Thu, 29 Jun 2017 14:00:12 +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: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mjg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 29 Jun 2017 14:00:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 --- Comment #35 from Mateusz Guzik --- Hi there, sorry for late reply. This somehow fell through the cracks. First of all there is no kernel bug per se that I can see, rather a bug in = the atom cpu which started manifesting itself. There were several changes to the affected code path on stable/11 and in particular the condition which trigg= ered the bug is gone. I don't have any reports, but I suspect stable/11 is now cleared. stable/10 will require a hack, but I'll need someone to test it as don't have the hardware to reproduce. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Thu Jun 29 14:02:22 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B52ADD9E36A for ; Thu, 29 Jun 2017 14:02:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1B60DDE for ; Thu, 29 Jun 2017 14:02:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5TE2MMR054367 for ; Thu, 29 Jun 2017 14:02:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Thu, 29 Jun 2017 14:02: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: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: franco@opnsense.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 29 Jun 2017 14:02:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 --- Comment #36 from Franco Fichtner --- You can use https://github.com/opnsense/src/commit/6b79b52c.patch on stable= /10, it was verified working on 11.0. Cheers, Franco --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Thu Jun 29 14:07:02 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A54A4D9E505 for ; Thu, 29 Jun 2017 14:07:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 932F31032 for ; Thu, 29 Jun 2017 14:07:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5TE71re064229 for ; Thu, 29 Jun 2017 14:07:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Thu, 29 Jun 2017 14:07:01 +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: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 29 Jun 2017 14:07:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 --- Comment #37 from Cassiano Peixoto --- (In reply to Mateusz Guzik from comment #35) Mateusz, Yes i realized many changes has been made on 11-STABLE related to this issu= e. I think it could be fixed as well. Anyway i have a server running with 11.1-B= ETA3 to confirm. Regarding FreeBSD 10, i can test it for you, just provide a patch and let me know. Thanks. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Thu Jun 29 14:11:05 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 295C5D9E675 for ; Thu, 29 Jun 2017 14:11:05 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 162BD12ED for ; Thu, 29 Jun 2017 14:11:05 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id 123ACD9E673; Thu, 29 Jun 2017 14:11:05 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11CA8D9E670 for ; Thu, 29 Jun 2017 14:11:05 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::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 D53C112EC for ; Thu, 29 Jun 2017 14:11:04 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.ingresso.co.uk ([2a02:b90:3002:411::6]) by constantine.ingresso.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dQa9u-000CSp-3o for stable@freebsd.org; Thu, 29 Jun 2017 14:11:02 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dQa9t-00053N-WC for stable@freebsd.org; Thu, 29 Jun 2017 15:11:02 +0100 To: stable@freebsd.org Subject: Problems attaching disks in Azure under 11.1-BETA2 Message-Id: From: Pete French Date: Thu, 29 Jun 2017 15:11:01 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 14:11:05 -0000 I am trying to attach a brand new disk to an azure VM, and what I see is the disk attachng and detaching immediately like this: da2 at storvsc3 bus 0 scbus5 target 0 lun 0 da2: Fixed Direct Access SPC-2 SCSI device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 32768MB (67108864 512 byte sectors) da2 at storvsc3 bus 0 scbus5 target 0 lun 0 da2: detached g_access(918): provider da2 has error g_access(918): provider da2 has error g_access(918): provider da2 has error g_access(918): provider da2 has error (da2:storvsc3:0:0:0): Periph destroyed I have seen this before with an existing disk if I detahc and reattach wiht a new LUN numer, but never with a brand new disk. The command I am using to create this is below: az vm disk attach --vm-name az-london01 \ --resource-group ticketswitch-london \ --caching ReadWrite --new --size-gb 32 \ --sku Standard_LRS \ --disk az-london01-tank01 The only thing I could find in bug reports which is similar is this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914 But those patches should have gone in ages ago. Will try and find a workaround for now, but its a bit puzzling. -pete. From owner-freebsd-stable@freebsd.org Thu Jun 29 14:56:37 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 013DBD9F3F8 for ; Thu, 29 Jun 2017 14:56:37 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 8AFB92F13 for ; Thu, 29 Jun 2017 14:56:35 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id v5TESf7v022934 for ; Thu, 29 Jun 2017 16:28:41 +0200 (CEST) Received: from [217.29.44.115] ([217.29.44.115]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id v5TESfDI085982 for ; Thu, 29 Jun 2017 16:28:41 +0200 (CEST) (envelope-from hausen@punkt.de) From: "Patrick M. Hausen" Content-Type: multipart/signed; boundary="Apple-Mail=_313749CD-4F92-4405-9E7A-C1755359E1A6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: What is /dev/zfs? Message-Id: <2BF904CF-7EC1-41BC-A9F3-BFF7813A897D@punkt.de> Date: Thu, 29 Jun 2017 16:28:40 +0200 To: freebsd-stable X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 14:56:37 -0000 --Apple-Mail=_313749CD-4F92-4405-9E7A-C1755359E1A6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, folks any pointer to an explanation would be nice, there seems to be no zfs(4) manpage ... Reason for asking: I have a piece of software that uses 14,000 ioctl() calls on that device during one execution and I'm asking myself what it tries to do. Thanks! Patrick --Apple-Mail=_313749CD-4F92-4405-9E7A-C1755359E1A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZVQ6ZAAoJEJBvLuLt2olcUwMH/A7PKicN6jkT1vxlF/U5i723 2B9e63BAqrHpdBkC5pFKWqfeaAIsR/o+t+RLHWv0DsJPUMXqRYuoME+HSowR3oS+ I8LGpF3V828wx8ttkZCeraucKEppTWiJdALgpUTwjaDjjcBlvVhuqmCeHvOr3oOv 8w8EXmYTjW1wfqjV/L1Uk15LZrINPmM5vugd4XSW/GtTORvAGeH2KZhvU1k7vuc6 YuR98n7al/P3cu/xJbsPsLd1gD+eWKpf7mJU3DgOV+JHi5cUJNjlec9bZzkyJYHd k2nqDHtCJm3/1wUegRqbOoNfN8X4r/VlQkex2Przb6uA7+jccolOVD61FG4fyKg= =dwN2 -----END PGP SIGNATURE----- --Apple-Mail=_313749CD-4F92-4405-9E7A-C1755359E1A6-- From owner-freebsd-stable@freebsd.org Thu Jun 29 16:02:30 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BE2BDA03E5 for ; Thu, 29 Jun 2017 16:02:30 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A72C64E55 for ; Thu, 29 Jun 2017 16:02:30 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22f.google.com with SMTP id j11so38817168ywa.2 for ; Thu, 29 Jun 2017 09:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Clbu128eW21Ugaxs6BNpgjEokzskZu+bbSFSRQYRzKw=; b=BvydPcENKEc0Gx1qu2TTExiQKQXYdxfKxASHyeKt+XtmcBfo/+Ifwmy+Ohz6lDEJtG YV5PTNKoVH65lX8LCFXSQq9Wx+ITOAwCuVuMCtQqSSUNSt98YJ0+OwMudReByb4/NYw9 Cm6qi2FFh7kFw19UP/auKce1cb33ROggMEoVeCA9Up+ebKHIqHPw1oCuLk73jVQBbKNu n9R60etXC/SA9TRrnU5OpVpqB+tjRzerPNR3g3mTiWSqDdOgmnqtFMR7WPBIOsfB6SZz P/0JtdZmKhkPXB8gRtxn/M2kxottdcnivyTN3/n9EFLNmEbtHkNKr9MncbBGJXY0aMgr Kjfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Clbu128eW21Ugaxs6BNpgjEokzskZu+bbSFSRQYRzKw=; b=e2Iv2fjm89MUzvYZ3MVhta4Oa9lTunKa0i93L/Mh+zsAY3/4u0fjFSkLuHxvJgg9Dk VhSwqOqKKTLYxc9gF0bH3q+GrHkDk2F8PhNZeuNeiB7Ywq9cI4EcAsePvSzilyo3Ydwb 6NjKK3h+VCK/mBzB8gqRINyYbhqhLqbWTESOMakrDtShT5JCxxliF7wtGrhLjBbo6hIE VhQnuFh5ese8WAhNsoPM6bzL5b/7W8H/CUCSmeMW2GLs5sYhiWDKGKygyGv1k5SkLTc4 Pi0v5KK1NanFDutuBrfikIqTjwz9rVigA2iotBeam/87gif+ZVhQzXJi2QFIjePM8ivJ 9J/w== X-Gm-Message-State: AKS2vOwCAFCD2/ar48dnHKttReL0OxmXVhDCevQNo6HvkYLNlQgLRH1U ZIF/q4grDr6j3w1siq51v6YDZZNaGQ== X-Received: by 10.13.235.202 with SMTP id u193mr12425337ywe.222.1498752149499; Thu, 29 Jun 2017 09:02:29 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Thu, 29 Jun 2017 09:02:28 -0700 (PDT) In-Reply-To: <2BF904CF-7EC1-41BC-A9F3-BFF7813A897D@punkt.de> References: <2BF904CF-7EC1-41BC-A9F3-BFF7813A897D@punkt.de> From: Alan Somers Date: Thu, 29 Jun 2017 10:02:28 -0600 X-Google-Sender-Auth: qnaL5shRptNkD0pvTKnnp3DeYWU Message-ID: Subject: Re: What is /dev/zfs? To: "Patrick M. Hausen" Cc: freebsd-stable Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 16:02:30 -0000 On Thu, Jun 29, 2017 at 8:28 AM, Patrick M. Hausen wrote: > Hi, folks > > any pointer to an explanation would be nice, > there seems to be no zfs(4) manpage ... > > Reason for asking: I have a piece of software > that uses 14,000 ioctl() calls on that device during > one execution and I'm asking myself what it tries > to do. > > Thanks! > Patrick The zpool and zfs commands do everything through ioctls, and /dev/zfs is the device node those ioctls are bound to. You can't read from it or write to it; all you can with /dev/zfs is use ZFS's custom ioctls. -Alan From owner-freebsd-stable@freebsd.org Thu Jun 29 16:38:20 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0FF0DA0A1C for ; Thu, 29 Jun 2017 16:38:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1F5A65B1E for ; Thu, 29 Jun 2017 16:38:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5TGcK9V092612 for ; Thu, 29 Jun 2017 16:38:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Thu, 29 Jun 2017 16:38:20 +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: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: chrysalis@chrysalisnet.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 29 Jun 2017 16:38:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 --- Comment #38 from Chris Collins --- (In reply to Mateusz Guzik from comment #35) Just to let you know my pfsense unit affected by this issue does not have an atom cpu. It has a celeron N3150 cpu. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Thu Jun 29 22:23:28 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72716DA6BCC for ; Thu, 29 Jun 2017 22:23:28 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 391FE75E9C for ; Thu, 29 Jun 2017 22:23:27 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qk0-x232.google.com with SMTP id v143so4062326qkb.0 for ; Thu, 29 Jun 2017 15:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=NsrirsQP6HtIFH55osPoUSgE2kztyGM/8VL5v5CZpEw=; b=mtldMBCSSr3mW1CLvgcZ59wzJ9YqQrZosORotHrAwkm6hfaHOdXDtYiju0HY9txPD5 oDp2bcqR1IAenBZUZ1gQ5o578SKzi02AacbLJanitZSjRe+S58r27z1AiNgHrsa2hACd 00g57Opg14d//ZFz81HXhpvLw9ZcOd1xr0gDN8koF9Q9G2H+Ir6g0PXr345LgM5OO1Xi TZunhjGhLU25SXtc6fHonnBWTnbnr2R59ajFzQz/Tz5U5U3vw08Dlm+MBbWaIc+U/WWz e5muU/lKGyZWsILv3Cn36HotqsQOVLvZ8s9dudYtmCzasERznbxWBN872e8vjP5SPbvg Gwpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NsrirsQP6HtIFH55osPoUSgE2kztyGM/8VL5v5CZpEw=; b=njcWTYnVSxOIsA7KtzsTJ3/N929R0t8rHWvCS31zCZCcLsCmIzW+s89l6DOEYNN+W3 aqewzB/yCLxXLJr7nBCxFl7sbdSwa6dVPDaeQiKP3pKPiJ0sglAU43lleiiUFyttixWv 6D4cddwwv8h98BbHtlbYVm6uWwJnAByaFWr7Bj6dpBb4mM409/laBMVkD4ktuyNzhSIs bQ4bdwzrdTn6qpOUdwTX9YRabrHIAAXRK+FdGa/K4UIRUM8iyQQ9QQPwqk3alHnNN+G8 hfCFvRedUeNTtIYakOPrheiGOiCiuwtzkPRyNOQGZETZkbxEN/cOdggXKHgQ3a6xOLmc N87A== X-Gm-Message-State: AKS2vOyH0hCg4+WUpplibpXWKEU/ks44pGW3HZvGtvw38f25yCGWN83V AP87ezO2nyOZ6EPEuxroi7X92cdJahLj X-Received: by 10.55.158.137 with SMTP id h131mr22379622qke.246.1498775006666; Thu, 29 Jun 2017 15:23:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.23 with HTTP; Thu, 29 Jun 2017 15:23:26 -0700 (PDT) X-Originating-IP: [203.99.129.1] From: Jonathan Chen Date: Fri, 30 Jun 2017 10:23:26 +1200 Message-ID: Subject: 11.1-BETA3 uhub probes on warm boot triggers endless reboot cycle To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 22:23:28 -0000 Hi, I've got a dual boot system at home, booting into Windows 10 for games. I've noticed that since I updated to 11.1-BETA3, a reboot from Windows into FreeBSD results in a endless reboot cycle. In order to reboot FreeBSD, I have to cold-boot. The endless reboot cycle appears to be triggered when the kernel attempts to talk to "uhub", at which point it reboots, and the cycle repeats. No kernel panics, no crash cores. The issue is not a biggie, other than the time it takes for me to power down completely, wait for capacitors to discharge completely, and then cold boot the machine. However, I thought I'd bring it to the notice of list. Cheers. -- Jonathan Chen From owner-freebsd-stable@freebsd.org Thu Jun 29 22:28:02 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0363DA6D84 for ; Thu, 29 Jun 2017 22:28:02 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AB47760CA; Thu, 29 Jun 2017 22:28:02 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id A689C1385D; Thu, 29 Jun 2017 22:28:01 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 29 Jun 2017 22:27:59 +0000 From: Glen Barber To: Jonathan Chen Cc: freebsd-stable@freebsd.org Subject: Re: 11.1-BETA3 uhub probes on warm boot triggers endless reboot cycle Message-ID: <20170629222759.GA23311@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-STABLE amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer X-Spidey-Sense: Uh oh, Peter logged in User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 22:28:02 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2017 at 10:23:26AM +1200, Jonathan Chen wrote: > Hi, >=20 > I've got a dual boot system at home, booting into Windows 10 for > games. I've noticed that since I updated to 11.1-BETA3, a reboot from > Windows into FreeBSD results in a endless reboot cycle. In order to > reboot FreeBSD, I have to cold-boot. The endless reboot cycle appears > to be triggered when the kernel attempts to talk to "uhub", at which > point it reboots, and the cycle repeats. No kernel panics, no crash > cores. >=20 > The issue is not a biggie, other than the time it takes for me to > power down completely, wait for capacitors to discharge completely, > and then cold boot the machine. However, I thought I'd bring it to the > notice of list. >=20 Thank you for the report. Could you please open a PR about this? Glen --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAllVfu8ACgkQAxRYpUeP 4pO6AQ/+MTZijOy4QkAg0g4rbTnj9U8yUS6srdimXIwFH0UxF5WW8QYMDsbtwymG yMUEbyqgBE3JaZk6Bf6YoW2OJen1pY8I1cstF7TqWbCcM2aIheizqZ69T1z8Vcw4 LLffQ87PFIDB3A6pgPlHS0VTvSqTVgWPnXViWMC0BsRTT54W1Gwcv3qun0yIC0eM D+REAjjyaofL7h/PL12snL1PXFLsmAL4lVF3fjjAPUTn8T3SEK+uS0tgLO4zL4zb /cAOXqj+Q9MhcWWEEtYd5ks8ZaP+lj+NdMQ6RdV5bpx4UxYD9CG5qNmrEZdaV5Zl 1VVkRMhHYWl0HwA//HP4Lv9rPFBQoglrh4doArR9lCs2rnezTHeIG+SWmyrbHlHR l/JRi3qNp0TuFNGMyXsGUld1wOqt3lu4d7pYIKZXA5kFzhu3kciwvH77uwxnAHgI 8s2qDjfvZu6+xCQbiqLOieE++pOg91gCv4FFxklm1dN0jvDPgiJDWPonNKwh1P73 mzIfrd8mfZE+n8grHN0gaoRrHDWOEb4Sumr7UC3hauQj0D9d43CQ2tTphBgHc0bD BP7NV5TK2H6y9fLUv+4IpZJugmf7BzGjLZCpD17eAHolnKkEvLg6LawGqXmluJco Cm8sTHYZAb+By/2GKhoaAiiSRAIwMGXXLgOiEgY6LDug+y3ztP4= =qsmR -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-stable@freebsd.org Thu Jun 29 22:32:24 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1506DA7059 for ; Thu, 29 Jun 2017 22:32:24 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BE17764D5 for ; Thu, 29 Jun 2017 22:32:24 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qt0-x229.google.com with SMTP id i2so86289392qta.3 for ; Thu, 29 Jun 2017 15:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EHaxiRX7YGEUqWYVuc/pT6rSK6dS2YSvExjCIUdGkCk=; b=zMbrCgU2IigLYTlhqMlDBH1jOKUXM/mjLaJcJquH9+8y+vYa9FccdechrOPzfbm71Y nWU0ebgjRs0/+8dK3mOnMBOXUKogaoKDarD0mKy5o6W8uBtKnz4r7xf4p52aXl751o9H SLWwK43WAfBWlU6ol+t4U+O3SQjJfg8N47YFzKfBi5MXQuOIJ69sPh6hFxY9/cDiPs/Z qIgXtO6CsI2+LQQ4Ay+7GqPbwGytqQL8QeQU0aSizbXIfAswJCBeDAI7Mam809SxmuE6 Xew+U6vhtkIXztlCALTTLAK63VUZlo1yNxVL6gZ+LB2HtM2a0q+LeSaKFNXFfkanKQrO XFuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EHaxiRX7YGEUqWYVuc/pT6rSK6dS2YSvExjCIUdGkCk=; b=OJ9bGP77B2RgXXG4ARiE3S4UtZk3D5WnFVrxdegnRmvBwyPbuBkngHg5tuYjYE9MSt N/Bx8/iFkYGeuIWDhlDiXaOj/Ln79xOG32ohhKCwEpaNyuEeKiODSJp060ZZbvStz1aa rCPLjhicjorFwM355UWAFYBNAGZXm1ydOuxUsQcs1XcT+nkit3XosqRYGvOOySTmxArV qGbjRX7uSuUpq+cgeJvUUjJGiMXFv+qUyL1XgpXWnWvJSvKbQ9PQ3P+RQ1GWuzpKiYwV xJRzSBVlkwEKKYZnGC1fbINOzyaQyKdn92q5nI1KL6Tg97fpUUAUjlID5x3wDKDn2Obb s/uw== X-Gm-Message-State: AKS2vOxGgN5cDa8Hp+gnemZJKwYoSnlEz81meE736+mjiiJGhk8uqkXg pFE1jx/N3Yt2MH3UKOFWFYgaZwCgrbwAJaE= X-Received: by 10.237.58.102 with SMTP id n93mr22225054qte.76.1498775543536; Thu, 29 Jun 2017 15:32:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.23 with HTTP; Thu, 29 Jun 2017 15:32:23 -0700 (PDT) X-Originating-IP: [203.99.129.1] In-Reply-To: <20170629222759.GA23311@FreeBSD.org> References: <20170629222759.GA23311@FreeBSD.org> From: Jonathan Chen Date: Fri, 30 Jun 2017 10:32:23 +1200 Message-ID: Subject: Re: 11.1-BETA3 uhub probes on warm boot triggers endless reboot cycle To: Glen Barber Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 22:32:24 -0000 On 30 June 2017 at 10:27, Glen Barber wrote: > On Fri, Jun 30, 2017 at 10:23:26AM +1200, Jonathan Chen wrote: >> Hi, >> >> I've got a dual boot system at home, booting into Windows 10 for >> games. I've noticed that since I updated to 11.1-BETA3, a reboot from >> Windows into FreeBSD results in a endless reboot cycle. In order to >> reboot FreeBSD, I have to cold-boot. The endless reboot cycle appears >> to be triggered when the kernel attempts to talk to "uhub", at which >> point it reboots, and the cycle repeats. No kernel panics, no crash >> cores. >> >> The issue is not a biggie, other than the time it takes for me to >> power down completely, wait for capacitors to discharge completely, >> and then cold boot the machine. However, I thought I'd bring it to the >> notice of list. >> > > Thank you for the report. Could you please open a PR about this? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220370 Cheers. -- Jonathan Chen From owner-freebsd-stable@freebsd.org Thu Jun 29 23:16:27 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 348C1DA7AD1 for ; Thu, 29 Jun 2017 23:16:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C7AE7770E; Thu, 29 Jun 2017 23:16:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 1D14C13FAB; Thu, 29 Jun 2017 23:16:26 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 29 Jun 2017 23:16:24 +0000 From: Glen Barber To: Jonathan Chen Cc: freebsd-stable@freebsd.org Subject: Re: 11.1-BETA3 uhub probes on warm boot triggers endless reboot cycle Message-ID: <20170629231624.GB23311@FreeBSD.org> References: <20170629222759.GA23311@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-STABLE amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer X-Spidey-Sense: Uh oh, Peter logged in User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 23:16:27 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2017 at 10:32:23AM +1200, Jonathan Chen wrote: > On 30 June 2017 at 10:27, Glen Barber wrote: > > On Fri, Jun 30, 2017 at 10:23:26AM +1200, Jonathan Chen wrote: > >> Hi, > >> > >> I've got a dual boot system at home, booting into Windows 10 for > >> games. I've noticed that since I updated to 11.1-BETA3, a reboot from > >> Windows into FreeBSD results in a endless reboot cycle. In order to > >> reboot FreeBSD, I have to cold-boot. The endless reboot cycle appears > >> to be triggered when the kernel attempts to talk to "uhub", at which > >> point it reboots, and the cycle repeats. No kernel panics, no crash > >> cores. > >> > >> The issue is not a biggie, other than the time it takes for me to > >> power down completely, wait for capacitors to discharge completely, > >> and then cold boot the machine. However, I thought I'd bring it to the > >> notice of list. > >> > > > > Thank you for the report. Could you please open a PR about this? >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220370 >=20 Thank you. Glen --XF85m9dhOBO43t/C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAllVikgACgkQAxRYpUeP 4pNDfhAAi34KAv4DihMkbjYZsN+GPnl+Ni8EeAh3tEFab0EDDbhAO4URstQU1qg/ LbwD0+bd/Wi2mlIUdoMf5xjubgsLKwcvurr3PPDVcRLuY/6z5x3Cp5GkycARLyMn G7HyM7W8HxObZXPn0icCxigo2nB9JzjVF2BZyBZ0h5GnRYfOd2HBvaXFA+ZzbDds xIFuJIUg/mHhOTCRHKNrbXdcS6lw27C562bYvA36yvV1djb8IDnhcux+7DhgyOu7 xwk1OzDc7CbmE5ReH9TgX1HYo1ULSOJr5KV5NOs19DfZMHY6WP0KFdzQesVyeH1k 46RM/2M6huKlv56HLipkbZa5tImavzQZ0/IUT1W9azx1Ga0ovnJ4C+WdBvQ28sSN pisXFuKkS6a9PhDdURQdDlRMubBjhnUczFihmWuxlHMHOEoMP8g44gdWOy9cs8EE /rjNaE4eQcUHXbN84+nTZuM+09l//vo6LiHPwmwh9ODOPtceBUIfqqjamwLtv1mj ApbWt+Bjr5+cb2opEH7UZUGMrlcCun5bKXQepoHXEcDrEoIZIqTCAaHNkeDMFuUs bfG6NnphJyHMHtFcoR3fd598aa3URSo0mNJOrNmH2yPxi+hmec7ikAuWO4G5L+2G 6hAOm5BENKWlaGlzUPihgF2dBZoQgVEd+rJczdlw3JUDjZBTKuk= =Qo9R -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-stable@freebsd.org Fri Jun 30 00:59:05 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4C35DA947C; Fri, 30 Jun 2017 00:59:05 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 827407A131; Fri, 30 Jun 2017 00:59:05 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (localhost [127.0.0.1]) by ainaz.pair.com (Postfix) with ESMTP id 47A943F4D9; Thu, 29 Jun 2017 20:58:58 -0400 (EDT) Received: from [192.168.1.108] (unknown [202.188.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 65C463F4D5; Thu, 29 Jun 2017 20:58:41 -0400 (EDT) Date: Fri, 30 Jun 2017 08:58:21 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work To: Mark Millard CC: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni From: Gerald Pfeifer Message-ID: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Jun 2017 00:59:05 -0000 Am 29=2E Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard : >I'm not currently set up to run more than head on >any of amd64, powerpc64, powerpc, aarch64, or armv6/7 >(which are all I target)=2E And I'm in the middle of >attempting a fairly large jump to head -r320458 on >those=2E Oh, then I had misunderstood your previous mail=2E No worries, I'll gently= proceed then=2E I expect to update gcc5 in the next 24 hours=2E >[In my normal/head environment I'm switching to lang/gcc7-devel >for gcc (from lang/gcc6 ) but I'm odd that way=2E] The compiler should be fine, it's a number of ports that are not (even blo= cking the move from GCC 5 to 6 as default)=2E Gerald From owner-freebsd-stable@freebsd.org Sat Jul 1 02:09:20 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 271C5DA25C3 for ; Sat, 1 Jul 2017 02:09:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 088972AEA for ; Sat, 1 Jul 2017 02:09:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6129Jet048665 for ; Sat, 1 Jul 2017 02:09:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Sat, 01 Jul 2017 02:09: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: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mjg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 01 Jul 2017 02:09:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 --- Comment #39 from Mateusz Guzik --- Can someone who runs into the problem on stable/10 test the following pleas= e: https://people.freebsd.org/~mjg/patches/rwlock-unlock.diff --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sat Jul 1 14:20:19 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D4CDD8AE59 for ; Sat, 1 Jul 2017 14:20:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4062F39 for ; Sat, 1 Jul 2017 14:20:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v61EKHPr070306 for ; Sat, 1 Jul 2017 14:20:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Sat, 01 Jul 2017 14:20:18 +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: CURRENT X-Bugzilla-Keywords: crash, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 01 Jul 2017 14:20:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sat Jul 1 14:44:47 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EDF8D8BCAF for ; Sat, 1 Jul 2017 14:44:47 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AFA56437E; Sat, 1 Jul 2017 14:44:47 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 42F6F11E3F; Sat, 1 Jul 2017 14:44:46 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 1 Jul 2017 14:44:44 +0000 From: Glen Barber To: freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 11.1-RC1 Now Available Message-ID: <20170701144444.GI23311@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-STABLE amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer X-Spidey-Sense: Uh oh, Peter logged in User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Jul 2017 14:44:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The first RC build of the 11.1-RELEASE release cycle is now available. Installation images are available for: o 11.1-RC1 amd64 GENERIC o 11.1-RC1 i386 GENERIC o 11.1-RC1 powerpc GENERIC o 11.1-RC1 powerpc64 GENERIC64 o 11.1-RC1 sparc64 GENERIC o 11.1-RC1 armv6 BANANAPI o 11.1-RC1 armv6 BEAGLEBONE o 11.1-RC1 armv6 CUBIEBOARD o 11.1-RC1 armv6 CUBIEBOARD2 o 11.1-RC1 armv6 CUBOX-HUMMINGBOARD o 11.1-RC1 armv6 GUMSTIX o 11.1-RC1 armv6 RPI-B o 11.1-RC1 armv6 RPI2 o 11.1-RC1 armv6 PANDABOARD o 11.1-RC1 armv6 WANDBOARD o 11.1-RC1 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.1/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/11.1" branch. A summary of changes since BETA3 includes: o Several build toolchain related fixes. o A use-after-free in RPC client code has been corrected. o The ntpd(8) leap-seconds file has been updated. o Various VM subsystem fixes. o The '_' character is now allowed in newfs(8) labels. o A potential sleep while holding a mutex has been corrected in the sa(4) driver. o A memory leak in an ioctl handler has been fixed in the ses(4) driver. A list of changes since 11.0-RELEASE are available in the releng/11.1 release notes: https://www.freebsd.org/releases/11.1R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 11.1-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/11.1-RC1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: ap-south-1 region: ami-8aa8d6e5 eu-west-2 region: ami-3e20365a eu-west-1 region: ami-b950b4c0 ap-northeast-2 region: ami-50449b3e ap-northeast-1 region: ami-d2e9fab5 sa-east-1 region: ami-519af03d ca-central-1 region: ami-e18e3185 ap-southeast-1 region: ami-4fd65e2c ap-southeast-2 region: ami-d78192b4 eu-central-1 region: ami-6f71d000 us-east-1 region: ami-53625e45 us-east-2 region: ami-c53716a0 us-west-1 region: ami-788fa318 us-west-2 region: ami-121b0a6b === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 11.1-RC1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 10.x. Alternatively, the user can install misc/compat10x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 11.1-RC1 amd64 GENERIC: SHA512 (FreeBSD-11.1-RC1-amd64-bootonly.iso) = 0e211b02d7452f0cda82430009f1ca7009a824bebbd1a36ee2205f746414d84cab645b408e49f312e2b9cabfbc02ac59a9816af6ce8ea97d2841dad6400d7733 SHA512 (FreeBSD-11.1-RC1-amd64-bootonly.iso.xz) = bd04d65272817aa8b9edaca67dd681f8f068518a8583375ec137d1c1f1c23905274cec57a3d9da1b39fc922189ac01e5d762d25ecbf54d409d622819a9bd80b7 SHA512 (FreeBSD-11.1-RC1-amd64-disc1.iso) = 90114172b5278c8a5f9c772ee166e19b8240cde49caac5621f49d44f20dd635175746c4d038aff7c42220f9d35d75c36c50ecd78387345ddb901a34a55384b8c SHA512 (FreeBSD-11.1-RC1-amd64-disc1.iso.xz) = 7b625e8a431637eb5939c32f02dbf9cd859c6b542583b0762f74a2b4430f25e0a022c4d841a2405e6009524d181b2a7e8d270ac1cc10c6e28321ab152009b56d SHA512 (FreeBSD-11.1-RC1-amd64-dvd1.iso) = fa8ffc51d4bbca4c799d430a8fbe6b1284f32ccd3cb283145e62cfa0cae5f15a97861d7d17759d0acb3ce35740f24176a5098942d8dd992006ee58ca43e45c06 SHA512 (FreeBSD-11.1-RC1-amd64-dvd1.iso.xz) = 4f57f52fca1647716a0ad88e6c32d1e5511b7a01181010746181b062295434c5888c49bc0067c98f53cd7611e5a0383a6317067908361c06c63b78c950928361 SHA512 (FreeBSD-11.1-RC1-amd64-memstick.img) = 26f0e16679750a61ec00e0698c0084264227fabd0e84a93fa6910779e83149b492002274a4cd9b73de229f6a87e0b19de616b587d26b53cb894083c4caa2a623 SHA512 (FreeBSD-11.1-RC1-amd64-memstick.img.xz) = e36421b88e7c8e7415d219864fe056b1216aeeb1d5ed7b3fd9ff8236cbe90ee8444c41fb062e4755072c358f3113e161039e91aeab706af3bcc14fddfd65d8a6 SHA512 (FreeBSD-11.1-RC1-amd64-mini-memstick.img) = 9a321d404b008804f083ffd7b84934bbb54e5888aea0ecf5f97ef3c8014a269438f631e7bacb7c5fb510f47dd69378b83db8bebd8fc9c7470bac4535bf0bc1fe SHA512 (FreeBSD-11.1-RC1-amd64-mini-memstick.img.xz) = a00d475430f733e9a0ba98fc7ee0ccd5d11eaf6d40cd32e3a513f7bc84a4e7e6a2b042e491f280a1c3dbf13b47f5cb80c71a2456dedae5ae25107bcbcdea71ea SHA256 (FreeBSD-11.1-RC1-amd64-bootonly.iso) = da74f34bcd4ec3a23c7cd38a858880cbd86668fac71f6e20ea11758b8aa017ce SHA256 (FreeBSD-11.1-RC1-amd64-bootonly.iso.xz) = c1fd7ed9c17d0d30c8ee93958b2d7ac271817838815fee2921f3c04fa855e21b SHA256 (FreeBSD-11.1-RC1-amd64-disc1.iso) = ba049786abd34b664fd2aca62f5984333e852cad17d212da5084a55e2d4d98f1 SHA256 (FreeBSD-11.1-RC1-amd64-disc1.iso.xz) = 45a3369882582b05068956b62c7c4f22f677e68c61076e627ca6bf5ac2f80c18 SHA256 (FreeBSD-11.1-RC1-amd64-dvd1.iso) = 5b13f2c4ff1d03246c82390287ff8345014c970550302341d938fb6f8e416133 SHA256 (FreeBSD-11.1-RC1-amd64-dvd1.iso.xz) = d7f1d71c7a4434080392d1178bbd2f76069594dd2997b6958292a7ba70c7a763 SHA256 (FreeBSD-11.1-RC1-amd64-memstick.img) = 87e1665122499e7343d52349daf016fa14f8af78230ce53aeb1db7fb14c655e3 SHA256 (FreeBSD-11.1-RC1-amd64-memstick.img.xz) = ee5141757010b0044c514c1c7d212fccce2b412eeb11a27eeef4f6670e2cf5eb SHA256 (FreeBSD-11.1-RC1-amd64-mini-memstick.img) = 4c5c16be4d2d6b5355b6b9db265eef4b19d03e40df8efd32d9a250648defb780 SHA256 (FreeBSD-11.1-RC1-amd64-mini-memstick.img.xz) = 1dcd60119e974709d0b1478a05858b27ad3359bae98770eaf0e3cdb0ea79d9e2 o 11.1-RC1 i386 GENERIC: SHA512 (FreeBSD-11.1-RC1-i386-bootonly.iso) = aef8b4755a748a7e26091a47b8f3edca7f9dab086613bddb146f1d0cc52ceabcf695bec8a8cca4d23a4828f61b9c35af93d5ebbe5940f1d8946b06109cb92177 SHA512 (FreeBSD-11.1-RC1-i386-bootonly.iso.xz) = 48bea65642b8e09feba0b52f79851d9e7392f9fa60f0c5ae265ee3c6ff0af084d3d23634d557e215193799aece80e63466e79f08d70df14754e87bbf3e7e853b SHA512 (FreeBSD-11.1-RC1-i386-disc1.iso) = 92095d32ced586acd8cddb753a90602911c004ade02284b7d8793e0dd31bd352dad1c6bb3f2608af9cbf8d0d7c846817db20db8617597b59d603f942802a54a9 SHA512 (FreeBSD-11.1-RC1-i386-disc1.iso.xz) = 0a33852a9fd7fdb7330d88d20868e7d83aea7a20f3f88018a0f7cd9c98df7ef1766fb06c64815a007f0b6bb3e05725f3a25b2b578b0d41a51406ae4be64556b6 SHA512 (FreeBSD-11.1-RC1-i386-dvd1.iso) = 912da7d7c7ecf0a99176c3fb668f5959682753458a9fc610756f2e4d2d3c343982e407e4900971c0d27bef2ae12a7dd75f02bdb29b9599f46b8c5875430bfa1d SHA512 (FreeBSD-11.1-RC1-i386-dvd1.iso.xz) = 15afe5da04931396c8eb93d701d24f694d16f51e8139badd1085504c05277412192c82b924fb2a9e8ccc4cbac76478ef0a5ecb5c0e877f4be093f5177a72ee6f SHA512 (FreeBSD-11.1-RC1-i386-memstick.img) = e469ae3085f38950760b2a7841c4b05e87aebd3a4a167766bffa2ae4ee7f7ab8efeb4332b24ae735e9f3a0950f55efed7baa66f1316532598a8b6bc780b3eebc SHA512 (FreeBSD-11.1-RC1-i386-memstick.img.xz) = 26bd62f9923941034f399df66e422f073a66e5923cf366bfda62068e4f65efa4e41e619111ecf497a9ae9036cfa7ca77151645e6777b7d1bc0f40fcdfe9ecf72 SHA512 (FreeBSD-11.1-RC1-i386-mini-memstick.img) = 6895d9ec55f56a0c64c93db5dc42f7ed6554198eafd32dff611f6a9f993bfab5b0ca93334c13f7ebd9c56a1a592d72582c3a744f0db60a80358a417cf1ca26e9 SHA512 (FreeBSD-11.1-RC1-i386-mini-memstick.img.xz) = 1c0eb71ed0283b8543add5228df4e2b09799070ff3d126dc8f0f35dc03d37bd73fcbdbd6c042b4c558e9028bf857b6af77ab663ad1026d37ca46c3bd49a91a0f SHA256 (FreeBSD-11.1-RC1-i386-bootonly.iso) = 5f03951c5ce3078228bdc6c4d0380f63e7c33886c758808670d39c1fae41b33b SHA256 (FreeBSD-11.1-RC1-i386-bootonly.iso.xz) = 439e4697c5c4640f2180926889889de2a1c7f119fe5d39d80b6c8de1ab5531bf SHA256 (FreeBSD-11.1-RC1-i386-disc1.iso) = 3f7d1f297dbaee48aaf6b87dcc55ded3eb719e1e308a7a076f4b1b7bfceb1ba0 SHA256 (FreeBSD-11.1-RC1-i386-disc1.iso.xz) = f27b13272b9b90d5bd9ad645c66aab834e003b2ba1e5162445aeaaa70703c2e7 SHA256 (FreeBSD-11.1-RC1-i386-dvd1.iso) = 42cc809758e034e71669adfcc5e8b6fb74bfaef9056b23c07c9ddd193d915fb4 SHA256 (FreeBSD-11.1-RC1-i386-dvd1.iso.xz) = 3089ae1a8d7c381dad6c9a477343626aa57191f9d3d7f5ef2003358db7550f5e SHA256 (FreeBSD-11.1-RC1-i386-memstick.img) = 0ec29e4b1b62e24dfeb6d82c8a2f4e4751f8c513e827db31effd025c1ee85725 SHA256 (FreeBSD-11.1-RC1-i386-memstick.img.xz) = 2ba6fd945121047d218fa958fe892c08a390e229afa33e37eb8e37a40d5de394 SHA256 (FreeBSD-11.1-RC1-i386-mini-memstick.img) = ea93b1cd9be76fb8a8b54b638f5d2100ac8e5bd1fc81efb2a8ad2e99105924f8 SHA256 (FreeBSD-11.1-RC1-i386-mini-memstick.img.xz) = c85a9c1e1bf50bf1871a8f361433dc4e4ff00c4e2597b0023886acafda77517b o 11.1-RC1 powerpc GENERIC: SHA512 (FreeBSD-11.1-RC1-powerpc-bootonly.iso) = a81456f38c5024928ef0a111fe430f12079e6d1d70321604c915f0714257285df955b0f244172fc2de490d46942ea85403e4287a1eaa5ac51cef73afdaf7455f SHA512 (FreeBSD-11.1-RC1-powerpc-bootonly.iso.xz) = 70134802137dafe8b755856fbd47642665edbba30c2f774ff1722f6c03f9a3cefdeab03478eb03283820c5bd3ac8fa1497033b730965f5de872c2347e8c27eea SHA512 (FreeBSD-11.1-RC1-powerpc-disc1.iso) = e0fde742f7588d76bc2979cf9a32dac005cee7a07e5ae4da15ff5abe5967c30711295eabcc5c0fc6f95ddcd73d056a54b1837a5c2ef3bf5cc8875cc951b92f82 SHA512 (FreeBSD-11.1-RC1-powerpc-disc1.iso.xz) = d821ef63b7b2219a62da3cbde7311f8dad75ddb352d8cf4582b219d0d6ff3210b2c32cf71cb7e8546c74f91978562ab34983ce8ee7731652a164b986996b95eb SHA512 (FreeBSD-11.1-RC1-powerpc-dvd1.iso) = 1252e7594cffd9fc1c075bc47141846966b38369b582c2a852bf6673b865234fa38940a18e637b787b464e31bd763bc0884c29d0a1c14aeb0a7fd96f3d1acb5e SHA512 (FreeBSD-11.1-RC1-powerpc-dvd1.iso.xz) = c57f8051073c1121914768367f91aff7d9e56f1fcb246121ea41dbd38bc11e8e1f930b64ae9791637449cacb98b451f1e2ab381f4e502327b1e1aaf3d43553b7 SHA512 (FreeBSD-11.1-RC1-powerpc-memstick.img) = c7fa4d3ccfd621d3880ff29d62b0cf7d7875e6ab816d1333be49d9dfb21d357c0ebb30d52f02410e5deb6e887a4f2a49bace5c91cb9c2d283a6b11734951278e SHA512 (FreeBSD-11.1-RC1-powerpc-memstick.img.xz) = 211286f8090ce8abf4c023c539d15513addb47d2f17612b5929cb558ca7f4dcf77ced4833e72f66599604a7457b9eb010e07b7487067a64fc2a643a4f526fd91 SHA512 (FreeBSD-11.1-RC1-powerpc-mini-memstick.img) = 8d01a185d359e75b7b78aed0d18fb5543b4699471317de9372d2907c403ae5f17eba4fcf8f4c30e8d88bfe417d78056e3e2620d6705ae14b554fe3a854b63a12 SHA512 (FreeBSD-11.1-RC1-powerpc-mini-memstick.img.xz) = 872abe5b872d127e4089b37704bce04d8336eadedfe614ba8f74aabaa0fcd522df0b1bf35fb4a3ba93b0721717313795d0debda27a495b2a8254dfbc41051c30 SHA256 (FreeBSD-11.1-RC1-powerpc-bootonly.iso) = dc8de4715d549884232bf26e003a5788e5982cf33b4825aa6a0d0e22c71715aa SHA256 (FreeBSD-11.1-RC1-powerpc-bootonly.iso.xz) = a9d372ae32a377d9f15b4c462daf6a9d861177f2200723fd4e9b70a419344756 SHA256 (FreeBSD-11.1-RC1-powerpc-disc1.iso) = 568e1818b7ce8b9fe786e7094f78031a4335cd831f5e589cfea3ecbbf55bf1a5 SHA256 (FreeBSD-11.1-RC1-powerpc-disc1.iso.xz) = 4ba2b570158b5c1d210e29255b77740527dd510ec2bb2e63ee7d9fc2306e1ac5 SHA256 (FreeBSD-11.1-RC1-powerpc-dvd1.iso) = fa5c0e605349c5321f86f9ca811873b8574d11bc83da9941d964393aa311ce5b SHA256 (FreeBSD-11.1-RC1-powerpc-dvd1.iso.xz) = 5adea906cb886a3e86a68525f0a06c8d2121063377649dcd1e64807c2adf3df6 SHA256 (FreeBSD-11.1-RC1-powerpc-memstick.img) = 5eaabfecc9b5d4bc2753358d1bab6a0d27f9a9299ae126328eaeec0f87694e67 SHA256 (FreeBSD-11.1-RC1-powerpc-memstick.img.xz) = 230d3aea0811fd0b1d7af69493d170953fabeb820c57f68255d8d45f4a559a45 SHA256 (FreeBSD-11.1-RC1-powerpc-mini-memstick.img) = 5e37856a4a72c67b6b79f8ad036886ee96fd9e8628164bbbf745b7eb62583dc8 SHA256 (FreeBSD-11.1-RC1-powerpc-mini-memstick.img.xz) = b70949ba60161cf44d87d156f30d3b33307ab0f32b9ee9c5dd25e9b81d41fa9c o 11.1-RC1 powerpc64 GENERIC64: SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-bootonly.iso) = 24e7fda2fa3d9837581d16c6ad57f805aecf10eff024a86022f334302aed7f6f836a3b19d41f4ec3a53a06a9ed25413b90dd0e4334a79b98299958c0b4b77883 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-bootonly.iso.xz) = 26c84ddf697eda1f1d57a97ca4e6c33ee19980f467dce2e99169c32a22e4d5db2471c0a7f1c84a240d95e14d7d5ed555f75c17d24af3471021ae26dbb8f1908e SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-disc1.iso) = 864c8b9b8a52fc9f73bc11e5226229257b6d9015ceaae50383a8cdd0b421df3cb97b5ce93a0a7576651e2e9c1ff891f5f3bdc08df2e7b34ebad7c9a88a6c8446 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-disc1.iso.xz) = 71ad13c25e91bc46ca791cceb354fd3c10bbf487a776030ec3517c4a85ddea5dddcc57fc227ceb697c4ad77c3fb83804228516ada5980e6a1664e60816615901 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-dvd1.iso) = 1f9753147c7ba129e08d327c742f3a61dfe9b12f2847866b6eb46d0a4c036b56e578a390d2fe13a67b52cd20cf638824c7d000fed57792022ece89b7cfab17a0 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-dvd1.iso.xz) = e634a8722fd4f54753e0094f6e66876f5ad0c4b9d25448210d3a19c122cfde09e80e136fad05eb52e6aec0e932684489700c0704e40b6f35d67eed8360e33212 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-memstick.img) = 41f3afc708aeea8a8b33004f11732cefeb17061391b547d695f4bd22f23d91ef5a20482af761932572fff4b8edca241184f59941e7f6bbf788702902ed34ac01 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-memstick.img.xz) = 56c7c7acd92e581a9a468ca3966d597fd1afcc6b22de311a0843e31b42535609e3aef3f2f82b0498aeb19a54773c7d46a4ca479332773eab29b03a3dc77cf9d7 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-mini-memstick.img) = a99a0cb51a64ea1b5cc8066a87e359b6e9e8e5175f14e52840b6e6de16e7eacefe31034fd42f3e34bcef352cdae957a3eea7ac22f278d1fb3c0678d7ec0dd956 SHA512 (FreeBSD-11.1-RC1-powerpc-powerpc64-mini-memstick.img.xz) = 50251e2133b203c42740c0d969fdfa09c29300e4c1686b16ce920c016c418c84b1a47a98e61c207f2a8bb9ae0ec0788003ecbdf81eaaaefedbebfb5381a49386 SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-bootonly.iso) = 441a75b55639719b9db10fcf219ebcf463160f4f1fa555633bddc8a2188e18ba SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-bootonly.iso.xz) = 6664eaec87e2b110150e2bcaf87cb07c758f032d1d096c1b21cf73190ee4a82c SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-disc1.iso) = b9a2e1aaf36580af6b2f3fb9a1754822491da5a1581a1298ffc4c03c30845f58 SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-disc1.iso.xz) = 0ca3892f7f312376cd93416399b8746d737b2344f9126f8f8310291403971026 SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-dvd1.iso) = f7052cfc2164f3e64f1db189a6310a519cac5bb03a38f69ad0421a09ccdd6c9d SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-dvd1.iso.xz) = fef26ef9c45d70ff24a784a629bf55f7046a90b00325bc160784bf1f7052c599 SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-memstick.img) = 8269ada209ba2860d589ed198efcbc527e1bcc4928f75cd535b4aa71bf55e61f SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-memstick.img.xz) = da1dcf95d2192d1e067bae2e478746bf4e15d831f5b6d7316339c7203edcfc80 SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-mini-memstick.img) = a860bdd263b530199c53b80a28bb605e66429179200dfdd58d021eb3fb64145c SHA256 (FreeBSD-11.1-RC1-powerpc-powerpc64-mini-memstick.img.xz) = 4db4852ae1e78aed1c15d107002684d77e3f5b8b396bcc9f555c8add385b5ae0 o 11.1-RC1 sparc64 GENERIC: SHA512 (FreeBSD-11.1-RC1-sparc64-bootonly.iso) = 569711e8bd6b69d4893d4617ad47ee6ac51144167c462b8f0785df45bf3d3d7c5ba0c3b146281dbc598cfd46cbad211ffa93b3e8e225cc0b9658ddd0964140d5 SHA512 (FreeBSD-11.1-RC1-sparc64-bootonly.iso.xz) = 7199afca50b779338443f2ec5166cc2026b44c92ab093e49c45ae7a6950c348643e0c673ba74fb05e2c35e26da18ca4e80ada03809a39312fc4f7043c4c5d187 SHA512 (FreeBSD-11.1-RC1-sparc64-disc1.iso) = 442129506763f41989d4c374af898fc1dcb3431e237a5ea7b45d00b4dba85f032488684daa22f4faca2f9f78f2d3d1a3ea385df35168240a55fbc0daa7cf0641 SHA512 (FreeBSD-11.1-RC1-sparc64-disc1.iso.xz) = a4feab21a28372aef9707130ac033ca8f29470fdf4f5cce4f76c2a4d9a7b85283c687b5401c8851ed4e6cdea689673a0e7050a30a6061fdd09489cb8886e02a8 SHA512 (FreeBSD-11.1-RC1-sparc64-dvd1.iso) = b549ea7c6433eccfa060eb8bb20f21b929d0f5037299afe3b0a94fed1e3160b1c0f63d669ff349d629f54226b5b7109ffea964eeb78b838a45433a785203b72e SHA512 (FreeBSD-11.1-RC1-sparc64-dvd1.iso.xz) = 9c02ee6e3fd5747dee2c005d2b9a6ae42e5199a6a6de7e5f06d0624788cd28d76c9ac87c1ddab604a43f5a55fec6cc8cb28b4d945a10f20f29c182937d7a6713 SHA256 (FreeBSD-11.1-RC1-sparc64-bootonly.iso) = bbae1323410adf1ede635a3b13ab1ea559363db4d2955fd59f314fc7fd8b7d0b SHA256 (FreeBSD-11.1-RC1-sparc64-bootonly.iso.xz) = c82919a63d0e0029b8643ac02ef5bbdb965bd0e01cbaf328b72d4bb0e0bcdec3 SHA256 (FreeBSD-11.1-RC1-sparc64-disc1.iso) = 400f314f32faac9a2819b24e2985a6c67cadcf54304019f650b9d3f8e35a871b SHA256 (FreeBSD-11.1-RC1-sparc64-disc1.iso.xz) = b1dc752bf3dc26f7311c6798cb175692ba94f0a044b32f00ffe9b417e0df86fd SHA256 (FreeBSD-11.1-RC1-sparc64-dvd1.iso) = dbee5d8a1ee168ace5c1ed5a7746156584edba74485a9aca22358befa74017c6 SHA256 (FreeBSD-11.1-RC1-sparc64-dvd1.iso.xz) = e0f4e55c093e307a99e8ac2809e15d4ad7500d91e105ba9a1a682cdd131af684 o 11.1-RC1 armv6 BANANAPI: SHA512 (FreeBSD-11.1-RC1-arm-armv6-BANANAPI.img.xz) = a5816e34bb773b4f60e424188479883f872ef1d9c04fdfb1dc5b26faf6fff82959cf8588a0b1a6713c96763fc02d22c55f47d52e166ade50f87d61625c2eb701 SHA256 (FreeBSD-11.1-RC1-arm-armv6-BANANAPI.img.xz) = 44e98dcb6ba1abd27861819ed71736bede8cb286deb6fd795ffac710f4ce01ed o 11.1-RC1 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.1-RC1-arm-armv6-BEAGLEBONE.img.xz) = 2cdb49d1b843b91a257561a2c0e7f9d921aaa6f0525faf69c12bc8bafc63eff13ce7a02afe807f5dd58671acf158c671e4063b747304b668b1cbe40ff00c6f09 SHA256 (FreeBSD-11.1-RC1-arm-armv6-BEAGLEBONE.img.xz) = 128b9f88e3f746b4b79f8184b80daf5d0dc7f27f86959ec7cb43296841d134d1 o 11.1-RC1 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.1-RC1-arm-armv6-CUBIEBOARD.img.xz) = a9529c23109ec343107b5fd5489334b2da208fe3de7f50f03f31294269af88ed3b7d60c7de9b0fe6a33985547ce136fdf92d75385fa86d842a0c2fb79d81dd73 SHA256 (FreeBSD-11.1-RC1-arm-armv6-CUBIEBOARD.img.xz) = 6639cd5d1ea766a619cb7a7a17889b840626ea0d659232b0e54c9fd1cdbe04d8 o 11.1-RC1 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.1-RC1-arm-armv6-CUBIEBOARD2.img.xz) = f949e34e574efa31177df82d8de7a9a337830484b3ae528c09ff01ff517d92d1786a8c0a9f9bfe8dfc0ff1746b1c22e70d00ca738e630016a34a403368816a62 SHA256 (FreeBSD-11.1-RC1-arm-armv6-CUBIEBOARD2.img.xz) = e6c764bd528bf4660f68f810034e1a30ebae1c31c86f3322bfad2e4115073d8d o 11.1-RC1 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.1-RC1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = d7b0ac23e451dc989cebcba407427e2a64d3e37c0e4bfa23d5ecdabe7814dfdb0f4ed1be62b43e6dcc28b50170095b286edb01dfc4073f10de54fe655bde407d SHA256 (FreeBSD-11.1-RC1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = e7228bccff119bd8e57825d5ad12fa4ef229a0884e1aff7a8dffbad678c1ec63 o 11.1-RC1 armv6 GUMSTIX: SHA512 (FreeBSD-11.1-RC1-arm-armv6-GUMSTIX.img.xz) = 8c4fec5d814ba4327fbd2ec73b36930b65a463eeec69d14e7db35ccf8d068e6b19caf031fb5b62864377168b2f6be1f13fcc76b17d65e2ea62c0cd5bf3e251a0 SHA256 (FreeBSD-11.1-RC1-arm-armv6-GUMSTIX.img.xz) = e50fdb9b6723215c273da9adb601cc466ddf6c0c0a0ccb43efbea3fca4199127 o 11.1-RC1 armv6 RPI-B: SHA512 (FreeBSD-11.1-RC1-arm-armv6-RPI-B.img.xz) = 5c3e6426bf1a06ac4c28a72836e09570e7de141b477749f63ec4f1ad4e1cc245bec55bd95bc4a286c677ce3ac57bc1b9c22413f288ae2eba411bf80c4e1590e3 SHA256 (FreeBSD-11.1-RC1-arm-armv6-RPI-B.img.xz) = e8e7efed71b8927daaab6ff9dec72768f4155f426a5a2e90f3104c829704e26b o 11.1-RC1 armv6 RPI2: SHA512 (FreeBSD-11.1-RC1-arm-armv6-RPI2.img.xz) = d65ce9f476edbbb80bc13e68e805352b69488312421cb6cc55666c70da77289c41150dbf6e7512d2d81aa0f76996114b249e25866420b57ad52572efbafef685 SHA256 (FreeBSD-11.1-RC1-arm-armv6-RPI2.img.xz) = 3496b1af8f2d9b3ab077b2786e880f68f7e8851cfcc835417e6bfd0fd4ace5cb o 11.1-RC1 armv6 PANDABOARD: SHA512 (FreeBSD-11.1-RC1-arm-armv6-PANDABOARD.img.xz) = 2e955b3dc6e5f8b8bf1f5c9bf27b2bead14bf02b9955eb82d4b2c7ff8600f98cafa0acf48175715c4ff70768dd1f0a326ceb5c34a82f5a6517756c97d623d8b3 SHA256 (FreeBSD-11.1-RC1-arm-armv6-PANDABOARD.img.xz) = f656ff543f0e8d60facbe49f7ee599339ff4d2691948b6c2da4bff45c4bd3aa4 o 11.1-RC1 armv6 WANDBOARD: SHA512 (FreeBSD-11.1-RC1-arm-armv6-WANDBOARD.img.xz) = a9d693709d7b4f8ddca512e325813164452b3b6d183c5a1c6f49005d3d3a7bc9b0caedfa25d1f49bad4ba2bb35b25fba248d39a45d266c79a7aee9632d0ad01f SHA256 (FreeBSD-11.1-RC1-arm-armv6-WANDBOARD.img.xz) = 6269619f5eb86e928cb476723dc052702ba14151dd2a73905388ea1ede08a257 o 11.1-RC1 aarch64 GENERIC: SHA512 (FreeBSD-11.1-RC1-arm64-aarch64-memstick.img) = bd3162825d266086211edc25cb49e358ccee52ba97e77696d0c254d87b866974967a237ec2b8d56383128d8b4dfff13bcf5e8381da75a5224000aea17f3111a8 SHA512 (FreeBSD-11.1-RC1-arm64-aarch64-memstick.img.xz) = 60ded5c18485c9de17c4fd7cdd7715a54217e09c163b5ca670303de2cfaffca7d6c590addc30830bbf2afedcf1253cd3581461670a557b78e94b2f845d8ec034 SHA512 (FreeBSD-11.1-RC1-arm64-aarch64-mini-memstick.img) = 1747faf32f95ea128557044f471314fa7514dacbb4104cae2fc161e7f47d5ff8bb70b2bf21bb17981472cf375ac19ae87c6dbec96bbac5a4fedd1ed340a66eea SHA512 (FreeBSD-11.1-RC1-arm64-aarch64-mini-memstick.img.xz) = dc904801354adf3e09d22c6d23f445de8323c1d1073978e0af3d75b7f9bae83c2e6255f93ce262ba84ee071355b7597988cab6b32b9f6349b7e2da31ac38ed3a SHA256 (FreeBSD-11.1-RC1-arm64-aarch64-memstick.img) = a03475f970ae06bdf1c5ad3bc349f4f60e97073cfbfce5d18704afe481f215cc SHA256 (FreeBSD-11.1-RC1-arm64-aarch64-memstick.img.xz) = 9341966a4325527dbccbef5e26e17f28ed898cfdc370c444b145286702870481 SHA256 (FreeBSD-11.1-RC1-arm64-aarch64-mini-memstick.img) = 6d1a1562ebd9e6ba54ba91da364b58530ecd0d3c28542b41a6474c6a1e6c50f2 SHA256 (FreeBSD-11.1-RC1-arm64-aarch64-mini-memstick.img.xz) = 6acf903bb50edc54ded624fa25ec110c08fe1dc44a4ba68ea158aa980ed5a8f5 == VM IMAGE CHECKSUMS == o 11.1-RC1 amd64: SHA512 (FreeBSD-11.1-RC1-amd64.qcow2.xz) = ead5fdde1fae60bd47a17460c5ed596048643964ac9592ec6b4ed75fdd09240010f4f37485a185882dfb34f799edc25b6d95f2250020d3f228ec02f0eb40e85e SHA512 (FreeBSD-11.1-RC1-amd64.raw.xz) = 05539c740a982a1ddd2cad5a7eb35c38bdd3380552cb320740fa20e19d3c90d0b659059f158cec8c36ad5531f2217ae0917afc533bbe1d6391052de33d82ca0c SHA512 (FreeBSD-11.1-RC1-amd64.vhd.xz) = 5096065e6a4f41ffb981249ff86b3e35334d0db43a5cbb3fce9fe885b4b33c8784b11ceb616edd2c71c9f670eadfbcda281ef6a606d82d4589780e9838f503e9 SHA512 (FreeBSD-11.1-RC1-amd64.vmdk.xz) = b4bcb8d1d3d7273a4945806c0e95f16855d9e0a0f8501c7fcd4477704c366772f4a4347c3087474ec1b117176770c7996536906dddfbd447b1e4acb41be061c0 SHA256 (FreeBSD-11.1-RC1-amd64.qcow2.xz) = 91fecf695fce403d3ac13d9e6b7f1dbaf020c8f5a18b45332b71d9ff3aa3e0b9 SHA256 (FreeBSD-11.1-RC1-amd64.raw.xz) = b51bd3000f6bd122a7ceb42c05a5ad71de5304acc9aae05a48747c6655728e4d SHA256 (FreeBSD-11.1-RC1-amd64.vhd.xz) = 561843881fbef4aafb8ab44282e6aa91032a22b233b0e113b64c2f013e493c78 SHA256 (FreeBSD-11.1-RC1-amd64.vmdk.xz) = e35e2867e2cc0ba97f0f6497b1ed1c21af2f96fa0c23ee227a866ccd12f91c60 o 11.1-RC1 i386: SHA512 (FreeBSD-11.1-RC1-i386.qcow2.xz) = f5d6c0373f25d4d421a91b5b8b5a56b862252b5b3116b7cf7a34513107518ca4d1ecb505a9448a54a549f6d34dc370a096017e500f38be36b810b379b84f1d2a SHA512 (FreeBSD-11.1-RC1-i386.raw.xz) = eabb8c74b7567fabd1787955489e6568fd873c72bb84d899658e109a25c1e2b5656dd8c12bae4743c4c85ed4118394a7173a8f87aae05eda28c8bf3d4200843f SHA512 (FreeBSD-11.1-RC1-i386.vhd.xz) = 3ad7dd6cd57d75580172a31b5d2f7b6b2e5771549c9442b3f9aad8dea3cf32cbb75b7abaa7ca538f7ad4e299972ab6366c12ad1b1503a0ec486297196c933728 SHA512 (FreeBSD-11.1-RC1-i386.vmdk.xz) = b0649dcec768486f77085ba5e1b07a8e78b0c10870cf0d3aee24826aa4dd1176077c4a05144bcde4184a687089fcb389ab1a760b6546534009cfbf337526fe18 SHA256 (FreeBSD-11.1-RC1-i386.qcow2.xz) = 9ce9cfe7f833f608a75ee4763d4ca07941eecd0b6fe9928b66de918afe0ab64c SHA256 (FreeBSD-11.1-RC1-i386.raw.xz) = 21d11cbd291cb45fc281d54f28fcfc51666f007512041fb3bb4d94e2cb15ea1e SHA256 (FreeBSD-11.1-RC1-i386.vhd.xz) = 1a74bba140c76efbd7d6a6e742713fe41140e91a0338510fa5aa8d8c0d254138 SHA256 (FreeBSD-11.1-RC1-i386.vmdk.xz) = ba30a8fae6485f38bd5ef77ce4115235a6150fc11d6a40f7e7e32c374dfc450d o 11.1-RC1 aarch64: SHA512 (FreeBSD-11.1-RC1-arm64-aarch64.qcow2.xz) = 7ee4c3a0ee9796d529b2a6c67c70149c2a968d8bf0bdcb5d6ac555ffd765c815879f6ddab40a09db52906ce6cf66e73f5db00ec4fad1f2bad33f61fad14267b3 SHA512 (FreeBSD-11.1-RC1-arm64-aarch64.raw.xz) = 1ed6acce9dc004a299f03e7cc40364fbf3217bed282d55a6a1701bde93d47527d4901a0e7e1dadd1d70eeace587463e3cd53982aab5e00e7c8eb052388a9d036 SHA512 (FreeBSD-11.1-RC1-arm64-aarch64.vhd.xz) = d5127033054b018a0e681638a55af87cd836eebf30dd9ea59fbf14ac13a89e71bd39c342fce741c894a351d11c315069162be7cefaceaef02db999656f28069b SHA512 (FreeBSD-11.1-RC1-arm64-aarch64.vmdk.xz) = 5ead71615b79046c690b15947c45c4352899ee4b848a6c418798073952520ef25c76cf534a6cad195a6ed32e0ef32ea81ab1f74b81275d8cd386a47c09a556d7 SHA256 (FreeBSD-11.1-RC1-arm64-aarch64.qcow2.xz) = ef8fcc0148c098789119549ccb34a4c0265f5a028983b2a35bad4d11eebcd5b0 SHA256 (FreeBSD-11.1-RC1-arm64-aarch64.raw.xz) = cb3ff377f8da9f6b59ca898b00b57dfd45a6051d5627ad0ef03e02714e315021 SHA256 (FreeBSD-11.1-RC1-arm64-aarch64.vhd.xz) = 1f33ba341ff7e9df5febfdba205df68c7609cb61a3e19701adc18e9687f645ff SHA256 (FreeBSD-11.1-RC1-arm64-aarch64.vmdk.xz) = fddbdb9f0266bfc82907903c5c01eaa6fbd07224d8ca8114d514283f0599ec5c Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAllXtVwACgkQAxRYpUeP 4pPA4w/+Pcw2i921fYZrZzsDH+gKe1vj7o9OUABZ5Nb2pZ+S4A8hxWxTLxUOMfhZ ol6WoOpxWR3dvHAjOfPKOpTAbYgozGxHN+Am2prYy4E4vpZHwNxCfpLw19vi5uXJ vTubLVifvrj5kMcwsOfu3QkVzuagSrRLi+v1stQlYIugT5MqHpf6o5JHtUMj5FtQ Mz2Y4HZ9SELQGpr7MGNBeucW0rONhlE+aRq+25eBBfZ9HBs1FW96V9VmJbTIoZ4M QjfADXhc/Z1NqYwo124hR7mUImvKri4PVzWIAFjK5Zs2laPlJwT0uoTIRbHJOhT8 XjxI7tLRdfu8/Th0pEMSI1QyMi6z5FTZnbPJ4rfOR9W5N1pBEYCoKmpdSupZ9git 6nMMhCCnhZO7pA/1Xy1zRLfOtYDmY8bX+jPGpGzY9tMPgrTi24AK4fRJMOlQU2wp kBWL54LcXx8I5ACIE4myjmU1XeyqAq3Di2MogJlzd4C5mFEeX4Btt2bG+hEdMGhD RWz8N4owWMGI9V1dLOWW3ZhVjFjxsUtXlWn3Pg2UDyQFfJl7UW+wOqGgonNzvMjV 2Tczt2j13o2Kz/b2ij9xjSAqs/1a3edMqrxScoAucXWmihmTIrEY6bKcjo5OHvwo ynIYEFJWYsWkYzmidoNMxoBinA5mGwYa+VwXa0ddsx4y6jfWK6A= =O/F9 -----END PGP SIGNATURE-----