From owner-freebsd-current@freebsd.org Sun Jul 22 01:01:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D66CD1031F09 for ; Sun, 22 Jul 2018 01:01:17 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 75F637E3B3 for ; Sun, 22 Jul 2018 01:01:17 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 362941031F08; Sun, 22 Jul 2018 01:01:17 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 122A41031F07 for ; Sun, 22 Jul 2018 01:01:17 +0000 (UTC) (envelope-from lwhsu@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 BB5167E3AE; Sun, 22 Jul 2018 01:01:16 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 954366984; Sun, 22 Jul 2018 01:01:16 +0000 (UTC) Date: Sun, 22 Jul 2018 01:01:16 +0000 From: Li-Wen Hsu To: Konstantin Belousov Cc: current@FreeBSD.org, br@freebsd.org Subject: Re: FreeBSD-head-riscv64-build - Build #9623 (r336573) - Failure Message-ID: <20180722010116.GA13419@freefall.freebsd.org> References: <941706773.1.1532139392496.JavaMail.jenkins@jenkins.ci.freebsd.org> <20180721231832.GC65334@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20180721231832.GC65334@kib.kiev.ua> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 01:01:18 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 22, 2018 at 02:18:32 +0300, Konstantin Belousov wrote: > On Sat, Jul 21, 2018 at 02:16:17AM +0000, jenkins-admin@FreeBSD.org wrote: > > --- lib/ofed/libmlx5__L --- > > In file included from /workspace/src/contrib/ofed/libmlx5/mlx5.h:44:0, > > from /workspace/src/contrib/ofed/libmlx5/buf.c:42: > > /workspace/obj/workspace/src/riscv.riscv64/tmp/usr/include/infiniband/udma_barrier.h:108:2: error: #error No architecture specific memory barrier defines found! > > #error No architecture specific memory barrier defines found! > > ^~~~~ > > The patch below should be enough to fix the build, modulo the syntax > errors which I cannot check. The reason is that it seems riscv is not > cross-buildable from stable/11 host: > --- includes_subdir_include/rpcsvc --- > RPCGEN_CPP=cpp\ -target\ riscv64-unknown-freebsd12.0\ --sysroot=/usr/home/konstantinb/build/bsd/DEV/obj/usr/home/konstantinb/build/bsd/DEV/src/riscv.riscv64/tmp\ -B/usr/local rpcgen -C -h -DWANT_NFS3 /usr/home/konstantinb/build/bsd/DEV/src/include/rpcsvc/klm_prot.x -o klm_prot.h > --- key_prot.h --- > error: unknown target triple 'riscv64-unknown-freebsd12.0', please use -triple or -arch > *** [key_prot.h] Error code 1 > > make[4]: stopped in /usr/home/konstantinb/build/bsd/DEV/src/include/rpcsvc > > So if somebody who care about riscv and can build the world could > confirm the fix, I will commit it. > > diff --git a/contrib/ofed/include/udma_barrier.h b/contrib/ofed/include/udma_barrier.h > index 71d264f8dce..6709d4433a7 100644 > --- a/contrib/ofed/include/udma_barrier.h > +++ b/contrib/ofed/include/udma_barrier.h > @@ -104,6 +104,10 @@ > #include > #include > #define udma_to_device_barrier() dmb() > +#elif defined(__riscv__) > +#include > +#include > +#define udma_to_device_barrier() fence() > #else > #error No architecture specific memory barrier defines found! > #endif Thanks for looking into this. Attached patch is slightly modified. RISC-V is using __riscv and there are few more atomic macros need to be defined. However this seems not enough, there are some c++ errors which may take longer to fix: In file included from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:43:0, from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/acm.c:42: /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer atomic_store(&lock->cnt, 0); ^ In file included from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/acm.c:42:0: /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' if (atomic_fetch_add(&lock->cnt, 1) > 0) ^~ /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' if (atomic_fetch_sub(&lock->cnt, 1) > 1) ^~ *** [acm.o] Error code 1 make[6]: stopped in /usr/home/lwhsu/freebsd-src/lib/ofed/librdmacm BTW, stable/11 should be fine to cross-build riscv64, this job uses 11.2-RELEASE and riscv64-xtoolchain-gcc package, with CROSS_TOOLCHAIN=riscv64-gcc defined. Best, Li-Wen -- Li-Wen Hsu https://lwhsu.org --uAKRQypu60I7Lcqm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="udma_barrier.h.diff" Index: contrib/ofed/include/udma_barrier.h =================================================================== --- contrib/ofed/include/udma_barrier.h (revision 336593) +++ contrib/ofed/include/udma_barrier.h (working copy) @@ -104,6 +104,10 @@ #include #include #define udma_to_device_barrier() dmb() +#elif defined(__riscv) +#include +#include +#define udma_to_device_barrier() fence() #else #error No architecture specific memory barrier defines found! #endif @@ -140,6 +144,8 @@ #define udma_from_device_barrier() mips_sync() #elif defined(__arm__) #define udma_from_device_barrier() dmb() +#elif defined(__riscv) +#define udma_from_device_barrier() fence() #else #error No architecture specific memory barrier defines found! #endif @@ -208,6 +214,8 @@ #define mmio_flush_writes() mips_sync() #elif defined(__arm__) #define mmio_flush_writes() dmb() +#elif defined(__riscv) +#define mmio_flush_writes() fence() #else #error No architecture specific memory barrier defines found! #endif --uAKRQypu60I7Lcqm-- From owner-freebsd-current@freebsd.org Sun Jul 22 14:27:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82834104D036 for ; Sun, 22 Jul 2018 14:27:06 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 0718D76CF7 for ; Sun, 22 Jul 2018 14:27:05 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wr1-x435.google.com with SMTP id s11-v6so15377884wra.13 for ; Sun, 22 Jul 2018 07:27:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oqU5jW5WbTR+9r7bcAjsRTbT7YUVVugsIz4mDafWyh4=; b=jlkpjI7MRCT0FKPktZAPUIJNUSgjXGCoHloY/2KycuEN5a0WfyKhcguHNWmqcK6/7c bczguM07c/kWDSkAlJp6O584nlN0xwhl7u7UX9qWtefe4FEpvPoc0AehM0j/GBbqKud6 4IB34UTvnAC2wo62fhuBRYe+prQp8ThzR74KnYkPMGJd9cfX1baqXe2LFxqsLQJb+0cg VJbsRoftqyIsv1UaJ8S/M++6fsG0S7zIQHXAGk1IRrq1ub/gnAuQnDHPhbj+DkBxX47u /Bjfy16zdYjbGt6VcrHdHUXgtICxArjAvdxnoft6m1noxJm6hiTL/fS2ugyTUaC9G//g R3pw== X-Gm-Message-State: AOUpUlFqSexlnbZMvEIbL+RGSrXed9g5DwZIc62C41X12EGJgeRKJmyG sfSxtfuWRhJPMbajuLho7N+fVnQTi28= X-Google-Smtp-Source: AAOMgpfZ7snDUJhP1d2LPJGME1znmITYMaUria3Ks7DbNU019RNI/gJRANtGfYG964PR1Rhm/wDYHw== X-Received: by 2002:adf:f9c9:: with SMTP id w9-v6mr6091230wrr.105.1532269624856; Sun, 22 Jul 2018 07:27:04 -0700 (PDT) Received: from gumby.homeunix.com ([90.205.255.240]) by smtp.gmail.com with ESMTPSA id q11-v6sm10094412wrp.58.2018.07.22.07.27.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 22 Jul 2018 07:27:04 -0700 (PDT) Date: Sun, 22 Jul 2018 15:27:02 +0100 From: RW To: Cy Schubert Cc: "freebsd-current@freebsd.org" Subject: Re: ntpd as ntpd user question Message-ID: <20180722152702.53b4d9bc@gumby.homeunix.com> In-Reply-To: <20180721190218.0EF0F79C@spqr.komquats.com> References: <20180721190218.0EF0F79C@spqr.komquats.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 14:27:06 -0000 On Sat, 21 Jul 2018 12:02:19 -0700 Cy Schubert wrote: >> I wish mergemaster had an option to just add new users and groups, >> rather than merging the files. > What's the difference? It would be automatic, so less hassle and no chance of getting the merge wrong. From owner-freebsd-current@freebsd.org Sun Jul 22 15:45:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 785FE104E908 for ; Sun, 22 Jul 2018 15:45:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E302E791FC for ; Sun, 22 Jul 2018 15:45:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9C71F104E907; Sun, 22 Jul 2018 15:45:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78440104E906 for ; Sun, 22 Jul 2018 15:45:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 006E7791F7; Sun, 22 Jul 2018 15:45:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w6MFj5hJ062534 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 22 Jul 2018 18:45:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w6MFj5hJ062534 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w6MFj5x9062533; Sun, 22 Jul 2018 18:45:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Jul 2018 18:45:05 +0300 From: Konstantin Belousov To: Li-Wen Hsu Cc: current@FreeBSD.org, br@freebsd.org Subject: Re: FreeBSD-head-riscv64-build - Build #9623 (r336573) - Failure Message-ID: <20180722154505.GE65334@kib.kiev.ua> References: <941706773.1.1532139392496.JavaMail.jenkins@jenkins.ci.freebsd.org> <20180721231832.GC65334@kib.kiev.ua> <20180722010116.GA13419@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180722010116.GA13419@freefall.freebsd.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 15:45:19 -0000 On Sun, Jul 22, 2018 at 01:01:16AM +0000, Li-Wen Hsu wrote: > On Sun, Jul 22, 2018 at 02:18:32 +0300, Konstantin Belousov wrote: > > On Sat, Jul 21, 2018 at 02:16:17AM +0000, jenkins-admin@FreeBSD.org wrote: > > > --- lib/ofed/libmlx5__L --- > > > In file included from /workspace/src/contrib/ofed/libmlx5/mlx5.h:44:0, > > > from /workspace/src/contrib/ofed/libmlx5/buf.c:42: > > > /workspace/obj/workspace/src/riscv.riscv64/tmp/usr/include/infiniband/udma_barrier.h:108:2: error: #error No architecture specific memory barrier defines found! > > > #error No architecture specific memory barrier defines found! > > > ^~~~~ > > > > The patch below should be enough to fix the build, modulo the syntax > > errors which I cannot check. The reason is that it seems riscv is not > > cross-buildable from stable/11 host: > > --- includes_subdir_include/rpcsvc --- > > RPCGEN_CPP=cpp\ -target\ riscv64-unknown-freebsd12.0\ --sysroot=/usr/home/konstantinb/build/bsd/DEV/obj/usr/home/konstantinb/build/bsd/DEV/src/riscv.riscv64/tmp\ -B/usr/local rpcgen -C -h -DWANT_NFS3 /usr/home/konstantinb/build/bsd/DEV/src/include/rpcsvc/klm_prot.x -o klm_prot.h > > --- key_prot.h --- > > error: unknown target triple 'riscv64-unknown-freebsd12.0', please use -triple or -arch > > *** [key_prot.h] Error code 1 > > > > make[4]: stopped in /usr/home/konstantinb/build/bsd/DEV/src/include/rpcsvc > > > > So if somebody who care about riscv and can build the world could > > confirm the fix, I will commit it. > > > > diff --git a/contrib/ofed/include/udma_barrier.h b/contrib/ofed/include/udma_barrier.h > > index 71d264f8dce..6709d4433a7 100644 > > --- a/contrib/ofed/include/udma_barrier.h > > +++ b/contrib/ofed/include/udma_barrier.h > > @@ -104,6 +104,10 @@ > > #include > > #include > > #define udma_to_device_barrier() dmb() > > +#elif defined(__riscv__) > > +#include > > +#include > > +#define udma_to_device_barrier() fence() > > #else > > #error No architecture specific memory barrier defines found! > > #endif > > Thanks for looking into this. Attached patch is slightly modified. > RISC-V is using __riscv and there are few more atomic macros need to be > defined. Well, the arch(7) manpage documents __riscv__. Compilers typically provide both __XXX__ and __XXX, while FreeBSD traditionally uses the __XXX__ form. With that change, I think that your patch should go in regardless of the second issue below. > > However this seems not enough, there are some c++ errors which may take > longer to fix: > > In file included from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:43:0, > from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/acm.c:42: > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer > atomic_store(&lock->cnt, 0); > ^ > In file included from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/acm.c:42:0: > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' > if (atomic_fetch_add(&lock->cnt, 1) > 0) > ^~ > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' > if (atomic_fetch_sub(&lock->cnt, 1) > 1) > ^~ > *** [acm.o] Error code 1 > > make[6]: stopped in /usr/home/lwhsu/freebsd-src/lib/ofed/librdmacm I will look at this later, but it seems that linuxkpi is not ported. I will disable OFED on RISC-V. > > > BTW, stable/11 should be fine to cross-build riscv64, this job uses > 11.2-RELEASE and riscv64-xtoolchain-gcc package, with > CROSS_TOOLCHAIN=riscv64-gcc defined. > > > Best, > Li-Wen > > -- > Li-Wen Hsu > https://lwhsu.org > Index: contrib/ofed/include/udma_barrier.h > =================================================================== > --- contrib/ofed/include/udma_barrier.h (revision 336593) > +++ contrib/ofed/include/udma_barrier.h (working copy) > @@ -104,6 +104,10 @@ > #include > #include > #define udma_to_device_barrier() dmb() > +#elif defined(__riscv) > +#include > +#include > +#define udma_to_device_barrier() fence() > #else > #error No architecture specific memory barrier defines found! > #endif > @@ -140,6 +144,8 @@ > #define udma_from_device_barrier() mips_sync() > #elif defined(__arm__) > #define udma_from_device_barrier() dmb() > +#elif defined(__riscv) > +#define udma_from_device_barrier() fence() > #else > #error No architecture specific memory barrier defines found! > #endif > @@ -208,6 +214,8 @@ > #define mmio_flush_writes() mips_sync() > #elif defined(__arm__) > #define mmio_flush_writes() dmb() > +#elif defined(__riscv) > +#define mmio_flush_writes() fence() > #else > #error No architecture specific memory barrier defines found! > #endif From owner-freebsd-current@freebsd.org Sun Jul 22 16:34:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D66BC104FBBA for ; Sun, 22 Jul 2018 16:34:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 6428D7AA90 for ; Sun, 22 Jul 2018 16:34:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 11558ddb-8dcd-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 11558ddb-8dcd-11e8-904b-1d2e466b3c59; Sun, 22 Jul 2018 16:34:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6MGYCYR010988; Sun, 22 Jul 2018 10:34:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532277252.1344.105.camel@freebsd.org> Subject: Re: ntpd as ntpd user question From: Ian Lepore To: bob prohaska Cc: Pete Wright , FreeBSD Current Date: Sun, 22 Jul 2018 10:34:12 -0600 In-Reply-To: <20180721220925.GA40238@www.zefox.net> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 16:34:23 -0000 On Sat, 2018-07-21 at 15:09 -0700, bob prohaska wrote: > On Sat, Jul 21, 2018 at 12:14:10PM -0600, Ian Lepore wrote: > > > > > > I can't see any way that installkernel would lead to the complaint > > about the ntpd user not existing; that check is tied to the > > installworld target. > > > My mistake. I was sleepy and in a hurry. The error message was in > installworld > and my attempt to adduser ntpd concluded with an error: > Locked     : yes > OK? (yes/no): yes > pw: Bad id 'ntpd': invalid > adduser: ERROR: There was an error adding user (ntpd). > On reboot the old ntpd set the clock and I thought all was well. > > The failure is a little surprising, is ntpd a reserved name? > > The machine is re-running buildworld/installworld from a clean start, > so presumably it'll halt over the same error again. When that > happens,  > what's the simplest way to recover? Mergemaster is a big hammer, > something > less comprehensive might suffice, even manual editing of files.   > > There's minimal customization on the machine, basically /etc/fstab,  > /etc/rc.conf and /etc/passwd. Nothing else of real value, so if I > kill  > it in the attempt it won't be a disaster. > > > Thanks for waking me to my blunder... > > bob prohaska >   The important changes that mergemaster would handle are:   - add ntpd user, id 123   - add ntpd group, id 123   - set ntpd_flags="" in /etc/defaults/rc.conf   - install the new /etc/rc.d/ntpd You can add the user by doing vipw and pasting the ntpd line from /usr/src/etc/master.passwd, IMO easier than doing adduser and answering all the questions. -- Ian From owner-freebsd-current@freebsd.org Sun Jul 22 17:16:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C28C31050C4E for ; Sun, 22 Jul 2018 17:16:07 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 55DDE7C713 for ; Sun, 22 Jul 2018 17:16:07 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1241B1050C4C; Sun, 22 Jul 2018 17:16:07 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DED441050C4B for ; Sun, 22 Jul 2018 17:16:06 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 4E6C17C711; Sun, 22 Jul 2018 17:16:06 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id q10-v6so15644618wrd.4; Sun, 22 Jul 2018 10:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bCiQec/p5KRwj7fnFA2nLkoNjjspaSRswlNOkvKdozg=; b=f4KgF10tv7L8G2PSAK/MWRBlan+lxjHcopkNWq2GTiqk2S2rOF/NlQEW9dX1a5mNM9 5fmAoY464qmodEhs3aR/RvEPG6eoMffpzJpxpf3DQ8pcJECzzJoDmQh7Ms80sdQN/rsl hHP4YIZIrVlSGXiWW8GHQJE4frBlwJnDUBjc3Sn0aTfJ0/ICLLaR3bILbefvaq+Z4lcP LL7e7r1bYePmDNO5M5cjQfV1lGjwIZlEAYDTHxyvCgP1C69MkL6xXX+igp32+diRwvS/ gwMq+ZExVYnuuvVxflWhGPAlYWYiHiizt/vvrbOgAgSTau0FvfWDinsSxcj9XVvEAIPx EuqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=bCiQec/p5KRwj7fnFA2nLkoNjjspaSRswlNOkvKdozg=; b=NDqglsYlh0kV6D3kMBPeuNQ2XaSptaHd2qciJrJbSOZUIlR1aUXeP5Ow4DRZbTlyPk RKaEYKB5VVfm/iIms9Xd2RXUN0ZYw1mgD0VCjwjfrq5L2uti8QEO0k2XdIqxI5mWQ9Uj zNByylvr9YMLJ1FXrAJWdGgqzN2a65KhO6y/TA6zO1YyP4QKWndTIvEUMdPGo2VMiQMF 46uDBtwohe66abUtr7wA6y65mTML4JhcUPiBTxLbww0NGmZHlC4h4VhfLcF5KYL1HL/u Dg0it4yf1+s1ObN2MC3tWqlPd3JHh84SOZ5jef7vZ6J+j0mmYfZBINlqUoZTRDHRsMg2 /qOg== X-Gm-Message-State: AOUpUlHCHdEAfhUZYqaZd/ic2qFje3RF6gUoMuB0Z29I5s135umNEOjr 4f6tXKbEoEiKZZZtWG71MMCN/09/ X-Google-Smtp-Source: AAOMgpePIo/xhBbxwJ5NMyLG5w7iTAnZwDFPTtwic1/pkk1g6DaLgu4CVZyyERtqeDisdAfQPdkWVQ== X-Received: by 2002:adf:ac2d:: with SMTP id v42-v6mr6447376wrc.142.1532279765246; Sun, 22 Jul 2018 10:16:05 -0700 (PDT) Received: from x1c.lwhsu.org (global-5-184.nat-2.net.cam.ac.uk. [131.111.5.184]) by smtp.gmail.com with ESMTPSA id 79-v6sm12331046wmf.5.2018.07.22.10.16.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 10:16:04 -0700 (PDT) Sender: Li-Wen Hsu Date: Sun, 22 Jul 2018 18:16:02 +0100 From: Li-Wen Hsu To: Konstantin Belousov Cc: current@freebsd.org, br@freebsd.org Subject: Re: FreeBSD-head-riscv64-build - Build #9623 (r336573) - Failure Message-ID: <20180722171601.GA25771@x1c.lwhsu.org> References: <941706773.1.1532139392496.JavaMail.jenkins@jenkins.ci.freebsd.org> <20180721231832.GC65334@kib.kiev.ua> <20180722010116.GA13419@freefall.freebsd.org> <20180722154505.GE65334@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20180722154505.GE65334@kib.kiev.ua> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 17:16:08 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 22, 2018 at 18:45:05 +0300, Konstantin Belousov wrote: > On Sun, Jul 22, 2018 at 01:01:16AM +0000, Li-Wen Hsu wrote: > > On Sun, Jul 22, 2018 at 02:18:32 +0300, Konstantin Belousov wrote: > > > On Sat, Jul 21, 2018 at 02:16:17AM +0000, jenkins-admin@FreeBSD.org w= rote: > > > > --- lib/ofed/libmlx5__L --- > > > > In file included from /workspace/src/contrib/ofed/libmlx5/mlx5.h:44= :0, > > > > from /workspace/src/contrib/ofed/libmlx5/buf.c:42: > > > > /workspace/obj/workspace/src/riscv.riscv64/tmp/usr/include/infiniba= nd/udma_barrier.h:108:2: error: #error No architecture specific memory barr= ier defines found! > > > > #error No architecture specific memory barrier defines found! > > > > ^~~~~ > > >=20 > > > The patch below should be enough to fix the build, modulo the syntax > > > errors which I cannot check. The reason is that it seems riscv is not > > > cross-buildable from stable/11 host: > > > --- includes_subdir_include/rpcsvc --- > > > RPCGEN_CPP=3Dcpp\ -target\ riscv64-unknown-freebsd12.0\ --sysroot=3D/= usr/home/konstantinb/build/bsd/DEV/obj/usr/home/konstantinb/build/bsd/DEV/s= rc/riscv.riscv64/tmp\ -B/usr/local rpcgen -C -h -DWANT_NFS3 /usr/home/konst= antinb/build/bsd/DEV/src/include/rpcsvc/klm_prot.x -o klm_prot.h > > > --- key_prot.h --- > > > error: unknown target triple 'riscv64-unknown-freebsd12.0', please us= e -triple or -arch > > > *** [key_prot.h] Error code 1 > > >=20 > > > make[4]: stopped in /usr/home/konstantinb/build/bsd/DEV/src/include/r= pcsvc > > >=20 > > > So if somebody who care about riscv and can build the world could > > > confirm the fix, I will commit it. > > >=20 > > > diff --git a/contrib/ofed/include/udma_barrier.h b/contrib/ofed/inclu= de/udma_barrier.h > > > index 71d264f8dce..6709d4433a7 100644 > > > --- a/contrib/ofed/include/udma_barrier.h > > > +++ b/contrib/ofed/include/udma_barrier.h > > > @@ -104,6 +104,10 @@ > > > #include > > > #include > > > #define udma_to_device_barrier() dmb() > > > +#elif defined(__riscv__) > > > +#include > > > +#include > > > +#define udma_to_device_barrier() fence() > > > #else > > > #error No architecture specific memory barrier defines found! > > > #endif > >=20 > > Thanks for looking into this. Attached patch is slightly modified. > > RISC-V is using __riscv and there are few more atomic macros need to be > > defined. > Well, the arch(7) manpage documents __riscv__. Compilers typically > provide both __XXX__ and __XXX, while FreeBSD traditionally uses > the __XXX__ form. Please check r322168, __riscv__ is replaced by __riscv and __riscv64 is replaced by (__riscv && __riscv_xlen =3D=3D 64). Details are in the commit message. Alghough I grep'd sys/ and there are some __riscv__ still existing: sys/vm/vm_unix.c:72:#if !defined(__aarch64__) && !defined(__riscv__) sys/vm/vm_unix.c:81:#else /* defined(__aarch64__) || defined(__riscv__) */ sys/vm/vm_unix.c:83:#endif /* defined(__aarch64__) || defined(__riscv__) */ I guess those also need changing, as well as arch(7) > With that change, I think that your patch should go in regardless of > the second issue below. Thanks, please commit or approve it. > >=20 > > However this seems not enough, there are some c++ errors which may take > > longer to fix: > >=20 > > In file included from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmac= m/cma.h:43:0, > > from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmac= m/acm.c:42: > > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function '= fastlock_init': > > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:60:2: error: i= nvalid initializer > > atomic_store(&lock->cnt, 0); > > ^ > > In file included from /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmac= m/acm.c:42:0: > > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function '= fastlock_acquire': > > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:68:2: error: o= perand type 'struct *' is incompatible with argument 1 of '__at= omic_fetch_add' > > if (atomic_fetch_add(&lock->cnt, 1) > 0) > > ^~ > > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h: In function '= fastlock_release': > > /usr/home/lwhsu/freebsd-src/contrib/ofed/librdmacm/cma.h:73:2: error: o= perand type 'struct *' is incompatible with argument 1 of '__at= omic_fetch_sub' > > if (atomic_fetch_sub(&lock->cnt, 1) > 1) > > ^~ > > *** [acm.o] Error code 1 > >=20 > > make[6]: stopped in /usr/home/lwhsu/freebsd-src/lib/ofed/librdmacm > I will look at this later, but it seems that linuxkpi is not ported. > I will disable OFED on RISC-V. Thanks, I think this is the right way to go for now. > >=20 > >=20 > > BTW, stable/11 should be fine to cross-build riscv64, this job uses > > 11.2-RELEASE and riscv64-xtoolchain-gcc package, with > > CROSS_TOOLCHAIN=3Driscv64-gcc defined. > >=20 > >=20 > > Best, > > Li-Wen > >=20 > > --=20 > > Li-Wen Hsu > > https://lwhsu.org >=20 > > Index: contrib/ofed/include/udma_barrier.h > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- contrib/ofed/include/udma_barrier.h (revision 336593) > > +++ contrib/ofed/include/udma_barrier.h (working copy) > > @@ -104,6 +104,10 @@ > > #include > > #include > > #define udma_to_device_barrier() dmb() > > +#elif defined(__riscv) > > +#include > > +#include > > +#define udma_to_device_barrier() fence() > > #else > > #error No architecture specific memory barrier defines found! > > #endif > > @@ -140,6 +144,8 @@ > > #define udma_from_device_barrier() mips_sync() > > #elif defined(__arm__) > > #define udma_from_device_barrier() dmb() > > +#elif defined(__riscv) > > +#define udma_from_device_barrier() fence() > > #else > > #error No architecture specific memory barrier defines found! > > #endif > > @@ -208,6 +214,8 @@ > > #define mmio_flush_writes() mips_sync() > > #elif defined(__arm__) > > #define mmio_flush_writes() dmb() > > +#elif defined(__riscv) > > +#define mmio_flush_writes() fence() > > #else > > #error No architecture specific memory barrier defines found! > > #endif >=20 --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEwJe+rporMbugMm8ojXvMfQEv034FAltUu8dfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMw OTdCRUFFOUEyQjMxQkJBMDMyNkYyODhEN0JDQzdEMDEyRkQzN0UACgkQjXvMfQEv 036WmBAA0OxxqHdhAYucJsDcVcACWp2bCshSWZbr3MFTg6YUfJiNp9yH4wyS5BME e/DzVnQpm1CRJ+ohv6dP8Lsrse0VZmhUQ3fQlAUGE10ecFuurT75DyJLHWkTC919 f2Ka3bwHsB0g8f7eiqCjiO4j3+0IGQEdnqmo7AiAFhQXHKfWSOJSE5X5Bbns/C9/ ZJVs5W+jgrtFWwTyfIEuC0U0Kykl4LBa3Qby0HKyesP3ulAEUwN7Pm8QCyGYn7Kk NewDzYe7wy4LAnUoh0qklo+U2aFpde7j2uXWWLhw0nEuTbvGTumhz2A9kFHTgfCv W7YRFGu2gx1ydnzH0YMonDkOiIp5ZdKrko0jvoDiKgvCnDgy3eiPfHtU7eNNP0oV 1MDxF5yh1fZ4zYhFhXwssAgK2cmMdLebMn8C7L659zcgZquLu44TQRJTx6uQwVB/ snPqGoN1vKDHzlzFf5ActYtlVG5UTGOS59w4KMrggM1zS0rrvKkUq7OKgh3Pgsly UePzKnmwgiEHCGTYsiUczUSM2EnNiFhNRK96E0TRILAxti9+XC0XkPZKCxkGUWkW 4j04Lj6p3gw9glrGioc3CDXp/Zidu0eqVz8NmB3chlljZVGprCjlNv9GumT2Rxvj vUNxotkHt95Pon7L/yzO9UbBGACRYq0+7FMvR6CozzJ8N/buqfE= =T5vG -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-current@freebsd.org Sun Jul 22 19:59:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C596310545A8 for ; Sun, 22 Jul 2018 19:59:09 +0000 (UTC) (envelope-from sh+freebsd-current@codevoid.de) Received: from mail.codevoid.de (codevoid.de [176.9.40.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5D27F82562 for ; Sun, 22 Jul 2018 19:59:09 +0000 (UTC) (envelope-from sh+freebsd-current@codevoid.de) Received: from localhost (HSI-KBW-109-193-103-113.hsi7.kabel-badenwuerttemberg.de [109.193.103.113]) by mail.codevoid.de (Postfix) with ESMTPSA id CBFD811AE0 for ; Sun, 22 Jul 2018 21:58:20 +0200 (CEST) Date: Sun, 22 Jul 2018 21:59:00 +0200 From: Stefan Hagen To: freebsd-current@freebsd.org Subject: fatal error: 'immintrin.h' file not found Message-ID: <20180722195900.GA75436@ptrace.hagen.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: first-class Priority: normal X-Editor: VIM - Vi IMproved 8.1 X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-Mailer: Mutt 1.10.0 (2018-05-17) OpenPGP: id=52BE43BA; =?utf-8?B?dXJsPWh0dHBzOi8v?= =?utf-8?B?Y29kZXZvaWQuZGUvP+KYuj1ncGc7?= preference=sign; X-Jabber: sh@codevoid.de User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 19:59:10 -0000 Hello, I think I broke something and I can't figure out what it is. Since a few weeks, I'm not able to build current anymore. make buildkernel, buildworld, toolchain - all abort with the following error: --- lz_encoder.o --- In file included from /usr/src/contrib/xz/src/liblzma/lz/lz_encoder.c:23: /usr/src/contrib/xz/src/liblzma/common/memcmplen.h:19:11: fatal error: 'immintrin.h' file not found # include ^~~~~~~~~~~~~ 1 error generated. Find shows me, that immintrin.h can be found in the following locations: $ find / -name "immintrin.h" /usr/lib/clang/4.0.0/include/immintrin.h /usr/lib/clang/3.8.0/include/immintrin.h /usr/lib/clang/5.0.0/include/immintrin.h /usr/lib/clang/6.0.0/include/immintrin.h /usr/lib/clang/5.0.1/include/immintrin.h /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/clang/6.0.1/include/immintrin.h /usr/obj/usr/src/tmp/usr/lib/clang/5.0.0/include/immintrin.h /usr/src/contrib/llvm/tools/clang/lib/Headers/immintrin.h /usr/local/llvm60/lib/clang/6.0.1/include/immintrin.h /compat/linux/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/immintrin.h I'm usually compiling with meta-mode and ccache. I've turned off both and still encounter the same error. How can I figure out what is missing here? Best Regards, Stefan -- Stefan Hagen Mail: sh@codevoid.de | encryption key in header. gopher://codevoid.de | https://codevoid.de From owner-freebsd-current@freebsd.org Sun Jul 22 20:37:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 630A3102A2DF for ; Sun, 22 Jul 2018 20:37:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBEF483BE5 for ; Sun, 22 Jul 2018 20:37:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ADB30369FC; Sun, 22 Jul 2018 22:37:26 +0200 (CEST) From: Dimitry Andric Message-Id: <82B3EB35-676F-42B6-9577-3BAF43F2719F@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3EA7F67B-718E-49EC-9DC9-366171FE0465"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: fatal error: 'immintrin.h' file not found Date: Sun, 22 Jul 2018 22:37:20 +0200 In-Reply-To: <20180722195900.GA75436@ptrace.hagen.corp> Cc: freebsd-current@freebsd.org To: Stefan Hagen References: <20180722195900.GA75436@ptrace.hagen.corp> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 20:37:35 -0000 --Apple-Mail=_3EA7F67B-718E-49EC-9DC9-366171FE0465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Jul 2018, at 21:59, Stefan Hagen = wrote: >=20 > I think I broke something and I can't figure out what it is. Since a = few > weeks, I'm not able to build current anymore. >=20 > make buildkernel, buildworld, toolchain - all abort with the following > error: >=20 > --- lz_encoder.o --- > In file included from = /usr/src/contrib/xz/src/liblzma/lz/lz_encoder.c:23: > /usr/src/contrib/xz/src/liblzma/common/memcmplen.h:19:11: fatal error: = 'immintrin.h' file not found > # include > ^~~~~~~~~~~~~ > 1 error generated. >=20 > Find shows me, that immintrin.h can be found in the following = locations: >=20 > $ find / -name "immintrin.h" > /usr/lib/clang/4.0.0/include/immintrin.h > /usr/lib/clang/3.8.0/include/immintrin.h > /usr/lib/clang/5.0.0/include/immintrin.h > /usr/lib/clang/6.0.0/include/immintrin.h > /usr/lib/clang/5.0.1/include/immintrin.h What does "cc -v" show? If it is clang 6.0.1, you are missing the 6.0.1 intrinsics headers, located in /usr/lib/clang/6.0.1/include. As a quick hack, you can try copying the /usr/lib/clang/6.0.0 headers there, or attempt to run "make install" in /usr/src/lib/clang/headers. -Dimitry --Apple-Mail=_3EA7F67B-718E-49EC-9DC9-366171FE0465 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----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW1TrAAAKCRCwXqMKLiCW ow7eAJ0Q2eRTyW8J6DCH4MBBcfnThKiw1QCgz/IoJ2gt6KhcRxjo+eCR6iQtAv4= =SniT -----END PGP SIGNATURE----- --Apple-Mail=_3EA7F67B-718E-49EC-9DC9-366171FE0465-- From owner-freebsd-current@freebsd.org Sun Jul 22 21:27:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B9FD102E7A6 for ; Sun, 22 Jul 2018 21:27:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 12A1586033 for ; Sun, 22 Jul 2018 21:27:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C2795102E7A5; Sun, 22 Jul 2018 21:27:07 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C819102E7A4 for ; Sun, 22 Jul 2018 21:27:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1ABB786030; Sun, 22 Jul 2018 21:27:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w6MLQtWL040915 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Jul 2018 00:26:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w6MLQtWL040915 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w6MLQtO6040914; Mon, 23 Jul 2018 00:26:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jul 2018 00:26:55 +0300 From: Konstantin Belousov To: Li-Wen Hsu Cc: current@freebsd.org, br@freebsd.org Subject: Re: FreeBSD-head-riscv64-build - Build #9623 (r336573) - Failure Message-ID: <20180722212655.GF65334@kib.kiev.ua> References: <941706773.1.1532139392496.JavaMail.jenkins@jenkins.ci.freebsd.org> <20180721231832.GC65334@kib.kiev.ua> <20180722010116.GA13419@freefall.freebsd.org> <20180722154505.GE65334@kib.kiev.ua> <20180722171601.GA25771@x1c.lwhsu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180722171601.GA25771@x1c.lwhsu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 21:27:08 -0000 On Sun, Jul 22, 2018 at 06:16:02PM +0100, Li-Wen Hsu wrote: > On Sun, Jul 22, 2018 at 18:45:05 +0300, Konstantin Belousov wrote: > > On Sun, Jul 22, 2018 at 01:01:16AM +0000, Li-Wen Hsu wrote: > > > On Sun, Jul 22, 2018 at 02:18:32 +0300, Konstantin Belousov wrote: > > > > On Sat, Jul 21, 2018 at 02:16:17AM +0000, jenkins-admin@FreeBSD.org wrote: > > > > > --- lib/ofed/libmlx5__L --- > > > > > In file included from /workspace/src/contrib/ofed/libmlx5/mlx5.h:44:0, > > > > > from /workspace/src/contrib/ofed/libmlx5/buf.c:42: > > > > > /workspace/obj/workspace/src/riscv.riscv64/tmp/usr/include/infiniband/udma_barrier.h:108:2: error: #error No architecture specific memory barrier defines found! > > > > > #error No architecture specific memory barrier defines found! > > > > > ^~~~~ > > > > > > > > The patch below should be enough to fix the build, modulo the syntax > > > > errors which I cannot check. The reason is that it seems riscv is not > > > > cross-buildable from stable/11 host: > > > > --- includes_subdir_include/rpcsvc --- > > > > RPCGEN_CPP=cpp\ -target\ riscv64-unknown-freebsd12.0\ --sysroot=/usr/home/konstantinb/build/bsd/DEV/obj/usr/home/konstantinb/build/bsd/DEV/src/riscv.riscv64/tmp\ -B/usr/local rpcgen -C -h -DWANT_NFS3 /usr/home/konstantinb/build/bsd/DEV/src/include/rpcsvc/klm_prot.x -o klm_prot.h > > > > --- key_prot.h --- > > > > error: unknown target triple 'riscv64-unknown-freebsd12.0', please use -triple or -arch > > > > *** [key_prot.h] Error code 1 > > > > > > > > make[4]: stopped in /usr/home/konstantinb/build/bsd/DEV/src/include/rpcsvc > > > > > > > > So if somebody who care about riscv and can build the world could > > > > confirm the fix, I will commit it. > > > > > > > > diff --git a/contrib/ofed/include/udma_barrier.h b/contrib/ofed/include/udma_barrier.h > > > > index 71d264f8dce..6709d4433a7 100644 > > > > --- a/contrib/ofed/include/udma_barrier.h > > > > +++ b/contrib/ofed/include/udma_barrier.h > > > > @@ -104,6 +104,10 @@ > > > > #include > > > > #include > > > > #define udma_to_device_barrier() dmb() > > > > +#elif defined(__riscv__) > > > > +#include > > > > +#include > > > > +#define udma_to_device_barrier() fence() > > > > #else > > > > #error No architecture specific memory barrier defines found! > > > > #endif > > > > > > Thanks for looking into this. Attached patch is slightly modified. > > > RISC-V is using __riscv and there are few more atomic macros need to be > > > defined. > > Well, the arch(7) manpage documents __riscv__. Compilers typically > > provide both __XXX__ and __XXX, while FreeBSD traditionally uses > > the __XXX__ form. > > Please check r322168, __riscv__ is replaced by __riscv and > __riscv64 is replaced by (__riscv && __riscv_xlen == 64). Details are > in the commit message. > > Alghough I grep'd sys/ and there are some __riscv__ still existing: > > sys/vm/vm_unix.c:72:#if !defined(__aarch64__) && !defined(__riscv__) > sys/vm/vm_unix.c:81:#else /* defined(__aarch64__) || defined(__riscv__) */ > sys/vm/vm_unix.c:83:#endif /* defined(__aarch64__) || defined(__riscv__) */ > > I guess those also need changing, as well as arch(7) > > > > With that change, I think that your patch should go in regardless of > > the second issue below. > > Thanks, please commit or approve it. Why do you need an approval ? I already said that your patch looks fine. From owner-freebsd-current@freebsd.org Sun Jul 22 21:48:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 555FC102F054 for ; Sun, 22 Jul 2018 21:48:54 +0000 (UTC) (envelope-from sh+freebsd-current@codevoid.de) Received: from mail.codevoid.de (codevoid.de [176.9.40.102]) by mx1.freebsd.org (Postfix) with ESMTP id DE15486A08; Sun, 22 Jul 2018 21:48:53 +0000 (UTC) (envelope-from sh+freebsd-current@codevoid.de) Received: from localhost (HSI-KBW-109-193-103-113.hsi7.kabel-badenwuerttemberg.de [109.193.103.113]) by mail.codevoid.de (Postfix) with ESMTPSA id 1197711B7E; Sun, 22 Jul 2018 23:48:12 +0200 (CEST) Date: Sun, 22 Jul 2018 23:48:52 +0200 From: Stefan Hagen To: Dimitry Andric Cc: freebsd-current@freebsd.org Subject: Re: fatal error: 'immintrin.h' file not found Message-ID: <20180722214852.GA76585@ptrace.hagen.corp> References: <20180722195900.GA75436@ptrace.hagen.corp> <82B3EB35-676F-42B6-9577-3BAF43F2719F@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <82B3EB35-676F-42B6-9577-3BAF43F2719F@FreeBSD.org> Precedence: first-class Priority: normal X-Editor: VIM - Vi IMproved 8.1 X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-Mailer: Mutt 1.10.0 (2018-05-17) X-PGP-Fingerprint: CBD3 C468 64B4 6517 E8FB B90F B6BC 2EC5 52BE 43BA OpenPGP: id=52BE43BA; =?utf-8?B?dXJsPWh0dHBzOi8v?= =?utf-8?B?Y29kZXZvaWQuZGUvP+KYuj1ncGc7?= preference=sign; X-Jabber: sh@codevoid.de User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 21:48:54 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dimitry, Dimitry Andric wrote: > Stefan Hagen wrote: >> --- lz_encoder.o --- >> In file included from /usr/src/contrib/xz/src/liblzma/lz/lz_encoder.c:23: >> /usr/src/contrib/xz/src/liblzma/common/memcmplen.h:19:11: fatal error: '= immintrin.h' file not found >> # include >> ^~~~~~~~~~~~~ >> 1 error generated. >> >> Find shows me, that immintrin.h can be found in the following locations: >> >> $ find / -name "immintrin.h" >> /usr/lib/clang/4.0.0/include/immintrin.h >> /usr/lib/clang/3.8.0/include/immintrin.h >> /usr/lib/clang/5.0.0/include/immintrin.h >> /usr/lib/clang/6.0.0/include/immintrin.h >> /usr/lib/clang/5.0.1/include/immintrin.h > > What does "cc -v" show? If it is clang 6.0.1, you are missing the 6.0.1 > intrinsics headers, located in /usr/lib/clang/6.0.1/include. As a quick > hack, you can try copying the /usr/lib/clang/6.0.0 headers there, or > attempt to run "make install" in /usr/src/lib/clang/headers. $ cc -v FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM = 6.0.1) The following fixed it for me: mkdir -p /usr/lib/clang/6.0.1/include/ cd /usr/src/lib/clang/headers && make install Shouldn't these headers be included in the llvm60-6.0.1_1 package? Or are they part of the base system? I just wonder why I never had to install them before. Kind Regards && thank you, Stefan --=20 Stefan Hagen Mail: sh@codevoid.de | encryption key in header. gopher://codevoid.de | https://codevoid.de --/04w6evG8XlLl3ft Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJwBAABCgBaFiEEy9PEaGS0ZRfo+7kPtrwuxVK+Q7oFAltU+8M8FIAAAAAAFQAe cGthLWFkZHJlc3NAZ251cGcub3Jnc2grZnJlZWJzZC1jdXJyZW50QGNvZGV2b2lk LmRlAAoJELa8LsVSvkO6wzUP/jZEvHyGkDYnlMvQx6Au/NzN30N8w+VBt9EIFJdq Jmu3mN7WD02GAQiD7bkniAVw4XvuYBMrh/qp4EbHBsZaDNZgTU19y2edNS7DjlUr Q+mi6jWr0bCHyyQ5W9ZH27OR6Mwq7IVze0mG5uY03/PWVftkOlV77aDRkc6mU4P7 SSIZBDndAB7dqBlYnw/hm9C7hFB1Jo9qsEY6sqSfzYs2jhp6j8JdGlib2J1rC7Gd 6Ow15bNLaBgnGaCnHZ+3rkaw7mqLFEfCjJQWT/u3XzsuDcypW0FF614QIQcqaeNq 48Ng93AeXth7ZRCL4vHnJviFQEOKo5BSg2m29NnzrT8pKCkysoNM+sabC2eO+1EW wsAaaXD/joHdk3rXuRoLCV0Z2kHxU405j/fjIQf8ytLbdB4tSB4Y6yDU7RlylKQN uISG4vupOxzvfawuylDC/BFqY5iYCsieIQTu9mnW84FoQ/NXHtEnMezbu3SeS5g2 6YRKkvGGZ1bUfQwjIuryYSL2AdXxJL5IMaOFKerdwQsBDGulo4NE3B79yMS/ZQpp rk9knsp6haOCXNVmPMfpcmGWYPQkQbxGRgANvTdvi1qROuFW6erJFr5O11JmAdxl ts6t7dY8wz37TnYzOkBYlFeaf0DCc3ZmhMpDq+eR4qMMgUwIB2ADNEXV+TohHZqf 1Int =n+G2 -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@freebsd.org Sun Jul 22 22:04:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E89A4102F884 for ; Sun, 22 Jul 2018 22:04:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7F260871C4 for ; Sun, 22 Jul 2018 22:04:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3FC4C102F883; Sun, 22 Jul 2018 22:04:21 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E201102F882 for ; Sun, 22 Jul 2018 22:04:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93D65871C1; Sun, 22 Jul 2018 22:04:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w6MM4DrX048895 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Jul 2018 01:04:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w6MM4DrX048895 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w6MM4DF3048894; Mon, 23 Jul 2018 01:04:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jul 2018 01:04:13 +0300 From: Konstantin Belousov To: Li-Wen Hsu Cc: current@freebsd.org, Ruslan Bukin Subject: Re: FreeBSD-head-riscv64-build - Build #9623 (r336573) - Failure Message-ID: <20180722220413.GG65334@kib.kiev.ua> References: <941706773.1.1532139392496.JavaMail.jenkins@jenkins.ci.freebsd.org> <20180721231832.GC65334@kib.kiev.ua> <20180722010116.GA13419@freefall.freebsd.org> <20180722154505.GE65334@kib.kiev.ua> <20180722171601.GA25771@x1c.lwhsu.org> <20180722212655.GF65334@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 22:04:22 -0000 On Sun, Jul 22, 2018 at 10:39:08PM +0100, Li-Wen Hsu wrote: > On Sun, Jul 22, 2018 at 10:27 PM Konstantin Belousov > wrote: > > > > On Sun, Jul 22, 2018 at 06:16:02PM +0100, Li-Wen Hsu wrote: > > > On Sun, Jul 22, 2018 at 18:45:05 +0300, Konstantin Belousov wrote: > > > > On Sun, Jul 22, 2018 at 01:01:16AM +0000, Li-Wen Hsu wrote: > > > > Well, the arch(7) manpage documents __riscv__. Compilers typically > > > > provide both __XXX__ and __XXX, while FreeBSD traditionally uses > > > > the __XXX__ form. > > > > > > Please check r322168, __riscv__ is replaced by __riscv and > > > __riscv64 is replaced by (__riscv && __riscv_xlen == 64). Details are > > > in the commit message. > > > > > > Alghough I grep'd sys/ and there are some __riscv__ still existing: > > > > > > sys/vm/vm_unix.c:72:#if !defined(__aarch64__) && !defined(__riscv__) > > > sys/vm/vm_unix.c:81:#else /* defined(__aarch64__) || defined(__riscv__) */ > > > sys/vm/vm_unix.c:83:#endif /* defined(__aarch64__) || defined(__riscv__) */ > > > > > > I guess those also need changing, as well as arch(7) > > > > > > > > > > With that change, I think that your patch should go in regardless of > > > > the second issue below. > > > > > > Thanks, please commit or approve it. > > Why do you need an approval ? I already said that your patch looks fine. > > Oh, I did not realize that means a green light. Also I am not sure > about your opinion of __riscv and __riscv__. Does my original patch > look OK to you? The change to __riscv looks strange. At least arch(7) should be updated, but this also contradicts the usual syntax. Anyway, I do not have an opinion there, perhaps use __riscv since this apparently is what Ruslan wants to use. From owner-freebsd-current@freebsd.org Sun Jul 22 22:33:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 399F1103139E for ; Sun, 22 Jul 2018 22:33:39 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C62B78877A for ; Sun, 22 Jul 2018 22:33:38 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7FD961031396; Sun, 22 Jul 2018 22:33:38 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B9AE1031391 for ; Sun, 22 Jul 2018 22:33:38 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) (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 EE57688778; Sun, 22 Jul 2018 22:33:37 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wr1-f68.google.com with SMTP id c13-v6so16065316wrt.1; Sun, 22 Jul 2018 15:33:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qTR99K/2LcK6bAeeoPVOCA6IUqXtnUXqkcduU3Cq8Pc=; b=RA/gCApEJLVTMwj2vxxQ6wvWiOyJAqmN4sFE//WhMiQgIJZi5nmuzTzR2wrIBbOj+t Ocx/Kj36gsTFS7vLEs2beAduhf9oyePYzg/OU2RsYGZsgUiAthOpRNVuu/Ar0aF5jZc5 A+ZuLJs9DQh0vBMWqMMk7oMRHHO/U9zpVSiCK5vOwtG10fOeIxicatJLKQhETjlFEkh4 Ct1eCzkZUzXtqnNEKW7SRldmt4tCuyXg4VdRmtQevqRNh/GOooQnXronG7/ExmC53JU1 3Azym3FWKoa5eglHv7INw2ygnAPtmLZRVeYuu9t+JOb+rwR90h6qQGFtPbGVzetmmqCr Ud9A== X-Gm-Message-State: AOUpUlGeBweKrVe9hM7e5BaDtHiZDedJwRnwUBq7zNEIym61adAOPN6H BytVJYakrMTUyu+Qcn+36FfGOySeYA+dH3QruhcK2w== X-Google-Smtp-Source: AAOMgpfX/1TzdtligvXz/ddZ4gwLPsvqlTb+6Hum9Q6hZL8oNyfFJsZTfYHde88mxrn5KYfteO108aYSO5xOdPw5mms= X-Received: by 2002:adf:e190:: with SMTP id k16-v6mr6816863wri.36.1532295560296; Sun, 22 Jul 2018 14:39:20 -0700 (PDT) MIME-Version: 1.0 References: <941706773.1.1532139392496.JavaMail.jenkins@jenkins.ci.freebsd.org> <20180721231832.GC65334@kib.kiev.ua> <20180722010116.GA13419@freefall.freebsd.org> <20180722154505.GE65334@kib.kiev.ua> <20180722171601.GA25771@x1c.lwhsu.org> <20180722212655.GF65334@kib.kiev.ua> In-Reply-To: <20180722212655.GF65334@kib.kiev.ua> From: Li-Wen Hsu Date: Sun, 22 Jul 2018 22:39:08 +0100 Message-ID: Subject: Re: FreeBSD-head-riscv64-build - Build #9623 (r336573) - Failure To: Konstantin Belousov Cc: current@freebsd.org, Ruslan Bukin Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 22:33:39 -0000 On Sun, Jul 22, 2018 at 10:27 PM Konstantin Belousov wrote: > > On Sun, Jul 22, 2018 at 06:16:02PM +0100, Li-Wen Hsu wrote: > > On Sun, Jul 22, 2018 at 18:45:05 +0300, Konstantin Belousov wrote: > > > On Sun, Jul 22, 2018 at 01:01:16AM +0000, Li-Wen Hsu wrote: > > > Well, the arch(7) manpage documents __riscv__. Compilers typically > > > provide both __XXX__ and __XXX, while FreeBSD traditionally uses > > > the __XXX__ form. > > > > Please check r322168, __riscv__ is replaced by __riscv and > > __riscv64 is replaced by (__riscv && __riscv_xlen == 64). Details are > > in the commit message. > > > > Alghough I grep'd sys/ and there are some __riscv__ still existing: > > > > sys/vm/vm_unix.c:72:#if !defined(__aarch64__) && !defined(__riscv__) > > sys/vm/vm_unix.c:81:#else /* defined(__aarch64__) || defined(__riscv__) */ > > sys/vm/vm_unix.c:83:#endif /* defined(__aarch64__) || defined(__riscv__) */ > > > > I guess those also need changing, as well as arch(7) > > > > > > > With that change, I think that your patch should go in regardless of > > > the second issue below. > > > > Thanks, please commit or approve it. > Why do you need an approval ? I already said that your patch looks fine. Oh, I did not realize that means a green light. Also I am not sure about your opinion of __riscv and __riscv__. Does my original patch look OK to you? -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Sun Jul 22 23:08:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82071103223D for ; Sun, 22 Jul 2018 23:08:45 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFE289909 for ; Sun, 22 Jul 2018 23:08:45 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id CF842103223B; Sun, 22 Jul 2018 23:08:44 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9B43103223A for ; Sun, 22 Jul 2018 23:08:44 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 2E48B89906; Sun, 22 Jul 2018 23:08:44 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wr1-f43.google.com with SMTP id e7-v6so16082549wrs.9; Sun, 22 Jul 2018 16:08:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mJidVVzs6LxAlIktb3CqVCQilS4IFTivdTnlg8y9mSs=; b=Dyc50wD9Rwyu5YVA3Ldk8KLBNXMfflS/Gn0l5EvEsc1qs4KHg75AatZFZANxvm2qKY t1fuTyGUibra0Sxev48a0Dw/ti7Nj1bXnMmUcnA7ekn+uisyOvtIeDM86TYULX6z3cWk AJzQ7EFcoiW6v7pahXxCD95Sb22A0FEhSwlR8x5/5nOP/itwe35PzKpj7YBctJVkHNo8 smt4N40LxqOZWUuGNmEyBc0i4fhJSe3eZ1LThqUdib+/l4JtFzByukJyVoZkHg9eyjrB Er2dUB8LFlBpfmicrSrg6deXs2qP/R5bFZ9iy2o7L2pKfIGlYgG+yRSvpHjw2a8f+/aq jhaQ== X-Gm-Message-State: AOUpUlG0XWiNiWTX2SkmyTF+6tqUb8TYmmRzo+FS2hS2wasz9D5P9VkE 3WeHjq4492g54KxYbtIW6j2jemWpOkT/LJGx7qY= X-Google-Smtp-Source: AAOMgpdBiMBHgPMvamz+8q93t/hZCaWyfxgjcTgbcJ0hVgjJ6NxCvwgks8NlW1OKUp2RN520YQp2wbGY3AFBj1RU8Zo= X-Received: by 2002:adf:ed41:: with SMTP id u1-v6mr6608330wro.262.1532300507826; Sun, 22 Jul 2018 16:01:47 -0700 (PDT) MIME-Version: 1.0 References: <941706773.1.1532139392496.JavaMail.jenkins@jenkins.ci.freebsd.org> <20180721231832.GC65334@kib.kiev.ua> <20180722010116.GA13419@freefall.freebsd.org> <20180722154505.GE65334@kib.kiev.ua> <20180722171601.GA25771@x1c.lwhsu.org> <20180722212655.GF65334@kib.kiev.ua> <20180722220413.GG65334@kib.kiev.ua> In-Reply-To: <20180722220413.GG65334@kib.kiev.ua> From: Li-Wen Hsu Date: Mon, 23 Jul 2018 00:01:35 +0100 Message-ID: Subject: Re: FreeBSD-head-riscv64-build - Build #9623 (r336573) - Failure To: Konstantin Belousov Cc: current@freebsd.org, Ruslan Bukin Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 23:08:45 -0000 On Sun, Jul 22, 2018 at 11:04 PM Konstantin Belousov wrote: > The change to __riscv looks strange. At least arch(7) should be updated, > but this also contradicts the usual syntax. Just found that arch(7) was also updated in r322168. > Anyway, I do not have an opinion there, perhaps use __riscv since this > apparently is what Ruslan wants to use. I committed the original patch as r336620. -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Mon Jul 23 04:55:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58273103E1BC for ; Mon, 23 Jul 2018 04:55:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6BFC935F7 for ; Mon, 23 Jul 2018 04:55:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6N4ttNM045696 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 22 Jul 2018 21:55:56 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6N4tqs0045695; Sun, 22 Jul 2018 21:55:52 -0700 (PDT) (envelope-from fbsd) Date: Sun, 22 Jul 2018 21:55:52 -0700 From: bob prohaska To: "Herbert J. Skuhra" Cc: freebsd-current@freebsd.org, bob prohaska Subject: Re: ntpd as ntpd user question Message-ID: <20180723045552.GA44941@www.zefox.net> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 04:55:46 -0000 On Sun, Jul 22, 2018 at 01:49:41AM +0200, Herbert J. Skuhra wrote: > On Sat, Jul 21, 2018 at 03:09:26PM -0700, bob prohaska wrote: > > The failure is a little surprising, is ntpd a reserved name? > > Why? You obviously entered the string "ntpd" instead of an integer when > asked for the uid!? > Sigh...you're right. Must have been sleepier than I thought. > > The machine is re-running buildworld/installworld from a clean start, > > so presumably it'll halt over the same error again. When that happens, > > what's the simplest way to recover? Mergemaster is a big hammer, something > > less comprehensive might suffice, even manual editing of files. > > In this case 'mergemaster -p' is enough. > An example or two on the use of mergemaster might be a considerable help. There's something very basic that I don't understand. What is the correct response to the prompts for this simple case? The output displayed is said to be differences, so the "temporary" file's nature isn't self-evident. It looks as if the most obvious option is m, followed by eb, but that leaves me editing by hand, which is what I thought mergemaster was supposed to avoid. Thanks for reading, and apologies for being dense. bob prohaska From owner-freebsd-current@freebsd.org Mon Jul 23 05:47:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E57E103F8A1 for ; Mon, 23 Jul 2018 05:47:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CC7794E76 for ; Mon, 23 Jul 2018 05:47:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 07FD136A46; Mon, 23 Jul 2018 07:47:47 +0200 (CEST) From: Dimitry Andric Message-Id: <3D7D1A21-5D35-4246-83E4-1D64FBB8716D@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F7E2DCDA-A02F-46F8-AD16-CEF5D20DE67F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: fatal error: 'immintrin.h' file not found Date: Mon, 23 Jul 2018 07:47:36 +0200 In-Reply-To: <20180722214852.GA76585@ptrace.hagen.corp> Cc: freebsd-current@freebsd.org To: Stefan Hagen References: <20180722195900.GA75436@ptrace.hagen.corp> <82B3EB35-676F-42B6-9577-3BAF43F2719F@FreeBSD.org> <20180722214852.GA76585@ptrace.hagen.corp> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 05:47:49 -0000 --Apple-Mail=_F7E2DCDA-A02F-46F8-AD16-CEF5D20DE67F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Jul 2018, at 23:48, Stefan Hagen = wrote >=20 > Dimitry Andric wrote: >> Stefan Hagen wrote: >>> --- lz_encoder.o --- >>> In file included from = /usr/src/contrib/xz/src/liblzma/lz/lz_encoder.c:23: >>> /usr/src/contrib/xz/src/liblzma/common/memcmplen.h:19:11: fatal = error: 'immintrin.h' file not found >>> # include >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>>=20 >>> Find shows me, that immintrin.h can be found in the following = locations: >>>=20 >>> $ find / -name "immintrin.h" >>> /usr/lib/clang/4.0.0/include/immintrin.h >>> /usr/lib/clang/3.8.0/include/immintrin.h >>> /usr/lib/clang/5.0.0/include/immintrin.h >>> /usr/lib/clang/6.0.0/include/immintrin.h >>> /usr/lib/clang/5.0.1/include/immintrin.h >>=20 >> What does "cc -v" show? If it is clang 6.0.1, you are missing the = 6.0.1 >> intrinsics headers, located in /usr/lib/clang/6.0.1/include. As a = quick >> hack, you can try copying the /usr/lib/clang/6.0.0 headers there, or >> attempt to run "make install" in /usr/src/lib/clang/headers. >=20 > $ cc -v > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) >=20 > The following fixed it for me: >=20 > mkdir -p /usr/lib/clang/6.0.1/include/ > cd /usr/src/lib/clang/headers && make install >=20 > Shouldn't these headers be included in the llvm60-6.0.1_1 package? > Or are they part of the base system? They are part of the base system, but the port will install them in a similar location, under /usr/local. > I just wonder why I never had to install them before. That is the real mystery: during a normal installworld, these headers get installed. Maybe you ran an installworld using WITHOUT_CLANG, and then attempted to build a new one? Btw, you still have the /usr/lib/clang/3.8.0 through 6.0.0 directories, so maybe it is time to run "make delete-old" at some point. :) -Dimitry --Apple-Mail=_F7E2DCDA-A02F-46F8-AD16-CEF5D20DE67F 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----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW1Vr+AAKCRCwXqMKLiCW o62pAJ4+e1jnOw7uP4QsKMv19x/maCCjdgCeMUI0K/kg6DPz8BBlqqSfIZ8XGDA= =efLQ -----END PGP SIGNATURE----- --Apple-Mail=_F7E2DCDA-A02F-46F8-AD16-CEF5D20DE67F-- From owner-freebsd-current@freebsd.org Mon Jul 23 07:33:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E2151041E16 for ; Mon, 23 Jul 2018 07:33:00 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DD47700D1 for ; Mon, 23 Jul 2018 07:32:59 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpPg1-1gAoGX06AH-00fDuf; Mon, 23 Jul 2018 09:27:40 +0200 Date: Mon, 23 Jul 2018 09:27:38 +0200 From: "O. Hartmann" To: Toomas Soome Cc: freebsd-current Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:FwH7604Bdkg7+LeRZyqI5sZPYvPdQ9n93QN75WS1RBxIrmgevl1 BePDmIC+tZbCn3jLX1idzhf0lKUlmFxjzsBDJCI89yc9bMjgLiCk5hu7AmfEnDmA0RyVnwD Cl2902cx7XkVIMK8LA5sORR7pOtv8d/K/lmWNV3LqwLTIU5dTeZyzwm3mNn6K67stRa87B9 u7ZzCTAyCRKoXV+qW447Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:5Hj+822oEuY=:+K0A32isDgl1R7kzVG8GuM TPFfXEb0wZyjiohdO63FToKWQexl30onI7h32LObfikYgHdUYdQMB/uWiU0SQPPjDYPOPGTP7 23KjMhk11HFndCrzyHzImpsllzP1Z2fiP8OJHXqaEtJfkWTQ5+sHt1BvUlu3+R4Tf3/jiqfJJ PFPVdTwVZcrYPoV+Uz5OQinlrvfTkcvyGPkuQifWb/9FNM2OnRmQUrHWICHXC1oILSqZ46ypt 6ahusAZScF5MWFL/xdW8Bd7+vRsTUc7wU/5RJWtPIGwep7p+zjdmJzZxQhTqg9vtSDX0H97pM ztaeJL+CJixEVaLHal7dyr0Aj+/nUPBnsem9io/yVaRhTmUfKtA0fQutOIu36sGV6A9fbGp9z Ddj44vKO+gh0T3o9My8uJWTDtdpmBGTZ/jEc+On5yUykoF2UzSkCL+XKMm4BdjiCPW0nNfg5a 89zb7mMgaU4hCFA0LcaUdgFK3pEYGfIU0R4FCmKfthaElZdQHiDYTIfNMius1YPWBh7C4iDhk UwxkXjjbTaEZEBgFWVP4hb/LYiMAc4ilQZtzqcnMgFxjV3eUsyekf7cmXnIL1ZPXw9UK11JfD BNZfJ9tnF3rUSfFbaNYGu3zlHMnA8K50UOk1WtcT4nM1008vfNRK7lFpEsXfOd32n6VctdtbQ 4tyUsrWyVpnl5aMXT1hPe5IDhWIEgs3jMa1CmYSbvtPw0CyXZIhh1Rm/gSMeiRsce2bWVkc/A 7sOIrCxPvuDsfZsMDVCFAwUUqusE9emvJrDZL3TYP8rAWerENHZmrvZhTCEQ62N8o5waccxsu dMOxZo8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 07:33:00 -0000 On Fri, 13 Jul 2018 18:44:23 +0300 Toomas Soome wrote: > > On 13 Jul 2018, at 17:44, O. Hartmann wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Am Fri, 13 Jul 2018 14:26:51 +0300 > > Toomas Soome > schrieb: > > > >>> On 13 Jul 2018, at 14:00, O. Hartmann wrote: > >>> > >>> The problem is some kind of weird. I face UEFI boot problems on GPT drives > >>> where the first partition begins at block 40 of the hdd/ssd. > >>> > >>> I have two host in private use based on an > >>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket > >>> LGA1155). Both boards are equipted with the lates official available AMI > >>> firmware revision, dating to 2013. This is for the Z77-Pro4-M revision > >>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both > >>> boards a BETA revision for the Spectre/Meltdown mitigation is available, > >>> but I didn't test that. But please read. > >>> > >>> The third box I realised this problem is a brand new Fujitsu Esprimo > >>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date > >>> 05/25/2018 (or 20180525). > >>> > >>> Installing on any kind of HDD or SSD manually or via bsdinstall the OS > >>> using UEFI-only boot method on a GPT partitioned device fails. The ASRock > >>> boards jump immediately into the firmware, the Fujitsu offers some kind > >>> of CPU/Memory/HDD test facility. > >>> > >>> If on both type of vendor/boards CSM is disabled and UEFI boot only is > >>> implied, the MBR partitioned FreeBSD installation USB flash device does > >>> boot in UEFI! I guess I can assume this when the well known clumsy 80x25 > >>> char console suddenly gets bright and shiny with a much higher resoltion > >>> as long the GPU supports EFI GOP. Looking with gpart at the USB flash > >>> drives reveals that the EFI partition starts at block 1 of the device and > >>> the device has a MBR layout. I haven't found a way to force the GPT > >>> scheme, when initialised via gpart, to let the partitions start at block > >>> 1. This might be a naiv thinking, so please be patient with me. > >>> > >>> I do not know whether this is a well-known issue. On the ASRock boards, I > >>> tried years ago some LinuxRed Hat and Suse with UEFI and that worked - > >>> FreeBSD not. I gave up on that that time. Now, having the very same > >>> issues with a new Fujitsu system, leaves me with the impression that > >>> FreeBSD's UEFI implementation might have problems I'm not aware of. > >>> > >>> Can someone shed some light onto this? > >>> > >> > >> The first thing to check is if the secure boot is disabled. We do not > >> support secure boot at all at this time. > > > > Secure boot is in every scenario disabled! > > > >> > >> If you have efi or bios version running - you can check from either > >> console variable value (it can have efi or vidconsole or comconsole) or > >> better yet, see if efi-version is set (show efi-version) - if efi-version > >> is not set, it is BIOS loader running. Another indirect way is to see > >> lsdev -v, with device paths present, it is uefi:) > > > > What are you talking about? > > What is the point of entry - running system, loader? > > > > sysct machdep.bootmethod: BIOS > > > > This makes me quite sure that the system has booted via BIOS - as I'm sure > > since I've checked that many times. UEFI doesn't work on those systems with > > FreeBSD. I'm not sure antmore, but I tried also Windows 7 on those > > mainboards booting via UEFI - and I might recall that they failed also. I > > also recall that there were issues with earlier UEFI versions regarding > > booting only Windows 8/8.1 - and nothing else, but the fact that Linux > > worked confuses me a bit. > > > > If this ASRock crap (never ever again this brand!) doesn't work at all - > > who cares, I intend to purchase new server grade hardware. But the more > > puzzling issue is with the Fujitsu, which I consider serious and from the > > behaviour the Fujitsu failure looks exactly like the ASRock - Windows 7 > > works, RedHat 7.5 works (I assume I can trust the Firmware settings when I > > disable CSM support, that the Firmware will only EFI/UEFI capable loader? > > Or is there a ghosty override somwhere to be expected?). Also on ASRock > > disabling CSM should ensure not booting a dual-bootstrap-capable system. > > This said, on the recent Fujitsu, it seems to boil down to a FreeBSD > > UEFI-firmware interaction problem, while the ASRock is still under > > suspicion to be broken by design. > >> > >> GPT partitions can never start from disk absolute sector 1; this is > >> because at sector 0 there is MBR (for compatibility), sector 1 is GPT > >> table and then sectors 2-33 have GPT partition table entries, so the first > >> possible data sector is 34 (absolute 34). Thats assuming 512B sectors. > >> For details see UEFI 2.7 Chapter 5.3.1 page 131. > > > > Thanks for the explanation. That implies the installer did right, gpart did > > also right and therefore there must be an issue with the stuff located > > within the EFI partition? > > Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BIOS loader > at all or not - that is, if the BIOS bootstrap is actually caring to read the > MBR code and start it, since once the MBR code is started, it is all about > our code. I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or do you mean that specific portion of the UEFI firmware, which looks for the proper UEFI partition? The boxes in question, most notably the more recent Fujitsu Esprimo Q956, refuse booting UEFI, even if properly setup (in terms of what FreeBSD provides on recent CURRENT) is applied and CSM is switched off in the firmware. Again: GPT partition scheme. The system boots properly if a second partition of type "freebsd-boot" is applied and bootcode is properly applied via "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" (ada0 is the device). > > btw, you can try to validate the installed boot blocks by using recent enough > loader (usb or iso) and then you can use from OK prompt: lsdev provides me with the follwoing informations (CSM enabled): OK lsdev disk devices: disk0: BIOS DRIVE C ... disk0p1: EFI disk0p2: FreeBSD BOOT disk0p3: FreeBSD SWAP disk0p4: FreeBSD ZFS zfs devices: zfs:zroot OK chain disk0 open failed (so for disk0p{1-4}. OK chain zroot failed to read disk (just for completeness) > > OK chain diskX: > > (replace X by correct disk number from lsdev) to read and start the MBR code. > If that is working, then its really about BIOS refusing to read the MBR and > execute it. See above. I do not get that far to the loader if CSM is disabled (pure UEFI). The same on the ASROCK boards. The ASRock systems boot off of an SSD with GPT partition scheme and UFS filesystem only (running recent 12-CURRENT), while the Esprimo box is also an SSD, but GPT/ZFS (11.2-RELENG). I do not doubt the principle here, since a bunch of Fujitsu servers around here boot off 12-CURRENT and 11.2-RELENG from GPT/UFS SSDs as well as GPT/ZFS SSDs. Not problem so far. I checked out for the most recent Firmware for the ASRock boards and applied the may, 2018 Spectre/Meltdown mitigation images found in the BETA section. No changes for boot at all. Can I do something to help? > > rgds, > toomas > Kind regards, oh From owner-freebsd-current@freebsd.org Mon Jul 23 07:56:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9606210429A2 for ; Mon, 23 Jul 2018 07:56:26 +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 3828470DA1 for ; Mon, 23 Jul 2018 07:56:26 +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 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCB00M00732E800@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Mon, 23 Jul 2018 07:56:08 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCB005LO7DG9210@st13p35im-asmtp002.me.com>; Mon, 23 Jul 2018 07:56:08 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-23_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=8 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807230094 From: Toomas Soome Message-id: <80523BE6-C035-482D-B134-23812183DE83@me.com> MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations Date: Mon, 23 Jul 2018 10:56:04 +0300 In-reply-to: <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> Cc: freebsd-current To: "O. Hartmann" References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 07:56:27 -0000 > On 23 Jul 2018, at 10:27, O. Hartmann wrote: >=20 > On Fri, 13 Jul 2018 18:44:23 +0300 > Toomas Soome > wrote: >=20 >>> On 13 Jul 2018, at 17:44, O. Hartmann > wrote: >>>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>=20 >>> Am Fri, 13 Jul 2018 14:26:51 +0300 >>> Toomas Soome = >> schrieb: >>>=20 >>>>> On 13 Jul 2018, at 14:00, O. Hartmann = wrote: >>>>>=20 >>>>> The problem is some kind of weird. I face UEFI boot problems on = GPT drives >>>>> where the first partition begins at block 40 of the hdd/ssd. >>>>>=20 >>>>> I have two host in private use based on an >>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, = Socket >>>>> LGA1155). Both boards are equipted with the lates official = available AMI >>>>> firmware revision, dating to 2013. This is for the Z77-Pro4-M = revision >>>>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For = both >>>>> boards a BETA revision for the Spectre/Meltdown mitigation is = available, >>>>> but I didn't test that. But please read. >>>>>=20 >>>>> The third box I realised this problem is a brand new Fujitsu = Esprimo >>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date >>>>> 05/25/2018 (or 20180525). >>>>>=20 >>>>> Installing on any kind of HDD or SSD manually or via bsdinstall = the OS >>>>> using UEFI-only boot method on a GPT partitioned device fails. The = ASRock >>>>> boards jump immediately into the firmware, the Fujitsu offers some = kind >>>>> of CPU/Memory/HDD test facility. >>>>>=20 >>>>> If on both type of vendor/boards CSM is disabled and UEFI boot = only is >>>>> implied, the MBR partitioned FreeBSD installation USB flash device = does >>>>> boot in UEFI! I guess I can assume this when the well known clumsy = 80x25 >>>>> char console suddenly gets bright and shiny with a much higher = resoltion >>>>> as long the GPU supports EFI GOP. Looking with gpart at the USB = flash >>>>> drives reveals that the EFI partition starts at block 1 of the = device and >>>>> the device has a MBR layout. I haven't found a way to force the = GPT >>>>> scheme, when initialised via gpart, to let the partitions start at = block >>>>> 1. This might be a naiv thinking, so please be patient with me. >>>>>=20 >>>>> I do not know whether this is a well-known issue. On the ASRock = boards, I >>>>> tried years ago some LinuxRed Hat and Suse with UEFI and that = worked - >>>>> FreeBSD not. I gave up on that that time. Now, having the very = same >>>>> issues with a new Fujitsu system, leaves me with the impression = that >>>>> FreeBSD's UEFI implementation might have problems I'm not aware = of. >>>>>=20 >>>>> Can someone shed some light onto this?=20 >>>>>=20 >>>>=20 >>>> The first thing to check is if the secure boot is disabled. We do = not >>>> support secure boot at all at this time. =20 >>>=20 >>> Secure boot is in every scenario disabled! >>>=20 >>>>=20 >>>> If you have efi or bios version running - you can check from either >>>> console variable value (it can have efi or vidconsole or = comconsole) or >>>> better yet, see if efi-version is set (show efi-version) - if = efi-version >>>> is not set, it is BIOS loader running. Another indirect way is to = see >>>> lsdev -v, with device paths present, it is uefi:) =20 >>>=20 >>> What are you talking about? >>> What is the point of entry - running system, loader? >>>=20 >>> sysct machdep.bootmethod: BIOS >>>=20 >>> This makes me quite sure that the system has booted via BIOS - as = I'm sure >>> since I've checked that many times. UEFI doesn't work on those = systems with >>> FreeBSD. I'm not sure antmore, but I tried also Windows 7 on those >>> mainboards booting via UEFI - and I might recall that they failed = also. I >>> also recall that there were issues with earlier UEFI versions = regarding >>> booting only Windows 8/8.1 - and nothing else, but the fact that = Linux >>> worked confuses me a bit. >>>=20 >>> If this ASRock crap (never ever again this brand!) doesn't work at = all - >>> who cares, I intend to purchase new server grade hardware. But the = more >>> puzzling issue is with the Fujitsu, which I consider serious and = from the >>> behaviour the Fujitsu failure looks exactly like the ASRock - = Windows 7 >>> works, RedHat 7.5 works (I assume I can trust the Firmware settings = when I >>> disable CSM support, that the Firmware will only EFI/UEFI capable = loader? >>> Or is there a ghosty override somwhere to be expected?). Also on = ASRock >>> disabling CSM should ensure not booting a dual-bootstrap-capable = system. >>> This said, on the recent Fujitsu, it seems to boil down to a FreeBSD >>> UEFI-firmware interaction problem, while the ASRock is still under >>> suspicion to be broken by design.=20 >>>>=20 >>>> GPT partitions can never start from disk absolute sector 1; this is >>>> because at sector 0 there is MBR (for compatibility), sector 1 is = GPT >>>> table and then sectors 2-33 have GPT partition table entries, so = the first >>>> possible data sector is 34 (absolute 34). Thats assuming 512B = sectors. >>>> For details see UEFI 2.7 Chapter 5.3.1 page 131. =20 >>>=20 >>> Thanks for the explanation. That implies the installer did right, = gpart did >>> also right and therefore there must be an issue with the stuff = located >>> within the EFI partition?=20 >>=20 >> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BIOS = loader >> at all or not - that is, if the BIOS bootstrap is actually caring to = read the >> MBR code and start it, since once the MBR code is started, it is all = about >> our code. >=20 > I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or do = you mean > that specific portion of the UEFI firmware, which looks for the proper = UEFI > partition? >=20 BIOS as either native or CSM. Note that from boot code point of view the = CSM boot *is* BIOS boot, we have no access to UEFI features. >=20 > The boxes in question, most notably the more recent Fujitsu Esprimo = Q956, > refuse booting UEFI, even if properly setup (in terms of what FreeBSD = provides > on recent CURRENT) is applied and CSM is switched off in the firmware. = Again: > GPT partition scheme. >=20 > The system boots properly if a second partition of type "freebsd-boot" = is > applied and bootcode is properly applied via "gpart bootcode -b = /boot/pmbr > -p /boot/gptboot -i 2 ada0" (ada0 is the device).=20 >>=20 >> btw, you can try to validate the installed boot blocks by using = recent enough >> loader (usb or iso) and then you can use from OK prompt: >=20 > lsdev provides me with the follwoing informations (CSM enabled): >=20 > OK lsdev > disk devices: > disk0: BIOS DRIVE C ... >=20 > disk0p1: EFI > disk0p2: FreeBSD BOOT > disk0p3: FreeBSD SWAP > disk0p4: FreeBSD ZFS > zfs devices: > zfs:zroot >=20 > OK chain disk0 > open failed (so for disk0p{1-4}. >=20 > OK chain zroot > failed to read disk (just for completeness) chain command does use only device name (such as disk0: or disk0p2: ), = but not zfs pool as device. I just found I haven=E2=80=99t ported the = code to read the file. the point for chain command test is to see if the normal read and = execute would work, so in your case please try: chain disk0: to read pmbr (512B) and execute it. The expected outcome would be that = pmbr boot code would browse the GPT, read stage1 from disk0p2: and = execute it; stage1 would detect FreeBSD ZFS from disk0p4: and load and = execute /boot/loader. If that will happen, it means the boot code in our = stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6. if = thats true, it would mean that you either need to use UEFI boot or need = to have some hack to fool the BIOS or just not use GPT on that machine = with CSM. rgds, toomas >>=20 >> OK chain diskX: >>=20 >> (replace X by correct disk number from lsdev) to read and start the = MBR code. >> If that is working, then its really about BIOS refusing to read the = MBR and >> execute it. >=20 > See above. >=20 > I do not get that far to the loader if CSM is disabled (pure UEFI). = The same on > the ASROCK boards.=20 >=20 > The ASRock systems boot off of an SSD with GPT partition scheme and = UFS > filesystem only (running recent 12-CURRENT), while the Esprimo box is = also an > SSD, but GPT/ZFS (11.2-RELENG). >=20 > I do not doubt the principle here, since a bunch of Fujitsu servers = around here > boot off 12-CURRENT and 11.2-RELENG from GPT/UFS SSDs as well as = GPT/ZFS SSDs. > Not problem so far. >=20 > I checked out for the most recent Firmware for the ASRock boards and = applied > the may, 2018 Spectre/Meltdown mitigation images found in the BETA = section. No > changes for boot at all. >=20 > Can I do something to help? >=20 >>=20 >> rgds, >> toomas >>=20 >=20 > Kind regards, > oh > _______________________________________________ > freebsd-current@freebsd.org = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current = > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org = " From owner-freebsd-current@freebsd.org Mon Jul 23 10:57:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3E7B1046F68 for ; Mon, 23 Jul 2018 10:57:45 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (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 5F20A76801 for ; Mon, 23 Jul 2018 10:57:45 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 41Yz3Q1rxDzDhbK; Mon, 23 Jul 2018 10:57:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=daemonic.se; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=20151023; t=1532343457; bh=jBJL7IbjDGe6yfeUCY1W01r3 J7xLZI4sa5twbT0qEck=; b=eWv+KOlCEJNZoZ0pDxjzYRgsiXg6cWoq9fz3xsNh VnCG0Jwc6JGqryLoMw2ak4eJ6YCjUdbxIDe9M5Lp8yvV+L+SoSpUPgZxhCjg3xup UauVt7dye7cgkI3IJAC4z0uIUFUhVHieyU6Oa1+Lgd9ubkweBhpueOY159t3ayc1 bSc= X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id 3dlKpIkoQ11r; Mon, 23 Jul 2018 10:57:37 +0000 (UTC) Received: from garnet.daemonic.se (host-95-192-255-70.mobileonline.telia.com [95.192.255.70]) by mail.daemonic.se (Postfix) with ESMTPSA id 41Yz3P4JPGzDhbM; Mon, 23 Jul 2018 10:57:37 +0000 (UTC) Subject: Re: ntpd as ntpd user question To: RW , freebsd-current@freebsd.org References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721185654.239b4c8b@gumby.homeunix.com> From: Niclas Zeising Message-ID: Date: Mon, 23 Jul 2018 12:57:28 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 In-Reply-To: <20180721185654.239b4c8b@gumby.homeunix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 10:57:45 -0000 On 07/21/18 19:56, RW wrote: > On Sat, 21 Jul 2018 11:14:45 -0600 > Ian Lepore wrote: > > >> There's a "pre-world" stage of mergemaster (-Fp option I think) which >> isn't needed often, but one of the times it is needed is apparently >> when new user ids are added. > > I wish mergemaster had an option to just add new users and groups, > rather than merging the files. etcupdate is usually pretty good at automatically merge updates to files without user interaction, even when the files are locally edited as well. For instance, I had no problem merging /etc/master.passwd and /etc/group for the ntp change. Regards -- Niclas From owner-freebsd-current@freebsd.org Mon Jul 23 16:00:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCD34104ECAC for ; Mon, 23 Jul 2018 16:00:14 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 7C2B0827B3 for ; Mon, 23 Jul 2018 16:00:14 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-YMail-OSG: N03bsisVM1mgJX8CMrbNXVqqFb6MjJUgMVfjvagfadp60efxcmTQjYmd2uNnKQH ziXrxW7EIMSXvkQLmNlSnUrFqE7Rr3dR0pWbzVKLZ9c7LdJTwYZmfw.unt15ETBsT8DiXOjWloPO kttKM2QGg3MIhYD1jkgSO1YqcPpFyTs9SKHYU8omrdgodgYmWl_Fw2D4hZW_cWW2EezZUD_E12dV pUaMxtsqEIBctaT0s1__oRIqsSvBkaupMpB5AGldoZcRTDxgf_OHyk2ukjSXYjHCAQ8kqe8h65Xi 5tGd_uvdOSBL4cOSvml0v2o2G_aTFJZbBSTVXac1C5fftmJZUtCyrRq8XscQQxDLwdiz8hp_su6d 3xBL_M0YnVvrM8zXXfXg01Vzez7ZevuM3VAm5XByLLxaQbfmGWUZeGTr75KThc36eW6qobkMVfLY doZPD_56BKoqK0LHYVOBoasw51xjOdG1fw9fmTtMeQwOHZCb18wg3CysTPn0JsSmgYBbX5gGiwV9 kGeXQOPT5MprEQwXC1NOjDRUxRxLytPLVwWQaKPAO8I7EIdjT1KsRM9SYEWBXWZGbJsPJA65gRR1 24czsImPyhzmQzYSG2tUQ8FmChp6RLBzn_E9vlIQv5_kdbxqh5dtRYVnjvAycfMmu5zl5j4vdYXi OOON12EjikSLKeZwxT4ClF45y4X5f2CEQuKzjqQmUCVMmkm5obtJXs2N28pDyrDSPDc9qRJqzprh I1Sh2zjwnSCHskXEAOwcv231jtRfhADsLAuBxNwIUkW19FLhnoXwA8I8AC0w6h1avgCLkgg1W9sY sJBWOqmFEFi8SrofeSG5PPs.JtECuXtioDGAeJDKV_kxIIjudPBFIYwNuXX9UarSOj7t0TIy.ZUV .UHkvs74dOw47fxZBqat_nDZUm07KGLMrvr0Ul8PTVfeKRA.m92U7xwVvHespm38yHzMqZzPGnav JjVwp3ZHnvorFugSfD6Ped7EuKIN_hhU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 23 Jul 2018 16:00:08 +0000 Date: Mon, 23 Jul 2018 16:00:04 +0000 (UTC) From: Filippo Moretti To: Niclas Zeising Cc: FreeBSD Current Message-ID: <1712153218.980034.1532361604176@mail.yahoo.com> In-Reply-To: References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721185654.239b4c8b@gumby.homeunix.com> Subject: Re: ntpd as ntpd user question MIME-Version: 1.0 X-Mailer: WebService/1.1.12144 YMailNorrin Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:00:15 -0000 I have ntpd both in etc(passwd and /etc/group but installworld fail saying= that user ntpd is missing can you please let me know how to manually edit the entries for ntpd in both files.Etcupdate fails .It is rather odd because with the same hardware using ufs I did not run in= to problem with zfs system I get this error Filippo On Monday, July 23, 2018, 1:00:10 PM GMT+2, Niclas Zeising wrote: =20 =20 On 07/21/18 19:56, RW wrote: > On Sat, 21 Jul 2018 11:14:45 -0600 > Ian Lepore wrote: >=20 >=20 >> There's a "pre-world" stage of mergemaster (-Fp option I think) which >> isn't needed often, but one of the times it is needed is apparently >> when new user ids are added. >=20 > I wish mergemaster had an option to just add new users and groups, > rather than merging the files. etcupdate is usually pretty good at automatically merge updates to files=20 without user interaction, even when the files are locally edited as=20 well.=C2=A0 For instance, I had no problem merging /etc/master.passwd and= =20 /etc/group for the ntp change. Regards --=20 Niclas _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" =20 From owner-freebsd-current@freebsd.org Mon Jul 23 16:03:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95C3A104EF21 for ; Mon, 23 Jul 2018 16:03:15 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 393BC82C6A for ; Mon, 23 Jul 2018 16:03:15 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-YMail-OSG: 6wyJ1fMVM1m59lJqcSvwP99IVAQ5bTOIVlWItkVMrNHtSU9GntQRmVg1T_VY2sn mOfR5R5x3BcSdzupdrdu1vUOkegV2loPxnuPVc7urAyxZ8CXaAGz.4bvMplj9phjz4l0mi8Tq5YO wLLqBGNidStPnBxPTpLEM.4uiJVG6iKjcp3YOi0_ERsm9t1oJ9WAZnhzlf8DGdL.94bDeSJvBM0. wFPc4i20s2i0gTBG22s9lRdpPAzZ9kKO9IKciZ5QiSVU6jrgUSZ5PIB2TBHZesDG.DdZNf984cdO _BvvNOIqCQrZ5QKXcx02K4hzkGSpwfZ4ngCVCYPYEBDa9qagDFzKHYb9IAl3rGCv8znZzEXCfPwK gYqrQZw7o7_micvPC4VHA4gdIhoUV.PpxL9dvUhV8FxGxeT63j0DzCwB6tIpm61IY2RT.Z8nXDr2 CM6Z4RTGVQ2B5Rp6mgVU5FCjviDDfQP6HFH3SypzB947LLCya77GccYCuzuC.GG6lSrQMZa1wUso yxBpT80bAX824mzXhBH04xM.rr6hMLyb_WZI7ASFMSl2DOrzuXIHRzvveq4dvgC8mQHaBj3gmeOI 74qfI6K0GVG_n0DSNgoICBKNQy08vFc9pyXSFL3MbvvQTmyatTuWsj44QS2UKm7v_jN_BDM25BJ5 C4Lbo51LFu1jdDxz1n8JsYysXhoNrKWJTzhV.T3deUlde5GRY0ltiyjRlt0yAjZWGSZSI6nXJ5DR yd5aWreG9XnRGFnvs9lJ2TT4DQj8XVXSOtmWchj9MKnm2yhzARxVNgzUcvayPNmLPzgTNTlQ_pUH tdRgtM7pygkoNUxTxdQZDkWnd9vmHTGcRZPnSA6UZZPG34ISAW5paRlhc85YZdi2T6GmmOeUJHtL PPPfZWS4qmRuikECAycENmX5ezQnddnfel1shE8BaapFzhXycuJZ0ldNBLCIEvCOsKHztte1pYDq cgLRsPNvwZUVtMLjEpsjEgj8h2j0syTU3CBY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Mon, 23 Jul 2018 16:03:14 +0000 Date: Mon, 23 Jul 2018 16:03:10 +0000 (UTC) From: Filippo Moretti To: Filippo Moretti Cc: FreeBSD Current Message-ID: <54187900.992082.1532361790393@mail.yahoo.com> In-Reply-To: <1712153218.980034.1532361604176@mail.yahoo.com> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721185654.239b4c8b@gumby.homeunix.com> <1712153218.980034.1532361604176@mail.yahoo.com> Subject: Re: ntpd as ntpd user question MIME-Version: 1.0 X-Mailer: WebService/1.1.12144 YMailNorrin Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:03:15 -0000 =20 It does not matter the system no longer boot. Filippo On Monday, July 23, 2018, 6:00:04 PM GMT+2, Filippo Moretti wrote: =20 =20 I have ntpd both in etc(passwd and /etc/group but installworld fail sayin= g that user ntpd is missing can you please let me know how to manually edit the entries for ntpd in both files.Etcupdate fails .It is rather odd because with the same hardware using ufs I did not run in= to problem with zfs system I get this error Filippo On Monday, July 23, 2018, 1:00:10 PM GMT+2, Niclas Zeising wrote: =20 =20 On 07/21/18 19:56, RW wrote: > On Sat, 21 Jul 2018 11:14:45 -0600 > Ian Lepore wrote: >=20 >=20 >> There's a "pre-world" stage of mergemaster (-Fp option I think) which >> isn't needed often, but one of the times it is needed is apparently >> when new user ids are added. >=20 > I wish mergemaster had an option to just add new users and groups, > rather than merging the files. etcupdate is usually pretty good at automatically merge updates to files=20 without user interaction, even when the files are locally edited as=20 well.=C2=A0 For instance, I had no problem merging /etc/master.passwd and= =20 /etc/group for the ntp change. Regards --=20 Niclas _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" =20 From owner-freebsd-current@freebsd.org Mon Jul 23 16:07:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF76E104F16E for ; Mon, 23 Jul 2018 16:07:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 77BC082F5B for ; Mon, 23 Jul 2018 16:07:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 384FD104F16D; Mon, 23 Jul 2018 16:07:45 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24307104F16B for ; Mon, 23 Jul 2018 16:07:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 62ECC82F59 for ; Mon, 23 Jul 2018 16:07:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id w6NG7Zx1023520; Mon, 23 Jul 2018 16:07:35 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id w6NG7Zvk023519; Mon, 23 Jul 2018 09:07:35 -0700 (PDT) (envelope-from david) Date: Mon, 23 Jul 2018 09:07:35 -0700 From: David Wolfskill To: Filippo Moretti Cc: current@freebsd.org Subject: Re: ntpd as ntpd user question Message-ID: <20180723160735.GF1596@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Filippo Moretti , current@freebsd.org References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721185654.239b4c8b@gumby.homeunix.com> <1712153218.980034.1532361604176@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6fxres9eYHxJ4LJN" Content-Disposition: inline In-Reply-To: <1712153218.980034.1532361604176@mail.yahoo.com> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:07:46 -0000 --6fxres9eYHxJ4LJN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 23, 2018 at 04:00:04PM +0000, Filippo Moretti wrote: > I have ntpd both in etc(passwd and /etc/group but installworld fail sayi= ng that user ntpd is missing can you please let me know how > to manually edit the entries for ntpd in both files.Etcupdate fails > .It is rather odd because with the same hardware using ufs I did not run = into problem with zfs system I get this error > .... Depending on how you updated /etc/master.passwd, you may also need to run pwd_mkdb. Peace, david --=20 David H. Wolfskill david@catwhisker.org Can a "stable genius" get a Nobel Peace Prize for firing off ALL CAPS tweet= s? See http://www.catwhisker.org/~david/publickey.gpg for my public key. --6fxres9eYHxJ4LJN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAltV/UdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7he1TAgAqlyo3aR94hcT/fofq7eLqCff35kSUNb+8+BZIICE1ibUYNs4KFmuwkIl s461wXkXlmbPv/7wzhcNv9arthaj/VWWQTE5OnfQw+1Eb2p3wijwKBhcp0QWY2NG pvDoRlVYvtpQHfJjrCrTqzzXFxoR04nkG9Bz5IlZfBPhhnrn1CaCWnmf6Al4Zk7m h4UomUMtJJ2pPccIQp0qn11veuO2vXVc6CMY73nhotop/H748nJrj5ZQU544i03D kIv051IcqTEhkbpgPQSLJJJlF6bvXKgPowutOElbrwEbC3kgFeq9bIILMJSm0uGn TuzrVmQhVd3CMexg0a8NeCFShL0QSg== =SY79 -----END PGP SIGNATURE----- --6fxres9eYHxJ4LJN-- From owner-freebsd-current@freebsd.org Mon Jul 23 19:34:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57DC110533B3 for ; Mon, 23 Jul 2018 19:34:35 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [144.76.30.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAD4E8B680 for ; Mon, 23 Jul 2018 19:34:34 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Mon, 23 Jul 2018 21:34:26 +0200 Message-ID: <87r2jtiw59.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: bob prohaska Cc: freebsd-current@freebsd.org Subject: Re: ntpd as ntpd user question In-Reply-To: <20180723045552.GA44941@www.zefox.net> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/27.0 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 19:34:35 -0000 On Mon, 23 Jul 2018 06:55:52 +0200, bob prohaska wrote: > > On Sun, Jul 22, 2018 at 01:49:41AM +0200, Herbert J. Skuhra wrote: > > On Sat, Jul 21, 2018 at 03:09:26PM -0700, bob prohaska wrote: > > > > The failure is a little surprising, is ntpd a reserved name? > > > > Why? You obviously entered the string "ntpd" instead of an integer when > > asked for the uid!? > > > > Sigh...you're right. Must have been sleepier than I thought. > > > > The machine is re-running buildworld/installworld from a clean start, > > > so presumably it'll halt over the same error again. When that happens, > > > what's the simplest way to recover? Mergemaster is a big hammer, something > > > less comprehensive might suffice, even manual editing of files. > > > > In this case 'mergemaster -p' is enough. > > > > An example or two on the use of mergemaster might be a considerable help. There's something > very basic that I don't understand. > > What is the correct response to the prompts for this simple case? The output displayed > is said to be differences, so the "temporary" file's nature isn't self-evident. It looks > as if the most obvious option is m, followed by eb, but that leaves me editing by hand, > which is what I thought mergemaster was supposed to avoid. Yes, first you press m. Then you will see differences of installed file (left) and new file (right). Then you press either l or r: l | 1: choose left diff r | 2: choose right diff If the diff tries to remove/add to many lines you can: el: edit left diff er: edit right diff And if done you can view the merged file (v) before installing (i) it. I am sure, someone can explain it better! :) -- Herbert From owner-freebsd-current@freebsd.org Mon Jul 23 23:06:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8AF01056CA2 for ; Mon, 23 Jul 2018 23:06:21 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 2BAD0724CA for ; Mon, 23 Jul 2018 23:06:21 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: by mail-pl0-x22f.google.com with SMTP id w8-v6so843346ply.8 for ; Mon, 23 Jul 2018 16:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8swCLK3MiPpcwRltncFCc90s4ApWCs8iuKKDQi0QxsA=; b=oDH+9Qid3klrPTEs+qzS5GtLs7TbJZG+20Z3PE0YV30lV9vtnIAf5fq0FBLnMnkhfj gzEAkJFS+s4DPoEZq6/NTcw8AcJvobMiE1E3U5o3et5zUbQrJSAEMVcL0J8kUw8hIV0V e70sZu/xLVsxX3GOmJgR1sG2bcOGmZZAebjapTiUiUfu767Vx6lpBa9KLUNsXjrQQ6n7 X2c8ypsz4JPlkGWo44Hn/18XTU4jWFCDQS8SUv762xArrm6moDElj5GMc+mAmg+3baGj sY5eUZs32C12a1qtaQxd831QOHAH4QxECsrdciwS5DVogYtQMUqi6Fx4E8N+TkpGTsyH M9XQ== 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=8swCLK3MiPpcwRltncFCc90s4ApWCs8iuKKDQi0QxsA=; b=RAsy1sFBoNEWagvtPGO6fso1LAjOjd3ewuOayxf17iUxwEvRYV3G0M0PtCitxYHeZn 4HpvAGfHF8cW+JId8u9Gt+wyxpFeh0ELBNjCKje1AWHuUhw5kBYcrXbHvXD5qnLZIKYp 1G0Y7px0XLoFLOgvrDnLCrJVOMUzedDvoXUMqDkOdc33PaJ4X8HyzEkn5SxToV2hSQs2 8Ny4nDMyAVR1HYeohSlMmrrZFZVnWQDkB6yKNKAqDtFp7VlQtwq9KTjrAU1S2Ehk0rM6 YfbZ/3HwY9YnbHDnVSBKHUp8nWTRDnAILOW/NwKU3mS8muzL/9fxPU6yTo68nXOmLdSO kOYg== X-Gm-Message-State: AOUpUlGqXd5d5gxjhu8tEasAPQP5fK6NUpePzCGMShYtg/BtYnf2thnO SDuNQjNZSoM18bDC0xUJLLkc2hjc1hQV94jL+K3if48Rm2g= X-Google-Smtp-Source: AAOMgpcf3Mke9XpmFmry66KnmAtZDxCebbSyvjSITeGM2ZBkwLqGeuKESO5GWelEKKXofZUp+PYoXZ6rkgVYBof9kLo= X-Received: by 2002:a17:902:8645:: with SMTP id y5-v6mr14569004plt.334.1532387179925; Mon, 23 Jul 2018 16:06:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:7148:0:0:0:0 with HTTP; Mon, 23 Jul 2018 16:06:19 -0700 (PDT) From: Samy Mahmoudi Date: Tue, 24 Jul 2018 01:06:19 +0200 Message-ID: Subject: awk manual To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 23:06:21 -0000 Hello, The awk manual seems out of date. For example, the -V option is documented but is unknown at execution. Reciprocally, --version is not documented but is functional at execution. Under FreeBSD 12.0-CURRENT, the date at the end of the manual also seems older than expected, as the FreeBSD Manual Pages indicates a newer date for FreeBSD 11.2. I could edit awk.1 and copy/paste a patch to solve these but reviewing the whole manual may be better to eradicate other omissions. From the FreeBSD Manual Pages, I have found out that options (including -V) were introduced between 11.0 RELEASE and 11.1 RELEASE. By the way, choosing the "FreeBSD 12-current" manual on that web page actually gives the "FreeBSD 11.2" manual, seemingly. Best regards, Samy From owner-freebsd-current@freebsd.org Tue Jul 24 01:54:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19B231032585 for ; Tue, 24 Jul 2018 01:54:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 71C7978323 for ; Tue, 24 Jul 2018 01:54:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6O1sUhG049398 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Jul 2018 18:54:31 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6O1sSs8049397; Mon, 23 Jul 2018 18:54:28 -0700 (PDT) (envelope-from fbsd) Date: Mon, 23 Jul 2018 18:54:28 -0700 From: bob prohaska To: "Herbert J. Skuhra" Cc: freebsd-current@freebsd.org, bob prohaska Subject: Re: ntpd as ntpd user question Message-ID: <20180724015428.GB47869@www.zefox.net> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> <87r2jtiw59.wl-herbert@gojira.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r2jtiw59.wl-herbert@gojira.at> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 01:54:17 -0000 On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > Yes, first you press m. Then you will see differences of installed > file (left) and new file (right). Then you press either l or > r: > > l | 1: choose left diff > r | 2: choose right diff > > If the diff tries to remove/add to many lines you can: > > el: edit left diff > er: edit right diff > > And if done you can view the merged file (v) before installing (i) it. > > I am sure, someone can explain it better! :) > Perhaps, but you've made the essential point. Your reply let me understand that mergemaster does not really "master" the merge, it rather identifies files needing to be merged and then starts sdiff to let me modify files. Never having even looked at sdiff, the learning curve proved very steep. Too steep, in fact. I'm going to try a more incremental approach. Thank you _very_ much! bob prohaska From owner-freebsd-current@freebsd.org Tue Jul 24 02:26:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D5A51034493 for ; Tue, 24 Jul 2018 02:26:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 18B2079D7F for ; Tue, 24 Jul 2018 02:26:12 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: e7cc395f-8ee8-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e7cc395f-8ee8-11e8-aff6-0b9b8210da61; Tue, 24 Jul 2018 02:26:02 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6O2Px5o014325; Mon, 23 Jul 2018 20:25:59 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532399159.1344.211.camel@freebsd.org> Subject: Re: ntpd as ntpd user question From: Ian Lepore To: bob prohaska , "Herbert J. Skuhra" Cc: freebsd-current@freebsd.org Date: Mon, 23 Jul 2018 20:25:59 -0600 In-Reply-To: <20180724015428.GB47869@www.zefox.net> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> <87r2jtiw59.wl-herbert@gojira.at> <20180724015428.GB47869@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 02:26:13 -0000 On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > > > > > Yes, first you press m. Then you will see differences of installed > > file (left) and new file (right). Then you press either l or > > r: > > > > l | 1: choose left diff > > r | 2: choose right diff > > > > If the diff tries to remove/add to many lines you can: > > > > el: edit left diff > > er: edit right diff > > > > And if done you can view the merged file (v) before installing (i) > > it. > > > > I am sure, someone can explain it better! :) > > > Perhaps, but you've made the essential point. Your reply let me > understand that  > mergemaster does not really "master" the merge, it rather identifies > files needing  > to be merged and then starts sdiff to let me modify files. Never > having even looked  > at sdiff, the learning curve proved very steep. Too steep, in fact. > > I'm going to try a more incremental approach.  > > Thank you _very_ much! > > bob prohaska Your reaction to mergemaster is about the same as mine was when I first encountered it very long ago, and re-discovered when I tried it a couple years ago. It just seems like more trouble than it's worth, I can usually figure out what's broken and fix it by hand faster than messing with all the merge stuff. But, someone told me that if you give mergemaster the right flags it can potentially be intervention-free. Those apparently aren't the flag or two that're suggested at the bottom of UPDATING. So I didn't really dig into that any deeper, but I toss it out there in case someone can expand on it. It certainly makes some sense that it could be done intervention-free. When doing other diff-based merges (like 'svn update') you only have to intervene when there's an actual conflict between some local change you've made and the incoming changes. -- Ian From owner-freebsd-current@freebsd.org Tue Jul 24 03:10:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 001CC103CD68 for ; Tue, 24 Jul 2018 03:10:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EEE47BC8B; Tue, 24 Jul 2018 03:10:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6O3B0D3049657 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Jul 2018 20:11:01 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6O3Axfs049644; Mon, 23 Jul 2018 20:10:59 -0700 (PDT) (envelope-from fbsd) Date: Mon, 23 Jul 2018 20:10:58 -0700 From: bob prohaska To: Ian Lepore Cc: "Herbert J. Skuhra" , freebsd-current@freebsd.org, bob prohaska Subject: Re: ntpd as ntpd user question Message-ID: <20180724031058.GC47869@www.zefox.net> References: <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> <87r2jtiw59.wl-herbert@gojira.at> <20180724015428.GB47869@www.zefox.net> <1532399159.1344.211.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1532399159.1344.211.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 03:10:46 -0000 On Mon, Jul 23, 2018 at 08:25:59PM -0600, Ian Lepore wrote: > On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > > at sdiff, the learning curve proved very steep. Too steep, in fact. > > > > I'm going to try a more incremental approach.? > > > > Thank you _very_ much! > > > > bob prohaska > > Your reaction to mergemaster is about the same as mine was when I first > encountered it very long ago, and re-discovered when I tried it a > couple years ago. It just seems like more trouble than it's worth, I > can usually figure out what's broken and fix it by hand faster than > messing with all the merge stuff. > Your suggestion to use vipw seems to have worked. Copied the required line, ran /usr/sbin/pwd_mkdb -p /etc/master.passwd and installworld ran without issue. The machine has now rebooted and ntp has set the clock correctly. I don't see ntpd in a ps -aux output. It's unclear what I need to do next, but at least I'm over the first hurdle. I'll go back to your earlier email and attempt the rest of the updates by hand. Thanks for all your help! bob prohaska > But, someone told me that if you give mergemaster the right flags it > can potentially be intervention-free. Those apparently aren't the flag > or two that're suggested at the bottom of UPDATING. So I didn't really > dig into that any deeper, but I toss it out there in case someone can > expand on it. > > It certainly makes some sense that it could be done intervention-free. > When doing other diff-based merges (like 'svn update') you only have to > intervene when there's an actual conflict between some local change > you've made and the incoming changes. > > -- Ian > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Jul 24 04:28:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 924BC103F13B for ; Tue, 24 Jul 2018 04:28:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 1702C7E034; Tue, 24 Jul 2018 04:28:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-oi0-x233.google.com with SMTP id y207-v6so5157493oie.13; Mon, 23 Jul 2018 21:28:43 -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=dMoVp7t5w/vnMY9aJnXo7UR/uh/EosdouRim44jQ7Tg=; b=GeBRZigEW/RfjqisO5sAfn9raoEMXRmpbW74fsuJq6mDRNgLV5X7YM3GOFn8EaxcZV nPLlXk0umPbT4nTmOrkojJGCyCBpyPJsVIGgI3XUpInrgL++jfllibM819lkMW9Ulya4 m5/GhIZCNLOI0+OHJS2TSwNAb7bWipXtKizwj7RcbxYoVyZC9b2efxKkwE1ZWuyeDrT0 7d81FdVir8bCuIiPwR4jWKca/BNOltH4mEWhhaEUEJRrVQ0QaMUi2AxGnFFU15Y8nuZQ PmDKlai+UlTx9WBNtFEI8hVvZPuZ1hLaS/3tyMEExtXSyj09W8AdASkHZIvXek+8k1Jr kYWw== 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=dMoVp7t5w/vnMY9aJnXo7UR/uh/EosdouRim44jQ7Tg=; b=ieCZQ02Ez1oFX6wD5vL9K3zMb1EluYD9MrRAzPk0eKFhlwBOLBo8+DI+dsWqkEDIhL DzPOW3pF7GLDvYhAUCEtgpuJ1XzwO3Cxug6plN258lUQrgVvDXaTgzUl41O4HZZCewD6 sWOEiiTY+IHkUenvVQiFIMgyEknVYAlZGzf7pogIlukxg179IWIG953XjMQyAzOTQfIh IkvhIoyMS09gPem1YhX7oxrAiA5i8LdKcKX5UO6nDYTKJJa11igKheGj18TnDxvQn2OP l6FLMYQMopSP9S+GsVY3K1PkcbzzHJFm4iWNRXJjYltpk8VJ6KeNx4l+Zz42QYkP+/s4 l0cA== X-Gm-Message-State: AOUpUlHcAyvnatwmhU9EalsdHvGb9ldtDv8+bsBYaen3TinVpBh4S5j3 aCsqMXYm3VhshCL950wrpxAqR99TGkBaSR1IdLSm3dYz X-Google-Smtp-Source: AAOMgpc78VQDzLsYtJoRFKQAmolfHOOTZgWdy7yMsKVbvS4esNU/aV5ThZEAOnqC4wvp9JIqIFa1bllizrs/Bb+37qc= X-Received: by 2002:aca:578b:: with SMTP id l133-v6mr1655570oib.329.1532406521766; Mon, 23 Jul 2018 21:28:41 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 2002:ac9:2c55:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 21:28:41 -0700 (PDT) In-Reply-To: <1532399159.1344.211.camel@freebsd.org> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> <87r2jtiw59.wl-herbert@gojira.at> <20180724015428.GB47869@www.zefox.net> <1532399159.1344.211.camel@freebsd.org> From: Kevin Oberman Date: Mon, 23 Jul 2018 21:28:41 -0700 X-Google-Sender-Auth: dc8wBU1ssw7mDBIO2XiKuKVhJJI Message-ID: Subject: Re: ntpd as ntpd user question To: Ian Lepore Cc: bob prohaska , "Herbert J. Skuhra" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 04:28:43 -0000 On Mon, Jul 23, 2018 at 7:25 PM, Ian Lepore wrote: > On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > > > > > > > > Yes, first you press m. Then you will see differences of installed > > > file (left) and new file (right). Then you press either l or > > > r: > > > > > > l | 1: choose left diff > > > r | 2: choose right diff > > > > > > If the diff tries to remove/add to many lines you can: > > > > > > el: edit left diff > > > er: edit right diff > > > > > > And if done you can view the merged file (v) before installing (i) > > > it. > > > > > > I am sure, someone can explain it better! :) > > > > > Perhaps, but you've made the essential point. Your reply let me > > understand that > > mergemaster does not really "master" the merge, it rather identifies > > files needing > > to be merged and then starts sdiff to let me modify files. Never > > having even looked > > at sdiff, the learning curve proved very steep. Too steep, in fact. > > > > I'm going to try a more incremental approach. > > > > Thank you _very_ much! > > > > bob prohaska > > Your reaction to mergemaster is about the same as mine was when I first > encountered it very long ago, and re-discovered when I tried it a > couple years ago. It just seems like more trouble than it's worth, I > can usually figure out what's broken and fix it by hand faster than > messing with all the merge stuff. > > But, someone told me that if you give mergemaster the right flags it > can potentially be intervention-free. Those apparently aren't the flag > or two that're suggested at the bottom of UPDATING. So I didn't really > dig into that any deeper, but I toss it out there in case someone can > expand on it. > > It certainly makes some sense that it could be done intervention-free. > When doing other diff-based merges (like 'svn update') you only have to > intervene when there's an actual conflict between some local change > you've made and the incoming changes. > > It gets a LOT simpler if you use "mergemaster -iPUF" Only those files you have modified will show up. In most cases, it just zips right by. In most that it does not, the use of 'r' or 'l' in merge is all you need and always 'r' eccepton lines you have modified, yourself, so you should know about them. I should note that 'U' does have a small "race" in it, so it i possible to get biten by it, but it is very unlikely. Has to do with multiple commits that touch the same lines in the file in a timing that is out of sync with your running it. I use '-iPF' because I m paranoid. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Tue Jul 24 05:17:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19DE410407BB for ; Tue, 24 Jul 2018 05:17:07 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CA557FB80 for ; Tue, 24 Jul 2018 05:17:06 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LyB6P-1g2spE3YEX-015W93; Tue, 24 Jul 2018 07:16:54 +0200 Date: Tue, 24 Jul 2018 07:16:45 +0200 From: "O. Hartmann" To: Toomas Soome Cc: freebsd-current Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <80523BE6-C035-482D-B134-23812183DE83@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:kaldUXvoNbvSJiQgZs0oudw04hQJ8TXGk8BteXYtUdpS30A/5P3 ILx/szbRdULvy2HtdGivh/UWfwpg05BCEk8Z3bNFnu5GgLgiqU/w4VOXrmImlhEaF0ux2XF JwR3bMuGNpW1Yj3Jf4Udiil7JBj+5zWU14S2oaNkz85xWeee2zDKxXTrU2JYEkNVvbPBtQQ FdkMz3gQVdrP44b7H2k0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:XofDm7xAoQM=:TpGe8/xlwtImGlRPOo83qF SAufpTDbK7etPp+fJKuuKSq1vndXKfL4MJc/8HSXGzy9KLZR9hPonLIvroKxKLASd2yUA33dr /+/loRrJY8R4YTZ338PUMI92bS6C7utIaOeMfLuZsVGPjcSu8mCgAqW8yO6oizzGDu3aQCwkx 8fymEj+NAHzKdUOxuxvoWDLsXklwCL8cJAXUvu/i7dHZNaXEZNnvRHxpRSyRtUEbKXdXGJNaN 3vjd6A5VRwZgiU5gMWQ9Q/aOstQE+XP3b8w1mXf4Ko8fkLMnBbMTGL87Pb23HMwM/ZWazaNGf DWS6vUVw+KLZjLDsyUIGYbZVxNgzhNUArIf/v7BNT/TunZ5oe/v/Bu7x93iCLMUTBrwcITnXC +8zsYcqWvvlQ81AH/fUQGM5mleLz02ZSjU5WSuvi8AEI4wKSs7Fd+4vuK7t+k9g4boGd+LHPc Ri5cCPVpNsYxySLVxpBz3vKBczZn9AScv8ogoTm4CqJ9sisBfcCYbpeWq+tvB4kYCtR+aVRMz 8bHlw5U85on/F1sPCYdlgDvv/ECVUPS6mWllbPWXHsOXWaLJbBotg8MNsABloJZsEUOa4wvJV wzf0v/q8u7EOF+N3G1pHhiFilH3U1jpiPKAAQyH+FC75Qps/Ocj2MFMdaTZp0UIchkEvA7iLb NfLrZoLThqDqUK3uNpdbp1OHoXeyLKDWn0ArX3Cocn2ilmIDYmvdpCqcbmLnEZ80BVBBJN9C7 ii2Vc8gP11IXOLFXsofv/A1b2PgVTxwJz3HyMPWsx97q1yagui9l+96Ur9uvgQYpNYvjzPFFb TXOIZsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 05:17:07 -0000 On Mon, 23 Jul 2018 10:56:04 +0300 Toomas Soome wrote: > > On 23 Jul 2018, at 10:27, O. Hartmann wrote: > >=20 > > On Fri, 13 Jul 2018 18:44:23 +0300 > > Toomas Soome > wrote: > > =20 > >>> On 13 Jul 2018, at 17:44, O. Hartmann >>> > wrote: > >>>=20 > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA512 > >>>=20 > >>> Am Fri, 13 Jul 2018 14:26:51 +0300 > >>> Toomas Soome >>> >> schrieb:=20 > >>>>> On 13 Jul 2018, at 14:00, O. Hartmann wrot= e: > >>>>>=20 > >>>>> The problem is some kind of weird. I face UEFI boot problems on GPT > >>>>> drives where the first partition begins at block 40 of the hdd/ssd. > >>>>>=20 > >>>>> I have two host in private use based on an > >>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket > >>>>> LGA1155). Both boards are equipted with the lates official availabl= e AMI > >>>>> firmware revision, dating to 2013. This is for the Z77-Pro4-M revis= ion > >>>>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For = both > >>>>> boards a BETA revision for the Spectre/Meltdown mitigation is avail= able, > >>>>> but I didn't test that. But please read. > >>>>>=20 > >>>>> The third box I realised this problem is a brand new Fujitsu Esprimo > >>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date > >>>>> 05/25/2018 (or 20180525). > >>>>>=20 > >>>>> Installing on any kind of HDD or SSD manually or via bsdinstall the= OS > >>>>> using UEFI-only boot method on a GPT partitioned device fails. The > >>>>> ASRock boards jump immediately into the firmware, the Fujitsu offers > >>>>> some kind of CPU/Memory/HDD test facility. > >>>>>=20 > >>>>> If on both type of vendor/boards CSM is disabled and UEFI boot only= is > >>>>> implied, the MBR partitioned FreeBSD installation USB flash device = does > >>>>> boot in UEFI! I guess I can assume this when the well known clumsy = 80x25 > >>>>> char console suddenly gets bright and shiny with a much higher reso= ltion > >>>>> as long the GPU supports EFI GOP. Looking with gpart at the USB fla= sh > >>>>> drives reveals that the EFI partition starts at block 1 of the devi= ce > >>>>> and the device has a MBR layout. I haven't found a way to force the= GPT > >>>>> scheme, when initialised via gpart, to let the partitions start at = block > >>>>> 1. This might be a naiv thinking, so please be patient with me. > >>>>>=20 > >>>>> I do not know whether this is a well-known issue. On the ASRock boa= rds, > >>>>> I tried years ago some LinuxRed Hat and Suse with UEFI and that wor= ked - > >>>>> FreeBSD not. I gave up on that that time. Now, having the very same > >>>>> issues with a new Fujitsu system, leaves me with the impression that > >>>>> FreeBSD's UEFI implementation might have problems I'm not aware of. > >>>>>=20 > >>>>> Can someone shed some light onto this?=20 > >>>>> =20 > >>>>=20 > >>>> The first thing to check is if the secure boot is disabled. We do not > >>>> support secure boot at all at this time. =20 > >>>=20 > >>> Secure boot is in every scenario disabled! > >>> =20 > >>>>=20 > >>>> If you have efi or bios version running - you can check from either > >>>> console variable value (it can have efi or vidconsole or comconsole)= or > >>>> better yet, see if efi-version is set (show efi-version) - if efi-ve= rsion > >>>> is not set, it is BIOS loader running. Another indirect way is to see > >>>> lsdev -v, with device paths present, it is uefi:) =20 > >>>=20 > >>> What are you talking about? > >>> What is the point of entry - running system, loader? > >>>=20 > >>> sysct machdep.bootmethod: BIOS > >>>=20 > >>> This makes me quite sure that the system has booted via BIOS - as I'm= sure > >>> since I've checked that many times. UEFI doesn't work on those systems > >>> with FreeBSD. I'm not sure antmore, but I tried also Windows 7 on tho= se > >>> mainboards booting via UEFI - and I might recall that they failed als= o. I > >>> also recall that there were issues with earlier UEFI versions regardi= ng > >>> booting only Windows 8/8.1 - and nothing else, but the fact that Linux > >>> worked confuses me a bit. > >>>=20 > >>> If this ASRock crap (never ever again this brand!) doesn't work at al= l - > >>> who cares, I intend to purchase new server grade hardware. But the mo= re > >>> puzzling issue is with the Fujitsu, which I consider serious and from= the > >>> behaviour the Fujitsu failure looks exactly like the ASRock - Windows= 7 > >>> works, RedHat 7.5 works (I assume I can trust the Firmware settings w= hen I > >>> disable CSM support, that the Firmware will only EFI/UEFI capable loa= der? > >>> Or is there a ghosty override somwhere to be expected?). Also on ASRo= ck > >>> disabling CSM should ensure not booting a dual-bootstrap-capable syst= em. > >>> This said, on the recent Fujitsu, it seems to boil down to a FreeBSD > >>> UEFI-firmware interaction problem, while the ASRock is still under > >>> suspicion to be broken by design. =20 > >>>>=20 > >>>> GPT partitions can never start from disk absolute sector 1; this is > >>>> because at sector 0 there is MBR (for compatibility), sector 1 is GPT > >>>> table and then sectors 2-33 have GPT partition table entries, so the > >>>> first possible data sector is 34 (absolute 34). Thats assuming 512B > >>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. =20 > >>>=20 > >>> Thanks for the explanation. That implies the installer did right, gpa= rt > >>> did also right and therefore there must be an issue with the stuff lo= cated > >>> within the EFI partition? =20 > >>=20 > >> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BIOS l= oader > >> at all or not - that is, if the BIOS bootstrap is actually caring to r= ead > >> the MBR code and start it, since once the MBR code is started, it is a= ll > >> about our code. =20 > >=20 > > I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or do y= ou > > mean that specific portion of the UEFI firmware, which looks for the pr= oper > > UEFI partition? > > =20 >=20 > BIOS as either native or CSM. Note that from boot code point of view the = CSM > boot *is* BIOS boot, we have no access to UEFI features. >=20 > >=20 > > The boxes in question, most notably the more recent Fujitsu Esprimo Q95= 6, > > refuse booting UEFI, even if properly setup (in terms of what FreeBSD > > provides on recent CURRENT) is applied and CSM is switched off in the > > firmware. Again: GPT partition scheme. > >=20 > > The system boots properly if a second partition of type "freebsd-boot" = is > > applied and bootcode is properly applied via "gpart bootcode -b /boot/p= mbr > > -p /boot/gptboot -i 2 ada0" (ada0 is the device). =20 > >>=20 > >> btw, you can try to validate the installed boot blocks by using recent > >> enough loader (usb or iso) and then you can use from OK prompt: =20 > >=20 > > lsdev provides me with the follwoing informations (CSM enabled): > >=20 > > OK lsdev > > disk devices: > > disk0: BIOS DRIVE C ... > >=20 > > disk0p1: EFI > > disk0p2: FreeBSD BOOT > > disk0p3: FreeBSD SWAP > > disk0p4: FreeBSD ZFS > > zfs devices: > > zfs:zroot > >=20 > > OK chain disk0 > > open failed (so for disk0p{1-4}. > >=20 > > OK chain zroot > > failed to read disk (just for completeness) =20 >=20 >=20 > chain command does use only device name (such as disk0: or disk0p2: ), but > not zfs pool as device. I just found I haven=E2=80=99t ported the code t= o read the > file. ?? >=20 > the point for chain command test is to see if the normal read and execute > would work, so in your case please try: >=20 > chain disk0: As stated above, I did so, and the result is also mentioned above, I always= get=20 "open failed". This is the same for=20 chain disk0 chain disk0p1 chain disk0p2 chain disk0p3 chain disk0p4 as already said. CSM is enabled in this case. >=20 > to read pmbr (512B) and execute it. The expected outcome would be that pm= br > boot code would browse the GPT, read stage1 from disk0p2: and execute it; > stage1 would detect FreeBSD ZFS from disk0p4: and load and > execute /boot/loader. If that will happen, it means the boot code in our > stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6. if = thats true, > it would mean that you either need to use UEFI boot or need to have some = hack > to fool the BIOS or just not use GPT on that machine with CSM. To make it clear here: The only way to boot this box is using CSM (as it is= the same with the ASRock boards mentioned earlier). But my intention is to disa= ble CSM and use a GPT/UEFI environment only! And GPT/UEFI doesn't work with FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG. It would be nice if this could be fixed. I'm more interested in the fix on = the recent Fujitsu device than the outdated ASRock crap, but if the fix for the Fujitsu Firmware could fix older issues as a byproduct, I'd appreciate that. Kind regards, oh >=20 > rgds, > toomas >=20 > >>=20 > >> OK chain diskX: > >>=20 > >> (replace X by correct disk number from lsdev) to read and start the MBR > >> code. If that is working, then its really about BIOS refusing to read = the > >> MBR and execute it. =20 > >=20 > > See above. > >=20 > > I do not get that far to the loader if CSM is disabled (pure UEFI). The > > same on the ASROCK boards.=20 > >=20 > > The ASRock systems boot off of an SSD with GPT partition scheme and UFS > > filesystem only (running recent 12-CURRENT), while the Esprimo box is a= lso > > an SSD, but GPT/ZFS (11.2-RELENG). > >=20 > > I do not doubt the principle here, since a bunch of Fujitsu servers aro= und > > here boot off 12-CURRENT and 11.2-RELENG from GPT/UFS SSDs as well as > > GPT/ZFS SSDs. Not problem so far. > >=20 > > I checked out for the most recent Firmware for the ASRock boards and ap= plied > > the may, 2018 Spectre/Meltdown mitigation images found in the BETA sect= ion. > > No changes for boot at all. > >=20 > > Can I do something to help? > > =20 > >>=20 > >> rgds, > >> toomas > >> =20 > >=20 > > Kind regards, > > oh > > _______________________________________________ > > freebsd-current@freebsd.org mailing > > list https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To > > unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > > " =20 >=20 From owner-freebsd-current@freebsd.org Tue Jul 24 05:53:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A686A1041450 for ; Tue, 24 Jul 2018 05:53:42 +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 3052A80EA2 for ; Tue, 24 Jul 2018 05:53:42 +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 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCC00K00WCFX600@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Tue, 24 Jul 2018 05:53:41 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCC0016RWDDFK40@st13p35im-asmtp002.me.com>; Tue, 24 Jul 2018 05:53:40 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-24_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=8 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807240062 From: Toomas Soome Message-id: <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations Date: Tue, 24 Jul 2018 08:53:36 +0300 In-reply-to: <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> Cc: freebsd-current To: "O. Hartmann" References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 05:53:43 -0000 > On 24 Jul 2018, at 08:16, O. Hartmann wrote: >=20 > On Mon, 23 Jul 2018 10:56:04 +0300 > Toomas Soome wrote: >=20 >>> On 23 Jul 2018, at 10:27, O. Hartmann = wrote: >>>=20 >>> On Fri, 13 Jul 2018 18:44:23 +0300 >>> Toomas Soome > wrote: >>>=20 >>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>> > wrote: >>>>>=20 >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA512 >>>>>=20 >>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 >>>>> Toomas Soome = >>>> >> schrieb:=20 >>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann = wrote: >>>>>>>=20 >>>>>>> The problem is some kind of weird. I face UEFI boot problems on = GPT >>>>>>> drives where the first partition begins at block 40 of the = hdd/ssd. >>>>>>>=20 >>>>>>> I have two host in private use based on an >>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, = Socket >>>>>>> LGA1155). Both boards are equipted with the lates official = available AMI >>>>>>> firmware revision, dating to 2013. This is for the Z77-Pro4-M = revision >>>>>>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). = For both >>>>>>> boards a BETA revision for the Spectre/Meltdown mitigation is = available, >>>>>>> but I didn't test that. But please read. >>>>>>>=20 >>>>>>> The third box I realised this problem is a brand new Fujitsu = Esprimo >>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, = date >>>>>>> 05/25/2018 (or 20180525). >>>>>>>=20 >>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall = the OS >>>>>>> using UEFI-only boot method on a GPT partitioned device fails. = The >>>>>>> ASRock boards jump immediately into the firmware, the Fujitsu = offers >>>>>>> some kind of CPU/Memory/HDD test facility. >>>>>>>=20 >>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot = only is >>>>>>> implied, the MBR partitioned FreeBSD installation USB flash = device does >>>>>>> boot in UEFI! I guess I can assume this when the well known = clumsy 80x25 >>>>>>> char console suddenly gets bright and shiny with a much higher = resoltion >>>>>>> as long the GPU supports EFI GOP. Looking with gpart at the USB = flash >>>>>>> drives reveals that the EFI partition starts at block 1 of the = device >>>>>>> and the device has a MBR layout. I haven't found a way to force = the GPT >>>>>>> scheme, when initialised via gpart, to let the partitions start = at block >>>>>>> 1. This might be a naiv thinking, so please be patient with me. >>>>>>>=20 >>>>>>> I do not know whether this is a well-known issue. On the ASRock = boards, >>>>>>> I tried years ago some LinuxRed Hat and Suse with UEFI and that = worked - >>>>>>> FreeBSD not. I gave up on that that time. Now, having the very = same >>>>>>> issues with a new Fujitsu system, leaves me with the impression = that >>>>>>> FreeBSD's UEFI implementation might have problems I'm not aware = of. >>>>>>>=20 >>>>>>> Can someone shed some light onto this?=20 >>>>>>>=20 >>>>>>=20 >>>>>> The first thing to check is if the secure boot is disabled. We do = not >>>>>> support secure boot at all at this time. =20 >>>>>=20 >>>>> Secure boot is in every scenario disabled! >>>>>=20 >>>>>>=20 >>>>>> If you have efi or bios version running - you can check from = either >>>>>> console variable value (it can have efi or vidconsole or = comconsole) or >>>>>> better yet, see if efi-version is set (show efi-version) - if = efi-version >>>>>> is not set, it is BIOS loader running. Another indirect way is to = see >>>>>> lsdev -v, with device paths present, it is uefi:) =20 >>>>>=20 >>>>> What are you talking about? >>>>> What is the point of entry - running system, loader? >>>>>=20 >>>>> sysct machdep.bootmethod: BIOS >>>>>=20 >>>>> This makes me quite sure that the system has booted via BIOS - as = I'm sure >>>>> since I've checked that many times. UEFI doesn't work on those = systems >>>>> with FreeBSD. I'm not sure antmore, but I tried also Windows 7 on = those >>>>> mainboards booting via UEFI - and I might recall that they failed = also. I >>>>> also recall that there were issues with earlier UEFI versions = regarding >>>>> booting only Windows 8/8.1 - and nothing else, but the fact that = Linux >>>>> worked confuses me a bit. >>>>>=20 >>>>> If this ASRock crap (never ever again this brand!) doesn't work at = all - >>>>> who cares, I intend to purchase new server grade hardware. But the = more >>>>> puzzling issue is with the Fujitsu, which I consider serious and = from the >>>>> behaviour the Fujitsu failure looks exactly like the ASRock - = Windows 7 >>>>> works, RedHat 7.5 works (I assume I can trust the Firmware = settings when I >>>>> disable CSM support, that the Firmware will only EFI/UEFI capable = loader? >>>>> Or is there a ghosty override somwhere to be expected?). Also on = ASRock >>>>> disabling CSM should ensure not booting a dual-bootstrap-capable = system. >>>>> This said, on the recent Fujitsu, it seems to boil down to a = FreeBSD >>>>> UEFI-firmware interaction problem, while the ASRock is still under >>>>> suspicion to be broken by design. =20 >>>>>>=20 >>>>>> GPT partitions can never start from disk absolute sector 1; this = is >>>>>> because at sector 0 there is MBR (for compatibility), sector 1 is = GPT >>>>>> table and then sectors 2-33 have GPT partition table entries, so = the >>>>>> first possible data sector is 34 (absolute 34). Thats assuming = 512B >>>>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. =20 >>>>>=20 >>>>> Thanks for the explanation. That implies the installer did right, = gpart >>>>> did also right and therefore there must be an issue with the stuff = located >>>>> within the EFI partition? =20 >>>>=20 >>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach = BIOS loader >>>> at all or not - that is, if the BIOS bootstrap is actually caring = to read >>>> the MBR code and start it, since once the MBR code is started, it = is all >>>> about our code. =20 >>>=20 >>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or = do you >>> mean that specific portion of the UEFI firmware, which looks for the = proper >>> UEFI partition? >>>=20 >>=20 >> BIOS as either native or CSM. Note that from boot code point of view = the CSM >> boot *is* BIOS boot, we have no access to UEFI features. >>=20 >>>=20 >>> The boxes in question, most notably the more recent Fujitsu Esprimo = Q956, >>> refuse booting UEFI, even if properly setup (in terms of what = FreeBSD >>> provides on recent CURRENT) is applied and CSM is switched off in = the >>> firmware. Again: GPT partition scheme. >>>=20 >>> The system boots properly if a second partition of type = "freebsd-boot" is >>> applied and bootcode is properly applied via "gpart bootcode -b = /boot/pmbr >>> -p /boot/gptboot -i 2 ada0" (ada0 is the device). =20 >>>>=20 >>>> btw, you can try to validate the installed boot blocks by using = recent >>>> enough loader (usb or iso) and then you can use from OK prompt: =20 >>>=20 >>> lsdev provides me with the follwoing informations (CSM enabled): >>>=20 >>> OK lsdev >>> disk devices: >>> disk0: BIOS DRIVE C ... >>>=20 >>> disk0p1: EFI >>> disk0p2: FreeBSD BOOT >>> disk0p3: FreeBSD SWAP >>> disk0p4: FreeBSD ZFS >>> zfs devices: >>> zfs:zroot >>>=20 >>> OK chain disk0 >>> open failed (so for disk0p{1-4}. >>>=20 >>> OK chain zroot >>> failed to read disk (just for completeness) =20 >>=20 >>=20 >> chain command does use only device name (such as disk0: or disk0p2: = ), but >> not zfs pool as device. I just found I haven=E2=80=99t ported the = code to read the >> file. >=20 > ?? >=20 >>=20 >> the point for chain command test is to see if the normal read and = execute >> would work, so in your case please try: >>=20 >> chain disk0: >=20 > As stated above, I did so, and the result is also mentioned above, I = always get=20 > "open failed". > This is the same for=20 >=20 > chain disk0 > chain disk0p1 > chain disk0p2 > chain disk0p3 > chain disk0p4 >=20 > as already said. CSM is enabled in this case. sigh=E2=80=A6 chain command does take device as argument, device must = always end with colon=E2=80=A6. in this case, the devil is in details:) = as I wrote above, the command should be: chain disk0: The disk0p1: etc will only work when partition boot code was installed = (which you most likely do not have - the only possible candidate could = be FreeBSD ZFS partition). >=20 >>=20 >> to read pmbr (512B) and execute it. The expected outcome would be = that pmbr >> boot code would browse the GPT, read stage1 from disk0p2: and execute = it; >> stage1 would detect FreeBSD ZFS from disk0p4: and load and >> execute /boot/loader. If that will happen, it means the boot code in = our >> stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6. = if thats true, >> it would mean that you either need to use UEFI boot or need to have = some hack >> to fool the BIOS or just not use GPT on that machine with CSM. >=20 > To make it clear here: The only way to boot this box is using CSM (as = it is the > same with the ASRock boards mentioned earlier). But my intention is to = disable > CSM and use a GPT/UEFI environment only! And GPT/UEFI doesn't work = with > FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG. >=20 > It would be nice if this could be fixed. I'm more interested in the = fix on the > recent Fujitsu device than the outdated ASRock crap, but if the fix = for the > Fujitsu Firmware could fix older issues as a byproduct, I'd appreciate = that. >=20 > Kind regards, >=20 ok, somehow I have lost that part of the discussion. Well, you wrote = that the UEFI boot fails when the first partition starts from sector 40 = - does it mean you have boot when the partition will start from some = other sector? I think, there is something else going on. What you can do is to see if that firmware will offer you EFI shell = option, from there you can try to start the bootx64.efi manually and see = what error you will get. However, the number 1 cause for failing to = start the bootloader in UEFI is secure boot - we do not support it and = secure boot must be switched off.=20 However, they seem to claim "The Secure Boot option is available in the = UEFI/BIOS of most if not all ASRock boards. It is disabled by = default.=E2=80=9D=20 Still suggest to double check if thats really the case. Also, if the = bootx64.efi start will fail and no messages are appearing on screen, = then either there is something in firmware logs or you could get them = from trying to start bootx64.efi from UEFI shell. thds, toomas >=20 >>=20 >> rgds, >> toomas >>=20 >>>>=20 >>>> OK chain diskX: >>>>=20 >>>> (replace X by correct disk number from lsdev) to read and start the = MBR >>>> code. If that is working, then its really about BIOS refusing to = read the >>>> MBR and execute it. =20 >>>=20 >>> See above. >>>=20 >>> I do not get that far to the loader if CSM is disabled (pure UEFI). = The >>> same on the ASROCK boards.=20 >>>=20 >>> The ASRock systems boot off of an SSD with GPT partition scheme and = UFS >>> filesystem only (running recent 12-CURRENT), while the Esprimo box = is also >>> an SSD, but GPT/ZFS (11.2-RELENG). >>>=20 >>> I do not doubt the principle here, since a bunch of Fujitsu servers = around >>> here boot off 12-CURRENT and 11.2-RELENG from GPT/UFS SSDs as well = as >>> GPT/ZFS SSDs. Not problem so far. >>>=20 >>> I checked out for the most recent Firmware for the ASRock boards and = applied >>> the may, 2018 Spectre/Meltdown mitigation images found in the BETA = section. >>> No changes for boot at all. >>>=20 >>> Can I do something to help? >>>=20 >>>>=20 >>>> rgds, >>>> toomas >>>>=20 >>>=20 >>> Kind regards, >>> oh >>> _______________________________________________ >>> freebsd-current@freebsd.org = mailing >>> list https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To >>> unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org >>> " =20 >>=20 >=20 From owner-freebsd-current@freebsd.org Tue Jul 24 06:20:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17ABA1041967 for ; Tue, 24 Jul 2018 06:20:11 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 A3E80816F1 for ; Tue, 24 Jul 2018 06:20:10 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 862FA1B821 for ; Tue, 24 Jul 2018 06:20:04 +0000 (UTC) Subject: Re: [UEFI] Boot issues on some UEFI implementations To: freebsd-current@freebsd.org References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> From: Allan Jude Openpgp: preference=signencrypt Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Message-ID: Date: Tue, 24 Jul 2018 02:20:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YUGWAA3rXCwzKqnTdMCU9T7lNdBxHX5yi" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 06:20:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YUGWAA3rXCwzKqnTdMCU9T7lNdBxHX5yi Content-Type: multipart/mixed; boundary="jlj7vcZUNK0fte6P5h0H7d1yMKrnfR5Rh"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: [UEFI] Boot issues on some UEFI implementations References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> --jlj7vcZUNK0fte6P5h0H7d1yMKrnfR5Rh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-07-13 07:00, O. Hartmann wrote: > The problem is some kind of weird. I face UEFI boot problems on GPT dri= ves > where the first partition begins at block 40 of the hdd/ssd. >=20 > I have two host in private use based on an > outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket LG= A1155). > Both boards are equipted with the lates official available AMI firmware= > revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 (2013= /7/23) > and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA r= evision > for the Spectre/Meltdown mitigation is available, but I didn't test tha= t. But > please read. >=20 > The third box I realised this problem is a brand new Fujitsu Esprimo Q9= 56, also > AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or 2= 0180525). >=20 > Installing on any kind of HDD or SSD manually or via bsdinstall the OS = using > UEFI-only boot method on a GPT partitioned device fails. The ASRock boa= rds jump > immediately into the firmware, the Fujitsu offers some kind of CPU/Memo= ry/HDD > test facility. >=20 > If on both type of vendor/boards CSM is disabled and UEFI boot only is = implied, > the MBR partitioned FreeBSD installation USB flash device does boot in = UEFI! I > guess I can assume this when the well known clumsy 80x25 char console s= uddenly > gets bright and shiny with a much higher resoltion as long the GPU supp= orts > EFI GOP. Looking with gpart at the USB flash drives reveals that the EF= I > partition starts at block 1 of the device and the device has a MBR layo= ut. I > haven't found a way to force the GPT scheme, when initialised via gpart= , to let > the partitions start at block 1. This might be a naiv thinking, so plea= se be > patient with me. >=20 > I do not know whether this is a well-known issue. On the ASRock boards,= I > tried years ago some LinuxRed Hat and Suse with UEFI and that worked - = FreeBSD > not. I gave up on that that time. Now, having the very same issues with= a new > Fujitsu system, leaves me with the impression that FreeBSD's UEFI > implementation might have problems I'm not aware of. >=20 > Can someone shed some light onto this?=20 >=20 > Thanks in advance, >=20 > Oliver=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 If you are up for experimenting, see if either of these results in your system booting: gpart set -a active ada0 gpart set -a lenovofix ada0 Although both of these should only impact BIOS boot, not UEFI, you never know. The other option is to try an ESP (EFI System Partition) that is formatted FAT32 instead of FAT12/FAT16) --=20 Allan Jude --jlj7vcZUNK0fte6P5h0H7d1yMKrnfR5Rh-- --YUGWAA3rXCwzKqnTdMCU9T7lNdBxHX5yi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJbVsUTAAoJEBmVNT4SmAt+HvwQAMMM7ZDFL3pZ9kHOIxra9vcq kcFZUKT/qTiMBg6+vC7Woci4tXBZEDR9APojxA0i7Z1urWlw0JFHTXIMXcB7oI1Q SmTFrEb0fbvo9+aXtUPZ6Si9BNJZgHv3wTZVu3y1W7dKazztnX8rJq5vsoBRVRoX NS3ok5XWd0za/EqWW8EMxkzb0m8FqEegKPKpCQq2hXwTBHJFNrYAQgB+zRpd5JWz Bj24UnfeUQvHkYbRbX66huYtFO6+YjdX7kJ2AEqeamjjF204kfjQBItwsDlTH3TU YzFAotr+j1VpXqvDPRZ47HPPkHGWMdCin5GUzDoKV8MXjRW3m/QhyiYqcErQEoxQ i9AN8M0hHdG6eX76Onde2+dZkz4EsK5IIvGbd5HTBpcHltuyIVWtw/1MNREQaaaT EyC4O2CxLab4J5Jx3b0ne4CVmPjzDY3AnqoeUbRCbAsr3hBk/UZoUvJ+jUYegvRg kEeLjODlOVeyqEKZAbSrqkuV5S0QnLVzQHNuvzPZ0nwS8ADpiVYL/YZXBEuLx1H1 OGw3LadVB9oWPfz3ZVS7T+bcXfkCVRmjuiUsM2bGHSsOtkEtd6xvgRwBVsDWkMEy du95CTQfE/W248b9XUT/UvptSw9CWE8HI0WxzcKMNQqUy/ys7TeFQ5TIUTWKehES 7dBDk6TYhojzdPypg9PB =HsAa -----END PGP SIGNATURE----- --YUGWAA3rXCwzKqnTdMCU9T7lNdBxHX5yi-- From owner-freebsd-current@freebsd.org Tue Jul 24 07:30:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D65571043148 for ; Tue, 24 Jul 2018 07:30:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 8393A834D9; Tue, 24 Jul 2018 07:30:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCC00C00Y0I5200@st13p35im-asmtp001.me.com>; Tue, 24 Jul 2018 06:30:12 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCC00PIIY283530@st13p35im-asmtp001.me.com>; Tue, 24 Jul 2018 06:30:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-24_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=8 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807240069 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations From: Toomas Soome In-reply-to: Date: Tue, 24 Jul 2018 09:30:08 +0300 Cc: freebsd-current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <5BE9BA38-4B13-4BC8-A0CE-EEE4F34CFF08@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> To: Allan Jude X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 07:30:40 -0000 > On 24 Jul 2018, at 09:20, Allan Jude wrote: >=20 > On 2018-07-13 07:00, O. Hartmann wrote: >> The problem is some kind of weird. I face UEFI boot problems on GPT = drives >> where the first partition begins at block 40 of the hdd/ssd. >>=20 >> I have two host in private use based on an >> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket = LGA1155). >> Both boards are equipted with the lates official available AMI = firmware >> revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 = (2013/7/23) >> and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA = revision >> for the Spectre/Meltdown mitigation is available, but I didn't test = that. But >> please read. >>=20 >> The third box I realised this problem is a brand new Fujitsu Esprimo = Q956, also >> AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or = 20180525). >>=20 >> Installing on any kind of HDD or SSD manually or via bsdinstall the = OS using >> UEFI-only boot method on a GPT partitioned device fails. The ASRock = boards jump >> immediately into the firmware, the Fujitsu offers some kind of = CPU/Memory/HDD >> test facility. >>=20 >> If on both type of vendor/boards CSM is disabled and UEFI boot only = is implied, >> the MBR partitioned FreeBSD installation USB flash device does boot = in UEFI! I >> guess I can assume this when the well known clumsy 80x25 char console = suddenly >> gets bright and shiny with a much higher resoltion as long the GPU = supports >> EFI GOP. Looking with gpart at the USB flash drives reveals that the = EFI >> partition starts at block 1 of the device and the device has a MBR = layout. I >> haven't found a way to force the GPT scheme, when initialised via = gpart, to let >> the partitions start at block 1. This might be a naiv thinking, so = please be >> patient with me. >>=20 >> I do not know whether this is a well-known issue. On the ASRock = boards, I >> tried years ago some LinuxRed Hat and Suse with UEFI and that worked = - FreeBSD >> not. I gave up on that that time. Now, having the very same issues = with a new >> Fujitsu system, leaves me with the impression that FreeBSD's UEFI >> implementation might have problems I'm not aware of. >>=20 >> Can someone shed some light onto this?=20 >>=20 >> Thanks in advance, >>=20 >> Oliver=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 >=20 > If you are up for experimenting, see if either of these results in = your > system booting: > gpart set -a active ada0 > gpart set -a lenovofix ada0 >=20 > Although both of these should only impact BIOS boot, not UEFI, you = never > know. >=20 > The other option is to try an ESP (EFI System Partition) that is > formatted FAT32 instead of FAT12/FAT16) >=20 >=20 oops, indeed, and not just FAT32, but rather large one; first, the = minimum size for FAT32 is ~32MB - it can not be smaller, and with 4kn = you can not get below 256MB:) but, I recall there were some reports about systems refusing to boot if = ESP was not FAT32. I can not remember if there was some size limit = involved too or not (the UEFI specification does not set requirements = for ESP size). my 2cents, toomas From owner-freebsd-current@freebsd.org Tue Jul 24 12:23:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB5BB104A75F for ; Tue, 24 Jul 2018 12:23:08 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AC438CCB3; Tue, 24 Jul 2018 12:23:07 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lp7d2-1gBlNw1ApQ-00euGy; Tue, 24 Jul 2018 14:23:00 +0200 Date: Tue, 24 Jul 2018 14:22:59 +0200 From: "O. Hartmann" To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180724142255.23e120c6@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:zu+fIIqgTgzzQ2bZzRUpF7aI6AAxXBpbqvMRCwNQTV5HSnJeWXb a9DDVC38NkFmBfBujFUZ7qQbCc1+l/bF8QDNfknGB/YX57JOxGaJBfmzQxXZJ9CzMMqC/xz pLRNDTP2C8smOyKj3jdYykUH5FoqgsZuzXQFobY8n4oW9XNY49BOw/Rcqp9cMqtYahjRjLW exLC6uqoNklzwVhE9hDwA== X-UI-Out-Filterresults: notjunk:1;V01:K0:4xnOPC0VZ9k=:DqNuufe2H1LIyZOzCqVRc7 WxAtG2ORAkIUUu5R1iPfuIPTvDtVxm2yp/uxbBUzQVscixvqx6w379WRpIvUFwiY3cGQWxS62 e2QF6DbmuBzgNORf6ZUahRXq/taaZfrWx7r5QpgdfVHCa4iHLbSFjqte/R4zmC+FligrcbGAb VRs8UlC9WuHR+18TZZEklCbThcexFes6Nxwkgwb/KDkhDdga4iLf2EyAwsaPxVUFu/rOyK5Re jRqproNLXOuY6ggIRClQ8280IX3YnHEAfQ5EyrHSqwYXO+3rY0FXAlfN6vgw7AreQb/ADgHr3 zh0wcYT3xbEn8E8FEiI1iErpAz4qXWf2L28SqqGjIpCjRiz00TYBmJpDhc2dpqak8xaDFPHcW o5Da7I8Iq03mbhf9WEh/+OcSAcuKb5fb55pe12ClalO2yxMWVPtl10VwiM/dn/4j6Y+ivgREE z5Ll4fWbRQDRwTPdLM98wGj88dMAb1aFbmx9x4OcOxRcv9gBL78svW/PB4DhJ4VVCBb88rNnT 7hMVgCW1k75oJg5EM5yQms3nkKzjfqoB8lYh7xJhB00OpCZlrzMEbZ2ejLz+4pG8b9U8TRXnN aPBP0zftSO6j9LxBAMJKBGvi7IbZuyfyxlUZLVBH7UVNjpgpJHZMoSJz5YF3cnSbzgd2CmU4a aGOvDVOlEDKEYfDMgPGcMsiBVcdpE+eEfYJkpAPGPez31Omct/LG/7m8Jdsy61AfYx88NhNJi /490GUXLW7cH0v2dGlzc0wJFVDnSozIGFkosQEw8WPV6Btof0ac4Ohn3jujXB+SlY3enUWZxo Hn6YKc2 X-Mailman-Approved-At: Tue, 24 Jul 2018 12:24:51 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 12:23:09 -0000 On Tue, 24 Jul 2018 02:20:00 -0400 Allan Jude wrote: > On 2018-07-13 07:00, O. Hartmann wrote: > > The problem is some kind of weird. I face UEFI boot problems on GPT dri= ves > > where the first partition begins at block 40 of the hdd/ssd. > >=20 > > I have two host in private use based on an > > outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket > > LGA1155). Both boards are equipted with the lates official available AMI > > firmware revision, dating to 2013. This is for the Z77-Pro4-M revision = 2.0 > > (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boa= rds > > a BETA revision for the Spectre/Meltdown mitigation is available, but I > > didn't test that. But please read. > >=20 > > The third box I realised this problem is a brand new Fujitsu Esprimo Q9= 56, > > also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 = (or > > 20180525). > >=20 > > Installing on any kind of HDD or SSD manually or via bsdinstall the OS = using > > UEFI-only boot method on a GPT partitioned device fails. The ASRock boa= rds > > jump immediately into the firmware, the Fujitsu offers some kind of > > CPU/Memory/HDD test facility. > >=20 > > If on both type of vendor/boards CSM is disabled and UEFI boot only is > > implied, the MBR partitioned FreeBSD installation USB flash device does > > boot in UEFI! I guess I can assume this when the well known clumsy 80x25 > > char console suddenly gets bright and shiny with a much higher resoltio= n as > > long the GPU supports EFI GOP. Looking with gpart at the USB flash driv= es > > reveals that the EFI partition starts at block 1 of the device and the > > device has a MBR layout. I haven't found a way to force the GPT scheme, > > when initialised via gpart, to let the partitions start at block 1. This > > might be a naiv thinking, so please be patient with me. > >=20 > > I do not know whether this is a well-known issue. On the ASRock boards,= I > > tried years ago some LinuxRed Hat and Suse with UEFI and that worked - > > FreeBSD not. I gave up on that that time. Now, having the very same iss= ues > > with a new Fujitsu system, leaves me with the impression that FreeBSD's= UEFI > > implementation might have problems I'm not aware of. > >=20 > > Can someone shed some light onto this?=20 > >=20 > > Thanks in advance, > >=20 > > Oliver=20 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > =20 >=20 > If you are up for experimenting, see if either of these results in your > system booting: > gpart set -a active ada0 > gpart set -a lenovofix ada0 >=20 > Although both of these should only impact BIOS boot, not UEFI, you never > know. >=20 > The other option is to try an ESP (EFI System Partition) that is > formatted FAT32 instead of FAT12/FAT16) How can I detect the format of the EFI partition? Suppose I create the EFI partition via gpart, 12-CURRENT installer or 11.2-RELENG installer, what fo= rmat would that EFI partition be (the partition scheme I use is always GPT so far and as far as I know)? What format is the result, if I would dd /boot/boot1.efifat to the EFI partition? =46rom a first glimpse I guess its FAT12/16, since creating an EFI partition = via gpart myself of 500m and try to newfs_msdos -F 32, I receive an error about insufficient clusters with no further parameters. I tried to create a 512m partition fiddling around with the blocksize option -b of newfs_msdos When created manually /dev/gpt/efiboot0, formatted FAT32 (with -b 512 or -b 1024, I forgot) and preparing/copying the content of /boot/boot1.efifat (mdconfig mounted ...) with proper folder structure to efi/boot/ on the new= ly created FAT32 formatted EFI partition, I struggle then with a quick installation of FreeBSD using "bsdinstall". Having created according to a p= ure ZFS disk swap, gptboot (to be on the secure side if UEFI fails again) and a zroot ZFS pool, the dumb installer doesn't let me create a filesystem struc= ture on ZFS for the installation without destroying the initial layout :-(=20 So I stopped at that point and tried booting the box with only the FAT32 EFI/ESP partition with the loader copied from boot1.efifat as described.=20 The result is annoying, the ESPRIMO Q956 firmware shows up with some kind of testing tool/shell as reported in the initial posting of mine. I'd have expected some signs from the FreeBSD UEFI bootloader so far at this point, = but I might be mislead here. I also have applied the "gpart set -a" commands, without any effect. >=20 From owner-freebsd-current@freebsd.org Tue Jul 24 16:40:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD3DE10503A2 for ; Tue, 24 Jul 2018 16:40:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EA397632C; Tue, 24 Jul 2018 16:40:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-169-199-167.dyn.iinet.net.au [124.169.199.167]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w6OGeGHB075997 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2018 09:40:20 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: gcc/clang interoperability problem with a custom "samba" build in recent -current. To: Dimitry Andric , Yuri Pankov Cc: freebsd-current References: <3dd60a0d-7a5e-e9f0-3018-d09b5b8ac389@yuripv.net> From: Julian Elischer Message-ID: <0a54cb6e-f528-df63-57f2-6caa3d76ff6c@freebsd.org> Date: Wed, 25 Jul 2018 00:40:11 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 16:40:29 -0000 On 22/7/18 4:32 am, Dimitry Andric wrote: > On 21 Jul 2018, at 21:11, Yuri Pankov wrote: >> Yuri Pankov wrote: >>> Julian Elischer wrote: > ... >>>>> anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? >>> In later GCC versions the cpp's -lang-asm seems to be deprecated in >>> favor of -x assembler-with-cpp as it conflicts with -l option. >>> Could you try changing the -Wp,-E,-lang-asm to -Wp,-E,-xassembler-with-cpp? >> Just tried it myself, and if you indeed mean the third_party/aesni-intel/aesni-intel_asm.c, the following seems to work for me: >> >> clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c > Yes, that is exactly what I suggested to Julian on IRC. The point is > that the ".c" extension is misleading, it should more likely be a ".S" > extension. But maybe this source file is used for multiple purposes. > > Note that -x assembler-with-cpp should also work fine for gcc. > > -Dimitry > thanks I tried that but the version of the file we have has several lines that caused problems... a lot of the assembler has assembler comments (starting with '#') which clang complained about and died.. it also had #.align 4 which I HOPE is just a commented out line.. From owner-freebsd-current@freebsd.org Tue Jul 24 17:44:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E55E1051CF9 for ; Tue, 24 Jul 2018 17:44:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 CC41278F12 for ; Tue, 24 Jul 2018 17:44:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x236.google.com with SMTP id w16-v6so4952744ita.0 for ; Tue, 24 Jul 2018 10:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=y7Gr0D4/LR4G4YTj60COLWstadlTZKtOKosI4d7dA1M=; b=XJkRi5RbkXA7Qvi9WxmsDq1v+AdwV+SPqPH/hjHMWCzhV5E8Cy7hFSM+fjNVnn4gy3 WR/sso5FkD3X5cPc0INud/pEFWxWaY73ZlbATWPddXImyu/VQUwX2sAdhjwwxpPUuWAX BotaHxIxpAAwJ8X0fCy+T8gTVRCuArEq9nu5twupQtgzxvnRuJxTM8l1tFQws+pTwGI+ s/+uYUQ4Hqh7EjRPefo6hptSpNz1UPEzUrXzZnJCBi+NjBWnyCo05pL4mOLga1PbyZdj JPzGubh57pow/FN+/yJGP1D7F2bmvhMWF9KoGUh1qUy0uWqsgbwSiyl82j+U5+cAlWPp FnlQ== 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:from:date:message-id:subject :to; bh=y7Gr0D4/LR4G4YTj60COLWstadlTZKtOKosI4d7dA1M=; b=XInPNcRnhfu4de07W18F+ZwIxBaGuMHidhKryniVZMbKZOMZr/xFGASCPH8xv+52QY mdKxK+mtw9FZE1F55qTUdypWyGp1sYho3Tm1c0crZpCE6Prl2ZpFOwkPLNW84yvZJDDi T+M+wwZL454ove/6ETC1XX2EiX2URcRVnYPA57pve2lEYol9IGoT/SHs5hz/HMyeu17T Oe7r0IjaYyutbLavfxVcz6mSIPqFRudLfUkF6b0HZ/Z9dbwGKzoOtG+v97NXOJsKF1b+ Cl4CO7nXFy35LcduuXFbbNGbSMMPb5Wl0Mo3rjcvLa0ptZTyA9rUfre/jrcj86JMtDEb gzZA== X-Gm-Message-State: AOUpUlHevAidK+i0+zPYemMUMQfHLmLxSbqQCF4zBmOncLYOmY4Fb0EU Up1zcvaSeVloiFaC8vumtnKvPGwAnlDXJ+/JGWdhgA== X-Google-Smtp-Source: AAOMgpd8JdVkvB6ucy4MnJ6Mf9CT0JenPciyITk4LTBkqokRH0BCn0omUIZ4BSeOKMhcZX+5vYvXFhr+pvQoGpMvabE= X-Received: by 2002:a02:9a10:: with SMTP id b16-v6mr16644080jal.4.1532454255717; Tue, 24 Jul 2018 10:44:15 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:290d:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 10:43:55 -0700 (PDT) From: Ed Maste Date: Tue, 24 Jul 2018 13:43:55 -0400 X-Google-Sender-Auth: K95KpsMYiU2plYzvbF7PbhA7kmo Message-ID: Subject: i386 top reporting nan% or inf% WCPU To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:44:17 -0000 I recently merged my work in progress tree up to r336665 and built a i386 VM image. Running the image in QEMU (qemu-system-x86_64) and executing 'top' I see the WCPU column reported as either nan% or inf% for all processes. Prior to today I hadn't built or tested i386 in a while, so I am not sure off hand if this is a recent issue. amd64 is fine. Is anyone else seeing this? From owner-freebsd-current@freebsd.org Tue Jul 24 18:17:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AD231052872 for ; Tue, 24 Jul 2018 18:17:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E90C67A2C2; Tue, 24 Jul 2018 18:17:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w6OIH3We051618 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Jul 2018 21:17:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w6OIH3We051618 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w6OIH3te051617; Tue, 24 Jul 2018 21:17:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Jul 2018 21:17:03 +0300 From: Konstantin Belousov To: Ed Maste Cc: FreeBSD Current Subject: Re: i386 top reporting nan% or inf% WCPU Message-ID: <20180724181703.GK65334@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:17:11 -0000 On Tue, Jul 24, 2018 at 01:43:55PM -0400, Ed Maste wrote: > I recently merged my work in progress tree up to r336665 and built a > i386 VM image. Running the image in QEMU (qemu-system-x86_64) and > executing 'top' I see the WCPU column reported as either nan% or inf% > for all processes. > > Prior to today I hadn't built or tested i386 in a while, so I am not > sure off hand if this is a recent issue. amd64 is fine. Is anyone else > seeing this? I believe this is a qemu bug. Their FPU emulation is very basic, at least it was so several years ago, when not using accelerated emulation. From owner-freebsd-current@freebsd.org Tue Jul 24 20:02:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3F5B1054A29 for ; Tue, 24 Jul 2018 20:02:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 542007D778; Tue, 24 Jul 2018 20:02:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id i3VRfZFIVp5A1i3VTfgkJc; Tue, 24 Jul 2018 14:02:04 -0600 X-Authority-Analysis: v=2.3 cv=JLKPTPCb c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=R9QF1RCXAYgA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=aCSBqE10hRDOshZ2GicA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 954086CB; Tue, 24 Jul 2018 13:02:08 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w6OK1m3L002265; Tue, 24 Jul 2018 13:01:48 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w6OK1lFG002262; Tue, 24 Jul 2018 13:01:47 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201807242001.w6OK1lFG002262@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Konstantin Belousov cc: Ed Maste , FreeBSD Current Subject: Re: i386 top reporting nan% or inf% WCPU In-Reply-To: Message from Konstantin Belousov of "Tue, 24 Jul 2018 21:17:03 +0300." <20180724181703.GK65334@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jul 2018 13:01:47 -0700 X-CMAE-Envelope: MS4wfKjwDjKb5Z0ZHIFy4R/w83niBJy6DuIAN3soo+2gWs16eX4JHCQfQLRYFwHZDQ6OA8xkulYmAcR5L9flIhwiKaxwnQ8ijZb/WvrwxcAaV/Cl2Qwlxjdt mdSLTJXV7amExU/rDGr7hwwM3/54mhYm5b7zb43dTrIhS1QNO6K3rDW2Lnj8J+/Iwh1qJYwNqouAFU0ifKQg0JAbxuvSRMaTRVd5vIMuvGmbfV1/xWeE1wdh C1RG6keSB0IUh4sbT1jGVQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:02:06 -0000 In message <20180724181703.GK65334@kib.kiev.ua>, Konstantin Belousov writes: > On Tue, Jul 24, 2018 at 01:43:55PM -0400, Ed Maste wrote: > > I recently merged my work in progress tree up to r336665 and built a > > i386 VM image. Running the image in QEMU (qemu-system-x86_64) and > > executing 'top' I see the WCPU column reported as either nan% or inf% > > for all processes. > > > > Prior to today I hadn't built or tested i386 in a while, so I am not > > sure off hand if this is a recent issue. amd64 is fine. Is anyone else > > seeing this? > > I believe this is a qemu bug. Their FPU emulation is very basic, at least > it was so several years ago, when not using accelerated emulation. Just tested on the i386 slice on my laptop. No problems there. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Tue Jul 24 20:11:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C3581054CB5 for ; Tue, 24 Jul 2018 20:11:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D3F17DC6B; Tue, 24 Jul 2018 20:11:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6OKBFOc053300 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Jul 2018 13:11:16 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6OKBDLS053299; Tue, 24 Jul 2018 13:11:13 -0700 (PDT) (envelope-from fbsd) Date: Tue, 24 Jul 2018 13:11:13 -0700 From: bob prohaska To: Kevin Oberman Cc: Ian Lepore , "Herbert J. Skuhra" , FreeBSD Current Subject: Re: ntpd as ntpd user question Message-ID: <20180724201113.GA52627@www.zefox.net> References: <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> <87r2jtiw59.wl-herbert@gojira.at> <20180724015428.GB47869@www.zefox.net> <1532399159.1344.211.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:11:07 -0000 On Mon, Jul 23, 2018 at 09:28:41PM -0700, Kevin Oberman wrote: > On Mon, Jul 23, 2018 at 7:25 PM, Ian Lepore wrote: > > > On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > > > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > > > > > > > > > > > Yes, first you press m. Then you will see differences of installed > > > > file (left) and new file (right). Then you press either l or > > > > r: > > > > > > > > l | 1: choose left diff > > > > r | 2: choose right diff > > > > > > > > If the diff tries to remove/add to many lines you can: > > > > > > > > el: edit left diff > > > > er: edit right diff > > > > > > > > And if done you can view the merged file (v) before installing (i) > > > > it. > > > > > > > > I am sure, someone can explain it better! :) > > > > > > > Perhaps, but you've made the essential point. Your reply let me > > > understand that > > > mergemaster does not really "master" the merge, it rather identifies > > > files needing > > > to be merged and then starts sdiff to let me modify files. Never > > > having even looked > > > at sdiff, the learning curve proved very steep. Too steep, in fact. > > > > > > I'm going to try a more incremental approach. > > > > > > Thank you _very_ much! > > > > > > bob prohaska > > > > Your reaction to mergemaster is about the same as mine was when I first > > encountered it very long ago, and re-discovered when I tried it a > > couple years ago. It just seems like more trouble than it's worth, I > > can usually figure out what's broken and fix it by hand faster than > > messing with all the merge stuff. > > > > But, someone told me that if you give mergemaster the right flags it > > can potentially be intervention-free. Those apparently aren't the flag > > or two that're suggested at the bottom of UPDATING. So I didn't really > > dig into that any deeper, but I toss it out there in case someone can > > expand on it. > > > > It certainly makes some sense that it could be done intervention-free. > > When doing other diff-based merges (like 'svn update') you only have to > > intervene when there's an actual conflict between some local change > > you've made and the incoming changes. > > > > > It gets a LOT simpler if you use "mergemaster -iPUF" Only those files you > have modified will show up. In most cases, it just zips right by. In most > that it does not, the use of 'r' or 'l' in merge is all you need and always > 'r' eccepton lines you have modified, yourself, so you should know about > them. > I realize your comments are directed to Ian and not me, so please take these $.02 for no more than they're worth. My problems with mergemaster are _not_ with mergemaster. They're with sdiff. The window presented, along with the prompts, are simply bewildering. I suspect that someboey truly fluent with vi would recognize what's going on at once and have no trouble. I've used vi for a long time, but only in the most naive way, and sdiff's man page is little help for a newcomer. Even a Web search for tutorials found nothing very useful, at least not quickly. A plain language discription of what sdif does and how might make the minutia of the man page comprehensible to non-experts. Apologies if I'm belaboring the obvious, and thanks for reading! bob prohaska From owner-freebsd-current@freebsd.org Tue Jul 24 21:04:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83C9D1056245 for ; Tue, 24 Jul 2018 21:04:25 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 19500803CF; Tue, 24 Jul 2018 21:04:24 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fi4Tf-0004eT-J6; Tue, 24 Jul 2018 23:04:15 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Ian Lepore" , "Kevin Oberman" Cc: "bob prohaska" , "Herbert J. Skuhra" , "FreeBSD Current" Subject: Re: ntpd as ntpd user question References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> <87r2jtiw59.wl-herbert@gojira.at> <20180724015428.GB47869@www.zefox.net> <1532399159.1344.211.camel@freebsd.org> Date: Tue, 24 Jul 2018 23:04:16 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: d9b0ae15ee993d77aea4f0208a5c5b8c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 21:04:25 -0000 On Tue, 24 Jul 2018 06:28:41 +0200, Kevin Oberman wrote: > On Mon, Jul 23, 2018 at 7:25 PM, Ian Lepore wrote: > >> On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: >> > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: >> > > >> > > >> > > Yes, first you press m. Then you will see differences of installed >> > > file (left) and new file (right). Then you press either l or >> > > r: >> > > >> > > l | 1: choose left diff >> > > r | 2: choose right diff >> > > >> > > If the diff tries to remove/add to many lines you can: >> > > >> > > el: edit left diff >> > > er: edit right diff >> > > >> > > And if done you can view the merged file (v) before installing (i) >> > > it. >> > > >> > > I am sure, someone can explain it better! :) >> > > >> > Perhaps, but you've made the essential point. Your reply let me >> > understand that >> > mergemaster does not really "master" the merge, it rather identifies >> > files needing >> > to be merged and then starts sdiff to let me modify files. Never >> > having even looked >> > at sdiff, the learning curve proved very steep. Too steep, in fact. >> > >> > I'm going to try a more incremental approach. >> > >> > Thank you _very_ much! >> > >> > bob prohaska >> >> Your reaction to mergemaster is about the same as mine was when I first >> encountered it very long ago, and re-discovered when I tried it a >> couple years ago. It just seems like more trouble than it's worth, I >> can usually figure out what's broken and fix it by hand faster than >> messing with all the merge stuff. >> >> But, someone told me that if you give mergemaster the right flags it >> can potentially be intervention-free. Those apparently aren't the flag >> or two that're suggested at the bottom of UPDATING. So I didn't really >> dig into that any deeper, but I toss it out there in case someone can >> expand on it. >> >> It certainly makes some sense that it could be done intervention-free. >> When doing other diff-based merges (like 'svn update') you only have to >> intervene when there's an actual conflict between some local change >> you've made and the incoming changes. >> >> > It gets a LOT simpler if you use "mergemaster -iPUF" Only those files you > have modified will show up. In most cases, it just zips right by. In most > that it does not, the use of 'r' or 'l' in merge is all you need and > always > 'r' eccepton lines you have modified, yourself, so you should know about > them. > > I should note that 'U' does have a small "race" in it, so it i possible > to > get biten by it, but it is very unlikely. Has to do with multiple commits > that touch the same lines in the file in a timing that is out of sync > with > your running it. I use '-iPF' because I m paranoid. $ cat /etc/mergemaster.rc AUTO_INSTALL=yes AUTO_UPGRADE=yes COMP_CONFS=yes FREEBSD_ID=yes IGNORE_FILES='/etc/motd /etc/printcap' This helps me a lot. Cheers, Ronald. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Jul 25 05:53:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E945103F891 for ; Wed, 25 Jul 2018 05:53:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-22.consmr.mail.ne1.yahoo.com (sonic314-22.consmr.mail.ne1.yahoo.com [66.163.189.148]) (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 F206270E53 for ; Wed, 25 Jul 2018 05:53:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Pdj.OYkVM1mJ5TgeeAenZ9Vbk9g3buKhVt7d3bPkwlPm3iq6A3rxs9aFx_6E6yu HVjZHqYI_ISXSJw_sMAhQMr2a4CFjetXGnnkNFBcGfAdgSid3U3IiuV9r7mo7BwwSTJAwxOVj6iT qtGMkJ.We3Gpil32hZaUoPhgtVtkzKFL39Sac0kkfdj1PubRHRf0_6qsjVLIYHT4rUPGdydNi.2c v1yOxvSfsBqgjKec3wP4FkGWYboPGrqUeHD6t1O1AJfTU89y0QhSAJVqz1_Bj74KsNgVF2DDbQAx uASo19GnPBp6vb18Ad4pTdXm91NI_2qluWBM0FVovEXGEC2GtSb0lOXxrsELt9X2Oeh1xuzqaImP iZ7oInif9bfzVpV_joW8Z1P0QUwv8t9tsQ2sFyb9U5tdMDHwSTSGdesQOOYE9ISsx3HexJp3cgKH sT5iCK3cTmDprQPKm6W7_OzYTs656OMa.oAAxZdhoLBCHN1_X6wyiM.L4BgXTE_ODMfdJ8LJFtOv jQFn67HM7oPc1QK4Ny8tOJ81GM3TH1fan8_p7FyXR6OKk4.BXcVFyz9Fh_CwNE2HEVGihwL9IJPj 1_.F7FZp5b3E_BtOw35f3yeiXalwYWv1BlTfr9RqaJTNEgWJVwhVs7hWCu.BraysIjvJkXWFKpfx krnXhuniSRfVq8RFKawQaiZZyvqgXEs_PMZrXnkg15mkbvMmEECkLNSAZx5NHdIY1QBQSA2uiNB8 LfXXwJfml1L0_.GXvpg5TK6NGC1wMMOd_3DXkkrF2GyT9QqTes8GMeKSmN0vh.5Wk_UFNm09GAVi BxJASsLcyXCNLwEuVJIc59ky_PY9vbuIxvlT7UuG.kBQZ1UXXAm3K8yuZWgQrIgeurd.okqGzJSx VDIjmgcgRu.2RfBoMfGA0cO7_pCFsEk6i3AgJyB3733TO67apQKkX_QnpdGfCQOD8uAuA7lLci4D FyfGXae1lUStUyuxMWtMVu5Bd8esAwjs1vQK0WA_XY7Kzq8XChhhifOIuFk.VF15V6gngjJ_Y_AD gpaSqz6CWYl1kOcGsPxmAjGG8jObccJBYhAre19QBEUivjWUr2dmYoDqSu_jPHQf9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Wed, 25 Jul 2018 05:53:08 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp426.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 440f42d48b38fdde6d9ffcad46d849e2; Wed, 25 Jul 2018 05:32:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') Message-Id: Date: Tue, 24 Jul 2018 22:32:48 -0700 To: Konstantin Belousov , FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 05:53:10 -0000 https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText (head -r336573 after the prior 6596's -r336565 ): --- all_subdir_lib/ofed --- In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, from /workspace/src/contrib/ofed/librdmacm/acm.c:42: /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_init': /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer atomic_store(&lock->cnt, 0); ^ In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' if (atomic_fetch_add(&lock->cnt, 1) > 0) ^~ /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' if (atomic_fetch_sub(&lock->cnt, 1) > 1) ^~ . . . --- all_subdir_lib/ofed --- *** [acm.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for -r336700 ) still shows this type of error. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Jul 25 06:39:30 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B9561040AC8 for ; Wed, 25 Jul 2018 06:39:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 0135971F44 for ; Wed, 25 Jul 2018 06:39:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: U0wjPc4VM1l8lLhYqkQJUeJnbkOwL0y8uz831gVv0wFMUX8P7KCqQaZvkiCPfsY iupW8I0kbj2.fL4zMaFLkVoE809d4qg3a.LEWtX4_LOk.sYiOfM7kJDgIqzHcaEsktuas_69gFme LQkm3HEscgCZiTWUbvaq8xWk_nFIgk11irZ94yoeLhiUG4yt82_0O.oxedYJoUKIxGuTVtXRGuZN hZ6_SG5x0ipKqAFkvGj5CdgTE..dSklB5OJqlRjZebTOPXvy88QXzzGy9HmBMQugc6AJ1r8oZV3x bdY01Gs61IvRV7ZgKnEKpQhb4LvAlEqZWGLnFWcWZfFbBGkJmtUoPRWqWSzY3KV3FOCqNnKnOHI. lKrxwZYGAJk0ObPteDgab.gDo22QsZJuSGNhI37zR8yx2YnfLNywxoKq6KQyVrW5GlVs.Krz7NZi 8oI7P3qtuboUJeAvM62BQQwEQtD.xm5tJaF_QAfTx9e3AcU.7MunMU462RLi13iHIcG7Im1dF0VC H9mXFjWnhufZi0_cMfGiP8q48Y8FPkQOUZe2LseQJcBGqQpYQPv5YdhSw6e5oa1tK7HvRCh1s3YR CK1.DISMgZ1mQinzDc2GcngJxwNSiXG0VTrldY34dvJ7qQ0mO9mICp5EkkRmxbx56mOFaLOPUcnK lUSpwvSc8_8RvEeCMP6.rvsddYgZAharsP4cFTxDZJw7WIIu1Jsu0djoIvrtnvhmDbA8NRrvwztZ y7yZNK7BOhhnSR.jwe_FP5skSgu5ez8Aae.aTmpK1B_KTZrW.zsLVZDt_0DZeYbVzC9141ye4v7I hvTGCV5_pOJKYYP5f46hvYElXqCnjZDhJ56c8iukWV2X5cF4yyj5PPe4mf7LTu9yrDrTSqVSqzDN ..NZ8gV3AgxWb3TZwrty9J14Jm3CSYZh3UoP5.NJv6qd9ARJAlMVVqCbbCvowZW.u.MMpmutbjiS DIcCGbK85OSZEkzEBOQz9dEXz2V5p.jHPQEMi2JRt4xrDdht1Yii8OL8Cw_JaUqTQtwkQUppJYoE uK_oxD3WcR2M8zyr.Wn754KobFAHy0J8zrmZCeHwfl7PJ8vQew81.buHZAE63VezXtkjp Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 25 Jul 2018 06:39:23 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9fc224754d06040e512481562d5a345b; Wed, 25 Jul 2018 06:39:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: Date: Tue, 24 Jul 2018 23:39:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Konstantin Belousov , FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 06:39:30 -0000 On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText > (head -r336573 after the prior 6596's -r336565 ): >=20 > --- all_subdir_lib/ofed --- > In file included from = /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, > from /workspace/src/contrib/ofed/librdmacm/acm.c:42: > /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_init': > /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer > atomic_store(&lock->cnt, 0); > ^ > In file included from = /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: > /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': > /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' > if (atomic_fetch_add(&lock->cnt, 1) > 0) > ^~ > /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': > /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' > if (atomic_fetch_sub(&lock->cnt, 1) > 1) > ^~ > . . . > --- all_subdir_lib/ofed --- > *** [acm.o] Error code 1 >=20 >=20 > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( = for > -r336700 ) still shows this type of error. [I should have a subject with "head -r336568 through -r336570 . . .".] =46rom what I can tell looking around having something like: if (atomic_fetch_add(&lock->cnt, 1) > 0) involve a __atomic_fetch_add indicates that: /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h was in use instead of FreeBSD's stdatomic.h file. If this is right, then the issue may be tied to head -r335782 implicitly changing the order of the include file directory searching for builds via the devel/*-gcc . (I reverted -r335782 in my environment some time ago and have not run into this problem in my context so far.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Jul 25 08:12:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 573171043B12 for ; Wed, 25 Jul 2018 08:12:46 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDF4474529; Wed, 25 Jul 2018 08:12:45 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Ld1CS-1gQKsu03lo-00iBc2; Wed, 25 Jul 2018 09:59:40 +0200 Date: Wed, 25 Jul 2018 09:59:32 +0200 From: "O. Hartmann" To: Toomas Soome Cc: "O. Hartmann" , freebsd-current , Allan Jude Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180725095926.7d52a15a@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:bGBoexVi7l94+Uqp0jhoptI/zQY47kQmUEFmTShFH+AA8tv6M5S t2G0/SMG3XA6wjLk+SzhBTtDGuVv1Cbs5RriJybNDVTW5Z5OAbYxny3MQku61iSkAQ+o1eD wKgDaZAUORtybmSmFqkLcJf9XhzInC1QKq1qF0pFu/r0QyuGHIufJWV9WjemVgKBLjtD8Xy s1Im3DVQpAaDCAImKUp6g== X-UI-Out-Filterresults: notjunk:1;V01:K0:V+WmRumLWgw=:9Ep57N+aw8v/8IL08LzT8g 57XfnARUxW1J4/ylMfm7AQUIlU7xPtH85w677WC94fXt9zNUNgr4PyBmitzZm6EsqZBOtcEnr fGTRwlq9D5UukHpycIn39yMvTjChSHy8fZPXKwbhB7Zdb13pL1SX+W6iP3ePBT/ZshXLh+Npn SSPnlbGrdwKhns+luKGT45/e00/kxZwv4zKzhkkpVassoebV8yWNvSAb3Sshj7JAe+IJ4JEhV i3qugiLf7pCbHERcXFuIUMASxKNzwCObyNIKjqmDjkZZJQBHe0KPK9efFIRDlxEEh069nC/zt AOqzm3SzKvJV+j5+miR4EOb4aw/ckl7aKr73y2g56ZR9I6ffi+0BU7kVSdgv/JYkdOXXqntz8 ZkpDs1RlgRf2IQuvTpVAPsyUjTEfvC8/C5x5Owv7999Oe4Ej+R6nhTONryUWJf7vFI8ckGNy/ zAZMp+yLgq+k7x0PkXAKJod4wE9cpKkLn+M7WyrtP6KLdC8Vg6S3Q/gj5tUw2m1P63f5OUEgC zSO/+N39ZOdS87IyRd0oR8PqrdUvGoUUfd+dNbXIQa7IyNYy7YWPsyqI6Gf7BP+PLhxgxubLZ mG92GP3iDiErGrcvErfOzI2mtUQ5fZ6ByjfuIQJ8YjqFWDlL7UMkkR8nnGhnwBEDZ5HZyVVjh Bnn2vUVetQxpxI0ZDIKqC3Ms4MLv1gMXb9aY6oMopeZ4kTccd579WyB+SUMEUHKQXdYW9i7Ck 5NY7dHIVAnlw9Zx9A35/IxMNJ7NGolsrQ6VZAgzpc/L+NwUYQ00G17PtPAZtEkMv7wesqdNhG iR99BX7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 08:12:46 -0000 On Tue, 24 Jul 2018 08:53:36 +0300 Toomas Soome wrote: Hello Toomas Soome, I CC Allan Jude since I discovered something weird today regarding the UEFI boot capabilities of USB flash devices and SSDs. See below. =20 > > On 24 Jul 2018, at 08:16, O. Hartmann wrote: > >=20 > > On Mon, 23 Jul 2018 10:56:04 +0300 > > Toomas Soome wrote: > > =20 > >>> On 23 Jul 2018, at 10:27, O. Hartmann wrote: > >>>=20 > >>> On Fri, 13 Jul 2018 18:44:23 +0300 > >>> Toomas Soome > wrote: > >>> =20 > >>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>>> > wrote: > >>>>>=20 > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA512 > >>>>>=20 > >>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 > >>>>> Toomas Soome >>>>> >> schrieb: =20 > >>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann wr= ote: > >>>>>>>=20 > >>>>>>> The problem is some kind of weird. I face UEFI boot problems on G= PT > >>>>>>> drives where the first partition begins at block 40 of the hdd/ss= d. > >>>>>>>=20 > >>>>>>> I have two host in private use based on an > >>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Soc= ket > >>>>>>> LGA1155). Both boards are equipted with the lates official availa= ble > >>>>>>> AMI firmware revision, dating to 2013. This is for the Z77-Pro4-M > >>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 > >>>>>>> (2013/7/17). For both boards a BETA revision for the Spectre/Melt= down > >>>>>>> mitigation is available, but I didn't test that. But please read. > >>>>>>>=20 > >>>>>>> The third box I realised this problem is a brand new Fujitsu Espr= imo > >>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date > >>>>>>> 05/25/2018 (or 20180525). > >>>>>>>=20 > >>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall t= he OS > >>>>>>> using UEFI-only boot method on a GPT partitioned device fails. The > >>>>>>> ASRock boards jump immediately into the firmware, the Fujitsu off= ers > >>>>>>> some kind of CPU/Memory/HDD test facility. > >>>>>>>=20 > >>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot on= ly is > >>>>>>> implied, the MBR partitioned FreeBSD installation USB flash device > >>>>>>> does boot in UEFI! I guess I can assume this when the well known > >>>>>>> clumsy 80x25 char console suddenly gets bright and shiny with a m= uch > >>>>>>> higher resoltion as long the GPU supports EFI GOP. Looking with g= part > >>>>>>> at the USB flash drives reveals that the EFI partition starts at > >>>>>>> block 1 of the device and the device has a MBR layout. I haven't > >>>>>>> found a way to force the GPT scheme, when initialised via gpart, = to > >>>>>>> let the partitions start at block 1. This might be a naiv thinkin= g, > >>>>>>> so please be patient with me. > >>>>>>>=20 > >>>>>>> I do not know whether this is a well-known issue. On the ASRock > >>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI and > >>>>>>> that worked - FreeBSD not. I gave up on that that time. Now, havi= ng > >>>>>>> the very same issues with a new Fujitsu system, leaves me with the > >>>>>>> impression that FreeBSD's UEFI implementation might have problems= I'm > >>>>>>> not aware of. > >>>>>>>=20 > >>>>>>> Can someone shed some light onto this?=20 > >>>>>>> =20 > >>>>>>=20 > >>>>>> The first thing to check is if the secure boot is disabled. We do = not > >>>>>> support secure boot at all at this time. =20 > >>>>>=20 > >>>>> Secure boot is in every scenario disabled! > >>>>> =20 > >>>>>>=20 > >>>>>> If you have efi or bios version running - you can check from either > >>>>>> console variable value (it can have efi or vidconsole or comconsol= e) or > >>>>>> better yet, see if efi-version is set (show efi-version) - if > >>>>>> efi-version is not set, it is BIOS loader running. Another indirect > >>>>>> way is to see lsdev -v, with device paths present, it is uefi:) = =20 > >>>>>=20 > >>>>> What are you talking about? > >>>>> What is the point of entry - running system, loader? > >>>>>=20 > >>>>> sysct machdep.bootmethod: BIOS > >>>>>=20 > >>>>> This makes me quite sure that the system has booted via BIOS - as I= 'm > >>>>> sure since I've checked that many times. UEFI doesn't work on those > >>>>> systems with FreeBSD. I'm not sure antmore, but I tried also Window= s 7 > >>>>> on those mainboards booting via UEFI - and I might recall that they > >>>>> failed also. I also recall that there were issues with earlier UEFI > >>>>> versions regarding booting only Windows 8/8.1 - and nothing else, b= ut > >>>>> the fact that Linux worked confuses me a bit. > >>>>>=20 > >>>>> If this ASRock crap (never ever again this brand!) doesn't work at = all - > >>>>> who cares, I intend to purchase new server grade hardware. But the = more > >>>>> puzzling issue is with the Fujitsu, which I consider serious and fr= om > >>>>> the behaviour the Fujitsu failure looks exactly like the ASRock - > >>>>> Windows 7 works, RedHat 7.5 works (I assume I can trust the Firmware > >>>>> settings when I disable CSM support, that the Firmware will only > >>>>> EFI/UEFI capable loader? Or is there a ghosty override somwhere to = be > >>>>> expected?). Also on ASRock disabling CSM should ensure not booting a > >>>>> dual-bootstrap-capable system. This said, on the recent Fujitsu, it > >>>>> seems to boil down to a FreeBSD UEFI-firmware interaction problem, > >>>>> while the ASRock is still under suspicion to be broken by design. = =20 > >>>>>>=20 > >>>>>> GPT partitions can never start from disk absolute sector 1; this is > >>>>>> because at sector 0 there is MBR (for compatibility), sector 1 is = GPT > >>>>>> table and then sectors 2-33 have GPT partition table entries, so t= he > >>>>>> first possible data sector is 34 (absolute 34). Thats assuming 512B > >>>>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. =20 > >>>>>=20 > >>>>> Thanks for the explanation. That implies the installer did right, g= part > >>>>> did also right and therefore there must be an issue with the stuff > >>>>> located within the EFI partition? =20 > >>>>=20 > >>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BIOS > >>>> loader at all or not - that is, if the BIOS bootstrap is actually ca= ring > >>>> to read the MBR code and start it, since once the MBR code is starte= d, > >>>> it is all about our code. =20 > >>>=20 > >>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or do= you > >>> mean that specific portion of the UEFI firmware, which looks for the > >>> proper UEFI partition? > >>> =20 > >>=20 > >> BIOS as either native or CSM. Note that from boot code point of view t= he > >> CSM boot *is* BIOS boot, we have no access to UEFI features. > >> =20 > >>>=20 > >>> The boxes in question, most notably the more recent Fujitsu Esprimo Q= 956, > >>> refuse booting UEFI, even if properly setup (in terms of what FreeBSD > >>> provides on recent CURRENT) is applied and CSM is switched off in the > >>> firmware. Again: GPT partition scheme. > >>>=20 > >>> The system boots properly if a second partition of type "freebsd-boot= " is > >>> applied and bootcode is properly applied via "gpart bootcode -b /boot= /pmbr > >>> -p /boot/gptboot -i 2 ada0" (ada0 is the device). =20 > >>>>=20 > >>>> btw, you can try to validate the installed boot blocks by using rece= nt > >>>> enough loader (usb or iso) and then you can use from OK prompt: =20 > >>>=20 > >>> lsdev provides me with the follwoing informations (CSM enabled): > >>>=20 > >>> OK lsdev > >>> disk devices: > >>> disk0: BIOS DRIVE C ... > >>>=20 > >>> disk0p1: EFI > >>> disk0p2: FreeBSD BOOT > >>> disk0p3: FreeBSD SWAP > >>> disk0p4: FreeBSD ZFS > >>> zfs devices: > >>> zfs:zroot > >>>=20 > >>> OK chain disk0 > >>> open failed (so for disk0p{1-4}. > >>>=20 > >>> OK chain zroot > >>> failed to read disk (just for completeness) =20 > >>=20 > >>=20 > >> chain command does use only device name (such as disk0: or disk0p2: ),= but > >> not zfs pool as device. I just found I haven=E2=80=99t ported the cod= e to read the > >> file. =20 > >=20 > > ?? > > =20 > >>=20 > >> the point for chain command test is to see if the normal read and exec= ute > >> would work, so in your case please try: > >>=20 > >> chain disk0: =20 > >=20 > > As stated above, I did so, and the result is also mentioned above, I al= ways > > get "open failed". > > This is the same for=20 > >=20 > > chain disk0 > > chain disk0p1 > > chain disk0p2 > > chain disk0p3 > > chain disk0p4 > >=20 > > as already said. CSM is enabled in this case. =20 >=20 > sigh=E2=80=A6 chain command does take device as argument, device must alw= ays end with > colon=E2=80=A6. in this case, the devil is in details:) as I wrote above,= the command > should be: >=20 > chain disk0: >=20 > The disk0p1: etc will only work when partition boot code was installed (w= hich > you most likely do not have - the only possible candidate could be FreeBSD > ZFS partition). The command "chain disk0:" works as expected (CSM enabled, GPT partition scheme, but with PMBR bootblock installed and freebsd-boot partition conati= ning gptzfsboot installed. >=20 > > =20 > >>=20 > >> to read pmbr (512B) and execute it. The expected outcome would be that= pmbr > >> boot code would browse the GPT, read stage1 from disk0p2: and execute = it; > >> stage1 would detect FreeBSD ZFS from disk0p4: and load and > >> execute /boot/loader. If that will happen, it means the boot code in o= ur > >> stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6. = if thats > >> true, it would mean that you either need to use UEFI boot or need to h= ave > >> some hack to fool the BIOS or just not use GPT on that machine with CS= M. =20 > >=20 > > To make it clear here: The only way to boot this box is using CSM (as i= t is > > the same with the ASRock boards mentioned earlier). But my intention is= to > > disable CSM and use a GPT/UEFI environment only! And GPT/UEFI doesn't w= ork > > with FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG. > >=20 > > It would be nice if this could be fixed. I'm more interested in the fix= on > > the recent Fujitsu device than the outdated ASRock crap, but if the fix= for > > the Fujitsu Firmware could fix older issues as a byproduct, I'd appreci= ate > > that. > >=20 > > Kind regards, > > =20 >=20 > ok, somehow I have lost that part of the discussion. Well, you wrote that= the > UEFI boot fails when the first partition starts from sector 40 - does it = mean > you have boot when the partition will start from some other sector? I thi= nk, > there is something else going on. Well, I simply try to describe what I "see" to make things disambiguous. I'm not familiar with the deeper insights of disk layouts on a binary level. So, you explained to me the reason, why ESP (EGI partition) starts at block 40.= I compared that to the FreeBSD USB flash image FreeBSD provides, but this is another story since the image uses MBR scheme as I figured out. =20 >=20 > What you can do is to see if that firmware will offer you EFI shell optio= n, > from there you can try to start the bootx64.efi manually and see what err= or > you will get. However, the number 1 cause for failing to start the bootlo= ader > in UEFI is secure boot - we do not support it and secure boot must be > switched off.=20 >=20 > However, they seem to claim "The Secure Boot option is available in the > UEFI/BIOS of most if not all ASRock boards. It is disabled by default.=E2= =80=9D=20 >=20 > Still suggest to double check if thats really the case. Also, if the > bootx64.efi start will fail and no messages are appearing on screen, then > either there is something in firmware logs or you could get them from try= ing > to start bootx64.efi from UEFI shell. Since I'm with this problem since 2014 and try from time to time, be ausred that I tried every possible permutationof all reasonable options, even those nonsense, to get rid of that problem. I never had any problems with any other UEFI capable server/workstation firmware so far booting FreeBSD off in UEFI-native (GPT partition scheme, C= SM disabled) so far - until now, when I ran into this Fujitsu ESPRIMO Q956 with the most recent firmware (as of lat week, week 29 of 2018) having the very = same problems.=20 I figured out something strange on the Fujitsu - and that is the same with = the ASRock boards. We/I prepare some USB flash drives to boot a NanoBSD for a very small appliance, but nevertheless, the USB flash device is booted on Fujitsu serv= ers with UEFI-only configurations. I assume at this point that disabling on the most recent Fujitsu firmwares on reasonable "new" hardware (not older than three years) will disable any(!) legacy BIOS capabilities. The same is assu= med for the Fujitus ESPRIMO Q956. I can not speak for the ASRock A77 Pro4/m boa= rds mentioned above/earlier, they are from 2012/2013 and "quite old". The NanoBSD image of ours doesn't have a "freebsd-boot" partition. The partition scheme of the flash device is GPT. The layout looks like this: gpart show -l da4 =3D> 40 15425456 da4 GPT (7.4G) 40 2000 1 efiboot0 (1.0M) 2040 1453584 3 disk1a (710M) 1455624 4096 5 disk3 (2.0M) 1459720 13965776 - free - (6.7G) I created the flash with md, gpart and dd straightforward, efiboot0 is the = ESP partition and its format/content is created via dd if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is very simple. This USB flash device boots(!) successfully (UEFI!) on both the ASRock boar= ds and the Esprimo Q956! But any SSD prepared the same way doesn't. Why?=20 On the ASRock, I recall having fiddled around with HDD also for a while conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - I can't remember.=20 In the lack of proper hardware I'm unable to check whether USB-attached HDD= or SSD will boot or HDD will boot (just in case the local SATA has problems booting UEFI and USB not). Kind regards, Oliver=20 >=20 > thds, > toomas [...] From owner-freebsd-current@freebsd.org Wed Jul 25 08:46:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 484FA1044764 for ; Wed, 25 Jul 2018 08:46:20 +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 E6CC7751C8; Wed, 25 Jul 2018 08:46:19 +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 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCE00G00YUVZF00@st13p35im-asmtp002.me.com>; Wed, 25 Jul 2018 08:46:12 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCE001G6Z0VX350@st13p35im-asmtp002.me.com>; Wed, 25 Jul 2018 08:46:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-25_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807250097 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations From: Toomas Soome In-reply-to: <20180725095926.7d52a15a@freyja.zeit4.iv.bundesimmobilien.de> Date: Wed, 25 Jul 2018 11:46:07 +0300 Cc: freebsd-current , Allan Jude Content-transfer-encoding: quoted-printable Message-id: <2FCF2BCC-05E5-466A-B1AE-90300990ED1A@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> <20180725095926.7d52a15a@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 08:46:20 -0000 > On 25 Jul 2018, at 10:59, O. Hartmann wrote: >=20 > On Tue, 24 Jul 2018 08:53:36 +0300 > Toomas Soome wrote: >=20 >=20 > Hello Toomas Soome, >=20 > I CC Allan Jude since I discovered something weird today regarding = the UEFI > boot capabilities of USB flash devices and SSDs. See below. >=20 >>> On 24 Jul 2018, at 08:16, O. Hartmann = wrote: >>>=20 >>> On Mon, 23 Jul 2018 10:56:04 +0300 >>> Toomas Soome wrote: >>>=20 >>>>> On 23 Jul 2018, at 10:27, O. Hartmann = wrote: >>>>>=20 >>>>> On Fri, 13 Jul 2018 18:44:23 +0300 >>>>> Toomas Soome > wrote: >>>>>=20 >>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>>>> > wrote: >>>>>>>=20 >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA512 >>>>>>>=20 >>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 >>>>>>> Toomas Soome = >>>>>> >> schrieb: =20 >>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann = wrote: >>>>>>>>>=20 >>>>>>>>> The problem is some kind of weird. I face UEFI boot problems = on GPT >>>>>>>>> drives where the first partition begins at block 40 of the = hdd/ssd. >>>>>>>>>=20 >>>>>>>>> I have two host in private use based on an >>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, = Socket >>>>>>>>> LGA1155). Both boards are equipted with the lates official = available >>>>>>>>> AMI firmware revision, dating to 2013. This is for the = Z77-Pro4-M >>>>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 >>>>>>>>> (2013/7/17). For both boards a BETA revision for the = Spectre/Meltdown >>>>>>>>> mitigation is available, but I didn't test that. But please = read. >>>>>>>>>=20 >>>>>>>>> The third box I realised this problem is a brand new Fujitsu = Esprimo >>>>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, = date >>>>>>>>> 05/25/2018 (or 20180525). >>>>>>>>>=20 >>>>>>>>> Installing on any kind of HDD or SSD manually or via = bsdinstall the OS >>>>>>>>> using UEFI-only boot method on a GPT partitioned device fails. = The >>>>>>>>> ASRock boards jump immediately into the firmware, the Fujitsu = offers >>>>>>>>> some kind of CPU/Memory/HDD test facility. >>>>>>>>>=20 >>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot = only is >>>>>>>>> implied, the MBR partitioned FreeBSD installation USB flash = device >>>>>>>>> does boot in UEFI! I guess I can assume this when the well = known >>>>>>>>> clumsy 80x25 char console suddenly gets bright and shiny with = a much >>>>>>>>> higher resoltion as long the GPU supports EFI GOP. Looking = with gpart >>>>>>>>> at the USB flash drives reveals that the EFI partition starts = at >>>>>>>>> block 1 of the device and the device has a MBR layout. I = haven't >>>>>>>>> found a way to force the GPT scheme, when initialised via = gpart, to >>>>>>>>> let the partitions start at block 1. This might be a naiv = thinking, >>>>>>>>> so please be patient with me. >>>>>>>>>=20 >>>>>>>>> I do not know whether this is a well-known issue. On the = ASRock >>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI = and >>>>>>>>> that worked - FreeBSD not. I gave up on that that time. Now, = having >>>>>>>>> the very same issues with a new Fujitsu system, leaves me with = the >>>>>>>>> impression that FreeBSD's UEFI implementation might have = problems I'm >>>>>>>>> not aware of. >>>>>>>>>=20 >>>>>>>>> Can someone shed some light onto this?=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The first thing to check is if the secure boot is disabled. We = do not >>>>>>>> support secure boot at all at this time. =20 >>>>>>>=20 >>>>>>> Secure boot is in every scenario disabled! >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If you have efi or bios version running - you can check from = either >>>>>>>> console variable value (it can have efi or vidconsole or = comconsole) or >>>>>>>> better yet, see if efi-version is set (show efi-version) - if >>>>>>>> efi-version is not set, it is BIOS loader running. Another = indirect >>>>>>>> way is to see lsdev -v, with device paths present, it is uefi:) = =20 >>>>>>>=20 >>>>>>> What are you talking about? >>>>>>> What is the point of entry - running system, loader? >>>>>>>=20 >>>>>>> sysct machdep.bootmethod: BIOS >>>>>>>=20 >>>>>>> This makes me quite sure that the system has booted via BIOS - = as I'm >>>>>>> sure since I've checked that many times. UEFI doesn't work on = those >>>>>>> systems with FreeBSD. I'm not sure antmore, but I tried also = Windows 7 >>>>>>> on those mainboards booting via UEFI - and I might recall that = they >>>>>>> failed also. I also recall that there were issues with earlier = UEFI >>>>>>> versions regarding booting only Windows 8/8.1 - and nothing = else, but >>>>>>> the fact that Linux worked confuses me a bit. >>>>>>>=20 >>>>>>> If this ASRock crap (never ever again this brand!) doesn't work = at all - >>>>>>> who cares, I intend to purchase new server grade hardware. But = the more >>>>>>> puzzling issue is with the Fujitsu, which I consider serious and = from >>>>>>> the behaviour the Fujitsu failure looks exactly like the ASRock = - >>>>>>> Windows 7 works, RedHat 7.5 works (I assume I can trust the = Firmware >>>>>>> settings when I disable CSM support, that the Firmware will only >>>>>>> EFI/UEFI capable loader? Or is there a ghosty override somwhere = to be >>>>>>> expected?). Also on ASRock disabling CSM should ensure not = booting a >>>>>>> dual-bootstrap-capable system. This said, on the recent Fujitsu, = it >>>>>>> seems to boil down to a FreeBSD UEFI-firmware interaction = problem, >>>>>>> while the ASRock is still under suspicion to be broken by = design. =20 >>>>>>>>=20 >>>>>>>> GPT partitions can never start from disk absolute sector 1; = this is >>>>>>>> because at sector 0 there is MBR (for compatibility), sector 1 = is GPT >>>>>>>> table and then sectors 2-33 have GPT partition table entries, = so the >>>>>>>> first possible data sector is 34 (absolute 34). Thats assuming = 512B >>>>>>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. =20= >>>>>>>=20 >>>>>>> Thanks for the explanation. That implies the installer did = right, gpart >>>>>>> did also right and therefore there must be an issue with the = stuff >>>>>>> located within the EFI partition? =20 >>>>>>=20 >>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach = BIOS >>>>>> loader at all or not - that is, if the BIOS bootstrap is actually = caring >>>>>> to read the MBR code and start it, since once the MBR code is = started, >>>>>> it is all about our code. =20 >>>>>=20 >>>>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or = do you >>>>> mean that specific portion of the UEFI firmware, which looks for = the >>>>> proper UEFI partition? >>>>>=20 >>>>=20 >>>> BIOS as either native or CSM. Note that from boot code point of = view the >>>> CSM boot *is* BIOS boot, we have no access to UEFI features. >>>>=20 >>>>>=20 >>>>> The boxes in question, most notably the more recent Fujitsu = Esprimo Q956, >>>>> refuse booting UEFI, even if properly setup (in terms of what = FreeBSD >>>>> provides on recent CURRENT) is applied and CSM is switched off in = the >>>>> firmware. Again: GPT partition scheme. >>>>>=20 >>>>> The system boots properly if a second partition of type = "freebsd-boot" is >>>>> applied and bootcode is properly applied via "gpart bootcode -b = /boot/pmbr >>>>> -p /boot/gptboot -i 2 ada0" (ada0 is the device). =20 >>>>>>=20 >>>>>> btw, you can try to validate the installed boot blocks by using = recent >>>>>> enough loader (usb or iso) and then you can use from OK prompt: = =20 >>>>>=20 >>>>> lsdev provides me with the follwoing informations (CSM enabled): >>>>>=20 >>>>> OK lsdev >>>>> disk devices: >>>>> disk0: BIOS DRIVE C ... >>>>>=20 >>>>> disk0p1: EFI >>>>> disk0p2: FreeBSD BOOT >>>>> disk0p3: FreeBSD SWAP >>>>> disk0p4: FreeBSD ZFS >>>>> zfs devices: >>>>> zfs:zroot >>>>>=20 >>>>> OK chain disk0 >>>>> open failed (so for disk0p{1-4}. >>>>>=20 >>>>> OK chain zroot >>>>> failed to read disk (just for completeness) =20 >>>>=20 >>>>=20 >>>> chain command does use only device name (such as disk0: or disk0p2: = ), but >>>> not zfs pool as device. I just found I haven=E2=80=99t ported the = code to read the >>>> file. =20 >>>=20 >>> ?? >>>=20 >>>>=20 >>>> the point for chain command test is to see if the normal read and = execute >>>> would work, so in your case please try: >>>>=20 >>>> chain disk0: =20 >>>=20 >>> As stated above, I did so, and the result is also mentioned above, I = always >>> get "open failed". >>> This is the same for=20 >>>=20 >>> chain disk0 >>> chain disk0p1 >>> chain disk0p2 >>> chain disk0p3 >>> chain disk0p4 >>>=20 >>> as already said. CSM is enabled in this case. =20 >>=20 >> sigh=E2=80=A6 chain command does take device as argument, device must = always end with >> colon=E2=80=A6. in this case, the devil is in details:) as I wrote = above, the command >> should be: >>=20 >> chain disk0: >>=20 >> The disk0p1: etc will only work when partition boot code was = installed (which >> you most likely do not have - the only possible candidate could be = FreeBSD >> ZFS partition). >=20 > The command "chain disk0:" works as expected (CSM enabled, GPT = partition > scheme, but with PMBR bootblock installed and freebsd-boot partition = conatining > gptzfsboot installed. >=20 >=20 >>=20 >>>=20 >>>>=20 >>>> to read pmbr (512B) and execute it. The expected outcome would be = that pmbr >>>> boot code would browse the GPT, read stage1 from disk0p2: and = execute it; >>>> stage1 would detect FreeBSD ZFS from disk0p4: and load and >>>> execute /boot/loader. If that will happen, it means the boot code = in our >>>> stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6. = if thats >>>> true, it would mean that you either need to use UEFI boot or need = to have >>>> some hack to fool the BIOS or just not use GPT on that machine with = CSM. =20 >>>=20 >>> To make it clear here: The only way to boot this box is using CSM = (as it is >>> the same with the ASRock boards mentioned earlier). But my intention = is to >>> disable CSM and use a GPT/UEFI environment only! And GPT/UEFI = doesn't work >>> with FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG. >>>=20 >>> It would be nice if this could be fixed. I'm more interested in the = fix on >>> the recent Fujitsu device than the outdated ASRock crap, but if the = fix for >>> the Fujitsu Firmware could fix older issues as a byproduct, I'd = appreciate >>> that. >>>=20 >>> Kind regards, >>>=20 >>=20 >> ok, somehow I have lost that part of the discussion. Well, you wrote = that the >> UEFI boot fails when the first partition starts from sector 40 - does = it mean >> you have boot when the partition will start from some other sector? I = think, >> there is something else going on. >=20 > Well, I simply try to describe what I "see" to make things = disambiguous. I'm > not familiar with the deeper insights of disk layouts on a binary = level. So, > you explained to me the reason, why ESP (EGI partition) starts at = block 40. I > compared that to the FreeBSD USB flash image FreeBSD provides, but = this is > another story since the image uses MBR scheme as I figured out. >=20 >=20 >>=20 >> What you can do is to see if that firmware will offer you EFI shell = option, >> from there you can try to start the bootx64.efi manually and see what = error >> you will get. However, the number 1 cause for failing to start the = bootloader >> in UEFI is secure boot - we do not support it and secure boot must be >> switched off.=20 >>=20 >> However, they seem to claim "The Secure Boot option is available in = the >> UEFI/BIOS of most if not all ASRock boards. It is disabled by = default.=E2=80=9D=20 >>=20 >> Still suggest to double check if thats really the case. Also, if the >> bootx64.efi start will fail and no messages are appearing on screen, = then >> either there is something in firmware logs or you could get them from = trying >> to start bootx64.efi from UEFI shell. >=20 > Since I'm with this problem since 2014 and try from time to time, be = ausred > that I tried every possible permutationof all reasonable options, even = those > nonsense, to get rid of that problem. >=20 > I never had any problems with any other UEFI capable = server/workstation > firmware so far booting FreeBSD off in UEFI-native (GPT partition = scheme, CSM > disabled) so far - until now, when I ran into this Fujitsu ESPRIMO = Q956 with > the most recent firmware (as of lat week, week 29 of 2018) having the = very same > problems.=20 >=20 >=20 >=20 > I figured out something strange on the Fujitsu - and that is the same = with the > ASRock boards. >=20 > We/I prepare some USB flash drives to boot a NanoBSD for a very small > appliance, but nevertheless, the USB flash device is booted on Fujitsu = servers > with UEFI-only configurations. I assume at this point that disabling = on the > most recent Fujitsu firmwares on reasonable "new" hardware (not older = than > three years) will disable any(!) legacy BIOS capabilities. The same is = assumed > for the Fujitus ESPRIMO Q956. I can not speak for the ASRock A77 = Pro4/m boards > mentioned above/earlier, they are from 2012/2013 and "quite old". >=20 > The NanoBSD image of ours doesn't have a "freebsd-boot" partition. The > partition scheme of the flash device is GPT. The layout looks like = this: >=20 > gpart show -l da4 > =3D> 40 15425456 da4 GPT (7.4G) > 40 2000 1 efiboot0 (1.0M) > 2040 1453584 3 disk1a (710M) > 1455624 4096 5 disk3 (2.0M) > 1459720 13965776 - free - (6.7G) >=20 > I created the flash with md, gpart and dd straightforward, efiboot0 is = the ESP > partition and its format/content is created via dd = if=3D/boot/boot1.efifat > of=3D/dev/da4p1 - I presume this is very simple. >=20 > This USB flash device boots(!) successfully (UEFI!) on both the ASRock = boards > and the Esprimo Q956! >=20 > But any SSD prepared the same way doesn't. Why?=20 >=20 > On the ASRock, I recall having fiddled around with HDD also for a = while > conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - I = can't > remember.=20 >=20 > In the lack of proper hardware I'm unable to check whether = USB-attached HDD or > SSD will boot or HDD will boot (just in case the local SATA has = problems > booting UEFI and USB not). >=20 > Kind regards, >=20 > Oliver=20 >=20 Am. well. I think the suggestion to test out FAT32 is still good one to = test. This is because it is known that some vendors do not support = booting FAT12/FAT16 from HDD (the likely reason is that UEFI = specification does not tell which FAT must be supported, and only hint = about FAT12/FAT16 in context of removable devices). There are other possible causes too, for example: = https://ubuntuforums.org/showthread.php?t=3D2147295=20 Also about the ESP sizes: https://www.ctrl.blog/entry/esp-size-guide "The UEFI System Partition should be at least 260 MiB (273 MB) to ensure = its properly formatted with FAT32 so that you avoid UEFI implementation = compatibility issues. (If you do have incompatible hardware that = requires FAT16-formatting, then I suggest you move aside the files on = the UEFI System Partition, convert the partition to FAT16, and copy the = files back over to it.)=E2=80=9D So, as you see, even just telling =E2=80=9Cuse FAT32=E2=80=9D is not = universal medicine, but I suspect it is still more universal than using = FAT12/FAT16:) Just to be clear, there is *no* standard size rule for ESP, there are = only suggestions from vendors=E2=80=A6=20 Yes, this all means that if the solution from default installer does not = work, the manual work is needed to identify why the default is not = working and the findings should be reported, so the installer (and = possibly other parts of the system) could be adjusted. Since this all is = vendor specific, it has to be handled case by case. rgds, toomas From owner-freebsd-current@freebsd.org Wed Jul 25 09:26:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAD0510457D5 for ; Wed, 25 Jul 2018 09:26:26 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 6D991765DC; Wed, 25 Jul 2018 09:26:26 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCF008000IUX000@st13p35im-asmtp001.me.com>; Wed, 25 Jul 2018 09:26:19 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCF004JG0VPHD40@st13p35im-asmtp001.me.com>; Wed, 25 Jul 2018 09:26:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-25_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807250104 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations From: Toomas Soome In-reply-to: <20180725111032.1632b885@freyja.zeit4.iv.bundesimmobilien.de> Date: Wed, 25 Jul 2018 12:26:13 +0300 Cc: freebsd-current , Allan Jude Content-transfer-encoding: quoted-printable Message-id: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> <20180725095926.7d52a15a@freyja.zeit4.iv.bundesimmobilien.de> <2FCF2BCC-05E5-466A-B1AE-90300990ED1A@me.com> <20180725111032.1632b885@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 09:26:27 -0000 > On 25 Jul 2018, at 12:10, O. Hartmann wrote: >=20 > On Wed, 25 Jul 2018 11:46:07 +0300 > Toomas Soome wrote: >=20 >>> On 25 Jul 2018, at 10:59, O. Hartmann = wrote: >>>=20 >>> On Tue, 24 Jul 2018 08:53:36 +0300 >>> Toomas Soome wrote: >>>=20 >>>=20 >>> Hello Toomas Soome, >>>=20 >>> I CC Allan Jude since I discovered something weird today regarding = the UEFI >>> boot capabilities of USB flash devices and SSDs. See below. >>>=20 >>>>> On 24 Jul 2018, at 08:16, O. Hartmann = wrote: >>>>>=20 >>>>> On Mon, 23 Jul 2018 10:56:04 +0300 >>>>> Toomas Soome wrote: >>>>>=20 >>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann = wrote: >>>>>>>=20 >>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 >>>>>>> Toomas Soome > wrote: >>>>>>>=20 >>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>> Hash: SHA512 >>>>>>>>>=20 >>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 >>>>>>>>> Toomas Soome >>>>>>>>> >> schrieb: =20 >>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann = >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> The problem is some kind of weird. I face UEFI boot problems = on GPT >>>>>>>>>>> drives where the first partition begins at block 40 of the = hdd/ssd. >>>>>>>>>>>=20 >>>>>>>>>>> I have two host in private use based on an >>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard = (IvyBridge, Socket >>>>>>>>>>> LGA1155). Both boards are equipted with the lates official = available >>>>>>>>>>> AMI firmware revision, dating to 2013. This is for the = Z77-Pro4-M >>>>>>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 >>>>>>>>>>> (2013/7/17). For both boards a BETA revision for the >>>>>>>>>>> Spectre/Meltdown mitigation is available, but I didn't test = that. >>>>>>>>>>> But please read. >>>>>>>>>>>=20 >>>>>>>>>>> The third box I realised this problem is a brand new Fujitsu = Esprimo >>>>>>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, = date >>>>>>>>>>> 05/25/2018 (or 20180525). >>>>>>>>>>>=20 >>>>>>>>>>> Installing on any kind of HDD or SSD manually or via = bsdinstall the >>>>>>>>>>> OS using UEFI-only boot method on a GPT partitioned device = fails. >>>>>>>>>>> The ASRock boards jump immediately into the firmware, the = Fujitsu >>>>>>>>>>> offers some kind of CPU/Memory/HDD test facility. >>>>>>>>>>>=20 >>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI = boot only >>>>>>>>>>> is implied, the MBR partitioned FreeBSD installation USB = flash >>>>>>>>>>> device does boot in UEFI! I guess I can assume this when the = well >>>>>>>>>>> known clumsy 80x25 char console suddenly gets bright and = shiny with >>>>>>>>>>> a much higher resoltion as long the GPU supports EFI GOP. = Looking >>>>>>>>>>> with gpart at the USB flash drives reveals that the EFI = partition >>>>>>>>>>> starts at block 1 of the device and the device has a MBR = layout. I >>>>>>>>>>> haven't found a way to force the GPT scheme, when = initialised via >>>>>>>>>>> gpart, to let the partitions start at block 1. This might be = a naiv >>>>>>>>>>> thinking, so please be patient with me. >>>>>>>>>>>=20 >>>>>>>>>>> I do not know whether this is a well-known issue. On the = ASRock >>>>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with = UEFI and >>>>>>>>>>> that worked - FreeBSD not. I gave up on that that time. Now, = having >>>>>>>>>>> the very same issues with a new Fujitsu system, leaves me = with the >>>>>>>>>>> impression that FreeBSD's UEFI implementation might have = problems >>>>>>>>>>> I'm not aware of. >>>>>>>>>>>=20 >>>>>>>>>>> Can someone shed some light onto this?=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The first thing to check is if the secure boot is disabled. = We do not >>>>>>>>>> support secure boot at all at this time. =20 >>>>>>>>>=20 >>>>>>>>> Secure boot is in every scenario disabled! >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> If you have efi or bios version running - you can check from = either >>>>>>>>>> console variable value (it can have efi or vidconsole or = comconsole) >>>>>>>>>> or better yet, see if efi-version is set (show efi-version) - = if >>>>>>>>>> efi-version is not set, it is BIOS loader running. Another = indirect >>>>>>>>>> way is to see lsdev -v, with device paths present, it is >>>>>>>>>> uefi:) =20 >>>>>>>>>=20 >>>>>>>>> What are you talking about? >>>>>>>>> What is the point of entry - running system, loader? >>>>>>>>>=20 >>>>>>>>> sysct machdep.bootmethod: BIOS >>>>>>>>>=20 >>>>>>>>> This makes me quite sure that the system has booted via BIOS - = as I'm >>>>>>>>> sure since I've checked that many times. UEFI doesn't work on = those >>>>>>>>> systems with FreeBSD. I'm not sure antmore, but I tried also = Windows 7 >>>>>>>>> on those mainboards booting via UEFI - and I might recall that = they >>>>>>>>> failed also. I also recall that there were issues with earlier = UEFI >>>>>>>>> versions regarding booting only Windows 8/8.1 - and nothing = else, but >>>>>>>>> the fact that Linux worked confuses me a bit. >>>>>>>>>=20 >>>>>>>>> If this ASRock crap (never ever again this brand!) doesn't = work at >>>>>>>>> all - who cares, I intend to purchase new server grade = hardware. But >>>>>>>>> the more puzzling issue is with the Fujitsu, which I consider = serious >>>>>>>>> and from the behaviour the Fujitsu failure looks exactly like = the >>>>>>>>> ASRock - Windows 7 works, RedHat 7.5 works (I assume I can = trust the >>>>>>>>> Firmware settings when I disable CSM support, that the = Firmware will >>>>>>>>> only EFI/UEFI capable loader? Or is there a ghosty override = somwhere >>>>>>>>> to be expected?). Also on ASRock disabling CSM should ensure = not >>>>>>>>> booting a dual-bootstrap-capable system. This said, on the = recent >>>>>>>>> Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware = interaction >>>>>>>>> problem, while the ASRock is still under suspicion to be = broken by >>>>>>>>> design. =20 >>>>>>>>>>=20 >>>>>>>>>> GPT partitions can never start from disk absolute sector 1; = this is >>>>>>>>>> because at sector 0 there is MBR (for compatibility), sector = 1 is GPT >>>>>>>>>> table and then sectors 2-33 have GPT partition table entries, = so the >>>>>>>>>> first possible data sector is 34 (absolute 34). Thats = assuming 512B >>>>>>>>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. = =20 >>>>>>>>>=20 >>>>>>>>> Thanks for the explanation. That implies the installer did = right, >>>>>>>>> gpart did also right and therefore there must be an issue with = the >>>>>>>>> stuff located within the EFI partition? =20 >>>>>>>>=20 >>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach = BIOS >>>>>>>> loader at all or not - that is, if the BIOS bootstrap is = actually >>>>>>>> caring to read the MBR code and start it, since once the MBR = code is >>>>>>>> started, it is all about our code. =20 >>>>>>>=20 >>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? = or do >>>>>>> you mean that specific portion of the UEFI firmware, which looks = for the >>>>>>> proper UEFI partition? >>>>>>>=20 >>>>>>=20 >>>>>> BIOS as either native or CSM. Note that from boot code point of = view the >>>>>> CSM boot *is* BIOS boot, we have no access to UEFI features. >>>>>>=20 >>>>>>>=20 >>>>>>> The boxes in question, most notably the more recent Fujitsu = Esprimo >>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms of = what >>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is = switched off >>>>>>> in the firmware. Again: GPT partition scheme. >>>>>>>=20 >>>>>>> The system boots properly if a second partition of type = "freebsd-boot" >>>>>>> is applied and bootcode is properly applied via "gpart bootcode >>>>>>> -b /boot/pmbr -p /boot/gptboot -i 2 ada0" (ada0 is the device). = =20 >>>>>>>>=20 >>>>>>>> btw, you can try to validate the installed boot blocks by using = recent >>>>>>>> enough loader (usb or iso) and then you can use from OK prompt: = =20 >>>>>>>=20 >>>>>>> lsdev provides me with the follwoing informations (CSM enabled): >>>>>>>=20 >>>>>>> OK lsdev >>>>>>> disk devices: >>>>>>> disk0: BIOS DRIVE C ... >>>>>>>=20 >>>>>>> disk0p1: EFI >>>>>>> disk0p2: FreeBSD BOOT >>>>>>> disk0p3: FreeBSD SWAP >>>>>>> disk0p4: FreeBSD ZFS >>>>>>> zfs devices: >>>>>>> zfs:zroot >>>>>>>=20 >>>>>>> OK chain disk0 >>>>>>> open failed (so for disk0p{1-4}. >>>>>>>=20 >>>>>>> OK chain zroot >>>>>>> failed to read disk (just for completeness) =20 >>>>>>=20 >>>>>>=20 >>>>>> chain command does use only device name (such as disk0: or = disk0p2: ), >>>>>> but not zfs pool as device. I just found I haven=E2=80=99t = ported the code to >>>>>> read the file. =20 >>>>>=20 >>>>> ?? >>>>>=20 >>>>>>=20 >>>>>> the point for chain command test is to see if the normal read and = execute >>>>>> would work, so in your case please try: >>>>>>=20 >>>>>> chain disk0: =20 >>>>>=20 >>>>> As stated above, I did so, and the result is also mentioned above, = I >>>>> always get "open failed". >>>>> This is the same for=20 >>>>>=20 >>>>> chain disk0 >>>>> chain disk0p1 >>>>> chain disk0p2 >>>>> chain disk0p3 >>>>> chain disk0p4 >>>>>=20 >>>>> as already said. CSM is enabled in this case. =20 >>>>=20 >>>> sigh=E2=80=A6 chain command does take device as argument, device = must always end >>>> with colon=E2=80=A6. in this case, the devil is in details:) as I = wrote above, the >>>> command should be: >>>>=20 >>>> chain disk0: >>>>=20 >>>> The disk0p1: etc will only work when partition boot code was = installed >>>> (which you most likely do not have - the only possible candidate = could be >>>> FreeBSD ZFS partition). =20 >>>=20 >>> The command "chain disk0:" works as expected (CSM enabled, GPT = partition >>> scheme, but with PMBR bootblock installed and freebsd-boot partition >>> conatining gptzfsboot installed. >>>=20 >>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> to read pmbr (512B) and execute it. The expected outcome would be = that >>>>>> pmbr boot code would browse the GPT, read stage1 from disk0p2: = and >>>>>> execute it; stage1 would detect FreeBSD ZFS from disk0p4: and = load and >>>>>> execute /boot/loader. If that will happen, it means the boot code = in our >>>>>> stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6= . if thats >>>>>> true, it would mean that you either need to use UEFI boot or need = to have >>>>>> some hack to fool the BIOS or just not use GPT on that machine = with >>>>>> CSM. =20 >>>>>=20 >>>>> To make it clear here: The only way to boot this box is using CSM = (as it >>>>> is the same with the ASRock boards mentioned earlier). But my = intention >>>>> is to disable CSM and use a GPT/UEFI environment only! And = GPT/UEFI >>>>> doesn't work with FreeBSD, neither with 12-CURRENT, nor = 11.2-RELENG. >>>>>=20 >>>>> It would be nice if this could be fixed. I'm more interested in = the fix on >>>>> the recent Fujitsu device than the outdated ASRock crap, but if = the fix >>>>> for the Fujitsu Firmware could fix older issues as a byproduct, = I'd >>>>> appreciate that. >>>>>=20 >>>>> Kind regards, >>>>>=20 >>>>=20 >>>> ok, somehow I have lost that part of the discussion. Well, you = wrote that >>>> the UEFI boot fails when the first partition starts from sector 40 = - does >>>> it mean you have boot when the partition will start from some other >>>> sector? I think, there is something else going on. =20 >>>=20 >>> Well, I simply try to describe what I "see" to make things = disambiguous. I'm >>> not familiar with the deeper insights of disk layouts on a binary = level. So, >>> you explained to me the reason, why ESP (EGI partition) starts at = block 40. >>> I compared that to the FreeBSD USB flash image FreeBSD provides, but = this is >>> another story since the image uses MBR scheme as I figured out. >>>=20 >>>=20 >>>>=20 >>>> What you can do is to see if that firmware will offer you EFI shell = option, >>>> from there you can try to start the bootx64.efi manually and see = what error >>>> you will get. However, the number 1 cause for failing to start the >>>> bootloader in UEFI is secure boot - we do not support it and secure = boot >>>> must be switched off.=20 >>>>=20 >>>> However, they seem to claim "The Secure Boot option is available in = the >>>> UEFI/BIOS of most if not all ASRock boards. It is disabled by = default.=E2=80=9D=20 >>>>=20 >>>> Still suggest to double check if thats really the case. Also, if = the >>>> bootx64.efi start will fail and no messages are appearing on = screen, then >>>> either there is something in firmware logs or you could get them = from >>>> trying to start bootx64.efi from UEFI shell. =20 >>>=20 >>> Since I'm with this problem since 2014 and try from time to time, be = ausred >>> that I tried every possible permutationof all reasonable options, = even those >>> nonsense, to get rid of that problem. >>>=20 >>> I never had any problems with any other UEFI capable = server/workstation >>> firmware so far booting FreeBSD off in UEFI-native (GPT partition = scheme, >>> CSM disabled) so far - until now, when I ran into this Fujitsu = ESPRIMO Q956 >>> with the most recent firmware (as of lat week, week 29 of 2018) = having the >>> very same problems.=20 >>>=20 >>>=20 >>>=20 >>> I figured out something strange on the Fujitsu - and that is the = same with >>> the ASRock boards. >>>=20 >>> We/I prepare some USB flash drives to boot a NanoBSD for a very = small >>> appliance, but nevertheless, the USB flash device is booted on = Fujitsu >>> servers with UEFI-only configurations. I assume at this point that >>> disabling on the most recent Fujitsu firmwares on reasonable "new" = hardware >>> (not older than three years) will disable any(!) legacy BIOS = capabilities. >>> The same is assumed for the Fujitus ESPRIMO Q956. I can not speak = for the >>> ASRock A77 Pro4/m boards mentioned above/earlier, they are from = 2012/2013 >>> and "quite old". >>>=20 >>> The NanoBSD image of ours doesn't have a "freebsd-boot" partition. = The >>> partition scheme of the flash device is GPT. The layout looks like = this: >>>=20 >>> gpart show -l da4 =20 >>> =3D> 40 15425456 da4 GPT (7.4G) =20 >>> 40 2000 1 efiboot0 (1.0M) >>> 2040 1453584 3 disk1a (710M) >>> 1455624 4096 5 disk3 (2.0M) >>> 1459720 13965776 - free - (6.7G) >>>=20 >>> I created the flash with md, gpart and dd straightforward, efiboot0 = is the >>> ESP partition and its format/content is created via dd = if=3D/boot/boot1.efifat >>> of=3D/dev/da4p1 - I presume this is very simple. >>>=20 >>> This USB flash device boots(!) successfully (UEFI!) on both the = ASRock >>> boards and the Esprimo Q956! >>>=20 >>> But any SSD prepared the same way doesn't. Why?=20 >>>=20 >>> On the ASRock, I recall having fiddled around with HDD also for a = while >>> conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - I = can't >>> remember.=20 >>>=20 >>> In the lack of proper hardware I'm unable to check whether = USB-attached HDD >>> or SSD will boot or HDD will boot (just in case the local SATA has = problems >>> booting UEFI and USB not). >>>=20 >>> Kind regards, >>>=20 >>> Oliver=20 >>>=20 >>=20 >> Am. well. I think the suggestion to test out FAT32 is still good one = to test. >> This is because it is known that some vendors do not support booting >> FAT12/FAT16 from HDD (the likely reason is that UEFI specification = does not >> tell which FAT must be supported, and only hint about FAT12/FAT16 in = context >> of removable devices). >=20 > I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO Q956. = It took me > a time to circumvent the installer and I had to install the system = manually. In > that strain, I also "tried" to establish the ESP with FAT32, as Allen = Jude > suggested earlier. I didn't find any ad hoc help how to find out the = format > (FAT12/16/32) of the ESP, so I assume when using 12-CURRENT's or = 11.2-RELENG's > installer with AUTO-ZFS and GPT (UEFI) (only!) the resulting ESP is = FAT12 or > FAT16 (300mb by default). I also assume, that when dd'ing the = /boo/boot1.efifat > image to a partition, the format is FAT, but not FAT32. Therefore, I = refomatted > the manually created ESP (using "gpart add -t efi ...") using = "newfs_msdos -F > 32 -b xxx ...". I had to fiddle around a bit with option -b to fit in = a proper > format to meet a 512mb ESP - I'm not sure whether this is the proper = option to > deal with. When using the default and only -F32, the size of the = partition has > to be 4G at least I assume. Having done that, I copied the the content = of > boot1.efifat (mdconfig -t vnode ..., I guess we know the drill ...) to = the > newly formatted ESP to /boot/efi/ ... >=20 > Having so far no knowledge of how to asure that the created ESP is = FAT32, I > assume it is FAT32. >=20 > The result is negative on the ESPRIMO Q956. When disabling the CSM, = the box is > not willing to boot from SSD with the ESP prepared as decribed. So, a = chance > that this might still be due to a misconfiguration lies now within the = -b > option of newfs_msdos - if the -b option is assumed the proper option? >=20 > At the moment, the ESP of the Esprimo is subject to changes, if you = wish, but > not in size, since it is limited to 512mb. >=20 > Thanks and kind regards, >=20 > Oliver Yea, i was hoping fstyp command would report the FAT type, but it does = not (request for feature?:) However, the more annoying idea would be to install some OS which will = boot with UEFI on this machine, then copy boot1.efi from freebsd to it = (the default program the UEFI will load is ESP:EFI/boot/bootx64.efi in = case of UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, we do = not support EFI32. note that boot1.efi alone will not do much but printing on screen how it = will search for freebsd, but for the purpose of the test it would = suffice - that would give us confirmed working ESP file system (since = the other os would be able to boot) and then we can confirm if boot1.efi = itself is OK. rgds, toomas From owner-freebsd-current@freebsd.org Wed Jul 25 09:10:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9FF9104529C for ; Wed, 25 Jul 2018 09:10:39 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 260A275C0F; Wed, 25 Jul 2018 09:10:38 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MV6EP-1fUEgG2Us1-00YObp; Wed, 25 Jul 2018 11:10:33 +0200 Date: Wed, 25 Jul 2018 11:10:32 +0200 From: "O. Hartmann" To: Toomas Soome Cc: "O. Hartmann" , freebsd-current , Allan Jude Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180725111032.1632b885@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <2FCF2BCC-05E5-466A-B1AE-90300990ED1A@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> <20180725095926.7d52a15a@freyja.zeit4.iv.bundesimmobilien.de> <2FCF2BCC-05E5-466A-B1AE-90300990ED1A@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:kPVbInRYNCR3l73zajyBnLQUt8kZIKPVuWNMxhX20D2FX2kQIzs vW7D5nyn/s8BVNCk8Ofz9lKVfy3+qNz/GpCLXuFP2Qc/GLSLnDOETsFp6N8Qcph1AgFt+Go 2/h4HwmjYfMZlfz5XVTUKtpWzTmUoAimfV+12kwpDgGoUr0MnYF+5N/29fomD6VICjme0n7 2aAiT2pkedc38i/5AsfzQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:9vWC4ts+7Sw=:zY7l2zH72k1daGISokhd8X tLJnLiH8VhGC2FwL6eYqwLZSNLRvq1Tf35cZBErWkqkbB9pQkdr2gyHra2eVG3fXdh/cf/yre VTFSJ6vWf96OoaiqXEDNNC02xTfD7l/A8HByhLa1VJPSxaleMlW5lSHmnYvCjwaKzsYz9826p F+cH4fo9JalHWOeMLVoDgkq+bj3BuRlLje9LxM/rjJK9i+vvUtzjcfWyRjV9ux4DAi3OlMet1 G1wfHLRMpx6Lk+tErgwrIIhRuuHz+jMPXHsX4YWZDqL5X94TV/Os2WKyqetTqql8bV3eDnE/K k+n7q0Hs5b6LoldfpVtze0bnCAzqDQES3qBL/QXovsX3melPmI9SS53XOVWqyFQOzXZCnaZ/m u9VZGKEp2tYCbYIBlpZQZO68cbFJ3k4KpR0+QM/Dav7itjJI1yWjkDzI+0nGnSMq2U4uAn5xr JOrBNbrVYF8SzpWlk3cFhkk754YFnEoSlKEmWLYnhGn5L2qSVRok/4WuewaRaKaRDbwNB7+a/ unp1IBLPqwdAVp4cp5PxRvCX8EACgmZiRMLMes0Jy0Vrm7QfsNT3uUqvO6DE5d+ZqEt9urPJt IMLohsrIMc6rOGmAuSdioP19C+aZqCfUdu0M1A2ANauXVwPe7mGuArETJ3Ktq8/TrtnsCjiTo B7sRGKsVgN2RVxETFp9nKVUknpVmRJYpzAwMFfT9D0hQ0xBOqTnbvFy/er56mDWIFj2ZO3d5X raUR2cWUfNO6O/K4GbR3wmjjG/qRyqtDeuoROqqgvvXtcGRk/LicUSgHF6a2HM9JSbAwwtT2N 56Xq07q X-Mailman-Approved-At: Wed, 25 Jul 2018 10:15:10 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 09:10:39 -0000 On Wed, 25 Jul 2018 11:46:07 +0300 Toomas Soome wrote: > > On 25 Jul 2018, at 10:59, O. Hartmann wrote: > >=20 > > On Tue, 24 Jul 2018 08:53:36 +0300 > > Toomas Soome wrote: > >=20 > >=20 > > Hello Toomas Soome, > >=20 > > I CC Allan Jude since I discovered something weird today regarding the= UEFI > > boot capabilities of USB flash devices and SSDs. See below. > > =20 > >>> On 24 Jul 2018, at 08:16, O. Hartmann wrote: > >>>=20 > >>> On Mon, 23 Jul 2018 10:56:04 +0300 > >>> Toomas Soome wrote: > >>> =20 > >>>>> On 23 Jul 2018, at 10:27, O. Hartmann wrot= e: > >>>>>=20 > >>>>> On Fri, 13 Jul 2018 18:44:23 +0300 > >>>>> Toomas Soome > wrote: > >>>>> =20 > >>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>>>>> > wrote: > >>>>>>>=20 > >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>> Hash: SHA512 > >>>>>>>=20 > >>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 > >>>>>>> Toomas Soome > >>>>>>> >> schrieb: =20 > >>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann > >>>>>>>>> wrote: > >>>>>>>>>=20 > >>>>>>>>> The problem is some kind of weird. I face UEFI boot problems on= GPT > >>>>>>>>> drives where the first partition begins at block 40 of the hdd/= ssd. > >>>>>>>>>=20 > >>>>>>>>> I have two host in private use based on an > >>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, S= ocket > >>>>>>>>> LGA1155). Both boards are equipted with the lates official avai= lable > >>>>>>>>> AMI firmware revision, dating to 2013. This is for the Z77-Pro4= -M > >>>>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 > >>>>>>>>> (2013/7/17). For both boards a BETA revision for the > >>>>>>>>> Spectre/Meltdown mitigation is available, but I didn't test tha= t. > >>>>>>>>> But please read. > >>>>>>>>>=20 > >>>>>>>>> The third box I realised this problem is a brand new Fujitsu Es= primo > >>>>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, da= te > >>>>>>>>> 05/25/2018 (or 20180525). > >>>>>>>>>=20 > >>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall= the > >>>>>>>>> OS using UEFI-only boot method on a GPT partitioned device fail= s. > >>>>>>>>> The ASRock boards jump immediately into the firmware, the Fujit= su > >>>>>>>>> offers some kind of CPU/Memory/HDD test facility. > >>>>>>>>>=20 > >>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot = only > >>>>>>>>> is implied, the MBR partitioned FreeBSD installation USB flash > >>>>>>>>> device does boot in UEFI! I guess I can assume this when the we= ll > >>>>>>>>> known clumsy 80x25 char console suddenly gets bright and shiny = with > >>>>>>>>> a much higher resoltion as long the GPU supports EFI GOP. Looki= ng > >>>>>>>>> with gpart at the USB flash drives reveals that the EFI partiti= on > >>>>>>>>> starts at block 1 of the device and the device has a MBR layout= . I > >>>>>>>>> haven't found a way to force the GPT scheme, when initialised v= ia > >>>>>>>>> gpart, to let the partitions start at block 1. This might be a = naiv > >>>>>>>>> thinking, so please be patient with me. > >>>>>>>>>=20 > >>>>>>>>> I do not know whether this is a well-known issue. On the ASRock > >>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI = and > >>>>>>>>> that worked - FreeBSD not. I gave up on that that time. Now, ha= ving > >>>>>>>>> the very same issues with a new Fujitsu system, leaves me with = the > >>>>>>>>> impression that FreeBSD's UEFI implementation might have proble= ms > >>>>>>>>> I'm not aware of. > >>>>>>>>>=20 > >>>>>>>>> Can someone shed some light onto this?=20 > >>>>>>>>> =20 > >>>>>>>>=20 > >>>>>>>> The first thing to check is if the secure boot is disabled. We d= o not > >>>>>>>> support secure boot at all at this time. =20 > >>>>>>>=20 > >>>>>>> Secure boot is in every scenario disabled! > >>>>>>> =20 > >>>>>>>>=20 > >>>>>>>> If you have efi or bios version running - you can check from eit= her > >>>>>>>> console variable value (it can have efi or vidconsole or comcons= ole) > >>>>>>>> or better yet, see if efi-version is set (show efi-version) - if > >>>>>>>> efi-version is not set, it is BIOS loader running. Another indir= ect > >>>>>>>> way is to see lsdev -v, with device paths present, it is > >>>>>>>> uefi:) =20 > >>>>>>>=20 > >>>>>>> What are you talking about? > >>>>>>> What is the point of entry - running system, loader? > >>>>>>>=20 > >>>>>>> sysct machdep.bootmethod: BIOS > >>>>>>>=20 > >>>>>>> This makes me quite sure that the system has booted via BIOS - as= I'm > >>>>>>> sure since I've checked that many times. UEFI doesn't work on tho= se > >>>>>>> systems with FreeBSD. I'm not sure antmore, but I tried also Wind= ows 7 > >>>>>>> on those mainboards booting via UEFI - and I might recall that th= ey > >>>>>>> failed also. I also recall that there were issues with earlier UE= FI > >>>>>>> versions regarding booting only Windows 8/8.1 - and nothing else,= but > >>>>>>> the fact that Linux worked confuses me a bit. > >>>>>>>=20 > >>>>>>> If this ASRock crap (never ever again this brand!) doesn't work at > >>>>>>> all - who cares, I intend to purchase new server grade hardware. = But > >>>>>>> the more puzzling issue is with the Fujitsu, which I consider ser= ious > >>>>>>> and from the behaviour the Fujitsu failure looks exactly like the > >>>>>>> ASRock - Windows 7 works, RedHat 7.5 works (I assume I can trust = the > >>>>>>> Firmware settings when I disable CSM support, that the Firmware w= ill > >>>>>>> only EFI/UEFI capable loader? Or is there a ghosty override somwh= ere > >>>>>>> to be expected?). Also on ASRock disabling CSM should ensure not > >>>>>>> booting a dual-bootstrap-capable system. This said, on the recent > >>>>>>> Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware interac= tion > >>>>>>> problem, while the ASRock is still under suspicion to be broken by > >>>>>>> design. =20 > >>>>>>>>=20 > >>>>>>>> GPT partitions can never start from disk absolute sector 1; this= is > >>>>>>>> because at sector 0 there is MBR (for compatibility), sector 1 i= s GPT > >>>>>>>> table and then sectors 2-33 have GPT partition table entries, so= the > >>>>>>>> first possible data sector is 34 (absolute 34). Thats assuming 5= 12B > >>>>>>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. = =20 > >>>>>>>=20 > >>>>>>> Thanks for the explanation. That implies the installer did right, > >>>>>>> gpart did also right and therefore there must be an issue with the > >>>>>>> stuff located within the EFI partition? =20 > >>>>>>=20 > >>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BI= OS > >>>>>> loader at all or not - that is, if the BIOS bootstrap is actually > >>>>>> caring to read the MBR code and start it, since once the MBR code = is > >>>>>> started, it is all about our code. =20 > >>>>>=20 > >>>>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or = do > >>>>> you mean that specific portion of the UEFI firmware, which looks fo= r the > >>>>> proper UEFI partition? > >>>>> =20 > >>>>=20 > >>>> BIOS as either native or CSM. Note that from boot code point of view= the > >>>> CSM boot *is* BIOS boot, we have no access to UEFI features. > >>>> =20 > >>>>>=20 > >>>>> The boxes in question, most notably the more recent Fujitsu Esprimo > >>>>> Q956, refuse booting UEFI, even if properly setup (in terms of what > >>>>> FreeBSD provides on recent CURRENT) is applied and CSM is switched = off > >>>>> in the firmware. Again: GPT partition scheme. > >>>>>=20 > >>>>> The system boots properly if a second partition of type "freebsd-bo= ot" > >>>>> is applied and bootcode is properly applied via "gpart bootcode > >>>>> -b /boot/pmbr -p /boot/gptboot -i 2 ada0" (ada0 is the device). = =20 > >>>>>>=20 > >>>>>> btw, you can try to validate the installed boot blocks by using re= cent > >>>>>> enough loader (usb or iso) and then you can use from OK prompt: = =20 > >>>>>=20 > >>>>> lsdev provides me with the follwoing informations (CSM enabled): > >>>>>=20 > >>>>> OK lsdev > >>>>> disk devices: > >>>>> disk0: BIOS DRIVE C ... > >>>>>=20 > >>>>> disk0p1: EFI > >>>>> disk0p2: FreeBSD BOOT > >>>>> disk0p3: FreeBSD SWAP > >>>>> disk0p4: FreeBSD ZFS > >>>>> zfs devices: > >>>>> zfs:zroot > >>>>>=20 > >>>>> OK chain disk0 > >>>>> open failed (so for disk0p{1-4}. > >>>>>=20 > >>>>> OK chain zroot > >>>>> failed to read disk (just for completeness) =20 > >>>>=20 > >>>>=20 > >>>> chain command does use only device name (such as disk0: or disk0p2: = ), > >>>> but not zfs pool as device. I just found I haven=E2=80=99t ported t= he code to > >>>> read the file. =20 > >>>=20 > >>> ?? > >>> =20 > >>>>=20 > >>>> the point for chain command test is to see if the normal read and ex= ecute > >>>> would work, so in your case please try: > >>>>=20 > >>>> chain disk0: =20 > >>>=20 > >>> As stated above, I did so, and the result is also mentioned above, I > >>> always get "open failed". > >>> This is the same for=20 > >>>=20 > >>> chain disk0 > >>> chain disk0p1 > >>> chain disk0p2 > >>> chain disk0p3 > >>> chain disk0p4 > >>>=20 > >>> as already said. CSM is enabled in this case. =20 > >>=20 > >> sigh=E2=80=A6 chain command does take device as argument, device must = always end > >> with colon=E2=80=A6. in this case, the devil is in details:) as I wrot= e above, the > >> command should be: > >>=20 > >> chain disk0: > >>=20 > >> The disk0p1: etc will only work when partition boot code was installed > >> (which you most likely do not have - the only possible candidate could= be > >> FreeBSD ZFS partition). =20 > >=20 > > The command "chain disk0:" works as expected (CSM enabled, GPT partition > > scheme, but with PMBR bootblock installed and freebsd-boot partition > > conatining gptzfsboot installed. > >=20 > > =20 > >> =20 > >>> =20 > >>>>=20 > >>>> to read pmbr (512B) and execute it. The expected outcome would be th= at > >>>> pmbr boot code would browse the GPT, read stage1 from disk0p2: and > >>>> execute it; stage1 would detect FreeBSD ZFS from disk0p4: and load a= nd > >>>> execute /boot/loader. If that will happen, it means the boot code in= our > >>>> stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6.= if thats > >>>> true, it would mean that you either need to use UEFI boot or need to= have > >>>> some hack to fool the BIOS or just not use GPT on that machine with > >>>> CSM. =20 > >>>=20 > >>> To make it clear here: The only way to boot this box is using CSM (as= it > >>> is the same with the ASRock boards mentioned earlier). But my intenti= on > >>> is to disable CSM and use a GPT/UEFI environment only! And GPT/UEFI > >>> doesn't work with FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG. > >>>=20 > >>> It would be nice if this could be fixed. I'm more interested in the f= ix on > >>> the recent Fujitsu device than the outdated ASRock crap, but if the f= ix > >>> for the Fujitsu Firmware could fix older issues as a byproduct, I'd > >>> appreciate that. > >>>=20 > >>> Kind regards, > >>> =20 > >>=20 > >> ok, somehow I have lost that part of the discussion. Well, you wrote t= hat > >> the UEFI boot fails when the first partition starts from sector 40 - d= oes > >> it mean you have boot when the partition will start from some other > >> sector? I think, there is something else going on. =20 > >=20 > > Well, I simply try to describe what I "see" to make things disambiguous= . I'm > > not familiar with the deeper insights of disk layouts on a binary level= . So, > > you explained to me the reason, why ESP (EGI partition) starts at block= 40. > > I compared that to the FreeBSD USB flash image FreeBSD provides, but th= is is > > another story since the image uses MBR scheme as I figured out. > >=20 > > =20 > >>=20 > >> What you can do is to see if that firmware will offer you EFI shell op= tion, > >> from there you can try to start the bootx64.efi manually and see what = error > >> you will get. However, the number 1 cause for failing to start the > >> bootloader in UEFI is secure boot - we do not support it and secure bo= ot > >> must be switched off.=20 > >>=20 > >> However, they seem to claim "The Secure Boot option is available in the > >> UEFI/BIOS of most if not all ASRock boards. It is disabled by default.= =E2=80=9D=20 > >>=20 > >> Still suggest to double check if thats really the case. Also, if the > >> bootx64.efi start will fail and no messages are appearing on screen, t= hen > >> either there is something in firmware logs or you could get them from > >> trying to start bootx64.efi from UEFI shell. =20 > >=20 > > Since I'm with this problem since 2014 and try from time to time, be au= sred > > that I tried every possible permutationof all reasonable options, even = those > > nonsense, to get rid of that problem. > >=20 > > I never had any problems with any other UEFI capable server/workstation > > firmware so far booting FreeBSD off in UEFI-native (GPT partition schem= e, > > CSM disabled) so far - until now, when I ran into this Fujitsu ESPRIMO = Q956 > > with the most recent firmware (as of lat week, week 29 of 2018) having = the > > very same problems.=20 > >=20 > >=20 > >=20 > > I figured out something strange on the Fujitsu - and that is the same w= ith > > the ASRock boards. > >=20 > > We/I prepare some USB flash drives to boot a NanoBSD for a very small > > appliance, but nevertheless, the USB flash device is booted on Fujitsu > > servers with UEFI-only configurations. I assume at this point that > > disabling on the most recent Fujitsu firmwares on reasonable "new" hard= ware > > (not older than three years) will disable any(!) legacy BIOS capabiliti= es. > > The same is assumed for the Fujitus ESPRIMO Q956. I can not speak for t= he > > ASRock A77 Pro4/m boards mentioned above/earlier, they are from 2012/20= 13 > > and "quite old". > >=20 > > The NanoBSD image of ours doesn't have a "freebsd-boot" partition. The > > partition scheme of the flash device is GPT. The layout looks like this: > >=20 > > gpart show -l da4 =20 > > =3D> 40 15425456 da4 GPT (7.4G) =20 > > 40 2000 1 efiboot0 (1.0M) > > 2040 1453584 3 disk1a (710M) > > 1455624 4096 5 disk3 (2.0M) > > 1459720 13965776 - free - (6.7G) > >=20 > > I created the flash with md, gpart and dd straightforward, efiboot0 is = the > > ESP partition and its format/content is created via dd if=3D/boot/boot1= .efifat > > of=3D/dev/da4p1 - I presume this is very simple. > >=20 > > This USB flash device boots(!) successfully (UEFI!) on both the ASRock > > boards and the Esprimo Q956! > >=20 > > But any SSD prepared the same way doesn't. Why?=20 > >=20 > > On the ASRock, I recall having fiddled around with HDD also for a while > > conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - I can't > > remember.=20 > >=20 > > In the lack of proper hardware I'm unable to check whether USB-attached= HDD > > or SSD will boot or HDD will boot (just in case the local SATA has prob= lems > > booting UEFI and USB not). > >=20 > > Kind regards, > >=20 > > Oliver=20 > > =20 >=20 > Am. well. I think the suggestion to test out FAT32 is still good one to t= est. > This is because it is known that some vendors do not support booting > FAT12/FAT16 from HDD (the likely reason is that UEFI specification does n= ot > tell which FAT must be supported, and only hint about FAT12/FAT16 in cont= ext > of removable devices). I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO Q956. It too= k me a time to circumvent the installer and I had to install the system manually= . In that strain, I also "tried" to establish the ESP with FAT32, as Allen Jude suggested earlier. I didn't find any ad hoc help how to find out the format (FAT12/16/32) of the ESP, so I assume when using 12-CURRENT's or 11.2-RELEN= G's installer with AUTO-ZFS and GPT (UEFI) (only!) the resulting ESP is FAT12 or FAT16 (300mb by default). I also assume, that when dd'ing the /boo/boot1.ef= ifat image to a partition, the format is FAT, but not FAT32. Therefore, I refoma= tted the manually created ESP (using "gpart add -t efi ...") using "newfs_msdos = -F 32 -b xxx ...". I had to fiddle around a bit with option -b to fit in a pro= per format to meet a 512mb ESP - I'm not sure whether this is the proper option= to deal with. When using the default and only -F32, the size of the partition = has to be 4G at least I assume. Having done that, I copied the the content of boot1.efifat (mdconfig -t vnode ..., I guess we know the drill ...) to the newly formatted ESP to /boot/efi/ ... Having so far no knowledge of how to asure that the created ESP is FAT32, I assume it is FAT32. The result is negative on the ESPRIMO Q956. When disabling the CSM, the box= is not willing to boot from SSD with the ESP prepared as decribed. So, a chance that this might still be due to a misconfiguration lies now within the -b option of newfs_msdos - if the -b option is assumed the proper option? At the moment, the ESP of the Esprimo is subject to changes, if you wish, b= ut not in size, since it is limited to 512mb. Thanks and kind regards, Oliver >=20 > There are other possible causes too, for example: > https://ubuntuforums.org/showthread.php?t=3D2147295=20 >=20 > Also about the ESP sizes: https://www.ctrl.blog/entry/esp-size-guide >=20 > "The UEFI System Partition should be at least 260 MiB (273 MB) to ensure = its > properly formatted with FAT32 so that you avoid UEFI implementation > compatibility issues. (If you do have incompatible hardware that requires > FAT16-formatting, then I suggest you move aside the files on the UEFI Sys= tem > Partition, convert the partition to FAT16, and copy the files back over to > it.)=E2=80=9D >=20 > So, as you see, even just telling =E2=80=9Cuse FAT32=E2=80=9D is not univ= ersal medicine, but > I suspect it is still more universal than using FAT12/FAT16:) >=20 > Just to be clear, there is *no* standard size rule for ESP, there are only > suggestions from vendors=E2=80=A6=20 >=20 > Yes, this all means that if the solution from default installer does not > work, the manual work is needed to identify why the default is not working > and the findings should be reported, so the installer (and possibly other > parts of the system) could be adjusted. Since this all is vendor specific= , it > has to be handled case by case. >=20 > rgds, > toomas >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Jul 25 13:20:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C0EC104ADFF for ; Wed, 25 Jul 2018 13:20:24 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 B43C67DAAA; Wed, 25 Jul 2018 13:20:23 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id n21-v6so13816421oig.3; Wed, 25 Jul 2018 06:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mdfALpKPjeRY56iavHY7scPCRiHVK2YVzi9zkCXv5aQ=; b=pnjbW/QhU7RJnMdCDYTG/yZhJHNXO5Wgt9vrAe3yOM/vYv7gnekrDH3neLDXE2zsKB vftp2KQlsYSqVc1b1Gw5jWVSqVhl6qJWBgzgXsTLAbzW9063wsQGPl14iDCVxSotGzb/ CVToFlkCwqNtyvh3uxETqgDTW9+IMdudllh3PHQPJ0xcnqF6iXZx/JlepIZX+bSs010z dwVFH9KrJmyfN2Ne9l6f/ffXe054HpvAIrslnBxQCneRw/eUn5EpihitjfxIZxisyqP8 UKAKPJ5ipShcgxuTJ1g6hVAD+Jilp7F0NSXhgGxBDVQIcEvtnDDvcxjVxfFimImDiTM2 G74A== 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=mdfALpKPjeRY56iavHY7scPCRiHVK2YVzi9zkCXv5aQ=; b=OgRXw8NDENtk1MI9WQ+sdzSXTW9kFlXXmr0XjXChRbFxL3kTrPds7kchVinKIDkA9v DSzyJ1OqIT4ASBBkgWbndWlP/+0gKW8VfxFPEL40lfXygc70v/9qVAK0EnGlgol6+9Wq SHgt/LyYzUIGQNNy1yKGsCJir1EmV3E4Ibn3itWevv9+h2HvDCQqMcYFE/lDVLkVgr8M 6xhV+eoIDb8EGfac7Tunt+XbWqbY17eR3ig9/izWm3RCl28tYn2JquZqsmvYi7N/8a0s 9EWOmib+w5Nq3mY3fYsuoMBSdwiERi5OKdL887chgajrYf+Xaa1/8VU4cMqQtwTypRwK znXw== X-Gm-Message-State: AOUpUlFqjii8bWxzhFeUVXtiVRObkccX5V2Et9qA4/Naxwy81Ea+nVAN vJH1Mc3q++RSIpnhJ9Xkzwwi8YqIU2jBh2vc1BPxxEzDqg8= X-Google-Smtp-Source: AAOMgpdZulSEMZHJoalSrVZrh82DSUs+HPtaNwSL8G0J19m/d2M7s5yp8CXl3tQH4xI5ej94fMtW14YPxv1lNcJYCkk= X-Received: by 2002:aca:de04:: with SMTP id v4-v6mr3555677oig.328.1532524822839; Wed, 25 Jul 2018 06:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:7901:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 06:20:22 -0700 (PDT) From: Andrey Fesenko Date: Wed, 25 Jul 2018 16:20:22 +0300 Message-ID: Subject: Spam in console after r336593 (NFS mounted) To: freebsd-current , cperciva@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 13:20:24 -0000 Hello. After https://svnweb.freebsd.org/base?view=revision&revision=336593 any make action starting spam errors (svn not work on NFS mounted partitions) svn: E155016: The working copy database at '/usr/src' is corrupt. svn: E155016: The working copy database at '/usr/src' is corrupt. make[2]: "/usr/src/release/Makefile.ec2" line 24: warning: "/usr/local/bin/svn info --show-item last-changed-revision /usr/sr c/release/.." returned non-zero status svn: E155016: The working copy database at '/usr/src' is corrupt. svn: E155016: The working copy database at '/usr/src' is corrupt. make[2]: "/usr/src/release/Makefile.ec2" line 24: warning: "/usr/local/bin/svn info --show-item last-changed-revision /usr/sr c/release/.." returned non-zero status From owner-freebsd-current@freebsd.org Wed Jul 25 13:32:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7783104B388 for ; Wed, 25 Jul 2018 13:32:19 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 6FE437E4EB for ; Wed, 25 Jul 2018 13:32:19 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22e.google.com with SMTP id l189-v6so2844637ywb.10 for ; Wed, 25 Jul 2018 06:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=uf5Lv8salaKWTkiIzzPViN4PqLwS4PIgG8rO17Jo2Kk=; b=hZoNtvg6KyRIT3uAowomE6kRkRGsSeH/Hyd5MM/KbB2DWgKCbxf6+LKBCfg9UNQp9/ MQSLhPvoMSwNg8Zcafx3u5vm3AK3QfIaDtOTlXThab/Tn2ylUKWfoNmK8KyphLdiQ1XV eUhICDs1tqvOoi5DQlm/ZEKNLQc9ydfTuZS9U= 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=uf5Lv8salaKWTkiIzzPViN4PqLwS4PIgG8rO17Jo2Kk=; b=XGWLtE2YBve3zEKPgOmnnb/JimEEe69uIcGImcTQXF2RXVgNsKPOnDR405wigLc8zl cnBBBNvJm+sZdWNsdEyr/WIaFNd+DALSO/ZRlZTpiw7JN2+A80P9BYF1R3E8XUruXpIp 78dpBqUsLvsltWXTT2GjRRJoFDhELDxjC+NsIEw8cMKlvtbrF9NJ0ecZEBja/UvWBH57 hWUCUFEp3Uv3T1BKhxTWK2cqcb5yZWPQjI/ptvGgLobzaxgY5ea5WCSGN/4VCLFfrxV3 k+VaDFCd+JBt1dEbHl5XQgTe+dWGFuOtJZlZkRquJXB44PMzZRm7zVGa1n9hUQxIFCjG RBDA== X-Gm-Message-State: AOUpUlHmhgIifbIMV5PWpaeiTf7lpBCLG2jbIMkNdYcCD+NcXzkeEqj+ mzDJbzIHTxz0woN2csUFrE7bMIQKcYDzyEh7m30J05cS9bAaxA== X-Google-Smtp-Source: AAOMgpcEe1pzFneWGpHss6oKJhyUQH2BTtYq8OleiFaYiftj6JGnM8EyyMvjTCtXwPmqfYvTRGC27/cbqa5fthy4Fa0= X-Received: by 2002:a0d:de02:: with SMTP id h2-v6mr10776255ywe.162.1532525538285; Wed, 25 Jul 2018 06:32:18 -0700 (PDT) MIME-Version: 1.0 From: Eitan Adler Date: Wed, 25 Jul 2018 06:31:51 -0700 Message-ID: Subject: error building r336696: cp: asn1_OCSPResponseStatus.c: Bad address To: freebsd-current Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 13:32:19 -0000 I'm currently on r335788 and trying to build r336696. When running make -s buildworld buildkernel -j33 I get the following. Any help is appreciated to fix. CMD cp -f asn1_OCSPResponseStatus.x asn1_OCSPResponseStatus.c CWD /srv/obj/fbsd/usr/src/amd64.amd64/kerberos5/lib/libhx509 TARGET asn1_OCSPResponseStatus.c -- command output -- cp: asn1_OCSPResponseStatus.c: Bad address src.conf === MALLOC_PRODUCTION=true WITHOUT_SVNLITE=true WITHOUT_LIB32=true WITH_CLANG_EXTRAS=true WITH_BSD_GREP=true WITH_GNU_GREP_COMPAT=true WITH_EXTRA_TCP_STACKS=true WITH_LOADER_LUA=true WITHOUT_FORTH=true WITH_SORT_THREADS=true src-env.conf === MAKEOBJDIRPREFIX?=/srv/obj/fbsd WITH_META_MODE=yes make.conf === WRKDIRPREFIX=/srv/obj/fbsd/ports DISTDIR=/srv/obj/distfiles FORMATS=html DEVELOPER=yes WITH_PKGNG=devel CPUTYPE?=znver1 # Set here for ports development only DEFAULT_VERSIONS+=ssl=openssl -- Eitan Adler From owner-freebsd-current@freebsd.org Wed Jul 25 14:30:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4ADE104C7FF for ; Wed, 25 Jul 2018 14:30:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 2C1DD80729; Wed, 25 Jul 2018 14:30:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w6PEUWFm041287; Wed, 25 Jul 2018 07:30:32 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w6PEUWPn041286; Wed, 25 Jul 2018 07:30:32 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> Subject: Re: [UEFI] Boot issues on some UEFI implementations In-Reply-To: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> To: Toomas Soome Date: Wed, 25 Jul 2018 07:30:32 -0700 (PDT) CC: "O. Hartmann" , freebsd-current , Allan Jude X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 14:30:38 -0000 > > On 25 Jul 2018, at 12:10, O. Hartmann wrote: > > > > On Wed, 25 Jul 2018 11:46:07 +0300 > > Toomas Soome wrote: > > > >>> On 25 Jul 2018, at 10:59, O. Hartmann wrote: > >>> > >>> On Tue, 24 Jul 2018 08:53:36 +0300 > >>> Toomas Soome wrote: > >>> > >>> > >>> Hello Toomas Soome, > >>> > >>> I CC Allan Jude since I discovered something weird today regarding the UEFI > >>> boot capabilities of USB flash devices and SSDs. See below. > >>> > >>>>> On 24 Jul 2018, at 08:16, O. Hartmann wrote: > >>>>> > >>>>> On Mon, 23 Jul 2018 10:56:04 +0300 > >>>>> Toomas Soome wrote: > >>>>> > >>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann wrote: > >>>>>>> > >>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 > >>>>>>> Toomas Soome > wrote: > >>>>>>> > >>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>>>>>>> > wrote: > >>>>>>>>> > >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>>>> Hash: SHA512 > >>>>>>>>> > >>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 > >>>>>>>>> Toomas Soome > >>>>>>>>> >> schrieb: > >>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> The problem is some kind of weird. I face UEFI boot problems on GPT > >>>>>>>>>>> drives where the first partition begins at block 40 of the hdd/ssd. > >>>>>>>>>>> > >>>>>>>>>>> I have two host in private use based on an > >>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket > >>>>>>>>>>> LGA1155). Both boards are equipted with the lates official available > >>>>>>>>>>> AMI firmware revision, dating to 2013. This is for the Z77-Pro4-M > >>>>>>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 > >>>>>>>>>>> (2013/7/17). For both boards a BETA revision for the > >>>>>>>>>>> Spectre/Meltdown mitigation is available, but I didn't test that. > >>>>>>>>>>> But please read. > >>>>>>>>>>> > >>>>>>>>>>> The third box I realised this problem is a brand new Fujitsu Esprimo > >>>>>>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date > >>>>>>>>>>> 05/25/2018 (or 20180525). > >>>>>>>>>>> > >>>>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall the > >>>>>>>>>>> OS using UEFI-only boot method on a GPT partitioned device fails. > >>>>>>>>>>> The ASRock boards jump immediately into the firmware, the Fujitsu > >>>>>>>>>>> offers some kind of CPU/Memory/HDD test facility. > >>>>>>>>>>> > >>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot only > >>>>>>>>>>> is implied, the MBR partitioned FreeBSD installation USB flash > >>>>>>>>>>> device does boot in UEFI! I guess I can assume this when the well > >>>>>>>>>>> known clumsy 80x25 char console suddenly gets bright and shiny with > >>>>>>>>>>> a much higher resoltion as long the GPU supports EFI GOP. Looking > >>>>>>>>>>> with gpart at the USB flash drives reveals that the EFI partition > >>>>>>>>>>> starts at block 1 of the device and the device has a MBR layout. I > >>>>>>>>>>> haven't found a way to force the GPT scheme, when initialised via > >>>>>>>>>>> gpart, to let the partitions start at block 1. This might be a naiv > >>>>>>>>>>> thinking, so please be patient with me. > >>>>>>>>>>> > >>>>>>>>>>> I do not know whether this is a well-known issue. On the ASRock > >>>>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI and > >>>>>>>>>>> that worked - FreeBSD not. I gave up on that that time. Now, having > >>>>>>>>>>> the very same issues with a new Fujitsu system, leaves me with the > >>>>>>>>>>> impression that FreeBSD's UEFI implementation might have problems > >>>>>>>>>>> I'm not aware of. > >>>>>>>>>>> > >>>>>>>>>>> Can someone shed some light onto this? > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> The first thing to check is if the secure boot is disabled. We do not > >>>>>>>>>> support secure boot at all at this time. > >>>>>>>>> > >>>>>>>>> Secure boot is in every scenario disabled! > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> If you have efi or bios version running - you can check from either > >>>>>>>>>> console variable value (it can have efi or vidconsole or comconsole) > >>>>>>>>>> or better yet, see if efi-version is set (show efi-version) - if > >>>>>>>>>> efi-version is not set, it is BIOS loader running. Another indirect > >>>>>>>>>> way is to see lsdev -v, with device paths present, it is > >>>>>>>>>> uefi:) > >>>>>>>>> > >>>>>>>>> What are you talking about? > >>>>>>>>> What is the point of entry - running system, loader? > >>>>>>>>> > >>>>>>>>> sysct machdep.bootmethod: BIOS > >>>>>>>>> > >>>>>>>>> This makes me quite sure that the system has booted via BIOS - as I'm > >>>>>>>>> sure since I've checked that many times. UEFI doesn't work on those > >>>>>>>>> systems with FreeBSD. I'm not sure antmore, but I tried also Windows 7 > >>>>>>>>> on those mainboards booting via UEFI - and I might recall that they > >>>>>>>>> failed also. I also recall that there were issues with earlier UEFI > >>>>>>>>> versions regarding booting only Windows 8/8.1 - and nothing else, but > >>>>>>>>> the fact that Linux worked confuses me a bit. > >>>>>>>>> > >>>>>>>>> If this ASRock crap (never ever again this brand!) doesn't work at > >>>>>>>>> all - who cares, I intend to purchase new server grade hardware. But > >>>>>>>>> the more puzzling issue is with the Fujitsu, which I consider serious > >>>>>>>>> and from the behaviour the Fujitsu failure looks exactly like the > >>>>>>>>> ASRock - Windows 7 works, RedHat 7.5 works (I assume I can trust the > >>>>>>>>> Firmware settings when I disable CSM support, that the Firmware will > >>>>>>>>> only EFI/UEFI capable loader? Or is there a ghosty override somwhere > >>>>>>>>> to be expected?). Also on ASRock disabling CSM should ensure not > >>>>>>>>> booting a dual-bootstrap-capable system. This said, on the recent > >>>>>>>>> Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware interaction > >>>>>>>>> problem, while the ASRock is still under suspicion to be broken by > >>>>>>>>> design. > >>>>>>>>>> > >>>>>>>>>> GPT partitions can never start from disk absolute sector 1; this is > >>>>>>>>>> because at sector 0 there is MBR (for compatibility), sector 1 is GPT > >>>>>>>>>> table and then sectors 2-33 have GPT partition table entries, so the > >>>>>>>>>> first possible data sector is 34 (absolute 34). Thats assuming 512B > >>>>>>>>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. > >>>>>>>>> > >>>>>>>>> Thanks for the explanation. That implies the installer did right, > >>>>>>>>> gpart did also right and therefore there must be an issue with the > >>>>>>>>> stuff located within the EFI partition? > >>>>>>>> > >>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BIOS > >>>>>>>> loader at all or not - that is, if the BIOS bootstrap is actually > >>>>>>>> caring to read the MBR code and start it, since once the MBR code is > >>>>>>>> started, it is all about our code. > >>>>>>> > >>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or do > >>>>>>> you mean that specific portion of the UEFI firmware, which looks for the > >>>>>>> proper UEFI partition? > >>>>>>> > >>>>>> > >>>>>> BIOS as either native or CSM. Note that from boot code point of view the > >>>>>> CSM boot *is* BIOS boot, we have no access to UEFI features. > >>>>>> > >>>>>>> > >>>>>>> The boxes in question, most notably the more recent Fujitsu Esprimo > >>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms of what > >>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is switched off > >>>>>>> in the firmware. Again: GPT partition scheme. > >>>>>>> > >>>>>>> The system boots properly if a second partition of type "freebsd-boot" > >>>>>>> is applied and bootcode is properly applied via "gpart bootcode > >>>>>>> -b /boot/pmbr -p /boot/gptboot -i 2 ada0" (ada0 is the device). > >>>>>>>> > >>>>>>>> btw, you can try to validate the installed boot blocks by using recent > >>>>>>>> enough loader (usb or iso) and then you can use from OK prompt: > >>>>>>> > >>>>>>> lsdev provides me with the follwoing informations (CSM enabled): > >>>>>>> > >>>>>>> OK lsdev > >>>>>>> disk devices: > >>>>>>> disk0: BIOS DRIVE C ... > >>>>>>> > >>>>>>> disk0p1: EFI > >>>>>>> disk0p2: FreeBSD BOOT > >>>>>>> disk0p3: FreeBSD SWAP > >>>>>>> disk0p4: FreeBSD ZFS > >>>>>>> zfs devices: > >>>>>>> zfs:zroot > >>>>>>> > >>>>>>> OK chain disk0 > >>>>>>> open failed (so for disk0p{1-4}. > >>>>>>> > >>>>>>> OK chain zroot > >>>>>>> failed to read disk (just for completeness) > >>>>>> > >>>>>> > >>>>>> chain command does use only device name (such as disk0: or disk0p2: ), > >>>>>> but not zfs pool as device. I just found I haven?t ported the code to > >>>>>> read the file. > >>>>> > >>>>> ?? > >>>>> > >>>>>> > >>>>>> the point for chain command test is to see if the normal read and execute > >>>>>> would work, so in your case please try: > >>>>>> > >>>>>> chain disk0: > >>>>> > >>>>> As stated above, I did so, and the result is also mentioned above, I > >>>>> always get "open failed". > >>>>> This is the same for > >>>>> > >>>>> chain disk0 > >>>>> chain disk0p1 > >>>>> chain disk0p2 > >>>>> chain disk0p3 > >>>>> chain disk0p4 > >>>>> > >>>>> as already said. CSM is enabled in this case. > >>>> > >>>> sigh? chain command does take device as argument, device must always end > >>>> with colon?. in this case, the devil is in details:) as I wrote above, the > >>>> command should be: > >>>> > >>>> chain disk0: > >>>> > >>>> The disk0p1: etc will only work when partition boot code was installed > >>>> (which you most likely do not have - the only possible candidate could be > >>>> FreeBSD ZFS partition). > >>> > >>> The command "chain disk0:" works as expected (CSM enabled, GPT partition > >>> scheme, but with PMBR bootblock installed and freebsd-boot partition > >>> conatining gptzfsboot installed. > >>> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> to read pmbr (512B) and execute it. The expected outcome would be that > >>>>>> pmbr boot code would browse the GPT, read stage1 from disk0p2: and > >>>>>> execute it; stage1 would detect FreeBSD ZFS from disk0p4: and load and > >>>>>> execute /boot/loader. If that will happen, it means the boot code in our > >>>>>> stages is just fine, but the bios (CSM) does not load pmbr?. if thats > >>>>>> true, it would mean that you either need to use UEFI boot or need to have > >>>>>> some hack to fool the BIOS or just not use GPT on that machine with > >>>>>> CSM. > >>>>> > >>>>> To make it clear here: The only way to boot this box is using CSM (as it > >>>>> is the same with the ASRock boards mentioned earlier). But my intention > >>>>> is to disable CSM and use a GPT/UEFI environment only! And GPT/UEFI > >>>>> doesn't work with FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG. > >>>>> > >>>>> It would be nice if this could be fixed. I'm more interested in the fix on > >>>>> the recent Fujitsu device than the outdated ASRock crap, but if the fix > >>>>> for the Fujitsu Firmware could fix older issues as a byproduct, I'd > >>>>> appreciate that. > >>>>> > >>>>> Kind regards, > >>>>> > >>>> > >>>> ok, somehow I have lost that part of the discussion. Well, you wrote that > >>>> the UEFI boot fails when the first partition starts from sector 40 - does > >>>> it mean you have boot when the partition will start from some other > >>>> sector? I think, there is something else going on. > >>> > >>> Well, I simply try to describe what I "see" to make things disambiguous. I'm > >>> not familiar with the deeper insights of disk layouts on a binary level. So, > >>> you explained to me the reason, why ESP (EGI partition) starts at block 40. > >>> I compared that to the FreeBSD USB flash image FreeBSD provides, but this is > >>> another story since the image uses MBR scheme as I figured out. > >>> > >>> > >>>> > >>>> What you can do is to see if that firmware will offer you EFI shell option, > >>>> from there you can try to start the bootx64.efi manually and see what error > >>>> you will get. However, the number 1 cause for failing to start the > >>>> bootloader in UEFI is secure boot - we do not support it and secure boot > >>>> must be switched off. > >>>> > >>>> However, they seem to claim "The Secure Boot option is available in the > >>>> UEFI/BIOS of most if not all ASRock boards. It is disabled by default.? > >>>> > >>>> Still suggest to double check if thats really the case. Also, if the > >>>> bootx64.efi start will fail and no messages are appearing on screen, then > >>>> either there is something in firmware logs or you could get them from > >>>> trying to start bootx64.efi from UEFI shell. > >>> > >>> Since I'm with this problem since 2014 and try from time to time, be ausred > >>> that I tried every possible permutationof all reasonable options, even those > >>> nonsense, to get rid of that problem. > >>> > >>> I never had any problems with any other UEFI capable server/workstation > >>> firmware so far booting FreeBSD off in UEFI-native (GPT partition scheme, > >>> CSM disabled) so far - until now, when I ran into this Fujitsu ESPRIMO Q956 > >>> with the most recent firmware (as of lat week, week 29 of 2018) having the > >>> very same problems. > >>> > >>> > >>> > >>> I figured out something strange on the Fujitsu - and that is the same with > >>> the ASRock boards. > >>> > >>> We/I prepare some USB flash drives to boot a NanoBSD for a very small > >>> appliance, but nevertheless, the USB flash device is booted on Fujitsu > >>> servers with UEFI-only configurations. I assume at this point that > >>> disabling on the most recent Fujitsu firmwares on reasonable "new" hardware > >>> (not older than three years) will disable any(!) legacy BIOS capabilities. > >>> The same is assumed for the Fujitus ESPRIMO Q956. I can not speak for the > >>> ASRock A77 Pro4/m boards mentioned above/earlier, they are from 2012/2013 > >>> and "quite old". > >>> > >>> The NanoBSD image of ours doesn't have a "freebsd-boot" partition. The > >>> partition scheme of the flash device is GPT. The layout looks like this: > >>> > >>> gpart show -l da4 > >>> => 40 15425456 da4 GPT (7.4G) > >>> 40 2000 1 efiboot0 (1.0M) > >>> 2040 1453584 3 disk1a (710M) > >>> 1455624 4096 5 disk3 (2.0M) > >>> 1459720 13965776 - free - (6.7G) > >>> > >>> I created the flash with md, gpart and dd straightforward, efiboot0 is the > >>> ESP partition and its format/content is created via dd if=/boot/boot1.efifat > >>> of=/dev/da4p1 - I presume this is very simple. > >>> > >>> This USB flash device boots(!) successfully (UEFI!) on both the ASRock > >>> boards and the Esprimo Q956! > >>> > >>> But any SSD prepared the same way doesn't. Why? > >>> > >>> On the ASRock, I recall having fiddled around with HDD also for a while > >>> conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - I can't > >>> remember. > >>> > >>> In the lack of proper hardware I'm unable to check whether USB-attached HDD > >>> or SSD will boot or HDD will boot (just in case the local SATA has problems > >>> booting UEFI and USB not). > >>> > >>> Kind regards, > >>> > >>> Oliver > >>> > >> > >> Am. well. I think the suggestion to test out FAT32 is still good one to test. > >> This is because it is known that some vendors do not support booting > >> FAT12/FAT16 from HDD (the likely reason is that UEFI specification does not > >> tell which FAT must be supported, and only hint about FAT12/FAT16 in context > >> of removable devices). > > > > I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO Q956. It took me > > a time to circumvent the installer and I had to install the system manually. In > > that strain, I also "tried" to establish the ESP with FAT32, as Allen Jude > > suggested earlier. I didn't find any ad hoc help how to find out the format > > (FAT12/16/32) of the ESP, so I assume when using 12-CURRENT's or 11.2-RELENG's > > installer with AUTO-ZFS and GPT (UEFI) (only!) the resulting ESP is FAT12 or > > FAT16 (300mb by default). I also assume, that when dd'ing the /boo/boot1.efifat > > image to a partition, the format is FAT, but not FAT32. Therefore, I refomatted > > the manually created ESP (using "gpart add -t efi ...") using "newfs_msdos -F > > 32 -b xxx ...". I had to fiddle around a bit with option -b to fit in a proper > > format to meet a 512mb ESP - I'm not sure whether this is the proper option to > > deal with. When using the default and only -F32, the size of the partition has > > to be 4G at least I assume. Having done that, I copied the the content of > > boot1.efifat (mdconfig -t vnode ..., I guess we know the drill ...) to the > > newly formatted ESP to /boot/efi/ ... > > > > Having so far no knowledge of how to asure that the created ESP is FAT32, I > > assume it is FAT32. > > > > The result is negative on the ESPRIMO Q956. When disabling the CSM, the box is > > not willing to boot from SSD with the ESP prepared as decribed. So, a chance > > that this might still be due to a misconfiguration lies now within the -b > > option of newfs_msdos - if the -b option is assumed the proper option? > > > > At the moment, the ESP of the Esprimo is subject to changes, if you wish, but > > not in size, since it is limited to 512mb. > > > > Thanks and kind regards, > > > > Oliver > > Yea, i was hoping fstyp command would report the FAT type, but it does not (request for feature?:) FYI, the file(1) command is very good at disecting a disk image to tell you what the MBR looks like, and at looking at partitions if pointed at them with the -s option. It should be able to detect FAT12/16/32. root@x230a:/home/ISO/x # file -s /dev/md2s1 /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 ", root entries 512, sectors 1600 (volumes <=32 MB) , sectors/FAT 5, sectors/track 63, heads 1, serial number 0xbd4111ee, label: "EFISYS ", FAT (12 bit), followed by FAT > > However, the more annoying idea would be to install some OS which will boot with UEFI on this machine, then copy boot1.efi from freebsd to it (the default program the UEFI will load is ESP:EFI/boot/bootx64.efi in case of UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, we do not support EFI32. > > note that boot1.efi alone will not do much but printing on screen how it will search for freebsd, but for the purpose of the test it would suffice - that would give us confirmed working ESP file system (since the other os would be able to boot) and then we can confirm if boot1.efi itself is OK. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Jul 25 14:45:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06C7D104CDD5 for ; Wed, 25 Jul 2018 14:45:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F7C6811E0 for ; Wed, 25 Jul 2018 14:45:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-169-199-167.dyn.iinet.net.au [124.169.199.167]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w6PEjqWL081905 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2018 07:45:55 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: gcc/clang interoperability problem with a custom "samba" build in recent -current. To: Yuri Pankov , freebsd-current References: <3dd60a0d-7a5e-e9f0-3018-d09b5b8ac389@yuripv.net> From: Julian Elischer Message-ID: <05c98785-4812-e519-5555-3d2315d28a1f@freebsd.org> Date: Wed, 25 Jul 2018 22:45:46 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3dd60a0d-7a5e-e9f0-3018-d09b5b8ac389@yuripv.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 14:45:58 -0000 On 22/7/18 3:11 am, Yuri Pankov wrote: > Yuri Pankov wrote: >> Julian Elischer wrote: >>> I would really like ot get some pointers as to who are our tools >>> committers at the moment, in particular who might know about these >>> issues. >>> The main issue for me at the moment is the ability to compile the >>> aesni code in Samba from clang.. >>> >>> Julian >>> >>> >>> On 20/7/18 7:32 pm, Julian Elischer wrote: >>>> compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour >>>> when lld became the linker I think.. >>>> >>>> 1/ linking needed some directories added to some of the build >>>> scripts because previously apparently it looked in $SYSROOT/usr/lib >>>> by default and now it doesn't. >>>> >>>> 2/ compiling our samba produces a libtdb.so that has various symbols >>>> in it, (according to nm(1) ), but when we try link against it we get >>>> complaints about those symbols not being defined. >>>> >>>> 3/ an attempt to switch to using clang to compile everything >>>> leads to: >>>> >>>> >>>> "--aes-accel=intelaesni selected and compiler rejects >>>> -Wp,-E,-lang-asm. >>>> >>>> One wonders whether there is a clang equivalent of >>>> "-Wp,-E,-lang-asm" >>>> >>>> The AES acceleration is a configure option for the samba package. >>>> >>>> Apparently turning it on requires -Wp,-E,-lang-asm. >>>> >>>> which apparently gcc 4.2.1 has, but clang doesn't have. >>>> >>>>      FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) >>>> (based >>>>      on LLVM 6.0.1) >>>>      Target: x86_64-unknown-freebsd12.0 >>>>      Thread model: posix >>>>      InstalledDir: /usr/bin >>>> >>>> anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? >> >> In later GCC versions the cpp's -lang-asm seems to be deprecated in >> favor of -x assembler-with-cpp as it conflicts with -l option. >> >> Could you try changing the -Wp,-E,-lang-asm to >> -Wp,-E,-xassembler-with-cpp? > > Just tried it myself, and if you indeed mean the > third_party/aesni-intel/aesni-intel_asm.c, the following seems to > work for me: > > clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c when I try it I get lots of errors due to hte fact that there are assembled comments that start with # and they are all cited as errors by clang. I had to put '//' before about 80 lines line that. > >>>> possible work arrounds include: >>>> >>>> 1/ Get gcc/lld to produce a library from which lld can find the >>>> symbols >>>> >>>> 2/ find a way to compile this with clang but everything else with >>>> gcc? >>>> >>>> 3/ find a way to allow clang to use >>>> -Wp,-E,-lang-asm >>>> >>>> whatever that means >>>> >>>> >>>> Thoughts from any tools people? > > From owner-freebsd-current@freebsd.org Wed Jul 25 15:40:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5326A104DFAA for ; Wed, 25 Jul 2018 15:40:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC10C82AC7; Wed, 25 Jul 2018 15:40:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 65AB910AFD2; Wed, 25 Jul 2018 11:39:55 -0400 (EDT) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') To: Mark Millard , Konstantin Belousov , FreeBSD Current References: From: John Baldwin Message-ID: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> Date: Wed, 25 Jul 2018 08:39:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 25 Jul 2018 11:39:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:40:03 -0000 On 7/24/18 11:39 PM, Mark Millard wrote: > On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: > >> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >> (head -r336573 after the prior 6596's -r336565 ): >> >> --- all_subdir_lib/ofed --- >> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer >> atomic_store(&lock->cnt, 0); >> ^ >> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': >> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' >> if (atomic_fetch_add(&lock->cnt, 1) > 0) >> ^~ >> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': >> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' >> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >> ^~ >> . . . >> --- all_subdir_lib/ofed --- >> *** [acm.o] Error code 1 >> >> >> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >> -r336700 ) still shows this type of error. > > > [I should have a subject with "head -r336568 through -r336570 . . .".] > > From what I can tell looking around having something like: > > if (atomic_fetch_add(&lock->cnt, 1) > 0) > > involve a __atomic_fetch_add indicates that: > > /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h > > was in use instead of FreeBSD's stdatomic.h file. > > If this is right, then the issue may be tied to head -r335782 > implicitly changing the order of the include file directory > searching for builds via the devel/*-gcc . > > (I reverted -r335782 in my environment some time ago and have > not run into this problem in my context so far.) C11 atomics should work fine with compiler-provided headers since they are a part of the language (and the system stdatomic.h simply attempts to mimic the compiler-provided header in case it is missing). Simple standalone tests of _Atomic(int) with GCC don't trigger those failures when using its stdatomic.h, so there is probably something else going on with kernel includes being used while building the library, etc. The last time we had this issue with stdarg.h it was because a header shared between the kernel and userland always used '' which is correct for the kernel but not for userland. -- John Baldwin From owner-freebsd-current@freebsd.org Wed Jul 25 17:09:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9EA6104F7E4 for ; Wed, 25 Jul 2018 17:09:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (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 8944C8580F for ; Wed, 25 Jul 2018 17:09:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 0FhAYMcVM1lXXDL.56Q_JYeAcgFhYLTvgMyG8kCkKG4Fxj0XXVjaI4PzYA8XfCp lvakjVJk.umz77q.33b1WnIdbTbypaoepsDjEIwwW0ALGD0d8Ag7SBVkm5VwDvSJQOJgdD0gue_K 0FEmruM0kd3fucOZrO9VdAkzoSzk4pDGnerMBsPAdL3zuvloBtfSSoqJu965B4xVXuEWe.uTIGJP JDCSMFs5RjXzxkytwotuE._vXs4TaocBrLYCLO6KH24OEwrbfT3ThkLA31Ns.pqW4TijBepF8oPm WKV0IHNmjXaPZBg_M4aQrdNxMzU7pmflRM7rTtZQBhq5lUfBTnfGHzUnGDGOgutDQRRipt5YRIRw 4f8hHCzT_A0N_9Ca5tDMGSSSdIpWVrTzPyDfWJOQZ5xY97s0ak1_yo.RHe_Gad29SU4w1qZOCtXw t1WpJwYrKVUkWX7YlQH6nXKF8fGm0ll1PeeYnNSr_qKB6X8efBXtLs4AIDFhbOzJXiX9DVPENx9j .tj8dBnbvhtUwfRn0qvHwfuNo1cUVS..JB3TcQANyN8otWBESuCIezp1ObL5zms1R5tGxEJ9liUX v_XkA2FnNiDlxeHEt8HKnMOtZhvigQJz8JFgPuz.pdY5vYRpJvDUFZFG4XpKtJrVPfafYHCyo6au uHHDIwxPKA1c6LHWl7sYM.y.jmZtgM1mIQ7.kbNf3NgHvy72HcWrUpBjOkhxMVuN213MIyksUsPt DH_LsSgVvo2KvjGokZbHGJ7Mb3HYF7Nnk7GkBpKL8dcmbgtplC3H7Aamc6vn6nsR1Ui6IoI1b4iL _cdHc29spHYS6XUzE9c6wZ3NImjOKS1YxfWQMw7elngRAa6KueV2vNYGukH.RcHzJ9Hktb2jcxSb U.Ev_16CG26h.fPO.R0LgGx43CwFp_fLaaCCsr2IW3wfROR2aPsziq4BE.RifUA17kOVaaPaj6.r IdCcGwfHmqHffX0wePKECVpcVlz8aBSkDYq_lTTqs85wX1jO8M_vT61H8KL4U7vdhWdVj4Q4AWdg nSjQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 25 Jul 2018 17:09:18 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 71bbae85b95da5146ebb7afc44545263; Wed, 25 Jul 2018 17:09:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> Date: Wed, 25 Jul 2018 10:09:14 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:09:26 -0000 On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: > On 7/24/18 11:39 PM, Mark Millard wrote: >> On 2018-Jul-24, at 10:32 PM, Mark Millard = wrote: >>=20 >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>> (head -r336573 after the prior 6596's -r336565 ): >>>=20 >>> --- all_subdir_lib/ofed --- >>> In file included from = /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_init': >>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer >>> atomic_store(&lock->cnt, 0); >>> ^ >>> In file included from = /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': >>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' >>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>> ^~ >>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': >>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' >>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>> ^~ >>> . . . >>> --- all_subdir_lib/ofed --- >>> *** [acm.o] Error code 1 >>>=20 >>>=20 >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( = for >>> -r336700 ) still shows this type of error. >>=20 >>=20 >> [I should have a subject with "head -r336568 through -r336570 . . = .".] >>=20 >> =46rom what I can tell looking around having something like: >>=20 >> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>=20 >> involve a __atomic_fetch_add indicates that: >>=20 >> = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>=20 >> was in use instead of FreeBSD's stdatomic.h file. >>=20 >> If this is right, then the issue may be tied to head -r335782 >> implicitly changing the order of the include file directory >> searching for builds via the devel/*-gcc . >>=20 >> (I reverted -r335782 in my environment some time ago and have >> not run into this problem in my context so far.) >=20 > C11 atomics should work fine with compiler-provided headers since they > are a part of the language (and the system stdatomic.h simply attempts > to mimic the compiler-provided header in case it is missing). >=20 > Simple standalone tests of _Atomic(int) with GCC don't trigger those > failures when using its stdatomic.h, so there is probably something = else > going on with kernel includes being used while building the library, > etc. The last time we had this issue with stdarg.h it was because a > header shared between the kernel and userland always used = '' > which is correct for the kernel but not for userland. I did misread the headers. FreeBSD has the likes of: #if defined(__CLANG_ATOMICS) . . . #define atomic_fetch_add_explicit(object, operand, order) = \ __c11_atomic_fetch_add(object, operand, order) . . . #elif defined(__GNUC_ATOMICS) . . . #define atomic_fetch_add_explicit(object, operand, order) = \ __atomic_fetch_add(&(object)->__val, operand, order) . . . #endif . . . #define atomic_fetch_add(object, operand) = \ atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) so __atomic_fetch_add would occur. But so far I do not see the problem with -r335782 reverted. I last built -r336693 last night via devel/amd64-gcc (via xtoolchain). =46rom what I can tell FreeBSD defines: #if !defined(__CLANG_ATOMICS) #define _Atomic(T) struct { volatile T __val; } #endif and that struct is being used in &(object)->__val is what the error reports are about. So that would be, for example, &(&lock->cnt)->__val This would appear to suggest that __val itself had a type meeting: operand type struct for T in _Atomic(T) . (This is independent of just what the issue traces back to: just the net result on ci.freebsd.org . No claim that you are right or wrong here. I'll not be looking any more until this afternoon or night.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Jul 25 17:53:30 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D7B71050C59 for ; Wed, 25 Jul 2018 17:53:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B355C873DE; Wed, 25 Jul 2018 17:53:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 7679710AFD2; Wed, 25 Jul 2018 13:53:28 -0400 (EDT) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') To: Mark Millard References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> Cc: Konstantin Belousov , FreeBSD Current From: John Baldwin Message-ID: <7c4e995d-ec64-030a-ed84-7a211166b993@FreeBSD.org> Date: Wed, 25 Jul 2018 10:53:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 25 Jul 2018 13:53:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:53:30 -0000 On 7/25/18 10:09 AM, Mark Millard wrote: > > > On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: > >> On 7/24/18 11:39 PM, Mark Millard wrote: >>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>> >>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>> (head -r336573 after the prior 6596's -r336565 ): >>>> >>>> --- all_subdir_lib/ofed --- >>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer >>>> atomic_store(&lock->cnt, 0); >>>> ^ >>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': >>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' >>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>> ^~ >>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': >>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' >>>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>>> ^~ >>>> . . . >>>> --- all_subdir_lib/ofed --- >>>> *** [acm.o] Error code 1 >>>> >>>> >>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >>>> -r336700 ) still shows this type of error. >>> >>> >>> [I should have a subject with "head -r336568 through -r336570 . . .".] >>> >>> From what I can tell looking around having something like: >>> >>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>> >>> involve a __atomic_fetch_add indicates that: >>> >>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>> >>> was in use instead of FreeBSD's stdatomic.h file. >>> >>> If this is right, then the issue may be tied to head -r335782 >>> implicitly changing the order of the include file directory >>> searching for builds via the devel/*-gcc . >>> >>> (I reverted -r335782 in my environment some time ago and have >>> not run into this problem in my context so far.) >> >> C11 atomics should work fine with compiler-provided headers since they >> are a part of the language (and the system stdatomic.h simply attempts >> to mimic the compiler-provided header in case it is missing). >> >> Simple standalone tests of _Atomic(int) with GCC don't trigger those >> failures when using its stdatomic.h, so there is probably something else >> going on with kernel includes being used while building the library, >> etc. The last time we had this issue with stdarg.h it was because a >> header shared between the kernel and userland always used '' >> which is correct for the kernel but not for userland. > > I did misread the headers. FreeBSD has the likes of: > > #if defined(__CLANG_ATOMICS) > . . . > #define atomic_fetch_add_explicit(object, operand, order) \ > __c11_atomic_fetch_add(object, operand, order) > . . . > #elif defined(__GNUC_ATOMICS) > . . . > #define atomic_fetch_add_explicit(object, operand, order) \ > __atomic_fetch_add(&(object)->__val, operand, order) > . . . > #endif > . . . > #define atomic_fetch_add(object, operand) \ > atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) > > so __atomic_fetch_add would occur. > > But so far I do not see the problem with -r335782 reverted. I last built > -r336693 last night via devel/amd64-gcc (via xtoolchain). > > From what I can tell FreeBSD defines: > > #if !defined(__CLANG_ATOMICS) > #define _Atomic(T) struct { volatile T __val; } > #endif This looks wrong for modern GCC supporting C11 atomics. What is happening is that this is probably overriding the compiler's builtin _Atomic and then the compiler's stdatomic.h which doesn't look for __val but expects 'object' to be a plain int is then failing to compile. Just including sys/cdefs.h in my test program doesn't trigger the failure though. -- John Baldwin From owner-freebsd-current@freebsd.org Wed Jul 25 17:41:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9997105080C for ; Wed, 25 Jul 2018 17:41:40 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5432486A8B for ; Wed, 25 Jul 2018 17:41:39 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.0.208.133]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M3R1g-1fzufn1yzI-00qx5I; Wed, 25 Jul 2018 19:41:27 +0200 Date: Wed, 25 Jul 2018 19:40:51 +0200 From: "O. Hartmann" To: "Rodney W. Grimes" Cc: freebsd-current Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180725194118.37c2b442@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:KWQHk9xKB4AxDNZNLmAP2uUXKjpW0L3vrnNGHGb1BHXthLdQE8P Rl4Ar8S/Y0mmnA0+Xni4VQ2lIEnw9CHqOkhXp7iMUIpQhBt0eVIMBkAAvMBCpBOZeyJfsDd PxWbalT4PZz7mhK+I8Ro4KPB1CBCOclfdirERmB/k0KGqwA5Oqh1dYE91unlTxS4q1/oznL yWR5zs9ruinvog4k+WyDQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:o20LTi9NNgw=:jJFn6qq2g/jgfbE/RS64MW 7t8yWVHwzl/eBAX6ujp+zt7LvTZwxl/R2m0VP91Zg2WHH9q/43LiQTnAmKZpB6McOPEdpOTR/ alz5PcOARCYaZnCdss5dN2XWgSZRmibgHG3L5f7tC1dG4xQBQbw7kTXTzniGpC11E5th5yfy8 SFQb9pevzP7pYOvI/Bfu+LkYIsu5ft7YMnnS4maGdYieiIH+mAkE+rnOwm3FEI+rzgjbLJUKD qvab/Po2vHgT/W9h6o5j5x1LgdnEgyuIcYSm8dJDfMUKmjnZWJk0EgrFamI7SGz5M8UBxFnR/ qltKWBG9DIBYnKUKrnYdePu2vhNHNlYj4wCWrsZ19YMkfvwKBfzpSvkxuQN7/cyFimkXObjnE sIPRj3zuHamKp8p7dIACvGVZlsbLnHZUuEngaRaHHdICJC2ivuXrQcbPMC47BghsAgUOTmAFg RPRFalujVNgMnWKTUUWAq2y0gh0KJsvYOto3G6uV5J39qT5zQXf+mDDk2nTBfYnpPZ1QK5VPk DIcDC9+X7Jcoaih6tVySGKSC1Ui9uYOs3nOmEoQRYwAjv5/rxcI9D+a3gJzW+DnwoDFZRLlya VXPpFkeR4R8+uWFRhb1nHWcf79GZxHnPXFhLEIYmMNpeX3x9GAGn0WTYXh69iu2l+e4uH9zqR 46XHMkDprsGR4HfDXKHyP+wI+8KppW09Q6JEXto60kjHq4dQ0JZHwdVFsRqH08NUXjKcp7Ftz NpmrgHEOiVjIwUIry9b8rSU2MIReCcNAbgNZDIpeuPS5Cb/oIj7NJnSu4BySwYXj6US0FboD2 DvUCe0H X-Mailman-Approved-At: Wed, 25 Jul 2018 19:33:35 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:41:41 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIFdl ZCwgMjUgSnVsIDIwMTggMDc6MzA6MzIgLTA3MDAgKFBEVCkNCiJSb2RuZXkgVy4gR3JpbWVzIiA8 ZnJlZWJzZC1yd2dAcGR4LnJoLkNOODUuZG5zbWdyLm5ldD4gc2NocmllYjoNCg0KWy4uLl0NCg0K PiA+IFllYSwgaSB3YXMgaG9waW5nIGZzdHlwIGNvbW1hbmQgd291bGQgcmVwb3J0IHRoZSBGQVQg dHlwZSwgYnV0IGl0IGRvZXMgbm90IChyZXF1ZXN0DQo+ID4gZm9yIGZlYXR1cmU/OikgIA0KPiAN Cj4gRllJLCB0aGUgZmlsZSgxKSBjb21tYW5kIGlzIHZlcnkgZ29vZCBhdCBkaXNlY3RpbmcgYSBk aXNrIGltYWdlIHRvIHRlbGwNCj4geW91IHdoYXQgdGhlIE1CUiBsb29rcyBsaWtlLCBhbmQgYXQg bG9va2luZyBhdCBwYXJ0aXRpb25zIGlmIHBvaW50ZWQgYXQNCj4gdGhlbSB3aXRoIHRoZSAtcyBv cHRpb24uICBJdCBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3QgRkFUMTIvMTYvMzIuDQo+IA0KPiBy b290QHgyMzBhOi9ob21lL0lTTy94ICMgZmlsZSAtcyAvZGV2L21kMnMxDQo+IC9kZXYvbWQyczE6 IERPUy9NQlIgYm9vdCBzZWN0b3IsIGNvZGUgb2Zmc2V0IDB4M2MrMiwgT0VNLUlEICJCU0Q0LjQg ICIsIHJvb3QgZW50cmllcw0KPiA1MTIsIHNlY3RvcnMgMTYwMCAodm9sdW1lcyA8PTMyIE1CKSAs IHNlY3RvcnMvRkFUIDUsIHNlY3RvcnMvdHJhY2sgNjMsIGhlYWRzIDEsIHNlcmlhbA0KPiBudW1i ZXIgMHhiZDQxMTFlZSwgbGFiZWw6ICJFRklTWVMgICAgICIsIEZBVCAoMTIgYml0KSwgZm9sbG93 ZWQgYnkgRkFUDQoNClRoYW5rcyBmb3IgdGhpcyB2ZXJ5IGhlbHBmdWwgaGludCENCg0KPiANCj4g PiANCj4gPiBIb3dldmVyLCB0aGUgbW9yZSBhbm5veWluZyBpZGVhIHdvdWxkIGJlIHRvIGluc3Rh bGwgc29tZSBPUyB3aGljaCB3aWxsIGJvb3Qgd2l0aCBVRUZJDQo+ID4gb24gdGhpcyBtYWNoaW5l LCB0aGVuIGNvcHkgYm9vdDEuZWZpIGZyb20gZnJlZWJzZCB0byBpdCAodGhlIGRlZmF1bHQgcHJv Z3JhbSB0aGUgVUVGSQ0KPiA+IHdpbGwgbG9hZCBpcyBFU1A6RUZJL2Jvb3QvYm9vdHg2NC5lZmkg IGluIGNhc2Ugb2YgVUVGSTY0IGFuZA0KPiA+IEVTUDpFRkkvYm9vdC9ib290aWEzMi5lZmkgZm9y IEVGSTMyLiBIb3dldmVyLCB3ZSBkbyBub3Qgc3VwcG9ydCBFRkkzMi4NCj4gPiANCj4gPiBub3Rl IHRoYXQgYm9vdDEuZWZpIGFsb25lIHdpbGwgbm90IGRvIG11Y2ggYnV0IHByaW50aW5nIG9uIHNj cmVlbiBob3cgaXQgd2lsbCBzZWFyY2gNCj4gPiBmb3IgZnJlZWJzZCwgYnV0IGZvciB0aGUgcHVy cG9zZSBvZiB0aGUgdGVzdCBpdCB3b3VsZCBzdWZmaWNlIC0gdGhhdCB3b3VsZCBnaXZlIHVzDQo+ ID4gY29uZmlybWVkIHdvcmtpbmcgRVNQIGZpbGUgc3lzdGVtIChzaW5jZSB0aGUgb3RoZXIgb3Mg d291bGQgYmUgYWJsZSB0byBib290KSBhbmQgdGhlbg0KPiA+IHdlIGNhbiBjb25maXJtIGlmIGJv b3QxLmVmaSBpdHNlbGYgaXMgT0suICANCj4gDQoNCg0KDQotIC0tIA0KTy4gSGFydG1hbm4NCg0K SWNoIHdpZGVyc3ByZWNoZSBkZXIgTnV0enVuZyBvZGVyIMOcYmVybWl0dGx1bmcgbWVpbmVyIERh dGVuIGbDvHINCldlcmJlendlY2tlIG9kZXIgZsO8ciBkaWUgTWFya3QtIG9kZXIgTWVpbnVuZ3Nm b3JzY2h1bmcgKMKnIDI4IEFicy4gNCBCRFNHKS4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0t LS0tDQoNCmlMVUVBUk1LQUIwV0lRUVpWWk16QXR3QzJULzg2VHJTNTI4ZnlGaFlsQVVDVzFpMlB3 QUtDUkRTNTI4ZnlGaFkNCmxGejVBZjlNWTQxaG9BTkQ0T29LQ093RXhBTTdvUVlWQ3BIU3orbW85 NE9CVnFTQ3FjbnByZHZkRTJDMStQaU4NClV6YTdsTXZCOEtWU3FjeXh1WWJJRkQwRTVBNGJBZ0Nr L2x6S3dFOWhUUEJ0NGdkQng0dDdOL1hQYWZPRUJFR00NCjhpckdvektiQXZpa1NraEFRVE1QdHd5 RSs4NjFBdkt5MkR3MW8rbVFvNEFmaWtKSTBkZ3ENCj05Y0tMDQotLS0tLUVORCBQR1AgU0lHTkFU VVJFLS0tLS0NCg== From owner-freebsd-current@freebsd.org Wed Jul 25 17:53:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B2AC1050C66 for ; Wed, 25 Jul 2018 17:53:31 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7742873E0; Wed, 25 Jul 2018 17:53:30 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.0.208.133]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M1Wcz-1fxyx82UMD-00tTDG; Wed, 25 Jul 2018 19:53:23 +0200 Date: Wed, 25 Jul 2018 19:52:50 +0200 From: "O. Hartmann" To: Toomas Soome Cc: freebsd-current , Allan Jude Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180725195317.027a8acd@thor.intern.walstatt.dynvpn.de> In-Reply-To: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> <20180725095926.7d52a15a@freyja.zeit4.iv.bundesimmobilien.de> <2FCF2BCC-05E5-466A-B1AE-90300990ED1A@me.com> <20180725111032.1632b885@freyja.zeit4.iv.bundesimmobilien.de> <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:opNZfRMYIQOzE24OHhVDwXQmDp5XU2yNzZDq+1MLbCDvt7/qFJ0 Yjuu3/7MNhzB1nRZcODnAG07DBKGF90s+eAh66luXBaC6EIv8DaYnUsOf88pj+G8Fj4/b3f fRZQT2AKDyTaFfD5QBQcg/EgOYj1ZRpAblnoa69nR0raZUmlVBamocONq8Nvp2gT5sR45ul Rk7Xxgg1lLps45mkRV0kw== X-UI-Out-Filterresults: notjunk:1;V01:K0:dtSZXN8W5yg=:rDEnqv8vByGXZZoSt182sA 9QwkweO2nFUe2Adh4+Uo4+nTAjhRd0hZEJZzOxZdb0PMRLzZN4QzheX95m1MJW4mxpQy78rVR zVCeh9WMJljGFQ1h8XinsBjTK6SIEKvjdIlJi7YC3/c0ZFt2NT8inSxXTaUKY8CFzD118yWVU 7NAmB06U3rXVfPNAG1U4GHYCKcR/Pz7+97rGRbhvGFutMHeZpKZwSjx7ruS8uKfhFDMETxNa1 nz9K2xUr5SyIgFOorYtobLlF03j/7HOObM5zber8UyRfVcC2+4sMkjD092QxAO4YuQjmUwn7K XvBnRpEVIzqnVRUcSTcSYG5zKZa5qT2SaiTEvsVKFCOf70KCqtGtnN/1VIkgBEOF349pQ8DW9 jYfpjRTCDIIV/rQGmOoyZr1pTqV08sgH8UDZ8rZNxnHvBmEuudI5mw+b6gDU6qxFnHujKCWRf xOoAo9ITAj0KRaGI1DywRnBXg0EYE+0dYBqEnvy6c8wjaTzJ4NodrCtgl6jIEJyPqF1LCF0/n lvKHh4MQqIDb3FpplxiWwUssoraHMucXi0VlGyw3VbUvrSjg/fyaGrviiCt/D3MGTSxutdDbT yfJ5ff53PzM/Q/6ZaKOfSQCqkJsiv1k3v+UE2rwCBPcBsu3aSdfqOW8ZKX3dyDLRD0YoMpnqz /05cQCeo+3Mn/NmGxMvNcufjwjJ73XI34ajiN+Z5jV1oFumeh+T0vV7DXshwsfxMdyZF0dtP4 /Sh9iRVE83GeCmzqrIWP75povt4piEzKpDsZn/bKBstO4Xv9IRt2nwGX23F9Yqp8yiCB29pJA OpEUiQc X-Mailman-Approved-At: Wed, 25 Jul 2018 19:41:37 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:53:31 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIFdl ZCwgMjUgSnVsIDIwMTggMTI6MjY6MTMgKzAzMDANClRvb21hcyBTb29tZSA8dHNvb21lQG1lLmNv bT4gc2NocmllYjoNCg0KPiA+IE9uIDI1IEp1bCAyMDE4LCBhdCAxMjoxMCwgTy4gSGFydG1hbm4g PG8uaGFydG1hbm5Ad2Fsc3RhdHQub3JnPiB3cm90ZToNCj4gPiANCj4gPiBPbiBXZWQsIDI1IEp1 bCAyMDE4IDExOjQ2OjA3ICswMzAwDQo+ID4gVG9vbWFzIFNvb21lIDx0c29vbWVAbWUuY29tPiB3 cm90ZToNCj4gPiAgIA0KPiA+Pj4gT24gMjUgSnVsIDIwMTgsIGF0IDEwOjU5LCBPLiBIYXJ0bWFu biA8b2hhcnRtYW5uQHdhbHN0YXR0Lm9yZz4gd3JvdGU6DQo+ID4+PiANCj4gPj4+IE9uIFR1ZSwg MjQgSnVsIDIwMTggMDg6NTM6MzYgKzAzMDANCj4gPj4+IFRvb21hcyBTb29tZSA8dHNvb21lQG1l LmNvbT4gd3JvdGU6DQo+ID4+PiANCj4gPj4+IA0KPiA+Pj4gSGVsbG8gIFRvb21hcyBTb29tZSwN Cj4gPj4+IA0KPiA+Pj4gSSBDQyBBbGxhbiBKdWRlIHNpbmNlIEkgZGlzY292ZXJlZCBzb21ldGhp bmcgIHdlaXJkIHRvZGF5IHJlZ2FyZGluZyB0aGUgVUVGSQ0KPiA+Pj4gYm9vdCBjYXBhYmlsaXRp ZXMgb2YgVVNCIGZsYXNoIGRldmljZXMgYW5kIFNTRHMuIFNlZSBiZWxvdy4NCj4gPj4+ICAgDQo+ ID4+Pj4+IE9uIDI0IEp1bCAyMDE4LCBhdCAwODoxNiwgTy4gSGFydG1hbm4gPG9oYXJ0bWFubkB3 YWxzdGF0dC5vcmc+IHdyb3RlOg0KPiA+Pj4+PiANCj4gPj4+Pj4gT24gTW9uLCAyMyBKdWwgMjAx OCAxMDo1NjowNCArMDMwMA0KPiA+Pj4+PiBUb29tYXMgU29vbWUgPHRzb29tZUBtZS5jb20+IHdy b3RlOg0KPiA+Pj4+PiAgIA0KPiA+Pj4+Pj4+IE9uIDIzIEp1bCAyMDE4LCBhdCAxMDoyNywgTy4g SGFydG1hbm4gPG9oYXJ0bWFubkB3YWxzdGF0dC5vcmc+IHdyb3RlOg0KPiA+Pj4+Pj4+IA0KPiA+ Pj4+Pj4+IE9uIEZyaSwgMTMgSnVsIDIwMTggMTg6NDQ6MjMgKzAzMDANCj4gPj4+Pj4+PiBUb29t YXMgU29vbWUgPHRzb29tZUBtZS5jb20gPG1haWx0bzp0c29vbWVAbWUuY29tPj4gd3JvdGU6DQo+ ID4+Pj4+Pj4gICANCj4gPj4+Pj4+Pj4+IE9uIDEzIEp1bCAyMDE4LCBhdCAxNzo0NCwgTy4gSGFy dG1hbm4gPG8uaGFydG1hbm5Ad2Fsc3RhdHQub3JnDQo+ID4+Pj4+Pj4+PiA8bWFpbHRvOm8uaGFy dG1hbm5Ad2Fsc3RhdHQub3JnPj4gd3JvdGU6DQo+ID4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+IC0t LS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gPj4+Pj4+Pj4+IEhhc2g6IFNIQTUx Mg0KPiA+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+PiBBbSBGcmksIDEzIEp1bCAyMDE4IDE0OjI2OjUx ICswMzAwDQo+ID4+Pj4+Pj4+PiBUb29tYXMgU29vbWUgPHRzb29tZUBtZS5jb20gPG1haWx0bzp0 c29vbWVAbWUuY29tPg0KPiA+Pj4+Pj4+Pj4gPG1haWx0bzp0c29vbWVAbWUuY29tIDxtYWlsdG86 dHNvb21lQG1lLmNvbT4+PiBzY2hyaWViOiAgICAgICANCj4gPj4+Pj4+Pj4+Pj4gT24gMTMgSnVs IDIwMTgsIGF0IDE0OjAwLCBPLiBIYXJ0bWFubiA8b2hhcnRtYW5uQHdhbHN0YXR0Lm9yZz4NCj4g Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBUaGUgcHJv YmxlbSBpcyBzb21lIGtpbmQgb2Ygd2VpcmQuIEkgZmFjZSBVRUZJIGJvb3QgcHJvYmxlbXMgb24g R1BUDQo+ID4+Pj4+Pj4+Pj4+IGRyaXZlcyB3aGVyZSB0aGUgZmlyc3QgcGFydGl0aW9uIGJlZ2lu cyBhdCBibG9jayA0MCBvZiB0aGUgaGRkL3NzZC4NCj4gPj4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+ Pj4+IEkgaGF2ZSB0d28gaG9zdCBpbiBwcml2YXRlIHVzZSBiYXNlZCBvbiBhbg0KPiA+Pj4+Pj4+ Pj4+PiBvdXRkYXRlZCBBU1JvY2sgWjc3LVBybzQtTSBhbmQgWjc3LVBybzQgbWFpbmJvYXJkIChJ dnlCcmlkZ2UsIFNvY2tldA0KPiA+Pj4+Pj4+Pj4+PiBMR0ExMTU1KS4gQm90aCBib2FyZHMgYXJl IGVxdWlwdGVkIHdpdGggdGhlIGxhdGVzIG9mZmljaWFsIGF2YWlsYWJsZQ0KPiA+Pj4+Pj4+Pj4+ PiBBTUkgZmlybXdhcmUgcmV2aXNpb24sIGRhdGluZyB0byAyMDEzLiBUaGlzIGlzIGZvciB0aGUg Wjc3LVBybzQtTQ0KPiA+Pj4+Pj4+Pj4+PiByZXZpc2lvbiAyLjAgKDIwMTMvNy8yMykgYW5kIGZv ciB0aGUgWjc3IFBybzQgcmV2aXNpb24gMS44DQo+ID4+Pj4+Pj4+Pj4+ICgyMDEzLzcvMTcpLiBG b3IgYm90aCBib2FyZHMgYSBCRVRBIHJldmlzaW9uIGZvciB0aGUNCj4gPj4+Pj4+Pj4+Pj4gU3Bl Y3RyZS9NZWx0ZG93biBtaXRpZ2F0aW9uIGlzIGF2YWlsYWJsZSwgYnV0IEkgZGlkbid0IHRlc3Qg dGhhdC4NCj4gPj4+Pj4+Pj4+Pj4gQnV0IHBsZWFzZSByZWFkLg0KPiA+Pj4+Pj4+Pj4+PiANCj4g Pj4+Pj4+Pj4+Pj4gVGhlIHRoaXJkIGJveCBJIHJlYWxpc2VkIHRoaXMgcHJvYmxlbSBpcyBhIGJy YW5kIG5ldyBGdWppdHN1IEVzcHJpbW8NCj4gPj4+Pj4+Pj4+Pj4gUTk1NiwgYWxzbyBBTUkgZmly bXdhcmUsIGF0IFY1LjAuMC4xMSBSIDEuMjYuMCBmb3IgMzQxMy1BMXgsIGRhdGUNCj4gPj4+Pj4+ Pj4+Pj4gMDUvMjUvMjAxOCAob3IgMjAxODA1MjUpLg0KPiA+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+ Pj4+Pj4gSW5zdGFsbGluZyBvbiBhbnkga2luZCBvZiBIREQgb3IgU1NEIG1hbnVhbGx5IG9yIHZp YSBic2RpbnN0YWxsIHRoZQ0KPiA+Pj4+Pj4+Pj4+PiBPUyB1c2luZyBVRUZJLW9ubHkgYm9vdCBt ZXRob2Qgb24gYSBHUFQgcGFydGl0aW9uZWQgZGV2aWNlIGZhaWxzLg0KPiA+Pj4+Pj4+Pj4+PiBU aGUgQVNSb2NrIGJvYXJkcyBqdW1wIGltbWVkaWF0ZWx5IGludG8gdGhlIGZpcm13YXJlLCB0aGUg RnVqaXRzdQ0KPiA+Pj4+Pj4+Pj4+PiBvZmZlcnMgc29tZSBraW5kIG9mIENQVS9NZW1vcnkvSERE IHRlc3QgZmFjaWxpdHkuDQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBJZiBvbiBib3Ro IHR5cGUgb2YgdmVuZG9yL2JvYXJkcyBDU00gaXMgZGlzYWJsZWQgYW5kIFVFRkkgYm9vdCBvbmx5 DQo+ID4+Pj4+Pj4+Pj4+IGlzIGltcGxpZWQsIHRoZSBNQlIgcGFydGl0aW9uZWQgRnJlZUJTRCBp bnN0YWxsYXRpb24gVVNCIGZsYXNoDQo+ID4+Pj4+Pj4+Pj4+IGRldmljZSBkb2VzIGJvb3QgaW4g VUVGSSEgSSBndWVzcyBJIGNhbiBhc3N1bWUgdGhpcyB3aGVuIHRoZSB3ZWxsDQo+ID4+Pj4+Pj4+ Pj4+IGtub3duIGNsdW1zeSA4MHgyNSBjaGFyIGNvbnNvbGUgc3VkZGVubHkgZ2V0cyBicmlnaHQg YW5kIHNoaW55IHdpdGgNCj4gPj4+Pj4+Pj4+Pj4gYSBtdWNoIGhpZ2hlciByZXNvbHRpb24gYXMg bG9uZyB0aGUgR1BVIHN1cHBvcnRzIEVGSSBHT1AuIExvb2tpbmcNCj4gPj4+Pj4+Pj4+Pj4gd2l0 aCBncGFydCBhdCB0aGUgVVNCIGZsYXNoIGRyaXZlcyByZXZlYWxzIHRoYXQgdGhlIEVGSSBwYXJ0 aXRpb24NCj4gPj4+Pj4+Pj4+Pj4gc3RhcnRzIGF0IGJsb2NrIDEgb2YgdGhlIGRldmljZSBhbmQg dGhlIGRldmljZSBoYXMgYSBNQlIgbGF5b3V0LiBJDQo+ID4+Pj4+Pj4+Pj4+IGhhdmVuJ3QgZm91 bmQgYSB3YXkgdG8gZm9yY2UgdGhlIEdQVCBzY2hlbWUsIHdoZW4gaW5pdGlhbGlzZWQgdmlhDQo+ ID4+Pj4+Pj4+Pj4+IGdwYXJ0LCB0byBsZXQgdGhlIHBhcnRpdGlvbnMgc3RhcnQgYXQgYmxvY2sg MS4gVGhpcyBtaWdodCBiZSBhIG5haXYNCj4gPj4+Pj4+Pj4+Pj4gdGhpbmtpbmcsIHNvIHBsZWFz ZSBiZSBwYXRpZW50IHdpdGggbWUuDQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBJIGRv IG5vdCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIHdlbGwta25vd24gaXNzdWUuIE9uIHRoZSBBU1Jv Y2sNCj4gPj4+Pj4+Pj4+Pj4gYm9hcmRzLCBJIHRyaWVkIHllYXJzIGFnbyBzb21lIExpbnV4UmVk IEhhdCBhbmQgU3VzZSB3aXRoIFVFRkkgYW5kDQo+ID4+Pj4+Pj4+Pj4+IHRoYXQgd29ya2VkIC0g RnJlZUJTRCBub3QuIEkgZ2F2ZSB1cCBvbiB0aGF0IHRoYXQgdGltZS4gTm93LCBoYXZpbmcNCj4g Pj4+Pj4+Pj4+Pj4gdGhlIHZlcnkgc2FtZSBpc3N1ZXMgd2l0aCBhIG5ldyBGdWppdHN1IHN5c3Rl bSwgbGVhdmVzIG1lIHdpdGggdGhlDQo+ID4+Pj4+Pj4+Pj4+IGltcHJlc3Npb24gdGhhdCBGcmVl QlNEJ3MgVUVGSSBpbXBsZW1lbnRhdGlvbiBtaWdodCBoYXZlIHByb2JsZW1zDQo+ID4+Pj4+Pj4+ Pj4+IEknbSBub3QgYXdhcmUgb2YuDQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBDYW4g c29tZW9uZSBzaGVkIHNvbWUgbGlnaHQgb250byB0aGlzPyANCj4gPj4+Pj4+Pj4+Pj4gICANCj4g Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBUaGUgZmlyc3QgdGhpbmcgdG8gY2hlY2sgaXMgaWYg dGhlIHNlY3VyZSBib290IGlzIGRpc2FibGVkLiBXZSBkbyBub3QNCj4gPj4+Pj4+Pj4+PiBzdXBw b3J0IHNlY3VyZSBib290IGF0IGFsbCBhdCB0aGlzIHRpbWUuICAgICAgICAgIA0KPiA+Pj4+Pj4+ Pj4gDQo+ID4+Pj4+Pj4+PiBTZWN1cmUgYm9vdCBpcyBpbiBldmVyeSBzY2VuYXJpbyBkaXNhYmxl ZCENCj4gPj4+Pj4+Pj4+ICAgDQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gSWYgeW91IGhh dmUgZWZpIG9yIGJpb3MgdmVyc2lvbiBydW5uaW5nIC0geW91IGNhbiBjaGVjayBmcm9tIGVpdGhl cg0KPiA+Pj4+Pj4+Pj4+IGNvbnNvbGUgdmFyaWFibGUgdmFsdWUgKGl0IGNhbiBoYXZlIGVmaSBv ciB2aWRjb25zb2xlIG9yIGNvbWNvbnNvbGUpDQo+ID4+Pj4+Pj4+Pj4gb3IgYmV0dGVyIHlldCwg c2VlIGlmIGVmaS12ZXJzaW9uIGlzIHNldCAoc2hvdyBlZmktdmVyc2lvbikgLSBpZg0KPiA+Pj4+ Pj4+Pj4+IGVmaS12ZXJzaW9uIGlzIG5vdCBzZXQsIGl0IGlzIEJJT1MgbG9hZGVyIHJ1bm5pbmcu IEFub3RoZXIgaW5kaXJlY3QNCj4gPj4+Pj4+Pj4+PiB3YXkgaXMgdG8gc2VlIGxzZGV2IC12LCB3 aXRoIGRldmljZSBwYXRocyBwcmVzZW50LCBpdCBpcw0KPiA+Pj4+Pj4+Pj4+IHVlZmk6KSAgICAg ICAgICANCj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4gV2hhdCBhcmUgeW91IHRhbGtpbmcgYWJv dXQ/DQo+ID4+Pj4+Pj4+PiBXaGF0IGlzIHRoZSBwb2ludCBvZiBlbnRyeSAtIHJ1bm5pbmcgc3lz dGVtLCBsb2FkZXI/DQo+ID4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+IHN5c2N0IG1hY2hkZXAuYm9v dG1ldGhvZDogQklPUw0KPiA+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+PiBUaGlzIG1ha2VzIG1lIHF1 aXRlIHN1cmUgdGhhdCB0aGUgc3lzdGVtIGhhcyBib290ZWQgdmlhIEJJT1MgLSBhcyBJJ20NCj4g Pj4+Pj4+Pj4+IHN1cmUgc2luY2UgSSd2ZSBjaGVja2VkIHRoYXQgbWFueSB0aW1lcy4gVUVGSSBk b2Vzbid0IHdvcmsgb24gdGhvc2UNCj4gPj4+Pj4+Pj4+IHN5c3RlbXMgd2l0aCBGcmVlQlNELiBJ J20gbm90IHN1cmUgYW50bW9yZSwgYnV0IEkgdHJpZWQgYWxzbyBXaW5kb3dzIDcNCj4gPj4+Pj4+ Pj4+IG9uIHRob3NlIG1haW5ib2FyZHMgYm9vdGluZyB2aWEgVUVGSSAtIGFuZCBJIG1pZ2h0IHJl Y2FsbCB0aGF0IHRoZXkNCj4gPj4+Pj4+Pj4+IGZhaWxlZCBhbHNvLiBJIGFsc28gcmVjYWxsIHRo YXQgdGhlcmUgd2VyZSBpc3N1ZXMgd2l0aCBlYXJsaWVyIFVFRkkNCj4gPj4+Pj4+Pj4+IHZlcnNp b25zIHJlZ2FyZGluZyBib290aW5nIG9ubHkgV2luZG93cyA4LzguMSAtIGFuZCBub3RoaW5nIGVs c2UsIGJ1dA0KPiA+Pj4+Pj4+Pj4gdGhlIGZhY3QgdGhhdCBMaW51eCB3b3JrZWQgY29uZnVzZXMg bWUgYSBiaXQuDQo+ID4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+IElmIHRoaXMgQVNSb2NrIGNyYXAg KG5ldmVyIGV2ZXIgYWdhaW4gdGhpcyBicmFuZCEpIGRvZXNuJ3Qgd29yayBhdA0KPiA+Pj4+Pj4+ Pj4gYWxsIC0gd2hvIGNhcmVzLCBJIGludGVuZCB0byBwdXJjaGFzZSBuZXcgc2VydmVyIGdyYWRl IGhhcmR3YXJlLiBCdXQNCj4gPj4+Pj4+Pj4+IHRoZSBtb3JlIHB1enpsaW5nIGlzc3VlIGlzIHdp dGggdGhlIEZ1aml0c3UsIHdoaWNoIEkgY29uc2lkZXIgc2VyaW91cw0KPiA+Pj4+Pj4+Pj4gYW5k IGZyb20gdGhlIGJlaGF2aW91ciB0aGUgRnVqaXRzdSBmYWlsdXJlIGxvb2tzIGV4YWN0bHkgbGlr ZSB0aGUNCj4gPj4+Pj4+Pj4+IEFTUm9jayAtIFdpbmRvd3MgNyB3b3JrcywgUmVkSGF0IDcuNSB3 b3JrcyAoSSBhc3N1bWUgSSBjYW4gdHJ1c3QgdGhlDQo+ID4+Pj4+Pj4+PiBGaXJtd2FyZSBzZXR0 aW5ncyB3aGVuIEkgZGlzYWJsZSBDU00gc3VwcG9ydCwgdGhhdCB0aGUgRmlybXdhcmUgd2lsbA0K PiA+Pj4+Pj4+Pj4gb25seSBFRkkvVUVGSSBjYXBhYmxlIGxvYWRlcj8gT3IgaXMgdGhlcmUgYSBn aG9zdHkgb3ZlcnJpZGUgc29td2hlcmUNCj4gPj4+Pj4+Pj4+IHRvIGJlIGV4cGVjdGVkPykuIEFs c28gb24gQVNSb2NrIGRpc2FibGluZyBDU00gc2hvdWxkIGVuc3VyZSBub3QNCj4gPj4+Pj4+Pj4+ IGJvb3RpbmcgYSBkdWFsLWJvb3RzdHJhcC1jYXBhYmxlIHN5c3RlbS4gVGhpcyBzYWlkLCBvbiB0 aGUgcmVjZW50DQo+ID4+Pj4+Pj4+PiBGdWppdHN1LCBpdCBzZWVtcyB0byBib2lsIGRvd24gdG8g YSBGcmVlQlNEIFVFRkktZmlybXdhcmUgaW50ZXJhY3Rpb24NCj4gPj4+Pj4+Pj4+IHByb2JsZW0s IHdoaWxlIHRoZSBBU1JvY2sgaXMgc3RpbGwgdW5kZXIgc3VzcGljaW9uIHRvIGJlIGJyb2tlbiBi eQ0KPiA+Pj4+Pj4+Pj4gZGVzaWduLiAgICAgICAgIA0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+ Pj4+IEdQVCBwYXJ0aXRpb25zIGNhbiBuZXZlciBzdGFydCBmcm9tIGRpc2sgYWJzb2x1dGUgc2Vj dG9yIDE7IHRoaXMgaXMNCj4gPj4+Pj4+Pj4+PiBiZWNhdXNlIGF0IHNlY3RvciAwIHRoZXJlIGlz IE1CUiAoZm9yIGNvbXBhdGliaWxpdHkpLCBzZWN0b3IgMSBpcyBHUFQNCj4gPj4+Pj4+Pj4+PiB0 YWJsZSBhbmQgdGhlbiBzZWN0b3JzIDItMzMgaGF2ZSBHUFQgcGFydGl0aW9uIHRhYmxlIGVudHJp ZXMsIHNvIHRoZQ0KPiA+Pj4+Pj4+Pj4+IGZpcnN0IHBvc3NpYmxlIGRhdGEgc2VjdG9yIGlzIDM0 IChhYnNvbHV0ZSAzNCkuIFRoYXRzIGFzc3VtaW5nIDUxMkINCj4gPj4+Pj4+Pj4+PiBzZWN0b3Jz LiBGb3IgZGV0YWlscyBzZWUgVUVGSSAyLjcgQ2hhcHRlciA1LjMuMSBwYWdlIDEzMS4gICAgICAg ICAgDQo+ID4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+IFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9u LiBUaGF0IGltcGxpZXMgdGhlIGluc3RhbGxlciBkaWQgcmlnaHQsDQo+ID4+Pj4+Pj4+PiBncGFy dCBkaWQgYWxzbyByaWdodCBhbmQgdGhlcmVmb3JlIHRoZXJlIG11c3QgYmUgYW4gaXNzdWUgd2l0 aCB0aGUNCj4gPj4+Pj4+Pj4+IHN0dWZmIGxvY2F0ZWQgd2l0aGluIHRoZSBFRkkgcGFydGl0aW9u PyAgICAgICAgIA0KPiA+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4gT2ssIHNvLCBpdCBpcyBub3QgYWJv dXQgVUVGSSBib290Y29kZSBidXQgQklPUywgYW5kIGlmIHdlIHJlYWNoIEJJT1MNCj4gPj4+Pj4+ Pj4gbG9hZGVyIGF0IGFsbCBvciBub3QgLSB0aGF0IGlzLCBpZiB0aGUgQklPUyBib290c3RyYXAg aXMgYWN0dWFsbHkNCj4gPj4+Pj4+Pj4gY2FyaW5nIHRvIHJlYWQgdGhlIE1CUiBjb2RlIGFuZCBz dGFydCBpdCwgc2luY2Ugb25jZSB0aGUgTUJSIGNvZGUgaXMNCj4gPj4+Pj4+Pj4gc3RhcnRlZCwg aXQgaXMgYWxsIGFib3V0IG91ciBjb2RlLiAgICAgICAgDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4g SSdtIGdldHRpbmcgY29uZnVzZWQgYSBiaXQgaGVyZS4gRG8geW91IG1lYW4gYnkgIkJJT1MiIHRo ZSBDU00/IG9yIGRvDQo+ID4+Pj4+Pj4geW91IG1lYW4gdGhhdCBzcGVjaWZpYyBwb3J0aW9uIG9m IHRoZSBVRUZJIGZpcm13YXJlLCB3aGljaCBsb29rcyBmb3IgdGhlDQo+ID4+Pj4+Pj4gcHJvcGVy IFVFRkkgcGFydGl0aW9uPw0KPiA+Pj4+Pj4+ICAgDQo+ID4+Pj4+PiANCj4gPj4+Pj4+IEJJT1Mg YXMgZWl0aGVyIG5hdGl2ZSBvciBDU00uIE5vdGUgdGhhdCBmcm9tIGJvb3QgY29kZSBwb2ludCBv ZiB2aWV3IHRoZQ0KPiA+Pj4+Pj4gQ1NNIGJvb3QgKmlzKiBCSU9TIGJvb3QsIHdlIGhhdmUgbm8g YWNjZXNzIHRvIFVFRkkgZmVhdHVyZXMuDQo+ID4+Pj4+PiAgIA0KPiA+Pj4+Pj4+IA0KPiA+Pj4+ Pj4+IFRoZSBib3hlcyBpbiBxdWVzdGlvbiwgbW9zdCBub3RhYmx5IHRoZSBtb3JlIHJlY2VudCBG dWppdHN1IEVzcHJpbW8NCj4gPj4+Pj4+PiBROTU2LCByZWZ1c2UgYm9vdGluZyBVRUZJLCBldmVu IGlmIHByb3Blcmx5IHNldHVwIChpbiB0ZXJtcyBvZiB3aGF0DQo+ID4+Pj4+Pj4gRnJlZUJTRCBw cm92aWRlcyBvbiByZWNlbnQgQ1VSUkVOVCkgaXMgYXBwbGllZCBhbmQgQ1NNIGlzIHN3aXRjaGVk IG9mZg0KPiA+Pj4+Pj4+IGluIHRoZSBmaXJtd2FyZS4gQWdhaW46IEdQVCBwYXJ0aXRpb24gc2No ZW1lLg0KPiA+Pj4+Pj4+IA0KPiA+Pj4+Pj4+IFRoZSBzeXN0ZW0gYm9vdHMgcHJvcGVybHkgaWYg YSBzZWNvbmQgcGFydGl0aW9uIG9mIHR5cGUgImZyZWVic2QtYm9vdCINCj4gPj4+Pj4+PiBpcyBh cHBsaWVkIGFuZCBib290Y29kZSBpcyBwcm9wZXJseSBhcHBsaWVkIHZpYSAiZ3BhcnQgYm9vdGNv ZGUNCj4gPj4+Pj4+PiAtYiAvYm9vdC9wbWJyIC1wIC9ib290L2dwdGJvb3QgLWkgMiBhZGEwIiAo YWRhMCBpcyB0aGUgZGV2aWNlKS4gICAgICAgICANCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+IGJ0 dywgeW91IGNhbiB0cnkgdG8gdmFsaWRhdGUgdGhlIGluc3RhbGxlZCBib290IGJsb2NrcyBieSB1 c2luZyByZWNlbnQNCj4gPj4+Pj4+Pj4gZW5vdWdoIGxvYWRlciAodXNiIG9yIGlzbykgYW5kIHRo ZW4geW91IGNhbiB1c2UgZnJvbSBPSyBwcm9tcHQ6ICAgICAgICANCj4gPj4+Pj4+PiANCj4gPj4+ Pj4+PiBsc2RldiBwcm92aWRlcyBtZSB3aXRoIHRoZSBmb2xsd29pbmcgaW5mb3JtYXRpb25zIChD U00gZW5hYmxlZCk6DQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gT0sgbHNkZXYNCj4gPj4+Pj4+PiBk aXNrIGRldmljZXM6DQo+ID4+Pj4+Pj4gCWRpc2swOgkJQklPUyBEUklWRSBDIC4uLg0KPiA+Pj4+ Pj4+IA0KPiA+Pj4+Pj4+IAkJZGlzazBwMToJRUZJDQo+ID4+Pj4+Pj4gCQlkaXNrMHAyOglGcmVl QlNEIEJPT1QNCj4gPj4+Pj4+PiAJCWRpc2swcDM6CUZyZWVCU0QgU1dBUA0KPiA+Pj4+Pj4+IAkJ ZGlzazBwNDoJRnJlZUJTRCBaRlMNCj4gPj4+Pj4+PiB6ZnMgZGV2aWNlczoNCj4gPj4+Pj4+PiAJ emZzOnpyb290DQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gT0sgY2hhaW4gZGlzazANCj4gPj4+Pj4+ PiBvcGVuIGZhaWxlZCAgICAgKHNvIGZvciBkaXNrMHB7MS00fS4NCj4gPj4+Pj4+PiANCj4gPj4+ Pj4+PiBPSyBjaGFpbiB6cm9vdA0KPiA+Pj4+Pj4+IGZhaWxlZCB0byByZWFkIGRpc2sgKGp1c3Qg Zm9yIGNvbXBsZXRlbmVzcykgICAgICAgIA0KPiA+Pj4+Pj4gDQo+ID4+Pj4+PiANCj4gPj4+Pj4+ IGNoYWluIGNvbW1hbmQgZG9lcyB1c2Ugb25seSBkZXZpY2UgbmFtZSAoc3VjaCBhcyBkaXNrMDog b3IgZGlzazBwMjogKSwNCj4gPj4+Pj4+IGJ1dCBub3QgemZzIHBvb2wgYXMgZGV2aWNlLiAgSSBq dXN0IGZvdW5kIEkgaGF2ZW7igJl0IHBvcnRlZCB0aGUgY29kZSB0bw0KPiA+Pj4+Pj4gcmVhZCB0 aGUgZmlsZS4gICAgICANCj4gPj4+Pj4gDQo+ID4+Pj4+ID8/DQo+ID4+Pj4+ICAgDQo+ID4+Pj4+ PiANCj4gPj4+Pj4+IHRoZSBwb2ludCBmb3IgY2hhaW4gY29tbWFuZCB0ZXN0IGlzIHRvIHNlZSBp ZiB0aGUgbm9ybWFsIHJlYWQgYW5kIGV4ZWN1dGUNCj4gPj4+Pj4+IHdvdWxkIHdvcmssIHNvIGlu IHlvdXIgY2FzZSBwbGVhc2UgdHJ5Og0KPiA+Pj4+Pj4gDQo+ID4+Pj4+PiBjaGFpbiBkaXNrMDog ICAgICANCj4gPj4+Pj4gDQo+ID4+Pj4+IEFzIHN0YXRlZCBhYm92ZSwgSSBkaWQgc28sIGFuZCB0 aGUgcmVzdWx0IGlzIGFsc28gbWVudGlvbmVkIGFib3ZlLCBJDQo+ID4+Pj4+IGFsd2F5cyBnZXQg Im9wZW4gZmFpbGVkIi4NCj4gPj4+Pj4gVGhpcyBpcyB0aGUgc2FtZSBmb3IgDQo+ID4+Pj4+IA0K PiA+Pj4+PiBjaGFpbiBkaXNrMA0KPiA+Pj4+PiBjaGFpbiBkaXNrMHAxDQo+ID4+Pj4+IGNoYWlu IGRpc2swcDINCj4gPj4+Pj4gY2hhaW4gZGlzazBwMw0KPiA+Pj4+PiBjaGFpbiBkaXNrMHA0DQo+ ID4+Pj4+IA0KPiA+Pj4+PiBhcyBhbHJlYWR5IHNhaWQuIENTTSBpcyBlbmFibGVkIGluIHRoaXMg Y2FzZS4gICAgICANCj4gPj4+PiANCj4gPj4+PiBzaWdo4oCmIGNoYWluIGNvbW1hbmQgZG9lcyB0 YWtlIGRldmljZSBhcyBhcmd1bWVudCwgZGV2aWNlIG11c3QgYWx3YXlzIGVuZA0KPiA+Pj4+IHdp dGggY29sb27igKYuIGluIHRoaXMgY2FzZSwgdGhlIGRldmlsIGlzIGluIGRldGFpbHM6KSBhcyBJ IHdyb3RlIGFib3ZlLCB0aGUNCj4gPj4+PiBjb21tYW5kIHNob3VsZCBiZToNCj4gPj4+PiANCj4g Pj4+PiBjaGFpbiBkaXNrMDoNCj4gPj4+PiANCj4gPj4+PiBUaGUgZGlzazBwMTogZXRjIHdpbGwg b25seSB3b3JrIHdoZW4gcGFydGl0aW9uIGJvb3QgY29kZSB3YXMgaW5zdGFsbGVkDQo+ID4+Pj4g KHdoaWNoIHlvdSBtb3N0IGxpa2VseSBkbyBub3QgaGF2ZSAtIHRoZSBvbmx5IHBvc3NpYmxlIGNh bmRpZGF0ZSBjb3VsZCBiZQ0KPiA+Pj4+IEZyZWVCU0QgWkZTIHBhcnRpdGlvbikuICAgIA0KPiA+ Pj4gDQo+ID4+PiBUaGUgY29tbWFuZCAiY2hhaW4gZGlzazA6IiB3b3JrcyBhcyBleHBlY3RlZCAo Q1NNIGVuYWJsZWQsIEdQVCBwYXJ0aXRpb24NCj4gPj4+IHNjaGVtZSwgYnV0IHdpdGggUE1CUiBi b290YmxvY2sgaW5zdGFsbGVkIGFuZCBmcmVlYnNkLWJvb3QgcGFydGl0aW9uDQo+ID4+PiBjb25h dGluaW5nIGdwdHpmc2Jvb3QgaW5zdGFsbGVkLg0KPiA+Pj4gDQo+ID4+PiAgIA0KPiA+Pj4+ICAg DQo+ID4+Pj4+ICAgDQo+ID4+Pj4+PiANCj4gPj4+Pj4+IHRvIHJlYWQgcG1iciAoNTEyQikgYW5k IGV4ZWN1dGUgaXQuIFRoZSBleHBlY3RlZCBvdXRjb21lIHdvdWxkIGJlIHRoYXQNCj4gPj4+Pj4+ IHBtYnIgYm9vdCBjb2RlIHdvdWxkIGJyb3dzZSB0aGUgR1BULCByZWFkIHN0YWdlMSBmcm9tIGRp c2swcDI6IGFuZA0KPiA+Pj4+Pj4gZXhlY3V0ZSBpdDsgc3RhZ2UxIHdvdWxkIGRldGVjdCBGcmVl QlNEIFpGUyBmcm9tIGRpc2swcDQ6IGFuZCBsb2FkIGFuZA0KPiA+Pj4+Pj4gZXhlY3V0ZSAvYm9v dC9sb2FkZXIuIElmIHRoYXQgd2lsbCBoYXBwZW4sIGl0IG1lYW5zIHRoZSBib290IGNvZGUgaW4g b3VyDQo+ID4+Pj4+PiBzdGFnZXMgaXMganVzdCBmaW5lLCBidXQgdGhlIGJpb3MgKENTTSkgZG9l cyBub3QgbG9hZCBwbWJy4oCmLiAgaWYgdGhhdHMNCj4gPj4+Pj4+IHRydWUsIGl0IHdvdWxkIG1l YW4gdGhhdCB5b3UgZWl0aGVyIG5lZWQgdG8gdXNlIFVFRkkgYm9vdCBvciBuZWVkIHRvIGhhdmUN Cj4gPj4+Pj4+IHNvbWUgaGFjayB0byBmb29sIHRoZSBCSU9TIG9yIGp1c3Qgbm90IHVzZSBHUFQg b24gdGhhdCBtYWNoaW5lIHdpdGgNCj4gPj4+Pj4+IENTTS4gICAgICANCj4gPj4+Pj4gDQo+ID4+ Pj4+IFRvIG1ha2UgaXQgY2xlYXIgaGVyZTogVGhlIG9ubHkgd2F5IHRvIGJvb3QgdGhpcyBib3gg aXMgdXNpbmcgQ1NNIChhcyBpdA0KPiA+Pj4+PiBpcyB0aGUgc2FtZSB3aXRoIHRoZSBBU1JvY2sg Ym9hcmRzIG1lbnRpb25lZCBlYXJsaWVyKS4gQnV0IG15IGludGVudGlvbg0KPiA+Pj4+PiBpcyB0 byBkaXNhYmxlIENTTSBhbmQgdXNlIGEgR1BUL1VFRkkgZW52aXJvbm1lbnQgb25seSEgQW5kIEdQ VC9VRUZJDQo+ID4+Pj4+IGRvZXNuJ3Qgd29yayB3aXRoIEZyZWVCU0QsIG5laXRoZXIgd2l0aCAx Mi1DVVJSRU5ULCBub3IgMTEuMi1SRUxFTkcuDQo+ID4+Pj4+IA0KPiA+Pj4+PiBJdCB3b3VsZCBi ZSBuaWNlIGlmIHRoaXMgY291bGQgYmUgZml4ZWQuIEknbSBtb3JlIGludGVyZXN0ZWQgaW4gdGhl IGZpeCBvbg0KPiA+Pj4+PiB0aGUgcmVjZW50IEZ1aml0c3UgZGV2aWNlIHRoYW4gdGhlIG91dGRh dGVkIEFTUm9jayBjcmFwLCBidXQgaWYgdGhlIGZpeA0KPiA+Pj4+PiBmb3IgdGhlIEZ1aml0c3Ug RmlybXdhcmUgY291bGQgZml4IG9sZGVyIGlzc3VlcyBhcyBhIGJ5cHJvZHVjdCwgSSdkDQo+ID4+ Pj4+IGFwcHJlY2lhdGUgdGhhdC4NCj4gPj4+Pj4gDQo+ID4+Pj4+IEtpbmQgcmVnYXJkcywNCj4g Pj4+Pj4gICANCj4gPj4+PiANCj4gPj4+PiBvaywgc29tZWhvdyBJIGhhdmUgbG9zdCB0aGF0IHBh cnQgb2YgdGhlIGRpc2N1c3Npb24uIFdlbGwsIHlvdSB3cm90ZSB0aGF0DQo+ID4+Pj4gdGhlIFVF RkkgYm9vdCBmYWlscyB3aGVuIHRoZSBmaXJzdCBwYXJ0aXRpb24gc3RhcnRzIGZyb20gc2VjdG9y IDQwIC0gZG9lcw0KPiA+Pj4+IGl0IG1lYW4geW91IGhhdmUgYm9vdCB3aGVuIHRoZSBwYXJ0aXRp b24gd2lsbCBzdGFydCBmcm9tIHNvbWUgb3RoZXINCj4gPj4+PiBzZWN0b3I/IEkgdGhpbmssIHRo ZXJlIGlzIHNvbWV0aGluZyBlbHNlIGdvaW5nIG9uLiAgICANCj4gPj4+IA0KPiA+Pj4gV2VsbCwg SSBzaW1wbHkgdHJ5IHRvIGRlc2NyaWJlIHdoYXQgSSAic2VlIiB0byBtYWtlIHRoaW5ncyBkaXNh bWJpZ3VvdXMuIEknbQ0KPiA+Pj4gbm90IGZhbWlsaWFyIHdpdGggdGhlIGRlZXBlciBpbnNpZ2h0 cyBvZiBkaXNrIGxheW91dHMgb24gYSBiaW5hcnkgbGV2ZWwuIFNvLA0KPiA+Pj4geW91IGV4cGxh aW5lZCB0byBtZSB0aGUgcmVhc29uLCB3aHkgRVNQIChFR0kgcGFydGl0aW9uKSBzdGFydHMgYXQg YmxvY2sgNDAuDQo+ID4+PiBJIGNvbXBhcmVkIHRoYXQgdG8gdGhlIEZyZWVCU0QgVVNCIGZsYXNo IGltYWdlIEZyZWVCU0QgcHJvdmlkZXMsIGJ1dCB0aGlzIGlzDQo+ID4+PiBhbm90aGVyIHN0b3J5 IHNpbmNlIHRoZSBpbWFnZSB1c2VzIE1CUiBzY2hlbWUgYXMgSSBmaWd1cmVkIG91dC4NCj4gPj4+ IA0KPiA+Pj4gICANCj4gPj4+PiANCj4gPj4+PiBXaGF0IHlvdSBjYW4gZG8gaXMgdG8gc2VlIGlm IHRoYXQgZmlybXdhcmUgd2lsbCBvZmZlciB5b3UgRUZJIHNoZWxsIG9wdGlvbiwNCj4gPj4+PiBm cm9tIHRoZXJlIHlvdSBjYW4gdHJ5IHRvIHN0YXJ0IHRoZSBib290eDY0LmVmaSBtYW51YWxseSBh bmQgc2VlIHdoYXQgZXJyb3INCj4gPj4+PiB5b3Ugd2lsbCBnZXQuIEhvd2V2ZXIsIHRoZSBudW1i ZXIgMSBjYXVzZSBmb3IgZmFpbGluZyB0byBzdGFydCB0aGUNCj4gPj4+PiBib290bG9hZGVyIGlu IFVFRkkgaXMgc2VjdXJlIGJvb3QgLSB3ZSBkbyBub3Qgc3VwcG9ydCBpdCBhbmQgc2VjdXJlIGJv b3QNCj4gPj4+PiBtdXN0IGJlIHN3aXRjaGVkIG9mZi4gDQo+ID4+Pj4gDQo+ID4+Pj4gSG93ZXZl ciwgdGhleSBzZWVtIHRvIGNsYWltICJUaGUgU2VjdXJlIEJvb3Qgb3B0aW9uIGlzIGF2YWlsYWJs ZSBpbiB0aGUNCj4gPj4+PiBVRUZJL0JJT1Mgb2YgbW9zdCBpZiBub3QgYWxsIEFTUm9jayBib2Fy ZHMuIEl0IGlzIGRpc2FibGVkIGJ5IGRlZmF1bHQu4oCdIA0KPiA+Pj4+IA0KPiA+Pj4+IFN0aWxs IHN1Z2dlc3QgdG8gZG91YmxlIGNoZWNrIGlmIHRoYXRzIHJlYWxseSB0aGUgY2FzZS4gQWxzbywg aWYgdGhlDQo+ID4+Pj4gYm9vdHg2NC5lZmkgc3RhcnQgd2lsbCBmYWlsIGFuZCBubyBtZXNzYWdl cyBhcmUgYXBwZWFyaW5nIG9uIHNjcmVlbiwgdGhlbg0KPiA+Pj4+IGVpdGhlciB0aGVyZSBpcyBz b21ldGhpbmcgaW4gZmlybXdhcmUgbG9ncyBvciB5b3UgY291bGQgZ2V0IHRoZW0gZnJvbQ0KPiA+ Pj4+IHRyeWluZyB0byBzdGFydCBib290eDY0LmVmaSBmcm9tIFVFRkkgc2hlbGwuICAgIA0KPiA+ Pj4gDQo+ID4+PiBTaW5jZSBJJ20gd2l0aCB0aGlzIHByb2JsZW0gc2luY2UgMjAxNCBhbmQgdHJ5 IGZyb20gdGltZSB0byB0aW1lLCBiZSBhdXNyZWQNCj4gPj4+IHRoYXQgSSB0cmllZCBldmVyeSBw b3NzaWJsZSBwZXJtdXRhdGlvbm9mIGFsbCByZWFzb25hYmxlIG9wdGlvbnMsIGV2ZW4gdGhvc2UN Cj4gPj4+IG5vbnNlbnNlLCB0byBnZXQgcmlkIG9mIHRoYXQgcHJvYmxlbS4NCj4gPj4+IA0KPiA+ Pj4gSSBuZXZlciBoYWQgYW55IHByb2JsZW1zIHdpdGggYW55IG90aGVyIFVFRkkgY2FwYWJsZSBz ZXJ2ZXIvd29ya3N0YXRpb24NCj4gPj4+IGZpcm13YXJlIHNvIGZhciBib290aW5nIEZyZWVCU0Qg b2ZmIGluIFVFRkktbmF0aXZlIChHUFQgcGFydGl0aW9uIHNjaGVtZSwNCj4gPj4+IENTTSBkaXNh YmxlZCkgc28gZmFyIC0gdW50aWwgbm93LCB3aGVuIEkgcmFuIGludG8gdGhpcyBGdWppdHN1IEVT UFJJTU8gUTk1Ng0KPiA+Pj4gd2l0aCB0aGUgbW9zdCByZWNlbnQgZmlybXdhcmUgKGFzIG9mIGxh dCB3ZWVrLCB3ZWVrIDI5IG9mIDIwMTgpIGhhdmluZyB0aGUNCj4gPj4+IHZlcnkgc2FtZSBwcm9i bGVtcy4gDQo+ID4+PiANCj4gPj4+IA0KPiA+Pj4gDQo+ID4+PiBJIGZpZ3VyZWQgb3V0IHNvbWV0 aGluZyBzdHJhbmdlIG9uIHRoZSBGdWppdHN1IC0gYW5kIHRoYXQgaXMgdGhlIHNhbWUgd2l0aA0K PiA+Pj4gdGhlIEFTUm9jayBib2FyZHMuDQo+ID4+PiANCj4gPj4+IFdlL0kgcHJlcGFyZSBzb21l IFVTQiBmbGFzaCBkcml2ZXMgdG8gYm9vdCBhIE5hbm9CU0QgZm9yIGEgdmVyeSBzbWFsbA0KPiA+ Pj4gYXBwbGlhbmNlLCBidXQgbmV2ZXJ0aGVsZXNzLCB0aGUgVVNCIGZsYXNoIGRldmljZSBpcyBi b290ZWQgb24gRnVqaXRzdQ0KPiA+Pj4gc2VydmVycyB3aXRoIFVFRkktb25seSBjb25maWd1cmF0 aW9ucy4gSSBhc3N1bWUgYXQgdGhpcyBwb2ludCB0aGF0DQo+ID4+PiBkaXNhYmxpbmcgb24gdGhl IG1vc3QgcmVjZW50IEZ1aml0c3UgZmlybXdhcmVzIG9uIHJlYXNvbmFibGUgIm5ldyIgaGFyZHdh cmUNCj4gPj4+IChub3Qgb2xkZXIgdGhhbiB0aHJlZSB5ZWFycykgd2lsbCBkaXNhYmxlIGFueSgh KSBsZWdhY3kgQklPUyBjYXBhYmlsaXRpZXMuDQo+ID4+PiBUaGUgc2FtZSBpcyBhc3N1bWVkIGZv ciB0aGUgRnVqaXR1cyBFU1BSSU1PIFE5NTYuIEkgY2FuIG5vdCBzcGVhayBmb3IgdGhlDQo+ID4+ PiBBU1JvY2sgQTc3IFBybzQvbSBib2FyZHMgbWVudGlvbmVkIGFib3ZlL2VhcmxpZXIsIHRoZXkg YXJlIGZyb20gMjAxMi8yMDEzDQo+ID4+PiBhbmQgInF1aXRlIG9sZCIuDQo+ID4+PiANCj4gPj4+ IFRoZSBOYW5vQlNEIGltYWdlIG9mIG91cnMgZG9lc24ndCBoYXZlIGEgImZyZWVic2QtYm9vdCIg cGFydGl0aW9uLiBUaGUNCj4gPj4+IHBhcnRpdGlvbiBzY2hlbWUgb2YgdGhlIGZsYXNoIGRldmlj ZSBpcyBHUFQuIFRoZSBsYXlvdXQgbG9va3MgbGlrZSB0aGlzOg0KPiA+Pj4gDQo+ID4+PiBncGFy dCBzaG93IC1sIGRhNCAgICANCj4gPj4+ID0+ICAgICAgNDAgIDE1NDI1NDU2ICBkYTQgIEdQVCAg KDcuNEcpICAgIA0KPiA+Pj4gICAgICAgNDAgICAgICAyMDAwICAgIDEgIGVmaWJvb3QwICAoMS4w TSkNCj4gPj4+ICAgICAyMDQwICAgMTQ1MzU4NCAgICAzICBkaXNrMWEgICg3MTBNKQ0KPiA+Pj4g IDE0NTU2MjQgICAgICA0MDk2ICAgIDUgIGRpc2szICAoMi4wTSkNCj4gPj4+ICAxNDU5NzIwICAx Mzk2NTc3NiAgICAgICAtIGZyZWUgLSAgKDYuN0cpDQo+ID4+PiANCj4gPj4+IEkgY3JlYXRlZCB0 aGUgZmxhc2ggd2l0aCBtZCwgZ3BhcnQgYW5kIGRkIHN0cmFpZ2h0Zm9yd2FyZCwgZWZpYm9vdDAg aXMgdGhlDQo+ID4+PiBFU1AgcGFydGl0aW9uIGFuZCBpdHMgZm9ybWF0L2NvbnRlbnQgaXMgY3Jl YXRlZCB2aWEgZGQgaWY9L2Jvb3QvYm9vdDEuZWZpZmF0DQo+ID4+PiBvZj0vZGV2L2RhNHAxIC0g SSBwcmVzdW1lIHRoaXMgaXMgdmVyeSBzaW1wbGUuDQo+ID4+PiANCj4gPj4+IFRoaXMgVVNCIGZs YXNoIGRldmljZSBib290cyghKSBzdWNjZXNzZnVsbHkgKFVFRkkhKSBvbiBib3RoIHRoZSBBU1Jv Y2sNCj4gPj4+IGJvYXJkcyBhbmQgdGhlIEVzcHJpbW8gUTk1NiENCj4gPj4+IA0KPiA+Pj4gQnV0 IGFueSBTU0QgcHJlcGFyZWQgdGhlIHNhbWUgd2F5IGRvZXNuJ3QuIFdoeT8gDQo+ID4+PiANCj4g Pj4+IE9uIHRoZSBBU1JvY2ssIEkgcmVjYWxsIGhhdmluZyBmaWRkbGVkIGFyb3VuZCB3aXRoIEhE RCBhbHNvIGZvciBhIHdoaWxlDQo+ID4+PiBjb25hdGluaW5nIFdpbmRvd3MgNy9TUDEgYW5kIEZy ZWVCU0QuIFdpbmRvd3M3IGJvb3RlZCwgRnJlZUJTRCAtIEkgY2FuJ3QNCj4gPj4+IHJlbWVtYmVy LiANCj4gPj4+IA0KPiA+Pj4gSW4gdGhlIGxhY2sgb2YgcHJvcGVyIGhhcmR3YXJlIEknbSB1bmFi bGUgdG8gY2hlY2sgd2hldGhlciBVU0ItYXR0YWNoZWQgSEREDQo+ID4+PiBvciBTU0Qgd2lsbCBi b290IG9yIEhERCB3aWxsIGJvb3QgKGp1c3QgaW4gY2FzZSB0aGUgbG9jYWwgU0FUQSBoYXMgcHJv YmxlbXMNCj4gPj4+IGJvb3RpbmcgVUVGSSBhbmQgVVNCIG5vdCkuDQo+ID4+PiANCj4gPj4+IEtp bmQgcmVnYXJkcywNCj4gPj4+IA0KPiA+Pj4gT2xpdmVyIA0KPiA+Pj4gICANCj4gPj4gDQo+ID4+ IEFtLiB3ZWxsLiBJIHRoaW5rIHRoZSBzdWdnZXN0aW9uIHRvIHRlc3Qgb3V0IEZBVDMyIGlzIHN0 aWxsIGdvb2Qgb25lIHRvIHRlc3QuDQo+ID4+IFRoaXMgaXMgYmVjYXVzZSBpdCBpcyBrbm93biB0 aGF0IHNvbWUgdmVuZG9ycyBkbyBub3Qgc3VwcG9ydCBib290aW5nDQo+ID4+IEZBVDEyL0ZBVDE2 IGZyb20gSEREICh0aGUgbGlrZWx5IHJlYXNvbiBpcyB0aGF0IFVFRkkgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdA0KPiA+PiB0ZWxsIHdoaWNoIEZBVCBtdXN0IGJlIHN1cHBvcnRlZCwgYW5kIG9ubHkg aGludCBhYm91dCBGQVQxMi9GQVQxNiBpbiBjb250ZXh0DQo+ID4+IG9mIHJlbW92YWJsZSBkZXZp Y2VzKS4gIA0KPiA+IA0KPiA+IEkgcHJlcGFyZWQgeWVzdGVyZGF5IGEgR1RQL1pGUy1vbmx5IDEx LjItUkVMRU5HIG9uIHRoZSBFU1BSSU1PIFE5NTYuIEl0IHRvb2sgbWUNCj4gPiBhIHRpbWUgdG8g Y2lyY3VtdmVudCB0aGUgaW5zdGFsbGVyIGFuZCBJIGhhZCB0byBpbnN0YWxsIHRoZSBzeXN0ZW0g bWFudWFsbHkuIEluDQo+ID4gdGhhdCBzdHJhaW4sIEkgYWxzbyAidHJpZWQiIHRvIGVzdGFibGlz aCB0aGUgRVNQIHdpdGggRkFUMzIsIGFzIEFsbGVuIEp1ZGUNCj4gPiBzdWdnZXN0ZWQgZWFybGll ci4gSSBkaWRuJ3QgZmluZCBhbnkgYWQgaG9jIGhlbHAgaG93IHRvIGZpbmQgb3V0IHRoZSBmb3Jt YXQNCj4gPiAoRkFUMTIvMTYvMzIpIG9mIHRoZSBFU1AsIHNvIEkgYXNzdW1lIHdoZW4gdXNpbmcg MTItQ1VSUkVOVCdzIG9yIDExLjItUkVMRU5HJ3MNCj4gPiBpbnN0YWxsZXIgd2l0aCBBVVRPLVpG UyBhbmQgR1BUIChVRUZJKSAob25seSEpIHRoZSByZXN1bHRpbmcgRVNQIGlzIEZBVDEyIG9yDQo+ ID4gRkFUMTYgKDMwMG1iIGJ5IGRlZmF1bHQpLiBJIGFsc28gYXNzdW1lLCB0aGF0IHdoZW4gZGQn aW5nIHRoZSAvYm9vL2Jvb3QxLmVmaWZhdA0KPiA+IGltYWdlIHRvIGEgcGFydGl0aW9uLCB0aGUg Zm9ybWF0IGlzIEZBVCwgYnV0IG5vdCBGQVQzMi4gVGhlcmVmb3JlLCBJIHJlZm9tYXR0ZWQNCj4g PiB0aGUgbWFudWFsbHkgY3JlYXRlZCBFU1AgKHVzaW5nICJncGFydCBhZGQgLXQgZWZpIC4uLiIp IHVzaW5nICJuZXdmc19tc2RvcyAtRg0KPiA+IDMyIC1iIHh4eCAuLi4iLiBJIGhhZCB0byBmaWRk bGUgYXJvdW5kIGEgYml0IHdpdGggb3B0aW9uIC1iIHRvIGZpdCBpbiBhIHByb3Blcg0KPiA+IGZv cm1hdCB0byBtZWV0IGEgNTEybWIgRVNQIC0gSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBpcyB0 aGUgcHJvcGVyIG9wdGlvbiB0bw0KPiA+IGRlYWwgd2l0aC4gV2hlbiB1c2luZyB0aGUgZGVmYXVs dCBhbmQgb25seSAtRjMyLCB0aGUgc2l6ZSBvZiB0aGUgcGFydGl0aW9uIGhhcw0KPiA+IHRvIGJl IDRHIGF0IGxlYXN0IEkgYXNzdW1lLiBIYXZpbmcgZG9uZSB0aGF0LCBJIGNvcGllZCB0aGUgdGhl IGNvbnRlbnQgb2YNCj4gPiBib290MS5lZmlmYXQgKG1kY29uZmlnIC10IHZub2RlIC4uLiwgSSBn dWVzcyB3ZSBrbm93IHRoZSBkcmlsbCAuLi4pIHRvIHRoZQ0KPiA+IG5ld2x5IGZvcm1hdHRlZCBF U1AgdG8gL2Jvb3QvZWZpLyAuLi4NCj4gPiANCj4gPiBIYXZpbmcgc28gZmFyIG5vIGtub3dsZWRn ZSBvZiBob3cgdG8gYXN1cmUgdGhhdCB0aGUgY3JlYXRlZCBFU1AgaXMgRkFUMzIsIEkNCj4gPiBh c3N1bWUgaXQgaXMgRkFUMzIuDQo+ID4gDQo+ID4gVGhlIHJlc3VsdCBpcyBuZWdhdGl2ZSBvbiB0 aGUgRVNQUklNTyBROTU2LiBXaGVuIGRpc2FibGluZyB0aGUgQ1NNLCB0aGUgYm94IGlzDQo+ID4g bm90IHdpbGxpbmcgdG8gYm9vdCBmcm9tIFNTRCB3aXRoIHRoZSBFU1AgcHJlcGFyZWQgYXMgZGVj cmliZWQuIFNvLCBhIGNoYW5jZQ0KPiA+IHRoYXQgdGhpcyBtaWdodCBzdGlsbCBiZSBkdWUgdG8g YSBtaXNjb25maWd1cmF0aW9uIGxpZXMgbm93IHdpdGhpbiB0aGUgLWINCj4gPiBvcHRpb24gb2Yg bmV3ZnNfbXNkb3MgLSBpZiB0aGUgLWIgb3B0aW9uIGlzIGFzc3VtZWQgdGhlIHByb3BlciBvcHRp b24/DQo+ID4gDQo+ID4gQXQgdGhlIG1vbWVudCwgdGhlIEVTUCBvZiB0aGUgRXNwcmltbyBpcyBz dWJqZWN0IHRvIGNoYW5nZXMsIGlmIHlvdSB3aXNoLCBidXQNCj4gPiBub3QgaW4gc2l6ZSwgc2lu Y2UgaXQgaXMgbGltaXRlZCB0byA1MTJtYi4NCj4gPiANCj4gPiBUaGFua3MgYW5kIGtpbmQgcmVn YXJkcywNCj4gPiANCj4gPiBPbGl2ZXIgIA0KPiANCj4gWWVhLCBpIHdhcyBob3BpbmcgZnN0eXAg Y29tbWFuZCB3b3VsZCByZXBvcnQgdGhlIEZBVCB0eXBlLCBidXQgaXQgZG9lcyBub3QgKHJlcXVl c3QgZm9yDQo+IGZlYXR1cmU/OikNCj4gDQo+IEhvd2V2ZXIsIHRoZSBtb3JlIGFubm95aW5nIGlk ZWEgd291bGQgYmUgdG8gaW5zdGFsbCBzb21lIE9TIHdoaWNoIHdpbGwgYm9vdCB3aXRoIFVFRkkN Cj4gb24gdGhpcyBtYWNoaW5lLCB0aGVuIGNvcHkgYm9vdDEuZWZpIGZyb20gZnJlZWJzZCB0byBp dCAodGhlIGRlZmF1bHQgcHJvZ3JhbSB0aGUgVUVGSQ0KPiB3aWxsIGxvYWQgaXMgRVNQOkVGSS9i b290L2Jvb3R4NjQuZWZpICBpbiBjYXNlIG9mIFVFRkk2NCBhbmQgRVNQOkVGSS9ib290L2Jvb3Rp YTMyLmVmaQ0KPiBmb3IgRUZJMzIuIEhvd2V2ZXIsIHdlIGRvIG5vdCBzdXBwb3J0IEVGSTMyLg0K DQpJIGNoZWNrZWQgb24gb25lIG9mIHRoZSBBU1JvY2sgWjc3LVBybzQgc3lzdGVtcy4gT24gb25l LCBJIGV4Y2hhbmdkIHJlY2VudGx5IHRoZSBvbGQgU1NEDQp3aXRoIGEgbmV3IG9uZSBhbmQgaW5z dGFsbGVkIHRoZSBuZXcgc3RhbmRhcmQgRVNQIG9mIDMwMG1iLiBVc2luZyANCg0KbWV3ZnNfbXNk b3MgLUYgMzIgLWIgNTEyIC9kZXYvZ3B0L2VmaWJvb3QwDQoNCndvcmtkZWQgc28gZmFyLCBmaWxl IC1zIC9kZXYvZ3B0L2VmaWJvb3QwIHJlc3VsdHMgaW46DQoNCiAvZGV2L2dwdC9lZmlib290MDog RE9TL01CUiBib290IHNlY3RvciwgY29kZSBvZmZzZXQgMHg1OCsyLCBPRU0tSUQgIkJTRDQuNCAg IiwNCnNlY3RvcnMvdHJhY2sgNjMsIGhlYWRzIDE2LCBzZWN0b3JzIDYxNDQwMCAodm9sdW1lcyA+ IDMyIE1CKSwgRkFUICgzMiBiaXQpLCBzZWN0b3JzL0ZBVA0KNDcyNiwgc2VyaWFsIG51bWJlciAw eGNlZmQxMTA2LCB1bmxhYmVsZWQNCg0KSXQgZG9lc24ndCB3b3JrIHdpdGggZWl0aGVyLg0KDQo+ IA0KPiBub3RlIHRoYXQgYm9vdDEuZWZpIGFsb25lIHdpbGwgbm90IGRvIG11Y2ggYnV0IHByaW50 aW5nIG9uIHNjcmVlbiBob3cgaXQgd2lsbCBzZWFyY2gNCj4gZm9yIGZyZWVic2QsIGJ1dCBmb3Ig dGhlIHB1cnBvc2Ugb2YgdGhlIHRlc3QgaXQgd291bGQgc3VmZmljZSAtIHRoYXQgd291bGQgZ2l2 ZSB1cw0KPiBjb25maXJtZWQgd29ya2luZyBFU1AgZmlsZSBzeXN0ZW0gKHNpbmNlIHRoZSBvdGhl ciBvcyB3b3VsZCBiZSBhYmxlIHRvIGJvb3QpIGFuZCB0aGVuDQo+IHdlIGNhbiBjb25maXJtIGlm IGJvb3QxLmVmaSBpdHNlbGYgaXMgT0suDQoNCkkgdW5kZXJzdGFuZC4gVGhhdCB3YXMgYWxzbyBt eSBpbnRlbnRpb24gd2hlbiBjcmVhdGVkIG1hbnVhbGx5IHRoZSBGQVQzMiBFU1AgYW5kDQppbnN0 YWxsZWQgbWFudWFsbHkgdGhlIFpGUy1iYXNlZCAxMS4yIEZCU0QgLSBJIGhvcGVkIGZvciBhbnkg a2luZCBvZiBhIHJlc3BvbnNlIGZyb20gdGhlDQpmaXJtd2FyZSBoYXZpbmcgZm91bmQgdGhlIEVG SSBwYXJ0aXRpb24uIEJ1dCBub3RoaW5nLiBFdmVuIHRoZSByZWNlbnQgRXNwcmltbyBpcyB2ZXJ5 DQpyZXNpbGllbnQgdG8gc3VjaCBhdHRlbXB0cy4NCg0KV2hhdCBPUyBkbyB5b3Ugc3VnZ2VzdD8g VGhlIG9ubHkgYXZhaWxhYmxlIG9wdGlvbnMgYXJlIFJlZHRIYXQgNy41IGFuZC9vciBXaW5kb3dz IDcvU1AxLg0KSSBhc3N1bWUgZGlzYWJsaW5nIENTTSBsZWFkcyBtZSB0b3dhcmRzIGEgVUVGSS1v bmx5IGluc3RhbGxhdGlvbj8gSSBoYXZlIG5vIGV4cGVyaWVuY2UgaW4NCmhvdyB0byBkZWFsIHdp dGggTGludXgnIGJvb3QgbWVjaGFuaXNtIC0gYnV0IEknbGwgZ2l2ZSBpdCBhIHRyeSBpZiBpdCBo ZWxwcy4NCg0KQnkgdGhlIHdheTogbmV3ZnNfbXNkb3Mgb2ZmZXJzIDMgb3B0aW9ucyB3aXRoIHNw ZWNpYWwgbWVhbmluZ3MgaW5mbHVlbmNpbmcgdGhlIHJlc3VsdA0Kd2hldGhlciB0byBiZSBhYmxl IHRvIGZvcm1hdCBhIHBhcnRpdGlvbiBGQVQzMiBvciBub3Q6IC1iIChibG9jay1zaXplKSwgLVMg KHNlY3Rvci1zaXplKQ0KYW5kIC1jIChjbHVzdGVyLXNpemUpLiBEbyB0aGV5IGhhdmUgYW55IHNl cmlvdXMgaW5mbHVlbmNlIG9uIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlDQpmaXJtd2FyZSB0byBk ZXRlY3QgdGhlIEVTUCBvciBub3Q/DQoNCktpbmQgcmVnYXJkcywNCk9saXZlcg0KDQo+IA0KPiBy Z2RzLA0KPiB0b29tYXMNCj4gDQoNCg0KLSAtLSANCk8uIEhhcnRtYW5uDQoNCkljaCB3aWRlcnNw cmVjaGUgZGVyIE51dHp1bmcgb2RlciDDnGJlcm1pdHRsdW5nIG1laW5lciBEYXRlbiBmw7xyDQpX ZXJiZXp3ZWNrZSBvZGVyIGbDvHIgZGllIE1hcmt0LSBvZGVyIE1laW51bmdzZm9yc2NodW5nICjC pyAyOCBBYnMuIDQgQkRTRykuDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQppTFVF QVJNS0FCMFdJUVFaVlpNekF0d0MyVC84NlRyUzUyOGZ5RmhZbEFVQ1cxaTVEUUFLQ1JEUzUyOGZ5 RmhZDQpsQXAyQWY5OTdSUlpqWkx1TkxHOGREMzlPcVYyNzVLMDIzR0VwcDU2TlBsZDltT0krRGRG L2RldW03b2g4d2F1DQpqTU9hRjQyVjJ5K2RzTEtJZFRSOWhkUXBNck9xQWdDSUxBaEI5cWZiOEdq SzZRN3g0TmpsYWtjVm5XWmtxR2YvDQpqOWNVUTVmQ0dDaDJ5QTJ0bmwySitKVlVLRnFNTHNJS2h4 dnc2SG1DMWJlSlJpQUJWa1dWDQo9dnhFOA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-current@freebsd.org Wed Jul 25 21:10:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB0241054683 for ; Wed, 25 Jul 2018 21:10:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-9.consmr.mail.gq1.yahoo.com (sonic307-9.consmr.mail.gq1.yahoo.com [98.137.64.33]) (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 367F98E8FD for ; Wed, 25 Jul 2018 21:10:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: xREWIf8VM1lt31kfGzgwYYLFDSbNIcPUSC14uD0F_KLdCYgSz.o34a7V0R52SdD 94BtDAihPRKGVB3.MTD2m2nfr0rRePoEkzlyrtE.maKZDOUS5GXlyjKBYysGYx9AQSZRAMHQ0AK1 t.idog589KMVTIzxvJgbVDk3L.mV.QmhC4LPWotMteXycjLA21g5yMVuyWsLzBrVVy5TreiTinBB dHI_oxqPBC55v_IDm5hkcWZ4__.3Q2HPRJMoYYv0OrwFSLszddfpp2uDUGMiSBQxorqx3b7PAgik lR8FW3qZkfwAGYsX_rnbP8_dXFAXvLb6ZTnMh4TbLCq0wkw4cxoXJ3_owDtzp3nIlP1AgiOkRohP fnVxWQNvFhQ4s0hEsg1NdqnQac_wLptRBt0HBIi9SkLeT9dSsNth.SH8_bumUaUw8diZUcS8XCdB 81R8VCQKVNR45ujJbhtLq2mxjAG.s957zWSZSzSFCtLwOTpbptwAY1Cf8_bo40EHMSwSwQjedpOP ZjLy.mGofsiWjCB6v6ZPv4v4LuP_KdthixQXCIqHAqZgeM4rFaj8o6g0q1sE90gCD_IFLofC6FeE ab0cfF8u3F0e9MndA3A4dwZCp3A0yex0CcYjJ2HwUeGUWZ7YBDksAvoNoc2dRM8UzREmXFfeaeZm 0iZIVjZnR1qzg2.dsn_tB1fWSil6itzBQVV3I5.F0rKKmf5rCnEMfs8gxOWEpjsG7HtvcYh9ZeJ_ PjVr5ncRYdn6pmRRiuORPC.Uld6frUckbauouCBznZfnR4Swcc16wD.WTD_3yu_tVn_rLmNp5wSI NnAWisLGG_KsadEhUqa797pTmIyzZl8Bc0JQiOCvOyPvWTMunR_rZatHXztt7BhQlddTpsnNYFoY D5i5xGFJLmPYmAd7941mz76ae7ZTRJ9qLlTkdPE.F_l_PhTsB3UHTqHheX1NQtRsGMZQai4sXXB8 pewH8JSLN8lG6rqTck38dugPSpkU_vc6Ezg8nBVbXe1UJpDm7dU0_b0W_oouePhlFJf96vfYuYFa hCNi1rZGcebk7nNKOGg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 25 Jul 2018 21:10:06 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b3e6d7ef3467e9040aa33384097272b6; Wed, 25 Jul 2018 21:10:02 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> Date: Wed, 25 Jul 2018 14:10:00 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:10:14 -0000 On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: > On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >=20 >> On 7/24/18 11:39 PM, Mark Millard wrote: >>> On 2018-Jul-24, at 10:32 PM, Mark Millard = wrote: >>>=20 >>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>> (head -r336573 after the prior 6596's -r336565 ): >>>>=20 >>>> --- all_subdir_lib/ofed --- >>>> In file included from = /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_init': >>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer >>>> atomic_store(&lock->cnt, 0); >>>> ^ >>>> In file included from = /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': >>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' >>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>> ^~ >>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': >>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' >>>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>>> ^~ >>>> . . . >>>> --- all_subdir_lib/ofed --- >>>> *** [acm.o] Error code 1 >>>>=20 >>>>=20 >>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText = ( for >>>> -r336700 ) still shows this type of error. >>>=20 >>>=20 >>> [I should have a subject with "head -r336568 through -r336570 . . = .".] >>>=20 >>> =46rom what I can tell looking around having something like: >>>=20 >>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>=20 >>> involve a __atomic_fetch_add indicates that: >>>=20 >>> = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>=20 >>> was in use instead of FreeBSD's stdatomic.h file. >>>=20 >>> If this is right, then the issue may be tied to head -r335782 >>> implicitly changing the order of the include file directory >>> searching for builds via the devel/*-gcc . >>>=20 >>> (I reverted -r335782 in my environment some time ago and have >>> not run into this problem in my context so far.) >>=20 >> C11 atomics should work fine with compiler-provided headers since = they >> are a part of the language (and the system stdatomic.h simply = attempts >> to mimic the compiler-provided header in case it is missing). >>=20 >> Simple standalone tests of _Atomic(int) with GCC don't trigger those >> failures when using its stdatomic.h, so there is probably something = else >> going on with kernel includes being used while building the library, >> etc. The last time we had this issue with stdarg.h it was because a >> header shared between the kernel and userland always used = '' >> which is correct for the kernel but not for userland. >=20 > I did misread the headers. FreeBSD has the likes of: >=20 > #if defined(__CLANG_ATOMICS) > . . . > #define atomic_fetch_add_explicit(object, operand, order) = \ > __c11_atomic_fetch_add(object, operand, order) > . . . > #elif defined(__GNUC_ATOMICS) > . . . > #define atomic_fetch_add_explicit(object, operand, order) = \ > __atomic_fetch_add(&(object)->__val, operand, order) > . . . > #endif > . . . > #define atomic_fetch_add(object, operand) = \ > atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) >=20 > so __atomic_fetch_add would occur. >=20 > But so far I do not see the problem with -r335782 reverted. I last = built > -r336693 last night via devel/amd64-gcc (via xtoolchain). >=20 > =46rom what I can tell FreeBSD defines: >=20 > #if !defined(__CLANG_ATOMICS) > #define _Atomic(T) struct { volatile T = __val; } > #endif >=20 > and that struct is being used in &(object)->__val is what the > error reports are about. So that would be, for example, >=20 > &(&lock->cnt)->__val >=20 > This would appear to suggest that __val itself had a type meeting: >=20 > operand type struct >=20 > for T in _Atomic(T) . >=20 > (This is independent of just what the issue traces back to: just > the net result on ci.freebsd.org . No claim that you are right > or wrong here. I'll not be looking any more until this afternoon > or night.) Going in a somewhat different direction . . . Looking around I found https://bugs.llvm.org/show_bug.cgi?id=3D26462 which is titled: 26462 =E2=80=93 GCC/clang C11 _Atomic incompatibility It appears that the normal source of platform ABI definitions are not explicit/detailed in the area and allow for incompatibilities in this area. clang and gcc made differing choices absent being constrained to match. An example (a powerpc64 context was indicated): struct A16 { char val[16]; };=20 _Atomic struct A16 a16;=20 // GCC: _Static_assert(_Alignof(a16) =3D=3D 16, "");=20 // Clang: _Static_assert(_Alignof(a16) =3D=3D 1, "");=20 Non-power-of-2 is a general problem (not a powerpc64 context from what I can tell): struct A3 { char val[3]; }; _Atomic struct A3 a3; // GCC: _Static_assert(sizeof(a3) =3D=3D 3, ""); _Static_assert(_Alignof(a3) =3D=3D 1, ""); // Clang: _Static_assert(sizeof(a3) =3D=3D 4, ""); _Static_assert(_Alignof(a3) =3D=3D 4, ""); Comment 6 (by John McCall) is relevant: QUOTE Anyway, while I prefer the Clang rule, the GCC rule is defensible, as = are any number of other rules. The important point, however, is that = having this discussion is not the right approach to solving this = problem. The layout of _Atomic(T) is ABI. ABI rules are not generally = determined by compiler implementors making things up as they go along, = or at least they shouldn't be. The Darwin ABI for _Atomic is the rule = implemented in Clang, which we actually did think about carefully when = we adopted it. Other platforms need to make their own call, and it = probably shouldn't just be "whatever's implemented in GCC", especially = on other platforms where GCC is not the system compiler. END QUOTE (I do nto claim to have proivided all the material that should be read in https://bugs.llvm.org/show_bug.cgi?id=3D26462 .) It may be that FreeBSD needs to be the source of the ABI definitions involved if clang and gcc freeBSD builds are to be interoperable in this area. But this could mean avoiding builtins? If any of this is inlined and so not behind a more stable interface, it looks like clang and gcc can not be mixed for the same instances of various _Atomic possibilities. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Jul 26 01:52:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C35331059B4A for ; Thu, 26 Jul 2018 01:52:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-22.consmr.mail.ne1.yahoo.com (sonic303-22.consmr.mail.ne1.yahoo.com [66.163.188.148]) (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 5A1C076118 for ; Thu, 26 Jul 2018 01:52:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 2ONrIdgVM1kzNP1UhgikjtoqRFlnWUBRn92JMboXGZu7fNVUONBOMT.i3hXhY8S uas1R9_3Z7CRQP.1.qJxzxwYYtTw_.bm0ob9qs7ExSJJ9_CTPvIBSF92mMQZ4UHUbTXCkc9Rp6s. 7009ATxrOcr96wdRqZcYskobWv4.8ezWE7dtDGVJ3.PsAybE63kJqiZyqJAhf7R8Vzyq5to3VZpN HJ3kl0aYFwHC9oqjNZn46QE6ZdcaoNDZogqvhZ610bbf0x6wSSuDq1KA1H9bnW5uVJgD6G4kCXqL tm531I3u8UoXeCKdVtoK.CkYKOoql46gY6eO887J6VAgFXwldbr07MTx67cCOvFFlCZ3U7q.wcH. 5krtCcNSdlTuYtvy.oRaZ._am2L1lG.DrEVYM3ZRvJ._rkvdqVlueXXmi2Uk.t6WguynElAhFpVv TKoCDRnNABOhWINr01oVbcWW8YHgvjnlHwrvxxdY64gSshJp_awAKbNKT7rbldc24wICWFVWRZyZ 3yi7VzxDu6YXeW.wIEY5UKc4TfXc6YYWY39f8gQW92nbemI.pZ2cj0h9Kq7O0sEbbqKtwIXxrZuQ xPS.9dc29aNDNeHL8qdXMZE0E1V4CL1YWNe0.QWQmaaMywU.tdFHjPd.bta.MvNJWXRw8yYQ33XG 4zDAfdZhvIIwivF5YxuQY15j1cCEDmG0sWIAb5dXBSpkkzezigS0hVbRk8QyrHcKMMxcBbvaLKh8 lObyno_pe93Jab9ayFkaTd_Epv2ajCRK7B0Oipq.iLmvXfeaevHtw3ktfuStoETyUAGkuOt.PCAr GME2jag_xphU6RgQc5Sj5B1a1M3JYtXSarIM.5m1HG8SujaIcpWHvdv6F7yL0f.J0wxh1deSYBLV Z4Z9flLr_qP3cg50ybV4AsgeNnShpk5NfxEnsFg0FfBl3bQ.ufH4g4P5QGZqOOWEbprzJztr9_po svHdgQuEQL3hAqwX4kNIBYnVM5Y6mHAhxvyZ4RGs1M7.zcU8L9H9qyvGfjGT_R4iz3p0X5pQJ81L e9.fZLJKWE0qYcf1l0cbH8g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 26 Jul 2018 01:52:12 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp402.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2ee2ee847328818624f94d2bfa3bfe23; Thu, 26 Jul 2018 01:52:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> Date: Wed, 25 Jul 2018 18:52:05 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 01:52:20 -0000 On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: > On 2018-Jul-25, at 10:09 AM, Mark Millard = wrote: >=20 >> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >>=20 >>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>> On 2018-Jul-24, at 10:32 PM, Mark Millard = wrote: >>>>=20 >>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>>=20 >>>>> --- all_subdir_lib/ofed --- >>>>> In file included from = /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_init': >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer >>>>> atomic_store(&lock->cnt, 0); >>>>> ^ >>>>> In file included from = /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' >>>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>> ^~ >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' >>>>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>>>> ^~ >>>>> . . . >>>>> --- all_subdir_lib/ofed --- >>>>> *** [acm.o] Error code 1 >>>>>=20 >>>>>=20 >>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText = ( for >>>>> -r336700 ) still shows this type of error. >>>>=20 >>>>=20 >>>> [I should have a subject with "head -r336568 through -r336570 . . = .".] >>>>=20 >>>> =46rom what I can tell looking around having something like: >>>>=20 >>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>=20 >>>> involve a __atomic_fetch_add indicates that: >>>>=20 >>>> = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>>=20 >>>> was in use instead of FreeBSD's stdatomic.h file. >>>>=20 >>>> If this is right, then the issue may be tied to head -r335782 >>>> implicitly changing the order of the include file directory >>>> searching for builds via the devel/*-gcc . >>>>=20 >>>> (I reverted -r335782 in my environment some time ago and have >>>> not run into this problem in my context so far.) >>>=20 >>> C11 atomics should work fine with compiler-provided headers since = they >>> are a part of the language (and the system stdatomic.h simply = attempts >>> to mimic the compiler-provided header in case it is missing). >>>=20 >>> Simple standalone tests of _Atomic(int) with GCC don't trigger those >>> failures when using its stdatomic.h, so there is probably something = else >>> going on with kernel includes being used while building the library, >>> etc. The last time we had this issue with stdarg.h it was because a >>> header shared between the kernel and userland always used = '' >>> which is correct for the kernel but not for userland. >>=20 >> I did misread the headers. FreeBSD has the likes of: >>=20 >> #if defined(__CLANG_ATOMICS) >> . . . >> #define atomic_fetch_add_explicit(object, operand, order) = \ >> __c11_atomic_fetch_add(object, operand, order) >> . . . >> #elif defined(__GNUC_ATOMICS) >> . . . >> #define atomic_fetch_add_explicit(object, operand, order) = \ >> __atomic_fetch_add(&(object)->__val, operand, order) >> . . . >> #endif >> . . . >> #define atomic_fetch_add(object, operand) = \ >> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) >>=20 >> so __atomic_fetch_add would occur. >>=20 >> But so far I do not see the problem with -r335782 reverted. I last = built >> -r336693 last night via devel/amd64-gcc (via xtoolchain). >>=20 >> =46rom what I can tell FreeBSD defines: >>=20 >> #if !defined(__CLANG_ATOMICS) >> #define _Atomic(T) struct { volatile T = __val; } >> #endif >>=20 >> and that struct is being used in &(object)->__val is what the >> error reports are about. So that would be, for example, >>=20 >> &(&lock->cnt)->__val >>=20 >> This would appear to suggest that __val itself had a type meeting: >>=20 >> operand type struct >>=20 >> for T in _Atomic(T) . >>=20 >> (This is independent of just what the issue traces back to: just >> the net result on ci.freebsd.org . No claim that you are right >> or wrong here. I'll not be looking any more until this afternoon >> or night.) >=20 > Going in a somewhat different direction . . . >=20 > Looking around I found https://bugs.llvm.org/show_bug.cgi?id=3D26462 > which is titled: >=20 > 26462 =E2=80=93 GCC/clang C11 _Atomic incompatibility >=20 > It appears that the normal source of platform ABI definitions are > not explicit/detailed in the area and allow for incompatibilities > in this area. clang and gcc made differing choices absent being > constrained to match. >=20 > An example (a powerpc64 context was indicated): >=20 > struct A16 { char val[16]; };=20 > _Atomic struct A16 a16;=20 > // GCC: > _Static_assert(_Alignof(a16) =3D=3D 16, "");=20 > // Clang: > _Static_assert(_Alignof(a16) =3D=3D 1, "");=20 >=20 >=20 > Non-power-of-2 is a general problem > (not a powerpc64 context from what I can > tell): >=20 > struct A3 { char val[3]; }; > _Atomic struct A3 a3; > // GCC: > _Static_assert(sizeof(a3) =3D=3D 3, ""); > _Static_assert(_Alignof(a3) =3D=3D 1, ""); > // Clang: > _Static_assert(sizeof(a3) =3D=3D 4, ""); > _Static_assert(_Alignof(a3) =3D=3D 4, ""); >=20 >=20 >=20 > Comment 6 (by John McCall) is relevant: >=20 > QUOTE > Anyway, while I prefer the Clang rule, the GCC rule is defensible, as = are any number of other rules. The important point, however, is that = having this discussion is not the right approach to solving this = problem. The layout of _Atomic(T) is ABI. ABI rules are not generally = determined by compiler implementors making things up as they go along, = or at least they shouldn't be. The Darwin ABI for _Atomic is the rule = implemented in Clang, which we actually did think about carefully when = we adopted it. Other platforms need to make their own call, and it = probably shouldn't just be "whatever's implemented in GCC", especially = on other platforms where GCC is not the system compiler. > END QUOTE >=20 >=20 > (I do nto claim to have proivided all the material that should > be read in https://bugs.llvm.org/show_bug.cgi?id=3D26462 .) >=20 > It may be that FreeBSD needs to be the source of the ABI definitions > involved if clang and gcc freeBSD builds are to be interoperable in > this area. But this could mean avoiding builtins? >=20 > If any of this is inlined and so not behind a more stable interface, > it looks like clang and gcc can not be mixed for the same instances > of various _Atomic possibilities. >=20 >=20 Going back to the code being compiled and=20 confirming your note: ( /usr/src/contrib/ofed/librdmacm/cma.h ) typedef struct { sem_t sem; _Atomic(int) cnt; } fastlock_t; . . . static inline void fastlock_acquire(fastlock_t *lock) { if (atomic_fetch_add(&lock->cnt, 1) > 0) sem_wait(&lock->sem); } So lock->cnt is an _Atomic(int) , i.e., struct { volatile int __val; } so overall: typedef struct { sem_t sem; struct { volatile int __val; } cnt; } fastlock_t; for which: atomic_fetch_add(&lock->cnt, 1) has for A filled-in in the C11 language official: atomic_fetch_add (volatile A* obj, M arg) (generic function) being: atomic_fetch_add (volatile struct { volatile int __val; }* obj, M arg) and a direct type-check of that notation for obj would find: operand type 'struct *' and that would propagate to GCC's translation to __atomic_fetch_add via gcc's stdatomic.h : #define atomic_fetch_add(PTR, VAL) __atomic_fetch_add ((PTR), (VAL), = \ __ATOMIC_SEQ_CST) So, yes, it looks like the: #if !defined(__CLANG_ATOMICS) #define _Atomic(T) struct { volatile T __val; } #endif overriding the GCC compiler's _Atomic(T) notation is inappropriate if one is trying for the GCC atomic ABI (via GCC's builtins). (Such is not the same as the clang atomic ABI for at least some T's on some architectures.) (But if always being compatible with clang's atomic ABI was a criteria, I'm not sure what things should be like when compiling via gcc.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Jul 26 04:53:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FDBB103D293 for ; Thu, 26 Jul 2018 04:53:54 +0000 (UTC) (envelope-from tyler@monkeypox.org) Received: from starfish.geekisp.com (starfish.geekisp.com [216.168.135.166]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.geekisp.com", Issuer "mail.geekisp.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1867D7D292 for ; Thu, 26 Jul 2018 04:53:53 +0000 (UTC) (envelope-from tyler@monkeypox.org) Received: (qmail 5894 invoked by uid 1003); 26 Jul 2018 04:47:11 -0000 Received: from unknown (HELO grape.lasagna.io) (tyler@monkeypox.org@50.0.244.65) by mail.geekisp.com with (AES256-SHA encrypted) SMTP; 26 Jul 2018 04:47:10 -0000 Date: Wed, 25 Jul 2018 21:47:06 -0700 From: "R. Tyler Croy" To: Michael Butler Cc: tech-lists , freebsd-current@freebsd.org Subject: Re: em0 link fail Message-ID: <20180726044705.GB5081@grape.lasagna.io> References: <739ef71a-f29f-68ea-955a-fb53c57960a6@protected-networks.net> <8e2bf594-6d7e-477e-836b-4cc4483cb525@protected-networks.net> <64e462dd-16fc-b57f-7bf2-02068d0e24c8@zyxst.net> <7a4607ce-e212-5cba-bc04-1d0abf1a7824@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 04:53:54 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (replies inline) On Sun, 15 Jul 2018, Michael Butler wrote: > On 07/05/18 09:54, I wrote: > > On 07/05/18 09:27, tech-lists wrote: > >> On 03/07/2018 19:47, Michael Butler wrote: > >>> That would've been .. > >>> > >>> Jun=A0 1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri= Jun > >>> 1 08:25:58 EDT 2018 > >>> > >>> I'm going to build one with SVN r334862 reverted to see if that works, > >> > >> Hi, > >> > >> Is it working now? Am asking because a system I'd like to take from > >> 11-stable to 12 uses the em driver. > >=20 > > No :-( I haven't had the chance yet to revisit it, >=20 > As it turns out, SVN r336313 (committed today) solves the issue I was > having with the hardware stalling, Just to add a bit more metadata to this thread, I've seen this exact same b= ehavior for a few months now! I've recently rebuilt to r336294 which still = exhibited the problem, with periodic logs such as these: Jul 26 04:09:53 strawberry kernel: em1: Watchdog timeout Queue[0]-- resett= ing Jul 26 04:09:53 strawberry kernel: Interface is RUNNING and ACTIVE Jul 26 04:09:53 strawberry kernel: em1: TX Queue 0 ------ Jul 26 04:09:53 strawberry kernel: em1: hw tdh =3D 524, hw tdt =3D 544 Jul 26 04:09:53 strawberry kernel: em1: Tx Queue Status =3D -2147483648 Jul 26 04:09:53 strawberry kernel: em1: TX descriptors avail =3D 1004 Jul 26 04:09:53 strawberry kernel: em1: Tx Descriptors avail failure =3D 0 Jul 26 04:09:53 strawberry kernel: em1: RX Queue 0 ------ Jul 26 04:09:53 strawberry kernel: em1: hw rdh =3D 172, hw rdt =3D 170 Jul 26 04:09:53 strawberry kernel: em1: RX discarded packets =3D 0 Jul 26 04:09:53 strawberry kernel: em1: RX Next to Check =3D 171 Jul 26 04:09:53 strawberry kernel: em1: RX Next to Refresh =3D 170 Jul 26 04:09:53 strawberry kernel: em1: link state changed to DOWN Jul 26 04:09:54 strawberry kernel: em1: link state changed to UP Jul 26 04:10:20 strawberry kernel: em1: Watchdog timeout Queue[0]-- resett= ing Jul 26 04:10:20 strawberry kernel: Interface is RUNNING and ACTIVE Jul 26 04:10:20 strawberry kernel: em1: TX Queue 0 ------ Jul 26 04:10:20 strawberry kernel: em1: hw tdh =3D 0, hw tdt =3D 358 Jul 26 04:10:20 strawberry kernel: em1: Tx Queue Status =3D -2147483648 Jul 26 04:10:20 strawberry kernel: em1: TX descriptors avail =3D 666 Jul 26 04:10:20 strawberry kernel: em1: Tx Descriptors avail failure =3D 0 Jul 26 04:10:20 strawberry kernel: em1: RX Queue 0 ------ Jul 26 04:10:20 strawberry kernel: em1: hw rdh =3D 0, hw rdt =3D 1023 Jul 26 04:10:20 strawberry kernel: em1: RX discarded packets =3D 0 Jul 26 04:10:20 strawberry kernel: em1: RX Next to Check =3D 0 Jul 26 04:10:20 strawberry kernel: em1: RX Next to Refresh =3D 1023 Jul 26 04:10:20 strawberry kernel: em1: link state changed to DOWN I'll give r336313 a try as soon as possible and corroborate the fixes! Cheers, R Tyler Croy --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSQYoZaRujHSSvxiNcUJsfcP1HhbwUCW1lSRQAKCRAUJsfcP1Hh bzIpAKCnryspKEsRIRn5Oe6OulyJevykWACgptdnvoU+MYHVWpIz5RTjoRA2GAk= =GIlg -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-freebsd-current@freebsd.org Thu Jul 26 06:29:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 969C51041B76 for ; Thu, 26 Jul 2018 06:29:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 2C402806E1 for ; Thu, 26 Jul 2018 06:29:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22b.google.com with SMTP id l189-v6so205182ywb.10 for ; Wed, 25 Jul 2018 23:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8LNsy1KuRxGBm/Du5thrPBezGRokqVns0DH8R6i4fJU=; b=rykRnD1WvBdo6LwcUtHsXJWIFvHSx20ttvrx0R2ALpzfLwqZWgTw2jEQmpURAn0kks Y+MTEh3OByftCDgqSfqgA/z7e6SOtRIO8CwMk9cf3Z1+GsXh9HJG71te4G/WfPnapduM Y8Ezfx4Biv2hg239fedvdF+tS0xOHDOxx+PJU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8LNsy1KuRxGBm/Du5thrPBezGRokqVns0DH8R6i4fJU=; b=rjjxv9ZP1tF850JS7PTOis4gxSNZ8yCedLT+UVlAsm5YQvYSufaqbqO6jUmqyp/R2f sFDGYZtpBFBsEo8VerYh23Y/hMqsMYcbrkY+ZYFXCLxtUwcrbwzxHAlDIkiro89JqQ/S wqkMVxy/HMRNA8p8/p2B8si/3CENF5wANGdoGTdutbOZmaDc5pyLBnnL2Lsb1ReLZB6Q A1xdiOtseZA+PsEEsDWKWXEe9PYrDUk06Jf1pu+a9Ymrc0M7TUf6xs8LTV5lVXGeS+8L D7AALSIc0kICzZMnbci3r/xXqBhwbQGeh2y9kjSzLRZqt8IPG+dRXMiLhkPWBvLjETTH g2UQ== X-Gm-Message-State: AOUpUlF5bK8k0dy58uKfoqG+fF7HTRZC2syr8A5c/5eXmoe76UL7cT/6 wPtLQFRzQzrNSnNcZX/cgJhF62Tt6NSYKmIY34bICubN5MTWUw== X-Google-Smtp-Source: AAOMgpe77/VMa4Tzvxiw1Qcw62ec7/wfqtWEkpIhlUrd6SbnqcjRPIh0P+dpSOTMFXBo/F4P7R0CQeZ5a2KrUw4az0o= X-Received: by 2002:a81:af06:: with SMTP id n6-v6mr273354ywh.113.1532586597217; Wed, 25 Jul 2018 23:29:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eitan Adler Date: Wed, 25 Jul 2018 23:29:31 -0700 Message-ID: Subject: Re: error building r336696: cp: asn1_OCSPResponseStatus.c: Bad address To: freebsd-current Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 06:29:58 -0000 On Wed, 25 Jul 2018 at 06:31, Eitan Adler wrote: > > I'm currently on r335788 and trying to build r336696. Going to r336238 and then r336732 seems to have succeeded. -- Eitan Adler From owner-freebsd-current@freebsd.org Thu Jul 26 06:35:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 469A91041F00 for ; Thu, 26 Jul 2018 06:35:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD9C780B19; Thu, 26 Jul 2018 06:35:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-169-199-167.dyn.iinet.net.au [124.169.199.167]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w6Q6Z4jR085604 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2018 23:35:07 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: gcc/clang interoperability problem with a custom "samba" build in recent -current. From: Julian Elischer To: Dimitry Andric , Yuri Pankov Cc: freebsd-current References: <3dd60a0d-7a5e-e9f0-3018-d09b5b8ac389@yuripv.net> <0a54cb6e-f528-df63-57f2-6caa3d76ff6c@freebsd.org> Message-ID: <2c5d8af1-f703-e33b-2b71-905dc8fe0908@freebsd.org> Date: Thu, 26 Jul 2018 14:34:59 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0a54cb6e-f528-df63-57f2-6caa3d76ff6c@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 06:35:10 -0000 On 25/7/18 12:40 am, Julian Elischer wrote: > On 22/7/18 4:32 am, Dimitry Andric wrote: >> On 21 Jul 2018, at 21:11, Yuri Pankov wrote: >>> Yuri Pankov wrote: >>>> Julian Elischer wrote: >> ... >>>>>> anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? >>>> In later GCC versions the cpp's -lang-asm seems to be deprecated in >>>> favor of -x assembler-with-cpp as it conflicts with -l option. >>>> Could you try changing the -Wp,-E,-lang-asm to >>>> -Wp,-E,-xassembler-with-cpp? I did this but if failed.. I had to reread this email  a few times to think of replacing the whole -Wp,-E,-lang-asm  with just  -xassembler-with-cpp! >>> Just tried it myself, and if you indeed mean the >>> third_party/aesni-intel/aesni-intel_asm.c, the following seems to >>> work for me: >>> >>> clang -xassembler-with-cpp -c >>> third_party/aesni-intel/aesni-intel_asm.c >> Yes, that is exactly what I suggested to Julian on IRC.  The point is >> that the ".c" extension is misleading, it should more likely be a ".S" >> extension.  But maybe this source file is used for multiple purposes. >> >> Note that -x assembler-with-cpp should also work fine for gcc. Ah..  the trick is to remove the -Wp,-E as well... >> >> -Dimitry >> > thanks > > I tried that but the version of the file we have has several lines > that caused problems... > > a lot of the assembler has assembler comments (starting with '#') > which clang complained about and died.. > > it also had #.align 4 > > which I HOPE is just a commented out line.. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Jul 26 13:58:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18E8F105000E for ; Thu, 26 Jul 2018 13:58:43 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79E12905EC; Thu, 26 Jul 2018 13:58:42 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MGj8j-1fmpWv1Zi5-00DZPg; Thu, 26 Jul 2018 15:58:28 +0200 Date: Thu, 26 Jul 2018 15:58:26 +0200 From: "O. Hartmann" To: "Rodney W. Grimes" Cc: Toomas Soome , freebsd-current , Allan Jude Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:nSGtrVdUW3hxlsEmhOdlPzFAF8vSb7LyW6EJb4J8opkVrwbtYZg vFEUIOMKoNdlXl+e+YE+ChuVA5sIoLgkxHWlxBzDONkPLN1jXZkVcqhEiFj4OvvG6it8FAA entNAL+MlZtKIFbDd/RzMy4zmJzYbAWpwYHrZ+4kUOTRZT+ZrLOk6GsHLiWkN4HI7qYektd ErEtRrXMBjHySsUOsl7QQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:83yZbVLGPZI=:MdcoCJV3Yvgneulz1CQLom 3hBxdiZqdPG/ezs/GtwWEw5MV3EkyAnlnHV8FxN/mBOmPnRVQa0EfDggV2lnQaGuac58SC5iu c0AzaaaLs4hTsOO00EMeRoTeMNtgU4T0CA3QYM7nQjgJ0oFXTW6pc1DdfxBfsNuJAtxihuZOk Ek3Gz7rPC5iR8Gn39Q+jWvuvuYv1nn9bJlMB2dJ0Xlt2V/30f4VHemER49TVdlW8/mc8y/3Cj HwEuczfivunBxOmESdv91B8EmjlvajW/aRckZ4jIVLHrhP4E9475UFM0igsjMp9Q0x47UCHmR 4Q2JA3HZ4MoqYN3Ob+13RgPxGgP0i6Dad7/1YGBWnHST5n87YY5JaoPxVH7V/StF42qMB6gQM J8wiqXIPhbwLhyukz4tsjafuPk3bYMU39S9lz11xs91OJkHwy69jND/Mjb+rbwGkx3sjj778H LBVKcf/gMWkS8fAmE/GxTGNxtW/Ci3WrbUnajPnmsUBvsPAgeFmPUZBtARYZQlvUUW9adiB4+ iJj9Fjc/x3EjubzVC+LeHHPYOt4JunN5x4HIRfuDg/ygUEPXUy8a8CPowt7eRLWK+EZ/kbEUK IegfxcYu3SDidddNaUMFSKvoY0yBosnFvai8SkPJIxO5zzbMq3az5xGCtrmtyUzPdLX6kOwPB Bkz+nyRhvImLkcnxOhlnu9I+qXiPYItZwvQKuIfUvym0+dYpA/YCcjNhutU4M8F+o4ZsbJfrg wTOl6JuDlh5MR5Cpf+9mthGPE7NBw2AcommJ2VYG4vzrLlPNOxWAToxm9HzDXjoFx1fiAyzzX g0cE8sj X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 13:58:43 -0000 On Wed, 25 Jul 2018 07:30:32 -0700 (PDT) "Rodney W. Grimes" wrote: > > > On 25 Jul 2018, at 12:10, O. Hartmann wrote: > > > > > > On Wed, 25 Jul 2018 11:46:07 +0300 > > > Toomas Soome wrote: > > > > > >>> On 25 Jul 2018, at 10:59, O. Hartmann wrote: > > >>> > > >>> On Tue, 24 Jul 2018 08:53:36 +0300 > > >>> Toomas Soome wrote: > > >>> > > >>> > > >>> Hello Toomas Soome, > > >>> > > >>> I CC Allan Jude since I discovered something weird today regarding the > > >>> UEFI boot capabilities of USB flash devices and SSDs. See below. > > >>> > > >>>>> On 24 Jul 2018, at 08:16, O. Hartmann wrote: > > >>>>> > > >>>>> On Mon, 23 Jul 2018 10:56:04 +0300 > > >>>>> Toomas Soome wrote: > > >>>>> > > >>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 > > >>>>>>> Toomas Soome > wrote: > > >>>>>>> > > >>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann > >>>>>>>>> > wrote: > > >>>>>>>>> > > >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > > >>>>>>>>> Hash: SHA512 > > >>>>>>>>> > > >>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 > > >>>>>>>>> Toomas Soome > > >>>>>>>>> >> schrieb: > > >>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann > > >>>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> The problem is some kind of weird. I face UEFI boot problems on > > >>>>>>>>>>> GPT drives where the first partition begins at block 40 of the > > >>>>>>>>>>> hdd/ssd. > > >>>>>>>>>>> > > >>>>>>>>>>> I have two host in private use based on an > > >>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, > > >>>>>>>>>>> Socket LGA1155). Both boards are equipted with the lates > > >>>>>>>>>>> official available AMI firmware revision, dating to 2013. This > > >>>>>>>>>>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77 > > >>>>>>>>>>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision > > >>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I didn't > > >>>>>>>>>>> test that. But please read. > > >>>>>>>>>>> > > >>>>>>>>>>> The third box I realised this problem is a brand new Fujitsu > > >>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for > > >>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525). > > >>>>>>>>>>> > > >>>>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall > > >>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned device > > >>>>>>>>>>> fails. The ASRock boards jump immediately into the firmware, > > >>>>>>>>>>> the Fujitsu offers some kind of CPU/Memory/HDD test facility. > > >>>>>>>>>>> > > >>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot > > >>>>>>>>>>> only is implied, the MBR partitioned FreeBSD installation USB > > >>>>>>>>>>> flash device does boot in UEFI! I guess I can assume this when > > >>>>>>>>>>> the well known clumsy 80x25 char console suddenly gets bright > > >>>>>>>>>>> and shiny with a much higher resoltion as long the GPU supports > > >>>>>>>>>>> EFI GOP. Looking with gpart at the USB flash drives reveals > > >>>>>>>>>>> that the EFI partition starts at block 1 of the device and the > > >>>>>>>>>>> device has a MBR layout. I haven't found a way to force the GPT > > >>>>>>>>>>> scheme, when initialised via gpart, to let the partitions start > > >>>>>>>>>>> at block 1. This might be a naiv thinking, so please be patient > > >>>>>>>>>>> with me. > > >>>>>>>>>>> > > >>>>>>>>>>> I do not know whether this is a well-known issue. On the ASRock > > >>>>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI > > >>>>>>>>>>> and that worked - FreeBSD not. I gave up on that that time. > > >>>>>>>>>>> Now, having the very same issues with a new Fujitsu system, > > >>>>>>>>>>> leaves me with the impression that FreeBSD's UEFI > > >>>>>>>>>>> implementation might have problems I'm not aware of. > > >>>>>>>>>>> > > >>>>>>>>>>> Can someone shed some light onto this? > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> The first thing to check is if the secure boot is disabled. We > > >>>>>>>>>> do not support secure boot at all at this time. > > >>>>>>>>> > > >>>>>>>>> Secure boot is in every scenario disabled! > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> If you have efi or bios version running - you can check from > > >>>>>>>>>> either console variable value (it can have efi or vidconsole or > > >>>>>>>>>> comconsole) or better yet, see if efi-version is set (show > > >>>>>>>>>> efi-version) - if efi-version is not set, it is BIOS loader > > >>>>>>>>>> running. Another indirect way is to see lsdev -v, with device > > >>>>>>>>>> paths present, it is uefi:) > > >>>>>>>>> > > >>>>>>>>> What are you talking about? > > >>>>>>>>> What is the point of entry - running system, loader? > > >>>>>>>>> > > >>>>>>>>> sysct machdep.bootmethod: BIOS > > >>>>>>>>> > > >>>>>>>>> This makes me quite sure that the system has booted via BIOS - as > > >>>>>>>>> I'm sure since I've checked that many times. UEFI doesn't work on > > >>>>>>>>> those systems with FreeBSD. I'm not sure antmore, but I tried > > >>>>>>>>> also Windows 7 on those mainboards booting via UEFI - and I might > > >>>>>>>>> recall that they failed also. I also recall that there were > > >>>>>>>>> issues with earlier UEFI versions regarding booting only Windows > > >>>>>>>>> 8/8.1 - and nothing else, but the fact that Linux worked confuses > > >>>>>>>>> me a bit. > > >>>>>>>>> > > >>>>>>>>> If this ASRock crap (never ever again this brand!) doesn't work at > > >>>>>>>>> all - who cares, I intend to purchase new server grade hardware. > > >>>>>>>>> But the more puzzling issue is with the Fujitsu, which I consider > > >>>>>>>>> serious and from the behaviour the Fujitsu failure looks exactly > > >>>>>>>>> like the ASRock - Windows 7 works, RedHat 7.5 works (I assume I > > >>>>>>>>> can trust the Firmware settings when I disable CSM support, that > > >>>>>>>>> the Firmware will only EFI/UEFI capable loader? Or is there a > > >>>>>>>>> ghosty override somwhere to be expected?). Also on ASRock > > >>>>>>>>> disabling CSM should ensure not booting a dual-bootstrap-capable > > >>>>>>>>> system. This said, on the recent Fujitsu, it seems to boil down > > >>>>>>>>> to a FreeBSD UEFI-firmware interaction problem, while the ASRock > > >>>>>>>>> is still under suspicion to be broken by design. > > >>>>>>>>>> > > >>>>>>>>>> GPT partitions can never start from disk absolute sector 1; this > > >>>>>>>>>> is because at sector 0 there is MBR (for compatibility), sector > > >>>>>>>>>> 1 is GPT table and then sectors 2-33 have GPT partition table > > >>>>>>>>>> entries, so the first possible data sector is 34 (absolute 34). > > >>>>>>>>>> Thats assuming 512B sectors. For details see UEFI 2.7 Chapter > > >>>>>>>>>> 5.3.1 page 131. > > >>>>>>>>> > > >>>>>>>>> Thanks for the explanation. That implies the installer did right, > > >>>>>>>>> gpart did also right and therefore there must be an issue with the > > >>>>>>>>> stuff located within the EFI partition? > > >>>>>>>> > > >>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach > > >>>>>>>> BIOS loader at all or not - that is, if the BIOS bootstrap is > > >>>>>>>> actually caring to read the MBR code and start it, since once the > > >>>>>>>> MBR code is started, it is all about our code. > > >>>>>>> > > >>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or > > >>>>>>> do you mean that specific portion of the UEFI firmware, which looks > > >>>>>>> for the proper UEFI partition? > > >>>>>>> > > >>>>>> > > >>>>>> BIOS as either native or CSM. Note that from boot code point of view > > >>>>>> the CSM boot *is* BIOS boot, we have no access to UEFI features. > > >>>>>> > > >>>>>>> > > >>>>>>> The boxes in question, most notably the more recent Fujitsu Esprimo > > >>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms of what > > >>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is switched > > >>>>>>> off in the firmware. Again: GPT partition scheme. > > >>>>>>> > > >>>>>>> The system boots properly if a second partition of type > > >>>>>>> "freebsd-boot" is applied and bootcode is properly applied via > > >>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" (ada0 is > > >>>>>>> the device). > > >>>>>>>> > > >>>>>>>> btw, you can try to validate the installed boot blocks by using > > >>>>>>>> recent enough loader (usb or iso) and then you can use from OK > > >>>>>>>> prompt: > > >>>>>>> > > >>>>>>> lsdev provides me with the follwoing informations (CSM enabled): > > >>>>>>> > > >>>>>>> OK lsdev > > >>>>>>> disk devices: > > >>>>>>> disk0: BIOS DRIVE C ... > > >>>>>>> > > >>>>>>> disk0p1: EFI > > >>>>>>> disk0p2: FreeBSD BOOT > > >>>>>>> disk0p3: FreeBSD SWAP > > >>>>>>> disk0p4: FreeBSD ZFS > > >>>>>>> zfs devices: > > >>>>>>> zfs:zroot > > >>>>>>> > > >>>>>>> OK chain disk0 > > >>>>>>> open failed (so for disk0p{1-4}. > > >>>>>>> > > >>>>>>> OK chain zroot > > >>>>>>> failed to read disk (just for completeness) > > >>>>>> > > >>>>>> > > >>>>>> chain command does use only device name (such as disk0: or > > >>>>>> disk0p2: ), but not zfs pool as device. I just found I haven?t > > >>>>>> ported the code to read the file. > > >>>>> > > >>>>> ?? > > >>>>> > > >>>>>> > > >>>>>> the point for chain command test is to see if the normal read and > > >>>>>> execute would work, so in your case please try: > > >>>>>> > > >>>>>> chain disk0: > > >>>>> > > >>>>> As stated above, I did so, and the result is also mentioned above, I > > >>>>> always get "open failed". > > >>>>> This is the same for > > >>>>> > > >>>>> chain disk0 > > >>>>> chain disk0p1 > > >>>>> chain disk0p2 > > >>>>> chain disk0p3 > > >>>>> chain disk0p4 > > >>>>> > > >>>>> as already said. CSM is enabled in this case. > > >>>> > > >>>> sigh? chain command does take device as argument, device must always > > >>>> end with colon?. in this case, the devil is in details:) as I wrote > > >>>> above, the command should be: > > >>>> > > >>>> chain disk0: > > >>>> > > >>>> The disk0p1: etc will only work when partition boot code was installed > > >>>> (which you most likely do not have - the only possible candidate could > > >>>> be FreeBSD ZFS partition). > > >>> > > >>> The command "chain disk0:" works as expected (CSM enabled, GPT partition > > >>> scheme, but with PMBR bootblock installed and freebsd-boot partition > > >>> conatining gptzfsboot installed. > > >>> > > >>> > > >>>> > > >>>>> > > >>>>>> > > >>>>>> to read pmbr (512B) and execute it. The expected outcome would be > > >>>>>> that pmbr boot code would browse the GPT, read stage1 from disk0p2: > > >>>>>> and execute it; stage1 would detect FreeBSD ZFS from disk0p4: and > > >>>>>> load and execute /boot/loader. If that will happen, it means the > > >>>>>> boot code in our stages is just fine, but the bios (CSM) does not > > >>>>>> load pmbr?. if thats true, it would mean that you either need to > > >>>>>> use UEFI boot or need to have some hack to fool the BIOS or just not > > >>>>>> use GPT on that machine with CSM. > > >>>>> > > >>>>> To make it clear here: The only way to boot this box is using CSM (as > > >>>>> it is the same with the ASRock boards mentioned earlier). But my > > >>>>> intention is to disable CSM and use a GPT/UEFI environment only! And > > >>>>> GPT/UEFI doesn't work with FreeBSD, neither with 12-CURRENT, nor > > >>>>> 11.2-RELENG. > > >>>>> > > >>>>> It would be nice if this could be fixed. I'm more interested in the > > >>>>> fix on the recent Fujitsu device than the outdated ASRock crap, but > > >>>>> if the fix for the Fujitsu Firmware could fix older issues as a > > >>>>> byproduct, I'd appreciate that. > > >>>>> > > >>>>> Kind regards, > > >>>>> > > >>>> > > >>>> ok, somehow I have lost that part of the discussion. Well, you wrote > > >>>> that the UEFI boot fails when the first partition starts from sector > > >>>> 40 - does it mean you have boot when the partition will start from > > >>>> some other sector? I think, there is something else going on. > > >>> > > >>> Well, I simply try to describe what I "see" to make things > > >>> disambiguous. I'm not familiar with the deeper insights of disk layouts > > >>> on a binary level. So, you explained to me the reason, why ESP (EGI > > >>> partition) starts at block 40. I compared that to the FreeBSD USB flash > > >>> image FreeBSD provides, but this is another story since the image uses > > >>> MBR scheme as I figured out. > > >>> > > >>> > > >>>> > > >>>> What you can do is to see if that firmware will offer you EFI shell > > >>>> option, from there you can try to start the bootx64.efi manually and > > >>>> see what error you will get. However, the number 1 cause for failing > > >>>> to start the bootloader in UEFI is secure boot - we do not support it > > >>>> and secure boot must be switched off. > > >>>> > > >>>> However, they seem to claim "The Secure Boot option is available in the > > >>>> UEFI/BIOS of most if not all ASRock boards. It is disabled by > > >>>> default.? > > >>>> > > >>>> Still suggest to double check if thats really the case. Also, if the > > >>>> bootx64.efi start will fail and no messages are appearing on screen, > > >>>> then either there is something in firmware logs or you could get them > > >>>> from trying to start bootx64.efi from UEFI shell. > > >>> > > >>> Since I'm with this problem since 2014 and try from time to time, be > > >>> ausred that I tried every possible permutationof all reasonable > > >>> options, even those nonsense, to get rid of that problem. > > >>> > > >>> I never had any problems with any other UEFI capable server/workstation > > >>> firmware so far booting FreeBSD off in UEFI-native (GPT partition > > >>> scheme, CSM disabled) so far - until now, when I ran into this Fujitsu > > >>> ESPRIMO Q956 with the most recent firmware (as of lat week, week 29 of > > >>> 2018) having the very same problems. > > >>> > > >>> > > >>> > > >>> I figured out something strange on the Fujitsu - and that is the same > > >>> with the ASRock boards. > > >>> > > >>> We/I prepare some USB flash drives to boot a NanoBSD for a very small > > >>> appliance, but nevertheless, the USB flash device is booted on Fujitsu > > >>> servers with UEFI-only configurations. I assume at this point that > > >>> disabling on the most recent Fujitsu firmwares on reasonable "new" > > >>> hardware (not older than three years) will disable any(!) legacy BIOS > > >>> capabilities. The same is assumed for the Fujitus ESPRIMO Q956. I can > > >>> not speak for the ASRock A77 Pro4/m boards mentioned above/earlier, > > >>> they are from 2012/2013 and "quite old". > > >>> > > >>> The NanoBSD image of ours doesn't have a "freebsd-boot" partition. The > > >>> partition scheme of the flash device is GPT. The layout looks like this: > > >>> > > >>> gpart show -l da4 > > >>> => 40 15425456 da4 GPT (7.4G) > > >>> 40 2000 1 efiboot0 (1.0M) > > >>> 2040 1453584 3 disk1a (710M) > > >>> 1455624 4096 5 disk3 (2.0M) > > >>> 1459720 13965776 - free - (6.7G) > > >>> > > >>> I created the flash with md, gpart and dd straightforward, efiboot0 is > > >>> the ESP partition and its format/content is created via dd > > >>> if=/boot/boot1.efifat of=/dev/da4p1 - I presume this is very simple. > > >>> > > >>> This USB flash device boots(!) successfully (UEFI!) on both the ASRock > > >>> boards and the Esprimo Q956! > > >>> > > >>> But any SSD prepared the same way doesn't. Why? > > >>> > > >>> On the ASRock, I recall having fiddled around with HDD also for a while > > >>> conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - I can't > > >>> remember. > > >>> > > >>> In the lack of proper hardware I'm unable to check whether USB-attached > > >>> HDD or SSD will boot or HDD will boot (just in case the local SATA has > > >>> problems booting UEFI and USB not). > > >>> > > >>> Kind regards, > > >>> > > >>> Oliver > > >>> > > >> > > >> Am. well. I think the suggestion to test out FAT32 is still good one to > > >> test. This is because it is known that some vendors do not support > > >> booting FAT12/FAT16 from HDD (the likely reason is that UEFI > > >> specification does not tell which FAT must be supported, and only hint > > >> about FAT12/FAT16 in context of removable devices). > > > > > > I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO Q956. It > > > took me a time to circumvent the installer and I had to install the > > > system manually. In that strain, I also "tried" to establish the ESP with > > > FAT32, as Allen Jude suggested earlier. I didn't find any ad hoc help how > > > to find out the format (FAT12/16/32) of the ESP, so I assume when using > > > 12-CURRENT's or 11.2-RELENG's installer with AUTO-ZFS and GPT (UEFI) > > > (only!) the resulting ESP is FAT12 or FAT16 (300mb by default). I also > > > assume, that when dd'ing the /boo/boot1.efifat image to a partition, the > > > format is FAT, but not FAT32. Therefore, I refomatted the manually > > > created ESP (using "gpart add -t efi ...") using "newfs_msdos -F 32 -b > > > xxx ...". I had to fiddle around a bit with option -b to fit in a proper > > > format to meet a 512mb ESP - I'm not sure whether this is the proper > > > option to deal with. When using the default and only -F32, the size of > > > the partition has to be 4G at least I assume. Having done that, I copied > > > the the content of boot1.efifat (mdconfig -t vnode ..., I guess we know > > > the drill ...) to the newly formatted ESP to /boot/efi/ ... > > > > > > Having so far no knowledge of how to asure that the created ESP is FAT32, > > > I assume it is FAT32. > > > > > > The result is negative on the ESPRIMO Q956. When disabling the CSM, the > > > box is not willing to boot from SSD with the ESP prepared as decribed. > > > So, a chance that this might still be due to a misconfiguration lies now > > > within the -b option of newfs_msdos - if the -b option is assumed the > > > proper option? > > > > > > At the moment, the ESP of the Esprimo is subject to changes, if you wish, > > > but not in size, since it is limited to 512mb. > > > > > > Thanks and kind regards, > > > > > > Oliver > > > > Yea, i was hoping fstyp command would report the FAT type, but it does not > > (request for feature?:) > > FYI, the file(1) command is very good at disecting a disk image to tell > you what the MBR looks like, and at looking at partitions if pointed at > them with the -s option. It should be able to detect FAT12/16/32. > > root@x230a:/home/ISO/x # file -s /dev/md2s1 > /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 ", root > entries 512, sectors 1600 (volumes <=32 MB) , sectors/FAT 5, sectors/track > 63, heads 1, serial number 0xbd4111ee, label: "EFISYS ", FAT (12 bit), > followed by FAT > > > > > However, the more annoying idea would be to install some OS which will boot > > with UEFI on this machine, then copy boot1.efi from freebsd to it (the > > default program the UEFI will load is ESP:EFI/boot/bootx64.efi in case of > > UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, we do not support > > EFI32. > > > > note that boot1.efi alone will not do much but printing on screen how it > > will search for freebsd, but for the purpose of the test it would suffice - > > that would give us confirmed working ESP file system (since the other os > > would be able to boot) and then we can confirm if boot1.efi itself is OK. > Some new results. I installed RedHat 7.5 and inestigated the ESP. - The ESP starts at block 2048, while FreeBSD's ESP starts at block 40. - size is both 200mb if installed automatically. I forgit to investigate the FAT format, but this might be unnecessary as shown further in this post. - RedHat's ESP contains ~ 10 MB of data in two folders, /efi/boot, /efi/redhat. copying FreeBSD's BOOTX64.efi over RedHat's doesn't change anything, also renaming /efi/boot/fbx64.efi of RedHat's installation. But renaming /efi/redhat renders RedHat to fail the boot process on the Fujitsu with the signs of the built-in testprogram as reported. I took the liberty and installed 11.2-RELENG again, ZFS only, UEFI boot only (CSM in firmware disabled, but there is still a gptzfsboot-prepared partition for later use, just for the record). Booting UEFI-only fails as reported. On this installation I copied the RedHat ESP completely into FreeBSD's ESP, renamed /efi/boot/BOOTX64.efi to /efi/boot/BOOTX64.efi.rh and copied FreeBSD's BOOTX64.efi to /efi/boot. The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, that the /efi/redhat folder of the ESP is important, if renamed, the whole process dies as I reported earlier. Still unanswered is the question: why is a NanoBSD prepared UEFI-only USB flash booting with CSM disabled (so asumingly UEFI only then) on both ASRock and Fujitsu (as described in more detail initially and earlier), while SSDs fail? Is there a difference? Since FreeBSD boots in UEFI mode from USB flash prepared as described (straight forward, 800k ESP starting at block 40, the boot1.efifat image dd'ed onto the partition, UFS partition following, no freebsd-boot partition or MBR/PMBR bootcode applied ever!), I think BOOTX64.EFI is technically all right. There must be then an issue with the SATA/SSD/HDD boot pathway. Hope I could provide some more details, sorry if it sounds confusing or way too long, but I try to descibe the situation as thorough as possible. Kind regards Oliver From owner-freebsd-current@freebsd.org Thu Jul 26 16:23:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 951721053C06 for ; Thu, 26 Jul 2018 16:23:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 30D3596C2E; Thu, 26 Jul 2018 16:23:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCH00N00EBURS00@st13p35im-asmtp001.me.com>; Thu, 26 Jul 2018 16:23:50 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCH00JCOEVKET60@st13p35im-asmtp001.me.com>; Thu, 26 Jul 2018 16:23:48 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-26_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=7 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807260168 From: Toomas Soome Message-id: <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations Date: Thu, 26 Jul 2018 19:23:43 +0300 In-reply-to: <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> Cc: "Rodney W. Grimes" , freebsd-current , Allan Jude To: "O. Hartmann" References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 16:23:57 -0000 > On 26 Jul 2018, at 16:58, O. Hartmann wrote: >=20 > On Wed, 25 Jul 2018 07:30:32 -0700 (PDT) > "Rodney W. Grimes" > wrote: >=20 >>>> On 25 Jul 2018, at 12:10, O. Hartmann = wrote: >>>>=20 >>>> On Wed, 25 Jul 2018 11:46:07 +0300 >>>> Toomas Soome wrote: >>>>=20 >>>>>> On 25 Jul 2018, at 10:59, O. Hartmann = wrote: >>>>>>=20 >>>>>> On Tue, 24 Jul 2018 08:53:36 +0300 >>>>>> Toomas Soome wrote: >>>>>>=20 >>>>>>=20 >>>>>> Hello Toomas Soome, >>>>>>=20 >>>>>> I CC Allan Jude since I discovered something weird today = regarding the >>>>>> UEFI boot capabilities of USB flash devices and SSDs. See below. >>>>>>=20 >>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann = wrote: >>>>>>>>=20 >>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300 >>>>>>>> Toomas Soome wrote: >>>>>>>>=20 >>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann = >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 >>>>>>>>>> Toomas Soome > wrote: >>>>>>>>>>=20 >>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann = >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>>>> Hash: SHA512 >>>>>>>>>>>>=20 >>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 >>>>>>>>>>>> Toomas Soome >>>>>>>>>>>> >> schrieb: = =20 >>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot = problems on >>>>>>>>>>>>>> GPT drives where the first partition begins at block 40 = of the >>>>>>>>>>>>>> hdd/ssd. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have two host in private use based on an >>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard = (IvyBridge, >>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the lates >>>>>>>>>>>>>> official available AMI firmware revision, dating to 2013. = This >>>>>>>>>>>>>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for = the Z77 >>>>>>>>>>>>>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA = revision >>>>>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I = didn't >>>>>>>>>>>>>> test that. But please read. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The third box I realised this problem is a brand new = Fujitsu >>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 = for >>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via = bsdinstall >>>>>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned = device >>>>>>>>>>>>>> fails. The ASRock boards jump immediately into the = firmware, >>>>>>>>>>>>>> the Fujitsu offers some kind of CPU/Memory/HDD test = facility. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI = boot >>>>>>>>>>>>>> only is implied, the MBR partitioned FreeBSD installation = USB >>>>>>>>>>>>>> flash device does boot in UEFI! I guess I can assume this = when >>>>>>>>>>>>>> the well known clumsy 80x25 char console suddenly gets = bright >>>>>>>>>>>>>> and shiny with a much higher resoltion as long the GPU = supports >>>>>>>>>>>>>> EFI GOP. Looking with gpart at the USB flash drives = reveals >>>>>>>>>>>>>> that the EFI partition starts at block 1 of the device = and the >>>>>>>>>>>>>> device has a MBR layout. I haven't found a way to force = the GPT >>>>>>>>>>>>>> scheme, when initialised via gpart, to let the partitions = start >>>>>>>>>>>>>> at block 1. This might be a naiv thinking, so please be = patient >>>>>>>>>>>>>> with me. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I do not know whether this is a well-known issue. On the = ASRock >>>>>>>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with = UEFI >>>>>>>>>>>>>> and that worked - FreeBSD not. I gave up on that that = time. >>>>>>>>>>>>>> Now, having the very same issues with a new Fujitsu = system, >>>>>>>>>>>>>> leaves me with the impression that FreeBSD's UEFI >>>>>>>>>>>>>> implementation might have problems I'm not aware of. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Can someone shed some light onto this?=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The first thing to check is if the secure boot is = disabled. We >>>>>>>>>>>>> do not support secure boot at all at this time. =20= >>>>>>>>>>>>=20 >>>>>>>>>>>> Secure boot is in every scenario disabled! >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If you have efi or bios version running - you can check = from >>>>>>>>>>>>> either console variable value (it can have efi or = vidconsole or >>>>>>>>>>>>> comconsole) or better yet, see if efi-version is set (show >>>>>>>>>>>>> efi-version) - if efi-version is not set, it is BIOS = loader >>>>>>>>>>>>> running. Another indirect way is to see lsdev -v, with = device >>>>>>>>>>>>> paths present, it is uefi:) =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> What are you talking about? >>>>>>>>>>>> What is the point of entry - running system, loader? >>>>>>>>>>>>=20 >>>>>>>>>>>> sysct machdep.bootmethod: BIOS >>>>>>>>>>>>=20 >>>>>>>>>>>> This makes me quite sure that the system has booted via = BIOS - as >>>>>>>>>>>> I'm sure since I've checked that many times. UEFI doesn't = work on >>>>>>>>>>>> those systems with FreeBSD. I'm not sure antmore, but I = tried >>>>>>>>>>>> also Windows 7 on those mainboards booting via UEFI - and I = might >>>>>>>>>>>> recall that they failed also. I also recall that there were >>>>>>>>>>>> issues with earlier UEFI versions regarding booting only = Windows >>>>>>>>>>>> 8/8.1 - and nothing else, but the fact that Linux worked = confuses >>>>>>>>>>>> me a bit. >>>>>>>>>>>>=20 >>>>>>>>>>>> If this ASRock crap (never ever again this brand!) doesn't = work at >>>>>>>>>>>> all - who cares, I intend to purchase new server grade = hardware. >>>>>>>>>>>> But the more puzzling issue is with the Fujitsu, which I = consider >>>>>>>>>>>> serious and from the behaviour the Fujitsu failure looks = exactly >>>>>>>>>>>> like the ASRock - Windows 7 works, RedHat 7.5 works (I = assume I >>>>>>>>>>>> can trust the Firmware settings when I disable CSM support, = that >>>>>>>>>>>> the Firmware will only EFI/UEFI capable loader? Or is there = a >>>>>>>>>>>> ghosty override somwhere to be expected?). Also on ASRock >>>>>>>>>>>> disabling CSM should ensure not booting a = dual-bootstrap-capable >>>>>>>>>>>> system. This said, on the recent Fujitsu, it seems to boil = down >>>>>>>>>>>> to a FreeBSD UEFI-firmware interaction problem, while the = ASRock >>>>>>>>>>>> is still under suspicion to be broken by design. =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> GPT partitions can never start from disk absolute sector = 1; this >>>>>>>>>>>>> is because at sector 0 there is MBR (for compatibility), = sector >>>>>>>>>>>>> 1 is GPT table and then sectors 2-33 have GPT partition = table >>>>>>>>>>>>> entries, so the first possible data sector is 34 (absolute = 34). >>>>>>>>>>>>> Thats assuming 512B sectors. For details see UEFI 2.7 = Chapter >>>>>>>>>>>>> 5.3.1 page 131. =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks for the explanation. That implies the installer did = right, >>>>>>>>>>>> gpart did also right and therefore there must be an issue = with the >>>>>>>>>>>> stuff located within the EFI partition? =20 >>>>>>>>>>>=20 >>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we = reach >>>>>>>>>>> BIOS loader at all or not - that is, if the BIOS bootstrap = is >>>>>>>>>>> actually caring to read the MBR code and start it, since = once the >>>>>>>>>>> MBR code is started, it is all about our code. =20 >>>>>>>>>>=20 >>>>>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the = CSM? or >>>>>>>>>> do you mean that specific portion of the UEFI firmware, which = looks >>>>>>>>>> for the proper UEFI partition? >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> BIOS as either native or CSM. Note that from boot code point = of view >>>>>>>>> the CSM boot *is* BIOS boot, we have no access to UEFI = features. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The boxes in question, most notably the more recent Fujitsu = Esprimo >>>>>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms = of what >>>>>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is = switched >>>>>>>>>> off in the firmware. Again: GPT partition scheme. >>>>>>>>>>=20 >>>>>>>>>> The system boots properly if a second partition of type >>>>>>>>>> "freebsd-boot" is applied and bootcode is properly applied = via >>>>>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" = (ada0 is >>>>>>>>>> the device). =20 >>>>>>>>>>>=20 >>>>>>>>>>> btw, you can try to validate the installed boot blocks by = using >>>>>>>>>>> recent enough loader (usb or iso) and then you can use from = OK >>>>>>>>>>> prompt: =20 >>>>>>>>>>=20 >>>>>>>>>> lsdev provides me with the follwoing informations (CSM = enabled): >>>>>>>>>>=20 >>>>>>>>>> OK lsdev >>>>>>>>>> disk devices: >>>>>>>>>> disk0: BIOS DRIVE C ... >>>>>>>>>>=20 >>>>>>>>>> disk0p1: EFI >>>>>>>>>> disk0p2: FreeBSD BOOT >>>>>>>>>> disk0p3: FreeBSD SWAP >>>>>>>>>> disk0p4: FreeBSD ZFS >>>>>>>>>> zfs devices: >>>>>>>>>> zfs:zroot >>>>>>>>>>=20 >>>>>>>>>> OK chain disk0 >>>>>>>>>> open failed (so for disk0p{1-4}. >>>>>>>>>>=20 >>>>>>>>>> OK chain zroot >>>>>>>>>> failed to read disk (just for completeness) =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> chain command does use only device name (such as disk0: or >>>>>>>>> disk0p2: ), but not zfs pool as device. I just found I = haven?t >>>>>>>>> ported the code to read the file. =20 >>>>>>>>=20 >>>>>>>> ?? >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> the point for chain command test is to see if the normal read = and >>>>>>>>> execute would work, so in your case please try: >>>>>>>>>=20 >>>>>>>>> chain disk0: =20 >>>>>>>>=20 >>>>>>>> As stated above, I did so, and the result is also mentioned = above, I >>>>>>>> always get "open failed". >>>>>>>> This is the same for=20 >>>>>>>>=20 >>>>>>>> chain disk0 >>>>>>>> chain disk0p1 >>>>>>>> chain disk0p2 >>>>>>>> chain disk0p3 >>>>>>>> chain disk0p4 >>>>>>>>=20 >>>>>>>> as already said. CSM is enabled in this case. =20 >>>>>>>=20 >>>>>>> sigh? chain command does take device as argument, device must = always >>>>>>> end with colon?. in this case, the devil is in details:) as I = wrote >>>>>>> above, the command should be: >>>>>>>=20 >>>>>>> chain disk0: >>>>>>>=20 >>>>>>> The disk0p1: etc will only work when partition boot code was = installed >>>>>>> (which you most likely do not have - the only possible candidate = could >>>>>>> be FreeBSD ZFS partition). =20 >>>>>>=20 >>>>>> The command "chain disk0:" works as expected (CSM enabled, GPT = partition >>>>>> scheme, but with PMBR bootblock installed and freebsd-boot = partition >>>>>> conatining gptzfsboot installed. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> to read pmbr (512B) and execute it. The expected outcome would = be >>>>>>>>> that pmbr boot code would browse the GPT, read stage1 from = disk0p2: >>>>>>>>> and execute it; stage1 would detect FreeBSD ZFS from disk0p4: = and >>>>>>>>> load and execute /boot/loader. If that will happen, it means = the >>>>>>>>> boot code in our stages is just fine, but the bios (CSM) does = not >>>>>>>>> load pmbr?. if thats true, it would mean that you either need = to >>>>>>>>> use UEFI boot or need to have some hack to fool the BIOS or = just not >>>>>>>>> use GPT on that machine with CSM. =20 >>>>>>>>=20 >>>>>>>> To make it clear here: The only way to boot this box is using = CSM (as >>>>>>>> it is the same with the ASRock boards mentioned earlier). But = my >>>>>>>> intention is to disable CSM and use a GPT/UEFI environment = only! And >>>>>>>> GPT/UEFI doesn't work with FreeBSD, neither with 12-CURRENT, = nor >>>>>>>> 11.2-RELENG. >>>>>>>>=20 >>>>>>>> It would be nice if this could be fixed. I'm more interested in = the >>>>>>>> fix on the recent Fujitsu device than the outdated ASRock crap, = but >>>>>>>> if the fix for the Fujitsu Firmware could fix older issues as a >>>>>>>> byproduct, I'd appreciate that. >>>>>>>>=20 >>>>>>>> Kind regards, >>>>>>>>=20 >>>>>>>=20 >>>>>>> ok, somehow I have lost that part of the discussion. Well, you = wrote >>>>>>> that the UEFI boot fails when the first partition starts from = sector >>>>>>> 40 - does it mean you have boot when the partition will start = from >>>>>>> some other sector? I think, there is something else going on. =20= >>>>>>=20 >>>>>> Well, I simply try to describe what I "see" to make things >>>>>> disambiguous. I'm not familiar with the deeper insights of disk = layouts >>>>>> on a binary level. So, you explained to me the reason, why ESP = (EGI >>>>>> partition) starts at block 40. I compared that to the FreeBSD USB = flash >>>>>> image FreeBSD provides, but this is another story since the image = uses >>>>>> MBR scheme as I figured out. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> What you can do is to see if that firmware will offer you EFI = shell >>>>>>> option, from there you can try to start the bootx64.efi manually = and >>>>>>> see what error you will get. However, the number 1 cause for = failing >>>>>>> to start the bootloader in UEFI is secure boot - we do not = support it >>>>>>> and secure boot must be switched off.=20 >>>>>>>=20 >>>>>>> However, they seem to claim "The Secure Boot option is available = in the >>>>>>> UEFI/BIOS of most if not all ASRock boards. It is disabled by >>>>>>> default.?=20 >>>>>>>=20 >>>>>>> Still suggest to double check if thats really the case. Also, if = the >>>>>>> bootx64.efi start will fail and no messages are appearing on = screen, >>>>>>> then either there is something in firmware logs or you could get = them >>>>>>> from trying to start bootx64.efi from UEFI shell. =20 >>>>>>=20 >>>>>> Since I'm with this problem since 2014 and try from time to time, = be >>>>>> ausred that I tried every possible permutationof all reasonable >>>>>> options, even those nonsense, to get rid of that problem. >>>>>>=20 >>>>>> I never had any problems with any other UEFI capable = server/workstation >>>>>> firmware so far booting FreeBSD off in UEFI-native (GPT partition >>>>>> scheme, CSM disabled) so far - until now, when I ran into this = Fujitsu >>>>>> ESPRIMO Q956 with the most recent firmware (as of lat week, week = 29 of >>>>>> 2018) having the very same problems.=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I figured out something strange on the Fujitsu - and that is the = same >>>>>> with the ASRock boards. >>>>>>=20 >>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a very = small >>>>>> appliance, but nevertheless, the USB flash device is booted on = Fujitsu >>>>>> servers with UEFI-only configurations. I assume at this point = that >>>>>> disabling on the most recent Fujitsu firmwares on reasonable = "new" >>>>>> hardware (not older than three years) will disable any(!) legacy = BIOS >>>>>> capabilities. The same is assumed for the Fujitus ESPRIMO Q956. I = can >>>>>> not speak for the ASRock A77 Pro4/m boards mentioned = above/earlier, >>>>>> they are from 2012/2013 and "quite old". >>>>>>=20 >>>>>> The NanoBSD image of ours doesn't have a "freebsd-boot" = partition. The >>>>>> partition scheme of the flash device is GPT. The layout looks = like this: >>>>>>=20 >>>>>> gpart show -l da4 =20 >>>>>> =3D> 40 15425456 da4 GPT (7.4G) =20 >>>>>> 40 2000 1 efiboot0 (1.0M) >>>>>> 2040 1453584 3 disk1a (710M) >>>>>> 1455624 4096 5 disk3 (2.0M) >>>>>> 1459720 13965776 - free - (6.7G) >>>>>>=20 >>>>>> I created the flash with md, gpart and dd straightforward, = efiboot0 is >>>>>> the ESP partition and its format/content is created via dd >>>>>> if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is very = simple. >>>>>>=20 >>>>>> This USB flash device boots(!) successfully (UEFI!) on both the = ASRock >>>>>> boards and the Esprimo Q956! >>>>>>=20 >>>>>> But any SSD prepared the same way doesn't. Why?=20 >>>>>>=20 >>>>>> On the ASRock, I recall having fiddled around with HDD also for a = while >>>>>> conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - = I can't >>>>>> remember.=20 >>>>>>=20 >>>>>> In the lack of proper hardware I'm unable to check whether = USB-attached >>>>>> HDD or SSD will boot or HDD will boot (just in case the local = SATA has >>>>>> problems booting UEFI and USB not). >>>>>>=20 >>>>>> Kind regards, >>>>>>=20 >>>>>> Oliver=20 >>>>>>=20 >>>>>=20 >>>>> Am. well. I think the suggestion to test out FAT32 is still good = one to >>>>> test. This is because it is known that some vendors do not support >>>>> booting FAT12/FAT16 from HDD (the likely reason is that UEFI >>>>> specification does not tell which FAT must be supported, and only = hint >>>>> about FAT12/FAT16 in context of removable devices). =20 >>>>=20 >>>> I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO = Q956. It >>>> took me a time to circumvent the installer and I had to install the >>>> system manually. In that strain, I also "tried" to establish the = ESP with >>>> FAT32, as Allen Jude suggested earlier. I didn't find any ad hoc = help how >>>> to find out the format (FAT12/16/32) of the ESP, so I assume when = using >>>> 12-CURRENT's or 11.2-RELENG's installer with AUTO-ZFS and GPT = (UEFI) >>>> (only!) the resulting ESP is FAT12 or FAT16 (300mb by default). I = also >>>> assume, that when dd'ing the /boo/boot1.efifat image to a = partition, the >>>> format is FAT, but not FAT32. Therefore, I refomatted the manually >>>> created ESP (using "gpart add -t efi ...") using "newfs_msdos -F 32 = -b >>>> xxx ...". I had to fiddle around a bit with option -b to fit in a = proper >>>> format to meet a 512mb ESP - I'm not sure whether this is the = proper >>>> option to deal with. When using the default and only -F32, the size = of >>>> the partition has to be 4G at least I assume. Having done that, I = copied >>>> the the content of boot1.efifat (mdconfig -t vnode ..., I guess we = know >>>> the drill ...) to the newly formatted ESP to /boot/efi/ ... >>>>=20 >>>> Having so far no knowledge of how to asure that the created ESP is = FAT32, >>>> I assume it is FAT32. >>>>=20 >>>> The result is negative on the ESPRIMO Q956. When disabling the CSM, = the >>>> box is not willing to boot from SSD with the ESP prepared as = decribed. >>>> So, a chance that this might still be due to a misconfiguration = lies now >>>> within the -b option of newfs_msdos - if the -b option is assumed = the >>>> proper option? >>>>=20 >>>> At the moment, the ESP of the Esprimo is subject to changes, if you = wish, >>>> but not in size, since it is limited to 512mb. >>>>=20 >>>> Thanks and kind regards, >>>>=20 >>>> Oliver =20 >>>=20 >>> Yea, i was hoping fstyp command would report the FAT type, but it = does not >>> (request for feature?:) =20 >>=20 >> FYI, the file(1) command is very good at disecting a disk image to = tell >> you what the MBR looks like, and at looking at partitions if pointed = at >> them with the -s option. It should be able to detect FAT12/16/32. >>=20 >> root@x230a:/home/ISO/x # file -s /dev/md2s1 >> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 = ", root >> entries 512, sectors 1600 (volumes <=3D32 MB) , sectors/FAT 5, = sectors/track >> 63, heads 1, serial number 0xbd4111ee, label: "EFISYS ", FAT (12 = bit), >> followed by FAT >>=20 >>>=20 >>> However, the more annoying idea would be to install some OS which = will boot >>> with UEFI on this machine, then copy boot1.efi from freebsd to it = (the >>> default program the UEFI will load is ESP:EFI/boot/bootx64.efi in = case of >>> UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, we do not = support >>> EFI32. >>>=20 >>> note that boot1.efi alone will not do much but printing on screen = how it >>> will search for freebsd, but for the purpose of the test it would = suffice - >>> that would give us confirmed working ESP file system (since the = other os >>> would be able to boot) and then we can confirm if boot1.efi itself = is OK. =20 >>=20 >=20 > Some new results. > I installed RedHat 7.5 and inestigated the ESP. >=20 > - The ESP starts at block 2048, while FreeBSD's ESP starts at block = 40. > - size is both 200mb if installed automatically. I forgit to = investigate the > FAT format, but this might be unnecessary as shown further in this = post. > - RedHat's ESP contains ~ 10 MB of data in two folders, /efi/boot, = /efi/redhat. > copying FreeBSD's BOOTX64.efi over RedHat's doesn't change anything, = also > renaming /efi/boot/fbx64.efi of RedHat's installation. But renaming = /efi/redhat > renders RedHat to fail the boot process on the Fujitsu with the signs = of the > built-in testprogram as reported. >=20 > I took the liberty and installed 11.2-RELENG again, ZFS only, UEFI = boot only > (CSM in firmware disabled, but there is still a gptzfsboot-prepared = partition > for later use, just for the record). Booting UEFI-only fails as = reported. On > this installation I copied the RedHat ESP completely into FreeBSD's = ESP, > renamed /efi/boot/BOOTX64.efi to /efi/boot/BOOTX64.efi.rh and copied = FreeBSD's > BOOTX64.efi to /efi/boot.=20 > The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, that > the /efi/redhat folder of the ESP is important, if renamed, the whole = process > dies as I reported earlier. >=20 > Still unanswered is the question: why is a NanoBSD prepared UEFI-only = USB flash > booting with CSM disabled (so asumingly UEFI only then) on both ASRock = and > Fujitsu (as described in more detail initially and earlier), while = SSDs fail? > Is there a difference? Since FreeBSD boots in UEFI mode from USB flash = prepared > as described (straight forward, 800k ESP starting at block 40, the = boot1.efifat > image dd'ed onto the partition, UFS partition following, no = freebsd-boot > partition or MBR/PMBR bootcode applied ever!), I think BOOTX64.EFI is > technically all right. There must be then an issue with the = SATA/SSD/HDD boot > pathway. >=20 > Hope I could provide some more details, sorry if it sounds confusing = or way too > long, but I try to descibe the situation as thorough as possible. >=20 OK, this is already good hint. The thing with ESP is that there is = =E2=80=9Cdefault=E2=80=9D file system tree: EFI/BOOT/BOOT.EFI, = this is noted as default for *removable* media, fortunately it is usable = for hard disks as well, or at least in most cases. Now, for non-removable media, the UEFI does provide boot manager = interface to define boot entries, and the fact that renaming efi/redhad = directory did break the redhat boot, is very loud hint. And this means, = this system is probably ignoring efi/boot tree on non-removable media = and is expecting the boot manager entry to be created instead. UEFI boot manager can be configured /usually/ manually via firmware = menu, or by application, such as efibootmgr. The normal approach is to = create efi/ directory and to copy the application there, = then create the boot manager configuration. See UEFI specification v2.7, chapter 3 Boot Manager, page 79. What is different in FreeBSD case is that the whole interface to program = the UEFI Boot Manager is currently being developed, so either it has to = be done manually or from some other OS (see = https://wiki.gentoo.org/wiki/Efibootmgr = for example, first hit from = google:D). rgds, toomas From owner-freebsd-current@freebsd.org Thu Jul 26 17:21:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81EAE1055523 for ; Thu, 26 Jul 2018 17:21:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AE2C710D4; Thu, 26 Jul 2018 17:21:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 935F110AFD2; Thu, 26 Jul 2018 13:21:09 -0400 (EDT) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') To: Mark Millard References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> Cc: Konstantin Belousov , FreeBSD Current From: John Baldwin Message-ID: <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> Date: Thu, 26 Jul 2018 10:21:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 26 Jul 2018 13:21:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 17:21:11 -0000 On 7/25/18 6:52 PM, Mark Millard wrote: > > > On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: > > > >> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: >> >>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >>> >>>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>>>> >>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>>> >>>>>> --- all_subdir_lib/ofed --- >>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer >>>>>> atomic_store(&lock->cnt, 0); >>>>>> ^ >>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' >>>>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>>> ^~ >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' >>>>>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>>>>> ^~ >>>>>> . . . >>>>>> --- all_subdir_lib/ofed --- >>>>>> *** [acm.o] Error code 1 >>>>>> >>>>>> >>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >>>>>> -r336700 ) still shows this type of error. >>>>> >>>>> >>>>> [I should have a subject with "head -r336568 through -r336570 . . .".] >>>>> >>>>> From what I can tell looking around having something like: >>>>> >>>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>> >>>>> involve a __atomic_fetch_add indicates that: >>>>> >>>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>>> >>>>> was in use instead of FreeBSD's stdatomic.h file. >>>>> >>>>> If this is right, then the issue may be tied to head -r335782 >>>>> implicitly changing the order of the include file directory >>>>> searching for builds via the devel/*-gcc . >>>>> >>>>> (I reverted -r335782 in my environment some time ago and have >>>>> not run into this problem in my context so far.) >>>> >>>> C11 atomics should work fine with compiler-provided headers since they >>>> are a part of the language (and the system stdatomic.h simply attempts >>>> to mimic the compiler-provided header in case it is missing). >>>> >>>> Simple standalone tests of _Atomic(int) with GCC don't trigger those >>>> failures when using its stdatomic.h, so there is probably something else >>>> going on with kernel includes being used while building the library, >>>> etc. The last time we had this issue with stdarg.h it was because a >>>> header shared between the kernel and userland always used '' >>>> which is correct for the kernel but not for userland. >>> >>> I did misread the headers. FreeBSD has the likes of: >>> >>> #if defined(__CLANG_ATOMICS) >>> . . . >>> #define atomic_fetch_add_explicit(object, operand, order) \ >>> __c11_atomic_fetch_add(object, operand, order) >>> . . . >>> #elif defined(__GNUC_ATOMICS) >>> . . . >>> #define atomic_fetch_add_explicit(object, operand, order) \ >>> __atomic_fetch_add(&(object)->__val, operand, order) >>> . . . >>> #endif >>> . . . >>> #define atomic_fetch_add(object, operand) \ >>> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) >>> >>> so __atomic_fetch_add would occur. >>> >>> But so far I do not see the problem with -r335782 reverted. I last built >>> -r336693 last night via devel/amd64-gcc (via xtoolchain). >>> >>> From what I can tell FreeBSD defines: >>> >>> #if !defined(__CLANG_ATOMICS) >>> #define _Atomic(T) struct { volatile T __val; } >>> #endif >>> >>> and that struct is being used in &(object)->__val is what the >>> error reports are about. So that would be, for example, >>> >>> &(&lock->cnt)->__val >>> >>> This would appear to suggest that __val itself had a type meeting: >>> >>> operand type struct >>> >>> for T in _Atomic(T) . >>> >>> (This is independent of just what the issue traces back to: just >>> the net result on ci.freebsd.org . No claim that you are right >>> or wrong here. I'll not be looking any more until this afternoon >>> or night.) >> >> Going in a somewhat different direction . . . >> >> Looking around I found https://bugs.llvm.org/show_bug.cgi?id=26462 >> which is titled: >> >> 26462 – GCC/clang C11 _Atomic incompatibility >> >> It appears that the normal source of platform ABI definitions are >> not explicit/detailed in the area and allow for incompatibilities >> in this area. clang and gcc made differing choices absent being >> constrained to match. >> >> An example (a powerpc64 context was indicated): >> >> struct A16 { char val[16]; }; >> _Atomic struct A16 a16; >> // GCC: >> _Static_assert(_Alignof(a16) == 16, ""); >> // Clang: >> _Static_assert(_Alignof(a16) == 1, ""); >> >> >> Non-power-of-2 is a general problem >> (not a powerpc64 context from what I can >> tell): >> >> struct A3 { char val[3]; }; >> _Atomic struct A3 a3; >> // GCC: >> _Static_assert(sizeof(a3) == 3, ""); >> _Static_assert(_Alignof(a3) == 1, ""); >> // Clang: >> _Static_assert(sizeof(a3) == 4, ""); >> _Static_assert(_Alignof(a3) == 4, ""); >> >> >> >> Comment 6 (by John McCall) is relevant: >> >> QUOTE >> Anyway, while I prefer the Clang rule, the GCC rule is defensible, as are any number of other rules. The important point, however, is that having this discussion is not the right approach to solving this problem. The layout of _Atomic(T) is ABI. ABI rules are not generally determined by compiler implementors making things up as they go along, or at least they shouldn't be. The Darwin ABI for _Atomic is the rule implemented in Clang, which we actually did think about carefully when we adopted it. Other platforms need to make their own call, and it probably shouldn't just be "whatever's implemented in GCC", especially on other platforms where GCC is not the system compiler. >> END QUOTE >> >> >> (I do nto claim to have proivided all the material that should >> be read in https://bugs.llvm.org/show_bug.cgi?id=26462 .) >> >> It may be that FreeBSD needs to be the source of the ABI definitions >> involved if clang and gcc freeBSD builds are to be interoperable in >> this area. But this could mean avoiding builtins? >> >> If any of this is inlined and so not behind a more stable interface, >> it looks like clang and gcc can not be mixed for the same instances >> of various _Atomic possibilities. >> >> > > > Going back to the code being compiled and > confirming your note: > ( /usr/src/contrib/ofed/librdmacm/cma.h ) > > typedef struct { > sem_t sem; > _Atomic(int) cnt; > } fastlock_t; > . . . > static inline void fastlock_acquire(fastlock_t *lock) > { > if (atomic_fetch_add(&lock->cnt, 1) > 0) > sem_wait(&lock->sem); > } > > So lock->cnt is an _Atomic(int) , i.e., > > struct { volatile int __val; } > > so overall: > > typedef struct { > sem_t sem; > struct { volatile int __val; } cnt; > } fastlock_t; > > > for which: atomic_fetch_add(&lock->cnt, 1) has > for A filled-in in the C11 language official: > > atomic_fetch_add (volatile A* obj, M arg) > > (generic function) being: > > atomic_fetch_add (volatile struct { volatile int __val; }* obj, M arg) > > and a direct type-check of that notation for obj would find: > > operand type 'struct *' > > and that would propagate to GCC's translation to __atomic_fetch_add > via gcc's stdatomic.h : > > #define atomic_fetch_add(PTR, VAL) __atomic_fetch_add ((PTR), (VAL), \ > __ATOMIC_SEQ_CST) > > So, yes, it looks like the: > > #if !defined(__CLANG_ATOMICS) > #define _Atomic(T) struct { volatile T __val; } > #endif So where are you seeing this btw? In head the conditional is different: #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ !__has_extension(cxx_atomic) /* * No native support for _Atomic(). Place object in structure to prevent * most forms of direct non-atomic access. */ #define _Atomic(T) struct { T volatile __val; } #endif And external GCC does support those extensions so should end up not defining an _Atomic macro, and in fact when I use -E with external GCC it leaves _Atomic(int) alone: % x86_64-unknown-freebsd11.2-gcc -E bar.c ... # 1 "bar.c" # 1 "/usr/include/sys/cdefs.h" 1 3 4 # 2 "bar.c" 2 # 1 "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" 1 3 4 # 29 "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" 3 4 # 29 "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" 3 4 typedef enum { memory_order_relaxed = 0, memory_order_consume = 1, memory_order_acquire = 2, memory_order_release = 3, memory_order_acq_rel = 4, memory_order_seq_cst = 5 } memory_order; typedef _Atomic _Bool atomic_bool; typedef _Atomic char atomic_char; ... So cdefs.h isn't overriding _Atomic and should be using the CLANG_ATOMICS case for external GCC. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Jul 26 17:56:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 948511055EF8 for ; Thu, 26 Jul 2018 17:56:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-9.consmr.mail.gq1.yahoo.com (sonic307-9.consmr.mail.gq1.yahoo.com [98.137.64.33]) (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 04C71723C2 for ; Thu, 26 Jul 2018 17:56:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EYrXbAwVM1lqtAcvRuNLwDjxagDAYFJ_Bokbud6J_4v8OSmQbvcB8g85pXEjF6v OjP6WQHr.7mwdq2_DE0fPu5AaypN3_NaN_6cqzUdvCXfydx6lRHS.xjZLUrUNvdbHi15l3gZfxLm b.J6KKEXIss_TCJHsf4JKnZWQovOsO24dx2m5B.q_8DUmwoWzCBslDUQqN2NplRxrhiMJVPERAtj kBRVLeXqZEHKCXE8w5cMO_z6tXJ9bD0SiuofZM.22HtzZrwB.y8Q4JKLwThz9fq4sRjEhJD7IwLw WkCVRobQagZOZN9yowVzIcDm5VGLLSOcB6QTYzM_Dqanm7qxN.6iKxUZU1Tfxb2PCXHnlaDPqkHL 6Lx3bbJhKpFYd36Ux1SgqplUdYlc3IBjDfn0wFgXS3CCwU2uvORZ68VaaLIknqDK6Vz5tfejlOYj FD0Qng0cBPOdXmPkCZOWzCe88_Pc2NepfWG61OX2VxmvcmLa3amwffDCFAMxxflL1NE7e60PHhqa cN_OGrB50cvTqmCPGjK8HEgvWwEn4lzqBpfpEjmbvDaA_WuoZ0._oYGEMLLagHoju3nb8mfi.LjD rOxyCWgONQ84QBF8UyyN9xlGK.VTybYIVqQmYr7VELagD2NRdzXhb2AyNqc7rNBkwA9nzg6e6G1F p.CzVDPbpNx1GxQX0H2eIj04VV8I0fPt0Z3MdqhuC9UZiUVfIxN1sVcB46ODaeZFJFPiwql.rL55 Nb3hphoMRuH4jDrEOQzjhDl_yIvPaV_O1E27IvbbM3paHKytLn__hH0QoEBuVTzy2ZHnTLY6hyR2 kUZaxLVn7cqpDcraOy519eu73vTG1r7RYggZ5AniAr8VOwpqRKZSy5sjmtK2aMSy9wMCOIXUATBx IT1Z_ANSMnd6Tm90sz51F8oqatgSh3oWjQYUzVPiGrkz7M1SpmHJAkXU7fcmdSurZyEn.uqTKqEt Q_Plg7szgFHumY1D71pxSrV1wbEBZVCZNlnjrhb_7OX36FpuvlcD3yqPt9g3w6IrfC1DDwdn69J_ _6oj9FLOaEylHC0udnQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 26 Jul 2018 17:56:04 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f610466ce0fc186c1b733e448d8a127f; Thu, 26 Jul 2018 17:55:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> Date: Thu, 26 Jul 2018 10:55:58 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 17:56:06 -0000 On 2018-Jul-26, at 10:21 AM, John Baldwin wrote: > On 7/25/18 6:52 PM, Mark Millard wrote: >>=20 >>=20 >> On 2018-Jul-25, at 2:10 PM, Mark Millard = wrote: >>=20 >>=20 >>=20 >>> On 2018-Jul-25, at 10:09 AM, Mark Millard = wrote: >>>=20 >>>> On 2018-Jul-25, at 8:39 AM, John Baldwin = wrote: >>>>=20 >>>>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard = wrote: >>>>>>=20 >>>>>>> = https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>>>>=20 >>>>>>> --- all_subdir_lib/ofed --- >>>>>>> In file included from = /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_init': >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer >>>>>>> atomic_store(&lock->cnt, 0); >>>>>>> ^ >>>>>>> In file included from = /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' >>>>>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>>>> ^~ >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand = type 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' >>>>>>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>>>>>> ^~ >>>>>>> . . . >>>>>>> --- all_subdir_lib/ofed --- >>>>>>> *** [acm.o] Error code 1 >>>>>>>=20 >>>>>>>=20 >>>>>>> = https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >>>>>>> -r336700 ) still shows this type of error. >>>>>>=20 >>>>>>=20 >>>>>> [I should have a subject with "head -r336568 through -r336570 . . = .".] >>>>>>=20 >>>>>> =46rom what I can tell looking around having something like: >>>>>>=20 >>>>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>>>=20 >>>>>> involve a __atomic_fetch_add indicates that: >>>>>>=20 >>>>>> = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>>>>=20 >>>>>> was in use instead of FreeBSD's stdatomic.h file. >>>>>>=20 >>>>>> If this is right, then the issue may be tied to head -r335782 >>>>>> implicitly changing the order of the include file directory >>>>>> searching for builds via the devel/*-gcc . >>>>>>=20 >>>>>> (I reverted -r335782 in my environment some time ago and have >>>>>> not run into this problem in my context so far.) >>>>>=20 >>>>> C11 atomics should work fine with compiler-provided headers since = they >>>>> are a part of the language (and the system stdatomic.h simply = attempts >>>>> to mimic the compiler-provided header in case it is missing). >>>>>=20 >>>>> Simple standalone tests of _Atomic(int) with GCC don't trigger = those >>>>> failures when using its stdatomic.h, so there is probably = something else >>>>> going on with kernel includes being used while building the = library, >>>>> etc. The last time we had this issue with stdarg.h it was because = a >>>>> header shared between the kernel and userland always used = '' >>>>> which is correct for the kernel but not for userland. >>>>=20 >>>> I did misread the headers. FreeBSD has the likes of: >>>>=20 >>>> #if defined(__CLANG_ATOMICS) >>>> . . . >>>> #define atomic_fetch_add_explicit(object, operand, order) = \ >>>> __c11_atomic_fetch_add(object, operand, order) >>>> . . . >>>> #elif defined(__GNUC_ATOMICS) >>>> . . . >>>> #define atomic_fetch_add_explicit(object, operand, order) = \ >>>> __atomic_fetch_add(&(object)->__val, operand, order) >>>> . . . >>>> #endif >>>> . . . >>>> #define atomic_fetch_add(object, operand) = \ >>>> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) >>>>=20 >>>> so __atomic_fetch_add would occur. >>>>=20 >>>> But so far I do not see the problem with -r335782 reverted. I last = built >>>> -r336693 last night via devel/amd64-gcc (via xtoolchain). >>>>=20 >>>> =46rom what I can tell FreeBSD defines: >>>>=20 >>>> #if !defined(__CLANG_ATOMICS) >>>> #define _Atomic(T) struct { volatile T = __val; } >>>> #endif >>>>=20 >>>> and that struct is being used in &(object)->__val is what the >>>> error reports are about. So that would be, for example, >>>>=20 >>>> &(&lock->cnt)->__val >>>>=20 >>>> This would appear to suggest that __val itself had a type meeting: >>>>=20 >>>> operand type struct >>>>=20 >>>> for T in _Atomic(T) . >>>>=20 >>>> (This is independent of just what the issue traces back to: just >>>> the net result on ci.freebsd.org . No claim that you are right >>>> or wrong here. I'll not be looking any more until this afternoon >>>> or night.) >>>=20 >>> Going in a somewhat different direction . . . >>>=20 >>> Looking around I found https://bugs.llvm.org/show_bug.cgi?id=3D26462 >>> which is titled: >>>=20 >>> 26462 =E2=80=93 GCC/clang C11 _Atomic incompatibility >>>=20 >>> It appears that the normal source of platform ABI definitions are >>> not explicit/detailed in the area and allow for incompatibilities >>> in this area. clang and gcc made differing choices absent being >>> constrained to match. >>>=20 >>> An example (a powerpc64 context was indicated): >>>=20 >>> struct A16 { char val[16]; };=20 >>> _Atomic struct A16 a16;=20 >>> // GCC: >>> _Static_assert(_Alignof(a16) =3D=3D 16, "");=20 >>> // Clang: >>> _Static_assert(_Alignof(a16) =3D=3D 1, "");=20 >>>=20 >>>=20 >>> Non-power-of-2 is a general problem >>> (not a powerpc64 context from what I can >>> tell): >>>=20 >>> struct A3 { char val[3]; }; >>> _Atomic struct A3 a3; >>> // GCC: >>> _Static_assert(sizeof(a3) =3D=3D 3, ""); >>> _Static_assert(_Alignof(a3) =3D=3D 1, ""); >>> // Clang: >>> _Static_assert(sizeof(a3) =3D=3D 4, ""); >>> _Static_assert(_Alignof(a3) =3D=3D 4, ""); >>>=20 >>>=20 >>>=20 >>> Comment 6 (by John McCall) is relevant: >>>=20 >>> QUOTE >>> Anyway, while I prefer the Clang rule, the GCC rule is defensible, = as are any number of other rules. The important point, however, is that = having this discussion is not the right approach to solving this = problem. The layout of _Atomic(T) is ABI. ABI rules are not generally = determined by compiler implementors making things up as they go along, = or at least they shouldn't be. The Darwin ABI for _Atomic is the rule = implemented in Clang, which we actually did think about carefully when = we adopted it. Other platforms need to make their own call, and it = probably shouldn't just be "whatever's implemented in GCC", especially = on other platforms where GCC is not the system compiler. >>> END QUOTE >>>=20 >>>=20 >>> (I do nto claim to have proivided all the material that should >>> be read in https://bugs.llvm.org/show_bug.cgi?id=3D26462 .) >>>=20 >>> It may be that FreeBSD needs to be the source of the ABI definitions >>> involved if clang and gcc freeBSD builds are to be interoperable in >>> this area. But this could mean avoiding builtins? >>>=20 >>> If any of this is inlined and so not behind a more stable interface, >>> it looks like clang and gcc can not be mixed for the same instances >>> of various _Atomic possibilities. >>>=20 >>>=20 >>=20 >>=20 >> Going back to the code being compiled and=20 >> confirming your note: >> ( /usr/src/contrib/ofed/librdmacm/cma.h ) >>=20 >> typedef struct { >> sem_t sem; >> _Atomic(int) cnt; >> } fastlock_t; >> . . . >> static inline void fastlock_acquire(fastlock_t *lock) >> { >> if (atomic_fetch_add(&lock->cnt, 1) > 0) >> sem_wait(&lock->sem); >> } >>=20 >> So lock->cnt is an _Atomic(int) , i.e., >>=20 >> struct { volatile int __val; } >>=20 >> so overall: >>=20 >> typedef struct { >> sem_t sem; >> struct { volatile int __val; } cnt; >> } fastlock_t; >>=20 >>=20 >> for which: atomic_fetch_add(&lock->cnt, 1) has >> for A filled-in in the C11 language official: >>=20 >> atomic_fetch_add (volatile A* obj, M arg) >>=20 >> (generic function) being: >>=20 >> atomic_fetch_add (volatile struct { volatile int __val; }* obj, M = arg) >>=20 >> and a direct type-check of that notation for obj would find: >>=20 >> operand type 'struct *' >>=20 >> and that would propagate to GCC's translation to __atomic_fetch_add >> via gcc's stdatomic.h : >>=20 >> #define atomic_fetch_add(PTR, VAL) __atomic_fetch_add ((PTR), (VAL), = \ >> __ATOMIC_SEQ_CST) >>=20 >> So, yes, it looks like the: >>=20 >> #if !defined(__CLANG_ATOMICS) >> #define _Atomic(T) struct { volatile T = __val; } >> #endif >=20 > So where are you seeing this btw? In head the conditional is = different: >=20 > #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ > !__has_extension(cxx_atomic) > /* > * No native support for _Atomic(). Place object in structure to = prevent > * most forms of direct non-atomic access. > */ > #define _Atomic(T) struct { T volatile __val; } > #endif >=20 > And external GCC does support those extensions so should end up not = defining > an _Atomic macro, and in fact when I use -E with external GCC it = leaves > _Atomic(int) alone: >=20 > % x86_64-unknown-freebsd11.2-gcc -E bar.c > ... > # 1 "bar.c" > # 1 "/usr/include/sys/cdefs.h" 1 3 4 > # 2 "bar.c" 2 > # 1 = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" = 1 3 4 > # 29 = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" = 3 4 >=20 > # 29 = "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" = 3 4 > typedef enum > { > memory_order_relaxed =3D 0, > memory_order_consume =3D 1, > memory_order_acquire =3D 2, > memory_order_release =3D 3, > memory_order_acq_rel =3D 4, > memory_order_seq_cst =3D 5 > } memory_order; >=20 >=20 > typedef _Atomic _Bool atomic_bool; > typedef _Atomic char atomic_char; > ... >=20 > So cdefs.h isn't overriding _Atomic and should be using the = CLANG_ATOMICS case > for external GCC. Some of my research was when I did not have FreeBSD available and was = over the web and I did not cross check all of it later. I apparently looked at some older source at some point. I now see what you report for the #if test. Sorry for the confusion. However, there is in /usr/src/sys/sys/cdefs.h : /* * Testing against Clang-specific extensions. */ #ifndef __has_attribute #define __has_attribute(x) 0 #endif #ifndef __has_extension #define __has_extension __has_feature #endif #ifndef __has_feature #define __has_feature(x) 0 #endif so if those are clang specific then: #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ !__has_extension(cxx_atomic) will test for C code: !0 && !0 && !0 and then the code will select to: #define _Atomic(T) struct { T volatile __val; } https://clang.llvm.org/docs/LanguageExtensions.html (for clang 7) lists: QUOTE __has_feature and __has_extension These function-like macros take a single identifier argument that is the = name of a feature. __has_feature evaluates to 1 if the feature is both = supported by Clang and standardized in the current language standard or = 0 if not (but see below), while __has_extension evaluates to 1 if the = feature is supported by Clang in the current language (either as a = language extension or a standard language feature) or 0 if not. They can = be used like this: #ifndef __has_feature // Optional of course. =20 #define __has_feature(x) 0 // Compatibility with non-clang compilers. #endif #ifndef __has_extension =20 #define __has_extension __has_feature // Compatibility with pre-3.0 = compilers. #endif END QUOTE so I think that: #define _Atomic(T) struct { T volatile __val; } is being done. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Jul 26 18:21:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D044310568B3 for ; Thu, 26 Jul 2018 18:21:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73228731F1; Thu, 26 Jul 2018 18:21:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id B9CF810AFCD; Thu, 26 Jul 2018 14:21:56 -0400 (EDT) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') To: Mark Millard References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> Cc: Konstantin Belousov , FreeBSD Current From: John Baldwin Message-ID: <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> Date: Thu, 26 Jul 2018 11:21:54 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 26 Jul 2018 14:21:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 18:21:59 -0000 On 7/26/18 10:55 AM, Mark Millard wrote: > > > On 2018-Jul-26, at 10:21 AM, John Baldwin wrote: > >> On 7/25/18 6:52 PM, Mark Millard wrote: >>> >>> >>> On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: >>> >>> >>> >>>> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: >>>> >>>>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >>>>> >>>>>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>>>>>> >>>>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>>>>> >>>>>>>> --- all_subdir_lib/ofed --- >>>>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer >>>>>>>> atomic_store(&lock->cnt, 0); >>>>>>>> ^ >>>>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' >>>>>>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>>>>> ^~ >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' >>>>>>>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>>>>>>> ^~ >>>>>>>> . . . >>>>>>>> --- all_subdir_lib/ofed --- >>>>>>>> *** [acm.o] Error code 1 >>>>>>>> >>>>>>>> >>>>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >>>>>>>> -r336700 ) still shows this type of error. >>>>>>> >>>>>>> >>>>>>> [I should have a subject with "head -r336568 through -r336570 . . .".] >>>>>>> >>>>>>> From what I can tell looking around having something like: >>>>>>> >>>>>>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>>>>>> >>>>>>> involve a __atomic_fetch_add indicates that: >>>>>>> >>>>>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>>>>> >>>>>>> was in use instead of FreeBSD's stdatomic.h file. >>>>>>> >>>>>>> If this is right, then the issue may be tied to head -r335782 >>>>>>> implicitly changing the order of the include file directory >>>>>>> searching for builds via the devel/*-gcc . >>>>>>> >>>>>>> (I reverted -r335782 in my environment some time ago and have >>>>>>> not run into this problem in my context so far.) >>>>>> >>>>>> C11 atomics should work fine with compiler-provided headers since they >>>>>> are a part of the language (and the system stdatomic.h simply attempts >>>>>> to mimic the compiler-provided header in case it is missing). >>>>>> >>>>>> Simple standalone tests of _Atomic(int) with GCC don't trigger those >>>>>> failures when using its stdatomic.h, so there is probably something else >>>>>> going on with kernel includes being used while building the library, >>>>>> etc. The last time we had this issue with stdarg.h it was because a >>>>>> header shared between the kernel and userland always used '' >>>>>> which is correct for the kernel but not for userland. >>>>> >>>>> I did misread the headers. FreeBSD has the likes of: >>>>> >>>>> #if defined(__CLANG_ATOMICS) >>>>> . . . >>>>> #define atomic_fetch_add_explicit(object, operand, order) \ >>>>> __c11_atomic_fetch_add(object, operand, order) >>>>> . . . >>>>> #elif defined(__GNUC_ATOMICS) >>>>> . . . >>>>> #define atomic_fetch_add_explicit(object, operand, order) \ >>>>> __atomic_fetch_add(&(object)->__val, operand, order) >>>>> . . . >>>>> #endif >>>>> . . . >>>>> #define atomic_fetch_add(object, operand) \ >>>>> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) >>>>> >>>>> so __atomic_fetch_add would occur. >>>>> >>>>> But so far I do not see the problem with -r335782 reverted. I last built >>>>> -r336693 last night via devel/amd64-gcc (via xtoolchain). >>>>> >>>>> From what I can tell FreeBSD defines: >>>>> >>>>> #if !defined(__CLANG_ATOMICS) >>>>> #define _Atomic(T) struct { volatile T __val; } >>>>> #endif >>>>> >>>>> and that struct is being used in &(object)->__val is what the >>>>> error reports are about. So that would be, for example, >>>>> >>>>> &(&lock->cnt)->__val >>>>> >>>>> This would appear to suggest that __val itself had a type meeting: >>>>> >>>>> operand type struct >>>>> >>>>> for T in _Atomic(T) . >>>>> >>>>> (This is independent of just what the issue traces back to: just >>>>> the net result on ci.freebsd.org . No claim that you are right >>>>> or wrong here. I'll not be looking any more until this afternoon >>>>> or night.) >>>> >>>> Going in a somewhat different direction . . . >>>> >>>> Looking around I found https://bugs.llvm.org/show_bug.cgi?id=26462 >>>> which is titled: >>>> >>>> 26462 – GCC/clang C11 _Atomic incompatibility >>>> >>>> It appears that the normal source of platform ABI definitions are >>>> not explicit/detailed in the area and allow for incompatibilities >>>> in this area. clang and gcc made differing choices absent being >>>> constrained to match. >>>> >>>> An example (a powerpc64 context was indicated): >>>> >>>> struct A16 { char val[16]; }; >>>> _Atomic struct A16 a16; >>>> // GCC: >>>> _Static_assert(_Alignof(a16) == 16, ""); >>>> // Clang: >>>> _Static_assert(_Alignof(a16) == 1, ""); >>>> >>>> >>>> Non-power-of-2 is a general problem >>>> (not a powerpc64 context from what I can >>>> tell): >>>> >>>> struct A3 { char val[3]; }; >>>> _Atomic struct A3 a3; >>>> // GCC: >>>> _Static_assert(sizeof(a3) == 3, ""); >>>> _Static_assert(_Alignof(a3) == 1, ""); >>>> // Clang: >>>> _Static_assert(sizeof(a3) == 4, ""); >>>> _Static_assert(_Alignof(a3) == 4, ""); >>>> >>>> >>>> >>>> Comment 6 (by John McCall) is relevant: >>>> >>>> QUOTE >>>> Anyway, while I prefer the Clang rule, the GCC rule is defensible, as are any number of other rules. The important point, however, is that having this discussion is not the right approach to solving this problem. The layout of _Atomic(T) is ABI. ABI rules are not generally determined by compiler implementors making things up as they go along, or at least they shouldn't be. The Darwin ABI for _Atomic is the rule implemented in Clang, which we actually did think about carefully when we adopted it. Other platforms need to make their own call, and it probably shouldn't just be "whatever's implemented in GCC", especially on other platforms where GCC is not the system compiler. >>>> END QUOTE >>>> >>>> >>>> (I do nto claim to have proivided all the material that should >>>> be read in https://bugs.llvm.org/show_bug.cgi?id=26462 .) >>>> >>>> It may be that FreeBSD needs to be the source of the ABI definitions >>>> involved if clang and gcc freeBSD builds are to be interoperable in >>>> this area. But this could mean avoiding builtins? >>>> >>>> If any of this is inlined and so not behind a more stable interface, >>>> it looks like clang and gcc can not be mixed for the same instances >>>> of various _Atomic possibilities. >>>> >>>> >>> >>> >>> Going back to the code being compiled and >>> confirming your note: >>> ( /usr/src/contrib/ofed/librdmacm/cma.h ) >>> >>> typedef struct { >>> sem_t sem; >>> _Atomic(int) cnt; >>> } fastlock_t; >>> . . . >>> static inline void fastlock_acquire(fastlock_t *lock) >>> { >>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>> sem_wait(&lock->sem); >>> } >>> >>> So lock->cnt is an _Atomic(int) , i.e., >>> >>> struct { volatile int __val; } >>> >>> so overall: >>> >>> typedef struct { >>> sem_t sem; >>> struct { volatile int __val; } cnt; >>> } fastlock_t; >>> >>> >>> for which: atomic_fetch_add(&lock->cnt, 1) has >>> for A filled-in in the C11 language official: >>> >>> atomic_fetch_add (volatile A* obj, M arg) >>> >>> (generic function) being: >>> >>> atomic_fetch_add (volatile struct { volatile int __val; }* obj, M arg) >>> >>> and a direct type-check of that notation for obj would find: >>> >>> operand type 'struct *' >>> >>> and that would propagate to GCC's translation to __atomic_fetch_add >>> via gcc's stdatomic.h : >>> >>> #define atomic_fetch_add(PTR, VAL) __atomic_fetch_add ((PTR), (VAL), \ >>> __ATOMIC_SEQ_CST) >>> >>> So, yes, it looks like the: >>> >>> #if !defined(__CLANG_ATOMICS) >>> #define _Atomic(T) struct { volatile T __val; } >>> #endif >> >> So where are you seeing this btw? In head the conditional is different: >> >> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ >> !__has_extension(cxx_atomic) >> /* >> * No native support for _Atomic(). Place object in structure to prevent >> * most forms of direct non-atomic access. >> */ >> #define _Atomic(T) struct { T volatile __val; } >> #endif >> >> And external GCC does support those extensions so should end up not defining >> an _Atomic macro, and in fact when I use -E with external GCC it leaves >> _Atomic(int) alone: >> >> % x86_64-unknown-freebsd11.2-gcc -E bar.c >> ... >> # 1 "bar.c" >> # 1 "/usr/include/sys/cdefs.h" 1 3 4 >> # 2 "bar.c" 2 >> # 1 "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" 1 3 4 >> # 29 "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" 3 4 >> >> # 29 "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include/stdatomic.h" 3 4 >> typedef enum >> { >> memory_order_relaxed = 0, >> memory_order_consume = 1, >> memory_order_acquire = 2, >> memory_order_release = 3, >> memory_order_acq_rel = 4, >> memory_order_seq_cst = 5 >> } memory_order; >> >> >> typedef _Atomic _Bool atomic_bool; >> typedef _Atomic char atomic_char; >> ... >> >> So cdefs.h isn't overriding _Atomic and should be using the CLANG_ATOMICS case >> for external GCC. > > Some of my research was when I did not have FreeBSD available and was over > the web and I did not cross check all of it later. I apparently looked > at some older source at some point. I now see what you report for the > #if test. Yes, but the -E from above was when compiled with external GCC and it didn't change _Atomic(int). Here's part of the source of bar.c: #include #include struct foo { _Atomic(int) one; _Atomic int two; atomic_int three; }; And here is what that became after -E: # 4 "bar.c" struct foo { _Atomic(int) one; _Atomic int two; atomic_int three; }; So cdefs.h did not define _Atomic. Ah, if I add '-std=c99' then it does break. Code that wants to use C11 atomics via should not be using -std=c99. Try this: Index: lib/ofed/librdmacm/Makefile =================================================================== --- lib/ofed/librdmacm/Makefile (revision 335896) +++ lib/ofed/librdmacm/Makefile (working copy) @@ -8,6 +8,7 @@ SHLIB_MAJOR= 1 MK_PROFILE= no CFLAGS+= -I${_spath} +CSTD= gnu11 SRCS= \ acm.c \ If this works then we should probably mark OFED as a BROKEN_OPTION when building with ancient GCC for now as well. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Jul 26 18:29:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0611810569F4; Thu, 26 Jul 2018 18:29:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98F7773418; Thu, 26 Jul 2018 18:29:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 41A9310AFD2; Thu, 26 Jul 2018 14:29:11 -0400 (EDT) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) To: Mark Millard References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> <72081b02-cf23-82ec-32df-7f5793c35f57@FreeBSD.org> <003509F0-F2F4-4A43-82FE-3F6FC23D19D4@yahoo.com> <65b19cc4-eaf0-13ed-43e6-9f04a1f7f196@FreeBSD.org> <49BF6569-96A9-4104-BDE6-8BB94C0D9626@yahoo.com> <9251BE92-A8CE-45E3-B4BF-706E7219321A@yahoo.com> Cc: Dimitry Andric , Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current From: John Baldwin Message-ID: Date: Thu, 26 Jul 2018 11:29:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9251BE92-A8CE-45E3-B4BF-706E7219321A@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 26 Jul 2018 14:29:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 18:29:13 -0000 On 7/16/18 11:27 PM, Mark Millard wrote: > On 2018-Jul-1, at 6:34 AM, Mark Millard wrote: > >> My brain finally engaged for showing exactly what files are included >> for the gcc builds: the .meta files include that information explicitly >> (along with other files that are opened during the operation). >> >> amd64 is as I reported, just one header file from gcc: float.h . >> >> powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so >> is not including . Building without __ALTIVEC__ might >> be an error itself but would be a workaround for the altivec.h >> file name aliasing vs. search-path problem. >> >> . . . > > Going in a different direction, what of the unchanged Makefile.inc1 > code block: > > .if ${WANT_COMPILER_TYPE} == gcc || \ > (defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc) > # GCC requires -isystem and -L when using a cross-compiler. --sysroot > # won't set header path and -L is used to ensure the base library path > # is added before the port PREFIX library path. > CD2CFLAGS+= -isystem ${XDDESTDIR}/usr/include -L${XDDESTDIR}/usr/lib > # GCC requires -B to find /usr/lib/crti.o when using a cross-compiler > # combined with --sysroot. > CD2CFLAGS+= -B${XDDESTDIR}/usr/lib > # Force using libc++ for external GCC. > .if defined(X_COMPILER_TYPE) && \ > ${X_COMPILER_TYPE} == gcc && ${X_COMPILER_VERSION} >= 40800 > CD2CXXFLAGS+= -isystem ${XDDESTDIR}/usr/include/c++/v1 -std=c++11 \ > -nostdinc++ > .endif > .endif > > Why is that pair of -isystem uses that gives the old search order > okay? Or was the block just missed? (Similarly for other options > listed above.) Just missed. They should probably also be removed. > Note: Locally I've reverted the -r335782 changes in order for my use > of devel/*-gcc as cross compilers to work where they used to (hopefully: > still building), restoring the historical search order for the > directories for now. I finally got the approval 2 days ago to remove float.h from amd64-gcc so you shouldn't need this reverted anymore once the OFED thing is straightened out. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Jul 26 20:12:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 199C21058A26 for ; Thu, 26 Jul 2018 20:12:54 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A7F2076CBF for ; Thu, 26 Jul 2018 20:12:53 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6C68B1058A25; Thu, 26 Jul 2018 20:12:53 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B01E1058A24 for ; Thu, 26 Jul 2018 20:12:53 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C2B3C76CBE for ; Thu, 26 Jul 2018 20:12:52 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w6QKCpwv049006 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 26 Jul 2018 13:12:51 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me To: current From: Yuri Subject: panic in btsocks_l2cap_sockets_mtx @ ng_btsocket_2cap.c:2438 Message-ID: <80605275-56ed-8f2d-0a08-1e768aa9db2e@rawbw.com> Date: Thu, 26 Jul 2018 13:12:50 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 20:12:54 -0000 Got this panic while trying to register the bluetooth mouse. See the screenshot: https://imgur.com/a/RXZRIn9 r336271 Yuri From owner-freebsd-current@freebsd.org Fri Jul 27 01:45:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBA3E105D72A for ; Fri, 27 Jul 2018 01:45:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 09D0A7F89F for ; Fri, 27 Jul 2018 01:45:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: QEUZlFYVM1micge6KVJb3USJJAfXW3Fn3aQMPNv5VEo6cRbh.vq8nvCljoKB0TC h6Zujnlyj5XuyyBGxcp.ibE7VZ.fpmAxUqUIkHEWdkJRrsryMyIPN02rCzlL9Aa494R3xdk7hRTJ m3clhEGG7rpcA7ZzWQdmHJGEv.ygWEJpz4mBI.EXeWE3aeUJ_mMpFsaP4RuExmVf61NzDl3S1hdG 9hwVdSp9mSXYHouQpz3PXB.acwFg8cYIkmF.v.Ii9JLPDgIIUxvszSjH134tMtuTI4K8wwo_2FOU yb.KIoT3vQsJtFCHsLJxC3HcSQjJ2baG2yCwW4Pb3ZoCdfTFMt3MbZbVqRvCWdUBe5RpoveYwktd 1H7ItMpTCFcXePPirpiFBn7_6AuU09mtH5oDOsTbS1WXz1gVNMDgUCj74fyBXJGyDY6tVd5J92pc rIIXqhfKBOA08PNTVXXt7ENUWbxugJuRuwWTGpCukCwVAR43nJmdjfmdfqQSCnkCbk02wIu5GR3m ePAw6kS1KYw_NWhD5xitnJME6WRELD.ps2z42tKdG9XZwwmkAz3NCIf4fW23YCtRZ2dDLs3kj9LK IK7haaQ3XBPR9NbVzw20tybz5u01Fn9x5uA4rgG2R8SETjIaRsEFJ08umseQJYuDsWC47W9tSITo CB4mrqeHfW7XyltCZDxgRsygXh3kywnZmV_Ac6ZiCy8Feqcmzz6ZvnyV8A80C1CboadMXJubbj6I WtyZ4zA_80bacN_nJVPhfgr6ATye97NerstqsJtzBWPfneSJ84Yq2fkomRRMlwPgm_rMOZTjEcO4 nkRdaQbj0K7_U7jOJhsD2uOwXEeLjrkJqlO7qNAaKEookMEz2p3N1iNICnug54dzBhHTGD6HqV9I lj9deuMFENarQmdSrNsPoBUdkNVsFRJnDFP4uV7WiOAU8ihUThSpqviA.4aR9E_ZD7UV7jt3Q.CV QhOCu3Dx0EJkqinrvxU0ln264CwZsrndEz.H846NIUUEj1UvQT06zk9g_wbVIGbLzCJ6ray29yOs - Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 27 Jul 2018 01:45:17 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8d139c1c12f899e51158969ae772db9a; Fri, 27 Jul 2018 01:14:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> Date: Thu, 26 Jul 2018 18:14:48 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 01:45:25 -0000 On 2018-Jul-26, at 11:21 AM, John Baldwin wrote: > On 7/26/18 10:55 AM, Mark Millard wrote: >> . . . >=20 > Yes, but the -E from above was when compiled with external GCC and it = didn't change > _Atomic(int). Here's part of the source of bar.c: >=20 > #include > #include >=20 > struct foo { > _Atomic(int) one; > _Atomic int two; > atomic_int three; > }; >=20 > And here is what that became after -E: >=20 > # 4 "bar.c" > struct foo { > _Atomic(int) one; > _Atomic int two; > atomic_int three; > }; >=20 > So cdefs.h did not define _Atomic. >=20 > Ah, if I add '-std=3Dc99' then it does break. Code that wants to use > C11 atomics via should not be using -std=3Dc99. Try = this: >=20 > Index: lib/ofed/librdmacm/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/ofed/librdmacm/Makefile (revision 335896) > +++ lib/ofed/librdmacm/Makefile (working copy) > @@ -8,6 +8,7 @@ > SHLIB_MAJOR=3D 1 > MK_PROFILE=3D no > CFLAGS+=3D -I${_spath} > +CSTD=3D gnu11 >=20 > SRCS=3D \ > acm.c \ >=20 > If this works then we should probably mark OFED as a BROKEN_OPTION = when > building with ancient GCC for now as well. I've "unreverted" to set up a context for testing this. So far I'll I've done is to test that I can still reproduce the failure in my environment, same sort of error reports as ci.freebsd.org's FreeBSD-head-amd64-gcc . This is without your patch. But I've done this with gcc being given -v so that I've the exact = commands and search order and the like. It does show: -std=3Dgnu99 . I list the filemon data from the .meta as well, showing the exact mix of FreeBSD and gcc headers used. (I could also provide such for with the reverted Makefile.{inc1,libcompat} [so non-failing] build if you care.) For now I just report the failure *without your patch*: (I'll build again with your patch next.) . . . --- all_subdir_lib/ofed --- Building = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o --- acm.o --- Using built-in specs. COLLECT_GCC=3D/usr/local/bin/x86_64-unknown-freebsd12.0-gcc Target: x86_64-unknown-freebsd12.0 Configured with: = /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure = --target=3Dx86_64-unknown-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --enable-gnu-indirect-function = --without-headers --with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD = Ports Collection for amd64' --with-system-zlib = --with-gxx-include-dir=3D/usr/include/c++/v1/ --with-sysroot=3D/ = --with-as=3D/usr/local/bin/x86_64-unknown-freebsd12.0-as = --with-ld=3D/usr/local/bin/x86_64-unknown-freebsd12.0-ld = --enable-initfini-array --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ = --build=3Dx86_64-unknown-freebsd12.0 Thread model: posix gcc version 6.4.0 (FreeBSD Ports Collection for amd64)=20 COLLECT_GCC_OPTIONS=3D'-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' = '-O2' '-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wno-error=3Daddress' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dattributes' = '-Wno-error=3Dbool-compare' '-Wno-error=3Dcast-align' = '-Wno-error=3Dclobbered' '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' = '-Wno-error=3Dinline' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dstrict-aliasing' '-Wno-error=3Duninitialized' = '-Wno-error=3Dunused-but-set-variable' '-Wno-error=3Dunused-function' = '-Wno-error=3Dunused-value' '-Wno-error=3Dmisleading-indentation' = '-Wno-error=3Dnonnull-compare' '-Wno-error=3Dshift-negative-value' = '-Wno-error=3Dtautological-compare' '-Wno-error=3Dunused-const-variable' = '-v' '-c' '-o' 'acm.o' '-mtune=3Dgeneric' '-march=3Dx86-64' /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v = -I /usr/src/contrib/ofed/librdmacm -isysroot = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp = /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c = -mtune=3Dgeneric -march=3Dx86-64 -auxbase-strip acm.o -g -O2 = -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dmisleading-indentation -Wno-error=3Dnonnull-compare = -Wno-error=3Dshift-negative-value -Wno-error=3Dtautological-compare = -Wno-error=3Dunused-const-variable -std=3Dgnu99 -version = -fstack-protector-strong -o - | /usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I = /usr/src/contrib/ofed/librdmacm -o acm.o GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-un= known-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/contrib/ofed/librdmacm /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude End of search list. GNU assembler version 2.30 (x86_64-unknown-freebsd12.0) using BFD = version (GNU Binutils) 2.30 GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 Compiler executable checksum: 0b55436e4202650149cc2feb351f4e0e In file included from /usr/src/contrib/ofed/librdmacm/cma.h:43:0, from /usr/src/contrib/ofed/librdmacm/acm.c:42: /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': /usr/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer atomic_store(&lock->cnt, 0); ^ In file included from /usr/src/contrib/ofed/librdmacm/acm.c:42:0: /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': /usr/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct = *' is incompatible with argument 1 of '__atomic_fetch_add' if (atomic_fetch_add(&lock->cnt, 1) > 0) ^~ /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': /usr/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct = *' is incompatible with argument 1 of '__atomic_fetch_sub' if (atomic_fetch_sub(&lock->cnt, 1) > 1) ^~ *** [acm.o] Error code 1 make[6]: stopped in /usr/src/lib/ofed/librdmacm .ERROR_TARGET=3D'acm.o' = .ERROR_META_FILE=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd6= 4.amd64/lib/ofed/librdmacm/acm.o.meta' .MAKE.LEVEL=3D'6' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'/usr/local/bin/x86_64-unknown-freebsd12.0-gcc = --sysroot=3D/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/= tmp -B/usr/local/x86_64-unknown-freebsd12.0/bin/ -O2 -pipe = -I/usr/src/contrib/ofed/librdmacm -g -std=3Dgnu99 = -fstack-protector-strong -Wno-error=3Daddress -Wno-error=3Darray-bounds = -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align = -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra = -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses = -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function = -Wno-error=3Dunused-value -Wno-error=3Dmisleading-indentation = -Wno-error=3Dnonnull-compare -Wno-error=3Dshift-negative-value = -Wno-error=3Dtautological-compare -Wno-error=3Dunused-const-variable = -v -c /usr/src/contrib/ofed/librdmacm/acm.c -o acm.o; ;' .CURDIR=3D'/usr/src/lib/ofed/librdmacm' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/l= ib/ofed/librdmacm' .TARGETS=3D'all' = DESTDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/t= mp' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20180512' = PATH=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/= legacy/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.am= d64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/a= md64.amd64/tmp/legacy/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/sr= c/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/s= rc/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.amd64-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/ofed/librdmacm/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/lib/ofed/librdmacm/../Makefile.inc /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.symver.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk = /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/lib/ofed/librdmacm /usr/src/contrib/ofed/librdmacm = /usr/src/contrib/ofed/librdmacm/man' 1 error =46rom = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o.meta is the filemon data: -- filemon acquired metadata -- # filemon version 5 # Target pid 95011 # Start 1532652684.414953 V 5 E 95033 /bin/sh R 95033 /etc/libmap.conf R 95033 /var/run/ld-elf.so.hints R 95033 /lib/libedit.so.7 R 95033 /lib/libc.so.7 R 95033 /lib/libncursesw.so.8 F 95033 95034 E 95034 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc R 95034 /etc/libmap.conf R 95034 /var/run/ld-elf.so.hints R 95034 /usr/lib/libc++.so.1 R 95034 /lib/libcxxrt.so.1 R 95034 /lib/libm.so.5 R 95034 /lib/libc.so.7 R 95034 /lib/libgcc_s.so.1 F 95034 95035 E 95035 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 F 95034 95036 R 95035 /etc/libmap.conf R 95035 /var/run/ld-elf.so.hints R 95035 /usr/local/lib/libmpc.so.3 R 95035 /usr/local/lib/libmpfr.so.6 R 95035 /usr/local/lib/libgmp.so.10 R 95035 /lib/libz.so.6 R 95035 /usr/lib/libc++.so.1 R 95035 /lib/libcxxrt.so.1 R 95035 /lib/libm.so.5 R 95035 /lib/libc.so.7 R 95035 /lib/libgcc_s.so.1 R 95035 /dev/urandom R 95035 /usr/src/contrib/ofed/librdmacm/acm.c E 95036 /usr/local/bin/x86_64-unknown-freebsd12.0-as R 95036 /etc/libmap.conf R 95036 /var/run/ld-elf.so.hints R 95036 /lib/libc.so.7 R 95036 acm.o W 95036 acm.o R 95035 /usr/src/contrib/ofed/librdmacm/config.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdio.h R 95035 /usr/src/sys/sys/cdefs.h R 95035 /usr/src/sys/sys/_null.h R 95035 /usr/src/sys/sys/_types.h R 95035 /usr/src/sys/amd64/include/_types.h R 95035 /usr/src/sys/x86/include/_types.h R 95035 /usr/src/sys/amd64/include/_limits.h R 95035 /usr/src/sys/x86/include/_limits.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/inttypes.h R 95035 /usr/src/sys/amd64/include/_inttypes.h R 95035 /usr/src/sys/x86/include/_inttypes.h R 95035 /usr/src/sys/sys/stdint.h R 95035 /usr/src/sys/amd64/include/_stdint.h R 95035 /usr/src/sys/x86/include/_stdint.h R 95035 /usr/src/sys/amd64/include/_limits.h R 95035 /usr/src/sys/sys/_stdint.h R 95035 /usr/src/sys/sys/types.h R 95035 /usr/src/sys/amd64/include/endian.h R 95035 /usr/src/sys/x86/include/endian.h R 95035 /usr/src/sys/sys/_pthreadtypes.h R 95035 /usr/src/sys/sys/select.h R 95035 /usr/src/sys/sys/_sigset.h R 95035 /usr/src/sys/sys/_timeval.h R 95035 /usr/src/sys/sys/timespec.h R 95035 /usr/src/sys/sys/_timespec.h R 95035 /usr/src/sys/sys/socket.h R 95035 /usr/src/sys/sys/_iovec.h R 95035 /usr/src/sys/amd64/include/_align.h R 95035 /usr/src/sys/x86/include/_align.h R 95035 /usr/src/sys/sys/_sockaddr_storage.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/netdb.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/unistd.h R 95035 /usr/src/sys/sys/unistd.h R 95035 /usr/src/contrib/ofed/librdmacm/cma.h R 95035 /usr/src/contrib/ofed/librdmacm/config.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdlib.h R 95035 /usr/src/sys/sys/errno.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/endian.h R 95035 /usr/src/sys/sys/endian.h R 95035 /usr/src/sys/amd64/include/endian.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/semaphore.h R 95035 /usr/src/sys/sys/_umtx.h R 95035 /usr/src/sys/amd64/include/_limits.h R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/rdma/rdma_cma.h R 95035 /usr/src/sys/netinet/in.h R 95035 /usr/src/sys/amd64/include/endian.h R 95035 /usr/src/sys/netinet6/in6.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/verbs.h R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdint.h R 95035 /usr/src/sys/sys/stdint.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/pthread.h R 95035 /usr/src/sys/amd64/include/_limits.h R 95035 /usr/src/sys/amd64/include/_types.h R 95035 /usr/src/sys/sys/sched.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/time.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_time.h R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stddef.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/string.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/strings.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_strings.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_string.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/types.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/sa.h R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/ib.h R 95035 /usr/src/contrib/ofed/librdmacm/cma.h X 95036 0 0 X 95035 1 0 D 95034 acm.o X 95034 1 0 X 95033 1 0 # Stop 1532652684.494688 # Bye bye For reference the amd64-gcc is: # pkg info amd64-gcc amd64-gcc-6.4.0_1 Name : amd64-gcc Version : 6.4.0_1 Installed on : Sun Jul 15 09:15:38 2018 PDT Origin : devel/amd64-gcc Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : devel Licenses : GPLv3, GPLv3RLE Maintainer : kan@FreeBSD.org WWW : http://gcc.gnu.org/ Comment : Cross GNU Compiler Collection for amd64 Shared Libs required: libmpc.so.3 libgmp.so.10 libmpfr.so.6 Shared Libs provided: liblto_plugin.so.0 Annotations : FreeBSD_version: 1200069 repo_type : binary repository : custom Flat size : 338MiB Description : GCC, the GNU Compiler Collection supporting C and C++ for targetting = crossbuilding. WWW: http://gcc.gnu.org/ =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 27 03:57:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28E41105F98A for ; Fri, 27 Jul 2018 03:57:37 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 6394E82B98 for ; Fri, 27 Jul 2018 03:57:35 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from unknown (HELO leader.local) ([118.211.27.182]) by ipmail06.adl6.internode.on.net with ESMTP; 27 Jul 2018 13:22:24 +0930 To: FreeBSD Current From: Shane Ambler Subject: Changes to sysctl values Message-ID: Date: Fri, 27 Jul 2018 13:22:21 +0930 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 03:57:37 -0000 I use devel/py-sysctl in some scripts to get values, using a recent 12-current (r336728) I see at least two values that get a different value type than on 11-stable. Same version of python and port. I have 12-current running in a bhyve on an 11-stable host. Is there a recent change to sysctl calls that would cause this? or is this bhyve related? On 11-stable I get long int values that I expect Python 2.7.15 (default, Jun 8 2018, 08:54:38) [GCC 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final 326565)] on freebsd11 Type "help", "copyright", "credits" or "license" for more information. >>> sysctl.filter('vm.stats.vm.v_wire_count')[0].value 1061486L >>> sysctl.filter('vm.stats.vm.v_free_count')[0].value 77217L On 12-current I get the same sysctls as a bytearray Python 2.7.15 (default, Jul 26 2018, 10:32:28) [GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)] on freebsd12 Type "help", "copyright", "credits" or "license" for more information. >>> sysctl.filter('vm.stats.vm.v_wire_count')[0].value bytearray(b"\'R\x12\x00") >>> sysctl.filter('vm.stats.vm.v_free_count')[0].value bytearray(b'\x06\\\x08\x00') -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-current@freebsd.org Fri Jul 27 04:06:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 370E5105FC3C for ; Fri, 27 Jul 2018 04:06:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (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 95FC682FE2 for ; Fri, 27 Jul 2018 04:06:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: tahzE6gVM1nL.ynOCd90R.rZERblYRQJrCYxcNA4wdpAi_Sm55TTvgsRw4o_mlt 5E9aKUHhe8n9aOoc0KrSZuKPOoq2Q12ZaUbOsQyKbvJNau4OqJ17VijFFfi_jY.TInPpdG4CPzOa 6K5zxmCXMFR77fAUIa0yDEjmO1MRZwSI8X84DOlZtvx4OGBGGodp.qdLBp8CyTA5BgUcQts4kbDb y36g9XAlQFGcNdErQds63MjHPRgN2VOIlDJP6zW4djWhZ1.Ncc12OepwknrbP1JvS8UUwjzeLqPm 10TIKoNjGxqlj0lnQ1brjdT94WOZzWab_Tvj7UV6hVMpZNASoADI.k0tcNtiI1UQGiXw_DzGV5BK XRDCuNp8gTEeWgBKE8W072Zmvho5FqrSBF5zl_AhWE3TDFuIWBSPc7mzgr7n3EDGLR3YfoWAwreU Wf568LYbzJH9F3DWuhJ9VUXFpVk2RnpgL9HL.2J9SHdsy7i7VG8ZGYCYNEiR4QuiHjp_yCcLHYF9 Cr67XMkh7Zgo_tgRgzz4Dbv.jD2oFbiMIfxiRi1zXxavuuK0x1DZcgF.JwPphQiSkeSlJSSyHCKy 8O8BJCkk0n5z8UIIcBpanfx8jvPQhw5fmTrNQdYWBLIzqVldFR.8qLqw4uEJa3W4Y7D0uDYynNBv Rg30HOrABiyCKaWKFr2dTmCAR8hmHmlScUtUSE14mWRnw0o9h1GFwo29Arw1QK87rXd.yS43jGMG 3eVVm090IJ9qfgrtpIsKYewkDSCnIeenoUkmI7l4m2SlmYKuFYiLMfOt0sKvxEaNdn6FMGoUAaKB NiK85g6ppuZZDMLRMzQc0TS5nNVbDX5XqH58fTmK_8SK1PxpSOplFThTRNctasTxzS407bJ921zw 7cLLCMndaAvGqoB5ANq5e8EtopiQKSENsR17axH2z4u3oPAcJo0GK4zZo0Yhhh.arf0X9.sFmifh Df1sdNMoQbsgi0hyzgCIZQ_VBkrem0B22rzri6pWqNdXHGgwrPlOkBpv06RP_L6QxgCQY3gBKhr0 - Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Fri, 27 Jul 2018 04:06:33 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID def4ef59407bed37eea5528f6b1c8b8c; Fri, 27 Jul 2018 04:06:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> Date: Thu, 26 Jul 2018 21:06:29 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 04:06:36 -0000 On 2018-Jul-26, at 6:14 PM, Mark Millard wrote: > On 2018-Jul-26, at 11:21 AM, John Baldwin wrote: >=20 >> On 7/26/18 10:55 AM, Mark Millard wrote: >>> . . . >>=20 >> Yes, but the -E from above was when compiled with external GCC and it = didn't change >> _Atomic(int). Here's part of the source of bar.c: >>=20 >> #include >> #include >>=20 >> struct foo { >> _Atomic(int) one; >> _Atomic int two; >> atomic_int three; >> }; >>=20 >> And here is what that became after -E: >>=20 >> # 4 "bar.c" >> struct foo { >> _Atomic(int) one; >> _Atomic int two; >> atomic_int three; >> }; >>=20 >> So cdefs.h did not define _Atomic. >>=20 >> Ah, if I add '-std=3Dc99' then it does break. Code that wants to use >> C11 atomics via should not be using -std=3Dc99. Try = this: >>=20 >> Index: lib/ofed/librdmacm/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/ofed/librdmacm/Makefile (revision 335896) >> +++ lib/ofed/librdmacm/Makefile (working copy) >> @@ -8,6 +8,7 @@ >> SHLIB_MAJOR=3D 1 >> MK_PROFILE=3D no >> CFLAGS+=3D -I${_spath} >> +CSTD=3D gnu11 >>=20 >> SRCS=3D \ >> acm.c \ >>=20 >> If this works then we should probably mark OFED as a BROKEN_OPTION = when >> building with ancient GCC for now as well. >=20 > I've "unreverted" to set up a context for testing this. >=20 > So far I'll I've done is to test that I can still reproduce the = failure > in my environment, same sort of error reports as ci.freebsd.org's > FreeBSD-head-amd64-gcc . This is without your patch. >=20 > But I've done this with gcc being given -v so that I've the exact = commands > and search order and the like. It does show: -std=3Dgnu99 . I list = the > filemon data from the .meta as well, showing the exact mix of > FreeBSD and gcc headers used. (I could also provide such for with > the reverted Makefile.{inc1,libcompat} [so non-failing] build if you > care.) >=20 >=20 > For now I just report the failure *without your patch*: > (I'll build again with your patch next.) >=20 > . . . > --- all_subdir_lib/ofed --- > Building = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o > --- acm.o --- > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/x86_64-unknown-freebsd12.0-gcc > Target: x86_64-unknown-freebsd12.0 > Configured with: = /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure = --target=3Dx86_64-unknown-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --enable-gnu-indirect-function = --without-headers --with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD = Ports Collection for amd64' --with-system-zlib = --with-gxx-include-dir=3D/usr/include/c++/v1/ --with-sysroot=3D/ = --with-as=3D/usr/local/bin/x86_64-unknown-freebsd12.0-as = --with-ld=3D/usr/local/bin/x86_64-unknown-freebsd12.0-ld = --enable-initfini-array --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ = --build=3Dx86_64-unknown-freebsd12.0 > Thread model: posix > gcc version 6.4.0 (FreeBSD Ports Collection for amd64)=20 > COLLECT_GCC_OPTIONS=3D'-B' = '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2' '-pipe' '-I' = '/usr/src/contrib/ofed/librdmacm' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wno-error=3Daddress' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dattributes' = '-Wno-error=3Dbool-compare' '-Wno-error=3Dcast-align' = '-Wno-error=3Dclobbered' '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' = '-Wno-error=3Dinline' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dstrict-aliasing' '-Wno-error=3Duninitialized' = '-Wno-error=3Dunused-but-set-variable' '-Wno-error=3Dunused-function' = '-Wno-error=3Dunused-value' '-Wno-error=3Dmisleading-indentation' = '-Wno-error=3Dnonnull-compare' '-Wno-error=3Dshift-negative-value' = '-Wno-error=3Dtautological-compare' '-Wno-error=3Dunused-const-variable' = '-v' '-c' '-o' 'acm.o' '-mtune=3Dgeneric' '-march=3Dx86-64' > /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v = -I /usr/src/contrib/ofed/librdmacm -isysroot = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp = /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c = -mtune=3Dgeneric -march=3Dx86-64 -auxbase-strip acm.o -g -O2 = -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dmisleading-indentation -Wno-error=3Dnonnull-compare = -Wno-error=3Dshift-negative-value -Wno-error=3Dtautological-compare = -Wno-error=3Dunused-const-variable -std=3Dgnu99 -version = -fstack-protector-strong -o - | > /usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I = /usr/src/contrib/ofed/librdmacm -o acm.o > GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none > GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 > ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" > ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-un= known-freebsd12.0/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/contrib/ofed/librdmacm > /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include > = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude > End of search list. > GNU assembler version 2.30 (x86_64-unknown-freebsd12.0) using BFD = version (GNU Binutils) 2.30 > GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none > GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 > Compiler executable checksum: 0b55436e4202650149cc2feb351f4e0e > In file included from /usr/src/contrib/ofed/librdmacm/cma.h:43:0, > from /usr/src/contrib/ofed/librdmacm/acm.c:42: > /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': > /usr/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer > atomic_store(&lock->cnt, 0); > ^ > In file included from /usr/src/contrib/ofed/librdmacm/acm.c:42:0: > /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': > /usr/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' > if (atomic_fetch_add(&lock->cnt, 1) > 0) > ^~ > /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': > /usr/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' > if (atomic_fetch_sub(&lock->cnt, 1) > 1) > ^~ > *** [acm.o] Error code 1 >=20 > make[6]: stopped in /usr/src/lib/ofed/librdmacm > .ERROR_TARGET=3D'acm.o' > = .ERROR_META_FILE=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd6= 4.amd64/lib/ofed/librdmacm/acm.o.meta' > .MAKE.LEVEL=3D'6' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'/usr/local/bin/x86_64-unknown-freebsd12.0-gcc = --sysroot=3D/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/= tmp -B/usr/local/x86_64-unknown-freebsd12.0/bin/ -O2 -pipe = -I/usr/src/contrib/ofed/librdmacm -g -std=3Dgnu99 = -fstack-protector-strong -Wno-error=3Daddress -Wno-error=3Darray-bounds = -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align = -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra = -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses = -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function = -Wno-error=3Dunused-value -Wno-error=3Dmisleading-indentation = -Wno-error=3Dnonnull-compare -Wno-error=3Dshift-negative-value = -Wno-error=3Dtautological-compare -Wno-error=3Dunused-const-variable = -v -c /usr/src/contrib/ofed/librdmacm/acm.c -o acm.o; ;' > .CURDIR=3D'/usr/src/lib/ofed/librdmacm' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/l= ib/ofed/librdmacm' > .TARGETS=3D'all' > = DESTDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/t= mp' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'amd64' > MACHINE_ARCH=3D'amd64' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20180512' > = PATH=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/= legacy/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.am= d64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/a= md64.amd64/tmp/legacy/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/sr= c/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/s= rc/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > OBJTOP=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64'= > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.amd64-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/ofed/librdmacm/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/lib/ofed/librdmacm/../Makefile.inc /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.symver.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk = /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' > .PATH=3D'. /usr/src/lib/ofed/librdmacm /usr/src/contrib/ofed/librdmacm = /usr/src/contrib/ofed/librdmacm/man' > 1 error >=20 > =46rom = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o.meta > is the filemon data: >=20 > -- filemon acquired metadata -- > # filemon version 5 > # Target pid 95011 > # Start 1532652684.414953 > V 5 > E 95033 /bin/sh > R 95033 /etc/libmap.conf > R 95033 /var/run/ld-elf.so.hints > R 95033 /lib/libedit.so.7 > R 95033 /lib/libc.so.7 > R 95033 /lib/libncursesw.so.8 > F 95033 95034 > E 95034 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc > R 95034 /etc/libmap.conf > R 95034 /var/run/ld-elf.so.hints > R 95034 /usr/lib/libc++.so.1 > R 95034 /lib/libcxxrt.so.1 > R 95034 /lib/libm.so.5 > R 95034 /lib/libc.so.7 > R 95034 /lib/libgcc_s.so.1 > F 95034 95035 > E 95035 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 > F 95034 95036 > R 95035 /etc/libmap.conf > R 95035 /var/run/ld-elf.so.hints > R 95035 /usr/local/lib/libmpc.so.3 > R 95035 /usr/local/lib/libmpfr.so.6 > R 95035 /usr/local/lib/libgmp.so.10 > R 95035 /lib/libz.so.6 > R 95035 /usr/lib/libc++.so.1 > R 95035 /lib/libcxxrt.so.1 > R 95035 /lib/libm.so.5 > R 95035 /lib/libc.so.7 > R 95035 /lib/libgcc_s.so.1 > R 95035 /dev/urandom > R 95035 /usr/src/contrib/ofed/librdmacm/acm.c > E 95036 /usr/local/bin/x86_64-unknown-freebsd12.0-as > R 95036 /etc/libmap.conf > R 95036 /var/run/ld-elf.so.hints > R 95036 /lib/libc.so.7 > R 95036 acm.o > W 95036 acm.o > R 95035 /usr/src/contrib/ofed/librdmacm/config.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdio.h > R 95035 /usr/src/sys/sys/cdefs.h > R 95035 /usr/src/sys/sys/_null.h > R 95035 /usr/src/sys/sys/_types.h > R 95035 /usr/src/sys/amd64/include/_types.h > R 95035 /usr/src/sys/x86/include/_types.h > R 95035 /usr/src/sys/amd64/include/_limits.h > R 95035 /usr/src/sys/x86/include/_limits.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/inttypes.h > R 95035 /usr/src/sys/amd64/include/_inttypes.h > R 95035 /usr/src/sys/x86/include/_inttypes.h > R 95035 /usr/src/sys/sys/stdint.h > R 95035 /usr/src/sys/amd64/include/_stdint.h > R 95035 /usr/src/sys/x86/include/_stdint.h > R 95035 /usr/src/sys/amd64/include/_limits.h > R 95035 /usr/src/sys/sys/_stdint.h > R 95035 /usr/src/sys/sys/types.h > R 95035 /usr/src/sys/amd64/include/endian.h > R 95035 /usr/src/sys/x86/include/endian.h > R 95035 /usr/src/sys/sys/_pthreadtypes.h > R 95035 /usr/src/sys/sys/select.h > R 95035 /usr/src/sys/sys/_sigset.h > R 95035 /usr/src/sys/sys/_timeval.h > R 95035 /usr/src/sys/sys/timespec.h > R 95035 /usr/src/sys/sys/_timespec.h > R 95035 /usr/src/sys/sys/socket.h > R 95035 /usr/src/sys/sys/_iovec.h > R 95035 /usr/src/sys/amd64/include/_align.h > R 95035 /usr/src/sys/x86/include/_align.h > R 95035 /usr/src/sys/sys/_sockaddr_storage.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/netdb.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/unistd.h > R 95035 /usr/src/sys/sys/unistd.h > R 95035 /usr/src/contrib/ofed/librdmacm/cma.h > R 95035 /usr/src/contrib/ofed/librdmacm/config.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdlib.h > R 95035 /usr/src/sys/sys/errno.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/endian.h > R 95035 /usr/src/sys/sys/endian.h > R 95035 /usr/src/sys/amd64/include/endian.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/semaphore.h > R 95035 /usr/src/sys/sys/_umtx.h > R 95035 /usr/src/sys/amd64/include/_limits.h > R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/rdma/rdma_cma.h > R 95035 /usr/src/sys/netinet/in.h > R 95035 /usr/src/sys/amd64/include/endian.h > R 95035 /usr/src/sys/netinet6/in6.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/verbs.h > R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdint.h > R 95035 /usr/src/sys/sys/stdint.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/pthread.h > R 95035 /usr/src/sys/amd64/include/_limits.h > R 95035 /usr/src/sys/amd64/include/_types.h > R 95035 /usr/src/sys/sys/sched.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/time.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_time.h > R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stddef.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/string.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/strings.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_strings.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_string.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/types.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/sa.h > R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/ib.h > R 95035 /usr/src/contrib/ofed/librdmacm/cma.h > X 95036 0 0 > X 95035 1 0 > D 95034 acm.o > X 95034 1 0 > X 95033 1 0 > # Stop 1532652684.494688 > # Bye bye >=20 >=20 >=20 > For reference the amd64-gcc is: >=20 > # pkg info amd64-gcc > amd64-gcc-6.4.0_1 > Name : amd64-gcc > Version : 6.4.0_1 > Installed on : Sun Jul 15 09:15:38 2018 PDT > Origin : devel/amd64-gcc > Architecture : FreeBSD:12:amd64 > Prefix : /usr/local > Categories : devel > Licenses : GPLv3, GPLv3RLE > Maintainer : kan@FreeBSD.org > WWW : http://gcc.gnu.org/ > Comment : Cross GNU Compiler Collection for amd64 > Shared Libs required: > libmpc.so.3 > libgmp.so.10 > libmpfr.so.6 > Shared Libs provided: > liblto_plugin.so.0 > Annotations : > FreeBSD_version: 1200069 > repo_type : binary > repository : custom > Flat size : 338MiB > Description : > GCC, the GNU Compiler Collection supporting C and C++ for targetting = crossbuilding. >=20 > WWW: http://gcc.gnu.org/ With your patch it gets past that point of build failure. But my devel/amd64-gcc predates the removal of float.h from the installed devel/amd64-gcc so the following may not be as it would be in such a context: --- lib/msun__L --- /usr/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long = double format" #error "Unsupported long double format" ^~~~~ . . . --- lib/msun__L --- /usr/src/lib/msun/src/catrigl.c: In function 'casinhl': /usr/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared (first = use in this function) w =3D clog_for_large_values(z) + m_ln2; ^~~~~ /usr/src/lib/msun/src/catrigl.c:190:35: note: each undeclared identifier = is reported only once for each function it appears in /usr/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON' = undeclared (first use in this function) if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) ^~~~~~~~~~~~~~ /usr/src/lib/msun/src/catrigl.c: In function 'cacosl': /usr/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared (first = use in this function) ry =3D creall(w) + m_ln2; ^~~~~ /usr/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON' = undeclared (first use in this function) if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) ^~~~~~~~~~~~~~ In file included from /usr/src/lib/msun/src/catrigl.c:45:0: I can remove float.h and see what happens. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 27 05:37:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04423106154F for ; Fri, 27 Jul 2018 05:37:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (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 8565C858CC for ; Fri, 27 Jul 2018 05:37:52 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f177.google.com with SMTP id q9-v6so3264374ioj.8 for ; Thu, 26 Jul 2018 22:37:52 -0700 (PDT) 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=5rk9VA2k7OwGxfzsBAakHnO7jIx/DPT+et7oX5hh+9Y=; b=BkOAnPVZF3mvX0X9FirHaSibdSR3RaoOuW0upjpeOBinBwIJ2EdfDMYBfl5yTw7yQO wR8fUjJwpxfHpglLRE94cFmlGPfCfkhr0GpB/SO5gPI1UvqNXQ0o4oIPFoZ/aAQxVHFe LeYgq6vtVBz3Ou82WJOTrvDD7Z+FWcAXIkSkSzCbF0iuI5gE5lK2WltzYmW9MVaxblXb mkzeqnY0HnEPDP/RF2Lzk8lEvQvG+6Mfk/e3FFY0FtXK4FXWQXJ/hIfpUrsFbgphObX4 d+70ICqXBYmKy4jw5awcUKFpxpLol9GA5ncTiy7ykEYBslM17oltS6GW7sJKh3A1F3nc pkOQ== X-Gm-Message-State: AOUpUlEg1scJ0nWjz/Z3gCnnaRSAhPjf4l1Xz5URrXfQVv3maHPDFtRw QGepSqN7Uah9+LoqWWeL7/sEtlwE X-Google-Smtp-Source: AAOMgpdE1JE050XA+CCwACq3l3FBVVUABOyYYL7A8axxcDWR1j4GQrqy8uZyV91nOS0Phk/fy6fvJQ== X-Received: by 2002:a5e:950a:: with SMTP id r10-v6mr4067510ioj.241.1532668096463; Thu, 26 Jul 2018 22:08:16 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id m10-v6sm1022844ioj.22.2018.07.26.22.08.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 22:08:16 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id g141-v6so5808212ita.4 for ; Thu, 26 Jul 2018 22:08:15 -0700 (PDT) X-Received: by 2002:a24:a308:: with SMTP id p8-v6mr4268571ite.53.1532668095783; Thu, 26 Jul 2018 22:08:15 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 22:08:15 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Thu, 26 Jul 2018 22:08:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Changes to sysctl values To: Shane Ambler Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 05:37:53 -0000 On Thu, Jul 26, 2018 at 8:52 PM, Shane Ambler wrote: > I use devel/py-sysctl in some scripts to get values, using a recent > 12-current (r336728) I see at least two values that get a different > value type than on 11-stable. Same version of python and port. > ... Hi Shane, At some point, new sysctl types were added to the kernel, including CTLTYPE_U32. As part of the conversion to the counter(9) API, it seems the v_wire_count (and other vm.stats sysctls) changed to U32 type. py-sysctl lacks support for CTLTYPE_U32 and defaults to giving you a bytearray for unrecognized types. Best, Conrad From owner-freebsd-current@freebsd.org Fri Jul 27 05:51:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 095D810618C1 for ; Fri, 27 Jul 2018 05:51:56 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 649428646E; Fri, 27 Jul 2018 05:51:55 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LlYrb-1gIolP1uB5-00bLTG; Fri, 27 Jul 2018 07:46:28 +0200 Date: Fri, 27 Jul 2018 07:46:21 +0200 From: "O. Hartmann" To: Toomas Soome Cc: "O. Hartmann" , "Rodney W. Grimes" , freebsd-current , Allan Jude Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Om7LofMCCx9QUpoktdYZmGrSu5kxHQ8YwG6LpwVQDeP+qw8inPl Ojkt8sr+yetCgAA229hMzSZwTc+EnulR+4X4d07o2/03om5KQfOMZO4BTReox+cfE/hgmwV V92/GJeQNgyMpEDD8OwxEfmAUh60BAm3i+7WX5FQDR0ZE/lamxo4+KiIANGZwsdBIBH+zUk Oh/yM1Quu+OjCIdiEDOTQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:iTSKZafEMXQ=:2K9R/ro/BAIEGCZYMvmbDl inOOgT3X19uca4XOKbSZdHlcOsdp6jhdWq39dQQ3lRxh2EiDXEIKZ0Eqih8FWQXxpJu9DtJwY C16wbx0+CaJ7m+brXDv2jI/pGcurmUPZoYwtYixXYA+NCjyvjz9QgFbkL/X70k1w2pf2wBhGA yDB9QDezDFUnFD0Z3bl8e8DmmPHMbShzCKnfzZyr0RjvStukZshQ6+Y/WdeXunqWCy0E1PeAO emoTedHTjgwcyb5qP3mDNeM8ZOb4wsTbLtI1/P5DBmIaG+5kL22FE10Z4gKxXAsjVDo2ti0Aa b1xqkf2or+wOe6h0ygiOxrP6BDykmphcqznbtFZtvhmPlSOCpt6HnSdg9Ctuka7cw8kGJ9TAD bOYUHjbNmXEYdZ2WR+fqA/0dAVyyfGSaWRjmijD6FJgqRG0wp02jbQIYmXM/aabcK6ANodRjv u41leOF0cpTPzjRCvszGGQxHFtsepXc2Pb9bpdcOngqQa5IGWD5oclIyzhcIKgkHow55TeWv8 ddA7srizM54l8gfHWRKNC7q/x97fVko9SLpb8V6TRnroqXlngxlXuNyNAzzS0+aIacM9RYd/x gWfHWujk0Q8UP9yJBqTKJIpF7D4th3LzffSMUB5UDXAMWqAwD6jbFyRXy9tols0v3rsLg9OaM ZxxhawlSPFg8HWN4M65rwuhkEgznci+lh5a5CeRpms1PFbBjJfX7aI6RR0f74YSMqoUIXG7U9 INsL6WvkLVB5uhJ/BLeXEz098SDeWQ6Y1a4QFXyzVhUxeYwF02szvHkbai7QscikjXc1m84Dp AACrJZG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 05:51:56 -0000 On Thu, 26 Jul 2018 19:23:43 +0300 Toomas Soome wrote: (reply inline/at the end) > > On 26 Jul 2018, at 16:58, O. Hartmann wrote: > >=20 > > On Wed, 25 Jul 2018 07:30:32 -0700 (PDT) > > "Rodney W. Grimes" > > wrote:=20 > >>>> On 25 Jul 2018, at 12:10, O. Hartmann wrot= e: > >>>>=20 > >>>> On Wed, 25 Jul 2018 11:46:07 +0300 > >>>> Toomas Soome wrote: > >>>> =20 > >>>>>> On 25 Jul 2018, at 10:59, O. Hartmann wro= te: > >>>>>>=20 > >>>>>> On Tue, 24 Jul 2018 08:53:36 +0300 > >>>>>> Toomas Soome wrote: > >>>>>>=20 > >>>>>>=20 > >>>>>> Hello Toomas Soome, > >>>>>>=20 > >>>>>> I CC Allan Jude since I discovered something weird today regardin= g the > >>>>>> UEFI boot capabilities of USB flash devices and SSDs. See below. > >>>>>> =20 > >>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann w= rote: > >>>>>>>>=20 > >>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300 > >>>>>>>> Toomas Soome wrote: > >>>>>>>> =20 > >>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann > >>>>>>>>>> wrote: > >>>>>>>>>>=20 > >>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 > >>>>>>>>>> Toomas Soome > wrote: > >>>>>>>>>> =20 > >>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>>>>>>>>>> > wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>>>>>>> Hash: SHA512 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 > >>>>>>>>>>>> Toomas Soome > >>>>>>>>>>>> >> schrieb: = =20 > >>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot proble= ms on > >>>>>>>>>>>>>> GPT drives where the first partition begins at block 40 of= the > >>>>>>>>>>>>>> hdd/ssd. > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> I have two host in private use based on an > >>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBrid= ge, > >>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the lates > >>>>>>>>>>>>>> official available AMI firmware revision, dating to 2013. = This > >>>>>>>>>>>>>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the= Z77 > >>>>>>>>>>>>>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA revi= sion > >>>>>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I di= dn't > >>>>>>>>>>>>>> test that. But please read. > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> The third box I realised this problem is a brand new Fujit= su > >>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for > >>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525). > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdin= stall > >>>>>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned de= vice > >>>>>>>>>>>>>> fails. The ASRock boards jump immediately into the firmwar= e, > >>>>>>>>>>>>>> the Fujitsu offers some kind of CPU/Memory/HDD test facili= ty. > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI = boot > >>>>>>>>>>>>>> only is implied, the MBR partitioned FreeBSD installation = USB > >>>>>>>>>>>>>> flash device does boot in UEFI! I guess I can assume this = when > >>>>>>>>>>>>>> the well known clumsy 80x25 char console suddenly gets bri= ght > >>>>>>>>>>>>>> and shiny with a much higher resoltion as long the GPU sup= ports > >>>>>>>>>>>>>> EFI GOP. Looking with gpart at the USB flash drives reveals > >>>>>>>>>>>>>> that the EFI partition starts at block 1 of the device and= the > >>>>>>>>>>>>>> device has a MBR layout. I haven't found a way to force th= e GPT > >>>>>>>>>>>>>> scheme, when initialised via gpart, to let the partitions = start > >>>>>>>>>>>>>> at block 1. This might be a naiv thinking, so please be pa= tient > >>>>>>>>>>>>>> with me. > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> I do not know whether this is a well-known issue. On the A= SRock > >>>>>>>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with = UEFI > >>>>>>>>>>>>>> and that worked - FreeBSD not. I gave up on that that time. > >>>>>>>>>>>>>> Now, having the very same issues with a new Fujitsu system, > >>>>>>>>>>>>>> leaves me with the impression that FreeBSD's UEFI > >>>>>>>>>>>>>> implementation might have problems I'm not aware of. > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> Can someone shed some light onto this?=20 > >>>>>>>>>>>>>> =20 > >>>>>>>>>>>>>=20 > >>>>>>>>>>>>> The first thing to check is if the secure boot is disabled.= We > >>>>>>>>>>>>> do not support secure boot at all at this time. = =20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Secure boot is in every scenario disabled! > >>>>>>>>>>>> =20 > >>>>>>>>>>>>>=20 > >>>>>>>>>>>>> If you have efi or bios version running - you can check from > >>>>>>>>>>>>> either console variable value (it can have efi or vidconsol= e or > >>>>>>>>>>>>> comconsole) or better yet, see if efi-version is set (show > >>>>>>>>>>>>> efi-version) - if efi-version is not set, it is BIOS loader > >>>>>>>>>>>>> running. Another indirect way is to see lsdev -v, with devi= ce > >>>>>>>>>>>>> paths present, it is uefi:) =20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> What are you talking about? > >>>>>>>>>>>> What is the point of entry - running system, loader? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> sysct machdep.bootmethod: BIOS > >>>>>>>>>>>>=20 > >>>>>>>>>>>> This makes me quite sure that the system has booted via BIOS= - as > >>>>>>>>>>>> I'm sure since I've checked that many times. UEFI doesn't wo= rk on > >>>>>>>>>>>> those systems with FreeBSD. I'm not sure antmore, but I tried > >>>>>>>>>>>> also Windows 7 on those mainboards booting via UEFI - and I = might > >>>>>>>>>>>> recall that they failed also. I also recall that there were > >>>>>>>>>>>> issues with earlier UEFI versions regarding booting only Win= dows > >>>>>>>>>>>> 8/8.1 - and nothing else, but the fact that Linux worked con= fuses > >>>>>>>>>>>> me a bit. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> If this ASRock crap (never ever again this brand!) doesn't w= ork > >>>>>>>>>>>> at all - who cares, I intend to purchase new server grade > >>>>>>>>>>>> hardware. But the more puzzling issue is with the Fujitsu, w= hich > >>>>>>>>>>>> I consider serious and from the behaviour the Fujitsu failure > >>>>>>>>>>>> looks exactly like the ASRock - Windows 7 works, RedHat 7.5 > >>>>>>>>>>>> works (I assume I can trust the Firmware settings when I dis= able > >>>>>>>>>>>> CSM support, that the Firmware will only EFI/UEFI capable > >>>>>>>>>>>> loader? Or is there a ghosty override somwhere to be expecte= d?). > >>>>>>>>>>>> Also on ASRock disabling CSM should ensure not booting a > >>>>>>>>>>>> dual-bootstrap-capable system. This said, on the recent Fuji= tsu, > >>>>>>>>>>>> it seems to boil down to a FreeBSD UEFI-firmware interaction > >>>>>>>>>>>> problem, while the ASRock is still under suspicion to be bro= ken > >>>>>>>>>>>> by design. =20 > >>>>>>>>>>>>>=20 > >>>>>>>>>>>>> GPT partitions can never start from disk absolute sector 1;= this > >>>>>>>>>>>>> is because at sector 0 there is MBR (for compatibility), se= ctor > >>>>>>>>>>>>> 1 is GPT table and then sectors 2-33 have GPT partition tab= le > >>>>>>>>>>>>> entries, so the first possible data sector is 34 (absolute = 34). > >>>>>>>>>>>>> Thats assuming 512B sectors. For details see UEFI 2.7 Chapt= er > >>>>>>>>>>>>> 5.3.1 page 131. =20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks for the explanation. That implies the installer did r= ight, > >>>>>>>>>>>> gpart did also right and therefore there must be an issue wi= th > >>>>>>>>>>>> the stuff located within the EFI partition? =20 > >>>>>>>>>>>=20 > >>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we rea= ch > >>>>>>>>>>> BIOS loader at all or not - that is, if the BIOS bootstrap is > >>>>>>>>>>> actually caring to read the MBR code and start it, since once= the > >>>>>>>>>>> MBR code is started, it is all about our code. =20 > >>>>>>>>>>=20 > >>>>>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM= ? or > >>>>>>>>>> do you mean that specific portion of the UEFI firmware, which = looks > >>>>>>>>>> for the proper UEFI partition? > >>>>>>>>>> =20 > >>>>>>>>>=20 > >>>>>>>>> BIOS as either native or CSM. Note that from boot code point of= view > >>>>>>>>> the CSM boot *is* BIOS boot, we have no access to UEFI features. > >>>>>>>>> =20 > >>>>>>>>>>=20 > >>>>>>>>>> The boxes in question, most notably the more recent Fujitsu Es= primo > >>>>>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms of= what > >>>>>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is swit= ched > >>>>>>>>>> off in the firmware. Again: GPT partition scheme. > >>>>>>>>>>=20 > >>>>>>>>>> The system boots properly if a second partition of type > >>>>>>>>>> "freebsd-boot" is applied and bootcode is properly applied via > >>>>>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" (ada= 0 is > >>>>>>>>>> the device). =20 > >>>>>>>>>>>=20 > >>>>>>>>>>> btw, you can try to validate the installed boot blocks by usi= ng > >>>>>>>>>>> recent enough loader (usb or iso) and then you can use from OK > >>>>>>>>>>> prompt: =20 > >>>>>>>>>>=20 > >>>>>>>>>> lsdev provides me with the follwoing informations (CSM enabled= ): > >>>>>>>>>>=20 > >>>>>>>>>> OK lsdev > >>>>>>>>>> disk devices: > >>>>>>>>>> disk0: BIOS DRIVE C ... > >>>>>>>>>>=20 > >>>>>>>>>> disk0p1: EFI > >>>>>>>>>> disk0p2: FreeBSD BOOT > >>>>>>>>>> disk0p3: FreeBSD SWAP > >>>>>>>>>> disk0p4: FreeBSD ZFS > >>>>>>>>>> zfs devices: > >>>>>>>>>> zfs:zroot > >>>>>>>>>>=20 > >>>>>>>>>> OK chain disk0 > >>>>>>>>>> open failed (so for disk0p{1-4}. > >>>>>>>>>>=20 > >>>>>>>>>> OK chain zroot > >>>>>>>>>> failed to read disk (just for completeness) =20 > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> chain command does use only device name (such as disk0: or > >>>>>>>>> disk0p2: ), but not zfs pool as device. I just found I haven?t > >>>>>>>>> ported the code to read the file. =20 > >>>>>>>>=20 > >>>>>>>> ?? > >>>>>>>> =20 > >>>>>>>>>=20 > >>>>>>>>> the point for chain command test is to see if the normal read a= nd > >>>>>>>>> execute would work, so in your case please try: > >>>>>>>>>=20 > >>>>>>>>> chain disk0: =20 > >>>>>>>>=20 > >>>>>>>> As stated above, I did so, and the result is also mentioned abov= e, I > >>>>>>>> always get "open failed". > >>>>>>>> This is the same for=20 > >>>>>>>>=20 > >>>>>>>> chain disk0 > >>>>>>>> chain disk0p1 > >>>>>>>> chain disk0p2 > >>>>>>>> chain disk0p3 > >>>>>>>> chain disk0p4 > >>>>>>>>=20 > >>>>>>>> as already said. CSM is enabled in this case. =20 > >>>>>>>=20 > >>>>>>> sigh? chain command does take device as argument, device must alw= ays > >>>>>>> end with colon?. in this case, the devil is in details:) as I wro= te > >>>>>>> above, the command should be: > >>>>>>>=20 > >>>>>>> chain disk0: > >>>>>>>=20 > >>>>>>> The disk0p1: etc will only work when partition boot code was inst= alled > >>>>>>> (which you most likely do not have - the only possible candidate = could > >>>>>>> be FreeBSD ZFS partition). =20 > >>>>>>=20 > >>>>>> The command "chain disk0:" works as expected (CSM enabled, GPT > >>>>>> partition scheme, but with PMBR bootblock installed and freebsd-bo= ot > >>>>>> partition conatining gptzfsboot installed. > >>>>>>=20 > >>>>>> =20 > >>>>>>> =20 > >>>>>>>> =20 > >>>>>>>>>=20 > >>>>>>>>> to read pmbr (512B) and execute it. The expected outcome would = be > >>>>>>>>> that pmbr boot code would browse the GPT, read stage1 from disk= 0p2: > >>>>>>>>> and execute it; stage1 would detect FreeBSD ZFS from disk0p4: a= nd > >>>>>>>>> load and execute /boot/loader. If that will happen, it means the > >>>>>>>>> boot code in our stages is just fine, but the bios (CSM) does n= ot > >>>>>>>>> load pmbr?. if thats true, it would mean that you either need = to > >>>>>>>>> use UEFI boot or need to have some hack to fool the BIOS or jus= t not > >>>>>>>>> use GPT on that machine with CSM. =20 > >>>>>>>>=20 > >>>>>>>> To make it clear here: The only way to boot this box is using CS= M (as > >>>>>>>> it is the same with the ASRock boards mentioned earlier). But my > >>>>>>>> intention is to disable CSM and use a GPT/UEFI environment only!= And > >>>>>>>> GPT/UEFI doesn't work with FreeBSD, neither with 12-CURRENT, nor > >>>>>>>> 11.2-RELENG. > >>>>>>>>=20 > >>>>>>>> It would be nice if this could be fixed. I'm more interested in = the > >>>>>>>> fix on the recent Fujitsu device than the outdated ASRock crap, = but > >>>>>>>> if the fix for the Fujitsu Firmware could fix older issues as a > >>>>>>>> byproduct, I'd appreciate that. > >>>>>>>>=20 > >>>>>>>> Kind regards, > >>>>>>>> =20 > >>>>>>>=20 > >>>>>>> ok, somehow I have lost that part of the discussion. Well, you wr= ote > >>>>>>> that the UEFI boot fails when the first partition starts from sec= tor > >>>>>>> 40 - does it mean you have boot when the partition will start from > >>>>>>> some other sector? I think, there is something else going on. = =20 > >>>>>>=20 > >>>>>> Well, I simply try to describe what I "see" to make things > >>>>>> disambiguous. I'm not familiar with the deeper insights of disk la= youts > >>>>>> on a binary level. So, you explained to me the reason, why ESP (EGI > >>>>>> partition) starts at block 40. I compared that to the FreeBSD USB = flash > >>>>>> image FreeBSD provides, but this is another story since the image = uses > >>>>>> MBR scheme as I figured out. > >>>>>>=20 > >>>>>> =20 > >>>>>>>=20 > >>>>>>> What you can do is to see if that firmware will offer you EFI she= ll > >>>>>>> option, from there you can try to start the bootx64.efi manually = and > >>>>>>> see what error you will get. However, the number 1 cause for fail= ing > >>>>>>> to start the bootloader in UEFI is secure boot - we do not suppor= t it > >>>>>>> and secure boot must be switched off.=20 > >>>>>>>=20 > >>>>>>> However, they seem to claim "The Secure Boot option is available = in > >>>>>>> the UEFI/BIOS of most if not all ASRock boards. It is disabled by > >>>>>>> default.?=20 > >>>>>>>=20 > >>>>>>> Still suggest to double check if thats really the case. Also, if = the > >>>>>>> bootx64.efi start will fail and no messages are appearing on scre= en, > >>>>>>> then either there is something in firmware logs or you could get = them > >>>>>>> from trying to start bootx64.efi from UEFI shell. =20 > >>>>>>=20 > >>>>>> Since I'm with this problem since 2014 and try from time to time, = be > >>>>>> ausred that I tried every possible permutationof all reasonable > >>>>>> options, even those nonsense, to get rid of that problem. > >>>>>>=20 > >>>>>> I never had any problems with any other UEFI capable server/workst= ation > >>>>>> firmware so far booting FreeBSD off in UEFI-native (GPT partition > >>>>>> scheme, CSM disabled) so far - until now, when I ran into this Fuj= itsu > >>>>>> ESPRIMO Q956 with the most recent firmware (as of lat week, week 2= 9 of > >>>>>> 2018) having the very same problems.=20 > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> I figured out something strange on the Fujitsu - and that is the s= ame > >>>>>> with the ASRock boards. > >>>>>>=20 > >>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a very sm= all > >>>>>> appliance, but nevertheless, the USB flash device is booted on Fuj= itsu > >>>>>> servers with UEFI-only configurations. I assume at this point that > >>>>>> disabling on the most recent Fujitsu firmwares on reasonable "new" > >>>>>> hardware (not older than three years) will disable any(!) legacy B= IOS > >>>>>> capabilities. The same is assumed for the Fujitus ESPRIMO Q956. I = can > >>>>>> not speak for the ASRock A77 Pro4/m boards mentioned above/earlier, > >>>>>> they are from 2012/2013 and "quite old". > >>>>>>=20 > >>>>>> The NanoBSD image of ours doesn't have a "freebsd-boot" partition.= The > >>>>>> partition scheme of the flash device is GPT. The layout looks like > >>>>>> this: > >>>>>>=20 > >>>>>> gpart show -l da4 =20 > >>>>>> =3D> 40 15425456 da4 GPT (7.4G) =20 > >>>>>> 40 2000 1 efiboot0 (1.0M) > >>>>>> 2040 1453584 3 disk1a (710M) > >>>>>> 1455624 4096 5 disk3 (2.0M) > >>>>>> 1459720 13965776 - free - (6.7G) > >>>>>>=20 > >>>>>> I created the flash with md, gpart and dd straightforward, efiboot= 0 is > >>>>>> the ESP partition and its format/content is created via dd > >>>>>> if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is very s= imple. > >>>>>>=20 > >>>>>> This USB flash device boots(!) successfully (UEFI!) on both the AS= Rock > >>>>>> boards and the Esprimo Q956! > >>>>>>=20 > >>>>>> But any SSD prepared the same way doesn't. Why?=20 > >>>>>>=20 > >>>>>> On the ASRock, I recall having fiddled around with HDD also for a = while > >>>>>> conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD - I > >>>>>> can't remember.=20 > >>>>>>=20 > >>>>>> In the lack of proper hardware I'm unable to check whether USB-att= ached > >>>>>> HDD or SSD will boot or HDD will boot (just in case the local SATA= has > >>>>>> problems booting UEFI and USB not). > >>>>>>=20 > >>>>>> Kind regards, > >>>>>>=20 > >>>>>> Oliver=20 > >>>>>> =20 > >>>>>=20 > >>>>> Am. well. I think the suggestion to test out FAT32 is still good on= e to > >>>>> test. This is because it is known that some vendors do not support > >>>>> booting FAT12/FAT16 from HDD (the likely reason is that UEFI > >>>>> specification does not tell which FAT must be supported, and only h= int > >>>>> about FAT12/FAT16 in context of removable devices). =20 > >>>>=20 > >>>> I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO Q956.= It > >>>> took me a time to circumvent the installer and I had to install the > >>>> system manually. In that strain, I also "tried" to establish the ESP= with > >>>> FAT32, as Allen Jude suggested earlier. I didn't find any ad hoc hel= p how > >>>> to find out the format (FAT12/16/32) of the ESP, so I assume when us= ing > >>>> 12-CURRENT's or 11.2-RELENG's installer with AUTO-ZFS and GPT (UEFI) > >>>> (only!) the resulting ESP is FAT12 or FAT16 (300mb by default). I al= so > >>>> assume, that when dd'ing the /boo/boot1.efifat image to a partition,= the > >>>> format is FAT, but not FAT32. Therefore, I refomatted the manually > >>>> created ESP (using "gpart add -t efi ...") using "newfs_msdos -F 32 = -b > >>>> xxx ...". I had to fiddle around a bit with option -b to fit in a pr= oper > >>>> format to meet a 512mb ESP - I'm not sure whether this is the proper > >>>> option to deal with. When using the default and only -F32, the size = of > >>>> the partition has to be 4G at least I assume. Having done that, I co= pied > >>>> the the content of boot1.efifat (mdconfig -t vnode ..., I guess we k= now > >>>> the drill ...) to the newly formatted ESP to /boot/efi/ ... > >>>>=20 > >>>> Having so far no knowledge of how to asure that the created ESP is F= AT32, > >>>> I assume it is FAT32. > >>>>=20 > >>>> The result is negative on the ESPRIMO Q956. When disabling the CSM, = the > >>>> box is not willing to boot from SSD with the ESP prepared as decribe= d. > >>>> So, a chance that this might still be due to a misconfiguration lies= now > >>>> within the -b option of newfs_msdos - if the -b option is assumed the > >>>> proper option? > >>>>=20 > >>>> At the moment, the ESP of the Esprimo is subject to changes, if you = wish, > >>>> but not in size, since it is limited to 512mb. > >>>>=20 > >>>> Thanks and kind regards, > >>>>=20 > >>>> Oliver =20 > >>>=20 > >>> Yea, i was hoping fstyp command would report the FAT type, but it doe= s not > >>> (request for feature?:) =20 > >>=20 > >> FYI, the file(1) command is very good at disecting a disk image to tell > >> you what the MBR looks like, and at looking at partitions if pointed at > >> them with the -s option. It should be able to detect FAT12/16/32. > >>=20 > >> root@x230a:/home/ISO/x # file -s /dev/md2s1 > >> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 ", > >> root entries 512, sectors 1600 (volumes <=3D32 MB) , sectors/FAT 5, > >> sectors/track 63, heads 1, serial number 0xbd4111ee, label: "EFISYS = ", > >> FAT (12 bit), followed by FAT > >> =20 > >>>=20 > >>> However, the more annoying idea would be to install some OS which will > >>> boot with UEFI on this machine, then copy boot1.efi from freebsd to it > >>> (the default program the UEFI will load is ESP:EFI/boot/bootx64.efi = in > >>> case of UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, we do > >>> not support EFI32. > >>>=20 > >>> note that boot1.efi alone will not do much but printing on screen how= it > >>> will search for freebsd, but for the purpose of the test it would suf= fice > >>> - that would give us confirmed working ESP file system (since the oth= er os > >>> would be able to boot) and then we can confirm if boot1.efi itself is > >>> OK. =20 > >> =20 > >=20 > > Some new results. > > I installed RedHat 7.5 and inestigated the ESP. > >=20 > > - The ESP starts at block 2048, while FreeBSD's ESP starts at block 40. > > - size is both 200mb if installed automatically. I forgit to investigat= e the > > FAT format, but this might be unnecessary as shown further in this pos= t. > > - RedHat's ESP contains ~ 10 MB of data in two > > folders, /efi/boot, /efi/redhat. copying FreeBSD's BOOTX64.efi over > > RedHat's doesn't change anything, also renaming /efi/boot/fbx64.efi of > > RedHat's installation. But renaming /efi/redhat renders RedHat to fail = the > > boot process on the Fujitsu with the signs of the built-in testprogram = as > > reported. > >=20 > > I took the liberty and installed 11.2-RELENG again, ZFS only, UEFI boot= only > > (CSM in firmware disabled, but there is still a gptzfsboot-prepared > > partition for later use, just for the record). Booting UEFI-only fails = as > > reported. On this installation I copied the RedHat ESP completely into > > FreeBSD's ESP, renamed /efi/boot/BOOTX64.efi to /efi/boot/BOOTX64.efi.rh > > and copied FreeBSD's BOOTX64.efi to /efi/boot.=20 > > The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, that > > the /efi/redhat folder of the ESP is important, if renamed, the whole > > process dies as I reported earlier. > >=20 > > Still unanswered is the question: why is a NanoBSD prepared UEFI-only U= SB > > flash booting with CSM disabled (so asumingly UEFI only then) on both > > ASRock and Fujitsu (as described in more detail initially and earlier), > > while SSDs fail? Is there a difference? Since FreeBSD boots in UEFI mode > > from USB flash prepared as described (straight forward, 800k ESP starti= ng > > at block 40, the boot1.efifat image dd'ed onto the partition, UFS parti= tion > > following, no freebsd-boot partition or MBR/PMBR bootcode applied ever!= ), I > > think BOOTX64.EFI is technically all right. There must be then an issue > > with the SATA/SSD/HDD boot pathway. > >=20 > > Hope I could provide some more details, sorry if it sounds confusing or= way > > too long, but I try to descibe the situation as thorough as possible. > > =20 >=20 > OK, this is already good hint. The thing with ESP is that there is =E2=80= =9Cdefault=E2=80=9D > file system tree: EFI/BOOT/BOOT.EFI, this is noted as default for > *removable* media, fortunately it is usable for hard disks as well, or at > least in most cases. >=20 > Now, for non-removable media, the UEFI does provide boot manager interfac= e to > define boot entries, and the fact that renaming efi/redhad directory did > break the redhat boot, is very loud hint. And this means, this system is > probably ignoring efi/boot tree on non-removable media and is expecting t= he > boot manager entry to be created instead. This inplication I'd confirm for the recent Fujitsu ESPRIMO Q956 firmware (= not tested on ASRock Z77-Pro4 firmware). >=20 > UEFI boot manager can be configured /usually/ manually via firmware menu,= or > by application, such as efibootmgr. The normal approach is to create > efi/ directory and to copy the application there, then create= the > boot manager configuration. >=20 > See UEFI specification v2.7, chapter 3 Boot Manager, page 79. >=20 > What is different in FreeBSD case is that the whole interface to program = the > UEFI Boot Manager is currently being developed, so either it has to be do= ne > manually or from some other OS (see https://wiki.gentoo.org/wiki/Efibootm= gr > for example, first hit from > google:D). Well, thanks for this important hint! FreeBSD 12-CURRENT's and FreeBSD 11.2-RELENG's USB flash devices are capable of booting off on Fujitsu's ESP= RIMO and ASRock's boards. As a note: after "kldload efirt.ko" I was able to use = the already in FreeBSD present toolset efibootmgr(8) and sibblings (the tools do not do anything useful when booted non-UEFI). Mounting the ESP of the harddrive (in my case, ada0p1) to /mnt and following the steps in the examples and having created /efi/freebsd/BOOTx64.efi as recommended by copy from /efi/boot, let me create a proper boot variable. To make things sure, I also applied "efibootmgr -a VARIABLENAME". And ... it worked! Yes, it worked! The ESP is FAT32 formatted, I do not know whether this will also work with FAT12/16, I should test this case, too. There is a bug in the manpage of efibootmg(8). It does not explain the opti= ons -d and -p, although they could be "implied" by reading carefully. There is = now a PR at=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230080 for this issue. So, it's apity that the handbook has no note I could easily find on this;=20 Thank you very much for your patience and help! Kind regards, Oliver >=20 > rgds, > toomas >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Jul 27 05:54:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A5071061B2B for ; Fri, 27 Jul 2018 05:54:54 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 AAF658669C; Fri, 27 Jul 2018 05:54:53 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCI00P00G6T4C00@st13p35im-asmtp001.me.com>; Fri, 27 Jul 2018 05:54:52 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCI00CBUGFD1M10@st13p35im-asmtp001.me.com>; Fri, 27 Jul 2018 05:54:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-27_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=7 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807270059 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations From: Toomas Soome In-reply-to: <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> Date: Fri, 27 Jul 2018 08:54:48 +0300 Cc: "Rodney W. Grimes" , freebsd-current , Allan Jude Content-transfer-encoding: quoted-printable Message-id: <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 05:54:54 -0000 > On 27 Jul 2018, at 08:46, O. Hartmann wrote: >=20 > On Thu, 26 Jul 2018 19:23:43 +0300 > Toomas Soome wrote: >=20 > (reply inline/at the end) >=20 >=20 >>> On 26 Jul 2018, at 16:58, O. Hartmann = wrote: >>>=20 >>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT) >>> "Rodney W. Grimes" >> > wrote:=20 >>>>>> On 25 Jul 2018, at 12:10, O. Hartmann = wrote: >>>>>>=20 >>>>>> On Wed, 25 Jul 2018 11:46:07 +0300 >>>>>> Toomas Soome wrote: >>>>>>=20 >>>>>>>> On 25 Jul 2018, at 10:59, O. Hartmann = wrote: >>>>>>>>=20 >>>>>>>> On Tue, 24 Jul 2018 08:53:36 +0300 >>>>>>>> Toomas Soome wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hello Toomas Soome, >>>>>>>>=20 >>>>>>>> I CC Allan Jude since I discovered something weird today = regarding the >>>>>>>> UEFI boot capabilities of USB flash devices and SSDs. See = below. >>>>>>>>=20 >>>>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann = wrote: >>>>>>>>>>=20 >>>>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300 >>>>>>>>>> Toomas Soome wrote: >>>>>>>>>>=20 >>>>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann = >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 >>>>>>>>>>>> Toomas Soome > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann = >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>>>>>> Hash: SHA512 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 >>>>>>>>>>>>>> Toomas Soome >>>>>>>>>>>>>> >> schrieb: = =20 >>>>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann = >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot = problems on >>>>>>>>>>>>>>>> GPT drives where the first partition begins at block 40 = of the >>>>>>>>>>>>>>>> hdd/ssd. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I have two host in private use based on an >>>>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard = (IvyBridge, >>>>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the = lates >>>>>>>>>>>>>>>> official available AMI firmware revision, dating to = 2013. This >>>>>>>>>>>>>>>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for = the Z77 >>>>>>>>>>>>>>>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA = revision >>>>>>>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I = didn't >>>>>>>>>>>>>>>> test that. But please read. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The third box I realised this problem is a brand new = Fujitsu >>>>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 = for >>>>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525). >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via = bsdinstall >>>>>>>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned = device >>>>>>>>>>>>>>>> fails. The ASRock boards jump immediately into the = firmware, >>>>>>>>>>>>>>>> the Fujitsu offers some kind of CPU/Memory/HDD test = facility. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> If on both type of vendor/boards CSM is disabled and = UEFI boot >>>>>>>>>>>>>>>> only is implied, the MBR partitioned FreeBSD = installation USB >>>>>>>>>>>>>>>> flash device does boot in UEFI! I guess I can assume = this when >>>>>>>>>>>>>>>> the well known clumsy 80x25 char console suddenly gets = bright >>>>>>>>>>>>>>>> and shiny with a much higher resoltion as long the GPU = supports >>>>>>>>>>>>>>>> EFI GOP. Looking with gpart at the USB flash drives = reveals >>>>>>>>>>>>>>>> that the EFI partition starts at block 1 of the device = and the >>>>>>>>>>>>>>>> device has a MBR layout. I haven't found a way to force = the GPT >>>>>>>>>>>>>>>> scheme, when initialised via gpart, to let the = partitions start >>>>>>>>>>>>>>>> at block 1. This might be a naiv thinking, so please be = patient >>>>>>>>>>>>>>>> with me. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I do not know whether this is a well-known issue. On = the ASRock >>>>>>>>>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse = with UEFI >>>>>>>>>>>>>>>> and that worked - FreeBSD not. I gave up on that that = time. >>>>>>>>>>>>>>>> Now, having the very same issues with a new Fujitsu = system, >>>>>>>>>>>>>>>> leaves me with the impression that FreeBSD's UEFI >>>>>>>>>>>>>>>> implementation might have problems I'm not aware of. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Can someone shed some light onto this?=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The first thing to check is if the secure boot is = disabled. We >>>>>>>>>>>>>>> do not support secure boot at all at this time. = =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Secure boot is in every scenario disabled! >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If you have efi or bios version running - you can check = from >>>>>>>>>>>>>>> either console variable value (it can have efi or = vidconsole or >>>>>>>>>>>>>>> comconsole) or better yet, see if efi-version is set = (show >>>>>>>>>>>>>>> efi-version) - if efi-version is not set, it is BIOS = loader >>>>>>>>>>>>>>> running. Another indirect way is to see lsdev -v, with = device >>>>>>>>>>>>>>> paths present, it is uefi:) =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> What are you talking about? >>>>>>>>>>>>>> What is the point of entry - running system, loader? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> sysct machdep.bootmethod: BIOS >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This makes me quite sure that the system has booted via = BIOS - as >>>>>>>>>>>>>> I'm sure since I've checked that many times. UEFI doesn't = work on >>>>>>>>>>>>>> those systems with FreeBSD. I'm not sure antmore, but I = tried >>>>>>>>>>>>>> also Windows 7 on those mainboards booting via UEFI - and = I might >>>>>>>>>>>>>> recall that they failed also. I also recall that there = were >>>>>>>>>>>>>> issues with earlier UEFI versions regarding booting only = Windows >>>>>>>>>>>>>> 8/8.1 - and nothing else, but the fact that Linux worked = confuses >>>>>>>>>>>>>> me a bit. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If this ASRock crap (never ever again this brand!) = doesn't work >>>>>>>>>>>>>> at all - who cares, I intend to purchase new server grade >>>>>>>>>>>>>> hardware. But the more puzzling issue is with the = Fujitsu, which >>>>>>>>>>>>>> I consider serious and from the behaviour the Fujitsu = failure >>>>>>>>>>>>>> looks exactly like the ASRock - Windows 7 works, RedHat = 7.5 >>>>>>>>>>>>>> works (I assume I can trust the Firmware settings when I = disable >>>>>>>>>>>>>> CSM support, that the Firmware will only EFI/UEFI capable >>>>>>>>>>>>>> loader? Or is there a ghosty override somwhere to be = expected?). >>>>>>>>>>>>>> Also on ASRock disabling CSM should ensure not booting a >>>>>>>>>>>>>> dual-bootstrap-capable system. This said, on the recent = Fujitsu, >>>>>>>>>>>>>> it seems to boil down to a FreeBSD UEFI-firmware = interaction >>>>>>>>>>>>>> problem, while the ASRock is still under suspicion to be = broken >>>>>>>>>>>>>> by design. =20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> GPT partitions can never start from disk absolute sector = 1; this >>>>>>>>>>>>>>> is because at sector 0 there is MBR (for compatibility), = sector >>>>>>>>>>>>>>> 1 is GPT table and then sectors 2-33 have GPT partition = table >>>>>>>>>>>>>>> entries, so the first possible data sector is 34 = (absolute 34). >>>>>>>>>>>>>>> Thats assuming 512B sectors. For details see UEFI 2.7 = Chapter >>>>>>>>>>>>>>> 5.3.1 page 131. =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thanks for the explanation. That implies the installer = did right, >>>>>>>>>>>>>> gpart did also right and therefore there must be an issue = with >>>>>>>>>>>>>> the stuff located within the EFI partition? =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we = reach >>>>>>>>>>>>> BIOS loader at all or not - that is, if the BIOS bootstrap = is >>>>>>>>>>>>> actually caring to read the MBR code and start it, since = once the >>>>>>>>>>>>> MBR code is started, it is all about our code. =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the = CSM? or >>>>>>>>>>>> do you mean that specific portion of the UEFI firmware, = which looks >>>>>>>>>>>> for the proper UEFI partition? >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> BIOS as either native or CSM. Note that from boot code point = of view >>>>>>>>>>> the CSM boot *is* BIOS boot, we have no access to UEFI = features. >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The boxes in question, most notably the more recent Fujitsu = Esprimo >>>>>>>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms = of what >>>>>>>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is = switched >>>>>>>>>>>> off in the firmware. Again: GPT partition scheme. >>>>>>>>>>>>=20 >>>>>>>>>>>> The system boots properly if a second partition of type >>>>>>>>>>>> "freebsd-boot" is applied and bootcode is properly applied = via >>>>>>>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" = (ada0 is >>>>>>>>>>>> the device). =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> btw, you can try to validate the installed boot blocks by = using >>>>>>>>>>>>> recent enough loader (usb or iso) and then you can use = from OK >>>>>>>>>>>>> prompt: =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> lsdev provides me with the follwoing informations (CSM = enabled): >>>>>>>>>>>>=20 >>>>>>>>>>>> OK lsdev >>>>>>>>>>>> disk devices: >>>>>>>>>>>> disk0: BIOS DRIVE C ... >>>>>>>>>>>>=20 >>>>>>>>>>>> disk0p1: EFI >>>>>>>>>>>> disk0p2: FreeBSD BOOT >>>>>>>>>>>> disk0p3: FreeBSD SWAP >>>>>>>>>>>> disk0p4: FreeBSD ZFS >>>>>>>>>>>> zfs devices: >>>>>>>>>>>> zfs:zroot >>>>>>>>>>>>=20 >>>>>>>>>>>> OK chain disk0 >>>>>>>>>>>> open failed (so for disk0p{1-4}. >>>>>>>>>>>>=20 >>>>>>>>>>>> OK chain zroot >>>>>>>>>>>> failed to read disk (just for completeness) =20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> chain command does use only device name (such as disk0: or >>>>>>>>>>> disk0p2: ), but not zfs pool as device. I just found I = haven?t >>>>>>>>>>> ported the code to read the file. =20 >>>>>>>>>>=20 >>>>>>>>>> ?? >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> the point for chain command test is to see if the normal = read and >>>>>>>>>>> execute would work, so in your case please try: >>>>>>>>>>>=20 >>>>>>>>>>> chain disk0: =20 >>>>>>>>>>=20 >>>>>>>>>> As stated above, I did so, and the result is also mentioned = above, I >>>>>>>>>> always get "open failed". >>>>>>>>>> This is the same for=20 >>>>>>>>>>=20 >>>>>>>>>> chain disk0 >>>>>>>>>> chain disk0p1 >>>>>>>>>> chain disk0p2 >>>>>>>>>> chain disk0p3 >>>>>>>>>> chain disk0p4 >>>>>>>>>>=20 >>>>>>>>>> as already said. CSM is enabled in this case. =20 >>>>>>>>>=20 >>>>>>>>> sigh? chain command does take device as argument, device must = always >>>>>>>>> end with colon?. in this case, the devil is in details:) as I = wrote >>>>>>>>> above, the command should be: >>>>>>>>>=20 >>>>>>>>> chain disk0: >>>>>>>>>=20 >>>>>>>>> The disk0p1: etc will only work when partition boot code was = installed >>>>>>>>> (which you most likely do not have - the only possible = candidate could >>>>>>>>> be FreeBSD ZFS partition). =20 >>>>>>>>=20 >>>>>>>> The command "chain disk0:" works as expected (CSM enabled, GPT >>>>>>>> partition scheme, but with PMBR bootblock installed and = freebsd-boot >>>>>>>> partition conatining gptzfsboot installed. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> to read pmbr (512B) and execute it. The expected outcome = would be >>>>>>>>>>> that pmbr boot code would browse the GPT, read stage1 from = disk0p2: >>>>>>>>>>> and execute it; stage1 would detect FreeBSD ZFS from = disk0p4: and >>>>>>>>>>> load and execute /boot/loader. If that will happen, it means = the >>>>>>>>>>> boot code in our stages is just fine, but the bios (CSM) = does not >>>>>>>>>>> load pmbr?. if thats true, it would mean that you either = need to >>>>>>>>>>> use UEFI boot or need to have some hack to fool the BIOS or = just not >>>>>>>>>>> use GPT on that machine with CSM. =20 >>>>>>>>>>=20 >>>>>>>>>> To make it clear here: The only way to boot this box is using = CSM (as >>>>>>>>>> it is the same with the ASRock boards mentioned earlier). But = my >>>>>>>>>> intention is to disable CSM and use a GPT/UEFI environment = only! And >>>>>>>>>> GPT/UEFI doesn't work with FreeBSD, neither with 12-CURRENT, = nor >>>>>>>>>> 11.2-RELENG. >>>>>>>>>>=20 >>>>>>>>>> It would be nice if this could be fixed. I'm more interested = in the >>>>>>>>>> fix on the recent Fujitsu device than the outdated ASRock = crap, but >>>>>>>>>> if the fix for the Fujitsu Firmware could fix older issues as = a >>>>>>>>>> byproduct, I'd appreciate that. >>>>>>>>>>=20 >>>>>>>>>> Kind regards, >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ok, somehow I have lost that part of the discussion. Well, you = wrote >>>>>>>>> that the UEFI boot fails when the first partition starts from = sector >>>>>>>>> 40 - does it mean you have boot when the partition will start = from >>>>>>>>> some other sector? I think, there is something else going on. = =20 >>>>>>>>=20 >>>>>>>> Well, I simply try to describe what I "see" to make things >>>>>>>> disambiguous. I'm not familiar with the deeper insights of disk = layouts >>>>>>>> on a binary level. So, you explained to me the reason, why ESP = (EGI >>>>>>>> partition) starts at block 40. I compared that to the FreeBSD = USB flash >>>>>>>> image FreeBSD provides, but this is another story since the = image uses >>>>>>>> MBR scheme as I figured out. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> What you can do is to see if that firmware will offer you EFI = shell >>>>>>>>> option, from there you can try to start the bootx64.efi = manually and >>>>>>>>> see what error you will get. However, the number 1 cause for = failing >>>>>>>>> to start the bootloader in UEFI is secure boot - we do not = support it >>>>>>>>> and secure boot must be switched off.=20 >>>>>>>>>=20 >>>>>>>>> However, they seem to claim "The Secure Boot option is = available in >>>>>>>>> the UEFI/BIOS of most if not all ASRock boards. It is disabled = by >>>>>>>>> default.?=20 >>>>>>>>>=20 >>>>>>>>> Still suggest to double check if thats really the case. Also, = if the >>>>>>>>> bootx64.efi start will fail and no messages are appearing on = screen, >>>>>>>>> then either there is something in firmware logs or you could = get them >>>>>>>>> from trying to start bootx64.efi from UEFI shell. =20 >>>>>>>>=20 >>>>>>>> Since I'm with this problem since 2014 and try from time to = time, be >>>>>>>> ausred that I tried every possible permutationof all reasonable >>>>>>>> options, even those nonsense, to get rid of that problem. >>>>>>>>=20 >>>>>>>> I never had any problems with any other UEFI capable = server/workstation >>>>>>>> firmware so far booting FreeBSD off in UEFI-native (GPT = partition >>>>>>>> scheme, CSM disabled) so far - until now, when I ran into this = Fujitsu >>>>>>>> ESPRIMO Q956 with the most recent firmware (as of lat week, = week 29 of >>>>>>>> 2018) having the very same problems.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I figured out something strange on the Fujitsu - and that is = the same >>>>>>>> with the ASRock boards. >>>>>>>>=20 >>>>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a very = small >>>>>>>> appliance, but nevertheless, the USB flash device is booted on = Fujitsu >>>>>>>> servers with UEFI-only configurations. I assume at this point = that >>>>>>>> disabling on the most recent Fujitsu firmwares on reasonable = "new" >>>>>>>> hardware (not older than three years) will disable any(!) = legacy BIOS >>>>>>>> capabilities. The same is assumed for the Fujitus ESPRIMO Q956. = I can >>>>>>>> not speak for the ASRock A77 Pro4/m boards mentioned = above/earlier, >>>>>>>> they are from 2012/2013 and "quite old". >>>>>>>>=20 >>>>>>>> The NanoBSD image of ours doesn't have a "freebsd-boot" = partition. The >>>>>>>> partition scheme of the flash device is GPT. The layout looks = like >>>>>>>> this: >>>>>>>>=20 >>>>>>>> gpart show -l da4 =20 >>>>>>>> =3D> 40 15425456 da4 GPT (7.4G) =20 >>>>>>>> 40 2000 1 efiboot0 (1.0M) >>>>>>>> 2040 1453584 3 disk1a (710M) >>>>>>>> 1455624 4096 5 disk3 (2.0M) >>>>>>>> 1459720 13965776 - free - (6.7G) >>>>>>>>=20 >>>>>>>> I created the flash with md, gpart and dd straightforward, = efiboot0 is >>>>>>>> the ESP partition and its format/content is created via dd >>>>>>>> if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is = very simple. >>>>>>>>=20 >>>>>>>> This USB flash device boots(!) successfully (UEFI!) on both the = ASRock >>>>>>>> boards and the Esprimo Q956! >>>>>>>>=20 >>>>>>>> But any SSD prepared the same way doesn't. Why?=20 >>>>>>>>=20 >>>>>>>> On the ASRock, I recall having fiddled around with HDD also for = a while >>>>>>>> conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD = - I >>>>>>>> can't remember.=20 >>>>>>>>=20 >>>>>>>> In the lack of proper hardware I'm unable to check whether = USB-attached >>>>>>>> HDD or SSD will boot or HDD will boot (just in case the local = SATA has >>>>>>>> problems booting UEFI and USB not). >>>>>>>>=20 >>>>>>>> Kind regards, >>>>>>>>=20 >>>>>>>> Oliver=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> Am. well. I think the suggestion to test out FAT32 is still good = one to >>>>>>> test. This is because it is known that some vendors do not = support >>>>>>> booting FAT12/FAT16 from HDD (the likely reason is that UEFI >>>>>>> specification does not tell which FAT must be supported, and = only hint >>>>>>> about FAT12/FAT16 in context of removable devices). =20 >>>>>>=20 >>>>>> I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO = Q956. It >>>>>> took me a time to circumvent the installer and I had to install = the >>>>>> system manually. In that strain, I also "tried" to establish the = ESP with >>>>>> FAT32, as Allen Jude suggested earlier. I didn't find any ad hoc = help how >>>>>> to find out the format (FAT12/16/32) of the ESP, so I assume when = using >>>>>> 12-CURRENT's or 11.2-RELENG's installer with AUTO-ZFS and GPT = (UEFI) >>>>>> (only!) the resulting ESP is FAT12 or FAT16 (300mb by default). I = also >>>>>> assume, that when dd'ing the /boo/boot1.efifat image to a = partition, the >>>>>> format is FAT, but not FAT32. Therefore, I refomatted the = manually >>>>>> created ESP (using "gpart add -t efi ...") using "newfs_msdos -F = 32 -b >>>>>> xxx ...". I had to fiddle around a bit with option -b to fit in a = proper >>>>>> format to meet a 512mb ESP - I'm not sure whether this is the = proper >>>>>> option to deal with. When using the default and only -F32, the = size of >>>>>> the partition has to be 4G at least I assume. Having done that, I = copied >>>>>> the the content of boot1.efifat (mdconfig -t vnode ..., I guess = we know >>>>>> the drill ...) to the newly formatted ESP to /boot/efi/ ... >>>>>>=20 >>>>>> Having so far no knowledge of how to asure that the created ESP = is FAT32, >>>>>> I assume it is FAT32. >>>>>>=20 >>>>>> The result is negative on the ESPRIMO Q956. When disabling the = CSM, the >>>>>> box is not willing to boot from SSD with the ESP prepared as = decribed. >>>>>> So, a chance that this might still be due to a misconfiguration = lies now >>>>>> within the -b option of newfs_msdos - if the -b option is assumed = the >>>>>> proper option? >>>>>>=20 >>>>>> At the moment, the ESP of the Esprimo is subject to changes, if = you wish, >>>>>> but not in size, since it is limited to 512mb. >>>>>>=20 >>>>>> Thanks and kind regards, >>>>>>=20 >>>>>> Oliver =20 >>>>>=20 >>>>> Yea, i was hoping fstyp command would report the FAT type, but it = does not >>>>> (request for feature?:) =20 >>>>=20 >>>> FYI, the file(1) command is very good at disecting a disk image to = tell >>>> you what the MBR looks like, and at looking at partitions if = pointed at >>>> them with the -s option. It should be able to detect FAT12/16/32. >>>>=20 >>>> root@x230a:/home/ISO/x # file -s /dev/md2s1 >>>> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 = ", >>>> root entries 512, sectors 1600 (volumes <=3D32 MB) , sectors/FAT 5, >>>> sectors/track 63, heads 1, serial number 0xbd4111ee, label: "EFISYS = ", >>>> FAT (12 bit), followed by FAT >>>>=20 >>>>>=20 >>>>> However, the more annoying idea would be to install some OS which = will >>>>> boot with UEFI on this machine, then copy boot1.efi from freebsd = to it >>>>> (the default program the UEFI will load is = ESP:EFI/boot/bootx64.efi in >>>>> case of UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, = we do >>>>> not support EFI32. >>>>>=20 >>>>> note that boot1.efi alone will not do much but printing on screen = how it >>>>> will search for freebsd, but for the purpose of the test it would = suffice >>>>> - that would give us confirmed working ESP file system (since the = other os >>>>> would be able to boot) and then we can confirm if boot1.efi itself = is >>>>> OK. =20 >>>>=20 >>>=20 >>> Some new results. >>> I installed RedHat 7.5 and inestigated the ESP. >>>=20 >>> - The ESP starts at block 2048, while FreeBSD's ESP starts at block = 40. >>> - size is both 200mb if installed automatically. I forgit to = investigate the >>> FAT format, but this might be unnecessary as shown further in this = post. >>> - RedHat's ESP contains ~ 10 MB of data in two >>> folders, /efi/boot, /efi/redhat. copying FreeBSD's BOOTX64.efi over >>> RedHat's doesn't change anything, also renaming /efi/boot/fbx64.efi = of >>> RedHat's installation. But renaming /efi/redhat renders RedHat to = fail the >>> boot process on the Fujitsu with the signs of the built-in = testprogram as >>> reported. >>>=20 >>> I took the liberty and installed 11.2-RELENG again, ZFS only, UEFI = boot only >>> (CSM in firmware disabled, but there is still a gptzfsboot-prepared >>> partition for later use, just for the record). Booting UEFI-only = fails as >>> reported. On this installation I copied the RedHat ESP completely = into >>> FreeBSD's ESP, renamed /efi/boot/BOOTX64.efi to = /efi/boot/BOOTX64.efi.rh >>> and copied FreeBSD's BOOTX64.efi to /efi/boot.=20 >>> The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, = that >>> the /efi/redhat folder of the ESP is important, if renamed, the = whole >>> process dies as I reported earlier. >>>=20 >>> Still unanswered is the question: why is a NanoBSD prepared = UEFI-only USB >>> flash booting with CSM disabled (so asumingly UEFI only then) on = both >>> ASRock and Fujitsu (as described in more detail initially and = earlier), >>> while SSDs fail? Is there a difference? Since FreeBSD boots in UEFI = mode >>> from USB flash prepared as described (straight forward, 800k ESP = starting >>> at block 40, the boot1.efifat image dd'ed onto the partition, UFS = partition >>> following, no freebsd-boot partition or MBR/PMBR bootcode applied = ever!), I >>> think BOOTX64.EFI is technically all right. There must be then an = issue >>> with the SATA/SSD/HDD boot pathway. >>>=20 >>> Hope I could provide some more details, sorry if it sounds confusing = or way >>> too long, but I try to descibe the situation as thorough as = possible. >>>=20 >>=20 >> OK, this is already good hint. The thing with ESP is that there is = =E2=80=9Cdefault=E2=80=9D >> file system tree: EFI/BOOT/BOOT.EFI, this is noted as = default for >> *removable* media, fortunately it is usable for hard disks as well, = or at >> least in most cases. >>=20 >> Now, for non-removable media, the UEFI does provide boot manager = interface to >> define boot entries, and the fact that renaming efi/redhad directory = did >> break the redhat boot, is very loud hint. And this means, this system = is >> probably ignoring efi/boot tree on non-removable media and is = expecting the >> boot manager entry to be created instead. >=20 > This inplication I'd confirm for the recent Fujitsu ESPRIMO Q956 = firmware (not > tested on ASRock Z77-Pro4 firmware). >=20 >>=20 >> UEFI boot manager can be configured /usually/ manually via firmware = menu, or >> by application, such as efibootmgr. The normal approach is to create >> efi/ directory and to copy the application there, then = create the >> boot manager configuration. >>=20 >> See UEFI specification v2.7, chapter 3 Boot Manager, page 79. >>=20 >> What is different in FreeBSD case is that the whole interface to = program the >> UEFI Boot Manager is currently being developed, so either it has to = be done >> manually or from some other OS (see = https://wiki.gentoo.org/wiki/Efibootmgr >> for example, first hit from >> google:D). >=20 > Well, thanks for this important hint! FreeBSD 12-CURRENT's and FreeBSD > 11.2-RELENG's USB flash devices are capable of booting off on = Fujitsu's ESPRIMO > and ASRock's boards. As a note: after "kldload efirt.ko" I was able to = use the > already in FreeBSD present toolset efibootmgr(8) and sibblings (the = tools do > not do anything useful when booted non-UEFI). >=20 > Mounting the ESP of the harddrive (in my case, ada0p1) to /mnt and = following > the steps in the examples and having created /efi/freebsd/BOOTx64.efi = as > recommended by copy from /efi/boot, let me create a proper boot = variable. >=20 > To make things sure, I also applied "efibootmgr -a VARIABLENAME". >=20 > And ... it worked! Yes, it worked! The ESP is FAT32 formatted, I do = not know > whether this will also work with FAT12/16, I should test this case, = too. >=20 > There is a bug in the manpage of efibootmg(8). It does not explain the = options > -d and -p, although they could be "implied" by reading carefully. = There is now > a PR at=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230080 >=20 > for this issue. >=20 > So, it's apity that the handbook has no note I could easily find on = this;=20 >=20 > Thank you very much for your patience and help! >=20 > Kind regards, > Oliver yep, efibootmgr does call UEFI RuntimeServices to set up the variables, = and this is only possible when booted UEFI. But glad we finally found = the root cause. It would be good to have HW notes for such cases, it is = important to know that those systems wont boot UEFI from HDD unless the = boot manager setup is done. rgds, toomas= From owner-freebsd-current@freebsd.org Fri Jul 27 06:29:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67EF81062262 for ; Fri, 27 Jul 2018 06:29:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.ne1.yahoo.com (sonic310-21.consmr.mail.ne1.yahoo.com [66.163.186.202]) (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 BD7598726F for ; Fri, 27 Jul 2018 06:29:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8Oge2iEVM1nbQBAnim4krKruU5hOC39fB4TjvuUiXxrW.Rd5b_Qv7z1n5wXbRxG 2iWdOJsZI_rBV8XpP6AQPIQrkm9cbNeFN8vsJkBKvwPRtJc7QiUF6VO10XYDZPPgzcDQd.DTq9NZ tv4CrrRIKP9BX_oSmVhuLB1Xn10go87p7zuprddT4gPh.JsUqksvLdiUPfB861IK0PRTY5hu3AwI 4Lo8CSY6sTQjWG_F2WQWXgBOPMsRrVEBcLiFu403YQm5MdsU0K5w8bI0.vI2a43eEClCv7Cmg19f waXMni47RsnQ_FFfDAUZstzWFVmCRgJWnzvmYFZfCnHUpjfkI.Ebwl1XT7m8lG1_gAFwbw_ceYC6 CUWBHS7tTJAzL22uiLxYoWO5EAT.Vrm7l9cN6d38KSn0g2aB3sc3X3kIIDfgGi8sKBWkETdyPhQY qp3U1YRTQVIsZn_PZgwLx37ew7xvbVbVaevVq8NVbeeKkjGrbBueK6a1zxBnGmHXTfvJmhRrl56C 6aupPrKJpEQEvsPWXlkFplvHvOlqxCPKseY.MEStfq4ZGCT8E86lcKPX8EuMoqU2ECmscjOAKMO7 ijy8IrxraRGyi5.riscwj1WxGTlFzJM8OmFwtshjjqpF_R3VkcenCjTHf5_RCJtk1oIs_x0VyJAI LsnVCwVkjUWU3_Fk.OYxjaqNqWBCWRCb9ZROS_t9dYgEFUicYWuEnYOKFkVzgfw1Y87J0VCe1blg rMMcSdaX3bW9eHrmdF4Pibklve4Wxjz_oMuFmbxD9k.PYu1ramkz3z0F6TP7aZHrDmkO76bQD285 9L5p1t9s4jw24c4iaBFji_SJCN261aAJPBtz5_2pq1DEUqw9R2OKIucxr6bm3bx_p.tmeyxnmbGY JSrRxeTUeYJ8L8WaJRoo1CR0BkSN7i6THOzJ3aNKDVy1CuFrHnXpYASYCZpd3mx4x33sKvG0bv9v e3AmsZgH2KRUXGAa_r5Rnlmbc63COYGJGVEOWMY_xIexTLNtEHjfKwowWuA4Od5uAQPGaaxdpjq1 BkQ4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Fri, 27 Jul 2018 06:29:56 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp403.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8b0ef247023d1b87e5e70354b1b7fdc3; Fri, 27 Jul 2018 06:29:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: Date: Thu, 26 Jul 2018 23:29:49 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <462BE582-0C2E-4D40-92F3-A27155777E58@yahoo.com> References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 06:29:58 -0000 On 2018-Jul-26, at 9:06 PM, Mark Millard wrote: > On 2018-Jul-26, at 6:14 PM, Mark Millard wrote: >=20 >> On 2018-Jul-26, at 11:21 AM, John Baldwin wrote: >>=20 >>> On 7/26/18 10:55 AM, Mark Millard wrote: >>>> . . . >>>=20 >>> Yes, but the -E from above was when compiled with external GCC and = it didn't change >>> _Atomic(int). Here's part of the source of bar.c: >>>=20 >>> #include >>> #include >>>=20 >>> struct foo { >>> _Atomic(int) one; >>> _Atomic int two; >>> atomic_int three; >>> }; >>>=20 >>> And here is what that became after -E: >>>=20 >>> # 4 "bar.c" >>> struct foo { >>> _Atomic(int) one; >>> _Atomic int two; >>> atomic_int three; >>> }; >>>=20 >>> So cdefs.h did not define _Atomic. >>>=20 >>> Ah, if I add '-std=3Dc99' then it does break. Code that wants to = use >>> C11 atomics via should not be using -std=3Dc99. Try = this: >>>=20 >>> Index: lib/ofed/librdmacm/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- lib/ofed/librdmacm/Makefile (revision 335896) >>> +++ lib/ofed/librdmacm/Makefile (working copy) >>> @@ -8,6 +8,7 @@ >>> SHLIB_MAJOR=3D 1 >>> MK_PROFILE=3D no >>> CFLAGS+=3D -I${_spath} >>> +CSTD=3D gnu11 >>>=20 >>> SRCS=3D \ >>> acm.c \ >>>=20 >>> If this works then we should probably mark OFED as a BROKEN_OPTION = when >>> building with ancient GCC for now as well. >>=20 >> I've "unreverted" to set up a context for testing this. >>=20 >> So far I'll I've done is to test that I can still reproduce the = failure >> in my environment, same sort of error reports as ci.freebsd.org's >> FreeBSD-head-amd64-gcc . This is without your patch. >>=20 >> But I've done this with gcc being given -v so that I've the exact = commands >> and search order and the like. It does show: -std=3Dgnu99 . I list = the >> filemon data from the .meta as well, showing the exact mix of >> FreeBSD and gcc headers used. (I could also provide such for with >> the reverted Makefile.{inc1,libcompat} [so non-failing] build if you >> care.) >>=20 >>=20 >> For now I just report the failure *without your patch*: >> (I'll build again with your patch next.) >>=20 >> . . . >> --- all_subdir_lib/ofed --- >> Building = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o >> --- acm.o --- >> Using built-in specs. >> COLLECT_GCC=3D/usr/local/bin/x86_64-unknown-freebsd12.0-gcc >> Target: x86_64-unknown-freebsd12.0 >> Configured with: = /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure = --target=3Dx86_64-unknown-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --enable-gnu-indirect-function = --without-headers --with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD = Ports Collection for amd64' --with-system-zlib = --with-gxx-include-dir=3D/usr/include/c++/v1/ --with-sysroot=3D/ = --with-as=3D/usr/local/bin/x86_64-unknown-freebsd12.0-as = --with-ld=3D/usr/local/bin/x86_64-unknown-freebsd12.0-ld = --enable-initfini-array --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ = --build=3Dx86_64-unknown-freebsd12.0 >> Thread model: posix >> gcc version 6.4.0 (FreeBSD Ports Collection for amd64)=20 >> COLLECT_GCC_OPTIONS=3D'-B' = '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2' '-pipe' '-I' = '/usr/src/contrib/ofed/librdmacm' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wno-error=3Daddress' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dattributes' = '-Wno-error=3Dbool-compare' '-Wno-error=3Dcast-align' = '-Wno-error=3Dclobbered' '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' = '-Wno-error=3Dinline' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dstrict-aliasing' '-Wno-error=3Duninitialized' = '-Wno-error=3Dunused-but-set-variable' '-Wno-error=3Dunused-function' = '-Wno-error=3Dunused-value' '-Wno-error=3Dmisleading-indentation' = '-Wno-error=3Dnonnull-compare' '-Wno-error=3Dshift-negative-value' = '-Wno-error=3Dtautological-compare' '-Wno-error=3Dunused-const-variable' = '-v' '-c' '-o' 'acm.o' '-mtune=3Dgeneric' '-march=3Dx86-64' >> /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v = -I /usr/src/contrib/ofed/librdmacm -isysroot = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp = /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c = -mtune=3Dgeneric -march=3Dx86-64 -auxbase-strip acm.o -g -O2 = -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dmisleading-indentation -Wno-error=3Dnonnull-compare = -Wno-error=3Dshift-negative-value -Wno-error=3Dtautological-compare = -Wno-error=3Dunused-const-variable -std=3Dgnu99 -version = -fstack-protector-strong -o - | >> /usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I = /usr/src/contrib/ofed/librdmacm -o acm.o >> GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) >> compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none >> GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 >> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" >> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-un= known-freebsd12.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/src/contrib/ofed/librdmacm >> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include >> = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude >> End of search list. >> GNU assembler version 2.30 (x86_64-unknown-freebsd12.0) using BFD = version (GNU Binutils) 2.30 >> GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) >> compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none >> GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 >> Compiler executable checksum: 0b55436e4202650149cc2feb351f4e0e >> In file included from /usr/src/contrib/ofed/librdmacm/cma.h:43:0, >> from /usr/src/contrib/ofed/librdmacm/acm.c:42: >> /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >> /usr/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer >> atomic_store(&lock->cnt, 0); >> ^ >> In file included from /usr/src/contrib/ofed/librdmacm/acm.c:42:0: >> /usr/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': >> /usr/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' >> if (atomic_fetch_add(&lock->cnt, 1) > 0) >> ^~ >> /usr/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': >> /usr/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' >> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >> ^~ >> *** [acm.o] Error code 1 >>=20 >> make[6]: stopped in /usr/src/lib/ofed/librdmacm >> .ERROR_TARGET=3D'acm.o' >> = .ERROR_META_FILE=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd6= 4.amd64/lib/ofed/librdmacm/acm.o.meta' >> .MAKE.LEVEL=3D'6' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> _ERROR_CMD=3D'/usr/local/bin/x86_64-unknown-freebsd12.0-gcc = --sysroot=3D/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/= tmp -B/usr/local/x86_64-unknown-freebsd12.0/bin/ -O2 -pipe = -I/usr/src/contrib/ofed/librdmacm -g -std=3Dgnu99 = -fstack-protector-strong -Wno-error=3Daddress -Wno-error=3Darray-bounds = -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align = -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra = -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses = -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function = -Wno-error=3Dunused-value -Wno-error=3Dmisleading-indentation = -Wno-error=3Dnonnull-compare -Wno-error=3Dshift-negative-value = -Wno-error=3Dtautological-compare -Wno-error=3Dunused-const-variable = -v -c /usr/src/contrib/ofed/librdmacm/acm.c -o acm.o; ;' >> .CURDIR=3D'/usr/src/lib/ofed/librdmacm' >> .MAKE=3D'make' >> = .OBJDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/l= ib/ofed/librdmacm' >> .TARGETS=3D'all' >> = DESTDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/t= mp' >> LD_LIBRARY_PATH=3D'' >> MACHINE=3D'amd64' >> MACHINE_ARCH=3D'amd64' >> MAKEOBJDIRPREFIX=3D'' >> MAKESYSPATH=3D'/usr/src/share/mk' >> MAKE_VERSION=3D'20180512' >> = PATH=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/= legacy/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.am= d64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/a= md64.amd64/tmp/legacy/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/sr= c/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/s= rc/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' >> SRCTOP=3D'/usr/src' >> = OBJTOP=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64' >> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.amd64-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/ofed/librdmacm/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/lib/ofed/librdmacm/../Makefile.inc /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.symver.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk = /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' >> .PATH=3D'. /usr/src/lib/ofed/librdmacm = /usr/src/contrib/ofed/librdmacm /usr/src/contrib/ofed/librdmacm/man' >> 1 error >>=20 >> =46rom = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o.meta >> is the filemon data: >>=20 >> -- filemon acquired metadata -- >> # filemon version 5 >> # Target pid 95011 >> # Start 1532652684.414953 >> V 5 >> E 95033 /bin/sh >> R 95033 /etc/libmap.conf >> R 95033 /var/run/ld-elf.so.hints >> R 95033 /lib/libedit.so.7 >> R 95033 /lib/libc.so.7 >> R 95033 /lib/libncursesw.so.8 >> F 95033 95034 >> E 95034 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc >> R 95034 /etc/libmap.conf >> R 95034 /var/run/ld-elf.so.hints >> R 95034 /usr/lib/libc++.so.1 >> R 95034 /lib/libcxxrt.so.1 >> R 95034 /lib/libm.so.5 >> R 95034 /lib/libc.so.7 >> R 95034 /lib/libgcc_s.so.1 >> F 95034 95035 >> E 95035 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 >> F 95034 95036 >> R 95035 /etc/libmap.conf >> R 95035 /var/run/ld-elf.so.hints >> R 95035 /usr/local/lib/libmpc.so.3 >> R 95035 /usr/local/lib/libmpfr.so.6 >> R 95035 /usr/local/lib/libgmp.so.10 >> R 95035 /lib/libz.so.6 >> R 95035 /usr/lib/libc++.so.1 >> R 95035 /lib/libcxxrt.so.1 >> R 95035 /lib/libm.so.5 >> R 95035 /lib/libc.so.7 >> R 95035 /lib/libgcc_s.so.1 >> R 95035 /dev/urandom >> R 95035 /usr/src/contrib/ofed/librdmacm/acm.c >> E 95036 /usr/local/bin/x86_64-unknown-freebsd12.0-as >> R 95036 /etc/libmap.conf >> R 95036 /var/run/ld-elf.so.hints >> R 95036 /lib/libc.so.7 >> R 95036 acm.o >> W 95036 acm.o >> R 95035 /usr/src/contrib/ofed/librdmacm/config.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdio.h >> R 95035 /usr/src/sys/sys/cdefs.h >> R 95035 /usr/src/sys/sys/_null.h >> R 95035 /usr/src/sys/sys/_types.h >> R 95035 /usr/src/sys/amd64/include/_types.h >> R 95035 /usr/src/sys/x86/include/_types.h >> R 95035 /usr/src/sys/amd64/include/_limits.h >> R 95035 /usr/src/sys/x86/include/_limits.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/inttypes.h >> R 95035 /usr/src/sys/amd64/include/_inttypes.h >> R 95035 /usr/src/sys/x86/include/_inttypes.h >> R 95035 /usr/src/sys/sys/stdint.h >> R 95035 /usr/src/sys/amd64/include/_stdint.h >> R 95035 /usr/src/sys/x86/include/_stdint.h >> R 95035 /usr/src/sys/amd64/include/_limits.h >> R 95035 /usr/src/sys/sys/_stdint.h >> R 95035 /usr/src/sys/sys/types.h >> R 95035 /usr/src/sys/amd64/include/endian.h >> R 95035 /usr/src/sys/x86/include/endian.h >> R 95035 /usr/src/sys/sys/_pthreadtypes.h >> R 95035 /usr/src/sys/sys/select.h >> R 95035 /usr/src/sys/sys/_sigset.h >> R 95035 /usr/src/sys/sys/_timeval.h >> R 95035 /usr/src/sys/sys/timespec.h >> R 95035 /usr/src/sys/sys/_timespec.h >> R 95035 /usr/src/sys/sys/socket.h >> R 95035 /usr/src/sys/sys/_iovec.h >> R 95035 /usr/src/sys/amd64/include/_align.h >> R 95035 /usr/src/sys/x86/include/_align.h >> R 95035 /usr/src/sys/sys/_sockaddr_storage.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/netdb.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/unistd.h >> R 95035 /usr/src/sys/sys/unistd.h >> R 95035 /usr/src/contrib/ofed/librdmacm/cma.h >> R 95035 /usr/src/contrib/ofed/librdmacm/config.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdlib.h >> R 95035 /usr/src/sys/sys/errno.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/endian.h >> R 95035 /usr/src/sys/sys/endian.h >> R 95035 /usr/src/sys/amd64/include/endian.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/semaphore.h >> R 95035 /usr/src/sys/sys/_umtx.h >> R 95035 /usr/src/sys/amd64/include/_limits.h >> R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/rdma/rdma_cma.h >> R 95035 /usr/src/sys/netinet/in.h >> R 95035 /usr/src/sys/amd64/include/endian.h >> R 95035 /usr/src/sys/netinet6/in6.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/verbs.h >> R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdint.h >> R 95035 /usr/src/sys/sys/stdint.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/pthread.h >> R 95035 /usr/src/sys/amd64/include/_limits.h >> R 95035 /usr/src/sys/amd64/include/_types.h >> R 95035 /usr/src/sys/sys/sched.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/time.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_time.h >> R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stddef.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/string.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/strings.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_strings.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_string.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/types.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/sa.h >> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/ib.h >> R 95035 /usr/src/contrib/ofed/librdmacm/cma.h >> X 95036 0 0 >> X 95035 1 0 >> D 95034 acm.o >> X 95034 1 0 >> X 95033 1 0 >> # Stop 1532652684.494688 >> # Bye bye >>=20 >>=20 >>=20 >> For reference the amd64-gcc is: >>=20 >> # pkg info amd64-gcc >> amd64-gcc-6.4.0_1 >> Name : amd64-gcc >> Version : 6.4.0_1 >> Installed on : Sun Jul 15 09:15:38 2018 PDT >> Origin : devel/amd64-gcc >> Architecture : FreeBSD:12:amd64 >> Prefix : /usr/local >> Categories : devel >> Licenses : GPLv3, GPLv3RLE >> Maintainer : kan@FreeBSD.org >> WWW : http://gcc.gnu.org/ >> Comment : Cross GNU Compiler Collection for amd64 >> Shared Libs required: >> libmpc.so.3 >> libgmp.so.10 >> libmpfr.so.6 >> Shared Libs provided: >> liblto_plugin.so.0 >> Annotations : >> FreeBSD_version: 1200069 >> repo_type : binary >> repository : custom >> Flat size : 338MiB >> Description : >> GCC, the GNU Compiler Collection supporting C and C++ for targetting = crossbuilding. >>=20 >> WWW: http://gcc.gnu.org/ >=20 > With your patch it gets past that point of build failure. >=20 > But my devel/amd64-gcc predates the removal of float.h from > the installed devel/amd64-gcc so the following may not be as > it would be in such a context: >=20 > --- lib/msun__L --- > /usr/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long = double format" > #error "Unsupported long double format" > ^~~~~ > . . . > --- lib/msun__L --- > /usr/src/lib/msun/src/catrigl.c: In function 'casinhl': > /usr/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared = (first use in this function) > w =3D clog_for_large_values(z) + m_ln2; > ^~~~~ > /usr/src/lib/msun/src/catrigl.c:190:35: note: each undeclared = identifier is reported only once for each function it appears in > /usr/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON' = undeclared (first use in this function) > if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) > ^~~~~~~~~~~~~~ > /usr/src/lib/msun/src/catrigl.c: In function 'cacosl': > /usr/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared = (first use in this function) > ry =3D creall(w) + m_ln2; > ^~~~~ > /usr/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON' = undeclared (first use in this function) > if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) > ^~~~~~~~~~~~~~ > In file included from /usr/src/lib/msun/src/catrigl.c:45:0: >=20 >=20 >=20 > I can remove float.h and see what happens. While the build without gcc's float.h goes on, here are some small experiments with interesting results (mostly these are with -std=3Dgnu11): # more AtomicTest.c=20 // x86_64-unknown-freebsd12.0-gcc -v -E AtomicTest.c #include #include struct foo { _Atomic(int) one; _Atomic int two; atomic_int three; }; # x86_64-unknown-freebsd12.0-gcc -dM -std=3Dgnu11 -E AtomicTest.c | grep = has_ #define __has_include(STR) __has_include__(STR) #define __has_include_next(STR) __has_include_next__(STR) #define __has_extension __has_feature #define __has_builtin(x) 0 #define __has_feature(x) 0 (-std=3Dgnu99 matches the above) # x86_64-unknown-freebsd12.0-gcc -dM -std=3Dgnu11 -E AtomicTest.c | grep = atomic_fetch #define atomic_fetch_or(PTR,VAL) __atomic_fetch_or ((PTR), (VAL), = __ATOMIC_SEQ_CST) #define atomic_fetch_or_explicit(PTR,VAL,MO) __atomic_fetch_or ((PTR), = (VAL), (MO)) #define atomic_fetch_and_explicit(PTR,VAL,MO) __atomic_fetch_and ((PTR), = (VAL), (MO)) #define atomic_fetch_sub_explicit(PTR,VAL,MO) __atomic_fetch_sub ((PTR), = (VAL), (MO)) #define atomic_fetch_xor_explicit(PTR,VAL,MO) __atomic_fetch_xor ((PTR), = (VAL), (MO)) #define atomic_fetch_add(PTR,VAL) __atomic_fetch_add ((PTR), (VAL), = __ATOMIC_SEQ_CST) #define atomic_fetch_sub(PTR,VAL) __atomic_fetch_sub ((PTR), (VAL), = __ATOMIC_SEQ_CST) #define atomic_fetch_and(PTR,VAL) __atomic_fetch_and ((PTR), (VAL), = __ATOMIC_SEQ_CST) #define atomic_fetch_xor(PTR,VAL) __atomic_fetch_xor ((PTR), (VAL), = __ATOMIC_SEQ_CST) #define atomic_fetch_add_explicit(PTR,VAL,MO) __atomic_fetch_add ((PTR), = (VAL), (MO)) (-std=3Dgnu99 matches the above) The following shows -std=3Dgnu99 vs. -std=3Dgnu11 results that do not match: # x86_64-unknown-freebsd12.0-gcc -E -std=3Dgnu99 AtomicTest.c | more . . . # 6 "AtomicTest.c" struct foo { =20 # 7 "AtomicTest.c" 3 4 struct {=20 # 7 "AtomicTest.c" int=20 # 7 "AtomicTest.c" 3 4 volatile __val; }=20 # 7 "AtomicTest.c" one; _Atomic int two; atomic_int three; }; . . . # x86_64-unknown-freebsd12.0-gcc -E -std=3Dgnu11 AtomicTest.c | more . . . # 6 "AtomicTest.c" struct foo { _Atomic(int) one; _Atomic int two; atomic_int three; }; . . . I will add a #warning where FreeBSD's cdefs.h has the #define _Atomic(T) to report on if the #define _Atomic(T) is being processed (but possibly ignored) for -std=3Dgnu11 . (But after the ongoing build stops.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 27 07:12:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D2931062E6D for ; Fri, 27 Jul 2018 07:12:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.146]) (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 C8C4688EE5 for ; Fri, 27 Jul 2018 07:12:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 7HdMfRcVM1nYeD1b3nqSrwytzt3dDjHrpdbbzw85mueYxVYnkjgd0Fq02c5GxfG B793XU7_LrWo3aJchu5iNHQ7T7f5Q34Lo8AysVA_KTGCXPKPH36nehNrA1oXZvGLnq1srfcYoL48 S9G2vstPSfEeZ6REFpycov5JV1ap2gqlEJJQIP.DNtDlzRoPgQdL6UR.tJ5vq2qupnIA_4rpd5Kl uMxTDHY4SsOC9gEYnT9.5TUpXHkquWXd59hH2IlrfXuBBNxkk4eNtqzcbqBvXg02zClrcTx96.Qh yMa6BHBezi0cjpLUHXvG37h_EUHELSkF2FfpW5xCV.Hnr7OigZMd3v1yxJq.yztvB1jdewXngIvO WkkiOPqnsEhPVdhoSqn2RmAVzPXEIblWsNAHv_7bjN2fgy_OCxiuzIH9t9ue2mm_NQw8g1FXKRRo ggxDBhm2m0CU0zke8xPCpycR7PX3.lct.V37Me1Nwr7N4Dh3E8wREpuowqhtFGNF9Nne9xpJsfnp fUTgvuDYqXxp.x4FkRjY14r8SUi9BOgScTBOvFwl5i0vsNcKn_LgKq5Lvhb7MDTcF4wqu2XTQYyk k0UITSwgLkZwZQYtCC6V.QBuzv7UfXfqF746Uie59WUygjlu8AIwNc7PwJUtAURxWDnHg56sn00B q3mv7sxvXx5sP9oBDSRE9QtU7rmO3CBdvKdaXK5mgXF6iN.y_3X5jnUFF6raMYd_KsLSuOZQfYJ0 iSryY5GQkSbbWx4gj_k3Gb6bq3nqLnvx2Gi4UIQ9JU6aGyAEZr_rmi2dXkAKFsXNXfYrabz9zEeh bK..v5jwP1rziPhnVcSpCyeqiYFW_PmmjBGTtbFKw_NEMfUb3HxsiwN8p7Rq.fmygnYLJ8boiYR. EILiItF2BIy_qergTBPB5..ILCqORH4yZsuAw8lqHA4grRpCQWfGEOQAtgmtijTc9cUzExVN6qyM _ifUNvsZTsQTLP7CnbbPtiAERiDS4k_Qs2kV9dzQAIuHqxVy5gAPe8ifvHQHAKrfBac1ATnRHcw- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Fri, 27 Jul 2018 07:12:09 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp406.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 511e70b1d557906a695968041a91aa8c; Fri, 27 Jul 2018 07:12:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <462BE582-0C2E-4D40-92F3-A27155777E58@yahoo.com> Date: Fri, 27 Jul 2018 00:12:06 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <1E03ECE7-297C-4D40-BC58-FB1903538181@yahoo.com> References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> <462BE582-0C2E-4D40-92F3-A27155777E58@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 07:12:17 -0000 On 2018-Jul-26, at 11:29 PM, Mark Millard wrote: > On 2018-Jul-26, at 9:06 PM, Mark Millard wrote: >=20 >> On 2018-Jul-26, at 6:14 PM, Mark Millard = wrote: >>=20 >>> On 2018-Jul-26, at 11:21 AM, John Baldwin = wrote: >>>=20 >>>> On 7/26/18 10:55 AM, Mark Millard wrote: >>>>> . . . >>>>=20 >>>> Yes, but the -E from above was when compiled with external GCC and = it didn't change >>>> _Atomic(int). Here's part of the source of bar.c: >>>>=20 >>>> #include >>>> #include >>>>=20 >>>> struct foo { >>>> _Atomic(int) one; >>>> _Atomic int two; >>>> atomic_int three; >>>> }; >>>>=20 >>>> And here is what that became after -E: >>>>=20 >>>> # 4 "bar.c" >>>> struct foo { >>>> _Atomic(int) one; >>>> _Atomic int two; >>>> atomic_int three; >>>> }; >>>>=20 >>>> So cdefs.h did not define _Atomic. >>>>=20 >>>> Ah, if I add '-std=3Dc99' then it does break. Code that wants to = use >>>> C11 atomics via should not be using -std=3Dc99. Try = this: >>>>=20 >>>> Index: lib/ofed/librdmacm/Makefile >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- lib/ofed/librdmacm/Makefile (revision 335896) >>>> +++ lib/ofed/librdmacm/Makefile (working copy) >>>> @@ -8,6 +8,7 @@ >>>> SHLIB_MAJOR=3D 1 >>>> MK_PROFILE=3D no >>>> CFLAGS+=3D -I${_spath} >>>> +CSTD=3D gnu11 >>>>=20 >>>> SRCS=3D \ >>>> acm.c \ >>>>=20 >>>> If this works then we should probably mark OFED as a BROKEN_OPTION = when >>>> building with ancient GCC for now as well. >>>=20 >>> I've "unreverted" to set up a context for testing this. >>>=20 >>> So far I'll I've done is to test that I can still reproduce the = failure >>> in my environment, same sort of error reports as ci.freebsd.org's >>> FreeBSD-head-amd64-gcc . This is without your patch. >>>=20 >>> But I've done this with gcc being given -v so that I've the exact = commands >>> and search order and the like. It does show: -std=3Dgnu99 . I list = the >>> filemon data from the .meta as well, showing the exact mix of >>> FreeBSD and gcc headers used. (I could also provide such for with >>> the reverted Makefile.{inc1,libcompat} [so non-failing] build if you >>> care.) >>>=20 >>>=20 >>> For now I just report the failure *without your patch*: >>> (I'll build again with your patch next.) >>>=20 >>> . . . >>> --- all_subdir_lib/ofed --- >>> Building = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o >>> --- acm.o --- >>> Using built-in specs. >>> COLLECT_GCC=3D/usr/local/bin/x86_64-unknown-freebsd12.0-gcc >>> Target: x86_64-unknown-freebsd12.0 >>> Configured with: = /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure = --target=3Dx86_64-unknown-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --enable-gnu-indirect-function = --without-headers --with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD = Ports Collection for amd64' --with-system-zlib = --with-gxx-include-dir=3D/usr/include/c++/v1/ --with-sysroot=3D/ = --with-as=3D/usr/local/bin/x86_64-unknown-freebsd12.0-as = --with-ld=3D/usr/local/bin/x86_64-unknown-freebsd12.0-ld = --enable-initfini-array --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ = --build=3Dx86_64-unknown-freebsd12.0 >>> Thread model: posix >>> gcc version 6.4.0 (FreeBSD Ports Collection for amd64)=20 >>> COLLECT_GCC_OPTIONS=3D'-B' = '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2' '-pipe' '-I' = '/usr/src/contrib/ofed/librdmacm' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wno-error=3Daddress' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dattributes' = '-Wno-error=3Dbool-compare' '-Wno-error=3Dcast-align' = '-Wno-error=3Dclobbered' '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' = '-Wno-error=3Dinline' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dstrict-aliasing' '-Wno-error=3Duninitialized' = '-Wno-error=3Dunused-but-set-variable' '-Wno-error=3Dunused-function' = '-Wno-error=3Dunused-value' '-Wno-error=3Dmisleading-indentation' = '-Wno-error=3Dnonnull-compare' '-Wno-error=3Dshift-negative-value' = '-Wno-error=3Dtautological-compare' '-Wno-error=3Dunused-const-variable' = '-v' '-c' '-o' 'acm.o' '-mtune=3Dgeneric' '-march=3Dx86-64' >>> /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet = -v -I /usr/src/contrib/ofed/librdmacm -isysroot = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp = /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c = -mtune=3Dgeneric -march=3Dx86-64 -auxbase-strip acm.o -g -O2 = -Wno-error=3Daddress -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dmisleading-indentation -Wno-error=3Dnonnull-compare = -Wno-error=3Dshift-negative-value -Wno-error=3Dtautological-compare = -Wno-error=3Dunused-const-variable -std=3Dgnu99 -version = -fstack-protector-strong -o - | >>> /usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I = /usr/src/contrib/ofed/librdmacm -o acm.o >>> GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) >>> compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none >>> GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 >>> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" >>> ignoring nonexistent directory = "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-un= known-freebsd12.0/include" >>> #include "..." search starts here: >>> #include <...> search starts here: >>> /usr/src/contrib/ofed/librdmacm >>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include >>> = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude >>> End of search list. >>> GNU assembler version 2.30 (x86_64-unknown-freebsd12.0) using BFD = version (GNU Binutils) 2.30 >>> GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 = (x86_64-unknown-freebsd12.0) >>> compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 = (tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none >>> GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 >>> Compiler executable checksum: 0b55436e4202650149cc2feb351f4e0e >>> In file included from /usr/src/contrib/ofed/librdmacm/cma.h:43:0, >>> from /usr/src/contrib/ofed/librdmacm/acm.c:42: >>> /usr/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >>> /usr/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid = initializer >>> atomic_store(&lock->cnt, 0); >>> ^ >>> In file included from /usr/src/contrib/ofed/librdmacm/acm.c:42:0: >>> /usr/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_acquire': >>> /usr/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_add' >>> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>> ^~ >>> /usr/src/contrib/ofed/librdmacm/cma.h: In function = 'fastlock_release': >>> /usr/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type = 'struct *' is incompatible with argument 1 of = '__atomic_fetch_sub' >>> if (atomic_fetch_sub(&lock->cnt, 1) > 1) >>> ^~ >>> *** [acm.o] Error code 1 >>>=20 >>> make[6]: stopped in /usr/src/lib/ofed/librdmacm >>> .ERROR_TARGET=3D'acm.o' >>> = .ERROR_META_FILE=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd6= 4.amd64/lib/ofed/librdmacm/acm.o.meta' >>> .MAKE.LEVEL=3D'6' >>> MAKEFILE=3D'' >>> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >>> _ERROR_CMD=3D'/usr/local/bin/x86_64-unknown-freebsd12.0-gcc = --sysroot=3D/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/= tmp -B/usr/local/x86_64-unknown-freebsd12.0/bin/ -O2 -pipe = -I/usr/src/contrib/ofed/librdmacm -g -std=3Dgnu99 = -fstack-protector-strong -Wno-error=3Daddress -Wno-error=3Darray-bounds = -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align = -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra = -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses = -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function = -Wno-error=3Dunused-value -Wno-error=3Dmisleading-indentation = -Wno-error=3Dnonnull-compare -Wno-error=3Dshift-negative-value = -Wno-error=3Dtautological-compare -Wno-error=3Dunused-const-variable = -v -c /usr/src/contrib/ofed/librdmacm/acm.c -o acm.o; ;' >>> .CURDIR=3D'/usr/src/lib/ofed/librdmacm' >>> .MAKE=3D'make' >>> = .OBJDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/l= ib/ofed/librdmacm' >>> .TARGETS=3D'all' >>> = DESTDIR=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/t= mp' >>> LD_LIBRARY_PATH=3D'' >>> MACHINE=3D'amd64' >>> MACHINE_ARCH=3D'amd64' >>> MAKEOBJDIRPREFIX=3D'' >>> MAKESYSPATH=3D'/usr/src/share/mk' >>> MAKE_VERSION=3D'20180512' >>> = PATH=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/= legacy/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.am= d64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/a= md64.amd64/tmp/legacy/bin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/sr= c/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/s= rc/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' >>> SRCTOP=3D'/usr/src' >>> = OBJTOP=3D'/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64' >>> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.amd64-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/ofed/librdmacm/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/lib/ofed/librdmacm/../Makefile.inc /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.symver.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk = /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' >>> .PATH=3D'. /usr/src/lib/ofed/librdmacm = /usr/src/contrib/ofed/librdmacm /usr/src/contrib/ofed/librdmacm/man' >>> 1 error >>>=20 >>> =46rom = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/lib= rdmacm/acm.o.meta >>> is the filemon data: >>>=20 >>> -- filemon acquired metadata -- >>> # filemon version 5 >>> # Target pid 95011 >>> # Start 1532652684.414953 >>> V 5 >>> E 95033 /bin/sh >>> R 95033 /etc/libmap.conf >>> R 95033 /var/run/ld-elf.so.hints >>> R 95033 /lib/libedit.so.7 >>> R 95033 /lib/libc.so.7 >>> R 95033 /lib/libncursesw.so.8 >>> F 95033 95034 >>> E 95034 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc >>> R 95034 /etc/libmap.conf >>> R 95034 /var/run/ld-elf.so.hints >>> R 95034 /usr/lib/libc++.so.1 >>> R 95034 /lib/libcxxrt.so.1 >>> R 95034 /lib/libm.so.5 >>> R 95034 /lib/libc.so.7 >>> R 95034 /lib/libgcc_s.so.1 >>> F 95034 95035 >>> E 95035 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 >>> F 95034 95036 >>> R 95035 /etc/libmap.conf >>> R 95035 /var/run/ld-elf.so.hints >>> R 95035 /usr/local/lib/libmpc.so.3 >>> R 95035 /usr/local/lib/libmpfr.so.6 >>> R 95035 /usr/local/lib/libgmp.so.10 >>> R 95035 /lib/libz.so.6 >>> R 95035 /usr/lib/libc++.so.1 >>> R 95035 /lib/libcxxrt.so.1 >>> R 95035 /lib/libm.so.5 >>> R 95035 /lib/libc.so.7 >>> R 95035 /lib/libgcc_s.so.1 >>> R 95035 /dev/urandom >>> R 95035 /usr/src/contrib/ofed/librdmacm/acm.c >>> E 95036 /usr/local/bin/x86_64-unknown-freebsd12.0-as >>> R 95036 /etc/libmap.conf >>> R 95036 /var/run/ld-elf.so.hints >>> R 95036 /lib/libc.so.7 >>> R 95036 acm.o >>> W 95036 acm.o >>> R 95035 /usr/src/contrib/ofed/librdmacm/config.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdio.h >>> R 95035 /usr/src/sys/sys/cdefs.h >>> R 95035 /usr/src/sys/sys/_null.h >>> R 95035 /usr/src/sys/sys/_types.h >>> R 95035 /usr/src/sys/amd64/include/_types.h >>> R 95035 /usr/src/sys/x86/include/_types.h >>> R 95035 /usr/src/sys/amd64/include/_limits.h >>> R 95035 /usr/src/sys/x86/include/_limits.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/inttypes.h >>> R 95035 /usr/src/sys/amd64/include/_inttypes.h >>> R 95035 /usr/src/sys/x86/include/_inttypes.h >>> R 95035 /usr/src/sys/sys/stdint.h >>> R 95035 /usr/src/sys/amd64/include/_stdint.h >>> R 95035 /usr/src/sys/x86/include/_stdint.h >>> R 95035 /usr/src/sys/amd64/include/_limits.h >>> R 95035 /usr/src/sys/sys/_stdint.h >>> R 95035 /usr/src/sys/sys/types.h >>> R 95035 /usr/src/sys/amd64/include/endian.h >>> R 95035 /usr/src/sys/x86/include/endian.h >>> R 95035 /usr/src/sys/sys/_pthreadtypes.h >>> R 95035 /usr/src/sys/sys/select.h >>> R 95035 /usr/src/sys/sys/_sigset.h >>> R 95035 /usr/src/sys/sys/_timeval.h >>> R 95035 /usr/src/sys/sys/timespec.h >>> R 95035 /usr/src/sys/sys/_timespec.h >>> R 95035 /usr/src/sys/sys/socket.h >>> R 95035 /usr/src/sys/sys/_iovec.h >>> R 95035 /usr/src/sys/amd64/include/_align.h >>> R 95035 /usr/src/sys/x86/include/_align.h >>> R 95035 /usr/src/sys/sys/_sockaddr_storage.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/netdb.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/unistd.h >>> R 95035 /usr/src/sys/sys/unistd.h >>> R 95035 /usr/src/contrib/ofed/librdmacm/cma.h >>> R 95035 /usr/src/contrib/ofed/librdmacm/config.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/stdlib.h >>> R 95035 /usr/src/sys/sys/errno.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/endian.h >>> R 95035 /usr/src/sys/sys/endian.h >>> R 95035 /usr/src/sys/amd64/include/endian.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/semaphore.h >>> R 95035 /usr/src/sys/sys/_umtx.h >>> R 95035 /usr/src/sys/amd64/include/_limits.h >>> R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/rdma/rdma_cma.h >>> R 95035 /usr/src/sys/netinet/in.h >>> R 95035 /usr/src/sys/amd64/include/endian.h >>> R 95035 /usr/src/sys/netinet6/in6.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/verbs.h >>> R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdint.h >>> R 95035 /usr/src/sys/sys/stdint.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/pthread.h >>> R 95035 /usr/src/sys/amd64/include/_limits.h >>> R 95035 /usr/src/sys/amd64/include/_types.h >>> R 95035 /usr/src/sys/sys/sched.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/time.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_time.h >>> R 95035 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stddef.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/string.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/strings.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_strings.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/xlocale/_string.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/types.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/sa.h >>> R 95035 = /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp/usr/incl= ude/infiniband/ib.h >>> R 95035 /usr/src/contrib/ofed/librdmacm/cma.h >>> X 95036 0 0 >>> X 95035 1 0 >>> D 95034 acm.o >>> X 95034 1 0 >>> X 95033 1 0 >>> # Stop 1532652684.494688 >>> # Bye bye >>>=20 >>>=20 >>>=20 >>> For reference the amd64-gcc is: >>>=20 >>> # pkg info amd64-gcc >>> amd64-gcc-6.4.0_1 >>> Name : amd64-gcc >>> Version : 6.4.0_1 >>> Installed on : Sun Jul 15 09:15:38 2018 PDT >>> Origin : devel/amd64-gcc >>> Architecture : FreeBSD:12:amd64 >>> Prefix : /usr/local >>> Categories : devel >>> Licenses : GPLv3, GPLv3RLE >>> Maintainer : kan@FreeBSD.org >>> WWW : http://gcc.gnu.org/ >>> Comment : Cross GNU Compiler Collection for amd64 >>> Shared Libs required: >>> libmpc.so.3 >>> libgmp.so.10 >>> libmpfr.so.6 >>> Shared Libs provided: >>> liblto_plugin.so.0 >>> Annotations : >>> FreeBSD_version: 1200069 >>> repo_type : binary >>> repository : custom >>> Flat size : 338MiB >>> Description : >>> GCC, the GNU Compiler Collection supporting C and C++ for targetting = crossbuilding. >>>=20 >>> WWW: http://gcc.gnu.org/ >>=20 >> With your patch it gets past that point of build failure. >>=20 >> But my devel/amd64-gcc predates the removal of float.h from >> the installed devel/amd64-gcc so the following may not be as >> it would be in such a context: >>=20 >> --- lib/msun__L --- >> /usr/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long = double format" >> #error "Unsupported long double format" >> ^~~~~ >> . . . >> --- lib/msun__L --- >> /usr/src/lib/msun/src/catrigl.c: In function 'casinhl': >> /usr/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared = (first use in this function) >> w =3D clog_for_large_values(z) + m_ln2; >> ^~~~~ >> /usr/src/lib/msun/src/catrigl.c:190:35: note: each undeclared = identifier is reported only once for each function it appears in >> /usr/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON' = undeclared (first use in this function) >> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) >> ^~~~~~~~~~~~~~ >> /usr/src/lib/msun/src/catrigl.c: In function 'cacosl': >> /usr/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared = (first use in this function) >> ry =3D creall(w) + m_ln2; >> ^~~~~ >> /usr/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON' = undeclared (first use in this function) >> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) >> ^~~~~~~~~~~~~~ >> In file included from /usr/src/lib/msun/src/catrigl.c:45:0: >>=20 >>=20 >>=20 >> I can remove float.h and see what happens. >=20 > While the build without gcc's float.h goes on, here are some small > experiments with interesting results (mostly these are with > -std=3Dgnu11): >=20 > # more AtomicTest.c=20 > // x86_64-unknown-freebsd12.0-gcc -v -E AtomicTest.c >=20 > #include > #include >=20 > struct foo { > _Atomic(int) one; > _Atomic int two; > atomic_int three; > }; >=20 >=20 >=20 > # x86_64-unknown-freebsd12.0-gcc -dM -std=3Dgnu11 -E AtomicTest.c | = grep has_ > #define __has_include(STR) __has_include__(STR) > #define __has_include_next(STR) __has_include_next__(STR) > #define __has_extension __has_feature > #define __has_builtin(x) 0 > #define __has_feature(x) 0 >=20 > (-std=3Dgnu99 matches the above) >=20 >=20 > # x86_64-unknown-freebsd12.0-gcc -dM -std=3Dgnu11 -E AtomicTest.c | = grep atomic_fetch > #define atomic_fetch_or(PTR,VAL) __atomic_fetch_or ((PTR), (VAL), = __ATOMIC_SEQ_CST) > #define atomic_fetch_or_explicit(PTR,VAL,MO) __atomic_fetch_or ((PTR), = (VAL), (MO)) > #define atomic_fetch_and_explicit(PTR,VAL,MO) __atomic_fetch_and = ((PTR), (VAL), (MO)) > #define atomic_fetch_sub_explicit(PTR,VAL,MO) __atomic_fetch_sub = ((PTR), (VAL), (MO)) > #define atomic_fetch_xor_explicit(PTR,VAL,MO) __atomic_fetch_xor = ((PTR), (VAL), (MO)) > #define atomic_fetch_add(PTR,VAL) __atomic_fetch_add ((PTR), (VAL), = __ATOMIC_SEQ_CST) > #define atomic_fetch_sub(PTR,VAL) __atomic_fetch_sub ((PTR), (VAL), = __ATOMIC_SEQ_CST) > #define atomic_fetch_and(PTR,VAL) __atomic_fetch_and ((PTR), (VAL), = __ATOMIC_SEQ_CST) > #define atomic_fetch_xor(PTR,VAL) __atomic_fetch_xor ((PTR), (VAL), = __ATOMIC_SEQ_CST) > #define atomic_fetch_add_explicit(PTR,VAL,MO) __atomic_fetch_add = ((PTR), (VAL), (MO)) >=20 > (-std=3Dgnu99 matches the above) >=20 >=20 > The following shows -std=3Dgnu99 vs. -std=3Dgnu11 results that do not > match: >=20 > # x86_64-unknown-freebsd12.0-gcc -E -std=3Dgnu99 AtomicTest.c | more > . . . > # 6 "AtomicTest.c" > struct foo { >=20 > # 7 "AtomicTest.c" 3 4 > struct {=20 > # 7 "AtomicTest.c" > int=20 > # 7 "AtomicTest.c" 3 4 > volatile __val; }=20 > # 7 "AtomicTest.c" > one; > _Atomic int two; > atomic_int three; > }; > . . . >=20 > # x86_64-unknown-freebsd12.0-gcc -E -std=3Dgnu11 AtomicTest.c | more > . . . >=20 > # 6 "AtomicTest.c" > struct foo { > _Atomic(int) one; > _Atomic int two; > atomic_int three; > }; > . . . >=20 > I will add a #warning where FreeBSD's cdefs.h has the #define = _Atomic(T) > to report on if the #define _Atomic(T) is being processed (but = possibly > ignored) for -std=3Dgnu11 . (But after the ongoing build stops.) >=20 I was looking too locally: the overall context has an outer #if as well that skips the section: /* * Keywords added in C11. */ =20 #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L . . . #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ !__has_extension(cxx_atomic) /* * No native support for _Atomic(). Place object in structure to prevent * most forms of direct non-atomic access. */ #define _Atomic(T) struct { T volatile __val; } #endif . . . #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */ The build with gcc's float.h also removed did complete instead of stopping early. As for what x86_64-unknown-freebsd12.0 .h files were used: (some may do include_next back into FreeBSD headers) # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R = .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; | sort -k 3 | uniq -f 2 | = more R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/adxintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ammintrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx2intrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512bwintrin= .h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512cdintrin= .h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512dqintrin= .h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512erintrin= .h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512fintrin.= h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmaintr= in.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmavlin= trin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512pfintrin= .h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmiintr= in.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmivlin= trin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlbwintr= in.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vldqintr= in.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlintrin= .h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avxintrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmi2intrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmiintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clflushoptintr= in.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clwbintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clzerointrin.h= R 56022 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/cpuid.h R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/emmintrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/f16cintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fma4intrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fmaintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fxsrintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ia32intrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/immintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lwpintrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lzcntintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm3dnow.h R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm_malloc.h R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mmintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mwaitxintrin.h= R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pkuintrin.h R 1336 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pmmintrin.h R 1485 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/popcntintrin.h= R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/prfchwintrin.h= R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rdseedintrin.h= R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rtmintrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/shaintrin.h R 1485 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/smmintrin.h R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdarg.h R 27622 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdbool.h R 10025 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stddef.h R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdint.h R 68604 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdnoreturn.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/tbmintrin.h R 1336 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/tmmintrin.h R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/wmmintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/x86intrin.h R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xmmintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xopintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsavecintrin.h= R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsaveintrin.h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsaveoptintrin= .h R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsavesintrin.h= R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xtestintrin.h =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 27 10:02:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B50351045671 for ; Fri, 27 Jul 2018 10:02:50 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 166428DABC; Fri, 27 Jul 2018 10:02:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Ltqb7-1gAWEH1fsr-0117Yl; Fri, 27 Jul 2018 12:02:40 +0200 Date: Fri, 27 Jul 2018 12:02:36 +0200 From: "O. Hartmann" To: Toomas Soome Cc: "O. Hartmann" , "Rodney W. Grimes" , freebsd-current , Allan Jude Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180727120232.270e1d9f@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:n1HjFkfKmUHVo98XryWYSyeRNXS4uE/jtugREKQNR1r2krsihef yNtS1IHoZnsSSg9qsRIegq4LGrQDM2m9Y6Ksm+fB2XxQp4EYp45i3cvOkVX3hxlBh7qAojG 1O54VnwsPrOvMCsxtmFM++lGLPbvqoW3FZam6DfUpd7Yby3qbrUtEc6wyRc7I8JCMQQX4Bd d3LLZR5NKIkOnIUD1YcxA== X-UI-Out-Filterresults: notjunk:1;V01:K0:+B7bj11Gldg=:JoFGIutZ9/OjbGBAARS4jJ VFl1vzp9DRyV30g/VtR3rcE9X6miZ+RLA+Cq4e5uTd1dBTeu6j4M3JGfK1oiBCICeBh5/Xqqh /mmnOEEZDQIUvqA7PPMZaZmspZW1OrDDAHBHM/49NBgxZFPq8QtekoAzgSy4kDxIAXhkNMjlR fofyGvWRv13MSzNafu26RVo/HQmVXWR1dmp7TuHPjacC8QagfEO0oD7DqPLbjM2ZCl9HAhzkI Ezvr6hKx+HtozSukHcbcrlDRcLJgDTULaW6sU4xpTcAEyZ/eiAdPPiX2H5h44lTJ5RUVZSXwO t8oe1V2c2A3Ee55P3PCEst0ejJjiCKZ958oRwPNpStLdoa7YhLzX71JWmAJOM5N4IUt6sVK4g RMPUFbCbMuUUtQm4lsgj973f0cH1JoEFybaxC0D+KRWNCDmwWuZEZ+D0f/bYeG6fTVPVFASV0 Rv5ZhVo90pdYWOiZaADaP1Xt1hAsAJUMsPWQ2ddEehE63zUlmZ4Sy7+kz83L1TOAoTSqPS/H8 G9vJGpCBbXVikQcQ+yER0XeorqAJd/YQsqdQEl1YdXlBlfNpN8k+rIHmIKF3mgMBh30YRbUsD h9dnC6HyHxZOLY49kzpS5/OlGJlyp5kn1Jf9/NZREIAHxkc2VoFLKuBAZPWl0tr48A6NYazl0 qnHRuRsuw9fkfV86KNxKG632fYEF6uYO0GjrjcBqilkttENx65zyYvyNVkVVqZvvOrvMS15Ek I2qI34x6QAH8FLHkstWJ+KtZS3Q6msiPJUeu/r3vsWechsDjZmdCo6bjsm+gSSJm1HwbJQx7D UGrjhn/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 10:02:51 -0000 On Fri, 27 Jul 2018 08:54:48 +0300 Toomas Soome wrote: > > On 27 Jul 2018, at 08:46, O. Hartmann wrote: > >=20 > > On Thu, 26 Jul 2018 19:23:43 +0300 > > Toomas Soome wrote: > >=20 > > (reply inline/at the end) > >=20 > > =20 > >>> On 26 Jul 2018, at 16:58, O. Hartmann wrote: > >>>=20 > >>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT) > >>> "Rodney W. Grimes" >>> > wrote: =20 > >>>>>> On 25 Jul 2018, at 12:10, O. Hartmann wr= ote: > >>>>>>=20 > >>>>>> On Wed, 25 Jul 2018 11:46:07 +0300 > >>>>>> Toomas Soome wrote: > >>>>>> =20 > >>>>>>>> On 25 Jul 2018, at 10:59, O. Hartmann w= rote: > >>>>>>>>=20 > >>>>>>>> On Tue, 24 Jul 2018 08:53:36 +0300 > >>>>>>>> Toomas Soome wrote: > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> Hello Toomas Soome, > >>>>>>>>=20 > >>>>>>>> I CC Allan Jude since I discovered something weird today regard= ing > >>>>>>>> the UEFI boot capabilities of USB flash devices and SSDs. See be= low. > >>>>>>>> =20 > >>>>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann > >>>>>>>>>> wrote: > >>>>>>>>>>=20 > >>>>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300 > >>>>>>>>>> Toomas Soome wrote: > >>>>>>>>>> =20 > >>>>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 > >>>>>>>>>>>> Toomas Soome > wrote: > >>>>>>>>>>>> =20 > >>>>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann >>>>>>>>>>>>>> > wrote: > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>>>>>>>>> Hash: SHA512 > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 > >>>>>>>>>>>>>> Toomas Soome > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> schrieb: =20 > >>>>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot prob= lems > >>>>>>>>>>>>>>>> on GPT drives where the first partition begins at block = 40 > >>>>>>>>>>>>>>>> of the hdd/ssd. > >>>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>>> I have two host in private use based on an > >>>>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBr= idge, > >>>>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the lates > >>>>>>>>>>>>>>>> official available AMI firmware revision, dating to 2013. > >>>>>>>>>>>>>>>> This is for the Z77-Pro4-M revision 2.0 (2013/7/23) and = for > >>>>>>>>>>>>>>>> the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a > >>>>>>>>>>>>>>>> BETA revision for the Spectre/Meltdown mitigation is > >>>>>>>>>>>>>>>> available, but I didn't test that. But please read. > >>>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>>> The third box I realised this problem is a brand new Fuj= itsu > >>>>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 f= or > >>>>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525). > >>>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via > >>>>>>>>>>>>>>>> bsdinstall the OS using UEFI-only boot method on a GPT > >>>>>>>>>>>>>>>> partitioned device fails. The ASRock boards jump immedia= tely > >>>>>>>>>>>>>>>> into the firmware, the Fujitsu offers some kind of > >>>>>>>>>>>>>>>> CPU/Memory/HDD test facility. > >>>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI > >>>>>>>>>>>>>>>> boot only is implied, the MBR partitioned FreeBSD > >>>>>>>>>>>>>>>> installation USB flash device does boot in UEFI! I guess= I > >>>>>>>>>>>>>>>> can assume this when the well known clumsy 80x25 char > >>>>>>>>>>>>>>>> console suddenly gets bright and shiny with a much higher > >>>>>>>>>>>>>>>> resoltion as long the GPU supports EFI GOP. Looking with > >>>>>>>>>>>>>>>> gpart at the USB flash drives reveals that the EFI parti= tion > >>>>>>>>>>>>>>>> starts at block 1 of the device and the device has a MBR > >>>>>>>>>>>>>>>> layout. I haven't found a way to force the GPT scheme, w= hen > >>>>>>>>>>>>>>>> initialised via gpart, to let the partitions start at bl= ock > >>>>>>>>>>>>>>>> 1. This might be a naiv thinking, so please be patient w= ith > >>>>>>>>>>>>>>>> me. > >>>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>>> I do not know whether this is a well-known issue. On the > >>>>>>>>>>>>>>>> ASRock boards, I tried years ago some LinuxRed Hat and S= use > >>>>>>>>>>>>>>>> with UEFI and that worked - FreeBSD not. I gave up on th= at > >>>>>>>>>>>>>>>> that time. Now, having the very same issues with a new > >>>>>>>>>>>>>>>> Fujitsu system, leaves me with the impression that FreeB= SD's > >>>>>>>>>>>>>>>> UEFI implementation might have problems I'm not aware of. > >>>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>>> Can someone shed some light onto this?=20 > >>>>>>>>>>>>>>>> =20 > >>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>> The first thing to check is if the secure boot is disable= d. We > >>>>>>>>>>>>>>> do not support secure boot at all at this time. = =20 > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> Secure boot is in every scenario disabled! > >>>>>>>>>>>>>> =20 > >>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>> If you have efi or bios version running - you can check f= rom > >>>>>>>>>>>>>>> either console variable value (it can have efi or vidcons= ole > >>>>>>>>>>>>>>> or comconsole) or better yet, see if efi-version is set (= show > >>>>>>>>>>>>>>> efi-version) - if efi-version is not set, it is BIOS load= er > >>>>>>>>>>>>>>> running. Another indirect way is to see lsdev -v, with de= vice > >>>>>>>>>>>>>>> paths present, it is uefi:) =20 > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> What are you talking about? > >>>>>>>>>>>>>> What is the point of entry - running system, loader? > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> sysct machdep.bootmethod: BIOS > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> This makes me quite sure that the system has booted via BI= OS - > >>>>>>>>>>>>>> as I'm sure since I've checked that many times. UEFI doesn= 't > >>>>>>>>>>>>>> work on those systems with FreeBSD. I'm not sure antmore, = but > >>>>>>>>>>>>>> I tried also Windows 7 on those mainboards booting via UEF= I - > >>>>>>>>>>>>>> and I might recall that they failed also. I also recall th= at > >>>>>>>>>>>>>> there were issues with earlier UEFI versions regarding boo= ting > >>>>>>>>>>>>>> only Windows 8/8.1 - and nothing else, but the fact that L= inux > >>>>>>>>>>>>>> worked confuses me a bit. > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> If this ASRock crap (never ever again this brand!) doesn't= work > >>>>>>>>>>>>>> at all - who cares, I intend to purchase new server grade > >>>>>>>>>>>>>> hardware. But the more puzzling issue is with the Fujitsu, > >>>>>>>>>>>>>> which I consider serious and from the behaviour the Fujitsu > >>>>>>>>>>>>>> failure looks exactly like the ASRock - Windows 7 works, > >>>>>>>>>>>>>> RedHat 7.5 works (I assume I can trust the Firmware settin= gs > >>>>>>>>>>>>>> when I disable CSM support, that the Firmware will only > >>>>>>>>>>>>>> EFI/UEFI capable loader? Or is there a ghosty override > >>>>>>>>>>>>>> somwhere to be expected?). Also on ASRock disabling CSM sh= ould > >>>>>>>>>>>>>> ensure not booting a dual-bootstrap-capable system. This s= aid, > >>>>>>>>>>>>>> on the recent Fujitsu, it seems to boil down to a FreeBSD > >>>>>>>>>>>>>> UEFI-firmware interaction problem, while the ASRock is sti= ll > >>>>>>>>>>>>>> under suspicion to be broken by design. =20 > >>>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>>> GPT partitions can never start from disk absolute sector = 1; > >>>>>>>>>>>>>>> this is because at sector 0 there is MBR (for compatibili= ty), > >>>>>>>>>>>>>>> sector 1 is GPT table and then sectors 2-33 have GPT > >>>>>>>>>>>>>>> partition table entries, so the first possible data secto= r is > >>>>>>>>>>>>>>> 34 (absolute 34). Thats assuming 512B sectors. For details > >>>>>>>>>>>>>>> see UEFI 2.7 Chapter 5.3.1 page 131. =20 > >>>>>>>>>>>>>>=20 > >>>>>>>>>>>>>> Thanks for the explanation. That implies the installer did > >>>>>>>>>>>>>> right, gpart did also right and therefore there must be an > >>>>>>>>>>>>>> issue with the stuff located within the EFI > >>>>>>>>>>>>>> partition? =20 > >>>>>>>>>>>>>=20 > >>>>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we r= each > >>>>>>>>>>>>> BIOS loader at all or not - that is, if the BIOS bootstrap = is > >>>>>>>>>>>>> actually caring to read the MBR code and start it, since on= ce > >>>>>>>>>>>>> the MBR code is started, it is all about our code. = =20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the C= SM? > >>>>>>>>>>>> or do you mean that specific portion of the UEFI firmware, w= hich > >>>>>>>>>>>> looks for the proper UEFI partition? > >>>>>>>>>>>> =20 > >>>>>>>>>>>=20 > >>>>>>>>>>> BIOS as either native or CSM. Note that from boot code point = of > >>>>>>>>>>> view the CSM boot *is* BIOS boot, we have no access to UEFI > >>>>>>>>>>> features.=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> The boxes in question, most notably the more recent Fujitsu > >>>>>>>>>>>> Esprimo Q956, refuse booting UEFI, even if properly setup (in > >>>>>>>>>>>> terms of what FreeBSD provides on recent CURRENT) is applied= and > >>>>>>>>>>>> CSM is switched off in the firmware. Again: GPT partition sc= heme. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> The system boots properly if a second partition of type > >>>>>>>>>>>> "freebsd-boot" is applied and bootcode is properly applied v= ia > >>>>>>>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" (a= da0 > >>>>>>>>>>>> is the device). =20 > >>>>>>>>>>>>>=20 > >>>>>>>>>>>>> btw, you can try to validate the installed boot blocks by u= sing > >>>>>>>>>>>>> recent enough loader (usb or iso) and then you can use from= OK > >>>>>>>>>>>>> prompt: =20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> lsdev provides me with the follwoing informations (CSM enabl= ed): > >>>>>>>>>>>>=20 > >>>>>>>>>>>> OK lsdev > >>>>>>>>>>>> disk devices: > >>>>>>>>>>>> disk0: BIOS DRIVE C ... > >>>>>>>>>>>>=20 > >>>>>>>>>>>> disk0p1: EFI > >>>>>>>>>>>> disk0p2: FreeBSD BOOT > >>>>>>>>>>>> disk0p3: FreeBSD SWAP > >>>>>>>>>>>> disk0p4: FreeBSD ZFS > >>>>>>>>>>>> zfs devices: > >>>>>>>>>>>> zfs:zroot > >>>>>>>>>>>>=20 > >>>>>>>>>>>> OK chain disk0 > >>>>>>>>>>>> open failed (so for disk0p{1-4}. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> OK chain zroot > >>>>>>>>>>>> failed to read disk (just for completeness) =20 > >>>>>>>>>>>=20 > >>>>>>>>>>>=20 > >>>>>>>>>>> chain command does use only device name (such as disk0: or > >>>>>>>>>>> disk0p2: ), but not zfs pool as device. I just found I haven= ?t > >>>>>>>>>>> ported the code to read the file. =20 > >>>>>>>>>>=20 > >>>>>>>>>> ?? > >>>>>>>>>> =20 > >>>>>>>>>>>=20 > >>>>>>>>>>> the point for chain command test is to see if the normal read= and > >>>>>>>>>>> execute would work, so in your case please try: > >>>>>>>>>>>=20 > >>>>>>>>>>> chain disk0: =20 > >>>>>>>>>>=20 > >>>>>>>>>> As stated above, I did so, and the result is also mentioned ab= ove, > >>>>>>>>>> I always get "open failed". > >>>>>>>>>> This is the same for=20 > >>>>>>>>>>=20 > >>>>>>>>>> chain disk0 > >>>>>>>>>> chain disk0p1 > >>>>>>>>>> chain disk0p2 > >>>>>>>>>> chain disk0p3 > >>>>>>>>>> chain disk0p4 > >>>>>>>>>>=20 > >>>>>>>>>> as already said. CSM is enabled in this case. =20 > >>>>>>>>>=20 > >>>>>>>>> sigh? chain command does take device as argument, device must a= lways > >>>>>>>>> end with colon?. in this case, the devil is in details:) as I w= rote > >>>>>>>>> above, the command should be: > >>>>>>>>>=20 > >>>>>>>>> chain disk0: > >>>>>>>>>=20 > >>>>>>>>> The disk0p1: etc will only work when partition boot code was > >>>>>>>>> installed (which you most likely do not have - the only possible > >>>>>>>>> candidate could be FreeBSD ZFS partition). =20 > >>>>>>>>=20 > >>>>>>>> The command "chain disk0:" works as expected (CSM enabled, GPT > >>>>>>>> partition scheme, but with PMBR bootblock installed and freebsd-= boot > >>>>>>>> partition conatining gptzfsboot installed. > >>>>>>>>=20 > >>>>>>>> =20 > >>>>>>>>> =20 > >>>>>>>>>> =20 > >>>>>>>>>>>=20 > >>>>>>>>>>> to read pmbr (512B) and execute it. The expected outcome woul= d be > >>>>>>>>>>> that pmbr boot code would browse the GPT, read stage1 from > >>>>>>>>>>> disk0p2: and execute it; stage1 would detect FreeBSD ZFS from > >>>>>>>>>>> disk0p4: and load and execute /boot/loader. If that will happ= en, > >>>>>>>>>>> it means the boot code in our stages is just fine, but the bi= os > >>>>>>>>>>> (CSM) does not load pmbr?. if thats true, it would mean that= you > >>>>>>>>>>> either need to use UEFI boot or need to have some hack to fool > >>>>>>>>>>> the BIOS or just not use GPT on that machine with CSM. = =20 > >>>>>>>>>>=20 > >>>>>>>>>> To make it clear here: The only way to boot this box is using = CSM > >>>>>>>>>> (as it is the same with the ASRock boards mentioned earlier). = But > >>>>>>>>>> my intention is to disable CSM and use a GPT/UEFI environment > >>>>>>>>>> only! And GPT/UEFI doesn't work with FreeBSD, neither with > >>>>>>>>>> 12-CURRENT, nor 11.2-RELENG. > >>>>>>>>>>=20 > >>>>>>>>>> It would be nice if this could be fixed. I'm more interested i= n the > >>>>>>>>>> fix on the recent Fujitsu device than the outdated ASRock crap= , but > >>>>>>>>>> if the fix for the Fujitsu Firmware could fix older issues as a > >>>>>>>>>> byproduct, I'd appreciate that. > >>>>>>>>>>=20 > >>>>>>>>>> Kind regards, > >>>>>>>>>> =20 > >>>>>>>>>=20 > >>>>>>>>> ok, somehow I have lost that part of the discussion. Well, you = wrote > >>>>>>>>> that the UEFI boot fails when the first partition starts from s= ector > >>>>>>>>> 40 - does it mean you have boot when the partition will start f= rom > >>>>>>>>> some other sector? I think, there is something else going > >>>>>>>>> on. =20 > >>>>>>>>=20 > >>>>>>>> Well, I simply try to describe what I "see" to make things > >>>>>>>> disambiguous. I'm not familiar with the deeper insights of disk > >>>>>>>> layouts on a binary level. So, you explained to me the reason, w= hy > >>>>>>>> ESP (EGI partition) starts at block 40. I compared that to the > >>>>>>>> FreeBSD USB flash image FreeBSD provides, but this is another st= ory > >>>>>>>> since the image uses MBR scheme as I figured out. > >>>>>>>>=20 > >>>>>>>> =20 > >>>>>>>>>=20 > >>>>>>>>> What you can do is to see if that firmware will offer you EFI s= hell > >>>>>>>>> option, from there you can try to start the bootx64.efi manuall= y and > >>>>>>>>> see what error you will get. However, the number 1 cause for fa= iling > >>>>>>>>> to start the bootloader in UEFI is secure boot - we do not supp= ort > >>>>>>>>> it and secure boot must be switched off.=20 > >>>>>>>>>=20 > >>>>>>>>> However, they seem to claim "The Secure Boot option is availabl= e in > >>>>>>>>> the UEFI/BIOS of most if not all ASRock boards. It is disabled = by > >>>>>>>>> default.?=20 > >>>>>>>>>=20 > >>>>>>>>> Still suggest to double check if thats really the case. Also, i= f the > >>>>>>>>> bootx64.efi start will fail and no messages are appearing on sc= reen, > >>>>>>>>> then either there is something in firmware logs or you could get > >>>>>>>>> them from trying to start bootx64.efi from UEFI shell. =20 > >>>>>>>>=20 > >>>>>>>> Since I'm with this problem since 2014 and try from time to time= , be > >>>>>>>> ausred that I tried every possible permutationof all reasonable > >>>>>>>> options, even those nonsense, to get rid of that problem. > >>>>>>>>=20 > >>>>>>>> I never had any problems with any other UEFI capable > >>>>>>>> server/workstation firmware so far booting FreeBSD off in > >>>>>>>> UEFI-native (GPT partition scheme, CSM disabled) so far - until = now, > >>>>>>>> when I ran into this Fujitsu ESPRIMO Q956 with the most recent > >>>>>>>> firmware (as of lat week, week 29 of 2018) having the very same > >>>>>>>> problems.=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> I figured out something strange on the Fujitsu - and that is the= same > >>>>>>>> with the ASRock boards. > >>>>>>>>=20 > >>>>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a very = small > >>>>>>>> appliance, but nevertheless, the USB flash device is booted on > >>>>>>>> Fujitsu servers with UEFI-only configurations. I assume at this > >>>>>>>> point that disabling on the most recent Fujitsu firmwares on > >>>>>>>> reasonable "new" hardware (not older than three years) will disa= ble > >>>>>>>> any(!) legacy BIOS capabilities. The same is assumed for the Fuj= itus > >>>>>>>> ESPRIMO Q956. I can not speak for the ASRock A77 Pro4/m boards > >>>>>>>> mentioned above/earlier, they are from 2012/2013 and "quite old". > >>>>>>>>=20 > >>>>>>>> The NanoBSD image of ours doesn't have a "freebsd-boot" partitio= n. > >>>>>>>> The partition scheme of the flash device is GPT. The layout looks > >>>>>>>> like this: > >>>>>>>>=20 > >>>>>>>> gpart show -l da4 =20 > >>>>>>>> =3D> 40 15425456 da4 GPT (7.4G) =20 > >>>>>>>> 40 2000 1 efiboot0 (1.0M) > >>>>>>>> 2040 1453584 3 disk1a (710M) > >>>>>>>> 1455624 4096 5 disk3 (2.0M) > >>>>>>>> 1459720 13965776 - free - (6.7G) > >>>>>>>>=20 > >>>>>>>> I created the flash with md, gpart and dd straightforward, efibo= ot0 > >>>>>>>> is the ESP partition and its format/content is created via dd > >>>>>>>> if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is very= simple. > >>>>>>>>=20 > >>>>>>>> This USB flash device boots(!) successfully (UEFI!) on both the > >>>>>>>> ASRock boards and the Esprimo Q956! > >>>>>>>>=20 > >>>>>>>> But any SSD prepared the same way doesn't. Why?=20 > >>>>>>>>=20 > >>>>>>>> On the ASRock, I recall having fiddled around with HDD also for a > >>>>>>>> while conatining Windows 7/SP1 and FreeBSD. Windows7 booted, Fre= eBSD > >>>>>>>> - I can't remember.=20 > >>>>>>>>=20 > >>>>>>>> In the lack of proper hardware I'm unable to check whether > >>>>>>>> USB-attached HDD or SSD will boot or HDD will boot (just in case= the > >>>>>>>> local SATA has problems booting UEFI and USB not). > >>>>>>>>=20 > >>>>>>>> Kind regards, > >>>>>>>>=20 > >>>>>>>> Oliver=20 > >>>>>>>> =20 > >>>>>>>=20 > >>>>>>> Am. well. I think the suggestion to test out FAT32 is still good = one > >>>>>>> to test. This is because it is known that some vendors do not sup= port > >>>>>>> booting FAT12/FAT16 from HDD (the likely reason is that UEFI > >>>>>>> specification does not tell which FAT must be supported, and only= hint > >>>>>>> about FAT12/FAT16 in context of removable devices). =20 > >>>>>>=20 > >>>>>> I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO Q95= 6. It > >>>>>> took me a time to circumvent the installer and I had to install the > >>>>>> system manually. In that strain, I also "tried" to establish the E= SP > >>>>>> with FAT32, as Allen Jude suggested earlier. I didn't find any ad = hoc > >>>>>> help how to find out the format (FAT12/16/32) of the ESP, so I ass= ume > >>>>>> when using 12-CURRENT's or 11.2-RELENG's installer with AUTO-ZFS a= nd > >>>>>> GPT (UEFI) (only!) the resulting ESP is FAT12 or FAT16 (300mb by > >>>>>> default). I also assume, that when dd'ing the /boo/boot1.efifat im= age > >>>>>> to a partition, the format is FAT, but not FAT32. Therefore, I > >>>>>> refomatted the manually created ESP (using "gpart add -t efi ...") > >>>>>> using "newfs_msdos -F 32 -b xxx ...". I had to fiddle around a bit > >>>>>> with option -b to fit in a proper format to meet a 512mb ESP - I'm= not > >>>>>> sure whether this is the proper option to deal with. When using the > >>>>>> default and only -F32, the size of the partition has to be 4G at l= east > >>>>>> I assume. Having done that, I copied the the content of boot1.efif= at > >>>>>> (mdconfig -t vnode ..., I guess we know the drill ...) to the newly > >>>>>> formatted ESP to /boot/efi/ ... > >>>>>>=20 > >>>>>> Having so far no knowledge of how to asure that the created ESP is > >>>>>> FAT32, I assume it is FAT32. > >>>>>>=20 > >>>>>> The result is negative on the ESPRIMO Q956. When disabling the CSM= , the > >>>>>> box is not willing to boot from SSD with the ESP prepared as decri= bed. > >>>>>> So, a chance that this might still be due to a misconfiguration li= es > >>>>>> now within the -b option of newfs_msdos - if the -b option is assu= med > >>>>>> the proper option? > >>>>>>=20 > >>>>>> At the moment, the ESP of the Esprimo is subject to changes, if you > >>>>>> wish, but not in size, since it is limited to 512mb. > >>>>>>=20 > >>>>>> Thanks and kind regards, > >>>>>>=20 > >>>>>> Oliver =20 > >>>>>=20 > >>>>> Yea, i was hoping fstyp command would report the FAT type, but it d= oes > >>>>> not (request for feature?:) =20 > >>>>=20 > >>>> FYI, the file(1) command is very good at disecting a disk image to t= ell > >>>> you what the MBR looks like, and at looking at partitions if pointed= at > >>>> them with the -s option. It should be able to detect FAT12/16/32. > >>>>=20 > >>>> root@x230a:/home/ISO/x # file -s /dev/md2s1 > >>>> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 = ", > >>>> root entries 512, sectors 1600 (volumes <=3D32 MB) , sectors/FAT 5, > >>>> sectors/track 63, heads 1, serial number 0xbd4111ee, label: "EFISYS > >>>> ", FAT (12 bit), followed by FAT > >>>> =20 > >>>>>=20 > >>>>> However, the more annoying idea would be to install some OS which w= ill > >>>>> boot with UEFI on this machine, then copy boot1.efi from freebsd to= it > >>>>> (the default program the UEFI will load is ESP:EFI/boot/bootx64.efi= in > >>>>> case of UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, we= do > >>>>> not support EFI32. > >>>>>=20 > >>>>> note that boot1.efi alone will not do much but printing on screen h= ow it > >>>>> will search for freebsd, but for the purpose of the test it would > >>>>> suffice > >>>>> - that would give us confirmed working ESP file system (since the o= ther > >>>>> os would be able to boot) and then we can confirm if boot1.efi itse= lf is > >>>>> OK. =20 > >>>> =20 > >>>=20 > >>> Some new results. > >>> I installed RedHat 7.5 and inestigated the ESP. > >>>=20 > >>> - The ESP starts at block 2048, while FreeBSD's ESP starts at block 4= 0. > >>> - size is both 200mb if installed automatically. I forgit to investig= ate > >>> the FAT format, but this might be unnecessary as shown further in this > >>> post. > >>> - RedHat's ESP contains ~ 10 MB of data in two > >>> folders, /efi/boot, /efi/redhat. copying FreeBSD's BOOTX64.efi over > >>> RedHat's doesn't change anything, also renaming /efi/boot/fbx64.efi of > >>> RedHat's installation. But renaming /efi/redhat renders RedHat to fai= l the > >>> boot process on the Fujitsu with the signs of the built-in testprogra= m as > >>> reported. > >>>=20 > >>> I took the liberty and installed 11.2-RELENG again, ZFS only, UEFI bo= ot > >>> only (CSM in firmware disabled, but there is still a gptzfsboot-prepa= red > >>> partition for later use, just for the record). Booting UEFI-only fail= s as > >>> reported. On this installation I copied the RedHat ESP completely into > >>> FreeBSD's ESP, renamed /efi/boot/BOOTX64.efi to /efi/boot/BOOTX64.efi= .rh > >>> and copied FreeBSD's BOOTX64.efi to /efi/boot.=20 > >>> The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, that > >>> the /efi/redhat folder of the ESP is important, if renamed, the whole > >>> process dies as I reported earlier. > >>>=20 > >>> Still unanswered is the question: why is a NanoBSD prepared UEFI-only= USB > >>> flash booting with CSM disabled (so asumingly UEFI only then) on both > >>> ASRock and Fujitsu (as described in more detail initially and earlier= ), > >>> while SSDs fail? Is there a difference? Since FreeBSD boots in UEFI m= ode > >>> from USB flash prepared as described (straight forward, 800k ESP star= ting > >>> at block 40, the boot1.efifat image dd'ed onto the partition, UFS > >>> partition following, no freebsd-boot partition or MBR/PMBR bootcode > >>> applied ever!), I think BOOTX64.EFI is technically all right. There m= ust > >>> be then an issue with the SATA/SSD/HDD boot pathway. > >>>=20 > >>> Hope I could provide some more details, sorry if it sounds confusing = or > >>> way too long, but I try to descibe the situation as thorough as possi= ble. > >>> =20 > >>=20 > >> OK, this is already good hint. The thing with ESP is that there is > >> =E2=80=9Cdefault=E2=80=9D file system tree: EFI/BOOT/BOOT.EFI= , this is noted as > >> default for *removable* media, fortunately it is usable for hard disks= as > >> well, or at least in most cases. > >>=20 > >> Now, for non-removable media, the UEFI does provide boot manager inter= face > >> to define boot entries, and the fact that renaming efi/redhad director= y did > >> break the redhat boot, is very loud hint. And this means, this system = is > >> probably ignoring efi/boot tree on non-removable media and is expectin= g the > >> boot manager entry to be created instead. =20 > >=20 > > This inplication I'd confirm for the recent Fujitsu ESPRIMO Q956 firmwa= re > > (not tested on ASRock Z77-Pro4 firmware). > > =20 > >>=20 > >> UEFI boot manager can be configured /usually/ manually via firmware me= nu, > >> or by application, such as efibootmgr. The normal approach is to create > >> efi/ directory and to copy the application there, then cre= ate > >> the boot manager configuration. > >>=20 > >> See UEFI specification v2.7, chapter 3 Boot Manager, page 79. > >>=20 > >> What is different in FreeBSD case is that the whole interface to progr= am > >> the UEFI Boot Manager is currently being developed, so either it has t= o be > >> done manually or from some other OS (see > >> https://wiki.gentoo.org/wiki/Efibootmgr > >> for example, first hit from > >> google:D). =20 > >=20 > > Well, thanks for this important hint! FreeBSD 12-CURRENT's and FreeBSD > > 11.2-RELENG's USB flash devices are capable of booting off on Fujitsu's > > ESPRIMO and ASRock's boards. As a note: after "kldload efirt.ko" I was = able > > to use the already in FreeBSD present toolset efibootmgr(8) and sibblin= gs > > (the tools do not do anything useful when booted non-UEFI). > >=20 > > Mounting the ESP of the harddrive (in my case, ada0p1) to /mnt and foll= owing > > the steps in the examples and having created /efi/freebsd/BOOTx64.efi as > > recommended by copy from /efi/boot, let me create a proper boot variabl= e. > >=20 > > To make things sure, I also applied "efibootmgr -a VARIABLENAME". > >=20 > > And ... it worked! Yes, it worked! The ESP is FAT32 formatted, I do not= know > > whether this will also work with FAT12/16, I should test this case, too. > >=20 > > There is a bug in the manpage of efibootmg(8). It does not explain the > > options -d and -p, although they could be "implied" by reading carefull= y. > > There is now a PR at=20 > >=20 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230080 > >=20 > > for this issue. > >=20 > > So, it's apity that the handbook has no note I could easily find on thi= s;=20 > >=20 > > Thank you very much for your patience and help! > >=20 > > Kind regards, > > Oliver =20 >=20 > yep, efibootmgr does call UEFI RuntimeServices to set up the variables, a= nd > this is only possible when booted UEFI. But glad we finally found the root > cause. It would be good to have HW notes for such cases, it is important = to > know that those systems wont boot UEFI from HDD unless the boot manager s= etup > is done. >=20 > rgds, > toomas This pops up the question how to deal with such HW. We have as a institutio= n a lot of Fujitsu hardware her - from larger servers down to Fujitsu ESPRIMO Q= 956. The latter one is the first (and so far the only) piece of hardware I found incapable of booting off UEFI within the past 5 years. If the "standard" for removeable devices is to boot from /efi/boot/bootx64.= efi, than I'd guess it is good luck for FreeBSD that the firmware vendors did fallback to such a mechanism. GRUB/Linux seem to install by default their bootloader into /efi/something/ I'll check on Debian, Suse and CentOS so far soon, the latter probably will, since its the "free" RedHat). Anyway, apart from any criticism, I'm glad to have the tools to make things work without using alien help (outside FreeBSD's world!). That is a thank y= ou towards the developers. Kind regards, oh From owner-freebsd-current@freebsd.org Fri Jul 27 10:59:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6331C10466F1 for ; Fri, 27 Jul 2018 10:59:50 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 0F0468F6C4; Fri, 27 Jul 2018 10:59:50 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PCI00500UIH9500@st13p35im-asmtp001.me.com>; Fri, 27 Jul 2018 10:59:49 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PCI00EZNUJLCD40@st13p35im-asmtp001.me.com>; Fri, 27 Jul 2018 10:59:49 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-27_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=7 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807270115 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations From: Toomas Soome In-reply-to: <20180727120232.270e1d9f@freyja.zeit4.iv.bundesimmobilien.de> Date: Fri, 27 Jul 2018 13:59:44 +0300 Cc: "Rodney W. Grimes" , freebsd-current , Allan Jude Content-transfer-encoding: quoted-printable Message-id: <2A5E5E42-8595-44E9-A51E-504C9C2C7FA7@me.com> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> <20180727120232.270e1d9f@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 10:59:50 -0000 > On 27 Jul 2018, at 13:02, O. Hartmann wrote: >=20 > On Fri, 27 Jul 2018 08:54:48 +0300 > Toomas Soome wrote: >=20 >>> On 27 Jul 2018, at 08:46, O. Hartmann = wrote: >>>=20 >>> On Thu, 26 Jul 2018 19:23:43 +0300 >>> Toomas Soome wrote: >>>=20 >>> (reply inline/at the end) >>>=20 >>>=20 >>>>> On 26 Jul 2018, at 16:58, O. Hartmann = wrote: >>>>>=20 >>>>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT) >>>>> "Rodney W. Grimes" >>>> > wrote: =20 >>>>>>>> On 25 Jul 2018, at 12:10, O. Hartmann = wrote: >>>>>>>>=20 >>>>>>>> On Wed, 25 Jul 2018 11:46:07 +0300 >>>>>>>> Toomas Soome wrote: >>>>>>>>=20 >>>>>>>>>> On 25 Jul 2018, at 10:59, O. Hartmann = wrote: >>>>>>>>>>=20 >>>>>>>>>> On Tue, 24 Jul 2018 08:53:36 +0300 >>>>>>>>>> Toomas Soome wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hello Toomas Soome, >>>>>>>>>>=20 >>>>>>>>>> I CC Allan Jude since I discovered something weird today = regarding >>>>>>>>>> the UEFI boot capabilities of USB flash devices and SSDs. See = below. >>>>>>>>>>=20 >>>>>>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann = >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300 >>>>>>>>>>>> Toomas Soome wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 >>>>>>>>>>>>>> Toomas Soome > = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann = >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>>>>>>>> Hash: SHA512 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 >>>>>>>>>>>>>>>> Toomas Soome >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> schrieb: =20 >>>>>>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot = problems >>>>>>>>>>>>>>>>>> on GPT drives where the first partition begins at = block 40 >>>>>>>>>>>>>>>>>> of the hdd/ssd. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I have two host in private use based on an >>>>>>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard = (IvyBridge, >>>>>>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the = lates >>>>>>>>>>>>>>>>>> official available AMI firmware revision, dating to = 2013. >>>>>>>>>>>>>>>>>> This is for the Z77-Pro4-M revision 2.0 (2013/7/23) = and for >>>>>>>>>>>>>>>>>> the Z77 Pro4 revision 1.8 (2013/7/17). For both = boards a >>>>>>>>>>>>>>>>>> BETA revision for the Spectre/Meltdown mitigation is >>>>>>>>>>>>>>>>>> available, but I didn't test that. But please read. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> The third box I realised this problem is a brand new = Fujitsu >>>>>>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R = 1.26.0 for >>>>>>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525). >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via >>>>>>>>>>>>>>>>>> bsdinstall the OS using UEFI-only boot method on a = GPT >>>>>>>>>>>>>>>>>> partitioned device fails. The ASRock boards jump = immediately >>>>>>>>>>>>>>>>>> into the firmware, the Fujitsu offers some kind of >>>>>>>>>>>>>>>>>> CPU/Memory/HDD test facility. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> If on both type of vendor/boards CSM is disabled and = UEFI >>>>>>>>>>>>>>>>>> boot only is implied, the MBR partitioned FreeBSD >>>>>>>>>>>>>>>>>> installation USB flash device does boot in UEFI! I = guess I >>>>>>>>>>>>>>>>>> can assume this when the well known clumsy 80x25 char >>>>>>>>>>>>>>>>>> console suddenly gets bright and shiny with a much = higher >>>>>>>>>>>>>>>>>> resoltion as long the GPU supports EFI GOP. Looking = with >>>>>>>>>>>>>>>>>> gpart at the USB flash drives reveals that the EFI = partition >>>>>>>>>>>>>>>>>> starts at block 1 of the device and the device has a = MBR >>>>>>>>>>>>>>>>>> layout. I haven't found a way to force the GPT = scheme, when >>>>>>>>>>>>>>>>>> initialised via gpart, to let the partitions start at = block >>>>>>>>>>>>>>>>>> 1. This might be a naiv thinking, so please be = patient with >>>>>>>>>>>>>>>>>> me. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I do not know whether this is a well-known issue. On = the >>>>>>>>>>>>>>>>>> ASRock boards, I tried years ago some LinuxRed Hat = and Suse >>>>>>>>>>>>>>>>>> with UEFI and that worked - FreeBSD not. I gave up on = that >>>>>>>>>>>>>>>>>> that time. Now, having the very same issues with a = new >>>>>>>>>>>>>>>>>> Fujitsu system, leaves me with the impression that = FreeBSD's >>>>>>>>>>>>>>>>>> UEFI implementation might have problems I'm not aware = of. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Can someone shed some light onto this?=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The first thing to check is if the secure boot is = disabled. We >>>>>>>>>>>>>>>>> do not support secure boot at all at this time. = =20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Secure boot is in every scenario disabled! >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> If you have efi or bios version running - you can = check from >>>>>>>>>>>>>>>>> either console variable value (it can have efi or = vidconsole >>>>>>>>>>>>>>>>> or comconsole) or better yet, see if efi-version is = set (show >>>>>>>>>>>>>>>>> efi-version) - if efi-version is not set, it is BIOS = loader >>>>>>>>>>>>>>>>> running. Another indirect way is to see lsdev -v, with = device >>>>>>>>>>>>>>>>> paths present, it is uefi:) =20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> What are you talking about? >>>>>>>>>>>>>>>> What is the point of entry - running system, loader? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> sysct machdep.bootmethod: BIOS >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> This makes me quite sure that the system has booted via = BIOS - >>>>>>>>>>>>>>>> as I'm sure since I've checked that many times. UEFI = doesn't >>>>>>>>>>>>>>>> work on those systems with FreeBSD. I'm not sure = antmore, but >>>>>>>>>>>>>>>> I tried also Windows 7 on those mainboards booting via = UEFI - >>>>>>>>>>>>>>>> and I might recall that they failed also. I also recall = that >>>>>>>>>>>>>>>> there were issues with earlier UEFI versions regarding = booting >>>>>>>>>>>>>>>> only Windows 8/8.1 - and nothing else, but the fact = that Linux >>>>>>>>>>>>>>>> worked confuses me a bit. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> If this ASRock crap (never ever again this brand!) = doesn't work >>>>>>>>>>>>>>>> at all - who cares, I intend to purchase new server = grade >>>>>>>>>>>>>>>> hardware. But the more puzzling issue is with the = Fujitsu, >>>>>>>>>>>>>>>> which I consider serious and from the behaviour the = Fujitsu >>>>>>>>>>>>>>>> failure looks exactly like the ASRock - Windows 7 = works, >>>>>>>>>>>>>>>> RedHat 7.5 works (I assume I can trust the Firmware = settings >>>>>>>>>>>>>>>> when I disable CSM support, that the Firmware will only >>>>>>>>>>>>>>>> EFI/UEFI capable loader? Or is there a ghosty override >>>>>>>>>>>>>>>> somwhere to be expected?). Also on ASRock disabling CSM = should >>>>>>>>>>>>>>>> ensure not booting a dual-bootstrap-capable system. = This said, >>>>>>>>>>>>>>>> on the recent Fujitsu, it seems to boil down to a = FreeBSD >>>>>>>>>>>>>>>> UEFI-firmware interaction problem, while the ASRock is = still >>>>>>>>>>>>>>>> under suspicion to be broken by design. =20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> GPT partitions can never start from disk absolute = sector 1; >>>>>>>>>>>>>>>>> this is because at sector 0 there is MBR (for = compatibility), >>>>>>>>>>>>>>>>> sector 1 is GPT table and then sectors 2-33 have GPT >>>>>>>>>>>>>>>>> partition table entries, so the first possible data = sector is >>>>>>>>>>>>>>>>> 34 (absolute 34). Thats assuming 512B sectors. For = details >>>>>>>>>>>>>>>>> see UEFI 2.7 Chapter 5.3.1 page 131. =20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Thanks for the explanation. That implies the installer = did >>>>>>>>>>>>>>>> right, gpart did also right and therefore there must be = an >>>>>>>>>>>>>>>> issue with the stuff located within the EFI >>>>>>>>>>>>>>>> partition? =20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if = we reach >>>>>>>>>>>>>>> BIOS loader at all or not - that is, if the BIOS = bootstrap is >>>>>>>>>>>>>>> actually caring to read the MBR code and start it, since = once >>>>>>>>>>>>>>> the MBR code is started, it is all about our code. = =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" = the CSM? >>>>>>>>>>>>>> or do you mean that specific portion of the UEFI = firmware, which >>>>>>>>>>>>>> looks for the proper UEFI partition? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> BIOS as either native or CSM. Note that from boot code = point of >>>>>>>>>>>>> view the CSM boot *is* BIOS boot, we have no access to = UEFI >>>>>>>>>>>>> features.=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The boxes in question, most notably the more recent = Fujitsu >>>>>>>>>>>>>> Esprimo Q956, refuse booting UEFI, even if properly setup = (in >>>>>>>>>>>>>> terms of what FreeBSD provides on recent CURRENT) is = applied and >>>>>>>>>>>>>> CSM is switched off in the firmware. Again: GPT partition = scheme. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The system boots properly if a second partition of type >>>>>>>>>>>>>> "freebsd-boot" is applied and bootcode is properly = applied via >>>>>>>>>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" = (ada0 >>>>>>>>>>>>>> is the device). =20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> btw, you can try to validate the installed boot blocks = by using >>>>>>>>>>>>>>> recent enough loader (usb or iso) and then you can use = from OK >>>>>>>>>>>>>>> prompt: =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> lsdev provides me with the follwoing informations (CSM = enabled): >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> OK lsdev >>>>>>>>>>>>>> disk devices: >>>>>>>>>>>>>> disk0: BIOS DRIVE C ... >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> disk0p1: EFI >>>>>>>>>>>>>> disk0p2: FreeBSD BOOT >>>>>>>>>>>>>> disk0p3: FreeBSD SWAP >>>>>>>>>>>>>> disk0p4: FreeBSD ZFS >>>>>>>>>>>>>> zfs devices: >>>>>>>>>>>>>> zfs:zroot >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> OK chain disk0 >>>>>>>>>>>>>> open failed (so for disk0p{1-4}. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> OK chain zroot >>>>>>>>>>>>>> failed to read disk (just for completeness) =20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> chain command does use only device name (such as disk0: or >>>>>>>>>>>>> disk0p2: ), but not zfs pool as device. I just found I = haven?t >>>>>>>>>>>>> ported the code to read the file. =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> ?? >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> the point for chain command test is to see if the normal = read and >>>>>>>>>>>>> execute would work, so in your case please try: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> chain disk0: =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> As stated above, I did so, and the result is also mentioned = above, >>>>>>>>>>>> I always get "open failed". >>>>>>>>>>>> This is the same for=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> chain disk0 >>>>>>>>>>>> chain disk0p1 >>>>>>>>>>>> chain disk0p2 >>>>>>>>>>>> chain disk0p3 >>>>>>>>>>>> chain disk0p4 >>>>>>>>>>>>=20 >>>>>>>>>>>> as already said. CSM is enabled in this case. =20 >>>>>>>>>>>=20 >>>>>>>>>>> sigh? chain command does take device as argument, device = must always >>>>>>>>>>> end with colon?. in this case, the devil is in details:) as = I wrote >>>>>>>>>>> above, the command should be: >>>>>>>>>>>=20 >>>>>>>>>>> chain disk0: >>>>>>>>>>>=20 >>>>>>>>>>> The disk0p1: etc will only work when partition boot code was >>>>>>>>>>> installed (which you most likely do not have - the only = possible >>>>>>>>>>> candidate could be FreeBSD ZFS partition). =20 >>>>>>>>>>=20 >>>>>>>>>> The command "chain disk0:" works as expected (CSM enabled, = GPT >>>>>>>>>> partition scheme, but with PMBR bootblock installed and = freebsd-boot >>>>>>>>>> partition conatining gptzfsboot installed. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> to read pmbr (512B) and execute it. The expected outcome = would be >>>>>>>>>>>>> that pmbr boot code would browse the GPT, read stage1 from >>>>>>>>>>>>> disk0p2: and execute it; stage1 would detect FreeBSD ZFS = from >>>>>>>>>>>>> disk0p4: and load and execute /boot/loader. If that will = happen, >>>>>>>>>>>>> it means the boot code in our stages is just fine, but the = bios >>>>>>>>>>>>> (CSM) does not load pmbr?. if thats true, it would mean = that you >>>>>>>>>>>>> either need to use UEFI boot or need to have some hack to = fool >>>>>>>>>>>>> the BIOS or just not use GPT on that machine with CSM. = =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> To make it clear here: The only way to boot this box is = using CSM >>>>>>>>>>>> (as it is the same with the ASRock boards mentioned = earlier). But >>>>>>>>>>>> my intention is to disable CSM and use a GPT/UEFI = environment >>>>>>>>>>>> only! And GPT/UEFI doesn't work with FreeBSD, neither with >>>>>>>>>>>> 12-CURRENT, nor 11.2-RELENG. >>>>>>>>>>>>=20 >>>>>>>>>>>> It would be nice if this could be fixed. I'm more = interested in the >>>>>>>>>>>> fix on the recent Fujitsu device than the outdated ASRock = crap, but >>>>>>>>>>>> if the fix for the Fujitsu Firmware could fix older issues = as a >>>>>>>>>>>> byproduct, I'd appreciate that. >>>>>>>>>>>>=20 >>>>>>>>>>>> Kind regards, >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ok, somehow I have lost that part of the discussion. Well, = you wrote >>>>>>>>>>> that the UEFI boot fails when the first partition starts = from sector >>>>>>>>>>> 40 - does it mean you have boot when the partition will = start from >>>>>>>>>>> some other sector? I think, there is something else going >>>>>>>>>>> on. =20 >>>>>>>>>>=20 >>>>>>>>>> Well, I simply try to describe what I "see" to make things >>>>>>>>>> disambiguous. I'm not familiar with the deeper insights of = disk >>>>>>>>>> layouts on a binary level. So, you explained to me the = reason, why >>>>>>>>>> ESP (EGI partition) starts at block 40. I compared that to = the >>>>>>>>>> FreeBSD USB flash image FreeBSD provides, but this is another = story >>>>>>>>>> since the image uses MBR scheme as I figured out. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> What you can do is to see if that firmware will offer you = EFI shell >>>>>>>>>>> option, from there you can try to start the bootx64.efi = manually and >>>>>>>>>>> see what error you will get. However, the number 1 cause for = failing >>>>>>>>>>> to start the bootloader in UEFI is secure boot - we do not = support >>>>>>>>>>> it and secure boot must be switched off.=20 >>>>>>>>>>>=20 >>>>>>>>>>> However, they seem to claim "The Secure Boot option is = available in >>>>>>>>>>> the UEFI/BIOS of most if not all ASRock boards. It is = disabled by >>>>>>>>>>> default.?=20 >>>>>>>>>>>=20 >>>>>>>>>>> Still suggest to double check if thats really the case. = Also, if the >>>>>>>>>>> bootx64.efi start will fail and no messages are appearing on = screen, >>>>>>>>>>> then either there is something in firmware logs or you could = get >>>>>>>>>>> them from trying to start bootx64.efi from UEFI shell. = =20 >>>>>>>>>>=20 >>>>>>>>>> Since I'm with this problem since 2014 and try from time to = time, be >>>>>>>>>> ausred that I tried every possible permutationof all = reasonable >>>>>>>>>> options, even those nonsense, to get rid of that problem. >>>>>>>>>>=20 >>>>>>>>>> I never had any problems with any other UEFI capable >>>>>>>>>> server/workstation firmware so far booting FreeBSD off in >>>>>>>>>> UEFI-native (GPT partition scheme, CSM disabled) so far - = until now, >>>>>>>>>> when I ran into this Fujitsu ESPRIMO Q956 with the most = recent >>>>>>>>>> firmware (as of lat week, week 29 of 2018) having the very = same >>>>>>>>>> problems.=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I figured out something strange on the Fujitsu - and that is = the same >>>>>>>>>> with the ASRock boards. >>>>>>>>>>=20 >>>>>>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a = very small >>>>>>>>>> appliance, but nevertheless, the USB flash device is booted = on >>>>>>>>>> Fujitsu servers with UEFI-only configurations. I assume at = this >>>>>>>>>> point that disabling on the most recent Fujitsu firmwares on >>>>>>>>>> reasonable "new" hardware (not older than three years) will = disable >>>>>>>>>> any(!) legacy BIOS capabilities. The same is assumed for the = Fujitus >>>>>>>>>> ESPRIMO Q956. I can not speak for the ASRock A77 Pro4/m = boards >>>>>>>>>> mentioned above/earlier, they are from 2012/2013 and "quite = old". >>>>>>>>>>=20 >>>>>>>>>> The NanoBSD image of ours doesn't have a "freebsd-boot" = partition. >>>>>>>>>> The partition scheme of the flash device is GPT. The layout = looks >>>>>>>>>> like this: >>>>>>>>>>=20 >>>>>>>>>> gpart show -l da4 =20 >>>>>>>>>> =3D> 40 15425456 da4 GPT (7.4G) =20 >>>>>>>>>> 40 2000 1 efiboot0 (1.0M) >>>>>>>>>> 2040 1453584 3 disk1a (710M) >>>>>>>>>> 1455624 4096 5 disk3 (2.0M) >>>>>>>>>> 1459720 13965776 - free - (6.7G) >>>>>>>>>>=20 >>>>>>>>>> I created the flash with md, gpart and dd straightforward, = efiboot0 >>>>>>>>>> is the ESP partition and its format/content is created via dd >>>>>>>>>> if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is = very simple. >>>>>>>>>>=20 >>>>>>>>>> This USB flash device boots(!) successfully (UEFI!) on both = the >>>>>>>>>> ASRock boards and the Esprimo Q956! >>>>>>>>>>=20 >>>>>>>>>> But any SSD prepared the same way doesn't. Why?=20 >>>>>>>>>>=20 >>>>>>>>>> On the ASRock, I recall having fiddled around with HDD also = for a >>>>>>>>>> while conatining Windows 7/SP1 and FreeBSD. Windows7 booted, = FreeBSD >>>>>>>>>> - I can't remember.=20 >>>>>>>>>>=20 >>>>>>>>>> In the lack of proper hardware I'm unable to check whether >>>>>>>>>> USB-attached HDD or SSD will boot or HDD will boot (just in = case the >>>>>>>>>> local SATA has problems booting UEFI and USB not). >>>>>>>>>>=20 >>>>>>>>>> Kind regards, >>>>>>>>>>=20 >>>>>>>>>> Oliver=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Am. well. I think the suggestion to test out FAT32 is still = good one >>>>>>>>> to test. This is because it is known that some vendors do not = support >>>>>>>>> booting FAT12/FAT16 from HDD (the likely reason is that UEFI >>>>>>>>> specification does not tell which FAT must be supported, and = only hint >>>>>>>>> about FAT12/FAT16 in context of removable devices). =20 >>>>>>>>=20 >>>>>>>> I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO = Q956. It >>>>>>>> took me a time to circumvent the installer and I had to install = the >>>>>>>> system manually. In that strain, I also "tried" to establish = the ESP >>>>>>>> with FAT32, as Allen Jude suggested earlier. I didn't find any = ad hoc >>>>>>>> help how to find out the format (FAT12/16/32) of the ESP, so I = assume >>>>>>>> when using 12-CURRENT's or 11.2-RELENG's installer with = AUTO-ZFS and >>>>>>>> GPT (UEFI) (only!) the resulting ESP is FAT12 or FAT16 (300mb = by >>>>>>>> default). I also assume, that when dd'ing the /boo/boot1.efifat = image >>>>>>>> to a partition, the format is FAT, but not FAT32. Therefore, I >>>>>>>> refomatted the manually created ESP (using "gpart add -t efi = ...") >>>>>>>> using "newfs_msdos -F 32 -b xxx ...". I had to fiddle around a = bit >>>>>>>> with option -b to fit in a proper format to meet a 512mb ESP - = I'm not >>>>>>>> sure whether this is the proper option to deal with. When using = the >>>>>>>> default and only -F32, the size of the partition has to be 4G = at least >>>>>>>> I assume. Having done that, I copied the the content of = boot1.efifat >>>>>>>> (mdconfig -t vnode ..., I guess we know the drill ...) to the = newly >>>>>>>> formatted ESP to /boot/efi/ ... >>>>>>>>=20 >>>>>>>> Having so far no knowledge of how to asure that the created ESP = is >>>>>>>> FAT32, I assume it is FAT32. >>>>>>>>=20 >>>>>>>> The result is negative on the ESPRIMO Q956. When disabling the = CSM, the >>>>>>>> box is not willing to boot from SSD with the ESP prepared as = decribed. >>>>>>>> So, a chance that this might still be due to a misconfiguration = lies >>>>>>>> now within the -b option of newfs_msdos - if the -b option is = assumed >>>>>>>> the proper option? >>>>>>>>=20 >>>>>>>> At the moment, the ESP of the Esprimo is subject to changes, if = you >>>>>>>> wish, but not in size, since it is limited to 512mb. >>>>>>>>=20 >>>>>>>> Thanks and kind regards, >>>>>>>>=20 >>>>>>>> Oliver =20 >>>>>>>=20 >>>>>>> Yea, i was hoping fstyp command would report the FAT type, but = it does >>>>>>> not (request for feature?:) =20 >>>>>>=20 >>>>>> FYI, the file(1) command is very good at disecting a disk image = to tell >>>>>> you what the MBR looks like, and at looking at partitions if = pointed at >>>>>> them with the -s option. It should be able to detect = FAT12/16/32. >>>>>>=20 >>>>>> root@x230a:/home/ISO/x # file -s /dev/md2s1 >>>>>> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID = "BSD4.4 ", >>>>>> root entries 512, sectors 1600 (volumes <=3D32 MB) , sectors/FAT = 5, >>>>>> sectors/track 63, heads 1, serial number 0xbd4111ee, label: = "EFISYS >>>>>> ", FAT (12 bit), followed by FAT >>>>>>=20 >>>>>>>=20 >>>>>>> However, the more annoying idea would be to install some OS = which will >>>>>>> boot with UEFI on this machine, then copy boot1.efi from freebsd = to it >>>>>>> (the default program the UEFI will load is = ESP:EFI/boot/bootx64.efi in >>>>>>> case of UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However, = we do >>>>>>> not support EFI32. >>>>>>>=20 >>>>>>> note that boot1.efi alone will not do much but printing on = screen how it >>>>>>> will search for freebsd, but for the purpose of the test it = would >>>>>>> suffice >>>>>>> - that would give us confirmed working ESP file system (since = the other >>>>>>> os would be able to boot) and then we can confirm if boot1.efi = itself is >>>>>>> OK. =20 >>>>>>=20 >>>>>=20 >>>>> Some new results. >>>>> I installed RedHat 7.5 and inestigated the ESP. >>>>>=20 >>>>> - The ESP starts at block 2048, while FreeBSD's ESP starts at = block 40. >>>>> - size is both 200mb if installed automatically. I forgit to = investigate >>>>> the FAT format, but this might be unnecessary as shown further in = this >>>>> post. >>>>> - RedHat's ESP contains ~ 10 MB of data in two >>>>> folders, /efi/boot, /efi/redhat. copying FreeBSD's BOOTX64.efi = over >>>>> RedHat's doesn't change anything, also renaming = /efi/boot/fbx64.efi of >>>>> RedHat's installation. But renaming /efi/redhat renders RedHat to = fail the >>>>> boot process on the Fujitsu with the signs of the built-in = testprogram as >>>>> reported. >>>>>=20 >>>>> I took the liberty and installed 11.2-RELENG again, ZFS only, UEFI = boot >>>>> only (CSM in firmware disabled, but there is still a = gptzfsboot-prepared >>>>> partition for later use, just for the record). Booting UEFI-only = fails as >>>>> reported. On this installation I copied the RedHat ESP completely = into >>>>> FreeBSD's ESP, renamed /efi/boot/BOOTX64.efi to = /efi/boot/BOOTX64.efi.rh >>>>> and copied FreeBSD's BOOTX64.efi to /efi/boot.=20 >>>>> The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, = that >>>>> the /efi/redhat folder of the ESP is important, if renamed, the = whole >>>>> process dies as I reported earlier. >>>>>=20 >>>>> Still unanswered is the question: why is a NanoBSD prepared = UEFI-only USB >>>>> flash booting with CSM disabled (so asumingly UEFI only then) on = both >>>>> ASRock and Fujitsu (as described in more detail initially and = earlier), >>>>> while SSDs fail? Is there a difference? Since FreeBSD boots in = UEFI mode >>>>> from USB flash prepared as described (straight forward, 800k ESP = starting >>>>> at block 40, the boot1.efifat image dd'ed onto the partition, UFS >>>>> partition following, no freebsd-boot partition or MBR/PMBR = bootcode >>>>> applied ever!), I think BOOTX64.EFI is technically all right. = There must >>>>> be then an issue with the SATA/SSD/HDD boot pathway. >>>>>=20 >>>>> Hope I could provide some more details, sorry if it sounds = confusing or >>>>> way too long, but I try to descibe the situation as thorough as = possible. >>>>>=20 >>>>=20 >>>> OK, this is already good hint. The thing with ESP is that there is >>>> =E2=80=9Cdefault=E2=80=9D file system tree: = EFI/BOOT/BOOT.EFI, this is noted as >>>> default for *removable* media, fortunately it is usable for hard = disks as >>>> well, or at least in most cases. >>>>=20 >>>> Now, for non-removable media, the UEFI does provide boot manager = interface >>>> to define boot entries, and the fact that renaming efi/redhad = directory did >>>> break the redhat boot, is very loud hint. And this means, this = system is >>>> probably ignoring efi/boot tree on non-removable media and is = expecting the >>>> boot manager entry to be created instead. =20 >>>=20 >>> This inplication I'd confirm for the recent Fujitsu ESPRIMO Q956 = firmware >>> (not tested on ASRock Z77-Pro4 firmware). >>>=20 >>>>=20 >>>> UEFI boot manager can be configured /usually/ manually via firmware = menu, >>>> or by application, such as efibootmgr. The normal approach is to = create >>>> efi/ directory and to copy the application there, then = create >>>> the boot manager configuration. >>>>=20 >>>> See UEFI specification v2.7, chapter 3 Boot Manager, page 79. >>>>=20 >>>> What is different in FreeBSD case is that the whole interface to = program >>>> the UEFI Boot Manager is currently being developed, so either it = has to be >>>> done manually or from some other OS (see >>>> https://wiki.gentoo.org/wiki/Efibootmgr >>>> for example, first hit = from >>>> google:D). =20 >>>=20 >>> Well, thanks for this important hint! FreeBSD 12-CURRENT's and = FreeBSD >>> 11.2-RELENG's USB flash devices are capable of booting off on = Fujitsu's >>> ESPRIMO and ASRock's boards. As a note: after "kldload efirt.ko" I = was able >>> to use the already in FreeBSD present toolset efibootmgr(8) and = sibblings >>> (the tools do not do anything useful when booted non-UEFI). >>>=20 >>> Mounting the ESP of the harddrive (in my case, ada0p1) to /mnt and = following >>> the steps in the examples and having created = /efi/freebsd/BOOTx64.efi as >>> recommended by copy from /efi/boot, let me create a proper boot = variable. >>>=20 >>> To make things sure, I also applied "efibootmgr -a VARIABLENAME". >>>=20 >>> And ... it worked! Yes, it worked! The ESP is FAT32 formatted, I do = not know >>> whether this will also work with FAT12/16, I should test this case, = too. >>>=20 >>> There is a bug in the manpage of efibootmg(8). It does not explain = the >>> options -d and -p, although they could be "implied" by reading = carefully. >>> There is now a PR at=20 >>>=20 >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230080 >>>=20 >>> for this issue. >>>=20 >>> So, it's apity that the handbook has no note I could easily find on = this;=20 >>>=20 >>> Thank you very much for your patience and help! >>>=20 >>> Kind regards, >>> Oliver =20 >>=20 >> yep, efibootmgr does call UEFI RuntimeServices to set up the = variables, and >> this is only possible when booted UEFI. But glad we finally found the = root >> cause. It would be good to have HW notes for such cases, it is = important to >> know that those systems wont boot UEFI from HDD unless the boot = manager setup >> is done. >>=20 >> rgds, >> toomas >=20 >=20 > This pops up the question how to deal with such HW. We have as a = institution a > lot of Fujitsu hardware her - from larger servers down to Fujitsu = ESPRIMO Q956. > The latter one is the first (and so far the only) piece of hardware I = found > incapable of booting off UEFI within the past 5 years. >=20 > If the "standard" for removeable devices is to boot from = /efi/boot/bootx64.efi, > than I'd guess it is good luck for FreeBSD that the firmware vendors = did > fallback to such a mechanism. GRUB/Linux seem to install by default = their > bootloader into /efi/something/ I'll check on Debian, Suse and CentOS = so far > soon, the latter probably will, since its the "free" RedHat). >=20 > Anyway, apart from any criticism, I'm glad to have the tools to make = things > work without using alien help (outside FreeBSD's world!). That is a = thank you > towards the developers. >=20 > Kind regards, >=20 > oh >=20 The efibootmgr is only relatively recent addition (in illumos we do not = have yet even access to UEFI RS), so it is only question of time once = installer will get updated:) But of course there is still an issue about the scenario when the = install is done in BIOS mode and later switched to UEFI - then the boot = manager configuration needs to be updated manually (or by some = maintenance service like grub2 is calling via grub-install script). rgds, toomas From owner-freebsd-current@freebsd.org Fri Jul 27 14:43:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0DF2104D440 for ; Fri, 27 Jul 2018 14:43:55 +0000 (UTC) (envelope-from lwhsu@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 5B38F77CDE; Fri, 27 Jul 2018 14:43:55 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 52FB1EA63; Fri, 27 Jul 2018 14:43:55 +0000 (UTC) Date: Fri, 27 Jul 2018 14:43:55 +0000 From: Li-Wen Hsu To: Ian Lepore Cc: freebsd-current@FreeBSD.org Subject: Re: svn commit: r336751 - head/usr.sbin/pw Message-ID: <20180727144355.GA47251@freefall.freebsd.org> References: <201807262003.w6QK3B7E026934@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201807262003.w6QK3B7E026934@repo.freebsd.org> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 14:43:55 -0000 On Thu, Jul 26, 2018 at 20:03:11 +0000, Ian Lepore wrote: > Author: ian > Date: Thu Jul 26 20:03:11 2018 > New Revision: 336751 > URL: https://svnweb.freebsd.org/changeset/base/336751 > > Log: > Re-apply r336625 which was reverted with r336638, now that the underlying > pw_scan(3) has been fixed in a way that doesn't perturb other callers of > it or the getpwnam(3) family. > > Make pw(8) showuser work the same with or without -R for non-root > users. Without -R, pw(8) uses getpwnam(3), which will open master.passwd > for the root user or passwd for non-root users. With -R pw(8) was > always opening /master.passwd, which would fail for a non-root user, > then falsely claim the userid you're trying to show doesn't exist. > > Now for a non-root user it opens /passwd, and populates the fields in > the returned struct passwd which aren't present in that file with well-known > canonical values, which duplicates the behavior of getpwnam(3). The net > effect is that the showuser output is identical whether using -R or not. > > Modified: > head/usr.sbin/pw/pw_vpw.c Hi Ian, It seems usr.sbin.pw.* tests are failing after this commit: https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8367/testReport/ Can you help me check this is realted to the new pw code or there is anything we need to modify in the test VM setup or running environment. The related artifacts are available here: https://artifact.ci.freebsd.org/snapshot/head/r336751/amd64/amd64/ You can use disk-test.img.xz which is a VM with setup testing environment. The build script will start automatically but you can ctrl-c to interrupt anytime and run tests by hand: cd /usr/tests/usr.sbin/pw kyua test Thanks, Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Fri Jul 27 15:22:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A99F6104E49C for ; Fri, 27 Jul 2018 15:22:26 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 3818C79D6E for ; Fri, 27 Jul 2018 15:22:25 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: d7f9e1bd-91b0-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id d7f9e1bd-91b0-11e8-aff6-0b9b8210da61; Fri, 27 Jul 2018 15:22:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6RFMFl6023715; Fri, 27 Jul 2018 09:22:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532704935.61594.42.camel@freebsd.org> Subject: Re: svn commit: r336751 - head/usr.sbin/pw From: Ian Lepore To: Li-Wen Hsu Cc: freebsd-current@FreeBSD.org Date: Fri, 27 Jul 2018 09:22:15 -0600 In-Reply-To: <20180727144355.GA47251@freefall.freebsd.org> References: <201807262003.w6QK3B7E026934@repo.freebsd.org> <20180727144355.GA47251@freefall.freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:22:26 -0000 On Fri, 2018-07-27 at 14:43 +0000, Li-Wen Hsu wrote: > On Thu, Jul 26, 2018 at 20:03:11 +0000, Ian Lepore wrote: > > > > Author: ian > > Date: Thu Jul 26 20:03:11 2018 > > New Revision: 336751 > > URL: https://svnweb.freebsd.org/changeset/base/336751 > > > > Log: > >   Re-apply r336625 which was reverted with r336638, now that the underlying > >   pw_scan(3) has been fixed in a way that doesn't perturb other callers of > >   it or the getpwnam(3) family. > >    > >   Make pw(8) showuser work the same with or without -R for non-root > >   users.  Without -R, pw(8) uses getpwnam(3), which will open master.passwd > >   for the root user or passwd for non-root users.  With -R pw(8) was > >   always opening /master.passwd, which would fail for a non-root user, > >   then falsely claim the userid you're trying to show doesn't exist. > >    > >   Now for a non-root user it opens /passwd, and populates the fields in > >   the returned struct passwd which aren't present in that file with well-known > >   canonical values, which duplicates the behavior of getpwnam(3).  The net > >   effect is that the showuser output is identical whether using -R or not. > > > > Modified: > >   head/usr.sbin/pw/pw_vpw.c > Hi Ian, > > It seems usr.sbin.pw.* tests are failing after this commit: > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8367/testReport/ > > Can you help me check this is realted to the new pw code or there is > anything we need to modify in the test VM setup or running environment. > > The related artifacts are available here: > > https://artifact.ci.freebsd.org/snapshot/head/r336751/amd64/amd64/ > > You can use disk-test.img.xz which is a VM with setup testing > environment.  The build script will start automatically but you can > ctrl-c to interrupt anytime and run tests by hand: > > cd /usr/tests/usr.sbin/pw > kyua test This was just an error on my part, the code was wrong and I fixed it in r336762. This time I made sure the kyua tests pass first. I had intended to run the kyua tests before and after re-applying my changes to pw(8). Now that I look in my scrollback, it seems I ran the "before" tests, then got distracted and forgot to run them again after and just committed the changes. Sorry about the breakage. -- Ian From owner-freebsd-current@freebsd.org Fri Jul 27 15:23:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4FD2104E4E6 for ; Fri, 27 Jul 2018 15:23:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D16379E49; Fri, 27 Jul 2018 15:23:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 6700710AFD2; Fri, 27 Jul 2018 11:23:24 -0400 (EDT) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') To: Mark Millard References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> <462BE582-0C2E-4D40-92F3-A27155777E58@yahoo.com> <1E03ECE7-297C-4D40-BC58-FB1903538181@yahoo.com> Cc: Konstantin Belousov , FreeBSD Current From: John Baldwin Message-ID: Date: Fri, 27 Jul 2018 08:23:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1E03ECE7-297C-4D40-BC58-FB1903538181@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 27 Jul 2018 11:23:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:23:26 -0000 On 7/27/18 12:12 AM, Mark Millard wrote: > I was looking too locally: the overall context has an outer #if > as well that skips the section: > > /* > * Keywords added in C11. > */ > > #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L > . . . > #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ > !__has_extension(cxx_atomic) > /* > * No native support for _Atomic(). Place object in structure to prevent > * most forms of direct non-atomic access. > */ > #define _Atomic(T) struct { T volatile __val; } > #endif > . . . > #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */ Yes. It also means that if we didn't ship the compiler's stdatomic.h and tried to build with -std=gnu11 or -std=c11 the compile would break. Rather than requiring c11, another approach might be to fix sys/cdefs.h and sys/stdatomic.h to actually work with modern GCC by having them not use the struct for the _GCC_ATOMICS case, only for the _SYNC case. I think that would fix all of the cases. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Jul 27 15:52:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FDC7104F0F9 for ; Fri, 27 Jul 2018 15:52:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (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 16D8A7B1D5 for ; Fri, 27 Jul 2018 15:52:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: XsjrrhwVM1kk5vAdxarzdH_.3W.QGxH0SjExtFeh4JNS8KfjKe37Dc5AFFgW5NZ 5XSxsMtJTbeejv6j5P9eWX9T3kw4YWWmqe8kD3nuGg1faGc.rxrntvgsZd6uhl1qEXwQVELHCcXe pyWowvWVr3IO3bnfdjws1.N1OqtaT53VsAaXYqEFG3k3LjcAOddjZMvjTlI2neei9zUDTN.Y6ZDl v7ucXQwBn.2ZarEqWTwCdVybyDS5La2QUHLgle_NdjlG.IuYRdMLi3UWiyu6Mq6iUpDtBsaWLksz P1ri4Q7ld.xrSwV9iM.gZ6Ckk4KOfaSHn_pklKiycMsNTe9AH9xS.SqBSBsIwk48xyCm.gIpYwNj 7xXWGr5Vg8bFWz5CxeS.WD78fYaLlEU_6YBhR4tNjM9DMV60QLzP6sHLTg4rpXMaI0FtR7vE2T.t pj1uS59JsFs_eJcQO1ol1NoM91.qhy54hOV9LUXKZezZXG.SUDDwJzcItWrVFYQjXDAkSrb9iuyM 4mChWmh07_S643IEn15syZe58oO7ZFXTmYWvhfAyC.tox7uk3UI.1DSVxjzsNcohnYG5vb91RHF2 zCPIn2MaBM2L_9mWqjKVal1dYc.NUX69Z5O9Swmxj2zTS1YJV98UqKnKweolFtUrB1EZF256mFQg zSesMAdNI9psJAAev7aeNGLOBELBV99oxrT77mdmO3sNTPRI.HzIKVjYa.J9bVkGWMRuEKsq5.f8 bwi9XF1iNcqGP3DdoZAvb9tT5AQET7TUMlAftGHdaGJH.4kA7Bs29EumcnAKABTw85o.PqBsrMI8 wUNRO19EE_xfwlv9JXMYhDB0.PODazw3wjN6PCWU0pg7YK84iWxBKC5kuKbl2K1qnWG_4cN_.Xos OBIqs6Wr3AWiZL3i.qtG9MdKO2KC.5gDX1FFxeJ1Q6isFy.KH1MJkA16j3bUu_qKOSbSIRwIjEWU r6xdJXYvmIPKkrFwaaznOWZ1HCS7..PfVyrK8uPSzdbn3C_GzFbwxsQL63oK.jpgdnepgXOfy2Ek 33ZY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Fri, 27 Jul 2018 15:52:20 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID eb1771b860a9790fe01735524d00fac6; Fri, 27 Jul 2018 15:52:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') From: Mark Millard In-Reply-To: <1E03ECE7-297C-4D40-BC58-FB1903538181@yahoo.com> Date: Fri, 27 Jul 2018 08:52:13 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> <462BE582-0C2E-4D40-92F3-A27155777E58@yahoo.com> <1E03ECE7-297C-4D40-BC58-FB1903538181@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:52:27 -0000 On 2018-Jul-27, at 12:12 AM, Mark Millard wrote: On 2018-Jul-26, at 11:29 PM, Mark Millard wrote: > . . . > I was looking too locally: the overall context has an outer #if > as well that skips the section: >=20 > /* > * Keywords added in C11. > */ >=20 > #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L > . . . > #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ > !__has_extension(cxx_atomic) > /* > * No native support for _Atomic(). Place object in structure to = prevent > * most forms of direct non-atomic access. > */ > #define _Atomic(T) struct { T volatile __val; } > #endif > . . . > #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */ >=20 >=20 >=20 >=20 > The build with gcc's float.h also removed did complete instead of > stopping early. >=20 >=20 >=20 > As for what x86_64-unknown-freebsd12.0 .h files were used: > (some may do include_next back into FreeBSD headers) >=20 >=20 > # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R = .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; | sort -k 3 | uniq -f 2 | = more > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/adxintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ammintrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx2intrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512bwintrin= .h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512cdintrin= .h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512dqintrin= .h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512erintrin= .h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512fintrin.= h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmaintr= in.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmavlin= trin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512pfintrin= .h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmiintr= in.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmivlin= trin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlbwintr= in.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vldqintr= in.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlintrin= .h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avxintrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmi2intrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmiintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clflushoptintr= in.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clwbintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clzerointrin.h= > R 56022 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/cpuid.h > R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/emmintrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/f16cintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fma4intrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fmaintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fxsrintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ia32intrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/immintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lwpintrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lzcntintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm3dnow.h > R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm_malloc.h > R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mmintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mwaitxintrin.h= > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pkuintrin.h > R 1336 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pmmintrin.h > R 1485 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/popcntintrin.h= > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/prfchwintrin.h= > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rdseedintrin.h= > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rtmintrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/shaintrin.h > R 1485 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/smmintrin.h > R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdarg.h > R 27622 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h > R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdbool.h > R 10025 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stddef.h > R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdint.h > R 68604 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdnoreturn.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/tbmintrin.h > R 1336 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/tmmintrin.h > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/wmmintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/x86intrin.h > R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xmmintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xopintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsavecintrin.h= > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsaveintrin.h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsaveoptintrin= .h > R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsavesintrin.h= > R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xtestintrin.h FYI: a devel/powerpc64-gcc amd64 -> powerpc64 cross build completed = (lib32 build disabled for other reasons). [ ci.freebsd.org only tries amd64-gcc based = .] For reference: (some may do include_next back into FreeBSD headers) # find /usr/obj/powerpc64vtsc_xtoolchain-gcc-no_toolchain/ -name = "*.meta" -exec grep "^R .*/.*-unknown-freebsd12.0/.*/include/" {} \; | = sort -k 3 | uniq -f 2 | more R 1003 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/float.h R 10005 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdarg.h R 38468 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdatomic.h= R 10001 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdbool.h R 10050 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stddef.h R 10000 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdint.h R 74283 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdnoreturn= .h =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 27 15:58:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42F98104F440 for ; Fri, 27 Jul 2018 15:58:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (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 A678A7B708 for ; Fri, 27 Jul 2018 15:58:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: c1jPnRMVM1kat37ic8MZpQ9Xrzu5tiynvQ3hLoF01kFVGhOpCMVDyumi64SY1K2 xtL0aJXFa0RMWYQK.luJGGo6YARi86YxepJ9aN7HaCd24eikiK8OdMCG2zSl5fLkM_5rPhsXkQAu wuxjCgxWomTytYMxc7oUaked6_x6O_i_unX7S5_ri1Q8DwpsgDp4Za7cGBhAXKq_JVV9ALmYLUTM agZcS6q_T7TT9KxJfIwA28pobtByOnj11isVoSrt4hFmT2pzA4TVGL79VPYkRw1oFZaOYoyasJur qYfleJBWkIPGem26EDFsPB3N1mYXxznUNT4Eo6AVq7zsvpTQdxGy2_bqrwyhOJtXeY3P0tJdC1hi wKJ1FUMOzC97joJbN9vuQ4sODsPbAW69cCvuvfPPUs56MnsnmKrgca7TQOQEMtw5xRv4mWi2KdOr PJWqXp19St6ImzT8nD.TBGx4j8CpkfLQMVeHHxOpHiaBrhQFRTIR8DV9i7t0G7Zlqm8DiIoRN.z8 F.jYJBBGczkIFzMWENzbApO7lxGnW5g7ug07H9vqnGvdC1vFmatuPQNRD8nJ8pGf681WAnYZAKKm JraHRUZHOxaOD_bjFeH9p0RjKqg5jzlHMZ0p53fGQvzrb8Po4K2Ro7V.ZozZQYX8V1gcofPrDVzj KOCr3YgkTc.6u96sbO6OXKBEFS._kCHIX4yWoIxvnKl5i2nQrL_KlJPB6Ybp0qI6OEX7lCAbyOqk A2npWK2HTiB_UkqrQnvKHAnFqkNI2Bj9PCdT2vm4lOZm9T9X6qZqKDO_Qu_0u7VzHMtZHu55T8aw fzL0JHWSpY5Rtecy69mlTxxbS6ZML.vCKiYq0gUTW54isMy5EPonKqQdPIM9uFwPEk68L87u3ls7 vWR_awzJsWVl3SeTtft6KtsegyOCvSGGoSwFdonqLhM8dggRlXmB2_I8KMfumcH.Ex2T71wSs.DN o8Y04vdW7RKublX.P1OWtR6ZWSySmjhk_NuR_Twk14jAu0JRw9E2bcEQPZtxE55oOVojomvunOWm 5Gssn1Cc8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 27 Jul 2018 15:58:19 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3798012b0cef88ed970646893bd0fb70; Fri, 27 Jul 2018 15:58:15 +0000 (UTC) From: Mark Millard Message-Id: <8E61EA21-2DBE-4DED-A7E6-CCE4C79D0359@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add') Date: Fri, 27 Jul 2018 08:58:14 -0700 In-Reply-To: Cc: Konstantin Belousov , FreeBSD Current To: John Baldwin References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> <9D40F38E-F1DC-4A3F-8792-09AD30D8802B@yahoo.com> <1ea2a8d0-b27a-503a-0a8b-48d7fbcd8fcb@FreeBSD.org> <0103123A-2D77-4D64-8FF6-97CD521CA7A8@yahoo.com> <11b515f2-5777-f983-bec5-e60bceda06ab@FreeBSD.org> <6DB0B921-30C8-4BF5-B610-770C0CBF1174@yahoo.com> <462BE582-0C2E-4D40-92F3-A27155777E58@yahoo.com> <1E03ECE7-297C-4D40-BC58-FB1903538181@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:58:27 -0000 On 2018-Jul-27, at 8:52 AM, Mark Millard wrote: > On 2018-Jul-27, at 12:12 AM, Mark Millard = wrote: >=20 > On 2018-Jul-26, at 11:29 PM, Mark Millard = wrote: >=20 >> . . . >> I was looking too locally: the overall context has an outer #if >> as well that skips the section: >>=20 >> /* >> * Keywords added in C11. >> */ >>=20 >> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L >> . . . >> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \ >> !__has_extension(cxx_atomic) >> /* >> * No native support for _Atomic(). Place object in structure to = prevent >> * most forms of direct non-atomic access. >> */ >> #define _Atomic(T) struct { T volatile __val; } >> #endif >> . . . >> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */ >>=20 >>=20 >>=20 >>=20 >> The build with gcc's float.h also removed did complete instead of >> stopping early. >>=20 >>=20 >>=20 >> As for what x86_64-unknown-freebsd12.0 .h files were used: >> (some may do include_next back into FreeBSD headers) >>=20 >>=20 >> # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R = .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; | sort -k 3 | uniq -f 2 | = more >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/adxintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ammintrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx2intrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512bwintrin= .h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512cdintrin= .h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512dqintrin= .h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512erintrin= .h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512fintrin.= h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmaintr= in.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmavlin= trin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512pfintrin= .h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmiintr= in.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmivlin= trin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlbwintr= in.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vldqintr= in.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlintrin= .h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avxintrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmi2intrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmiintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clflushoptintr= in.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clwbintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clzerointrin.h= >> R 56022 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/cpuid.h >> R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/emmintrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/f16cintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fma4intrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fmaintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fxsrintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ia32intrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/immintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lwpintrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lzcntintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm3dnow.h >> R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm_malloc.h >> R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mmintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mwaitxintrin.h= >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pkuintrin.h >> R 1336 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pmmintrin.h >> R 1485 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/popcntintrin.h= >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/prfchwintrin.h= >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rdseedintrin.h= >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rtmintrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/shaintrin.h >> R 1485 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/smmintrin.h >> R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdarg.h >> R 27622 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >> R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdbool.h >> R 10025 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stddef.h >> R 10000 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdint.h >> R 68604 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdnoreturn.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/tbmintrin.h >> R 1336 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/tmmintrin.h >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/wmmintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/x86intrin.h >> R 1222 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xmmintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xopintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsavecintrin.h= >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsaveintrin.h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsaveoptintrin= .h >> R 1595 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xsavesintrin.h= >> R 1520 = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/xtestintrin.h >=20 > FYI: a devel/powerpc64-gcc amd64 -> powerpc64 cross build completed = (lib32 build > disabled for other reasons). [ ci.freebsd.org only tries amd64-gcc = based .] >=20 > For reference: > (some may do include_next back into FreeBSD headers) >=20 > # find /usr/obj/powerpc64vtsc_xtoolchain-gcc-no_toolchain/ -name = "*.meta" -exec grep "^R .*/.*-unknown-freebsd12.0/.*/include/" {} \; | = sort -k 3 | uniq -f 2 | more > R 1003 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/float.h > R 10005 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdarg.h > R 38468 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdatomic.h= > R 10001 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdbool.h > R 10050 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stddef.h > R 10000 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdint.h > R 74283 = /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/stdnoreturn= .h I forgot to write for the powerpc64-gcc case: The build had no system clang or gcc 4.2.1 toolchain built either: it is = one I use for base/{binutils,gcc} experiments (when I have access to the hardware). So this avoided the altivec.h potential issue in building the clang = related materials for powerpc64. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 27 17:06:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5F4E1050E4B for ; Fri, 27 Jul 2018 17:06:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 362FC7DC6A; Fri, 27 Jul 2018 17:06:11 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.164.63]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LcEPJ-1gS66o0AAH-00jXxH; Fri, 27 Jul 2018 19:06:03 +0200 Date: Fri, 27 Jul 2018 19:05:28 +0200 From: "O. Hartmann" To: Toomas Soome Cc: "O. Hartmann" , "Rodney W. Grimes" , freebsd-current , Allan Jude Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180727190555.55439fb3@thor.intern.walstatt.dynvpn.de> In-Reply-To: <2A5E5E42-8595-44E9-A51E-504C9C2C7FA7@me.com> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> <20180727120232.270e1d9f@freyja.zeit4.iv.bundesimmobilien.de> <2A5E5E42-8595-44E9-A51E-504C9C2C7FA7@me.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:7YNc+oo9JCSL+3W3qIc7qzvkxgh/g1edLvUxTUBUnIzEsSMsCfD ELM3npEyfcO1OJNhlmCn4rDcxyFXwB4qg+ZjHl7903O35xsi57ViOzOlpI33gcVervvxQbB pG+wWPzATeIJNbzGCFlPAAEe78Yg5PgdiMMUfk0Mb8DLs0W/bGxZ/V5LxsJ35XxEE06vjR6 MTsouOqe5XifyIYUhA0Mw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+MoQXk76xpE=:IorzFRhrl0JrLKSEX/n5Sc DDUcm7sqLaqUkqDBGqhZ72KsWEqFku136y0DNTTozLE4+x/93OFXKbvuvXJRxbikWSXICtavP iW5TCqwOTQANXQaBEybtkk/VO1iQIHY9LCLtKvCmpWD8mFJhL6M57FF22G6tEuB2ntkHYV0VB fluyQwh0Ez/apL27kRbSN69nUTghzkZu7KoX6e/KI6Vworj4EuNCmZE+5B2hAwkTnTlhzC/Mw 64fQQxOkYuXI+ZMAl/7IcXkG7qDma4cA2u3L4d0nuZe1IuP/6LJ7qMxiSmBJwxdFoiJn3v/Sr i7BG8g7+DhA2wvPjV5Sh70UsXGOu7bJIcPighD3oCE1H+K7wiIQl6avzaFyg/SuQNJb0XD5TS 8TViXl4/jSHdy24jQ1PQb8XVMI2ub8YM1Gnm6e5pslLSfwh6uyBmlVuUO3mmCzxEpA9TTI3IO g77W+clRq4IIZsd3c0ZEqm8f3lCNqY/chr3UkwOlm9xjD4v+sDHV7xv38rUk2QrWLhn6KLc07 Tiy/eXJfY0DCOorHOeIS40aWP2EV7LTKN0fi2DlnGJpb5EPt11kw4DC5CUNtP2m/q7TRjZP6Y OTR7faEylco8Yq3xLp3keXNjxonn86FVyg9yj0NUIRwGLJ4y6koWgIdlSzOVmBkA3FFPtznLu ay/3PIj2Ul4sNK+ICbDcqlKmmqppK5EYxaePr4yclfEIPRSvSIWLdSiptcg+iZgMJRzqLGQ2o YtJ7d3myEYMatMZpWT4DWGWRqW2ne8AzhRGjHEj/QgM7KCXV6XMoujrDSqj9OaqR+uJ794+Ls sGOxPDO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:06:13 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIEZy aSwgMjcgSnVsIDIwMTggMTM6NTk6NDQgKzAzMDANClRvb21hcyBTb29tZSA8dHNvb21lQG1lLmNv bT4gc2NocmllYjoNCg0KPiA+IE9uIDI3IEp1bCAyMDE4LCBhdCAxMzowMiwgTy4gSGFydG1hbm4g PG9oYXJ0bWFubkB3YWxzdGF0dC5vcmc+IHdyb3RlOg0KPiA+IA0KPiA+IE9uIEZyaSwgMjcgSnVs IDIwMTggMDg6NTQ6NDggKzAzMDANCj4gPiBUb29tYXMgU29vbWUgPHRzb29tZUBtZS5jb20+IHdy b3RlOg0KPiA+ICAgDQo+ID4+PiBPbiAyNyBKdWwgMjAxOCwgYXQgMDg6NDYsIE8uIEhhcnRtYW5u IDxvaGFydG1hbm5Ad2Fsc3RhdHQub3JnPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gT24gVGh1LCAy NiBKdWwgMjAxOCAxOToyMzo0MyArMDMwMA0KPiA+Pj4gVG9vbWFzIFNvb21lIDx0c29vbWVAbWUu Y29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gKHJlcGx5IGlubGluZS9hdCB0aGUgZW5kKQ0KPiA+ Pj4gDQo+ID4+PiAgIA0KPiA+Pj4+PiBPbiAyNiBKdWwgMjAxOCwgYXQgMTY6NTgsIE8uIEhhcnRt YW5uIDxvaGFydG1hbm5Ad2Fsc3RhdHQub3JnPiB3cm90ZToNCj4gPj4+Pj4gDQo+ID4+Pj4+IE9u IFdlZCwgMjUgSnVsIDIwMTggMDc6MzA6MzIgLTA3MDAgKFBEVCkNCj4gPj4+Pj4gIlJvZG5leSBX LiBHcmltZXMiIDxmcmVlYnNkLXJ3Z0BwZHgucmguQ044NS5kbnNtZ3IubmV0DQo+ID4+Pj4+IDxt YWlsdG86ZnJlZWJzZC1yd2dAcGR4LnJoLkNOODUuZG5zbWdyLm5ldD4+IHdyb3RlOiAgICAgDQo+ ID4+Pj4+Pj4+IE9uIDI1IEp1bCAyMDE4LCBhdCAxMjoxMCwgTy4gSGFydG1hbm4gPG8uaGFydG1h bm5Ad2Fsc3RhdHQub3JnPiB3cm90ZToNCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+IE9uIFdlZCwg MjUgSnVsIDIwMTggMTE6NDY6MDcgKzAzMDANCj4gPj4+Pj4+Pj4gVG9vbWFzIFNvb21lIDx0c29v bWVAbWUuY29tPiB3cm90ZToNCj4gPj4+Pj4+Pj4gICANCj4gPj4+Pj4+Pj4+PiBPbiAyNSBKdWwg MjAxOCwgYXQgMTA6NTksIE8uIEhhcnRtYW5uIDxvaGFydG1hbm5Ad2Fsc3RhdHQub3JnPiB3cm90 ZToNCj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBPbiBUdWUsIDI0IEp1bCAyMDE4IDA4OjUz OjM2ICswMzAwDQo+ID4+Pj4+Pj4+Pj4gVG9vbWFzIFNvb21lIDx0c29vbWVAbWUuY29tPiB3cm90 ZToNCj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBIZWxsbyAgVG9v bWFzIFNvb21lLA0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IEkgQ0MgQWxsYW4gSnVkZSBz aW5jZSBJIGRpc2NvdmVyZWQgc29tZXRoaW5nICB3ZWlyZCB0b2RheSByZWdhcmRpbmcNCj4gPj4+ Pj4+Pj4+PiB0aGUgVUVGSSBib290IGNhcGFiaWxpdGllcyBvZiBVU0IgZmxhc2ggZGV2aWNlcyBh bmQgU1NEcy4gU2VlIGJlbG93Lg0KPiA+Pj4+Pj4+Pj4+ICAgDQo+ID4+Pj4+Pj4+Pj4+PiBPbiAy NCBKdWwgMjAxOCwgYXQgMDg6MTYsIE8uIEhhcnRtYW5uIDxvaGFydG1hbm5Ad2Fsc3RhdHQub3Jn Pg0KPiA+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+ IE9uIE1vbiwgMjMgSnVsIDIwMTggMTA6NTY6MDQgKzAzMDANCj4gPj4+Pj4+Pj4+Pj4+IFRvb21h cyBTb29tZSA8dHNvb21lQG1lLmNvbT4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+PiAgIA0KPiA+Pj4+ Pj4+Pj4+Pj4+PiBPbiAyMyBKdWwgMjAxOCwgYXQgMTA6MjcsIE8uIEhhcnRtYW5uIDxvaGFydG1h bm5Ad2Fsc3RhdHQub3JnPg0KPiA+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4+ Pj4gDQo+ID4+Pj4+Pj4+Pj4+Pj4+IE9uIEZyaSwgMTMgSnVsIDIwMTggMTg6NDQ6MjMgKzAzMDAN Cj4gPj4+Pj4+Pj4+Pj4+Pj4gVG9vbWFzIFNvb21lIDx0c29vbWVAbWUuY29tIDxtYWlsdG86dHNv b21lQG1lLmNvbT4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+Pj4+PiAgIA0KPiA+Pj4+Pj4+Pj4+Pj4+ Pj4+IE9uIDEzIEp1bCAyMDE4LCBhdCAxNzo0NCwgTy4gSGFydG1hbm4gPG8uaGFydG1hbm5Ad2Fs c3RhdHQub3JnDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzpvLmhhcnRtYW5uQHdhbHN0YXR0 Lm9yZz4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IC0t LS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBIYXNo OiBTSEE1MTINCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBBbSBGcmks IDEzIEp1bCAyMDE4IDE0OjI2OjUxICswMzAwDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4gVG9vbWFzIFNv b21lIDx0c29vbWVAbWUuY29tIDxtYWlsdG86dHNvb21lQG1lLmNvbT4NCj4gPj4+Pj4+Pj4+Pj4+ Pj4+PiA8bWFpbHRvOnRzb29tZUBtZS5jb20gPG1haWx0bzp0c29vbWVAbWUuY29tPj4+DQo+ID4+ Pj4+Pj4+Pj4+Pj4+Pj4gc2NocmllYjogICAgICAgICAgICAgDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBPbiAxMyBKdWwgMjAxOCwgYXQgMTQ6MDAsIE8uIEhhcnRtYW5uDQo+ID4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiA8b2hhcnRtYW5uQHdhbHN0YXR0Lm9yZz4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBwcm9ibGVtIGlzIHNvbWUga2luZCBvZiB3ZWly ZC4gSSBmYWNlIFVFRkkgYm9vdCBwcm9ibGVtcw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gb24gR1BU IGRyaXZlcyB3aGVyZSB0aGUgZmlyc3QgcGFydGl0aW9uIGJlZ2lucyBhdCBibG9jayA0MA0KPiA+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gb2YgdGhlIGhkZC9zc2QuDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAN Cj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgaGF2ZSB0d28gaG9zdCBpbiBwcml2YXRlIHVzZSBiYXNl ZCBvbiBhbg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gb3V0ZGF0ZWQgQVNSb2NrIFo3Ny1Qcm80LU0g YW5kIFo3Ny1Qcm80IG1haW5ib2FyZCAoSXZ5QnJpZGdlLA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g U29ja2V0IExHQTExNTUpLiBCb3RoIGJvYXJkcyBhcmUgZXF1aXB0ZWQgd2l0aCB0aGUgbGF0ZXMN Cj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9mZmljaWFsIGF2YWlsYWJsZSBBTUkgZmlybXdhcmUgcmV2 aXNpb24sIGRhdGluZyB0byAyMDEzLg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyBmb3Ig dGhlIFo3Ny1Qcm80LU0gcmV2aXNpb24gMi4wICgyMDEzLzcvMjMpIGFuZCBmb3INCj4gPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IHRoZSBaNzcgUHJvNCByZXZpc2lvbiAxLjggKDIwMTMvNy8xNykuIEZvciBi b3RoIGJvYXJkcyBhDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBCRVRBIHJldmlzaW9uIGZvciB0aGUg U3BlY3RyZS9NZWx0ZG93biBtaXRpZ2F0aW9uIGlzDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhdmFp bGFibGUsIGJ1dCBJIGRpZG4ndCB0ZXN0IHRoYXQuIEJ1dCBwbGVhc2UgcmVhZC4NCj4gPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIHRoaXJkIGJveCBJIHJlYWxp c2VkIHRoaXMgcHJvYmxlbSBpcyBhIGJyYW5kIG5ldyBGdWppdHN1DQo+ID4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBFc3ByaW1vIFE5NTYsIGFsc28gQU1JIGZpcm13YXJlLCBhdCBWNS4wLjAuMTEgUiAxLjI2 LjAgZm9yDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAzNDEzLUExeCwgZGF0ZSAwNS8yNS8yMDE4IChv ciAyMDE4MDUyNSkuDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IEluc3RhbGxpbmcgb24gYW55IGtpbmQgb2YgSEREIG9yIFNTRCBtYW51YWxseSBvciB2aWENCj4g Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJzZGluc3RhbGwgdGhlIE9TIHVzaW5nIFVFRkktb25seSBib290 IG1ldGhvZCBvbiBhIEdQVA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcGFydGl0aW9uZWQgZGV2aWNl IGZhaWxzLiBUaGUgQVNSb2NrIGJvYXJkcyBqdW1wIGltbWVkaWF0ZWx5DQo+ID4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBpbnRvIHRoZSBmaXJtd2FyZSwgdGhlIEZ1aml0c3Ugb2ZmZXJzIHNvbWUga2luZCBv Zg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ1BVL01lbW9yeS9IREQgdGVzdCBmYWNpbGl0eS4NCj4g Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSWYgb24gYm90aCB0eXBl IG9mIHZlbmRvci9ib2FyZHMgQ1NNIGlzIGRpc2FibGVkIGFuZCBVRUZJDQo+ID4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBib290IG9ubHkgaXMgaW1wbGllZCwgdGhlIE1CUiBwYXJ0aXRpb25lZCBGcmVlQlNE DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpbnN0YWxsYXRpb24gVVNCIGZsYXNoIGRldmljZSBkb2Vz IGJvb3QgaW4gVUVGSSEgSSBndWVzcyBJDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjYW4gYXNzdW1l IHRoaXMgd2hlbiB0aGUgd2VsbCBrbm93biBjbHVtc3kgODB4MjUgY2hhcg0KPiA+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gY29uc29sZSBzdWRkZW5seSBnZXRzIGJyaWdodCBhbmQgc2hpbnkgd2l0aCBhIG11 Y2ggaGlnaGVyDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZXNvbHRpb24gYXMgbG9uZyB0aGUgR1BV IHN1cHBvcnRzIEVGSSBHT1AuIExvb2tpbmcgd2l0aA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZ3Bh cnQgYXQgdGhlIFVTQiBmbGFzaCBkcml2ZXMgcmV2ZWFscyB0aGF0IHRoZSBFRkkgcGFydGl0aW9u DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzdGFydHMgYXQgYmxvY2sgMSBvZiB0aGUgZGV2aWNlIGFu ZCB0aGUgZGV2aWNlIGhhcyBhIE1CUg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbGF5b3V0LiBJIGhh dmVuJ3QgZm91bmQgYSB3YXkgdG8gZm9yY2UgdGhlIEdQVCBzY2hlbWUsIHdoZW4NCj4gPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IGluaXRpYWxpc2VkIHZpYSBncGFydCwgdG8gbGV0IHRoZSBwYXJ0aXRpb25z IHN0YXJ0IGF0IGJsb2NrDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAxLiBUaGlzIG1pZ2h0IGJlIGEg bmFpdiB0aGlua2luZywgc28gcGxlYXNlIGJlIHBhdGllbnQgd2l0aA0KPiA+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gbWUuDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkg ZG8gbm90IGtub3cgd2hldGhlciB0aGlzIGlzIGEgd2VsbC1rbm93biBpc3N1ZS4gT24gdGhlDQo+ ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBU1JvY2sgYm9hcmRzLCBJIHRyaWVkIHllYXJzIGFnbyBzb21l IExpbnV4UmVkIEhhdCBhbmQgU3VzZQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd2l0aCBVRUZJIGFu ZCB0aGF0IHdvcmtlZCAtIEZyZWVCU0Qgbm90LiBJIGdhdmUgdXAgb24gdGhhdA0KPiA+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gdGhhdCB0aW1lLiBOb3csIGhhdmluZyB0aGUgdmVyeSBzYW1lIGlzc3VlcyB3 aXRoIGEgbmV3DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBGdWppdHN1IHN5c3RlbSwgbGVhdmVzIG1l IHdpdGggdGhlIGltcHJlc3Npb24gdGhhdCBGcmVlQlNEJ3MNCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IFVFRkkgaW1wbGVtZW50YXRpb24gbWlnaHQgaGF2ZSBwcm9ibGVtcyBJJ20gbm90IGF3YXJlIG9m Lg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDYW4gc29tZW9u ZSBzaGVkIHNvbWUgbGlnaHQgb250byB0aGlzPyANCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgDQo+ ID4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgZmlyc3QgdGhpbmcg dG8gY2hlY2sgaXMgaWYgdGhlIHNlY3VyZSBib290IGlzIGRpc2FibGVkLiBXZQ0KPiA+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBkbyBub3Qgc3VwcG9ydCBzZWN1cmUgYm9vdCBhdCBhbGwgYXQgdGhpcyB0aW1l LiAgICAgICAgICAgICAgICANCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+ PiBTZWN1cmUgYm9vdCBpcyBpbiBldmVyeSBzY2VuYXJpbyBkaXNhYmxlZCENCj4gPj4+Pj4+Pj4+ Pj4+Pj4+PiAgIA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4gSWYg eW91IGhhdmUgZWZpIG9yIGJpb3MgdmVyc2lvbiBydW5uaW5nIC0geW91IGNhbiBjaGVjayBmcm9t DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+IGVpdGhlciBjb25zb2xlIHZhcmlhYmxlIHZhbHVlIChpdCBj YW4gaGF2ZSBlZmkgb3IgdmlkY29uc29sZQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvciBjb21jb25z b2xlKSBvciBiZXR0ZXIgeWV0LCBzZWUgaWYgZWZpLXZlcnNpb24gaXMgc2V0IChzaG93DQo+ID4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGVmaS12ZXJzaW9uKSAtIGlmIGVmaS12ZXJzaW9uIGlzIG5vdCBzZXQs IGl0IGlzIEJJT1MgbG9hZGVyDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJ1bm5pbmcuIEFub3RoZXIg aW5kaXJlY3Qgd2F5IGlzIHRvIHNlZSBsc2RldiAtdiwgd2l0aCBkZXZpY2UNCj4gPj4+Pj4+Pj4+ Pj4+Pj4+Pj4gcGF0aHMgcHJlc2VudCwgaXQgaXMgdWVmaTopICAgICAgICAgICAgICAgIA0KPiA+ Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoYXQgYXJlIHlvdSB0YWxraW5n IGFib3V0Pw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoYXQgaXMgdGhlIHBvaW50IG9mIGVudHJ5IC0g cnVubmluZyBzeXN0ZW0sIGxvYWRlcj8NCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+ Pj4+Pj4+PiBzeXNjdCBtYWNoZGVwLmJvb3RtZXRob2Q6IEJJT1MNCj4gPj4+Pj4+Pj4+Pj4+Pj4+ PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIG1ha2VzIG1lIHF1aXRlIHN1cmUgdGhhdCB0aGUg c3lzdGVtIGhhcyBib290ZWQgdmlhIEJJT1MgLQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IGFzIEknbSBz dXJlIHNpbmNlIEkndmUgY2hlY2tlZCB0aGF0IG1hbnkgdGltZXMuIFVFRkkgZG9lc24ndA0KPiA+ Pj4+Pj4+Pj4+Pj4+Pj4+IHdvcmsgb24gdGhvc2Ugc3lzdGVtcyB3aXRoIEZyZWVCU0QuIEknbSBu b3Qgc3VyZSBhbnRtb3JlLCBidXQNCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBJIHRyaWVkIGFsc28gV2lu ZG93cyA3IG9uIHRob3NlIG1haW5ib2FyZHMgYm9vdGluZyB2aWEgVUVGSSAtDQo+ID4+Pj4+Pj4+ Pj4+Pj4+Pj4gYW5kIEkgbWlnaHQgcmVjYWxsIHRoYXQgdGhleSBmYWlsZWQgYWxzby4gSSBhbHNv IHJlY2FsbCB0aGF0DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlcmUgd2VyZSBpc3N1ZXMgd2l0aCBl YXJsaWVyIFVFRkkgdmVyc2lvbnMgcmVnYXJkaW5nIGJvb3RpbmcNCj4gPj4+Pj4+Pj4+Pj4+Pj4+ PiBvbmx5IFdpbmRvd3MgOC84LjEgLSBhbmQgbm90aGluZyBlbHNlLCBidXQgdGhlIGZhY3QgdGhh dCBMaW51eA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IHdvcmtlZCBjb25mdXNlcyBtZSBhIGJpdC4NCj4g Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBJZiB0aGlzIEFTUm9jayBjcmFw IChuZXZlciBldmVyIGFnYWluIHRoaXMgYnJhbmQhKSBkb2Vzbid0IHdvcmsNCj4gPj4+Pj4+Pj4+ Pj4+Pj4+PiBhdCBhbGwgLSB3aG8gY2FyZXMsIEkgaW50ZW5kIHRvIHB1cmNoYXNlIG5ldyBzZXJ2 ZXIgZ3JhZGUNCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBoYXJkd2FyZS4gQnV0IHRoZSBtb3JlIHB1enps aW5nIGlzc3VlIGlzIHdpdGggdGhlIEZ1aml0c3UsDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4gd2hpY2gg SSBjb25zaWRlciBzZXJpb3VzIGFuZCBmcm9tIHRoZSBiZWhhdmlvdXIgdGhlIEZ1aml0c3UNCj4g Pj4+Pj4+Pj4+Pj4+Pj4+PiBmYWlsdXJlIGxvb2tzIGV4YWN0bHkgbGlrZSB0aGUgQVNSb2NrIC0g V2luZG93cyA3IHdvcmtzLA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IFJlZEhhdCA3LjUgd29ya3MgKEkg YXNzdW1lIEkgY2FuIHRydXN0IHRoZSBGaXJtd2FyZSBzZXR0aW5ncw0KPiA+Pj4+Pj4+Pj4+Pj4+ Pj4+IHdoZW4gSSBkaXNhYmxlIENTTSBzdXBwb3J0LCB0aGF0IHRoZSBGaXJtd2FyZSB3aWxsIG9u bHkNCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBFRkkvVUVGSSBjYXBhYmxlIGxvYWRlcj8gT3IgaXMgdGhl cmUgYSBnaG9zdHkgb3ZlcnJpZGUNCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBzb213aGVyZSB0byBiZSBl eHBlY3RlZD8pLiBBbHNvIG9uIEFTUm9jayBkaXNhYmxpbmcgQ1NNIHNob3VsZA0KPiA+Pj4+Pj4+ Pj4+Pj4+Pj4+IGVuc3VyZSBub3QgYm9vdGluZyBhIGR1YWwtYm9vdHN0cmFwLWNhcGFibGUgc3lz dGVtLiBUaGlzIHNhaWQsDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4gb24gdGhlIHJlY2VudCBGdWppdHN1 LCBpdCBzZWVtcyB0byBib2lsIGRvd24gdG8gYSBGcmVlQlNEDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4g VUVGSS1maXJtd2FyZSBpbnRlcmFjdGlvbiBwcm9ibGVtLCB3aGlsZSB0aGUgQVNSb2NrIGlzIHN0 aWxsDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4gdW5kZXIgc3VzcGljaW9uIHRvIGJlIGJyb2tlbiBieSBk ZXNpZ24uICAgICAgICAgICAgICAgDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBHUFQgcGFydGl0aW9ucyBjYW4gbmV2ZXIgc3RhcnQgZnJvbSBkaXNrIGFic29sdXRl IHNlY3RvciAxOw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGlzIGlzIGJlY2F1c2UgYXQgc2VjdG9y IDAgdGhlcmUgaXMgTUJSIChmb3IgY29tcGF0aWJpbGl0eSksDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHNlY3RvciAxIGlzIEdQVCB0YWJsZSBhbmQgdGhlbiBzZWN0b3JzIDItMzMgaGF2ZSBHUFQNCj4g Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcGFydGl0aW9uIHRhYmxlIGVudHJpZXMsIHNvIHRoZSBmaXJzdCBw b3NzaWJsZSBkYXRhIHNlY3RvciBpcw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+PiAzNCAoYWJzb2x1dGUg MzQpLiBUaGF0cyBhc3N1bWluZyA1MTJCIHNlY3RvcnMuIEZvciBkZXRhaWxzDQo+ID4+Pj4+Pj4+ Pj4+Pj4+Pj4+IHNlZSBVRUZJIDIuNyBDaGFwdGVyIDUuMy4xIHBhZ2UgMTMxLiAgICAgICAgICAg ICAgICANCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFua3MgZm9y IHRoZSBleHBsYW5hdGlvbi4gVGhhdCBpbXBsaWVzIHRoZSBpbnN0YWxsZXIgZGlkDQo+ID4+Pj4+ Pj4+Pj4+Pj4+Pj4gcmlnaHQsIGdwYXJ0IGRpZCBhbHNvIHJpZ2h0IGFuZCB0aGVyZWZvcmUgdGhl cmUgbXVzdCBiZSBhbg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+IGlzc3VlIHdpdGggdGhlIHN0dWZmIGxv Y2F0ZWQgd2l0aGluIHRoZSBFRkkNCj4gPj4+Pj4+Pj4+Pj4+Pj4+PiBwYXJ0aXRpb24/ICAgICAg ICAgICAgICAgDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+IE9rLCBzbywg aXQgaXMgbm90IGFib3V0IFVFRkkgYm9vdGNvZGUgYnV0IEJJT1MsIGFuZCBpZiB3ZSByZWFjaA0K PiA+Pj4+Pj4+Pj4+Pj4+Pj4gQklPUyBsb2FkZXIgYXQgYWxsIG9yIG5vdCAtIHRoYXQgaXMsIGlm IHRoZSBCSU9TIGJvb3RzdHJhcCBpcw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gYWN0dWFsbHkgY2FyaW5n IHRvIHJlYWQgdGhlIE1CUiBjb2RlIGFuZCBzdGFydCBpdCwgc2luY2Ugb25jZQ0KPiA+Pj4+Pj4+ Pj4+Pj4+Pj4gdGhlIE1CUiBjb2RlIGlzIHN0YXJ0ZWQsIGl0IGlzIGFsbCBhYm91dCBvdXIgY29k ZS4gICAgICAgICAgICAgIA0KPiA+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4gSSdt IGdldHRpbmcgY29uZnVzZWQgYSBiaXQgaGVyZS4gRG8geW91IG1lYW4gYnkgIkJJT1MiIHRoZSBD U00/DQo+ID4+Pj4+Pj4+Pj4+Pj4+IG9yIGRvIHlvdSBtZWFuIHRoYXQgc3BlY2lmaWMgcG9ydGlv biBvZiB0aGUgVUVGSSBmaXJtd2FyZSwgd2hpY2gNCj4gPj4+Pj4+Pj4+Pj4+Pj4gbG9va3MgZm9y IHRoZSBwcm9wZXIgVUVGSSBwYXJ0aXRpb24/DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgDQo+ID4+Pj4+ Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4+Pj4gQklPUyBhcyBlaXRoZXIgbmF0aXZlIG9yIENTTS4g Tm90ZSB0aGF0IGZyb20gYm9vdCBjb2RlIHBvaW50IG9mDQo+ID4+Pj4+Pj4+Pj4+Pj4gdmlldyB0 aGUgQ1NNIGJvb3QgKmlzKiBCSU9TIGJvb3QsIHdlIGhhdmUgbm8gYWNjZXNzIHRvIFVFRkkNCj4g Pj4+Pj4+Pj4+Pj4+PiBmZWF0dXJlcy4gICANCj4gPj4+Pj4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+ Pj4+Pj4+IFRoZSBib3hlcyBpbiBxdWVzdGlvbiwgbW9zdCBub3RhYmx5IHRoZSBtb3JlIHJlY2Vu dCBGdWppdHN1DQo+ID4+Pj4+Pj4+Pj4+Pj4+IEVzcHJpbW8gUTk1NiwgcmVmdXNlIGJvb3Rpbmcg VUVGSSwgZXZlbiBpZiBwcm9wZXJseSBzZXR1cCAoaW4NCj4gPj4+Pj4+Pj4+Pj4+Pj4gdGVybXMg b2Ygd2hhdCBGcmVlQlNEIHByb3ZpZGVzIG9uIHJlY2VudCBDVVJSRU5UKSBpcyBhcHBsaWVkIGFu ZA0KPiA+Pj4+Pj4+Pj4+Pj4+PiBDU00gaXMgc3dpdGNoZWQgb2ZmIGluIHRoZSBmaXJtd2FyZS4g QWdhaW46IEdQVCBwYXJ0aXRpb24gc2NoZW1lLg0KPiA+Pj4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+ Pj4+Pj4+Pj4gVGhlIHN5c3RlbSBib290cyBwcm9wZXJseSBpZiBhIHNlY29uZCBwYXJ0aXRpb24g b2YgdHlwZQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiAiZnJlZWJzZC1ib290IiBpcyBhcHBsaWVkIGFuZCBi b290Y29kZSBpcyBwcm9wZXJseSBhcHBsaWVkIHZpYQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiAiZ3BhcnQg Ym9vdGNvZGUgLWIgL2Jvb3QvcG1iciAtcCAvYm9vdC9ncHRib290IC1pIDIgYWRhMCIgKGFkYTAN Cj4gPj4+Pj4+Pj4+Pj4+Pj4gaXMgdGhlIGRldmljZSkuICAgICAgICAgICAgICAgDQo+ID4+Pj4+ Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4+IGJ0dywgeW91IGNhbiB0cnkgdG8gdmFsaWRh dGUgdGhlIGluc3RhbGxlZCBib290IGJsb2NrcyBieSB1c2luZw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4g cmVjZW50IGVub3VnaCBsb2FkZXIgKHVzYiBvciBpc28pIGFuZCB0aGVuIHlvdSBjYW4gdXNlIGZy b20gT0sNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IHByb21wdDogICAgICAgICAgICAgIA0KPiA+Pj4+Pj4+ Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+Pj4gbHNkZXYgcHJvdmlkZXMgbWUgd2l0aCB0aGUgZm9s bHdvaW5nIGluZm9ybWF0aW9ucyAoQ1NNIGVuYWJsZWQpOg0KPiA+Pj4+Pj4+Pj4+Pj4+PiANCj4g Pj4+Pj4+Pj4+Pj4+Pj4gT0sgbHNkZXYNCj4gPj4+Pj4+Pj4+Pj4+Pj4gZGlzayBkZXZpY2VzOg0K PiA+Pj4+Pj4+Pj4+Pj4+PiAJZGlzazA6CQlCSU9TIERSSVZFIEMgLi4uDQo+ID4+Pj4+Pj4+Pj4+ Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+PiAJCWRpc2swcDE6CUVGSQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiAJ CWRpc2swcDI6CUZyZWVCU0QgQk9PVA0KPiA+Pj4+Pj4+Pj4+Pj4+PiAJCWRpc2swcDM6CUZyZWVC U0QgU1dBUA0KPiA+Pj4+Pj4+Pj4+Pj4+PiAJCWRpc2swcDQ6CUZyZWVCU0QgWkZTDQo+ID4+Pj4+ Pj4+Pj4+Pj4+IHpmcyBkZXZpY2VzOg0KPiA+Pj4+Pj4+Pj4+Pj4+PiAJemZzOnpyb290DQo+ID4+ Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+PiBPSyBjaGFpbiBkaXNrMA0KPiA+Pj4+Pj4+ Pj4+Pj4+PiBvcGVuIGZhaWxlZCAgICAgKHNvIGZvciBkaXNrMHB7MS00fS4NCj4gPj4+Pj4+Pj4+ Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4+Pj4+IE9LIGNoYWluIHpyb290DQo+ID4+Pj4+Pj4+Pj4+Pj4+ IGZhaWxlZCB0byByZWFkIGRpc2sgKGp1c3QgZm9yIGNvbXBsZXRlbmVzcykgICAgICAgICAgICAg IA0KPiA+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+IGNo YWluIGNvbW1hbmQgZG9lcyB1c2Ugb25seSBkZXZpY2UgbmFtZSAoc3VjaCBhcyBkaXNrMDogb3IN Cj4gPj4+Pj4+Pj4+Pj4+PiBkaXNrMHAyOiApLCBidXQgbm90IHpmcyBwb29sIGFzIGRldmljZS4g IEkganVzdCBmb3VuZCBJIGhhdmVuP3QNCj4gPj4+Pj4+Pj4+Pj4+PiBwb3J0ZWQgdGhlIGNvZGUg dG8gcmVhZCB0aGUgZmlsZS4gICAgICAgICAgICANCj4gPj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+ Pj4+Pj4gPz8NCj4gPj4+Pj4+Pj4+Pj4+ICAgDQo+ID4+Pj4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+ Pj4+Pj4gdGhlIHBvaW50IGZvciBjaGFpbiBjb21tYW5kIHRlc3QgaXMgdG8gc2VlIGlmIHRoZSBu b3JtYWwgcmVhZCBhbmQNCj4gPj4+Pj4+Pj4+Pj4+PiBleGVjdXRlIHdvdWxkIHdvcmssIHNvIGlu IHlvdXIgY2FzZSBwbGVhc2UgdHJ5Og0KPiA+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+ IGNoYWluIGRpc2swOiAgICAgICAgICAgIA0KPiA+Pj4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4+ PiBBcyBzdGF0ZWQgYWJvdmUsIEkgZGlkIHNvLCBhbmQgdGhlIHJlc3VsdCBpcyBhbHNvIG1lbnRp b25lZCBhYm92ZSwNCj4gPj4+Pj4+Pj4+Pj4+IEkgYWx3YXlzIGdldCAib3BlbiBmYWlsZWQiLg0K PiA+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyB0aGUgc2FtZSBmb3IgDQo+ID4+Pj4+Pj4+Pj4+PiANCj4g Pj4+Pj4+Pj4+Pj4+IGNoYWluIGRpc2swDQo+ID4+Pj4+Pj4+Pj4+PiBjaGFpbiBkaXNrMHAxDQo+ ID4+Pj4+Pj4+Pj4+PiBjaGFpbiBkaXNrMHAyDQo+ID4+Pj4+Pj4+Pj4+PiBjaGFpbiBkaXNrMHAz DQo+ID4+Pj4+Pj4+Pj4+PiBjaGFpbiBkaXNrMHA0DQo+ID4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+ Pj4+Pj4+IGFzIGFscmVhZHkgc2FpZC4gQ1NNIGlzIGVuYWJsZWQgaW4gdGhpcyBjYXNlLiAgICAg ICAgICAgIA0KPiA+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4gc2lnaD8gY2hhaW4gY29tbWFu ZCBkb2VzIHRha2UgZGV2aWNlIGFzIGFyZ3VtZW50LCBkZXZpY2UgbXVzdCBhbHdheXMNCj4gPj4+ Pj4+Pj4+Pj4gZW5kIHdpdGggY29sb24/LiBpbiB0aGlzIGNhc2UsIHRoZSBkZXZpbCBpcyBpbiBk ZXRhaWxzOikgYXMgSSB3cm90ZQ0KPiA+Pj4+Pj4+Pj4+PiBhYm92ZSwgdGhlIGNvbW1hbmQgc2hv dWxkIGJlOg0KPiA+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4gY2hhaW4gZGlzazA6DQo+ID4+ Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBUaGUgZGlzazBwMTogZXRjIHdpbGwgb25seSB3b3Jr IHdoZW4gcGFydGl0aW9uIGJvb3QgY29kZSB3YXMNCj4gPj4+Pj4+Pj4+Pj4gaW5zdGFsbGVkICh3 aGljaCB5b3UgbW9zdCBsaWtlbHkgZG8gbm90IGhhdmUgLSB0aGUgb25seSBwb3NzaWJsZQ0KPiA+ Pj4+Pj4+Pj4+PiBjYW5kaWRhdGUgY291bGQgYmUgRnJlZUJTRCBaRlMgcGFydGl0aW9uKS4gICAg ICAgICAgDQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gVGhlIGNvbW1hbmQgImNoYWluIGRp c2swOiIgd29ya3MgYXMgZXhwZWN0ZWQgKENTTSBlbmFibGVkLCBHUFQNCj4gPj4+Pj4+Pj4+PiBw YXJ0aXRpb24gc2NoZW1lLCBidXQgd2l0aCBQTUJSIGJvb3RibG9jayBpbnN0YWxsZWQgYW5kIGZy ZWVic2QtYm9vdA0KPiA+Pj4+Pj4+Pj4+IHBhcnRpdGlvbiBjb25hdGluaW5nIGdwdHpmc2Jvb3Qg aW5zdGFsbGVkLg0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+ICAgDQo+ID4+Pj4+Pj4+Pj4+ ICAgDQo+ID4+Pj4+Pj4+Pj4+PiAgIA0KPiA+Pj4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+Pj4+ IHRvIHJlYWQgcG1iciAoNTEyQikgYW5kIGV4ZWN1dGUgaXQuIFRoZSBleHBlY3RlZCBvdXRjb21l IHdvdWxkIGJlDQo+ID4+Pj4+Pj4+Pj4+Pj4gdGhhdCBwbWJyIGJvb3QgY29kZSB3b3VsZCBicm93 c2UgdGhlIEdQVCwgcmVhZCBzdGFnZTEgZnJvbQ0KPiA+Pj4+Pj4+Pj4+Pj4+IGRpc2swcDI6IGFu ZCBleGVjdXRlIGl0OyBzdGFnZTEgd291bGQgZGV0ZWN0IEZyZWVCU0QgWkZTIGZyb20NCj4gPj4+ Pj4+Pj4+Pj4+PiBkaXNrMHA0OiBhbmQgbG9hZCBhbmQgZXhlY3V0ZSAvYm9vdC9sb2FkZXIuIElm IHRoYXQgd2lsbCBoYXBwZW4sDQo+ID4+Pj4+Pj4+Pj4+Pj4gaXQgbWVhbnMgdGhlIGJvb3QgY29k ZSBpbiBvdXIgc3RhZ2VzIGlzIGp1c3QgZmluZSwgYnV0IHRoZSBiaW9zDQo+ID4+Pj4+Pj4+Pj4+ Pj4gKENTTSkgZG9lcyBub3QgbG9hZCBwbWJyPy4gIGlmIHRoYXRzIHRydWUsIGl0IHdvdWxkIG1l YW4gdGhhdCB5b3UNCj4gPj4+Pj4+Pj4+Pj4+PiBlaXRoZXIgbmVlZCB0byB1c2UgVUVGSSBib290 IG9yIG5lZWQgdG8gaGF2ZSBzb21lIGhhY2sgdG8gZm9vbA0KPiA+Pj4+Pj4+Pj4+Pj4+IHRoZSBC SU9TIG9yIGp1c3Qgbm90IHVzZSBHUFQgb24gdGhhdCBtYWNoaW5lIHdpdGggQ1NNLiAgICAgICAg ICAgIA0KPiA+Pj4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4+PiBUbyBtYWtlIGl0IGNsZWFyIGhl cmU6IFRoZSBvbmx5IHdheSB0byBib290IHRoaXMgYm94IGlzIHVzaW5nIENTTQ0KPiA+Pj4+Pj4+ Pj4+Pj4gKGFzIGl0IGlzIHRoZSBzYW1lIHdpdGggdGhlIEFTUm9jayBib2FyZHMgbWVudGlvbmVk IGVhcmxpZXIpLiBCdXQNCj4gPj4+Pj4+Pj4+Pj4+IG15IGludGVudGlvbiBpcyB0byBkaXNhYmxl IENTTSBhbmQgdXNlIGEgR1BUL1VFRkkgZW52aXJvbm1lbnQNCj4gPj4+Pj4+Pj4+Pj4+IG9ubHkh IEFuZCBHUFQvVUVGSSBkb2Vzbid0IHdvcmsgd2l0aCBGcmVlQlNELCBuZWl0aGVyIHdpdGgNCj4g Pj4+Pj4+Pj4+Pj4+IDEyLUNVUlJFTlQsIG5vciAxMS4yLVJFTEVORy4NCj4gPj4+Pj4+Pj4+Pj4+ IA0KPiA+Pj4+Pj4+Pj4+Pj4gSXQgd291bGQgYmUgbmljZSBpZiB0aGlzIGNvdWxkIGJlIGZpeGVk LiBJJ20gbW9yZSBpbnRlcmVzdGVkIGluIHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4gZml4IG9uIHRoZSBy ZWNlbnQgRnVqaXRzdSBkZXZpY2UgdGhhbiB0aGUgb3V0ZGF0ZWQgQVNSb2NrIGNyYXAsIGJ1dA0K PiA+Pj4+Pj4+Pj4+Pj4gaWYgdGhlIGZpeCBmb3IgdGhlIEZ1aml0c3UgRmlybXdhcmUgY291bGQg Zml4IG9sZGVyIGlzc3VlcyBhcyBhDQo+ID4+Pj4+Pj4+Pj4+PiBieXByb2R1Y3QsIEknZCBhcHBy ZWNpYXRlIHRoYXQuDQo+ID4+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4+IEtpbmQgcmVnYXJk cywNCj4gPj4+Pj4+Pj4+Pj4+ICAgDQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBvaywg c29tZWhvdyBJIGhhdmUgbG9zdCB0aGF0IHBhcnQgb2YgdGhlIGRpc2N1c3Npb24uIFdlbGwsIHlv dSB3cm90ZQ0KPiA+Pj4+Pj4+Pj4+PiB0aGF0IHRoZSBVRUZJIGJvb3QgZmFpbHMgd2hlbiB0aGUg Zmlyc3QgcGFydGl0aW9uIHN0YXJ0cyBmcm9tIHNlY3Rvcg0KPiA+Pj4+Pj4+Pj4+PiA0MCAtIGRv ZXMgaXQgbWVhbiB5b3UgaGF2ZSBib290IHdoZW4gdGhlIHBhcnRpdGlvbiB3aWxsIHN0YXJ0IGZy b20NCj4gPj4+Pj4+Pj4+Pj4gc29tZSBvdGhlciBzZWN0b3I/IEkgdGhpbmssIHRoZXJlIGlzIHNv bWV0aGluZyBlbHNlIGdvaW5nDQo+ID4+Pj4+Pj4+Pj4+IG9uLiAgICAgICAgICANCj4gPj4+Pj4+ Pj4+PiANCj4gPj4+Pj4+Pj4+PiBXZWxsLCBJIHNpbXBseSB0cnkgdG8gZGVzY3JpYmUgd2hhdCBJ ICJzZWUiIHRvIG1ha2UgdGhpbmdzDQo+ID4+Pj4+Pj4+Pj4gZGlzYW1iaWd1b3VzLiBJJ20gbm90 IGZhbWlsaWFyIHdpdGggdGhlIGRlZXBlciBpbnNpZ2h0cyBvZiBkaXNrDQo+ID4+Pj4+Pj4+Pj4g bGF5b3V0cyBvbiBhIGJpbmFyeSBsZXZlbC4gU28sIHlvdSBleHBsYWluZWQgdG8gbWUgdGhlIHJl YXNvbiwgd2h5DQo+ID4+Pj4+Pj4+Pj4gRVNQIChFR0kgcGFydGl0aW9uKSBzdGFydHMgYXQgYmxv Y2sgNDAuIEkgY29tcGFyZWQgdGhhdCB0byB0aGUNCj4gPj4+Pj4+Pj4+PiBGcmVlQlNEIFVTQiBm bGFzaCBpbWFnZSBGcmVlQlNEIHByb3ZpZGVzLCBidXQgdGhpcyBpcyBhbm90aGVyIHN0b3J5DQo+ ID4+Pj4+Pj4+Pj4gc2luY2UgdGhlIGltYWdlIHVzZXMgTUJSIHNjaGVtZSBhcyBJIGZpZ3VyZWQg b3V0Lg0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+ICAgDQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+ Pj4+Pj4+Pj4+PiBXaGF0IHlvdSBjYW4gZG8gaXMgdG8gc2VlIGlmIHRoYXQgZmlybXdhcmUgd2ls bCBvZmZlciB5b3UgRUZJIHNoZWxsDQo+ID4+Pj4+Pj4+Pj4+IG9wdGlvbiwgZnJvbSB0aGVyZSB5 b3UgY2FuIHRyeSB0byBzdGFydCB0aGUgYm9vdHg2NC5lZmkgbWFudWFsbHkgYW5kDQo+ID4+Pj4+ Pj4+Pj4+IHNlZSB3aGF0IGVycm9yIHlvdSB3aWxsIGdldC4gSG93ZXZlciwgdGhlIG51bWJlciAx IGNhdXNlIGZvciBmYWlsaW5nDQo+ID4+Pj4+Pj4+Pj4+IHRvIHN0YXJ0IHRoZSBib290bG9hZGVy IGluIFVFRkkgaXMgc2VjdXJlIGJvb3QgLSB3ZSBkbyBub3Qgc3VwcG9ydA0KPiA+Pj4+Pj4+Pj4+ PiBpdCBhbmQgc2VjdXJlIGJvb3QgbXVzdCBiZSBzd2l0Y2hlZCBvZmYuIA0KPiA+Pj4+Pj4+Pj4+ PiANCj4gPj4+Pj4+Pj4+Pj4gSG93ZXZlciwgdGhleSBzZWVtIHRvIGNsYWltICJUaGUgU2VjdXJl IEJvb3Qgb3B0aW9uIGlzIGF2YWlsYWJsZSBpbg0KPiA+Pj4+Pj4+Pj4+PiB0aGUgVUVGSS9CSU9T IG9mIG1vc3QgaWYgbm90IGFsbCBBU1JvY2sgYm9hcmRzLiBJdCBpcyBkaXNhYmxlZCBieQ0KPiA+ Pj4+Pj4+Pj4+PiBkZWZhdWx0Lj8gDQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBTdGls bCBzdWdnZXN0IHRvIGRvdWJsZSBjaGVjayBpZiB0aGF0cyByZWFsbHkgdGhlIGNhc2UuIEFsc28s IGlmIHRoZQ0KPiA+Pj4+Pj4+Pj4+PiBib290eDY0LmVmaSBzdGFydCB3aWxsIGZhaWwgYW5kIG5v IG1lc3NhZ2VzIGFyZSBhcHBlYXJpbmcgb24gc2NyZWVuLA0KPiA+Pj4+Pj4+Pj4+PiB0aGVuIGVp dGhlciB0aGVyZSBpcyBzb21ldGhpbmcgaW4gZmlybXdhcmUgbG9ncyBvciB5b3UgY291bGQgZ2V0 DQo+ID4+Pj4+Pj4+Pj4+IHRoZW0gZnJvbSB0cnlpbmcgdG8gc3RhcnQgYm9vdHg2NC5lZmkgZnJv bSBVRUZJIHNoZWxsLiAgICAgICAgICANCj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBTaW5j ZSBJJ20gd2l0aCB0aGlzIHByb2JsZW0gc2luY2UgMjAxNCBhbmQgdHJ5IGZyb20gdGltZSB0byB0 aW1lLCBiZQ0KPiA+Pj4+Pj4+Pj4+IGF1c3JlZCB0aGF0IEkgdHJpZWQgZXZlcnkgcG9zc2libGUg cGVybXV0YXRpb25vZiBhbGwgcmVhc29uYWJsZQ0KPiA+Pj4+Pj4+Pj4+IG9wdGlvbnMsIGV2ZW4g dGhvc2Ugbm9uc2Vuc2UsIHRvIGdldCByaWQgb2YgdGhhdCBwcm9ibGVtLg0KPiA+Pj4+Pj4+Pj4+ IA0KPiA+Pj4+Pj4+Pj4+IEkgbmV2ZXIgaGFkIGFueSBwcm9ibGVtcyB3aXRoIGFueSBvdGhlciBV RUZJIGNhcGFibGUNCj4gPj4+Pj4+Pj4+PiBzZXJ2ZXIvd29ya3N0YXRpb24gZmlybXdhcmUgc28g ZmFyIGJvb3RpbmcgRnJlZUJTRCBvZmYgaW4NCj4gPj4+Pj4+Pj4+PiBVRUZJLW5hdGl2ZSAoR1BU IHBhcnRpdGlvbiBzY2hlbWUsIENTTSBkaXNhYmxlZCkgc28gZmFyIC0gdW50aWwgbm93LA0KPiA+ Pj4+Pj4+Pj4+IHdoZW4gSSByYW4gaW50byB0aGlzIEZ1aml0c3UgRVNQUklNTyBROTU2IHdpdGgg dGhlIG1vc3QgcmVjZW50DQo+ID4+Pj4+Pj4+Pj4gZmlybXdhcmUgKGFzIG9mIGxhdCB3ZWVrLCB3 ZWVrIDI5IG9mIDIwMTgpIGhhdmluZyB0aGUgdmVyeSBzYW1lDQo+ID4+Pj4+Pj4+Pj4gcHJvYmxl bXMuIA0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+ Pj4+Pj4+IEkgZmlndXJlZCBvdXQgc29tZXRoaW5nIHN0cmFuZ2Ugb24gdGhlIEZ1aml0c3UgLSBh bmQgdGhhdCBpcyB0aGUgc2FtZQ0KPiA+Pj4+Pj4+Pj4+IHdpdGggdGhlIEFTUm9jayBib2FyZHMu DQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gV2UvSSBwcmVwYXJlIHNvbWUgVVNCIGZsYXNo IGRyaXZlcyB0byBib290IGEgTmFub0JTRCBmb3IgYSB2ZXJ5IHNtYWxsDQo+ID4+Pj4+Pj4+Pj4g YXBwbGlhbmNlLCBidXQgbmV2ZXJ0aGVsZXNzLCB0aGUgVVNCIGZsYXNoIGRldmljZSBpcyBib290 ZWQgb24NCj4gPj4+Pj4+Pj4+PiBGdWppdHN1IHNlcnZlcnMgd2l0aCBVRUZJLW9ubHkgY29uZmln dXJhdGlvbnMuIEkgYXNzdW1lIGF0IHRoaXMNCj4gPj4+Pj4+Pj4+PiBwb2ludCB0aGF0IGRpc2Fi bGluZyBvbiB0aGUgbW9zdCByZWNlbnQgRnVqaXRzdSBmaXJtd2FyZXMgb24NCj4gPj4+Pj4+Pj4+ PiByZWFzb25hYmxlICJuZXciIGhhcmR3YXJlIChub3Qgb2xkZXIgdGhhbiB0aHJlZSB5ZWFycykg d2lsbCBkaXNhYmxlDQo+ID4+Pj4+Pj4+Pj4gYW55KCEpIGxlZ2FjeSBCSU9TIGNhcGFiaWxpdGll cy4gVGhlIHNhbWUgaXMgYXNzdW1lZCBmb3IgdGhlIEZ1aml0dXMNCj4gPj4+Pj4+Pj4+PiBFU1BS SU1PIFE5NTYuIEkgY2FuIG5vdCBzcGVhayBmb3IgdGhlIEFTUm9jayBBNzcgUHJvNC9tIGJvYXJk cw0KPiA+Pj4+Pj4+Pj4+IG1lbnRpb25lZCBhYm92ZS9lYXJsaWVyLCB0aGV5IGFyZSBmcm9tIDIw MTIvMjAxMyBhbmQgInF1aXRlIG9sZCIuDQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gVGhl IE5hbm9CU0QgaW1hZ2Ugb2Ygb3VycyBkb2Vzbid0IGhhdmUgYSAiZnJlZWJzZC1ib290IiBwYXJ0 aXRpb24uDQo+ID4+Pj4+Pj4+Pj4gVGhlIHBhcnRpdGlvbiBzY2hlbWUgb2YgdGhlIGZsYXNoIGRl dmljZSBpcyBHUFQuIFRoZSBsYXlvdXQgbG9va3MNCj4gPj4+Pj4+Pj4+PiBsaWtlIHRoaXM6DQo+ ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gZ3BhcnQgc2hvdyAtbCBkYTQgICAgICAgICAgDQo+ ID4+Pj4+Pj4+Pj4gPT4gICAgICA0MCAgMTU0MjU0NTYgIGRhNCAgR1BUICAoNy40RykgICAgICAg ICAgDQo+ID4+Pj4+Pj4+Pj4gICAgNDAgICAgICAyMDAwICAgIDEgIGVmaWJvb3QwICAoMS4wTSkN Cj4gPj4+Pj4+Pj4+PiAgMjA0MCAgIDE0NTM1ODQgICAgMyAgZGlzazFhICAoNzEwTSkNCj4gPj4+ Pj4+Pj4+PiAxNDU1NjI0ICAgICAgNDA5NiAgICA1ICBkaXNrMyAgKDIuME0pDQo+ID4+Pj4+Pj4+ Pj4gMTQ1OTcyMCAgMTM5NjU3NzYgICAgICAgLSBmcmVlIC0gICg2LjdHKQ0KPiA+Pj4+Pj4+Pj4+ IA0KPiA+Pj4+Pj4+Pj4+IEkgY3JlYXRlZCB0aGUgZmxhc2ggd2l0aCBtZCwgZ3BhcnQgYW5kIGRk IHN0cmFpZ2h0Zm9yd2FyZCwgZWZpYm9vdDANCj4gPj4+Pj4+Pj4+PiBpcyB0aGUgRVNQIHBhcnRp dGlvbiBhbmQgaXRzIGZvcm1hdC9jb250ZW50IGlzIGNyZWF0ZWQgdmlhIGRkDQo+ID4+Pj4+Pj4+ Pj4gaWY9L2Jvb3QvYm9vdDEuZWZpZmF0IG9mPS9kZXYvZGE0cDEgLSBJIHByZXN1bWUgdGhpcyBp cyB2ZXJ5IHNpbXBsZS4NCj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBUaGlzIFVTQiBmbGFz aCBkZXZpY2UgYm9vdHMoISkgc3VjY2Vzc2Z1bGx5IChVRUZJISkgb24gYm90aCB0aGUNCj4gPj4+ Pj4+Pj4+PiBBU1JvY2sgYm9hcmRzIGFuZCB0aGUgRXNwcmltbyBROTU2IQ0KPiA+Pj4+Pj4+Pj4+ IA0KPiA+Pj4+Pj4+Pj4+IEJ1dCBhbnkgU1NEIHByZXBhcmVkIHRoZSBzYW1lIHdheSBkb2Vzbid0 LiBXaHk/IA0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IE9uIHRoZSBBU1JvY2ssIEkgcmVj YWxsIGhhdmluZyBmaWRkbGVkIGFyb3VuZCB3aXRoIEhERCBhbHNvIGZvciBhDQo+ID4+Pj4+Pj4+ Pj4gd2hpbGUgY29uYXRpbmluZyBXaW5kb3dzIDcvU1AxIGFuZCBGcmVlQlNELiBXaW5kb3dzNyBi b290ZWQsIEZyZWVCU0QNCj4gPj4+Pj4+Pj4+PiAtIEkgY2FuJ3QgcmVtZW1iZXIuIA0KPiA+Pj4+ Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IEluIHRoZSBsYWNrIG9mIHByb3BlciBoYXJkd2FyZSBJJ20g dW5hYmxlIHRvIGNoZWNrIHdoZXRoZXINCj4gPj4+Pj4+Pj4+PiBVU0ItYXR0YWNoZWQgSEREIG9y IFNTRCB3aWxsIGJvb3Qgb3IgSEREIHdpbGwgYm9vdCAoanVzdCBpbiBjYXNlIHRoZQ0KPiA+Pj4+ Pj4+Pj4+IGxvY2FsIFNBVEEgaGFzIHByb2JsZW1zIGJvb3RpbmcgVUVGSSBhbmQgVVNCIG5vdCku DQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gS2luZCByZWdhcmRzLA0KPiA+Pj4+Pj4+Pj4+ IA0KPiA+Pj4+Pj4+Pj4+IE9saXZlciANCj4gPj4+Pj4+Pj4+PiAgIA0KPiA+Pj4+Pj4+Pj4gDQo+ ID4+Pj4+Pj4+PiBBbS4gd2VsbC4gSSB0aGluayB0aGUgc3VnZ2VzdGlvbiB0byB0ZXN0IG91dCBG QVQzMiBpcyBzdGlsbCBnb29kIG9uZQ0KPiA+Pj4+Pj4+Pj4gdG8gdGVzdC4gVGhpcyBpcyBiZWNh dXNlIGl0IGlzIGtub3duIHRoYXQgc29tZSB2ZW5kb3JzIGRvIG5vdCBzdXBwb3J0DQo+ID4+Pj4+ Pj4+PiBib290aW5nIEZBVDEyL0ZBVDE2IGZyb20gSEREICh0aGUgbGlrZWx5IHJlYXNvbiBpcyB0 aGF0IFVFRkkNCj4gPj4+Pj4+Pj4+IHNwZWNpZmljYXRpb24gZG9lcyBub3QgdGVsbCB3aGljaCBG QVQgbXVzdCBiZSBzdXBwb3J0ZWQsIGFuZCBvbmx5IGhpbnQNCj4gPj4+Pj4+Pj4+IGFib3V0IEZB VDEyL0ZBVDE2IGluIGNvbnRleHQgb2YgcmVtb3ZhYmxlIGRldmljZXMpLiAgICAgICAgDQo+ID4+ Pj4+Pj4+IA0KPiA+Pj4+Pj4+PiBJIHByZXBhcmVkIHllc3RlcmRheSBhIEdUUC9aRlMtb25seSAx MS4yLVJFTEVORyBvbiB0aGUgRVNQUklNTyBROTU2LiBJdA0KPiA+Pj4+Pj4+PiB0b29rIG1lIGEg dGltZSB0byBjaXJjdW12ZW50IHRoZSBpbnN0YWxsZXIgYW5kIEkgaGFkIHRvIGluc3RhbGwgdGhl DQo+ID4+Pj4+Pj4+IHN5c3RlbSBtYW51YWxseS4gSW4gdGhhdCBzdHJhaW4sIEkgYWxzbyAidHJp ZWQiIHRvIGVzdGFibGlzaCB0aGUgRVNQDQo+ID4+Pj4+Pj4+IHdpdGggRkFUMzIsIGFzIEFsbGVu IEp1ZGUgc3VnZ2VzdGVkIGVhcmxpZXIuIEkgZGlkbid0IGZpbmQgYW55IGFkIGhvYw0KPiA+Pj4+ Pj4+PiBoZWxwIGhvdyB0byBmaW5kIG91dCB0aGUgZm9ybWF0IChGQVQxMi8xNi8zMikgb2YgdGhl IEVTUCwgc28gSSBhc3N1bWUNCj4gPj4+Pj4+Pj4gd2hlbiB1c2luZyAxMi1DVVJSRU5UJ3Mgb3Ig MTEuMi1SRUxFTkcncyBpbnN0YWxsZXIgd2l0aCBBVVRPLVpGUyBhbmQNCj4gPj4+Pj4+Pj4gR1BU IChVRUZJKSAob25seSEpIHRoZSByZXN1bHRpbmcgRVNQIGlzIEZBVDEyIG9yIEZBVDE2ICgzMDBt YiBieQ0KPiA+Pj4+Pj4+PiBkZWZhdWx0KS4gSSBhbHNvIGFzc3VtZSwgdGhhdCB3aGVuIGRkJ2lu ZyB0aGUgL2Jvby9ib290MS5lZmlmYXQgaW1hZ2UNCj4gPj4+Pj4+Pj4gdG8gYSBwYXJ0aXRpb24s IHRoZSBmb3JtYXQgaXMgRkFULCBidXQgbm90IEZBVDMyLiBUaGVyZWZvcmUsIEkNCj4gPj4+Pj4+ Pj4gcmVmb21hdHRlZCB0aGUgbWFudWFsbHkgY3JlYXRlZCBFU1AgKHVzaW5nICJncGFydCBhZGQg LXQgZWZpIC4uLiIpDQo+ID4+Pj4+Pj4+IHVzaW5nICJuZXdmc19tc2RvcyAtRiAzMiAtYiB4eHgg Li4uIi4gSSBoYWQgdG8gZmlkZGxlIGFyb3VuZCBhIGJpdA0KPiA+Pj4+Pj4+PiB3aXRoIG9wdGlv biAtYiB0byBmaXQgaW4gYSBwcm9wZXIgZm9ybWF0IHRvIG1lZXQgYSA1MTJtYiBFU1AgLSBJJ20g bm90DQo+ID4+Pj4+Pj4+IHN1cmUgd2hldGhlciB0aGlzIGlzIHRoZSBwcm9wZXIgb3B0aW9uIHRv IGRlYWwgd2l0aC4gV2hlbiB1c2luZyB0aGUNCj4gPj4+Pj4+Pj4gZGVmYXVsdCBhbmQgb25seSAt RjMyLCB0aGUgc2l6ZSBvZiB0aGUgcGFydGl0aW9uIGhhcyB0byBiZSA0RyBhdCBsZWFzdA0KPiA+ Pj4+Pj4+PiBJIGFzc3VtZS4gSGF2aW5nIGRvbmUgdGhhdCwgSSBjb3BpZWQgdGhlIHRoZSBjb250 ZW50IG9mIGJvb3QxLmVmaWZhdA0KPiA+Pj4+Pj4+PiAobWRjb25maWcgLXQgdm5vZGUgLi4uLCBJ IGd1ZXNzIHdlIGtub3cgdGhlIGRyaWxsIC4uLikgdG8gdGhlIG5ld2x5DQo+ID4+Pj4+Pj4+IGZv cm1hdHRlZCBFU1AgdG8gL2Jvb3QvZWZpLyAuLi4NCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+IEhh dmluZyBzbyBmYXIgbm8ga25vd2xlZGdlIG9mIGhvdyB0byBhc3VyZSB0aGF0IHRoZSBjcmVhdGVk IEVTUCBpcw0KPiA+Pj4+Pj4+PiBGQVQzMiwgSSBhc3N1bWUgaXQgaXMgRkFUMzIuDQo+ID4+Pj4+ Pj4+IA0KPiA+Pj4+Pj4+PiBUaGUgcmVzdWx0IGlzIG5lZ2F0aXZlIG9uIHRoZSBFU1BSSU1PIFE5 NTYuIFdoZW4gZGlzYWJsaW5nIHRoZSBDU00sIHRoZQ0KPiA+Pj4+Pj4+PiBib3ggaXMgbm90IHdp bGxpbmcgdG8gYm9vdCBmcm9tIFNTRCB3aXRoIHRoZSBFU1AgcHJlcGFyZWQgYXMgZGVjcmliZWQu DQo+ID4+Pj4+Pj4+IFNvLCBhIGNoYW5jZSB0aGF0IHRoaXMgbWlnaHQgc3RpbGwgYmUgZHVlIHRv IGEgbWlzY29uZmlndXJhdGlvbiBsaWVzDQo+ID4+Pj4+Pj4+IG5vdyB3aXRoaW4gdGhlIC1iIG9w dGlvbiBvZiBuZXdmc19tc2RvcyAtIGlmIHRoZSAtYiBvcHRpb24gaXMgYXNzdW1lZA0KPiA+Pj4+ Pj4+PiB0aGUgcHJvcGVyIG9wdGlvbj8NCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+IEF0IHRoZSBt b21lbnQsIHRoZSBFU1Agb2YgdGhlIEVzcHJpbW8gaXMgc3ViamVjdCB0byBjaGFuZ2VzLCBpZiB5 b3UNCj4gPj4+Pj4+Pj4gd2lzaCwgYnV0IG5vdCBpbiBzaXplLCBzaW5jZSBpdCBpcyBsaW1pdGVk IHRvIDUxMm1iLg0KPiA+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4gVGhhbmtzIGFuZCBraW5kIHJlZ2Fy ZHMsDQo+ID4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+PiBPbGl2ZXIgICAgICAgIA0KPiA+Pj4+Pj4+IA0K PiA+Pj4+Pj4+IFllYSwgaSB3YXMgaG9waW5nIGZzdHlwIGNvbW1hbmQgd291bGQgcmVwb3J0IHRo ZSBGQVQgdHlwZSwgYnV0IGl0IGRvZXMNCj4gPj4+Pj4+PiBub3QgKHJlcXVlc3QgZm9yIGZlYXR1 cmU/OikgICAgICAgIA0KPiA+Pj4+Pj4gDQo+ID4+Pj4+PiBGWUksIHRoZSBmaWxlKDEpIGNvbW1h bmQgaXMgdmVyeSBnb29kIGF0IGRpc2VjdGluZyBhIGRpc2sgaW1hZ2UgdG8gdGVsbA0KPiA+Pj4+ Pj4geW91IHdoYXQgdGhlIE1CUiBsb29rcyBsaWtlLCBhbmQgYXQgbG9va2luZyBhdCBwYXJ0aXRp b25zIGlmIHBvaW50ZWQgYXQNCj4gPj4+Pj4+IHRoZW0gd2l0aCB0aGUgLXMgb3B0aW9uLiAgSXQg c2hvdWxkIGJlIGFibGUgdG8gZGV0ZWN0IEZBVDEyLzE2LzMyLg0KPiA+Pj4+Pj4gDQo+ID4+Pj4+ PiByb290QHgyMzBhOi9ob21lL0lTTy94ICMgZmlsZSAtcyAvZGV2L21kMnMxDQo+ID4+Pj4+PiAv ZGV2L21kMnMxOiBET1MvTUJSIGJvb3Qgc2VjdG9yLCBjb2RlIG9mZnNldCAweDNjKzIsIE9FTS1J RCAiQlNENC40ICAiLA0KPiA+Pj4+Pj4gcm9vdCBlbnRyaWVzIDUxMiwgc2VjdG9ycyAxNjAwICh2 b2x1bWVzIDw9MzIgTUIpICwgc2VjdG9ycy9GQVQgNSwNCj4gPj4+Pj4+IHNlY3RvcnMvdHJhY2sg NjMsIGhlYWRzIDEsIHNlcmlhbCBudW1iZXIgMHhiZDQxMTFlZSwgbGFiZWw6ICJFRklTWVMNCj4g Pj4+Pj4+ICIsIEZBVCAoMTIgYml0KSwgZm9sbG93ZWQgYnkgRkFUDQo+ID4+Pj4+PiAgIA0KPiA+ Pj4+Pj4+IA0KPiA+Pj4+Pj4+IEhvd2V2ZXIsIHRoZSBtb3JlIGFubm95aW5nIGlkZWEgd291bGQg YmUgdG8gaW5zdGFsbCBzb21lIE9TIHdoaWNoIHdpbGwNCj4gPj4+Pj4+PiBib290IHdpdGggVUVG SSBvbiB0aGlzIG1hY2hpbmUsIHRoZW4gY29weSBib290MS5lZmkgZnJvbSBmcmVlYnNkIHRvIGl0 DQo+ID4+Pj4+Pj4gKHRoZSBkZWZhdWx0IHByb2dyYW0gdGhlIFVFRkkgd2lsbCBsb2FkIGlzIEVT UDpFRkkvYm9vdC9ib290eDY0LmVmaSAgaW4NCj4gPj4+Pj4+PiBjYXNlIG9mIFVFRkk2NCBhbmQg RVNQOkVGSS9ib290L2Jvb3RpYTMyLmVmaSBmb3IgRUZJMzIuIEhvd2V2ZXIsIHdlIGRvDQo+ID4+ Pj4+Pj4gbm90IHN1cHBvcnQgRUZJMzIuDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gbm90ZSB0aGF0 IGJvb3QxLmVmaSBhbG9uZSB3aWxsIG5vdCBkbyBtdWNoIGJ1dCBwcmludGluZyBvbiBzY3JlZW4g aG93IGl0DQo+ID4+Pj4+Pj4gd2lsbCBzZWFyY2ggZm9yIGZyZWVic2QsIGJ1dCBmb3IgdGhlIHB1 cnBvc2Ugb2YgdGhlIHRlc3QgaXQgd291bGQNCj4gPj4+Pj4+PiBzdWZmaWNlDQo+ID4+Pj4+Pj4g LSB0aGF0IHdvdWxkIGdpdmUgdXMgY29uZmlybWVkIHdvcmtpbmcgRVNQIGZpbGUgc3lzdGVtIChz aW5jZSB0aGUgb3RoZXINCj4gPj4+Pj4+PiBvcyB3b3VsZCBiZSBhYmxlIHRvIGJvb3QpIGFuZCB0 aGVuIHdlIGNhbiBjb25maXJtIGlmIGJvb3QxLmVmaSBpdHNlbGYgaXMNCj4gPj4+Pj4+PiBPSy4g ICAgICAgIA0KPiA+Pj4+Pj4gICANCj4gPj4+Pj4gDQo+ID4+Pj4+IFNvbWUgbmV3IHJlc3VsdHMu DQo+ID4+Pj4+IEkgaW5zdGFsbGVkIFJlZEhhdCA3LjUgYW5kIGluZXN0aWdhdGVkIHRoZSBFU1Au DQo+ID4+Pj4+IA0KPiA+Pj4+PiAtIFRoZSBFU1Agc3RhcnRzIGF0IGJsb2NrIDIwNDgsIHdoaWxl IEZyZWVCU0QncyBFU1Agc3RhcnRzIGF0IGJsb2NrIDQwLg0KPiA+Pj4+PiAtIHNpemUgaXMgYm90 aCAyMDBtYiBpZiBpbnN0YWxsZWQgYXV0b21hdGljYWxseS4gSSBmb3JnaXQgdG8gaW52ZXN0aWdh dGUNCj4gPj4+Pj4gdGhlIEZBVCBmb3JtYXQsIGJ1dCB0aGlzIG1pZ2h0IGJlIHVubmVjZXNzYXJ5 IGFzIHNob3duIGZ1cnRoZXIgaW4gdGhpcw0KPiA+Pj4+PiBwb3N0Lg0KPiA+Pj4+PiAtIFJlZEhh dCdzIEVTUCBjb250YWlucyB+IDEwIE1CIG9mIGRhdGEgaW4gdHdvDQo+ID4+Pj4+IGZvbGRlcnMs IC9lZmkvYm9vdCwgL2VmaS9yZWRoYXQuIGNvcHlpbmcgRnJlZUJTRCdzIEJPT1RYNjQuZWZpIG92 ZXINCj4gPj4+Pj4gUmVkSGF0J3MgZG9lc24ndCBjaGFuZ2UgYW55dGhpbmcsIGFsc28gcmVuYW1p bmcgL2VmaS9ib290L2ZieDY0LmVmaSBvZg0KPiA+Pj4+PiBSZWRIYXQncyBpbnN0YWxsYXRpb24u IEJ1dCByZW5hbWluZyAvZWZpL3JlZGhhdCByZW5kZXJzIFJlZEhhdCB0byBmYWlsIHRoZQ0KPiA+ Pj4+PiBib290IHByb2Nlc3Mgb24gdGhlIEZ1aml0c3Ugd2l0aCB0aGUgc2lnbnMgb2YgdGhlIGJ1 aWx0LWluIHRlc3Rwcm9ncmFtIGFzDQo+ID4+Pj4+IHJlcG9ydGVkLg0KPiA+Pj4+PiANCj4gPj4+ Pj4gSSB0b29rIHRoZSBsaWJlcnR5IGFuZCBpbnN0YWxsZWQgMTEuMi1SRUxFTkcgYWdhaW4sIFpG UyBvbmx5LCBVRUZJIGJvb3QNCj4gPj4+Pj4gb25seSAoQ1NNIGluIGZpcm13YXJlIGRpc2FibGVk LCBidXQgdGhlcmUgaXMgc3RpbGwgYSBncHR6ZnNib290LXByZXBhcmVkDQo+ID4+Pj4+IHBhcnRp dGlvbiBmb3IgbGF0ZXIgdXNlLCBqdXN0IGZvciB0aGUgcmVjb3JkKS4gQm9vdGluZyBVRUZJLW9u bHkgZmFpbHMgYXMNCj4gPj4+Pj4gcmVwb3J0ZWQuIE9uIHRoaXMgaW5zdGFsbGF0aW9uIEkgY29w aWVkIHRoZSBSZWRIYXQgRVNQIGNvbXBsZXRlbHkgaW50bw0KPiA+Pj4+PiBGcmVlQlNEJ3MgRVNQ LCByZW5hbWVkIC9lZmkvYm9vdC9CT09UWDY0LmVmaSB0byAvZWZpL2Jvb3QvQk9PVFg2NC5lZmku cmgNCj4gPj4+Pj4gYW5kIGNvcGllZCBGcmVlQlNEJ3MgQk9PVFg2NC5lZmkgdG8gL2VmaS9ib290 LiANCj4gPj4+Pj4gVGhlIEVzcHJpbW8gUTk1NiB0cmllcyB0aGVuIHRvIGJvb3QoISkgUmVkSGF0 J3Mga2VybmVsLiBJdCBzZWVtcywgdGhhdA0KPiA+Pj4+PiB0aGUgL2VmaS9yZWRoYXQgZm9sZGVy IG9mIHRoZSBFU1AgaXMgaW1wb3J0YW50LCBpZiByZW5hbWVkLCB0aGUgd2hvbGUNCj4gPj4+Pj4g cHJvY2VzcyBkaWVzIGFzIEkgcmVwb3J0ZWQgZWFybGllci4NCj4gPj4+Pj4gDQo+ID4+Pj4+IFN0 aWxsIHVuYW5zd2VyZWQgaXMgdGhlIHF1ZXN0aW9uOiB3aHkgaXMgYSBOYW5vQlNEIHByZXBhcmVk IFVFRkktb25seSBVU0INCj4gPj4+Pj4gZmxhc2ggYm9vdGluZyB3aXRoIENTTSBkaXNhYmxlZCAo c28gYXN1bWluZ2x5IFVFRkkgb25seSB0aGVuKSBvbiBib3RoDQo+ID4+Pj4+IEFTUm9jayBhbmQg RnVqaXRzdSAoYXMgZGVzY3JpYmVkIGluIG1vcmUgZGV0YWlsIGluaXRpYWxseSBhbmQgZWFybGll ciksDQo+ID4+Pj4+IHdoaWxlIFNTRHMgZmFpbD8gSXMgdGhlcmUgYSBkaWZmZXJlbmNlPyBTaW5j ZSBGcmVlQlNEIGJvb3RzIGluIFVFRkkgbW9kZQ0KPiA+Pj4+PiBmcm9tIFVTQiBmbGFzaCBwcmVw YXJlZCBhcyBkZXNjcmliZWQgKHN0cmFpZ2h0IGZvcndhcmQsIDgwMGsgRVNQIHN0YXJ0aW5nDQo+ ID4+Pj4+IGF0IGJsb2NrIDQwLCB0aGUgYm9vdDEuZWZpZmF0IGltYWdlIGRkJ2VkIG9udG8gdGhl IHBhcnRpdGlvbiwgVUZTDQo+ID4+Pj4+IHBhcnRpdGlvbiBmb2xsb3dpbmcsIG5vIGZyZWVic2Qt Ym9vdCBwYXJ0aXRpb24gb3IgTUJSL1BNQlIgYm9vdGNvZGUNCj4gPj4+Pj4gYXBwbGllZCBldmVy ISksIEkgdGhpbmsgQk9PVFg2NC5FRkkgaXMgdGVjaG5pY2FsbHkgYWxsIHJpZ2h0LiBUaGVyZSBt dXN0DQo+ID4+Pj4+IGJlIHRoZW4gYW4gaXNzdWUgd2l0aCB0aGUgU0FUQS9TU0QvSEREIGJvb3Qg cGF0aHdheS4NCj4gPj4+Pj4gDQo+ID4+Pj4+IEhvcGUgSSBjb3VsZCBwcm92aWRlIHNvbWUgbW9y ZSBkZXRhaWxzLCBzb3JyeSBpZiBpdCBzb3VuZHMgY29uZnVzaW5nIG9yDQo+ID4+Pj4+IHdheSB0 b28gbG9uZywgYnV0IEkgdHJ5IHRvIGRlc2NpYmUgdGhlIHNpdHVhdGlvbiBhcyB0aG9yb3VnaCBh cyBwb3NzaWJsZS4NCj4gPj4+Pj4gICANCj4gPj4+PiANCj4gPj4+PiBPSywgdGhpcyBpcyBhbHJl YWR5IGdvb2QgaGludC4gVGhlIHRoaW5nIHdpdGggRVNQIGlzIHRoYXQgdGhlcmUgaXMNCj4gPj4+ PiDigJxkZWZhdWx04oCdIGZpbGUgc3lzdGVtIHRyZWU6IEVGSS9CT09UL0JPT1Q8c3lzbmFtZT4u RUZJLCB0aGlzIGlzIG5vdGVkIGFzDQo+ID4+Pj4gZGVmYXVsdCBmb3IgKnJlbW92YWJsZSogbWVk aWEsIGZvcnR1bmF0ZWx5IGl0IGlzIHVzYWJsZSBmb3IgaGFyZCBkaXNrcyBhcw0KPiA+Pj4+IHdl bGwsIG9yIGF0IGxlYXN0IGluIG1vc3QgY2FzZXMuDQo+ID4+Pj4gDQo+ID4+Pj4gTm93LCBmb3Ig bm9uLXJlbW92YWJsZSBtZWRpYSwgdGhlIFVFRkkgZG9lcyBwcm92aWRlIGJvb3QgbWFuYWdlciBp bnRlcmZhY2UNCj4gPj4+PiB0byBkZWZpbmUgYm9vdCBlbnRyaWVzLCBhbmQgdGhlIGZhY3QgdGhh dCByZW5hbWluZyBlZmkvcmVkaGFkIGRpcmVjdG9yeSBkaWQNCj4gPj4+PiBicmVhayB0aGUgcmVk aGF0IGJvb3QsIGlzIHZlcnkgbG91ZCBoaW50LiBBbmQgdGhpcyBtZWFucywgdGhpcyBzeXN0ZW0g aXMNCj4gPj4+PiBwcm9iYWJseSBpZ25vcmluZyBlZmkvYm9vdCB0cmVlIG9uIG5vbi1yZW1vdmFi bGUgbWVkaWEgYW5kIGlzIGV4cGVjdGluZyB0aGUNCj4gPj4+PiBib290IG1hbmFnZXIgZW50cnkg dG8gYmUgY3JlYXRlZCBpbnN0ZWFkLiAgICANCj4gPj4+IA0KPiA+Pj4gVGhpcyBpbnBsaWNhdGlv biBJJ2QgY29uZmlybSBmb3IgdGhlIHJlY2VudCBGdWppdHN1IEVTUFJJTU8gUTk1NiBmaXJtd2Fy ZQ0KPiA+Pj4gKG5vdCB0ZXN0ZWQgb24gQVNSb2NrIFo3Ny1Qcm80IGZpcm13YXJlKS4NCj4gPj4+ ICAgDQo+ID4+Pj4gDQo+ID4+Pj4gVUVGSSBib290IG1hbmFnZXIgY2FuIGJlIGNvbmZpZ3VyZWQg L3VzdWFsbHkvIG1hbnVhbGx5IHZpYSBmaXJtd2FyZSBtZW51LA0KPiA+Pj4+IG9yIGJ5IGFwcGxp Y2F0aW9uLCBzdWNoIGFzIGVmaWJvb3RtZ3IuIFRoZSBub3JtYWwgYXBwcm9hY2ggaXMgdG8gY3Jl YXRlDQo+ID4+Pj4gZWZpLzx2ZW5kb3JuYW1lPiBkaXJlY3RvcnkgYW5kIHRvIGNvcHkgdGhlIGFw cGxpY2F0aW9uIHRoZXJlLCB0aGVuIGNyZWF0ZQ0KPiA+Pj4+IHRoZSBib290IG1hbmFnZXIgY29u ZmlndXJhdGlvbi4NCj4gPj4+PiANCj4gPj4+PiBTZWUgVUVGSSBzcGVjaWZpY2F0aW9uIHYyLjcs IGNoYXB0ZXIgMyBCb290IE1hbmFnZXIsIHBhZ2UgNzkuDQo+ID4+Pj4gDQo+ID4+Pj4gV2hhdCBp cyBkaWZmZXJlbnQgaW4gRnJlZUJTRCBjYXNlIGlzIHRoYXQgdGhlIHdob2xlIGludGVyZmFjZSB0 byBwcm9ncmFtDQo+ID4+Pj4gdGhlIFVFRkkgQm9vdCBNYW5hZ2VyIGlzIGN1cnJlbnRseSBiZWlu ZyBkZXZlbG9wZWQsIHNvIGVpdGhlciBpdCBoYXMgdG8gYmUNCj4gPj4+PiBkb25lIG1hbnVhbGx5 IG9yIGZyb20gc29tZSBvdGhlciBPUyAoc2VlDQo+ID4+Pj4gaHR0cHM6Ly93aWtpLmdlbnRvby5v cmcvd2lraS9FZmlib290bWdyDQo+ID4+Pj4gPGh0dHBzOi8vd2lraS5nZW50b28ub3JnL3dpa2kv RWZpYm9vdG1ncj4gZm9yIGV4YW1wbGUsIGZpcnN0IGhpdCBmcm9tDQo+ID4+Pj4gZ29vZ2xlOkQp LiAgICANCj4gPj4+IA0KPiA+Pj4gV2VsbCwgdGhhbmtzIGZvciB0aGlzIGltcG9ydGFudCBoaW50 ISBGcmVlQlNEIDEyLUNVUlJFTlQncyBhbmQgRnJlZUJTRA0KPiA+Pj4gMTEuMi1SRUxFTkcncyBV U0IgZmxhc2ggZGV2aWNlcyBhcmUgY2FwYWJsZSBvZiBib290aW5nIG9mZiBvbiBGdWppdHN1J3MN Cj4gPj4+IEVTUFJJTU8gYW5kIEFTUm9jaydzIGJvYXJkcy4gQXMgYSBub3RlOiBhZnRlciAia2xk bG9hZCBlZmlydC5rbyIgSSB3YXMgYWJsZQ0KPiA+Pj4gdG8gdXNlIHRoZSBhbHJlYWR5IGluIEZy ZWVCU0QgcHJlc2VudCB0b29sc2V0IGVmaWJvb3RtZ3IoOCkgYW5kIHNpYmJsaW5ncw0KPiA+Pj4g KHRoZSB0b29scyBkbyBub3QgZG8gYW55dGhpbmcgdXNlZnVsIHdoZW4gYm9vdGVkIG5vbi1VRUZJ KS4NCj4gPj4+IA0KPiA+Pj4gTW91bnRpbmcgdGhlIEVTUCBvZiB0aGUgaGFyZGRyaXZlIChpbiBt eSBjYXNlLCBhZGEwcDEpIHRvIC9tbnQgYW5kIGZvbGxvd2luZw0KPiA+Pj4gdGhlIHN0ZXBzIGlu IHRoZSBleGFtcGxlcyBhbmQgaGF2aW5nIGNyZWF0ZWQgL2VmaS9mcmVlYnNkL0JPT1R4NjQuZWZp IGFzDQo+ID4+PiByZWNvbW1lbmRlZCBieSBjb3B5IGZyb20gL2VmaS9ib290LCBsZXQgbWUgY3Jl YXRlIGEgcHJvcGVyIGJvb3QgdmFyaWFibGUuDQo+ID4+PiANCj4gPj4+IFRvIG1ha2UgdGhpbmdz IHN1cmUsIEkgYWxzbyBhcHBsaWVkICJlZmlib290bWdyIC1hIFZBUklBQkxFTkFNRSIuDQo+ID4+ PiANCj4gPj4+IEFuZCAuLi4gaXQgd29ya2VkISBZZXMsIGl0IHdvcmtlZCEgVGhlIEVTUCBpcyBG QVQzMiBmb3JtYXR0ZWQsIEkgZG8gbm90IGtub3cNCj4gPj4+IHdoZXRoZXIgdGhpcyB3aWxsIGFs c28gd29yayB3aXRoIEZBVDEyLzE2LCBJIHNob3VsZCB0ZXN0IHRoaXMgY2FzZSwgdG9vLg0KPiA+ Pj4gDQo+ID4+PiBUaGVyZSBpcyBhIGJ1ZyBpbiB0aGUgbWFucGFnZSBvZiBlZmlib290bWcoOCku IEl0IGRvZXMgbm90IGV4cGxhaW4gdGhlDQo+ID4+PiBvcHRpb25zIC1kIGFuZCAtcCwgYWx0aG91 Z2ggdGhleSBjb3VsZCBiZSAiaW1wbGllZCIgYnkgcmVhZGluZyBjYXJlZnVsbHkuDQo+ID4+PiBU aGVyZSBpcyBub3cgYSBQUiBhdCANCj4gPj4+IA0KPiA+Pj4gaHR0cHM6Ly9idWdzLmZyZWVic2Qu b3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yMzAwODANCj4gPj4+IA0KPiA+Pj4gZm9yIHRo aXMgaXNzdWUuDQo+ID4+PiANCj4gPj4+IFNvLCBpdCdzIGFwaXR5IHRoYXQgdGhlIGhhbmRib29r IGhhcyBubyBub3RlIEkgY291bGQgZWFzaWx5IGZpbmQgb24gdGhpczsgDQo+ID4+PiANCj4gPj4+ IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcGF0aWVuY2UgYW5kIGhlbHAhDQo+ID4+PiAN Cj4gPj4+IEtpbmQgcmVnYXJkcywNCj4gPj4+IE9saXZlciAgICANCj4gPj4gDQo+ID4+IHllcCwg ZWZpYm9vdG1nciBkb2VzIGNhbGwgVUVGSSBSdW50aW1lU2VydmljZXMgdG8gc2V0IHVwIHRoZSB2 YXJpYWJsZXMsIGFuZA0KPiA+PiB0aGlzIGlzIG9ubHkgcG9zc2libGUgd2hlbiBib290ZWQgVUVG SS4gQnV0IGdsYWQgd2UgZmluYWxseSBmb3VuZCB0aGUgcm9vdA0KPiA+PiBjYXVzZS4gSXQgd291 bGQgYmUgZ29vZCB0byBoYXZlIEhXIG5vdGVzIGZvciBzdWNoIGNhc2VzLCBpdCBpcyBpbXBvcnRh bnQgdG8NCj4gPj4ga25vdyB0aGF0IHRob3NlIHN5c3RlbXMgd29udCBib290IFVFRkkgZnJvbSBI REQgdW5sZXNzIHRoZSBib290IG1hbmFnZXIgc2V0dXANCj4gPj4gaXMgZG9uZS4NCj4gPj4gDQo+ ID4+IHJnZHMsDQo+ID4+IHRvb21hcyAgDQo+ID4gDQo+ID4gDQo+ID4gVGhpcyBwb3BzIHVwIHRo ZSBxdWVzdGlvbiBob3cgdG8gZGVhbCB3aXRoIHN1Y2ggSFcuIFdlIGhhdmUgYXMgYSBpbnN0aXR1 dGlvbiBhDQo+ID4gbG90IG9mIEZ1aml0c3UgaGFyZHdhcmUgaGVyIC0gZnJvbSBsYXJnZXIgc2Vy dmVycyBkb3duIHRvIEZ1aml0c3UgRVNQUklNTyBROTU2Lg0KPiA+IFRoZSBsYXR0ZXIgb25lIGlz IHRoZSBmaXJzdCAoYW5kIHNvIGZhciB0aGUgb25seSkgcGllY2Ugb2YgaGFyZHdhcmUgSSBmb3Vu ZA0KPiA+IGluY2FwYWJsZSBvZiBib290aW5nIG9mZiBVRUZJIHdpdGhpbiB0aGUgcGFzdCA1IHll YXJzLg0KPiA+IA0KPiA+IElmIHRoZSAic3RhbmRhcmQiIGZvciByZW1vdmVhYmxlIGRldmljZXMg aXMgdG8gYm9vdCBmcm9tIC9lZmkvYm9vdC9ib290eDY0LmVmaSwNCj4gPiB0aGFuIEknZCBndWVz cyBpdCBpcyBnb29kIGx1Y2sgZm9yIEZyZWVCU0QgdGhhdCB0aGUgZmlybXdhcmUgdmVuZG9ycyBk aWQNCj4gPiBmYWxsYmFjayB0byBzdWNoIGEgbWVjaGFuaXNtLiBHUlVCL0xpbnV4IHNlZW0gdG8g aW5zdGFsbCBieSBkZWZhdWx0IHRoZWlyDQo+ID4gYm9vdGxvYWRlciBpbnRvIC9lZmkvc29tZXRo aW5nLyBJJ2xsIGNoZWNrIG9uIERlYmlhbiwgU3VzZSBhbmQgQ2VudE9TIHNvIGZhcg0KPiA+IHNv b24sIHRoZSBsYXR0ZXIgcHJvYmFibHkgd2lsbCwgc2luY2UgaXRzIHRoZSAiZnJlZSIgUmVkSGF0 KS4NCj4gPiANCj4gPiBBbnl3YXksIGFwYXJ0IGZyb20gYW55IGNyaXRpY2lzbSwgSSdtIGdsYWQg dG8gaGF2ZSB0aGUgdG9vbHMgdG8gbWFrZSB0aGluZ3MNCj4gPiB3b3JrIHdpdGhvdXQgdXNpbmcg YWxpZW4gaGVscCAob3V0c2lkZSBGcmVlQlNEJ3Mgd29ybGQhKS4gVGhhdCBpcyBhIHRoYW5rIHlv dQ0KPiA+IHRvd2FyZHMgdGhlIGRldmVsb3BlcnMuDQo+ID4gDQo+ID4gS2luZCByZWdhcmRzLA0K PiA+IA0KPiA+IG9oDQo+ID4gICANCj4gDQo+IFRoZSBlZmlib290bWdyIGlzIG9ubHkgcmVsYXRp dmVseSByZWNlbnQgYWRkaXRpb24gKGluIGlsbHVtb3Mgd2UgZG8gbm90IGhhdmUgeWV0IGV2ZW4N Cj4gYWNjZXNzIHRvIFVFRkkgUlMpLCBzbyBpdCBpcyBvbmx5IHF1ZXN0aW9uIG9mIHRpbWUgb25j ZSBpbnN0YWxsZXIgd2lsbCBnZXQgdXBkYXRlZDopDQo+IA0KPiBCdXQgb2YgY291cnNlIHRoZXJl IGlzIHN0aWxsIGFuIGlzc3VlIGFib3V0IHRoZSBzY2VuYXJpbyB3aGVuIHRoZSBpbnN0YWxsIGlz IGRvbmUgaW4NCj4gQklPUyBtb2RlIGFuZCBsYXRlciBzd2l0Y2hlZCB0byBVRUZJIC0gdGhlbiB0 aGUgYm9vdCBtYW5hZ2VyIGNvbmZpZ3VyYXRpb24gbmVlZHMgdG8gYmUNCj4gdXBkYXRlZCBtYW51 YWxseSAob3IgYnkgc29tZSBtYWludGVuYW5jZSBzZXJ2aWNlIGxpa2UgZ3J1YjIgaXMgY2FsbGlu ZyB2aWEgZ3J1Yi1pbnN0YWxsDQo+IHNjcmlwdCkuDQo+IA0KPiByZ2RzLA0KPiB0b29tYXMNCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGZy ZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0cHM6Ly9saXN0cy5m cmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtY3VycmVudA0KPiBUbyB1bnN1YnNj cmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vic2NyaWJlQGZyZWVi c2Qub3JnIg0KDQpKdXN0IHRvIGFkZCBhbm90aGVyIHN1Y2Nlc3Mgb24gQVNSb2NrIFo3Ny1Qcm80 ICg4MDBrIEVTUCwgRkFUMTIpIGFuZCBBU1JvY2sgWjc3LVBybzRNDQooMzAwbWIgRVNQLCBGQVQz MikuDQoNCk9uIHRoaXMgZmlybXdhcmUsIEkgZGlkIG5vdCBoYXZlIHRvIGRlZmluZS9jb3B5IHRo ZSBib290bG9hZGVyDQp3aXRoaW4gL2VmaS9mcmVlYmQvQk9PVHg2NC5lZmkuIEl0IHdhcyBzdWZm aWNpZW50IHRvIGFkZCBhbiBFRkkgdmFyaWFibGUgYXMgZGVzY3JpYmVkIGluDQp0aGUgbWFucGFn ZSBlZmlib290bWdyKDgpLg0KDQpUaGUgb25seSBwaXRmYWxsIG9uIHRoaXMgZmlybXdhcmUgKHZl cnkgb2xkLCBsYXN0IGZ1bmN0aW9uYWwgdXBkYXRlIDIwMTMsDQpTcGVjdHJlL01lbHRvZG93biBt aXRpZ2F0aW9uIG9ubHkgTWF5IDIwMTgpIHdhcyB0aGF0IEkgd2Fzbid0IGFibGUgdG8gYWN0aXZh dGUgdmFyaWFibGUNCiIwMDAwIiEgQ3JlYXRpbmcgDQoNCmVmaWJvb3RtZ3IgLWMgLWwgL21udC9l ZmkvYm9vdC9CT09UeDY0LmVmaSAtTCBGcmVlQlNELTEyDQoNCndoaWNoIHJlc3VsdHMgaW4gIkJv b3QwMDAwIg0KDQphbmQgZm9sbG93ZWQgYnkgDQoNCmVmaWJvb3RtZ3IgLWEgMDAwMA0KDQpvciAN Cg0KZWZpYm9vdG1nciAtbiAwMDAwDQoNCnJlc3VsdGVkIGluICJObyBzdWNoIHZhcmlhYmxlIiBv ciBzaW1pbGFyLg0KDQpJIGhhZCB0byBwZXJmb3JtIHRoZSB2ZXJ5IHNhbWUgdGFzayBhZ2FpbiB0 byBnYWluIHZhcmlhYmxlIDAwMDEgYW5kIHRoZW4gSSB3YXMgYWJsZSB0bw0KImFjdGl2YXRlIiB2 YXJpYWJsZSAwMDAwLiBUaGlzIG1pZ2h0IGJlIGR1ZSB0byB0aGUgZmFjdCB0aGUgb25seSB2YXJp YWJsZSBkZWZpbmVkIGF0IGFsbA0Kd2FzIEJvb3QwMDA1IHBvaW50aW5nIHRvIHRoZSBtb3N0IHJl Y2VudCBVU0IgZmxhc2ggZGV2aWNlIHdpdGggMTItQ1VSUkVOVCBmcm9tIDIwMTgtMDctMjYNCkkg anVzdCBwcmVwYXJlZC4NCg0KTm93LCBhbHNvIHRob3NlIGJveGVzIGJvb3QgdmlhIFVFRkkgKG9u ZSwgODAwayBFU1Agd2l0aCB0aGUgL2VmaS9ib290IGZvbGRlciwgdGhlIG90aGVyLA0KMzAwbWIg RVNQLCB3aXRoIGEgY29weSAvZWZpL2ZyZWVic2QgYXMgSSBoYWQgdG8gZG8gb24gdGhlIEZ1aml0 c3UgRVNQUklNTyBROTU2IGZpcm13YXJlKS4NCg0KS2luZCByZWdyYWRzLA0KDQpPbGl2ZXINCg0K LSAtLSANCk8uIEhhcnRtYW5uDQoNCkljaCB3aWRlcnNwcmVjaGUgZGVyIE51dHp1bmcgb2RlciDD nGJlcm1pdHRsdW5nIG1laW5lciBEYXRlbiBmw7xyDQpXZXJiZXp3ZWNrZSBvZGVyIGbDvHIgZGll IE1hcmt0LSBvZGVyIE1laW51bmdzZm9yc2NodW5nICjCpyAyOCBBYnMuIDQgQkRTRykuDQotLS0t LUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQppTFVFQVJNS0FCMFdJUVFaVlpNekF0d0MyVC84 NlRyUzUyOGZ5RmhZbEFVQ1cxdFE4d0FLQ1JEUzUyOGZ5RmhZDQpsR3VRQWdDWndXa1p3ZDJJYTVw cFFoQW1sd0lGdjJoWHNRem9xMklUL2E4c3lBRFFWM0hib2ZMdDF2VGZRb2k2DQpMOWRFUVQ4SllU MnVEeFZMeHVlWVFzYzNZT21CQWY5T1hKUTc1Mm1TcHpFbnlZeTJSbmxITjFoWHUycGk0L2k3DQpE anI4czU3NFlWNjFVVUpJY3luZllyV1dzSnk1QUZzMXZoKzg3MTJnQThsbVExM3pRcXZuDQo9WXFk dA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-current@freebsd.org Fri Jul 27 17:21:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0A1910515FA for ; Fri, 27 Jul 2018 17:21:54 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 7258B7E6FE for ; Fri, 27 Jul 2018 17:21:54 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: by mail-pf1-x435.google.com with SMTP id d14-v6so1954298pfo.3 for ; Fri, 27 Jul 2018 10:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:mime-version:subject:message-id:date:to; bh=e97dDElyT+FRiEZ+6Qrd6xWJim0y0gmBAJlass9p5yQ=; b=GEUYRhStwzAVmvBvDnmYbuyYlQ1f/A92okr51affNIAO1CSkIbdBzq0Bug7qrPjxo/ slSlpZGK40bXlMDJ0p/e/8RQIcrSw+4z2P06qOwTaO5Wc4+PMc5L3+E3Gsm4sbGKHixB U+iXYaU3mVAZFU0b9xhMUXdNSAN/6Evfj4DsobCQ0pM97D8cUIphL32dlOpQYxfML89J j5QP9A2Q0PVY3lRyk0toT2Vyi8eWJdW5qzvckq2gEfuy//U47mRPI4ZlBMDx0kI1J0Ph VYKBjvpr73jO6osE+6UwsfgSop47MVkLP787Z5rTaqpCu6hvS9oZfNYhoDc9r9cvOvKV 5dTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:mime-version:subject:message-id:date :to; bh=e97dDElyT+FRiEZ+6Qrd6xWJim0y0gmBAJlass9p5yQ=; b=mDzJmjEUjSXzRWc7fG6R43BXJCMefqcUo1139sZQhkwJNP24w+DabWJdqd6lR8MHtn 2bndSmPXrkAqmWGWA1TmJjGuLHmdpIdkFXjxL9WZaKOch6iSkBZILLyy4ykJPcpopOVc +ITL9GFgLhTdP+kOKE+U6gjeAQLGCT/nveoD2aCMb3XKd3ZY59A+UGx+zjXR0Ex45RH1 q0paVZV8xjmxb9O5GmKTawkqs5Lp6jl8vqfOplR6eP6r6uWtlnngY66w6P6FwpSfNPJH sLrvQlO8BLmwHO6ZEdZK5cRZm2OSRR+hOqC1hkEoIDJCZp7JbvV8jEiIV4IxhcnHNHUj /EWw== X-Gm-Message-State: AOUpUlGmI4Io2m1ULJRLbXPLrB+jk4EWEbb3HYX3Orpqy+Zq+8udmGDN aPh1uMlnPe+Qs2jLj4HXkniQWuF1 X-Google-Smtp-Source: AAOMgpdrgyYEp4+krCigcHCbce0/kf9f9kjVChpfACbX/Ftmzxe8jO4MIC+eSdyowiHYvzbE+ev50g== X-Received: by 2002:a62:fb05:: with SMTP id x5-v6mr7595307pfm.210.1532712112937; Fri, 27 Jul 2018 10:21:52 -0700 (PDT) Received: from [192.168.1.120] (mtb-219-198.tm.net.my. [210.187.219.198]) by smtp.gmail.com with ESMTPSA id r87-v6sm9583439pfb.1.2018.07.27.10.21.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 10:21:51 -0700 (PDT) Sender: Martin Wilke From: Martin Wilke Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: =?utf-8?Q?_make_distribution_fails=2C=C2=A0A_failure_has_been_det?= =?utf-8?Q?ected_in_another_branch_of_the_parallel_make?= Message-Id: Date: Sat, 28 Jul 2018 01:21:48 +0800 To: freebsd-current@FreeBSD.org X-Mailer: Apple Mail (2.3445.8.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:21:55 -0000 Hi, I just upgraded a jail in poudriere with latest head, = https://dpaste.de/bfTT/raw . - Martin= From owner-freebsd-current@freebsd.org Fri Jul 27 17:31:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABF21105184B for ; Fri, 27 Jul 2018 17:31:10 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 338307EA30 for ; Fri, 27 Jul 2018 17:31:10 +0000 (UTC) (envelope-from ml@vishwin.info) Received: by mailman.ysv.freebsd.org (Postfix) id E8BD8105184A; Fri, 27 Jul 2018 17:31:09 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6CAA1051849 for ; Fri, 27 Jul 2018 17:31:09 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (varun.vishwin.info [46.101.93.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "varun.vishwin.info", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 374C07EA2C for ; Fri, 27 Jul 2018 17:31:09 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (fd35:9eae:7575::2 [IPv6:fd35:9eae:7575::2]) by varun.vishwin.info (OpenSMTPD) with ESMTP id 3cbca7a0 for ; Fri, 27 Jul 2018 13:30:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=vishwin.info; h=subject :references:to:from:message-id:date:mime-version:in-reply-to :content-type; s=fuccboi12; bh=N6FFEFqiJKs2VEoliArS6cxrZWwzCNl2H KQhThKwMCE=; b=lEaMVuS0IIb6sCaybijciIgBFG4h81l1bEZZR91gVsFQ57YfK HCDkEAK+PG51amBzLB/X/zlpW27mUe1OyhfBGROdmTqzqF3mYfXZyRCy8TgSNv6R d5UEjINbT9InMCqHSvUZYBOaTYnREqXHpy4aiSH2YImsXBYpugB+Tk5U2fqp/oJl Gl8zkzSrRS/HyDi/IKJkF70EoDxasHGnZ4b7feyNXxpq29l0awmdP6w+Et7ZN3XU xhxpDzWW4YKvCR2JutqebaHHFi5PPMMYaB9TJRHdW1/BfJcwTNB1KK0WmbLSGJls mFQT2tji2U1yKvS7kcAmq0h+rnvkGmE9xLJ1g== Received: from [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d] (2001:470:8:6ca:cad7:19ff:fec0:a06d [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d]) by varun.vishwin.info (OpenSMTPD) with ESMTPSA id ea588274 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 27 Jul 2018 13:30:58 -0400 (EDT) Subject: =?UTF-8?Q?Re=3a_make_distribution_fails=2c=c2=a0A_failure_has_been_?= =?UTF-8?Q?detected_in_another_branch_of_the_parallel_make?= References: To: current@freebsd.org From: Charlie Li Openpgp: preference=signencrypt Autocrypt: addr=ml@vishwin.info; keydata= xsFNBFe4p7sBEADHSqa7WkWYRhRiAYsECn4Ek29AkNS7SF4YAbZTzg+3xkPL5cM5zbNCR4U4 o99wC0Y5wQn9y9X9wM16k1AxBkeQ7Dgh+AjxYGnwDjyrVdx9fcId8dQvLV/xw4V2b5CtU0Et M9IE3MDOkgLtWJamTWIL/MfrNgWk5nRZDBhDcygkTO87t0Pi4WC/QQ3TrrDya6FbBPI7I5Y2 0arX2LAeXqJ6pF7uPfjqogKy3UL+t++9nTG6FNR2oftlts1AB+kGHXJf1GiewXLpPEJTGlXx P+XGhjALqJkFw6azELYKjZcd9zGEOWiKJKp2c2RUDdEJHy+cm6cJ8g7dabVA4ZXs5O7NzeMr on7xFbBx/l/0qHux+d7gS4Z+GJ9WGvzvuj4L8MLgA0eaNzn564RJ5FCtPpaulMhcSc78LhZs NCN3rq8VxsxNrIFTlvnLdLsTNITZOKXnyalE9WlM3cK6UlQaagShhO3FliI2hIOW7j4QWJZC Thynnnj5wIAOgKv1WKFwnKJsMfsohIME6uqmt5AcH5okXGZCcBJx30+enqsoEYOvg0pi5oY7 6F/bQdvHzY2prjeujo0oJhVSeRpv5tjEUBDjX525SPNqvr4uddHiavrFBkesOh7nnOjsEMZ1 i5Q6iZrQpteoafFZTld7tfLw8gMwyiSleKN+x7tJG1H3d1Bd7QARAQABzSFDaGFybGllIExp IDx2aXNod2luQHZpc2h3aW4uaW5mbz7CwYAEEwEIACoCGwMFCQPCZwAFCwkIBwIGFQgJCgsC BBYCAwECHgECF4AFAlfq/VYCGQEACgkQtQ4IJhNZSS0i+g//fRJwTJHY/sjK0T0Mh0PzwSnm OSYEcscxTuMR9BQaXPMFjEPpArtms0Wd9S29BgzLB+F7To9MCFGiDB6yvF5fba4Zz+oJ9hB8 lJ3lvY1Hr/hxdxK6Etzl/oXM8LN08Hi9XrHDWm1yuLLJvpaynoOGotZYDLoh0hPomPp3j1w/ BcVK6cRCUArAhXwH0HWTKYlZcRsL/paTXvVgi0TKqF29u2ADhjukQh7qAwcZebC+FfxV9On4 1gCkco144JJX77Ak7g/IWeJy7MJCzbwH41PNyn/X5lwv5N+4cKcGlSOi1ndJuySY2G2Pr1Wu rRyUQ/BF70/laaQOsd5Eg4QimzhOJ3G7QqtYOCZdFBvRs4i3ht0tyKgh4NIr9Zl6FaX/AsDJ d1PBdaWdUaY3NHEDFHtntL9xWxdc+UM21fMqAh+TK4zY+FhaudZO1MdBjrMd8ukjpveaoWZJ NgFageX28AWqxFpOhcPDchkUnydqmEEnl87zuZ8OS+HilDH4JzVGAnYrCG4+/h0b9V4QGevS Jp5lnmSXv2/YFkTDHSXmyBTXrVCjfZM3zH9I+3unYxwio0iAhj8sE4gD2Mx53fmBzoS/3ckf dbG0rZ2lecEFiWez4wn7YTHWLl2ujmeBbhjoyY5JPjvOCkn2Gbcy7tJZqTW7ajkWzZQcexyW 7lLoCkCXz9zOwU0EV7inuwEQAOaRmAfkM3cDXbGYr+8QZ08T037xFyTx3pPtfg74BaL1DF5o 4nr7XG410rHT3biOUxH3Gk7NILQibA746zm/TKjj8m/S4xc+aGA8l/Wx34C/6UO+zUNg0Cpz Vynmwtvj6oh/guoPuO2mELf0tQTXEP8vo4nRVcuYlDm0VKHS5OFadlZuYc8vlCx3jOC0vXyC DUKSZu5HdcP3a75OUrHFa7fS6A6n4J8/OKyiXXO9+tUielafHv0zF4Enl7pJgRXLPoJm5FZk RQWNdltVXtfPeOvhM8Plwk5XXjkNShGhsCzTF56f2DUlHCXJQAVDHAbYuscifUY+2HrA41SY SMM1nS5YpQXRWOMuxeh1xwia1GNvgaJdaucCKZ4Fff1F6YuTPKGCOEOifRPoLfO6Te93o2Fs NvNWutiCO0jJj1rlLLdV44chMbiOIsdMtsMpj5/T/Jrm7aD2NvWXJy5+aDyqjmE529oVBYha ouX9XEeWzUL5MxdqgT2LlmBv/y6XbXhXTOUHBBQyCBbqDqiQOWPtOkusiCajTyY0lsM3gR24 +igkJEMND+kJmMdn7G8pSKy7LgRlW4haGmz+80xfMf593APbzlnGB8gD0aH7/ejYCMkGaYz+ ZwFopkl0I4QQxSc3tvVljDhWNyGZxz2Dw4DNALHiG6xmESX00itf2zMPABMrABEBAAHCwWUE GAEIAA8FAle4p7sCGwwFCQPCZwAACgkQtQ4IJhNZSS3BIxAAsXD7PgkrQWu1DunaiPlL0MbR gv2evjY+2cLdpMt8Je3+e25r8JTbPKIV1QY3q0ju0yXgWLW0dM1hWSVpsQURLNyFYnivXt4q rLuDv4T/xTUo/xuV0rUOXp+oTDVKQ7KhpvKtaZFkP0a1z0pVFJbk7AI5UkQ4+lcuyTqzawxd vxn41s/FNKIxXTtj0PAgthzE0ZivAIj4USRaULC20ZvOYFW6rc10UPmrkLsrfXepakGBc0KJ EajF8LiOUqPE4c4BH2CoeEFu+e5OJAAl4kjj/CuNvtlko1Qjd31HPpMaha4l/WAd4kKPmMeW WuRxFkOwkkJFKW2ycH837Njl8Jn6dFSpgZ5/DPBvRdBXjAgDhySr2h9Zn5b6svtnh1ByKJKv ovzp+64IRqfotlLK3J9X1eKHlq10SyprH6IlxsGyXi987ZeV6/04UUAdmPXio/Enxbtna7D2 Cvo+aXTGM9Yu/YwxfmkWRJvEUUzqCOq63Z0Aa5ckOi+8FLUj3ZryS3ctmph/x/flN+ab4R22 pDL8LW1kwMH4Y4krv7l4GBgJPzkBGmonMclGf19i9zwC3TV8oSQ26cyi5d6QmuE3KN9NuLrD CJo3QQ3fpqQrnJbtd0M6fjuKWN0o7UTVEkcOXWWRF85d33VXG8XTDXEJmAJsELG7txDPNZ9o FqGGsWKHymE= Message-ID: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> Date: Fri, 27 Jul 2018 13:30:42 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8vL1KesFGcRqrBfE3fGZQdw27ga7e3nsq" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:31:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8vL1KesFGcRqrBfE3fGZQdw27ga7e3nsq Content-Type: multipart/mixed; boundary="74Jmx2NlG86gVmjx6sn8q2x4pByOoK6RZ"; protected-headers="v1" From: Charlie Li To: current@freebsd.org Message-ID: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> Subject: =?UTF-8?Q?Re=3a_make_distribution_fails=2c=c2=a0A_failure_has_been_?= =?UTF-8?Q?detected_in_another_branch_of_the_parallel_make?= References: In-Reply-To: --74Jmx2NlG86gVmjx6sn8q2x4pByOoK6RZ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB-large Content-Transfer-Encoding: quoted-printable On 27/07/2018 13:21, Martin Wilke wrote: > I just upgraded a jail in poudriere with latest head, https://dpaste.de= /bfTT/raw . >=20 I was about to inquire about this myself. Can additionally confirm this has been happening since at least r336735. --=20 Charlie Li Can't think of a witty .sigline today=E2=80=A6 (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) --74Jmx2NlG86gVmjx6sn8q2x4pByOoK6RZ-- --8vL1KesFGcRqrBfE3fGZQdw27ga7e3nsq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE/RdyC3Asy49czZEGtQ4IJhNZSS0FAltbVtEACgkQtQ4IJhNZ SS2yiA//Y3holYKvJijg1Gy138mmxeZVRkoRJBkkD0bpJVoKgxLdmroz1lEiBwt3 0ddKRB0NVUnc2e4EaGLZxJbWEBugj2RmSxamqp6LRzHk7LLWrRq3LPG0Iozy3aDM ToBOTdPYKwipG49wtT1c6/x3H258hvMn7oZ8AQG9cm1AvKcPhRDAbm/8jp7LAexv u/P9ESr4Xn6V5ZzeLORiAetc9WplNByDUBTnBQiWXLvOp0R74IfX3XdNMm+XvC5G 2ujiBKNpHnZSB73+xA76eWqCq0hAv2KAZf5dRJOBNpEu/YpEu6YfnGRWgEmyYobK y1Lua62ecTaC3XBIri4o7zU2eVGcnu6V2AOgks7wAcE/NJikDBK360Eu2vItfBgY v+qDApnjYYKNe/Yr/jDDHo6EMXaQSZlGMRfsKofR6+ehve5gw7MTzy8eWDIY5HPA 8zcbPxElMsxOMDg9H6n/OyrewYm9aERdSOOALWCODmvd+bHjbe0Jxi/0gvmfWbtk 8yrUckeN4YR37H0TV/ImkJz8ll02cx85eCqPmSfW6Qhsg2g/5fpiWSAW7yZ9Aax+ ypVRaXnCKwh1wYyEuzvCh1wNk8sRQb45789J0PqEtvIKqDhypTutsu3F6UYIvR1C 4tKWbQomlD+BCESlkCda1xB6so/wkLsC9Ofb2LG6AeMhNAvRTG8= =boCw -----END PGP SIGNATURE----- --8vL1KesFGcRqrBfE3fGZQdw27ga7e3nsq-- From owner-freebsd-current@freebsd.org Fri Jul 27 18:03:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 331051052290 for ; Fri, 27 Jul 2018 18:03:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 AC68A801A7 for ; Fri, 27 Jul 2018 18:03:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id k16-v6so4824168iom.12 for ; Fri, 27 Jul 2018 11:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=awpF8BMx8NXqBVOWKXPxwETXRqy6wdfo2Sder7qGLrA=; b=S8kZoS17JkW6a9WvxvtViSAhp8BkvGWj1qOxynKNBwKSvjimGxGmgKufLPfp+v3x5s LPfwEgGCeRkS/iDp3r8eyolzEbTpe3DHawNkayZmUYCFwLGKhCe5K+NjZeMdNkQjf5T6 sWwPbmRvRx7PHNO+IGKHgG7yfqhnn7tRXhbjJB8QVol2xS/qvtqZ7bzgSLZ/A/ZFiKX/ cpbra9ROddzin9Cp7awozm9XDZqhONgVL2/jtVK4Itlb8K94GqZAaWuRlD16Wsj9iDae dk/8wKhYPgUxWHlHu+WdX/hlcI096iFM3raGY0Hq0pTVZ3Xjz5hi+jVdyTM76D3nCv1Y nunA== 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=awpF8BMx8NXqBVOWKXPxwETXRqy6wdfo2Sder7qGLrA=; b=SWw5iRmEgfLzQ8wRzKUiRfzSn/ZZ9rOL0juVeXUvTascC3e3pcZAw88V9GYDx/nHLt 84i6KOuYGwkMpDINze++XSXcA4p9Ows24OAsquaQL1tT78Oia/vzwqGLdglqEKlLaZYA nE17cBebDjG1L6JtY+EFmWi1wVv5ww2GCa9u0aj0sNUWqLge9ZplNqNyut52U7rYICzg DIEDBJJhBwTHRGKHiyhDk8oCLD9ngLh0CkDT2qiaGWz+HEtHwXOpP28r+ko/u5lkuKdl 0e4BIVc6Zll8WMpIJelWPWhYsNEChH8Vtd28MxH5Jl1DCFecFV0t/WrJ8ywy/SNwn7XR W+7g== X-Gm-Message-State: AOUpUlHyXHtIaVl9bB2ljzCWCuILmEr6uC8E9jFOMd1GFboo00mmVJfM Uy99D/3Uv6cz8Vu80K0sldKhdNnD/VmpB/g4v21Bydn0SPo= X-Google-Smtp-Source: AAOMgpd6o8dssGiREnTvH9d8aPAphbRdzDB8CLGpZ1TGDcfhjl7dZ9Oa/0qOBX0EGk/Ak2R+GAwUU2dHafEfNzukiX0= X-Received: by 2002:a6b:f719:: with SMTP id k25-v6mr6168353iog.37.1532714636787; Fri, 27 Jul 2018 11:03:56 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:4485:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 11:03:55 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180727190555.55439fb3@thor.intern.walstatt.dynvpn.de> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> <20180727120232.270e1d9f@freyja.zeit4.iv.bundesimmobilien.de> <2A5E5E42-8595-44E9-A51E-504C9C2C7FA7@me.com> <20180727190555.55439fb3@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Fri, 27 Jul 2018 12:03:55 -0600 X-Google-Sender-Auth: KNS7n1PpYnCkZylvRTvLNI33cuw Message-ID: Subject: Re: [UEFI] Boot issues on some UEFI implementations To: "O. Hartmann" Cc: Toomas Soome , "Rodney W. Grimes" , freebsd-current , Allan Jude Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 18:03:58 -0000 On Fri, Jul 27, 2018 at 11:05 AM, O. Hartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Fri, 27 Jul 2018 13:59:44 +0300 > Toomas Soome schrieb: > > > > On 27 Jul 2018, at 13:02, O. Hartmann wrote: > > > > > > On Fri, 27 Jul 2018 08:54:48 +0300 > > > Toomas Soome wrote: > > > > > >>> On 27 Jul 2018, at 08:46, O. Hartmann > wrote: > > >>> > > >>> On Thu, 26 Jul 2018 19:23:43 +0300 > > >>> Toomas Soome wrote: > > >>> > > >>> (reply inline/at the end) > > >>> > > >>> > > >>>>> On 26 Jul 2018, at 16:58, O. Hartmann > wrote: > > >>>>> > > >>>>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT) > > >>>>> "Rodney W. Grimes" > >>>>> > wrote: > > >>>>>>>> On 25 Jul 2018, at 12:10, O. Hartmann > wrote: > > >>>>>>>> > > >>>>>>>> On Wed, 25 Jul 2018 11:46:07 +0300 > > >>>>>>>> Toomas Soome wrote: > > >>>>>>>> > > >>>>>>>>>> On 25 Jul 2018, at 10:59, O. Hartmann > wrote: > > >>>>>>>>>> > > >>>>>>>>>> On Tue, 24 Jul 2018 08:53:36 +0300 > > >>>>>>>>>> Toomas Soome wrote: > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Hello Toomas Soome, > > >>>>>>>>>> > > >>>>>>>>>> I CC Allan Jude since I discovered something weird today > regarding > > >>>>>>>>>> the UEFI boot capabilities of USB flash devices and SSDs. Se= e > below. > > >>>>>>>>>> > > >>>>>>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann < > ohartmann@walstatt.org> > > >>>>>>>>>>>> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300 > > >>>>>>>>>>>> Toomas Soome wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann < > ohartmann@walstatt.org> > > >>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300 > > >>>>>>>>>>>>>> Toomas Soome > > wrote: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann < > o.hartmann@walstatt.org > > >>>>>>>>>>>>>>>> > wrote: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > > >>>>>>>>>>>>>>>> Hash: SHA512 > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300 > > >>>>>>>>>>>>>>>> Toomas Soome > > >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> schrieb: > > >>>>>>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann > > >>>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot > problems > > >>>>>>>>>>>>>>>>>> on GPT drives where the first partition begins at > block 40 > > >>>>>>>>>>>>>>>>>> of the hdd/ssd. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> I have two host in private use based on an > > >>>>>>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard > (IvyBridge, > > >>>>>>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the > lates > > >>>>>>>>>>>>>>>>>> official available AMI firmware revision, dating to > 2013. > > >>>>>>>>>>>>>>>>>> This is for the Z77-Pro4-M revision 2.0 (2013/7/23) > and for > > >>>>>>>>>>>>>>>>>> the Z77 Pro4 revision 1.8 (2013/7/17). For both > boards a > > >>>>>>>>>>>>>>>>>> BETA revision for the Spectre/Meltdown mitigation is > > >>>>>>>>>>>>>>>>>> available, but I didn't test that. But please read. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> The third box I realised this problem is a brand new > Fujitsu > > >>>>>>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R > 1.26.0 for > > >>>>>>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525). > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via > > >>>>>>>>>>>>>>>>>> bsdinstall the OS using UEFI-only boot method on a G= PT > > >>>>>>>>>>>>>>>>>> partitioned device fails. The ASRock boards jump > immediately > > >>>>>>>>>>>>>>>>>> into the firmware, the Fujitsu offers some kind of > > >>>>>>>>>>>>>>>>>> CPU/Memory/HDD test facility. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> If on both type of vendor/boards CSM is disabled and > UEFI > > >>>>>>>>>>>>>>>>>> boot only is implied, the MBR partitioned FreeBSD > > >>>>>>>>>>>>>>>>>> installation USB flash device does boot in UEFI! I > guess I > > >>>>>>>>>>>>>>>>>> can assume this when the well known clumsy 80x25 cha= r > > >>>>>>>>>>>>>>>>>> console suddenly gets bright and shiny with a much > higher > > >>>>>>>>>>>>>>>>>> resoltion as long the GPU supports EFI GOP. Looking > with > > >>>>>>>>>>>>>>>>>> gpart at the USB flash drives reveals that the EFI > partition > > >>>>>>>>>>>>>>>>>> starts at block 1 of the device and the device has a > MBR > > >>>>>>>>>>>>>>>>>> layout. I haven't found a way to force the GPT > scheme, when > > >>>>>>>>>>>>>>>>>> initialised via gpart, to let the partitions start a= t > block > > >>>>>>>>>>>>>>>>>> 1. This might be a naiv thinking, so please be > patient with > > >>>>>>>>>>>>>>>>>> me. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> I do not know whether this is a well-known issue. On > the > > >>>>>>>>>>>>>>>>>> ASRock boards, I tried years ago some LinuxRed Hat > and Suse > > >>>>>>>>>>>>>>>>>> with UEFI and that worked - FreeBSD not. I gave up o= n > that > > >>>>>>>>>>>>>>>>>> that time. Now, having the very same issues with a n= ew > > >>>>>>>>>>>>>>>>>> Fujitsu system, leaves me with the impression that > FreeBSD's > > >>>>>>>>>>>>>>>>>> UEFI implementation might have problems I'm not awar= e > of. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Can someone shed some light onto this? > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> The first thing to check is if the secure boot is > disabled. We > > >>>>>>>>>>>>>>>>> do not support secure boot at all at this time. > > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Secure boot is in every scenario disabled! > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> If you have efi or bios version running - you can > check from > > >>>>>>>>>>>>>>>>> either console variable value (it can have efi or > vidconsole > > >>>>>>>>>>>>>>>>> or comconsole) or better yet, see if efi-version is > set (show > > >>>>>>>>>>>>>>>>> efi-version) - if efi-version is not set, it is BIOS > loader > > >>>>>>>>>>>>>>>>> running. Another indirect way is to see lsdev -v, wit= h > device > > >>>>>>>>>>>>>>>>> paths present, it is uefi:) > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> What are you talking about? > > >>>>>>>>>>>>>>>> What is the point of entry - running system, loader? > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> sysct machdep.bootmethod: BIOS > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> This makes me quite sure that the system has booted vi= a > BIOS - > > >>>>>>>>>>>>>>>> as I'm sure since I've checked that many times. UEFI > doesn't > > >>>>>>>>>>>>>>>> work on those systems with FreeBSD. I'm not sure > antmore, but > > >>>>>>>>>>>>>>>> I tried also Windows 7 on those mainboards booting via > UEFI - > > >>>>>>>>>>>>>>>> and I might recall that they failed also. I also recal= l > that > > >>>>>>>>>>>>>>>> there were issues with earlier UEFI versions regarding > booting > > >>>>>>>>>>>>>>>> only Windows 8/8.1 - and nothing else, but the fact > that Linux > > >>>>>>>>>>>>>>>> worked confuses me a bit. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> If this ASRock crap (never ever again this brand!) > doesn't work > > >>>>>>>>>>>>>>>> at all - who cares, I intend to purchase new server > grade > > >>>>>>>>>>>>>>>> hardware. But the more puzzling issue is with the > Fujitsu, > > >>>>>>>>>>>>>>>> which I consider serious and from the behaviour the > Fujitsu > > >>>>>>>>>>>>>>>> failure looks exactly like the ASRock - Windows 7 work= s, > > >>>>>>>>>>>>>>>> RedHat 7.5 works (I assume I can trust the Firmware > settings > > >>>>>>>>>>>>>>>> when I disable CSM support, that the Firmware will onl= y > > >>>>>>>>>>>>>>>> EFI/UEFI capable loader? Or is there a ghosty override > > >>>>>>>>>>>>>>>> somwhere to be expected?). Also on ASRock disabling CS= M > should > > >>>>>>>>>>>>>>>> ensure not booting a dual-bootstrap-capable system. > This said, > > >>>>>>>>>>>>>>>> on the recent Fujitsu, it seems to boil down to a > FreeBSD > > >>>>>>>>>>>>>>>> UEFI-firmware interaction problem, while the ASRock is > still > > >>>>>>>>>>>>>>>> under suspicion to be broken by design. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> GPT partitions can never start from disk absolute > sector 1; > > >>>>>>>>>>>>>>>>> this is because at sector 0 there is MBR (for > compatibility), > > >>>>>>>>>>>>>>>>> sector 1 is GPT table and then sectors 2-33 have GPT > > >>>>>>>>>>>>>>>>> partition table entries, so the first possible data > sector is > > >>>>>>>>>>>>>>>>> 34 (absolute 34). Thats assuming 512B sectors. For > details > > >>>>>>>>>>>>>>>>> see UEFI 2.7 Chapter 5.3.1 page 131. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Thanks for the explanation. That implies the installer > did > > >>>>>>>>>>>>>>>> right, gpart did also right and therefore there must b= e > an > > >>>>>>>>>>>>>>>> issue with the stuff located within the EFI > > >>>>>>>>>>>>>>>> partition? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if > we reach > > >>>>>>>>>>>>>>> BIOS loader at all or not - that is, if the BIOS > bootstrap is > > >>>>>>>>>>>>>>> actually caring to read the MBR code and start it, sinc= e > once > > >>>>>>>>>>>>>>> the MBR code is started, it is all about our code. > > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" > the CSM? > > >>>>>>>>>>>>>> or do you mean that specific portion of the UEFI > firmware, which > > >>>>>>>>>>>>>> looks for the proper UEFI partition? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> BIOS as either native or CSM. Note that from boot code > point of > > >>>>>>>>>>>>> view the CSM boot *is* BIOS boot, we have no access to UE= FI > > >>>>>>>>>>>>> features. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> The boxes in question, most notably the more recent > Fujitsu > > >>>>>>>>>>>>>> Esprimo Q956, refuse booting UEFI, even if properly setu= p > (in > > >>>>>>>>>>>>>> terms of what FreeBSD provides on recent CURRENT) is > applied and > > >>>>>>>>>>>>>> CSM is switched off in the firmware. Again: GPT partitio= n > scheme. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> The system boots properly if a second partition of type > > >>>>>>>>>>>>>> "freebsd-boot" is applied and bootcode is properly > applied via > > >>>>>>>>>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0= " > (ada0 > > >>>>>>>>>>>>>> is the device). > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> btw, you can try to validate the installed boot blocks > by using > > >>>>>>>>>>>>>>> recent enough loader (usb or iso) and then you can use > from OK > > >>>>>>>>>>>>>>> prompt: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> lsdev provides me with the follwoing informations (CSM > enabled): > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> OK lsdev > > >>>>>>>>>>>>>> disk devices: > > >>>>>>>>>>>>>> disk0: BIOS DRIVE C ... > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> disk0p1: EFI > > >>>>>>>>>>>>>> disk0p2: FreeBSD BOOT > > >>>>>>>>>>>>>> disk0p3: FreeBSD SWAP > > >>>>>>>>>>>>>> disk0p4: FreeBSD ZFS > > >>>>>>>>>>>>>> zfs devices: > > >>>>>>>>>>>>>> zfs:zroot > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> OK chain disk0 > > >>>>>>>>>>>>>> open failed (so for disk0p{1-4}. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> OK chain zroot > > >>>>>>>>>>>>>> failed to read disk (just for completeness) > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> chain command does use only device name (such as disk0: o= r > > >>>>>>>>>>>>> disk0p2: ), but not zfs pool as device. I just found I > haven?t > > >>>>>>>>>>>>> ported the code to read the file. > > >>>>>>>>>>>> > > >>>>>>>>>>>> ?? > > >>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> the point for chain command test is to see if the normal > read and > > >>>>>>>>>>>>> execute would work, so in your case please try: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> chain disk0: > > >>>>>>>>>>>> > > >>>>>>>>>>>> As stated above, I did so, and the result is also mentione= d > above, > > >>>>>>>>>>>> I always get "open failed". > > >>>>>>>>>>>> This is the same for > > >>>>>>>>>>>> > > >>>>>>>>>>>> chain disk0 > > >>>>>>>>>>>> chain disk0p1 > > >>>>>>>>>>>> chain disk0p2 > > >>>>>>>>>>>> chain disk0p3 > > >>>>>>>>>>>> chain disk0p4 > > >>>>>>>>>>>> > > >>>>>>>>>>>> as already said. CSM is enabled in this case. > > >>>>>>>>>>> > > >>>>>>>>>>> sigh? chain command does take device as argument, device > must always > > >>>>>>>>>>> end with colon?. in this case, the devil is in details:) as > I wrote > > >>>>>>>>>>> above, the command should be: > > >>>>>>>>>>> > > >>>>>>>>>>> chain disk0: > > >>>>>>>>>>> > > >>>>>>>>>>> The disk0p1: etc will only work when partition boot code wa= s > > >>>>>>>>>>> installed (which you most likely do not have - the only > possible > > >>>>>>>>>>> candidate could be FreeBSD ZFS partition). > > >>>>>>>>>> > > >>>>>>>>>> The command "chain disk0:" works as expected (CSM enabled, G= PT > > >>>>>>>>>> partition scheme, but with PMBR bootblock installed and > freebsd-boot > > >>>>>>>>>> partition conatining gptzfsboot installed. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> to read pmbr (512B) and execute it. The expected outcome > would be > > >>>>>>>>>>>>> that pmbr boot code would browse the GPT, read stage1 fro= m > > >>>>>>>>>>>>> disk0p2: and execute it; stage1 would detect FreeBSD ZFS > from > > >>>>>>>>>>>>> disk0p4: and load and execute /boot/loader. If that will > happen, > > >>>>>>>>>>>>> it means the boot code in our stages is just fine, but th= e > bios > > >>>>>>>>>>>>> (CSM) does not load pmbr?. if thats true, it would mean > that you > > >>>>>>>>>>>>> either need to use UEFI boot or need to have some hack to > fool > > >>>>>>>>>>>>> the BIOS or just not use GPT on that machine with CSM. > > > >>>>>>>>>>>> > > >>>>>>>>>>>> To make it clear here: The only way to boot this box is > using CSM > > >>>>>>>>>>>> (as it is the same with the ASRock boards mentioned > earlier). But > > >>>>>>>>>>>> my intention is to disable CSM and use a GPT/UEFI > environment > > >>>>>>>>>>>> only! And GPT/UEFI doesn't work with FreeBSD, neither with > > >>>>>>>>>>>> 12-CURRENT, nor 11.2-RELENG. > > >>>>>>>>>>>> > > >>>>>>>>>>>> It would be nice if this could be fixed. I'm more > interested in the > > >>>>>>>>>>>> fix on the recent Fujitsu device than the outdated ASRock > crap, but > > >>>>>>>>>>>> if the fix for the Fujitsu Firmware could fix older issues > as a > > >>>>>>>>>>>> byproduct, I'd appreciate that. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Kind regards, > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> ok, somehow I have lost that part of the discussion. Well, > you wrote > > >>>>>>>>>>> that the UEFI boot fails when the first partition starts > from sector > > >>>>>>>>>>> 40 - does it mean you have boot when the partition will > start from > > >>>>>>>>>>> some other sector? I think, there is something else going > > >>>>>>>>>>> on. > > >>>>>>>>>> > > >>>>>>>>>> Well, I simply try to describe what I "see" to make things > > >>>>>>>>>> disambiguous. I'm not familiar with the deeper insights of > disk > > >>>>>>>>>> layouts on a binary level. So, you explained to me the > reason, why > > >>>>>>>>>> ESP (EGI partition) starts at block 40. I compared that to t= he > > >>>>>>>>>> FreeBSD USB flash image FreeBSD provides, but this is anothe= r > story > > >>>>>>>>>> since the image uses MBR scheme as I figured out. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> What you can do is to see if that firmware will offer you > EFI shell > > >>>>>>>>>>> option, from there you can try to start the bootx64.efi > manually and > > >>>>>>>>>>> see what error you will get. However, the number 1 cause fo= r > failing > > >>>>>>>>>>> to start the bootloader in UEFI is secure boot - we do not > support > > >>>>>>>>>>> it and secure boot must be switched off. > > >>>>>>>>>>> > > >>>>>>>>>>> However, they seem to claim "The Secure Boot option is > available in > > >>>>>>>>>>> the UEFI/BIOS of most if not all ASRock boards. It is > disabled by > > >>>>>>>>>>> default.? > > >>>>>>>>>>> > > >>>>>>>>>>> Still suggest to double check if thats really the case. > Also, if the > > >>>>>>>>>>> bootx64.efi start will fail and no messages are appearing o= n > screen, > > >>>>>>>>>>> then either there is something in firmware logs or you coul= d > get > > >>>>>>>>>>> them from trying to start bootx64.efi from UEFI shell. > > > >>>>>>>>>> > > >>>>>>>>>> Since I'm with this problem since 2014 and try from time to > time, be > > >>>>>>>>>> ausred that I tried every possible permutationof all > reasonable > > >>>>>>>>>> options, even those nonsense, to get rid of that problem. > > >>>>>>>>>> > > >>>>>>>>>> I never had any problems with any other UEFI capable > > >>>>>>>>>> server/workstation firmware so far booting FreeBSD off in > > >>>>>>>>>> UEFI-native (GPT partition scheme, CSM disabled) so far - > until now, > > >>>>>>>>>> when I ran into this Fujitsu ESPRIMO Q956 with the most rece= nt > > >>>>>>>>>> firmware (as of lat week, week 29 of 2018) having the very > same > > >>>>>>>>>> problems. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> I figured out something strange on the Fujitsu - and that is > the same > > >>>>>>>>>> with the ASRock boards. > > >>>>>>>>>> > > >>>>>>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a > very small > > >>>>>>>>>> appliance, but nevertheless, the USB flash device is booted = on > > >>>>>>>>>> Fujitsu servers with UEFI-only configurations. I assume at > this > > >>>>>>>>>> point that disabling on the most recent Fujitsu firmwares on > > >>>>>>>>>> reasonable "new" hardware (not older than three years) will > disable > > >>>>>>>>>> any(!) legacy BIOS capabilities. The same is assumed for the > Fujitus > > >>>>>>>>>> ESPRIMO Q956. I can not speak for the ASRock A77 Pro4/m boar= ds > > >>>>>>>>>> mentioned above/earlier, they are from 2012/2013 and "quite > old". > > >>>>>>>>>> > > >>>>>>>>>> The NanoBSD image of ours doesn't have a "freebsd-boot" > partition. > > >>>>>>>>>> The partition scheme of the flash device is GPT. The layout > looks > > >>>>>>>>>> like this: > > >>>>>>>>>> > > >>>>>>>>>> gpart show -l da4 > > >>>>>>>>>> =3D> 40 15425456 da4 GPT (7.4G) > > >>>>>>>>>> 40 2000 1 efiboot0 (1.0M) > > >>>>>>>>>> 2040 1453584 3 disk1a (710M) > > >>>>>>>>>> 1455624 4096 5 disk3 (2.0M) > > >>>>>>>>>> 1459720 13965776 - free - (6.7G) > > >>>>>>>>>> > > >>>>>>>>>> I created the flash with md, gpart and dd straightforward, > efiboot0 > > >>>>>>>>>> is the ESP partition and its format/content is created via d= d > > >>>>>>>>>> if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is = very > simple. > > >>>>>>>>>> > > >>>>>>>>>> This USB flash device boots(!) successfully (UEFI!) on both > the > > >>>>>>>>>> ASRock boards and the Esprimo Q956! > > >>>>>>>>>> > > >>>>>>>>>> But any SSD prepared the same way doesn't. Why? > > >>>>>>>>>> > > >>>>>>>>>> On the ASRock, I recall having fiddled around with HDD also > for a > > >>>>>>>>>> while conatining Windows 7/SP1 and FreeBSD. Windows7 booted, > FreeBSD > > >>>>>>>>>> - I can't remember. > > >>>>>>>>>> > > >>>>>>>>>> In the lack of proper hardware I'm unable to check whether > > >>>>>>>>>> USB-attached HDD or SSD will boot or HDD will boot (just in > case the > > >>>>>>>>>> local SATA has problems booting UEFI and USB not). > > >>>>>>>>>> > > >>>>>>>>>> Kind regards, > > >>>>>>>>>> > > >>>>>>>>>> Oliver > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Am. well. I think the suggestion to test out FAT32 is still > good one > > >>>>>>>>> to test. This is because it is known that some vendors do not > support > > >>>>>>>>> booting FAT12/FAT16 from HDD (the likely reason is that UEFI > > >>>>>>>>> specification does not tell which FAT must be supported, and > only hint > > >>>>>>>>> about FAT12/FAT16 in context of removable devices). > > >>>>>>>> > > >>>>>>>> I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO > Q956. It > > >>>>>>>> took me a time to circumvent the installer and I had to instal= l > the > > >>>>>>>> system manually. In that strain, I also "tried" to establish > the ESP > > >>>>>>>> with FAT32, as Allen Jude suggested earlier. I didn't find any > ad hoc > > >>>>>>>> help how to find out the format (FAT12/16/32) of the ESP, so I > assume > > >>>>>>>> when using 12-CURRENT's or 11.2-RELENG's installer with > AUTO-ZFS and > > >>>>>>>> GPT (UEFI) (only!) the resulting ESP is FAT12 or FAT16 (300mb = by > > >>>>>>>> default). I also assume, that when dd'ing the /boo/boot1.efifa= t > image > > >>>>>>>> to a partition, the format is FAT, but not FAT32. Therefore, I > > >>>>>>>> refomatted the manually created ESP (using "gpart add -t efi > ...") > > >>>>>>>> using "newfs_msdos -F 32 -b xxx ...". I had to fiddle around a > bit > > >>>>>>>> with option -b to fit in a proper format to meet a 512mb ESP - > I'm not > > >>>>>>>> sure whether this is the proper option to deal with. When usin= g > the > > >>>>>>>> default and only -F32, the size of the partition has to be 4G > at least > > >>>>>>>> I assume. Having done that, I copied the the content of > boot1.efifat > > >>>>>>>> (mdconfig -t vnode ..., I guess we know the drill ...) to the > newly > > >>>>>>>> formatted ESP to /boot/efi/ ... > > >>>>>>>> > > >>>>>>>> Having so far no knowledge of how to asure that the created ES= P > is > > >>>>>>>> FAT32, I assume it is FAT32. > > >>>>>>>> > > >>>>>>>> The result is negative on the ESPRIMO Q956. When disabling the > CSM, the > > >>>>>>>> box is not willing to boot from SSD with the ESP prepared as > decribed. > > >>>>>>>> So, a chance that this might still be due to a misconfiguratio= n > lies > > >>>>>>>> now within the -b option of newfs_msdos - if the -b option is > assumed > > >>>>>>>> the proper option? > > >>>>>>>> > > >>>>>>>> At the moment, the ESP of the Esprimo is subject to changes, i= f > you > > >>>>>>>> wish, but not in size, since it is limited to 512mb. > > >>>>>>>> > > >>>>>>>> Thanks and kind regards, > > >>>>>>>> > > >>>>>>>> Oliver > > >>>>>>> > > >>>>>>> Yea, i was hoping fstyp command would report the FAT type, but > it does > > >>>>>>> not (request for feature?:) > > >>>>>> > > >>>>>> FYI, the file(1) command is very good at disecting a disk image > to tell > > >>>>>> you what the MBR looks like, and at looking at partitions if > pointed at > > >>>>>> them with the -s option. It should be able to detect FAT12/16/3= 2. > > >>>>>> > > >>>>>> root@x230a:/home/ISO/x # file -s /dev/md2s1 > > >>>>>> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID > "BSD4.4 ", > > >>>>>> root entries 512, sectors 1600 (volumes <=3D32 MB) , sectors/FAT= 5, > > >>>>>> sectors/track 63, heads 1, serial number 0xbd4111ee, label: > "EFISYS > > >>>>>> ", FAT (12 bit), followed by FAT > > >>>>>> > > >>>>>>> > > >>>>>>> However, the more annoying idea would be to install some OS > which will > > >>>>>>> boot with UEFI on this machine, then copy boot1.efi from freebs= d > to it > > >>>>>>> (the default program the UEFI will load is > ESP:EFI/boot/bootx64.efi in > > >>>>>>> case of UEFI64 and ESP:EFI/boot/bootia32.efi for EFI32. However= , > we do > > >>>>>>> not support EFI32. > > >>>>>>> > > >>>>>>> note that boot1.efi alone will not do much but printing on > screen how it > > >>>>>>> will search for freebsd, but for the purpose of the test it wou= ld > > >>>>>>> suffice > > >>>>>>> - that would give us confirmed working ESP file system (since > the other > > >>>>>>> os would be able to boot) and then we can confirm if boot1.efi > itself is > > >>>>>>> OK. > > >>>>>> > > >>>>> > > >>>>> Some new results. > > >>>>> I installed RedHat 7.5 and inestigated the ESP. > > >>>>> > > >>>>> - The ESP starts at block 2048, while FreeBSD's ESP starts at > block 40. > > >>>>> - size is both 200mb if installed automatically. I forgit to > investigate > > >>>>> the FAT format, but this might be unnecessary as shown further in > this > > >>>>> post. > > >>>>> - RedHat's ESP contains ~ 10 MB of data in two > > >>>>> folders, /efi/boot, /efi/redhat. copying FreeBSD's BOOTX64.efi ov= er > > >>>>> RedHat's doesn't change anything, also renaming > /efi/boot/fbx64.efi of > > >>>>> RedHat's installation. But renaming /efi/redhat renders RedHat to > fail the > > >>>>> boot process on the Fujitsu with the signs of the built-in > testprogram as > > >>>>> reported. > > >>>>> > > >>>>> I took the liberty and installed 11.2-RELENG again, ZFS only, UEF= I > boot > > >>>>> only (CSM in firmware disabled, but there is still a > gptzfsboot-prepared > > >>>>> partition for later use, just for the record). Booting UEFI-only > fails as > > >>>>> reported. On this installation I copied the RedHat ESP completely > into > > >>>>> FreeBSD's ESP, renamed /efi/boot/BOOTX64.efi to > /efi/boot/BOOTX64.efi.rh > > >>>>> and copied FreeBSD's BOOTX64.efi to /efi/boot. > > >>>>> The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, > that > > >>>>> the /efi/redhat folder of the ESP is important, if renamed, the > whole > > >>>>> process dies as I reported earlier. > > >>>>> > > >>>>> Still unanswered is the question: why is a NanoBSD prepared > UEFI-only USB > > >>>>> flash booting with CSM disabled (so asumingly UEFI only then) on > both > > >>>>> ASRock and Fujitsu (as described in more detail initially and > earlier), > > >>>>> while SSDs fail? Is there a difference? Since FreeBSD boots in > UEFI mode > > >>>>> from USB flash prepared as described (straight forward, 800k ESP > starting > > >>>>> at block 40, the boot1.efifat image dd'ed onto the partition, UFS > > >>>>> partition following, no freebsd-boot partition or MBR/PMBR bootco= de > > >>>>> applied ever!), I think BOOTX64.EFI is technically all right. > There must > > >>>>> be then an issue with the SATA/SSD/HDD boot pathway. > > >>>>> > > >>>>> Hope I could provide some more details, sorry if it sounds > confusing or > > >>>>> way too long, but I try to descibe the situation as thorough as > possible. > > >>>>> > > >>>> > > >>>> OK, this is already good hint. The thing with ESP is that there is > > >>>> =E2=80=9Cdefault=E2=80=9D file system tree: EFI/BOOT/BOOT= .EFI, this is > noted as > > >>>> default for *removable* media, fortunately it is usable for hard > disks as > > >>>> well, or at least in most cases. > > >>>> > > >>>> Now, for non-removable media, the UEFI does provide boot manager > interface > > >>>> to define boot entries, and the fact that renaming efi/redhad > directory did > > >>>> break the redhat boot, is very loud hint. And this means, this > system is > > >>>> probably ignoring efi/boot tree on non-removable media and is > expecting the > > >>>> boot manager entry to be created instead. > > >>> > > >>> This inplication I'd confirm for the recent Fujitsu ESPRIMO Q956 > firmware > > >>> (not tested on ASRock Z77-Pro4 firmware). > > >>> > > >>>> > > >>>> UEFI boot manager can be configured /usually/ manually via firmwar= e > menu, > > >>>> or by application, such as efibootmgr. The normal approach is to > create > > >>>> efi/ directory and to copy the application there, then > create > > >>>> the boot manager configuration. > > >>>> > > >>>> See UEFI specification v2.7, chapter 3 Boot Manager, page 79. > > >>>> > > >>>> What is different in FreeBSD case is that the whole interface to > program > > >>>> the UEFI Boot Manager is currently being developed, so either it > has to be > > >>>> done manually or from some other OS (see > > >>>> https://wiki.gentoo.org/wiki/Efibootmgr > > >>>> for example, first hit > from > > >>>> google:D). > > >>> > > >>> Well, thanks for this important hint! FreeBSD 12-CURRENT's and > FreeBSD > > >>> 11.2-RELENG's USB flash devices are capable of booting off on > Fujitsu's > > >>> ESPRIMO and ASRock's boards. As a note: after "kldload efirt.ko" I > was able > > >>> to use the already in FreeBSD present toolset efibootmgr(8) and > sibblings > > >>> (the tools do not do anything useful when booted non-UEFI). > > >>> > > >>> Mounting the ESP of the harddrive (in my case, ada0p1) to /mnt and > following > > >>> the steps in the examples and having created > /efi/freebsd/BOOTx64.efi as > > >>> recommended by copy from /efi/boot, let me create a proper boot > variable. > > >>> > > >>> To make things sure, I also applied "efibootmgr -a VARIABLENAME". > > >>> > > >>> And ... it worked! Yes, it worked! The ESP is FAT32 formatted, I do > not know > > >>> whether this will also work with FAT12/16, I should test this case, > too. > > >>> > > >>> There is a bug in the manpage of efibootmg(8). It does not explain > the > > >>> options -d and -p, although they could be "implied" by reading > carefully. > > >>> There is now a PR at > > >>> > > >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230080 > > >>> > > >>> for this issue. > > >>> > > >>> So, it's apity that the handbook has no note I could easily find on > this; > > >>> > > >>> Thank you very much for your patience and help! > > >>> > > >>> Kind regards, > > >>> Oliver > > >> > > >> yep, efibootmgr does call UEFI RuntimeServices to set up the > variables, and > > >> this is only possible when booted UEFI. But glad we finally found th= e > root > > >> cause. It would be good to have HW notes for such cases, it is > important to > > >> know that those systems wont boot UEFI from HDD unless the boot > manager setup > > >> is done. > > >> > > >> rgds, > > >> toomas > > > > > > > > > This pops up the question how to deal with such HW. We have as a > institution a > > > lot of Fujitsu hardware her - from larger servers down to Fujitsu > ESPRIMO Q956. > > > The latter one is the first (and so far the only) piece of hardware I > found > > > incapable of booting off UEFI within the past 5 years. > > > > > > If the "standard" for removeable devices is to boot from > /efi/boot/bootx64.efi, > > > than I'd guess it is good luck for FreeBSD that the firmware vendors > did > > > fallback to such a mechanism. GRUB/Linux seem to install by default > their > > > bootloader into /efi/something/ I'll check on Debian, Suse and CentOS > so far > > > soon, the latter probably will, since its the "free" RedHat). > > > > > > Anyway, apart from any criticism, I'm glad to have the tools to make > things > > > work without using alien help (outside FreeBSD's world!). That is a > thank you > > > towards the developers. > > > > > > Kind regards, > > > > > > oh > > > > > > > The efibootmgr is only relatively recent addition (in illumos we do not > have yet even > > access to UEFI RS), so it is only question of time once installer will > get updated:) > > > > But of course there is still an issue about the scenario when the > install is done in > > BIOS mode and later switched to UEFI - then the boot manager > configuration needs to be > > updated manually (or by some maintenance service like grub2 is calling > via grub-install > > script). > > > > rgds, > > toomas > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > Just to add another success on ASRock Z77-Pro4 (800k ESP, FAT12) and > ASRock Z77-Pro4M > (300mb ESP, FAT32). > > On this firmware, I did not have to define/copy the bootloader > within /efi/freebd/BOOTx64.efi. It was sufficient to add an EFI variable > as described in > the manpage efibootmgr(8). > > The only pitfall on this firmware (very old, last functional update 2013, > Spectre/Meltodown mitigation only May 2018) was that I wasn't able to > activate variable > "0000"! Creating > > efibootmgr -c -l /mnt/efi/boot/BOOTx64.efi -L FreeBSD-12 > > which results in "Boot0000" > > and followed by > > efibootmgr -a 0000 > > or > > efibootmgr -n 0000 > > resulted in "No such variable" or similar. > Yes. that's a bogus sanity check in the code. I've removed it and will commit in a moment. > I had to perform the very same task again to gain variable 0001 and then = I > was able to > "activate" variable 0000. This might be due to the fact the only variable > defined at all > was Boot0005 pointing to the most recent USB flash device with 12-CURRENT > from 2018-07-26 > I just prepared. > > Now, also those boxes boot via UEFI (one, 800k ESP with the /efi/boot > folder, the other, > 300mb ESP, with a copy /efi/freebsd as I had to do on the Fujitsu ESPRIMO > Q956 firmware). OK. Warner From owner-freebsd-current@freebsd.org Fri Jul 27 18:08:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0480C1052475 for ; Fri, 27 Jul 2018 18:08:33 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 87278803C9 for ; Fri, 27 Jul 2018 18:08:32 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 486A21052474; Fri, 27 Jul 2018 18:08:32 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 371921052473 for ; Fri, 27 Jul 2018 18:08:32 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 AB022803C7; Fri, 27 Jul 2018 18:08:31 +0000 (UTC) (envelope-from miwi.fbsd@gmail.com) Received: by mail-pf1-x42d.google.com with SMTP id e13-v6so1988409pff.7; Fri, 27 Jul 2018 11:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zyNYM+xaPRIVv/wkjVc3jKgQCcvbdfyimXMTH1T3wzw=; b=QrPgL21o6bHrGFACKyrj0fH92/deIKcKxdENc5wGvXSFfLmI1t7kFgF60pmyMhUBDP Sauve1zd27khEATSeQeKHyxUnov2ABisUaau69glZLCYX0qXI5y77+rCHQRNCPMbVCui GGd07g62Dy/QFeq+tcY1JFOzHbIvxj6R2dLFu22ZNtX80W0XAD2wCZBaHmYtnyUjETnc 6GDCMwCaYxqwlVU6yoYfFKOGQ8Ful336V4SAj4oERzfrZmjragEPnX6LrIa2ZDH0YrDF iphFW4kUAgDOUb7kbydQAMNzK1TWyLerPseeJniN49l4SJ09PqLfYDKb1/osjxIC/ANt PC9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=zyNYM+xaPRIVv/wkjVc3jKgQCcvbdfyimXMTH1T3wzw=; b=Bm579meMdfUiyR2UfgX+0xDl8c7ZgX/QRBf4qBp2ejJoOPFK4UPil+5kR9/zWJ7bNc zO4UcjiojzZ9LVY35aLIfNSAcaAjRN+g4yPqYpbaWKtlXrgcAosZMjprili3xOUsLh72 ec7XGKmnf/CR3vkLZhRrNfOO9auSZt7or4EeP5mG8Yt7UYyfN99Zd9BNrIen7YIxlzRW l1Y6sCADxAjxQL6RxHuKAQI6WJOfi4tV0rwiJM7uDBQ4fgeOEtGyngMRpuN50Z0h8yG4 cmi1lKoMHsqFazRGImOLOq7VZf8AWot33UaiOtHTvxcidEZaRoSuXbwHun4YyMeZ0sNG Tmpw== X-Gm-Message-State: AOUpUlFwIBxuV9WbK1SZTXqMwWosH+2rS4nBVUCiY4PeZDcVlJt+EQfO l+0/0tgOIHO9m3rb5fYgd4D4kLEG X-Google-Smtp-Source: AAOMgpclopBmQrzcoJtaY0MUhx5ST7zuK31Mr/Jk0hZIc+w+nxqkX87xN7TJULguXmN3VN7/7wpIOA== X-Received: by 2002:a62:f587:: with SMTP id b7-v6mr7698908pfm.158.1532714910723; Fri, 27 Jul 2018 11:08:30 -0700 (PDT) Received: from [192.168.1.120] (mtb-219-198.tm.net.my. [210.187.219.198]) by smtp.gmail.com with ESMTPSA id c1-v6sm6420575pfi.142.2018.07.27.11.08.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 11:08:29 -0700 (PDT) Sender: Martin Wilke Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: =?utf-8?Q?Re=3A_make_distribution_fails=2C=C2=A0A_failure_has_bee?= =?utf-8?Q?n_detected_in_another_branch_of_the_parallel_make?= From: Martin Wilke In-Reply-To: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> Date: Sat, 28 Jul 2018 02:08:26 +0800 Cc: current@freebsd.org, brd@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> References: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> To: Charlie Li X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 18:08:33 -0000 r336743 CONFSGRP should be CONFSGROUP ? > On 28 Jul 2018, at 1:30 AM, Charlie Li wrote: >=20 > On 27/07/2018 13:21, Martin Wilke wrote: >> I just upgraded a jail in poudriere with latest head, = https://dpaste.de/bfTT/raw . >>=20 > I was about to inquire about this myself. Can additionally confirm = this > has been happening since at least r336735. >=20 > --=20 > Charlie Li > Can't think of a witty .sigline today=E2=80=A6 >=20 > (This email address is for mailing list use only; replace local-part > with vishwin for off-list communication) >=20 From owner-freebsd-current@freebsd.org Fri Jul 27 18:20:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C095E1052BE6 for ; Fri, 27 Jul 2018 18:20:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 528E680DB5 for ; Fri, 27 Jul 2018 18:20:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id e14-v6so8832624itf.1 for ; Fri, 27 Jul 2018 11:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=n3TFmLq5ZM+yVDyphpERbgpI8QYz3hyjzlAJaSYpU/Q=; b=hCPeQHPXY8EhaPguNGszpRrezq3xABPjm/5y4AqMzCOiW7wxuoJHX4ct7FPlT+Y7o0 LUUYiAN5mPSM2mQGM/DUg8BZnHpMgmBdFiAR6ruRTBkAlbDDXDC/N8OzeLfZXpTrvtRh 8IzUNhavsmfBo1SeY48yawW1J1A+/3fXWaXCgdatPZRS/cYpYLZXgRgykM29mXGd0SKo SBZSq1i6zOEQ8Y4f0CKRs0s/sDchQat/rR9UauQr2HE/S1U2NIFMDT34FU+92U4akfo3 EwUXykKQMxG0mlxqt8Ie6eA4PKtaVBuWigVvVnxlH7J69t8fMISxOjFIv8TFrcGce72U 7F5g== 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=n3TFmLq5ZM+yVDyphpERbgpI8QYz3hyjzlAJaSYpU/Q=; b=jVvrcZbKvTbejldvbjdBtWnPfjpFNpBQxhA6qoHn2WIdTF44dM3IF+qbewZtE2m3Cr XrL57RAzgPCl7vYIO5QVXdd4rH9NyZUdan6JYTZwitVK0fgOrrTngk50hxlM2jFbSWqH ypyCHSfozlJt+uFn2XlbBNR/LmdMzu1g1iYlOGiQXMfNelAm4/MWiiU7BSfubSeJJwyt 0a5v7lDgVHNdjpSsVY08+jAZWi+qQMZddoKumNQVMImCJPY4V6Hv0QLdX4w3jVnUYTrw VfMbb9YAT8EIhR2ZLuEkmBlNAcAgSk5Q2kMUMdXQSTv9TeIL6i5zmayRsTA2vKPyjmrt ezXA== X-Gm-Message-State: AOUpUlHPzzhlXfoQ4R74duWrS3USDGxK4KXgh0VJzwvG7vV2CAWusZwa YLJfx57xKUwsW7kqzyhmVI+fHb6unK2SDM8kUB//WPApyifXaw== X-Google-Smtp-Source: AAOMgpdyZP0cVFK/Xw+/LjPRUqFk4prkxw5RkCeNWjl4qMLCSpPm30oz7GYzjZTnm0Lb4ggHhq1s6xyXPu6TXI17EVE= X-Received: by 2002:a24:b211:: with SMTP id u17-v6mr6317667ite.1.1532715627663; Fri, 27 Jul 2018 11:20:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:4485:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 11:20:26 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> <20180727120232.270e1d9f@freyja.zeit4.iv.bundesimmobilien.de> <2A5E5E42-8595-44E9-A51E-504C9C2C7FA7@me.com> <20180727190555.55439fb3@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Fri, 27 Jul 2018 12:20:26 -0600 X-Google-Sender-Auth: pSKlm6X-R1XazrmZmZb8gqVzULg Message-ID: Subject: Re: [UEFI] Boot issues on some UEFI implementations To: "O. Hartmann" Cc: Toomas Soome , "Rodney W. Grimes" , freebsd-current , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 18:20:29 -0000 [[ context trimmed ]] On Fri, Jul 27, 2018 at 12:03 PM, Warner Losh wrote: > > > On Fri, Jul 27, 2018 at 11:05 AM, O. Hartmann > wrote: > >> >> Just to add another success on ASRock Z77-Pro4 (800k ESP, FAT12) and >> ASRock Z77-Pro4M >> (300mb ESP, FAT32). >> >> On this firmware, I did not have to define/copy the bootloader >> within /efi/freebd/BOOTx64.efi. It was sufficient to add an EFI variable >> as described in >> the manpage efibootmgr(8). >> >> The only pitfall on this firmware (very old, last functional update 2013, >> Spectre/Meltodown mitigation only May 2018) was that I wasn't able to >> activate variable >> "0000"! Creating >> >> efibootmgr -c -l /mnt/efi/boot/BOOTx64.efi -L FreeBSD-12 >> >> which results in "Boot0000" >> >> and followed by >> >> efibootmgr -a 0000 >> >> or >> >> efibootmgr -n 0000 >> >> resulted in "No such variable" or similar. >> > > Yes. that's a bogus sanity check in the code. I've removed it and will > commit in a moment. > that should be fixed as of r336768. > I had to perform the very same task again to gain variable 0001 and then I >> was able to >> "activate" variable 0000. This might be due to the fact the only variable >> defined at all >> was Boot0005 pointing to the most recent USB flash device with 12-CURRENT >> from 2018-07-26 >> I just prepared. >> > That part is weird.... > Now, also those boxes boot via UEFI (one, 800k ESP with the /efi/boot >> folder, the other, >> 300mb ESP, with a copy /efi/freebsd as I had to do on the Fujitsu ESPRIMO >> Q956 firmware). > > > OK. > Cool!... Warner From owner-freebsd-current@freebsd.org Fri Jul 27 19:18:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF9A2105434B for ; Fri, 27 Jul 2018 19:18:58 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 368BE83B7B for ; Fri, 27 Jul 2018 19:18:58 +0000 (UTC) (envelope-from ml@vishwin.info) Received: by mailman.ysv.freebsd.org (Postfix) id EBDAB105434A; Fri, 27 Jul 2018 19:18:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA0301054349 for ; Fri, 27 Jul 2018 19:18:57 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (varun.vishwin.info [46.101.93.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "varun.vishwin.info", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3407D83B78 for ; Fri, 27 Jul 2018 19:18:56 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (fd35:9eae:7575::2 [IPv6:fd35:9eae:7575::2]) by varun.vishwin.info (OpenSMTPD) with ESMTP id 2fd73b36 for ; Fri, 27 Jul 2018 15:18:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=vishwin.info; h=subject :references:from:to:message-id:date:mime-version:in-reply-to :content-type; s=fuccboi12; bh=REWzLP9eDH8FtXDZreJ7Ac3vzZUqzlDjY nPfZ8/rBQ0=; b=bdEkeOA+H3KbURCxrumvTy/lBhvOYt27E/wLdjjOolJqyOJ7I 5PSQytSkVUFvAGd/4OdRGzLv2VMLlEaIwuABpmZ77fZ4fpKy5/U1xKyy7hFPnv18 Iab7VqCwM16XrOKYEip7TmfPpZJ0GeZ+U8VaVW4DzSsqzXAlKYhCbAMtIaIoaXPE awrvSqg1gBVPjb7etWv6FibrmXA9BhvIOxlLXaa6jlTqwT6351GdZ+KysZtskTx+ qHqjDVVoiPGVm0hil0XTXOaMFoQ455SGJMvtP4OJon26WWrZSBU1KBEtTlMSOnPv Pt/YjogITxIReNgqFOQC2daZEEOk109Lkl1jQ== Received: from [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d] (2001:470:8:6ca:cad7:19ff:fec0:a06d [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d]) by varun.vishwin.info (OpenSMTPD) with ESMTPSA id 4b03858e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 27 Jul 2018 15:18:52 -0400 (EDT) Subject: =?UTF-8?Q?Re=3a_make_distribution_fails=2c=c2=a0A_failure_has_been_?= =?UTF-8?Q?detected_in_another_branch_of_the_parallel_make?= References: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> From: Charlie Li Openpgp: preference=signencrypt Autocrypt: addr=ml@vishwin.info; keydata= xsFNBFe4p7sBEADHSqa7WkWYRhRiAYsECn4Ek29AkNS7SF4YAbZTzg+3xkPL5cM5zbNCR4U4 o99wC0Y5wQn9y9X9wM16k1AxBkeQ7Dgh+AjxYGnwDjyrVdx9fcId8dQvLV/xw4V2b5CtU0Et M9IE3MDOkgLtWJamTWIL/MfrNgWk5nRZDBhDcygkTO87t0Pi4WC/QQ3TrrDya6FbBPI7I5Y2 0arX2LAeXqJ6pF7uPfjqogKy3UL+t++9nTG6FNR2oftlts1AB+kGHXJf1GiewXLpPEJTGlXx P+XGhjALqJkFw6azELYKjZcd9zGEOWiKJKp2c2RUDdEJHy+cm6cJ8g7dabVA4ZXs5O7NzeMr on7xFbBx/l/0qHux+d7gS4Z+GJ9WGvzvuj4L8MLgA0eaNzn564RJ5FCtPpaulMhcSc78LhZs NCN3rq8VxsxNrIFTlvnLdLsTNITZOKXnyalE9WlM3cK6UlQaagShhO3FliI2hIOW7j4QWJZC Thynnnj5wIAOgKv1WKFwnKJsMfsohIME6uqmt5AcH5okXGZCcBJx30+enqsoEYOvg0pi5oY7 6F/bQdvHzY2prjeujo0oJhVSeRpv5tjEUBDjX525SPNqvr4uddHiavrFBkesOh7nnOjsEMZ1 i5Q6iZrQpteoafFZTld7tfLw8gMwyiSleKN+x7tJG1H3d1Bd7QARAQABzSFDaGFybGllIExp IDx2aXNod2luQHZpc2h3aW4uaW5mbz7CwYAEEwEIACoCGwMFCQPCZwAFCwkIBwIGFQgJCgsC BBYCAwECHgECF4AFAlfq/VYCGQEACgkQtQ4IJhNZSS0i+g//fRJwTJHY/sjK0T0Mh0PzwSnm OSYEcscxTuMR9BQaXPMFjEPpArtms0Wd9S29BgzLB+F7To9MCFGiDB6yvF5fba4Zz+oJ9hB8 lJ3lvY1Hr/hxdxK6Etzl/oXM8LN08Hi9XrHDWm1yuLLJvpaynoOGotZYDLoh0hPomPp3j1w/ BcVK6cRCUArAhXwH0HWTKYlZcRsL/paTXvVgi0TKqF29u2ADhjukQh7qAwcZebC+FfxV9On4 1gCkco144JJX77Ak7g/IWeJy7MJCzbwH41PNyn/X5lwv5N+4cKcGlSOi1ndJuySY2G2Pr1Wu rRyUQ/BF70/laaQOsd5Eg4QimzhOJ3G7QqtYOCZdFBvRs4i3ht0tyKgh4NIr9Zl6FaX/AsDJ d1PBdaWdUaY3NHEDFHtntL9xWxdc+UM21fMqAh+TK4zY+FhaudZO1MdBjrMd8ukjpveaoWZJ NgFageX28AWqxFpOhcPDchkUnydqmEEnl87zuZ8OS+HilDH4JzVGAnYrCG4+/h0b9V4QGevS Jp5lnmSXv2/YFkTDHSXmyBTXrVCjfZM3zH9I+3unYxwio0iAhj8sE4gD2Mx53fmBzoS/3ckf dbG0rZ2lecEFiWez4wn7YTHWLl2ujmeBbhjoyY5JPjvOCkn2Gbcy7tJZqTW7ajkWzZQcexyW 7lLoCkCXz9zOwU0EV7inuwEQAOaRmAfkM3cDXbGYr+8QZ08T037xFyTx3pPtfg74BaL1DF5o 4nr7XG410rHT3biOUxH3Gk7NILQibA746zm/TKjj8m/S4xc+aGA8l/Wx34C/6UO+zUNg0Cpz Vynmwtvj6oh/guoPuO2mELf0tQTXEP8vo4nRVcuYlDm0VKHS5OFadlZuYc8vlCx3jOC0vXyC DUKSZu5HdcP3a75OUrHFa7fS6A6n4J8/OKyiXXO9+tUielafHv0zF4Enl7pJgRXLPoJm5FZk RQWNdltVXtfPeOvhM8Plwk5XXjkNShGhsCzTF56f2DUlHCXJQAVDHAbYuscifUY+2HrA41SY SMM1nS5YpQXRWOMuxeh1xwia1GNvgaJdaucCKZ4Fff1F6YuTPKGCOEOifRPoLfO6Te93o2Fs NvNWutiCO0jJj1rlLLdV44chMbiOIsdMtsMpj5/T/Jrm7aD2NvWXJy5+aDyqjmE529oVBYha ouX9XEeWzUL5MxdqgT2LlmBv/y6XbXhXTOUHBBQyCBbqDqiQOWPtOkusiCajTyY0lsM3gR24 +igkJEMND+kJmMdn7G8pSKy7LgRlW4haGmz+80xfMf593APbzlnGB8gD0aH7/ejYCMkGaYz+ ZwFopkl0I4QQxSc3tvVljDhWNyGZxz2Dw4DNALHiG6xmESX00itf2zMPABMrABEBAAHCwWUE GAEIAA8FAle4p7sCGwwFCQPCZwAACgkQtQ4IJhNZSS3BIxAAsXD7PgkrQWu1DunaiPlL0MbR gv2evjY+2cLdpMt8Je3+e25r8JTbPKIV1QY3q0ju0yXgWLW0dM1hWSVpsQURLNyFYnivXt4q rLuDv4T/xTUo/xuV0rUOXp+oTDVKQ7KhpvKtaZFkP0a1z0pVFJbk7AI5UkQ4+lcuyTqzawxd vxn41s/FNKIxXTtj0PAgthzE0ZivAIj4USRaULC20ZvOYFW6rc10UPmrkLsrfXepakGBc0KJ EajF8LiOUqPE4c4BH2CoeEFu+e5OJAAl4kjj/CuNvtlko1Qjd31HPpMaha4l/WAd4kKPmMeW WuRxFkOwkkJFKW2ycH837Njl8Jn6dFSpgZ5/DPBvRdBXjAgDhySr2h9Zn5b6svtnh1ByKJKv ovzp+64IRqfotlLK3J9X1eKHlq10SyprH6IlxsGyXi987ZeV6/04UUAdmPXio/Enxbtna7D2 Cvo+aXTGM9Yu/YwxfmkWRJvEUUzqCOq63Z0Aa5ckOi+8FLUj3ZryS3ctmph/x/flN+ab4R22 pDL8LW1kwMH4Y4krv7l4GBgJPzkBGmonMclGf19i9zwC3TV8oSQ26cyi5d6QmuE3KN9NuLrD CJo3QQ3fpqQrnJbtd0M6fjuKWN0o7UTVEkcOXWWRF85d33VXG8XTDXEJmAJsELG7txDPNZ9o FqGGsWKHymE= To: current@freebsd.org Message-ID: <88c46b78-8d48-eb09-a67e-5abbd67261f7@vishwin.info> Date: Fri, 27 Jul 2018 15:18:45 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="51mI0KZ0qr9y6jhoKFfbgyyFQXFhsdZMe" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 19:18:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --51mI0KZ0qr9y6jhoKFfbgyyFQXFhsdZMe Content-Type: multipart/mixed; boundary="BjXRS8zK4UQ4T1YIajOzVw8GQWzDT5JFJ"; protected-headers="v1" From: Charlie Li To: current@freebsd.org Message-ID: <88c46b78-8d48-eb09-a67e-5abbd67261f7@vishwin.info> Subject: =?UTF-8?Q?Re=3a_make_distribution_fails=2c=c2=a0A_failure_has_been_?= =?UTF-8?Q?detected_in_another_branch_of_the_parallel_make?= References: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> In-Reply-To: <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> --BjXRS8zK4UQ4T1YIajOzVw8GQWzDT5JFJ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB-large Content-Transfer-Encoding: quoted-printable On 27/07/2018 14:08, Martin Wilke wrote: > r336743 CONFSGRP should be CONFSGROUP ? >=20 That line doesn't seem to make any difference. Probably a jemalloc interaction? Emitted when attempting to update a -CURRENT arm64.aarch64 cross-build jail: =3D=3D=3D> sbin/dump (installconfig) --- _CONFSINS_null --- install -C -o root -g operator -m 664 /dev/null /usr/local/poudriere/jails/aarch64-current/etc/dumpdates : jemalloc_rtree.c:205: Failed assertion: "!dependent || leaf !=3D NULL" Abort trap (core dumped) *** [_CONFSINS_null] Error code 134 make[4]: stopped in /usr/local/poudriere/jails/aarch64-current/usr/src/sbin/dump 1 error Looking at my amd64.amd64 logs again, the failed assertion message does indeed appear there as well. --=20 Charlie Li Can't think of a witty .sigline today=E2=80=A6 (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) --BjXRS8zK4UQ4T1YIajOzVw8GQWzDT5JFJ-- --51mI0KZ0qr9y6jhoKFfbgyyFQXFhsdZMe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE/RdyC3Asy49czZEGtQ4IJhNZSS0FAltbcBUACgkQtQ4IJhNZ SS0TKw//ckstViiDmHNTnHti1hSqrrnBFvZupwCN2CdUEVqcQbzJNk2K68Wu6ArD DAtGcAn4ibAAxRbVC8kivYUgi/NLt8/vTnJ35oG9mRNgUYW4UM5J0P1TxlEJb95x JzyCeAEwgvXzonHtJdSoNQiYqtuZSGdxpgpKH7PLR2BHzlbOMH/bBnfzhXpkQMNp YRI8H1gI7PY+Kfn625WsZD1VwAAlLu/Y/k4v3McY+hPsAs6VhiuLRTY4skATc9oQ olavQ23PbX2X2DZbukzWpcjeOhcZpCTOVLNEYRKfgBQ4p4Irs7xIGqweWpi+NDk5 flILRSbGdarz4RgyhBMCd7DPj7gyeHC5GL0WxpWj7nFdeZLBpoJNh3R2A3SHMt1g m9Sx3c0OtQQWEaRjzJTRZg93J+DMlWk0kMjLjoOYVVTrfyWLk7bKJoJp6sPnt8ZM hS+haJgJlPvODvZ8SFb24RDhArohvGGHT6XVeUIA6CS9ZTaNwOO8oJBqSFS6rDhD 6jJ71m9ccXHg3xF7B6rlBZBhCv98UrLWnwBRExQ6AEFQIOW6qGBek5XCSu1WkFUI HzKwpyFydy1xfZWicTQ3KFpHow8U/oEO7enlEnFdo0qGiW5L5nIXUyvIUPHVJSmH YSrRpf2eK+mPZmkytwF1YppWeHyKTUzgeckcrKIHGUgR4jpQymw= =+D6o -----END PGP SIGNATURE----- --51mI0KZ0qr9y6jhoKFfbgyyFQXFhsdZMe-- From owner-freebsd-current@freebsd.org Fri Jul 27 19:52:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CBA31054FF1 for ; Fri, 27 Jul 2018 19:52:47 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 165258512E for ; Fri, 27 Jul 2018 19:52:47 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CEF2F1054FF0; Fri, 27 Jul 2018 19:52:46 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBD641054FEF for ; Fri, 27 Jul 2018 19:52:46 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 615588512C; Fri, 27 Jul 2018 19:52:46 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E13C721957; Fri, 27 Jul 2018 15:52:39 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute5.internal (MEProxy); Fri, 27 Jul 2018 15:52:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=GHdLZU G/5qtDcar3kFslqSUmlreNfIgN3HCdSRL6VGE=; b=hHz3/uz1LtHuGYzHq/VIdc pEAJ/ovU60bZ5RKQdT8iLfmxK+PMrC1VcbFE7hLX76+6OvFsg2W72TkDnQjZG7Y7 gz8I3mUtb1AyOgMNRkKi7Yqum7e90uLl58zAvBonIfkAOK0grrFXJeIcY1D2uW9C G+kHtxkXUhV/XXLIRupaVrH7vSc0L9541SkMYxNTo1G32TS4kHHwe81Xw5VT/Pjl 7JuWHLVL0vTfD3cHQmfs/p7UCLG2CytJCDdtKHK5yd3RrjLlNkhO8g9XIXMEp8x6 f2pbsMdVsgho/gQDQajTUYzHckh060xCZErGgBnnx1YRjMkxn0BDrne8ZoSKxxDg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 88CF99E10B; Fri, 27 Jul 2018 15:52:39 -0400 (EDT) Message-Id: <1532721159.3662360.1455244528.139B8E85@webmail.messagingengine.com> From: Brad Davis To: Martin Wilke , Charlie Li Cc: current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Fri, 27 Jul 2018 13:52:39 -0600 In-Reply-To: <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> Subject: =?utf-8?Q?Re=3A=20make=20distribut?= =?utf-8?Q?ion=20fails=2C=C2=A0A=20failu?= =?utf-8?Q?re=20has=20been=20detect?= =?utf-8?Q?ed=20in=20another=20bran?= =?utf-8?Q?ch=20of=20the=20parallel?= =?utf-8?Q?=20make?= References: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 19:52:47 -0000 On Fri, Jul 27, 2018, at 12:08 PM, Martin Wilke wrote: > r336743 CONFSGRP should be CONFSGROUP ? > > > On 28 Jul 2018, at 1:30 AM, Charlie Li wrote: > > > > On 27/07/2018 13:21, Martin Wilke wrote: > >> I just upgraded a jail in poudriere with latest head, https://dpaste.de/bfTT/raw . > >> > > I was about to inquire about this myself. Can additionally confirm this > > has been happening since at least r336735. I'll update my poudriere jail shortly and see if I can reproduce it. But CONFSGRP is correct, see share/mk/bsd.confs.mk. Regards, Brad Davis From owner-freebsd-current@freebsd.org Fri Jul 27 21:19:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AF1C105721E for ; Fri, 27 Jul 2018 21:19:32 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2026E88FBF; Fri, 27 Jul 2018 21:19:32 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wm0-f65.google.com with SMTP id r24-v6so3023298wmh.0; Fri, 27 Jul 2018 14:19:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rHLrYUtENZtYPeYyhsrDasdfCqNM8UaIx3Liy3mBGzE=; b=h3/HivwflJmw/kwALJJFwdmrzzPV56xaRgUq6rboVTLsbM4+jG/Jgw7yThZdBrbUlK LBkblSfrEhyWVSdn3LHWd3StfMYvtA8qsV8JGvc6WPDrPwwMCiw8V2XlQvaxNFMmWuKu qJwf+yPB4mzRaJgPp4e5RL6499yQQEukSJRNv02thUzjmWEQt57rXtd6jJQM8oA1UiFY zCWGpr8uKRxMBgNHVEENSFvTEM7PN1m3EKZJIOlvF0vB/CAxq22ICSMt0+ECBFsdiS9+ mQ1GNj5X5DhRrYhcx8RE/4osTtOoHz1/iOOQ6DuyB7Iz5m0t4oYJ99aCSX/ZXWq2z46H dIAA== X-Gm-Message-State: AOUpUlElNv49p6wRjB8+/sy112L+6jVaao6IZFtMwdev7fSs7d2FnBsY vHMO4wgVm+VqUt4OcFwYd4AT9EgXsv5Yq7IpehNhjEgJ X-Google-Smtp-Source: AAOMgpf4n33LOsPIwyyNY5ZSU4bRl4uZyt3E+hWnrPNmOHUZxPofR1uqL6vRpcaASuvotGNyEuspZriz31dgVmTEWr0= X-Received: by 2002:a1c:13ca:: with SMTP id 193-v6mr5451943wmt.127.1532724654806; Fri, 27 Jul 2018 13:50:54 -0700 (PDT) MIME-Version: 1.0 References: <201807262003.w6QK3B7E026934@repo.freebsd.org> <20180727144355.GA47251@freefall.freebsd.org> <1532704935.61594.42.camel@freebsd.org> In-Reply-To: <1532704935.61594.42.camel@freebsd.org> From: Li-Wen Hsu Date: Fri, 27 Jul 2018 21:50:43 +0100 Message-ID: Subject: Re: svn commit: r336751 - head/usr.sbin/pw To: Ian Lepore Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 21:19:32 -0000 On Fri, Jul 27, 2018 at 4:22 PM Ian Lepore wrote: > This was just an error on my part, the code was wrong and I fixed it in > r336762. This time I made sure the kyua tests pass first. > > I had intended to run the kyua tests before and after re-applying my > changes to pw(8). Now that I look in my scrollback, it seems I ran the > "before" tests, then got distracted and forgot to run them again after > and just committed the changes. Sorry about the breakage. No worries, now the test job is back to normal: https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8377/ Thanks for your help! Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Fri Jul 27 21:22:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3015A1057450 for ; Fri, 27 Jul 2018 21:22:25 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 BCF3A8936E; Fri, 27 Jul 2018 21:22:24 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id e14-v6so9505294itf.1; Fri, 27 Jul 2018 14:22:24 -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=BX5H/Gby6w/IZ7J5EmO+Vlesnl0Caehn91C7lrPD5D8=; b=PPJfVsfaj97/Vv7G6aiIEyDNDMzMWBs5sLxQ1FRI2s/UNmBmSe/qlta91F2pYMm4ci ffw89JwdIVc0sOi0Sg4ko+03CeFg6LvCLGEvCrL5MBkvGlphNawG7bkj9z3MEBWydyiY mScr9wtEVZ1BYr8ueW0HMwQ2mrY/EHfz+fJZIKGCGlVtVDeoxT+O879xjZpRFcbeB6H/ 3GkYfAejP+KU1brlOrJl9UKFBs2ZF5ajANF2N/YWYtsenysog6RiB/xFS+255htrVCT9 f+/AWDRYgAvgmWMxPdvW7LbRRz9fYkq22n8sJqHjRZe2OtP6vIqb524t5Gtr28G3jGhl GizA== 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=BX5H/Gby6w/IZ7J5EmO+Vlesnl0Caehn91C7lrPD5D8=; b=G39nTmwhibUfq7B57IFXD6cIK4RYr4no426txoZRerKu1KjOSSpdwPuTZQbxOmBElo 0m7d96XZtYXLUmTqbBL1kc5pglAZLM4HxQ+nqsPjKOOGyGFEaqAsjvGyxmmbxsdNi8Pc kkEi0fet1HrKqvWuk+zIfAQfn2Km2w131S37YcFKhjV4PLGaEPOGbTbbE7JNZkWf6moP x4cbLd+vAOcbnqifPlY0fWqHEUmN0VEmY7p2LJNzrLdcTrvuHFrsBEJQ4KX9HWP09VOV 9l6Jfij5KlJX9YLFNxL1D1Nr9AhiNxnYykK76AtzWCTDD0SQ69+2df9BZ8gd6XFJwOf4 VPqw== X-Gm-Message-State: AOUpUlHU3HUeAKKViJ4kDc6o7zDMajokpKnAVRfH9uaF7qLcE3+xClD6 /pAnI6HFjUo2EDVXLytaTY5vELxzNZzgiNi0LcoKag== X-Google-Smtp-Source: AAOMgpdYSyLK5QAWWx0iZQst1dSOkoBYV9uUnU7e0zUojWnlS/OFJKHCdVpQM+VqNNx2+zq+dxr58GacS6YMRfcyVMc= X-Received: by 2002:a24:2c49:: with SMTP id i70-v6mr7204332iti.135.1532726544015; Fri, 27 Jul 2018 14:22:24 -0700 (PDT) MIME-Version: 1.0 Sender: antoine.brodin.freebsd@gmail.com Received: by 2002:a02:a495:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 14:22:23 -0700 (PDT) In-Reply-To: References: From: Antoine Brodin Date: Fri, 27 Jul 2018 23:22:23 +0200 X-Google-Sender-Auth: APHZmcHO8yuXFvVaZSYsO_BZAPE Message-ID: Subject: Re: make distribution fails, A failure has been detected in another branch of the parallel make To: Martin Wilke Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 21:22:25 -0000 On Fri, Jul 27, 2018 at 7:21 PM, Martin Wilke wrote: > Hi, > > I just upgraded a jail in poudriere with latest head, https://dpaste.de/bfTT/raw . portmgr@ reproduces this issue too. Antoine From owner-freebsd-current@freebsd.org Fri Jul 27 22:08:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E5FB10587B0 for ; Fri, 27 Jul 2018 22:08:25 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 09A748BA46 for ; Fri, 27 Jul 2018 22:08:25 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id BF11910587AD; Fri, 27 Jul 2018 22:08:24 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADACD10587AC for ; Fri, 27 Jul 2018 22:08:24 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DA888BA42; Fri, 27 Jul 2018 22:08:24 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 26DC221E5F; Fri, 27 Jul 2018 18:08:24 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Fri, 27 Jul 2018 18:08:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=6D+9Vo wwjN60Tui95IdwHKrudb0mfXXZkoLCaYuuVlI=; b=mk1/PA/r5Pac6ziCBnKseo 52hrnea3IdlT00gpD/4Qfmt1H+VVoLjA/PIEdP8N4waoo44yMdFxUcGf/imFOWrW hgVJuGH8jt95DAQrV2QX4wQ3lGan+Ds4OOmV5AHwb1rboiY4g9MEYUK5+oXkOrBv TV/yTZyIfd0LIKIRJpdb5vmKEIHXMSqKmNun6Htisq2IddmxDwxq74/uw/rs48Uu IbdFdYbcORLR+TMATqKrBvtS+mOFkqxwqHp2JD8Fr1ArA/OprlV9z9klOso9nDh3 AsmKxJh51IqR9DkePRsi+OySkKq3wIzQVCEIm2x7lqKJZKqtqf3wvZqPg58p+0JQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C2E514143; Fri, 27 Jul 2018 18:08:23 -0400 (EDT) Message-Id: <1532729303.3864091.1455351560.3184C531@webmail.messagingengine.com> From: Brad Davis To: Martin Wilke , Charlie Li Cc: current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e In-Reply-To: <1532721159.3662360.1455244528.139B8E85@webmail.messagingengine.com> Date: Fri, 27 Jul 2018 16:08:23 -0600 Subject: =?utf-8?Q?Re=3A=20make=20distribut?= =?utf-8?Q?ion=20fails=2C=C2=A0A=20failu?= =?utf-8?Q?re=20has=20been=20detect?= =?utf-8?Q?ed=20in=20another=20bran?= =?utf-8?Q?ch=20of=20the=20parallel?= =?utf-8?Q?=20make?= References: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> <1532721159.3662360.1455244528.139B8E85@webmail.messagingengine.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 22:08:25 -0000 On Fri, Jul 27, 2018, at 1:52 PM, Brad Davis wrote: > On Fri, Jul 27, 2018, at 12:08 PM, Martin Wilke wrote: > > r336743 CONFSGRP should be CONFSGROUP ? > > > > > On 28 Jul 2018, at 1:30 AM, Charlie Li wrote: > > > > > > On 27/07/2018 13:21, Martin Wilke wrote: > > >> I just upgraded a jail in poudriere with latest head, https://dpaste.de/bfTT/raw . > > >> > > > I was about to inquire about this myself. Can additionally confirm this > > > has been happening since at least r336735. > > I'll update my poudriere jail shortly and see if I can reproduce it. > > But CONFSGRP is correct, see share/mk/bsd.confs.mk. FYI, I have opened this review if you want to try the patch: https://reviews.freebsd.org/D16476 Regards, Brad Davis From owner-freebsd-current@freebsd.org Fri Jul 27 22:48:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F44E10595D2 for ; Fri, 27 Jul 2018 22:48:02 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 19FBF8D59F for ; Fri, 27 Jul 2018 22:48:02 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id D2C8210595D1; Fri, 27 Jul 2018 22:48:01 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C19FC10595D0 for ; Fri, 27 Jul 2018 22:48:01 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7151F8D59C; Fri, 27 Jul 2018 22:48:01 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0CEF321E3E; Fri, 27 Jul 2018 18:48:01 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute5.internal (MEProxy); Fri, 27 Jul 2018 18:48:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=A0qVQK qN0CHBqyt+XNYR1W5zTnvz+Uvz7D1Dz3gj1ns=; b=iBaZW+VrIDhrrLCwgW18st fq1YrWyN/n01mHS5gFftP6FQKLQSPvW/nKJtOlt9VcO6WnLwUsp+S66gfVD0xvw5 s9iPgIdi+JZfI2kvqqg+lMRHH5Dx9vKUJdD6IXUBxfHcr4feKJDS4ug+gO6SkBQn VayjcEnz6erZjq2o1i75FsCbU7cfgFFr6p8CJSPo32T+WGfh4BCDEpaOhArehDI+ 86T68DSTVtoGdq+CMKUspLLRhY3Au8HpdEtI+Jfl4mDQ5/nDD/U36i61sdBvC4Ky Dsb3qOc78cSXbhkkKJ/MlOWtL0zNKYswmVDty3Zf7rvjkozDoUi3vlq132egMRAA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A0D589E0D5; Fri, 27 Jul 2018 18:48:00 -0400 (EDT) Message-Id: <1532731680.922579.1455377000.74BCD325@webmail.messagingengine.com> From: Brad Davis To: Martin Wilke , Charlie Li Cc: current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e In-Reply-To: <1532729303.3864091.1455351560.3184C531@webmail.messagingengine.com> Date: Fri, 27 Jul 2018 16:48:00 -0600 Subject: =?utf-8?Q?Re=3A=20make=20distribut?= =?utf-8?Q?ion=20fails=2C=C2=A0A=20failu?= =?utf-8?Q?re=20has=20been=20detect?= =?utf-8?Q?ed=20in=20another=20bran?= =?utf-8?Q?ch=20of=20the=20parallel?= =?utf-8?Q?=20make?= References: <415fe444-a01a-3ced-257d-a7180f223189@vishwin.info> <06B12014-742D-477B-AD85-EA51C6A3EEFE@FreeBSD.org> <1532721159.3662360.1455244528.139B8E85@webmail.messagingengine.com> <1532729303.3864091.1455351560.3184C531@webmail.messagingengine.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 22:48:02 -0000 On Fri, Jul 27, 2018, at 4:08 PM, Brad Davis wrote: > On Fri, Jul 27, 2018, at 1:52 PM, Brad Davis wrote: > > On Fri, Jul 27, 2018, at 12:08 PM, Martin Wilke wrote: > > > r336743 CONFSGRP should be CONFSGROUP ? > > > > > > > On 28 Jul 2018, at 1:30 AM, Charlie Li wrote: > > > > > > > > On 27/07/2018 13:21, Martin Wilke wrote: > > > >> I just upgraded a jail in poudriere with latest head, https://dpaste.de/bfTT/raw . > > > >> > > > > I was about to inquire about this myself. Can additionally confirm this > > > > has been happening since at least r336735. > > > > I'll update my poudriere jail shortly and see if I can reproduce it. > > > > But CONFSGRP is correct, see share/mk/bsd.confs.mk. > > FYI, I have opened this review if you want to try the patch: > > https://reviews.freebsd.org/D16476 Committed in r336794. Regards, Brad Davis From owner-freebsd-current@freebsd.org Sat Jul 28 02:41:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D500105FF11 for ; Sat, 28 Jul 2018 02:41:24 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 3481275018 for ; Sat, 28 Jul 2018 02:41:24 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x236.google.com with SMTP id l7-v6so5687501ioj.1 for ; Fri, 27 Jul 2018 19:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1niYgZkcXpPoLRwU5vTGI7XN79tnb1+s4q7+yowu/zE=; b=e//Eb+fJWYrnMODQzwlu9eyENJ2aT61E8mU6ZMsyfDMnppA7DaQC0wKJ/0JBgN5M+B MPy2aYvnYil8HaniJVTvG3hKaUsE90z+p0zgo9VXa+sluWrToeHA8R/yLE55WAcSo7y+ 03RgxxLi9ZZFFs4qXR6ZfeURDasCDk63PAVSdY0eysVl5yTOKhxVS6OuJ/xCwVLtrdRX jQk/+2UA0BKrnJifhpg9ZZGmgtqUIbcf9iBsl6zubBCyKDw6evJUa0JrOMQlV1rLlRQU zryXysPHOMUx91HSiwIjkk8Q5E4hK/2RypaqmyVRqYJSOFOJ1zWV0hVg23Dxy3btRdf4 j8ew== 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=1niYgZkcXpPoLRwU5vTGI7XN79tnb1+s4q7+yowu/zE=; b=cI0cpbzjOwQ2WCuADn06GtZUGAi6PvDjHvXZt5GxrvHe4BhF+mBnN1uBNvgwI52DUX BfOZzinKw1PkvlrPIUgj+VgJQT7RIa/WlR0dI6A/egpCguCSsfba1YDKG7QEi1K9+uYm gx4n8bim+F9wTrOniA7kdlx5Fwr92Sd9W8h4ExeOhb2jfU25EYMoFO93xmZfEPfkhaOi tBGfncZtCgJYr/acxI0ggHq1e+yF8t+8/oal9egrzdVjWznr874XxFxSZISszK5Wa9fb cfw3iwHL3uhIa4i3TqOQbrIKeRcEi1aEmY5mT7jlSC9kdQ8TqYLMHJqRFEF30CeFHxAW jjng== X-Gm-Message-State: AOUpUlGyoUSgQPo5dotSn+B7P9C5+4n8qP0bS7+KG/jePJlbBt+GL+31 4EUiZr0oDzQv+f3x49zi6g2DsRpYsFHQsD4w6hyG/LLb X-Google-Smtp-Source: AAOMgpftnqtmdPnWTOclCeT0H5lyBUSlBBITxXRDc/xajU+OY5s+pGgYVrXvlmiN8uWRFnXtx2PS1bcT/bUZWgk0v6g= X-Received: by 2002:a6b:1bd5:: with SMTP id b204-v6mr7403368iob.240.1532745683230; Fri, 27 Jul 2018 19:41:23 -0700 (PDT) MIME-Version: 1.0 From: blubee blubeeme Date: Sat, 28 Jul 2018 10:41:11 +0800 Message-ID: Subject: automake-wrapper conflicts To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 02:41:24 -0000 I am getting some build errors around automake-wrapper. I tried deinstalling automake-wrapper and then installing automake but then during the installation of automake I get this error: install-info: warning: no info dir entry in `/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info' /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1' install -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1 doc/automake-1.16.1 '/usr/ports/devel/automake/work/stage/usr/local/man/man1' /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' install -m 0644 lib/Automake/Config.pm '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' /usr/bin/make install-data-hook chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh' find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: No such file or directory ====> Compressing man pages (compress-man) ===> Installing for automake-1.16.1 ===> Checking if automake already installed ===> Registering installation for automake-1.16.1 Installing automake-1.16.1... pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203 (installs files into the same place). Problematic file: /usr/local/bin/aclocal *** Error code 70 Is this just me or a bug? Best, Owen From owner-freebsd-current@freebsd.org Sat Jul 28 02:43:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E66071060030 for ; Sat, 28 Jul 2018 02:43:14 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 7E30075311 for ; Sat, 28 Jul 2018 02:43:14 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x230.google.com with SMTP id v26-v6so5679024iog.5 for ; Fri, 27 Jul 2018 19:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7uSDL6d5734NrUS2XV7+rvvDd/HkfU8wcmWoBLD8vB4=; b=G0G5d4tQc5X7eHCCoDylnMZHshWBLEHLnexBIz5Nu2H+ENUTh2v86V2rQl1YY4ynyK v0sy3fNpFVHUu2l8tyVDLw6gEmDkN9Z2UGR7vp4throoALcowDo6mFIGZrv6MSZq+a9x RfERrZlG8NSs/oVmUD5uja5bylrKddIYRViTW/DRK9dHUIPqrfvL99CmkBlZIoQ1h51v DHfdYUFiyri4rexLcBGoPFOovRuk2qWs1+DG17o8Cte7J70Ic5I4Uilfk1LyLwyLhxxI X/yrFXQNqvWH7GqfoTphkgwugijriFUKy6rr8ZAAXG5l3YGjflHnlqaSt9Nr29ihQGNs w6Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7uSDL6d5734NrUS2XV7+rvvDd/HkfU8wcmWoBLD8vB4=; b=Aka5Iy9NLi/9ZeUYdWYxV3mcmZ3uua00A4GUp5KNxuzEu6SqFXMALqO6mz9GOal7d/ x1FuOj464OQueFiIBv0v5aoYksmdzYtvQfNVJif46Dw2Q0luSnVd/kAvP24dHeJWS9hI eANQJc/3PehgkvAJTUaCeYEja4/yic7XTb4CC+ZDkrMOmhJcuj1XJ6HG2vEk3nPgacBu C1i5i0nxN0neEBzdxrx9gumIP5i/xflk7tmRIQEXj2bEM55iR49KWN1ZdqMSk1wBld9g VQrc7sVofKzovk0tKrVzkTU9wBemjo3BG/P1PlPuxjudqoqTPMhsRF6d68OFnyx14uCO Feig== X-Gm-Message-State: AOUpUlErUGBtlpTMiR11fGrHq41f967PWEg2Wl+sJqbi2NC/H+Co6VPX NYMYA9j9QnWwCVyZNJNmVrRTLAXLZk/f/3nK8bZ8hQ== X-Google-Smtp-Source: AAOMgpeHwdMO6UI7ZstYJioGwphDdQTVfWhQ70UGTOPCCE5I7Ro3Tnq70NGNMcN2qpj0W1zAyM5ZnR2OXCe4BwCL1js= X-Received: by 2002:a6b:9c09:: with SMTP id f9-v6mr7135960ioe.179.1532745793674; Fri, 27 Jul 2018 19:43:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: blubee blubeeme Date: Sat, 28 Jul 2018 10:43:02 +0800 Message-ID: Subject: Re: automake-wrapper conflicts To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 02:43:15 -0000 On Sat, Jul 28, 2018 at 10:41 AM blubee blubeeme wrote: > I am getting some build errors around automake-wrapper. > > I tried deinstalling automake-wrapper and then installing automake but > then during the installation of automake I get this error: > > install-info: warning: no info dir entry in > `/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info > ' > /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1' > install -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1 > doc/automake-1.16.1 > '/usr/ports/devel/automake/work/stage/usr/local/man/man1' > /bin/mkdir -p > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' > install -m 0644 lib/Automake/Config.pm > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' > /usr/bin/make install-data-hook > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh' > find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: > No such file or directory > ====> Compressing man pages (compress-man) > ===> Installing for automake-1.16.1 > ===> Checking if automake already installed > ===> Registering installation for automake-1.16.1 > Installing automake-1.16.1... > pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203 > (installs files into the same place). Problematic file: > /usr/local/bin/aclocal > *** Error code 70 > > > Is this just me or a bug? > > Best, > Owen > Okay, seems that UPDATING addresses this issue! Best, Owen From owner-freebsd-current@freebsd.org Sat Jul 28 07:29:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6856E10445E5 for ; Sat, 28 Jul 2018 07:29:50 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 D93AD7F164 for ; Sat, 28 Jul 2018 07:29:49 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id s14-v6so7903505wmc.1 for ; Sat, 28 Jul 2018 00:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=laqKPIt8uGhZkOU38GbRURNGPWd+nliqy4Q4Syk0v+k=; b=cC7r9IZpV6Ne0geiRznL+57oAq/CgI6npZDeOvbvYlzJEN5x/XGfUOlik5uX+0fzoe qO11TlqCYW6+ra4I67zyYyps1L4+VFCzWdZf39V0uHDwvLrSDSkSQtAmWKQ/HxvW/gG2 PyQ/rhmPAGBj5InZf0ElxPdvQMMMY7Z4/De34ED93xmNi65xKaC7n05R8tFuNO+gOnsh u+bxsqDCtoa9kLcuHDHjSaPl+zI3W9xw+pdZkjnGx7Cj/XoRo9T3p2Ke+H+PT65MRT7i l9HIUm3N4vWuVJ/oM2wIHAC715tD+ZklDYOi5SrgiIpFw6yblKxksu5crAOmWcoSSP6l VX1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=laqKPIt8uGhZkOU38GbRURNGPWd+nliqy4Q4Syk0v+k=; b=DYAdQCkrveZfaAxFRXZ7srf5RYvMh+Csbwtadej5TlegchM5P/espds1943tL0Wk67 z/IWwzKXfqyTExtQZhpK+xNtvGvAyGbetvgZhDyqnE9DifdCG/W6WKzXQ9f8d8XC0ndr ZNpv0wGxNEApYIXL9lojgeS1HNlbMjl4KwX+Q5BuEt7ZlqSsorkqoOzvtEWj+XhLzSAN cgOCkU2fr7SVb9EpXbc2h/QuPlM87hy+5LZ/q8Uo7INd7RX5cL+LNScxgXnqkHrD9r3S AZSgGU+B9Ic5awfRm5soxIs++7tUlmYnKDhj2+OVhJDBaCWrS7THEFoi90MVEKm/5opD 8HSQ== X-Gm-Message-State: AOUpUlF/7TIoLMxlREMB8gjM4TFl+BmotHFYVmp64dwlylmPdR0WVeL4 I0sVqDb2fsV67jmuFyCBV/HnFk2O X-Google-Smtp-Source: AAOMgpcBPZxBJi94ltPSGW6EmhntW421rQ/mvjoA9kH/t6ChnPKQXnjOCCxHAvpTyO0CdvHsu0QKfg== X-Received: by 2002:a1c:d0ce:: with SMTP id h197-v6mr6880636wmg.43.1532762988377; Sat, 28 Jul 2018 00:29:48 -0700 (PDT) Received: from kloomba ([95.104.142.14]) by smtp.gmail.com with ESMTPSA id i205-v6sm7962762wmf.30.2018.07.28.00.29.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 00:29:47 -0700 (PDT) Sender: Roman Bogorodskiy Date: Sat, 28 Jul 2018 11:29:40 +0400 From: Roman Bogorodskiy To: freebsd-current@freebsd.org Subject: EFI issues Message-ID: <20180728072938.GA28778@kloomba> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 07:29:50 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have a test box that's updated to -CURRENT usually once in a week or two. This box boots using UEFI. After a regular update about two weeks ago it started to panic on boot frequently (not UEFI related), but I could not get a crash dump because my swap partition was too small. So I moved data to the backup drive, repartitioned the main drive and boot again. This went fine, so I decided to upgrade to fresh -CURRENT from ~Jul 27th. Booting with the new kernel went fine, but after installworld machine stopped booting, and on the screen I see: FreeBSD/amd64 EFI loader, ... .. BootOrder: .... And then it gets stuck and nothing happens. As I already have a fresh backup, I decided that it'd be easier to just re-install and copy data back over (maybe I messed up with repartitioning). So I've downloaded a fresh snapshot: FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img And re-installed. In the installer I choose all the same settings that were before: UEFI + GPT, default partition scheme it suggested (efi followed by freebsd-ufs followed by freebsd-swap), just increased the swap size. And the newly installed system won't boot just like a previous one: https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg Is there a way to recover this? Roman Bogorodskiy --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbXBtiAAoJEMltX/4IwiJqpc0IAIASeteIOrNx19vV1lozQwgB wtEgsK6ckV/CgnjfZ+H/a7Ui+RnxULvPZVsNZrVPydseK55ZQRYC2btXyYKARbjU XDoqDuT+sFQQcuMb98WNxrBHWKn+85UDrKX1YkL68b9qazKHDFqiZoeVZ/DBpjoD DVaTERcyCgDCK3KYO5ohH73J3Gatl+5PL68/moaG8vvtJO9lMqhbg6QnNKdTV/vl 8rpNqRzKyMSbE3C1NDOY4/n3EBvuemR48iMyhLAoIeDGV5pxYxdER0C4iIIqhYhD IuiEm05XeX7Ty6FRmzpehvZvuYvKqMjhRfeMrtij4E+y3vNVK3Bla5S0vhU+CU8= =7zrs -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@freebsd.org Sat Jul 28 10:34:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 994F0104A5CB for ; Sat, 28 Jul 2018 10:34:33 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (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 1C54884956 for ; Sat, 28 Jul 2018 10:34:33 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: by mail-pl0-x234.google.com with SMTP id m1-v6so3378482plt.6 for ; Sat, 28 Jul 2018 03:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rZIMYbOSdc8jPh7+20X5MI6zCAt7xK1pO+zJs/3s3ok=; b=M2rIz9EXgWgQUIVYw6AcCdZWTSGTRedw/toaRYPjhjf2vZOIV7kmPz+d/0AYlSCqa7 2kLmkx88Dop9yXEyc/F5lqKbLdWaTJRcXSns/AsoTRWg4yAHVNSkdDohTWPOK2kpEeZQ X2nDe+TeXJW3IyfweefBYCJB2Uw8rP7y6CxLkOPqmHLYJA0sjUW9Czq3FIoukt481D57 OYGZuMV3oOqkiwVqeUjDFggQO3YI002Tk1Hz7ZanoWWj+I/RhYVkUBnagasXZLYBk8mw Vi1s7G/h+sYqJ43X7Vl2wSEq8i4aKbKxu/2BgEhQpQ7/3pviQv3NOT2f/1q64xliR5dY vjDA== 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=rZIMYbOSdc8jPh7+20X5MI6zCAt7xK1pO+zJs/3s3ok=; b=Wu2gW+/5jZ+8PBKe9DPoSm3aVplV5loOplP/8DLflvfmuini5LZPOJIxfaoVK69ES8 kvENJhVt7Ykmhx3/z8mpvpRP/6HQJ+pH+rBQQC5guTyl3pgUic6dMl0QtPTFjXI8DD3L o+2u5WIbmGuxbQKdIV7tnjQu4DRuQUJyV7QM9qV6UT+t21CX2dlc9jF8yskre256Gsmj 8Y8oe77jnE7CQefDr00/EEvm1QwrASH80Dlv4uZLptZTyBbVGIu3pFUBOhCOWdNX/stN Imq2dWIasSFedqoLQD7L4t7Y+XhtrthSkaAqLYkCagFo9Sz7X0Nr+jmZZgjOJzfVrMKT vV/Q== X-Gm-Message-State: AOUpUlEW0Em3p3lTQr3cuzUGnj4ZwcY5NtOksAd5oeJp09MvJsl9FYfk cbkOBBu6WIGoysqPU1nmSaaSoiv39P5pYIDslcBSBULY2WU= X-Google-Smtp-Source: AAOMgpc++MaQLVc1zvGTZb3TzeGi8m5f7nME4BI10lxOmCzPrlDDz5j/gmxGgtmoNhc/HjiZ1AMEIkMvkGKHmAr186o= X-Received: by 2002:a17:902:a613:: with SMTP id u19-v6mr9180063plq.234.1532774071738; Sat, 28 Jul 2018 03:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:7148:0:0:0:0 with HTTP; Sat, 28 Jul 2018 03:34:31 -0700 (PDT) From: Samy Mahmoudi Date: Sat, 28 Jul 2018 12:34:31 +0200 Message-ID: Subject: r336806: buildworld failed: emmintrin.h file not found To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 10:34:33 -0000 ---- Basic/SourceManager.o ---- /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1175:10 fatal error: 'emmintrin.h' file not found #include ^------------------ The file is located at /usr/src/contrib/llvm/tools/clang/lib/Headers/emmintrin.h but I do not know how to properly indicate this to the build suite. From owner-freebsd-current@freebsd.org Sat Jul 28 11:06:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8C94104B738 for ; Sat, 28 Jul 2018 11:06:41 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 3DC1186528 for ; Sat, 28 Jul 2018 11:06:41 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: by mail-pg1-x52d.google.com with SMTP id f1-v6so4653921pgq.12 for ; Sat, 28 Jul 2018 04:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Wwhl2tbrBHn5bmwGCalB5WtZFR/K4J6suW/hxo7D4Fs=; b=VXnOlEyEb5FuzeZZsSA5gEn5F/KRGEMOP3/PK4zmlgT8ZUf5EYtkgjEZKBoL1AWxzv r9p8HhV5S9oJ+bZyp1hFTpbuJsFE5hplD1bU1+sN3PFp1VX41+rRKMGOAzZvw42iYjLj qSfVtvuQDHaIn7llfpAJSWPUSicNQrMsuJ9JShzsXfYJe+u2oPQ6gzmC530pTS5OfbgM aXjnWbz0dJfrSSNXhNhStMmOqRPKIBHxnjtqVsmhBw/I+9HZ9M8hlFDeabyEbl/29VLc cP04aXfkL1v0rpC4v8skxpqpSVRRbaCF8b3ROm6Pjm04qf1RwIsqS5IOkAtWE6VWHzRD cUMA== 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; bh=Wwhl2tbrBHn5bmwGCalB5WtZFR/K4J6suW/hxo7D4Fs=; b=XJ591y9/SMIwnoPZa2+NpOw7t3ZSMTduiYI4ic2NZiq9DYvbEmnPboPXy1TiKr8ZUE DFizppBD08EicIuq8ICqazwsJ9NnIqXKQyLjc9ZKeFjB6nPa1SOnwMOfK0gs+jUj2Ygp ACxPkvazK7tyYL261OUMywAvVm3D2Zt95OtBi3luFrse5yGWkAoKNOHgAALmpv7ikJHy ICCYFUG99cFkFoxJM6TBJQEzK64u/eRaGr2gR8DXWVo4pXuFi80YMXvVzV90i79wJUQy FRBiJfWnNvQuFloHG0NGfX/IutnvtRT15z9uITgDa+BA+W50feS+BN/lZ/OeboffG2oo nWzg== X-Gm-Message-State: AOUpUlFNJE7c+6ZUe/35ZnZLbkrQNHa1ezSY86d/mR8ioIhGwPvqDrlr ralt4OJKeMdMO8uxEnSER5HNoVxjd1nYGXxEzrXdyXCKJIM= X-Google-Smtp-Source: AAOMgpc+qW2cLZq9OQmQ80ALc5OfV6bSB+/aoAJP/A4+b0HR2m5QaSin/+rMY8tFnUFz6KEEzndj0mLvHU6EOy3dhHs= X-Received: by 2002:a65:5106:: with SMTP id f6-v6mr9288366pgq.72.1532776000061; Sat, 28 Jul 2018 04:06:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:7148:0:0:0:0 with HTTP; Sat, 28 Jul 2018 04:06:39 -0700 (PDT) In-Reply-To: References: From: Samy Mahmoudi Date: Sat, 28 Jul 2018 13:06:39 +0200 Message-ID: Subject: Re: r336806: buildworld failed: emmintrin.h file not found To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 11:06:42 -0000 I found an answer in the last comment of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190669 2018-07-28 12:34 GMT+02:00 Samy Mahmoudi : > ---- Basic/SourceManager.o ---- > /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1175:10 > fatal error: 'emmintrin.h' file not found > #include > ^------------------ > The file is located at /usr/src/contrib/llvm/tools/clang/lib/Headers/emmintrin.h > but I do not know how to properly indicate this to the build suite. > From owner-freebsd-current@freebsd.org Sat Jul 28 17:18:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B38C105769D for ; Sat, 28 Jul 2018 17:18:40 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 C185576216 for ; Sat, 28 Jul 2018 17:18:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x244.google.com with SMTP id n11-v6so8973187wmc.2 for ; Sat, 28 Jul 2018 10:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=CQLao8vk2u0OMeIrhSv6bAmzsYoQyDzwO6wkjiaB034=; b=Ezc/TYjvDQJYpXGSMZFUqJgAkPPrryPBZmvwyfuztB4D+aeTIApM7RCPaqwPMADo4B WoFEZUSrBfprHe2traPsPlvgrjO/akf2rnfpA706nwjzsZ/i00q+XMO/TwCCydCGABMp ghiWvFPuzMrPOrpZ3BxULIMudCuK/ejJMrOTqKXMYI3mYB8xeVpsS0BaXgHq+IO7Es5w iU0IdDEw+Q/u5jb5q7H7UrcaI7k111hGbCJdwUzjz4b/OStQhAjuIDu+wyqpxwHJf82b gRgwc+f5EZ+tZSbUfFVR44vcK8By3t+IGIYFn9JTlLd7/DDPsKFMxq1cbsZxOPGetqZE bLaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=CQLao8vk2u0OMeIrhSv6bAmzsYoQyDzwO6wkjiaB034=; b=Z3p7QMgxWQ2sBNfJO2/1MvkH26pwnU39y/m7LM0x1v/8OZHYabKTBh3JEpErQORDNX ZPnS23C6fPGzBJKa6YIysUfiy4GJenbcxykPp8W9c3rSdo5tKFr4rReN8v7aD69qCzpd 6KZaTTP0x/pFSL/hWZpRaOstO0654kXy1ZxeTgtbrwFjDWUmSttSqhzLGVe2YHWU3GnV QTGPkjKpOvDkL2FtjQT71NWJoFvrn09bHCdeFQl4bwMaaK2blbzPJvyZchdhn1fsBHf3 irnMPDWSbh5SIWVqBZ0Fasixs3bza82I63eknxtexRlEu8Bt/Dzl9VyXEPjJxVi77I9g /Hfg== X-Gm-Message-State: AOUpUlGueH1/K3Ti6zEib3a+8MiL8LgnYZjt3wRBsLLRqpdQTQeu/zYW TE+zCD+Li7rCD/AVA33527UiGZzfQ+C0QfpZOcRUCkU88ukG7S4p7nKb9dKaNnSThzCVO8HeJK4 sJMz5huKT5wHsJ8IbsM2tChflNm1EI0eGnOi8piwBur6x8LFOLnuEYOi8EAo+NpBXnbhCWJ9tU7 VGfPP9ubLpRA== X-Google-Smtp-Source: AAOMgpeL2qbWPzYtxtXu16+gFfkgo2h0dfq28tkJFmYfq8aN2cjHhPGJRBjDDHX7kyzj5ma4kGxu9w== X-Received: by 2002:a1c:6709:: with SMTP id b9-v6mr8917104wmc.68.1532798318281; Sat, 28 Jul 2018 10:18:38 -0700 (PDT) Received: from mutt-hbsd (tor-exit0-readme.dfri.se. [171.25.193.20]) by smtp.gmail.com with ESMTPSA id f9-v6sm7578297wmc.29.2018.07.28.10.18.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 10:18:37 -0700 (PDT) Date: Sat, 28 Jul 2018 13:17:45 -0400 From: Shawn Webb To: freebsd-current@freebsd.org, imp@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Booting arm64 uefi broken Message-ID: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lrstudwzs4myzhby" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 17:18:40 -0000 --lrstudwzs4myzhby Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It appears with the latest 12-CURRENT/arm64, booting is broken. The boot process gets stuck after the "Using DTB provided by..." message. This is on my SoftIron OverDrive 1000: >> FreeBSD EFI boot block = =20 Loader path: /boot/loader.efi = =20 = =20 Initializing modules: ZFS UFS = =20 Load Path: \EFI\BOOT\BOOTAA64.EFI = =20 Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,G= PT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) BootCurrent: 0002 = =20 BootOrder: 0001 0005 0006 0000 0002[*] = =20 Probing 7 block devices......+..* done = =20 ZFS found the following pools: rpool = =20 UFS found 1 partition = =20 Consoles: EFI console = =20 FreeBSD/arm64 EFI loader, Revision 1.1 = =20 (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) = =20 = =20 Command line arguments: loader.efi = =20 EFI version: 2.60 = =20 EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) = =20 Console: efi (0) = =20 Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00)= =20 Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,G= PT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) BootCurrent: 0002 = =20 BootOrder: 0001 0005 0006 0000 0002[*] = =20 BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) = =20 Ignoring Boot0002: Only one DP found = =20 Trying ESP: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,7= 3365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) Setting currdev to disk1p2: = =20 Loading /boot/defaults/loader.conf = =20 /boot/kernel/kernel text=3D0x8a7169 data=3D0x1384d0+0x7d39fc syms=3D[0x8+0x= 11d108+0x8+0x10e646] /boot/entropy size=3D0x1000 = =20 efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics= Adapter present = =20 Hit [Enter] to boot immediately, or any other key for command prompt. = =20 Booting [/boot/kernel/kernel]... = =20 Using DTB provided by EFI at 0x801fe00000. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --lrstudwzs4myzhby Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAltcpTUACgkQaoRlj1JF bu6WZBAAiMqyxjuVx0VmvVHMLJ5FI7zugUGjIEvnhaNJfnc86+9UUsc1pW9Ztn65 xP32REdbKLywBDYPrexUT2Rpq16s613SwKuPMGmndfEKmbLY9/FnAJS5QgJ1kaUQ PsdnBSw6kJzxe5LiB2lLVuapwbwOl/QK3lgrWf5Fd1rGvQoD0U6TAPYxAhKLVr9q kbDMuLp+f35PKX5TKg1xV1LMNtRfWADSmalCt0/SozzkXLh4Kl5MMJbZ5KpvppRT OiyRKQACEXHkPPB8ALr1/4zuY6T2HeswnIAKVSmY91rz7WbGNxfU3ydk245WqIno TQ6UQzc47fsKO6pzdRKSB9Nl5oKUcHyMUWlh0ORX0L0Yzrn2DIzJy78UWjdb8wGY t8t92cqfW1J3RrfDcxFGOhEZzQ+cPsPnY0HFmapg9jLTJ/qm3Tx2kbFTVdxy0NYy YAQlH+HLhYAfw1TtChYt8Z3b9Q43qbPDjR207GM+qGmE41T+Sd9GOiSczwcb7Xtr CyybpV+dqiJcauUGLe3epxrb1R5o0hgo1BVHv1BFitotTsvmvDjUpeN4ydzNLxHs cC7104YuO9QxhvpdcvSNAYUXe5IwlEAbssxwA+RvMGt+S4mBp5GmsqB0+u61ztx1 iJdiTXHIMX5pExn2HHIwrtkvMEfugVBLhB4x+HytI/vmqiko4qg= =Jkmr -----END PGP SIGNATURE----- --lrstudwzs4myzhby-- From owner-freebsd-current@freebsd.org Sat Jul 28 18:08:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 533671058B70; Sat, 28 Jul 2018 18:08:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 DA99977DAB; Sat, 28 Jul 2018 18:08:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x532.google.com with SMTP id n7-v6so5016629pgq.4; Sat, 28 Jul 2018 11:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6ZRhc3iECwNdn7XNogoWFWL/7A0Yjpiyu1QQ4yAIwy0=; b=k5fVv/wYF8Bl1nOFxxixgL4zZh44NxZ8hOeSay7o3LOfycb2NCUHib9VS/kH3lOMaS JN9AJYHv1pDGjHrYEDYvQ4IS9sypS9gnQqaFFZiVf3OStBWqh1l+mNrDaZ+6D8OAq5lB kOO8cDTn6fKLg50viYTrM7XeJyqF67UFPkKBF1DVCTCRpwKSE7Q9Ajqd4iwD3Ck8Bobt DRH6wtSbjpBQYF7Al0BJweuGm/DVmmLpKgddVi193uXcOjUBlDeLOkwnyBLEfzUl0Png 57p5xUxWoPi5qzmlhfyUo8qMvy8yeV2gxBG25HJgPPKf//pT5383sbVz69qjHQWVoGGX TeVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=6ZRhc3iECwNdn7XNogoWFWL/7A0Yjpiyu1QQ4yAIwy0=; b=Zl1aWdfAygxs1fuCJzavOaQFbhW8itsGugCttIvhVu/IK7myGstKFjZODHqZA3irtX 5ME/4vw6OX/IAmSm54n4YD8d6n1UkKwfeLK3eoDCdvqDFxdBf+bbF2RonhkV+zPQYrci XeuvTJDu7ChJxwIhOgUOTGzViFCJoRZWwPJSbEPCvg8h60AI37XvdEcYqHN33UZbvaDw 5HB55BR2EJCI2VunGUu8cuD3AMH9nMX6d/Q++SXVW5LYFkhmjykDPVwZ+WLqtprQRMOP khd0nSa6vtSZZIb+YnlX1SFiXO2vEDa/vOSNkGNGxrIyo5mTGVqXBrlaKuGpBPlQd/Br 2Rig== X-Gm-Message-State: AOUpUlFJqM2eGhT9sjWH4XzFUxB3GYgjZs7ss4CHcGmO5Qr6FxdCXGt3 KBGUwqXqbpDJYOFX+mcwto7t3DCE X-Google-Smtp-Source: AAOMgpdC60Bv+lNxPpmVmpW5s9KPf4hjWQj4L3b3rZuXzIiJRqKNEfx3GRkI8MZ6IXkhjcnU1YEvYw== X-Received: by 2002:a63:6188:: with SMTP id v130-v6mr10542494pgb.100.1532801317840; Sat, 28 Jul 2018 11:08:37 -0700 (PDT) Received: from raichu (toroon0560w-lp130-03-174-88-72-141.dsl.bell.ca. [174.88.72.141]) by smtp.gmail.com with ESMTPSA id h69-v6sm22382450pfh.13.2018.07.28.11.08.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 11:08:36 -0700 (PDT) Sender: Mark Johnston Date: Sat, 28 Jul 2018 14:08:31 -0400 From: Mark Johnston To: Shawn Webb Cc: freebsd-current@freebsd.org, imp@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Booting arm64 uefi broken Message-ID: <20180728180831.GA73141@raichu> References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 18:08:39 -0000 On Sat, Jul 28, 2018 at 01:17:45PM -0400, Shawn Webb wrote: > It appears with the latest 12-CURRENT/arm64, booting is broken. The > boot process gets stuck after the "Using DTB provided by..." message. > > This is on my SoftIron OverDrive 1000: You might try the patch here: https://reviews.freebsd.org/D16463 From owner-freebsd-current@freebsd.org Sat Jul 28 18:10:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4CC61058CE0 for ; Sat, 28 Jul 2018 18:10:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 76B9877FD4 for ; Sat, 28 Jul 2018 18:10:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id d9-v6so11831343itf.2 for ; Sat, 28 Jul 2018 11:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bn5VMqpjRlypqt9bc1LgGKulb5rv+0XvGi17nEjBJz4=; b=g5loSrIXw2ATH/CjJsJ3/sVHe7VzN8gnzQ3K+AIwMdLQEgKFW7lhkgMI+hXJRy5+Hk 8bTgxADglgcLf+hjyCJ9FI5OMrCqMpEIg6LbND5iwNAKduW86+gxdVylfZwLVYEE6Co2 Bgjar2HagA427hGr8iC7U10aT1JWSXc9e6mLpbzhT3R9zbLqDhcZZsUbv/7rvrmp4e1z DpvMtmbSK8uSekr7EBtNK1upnjvI/IC7ROaC2Nc2RssAg5UHQgoscvNF6qm2TBZ2fXL3 kIGWlGpr5R5Hl9WR1V06Wert7un0t4UXr6T/DnsT0xnLaLm0Y9d6vMr0ggRXAmNk1sNa p5yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bn5VMqpjRlypqt9bc1LgGKulb5rv+0XvGi17nEjBJz4=; b=hPFQKlUSuRysXBQdkRB1ARR2MshN0cd0FKmstl515zPv47fZ94g3UW/VSFgvxhcP2N r0NIPP7I9iVb+3N476DG6F3pl5oBbIT85U9CIzZAszFX56kwu5kgy/evf4GJH05Vlbhg iHeWaDQ/c7sVtjCetZQ7MC3xgK9uQ9LaGnz6FuU4hPhDwSaHG9lZn6I4g0A0HFyOeFnW 0stom+zmHW0EHCUzGM7s6qjYlyFV3u6c0WLZ9BWpoMKrgOFjJ/IP1Fs/JLhJhzwKFrFO hlO+2MrSv2cVzqRSKhjd7WuwgdPkQutrZ9YTmkIy0RXrrTW12y9VSSTXnT1UewauqUW0 ltsA== X-Gm-Message-State: AOUpUlFNfuL7nZl1By0SMLpriV1yLAGEmzzdsOIdsAh30hkkIrkdWcCR 4HrCIXDs6iXXFplA4so7QEWafh1zKRAUsadwAZNR7g== X-Google-Smtp-Source: AAOMgpeDvqlfgcf3jArcZyRAr+A2aNcm8Xz+mTjyvbk/xcVgmp7treJK6pzAunnXnPYDoQm3rhZxpoacETPAt+yR2/0= X-Received: by 2002:a24:3ec3:: with SMTP id s186-v6mr1996373its.73.1532801452708; Sat, 28 Jul 2018 11:10:52 -0700 (PDT) MIME-Version: 1.0 References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728180831.GA73141@raichu> In-Reply-To: <20180728180831.GA73141@raichu> From: Warner Losh Date: Sat, 28 Jul 2018 12:10:40 -0600 Message-ID: Subject: Re: Booting arm64 uefi broken To: Mark Johnston Cc: Shawn Webb , FreeBSD Current , imp@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 18:10:54 -0000 On Sat, Jul 28, 2018, 12:08 PM Mark Johnston wrote: > On Sat, Jul 28, 2018 at 01:17:45PM -0400, Shawn Webb wrote: > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > boot process gets stuck after the "Using DTB provided by..." message. > > > > This is on my SoftIron OverDrive 1000: > > You might try the patch here: https://reviews.freebsd.org/D16463 That's in the tree now... Warner > > From owner-freebsd-current@freebsd.org Sat Jul 28 18:28:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BB7D1059699; Sat, 28 Jul 2018 18:28:40 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC7E779120; Sat, 28 Jul 2018 18:28:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 4480a98d; Sat, 28 Jul 2018 20:28:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=TOKSQbC/nbtMpiXP8RDIWN8NoRE=; b=LFlvJTH/v7k2314K5nocDV/jPVlh xBDf6ZYB6u5vObrq9FSYxo1XAUPd1o4gHhhogD0G8MdSQI5UXBMaEDvUhXQtALuX gdds5u2K62ke9/SWYNV8qgttdipO6jyN8ARifDflc/i1Y/xlB1g9p346n+jsCKRo wZVigYTuTTW5UWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=IexAdoD7PEnTea9ajb6/qkLcqymFdM/1uzrvAnNR3iqCcTFNCBB9zeKM xwX1HzFu5LtDQpebZGDrU8zw2mevdckMUPiFUyBno+ne+TxgloU764AkWvM/OShy 9r3O+cLOCCXreC1mwFRRjoQTJNNh34lXGUA10+M96l+3ITl8VDM= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id b6f3ea70 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 28 Jul 2018 20:28:31 +0200 (CEST) Date: Sat, 28 Jul 2018 20:28:30 +0200 From: Emmanuel Vadot To: Shawn Webb Cc: freebsd-current@freebsd.org, imp@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Booting arm64 uefi broken Message-Id: <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> In-Reply-To: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 18:28:40 -0000 On Sat, 28 Jul 2018 13:17:45 -0400 Shawn Webb wrote: > It appears with the latest 12-CURRENT/arm64, booting is broken. The > boot process gets stuck after the "Using DTB provided by..." message. > > This is on my SoftIron OverDrive 1000: > > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: ZFS UFS > Load Path: \EFI\BOOT\BOOTAA64.EFI > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > BootCurrent: 0002 > BootOrder: 0001 0005 0006 0000 0002[*] > Probing 7 block devices......+..* done > ZFS found the following pools: rpool > UFS found 1 partition > Consoles: EFI console > FreeBSD/arm64 EFI loader, Revision 1.1 > (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) > > Command line arguments: loader.efi > EFI version: 2.60 > EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > Console: efi (0) > Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > BootCurrent: 0002 > BootOrder: 0001 0005 0006 0000 0002[*] > BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > Ignoring Boot0002: Only one DP found > Trying ESP: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > Setting currdev to disk1p2: > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc syms=[0x8+0x11d108+0x8+0x10e646] > /boot/entropy size=0x1000 > efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics Adapter present > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x801fe00000. > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal: +1 443-546-8752 > Tor+XMPP+OTR: lattera@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE Latest kernel works for me : FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r336834: Sat Jul 28 20:23:33 CEST 2018 root@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC arm64 I'll try with latest loader.efi -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Sat Jul 28 18:34:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CC1A1059B4B; Sat, 28 Jul 2018 18:34:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D154798F6; Sat, 28 Jul 2018 18:34:33 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 81595a3b; Sat, 28 Jul 2018 20:34:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=lFL2I0tdaV+a EV1B15/2RsjBMQc=; b=Y/29eBCRxumpRvHgt/EmkPuqthlbmim+v39v+OzdJl9O LOimAkC/fK+ly1EwGFswTMR3NCM4Uni9/ivEZpnjf5Omh/SQevzinJ0ofsPuRzCE ujnDyMoM6yrT2WXCiy6KBMeud/U4QdX+cZ9qOwo2Z9sZ5zQlFl3I7GTZE4B/gpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=JI4L06 Pa0u37szhQM9b8Yaw2jXXp8oucVIDDyDffoLNfNaMvRcW+BkpC0Sx1QG2KHxPpbQ FZnAxS59lBJlLKEFd/IyJ4sWDxlebe5+syz4I/PszDK/z1HDwnHtX26COcKQqCgg jhpBbEIpmMFvzPFJIrM79qOsIYH/eh1iCpg8Y= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id c27a64d7 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 28 Jul 2018 20:34:32 +0200 (CEST) Date: Sat, 28 Jul 2018 20:34:31 +0200 From: Emmanuel Vadot To: Shawn Webb , freebsd-current@freebsd.org, imp@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Booting arm64 uefi broken Message-Id: <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> In-Reply-To: <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 18:34:34 -0000 On Sat, 28 Jul 2018 20:28:30 +0200 Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 13:17:45 -0400 > Shawn Webb wrote: > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > boot process gets stuck after the "Using DTB provided by..." message. > > > > This is on my SoftIron OverDrive 1000: > > > > >> FreeBSD EFI boot block > > Loader path: /boot/loader.efi > > > > Initializing modules: ZFS UFS > > Load Path: \EFI\BOOT\BOOTAA64.EFI > > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > BootCurrent: 0002 > > BootOrder: 0001 0005 0006 0000 0002[*] > > Probing 7 block devices......+..* done > > ZFS found the following pools: rpool > > UFS found 1 partition > > Consoles: EFI console > > FreeBSD/arm64 EFI loader, Revision 1.1 > > (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) > > > > Command line arguments: loader.efi > > EFI version: 2.60 > > EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > Console: efi (0) > > Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > BootCurrent: 0002 > > BootOrder: 0001 0005 0006 0000 0002[*] > > BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > Ignoring Boot0002: Only one DP found > > Trying ESP: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > Setting currdev to disk1p2: > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc syms=[0x8+0x11d108+0x8+0x10e646] > > /boot/entropy size=0x1000 > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics Adapter present > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Using DTB provided by EFI at 0x801fe00000. > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder and Security Engineer > > HardenedBSD > > > > Tor-ified Signal: +1 443-546-8752 > > Tor+XMPP+OTR: lattera@is.a.hacker.sx > > GPG Key ID: 0x6A84658F52456EEE > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > > Latest kernel works for me : > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > r336834: Sat Jul 28 20:23:33 CEST 2018 > root@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC > arm64 > > I'll try with latest loader.efi > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Latest loader.efi fails for me the same way, Shawn did you start bisecting ? -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Sat Jul 28 18:37:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9DF41059CD4 for ; Sat, 28 Jul 2018 18:37:10 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6498179B74 for ; Sat, 28 Jul 2018 18:37:10 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x243.google.com with SMTP id r24-v6so4750386wmh.0 for ; Sat, 28 Jul 2018 11:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=c7p80zJtut5YpD+vey4bzPLDdMlbtfNfHnuuKjrTBKA=; b=D//UON6jyWbUwFsgM30etJ2VGp6D7eReaoFml+/iLMygNt+2nZGzN9vK2MoSzwXp1P CApEddvKz+FowuSerOIsb4znJ5kzo3gzLMOlTpi/Ed9Eab2LUEoMlHCG35z/f7WIGkGH 600f2MjQCwpzQprGqjGeFdK+xirYodVrW8X6R4ck1eCLBmt44dKOZz5b554mp26r8mGO XPhwkDes3lHm8RQRy+A11poKxVxmNeo2bFv9CoOgea2+bAqApxUJG1oj88+c9LasuJsD zYhYQCOdxvh1T+cec9X8K6OVuhh3eQ7QR1xl+HGegLkZyxX7gjIt50DaVl/wTsP5xNf7 5jfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=c7p80zJtut5YpD+vey4bzPLDdMlbtfNfHnuuKjrTBKA=; b=tGbZOPyPky/A2iZz9oEqP/n6avxQSaLvC6pwVIEMlj9yyZ+B8qxzSew+z30fKosYU/ vei2TF1Ia4d9SDE82USHVE6scEudtDT0n4UUSbYbeX8sBaUrwlucfQDDmB+LkJ5iq7Nx ce9DjEb3MGoz9pzyaYiWNwE/nMc6pXG2FjAVQNT4fDD1wEdgDi8r+Z20Pfw6tL33Dp9C AUtXxNqC3uWTBbzAVfb2r2SaKHJFKQr3ZxIAZ+eoRIpp+WHVc3bBlTbwl0pcfx3rJqFD VUkeJxj+wrQnltZv1I7xMDmvT8cfXd8OIcD9Ve7lm6iOJv2rd8a1+mOp9mqEKprebmSS u+AQ== X-Gm-Message-State: AOUpUlEn3y3mZ1/C0LUOwUX3+rJz7iSrqtNjyWMQAOIKtzLFSyVlht3p kFVE/+ZA6Vf9pqi/Q3SpbKKsyyBKn/gAGg== X-Google-Smtp-Source: AAOMgpfTtYKtVExshjmnR1EwxlwGrpLny24nJrPaWergIqoCay9tXq02aQpO0WyzKF0w31/1sI03og== X-Received: by 2002:a1c:6c14:: with SMTP id h20-v6mr9257625wmc.138.1532803029276; Sat, 28 Jul 2018 11:37:09 -0700 (PDT) Received: from mutt-hbsd ([185.248.160.21]) by smtp.gmail.com with ESMTPSA id w4-v6sm1047208wrl.46.2018.07.28.11.37.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 11:37:08 -0700 (PDT) Date: Sat, 28 Jul 2018 14:36:29 -0400 From: Shawn Webb To: Emmanuel Vadot Cc: freebsd-current@freebsd.org, imp@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Booting arm64 uefi broken Message-ID: <20180728183629.wxxabsnyrnqlmwog@mutt-hbsd> References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xfblujcxadv7knd2" Content-Disposition: inline In-Reply-To: <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 18:37:11 -0000 --xfblujcxadv7knd2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 28, 2018 at 08:34:31PM +0200, Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 20:28:30 +0200 > Emmanuel Vadot wrote: >=20 > > On Sat, 28 Jul 2018 13:17:45 -0400 > > Shawn Webb wrote: > >=20 > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > > boot process gets stuck after the "Using DTB provided by..." message. > > >=20 > > > This is on my SoftIron OverDrive 1000: > > >=20 > > > >> FreeBSD EFI boot block = =20 > > > Loader path: /boot/loader.efi = =20 > > > = =20 > > > Initializing modules: ZFS UFS = =20 > > > Load Path: \EFI\BOOT\BOOTAA64.EFI = =20 > > > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/= HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > > BootCurrent: 0002 = =20 > > > BootOrder: 0001 0005 0006 0000 0002[*] = =20 > > > Probing 7 block devices......+..* done = =20 > > > ZFS found the following pools: rpool = =20 > > > UFS found 1 partition = =20 > > > Consoles: EFI console = =20 > > > FreeBSD/arm64 EFI loader, Revision 1.1 = =20 > > > (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) = =20 > > > = =20 > > > Command line arguments: loader.efi = =20 > > > EFI version: 2.60 = =20 > > > EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) = =20 > > > Console: efi (0) = =20 > > > Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x1= 07D00) =20 > > > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/= HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > BootCurrent: 0002 = =20 > > > BootOrder: 0001 0005 0006 0000 0002[*] = =20 > > > BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0= ) =20 > > > Ignoring Boot0002: Only one DP found = =20 > > > Trying ESP: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2= ,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > Setting currdev to disk1p2: = =20 > > > Loading /boot/defaults/loader.conf = =20 > > > /boot/kernel/kernel text=3D0x8a7169 data=3D0x1384d0+0x7d39fc syms=3D[= 0x8+0x11d108+0x8+0x10e646] > > > /boot/entropy size=3D0x1000 = =20 > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal Gr= aphics Adapter present > > > = =20 > > > Hit [Enter] to boot immediately, or any other key for command prompt.= =20 > > > Booting [/boot/kernel/kernel]... = =20 > > > Using DTB provided by EFI at 0x801fe00000. > > >=20 > > > Thanks, > > >=20 > > > --=20 > > > Shawn Webb > > > Cofounder and Security Engineer > > > HardenedBSD > > >=20 > > > Tor-ified Signal: +1 443-546-8752 > > > Tor+XMPP+OTR: lattera@is.a.hacker.sx > > > GPG Key ID: 0x6A84658F52456EEE > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6E= EE > >=20 > > Latest kernel works for me : > >=20 > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > > r336834: Sat Jul 28 20:23:33 CEST 2018 > > root@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC > > arm64 > >=20 > > I'll try with latest loader.efi > >=20 > > --=20 > > Emmanuel Vadot > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 > Latest loader.efi fails for me the same way, Shawn did you start > bisecting ? Not yet. I don't have the time to right now. Probably won't for a while. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --xfblujcxadv7knd2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAltct6wACgkQaoRlj1JF bu7E7RAAingoE1tCaX3WddW9eljNvWJHYoI4ufChuRqAfFziVMiauW4GxzXbxt7A gogcl2NcvJKzkVBYdhf8Kvv2S3O5867Cf98uR3GwgG217i4El+NFApNpnAjJaqWb QDLT/ChTayZy7IrhFJfpYFwOk/Vxo0wqPP2r9QpvAUASDZwI6hMbunBSMFdawsp6 PeuYmPCkhCG0HeI+Vhkm5mXxaDDOvSvMb4L+YFh9c6JjW5ohrA8hUBVDlYuAZp1H jPcnT9pcuQhKIqxHzlaSkjrEQfurFxKiRSRJdljYYn77Jv5ueHNbtNmNbcCPVzCq apnWQRElao5gK5fbSmudqRsTm6sxYCgNZAJ3DnEFAad/n9DfYpXVuY7P6d+9rxKA kc7Ukcf3smFwSWKfydjU9PCqj9/mMZFIW9afMpDLrER+vY1irE+Hf5dABCcAvWBd BMLzqq/hn9ZXInokoOB1McnZDA4dr9KPTFaMtl/X97M0lUibtW52n1Yqqg4tMoUc yM3gVaYtgNbtEB+K/V4OnDPo4j7v0fP/VOD3ZF/3V3gZDq3lqNggG3lMkQMZLSCt OPHli1rV8Jgqf1+vasjeGsTOp+RxeMdRmFo3dUqfQ6FI97E/jcOEIYoFkXQJh8Ng VEui5swrBPPsxj6Eo3XzSV5mDbrJ67zZG92++nKlAlDizcl+z6c= =YNPl -----END PGP SIGNATURE----- --xfblujcxadv7knd2-- From owner-freebsd-current@freebsd.org Sat Jul 28 18:52:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0ADFE105A45C; Sat, 28 Jul 2018 18:52:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E2297A94F; Sat, 28 Jul 2018 18:52:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 273df023; Sat, 28 Jul 2018 20:52:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=bnWQwJ59H2NC 0kVAjhydsZenQmw=; b=CivJYgJDacDoE9/0FLzXYFu3354gZ2Dh9CB54c5chTDC GZPPm2zvA0OJk7VfHbbfVwdBYHeuVJycTk8ErcK0v8lhJ8xl6QUnmHGkodC4hqm0 7cQKLw20FCrwGoTcpkFaqP9gf2WKx/dkRojGJq3RO5rd2XWyDySV25EHQLJ92Ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=DefcAN K6DiY5fhdwMo1KRisxMA0WU79ftMePadnzdyRBeyCReDYP5uC6QESLg0DnLPMP+a jpGj88IMH+zErHTrbrmOx99ZBS3gnTIi4z0ieBpWwYjzxNiSEPTp++80AaIWsDVa JuWp6NCnjV7iqD4KPzdaJYfzzJtBZ7pZin68Y= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6e800f86 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 28 Jul 2018 20:52:18 +0200 (CEST) Date: Sat, 28 Jul 2018 20:52:18 +0200 From: Emmanuel Vadot To: Shawn Webb , freebsd-current@freebsd.org, imp@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Booting arm64 uefi broken Message-Id: <20180728205218.ef2661f72f27709c5d829708@bidouilliste.com> In-Reply-To: <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 18:52:21 -0000 On Sat, 28 Jul 2018 20:34:31 +0200 Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 20:28:30 +0200 > Emmanuel Vadot wrote: > > > On Sat, 28 Jul 2018 13:17:45 -0400 > > Shawn Webb wrote: > > > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > > boot process gets stuck after the "Using DTB provided by..." message. > > > > > > This is on my SoftIron OverDrive 1000: > > > > > > >> FreeBSD EFI boot block > > > Loader path: /boot/loader.efi > > > > > > Initializing modules: ZFS UFS > > > Load Path: \EFI\BOOT\BOOTAA64.EFI > > > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > > BootCurrent: 0002 > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > Probing 7 block devices......+..* done > > > ZFS found the following pools: rpool > > > UFS found 1 partition > > > Consoles: EFI console > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) > > > > > > Command line arguments: loader.efi > > > EFI version: 2.60 > > > EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > Console: efi (0) > > > Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > Load Device: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > BootCurrent: 0002 > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > Ignoring Boot0002: Only one DP found > > > Trying ESP: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > Setting currdev to disk1p2: > > > Loading /boot/defaults/loader.conf > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc syms=[0x8+0x11d108+0x8+0x10e646] > > > /boot/entropy size=0x1000 > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics Adapter present > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]... > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder and Security Engineer > > > HardenedBSD > > > > > > Tor-ified Signal: +1 443-546-8752 > > > Tor+XMPP+OTR: lattera@is.a.hacker.sx > > > GPG Key ID: 0x6A84658F52456EEE > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > > > > Latest kernel works for me : > > > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > > r336834: Sat Jul 28 20:23:33 CEST 2018 > > root@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC > > arm64 > > > > I'll try with latest loader.efi > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Latest loader.efi fails for me the same way, Shawn did you start > bisecting ? > Problem is between 20180709 and 20180719 -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Sat Jul 28 19:27:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 247D8105B4B4 for ; Sat, 28 Jul 2018 19:27:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 AE3867BF6C for ; Sat, 28 Jul 2018 19:27:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id e14-v6so12199053itf.1 for ; Sat, 28 Jul 2018 12:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u8lEF3azVlg8efjkeqkMcIZL/47YrOXSgRF3rGv+QP8=; b=tI5bD/VLYsNBAnghR7AoNCy2enfhQwQcIHPJerm79l0bGheLItyi409s3ZvCPd1nOB fv+BYGTXw4D9ylK0yduC1TLUSbV6KCJ63IrszZIryI6lwAdFT0QzySd3qUXTy4vL3p8N TqcgPDYoRksD889NHe7S5YN8XOXmDVUeIjEZOCdByZne98zJCVjFHGWND6u3LZHEya/k vyIsUjGZFwFaBWSQG4ny1ST+u2RiUjTHeJNqIhqlgYTeW6MzJJs6+yh5HQpO5OpL4lxd 72bOZrL4bBJc7NhsaUMD3VSMibvn+f+b5MDg7O8rY04TKHa2Auh5MUwfv+kJoBkj5nRt erNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u8lEF3azVlg8efjkeqkMcIZL/47YrOXSgRF3rGv+QP8=; b=LCeARf3UoryABwMYS6+H8cf5uwAS7ECDpaKNr0QjvJR6b8dzRvY8YTy/jDhC0ZmaLi OkLotc9cibK9tjUAYYNAXA8AO2xCOJloUnS92sZeeZmOl5N9cIZvKGmbWidiP09YM9ff 9jyT5ymAZb4pFudmxob9it691/9XmrcSdWQL96IjYf8QIEhdYHqjDys6rtFsO7wjblO9 u3d6QbW809uI4xBPmLD4oPtEXrwijvLdnescPXdfey2XqZqSCwwAQnZjXedwFx8u2NdU ON550pRjEKMPjSwjXKf+I+rnR6kBgkCmJ5Fb6sT3SXVSvXRYDcQguR/zw4nslGnL8448 T5qA== X-Gm-Message-State: AOUpUlFM5fFCCEome6LzIUTroQ9NCyFGTAEF34HEfnEzMKKIW1ooo7m9 jRLQ24bjEhRMtAeeQCwPhbX1WsLWApM8X1ohk6uIUQ== X-Google-Smtp-Source: AAOMgpfOBVwOxl1SJokX/+Vw1ejjmKF3v2B3pMWaP2+QePcQnVtb/MmHNHbiQDVDKTh96frA7iZm6Qjafs9TuRDeKvA= X-Received: by 2002:a24:4f52:: with SMTP id c79-v6mr9529838itb.36.1532806039962; Sat, 28 Jul 2018 12:27:19 -0700 (PDT) MIME-Version: 1.0 References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> <20180728205218.ef2661f72f27709c5d829708@bidouilliste.com> In-Reply-To: <20180728205218.ef2661f72f27709c5d829708@bidouilliste.com> From: Warner Losh Date: Sat, 28 Jul 2018 13:27:08 -0600 Message-ID: Subject: Re: Booting arm64 uefi broken To: Emmanuel Vadot Cc: Shawn Webb , FreeBSD Current , imp@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 19:27:21 -0000 Let me know the rev... all my fixes are in the tree... Warner On Sat, Jul 28, 2018, 12:52 PM Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 20:34:31 +0200 > Emmanuel Vadot wrote: > > > On Sat, 28 Jul 2018 20:28:30 +0200 > > Emmanuel Vadot wrote: > > > > > On Sat, 28 Jul 2018 13:17:45 -0400 > > > Shawn Webb wrote: > > > > > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > > > boot process gets stuck after the "Using DTB provided by..." message. > > > > > > > > This is on my SoftIron OverDrive 1000: > > > > > > > > >> FreeBSD EFI boot block > > > > > Loader path: /boot/loader.efi > > > > > > > > > > Initializing modules: ZFS UFS > > > > > Load Path: \EFI\BOOT\BOOTAA64.EFI > > > > > Load Device: > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > > > BootCurrent: 0002 > > > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > > > Probing 7 block devices......+..* done > > > > > ZFS found the following pools: rpool > > > > > UFS found 1 partition > > > > > Consoles: EFI console > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > > (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) > > > > > > > > > > Command line arguments: loader.efi > > > > > EFI version: 2.60 > > > > > EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > > > Console: efi (0) > > > > > Load Path: > HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > Load Device: > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > BootCurrent: 0002 > > > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > > > BootInfo Path: > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > > Ignoring Boot0002: Only one DP found > > > > > Trying ESP: > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > Setting currdev to disk1p2: > > > > > Loading /boot/defaults/loader.conf > > > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > syms=[0x8+0x11d108+0x8+0x10e646] > > > > /boot/entropy size=0x1000 > > > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal > Graphics Adapter present > > > > > > > > > Hit [Enter] to boot immediately, or any other key for command > prompt. > > > > Booting [/boot/kernel/kernel]... > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > > > Thanks, > > > > > > > > -- > > > > Shawn Webb > > > > Cofounder and Security Engineer > > > > HardenedBSD > > > > > > > > Tor-ified Signal: +1 443-546-8752 > > > > Tor+XMPP+OTR: lattera@is.a.hacker.sx > > > > GPG Key ID: 0x6A84658F52456EEE > > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 > 6EEE > > > > > > Latest kernel works for me : > > > > > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > > > r336834: Sat Jul 28 20:23:33 CEST 2018 > > > root@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC > > > arm64 > > > > > > I'll try with latest loader.efi > > > > > > -- > > > Emmanuel Vadot > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > Latest loader.efi fails for me the same way, Shawn did you start > > bisecting ? > > > > Problem is between 20180709 and 20180719 > > -- > Emmanuel Vadot > From owner-freebsd-current@freebsd.org Sat Jul 28 19:50:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C8EA105BF29; Sat, 28 Jul 2018 19:50:28 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B88267CE61; Sat, 28 Jul 2018 19:50:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 760810c6; Sat, 28 Jul 2018 21:50:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=+VMEA4ZsaA23W7gU/m2rwuSGuGE=; b=sIQ6ozSy7cOlmpBi+kS9bu+gPhG+ ZtWpVL98wkUBT2ZkjOBXqXopxDGMQRLzTOl99pHgnN/Iswub+k47x8JUTdoA9zUY 0rppnftJTzmISBt8FqsxZU1QblgFWCo2IWPUAQCT+31xSNjiyaAgapdAn2Lk/jZB bGYLW1y0gA48FMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=aBIt9tPMqSSCqqFpq3Du5uZIo6owne22NZaNeu4WXTK9jFIRt9Sq4aGp fWkgbqbbIPBrDJk80kxS34ci9Jfl1YmWyBmjpHmyzgRi4I/NtrJvln+qReEIAGPq DC5ipT2AntYrthqCnMiirLbbhCHzpL0e8la+Qpqy+w/Q1waFFuw= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 37850b65 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 28 Jul 2018 21:50:25 +0200 (CEST) Date: Sat, 28 Jul 2018 21:50:25 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Shawn Webb , FreeBSD Current , imp@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Booting arm64 uefi broken Message-Id: <20180728215025.f5acbac48ab0969eff2e7545@bidouilliste.com> In-Reply-To: References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> <20180728205218.ef2661f72f27709c5d829708@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 19:50:28 -0000 On Sat, 28 Jul 2018 13:27:08 -0600 Warner Losh wrote: > Let me know the rev... all my fixes are in the tree... > > Warner Fixed by r336837 Thanks, > On Sat, Jul 28, 2018, 12:52 PM Emmanuel Vadot wrote: > > > On Sat, 28 Jul 2018 20:34:31 +0200 > > Emmanuel Vadot wrote: > > > > > On Sat, 28 Jul 2018 20:28:30 +0200 > > > Emmanuel Vadot wrote: > > > > > > > On Sat, 28 Jul 2018 13:17:45 -0400 > > > > Shawn Webb wrote: > > > > > > > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > > > > boot process gets stuck after the "Using DTB provided by..." message. > > > > > > > > > > This is on my SoftIron OverDrive 1000: > > > > > > > > > > >> FreeBSD EFI boot block > > > > > > > Loader path: /boot/loader.efi > > > > > > > > > > > > > > Initializing modules: ZFS UFS > > > > > > > Load Path: \EFI\BOOT\BOOTAA64.EFI > > > > > > > Load Device: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > > > > BootCurrent: 0002 > > > > > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > > > > > Probing 7 block devices......+..* done > > > > > > > ZFS found the following pools: rpool > > > > > > > UFS found 1 partition > > > > > > > Consoles: EFI console > > > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > > > > (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) > > > > > > > > > > > > > > Command line arguments: loader.efi > > > > > > > EFI version: 2.60 > > > > > > > EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > > > > > Console: efi (0) > > > > > > > Load Path: > > HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > > Load Device: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > > BootCurrent: 0002 > > > > > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > > > > > BootInfo Path: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > > > Ignoring Boot0002: Only one DP found > > > > > > > Trying ESP: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > > Setting currdev to disk1p2: > > > > > > > Loading /boot/defaults/loader.conf > > > > > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > > syms=[0x8+0x11d108+0x8+0x10e646] > > > > > /boot/entropy size=0x1000 > > > > > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal > > Graphics Adapter present > > > > > > > > > > > > Hit [Enter] to boot immediately, or any other key for command > > prompt. > > > > > Booting [/boot/kernel/kernel]... > > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Shawn Webb > > > > > Cofounder and Security Engineer > > > > > HardenedBSD > > > > > > > > > > Tor-ified Signal: +1 443-546-8752 > > > > > Tor+XMPP+OTR: lattera@is.a.hacker.sx > > > > > GPG Key ID: 0x6A84658F52456EEE > > > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 > > 6EEE > > > > > > > > Latest kernel works for me : > > > > > > > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > > > > r336834: Sat Jul 28 20:23:33 CEST 2018 > > > > root@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC > > > > arm64 > > > > > > > > I'll try with latest loader.efi > > > > > > > > -- > > > > Emmanuel Vadot > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscribe@freebsd.org" > > > > > > Latest loader.efi fails for me the same way, Shawn did you start > > > bisecting ? > > > > > > > Problem is between 20180709 and 20180719 > > > > -- > > Emmanuel Vadot > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Sat Jul 28 19:55:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69110105C223 for ; Sat, 28 Jul 2018 19:55:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 E9BF07D2F0 for ; Sat, 28 Jul 2018 19:55:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id o22-v6so6825078ioh.6 for ; Sat, 28 Jul 2018 12:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OC7+XE3C/YzAKfodjQc3kR5PTd2eDk9QM+VQptf/oDU=; b=cDH1IWk6UdSxCoA7zAxrRrVtYCPy/Oh1RKwj+HSh8+oqFMBIuxoOZ8rRvZwjumBzMw ix8VZJd5LVEV3hG5YLQoB/UY81+4aHEDl+r6Y19R19Rhr9jtj0BKdKgd7NnOWC3E1qnh D17z191QbjCS7dLduc2ptLhGLdXJp2uKyKgI1YHavAmE16TFjxQuQEkiac8xBZWxFdvq BRpV9b4yeiHJOTufwxZSHwNONwvfnTRpd5c5xUuf6zsIWQ9UKZiVUpGIYFrmsJvR2oxL Er9Zxgw3meMTLDIvvORhcTFqW6JsHekdHo2NR4zwO5t10VHD5gYQkYOVly7PqRfv4BaW bHdA== 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=OC7+XE3C/YzAKfodjQc3kR5PTd2eDk9QM+VQptf/oDU=; b=MU6UITljhXvi7ZXue7xzTxaTTQob2n6Pcdipfu+wenSxMuke/ZqNDnnQ2aeJKvkI7V 7FlHqP2hYUP4eiV2z9xLzQSY1wjNOr3no00czfB06Z+HbsPJl+SxN9rhJehoTF5RwOhG EBoCZVdxZAQRzUEqHoz97BJmXvdkQVX0WCCpL79AhGduyGXY0s/Dw+iCWGuG0wbkEMkZ ZOJVC8GDdQvCOJqX25AgHMrk5ETgoXmVWYfDGw17rLS0ZQVs+Y2z4s4awya6SLSbjgct TlV56mJMstMjT4r4N/1+XVBP+iNSQX0+8QeNJJt6PFWut7WU1IBf20OqVtKnBT+rEa/I UfSA== X-Gm-Message-State: AOUpUlFy0/odP2pFj9bFKIPPIhqJi/ooxgV5KpEe8M0HriedhEUKW6PR 5M9N6cFSRjCMVIZwtgTHyMScoPujQTZXKZCZnPGIiA== X-Google-Smtp-Source: AAOMgpdWkuVG8dSkOyM1j8FcITdwrJgBDuxz3a2g7KxDxqyyOpOta6SxemK5RZW37imFRXZW6nTeKd6SL8GdN2Q2qD4= X-Received: by 2002:a6b:f719:: with SMTP id k25-v6mr9338531iog.37.1532807708261; Sat, 28 Jul 2018 12:55:08 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:4485:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 12:55:07 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180728215025.f5acbac48ab0969eff2e7545@bidouilliste.com> References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> <20180728205218.ef2661f72f27709c5d829708@bidouilliste.com> <20180728215025.f5acbac48ab0969eff2e7545@bidouilliste.com> From: Warner Losh Date: Sat, 28 Jul 2018 13:55:07 -0600 X-Google-Sender-Auth: Gj_O2jLT7kWXIaI028P5AO-Avik Message-ID: Subject: Re: Booting arm64 uefi broken To: Emmanuel Vadot Cc: Shawn Webb , FreeBSD Current , Warner Losh , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 19:55:09 -0000 On Sat, Jul 28, 2018 at 1:50 PM, Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 13:27:08 -0600 > Warner Losh wrote: > > > Let me know the rev... all my fixes are in the tree... > > > > Warner > > Fixed by r336837 > Yea, I thought I'd pushed all my in-flight src/stand branches yesterday, but I had one on a different machine that wasn't, and it was this one. Sorry for the hassle, it had been ready to go for a couple days... Warner > Thanks, > > > On Sat, Jul 28, 2018, 12:52 PM Emmanuel Vadot > wrote: > > > > > On Sat, 28 Jul 2018 20:34:31 +0200 > > > Emmanuel Vadot wrote: > > > > > > > On Sat, 28 Jul 2018 20:28:30 +0200 > > > > Emmanuel Vadot wrote: > > > > > > > > > On Sat, 28 Jul 2018 13:17:45 -0400 > > > > > Shawn Webb wrote: > > > > > > > > > > > It appears with the latest 12-CURRENT/arm64, booting is broken. > The > > > > > > boot process gets stuck after the "Using DTB provided by..." > message. > > > > > > > > > > > > This is on my SoftIron OverDrive 1000: > > > > > > > > > > > > >> FreeBSD EFI boot block > > > > > > > > > Loader path: /boot/loader.efi > > > > > > > > > > > > > > > > > > Initializing modules: ZFS UFS > > > > > > > > > Load Path: \EFI\BOOT\BOOTAA64.EFI > > > > > > > > > Load Device: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD( > 1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > > > > > BootCurrent: 0002 > > > > > > > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > > > > > > > Probing 7 block devices......+..* done > > > > > > > > > ZFS found the following pools: rpool > > > > > > > > > UFS found 1 partition > > > > > > > > > Consoles: EFI console > > > > > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > > > > > > (Sat Jul 28 11:32:06 UTC 2018 root@nyi-01.build.hardenedbsd.org) > > > > > > > > > > > > > > > > > > Command line arguments: loader.efi > > > > > > > > > EFI version: 2.60 > > > > > > > > > EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > > > > > > > Console: efi (0) > > > > > > > > > Load Path: > > > HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > > > Load Device: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD( > 2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > > > BootCurrent: 0002 > > > > > > > > > BootOrder: 0001 0005 0006 0000 0002[*] > > > > > > > > > BootInfo Path: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > > > > Ignoring Boot0002: Only one DP found > > > > > > > > > Trying ESP: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD( > 2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > > > Setting currdev to disk1p2: > > > > > > > > > Loading /boot/defaults/loader.conf > > > > > > > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > > > syms=[0x8+0x11d108+0x8+0x10e646] > > > > > > /boot/entropy size=0x1000 > > > > > > > > > efi-autoresizecons: Neither Graphics Output Protocol nor > Universal > > > Graphics Adapter present > > > > > > > > > > > > > > > Hit [Enter] to boot immediately, or any other key for command > > > prompt. > > > > > > Booting [/boot/kernel/kernel]... > > > > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -- > > > > > > Shawn Webb > > > > > > Cofounder and Security Engineer > > > > > > HardenedBSD > > > > > > > > > > > > Tor-ified Signal: +1 443-546-8752 > > > > > > Tor+XMPP+OTR: lattera@is.a.hacker.sx > > > > > > GPG Key ID: 0x6A84658F52456EEE > > > > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F > 5245 > > > 6EEE > > > > > > > > > > Latest kernel works for me : > > > > > > > > > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > > > > > r336834: Sat Jul 28 20:23:33 CEST 2018 > > > > > root@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/ > GENERIC > > > > > arm64 > > > > > > > > > > I'll try with latest loader.efi > > > > > > > > > > -- > > > > > Emmanuel Vadot > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to " > > > freebsd-current-unsubscribe@freebsd.org" > > > > > > > > Latest loader.efi fails for me the same way, Shawn did you start > > > > bisecting ? > > > > > > > > > > Problem is between 20180709 and 20180719 > > > > > > -- > > > Emmanuel Vadot > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > -- > Emmanuel Vadot > From owner-freebsd-current@freebsd.org Sat Jul 28 20:28:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71840105D4E1 for ; Sat, 28 Jul 2018 20:28:35 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 DA26C7F709 for ; Sat, 28 Jul 2018 20:28:34 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x242.google.com with SMTP id s12-v6so8882698wmc.0 for ; Sat, 28 Jul 2018 13:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Nv7fhfwYdmhNOvta9xg5noV3G4SV4WFuEsIcU9zxhME=; b=aJACxx9emOzUgS5egeUBQfnEP2VZQbZblekRrvhuffgUvbb608M0pT9DJWbLKE7jPc zwBIdyw0b5YSjnjvm3o+5Wcircw1Mi+Vo1c5mf7CQqvVfL3phjlsi7gBGcy6l8BftDcS dI0AveR3voPLKmtyPLx2ha0joWBMXBXKmT6DUduAoPj3dya03pIRz4yvuPIi9LbCVnd3 nCijdoFkJ35ASAq8vVAbkNrfzz6BVeTl9xd5PwWVwt+jQWmNtGaLcCXzJ4y/DhLLvJ+1 jIIOVHhIcje/BOjgtNvKX1mJX9FEIUqSYDGicWlkF9Y4peoCimtelJOiTYu4NC/XILxD d2nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Nv7fhfwYdmhNOvta9xg5noV3G4SV4WFuEsIcU9zxhME=; b=mwa8cgIpuo55AckgJRQHgPAvCoGwxpA917dcvlz/txJwuHRYtk9TWFud8LTKvV9SrJ DRsbWmWnrP5kaebUwdPKhaxkpmNxW8tvQUwcRtjpw8KWKdJwqORRqTN+XQj9J0jj4XoM pvy4F9XccHT+s2GT4WB7Iexc/jb86nBfP7617FCD2VGk9C7U1AyjSqYnEfVybbpLE429 T8p5v+N9DSAx2uTrqznk0D0FztfRQiIO7+emc4EifMRuSB6zOQzzJHhXoRFF381H4NIy hUF/sEHHaMTdLT/X5RoGTJ4OSop0Ij39DVKe2aqc1wjt7tTgydVHYLP2yUk3x93nvWUg Na9A== X-Gm-Message-State: AOUpUlFgIAn/yb3utS/Z0BXsg93kCuUG3SzZ8jzz3VoPAh/aZvlyP/6e i2YBh4xcuRUC8o0gSghc0EmWeA== X-Google-Smtp-Source: AAOMgpesLz4jsEYZPfASjnYaPc1YSm8U0rmNp47I01V8lmd+LyjQM66L0n96N+rfjyzDL8gYs9MRDQ== X-Received: by 2002:a1c:180e:: with SMTP id 14-v6mr9426615wmy.120.1532809713662; Sat, 28 Jul 2018 13:28:33 -0700 (PDT) Received: from mutt-hbsd ([185.220.102.4]) by smtp.gmail.com with ESMTPSA id q1-v6sm11169154wrw.42.2018.07.28.13.28.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 13:28:32 -0700 (PDT) Date: Sat, 28 Jul 2018 16:27:53 -0400 From: Shawn Webb To: Warner Losh Cc: Emmanuel Vadot , FreeBSD Current , Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: Booting arm64 uefi broken Message-ID: <20180728202753.p7mou4gmot54mzy6@mutt-hbsd> References: <20180728171745.e5g6dfrcjdn2mtg4@mutt-hbsd> <20180728202830.5ff22ce7b88c6cbf2cf25e18@bidouilliste.com> <20180728203431.4cb39877c0e1a9c55daf9641@bidouilliste.com> <20180728205218.ef2661f72f27709c5d829708@bidouilliste.com> <20180728215025.f5acbac48ab0969eff2e7545@bidouilliste.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="55hrtwwwlxxehgq4" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 20:28:35 -0000 --55hrtwwwlxxehgq4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 28, 2018 at 01:55:07PM -0600, Warner Losh wrote: > On Sat, Jul 28, 2018 at 1:50 PM, Emmanuel Vadot > wrote: >=20 > > On Sat, 28 Jul 2018 13:27:08 -0600 > > Warner Losh wrote: > > > > > Let me know the rev... all my fixes are in the tree... > > > > > > Warner > > > > Fixed by r336837 > > >=20 > Yea, I thought I'd pushed all my in-flight src/stand branches yesterday, > but I had one on a different machine that wasn't, and it was this one. > Sorry for the hassle, it had been ready to go for a couple days... Thanks for commiting the fix! I really appreciate it. :) --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --55hrtwwwlxxehgq4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAltc0cUACgkQaoRlj1JF bu4O1xAAkrLqjYZq4l2M3YKdtIvfuvlWhfhzp2YMOQ5cbQY6pPb5WCEOCzhyr0OD z04n5mlYzanT8zPBPnRF0tu+RGnDsJQXalvGq/iSszecdoy8KT2OZwPA4Ozm/hMK mCUj7RDUguYHGdQxjEIEHidSXkLs0RWeE7h5tCSUoS8wG4UkO3ulTSSPyf7g7C7t GAusBE4ZVYhpaJg23nAeSO03oIiL8Q4q3ykoY0dMMvoT7JB3ZL1x/x29rAnTR4zZ 0IQVm6UM94uia7Z5xazmU8u/mH3PEc0G7LZ4hgeAe3gfhCO2u/R3qtwdJahuMg8S +72k6om/oef3xAPYE4fWdxRCmkif/22wZcMBDHEJZMMtn+e6uw+vG9mk4Jxq0kk7 jLI4x6mCb8Ry7yLEarvNDEQJEkr7PZABlmAiHWaYNPXM74ZOzyHl5he5ydakuVGm nC9ezhoV4l10FLWv8MXSZ8jy9ECo2dz2NhuGTdCOtwLm6aCDIsV0xIZhLzAOQ/UT vEC23VsthwQK2f2/cQ4IU0fAvSs3HGY+TMWiCYtUVUEoN8EOJR6Lf5Qrf/CaanHw LBzmCZmYeT/GDUsMvC9AR/76S/3gHQ/xqTp7HS/n4jW+oZKNh8Sa+Nq4rKYq3Bto PcxZGInbIl+zmIAM/yk39+fRdZYknI0+R2x18nIb+SRfRoppsn8= =tbMu -----END PGP SIGNATURE----- --55hrtwwwlxxehgq4--